Fehlertoleranz und Sicherheit

Sergio Montenegro (hhtp://www.first.fhg.de/~sergio)

GMD FIRST (hhtp://www.first.fhg.de)

Von der Störung zum Fehler und Ausfall
bis zum Unfall

Der "normale" Funktionsbereich eines Systems ist ein sehr schmales Band, der Fehlerbereich dagegen der Rest (siehe Abbildung 1).

Die kleinste Störung, wie z.B. ein Alpha-Teilchen (subatomisches Partikel) oder ein Ion trifft eine Speicherzelle und kann einen Fehler verursachen, z.B. ein Speicherbit kippt um. Der Fehler kann einen Ausfall verursachen, beispielsweise wegen eines bit-Kippers im Programmcode verläuft sich die Steuerung und bleibt stehen. Deswegen fällt ein Steuerrechner aus und man kann das Flugzeug nicht mehr lenken - es stürzt ab. Und alles wegen eines subatomischen Partikels!

Ein am Anfang kleiner Fehler oder eine unvorhersehbare Situation kann sofort oder viel später das System in den "Fehlerbereich" bringen. Im Fehlerbereich kann sehr leicht die Kontrolle über die Anlage verloren gehen, besonders, weil es in undefinierten Zuständen arbeitet, für die die Steuerung nicht konzipiert ist. So kann ein Fehler, besonders ein Prozessorkern-Fehler, unvorhersehbare Zustände verursachen, und unvorhersehbare Zustände können wiederum Fehler verursachen. Ein Fehler kann sich erst zu einem viel späteren Zeitpunkt bemerkbar machen. So kann viel Zeit vergehen (Latenzzeit) zwischen dem Eintreten der Störung, dem ersten Fehler und dem Systemausfall (Abbildung 2).

Einige Fehler können ein unkontrolliertes Verhalten verursachen, welches mit einem Unfall enden könnte. Andere Fehler können die Steuerung zum Stillstand bringen, wie z.B. Fehler im Prozessorkern, was auch einen Unfall verursachen kann. Andere Fehler führen zu falschen Ergebnissen oder Handlungen, welche Folgefehler in den Modulen, die diese Daten benutzen, verursachen können. Diese Folgefehler können wiederum Schritte auf den Weg zu einem Unfall sein.

Sowohl Fehler als auch Unvorhersehbares (Anomalien) können Ausfälle und Unfälle verursachen. Der Umgang mit Unvorhersehbarem ist allerdings schwieriger als mit Fehlern, weil es sich hierbei um Ereignisse und Sachen handelt, an die keiner gedacht hat. Schlimmer noch ist die Vorstellung, daß die meist unkreative und dumme Steuerung ganz alleine mit unbekannten Zuständen, die nicht einmal ihr Schöpfer (Ingenieur) kannte, zurechtkommen soll. Dagegen hilft nur "an alles denken" - sagten sie mir, als ich klein war. Was man jedoch machen kann, ist zumindest Klassen von unerwarteten Zuständen zu bilden und eine passende Notreaktion für jede Klasse bereitzuhalten.

Obwohl, scheinbar, die Unfälle durch Komponentenausfall, Entwicklungsfehler, unerwartete Ereignisse oder Bedienungsfehler verursacht werden, haben sie tiefere Grundursachen wie beispielsweise:

Folgende Tabelle zeigt die statistische Verteilung der Ausfallquellen:

 

 

Kritische, aber nicht fehlertolerante Systeme

Fehlertolerante Systeme

Hardware

50%

8%

Software

25%

65%

Umgebung & Komm.

15%

7%

Bedienung

10%

10%

 

Fehlerfortpflanzung

Wenn eine Anomalie (unentdeckter Entwicklungsfehler, Störung, Ausfall oder unerwartete Situation) nicht erkannt wird, kann sie nicht behandelt werden. Noch schlimmer ist es, daß ein unerkannter Fehler sich weiter fortpflanzen kann (wie ein Feuer), so daß weitere übergeordnete Module und/oder andere Module, die Daten der fehlerhaften Module benutzen, sich ebenfalls fehlerhaft verhalten, bis das System ausfällt oder sogar ein Unfall geschieht.

Ein unbehandelter Fehler in einem kleinen Modul (z.B. ein Drucksensor) kann seinen Ausfall bedeuten. Dieser Ausfall verursacht einen Fehler in seinem übergeordneten Modul (z.B. ein regulierter Dampfkessel). Bleibt der Fehler unbehandelt, kann er den Ausfall dieses Moduls verursachen und so weiter, bis die ganze Anlage ausfällt oder ein Unfall geschieht, so wie es in der Abbildung 3 dargestellt wird.

 

Die Fehler pflanzen sich in der Modulhierarchie nicht nur vertikal (aufsteigend) fort, sondern auch horizontal entlang der DatenflußPfade des Systems. Jedes Modul, das ungeachtet falsche Input-Daten benutzt, wird auch falsche Ergebnisse liefern (siehe Abbildung 4).

Auf diesem Weg kann ein einziger Transistorausfall oder ein Programmfehler den Ausfall einer Anlage mit 109 Transistoren und einigen Millionen Lines-of-code und vielen anderen Komponenten verursachen. 109 Transistoren und Millionen Lines-of-code sind bereits üblich, und daß etwas ausfallen wird (gerade dann, wenn man es nicht erwartet), ist so gut wie sicher. Der Ausfall eines Moduls bedeutet nicht, daß es defekt ist. Es reicht, daß eines seiner Submodule einen Fehler verursacht hat. Ein unbehandelter Fehler impliziert auch nicht einen Ausfall und kann unbemerkt bleiben oder sich erst zu einem viel späteren Zeitpunkt bemerkbar machen.

Fehlerbehandlung

Eine Steuerung muß so konstruiert sein, daß sie immer in Bereitschaft ist, um Anomalien und weitere Ausnahmen abzufangen und zu behandeln, so daß keine Gefahr entstehen kann. Die Fehlertoleranzmaßnahmen sorgen dafür, daß das System, trotz Fehler, unbeschwert weiterarbeitet. Dies erfordert einen sehr hohen Entwicklungsaufwand, und oft ist das nicht nötig. Oft reicht es, eine Nothalt-Funktion zu aktivieren, um das System in einen sicheren Halt-Zustand zu bringen. Eine Fehlerbehandlung soll folgendem Schema folgen (siehe Abbildung 5): Fehler tritt ein, Fehler wird erkannt, Fehler wird gemeldet, es werden weitere Folgen des Fehlers verhindert, Fehler wird behandelt (z.B. Fehlertoleranz), Fehler wird behoben (Reparatur), weiterarbeiten.

Nach dem Erkennen muß der Fehler gemeldet werden, um andere Komponenten zu warnen und um eine Reparatur zu veranlassen. Der Fehler muß dann eingegrenzt werden und verhindert werden, daß er sich weiter verbreitet. Man muß feststellen, welche weiteren Module fehlerhafte Daten erhalten haben und sie entsprechend warnen und korrigieren. Danach wird der Fehler behandelt durch Fehlertoleranz-Maßnahmen, Rekonfiguration, sicheres Anhalten, Checkpoint Recovery u.a., und am Ende sollen die ausgefallenen Komponenten im Betrieb (z.B. Kraftwerke) oder bei der nächsten Wartung (z.B. Flugzeuge) repariert werden.

Wenn aber keine geeigneten Maßnahmen für die Fehlerbehandlung bereitliegen, dann ist unser Schicksal dem Zufall überlassen, so wie es in Abbildung 6 dargestellt ist.

 

Wenn wir Glück haben, tritt nach einem Fehler ein Systemausfall (Nichtausführen der vorgesehenen Funktion zur festgesetzten Zeit) ohne weitere Konsequenzen ein. Wenn wir Pech haben, tritt ein Unfall mit eventuell katastrophalen Folgen ein. Danach bleibt nur übrig, Maßnahmen für die Schadensbegrenzung zu ergreifen. Es gibt auch (sporadische) Fehler, die sich nicht bemerkbar machen, und der Betrieb kann ungestört weitergehen. Man darf sich darauf aber nicht verlassen. Beispiel: ein bit-Kipper in einer Speicherzelle, die nicht mehr gelesen oder als nächstes überschrieben wird.

Erkennung und Lokalisierung von Anomalien

In der Regel werden Anomalien erst erkannt, nachdem sie (negative) Folgen oder gar einen Unfall verursacht haben. Dies ist besonders bei Software-, Bedienungs- und Kommunikationsfehlern der Fall. Je später die Anomalie erkannt wird, desto schlimmer werden ihre Folgen sein. Daher ist es ratsam, Redundanz und Prüfmechanismen in allen kritischen Komponenten vorzusehen. Anstrebenswert für eine volle Fehlertoleranz ist, die Fehler zu erkennen und zu behandeln, bevor sie sichtbare Konsequenzen haben.

Ein einziger Schrauben- oder Transistorausfall kann einen gesamten Anlagenausfall verursachen, denn der am Anfang noch kleine Ausfall wird weitere übergeordnete Module befallen. Eine Schraube oder ein Transistor wird nicht den eigenen Ausfall erkennen, melden und behandeln können, das nächste übergeordnete Modul vielleicht auch nicht, aber je tiefer in der Modulhierarchie die Behandlung stattfindet, desto früher kann die Fehlerverbreitung gestoppt werden und desto weicher und effektiver können die Korrekturmaßnahmen sein. Sie können verhindern, daß weitere übergeordnete Module ausfallen und daß wir die Kontrolle über die Anlage verlieren. Bei den übergeordneten Modulen ist es einfacher, eine Anomalie zu erkennen, aber dann kann es schon zu spät sein. Ein Kompromiß zwischen Aufwand (Kosten) und Nutzen muß individuell gefunden werden. Es ist wie bei den Krankheiten: Am Anfang sind sie schwer zu erkennen, aber leicht zu heilen; später sind sie leicht zu erkennen, aber schwer zu heilen.

Manchmal ist es sogar möglich vorauszusehen, daß etwas passieren wird, z.B. weil es nicht mehr zu verhindern ist! In diesen Fällen soll die Behandlung noch vor dem Eintreten des Problems starten (nicht warten bis es geschehen ist), dadurch wird die Behandlung effektiver.

Um einen Fehler zu erkennen, braucht man eine Referenz zum Vergleichen: Was soll sein, was ist möglich, was ist wahrscheinlich, wie soll es passieren usw. Der Vergleich ist meistens ein Vergleich von Bereichen mit einer Toleranz. Besonders bei heterogener Redundanz kann man identische Meßgrößen oder Berechnungsergebnisse nicht erwarten. Dies betrifft nicht nur Werttoleranzen sondern auch Zeitverschiebungen. Verschiedene Komponenten werden auch zu verschiedenen Zeitpunkten reagieren und/oder Ergebnisse liefern. Bei einer zeitdiskreten Bearbeitung (digitale Systeme) muß man noch berücksichtigen, daß verschiedene Werte einige Taktzyklen verschoben sein dürfen. Wird mittels Software verglichen, so kann der Zeitunterschied zwischen dem Lesen von den verschiedenen Sensoren noch größer sein und damit auch ihr Wertunterschied.

Die bisher beschriebene Fehlererkennung funktioniert nur bei den Sensoren und der Steuerung (HW + SW). Fehler bei den Aktuatoren können nur indirekt durch die Sensoren festgestellt werden. Wenn die erwartete Reaktion des Systems, mit einer Zeittoleranz, von den Sensoren nicht registriert wird, deutet dies auf Aktuator- aber auch auf Sensorfehler hin. Die Fehlerlokalisierung muß durch weitere Redundanz und Tests im Betrieb durchgeführt werden, wobei Tests im Betrieb eine riskante Aktion bedeuten können.

Es gibt zwei Möglichkeiten, um Anomalien zu erkennen:
1. Reagierend: auf das Auftreten von gemeldeten Fehlern warten. Ein Modul erkennt den Fehler und meldet ihn an ein Fehlerbehandlungsmodul weiter. Das Fehlerbehandlungsmodul wartet auf Meldungen.
2. Agierend: aktiv nach Fehlern suchen oder versuchen, sie vorauszusagen. Das Fehlerbehandlungsmodul wartet nicht, sondern untersucht periodisch das gesamte System oder Teilsystem unter seiner Verantwortung, um Anomalien zu entdecken und zu behandeln.
Meistens hat man eine Kombination aus beiden Methoden. Einige Fehler werden aus den Umständen erkannt (z.B. der Temperaturregler bekommt zu hohe Werte) und andere werden explizit gesucht (z.B. regelmäßige Durchsuchung des Speichers nach bit-Kippern).

Fehlertoleranz und ähnliches

Ein fehlertolerantes System kann weiter seine normale Funktion erfüllen trotz Fehlern, Ausfällen und Ausnahmen (Anomalien). Das zu erreichen, ist eine schwierige Aufgabe und oft nicht nötig. Bei einem fehlertoleranten System müssen alle Komponenten redundant und voneinander unabhängig sein. 100%ige Fehlertoleranz und Sicherheit sind nicht möglich, und Aufwand und Kosten steigen unbegrenzt, je näher man an die 100%-Grenze kommt. Man hat immer einen Kompromiß zwischen Kosten, Leistung, Transparenz und Fehlertoleranzgrad. Trotzdem wird oft Fehlertoleranz unnötigerweise angewandt, wo andere einfachere Alternativen ausreichen würden. Oft reicht es, dafür zu sorgen, daß das System in einen sicheren stabilen Zustand (z.B. anhalten) gebracht wird, wenn Fehler aufgetreten sind. Danach kann man das System reparieren und weiter-betreiben.

Beispielsweise wird Fehlertoleranz oft zur Steigerung der Systemverfügbarkeit bei nicht sicherheitsrelevanten Systemen eingesetzt, wie bei den großen Datenbankservern. Hierfür würde ein hoch verfügbares System reichen. Solche Systeme maximieren die betriebsbereite Zeit (z.B. Monate) und minimieren die "Recovery" Zeit (z.B. Sekunden), die benötigt wird, um das System nach einem Ausfall wieder betriebsbereit zu machen und die Datenkonsistenz wiederherzustellen. Ein hoch verfügbares System minimiert die Systemausfallzeiten, aber es eliminiert sie nicht vollständig. Systemfehler können sich möglicherweise bemerkbar machen. Bei voll fehlertoleranten Systemen dagegen bleiben alle internen Fehler und Ausfälle für den Benutzer oder die Clients unsichtbar.

Auch wird oft Fehlertoleranz benutzt, um die Sicherheit von sonst gefährlichen Systemen zu garantieren. Hierfür gibt es zwei weniger aufwendige Möglichkeiten:

1) Fehlersicherheit (Fail safe): Das System fährt beim Erkennen von Fehlern oder Ausfällen in einen sicheren stabilen Betriebszustand und hält dort, bis die Ursache behoben oder repariert wird, z.B. kann die Wärmequelle eines Dampfkessels abgeschaltet werden, wenn der innere Druck oder die Temperatur zu hoch oder nicht mehr stellbar sind (Sensorenausfall). Fail safe ist aber nicht möglich, wenn das System keinen sicheren stabilen Zustand zum Halten hat (z.B. ein fliegendes Flugzeug).

2) Sanfte Rückstufung (Fail graceful): Beim Erkennen einer Anomalie arbeitet das System weiter, stellt aber nicht mehr den vollen Umfang seiner Funktionen oder Geschwindigkeit zur Verfügung, bis der Fehler behoben wird, z.B. bei der Eisenbahn - beim Ausfall der Kontrollrechner können alle Züge weiter bis zum nächsten Bahnhof fahren, aber mit Sichtgeschwindigkeit.

