Entwicklung eines Vorgehens zum Safety Assessment für sicherheits-kritische Informationssysteme. Christina Schäfer
alle Ursachen, die zu dieser Fehlermeldung führen, waren bei dem entsprechenden Bediener bekannt. Daher wurde zunächst mehrfach dieselbe Lösung angestrebt, die nicht zum Erfolg geführt hat. Ein größerer Erfahrungsschatz und Wissen über Ursache und Wirkung in Bezug auf die Maschine hätte Handlungsalternativen aufgezeigt und daher dem Mitarbeiter die Sicherheit zum eigenständigen Lösen des Problems gegeben.
Zu jedem Zeitpunkt hat der entsprechende Mitarbeiter die Möglichkeit seine Handlungen zu reflektieren, zu kontrollieren und zu bewerten oder sich bei anderen Mitarbeitern Rat zu suchen. Es zeigt sich deutlich, dass eine hinreichende Erfahrung des jeweiligen Mitarbeiters eine zielgerichtete Problemlösung erst möglich macht und damit ein wichtiger Baustein im Lösen komplexer Probleme ist [Funk04], was die nachfolgende Annahme verdeutlicht.
Annahme 4: Wissen des Problemlösers ist individuell an die Person gebunden, aber entscheidend für eine schnelle und nachhaltige Lösung.
Ein weiterer Aspekt eines komplexen Problems liegt in der Problembeschreibung an sich. Oftmals ist der Fehler am Produkt, was aktuell hergestellt wird, optisch zu sehen oder die Maschine bietet eine Fehlerausgabe an einem Terminal an. Aber auch hier kann eine Beschreibung von einer einfachen Ausgabe „Fehler 0815 ist aufgetreten“ bis zu einer detaillierten Lokalisation an der Maschine mit Angabe von Gründen für die entsprechende Meldung reichen. Je exakter die Fehlerbeschreibung ist, desto leichter ist für den Mechaniker die Herleitung der Ursache und somit die Behebung der Störung. Ein Mangel an der Problembeschreibung erhöht die Komplexität für den Menschen, der das Problem lösen muss.
Darüber hinaus nimmt hier die Umwelt (Rahmenbedingungen im Betrieb) Einfluss auf die Komplexität des Problems. Mehrschichtbetrieb, Fehler in der Übergabe zwischen den Schichten, Lärm in der Fertigungshalle und u.U. erforderliche Arbeitskleidung erschweren die Arbeit und somit eine effiziente Problemlösung. Zudem arbeiten oftmals Bediener, Mechaniker, Elektroniker und teilweise noch weiteres Personal an ein und derselben Maschine. In anderen Betrieben hingegen erfüllt eine Person nahezu alle diese Aufgaben. Daher haben die unterschiedlichen Benutzertypen auch verschiedene Wissensstände, zumal sie nicht die gleiche Ausbildung erhalten haben. Mechaniker und Elektroniker haben in der Regel die übliche Berufsausbildung ihrer Sparte absolviert, wobei Bediener unter Umständen auch ungelernt sein können und ihre Qualifikationen nur über die Arbeit an der Maschine gewonnen haben. Es ist auch möglich durch eine Teilnahme an einer Schulung oder anderen Weiterbildungen höhere Eignungen zu erreichen, was nicht jeder Bediener bzw. nicht jeder Betrieb in Anspruch nimmt. Die Erfahrung in Bezug auf die Maschine, mit der Arbeitsaufgabe und der allgemeinen Organisation des Betriebs variiert bei jedem, je nach Ausbildung, aber auch nach Dienstalter in dem jeweiligen Unternehmen. Es lässt sich allerdings auch feststellen, dass jüngeren Mitarbeiter der Umgang mit neuen Gegebenheiten leichter fällt, wie Bedienung der Maschine über einen Touchscreen und IT-Unterstützung in der Handhabung der Maschine. Die persönlichen Merkmale der Mitarbeiter, wie Alter oder Geschlecht, hängen natürlich auch stark von dem Betrieb, aber auch von dem Land, in dem das Unternehmen tätig ist, und dessen üblichen Standards ab. [Reck07]
Aus diesem Beispiel und der Differenzierung der einzelnen Mitarbeiter kann die nachfolgende Annahme gefolgert werden.
Annahme 5: Eine hohe Gebrauchstauglichkeit eines Informationssystems basiert auf einer hinreichenden Analyse des Nutzungsrahmens (Benutzer, Aufgabe, Kontext).
In diesem Abschnitt der Arbeit wurden die Bedienung einer Mensch-Maschine-Schnittstelle und die Relevanz von Erfahrung im Umgang mit der Maschine thematisiert. Basierend auf dem gegenwärtigen Standpunkt fehlt die Verknüpfung von Risikobetrachtungen und der Entwicklung von gebrauchstauglichen Systemen in dem Kontext und eröffnet daher den Handlungsbedarf.
2.3 Benutzerspezifische Qualitätseigenschaften
Um die Differenzierung zwischen den verschiedenen Einsatzkräften zu verdeutlichen, wird hier die Evaluation eines BMBF-Projektes herangezogen. Das Projekt AirShield3 hatte zum Ziel, Feuerwehr-Einsatzkräfte in einem Einsatz mit Gefahrstoffen (Atomar, Biologisch, Chemisch) zu unterstützen, durch die Nutzung unbemannter Flugroboter, die eine Gefahrstoffmessung des potentiell kontaminierten Gebiets teilautomatisiert durchführen können. Hierzu wurde eine Benutzungsschnittstelle konzipiert, die die Steuerung und Koordination der Flugroboter realisierte, eine Lagedarstellung liefert, die (zukünftige) Prognose simuliert und darauf basierend eine Entscheidungsunterstützung anbietet.
Es wurden drei Rollen mit unterschiedlichen Systemsichten definiert, um eine rezipierbare Unterstützung für die operative Einheit (ABC), die operativ-taktische Führungsstelle (EAL) und die technische Einsatzleitung (TEL) zu erzeugen [SPLR10]. Da jede Rolle einen abweichenden Informationsbedarf aufweist, wurden insbesondere für die Komponente der Entscheidungsunterstützung diese verschiedenen Sichten realisiert. Dazu wurden für jede Rolle relevante Ereignisse identifiziert und die Abhängigkeit zwischen einem Ereignis und einem daraus resultierenden Bedarf an neuen Informationen hergeleitet. Es wurden sowohl externe Ereignisse, wie die Detektion von Gefahrstoffen berücksichtigt, als auch interne Ereignisse, wie das Abschließen einer vorherigen Handlungsempfehlung oder Definieren eines Gefahrengebiets im System betrachtet. Zur Realisierung ist im AirShield-System ein regelbasierter Ansatz verfolgt worden, in dem periodisch die Gültigkeit von Prämissen geprüft wurde. Letztlich wurden so für jede Rolle abweichende Inhalte erzeugt, die Präsentation und Navigation im System wurde aber nicht variiert [KSFS11].
In der System - Evaluation wurden zwölf Probanden im Rahmen von semistrukturierten, offenen Interviews unter der Nutzung von vordefinierten Szenarios bezüglich Inhalt, Präsentation und Navigation des Systems befragt [FrSK12]. In den Szenarien wurde ein für die entsprechende Rolle typischer Ablauf definiert, in dem zu Beginn allgemeine Fertigkeiten in Bezug auf die Nutzung eines Geo-Informationssystems (GIS) abgefragt wurden (z.B. Zoomen, …). Im Weiteren wurden die Aufgaben spezifischer, in Relation zur Nutzung des Systems von der entsprechenden Rolle in der ABC-Gefahrenabwehr. Zur Erhöhung der Validität der Testergebnisse wurde sowohl schriftlich als auch durch eine Kamera protokolliert. Für die Auswertung wurden die Aussagen digitalisiert und entsprechend in vorher definierten Kategorien gruppiert. Die Evaluation diente zum einen der Prüfung der Erfüllung von Benutzeranforderungen und zum anderen der Priorisierung der weiterführenden Entwicklungsarbeiten. Das genaue Vorgehen wurde von Friberg und Schäfer in [FrSK12] beschrieben.
Auch wenn das System in seiner Gesamtheit auf Zustimmung gestoßen ist, konnten inner-halb einzelner Komponenten stark divergierende Äußerungen festgestellt werden. Für einige war der Informationsgehalt schon zu hoch, andere wünschten sich darüber hinaus noch viele weiterreichende Angaben. Während ein Teil der Probanden sich schon auf bestehendes Wissen bezüglich GIS-Anwendungen berufen konnte, war für andere die Navigation im System eine Herausforderung. Um Abweichungen zwischen den Probanden insbesondere für die Komponente der Entscheidungsunterstützung feststellen zu können, wurden im Rahmen dieser Arbeit die Aussagen nochmal in die übergeordneten Kategorien Inhalt, Navigation der Benutzungsschnittstelle und Präsentation untergliedert. Die Ergebnisse in Bezug auf die detaillierte Analyse werden im Folgenden dargestellt.
Navigation. Im Rahmen der Navigation sind zwei Aspekte zu betrachten. Das Entscheidungsunterstützungssystem ist nur eine Teilkomponente des Gesamtsystems von AirShield. Daher ist der eine relevant zu untersuchende Aspekt die Navigation zur Komponente und des Weiteren ist die Navigation innerhalb der Komponente zu betrachten. Die Realisierung der Integration des Entscheidungsunterstützungssystems (DSS) erfolgte mittels eines dritten Tabs in der unteren Navigationsleiste, wie es in der nachfolgenden Abbildung dargestellt ist (gekennzeichnet durch einen roten Pfeil).
Quelle: Verfasser siehe auch Koch et al. [KSFS11]
Abbildung 2-8 Gesamtsystem AirShield
Das DSS als Komponente kann auf verschiedene Weise in das Gesamtsystem integriert werden. Es wurde entschieden das DSS als Komponente gekapselt einzubinden. Drei grundlegende Einstellungen in Bezug auf die Platzierung des DSS im Gesamtsystem können daher angenommen werden.
• Gleichbleibende Kapselung (z.B. DSS als eigenständiger