Analysen der Anlagen-Sicherheit und -Gefahren (Hazard-Analyse)

S. Mohr & S. Montenegro (.)

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

(1.2)

Unser tägliches Leben ist geprägt durch Maschinen, denen wir blind unser Leben anvertrauen, z.B. Autos, Ampeln, medizinische Geräte und Energieanlagen. Wir vertrauen voll in ihre Sicherheit und Zuverlässigkeit - dank der Routine und der eingebauten Sicherheitsfunktionen. Um so schlimmer ist dann eine Fehlfunktion, mit der keiner gerechnet hat. Dies oder ein Bedienungsfehler kann in einigen Fällen tödliche Folgen haben. Wir sehen es als normal an, daß die Anlagen richtig und sicher funktionieren. Dabei ist der "Normale Bereich" im Funktionsspektrum einer Anlage ein sehr schmales Band, in dem sich das System aufhalten muß. Der Fehlerbereich ist dagegen der Rest: unendlich groß. Um das System in diesem schmalen Band zu halten, muß man Energie und Steuerung kontinuierlich fließen lassen, so wie um eine Kugel in einem instabilen Gleichgewicht zu halten. Eine kurze Unterbrechung oder eine kleine Anomalie dieses Flusses kann zu Unfällen oder sogar Katastrophen führen.

Um das zu verhindern, muß man für ALLES, was passieren kann, immer einen Ausweg bereit halten. Alles was nicht vor(her)gesehen wurde, stellt eine latente Gefahr dar. Das zentrale Problem dabei ist, zu erkennen, was geschehen kann. Die Antwort ist einfach: Alles! Jedes Teil wird einmal versagen, wenn ein Bedienungsfehler möglich ist, wird ihn jemand machen, aus der Umgebung werden Ereignisse kommen, mit denen keiner gerechnet hat, usw. Kurz: "Unverhofft kommt oft", aber noch zutreffender: "Es kommt, was keiner erwartet hat".

Ein Grundsatz bei den sicherheitsrelevanten Systemen ist: Ausfälle und Umstände, mit denen zu rechnen ist, dürfen sich nicht gefährlich auswirken. Dafür ist es lebensnotwendig, so viele Gefahren wie möglich im voraus zu identifizieren. Dabei hilft nur der gesunde Menschenverstand unterstützt von den Hazard-Analyse Techniken. Sie sind nur eine Unterstützung, um ein System auf potentielle Gefahren hin zu untersuchen und können nicht Ihre Kreativität ersetzen. In diesem Artikel werden wir zuerst den Feind kennen lernen: Gefahr, Fehler und Unfälle. Danach widmen wir uns einigen Punkten, um Ihre Kreativität zu unterstützen und am Ende stellen wir Ihnen noch einige praktische Techniken vor.

Man soll mit den Hazard-Analysen bereits sehr früh (schon bei der Systemkonzeption) anfangen. Aber die Hazard-Analyse ist kein Prozeß, der nur zu Beginn oder zu irgendeinem Zeitpunkt im Verlauf der Systementwicklung abläuft und dann abgeschlossen ist, sondern sie wird während des gesamten Entwicklungsprozesses weitergeführt, wie die Abbildung 1 zeigt. Jede Entwicklungsphase bringt neue Erkenntnisse und dadurch können neue Gefahren identifiziert werden. Deshalb soll die Hazard-Analyse den gesamten Entwicklungsweg begleiten.

 

Gefahr, Fehler und Unfälle

Gefahr

Gefahr (Hazard) ist eine Situation, in der eine tatsächliche oder eine potentielle Bedrohung für Menschen oder die Umgebung besteht. Diese Bedrohung kann zu einem Unfall führen. Dabei muß man sowohl Situationen betrachten, die vom System herbeigeführt werden können, als auch solche, die von der Umgebung auf das System einwirken können. Bei größeren Systemen kann eine Hazard-Analyse deshalb sehr komplex werden, denn auch die Kombinationen von Ereignissen werden untersucht. Bei Untersuchungen von schweren Unfällen hat sich ergeben, daß erst die Kombination von mehreren Ereignissen zur Katastrophe geführt hat.

