Home - improve
Unser Angebot
Presse-Forum
Veröffentlichungen
Referenzen
Kontakt
Termine
Logo improve

Erhöhung der Zuverlässigkeit von Rechnersystemen (Teil 4 von 4)

Von Klaus Eppele

Fehlererkennung durch Tests

Nicht alle Fehler lassen sich durch die oben aufgezählten Fehlererkennungsverfahren erkennen. Vor allem Fehler, die sich noch nicht auf den laufenden Systembetrieb ausgewirkt haben, bleiben unentdeckt und können nur durch aktive Testzyklen aufgespürt werden.

Ein Test ist eine algorithmische Durchprüfung eines Systems in einem speziellen Testmodus, in dem das System für den sonstigen Gebrauch nicht oder nur beschränkt zur Verfügung steht. Die Reaktion (Testantwort) des Subsystems auf bestimmte Eingabesignale (Testmuster) wird beobachtet, mit gegebenen Sollwerten verglichen und bei einer festgestellten Abweichung ein Fehler gemeldet. Die Gesamtheit der Testmuster, die zur Durchführung eines Tests verwendet wird, nennt man Testmenge. Beträgt die Fehlerüberdeckung bezüglich einer Fehlerklasse eines Testmusters 100 Prozent, so wird der Test als vollständig bezeichnet.

Zweckmäßigerweise wird ein hierarchischer Testablauf vorgesehen. Beginnend auf der Mikroprogrammebene stellt eine Primitiv-Diagnoseroutine, die zum Beispiel in einem redundant vorhandenen Nur-Lese-Speicher abgelegt ist, zunächst einmal fest, inwieweit andere Komponenten des Moduls verfügbar sind. Je nach Ergebnis des Tests werden dann umfangreichere Programme gestartet, die sich der im vorangegangenen Schritt als intakt befundenen Komponenten bedienen. So wird schließlich ein komplettes System in den Test mit einbezogen. Der Testzeitaufwand muß jedoch beschränkt werden, um die geforderten Mindestrechenleistung für Nutzfunktionen zu erhalten.

Bei der Fehlererkennung ist das zu testende System (Testobjekt) von dem System (Testsubjekt) zu unterscheiden, das als test-ausführende Instanz fungiert. Die sich ergebende Testsubjekt-Testobjekt-Realationen aller Tests eines Rechensystems lassen sich graphisch als gerichtete Kanten in einem Testgraphen darstellen.

Man unterscheidet Selbst- und Fremdtests.

Bei einem Selbsttest ist Testsubjekt und Testobjekt identisch. Damit ein System sich selbst bezüglich einer Menge von Fehlern F testen kann, muß es für jeden Fehler aus F mindestens ein Testmuster, das eine gültige Eingabe darstellt, geben, so daß die zugehörige Testantwort keine gültige Kombination von Ausgabesignalen darstellt. Als Beispiel für ein Selbsttestverfahren kann die Ausfallerkennung in dem 1976 auf den Markt gekommenen fehlertoleranten TANDEM T16-System angesehen werden. Das Herzstück der Fehlererkennung ist ein Botschaftensystem und das Kommunikationsmedium ist der aus zwei physikalisch völlig getrennten Bussen bestehende Dynabus. Die gegenseitige Überwachung der Rechnermodule geschieht durch den Austausch von “I am alive”-Nachrichten, die von jedem Modul in zyklischen Abständen an alle anderen Module verschickt werden. Wenn eine solche Botschaft zwei Zyklen ausbleibt oder nicht korrekt ist, tragen die anderen Module das betreffende Modul in einer Tabelle als defekt ein. Dabei wird nicht berücksichtigt, daß auch das Kommunikationsmedium defekt sein kann.

Sind Testsubjekt und Testobjekt nicht idendisch, liegt ein Fremdtest vor. Der Vorteil des Fremdtests gegenüber einem Selbsttest ist der, daß ein in Bezug auf die Fehlerausbreitung ein weitgehend isoliertes System die Aufgabe der Fehlererkennung übernimmt. Gemeinsame Fehlerursachen beider Systeme sind somit unwahrscheinlich. Andererseits wird für einen Selbsttest kein zusätzliches System benötigt, das selbst fehlertolerant sein muß.

