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.