Trotzdem ist es menschlich nicht möglich, alles in voraus zu sehen, deswegen bleibt bei jedem System eine verborgene Rest-Gefahr und dessen muß man sich bewußt sein. Das Risiko (die Quantifizierung der Gefahr) kann man nicht ausschalten, man muß damit leben (oder sterben). Per Definition:
Risiko = Wahrscheinlichkeit * Folgen

Risiko ist eine Kombination aus der Wahrscheinlichkeit des Eintreffens und der Schwere der Folgen eines Unfalls. Viele versuchen, das Risiko durch diese einfache mathematische Formel zu quantifizieren. Man kann einen genauen Wert mit vielen signifikanten Stellen berechnen, aber die Input-Daten (Wahrscheinlichkeit und Folgen) sind nur grobe und subjektive Abschätzungen. Oft hat man eine extrem kleine Wahrscheinlichkeit aber enorme Folgen, wie z.B. bei dem Risiko von Atom-Reaktoren. Die Fürsprecher reden nur von der Wahrscheinlichkeit und die Gegner nur von den Folgen. Man muß aber beide Werte multiplizieren und das Ergebnis dieser Multiplikation hilft auch keinem weiter. Denn die Frage nach dem akzeptablen Risiko kann man nicht mit Zahlen beantworten. Eine wissenschaftliche Analyse des Risikos endet bei der Frage nach der Vertretbarkeit. Sie kann nur die Größe des Ausmaßes klären, nicht aber eine Bewertung vornehmen. Meist tragen die Verursacher der Risiken die Folgen eines Unfalls nicht selbst, sondern die Arbeiter, die umliegende Bevölkerung oder die Benutzer (Kunden). Anstatt Zahlen zu liefern, machen Sie lieber alles was menschlich möglich ist, um das Risiko zu minimieren. Die Frage "Wann ist das Risiko klein genug, so daß es ignoriert werden kann?" kann nur Ihr Gewissen beantworten. Es muß aber ein Unterschied gemacht werden zwischen unbekannten Risiken und Risiken, die aus Kostengründen bewußt eingegangen werden. Wobei viele unbekannte Risiken nur aus Kosten- und Zeitdruck unbekannt bleiben.

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 Resultate 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. An zweiter Stelle stehen die Entwicklungsfehler (meist aus der Software). Diese Fälle gingen aus einer korrekten Spezifikation hervor, wurden aber falsch entworfen und/oder implementiert. An dritter 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.

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

  • Quelle: Entwicklungsfehler / Laufzeitfehler,
  • Art: Permanente / Sporadische / Bedingte Fehler,
  • Bereich: Wert / Zeit / unaufgeforderte Aktionen.

 

A) 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.

B) 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.

C) Bereich

Die Korrektheit der Echtzeit-Tasks besteht nicht nur darin, einen korrekten Output-Wert zu generieren, sondern auch zum richtigen Zeitpunkt. 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 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.

Fehler und Unfälle

