Systemarchitekturen für sicherheitskritische Systeme

Schrittweises Herangehen

Wie bei allen Embedded-Systemen geht dem Entwurf die Definition der Systemanforderungen mit der physikalischen und funktionalen Spezifikation voraus. Sicherheitskritische Systeme erfordern zudem eine umfassende Gefahren- und Risikoanalyse - erst dann folgt der Entwurf der Architektur.

Die Gefährdungsanalyse (Hazard-Analyse) dient dem systematischen Identifizieren von Gefährdungen der menschlichen Sicherheit durch ein System. Zudem wird die Wahrscheinlichkeit ermittelt, dass diese Gefährdungen einen Unfall zur Folge haben. Die Fehlerbaumanalyse (FTA) ist eine häufig verwendete Methode zur Gefährdungsanalyse. Sie basiert auf hierarchischer Top-down-Zerlegung; dabei werden jedoch keine Funktionen zerlegt, wie wir das zu Beginn unserer Ingenieursausbildung gelernt haben, sondern vielmehr unerwünschte System-Events. Damit ist es möglich, Kombinationen von Hardware-, Software-, Bedien- oder sonstiger Fehler zu identifizieren, die zu Sicherheitsgefährdungen führen können.

Bildergalerie

Bildergalerie mit 10 Bildern

Eine Fehlerbaumanalyse beginnt mit der Frage “Was sind die 3 (oder 6 oder 7) lebensbedrohlichsten Dinge, die mein System tun könnte?“. Tragen Sie jede Sicherheitsgefährdung, die Ihnen einfällt, als Spitze in jeweils einem eigenen Fehlerbaum ein (siehe Abbildung 3). Dann folgt die Frage „Was könnten die Ursachen für diese Dinge sein?“. Ihre Antwort erscheint als oberste Dekompositionsebene des Fehlerbaums. Nächste Frage: „Und was könnte wiederum diese Dinge verursacht haben?“. Die Antworten kommen auf die nächste Fehlerbaum-Ebene, und so weiter. Sie können dabei UND/ODER-Operatoren verwenden, um logische Verknüpfungen in Ihren Diagrammen zu zeigen (Abbildung 3).

Ein anderes und vielleicht systematischeres Vorgehen zur Gefährdungsanalyse ist die sogenannte Ereignisbaumanalyse – ein Bottom-Up-Ansatz, der die Ergebnisse aus dem Betrieb bzw. Ausfall (Failure) von Systemkomponenten und Untersystemen untersucht. Ein Ereignisbaum wird häufig horizontal dargestellt, siehe Abbildung 4.

Das sicherheitsgefährdende Ereignis (Event) auf oberster Ebene steht links in der Abbildung 4; die am Handling dieses Events beteiligten Komponenten und Subsysteme werden oben horizontal gezeigt. Der Ereignisbaum analysiert folgende Situation: „Wenn bei der Infusionspumpe der Flüssigkeitsdruck ausfällt, gibt das System die erforderliche Warnung aus?“. Die Wahrscheinlichkeiten für erfolgreichen Betrieb bzw. für Ausfall werden für alle beteiligten Komponenten und Subsysteme eingetragen. Nach Errechnen der Wahrscheinlichkeiten ist das Ergebnis in diesem Beispiel, dass in 16,21% der Zeit keine Warnung ausgegeben wird. [Hinweis: Dieses Beispiel ist frei erfunden, um möglichst einfache Zahlen verwenden zu können. Echte medizinische Systeme sind viel zuverlässiger.]

Auf die Gefährdungsanalyse folgt die Risikoanalyse. Risiko wird als die Kombination der Wahrscheinlichkeit und den erwarteten Folgen eines unerwünschten Ereignisses betrachtet. Man könnte es quantitativ z.B. als „Todesfälle je 100 Jahre Systembetrieb“ angeben. Sind die größten Risiken identifiziert, die ein System darstellen könnte, gilt es, sie beim Systementwurf zu berücksichtigen: Die zugrundeliegenden Gefährdungen sind sofern möglich zu vermeiden oder zu beseitigen. Dies lässt sich häufig mit folgenden Maßnahmen umsetzen:

