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

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

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.