Nach dem Eintreten eines Laufzeitfehlers oder nachdem ein Entwicklungsfehler sich bemerkbar gemacht hat, kann ein Ausfall oder sogar ein Unfall eintreten (so wie es in der Abbildung 4 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 in den Modulen, die diese Daten benutzen, verursachen können. Diese Folgefehler können wiederum Schritte auf den Weg zu einem Unfall sein.

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 Notreaktion für jede Klasse bereitzuhalten.

Obwohl, scheinbar, die Unfälle durch Komponentenausfall, Entwicklungsfehler, unerwartete Ereignisse oder Bedienungsfehler verursacht werden, haben sie tiefere Grundursachen wie z.B:

- Übermäßiges Selbstvertrauen und Selbstzufriedenheit
- Nichtberücksichtigung des Risikos
- Verlaß auf Redundanz und auf die "sichere" Technik
- Unrealistische Risikoeinschätzung (z.B. numerische Einschätzungen)
- Ignorieren von Ereignissen mit großen Folgen und kleiner Wahrscheinlichkeit
- Annahmen wie: "Wenn jahrelang nichts passiert ist, wird auch heute nichts passieren."
- Unterschätzung der softwarebezogenen Risiken
- Ignorieren von Warnsignalen (z.B. Vorfälle)
- Niedrige Priorität für Sicherheit
- Fehlerhafte Auflösung konkurrierender Ziele (z.B. Risiko um Zeit oder Geld zu sparen)
- Es werden Patches benutzt, um spezifische Ursachen und nicht die Designfehler zu eliminieren.
- Das Design von Sicherheitsvorrichtungen basiert auf falschen Annahmen

Daran sollen Sie denken

Sehr oft kommen die Katastrophen aus extrem unwahrscheinlichen Kombinationen von Ereignissen oder Fehlern, oder aus Sachen an die keiner gedacht hat, oder aus sehr einfachen Fehlern, weil diese so einfach sind, daß keiner einen zweiten Gedanken damit verschwenden wollte. z.B. wenn bei der Beschriftung "Min" und "Max" vertauscht werden, kann dadurch ein "Bedienungsfehler" mit katastrophalen Folgen entstehen.

Dagegen hilft nur ein Brain-Storming und denken an "alles" was möglich ist, aber auch an das, was unmöglich scheint. Sie können eine Liste von allen Einfällen machen, auch wenn sie noch so verrückt erscheinen (die Realität läßt sich nicht von unserer Bewertung von verrückt und vernünftig beeinflussen). Wenn Sie nichts mehr wissen, beschreiben Sie Ihr System einem Kind und fragen Sie es, was passieren kann. Sie werden von den vielen verrückten Vorschlägen erstaunt sein , die dennoch eintreten können. Denken Sie an die Dinge, die Ihnen unmöglich scheinen und beschreiben Sie warum sie unmöglich sind und niemals eintreten werden. Sie werden feststellen, daß diese Sachen nicht so unmöglich sind, wie sie am Anfang erschienen und ein zweiter Gedanke wird Ihnen zeigen, wann sie eintreten können oder werden. Sie werden dann vielleicht denken: "Gut, es ist nicht unmöglich, aber fast unmöglich". Oft wird der Fehler gemacht, daß eine Gefahr für so unwahrscheinlich gehalten wird, daß sie nicht weiter untersucht wird. Dabei werden die Folgen der Gefahr ignoriert, obwohl sie enorm sein können. Wenn es nicht unmöglich ist, wird sie irgendwann eintreten! Dies ist sehr oft der Fall bei großen Katastrophen gewesen. Die Wahrscheinlichkeit für solche Katastrophen war so niedrig, daß keine Maßnahmen für den Fall bereit waren. Klassisches Beispiel: Die Titanic, weil man sie für unsinkbar hielt, hatte man zu wenig Rettungsboote vorgesehen.

Eine Gefahr darf nur auf Grund von minimalen Folgen und nicht von minimaler Wahrscheinlichkeit ignoriert werden.

Es ist auch häufig nicht nur eine bestimmte Ursache, die zu einem Unfall führt, sondern das Zusammentreffen vieler Umstände (z.B. die Schraube war locker, das Not-Ventil war nicht geschlossen, der Druck war zu hoch und der Operator war gerade auf dem Klo). Dadurch scheint die Wahrscheinlichkeit für diesen Fall wiederum noch niedriger zu sein. Jeder der zusammenkommenden Umstände ist meistens nicht ausreichend, aber doch nötig, um die Katastrophe auszulösen. Diese Tatsache macht die Hazard-Analyse sehr kompliziert: Der Ingenieur muß mit der Kombination vieler gleichzeitiger oder zusammenkommender Umstände spielen. Dadurch erhält man Millionen und Billionen von Kombinationsmöglichkeiten. Meistens wird man müde und die Analysen enden bei 2 oder höchsten 3 zusammenkommenden Umständen. Dies bedeutet immerhin einige tausend Kombinationen. Viele Kombinationen sind aber nicht relevant und brauchen nicht weiter untersucht zu werden. Trotz aller Anstrengungen bleiben einige Millionen von Kombinationen unberücksichtigt. Leider ist mir kein Werkzeug bekannt, um dieses Verfahren zu unterstützen. Dabei hilft nur, nicht müde zu werden und so viele relevante Kombinationen wie möglich zu untersuchen.

Eine allgemein falsche Annahme ist die Unabhängigkeit von Ereignissen oder Komponentenausfällen. Ein unbedachtes Ereignis kann der Auslöser für viele andere scheinbar voneinander unabhängigen Ereignissen sein und dadurch treten wiederum viele Ereignisse gleichzeitig auf, deren gemeinsames Eintreten vorher für äußerst unwahrscheinlich gehalten wurde. Es schien z.B. extrem unwahrscheinlich zu sein, daß zwei redundante Steuerungseinheiten mit getrennten Netzteilen (Stromversorgung) gleichzeitig ausfallen würden. Leider hat der Systemintegrator beide Netzteile an einem einzigen Stecker angeschlossen und jemand ist über dieses Kabel gestolpert. Schon hat man den fast unmöglichen Fall.

Als Denkhilfe können Sie für den Anfang der Analyse folgende Liste von Gefahrenquellen benutzen: elektrische, thermische, chemische, mechanische durch Drehen und durch Fahren. Aber auch wenn das System angehalten ist, können Gefahren daraus hervorgehen z. B. durch gespeicherte Energie (z.B. einer gespannten Feder oder eines geladenen elektrischen Kondensators), durch Chemikalien, durch hohe Temperaturen oder einfach dadurch, daß es im Weg steht und Kollisionen verursachen kann. Es ist bemerkenswert, daß es keine Softwaregefährdung gibt. Gefahr kommt aus dem ganzen System und nicht nur aus der Software (Steuerung). 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 und Änderungen im Betrieb ohne kompletten Satz neuer Tests.

Bei der Suche von Gefahren soll man nebenbei, dem System zugrundeliegende Annahmen überprüfen und in Frage stellen, denn sonst bleiben falsche Annamen unentdeckt bis sie einen Unfall verursachen. Man soll mögliche Szenarien für den Systemeinsatz entwerfen und analysieren, Trainingsprogramme für Systembenutzer konzipieren und mögliche Systemveränderungen durchspielen. Sobald das System läuft, soll als erstes das benutzte Systemmodell (Simulationsmodell, Annahmen, usw.) mit der Realität verglichen werden, um prüfen zu können, ob die vorhandenen Abweichungen neue Gefahren bringen können.

Techniken

Unter dem Begriff Hazard-Analyse werden verschiedene Techniken zusammengefaßt, die dazu dienen, ein System auf potentielle Gefahren hin zu untersuchen. Dabei kann man die Vielzahl dieser Techniken in Typen wie Vorwärts- und Rückwärts-Suche oder Top-down und Bottom-up-Suchen einteilen. Die Bezeichnungen der Typen deuten auf die verschiedenen Ansätze und Vorgehensweisen hin, derer man sich bedient, um die Gefahren zu analysieren. Dabei konzentriert man sich nicht auf einen einzigen Aspekt der Systementwicklung, sondern betrachtet das System als Ganzes und versucht im Gesamtüberblick Hazards und ihre Ursachen zu erkennen und, wo möglich, zu reduzieren oder ganz auszuschließen. Diese Techniken sind teilweise für einen bestimmten Industriebereich entwickelt worden, andere wurden für ein breiteres Anwendungsgebiet konzipiert. Unabhängig davon empfielt es sich, mehrere Techniken zusammen zu benutzen, denn sie beleuchten verschiedene Sichten der Gefahren und können dabei neue Erkenntnisse bringen, die eine alleine nicht bringen kann. Das beste wäre, wenn alle diese Techniken zusammen angewendet werden.

Vorwärts- und Rückwärts-Suche

Die Abbildung 5 zeigt das Vorgehen bei Vorwärts- und Rückwärts-Suche.

 

Vorwärts bedeutet, daß man von einem initialen Ereignis ausgeht und versucht, die Folgen herauszufinden. Diese zeitlich nach vorn gerichtete Tätigkeit wird auch als induktive Suche bezeichnet. Der durch das initiale Ereignis erreichte Zustand kann wiederum eine Wirkung hervorrufen, d.h. ein Ereignis auslösen und möglicherweise indirekt zu einem gefährlichen Zustand führen. Die Frage, die man sich bei diesem Vorgang stellt, lautet Was passiert, wenn A?".

Die Rückwärts-Suche wird auch deduktive Suche genannt. Man geht bei dieser Methode von gefährlichen Zuständen aus und versucht herauszufinden, wodurch es dazu kommen kann. Man schaut also zeitlich gesehen nach hinten. Hier lautet die Frage in etwa Was ist die Ursache für A?". Bei der Vorwärts-Suche geht man von einem initialen Ereignis aus und bekommt als Ergebnis in der Regel mehrere Endzustände. Das Problem dabei ist die Schwierigkeit, Kombinationen von Ereignissen durchzuspielen. Bei der Rückwärts-Suche geht man von einem Endzustand aus und bekommt mehrere initiale Ereignisse als Ergebnis. Welche Methode man benutzt hängt davon ab, ob man eher die Ursachen für eine bestimmte Gefahr entdecken will oder ob man die Folgen eines bestimmten Ausfalls bestimmen möchte oder beides.

Top-Down und Bottom-Up Suche

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.

 

Bei der Bottom-Up Suche geht man von dem Ausfall einer kleinen Komponente aus und untersucht, welche übergeordneten Module dadurch getroffen werden. Diese Untersuchung soll für jede Komponente im System durchgeführt werden, was einen sehr hohen Aufwand bedeuten kann. Ein zweites Problem ist, daß diese Suche keine Unterstützung für die Untersuchung von Kombinationen von Ausfällen bietet.

Bei der Top-Down Suche geht man von der gesamten Anlage aus und untersucht, welche Ausfälle gefährlich wirken können. Und so geht man die Modulhierarchie herunter bis zu den elementarsten Komponenten.

Sammeln und protokollieren von Informationen

Nur durch eine systematische Aufbereitung der Informationen von Unfalluntersuchungen können gleiche oder ähnlichen Fehler vermieden werden. Die Schwierigkeit besteht allerdings darin, daß oftmals Informationen über Unfälle zurückgehalten werden. Die gesammelten Informationen können bei jeder neuen Entwicklung benutzt werden, um zu sehen, ob man nicht wieder alte bekannte Fehler machen wird.

Checklisten

Checklisten werden in allen Lebenszyklus-Phasen eines Systems eingesetzt. Sie basieren auf den Erfahrungen, die in der Vergangenheit gesammelt wurden und sind dynamisch erweiterbar. Während der Entwurfsphase liefern sie Informationen über bekannte Gefahren, wodurch man besser sicherstellen kann, daß man an alles gedacht hat. Die Checklisten können einfache Auflistungen von Gefahren sein oder auch Fragen enthalten, die als Antwort eine Erklärung darüber verlangen, wie das System vor einer bestimmten Gefahr geschützt werden soll. Ihre Nachteile sind: Sie können mitunter sehr groß werden und schwer zu benutzen sein. Außerdem sind sie selten vollständig und können in falscher Sicherheit wiegen, wenn man annimmt, daß das System sicher sei, weil alle Punkte der Checkliste abgehakt sind.

Ereignisbaumanalyse (ETA: "Event-tree-analysis")

Bei diesem Verfahren handelt es sich um eine zuvor beschriebene Vorwärts-Suche. Man geht von einem Ereignis aus, welches das System beeinflussen kann und untersucht die möglichen Folgen. Dieses auslösende Ereignis kann beispielsweise der Ausfall einer Systemkomponente oder ein externer Vorfall sein. Der Ereignisbaum wird von links nach rechts gezeichnet, jeweils mit Abzweigungen für zwei Alternativen, ein oberer Zweig für das erfolgreiche Verhalten der Schutzkomponente und ein unterer Zweig für dessen Scheitern. Dadurch wird es möglich, verschiedene Pfade zu durchlaufen und eine Unfallsequenz zu identifizieren. Da sich die Zahl der Zweige mit jedem Schritt verdoppelt, können in komplexen Systemen sehr große Bäume entstehen. (Siehe Abbildung 7)

Jeder Abzweig ist mit einer gewissen Wahrscheinlichkeit verbunden. Die Wahrscheinlichkeit, daß eine Komponente ausfällt, ist in der Regel sehr gering, so daß der erfolgreiche Betrieb annähernd 1 ist. Durch Multiplikation der jeweiligen Wahrscheinlichkeit der Zweige kann man die Wahrscheinlichkeit für einen bestimmten Pfad berechnen. Die Unfallwahrscheinlichkeit erhält man dann durch Kombination aller Pfadwahrscheinlichkeit der Pfade, die zu einem Unfall führen. Aber Vorsicht! Diese Berechnung mit so kleinen abgeschätzten Werten kann sehr große Ungenauigkeiten haben und große Fehler enthalten. Und wie bereits erwähnt, eine noch so niedrige Unfallwahrscheinlichkeit kann nicht das Ignorieren der damit verbundenen Gefahr rechtfertigen.

 

Fehlerbaumanalyse (FTA: "Fault-tree-analysis")

Im Gegensatz zur Ereignisbaumanalyse geht man bei der Fehlerbaumanalyse von einer Gefahr aus und arbeitet sich nach hinten (nach unten in dem Diagramm), um die Ursachen herauszufinden (Rückwärts-Suche). Die Beziehungen zwischen den Ereignissen wird durch logische AND / OR Symbole dargestellt. So kann man beispielsweise durch ein AND"-Symbol darstellen, daß ein Ereignis dann eintritt, wenn zwei oder mehrere andere Ereignisse gleichzeitig stattfinden (Analog für OR). Außerdem unterscheidet man durch verschiedene Symbole zwischen elementaren Ereignissen (Kreis) und Fehlerereignissen, die durch andere Ereignisse hervorgerufen werden (Rechteck) sowie Ereignissen, deren Ursachen bislang noch ungeklärt sind (Raute). Der Vorgang der Ursachenfindung und Dokumentation mittels Boolscher Algebra wird solange fortgesetzt, bis man bei grundlegenden Ereignissen angekommen ist, die selbst keine Ursache haben bzw. deren Ursachen man nicht weiter betrachten möchte (Siehe Abbildung 8).

 

Ursache-Wirkung-Analyse (CCA / CEA: "Cause-Effect-Analysis")

Diese Analysemethode kombiniert verschiedene Vorgehensweisen miteinander. Es wird ein kritisches Ereignis ausgewählt und sowohl die Ursachen als auch möglichen Konsequenzen untersucht. (Siehe Abbildung 9)

 

Ausfallarten- und Wirkungs-Analyse (FMAE: "Failure modes and effects")

Bei dieser Analyse betrachtet man den Ausfall jeder Komponente (Fehlermodell) eines Systems und untersucht dessen Wirkung auf das gesamte System (Bottom-Up Suche). Da man alle Komponentenausfälle untersucht, lassen sich mit diesem Verfahren solche Bedingungen gut entdecken, die durch nur einen Ausfall zu gefährlichen Situationen führen können. Die Nachteile sind, daß man keine Kombinationen von Ausfällen betrachtet und sich mit vielen Ausfällen beschäftigen muß, die nicht zu Gefahren führen, wodurch die Anwendung bei komplexen Systemen sehr teuer ist. Deshalb benutzt man die FMAE in der Regel in einer späten Entwicklungsstufe, wo sie nur auf die kritischen Bereiche angewandt wird.

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ällen und Entwicklung sicherheitsrelevanter eingebetteter Systeme.

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 sicherheitsrelevanten Systemen.