cole Doctorale de Grenoble Master 2 Recherche Systmes et Logiciel

Plan
Les horaires sont indicatifs

! Introduction la tolrance aux fautes (1h30)

Tolrance aux fautes - 1

Introduction, techniques de base

" Objectifs, dfinition, problmes " Principales mthodes " Exemples dapplication

! Techniques usuelles de la tolrance aux fautes

" Ralisation de serveurs a haute disponibilit (1h30) Sacha Krakowiak
Universit Joseph Fourier Projet Sardes (INRIA et IMAG-LSR) http://sardes.inrialpes.fr/people/krakowia

" Validation atomique (1h30)

! Algorithmique de la tolrance aux fautes

" Consensus et problmes connexes (2 x 1h30) " Cohrence, diffusion (1h30) " Complments divers (si le temps le permet)

2003-2004, S. Krakowiak

Dfinitions de base
! Service
" Ensemble de fonctions dfini par une interface, contrat entre le fournisseur et lutilisateur du service.

Srt de fonctionnement (dependability)

" Proprit dun systme informatique permettant ses utilisateurs de placer une confiance justifie dans le service que dlivre le systme

Diffrents aspects
interface utilisateur
(une personne, un systme, un composant dun systme)
spcifications

fournisseur
(un systme informatique, un composant logiciel ou matriel dun tel systme)

domaine de la tolrance aux fautes

Proprits attendues dun service Proprits fonctionnelles (dfinies dans les spcifications dinterface) validit (correctness) : le systme est conforme ses spcifications proprits de sret et de vivacit Proprits non fonctionnelles (les autres) performances ; sret de fonctionnement La distinction nest pas toujours vidente

Fiabilit (reliability)!: le systme est en tat (continu) de rendre le service Mesure : probabilit (fonction du temps t) que le systme ne soit pas dfaillant entre le temps 0 et le temps t Disponibilit (availability) : le service est disponible en permanence Mesure : fraction du temps (sur une priode dtermine) durant laquelle le systme fournit le service Scurit (au sens safety) : un mauvais fonctionnement du systme na pas dincidence catastrophique sur son environnement Il faut dfinir catastrophique et environnement Scurit (au sens security) : le systme assure la confidentialit et lintgrit des informations ainsi que le contrle de laccs au service le service est effectivement accessible aux utilisateurs autoriss, non aux autres
4

2003-2004, S. Krakowiak

2003-2004, S. Krakowiak

Sret de fonctionnement
! Dfinition ! Il ny a pas de critre absolu
" Limportance relative des critres dpend # de la nature de lapplication # des exigences des utilisateurs # des conditions dutilisation (environnement, etc.)

Dfaillances

" Un systme (ou composant) est sujet une dfaillance (failure) lorsque son comportement nest pas conforme sa spcification # Synonyme de dfaillance : panne

! Remarques
" Le systme ou composant est considr comme une bote noire!; on ne regarde que son comportement global, observ linterface " On peut dfinir diffrents degrs de gravit de dfaillance en fonction de leur impact sur la sret de fonctionnement (cf plus loin)
interface

! Exemples
" Systme embarqu : fiabilit, disponibilit " Systme de communication (ex : commutateur tlphonique) : disponibilit " Service de fichiers, base de donnes : disponibilit, scurit (security) " Systme de transport (exemple : navigation, guidage, freinage) : scurit (safety), disponibilit

contrat
2003-2004, S. Krakowiak 5 2003-2004, S. Krakowiak 6

Degr de gravit des dfaillances (1)

Degr de gravit des dfaillances (2)

interface

! Modle
" bote noire, messages entrants et sortants

! Pannes de temporisation
" Les dviations par rapport aux spcifications concernent uniquement le temps (par exemple temps de raction un vnement)

! Panne franche
" Dit aussi : arrt sur dfaillance (fail stop) # ou bien le systme fonctionne, et donne un rsultat correct # ou bien il est en panne (dfaillant), et ne fait rien " Cest le cas le plus simple, et on essaie de sy ramener (au besoin en forant larrt dun composant ds quune erreur y a t dtecte : technique fail fast)

! Pannes arbitraires (ou byzantines)