Eine Unterscheidung in Selbst- und Fremdtest gestattet keinen Schluß auf die Qualität oder die Quantität der Fehlererfassung.

Die zur Fehlererkennung nötige Überprüfung der Testantwort kann durch einen Soll-Ist-Vergleich, oder bei einer begrenzten Fehleranzahl durch eine Ist-Ist-Vergleich mehrerer Ergebnisse erfolgen. Somit liegen zwei Arten des Testvergleichen vor, der Absolut- und der Relativtest.

  • Ein Absoluttest prüft, ob a priori gegebene Prädikate über die Ergebnisse eines Systems erfüllt sind. Er findet typischerweise Anwendung bei dynamischer Redundanz, da dort im Normalbetrieb nur vom Primär-, nicht aber vom Ersatzsystem, Ergebnisse zur Verfügung stehen. Nur die Fehler, die ein gegebenes Prädikat über die Ergebnisse verletzt, können durch einen Absoluttest erkannt werden. Ein Prädikat, das alle zu entdeckenden Fehler umfasst, ist meistens schwierig zu finden und bedarf großer Laufzeiten der Tests.
  • Ein Relativtest vergleicht Ergebnisse miteinander, die während des Betriebs von verschiedenen Systemen oder durch verschiedene Berechnungen erzeugt wurden. Er wird bei Vorhandensein von statischer Redundanz eingesetzt. Fehler, die sich in gleicher Weise auf alle Systeme auswirken, werden nicht gefunden. Die Fehlerüberdeckungen von Absolut- und Relativtest  weichen je nach Fehlerart voneinander ab und die vorgegebene Menge der zu tolerierenden Fehler entscheidet, welche der beiden Testarten anzuwenden ist, oder ob sogar beide Verfahren gleichzeitig eingesetzt werden sollen.

Im folgenden werden Testmuster für ein paralleles Bussystem entwickelt, die Ständig-0/1-Fehler, Leitungsunterbrechungen und Überbrückungsfehler erkennen soll. Bei der Konstruktion des Tests wird aus Platzgründen ein Bus mit nur vier Busleitungen zugrundegelegt. Zur Durchführung des Tests sind neben dem Bussystem selbst zwei weitere Funktionseinheiten nötig; eine Einheit, die die Testmuster an einem Busende auf die Busleitungen gibt und eine Einheit, die die übertragenen Signale am anderen Busende detektiert und auswertet. Werden die Testmuster in einer bestimmten Reihenfolge auf den Bus gegeben und sind der detektierenden Einheit die Testmuster und deren Reihenfolge bekannt, so kann ein Absoluttest erfolgen. Ist ein zweiter redundanter Bus vorhanden, über den die Testvektoren gleichzeitig übertragen werden, so daß die detektierende Einheit beide Übertragungen erhält und miteinander vergleichen kann, so liegt die Anordnung für ein Relativtest vor. Folgende Schritte sind nun zur Testgenerierung auszuführen :

Zuerst wird eine Ausfallmatrix erstellt. Bild 3-23 zeigt, welche Auswirkungen die verschiedenen Fehler auf die einzelnen Eingabekombinationen haben. Dabei steht “Bruch x” für Unterbrechung der Leitung x, “Sax y” für Stuck-at-x auf Leitung y, “UÜ x/y” für Und-Überbrückung zwischen Leitung x und Leitung y und “OÜ” für Oder-Überbrückung. Die Leitungen sind in der Reihenfolge 4/3/2/1 durchnummeriert.

Bild 3-23: Ausfallmatrix für ein Bussystem mit vier Leitungen

Man versucht, diese Matrix so weit als möglich zu vereinfachen. Dazu werden zuerst die Zeilen gestrichen, die identisch der Eingabezeile sind, da die zugehörigen Fehler durch den Test nicht erkannt werden können und auch nicht unbedingt erkannt werden müssen. Im vorliegenden Beispiel kann man zu jedem Fehler eine Eingangsbelegung finden, die durch den Fehler verfälscht wird, so daß alle aufgeführten Fehler erkannt werden müssen und keine Zeile gestrichen werden kann.

