Plan

 Sû té de
Sûreté d fonctionnement
f ti t

 Défaillances fautes,
Défaillances, fautes erreurs

 Types
yp et sources de fautes

 Méthodes pour la sûreté de fonctionnement

 la tolérance aux fautes

 Exemple d’échec : Ariane 5

2
Sûreté de fonctionnement (dependability)
( p y)
 Définition :
 Propriété d’un système informatique permettant à ses utilisateurs
de placer une confiance justifiée dans le service que délivre le
système

 Aspects :
 Fiabilité (reliability)
 Disponibilité (availability)
 Sûreté (safety)
 Maintenabilité (maintainability)
 Sécurité (security)

3
Sûreté de fonctionnement (dependability)
( p y)
 Fiabilité
 La mesure dans
L d l
laquelle
ll un système
tè estt en état
ét t de
d rendre
d son
service (état opérationnel)
 Quantification : probabilité de défaillance sur une période donnée
 Pour systèmes à mission continue : MTTF (Mean Time To Failure),
MTBF (Mean Time Between Failure)

 Maintenabilité
 La mesure dans laquelle un système défaillant peut revenir à un
état opérationnel
 Quantification : temps nécessaire au système pour revenir à un
état opérationnel (reprise). Mission continue : MTTR (Mean Time
To Repair)

4
Sûreté de fonctionnement (dependability)
( p y)

 Disponibilité
 La mesure dans laquelle un système alterne entre état
opérationnel et état défaillant
 Quantification : probabilité que le système soit dans un état
 opérationnel à un instant donné.
 Mission continue : A = MTBF / (MTBF + MTTR)
 • A = 99 % -> 4 jours d ’indisponibilité par an
 • A = 99,9
99 9 % ->
> 9 heures
h par an
 • A = 99,999 % -> 5 minutes par an

5
Sûreté de fonctionnement (dependability)
( p y)

 Sûreté
 La mesure dans laquelle un système défaille sans incidence
«catastrophique» sur son environnement

 Sécurité
 La mesure dans laquelle un système résiste à des fautes
intentionnelles
 Aspects
 Authentification
 Contrôle d ’accès
accès
 Intégrité
 Confidentialité

6
Défaillances,, fautes,, erreurs

 La faute ((« fault »)) dans un système

y informatique
q
représente soit un défaut d’un composant physique, ou
soit un défaut d
d’un
un composant logiciel de ce système.
système Elle
peut être créée de manière intentionnelle ou accidentelle,
à cause des phénomènes physiques ou à cause des
imperfections humaines.

 Durant l’exécution du système, la faute reste dormante