" Le systme peut faire nimporte quoi (y compris avoir un comportement malveillant) " Intrt thorique : conditions les plus dfavorables " Hypothse parfois ncessaire pour des systmes trs haute fiabilit dans un environnement hostile (nuclaire, spatial) " Traitable, mais ncessite une redondance leve (typiquement 3k+1 exemplaires dun composant pour rsister k dfaillances)

! Panne par omission

" Le systme perd des messages entrants (omission en rception), sortants (omission en mission), ou les deux. Il ny a pas dautres dviations par rapport aux spcifications " Ce modle peut servir reprsenter des dfaillances du rseau " Plus difficile traiter que la panne franche

2003-2004, S. Krakowiak

2003-2004, S. Krakowiak

Mesures de fiabilit et disponibilit (1)

Mesures de fiabilit et disponibilit (2)

On utilise aussi MTBF (Mean Time Between Failures)
MTTF MTTR

Mesure de la fiabilit
Probabilit R(t) que le systme ne soit pas dfaillant entre 0 et t Temps moyen jusqu la prochaine panne : E(R(t)) = MTTF (Mean Time To Failure) E = esprance mathmatique

dfaillance
MTBF

rparation

Mesure de la disponibilit
Disponibilit instantane : Probabilit A(t) que le systme soit disponible (fournisse un service correct) linstant t Disponibilit moyenne a = E(A(t)) : fraction moyenne du temps o le systme est disponible (sur une priode donne) Mesure de la disponibilit Dans le cas de pannes franches : disponibilit = a = MTTF/(MTTF + MTTR) Mesure en nombre de 9 : 99.99% 99.999% (4 nines) (5 nines) indisponible 50 minutes/an indisponible 5 minutes/an

Rparation
Rparer un systme en panne : le remettre en tat de rendre un service correct Mesure : temps moyen de rparation : MTTR (Mean Time To Repair)
2003-2004, S. Krakowiak 9

Indisponibilit = 1 disponibilit = MTTR/(MTTF + MTTR) ! MTTR/MTTF, car en gnral MTTR << MTTF Donc diviser MTTR par 2 a le mme effet sur la disponibilt que doubler MTTF
2003-2004, S. Krakowiak 10

Mesures de fiabilit et disponibilit (3)

Bien comprendre la diffrence entre fiabilit (mesure par MTTF) et disponibilit (mesure par a = MTTF / (MTTF + MTTR)) Systme fiable, peu disponible
MTTF MTTR MTTF grand, a petit

Analyse des dfaillances (1)

! Principe
" On sintresse lorigine dune dfaillance (donc on doit ouvrir la bote noire que constitue le systme)

! Dfinitions
" Erreur : tat (ou partie de ltat) du systme susceptible de provoquer une dfaillance (partie de ltat interne dont les proprits courantes ne sont pas conformes aux spcifications) # exemple logiciel : la valeur dune table ne vrifie pas un invariant spcifi # exemple matriel : une connexion est coupe entre deux points qui devraient tre relis entre eux " Faute : toute cause (vnement, action, circonstance) pouvant provoquer une erreur # exemple : faute de programmation, malveillance, catastrophe naturelle, etc.

Systme disponible, peu fiable

MTTF petit, a grand

2003-2004, S. Krakowiak

11

2003-2004, S. Krakowiak

12

Analyse des dfaillances (2)

Analyse des dfaillances (3)

! Propagation entre composants (ou sous-systmes) ! De lerreur la dfaillance

" Une erreur est susceptible de provoquer une dfaillance, mais ne la provoque pas ncessairement (ou pas immdiatement) # parcequil y a une redondance interne suffisante pour que le systme continue de fournir le service # parceque la partie errone de ltat nest pas utilise pour telle ou telle fonction " Une erreur est latente tant quelle na pas provoqu de dfaillance " Le temps entre lapparition de ltat derreur et la dfaillance est le dlai de latence # plus le dlai de latence est long, plus la recherche des causes dune dfaillance est difficile " Un composant A utilise un composant B si le bon fonctionnement de A dpend de celui de B

erreur utilisateur dfaillance de A faute A

dfaillance B erreur faute