Echte Fehlertoleranz

Echte Fehlertoleranz wird benötigt bei Systemen ohne einen stabilen sicheren Zustand, bei denen ein Fehler oder ein Ausfall (Anomalien) tödliche Folgen haben (z.B. fliegende Flugzeuge) oder große Verluste (z.B. Telefonnetzwerke) verursachen kann. Fehlertoleranz wird auch bei Systemen benötigt, bei denen keine Reparaturen möglich sind, wie z.B. bei Satelliten oder Unterwasserstationen.

Ein fehlertolerantes System soll seine Funktion weiter erfüllen, auch bei Fehlern und internen Ausfällen. Es darf Fehler enthalten, aber es darf keine Fehler propagieren oder sichtbar machen. Seine Fehler, Ausfälle oder Störungen dürfen keine externe Wirkung zeigen. Ein großer Teil der Sicherheit hängt von der Fähigkeit des Systems ab, während der Laufzeit solche Anomalien zu entdecken und zu behandeln, bis Hilfe kommt - oder wenn keine Hilfe zu erwarten ist (z.B. Satelliten), dann solange es geht. Die Fehlertoleranz kann in 6 Stufen gestaffelt werden. Nicht nur die Kosten, sondern auch die Geschicklichkeit der Entwickler bestimmen die Fehlertoleranzstufe des Systems:

0: Keine Fehlertoleranz: Das System hat mindestens eine Stelle, deren Versagen den Verlust der kritischen Funktion bewirkt ("Single point of global failure"). Auch wenn andere Stellen sehr gut (z.B. dreifach) gesichert sind, reicht ein Schwachpunkt (Stromanschluß, Aktuatoren wie z.B. nur ein E-Motor), um die Fehlertoleranz zunichte zu machen.

1: Erhalt der kritischen Funktion: Es gibt keine Stelle, deren Versagen den Verlust der kritischen Funktion bewirken kann, auch wenn alle anderen nicht kritischen Funktionen verloren gehen könnten.

2: Degradierung: Die kritische Funktion geht niemals verloren. Die nicht kritische Funktion darf nicht vollständig verloren gehen, sie wird nur degradiert oder begrenzt.

3: Temporale Degradierung: Wie 1 oder 2, aber nur für eine kurze Zeitperiode, während das System sich rekonfiguriert und ein Recovery der verdächtigen Komponenten durchführt. Danach arbeitet das System mit der normalen Funktion weiter. Falls in dieser Periode auch die kritische Funktion ausfällt, handelt es sich nicht um ein fehlertolerantes, sondern um ein hoch verfügbares System.

4: Vollständige Fehlertoleranz: Das System erfüllt seine völlige Funktion trotz vorhandener Fehler und/oder interner Ausfälle für einen begrenzten Zeitraum weiter. Es liefert richtige Ergebnisse zum richtigen Zeitpunkt. Im System darf es keine (mechanische, elektrische, HW oder SW) Stelle geben, deren Versagen äußere Wirkungen verursachen kann (kein "Single point of global failure"). Rekonfiguration und Recovery sind so schnell, daß Anomalien sich nicht bemerkbar machen. Redundante Elemente dürfen keine gemeinsamen Komponenten haben (nicht einmal gemeinsame Steckdose) und müssen physikalisch voneinander entfernt sein. Das System erkennt und schaltet ausgefallene Elemente aus und rekonfiguriert sich selbst, um unter Verwendung von anderen Elementen weiterzuarbeiten, die dieselbe Funktion wie die ausgefallenen haben (Redundanz). So wird eine virtuell fehlerfreie Maschine zur Verfügung gestellt. Das System braucht aber nicht unbestimmt lange weiterarbeiten zu können. Es gibt Zeitpunkte (Wartungspausen oder am Ende des Tages), wo das System heruntergefahren werden darf, um repariert zu werden (z.B. Flugzeuge nach der Landung).