Danach streicht man alle redundanten Zeilen. In obigem Schaubild sind die Zeilen öBruch xö und öSa1 xö identisch, was dazu führt, daß man zum Beispiel die ersten vier Zeilen streichen kann. Die Gleichheit der Zeilen bedeutet, daß ein beliebiges Testmuster sowohl durch einen Bruch der Leitung x, als auch durch einen Stuck-at-1-Fehler der Leitung x in gleicher Weise verfälscht wird. Beide Fehler sind zwar durch einen Test zu erkennen, die Testantwort läßt jedoch nicht auf die Art des Fehlers schließen. Diese muß über weitere Diagnosemaßnahmen festgestellt werden.

Um die notwendigen Testmuster besser zu finden werden alle Testantworten, die vom zugehörigen Testmuster abweichen gekennzeichnet (in Bild 3-12 mit ö*ö). Haben mehrere Testmuster die gleiche Wirkung, erkennen sie also genau dieselben Fehler, können die zugehörigen Spalten bis auf eine gestrichen werden. In der verbleibenden Matrix sucht man nach einer möglichst kleinen Testmenge. Man untersucht hierzu zuerst, ob durch Kombinationen der Testmuster mit der größten Wirksamkeit eine vollständige Testmenge erhalten werden kann. Ist dies nicht möglich, weil beispielsweise ein bestimmter Fehler nur von einem Testmuster mit niedirger Wirksamkeit erkannt wird, so muß dieses Testmuster mit in die Testmenge aufgenommen werden.

Im vorliegenden Beispiel erkennt die Testmenge (1100,1010,0101) sämtliche aufgeführten Fehler. Da man für jeden Fehler eine andere Testantwort erhält, kann sogar die Fehlerart bestimmt werden (bis auf die bereits erwähnte Nichtunterscheidbarkeit von Unterbrechung und Ständig-1). Laut /ThaAbr80/ stellen diese Testmuster eine optimale Testmenge dar, die man mit folgendem Algorithmus für eine beliebige Anzahl n von Busleitungen erhält.

Die obere Hälfte des ersten Testmusters besteht aus Einsen, die unteres aus Nullen. Das nächste Testmuster erhält man, indem die Anzahl der identischen Bits des Testmusters aus dem vorherigen Schritt halbiert und die untere Hälfte jeweils invertiert wird. Dies wird solange wiederholt, solange noch identische Werte Werte in benachbarten Bitstellen stehen. Das letzte Testmuster erhält man durch Invertieren des Testmusters aus dem vorherigen Schritt.

Die Anzahl der nötigen Testmuster ergibt sich in Abhängigkeit von der Wortbreite zu (ld n)+1. 

Weitere Möglichkeiten zur Testgenerierung für beliebige Schaltnetze, die in der Regel weniger Aufwand bedeuten, sind die Pfadsensibilisierung, die Methode der Booleschen Differenz oder der D-Algorithmus, bei denen nicht von den möglichen Fehlern auf die Testantworten geschlossen wird (induktive Vorgehensweise), sondern überprüft wird, welche Fehler sich in einem gegebenen Ausgangssignal erkennen lassen (deduktive Methode).

3.2.1.6 Abschließende Bemerkungen

In den letzten Abschnitten wurden mehrere Möglichkeiten der Fehlererkennung besprochen. Welche der Methoden in einem konkreten Fall anzuwenden ist, ist von mehreren Faktoren abhängig.

1. Fehlermodell

Jede systematische Prüfung, ob in einem System ein Fehlzustand vorliegt, beruht auf Annahmen darüber, welche Fehlzustände für möglich gehalten werden. Die möglichen Fehlzustände, die sich negativ auf das Systemverhalten auswirken und deshalb erkannt werden müssen, werden in einem Fehlermodell beschrieben. Die Wahl des Fehlererkennungsverfahrens ist direkt vom Fehlermodell abhängig. Beispielsweise würde sich im Beispiel aus Abschnitt 3.1.2.5 eine andere optimale Testmenge ergeben, wenn auf den Busleitungen nur ein Ständig-0-Fehler auftreten könnte. Die optimale Testmenge würde dann nur aus dem einen Testmuster (1111) bestehen.

