Diskussion:Robustheit gegen Benutzungsfehler

Überarbeiten

Der Begriff Fehlertoleranz bedeutet in der Informatik weit mehr als fehlertolerante Dialoge. Fehlertoleranz als Forschungszweig beschäftigt sich meines Wissens in erster Linie mit der Ausfallsicherheit von Systemen und dabei gibt in erster Line Ansätze in der Hardware (Stichwort heiße und kalte Reserve) aber auch in der Software. (siehe auch Fault Tolerance in der englischen Wikipedia)

Bei Gelegenheit versuche ich das mal auszuformulieren.--Gudi 11:09, 4. Okt 2005 (CEST)

Ich habe mal mit der Überarbeitung begonnen. --Jdiemer 12:32, 27. Mär 2006 (CEST)

Hier noch ein Input für die Überarbeitung.

Fehlertoleranz ist bei der Raumfahrt ein extrem wichtiges Thema. Bei bemannten Systemen wird mindestens eine Toleranz gegen zwei mögliche Fehlern, die den Verlust des Systems oder eines Astronauten hervorrufen, gefordert.

Es muss sauber unterschieden werden, ob das System fehler-tolerant ist oder nur "kalte" Redundanzen besitzt. Beispiel: Ein Satellit (in diesem Falle das System), der von der Bodenstation im Fehlerfall durch Kommandos "repariert" wird, ist in diesem Sinne nicht fehler-tolerant; befindet sich die Fehlerentdeckungs- und Umschaltlogik im Satelliten ist er fehler-tolerant. Im Englischen wird weiterhin nach fault (gleich permanenter Fehler) und failure (gleich vorübergehende Störung) unterschieden. --Hjpospie 12:45, 3. Jan. 2007 (CET)

Da sich schon lange nichts meht getan hat, bis auf meine letzte Änderung, habe ich den Überarbeiten Hinweis entfernt. Fehlertoleranz und redundante System spielen natürlich Hand in Hand. Ich dazu einen Link unter "Siehe auch" auf Redundanz (Technik) hinzugefügt. Allerdings muss dieser Titel dringends überarbeiten werden. --Wiggerfr 19:42, 11. Apr. 2008 (CEST)

Fehlertoleranz in der Didaktik/Pädagogik fehlt

nicht nur technische Systeme, auch Schüler machen Fehler :) Die Frage ist nun, wie Lehrkräfte damit umgehen, jede Kleinigkeit korrigieren oder auch mal Fünfe grade sein lassen? Es ergibt sich ein Gradient zwischen diesen beiden Polen. In diesem Zusammenhang ist in der Schulpädagogik häufig von Fehlertoleranz die Rede. inwiefern kann und sollte dies in den Artikel eingearbeitet werden? (nicht signierter Beitrag von 83.171.145.214 (Diskussion) 12:54, 11. Mär. 2011 (CET))

Ich würde vielleicht eher von "Fehleraktzeptanz" sprechen, dann kommt man nicht dem hier behandelten technischen Konzept in die Quere. Das Thema Fehler spielt beim Lernen eine wichtige Rolle (das sollte am besten auch dort erwähnt werden), denn es geht nicht darum, Fehler bei Schülern deshalb zu akzeptieren, weil man sie nicht entmutigen will ("Fünfe grade sein lassen"): Ein Fehler findet allermeistens da statt, wo der Lerner eine bereits verstandene Regelmäßigkeit auf einen Fall anwendet, wo leider eine andere Regel gilt. Das Eingreifen eines Außenstehenden unterbricht den Lernprozess, eine bloße Korrektur (richtig/falsch) verhindert, dass Lerner und Lehrer analysieren können, welche Regeln bereits verstanden wurden. -- PhB 12:04, 11. Mai 2011 (CEST)

Unkorrekte Darstellung der Beziehung zwischen Hochverfügbarkeit und Fehlertoleranz sowie kleinere Ergänzungen

In der Einleiung ist zu lesen: "Fehlertoleranz ist ebenso eine Voraussetzung für Hochverfügbarkeit, ..." Bezogen auf IT-Systeme (und Telekommunikationssysteme) ist diese Aussage nicht korrekt. Richtig wäre "Fehlertoleranz ist die extremste Form von Hochverfügbarkeit."

