Sicherheit und die Mensch-Maschine-Kooperation

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

Es wird viel geforscht, um die Sicherheit von automatisierten Anlagen zu steigern. Einige investieren einen großen Aufwand für eine korrekte Entwicklung, z.B. durch die Verwendung von formalen Methoden. Andere investieren viel bei der Laufzeitsicherheit (Fehlertoleranz). Aber der größte Brocken, der fast alle Katastrophen verursacht, nämlich die Mensch-Maschine-Kooperation, wird selten behandelt. Und dabei ist es so einfach.

Ein eingebettetes System bildet ein Dreieck: Mensch - Maschine - Umwelt (siehe Abbildung 1). Die Sicherheit aller kann durch jeden einzelnen gefährdet werden. Mensch und Maschine können Gefahren durch Fehler verursachen. Aus der Umwelt bringen die unvorhersehbare Situationen Gefahr mit sich. Für die Sicherheit sind aber nur Mensch und Maschine zuständig und sie müssen zusammenarbeiten, um diese oft unmögliche Aufgabe zu erfüllen.

Der Mensch macht ständig Fehler (Sie natürlich nicht), Ungenauigkeiten und Abweichungen vom direkten Weg. Er löst niemals eine komplexe Aufgabe zwei Mal identisch. Aber seine Abweichungen und Fehler haben meistens keine bösen Folgen, und er schafft die Aufgabe, weil für ihn diese Abweichungen die Regel sind und er bei der nächsten Handlung die Abweichung der vorherigen korrigiert. Solange der Mensch seine Fehler korrigieren kann, ist alles in Ordnung. Er muß nur die Gelegenheit dafür haben. Der Rechner, auf der anderen Seite, macht selten Fehler und Ungenauigkeiten. Die gleiche Aufgabe wird immer gleich gelöst. Aber wehe, eine Abweichung oder eine unvorhersehbare Situation tritt ein. Dann kann der Rechner sich in der Regel nicht korrigieren und verläuft sich in undefinierten Zuständen, die böse Folgen haben können. Im Gegensatz zum Menschen ist bei den Rechnern nur alles in Ordnung, solange alles planmäßig läuft. Eine geeignete Kombination dieser Fähigkeiten und Eigenschaften kann ein starkes und sicheres Team bilden. 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 (siehe Abbildung 2). Das besondere an diesem Team ist, daß es kein Vertrauen geben darf. Beide, Mensch und Maschine, müssen sich gegenseitig mit Mißtrauen beobachten. Blindes Vertrauen in die Technik ist so gefährlich wie blindes Vertrauen in den Menschen. Nur durch dieses Gegenspiel kann man eine höhere Sicherheit erreichen.

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.

Es gibt eine Tendenz, Sicherheit durch volle Automatisierung zu erreichen. Die traurige Bilanz davon ist, daß die Wahrscheinlichkeit für einen Unfall, nachdem ein Fehler oder eine unvorhersehbare Situation auftritt, 4 mal höher ist, wenn der Mensch in die Steuerung nicht mehr eingreifen kann [Frick]. Besonders bei komplexen Anlagen, wo viele unerwartete Situationen zu erwarten sind, ist die Funktion des Menschen in der Kontrollschleife unverzichtbar. Die Operatoren sollen aber nicht als Teil der Regelungsschleife mit monotonen, trivialen Aufgaben trainiert werden, sondern viel eher als Überblicker, mit Gesamtanlagen-Durchblick und Verständnis. Von ihrem Überblick und ihrer Kreativität hängt die Sicherheit der Anlage ab, wenn ein Notfall oder eine Ausnahme eintritt, weil man nicht von den Entwicklern erwarten kann, daß sie alle möglichen Situationen und Kombinationen von Ereignissen berücksichtigt haben und weil der Kontrollrechner nur die vorhergesehenen Situationen, mit apriori definierten Handlungen, beherrschen kann. Der Mensch kann dagegen auch unvorhersehbare Situationen durch Kreativität und Flexibilität beherrschen.