5: Nonstop (continuous availability oder ununterbrochene Verwendbarkeit): Wie die Stufe 4 (aber auch Stufen 1 bis 3 wären denkbar), aber die Reparaturen und der Komponentenaustausch werden im Betrieb durchgeführt, ohne das System anzuhalten oder seine Funktionalität zu beschränken, d.h. es muß trotz Ausfällen unbestimmt lange arbeiten können, wie z.B. Stromnetze und der Vermittlungskern der Telefonzentralen. Das Austauschen von Komponenten während des Betriebs beschränkt sich nicht nur auf Hardware und mechanische Komponenten sondern auch (alle?) Softwaremodule müssen während des Betriebs austauschbar sein. Dies impliziert eine sehr modulare Struktur, so daß die neue Softwareversion geladen wird, während die alte läuft, und dann wird umgeschaltet. Andere Arten von Nonstop-Systemen können nicht repariert werden (z.B. Satelliten). Sie müssen sich umkonfigurieren und mit den noch verfügbaren Komponenten solange arbeiten, wie es noch geht. Meistens erlauben solche Systeme eine Ferndiagnose und das Fernladen von neuer Software, so daß nicht für alle möglichen Situationen die Behandlung im voraus vorbereitet sein muß.

Bisher war die Rede von einer einzigen Ausfallstelle oder Anomalie, aber ein Ausfall kommt selten allein! Es ist zu erwarten, daß mehrere Anomalien eintreten, bevor der Defekt behoben werden kann (wenn überhaupt). Bei einem einzigen internen Ausfall kann ein einfaches fehlertolerantes System weiterarbeiten, aber weitere Ausfälle können sich gefährlich auswirken. Das System ist dann in einem latenten Systemausfall-Zustand, der noch nicht gefährlich ist, aber kombiniert mit weiteren internen Ausfällen in einem Unfall enden kann. Deswegen sollen interne Ausfälle gemeldet und so schnell wie möglich repariert werden, oder Wartungsuntersuchungen müssen regelmäßig so oft durchgeführt werden, daß die Wahrscheinlichkeit für mehrere Ausfälle zwischen zwei Wartungen extrem niedrig ist.