jusqu’`a
jusqu a ce qu
qu’un
un évènement intentionnel ou accidentel
provoque son activation.

7
Défaillances,, fautes,, erreurs
 Erreur : l’activation d’une faute durant l’exploitation du
système peut se manifester par la présence d’un état
interne erroné dans ce système.
y Sous des circonstances
particulières cet état interne erroné peut conduire à une
erreur cc’est-à-dire
erreur, est-à-dire, à un résultat incorrect ou imprécis.
imprécis

 Défaillance : une erreur peut changer le comportement

d’un système et provoquer le non respect de sa
spécification : c’est une défaillance du système.

8
De la faute à la défaillance
 la défaillance d’un système est la conséquence d’une
erreur, et l’erreur est la conséquence d’une faute activée.

 En plus, étant donné qu’un système informatique est

souvent composé
é de plusieurs sous-systèmes,
è la
défaillance d’un sous-système peut créer et/ou activer une
faute dans un autre sous-système, ou dans le système lui
même.

9
De la faute à la défaillance

10
Types
yp de fautes

 Suivant la persistance temporelle d

d’une
une faute,
faute on
distingue trois types de fautes qui peuvent affecter
un système :
 fautes permanentes

 f t transitoires,
fautes t it i ett

 fautes intermittentes

11
Types
yp de fautes
 Une faute permanente se caractérise par sa durée
permanente, une fois activée, durant l’exploitation du
système. Elle persiste donc indéfiniment (jusqu’à
réparation)
é ti ) après
è son occurrence.

 Exemple : une faute de conception d’un composant

matériel est un exemple typique de faute permanente.
 L’étude réalisée sur la conception des mémoires DRAM
(Dynamic Random Access Memory) montre que l’augmentation
de la capacité d’une mémoire RAM à 32 fois sa capacité initiale
provoque une augmentation de 50% du taux d’occurrence de
fautes permanentes

12
Types
yp de fautes
 Une faute transitoire se caractérise par sa durée limitée,
une fois activée, durant l’exploitation du système.
 Les fautes transitoires sont souvent observées dans les
systèmes de communication, où la présence des radiations
électromagnétiques peut corrompre les données envoyées sur
une liaison.
liaison physique de communication.
communication Ceci provoque une
faute transitoire qui ne dure que la période de la présence de
ces radiations.

 Une faute intermittente est une faute transitoire q

qui se
reproduit sporadiquement.

13
Sources de fautes
 Suivant les exigences fonctionnelles et temporelles d’un système,
la défaillance de ce système peut être la conséquence de deux
sources de fautes :

 Faute fonctionnelle (ou fautes de valeur) : La valeur délivrée par le

système est fausse, c’est-à-dire qu’elle n’est pas conforme à sa
spécification, ou elle est en dehors de l’intervalle des valeurs
attendues.

 Faute temporelle : l’instant auquel la valeur est délivrée est en

dehors de l’intervalle de temps spécifié. Dans ce cas, la valeur est
considérée soit temporellement délivrée trop tôt, soit trop tard, soit
infiniment tard (jamais délivrée). La faute temporelle dans le cas où
la valeur n
n’est
est jamais délivrée est appelée : faute par omission.
omission

14
Méthodes p
pour sûreté de fonctionnement
 Évitement (« fault avoidance »)
 Vérification
 Détecter et supprimer les fautes avant qu’elles aient pu produire
une erreur
 Prévention
 A l
Analyser l causes potentielles
les t ti ll de d fautes
f t
 Prendre des mesures pour les éliminer (pas toujours possible) ou
réduire leur probabilité
 Évaluation
 Prévoir les fautes (et les mesures pour y faire face)
 Prévision souvent statistique

15
Méthodes p
pour sûreté de fonctionnement
 Tolérance aux fautes
 Toutes les fautes ne peuvent être évitées
 Quelles que soient les précautions prises, l’occurrence de fautes
est inévitable (erreur humaine, malveillance, vieillissement du
matériel, catastrophe naturelle, etc.). Cela ne veut pas dire qu’il ne
faut p
pas essayer
y de p prévenir ou d’éliminer les fautes,, mais les
mesures prises peuvent seulement réduire la probabilité de leur
occurrence

 Assurer la fourniture du service malgré l ’occurrence de fautes

16
Méthodes p
pour sûreté de fonctionnement
 Tolérance aux fautes
 Par l’emploi de redondances
 Spatiales (duplication de composants)
 Temporelles (traitements multiples)
 Informationnelles (codes et signatures)

 Remarque très importante …

 il n
n’existe
existe pas de méthodes de tolérance aux fautes valables dans
l‘absolu, seulement des méthodes adaptées à des hypothèses
particulières d’occurrence de fautes. Ces hypothèses doivent donc
être explicitement formulées,
formulées après une analyse soigneuse.
soigneuse

17
Phases d’un algorithme
g de tolérance aux fautes
 Détection des erreurs
 La détection des erreurs permet d d’identifier
identifier le type et ll’origine
origine des
erreurs. Cette détection peut être faite soit au niveau de l’environnement
du système, soit au niveau de l’application du système.
 Au niveau de ll’environnement
environnement, cc’est
est ll’exécutif
exécutif de ll’application
application qui se
charge de détecter certaines erreurs, qui peuvent être par exemple de
type : division par zéro, erreur d’entrée/sortie, accès interdit au
périphérique.
é i hé i
 Au niveau de l’application, ce sont les composants redondants qui se
chargent
g de réaliser cette tâche de détection. Les techniques de
détection d’erreurs au niveau de l’application sont nombreuses. Parmi les
techniques de base, on trouve la comparaison des résultats de
composants répliqués et la vérification des temps de délivrance des
résultats. Enfin, la réussite d’une telle technique de détection des erreurs
dépend de deux paramètres qui sont la latence (délai entre la production
et la détection de ll’erreur)
erreur), et le taux de couverture (pourcentage
d’erreurs détectées).
18
Phases d’un algorithme
g de tolérance aux fautes
 Traitement des erreurs
 Cette phase consiste à traiter les états erronés (ou erreurs) détectés par
la première phase, à l’aide d’une des deux techniques de base suivantes:
 recouvrement des erreurs : le recouvrement consiste à remplacer l’état
erroné par un état correct.
correct Il utilise soit la technique de la reprise,
reprise soit la
technique de la poursuite. La reprise consiste à mettre le système dans
un de ses états précédents corrects, et la poursuite consiste soit en la
reconstitution
tit ti d’un
d’ état
ét t correct,
t soitit en la
l reconstitution
tit ti partielle
ti ll d’un
d’ état
ét t
correct qui permet au système de fonctionner en mode dégradé.
 compensation des erreurs : la compensation consiste en la
reconstruction totale d’un état correct en utilisant un ensemble
d’informations redondantes existantes dans le système.

 Le choix entre ces deux techniques est un compromis entre plusieurs

facteurs, tels que la complexité du système, les contraintes temporelles
ett matérielles
té i ll ett la
l criticité
iti ité du
d système.
tè

19
Phases d’un algorithme
g de tolérance aux fautes
 Exemple de compensation des erreurs vote majoritaire

20
Hypothèses
yp de défaillance
 Systèmes à défaillances en valeur : ces systèmes supposent que les
valeurs sont délivrées à temps et qu
qu’ils
ils défaillent uniquement si les valeurs
délivrées sont fausses,

 Systèmes
S tè à silence
il sur défaillances
déf ill : un système
tè à silence
il sur
défaillances soit fonctionne correctement (valeurs correctes et délivrées à
temps), soit est défaillant et il arrête alors de fonctionner.

 Systèmes à arrêt sur défaillances : ce sont des systèmes à silence sur

défaillances, mais, avant que le système
y arrête son fonctionnement, il délivre
un message aux autres systèmes indiquant son arrêt. Un exemple de ces
systèmes est le processeur à arrêt sur défaillance. Ce processeur est un
composant physique, qui en présence de fautes, spécifiées dans ses
hypothèses de défaillances, génère un message indiquant son arrêt;

21
Hypothèses
yp de défaillance
 Systèmes à défaillances par omission : ces systèmes supposent que les
valeurs
l sontt correctes,
t ett qu’ils
’il défaillent
déf ill t uniquement
i t sii la
l valeur
l n’est
’ t jamais
j i
délivrée. Par exemple, un système perd des messages sortants (omission en
émission) ;

 Systèmes à défaillances temporelle : ces systèmes supposent que les

valeurs délivrées sont correctes,, et q
qu’ils défaillent uniquement
q si la valeur
est temporellement délivrée trop tôt (en avance par rapport à sa plage de
temps spécifiée) ou trop tard (en retard par rapport à sa plage de temps
spécifiée),
spécifiée)

 Systèmes à défaillances byzantines : ces systèmes défaillent d’une

manière
iè arbitraire.
bit i C mode
Ce d de d défaillance
déf ill estt parfois
f i considéré
idé é par des
d
systèmes à très haute fiabilité (nucléaire, spatial).

22
Couverture entre les hypothèses
yp de défaillance

23
Tolérance aux fautes logicielles
g
 Les fautes logicielles sont dues aux erreurs de conception des composants
logiciels de l’algorithme. Un exemple très intéressant de faute logicielle est
l’explosion de la fusée Ariane 5 en juin 1996 à cause des erreurs de conception
du logiciel.

 Uni-version du logiciel : utilise une seule version du logiciel. Pour tolérer la faute
de chaque uni-version du logiciel, le concepteur du système doit la modifier en
lui ajoutant des mécanismes de détection et de traitement d’erreurs. Exemple :
t it
traitementt d’exceptions,
d’ ti dét ti
détection d’
d’erreur, point
i t de
d reprise.
i

 Multi-version du logiciel : basée sur le principe de la redondance logicielle, où

chaque composant logiciel est répliqué en plusieurs versions différentes.
L’avantage de cette technique par rapport à la première technique est que ces
versions logicielles peuvent être exécutées en séquence ou en parallèle pour
tolérer les fautes
fa tes de certaines versions.
ersions En plus,
pl s les algorithmes implantant ces
versions logicielles peuvent être, tous ou certains, développés par différents
concepteurs sur différents outils. Exp : N-version de programmation. C’est le
cas des commandes de vol des avions Airbus et Boeing

24
Tolérance aux fautes matérielles

 Les fautes
L f t matérielles
té i ll sontt souventt dues
d soit
it aux fautes
f t d
de
conception et de fabrication des composants matériels du système,
soit à l’interaction du système
y avec l’environnement qqu’il contrôle.

 Elles peuvent être tolérées soit en utilisant des solutions logicielles,

soit en utilisant des solutions matérielles. Les solutions logicielles
sont basées sur la redondance des composants logiciels, et les
solutions matérielles sont basées sur la redondance des composants
matériels.

25
Difficulté de la tolérance aux fautes

 Les p
pièges
g sont nombreux …
 Mauvaise analyse des fautes possibles
 ne
e pas p
prévoir
é o des cas poss
possibles
b es de faute
au e
 laisser passer des fautes sans réaction
 Réaction
éact o inappropriée
app op ée due à des hypothèses
ypot èses mal
a formulées
o u ées
 le “remède” peut aggraver la situation
 Mise en oeuvre incorrecte de la redondance
 les éléments redondants doivent avoir des modes de défaillance
différents
 une mauvaise redondance donne un faux sentiment de sécurité

26
Exemple
p d’échec : Ariane 5
 Le 4 juin 1996, le premier tir de la fusée Ariane 5 se
termina par l’explosion de l’engin environ 40 secondes
après le décollage.

 L’enquête
q permit de déterminer les circonstances
p
précises de la catastrophe et mit en évidence plusieurs
erreurs de conception du logiciel de commande, et
notamment de son système de tolérance aux fautes, qui
conduisirent au déclenchement d’une réaction
inappropriée alors que les conditions de vol étaient
normales.

27
Exemple
p d’échec : Ariane 5
 Le système de pilotage

28
Exemple
p d’échec : Ariane 5
 Scénario (très) simplifié

29
Exemple
p d’échec : Ariane 5
 Scénario (très) simplifié

30
Exemple
p d’échec : Ariane 5
 Scénario (très) simplifié

31
Pourquoi
q l’échec : Ariane 5

Pourquoi le convertisseur a-t-il

a t il reçu en entrée une valeur trop grande ?

 L’entrée était la mesure d’une vitesse de déplacement horizontale, et servait

à un système
tè d calibrage
de lib d
des i t
instruments
t utilisé
tili é avantt le
l décollage.
dé ll C
Ce

système était inchangé depuis sa version Ariane 4 (on ne change pas un

dispositif qui marche…).

marche )

 Mais la trajectoire d’Ariane 5 était différente de celle d’Ariane 4, et en

particulier
ti li sa vitesse
it d déplacement
de dé l t horizontale
h i t l était
ét it beaucoup
b plus
l élevée
él é

 Donc la valeur de l’entrée, correspondant à la vitesse horizontale mesurée, a

dé
dépassé
é les
l capacités
ité du
d convertisseur
ti

32
Pourquoi
q l’échec : Ariane 5
Pourquoi le convertisseur a-t-il réagi en envoyant un diagnostic d’erreur sur le bus
de données ?
 Les instructions de conversion de données (écrites en Ada) n’étaient pas protégées par
un traitement d’exception (on n’avait pas prévu que la capacité d’entrée pouvait être
dépassée).
dépassée)
 C’est le dispositif standard de réaction aux erreurs qui a été activé par défaut. La
centrale à inertie a déclaré son incapacité à fonctionner et a été mise hors service selon
le principe fail stop (arrêt du processeur).
processeur)
 défaillance de probabilité très faible, traitée par redondance (on passe sur la centrale de
secours).
 M i la
Mais l défaillance
déf ill ét t d’origine
étant d’ i i l i i ll les
logicielle, l même
ê causes ontt produit
d it des
d effets
ff t
identiques, et la centrale de secours s’est trouvée hors service pour les mêmes raisons
que la centrale active.
 On se trouvait donc hors des hypothèses prévues pour le traitement des défaillances
(panne simultanée des deux unités). Ce cas étant supposé ne jamais se présenter, rien
n’était prévu pour le traiter et le diagnostic d’erreur a été envoyé sur le bus de données.

33
Ariane 501 : la morale de l’histoire
Le scénario de la catastrophe révèle plusieurs erreurs de conception
 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 conséquences du changement de conditions (vitesse différente) n’ont pas été analysées

 Analyse
y incorrecte des hypothèses
yp de défaillance
 Le dépassement de capacité n’a pas été prévu dans le convertisseur (pas de traitement
d’exception associé à l’opération de conversion).
 L’hypothèse
yp à la base de la redondance a été incorrectement formulée ((la redondance ne vaut
que si les conditions de défaillance sont indépendantes pour les deux unités redondantes).
 L’éventualité d’erreurs logicielles (qui précisément ne sont pas indépendantes, surtout si un
même algorithme sert dans les deux unités) n’a pas été prise en compte.

 Prévision insuffisante des conditions de traitement de situations anormales

 La réaction de mise hors service de la centrale après erreur (arrêt du processeur) prive le système
d’une possibilité de reprise (cette erreur d’analyse est liée à l’idée que la défaillance est toujours
traitée par la redondance des unités).
 La possibilité d’envoyer des informations de diagnostic sur un bus de données aurait du être
totalement exclue. Il valait mieux, en cas de situation anormale, envoyer des données
“raisonnables”.

34