Die Rolle des Menschen und der Maschinen hat sich in der letzten Zeit geändert und ist auch abhängig von der Anlagenkomplexität. Der Einzug des Rechners in die Kontrollschleife und der damit verknüpfte Automatisierungsgrad kann in 6 Stufen eingeteilt werden:

0. Alles manuell

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. Diese Stufe wird auch in modernen Anlagen als Frühwarnsystem eingesetzt.

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ß der Entwickler sehr zuversichtlich sein! Die gefährlichsten Stufen sind die Extreme: 0 und 5; beide, Mensch und Maschine, haben ihre typische Fehleranfälligkeit, aber hier, in den Extremen, gibt es keine Kontrollinstanz. Bei den Stufen 0 bis 2 liegt alles fast ausschließlich unter der Verantwortung des Operators, dennoch rückt der Rechner ab Stufe 2 an eine kritische Stelle. Als Frühwarnsystem kann der Rechner potentielle Gefahren durch ständige Überwachung entdecken und melden. Auch wenn es nicht offensichtlich ist, kann so eine zusätzliche Funktion neue Gefahren bringen. Die Menschen werden sich (nach einer Weile) auf das Frühwarnsystem blind verlassen und nachlässig werden. Wenn dann eine gefährliche Situation nicht gemeldet wird, z.B. wegen eines technischen Fehlers (was zu erwarten ist), hat man sehr wahrscheinlich einen Unfall. Dies wäre ohne das Frühwarnsystem nicht geschehen, denn der Operator wäre wachsamer gewesen. Das andere Extrem ist auch gefährlich. Das Frühwarnsystem ist zu empfindlich und meldet Gefahren, die keine sind. In diesem Fall verliert der Operator das Vertrauen in die Warnungen und kann dadurch Warnungen ignorieren, die eine wirkliche Gefahr signalisieren. Die Gefahren der Stufen 3 bis 5 sind offensichtlich und brauchen nicht extra erwähnt zu werden.

Bei komplexen Anlagen ist die Stufe 3 die sicherste. Aber die Mensch-Maschine-Kooperation ist extrem kritisch. Eine falsch entwickelte, nicht menschengerechte Schnittstelle kann die gesamte angestrebte Sicherheit ruinieren. Bei einer richtigen Konzeption der Schnittstelle geht es um die Minimierung der Wahrscheinlichkeit sogenannter "Bedienungsfehler".

Bedienungsfehler?

Oft wird der (menschliche) Operator als Gefahr Nummer 1 angesehen und daraus ziehen wir die logische Schlußfolgerung, daß die Sicherheit durch volle Automatisierung ohne menschliche Wirkung gesteigert werden kann. Dies ist aber eine Täuschung.

Bei 80% der Flugzeugkatastrophen lautete der Befund "Menschliches Versagen" [Frick]. Leider gibt es keine Statistik, wie oft Piloten ein Versagen der Technik beherrschen mußten, um eine Katastrophe zu verhindern. Diese Zahl dürfte aber höher als die erste sein, wie eine Studie der US. Airforce [Leveson] zeigt. Bei 681 Notfällen waren nur 10 durch Pilotenfehler verursacht, jedoch 659mal war ein technischer Fehler der Auslöser eines Notfalls, aber der Pilot konnte durch geschicktes Eingreifen einen Unfall vermeiden. Von den erstgenannten 10 Fällen wurden Unfallberichte geschrieben, aber über die 659 weiteren wurde nichts geschrieben. Normalerweise werden Berichte nur über Unfälle geschrieben, nicht aber über geschicktes Verhindern eines Unfalls, weil das die normale Aufgabe des Operators ist. Außerdem: Solange nichts passiert ist, braucht man die Sicherheit der Anlage nicht in Frage zu stellen. Dies bringt negative wirtschaftliche Folgen.

Weiterhin steht oft in Unfallberichten "Bedienungsfehler" als Ursache des Versagens. Aber viele von diesen Bedienungsfehlern waren bei der Entwicklung vorprogrammiert. Man sollte sie lieber als "Entwicklungsfehler" klassifizieren. Alte Studien geben an, daß mehr als 80% der Unfälle aus unsicherer Bedienung des Operators stammen. Genauere Studien [Kjellen] zeigen, daß 60 bis 80% der Unfälle dadurch entstehen, daß der Operator die Kontrolle über die Maschine verlor. In diesen Situationen kann nicht eindeutig gesagt werden, ob es ein menschliches Versagen war oder ob die Mensch-Maschine-Schnittstelle schlecht entworfen und implementiert wurde. Sicherheit hängt auch davon ab, inwieweit das System sich bedienen läßt -- unter allen Umständen, besonders in einem Notfall.