Damit man möglichst einfache Fehlererkennungverfahren einsetzen kann, berücksichtigt man die Fehler, deren Auftreten nicht sehr wahrscheinlich ist, nicht im Fehlermodell. Erfolgt beispielsweise in einem Bussystem die Busansteuerung nur mit open-Collector-Treibern, so führt ein Fehlerfall vorwiegend zu einem Low-Pegel auf einer Busleitung und vom Modul verursachte Ständig-1-Fehler können bei der Fehlererkennung vernachlässigt werden.

2. Kosten/Nutzen-Relation

Wenn man beliebig großen Aufwand zur Fehlererkennung treiben kann, ist in den meisten Fällen eine vollständige Fehlerüberdeckung zu erreichen. Da aber in allen Fällen nicht beliebig viele redundante Mittel zur Verfügung gestellt werden können, muß ein Kompromiß gefunden werden zwischen den Kosten für die Fehlererkennung, die sich durch zusätzliche Systemkomponenten oder zusätzliche Verarbeitungszeit ergeben kann, und der erreichbaren Fehlerüberdeckung. In vielen Fällen bietet sich als optimale Lösung dieses Problems eine Kombination verschiedener Fehlererkennungsverfahren an.

3. Unterstützung durch das Rechensystem

Die vorgestellten Fehlererkennungsverfahren lassen Unterschiede hinsichtlich ihrer Abhängigkeit vom zu überwachenden Rechensystem erkennen. So können die physikalischen Verfahren leicht in beliebigen Systemen, oft auch nachträglich, implementiert werden, während beispielsweise Konsistenzüberprüfungen einer an das jeweilige System angepassten Implementierung bedürfen. Die höchste Fehlerüberdeckung ist erreichbar, wenn das Betriebssystem des Systems die Fehlererkennung sogar unterstützt, also das Rechensystem selbst um Funktionen zur Fehlererkennung erweitert wird.

In jedem Fall ist der Einsatz von Fehlertoleranzverfahren nur dann zu vertreten, wenn die Korrektheit des Verfahrens nachgewiesen werden kann und in sicherheitskritischen Bereichen die Korrektheit der gegen mögliche Fehler ergriffenen Maßnahmen gegenüber Genehmigungsinstanzen nachweisbar ist. Eine Verifikation durch eine vollständige Überprüfung ist wegen der Komplexität moderner Schaltkreise nicht immer möglich. In diesen Fällen wird viel Mühe auf die korrekte Spezifikation der Fehlererkennungsverfahren gelegt und daraus abgeleitet, daß die geforderten Funktionen fehlerfrei erbracht werden können. Eine gewisse Restfehlerwahrscheinlichkeit bleibt jedoch in jedem Fall erhalten.

Alle Verfahren sind nur funktionsfähig, wenn bestimmte Funktionseinheiten, wie die En- und Decodiereinrichtungen bei Verwendung redundanter Codes, oder die Voter bei der Methode der Verdopplung und Vergleich, fehlerfrei arbeiten. Dem Entwurf dieser Einheiten, muß eine besondere Sorgfalt zukommen. Sie sollten selbsttestend und fehlersicher sein. Zumindest sollten sie so konstruiert sein, daß sie bei einem Ausfall das System in einen sicheren Zustand versetzen (fail-safe).

Einige der genannten Verfahren haben neben der Fähigkeit zur Fehlererkennung auch noch andere Qualifikationen. So kann ein redundanter Code, der einen Hamming-Abstand von mindestens d=3 aufweist selbständig Fehler korrigieren, oder ein Test kann so ausgelegt sein, daß er Informationen über die Art des erkannten Fehlers oder sogar über die Fehlerquelle liefert. Für andere Fehlererkennungsverfahren muß nach der Fehlererkennung ein gesonderter Prozeß für die Behandlung des Fehlers gestartet werden. Einige Verfahren der Fehlerbehandlung werden im nächsten Abschnitt besprochen.

3.2.2 Fehlerbehandlung

