Sicheres Systemdesign

Zuverlässigkeit
und Verfügbarkeit

Über sichere Systeme nachzudenken, ohne die Umgebung zu berücksichtigen, in der diese betrieben werden, kann fatale Folgen haben. In diesem Beitrag betrachten wir am Beispiel eines hypothetischen Steuerungssystems für Zugführerstände die Balance zwischen Verfügbarkeit und Zuverlässigkeit der Sicherheitskomponente des Systems.

Am 11. Juli 2011 fuhr ein U-Bahn-Zug der Victoria Line in London mit offenen Türen ab. Alle Systeme arbeiteten korrekt, aber der Zugführer hatte die Systeme in einer Weise bedient, die die Entwickler nicht vorhergesehen hatten. Jedes System interagiert auf zweierlei Art und Weise mit seiner Umgebung: Die Umgebung belastet das System mit unvorhergesehenen Anforderungen, und das System belastet mit seiner Reaktion seine Umgebung. Dieser Fachartikel untersucht solche Interaktionen und betrachtet die gegensätzlichen Ziele Zuverlässigkeit und Verfügbarkeit beim Systemdesign.

Verlässlichkeit

Bei einem softwarebasierten System ist Verlässlichkeit eine Kombination aus Verfügbarkeit (wie oft das System rechtzeitig auf einen Reiz reagiert) und Zuverlässigkeit (wie oft die Reaktion korrekt ist). Bei manchen Systemen ist Zuverlässigkeit wichtiger als Verfügbarkeit – keine Aktion ist besser als die falsche Aktion, während bei anderen Systemen Verfügbarkeit wichtiger ist – jede plausible Reaktion ist besser als gar keine Reaktion.

Design Safe States

Unabhängig davon, ob für ein gegebenes System Verfügbarkeit oder Zuverlässigkeit wichtiger ist, muss das System auf jeden Fall in gefährlichen Situationen auf definierte Weise agieren. In der Regel muss es in seinen Design Safe State wechseln. Dabei handelt es sich um einen klar definierten Zustand eines Systems, in den es wechselt, wenn es seine vorgesehenen normalen Funktionen nicht mehr korrekt ausführen kann, oder es nicht bestätigen kann, dass es dies gerade tut. Für die Sicherheit ist der Design Safe State also enorm wichtig. Leider vernachlässigen Entwickler jedoch zu oft die Auswirkungen, die ein Wechsel ihres Systems in den Design Safe State auf die weitere Umgebung hat, in der ihr System betrieben wird. Die meisten komplexen Systeme sind aus integrierten Subsystemen aufgebaut. Die einzelnen Subsysteme werden oft ohne tiefere Kenntnis der übergeordneten Systeme entwickelt, in die sie später integriert werden. Datenbanken, Betriebssysteme, Protokoll-Stacks und ähnliche Komponenten werden nicht im Hinblick auf ein konkretes System entwickelt. Dr. Martyn Thomas machte auf dem Safety-Critical Systems Symposium 2012 auf sogenannte Accidental Systems aufmerksam – Systeme, deren Entwickler sich nicht über versteckte Abhängigkeiten zwischen Komponenten aus unterschiedlichen Quellen bewusst waren, bei denen diese Abhängigkeiten also unbeabsichtigt (accidentally) entstanden sind. Das Verhalten eines solchen Gesamtsystems in unvorhergesehenen Situationen ist sehr schwer zu berechnen, da es abhängig ist von vielen, größtenteils voneinander unabhängigen Komponenten, die ggf. in ihren jeweiligen Design Safe State wechseln. Und selbst wenn unser komplettes System reibungslos in seinen Design Safe State wechselt, so ist es doch wahrscheinlich Teil eines übergeordneten Systems, welches nun zusätzlich belastet wird.

Die Umgebung

