Konzeption sicherheitsrelevanter eingebetteter Systeme
Sergio Montenegro (.)
GMD-FIRST (http://www.first.fhg.de)
Bei der Entwicklung sicherheitsrelevanter Systeme, deren Versagen tödliche Folgen haben kann, ist die Frage: Wann ist das System sicher genug? nicht beantwortbar. Wünschenswert wäre es, alles menschlich mögliche für die Sicherheit zu tun und ihr bei allen Entscheidungen die höchste Priorität einzuräumen.
Sicherheit ist nicht unbedingt das gleiche wie Verfügbarkeit. Wenn ein System einen Fail-Safe Zustand hat, stehen beide sogar gegeneinander. Fail-Safe bedeutet, daß das System in einen stabilen, sicheren Zustand (Halt) gebracht werden kann.
Beispiele: a) Ein Auto, das niemals fährt, ist sicher: es geht keine Gefahr von ihm aus (es ist aber nicht brauchbar). Ein Auto, das immer fahren kann, auch wenn es auseinanderfällt, hat die höchste Verfügbarkeit. b) Oft wird eine potentielle Gefahr rechtzeitig erkannt. Bei der Behandlung der Ausnahme- oder Fehlersituation entsteht ein Dilemma: Sicherheit oder Verfügbarkeit. 1. höhere Sicherheit: Sofort beim Erkennen einer potentiellen Gefahr Notmaßnahme einleiten (Halt). 2. höhere Verfügbarkeit: System mit eingeschränkter Funktionalität zum normalen Betrieb zurückbringen. Die Notmaßnahmen werden erst eingeleitet, wenn es sicher ist, daß ohne Notmaßnahmen ein Unfall eintreten würde. c) Redundanz kann eingesetzt werden, um eine der beiden Eigenschaften zu steigern: 1. als Fehlermonitor zum Ausschalten oder 2. als Reserve, um bei Fehlern weiterarbeiten zu können.
Wenn das System keinen Fail-Safe Zustand hat, ist Sicherheit ähnlich wie Verfügbarkeit. Das System soll seine Funktion weiter erfüllen, auch bei Fehlern und Ausnahmen. Z.B. ist in einem fliegenden Flugzeug die Sicherheit ist, daß es auch bei Ausfällen weiter fliegt. Oder ein fahrendes Auto muß steuerbar bleiben bis es anhält.
Um ein (noch) sichereres System zu konzipieren, ist es empfehlenswert, es zu vereinfachen, die Interaktion Mensch-Maschine zu überdenken, Gefahren zu erkennen und Maßnahmen für die Gefahrenbeherrschung zu planen.
Vereinfachen
Wenn die Komplexität eines Systems steigt, sinken seine Sicherheit und seine Verfügbarkeit, da ein Versagen jeder Komponente das Versagen des Gesamtsystems bedeuten kann, die Entwicklung unübersichtlicher wird und die Anzahl der Schnittstellen (Schwachstellen und Fehlerquellen) steigt. Deswegen, ist die einfachste Lösung immer die beste (die sicherste).
Warum werden Systeme immer komplexer? Die Steuerung der ersten Raketen bestand aus 30 Röhren (äquivalent zu 30 Transistoren). Heutzutage besteht die Steuerung aus 100 Rechnern mit jeweils 30 Millionen Transistoren (CPU + Speicher +...) plus Softwarekomplexität, die nicht meßbar ist (Millionen lines of code). Die Steuerung ist also mindestens eine Milliarde Mal komplexer als damals. Kein Mensch kann dies mehr überblicken noch das Gesamtsystem genau kennen: eine enorme Gefahrenquelle.
Die Rechner-Komplexität schaukelt sich in einem Teufelskreis auf: Der Kunde will keine Resourcen verschwenden, CPU-Zeit und Speicher müssen zu 100% ausgenutzt sein. Also mehr Funktionalität muß her. Dann wird es eng, man braucht mehr Speicher, schnellere CPUs. Und es geht wieder von vorne los. Ein System maximal auzunutzen, erfordert jedoch einen ernormen Aufwand. Dieses Verhältnis entspricht einer Sättigungskurve. Am Anfang bekommt man mit wenig Aufwand eine gute Leistung. Nahe an der 100%-Ausnutzungsgrenze müssen viel Aufwand und Tricks investiert werden, um wenig zu bekommen.
Dieser Aufwand bedeutet: teurer, längere Entwicklungszeit und (wichtiger) niedrigere Sicherheit. Der Aufwand sollte lieber bei der Sicherheitssteigerung investiert werden. Einfacher ist sicherer (man kann nicht viel falsch machen), zuverlässiger, übersichtlicher, vielseitiger und flexibler, preiswerter, leichter zu verstehen und zu benutzen, schneller und einfacher zu aktualisieren, hat kürzere Entwicklungszeit und einfachere Wartung und Inbetriebnahme.
Deswegen: "Man soll alles so einfach wie möglich machen..... aber nicht einfacher" (Einstein). Das Ziel sollte nicht ein System sein, bei dem man nichts mehr hinzufügen kann, sondern eins, von dem man nichts mehr wegnehmen kann.
Kooperation Mensch-Maschine
Es gibt eine Tendenz, Sicherheit durch Automatisierung zu erreichen. Die traurige Bilanz: viermal so viele Unfälle, wenn der Mensch in die Steuerung nicht mehr eingreifen kann. Bei 80% der Flugzeugkatastrophen lautet der Befund "Menschliches Versagen" [Frick]. Leider gibt es keine Statistik, wie oft Piloten ein Versagen der Technik beherrschen mußten, um eine Katastrophe zu vermeiden. Diese Zahl dürfte aber höher als die erste sein.
Bei der zunehmenden rechnergestützten Kontrolle eines gesamten Systems rücken Rechner und Software mehr und mehr auf einen sicherheitsrelevanten (kritischen) Platz. Es gibt fünf Stufen für diese Kritikalität:
1. Rechner werden eingesetzt, um Benutzern auf Anfrage Informationen zu liefern.
2. Der Rechner interpretiert Daten und schlägt Handlungen vor. Der Benutzer entscheidet und handelt.
3. Der Rechner steuert direkt das technische System. Der Benutzer überwacht ihn und kann notfalls Maßnahmen ergreifen.
4. Der Mensch wird aus der Kontrollschleife entfernt, wodurch Rechnersteuerung und technisches System ohne menschliche Hilfe oder Wirkung selbständig arbeiten.
5. Der Rechner kann (darf) menschliche Anweisungen ignorieren (sogar im Störfall).
Stufe 1 begann in den 60'er Jahren. Inzwischen rücken wir mehr und mehr zu Stufe 4 und 5. Für Stufe 5 muß man sehr zuversichtlich sein. Den Rechnern werden immer kritischere Aufgaben zugetraut. Dabei darf man niemals vergessen, daß die Sicherheit nicht aus dem Vertrauen in die Technik kommt, sondern aus dem Mißtrauen.
Es sollte viel lieber ein Team Mensch-Maschine gebildet werden, wo beide Parteien miteinander kooperieren und sich ergänzen. Die Maschine kann besser schnell regeln als der Mensch, aber für die Behandlung von Ausnahmen und unvorhersehbaren Situationen ist der Mensch mit seiner Kreativität und Intuition weit überlegen.
Der Mensch begeht ständig Fehler und Ungenauigkeiten. Er macht niemals eine komplexe Aufgabe zweimal identisch [Gramm]. Trotzdem kann er die Aufgabe schaffen, weil er Abweichungen korrigiert, bevor sie negative Folgen haben. Die Maschine dagegen macht selten Fehler, wenn aber doch (z.B. Programmfehler), dann kann sie sie in der Regel nicht korrigieren und verläuft sich in undefinierte Zustände, die böse Folgen haben können. Bei den Menschen ist alles in Ordnung, solange sie Abweichungen korrigieren können. Bei den Maschinen ist dagegen alles in Ordnung, solange keine Fehler oder unvorhersehbare Zustände auftreten. Eine geeignete Kombination der Fähigkeiten kann ein starkes und sicheres Team bilden.
Bei der Interaktion Mensch-Maschine sollte jeder in der Lage sein, Fehler des anderen (Mensch: Bedienungsfehler; Maschine: echt dumme Fehler) abzufangen und zu korrigieren. Die menschlichen Fehler können durch Plausibilitätsprüfungen erkannt werden, die Maschinenfehler durch den gesunden Menschenverstand.
Risiken und Gefahren erkennen
Der "normale" Funktionsbereich eines Systems ist ein sehr schmales Band, der Fehlerbereich dagegen der Rest.
Ein kleiner Fehler oder eine unvorhersehbare Situation kann das System in den "Fehlerbereich" bringen. In der Regel werden diese Umstände erst erkannt, nachdem sie (negative) Folgen (oder gar einen Unfall) verursacht haben.
Dies ist besonders bei Software-, Bedienungs- und Kommunikationsfehlern der Fall. Je früher deren Eintreten erkannt wird, desto weicher und effektiver können die Maßnahmen sein. Daher ist es ratsam, Redundanz und Prüfmechanismen (Plausibilitätsprüfungen) vorzusehen.
Fehler können aus folgenden Stellen kommen:
Es gibt viele Gefahren: elektrische, thermische, chemische und mechanische durch Drehen, Fahren und aus gespeicherter Energie (z.B. einer Feder). Es ist bemerkenswert, daß es keine Softwaregefährdung gibt. Gefahr kommt aus dem ganzen System und nicht nur aus der Software. Meist werden die Gefahren jedoch durch Softwaresteuerungsfehler verursacht. Diese Fehler kommen aus folgenden Quellen: zu hohe Komplexität, niedrige Prüfberichte, schlechte Ausbildung der Entwickler, unzureichende Spezifikation, geringer Informationsaustausch zwischen Projektbeteiligten, Dokumentationsmängel, unsystematisches und unzureichendes Testen, Änderungen im Betrieb ohne vollständig neuen Test.
Um die Gefahren zu erkennen, hilft nur der gesunde Menschenverstand unterstützt von einigen Hilfstechniken: Definition gefährlicher Situationen, hazard analysis [Prüßner], Checklisten, fault tree analysis, event tree analysis und FMEA: Fehlerminimierung und Einflußanalyse.[Leveson]
Häufig führt nicht nur ein, sondern das Zusammentreffen mehrerer Umstände zu einem Unfall. Die Analysen enden meist beim Auftreten höchstens zweier gleichzeitiger Umstände. Die Geschichte jedoch hat gezeigt, daß normalerweise viele unwahrscheinliche Umstände zusammenkommen, die den ernstfall auslösen.
[./seminar/index.html]
Alle gefundenen Gefahren sollten ernst genommen werden. Oft wird der Fehler gemacht, daß eine so kleine Wahrscheinlichkeit für ein das Auftreten einer Gefahr berechnet wird, daß diese nicht weiter verfolgt wird. Dabei werden die Konsequenzen ignoriert, obwohl sie sehr groß sein können. Sehr oft geschah genau das bei großen Katastrophen. Die Wahrscheinlichkeit war so niedrig, daß keine Maßnahmen für den Notfall bereit waren. Klassisches Beispiel: Die Titanic hatte zu wenige Rettungsboote, weil sie "unsinkbar" war.
Per Definition "Risiko = Wahrscheinlichkeit des Eintreffens * Schwere der Folgen". Eine niedrige Wahrscheinlichkeit aber große Folgen ergeben ein Risiko, daß weiter beherrscht werden muß. Wann ist das Risiko klein genug, um ignoriert zu werden? Diese Frage kann nur das Gewissen beantworten.
Viele Unfälle kommen aus: Niedrige Priorität für Sicherheit, Übermäßiges Selbstvertrauen, Glaube an die Technik, Unzureichende Sicherheitsvorrichtungen (Sie sind schlimmer als überhaupt keine, weil sie nur ein Gefühl von Sicherheit geben und die natürliche Vorsicht abschalten.), Unrealistische Risikoeinschätzung, Annahmen über zeitbezogene Risikominimierung (Das fehlerfreie Laufen eines Systems über Jahre hinweg garantiert nicht seine Sicherheit. Die Gefahr kann auch mit der Zeit zunehmen, z.B. durch Alterung.) Ignorieren von Warnsignalen [Leveson] [Prüßner].
Gefahren beherrschen
Das Risiko kann man nicht ausschalten, man muß damit leben (oder sterben). Aber man sollte es mindestens beherrschen können und einen Ausweg vorbereitet haben. Dazu werden folgenden Prioritäten empfohlen: 1. Gefahrenstellen vermeiden oder eliminieren. 2. Die Wahrscheinlichkeit eines Unfalls minimieren. 3. Maßnahmen vorbereiten, um aus gefährlichen Situationen herauszukommen. 4. Für jeden möglichen Unfall Konsequenzen minimieren und Schäden begrenzen.
Ein Beispiel aus der Bahntechnik: der Bahnübergang.
1. Gefahr eliminieren: eine Brücke bauen.
2. Wenn 1 nicht machbar ist, Wahrscheinlichkeit eines Unfalls minimieren: Schranke und Warnsignale einbauen.
3. Notmaßnahmen für jede gefährliche Situation: Falls ein Auto zwischen den Schranken eingesperrt bleibt: a) Platz frei lassen, so daß es sich in Sicherheit bringen kann. b) Automatische Notbremse im Zug plus die nötigen Sensoren.
4. Rettungsmaßnahmen für den Unfall vorbereiten: a) Automatische Notbremse im Zug, um den Zusammenstoß zu lindern. b) Automatischer Notruf, Verbandkasten (wenn es noch hilft).
Aber Vorsicht: Die Sicherheitsmaßnahmen können neue Gefahren mit sich bringen. Die neuen Elemente erfordern eine neue Gefahrenanalyse. Ohne Schranke im Bahnübergang besteht nicht die Gefahr, ein Auto einzusperren. Diese neue Gefahr muß wiederum wie oben genannt behandelt werden. 1. Priorität ist, die Gefahr zu eliminieren, z.B. Schranken nur auf der rechte Straßenseite einbauen.
Die Notmaßnahmen in Punkt 3 und die Rettungsmaßnahmen in Punkt 4 können folgendermaßen nach VDI/VDE 2180 dargestellt werden:
Als erstes müssen die Notmaßnahmen aktiviert werden, um das System zum Gutbereich zurückzubringen (weiche Maßnahmen). Dadurch wird die Verfügbarkeit des Systems gesteigert. Wenn das nicht hilft, muß das System in einen Fail-Safe Zustand (Halt) gebracht werden (harte Maßnahme). Wenn das auch nicht ausreicht und ein Unfall stattfindet, müssen Maßnahmen zur Schadensbegrenzung aktiviert werden.
Hier einige Sicherheitsvorschriften aus der Bahntechnik:
[./seminar/index.html] Ausfälle, mit denen zu rechnen ist, dürfen sich nicht gefährlich auswirken. Sicherheitsanlagen müssen signaltechnisch sicher sein (fail-safe). Ein einzelner Fehler darf nicht zu einem unzulässigen Fehlzustand führen. Ein Fehler soll möglichst sofort angezeigt werden. Macht sich ein Fehler nicht bemerkbar, so soll kein unzulässiger Fehlzustand auftreten, wenn ein zweiter Fehler hinzukommt. Anlagenteile, in denen ein zweiter oder weiterer Fehler eine Betriebsgefahr verursachen könnte, müssen in regelmäßigen Zeitabständen auf Fehlerfreiheit geprüft werden.
Literatur
Mein Buch: Sichere und Fehlertolerante Steuerungen
T. Gramm, Technisches und menschliches Versagen - ein Abgrenzungsproblem. VDI Bericht 1336, 1997
F. Frick, Menschliches Versagen. Bild der Wissenschaft, Mai 1997
N. Leveson, Safeware: system safety and computer. Addison-Wesley, 1995.
J. L. Lions ARIANE 5, Flight 501 Failure
http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html
L. Prüßner. Hazardanalyse ESPRESS-Seminar Ausarbeitung an der TU-Berlin 1996.
./seminar/ index.html