Nachdem ein Fehler erkannt ist, müssen fehlertolerante Rechensysteme eine Fehlerbehandlung durchführen, nach deren Abschluß alle noch benutzten Subsysteme wieder fehlerfrei sind. Zwei Wege führen zu diesem Ziel:

  • Ein fehlerhaftes Subsystem kann in einen fehlerfreien Zustand zurückgeführt werden oder
  • ein fehlerhaftes Subsystem kann durch ein fehlerfreies ersetzt werden.

Herstellung eines fehlerfreien Zustandes

Es bieten sich zwei grundsätzlich verschiedene Alternativen an, um nach dem Auftreten eines Fehlers zu einem fehlerfreien Zustand eines Subsystems zu gelangen: die Fehlerkompensierung und die Fehlerbehebung.

Die Fehlerkompensierung bewahrt die Fehlerfreiheit eines Systems nach außen, wenn auch einzelne Subsysteme fehlerhaft sind. Fehlerhafte Komponenten liefern fehlerhafte Ergebnisse an eine zusätzliche Komponenten, den Kompensierer, der die Aufgabe hat, aus den gelieferten Ergebnissen ein fehlerfreies Gesamtergebnis zu berechnen. Dabei kann diese Berechnung zu einer Korrektur oder zu einer Maskieirung der falschen Ergebnisse eingesetzt werden.

Bei einer Fehlerkorrektur wird ein fehlerhaftes Ergebnis auf ein fehlerfreies eindeutig zurückgeführt. Die Fehlerkorrektur kann zum Beispiel bei redundanten Codes angewendet werden,  die soviel Informationsredundanz beinhalten, daß eine gewisse Anzahl von Fehlern korrigiert werden kann (siehe auch Teile 1 und 2). Die Fehlermaskierung wird bei Vorhandensein statischer Redundanz eingesetzt. Der Kompensierer, hier auch Voter genannt, erhält die Ergebnisse mehrerer Subsysteme, vergleicht diese miteinander und fällt im Fehlerfall eine Mehrheitsentscheidung. Die Fehlerbehebung dagegen überführt  das  fehlerhafte Subsystem selbst in einen fehlerfreien Zustand. Auch hier lassen sich wieder zwei Möglichkeiten angeben: die Rückwärts- und die Vorwärtsbehebung.

Bei der Rückwärtsbehebung werden im Fehlerfall Subsysteme in einen Zustand zurückversetzt, den sie bereits in der Vergangenheit angenommen hatten oder hätten annehmen können. Damit dies möglich ist, müssen schon während des normalen Betriebs regelmäßig Rücksetzpunkte (Checkpoints) angelegt werden, bei denen die Subsysteme Zustandsinformationen in Form von Variableninhalten als Rücksetzinformation abspeichern. Damit diese Informationen im Fehlerfall nicht verlorengehen, sollten sie an einer vom entsprechenden Subsystem physikalisch getrennten Stelle, etwa in einem anderen Rechensystem, abgespeichert werden. Da Interprozeßkommunikation Abhängigkeiten zwischen Zuständen verschiedener Prozesse schafft, sind gegebenenfalls auch fehlerfrei gebliebene Prozesse zurückzusetzen, wodurch ein beträchtlicher Zusatzaufwand entstehen kann. Um eine Fehlerverschleppung zu vermeiden, sollten die Zeitintervalle zwischen  den  Rücksetzpunkten möglichst klein sein. Dadurch resultiert jedoch auch eine erhöhte Systembelastung. Zur Lösung dieses Konflikts kann man die Rücksetzpunkte funktionsabhängig anlegen, etwa vor der Ausgabe von Signalen oder vor der Änderung von Datenbeständen. Dies würde auch sicherstellen, daß bereits durchgeführte und korrekte  Ausgaben nach  einem Rücksetzen nicht noch einmal wiederholt werden.

Die Vorwärtsbehebung bezeichnet eine Fehlerbehebung, die nicht auf Zustandsinformationen der Vergangenheit zurückgreift, sondern durch Kenntnis der Anwendung und ihrer Konsistenzbedingungen fehlerfreie Zustände erzeugt. Dies kann beispielsweise bei einer Prozeßsteuerung dadurch geschehen, daß man keine neuen Steuergrößen ausgibt, sondern die anliegenden Eingangsgrößen zuerst einer erneuten Verarbeitung zuführt. Die Vorwärtsbehebung führt so zu einem Zustand, der aufgrund der Spezifikation durchlaufen werden darf.

