Prinzipien der Fehlertoleranz
GMD-FIRST (http://www.first.fhg.de)
Fehlertoleranz wird benötigt bei Systemen, bei denen ein Fehler oder ein Ausfall (Anomalien) tödliche Folgen haben (sicherheitskritische Anwendungen) oder große Verluste verursachen kann. Bei solchen Systemen gibt es nur eins, was noch schlimmer als ein Systemausfall sein kann: das blinde Vertrauen, das System sei sicher. 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 nicht 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, dann solange es geht. Diese Anomalien können unentdeckte Entwicklungsfehler, Störungen, Ausfälle oder unerwartete Situationen sein [Pendel]. Der Systementwickler muß alle möglichen Anomalien vorhersehen [Hazard-Analyse] und für jede eine Behandlung vorprogrammieren, was meistens nicht möglich ist. Ausfälle und Fehler, mit denen zu rechnen ist, dürfen sich nicht gefährlich auswirken. Leider gibt es auch viele Situationen, die keiner vorhersehen kann. Für diese Fälle wäre es ideal, wenn die Steuerung mindestens erkennen könnte, daß etwas nicht stimmt, um etwas zu unternehmen oder um Hilfe zu rufen. Dies ist äußerst schwierig, denn die kreativitätslose Steuerung muß eine Situation erkennen und beherrschen, die nicht einmal ihr Schöpfer (Entwickler) kannte. Ein verläßliches System muß sowohl erwartete (od. befürchtete) Fehler als auch unvorhergesehene Situationen meistern. Hier können wir uns leider nur auf die Fälle konzentrieren, die man vorhersehen und vorprogrammieren kann.
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.
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 unsichbar.
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) [Konzeption].
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.
Fehlertoleranz ist natürlich besser als diese zwei alternativen Techniken, aber aufwendiger. Beim Kompromiß gegen Kosten hat man trotzdem einen Spielraum, so daß die Fehlertoleranz in 6 Stufen gestaffelt werden kann. Nicht nur die Kosten, sondern auch die Geschicklichkeit der Entwickler bestimmen die Fehlertoleranzstufung 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: Wie 1, aber 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 flobal 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 der 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 [Hazard-Analyse] ! 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 3 auf der Stufe 1.
Redundanz
Während der Laufzeit müssen Mittel bereitliegen, um die vorhergesehenen Fehler und Ausfälle zu erkennen und zu maskieren. Dafür wird Redundanz benutzt, aber mit Redundanz allein ist es nicht getan. Dies steigert nur die Komplexität des Systems und das einzige, was sie garantieren kann, ist daher eine höhere Wahrscheinlichkeit, daß etwas ausfallen wird. Dadurch kann man das Gegenteil von dem erreichen, was man wollte. Es darf keine extrem hohe Komplexität in Kauf genommen werden, sie muß immer beherrschbar bleiben, sonst wird das System zu fehleranfällig. Beim Erkennen dieser Tendenz sollte man lieber ein Redesign des Systems vornehmen.
Das Ziel ist, mit minimaler Redundanz höchste Fehlertoleranz zu erreichen. Software allein ohne Hardware-Redundanz kann keine adäquate Sicherheit bieten. Eine Kombination von abgestimmter mechanischer, elektronischer Hardware- und Software-Redundanz ist nötig. Redundanz bedeutet aber nicht unbedingt, alles mehrfach zu haben, z.B. zwei Drucksensoren, drei Steuerrechner, zwei Sicherheitsventile. Man hat fast immer auch eine indirekte (implizite) Redundanz, ohne sich dessen bewußt zu sein. (Dieser Text hat z.B. auch eine gewisse Redundanz, ohne daß Sätze doppelt vorkommen.)
Bei den Sensorendaten können viele Meßgrößen von anderen abgeleitet werden, z.B. wenn das System einen Zeitmesser, einen Geschwindigkeitsmesser und einen Beschleunigungsmesser hat, kann man jede der drei Größen von den anderen zwei ableiten. Diese indirekte Redundanz kann sowohl zur Fehlererkennung dienen, als auch um eine Meßgröße abzuschätzen, falls einer der Sensoren ausgefallen ist. Ohne weitere Redundanz ist es aber oft nicht möglich festzustellen, welcher Wert falsch ist, falls sie nicht übereinstimmen. Man kann aber weitere indirekte Redundanz benutzen, wie z.B. physikalische Eigenschaften, Stellgrößen und Plausibilitätsprüfungen, Wenn beispielsweise der Geschwindigkeitssensor einen physikalisch nicht möglichen Geschwindigkeitssprung meldet, oder wenn Zeit und Beschleunigung mit den Stellgrössen übereinstimmen, aber der Geschwindigkeitssensor etwas anderes meldet, kann man ihn als defekt erkennen. Immer geltende physikalische Eigenschaften können auch ohne Sensor als redundante Mittel benutzt werden. Z.B. kann die Freifall-Geschwindigkeit sehr einfach ohne Sensor geschätzt werden. Meistens hat die Schätzung der Werte mittels indirekter Redundanz einen größeren Fehler als die Toleranz der Sensoren. Hinzu kommt das Problem, daß der Abschätzungsfehler sich akkumulieren kann. So kann man die Geschwindigkeit aus Zeit und Beschleunigung errechnen, aber die Meßfehler der Beschleunigung werden sich bei der Geschwindigkeit akkumulieren und nach einer Weile wird der geschätzte Wert so fehlerbehaftet sein, daß man ihn nicht mehr benutzen kann. Dies passiert immer, wenn der letzte Wert benutzt wird, um den nächsten zu berechnen (z.B. v = v + a*t). (Siehe Abbildung 1.) Anders ist es bei der Abschätzung der Beschleunigung aus Geschwindigkeit und Zeit oder bei der Abschätzung der Geschwindigkeit aus Strecke und Zeit. Hier haben wir auch einen Meßfehler, aber er akkumuliert sich nicht, denn für die Berechnung der gegenwärtigen Beschleunigung wird der alte Wert nicht benutzt (a = (v_new - v_old) / t).
Aktuatoren können auch (indirekt) redundant sein, auch wenn sie nicht dieselbe Funktion haben, z.B. können die Trimming Stellflächen eines Flugzeugs, die seine horizontale Lage stabil halten, durch eine Benzinpumpe teilweise (in der Not) ersetzt werden, indem Benzin von einem Flügel in den anderen gepumpt wird, um das Gewicht zu verlagern und die gewünschte horizontale Lage zu erreichen. So können verschiedene Effekte auf indirektem Wege erreicht werden.
Jedes System hat eine gewisse Redundanz in sich, auch wenn es auf den ersten Blick nicht ersichtlich ist. Diese indirekte Redundanz kann im Notfall eine Rettung sein, aber meistens ist sie nicht ausreichend, um die Sicherheit zu garantieren. Das einfachste (und billigste), um den gewünschten Redundanzgrad zu erreichen, ist die Replikation von Komponenten. Oft werden sie "similare Elemente" und homogene Redundanz genannt. Solche Redundanz erlaubt nur die Erkennung und Behandlung sporadischer Random-Fehler und -Ausfälle. Die systematischen Fehler, wie z.B. Entwicklungsfehler, die sich identisch in allen Replikationen auswirken, würden unerkannt bleiben oder die Behandlung würde nicht effektiv sein. Für diese Fälle ist die homogene Redundanz keine Hilfe, die indirekte Redundanz ist dann effektiver, aber vielleicht nicht ausreichend. Im Gegensatz zur homogenen Redundanz steht die heterogene oder diversitäre Redundanz. Dabei wird angestrebt, die redundanten Module so unterschiedlich wie möglich zu realisieren. Das beste Beispiel dafür ist die indirekte Redundanz. Beispielsweise um den Inhalt in einem großen Öltank zu bestimmen, können einmal ein Drucksensor unten und einmal ein Radar (oder Sonar) oben benutzt werden. (Man muß nur aufpassen, daß bei der Bedienerkonsole beide Werte gleich ausgegeben werden, und nicht einmal in Bar und einmal in Metern [Mensch-Maschine-Kooperation]). Durch die Verwendung von verschiedenen physikalischen Eigenschaften und verschiedenen Entwicklungen wird die Wahrscheinlichkeit, daß ein systematischer Fehler in allen Modulen sich gleich und gleichzeitig auswirkt, extrem niedrig. Dies begrenzt sich nicht auf Mechanik und Hardware. Besonders die redundanten Software-Komponenten sollten heterogen sein, z.B. indem sie von verschiedenen Teams mit verschiedenen Sprachen und Werkzeugen entwickelt werden. Diese redundanten Softwaremodule sollen das gleiche machen, aber nicht auf dieselbe Art und Weise (siehe unten). Die heterogene Redundanz ist sehr aufwendig, aber dadurch kann man sowohl Random- als auch systematische Fehler erkennen und effektiv behandeln.
Jedoch ist auch Redundanz nicht der Schlüssel zur Sicherheit. Es gibt noch viele - teilweise unbekannte - Ereignisse, die der Auslöser für weitere, scheinbar voneinander unabhängige Ereignisse sein können, z.B. ein kräftiger Schlag auf den redundant ausgeführten Steuerrechner. Deswegen ist es lebensnotwendig, dafür zu sorgen, daß kein einziges Ereignis den Ausfall beider (oder mehrerer) gegenseitig redundanter Elemente verursachen kann, z.B. zwei Drucksensoren sollen nicht physikalisch zusammen montiert werden, zwei Steuerrechner sollen nicht an derselben Steckdose angeschlossen werden, zwei Aktuatoren sollen nicht von demselben Steuerrechner gesteuert werden usw.
Fehler, Ausfall und Unfall
Nach dem Eintreten eines Laufzeitfehlers oder nachdem ein Entwicklungsfehler sich bemerkbar gemacht hat, kann ein Ausfall oder sogar ein Unfall eintreten (so wie es in Abbildung 2 dargestellt wird).
Wenn ein Fehler nicht erkannt wird, kann er nicht behandelt werden. Noch schlimmer ist es aber, wenn ein unerkannter Fehler sich weiter fortpflanzt, 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 Drucksensor kann einen Fehler in seinem übergeordneten Modul - einem regulierten Dampfkessel - verursachen. Bleibt der Fehler unbehandelt, kann die ganze Anlage ausfallen oder ein Unfall geschehen, so wie es in Abbildung 3 dargestellt ist.
Die Fehler pflanzen sich in der Modulhierarchie nicht nur vertikal (aufsteigend) fort, sondern auch horizontal entlang der Datenfluß-Pfade des Systems. Jedes Modul, das unbemerkt 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 10^9 Transistoren und einigen Millionen Lines of Code und vielen anderen Komponenten verursachen. 10^9 Transistoren und Millionen Lines of Code sind bereits üblich, und daß etwas ausfallen wird (gerade dann, wenn man es nicht erwartet) oder falsch ist, 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. Er kann unbemerkt bleiben oder sich erst zu einem viel späteren Zeitpunkt bemerkbar machen. So kann viel Zeit vergehen zwischen dem Eintreten der Störung, dem ersten Fehler und dem Systemausfall (Abildung 2).
Fehlerbehandlung
Eine Fehlerbehandlung soll folgendem Schema folgen: (Abbildung 5)
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. (siehe unten), 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 es nur, 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.
Anomalien-Erkennung und -Lokalisierung
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 wie das Feuer. 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. Besonderes 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 Sensor-Fehler hin. Die Fehlerlokalisierung muß durch weitere Redundanz und Tests im Betrieb durchgeführt werden, wobei Tests im Betrieb eine riskante Aktion bedeuten können. (S.u.)
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 wieder aufsetzen, 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 angewandt. 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 aktuellen Informationen aus den anderen (noch laufenden) Prozessoren erfahren.
Weitere Referenzen
Mein Buch: Sichere und Fehlertolerante Steuerungen