Oft hat man das Glück, daß verschiedene Fehler oder Ausfälle auch in verschiedenen Funktionsmodulen eintreten (z.B. einmal in einem Drucksensor und einmal in einem Speichermodul), dann dürfte ihre Behandlung kein weiteres Problem sein. Schwieriger ist es, wenn mehrere Ausfälle in gleichartigen Funktionsmodulen (z.B. in zwei redundanten Drucksensoren) eintreten. Noch schlimmer ist es, wenn mehre Ausfälle fast gleichzeitig eintreten, so daß die Steuerung nicht erkennen kann, daß mehre Ausfälle stattgefunden haben. Problematisch ist es auch, wenn ein neuer Ausfall eintritt, während die Steuerung ein Recovery und/oder eine Rekonfiguration durchführt. Meistens wird angenommen, daß die Wahrscheinlichkeit für solche Fälle so niedrig ist, daß man sie ignorieren kann. Aber Vorsicht: Solche Vermutungen sind ein Glücksspiel. Einige Ausfälle können Folgeausfälle in anderen Modulen verursachen und Konstruktionsfehler können systematische Kettenausfälle verursachen, z.B. Überspannung, elektromagnetische Störungen, thermische Probleme, oder z.B. wenn zwei redundante Sensoren physikalisch zusammen montiert sind und eine mechanische Beschädigung an dieser Stelle eintritt usw.