Pour A, la dfaillance de B (service incorrect) constitue une faute, qui peut son tour provoquer une erreur interne A, puis une dfaillance de A
faute " erreur " dfaillance " faute " erreur "

2003-2004, S. Krakowiak

13

2003-2004, S. Krakowiak

14

Degrs de permanence des dfaillances

Comment assurer la srt de fonctionnement

vitement des fautes : vise empcher loccurrence de fautes

! Les dfaillances nont pas un comportement uniforme

! Par la prvention
" Analyser les causes potentielles de fautes " Prendre des mesures pour les liminer (pas toujours possible) ou rduire leur probabilit

dans le temps
" Dfaillance transitoire # se produit de manire isole " Dfaillance intermittente # se reproduit sporadiquement " Dfaillance permanente # persiste indfiniment (jusqu rparation) aprs son occurrence " Les dfaillances non permanentes sont difficiles modliser et traiter

! Par lvaluation
" Prvoir les fautes (et les mesures pour y faire face) " Prvision souvent statistique

! Par la vrification
" Avant mise en route du systme : examiner les fautes restantes, et liminer celles que lon peut liminer

Tolrance aux fautes : vise prserver le service malgr loccurrence de fautes

! Par la redondance
" du matriel, des traitements, des donnes

2003-2004, S. Krakowiak

15

2003-2004, S. Krakowiak

16

Tolrance aux fautes - motivations

Tolrance aux fautes - tapes

! Constatation de base
" Quelles que soient les prcautions prises, loccurrence de fautes est invitable (erreur humaine, malveillance, vieillissement du matriel, catastrophe naturelle, etc.). Cela ne veut pas dire quil ne faut pas essayer de prvenir ou dliminer les fautes, mais les mesures prises peuvent seulement rduire la probabilit de leur occurrence " Il faut donc concevoir les systmes de manire ce quils continuent rendre le service attendu (ventuellement un service dgrad) mme en prsence de fautes