"Bedienungsfehler" in den Unfallbericht zu schreiben ist viel einfacher, als ein technisches Problem zugeben zu müssen. Aber dadurch wird erreicht, daß der wahre Grund des Unfalls unbehoben bleibt und daß er sich wiederholen kann. Ein technisches Problem zuzugeben, kann das Vertrauen in die Anlage schädigen, was viel Geld kosten kann. Ein Umbau der Anlage kann auch sehr teuer werden. Und letztlich wird meistens der Bericht von einem Mitglied der Technikgruppe geschrieben, und er will seine eigene Gruppe nicht schädigen. Obendrein kann sich der Operator oft nicht mehr beschweren oder verteidigen.

Stellen Sie sich als Operator während eines Notfalls in einer chemischen Anlage vor. Um die Anlage in einen sicheren Zustand zu bringen, brauchen Sie nur einige kritische Werte abzulesen und entsprechend gegenzusteuern. Im Normalfall wäre das kein Problem, aber in diesem Notfall haben Sie folgende Situation von ihrem freundlichen Systementwickler vorprogrammiert bekommen:

Eine Sirene jault in voller Lautstärke in Ihre Ohren, ein rotes Licht blinkt vor Ihrem Gesicht. Dadurch werden alle Operatoren nur noch nervöser und hektischer. Leute rennen herum und schreien verschiedene Anweisungen. Der Rechner gibt Ihnen keinen direkten Zugriff auf die Werte, die sie lesen sollen, denn er ist in einen Notbetrieb umgeschaltet worden. Wo normalerweise die benötigten Daten erscheinen, rauschen pro Sekunde 10 bis 30 Zeilen Fehlermeldungen und Warnungen über den Bildschirm. Sie sollen alle diese Meldungen lesen, um wissen zu können, was die jetzige Lage ist. Diese Situation war in Ihrem Training nicht erwähnt. Sie müssen zuerst in einem alten Manual nachsehen. Was da beschrieben ist, entspricht nicht dem, was vor Ihren Augen passiert. Trotz der "Hilfe" des Notprogramms und der Verwirrung der Dokumentation schaffen Sie es, die Werte, die Sie brauchen, zu bekommen. Sie versuchen in Ruhe, trotz Sirene und Rotlicht, die Gegenmaßnahme zu planen. Danach müssen Sie die Sollwerte in verschiedene Fenster eingeben, bei denen die Texte und Überschriften blinken, damit Sie ihre Wichtigkeit erkennen. Um die Anlage manuell zu steuern, müssen Sie noch ein 10-stelliges Paßwort eingeben, das vor kurzem geändert wurde, ohne daß Sie etwas davon wußten. Zum Glück wußte es einer von Ihren Kollegen noch, aber leider nicht, ob klein oder groß geschrieben. Nach mehreren Versuchen haben Sie es geschafft. Nun müssen Sie nur mit zitternder Hand die Maus pixelgenau positionieren, um die Sollwerte eingeben zu können. In der wenigen Zeit, die Sie noch hatten, schafften Sie es nicht mehr -- --und dann steht im Unfallbericht "Menschliches Versagen". "Die paar Werte zu lesen und gegenzusteuern hätte jeder Operator schaffen können". Dabei war der Unfall bereits bei der Entwicklung der Notsituationsmaßnahmen vorprogrammiert worden. Menschlich war es unmöglich, das System zu steuern.

Viele Unfälle, die als menschliches Versagen klassifiziert wurden, wurden nicht vom Operator verursacht, sondern der Operator hat es nicht geschafft, den Unfall zu verhindern, der von einem technischen Fehler oder von einer Ausnahmesituation verursacht worden ist. Gründe dafür können die Kürze der Zeit, die Hektik, die Komplexität der Bedienung, falsche Dokumentation, unvorhersehbare Situationen, ungewohnte Umgebung, schwierige Mensch-Maschine-Kommunikation sein, oder es war einfach menschlich nicht mehr möglich, etwas dagegen zu unternehmen.