Herstellung eines fehlerfreien Systems

Bei Auftreten eines transienten Fehlers genügt der Übergang des Systems in einen fehlerfreien Zustand. Liegt jedoch eine permanente Störung eines Subsystems vor, so sollte man dieses aus dem Systembetrieb ausgliedern und seine Funktionen auf andere Subsysteme verteilen. Man nimmt hierbei an, daß ein Fehler permanent ist, wenn die Anzahl der Fehler pro Zeiteinheit eine Höchstgrenze überschreitet.

Handelt es sich bei dem zu ersetzenden Subsystem um eine Hardwarekomponente, so wird eine Rekonfigurierung durchgeführt. Die fehlerhafte Komponente wird stillgelegt und an ihrer Stelle eine intakte Reservekomponente eingegliedert.  Dies setzt voraus, daß die Reservekomponente zuerst auf die Übernahme der Aufgaben vorbereitet wird (Konditionierung, Herstellung eines definierten Anfangszustandes, Initialisierung), um anschließend anstatt der defekten Komponente zum Einsatz zu kommen. Dazu benötigt die  Rekonfigurierung  zusätzliche Hilfsmittel auf Hardware- und Softwareebene. Insbesondere ist auch auf eine vollständige logische und elektrische Trennung der ausgefallenen Komponenten vom übrigen System zu achten, damit durch deFehler nicht nach und nach das gesamte System »infiziert« wird. Auch muß für die Rekonfigurierung sichergestellt sein, daß noch eine minimale Anzahl intakter Komponenten vorhanden ist, die den Perfektionskern (Hardcore) des Systems bilden.

Handelt es sich bei dem zu ersetzenden Subsystem um eine Software-Komponente, also um ein Programm, dann muß ein diversitäres Programm nachgeladen werden.  Auch hier werden zusätzliche Hilfsmittel auf Hardware- und Softwareebene in Anspruch genommen. Für eine Rekonfigurierung ist es nicht nötig, die Fehlerursache bis ins kleinste Detail aufzuklären. Viel-
mehr genügt es meistens, die kleinste ersetzbare Einheit (SRU = smallest replaceable unit) zu bestimmen, durch deren Austausch der Fehler behoben werden kann. Aussagen darüber, welche Einheit für ein Fehlverhalten des Systems verantwortlich ist und ersetzt werden muß, liefern die Verfahren der Fehlerlokalisation, die im weiteren besprochen werden.

3.2.3 Fehlerlokalisierung

Damit eine gezielte Rekonfigurierung nach der Fehlererkennung erfolgen kann, muß ermittelt werden, welches Subsystem der Verursacher der Störung ist. Wird beispielsweise in einem Bussystem der Fehler »Busleitung i ständig-0« erkannt, so kann sowohl der Bus als auch eines der angeschlossenen Module defekt sein. Ohne weitere Maßnahmen kann nicht festgestellt werden, welches Subsystem (Bus, Modul) ersetzt werden muß. Es wurde bereits gezeigt, daß entsprechend intelligente Fehlererkennungsmethoden  auch Fehler lokalisieren können. Vier weitere Möglichkeiten zur Fehlerlokalisierung werden hier vorgeschlagen:

  • Die einzelnen ersetzbaren Einheiten, die als Verursacher des erkannten Fehlers in Frage kommen, werden aktiven Tests unterzogen, bis die  fehlerhafte  Einheit  gefunden wird. Voraussetzung hierfür ist, daß die einzelnen Einheiten isoliert betrachtet werden können.
  • Das gesamte System wird mehrmals getestet, wobei bei jedem Test genau einer der möglichen Fehlerverursacher abgeschaltet wird und nicht am Systembetrieb teilnimmt.

Liegt beispielsweise der oben genannte Ständig-0-Fehler in einem Bussystem vor, so wird ein Testmuster,  das  diesen Fehler  erkennen kann, mehrmals über den Bus übertragen, wobei bei jeder Übertragung ein anderes Modul vom Bus getrennt wird. Dies wird solange wiederholt, bis man das defekte Modul gefunden hat, oder bis alle Module einmal vom Bus getrennt waren und auf einen Busfehler geschlossen werden muß.

