systèmes en temps réel tolérance aux défaillances de logiciel
TRANSCRIPT
Systèmes en temps réel
Tolérance aux défaillances de
logiciel
Fault Tolerance - 2
Synopsis
Tolérance
Redondance
Redondance statique
Redondance dynamique
Patterns de tolérance des défaillances
Fault Tolerance - 3
Prévention des fautes
Évitement des fautes – Limitation de l’introduction de composantes fautives durant la construction Spécification rigoureuses (formelles) Méthodologies de design prouvées Sélection d’un langage de programmation approprié Environnement de développement/ingénierie (IDEs)
Enlèvement des fautes – trouver et enlever les causes d’erreurs Revues, inspections, tests
Mais que ce passe-t-il si les fautes ne peuvent pas êtres prévenues?
Fault Tolerance - 4
Tolérance des défaillances
La capacité qu’un système a de continuer de fonctionner même en présence des fautes. Tolérance des défaillances complète – système
continue d’opérer sans aucune perte de fonctionnalité significative (pour une période de temps limitée)
Mode dégradé – système continue d’opérer mais en mode dégradé
Sécurité intégrée – (fail safe) système passe en un état sécuritaire avant de se fermer ou résultant d’une faute particulière
Fault Tolerance - 5
Redondance
Pour permettre la tolérance des fautes en logiciel, nous avons besoin d’un certain degré de redondance. {dans ce sens, la définition de redondance inclus le code additionnel qui ne serait pas requis pour l’opération normal du système}
But – minimiser la redondance, maximiser R(t)
Paradoxe – trop peut réduire R(t)
Fault Tolerance - 6
Redondance statique
Composantes redondantes sont utilisées pour masquer les erreurs
h/w: Redondance N Modulaire (NMR)
s/w: programmation N-versions N versions redondantes du même module sous
un même contrôleur et un système de votes
Fault Tolerance - 7
Redondance statique
Suppositions Spécifications complètes, consistantes, sans
ambiguïtés Mode de défaillance indépendants => équipes de développement séparés,
processeurs, langages, lignes de communication qui sont tolérantes, …
Problèmes) spécifications sont un facteur contribuant majeur
des défauts indépendance n’est pas une supposition
raisonnable $$$
Fault Tolerance - 8
Redondance dynamique
Composantes redondantes pour détecter les erreurs
h/w: check des parité
s/w: bloques de reprise phases
détection éval/contrôle des dommages reprise des erreurs traitement de faute/continue
RP1
RP2
RP3
Points de reprise
Processus P1
Fault Tolerance - 9
Redondance dynamique
Suppositions Modules alternes exécutent seulement sur la
détection d’erreur(s) Encore dépendant des spécification en grande
mesure Les modes de défaillance connues et non
connues peuvent être traités Problèmes
La reprise d’erreurs vers l’arrière ne peut pas toujours enlever les dommages
$$
Fault Tolerance - 10
Quelques patterns de tolérance
Pattern de redondance homogène Protège contre les défaillances matériels seulement
(aléatoire)
Pattern de redondance diverse Protège contre les fautes systématiques 3 types:
Différent mais égale Léger Séparation des moniteurs / actionneurs
Pattern Moniteur-Actionneur Spécialisation de la redondance diverse
Pattern de surveillance (Watchdog)
Fault Tolerance - 11
Pattern de redondance homogène
Fault Tolerance - 12
Pattern de redondance homogène
Fault Tolerance - 13
Pattern de redondance diverse
Fault Tolerance - 14
Pattern moniteur-actionneur
Fault Tolerance - 15
Pattern moniteur-actionneur
Fault Tolerance - 16
Pattern de surveillance (watchdog)
Fault Tolerance - 17
Pattern de surveillance (watchdog)
matériel ou logiciel
Fault Tolerance - 18
Références
[1] Burns and Wellings, “Real-Time Systems and Programming Languages”, Chap 5.
[2] Douglass, “Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns”, Chap 3.