Im Artikel zur Hochverfügbarkeit wird die Beziehung besser dargestellt: "In Abgrenzung zur Fehlertoleranz kann es bei dem (hochverfügbaren) Betrieb im Fehlerfall zu einer Unterbrechung kommen."

Erklärung: Es geht bei diesen Themen immer darum wie sich ein Ausfall für den "Nutzer" (Mensch/anderes IT-System/physisches Objekt das gesteuert wird/...) darstellt. Dabei gibt es zwei Kriterien die Ausschlaggebend sind: 1. Bleibt der (wie auch immer gearteter) interne Zustand trotz Ausfall von Komponenten erhalten? 2. Bleibt das Antwortzeitverhalten beim Ausfall von Komponenten unter der "Wahrnehmenungsschwelle" des Nutzers?

Hochverfügbare Systeme brauchen beide Punkte nicht zu erfüllen. Hochverfügbare Systeme versuchen die Ausfallzeit/Nichtverfügbarkeit (MTTR) zu minimieren. Interne Zustände (z.B. welcher Nutzer hat welche Dateien auf dem Server geöffnet) dürfen dabei verloren gehen, die "Reparaturzeit" sollte kürzer als die Dauer einer manuellen Reparatur sein. Fehlertolerante Systeme müssen beide Punkte erfüllen. Bei Echtzeitsysteme (z.B. FlyByWire in Passagierflugzeugen) ist dabei der zweite Punkt der kritische.

Für "Fehlertoleranz in Hardware" ergibt sich daraus, dass DMR-Systeme unter bestimmten Voraussetzungen fehlertolerant sein können. Der dargestellte Fall von DMR erkennt Fehler, kann sie aber nicht korrigieren. Damit ist es kein Beispiel für Fehlertoleranz, sondern für Fehlererkennung. Ein DMR-System wird erst dann Fehlertolerant, wenn es sicherstellt, dass Module nur in einer wohl definierten Art und Weise ausfallen können. Dieser Ausfall kann vom verbleibenden Modul zuverlässig (weil wohl definiert) erkannt werden, die Entscheidung richtig/falsch (voter) muß nicht getroffen werden, da der Ausfall an sich erkannt wird. Ein Beispiel dafür sind redundante Netzteile. Gemäß der Beschreibung im Artikel könnten DMR-Netzteile niemals den Ausfall eines Netzteil-Moduls kompensieren, sondern lediglich detektieren. Da der Ausfall eines Moduls jedoch "wohl definiert" ist (Ausgangsspannungen des defekten Moduls sind nicht mehr innerhalb der vorgebenen Toleranzbereiche) können DMR-Netzteile Fehlertolerant arbeiten. (1. Erhalt des Zustandes ein-/ausgeschaltet, 2. Sofortige Übernahme der durch das defekte Netzteil nicht mehr lieferbaren Stromversorgung, der mit Strom zu versorgende "Nutzer" bemerkt keinen Stromausfall)

Die gleiche Situation ergibt sich mit RAID1/Spiegelung bei Festplatten. Auch hier wir keine Beurteilung der Ergebnisse im Sinne von "richtig/falsch" benötigt. Der Ausfall einer Festplatte ist "wohl definiert", und wird für die Entscheidung herangezogen. Nichtsdestotrotz gibt es inzwischen Dateisysteme die defekte Daten erkennen können (z.B. anhand von Prüfsummen). Dies ermöglicht eine deutlich bessere Entscheidungsfindung bei Ausfällen die nicht wohl definiert sind (siehe https://en.wikipedia.org/wiki/Data_degradation#Data_degradation_in_storage).

Referenz: Meine Diplomarbeit aus dem Jahre 1999, nicht online verfügbar.

Software Fehlertoleranz

Man kann es täglich feststellen, dass Software-Fehler vorkommen, die durch Schwächen in der Programmierung verursacht werden. Komplexe Programme können weder durch Review noch Tests zu 100 % verifiziert werden. Daher hat die NASA damals die Shuttle Software, die während der Aufstiegsphase parallel auf drei Rechnern lief, von drei Teams erstellen lassen. Das ist natürlich ein teurer Weg aber eine gute Möglichkeit, Real-Time Software möglichst sicher zu machen. (nicht signierter Beitrag von Hjpospie (Diskussion | Beiträge) 11:49, 17. Nov. 2020 (CET))