Plusieurs phases successives, non obligatoirement toutes prsentes Dtection Dcouvrir lexistence dune erreur (tat incorrect) ou dune dfaillance (comportement incorrect) Localisation Identifier le point prcis (dans l'espace et le temps) o lerreur (ou la dfaillance) est apparue Isolation Confiner lerreur pour viter sa propagation dautres parties du systme Rparation Remettre du systme en tat de fournir un service correct

! Remarque trs importante!

" ll nexiste pas de mthodes de tolrance aux fautes valables dans labsolu, seulement des mthodes adaptes des hypothses particulires doccurrence de fautes. Ces hypothses doivent donc tre explicitement formules, aprs analyse soigneuse

2003-2004, S. Krakowiak

17

2003-2004, S. Krakowiak

18

Tolrance aux fautes - techniques

Traitement des erreurs

! Deux classes de techniques

" Traiter les erreurs # dtecter lexistence dun tat incorrect (erreur) # remplacer ltat incorrect par un tat correct (conforme aux spcifications) " Traiter les fautes # prvoir des composants multiples, pour rduire la probabilit quune faute conduise une dfaillance # raliser des traitements multiples
$ (par exemple : raliser la mme opration par des algorithmes diffrents pour tenter dviter les fautes de conception)

Deux techniques de base ! Recouvrement (error recovery)

" Remplacer ltat derreur par un tat correct " Ncessite dtection de lerreur (identification de la partie incorrecte de ltat), au moyen dun test de vraisemblance # explicite (exprimer et vrifier des proprits spcifiques de ltat) # implicite (via des consquences visibles : violation dun dlai de garde, violation de protection de mmoire, etc.) " Deux techniques de recouvrement # reprise (backward recovery) # poursuite (forward recovery)

! Dans tous les cas, un principe unique : la redondance

" redondance dinformation (dtection derreur) " redondance temporelle (traitements multiples) " redondance matrielle (composants dupliqus)

! Compensation (error masking)

" Ltat posde une redondance interne suffisante pour dtecter et corriger lerreur (les tests externes de vraisemblance sont inutiles)

2003-2004, S. Krakowiak

19

2003-2004, S. Krakowiak

20

Dtection derreur (1)

Dtection derreur (2)

! Techniques ! Objectifs
" prvenir (si possible) loccurrence dune dfaillance provoque par lerreur " viter la propagation de lerreur dautres composants " faciliter lidentification ultrieure de la faute (en vue de son limination ou de sa prvention " Comparaison des rsultats de composants dupliqus cot lev latence faible taux de couverture lev ncessit dindpendance des conditions de cration et d'activation des fautes (cf Ariane 501) " Contrle de vraisemblance # cot modr # latence variable selon la technique # taux de couverture souvent faible # # # #

! Paramtres
" latence : dlai entre production et dtection de lerreur " taux de couverture : pourcentage derreurs dtectes

2003-2004, S. Krakowiak

21

2003-2004, S. Krakowiak

22

Illustration des techniques de traitement des erreurs

Recouvrement (1)

! Recouvrement
" Dtection explicite derreur!; remplacement de ltat derreur par un tat correct # Reprise ( partir dun tat ancien enregistr) # Poursuite (reconstitution dun ltat courant correct) " Exemples # Tandem Non-Stop # Points de reprise dans un systme rparti

! Reprise (backward recovery)

" Retour en arrire vers un tat antrieur dont on sait quil est correct " Ncessite la sauvegarde de ltat " Technique gnrale
sauvegarde restauration tat correct tat erron

Reprise

! Poursuite (forward recovery)

" Tentative de reconstitution dun tat correct, sans retour arrire " La reconstitution est souvent seulement partielle, do service dgrad " Technique spcifique, la reconstitution dpend de lapplication, et ncessite une analyse pralable des types derreurs possibles
23 2003-2004, S. Krakowiak

! Compensation
" Redondance suffisante pour masquer (rendre invisibles aux utilisateurs) les consquences dune erreur " Exemples # Vote majoritaire # Tandem Integrity # Stratus S/32
2003-2004, S. Krakowiak

tat erron

reconstitution tat correct (ventuellement spcif. plus faibles)

Poursuite

24

Recouvrement (2)
! Un exemple
" Communication par paquets : comment ragir la perte dun paquet ?

Recouvrement : techniques de reprise

! Solution 1 : reprise
" Lmetteur conserve une copie des paquets quil a envoys, jusqu rception de lacquittement " En cas de dtection de perte (par dlai de garde), le rcepteur demande lmetteur de renvoyer le paquet manquant

! Reprise
" le systme est ramen un tat quil occupait avant occurrence de lerreur (retour arrire) " cet tat doit avoir pralablement t sauvegard (points de reprise)

! Solution 1 : poursuite
" Pour un type particulier dapplication, lmetteur peut reconstituer (totalement ou partiellement) le contenu dun paquet manquant en utilisant les paquets voisins (suivants, prcdents) " Le rcepteur peut alors poursuivre sans interroger lmetteur

! Problmes de la reprise
" sauvegarde et restauration doivent tre atomiques (pas dinterfrences) " ltat des points de reprise doit lui-mme tre protg contre les fautes " dans un systme rparti : # les points de reprise sont crs pour chaque processus # lensemble de ces points de reprise doit constituer un tat global cohrent du systme

! Comparaison
" Reprise : technique gnrique, peut tre coteuse en temps et place ; cest la plus utilise " Poursuite : technique spcifique, peut tre efficace, mais dapplication limite " Dans la suite, nous ne traitons que de la reprise
2003-2004, S. Krakowiak 25

2003-2004, S. Krakowiak

26

Exemple de recouvrement par reprise:

Tandem Non-Stop
Dynabus

Points de reprise dun systme rparti:

cohrence dun tat global
" La cohrence de ltat global est lie aux communications

UC mmoire canal

UC mmoire canal

# Matriel
$ lalimentation lectrique est galement redondante (deux sources indpendantes) $ composants dtection d'erreur par contrle de vraisemblance $ une dtection derreur bloque immdiatement le composant (fail fast)

" La causalit doit tre respecte (un message est mis avant dtre reu)
dtection derreur et retour arrire

PR1 processus p1 message m processus p2 PR2 C2 tat courant de p2 lors de la dtection de lerreur

contrleur

# Logiciel
$ Paires de processus (processus actif processus de secours, cf plus loin) $ Ncessite systme dexploitation spcifique (Unix modifi pour gestion des paires de processus)

contrleur

Disques miroir criture sur 2, lecture sur 1

Tolre une faute unique d'un composant (UC, bus, mmoire, contrleur, disque)

Ltat global (PR1, C2) est incohrent (m not comme reu et non mis) Le processus p2 (non dfaillant) est orphelin et doit revenir en PR2 Avec un mauvais choix des points de reprise, le retour en arrire peut se propager jusqu ltat initial (effet domino)
27 2003-2004, S. Krakowiak 28

idem pour autres priphriques (bandes, terminaux)

2003-2004, S. Krakowiak

Reprise :
comment constituer un tat de reprise cohrent ?
Bref rappel de points dj vus ! A priori (approche planifie)
" les sauvegardes des diffrents processus sont coordonnes pour constituer un tat global cohrent (pas deffet domino) " une synchronisation explicite doit donc tre assure entre les processus (cot lors de la sauvegarde) " il suffit de conserver, pour chaque processus, le dernier point de reprise " Exemples : Chandy-Lamport (vu en cours), Koo-Toueg

Exemple denregistrement asynchrone (1)

Principe : Dtecter les processus orphelins en comptant les messages envoys et reus Hypothses : canaux fiables FIFO, asynchrones application pilote par les vnements : rception, traitement, mission Algorithme optimiste : pour chaque processus, on enregistre pour chaque vnement, en mmoire volatile : (tat, message reu, messages mis). Priodiquement, ces enregistrements sont copis en mmoire permanente.
tat tat

! A posteriori (approche non planifie)

" les sauvegardes des processus sont indpendantes " en cas de reprise, on essaie de reconstituer un tat cohrent (cot lors de la restauration) " il faut conserver plusieurs points de reprise par processus, ainsi que les traces des communications " le risque deffet domino nest pas limin " Example : Juang-Venkatesan

T. Juang, S. Venkatesan. Crash Recovery with little Overhead, Proc. 11th Int. Conf. On Distributed Computing Systems (ICDCS), May 1991, pp. 454-461
29 2003-2004, S. Krakowiak 30

2003-2004, S. Krakowiak

Exemple denregistrement asynchrone (2)

Soit RCVDi # j(CKPTi) le nb de messages reus par i depuis j, enregistrs au point de reprise CKPTi Soit SENTi " j(CKPTi) le nb de messages envoy par i vers j, enregistrs au point de reprise CKPTi Alors pour quun ensemble de points de reprise CKPTi soit valide, il faut que : pt de reprise $ i, j : RCVDi # j(CKPTi) ! SENTj "i(CKPTj) P Q Q R R
T. Juang, S. Venkatesan. Crash Recovery with little Overhead, Proc. 11th Int. Conf. On Distributed Computing Systems (ICDCS), May 1991, pp. 454-461
2003-2004, S. Krakowiak 31

Exemple denregistrement asynchrone (3)

Algorithme : au moment de la reprise, le processus qui redmarre diffuse un message de reprise tous. Chacun vrifie que son dernier point de reprise (en mmoire volatile pour les processus non en panne) vrifie la condition de validit. Sinon, il doit remonter au dernier point vrifiant la condition, et ritrer ( cause des ractions en chane)
pt de reprise en mmoire volatile

en mmoire volatile

T. Juang, S. Venkatesan. Crash Recovery with little Overhead, Proc. 11th Int. Conf. On Distributed Computing Systems (ICDCS), May 1991, pp. 454-461
2003-2004, S. Krakowiak 32

Exemple denregistrement asynchrone (4)

Lors de la reprise : utiliser les informations enregistres au point de reprise (tat, message reu, message mis) rejouer le dernier message reu (qui a t enregistr) rejouer le traitement rmettre les messages mis ignorer les messages dupliqus
ignorer rejouer

Exemple de compensation : vote majoritaire

Systme TMR (Triple Modular Redundancy)

entres identiques

tape n

tape n+1

traitement

voteur

P
rejouer

rmettre

traitement

voteur

Rsiste (en gnral) la dfaillance d'un composant de traitement et dun voteur par tape

Q
rejouer rmettre

traitement

voteur

R
T. Juang, S. Venkatesan. Crash Recovery with little Overhead, Proc. 11th Int. Conf. On Distributed Computing Systems (ICDCS), May 1991, pp. 454-461
2003-2004, S. Krakowiak 33

composants identiques

vote majoritaire

2003-2004, S. Krakowiak

34

Exemple de compensation : Tandem Integrity

Exemple de compensation : Stratus S/32

UC mmoire locale

UC mmoire locale

UC mmoire locale

processeur autotestable

processeur autotestable

processeur 1

voteur : test chaque accs la mmoire code correcteur d'erreur en mmoire test chaque accs, correction si erreur

voteur

voteur

processeur 2

autotestable
Processeur autotestable :

mmoire commune IOP (canal)

mmoire commune IOP (canal)

Composant autotestable!: test interne (redondance), arrt et signal si erreur Tolre (et masque) la faute dun composant Fonctionne avec un systme dexploitation standard

processeurs identiques sortie compare bit bit, arrt et dconnexion si erreur

contrleur de disque

contrleur de disque

2003-2004, S. Krakowiak

35

2003-2004, S. Krakowiak

36

Compensation : rsum

Difficult de la tolrance aux fautes

! Les piges sont nombreux
" Mauvaise analyse des fautes possibles # ne pas prvoir des cas possibles de faute # laisser passer des fautes sans raction " Raction inapproprie due des hypothses mal formules # le remde peut aggraver la situation " Mise en uvre incorrecte de la redondance # les lments redondants doivent avoir des modes de dfaillance diffrents # une mauvaise redondance donne un faux sentiment de scurit

! Avantages
" Traitement derreur rapide " Masquage : dfaillances internes invisibles aux composants utilisateurs, condition que # les hypothses de fautes soient respectes # les fautes soient indpendantes sur les composants dupliqus

! Inconvnients
" Redondance leve, donc cot lev # Tandem Integrity : X 3 # Stratus : X 4

! Deux exemples dcole

" Ariane 501
http://www.cnes.fr/espace_pro/communiques/cp96/rapport_501/rapport_501_2.html

" Therac 25
http://sunnyday.mit.edu/therac-25.html

2003-2004, S. Krakowiak

37

2003-2004, S. Krakowiak

38

Ariane 501

Ariane 501: scnario (trs) simplifi (1)

Le systme de pilotage

Le 4 juin 1996, le premier tir de la fuse Ariane 5 se termina par lexplosion de lengin environ 40 secondes aprs le dcollage. Lenqute permit de dterminer les circonstances prcises de la catastrophe et mit en vidence plusieurs erreurs de conception du logiciel de commande, et notamment de son systme de tolrance aux fautes, qui conduisirent au dclenchement dune raction inapproprie alors que les conditions de vol taient normales.

paramtres de vol (attitude, vitesse, etc) mesures dacclration SRI-2 centrale inertielle (en service) capteurs commandes de pilotage (braquage des tuyres)

calculateur de bord

SRI-1

voir rapport denqute en :

http://www.cnes.fr/espace_pro/communiques/cp96/rapport_501/rapport_501_2.html

centrale inertielle (de secours)

inutilis

2003-2004, S. Krakowiak

39

2003-2004, S. Krakowiak

40

Ariane 501: scnario (trs) simplifi (2)

Ariane 501: scnario (trs) simplifi (3)

centrale inertielle en service SRI-2 convertisseur 64 bit 16 bit SRI-2

centrale inertielle en service convertisseur 64 bit valeur trop leve 16 bit traitement derreur

T0 + 36 sec. +72 ms
diagnostic derreur vers le calculateur de bord

SRI-1 convertisseur 64 bit valeur trop leve

(dpasse capacit)

SRI-1

T0 + 36 sec.
16 bit diagnostic derreur la centrale de secours est mise hors service (fail fast)
41 2003-2004, S. Krakowiak

chec de la tentative de passage sur la centrale de secours

hors service

traitement derreur

centrale inertielle de secours

2003-2004, S. Krakowiak

centrale inertielle de secours

42

Ariane 501: scnario (trs) simplifi (4)

Ariane 501 : explications (1)

Pourquoi le convertisseur a-t-il reu en entre une valeur trop grande ?

braquage maximum (20) des tuyres diagnostic derreur dviation de la trajectoire dsintgration sous leffet des forces arodynamiques auto-destruction 1) Lentre tait la mesure dune vitesse de dplacement horizontale, et servait un systme de calibrage des instruments utilis avant le dcollage. Ce systme tait inchang depuis sa version Ariane 4 (on ne change pas un dispositif qui marche). 2) Nanmoins, ce systme tait maintenu en service 40 secondes aprs le dcollage, en vue de permettre larrt puis la reprise du compte rebours dans les dernires secondes avant le dcollage (dans une limite de 40 secondes). Cette disposition (qui a servi une fois pour Ariane 4) tait en fait inutile pour Ariane 5 en raison dun changement des procdures. 3) Mais la trajectoire dAriane 5 tait diffrente de celle dAriane 4, et en particulier sa vitesse de dplacement horizontale tait beaucoup plus leve 4) Donc la valeur de lentre, correspondant la vitesse horizontale mesure, a dpass les capacits du convertisseur