Deswegen soll ein sicheres System nicht nur einen, sondern mehrere gleichzeitige interne Ausfälle garantiert tolerieren können. Dies wird als Robustheitsgrad des Systems bezeichnet: Er sagt uns, wie viele interne Fehler das System garantiert tolerieren kann, ohne seine Funktion zu verlieren. Ein nicht fehlertolerantes System hat einen Robustheitsgrad von 0. Ein Robustheitsgrad von 2 bedeutet, daß das System mindestens zwei Fehler oder Ausfälle tolerieren kann. Oft kann man Mischformen haben, z.B. ein System der Stufe 4 (vollständige Fehlertoleranz) kann einen Ausfall tolerieren, ab zwei Ausfällen rutscht es auf Stufe 3, ab drei Ausfällen rutscht es auf Stufe 1 (nur die Aufbewahrung der kritischen Funktion) und ab vier Ausfällen kann man seine Funktion nicht mehr garantieren. Dieses System hätte einen Robustheitsgrad von 1 auf der Stufe 4 und von 3 auf der Stufe 1.

Recovery

Ein voll fehlertolerantes System muß seine Funktion trotz Eintreten einer Anomalie möglichst ohne sichtbare Konsequenzen fortsetzen. Dafür ist eine sofortige automatische Rekonfiguration nötig, wobei die fehlerhaften Komponenten ausmaskiert werden. Wenn eine ausgefallene oder ausgeschaltete Komponente wieder integriert wird, muß ihr Zustand an den des Systems angepaßt werden. Dabei gibt es zwei Möglichkeiten: Backward-Recovery: zurück zum letzten fehlerfreien Zustand und dort fortsetzen, und Fordward-Recovery: einen neuen Zustand finden, von dem ab das System normal weiterarbeiten kann.

