Am 14. September 1993 rutschte der Lufthansa-Flug 2904 in Warschau über das Ende der Landebahn hinaus, weil das System zur Schubumkehr vollkommen spezifikationsgemäß gearbeitet hatte. Die Entwicklungsingenieure von Airbus hatten bestimmte Bedingungen nicht vorhergesehen, die bei einer Landung mit Scherwinden in Bodennähe auftreten können. Bei einem ähnlich gelagerten Vorfall fuhr am 11. Juli 2011 ein U-Bahn-Zug der Victoria Line in London mit offenen Türen ab. Alle Systeme arbeiteten korrekt, doch 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 seine Umgebung mit seiner Reaktion. Dieser Artikel untersucht solche Interaktionen und betrachtet die gegensätzlichen Ziele Zuverlässigkeit und Verfügbarkeit beim Systemdesign.

Der Status „Design Safe“

Verlässlichkeit ist bei einem software­basierten System 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.

Unabhängig davon, ob für ein gegebenes System Verfügbarkeit oder Zuverlässigkeit wichtiger ist: In gefährlichen Situationen muss das System auf jeden Fall auf definierte Weise agieren – in der Regel also in seinen „Design Safe State“ wechseln. Dies ist ein klar definierter Zustand eines Systems, in den es wechselt, wenn es seine vorgesehenen normalen Funktionen nicht mehr korrekt ausführen kann oder nicht bestätigen kann, dass es dies gerade tut. Für die Sicherheit ist der Design Safe State ergo enorm wichtig. Oft vernachlässigen Entwickler jedoch 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. Dabei entstanden die einzelnen Sub­systeme jeweils ohne tiefere Kenntnis der übergeordneten Systeme, in die sie später integriert werden. Datenbanken, Betriebssysteme, Protokoll-Stacks und ähnliche Komponenten werden nicht im Hinblick auf ein konkretes System entwickelt, sondern sind vielmehr für den Betrieb in Umgebungen ausgelegt, die bestimmten Bedingungen genügen, wie sie in den Sicherheitshandbüchern der Komponenten dokumentiert sind. Solche Komponenten bezeichnet zum Beispiel die Medizingeräte-Norm IEC 62304 als SOUP (Software of Unknown Provenance – Software unbekannter Herkunft); in der ISO 26262 für Automobilsysteme werden sie SEooCs (Safe­ty Elements out of Context – Sicherheitselemente ohne Kontext) genannt. Sogenannte Accidental Systems sind 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 lässt sich schwer berechnen, da es von vielen, größtenteils voneinander unabhängigen Komponenten abhängig ist, die in ihren jeweiligen Design Safe State wechseln. Und auch wenn das komplette System reibungslos in seinen Design Safe State wechselt, ist es doch wahrscheinlich Teil eines übergeordneten Systems, das nun zusätzlich belastet wird.

Die Umgebung

Ein System ist eine frei gewählte Gruppierung von Komponenten. Doch 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 er ein zulässiges Limit überschreitet.

Trifft nun das Doppler-Radar im Zug auf Bedingungen, 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 zum Beispiel, auf eine GPS-Quelle umzuschalten und von dieser die nötigen 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 unbe-absichtigten Abhängigkeiten handelt, könnte zum Beispiel 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 also nicht, wenn das Zugsicherungssystem vom 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. Dadurch wird der Zug gesichert, doch es entsteht eine zusätzliche Belastung für das Bahnsignalsystem. Bei der Planung des Signalsystems muss zwar eine unvorhergesehene Vollbremsung eines Zugs auf einer Hochgeschwindigkeitsstrecke berücksichtigt worden sein, aber der Umgang mit diesem Ereignis führt wiederum über einen Ausführungspfad, der im Feld nur selten durchlaufen wird.

Weniger Belastung für die Umgebung

Grundsätzlich treten Probleme häufiger auf, wenn ein System eine zusätzliche Belastung für das übergeordnete System erzeugt, in dem es betrieben wird. Das Beispiel der Victoria Line der Londoner U-Bahn zeigt dies exemplarisch: Auf dieser Linie sind in der Regel mehr Züge unterwegs, als Sta-tionen vorhanden sind. So könnte der Design Safe State jedes einzelnen Zugs zum Beispiel ein Halt an der nächsten Station sein – doch systemweit ist dieser Zustand nicht realisierbar, weil nicht genügend Stationen vorhanden sind.

Soll das Verhalten eines Systems auf seine Umgebung strukturiert erfasst werden, sind vier Zustände zu berücksichtigen, in denen sich das System zu jedem möglichen Zeitpunkt befinden kann

Mögliche Systemzustände

© QNX

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 Situa­tion eingetreten und das System hat korrekt in seinen Design Safe State gewechselt. Dies hat die Umgebung belastet, aber das System hatte keine andere Wahl. Zustand III, in dem das System eine gefährliche Bedingung nicht erkannt hat und einfach weiterläuft, ist nicht sicher. Beim Design ist darauf abzuzielen, die Wahrscheinlichkeit für das Eintreten dieses Zustands unter ein akzeptables Niveau zu senken (zum Beispiel unter 10–7 pro Betriebsstunde). Die wenigste Aufmerksamkeit wird in der Regel Zustand II 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.