calculateur de bord

Le calculateur de bord reoit en entre un diagnostic derreur, quil interprte comme des donnes de vol. Les valeurs tant hors limites, il ragit (normalement) par un ordre de braquage maximum

2003-2004, S. Krakowiak

43

2003-2004, S. Krakowiak

44

Ariane 501 : explications (2)

Ariane 501 : la morale de lhistoire

Le scnario de la catastrophe rvle plusieurs erreurs de conception

Pourquoi le convertisseur a-t-il ragi en envoyant un diagnostic derreur sur le bus de donnes ?
1) Les instructions de conversion de donnes (crites en Ada) ntaient pas protges par un traitement dexception (on navait pas prvu que la capacit dentre pouvait tre dpasse). 2) Cest le dispositif standard de raction aux erreurs qui a t activ par dfaut. La centrale inertie a dclar son incapacit fonctionner et a t mise hors service selon le principe fail stop (arrt du processeur). 3) Lhypothse sous-jacente (non explicite) tait celle de la dfaillance matrielle transitoire!: dfaillance de probabilit trs faible, traite par redondance (on passe sur la centrale de secours). 4) Mais la dfaillance tant dorigine logicielle, les mme causes ont produit des effets identiques, et la centrale de secours sest trouve hors service pour les mmes raisons que la centrale active. 5) On se trouvait donc hors des hypothses prvues pour le traitement des dfaillances (panne simultane des deux units). Ce cas tant suppos ne jamais se prsenter, rien ntait prvu pour le traiter et le diagnostic derreur a t envoy sur le bus de donnes.

