Das Pendeln zwischen Sicherheit und Gefahr

Sergio Montenegro (.)
GMD-FIRST (http://www.first.fhg.de)

 

Jeder Schritt, den wir täglich gehen, ist ein Pendeln zwischen einem sicheren stabilen Zustand und einem unsicheren und instabilen. Wir gehen mit Sicherheit und Gefahr Hand in Hand. Man merkt es nur, wenn man die Sicherheit braucht und sie nicht vorhanden ist. Erst dann merkt man, wie wichtig die Sicherheit ist, aber dann ist es meistens schon zu spät. Die Sicherheit braucht man angesichts einer Gefahr, die meistens aus der Umgebung kommt, die wir selbst für uns geschaffen haben, z.B. aus den Maschinen selbst, die uns helfen sollen, aber bei denen die Sicherheitsaspekte nicht im Vordergrund stehen, und das ist meistens der Fall. Es wird mehr in die Funktionalität der Maschinen als in ihre Sicherheit investiert.

Um sich vor diesen Gefahren zu schützen, werden Sicherheitsmaßnahmen und Einrichtungen benutzt, die keine absolute Sicherheit garantieren können. Trotzdem können die Geräte dadurch beim Benutzer so viel Vertrauen erlangen, daß wir ihnen unser Leben blind anvertrauen, z.B. Autos, Ampeln, medizinischen Geräten usw.. Durch die Routine ist man sich kaum noch bewußt, daß deren Versagen tödliche Folgen haben können. D.h., wir vertrauen voll in ihre Sicherheit und Zuverlässigkeit dank der Routine und der eingebauten Sicherheitsfunktionen. Und um so schlimmer ist dann eine Fehlfunktion, mit der keiner gerechnet hat. Deswegen ist gar keine Sicherheit besser als eine falsche oder schlecht implementierte Sicherheit, die uns nur täuscht. Denn man verläßt sich darauf und vergißt die natürliche Vorsicht. Eine offensichtliche Gefahr ist viel besser als eine versteckte oder vertuschte. Die letztere ist nichts anderes als eine Falle -- und genau das erschafft man mit einer falsch implementierten Sicherheit. Unsere persönliche Sicherheit erwächst nicht aus dem Vertrauen in die Technik, sondern aus dem Mißtrauen. Und so sollten alle diese Anlagen entwickelt und betrieben werden: mit Mißtrauen gegen alle Komponenten, Prozesse und Annahmen, insbesondere gegenüber der Steuerung. Ein Winterreifenhersteller schreibt in seine Werbung "Power is nothing without control" aber viel zutreffender ist "Power is dangerous without control".

Sicherheit und ähnliches

Sicherheit ist nicht das einzige, das wir von einer Anlage erwarten. 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, ist aber nicht sicher. Was wir brauchen ist Verläßlichkeit, d.h. daß das System seine Aufgabe erfüllt. Die Verläßlichkeit besteht, wie es in der Abbildung 1 dargestellt ist, aus:

 

Aber Vorsicht: Ist ein System als sehr zuverlässig bewertet worden, heißt das nur, daß wenige Fehler sich bemerkbar machen. Absolute Verläßlichkeit ist in technischen Systemen kaum möglich.

Die Verläßlichkeit einer Anlage baut auf zwei Aspekten auf:

 

Der Weg dorthin hat vier Schritte:

 

Einerseits muß man versuchen, Fehler bei der Entwicklung zu vermeiden, andererseits muß man Fehler, die man nicht vermeiden konnte, beseitigen, was voraussetzt, daß man sie bis dahin erkannt hat (z.B. durch Tests). Aber viele Entwicklungsfehler werden unentdeckt bleiben und stellen eine latente Gefahr dar. Mit diesen Fehlern muß man leben (oder sterben) -- deswegen muß die Steuerung darauf vorbereitet sein, beim Auftreten möglicher Gefahren wie beispielsweise beim Ausfall einer Hardwarekomponente, aber auch bei einem Steuerungsfehler (meistens Software) selbst, richtig zu reagieren, so daß das System in einem sicheren Zustand verbleibt oder noch besser, sicher weiterarbeitet.

Die Natur der Fehler

Ein Fehler ist die Ursache für unerwünschte Resultate und kann bei den Menschen (Bediener) oder bei den Maschinen liegen. Aus der Umgebung können auch unerwartete Zustände kommen, die ebenso unerwünschte Resultaten erzwingen.

 

Alle Bestandteile des Systems sind fehlergefährdet, wie es in der Abbildung 2 dargestellt wird. Aber nicht alle Bestandteile sind in gleicher Weise gefährdet. Maschinenfehler, die zu katastrophalen Konsequenzen führen, sind in erster Linie Steuerungsfehler. Die meisten davon kommen aus unvorhersehbaren Situationen. Solche Fehler können als Spezifikationsfehler klassifiziert werden. An zweiter Stelle stehen die Entwicklungsfehler (meist aus der Software). Diesen Fälle gingen aus einer korrekten Spezifikation hervor, wurden aber falsch entworfen und/oder implementiert. Ab der dritten Stelle kommen die Fehler wegen mechanischer Abnutzung (mangelhafte Wartung) und Ausfall von elektronischen Komponenten. Diese Sorten von Fehlern treten meistens in den ersten Betriebsstunden oder nach sehr langer Betriebszeit auf (siehe Abbildung 3, die Badewannenkurve).

 

Bei sicherheitskritischen Systemen, werden Ausfälle in der Altersschwäche-Phase durch regelmäßige Wartung und Überholungen, wie z.B. bei den Flugzeugen, minimiert. Die Ausfälle in der "Kindersterblichkeitsphase" werden durch ein "Burn-in" -Verfahren minimiert. Dabei werden die elektronischen Komponenten bei ca. 100 Grad über 24 Stunden betrieben. Hierbei fallen viele der schwachen Komponenten aus, und es bleiben fast nur die, die ihr Arbeitsleben anfangen können.

Fehler können, wie es in der Abbildung 4 dargestellt wird, folgendermaßen klassifiziert werden:

 

Quelle

Die Entwicklungsfehler sind permanente Fehler, aber sie machen sich nur unerwartet bemerkbar (sonst würde man sie kennen und korrigieren können). Einige davon können durch Testen entdeckt werden, andere aber bleiben unentdeckt und stellen eine latente Gefahr dar.

Die Laufzeitfehler treten nachträglich ins System ein und werden z.B. durch Hardwareausfälle, mechanische Abnutzung, unerwartetes Umgebungsverhalten, Bedienungsfehler, Kommunikationsfehler, vorübergehende Überlastung (Timing-Fehler, Deadline- Überschreitungen) u.a. verursacht.

Art

Die permanenten Fehler bleiben nach ihrem Eintreten erhalten, bis sie repariert werden. Die sporadischen Fehler kommen und gehen spontan und sind nicht reproduzierbar, bis man ihre Ursache gefunden hat (z.B. ein lockerer Kontakt). Die bedingten Fehler werden durch Störungen wie z.B. Temperatur, Strahlung, Vibrationen verursacht und sind bedingt reproduzierbar.

Bereich

Die Korrektheit der Echtzeit-Tasks besteht nicht nur darin, einen korrekten Output-Wert zu generieren, sondern auch zum richtigen Zeitpunkt, und nicht einfach "so schnell wie möglich". Wenn die Reaktion nicht in den vorgesehenen Reaktionszeitfenstern stattfindet, ist es ein Fehler, der zum Systemausfall führen kann, z.B das Ausschalten der Wärmequelle eines Kessels, bevor er explodiert. Jede Reaktion hat also ein Wert und ein Zeitfenster. Daher können Fehler im Wertbereich und/oder Zeitbereich klassifiziert werden. Das Nicht-Einhalten der vorgesehenen Reaktionszeitfenster kann durch Entwicklungsfehler aber auch durch Laufzeitfehler verursacht werden. Entwicklungsfehler liegen vor, wenn die Worstcase-Berechnungen oder Annahmen über das Eintreten von Ereignissen falsch waren oder wenn Annahmen über den Real-Time-Scheduler falsch waren. Es handelt sich um Laufzeitfehler, wenn das System vorübergehend außerhalb der vorgesehenen Parameter arbeitet oder wenn der Scheduler eine theoretisch beherrschbare Belastung (Leistung) praktisch nicht erbringen kann. Außer Wert- und Zeitbereichsverletzungen können auch Aktionen unaufgefordert stattfinden ("Fehler: Unaufgefordert"), wenn sie nicht nötig oder sogar nicht angebracht waren, z.B. ein Roboterarm bewegt sich plötzlich ohne einen sichtbaren Grund.

Der direkte Weg vom Fehler zum Unfall

Nach den Eintreten eines Laufzeitfehlers oder nach dem ein Entwicklungsfehler sich bemerkbar gemacht hat, kann ein Ausfall oder sogar ein Unfall eintreten (so wie es in der Abbildung 5 dargestellt wird).

 

 

Einige Fehler können ein unkontrolliertes Verhalten verursachen, welches mit einem Unfall enden könnte. Andere Fehler können die Steuerung zum Stillstand bringen, wie z.B. Fehler im Prozessorkern, was auch einen Unfall verursachen kann. Andere Fehler führen zu falschen Ergebnissen oder Handlungen, welche Folgefehler bei den Modulen, die diesen Daten benutzen, verursachen können. Diese Folgefehler können wiederum Schritte auf den Weg zu einem Unfall sein.

Fehler und Ausfälle pflanzen sich im System fort. Ein unbehandelter Fehler in einem kleinen Modul (z.B. ein Drucksensor) kann seinen Ausfall bedeuten. Dieser Ausfall verursacht einen Fehler in seinem übergeordneten Modul (z.B. ein regulierter Dampfkessel). Bleibt der Fehler unbehandelt, kann er den Ausfall dieses Moduls verursachen und so weiter, bis die ganze Anlage ausfällt oder ein Unfall geschieht, so wie es in der Abbildung 6 dargestellt wird.

 

Die Fehler pflanzen sich in der Modulhierarchie nicht nur vertikal (aufsteigend) fort, sondern auch horizontal entlang der Datenfluß-Pfade des Systems. Jedes Modul, das ungeachtet falsche Input-Daten benutzt, wird auch falsche Ergebnisse liefern (siehe Abbildung 7).

 

Auf diesem Weg kann ein einziger Transistorausfall oder ein Programmfehler den Ausfall einer Anlage mit 10^9 Transistoren und einigen Millionen Lines-of-code und vielen anderen Komponenten verursachen. 10^9 Transistoren und Millionen-lines-of-code ist bereits üblich, und daß etwas ausfallen wird (gerade dann, wenn man es nicht erwartet), ist so gut wie sicher. Der Ausfall eines Moduls bedeutet nicht, daß es defekt ist. Es reicht, daß eines seiner Submodule einen Fehler verursacht hat. Ein unbehandelter Fehler impliziert auch nicht einen Ausfall. Er kann unbemerkt bleiben oder sich erst zu einem viel späteren Zeitpunkt bemerkbar machen. So kann viel Zeit vergehen zwischen dem Eintreten des ersten Fehlers und dem Systemausfall.

Sowohl Fehler als auch Unvorhersehbares können Ausfälle und Unfälle verursachen. Der Umgang mit Unvorhersehbarem ist allerdings schwieriger als mit Fehlern, weil es sich hierbei um Ereignisse und Sachen handelt, an die keiner gedacht hat. Schlimmer noch ist die Vorstellung, daß die meist unkreative und dumme Steuerung ganz alleine mit unbekannten Zuständen, die nicht einmal ihr Schöpfer (Ingenieur) kannte, zurechtkommen soll. Dagegen hilft nur eins: "an alles denken" -- sagten sie mir,als ich klein war. Was man jedoch machen kann, ist zumindest Klassen von unerwarteten Zuständen zu bilden und eine passende Notreaktionen für jede Klasse bereitzuhalten.

Der "normale" Funktionsbereich eines Systems ist ein sehr schmales Band, der Fehlerbereich dagegen der Rest (siehe Abbildung 8).

 

 

Ein am Anfang kleiner Fehler oder eine unvorhersehbare Situation kann sofort oder viel später das System in den "Fehlerbereich" bringen. Im Fehlerbereich kann sehr leicht die Kontrolle über die Anlage verloren gehen, besonders, weil es in undefinierten Zuständen arbeitet, für die die Steuerung nicht konzipiert ist. So kann ein Fehler, besonders ein Prozessorkern-Fehler, unvorhersehbare Zustände verursachen, und unvorhersehbare Zustände können auch Fehler verursachen. Und wie es in der Abbildung 2 dargestellt wird, bleibt nichts davor verschont.

Leider werden häufig Ausnahmezustände erst erkannt, nachdem sie (negative) Folgen (oder gar einen Unfall) verursacht haben (siehe Abbildung 9). Dies ist besonders bei Software-, Bedienungs- und Kommunikationsfehlern der Fall. Je früher das Eintreten eines Fehlers erkannt wird, desto weicher und effektiver können die Korrekturmaßnahmen sein. Daher ist es ratsam, Redundanz und Prüfmechanismen (Plausibilitätsprüfungen) vorzusehen.

 

 

Die Steuerung muß so konstruiert sein, daß sie immer in Bereitschaft ist, um Anomalien, Fehler und weitere Ausnahmen abzufangen und zu behandeln, so daß keine Gefahr entstehen kann. Die Fehlertoleranzmaßnahmen sorgen dafür, daß das System, trotz Fehler, unbeschwert weiter arbeitet. Dies erfordert einen sehr hohen Entwicklungsaufwand, und oft ist das nicht nötig. Oft reicht es, eine Nothalt-Funktion zu aktivieren, um das System in einen sicheren Halt-Zustand zu bringen. Eine Fehlerbehandlung soll folgendem Schema folgen: (siehe Abbildung 10) Fehler tritt ein, Fehler wird erkannt, Fehler wird gemeldet, es werden weitere Folgen des Fehlers verhindert, Fehler wird behandelt (Fehlertoleranz), Fehler wird behoben (Reparatur), weiter arbeiten.

 

 

Aber wenn keine geeigneten Maßnahmen für die Fehlerbehandlung bereitliegen, dann ist unser Schicksal dem Zufall überlassen, so wie es in der Abbildung 5 dargestellt wird. Wenn wir Glück haben, tritt nach einem Fehler ein Systemausfall (Nichtausführung der vorgesehenen Funktion zur festgesetzten Zeit) ohne weitere Konsequenzen ein. Wenn wir Pech haben, tritt ein Unfall ein mit eventuell katastrophalen Folgen. Danach bleibt es nur, Maßnahmen für die Schadensbegrenzung zu unternehmen. Es gibt auch (sporadische) Fehler, die sich nicht bemerkbar machen, und der Betrieb kann ungestört weitergehen. Man darf sich darauf aber nicht verlassen.

Das System in seiner ungewissen Umgebung

Das System ist in seine Umgebung integriert und kann nicht alleine betrachtet werden. Das gleiche gilt für jede Komponente des Systems, und jede Komponente ist auch ein Teil der Umgebung der anderen Komponenten. Jede Komponente und das System selbst haben eine geplante Interaktion mit ihrer Umgebung,z.B. Befehle, Zustandserfassung oder physikalische Wirkung. Aber oft genug wird vergessen, daß es auch eine ungeplante und unerwünschte Interaktion gibt, wie thermische Einflüsse (z.B. Winter/Sommer, interne Wärmequellen), Vibrationen, Strahlungen, Elektromagnetismus (z.B. durch Starkstrom), chemische Reaktionen u.a. Besonders bei Steuerungen und eingebetteten Systemen sind die externen und die internen unerwünschten Einflüsse extrem hoch. Z.B. das Einschalten von Motoren erzeugt starke elektromagnetische Wellen, die Steuerung für einen Backofen oder ein Bügeleisen wird sehr warm werden usw. Die Abbildung 11 zeigt die Komponenten eines eingebetteten Systems mit ihren Interaktionen. Daraus wird deutlich, daß es mehr Quellen für ungeplante Interaktionen gibt als für geplante. Außerdem kann jede geplante Interaktion gestört werden und dadurch zu einer ungeplanten werden. Das einzige, das wir mit Sicherheit wissen können, ist, daß wir mit großer Ungewißheit arbeiten. Aber leider wird das oft ignoriert, und dadurch enstehen viele Gefahren.

 

 

Man kann die ungeplanten Interaktionen mit Abschirmung, Schutzeinrichtungen u.a. begrenzen, aber nicht ausschalten. Besonders deshalb nicht, weil wir sie nicht alle im voraus kennen. Deswegen muß das System immer für das Unerwartete und Unvorhersehbare vorbereitet sein.

Auch wenn die Umgebung durch die geplanten Wege erfaßt und beeinflußt wird, ist ihr Verhalten meistens nicht deterministisch und nicht vorhersehbar. Dies verursacht ein ungewisses Verhalten des Systems. Weiterhin kann die Umgebung nicht vollständig bei der Systemspezifikation erfaßt werden. Deswegen werden Vermutungen und Annahmen gemacht, u.a. um die Komplexität zu reduzieren. Leider kann der Spezifikator meistens zwischen Annahmen und Tatsachen nicht unterscheiden. Oft ist ihm nicht einmal bewußt, daß er nur auf Annahmen baut. Sind die Annahmen falsch, so fällt damit alles zusammen. Die Richtigkeit der Annahmen wird normalerweise nicht geprüft. Fehler, die auf falschen Annahmen beruhen, werden in der gesamten Entwicklung und auch beim Testen nicht entdeckt (man testet, was man angenommen hat), sondern fallen irgendwann in der Anwendungsphase auf. Diese Fehler können Systemausfälle und gefährliche Situationen verursachen. Obendrein ändert sich die Umgebung mit der Zeit (Verschleiß, Alterung, neue Bedingungen) aber die Steuerung (Software + Hardware) ändert sich nicht von selbst. Deswegen muß die Steuerung so konzipiert sein, daß sie sich an die Umgebung ständig anpassen kann.

Katastrophen werden meistens von Ereignissen verursacht, die keiner erwartet hatte. Die (böse) Überraschung kommt von dort, wo man sie nicht erwartet, sonst wären sie keine Überraschungen und die Katastrophe wäre nicht geschehen (es sei denn, jemand hat unverantwortlich gehandelt). Es kann auch passieren daß eine Gefahrensituation bekannt war, aber sie wurde als so unwahrscheinlich eingestuft, daß man sie ignoriert hat. Aber man soll nicht vergessen: Nichts ist unmöglich, besonders dann nicht, wenn man es nicht haben will.

Beispielsweise geschehen viele Unfälle nicht dort wo man denkt es wäre die gefährlichste Stelle, sondern dort wo man denkt die Gefahr wäre vorbei. Bei der gefährlichsten Stelle ist die Gefahr vorhanden, aber wir sind wachsam. Bei der scheinbar ungefährlichen Stelle ist auch eine Gefahr vorhanden, auch wenn kleiner, aber wir sind nicht wachsam und werden dadurch überrascht.

Wenn die Zeit drängt und die Entwicklung noch nicht fertig ist, ist das erste Opfer die Sicherheit. Der Grund dafür ist, daß man die Sicherheit nicht sehen kann, und ihren Wert schätzt man erst, wenn man sie braucht. Das zweite Opfer ist die Erkundung der Systemumgebung. Man denkt, man weiß schon genug, und der Rest wird nicht so wichtig sein. Die Geschichte hat gezeigt, daß das ein Irrtum ist. Meistens knallt es an der Schnittstelle zwischen dem System und seiner Umgebung. Dies kann man immer wieder sehen. Und nach der Katastrophe heißt es: "Wenn wir das gewußt hätten.....".

Ein Beispiel über den Umgang mit dem Ungewissen: Wir wollen an einem Tag ein unbekanntes Haus gegen Diebe, Einbrecher & Co sichern. Wir suchen und finden 3 Türen, es gibt aber 10! Den Rest des Tages benutzen wir, um die gefundenen 3 Türen ganz sicher zu schließen und dann denken wir, das Haus sei sicher. Nachts kommt der Dieb ungestört durch eine offene Tür, die wir nicht gesehen hatten (siehe Abbildung 12). Dann sagen wir "Wenn wir das gewußt hätten,....". Aber wir wußten doch, daß es mehr (Gefahren) gab als wir kannten. Das nächste Mal benutzen wir lieber den Rest des Tages, um weitere Türen zu suchen. Übrigens -- die abgesicherte Tür in der Abbildung geht nach außen auf!

 

Weitere Referenzen

Mein Buch: Sichere und Fehlertolerante Steuerungen

./public
Verschiedene Publikationen und Informationen zum Thema Sicherheit und Echtzeit.

./seminar
Seminar an der Technischen Universität Berlin über Sicherheit, Hazard-Analyse, Fehlertoleranz, Analysen von Unfälle und Entwicklung sicherheitsrelevanter eingebetteter Systeme.

http://www.first.fhg.de/~espress
Das Vorhaben ESPRESS zielt auf eine breite Verbesserung der Produktivität bei der Entwicklung komplexer, sicherheitsrelevanter, eingebetteter Systeme und auf eine Steigerung der Verläßlichkeit der Systeme selbst.

Neil Storey: Safety-critical computer systems; Addison-Wesley, 1996
Sicherheitsaspekte, Fehlertoleranz, Hazard-Analyse, Risiko-Analyse, Entwicklung von sicherheitsrelevanten Systemen, Formale Methoden.

N. Leveson, Safeware: system safety and computer; Addison-Wesley, 1995.
Hazard-Analyse, Ursachen und Konsequenzen von Unfällen, Entwicklung von sicherheitsrelevante Systemen.