Kürze der Zeit

Wenn die Notmaßnahmen zu spät aktiviert werden, ist dies ein Fehler, der aus einem Versagen des Frühwarnsystems kommen kann. Oder der primäre Fehler kommt von einer Stelle, die nicht überwacht wird. In diesem Fall wird der Fehler erst bemerkt, nachdem er sich so weit fortgepflanzt hat, daß man kaum noch etwas dagegen unternehmen kann.

Es kann auch sein, daß die Ausnahmesituation sehr plötzlich und unvorhersehbar eintrat und kritische Stellen der Anlage zu schnell befallen wurde (Entwicklungsfehler?).

Hektik und Überforderung

Untersuchungen der Atombehörde haben gezeigt, daß in den ersten 15 Minuten nach Eintreten eines Notfalls die Operatoren nicht in der Lage sind, etwas Vernünftiges zu unternehmen. Der Schreck und die Hektik blockieren das "normale" Denken. Die Reihenfolge der Handlungen des Operators sollte sein: 1. sich beruhigen, 2. Zustand erfassen, 3. denken, 4. handeln. Was oft in diesen Situationen geschieht ist aber: 1. weiter hetzen, 2. handeln, 3. zurück zu 1.

Das Notprogramm muß mit diesem Phänomen rechnen, und versuchen, die Operatoren zu beruhigen und nicht weiter zu hetzen. Bis die Operatoren die Situation beherrschen können, sollte das Notprogramm versuchen, so gut wie möglich alles unter Kontrolle zu halten und nicht einfach Fehlermeldungen auszugeben und sich zu verabschieden.

Die Anzahl von Informationen, die der Mensch pro Zeiteinheit annehmen und bearbeiten kann, ist begrenzt. Wird diese Grenze überschritten, so wird, im Gegensatz zu Maschinen, fast nichts mehr übernommen und fast alle Informationen gehen verloren, z.B. wenn mehrere gleichzeitig den Operator ansprechen, eine Sirene heult, am Monitor rauschen die Zeilen mit Warnungen vorbei, viele kleine rote Alarm-Lämpchen blinken usw. Der Operator wird nur wahrnehmen, daß es große Probleme gibt. In einer Notsituation ist es besser, nur die wichtigsten Daten, die der Operator eventuell braucht, auszugeben und alle scheinbar unwichtigen Informationen nur nach Abfrage zu liefern und nicht unaufgefordert zu wiederholen.

Komplexität der Bedienung

Oft ist die Bedienung so komplex und schwierig, daß "Bedienungsfehler" vorprogrammiert sind. Z.B. ist mir die Bedienung unserer rechnergesteuerten Waschmaschine nach wie vor ein Rätsel. Für moderne Kochherde bieten die Hersteller sogar Einführungskurse an. Ohne den Kurs wird man kaum damit zurecht kommen. Das gleiche kann man beim "modernen" Videorecorder beobachten. Ohne eine 100-seitige Gebrauchsanweisung geht nichts mehr. Dies sind aber einfache Geräte. Bei den komplizierten Geräten ist ein Bedienungsfehler wirklich vorprogrammiert, und wenn der "Bedienungsfehler" in einem sicherheitskritischen Moment geschieht, dann hat man den Unfall vorprogrammiert. Dagegen hilft nur "Einfach bleiben" und die wichtigsten Funktionen nicht mit unwichtigen Zusätzen zu überladen.

Falsche Dokumentation