1) Analyse incorrecte de la transition Ariane 4 " Ariane 5 (pour la centrale inertie)

Un dispositif totalement inutile a t maintenu en fonction dans un quipement critique Les consquences du changement de conditions (vitesse diffrente) nont pas t analyses

2) Analyse incorrecte des hypothses de dfaillance

Le dpassement de capacit na pas t prvu dans le convertisseur (pas de traitement dexception associ lopration de conversion). Lhypothse la base de la redondance a t incorrectement formule (la redondance ne vaut que si les conditions de dfaillance sont indpendantes pour les deux units redondantes). Lventualit derreurs logicielles (qui prcisment ne sont pas indpendantes, surtout si un mme algorithme sert dans les deux units) na pas t prise en compte.

3) Prvision insuffisante des conditions de traitement de situations anormales

La raction de mise hors service de la centrale aprs erreur (arrt du processeur) prive le systme dune possibilit de reprise (cette erreur danalyse est lie lide que la dfaillance est toujours traite par la redondance des units). La possibilit denvoyer des informations de diagnostic sur un bus de donnes aurait du tre totalement exclue. Il valait mieux, en cas de situation anormale, envoyer des donnes raisonnables, par exemple obtenues par extrapolation.

2003-2004, S. Krakowiak

45

2003-2004, S. Krakowiak

46