Professional Documents
Culture Documents
11
12
13
14
.
.
.
.
.
17
17
21
21
23
26
.
.
.
.
.
.
.
29
29
29
31
33
33
34
35
.
.
.
.
.
.
37
37
38
40
40
41
42
3 Les
3.1
3.2
3.3
3.4
.
.
.
.
.
lois de probabilit
e usuelles en fiabilit
e
Introduction . . . . . . . . . . . . . . . . . . . . .
La loi exponentielle exp() . . . . . . . . . . . . .
La loi de Weibull W(, ) . . . . . . . . . . . . .
Autres lois usuelles . . . . . . . . . . . . . . . . .
3.4.1 La loi gamma G(, ) . . . . . . . . . . . .
3.4.2 La loi lognormale LN (m, 2 ) . . . . . . .
3.4.3 Lois avec taux de defaillance en baignoire .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Calculs de fiabilit
e par structure
4.1 Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Syst`emes serie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Syst`emes parall`eles . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Definition et proprietes . . . . . . . . . . . . . . . . . . . . . . .
4.3.2 Cas o`
u tous les composants ont un taux de defaillance constant
4.3.3 Cas o`
u tous les composants sont identiques . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
8
9
10
`
TABLE DES MATIERES
.
.
.
.
.
.
.
42
43
44
44
44
45
46
5 Fiabilit
e dun logiciel non corrig
e : le processus de Poisson homog`
ene
5.1 Rappels et definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Proprietes des processus de Poisson homog`enes . . . . . . . . . . . . . . . .
5.2.1 Lois des durees inter-defaillances . . . . . . . . . . . . . . . . . . .
5.2.2 Lois des instants de defaillances . . . . . . . . . . . . . . . . . . . .
5.2.3 Loi du nombre de defaillances survenues a` chaque instant . . . . . .
5.2.4 Fiabilite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.5 MTTF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Estimation de la fiabilite . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Application aux donnees de lexemple . . . . . . . . . . . . . . . . . . . . .
5.5 Validation des logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.1 Validation en presence de defaillances . . . . . . . . . . . . . . . . .
5.5.2 Validation en labsence de defaillances . . . . . . . . . . . . . . . .
49
49
51
51
51
51
52
53
53
55
55
56
57
6 Les mod`
eles `
a dur
ees inter-d
efaillances exponentielles (ETBF)
6.1 Definition et proprietes . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 Loi des instants de defaillance . . . . . . . . . . . . . . . .
6.1.2 Loi du nombre de defaillances survenues a` chaque instant .
6.1.3 Fiabilite et MTTF . . . . . . . . . . . . . . . . . . . . . .
6.1.4 Fonction de vraisemblance . . . . . . . . . . . . . . . . . .
6.2 Le mod`ele de Jelinski-Moranda . . . . . . . . . . . . . . . . . . .
6.3 Le mod`ele geometrique de Moranda . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
59
59
60
60
60
61
61
64
.
.
.
.
.
.
.
.
.
.
.
67
67
68
69
69
70
70
72
75
75
75
76
4.4
4.5
4.6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
77
Chapitre 1
Probl
ematique de la s
uret
e de
fonctionnement des syst`
emes
informatiques
1.1
Contexte
Chapitre 1 - Probl
ematique de la s
uret
e de fonctionnement des syst`
emes
informatiques
de ces perturbations (communique de la SNCF). Le bug a provoque de longues files
dattente devant les guichets, mais na pas affecte les finances de la SNCF, car 90%
des voyageurs de cette periode avaient achete leurs billets a` lavance.
30 et 31 Octobre : une panne de plus dune journee est survenue sur le reseau fixe de
France Telecom. 26 commutateurs sur 600 ont ete affectes dans la region parisienne,
le nord et louest de la France. Quelques milliers dappels ont ete rejetes ou ne sont
pas parvenus a` leur destinataire. La panne provenait dune anomalie logicielle dans
un equipement de traitement de la voix sur IP (VoIP) situe `a Reims. Cette anomalie
logicielle a provoque des anormalites dans le formatage de la numerotation de certains
appels, qui ont declenche des protections de securite pour eviter une panne du reseau
(communique de France Telecom).
17-18 Novembre : une panne de plus dune journee est survenue sur le reseau mobile de Bouygues Telecom. 1.37 millions de clients nont pas pu du tout utiliser
leur portable et 5.6 millions ont eu des difficultes pour acceder au reseau. La facture de la panne sest elevee a` 16 millions deuros : une journee de chiffre daffaires
perdue et lequivalent en non facture aux clients en compensation du desagrement
subi. La panne provenait du dysfonctionnement de la base de donnees qui sert `a
reperer le mobile du client, lui permet dacheminer ses appels et den recevoir. Deux
serveurs centraux jumeaux sont tombes en panne au meme moment, dans deux endroits differents. Les deux serveurs sont du materiel classique et largement utilise
par de nombreux operateurs de telephonie mobile avec, jusqu`a ce jour, une fiabilite
sans faille. En fonctionnement normal, ils se secourent en prenant le relais lun de
lautre. La panne est de nature exceptionnelle (communique de Bouygues Telecom).
3 Decembre : 800 terminaux de vente de la SNCF (sur 4000) ont ete paralyses pendant
plus dune journee. La panne provenait dun algorithme defectueux qui a progressivement contamine les terminaux de vente en gare. Cet algorithme a pour objectif de
definir la zone de travail informatique de la transaction de paiement (communique
de la SNCF). Un nouveau bug du meme type est survenu en novembre 2009.
Dans ces 4 cas, les probl`emes ont ete causes par des defaillances logicielles. Le site
www5.in.tum.de/huckle/bugse.html recense une impressionnante collection de defaillances logicielles. Parmi celles-ci :
4 Juin 1996 : la fusee Ariane 5 a explose a` cause dune faute de conception logicielle,
et plus precisement un probl`eme de reutilisation. Un programme de controle dun
gyroscope de la fusee (en ADA) avait ete transfere sans modification dAriane 4 a`
Ariane 5. Or les trajectoires de vol dAriane 5 sont sensiblement differentes de celles
dAriane 4. Cela a provoque un depassement de mantisse qui a induit en erreur le
calculateur de pilotage et fini par faire exploser le lanceur. Cette erreur a co
ute 500
millions de dollars uniquement en materiel, sans parler des retards engendres et des
consequences sur limage de marque dArianespace.
3 mai 2000 : la moitie des ressources du reseau national de France Telecom ont ete
paralysees.
3 juin 2004 : le trafic aerien britannique a ete fortement perturbe pendant plusieurs
heures suite a` une defaillance du syst`eme informatique de controle aerien, qui a prive
tous les appareils en vol de ressources informatiques pendant deux heures.
1.1 Contexte
8 octobre 2005 : un defaut dans le syst`eme de controle en vol de la fusee russe Rockot
provoque la perte du satellite CryoSat charge detudier linfluence du rechauffement
climatique sur la fonte des glaces polaires. Co
ut de la mission : 136 millions deuros.
Septembre 2007 : un bug dans Excel 2007 provoque des resultats de multiplication
fantaisistes comme 77.1 850 = 100000 (au lieu de 65535)i.
2007 : les retards de livraisons de lAirbus A380 sont en partie dus `a un probl`eme
logiciel dont lorigine tient au fait que les sites dHambourg et Toulouse ont utilise
deux versions differentes du logiciel de CAO de Dassault Syst`emes CATIA. Les
penalites versees aux compagnies aeriennes se chiffrent a` plusieurs milliards deuros.
Mars 2008 : Chrysler rappelle 25000 Jeeps Cherokee et Commander pour corriger
un defaut dans le logiciel de transmission automatique.
Janvier 2010 : un bug dans le logiciel de lecture des puces electroniques des cartes
bancaires fabriquees par Gemalto a empeche 30 millions dallemands de se servir de
leur carte de credit pendant pr`es dune semaine. Pour certains, ce bug de lan 2010
a largement surpasse le fameux bug de lan 2000...
Ces pannes majeures et repetees ont serieusement entame la confiance du public dans
la s
urete des reseaux de telecommunication et des syst`emes informatiques en general.
Dans de nombreux secteurs, on a pu constater que les defaillances sont de plus en plus
frequentes. En effet, dans un contexte fortement concurrentiel, les entreprises cherchent a`
reduire leurs co
uts et avancer les dates de lancement de leurs produits, au detriment en
particulier de la s
urete de fonctionnement.
Par exemple, la fiabilite des ordinateurs de bureau a enormement ch
ute, en meme temps
que les co
uts. La garantie constructeur est passee de 3 ans `a 1 an en quelques annees et
les extensions de garantie sont tr`es ch`eres, ce qui indique clairement que les pannes des
PC sont tr`es frequentes.
Extraits dun article de Liberation du 19 novembre 2004 (voir document sur le Kiosk),
suite `a la succession de pannes des reseaux informatiques francais :
A la racine de toutes ces pannes, on trouve des defaillances de linformatique.
Il sagit danomalies logicielles.
On controle la qualite des services ou encore la couverture des reseaux, mais pas la
vulnerabilite des syst`emes.
Si la panne survient, cest que les operateurs rognent sur tout, y compris sur la
fiabilite de leur syst`eme.
Le consommateur est bien en droit de reclamer aujourdhui la garantie dune fiabilite
absolue. Celle-ci doit devenir un motif dachat, donc un argument de vente imperatif.
Pour que la fiabilite devienne un argument de vente imperatif, il faut etre capable de
levaluer ou la mesurer. Cest lobjectif essentiel de ce cours.
Chapitre 1 - Probl
ematique de la s
uret
e de fonctionnement des syst`
emes
informatiques
1.2
Terminologie g
en
erale de la s
uret
e de fonctionnement
1.3 Fiabilit
e des mat
eriels ou des logiciels
La maintenance pr
eventive est effectuee alors que le syst`eme fonctionne et a pour
but de retarder loccurrence des defaillances futures.
Dans les etudes de s
urete de fonctionnement, on distingue les approches bote noire et
bote blanche :
Approche bote blanche ou structurelle : on consid`ere quun syst`eme complexe
est constitue de composants et que sa fiabilite depend `a la fois de la fiabilite de
ses composants et de la facon dont le bon fonctionnement ou la panne de chaque
composant influe sur le bon fonctionnement ou la panne du syst`eme tout entier. En
particulier, on consid`ere souvent quun syst`eme reparable est constitue de composants non reparables. Quand un composant tombe en panne, on le remplace par un
neuf, mais le syst`eme complet, lui, nest pas remis `a neuf.
Approche bote noire ou globale : on consid`ere le syst`eme comme un tout, quon
ne cherche pas `a decomposer en composants. On sinteresse alors a` la suite des
defaillances et reparations successives du syst`eme.
1.3
Fiabilit
e des mat
eriels ou des logiciels
A priori, les defaillances des syst`emes informatiques peuvent etre soit dorigine materielle,
soit dorigine logicielle. En pratique, plus de 80 % sont dorigine logicielle. Cest le cas
de tous les exemples presentes dans la section 1.1. On sinteressera donc en priorite aux
probl`emes logiciels. Mais on peut noter quil existe des differences fondamentales entre la
fiabilite des materiels et celle des logiciels.
Les defaillances des materiels sont essentiellement dues a` lusure (ou vieillissement)
et aux facteurs environnementaux, tandis que celles des logiciels sont dues `a des
fautes de conception (ou bugs), cest-`a-dire a` des erreurs humaines.
Un materiel suse, un logiciel ne suse pas.
La maintenance des materiels ralentit le vieillissement des syst`emes mais ne lempeche
pas, tandis que la correction des logiciels augmente leur fiabilite.
Un logiciel non utilise ne tombe pas en panne (le terme de panne est dailleurs peu
utilise pour le logiciel). Un materiel non utilise peut tomber en panne du fait de
lusure ou des facteurs environnementaux.
En logiciel, une faute bien reperee et corrigee est eliminee definitivement et ne peut
plus se manifester. En materiel, on peut observer des defaillances repetables ou chroniques.
La sensibilite dun materiel `a son environnement est assez forte, mais on peut
neanmoins considerer quun materiel a une fiabilite en soi : les constructeurs quantifient la fiabilite dune ampoule electrique quel que soit son environnement. En revanche, la sensibilite dun logiciel a son environnement, a` travers son profil operationnel, est extremement forte. Un logiciel truffe de fautes peut tr`es bien fonctionner sans
defaillance si le profil operationnel nactive pas ces fautes. Un materiel ayant beaucoup de defauts ou tr`es use tombera fatalement en panne, quelle que soit la mani`ere
dont on lutilise.
Chapitre 1 - Probl
ematique de la s
uret
e de fonctionnement des syst`
emes
10
informatiques
Quand un materiel est en panne, il ne peut pas fonctionner tant quon ne la pas
repare. Au contraire, un logiciel peut etre relance immediatement apr`es une defaillance.
On voit que les differences sont nombreuses entre fiabilite des materiels et fiabilite des
logiciels. On ne pourra donc pas traiter les deux aspects de la meme mani`ere. Historiquement, les concepts de la fiabilite ont ete introduits pour les materiels. On commencera
donc par introduire ces concepts pour les materiels, puis on presentera les specificites des
logiciels.
1.4
Le risque logiciel
Les defaillances des logiciels sont causees par des fautes dans les programmes. Or,
dune part, une etude [16] a montre quun programmeur professionnel fait en moyenne 6
fautes pour 1000 lignes de code (LOC) ecrites, et dautre part, la taille et la complexite
des logiciels ne cesse daugmenter. Par exemple :
la navette spatiale americaine a besoin pour voler de 500 000 LOC logiciel embarque
et 3 millions et demi de LOC au sol.
les reseaux telephoniques utilisent des millions de LOC pour fonctionner.
le nombre de LOC est passe de moins de 5 millions pour Windows 95 `a plus de 50
millions pour Windows Vista.
plus generalement, un logiciel commercial standard fait en moyenne 350 000 LOC.
Par consequent, cela fait environ 2000 fautes potentielles pour un logiciel standard, 24
000 pour la navette spatiale et 300 000 pour Vista !
Evidemment, tout est fait pour eliminer ces fautes, essentiellement par le test du
logiciel. Mais il est extremement difficile et co
uteux de detecter et corriger des fautes
dans un logiciel. En effet, une etude de Microsoft [16] a etabli quil fallait en moyenne 12
heures de travail pour detecter et corriger une faute. Si un logiciel contient 2000 fautes,
il faut donc passer 24 000 heures pour le deboguer, soit presque 3 ans de travail cumule.
Cest pourquoi Microsoft emploie autant de personnel pour tester, verifier et valider les
programmes que pour les creer. Et malgre cela, chacun a pu experimenter quil subsiste
des erreurs dans les logiciels de Microsoft. Une etude plus recente [17] evalue a` 60% du
budget total dun projet informatique le co
ut de la detection et correction des erreurs
logicielles (ou maintenance du logiciel).
Malgre tous ces efforts, la complexite de la tache fait quil reste toujours des fautes
dans un logiciel. Comme partout, et peut-etre meme moins que partout, le zero defaut est
impossible. Quand ces fautes residuelles se manifestent, leurs consequences peuvent aller
du minime au franchement catastrophique, comme on la vu dans la section 1.1.
Il est donc imperatif de tout faire pour eviter que des pannes informatiques majeures
se produisent. Pour cela, on dispose de nombreuses methodes dont le but est de produire
des logiciels de fonctionnement s
ur. On peut classer ces methodes en 4 categories [10, 11] :
La pr
evention des fautes : ces methodes ont pour but dempecher loccurrence et
lintroduction de fautes d`es la conception du logiciel. Par exemple, on a de plus en
plus souvent recours a` des methodes formelles pour developper les specifications.
1.5 M
ethodes d
evaluation de la fiabilit
e des logiciels selon les
etapes du
cycle de vie
11
L
elimination des fautes : ces methodes ont pour but de detecter des fautes dans
un programme dej`a ecrit. Elles comprennent les preuves de programmes, les inspections formelles, la verification et surtout le test du logiciel.
La tol
erance aux fautes : ces methodes ont pour but de permettre au syst`eme de
fonctionner correctement meme en presence de fautes. On peut par exemple utiliser
de la redondance.
La pr
evision des fautes : ces methodes ont pour but destimer la presence des
fautes et de prevoir les defaillances futures du syt`eme.
Les methodes presentees dans ce cours rentrent dans la derni`ere categorie. En effet, il
ne suffit pas davoir utilise tous les moyens possibles pour developper un logiciel fiable,
encore faut-il sassurer quil lest effectivement : il faut des methodes pour atteindre des
objectifs de fiabilite (les trois premi`eres categories, qui concernent le genie logiciel) et
faire appel `a dautres methodes pour savoir si ces objectifs sont atteints (la quatri`eme
categorie, qui fait intervenir des concepts probabilistes et statistiques). Par consequent,
il est tr`es important de pouvoir prevoir loccurrence des defaillances, et donc d
evaluer,
mesurer ou quantifier la fiabilite dun logiciel. Notons que cette quatri`eme categorie de
methodes est aujourdhui moins utilisee dans lindustrie que les trois autres [19], mais que
cela va evoluer, notamment avec la prise en compte de ces notions dans les normes [2].
Pour les logiciels, on reduit parfois le concept de s
urete de fonctionnement `a celui de
securite-confidentialite. Cependant la securite-confidentialite concerne exclusivement les
dysfonctionnements dus a` des actes de malveillance volontaires (virus, attaques, etc.) alors
que la s
urete de fonctionnement prend egalement en compte les dysfonctionnements non
volontaires : pannes materielles, fautes logicielles, erreurs humaines non intentionnelles,
etc.
1.5
M
ethodes d
evaluation de la fiabilit
e des logiciels
selon les
etapes du cycle de vie
Les methodes devaluation de la fiabilite des logiciels varient suivant la nature des
informations disponibles. Celles-ci sont etroitement liees au cycle de vie du logiciel, comme
on le voit dans le tableau 1.1 [16] .
Phase du cycle de vie
Analyse
Conception
Codage et test
Vie operationnelle
Pourcentage derreurs
introduites
55%
30%
10%
5%
Pourcentage derreurs
detectees
18%
10%
50%
22%
Table 1.1 Pourcentages derreurs introduites et detectees selon les phases du cycle de
vie du logiciel
Les types derreurs dans les differentes phases sont les suivantes :
Chapitre 1 - Probl
ematique de la s
uret
e de fonctionnement des syst`
emes
12
informatiques
On constate que la majeure partie des erreurs sont introduites dans les premi`eres phases
du cycle de vie (85% en analyse et conception) et detectees dans les derni`eres phases (72%
en codage, test et vie operationnelle).
Dans les phases danalyse, conception et codage, le syst`eme nest pas encore construit,
donc il ne peut pas etre utilise et aucune defaillance nest observee. Les elements pouvant
etre utilises pour des previsions de fiabilite sont la structure du syst`eme et les metriques
logicielles (nombre de lignes de code, nombre cyclomatique du graphe de controle, mesures
darchitecture et de specifications, etc... [8]). A ce niveau, on peut evaluer la qualite du
logiciel, mais pas sa fiabilite. Or on ne sait pas mesurer la correlation entre qualite et
fiabilite dun logiciel.
En phase de test et en vie operationnelle, le syst`eme fonctionne, des defaillances sont
observees et des corrections sont apportees au logiciel pour remedier aux fautes apparues.
Lessentiel des methodes devaluation de la fiabilite repose sur lobservation et lanalyse
statistique de cette suite de defaillances et corrections successives.
Tout comme les materiels, les logiciels complexes sont constitues de modules unitaires
que lon assemble. Si on est capable devaluer la fiabilite de chaque module et danalyser
les liens entre les differents modules, on peut appliquer les methodes structurelles (bote
blanche) devaluation de fiabilite. Ce nest pas du tout facile en pratique. Aussi consid`eret-on en general un logiciel comme un tout et on evalue sa fiabilite par une approche bote
noire. Cest ce que nous ferons dans ce cours.
1.6
Utilisation des
evaluations de fiabilit
e des logiciels
1.7 Terminologie sp
ecifique aux logiciels
13
1.7
Terminologie sp
ecifique aux logiciels
.......
.....
......
Programme
.......
.....
......
Les sp
ecifications definissent quelle doit etre la donnee de sortie pour chaque donnee
dentree possible. Si, pour une donnee dentree particuli`ere, la sortie fournie par le pro-
Chapitre 1 - Probl
ematique de la s
uret
e de fonctionnement des syst`
emes
14
informatiques
gramme nest pas celle prevue par les specifications, il y a defaillance. On voit ainsi
apparatre une relation forte entre donnee dentree et defaillance, sur laquelle nous reviendrons.
Une faute logicielle ou bug est un defaut du programme qui, execute dans certaines
conditions, entranera une defaillance. Une faute est un phenom`ene intrins`eque au programme, elle existe meme quand le logiciel nest pas utilise. A linverse, une defaillance
est un phenom`ene dynamique : le programme doit etre execute pour quelle se manifeste.
Une faute est creee suite `a une erreur humaine de lanalyste, du concepteur ou du programmeur. Aussi, on emploie le terme de faute de conception. Les erreurs peuvent etre
de specification, de conception ou de codage. Il est egalement possible quune defaillance
dun syst`eme informatique soit due a` un probl`eme materiel. Ce type de defaillance est en
general facilement identifiable. Nous ne le traiterons pas dans la suite, o`
u nous supposerons
que toutes les defaillances sont dues a` des fautes de conception (au sens large).
Si on pouvait tester toutes les entrees possibles dun logiciel, on detecterait fatalement
toutes les fautes. Mais le nombre dentrees possibles est beaucoup trop grand pour cela.
Il faut donc determiner dans lespace des entrees un sous-ensemble dentrees a` tester.
Le profil op
erationnel definit le choix des entrees et la frequence de sollicitation du
logiciel, en associant `a chaque entree ou groupe dentrees sa probabilite detre fournie
au programme `a un instant donne. Le profil operationnel est en general tr`es different en
phase de test et en vie operationnelle.
Quand une defaillance survient, on cherche `a detecter la faute qui a provoque cette
defaillance et a` leliminer. On effectue alors une correction ou d
ebogage. Parfois, un
logiciel est amene a` changer radicalement certaines de ses fonctionnalites. On proc`ede
alors a` un changement de sp
ecifications, qui va aboutir a` une nouvelle version du
logiciel. Les corrections et les changements de specifications peuvent etre interpretes de
la meme mani`ere comme des modifications du programme. Une modification dun logiciel
est parfois appelee une maintenance logicielle. La correction a pour but de reduire loccurrence dapparition des defaillances, donc elle devrait augmenter la fiabilite du logiciel.
1.8
Exemple de donn
ees
Le syst`eme observe est une machine UNIX sur laquelle tourne un gros logiciel de bases
de donnees en phase de test. Le syst`eme a ete observe sur un an, du 14 juin 1995 `a 16h14
au 11 juin 1996 `a minuit.
Un demon a note tous les instants de panne, les causes des pannes et les instants de
redemarrage de la machine. Suivant la nature des interruptions, des corrections ont ete
apportees ou pas au logiciel. Le temps pris en compte est le temps calendaire. Le tableau
1.2 presente un extrait du rapport de fiabilite brut genere automatiquement par le demon.
On peut facilement en extraire les durees de bon fonctionnement et de non fonctionnement
successives.
On constate que les durees de non fonctionnement de la machine sont, dune part
negligeables par rapport aux durees de bon fonctionnement, et dautre part difficilement
exploitables : on a une valeur aberrante (7168) due `a une defaillance survenue pendant
un pont du mois de juin, puis des valeurs quasiment constantes (`a 4 mn). Cest souvent
le cas, aussi on se contente en general danalyser les durees de bon fonctionnement ou
durees inter-defaillances.
15
06/14/95 16:14
06/11/96 00:00
Territory:
Machine Usage:
Observation Phase:
FR
DataBase
Development
Interruption:
Start
06/14/95
06/14/95
06/24/95
06/28/95
06/29/95
09/14/95
10/03/95
10/09/95
10/23/95
Stop
16:14
17:17
19:28
15:02
10:21
15:16
17:39
17:37
12:13
06/14/95 16:52
06/19/95 23:00
06/28/95 13:24
06/29/95 10:16
07/05/95 17:00
10/03/95 17:34
10/09/95 17:33
10/23/95 12:08
--------------
Up Time
(h)
1
126
90
19
151
458
144
331
---
Stop Reason
Stop Error
Unknown
Unknown
Others
Normal
Time Out
Normal
Normal
Envir. Fault
------------
Boot Down
Boot Down
Program Int
Reboot Id
Graphics
Reboot Id
Reboot Id
Bump Int
-----------
Down Time
(mn)
25
7168
98
4
0
4
4
4
----
Chapitre 1 - Probl
ematique de la s
uret
e de fonctionnement des syst`
emes
16
informatiques
900
800
700
600
500
400
300
200
100
0
10
15
20
25
une mod
elisation probabiliste du processus des defaillances et corrections successives du logiciel
une analyse statistique de la suite de ces defaillances et corrections.
Le chapitre 2 presente les concepts de base et definit les principales mesures de fiabilite.
Le chapitre 3 decrit les lois de probabilite usuelles en fiabilite, en insistant sur les lois
exponentielle et de Weibull. Le chapitre 4 est consacre aux calculs de fiabilite par structure,
permettant de calculer la fiabilite dun syst`eme non reparable complexe a` partir de la
fiabilite de ses composants. Le chapitre 5 traite de la modelisation et de levaluation de
fiabilite dun logiciel que lon ne corrige pas. Enfin, les deux derniers chapitres presentent
les deux principales classes de mod`eles de fiabilite des logiciels, les mod`eles `a durees interdefaillances exponentielles (ETBF) dans le chapitre 6 et les processus de Poisson non
homog`enes (NHPP) dans le chapitre 7.
Chapitre 2
Les mesures de fiabilit
e
Les concepts generaux de la fiabilite ont ete introduits pour les materiels. On les
presente ici dans ce contexte en signalant a` loccasion les specificites des logiciels. Les
mesures de fiabilite sont differentes suivant que les syst`emes concernes sont reparables ou
non reparables.
2.1
Comme on la vu, un syst`eme non reparable est un syst`eme qui est mis au rebut d`es
quil tombe en panne. Les considerations sur les reparations ou corrections nont donc
pas lieu detre ici. Le seul point important est la date de panne, appelee aussi instant
de d
efaillance, dur
ee de vie ou dur
ee de bon fonctionnement du syst`eme. Comme
celle-ci nest pas previsible avec certitude `a lavance, on la modelise par une variable
aleatoire, que lon note X. Une duree etant un reel positif, cette variable aleatoire est a`
valeurs dans R+ .
Si on sinteressait `a des syst`emes pour lesquels le temps est exprime par un nombre
entier, comme un nombre de transactions, X serait a` valeurs dans N. On pourrait aussi
prendre en compte la possibilite que le syst`eme soit en panne `a linstant initial, ce qui
voudrait dire que P(X = 0) 6= 0. Nous ne nous placerons ici dans aucun de ces deux
cas. Par consequent, X sera une variable aleatoire continue `a valeurs dans R+ . Sa loi de
probabilite est definie par :
sa fonction de r
epartition F (x) = P(X x),
sa densit
e f (x) = F 0 (x).
Plus la duree de fonctionnement est grande, meilleure est la fiabilite du syst`eme. Donc
on choisit de definir la fiabilite du syst`eme `a linstant x comme la probabilite que le
syst`eme ne soit pas encore tombe en panne `a linstant x ou encore comme la probabilite
que le syst`eme fonctionne sans defaillance entre 0 et x.
D
efinition 1 La fiabilit
e dun syst`eme non reparable est la fonction du temps R (R
pour reliability) definie par :
x 0,
(2.1)
18
x 0,
h(x) = lim
(2.2)
Dans cette expression, la probabilite consideree est la probabilite que le syst`eme tombe
en panne entre x et x + x sachant quil a bien fonctionne entre 0 et x. Notons que la
fiabilite est une probabilite mais que le taux de defaillance nen est pas une : h(x) peut
etre superieur a` 1.
Linterpretation du taux de defaillance est liee `a celle de la densite de la facon suivante.
On sait que :
F (x + x) F (x)
x0
x
1
= lim
P(X x + x) P(X x)
x0 x
1
= lim
P(x < X x + x)
x0 x
On a donc, pour x
petit :
f (x) x P(x < X x + x)
et :
h(x) x P(x < X x + x | X > x)
La quantite f (x) x peut donc etre consideree comme la probabilite de defaillance
juste apr`es linstant x alors que h(x) x peut etre consideree comme la probabilite de
defaillance juste apr`es linstant x sachant que le syst`eme nest pas tombe en panne avant
x. Il y a donc une notion dinstantaneite dans f (x) et une notion de duree dans h(x)
(comme dans R(x)).
On peut illustrer cette difference en comparant :
la probabilite quun homme meure entre 100 et 101 ans ;
la probabilite quun homme meure entre 100 et 101 ans sachant quil a vecu jusqu`a
100 ans.
La premi`ere (liee a` la densite) est tr`es faible : on a de tr`es fortes chances de mourir
avant 100 ans. La seconde (liee au taux de defaillance) est evidemment tr`es forte.
On concoit donc que le taux de defaillance est une mesure pratique de lusure ou du
vieillissement. Un taux de defaillance croissant correspond a` un syst`eme qui se degrade,
19
tandis quun taux de defaillance decroissant correspond a` un syst`eme qui sameliore avec
le temps.
Il est facile detablir les liens entre le taux de defaillance et la fiabilite :
1
P(x < X x + x | X > x)
x0 x
1 P(x < X x + x X > x)
1 P(x < X x + x)
= lim
= lim
x0 x
x0 x
P(X > x)
P(X > x)
1
1
=
lim
[F (x + x) F (x)]
R(x) x0 x
f (x)
R0 (x)
d
f (x)
=
=
= ln R(x)
=
R(x)
1 F (x)
R(x)
dx
h(x) =
lim
D
efinition 3 Le taux de d
efaillance cumul
e ou taux de hasard cumul
e dun
syst`eme non reparable est la fonction du temps H definie par :
Z x
x 0, H(x) =
h(u) du = ln R(x)
(2.4)
0
20
la vie utile : pendant cette periode, le taux de defaillance est constant et les
defaillances sont purement accidentelles ;
le vieillissement : h se remet a` crotre car le risque de defaillance va finir par
augmenter a` cause de lusure du syst`eme.
20
40
60
80
100
MTTF = x R(x)
+
0
Z
+
R(x) dx
0
21
1
En supposant que R(x) tend vers 0 plus vite que , ce qui sera toujours le cas, on
x
obtient une formule plus usuelle pour le MTTF :
Z +
MTTF =
R(x) dx
(2.7)
0
2.2
R +
0
Quand les syst`emes sont reparables, deux cas de figure sont possibles, selon que lon
prend en compte ou pas les durees de reparation.
2.2.1
Dur
ees de r
eparation comptabilis
ees
fonctionnement
- -
X1
Y1
-
X2
panne
-
Y2
X3
M (y) = P(Y y)
22
1
P(y < Y y + y | Y > y)
y0 y
(y) = lim
Mais on peut sinteresser a` une autre quantite particuli`erement interessante pour les
syst`emes reparables, la disponibilite.
D
efinition 5 La disponibilit
e dun syst`eme reparable est la fonction du temps A (A
pour availability) telle que :
t 0,
Donner une expression mathematique generale est beaucoup plus complexe pour la
disponibilite que pour la fiabilite. Heureusement, il est souvent possible de donner des
expressions simples de la disponibilit
e asymptotique :
A() = lim A(t).
t+
Remarque : La fiabilite implique une notion de duree (fonctionnement pendant une certaine duree) tandis que la disponibilite implique une notion dinstantaneite (fonctionnement a` un instant donne).
Contrairement a` ceux de R(x) et M (y), le sens de variation de A(t) nest pas determine.
On a des syst`emes `a disponibilite croissante, dautres a` disponibilite decroissante et tous
les sens de variation imaginables sont possibles.
Quand le syst`eme est remis a` neuf apr`es reparation, il est logique de supposer que X2
a la meme loi de probabilite que X1 . Plus generalement, on suppose couramment que
les Xi sont independants et de meme loi, et que les Yi sont aussi independants et de
meme loi (mais pas la meme que celle des Xi ). Cela facilite grandement le calcul de la
disponibilite. Mais dans la pratique, la reparation ne remet pas souvent le syst`eme a` neuf,
ce qui complexifie les calculs.
On parle parfois de MTBF = MTTF+MTTR (Mean Time Between Failures). Le
MTBF est la duree moyenne entre deux defaillances successives, comprenant la duree
moyenne de bon fonctionnement et la duree moyenne de reparation. On a alors souvent :
lim A(t) =
t+
MT T F
,
MT T F + MT T R
2.2.2
23
Dur
ees de r
eparation non comptabilis
ees
T0 T1
T2 T3
T4
-
--
-
X1 X2
X3
X4
T5
X5
Remarque : Lhypoth`ese que les durees de correction sont negligeables peut sembler contradictoire avec les chiffres cites au chapitre 1 comme quoi il faudrait en moyenne 12 heures
pour detecter et corriger une faute. Dans la pratique, le logiciel est souvent relance sans
que la correction soit faite. Il fonctionne pendant que lequipe de correcteurs travaille
(alors que, rappelons-le, pour le materiel, la reparation empeche le fonctionnement). La
correction est introduite un peu plus tard. Les premiers travaux sur la fiabilite des logiciels
ont suppose que les durees de correction etaient negligeables (ou non comptabilisees) et
24
Nombre de dfaillances
25
20
15
10
5
0
1000
2000
3000
4000
t
5000
6000
7000
8000
quune correction etait effectuee `a chaque defaillance. Nous conserverons ces hypoth`eses
dans le cadre de ce cours, mais il est possible de prendre en compte des hypoth`eses plus
realistes.
Si on definit la fiabilite comme precedemment, seul linstant de la premi`ere defaillance
est en jeu :
x 0, R(x) = P(X1 > x) = P(T1 > x).
Or, si on prend le cas de lexemple, on souhaite etre capables devaluer la probabilite
que le logiciel fonctionne correctement pendant une duree quelconque `a partir de la fin du
test le 11 juin 1996. Aussi, on va modifier la definition de la fiabilite en considerant que
la fiabilite du syst`eme `a linstant t exprime la probabilite quil fonctionne correctement
pendant une certaine duree `a partir de t. Pour etre tout `a fait complet, on va considerer
que cette probabilite peut eventuellement dependre de tout ce qui sest passe depuis la
mise en service du syst`eme. Mathematiquement, cela signifie que cest une probabilite
conditionnelle au nombre et aux instants des defaillances ayant precede linstant present
t. Do`
u la definition suivante.
D
efinition 6 La fiabilit
e dun syst`eme reparable `a linstant t est la fonction Rt definie
par :
0,
25
tn
Tn+1
Figure 2.5 Fiabilite pour une duree a` partir de t, avec n defaillances observees
(2.9)
Suivre lintensite de defaillance au cours du temps revient donc a` etudier les taux de
defaillance conditionnels successifs des Xi sachant le passe. On parle alors de concatenation
ou damalgame de taux de defaillance.
On montre que lintensite de defaillance secrit aussi :
1
P(t < Tn+1 t + t | Nt = n, T1 = t1 , . . . , Tn = tn )
t0 t
1
P(Nt+t Nt = 0 | Nt = n, T1 = t1 , . . . , Tn = tn ) (2.10)
= lim
t0 t
t (n; t1 , . . . , tn ) =
lim
La probabilite dans cette ecriture est la probabilite que le syst`eme tombe en panne
entre t et t + t sachant tout le passe du processus des defaillances `a linstant t.
Lintensite de defaillance est aux syst`emes reparables ce que le taux de defaillance est
aux syst`emes non reparables. Une intensite de defaillance croissante correspond a` une
frequence de defaillance qui augmente avec le temps, donc `a un syst`eme qui suse malgre
les reparations. Une intensite de defaillance decroissante correspond `a un syst`eme qui
sameliore avec le temps. A priori, les materiels rentrent dans la premi`ere categorie et les
logiciels dans la seconde.
D
efinition 8 Le MTTF dun syst`eme reparable `a linstant t est la duree moyenne dattente de la prochaine defaillance `a linstant t, sachant tout le passe du processus des
defaillances `a cet instant :
MTTFt (n; t1 , . . . , tn ) = E [Tn+1 t | Nt = n, T1 = t1 , . . . , Tn = tn ]
(2.11)
Les resultats suivants sont les equivalents pour les syst`emes reparables des formules
(2.3) et (2.7).
26
Z
Rt ( ; n, t1 , . . . , tn ) = exp
t+
Z
u (n; t1 , . . . , tn ) du = exp
t+u (n; t1 , . . . , tn ) du
(2.12)
Z
Rt ( ; n, t1 , . . . , tn ) d
MTTFt (n; t1 , . . . , tn ) =
(2.13)
Z t
u (n; t1 , . . . , tn ) du
> t | T1 = t1 , . . . , Tn = tn ) = exp
tn
Z
> t tn | T1 = t1 , . . . , Tn = tn ) = exp
ttn
hXn+1 |T1 =t1 ,...,Tn =tn (u) du
Une autre mesure importante de fiabilite des syst`emes reparables est le nombre moyen
de defaillances survenues a` chaque instant. Cest ce quon appelle la fonction moyenne.
D
efinition 9 La fonction moyenne (en anglais mean value function) du processus des
defaillances est la fonction m definie par :
t 0,
m(t) = E[Nt ]
(2.14)
Pour le cas o`
u on ne prend pas en compte les durees de reparation, toutes les mesures
de fiabilite des syst`emes reparables sexpriment a` laide de lintensite de defaillance. Par
consequent, construire un mod
ele de fiabilit
e des syst`
emes r
eparables (et donc
des logiciels) revient `
a proposer une forme particuli`
ere pour lintensit
e de
d
efaillance.
Dans le cadre de ce cours, nous ne verrons que les 3 classes de mod`eles les plus simples,
caracterisees par les formes dintensite suivantes :
Processus de Poisson homog`enes (HPP)
t (n; t1 , . . . , tn ) =
2.3
t (n; t1 , . . . , tn ) = (t)
27
1. Mod
elisation probabiliste. A partir dhypoth`eses sur le fonctionnement du syst`eme, leffet des reparations et la nature du phenom`ene aleatoire ayant engendre les
defaillances, il faut proposer des mod`eles realistes pour les variables aleatoires impliquees. Par exemple, il faut proposer une loi de probabilite vraisemblable pour la
duree de bon fonctionnement X dun syst`eme non reparable ou pour la suite {Xi }i1
des durees inter-defaillances dun syst`eme reparable.
2. Analyse statistique. Les mod`eles proposes ont des param`etres inconnus quil va
falloir estimer. Pour cela, il faut observer le fonctionnement des syst`emes, relever les
instants des defaillances et des reparations, et effectuer une analyse statistique de
ces donnees (quon appelle le retour dexp
eriences). On va pouvoir ainsi estimer
les caracteristiques de fiabilite des syst`emes et utiliser ces estimations pour prendre
des decisions qui peuvent etre cruciales en termes de s
urete de fonctionnement. Par
exemple, il faut decider si un produit est suffisamment fiable pour que lon puisse le
mettre en vente sans risque, ou bien decider de larret des tests. Pour effectuer les
estimations, plusieurs methodes sont possibles, mais on utilise la plupart du temps
la methode du maximum de vraisemblance.
28
Chapitre 3
Les lois de probabilit
e usuelles en
fiabilit
e
3.1
Introduction
On a dit que la fiabilite dun syst`eme non reparable est caracterisee par la loi de
probabilite de sa duree de bon fonctionnement X. Quand on sinteresse, dans une approche
bote blanche, a` un syst`eme complexe constitue de composants interconnectes, on va
chercher a` determiner la loi de X en fonction des lois des durees de bon fonctionnement
des composants elementaires. Dans une approche bote noire, on sinteressera directement
a` la loi de X, sans chercher a` decomposer le syst`eme en composants.
Il est donc capital davoir des mod`eles de base pour les lois des durees de bon fonctionnement de syst`emes non reparables simples. Dans ce chapitre, on presente les plus
utilisees de ces lois, essentiellement la loi exponentielle et la loi de Weibull. Pour chaque
loi, on donnera, quand cest possible, lexpression de la fiabilite, du taux de defaillance
et du MTTF. Dans tout ce chapitre, on supposera que les durees de bon fonctionnement
sont `a valeurs dans R+ , donc x sera implicitement suppose etre un reel positif.
3.2
Une variable aleatoire X est de loi exponentielle de param`etre > 0, notee exp(), si
et seulement si sa fonction de repartition est :
F (x) = 1 exp(x)
La fiabilite est R(x) = 1 F (x) do`
u:
R(x) = exp(x)
(3.1)
Z
R(x) dx =
exp(x) dx =
0
(3.2)
30
exp(x)
f (x)
=
=
R(x)
exp(x)
(3.3)
Le taux de defaillance est donc constant, ce qui signifie que la loi exponentielle modelise
les durees de vie de syst`emes qui ne susent pas et qui ne sameliorent pas.
On dit aussi que la loi exponentielle est sans m
emoire, ce quon exprime de la facon
suivante : si le syst`eme nest pas encore tombe en panne a` linstant t, cest comme sil
etait neuf `a cet instant. Mathematiquement, cela secrit :
x 0,
On a :
P(X > t + x | X > t) =
exp((t + x))
= exp(x) = P(X > x)
exp(t)
R(t + x)
= P(X > x) = R(x)
R(t)
Donc la propriete dabsence de memoire implique que R(t + x) = R(t)R(x) pour tout
x 0 et t 0. On en deduit que pour tout x 0 :
R(x + x) R(x)
R(x)R(x) R(x)
= lim
x0
x0
x
x
R(x) 1
= R(x) lim
= R(x) R0 (0)
x0
x
R0 (x) =
lim
Comme R est decroissante, R0 (0) est une constante strictement negative que lon note
, avec > 0. Ainsi, R est lunique solution de lequation differentielle R0 (x) = R(x)
avec comme condition initiale R(0) = 1. Autrement dit, on a R(x) = exp(x). Ainsi la
seule loi de probabilite `a densite continue verifiant la propriete dabsence de memoire est
la loi exponentielle. Dans le contexte de la fiabilite, cette absence de memoire sinterpr`ete
comme une absence de vieillissement et une absence de rajeunissement.
Dans la pratique, on dit souvent que lon peut modeliser par une loi exponentielle la
duree de vie de syst`emes qui sont dans leur periode de vie utile, cest-`a-dire qui, dans la
courbe en baignoire, ont depasse la periode de jeunesse et ne sont pas encore entres en
periode dusure. Mais cest une erreur methodologique car la loi de probabilite de X doit
pouvoir modeliser lensemble de la duree de vie du syst`eme.
31
Par consequent, la loi exponentielle ne devrait etre utilisee que pour des syst`emes
qui ne susent pas et ne sameliorent pas. Or tous les syst`emes materiels sont soumis a`
lusure, donc leur duree de vie devrait avoir a priori un taux de defaillance croissant, au
moins en fin de vie. Par contre, un logiciel ne suse pas. Tant quil nest pas modifie, sa
propension `a subir une defaillance reste constante. Aussi la loi exponentielle a-t-elle un
role preponderant en fiabilite des logiciels.
Remarque 1 : Le MTTF est exprime par une unite de temps, par exemple lheure. La
relation MTTF = 1/ implique donc quen pratique, on donne pour unite de linverse
dune unite de temps. Cela explique quun objectif de fiabilite soit souvent exprime en
terme de taux de panne par heure , comme dans lexemple de Meteor vu en section
1.6. : on sous-entend un taux de defaillance constant et on se fixe comme objectif par
rame < 109 h1 pour le materiel et < 1011 h1 pour le logiciel.
Remarque 2 : Si lon admet que la duree de vie dun syst`eme est de loi exponentielle, toute
maintenance preventive est inutile puisque le syst`eme est comme neuf `a chaque instant
tant quil nest pas tombe en panne.
Si la loi exponentielle est de loin la loi de duree de vie la plus utilisee en raison de
sa simplicite, elle ne permet de modeliser ni lusure, ni le rajeunissement. Il est donc
necessaire de disposer de lois plus sophistiquees. En fiabilite, la loi de Weibull est la plus
populaire dentre elles.
3.3
La fiabilite est :
R(x) = exp
x
(3.4)
La densite est :
f (x) = F (x) =
1
x
x
exp
R +
0
exp (x/) dx. Un changement de
MTTF =
1
+1
o`
u est la fonction gamma dEuler definie par :
Z +
(a) =
xa1 exp(x) dx
0
(3.5)
(3.6)
32
h(x) =
=
R(x)
1
x
(3.7)
Le taux de defaillance de la loi de Weibull est donc une puissance du temps, ce qui
permet de modeliser de nombreuses situations. En particulier :
si < 1, h est decroissant donc le syst`eme sameliore ;
si > 1, h est croissant donc le syst`eme suse ;
si = 1, h est constant et on retrouve la loi exponentielle comme cas particulier de
la loi de Weibull.
3.0
La figure 3.1 donne les graphes des taux de defaillance de la loi de Weibull pour
{0.5, 1, 1.5, 3}.
=3
2.0
2.5
= 0.5
1.5
= 1.5
0.0
0.5
1.0
=1
0.0
0.2
0.4
0.6
0.8
1.0
33
Demonstration.
1/
) = exp
x1/
= exp
do`
u le resultat.
Une propriete remarquable de la loi de Weibull est que cest lune des lois des valeurs
extremes : pour n variables aleatoires X1 , . . . , Xn independantes et de meme loi, la loi
limite de variables aleatoires secrivant an minni=1 Xi + bn quand on fait tendre n vers
linfini, est de trois types possibles. La seule dont le support soit R+ est la loi de Weibull.
Concr`etement, cela signifie que la loi de Weibull est un mod`ele naturel pour des syst`emes
constitues dun tr`es grand nombre de composants et dont la panne survient d`es quun
composant est defaillant (syst`eme serie, voir chapitre 4).
3.4
3.4.1
exp (x) x1
()
o`
u est la fonction gamma definie en (3.6).
La fonction de repartition de la loi gamma na pas dexpression explicite, donc la
fiabilite et le taux de defaillance non plus. En revanche, on dispose du MTTF et delements
qualitatifs sur le taux de defaillance :
La duree de vie moyenne est : MTTF =
n 1
,
2 2
n
P
Xi est
i=1
2.5
3.0
34
1.5
2.0
<1
0.5
1.0
=1
0.0
>1
0.0
0.2
0.4
0.6
0.8
1.0
3.4.2
1
f (x) =
exp 2 (ln x m)2
2
x 2
2
2
0.0
0.2
0.4
0.6
0.8
10
3.4.3
35
Il est etonnant de constater que, bien quil soit communement admis quen pratique
le taux de defaillance dun syst`eme non reparable a souvent une forme de baignoire, il
existe peu de lois de probabilite de durees de vie possedant cette propriete. Par exemple,
aucune des lois citees jusqu`a maintenant ne rentre dans ce cadre. La facon la plus simple
de construire un taux de defaillance en baignoire est de raccorder trois taux de type
Weibull respectivement decroissant, constant et croissant, en faisant en sorte que le taux
resultant soit continu et a` derivee continue. Par exemple, la figure 2.1 a ete obtenue a`
partir dun taux de la forme :
1 1
1
1
si x [0, 1 [
+
1
1
si x [1 , 2 ]
h(x) =
2 1
x 2
+ 2
si x ]2 , +[
2
2
Dans cette expression, la periode de vie utile est lintervalle [1 , 2 ]. Dautres lois de
probabilite poss`edent des taux de defaillance dont la forme se rapproche dune baignoire,
sans avoir pour autant une periode de vie utile aussi bien delimitee. Notons par exemple :
(x)1/1
1.0
1.5
2.0
10
2.5
12
3.0
14
10
16
20
40
60
80
100
0.0
0.2
0.4
0.6
0.8
0.0
0.2
0.4
0.6
0.8
1.0
36
Chapitre 4
Calculs de fiabilit
e par structure
4.1
Principes
Le principe des calculs de fiabilite par structure (ou architecture) est de considerer
quun syst`eme est constitue de composants elementaires, et que sa fiabilite depend a` la
fois de la fiabilite de ses composants et de la facon dont le bon fonctionnement ou la panne
de chaque composant influe sur le bon fonctionnement ou la panne du syst`eme tout entier.
Il est donc necessaire de representer la logique de fonctionnement du syst`eme.
Plusieurs types de representations sont possibles : diagrammes de fiabilite, arbres de
defaillance, graphes de Markov, reseaux de Petri, diagrammes de decision binaires, reseaux
bayesiens, etc... On ne sinteressera ici qu`a des syst`emes non reparables et on representera
leur fonctionnement par un diagramme de fiabilite.
Le diagramme de fiabilit
e dun syst`eme est un graphe sans circuit admettant une
entree E et une sortie S, dont :
les sommets, appeles blocs, representent les composants du syst`eme,
les arcs traduisent les relations entre les differents composants, au sens o`
u le syst`eme
fonctionne si et seulement si il existe un chemin allant de E a` S qui ne passe que
par des composants en fonctionnement.
On peut faire lanalogie avec un reseau de distribution deau : leau nest pas coupee
tant quil existe un chemin dans le reseau qui lui permet daller de son point dentree a`
son point de sortie.
Remarque : le diagramme de fiabilite est une representation logique du fonctionnement du
syst`eme, qui na rien `a voir avec une representation physique des liaisons entre les differents
composants. De meme, il ny a aucune contrainte de precedence dans ces diagrammes.
Exemple : une chane hi-fi comprend une platine CD (1), un tuner FM (2), un amplificateur
(3) et deux enceintes (4 et 5). Le fonctionnement normal de la chane implique que tous
ces elements fonctionnent. Le diagramme de fiabilite est alors donne dans la figure 4.1. En
effet, si un seul de ces elements ne fonctionne pas, la chane ne fonctionne pas correctement.
Mais on peut admettre un fonctionnement degrade dans lequel il est suffisant dentendre
au moins une des deux sources sonores sur au moins une des deux enceintes. Le diagramme
38
X = min Xi . Dans le deuxi`eme cas, cest moins evident mais on obtient que X =
i=1
Rx
0
hi (u) du .
4.2
Syst`
emes s
erie
D
efinition 10 Un syst`
eme s
erie est un syst`eme qui ne fonctionne que si tous ses composants fonctionnent.
Cest le cas de la chaine hi-fi en fonctionnement normal. Le diagramme de fiabilite est
4.2 Syst`
emes s
erie
39
!
[Xi > x]
i=1
Comme on a suppose les composants independants, la probabilite ci-dessus est la probabilite dune intersection dev`enements independants. Elle est donc egale au produit des
probabilites de ces ev`enements :
R(x) =
n
Y
n
Y
P(Xi > x) =
i=1
ri (x)
i=1
On a donc :
R(x) =
n
Y
Z
exp
n Z
X
hi (u) du = exp
i=1
hi (u) du
Z
= exp
i=1
Rx
n
X
!
hi (u) du
i=1
h(u) du , on en deduit que :
h(x) =
n
X
hi (x)
i=1
Z
exp
i=1
n
X
!
hi (u) du
dx
i=1
Si tous les composants ont un taux de defaillance constant, i, x, hi (x) =i , donc Xi
n
n
Q
P
est de loi exp(i ) et ri (x) = exp(i x). Alors R(x) =
exp(i x) = exp [ i ]x
et h(x) =
n
P
i=1
i=1
i=1
MT T F =
1
n
X
i=1
40
4.3
Syst`
emes parall`
eles
4.3.1
D
efinition et propri
et
es
D
efinition 11 Un syst`
eme parall`
ele est un syst`eme tel quil suffit quun seul de ses
composants fonctionne pour quil fonctionne.
Autrement dit, la defaillance du syst`eme survient quand tous ses composants sont en
panne.
Dans les syst`emes parall`eles, on distingue deux cas :
La redondance passive ou stand-by : un seul composant fonctionne a` la fois.
Quand le composant qui fonctionne tombe en panne, il est instantanement remplace
n
P
par un des composants en attente. Dans ce cas, X =
Xi . La proposition 2 montre
i=1
que si tous les composants sont independants et de meme loi exp(), la duree de vie
du syst`eme en redondance passive correspondant est de loi gamma G(n, ).
La redondance active : les n composants fonctionnent en meme temps.
On se place dans la suite de cette section dans le cas de la redondance active. Le
diagramme de fiabilite est donne dans la figure 4.3.
X = max Xi
i=1
i=1
i=1
4.3 Syst`
emes parall`
eles
41
n
Y
P(Xi x) = 1
i=1
do`
u finalement :
n
Y
i=1
n
Y
R(x) = 1 (1 ri (x))
i=1
Z
n
Y
En ecrivant R(x) = 1
1 exp
R0 (x)
, on obhi (u) du
puis h(x) =
R(x)
i=1
h(x) =
Z
hi (x) exp
0
i=1
Y
Z
hi (u) du
1 exp
hj (u) du
j6=i
n
Y
Z
1 exp
x
hi (u) du
i=1
Donc, contrairement au cas dun syst`eme serie, le taux de defaillance dun syst`eme
parall`ele ne sexprime pas facilement en fonction du taux de defaillance de ses composants.
Il ny a pas non plus dexpression simple du MTTF.
4.3.2
Cas o`
u tous les composants ont un taux de d
efaillance
constant
On a :
i, hi (x) = i .
R(x) = 1
n
Q
(1 exp(i x)).
i=1
n
X
h(x) =
i exp(i x)
i=1
(1 exp(j x))
j6=i
n
Y
(1 exp(i x))
i=1
n
X
i=1
exp(i x)
n X
X
exp((i + j )x) +
i=1 j6=i
. . . + (1)n+1 exp([
n
X
i=1
X
i,j,k distincts
i ]x)
exp((i + j + k )x)
42
+
. . . + (1)n+1 n
X
i + j i,j,k distincts i + j + k
i=1 i
i=1 j6=i
i=1
n
On montre que lim h(x) = min i . Cest logique : cest le composant le plus fiable qui
t+
i=1
4.3.3
Cas o`
u tous les composants sont identiques
4.3.4
Gain de fiabilit
e par les redondances
Le principe ci-dessus est valable a` plus grande echelle. En pratique, le moyen le plus
simple pour augmenter la s
urete de fonctionnement dun syst`eme est dajouter des redondances, cest-`a-dire de faire fonctionner plusieurs syst`emes identiques en parall`ele. Par
exemple, on met deux phares aux voitures au lieu dun. Evidemment, cela a un co
ut et
il faut donc trouver un compromis entre le co
ut des redondances et le gain de fiabilite
quelles entrainent. Pour cela, il faut quantifier ce gain de fiabilite.
Prenons lexemple dun composant de taux de defaillance constant . Admettons que
lon mesure sa fiabilite par le MTTF, qui vaut ici 1/. De combien la mise en parall`ele de
plusieurs composants identiques et independants va-t-elle augmenter le MTTF ?
Si on met en parall`ele n composants, la fiabilite du syst`eme est R(x) = 1[1r(x)]n =
1 [1 exp(x)]n .
R +
Donc le MTTF est M T T F = 0 [1 [1 exp(x)]n ] dx.
Le changement de variables u = 1 exp(x) permet decrire
Z n1
Z 1
n1 Z
1 1X k
1 X 1 k
1 un
du =
u du =
u du
MT T F =
0 k=0
k=0 0
0 (1 u)
1
n1
n1
1 X uk+1
1 X 1
1
1
1
=
=
=
1 + + ... +
k=0 k + 1 0 k=0 k + 1
2
n
1
Pour n = 1, on retrouve bien M T T F = . Pour n = 2, on obtient M T T F =
1
1
3
1+
=
. Donc mettre 2 composants au lieu dun (cas des phares) augmente
2
2
4.3 Syst`
emes parall`
eles
43
4.3.5
La redondance logicielle
Ce qui fait bien fonctionner la redondance pour les syst`emes materiels, cest lindependance entre les durees de bon fonctionnement des composants. Si on a deux composants
de durees de vie continues et independantes X1 et X2 , on a P(X1 = X2 ) = 0. Donc
quand un des composants tombe en panne, lautre fonctionne toujours et fait fonctionner
le syst`eme. Ainsi, si on a un probl`eme avec un phare, on peut toujours rouler en utilisant
le deuxi`eme. La probabilite que les deux phares tombent en panne en meme temps est
nulle (sauf si un ev`enement externe perturbe lensemble de la voiture, comme une panne
electrique generale ou un accident, qui provoque ce quon appelle une defaillance de cause
commune).
Si on veut appliquer le principe de la redondance aux logiciels, on ne va evidemment pas
faire fonctionner en parall`ele deux copies du meme logiciel, puisque leur fonctionnement
sera identique. Il faut faire developper deux programmes ayant les memes specifications
par deux equipes differentes. Si on fait fonctionner les deux programmes en meme temps
avec les memes donnees dentree, on peut esperer que quand lun aura une defaillance,
lautre fonctionnera correctement. Mais lexperience montre que ce nest pas aussi simple :
les deux equipes butent sur les memes difficultes et auront tendance a` faire des fautes aux
memes endroits. Apparemment, cest ce qui sest passe pour la panne geante du reseau
mobile de Bouygues Telecom en novembre 2004 : deux serveurs en parall`ele sont tombes
en panne en meme temps.
En conclusion, lindependance des durees de bon fonctionnement, valable pour la plupart des materiels, ne lest plus pour les logiciels. Donc la redondance logicielle est loin
detre aussi efficace que la redondance materielle. Il reste que la redondance logicielle augmente quand meme la fiabilite des logiciels, meme si on ne sait pas quantifier cette augmentation. Cest donc une methode souvent utilisee. Par exemple, Airbus utilise une redondance logicielle sur la chane de commande et surveillance des avions. A noter egalement
que la redondance logicielle est tr`es ch`ere puisquil faut deux equipes de developpeurs.
44
4.4
Syst`
emes k/n
D
efinition 12 Un syst`
eme k/n est un syst`eme qui ne fonctionne que si au moins k
composants parmi n fonctionnent.
Par exemple, le syst`eme de controle-commande de la temperature dun reacteur chimique ou nucleaire est concu selon une architecture 2/3.
k = 1 correspond a` un syst`eme parall`ele.
k = n correspond `a un syst`eme serie.
On ne peut pas representer ce mode de fonctionnement par un diagramme de fiabilite
usuel.
La fiabilite R(x) est la probabilite que k composants au moins parmi n fonctionnent
encore a` linstant x. Si on note Nx le nombre de composants qui fonctionnent a` linstant
x, on a :
R(x) = P(Nx k)
Dans le cas general, on ne peut rien dire de plus. Mais si on suppose que tous les
composants sont identiques et independants, de meme fiabilite r(x), alors la variable
aleatoire Nx est de loi binomiale B(n, r(x)), ce qui permet de calculer :
R(x) =
n
X
j=k
Pour k = n, on obtient R(x) = r(x)n . Cest bien la fiabilite dun syst`eme serie.
Pour k = 1, on obtient :
R(x) =
n
X
Cnj
nj
r(x) [1 r(x)]
j=1
n
n
X
j=0
n
4.5
Syst`
emes mixtes
Les syst`emes mixtes sont obtenus en combinant les syst`emes serie et les syst`emes
parall`eles.
4.5.1
Syst`
emes s
erie-parall`
ele
D
efinition 13 Un syst`
eme s
erie-parall`
ele resulte de la mise en parall`ele de soussyst`emes serie.
4.5 Syst`
emes mixtes
45
4.5.2
j=1
Syst`
emes parall`
ele-s
erie
D
efinition 14 Un syst`
eme parall`
ele-s
erie resulte de la mise en serie de sous-syst`emes
parall`eles.
Le diagramme de fiabilite est donne dans la figure 4.5.
j=1
46
4.6
La m
ethode de factorisation
De nombreux syst`emes ne sont pas des syst`emes serie, parall`eles, k/n ou mixtes. Cest
le cas du syst`eme dit en pont, dont le diagramme de fiabilite est donne dans la figure
4.6.
4.6 La m
ethode de factorisation
47
+
=
= 0.82
2 3 4 5
60
0
Le MTTF du syst`eme vaut donc 82 % du MTTF de ses composants.
Le taux de defaillance est :
h(x) =
On a lim h(x) = 2. Cela signifie quau bout dun moment, le syst`eme se comx+
porte comme deux composants en serie, qui est la configuration minimale avant la panne
definitive. La forme du taux de defaillance est donnee dans la figure 4.9.
48
Chapitre 5
Fiabilit
e dun logiciel non corrig
e : le
processus de Poisson homog`
ene
5.1
Rappels et d
efinitions
50
Chapitre 5 - Fiabilit
e dun logiciel non corrig
e : le processus de Poisson
homog`
ene
Nt
6
5
4
3
2
T0 T1
T2 T3
T4
-
--
-
X1 X2
X3
X4
T5
X5
5.2 Propri
et
es des processus de Poisson homog`
enes
51
5.2
5.2.1
Propri
et
es des processus de Poisson homog`
enes
Lois des dur
ees inter-d
efaillances
5.2.2
fTn (t) =
n
exp(t) tn1
(n 1)!
n
La duree moyenne dattente de la n`eme defaillance est donc E[Tn ] = .
5.2.3
Loi du nombre de d
efaillances survenues `
a chaque instant
Z
fTn (x)dx =
n
n
exp(x) xn1 dx =
In
(n 1)!
(n 1)!
52
Chapitre 5 - Fiabilit
e dun logiciel non corrig
e : le processus de Poisson
homog`
ene
Z
avec In =
In =
tn
exp(t) + In+1
n
n
Alors :
n
n
t
(t)n
n+1
P(Nt n) =
exp(t) + In+1 =
exp(t) +
In+1
(n 1)! n
n
n!
n!
(t)n
=
exp(t) + P(Nt n + 1)
n!
Do`
u:
P(Nt = n) = P(Nt n) P(Nt n + 1) =
(t)n
exp(t)
n!
(5.1)
ce qui prouve que Nt est de loi de Poisson P(t). Ce resultat classique a donne son nom
au processus de Poisson homog`ene.
On peut montrer en fait que le processus aleatoire {Nt }t0 est a` accroissements independants, cest a` dire que, pour 0 < s < t, Nt Ns est independant de ce qui sest passe
avant s, et que Nt Ns est de loi P((t s)).
La fonction moyenne donne le nombre moyen de defaillances survenues entre 0 et t :
m(t) = E[Nt ] = t
Elle est proportionnelle a` t, ce qui est logique puisque lintensite de defaillance est
constante.
5.2.4
Fiabilit
e
La fiabilite est :
Rt ( ; n, t1 , . . . , tn ) = P(Nt+ Nt = 0|Nt = n, T1 = t1 , . . . , Tn = tn )
La propriete daccroissements independants entrane que
Rt ( ; n, t1 , . . . , tn ) = P(Nt+ Nt = 0)
Et comme Nt+ Nt est de loi P((t + t)) = P( ), on a :
t 0, n 1, t1 . . . , tn t,
Rt ( ; n, t1 , . . . , tn ) = exp( )
5.2.5
53
MTTF
MTTFt (n; t1 , . . . , tn ) = E [Tn+1 t | Nt = n, T1 = t1 , . . . , Tn = tn ]
Z +
Z +
Rt ( ; n, t1 , . . . , tn ) d =
exp( ) d
=
0
1
=
Donc le MTTF est independant de linstant auquel on le calcule, pour les memes raisons
que precedemment. Par consequent, quel que soit linstant auquel on se place, la duree
1
moyenne dattente de la prochaine defaillance est .
Ce phenom`ene est parfois connu sous le nom de paradoxe du bus : si les instants de
passage des bus `a un arret se font selon un HPP dintensite , alors la duree moyenne
dattente du bus pour un passager arrivant a` cet arret sera la meme, quel que soit le temps
ecoule depuis le passage du bus precedent. Bien s
ur, dans la pratique, les passages des
bus ne se font pas selon un HPP.
5.3
Estimation de la fiabilit
e
Les resultats probabilistes ci-dessus permettent de calculer toutes les mesures interessantes de fiabilite des logiciels. Elles sexpriment toutes `a laide du param`etre inconnu
. Pour avoir une evaluation de ces mesures, il faut donner une valeur a` , cest-`a-dire
estimer ce param`etre.
Pour cela, on se place a` linstant de la n`eme defaillance tn et on va estimer au vu de
la suite des durees inter-defaillances successives x1 , . . . , xn par la methode du maximum
de vraisemblance.
La fonction de vraisemblance associee `a lobservation de variables aleatoires X1 , . . . Xn
independantes et de meme loi est :
L(; x1 , . . . , xn ) = f(X1 ,...,Xn ) (x1 , . . . , xn ) =
n
Y
fXi (xi )
i=1
n
Y
exp(xi ) = exp(
i=1
n
X
xi )
i=1
n
X
xi
i=1
n X
ln L(; x1 , . . . , xn ) =
xi
i=1
54
Chapitre 5 - Fiabilit
e dun logiciel non corrig
e : le processus de Poisson
homog`
ene
Lestimateur de maximum de vraisemblance de est donc :
n =
n
n
X
Xi
n
1
=
Tn
Xn
i=1
Remarquons que, puisque la duree moyenne entre deux defaillances successives est
E[Xi ] = 1/, il semble naturel destimer par linverse de la moyenne des durees interdefaillances observees. Cest le principe de la methode destimation des moments.
Comme dans toute etude statistique, il faut se poser la question de la qualite de cet
estimateur : est-il sans biais, convergent, efficace ?
n est sans biais si et seulement si E(
n ) = . Or :
Z
Z +
n
1
n
n
n) = E
=
fTn (u) du = n
exp(u) un1 du
E(
Tn
u
u
(n
1)!
0
Z +
Z +
n1
n
n
n2
exp(u) u
du =
fTn1 (u) du
=
n1 0
(n 2)!
n1 0
n
=
n1
n ) 6= , donc
n est biaise. Mais
E(
n1
n1
0 n =
n =
n
Tn
(5.2)
R n ( ) = exp( n ).
Le M T T F =
1
Tn
1
Tn
1
=
=
peut etre estime par
= X n ou par
.
n
n
n1
0 n
Mais ce nest pas parce que 0 n est lestimateur optimal de que exp(0 n ) sera
1
1
lestimateur optimal de exp( ) ni que
sera lestimateur optimal de . En fait, on
0
n
montre que :
n1
55
1
1
est M\
TTFn =
= X n.
Remarque : quand il ny a pas de correction, la fiabilite est stable donc ca na aucun sens
de faire des calculs du type temps de test necessaire pour atteindre un objectif fixe de
fiabilite.
5.4
n1
= 3.256 103 .
0 n =
tn
tn
M\
TTFn =
= 294.3, donc on prevoit une duree moyenne dattente entre defaillances
n
de 294.3 h.
23
100
5.5
56
Chapitre 5 - Fiabilit
e dun logiciel non corrig
e : le processus de Poisson
homog`
ene
< 0 .
5.5.1
Validation en pr
esence de d
efaillances
Un test est determine par sa region critique, ensemble des valeurs des observations
pour lesquelles on rejettera H0 au profit de H1 . Le seuil du test est la probabilite
maximale de rejeter a` tort H0 . Ici, il est naturel de conclure que < 0 si 0 n est
significativement
inferieur a` 0 . On propose donc une region critique de la forme W =
n
o
0
n < l . Autrement dit, si lintensite estimee est suffisamment petite, on va conclure
que lobjectif de fiabilite est atteint, avec une faible probabilite de se tromper.
La valeur de l est determinee en ecrivant que le seuil du test est la probabilite
maximale de rejeter H0 alors que H0 est vraie :
= sup P(0 n < l ) = sup P
H0
n1
< l
Tn
n1
= sup P Tn >
l
0
Tn est de loi gamma G(n, ), qui est peu maniable. On pref`ere utiliser la loi du chi-deux,
que lon obtient facilement en ecrivant que :
2Tn ; G n,
2
1
2n 1
,
= G n,
=G
= 22n
2
2 2
n1
= sup P 2Tn > 2
l
0
n1
= sup 1 F22n 2
l
0
(5.3)
Une fonction de repartition est croissante, donc le terme entre crochets est une fonction
decroissante de . Son maximum pour 0 est donc atteint en = 0 . Par consequent :
20 (n 1)
n1
n1
= 1 F22n 20
= 20
= F1
2 (1 ) = l =
2n
l
l
F1
2 (1 )
(5.4)
2n
20 (n 1)
0 n < 1
F2 (1 )
)
(5.5)
2n
est une probabilite derreur, que lon se fixe. Prenons par exemple = 5%. Dans
lexemple, n = 24. La table de la loi du 2 permet detablir que F1
u
2 (0.95) 65.2, do`
48
n
o
W = 0 n < 0.71 0 .
On pourra donc conclure avec moins de 5% de chances de se tromper que < 0 si
0 n < 0.71 0 , cest-`a-dire si lintensite de defaillance estimee est a` peu pr`es inferieure aux
trois quarts de lintensite de defaillance objectif.
5.5.2
57
Validation en labsence de d
efaillances
ln
= ln M T T F0
0
1
est le MTTF objectif. Alors la region critique est
0
W = {T1 > ln M T T F0 }
58
Chapitre 5 - Fiabilit
e dun logiciel non corrig
e : le processus de Poisson
homog`
ene
Chapitre 6
Les mod`
eles `
a dur
ees
inter-d
efaillances exponentielles
(ETBF)
6.1
D
efinition et propri
et
es
1
2
4
3
T1
T2
T3
T4
6.1.1
La loi de Tn =
n
P
i=1
lois exponentielles. Si les i sont tous distincts, on montre que cette variable aleatoire est
de loi hypoexponentielle, definie par sa densite :
n
Y
j
n
X
j=1
exp(i t)
(6.1)
fTn (t) =
n
Y
i=1
(j i )
j=1
j6=i
n
P
E(Xi ) =
i=1
6.1.2
n 1
P
.
i=1 i
Loi du nombre de d
efaillances survenues `
a chaque instant
Ce nest pas une loi de probabilite usuelle et son esperance na pas dexpression simple.
6.1.3
Fiabilit
e et MTTF
(6.3)
6.2 Le mod`
ele de Jelinski-Moranda
M T T Ft (n, t1 , . . . , tn ) =
6.1.4
61
1
(6.4)
n+1
Fonction de vraisemblance
Dans la mesure o`
u les Xi sont independantes et de lois exponentielles, pour un mod`ele
ayant pour param`etre , la fonction de vraisemblance associee `a lobservation de x1 , . . . , xn
est :
" n #
!
n
n
n
Y
Y
Y
X
L(; x1 , . . . , xn ) =
fXi (xi ) =
i exp(i xi ) =
i exp
i xi
(6.5)
i=1
i=1
i=1
i=1
Pour aller plus loin, il faut faire des hypoth`eses sur la forme de i . On va voir dans
la suite de ce chapitre les deux plus connus des mod`eles ETBF, le mod`ele de JelinskiMoranda et le mod`ele geometrique de Moranda.
6.2
Le mod`
ele de Jelinski-Moranda
Le mod`ele de Jelinski-Moranda [9] est historiquement tr`es important car cest le tout
premier mod`ele de fiabilite des logiciels, propose en 1972. Il repose sur les hypoth`eses
suivantes :
x 10
Intensit de dfaillance
4.5
4
3.5
3
2.5
2
1000
2000
3000
4000
5000
(6.6)
1
.
(N n)
6.2 Le mod`
ele de Jelinski-Moranda
63
"
= n
i=1
n
Y
(N i + 1) exp
i=1
n
X
!
(N i + 1)xi
i=1
n
X
n
X
ln(N i + 1)
(N i + 1)xi
i=1
(6.8)
i=1
do`
u:
n X
ln L(N, ; x1 , . . . , xn ) =
(N i + 1)xi
i=1
(6.9)
n et n ,
On en deduit que les estimateurs de maximum de vraisemblance de N et , N
sont lies par la relation :
n
n = n
(6.10)
X
n i + 1)Xi
(N
i=1
Par ailleurs :
X
X
1
ln L(N, ; x1 , . . . , xn ) =
xi
N
N i+1
i=1
i=1
(6.11)
n
1
n
N i+1 X
n
X
Xi
i=1
=0
(6.12)
(N i + 1)Xi
i=1
6.3
Le mod`
ele g
eom
etrique de Moranda
Le principal defaut du mod`ele JM est que les fautes sont supposees avoir toutes le
meme taux de manifestation, ce qui se traduit par le fait que la decroissance de lintensite
est toujours la meme `a chaque correction. En fait, les fautes ont des severites differentes.
Les fautes les plus graves ont tendance a` se produire tr`es tot, et leur correction va grandement diminuer lintensite de defaillance. Lamelioration due aux corrections doit donc
logiquement etre forte au debut de la periode dobservation, puis de plus en plus faible.
Cest le phenom`ene bien connu de perte dimpact des corrections au cours du temps.
Une facon de modeliser ce phenom`ene dans les mod`eles ETBF est de faire en sorte
que les taux de defaillance successifs decroissent de mani`ere geometrique et non plus
arithmetique comme dans le mod`ele JM. On avait dans le mod`ele JM i = i1 . Pour
obtenir une decroissance geometrique, il suffit de poser i = ci1 .
La croissance de fiabilite se traduira par c < 1. Remarquons que ce mod`ele pourrait
etre un mod`ele de decroissance de fiabilite en prenant c > 1, et quon retouve le processus
de Poisson homog`ene (i = i) pour c = 1.
Alors i = ci1 = c2 i2 = . . . = ci1 1 . On pose 1 = et on obtient le mod`ele
propose par Moranda [14] sous le nom de geometric de-eutrophication model.
D
efinition 18 Le mod`
ele g
eom
etrique de Moranda (GM) est defini de mani`ere
equivalente par :
t (n; t1 , . . . , tn ) = cn , R+ , c ]0, 1].
Les Xi sont independantes et de lois respectives exp ( ci1 ).
sinterpr`ete comme lintensite de defaillance initiale et c represente la qualite de la
correction : plus c est petit, meilleure est la correction. c = 1 correspond a` labsence de
correction.
La perte defficacite des corrections au cours du temps se visualise sur lintensite du
mod`ele GM (figure 6.3) par des sauts entre les paliers qui diminuent geometriquement.
6.3 Le mod`
ele g
eom
etrique de Moranda
65
10
x 10
Intensit de dfaillance
9
8
7
6
5
4
3
2
1
1000
2000
3000
1
cn
= n c
i=1
Pn
i=1 (i1)
exp
i=1
n
X
i=1
!
ci1 xi
= n c
n(n1)
2
exp
i=1
n
X
!
ci1 xi
i=1
n
ln L(, c; x1 , . . . , xn ) = n ln +
X
n(n 1)
ln c
ci1 xi
2
i=1
n X i1
ln L(, c; x1 , . . . , xn ) =
c xi
i=1
n =
do`
u
n
n
X
(6.13)
(6.14)
ci1
n Xi
i=1
n
n(n 1)
ln L(, c; x1 , . . . , xn ) =
(i 1)ci2 xi
c
2c
i=1
(6.15)
(6.16)
Rtn (100) = 85.1%. Ces valeurs sont proches de celles obtenues pour le mod`ele JM.
Chapitre 7
Les processus de Poisson non
homog`
enes (NHPP)
7.1
D
efinition et propri
et
es
D
efinition 19 Les processus de Poisson non homog`
enes (NHPP pour Non Homogeneous Poisson Processes) sont les mod`eles de fiabilite des syst`emes reparables pour
lesquels lintensite de defaillances ne depend que du temps :
t (n; t1 , . . . , tn ) = (t)
(7.1)
0.90
0.85
lambda_t
0.95
On supposera que (t) est continue. Cela signifie quapr`es la correction, lintensite de
defaillance est la meme quavant la defaillance (voir figure 7.1).
1000
2000
3000
4000
5000
6000
7000
68
7.1.1
Loi du nombre de d
efaillances survenues `
a chaque instant
Rt
0
(u)du.
Ce resultat a donne son nom au processus de Poisson. Le processus est homog`ene quand
(t) est une fonction constante et non homog`ene sinon. On retrouve bien le resultat du
HPP en prenant (t) = : Nt est de loi P(t).
Comme pour le HPP, on peut montrer en fait que le processus aleatoire {Nt }t0 est a`
accroissements independants, cest a` dire que, pour 0 < s < t, Nt Ns est independant
de ce qui sest passe avant s, et que Nt Ns est de loi P(m(t) m(s)).
Le nombre moyen de defaillances survenues entre 0 et t est E[Nt ] = m(t), donc
d
E[Nt ] = m0 (t) = (t). Par consequent, lintensite de defaillance dun NHPP peut sindt
terpreter comme un taux moyen doccurrence de defaillances.
d
E[Nt ] = N exp(t). Par consequent, le
dt
NHPP dintensite (t) = N exp(t) (mod`ele GO, voir plus loin) peut etre considere
comme une approximation du mod`ele JM au sens o`
u une fonction continue est une approximation dune fonction en escalier. On peut donc sattendre en particulier a` ce que
les deux mod`eles donnent des estimations de fiabilite du meme ordre.
7.1 D
efinition et propri
et
es
69
De la meme facon, on peut approcher nimporte quel mod`ele ETBF par un NHPP.
Linteret est que le NHPP est beaucoup plus facile a` utiliser que le mod`ele ETBF correspondant.
7.1.2
(7.2)
Do`
u hXn+1 |Tn =tn (x) = (tn + x), ce qui signifie que le taux de defaillance de la loi
conditionnelle de Xn+1 sachant [Tn = tn ] est (tn + x). Tout se passe donc comme si le
syst`eme avait un taux de defaillance initial (t) et que les corrections navaient aucun
effet. On retrouve ici lidee de reparation minimale.
Dapr`es (2.5), ce resultat peut secrire aussi :
Z x
(tn + u)du
fXn+1 |Tn =tn (x) = (tn + x) exp
0
Z tn +x
= (tn + x) exp
(u)du
(7.3)
tn
ou :
P(Xn+1
Z
> x| Tn = tn ) = exp
tn +x
(u)du
(7.4)
tn
On remarque que, contrairement au cas des mod`eles ETBF, les durees inter-defaillances
Xi ne sont pas independantes.
En utilisant les resultats precedents, on montre facilement que la loi conditionnelle de
Tn+1 sachant [Tn = tn ] est donnee par :
Z t
fTn+1 |Tn =tn (t) = (t) exp
(u)du
(7.5)
tn
Z t
P(Tn+1 > t| Tn = tn ) = exp
(u)du
(7.6)
tn
7.1.3
Fiabilit
e et MTTF
t+
u (n; t1 , . . . , tn ) du
70
7.1.4
Fonction de vraisemblance
n
Y
i=1
"
n
Y
n
Y
i=1
n
Y
(ti )
Z
exp
i=1
ti
(ti ) exp
(u) du
ti1
i=1
tn
(u) du
(7.8)
Cette fonction est tr`es simple, ce qui permettra destimer tr`es simplement les param`etres des mod`eles NHPP. Cest en grande partie ce qui a fait leur succ`es aupr`es des
praticiens, malgre le fait quils soient moins realistes que les mod`eles ETBF.
Pour aller plus loin, il faut faire des hypoth`eses sur la forme de (t). On va voir dans
la suite de ce chapitre les deux plus connus des mod`eles NHPP, le mod`ele de Duane et le
mod`ele de Goel-Okumoto.
7.2
Le mod`
ele de Duane
Cest le plus connu et le plus utilise des NHPP. Il porte le nom de Duane [5] qui a
observe empiriquement que ce mod`ele etait bien adapte a` des materiels electriques, et il a
ete etudie par Crow [4]. Il est connu en anglais sous le nom de Power-Law Process (PLP).
D
efinition 20 Le mod`
ele de Duane ou Power-Law Process (PLP) est le NHPP
dont lintensite est une puissance du temps :
(t) = t1 , R+ , R+
(7.9)
71
3.0
7.2 Le mod`
ele de Duane
=3
2.0
2.5
= 0.5
1.5
= 1.5
0.0
0.5
1.0
=1
0.0
0.2
0.4
0.6
0.8
1.0
" i=1
n
Y
(7.10)
#
t1
i
"
exp(tn ) = n n
i=1
n
Y
#
t1
i
exp(tn )
i=1
ln L(, ; t1 , . . . , tn ) = n ln + n ln + ( 1)
n
X
ln ti tn
(7.11)
i=1
n
n
ln L
= tn , qui vaut 0 pour = .
tn
n
ln L
n X
= +
ln ti tn ln tn
i=1
En annulant cette quantite et en remplacant par
n
n
tn
(7.12)
, on obtient :
n X
n X ti
+
ln ti n ln tn = +
ln = 0
tn
i=1
i=1
n
= =
n
X
i=1
ti
ln
tn
n
n1
X
i=1
tn
ln
ti
(7.13)
(7.14)
72
n =
(7.15)
X Tn
Tnn
ln
Ti
i=1
Le fait que ces estimateurs aient une forme explicite est tr`es rare en fiabilite des logiciels
et explique en grande partie la popularite de ce mod`ele.
En remplacant et par
n et n dans les expressions de Rt ( ) et M T T Ft , on peut
estimer la fiabilite et le MTTF `a nimporte quel instant.
Pour les donnees de lexemple, on obtient
n = 0.100 et n = 0.618. Une valeur
inferieure a` 1 pour n confirme la croissance de fiabilite.
Les estimations de MTTF et de fiabilite a` 100 heures sont M\
T T F tn = 487.7 h et
Rtn (100) = 81.2%. Ces valeurs sont intermediaires entre celles obtenues pour les mod`eles
JM/GM et celles obtenues sous lhypoth`ese HPP.
Etant donne que le HPP est un cas particulier du mod`ele de Duane, si ce mod`ele avait
ete adapte aux donnees, lestimation de aurait ete proche de 1. Comme ce nest pas le
cas, cela signifie que, conformement `a lintuition, le HPP nest pas un bon mod`ele pour
ces donnees. Mathematiquement, traiter ce probl`eme cest tester H0 : = 1 contre H1 :
6= 1 quand on suppose que le mod`ele de Duane est adequat.
Il reste a` determiner si on peut considerer que les donnees proviennent du mod`ele de
Duane. Pour cela, il faut utiliser des tests dadequation a` ce mod`ele. Il en existe, mais
leur etude depasse le cadre de ce cours.
7.3
Le mod`
ele de Goel-Okumoto
7.3 Le mod`
ele de Goel-Okumoto
73
(7.17)
(7.18)
Do`
u:
g 0 (t)
= b = ln g(t) = bt + cste = g(t) = exp(bt + cste) = K exp(bt)
g(t)
(7.19)
(7.20)
(7.21)
Lintensite decroit donc comme une exponentielle alors que pour le PLP, elle decroit
comme une puissance. A priori, par construction du mod`ele, b est un reel positif. On
pourrait autoriser b a` etre negatif pour pouvoir modeliser une decroissance de fiabilite,
mais il faudrait alors reecrire le mod`ele, par exemple sous la forme (t) = exp(ct)
avec c R.
Comme on la dit plus haut, lintensite du mod`ele GO a la meme forme que le taux
doccurrence de defaillance du mod`ele JM, donc le mod`ele GO est lequivalent NHPP du
mod`ele JM.
Remarque : lim E[Nt ] = lim m(t) = a. Cela signifie que le nombre maximal de defaillant+
t+
ces observables si on poursuit indefiniment le test est a. Cest normal puisque a est
le nombre moyen de fautes initiales et quon elimine une et une seule faute a` chaque
defaillance. On nobservera donc quun nombre fini de defaillances et le logiciel sera parfait en moyenne apr`es la a`eme correction. Cest le meme phenom`ene que pour le mod`ele
JM, avec les memes defauts.
La fiabilite est :
Rt ( ) = exp([m(t + ) m(t)]) = exp (a exp(bt)[1 exp(b )])
74
Rt ( )d =
M T T Ft =
(7.22)
" i=1
n
Y
#
ab exp(bti )
i=1
= an bn exp(b
n
X
(7.23)
i=1
ln L(a, b; t1 , . . . , tn ) = n ln a + n ln b b
n
X
ti a[1 exp(btn )]
(7.24)
i=1
n
n
ln L
= 1 + exp(btn ), qui vaut 0 pour a =
.
a
a
1 exp(btn )
n
n X
ln L
=
ti atn exp(btn )
b
b
i=1
(7.25)
On en deduit que :
Proposition 7 Les estimateurs de maximum de vraisemblance des param`etres du mod`ele
de Goel-Okumoto sont tels que bn est solution de lequation implicite :
n
n X
nTn exp(bn Tn )
Ti
=0
bn
1 exp(bn Tn )
i=1
et
a
n =
n
1 exp(bn Tn )
(7.26)
(7.27)
75
7.4
7.4.1
Autres mod`
eles NHPP
Le mod`
ele de Musa-Okumoto
Cest le mod`ele NHPP derive du mod`ele geometrique de Moranda. Son intensite [15]
est :
, R+ , R+
(7.28)
(t) =
1 + t
n = 7.03 103 et n = 0.0547. Lestimation
Pour les donnees de lexemple, on obtient
tn (100) = 82.8% et celle du MTTF est M\
T T F tn = 559 h.
de fiabilite a` 100 heures est R
7.4.2
Le mod`
ele de Yamada-Ohba-Osaki
Les mod`eles precedents ont tous une intensite strictement monotone, croissante ou
decroissante. Or, dans la pratique, on a souvent constate que les defaillances etaient
espacees au debut de la periode dobservation, puis de plus en plus rapprochees, pour
finir par sespacer `a nouveau. Ce phenom`ene peut sexpliquer en phase de test par le
fait que les testeurs qui decouvrent un logiciel ne trouvent pas de defaillances tout de
suite. Puis, a` mesure que leur connaissance du logiciel sapprofondit, ils parviennent `a
localiser les fautes potentielles. Enfin, quand la majeure partie des fautes a ete eliminee,
les defaillances deviennent rares du fait de lefficacite de la correction et du faible potentiel
dactivation des fautes residuelles.
Mathematiquement, cela revient `a supposer que lintensite de defaillance commence
par crotre, puis decrot, do`
u le nom de mod`eles en forme de S (S-shaped models).
Le mod`ele de Yamada-Ohba-Osaki (YOO) [21] est de ce type avec :
(t) = a b2 t exp(bt) a R+ , b R+
(7.29)
fiabilite `a 100 heures est Rtn (100) = 89.5% et le MTTF est infini, comme pour le mod`ele
GO.
Il existe de nombreuses variantes de ces mod`eles, pouvant prendre en compte quantites
de param`etres comme la correction imparfaite, la correction differee, la dependance entre
les fautes, des param`etres environnementaux, une decomposition modulaire du logiciel,
une classification des types de defaillances, le co
ut du test et de la correction, lexistence
de ruptures, etc... [16].
0.015
0.000
0.005
0.010
lambda_t
0.020
0.025
0.030
76
20
40
60
80
100
7.5
Conclusion
Bibliographie
[1] Bon J.L., Fiabilite des syst`emes, Masson, 1995.
[2] Norme
CEI
61508,
Securite
fonctionnelle
des
syst`emes
electriques/electroniques/electroniques programmables relatifs `a la securite,
Commission Electrotechnique
Internationale, 2001.
[3] Cocozza-Thivent C., Processus stochastiques et fiabilite des syst`emes, Springer,
1997.
[4] Crow L.H., Reliability analysis for complex repairable systems, in Reliability and
biometry - Statistical analysis of lifelength, SIAM Philadelphia, 379-410, 1974.
[5] Duane J.T., Learning curve approach to reliability monitoring, IEEE Transactions
on Aerospace, AS-2, 2, 563-566, 1964.
[6] Gaudoin O. et Ledoux J., Modelisation aleatoire en fiabilite des logiciels, Herm`es
Science Publications, 2007.
[7] Goel A.L. et Okumoto K., Time dependent error detection rate model for software reliability and other performance measures, IEEE Transactions on Reliability,
R-28, 1, 206-211, 1979.
[8] Habrias H., La mesure du logiciel, Teknea, 1994.
[9] Jelinski Z. et Moranda P.B., Statistical computer performance evaluation, in
Software reliability research, 465-497, W. Freiberger ed, Academic press, New-York,
1972.
[10] Laprie J.C. ed., Dependability : basic concepts and terminology, Springer, 1992.
[11] Laprie J.C. ed., Guide de la s
urete de fonctionnement, Cepadu`es, 1996.
[12] Lawless J.F., Statistical models and methods for lifetime data, Wiley, 2003.
[13] Lyu M.R. ed., Handbook of software reliability engineering, IEEE Computer Society Press and Mc Graw-Hill Book Company, 1996.
[14] Moranda P.B., Event altered rate models for general reliability analysis, IEEE
Transactions on Reliability, R-28, 5, 376-381, 1979.
[15] Musa J.D. et Okumoto K., A logarithmic Poisson execution time model for
software reliability measurement, Proc. 7th Int. Conf. on Software Engineering,
230-238, 1984.
[16] Pham H., Software reliability, Springer, 2000.
[17] Printz J., Productivite des programmeurs, Herm`es-Lavoisier, 2001.
[18] Rausand M. and Hoyland A., System reliability theory : models, statistical
methods and applications, Wiley, 2004.
78
BIBLIOGRAPHIE