Veraltete Dokumentationen oder eine Dokumentation der falschen Version kann auch zu dieser Sorte von "Bedienungsfehler" führen. Für den Bediener ist es extrem verwirrend, wenn das System sich anders verhält als dokumentiert. Diese Situation kombiniert mit der normalen Hektik beim Ernstfall garantiert einen Unfall. Deswegen sollten alle alten Dokumentationen sofort bei der Lieferung von neuen Versionen vernichtet werden. Es ist hilfreich zu wissen, wie viele Dokumentationsexemplare bei jeder Anlage existieren, und es ist gefährlich, Exemplare oder Teile davon zu fotokopieren. Es ist modern, keine gedruckten, sondern nur On-Line-Dokumentationen zu liefern. Diese können leichter verwaltet werden, solange der Kunde sie nicht druckt. Sie sind abet nutzlos, wenn der Rechner unkooperativ wird.

Die Bedienungsdokumentation sollte auch keine Systemspezifikation sein, sondern nur "Handgriffe" und Vorgehen erklären, ohne sich in systeminterne Details zu vertiefen. Anders ist es bei der Anlagendokumentation, deren Zweck es ist, den Operatoren einen Überblick und Durchblick zu verschaffen. Aber diesen Durchblick sollen sich die Operatoren bereits beim Training erarbeiten. Wenn der Operator damit im Notfall anfängt, sind wir bereits auf verlorenem Posten.

Unvorhersehbare Situationen und Folgen

Viele Unfälle folgen aus unvorhersehbaren Situationen, für die die Steuerung nicht konzipiert und die Operatoren nicht trainiert worden sind. Um den Unfall zu verhindern, müssen die Operatoren in wenigen Sekunden so kreativ sein, wie die Systementwickler in den Monaten der Entwicklung nicht sein konnten. Die Operatoren müssen unter Zeitdruck und Hektik eine unbekannte Situation erfassen, trotz eventuell nicht vorhandener Meßpunkte, und dann einen Ausweg finden. Dann müssen sie ungewisse und unerprobte Handlungen durchführen. Danach, bei der Analyse der Situation, kann man leicht finden, was die richtige Handlung gewesen wäre -u.a. weil man schon weiß, was geschehen ist und viel mehr Daten und Zeit zur Verfügung hat. Aber mittendrin in der Notsituation -- mit begrenzten und widersprüchlichen Informationen -- kann der Operator nicht immer wissen, was für weitere Folgen seine Handlungen haben werden.

Die Entscheidung für eine riskante Handlung ist oft besonders schwierig, weil

1. die vorhandenen Informationen widersprüchlich sein können, z.B. die Angaben der Anzeigen sind nicht konsistent und der Operator kann nicht wissen, welche die richtige ist -- falls es eine richtige überhaupt gibt.

2. das, was der Operator selbst von der Anlage sieht unter Umständen mit den Anzeigen nicht nicht übereinstimmt.

3. sein Gefühl zur Situation und seine Intuition im Konflikt mit den Rechnerangaben und Vorschriften stehen können Oft zeigen Gefühle und Intuition den richtigen Weg -- im Gegensatz zu den Vorschriften, die geschrieben worden sind, ohne in der Situation gewesen zu sein. Aber ob seine Intuition das richtige zeigt, kann der Operator nicht im voraus wissen, und das Risiko des Versuchs ist enorm. Oft hat man auch das Dilemma: eingreifen oder nicht eingreifen? Beide können richtig oder falsch sein. Ob die Entscheidung das richtige oder das falsche war, kann man nur nachträglich herausbekommen: Dann bekommt der Operator ein wenig Ehre oder viel Ärger. Das Nicht-Einhalten der Vorschriften wird als schlimmer Bedienungsfehler eingestuft, aber sehr oft ist es genau das, was uns vor einem Unfall retten kann. Man weiß es aber nicht....

Ungewohnte Umgebung

Wenn etwas anders ist als erwartet, haben wir einen Bedienungsfehler vorprogrammiert. Beispielweise hat ein "normaler" Telefonhörer das Anschlußkabel an der Mikrofonseite. Wenn unerwarteterweise ein Nottelefon das Anschlußkabel an der Lautsprecherseite hätte (z.B. weil es sich besser montieren läßt), würden fast alle Benutzer es falschherum nehmen und es in der Hektik der Notsituation nicht bemerken. Danach könnte im Unfallbericht stehen "Der Operator war nicht einmal in der Lage, das Nottelefon zu benutzen". Ein Fall, der sehr oft vorkommt, wird in der Abbildung 3 dargestellt. Die verschiedenen Funktionen werden von verschiedenen Gruppen entwickelt, sie sprechen kaum miteinander und halten solche Kleinigkeiten nicht für wichtig. Aber in der Notfallsituation kann dieser kleine Entwicklungsfehler (!!) der Unterschied zwischen Unfall und Rettung sein.

