Robustheit gegen Benutzungsfehler in Hardware

Hardware, d. h. eine elektronische Schaltung, kann z. B. durch Hinzufügen von „heißer“ Redundanz fehlertolerant gemacht werden. „Kalte“ Redundanz benötigt hingegen den Eingriff eines anderen Systems (Operator, Software etc.) und erfüllt daher allein nicht die Fehlertoleranz-Anforderung.

Laufen z. B. zwei Implementierungen einer Schaltung parallel (dual modular redundancy, DMR), so kann eine Entscheidungseinheit einen Fehler durch Vergleichen der Ausgänge der beiden Komponenten feststellen, jedoch nicht korrigieren. Fügt man eine weitere Instanz der Komponenten hinzu (triple modular redundancy, TMR), so kann eine Entscheidungseinheit einen Fehler auch korrigieren. Wird die fehlerhafte Einheit als defekt markiert, ist ein Fehler weiter erkennbar (wie bei DMR). Wenn für den sicheren Betrieb eines Systems das Vorhandensein einer TMR gefordert ist, arbeitet man mit 4 oder mehr redundanten Komponenten.

Robustheit gegen Benutzungsfehler in Software

Auf Software-Ebene kann Fehlertoleranz durch folgende Maßnahmen erreicht werden:

• Design-Diversität: verschiedene Implementierungen eines Algorithmus laufen parallel
• Daten-Diversität: die Eingabedaten werden leicht modifiziert mehrfach bearbeitet (z. B. gut gegen Rundungsfehler)
• Temporale Diversität: ein Algorithmus wird mit denselben Daten mehrfach aufgerufen (z. B. gut gegen kurzzeitige Hardwarefehler)

Robustheit gegen Benutzungsfehler in Benutzerschnittstellen

Häufig verursachen fehlerhafte Benutzereingaben, also menschliches Versagen, abnorme Betriebszustände. Robustheit gegen Benutzungsfehler ist daher eines der Gestaltungsprinzipien für Dialoge nach EN ISO 9241, Abschnitt 110 (Grundsätze der Dialoggestaltung). Ein Dialog ist robust gegen Benutzungsfehler (vormals fehlertolerant), wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand durch den Benutzer erreicht werden kann:

• Unterstützung bei der Entdeckung und Vermeidung von Eingabefehlern (Plausibilisierung)
• Keine Systemabbrüche oder undefinierten Systemzustände
• Fehlererläuterungen zu Korrekturzwecken
• Zusätzlicher Darstellungsaufwand zur Fehlerlokalisierung
• Automatische Fehlerkorrektur mit Information
• Aufschiebbare Fehlerbehandlungen
• Zusätzliche Erläuterungen auf Anforderung
• Prüfung und Bestätigung vor Ausführung
• Fehlerbehebung ohne Zustandsänderung des Dialogs

Die potentiellen Fehler, die Besucher verursachen oder die ihnen begegnen können, lassen sich wie folgt klassifizieren:

Vermeidbare Fehler

Diese Art von Fehlern treten aufgrund mangelnder Beschäftigung mit dem Benutzerverhalten auf und wären bei sorgfältiger Auseinandersetzung mit der Zielgruppe und ihrem typischen Nutzungsverhalten vermeidbar. Typisch vermeidbare Anwenderfehler auf Websites sind Navigationsfehler oder fehlerhafte Eingaben auf Formularen. Durch umfangreiche Tests vor dem Launch einer Website oder Anwendung könnten viele dieser Fehler vermieden werden.

Bekannte, nicht vermeidbare Fehler

Nicht alle bekannten Fehler lassen sich vermeiden. Ein Vertippen mit der Tastatur, ein versehentliches Abschicken eines Formulars, das noch nicht vollständig ausgefüllt war, sind nur zwei Beispiele für Fehler, mit denen man rechnen muss, weil sie sich nicht ausschließen lassen. Für alle vorhersehbaren Fehler muss es deshalb einfache, klar erkennbare Korrekturmöglichkeiten geben.

Nicht antizipierbare Fehler

In diese Klasse von Fehlern fallen all diejenigen, welche aufgrund unerwarteten Benutzerverhaltens passieren oder durch schwer identifizierbare Programmierfehler verursacht werden. Meist führen diese Fehler zu undurchsichtigen Programmverhalten, die für den Benutzer nicht verständlich sind. Ein typischer Fall wäre zum Beispiel ein Fehler durch die Verwendung von nicht normalisierten Uhrzeiten. Bei der Umstellung von Sommer- auf Normalzeit wird so die Stunde 2 doppelt durchlaufen, wodurch eigentlich eindeutige Zeitstempel eventuell doppelt auftreten können oder Zeitmessungen scheinbar zu einer früheren Zeit enden als sie begonnen haben. Dieses Verhalten tritt nur einmal im Jahr auf und ist an den restlichen Tagen des Jahres nicht reproduzierbar. Die Lösung ist in solchen Fällen üblicherweise die Verwendung der UTC oder der normalisierten Lokalzeit (lokale Zeit ohne Sommerzeit-Verschiebung).

Vorwärtsfehlerkorrektur

Bei der Vorwärtsfehlerkorrektur versucht das System, so weiterzumachen als ob kein Fehler aufgetreten wäre, indem es etwa fehlerhafte Eingabewerte durch Erfahrungswerte aus der Vergangenheit oder Eingabewerte von korrekt funktionierenden Eingabeschnittstellen ausgleicht oder im Moment des Auftretens eines Fehlers sofort mit korrekt funktionierenden Ersatzsystemen weiterarbeitet. Fehler bleiben bei der Vorwärtsfehlerkorrektur normalerweise unsichtbar für Anwender.

Rückwärtsfehlerkorrektur

Bei der Rückwärtsfehlerkorrektur versucht das System bei Auftreten eines Fehlers in einen Zustand vor diesem Auftreten zurückzukehren, etwa in den Zustand direkt vor einer fehlerhaften Berechnung, um diese Berechnung erneut auszuführen. Genauso ist aber auch ein Zustandswechsel in einen Notbetrieb oder z. B. ein Neustart des Systems möglich. Kann eine fehlerhafte Berechnung erfolgreich wiederholt werden, bleibt auch bei der Rückwärtsfehlerkorrektur der Fehler für den Anwender unsichtbar. Oft ist aber nur ein Weiterbetrieb mit Leistungseinbußen oder eingeschränkter Funktionalität möglich und der Fehler somit sichtbar.

Externe Korrektur

In der Weltraumtechnik wird eine Fehlerkorrektur durch die Auswertung von Satelliten-Telemetriedaten in der Bodenstation durch Systemexperten und Umschaltung der Funktionen durch Telekommandos durchgeführt. Seit den enormen Fortschritten bei der Bord-Datenverarbeitung (schnelle Prozessoren, große Datenspeicher, intelligente Software-Konzepte) wird die Datenauswertung und Umschaltung zur Fehlerkorrektur mehr und mehr autonom vom Satellitensystem selbst ausgeführt.

Wegen der erforderlichen umfangreichen Überprüfungsmaßnahmen eines komplexen Bordsystems und dem damit verbundenen Zeit- und Kostenaufwand wird die zunehmende Autonomie in Hinsicht auf Fehlerkorrektur nur in kleinen Schritten realisiert, denn anders als bei Systemen auf der Erde kann eine falsche Fehlerkorrektur zum kompletten Verlust eines Satelliten führen.