Dieses Vorgehen verlangt, daß die einzelnen Module abschaltbar sind und daß überprüft werden kann, ob die  dafür benötigten Busschalter richtig funktionieren. Außerdem darf es nicht vorkommen, daß mehrere Module in gleicher Weise die Bussignale verfälschen, da ein Abschalten nur eines Moduls dann keine Änderung der Testantwort bewirkt.

  • Ein Konzept, das erstmals mit dem IBM-System/360 eingeführt wurde, ist die Erstellung eines Fehlerreports (error log). Es werden möglichst viele Informationen über das Fehlverhalten des Systems aufgezeichnet, bevor vielleicht durch Wiederherstellungsmanahmen diese Informationen verändert, zerstört oder überschrieben werden. Eine spezielle Prozedur hat dann die Aufgabe, einen solchen Fehlerreport zu analysieren, um Rückschlüsse auf den Ort des Fehlers zu gewinnen. Das Führen eines Fehlerreports ist vor allem nützlich zur Lokalisierung intermittierender Fehler, da diese nur in bestimmten Systemzuständen zu einem Fehlverhalten führen.
  • Die Fehlerlokalisierung kann erleichtert werden, wenn zu jeder Zeit Informationen über die Aktivitäten der einzelnen Subsysteme vorliegen. Hierzu können in unserem Beispiel die Aktivitäten an der Busankopplung eines jeden Moduls über eine spezielle Schaltung beobachtet werden. Dabei wird in einem Register festgehalten, ob das zugehörige Modul gerade sendet oder empfängt, oder ob die Treiberströme zu hoch oder zu niedrig sind. Wenn ein Fehlverhalten des Bussystems eintritt, dann wird durch Abfrage dieser Information  die  Fehlerlokalisierung Abschließend sei noch erwähnt, daß die Methoden der Fehlerlokalisierung zusammen mit den Methoden der Fehlererkennung die Fehlerdiagnose bilden.

Ziel dieser Serie war es, einige Ansatzpunkte zu beleuchten, die zur Erhöhung der Zuverlässigkeit von Rechnersystemen beitragen. Insbesondere sollten die wichtigsten Fehlererkennungsverfahren besprochen werden. Selbstverständlich kann die Aufzählung dieser Verfahren keinen Anspruch auf Vollständigkeit erheben; ebenso kann die Methodik der
einzelnen Verfahren in diesem Rahmen nur ansatzweise erörtert werden. Für detailliertere Informationen sei auf die jeweils angegebene Literatur verwiesen.

Literatur

  • F. Belli, K. Echtle, W. Görke: Methoden und Modelle der Fehlertoleranz, Informatik Spektrum, Band 9, Heft 2, April 1986
  • D. C. Bossen, M. Y, Hsiao: Model for transient and permanent Error-Detection and Fault-Isolation-Coverage, IBM Journal of Research and Developement, Vol. 26, Nr. 1, Januar 1982, S. 67-77
  • M. Dal Cin, K.-E. Großpietsch, M. Trautwein: Methoden der Fehlerdiagnose, Informatik Spektrum, Band 9, Heft 2, April 1986
  • K.-E. Großpietsch, U. Voges: Methoden der Fehlerbehandlung, Informatik Spektrum, Band 9, Heft 2, April 1986
  • Elmar Schrüfer: Zuverlässigkeit von Mess- und Automatisierungseinrichtungen, Carl Hanser Verlag München Wien, 1984
  • S. M. Thatte, J. A. Abraham: Test Generation for Microprocessors, IEEE Transaction on Computers, Vol. C-29, No.6, Juni 1980

 

Autor

improve
marketing-training-consulting
Dipl. Inform. Klaus Eppele
Heinrich-Weitz-Str. 31
76228 Karlsruhe
Tel: 07 21 / 94 74 621
Fax: 07 21 / 94 74 622
eMail:
eppele@improve-mtc.de
URL:
http://www.improve-mtc.de

Erschienen in Datacom 02/92, Seiten 120 - 126