Die Abbildung 4 zeigt noch ein reales Beispiel. Hier wurde beim Montieren der Kontrollknöpfe ihre Reihenfolge vertauscht. Die ganze Konsole wieder zu öffnen und alles umzubauen kostet zu viel Zeit und Arbeit -- und da der Operator lesen kann, wurde es so belassen. Im Notfall ist diese Vertauschung eine Falle. Noch schlimmer wäre, wenn auch die Beschriftung falsch wäre. So ein Fehler kann leicht unentdeckt bleiben, bis eine Notsituation eintritt.

Ein alltägliches Beispiel, daß fast jeder kennt, ist die letzte Frage eines Editors:

"Write changes befor ending? (Y/N)"

Aber einige wenige Editoren fragen:

"End and discard your changes? (Y/N)"

Schlechte Mensch-Maschine-Kommunikation

Auch die Mensch-Maschine-Kommunikation kann die Schwachstelle sein. Schuld ist nicht immer der Mensch, sondern es kann auch sein, daß die Technik nicht gut an den Menschen angepaßt ist und daß die Benutzerschnittstelle zu kompliziert und zweideutig ist.

Es gibt viele Meldungen und Fragen in einer Ausnahmesituation, die der Operator kaum verstehen kann. Oft enthält so eine Meldung Referenzen zu internen Programmvariablen, die etwas für den Programmierer bedeuteten, aber nicht für den Operator, der die Programmquellen noch nicht auswendig gelernt hat, z.B. "**** Error *** Refs_ptr[2] ist null". In anderen Fällen werden einfach vordefinierte graphische Abfragefenster benutzt, die fertige Knöpfe haben, z.B. "OK" / "Cancel". Wenn die Frage lautet "Cancel your Request" und Sie nur "OK" oder "Cancel" drücken können, dann müssen Sie zwei oder drei Mal überlegen, was Sie wirklich drücken sollen.

Andere Male wird die Frage einfach nachlässig gestellt. Einmal fragte mich ein Programm:
"Nicht alle Dateien löschen? (J/N)". 'Control-C' hat nicht funktioniert. Ich habe lieber den Rechner ausgeschaltet. Bei dem Steuerrechner einer großen Anlage wäre ich nicht so einfach davongekommen.

Folgende Liste ist ein kleins Angebot realer Maßnahmen [Leveson], um die Operatoren zu verwirren und Unfälle zu produzieren:

Redundante Instrumente, die die gleiche Größe messen, haben verschiedene Ausgabeeinheiten und Skalen. (Siehe Abbildung 4)
Der Normalbereich einer Größe ist nicht immer gleich markiert.
Es werden zu viele unnütze Informationen ausgegeben, die die nützlichen Informationen verdekken oder in den Hintergrund drängen.
Markierungen und Farbe der Markierungen sind nicht konsistent.
Die Anzeigen der rechten Seite werden von den Eingabegeräten der linken Seite gesteuert und umgekehrt.
Die Anzeigen und die dazugehörigen Steuergeräte befinden sich in verschiedenen Konsolen.
Die Texte und Angaben auf einer Panoramatafel sind so klein, daß man sie nur aus einem Meter Entfernung lesen kann. Aber die Eingabegeräte sind mindestens 3 Meter entfernt.
Zwei nebeneinander liegende Anzeigen haben dieselbe Skala, aber der Operator muß wissen: Die eine zeigt eine Größe, die Faktor 10 größer als die andere ist.
Texte und Markierungen entsprechen nicht mehr dem, was im Manual steht.
Der Trainingsraum und der echte Kontrollraum sind unterschiedlich.

Bedienungsfehler!

