Fehlertoleranz

- Fehlertoleranz -
Ausarbeitung im Rahmen des Seminars
Pleiten, Pech und Pannen der Informatik
von Herrn Jürgen Ruf und Herrn Thomas Kropf
im WS01/02
Christian Teufel
Urbansbrüderstr. 3
72108 Rottenburg
Studienfach: Informatik
Semester: 9
-1-
Inhaltsverzeichnis
1
1. Einführung
2
1.1 The Patriot Missile Failure
2
1.2 Einsatzorte fehlertoleranter Systeme
4
2. Fehler
5
2.1. Die Grundbegriffe fault, error und failure
5
2.2. Klassifzierung
5
2.3. Umgang mit Fehlern
6
3. Fehlertoleranz
3.1. Fehlerbehandlung
7
7
3.1.1. Rückwärtsfehlerbehebung
7
3.1.2. Vorwärtsfehlerbehebung
8
3.2. Fehlerkompensation
8
3.3. Redundanz
8
4. Techniken der Fehlertoleranz
4.1. Hardware
9
10
4.1.1. Triple Modular Redundancy (TMR)
10
4.1.2. Reservekomponenten
10
4.1.3. Selbstprüfende Paare
11
4.2. Software
12
4.2.1. Recovery Blocks
12
4.2.2. N-Version Programming
13
5. Fazit
14
Literaturverzeichnis
15
-2-
1
Einführung
Rechensysteme haben im Zuge der Technisierung und Automatisierung heutzutage beinahe in
allen Bereiche n des Lebens Einzug gefunden. Vielfach ist das Arbeiten bzw. Leben ohne sie
nicht mehr vorstellbar. Umso schlimmer ist die Situation, wenn ein Rechensystem
unvorhergesehen ausfällt. Dies kann großen materiellen, insbesondere finanziellen Schaden
zur Folge haben, aber auch Menschenleben fordern. Ziel der Fehlertoleranz ist es somit,
Rechensysteme tolerant gegenüber jeglicher Art von auftretenden Fehlern zu machen. Ideal
ist dabei die Fortsetzung der spezifizierten Leistungen, die das Rechensystem zu erbringen
hat, oder wenigstens der Übergang in einen sicheren Zustand.
Angesichts immer komplexer werdender Systeme und Anwendungen erweist sich dies jedoch
als äußerst schwierig. Schließlich sollte eine mögliche fehlerverursachende Quelle schon
während des Systementwurfs bekannt sein, um sie später erfolgreich tolerieren zu können. Es
wird somit wohl nie ein hundertprozentig fehleretolerantes System geben.
1.1
The Patriot Missile Failure
Ein Beispiel für das Versagen eines Rechensystems und dem daraus resultierenden Verlust
von Menschenleben fand am 25. Februar 1991 während des Golfkrieges statt. Durch das
Versagen einer amerikanische n Patriot Raketen Stellung in Dharan konnte eine sich nähernde
irakische Scud Rakete nicht abgefangen werden (siehe Abb. 1 Seite 2).
Abbildung 1
Die Scud schlug kurze Zeit später in eine amerikanische Kaserne ein, tötete 28 Menschen
sofort und verwundete weitere 100. Tragischerweise führte ein Rundungsfehler zu einer
ungenauen Berechnung der Zeit seit Beginn des Systemstarts.
-3-
Das Radarsystem der Patriot Raketenstellung tastet den Luftbereich über sich ab (s. Abb. 2, S.
3). Nachdem ein Objekt entdeckt wurde, wird dessen voraussichtlicher Kurs auf Grundlage
von charakteristischen Flugeigenschaften berechnet. Somit wird ein neuer Luftbereich am
Himmel festgelegt, in welchem das Radarsystem erneut nach dem Objekt sucht. Taucht dieses
in dem erwartenden Bereich auf, kann auf das Annähern einer Scud Rakete geschlossen
werden (GAO Report, 1992, S. 2ff).
Abbildung 2
In diesem Fall jedoch wurde ein falscher Luftbereich errechnet und das Abfangen der Scud
Rakete nicht eingeleitet (siehe Abb. 2 Seite 3).
Das Patriot Raketen System zählt die Zeit seit dem Systemstart in zehntel Sekunden. Um aber
eine Darstellung in zehntel Sekunden zu erlangen, muß diese mit 1/10 multipliziert werden.
1/10 hat aber eine nicht endende Binärdarstellung von:
0.0001100110011001100110011001100...
Das zur Berechnung verwendete 24bit Register kürzt die Binärdarstellung auf
0.00011001100110011001100
ab, was zu einem Fehler von ungefähr
9,5*10^(-8)
in Dezimaldarstellung führt. Tatsächlich war die Patriot Raketenstellung über 100 Stunden in
Betrieb, obwohl die Betriebsspezifikation nur 8 Stunden vorsah. Nach dieser langen
Betriebszeit wächst der Fehler jedoch auf
9,5*10^(-8) * 3,6*10^6 = 0,34 sec
an. Die Fluggeschwindigkeit einer Scud Rakete beträgt 6034 km/h und somit ist sie in dieser
Zeit 0,57km weiter als berechnet und außerhalb des „Aufspührsystems“ (Douglas, 2000).
Ein Neustart des Systems oder eine effizientere und sinnvollere Implementierung der
Zeitmessung hätte dieses Problem mit Sicherheit verhindert.
-4-
1.2
Einsatzorte fehlertoleranter Systeme
Es ist klar das fehlertolerante System gerade dann zum Einsatz kommen, wenn ein Versagen
des Systems katastrophale Folgen nach sich ziehen kann. Generell ist eine Aufteilung in vier
verschiedene Gebiete denkbar, welche sich aber auch schneiden können.
a) Anwendungen mit extremer Lebensdauer,
z.B. in der Raumfahrt. Hier ist es meist nicht möglich (oder nur unter großen
finaziellen Anstrengungen), ein sich bereits im Orbit befindliches Objekt zu
warten.
b) Sicherheitskritische Anwendungen,
z.B. in der Medizintechnik. Lebenserhaltende Systeme etwa dürfen unter keinen
Umständen den Betrieb ohne jegliche Vorwarnung einstellen oder von ihren
spezifizierten Leistungen abweichen.
c) Verlängerung der Wartungsintervalle,
z.B. bei räumlich weit verteilten Systemen. Hier wird eine zeitlich hohe
Verfügbarkeit vorausgesetzt, da Reperaturmöglichkeiten oder Wartungspausen nur
zu bestimmten Zeitpunkten möglich sind (Görke, 1989, S.17).
d) Hohe Anforderungen an die Verfügbarkeit,
z.B. in der Telekommunikation oder bei großen Buchungssystemen. In diesen
Bereichen kann ein längerer Ausfall beträchtlichen finanziellen Schaden bedeuten.
Es finden sich sicherlich noch viele weitere Beispiele und Anwendungsbereiche, in denen
fehlertolerante Systeme zum Einsatz kommen. Die Hauptziele sind jedoch meistens die
selben, finanziellen Schaden abzuwenden und Menschenleben zu schützen.
2
Fehler
Eine Definition von Fehler lautet, er sei die Abweichung vom Richtigen (Stoll, S.45). Das
Hauptproblem wird hieraus deutlich. Es ist sehr schwer ein Verfahren oder einen Algorithmus
zu finden, der zu jeder Zeit eindeutig entscheiden kann, was richtig und was falsch ist. Um
fehlertolerante Systeme zu entwerfen, zwingt sich somit eine tiefere Begriffseinteilung und
Klassifizierung auf.
-5-
2.1
Die Grundbegriffe fault, error und failure
Im Vergleich mit der englischen Sprache sind die Begriffe in der deutschen Sprache nicht
deckungsgleich. Fault und error sind streng genommen mit Fehler zu übersetzen (Görke,
1989, S.28). Diese Einteilung kennt aber keinen Unterschied zwischen der Fehlerursache und
deren Auswirkungen.
Fault bezeichnet die Fehlerursache bzw. den Grund, der ein System in einen inkorrekten
Zustand überführt. Dies kann z.B. ein Designfehler oder ein inkorrekter Algorithmus sein.
Die Fehlerursache kann nun zu einem error, der Fehlerauswirkung oder dem Fehlerzustand,
führen. Der error bezeichnet eine lokalisierbare Auswirkung im Systemzustand und hat z.B.
falsche Werte in Variablen zur Folge.
Im schlimmsten Fall folgt auf einen Fehlerzustand das Systemversagen, ein failure. Hierbei
handelt es sich um eine sichtbare Abweichung vom normalen und spezifizierten Verhalten des
Systems, welche nicht selten in großen Unglücken endet.
Die Fehlertoleranz versucht die hier aufgezeigte Kausalität zwischen fault - error und error failure zu unterbinden.
2.2
Klassifizierung
Es ist schwer, Verfahren und Methoden zu entwickeln, die Fehler und ihre Auswirkungen
tolerieren bzw. verhindern sollen. Eine Klassifizierung des Begriffs Fehlers scheint sinnvoll
und hierfür bieten sich folgende Frage n an:
a)
Warum wurde er gemacht?
Zufällig, absichtlich, ... .
b)
Wann gerät er in das System?
Entwicklungszeit, Laufzeit.
c)
Worin liegt sein Ursprung?
Logischer Fehler, physikalischer Fehler.
d)
Wie lange dauert seine Wirkung an?
Permanent, temporär, ... .
e)
Was sind seine Auswirkungen?
Leicht, schwer, (un-)kritisch, ... .
f)
Wo ist er lokalisiert?
Intern, extern, lokal, verteilt, ... .
g)
Wer hat hat ihn gemacht?
Mensch (Bediener, Entwickler),
physikalische Umwelt.
-6-
2.3
Umgang mit Fehlern
Grundsätzlich muß man zwischen dem Umgang mit Fehlern zur Entwicklungszeit und zur
Laufzeit unterscheiden. Man spricht von Fehlervermeidung (fault avoidance) in der
Entwicklungszeit und von Fehlertoleranz (fault tolerance) während der Laufzeit.
Fehlervermeidung kann durch formale Methoden, Software Engeneering, Reviews, Testen,
Lokalisierung, Analyse, Behebung und viele weitere Techniken verwirklicht werden.
Fehlertoleranz zur Laufzeit wird hingegen durch Fehlerentdeckung, Fehlerlokalisierung,
Fehlermeldung und Fehlerbehandlung erreicht. Eine Unterscheidung zwischen Fehlerentdeckung und Fehlerlokalisierung ist wichtig. Es muß nach der Entdeckung der
Auswirkungen eines Fehlers, dessen genauer Ursprung im System, seine Quelle also,
lokalisiert werden, um ihn später erfolgreich behandeln zu können. Nach der Fehlererkennung
und Fehlermeldung müssen nun Techniken zur Fehlerbehebung genutzt werden. Das Ziel
dieser Techniken ist es, den derzeitigen fehlerhaften Systemzustand in einen wohldefinierten
und fehlerfreien Zustand zu transformieren, von dem aus die normalen Systemoperationen
fortgeführt werden. Ohne solch eine Transformation würde wohl ein Versagen des Systems
folgen. Daher ist die Fehlerbehandlung einer der wichtigs ten Aspekte der Fehlertoleranz
(Anderson, 1981, S. 65).
3
Fehlertoleranz
Fehlertoleranz bezeichnet die Fähigkeit eines Systems, auch mit einer begrenzten Anzahl
fehlerhafter Komponenten seine spezifizierte Funktion zu erfüllen (Echtle, 1990, S.9).
Großen
Anteil
am
Erlangen
dieser
Fähigkeit
haben
die
Fehlerbehandlung,
Fehlerkompensation und Redundanz.
3.1
Fehlerbehandlung
Die Fehlerbehandlung beläßt fehlerhafte Komponenten im System und überführt deren
Fehlzustand in einen fehlerfreien Zustand (Echtle, 1990, S.14). Dies kann auf zwei
-7-
verschiedene
Weisen
erreicht
werden,
durch Rückwärtsfehlerbehebung
und
durch
Vorwärtsfehlerbehebung.
3.1.1 Rückwärtsfehlerbehebung
Bei der Rückwärtsfehlerbehebung werden Techniken angewandt, die einen vorherigen
Systemzustand, mit der Hoffnung dass dieser fehlerfrei ist, wiederherstellen. Hierbei wird der
jetzige Zustand nicht berücksichtigt. Dies setzt natürlich die Existenz von Rücksetzpunkten
voraus.
Merkmale:
-
Unabhängig von Schadensbewertung.
-
In der Lage beliebige Fehler zu beheben.
-
Anwendbar als ein allgemeines Konzept für alle Systeme und somit leicht als
Mechanismus verfügbar.
3.1.2 Vorwärtsfehlerbehebung
Die Vorwärtsfehlerbehebung strebt Techniken an, die einen Teil des jetzigen Zustands
manipulieren, um einen neuen Zustand zu generieren. Die Hoffnung hierbei ist das der
gewonnene Systemzustand fehlerfrei sein wird.
Merkmale:
-
Ungeeignet für unvorhersehbare Fehler.
-
Hängt von Schadensbewertung- und Vorhersage ab.
-
Muss für jedes System speziell entworfen werden und ist somit unmöglich als
allgemeines Konzept implementierbar.
3.2
Fehlerkompensation
Im Gegensatz zur Fehlerbehebung verändert die Fehlerkompensation nur das Ergebnis
fehlerhafter Komponenten. Durch diese Kompensierungsmaßnahmen werden ne gative
Fehlerfolgen verhindert (Echtle, 1990, S. 14).
-8-
Ein Verfahren zur Fehlerkompensierung ist die Fehlermaskierung. Sie läßt sozusagen durch
eine „Maske“ nur die Ergebnisse durch, die fehlerfrei sind. Um dies zu bewerkstelligen wird
Informationsredundanz (s. 3.3, S. 9) benötigt, mit deren Hilfe n-von-m-Systeme erschaffen
werden (s. 4.1.1, S. 9).
Merkmale:
-
Reicht als einziges Fehlertoleranzverfahren aus.
-
Maskierer sind vergleic hsweise leicht zu verwirklichen.
-
Sehr schnell, da Wiederholungsbetrieb entfällt.
-
Sehr teurer, da ein hoher Aufwand an Redundanz benötigt wird.
3.3
Redundanz
Redundanz ist ein Teil des Systems, der bei Fehlerfreiheit nicht notwendig wäre.
Es gibt verschiedene Arten von Redundanz, die in kombinierter Form auftreten können:
§
Strukturelle Redundanz
Vervielfältigung von Komponenten baugleicher oder alternativer Art.
§
Zeitliche Redundanz
Zusätzliche Zeit für wiederholte Ausführungen wird ermöglicht.
§
Funktionale Redundanz
Das System wird um zusätzliche für den Nutzbetrieb entbehrliche Komponenten
erweitert.
§
Informations Redundanz
Zur Nutzinformation zusätzliche Information, wie z.B. Prüfbits.
Redundante Mittel können im Normal- oder erst im Ausnahmebetrieb aktiviert werden
(Echtle, 1990, S. 61). Tragen sie zum Normalbetrieb bei, spricht man von statischer
Redundanz. Wenn sie aber erst im Ausnahmebetrieb zur Systemfunktion beitragen, spricht
man von dynamischer Redundanz.
-9-
4
Techniken der Fehlertoleranz
Die Charakteristika von Fehlern in Hardware und Software unterscheiden sich meist. So sind
Fehler in der Hardware oft sporadisch, temporär und unabhängig und können z.B. durch
Alterungs- und Verschleissersche inungen hervorgerufen werden. In der Software hingegen
sind die Fehler meist permanent. Hier treten keine Effekte von Alterung und Verschleiß auf.
Eine Replikation von Komponenten in der Hardware ist somit durchaus sinnvoll. In der
Software jedoch wäre die Replikation von identischen Komponenten sinnlos.
Auf Grund dieser Tatsache gibt es verschiedene Ansätze in der Hardware und Software, um
Fehlertoleranz zu verwirklichen.
4.1
Hardware
4.1.1
Triple Modular Redundancy (TMR)
In seiner Standard Form wird das TMR (s. Abb. 3, S.10) benutzt, um Ausfälle in Hardware
Komponenten zu tolerieren.
Abbildung 3
So könnte z.B., um das Versagen einer Systemkomponente zu tolerieren, dieselbe durch
baugleiche Komponenten 1, 2 und 3 und einen Voter, wie in Abbildung 3 dargestellt, ersetzt
werden. Der Voter überprüft die Ergebnisse der drei Komponenten und wählt mit Hilfe eines
Mehrheitsentscheids das richtige Ergebnis aus. Das TMR macht somit von struktuller,
funktionaler und statischer Redundanz Gebrauch. Beim Ausfall von mehr als einer
- 10 -
Komponente versagt dieser Ansatz jedoch. Zwei zufällig falsche Ergebnisse könnten das
Richtige beim Mehrheitsentscheid überstimmen. Desweiteren wird durch Hinzufügen eines
Voter eine neue kritische Komponente in das System aufgenommen.
Eingesetzt wird die TMR z.B. bei Bremsystemen und Triebwerken. Hier arbeiten alle
Replikate aktiv mit.
4.1.2
Reservekomponenten
Typisch
für
dynamische
strukturelle
Redundanz
ist
die
Unterscheidung
in
Primärkomponenten und Reservekomponenten (Echtle, 1990, S.62). Wie in Abbildung 4
Seite 11 dargestellt übernimmt die Reservekomponente 2 nach einem Versagen der
Primärkomponente 1 den Dienst. Die Fehlererkennungseinheit fault detection veranlaßt
hierbei die Wechseleinheit switch auf die Reservekomponente 2 umzuschalten.
Wird die Reservekomponente ständig aktualisiert, d.h sie ist auf dem gleichen Stand wie die
Primärkomponente, spricht man von einer „heißen Reserve“. Die Komponenten der „kalten
Reserve“ hingegen sind meist bis zu ihrer Aktivierung ausgeschaltet.
Abbildung 4
Der
Einsatz
von
Reservekomponenten
setzt
natürlich
die
Existenz
einer
Fehlererkennungseinheit voraus, die in sich wieder eine kritische und teure Komponente sein
kann.
- 11 -
4.1.3
Bei
Selbstprüfende Paare
den
slebstprüfenden
Paaren
wird
die
Hauptkomponente
verdoppelt.
Eine
Vergleichseinheit (s. Abb.5 S. 12) überprüft beide Ergebnisse und kann bei einer
Abweichnung dieser eine entsprechende Fehlermeldung senden. Ein etwas anderer Ansatz ist
in der unteren Hälfte von Abbildung 5 dargestellt. Hier erfolgt die Aus gabe nur, wenn zwei
Vergleichseinheiten dies zu lassen. Deshalb werden selbstprüfende Paare meistens dann
eingesetzt, wenn nach dem Erkennen eines Fehlers in einen sicheren Zustand (fail-safe)
gewechselt, oder eine „sanfte Leistungsminderung“ (gracefull degration, fail-soft) in Kauf
genommen werden kann. Eine Eisenbahn kann z.B. nach der Feststellung eines
systemkritischen Zustands einfach angehalten werden.
Abbildung 5
4.2
Software
4.2.1
Recovery Blocks
Aus Abbildung 6 Seite 13 wird die Funktionsweise von recovery blocks ersichtlich. Bevor in
die erste Software Komponente (Modul) eingetreten wird, muß implizit ein Rücksetzpunkt
etabliert werden. Hat das erste Modul seine Aufgabe erfüllt wird ein Akzeptanztest
durchgeführt. War das gelieferte Resultat richtig, wird aus dem recovery block ausgetreten.
- 12 -
Bei einem Fehler jedoch, muß zu dem zuvor gesetzten Rücksetzpunkt gesprungen werden und
das nächste Modul wird zur Ausführung benutzt (Anderson, 1981, S. 254). Dieses Verfahren
kann nun beliebig oft wiederholt werden.
Voraussetzung für diesen Ansatz ist natürlich die Existenz eines Akzeptanztests, der eventuell
sehr komplexe Ausmaße annehmen kann und die Möglichkeit zum Zurücksetzen. Außerdem
sollten die einzelnen Module verschieden implementiert sein, um den gleic hen Fehler nicht
ständig zu wiederholen.
Abbildung 6
4.2.2
N-Version Programming
Die TMR (s. 4.1.1, S.9) hat sich in der Hardwarefehlertoleranz als effektive Methode bewährt.
Es liegt nahe dieses Konzept nun auch in der Softwarefehlertoleranz anzuwenden. Wie der
Name schon sagt, wird eine Anzahl von n (n>1) unabhängig entwickelten Versionen eines
Programmes gestartet und ihre Ergebnisse verglichen (s. Abb. 7, S.13) (Anderson, 1981, S.
275f). Auf diese Art kann ein fehlerhaftes Ergebnis maskiert werden.
Das n-version programming setzt die Möglichkeit zur effizienten und nebenläufigen
Abarbeitung und Synchronisierung voraus. Außerdem ist die Existenz eines voters nötig. Will
man aber z.B. mehrer verschiedene Lösungen erlauben (Nullstellenberechnung) oder eine
gewisse Ungenauigkeit (Gleitkommaarithmetik) zulassen, wird das Entwerfen eines
geeigneten voters problematisch.
- 13 -
Abbildung 7
5. Fazit
Der Begriff des Fehlers ist im allgemeinen ein sehr vager Begriff und es gibt sehr viele
unterschiedliche Fehlerarten. Deshalb fordert der Umgang mit ihnen eine genau Identifikation
und Beschreibung, damit geeignete Fehlertoleranztechniken während der Entwurfsphase
berücksichtigt werden können. Diese sollten jedoch nur ein zusätzliches Verfahren darstellen
und nicht andere Verfahren zur Konstruktion korrekter Systeme ersetzen. Außerdem erhöhen
Fehlertoleranztechniken die Systemkomplexität und ihre Verwirklichung ist ein nicht zu
unterschätzender Kostenfaktor.
Murphys Gesetz - wenn etwas schiefgehen kann, dann wird es auch schiefgehen (Graf, 1997,
S. 11) - wird wohl nie ganz unterbunden werden können.
- 14 -
Literaturverzeichnis:
Anderson, T., Lee, P.A.: Fault Tolerance – Principles and Practice. Prentice/Hall International
1981.
Arnold, Douglas N. (2000): The Patriot Missile Failure,
[http://www.ima.umn.edu/~arnold/disasters/patriot.html], (Zuletzt geändert: 23.
August2000; Verfügbarkeitsdatum: 6. Februar2002).
Blair, Michael, Obenski, Sally, Bridickas, Paula: GAO/IMTEC-92-26 Patriot Missile
Software Problem, [http://www.fas.org/spp/starwars/gao/im92026.htm],
(Erstelldatum: 4. Februar1992; Verfügbarkeitsdatum: 6. Februar2002).
Klaus, Echtle : Fehlertoleranzverfahren. Springer Verla g 1990.
Görke, W.: Fehlertolerante Rechensysteme. Oldenbourg Verlag 1989.
Graf, Joachim: Murphys gemeinste Computergesetze. Markt&Technik Buch- und SoftwareVerlag GmbH 1997.
Stoll, Jürgen: Fehlertoleranz in verteilten Realzeitsystemen, Springer Verlag o. J.