P9 Unkonventionelle Fehler

Protokoll: Unkonventionelle Fehler in HW und SW
Zu Beginn werden folgende Beispiele für unkonventionelle Fehler gebracht:
→ Planarization: Wenn die Isolation nicht passt, entsteht ein Kondenstator.
→ Redundant military System: Wenn in einem kugelsicheren Container etwas explodiert, beschädigt
das Schrapnel davon auch die anderen redundanten Komponenten.
→ Environmental Test chamber: Durch Frequenz-Mismatch konnte das Reset-Signal eine bestimmte
Komponente nie erreichen.
→ Der Intel Floating Point Failure: 2.0 + 2.0 = 3.999998456
Übliche Gründe für Fehler:
→ “Das kann nicht passieren” heißt übersetzt “Es ist in 5000 Stunden an Tests nicht passiert”.
→ Designer haben vielleicht nicht die nötige Erfahrung, und haben nicht die nötige Zeit, sich
ordentlich einzulesen.
→ Leute (und Firmen) möchten keine Fehler zugeben, damit ihr Image keinen Schaden nimmt.
→ Bei einem ungewöhnlichen Fehler denkt man sich oft “Geh, das passiert eh nie wieder...”. Ein
“Once in a lifetime failure” passiert aber in der Praxis deutlich häufiger als einmal im Leben.
→ Clark's 3rd law: “any sufficiently advanced technology is indistinguishable from magic”.
→ Murphy's law: “If anything can go wrong, it will go wrong.” Ergänzt für kritische Systeme: ”...and,
if anything can’t go wrong, it will go wrong anyway.”
Weiteres Fallbeispiel Ariane 5:
Die Software von Ariane 4 wurde nahezu unverändert übernommen, und das Backupsystem hat die
selbe Software verwendet. Ariane 5 war allerdings deutlich anderes dimensioniert als Ariane 4.
Niemand hat damit gerechnet, dass eine bestimmte Variable so groß wird, daher kein Exception
handling.
Swiss Cheese Model:
Eine Käsescheibe ist ein Security Layer, und die Löcher sind Schwächen in diesem Security Layer.
Überlappende Löcher heißen, dass kein Security Layer den Hazard abfängt, und daher ein Failure
passiert.
Byzantinische Diode:
Wenn eine Diode auseinanderbricht, ist sie in Wahrheit ein Kondensator. Wenn dieser Kondensator
gerade im Ladeprozess ist, kann er bei den folgenden Geräten einen metastabilen Zustand ausgeben,
der je nach Gerät entweder als 0 oder als 1 interpretiert wird. Dadurch entsteht ein byzantinischer
Failure.
Diskussion
“Wenn es unerwartete Fehler gibt, gibt es dann auch sowas wie erwartete Fehler?”
→ Man testet immer gegen ein bestimmtes Fehlermodell. “100% Toleranz gegen Stuckat-Fehler” heißt
nicht viel, wenn der tatsächlich auftretende Fehler nicht diesem Fehlermodell entspricht. Es werden
natürlich mit der Zeit mehr Fehlermodelle bekannt. Elektromigration war früher “unerwartet”, heute
kennt man Elektromigration.
Es gibt zwar x Patente für metastability-free irgendwas, aber es gibt einen formalen Beweis dafür, dass
das nicht geht... Und wenn man glaubt, dass man metastability-free ist, dann wird man das vielleicht als
Fehlerursache nicht so ernst nehmen, wodurch es “unerwartet” wird.
Exhaustive Testing ist heute nahezu unmöglich... Es ist zwar möglich, einzelne Komponenten einem
exhaustive Test zu unterziehen, aber wenn man diese Komponenten dann miteinander kombiniert, gibt
es eine kombinatorische Explosion.
Firmen versuchen, Fehler totzuschweigen, weil die Imageverlust befürchten. Keine Firma möchte, dass
irgendein Serienfehler bekannt wird, weil es extrem teuer ist, einen Rückruf zu machen.
Es ist wichtig, für die “Das passiert eh nie”-Fehler eine konkrete Wahrscheinlichkeit anzugeben. Ein
Großteil der Fehler passiert deswegen, weil Designer sagen “Das passiert eh nie”, obwohl es deutlich
wahrscheinlicher ist, als die Spezifikation das zulassen würde.

Download Report