Ein Backward-Recovery ist einfacher, aber es ist nur bei den Nicht-Echtzeit-Systemen anwendbar sowie bei denen, die nichts in der physikalischen Welt bewirken (z.B. Datenbankservern, Telefonanlagen). Für ein Backward-Recovery speichert das System einen aktuellen, konsistenten und stabilen Zustand (Checkpoint) so oft wie möglich auf einem sicheren Medium (z.B. 2x Platten). Nach einem Ausfall geht das System zurück zum letzten vollständig abgespeicherten Checkpoint, lädt seinen Zustand und macht ab dieser Stelle weiter. Problematisch wird es bei allen Ausgaben und Nachrichten, die zwischendurch erfolgt sind. Dagegen werden Transaktionsmechanismen eingesetzt. Bei verteilten Systemen hat man drei zusätzliche Probleme: 1. Um einen global konsistenten Checkpoint für alle Prozessoren machen zu können, müssen die Prozessoren sich synchronisieren und warten, bis alle den Synchronisationspunkt erreicht haben. 2. Wenn jeder Prozessor sein eigenes Checkpointing schreibt, kann man sie kaum alle zu einem globalen konsistenten Zustand zurückbringen. 3. Wenn nicht alle Prozessoren zusammen wieder gestartet werden, muß man zurückverfolgen, welche Nachrichten der neu gestartete Prozessor zwischen seinem letzten Checkpoint und seinem Absturz gesendet hat und was die Empfänger damit gemacht haben und eventuell weiter zurückverfolgen. Dies kann zu einem Domino-Effekt werden.

