Fehlertoleranz in eingebetteten Systemen

Transkript

1 Fehlertoleranz in eingebetteten Systemen Ausgewählte Kapitel eingebetteter Systeme (AKES) / 36

2 Was ist ein Fehler? Fehlerklassen Überblick Einführung Was ist ein Fehler? Fehlerklassen 2 / 36

3 Was ist ein Fehler? Fehlerklassen Fehler Definition Ein Fehler ist eine Abweichung von einem optimalen oder normierten Zustand oder Verfahren in einem bezüglich seinen Funktionen determinierten System. (Wikipedia) 3 / 36

4 Was ist ein Fehler? Fehlerklassen Fault Failure - Error Fehler =...? Fault : Fehlfunktion, Störung Error : Irrtum, Abweg Failure : Ausfall, Versagen Fehlertoleranz = fault-tolerance 4 / 36

5 Was ist ein Fehler? Fehlerklassen Fehlerklassen : Versagen oder Fehlfunktion einer Komponente : Fehlerhaft programmierte Anwendung Kommunikations-Fehler: Fehlerhafte Übertragung von Daten 5 / 36

6 Überblick Einführung 6 / 36

7 Tolerieren von n Prinzip: Prozess wird repliziert Hardware mehrfach vorhanden Replikate werden verteilt 7 / 36

8 (1) Prinzip: alle Replikate gleichzeitig aktiv Ergebnisse werden simultan erzeugt Voter leitet mehrheitlich erzieltes Ergebnis weiter 8 / 36

9 (2) Replikat 1 Replikat 2 Replikat 3 Voter Input Nachricht Ergebnisberechnung Ergebnisberechnung Ergebnisberechnung Ergebnisse Voting Output Zeit 9 / 36

10 (3) Fehlererkennung: Ergebnis stimmt nicht mit Mehrheit überein Ergebnis wird zu spät erzeugt Ergebnis wird gar nicht erzeugt 10 / 36

11 (4) Bedingungen: Eingabe-Konsistenz Replikations-Determinismus 11 / 36

12 (5) Replikationsgrad: 2f+1 Knoten zur Tolerierung von f Fehlern Standardfall: f = 1 (triple modular redundancy) 12 / 36

13 fail-silent Knoten Besonderheiten: Sendung fehlerhafter Ergebnisse wird verhindert kein Voter notwendig nur f+1 Knoten zur Tolerierung von f Fehlern nötig 13 / 36

14 (1) Prinzip: nur ein Knoten aktiv Zustand wird zu bestimmten Zeiten (Checkpoints) auf die Replikate übertragen im Fehlerfall Aktivieren eines anderen Knoten Voraussetzung: alle Knoten sind fail-silent 14 / 36

15 (2) Replikat 1 Replikat 2 Replikat 3 Input Ergebnisberechnung Nachricht Checkpoint Aktivieren Fortsetzen der Berechnung am aktuellsten Checkpoint Zeit Output 15 / 36

16 (3) mögliches Problem: doppeltes Versenden von Nachrichten durch Rollback Gegenmaßnahmen: systematische Checkpoints periodische Checkpoints 16 / 36

17 (4) Systematische Checkpoints: Checkpoint nach jedem Versenden einer Nachricht Rollback erfordert niemals erneutes Senden 17 / 36

18 (5) Periodische Checkpoints: weniger Checkpoints, z.b. alle n Nachrichten nach Rollback jede zu Sendende Nachricht erst mit Log vergleichen Voraussetzungen: Replikations-Determinismus Eingabe-Konsistenz 18 / 36

19 (1) Prinzip: alle Knoten aktiv ein Knoten Leader, alle anderen Follower kein Voting, Leader übermittelt Ergebnis Leader trifft alle Entscheidungen und gibt sie via Synchronisations-Nachricht an Follower weiter defekter Leader wird durch einen Follower ersetzt 19 / 36

20 (2) Leader Follower 1 Follower 2 Input Nachricht Synchronisation Zeit /dev/null Output 20 / 36

21 (3) Synchronisations-Nachrichten: Input-Synchronisation: in welcher Reihenfolge sind Nachrichten zu konsumieren ( Eingabe-Konsistenz gewährleistet) Preemption-Synchronisation: zu welchem Zeitpunkt darf der Prozess unterbrochen werden ( Replikations-Determinismus gewährleistet) 21 / 36

