Eine zweite Meinung einholen
Es ist davon auszugehen, dass die meisten Ausfälle unseres Systems von nicht reproduzierbaren Heisenbugs ausgelöst werden, da die reproduzierbaren Bohrbugs beim Testen mit an Sicherheit grenzender Wahrscheinlichkeit bereits gefunden und beseitigt wurden. Ein Heisenbug kann seine Ursache in der Software selbst haben (z.B. eine subtile und selten auftretende Race Condition) oder in einem transienten Speicherfehler (wie er etwa von dem Handy des Zugführers ausgelöst werden kann). Unabhängig von seiner Ursache liegt es in der Natur eines Heisenbugs, dass eine Wiederholung der Berechnung zu einem anderen – und diesmal vermutlich korrekten – Ergebnis führt. Aber bleibt genug Zeit für eine Wiederholung der Berechnung? Das hängt von dem betrachteten System ab. Ein Hochgeschwindigkeitszug ist mit bis zu 100m/s unterwegs. Ist es bei Nichtübereinstimmung der beiden Überwacher akzeptabel, den Wechsel in den Design Safe State zu verzögern, bis die Berechnung wiederholt wurde? Wenn die beiden Überwacher übereinstimmend einen Wechsel in den Design Safe State anfordern, so wird dieser auch vollzogen. Wir sprechen hier nur von dem Fall, in dem die Überwacher nicht übereinstimmende Ergebnisse liefern. Die Antwort ist natürlich in der Ausfallanalyse des Systems zu suchen, aber in vielen Fällen lässt sich durch ein derartiges Design mit ‚zweiter Meinung‘ die Verfügbarkeit eines Systems wesentlich verbessern, ohne dass die Zuverlässigkeit signifikant leidet. Bei Ausdehnung der Ausfallanalyse auf die übergeordnete Umgebung lässt sich durch Steigerung der Systemverfügbarkeit auf Kosten der Zuverlässigkeit häufig insgesamt die Sicherheit verbessern.
Verschiedene Standpunkte
einnehmen
Beim Systemdesign besteht die Verlockung, das System isoliert zu betrachten und zu sagen: „Unser System ist sicher!“, ohne dabei die Auswirkungen einer Nichtverfügbarkeit für das übergeordnete System zu berücksichtigen, in dem unser System betrieben werden wird. Leider gelangen mit einer komplexen Komponente nur allzu leicht versteckte Ausfallabhängigkeiten in unser System, wodurch die Ergebnisse unserer Ausfallberechnungen ungültig werden.
Software vom Standpunkt der Umgebung aus betrachten
Als Entwickler von Embedded-Software konzentrieren wir uns bei der Erstellung des Safety Case naturgemäß auf die Entwicklung und Validierung unserer eigenen Software. Oft können wir nicht mehr tun, als unsere Annahmen über die Umgebung explizit zu machen, da wir keine Kontrolle (oder auch gar keine Kenntnis) darüber haben, wie und wo unsere Software eingesetzt werden wird. Wenn wir jedoch die Umgebung kennen, ist es naheliegend, über den Tellerrand zu schauen und die Umgebung vom Standpunkt der Software aus zu betrachten. Das ist aufgrund der Belastung, der wir die Umgebung aussetzen können, auch wichtig. Aber wir können sicherere Systeme bauen, wenn wir auch den Umkehrschritt gehen und die Software vom Standpunkt der Umgebung aus betrachten.