Hardware-Overrides, um bedenkliche Softwarekomponenten zu umgehen

Lockouts, um zu verhindern, dass ein System in einen risikoreichen Zustand eintritt

Lockins, um zu gewährleisten, dass ein System zuverlässig im sicheren Zustand bleibt

Interlocks, um Abfolgen von Events zu unterbinden und damit Gefährdung zu vermeiden

Wenn sich die Gefährdungen nicht vollständig vermeiden oder beseitigen lassen, gilt es, das Unfallrisiko einzudämmen. Tritt dennoch ein Unfall ein, ist das Risiko zu minimieren, dass Leben gefährdet wird.

Zusammen mit den Systemanforderungen stellen die Ergebnisse aus der Gefährdungs- und der Risikoanalyse eine Leitlinie für den Architekturentwurf von sicherheitskritischen Systemen dar.

Methoden zur Erkennung von Sensorfehlern

Korrekte Sensordaten sind für den sicheren Betrieb so kritisch, dass viele Systeme eine redundante Sensordatenerfassung haben. Das müssen nicht unbedingt Sensor-Replikate sein wie in Abbildung 5, wo zwei identische Sensoren zum Einsatz kommen. Auch funktionale Redundanz käme infrage, also die Messung desselben Wertes auf zwei verschiedene Arten. Zum Bespiel ließe sich die Atmungsrate eines Patienten sowohl über Ausweitung und Zusammenziehen des Brustkorbs messen sowie auch auf Basis der ausgeatmeten CO2-Konzentration.

Redundanz lässt sich auch als analytische Redundanz implementieren; dabei wird ein bestimmter Messwert mit einem anderweitig abgeleiteten Wert abgeglichen, siehe Abbildung 6.

Bespiel: Das Messergebnis eines Positionssensors ließe sich mit folgendem Wert vergleichen: Summe aus vorheriger Position plus Geschwindigkeit, multipliziert mit der Ablaufzeit.

xt = x0 + vavg*t .

Bei bekannter konstanter Beschleunigung wäre die Formel:

xt = x0 + v0*t + ½*aconst*(t)**2.

Der Physikunterricht hat seinen Zweck erfüllt! Stimmen die errechneten und gemessenen Werte annähernd überein, können wir darauf vertrauen, dass der Sensor richtig arbeitet. Noch ein Beispiel: Die Herzfrequenz eines Patienten lässt sich mittels Signalanalyse einer arteriellen Blutdruck-Wellenform extrahieren. Dann kann man sie dem Wert gegenüberstellen, der direkt aus dem elektrokardiographischen Signal (EKG) des Patienten gemessen wurde (analytische Redundanz).

Diese Ansätze lassen sich kombinieren und erweitern. Bei den bisher besprochenen Methoden wissen wir, dass bei einem Sensor etwas nicht in Ordnung ist, wenn die Vergleichswerte nicht übereinstimmen. Manchmal ist es dann am besten, das gesamte Redundanzpaar mittels „Fail-Stop“ abzuschalten. Es ist auch möglich, eine dritte redundante Komponente hinzuzufügen und „Vergleich“ durch „Voting“ zu ersetzen. Erfolgt dies in einem rein replikationsbasierten Design wie in Abbildung 5, entsteht eine sogenannte dreifach modulare Redundanz (Triple Modular Redundancy, TMR). Die verschiedenen Redundanz-Verfahren lassen sich auch kombinieren. Bei Triple-Modular-Redundanzen ist es möglich, einen als fehlerhaft identifizierten Sensor abzuschalten. Die anderen redundanten Elemente laufen sicher weiter.

(ID:44853387)