22 (1) : Vorteile: keine Unterbrechung im Fehlerfall, falls Knoten fail-silent keine Verzögerung und kein Voter nötig Nachteile: atomares Multicasting muss unterstützt werden, Prozesse müssen replikationsdeterministisch sein, Unterbrechungen sehr schwer zu handhaben, hoher Rechenaufwand 22 / 36

23 (2) : Vorteile: Unterbrechungen problemlos, einfache Kommunikation, Prozesse müssen nicht deterministisch sein, kein Voter nötig, geringer Rechenaufwand Nachteile: Knoten zwingend fail-silent, Verzögerung im Fehlerfall, Kommunikations- Overhead durch Checkpoint-Erstellung 23 / 36

24 (3) : Vorteile: kein Voter nötig, weniger Overhead als passive Replikation, Unterbrechungen kein Problem, nicht-deterministische Prozesse möglich Nachteile: Verzögerung beim Ausfall des Leaders, Knoten zwingend fail-silent, hoher Rechenaufwand trotz zusätzlicher Kommunikation 24 / 36

25 Recovery-Blocks N-Version-Programming Überblick Einführung Recovery-Blocks N-Version-Programming 25 / 36

26 Recovery-Blocks N-Version-Programming Recovery-Blocks (1) Prinzip: unabhängige Entwicklung mehrerer Alternativen nach gleicher Spezifikation Akzeptanztest, der Korrektheit der Ergebnisse prüft Ausführen der Alternativen nacheinander, bis Ergebnis Akzeptanztest besteht 26 / 36

27 Recovery-Blocks N-Version-Programming Recovery-Blocks (2) Recoverypoint erstellen Recovery Block Alternative 1 Alternative 2 Alternative 3 Recovery Akzeptanztest Nicht akzeptiert Fehler OK 27 / 36

28 Recovery-Blocks N-Version-Programming Recovery-Blocks (3) Problem: Alternative, die Nachrichten an andere gesendet hat, schlägt fehl verschickte Nachrichten sind ungültig, also alle Konsumenten fehlgeschlagen Konsumenten müssen identifiziert werden 28 / 36

29 Recovery-Blocks N-Version-Programming Recovery-Blocks (4) Mögliche Maßnahmen: Keine Inter-Prozess-Kommunikation in Recovery- Blocks zu restriktiv Verwendung von Dialogen 29 / 36

30 Recovery-Blocks N-Version-Programming Recovery-Blocks (5) Dialoge: enthalten Prozesse und Datenstrukturen ermöglichen Kommunikation ohne Recovery zu beeinträchtigen falls Alternative fehlschlägt werden betroffene Prozesse auch wiederhergestellt terminiert, wenn alle enthaltenen Prozesse erfolgreich 30 / 36

31 Recovery-Blocks N-Version-Programming N-Version-Programming (1) Prinzip: unabhängige Entwicklung mehrerer Alternativen nach gleicher Spezifikation Ausführung aller Alternativen nebenläufig Schiedsrichter konstruiert endgültiges Ergebnis aus allen Einzelergebnissen 31 / 36

32 Recovery-Blocks N-Version-Programming N-Version-Programming (2) N Version Module Alternative 1 Alternative 2 Alternative 3 Schiedsrichter 32 / 36

33 Recovery-Blocks N-Version-Programming N-Version-Programming (3) Problem: Verhalten nach Fehlschlagen einer Version Falls Modul zustandslos: kein Problem sonst: Modul in inkonsistentem Zustand 33 / 36

34 Recovery-Blocks N-Version-Programming N-Version-Programming (4) Maßnahmen: Klonen der fehlgeschlagenen Version Wiederherstellung des Zustands durch Untersuchung anderer Komponenten durch Abfrage bei anderen Versionen, dann Standard-Repräsentation des Zustands nötig 34 / 36

35 Recovery-Blocks N-Version-Programming Gibt es noch Fragen? 35 / 36

36 Recovery-Blocks N-Version-Programming Literaturverzeichnis Barret P. A., Speirs N. A. 1993: Towards an integrated approach to fault tolerance in Delta-4, IEE Distributed Systems Engineering, Volume 1, Issue 2, pp 59-66, IOP Publishing Ltd. Kopetz H., Bauer G. 2003: The Time-Triggered Architecture Proceedings of the IEEE, Special Issue on Modeling and Design of Embedded Software, pp / 36