Resilienz/Benutzungsfehler: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
K Dirkwagner verschob die Seite Resilienz/Robustheit gegen Benutzungsfehler nach Resilienz/Benutzungsfehler |
(kein Unterschied)
|
Aktuelle Version vom 3. März 2024, 13:52 Uhr
Robustheit gegen Benutzungsfehler
In der Technik, besonders in der Datenverarbeitung, bedeutet Robustheit gegen Benutzungsfehler, vormals als „Fehlertoleranz“ (von Vorlage:LaS ‚erleiden‘, ‚erdulden‘) bezeichnet, die Eigenschaft eines technischen Systems, seine Funktionsweise auch aufrechtzuerhalten, wenn unvorhergesehene Eingaben oder Fehler in der Hard- oder Software auftreten.
Robustheit gegen Benutzungsfehler erhöht die Zuverlässigkeit und Ausfallsicherheit eines Systems, wie es beispielsweise in der Medizintechnik oder in der Luft- und Raumfahrttechnik gefordert ist. Robustheit gegen Benutzungsfehler ist ebenso eine Voraussetzung für Hochverfügbarkeit, die insbesondere in der Telekommunikationstechnik eine wichtige Rolle spielt.
Ansätze auf verschiedenen Ebenen
Robustheit gegen Benutzungsfehler gemäß der Neufassung der DIN EN ISO 9241-110 kann auf verschiedenen Ebenen erreicht werden. Je nach Einsatzgebiet (PC, Medizintechnik, Weltraumtechnik usw.) sind verschiedene Ansätze sinnvoll, auch Kombinationen bieten sich oft an.
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.[1] 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).
Stufen der Robustheit gegen Benutzungsfehler
In der Regel werden folgende Stufen der Fehlertoleranz unterschieden:
Stufe | Verhalten des Systems |
---|---|
go | System reagiert sicher und korrekt. |
fail-operational | System fehlertolerant ohne Leistungsverminderung |
fail-soft | Systembetrieb sicher, aber Leistung vermindert |
fail-safe | Nur Systemsicherheit gewährleistet |
fail-unsafe | unvorhersehbares Systemverhalten |
Reaktion und Korrektur von Fehlern
Bei der Reaktion oder Korrektur von Fehlern unterscheidet man die zwei Prinzipien der Vorwärts- und der Rückwärtsfehlerkorrektur.
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.
- ↑ Vorlage:Webarchiv. Abgerufen am 27. Oktober 2012.