Es gibt auch Unfälle, die vom Operator verursacht werden. Beispielsweise werden fast alle Autounfälle durch Bedienungsfehler verursacht. Auch viele sensationelle Unfälle in großen Anlagen wurden durch Bedienungsfehler verursacht. Aber selbst wenn das menschliche Versagen wirklich die Ursache für einen Unfall ist, lohnt es sich nachzudenken, wo das System verbessert werden kann, damit die Situation sich nicht wiederholt. Den Menschen zu entmündigen ist aber nicht die Lösung. Damit steigt nur die Wahrscheinlichkeit eines Unfalls, da eines Tages doch etwas Unvorhersehbares auftreten wird. Viel besser ist es, den Grund für diese Fehler zu kennen, um dagegensteuern zu können. Dies betrifft die Systementwickler, aber auch die Operatoren selbst, deren Training diese Faktoren bewußt machen sollte.

Per Definition ist ein Bedienungsfehler: Ein Verstoß gegen die Spezifikation, eine vermeidbare Erhöhung des Risikos oder eine bedienerverursachte Überschreitung des Grenzrisikos.

Die Gründe dafür sind: Risikoakzeptanz und Risikofreude, Unterschätzung der drohenden Folgen/Schäden einer Handlung, Nicht-Berücksichtigen von alternativen Handlungen, falsche Vorstellungen vom Anlagenzustand, falsche Vorstellungen der Folgen einer Handlung, Überschätzung der eigenen Fähigkeiten, Eile, Müdigkeit, Zerstreuung, Unfähigkeit (Mangel des Trainings) u.a.

Wie gesagt, man kann menschliche Fehler nicht ausschalten, und solange die Fähigkeit, schwierige Entscheidungen zu treffen, nötig für den Prozeß ist, muß man mit dem damit verbundenen Risiko leben können. Bei jeder Entscheidung geht es darum, mit einer vermuteten Wahrscheinlichkeit etwas zu gewinnen und etwas anderes zu verlieren (kein Gewinn ohne Risiko). Bei vielen Notsituationen entsteht ein Dilemma: Sicherheit oder Verfügbarkeit. Für die Sicherheit soll sofort beim Erkennen einer potentiellen Gefahr die Notmaßnahme (Halt) eingeleitet werden. Die Anlage anzuhalten bedeutet einen Produktionsverlust plus viele andere Nebenwirkungen. Wenn man das nicht will, muß die Verfügbarkeit erhöht werden. Die Anlage wird weiter betrieben und sie wird erst angehalten, wenn es sicher ist, daß ohne Notmaßnahmen ein Unfall eintreten wird. Der Versuch, sich blind bis zu dieser Sicherheitsgrenze ("Point of no Return") heranzutasten, ist eine sehr riskante Angelegenheit. Aber er wird immer wieder unternommen.

Der Operator ist bereit, das Risiko zu übernehmen, solange er denkt, er hat die Kontrolle in der Hand. Oft verliert er die Kontrolle, ohne es zu merken, bis er versucht, den Gang der Dinge zu ändern. Aber dann ist es schon zu spät. Dagegen hilft, daß Operator und Rechner als Team ständig prüfen, inwieweit sie noch die Kontrolle über die Anlage haben. Der Rechner soll informiert werden, daß ein riskanter Versuch unternommen wird, und er sollte dabei den Operator unterstützen und nicht boykottieren. Ein Kampf, wer kontrolliert, Mensch oder Rechner, kann nur die Situation nur verschlechtern. Wenn in einem Auto zwei versuchen, gleichzeitig zu lenken: Jeder alleine hätte die Kurve geschafft, aber beide zusammen nicht.

Wenn die Kontrolle in den Händen von jemand anderem liegt, ist die Risikobereitschaft viel niedriger und die Anforderungen an die Sicherheit höher. Ein Beispiel ist die hohe Sicherheit, die die Fahrgäste von Zügen und Flugzeugen erwarten -- im Gegensatz zu den Risiken, die sie sich leisten, wenn sie selber Auto fahren. Das Selbstvertrauen ist einfach überdimensioniert, z.B. "Wenn es gut sein soll, dann mache ich es lieber selbst", "ja,... die anderen haben es nicht geschafft, aber bei mir ist es anders". Dieses Selbstvertrauen kann zu gefährlichen Handlungen verleiten, aber wenn es vom Menschen weggenommen wird, dann bleibt vom ihm nichts mehr übrig, was man noch gebrauchen könnte. Gerade diese Eigenschaften, die seine Handlungen gefährlich machen können, sind die Eigenschaften, die wir von ihm brauchen.