Ein System ist eine frei gewählte Gruppierung von Komponenten. Was für einen Entwickler ein System ist, kann für den anderen eine Komponente sein. Ein Beispiel: Hersteller A baut Komponenten zu einem System zusammen: ein Doppler-Radar zur Messung der Geschwindigkeit eines Zuges. Für Hersteller B stellt dieses System eine Komponente eines Zugsicherungssystems dar, das den Zug bremst, wenn dieser ein zulässiges Limit überschreitet. Wenn nun das Doppler-Radar im Zug auf Bedingungen trifft, für die es nicht ausgelegt ist, wechselt es in seinen Design Safe State und sendet ein Störungssignal an das Zugsicherungssystem. Das Zugsicherungssystem ist so programmiert, dass es mit dieser Situation umgehen kann, und versucht z.B. auf eine GPS-Quelle umzuschalten und von dieser Geschwindigkeitsinformationen zu beziehen. Das Umschalten auf die GPS-Quelle verursacht eine zusätzliche Belastung, weil das System Ausführungspfade durchlaufen muss, die weniger gut erprobt sind. Wenn es sich bei dem Zugsicherungssystem nun um ein System mit unbeabsichtigten Abhängigkeiten handelt, könnte z.B. das Doppler-Radar intern seinen Zeittakt aus einem GPS-Signal ableiten. Möglicherweise war eine Störung des GPS-Signals Grund für seinen Ausfall. In diesem Fall hilft es dann natürlich nicht, wenn das Zugsicherungssystem von dem Doppler-Radar auf eine GPS-Quelle umschaltet. Zwei Ausfälle, die der Systementwickler bei seinen Wahrscheinlichkeitsberechnungen als unabhängig betrachtet hat, sind in Wirklichkeit stark korreliert. Wenn nun das Zugsicherungssystem ausfällt, wechselt es seinerseits in seinen Design Safe State und veranlasst wahrscheinlich eine Bremsung des Zuges. Der Zug wird dadurch gesichert, aber es entsteht eine zusätzliche Belastung für das Bahnsignalsystem. Eine unvorhergesehene Vollbremsung eines Zuges auf einer Hochgeschwindigkeitsstrecke muss zwar bei der Planung des Signalsystems berücksichtigt worden sein, aber der Umgang mit diesem Ereignis führt wiederum über einen Ausführungspfad, der im Feld nur selten durchlaufen wird.

Reduzierung der Belastung für die Umgebung

Probleme treten häufiger auf, wenn ein System eine zusätzliche Belastung für das übergeordnete System erzeugt, in dem es betrieben wird. Dies sieht man schön an der Victoria-Line der Londoner U-Bahn: Auf der Linie sind in der Regel mehr Züge unterwegs, als Stationen vorhanden sind. Der Design Safe State jedes einzelnen Zugs könnte etwa ein Halt an der nächsten Station sein, aber systemweit lässt sich dieser Zustand nicht realisieren, weil es gar nicht genügend Stationen gibt. Wollen wir das Verhalten eines Systems auf seine Umgebung strukturiert erfassen, müssen wir vier Zustände berücksichtigen, in denen sich das System zu jedem möglichen Zeitpunkt befinden kann (Tabelle 1). In Zustand I arbeitet das System korrekt, es ist keine gefährliche Situation eingetreten und es wird keine zusätzliche Belastung verursacht. In Zustand IV ist tatsächlich eine gefährliche Situation eingetreten, und das System hat korrekt in seinen Design Safe State gewechselt. Dies hat die Umgebung belastet, aber das System hatte keine andere Wahl. Der Zustand III, in dem das System eine gefährliche Bedingung nicht erkannt hat und einfach weiterläuft, ist nicht sicher. Beim Design zielen wir darauf ab, die Wahrscheinlichkeit für das Eintreten dieses Zustands unter ein akzeptables Niveau zu senken (z.B. unter 10-7 pro Betriebsstunde). Zustand II wird in der Regel die wenigste Aufmerksamkeit zuteil. Hier hat das System fälschlicherweise eine gefährliche Bedingung erkannt, die in Wirklichkeit gar nicht existiert. Es wechselt unnötigerweise in seinen Design Safe State und belastet dadurch seine Umgebung.

Ein System mit labilem Auslöser

Abbildung 2 zeigt ein typisches Design für sicherheitskritische Systeme. Das Hauptsystem empfängt Sensordaten und führt die systemabhängige Berechnung durch, um die erforderliche Aktion zu ermitteln. Sein Betrieb wird von einer Sicherheitsfunktion (im Sinne von IEC61508) überwacht, die anhand einer viel einfacheren (und daher weniger störungsanfälligen) Berechnung ermittelt, ob das Hauptsystem plausibel arbeitet (Abbildung 3). Um die Zuverlässigkeit der Sicherheitsfunktion zu erhöhen, sind zwei Überwacher vorgesehen, die parallel arbeiten. Wenn einer der Überwacher zu dem Ergebnis gelangt, dass das Hauptsystem nicht plausibel arbeitet, meldet er dieses Ergebnis, und das System wird nicht mehr am Zurückfallen in seinen Safe State gehindert. Es handelt sich also um ein sogenanntes 1oo2-System (one out of two – einer von zwei): Jeder der Überwacher kann unabhängig das System zum Wechsel in den Design Safe State veranlassen. Das 1oo2-System erhöht tatsächlich zwar die Zuverlässigkeit, dies geschieht jedoch auf erhebliche Kosten der Verfügbarkeit. Wenn auch nur einer der beiden Überwacher fehlerhaft arbeitet – etwa aufgrund eines Speicherfehlers, den der Zugführer mit einem Handy in der Nähe des Geräts ausgelöst hat – wechselt das System sofort in den Zustand II, reduziert dadurch seine Verfügbarkeit und erzeugt eine unnötige Belastung für seine Umgebung.

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.