Entwicklung eines Vorgehens zum Safety Assessment für sicherheits-kritische Informationssysteme. Christina Schäfer
Informationssystemen (SKIS) unterschieden. „Unter einem Mensch-Maschine-System wird die zweckmäßige Abstraktion des zielgerichteten Zusammenwirkens von Personen mit technischen Systemen zur Erfüllung eines fremd- oder selbstgestellten Auftrags verstanden. Die allgemeine Struktur eines Mensch-Maschine-System ist die eines rückgekoppelten Systems, in dem ein Mensch oder ein Team entsprechend seiner organisatorischen Verankerung, seiner Zielstellung, des Auftrags und der wahrgenommenen Rückmeldung über Umgebung und Prozesszustand Entscheidungen fällt und das technische System steuert.“ [GiTi02] Des Weiteren definiert Johannsen (siehe [Joha93]) mindestens zwei notwendige Komponenten eines Mensch-Maschine-Systems:
• Den handelnden Menschen
• Die benutzbare Maschine
Ein sicherheits-kritisches Mensch-Maschine-System verursacht im Falle eines Schadensereignisses neben den hohen ökonomischen Auswirkungen für den Betreiber zusätzlich eine erhebliche Gefährdung von Mensch und auch Umwelt [Acat16].
Die nachfolgende Abbildung zeigt Zusammenhänge und Beispiele zu den in der vorliegenden Arbeit genannten Systemarten.
Quelle: Verfasser
Abbildung 1-1 Zusammenhänge zwischen Sicherheits-kritischen Systemen, Sicherheits-kritischen Mensch-Maschine-Systemen und Sicherheits-kritischen Informationssystemen
Bei der Entwicklung von SKS wird der Analyse und Berücksichtigung von Störfällen besondere Aufmerksamkeit geschenkt, da SKS auf die physische Umgebung direkt einwirken und daraus resultierend Schaden für das Umfeld und den Menschen hervorrufen können. Ein solcher Störfall wird in dem Kontext von SKS “Hazard” genannt. “A hazard is a state or set of conditions of a system (or an object) that, together with other conditions in the environment of the system (or object), will lead inevitably to an accident (loss event)” ([Leve01], S.177). Dazu werden in der Softwareentwicklung vier Phasen einbezogen: ”Hazard elimination“, ”Hazard reduction“, ”Hazard control“ und ”Damage minimization“ [BUOT11].
Im Gegensatz dazu stehen bei der Entwicklung von SKMMS die Usability und das Design der Benutzungsschnittstelle im Vordergrund.
Insbesondere im genannten Kontext der zivilen Gefahrenabwehr sind Aufgaben und Arbeitsabläufe komplex und es besteht die Anforderung des komplexen Problemlösens. Die Definition von Frensch und Funke (vgl. [FrFu95]) für komplexes Problemlösen zeigt verschiedene Dimensionen auf, die eine Unterscheidung des Problemlösers und damit eine individuelle Wahrnehmung von Komplexität induziert, wie „cognitive, emotional, personal, and social abilities and knowledge“. Dabei kann festgestellt werden, dass Komplexität ein subjektives Empfinden einer Person ist, denn „eine hohe Komplexität stellt hohe Anforderungen an die Fähigkeit des Akteurs, Informationen zu sammeln, zu integrieren und Handlungen zu planen“ [Dörn11].
Um das Zusammenspiel zwischen Systemen und Menschen zu verdeutlichen, mit besonderer Berücksichtigung von Auswirkungen im Fehlerfall, wurde hier ein Use Case basierter Ansatz verfolgt, um entsprechende Anwendungsfälle zu identifizieren und potentielle Fehler und Fehlerursachen aufzuzeigen (vgl.[DePB03]). Die gesammelten Use Cases und potentielle Nutzungsprobleme wurden analysiert. Ein Auszug aus dem Resultat der Analyse von Use Cases eines entscheidungsunterstützenden Informationssystems wird in der anschließenden Abbildung dargestellt. Die Pfeile in der Abbildung sollen den Verlauf der Analyse verdeutlichen.
Quelle: Verfasser
Abbildung 1-2 Auswertung der Use Cases eines entscheidungsunterstützenden Informationssystems
Einfache Use Cases wie „Informationen suchen“ können schon eine Vielzahl an Nutzungs-problemen hervorrufen, die damit Auswirkung auf Gesundheit und Leben von Menschen nehmen, wie in der Abbildung 1-2 verdeutlicht.
Für die vorliegende Arbeit stellt sich damit die Frage, wie risikobasierte Ansätze aus der Entwicklung von SKS, die potentielle Störfälle in den Mittelpunkt stellen, und Lösungswege aus dem Usability Engineering, die den Mensch fokussieren, angemessen zu kombinieren sind.
Die Zusammenhänge sind in der nachfolgenden Abbildung näher aufgeführt. Methoden, z.B. aus dem Usability Engineering, sind im inneren Kreis visualisiert und sind Basiselemente, die bereits aus verschiedenen Forschungsergebnissen vorliegen. Diese sollen entsprechend variiert und in den Entwicklungsprozess von SKIS eingebettet werden (mittlerer Kreis). Umfasst werden die Entwicklungsschritte von Elementen der Risikoanalyse (äußerer Kreis), die weitere relevante Grundlagen liefern, zurzeit aber nicht in die Entwicklungsparadigmen eingebettet sind. Ziel muss es daher sein, die vorhandenen Entwicklungsmuster folgerichtig zusammenzuführen und eine wechselseitige Vernetzung zu erzeugen.
Quelle: Verfasser
Abbildung 1-3 Zusammenhang der Entwicklungsmuster der betrachteten Systemklassen
1.2 Zielsetzung und Vorgehen
“Because software is like all capital, is embodied knowledge, and because that knowledge is initially dispersed, tacit, latent, and incomplete in large measure, software development is a social learning process. The process is a dialog in which the knowledge that must become the software is brought together and embodied in the software. The process provides interaction between users and designers, between users and evolving tools, and between designers and evolving tools [technology].” ([Baet98], S. 20)
Baetjer versteht Software als verkörpertes Wissen, entstanden aus der Interaktion zwischen Nutzer, Designer und involvierten Werkzeugen. In der vorliegenden Arbeit wird zusätzlich das Risiko, das in der Interaktion entstehen kann oder der Nutzung der Software als weitere Größe in Betracht gezogen.
Ziel der Arbeit ist es somit, den Kontext und die Anforderungen der Arbeitswelt „zivile Gefahrenabwehr“ mit den Methoden und Entwicklungsansätzen von SKMMS und SKS in Beziehung zu setzen und ein optimiertes Verfahren für die Entwicklung der Systemklasse SKIS abzuleiten. Darüber hinaus sollen geeignete Maßnahmen zum Safety Assessment in den Entwicklungsphasen eines Informationssystems zum Lösen komplexer Probleme in der zivilen Gefahrenabwehr erarbeitet werden. Dabei stellt ein Safety Assessment eine Risikoüberprüfung und Beurteilung von Entwicklungsständen dar, in Bezug auf den zu erwartenden Anwendungskontext. Dazu soll im Folgenden ein Beispiel aus der Luftfahrt gegeben werden, sodass Risiken und Ursachen von Störfällen mit SKMMS aufgezeigt werden.
Fallbeispiel SKMMS (siehe [Bund02]) - Durch einen Zusammenstoß zweier Flugzeuge in 11.000 m Höhe ist im Jahr 2002 ein folgenschwerer Absturz verursacht worden – Der Absturz ist sowohl auf menschliches wie auch technisches Versagen zurückzuführen. Das Annäherungswarnsystem veranlasste eine rechtzeitige optische und akustische Warnung. Jedoch wurden widersprüchliche Angaben vom zuständigen Fluglotsen getätigt. Zudem lag ein erhöhter Stresspegel und Überlastung auf Seiten der Piloten und der Lotsen vor, sodass es zu dem entstandenen Fehler kam. Darüber hinaus bestand bei den Beteiligten ein geringes Vertrauen in das System, da aufgrund von Fehlalarmen die Bedeutung der Warnung unterschätzt und letztlich auf die Angaben des Fluglotsen vertraut wurde.
Die Luftfahrt bietet prägnante Beispiele für SKMMS. Gordon Dupont [Dupo17] stellt nach umfassender Analyse von Unfällen in der Luftfahrt mit seinen „Dirty Dozen“ Ursachen für diese Fehler auf, findet jedoch maßgeblich menschliche Ursachen:
• Lack of communication (mangelnde Kommunikation)
• Complacency (Selbstgefälligkeit)
• Lack of Knowledge (Fehlendes Wissen)
• Distraction (Ablenkung)
• Lack of Teamwork (Fehlende Zusammenarbeit)
• Fatigue (Müdigkeit)
• Lack of Resources (Fehlende Ressourcen)
•