Eile ist ein weiterer Grund für Bedienungsfehler. Das erste Opfer der Eile ist immer die Sicherheit. Der Grund dafür ist, daß man Sicherheit nicht sehen kann, und ihren Wert schätzt man erst, wenn man sie braucht und sie nicht da ist. Aber dann ist es meistens schon zu spät.

Was tun?

Zuerst machen Sie nicht die obengenannten Fehler. Danach ist es wichtig, daß sich die Systementwickler bewußt werden, daß ihr System mindestens einen unbekannten Entwicklungsfehler hat, daß ihr System durch viele unvorhersehbare Situationen gehen muß und daß die Sicherheit in diesen Situationen vom Operator anhängt. Steuerung und Operator müssen wie ein Team arbeiten können und dürfen sich nicht behindern.

"Ingenieure haben nicht erlernt, ein System zu entwerfen, das effektiv Arbeiterintelligenz mit mechanischen Prozessen integriert. Sie verstehen selten, daß Arbeiter sogar in automatisierten Einstellungen Entscheidungen dennoch treffen müssen; eher neigen sie, Arbeiter als Extension der Maschinen anzusehen" (L. Hirschhorn 1982)

Man kann menschliche Fehler nicht ausschalten, sie sind eine Nebenwirkung seiner Flexibilität, Kreativität, Vorstellungskraft, Intuition, Phantasie, seiner Fähigkeit, aus unvollständigen und widersprüchlichen Daten konsistente Schlußfolgerungen zu ziehen usw. Solange man diese Fähigkeiten braucht, muß man mit den menschlichen Fehlern leben können. Eine sinnvolle, effektive, sichere und menschengerechte Mensch-Maschine-Kombination ist eine schwierige Aufgabe und es ist besser, darauf zu verzichten, als sie falsch zu implementieren. Bei ganz einfachen Systemen ohne unvorhersehbare Situationen kann man auf den Menschen verzichten und ihn vollständig aus der Kontrollschleife entfernen. Aber bei komplexen und sicherheitskritischen Aufgaben wäre das zu riskant.

Der Mensch wird benötigt, um Entscheidungen aufgrund von unvollständigen und widersprüchlichen Daten in unbekannten Situationen zu treffen. Dies kann zu Fehlentscheidungen führen. Das beste was, der Rechner machen kann, um ihn dabei zu unterstützen: die Informationen, die er anfordert (nicht was der Systementwickler sich ausgedacht hat), so klar und sauber wie möglich liefern. Das zweite wäre, die Folgen von Handlungen zu simulieren und zu präsentieren. Und letztendlich: "sich bedienen lassen".

Bei der Planung der Notmaßnahmen muß man von einem realistischen Bild des Menschen ausgehen, der Stärken und Schwächen hat, der Ruhe und Selbstkontrolle verlieren wird, wenn die Situation sehr bedrohlich aussieht. Wenn man das ignoriert, programmiert man einen Unfall vor. Beim Einsetzen von Bauteilen wird darauf geachtet, sie nur innerhalb der normalen Parameter zu betreiben. Auch beim Einsetzen von Menschen müßte darauf geachtet werden: nicht hetzen, nicht überladen, nicht überraschen, klare Informationen liefern usw.

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.

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

F. Frick, Menschliches Versagen. Bild der Wissenschaft, Mai 1997.
Statistiken und Ursachen von Luftfahrtunfällen.

U. Kjellen. A changing role of human actors in accidents, control implications for new technology systems. Jens Rasmussen, New Technology and Human error, John Wiley & Sons, New York, 1987. Studien und Statistiken über Unfälle.

D. Norman, The Design of everyday Things, Double Day, New York, 1989. Lustige Beispiele von echt unbedienbaren Bedienungen bei normalen Geräten. Physiologie von Benutzer und Entwickler.