In vielen Fällen ist ein Backward-Recovery nicht möglich, z.B. wenn das System etwas in der physikalischen Welt bewirkt (inklusive Echtzeit). Wir können nicht die Wurstfabrik zurücklaufen lassen und hinten wieder lebendige Schweine herausbringen. Wir können auch nicht die Zeit nach hinten drehen, um etwas zu wiederholen. Was geschehen ist, ist bereits geschehen. In diesen Fällen braucht man Fordward-Recovery. Das System muß den momentanen realen Zustand erfassen und dann versuchen, sich in einen normalen Zustand zu bringen um weiterzuarbeiten. Für ein Fordward-Recovery werden fast immer auch Checkpoints benötigt - der momentane Anlagenzustand allein ist meistens nicht ausreichend. Da hier die Zeit eine zentrale Rolle spielt, muß man ein schnelles Checkpoint-Medium benutzen, wie z.B. mit Batterie gepufferte Speicher (RAM) oder Flash-RAMS. Bei verteilten Systemen und bei solchen, die mehrere Prozessormodule haben, braucht man für ein Recovery nicht unbedingt Checkpoints; der neu gestartete Prozessor kann die aktuellen Informationen aus den anderen (noch laufenden) Prozessoren erfahren.

 

Weitere Referenzen

Mein Buch: Sichere und Fehlertolerante Steuerungen

Viele Referenzen auf Artikel mit jeweils einer Zusammenfassung
http://www.first.fhg.de/~sergio/references.html

Buch: Sichere und fehlertolerante Steuerungen, Sergio Montenegro, 1999
http://www.first.fhg.de/~sergio/buch.html

Verschiedene Publikationen
http://www.first.fhg.de/~sergio/public
(1) Design und Konstruktion von sicherheitsrelevanten Systemen.
Verschiedene Publikationen, Informationen und public domain Software zum Thema Fehlertoleranz, Sicherheit und Echtzeit-Programmierung

Seminar an der Technischen Universität Berlin
http://www.first.fhg.de/~sergio/seminar
(1) Sicherheit, Hazard-Analyse, Fehlertoleranz, Analysen von Unfällen und Entwicklung sicherheitsrelevanter eingebetteter Systeme.

Ariane 5: Flight 501 Failure
http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html
(1) Beispiel eines Unfalls durch Softwarefehler

Fault-Tolerant Distributed Consensus
http://tofu.alt.net/~lk/290.paper/290.paper.html
(1) Probleme und Lösungen bei fehlerhafter Kommunikation

Application of dynamic reconfiguration in the design of fault tolerant production systems. Matos, G.; Proceedings. Fourth International Conference on Configurable Distributed Systems Los Alamitos, CA, USA: IEEE Comput. Soc, 1998.
Praktische Methode für Design von Rekonfiguration in Hardware.

Online system upgrade on CENTUM CS FCSs.: Ito, H.; Nishida, J.; Ohsako, S.; Yajima, H.; Yokogawa Technical Report (English Edition) (June 1998), SICI: 0911-8977(199806)25L.13:OSUC;1-7
Praktisches Beispiel von Konstruktion für online Software-Upgrades.

Monitoring functional integrity in fault tolerant aircraft control computers for critical applications. : Belcastro, C.M, Fischl, R.; Proceedings of the 13th World Congress, International Federation of Automatic Control. Oxford, UK: Pergamon, 1997. ISBN: 0-08-042923-8
Praktische Evaluation von Design für Fehlertoleranz und Integrität von Redundanz.

Fast self-recovering controllers.: Hertwig, A.; Hellebrand, S.; Wunderlich, H.-J.; Proceedings. 16th IEEE VLSI Test Symposium (Cat. No.98TB100231) 1996, Los Alamitos, CA, USA, ISBN: 0-8186-8436-4
Praktisches Beispiel für Konstruktion von Recovery in Hardware.

Simulation of a component-oriented voter library for dependable control applications. : Latif-Shabgahi, G.; Bass, J.M.; Bennett, S. Proceedings. 24th EUROMICRO Conference (Cat. No.98EX204), 1996, Los Alamitos, CA, USA:ISBN: 0-8186-8646-4
Praktisches Beispiel für die Konstruktion von Vergleicher und Redundanz.

An embedded fail-safe interlocking system. Bin Pei; Yinghua Ming. Proceedings. Pacific Rim International Symposium on Fault-Tolerant Systems. Los Alamitos, CA, USA: IEEE Comput. Soc, 1997.
Praktisches Beispiel für die Konstruktion von sicheren Systemen.