Fehlervermeidung und Prozessmonitoring in komplexen und dynamischen Groschadenslagen Dissertation zur Erlangung des akademischen Grades doctor rerum naturalium (Dr. rer. nat.) vorgelegt dem Rat der Fakultur Mathematik at f und Informatik der Friedrich-Schiller-Universit at Jena von Dipl.-Inf. Uwe Kr uger geboren am 29. Mai 1972 in Eisenberg Friedrich-Schiller-Universit at Jena Fakultur Mathematik und Informatik at f¨ Institut f¨ ur Informatik Gutachter: 1. Prof. Dr. Clemens Beckstein, Praktische Informatik (Kunstliche Intelligenz), Institut fat Jena ur Informatik, Friedrich-Schiller-Universit 2. Prof. Dr. Stefan Strohschneider, Forschungsstelle interkulturelle und komplexe Arbeitswelten (FinkA), Fachgebiet Interkulturelle Wirtschaftskommunikation (IWK), Friedrich-Schiller-Universit at Jena Tag der  o entlichen Verteidigung: 26. August 2014 Kurzfassung In dieser Arbeit wird der Frage nachgegangen, inwieweit eine Computerunterst utzung in komplexen, kritischen Arbeitsbereichen zu einer Harmonisierung der Handlungsabl aufe und zur Verhinderung von Fehlern (z. B. Ged achtnisfehlern) beitragen kann. Als Beispiel eines komplexen und dynamischen Arbeitsbereiches wird das Agieren von Beh orden und Organisationen mit Sicherheitsaufgaben (BOS) in Groschadenslagen betrachtet. Motiviert durch den groen Erfolg von Checklisten in der Luftfahrt und in der Intensivmedizin, wird in ¨ dieser Arbeit eine systematische Ubertragung des Checklisten-Prinzips auf den deutschen BOS-Bereich vorgeschlagen. Hierfwird ein Rahmenwerk eines intelligenten elektroni ur schen Checklisten-Assistenzsystems erarbeitet, das auch falternative, soziotechnische ur Arbeitssysteme mit dem BOS-Bereich  ahnlichen Merkmalen hilfreich zur Fehlervermeidung eingesetzt werden kann. i ii Inhaltsverzeichnis Kurzfassung i 1 Einleitung 1 1.1 Motivation .................................... 1 1.2 AufteilungderArbeit .............................. 3 2 Akteure und Handlungsroutinen in Groschadenslagen 5 2.1 Beh............ orden und Organisationen mit Sicherheitsaufgaben 5 2.2 Groschadensereignisse und deren Charakteristiken . . . . . . . . . . . . . . 8 2.3 EinsatzplanungundEinsatzvorbereitung .................... 11 2.4 HandlungsroutinenundIT-Unterst. . . . . . . . . . . . . . . . . . . utzung 13 3 Stand der Forschung zur IT-Unterstur SOPs utzung f17 3.1 Forschungsperspektiven zur SOP-Unterst17 utzung... ... ... .. . .. .. 3.2 BusinessProcessundWork owManagement . . . . . . . . . . . . . . . . . 18 3.3 Ans................. atze der automatische Handlungsplanung 21 3.4 Fazit und Motivation des Checklisten-Ansatzes . . . . . . . . . . . . . . . . 27 4 Checklisten – eine Human Factors Perspektive 29 4.1 Strategien der Fehlervermeidung & Handlungsassistenz . . . . . . . . . . . . 29 4.2 ChecklistenalskognitivesHilfsmittel . . . . . . . . . . . . . . . . . . . . . . 31 4.2.1 Was sind Checklisten? – eine Arbeitsde nition . . . . . . . . . . . . 32 4.2.2 Funktionen, Einsatzbereiche und Zielgruppen . . . . . . . . . . . . . 33 4.2.3 ItemsundAnwendungsmethoden .................... 36 4.2.4 Repr................ asentationsformen von Checklisten 38 4.2.5 Nachteile und Akzeptanzproblematik . . . . . . . . . . . . . . . . . . 39 4.3 Unterscheidung der Begri e Checkliste und SOP . . . . . . . . . . . . . . . 40 iii INHALTSVERZEICHNIS 5 Intelligente elektronische Checklisten-Assistenz 43 5.1 Motivation & Anforderungen einer elektronischen Checklisten-Assistenz . . 43 5.2 Grundlegende Konzepte und Designentscheidungen . . . . . . . . . . . . . . 48 5.2.1 RollenundRollen............ ubernahme in einem Einsatz 48 5.2.2 Charakteristische Merkmale von Checklisten und SOPs . . . . . . . 51 5.2.3 Komplexit.............. at handhaben durch Hierarchien 57 5.2.4 HTN-Planung und Theorien der Handlungsregulation . . . . . . . . 64 5.2.5 Checklisten-Auswahlprozess und -Zuordnung . . . . . . . . . . . . . 69 5.2.6 StandardisiertesVokabular ....................... 71 6 Technische Realisierung 75 6.1 Komponenten der Casie-Architektur...................... 75 6.1.1 CL-Client, Benutzerschnittstelle und Endger. . . . . . . . . . . . ate 77 6.1.2 CL-Manager ............................... 79 6.1.3 CL-Repository&-Logbook ....................... 80 6.1.4 Knowledge-Base (System) / BOS-Ontologie . . . . . . . . . . . . . 81 6.2 Dynamik/reaktivesSystemverhalten ..................... 88 6.2.1 Zustandsange einer Checkliste und deren Items . . . . . . . . . 88 uberg 6.2.2 (Intelligentes) reaktives Systemverhalten . . . . . . . . . . . . . . . . 90 6.3 Kon guration/Wartung ............................. 94 6.3.1 EntwicklungeinerBOS-Ontologie. . . . . . . . . . . . . . . . . . . . 95 6.3.2 EntwicklungvonICLs .......................... 103 7 Vorteile der CASIE-Anwendung in der Praxis 107 7.1 BeitragzurFehlervermeidung .......................... 107 7.2 Prozessmonitoring ................................ 108 7.3 Zus........................ atzliche Vorteile und Ausblick 109 8 Zusammenfassung 117 Literaturverzeichnis und Photonachweise 122 Abbildungsverzeichnis 135 Kapitel 1 Einleitung Die Menschen stolpern nicht  uber Berge, " sondern ugel.“ (Konfuzius) uber Maulwurfsh 1.1 Motivation Wir Menschen sind zu groen geistigen Leistungen f ahig, jedoch nicht unfehlbar in dem, was wir tun. So stoen wir zum Beispiel beim Versuch, alle Schritte einer komplexen und ungewohnten Handlungssequenz korrekt auszuf uhren, in den Situationen an unsere Grenzen, in denen wir zus atzlich hohem physischen und psychischen Stress ausgesetzt sind. Denkblockaden und Vergesslichkeit sind die Folge. Dem steht eine Zunahme an Komplexit uber, wodurch sich das Risiko menschlicher Fehler at in vielen Arbeitsbereichen gegen erh oht [Rea94]. Vor allem in dynamischen Ad-hoc-Arbeitsumgebungen, in denen Teams unterschiedlicher Profession an der Abarbeitung komplexer und verteilter Aufgabenstellungen arbeiten, stellt eine fehlerfreie Abarbeitung und Koordinierung aller dabei gebotenen Handlungen eine besondere Herausforderung dar. Das Agieren von Beh orden und Organisationen mit Sicherheitsaufgaben (BOS) in Groschadenslagen ist ein solch komplexer und zugleich dynamischer Arbeitsbereich. Er enth alt eine Vielzahl kritischer Handlungsroutinen, bei denen menschliche Fehler enorme Auswirkungen haben kat onnen. Unter Komplexit eines solchen sog. soziotechnischen Arbeitssystems (vgl. [BHL08], S. 157 .) werden die u. a. von Simon [Sim62] und Dor75] charakterisierten Merkmale wie Anzahl der Auf orner [D gaben und Akteure, Vielfalt der magungen und die Vernetztheit oglichen Handlungsauspr verstanden (vgl. Manser [Man09] und Schaub [Sch06]). Die Dynamik, Intransparenz und Unbestimmtheit sind weitere charakteristische Merkmale eines solchen Arbeitsumfeldes. In Groschadenslagen unterliegen Einsatzkr afte in besonderem Mae groem physischen und psychischen Stress. Es ist daher nicht zu erwarten, dass alle erlernten Arbeitsabl aufe korrekt erinnert und im Ernstfall fehlerfrei durchgefatzun uhrt werden [Rea90; BHL08]. Sch gen gehen davon aus, dass gerade bei besonders groen Einsatzlagen, mit Dutzenden von Schwerverletzten, bis zu ein Drittel der Verletzten wegen Missmanagement am Einsatzort und in der Klinik unn otig versterben (vgl. [KHK+06]). Auch wenn groe Verletztenzahlen bei nur agen oder Naturkata auerst selten eintretenden Ereignissen wie z. B. Terroranschl strophen zu verzeichnen sind, o enbaren die Auswertungen bereits kleinerer Eins atze und ¨ Ubungen nicht selten eine Diskrepanz zwischen der A-priori-Vorstellung dessen, wie ein Schadensereignis zu managen ist (best practice\) und dem tats achlichen Verlauf. Insbe " sondere wird das Management in Groschadenslagen zus atzlich dadurch erschwert, dass 1 Motivation eine groe Anzahl von freiwilligen Einsatzkr aften beteiligt sind, welche weniger routiniert in dem fehlerfreien Anwenden von groschadensspezi schen Handlungsroutinen sind. Aus Eigeninitiative der BOS und aus Interesse von Forschungseinrichtungen und L andern untersuchen diese in jarkt den Einsatz von Computerunterst ungster Zeit verstutzung im Krisenmanagement und bei der Abarbeitung von Groschadenslagen. Ein Beispiel hier- f ur ist der Forschungsschwerpunkt Schutz und Rettung von Menschenleben“ im Rahmen " des Sicherheitsforschungsprogramms der Deutschen Bundesregierung, in dem eine Vielzahl von Projekten (siehe [BMBF]) die Einsatzm oglichkeiten von IT in Groschadenslagen untersucht. W ahrend sich viele dieser Projekte auf eine robuste Kommunikation zwischen den Einsatzkrutzung, eine Bereitstellung eines allumfassenden In aften, eine Telemetrieunterst formationssystems oder auf eine Kartendarstellung des Einsatzortes fokussieren, bleibt eine praktikable Assistenz von Handlungsroutinen bisher noch weitgehend unber ucksichtigt. Auch haben die auf internationaler Ebene in den letzten 20 Jahren vorgestellten L osungsans utzung im Krisenmanagement keinen Niederschlag in die heutige atze zur IT-Unterst (deutsche) BOS-Praxis gefunden. Ein Grund hierf ur liegt darin, dass der BOS-Bereich (im Vergleich zur Industrie oder speziell dem Militoglich ar) aktuell erst im Begriff ist, die M keiten eines Computereinsatzes am Einsatzort auszuloten und vereinzelt zu testen. Diese Arbeit geht der Frage nach, inwieweit eine Computerunterst utzung in komplexen, kritischen Arbeitsbereichen zu einer Harmonisierung der Handlungsabl aufe und zur Verhinderung von Fehlern (z. B. Ged achtnisfehlern) beitragen kann. Als Beispiel wird der Arbeitsbereich der deutschen BOS betrachtet, dessen besondere Merkmale und Anforderungen herausgearbeitet werden. Mageblich fosungsansatzes ur die Wahl des hier vorgestellten L ist die Beobachtung, dass ein vermeintlich simpler und im BOS-Bereich momentan wenig beachteter Kontrollmechanismus dazu dienen kann, menschliches Handeln fehlerfreier und konsistenter bez uglich Standardhandlungsroutinen werden zu lassen. Die Rede ist von Checklisten (CL), deren Anwendung mittlerweile eine Erfolgsgeschichte in vielen Hochsicherheitsbereichen wie etwa in der Luftfahrt [DW90] und der Intensivmedizin [Gaw10] verzeichnen kann. So entwickelte z. B. die Luftfahrt bereits Ende der 1960er Jahre eine gesunde Ehrfurcht gegen uber ihren immer komplexer werdenden Flugzeugen und den dazugeh  origen Arbeitsprozessen und entschied, Checklisten als kognitives Hilfsmittel dem menschlichen Geist bei der t aglichen Arbeit an die Seite zu stellen. Heutzutage sind sie ein fest etablierter Bestandteil aller sicherheitskritischen Prozeduren im Cockpit (siehe z. B. [DW90; DW93]). Warum also nicht von diesem positiven Beispiel lernen? Basierend auf diesen Erfahrungen des Checklisteneinsatzes wird in dieser Arbeit ei¨ ne systematische Ubertragung des Checklisten-Prinzips auf den deutschen BOS-Bereich vorgeschlagen. Hierzu wird nach einer Analyse der Praxisbedingungen und einer systematischen Betrachtung des Checklisten-Prinzips selbst ein Rahmenwerk f ur ein intelligentes elektronisches Checklisten-Assistenzsystem erarbeitet. Die Arbeit adressiert noch keine Implementierung und Evaluation unter Praxisbedingungen. Vielmehr gibt sie einen Anstoß funftigen Transfer des Checklisten-Prinzips in den BOS-Bereich. Sie soll inter ur einen zuk essierten Anwendern als Grundlage f ur kommende Implementierungen dienen. Die Arbeit diskutiert dar uber hinaus die zu erwartenden Vorteile einer computerverarbeitbaren Lagerepr ur erarbeitete Rahmenwerk asentation mittels einer formalen Wissensbasis. Das hierf ist prinzipiell domangig und auf alternative soziotechnische Arbeitssysteme mit anenunabh hohen Sicherheitsanforderungen und  ahnlichen Merkmalen wie die im BOS-Bereich ubertragbar. Aufteilung der Arbeit Die Arbeit gibt einen L osungsvorschlag zur Fragestellung, wie in der komplexen und dynamischen Arbeitsumgebung einer Groschadenslage ein Beitrag zur Fehlervermeidung geleistet werden kann. Die Arbeit geht dabei von folgender Hauptthese aus: EineIT-unterstutzteUmsetzungdesChecklisten-PrinzipsistimBOS-Bereichbeson- dersgeeignet,umeinensigni kantenBeitragzurFehlervermeidungundbesserenHandhabungvonKomplexitatimManagementeinerGroschadenslagezuleisten. These1 Zus atzlich wird gezeigt, wie ein Checklisten-Assistenzsystem einen Beitrag zum Aufbau eines einheitlichen Lagebildes leisten kann: DieAnwendungvernetztercomputerintegrierterChecklistenkannfureinProzessmo- nitoringgenutztwerden,welcheszusatzlichdemAufbaueinesLagebildesdientundsomitzueinemeinheitlichenLageverstandnis(SituationAwareness)fuhrt. These2 Dar uber hinaus weist das vorgestellte Rahmenwerk eine Vielzahl von Zusatze ekten auf: EineelektronischeChecklisten-AssistenzkannzueinerqualitativenVerbesserungdergesamtenEinsatzabwicklungbeitragen,dieweituberdiepositivenE ektederFehlervermeidungunddesProzessmonitoringshinausreicht. These3 Der Grundansatz dieser Arbeit basiert auf Erkenntnissen und Arbeiten aus dem BMBF Forschungsprojekt SpeedUp1 (siehe [KGK+10; WYM+11; WKK11; KWB12]), im Zuge dessen bereits Fragen und Latze einer m osungsansoglichen IT-Assistenz im BOS-Bereich bearbeitet wurden. Darosungsansat uber hinaus wurden die Wahl und die Umsetzung des L zes durch Erkenntnisse der Human-Factors-Forschung beein usst, die sich unter anderem mit Phaftigt. Nicht anomenen menschlicher Handlungen in komplexen Arbeitswelten besch zuletzt ossen fr uhere beru iche Erfahrungen2 des Autors mit in die Problemanalyse und die Konzeption eines vor allem praktikablen L osungsansatzes ein. 1.2 Aufteilung der Arbeit Das Kapitel 2 erlur werden zu Be autert den Arbeitsbereich der deutschen BOS. Hierf ginn die wichtigsten Organisationen vorgestellt und deren typische Einsatzvorbereitung und -koordination skizziert. Es wird auf besondere Einsatzlagen und deren Spezi ka eingegangen sowie die Grundlagen der F uhrungsorganisationen, die Einsatzdynamik und die Charakteristiken der Einsatzphasen aufgezeigt. Dar uber hinaus werden die in der Praxis oglichkeiten der Erfassung und Standardisie ublichen vorbereitenden Manahmen sowie M¨ rung von Handlungsroutinen betrachtet. Es wird der Frage nachgegangen, welchen Stellenwert das Auftreten m¨ oglicher Fehler in der Organisationskultur der BOS hat und welche 1 Titel: Untersuchung von mobilen und selbstorganisierenden Kommunikations-und Datenplattformen " sowie Organisations-und Handlungsstrategien fur komplexe Grolagen\. (Mai '09 -Juli '12) 2 Der Autor war 6 Jahre im aktiven Rettungsdienst und als Disponent einer Rettungsleitstelle t atig. Aufteilung der Arbeit Strategien zur Fehlervermeidung heute in der Praxis angewandt werden. Abschlieend wird auf den derzeitigen Einsatz von IT im Einsatzmanagement eingegangen. In Kapitel 3 werden bisherige Forschungsarbeiten zur Thematik IT-Einsatz zur Prozesserfassung und -unterst utzung in Krisenszenarien betrachtet. Hierbei werden zwei Herangehensweisen vorgestellt: Arbeiten aus dem Umfeld der Gesch aftsprozessmodellierung und Arbeiten aus dem Themenumfeld der automatischen Handlungsplanung der K unstlichen Intelligenz. Zusur die Problemstellung relevante Ergebnisse des For atzlich werden f schungsbereiches Human Factors studiert, welche sich unter anderem mit der Thematik Fehlervermeidung befassen. ¨ Das Kapitel 4 gibt einen Uberblick uber wichtige Aspekte des Checklisten-Prinzips  und geht auf die Anwendungsprinzipien in kritischen Arbeitsbereichen ein. Hierf ur werden die positiven Erfahrungen aus Hochsicherheitsbereichen wie Luftfahrt und Medizin analysiert und Grundprinzipien hinsichtlich Funktionen und Anwendungen herausgearbeitet. Weiterhin wird gekl art, welche Grundbestandteile Checklisten aufweisen und wer sie wann und wie einsetzt. Das Kapitel zeigt dar uber hinaus, welchen Problemen Checklisten entgegenwirken sollen und welche bekannten Nachteile sie haben. In Kapitel 5 wird ein Rahmenwerk eines intelligenten elektronischen Checklisten- Assistenzsystems vorgestellt, das jeder BOS (und Organisationen mit  ahnlichem Arbeitsumfeld) eine Hilfestellung bei der Sicherstellung fehlerfreier Anwendung von Standardhandlungsroutinen ermosungsidee motiviert und daraus oglicht. Hierzu wird zu Beginn die L abgeleitet die drei Thesen der Arbeit aufgestellt. Weiterhin werden die Anforderungen an ein elektronisches Checklisten-Assistenzsystem benannt und dessen grundlegende Konzepte und Designentscheidungen vorgestellt. Im Kapitel 6 wird eine zu den erarbeiteten Anforderungen passende Architektur vorgestellt und die Dynamik des Assistenzsystems erl autert. Neben der Vorstellung der Architekturkomponenten wird im Besonderen die Wissensbasis als die ausschlaggebende Komponente f ur ein intelligentes Systemverhalten behandelt. Auf die Fragen der richtigen Kon guration eines solchen Systems geht der Schluss des Kapitels ein. Das Kapitel 7 geht auf die Pragmatik und die sich zusur die Praxis ergebenden atzlich f Anwendungsm oglichkeiten ein. Es wird eine Reihe positiver Konsequenzen der Anwendung eines auf der Casie-Architektur basierenden Assistenzsystems vorgestellt, die neben der gew unschten Fehlervermeidung und dem Prozessmonitoring einen qualitativen Sprung im Management einer Groschadenslage darstellt. Abschlieend zieht Kapitel 8 ein Res umee der Arbeit und fasst das Erreichte zusammen. Darunftige Aufgabenstellungen uber hinaus gibt das Kapitel einen Ausblick auf zuk und nennt noch ungel oste Problemfelder. Kapitel 2 Akteure und Handlungsroutinen in Groschadenslagen Dieses Kapitel skizziert den komplexen und dynamischen Arbeitsbereich (ausgew ahlter) deutscher Beh orden und Organisationen mit Sicherheitsaufgaben (BOS). Es werden hierzu Charakteristiken besonderer Einsatzlagen und die sich daraus fdie Einsatzkrer ur afte gebenden Schwierigkeiten vorgestellt. Weiterhin wird kurz auf den organisationsinternen Umgang mit Fehlern eingegangen und der heutige Stand der IT-Unterst utzung mit dem Blick auf die Standardhandlungsroutinen diskutiert. Eine detaillierte Einf uhrung in die Thematik kann und soll dieser Abschnitt nicht bieten. F ur weitere Informationen sei der interessierte Leser auf die entsprechende Fachliteratur verwiesen. Als Einstieg emp ehlt sich z. B. die SEGmente Reihe des Stumpf + Kossendey Verlags (siehe z. B. [PM01]) und die Abhandlung von Lipp [Lip09]. 2.1 Beh orden und Organisationen mit Sicherheitsaufgaben Bevor auf die Charakteristiken von Groschadenslagen eingegangen wird, sollen die beteiligten Akteure mit ihren unterschiedlichen Aufgabenbereichen vorgestellt werden. In Deutschland z ahlen die Feuerwehr, der Rettungsdienst und die Polizei mit zu den wichtigsten BOS. Zusammen mit weiteren Organisationen decken sie in der Regel unterschiedliche Aufgabenbereiche ab. Feuerwehr Im Rahmen der nichtpolizeilichen Gefahrenabwehr  ubernimmt die Feuerwehr Aufgaben aus den Bereichen Retten, Lutzen, die durch Gesetze der jeweiligen oschen, Bergen und Sch Bundesl ander und Kommunen geregelt sind. Laut dem Bundesministerium des Inneren (BMI) hat die Feuerwehr die Aufgabe, innerhalb des deutschen Notfallvorsorgesystems bei ¨ Brallen, ahnlichen Ereignissen Hilfe zu leisten. anden, UnfUberschwemmungen und  Obwohl jede gr oere Stadt typischerweise eine sog. Berufsfeuerwehr vorweist, deren Einsatzkr  afte meist Beamte der jeweiligen Kommune sind, bilden die freiwilligen Feuerwehren zahlenmuckgrat des deutschen Feuerwehrsystems. aig das R In Deutschland spielen die Feuerwehr-Dienstvorschriften (FwDV) eine groe Rolle bei der Regelung der Aufgabenbereiche und der Durchfatzen. Je nach T uhrung von Einsatigkeitsfeld existieren eine Reihe unterschiedlicher Dienstvorschriften. Als Beispiel sei eine der wichtigsten genannt: 5 Beh orden und Organisationen mit Sicherheitsaufgaben • FwDV 100: F uhrung und Leitung im Einsatz. Zweck der Feuerwehr-Dienstvorschriften ist es, die erforderliche Einheitlichkeit im Feuerwehrdienst herbeizuf uhren und ” auch zukur den Einsatz und f unftig sicherzustellen. Sie gelten fur die Ausbildung“ (siehe [FwDV100]). Die Dienstvorschriften sind jedoch als grobe Richtlinie zu verstehen und geben lediglich einen Rahmen fandern zur ur eine konkrete Ausgestaltung vor. Sie werden den Bundesl Einfanderspe uhrung empfohlen und werden aufgrund der unterschiedlichen Rechtslagen l zi sch umgesetzt. Die aktuell gander un ultigen Dienstvorschriften der einzelnen Bundesl terscheiden sich daher mehr oder weniger stark. Die Struktur der Einsatzleitung auf der operativ-taktischen Fuhrungs uhrungsebene (F ¨ stab, Technische Einsatzleitung, Ortliche Einsatzleitung und Gemeinsame Einsatzleitung vor Ort) ist von der Gefahrenlage, dem Schadensereignis und den zu f uhrenden Einheiten abhangig. Wer konkret die Einsatzleitung  ubernimmt, ist in den Feuerwehr-bzw. den Katastrophenschutzgesetzen der L ander geregelt [FwDV100]. Ist die Feuerwehr bei einer Schadenslage beteiligt, so benennt der oberste Verwaltungsbeamte einen Einsatzleiter f ur die Leitung des kompletten Schadensereignisses. Er ist typischerweise ein erfahrener und speziell geschulter Feuerwehrbeamter. Zur Bew altigung der vielfuhrungs altigen Aufgaben wird der Einsatzleiter durch einen zu etablierenden F stab unterstatigkeiten aller beteiligten Stellen und utzt. Die Einsatzleitung koordiniert die T stellt die Schnittstelle zu den nachgeschalteten Faben und der zust uhrungsstandigen Rettungsleitstelle dar. Sie etabliert sich generell am Einsatzort z. B. in einem Einsatzleitwagen (ELW) [PM01]. Rettungsdienst Der Aufgabenbereich des Rettungsdienstes liegt in der Sicherstellung einer notfallmedizinischen Grundversorgung am Notfallort, dem Herstellen der Transportf ahigkeit und dem unter medizinisch-fachlicher Betreuung durchzuf uhrenden Transport in ein geeignetes Krankenhaus zur weiteren Versorgung. Der Rettungsdienst wird je nach Region vorrangig von Hilfsorganisationen wie z. B. dem Deutschen Roten Kreuz (DRK), dem Arbeiter-Samariter- Bund (ASB), der Johanniter-Unfall-Hilfe (JUH) und dem Malteser Hilfsdienst  ubernommen. Durch eine sog. Bedarfsplanung ist festgelegt, wie viele Rettungswagen (RTW), Notarzteinsatzfahrzeuge (NEF) und Krankentransportwagen (KTW) in der jeweiligen Region vorzuhalten sind, und wie dementsprechend die zeitlich-personelle Besetzung (Dienstplan) der Rettungsmittel zu erfolgen hat. Typischerweise beteiligt sich in St adten, die eine Berufsfeuerwehr unterhalten, auch die Feuerwehr mit eigenen RTW und NEF an dieser Aufgabe. Hinzu kommen in einigen Regionen private Rettungsdienstunternehmen. Die gesetzlichen Grundlagen der Aufgaben des Rettungsdienstes sind in den Rettungsdienstgesetzen bzw. Katastrophenschutzgesetzen der verantwortlichen Kommunen und L andern geregelt. Als Beispiel eines von 16 Gesetzen sei das entsprechende Gesetz von Th u- ringen genannt: • Thuringer Rettungsdienstgesetz (2008), dessen Zweck die Regelung einer uRettG: Th Sicherstellung einer bedarfsgerechten medizinischen Versorgung der Bev olkerung mit " Leistungen des Rettungsdienstes“ ist (siehe [Th urRettG]). Bei einer gr oeren Einsatzlage sind im Rettungsdienst zwei verschiedene Einsatzleitertypen dafuhren. Stellvertretend ur verantwortlich, das Notarzt-bzw. Rettungsdienstpersonal zu f furinger Rettungsdienstgesetz [Th ur die Rettungsdienste sei folgend aus dem ThurRettG] zitiert. Dort heit es unter § 17 Rettungsdienstliche Versorgung in besonderen FZur allen: ” Beh orden und Organisationen mit Sicherheitsaufgaben Sicherstellung der rettungsdienstlichen Versorgung bei gr oeren Notfallereignissen unterhalb der Katastrophenschwelle mit mehreren Verletzten oder Erkrankten, bei denen die Tussen, hat der Aufgabentr atigkeiten des eingesetzten Personals koordiniert werden mager des bodengebundenen Rettungsdienstes eine rettungsdienstliche Einsatzleitung vor Ort einzurichten. Dieser geh oren insbesondere ein Leitender Notarzt und ein Organisatorischer Leiter an.“ Die einzelnen Aufgabenbereiche werden ebenfalls im § 17 spezi ziert: • Leitender Notarzt (LNA): Der Leitende Notarzt leitet den rettungsdienstlichen " Einsatz, stimmt alle medizinischen Manahmen aufeinander ab und  uberwacht deren Durchfuber dem Personal des Rettungsdienstes, den einge uhrung. [...] Er ist gegen¨ ¨ setzten Arzten und den sonstigen zur rettungsdienstlichen Versorgung eingesetzten Kr\ aften weisungsbefugt. • Organisatorischer Leiter Rettungsdienst (OrgL): Der Organisatorische Leiter " unterst¨ uhrungs-und Koor utzt den Leitenden Notarzt, indem er organisatorische F¨ dinationsaufgaben ubernimmt. Er ist gegen¨ uber dem Personal des Rettungsdienstes und den zur rettungsdienstlichen Versorgung eingesetzten Kr\ aften weisungsbefugt. Polizei Die Aufgaben der Polizei ergeben sich aus Recht und Gesetz. Sie umfassen insbesondere die Gefahrenabwehr einschlielich Gefahrenvorsorge und die vorbeugende Bek ampfung sowie die Verfolgung von Straftaten und Ordnungswidrigkeiten [PDV100]. Speziell in einer Groschadenslage mit vielen Verletzten und Toten ist die Polizei zustur Amts-und andig f Vollzugshilfe, die Betreuung und Identi zierung unbekannter hil oser Personen, die Einleitung von Todesermittlungsverfahren sowie f ur die Beweissicherung, Ursachenforschung und Eigentumssicherung [Wei02]. Die Polizeidienstvorschriften (PDVs) regeln die Aufgaben und die Vorgehensweisen der Polizeikrur sind: afte. Beispiele hierf • PDV 100: F uhrung und Einsatz der Polizei (Ausgabe 1999). In der Verordnung werden alle Facetten der F uhrung und des Einsatzes der Polizei skizziert [PDV100]. • PDV/DV 800: Fernmeldeeinsatz (Ausgabe 1986). Diese Dienstvorschrift befasst sich mit Planung, Aufbau und Betrieb des Fernmeldeverkehrs und hat ebenfalls im Katastrophenschutz sowie der Feuerwehr Bedeutung. Die konkrete Ausgestaltung der Dienstvorschriften f allt auch hier bei den unterschiedlichen Polizeipruhrungsorgane ist ( asidien unterschiedlich aus. Der Aufbau der Fahnlich wie bei der Feuerwehr) abhuhrenden angig von der Art der sog. Aufbauordnung und den jeweils zu f Organisationseinheiten. Die F uhrungsstruktur der Polizei unterscheidet die Allgemeine Aufbauordnung (AAO) und die Besondere Aufbauordnung (BAO). Waglichen ahrend die AAO im Rahmen des t Dienstes etabliert ist,  andert sich die Struktur hin zu einer BAO, wenn es sich um einen gr oeren Einsatz handelt. Der Aufbau der BAO gliedert sich in zwei Phasen. Phase 1: Sofortmanahmen zur Stabilisierung der Lage, Vorbereitung der Phase 2 und Alarmierung aller zu Beginn benafte. Phase 2: Bewuhrungs otigten Kraltigung des Einsatzes mit dem F stab bzw. der F uhrungsgruppe und in Abstimmung mit allen beteiligten nicht-polizeilichen Kraften. In der Phase 1  ubernimmt in der Regel der diensthabende Dienstgruppenleiter (DGL) der Leitstelle (Polizeipruhrers. Der Poli asidium) die Funktion des sog. Polizeif zeifagt die Gesamtverantwortung und tri t die grunds uhrer tr¨ atzlichen Entscheidungen. Groschadensereignisse und deren Charakteristiken Weiterhin werden in einer BAO verschiedene Einsatzabschnitte (EA) mit jeweiligen Unterabschnitten (UA) etabliert, f ur die es jeweils wiederum spezielle Einsatzabschnittsleiter bzw. Unterabschnittsleiter gibt. Falls muhrungsstab unverz oglich, sollte im Polizeifuglich ein Fachberater des Rettungsdienstes integriert werden. Weitere Spezialorganisationen Je nachdem welche Merkmale eine Groschadenslage aufweist, kommen zus atzliche Organisationen zum Einsatz. So unterst utzen Einheiten des Katastrophenschutzes (KatSchutz) die Feuerwehr und den Rettungsdienst in Sachen Technik, Betreuung und Versorgung. ¨ Weiterhin existiert zur Uberbrucke zwischen dem Eintre en des uckung der zeitlichen L Katastrophenschutzes und der benutzung der regulafte das otigten Unterstaren Einsatzkr (teils  uberholte) Konzept der Schnellen-Einsatz-Gruppe (SEG). Die SEG ubernimmt dabei afte des Katastrophenschutzes, ist jedoch in der Regel ahnliche Aufgaben wie die Kr schneller alarmiert und somit frugbar. Zus uher am Einsatzort verfatzlich kommen bei Versch atzen der Wasserrettung die uttungen Rettungshundesta eln zum Einsatz und bei Eins Kr afte der Deutschen Lebens-Rettungs-Gesellschaft. Nicht zuletzt sei noch das als Bundesbeh  orde organisierte Technische Hilfswerk (THW) genannt, welches bundesweit bei Bedarf technische Hilfestellung in Groschadenslagen anbietet. Der Groteil der Einsatzkr afte der eben genannten Organisationen setzt sich aus hochmotivierten und freiwilligen Einsatzkr  aften zusammen. Hinweis: In der folgenden Arbeit wird sich bei den Beispielen auf die Feuerwehr und den Rettungsdienst beschr ankt, da diese wesentliche Aufgabenbereiche einer Groschadenslage abdecken und eng in einer solchen zusammenarbeiten. Dies ermur oglicht eine fden BOS-Bereich stellvertretende Betrachtung typischer Problemstellungen und interessanter Beispiele von Standardhandlungsroutinen. 2.2 Groschadensereignisse und deren Charakteristiken Kleinere Einsatzlagen, wie z. B. ein Rettungseinsatz nach einem Verkehrsunfall mit einer oder zwei verletzten Personen, stellen fafte eine gewisse Routine dar. Die ur die Einsatzkr Art und der Umfang einer solchen Schadenslage gehaft, sodass die gebo ort zum Tagesgesch tenen Arbeitsabluberschaubar und die aufe routiniert und fehlerfrei ablaufen. Die Lage ist  eingesetzten Mittel und Kraft zumeist afte sind ausreichend. Auch kommen im Alltagsgesch eingespielte Teams zum Einsatz, die einen hohen Grad an Professionalit at aufweisen. Hingegen werden die Einsatzkroeren Schadensereignis, wie z. B. einem afte in einem gr Massenanfall von Verletzten oder Erkrankten (MANV), mit besonderen Herausforderungen konfrontiert. Ein MANV ist zu Beginn von der Diskrepanz zwischen der Anzahl der verletzten Personen und den zunugung stehenden Einsatzkr achst zur Verfaften und -mitteln gekennzeichnet [PM01]. Da diese Situation vom t aglichen Einsatzgeschehen abweicht, entstehen besondere Koordinationsaufgaben, die nur durch eine organisatorische und taktische Planung sicherzustellen sind [PMU01]. Es gilt, einer groen Anzahl verletzter Personen eine m oglichst schnelle und angemessene Versorgung zukommen zu lassen, und das mit anfangs zu knappen Ressourcen. Weitsichtiges Handeln ist gerade zu Beginn eines der Erfolgskriterien der spateren Lagebewaltigung. Anfonnen sp angliche kleine Fehler kater zu gravierenden Auswirkungen f uhren. In Groschadenslagen sind die Einsatzkr¨ afte mit besonderen Widrigkeiten konfrontiert: Groschadensereignisse und deren Charakteristiken • Der zu Beginn herrschende Informationsmangel erschwert vor allem den F uhrungskr uber das weitere Vorgehen. aften die Entscheidung  • Viele Manahmen m ussen fast zeitgleich eingeleitet und abgearbeitet werden. • Auch kann sich die Einsatzlage jederzeit onnen hinzu- andern, neue Anforderungen k kommen und otzlich obsolet sein. Die Lageentwicklung ist schwer voraussag altere pl¨ bar. • Oftmals erschweren auch interorganisationale Zielkon ikte das Einsatzmanagement. • Die Manahmen sind zumeist nicht umkehrbar und teils ist unklar, ob sie die angestrebten E ekte erzielen werden. • Weiterhin muss die zum Teil ungewohnte Koordination und Kommunikation mit den anderen Organisationen gemeistert werden, und das ggf. bei einer geogra sch verteilten Einsatzlage. • Nicht zuletzt kande der onnen die unterschiedlichen Erfahrungs-und Ausbildungsst Einsatzkraltigung behindern. afte eine reibungslose Einsatzbew In einer Groschadenslage etablieren sich am Einsatzort die bereits angesprochenen besonderen Leitungsstrukturen, die im Wesentlichen die F uhrung und Koordination der Einsatzkr ubernehmen. Die Charakteristiken der Schadenslage bestimmen hierbei afte vor Ort  die beteiligten Hilfsorganisationen und deren Strukturen. Groschadensereignisse werden typischerweise anhand ihres Ausmaes klassi ziert. Ein Beispiel hierfist die MANV ur Stufeneinteilung der Planungsplattform des Deutschen St adtetages. Sie dient als eine grobe Richtlinie und ist im deutschen Katastrophenschutz gelud07] (vgl. Abb. 2.1). au g [L Versorgungs- stufen I II III IV Ausmaß politische Ebene Zuständige Behörde im Tagesgeschäft Bürgermeister, Landräte, OA Bürgermeister, Landräte, OB; ggf. Landesreg. Landesregierung; Bundesreg. administrativ-organisator. Ebene Integrierte Leitstelle, Ärztl. Leiter Verwaltungsstab -behörde; Führungsstab interdisziplinäre Krisenstäbe interdisziplinäre Krisenstäbe operativ- taktische Ebene Notarzt bzw. RA/RS Einsatzleitung vor Ort; LNA & OrgL Einsatzleitung vor Ort; LNA & OrgL Einsatzleitung vor Ort; LNA & OrgL Rettungsdienst MANV 1 MANV 2 MANV 3 MANV 4 Grund- bedarf Spitzen- bedarf Sonder- bedarf <50 Betroffene <=500 Betroffene >500 Betroffene zusätzlich zerstörte Infrastruktur Abbildung 2.1: MANV-Stufen versus Regelbetrieb (aus Sicht des Rettungsdienstes). Es bleibt zu bedenken, dass die konkrete Manahmenplanung in den unterschiedlichen Bundesladten und Kommunen nicht einheitlich umgesetzt wird. So existieren andern, St z. B. in Grost¨ oglichkeiten und t adten andere Versorgungsmagliche Vorhaltungen von Rettungskr andlichen Gegenden, wo schon eine wesentlich geringere aften und -Mitteln als in l Groschadensereignisse und deren Charakteristiken Anzahl von Verletzten die zur Verfaten erschon ugung stehenden Einsatzkapazitopfen k nen. So ist auch obige Stufeneinteilung kein bundesweiter Konsens und kann daher regional husseldorf ochst unterschiedlich ausfallen. Zum Beispiel verwendet die Feuerwehr in D drei MANV-Kategorien, wobei die dritte nicht einmal an obige MANV-1-Stufe heranreicht [SBQ+09]. Je nach MANV-Stufe treten auch unterschiedliche Akteure und F uhrungsebenen in Kraft. Abbildung 2.1 macht dies in Form einer Matrix deutlich (vgl. [FwDV100], S. 21). Die Abbildung stellt die verschiedenen F uhrungsebenen bei Groschadensereignissen dar, und zeigt die unterschiedlichen Verantwortlichkeiten in den jeweiligen Stufen auf. An dieser Stelle sei auf den Unterschied zwischen einer Groschadenslage und einer Katastrophe hingewiesen. Eine Katastrophe wird in [DIN13050] als ein  uber das Groscha ” densereignis hinausgehendes Ereignis mit einer wesentlichen Zerstadigung orung oder Sch der  ortlichen Infrastruktur, das im Rahmen der medizinischen Versorgung mit den Mitteln und Einsatzstrukturen des Rettungsdienstes alleine nicht bewde niert altigt werden kann“ und ist bez uglich der Abbildung 2.1 somit einem MANV-4 zuzuordnen. Die Polizei spricht hierbei jedoch nicht von einem MANV, sondern von Gr oere Gefahren und Schadenslagen, Katastrophen (GGSK), was die MANV-Stufen 1 bis 4 umfasst. F ur die weitere Arbeit soll sich ausschlielich auf die operativ-taktische Ebene konzentriert werden (vgl. Abbildung 2.1). Zus atzlich soll nicht mehr von MANV-Stufen die Rede sein, sondern allgemein der Begriff Groschadenslage f ur eine ganze Klasse von Schadensereignissen verwendet werden. Einsatzdynamik und Einsatzphasen Wie oben herausgestellt, liegt es in der Natur eines Groschadensereignisses, dass dessen Merkmale und dessen Entwicklungen schwer vorhersagbar sind. Dennoch gibt es invariante Charakteristiken, die sich in sog. Abarbeitungs-Phasen widerspiegeln. Wie lange jede einzelne Phase andauert und wie ausgepr agt sie ist, variiert von Schadensfall zu Schadensfall. Vor allem auf Seiten der polizeilichen Gefahrenabwehr hat sich hierfandnis ur das Verst einer groben Drei-Phasen-Einteilung etabliert, die prinzipiell auch auf die Bereiche der nicht-polizeilichen Gefahrenabwehr  ubertragbar sind (vgl. z. B. [BBK10; BBD+05]): 1. Die Initial-Phase, auch Chaos-oder Anlaufphase genannt, bezeichnet die Situation in den ersten Minuten eines Schadensereignisses. Sie ist aufgrund des in dieser Phase noch bestehenden l uckenhaften Lagebildes (selbst auf Seiten der professionellen Einsatzkr afte) von einem unkoordinierten Handeln und einem gewissen augenscheinlichen Durcheinander“ gepr agt. ” 2. In der zweiten Phase, der Konsolidierungs-Phase (auch F uhrungs-oder Abarbeitungsphase genannt), werden alle Einsatzbereiche gem aß der Einsatzplanung und der Faufe gem uhrungslehre strukturiert und deren Ablaß den Standardprozeduren harmonisiert. Hierzu geh ort der Aufbau besonderer Organisationsstrukturen der Einsatzleitung und die Einrichtung funktionsbezogener Einsatzabschnitte mit klarer Festlegung der Verantwortungsbereiche. 3. Die Ruhrungs-Phase, oder auch Demobilisierungs-Phase, bezeichnet den Zeituckf  raum zwischen den abgeschlossenen Arbeiten am Einsatzort und der Wiederherstellung der Einsatzfafte und Technik. Hierzu z ahigkeit aller Krahlen die Patienten uckfafte, die ubergabe in den Kliniken und die Ruhrung aller Einsatzmittel und -kr ¨ Uberpr ufung und Archivierung der Einsatzdokumentation (Patientenregistrierung, Einsatztagebuch) und eine nachgelagerte Einsatznachbesprechung (engl. debrie ng). Einsatzplanung und Einsatzvorbereitung 11 Rettungsdienst, Notarzt, Katastrophenschutz, Ablösung der Einsatz- Feuerwehr, Polizei LNA, OrgL, SEG THW, Spezialkräfte, etc. und Führungskräfte + 15 Min. + 30 Min. + 240 Min. + ab 8 Std. + „führungsfreies“ Intervall Chaosphase Konsolidierungsphase Rückführungsphase Schadensereignis Abbildung 2.2: Reihenfolge des Eintreffens bestimmter Einsatzkr¨ afte und Einsatzphasen. Eine alternative Perspektive auf die Einsatzphasen einer Großschadenslage stellt die Betrachtung der zeitlichen Eintreffreihenfolgealler beteiligten Einsatzkr¨ “ afte dar. In An ” lehnung an Hackstein [Hac06] skizziert die Abbildung 2.2 (von links nach rechts) die typischen zeitlichen Dimensionen und die Reihenfolge der einzurichtenden F¨ uhrungsstrukturen. Ebenfalls zu sehen ist das typischerweise zeitlich verz¨ ogerte Eintreffen nachgelagerter Spezialkr¨andigkeitsbereiche. afte anderer Aufgaben-und Zust¨ Die Abbildung macht weiterhin die Problematik des unterschiedlichen Erfahrungs-und Trainingslevels der Einsatzkr¨afte afte deutlich. So werden die erst-eintreffenden Einsatzkr¨ in der Regel keine besondere Ausbildung bzw. Erfahrung im Management einer Großschadenslage besitzen. Sie m¨ ussen jedoch (kommissarisch) bereits zu Beginn Teile der Einsatzleitung ¨ ubernehmen, wobei die Gefahr, strategische Fehler zu begehen, besonders groß ist. Die entsprechend geschulten Experten, wie z. B. der LNA und der OrgL, werden zumeist nach-alarmiert und treffen daher erst verz¨ur sie stellt sich ogert an der Einsatzstelle ein. F¨ beim Eintreffen die Problematik, das bereits Geschehene und die eingeleiteten Maßnahmen zu erfassen und die Einsatzleitung in ihren Bereichen zu ¨ ubernehmen. 2.3 Einsatzplanung und Einsatzvorbereitung Komplett vorgefertigte Einsatzpl¨ ane, die angeben, wann wer was im Ernstfall zu tun hat, sind aufgrund der Vielfalt, der Unsicherheit und der Dynamik der zu erwartenden Lageentwicklungen unm¨ankt sich daher die Planung auf oglich anzugeben. In der Praxis beschr¨ eine abstrakte Einsatzvorplanung mit einer Bereitstellung grob spezifizierter Handlungsanweisungen und Dokumente, die f¨oglichst breites Spektrum an vorstellbaren Scha ur ein m¨ denslagen anwendbar sind. Im Sprachgebrauch der BOS haben die Begriffe Plan, Planung oder Einsatzplanung ein breites Bedeutungsspektrum. So wird unter Planung haupts¨ achlich eine Menge von vorbereitender Maßnahmen sowie die konkrete kognitive Leistung eines Einsatzleiters verstanden, der in einem Einsatz aufgrund der ihm vorliegenden Fakten das weitere Vorgehen plant. Beide Facetten der Planung werden im Folgenden skizziert. Planung als vorbereitende Maßnahme Als vorbereitende Maßnahme ist es ublich, spezielle aneund Informationshilfen ¨Pl¨“ zu ” erarbeiten, von denen einige wichtige Vertreter im Folgenden vorgestellt werden. Alarmierungspl¨ane: Den (Integrierten) Leitstellen obliegt unter anderem die Aufgabe der Alarmausl¨f¨Rettungsdienst, Feuerwehr, SEG und Katastrophenschutz. osung ur Die hierf¨utzung erstellten Alarmierungspl¨ucke ur zur Unterst¨ane (auch Alarm-und Ausr¨ Ordnungen (AAO) genannt) sind oft sehr einfach gehaltene Listen, auf denen die zu alar Einsatzplanung und Einsatzvorbereitung mierenden Einheiten/Organisationen/Personen plus der jeweiligen Telefonnummer (bzw. der Manger auszulane oglichkeit, einen Alarmempfosen,) aufgelistet sind. Alarmierungspl sind eine der wichtigsten Voraussetzungen, um zu Beginn einer Schadenslage schnellst- motigten Einsatzkraß dem erwarteten Schadensumfang zu alarmie oglich alle benafte gem ren. Darane bei der Nachalarmierung von uber hinaus kommen erweiterte Alarmierungspl Sekundaften zum Einsatz. Diese Listen wurden im Vorfeld auf Ba ar-und Spezialeinsatzkr sis von Erfahrungen der Vergangenheit erstellt. Die Alarmierungspl ane sind entweder auf Papier in sog. Alarmordnern hinterlegt oder aber auch zunehmend in elektronischer Form anglich. So existieren mittlerweile Leitstellensys uber die jeweilige Leitstellensoftware zug¨ teme, die den Disponenten vorher abgelegte Einsatzkategorien zur Auswahl geben und die je nach Schadenskategorie und Einsatzstichwort Standard-Alarmierungspl¨ ane bereitstellen. Einsatzstichworte: Unterschiedliche Notfafte alle erfordern unterschiedliche Einsatzkr und somit Alarmierungspleingeplanten“ Schadenssituation kann anhand ane. Jeder zuvor " von sog. Einsatzstichworten ein entsprechender Alarmierungsplan zugeordnet werden. Einsatzstichworte sind eine M oglichkeit einer abstrakten Beschreibung von Einsatzsituationen. Vorrangig wird dieses Konzept in Integrierten Rettungsleitstellen (IRL) daf ur genutzt, um je nach Informationen des eingehenden Notrufs Russe auf die benafte und uckschlotigten Kr Alarmstufen zu ziehen. Zus atzlich zu den Fakten der Notrufmeldung gehen noch allgemeine Informationen wie z. B. uber die Tageszeit und die Wetterlage mit in die Bewertung  ein. Die Listen von Einsatzstichworten unterscheiden sich von Region zu Region stark. Eine Standardisierung von Einsatzstichworten ist in Deutschland nicht anzutre en und auch nicht angebracht. Vielmehr spiegeln die unterschiedlichen Einsatzklassi kationen die jeweiligen regionalen Besonderheiten und die jeweilige Technik-und Personalsituation der unterschiedlichen Kommunen wider. Rahmenplane fAlle denkbaren Szenarien im Vorfeld zu pla ur spezielle Szenarien: nen, ist ein unrealistisches Unterfangen und wird in der Praxis auch nicht getan. Dies bedeutet jedoch nicht, dass nicht trotzdem versucht wird, grobe Rahmenplur Szenari ane f en auf Basis mahrdender regionaler Besonderheiten (wie Atomkraftwerke, oglicherweise gef ¨ Hochhaige Groveranstaltungen, Flugbetrieb, auser, regelmUberschwemmungsgefahren) zu erarbeiten. Ganz im Gegenteil, die Kommunen sind sogar im Rahmen der Sicherstellung der zivilen Sicherheit unter anderem dazu verp ichtet, Rahmenplur sicherheitskriti ane f sche regionale Anlagen zu erarbeiten und vorzuhalten. Diese Art von Pl anen sind zumeist detailliert ausgearbeitete Dokumente, die neben dem innerbetrieblichen Krisenmanagement auch die Zusammenarbeit mit den  ortlichen BOS zur Gefahrenabwehr und zum Personenschutz betri t. Im Falle einer Schadenslage erhalten die Einsatzkr afte der Feuerwehr durch die Rahmenplane z. B. eine erste Orientierung  uber die zu erwartenden Gefahren, die Anfahrt zum Objekt, wichtige Kontaktpersonen und nicht zuletzt zumeist einen Grundriss des Gebandes. audes bzw. des Gel ¨ Checklisten-Varianten: Vereinzelt kommen zur uh- Uberwachung der korrekten Ausf rung von Prozessen papierbasierte Checklisten (PCLs) zum Einsatz, deren Aufbau und Abarbeitungskonzepte sich aber von Region zur Region und von BOS zu BOS stark unterscheiden sowie kein einheitliches Grundkonzept erkennen lassen (siehe [WKK11]). Vielmehr ist in der Praxis eine Vermischung zwischen Checklisten-Aspekten, Informationsbl attern, Alarmierungspl anen und Kartenmaterialien zu beobachten. Obwohl (elektronische) Checklisten in den Rettungsleitstellen teils verbreitet sind, kommen sie (selbst in Papierform) f ur Handlungsroutinen und IT-Unterst¨ utzung 13 die Einsatzkr¨ afte und Einsatzleitung vor Ort selten zum Einsatz. In Kapitel 4 wird sich der Thematik Checklisten ausf¨ uhrlich gewidmet. Abbildung 2.3: Klassisches Modell des F¨ uhrungsvorgangs (nach [FwDV100]). Planung als kognitiver Prozess im F¨ uhrungsvorgang Die Abbildung 2.3 skizziert das gelehrte klassische Modell dieses F¨ uhrungsvorganges. Ein erfolgreicher F¨amisse der Sicherstellung des Einsatzerfolges uhrungsvorgang ist unter der Pr¨ nur durch ein geordnetes Handeln aller Beteiligten zu erreichen [FwDV100]. Zu Beginn steht die unbekannte Lage, die von den erst-eintreffenden Kr¨ aften erkundet werden muss. Die Planung besteht aus der Beurteilung der Fakten und einem konkreten Handlungsentschluss. Der Entschluss zum Handeln beinhaltet die durchzuf¨ uhrenden Maßnahmen, die hier als ein Plan angesehen werden, der klar, einfach und ausf¨ uhrbar sein soll [FwDV100]. Die in der Praxis ablaufenden komplexen Denk-und Handlungsabl¨onnen mit die aufe, k¨ sem recht vereinfachten Bild allerdings nur schwer vermittelt werden. In der Literatur (vgl. z. B. [PMU01]) wird ein detaillierteres F¨uhrungsvoruhrungsmodell vorgestellt, das den F¨ gang besser widerspiegelt. Abbildung 2.4 (siehe folgende Seite) skizziert diesen erweiterten F¨w¨ uhrungsvorgang (siehe auch FwDV100, S. 24 ff.). Es are jedoch falsch, anzunehmen, dass der in Abbildung 2.4 gezeigte Fuhrungsvorgang ¨¨ ahnlich dem Vorgang eines starren Algorithmus oder eines Workflows in der Praxis exakt befolgt wird. Vielmehr dient das Schema zur Schulung der F¨afte und wird in der Praxis mehr oder weniger fle uhrungskr¨ xibel angewandt. Die dynamische Lage und die Vielzahl der erst zum Schadenszeitpunkt bekannten Randbedingungen sind Gr¨ur, die Einsatzf¨oglich unde daf¨uhrung so flexibel wie m¨ zu gestalten. 2.4 Handlungsroutinen und IT-Unterst¨ utzung ¨ Trotz regelm¨aßiger Ubungen stellt sich f¨uhrungskr¨ ur die F¨afte jede Großschadenslage als ein besonderes Ereignis dar, bei dessen Bew¨atzlich darauf ankommt, die wesent altigung es zus¨ lichen Standardprozeduren je nach (BOS-spezifischem) Training, lokalen Vereinbarungen oder ¨ ubergeordneten Regelwerken, soweit es die Situation erlaubt, korrekt zu befolgen. Die 14 utzung Handlungsroutinen und IT-Unterst LageLagefeststellungErkundung/KontrolleReichtdie Lagefeststellungzur augenblicklichenPlanung aus? Welche Gefahren sind erkannt? Muss zuerst eine Gefahrbeachtet werden? Welcher Einsatzschwerpunkt mussangegangen werden? Welche Möglichkeit der Verletzten- behandlung besteht? Entschluss/Absicht/NachforderungEinsatzbefehl! Lagemeldung/Nachforderung! Sind alle Aufgabenabgearbeitet? Lagemeldung/ NachfordernneinjaUnterstützung? janeinAbschließendeMaßnahmenjaneinEinsatzende Abbildung 2.4: Gelehrter F uhrungsvorgang aus Sicht der Feuerwehr (Quelle: [CP07]). Ausgestaltung der Arbeitsabl aufe im BOS-Bereich unterliegt einer Vielzahl von Regelwerken, Lehrmeinungen, Erfahrungen, Dienstvorschriften und Gesetzen. Die jeweilige Interpretation und Ausgestaltung der Regelwerke obliegt gr otenteils der Eigenverantwortung der BOS und ist den jeweiligen regionalen Besonderheiten angepasst [CG05]. Als Assistenz zur Einsatzzeit sind diese Regelwerke aufgrund ihres Inhalts und ihrer Form nicht geeignet und auch nicht vorgesehen. Ohne entsprechende Standards ist es schwierig, eine gleichbleibend hohe Qualit at der Manahmen sicherzustellen, insbesondere w ahrend langer, komplexer oder ungewohnter Einsatzsituationen. Die Anwendung von Standardhandlungsroutinen (im Folgenden auch Handlungsroutinen und IT-Unterst utzung 15 Standard Operation Procedures, kurz SOPs, genannt) stellt eine M oglichkeit dar, immer wiederkehrende Routineaufgaben motiger Rei oglichst fehlerfrei und unter Vermeidung unn bungsverluste durchzufonnen die Zusammenarbeit zwischen den Einsatzkr uhren. SOPs kaften und den unterschiedlichen Organisationen deutlich befat ordern und somit die Qualit einer gesamten Lagebewohen. SOPs machen umfangreiche Leitlinien operabel altigung erh (vgl. [Ell11]) und m ussen den jeweiligen regionalen und organisationsspezi schen Eigenheiten angepasst werden. Die Standard-Einsatz-Regeln (SER) aus dem deutschen Feuerwehrbereich sind Beispiele ¨ ur SOPs. Sie stellen den Versuch einer Ubertragung der in den USA weit verbreiteten SOPs dar (siehe hierzu die Bemvon und Graeger [CG05]). Sie sollten f uhungen Cimolino1 unter Beteiligung muhrungsebenen erstellt und allen Mitarbeitern bekannt oglichst aller F gemacht werden. Laut Cimolino erm oglicht die schriftliche Fixierung solcher Routinen eine Einsatzvorbereitung und kann somit die Grundlage einer gesamten groben Einsatz-bzw. Trainingsplanung sein. Eine komplette Vorplanung aller nur denkbaren Einsatzszenarien ist jedoch schlichtweg unm oglich. Allerdings sind in der BOS-Praxis niedergeschriebene SOPs (oder auch operationalisierte Einsatzplur die BOS g ane) in der Regel nicht anzutre en. Von den fultigen Standardhandlungsroutinen kann daher nicht die Rede sein. Dies deckt sich mit der Feststellung von Rose et al.: Most communities have very vague emergency plans. Procedures seem " to be locked in the head of experienced sta , but are not traceable by electronic or paper means“ [RPA08]. So weiß z. B. in der Regel jeder erfahrene Feuerwehreinsatzleiter, was er grob in welcher Situation zu tun hat und welches die in seinem Feuerwehr-Ausr uckebereich vereinbarten und akzeptierten Standardprozeduren sind. SOPs spiegeln hierbei eine momentane best-practicedes jeweiligen Arbeitsgebietes wider. SOPs d “ urfen jedoch nicht " als Work owsverstanden werden, sondern eher als eine grobe Arbeitsbeschreibung f “ ur ” spezielle Aufgaben. Nichtsdestotrotz besteht in der Praxis sehr wohl ein groes Interesse, gembest aß der ” practice“ zu handeln und Fehler durch Vergessen weitgehend zu vermeiden. Hierzu wird bis heute jedoch ausschlielich auf Training und den Aufbau von Erfahrung auf Seiten der Einsatzkr afte gesetzt. Neben den professionellen Einsatzkr¨ aften kommen in Groschadenlagen viele freiwillige Einsatzkraften ebenfalls ein hohes Maß an afte zum Einsatz. Obwohl von diesen Einsatzkr Professionalit at abverlangt wird, kann dies in der Praxis schwerlich erreicht werden. Doch vor Fehlern im Ablauf von Handlungsroutinen sind weder die Experten noch die wenig erfahrenen Einsatzkr afte gefeit. Die Art und Weise, wie eine Organisation mit eigenen Fehlern umgeht, ist ihre Fehler ” kultur\. Gemeint ist im weitesten Sinne der Umgang mit Fehlern, die in einer Organisation bei der Arbeit auftreten. Von der Polizei, der Feuerwehr und dem Rettungsdienst wird ein hohes Maß an Professionalito entlichen Raum und at erwartet. Sie agieren zumeist im  stehen daher in besonderem Mae im Fokus der Aufmerksamkeit von Medien und Bev  olkerung. Dies macht den Umgang und das ozielle Eingestehen von Fehlern problematisch; von Fehlern“ wird auerst ungern gesprochen. In der Human-Factors uberhaupt nur  ” Forschung, die sich unter anderem mit dem bewussten Umgang mit menschlichen Fehlern beschvon High aftigt, wird daher statt von Organisationen mit einer Fehlerkultur auch Reliability Organization (HRO) gesprochen [HPK+12]. Gemeint ist die Widerstandsf ahigkeit der Arbeitsabluber menschlichen Fehlern und aueren aufe einer Organisation gegen Ein  ussen. 1 Der Autor hat einige Brosch uren zum Thema Standard-Einsatz-Regeln verfasst und stellt unter www. standardeinsatzregel.org (abgerufen am 20.12.2013) weitere Informationen zum Thema bereit. 16 utzung Handlungsroutinen und IT-Unterst IT-Unterstur SOPs utzung f Im BOS-Bereich ndet sich eine umfassende IT-Unterst utzung auf Seiten der Rettungsleitstellen sowie der Krisenstandern. So ist in heutigen modernen abe von Kommunen und L Rettungsleitstellen der Computereinsatz nicht mehr wegzudenken. Leitstellendisponenten nutzen professionelle Softwarel osungen, um z. B. eine automatische Alarmierung durchzuf atze und die dazu zugewiesenen Einsatzfahrzeuge zu disponieren uhren, alle Notfalleins oder ein digitales Einsatztagebuch zu fuhren – um nur einige Beispiele zu nennen. Auf Seiten der Krisenst abe kommen teils bundeslandspezi sche Informationsplattformen zum Einsatz, die speziell auf den Informations-und den Nachrichtenverteilungsbedarf der Krisenstutzte Befehlsstellensoft abe zugeschnitten sind. So z. B. in Hessen die browsergest ware ILIAS-HE, welche zur Unterst utzung der Stabsarbeit bei der Polizei, der Feuerwehr und dem Katastrophenschutz/Landeskrisenstab dient. ILIAS-HE wird in der hessischen Polizei landesweit seit 2004 eingesetzt [Hei09]. Bei der Bayerischen Polizei und im Th uringer Landeskrisenzentrum ist hingegen das webbasierte Einsatz-Protokoll-System (EPSweb)  achendeckend im Einsatz. Weitere Beispiele sind das Stabsorganisationssystems Stabos in Nordreinwestfalen (vgl. [NKW08]) und das deutsche Notfallvorsorge-Informationssystems (deNIS II, siehe www.denis.bund.de (abgerufen am 20.12.2013)). Die obere Aufzuhren. Eine IT-Unterst ahlung liee sich noch weiterfutzung im operativen Bereich vor Ort hat sich bis heute nicht etablieren k onnen. Vereinzelt nden sich jedoch Insellager entstan osungen, die oft in Eigeninitiative einzelner engagierter Entscheidungstr den sind. Diese IT-L osungen sind auf die speziellen Belange eines bestimmten Einsatzbereiches und der jeweiligen BOS-Organisation zugeschnitten. So kommt z. B. in der mobilen Einsatzleitung des Rettungsdienstes (DRK) Lemgo (Kreis Lippe, Nordrhein-Westfalen) eine IT-Unterst utzung zum Einsatz, die eine Verwaltung aller Einsatzfahrzeuge und aller Verletzten erm oglicht. Der Abtransport der Verletzten kann somit besser organisiert und dokumentiert werden. Ein weiteres Beispiel stellt die im SpeedUp-Projekt prototypisch umgesetzte Kommunikationsplattform dar, welche die Fafte z. B. bei der Kommunikation und der uhrungskr Telemetrie der Patientendaten vor utzt. Nach Wissen des Au- Ort entscheidend unterst tors wird der Computereinsatz, im Sinne einer Assistenz zur Vermeidung von Fehlern bei SOPs, von keinem der heutigen Praxissysteme adressiert. Es zeichnet sich jedoch ab, dass sich mit einem zunehmenden Einsatz von IT auch am Einsatzort den Rettungskr aften die Mutzte Hilfestellung oglichkeit erschliet, kritische Arbeitsschritte durch eine computergest zu kontrollieren. Die vorliegende Arbeit widmet sich im Folgenden der Fragestellung, wie sich eine geeignete Unterst utzung von Handlungsroutinen im schwierigen Umfeld der BOS realisieren lachsten Kapitel verwandte Forschungsans asst. Zuvor werden jedoch im natze betrachtet, welche sich unter anderem mit dem Einsatz des Computers im Umfeld der Prozesse eines Krisenmanagements besch aftigen. Thematik IT-Unterstützung im Prozessmanagement von Krisenszenarien Automatische Handlungsplanung Forschungsbereich der Künstlichen Intelligenz Business Process Management Techniken und Tools im Bereich Modellierung, Automatisierung und Optimierung von Prozessen Thematik IT-Unterstützung im Prozessmanagement von Krisenszenarien Automatische Handlungsplanung Forschungsbereich der Künstlichen Intelligenz Business Process Management Techniken und Tools im Bereich Modellierung, Automatisierung und Optimierung von Prozessen Kapitel 3 Stand der Forschung zur IT-Unterst¨ur SOPs utzung f¨ ¨ Dieses Kapitel gibt einen Uberblick uber bisherige Forschungsarbeiten zum Thema IT ¨ Unterst¨ur (Standard-)Prozesse im BOS-Bereich bzw. in vergleichbaren (interna utzung f¨ tionalen) Einsatzbereichen. 3.1 Forschungsperspektiven zur SOP-Unterst¨ utzung Nicht zuletzt motiviert durch die Erfahrungen des 11. Septembers und einer Zunahme an Risiken f¨uckeninletzter Zeit ur Mensch und Infrastruktur durch Naturkatastrophen, r¨ vermehrt die Bereiche zivile Sicherheit“ und Krisenmanagement“ in den Fokus des For ”” schungsinteresses. Als Beispiel sei hierf¨Sicherheitsforschung ur die Auflage des Programms ” – Forschung f¨“ ur die zivile Sicherheitder deutschen Bundesregierung genannt, in dessen Rahmen sich Projekte auch mit der Frage einer geeigneten Bereitstellung von IT-Assistenz im Bereich Schutz und Rettung von Menschenbesch¨ “ aftigten. Mit dem Ziel, Forschung ” und Praxis zu vernetzen, hat sich international die seit 2003 j¨ ahrlich organisierte International Conference on Information Systems for Crisis Response and Management (ISCRAM) etabliert – auf der bereits zwei Vorarbeiten zu dieser Arbeit (siehe [WYM+11; KWB12]) vorgestellt wurden. W¨ ahrend sich viele Projekte mit der Bereitstellung einer allgemeinen und allumfassenden Kommunikationsplattform – sog. Emergency Management Information System“ ” (EMIS) –, einer Triage-Unterst¨Sichtung“) oder einer Visualisierung durch utzung (triage ” Kartendarstellungen befassten, wurden konkrete Fragen nach einer IT-Assistenz bez¨ uglich einer Sicherstellung reibungsfreier Prozesse nur in einigen wenigen Forschungsprojekten adressiert (siehe z. B. die Projekte MobisPro und I-LOV, weiter unten). Motivation: Prozess-Modellierung,Motivation: Berechnung von Plänen -Analyse, -Optimierung, -Überwachung (anhand eines Welt-Modells und Zielen) Abbildung 3.1: Zwei Ans¨ur manuelle vs. automatische Handlungsplanung. atze: IT-Assistenz f¨ 17 Business Process und Work ow Management Die Latze dieser Projekte lassen sich zwei (gr osungsansotenteils) disjunkten Forschungsrichtungen zuordnen (vgl. Abb. 3.1). Beide Ansatze  ahneln sich in ihren Zielen, unterscheiden sich jedoch vor allem in ihren speziellen Problemrosungsans aumen und Latzen. Die Rede ist von Arbeiten aus dem Themenumfeld des (Business) Process Managements (BPM) und den Arbeiten, die sich der SOP-Unterst utzung aus Richtung der automatischen Handlungsplanung nunstlichen-Intelligenz ahern. Letztere ist ein Teilgebiet der K Forschung. W ahrend sich die eine Seite mit der Anwendung von Techniken und Softwaretools des BPM beschunstlichen Intelligenz (KI) in der An aftigt, liegt der Ansatz der K wendung eines konkreten Planungsparadigmas f ur Probleme der Einsatzplanung. Ziel der KI-Handlungsplanung ist es, anhand einer geeigneten Modellierung der Dom ane und entsprechend expliziten Zielvorgaben einen (L osungs-)Plan zur Reaktion auf ein beliebiges Krisenszenario zu berechnen. Im Folgenden werden Arbeiten beider Herangehensweisen projekt-bzw. forschungsgruppenorientiert betrachtet, wobei die Begri e Krisenszenario und Krisenmanagement foeren Ausmaes bzw. deren Abarbeitungsma ur eine Vielzahl von Schadensereignissen gr nagement stehen. 3.2 Business Process und Work ow Management ¨ In diesem Abschnitt werden Forschungsarbeiten vorgestellt, die sich mit der Idee der Ubertragung von Techniken aus dem Business Process Management auf das Krisenmanagement befassen. Unter dem Begriff Process soll an dieser Stelle im weitesten Sinne ein Hergang, Fortgang bzw. Ablauf eines Vorganges verstanden werden. Im Kontext betrieblich- organisatorischer Ablvon aftsprozessen aufe wird in diesem Zusammenhang auch Gesch (Business Processes) gesprochen [Kla01]. Eine Vielzahl von Forschungsans atzen geht davon aus, dass sich die ablaufenden Prozesse einer Groschadenslage mittels BPM-Techniken/-Tools erfassen und modellieren lassen (siehe z. B.: Bur05]; Rose et al. [RPA08]; Peinel et al. [PR09]; Lindemann et urmann [B al. [LPK09]; Soboll et al. [SBQ+09]). Die Prozessmodelle dienen in einem ersten Schritt der Erfassung (Niederschrift) von Prozessen. Auf Basis des Prozessmodells k onnen Fehler im Ablauf erkannt und die Prozesse optimiert werden. Hierf ur kommen verschiedene Modellierungstechniken und -sprachen wie z. B. Ereignisgesteuerte-Prozessketten (EPKs) (vgl. Scheer [KNS92]) oder Petri-Netze [Pet62], BPML, BPMN, XPDL sowie UML zum ¨ Einsatz (fur einen umfassenden Uberblick siehe Bartonitz [Bar05]). In einem weiterf uhrenden zweiten Schritt werden die formalen Prozessmodelle genutzt, um deren praktische Ausfuhrung mit Hilfe des Computers zu  uberwachen und teils zu steuern. Diese Aufgabe uhrungssysteme (sog. Work ow-Management-Systeme ubernehmen spezielle Prozessausf (WfMS), siehe [Jab95]). Im Folgenden soll ein reprat asentativer Teil dieser Forschungsans ze vorgestellt werden, der die Charakteristiken dieser Latze gut widerspiegelt. osungsans Im Rahmen des europ aischen Verbundprojektes ERMA (Electronic Risk Management Architecture; '06 bis '08) wurden Prozessmodellierungsansur die Einsatzplanung und atze f Simulation von Groschadensereignissen erarbeitet. Hierzu motivieren Peinel & Rose in [RPA08; PR09] die Notwendigkeit einer formalen Modellierung der geplanten Vorgehensweisen als computerintegrierte Prozesse. Aus Sicht der Autoren ist diese Art von Modellierung zuerst einmal hilfreich feine Bewertung der Prozesse selbst, und weniger ur fatere automatische Ausfuhrungsda die uber ur eine spuhrung bzw. Ausfuberwachung,  ” wiegende Anzahl der Manahmen auerhalb von IT-Systemen ausgef uhrt werden“ [PR09]. Hierbei widmeten sich Peinel et al. unter anderem auch der Fragestellung, wie bereits vor Business Process und Work ow Management handene umfangreiche Regelwerke und Vorgehensbeschreibungen konkret am Beispiel des ¨ Einsatzkonzeptes der Rheinischen Projektgruppe MANV Uberortlich ( UMANV)“ (siehe " [Sch07]) mittels SOPs operationalisiert werden k onnen. Peinel et al. diskutieren in diesem Zusammenhang auch die M oglichkeit einer Wiederverwertung von sich in der Praxis bew unftiger Groschadenslagen. Weiterhin ahrten Prozessbausteinen beim Management zuk schlagen die Autoren ein allgemeines Metamodell vor, welches die Unterteilung der Prozesse in folgende Bestandteile (Sichten) vorsieht: Strategy view (strategische Einsatzziele), Concept view (wesentliche Manahmen in zeitlichem und sachlogischem Zusammenhang), Flow view (detaillierte Ablaufspezi kation), Organizations view (Einsatzorganisation, Rollen und Quali kationen), Objectives view (strategische und taktische Einsatzziele), und die Requisites view (Anforderungen). Begonnen bei den strategischen Einsatzzielen folgt der Modellierungsprozess den jeweiligen Sichten des Metamodells. Die Sichten sollen als Hilfestellung f ur die gesamte Prozessmodellierung dienen. Konkret wurde unter Nutzung eines EPK-zentrierten Modellierungswerkzeuges ein Pro¨ zessmodell des UMANV entwickelt, das eine erste Analyse der Vorgehensweisen erm oglichte ¨ (vgl. auch [Ars08]). Das erstellte Modell soll einen Uberblick  uber alle Prozesse geben und somit bereits bei der Diskussion der Einsatzvorbereitung dienlich sein. Peinel et al. res umieren jedoch in [PR09], dass sich bis heute in der BOS-Praxis keine formale Prozessmodellierung etablieren konnte, und vertreten j ungst in [PRW12a] den Standpunkt, that business process management methods and tools cannot be directly ap " plied to the emergency management domain\. Als Grund hierf ur sehen sie den Fakt, dass die Dom anenexperten aus den BOS (wie z. B. Feuerwehren oder Rettungsdienste) nicht auch zugleich Experten auf dem Gebiet der Prozessmodellierung sind, aber nur sie  uber das benugen, um die Prozesse der Praxis entsprechend mo otigte fachliche Know-how verf dellieren zu k onnen. Peinel et al. vertreten daraufhin die Meinung, dass heutige Techniken und Tools des BPM zur Planung von Katastrophenschutzpl anen ungeeignet sind, vor allem dann, wenn man eine selbst andige Prozesserfassung durch die BOS-Experten im Sinn hat [PRW12a]. J ungst gri en Peinel et al. in [PRW12b] den Ansatz der Checklisten-Perspektive von Wucholt & Kr uger [WKK11] auf, und erweiterten das von Wollert & Mannabeth [WM11] vorgeschlagene Plan-Autoring-Tool f ur Katastrophenschutzmanagement um die Perspektive der Modellierung von Checklisten statt um die zuvor angestrebten Einsatzpl ane. Hierzu beranenspezi sche Merkmale und geben in ihrem ucksichtigen die Autoren dom Checklisten-Meta-Modell, dass in Form eines Entity-Relationship-Diagramms gegeben ist, Konzepte wie: Item, Category, Event, Organisations, Persons, Resources und Measure an. Zum Beispiel steht Measure f ur eine bestimmte Aufgabe, die durch einen Satz beschreibender Merkmale gegeben sein soll. Der zentrale Editor soll es den Einsatzkroglichen, aften erm neben den Items einer Checkliste weitere detaillierte Angaben  uber das Ziel, die Zeitdauer, den Ort oder die genutzten Ressourcen anzugeben. Peinel et al. wollen somit das Erstellen sog. smarter Checklistenerm “ oglichen, die die Organisation im Gegensatz zu papierba ” sierten Checklisten erleichtert. Der smart\-Faktor soll dabei auf zwei Konzepten beruhen. " Zum einen soll das System – wie in [WKK11] motiviert – das Vokabular dem Sprachgebrauch der jeweiligen Organisation des Benutzers anpassen k onnen, und zweitens sollen Ressourcen-Kon ikte zwischen der Zuordnung zweier Checklisten erkannt werden. Wie und auf welcher Basis dies erm oglicht werden soll, bleibt leider unklar. Auch die Art der Ressourcen-Kon ikte und das Konzept der Zielmerkmale bleibt noch vage beschrieben. Auer der Angabe eines Entity-Relationship-Diagramms f ur das Checklisten-Konzept wird jedoch keine genaue Systembeschreibung bzw. keine Architektur des Gesamtsystems angegeben. Zudem erscheint der Anspruch der Modellierung von Ressourcen aufgrund der Business Process und Work ow Management Komplexit at und Dynamik realer Groschadensereignisse unrealistisch. Nichtsdestotrotz stellt der so entstandene Prototyp einen vielversprechenden Ansatz eines Autoring-Tools dar, mit dessen Hilfe Einsatzkronnen. afte ihre eigenen Checklisten erstellen und editieren k F ur einen Einsatz direkt zur Einsatzzeit sind dieser Prototyp und das vorgestellte Konzept nach Meinung der Autoren jedoch (noch) nicht geeignet. Nicht zuletzt entstanden im Rahmen des Sicherheitsforschungsprogramms der Bundesregierung, im Bereich Computeranwendung und Integration in Konstruktion und Planung“ " der Universit at Paderborn, Arbeiten zum Thema Prozessmodellierung im BOS-Bereich. Die Arbeiten pro tierten dort besonders von einer guten Zusammenarbeit mit Berufsfeuerwehren (wie z. B. der Feuerwehr Dosungsans usseldorf), wodurch viele Latze direkt bei den Anwendern in der Praxis evaluiert werden konnten. So z. B. das Forschungsprojekt SHARE (siehe [KPC06]), dessen allgemeines Ziel es war, durch Bereitstellung einer digitalen Kommunikationsplattform die Ezienz und E ektivitatzen zu at von Feuerwehreins verbessern. Als ein weiteres Forschungsprojekt verfolgte Mobis-Pro ('08 bis '12) eine Optimierung der gesamten Prozesskette vom vorbeugenden zum abwehrenden Brandschutz. Lindemann et al. [LPK09] untersuchten hierbei ebenfalls Einsatzm oglichkeiten von EPKs. Die Autoren stellten jedoch fest (siehe [LPK09]), dass es wegen der theoretisch unendlichen Anzahl " von Kombinationen und Variationen einzelner Ereignisse unrealistisch“ ist, alle denkbaren Informationen oglichen Prozesse den Einsatzkr uber die maften mit an die Hand zu geben bzw. sie im Vorfeld weitgehend vollst andig zu erfassen. Weiterhin schlugen Becker et al. [BLK11] ein im Rahmen des I-LOV\-Projektes ('08 " bis '11) konzipiertes SOP-gestur den Einsatz in der Einsatz utztes Informationssystem f f uhrung des Technischen Hilfswerks (THW) vor. Ziel war es, SOPs der Arbeitsprozesse am Beispiel Ortung und Bergung von Versch\ uttetenzu entwickeln und somit den gesamten " Einsatzablauf abzubilden. Die Autoren erkannten jedoch, dass reale Eins atze eine gewisse Flexibilitotigen, und schlugen daher den Einsatz sogenannter at in ihren SOPs beninter ” aktiver SOPs“ vor. Ziel war es, die Vorteile von Checklisten, Flussdiagrammen und die herk ommliche, textbasierte Darstellung der SOP zu vereinen. Im Kern wird in [BLK11] ein es uger ahnliches System skizziert, wie bereits in Kr et al. [KGK+10] motiviert wurde. Der Ansatz von Becker et al. [BLK11]  ahnelt jedoch eher einem Versuch, eine Art THW-spezi sches Expertensystem (vgl. [Jac98]) aufzubauen. ¨ Uber Ja-/Nein-Fragen soll der Nutzer im Einsatz durch die komplexe SOP-Struktur eines kompletten THW-Einsatzes gef uhrt werden. Das Konzept der interaktiven SOPs war zus¨ atzlich Bestandteil in der Entwicklung des SOP-gest utzten Informationssystems SOPHIE (Standard Operation Procedures Hierarchical Information Exchanger), das den Einsatzkr aften neben den interaktiven SOPs noch eine Karten-und Kommunikationkomponente bereitstellen soll. Ver o entlichungen zu diesem Thema sind jedoch bis heute nicht zu nden. Auch ist das von Becker et al. beschriebene Informationssystem recht vage beschrieben. So wird z. B. auf die Frage, wie auf sich  andern- de Situationen in den dynamischen SOPs reagiert wird, nur andeutungsweise eingegangen. Ebenso bleibt o en, wie und auf Basis welcher Konzepte eine automatische Zusammenstellung der dynamischen SOP konkret erfolgt. Allen oben genannten Ans atzen ist die prinzipielle Schwierigkeit der Prozess-Modellierung gemein. Wenn bereits die Modellierung der im Krisenmanagement angewandten Work ows problematisch ist, so verwundert es nicht, dass bis heute (nach Wissen des Autors) im BOS-Bereich auch keine WfMS praktische Anwendung nden. Die Diskussion ur uber ein F Ans21 atze der automatische Handlungsplanung und Wider von WfMS im Krisenmanagement wird bereits seit Jahren gef uhrt, zumeist motiviert von Verfechtern einer bestimmten Modellierungmethode/-Sprachen (z. B. EPKs, BPEL oder BPMN) bzw. von Herstellern der WfMS selbst. Aktuell wird der Einsatz sog. adaptiver WfMS diskutiert (siehe z. B. [RW07; HBS13]), welche den Anforderungen einer Groschadenslage durch dynamische Anpassung an neue Gegebenheiten gerecht(er) werden sollen. Diese Systeme sollen eine ausreichende Flexibilit  at durch alternative und parallele Work ow-Instanzen bereitstellen. Ein konkretes Beispiel hierf ur ist die von Hofmann et al. vorgeschlagene Architektur eines Disaster Response Work ow Management Systems (DRWfMS) [HBS13]. Die Autoren schlagen ein System vor, dass je nach vorliegender Situation initial einen Satz von noch unspezi zierten Prozessbeschreibungen aus einem vorkon gurierten Repository ausw ahlt. Die richtige Auswahl soll anhand der vorliegenden Fakten und einer geeigneten Beschreibung der Prozesse erfolgen. Zus atzlich soll ein Abgleich mit ebenfalls zuvor hinterlegten Einsatzregeln sicherstellen, dass nur die zu einer bestimmten Einsatzlage passenden Prozesse ausgew ahlt werden. Die Autoren schlagen hierzu ein disaster rule repository (DRR) vor, in dem, neben den Regeln der Anwendbarkeit von Prozessfragmenten, auch die Relationen zwischen verschiedenen Einsatztypen und die Abh angigkeiten der Prozesse untereinander abgelegt sind. Als Kernkomponente des Architekturvorschlages analysiert ein sog. disaster process analyser die Informationslage, selektiert die notwendigen Prozesse aus dem DRR und f ugt die Prozesse zu einem gesamten Plan“ zusammen – die Autoren sprechen hierbei von process tailoring. ” Schlussendlich sollen Instanzen der zuvor ausgew ahlten Prozesse durch ein adaptives WfMS ausgefuberwacht werden. Neben Hofmann et al. besch uhrt und aftigten sich auch Peinel et al. mit der Fragestellung einer geeigneten Ausfuberwachung von Prozessen im uhrungs Krisenmanagement [PRW12b]. Alles in allem steht der Ansatz von Hofmann et al. als ein Beispiel daf ur, dass auf Seiten der BPM-Forschung erkannt wurde, dass Prozesse in einem Krisenszenario keine starren, unver anderlichen Prozesse sind. Hofmann et al. lassen jedoch in ihrem Vorschlag eine Vielzahl von Fragen o en. So bleibt z. B. o en, wie ein DRR genau aufgebaut werden kann und wie es strukturiert ist, wie die Prozess-Templates gewonnen werden und wie vor allem das Verbinden der Fragmente zu einem Gesamtwork ow erfolgt. G anzlich unausgesprochen bleibt die Frage, wie sich solch ein System in die Arbeitskultur der an einer Groschadenlage beteiligten Organisationen einbinden luhrung des asst und wie die automatische Prozessausf WfMS mit den physischen Handlungen der Einsatzkr afte abgeglichen werden kann. 3.3 Ansatze der automatische Handlungsplanung Aus dem Umfeld der automatischen Handlungsplanung nden sich eine Reihe von Arbeiten zur Planungsassistenz in Groschadenslagen und im Krisenmanagement verschiedenster Art (Bekanden [ACF+05b], Katastrophenschutzplanung [BS01], mi ampfung von Waldbr lit arische Einsatzplanung [WD92; TDB+04; GHA+05]). Allen Arbeiten ist gemein, dass sie das Paradigma der Hierarchischen-Task-Netzwerk-Planung (HTN-Planung) (vgl. Sacerdoti [Sac73], Tate [Tat76] und Ghallab et al. [GNT04]) anwenden, in dem das Konzept der HTN-Methoden als M oglichkeit der Abstraktion von SOPs verstanden wird. Daneben gibt es mit der Modelreduktion [Ten88] und der Operator-Dekomposition [YM94; YP+94] weitere KI-Planungsans atze, die sich die hierarchische Abstraktion zu Nutze machen [Fox97]. Die HTN-Planung ist hiervon die in der Praxis am erfolgreichsten eingesetzte automatische Planungsmethode [EHN94a; GNT04]. Sie unterscheidet sich jedoch grundlegend von der sog. STRIPS-style-Planung in dem fwas und dem wie geplant wird ur [EHN94b]: HTN planners search for plans that accomplish task networks, which can in " 22 Ans atze der automatische Handlungsplanung clude things other than just attainment goals“ [Ero96]. Mit anderen Worten, das Ziel der HTN-Planung liegt nicht darin, einen Weg zur Erreichung einer Menge von Zielmerkmalen zu nden, sondern darin, eine (vorde nierte) Menge von Arbeitsschritten (Tasks) auszuf  uhren (zu performen) [GNT04]. Im Folgenden sollen einige wichtige Arbeiten dieses Ansatzes vorgestellt werden. Dabei wird davon ausgegangen, dass der Leser mit den Grundlagen der HTN-Planung vertraut ¨ ist. (Das Kapitel 11 in [GNT04] gibt einen umfassenden Uberblick zum Thema.) HICAP – ur milit HTN-Planung farischer Evakuierung-SOPs Das System HICAP (Hierarchical Interactive Case-based Architecture for Planning) soll stellvertretend fuhrt werden, die in den 1990er Jahren ur eine Reihe von Arbeiten aufgef den Einsatz von sog. case-based Planern im Kontext komplexer SOPs f ur Krisenszenarien untersuchten (vgl. hierzu z. B. auch Mitchell [Mit97]; Gervasio et al. [GIL98]). Munoz-Avila et al. stellen in [MAB+99] das HICAP System als eine Kombination zwischen einer case-based Planung und einer sog. doctrine-guided task decomposition vor. Es soll der Erstellung sog. milit arischer Noncombatant Evacuation Operations (NEOs) dienen. Die Rede ist von der komplexen Aufgabe der Evakuierung einer gef ahrdeten Region unter der Proglich unbeschadet aus einer Gefahrensitua amisse, so viele Zivilisten wie m tion zu verbringen. Wie Munoz-Avila et al. darlegen, gilt es hierbei, eine Vielzahl von Regelungen, Vorgaben, SOPs, Ressourcen und Abh angigkeiten zwischen den SOPs zu beachten. Wie die Vergangenheit zeigte, sind die Pl ane zu NEOs oft fehlerbehaftet, sodass ¨ sie des Ofteren zu einem vermeidbaren Verlust an Menschenleben gef uhrt haben. Ziel von HICAP war es daher, den Verantwortlichen eine Assistenz an die Hand zu geben, die es ihnen ermane zu operationalisieren, d. h. den abstrakten und pri oglicht, grobe taktische Pl mitiven Tasks konkrete Ressourcen zuzuweisen. Strategische Belange, die meist politische und  ubergeordnete Zielstellungen verfolgen, wurden in HICAP ausgeklammert. Neben der klassischen Einteilung in primitive und nicht-primitive Tasks wurden zus atzlich die nicht-primitiven Tasks in eindeutig-reduzierbar“ (uniquely decomposable) und " mehrdeutig-reduzierbar“ (decomposable by multiple methos) unterschieden. W ahrend die " primitiven Tasks – wie in der klassischen HTN-Planung auch – konkreten Aktionen entsprechen, stehen die eindeutig-reduzierbaren nicht-primitiven Tasks f ur die Art von Tasks, f ur die es genau eine entsprechende (durch Lehrmeinung, Gesetz oder Regel) Sub-Task- Reduzierung gibt. In diesem Fall enthalten die Methoden keine Vorbedingung, d. h. die Methode wird unabhaß einer zu erf angig von der Situation, gemullenden Vorschrift, angewandt. Fosung mehrdeutig-reduzierbarer Tasks existieren hingegen mehrere Metho ur die L den mit entsprechenden Vorbedingungen. Munoz-Avila et al. sprechen hierbei von einem spezi schen Probleml ose-Kontext, der als ein Case-based Planungsproblem aufgefasst wird. Methoden fasentieren Cases, deren Anwendungsbedingung ur problemspezi sche Tasks repr aus einer Menge von Frage-Antwort-Paaren besteht. Die Cases selbst sind auf Basis von SOPs oder aus fr uheren erfolgreich angewandten (Teil-)Tasknetzwerken erarbeitet worden. Abbildung 3.2 zeigt eine HICAP Nutzerschnittstelle, in der auf der linken Seite eine hierarchische Tasks-Liste einer konkreten NEO-Mission zu sehen ist. Die rechte Seite stellt die Organisationsstruktur der Evakuierungsteams dar. In HICAP wurden eine HTN-Wissensbasis (bestehend aus kritischen Tasks) aufgebaut, indem eine Menge von Dienstvorschriften, Handb uchern und SOPs analysiert wurden. Detaillierte Beispiele nden sich hierf ur jedoch nicht (mehr). HICAP konzentrierte sich vorwiegend auf eine Ressourcen-Zuweisung, sodass das HTN-Planungssystem hauptsur achlich f Probleme eingesetzt wurde, die eher dem Bereich Scheduling als dem der Planung zuzu Ans23 atze der automatische Handlungsplanung Abbildung 3.2: Anzeige der Task-Hierarchien im HICAP-Benutzerinterface. (Quelle: [MAB+99]) ordnen sind. In der Literatur wird Scheduling oft als ein Spezialfall der Handlungsplanung angesehen, der der eigentlichen Planung nachgelagert ist (vgl. [GNT04], Kap. 15). CoSAR-TS – Coalition Search and Rescue Task Support Das von Tate et al. [TDD96] entwickelte HTN-Planungssystem O-Plan soll menschliche Agenten in verschiedensten Arbeitsgebieten bei der Abarbeitung ihrer Tasks (Issues) unterstoglichkeiten der Anwendung von O-Plan und dessen Erweiterungen utzen. Die M (siehe z. B. das I-X -System [Tat00]) wurden in den letzten 10 Jahren auch f ur die Dom  ane des Krisenmanagements untersucht. So auch im Coalition Search and Rescue Task Support (CoSAR-TS; '03 bis '06) Projekt1 . Im CoSAR-TS-Projekt wurde unter anderem die Arbeitsweise von intelligenten Softwareagenten im Zusammenhang mit einem KI- Planungssystem und dem Einsatz von Policies (im Sinne von Strategien, Taktiken oder Politiken) untersucht. Ziel des Projektes war die Integration des KI-Planers I-X/I-Plan mit den KAoS Policies in einer Search & Rescue (SAR) Service-Dom ane. Bei KAoS Policies handelt es sich um ein spezielles Framework fanen und Policy Services (siehe ur Dom [UBJ+03; UBJ+04]). Policies sind in CoSAR-TS in wohlde nierten, deklarativen Beschreibungen hinterlegt und regeln die Zugri sm oglichkeiten von (elektronischen) Services verschiedenster Art. Es liegt in der Natur von SAR-Operationen, dass eine sich rasch ver andernde Umgebung eine gleichfalls schnelle Anpassung der zur Ausf uhrung geplanten policy-constrained Services erfordert. Die Planungskomponente in CoSAR-TS soll dies durch eine Semantic Web Services work ow composition [TDB+04] unterst utzen, bei der die Policies mit ber ucksichtigt werden. 1 siehe http://www.aiai.ed.ac.uk/project/cosar-ts/ (abgerufen am 20.12.2013) 24 Ans atze der automatische Handlungsplanung Dem Benutzer stehen uber ein sog. Process Panel Funktionalit aten eines KI-Planers bereit. Mit ihm kullung eines festgelegten onnen kontextsensitive Operationsfolgen zur Erf Zieles mit Blick auf die Performance und die einzuhaltenden Constraints geplant werden. Alle Services sind mit der Service-Modellierungs-Sprache OWL-S (vgl. [OWL-S]) beschrieben und mittels eines Konverters in eine geeignete Reprur den KI-Planer asentationsform f umgewandelt. Abbildung 3.3: Einzelne Komponenten des CoSAR-TS GUI. (Quelle: [TDB+04]) In Abbildung 3.3 sind die Interface-Komponenten des CoSAR-TS Projektes zu sehen. So erlaubt ein Domain Editor das Erstellen, Verwalten und Bekanntmachen von HTN- Methoden, unter denen typische Vorgehensweisen zur Losung komplexer und einfacher ¨ Problemstellungen verstanden werden. Uber das Process Panel konnen die anfallenden Aufgaben je nach ihrer Priorituhrenden Einheiten verteilt/ihnen zugewiesen at an die ausf ¨ werden. Gleichzeitig bietet das Process Panel einen Uberblick uber die aktuell laufenden  Manahmen und zeigt die noch anstehenden unbearbeiteten Tasks an. Die Autoren sprechen in diesem Zusammenhang auch von der Bereitstellung von distributed and intelligent " to-do lists“ [WTP06]. Das Map Tool bietet eine geogra sche Lage ubersicht aller sich im Einsatz be ndlichen Einheiten. Obwohl zu diesem Projekt einige Veranglich sind, bleiben viele De o entlichungen zug tails der Umsetzung unklar bzw. vage beschrieben. Auch ist auer einer Demonstration per Video keine frei verfug ugbare Applikation zum Test oder gar zur Weiterentwicklung verf bar. Es bleibt zu vermuten, dass dies dem milit arischen Anstrich des Projektes geschuldet ist. Auf den Webseiten des AIAI (Arti cial Intelligence Applications Institute School of Informatics, University of Edinburgh) lassen sich jedoch Folgeprojekte nden. So greifen z. B. Wickler und Potter den Ansatz der HTN-Planung in [WP10] erneut auf und schlagen ein Wiki-basiertes System zur kollaborativen Entwicklung und Anwendungsassistenz von SOPs vor. Durch das erweiterte Wiki-System sollen die Dom anenexperten auf einfache Art und Weise die formale Methodende nition fonnen. Jede ein ur das I-X -System erstellen k zelne Wiki-Seite soll einer Task entsprechen und jede Wiki-Unterseite soll einer Sub-Task entsprechen. Ans25 atze der automatische Handlungsplanung SIADEX – HTN-Planung in der Waldbrandbekampfung  Im Projekt SIADEX (Assisted Design of Forest Fire Fighting Plans by means of Arti cial Intelligence Techniques) [AGP04; ACF+05b] wurde ein auf KI-Planungstechniken basierendes Assistenzsystem fur das Generieren von Plzur Waldbrandbek anen ampfung entwickelt. Das System soll die manuelle Erarbeitung von Einsatzpl anen durch eine HTN- Planungskomponente unterstane von SIADEX beinhal utzen. Die dynamische Einsatzdom tet Schwierigkeiten wie: plotzliche Ereignisse, eine sich schnell  andernde Umgebung und fehlende bzw. falsche Informationen ane. Daronnen Aktionen uber die Domuber hinaus k nicht den gewuhrt werden. unschten Erfolg erzielen oder unerwartet nicht ausgef¨ Die Architektur von SIADEX soll laut den Autoren all diesen Unw¨ agbarkeiten Rechnung tragen [ACF+05b]. Das vorgeschlagene System soll zum einen als virtuelle Lernumgebung in Form einer Einsatzsimulation fampfung, zum Training von ur taktische Waldbrandbek Einsatzleitern und zur Evaluation von Einsatzstrategien genutzt werden. Auerdem soll das System in realen Latzen zur intelligenten Entscheidungsunterst oscheinsutzung – intelligent decision support system (IDSS) – eingesetzt werden. Besonderes Augenmerk wurde dabei auf ein human-centred Planungsframework gelegt, das eine einfache Interaktion von typischerweise KI-unbedarften Endanwendern mit dem Planungssystem erm oglicht. Mit dem Paper Bringing Users and Planning Technology Together [FCG+06] gewannen die Autoren diesbez uglich auf der ICAPS (International Conference on Automated Planning and Scheduling) 2006 den Best Applicaton Award\. " Abbildung 3.4: Der sog. lifecycle von SIADEX in einem Waldbrandszenario. (Quelle: [FCG+06]) In SIADEX wurde ein zustandsbasierter Vorw artsplaner auf Basis des HTN-Planers SHOP2 (siehe [NAI+03]) integriert, dessen Vorg anger (J)SHOP auch schon im HICAP-Projekt eingesetzt wurde. Der Planer unterst utzt an temporalen Konzepten die Dauer von Operatoren und die Angabe m oglicher Deadlines in den Zielvorgaben. Die temporale Erweiterung der Planungsfunktionalit at in SIADEX beruht auf dem von Nau [NAI+03] vorgeschlagenen Multi-Timeline Preprocessing (MTP) [NAI+03], einem speziellen Algorithmus, der eine zeitbehaftete PDDL (Planning Domain De nition Language) Operatorbeschreibung in eine zu SHOP2 konforme Darstellung umwandelt (siehe auch [CFG+06]). Abbildung 3.4 zeigt das Zusammenspiel aller Komponenten. 26 Ans atze der automatische Handlungsplanung Eine weitere Schl usselkomponente der Architektur stellt der Ontologie-Server BACAREX dar, in dem die Objekte der Planungsdom ane in Form von Individuen einer Wissensbasis reprasentation in asentiert sind [ACF+05a]. In BACAREX wurde die Wissensrepr vier verschiedene Ontologien aufgeteilt: Domain Object, World & Object States, Temporal Constraints und Tasks. In ihnen werden die Namen der Objekte der Dom(wie ane z. B. Fahrzeuge, GIS-Daten und Orte), dynamische Eigenschaften (Pr adikate/Fluents der Planungsdom ane), zeitliche Bedingungen (max. Flugdauer oder Einsatzdauer von Feuerwehrkr  aften) und die sog. Standard Operation Protocols (Task-Hierarchie) abgelegt. Der Ontologie-Server benutzt als Backend eine relationale Datenbank, wodurch eine persistente Datenspeicherung erreicht wird. Gleichzeitig werden durch die  ublichen Logging-und Recovery-Mechanismen quasi paralleleZugri sm “ oglichkeit von verschiedenen Benutzern " auf die Daten sichergestellt. In der Wissensbasis wurden wichtige Begri e und ozielle Brandbek ampfungsvorschriften und Handlungsstrategien der Feuerwehr sowie geogra sche Informationen (GIS) ahrdete Region abgelegt. uber gef Als Inferenzmechanismen kommen in SIADEX Abduktion (Hypothese vom Einzelnen auf eine Regel und das Allgemeine) und Deduktion (Schluss vom Allgemeinen auf das Einzelne; Wenn-Dann-Aussagen) zum Einsatz. Die Deduktionsfunktionalit at kann bei Bedarf durch spezielle Inferenz-Tasks im eigentlichen Dekompositionsprozess getriggert werden. Als E ekt dieser Inferenz-Tasks sollen Variablenbindungen oder Assertions/Retracts im jeweiligen Zustand resultieren. Zugriff sollen alle Beteiligten  uber eine Web-Plattform erhalten, uber die alle zur Verf onnen. Ein Web-Browser und eine ugung stehenden Informationen eingesehen werden k Internetverbindung stellen laut den Autoren die einzigen technischen Anforderungen an die Benutzer-PCs dar. Zur Reprasentation von Einsatzplanen wurden verschiedene den Nutzern vertraute Formate g angiger Oce-Anwendungen verwendet. Hybrider Planungsansatz fatze ur THW-Eins Aus der Forschungsgruppe rund um Biundo und Schattenberg (Institut funstliche ur K Intelligenz der Universitat Ulm) stammen Arbeiten rund um die Thematiken: (HTN)Planung, Scheduling, Hybrid-Planung und ontologiebasierte Middleware f ur Planung und Scheduling [Sch08; SB02; SBG+09]. In [BS01] thematisieren Biundo & Schattenberg den Einsatz der Hybrid-Planung als Basis eines Unterstur das Krisenma utzungssystems f nagement in der Dom ane der Bundesanstalt Technisches Hilfswerk (THW). Unter Hybrid- Planung verstehen die Autoren die Kombination von HTN-Planung mit zustandsbasierter Partial-Order-Planung (POP). Biundo et al. sprechen hierbei von Partial-Order Causal- Link (POCL)-Planung. Im Rahmen eines Meta-Projektes Namens PANDA (Planning and Acting in a Network Decomposition Architecture) wurden Fragen untersucht, die die Erstellung komplexer HTNPlanungsdom utzung durch geeignete Werkzeuge, die Konsistenzpr anen, die Unterstufung komplexer Dom anen und die Einbeziehung des Nutzers bei der manuellen Planverfeinerung und Reparatur betre en. Das dabei entwickelte PANDA-System soll erstmals eine konsequente Integration von anen, HTN-Plund Scheduling realisieren [Sch08]. POCL-Planen Fandig anwendbaren Plan, uhrt die HTN-Planungskomponente zu einem noch nicht vollst so soll in einem zweiten Schritt die konventionelle“ POP zur Vervollst andigung des Plan ” fragmentes herangezogen werden. O ene Vorbedingungen sollen durch den Aufbau kausaler Beziehungen bzw. durch eine Einf uhrung (abstrakter) Tasks in den Plan geschlossen werden (vgl. [BS01]). PANDA hat als Anwendungsdomatze im Fokus, ahnlich den ane u. a. reale THW-Eins im Oderbruch-Hochwasser 1997 durchgef uhrten Manahmen. In solch einem Szenario sind Fazit und Motivation des Checklisten-Ansatzes eine Vielzahl von qualitativ unterschiedlichen Aufgabenfeldern wie Logistik, Konstruktion, Organisation und Work ows zu managen, wobei laut Autoren von einer Beteiligung von bis zu 180 Gruppen, 1500 Helfern und einer Einsatzdauer von mehreren Wochen ausgegangen werden kann [Sch08]. Die Autoren kommen zu dem Schluss, dass es nicht selbstverst andlich ist, fane ur solch eine komplexe Domein widerspruchsfreies und damit konsistentes Dom anenmodell zu erstellen und zu administrieren. Schattenberg et al. schlagen daher – ahnlich dem Process-Panel in HICAP oder dem Domutzung f anen-Editor in CoSAR-TS – eine geeignete Tool-Unterstur die Modellierung konsistenter Domanenmodelle vor [SBB08]. Der Task-Editor soll den Benutzer  uber noch bestehende Inkonsistenzen und manenmodell bereits w ogliche Fehler im Domahrend der Kon gurierung informieren. Der PANDA-Editor enth alt Visualisierungstools (PANDA- Viz), mit denen der Planungserfolg visualisiert und eine Unterstur Plan utzung fsog. ” Entwicklungszyklen“ gegeben werden kann. Wommlichen, meist komman ahrend bei herk dozeilenbasierten KI-Planern bei einem nichtl osbaren Planungsproblem der Grund nicht ersichtlich ist, soll PANDA-Viz durch geeignete Darstellung eines Planfragmentes die noch o enen Teile geeignet visualisieren. Ein Dom anenexperte soll auf Basis dieses noch unvollst andigung auerhalb der eigentlichen KI andigen Planes eine manuelle Plan-Vervollst Planungsroutine vornehmen k onnen [Sch08]. Abbildung 3.5 zeigt einen beispielhaften Auszug aus einer Task-Hierarchie im PANDA-Projekt. Abbildung 3.5: Auszug einer Task-Hierarchie aus Sicht des THW. (Quelle: [BS01]) Bez uglich der POCL-Planung stellt sich jedoch die Frage nach der Anwendbarkeit in der Praxis. Ohne explizite Ziele kann auch keine pseudo\-Zielaktion angegeben werden, wel " che aber fotigt wird. Obwohl die Autoren ausdr ur eine POP benucklich auf den Einsatz ihrer Arbeit in der realen THW-Domanenmodell kon ane hinweisen, erscheint das Dom struiert. Es bleibt der Eindruck, dass sich die Planungsdom ane eher den Anforderungen des vorgeschlagenen Planungsframeworks anpasst, als das Planungsframework den Anforderungen der realen THW-Domuglich eines ane. Erfahrungs-und Evaluationsberichte bez realen THW-Einsatzes sind nicht verf ugbar. 3.4 Fazit und Motivation des Checklisten-Ansatzes Die Bemachlich auf die Modellierung der Management uhungen des BPM zielen haupts Prozesse bei Groschadenslagen ab. Wie sich jedoch zeigte, ist im BOS-Bereich eine Prozessmodellierung ungleich schwieriger als in klassischen BPM-Domunde hierf anen. Grur liegen in der hohen Komplexit at und der Dynamik eines Einsatzgeschehens. Peinel et al. Fazit und Motivation des Checklisten-Ansatzes sehen die Komplexitugung stehenden Modellierungsumgebungen at der momentan zur Verf als einen weiteren Hindernisgrund der Anwendung von BPM auf die BOS-Dom ane [PR09]. Hinzu kommt, dass sich im BOS-Bereich kaum detaillierte Prozesse identi zieren lassen, da die ablaufenden Einsagt sind. Falls Prozesse atze von Fall zu Fall unterschiedlich ausgepr de niert sind, dann nur auf der recht abstrakten Ebene der Regelwerke (z. B. den Dienstvorschriften). Ein zu prozeduraler SOP-Charakter, wie er z. B. in [BLK11] vorgeschlagen wird, ist im BOS-Bereich eher hinderlich. Allen vorgestellten BPM-Ans atzen mangelt es an pr azisen Beschreibungen dessen, wie die vorgeschlagenen Systeme aufgebaut sind und wie die Interaktion mit den Einsatzkrauft – was natuhen Phase aften genau ablurlich auch der fr dieser Ansunftige atze geschuldet ist. Hier lohnt es sich, die weiteren Fortschritte und zuk Praxiserfahrungen im Auge zu behalten. Die KI-Ansatze gehen von der Annahme aus, dass es eine hinreichend groe Menge de nierter Prozesse gibt, sodass sich bei Angabe der Toplevel-Tasks automatisch ein kompletter L“ ur das Vorgehen bei einer speziellen Krise berechnen lasst. Dies osungsplanf ” scheint mit Blick auf die dynamische und heterogene BOS-Dom ane nicht realistisch. Auch ist das Vorgehen nach festen Plane wegen der hohen Dynamik kaum anen in der BOS-Dom m oglich. Wie die Erfahrungen im SpeedUp-Projekt zeigten, ist zudem eine Erfassung aller Ressourcen (Einsatzkrur eine HTN-Planung notwendige afte und Einsatzmittel) in der f Form unpraktisch oder aus unm Informationsmangel gar oglich. Hinzu kommt, dass die Dom ane nicht statisch und nicht endlich ist. Auch sind die Zielvorgaben in Groschadensereignissen oft nicht ausreichend gut formulierte bzw. mandig angepasst werden. ussen st In dieser Arbeit soll als Alternative zur Planung und Prozessmodellierung ein anderer Weg eingeschlagen werden. Die vorliegende Arbeit konzentriert sich in den kommenden Kapiteln auf die Erarbeitung eines checklistenorientierten Ansatzes einer Handlungsassistenz bei der Anwendung von SOPs. In einigen der oben vorgestellten Arbeiten wurde bereits (direkt oder indirekt) das Thema Checklisten-Anwendung motiviert (vgl. z. B. interactive ” SOPs“ in [BLK11], smart Checklists“ in [PRW12b] oder distributed and intelligent to "" do lists“ in [WTP06]). Keiner der gezeigten Ansatze geht jedoch auf Fragen der Funktion  und Anwendung von Checklisten genauer ein. Ebenso wird der gew unschte E ekt einer Fehlervermeidung von keinem der genannten Ans atze thematisiert. In vielen der oben betrachteten Arbeiten bleibt unklar, inwieweit die Latze den Praxisanforderungen osungsans gerecht werden. Im Bereich der Sicherheitsforschung (als Teilbereich der Humanwissenschaften) sind Checklisten als kognitives Hilfsmittel bereits seit l angerer Zeit ein Thema. Da Checkliste nicht gleich Checkliste ist, soll im kommenden Kapitel ein Blick auf relevante Aspekte der Human-Factors-Forschung zeigen, was genau hinter dem Konzept Checkliste steckt und welche bekannten Phutzung von Checklisten beachtet anomene bei einer Computerunterst werden sollten. Kapitel 4 Checklisten – eine Human Factors Perspektive No matter how expert you may be, well-designed checklists " can improve outcomes.“ (Steven D. Levitt) In diesem Kapitel sollen Erkenntnisse aus dem seit den letzten Jahren an Bedeutung gewinnenden Human-Factors-Forschungszweig der Humanwissenschaften betrachtet werden, welche Fragen der Interaktion von Menschen in komplexer und dynamischer Arbeitsumgebung (auch komplexes, soziotechnisches System genannt) betre en. Nachfolgend wird speziell auf das Checklisten-Prinzip eingegangen, das zur Handhabung von Komplexit at und zur Einhaltung standardkonformer Arbeitsschritte verwendet wird. 4.1 Strategien der Fehlervermeidung & Handlungsassistenz Menschliches Versagen ist ein zentrales Thema der Human-Factors-Forschung, die sich mit der menschlichen Komponente in komplexen Systemen besch aftigt. Sie leitet daraus u. a. Strategien zur Fehlervermeidung ab. In dieser Arbeit sind die Strategien zur Fehlervermeidung bei der Ausf uhrung von Standardprozeduren von besonderem Interesse. Bevor auf diese Strategien eingegangen wird, soll das Konzept Fehler\, das bis jetzt " eher allgemein gebraucht wurde, im Kontext der Human-Factors-Forschung und der Zielstellung dieser Arbeit pr azisiert werden. Von Rasmussen [Ras82], Normen [Nor88] und Reason [Rea90] stammen grundlegende theoretische Arbeiten zur Thematik menschli ” che Fehler\, aus denen entsprechende Fehlermodelle hervorgegangen sind. Reason (vgl. [Rea90] S. 9) de niert z. B. den Begriff Fehler (error) als: a generic term to encompass all " those occasions in which a planned sequence of mental or physical activities fails to achieve its intended outcome\. Beispielhaft orientiert sich die vorliegende Arbeit am Fehlermodell von Reason, der in seinem Buch Human Errors“ [Rea90] zwei grundlegende Fehlertypen ” anhand der Ebenen Planung, Speicherung und Ausf uhrung unterscheidet. Reason folgt in seiner Arbeit dem als hybride Klassi kation“ bekannten Fehlermodell von Norman " [Nor88], in dem kognitive und motorische Fehler-Aspekte eine Einteilung in zwei Arten von Fehlern begruhrungsebene Handlungen, unden. In diesem Modell werden auf der Ausf die nicht planmahrend Pl aig verlaufen, als Patzer oder Schnitzer (slips) bezeichnet. Wane, die gem aß der Zielstellung in einer entsprechenden Situation nicht angemessen sind, von ihm als eigentliche Fehler (mistakes) bezeichnet werden (vgl. [Rea90] S. 255). 29 Strategien der Fehlervermeidung & Handlungsassistenz Folgt man obiger Einteilung, so wird deutlich, dass das Auslassen wichtiger, gebotener Handlungen (gem¨ aß den SOPs) in erster Linie dem Fehlertyp Patzer (bzw. Schnitzer) zuzurechnen ist. Erst auf der Ebene der Evaluierung von SOPs kann deren Unangemessenheit gem¨ aß der intendierten Zielstellung als ein Fehler im Sinne von Reason aufgefasst werden. Handlungspatzer treten nach Reason typischerweise bei routinierten Handlungen in vertrauten Arbeitsumgebungen immer dann auf, wenn die Aufmerksamkeit sinkt oder man durch externe Ereignisse abgelenkt ist. In der weiteren Arbeit soll f¨ ur das unbeabsichtigte sowie das beabsichtigte Auslassen von Handlungen der Einfachheit halber jedoch weiterhin die Bezeichnung Fehler“ verwendet ” werden. Die Einteilung von Reason sollte dabei allerdings im Hinterkopf behalten werden. Weiterhin wird sich im Folgenden nur noch auf die Ausf¨ uhrungsfehler konzentriert. führt zu Unsicherheit minimieren durch Standardisierung und Normung ..Verringerung von Handlungsspielräumen ..Zentralisierung von Planung und Steuerung ..Abweichung als zu eliminierende Störung Komplexität Unsicherheit kompetent begegnen durch Flexibilität und Lernen ..Erhöhung von Handlungsspielräumen ..Flexibilisierung der Anwendung von Regeln ..Abweichungen als Lerngelegenheit begreifen Strategien im Umgang Unsicherheit (eines Arbeitsumfeldes und deren Prozesse) Fehlern (Patzer, Schnitzer) führt zu (bei Ausführung/Anwendung) Abbildung 4.1: Grundlegende Strategien im Umgang mit Unsicherheit (Quelle: [Man09]). Nicht nur die Gefahr von sinkender Aufmerksamkeit w¨ ahrend Routinearbeiten hat die Human-Factors-Forschung als Ursache menschlicher Fehler identifiziert, sondern auch die Unsicherheit in den Arbeitsprozessen, die sich aus den Merkmalen komplexer Systeme ergibt. Manser [Man09] f¨ uhrt zwei grundlegende Tendenzen des Umgangs mit Unsicherheit in den Organisationen auf (siehe Abb. 4.1). Die Strategie der Standardisierung setzt auf eine Reduktion operativer Handlungsspielr¨ aume und verringert somit die subjektiv empfundene Komplexit¨ur den at der Prozesse aus Sicht des Handelnden. Somit wird die Unsicherheit f¨ Handelnden reduziert, wodurch letztendlich m¨ogliche Abweichungen von der best practice“ ” vermieden werden sollen. In diesem Zusammenhang hat sich der Begriff Komplexit¨“ atsreduktionetabliert, der ” jedoch etwas ungl¨ahlt ist. Er bedeutet n¨ ucklich gew¨amlich nicht – wie der Begriff suggeriert – eine Vereinfachung des Arbeitsumfeldes und der Prozesse selbst, sondern vielmehr eine Abstraktion im Umgang mit einem komplexen Arbeitsumfeld. Eine zur Standardisierung entgegengesetzte Strategie setzt auf eine bewusste Flexibilisierung. Gemeint ist eine bewusste Erweiterung von Handlungsspielr¨ aumen und eine flexible Anwendung von Regeln. Diese Strategie vertraut auf die menschlichen Probleml¨ahig osef¨ keiten und sieht notwendige Abweichungen als eine Chance zum Lernen und zur flexiblen Anpassung an die Gegeneinheiten an (vgl. z. B. [Man09]). Checklisten als kognitives Hilfsmittel Beide Strategien haben ihre Vor-und Nachteile. Abstrahiert man Komplexit at, so besteht immer die Gefahr, komplizierte Zusammenhogliche ange zu weit zu vereinfachen, sodass m kritische Punkte aus den Augen verloren werden. Auf der anderen Seite st ot die Strategie der Kompetenzerh ohung und Flexibilisierung in den Situationen an ihre Grenzen, in denen es gilt, Richtlinien (Gesetze, Vorschriften, SOPs) zu befolgen. Die Strategie der exiblen Regelanwendung erscheint auf den ersten Blick dem BOS- Bereich und den Merkmalen einer Groschadenslage angemessen. Wie in Kapitel 2 gezeigt wurde, ist im BOS-Bereich jedoch eine gewisse Standardisierung durch die Dienstvorschriften und Gesetze gegeben. Diese gilt es trotz einer notwendigen Flexibilit at der Handlungen zu beachten. Durch regelm aiges Training von Groschadenslagen soll sichergestellt werden, dass jede Einsatzkraft gem aß den Vorschriften korrekt agiert oder zumindest nur soweit davon abweicht, wie es die spezielle Lage erfordert und es die Regeln noch erlauben. Kluge et al. weisen in ihren Untersuchungen (siehe [KG12; KGB12]) jedoch darauf hin, dass der Trainingserfolg gerade fangere Zeit nicht angewendet werden ur Handlungsroutinen, die l (z. B. die in einem MANV), in der Regel sehr bescheiden ausf allt. Als alternative Herangehensweise geht Kluge daher davon aus, dass niemanden zugemutet werden sollte, sich ” alles auch angere Phasen des Nichtgebrauchs zu merken[KG12]. Vielmehr sollen uber l“ sog. Job-Aids“ als Arbeitshilfe die menschliche F ahigkeit, Informationen zu speichern und ” zu verarbeiten, erweiternd unterst utzen. Laut Rossett & Gautier-Downes [RG91] sind diese kognitiven Hilfsmittel gerade faig und selten ur die Aufgaben sinnvoll, die unregelm ausgef uhrt werden, die komplex und umfassend sind, und in denen Fehler folgenschwere Konsequenzen haben k onnen. Ein pragmatischer L¨ osungsansatz zur Fehlervermeidung stammt von Reason. In Anbetracht der Feststellung, dass in der Nuklearindustrie viele Unf alle auf eine fehlerhafte Ausfuckzuf uhrung von Wartungsprozessen zuruhren waren, stellten sich Reason und sein Forschungsteam bereits in den 1990er Jahren die Frage, ob eine Art elektronischer Checklisten hierbei nicht hilfreich sein k onnen (vgl. [Rea90], Kap. 8, S. 239 .). Er schlug hierzu ein computer-integriertes Checklisten-System vor, das einem Arbeiter bei komplexen und sicherheitskritischen Wartungsprozeduren assistierend zur Seite stehen soll. In seinem Labor entwickelten er und seine Kollegen hierf ur ein System namens PIMA (Portable Interactive Maintenance Auxiliary) (vgl. [Rea90] S. 240 .), das auf einem fraufer uhen Laptop-Vorl (Epson PX-8) basierte. Laut Reason hatte dieses frahigkeit, sich uhe System bereits die F ¨ mit dem Uberwachungssystem der Nuklearanlage zu verbinden und somit z. B. die Checklisten aufgrund der dort bereitgestellten Sensordaten automatisch anzupassen. Bevor im n achsten Kapitel die Idee der elektronischen Checklisten aufgegri en wird, soll im folgenden Abschnitt das Grundprinzip hinter Checklisten genauer vorgestellt werden, da es usselrolle bei der Bereitstellung einer Computer- in der weiteren Arbeit eine Schl unterst utzten Handlungsassistenz darstellt. 4.2 Checklisten als kognitives Hilfsmittel Checklisten sind vielen von uns ein wohlvertrautes Konzept. Ohne groß  uber sie nachzudenken, nutzen wir sie in manch Alltagssituationen. Doch die Wenigsten von uns machen sich Gedanken  uber das Grundprinzip hinter den Checklisten und dessen korrekte Anwendung. Zu trivial scheint dieses Hilfsmittel zu sein. Doch sind Checklisten wirklich ein so einfaches und leicht anzuwendendes Konzept? In der Literatur und in der Praxis gehen die Meinungen dar uber, was alles unter einer Checkliste zu verstehen ist und ob, wo und wie sie einzusetzen sind, weit auseinander. Checklisten als kognitives Hilfsmittel 4.2.1 Was sind Checklisten? – eine Arbeitsde nition Die Vorstellungen, was Checklisten genau sind und zu welchem Zweck sie eingesetzt werden, variieren von Anwendungsgebiet zu Anwendungsgebiet mehr oder weniger stark. Die folgenden De nitionsversuche aus dem WWW geben einen Eindruck altigen uber die vielf Vorstellungen  uber Checklisten. • Eine Checkliste ist eine Sonderform einer Liste mit dem Ziel, alle relevanten Fragen " zu einem Thema an zentraler Stelle zusammenzufassen. Sie bieten ein Grundger ust an kritischen Punkten, die bei einer bestimmten Tufen sind. Bei den Fragen atigkeit zu pr handelt es sich um geschlossene Fragen [sic] die schnell und zweifelsfrei beantwortet werden k onnen.“ (www.openthesaurus.de; abgerufen am 20.12.2013) • A checklist is a type of informational job aid used to reduce failure by compensating " for potential limits of human memory and attention. It helps to ensure consistency and completeness in carrying out a task.“ (en.wikipedia.org; abgerufen am 20.12.2013) • Checklist: A list of tasks to be completed, names to be consulted, conditions to be " veri ed and similar.“ (wiktionary.org; abgerufen am 20.12.2013) Wissenschaftliche Publikationen zum Thema Checklisten nden sich jedoch kaum. Eine Ausnahme stellt der Luftfahrtbereich dar. So de nieren z. B. M. R. Gr unninger et al. Checklisten wie folgt. A checklist is a device designed to support the pilots to avoid for " getting vital items and actions while following standard operating procedures“ ([GKB10]; S. 78). Allgemein l¨ = asst sich festhalten, dass als Checkliste (englisch check-list, aus: check Kontrolle, prufen und list = Liste) umgangssprachlich ein kognitives Hilfsmittel (englisch mnemonic device) bezeichnet wird, das einem Akteur bei einer Handlung als Kontrolle dient. Je nach Einsatzgebiet werden Checklisten auch synonym als Abhaklisten, Kontrolllisten oder auch Pr u isten bezeichnet (siehe z. B. [GLB86]). Im privaten Umfeld begegnen uns Checklisten z. B. in Form einer Einkaufsliste, einer einfachen Eselsbr ucke oder einer ToDo- Liste. In kritischen Arbeitsbereichen, wie z. B. der Luftfahrt oder der Prozessindustrie (z. B. Chemie), nehmen sie eine besondere Schl usselrolle bei der Fehlervermeidung ein. In all diesen Anwendungen soll etwas – im Auge des Anwenders – Wichtiges auf ein mogliches und zu vermeidendes Vergessenhin gepr “ uft werden. Was dieses Etwas genau " ist, l asst sich erst anhand einer konkreten Anwendung festmachen. Der De nitionsversuch von M. Scriven ([Scr07]; S. 1) macht die prinzipielle Vielfuft altigkeit dessen, was uberpr werden soll, deutlich: A checklist is [...] a list of factors, properties, aspects, components, ” criteria, tasks, or dimensions, the presence, referent, or amount of which are to be considered separately, in order to perform a certain task.“ Eine Checkliste kann als die groe Schwester der Merkhilfe (Eselsbr ucke) aufgefasst werden. Ein Beispiel fucke sind die groen 5W, die bei einer Notrufmeldung am ur eine Eselsbr Telefon als Informationen wichtig sind: Wo geschah es? Was geschah? Wie viele Personen sind betro en? Welche Art der Erkrankung/Verletzung liegt vor? Warten auf R uckfragen! Eine Checkliste jedoch nur als eine bloe Au istung von Punkten zu de nieren, ist zumindest dann unzureichend, wenn man sich mit der Frage nach Kriterien einer erfolgreichen Anwendung beschucksichtigen, aftigt. Hierzu gilt es, eine Reihe von Aspekten zu ber die allesamt entscheidend feine erfolgreiche Erstellung, Anwendung und Evaluierung ur von Checklisten sind. Die angesprochenen Aspekte einer Checkliste lassen sich wie folgt als W-Fragen formulieren: 1. Was wird gepruft? – Diese Frage bezieht sich auf das bereits oben angesprochene Etwas, das es zu pr ufen gilt. Hier besteht eine Relation zu kritischen Schritten einer dahinterliegenden komplexeren SOP. (Mehr hierzu im kommenden Abschnitt 4.3.) Checklisten als kognitives Hilfsmittel 2. Wann wird gepr– angt uft? Wann eine Checkliste zu beachten ist und wann nicht, h von der jeweiligen Arbeitssituation des Anwenders ab. F ur Checklisten sollte daher geregelt sein, wann sie anzuwenden sind und in welchen Situationen man von ihnen abweichen darf. 3. Wer pr– ur unterschiedliche Anwender. uft? Checklisten sind kognitive Hilfsmittel f Hier stellt sich die Frage nach dem Hintergrundwissen, dem Ausbildungsgrad und der eingenommenen Rolle des jeweiligen Anwenders im korrespondierenden Prozess. 4. Wozu wird gepruft? – Welchen Zweck haben die einzelnen Items bzw. eine ganze Checkliste, d. h., auf welche Funktionen zielt die Checkliste ab? 5. Wie wird gepruft? – Wie die Anwendung in der Praxis zeigt, gilt es je nach Anwendungsphilosophie, unterschiedliche Abarbeitungsmodelle anzuwenden (siehe 4.2.3). 6. Wo wird gepruft? – Weiterhin spielt die Frage des Einsatzortes, d. h. die zu erwartende Arbeitsumgebung und Situation eine wesentliche Rolle bei der konkreten Ausgestaltung und der Anwendungsmethodik einer Checkliste. Ein Groteil der Aspekte spiegelt sich in folgender Arbeitsde nition wider: De nition 1 (Checkliste) Als Checkliste wird eine Sonderform einer Liste bezeichnet, deren Listenelemente (Items genannt) jeweils aus einem Freitext und einer optionalen Checkbox bestehen. Jedes Item steht f ur einen aus Sicht des Anwenders sicherheitskritischen Aspekt einer zur Checkliste korrespondierenden (Standard-)Prozedur. Dar uber hinaus ist jeder Checkliste ein G ultigkeitsbereich, die Situation(en) ihrer Anwendung und ein adressierter Benutzerkreis zugeordnet. 4.2.2 Funktionen, Einsatzbereiche und Zielgruppen Checklisten helfen ¨ uhren, wo uberall dort Handlungen korrekt (standardkonform) auszuf uns unsere tat oder aufgrund unbe agliche Routine, z. B. durch Stress, steigende Komplexit kannter Situationen, im Stich lachtnisfehler zu vermeiden. asst. Sie sollen dabei helfen, Ged Eine Checkliste ist somit ein kognitives Werkzeug zur Sicherstellung einer konsistenten Anwendung einer (momentanen) best practice“ in einem Arbeitsgebiet. Ihre konsequen " te Anwendung soll zu einer koordinierten Vorgehensweise aller beteiligten Akteure f uhren [DW91]. Folgende Hauptfunktionen einer Checkliste lassen sich identi zieren: • Ged achtnisentlastung: Buerscaper & St. Pierre [BP07] sehen als psychologische Kernfunktion von Checklisten vor allem die Geduh achtnisentlastung bei der Durchf rung sicherheitskritischer Handlungsketten an. • Sicherstellung eines Qualitonatsstandards: Individuelle Verhaltensabweichungen k ¨ nen durch explizite normative Vorgaben und deren Uberpr ufung reduziert oder gar vermieden werden. Dies garantiert eine gleichbleibende Qualituhrung von at der Ausf Prozessen. • Handhaben von Komplexit at: Die Handhabung komplexer SOPs kann mittels Konzentration auf das Wesentliche deutlich ur den Menschen gestaltet uberschaubarer f¨ werden und somit durch Abstraktion (wo m¨ oglich) zur besseren Handhabung von Komplexit at beitragen. Checklisten als kognitives Hilfsmittel • Reduktion von Unsicherheit: Als psychologische Wirkung kann die Verringerung der Unsicherheit auf Seiten des Handelnden einen nicht zu untersch¨ atzender positiven Effekt darstellen. (Sie kann jedoch auch kontraproduktiv wirken, siehe Abs. 4.2.5 .) Die oben genannten Hauptfunktionen tragen allesamt mehr oder weniger zu der gew¨ unschten Minimierung des Fehlerrisikos auf der Handlungsebene bei (vgl. Abschnitt 4.1). “Alltag” “Notfall” - Nicht-Normale-Checklisten Normale-Checklisten Checkliste … .. … … … … .. … … … … .. … … … … .. … … … … .. … … … … Checkliste … .. … … … … .. … … … … .. … … … … .. … … … … .. … … … … Checkliste … .. … … … … .. … … … … ..? .. CL-Y CL-Z Wechsel der Situation zu seltenen SOPs Wechsel der Situation zu extrem seltenen und kritischen SOPs - sehr einfache Struktur - einfache Struktur - hoch spezialisiert - einfache Item-Listen - spezielle Einsätze - seltene Ausnahmefälle Abbildung 4.2: Checklisten f¨ ur unterschiedliche Situations-Klassen. In einigen Praxisf¨ ag allen werden Checklisten dazu verwendet, Mitarbeiter jenseits von allt¨ lichen Routinehandlungen sicher durch komplexe und besonders sicherheitskritische Prozedurenzuf ¨ uhren. Die abnormal-und emergency-checklists in der Luftfahrt sind hier- f¨prominente Beispiele (siehe hierzu z. B. [DW90; DW93]). Je nach Anwendungsklas ur se der Prozeduren werden dort verschieden komplexe Checklisten angewandt; ausgehend von Standardprozeduren, uber ¨Sonderprozeduren“ hin zu Notfallprozeduren“ (siehe Abb. ” ” 4.2). Die Art der SOP bedingt hier die Ausgestaltung und vor allem den erforderlichen Komplexit¨ ats-und Detaillierungsgrad der Checklisten. Einige Autoren (siehe z. B. [BLK11]) sehen daher Checklisten prim¨als Hilfsmittel ar zur Entscheidungsunterst¨ utzung oder gar zur Prozesssteuerung an. In diesem Sinne sollen Checklisten Handlungsalternativen vorgeben und somit den Anwendern die Entscheidung ¨ uber die korrekte Vorgehensweise abnehmen. Folgt man jedoch der Argumentation und der Fehler-Einteilung von Reason, so wird klar, dass Checklisten keine Hilfestellung in der Entscheidungsunterst¨onnen/sollten, wenn man utzung und Prozesssteuerung geben k¨ deren Hauptfunktion, die Vermeidung von Ausf¨ uhrungsfehlern, ernst nimmt. Auch die Autoren der Checklist for a Checklist“1 gebenzubedenken: A checklist is NOT a teaching ” ” tool or an algorithm“. Checklisten sollten also nicht alle Eventualit¨ aten und alle denkbaren Prozessauspr¨Check agungen wie in einem Workflow enthalten. Gawande schreibt hierzu: ” lists are not comprehensive how-to guides [...]. They are quick and simple tools aimed to buttress the skills of expert professionals“ ([Gaw10], S. 128). Da Checklisten nur als Ged¨utze gedacht sind, sollte deren Einsatz als eine reine achtnisst¨ Handlungsanweisung (Prozesssteuerung) mit Vorsicht begegnet werden. Zumindest sollte diese Art der Anwendung nur in Ausnahmef¨ allen angewendet werden, in denen keine Experten dieSOPsausf¨ussen. uhren bzw. in denen sehr seltene SOPs angewandt werden m¨ Seit den sp¨ aten 1960er Jahren finden Checklisten in der Luftfahrt Anwendung zur Sicherstellung einer richtigen Konfiguration der immer komplexer werdenden Flugzeuge. Heutzutage sind sie ein wichtiger Bestandteil aller sicherheitskritischen Prozeduren im Cockpit 1 Siehe www.projectcheck.org (abgerufen am 20.12.2013) und Anhang Seite 137. Checklisten als kognitives Hilfsmittel [DW90; DW93]. Checklisten spielen in der Luftfahrt jedoch eine gewisse Sonderrolle, da sie aufgrund der weiten Verbreitung und t aglichen Anwendung ein fester Bestandteil der Cockpit-Handlungsroutinen selbst geworden sind. Hierin liegt wohl auch begr undet, warum in der Luftfahrt Checkliste und SOP oft im gleichen Atemzug genannt werden (vgl. hierzu die Diskussion in Abschnitt 4.3). In Sachen Sicherheitskultur und Anwendungskonzepte gilt die Luftfahrt als Vorreiter und Ideengeber fahnlicher komplexer und sicherheitskritischer Arbeitsumge ur eine Reihe  bungen. So nden Checklisten in weiteren sogenannten Hochsicherheitsbereichen wie z. B. der Chemischen Industrie, der Intensivmedizin, der Hochseeschi fahrt und dem Milit ar eine ¨ breite Anwendung. Uberall dort, wo Menschen in komplexen (sozio-)technischen Systemen mit h ochsten Sicherheitsanforderungen arbeiten, lassen sich Anwendungsbeispiele nden. Qualität Beispiel Konsequenzen bei Fehlern Bereiche mit sehr geringen Sicherheitsanforderungen Privater Bereich, z.B. Einkaufsliste oder ToDo-List Objektiv sehr geringe und eher unkritische Auswirkungen Bereiche mit mäßigen Sicherheitsanforderungen Wirtschaftsunternehmen / Industrie mit hohem Qualitätsanspruch (Risiko- und Qualitätsmanagement) Bedrohend: Verdienstausfall, Regressforderungen, Image- schaden, Personenschäden Bereiche mit höchsten Sicherheitsanforderungen Hochsicherheitsberufe wie z.B.: Luft- und Raumfahrt, Intensivmedizin, Chemische Industrie oder Militär Katastrophal: Tote, Verletzte, große materielle Schäden, Zerstörung von Infrastruktur Abbildung 4.3: Grade der Sicherheitsanforderungen. Mit steigendem Ausmaß der Fehlerkonsequenzen steigt auch der Anspruch an die Fehlervermeidung (vgl. Abb. 4.3). Werden im privaten Bereich Punkte einer Checkliste vergessen, so sind die zu erwartenden Konsequenzen in der Regel wohl eher gering. In Hochsicherheitsbereichen hingegen k onnen Fehler fatale Auswirkungen haben, sodass dem Checklisten- Konzept dort eine besondere Aufmerksamkeit zuteilwird. Checklisten nden dort ausnahmslos als kognitives Hilfsmittel fhochspezialisiertes und erfahrenes Personal (die ur Experten) Anwendung. Williamson weist in [Wil10] (S. 3) unter anderen drauf hin, dass checklists are used by experienced and quali ed people and are not a substitute for trai " ning.“ Checklisten nur zu Trainingszwecken einzusetzen, sollte vermieden werden. Ein weiteres Einsatzgebiet stellt die Medizin dar. In der heutigen Zeit verlangen viele ¨ Arbeitsgebiete der Medizin den Arzten und dem teils hochspezialisiertem P egepersonal immer mehr Spezialwissen  uber immer komplexer werdenden Techniken und Prozeduren ab. Gawande spricht hierbei von dem Ph anomen der super-specialization [Gaw10]. Inspiriert durch den erfolgreichen Einsatz in der Luftfahrt, werden Checklisten daher seit ca. f unf Jahren vermehrt auch im Klinikalltag – speziell auf den Intensivtherapiestationen und in den Operationssahlten Kliniken evaluiert alen – eingesetzt und wurden bereits in ausgew [HP06; Gaw10]. Checklisten dienen in der Medizin ausschlielich Experten zur Unterst utzung. Jedoch stehen die Bemoder Pronovost (siehe [Lan11]) uhungen von Gawande2 trotz ihres bereits erreichten Erfolges erst am Anfang einer intensiveren Nutzung im medizinischen Bereich. Checklisten sind daher im Klinikbereich noch eher selten verbreitet und deren Verwendung ist  ublicherweise auch nicht P icht (siehe Akzeptanzproblematik in Abschnitt 4.2.5). 2 siehe z. B. Projektweiterf uhrung unter http://www.safesurgery2015.org (abgerufen am 20.12.2013) Checklisten als kognitives Hilfsmittel 4.2.3 Items und Anwendungsmethoden Bei den Items einer Checkliste handelt es sich um sicherheitskritische Aspekte (Schritte, Punkte, Sachverhalte) einer zur Checkliste korrespondierenden SOP. Darunter fallen jedoch nicht nur prozedurale Schritte wie z. B. der Aufbau einer Verletztenversorgung“ oder die " Aktion Informiere X uber die EinsatzlageAuch Aspekte, die nicht direkt Handlungen \. ” eines Prozesses entsprechen, kahlen allgemeine onnen als Items in Frage kommen. Hierzu z Hinweise, die sich auf die Gesamtheit des Prozesses selbst oder aber auf die Einbettung in andere Prozesse beziehen. Die Hinweise Ruhe bewahren!“ oder Weiteres Vorgehen mit der "" Einsatzleitung der Feuerwehr abstimmen!“ sind hierf ur Beispiele. Auch sind in der Praxis Items anzutre en, die auf Dinge hinweisen, die ausdr ucklich nicht getan werden sollen. Ein populur ist das Problem, dass Einsatzkr ares Beispiel hierfafte des Rettungsdienstes die Tendenz zum Abtransport von verletzten Personen haben, da dies ihrem korrekten Vorgehen im Regelbetrieb entspricht. In einer Groschadenslage soll jedoch genau dies zu Beginn unbedingt vermieden werden. Keine Patienten abtransportieren!“ ist " daher ein Beispiel f ur ein Item, das die Einsatzkraft daran erinnern soll, etwas nicht zu tun. Zusammenfassend sollen in dieser Arbeit grob drei Item-Klassen unterschieden werden: 1. SOP-Schritte, die nicht vergessen werden d urfen (die To-Dos), 2. allgemeine Hinweise f ur SOPs, die keinen direkten Aktionen entsprechen, und 3. Schritte, die es unbedingt zu vermeiden gilt (die Not-To-Dos). Obige Item-Klassi kation soll (lediglich) verdeutlichen, dass Items f ur mehr als nur konkrete physische Handlungen stehen k onnen. Jedoch sind die Grenzen zwischen den drei Klassi zierungen ieend. So lRuhe bewahren!durchaus auch als ein asst sich das Item “ ” Prozessschritt au assen. Weiterhin lRuhe bewahren!zu Nicht hektisch werden!\ asst sich “ "” umformulieren, was der gleichen Ursprungsintention entspricht, jedoch nun o enkundig in die Klasse der Not-To-Dos fufen eines kritischen Aspektes kann somit allt. Das Abpr durch verschiedene Item-Formulierungen realisiert werden. Um z. B. sicherzustellen, dass das obige Abtransport-Problem vermieden wird, kann prinzipiell die Form einer Anweisung: Transportstopp aussprechen!“ oder Keine Patienten abtransportieren!\, oder alternativ "" die einer Frage: Wurde Transportstopp ausgesprochen?“ genutzt werden. " Weiterhin lassen sich verschiedene Fragekategorien fdie Itemtexte einsetzten. Ge ur schlossene Fragen kjaoder “ oglichen onnen nur mit “ neinbeantwortet werden und erm "” dadurch eine Verzweigung in z. B. entsprechende Folge-Checklisten, so wie es in Abb. 4.2 rechts angedeutet ist. Nicht alle Aspekte lassen sich mit geschlossenen Fragen abfragen. Mit den sog. o enen Fragen lassen sich Informationen  uber eine Situation vom Checklistenanwender abfragen. Hiermit kann beliebiger Freitext“ als Antwortformat erfasst werden, der ” vor allem bisher zu Dokumentationszwecken genutzt wird. O ene Frageformen f ur Items sind in der Praxis eher selten anzutre en. Im no net jedoch gerade diese achsten Kapitel er Frageform eine nat in einem elektronischen Assistenzsystem. utzliche Funktionalit Bei der Erstellung der Checklisten stellt sich die Frage nach einem geeigneten Vokabular fatzlich zu der Anforderung an eine gute Lesbarkeit sollten die Texte ur die Item-Texte. Zus mazise und unmissverst oglichst prandlich formuliert sein. Obwohl das Vokabular von der jeweiligen BOS-eigenen Organisationskultur und der adressierten SOP abh angt, sollten einige prinzipielle Empfehlungen bei der Wahl des verwendeten Vokabulars beachtet werden. Der Text der Checklisten sollte derart gestaltet werden, dass Missverst andnisse bei der Interpretation durch den Endanwender m oglichst auszuschlieen sind. Checklisten als kognitives Hilfsmittel Ein Blick auf die langj ahrigen Erfahrungen der Luftfahrt, in der der sog. Checklisten Phraseologie ein besonderer Stellenwert zukommt (vgl. Degani & Wiener [DW90]), scheint hierf ur lohnenswert. Auch in der Literatur rund um die Thematik zur Schnittstelle Mensch-Maschine lassen sich grundlegende Empfehlungen nden, die ebenfalls auf die Checklistenerstellung angewendet werden k onnen. So emp ehlt z. B. Krypter [Kry72], den Umfang des Vokabulars motig zu halten, und Wickens [Wic84], oglichst so gering wie n wichtige Woglichst oft einzusetzen. In orter, deren Bedeutung den Anwendern klar ist, m dieser Arbeit soll jedoch nicht weiter auf den Formulierungsprozess der Texte eingegangen werden. F ur mehr Details zu dieser Thematik sei als Einstieg auf die obige Literatur ([Kry72; Wic84; DW90]) verwiesen. Checklisten stellen in der Regel an den Benutzer keine besonderen Anforderungen. Jedoch variiert die Art und Weise ihrer Anwendung von Einsatzgebiet zu Einsatzgebiet bzw. von Organisation zu Organisation. Degani & Wiener [DW93] unterscheiden – orientiert an der Luftfahrt – uhrungsmethoden f prinzipiell zwei Durchf¨ ur Checklisten: 1. Challenge-response (oder challenge-veri cation-response). Die CL dient hier nur“ als ” eine redundante Backup-Prozedur. Zum Beispiel kon guriert der Pilot das Flugzeug aus dem Geduft nachtr achtnis und praglich (nach jedem Schritt bzw. nach einer gesamten Handlungssequenz), ob alle kritischen Punkte beachtet wurden. Hierbei ¨ handelt es sich um eine gewollte Redundanz: erst Gedachtnis, dann Uberpr ufung. 2. Call-do-response (oder Do-list). Die Items einer CL werden eines nach dem anderen durchlaufen\. Diese Methode eliminiert die gewollte Redundanz aus Methode 1 – " mit Vor-und Nachteilen (siehe Diskussion im Abschnitt 4.2.5). In der Praxis sind beide Methoden in Kombination anzutre en, wobei nach Degani & Wiener die Challenge-response Methode die gebr auchlichste Form der Anwendung in der Luftfahrt darstellt [DW93]. Zus atzlich weist Gawande [Gaw10], mit Blick auf die Anwendung von Checklisten in OP-Salen, auf den wichtigen Aspekt der lauten Aussprache“ " jedes Items hin. Er spricht von verbal checklist, wodurch sichergestellt werden soll, dass sich alle im Raum der anstehenden Prozeduren mit all den zu erwartenden Gefahren bewusst werden. Im Cockpit eines Flugzeuges ndet diese laute Aussprache ebenfalls Anwendung, ¨ welche zur gegenseitigen Uberwachung eingesetzt wird und die Teamarbeit f ordern soll. Gawande weist in [Gaw10] und in Interviews darauf hin, dass die Abarbeitung einer Checkliste auf keinen Fall wie eine tick-box exercise“ zu verstehen ist, wer dies trotzdem ” tut, wird der Grundidee und dem Potential von Checklisten nicht gerecht. Schlussendlich variiert die Checklisten-Philosophie von Organisation zu Organisation und spiegelt somit die unterschiedlichen Organisationskulturen wider. Organisationskultur beinhaltet viele Faktoren des gesamten operativen Konzepts der Organisation: traditionelle Methoden der Operationen, vorgegebenen Richtlinien, spezieller Fvon uhrungsstil, Delegation Verantwortung in der Befehlskette sowie Straf-und Disziplinarmanahmen. Neben der Frage der geeigneten Anwendungsmethode kommt der Frage, wann (in welcher Situation) eine Checkliste anzuwenden ist, eine ebenso groe Bedeutung zu. Diese korrespondiert mit der Frage, wann eine SOP einzuleiten ist. Wie Cimolino bez uglich der Standard-Einsatz-Regeln (SER) schreibt (siehe [CG05]), sollte in jeder SER (respektive in jeder SOP) beschrieben werden, wann sie anzuwenden ist. Der beste Zeitpunkt zur Initiierung einer Checkliste ist typischerweise der, wenn der Nutzer gerade im Begriff ist, einen anstehenden Arbeitsprozess zu beginnen, also gerade nicht mit anderen Aufgaben besch aftigt ist [Ros04; BP07]. Wie zum Beispiel vor dem take-off im Cockpit eines Flugzeuges, vor Beginn eines chirurgischen Eingri s im OP oder bei der Fahrt eines Einsatzleiters zum Einsatzort. Checklisten als kognitives Hilfsmittel 4.2.4 Reprasentationsformen von Checklisten Papierbasierte Checklisten (PCLs) gehasentationsformen oren zu den verbreitetsten Repr (siehe Beispiele im Anhang, S. 138 .). Der Vorteil einer PCL liegt in ihrer Einfachheit und ihrer unkomplizierten Handhabung. Sie sind schnell erstellt und leicht zu vervielf altigen. Die Interaktion mit ihnen erfordert keinerlei technische Hilfsmittel noch spezielle Fachkenntnisse – asst man das Wissen uber die dahinter liegenden SOPs auer Acht. l Ihre Einfachheit kann in einigen Anwendungsgebieten jedoch auch nachteilig sein. So stoen papierbasierte Checklisten in verteilten, dynamischen Umgebungen an ihre Grenzen, da ihre Anwendung lokal begrenzt und ihre Informationsdarbietung statisch ist. Zus atzlich stellt sich die Aufgabe, alle sich im Umlauf be ndlichen PCLs aktuell und f ur alle Anwender zugreifbar zu halten. Hinzu kommt, dass PCLs schnell un ubersichtlich werden, wenn die jeweilige SOP eine Realisierung mit mehr als einer Seite erforderlich macht. Zwei zu PCLs alternative Repr asentationsformen sollen im Folgenden skizziert werden. Mechanische Checklisten: Sogenannte mechanische Checklisten sind eine seltene Form einer Checklistenrepr  asentation, die z. B. in der Luftfahrt im Cockpit einiger Flugzeugtypen zum Einsatz kamen und kommen. Wegen ihrer technisch-bedingten Beschrucksichti anktheit, ber gen sie normale“ Standardprozeduren mit wenigen Items, ” wie z. B. fur die Take-Off -und Landing-Prozedur. Als Beispiel ist in Abbildung 4.4 eine mechanische CL in einer Boeing 757 zu sehen. Ein erf ulltes Item quittiert der Pilot mittels eines einfachen mechanischen Kippschalters. W ahrend zu Beginn alle entsprechenden Items der CL au euchten, erlischt nach jedem Umlegen des jeweiligen Schalters die Hintergrundbeleuchtung. Der Pilot hat somit jederzeit alle noch o enen Punkte im Blick, auch wenn er zwischenzeitlich die Aufmerksamkeit weg von der CL richten muss. Selbst wenn der Pilot die Abarbeitungsreihenfolge variiert, wird durch diese Art der Umsetzung ein Vergessen eines fr uheren Items verhindert. Mechanische CLs stellen somit bereits eine einfache M¨ oglichkeit dar, typische Fehler bei der Abarbeitung einer PCL vorzubeugen (vgl. hierzu Abschnitt 4.2.5). Jedoch sind sie in ihrer Flexibilitankt. at und in der Anzahl der Items deutlich beschr Abbildung4.4:TeileinerMCL(Take-O )ineinerBoeing757. Abbildung 4.5: Elektronische Checkliste im Cockpit einer Boeing 777. Checklisten als kognitives Hilfsmittel Elektronische Checklisten: In Zeiten zunehmender Computerisierung liegt die Idee nahe, elektronische Checklisten (ECLs) umzusetzen, die den Anwendern  uber einen Monitor dargeboten werden. Der Computer kann in diesem Fall nicht nur zur bloen Anzeige der CLs genutzt werden, sondern darat durch eine uber hinaus eine erweiterte Funktionalit Kopplung mit beliebigen Informationssystemen erm oglichen. Mit der Einf¨ uhrung moderner sog. Glascockpits in der Luftfahrt wurden in einigen Flugzeugtypen auch ECLs eingef uhrt. In Abbildung 4.5 ist als Beispiel eine ECL des Flugzeugtyps Boeing 777 zu sehen, welche das Ergebnis jahrelanger Forschung und Entwicklung der Boeing Flight Deck Research Group in den sp aten 1980er Jahren war. Im Cockpit sollen ECLs zum einen Fehler bei der Nutzung von PCLs vermeiden helfen und zum anderen durch eine (teilweise) Kopplung des Bord-IT-Systems mit dem ECL-System ihren Einsatz weiter vereinfachen [Boo01a; Boo01b]. Dar uber hinaus beinhalten sie alle normal und not-normal Checklisten des entsprechenden Flugzeugtyps. Vor allem die teils recht umfangreichen Ordner, in denen alle not-normal CLs onnen so ublicherweise abgelegt sind, k eingespart werden. Boeing zog nach einer zehnjumee, ahrigen Einsatzphase ein positives Res sodass sie planten, weitere Flugzeugtypen zuk unftig mit einem elektronischen Checklisten- System auszustatten [Ark06]. So ist z. B. der neue Flugzeugtyp Boeing 787 mit einer neuen  uberarbeiteten Version eines elektronischen Checklisten-Systems versehen [Bra10]. Auch im Klinikbereich wird die Anwendung elektronischer Checklisten seit einigen Jahren vereinzelt diskutiert [Par10], prim ar mit dem Ziel einer Anbindung an das klinikeigene IT-System. Es zeigte sich aber, dass mit steigender Komplexit at solcher Systeme deren Akzeptanz und Bedienbarkeit typischerweise sinkt, wodurch dann der eigentliche Nutzen des Checklisten-Prinzips verloren geht. Nicht zuletzt aus diesen Gr unden sind ECLs daher im Klinikalltag momentan kaum verbreitet [Par10]. 4.2.5 Nachteile und Akzeptanzproblematik Obwohl die Vorteile von Checklisten zur Absicherung kritischer Handlungen unbestritten sind, stehen ihnen einige bekannte Nachteile gegenahrige Praxiser uber. Vor allem die langj fahrung in der Luftfahrt o enbarte, dass deren Einsatz auch zu unbeabsichtigten, negativen E ekten f uhren kann. Hinzu kommt die Tendenz einer geringen Akzeptanz von Checklisten bei Mitarbeitern verschiedenster Bereiche und Ausbildungsgrade. Nachstehend sollen beide kurz vorgestellt werden. Bekannte Nachteile eines Checklisteneinsatzes Die Standardisierung von Prozessen, und daher auch die Abarbeitung strikter Checklisten, kann neben den Vorteilen auch mangelnde Flexibilit at in der Anpassung an auergew uhren [Gro04; HS98]. Langfristig kann dies auch zu einer ohnliche Situationen mit sich f Reduktion der Problemluhren, wodurch eine gewisse an osekompetenz der Benutzer fAbh ” gigkeitsproblematik“ droht. Haben sich die Mitarbeiter erst einmal an die Abarbeitung einer Checkliste gewonnen sie ohne diese pl ohnt, so kotzlich groe Probleme haben, ihre Arbeit korrekt durchzuf uhren. Weiterhin ist bekannt, dass das Vorgehen gem¨ aß zu starrer und detaillierter Checklisten, vor allem in dynamischen Anwendungsf allen, sogar handlungshemmend wirken kann. Die Entwicklung alternativer L osungsstrategien kann dadurch gehemmt und die Handlungsfreiheit ungewollt eingeschr ankt werden [BHL08]. An dieser Stelle sei jedoch angemerkt, dass dieser E ekt durchaus gew unscht sein kann (siehe Abschnitt 4.2.2). Buerschaper & St. Pierre weisen in [BP07] darauf hin, dass sich bei einer erfolgreichen Checklistenbearbeitung moglicherweise ein falschesSicherheitsgef “ uhl einstellt, wo ” durch die Aufmerksamkeit sinkt. Der damit einhergehende Gef uhlszustand kann negative Unterscheidung der Begri e Checkliste und SOP Folgen auf andere kognitive Prozesse der Anwender haben. Als Beispiel nennen die Autoren die Tendenz, bei vermeintlicher Sicherheit einen geringeren Erwartungshorizont aufzuf ogliche kritische Lageentwicklungen eventuell ubersehen oder falsch achern, wodurch m bewertet werden. Zusandnis (Si atzlich kann es daher zu einem sinkenden Situationsverst tuation Awareness, siehe z. B. [BH89]) kommen, da die Aufmerksamkeit f ur Dinge sinkt, die sich auerhalb der eigenen Checkliste be nden. Weiterhin ist bekannt, dass Checklisten, wenn sie falsch eingesetzt werden, die E ektivit achtigen k at der dahinterliegenden Prozesse sogar beeintronnen. In der Luftfahrt sind diesbez uglich eine Reihe von Problemen und Fehlerquellen bekannt (vgl. hierzu [Ros04]). Subjektive Ablehnung Checklisten als Hilfsmittel zur Fehlervermeidung werden in vielen Arbeitsbereichen, so auch im BOS-Bereich, kontrovers diskutiert. Wie sich im SpeedUp-Projekt zeigte, stehen einige Fafte dem Checklisteneinsatz skeptisch bis ablehnend gegen uhrungskruber. Die Skepsis und die Ablehnung hat jedoch weniger objektive als persunde. onliche und emotionale Gr So stellte Gawande fest, dass sich Mitarbeiter durch Checklisten oftmals bevormundet und in ihren Handlungsmankt f oglichkeiten eingeschruhlen [Gaw10]. Keiner der Praktiker will sich gern vorschreiben lassen, was er zu tun und zu lassen hat. Schaut man in die Luftfahrt, so stellt man fest, dass obwohl Checklisten dort am l angsten und erfolgreichsten eingesetzt werden, deren Einsatz teils als lotig empfunden astig und unn wird [Ros04]. Wurden, sehen andere in ihrer ahrend einige Piloten nie ohne sie iegen w Nutzung ein Zeichen von Schw ache. Die Fluggesellschaften haben jedoch Checklisten fest in ihre Sicherheitskultur verankert, sodass die Piloten CLs nutzen m ussen. Im Klinikbereich stuhrung von Checklisten, trotz des nachgewiesenen positi ot die Einf¨ ¨ ven E ektes auf die Uberlebensrate der Patienten [HP06], ebenfalls zu Beginn oftmals auf ¨ Ablehnung bei Arzten und P egepersonal. Sie fragen sich, wie so ein St uck Papier mit ein paar Boxen ihre Arbeit verbessern kann? Die Fronten der Gegner und Bef urworter scheinen verhunde, warum Checklisten in der Medizin artet. Gawande identi ziert drei Hauptgr schwer zu etablieren sind und warum ihnen wenig Aufmerksamkeit zuteil wird [Gaw10]: ¨ 1. Arzte f uhlten sich beleidigt, ihre Egos wurden verletzt. 2. Das P egepersonal sieht sich bereits mit anderen Formularen  uberlastet. 3. Solch banale“ Forschung wird gern zu Gunsten der aufregenderen Themen ignoriert. ” Papierbasierte Checklisten sind daher im Klinikbereich noch bei weitem nicht so verbreitet wie in der Luftfahrt. 4.3 Unterscheidung der Begri e Checkliste und SOP Obwohl oft in einem Atemzug genannt, stellen Checklisten“ und SOPs“ zwei unterschied "” liche (wenn auch verwandte) Konzepte dar. Diese konzeptionelle Trennung wird in der Literatur kaum beachtet, was zu Missverst andnissen in der praktischen Verwendung beider Begri e fahrend SOPs f uhren kann. Wur mehr oder weniger detaillierte operationalisierte Richtlinien stehen, adressieren Checklisten in der Regel ausschlielich kritische Punkte bei der Ausfuglich einen uhrung dieser SOPs. Brabant (siehe [Bra10], S. 43) zitiert diesbez Checklisten-Experten (E. Mahr) von Boeing: A good checklist is precise and lists only " critical steps in a concise way\. Unterscheidung der Begriffe Checkliste und SOP Kontrolle kritischer Checklisten Standard Operating Procedures (SOPs) SOPs machen Leitlinien: Dienstvorschriften, Gesetze, etc. Leitlinien als Rahmen- bedingen bedingen klisten bedingungen Leitlinien operabel Punkte der SOPs Abbildung 4.6: Zusammenhang zwischen Leitlinien“, SOPs und Checklisten. ” Die Vermischung der Begriffe SOP und Checkliste liegt offensichtlich nicht zuletzt darin begr¨ undet, dass eine klare Trennung aller drei in Abbildung 4.6 gezeigten Konzepte in der Praxis oft schwierig ist. So tragen manche konkreten Leitlinien den Charakter von SOPs, w¨asentationen komplexer und ahrend in anderen Bereichen Checklisten als Repr¨ umfangreicher SOPs verstanden und eingesetzt werden. Checkliste dienen als kognitives Werkzeug zur Unterst¨ utzung der Erinnerungsleistung des Menschen und unterscheiden sich dadurch prinzipiell vom Konzept der SOPs. Checklisten repr¨ asentieren in der Regel nur ganz bestimmte kritische Teilaspekte der dahinterliegenden SOPs. Damit die gew¨ unschten positiven Effekte eines Checklisteneinsatzes auch erreicht werden, sollte eine Vermischung beider Konzepte vermieden werden. In Anbetracht einer Erarbeitung der Anforderungen an ein IT-Assistenzsystem empfiehlt sich jedoch, eine strikte Trennung aller drei Konzepte vorzunehmen. Ein wesentliches Merkmal des in dieser Arbeit in Kapitel 5 vorgeschlagenen L¨ osungsansatz soll daher die explizite Trennung der beiden Konzepte SOP und Checkliste sein. Die in dieser Arbeit propagierte Sichtweise unterscheidet sich von der von Becker et al. [BLK11] und von Peinel et al. [PRW12b] (vgl. Abschnitt 3), in denen Checklisten als nur eine M¨ oglichkeit der Darstellung von SOPs angesehen werden bzw. Checklisten einen Workflow (Plan) repr¨ asentieren. Checkliste zu X ..… … … … … ..… … … … … ..… … … … … ..… … … … … ..… … … … … ..… … … … … ..… … … … … ..… … … … … einen einzelnen kritischen Schritt allgemeine Hinweise bei der Abarbeitung einer SOP einen größerer Abschnitt oder Aspekte einer korrespondierenden SOP SOP X Do-Not! Checklisten-Perspektiverspektive Ein Item kann sich beziehen auf: SOP-Perspektive CL enthält „nur“ kritische Bereich einer SOP eine Handlung, die unbedingt vermieden werden sollte Abbildung 4.7: Arten der Korrespondenzen zwischen einer Checkliste und ihrer SOP. Eine CL adressiert in der Regel nur die kritischen Aspekte einer SOP und keine detaillierte Prozessbeschreibung. Abbildung 4.7 illustriert die prinzipielle Vielfalt der Korresponden Unterscheidung der Begri e Checkliste und SOP zen zwischen den Checklisten-Items und den entsprechenden Aspekten (Aufgaben, Schritte, Merkmale, Besonderheiten) einer zugeh origen SOP. Die komplette SOP soll und kann in der Regel nicht durch Checklisten abgebildet werden. Primasentieren die Items kriti ar repr sche (atomare) Schritte (die To-Dos) einer SOP wie zum Beispiel Sichtungszelt aufbauen!\. " Zusonnen Items auf allgemeine Anordnungen (wie z. B. \) hinwei atzlich kRuhe bewahren ” sen sowie auf Aktionen, die auf keinen Fall bei der SOP-Anwendung durchgef uhrt werden sollten (die Not-To-Dos). Spezialfall Luftfahrt: In der stark regulierten Luftfahrt werden die Begri e SOP und Checkliste h au g synonym verwendet. Dies ist in den technischen und hochkomplexen Rahmenbedingungen begr undet, die von den Piloten eine strikte Vorgehensweise abverlangen und die uhrt haben, dass sich die Abarbeitung der Checklisten selbst uber die Jahre dazu gef als ein wesentlicher Prozess (also als eine SOP) verankert hat. Viele SOPs werden in der Luftfahrt aus der Perspektive der Abarbeitung der entsprechenden Checklisten gesehen, obwohl auch dort komplexere SOPs uft werden. Einige hochkritische SOPs decken uberpr sich jedoch fast zu einhundert Prozent mit den entsprechenden Checklisten-Items. Dies ist jedoch die Ausnahme und nicht die Regel, sodass die Trennung beider Begri e in anderen Anwendungsgebieten durchaus ber ucksichtigt werden sollte. Fazit Als eine Strategie des Umgangs mit Komplexit at und der Vermeidung von Unsicherheit wurde die Standardisierung (von Prozessen) aufgef uhrt. Da in einer Groschadenslage bereits kleine Fehler zu fatalen Auswirkungen fonnen, bietet sich im BOS-Bereich zur uhren k Fehlervermeidung auf den ersten Blick die Strategie der Standardisierung an. Wir haben in Kapitel 2 Dienstvorschriften als eine Muhungen kennen gelernt. oglichkeit dieser Bem Jedoch wurde bisher auch deutlich, dass Dienstvorschriften allein noch zu viel Spielraum in der Ausgestaltung aufweisen. Die Einsatzkrussen zum einen exibel reagieren k afte monnen und zum anderen jedoch auch die g ultigen Richtlinien beachten. Sie sollen sich trotz FlexibilitLeitplanken\) bewegen. at in einem gewissen Rahmen (als eine Art " Wie kann ein elektronisches Assistenzsystem diesen beiden Ansprugen? Als uchen gen ¨ Antwort auf diese Frage wird als Grundidee dieser Arbeit die Ubertragung des Checklisten- Prinzips auf den BOS-Bereich vorgeschlagen. Dadurch dass Checklisten nur kritische Aspekte einer SOP bernureine Erinnerungsfunktion anbieten, bleibt die ge ucksichtigen und “ ” wat in den Handlungen erhalten. Die Einsatzkronnen weiterhin frei unschte Flexibilitafte k agieren und sollen durch die Checklisten auf einen groben Handlungsrahmen als Leitplanken aufmerksam gemacht werden. Die restliche Arbeit geht der Fragestellung nach, wie genau eine elektronische Umsetzung des Checklisten-Prinzips im BOS-Bereich realisiert werden kann und welche Merkmale ein entsprechendes Assistenzsystem aufweisen sollte. Hierzu wird im n achsten Kapitel ein Rahmenwerk eines reaktiven Assistenzsystems vorgestellt, das  uber die Fehlervermeidung und ein Prozessmonitoring hinaus, zu einer signi kanten Verbesserungen des gesamten Einsatzmanagements beitragen kann. Kapitel 5 Intelligente elektronische Checklisten-Assistenz Dieses Kapitel stellt ein Rahmenwerk und die Architektur eines intelligenten elektronischen Checklisten-Assistenzsystems vor. ur Das System kann, speziell kon guriert fden BOS- Bereich, den Einsatzkraften eine neuartige Hilfestellung bieten, um Handlungsroutinen sicher und fehlerfreier anzuwenden. Daroglicht der vorgestellte Ansatz ein uber hinaus erm Monitoring der ausgefur jede uhrten und sich in Bearbeitung be ndlichen Handlungen f BOS bzw. fahnlichem Arbeitsumfeld. ur alle Organisationen mit  5.1 Motivation & Anforderungen einer elektronischen Checklisten- Assistenz Inwieweit eine IT-Unterstzur zur utzung Harmonisierung des Einsatzmanagements und Fehlervermeidung beitragen kann, ist eine der Kernfragen dieser Arbeit. In der heutigen BOS-Praxis kommen zwar vereinzelt Computer bei der Administration und Koordinierung ausgew ahlter Aufgabenbereiche zum Einsatz (vgl. Abschnitt 2.4), eine direkte Hilfestellung bez uglich einer fehlerfreien Anwendung von Handlungsroutinen bieten diese jedoch bis heute nicht. Auch haben die bisherigen (meist akademischen) Latze aus dem osungsans Bereich der Prozessmodellierung sowie der automatischen Handlungsplanung ihre deutlichen Schwane zu achen, wenn man versucht, diese Konzepte eins zu eins auf die BOS-Dom ubertragen (vgl. Kapitel 3). Doch was l asst sich tun, wenn sich die Prozesse im Vorfeld nicht zufriedenstellend erfassen lassen bzw. eine klassische (automatische) Handlungsplanung im Kontext einer Groschadenslage nicht praktikabel ist? Eine m ogliche Antwort stellt die Anwendung von SOPs dar. SOPs k onnen zu einer Harmonisierung von Handlungsroutinen beitragen. Jedoch sind sie im Vergleich zu Prozessen oder Handlungspl anen deutlich abstrakter formuliert und er- m oglichen dadurch eine (gewollte) exiblere Anwendung ihrer Handlungsbeschreibungen. Reinwarth de niert eine SOP als eine Beschreibung einer gew unschten Vorgehensweise " bei der Erledigung bestimmter Aufgaben, die m oglichst im Einklang mit operationell logischen Abluhzeitig, dass die aufen steht“ ([Rei07], S. 13). Im SpeedUp-Projekt zeigte sich fr angestrebte (formale) Modellierung derartiger SOPs nicht praktikabel ist, da die dort angewandten SOPs gr otenteils nicht explizit vorliegen. Vielmehr lassen sich im BOS-Bereich kaum niedergeschriebene operationalisierte Handlungsrichtlinien in SOP-Form nden (vgl. Abschnitt 2). Dieser Einsch atzung folgen auch Becker et al. [BLK11] und Peinel et 43 Motivation & Anforderungen einer elektronischen Checklisten-Assistenz al. [PRW12a]. Doch wie lassen sich Fehler (Patzer und Schnitzer) mittels SOPs im BOS- Bereich vermeiden, wenn sich keine expliziten SOPs nden lassen? Vergleicht man die Arbeitsbedingungen des BOS-Bereichs mit denen anderer Hochsicherheitsbereiche, in denen Checklisten seit langer Zeit erfolgreich eingesetzt werden, so lassen sich gemeinsame Charakteristiken feststellen, die f ur einen systematischen Checklisteneinsatz im BOS-Bereich sprechen. Hierzu zat der Handlungsrouti ahlen die Komplexit nen, die Notwendigkeit einer reibungslosen Zusammenarbeit aller Einsatzkr afte (hier wird z.B. in  ahnlichen Bereichen von einer Choreographie aller gesprochen [Gaw10]) und die stetig steigenden Anforderungen an die Einsatzkrussen z. B. die Einsatzkr afte. So mafte der Feuerwehr immer mehr Technik beherrschen und im Einsatzfall immer mehr Spezialwissen abrufen k onnen. Der BOS-Bereich weist jedoch ¨ uberdies Merkmale auf, die eine Anwendung des Checklistenprinzips erschweren bzw. die eine spezielle Anpassung und neue Konzepte der Umsetzung erfordern. Folgende Hauptmerkmale eines komplexen, soziotechnischen Arbeitssystems einer Groschadenslage kommen hierbei erschwerend hinzu. • Dynamik der Einsatzlage. Eine Groschadenslage ist eine hochgradig dynamische Arbeitsumgebung, deren Verlauf schwer vorhersagbar ist. Aufgrund dieser Unvorhersagbarkeit motig, der Lageentwicklung angepasst werden. ussen die Einsatzziele, falls n Einen detaillierten Einsatzplan vorzuhalten, ist daher nur fankte sta ur sehr beschr tische Einsatzlagen und in einer abstrakten Form sinnvoll. • Vernetztheit der Aufgaben. W ahrend z. B. im Cockpit oder im Operationssaal ein Team von Experten eine komplexe Arbeitsaufgabe bewaltigt, wobei in der Regel nur“ ” jeweils eine Checkliste aktiv ist, arbeiten in einem Groschadensfall verschiedene BOS parallel an sich teils bedingenden Aufgaben. Hier stellt sich die Aufgabe, die Vernetzung der SOPs mit zu ber ucksichtigen. • Ggf. geographische Verteilung. Der Einsatzort kann sich uber eine groe Fl ache erstrecken, wodurch eine direkte Face-to-Face-Kommunikation aller beteiligten Einsatzkr afte in der Regel nicht moglichkeit oglich ist. Der Frage nach einer Mzum Informationsaustausch und Abgleich kommt daher zus atzlich eine groe Bedeutung zu, wenn man als Ziel eine Koordination aller Einsatzkr afte verfolgt. Um die oberen zus atzlichen Merkmale zu adressieren, bietet sich eine computerintegrierte Umsetzung von Checklisten an, deren Potential bis heute in der BOS-Praxis kaum ausgeschopft wird (vgl. Kapitel 2). Zudem ergaben Anforderungsanalysen von Notfallmanagementsystemen aus dem zivilen und milit arischen Bereich, dass eine elektronische Checklistenunterstaten eines solchen Assistenz utzung mit zu den wichtigsten Funktionalit systems z ahlen sollte (vgl. [RS08; LI09; WMY11]). Interviews mit Anwendern verschiedener BOS im Rahmen des SpeedUp-Projektes ergaben, dass eine elektronische Checklistenunterstutzung, als ein Hilfsmittel fur Fafte, durchaus gew uhrungskrunscht ist. Die Erkenntnisse von Peinel et al. (siehe [PRW12a]) best atigen diese Erfahrungen. Thesen und Potential Dass ECLs bez uglich PCLs ihre Vorteile besitzen, wurde bereits in der Luftfahrt erkannt. So kann im Gegensatz zu PCLs im Computer eine sehr groe Anzahl von Checklisten hinterlegt und leicht recherchierbar gemacht werden. Fatzlich in ur den BOS-Bereich zus teressant ist die M oglichkeit der Verteilung von Checklisten in einem geogra sch verteilten Einsatzgebiet. Weiterhin kECLs drei typischen Fehlern beim Umgang mit PCLs onnen entgegenwirken ([PD91; Boo01a; Ark06]): Motivation & Anforderungen einer elektronischen Checklisten-Assistenz 1. Vergessen (nach Unterbrechung oder Ablenkung) des aktuellen Items in der Liste. ¨ 2. Absichtliches (der Situation geschuldetes) Uberspringen eines Items und dann vergessen, spuckzuspringen (sog. Wiederaufnahmefehler). ater zu diesem Item zur 3. Item als ausgef“ ur die uhrt/beachtetmarkieren, obwohl dies nicht zutri t. (Gilt f " Items, deren Erf¨ uberpr ullung ein angeschlossenes IT-System automatisch ufen kann.) Werden die besonderen Arbeitsbedingungen einer Groschadenslage bei der Entwicklung von elektronischen Checklisten berachtnisentlastung ucksichtigt, so kann der E ekt der Ged auch im BOS-Bereich hilfreich genutzt werden. Dieser Kernansatz spiegelt sich in folgender Hauptthese dieser Arbeit wider: EineIT-unterstutzteUmsetzungdesChecklisten-PrinzipsistimBOS-Bereichbeson- dersgeeignet,umeinensigni kantenBeitragzurFehlervermeidungundbesserenHandhabungvonKomplexitatimManagementeinerGroschadenslagezuleisten. These1 Neben der Funktion der Fehlervermeidung k onnen computerintegrierte Checklisten einen wesentlichen Beitrag zum Aufbau eines zentralen Lage uberblicks leisten. Jede Interaktion mit einer Checkliste eroglichkeit, Informationen uber den Fortgang o net zugleich die M der Lagebewonnen wichtige Informationen  altigung zu erhalten. Dies kuber den Verlauf kritischer Schritte einer SOP sein. Weiterhin ist es auch m oglich, mit einem Item Informationen uber die Einsatzlage vom Nutzer abzufragen bzw. zuvor annotierte Informationen  beim Check eines Items automatisch zu einem Lagebild zusammenzuf uhren. Dieses Potential f uhrt zu einer weiteren These dieser Arbeit: DieAnwendungvernetztercomputerintegrierterChecklistenkannfureinProzessmo- nitoringgenutztwerden,welcheszusatzlichdemAufbaueinesLagebildesdientundsomitzueinemeinheitlichenLageverstandnis(SituationAwareness)fuhrt. These2 Wird den Einsatzkr¨ ugung gestellt, aften eine elektronische Checklisten-Assistenz zur Verf so erschlieen sich eine Vielzahl weiterer Zusatzfunktionalit aten, die in vielen Bereichen der Einsatzvorbereitung, -durchfonnen (siehe uhrung und -nachbereitung hilfreich sein k Kapitel 7). Bezuglich dieses zus atzlichen Praxispotentials ergibt sich eine allgemeinere, dritte These dieser Arbeit: EineelektronischeChecklisten-AssistenzkannzueinerqualitativenVerbesserungdergesamtenEinsatzabwicklungbeitragen,dieweituberdiepositivenE ektederFehlervermeidungunddesProzessmonitoringshinausreicht. These3 Grundlegende Arbeiten des im Folgenden vorgestellten L osungsansatzes wurden bereits vom Autor in [KGK+10; WKK11; KWB12] einem Fachpublikum vorgestellt und diskutiert. In der BOS-Praxis existieren zurzeit keine vergleichbare checklistenorientierte ITUnterst ahrend einer Groschadenslage den Einsatzkrut utzung, die waften eine Unterst zung vor Ort bietet. Aktuelle Arbeiten von Peinel et al. [PRW12b] und Becker et al. Motivation & Anforderungen einer elektronischen Checklisten-Assistenz [BLK11] zeigen hierfosungsans ur zwar erste Latze auf, skizzieren jedoch bislang deren genaue Umsetzung und vor allem Fragen des dynamischen Systemverhaltens nur recht vage (siehe Kap. 3). Anforderungen an eine elektr. Checklisten-Assistenz f¨ ane ur die BOS-Dom Nach der Analyse der BOS-Dom ane in Kapitel 2, der Sichtung und Bewertung bisheriger Lage in Kapitel 3 und der ausf osungsvorschluhrlichen Betrachtung des Checklistenprinzips in Kapitel 4 werden im Folgenden die sich daraus herauskristallisierten Anforderungen an eine elektronische Checklisten-Assistenz zusammengefasst, die solch ein System leisten bzw. geeignet ber ucksichtigen sollte. 1. Wahlfreiheit gew– ankung bei der Wahl und Abarbeitung ahrleisten Keine Einschr der hinterlegten CLs. Assistenz nur als Vorschlag, der jederzeit ablehnbar ist. Ein exibler Wechsel zwischen verschiedenen Checklisten sollte immer m oglich sein. 2. Organisationsaufbau berahrend einer Groucksichtigen – Der Organisationsaufbau w schadenslage mit seinen unterschiedlichen Arbeitsbereichen sollte sich im Auswahlprozess der CLs widerspiegeln. Eine redundanzfreie Zuordnung der Checklisten zu den unterschiedlichen Arbeitsaufgaben sollte gew ahrleistet sein. ¨ 3. Komplexit– Ubersichtlichkeit der zuat handhaben Damit bei komplexen SOPs die geh¨ origen CLs gewahrt bleibt, sollte das Anlegen und Anzeigen hierarchisch strukturierter CLs m oglich sein. 4. Dynamik berandernde Einsatzlage (z. B. Vorucksichtigen – Reaktion auf die sich ver schlag einer passenden Checkliste zu Gefahrgutlagen, wenn es eine Gefahrgutbeteiligung gibt). Ein Assistenzsystem sollte in seinem Verhalten die Dynamik einer Einsatzlage mit ber ucksichtigen und einen exiblen Umgang mit den computerintegrierten Checklisten erm oglichen. 5. Umgang mit Informationsmangel – Ein CL-System sollte auch bei einem Mangel an (zuverlahrdung, Ausma, Anzahl Verletzter,  assigen) Informationen (Art der Gefortliche Besonderheiten, Gefahren, Lageentwicklung) arbeitsfur unbe ahig sein. D. h., f kannte Lagen kommen abstrakte CLs zum Einsatz, die bei wachsendem Wissensstand immer konkreter werden. 6. Dokumentation – Eine wichtige Forderung der Praxis ist das Protokollieren des gesamten Ablaufes einer Groschadenslage. Neben der rechtlichen Absicherung f ur jede BOS ist eine muckenlose Protokollierung die Grundlage einer jeden Einsatz oglichst l evaluierung. Eine elektronische Checklisten-Assistenz sollte daher auch einen wesentlichen Beitrag zur Einsatzdokumentation leisten. 7. Dokumentenpool als Zusatzinformation – Ein CL-System sollte die bereits existierenden elektronischen Dokumente genau an den Stellen eines Arbeitsablaufes zugreifbar machen, an denen sie beim Anwenden einer SOP n utzlich sind. 8. Einfache Bedienung – Da im BOS-Bereich nicht davon auszugehen ist, dass alle Nutzer erfahren im Umgang mit Computern sind, und da sich die Arbeitsumgebungen und -bedingungen teilweise recht widrig gestalten (wechselnde Lichtverh altnisse, Regen, Schmutz, Kalte, Hitze, Stress), besteht die Notwendigkeit eines m oglichst einfachen Benutzungskonzeptes. Motivation & Anforderungen einer elektronischen Checklisten-Assistenz 9. Einheitliches Vokabular – Ein zentral verwaltetes Vokabular der Einsatzdom ane sollte als Quelle f ur eine einheitliche Begri sverwendung bei den Texten dienen. Missverst arungen sind zu vermeiden. andnisse in den Begri serkl 10. Unterschiedliche Benutzergruppen – Zus atzlich zu den Experten kommen in der Regel auch wenig trainierte bzw. unerfahrene Einsatzkr afte zum Einsatz. Eine elektronische Checklisten-Assistenz muss es auch diesen ermoglichen, die Checklisten mit ihren personalisierten Zusatzinformationen anzureichern und zu nutzen. osungsansatz L Der folgende Teil der Arbeit stellt ein Rahmenwerk eines intelligenten elektronischen Checklisten- Assistenzsystems (im Folgenden kurz Casie1 genannt) vor. Casie er o net ein neues Anwendungsszenario von Computerassistenz, dessen Besonderheit in dem bewussten Verzicht auf eine umfassende Prozessmodellierung zugunsten einer computerintegrierten Umsetzung von Checklisten liegt. Der gewosungsweg stellt somit einen Mittelweg ahlte L zwischen einer vollst andig normativen Handlungsanweisung und dem bloen Vertrauen auf die menschlichen Problemlahigkeiten bei der Ausf osefuhrung von Handlungen dar. Dabei bietet Casie eine Checklisten-Assistenz auch f ur alternative soziotechnische Arbeitssysteme mit  ahnlichen Merkmalen wie die des BOS-Bereiches. Obwohl das Rahmenwerk sich an den Anforderungen des BOS-Bereiches orientiert, adressiert es eine allgemeine Problemklasse. Casie kann neben dem BOS-Bereich auch in alternativen sicherheitskritischen Arbeitsbereichen zu einer Harmonisierung der Handlungsabl aufe und zur Verhinderung von Fehlern (z. B. Ged achtnisfehlern) beitragen. Hierzu bedarf es lediglich einer entsprechenden Kon guration von Casie f ur den entsprechenden Anwendungsbereich (siehe Abschnitt 6.3). Darutzlicher Eigenschaften, die in Kapitel 7 uber hinaus bietet Casie eine Vielzahl n erl autert werden. Das Rahmenwerk beschreibt ein reaktives System, das ein intelligentes“ Systemverhal " ten zeigt. Als intelligent wird hierbei die Fahigkeit des Systems verstanden, sich  uber die Arbeit mit den Checklisten einer sich  andernden Informationslage anzupassen. Das System uberwacht den Fortschritt von Handlungsroutinen und gewinnt somit Wissen  uber seine Umwelt. Zum anderen wird das gewonnene Wissen dazu genutzt, Anwendungskriterien von Checklisten und deren Items zu ufen und somit eine dem aktuellen Wissensstand uberpr angepasste Checklisten-Assistenz zu bieten. Der in dieser Arbeit vorgestellte L osungsansatz hat jedoch nicht den Anspruch, eine Hilfestellung fur eine ur eine detaillierte Einsatzplanung zu geben oder eine Grundlage f umfassende SOP-Modellierung zu sein. Beide Anspr uche sind hinsichtlich der in Kapitel 2 erarbeiteten Charakteristika der BOS-Dom ane unangemessen. Vielmehr sollen die computerintegrierten Checklisten den Einsatzkr aften eine einfache Assistenz zur Vermeidung von Handlungsfehlern an die Hand geben, wobei das Augenmerk nur auf den kritischen Punkten einer SOP liegen sollte. Die vorliegende Arbeit zeigt, dass ein Checklisten-System – frei nach dem Motto keep it simple – mit wenig viel erreichen kann. Vor allem die minimale Interaktion des Nutzers mit dem System, die sich im Wesentlichen auf das Aufrufen und Abhaken von Items beschraften von PCL her gut vertraut und ankt, ist den Einsatzkr entspricht der Anforderung nach einen einfachen Benutzungskonzept. Zudem f ordert eine einfaches Bedienkonzept die Akzeptanz des Computereinsatzes im BOS-Umfeld. In der weiteren Arbeit wird vorausgesetzt, dass ein robustes Basiskommunikationssystem verfat einer elektronischen Checklisten-Assistenz aufbau ugbar ist, auf das die Funktionalit 1 Der Name Casie wurde aus dem Akronym IECAS (intelligentes elektronisches Checklisten-Assistenz- System) abgeleitet und ist angelehnt an das irische Wort casey (umsichtig\, wachsam\). "” Grundlegende Konzepte und Designentscheidungen en kann. Wie genau solch ein robustes und exibles Kommunikationssystem aufgebaut ist und wie es im Detail arbeitet, ist daher nicht Gegenstand dieser Arbeit. Das im Rahmen des SpeedUp-Projektes entwickelte prototypische Kommunikationssystem ist zum Beispiel ein solches Basissystem, das gemortlichen Bedingungen eine robuste  aß den technischen und und exible Datenkommunikation zwischen geogra sch verteilten Einsatzkrog aften erm ¨ licht. Dessen prinzipielle Praxistauglichkeit konnte auf zahlreichen Ubungen unter Beweis gestellt werden. Die allgemeinen Anforderungen und das prinzipielle Potential eines solchen Basissystems wurden in Wucholt et al. [WMY11] erarbeitet. Auf die Aufgabe der Checklistenerarbeitung (siehe Abschnitt 6.3) und der Umsetzung einer geeigneten Benutzerschnittstelle (siehe Abschnitt 6.1.1) wird nur am Rande eingegangen. Ohne Zweifel sind beides Problemstellungen, deren erfolgreiche Bearbeitung mageblich den Praxiserfolg eines hier beschriebenen Systems mitbestimmt. Da beide Thematiken jedoch eigenst andige Forschungsgebiete betre en, wird auf deren Bearbeitung zugunsten der Darstellung der Kernkomponenten und der Funktionsweise einer intelligenten elektronischen Checklisten-Assistenz verzichtet. Der Autor ist sich bewusst, dass die Anwendung von IT im BOS-Bereich f ur die Anwender eine groe Herausforderung darstellt. Des Weiteren ist davon auszugehen, dass sich neue Paradigmen und Technologien im  o entliche Bereich der BOS eher mittelfristig durchsetzen werden. Hinzu kommt, dass die Idee, in der BOS-Praxis verst arkt Computer einzusetzen, nicht nur auf Befot. So besteht z. B. bei den Einsatzkrurchtung, urworter staften die Bef sich von der IT abhoglichkeit des exiblen Handelns zu verlie angig zu machen und die M ren. Da der BOS-Bereich ein Arbeitsgebiet ist, das exibles Handeln notwendig macht, darf diese Freiheit durch ein Assistenzsystem nicht eingeschr ankt werden. Es ist daher unangebracht, zu regulierend in die Handlungsroutinen einzugreifen. Eine Handlungsassistenz, die lediglich grobe Leitplanken bietet, so wie das gute Checklisten tun sollten, ist der schwierigen Arbeitsumgebung und den Anforderungen einer Groschadenslage eher angemessen als eine zu detaillierte, starre Handlungsanweisung. Da Checklisten den Einsatzkr aften jedoch nicht direkt ihre Entscheidungen abnehmen sollen, sondern vielmehr zur Absicherung und Entlastung dienen, kuhrungskr onnen sich die Fafte auf das Wesentliche (das Neue) einer Einsatzlage konzentrieren, ohne dabei die SOPs aus den Augen zu verlieren. 5.2 Grundlegende Konzepte und Designentscheidungen Dieser Abschnitt stellt die Grundlagen der elektronischen Checklisten-Assistenz und die Designentscheidungen der Casie-Architektur vor. Bevor der Aufbau und die Funktionsweise von intelligenten elektronischen Checklisten erl autert wird, wird zuvor das Konzept der Rollen eingef uhrt. Darauf folgend werden die wichtigsten Aspekte der Checklisten und Items erarbeitet und der Ansatz vorgestellt, wie Komplexit at mittels Hierarchien gehandhabt werden kann. Dabei bezieht sich der Abschnitt auf verwandte Aspekte der HTN-Planung und auf Theorien der Handlungsregulation. Der Abschnitt erl autert die hierarchische Verkn oglichkeiten der Checklistenzuordnung zu den upfung einzelner CLs und diskutiert die M Einsatzlagen. Das Ende dieses Abschnittes motiviert den Einsatz eines standardisierten Vokabulars zur einheitlichen Begri sverwendung. 5.2.1 Rollen und Rollen ubernahme in einem Einsatz Der Organisationsaufbau in einem Groschadensereignis ist unter anderem durch eine Aufteilung in unterschiedliche Arbeitsbereiche (z. B. in die sog. Einsatzabschnitte) charakte Grundlegende Konzepte und Designentscheidungen risiert. Fdiese sind bestimmte Aufgaben-und Verantwortungsbereiche de niert (vgl. ur Abschnitt 2). Jede Einsatzkraft nimmt in einem Groschadensereignis – wie auch im Alltagsbetrieb – eine bestimmte Position im Team ein, wie z. B. Einsatzleiter Rettungsdienst\, " Leitender Notarzt (LNA)“ oder Leiter Unterabschnitt Verletztenablage\. "" Die Benennung jeder der Aufgaben-und Verantwortungsbereiche wird in dieser Arbeit als Rolle bezeichnet. Der Name einer Rolle stellt eine Art Signalwort dar, das die Einsatzkraft mit einem ganz bestimmten Aufgabenbereich verbindet. Um die Rollen geeignet im Computer zu repr asentieren, werden in dieser Arbeit neben den Namen weitere grundlegende Merkmale einer Rolle formalisiert. In Casie ndet folgende De nition einer Rolle Anwendung. De nition 2 (Rolle) Die unterschiedlichen Positionen, die die Aufgaben in einem Arbeitsbereich bez uglich einer Einsatzkraftverteilung strukturieren und die eine Einsatzkraft  ubernehmen kann, heien Rollen. Die Menge aller Rollen wird mit R bezeichnet. Eine Rolle r 2R ist charakterisiert durch folgende Bestandteile: • name(r) – steht f ur einen eindeutigen Namen der Rolle r. • nc(r) steht fassige Anzahl (Kardinalit – ur die maximal zulat) zuzuordnender Einsatzkr  afte. • org(r) – ur eine konkrete Organisation (BOS-Instanz), der die Rolle r zuge steht f¨ ordnet ist und • desc(r) – ur eine nat steht furlichsprachliche Beschreibung der Verantwortungs-und Aufgabenbereiche der Rolle r. Es gibt Rollen, die kaften zugeordnet werden, z. B. \ onnen mehreren EinsatzkrMaschinist ” oder Rettungsassistent“ (RA) oder aber Rollen, die nur ein einziges Mal besetzt werden, " zum Beispiel die eines Leitenden Notarztes“ (LNA). Durch die Angabe von nc kann dies ” ¨ genau festgelegt werden. In Casie kann durch eine strikte Uberwachung der Kardinalit at sichergestellt werden, dass bestimmte Aktionen eines Aufgabenbereiches nicht versehentlich mehrfach eingeleitet werden. Die Angabe der Organisation (org) ist zur zus atzlichen Abgrenzung der Rollenkonzepte unterschiedlicher BOS notwendig, da es hier (wenn auch selten) zu Bedeutungsabweichungen bez uglich der Rollennamen kommen kann. Somit lassen sich Rollen verschiedener BOS in einer Groschadenslage zusammenf uhren und un¨ terscheiden. Uber das Merkmal desc kann eine Rollenbeschreibung angegeben werden, die zum einen hilfreich bei der Modellierung aller Rollen im System ist und zum anderen als zus atzliche Informationsquelle im Einsatz (zur runtime) genutzt werden kann. Beispiel 1 Sei r1 2R die Rolle eines Organisatorischen Leiters Rettungsdienstes (OrgL) (vgl. Abschnitt 2). Dann kann die Rolleninstanz r1 z. B. folgende Auspr agung haben: name(r1)= Organisatorischer Leiter Rettungsdienst (OrgL)\, " nc(r1)= 1, org(r1)= Deutsches-Rotes-Kreuz Jena\, ” desc(r1)= Der Organisatorische Leiter unterst¨ utzt den Leitenden Notarzt (LNA), in " dem er organisatorische Fubernimmt. uhrungs-und Koordinationsaufgaben Er ist gegen uber dem Personal des Rettungsdienstes und den sonstigen zur rettungsdienstlichen Versorgung eingesetzten Kraften weisungsbefugt.\. Grundlegende Konzepte und Designentscheidungen ¨ Ubernimmt eine Einsatzkraft ein Aufgabengebiet, so kann dies in Form einer Rollenzuordnung gemuckt werden. Eine Rollenzuordnung aß der jeweiligen Rollende nition ausgedr sei de niert als eine Relation a . W R, wobei W f ur die Menge aller im Einsatz aktiven Einsatzkrogliche Rolle eines OrgL. Eine konkrete afte steht. Beispiel 1 zeigt eine m Rollenzuordnung kann dann wie folgt ausgedruckt werden:  (Peter M uller\, r1). ” Die explizite Verwendung des Begri es Rolle ist im BOS-Bereich jedoch wenig gel au g. Im Rahmen des SpeedUp-Projektes wurde er als Konzept der Einteilung der unterschiedlichen Aufgabenbereiche eingef uhrt (siehe hierzu z. B. [GKM+11]). Obwohl sich Rollen auf allen Ebenen der Organisationsstruktur einer BOS nden, wird sich in dieser Arbeit auf die speziellen Rollen der Fuhrungskrafte konzentriert, da die Fafte die prim uhrungskrare Zielgruppe des Assistenzsystems darstellen. Daronnen in Casie prinzipiell uber hinaus k alle denkbaren Rollenausprucksichtigt werden. agungen ber Spezialisierung Instanziierung Abbildung 5.1: Beispiel einer de nierten Rollenstruktur (aus [BOS-O]). Die im Beispiel 1 adressierte Rolle des OrgL wird in der Regel nur durch eine einzige Einsatzkraft  ubernommen. Abbildung 5.1 zeigt ein Beispiel eines Rollenstruktur, die sich so (oder so ahnlich) in der BOS-Praxis manifestiert. Zusur die Rolle \ atzlich ist fNotarzt ” ein Beispiel fafte ur eine Mehrfachbelegung dieser Rolle zu sehen, d. h., mehrere Einsatzkrur sich die Rolle eines Notarztes. Weiterhin sind einige Beispiele f ubernehmen jeweils fur Rollen-Spezialisierungen (bzw. Verallgemeinerungen) gegeben. So umfasst die abstraktere Rolle einer F uhrungskraft untergeordnete Rollen wie z. B. die des OrgL, Einsatzleiters und ¨ LNA. Es zeigt sich eine Ahnlichkeit zu der F uhrungsstruktur in einer Groschadenslage (vgl. Kapitel 2), die im weiteren Verlauf f ur die Zuordnung der Checklisten zu den Einsatzbereichen wichtig ist. Da die unterschiedlichen Rollen den jeweiligen Aufgaben-und Verantwortungsbereich (mehr oder weniger) klar de nieren, stellen sie einen geeigneten Ausgangspunkt f ur die Zuordnung der Checklisten zu den aufgabenspezi schen SOPs dar (siehe Abschnitt 5.2.5 weiter unten). In der Regel werden Rollen nur von den Einsatzkr aften eingenommen, die auch eine entsprechende Quali kation fuhrer (GF) der ur diese besitzen. So hat z. B. ein Gruppenf Feuerwehr oder ein Rettungsassistent (RA) auf einem Notarzteinsatzfahrzeug (NEF) durch eine Ausbildung seine fachliche Eignung f ur die jeweilige Rolle zuvor erworben. Ein leitender Notarzt (LNA) oder ein organisatorischer Leiter Rettungsdienst (OrgL) verf ugt zudem Grundlegende Konzepte und Designentscheidungen atzliche Ausbildung als Fuber spezielle uber eine zusuhrungskraft. Da nicht alle Mitarbeiter  Fugen, kommt es jedoch in der Praxis ab und zu vor, dass Mit uhrungsquali kationen verf arbeiter ohne entsprechende Quali kation eine Fuhrungsrolle – typischerweise zu Beginn einer Groschadenslage – ussen, bis die entsprechend quali kommissarisch einnehmen m zierten Einsatzkrau g jede Einsatzkraft nach ihrer afte eintre en. Auch wird nicht zwangsl maximalen Quali kation eingesetzt. Eine Rollenzuordnung spiegelt daher nicht zwangsl au g die Quali kation einer Einsatzkraft wider, sondern lediglich deren eingenommene Rolle im Team. Das Konzept der Rolle ist daher von dem der Quali kation zu unterscheiden. 5.2.2 Charakteristische Merkmale von Checklisten und SOPs Um die Unterschiede (vgl. Abschnitt 4.3) und Gemeinsamkeiten der Konzepte SOP und Checkliste herauszuarbeiten, wird im Folgenden eine typische Struktur einer SOP de niert, von der dann die entsprechende Struktur von Checklisten abgeleitet wird. SOPs werden zwar in Casie nicht direkt hinterlegt, jedoch verfolgt die Arbeit das Ziel, die Korrespondenz beider Konzepte auch formal repronnen. In einem sp asentieren zu kateren Abschnitt (siehe Abschnitt 6.3.2) wird die sich daraus ergebende Muck oglichkeit einer Rubersetzung von Checklisten zu (Teil-)Prozessmodellen einer SOP motiviert. Eine SOP formal zu erfassen, wird nicht zuletzt dadurch erschwert, dass in der Praxis kein Konsens daruberhaupt beinhalten sollte uber besteht, welche Informationen eine SOP  und wie diese strukturiert sind. Vor allem aus dem angels achsischen Raum stammt eine Vielzahl von Vorschl agen, wie SOPs zu erarbeiten sind und wie sie aufgebaut sein sollten (siehe hierzu z. B. [FEM99; Gru03; CG05; DHS06]). Diese Vorschl age unterscheiden sich mehr oder weniger stark voneinander, was auf die unterschiedlichen Einsatzgebiete und die vielfuckzuf altigen Au assungen davon, was alles unter einer SOP zu verstehen ist, zuruhren ist. Nichtsdestotrotz zeigen diese Arbeiten, dass SOPs strukturelle Invarianten besitzen sollten. Die vorliegende Arbeit orientiert sich an der Herangehensweise von Cimolino [CG05], welche sich an der Struktur sogenannter Verfahrensanweisungen aus dem Bereich des Qualit  atsmanagements (QM) ausrichtet. Die folgende De nition soll den Anforderungen einer Checklistenableitung Gen uge leisten: De nition 3 (SOP) Eine operationalisierte Arbeitsanweisung, die eine (gem aß den Vorschriften und Richtlinien) gew unschte Vorgehensweise bei der Erledigung bestimmter Aufgaben beschreibt, heit SOP. Sei P die Menge aller SOPs in der Dom ane. Eine SOP p 2P wird durch folgende Merkmale charakterisiert: • name(p) – steht f ur den eindeutigen Namen der SOP, • org(p) – bezeichnet die Organisation, in deren Einsatzbereich die SOP f allt, • pur(p) – steht furlichsprachliche Beschreibung des Zweckes der SOP, ur eine nat • r(p) – erlur welche Rolle(n) (bzw. Rollengruppen) die SOP g autert klar, fultig ist, • app(p) – beschreibt, wann (in welcher Situation) die SOP angewendet werden sollte, • desc(p) – steht furlichsprachliche) detaillierte Beschreibung der Prozedur, ur eine (nat • notes(p) – steht (optional) f ur eine Menge von Hinweisen auf besonders zu beachtende Sachverhalte in der SOP, und • term(p) – ur eine unmissverst steht (optional) fandliche Beschreibung wichtiger Begri e und Abk urzungen, die in desc, pur und notes relevant sind. Grundlegende Konzepte und Designentscheidungen Die Beschreibung (desc) des Prozesses stellt den Kern einer SOP dar. Die M oglichkeiten einer geeigneten Formalisierung und Strukturierung sind hierbei so vielf altig wie die Anwendungsgebiete und die Organisationen selbst. Zus atzlich machen es regionale Eigenheiten sowie pers onliche Vorlieben schwierig, eine einheitliche Struktur der Beschreibung desc festzulegen. In Casie wird daher bewusst nicht der Versuch unternommen, diese Beschreibung detailliert zu formalisieren, so wie es teils in den in Kapitel 3 vorgestellten Arbeiten versucht wurde. Vielmehr soll obige De nition den Weg zu einer geeigneten Checklistende nition bereiten, in der die Korrespondenz zu den strukturellen Invarianten einer SOP Beachtung ndet. Beispiel 2 Als Beispiel p1 einer SOP dient das Vorgehen bei Ausl osen einer Brandmeldeanlage aus der Feuerwehrpraxis (siehe [StadtVS06], S. 33 .). Es kur p1 onnte dann z. B. f gelten: name(p1) = "Brandmeldeanlagen\, org(p1) = "Freiwillige Feuerwehr Villingen-Schwenningen\, pur(p1) = "Vorgehensbeschreibung und Hinweise bei Auslosung einer Brandmeldeanlag e fur die taktische Grundeinheit der Gruppe\, r(p1) = "Gruppenfuhrer FW\, app(p1) = "Bei Alarm einer Brandmeldeanlage\, desc(p1) = (siehe [StadtVS06], S. 33-37), notes(p1) = (siehe [StadtVS06], S. 33-37), term(p1) = "BMA – Brandmeldeanlage; BMZ – Brandmelderzentrale; ¨ UE – ¨ Ubertragungseinrichtung ; FBF – Feuerwehr-Bedienfeld; FAT – Feuerwehr-Anzeigetableau; FSD – Feuerwehr Schlussel Depot“ . . Beispiel 2 zeigt Teile einer SOP-Beschreibung aus dem Feuerwehrbereich. Das Merkmal term(p1) beinhaltet in diesem Beispiel nureine Erl “ auterung der in der Beschreibung ” desc(p1) und in den Hinweisen notes(p1) verwendeten Fachbegri e. Auf eine detaillierte Angabe von desc und notes wurde aus Platzgr unden verzichtet und auf die entsprechende Quelle verwiesen. Zuf alligerweise sind in der Beispiel-SOP die Hinweise (notes) in Form einer Checkliste (siehe Anhang, Seite 138) gegeben. Im Allgemeinen k onnen diese Hinweise jedoch eine beliebige Form (Freitext, Stichpunkte oder Kombination aus beiden) aufweisen. Gerade mit Blick auf die Erarbeitung computerintegrierter Checklisten, die mehr bieten sollen als nur eine bloe Au istung von Items, spielen die Metadaten (gemeint sind alle obigen Merkmale auer desc) einer SOP eine wesentliche Rolle dabei, die jeweiligen Checklisten zur aktuellen SOP zuzuordnen, und bei der Realisierung eines dynamischen und exiblen Systemverhaltens. Bevor auf die Items als wesentlichste Elemente einer Checkliste genauer eingegangen wird, soll im Folgenden deren Struktur unter Beachtung der zuvor erarbeiteten SOP- Korrespondenz de niert werden: De nition 4 (Checkliste) Eine Liste kritischer Aspekte einer SOP heit Checkliste. Eine Checkliste cl ist charakterisiert durch folgende Bestandteile: • name(cl) – steht f ur einen eindeutigen Namen von cl, • org(cl) – steht fallt, ur den Organisationsnamen, in deren Einsatzbereich cl f Grundlegende Konzepte und Designentscheidungen • pur(cl) – steht furlichsprachliche Beschreibung des Zweckes von cl, ur eine nat R(cl) – steht f ur die Menge von Rollen, in deren Kontext cl beachtet werden muss, K(cl) – steht (optional) f ur eine Menge von Anwendungskriterien, d. h. Kriterien der Umwelt (Einsatzlage), die die Anwendung der Checkliste indizieren, I(cl) – ur eine Menge kritischer “ (Items ist ein Paar (, ), wobei F fAspekte " genannt) einer zu cl zugehur eine Menge von Ordnungsconstraints origen SOP und . f¨ ¨ uber F steht. • stat(cl) – steht f ur einen Bearbeitungszustand aus finactive, active, complete, canceledg. Die Merkmale name, org und pur entsprechen den gleichnamigen Merkmalen einer SOP (siehe Def. 3). Die Menge R(cl) aller fahlung ur cl relevanten Rollen entspricht der Aufz der Rollen r(p) einer SOP. Durch die Einf uhrung der Menge R soll ein expliziter Bezug auf die formalen Rollende nitionen genommen werden. Weiterhin entspricht die Menge der Anwendungskriterien K der Menge app einer SOP. Jedoch soll in Casie, mit Blick auf eine computerverarbeitbare Situationsbeschreibung, die Angabe der Anwendungskriterien K in einer formalen und praziseren Form als nurin einer nat “ urlichsprachlichen Beschreibung ” maheres hierzu folgt im Abschnitt 6.3, in dem der Aufbau und die Nutzung oglich sein. N einer formalen Wissensbasis thematisiert werden. Die Struktur I, bestehend aus der Menge der Items und optional einer Menge von Ordnungsrelationen  uber den Items, stellt den Kern einer jeden Checkliste dar. Obwohl die Items typischerweise in Form einer Liste organisiert sind, bietet Casie die Moglichkeit der Angabe einer partiellen Ordnung  uber den Items. ¨ Uber die Angabe der partiellen Ordnung () kann eine gewunschte Ausf uhrungsreihenfol ” ge“ der Items festgelegt werden. Dadurch ist es mangigkeit oglich, eine zeitlich-kausale Abh kritischer SOP-Punkte zu reproglicht eine exible Formulierung der asentieren. Das erm Reihenfolge und der spuberwachung der Item-Checks. ateren System In Abgrenzung zu einer einfachen Abbildung von papierbasierten Checklisten in einem Computer wird im Folgenden unter einer intelligenten elektronischen Checkliste (kurz intelligente CL oder ICL) eine computerintegrierte Umsetzung einer (papierbasierten) Checkliste verstanden, die mittels einer gra schen Benutzerschnittstelle dem Benutzer eine Interaktion (Abhaken) mit der Liste ermatzlich die folgenden oglicht (analog zu ECLs) und zus Merkmale aufweist: ¨ 1. Ausfuberwachung von Items (Vergessen/ Uberspringen von Items verhindern), uhrungs 2. Situationsorientierte, dynamische Anpassung der Items an die Einsatzlage, 3. Handhaben der Komplexit at durch Hierarchien von Checklisten/Items und 4. Vernetztheit der Checklisten untereinander, auch  uber Rollengrenzen hinweg. Eine ICL bietet daher mehr als eine bloe Speicherung einer statischen Liste von Items im Computer, die auer der M oglichkeit des Anzeigens und des Abhakens der Items keine weitere Funktionalit at aufweist. Jede Checkliste langig davon, asst sich in der Regel genau einer SOP zuordnen, unabh ob die jeweilige SOP explizit (formal erarbeitet) oder implizit (in den K opfen\) vorliegt. ” Dieser Zusammenhang soll in dieser Arbeit als Prozesskontext, kurz PK, bezeichnet werden. Sei C die Menge aller Checklisten, so lur jedes Element aus C ein entsprechender asst sich f Prozess aus P zuordnen. Grundlegende Konzepte und Designentscheidungen In der Praxis ist zu erwarten, dass, nicht zuletzt durch die f ur PCLs gewohnte und daher pr aferierte Challenge-Veri cation-Response Bearbeitungsmethode (vgl. Abschnitt 4.2.3), in der Regel von den Anwendern eine totale Ordnung der Items gew ahlt wird. Jedoch kann f ur ICLs der Freiheitsgrad bei der Angabe der Itemreihenfolge durchaus von Vorteil sein. So kann z. B. in Anwendungsgebieten mit einer Vielzahl zeitlich ausgedehnter und voneinander unabh angiger Aktionen deren parallele Abarbeitung sich in einem entsprechenden Freiheitsgrad in der vorgeschriebenen Reihenfolge der zugeh origen Items widerspiegeln. Zus atzlich kann das Problem, dass eine feste Itemreihenfolge von den Anwendern als zu einengend empfunden wird, somit falle entsch ur einige Einsatzfarft werden. Ob und wie eine Angabe einer Halbordnung der Items relevant ist, h angt jedoch einzig und allein von der jeweiligen zur CL korrespondierenden SOP ab. Der Bearbeitungszustand einer ICL wird durch einen der vier Zust ande inactive, active, complete und canceled reprur andig bearbeitet“ und asentiert. Neben active fnoch unvollst ” complete fur abgeschlossenl “ asst sich uber den Status canceled ein gewollter Abbruch " der Bearbeitung ausdr ucken. ICLs, die noch keiner Einsatzkraft zur Bearbeitung zugeordnet wurden, gelten als inactive und werden im Folgenden auch als CL-Schema bezeichnet, da erst eine sp atere Einsatzsituation die konkrete Instanz einer Checklistenhierarchie bestimmt. Die Erstellung dieser Schemata obliegt den jeweiligen BOS. Auf Fragen der Erarbeitung der ICL, speziell der Erarbeitung der kritischen Punkte einer SOP, wird in Abschnitt 6.3.2 eingegangen. Das Problem inkonsistenter Ordnungsconstraints, das bei einer unsachgemaher aen Erstellung von ICLs auftreten kann, soll in dieser Arbeit nicht n betrachtet werden. Vielmehr wird im Weiteren davon ausgegangen, dass die Item-Ordnung () keine widerspralt. uchlichen Elemente enth Kommen wir nun zu den Items als wesentliche Bestandteile einer Checkliste. Obwohl jedes Item im Prinzip jeden erdenklichen, als kritisch erachteten Aspekt (Punkt, Sachverhalt) einer entsprechenden SOP repr asentieren kann (vgl. Abb. 4.7), lassen sich Invarianten in ihrer Auspr agung und ihren Intentionen erkennen. Nach der Sichtung typischer Checklisten aus der Praxis (siehe z. B. im Anhang, S. 138 .) und auf Basis der Analyse aus Kapitel 4 wird mit Blick auf die angestrebte Funktionalit at des Assistenzsystems folgende Unterscheidung in drei Itemtypen gew ahlt: Hinweis (note-Item) – soll den Anwender an einen allgemeinen Sachverhalt erinnern. Hinweise betre en Meta-Aspekte der Abarbeitung, zu denen z. B. die bereits erw ahnten Not-To-Dos z ahlen. Beispiele sind: . Keine hohen Hindernisse in der Nahe des Landeplatzes. und . Ruhe bewahren! Aktion (action-Item) – ur eine konkrete Aufgabe (einen Prozessschritt) in einer steht f¨ SOP und soll sicherstellen, dass diese Aufgabe ausgef¨ uhrt bzw. delegiert wird. Beispiele hierf ur sind: . Ruber Lage! . Hubschrauberlandeplatz einrichten! uckmeldung an RLS und Hinter jedem dieser Items verbirgt sich eine konkrete bzw. abstrakte Aufgabe (Task). F ur abstrakte (komplexe) Tasks, die auf eine eigene Sub-SOP referenzieren, kann (falls de niert) zur Konkretisierung eine eigens f ur diese Unteraufgabe zugeschnittene ICL bereitgestellt werden (siehe Abschnitt 5.2.3, S. 57 .). Geschlossene/O ene Frage (query-Item) – Geschlossene Fragen sollte der Anwender schnell und zweifelsfrei (mit ja oder nein) beantworten k onnen. Zum Beispiel: Grundlegende Konzepte und Designentscheidungen . Anzahl der Notarzte ausreichend? ja/nein und . Ist Gefahrgut involviert? ja/nein O ene Fragen konnen hingegen beliebige Informationen  uber die Einsatzlage abfragen. Die Informationen kdann weiteren Steuerung der ICL-Darbietung onnen zur bzw. zur Gewinnung eines Lagebildes genutzt werden. Ein Beispiel ist: . Erste Schatzung  uber die Anzahl Verletzter: ... ¨ Uber o ene Fragen katen eines bestimmten Konzeptes (Anzahl Schwerver onnen Quantit letzter oder Anzahl der Rettungsmittel vor Ort) abgefragt werden. Aber auch Fragen bez oglich. So kann z. B. die Frage uglich qualitativer Eigenschaften von Konzepten sind m nach der Art eines Gefahrsto es durch die Angabe seines Namens beantwortet werden. Denkbar sind weiterhin auch Fragen, die nur durch einen Freitext beantwortet werden kur diese ist jedoch eine sp onnen. Fatere automatische Auswertung im Computer nicht ohne Weiteres muber hinaus haben Praxistests des SpeedUp-Systems gezeigt, oglich. Dar dass im Ernstfall wenig Zeit fangeren Informationen in Freitextform ur das Eintippen von l bleibt. W ahrend bei klassischen PCLs die Checks und die niedergeschriebenen Antworten der Dokumentation und/oder zur Erinnerung f ur den Anwender dienen, erschliet sich in ICLs die Moglichkeit, gezielt Informationen  uber die Einsatzlage durch entsprechend vorbereitete ICLs f ur ein Computersystem bereitzustellen. Die Beachtung unterschiedlicher Item- typen und deren Abarbeitungsstatus erm oglicht einen qualitativen Sprung einer Checklistennutzung, verglichen mit dem, was mit klassischen PCLs erreicht werden kann. F ur die Einsatzleitung konnen wichtige Informationen  uber den Verlauf des Einsatzes mit Hilfe des Computers zu einem Lagebild verarbeitet werden. Um eine erweiterte Ausf uhrungs uberwachung der Items zu erreichen, werden die Items in einer entsprechenden Struktur reprur, dass Casie im Einsatz er asentiert. Folgende Itemde nition legt die Grundlage daf weiterte qualitative Aussagen  uber den Bearbeitungsstand der Checklisten und somit den Verlauf des gesamten Einsatzes erhalten kann. De nition 5 (Item) Die Listenelemente einer Checkliste heien Items. Ein Item f zeichnet sich durch folgende Merkmale aus: • text() – ur einen stichpunkthaften Informationstext (f steht fur die Anzeige in der Benutzerober  ache vorgesehen), der einem kritischen Aspekt einer SOP entspricht, • desc() – steht fuhrlichere Erl ur eine (optionale) ausfauterung von text(), • res() steht f – ur eine Menge optionaler Zusatzressourcen (Dokumente, Tabellen, Abbildungen), • type() – steht f ur dessen Typ faction, note, queryg, • stat() – steht f ur einen Bearbeitungsstatus fopen, inprogress, done, cancel, fail, ignorg, Sub() – steht (optional) fullung ur eine Menge von Sub-Checklisten, die je nach Erf ihrer Anwendungskriterien f entsprechend weiter konkretisieren k onnen, • P re() – steht (optional) f ur eine Menge an Vorbedingungen, und • Eff() – steht (optional) f ur eine Menge von E ekten (Merkmalen), die in der Einsatzlage explizit gelten, nachdem das Item best atigt wurde. Grundlegende Konzepte und Designentscheidungen Im Folgenden werden die einzelnen Strukturelemente der De nition 5 nautert. Wenn aher erl im weiteren Verlauf dieser Arbeit von CLs oder ICLs die Rede ist, ist genau obere CL-und Itemstruktur gemeint. Neben der klassischen Angabe eines Itemtextes (text) erm oglicht die Angabe von Zusatzinformationen (desc) und Dokumenten (res) selbige genau an den Stellen im Arbeitsablauf einer SOP zug anglich zu machen, an der sie im Einsatz auch relevant sind. Von besonderer Bedeutung in Casie ist der Typ eines Items. Die in dieser Arbeit vorgenommene Klassi zierung der Items in action-, note-und query-Item ist das Ergebnis einer Analyse zahlreicher PCLs, die der Autor im Rahmen dieser Arbeit gesichtet hat. So k onnen in Casie Items angemessen ber ucksichtigt werden, die mit einer Aktion korrespondieren (action-Items wie z. B. Hubschrauberlandeplatz einrichten!\), welche in der Regel eine gewisse Zeitspanne be" otigt und gegebenenfalls auch fehlschlagen kann (siehe reaktives Systemverhalten, Abschnitt 6.2.2). Hingegen spiegeln die note-Items lediglich allgemeine Hinweise wider, so dass fatzlichen Funktionalituglich des Systemverhaltens n ur diese Items keine zusaten bez von Casie notwendig sind. Unter dem Begriff query-Item sind all diejenigen Items zusammengefasst, in denen eine zus atzliche Nutzerinteraktion (neben dem Abhaken) in Form einer Dateneingabe modelliert wird. Mit Casie ist es somit mahrend der Arbeit oglich, w mit einer Checkliste zugleich Informationen  uber die Einsatzlage in ein Computersystem aufzunehmen, weiterzuleiten und auszuwerten. Weiterhin kann die Angabe des Itemtyps auf der Benutzerober ur genutzt wer ache daf den, die Items visuell nach ihrem Typ zu unterscheiden. Im Gesamtsystem kur die onnen f unterschiedlichen Typen computergest utzte Dienste bereitgestellt werden. So kann z. B. zur ErfInformiere IRL uber Anzahl Verletzter!“ ein entsprechend ullung des action-Items  ” zur Verf ugung stehender elektronischer Dienst zur Informationsweitergabe (informationpropagation service) genutzt werden. Oder es kann in der Gegenrichtung eine Informationsabfrage (information-gathering service) (z. B. Anzahl der Unfallbetten im Klinikum X ” abfragen!\) automatisiert werden. In [KGK+10] wird hierzu bereits ein Ansatz der Einbindung semantischer Dienste f ur Aktionen in einem Krisenszenario vorgestellt. Die stat-Eigenschaft repr¨ asentiert den Zustand eines Items. Die Status open und done stehen fdie noch leere (noch nicht bestabgehakte“ Checkbox. Um eine ur atigte) bzw. " zeitliche Ausdehnung und einen m oglichen Fehlschlag einer Aktion (action-Items) zu repr atzlich die Zust asentieren, werden in Casie zusande inprogress (noch in Bearbeitung) und fail (expliziter Fehlschlag) beruberg ucksichtigt. Die Ereignisse, die Zustandsange von Checklisten und deren Items bewirken, werden im kommenden Abschnitt 6.2 genauer er- l autert. Eine Verkn¨ upfung eines Items zu einer entsprechend konkretisierten Checkliste kann mittels der Eigenschaft Sub realisiert werden (siehe Abschnitt 6.2). Falls f ur ein Item f keine Sub-Checkliste zur eventuellen Detaillierung angegeben ist, wird f als primitiv bezeichnet, anderenfalls heit f nicht-primitiv. Synonym wird im Weiteren f ur nicht-primitiv auch von abstrakten Items gesprochen. Durch die Menge der Vorbedingungen P re() und der E ekte Eff() kann der Teil der Einsatzlage beschrieben werden, welcher f ur eine Beachtung gelten muss bzw. welcher sich durch eine erfolgreiche Bearbeitung des jeweiligen Items ergibt. Analog zu der Menge der Anwendungskriterien K einer Checkliste sollen die Pre-und E ektmerkmale gem aß eines formalisierten Dom anenvokabulars in einer computerverarbeitbaren Form abgelegt werden. Details hierzu werden im Abschnitt 6.3 erl autert. Beispiel 3 Als Beispiel i1 eines konkreten Items dient ein kritischer Schritt aus der SOP aus Beispiel 2. Es zeigt eine magung eines Items im Kontext einer Checkliste ogliche Auspr Grundlegende Konzepte und Designentscheidungen zum Vorgehen beim Signaleingang einer Brandmeldeanlage (BMA) (vgl. Anhang, Seite 138): name(i1)= Entnahme Plan BMA“, ” text(i1)= Brandmeldeanlage (BMA) zur¨ ucksetzen.“, ” desc(i1)= BMA wird mit dem Taster ’BMZ uckstellen’ im Feuerwehr- r¨ ” Bedienfeld wieder in den Ruhezustand versetzt. Eine R¨ uckstellung darf erst nach Kontrolle der ausgel¨ osten Melder erfolgen!“, res(i1)= {’Abbildung Feuerwehr-Bedienfeld’}, type(i1)= action, stat(i1)= open, Sub(i1)= Ø, Pre(i1)= Ø, Eff (i1)= {bma zur¨ uckgesetzt(’BMA1’)}. Das Beispiel 3 zeigt, welche Arten von ur Informationen f¨ein Item in Casie hinterlegt werden k¨atzliche Ressource zum Item ist im onnen. Die Referenz auf die Abbildung als zus¨ Beispiel nur angedeutet. Zu Beginn ist dem Item per default der Status open zugeordnet, damit wird angezeigt, dass dieser Punkt noch beachtet werden muss. Da die Menge Sub(i1) leer ist, handelt es sich bei i1 um kein abstraktes Item. Als Effekt ist hinterlegt, dass die betreffende Brandmeldeanlage (BMA1) in den normalen Betriebszustand zur¨ uckgesetzt wurde. Effekte werden erst nach erfolgreicher Best¨ atigung der entsprechenden Items zum Aufbau und Update der Lageinformation genutzt. N¨ aheres hierzu wird im Abschnitt 6.2 Dynamik erl¨ autert. Checkliste . Checkliste . ..Bereitstellungsraum für RD-Fahrz. in der Nähe der VA BP einrichten ..Hubschrauberlandeplatz („nah“ und „fern“) festlegen ..auf eine ausreichend große Zu- und Abfahrt achten ..Leiter Bereitstellungsraum und RTH-Landeplatz benennen ..… … … abstraktes (action)-Item ..… … … ..Größe Landeplatz: mind. 30x30 m ..keine hohen Hindernisse in der Nähe ..freien Zugang für den RD herstellen ..Landeplatz absperren ..Landeplatz kenntlich machen (Blaulicht/Warnblinkanlage) ..… … … .............. Abbildung 5.2: Beispiel einer Konkretisierung eines abstrakten Items. 5.2.3 Komplexit¨at handhaben durch Hierarchien Die Umsetzung von PCLs ist in der Regel aus Platz-und Handhabbarkeitsgr¨ unden auf eine oder wenige A4-Seite(n) beschr¨uberschaubar darstel ankt. Einfache SOPs lassen sich somit ¨ len. PCLs stoßen jedoch bei komplexeren SOPs schnell an ihre Grenzen. Eine bekannte und effektive Methode zur Handhabung von Komplexit¨ at ist die Abstraktion. Angewandt auf komplexe SOPs heißt das, dass bei Bedarf Teilaspekte einer SOP in Form eines (abstrakten) Items zusammengefasst werden. Doch was tun, wenn die SOPs schwer abstrahiert werden Grundlegende Konzepte und Designentscheidungen onnen, da dadurch wichtige Informationen verloren gehen oder Schritte ausgelassen werden? Eine L¨angige Bestandteile zu k¨ osung liegt darin, komplexe SOPs in einzelne, unabh¨ zerlegen und f¨ ur jeden dieser Teilbereiche jeweils eine eigene, detailliertere CL umzusetzen. Durch den Computereinsatz erschließt Casie die M¨ oglichkeit einer hierarchisch vernetzten Gesamtverwaltung dieser Checklisten. In Casie lassen sich zusammengeh¨ orige Teile einer SOP als ein sogenanntes abstraktes Item (auch nicht-primitives Item genannt) in die ¨ ubergeordnete ICL dieser SOP aufnehmen (vgl. Abschnitt 5.2). Bei Bedarf kann der Anwender ¨ uber die abstrakten Items Zugriff auf die entsprechenden referenzierten Sub-CLs erhalten. In Abbildung 5.2 ist als Beispiel eines abstrakten Items und einer m¨ oglichen Konkretisierung die Aufgabe, einen Hubschrauberlandeplatz (nah“ und fern“) einzurichten, illus ”” triert (angelehnt an [PM01], S. 92). Der Einfachheit halber besitzt im Beispiel die Menge Sub(f2) mit der Checkliste b nur ein einziges Element. Im Allgemeinen k¨ur onnenjedochf¨ ein abstraktes Item mehrere alternative Realisierungen angegeben werden. Rolle: TEL Org: Feuerwehr .......................................................................................................... … … … … .. … … … … ..… … … … .. … … … … .. … … … … .. … … … … .. … … … … Rolle: TEL Org: Feuerwehr .. … … … … .. … … … … .. … … … … .. … … … … .. … … … … .. … … … … ..… … … … ..… … … … Rolle: TEL Org: Feuerwehr .. … … … … .. … … … … .. … … … … .. … … … … Rolle: TEL Org: Feuerweh .. … … … … .. … … … … .. … … … … .. hhrr h .. r .. Abbildung 5.3: Schema einer Konkretisierung abstrakter Items. Die Methode der Abstraktion ist im Prinzip f¨ ur alle drei in dieser Arbeit unterschiedenen Typen von Items anwendbar. Neben den action-Items eignen sich auch note-Items zur Abstraktion f¨asst sich das Prinzip ur komplexere Hinweise. Aber auch auf query-Items l¨ anwenden. Somit k¨onnen z. B. allgemeine Fragen ¨ uber spezielle Bereiche einer Einsatzlage auf eine Sub-Checkliste verweisen, mit der sich detailliertere Angaben ¨ uber die Lage vom Benutzer abfragen lassen. Die Abbildung 5.3 zeigt ein Beispielschema einer sich durch Abstraktion ergebenden Checklistenhierarchie (CLH). Jedes abstrakte Item f referenziert dabei auf eine Menge Sub(f)m¨ogliche Konkretisierung. Hier wurde ebenfalls als oglicher Sub-Checklisten als m¨ Vereinfachung eine jeweils einelementige Menge Sub(f) angenommen. Hierdurch ergibt sich eine Hierarchie von Checklisten, die der Struktur eines Baums ¨ ahnelt. Ausgehend von einer Wurzel an oberster (abstrakter) Stelle, f¨ achert sich somit ein Baum auf, dessen Blattknoten aus Checklisten bestehen, deren Items alle primitiv sind. Alle inneren CL-Knoten besitzen hingegen abstrakte Items. Die Checklistenhierarchie stellt das Prinzip einer Konkretisierung abstrakter Items einer Checkliste a dar. Der Aufbau einer solchen CLH wird in Abschnitt 6.2 genauer erl¨ autert. Grundlegende Konzepte und Designentscheidungen Der Einfachheit halber wurde in der Abbildung 5.3 als Ordnungsrelation der Items eine Totalordnung angenommen. Die Ordnung der Items entspricht in diesem Fall einer Sequenz von Items. In den kommenden Beispielen wird, falls nicht anders angegeben, immer von einer Totalordnung der Checklistenitems ausgegangen. Mastercheckliste und Rollen¨ ubergang Die Checkliste an oberster Position einer CLH nimmt in Casie einen besonderen Stellenwert ein. Sie wird im weiteren Mastercheckliste (MCL) einer CLH genannt (siehe Abb. 5.3, links) und dient der jeweiligen Einsatzkraft als ein Ausgangspunkt der Checklistenbearbeitung. F¨ ur eine MCL gilt, dass keine andere Checkliste auf sie als Sub-Checkliste referenziert. Des Weiteren sind ¨ uber eine MCL alle relevanten Sub-Checklisten der Rolle zu erreichen. TEL Feuerwehr TEL Feuerwehr TEL Feuerwehr ..… … … … ..… … … … ..… … … … ..… … … … TEL Feuerwehr UA Feuerwehr UA Feuerwehr ..… … … … ..… … … … ..… … … … ..… … … … UA Feuerwehr ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..............................… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ......… … … … ..… … … … ..… … … … ..… … … … ..… … … … .. … … … … ..… … … … .. … … … … Rolle: Leiter UA Brandbekämpfung Rolle: Technische Einsatzleitung Feuerwehr Abbildung 5.4: Rollenbegrenzung in einer Checklistenhierarchie. Die Designentscheidung in Casie, dass einem aktiven Rolleninhaber genau eine MCL zugeordnet wird, beruht auf der Annahme, dass jede MCL eine (abstrakte) Zusammenstellung aller kritischen Aspekte des gesamten Aufgabenbereiches der entsprechenden Rolle umfasst. Diese Sichtweise soll zur runtime eine initiale Zuordnung der Checklisten gem¨ aß der Aufgabenbereiche erm¨ oglichen (siehe kommenden Abschnitt 5.2.5). Vor allem f¨afte der oberen F¨ ur Einsatzkr¨uhrungsebene ist eine volle Expandierung einer Mastercheckliste nur dann sinnvoll, wenn die Items der unteren Ebene noch in das Aufgabengebiet der eingenommenen Rolle fallen. Je h¨uhrungsinstanz (z. B. Gesamtein oher die F¨ satzleiter) desto mehr Aufgabenbereiche und untergeordnete F¨afte (z. B. Unter uhrungskr¨ abschnittsleiter) sind dieser in der Regel unterstellt. Details der Arbeiten im Unterabschnitt sind f¨uhrungsebenen meist nicht von Belang. Wesentlich ist zu wissen, ob ur die oberen F¨ und ggf. wann eine Aufgabe erf¨ ullt wurde. Eine Besonderheit des Casie-Konzeptes liegt in der Beachtung aller durch die Einsatzkr¨ afte unterschiedlich eingenommenen Rollen. D. h., die Konkretisierung der abstrakten Items soll nur bis auf die Ebenen erfolgen, deren Items noch in den Verantwortungsbereich des Anwenders der MCL fallen. Abbildung 5.4 skizziert diese Rollengrenzen. Ausgehend von der MCL mk zeigt obige Abbildung 5.4 eine Checklistenhierarchie, die sich ¨ubergang, der aus ß uber zwei Rollenbereiche erstreckt. Der hervorgehobene Rollen¨ berechnet ist, korrespondiert mit einem entsprechenden Wechsel des Verantwortungsbereiches gem¨uhrungsstruktur (vgl. Abschnitt aß einer zugrunde liegenden Organisations-und F¨ 5.2.5, unten): Der Verweis vom abstraktem Item fi zur MCL ml korrespondiert im Beispiel mit einem Wechsel des Verantwortungsbereiches vom Technischen Einsatzleiter hin zum Grundlegende Konzepte und Designentscheidungen Unterabschnittsleiter Brandbek¨ ampfung. Dem Item fi kommt in Casie daher zur runtime eine besondere Bedeutung zu. … Level 1 abstraktes Item (OR-Knoten) Checkliste (AND-Knoten) … primitives Item (Blattknoten) …… ........… … … … ..… … … … ..… … … … ..… … … … ..… … … … ..… … … … ……… … … …… …… … …… … …… Level 2 Level 3 ..… … … ..… … … ..… … … ..… … … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … Abbildung 5.5: Entwicklung einer CLH als AND/OR-Graph. Erweiterung um alternative Sub-Checklisten Wie die BOS-Praxis zeigt, kann es f¨ ur bestimmte SOPs durchaus sinnvoll sein, je nach den Erfordernissen der Lage alternative Vorgehensweisen f¨ ur ein und dieselbe Zielstellung zu unterscheiden. So kann sich z. B. die SOP hinter der Aufgabenstellung ’Behandlungsplatz etablieren’ f¨ ur eine Einsatzlage mit und ohne Gefahrgutbeteiligung wesentlich unterscheiden. In Anbetracht des Prozesskontextes von Checklisten sollte daher obige Anforderung auch bei einem Checklisten-Assistenzsystem mit beachtet werden. In Analogie zu der Struktur von AND/OR-Graphen, welche unter anderem in der KI- Forschung im Umfeld von Problemreduktion (siehe z. B. [HJW94], S. 99 ff.) zu finden sind, spannt sich in Casie ein Suchraum bez¨ uglich der zu beachtenden nicht-primitiven Items auf. Abbildung 5.5 zeigt links das Schema einer m¨ oglichen MCL-Expandierung in Form eines AND/OR-Graphen. Eine der potentiell m¨ oglichen Konkretisierungen ist (dick) hervorgehoben. Die sich daraus ergebende CLH ist in der Abbildung auf der rechten Seite angedeutet. Jede Checkliste mit ihren Items steht f¨ ur einen AND-Knoten. Jedes abstrakte Item, f¨ ur das mehr als eine alternative Konkretisierung angegeben ist, stellt einen OR- Knoten dar. Die Blattknoten als Saum des Graphen sind die konkreten Items, die beachtet werden m¨ ussen. Grundlegende Konzepte und Designentscheidungen .......... … … … … ..… … … … ..… … … … .. … … … … .. … … … … .. … … … … .. … … … … ..................................… … … ..… … … ..… … … ..… … … ..… … … ............ CL-Varianten zur Realisierung von ...... . . . Situationsabhängige Entscheidung (..) ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … ..… … … .... Abbildung 5.6: Grundprinzip der Angabe von alternativen Sub-Checklisten. Eine M¨ur unterschiedliche SOP-Auspr¨ oglichkeit, Casie f¨agungen zu konfigurieren, besteht darin, f¨ ur ein abstraktes Item alternative Sub-CLs als Realisierung anzugeben. Obwohl theoretisch einem abstrakten Item f mittels Sub(f)= {cl1,...,cln} beliebig viele Checklisten zugeordnet werden k¨ onnen, ist in der BOS-Praxis zu erwarten, dass nur sehr wenige Alternativen in Frage kommen. Dieser Mechanismus kann jedoch, neben der Beachtung unterschiedlicher Einsatzlagen, auch zur Realisierung von personalisierten Checklisten genutzt werden (siehe Kapitel 7). Die Abbildung 5.6 zeigt schematisch das Grundprinzip der alternativen Sub-CLs. Zu sehen ist eine MCL, die ein abstraktes Item enth¨art werden, wel alt. Zur runtime muss gekl¨ che der m¨oglichen Varianten aus {cl1,...,cln} als Konkretisierung eines abstrakten Items in Frage kommen. Dieser Entscheidungsschritt wurde in der Abbildung mittels d kenntlich gemacht. Die Entscheidung dar¨ uber, welche Sub-Checkliste in der jeweiligen Situation angewandt werden muss, obliegt in erster Linie der Einsch¨ atzung des Anwenders. Als Assistenzsystem kann jedoch auch Casie die G¨uberpr¨ ultigkeit der Anwendungskriterien ¨ufen und die Zuordnung automatisch vornehmen, falls nur eine Checkliste als Konkretisierung in Frage kommt. Hierzu wird ¨uft, f¨ uberpr¨ur welche Checkliste alle Anwendungskriterien der Menge K(cl)erfullt sind ¨– vorausgesetzt, es lassen sich dementsprechende Informationen ¨ultigkeit der jeweiligen Anwendungskriterien ermitteln (siehe Abschnitt 6.2, uber die G¨ Dynamik). Es obliegt dem Anwender, die Varianten so zu konfigurieren, dass sich die Anwendungskriterien gegenseitig ausschließen. Das heißt, es muss klar geregelt sein, welche Sub-CL aus dem Pool der Varianten im konkreten Einsatz anzuwenden ist. Die Abbildungen 5.7 und 5.8 (siehe n¨ogliche achste Seite) skizzieren beispielhaft eine m¨ Checklistenhierachie. Ausgehend von der MCL cl1 f¨ ur die Rolle des Gesamteinsatzleiters (TEL) ist ein Auszug einer CLH skizziert, die sich ¨ uber 4 weitere Rollenbereiche erstreckt. Zu sehen sind Beispiele realer Checklisten (in Anlehnung an [PM01], S. 83 ff.) f¨ ur die Rollen ’Gesamteinsatzleiter (TEL)’, ’Unterabschnittsf¨ uhrer Hubschrauberlandeplatz (HLP)’, ’OrgL’, ’Leiter Behandlungsplatz (BP)’ und ’Medizinische Leiter Behandlungsplatz’. Obwohl in den beiden Abbildungen viel Wert auf Authentizit¨ at gelegt wurde, stellen die Items lediglich Musterbeispiele ohne Anspruch auf Korrektheit der Iteminhalte dar. Grundlegende Konzepte und Designentscheidungen Rolle: Gesamteinsatzleiter/TEL BOS: Feuerwehr (FW) SOP: Nachalarmierung MANV ..Absprache mit der RLS beachten ..Überörtliche Hilfe ..Werkfeuerwehren ..ausgleichende Maßnahmen ..THW; Bundeswehr; DLRG; BGS; etc. ..Reserveführungskräfte Feuerwehr ..Führungskräfte für TEL ..Betreuung eigener Kräfte ..Notfallseelsorger anfordern Rolle: Gesamteinsatzleiter/TEL BOS: Feuerwehr (FW) SOP: Benachrichtigungen ..Leiter Feuerwehr informieren ..Beigeordnete informieren ..Oberbürgermeister informieren ..Presseruf auslösen ..Meldung an die Bezirksregierung ..Zuständige Ordnungsbehörden verständigen ..Gesundheitsamt (falls nötig) ..Presse- und Bürgeramt ..Alarmschwelle für Krankenhäuser festlegen und kommunizieren ..Warnung der Bevölkerung (falls Schadstoffwolke) Rolle: Unterabschnittsführer BOS: Feuerwehr (FW) SOP: Geeigneter RTH-Landeplatz ..Mind. 35 x 70 m! ..Ebener und fester Platz möglichst ohne Grasbewuchs! ..Keine hohen Hindernisse in unmittelbarer Nähe! ..Keine Freileitungen über Landeplatz! R: OrgL Rolle: Gesamteinsatzleiter/TEL BOS: Feuerwehr (FW) SOP: Technische Einsatzleitung MANV ..Abschnittsbildung gemäß Einsatzplan (siehe EPL) ..Funkkonzept anwenden (siehe FKZ) ..Raumordnung festlegen ..Erstbeurteilen der Lage ..Nachalarmierungen veranlassen ..Benachrichtigungen ..Alarmierung anderer Behörden und Betriebe ..Führungsstab organisieren ..… … … … Rolle: Gesamteinsatzleiter/TEL BOS: Feuerwehr (FW) SOP: Raumordnung festlegen ..Bereitstellungsraum Einsatzstelle bestimmen ..Sammelstellen für überörtliche Kräfte bestimmen ..Einrichtung Einsatzabschnitt (EA) Schadensbewältigung ..Einrichtung EA Umwelt; Logistik im EA Schadengebiet ..Absperrbereich festlegen ..Standort TEL festlegen ..Behandlungsplatz (EA-Führer- Verletztenversorgung) ..Verletztenablage festlegen ..Hubschrauberlandeplatz etablieren ..Bereitstellungsraum für Rettungsdienstfahrzeuge ..… … … … … Rolle: Unterabschnittsführer BOS: Feuerwehr (FW) SOP: Hubschrauberlandeplatz ..Landeplatz räumlich festlegen ..freien Zugang für RD herstellen ..Landeplatz absperren ..Landeplatz kenntlich machen ..Funkkontakt mit RTH-Besatzung aufnehmen ..Informationen über Landeplatz an alle weiterleiten ..ausleuchten (bei Nacht) ..Lose Gegenstände entfernen oder festbinden ..Sicherstellung Brandschutz ..Keine Tücher oder sonstige Zeichen auslegen!* ..Pilot sucht evtl. anderen Landeplatz (er allein trägt die Verantwortung)* ............................................ MCL MCL Abbildung 5.7: Auspr¨ agung einer Checklistenhierarchie (1/2). Grundlegende Konzepte und Designentscheidungen 63 ... Rolle: OrgL BOS: Rettungsdienst (RD) SOP: Vorgehen MANV II Rolle: Leiter Verletztenablage (RD) BOS: Rettungsdienst (RD) SOP: Leitung Verletztenablage Rolle: Med. Leiter Behandlungsplatz BOS: Rettungsdienst (RD) SOP: Med. Leiter Behandlungsplatz Rolle: Leiter Behandlungsplatz (BP) BOS: Rettungsdienst (RD) SOP: Leitung Behandlungsplatz ..Raumordnung und Behandlungsplatz mit Absprache OrgL festlegen ..BP entsprechend kennzeichnen ..Absprache mit dem med. Leiter Behandlungsplatz ..Aufstellung der Fahrzeuge und Zelte festlegen ..Eingang Behandlungsplatz festlegen ..Eingangsdokumentation delegieren ..Ablauforganisation nach Sichtungskategorien ..Ausgangsbehandlungsplatz festlegen ..Ausgangsdokumentation delegieren ..Ausgang aus dem Betreuungsbereich festlegen ..Evtl. Betreuungsbereich (Gebäude/ Zelt/Container) für Angehhörige von Betroffenen schaffen ..Ruhe bewahren! ..Kommunikation sicherstellen Ansprechpartner: OLRD/LNA/TEL ..Verletztenablage kennzeichnen ..Tragen für Trägertrupps ausgeben ..Rettungsmittel (Material/ggf. Zelte) platzieren – Windrichtung beachten! ..Zu-/Abfahrtswege – ausreichend Platz lassen (auch für Busse) – Achtung – Einbahnstraßensystem! ..Zu-/Abfahrtwege/Zugänge sichern ..Bereitstellungsräume für Rettungsfahrzeuge festlegen ..Verfügbarkeit der Materialien sicherstellen ..Rückmeldung an OrgL ..............Kennzeichnung (Überwurfweste) ..Erstausstattung vorhanden? (3 RTW, 2-3 NEF) ..Vergabe der Aufgabenbereiche an Notärzte (Eingangssichtung, Behandlung, Ausgangssichtung) ..Triagierung auf Anhängekarte dok. ..Individuelle Dokumentation ..Einbindung der SEG-Behandlungsplätze, wenn nötig ..Transportpriorität festlegen ..Anforderung von Rettungsmitteln über den Leiter BP ..Zuweisung der Patienten in die Behandlungseinrichtung ..Anmeldung von Patienten in Krankenhäusern nur in Ausnahmefällen; dann aufnehmender RTW über LST ..Kommunikationswege und -mittel gemäß Funkskizze ..… … … … abstraktes Item Sub-Checkliste ............................Ruhe bewahren! ..Transportstopp! ..Kontakt mit TE herstellen ..Schadensentwicklung abgeschlossen? ..Drohende Gefahren ermitteln – Einsatzkräfte informieren! ..Anzahl der Betroffenen ermitteln – ggf. Abschnittsleiter einteilen ..Lagemeldung an die ILS ..Windrichtung beachten ..Verletztenablage festlegen – (Leiter bestimmen) CL beachten ..Med. Leiter BP bestimmen ..Behandlungsplatz festlegen (Ort) ..Verbandplatz (räumlich) festlegen ..KTW-Halteplatz festlegen – Leiter bestimmen ..Ggf. weitere Hilfskräfte anfordern ..Festlegen Einbahnstraßensystem ..Nachfolgende Einsatzkräfte einteilen (wenn möglich Melder als Funker einteilen) bezüglich MCL MCL MCLMCL Abbildung5.8:Auspr¨agungeinerChecklistenhierarchie(2/2). Grundlegende Konzepte und Designentscheidungen Weiterhin ist in den Abbildungen 5.7 und 5.8 im Kopf einer Checkliste die jeweilige Rolle der Einsatzkraft, ihre Organisationszugeh origkeit und der Prozesskontext PK (cl) benannt. Weitere Merkmale wie m ogliche Anwendungskriterien K(cl) oder der Zustand stat(cl) sind in der Skizze einfachheitshalber nicht abgetragen. Auch eine eventuell vorliegende partielle Ordnung der Items ist in der gew ahlten Serialisierung nicht mehr als solche zu erkennen. Zur besseren Unterscheidung sind im Beispiel die note-Items kursiv dargestellt und die query-Items durch ein Fragezeichen am Ende des Textes gekennzeichnet. Items, die nur in bestimmten Situationen beachtet werden m ussen (d. h., die Menge P re() eines Items enth alt mindestens eine Vorbedingung), werden bedingte Items genannt und sind in der Abbildung mittels Unterstreichung als solche kenntlich gemacht. Bei einem bedingten Item handelt es sich nicht um einen zusuhrten Itemtyp, sondern um eine (optionale) atzlich eingef Qualitat der bereits de nierten note-, action-und query-Items. Vorbedingungen lassen sich in nat urlichsprachlicher Form angeben. Der Hinweis, dass bei einer Schadsto wolke (falls Schadsto wolke\, siehe Abbildung 5.7, cl3) die Bev olkerung zu warnen ist, ist ein " Beispiel eines bedingten Items, dass nur beachtet werden muss, falls die Vorbedingung erfoglichen die Kon guration einer Checkliste foglichst ullt ist. Bedingte Items ermur ein m breites Spektrum an Anwendungsszenarien. Auch fat von Items ur diese spezielle Qualit kann Casie automatisch die Gufen. Voraussetzung ist auch ultigkeit der Bedingungen pr hier, dass die Vorbedingungen in einer computerverarbeitbaren Form gegeben sind und der momentane systeminterne Wissensstand  uber die Einsatzlage eine Schlussfolgerung ermoglicht. Ist z. B. in der Wissensbasis bereits bekannt, dass es sich bei dem Einsatz um einen Grobrand handelt, der zudem in einem D ungemittelbetrieb ausgebrochen ist, so kann Casie automatisch den Schluss ziehen, dass eine Schadsto wolke droht. Hierf ur muss das System zuvor mit einer entsprechenden Regel (Axiom) kon guriert werden. In dem kommenden Abschnitt 6.2 und dem Kapitel 7 wird genauer auf die Thematik der bedingten Items eingegangen. Foglicher Konkretisierun ur einzelne abstrakte Items (grau hinterlegt) sind Beispiele m gen zu sehen. So sind z. B. f ur die drei abstrakten Items von cl1 deren jeweilige Konkretisierung (cl2, . . . , cl4) als Sub-Checklisten zu sehen. Weiterhin sind Beispiele fuberg ur Rollenange 1;:::; 5 gegeben. Die Konkretisierung abstrakter Items, welche im Verantwortungsbereich einer anderen Rolle liegen, ist durch gestrichelte Pfeile gekennzeichnet. Die Checkliste cl2 des 'Technischen Einsatzleiters’ beinhaltet z. B. zwei abstrakte Items, deren jeweilige Konkretisierung auf die Sub-Checkliste cl5 bzw. cl7 verweist. cl7 des 'OrgL’ verweist wiederum auf drei Sub-Checklisten (cl8, . . . , cl10), welche jeweils im Verantwortungsbereich von Abschnittsleitern liegen, die dem 'OrgL’ unterstellt sind. (Dass der 'Medizinische Leiter Behandlungsplatz’ in der Praxis immer dem leitenden Notarzt unterstellt ist, wurde in der ¨ Abbildung 5.8 zu Gunsten der Ubersichtlichkeit ausgeblendet.) 5.2.4 HTN-Planung und Theorien der Handlungsregulation Die Berechung einer Checklistenhierarchie orientiert sich an der sogenannten Reduktion eines hierarchischen Tasknetzwerks in der HTN-Planung (vgl. [GNT04]), deren Grundlagen 1975 von Sacerdotis als L osungsansatz komplexer Probleme beschrieben wurden (vgl. [Sac75]). Wprozeduralen ahrend Sacerdotis in seinen Arbeiten statt von HTN noch von " Netzen“ sprach und eher die hierarchische Organisation und zielorientierte Wiederverwendung von Programmprozeduren adressierte, besch aftigt sich die heutige HTN-Planung allgemein mit der Perspektive weltver andernder Handlungen in einer Planungsumgebung. Ein wesentliches Konzept in der HTN-Planung sind die sog. Methoden. HTN-Methoden sind stark problembezogen und k onnen als eine Art Standard Operating Procedure aufgefasst werden [GNT04]. Dom anenexperten formulieren in ihnen ihre Standardvorgehensweise bei Grundlegende Konzepte und Designentscheidungen der Bearbeitung von mehr oder weniger abstrakten wiederkehrenden Aufgaben. Wie in den HTN-Methoden, so wird auch in den Checklisten jeweils eine best practiceals L¨ “ osung ” ur eine abstrakte Aufgabe beschrieben, wenn auch bei letzteren ausschließlich kritische Aspekte einer ubergeordneten SOP adressiert werden. Im Prinzip l¨ f¨ ¨asst sich der Aufbau einer CLH mit der Aufgabe einer Task-Dekomposition bei der HTN-Planung vergleichen. ........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ Abbildung 5.9: Das Prinzip der Task-Dekomposition. Die MCL in Casie ¨ ahneln dem Konzept eines Start-Task-Netzwerk weines HTN-Planungsproblems P =(s0,w,O,M) (vgl. hierzu [GNT04], S. 236 ff.). Wie eine komplexe Task realisiert werden kann, wird durch eine oder mehrere zuvor konfigurierte Methoden vorgegeben. Abbildung 5.9 zeigt, wie das Prinzip der Task-Dekomposition (auch Taskreduktion genannt) bei der Plansuche angewendet wird. Zu Beginn steht eine vorgegebene nicht- primitive Task, die erf¨ur solch eine Task kann es mehrere vorgegebene ullt werden soll. F¨ Methoden als Realisierung geben. Kann z. B. zwischen zwei Methoden f¨ ur ein und dieselbe Task gew¨ahlt werden, so entscheiden die in der jeweiligen Methode angebbaren Vorbedingungen ¨wenn uber die Wahl der anzuwendenden Methode. Nur die Vorbedingungen der jeweiligen Methode im momentanen Zustand gelten, versucht der Planer, die Methode zur weiteren Konkretisierung der Task anzuwenden. Beginnend vom Startzustand s1 wird durch Hintereinanderausf¨ uhrung der Aktionen (Operator-Instanzen) der Zielzustand s4 erreicht. Im Zustand s4 wurde der potentielle Weltzustand durch Anwendung der Aktionen dahingehen ge¨ullung andert, dass nun alle Merkmale, die eine erfolgreiche Taskerf¨ charakterisieren, gelten. In Abbildung 5.10 ist eine vereinfachte Darstellung eines Teils einer m¨ane als AND/OR-Graph dargestellt. oglichen Planungsdom¨ Die Itemstruktur I einer MCL l¨ asst sich mit der eines Task-Netzwerks w vergleichen. Bei der HTN-Planung besteht das Problem in einer Reduktion von w im Startzustand s0, unter Beachtung der Dom¨ anenmodellierung (bestehend aus den Methoden M und den Operatoren O). Hingegen stellt sich in Casie die Aufgabe einer Reduktion der Itemstruktur I der MCL. F¨ ur Casie gelten daher im Vergleich zur HTN-Planung folgende Besonderheiten/ Unterschiede: 1. In einer Großschadenslage lassen sich aufgrund des zu Beginn herrschenden Informationsmangels kaum konkrete Planungsprobleme formulieren. Wenn ¨ uberhaupt, dann sind die Ziele nur sehr abstrakt gegeben (Leben retten“, Schaden abwenden“, Be ”” ” handlungsplatz aufbauen“). Bei Casie handelt es sich aus Planungssicht nicht um Grundlegende Konzepte und Designentscheidungen .................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................... Abbildung 5.10: Beispielhafter Auszug einer HTN-Planungs-Dom¨ ane als AND/OR-Graph. eine Vorplanung, sondern vielmehr um eine Art on-demand CLs-Konkretisierung mit Prozessmonitoring. 2. Die Items in Casie entsprechen im Gegensatz zu den HTN-Operatoren nicht zwangsl ¨ aufig konkreten Aktionen einer SOP. D. h., die meisten Items entsprechen abstrakten Tasks. Es ist zu erwarten, dass nur f¨ ur diewenigsten ItemseinekorrekteAngabeder Vor-und Nachbedingungen m¨ oglich (sinnvoll) ist. Auch steht die Instantiierung von Operatoren zu Aktionen (durch Ressourcenzuweisung) in Casie nicht im Fokus. Casie arbeitet vielmehr auf einer abstrakteren Ebene, da umfassende Informationen ¨ uber alle Ressourcen in der Regel nicht vorliegen. 3. In Casie m¨atzlich zu dem Aufbau der ussen aufgrund des Multiagentenszenarios zus¨ Checklistenhierarchie(n) die jeweiligen eingenommene Rollen und die m¨ oglichen Rollen ¨ange mit beachtet werden. Des Weiteren gilt es zus¨ uberg¨atzlich zum Paradigma der Taskreduktion in der HTN-Planung, den Level der jeweiligen Sub-CLs im Ergebnis einer CLH mit zu ber¨ ucksichtigen. Obige Diskussion soll aufzeigen, dass die Anwendung des HTN-Planungsparadigmas im Prinzip f¨otigte Konkretisierung von MCLs geeignet ist. Jedoch liegt ur die in Casie ben¨ der Fokus bei Casie eher auf der Verzahnung zwischen Taskreduktion und Ausf¨ uhrung zur Einsatzzeit, und weniger auf der Berechnung eines in allen Einzelheiten konkretisierten Planes. Die KI bietet jedoch mit der HTN-Planungstheorie ein Verarbeitungsmodell menschlicher Handlungsplanung, das als Rahmenwerk f¨ ur den Umgang mit abstrakten Aufgabenbeschreibungen geeignet ist. Abstraktionen und Hierarchien finden sich ebenfalls in den sozialpsychologischen Handlungstheorien (auch Handlungsregulationstheorien genannt) wieder. Dies untermauert die Angemessenheit der hierarchischen Checklistenstruktur und zeigt, dass der Casie-Ansatz der menschlichen Herangehensweise an komplexe Problemstellungen entspricht. Im Folgenden werden zwei popul¨uhrt, die die Analogie zum Vorgehen are Handlungstheorien aufgef¨ der CLH bzw. HTN-Taskreduktion deutlich machen. Die Handlungstheorien leisten einen Beitrag zur Erklarung¨und Vorhersage sozialer Interaktionen und sozialen Verhaltens [FG97]. Sie versuchen zu klaren,¨wie elementare Grundlegende Konzepte und Designentscheidungen Handlungen im Gesamtkontext von abstrakten ubergeordneten Aufgaben zu verstehen  sind [FG97]. So gibt es unter anderem relevante kognitions-, motivations-, pers onlichkeits-, entwicklungs-und arbeitspsychologische Ans atze [Bos07]. In allen handlungspsychologischen Ansatigen Menschen mit anderen Menschen und atzen kommt die Interaktion des t seiner Umwelt, d. h. die Wechselwirkung mit seiner sozialen und physikalischen Umwelt zum Ausdruck [Amm05]. Die Handlungspsychologie geht davon aus, dass sich der Mensch aktiv, zielgerichtet, denkend und planend mit seiner Umwelt auseinandersetzt ([Wie94] S. 73f.). Durch Pl ane werden Abfolgen von menschlichen Handlungen festgelegt, die auf ein bestimmtes Ziel hin ausgerichtet sind. Dieser Sichtweise entspricht prinzipiell die KI- Planung, jedoch wird in der sozialpsychologischen Literatur der Begriff Planung“ teils sehr " allgemein fuhungen verwendet. ur jegliche zielgerichteten Bem Straßenbäume ersetzenVerwalterische VorbereitungenAusführenStraßenteilfestlegenBaumartfestlegen und bereitstellenAufträgeausstellenFällen undRodenPflanzenNacharbeitenFällenRodenHolenGrubevorbereitenSetzenErsatzerfordernisermittelnLuftverhältnisseermittelnAngebot prüfenErläuternPflasternAufgrabenBallen aushebenBaum setzenPfahl setzenKette befestigenKran einweisenKran bedienen Abbildung 5.11: Beispiel einer hierarchischen Aufgabendekodierung nach Hacker [Hac97]. Wie Hacker in [Hac97] schreibt, besteht das Kernproblem bei der psychologischen Ana " lyse des Handelns darin\, ein theoretisches Vakuum zwischen Erkenntnis und Handeln zu ” fullen.“ Gemeint ist hier die Frage, wie Handlungen durch die interne Repr asentation der ” Umwelt im Organismus reguliert werden\. Die Handlungspsychologie versucht, menschliches Handeln zu erkl aren, indem sie ihre Aufmerksamkeit auf die handlungssteuernden Pl ane und die kognitiven Strukturen beim Planen richtet. Aus dem Bereich der Arbeitspsychologie stammt ein Modell der Regulation von Arbeitst Allgemeine Arbeitspsychologie. atigkeiten, das Hacker unter anderem in seinem Buch " Psychische Regulation von Arbeitst[Hac97] vorstellt. Hacker untersucht die atigkeiten“ Bildung von regulativen Funktionseinheiten und erarbeitet in diesem Zusammenhang ein hierarchisches Modell der Regulation von Arbeitst atigkeiten. Komplexere Aufgaben werden dabei in Unteraufgaben unterteilt. Die in Abbildung 5.11 gezeigte Aufgabendekodierung entspricht der einer Taskreduktion in der HTN-Planung. Die Kreise auf der unteren Ebene stellen die auszuf uhrenden elementaren Handlungen (Aktionen in der Planung) dar. Die angedeutete Sequenz dieser Handlungen spiegelt hier einen (total-geordneten) Plan wider. Wie Hacker schreibt, entspricht der Hierarchie der Zielsetzung“ eine Hierarchie der "” Pl[Hac97]. Dies entspricht der Vorstellung der HTN-Planung HTN-Methoden ane“ von Grundlegende Konzepte und Designentscheidungen als eine Art Teilpl“ osung von untergeordneten Zielen. Weiterhin emp ehlt er anezur L " als allgemeineren Begriff fur Plan“ den Begriff Aktionsprogramm“ zu nutzen, wodurch "" erneut die N ahe zum Planbegriff der KI-Planung deutlich wird. Die Aufgabendekodierung tri t nicht nur auf individuelle Arbeitst¨ atigkeiten zu, sondern gilt auch fatigkeiten von Gruppen und umfassenderen organisatorischen Einhei ur T ten. Dieser Ansatz l asst sich gut auf die Zusammenarbeit der unterschiedlichen BOS in einem MANV anwenden. Hacker fasst die in Abbildung 5.11 angedeuteten Teilaufgaben hierzu zu Bluglich ihrer organisationalen (betrieblich-abteilungsbezogenen) ocken bez Arbeitsteilung bzw. Arbeitskooperation zusammen. Besonders interessant sind hierbei die Schnittstellen und der notwendige Informationsaustausch zwischen den Bl ocken, die eine reibungslose Zusammenarbeit zwischen den Organisationen sicherstellen. Bezogen auf die HTN-Planung korrespondiert diese Gruppierung mit dem Konzept der Methodende nition. Ziel (Z) Transformation (T1) Transformation (T2) Transformation (T3) Transformation (T4) Entschluss zurAusführung von T1Rückmeldung, Kontrolle der Zielerreichung Abbildung 5.12: Die Zyklische Einheit nach Volpert 1982 [FG97]. Eine weitere Handlungstheorie stellt das Modell der hierarchisch-sequentiellen Handlungsorganisation von Volpert [Vol83] dar. In ihr besteht die Ausgangssituation in einem hierarchisch uber mehrere Hierarchieebenen in ubergeordneten komplexen Ziel, das absteigend  einfachere Teilziele aufgeteilt wird, bis eine Sequenz elementarer umweltver anderlicher Operationen realisiert ist. Ein Basiskonzept dieser Handlungstheorie ist die Zyklische Einheit (siehe Abbildung 5.12). Das Erfullen eines Ziels wird  uber sequenzielle Transformationen derart realisiert, dass nach Beendigung der letzten Transformation das gew unschte Ziel erreicht ist. Im Idealfall hat der erfolgreiche Abschluss aller einzelnen Transformationen der Handlungssequenz das Erreichen des gew unschten Ziels zur Folge. Die Muckmeldung im Fehlerfall spiegelt sich in dem vorgesehenen Zy oglichkeit einer R klus dieser Einheit wider. Begrusse, die das erfolgreiche Anwenden undet auf auere Ein  der Handlungsstrategie vereiteln k onnen, ist hier eine Erfolgskontrolle nach der letzten Transformation vorgesehen. Somit kann uft werden, ob die Handlungssequenz das uberpr gew unschte Ziel erreicht. Falls das Ziel nicht erreicht wurde, sieht das Modell eine erneute Anwendung der Sequenz vor. Dieser Zyklus wird solange durchlaufen, bis das Ziel erreicht ist. Ist die Handlungssequenz jedoch fehlerhaft, d. h. prinzipiell nicht zielf uhrend, dann nandige Wiederholung hier nichts. Vielmehr sollte in den meisten Situationen, utzt eine st bei denen eine zuvor gewatzung aller ahlte Handlungssequenz fehlschlug, eine Neueinsch Umstanderten Handlungssequenz f ande zu einer abgeuhren. Der Fehlschlag kann prinzipiell zwei Ursachen haben: (1) die Handlungssequenz ist prinzipiell nicht durchf uhrbar und (2) die Handlungssequenz ist in der momentanen Umgebung (mit ihren aktuellen Merkmalsauspr uhrbar. Im 2. Fall w agungen) nicht durchfare eine erneute Wiederholung durchaus sinnvoll, wanderte Handlungssequenz gefunden werden ahrend im 1. Fall eine neue/abge muss (Re-Planung in der KI-Planung, vgl. z. B. [NK95]). Die Transformationen k onnen wiederum selbst eine zyklische Einheit darstellen (siehe Abb. 5.13). Jede Transformation kann als Teilziel der  ubergeordneten Transformation bzw. Grundlegende Konzepte und Designentscheidungen des  ubergeordneten Ziels angesehen werden. Zum einen kann die Aufspaltung des Hauptziels in Teilziele als Abstraktionsreduktion gesehen werden, bis hin zu konkret ausf uhrbaren Handlungen (Top-down-Sichtweise). Auf der anderen Seite ist jedes Teilziel ein Bestandteil eines komplexeren Oberziels, dessen Beschreibung auf dem Weg von unten nach oben“ ” abstrahiert wird (Buttom-up-Sichtweise). Dies ahnelt einer Baumstruktur, die uber eine  bestimmte Anzahl von Ebenen hinweg die Handlungsorganisation darstellt. Das abstrakte Hauptziel“ stellt die Wurzel des Baumes da. " Z1Z11Z12T2T3123456378910 Abbildung 5.13: Das hierarchisch-sequenzielle Modell der Handlungsregulation [FG97]. Das in Abbildung 5.13 gezeigte Modell entspricht prinzipiell der Arbeitsweise der OrderedTask- Decomposition des SHOP2-Planers (vgl. [NMAC+01]). Eine unabh angige Teilzieldekomposition ist jedoch in der Praxis nicht immer mullung oglich. Bei der separaten Erf von Teilzielen besteht die Gefahr, dass die L osung eines Teilzieles eine bereits zuvor erreichte Loren kann. Dieses Problem osung eines anderen Teilzieles (zum Teil) wieder zerst ist in der KI-Planung unter der sog. Sussman-Anomalie [Sus75] bekannt, die beispielhaft die Problematik einer unbedachten Zielzerlegung aufzeigt. In der HTN-Planung muss diese unabh angige Teilzieldekomposition durch den Methodenmodellierer sichergestellt werden. 5.2.5 Checklisten-Auswahlprozess und -Zuordnung Analog zu klassischen PCLs obliegt es in erster Linie der Einsatzkraft, zu entscheiden, welche Checkliste in welcher Situation zur Hand genommen werden muss. Neben der Ablage aller Checklisten in einem entsprechenden Repository (siehe Abschnitt 6.1), aus dem dann die Einsatzkraft zur Laufzeit die passende Checkliste manuell ausw ahlt, stellt sich in Casie besonders die Frage danach, inwiefern dieser Auswahlprozess vom Computer unterst utzt werden kann. Ziel ist es, die zum Einsatz und zur Rolle passende(n) ICL(s) anzubieten bzw. die Menge der zur Auswahl stehenden ICLs moglichst gering und damit  uberschaubar zu halten. Zwei Problemstellungen sind hierbei zu unterschieden: 1. Zu Beginn eines Einsatzes: Wie lankter Faktenlage) asst sich zu Beginn (bei beschr eine Auswahl passender Checklisten realisieren? Mit anderen Worten, nach welchen Kriterien und durch welche Automatismen log asst sich erreichen, dass das System m lichst nur f ur die Einsatzlage relevante Checklisten anbietet? 2. Wahrend eines Einsatzes: Wie ist es m oglich, auf sich andernde Einsatzmerkmale mit entsprechend angepassten Checklisten zu reagieren bzw. die Notwendigkeit der Bearbeitung neuer Checklisten automatisch abzuleiten? Die zweite Problemstellung adressiert das in Casie angestrebte dynamische und intelligente Gesamtsystemverhalten, auf das in den kommenden Abschnitten (siehe Abschnitt 6.2) Grundlegende Konzepte und Designentscheidungen genauer eingegangen wird. An dieser Stelle soll vorerst die erste Fragestellung, n¨ amlich die der Zuordnung von Checklisten zu entsprechenden Aufgaben einer Einsatzsituation, behandelt werden. Zur Beantwortung der ersten Frage wurden im Rahmen dieser Arbeit folgende drei Herangehensweisen in Betracht gezogen: 1. Einsatzstichworte: Zuordnung der MCLs ¨ uber eine Hierarchie von sog. Einsatzstichworten, welche jedem Einsatztyp ein entsprechendes Schl¨ usselwort zuordnet. 2. Aufgaben/Tasks: Zuordnung zu entsprechenden Aufgaben (Tasks), deren Bearbeitung durch die Situation oder durch eine Handlungsaufforderung eines Vorgesetzten notwendig werden. 3. Rollen und Organisationsstruktur: Zuordnung mit Hilfe der anzuwendenden Organisationsstruktur des jeweiligen Einsatzes, durch die die Einsatzrollen bestimmt werden. Einsatzstichworte. Auf den ersten Blick bietet sich eine MCL-Zuordnung anhand einer zuvor erstellten Einsatzklassifikation (z. B. Geb¨ audebrand, Gefahrgutunfall, MANV) an. Hierbei besteht der Ansatz darin, eine Hierarchie von sog. Einsatzstichworten (vgl. Abschnitt 2) zu nutzen – so wie sie in Rettungsleitstellen bekannt sind, um hinter jedem Einsatztyp die zu beachtenden Checklisten zu hinterlegen. Diese M¨ oglichkeit der Klassifizierung ist jedoch nur in Rettungsleitstellen gel¨ aufig, wo sie zur Auswahl der zu alarmierenden Kr¨upfung zu entsprechenden zugeh¨ afte dient. Die Verkn¨origen SOPs ist in der Regel nicht damit verbunden. Zudem sind die Listen der Einsatzstichworte von Region zu Region stark individuell ausgepr¨ agt bzw. deren Verwendung nicht in jedem Einsatzgebiet verbreitet. Obgleich eine erste Einschr¨ ankung der in Frage kommenden CLs durch Einsatzstichworte erreicht werden kann, bleibt der Rollenaspekt noch unbeachtet. CLs anhand von Einsatzstichworten zu organisieren ist daher eher ungeeignet. ................ „Gesamteinsatzleitung MANV (FW) …“ .................................... „Maßnahmen ersteintreffendes Rettungsmittel …“ .................................. „Organisatorischer Leiter Rettungsdienst …“ ....................................„Nachalarmierung aller Reservekräfte (KatSchutz) …“ ................................ „Rettungsmittelhalteplatz einrichten …“ .................................................... korrespondiert mit Abbildung 5.14: Zuordnung der Aufgaben/Tasks ¨ uber die Beschreibungen zu den Checklisten. Aufgaben/Tasks. Ausgehend den jeweiligen Aufgabengebieten lassen sich gem¨ von aß der SOPs alle Checklisten anhand ihrer adressierten Aufgabenstellungen (gem¨ aß SOP Beschreibung) organisieren. Abbildung 5.14 skizziert eine m¨ ogliche 1:1-Zuordnung der Tasks (1...n) aus einer Liste zu den entsprechenden Checklisten. Die Beschreibung pur(cl)einer Checkliste cl beschreibt zugleich die dahinterstehende Task. Sind f¨ ur alle Tasks auch entsprechende CLs hinterlegt, so k¨ onnte die Einsatzkraft, je nach Aufgaben, Zugriff auf eine passende Checkliste anhand einer Task aus der Tasklist erhalten. Eine automatische Vorauswahl ist jedoch ohne konkretes Wissen ¨oglich bzw. h¨ uber die Einsatzlage schwer m¨angt von der Entscheidung ab, welche Organisationsstruktur etabliert wird. Als taskorientierte Sicht auf die Checklisten ist diese Variante jedoch geeignet. Grundlegende Konzepte und Designentscheidungen (Gesamt-) Einsatzleiter (EL/TEL) Org: Feuerwehr (FW) MCL Einsatzabschnitt (EA) Einsatzleitung RD (LNA) / (OrgL) Org: Rettungsdienst (EA) … … Einsatzabschnitt (EA) Gefahrenabwehr Org: Feuerwehr (FW) (EA) … … Unterabschnitt Menschenrettung Org: FW Unterabschnitt Brandbekämpfung Org: FW (UA) … … Unterabschnitt Behandlungsplatz Org: RD Unterabschnitt Bereitstellungsraum Org: RD (UA) … … EEiEMCL (MCL MCL E(MCL (U(MCL Me UU MCL Bra U MCL Beh UUMCL Bere iB MCL U(MCL Abbildung 5.15: Auszug eines MANV-Organisationsaufbaus. Rollen und Organisationsstruktur. In Abschnitt 5.2.1 wurde bereits die enge Verbindung von SOPs zur Rollenverteilung angesprochen. Da die Rolle einer Einsatzkraft auch deren Aufgabengebiet bestimmt (zumindest stark eingrenzt), wird in Casie die Organisation der ICLs anhand der definierten Rollen favorisiert. W¨ ahlt eine Einsatzkraft ihre zutreffende Rolle aus, so kann sie die prinzipiell f¨ ur sie in Frage kommende ICL selektieren oder die Menge aller relevanten ICLs auf eine ¨anken. Bei der uberschaubare Menge einschr¨ Konfiguration des Systems empfiehlt es sich, f¨ ur jede definierte Rolle eine entsprechende MCL als Startpunkt (Einstiegspunkt) festzulegen. Die Abbildung 5.15 zeigt hierzu ein Beispiel einer Rollenverteilung anhand der Gliederung der Einsatzabschnitte und der F¨ uhrungshierarchie. Zu sehen ist ein Auszug einer m¨uhrungsorganisation mit den unterschiedlichen Aufgabenbereichen oglichen etablierten F¨ wie z. B. Gesamteinsatzleitung, Einsatzabschnitte (EA) und Unterabschnitte (UA). Abbildung 5.15 kann jedoch nur den Teil der Rollenstruktur visualisieren, der dem Verantwortungsbereich der F¨afte entspricht. Verschiedene Unterabschnitte oder mehrfach uhrungskr¨ eingenommene Rollen (wie z. B. die eines Notarztes (NA) oder Truppf¨ussen uhrers (TF)) m¨ zus¨ucksichtigt werden. atzlich ber¨ Es ist zu beachten, dass eine Rolle in der Regel zwar eine spezielle Qualifikation der Einsatzkraft voraussetzt, die Qualifikation jedoch nicht zwingend mit der Rolle gleichgesetzt werden darf. Zum Beispiel kann ein Arzt mit der Qualifikation zum LNA durchaus einem anderen, die Rolle des LNA innehabenden Notarzt untergeordnet sein. Beispiel hierf¨ ur ist die Rolle ’Eingangssichtung Behandlungsplatz’, die unter der Leitung eines ’Leitenden Notarztes’ (LNA) arbeitet. Die Frage, wann welche ICL beachtet werden muss und wie deren m¨¨angig von oglichen abstrakten Items konkretisiert werden, ist uber die Rolle hinaus abh¨ der jeweiligen vorgefundenen und sich ergebenden Einsatzsituation. 5.2.6 Standardisiertes Vokabular ur die Problemstellung dieser Arbeit stellt sich die Frage, wie eine Computerassistenz bei der Definition und Eingrenzung eines Grundwortschatzes f¨ F¨ ur die Erstellungszeit (offline) und f¨ ur die Nutzung eines Assistenzsystems im Einsatz (online) genutzt werden kann. Hier- f¨ur Casie als eines der zentralen Elemente der Einsatz einer formalen Wissens ur wird f¨ repr¨oglichkeiten einer asentation vorgeschlagen (vgl. Abschnitt 6.1). Drei Verwendungsm¨ formalen Wissensrepr¨ur Casie zum Einsatz: asentation kommen f¨ Grundlegende Konzepte und Designentscheidungen 1. Erstellung (oine) – Wahrend der Erstellung der Checklistentexte kann die Termi- nologie der Anwendungsdomane ane (in dieser Arbeit beispielhaft an der BOS-Dom gezeigt, vgl. Abschnitt 6.3.1) bei der Wahl der zu verwendenden Fachbegri e zu Rate gezogen werden. Dies bef ordert eine Vereinheitlichung im Sprachgebrauch, wodurch das Risiko eventueller Fehlinterpretationen im Einsatz verringert wird. Zum Beispiel sollte immer dann, wenn von Orten die Rede ist, an denen Einsatzkr afte und Einsatzmittel fBereitstellungsraum“ ver ur den Einsatz vorgehalten werden, der Name " wendet werden. Abbildung 5.16 zeigt eine entsprechende Konzeptde nition aus der BOS-Ontologie. (Zu sehen ist ein Ausschnitt der BOS-Ontologie ([BOS-O]), ediert mit dem Ontologieeditor Protege, vgl. hierzu Abschnitt 6.3.) Abbildung 5.16: Annotation des Konzeptes Bereitstellungsraum“ (siehe [BOS-O]). " 2. Informationsquelle (online) – ur die Itemtexte in der Benutzerschnittstelle (UI) Da f in der Regel wenig Platz zur Verfussen die Texte eher stichpunkthaft ugung steht, m¨ gehalten werden. Darunter kann das Verst¨ andnis der Aussagen leiden. Eine formale Wissensbasis kann nun auf Begri sebene eine Quelle f ur Zusatzinformationen sein, die ein Nutzer bei Bedarf im UI bezarung eines Begri es ( uglich einer Kl¨ ahnlich eines interaktiven Thesaurus) konsultieren kann. Diese Assistenz ist vor allem mit Blick auf die wenig trainierten und unerfahrenen Einsatzkr aften von Vorteil. Die in Abbildung 5.16 unter comment hinterlegte Begri sbeschreibung des KB-Konzeptes Bereitstellungsraum“ kann beispielsweise bei Bedarf dem Anwender als Information " eingeblendet werden. 3. Wissensakquise und Reasoning (online) – Beobachtete Fakten der Einsatzlage k onnen gem aß der Terminologie der Wissensbasis abgespeichert werden. Dabei entsteht eine formale Repr asentation der Einsatzlage, die ein automatisches Ableiten von Wissen erlaubt (intelligentes Systemverhalten). Das Problem, wie in der Praxis das Wissen aß der Terminologie abgespeichert werden kann, wird in uber eine Einsatzlage gem¨ Casie pragmatisch durch den Einsatz der ICLs gel¨ ost. Durch die Arbeit mit den ICLs werden z. B. bereits bei den Rollen ubernahmen die Namen der entsprechenden Einsatzkruhrungskonzepten zugeordnet. Die afte den jeweiligen formal de nierten F automatische Auswertung der Item-Nachbedingungen und die manuell abgefragten query-Items sind weitere Quellen f ur eine Wissensakquise. Ein Beispiel der Reasoningfunktionalit autert. at ist in Abschnitt 6.1.4 erl Selbst wenn das verwendete Vokabular sich an einer Anwendungsontologie orientiert, sind in der BOS-Praxis immer noch Missverstuglich der Deutung einzelner Fachbe andnisse bez gri e zu erwarten. Da in einer Groschadenslage typischerweise mit unterschiedlich quali Grundlegende Konzepte und Designentscheidungen zierten Benutzergruppen zu rechnen ist, ist auch ein di erenziert ausgeprandnis agtes Verst fur BOS-aften zu erwarten ur BOS-eigene und fubergreifende Fachtermini bei den Einsatzkr (vgl. Wucholt et al. [WYM+11]). Die Verwendung einer einheitlichen Terminologie als Informationsquelle im Einsatz (Punkt 2.) ist daher besonders hilfreich zur Vorbeugung von begriichen Missverstat andnissen im BOS-Bereich. Wie solch eine Nachschlagefunktionalit in einem UI geeignet umgesetzt werden kann, soll nicht Gegenstand dieser Arbeit sein. Im Rahmen des SpeedUp-Projekts konnte diesbez uglich bereits eine Methode erarbeitet werden (siehe Wucholt et al. [WYM+11]), welche mit einer Analyse der inter-und intraorganisationalen Kommunikation in einem MANV-Szenario beginnt. Begleitet durch ¨ Beobachtungen ( Ubungen), Dokumentenanalysen (Dienstvorschriften, Regelwerke, Fachb asst sich so eine erste pr ucher) und durch das Mittel (narrativer) Interviews, laformale Modellierung des Wissensbereiches erreichen. Diese dient dann in einem n achsten Schritt einem sog. Knowledge Engineer als Ausgangspunkt einer formalen Modellierung. Die Ontologie selbst wird wiederum Bestandteil einer sog. Wissensbasis (WB) in einem wissensbasierten System (Knowledge Base System) sein (vgl. Abb. 5.17). Die Begri e Wissensbasis (WB), Wissensdatenbank und Knowledge Base (KB) werden in dieser Arbeit synonym verwendet. Abbildung 5.17: Kulturanalyse und Knowledge Engineering. Abbildung 5.17 skizziert die drei Schritte von der pr aformalen Modellierung hin zu der Nutzung in einer wissensbasierten Softwarekomponente. Die im Rahmen dieser Arbeit erstellte BOS-Ontologie dient ausschlielich als Beispiel einer konkreten Realisierung und muss f ur einen realen Einsatz noch auf die jeweiligen lokalen Besonderheiten und der ben otigten Anforderung hin erweitert/abge andert werden. 74 Kapitel 6 Technische Realisierung In diesem Kapitel werden das Casie-Architekturkonzept und das Zusammenspiel der einzelnen Komponenten dargestellt. Als Voraussetzung wird angenommen, dass bereits ein geeignetes (robustes) Kommunikationsnetzwerk existiert, worauf Casie mit seiner Funktionalit ¨ at aufsetzen kann. 6.1 Komponenten der Casie-Architektur In Abbildung 6.1 ist das vorgeschlagene Architekturkonzept von Casie zu sehen. CL-Manager (Engine) Inference System(FaCT++, RacerPro, etc.) T-Box (BOS-Ontologie) A-Box (Fakten über Einsatzlage) CL-Repository (CL-Schemata) CL-Logbook (Event-Logs + CL) DL Knowledge Base System Agenti ... Agent1 A t CL-Client Checkliste( n) Checkliste ..… … … ..… … … ..… … … CL-Client Checkliste( n) Checkliste ..… … … ..… … … ..… … … ... Agentn CL-Client Checkliste( n) Checkliste ..… … … ..… … … ..… … … CLs/CLH Checkliste ..… … … ..… … … ..… … … ..… … … Update ReasoningDokumentenpool für Zusatz-Materialien wie: Karten, Lagepläne, Text-Dokumente, Tabellen, Kataloge und Pläne GUI ... ... ..… … … ..12:37: Item 34 bestätigt. ..12:45: Start der Task a3$. ..12:45: Task a3 ist abgeschlossen. ..01:15: Task 3 abgebrochen. ..01:34: Bearbeitung CL3 abgebrochen. ..02:15: C12 vollständig abgeschlossen. ..12:37: Item 34 bestätigt. ..12:45: Start der Task a3$. ..12:45: Task a3 ist abgeschlossen. ..01:15: Bearbeitung CL5 abgebrochen. ..02:15: C12 vollständig abgeschlossen. ..… … … ..Zugriff CL-Repository ..Init. CL-Schemata und Aufbau der CLH ..Prozess-Monitoring ..Event-Monitoring ..Logging (Logbook) ..KB-Connector, Update & Reasoning ..Verbindungsaufbau & -überwachung zu CL-Clients bzw. System-Instanzen (E Abbildung 6.1: Meta-Architekturskizze der wichtigsten Casie-Komponenten. Eine fr¨ uhe Version dieses Architekturkonzeptes wurde bereits 2010 auf dem International Workshop on Emergency Management through Service Oriented Architectures (vgl. [KGK+10]) vorgestellt. Die hier gezeigte Variante stellt eine Verfeinerung des fr¨ uhen Konzeptes dar, wobei die automatische Planungskomponente durch eine Checklisten-Assistenz (CL-Manager) spezialisiert wurde. Die Servicekomponente aus [KGK+10] (S. 5 ff.), welche eine automatische Ausf¨oglicht, wurde in dieser Arbeit aus uhrung ausgesuchter Items erm¨ gespart. Prinzipiell kann, je nach Typ und Aufgabe der Items, auch eine Servicearchitektur, 75 Komponenten der Casie-Architektur z. B. durch Bereitstellung von sog. information gathering-und information propagation- Services, die Arbeit der Einsatzkr afte erleichtern. Datenbank-Management-System (DBMS) Runtime-Client Agentn ... Buildtime-Client Engine (+ Kernel) Agent1 Workflow-Modelle Metadaten Tools Modellierung, Validierung, Simulation, Debugging, Übersetzung, … Runtime-Client Arbeitsdaten Runtime-Komponenten Buildtime-Komponente(n) Shell Daten-Server, Kontrollfluss-Server, Benachrichtigungsserver, Applikationsserver, … work- to-do-list work- to-do-list ... Abbildung 6.2: Architektur eines WfMS (nach Klausner [Kla01]). Obwohl Checklisten in der Regel keine (reinen) Work ows1 darstellen (vgl. die Diskussion in Abschnitt 3 und zu Beginn des Kapitels 5), kann die Architektur von Casie mit der eines Work ow-Management-Systems (WfMS) (vgl. z. B. Klausner [Kla01], S. 5 .) verglichen werden. Abbildung 6.2 zeigt den Aufbau eines WfMS, wobei der zu Casie korrespondierende Bereich schraert gekennzeichnet ist. Vor allem das Konzept der work-to-do-lists (vgl. Abb. 6.2) ist mit dem der Itemlisten in Casie vergleichbar. Auch die distributed and intelligent to-do lists des Ansatzes von Wickler et al. (siehe [WTP06]) beruhen auf einem  ahnlichen Prinzip. Im Gegensatz zu einem WfMS steht in Casie jedoch keine automatische, sondern eine manuelle Ausf uhrung von Aufgaben im Zentrum. Es gilt, in einer Multiagentenumgebung physische Aktionen auszufafte dabei assistierend uhren und die Einsatzkr mittels Checklisten zu begleiten\. Eine vollstuhrung(-skontrolle) andige automatische Ausf " wird durch Casie nicht realisiert. Dokumentenpool Die in der Architekturgra k (Abb. 6.1) rechts auen angedeutete Komponente des zusane, Text-Dokumente, Ta atzlichen Dokumentenpools (Karten, Lagepl bellen, Kataloge, Plagt der Praxisanforderung Rechnung, eine Vielzahl von m ane) troglichen bzw. bereits verf ugbaren elektronischen Dokumenten genau an den Stellen zugreifbar zu machen, an denen sie als Hilfestellung auch wirklich angebracht sind. Die Realisierung einer geeigneten Zugri smugbaren Dokumente wird vorausgesetzt. oglichkeit auf die verf Ein Verweis auf die jeweiligen Zusatzressourcen wird in Casie uber das De nieren eines  entsprechenden Merkmals res() := fRess1, Ress2, :::} einer CL bzw. eines Items realisiert. Im Folgenden werden die einzelnen Casie-Architekturkomponenten mit ihren Funktionen vorgestellt. Wie diese in einem reaktiven und wissensbasierten System zusammenspielen, wird im Anschlussabschnitt 6.2 erl autert. 1 Als Work ow (-Instanz) wird nach Jablonski [Jab95], eine ausf uhrbare Beschreibung bzw. Abbild ” eines Gesch aftsprozesses“ verstanden. Komponenten der Casie-Architektur 6.1.1 CL-Client, Benutzerschnittstelle und Endgerate Der sog. Checklisten-Client (kurz CL-Client) stellt als eine der Runtime-Komponenten die Funktionalitaften bereit. Jeder CL-Client kommuniziert dabei aten der ICL den Einsatzkr mit dem CL-Manager, von dem er mit Daten versorgt wird und der die Dynamik steuert. Abbildung 6.1 abstrahiert das Detail der technischen Aufteilung der Architekturkomponenten auf die eingesetzten Endgerasst bewusst o en, ob jedes Endger ate. Die Abbildung lat, auf dem der CL-Client l auft, auch zugleich alle restlichen Komponenten bereitstellen muss. Ob sich der CL-Client und der CL-Manager auf ein und demselben Rechner be nden oder aber auf unterschiedliche Rechner im Netzwerk verteilt sind, hahl angt von der konkret gew ten Umsetzung der Casie-Architektur ab. Aus der Perspektive der Komponentenverteilung kommen folgende zwei Grundvarianten der Architekturumsetzung in Betracht: 1. Stand-Alone-Variante – Jedes Endgerugt  at verfuber eine komplette Implementierung aller Casie-Komponenten in einer einzigen Applikation bzw. auf einem Endger at. Jedes Endgerotigt 2. Network-Variante – at bennur“ einen CL-Client und eine Netz” ¨ werkanbindung. Uber das Netzwerk kann sich der Client an einen verf ugbaren CL- Manager anmelden und seine Dienste in Anspruch nehmen. Welche der beiden Varianten in der Praxis einsetzbar ist, h angt von der jeweiligen Implementierung und der zu erwartenden Netzwerkabdeckung ab. Im SpeedUp-Projekt hat sich eine Variante der ersten L osungen als vorteilhaft herausgestellt (siehe Abschnitt 6.2), bei der auf jedem Endger at eine komplette Instanz aller Architekturelemente des SpeedUp- Demonstrators untergebracht wurde. Dies hat den Vorteil, dass das System unabh angig von einer bestehenden Netzwerkverbindung autonom arbeiten kann. Kann ein System w ahrend einer Groschadenslage eine Verbindung zu einem zweiten System aufbauen, so k onnen diese dann ihre bis dahin aggregierten Daten abgleichen. Dies ist eine Anforderung, die sich aus der Einsatzcharakteristik einer Groschadenslage direkt ableitet und daher auch f ur die konkrete Casie-Implementierung beachtet werden sollte. F¨ ur die Stand-Alone-Variante (und den Datenaustausch in der Network-Variante) ist die Anwendung verschiedener Netzwerktopologien m oglich. Beispielsweise kann ein zentraler Server alle CL-Clients bedienen (at uberwachen) oder aber ein dediziertes Endgeratzlich die Aufgabe des Servers f ubernimmt bei bestehender Netzwerkverbindung zusur alle CL-Clients, die im Einsatz sind. In der Network-Variante wird die Verbindung einzelner CL-Clients untereinander (bzw. mit einer zentralen Verwaltungskomponente)  uber ein zuvor etabliertes Kommunikationsnetzwerk realisiert. In diesem Fall ben otigt der Nutzer als Mindestanforderung nur einen auf das eingesetzte Endger at (PC, Notebook, Tablet) zugeschnittenen Client und eine Netzwerkverbindung. Gem aß des klassischen Client/Server-Prinzips [Gei95] nutzt der Client dann die von einem dedizierten CL-Manager innerhalb eines Netzwerkes bereitgestellten Funktionalit aten (siehe CL-Manager weiter unten). Der BOS-Bereich ist ein stark heterogener Bereich, was sich auch in der vorhandenen IT-Unterst utzung widerspiegelt. Ziel einer konkreten Casie-Implementierung sollte daher eine mangigkeit bez oglichst hohe Plattformunabhuglich der eingesetzten Systeme sowie eine breite Unterstoglicher Ger utzung mateklassen sein. Abbildung 6.3 skizziert von Tablet-PCs oglicher Ger uber normale Desktop-PCs bis hin zu Smartphones ein Spektrum mateklassen. Weiterhin ist an eine Druckeranbindung als R“ und/oder zu Back-Up-und uckfallebene ” Dokumentationszwecken als notwendiges Kriterium f ur einen Praxiseinsatz zu denken. Komponenten der Casie-Architektur Obwohl die Gestaltung einer geeigneten grafischen Benutzerschnittstelle (engl. graphical user interface, kurz GUI) nicht Zielstellung dieser Arbeit ist, sollen im Folgenden einige allgemeine Aspekte und Anforderungen an diese zusammengefasst werden. Benutzerschnittstellen (UI) / Geräte zur CL-Engine Abbildung 6.3: M¨aten. ogliche Klassen von Endger¨ F¨ur die ur einer Casie-Implementierung stellt sich die Aufgabe, jeweils eine geeignete GUI f¨ Buildtime-und eine f¨ur die Modellierung der ur die Runtime-Komponenten zu realisieren. F¨ Dom¨ anenontologie (mit Rollen und Organisationsstruktur) kann auf vorhandene Werkzeuge (wie z. B. den Ontologieeditor Prot´eg´uckgegriffen werden. F¨ e) zur¨ur die Konfiguration der Checklisten bedarf es hingegen neuer Softwarewerkzeuge, die auf die jeweiligen Anwender zugeschnitten sind. Peinel et al. schlagen hierzu z. B. in [PRW12b] einen webbasierten Editor vor, mit dem Einsatzkr¨ afte SOPs bzw. Checklisten in elektronischer Form ablegen und organisieren k¨ onnen. ...... Zugriff auf Zusatz- material: ................ Rollenauswahl (Master-)Checkliste der Rolle: ‘Technische Einsatzleitung (TEL)‘ CL-Hierarchie (automatisch generiert) Item verbergen Zeit des Itemchecks (z.B. für das Logbuch) action-Item einer delegierten Aktion, die längere Zeit in Anspruch nimmt Bereitstellung einer Erläuterung (desc) über das “Fragezeichen”-Icon Abbildung 6.4: Eigene Studie eines m¨ oglichen GUI (vgl. [KWB12]). Wie die Erfahrungen des SpeedUp-Projekts zeigten, besteht bereits bei der Konfiguration eines solchen Systems ein sehr hoher Usability-Anspruch an die eingesetzten Softwarewerkzeuge. Da zudem im BOS-Bereich nicht davon auszugehen ist, dass alle Nutzer erfahren im Umgang mit Computern sind, und da sich die Arbeitsumgebungen und -bedingungen teilweise recht widrig gestalten (wechselnde Lichtverh¨alte, Hitze, altnisse, Regen, Schmutz, K¨ Komponenten der Casie-Architektur Stress), leitet sich die Notwendigkeit einer m¨ zu oglichst einfach bedienenden Benutzerschnittstelle ab. Nicht zuletzt um der Akzeptanzproblematik entgegen zu wirken, sollten die Werkzeuge den Einsatzkroglichen, ihr eigenes CL-Repository m aften ermoglichst einfach einzup egen und zu warten. Erfahrungen der SpeedUp-Praxis zeigten dar uber hinaus, dass sich die Fafte eine einheitliche Benutzerschnittstelle f uhrungskrur die Buildtime-und Runtime-Komponenten w unschen. Eines der Designziele sollte daher darin liegen, die notwendige Interaktion mit dem System auf ein Minimum zu beschr anken. Die Verknasst sich in einem GUI auf mindestens upfung der einzelnen CLs einer CLH l zwei Arten visualisieren. So k onnen z. B. ausgehend von einer MCL alle Items der Sub-CLs (der kompletten Hierarchie) in einer Baumstruktur visualisiert werden (siehe Beispiel in Abb. 6.4). Oder es k onnen alle Checklisten einer Hierarchie jeweils separat dargestellt werden. Die Darbietung aller Items f ur eine MCL, in Form einer achen Liste, wird bei groen und komplexen Hierarchien zu un ubersichtlich und sollte daher keine Option sein. Eine m ogliche Itemreihenfolge sollte im Benutzerinterface der Ordnungsconstraints () folgen. Foglichkeiten der seriellen Darstellungen. ur jede partielle Ordnung existieren mehrere M Abbildung 6.4 zeigt eine M oglichkeit einer Umsetzung, die im Rahmen dieser Arbeit prototypisch entwickelt wurde. Bedingte Items sind in der Abbildung nicht beachtet. Welche Darstellungsformen konkret den Kriterien einer angestrebten Benutzerfreundlichkeit entsprechen, kann letztendlich nur eine Evaluierung verschiedener Konzepte in der Praxis zeigen. In dieser Arbeit soll der sich dadurch er o nende eigene Themenkomplex nicht weiter vertieft werden. Vielmehr wird im Folgenden vorausgesetzt, dass geeignete Werkzeuge zur Kon guration der Checklisten und der Ontologie vorhanden sind und von den BOS-Mitarbeitern (mit oder ohne Hilfe von Experten) bedient werden k onnen. 6.1.2 CL-Manager Der CL-Manager stellt die zentrale Steuereinheit in Casie dar. Je nachdem, ob ein CL- Client f ur eine Einsatzkraft isoliert genutzt wird (Single-User-Modus, kurz SUM ) oder aber im Datenaustausch mit weiteren Clients (Multi-User-Modus, kurz MUM ) betrieben wird, steht ein eingeschr ankter bzw. der volle Funktionsumfang dem Nutzer bereit. Folgende Funktionalitugung. aten stellt der CL-Manager einem CL-Clienten zur Verf • Zugriff auf Repository – Der CL-Manager ermoglicht den CL-Clienten einen wahl- freien Zugriff auf alle hinterlegten (relevanten) CL-Schemata (siehe n achsten Unterabschnitt). • Prozess-Monitoring { Der CL-Manager uberwacht den Status aller Checklisten (von ¨ der Aktivierung bis zum Ende der Bearbeitung) und kann somit einen Uberblick aß des uber alle abgeschlossenen, abgebrochenen und noch laufenden Prozesse gem ¨ Prozesskontextes der ICL liefern. Dies wird durch die Uberwachung aller Client- Ereignisse und aller externen Ereignisse (ausgel ost durch andere Casie-Instanzen im Multi-User-Mode) erreicht. • KB-Connector { Alle uber den Client erfassten Informationen uber die Einsatzlage werden vom CL-Manager erfasst und zur Erweiterung der KB genutzt. Zu den Informationen zatigten Items bzw. bereits abgeschlossener ahlen die E ekte der best Checklisten. Ein automatisches Schlieen ur situationsange uber die Informationen f¨ passte ICL wird so erst erm¨ oglicht. • Logging/Dokumentation – Durch das automatische Speichern von Informationen  uber die Statuswechsel der aktiven CL und deren Items ist der CL-Manager in der Lage, Komponenten der Casie-Architektur einen Logging-Mechanismus zu Dokumentationszwecken bereitzustellen (siehe n¨ achsten Abschnitt). ¨ • Network-Manager – Der Verbindungsaufbau und die Uberwachung der Ereignisse anderer Clients erm¨ubergreifende Zusammenf¨ oglichen eine einsatz¨uhrung und Beachtung aller durch die Arbeit mit den Checklisten gewonnenen Informationen. Auf die einzelnen Funktionsbereiche, die das reaktive Systemverhalten von Casie bestimmen, wird im kommenden Abschnitt 6.2 genauer eingegangen. 6.1.3 CL-Repository & -Logbook Im Checklisten-Repository ist die Menge aller erarbeiteten Checklisten hinterlegt. Hierzu k¨ onnen die Checklisten jeweils lose in einer geeigneten Datenstruktur organisiert werden. Da selbst bei einer gr¨ oßeren Anzahl vorgehaltener Checklisten der zu erwartende Datenumfang relativ gering ausf¨osungen f¨ allt, bedarf es keiner besonderen L¨ur große Datenmengen. Die Dom¨onnen mittels eines Build-Time-Editors (welcher an dieser Stelle anenexperten k¨ nicht n¨autert wird) ihre eigenen CLs erstellen, ¨oschen. Die Speicherung aher erl¨andern und l¨ ¨oglichkeit stellt uber das Dateisystem der Plattform ist hierbei ausreichend. Eine einfache M¨ z. B. eine Menge von Dateien dar, bei der jede Datei f¨ ur eine einzelne Checkliste steht. Die Checklisten k¨ onnen zentral vorgehalten werden, was eine Pflege und Aktualisierung erleichtert. Als Build-Time-Komponente kann die Erstellung der CLs z. B. ¨ uber eine Tabellenkalkulationsanwendung g¨oglicht den Einsatzkr¨ angiger Office-Produkte erfolgen. Dies erm¨aften die Konfiguration des Repositories unter Verwendung g¨ angiger Softwareumgebungen. CL-Manager CL-Repository (CL-Schemata) Checkliste ..… … … ..… … … ..… … … ..… … … Buildtime-Client(s) BOS-Ontologie Vokabular & create, update, delete Checkliste ..… … … ..… … … ..… … … ..… … … Checkliste ..… … … ..… … … ..… … … ..… … … Lagemerkmale Domänenexperten Abbildung 6.5: Die Komponente des CL-Repository. Die Komponente CL-Logbook steht f¨ ur eine digitale Variante eines Einsatztagebuches, in der Informationen ¨uglich der laufenden und bereits erledigten uber die Lageentwicklung bez¨ Handlungen protokolliert werden k¨ onnen. Der CL-Manager aggregiert hierzu die Informationen ¨ uber die vom CL-Client registrierten Benutzeraktionen. Die so gewonnene Historie der Aufgabenabarbeitung leistet einen entscheidenden Beitrag zur Pflicht der Einsatzdokumentation, welche im BOS-Bereich einen hohen Stellenwert einnimmt (siehe Abschnitt 7.3). Jedem im Einsatz aktiven CL-Client kann sein eigenes Einsatztagebuch zugeordnet werden. Zus¨onnen durch das Anlegen verschiedener Eintragsschemata (Log-Modus) atzlich k¨ (siehe Abb. 6.6) eine auf die jeweiligen Anspr¨ uche des Anwenders zugeschnittene Form und der gew¨ unschte Detaillierungsgrad angegeben werden. Die Aggregation aller Informationen kann mittels einer dedizierten Logging-Komponente des CL-Manager erfolgen, welche alle relevanten Informationen z. B. in Form eines einfachen Logfiles im CL-Client abgespeichert. Tabelle 6.1 zeigt f¨oglichen internen Zustands¨ange einen entsprechen ur jeden der m¨uberg¨ den Beispieleintrag. Die genaue Auspr¨age im Logbuch l¨ agung der Eintr¨ asst sich je nach Komponenten der Casie-Architektur CL-Manager CL-Logbook … Export-Analog als Ausdruck Export-Digital in Form von Dateien bzw. Schnittstelle ..… … … ..12:37: Item 34 bestätigt. ..12:45: Start der Task a3$. ..12:45: Task a3 ist abgeschlossen. ..01:15: Task 3 abgebrochen. ..01:34: Bearbeitung CL3 abgebrochen. ..02:15: C12 vollständig abgeschlossen. ..12:37: Item 34 bestätigt. ..12:45: Start der Task a3$. ..12:45: Task a3 ist abgeschlossen. … … … Logging-Mod 1 Zeit Logging-Mod n Zeit ..… … … ..12:37: Item 34 bestätigt. ..12:45: Start der Task a3$. ..12:45: Task a3 ist abgeschlossen. ..01:15: Task 3 abgebrochen. ..01:34: Bearbeitung CL3 abgebrochen. ..02:15: C12 vollständig abgeschlossen. ..12:37: Item 34 bestätigt. ..12:45: Start der Task a3$. ..12:45: Task a3 ist abgeschlossen. … … … PDF, XML, TXT, o.Ä. P X Abbildung 6.6: Die Komponente des CL-Logbooks. Wunsch frei gestalten. Die Tabelle soll ein Gef¨ur vermitteln, welche M¨ uhl daf¨oglichkeiten eine automatische Loggingfunktion in Casie bietet. Event Beispiel-Schema f¨ur Eintr¨age eines Logbook init(cl) time Uhr: Start der Checklise name(cl). check(f) time Uhr: Item f best¨atigt. start(f) time Uhr: Start der Task (action-Item) name(f). finish(f) time Uhr: Task (action-Item) name(f) ist abgeschlossen. abandon(f) time Uhr: Task (action-Item) name(f) abgebrochen. cancel(cl) time Uhr: Bearbeitung von name(cl) abgebrochen. finish(cl) time Uhr: name(cl) vollst¨andig abgeschlossen. login(w) time Uhr: w ist am CL-Client mir der ID id angemeldet. fulfil(w) time Uhr: w ¨ubernimmt Rolle name(r). Tabelle 6.1: M¨age. ogliches Schema der Logbook-Eintr¨ Die beiden letzten Eintr¨ age in der Tabelle 6.1 beziehen sich bereits auf die Interaktion eines Nutzers mit dem System selbst. Im kommenden Abschnitt 6.2 werden die Loggingfunktionalit ¨aher erl¨ at und die Events n¨autert. 6.1.4 Knowledge-Base (System) / BOS-Ontologie In Casie soll der Wissensbereich der BOS-Dom¨ ane in Form einer formalen Ontologie modelliert werden. Unter einer Ontologie wird in der Informatik eine explicit specification ” of a conceptualization“ ungeren Zeit [Gru93] eines Wissensbereiches verstanden. In der j¨ wurde der formale Aspekt einer solchen Spezifikation herausgehoben und obige Definition zu explicit and formal specification of a conceptualization“ erweitert [AH04]. Die Begrif ” fe BOS-Ontologie, Anwendungsontologie, Dom¨ anenontologie und Ontologie werden in der weiteren Arbeit, wenn nicht explizit eingeschr¨ ankt, synonym verwendet. Ein wesentliches Merkmal der Casie-Architektur liegt daher darin, die formale Spezifikation des ontologischen BOS-Dom¨asentieren und als Wissensbasis anenwissens im Rechner geeignet zu repr¨ zu nutzen. Das so modellierte Wissen ist konform seiner Bedeutung maschinell verarbeitbar (machine processable), wodurch sich vor allem die M¨uber die oglichkeit ergibt, automatisch ¨ Menge der vorhandenen Fakten der Wissensbasis schließen zu k¨ onnen. Der oft statt machine processable unsauber verwendete Ausdruck machine understandable sollte vermieden Komponenten der Casie-Architektur werden, da er ein wirkliches Verstehen im Sinne des menschlichen Verstandes suggeriert, wovon jedoch im Rechner keine Rede sein kann. Konkret wird Casie durch den Aufbau einer Wissensbasis in die Lage versetzt, die G¨ ultigkeit der Anwendungskriterien von ICLs und der Vorbedingungen der Items automatisch zu evaluieren. Falls die Qualit¨at der Datenlage es erm¨ at und die Quantit¨oglichen, kann diese zu einer intelligenten, lagekonformen Anpassung der ICLs genutzt werden (siehe Abschnitt 6.2). ¨ Ein weiterer Vorteil dieser Art der Modellierung liegt darin, dass Anderungen am Dom ¨oglich sind, da anenmodell (in der Regel) ohne eine Anpassung der Programmlogik m¨ das Wissen uber die Anwendungsdom¨angig von der jeweiligen Programmlogik ¨ane unabh¨ (CL-Manager) realisiert ist. In der KI werden Systeme, in denen deklaratives Wissen einer Dom¨ ane von der Programmlogik getrennt wird, als wissensbasierte Systeme oder auch Knowledge Base Systems bezeichnet. Die Abbildung 6.7 skizziert den Aufbau einer Wissensbasis (Knowledge Base) als die zentrale Komponente eines solchen Systems. Inference System Knowledge Base (System) TBox (Schema) ABox (Daten) Patient =Person....hat.Verletzung Einsatzkraft =Person....gehörtZu.BOSLNA = Notarzt ....leitet.EinsatzNotarzt(‘Dr. Müller’) hatRolle('Dr. Müller'‚ 'LNA' ) beteiligtesGefahrgut(‘Blausäure’) leitet(‘Dr. Eilig’, ‘Behandlungsplatz’) Bsp. Fakten (Assertions) über Einsatzlage Bsp. Axiome der BOS-Ontologie Knowledge Base CL-Manager Tell Assertion (Update) Ask (Reasoning) Abbildung 6.7: Architektur eines Knowledge Base Systems (KBS) (nach Baader [BCM+03]). Eine formale Wissensbasis besteht aus einer TBox (das T steht f¨Terminology) und ur einer ABox (das A steht f¨alt axiomatische De ur Assertions) [BCM+07]. Die TBox enth¨ finitionen (terminologisches Wissen) aller Konzepte und deren Beziehungen untereinander – in dieser Arbeit z. B. bereitgestellt durch eine BOS-Ontologie. Sie stellt das Vokabular des Anwendungsgebietes bereit und legt fest, welche Relationen zwischen den Instanzen der Konzeptklassen bestehen. In der ABox wird mit den Sprachmitteln der TBox Faktenwissen (Assertions)¨ uber Individuen (Objekte der Welt) abgelegt. Die ABox beinhaltet Informationen ¨ane). Um uber einen konkreten Zustand der Welt (der Anwendungsdom¨ die Wissensbasis nutzen zu k¨ onnen, bedarf es der Anwendung entsprechender Schlussfolgerungssysteme (Reasoner). Das Ziel der logischen Inferenz ist es, zu entscheiden, ob aus einer gegebenen Wissensbasis KB die G¨ ultigkeit einer gegebene Formel . ableitbar (logisch inferierbar) ist, geschrieben KB |= .. Alle Komponenten zusammen, stellen ein KB-System dar. Die KB-Komponente stellt eine sog. Tell/Ask-Schnittstelle zum CL-Manager bereit, ¨onnen (Tell) und ¨ uber die Fakten der Welt der KB mitgeteilt werden k¨uber die Anfragen ¨ultigkeit einer Formel . gestellt werden k¨ uber die G¨onnen (Ask) [BCM+07]. Abbildung 6.7 stellt dies schematisch dar. Auf der rechten Seite sind jeweils Beispiele von Axiomen bzw. Assertions gegeben. Das Axiom Patient Person .hat.Verletzung definiert z. B. ein Konzept Patient, zu dem Individuen z¨ ahlen, die eine Person sind und zugleich eine Verletzung aufweisen. Eine konkrete Beobachtung, z. B. dass Dr. M¨ uller die Rolle des LNA ¨uller’,’LNA’) repr¨ubernommen hat, wird in der ABox als Assertion hatRolle(’Dr. M¨asentiert. Als Sprachmittel zur terminologischen Wissensrepr¨ asentation hat sich in der KI-Forschung der Einsatz von Beschreibungslogik (Description Logic, DL) etabliert. DL steht f¨ei ur Komponenten der Casie-Architektur ne ganze Familie von Formalismen zur Wissensrepr asentation (Knowledge Representation, KR), deren Urspr unge in der Forschung zu semantischen Netzen und Frames (siehe Minsky, [Min75]) liegen. Frasentationssysteme (siehe z. B. uhere objektzentrierte Wissensrepr Schmolze et al. [SBI85]) verfugten noch nicht uber eine formale Semantik. Dies f uhrte zur Entwicklung entsprechender Sprachformalismen wie DLs, die ausdrucksst arker als die Aussagenlogik (propositional logic), aber noch nicht so komplex wie die volle Pr adikatenlogik 1. Stufe (PL1) ( rst-order predicate logic, FOL) sind, sodass einige interessante Entscheidungsprobleme (und damit Schlussfolgerungen) e ektiv berechnet werden k onnen (vgl. z. B. [BHS08]). DL stellt wegen ihrer Beschrare Pr ankung auf binadikate und den Verzicht auf Funktionen eine entscheidbare Untermenge der PL1 dar. Ein einfaches Beispiel soll den prinzipiellen Zusammenhang von PL1 und DL verdeutlichen. Angenommen wir wollen folgenden Sachverhalt modellieren: Ein Leitender Notarzt ” ist ein Notarzt, der einen Einsatz leitet\. Formalisiert in PL1 lautet er, wie folgt 8x. [LeitenderNotarzt(x) . Notarzt(x) ^9y. [leitet(x, y) . Einsatz(y)]] . Die Syntax der Description Logic erlaubt, den gleichen Sachverhalt einfacher und in einer pr agnanten, variablenfreien Syntax zu notieren: LeitenderNotarzt . Notarzt u9leitet.Einsatz . Im Beispiel wird das Konzept LeitenderNotarzt durch Zuhilfenahme bereits de nierter Konzepte (Notarzt und Einsatz) und deren Relationen (hier z. B. leitet) neu de niert. Eine Ontologie l asst sich als eine Sammlung von DL-Axiomen obiger Beispielstruktur verstehen. Das zentrale Element jeder Ontologie stellen die Konzepte (auch Klassen genannt) und die Relationen (auch Rollen oder Eigenschaften genannt) zwischen den Konzepten der Anwendungsdom ane dar [NM01]. (Dieser Rollenbegriff darf nicht mit dem in Casie eingef uhrten Begriff der Rolle einer Einsatzkraft (vgl. Def. 2) verwechselt werden.) Zum Beispiel kann die Klasse Patient alle Verletzten und Erkrankten in einem MANV repr asentieren. Ein konkreter Patient ist diesbez uglich ein Individuum, eine Instanz dieser Klasse. Je nach Modellierung und Anforderung k onnen Konzepte auch abstrakte Dinge wie z. B. eine Schadenslage oder ein Gefahrenpotential repr asentieren. Spezialisierungen zu Konzepten konnen in Form von Subklassen realisiert werden. Zum Beispiel ware das Konzept Verletzter eine Subklasse (sub-class) von Patient und dieses wiederum von Person. Durch Relationen werden Eigenschaften von Klassen und Beziehungen zwischen konkreten Instanzen beschrieben. So kann z. B. eine Relation hatDiagnoseGestellt zwischen der Klasse Patient und Notarzt de niert werden. Ein konkreter Patient kann so sp ater in Beziehung zu seinem diagnostizierenden Notarzt gebracht werden. Es handelt sich in diesem Beispiel um eine binagung z. B. hatDia are Relation hatDiagnostiziert(Notarzt,Patient), deren konkrete Ausprgnostiziert('Dr. Eilig','Max Mustermann') lauten kuhrliche Abhandlung zum onnte. Eine ausf Thema Ontologien und Beschreibungslogik l asst sich z. B. in [SS04] bzw. [BCM+07] nden und soll nicht Gegenstand dieser Arbeit sein. Die Wahl einer konkreten Ontologiesprache Bez uglich des theoretischen Hintergrundes von DL und KBS stellt sich die Frage der Umsetzung in einem entsprechenden Softwaresystem. Eine konkrete Realisierung von DL stellt eine Variante der Web Ontology Language (OWL) dar, f ur die mittlerweile eine Vielzahl hilfreicher Softwarewerkzeuge existieren. Die Sprache ist eine Weiterentwicklung der Ontologiesprache DAML+OIL (siehe [DAML]). Bei der Entwicklung der Sprache hatte das Forschungsgebiet der Beschreibungslogiken einen groen Ein uss, vor allem was die formale Komponenten der Casie-Architektur Semantik, die Wahl der Sprachkonstruktoren und die Integration der Datentypen und spezieller Werte anbelangt [HPM+07]. OWL ist eine semantische Auszeichnungssprache (Markup- Sprache), die urspro entlichung und zum Austausch von Ontologien im unglich zur Ver World Wide Web (WWW) entwickelt wurde. Durch eine relativ gute Tool-Unterst utzung und die theoretische DL-Basis ist OWL auch auerhalb des WWW-Umfeldes als Mittel der Wahl zur Ontologieentwicklung weit verbreitet. Mit OWL k onnen Klassen (Classes), Eigenschaften (Properties) und Instanzen (Individuals) beschrieben werden. Die Klassen stehen fonnen. Instanzen sind ur die Konzepte, welche spezielle Eigenschaften besitzen k Individuen einer oder mehrerer Klassen. Die OWL-Spezi kation2 unterscheidet zwischen den drei zunehmend komplexen Sprachversionen (auch pro les genannt) OWL-Lite, OWLDL und OWL-Full. Da im Rahmen dieser Arbeit nur OWL-DL relevant ist, soll auf die beiden anderen Pro le nicht weiter eingegangen werden. OWL-DL (DLsteht hier f “ ur ” Description Logic) stellt einen ausdrucksstarken Sprachformalismus dar und ist  aquivalent zu der Beschreibungslogik SHOIN (D) [HPM+07]. Der praktische Einsatz von Beschreibungslogiken ließ in vielen Anwendungsbereichen den Wunsch aufkommen, Schlussfolgerungen anen mit einer xen (con uber spezielle Dom crete) Semantik fahlte Konzepte, wie Integer, Real oder String, nutzen zu k ur ausgewonnen. Ziel war es, konkrete Qualitur reale aten (wie z. B. Gewicht, Temperatur oder Entfernung) f Objekte der Welt einfacher zu modellieren und verarbeiten zu kog onnen. Um dies zu erm lichen, wurden die DL-Reasoner um die Muber diese sogenannten oglichkeit des Schlieens  Concrete Domains (kurz D) erweitert. F ur weitere Details sei z. B. auf [BH91; HMW01; Lut03] verwiesen. Folgende Au istung soll speziell f ur SHOIN (D) die charakteristischen Sprachbestandteile wiedergeben (siehe Description Logic Complexity Navigator [DLCN]): S – ur transitive Rollen (Rollen-Axiom): T rans(R). steht f H – steht f ur Rollen-Hierarchie (Rollen-Axiom): R . S. O – steht fur eine Menge von Indiur sog. Nominale (abgeschlossene Klassen), d. h. f¨ viduen a1, :::, an ist fa1, :::, an} ein eigenes Konzept. I – ur inverse Rollen: R.. steht f. N – ur eine (unquali ed) number restrictions:(= nR), (= nR). steht f • D – steht f ur Concrete Domains. Obige Sprachbestandteile ermanenmodell zu erstellen. oglichen es, ein sehr detailliertes Dom Die im Rahmen dieser Arbeit beispielhaft umgesetzte BOS-Ontologie (siehe [BOS-O]) nutzt direkt (oder indirekt) all diese Sprachbestandteile, indem es die entsprechenden OWL ¨ Konstrukte verwendet. In den Abbildungen 6.8 und 6.9 wird die Aquivalenz ausgew ahlter OWL-Konstrukte (linke Spalte) mit der entsprechenden korrespondierenden DL-Syntax aufgezeigt, erg anzt um eine jeweilige FOL-Variante bzw. Beispiele. Die Praxiserfahrungen mit OWL fungster Zeit zu dem Wunsch nach Erweite uhrten in j rung des alten OWL-Standards und schlielich zu einer  uberarbeiteten OWL-2-Spezi kation [OWL2]. In OWL 2 wurden zus atzliche ontologische Axiome zur Steigerung der Ausdruckskraft eingef uhrt. Des Weiteren wurden nichtlogische Erweiterungen, z. B. bei Syntax und ¨ Metadaten, und eine Uberarbeitung der OWL-Varianten (Lite/DL/Full) vorgenommen. Durch die Erweiterungen hat sich auch die DL-Basis von SROIN (D) zu SROIQ(D) geandert (erweitert). An dieser Stelle soll auf eine detaillierte Vorstellung von OWL 2 verzichtet werden (siehe [OWL2]). 2 siehe http://www.w3.org/2004/OWL/ (abgerufen am 01.12.2013) Komponenten der Casie-Architektur Abbildung 6.8: OWL-Konstruktoren vs. DL (Quelle: [BHS08]). Abbildung 6.9: OWL-Axiome vs. DL (Quelle: [BHS08]). ur diese Arbeit relevant ist jedoch die Tatsache, dass ab OWL 2 eine explizite Angabe negierter Relationen (z. B. ¬ hatDiagnostiziert('Dr. Eilig','Max Mustermann')) moglich ist.  Fur Casie ist dies vor allem bei der Aufnahme von Beobachtungen der Fakten  F uber die Welt von Interesse, bei denen ein explizites Nichtzutre en eines bestimmten Merkmales im System aufgenommen werden soll. Zum Beispiel kann der Fakt, dass kein Gefahrgut bei einem Grobrand mit beteiligt ist (¬ beteiligtGefahrgut('MANV-A7')), somit in Casie explizit repr asentiert werden. Dieser Fakt hat mehr Aussagekraft als das bloe Nichtwissen, ob Gefahrgut beteiligt ist oder nicht. Folgende zwei Punkte sprechen zusur den atzlich f Einsatz von OWL-DL als Repr asentationssprache in Casie: 1. Entwicklungstool-Support. Da OWL in der j ungsten Zeit als quasi de facto Standard fdie Ontologieentwicklung auch auerhalb des Einsatzes in der Semantic ur Web Vision annoncierte, existieren mittlerweile einige m¨ achtige Softwarewerkzeuge zur Entwicklung und Integration von OWL-Ontologien. Zu nennen sei hier z. B. der Ontologieeditor Protege [Protege] und die OWL API [HB11]. 2. Formale Semantik. Da sich die wohlde nierte Syntax der Sprachelemente von OWLDL auf die entsprechende Syntax der Beschreibungslogik SHOIN (D) abbilden l asst, k onnen Schlussfolgerungsmechanismen der Beschreibungslogiktheorie auf die Ontologie angewandt werden. Dies ist nur muber eine formale Semantik oglich, da DL ¨ verf¨ ugt. Des Weiteren existiert eine Reihe von Reasonern wie z. B. [Racer], [FaCT++] und [Pellet], die als Beschreibungslogikdialekt OWL-DL unterst utzen. Komponenten der Casie-Architektur Abbildung 6.10: TBox-Auszug der BOS-De nitionen aus [BOS-O]. Modellierung und Reasoning-F ahigkeiten In diesem Unterabschnitt wird das Grundprinzip hinter der Reasoning-Funktionalit at und den dazu notwendigen TBox-Axiomen anhand eines einfachen Beispiels illustriert. Stellen wir uns vor, wir wollen in Erfahrung bringen, welche BOS alle in einer Groschadenslage rettungsdienstliche Aufgaben inne haben. D. h., wir wollen wissen, welche BOS bei der Behandlung von Patienten involviert sind, um z. B. nur ihnen wichtige Erkenntnisse uber  einen Giftstoff zukommen zu lassen. Dies stellt ein Beispiel einer Competency Question dar (vgl. Schritt 1 im vorhergehenden Abschnitt), welche die Ontologie in der Lage sein sollte, zu beantworten. Vorausgesetzt, es sind alle konkreten BOS am Einsatzort ihrem allgemeinen BOS-Typ zugeordnet, liee sich obige CQ durch Au istung aller Individuen erreichen, die der Klasse Hilfsorganisation zugeordnet sind (vgl. Abb. 6.10). Konkret handelt es sich hierbei um eine zusammengesetzte Reasoningaufgabe (vgl. hierzu [BCM+03; BCM+07]). In einem ersten Schritt muss mittels Klassi kation (Classi cation) das Hasse-Diagramm der Subsumtions-Relationen vT bez uglich einer gegebenen TBox T berechnet werden. Somit erhis alt man im oberen Beispiel all die Klassen, die direkt per ” a\-Relation zur Klasse Hilfsorganisation zugeordnet sind, und zus atzlich jene, die indirekt aufgrund entsprechender TBox-Axiome ebenfalls unter die gesuchte Klasse subsumiert werden. In einem zweiten Schritt werden  uber die Menge der Individuen diejenigen berechnet, die in eine der gesuchten Klassen fallen. Letztere Aufgabe ist ein Inferenzproblem bez uglich Zusicherungen in der ABox. Alle Individuen einer Klasse zu ermitteln, wird  uber Retrieval erreicht (siehe [BCM+03]). Retrieval bezeichnet die Berechnung der Menge IA;T (C) von Individuennamen a 2A,f=T C(a). Vorausgesetzt, gegeben ist eine ABox A, ur die gilt: A j eine TBox T und ein Konzept C. In der Praxis  ubernehmen jedoch nicht nur Hilfsorganisationen wie das DRK oder der ASB rettungsdienstliche Aufgaben. Auch Feuerwehren und die Bundeswehr kur onnen hierf in Frage kommen (vgl. Kapitel 2). Die Abfrage nur auf die Klasse Hilfsorganisation zu beschr anken, ist daher ungeeignet. Eine Erweiterung auf die gesamte Klasse der BOS ist hingegen zu weitreichend, schlielich kann es auch Hilfsorganisationen oder Feuerwehren in einem Einsatz geben, die nicht in die Patientenbehandlung involviert sind. Die De nition Komponenten der Casie-Architektur einer Klasse der Rettungsdienstorganisation ist hierfosung, andere L ur eine Losungen sind ebenfalls denkbar. Abbildung 6.11: Beispiel eines Reasoningergebnisses (Protege). Folgendes TBox-Axiom de niert eine neue benannte Klasse auf Basis von BOS, die einen Fahrzeugtyp der Klasse Rettungsdienstfahrzeug am Einsatzort angemeldet haben. : Rettungsdienstorganisation = BOS u9fahrzeugGeh ortZuBOS...Rettungsdienstfahrzeug. Abbildung 6.12: Explanation Schlussfolgerungsergebnis (Protege). Abbildung 6.11 zeigt ein entsprechendes Reasoningergebnis, so wie es mittels Protege auf Basis eines Reasoneres (hier HermiT OWL Reasoner, siehe [MSH09]) berechnet und angezeigt wird. Das Axiom selbst ist in der Manchester Syntax zu sehen, welche eine alternative Schreibweise der DL-Syntax darstellt. Das Beispiel stammt aus der BOS-Ontologie [BOSO], in der einige Individuen als Beispiel abgelegt sind. Zu sehen sind drei Individuen, die als Members der Klasse Rettungsdienstorganisation ermittelt wurden. Eine Begr undung, warum z. B. das 'DRK Jena-Eisenberg-Stadtroda e. V.’ mit zu den gesuchten BOS zahlt, kann in Protege durch einen Click auf das Fragezeichen-Icon angezeigt werden. Abbildung 6.12 listet alle Fakten auf, die in ihrer Gesamtheit zur Ableitung gef uhrt haben. Die Stonnen bereits w arken logischen Schlieens kahrend der Modellierungsphase genutzt werden. Dadurch kungewollte Beziehungen (Relationen) und Inkonsistenzen auf onnen gedeckt werden. Automatische Schlussfolgerungen sind f ur folgende Anwendungsbereiche hilfreich: 1. Es kuchlich de nierte Konzepte der onnen Modellierungsfehler z. B. anhand widerspr¨ TBox erkannt werden. Dynamik / reaktives Systemverhalten 2. Die Struktur der Konzepthierarchie kann mittels Schlussfolgerung bez¨ uglich der Subklassenbeziehungen (is-a-Relation) zur besseren Darstellung explizit gemacht werden. Die Darstellung der Konzepthierarchie in Abbildung 6.19 ist ein Beispiel hierf¨ ur. 3. Schlussfolgerungen k¨onnen ungewollte Redundanzen finden, in dem z. B. zwei ¨ aquivalente Konzepte erkannt werden, die unter Umst¨ anden so nicht beabsichtigt waren. Der hier vorgeschlagene Ansatz geht weit ¨ uber die Bereitstellung eines bloßen Glossars, wie er z.B. in Peinel et al [PRW12b] vorgeschlagen wird, hinaus. So kann das Dom¨ anenwissen (Punkt 3.) als Schema genutzt werden, um ihm die Informationen einer taskorientierten Datenakquise w¨ ahrend eines Einsatzes zuzuordnen. Was genau unter taskorientierter Datenakquise zu verstehen ist und wie diese in Casie zur Gewinnung einer Lagerepr¨ asentation genutzt werden kann, wird im Unterabschnitt 7.3 erl¨ autert. 6.2 Dynamik / reaktives Systemverhalten Unter Zuhilfenahme der oben erarbeiteten Konzepte und Definitionen werden im Folgenden die wesentlichen Aspekte des dynamischen Systemverhaltens von Casie erl¨ autert. Eine den Anforderungen entsprechende Konfiguration (siehe Abschnitt 6.3) des Systems (Checklisten, Rollendefinitionen, Dom¨ anenmodell in der Wissensbasis) soll hierbei als gegeben vorausgesetzt werden. Vorerst wird sich auf die reine Anwendungsdynamik im Einsatz konzentriert. 6.2.1 Zustands¨ange einer Checkliste und deren Items uberg¨ Wesentliche Bestandteile der Modellierung des dynamischen Verhaltens reaktiver Systeme sind deren Zust¨ ande, in denen sich das System befinden kann, und die als Transitionen ¨ bezeichneten Zustands¨ange. uberg¨Uber ein Transitionssystem (englisch state maschine) k¨onnen die dynamischen Aspekte eines solchen Systems spezifiziert werden. Ziel ist es hierbei, die Zust¨ ande der Welt (speziell der Bearbeitungsstand der ICLs) durch interne Systemzust¨asentieren. ande in Casie zu repr¨ … … … … ..… … … ..… … … ..… … … ... … … … ..… … … ..… … … ..… … … Repository in Bearbeitung (Item-Checks) Prozess-Monitoring zur Runtime inactive active completed canceled … … … … ..… … … ..… … … ..… … … p ... … … … ..… … … ..… … … ..… … … ............................ Logbook Abbildung 6.13: Diagramm der m¨uberg¨ oglichen Zustands¨ange einer ICL. F¨ubergang einer Check ur Casie sind folgende drei Ereignisse definiert, die einen Zustands¨ liste bewirken: init() – Die Initiierung einer Checkliste aus dem Repository zeigt an, dass die zugeh¨ orige SOP begonnen wurde. Der Zustand der ICL wechselt von inactive auf active.Das Ereignis init() wird entweder durch eine aktive Auswahl einer Checkliste durch den Dynamik / reaktives Systemverhalten Benutzer selbst ausgel¨atigung eines automatischen Vorschlages von ost, durch Best¨ Checklisteninstanzen, welche dem Nutzer dargeboten werden, oder im Rahmen des automatischen Aufbaus eines CLH durch Casie selbst (siehe Abschnitt 6.2.2). finish() – Alle Items wurden vom Nutzer best¨atigt (siehe Item-Zust¨ ande“ weiter unten), ” oder der Nutzer deklariert die Checkliste als abgeschlossen“ (Status completed), ob ” wohl noch offene Items vorhanden sind. Die Aufgabenstellung der zugeh¨ origen SOP wurde den Gegebenheiten entsprechend erf¨ ullt. cancel() – Expliziter Abbruch der Bearbeitung durch den Benutzer, bevor alle Items bearbeitet/ beachtet wurden, d. h., die Aufgabenstellung der zugeh¨ origen SOP ist nicht mehr aktuell oder konnte nicht vollst¨unde f¨ andig abgeschlossen werden. Gr¨ur einen Abbruch sind der aktuellen Einsatzlage geschuldet und spielen an dieser Stelle keine weitere Rolle. ¨ In Abbildung 6.13 sind die m¨ande und deren ange durch die jeweiligen oglichen Zust¨Uberg¨ Ereignisse illustriert. Die Initiierung einer ICL ordnet eine entsprechende CL-Instanz einer Einsatzkraft zur Bearbeitung zu. Die ICL ist solange im Zustand active undwirdsomit in Casie ¨ uberwacht, wie keines der Ereignisse finish() bzw. cancel() eintritt. ..… … … ................… … … ......................................................................................: open ................: inprogress ................fail ................done ..… … … ................: ignor .......................................................................................................... p ..… … … ............: inprogress ..… … … Abbildung 6.14: Diagramm der Zustands¨ange eines Items. uberg¨ Auf der Ebene der Items werden die f¨ande open, inprogress, fail, done und ignor unf Zust¨ unterschieden (vgl. Def. 5). Um den f¨asen ur action-Items typischen zeitlichen Verlauf repr¨ tieren zu k¨ur diesen Itemtyp die Zust¨ onnen, sind in Casie speziell f¨ande inprogress und fail definiert. Nachfolgend sind die m¨uhrt, oglichen Ereignisse und deren Bedeutungen aufgef¨ die zu einem Zustands¨uhren k¨ ubergang eines Items f f¨onnen: check() – Durch das Abhaken eines Items wird dessen erfolgreicher Abschluss, d. h. dessen Ber¨ur ucksichtigung quittiert. Der Zustand wechselt von open zu done. check() ist f¨ alle drei Item-Typen (note, query, action)definiert. start() – Ist der Nutzer an einem bestimmten Prozessschritt angelangt, f¨ ur den ein actionItem in der zugeh¨ origen Checkliste definiert wurde, so kann er den Start (Ereignis start() ) dieses Schrittes best¨ atigen. finish() – Der Nutzer best¨ atigt den erfolgreichen Abschluss eines zuvor gestarteten action- Items. Der Zustand des Items wechselt von inprogress zu done. abandon() – Ist eine begonnene Aktion (repr¨ asentiert durch den Zustand inprogress)nicht abschließbar und muss daher aufgegeben werden, so quittiert dies der Nutzer explizit. Das dadurch ausgel¨ oste Ereignis abandon() setzt f auf den Zustand fail. Dynamik / reaktives Systemverhalten disable() – Sind die unter P re() angegebenen Vorbedingungen eines bedingten Items f nicht gegeben, so wird dieses auf den Status ignor gesetzt. Die Elemente aus P re() k onnen entweder manuell durch die Einsatzkraft oder aber (je nach Type) automatisch durch Casie evaluiert werden. enable() – ur ein bedingtes Item f im Status ignor (automatisch oder durch die Wird f Einsatzkraft) festgestellt, dass im Verlauf eines Einsatzes alle Vorbedingungen erf ullt sind, wird f wieder auf den Status open gesetzt. Die Abbildung 6.14 zeigt alle de nierten Ereignisse, die einen Zustands ubergang eines Items bewirken konnen. Die Rechtecke reprasentieren alle mande eines Items, w oglichen Zustahrend die Kanten die Zustandsange darstellen. Zus ubergatzlich zu dem bereits beschriebenen Systemverhalten werden die Informationen, die mittels eines query-Items vom Nutzer abgefragt werden k onnen, bzw. die bei der Itemde nition zuvor annotierten E ekte mit in die lokale Lagereprage in die KB aufgenom asentation durch entsprechende ABox-Eintr men. Die Magt der oglichkeit, bedingte Items (siehe S. 64) zu de nieren (kon gurieren) tr Bobachtung Rechnung, dass in vielen Eins atzen eine Vielzahl von zuvor bedachten Items keine Rolle mehr spielen. Diese Items werden dem Nutzer zwar zu Beginn pron asentiert, k nen jedoch manuell oder automatisch ausgeblendet werden, wodurch eine  ubersichtlichere Darstellung komplexer CLH erreicht werden kann. Event E ekt(e)/Systemverhalten check() Statuswechsel zu done und alle E ekte werden als Assertions in die ABox geschrieben. start() Statuswechsel zu inprogress und entsprechender Logbucheintrag. abandon() Statuswechsel zu fail und Logbucheintrag und Loschen der Aufgabe aus der Liste der laufenden Tasks. finish() Statuswechsel zu done und Loschen der Aufgabe aus der Liste der laufenden Tasks. disable() Statuswechsel zu ignor, Item wird zur ¨ Uberwachungsliste hinzugefugt. enable() Statuswechsel zu open und Loschen des Items aus der ¨ Uberwachungsliste. Tabelle 6.2: M ogliche Item-Events und das resultierende Systemverhalten. Die Tabelle 6.2 fasst die Zustandsange und das jeweils daraus resultierendes System uberg verhalten zusammen. 6.2.2 (Intelligentes) reaktives Systemverhalten In Abhvon andernden Einsatzsituation ussen unterschiedliche Auf angigkeit der sich m gaben durch die Einsatzkrullt werden. Ein CL-Assistenzsystem sollte in seinem afte erf Verhalten die Dynamik einer Einsatzlage mitberullt diese Forde ucksichtigen. Casie erf rung dahingehend, dass aus den durch die ICL-Bearbeitung gewonnenen Informationen eine entsprechende ICL-Anpassung vorgenommen wird. Die Abbildung 6.15 illustriert die in Abschnitt 6.1.2 eingef uhrten Betriebsmodi SUM und MUM. W ahrend im SUM nur lokale, auf den jeweiligen Runtime-Client beruhende Events und Informationen beronnen im MUM die (externen) Events ucksichtigt werden, k und Lageinformationen (z. B. die Anzahl der Verletzten oder das erfolgreiche Einrichten Dynamik / reaktives Systemverhalten Single-User Modus CL-Client Check- liste(n)) Checkliste ..… … … ..… … … ..… … … CASIE Clients CASIE Client CASIE Client CASIE Client Multi-User Modus CL-Client Check- liste(n)) Checkliste ..… … … ..… … … ..… … … CASIE Client CASIE Client CASIE Client CASIE Client Abbildung 6.15: Singel-User-vs. Multi-User-Modus. eines Behandlungsplatzes) anderer Nutzer zusammengef¨ uhrt und gegebenenfalls mitber ¨ ucksichtigt werden. Das intelligente reaktive Systemverhalten von Casie wird hierbei durch das Zusammenspiel zweier grundlegender Mechanismen erreicht: zum einen durch das Auswerten der Interaktionen zwischen der Einsatzkraft und dem CL-Client sowie der Statuswechsel und/ oder KB-Updates andere CL-Clients im Netzwerk; und zum anderen durch eine darauf ¨ folgende interne Uberpr¨ ufungsroutine, welche die durch die Nutzeraktion gewonnenen Informationen im System weiterverarbeitet und ggf. mit der Anpassung bzw. der Darbietung der ICLs reagiert. In den Definitionen der ICLs (Def. 4, S. 52) und der Items (Def. 5, S. 52) sind durch K(cl) bzw. Pre(f) zwei Stellen zur Angabe von Anwendungsbedingungen (Contraints) vorgesehen. Bei den Bedingungen handelt es sich um eine Menge formaler bzw. nat¨ urlichsprachlich repr¨ asentierter (Anwendungs-)Kriterien, die, wie folgt, in Casie Anwendung finden. 1. Bei manueller Auswahl einer Checkliste durch den Benutzer und deren Initialisierung kann davon ausgegangen werden, dass die Anwendungskriterien der ausgew¨ ahlten Checkliste in der aktuellen Einsatzlage gelten. Diese Informationen k¨ onnen als Fakten ¨asentation hinzugef¨ uber die Einsatzlage zur Lagerepr¨ugt werden. ¨ 2. Wird im Zuge eines Uberpr¨ ufungszyklus der Anwendungskriterien aller noch nicht initiierten Checklisten festgestellt, dass die Kriterien f¨ullt sind, so wird ur eine ICL erf¨ die entsprechende ICL der Einsatzkraft als zu beachtend“ automatisch vorgeschla ” gen. Im Folgenden soll das Systemverhalten aus der Perspektive einer einzelnen F¨ uhrungs-bzw. Einsatzkraft (im Folgenden auch Nutzer genannt) beschrieben werden. Mit dem SUM und dem MUM werden jedoch beide Facetten der Anwendung gemeinsam behandelt. Die Abbildung 6.16 (n¨atsdiagramms das reaktive achste Seite) skizziert hierzu in Form eines Aktivit¨ Systemverhalten von Casie. Die Abbildung stellt die dynamischen Aspekte des modellierten Systems dar. Die einzelnen Aktivit¨ aten sind in die logischen Bereiche Anmelden, Auswahl & CL-Hierarchie, Bearbeitung/Update und Abmelden/Dokumentation zusammengefasst dargestellt. Die grau (hell) hinterlegten Aktivit¨ur manuelle Interak aten stehen f¨ tionen des Nutzers mit dem System, w¨ ahrend die rot (dunklen) hinterlegten (voll-) automatisch durch Casie realisiert werden. Die schraffiert hinterlegten Aktivit¨ur aten stehen f¨ eine Mischform beider, d. h. f¨ ur eine manuelle Aktion des Nutzers mit semiautomatischer Assistenz des Systems. Dynamik / reaktives Systemverhalten CL-Hierarchie & Bearbeitung/Update Bearbeitungszyklus Anmelden Auswahl der MCL (bzw. alt. ICLs) man. CL(s) auswählen Benutzer anmelden (autom.) MCL auswählen Rolle einnehmen (bzw. wechseln) ICL(s) aktivieren Rolle bereits vergeben Vorschlag OK Vorschlag nicht OK ICL-Hierarchie aufbauen bereits erfüllte Items ermitteln Abmelden/Dokumentation (alle) ICLs archivieren & Logbucheintrag Benutzer abmelden act: CASIE Anwendung weitere CLs auswählen offene Items „bearbeiten“ Start .... 2 3 4 5 Ende 8 falls Rollenbereich überschritten 6 7 1 10 9 .. Item deaktivieren und aktivieren falls Item wieder relevant wird ..8.1 Eingenommene Rolle noch nicht belegt Item delegieren 8.2 ICL vorzeitig abgebrochen ICL vollständig abgeschlossen ICL explizit abgeschlossen (trotz offener Items) Pre eines Items nicht erfüllt Info, falls abgeschlossen oder fehlgeschlagen zeitzyklische Überprüfung „manuelle“ Aktion des Nutzers semiautomatische Aktion automatische System-Aktion zeitzyklisches System-Event Abbildung 6.16: Aktivit¨ atsdiagramm des reaktiven Systemverhaltens von Casie. Anmelden Zu Beginn (1) muss sich der Nutzer am CL-Client mit seinem Namen anmelden. Im SUM spielt der Name zwar noch keine Rolle, jedoch kann im MUM dann nach Bedarf eine Liste aller aktiven CL-Clients mit deren Nutzernamen erstellt werden. Danach w¨ ahlt der Nutzer diejenige Rolle aus (2), die er ubernehmen m¨ur eine ¨ochte. Casie kann dem Nutzer hierf¨ Liste aller Rollen pr¨ur die entsprechende ICLs hinterlegt sind. Die Liste l¨ asentieren, f¨asst sich auf Basis aller ICL-Definitionen des Repository leicht ermitteln. Diese semiautoma Dynamik / reaktives Systemverhalten tische Systemunterst utzung ist in der Abbildung 6.16 durch die Schraerung des Aktivit ahlen atsknotens gekennzeichnet. Im Prinzip sollte der Nutzer jede beliebige Rolle frei w k onnen. Als Assistenz kann jedoch in der MUM-Variante auf Basis der Rollende nitionen und deren Kardinalitubernahme erkannt und aten (nc) eine ungewollt redundante Rollen dem Nutzer angezeigt werden. Das Netzwerksymbol in der Abbildung 6.16 zeigt an, dass ein Mehrwert nur dann zur Verf ugung steht, wenn eine Verbindung mehrerer CL-Clients (bzw. Casie-Systeme) untereinander besteht. Auswahl der MCL bzw. alternativer ICLs Nach erfolgreicher Rollenur die Rolle hinterlegte MCL automatisch ubernahme wird die f aus dem Repository ermittelt (3). Existiert eine f ur den Nutzer passende, personalisierte MCL-Variante (siehe Abschnitt 6.3), so wird diese anstatt der allgemeinen MCL ausgew onnen auch alle dazugeh ahlt. Zur weiteren Detaillierung korenden Sub-CLs gelistet werden. Sind zu den ICLs entsprechende formale Vorbedingungen de niert, so pr uft Casie automatisch, ob diese mit dem momentanen Wissenstand der Wissensbasis (KB) jeweils als gultig ableitbar sind (S j=T K). Falls die Anwendungskriterien einer ICL bzw. MCL nicht erf ullt sind, so kann dies dem Nutzer entsprechend kenntlich gemacht werden. Ist der Nutzer mit der angebotenen Auswahl nicht zufrieden, w ahlt er alternativ eine beliebige Menge von ICLs, passend zu oder abweichend von seiner Rolle aus (5). Ist der Nutzer hingegen mit der MCL einverstanden, was als Regelfall zu erwarten ist, kann er diesen Vorschlag  ubernehmen und somit den Bearbeitungsbeginn der MCL aktivieren (4). Der Status der jeweils ausgewahlten ICLs) wechselt hierbei von ahlten MCL (bzw. der alternativ gewinactive auf active. Der CL-Manager  uberwacht ab nun die Bearbeitung der ICLs, bis diese abgeschlossen bzw. explizit abgebrochen werden. Hierzu werden alle aktiven ICLs im CL-Manager in eine sog. Watch-List (Beobachtungsliste) aufgenommen. Initialer Aufbau der CL-Hierarchie & -Bearbeitung Mit der Aktivierung einer MCL erfolgt der Aufbau der entsprechenden CL-Hierarchie (6). Die CL-Hierarchie ist als eine automatisch generierte Sicht einer Menge verkn upfter ICLs zu verstehen, wodurch ein Wurzelbaum entsteht, dessen Wurzel eine MCL darstellt. Abstrakte Items werden dabei nur soweit durch Sub-CLs konkretisiert, wie es die Auswertung der Anwendungsbedingungen gestattet. Der Einfachheit halber wird davon ausgegangen, dass der Nutzer nur die fahlt. F ur ihn passende MCL auswur eventuelle alternative ICLs gilt jeweils die analoge Vorgehensweise. Um eine initiale CL-Hierarchie zu berechnen, werden in einem ersten Schritt alle zur Rolle passenden ICLs aus dem Repository gelesen. Danach wird die in jedem Sub-CL- Verweis (falls vorhanden) angegebene ICL mit dem abstrakten Item verknso upft. Die entstehende Datenstruktur muss bei Bedarf zus atzlich die verschiedenen alternativen Sub- CLs, die fonnen, mitbeachten. Alle so ermittelten ur ein abstraktes Item angegeben sein k Sub-CLs, die exklusiv (ohne Alternativen) mit einem Item verkn upft sind, werden ebenfalls mit in die Watch-List aufgenommen und auf Status active gesetzt. Zu jedem Satz an uberpr CL-Alternativen wird dann uft, welche Checklisten ein abstraktes Item in der gegenwagung die CL- artigen Lage konkretisiert, d. h., welche Auspr ¨ Hierarchie in der jeweiligen Lage konkret einnimmt. Analog zur Uberpr ufung der Anwendungskriterien f ur ICLs wird hierzu in jedem Entscheidungsschritt d (vgl. Abb. 5.6, S. 61) eine passende Sub-CLs gew ahlt. Die Konkretisierung kann entweder automatisch oder auf Basis der ausgewerteten Anwendungsbedingungen getro en werden – vorausgesetzt, die IC- Ls sind mit entsprechenden formalen Anwendungskriterien K annotiert worden und es l asst Kon guration/Wartung sich aus der Wissensbasis schlieen, dass die Anwendungsbedingungen gelten (S j=T K). Oder aber der Nutzer tri t die Entscheidung selbst, indem er eine seiner Meinung nach passende Sub-CL aus der Liste der mahlt. oglichen Alternativen ausw In einem weiteren Schritt wird automatisch fuberpr ur jedes Item aller aktiven ICLs uft, ob das Item bereits erfoglicherweise bereits vorliegen ullt wurde (7), d. h., ob anhand der m den Informationen zur Einsatzlage deren E ektmenge Eff() (falls angegeben) als erf ullt abgeleitet werden kann oder nicht. Falls ja, so wird dessen Status automatisch auf done gesetzt. Eine entsprechende visuelle Hervorhebung kann dies dem Nutzer kenntlich machen. Die CL-Bearbeitung (8) stellt die Hauptaktivit at des Anwenders dar. Dieser Bearbeitungszyklus besteht im Wesentlichen aus dem Abhaken der einzelnen Items. Da der Verlauf dieser Aktivitangt, l at von der jeweiligen Einsatzlage und den konkreten ICLs abhasst sich dieser Teil im Aktivit atsdiagramm nur abstrakt darstellen. Neben dem allgemeinen Abhaken von Items lassen sich zwei m ogliche Unteraktionen nennen. Zum einen kann Casie die Gultigkeit von Item-Vorbedingungen automatisch ufen. L uberprasst sich z. B. aus der KB ableiten, dass kein Gefahrgut beteiligt ist, so k onnen all diejenigen bedingten Items ausgeblendet werden (8.1), die nur f ur den Fall einer Gefahrgutbeteiligung beachtet werden mahrend des Einsatzes Gefahrgut auf und wird dies der KB bekannt ge ussen. Tritt w macht, so kann Casie automatisch die entsprechenden Items wieder in der Liste anzeigen. Bei der zweiten Unteraktion handelt es sich um eine Delegation (8.2) eines Items zu einem anderen Nutzer, da dessen Bearbeitungsverantwortung in einer untergeordneten Rolle liegt. Diese Funktionalitugung, falls ein weiterer CL-Client im at steht jedoch nur zur Verf Netz verfatz ugbar ist, an dem sich der entsprechende Rolleninhaber angemeldet hat. Zus lich mupfungspunkte zuvor bei der Kon guration des Systems explizit ussen diese Verkn angegeben werden (siehe Abschnitt 6.3). Abmelden/Dokumentation Nachdem der Nutzer alle ICLs abgeschlossen hat (Event finish()) bzw. die Bearbeitung explizit abgebrochen hat (Event cancel()), werden die ICLs automatisch mittels der Logbook- Komponente archiviert (9). Das explizite Abmelden (10) des Nutzers am CL-Client archiviert alle noch o enen (Status aktive) ICLs und versetzt den CL-Client in den Stand-by- Modus. Ein Abmelden ist prinzipiell zu jeder Zeit m oglich, ohne dabei die Informationen der bis dato Bearbeitet ICLs zu verlieren. Die Vorteile, die solch eine automatische Dokumentation fautert. ur die BOS hat, werden im Abschnitt 7.3 erl 6.3 Kon guration/Wartung Um Casie f ur den Einsatz in einem Anwendungsbereich zu kon gurieren, bedarf es zwei sich teils erg anzender Modellierungen. Zum einen muss ein entsprechendes terminologisches Dom anenmodells erstellt und zum anderen muss das prozedurale Wissen der SOPs in Form der ICLs erfasst werden. Da jede Organisation ihre eigenen spezi schen Anforderungen und Auspr agungen von Arbeitsprozessen aufweist, wird jede Organisation das System mit ihren eigenen Checklisten fussen. W ullen mahrend die Benutzung von Casie kein spezielles Know-how von einer Einsatzkraft abverlangt, ist bei der Kon guration des Systems, der Ontologieerstellung und der Verkn upfung der Checklisten und der Merkmale zur Situationsbeschreibung ein tiefgreifendes Fachwissen erforderlich. Die jeweils regional ausgepr agte BOS-Ontologie kann daher nur mit Hilfe eines Ontologieexperten in enger Kooperation mit den Anwendern erstellt werden. Kon guration/Wartung Im Folgenden werden die Erstellung einer Domautert und Hinweise f anenontologie erlur den Aufbau eines CL-Repository und die Personalisierung von Checklisten gegeben. 6.3.1 Entwicklung einer BOS-Ontologie Dieser Abschnitt beschreibt die Entwicklung einer BOS-Ontologie als beispielhaftes Dom anenmodell und gibt am Ende ein Beispiel dafachtigkeit der Reasoning ur, inwieweit die M funktionalitangig ist. at von einer geeigneten Modellierung abh Formale Ontologien sollen einen Konsens der Begri sverwendung einer speziellen Dom asentieren. Dieser Thematik widmet sich der Forschungsbereich des Ontologie ane repr Engineering aus dem bis heute eine Vielzahl von Vorschl agen, Techniken und Methoden zur Ontologieerstellung hervorgegangen sind. So gibt z. B. Fernopez in [Fer99] andez-L´ ¨ einen kurzen Uberblick uber verschiedene Methoden, ahrend Gerez womez-P´ et al. in ihrem Buch Ontological Engineering“ [GFC04] einen umfassenden Einstieg in das Fach " gebiet geben. Ohne auf die Vor-und Nachteile der unterschiedlichen Herangehensweisen genauer einzugehen, werden in dieser Arbeit die Einzelschritte der Ontologiemodellierung beispielhaft anhand der von Noy & McGuiness in [NM01] vorgeschlagenen Knowledge- Engineering Methodology vorgestellt. Die Autoren schlagen vor, den Entwicklungszyklus in sieben Schritte zu unterteilen (siehe Abbildung 6.17). determine scope determine scope considerreusing considerreusing enumeraterterms enumeratertermsdefineclassesdefineclassesdefine propertiesdefine propertiesdefine constraintsdefine constraintscreatec instancescreatec instances11223344556677 Abbildung 6.17: Schritte der Ontologieentwicklung nach McGuinness et al. [NM01]. ahrend der Evaluierungs-und Anpassungsphase der Ontologie werden je nach Bedarf einzelne Schritte erneut durchlaufen. Es ist bei der Ontologieentwicklung ratsam, einige wichtige Grunds W atze nicht aus dem Blick zu verlieren. Noy und McGuiness (siehe [NM01]) geben dem Entwickler drei LeitsThere is no one correct way atze mit auf den Weg: (1) " to model a domain – there are always viable alternatives. The best solution [...] depends on the application that you have in mind.“ (2) Ontology development is necessarily an " iterative process.“ (3) Concepts in the ontology should be close to objects (physical or " logical) and relationships in your domain of interest. These are most likely to be nouns (objects) or verbs (relationships) in sentences that describe your domain.“ Die Erstellung einer Ontologie ist als ein kreativer Prozess zu verstehen. Zwei unterschiedliche Modellierer werden aufgrund ihrer unterschiedlichen F ahigkeiten und Sichtweisen auch unterschiedliche Ontologien fane entwickeln. Die G ur ein und dieselbe Domute der Ergebnisse l asst sich nur durch den Grad der erfolgreichen Anwendbarkeit in der zu erzielenden Anwendung einschatzen (the proof is in the pudding“ [GF95]). Die im Rah " men dieser Arbeit modellierte BOS-Ontologie (siehe [BOS-O]) ist daher als eine m ogliche Beispielmodellierung der BOS-Dom ane anzusehen. Protege als Tool zur Ontologieentwicklung Eine Schlur die erfolgreiche Modellierung einer Ontologie nehmen spezielle Soft usselrolle f ware-Tools ein. Obwohl sich die Idee des Semantic Web wachsender Beliebtheit erfreut, existieren bisher nur wenige Programme zur Unterst utzung einer Ontologieentwicklung. Kon guration/Wartung Abbildung 6.18: Das GUI von Protege (4.*) mit geladener BOS-Ontologie [BOS-O]. Speziell f ur die junge Ontologiesprache OWL 2 stehen dem Entwickler momentan wenige Tools zur Verfeg ugung. Hinsichtlich der Entwicklungsumgebungen nimmt das ProteProjekt3 eine f uhrende Stellung ein. Nicht zuletzt sind die Editoren OilEd [BHG+01] von der University Manchester und OntoStudio (ehemals OntoEdit) der Firma semafora systems zwei weitere Vertreter f ur Ontologieeditoren. Bei Protege handelt es sich um ein Open-Source-Projekt. Das mit einem Graphical User Interface (GUI ) ausgestattete m achtige Entwicklungstool (Abb. 6.18) gilt momentan als de facto Standard zur Ontologieentwicklung mit OWL 2 und stellt dar uber hinaus eine standardisierte Schnittstelle zu verschiedenen Inferenzmaschinen bereit. Protege ist in Java implementiert und somit plattformunabh angig einsetzbar. Weiterhin ist eine Ontologie- Validierung schon woglich, wodurch syntaktische Modellierungs ahrend der Erstellung m fehler bereits zu Beginn erkannt und behoben werden k onnen. Die Benutzerober ¨ ache bietet eine Reihe von Registerkarten, mit deren Hilfe die Erstellung bzw. das Editieren von Ontologien erm oglicht wird. Hierbei sind die wichtigsten Registerkarten OWL-Classes, Properties und Individuals. F ur den Aufbau einer Wissensbasis ¨ werden otigten Klassen de niert. uber den OWL-Classes-Tab die verschiedenen benUber den Properties-Tab katere Instanz onnen die Eigenschaften, die eine Klasse bzw. eine sp der Klasse haben soll, festgelegt werden. Zur De nition des Werte-(Range) und De nitionsbereichs (Domain) einer Property werden die zuvor eingef uhrten Klassende nitionen (bzw. die zur Verf ugung stehenden Datentypen) genutzt. Auf der Reiterkarte Individuals k onnen im Anschluss beliebig viele Instanzen einer Klasse angelegt und die durch die Properties zuvor bestimmten m oglichen Attributwerte festgelegt werden. Es wird an dieser Stelle auch von Wissensakquise gesprochen, da das Anlegen von Instanzen eine konkrete Repr asentation von Individuen eines Wissensbereiches anhand einer zuvor de nierten Ontologie entspricht. Ob eine Ontologie mit Protege 3.* oder mit Protege 4.* entwickelt wird, hangt ganz von den jeweiligen Anforderungen ihrer Verwendung ab (vgl. Wang [Wan06]). Da im Rahmen 3 Homepage des Protege Projekts: http://www.protege.standford.edu. (abgerufen am 01.12.2013) Kon guration/Wartung dieser Arbeit die Modellierung der korrekten Zusammenh ange der Begriichkeiten mehr im Vordergrund steht als die Akquise umfangreicher Datenmengen, wurde sich fdie ur OWL-Variante von Protege entschieden. Die einzelne Schritte der BOS-Ontologieentwicklung im Detail Im Folgenden werden die einzelnen Schritte der Ontologieentwicklung gem aß der vorgeschlagenen Herangehensweise von Noy & McGuiness [NM01] Schritt f ur Schritt betrachtet. Die Entwicklungsschritte werden beispielhaft anhand der BOS-Ontologie illustriert. Vereinzelt werden dabei einige spezi sche Modellierungsdetails aufgef uhrt, die die eingesetzten Werkzeuge bzw. die formale Ontologiesprache betre en. Schritt 1: Festlegen des Wissensbereiches Im ersten Schritt m¨ art werden wie: Welches Anwendungsgebiet soll model ussen Fragen gekl liert werden und was soll nicht modelliert werden? Wie soll die Ontologie genutzt werden? D. h., welche Fragen uber die Dom ane soll die Ontologie beantworten? Und nicht zuletzt: Wer wird die Ontologie nutzen und administrieren? Diese Fragestellungen sollen folgend genauer betrachtet werden. Welches Anwendungsgebiet soll modelliert werden? Die Beantwortung dieser Frage ist so einfach wie schwierig zugleich. Die Herausforderung besteht darin, einen Mittelweg zwischen einer einfachen Ontologie und ihrer gleichzeitigen Ausdruckskraft und Vollst andigkeit bez uglich ihres geplanten Einsatzgebietes zu nden. Im Rahmen dieser Arbeit wurde sich bei der Umsetzung einer beispielhaften BOS-Ontologie auf die Modellierung der wesentlichen Konzepte einer Groschadenslage und einem Satz beispielhafter Relationen konzentriert. Welche Fragen ane soll die Ontologie beantworten? Das problemorientierte uber die Dom Erarbeiten sogenannter Competency Questions (CQ) dient dazu, den Einsatzbereich der Ontologie zu bestimmen (vgl. [GF95; UG96]). Um eine Ontologie in einer realen Anwendung hilfreich nutzen zu kahigen, die in den CQ onnen, sollte sie einen Reasoner dazu bef informell formulierten Anforderungen zu erf ullen. D. h., die CQs sollen deutlich machen, welche Fragen durch den Einsatz der Ontologie mit einem Reasoner durch die Anwendung onnen. Die CQs stellen eine Orientierung f uberhaupt beantwortet werden kur die weiteren Schritte der Ontologieentwicklung und des Anwendungssystems selbst dar. Es ist davon auszugehen, dass sich die CQs andern werden uber den Entwicklungszyklus der Ontologie  und daher die Ontologie gem aß der neuen Anforderungen angepasst werden muss. Eine beispielhafte Menge von informellen Competency Questions, die sich in Casie ergeben, lautet wie folgt: • Welche Rollen sind momentan durch wen belegt, und welche SOPs sind aktuell durch wen in Bearbeitung? • Gibt es Rollenkon ikte durch irrt umlich mehrfach belegte Rollen? • Um welches Schadensereignis handelt es sich? • Gibt es Redundanzen in der Patientenerfassung? • Welche Organisationen mit Rettungsdienstaufgaben sind im Einsatz involviert? Kon guration/Wartung Wer wird die Ontologie nutzen und wie? Dieser Aspekt wird (nach McGuiness [NM01]) oft vernachl assigt, obwohl dies eine wichtige Fragestellung hinsichtlich des Praxiserfolgs einer ontologiebasierten Anwendung ist. Wie in Abschnitt 5.2.6 gezeigt, soll die BOS-Ontologie in Casie zum einen als Diskussionsgrundlage f ur die Modellierung relevanter Aspekte einer Groschadenslage dienen, und zwar bereits im Vorfeld einer solchen. In einem zweiten Schritt dient die Ontologie einer Wissensbasis als Terminologie, wodurch logische Schlussfolgerungen uber Aktionen in Casie m uber eine konkrete Einsatzsituation und oglich sind. Wer wird die Ontologie bei Bedarf anpassen? Die Frage nach der Anpassung der Ontologie ist ein zweischneidiges Schwert. Zum einen liegt der Vorteil der Nutzung einer Wissensbasis gerade darin, dass die Modellierung Modellierung von Wissen und die Einordnung von Fakten der Anwendungsdom ane exibler gehandhabt werden kann. So kann die Ontolo¨ gie bei Bedarf angepasst werden, ohne dass eine oft aufwAnderung der Logik des andige Anwendungsprogramms erforderlich wird. Auf der anderen Seite bedarf es eines tiefgreifenden Grundverst andnisses der einer Ontologie zugrunde liegenden Theorie sowie der Syntax und der formalen Semantik der verwendeten Ontologiesprache. Es l asst sich der Standpunkt vertreten, dass die Ontologie nach ihrer Erstellung nicht mehr ge andert werden kann und soll. Das SpeedUp-Projekt hat gezeigt, dass ein groer Anpassungsbedarf solcher Systeme an die lokalen Gegebenheiten besteht, was nicht selten den Eingriff in die grundlegende Modellierung zur Folge hat. Ziel von Casie ist jedoch, ein m oglichst exibles Rahmenwerk zu erarbeiten, das eine Anpassung der Ontologie an sich  andernde Gegebenheiten unterst  utzt. Eine Anpassung der Ontologie wird immer durch einen Ontologieexperten erfolgen m ussen. Schritt 2: Integration bereits bestehender Ontologien pr ufen Existiert bereits f ur einen Teilbereich eine formale Ontologie, sei es eine selbst entwickelte oder eine fremdeOntologie, so ist es ratsam, abzukl “ aren, ob diese Ontologie genutzt ” werden kann. L asst sich eine bereits vorhandene Ontologie integrieren, hilft dies, die Entwicklungsarbeit zu erleichtern. Dar uber hinaus kann es Vorteile haben, sich auf eine bereits etablierte (Quasi-)Standardontologie zu beziehen. Zwei Beispiele sollen dies verdeutlichen. Angenommen es soll eine Ontologie f ur einen Buchshop erstellt werden, so bietet es sich an, die bereits existierende Ontologie des Dublin Core Metadata Standards mit bei der Ontologieentwicklung zu ber ucksichtigen. Soll hingegen eine Ontologie zur Beschreibung von Web-Services erstellt werden, so sollte die Nutzung der bereits daf ur etablierten OWL-S-Ontologie in Betracht gezogen werden [MBM+07]. Es ist jedoch eine Konsequenz aus Schritt 1, dass es recht unwahrscheinlich ist, eine frei verfane und ugbare Ontologie zu nden, die sich auch mit der gleichen Anwendungsdom vor allem mit den gleichen CQs deckt. Je spezieller das Anwendungsgebiet, desto spezieller wird auch eine Ontologie zu diesem Gebiet ausfallen. Zwar wurden in den letzten Jahren einige Ontologien im Bereich Krisenmanagement entwickelt (vgl. hierzu z. B. die Au istung von Liu et al. [LSB13]), doch sind diese nicht auf die deutschen BOS anen der in Kapitel 3 vorgestell ubertragbar. Obwohl die modellierten Dom ten Forschungsarbeiten den BOS-Bereich  ahneln, sind deren Unterschiede jedoch so gro, dass eine Nutzung foglich ist. Dies liegt nicht zuletzt an den deutlichen ur Casie nicht m l anderspezi schen Unterschieden im Rescue Management und den damit einhergehenden Konzepten. Selbst die deutschen Projekte, in denen Ontologien im BOS-Bereich Teil der Kon guration/Wartung Forschungsarbeit waren (vgl. z. B. SHARE [KPS+08]), decken sich nicht mit den Anforderungen in Casie. Schritt 3: Zusammentragen der wichtigsten Konzepte Ist die Dom¨ achsten Schritt die wichtigsten Begri e des Anwen ane abgesteckt, werden im n dungsbereiches zusammengetragen, welche primur die zu modellierenden ar Kandidaten f Konzepte darstellen. Ob die Aufnahme eines Konzeptes sinnvoll ist, h angt direkt von der konkreten Verwendung der Ontologie in der entsprechenden Anwendung (siehe Competency Questions) ab. Nat¨ ahlung der wichtigsten Begri e noch nichts  urlich sagt eine bloe Aufzuber den Zusammenhang und die Eigenheiten der Domur bedarf es eines ausreichenden ane aus. Hierf Domandnisses und einer weiterf anenverstuhrenden Modellierung in den folgenden Schritten. Auch sind nicht alle der ermittelten Begri e zugleich sinnvolle Kandidaten f ur Klassende nitionen. So werden z. B. substantivierte Torter zumeist als Relationen atigkeitsw umgesetzt (siehe Schritt 5). Nachfolgend werden beispielhaft einige relevante Begri e der BOS-Domane aufgef uhrt. F ur eine komplette Au istung aller potentiell relevanten Begri e und Konzepte sei auf die BOS-Ontologie verwiesen. • Spezielle Pluckeordnung, Objektplan, Hydrantenplan, ane: Alarmierungsplan, Ausr¨ Evakuierungsplan und Lageplan. • Organisationen: Hilfsorganisation, Polizei, Feuerwehr, Berufsfeuerwehr, Werkfeuerwehr, Rettungsdienst und Rettungsleitstelle sowie konkrete BOS: DRK, THW, JUH, ASB, DLRG und BRK. ¨ • Ortlichkeiten: Einsatzort, Standort, GPS-Koordinaten, raumliche Einsatzabschnitte, Anfahrtswege, Objektnamen, Behandlungsplatz, Hubschrauberlandeplatz und Bereitstellungsraum. • Organisationsstruktur und Rollen: Technische Einsatzleitung, Stab, Krisenstab, AAO, EL, Notarzt, OrgL, Abschnittsleiter, Einsatzleiter, Gruppenfuhrer, Truppuhrer, Zugf fater und Polizeif uhrer, Rettungsassistent, Rettungshelfer, Rettungssanit¨ uhrer. atigkeiten: Alarmieren, Aufbauen, Anfordern, Melden der Lage, Tre en von Entscheidungen, Befehlen, Dokumentieren, Sichten, Absprechen, Datenerfassung, Behandlung, Bergung, Rettung, Berichten, Angri , Ermitteln, Aggregieren, Zuweisen, Transportieren und Informieren. • T Fdie BOS-Ontologie konnte fdie De nition einiger Begri e die DIN-Norm 13050 ur ur Rettungswesen – Begri e“ herangezogen werden. Insgesamt sind derzeit ca. 350 Kon " zepte der Domin der Ontologie erfasst. Alle Konzepte wurden unter Zuhilfenahme ane der Annotation-Property label benannt und mit einem erklarenden Kommentar  uber die Annotation-Property (comment) annotiert. Falls vorhanden, wurde zu jedem Konzept dessen gelau ge Abkurzung mit erfasst, z. B. LNA fu f ur Leitenden Notarzt oder GrFur einen Gruppenfonnen diese Be uhrer der Feuerwehr. Zum Zweck der Ontologiedokumentation k schreibungen automatisch aus der Ontologie extrahiert und als Bestandteil der Klassenbeschreibungen mit in die Dokumentation  ubernommen werden. Kon guration/Wartung Beispiel: OWL- Konzepthierarchie Abbildung 6.19: Beispielhafter Ausschnitt aus der BOS-Ontologie [BOS-O]. Schritt 4: De nition der Konzepte und der Konzepthierarchie Zur richtigen De nition der Konzepte, und speziell der Konzepthierarchie (siehe Abb. als Beispiel 6.19), existieren unterschiedliche Ans atze und Empfehlungen. Ein Ansatz besteht Kon guration/Wartung darin, mit der De nition der allgemeineren Konzepte zu beginnen (Top-down) und in der Folge speziellere Konzepte diesen unterzuordnen. Als entgegengesetzter Ansatz werden spezielle Konzepte zu allgemeineren Konzepten zusammengefasst (Bottom-up). Beide Vorgehensweisen k onnen je nach Anforderung kombiniert werden. Uschuld & Gruninger weisen darauf hin, dass keine Methode prinzipiell besser ist als die andere. Vielmehr hahigkeiten des Modellierers selbst und seiner Sicht auf die Dom angt es von den Fane ab, welche Methode f ur ihn die geeignetste und praktikabelste ist [UG96]. In Abbildung 6.19 ist mit den Klassen nur eine Facette der Ontologiestruktur sichtbar. Durch eine Ontologie wird in der Regel mehr als eine bloe Taxonomie von Konzepten, so wie die Abbildung vielleicht suggeriert, reprandige Abbildung einer asentiert. Eine vollst komplexen Ontologie wubersichtlicher. are an dieser Stelle weitaus umfangreicher und un Schritt 5: Festlegen der Relationen Nachdem die wichtigsten Konzepte bestimmt wurden, gilt es, deren Relationen (auch Beziehungen, Rollen oder Eigenschaften genannt) untereinander zu formalisieren. Einige in Schritt 3 identi zierten Begri e lassen sich zum Beispiel als Relation4 zwischen Konzepten interpretieren und stellen somit Kandidaten f ur eine zu de nierende Relation dar. So erscheint z. B. der Begriff Retten (aus der DIN 13050) als Konzeptklasse wenig sinnvoll, da er vielmehr eine Beziehung zwischen zwei Konzeptklassen beschreibt (Einsatzkr afte retten Patienten), und sollte daher als Relation de niert werden. Abbildung 6.20: Auszug einer Rollende nition der BOS-Ontologie in Protege. Relationen zwischen Konzeptklassen werden durch die Angabe ihres De nitionsbereichs (domain) und des Wertebereiches (range) genauer spezi ziert. In dem eben genannten Beispiel (retten) wurde daher als De nitionsbereich das Konzept Einsatzkraft und als Wertebereich das Konzept Patient zugeordnet. Abbildung 6.20 zeigt beispielhaft einen Auszug aus der mittels Protege modellierten Relationende nitionen. Im oberen Bereich sind die Datatype-Properties und im unteren Bereich die Object-Properties zu sehen. 4 Da der Begriff Rolle in dieser Arbeit bereits belegt ist, wird im Weiteren der Begriff Relation verwendet. Kon guration/Wartung Schritt 6: Festlegen der Restriktionen uber die Relationen  Die in Schritt 5 de nierten Rollen unterliegen Restriktionen bez uglich des Datentyps und der m oglichen Anzahl der Werte (cardinality des Wertebereiches). Die Restriktionen der Relationen beziehen sich auf die Festlegung des De nitionsbereiches und des Wertebereiches. Zum Beispiel hat die Relation hatName(Ort,String) als De nitionsbereich Individuen der Klasse Ort und als Wertebereich Individuen des Typs String, w ahrend die Relation istFrei(RTW,Boolean) einen RTW mit einem Wahrheitswert (true oder false) in Beziehung setzt. Obwohl String und Boolean prinzipiell zwei Konzepte der TBox darstellen, werden solche elementaren Datentypen in konkreten KB-Systemen jedoch separat behandelt und nicht extra als neue Konzepte in die Ontologie aufgenommen. Hierbei handelt es sich um ein Beispiel des bereits angesprochenen SHOIN (D)-Sprachmerkmals (concrete domain, D). ¨ Mehr Informationen zum Thema nden sich im Uberblick von Lutz [Lut03]. Analog zur atsbeschrim Entity-Relationship-Modell (vgl. [Che76]) Kardinalitankung lmagungen feine spezielle Relation festlegen. asst sich die Anzahl der oglichen Ausprur Es kann grob zwischen Single-Kardinalitochstens ein Wert ist erlaubt) und Multi at (h ple-Kardinalit at (mehrere Werte sind erlaubt) unterschieden werden. Zum Beispiel wird durch die Relation hatFunkkenner(RTW,Funkkenner) ein Rettungswagen mit einer (seiner) ganz speziellen Funkkennung in Beziehung gesetzt. Hierbei handelt es sich um eine 1Kardinalit ur ein Rettungsfahrzeug ausgeschlossen sind. at, da mehrere Funkkenner f Da einem Rettungsfahrzeug immer ein Funkkenner zugewiesen ist, handelt es sich bei diesem Beispiel genau genommen um einen funktionalen Zusammenhang, der sich z. B. mit OWL-Sprachmitteln owl:FunctionalProperty auch als solcher de nieren l asst. Die Relation hatAlsMitglied(Org,Person) hingegen erlaubt die Zuordnung mehrerer Personen zu einer Organisation und ist somit ein Beispiel fat. ur eine Multiple-Kardinalit Schritt 7: Bev\ olkernder Ontologie mit Instanzen " In der Regel beinhaltet die formale Spezi kation einer Konzeptualisierung noch keine konkreten Symbole fIndividuen. Erst in einer konkreten Anwendung werden Individuen ur den Konzepten und Relationen als Assertions ugt. Dieser uber einen Weltzustand hinzugef Vorgang wird in der Literatur auch als Vorgang der Ontologie Population bezeichnet und entspricht der Beschreibung eines bestimmten Weltzustands der Dom ane. Ob Ontologien prinzipiell individuenfrei sein m¨ ussen, wird selbst unter Experten teils kontrovers diskutiert. Da Ontologien in der Praxis jedoch in der Regel kein reiner Selbstzweck sind, sondern immer einer ganz bestimmten Anwendung dienen, entscheidet die Art der Anwendung dar uber, ob es sinnvoll ist, Individuende nitionen bereits in die Ontologie ein ieen zu onnen  lassen. So kz. B. (invariante) ortliche Gegebenheiten wie istBenachbart(Ort1,Ort2 ) als konstante individuenbezogene Aussagen einer Dom ane in die Ontologie aufgenommen werden. Die unterschiedlichen Triagierungsstufen bei der Verletztensichtung sind ein weiteres Beispiel f ur invariante Fakten, die bereits im Vorfeld in der Ontologie als Instanzen des Konzeptes Triagierungsstufeerfasst werden kahrend “ onnen, da sie sich w " eines Einsatzes nicht  andern werden. Die Ontologie sollte einerseits m¨ oglichst alle relevanten Sachverhalte der Welt widerspiegeln und andererseits kompakt genug sein, um noch ezient Schlussfolgerungen ziehen zu kane (teils Ressourcen genannt) wie Personen onnen. Von den konkreten Objekten der Dom (Einsatzkr afte, Helfer, Patienten) und Rettungsmittel sollen in Casie nur solche beachtet werden, die f ur einen Ablauf und die Koordinierung von Checklisten notwendig sind. Eine Kon guration/Wartung vollstafte, technische Ger andige Aufnahme aller Ressourcen (Einsatzkrate, Verbrauchsmaterialien, etc.) ist nicht praktikabel umsetzbar und soll nicht realisiert werden. 6.3.2 Entwicklung von ICLs Ist die Erstellung und Nutzung simpler Checklisten in unserem Alltag noch recht einfach und  uberschaubar, so steht man bei sicherheitskritischen Einsatzgebieten schon vor einer gr oeren Herausforderung. Welche kritischen Schritte lassen sich denn bei welchen Routinehandlungen identi zieren? Wie proglichst asentiere ich diese Punkte geeignet, damit m alle Mitarbeiter den Sinn dahinter korrekt interpretieren? Das Verbalisieren und das Formulieren passender Checklisten (Methoden) ist eine recht schwierige Aufgabe, vor allem dann, wenn es sich um Handlungen handelt, denen sich die Akteure nicht in Gurden in einer entsprechenden Situation durch anze bewusst sind. Sie w aus richtig handeln, k onnen ihre Handlungsschritte im Vorfeld jedoch schwer formulieren bzw. nicht vollstunden. Geeignete Checklisten f andig begrur die unterschiedlichen SOPs zu erstellen, kann nur individuell von den jeweiligen lokalen BOS und unter Ber ucksichtigung ihrer speziellen regionalen Besonderheiten umgesetzt werden. Im Rahmen dieser Arbeit soll trotzdem versucht werden, die einzelnen Schritte der CL-Erarbeitung aufzuzeigen. Abbildung 6.21 zeigt hierfogliches Ablaufschema. ur ein m extrahieren kritischer PunkteZusammenfassen nach jeweiligen SOPsStrukturierung (Hierarchien, Ordnung) Metadaten: Rolle, Task, Merkmale, ZusatzdokumenteItem-Texte festlegen(standardisiertes Vokabular) Checkliste .… … … .… … … .… … … .… … … Checkliste .… … … .… … … .… … … .… … … Checkliste .… … … .… … … .… … … .… … … Checkliste .… … … .… … … .… … … .… … … Einsatz/ Übung Anwendung im Einsatz/Übung234Nachbesprechung (Debriefing) Checkliste .… … … .… … … .… … … .… … … Checkliste .… … … .… … … .… … … .… … … Checklist .… .… .… Checklist .… .… .… 7SOPs/SERsundErfahrungen aus Einsatz/ÜbungenSOPs/SERsundErfahrungen aus Einsatz/Übungen156Checkliste .… … … .… … … .… … … .… … … Checkliste .… … … .… … … .… … … .… … … Checkliste .… … … .… … … .… … … .… … … Checkliste .… … … .… … … .… … … .… … … Checkliste .… … … .… … … .… … … .… … … Checkliste .… … … .… … … .… … … .… … … ............,..........,.........., ......,......, .........., ........, .........., ........, ......(..) mögl. AlternativenChecklist .… .… .… Checklist .… .… .… Checklist .… .… .… Checklist .… .… .… Checklist .… .… .… Checklist .… .… .… Checkliste .… … … .… … … .… … … .… … … Checkliste .… … … .… … … .… … … .… … … Checkliste .… … … .… … … .… … … .… … … Checkliste .… … … .… … … .… … … .… … … Abbildung 6.21: Von SOPs zu Checklisten und zur uck. . Kritische Punkte ermitteln In einem ersten Schritt gilt es, basierend auf den Erfah¨ rungen vorangegangener EinsUbungen), die kritischen Punkte zu identi zieren, atze (und die oft vergessen werden, deren Beachtung aber essentiell f ur die jeweiligen SOPs sind. Jede Organisation muss anhand ihrer spezi schen SOPs selbst fur welche ur sich entscheiden, f Bereiche eine Fehlerminimierung angestrebt wird. Weiterhin sind die g ultigen Ordnungen, Regelwerke, Gesetze und Dienstvorschriften zu beachten. Aus ihnen k onnen sich ebenfalls kritische Punkte ergeben, deren Einhaltung im Ernstfall durch die CLs sichergestellt werden soll. . Kritische Punkte gruppieren Wurde ein Satz kritischer Punkte notiert, so m ussen diese zunaß der zu beachtenden SOPs bzw. Rollenverantwortungen gruppiert achst gem ¨ werden. Hierbei muss zuvor geklur welche der Punkte eine ufung mit art werden, fUberpr tels Checklisten  uberhaupt sinnvoll und praktikabel ist. Bei Bedarf lassen sich ebenfalls Kon guration/Wartung individuelle Wafte mit ber unsche und die jeweiligen Erfahrungen konkreter Einsatzkrucksichtigen. . Itemtexte und -ordnung festlegen Die bis jetzt ungeordneten kritischen Punkten maß der SOP-Korrespondenz geordnet werden und ussen zum einen (falls erforderlich) gem zum anderen in eine geeignete Itemstruktur uhrt werden (vgl. De nition, S. 55). Die uberf Ordnung der Items einer ICL wird durch das Paar I(cl)=(, ) bestimmt, mit F als Menge der Items und . als Ordnungsconstraints ur jedes Item uber F (vgl. Def. 4, S. 52). F f einer ICL wird dann ein stichpunkthafter Informationstext text() erstellt. Siehe hierzu die Diskussion zur Checklisten-Phraseologie auf Seite 36 . Das durch die BOS-Ontologie bereitgestellte standardisierte Vokabular sollte zudem eine wichtige Quelle f ur verwendete Fachbegri e sein. Im Idealfall bedient man sich bei der Formulierung der Itemtexte strikt der Bezeichnungen der Fachkonzepte, die in der Ontologie ber ucksichtigt wurden. Die Verbindung der Fachbegri e mit den jeweiligen Namen der TBox-Konzepte entspricht einer semantischen Annotation ausgew ahlter Itemtext-Elemente, womit sich die Meiner arungsfunktionalitfweniger routinierteren Einsatzkrer oglichkeit Erklat ur afte schliet. . Metadaten, Anwendungskriterien und E ekte In einem weiteren Schritt k onnen gem aß der Strukturde nitionen von Checklisten und Items, deren Merkmale an den CLs und Items angegeben werden. Auf Seiten der Checkliste selbst sollten folgende Angaben gemacht werden: ein eindeutiger Name name(cl), der BOS-Name org(cl), in deren Einsatzbereich cl furlichsprachliche Beschreibung pur(cl) des Zweckes, die Menge allt, eine nat R(cl) von zust andigen Rollen und die Menge K(cl) von Anwendungskriterien. Fonnen eine ausf¨ ur jedes Item f der Liste kuhrliche Beschreibung desc(), eventuell vorhandenen Zusatzressourcen res(), der Typ des Items und m ogliche Vor-und Nachbedingungen angegeben werden. Items mit Vorbedingungen werden bedingte Items genannt. Der Anwender/Ersteller einer ICL kann Vorbedingungen auf zwei Weisen de nieren: 1. Er kann die Vorbedingungen als Anwendungskriterien vom Typ Freitext“ angeben. ” Diese Bedingungen k onnen von Casie im GUI nur dem Nutzer angezeigt werden. ¨ Eine automatische Uberprultigkeit ist nicht multigkeit der ufung der Goglich. Die G angegebenen Bedingungen kann jedoch vom Nutzer w ahrend einer Casie-Anwendung abgefragt (erfragt) werden. (Vorausgesetzt in der GUI wird eine entsprechende Funktionalit  at bereitgestellt.) 2. Er kann aus dem Satz von zuvor in der Ontologie de nierten Merkmalen w ahlen und somit die Grundlage fatere automatische Auswertung geben. Jedoch sollte in ur eine sp den Funknown“ liefert, ebenfalls allen, in denen die KB als Ergebnis der Auswertung ” der Nutzer ultigkeit der Vorbedingungen befragt werden. uber die eventuelle G Nicht f ur jedes bedingte Item wird sich in der Praxis auch ein geeignetes Merkmal nden lassen, das zuvor auch in der Ontologie ber ucksichtigt wurde. Oftmals ist es wohl sinnvoller, die Vorbedingungen in nat urlichsprachlicher Form abzulegen und dem Nutzer im Einsatz selbst entscheiden zu lassen. Bedingte Items, fultigkeit ur die das System keine G ¨ feststellen kann, kohung der onnen (automatisch) zur ErhUbersichtlichkeit von der jeweiligen Checkliste ausgeblendet werden. Falls w ahrend der Bearbeitungszeit der Checkliste die Vorbedingungen plullt sind, kann dieses Item automatisch als noch o en wieder otzlich erf eingeblendet werden. Kon guration/Wartung . Sub-CLs und Alternativen ur jedes abstrakte Item f werden uber die Menge FSub() alle potentiell mupfungen sind die Basis oglichen Sub-CLs angegeben. Diese Verkn der automatischen Berechnung der Checklisthierarchien. Analog zu den HTN-Methoden geben sie an, welche CLs die jeweiligen abstrakten Items konkretisieren k onnen (siehe Abschnitt 5.2.3). . Anwenden in der Praxis Das Ergebnis des ersten Durchlaufs des Zyklus kann dann ¨ im Ernstfall oder in einer Ubung angewandt werden. Neben dem Einsatz einer konkreten Casie-Implementierung k onnen die CLs aus dem CL-Repository auch als einfache PCLs eingesetzt werden. Selbst in diesem Fall lassen sich noch fehlende Punkte oder Unstimmigkeiten aufdecken. . Evaluierung/Debrie ng In Analogie zur Entwicklung von SOPs [Gru03] m ussen nach der Erarbeitung der Checklisten Evaluationsmechanismen erarbeitet und etabliert werden, die die E ektivitufen. at der Checklisten und deren korrekte Anwendung uberpr Personalisierte Checklisten Aufgrund der Heterogenitafte liegt der Wunsch nahe, at der Quali kationen aller Einsatzkr Checklisten zus atzlich zu personalisieren (vgl. Anforderungen, S. 46 .). Gemeint ist hiermit, dass z. B. ein hoch quali zierter und erfahrener Notarzt, der die Rolle des Leitenden Notarztes einnimmt, deutlich weniger und detailliertere Items bevorzugt als etwa ein kaum erfahrener Kollege. Letzterer wird unter Umstanden  uber mehr Assistenz (erweiterte CLs und detailliertere Items, mehr Zusatzmaterialien, pers onliche Anmerkungen) sehr dankbar sein. Um diese Zusatzfunktionalit at zu realisieren, bedarf es lediglich einer entsprechenden Abfrage im GUI und ein um die personalisierten Checklisten erweitertes CL-Repository. Je nachdem, unter welchem Namen (ID) sich eine Einsatzkraft am CL-Client anmeldet und welche Rolle sie  ubernommen hat, wird die zuvor personalisierte Checkliste aktiviert. Diese Zusatzfunktionalit at kann recht einfach durch entsprechend abgelegte CL-Varianten realisiert werden, so wie sie weiter oben im Abschnitt 5.2.3 vorgestellt wurden. Die Menge der Anwendungsbedingungen K muss nun lediglich um ein Merkmal erweitert werden, das Auskunft  uber den jeweiligen Rolleninhaber gibt. Eine unsachgem¨ ae Nutzung solch einer Personalisierung birgt jedoch auch Gefahren. Volle Freiheit bei der Personalisierung kuhren, dass der gew onnte dazu funschte E ekt, ausschlielich auf kritische Punkte hinzuweisen, verloren geht, wenn diese (leichtsinnig) von einer personalisierten Checkliste entfernt werden. Hingegen weitgehend unproblematisch ist die Erweiterung um zusonliche Anmerkungen und atzliche Items oder Informationen (pers Ergonnen zu viele Informationen dazu f anzungen). Aber auch hier kuhren, dass die CL zu umfangreich wird, was sich wiederum negativ auf deren Anwendung auswirken kann (siehe Diskussion in Abschnitt 4.2.5). Inwieweit diese Funktionalit at genutzt wird und bis zu welcher Granularit at diese umgesetzt wird, liegt bei jeder Organisation selbst. Von CLs zu SOPs In der vorliegenden Arbeit (Kapitel 4 und 5) wurde der Verzicht auf eine komplexe und allumfassende Prozessmodellierung zugunsten des Checklisten-Konzeptes motiviert. Begrundet wurde dies vor allem durch zwei Feststellungen: (1) Eine Groschadenslage ist hochgradig dynamisch und im Detail nicht planbar. (2) Auch die Teile der SOPs, welche sich in jeder Groschadenslage gleichen, sind schwer zu erfassen und zu modellieren. Es mangelt hierf ur zum einen an geeigneten und einfach zu bedienenden Softwarewerkzeugen, TEL-Feuerwehr . … … … … . … … … … . … … … … . … … … … Unter- Abschnitt Feuerwehr . … … … … . … … … … . … … … … ...... ...... TEL-Feuerwehr . … … … … . … … … … . … … … … . … … … … . … … … … . … … … … . … … … … .… … … … TEL-Feuerwehr . … … … … . … … … … . … … … … TEL-Feuerwehr . … … … … . … … … … . … … … … . … … … … . … … … … .… … … … .… … … … UA-Feuerwehr . … … … … . … … … … . … … … … . … … … … . … … … … .… … … … .… … … … .… … … … Kon guration/Wartung und zum anderen sind diese SOPs als solche kaum in der deutschen BOS-Kultur verankert. Obgleich sich SOPs sehr wohl in der Praxis herausbilden, sind diese zumeist nur implizit in den K opfen der Anwender gegeben. Trotz der oben genannten Schwierigkeiten ist im BOS-Bereich der Versuch einer (teilweisen) Prozesserfassung durchaus ein lohnenswertes Ziel. Eine Evaluierung von Handlungsstrategien und eine Qualitoglicht werden. Zum Beispiel atssicherung kann somit erm beschreibt Arsenova in [Ars08] die Praxiserfahrung, dass ein Prozessmodell den Einsatz¨ krUberblick uber ihre Prozesse gibt und somit bereits aften der Feuerwehr einen ersten  bei der Diskussion der Einsatzvorbereitung dienlich ist. Es bleibt die Frage, wie solch ein Prozessmodell zu erarbeiten ist. Der Autor stimmt mit Peinel et al. [PR09] uberein, dass  heutige BPM-Techniken nicht direkt 1:1 im BOS-Bereich angewendet werden k onnen (siehe Diskussion in Kapitel 3). Vielmehr bedarf es alternativer Ans atze der Modellierung. Abbildung 6.22: Beispielschema eines Prozessskeletts. Mit Casie erschliet sich hierf ur ein pragmatischer, alternativer Ansatz. Ausgehend von der Menge der Checklisten im CL-Repository, l asst sich theoretisch zu jeder Checkliste ein entsprechendes Prozess-Skelett ermitteln. Dieses besteht nur“ aus kritischen Tasks einer ” (oder mehrerer) SOPs. In der Praxis ist es jedoch ausreichend, die Checklisten der h ochsten Hierarchieebene (MCLs) zu konkretisieren. Ber ucksichtigt man dabei ausschlielich die de nierten action-Items, so erhangigkeit der Anwendungskriterien der je- alt man, in Abh weiligen CLs, ein sog. Task-Netzwerk. Abbildung 6.22 skizziert solch ein sich ergebendes Prozess-Skelett. In einem zweiten Schritt l asst sich daraus ein Prozessmodell in der gew asst sich leicht eine Umwandlung in einen unschten Modellierungstechnik erstellen. So l g angigen Modellierungsformalismus, wie z. B. in den, der Ereignisgesteuerten Prozessketten (siehe Scheer [KNS92]), vornehmen. Man erh alt somit ein grobes Schema der in einer Groschadenslage ablaufenden Prozesse, was z. B. nur eine Prozessdokumentation utzlich f sein kann. Durch die De nition der Checklisten erhalt man gleichzeitig Informationen  uber alle potentiellen Aufgaben und deren Prozesse. Checklisten k onnen daher Einblick auf die dahinterliegenden impliziten SOPs geben. Genau dieser E ekt kann dazu beitragen, dass jede BOS sich ihrer implizit vorhandenen SOPs bewusst(er) wird und diese somit re ektieren, evaluieren und verbessern kann. Auch wenn diese Sicht auf die Prozesse noch l uckenhaft ist, da sie sich nur auf kritische Aspekte beziehen, k onnen die Prozessskelette einen Ausgangspunkt f ur eine detailliertere Modellierung sein. Kapitel 7 Vorteile der CASIE-Anwendung in der Praxis In diesem Kapitel wird der praktische Nutzen von Casie zusammengefasst. Dar uber hinaus werden eine Reihe zusautert und Aus atzlicher Vorteile eines solchen Assistenzsystemes erl blicke auf zuk unftige Erweiterungen gegeben. Das Anwendungsfeld der BOS dient dabei an einigen Stellen als Illustration allgemeiner Systemmerkmale. 7.1 Beitrag zur Fehlervermeidung Der in erster Linie durch Casie erreichte Praxisnutzen liegt in der Fehlervermeidung bei der Anwendung von standardisierten Handlungsroutinen. Das liegt vor allem an den Hauptfunktionen von Checklisten (vgl. Kapitel 4): • Sicherstellung eines Qualitur Standardprozeduren, atsstandards f • Handhaben komplexer Prozeduren durch Abstraktion, • Reduktion der Unsicherheit der Einsatzkr afte und • Ged achtnisentlastung in Stresssituationen, die jede f ur sich genommen das Risiko des Auftretens von groben Fehlern (Patzer oder Schnitzer) minimieren katzlich ist zu erwarten, dass im Zu onnen (vgl. Abschnitt 4.1). Zus ge der Kon guration der Checklisten, sich jede BOS auch mit der Qualit at ihrer eigenen SOPs kritisch auseinandersetzt. Der von Reason [Rea90] als eigentlicher Fehler“ bezeich " nete Problematik, unangemessene Plur bestimmte Zielstellungen anzuwenden, kann ane f somit ebenfalls entgegengewirkt werden, da bereits bei der Kon guration o ensichtliche Fehler im Ablauf erkannt und behoben werden k onnen. In der Praxis ist daher zu erwarten, dass Casie dazu beitragen kann, die beiden grundlegenden Fehlertypen Fehler“ und ” Patzer“ auf den von Reason unterschiedenen Handlungsebenen Planung, Speicherung ” und Ausf uhrung zu vermeiden (vgl. Abschnitt 4.1). Nat¨ urlich sind obige E ekte auch bereits mit klassischen, papierbasierten Checklisten zu erreichen. Wie in dieser Arbeit in Abschnitt 5.1 gezeigt wurde, besitzen Groschadenslagen jedoch besondere Merkmale, bei denen der Einsatz papierbasierter Checklisten an seine Grenzen stahlen die zu erwartenden unterschiedlichen Benutzergruppen, die ot. Zu ihnen z geographische Verteilung der Einsatzkr afte, die Vernetztheit der Aufgaben unterschiedlicher SOPs und BOS sowie die Dynamik der Einsatzlage und der Informationsmangel. 107 Prozessmonitoring Computerintegrierte Checklisten k onnen zum einen den bekannten Fehlern (wie z. B. dem Vergessen von Items oder dem Wiederaufnahmefehler) bei der Ausf uhrung von PCL entgegenwirken. Zum anderen kann Casie den besonderen Merkmalen einer Groschadenslage gerecht werden. So kann im Gegensatz zu PCLs den Einsatzkr aften eine theoretisch unbeschr anglich gemacht werden. ankte Zahl an unterschiedlichsten ICLs leicht zug¨ Alle eben genannten Vorteile von Casie zeigen, dass eine IT-unterst¨ utzte Umsetzung des Checklisten-Prinzips im BOS-Bereich besonders geeignet ist, um einen signi kanten Beitrag zur Fehlervermeidung beizutragen. Dies best atigt die These 1 dieser Arbeit. Casie dient in erster Linie den Einsatzleitern verschiedener BOS zur Bereitstellung und Anwendungsassistenz von elektronischen Checklisten. Im Prinzip kann jedoch jede beliebige Einsatzkraft, die at mit einem CL-Client ausgestattet ist, uber ein entsprechendes Endger ebenfalls durch die De nition eigener Checklisten von Casie pro tieren. Das Anwenderspektrum sowie die Anwendungsfelder von Casie sind prinzipiell unbeschr  ankt. Die freie Kon gurierbarkeit des CL-Repositories und der formalen Anwendungsontologie erm oglicht es den Anwendern, ein Assistenzsystem zu etablieren, das genau auf ihre speziellen Anforderungen zugeschnitten ist. 7.2 Prozessmonitoring Besteht eine Verbindung zwischen mehreren CL-Clients am Einsatzort, so kann mittels ¨ der aktuellen Bearbeitungszustande aller ICLs ein Uberblick  uber alle laufenden und abgeschlossenen SOPs abgeleitet werden. Neben den ICLs mit ihren Status inactive, active, completed und canceled, sind deren action-Items hierbei von besonderem Interesse, da sie f ur bestimmte Handlungen/Aufgaben der zu den ICLs korrespondierenden SOPs stehen. Auf Basis des fucksichtigten Status inprogress k ur action-Items speziell beronnen auch alle noch nicht abgeschlossenen, aber bereits gestarteten Aktionen ber ucksichtigt werden. Zusonnen auch abgebrochene ICLs oder Items als solche mittels der Status cancel atzlich k bzw. abandon ber ucksichtigt werden, wodurch Casie eine detailliertere Sicht auf die Einsatzlage bereitstellt, als es nur unter Beratigten Items m ucksichtigung der bestoglich ist. Im Ende ekt erm oglicht dies einen qualitativen Sprung im gesamten Einsatzmanagement. Prinzipiell lassen sich durch die Komponente des Prozessmonitorings folgende Fragen an die Einsatzlage beantworten. 1. Welche Rollen sind im Einsatz aktiv und wer hat diese  ubernommen? 2. Welche ICLs, und daher welche SOPs, sind gerade in Bearbeitung? 3. Welche ICLs wurden bereits abgeschlossen bzw. explizit abgebrochen? 4. Wie ist der jeweilige Bearbeitungszustand der aktiven ICLs? Dies umfasst alle noch o enen, abgeschlossenen und delegierte Items. Abbildung 7.1 zeigt das Schema der durch Casie muberwachung. Die oglichen Prozess vertikalen Pfeile stehen fuber alle aktiven Rollenbereiche hin ur Statusabfragen, in denen,  weg, die Bearbeitungszustonnen. Aufgrund des ande aller aktiven CLs aggregiert werden k Prozesskontextes jeder ICL kann daher auch der Fortschritt aller eingeleiteten SOPs  uberwacht werden. Die Casie-Komponente des Prozessmonitorings kann somit einen Beitrag ¨ dazu leisten, dass Fuhrungskrafte einen umfassenden Uberblick  uber alle laufenden Prozesse erhalten. Somit kann fatzung der eigenen Lage zeitnah auch der Verlauf ur die Einsch der zu den CLs korrespondierende SOPs herangezogen werden. Zus109 atzliche Vorteile und Ausblick Wenngleich uber das Monitoring ucksichtigten SOPs beachtet nur“ die in den ICLs ber ” werden, kann solch eine Funktionalit at einen signi kanten Beitrag zur allgemeinen Situation Awareness (siehe S. 111) leisten. Die Qualit at der auf durch das Monitoring fuenden Entscheidungen kann dadurch wesentlich verbessert werden. Dies untermauert die These 2 dieser Arbeit (vgl. S. 45), welche besagt, dass durch den Einsatz einer Checklisten-Assistenz zugleich ein Monitoring der laufenden Prozesse erreicht werden kann. aktiver Rollenbereich r1 Zeit MCL Sub-CL Sub-CL Sub-CL Sub-CL Sub-CL Prozess- Monitoring … … r2 r3 weitere aktive Rollenbereiche rn … … SOP-Status SOP-Status SOP-Status Abbildung 7.1: Schema des Prozessmonitorings. Obwohl die Informationen aller laufenden Prozesse an jedem beliebigen CL-Client angezeigt werden k onnen, bietet es sich an, die Rollenstruktur und somit die Organisationsstruktur ¨ (vgl. Abb. 5.15) des Einsatzes zu beachten. Uber die Auswertung der Rollenhierarchie kann der Zugriff auf die einzelnen Status der CL-Clients gesteuert und ge ltert werden. Wie eine konkrete GUI-Umsetzung eines Prozessmonitoring realisiert werden kann, soll nicht Gegenstand dieser Arbeit sein. Mit der Task-Agenda des HICAP-Projektes (siehe Abb. 3.3, S. 22) und mit dem Process Panel des CoSAR-TS-Projektes (siehe Abb. 3.3, S. 23 und [TDS02]) wurden bereits m ogliche Umsetzungen vorgestellt, an denen sich orientiert werden kann. Diese Lucksichtigen jedoch noch keine Rollenaspekte und zielen osungen ber ausschlielich auf eine Ausfuberwachung von Pl uhrungsanen ab. 7.3 Zusatzliche Vorteile und Ausblick Im Folgenden wird eine Reihe weiterer Vorteile beschrieben, die Casie in der Praxis bietet. Taskorientierte Datenakquise Wie nicht zuletzt die Erfahrungen des SpeedUp-Projekts zeigten, besteht vor allem in der Chaosphase, aber auch im weiteren Verlauf einer Groschadenslage ein Mangel an (vertrauensw undet, urdigen) Informationen uber die Einsatzlage. Dies liegt zum einen darin begr dass eine Einsatzlage zu Beginn typischerweise noch weitgehend unklar ist und erst erkundet werden muss. Zum anderen auch darin, dass wichtige Informationen zwar verteilt vorliegen, diese jedoch noch nicht an die richtigen Stellen weitergeleitet bzw. zu einem 110 Zus atzliche Vorteile und Ausblick einheitlichen Lagebild aufbereitet wurden. Eine F uhrungskraft, auf welcher Ebene auch immer, wird daher nicht selten auf Basis eines unvollst andigen bzw. veralteten Lagebildes wichtige Entscheidungen tre en m ussen. Um den Faften m¨ uhrungskroglichst zeitnah die Informationen an die Hand zu geben, die sie auch benuhzeitig mit Hilfe ei otigen, liegt die Idee nahe, relevante Daten bereits fr nes IT-Systems aufzunehmen und die sich daraus ergebenden Informationen weiterzuleiten und auszuwerten. Wie das SpeedUp-Projekt gezeigt hat, kann bereits ein relativ einfaches IT-System, das Informationen  uber die Anzahl der Verletzten und deren Triage-Daten sammelt, den Einsatzkrauerst hilfreich sein. Ein allgemeiner Einsatz computerbasierter aften  Informationsplattformen st ot im BOS-Bereich jedoch auf eine grundlegende Schwierigkeit: Woher kommen die Informationen  uber die Einsatzlage und deren momentanen Abarbeitungsstand? Wer soll diese wann und wie in ein Computersystem einp egen? Wie werden diese gespeichert und wie kann auf diese zugegri en werden? Einsatz ubungen im Umfeld des SpeedUp-Projektes zeigten, dass den Faften vor Ort in der Regel kaum Zeit uhrungskr bleibt, umfangreiche Eingaben atz uber eine Tastatur in ein IT-System vorzunehmen. Zus lich versch arft sich das Problem durch widrige technische Gegebenheiten wie z. B. schlechter bedienbare Tastaturen“ von Tablet-PCs oder kleineren mobilen Endger aten. ” Folgt man der Zielstellung dieser Arbeit, nuhrungskr amlich den Faften eine elektronische Checklistenassistenz an die Hand zu geben, die auf einer minimalen Nutzerinteraktion beruht (im Wesentlichen das Abhaken von Items), so erschliet sich quasi ganz nebenbei ein pragmatischer Lur obige Problemstellung. Informationen des Bear osungsbeitrag f beitungsstatus der ICLs konnen dazu genutzt werden, um daraus Ruckschl usse uber die eigene Lage“ onnen. Daronnen query-Items f (vgl. Kapitel 2) ziehen zu kuber hinaus k¨ ur " eine taskorientierte Datenakquise herangezogen werden. Casie kann Informationen gem aß folgender prinzipieller Fragestellungen bereitstellen: 1. Welche Rollen sind aktiv und wer hat sie ubernommen? – Die Rollenzuordnung der ICLs ermuber zu erhalten, welche Rollen durch oglicht es, Informationen darwen atzung genutzt werden und ubernommen wurden. Dies kann zur eigenen Lageeinsch z. B. bei einer mosung eines Rolleninhabers durch eine andere Einsatzoglichen Abl¨ kraft Klarheit ¨ uber die etablierte, aktuelle Rollenstruktur geben. 2. Wie ist der Bearbeitungsstand der einzelnen Aufgaben? – Durch die Interaktion mit den ICLs kuber o ene, laufende und beonnen in Casie automatisch Informationen  reits abgeschlossene Aufgaben gesammelt werden. Realisiert wird diese Funktionalit at  uber das Prozessmonitoring der CL-Manager-Komponente (siehe Abschnitt 6.1). 3. Welche Lagemerkmale sind bisher sicher bekannt? – Zusatzlich kann jeder Status- wechsel eines Items (oder ganzer ICLs) dazu f uhren, dass neue Fakten in die Wissensbasis aufgenommen werden. Das einheitliche Datenmodell, das durch die BOS- Ontologie realisiert wird, garantiert eine semantisch korrekte Speicherung und Verwendung der Informationen. Dar uber hinaus kann die Wissensbasis von Casie als Informationsquelle f ur ein externes Informations-und Managementsystem dienen. Eine rechnerinterne Repr¨ au g immer hinter asentation der Einsatzlage wird jedoch zwangsl einer wirklichen Einsatzlage hinterherhinken. Der Versuch, eine exakte Lagerepr asentation im Computer abzubilden, wird in dieser Arbeit daher nicht verfolgt; vielmehr soll sich nur auf die Einsatzmerkmale konzentriert werden, die aufgrund der Interaktionen mit den ICLs (Auswahl, Abhaken, Beenden) dem System bekannt gemacht wurden. Durch Casie k onnen jedoch nur Informationen gesammelt werden, welche zuvor im Kontext der vorde nierten Zus¨111 atzliche Vorteile und Ausblick Rollenstrukturen und der Aufgaben sowie der damit verkn¨ upften Ergebnisse (Effekte) ber ¨ ucksichtigt wurden. Nichtsdestotrotz bietet Casie einen innovativen und pragmatischen L¨osungsbeitrag zur Frage, wie die Informationen ¨ uberhaupt in ein Computersystem zur Weiterverarbeitung gelangen k¨ onnen. Beitrag zur Steigerung der Situation Awareness Die Informationen, die mittels Casie erhoben werden, k¨ onnen zum Aufbau eines besseren Verst¨uber eine Einsatzlage genutzt werden. Der besondere Vorteil von Casie liegt andnisses ¨ darin, dass Einsatzkr¨ afte aller Organisationen Einblick in laufende Aktionen anderer Teams erhalten k¨atzlich zu einem besseren Verst¨ onnen, was zus¨andnis der Problemstellungen der jeweils anderen BOS f¨ uhren kann. Sich der richtigen Einsatzsituation bewusst zu sein, spielt im Management einer Großschadenslage eine besonders wichtige Rolle. In der Literatur wird hierf¨ ur der Begriff der Situation Awareness (SA) verwendet. Im Crew Resource Management (CRM) der HumanFactors- Forschung in der Luftfahrt nimmt die SA einen prominenten Stellenwert ein (vgl. z. B. [BH89]). Da eine Großschadenslage ¨ ahnliche Charakteristika aufweist, lohnt sich ein Blick auf das Konzept der SA auch im Kontext des BOS-Bereiches. Aufgrund einer vergleichbaren Komplexit¨ at der Arbeitsbereiche greift z. B. Wagner in [Wag06] das Konzept ¨ der SA auf und propagiert eine Ubertragung auf den Bereich der Notfallmedizin. Situation Awareness State of the Environment Decision Performance of Actions Feedback Perception of Elements in Current Situation Comprehension of Current Situation Level 2 Level 1 Projection of Future Status Level 3 External Events a) b) Abbildung 7.2: a) F¨ uhrungsvorgang vs. b) Situation Awareness im Entscheidungsprozess. Um den Beitrag von Casie zur SA in einer Großschadenslage zu illustriere, sei beispielhaft das popul¨ are Modell des SA-Konzeptes im dynamischen Entscheidungsprozess von Endsley (siehe [End00]) aufgef¨ uhrt. Abbildung 7.2 (nach [End00], S. 3) zeigt hierzu unter b) das (vereinfachte1) SA-Modell nach Endsley. Das in Kapitel 2.3 vorgestellte Modell des F¨ uhrungsvorganges (siehe Abbildung 2.3) laut [FwDV100], das auf der linken Seite der Abbildung dem SA-Modell gegen¨ ubergestellt ist, zeigt zudem, dass beide Modelle denselben Zyklus aus leicht unterschiedlichen Perspektiven darstellen. Der Aufbau der SA wird demnach in drei aufeinander folgende Schritte (Level) unterteilt. Die Wahrnehmung der Umweltmerkmale im ersten Level ist der fundamentalste Schritt zum Aufbau einer SA. Darauf aufbauend folgt in Level zwei die Interpretation der Informationen, die zum Aufbau eines gesamten Lageverst¨uhrt. In Level drei wird aus den vorhandenen andnisses f¨ ¨ schneidung mit dem Modell des F¨ 1 Im Bild wurden die Individual Factors und die Task/System Factors ausgespart, da hier die Uber uhrungsvorgangs (Abb. 7.2 a))deutlichgemacht werdensoll. 112 Zus atzliche Vorteile und Ausblick Informationen unftige Entwicklung abgesch uber die Lage deren zukatzt. Das Ergebnis aller drei Level bildet die Grundlage f ur die zu tre enden Entscheidungen. Eines der Hauptprobleme fuhrungskr¨ ur die Fafte in einer Groschadenslage ist der Mangel an zuverluber die Einsatzlage (vgl. assigen Informationen. Indem Casie Informationen ¨ State of the Environment“ ¨ in Abb. 7.2) automatisch uber die Arbeit mit den ICLs ag ” gregieren kann, was vor allem in geogra sch weit verteilten Einsatzsituationen ohne Casie schwer bzw. zeitverzoglich ist, leistet das System einen entscheidenden Beitrag f ogert mur den ersten Schritt der Perception Of Elements In Current Situation“ im SA-Modell. " Wird Casie in der Praxis von allen beteiligten BOS genutzt, so kann es dazu beitragen, das Verstur die jeweils anderen agierenden BOS zu erh andnis fohen. Da in einer Groschadenslage alle BOS an einer altigung zusammenarbeiten, ubergeordneten Lagebew ¨ existieren in einigen Bereichen und zu bestimmten Zeitpunkten Uberschneidungen in den Arbeitsschritten. Die Arbeiten der unterschiedlichen BOS m ussen dann situationsbedingt ineinandergreifen. Deutlich wird dies z. B. bei einem MANV mit chemisch kontaminierten Patienten. Fandig und ur die Dekontaminierung der Verletzten ist die Feuerwehr zust erst nach erfolgter Dekontaminierung kann und soll der Rettungsdienst z. B. mit seinem Sichtungszelt aktiv werden. Weiterhin ist es beispielsweise m oglich, dass aufgrund einer durch die Feuerwehr festgestellten Gefahrgutbeteiligung am Einsatzort (erkannt durch die Beantwortung eines entsprechenden query-Items) Casie dahingehend reagiert, dass alle anderen beteiligten BOS automatisch die passenden ICLs (falls de niert) f ur den Umgang mit Gefahrgutlagen eingespielt (vorgeschlagen) bekommen. In Kombination mit einer diesbez afte dadurch zeitnah uglichen Meldung in der GUI wird die Aufmerksamkeit der Einsatzkr auf diesen neuen Sachverhalt gelenkt. Automatische Protokollierung Eine wichtige Forderung der Praxis ist das Protokollieren des gesamten Ablaufs einer Groschadenslage. Neben der rechtlichen Absicherung ist eine muckenlose Pro oglichst l tokollierung fuhren eines sog. ur jede BOS die Grundlage einer Einsatzevaluierung. Das F Einsatzlogbuchs (oder auch Einsatztagebuch genannt) gestaltet sich jedoch in der Praxis oft als schwierig bzw. wird zugunsten dringenderer“ Handlungen vernachlahrend assigt. W " das Fur einen extra daf uhren eines Logbuchs im Krisenstab fur abgestellten Mitarbeiter noch einfach ist, gestaltet sich eine Protokollierung fuhrungskraft am Einsatzort ur eine F schon problematischer. Aus eigener Erfahrung des Autors werden nicht selten Eintr age in ein Einsatztagebuch erst nach einem Einsatz aus dem Gedanzt oder achtnis verfasst, erg ge andert, worunter die Genauigkeit der Angaben leidet. Auch ein elektronisches Logbuch, das dem Nutzer den Eintrag von Freitext erm¨ oglicht, so wie es z. B. im Rahmen des SpeedUp-Projektes umgesetzt wurde, unterliegt obiger Problematik. So konnte der Autor selbst erfahren, wie unhandlich sich das F uhren eines elektronischen Logbuchs in einer stressigen Einsatzlage gestalten kann. Obwohl die Benutzerfreundlichkeit stark von der jeweils eingesetzten Hardware bzw. des GUI abh angt, bleibt im Einsatz meist kaum die Zeit, um latze oder Stichpunkte korrekt und in Ruhe angere S einzutippen. Hinzu kommt, dass in der Praxis die Eingabe von Text in ein GUI nicht von jeder Einsatzkraft gleich gut bew altigt werden kann. Mit Casie erschliet sich ein alternativer Beitrag zu obiger Problemstellung (siehe Abschnitt 6.2). Da die Interaktionen des Nutzers mit den ICLs minimal ausfallen (vgl. Abschnitt 6.1.1), wird diese Problematik weitgehend vermieden. Die Idee besteht hierbei darin, dass in der Praxis bereits das Aktivieren einer ICL und das einfache Abhaken von Items einen wichtigen Beitrag zur Protokollierung leisten kann. Je nach Statuswechsel der Items (oder ganzer ICLs) kann ein entsprechend vorbereiteter (oder automatisch aggregierter) Zus113 atzliche Vorteile und Ausblick Text in ein lokales/globales Einsatzlogbuch mit einem Klick (bzw. Fingerdruck am Touchscreen) eingetragen werden. Somit l asst sich bequem festhalten, wer was wann festgestellt ¨ bzw. bearbeitet hat. Auch die Ubernahme einer Rolle durch eine Einsatzkraft und der Wechsel der Person zu einer neuen Rolle sind wichtige Informationen, die in einer Dokumentation mit erfasst werden sollten. Eine Einsatznachbereitung und Rekonstruktion kann dadurch mageblich verbessert werden. Kontextabhangige Bereitstellung von Dokumenten In vielen BOS existiert eine Vielzahl an Dokumenten zur Einsatzvorbereitung und Einsatzplanung. Diese reichen von Alarmierungsplanen anen, Kartenmaterialien und Funkpl bis hin zu Rahmenplur spezielle Szenarien (z. B. MANV) oder bestimmten Objekten anen f (z. B. Chemiefabrik) des Einzugsgebietes. Wie die Erfahrungen in SpeedUp zeigten, werden diese Dokumente nicht selten zentral bei der Einsatzleitung (z. B. auf einem Notebook im Einsatzleitfahrzeug) vorgehalten. Damit stellt sich die Frage des organisierten Ablegens dieser Dokumente. Je nach Lage und aktuellem Bearbeitungsstand der Checklisten erm oglicht Casie das Hinterlegen dieser Zusatzinformationen in elektronischer Form. Diese Materialien k onnen den Einsatzkrangig, d. h. jeweiligen SOP oder Task uber die GUI aften kontextabhzur des CL-Clients entsprechend zugur anglich gemacht werden. In Abschnitt 6.1.1 wurde hierf beispielhaft eine entsprechende GUI-Komponente gezeigt. Assistenzsystem f ur dynamische Lageentwicklungen ahrend beim Start von Casie keinerlei Wissen uber die aktuelle Einsatzsituation in der KB vorliegt, wird durch die Interaktion des Nutzers mit dem CL-Client im Laufe eines Einsatzes sukzessiv das Wissen  W uber die Lage erweitert. Zu Beginn eines jeden Einsatzes bedarf es einer initialen Benutzerinteraktion. Als Erstes meldet sich eine Einsatzkraft am CL-Client durch die Auswahl der eingenommenen Rolle an. Danach hat sie Zugriff auf alle hinterlegten CL-Schemata. Je nach Informationslage kann hierbei bereits eine Filterung nach Relevanz automatisch angeboten werden. Im Laufe des Einsatzes passt sich das System mit Hilfe der Informationen, die  uber die Abarbeitung der Checklisten gewonnen wurde, bestm oglich an die Einsatzsituation an. Die Zunahme an faktischem Wissen manifestiert sich  uber die Zeit in der Wissensbasis und dient der fortlaufenden, automatischen ¨ UberprAndert sich etwas in den Vorbedingungen der ufung aller Vorbedingungen der CL. aktiven Checklisten, kann der Nutzer darotz uber automatisch informiert werden. Sind pl lich Kriterien fullt, die noch nicht initiiert wurden, so kann der ur eine CL-Anwendung erf passende Rolleninhaber (falls vorhanden) dar uber informiert werden, dass die Situation die Bearbeitung einer Checkliste erfordert. Wenn es laut einem Item z. B. notwendig ist, einen GerGefahrgutzur Gefahrsto erkundung anzufordern, dies aber bereits atewagen “ " durch eine z. B. uhrungsinstanz erfolgreich geschehen ist, so kann dieser ubergeordnete F Punkt automatisch in der ICL als erledigt“ markiert werden. Dies f uhrt zu einer direkten " Entlastung der Einsatzkr afte und zu einem koordinierterem Vorgehen. Organisations ubergreifende Checklisten Wie die Erfahrungen im SpeedUp-Projekt zeigten, verl auft die Koordination und das Zusammenspiel aller beteiligten BOS in einem MANV oft nicht in der Art, wie es gew unscht ist. Dies kann zu zusuh atzlichen Reibungsverlusten bei einem koordinierten Vorgehen f ren. Zum Beispiel wird in der Praxis um die Nutzung der richtigen Funkkan ale diskutiert, 114 Zus atzliche Vorteile und Ausblick wichtige Ressourcen werden eigenm achtig an falschen Stellen eingesetzt und damit gebunden oder es werden Informationen nicht oder versp atet an andere BOS weitergeleitet. Die bereits oben angesprochene Situation Awareness ist zumeist auf Aspekte beschr ankt, die nur“ ur die eigenen BOS wichtig sind. Mit Casie bietet sich die Moglichkeit der Erstel- f ” lung BOS-ubergreifender Checklisten. Vorausgesetzt, die einzelnen CL-Clients sind  uber ein etabliertes Kommunikationssystem am Einsatzort miteinander verbunden. Die Informationen asentiert durch action-Items) uber initiierte und abgeschlossene Aufgaben (repr kubergreifenden Checkliste aggregiert werden. Diese sollte onnen so in einer organisations als eine Art Meta-Checkliste kritische Aspekte beim Zusammentre en und Arbeiten von BOS mit unterschiedlichen Kompetenz-und Aufgabenbereichen widerspiegeln. Der Einsatz von Checklisten in organisationsanzlich ubergreifenden Prozessen ist ein g neuer Ansatz, der im heutigen Management einer Groschadenslage noch nicht angewandt wird. Die Schwierigkeiten dieser Art der CL-Nutzung liegen jedoch weniger im technischen Bereich. So kann Casie diese Art von Checklisten ohne Weiteres durch z. B. die Einf uhrung einer Meta-Rolle und der ihr zugeordneten Checklisten abbilden. Vielmehr stellt neben der Akzeptanzproblematik die Erstellung solcher organisations ubergreifender Checklisten eine besondere und neuartige Herausforderung dar. Es gilt, viele Interessen und Meinungen unter einen Hut zu bringen. So weisen die in einer Groschadenslage involvierten BOS neben unterschiedlichen Zust andigkeiten und Aufgabengebieten jeweils abweichende und ganz spezi sche Arbeits-und Kommunikationsstile auf (vgl. hierzu [SMS10]). All dies gilt es zu ber ucksichtigen. Neue Items zur Laufzeit einf ugen Bis jetzt wurde davon ausgegangen, dass alle kritischen Aspekte der SOPs im Vorfeld (o line) in Form von CLs erarbeitet werden. Die Einsatzkronnen afte kdaher zur Laufzeit (online) nur“ an zuvor auch ber ucksichtigte Aspekte erinnert werden. Erst im Zuge einer ” Einsatznachbesprechung und Evaluierung k onnen noch fehlende bzw. neue Aspekte erkannt und die jeweiligen CLs funftigen Einsatz erweitert werden. In Interviews (im ur einen zuk Rahmen des SpeedUp-Projektes) uhrungskr auerten Fafte der Feuerwehr den Wunsch, Checklisten nicht erst nach einem Einsatz zu editieren/erweitern, sondern diese Anpas¨ sung bereits wahrend einer Ubung oder gar im Einsatz (wenn es die Umst ande erlauben) vornehmen zu k onnen. Aus Sicht der Erarbeitung und st¨ andigen Verbesserung der Checklisten ist diese Funktionalit  at durch eine Erweiterung im GUI und im CL-Manager realisierbar. In der Praxis ist es wahrend der Bearbeitung einer Check unschenswert, dass ein Anwender bereits w liste neue Items an einer beliebigen Position hinzuf ugen kann. Je nachdem, welche Rolle und welche Aufgabe das neu eingef ugte Item betri t, wird ein Update des entsprechenden CL-Schemas im CL-Repository vorgenommen. Analog zur Hinzunahme von Items kann prinzipiell auch das L oschen und das Anpassen von Items zur Laufzeit erm oglicht werden. Diese sollten jedoch aufgrund der sich daraus ergebenden Problematiken (Update laufender CLs, maf ogliche Verwirrung der Einsatzkr te) erst bei zukatzen ber unftigen Einsucksichtigt werden. In der Praxis kann ein Update auch dazu genutzt werden, allen Beteiligten die sich zur Laufzeit neu ergebenden kritischen Aspekte einer Einsatzlage einzuspielen\, welche nur f ur den aktuell laufenden Einsatz gel " ten sollen. Zu realisieren ist dies z. B. durch die Einf uhrung eines neuen Itemtypes (z. B. temp-Item) in Casie, der nur im aktuellen Einsatz der Checklisten aktiv ist und nicht mit in das CL-Schema aufgenommen wird. In gewisser Weise kommt dies einer Informationsfunktion nahe, Instrument for communicationin ahnlich einer Chatfunktion (vgl. “ ” [WMY11]) in einem Einsatzmanagementsystem. Jedoch mit dem Unterschied, dass sich Zus115 atzliche Vorteile und Ausblick die Einsatzkrussen und die Informa afte nur auf eine Art Assistenzsystem konzentrieren m tionen rollenabhonnen. Somit ist es mit Casie m angig verbreitet werden koglich, basierend auf sich  andernde Spezialanforderungen der aktuellen Situation, kritische Punkte, die sich neu ergeben, ad hoc w ahrend der Laufzeit zu de nieren und allen Beteiligten bekannt zu machen. Alternative Einsatzgebiete Neben den klassischen Einsatzgebieten von Checklisten in Hochsicherheitsbereichen kann die hier vorgestellte Casie-Architektur auch in  ahnlich charakteristischen Arbeitsbereichen hilfreich eingesetzt werden. Gemeint sind alternative Einsatzgebiete, in denen (verteilte) Prozesse in einem beliebigen Notfallszenario fehlerfrei auszuf uhren sind. Das Arbeitsfeld des Business Continuity Management (BCM) ist ein Beispielbereich (vgl. Starke [Sta10], S. 52 .), in dem die Sicherstellung fehlerfreier SOP-Anwendungen im Zuge eines Qualit atsund/ oder Risikomanagements anhand des Checklistenprinzips m oglich ist. Jedes grogliche Notf oere Industrie-oder Wirtschaftsunternehmen bereitet sich auf malle und Krisen vor. Die Etablierung eines BCM wird vielerorts sogar von  ubergeordneten Institutionen verp ichtend vorgeschrieben. Im Rahmen des BCM werden u. a. entsprechende Krisenmanagementpl ane erarbeitet. Sind diese erst einmal vorhanden, stellt sich die Frage: Wie kann sichergestellt werden, dass alle Mitarbeiter im Ernstfall Kenntnis  uber die aktuellen Pluber hinaus auch innerhalb der vorgegebenen \ ane erhalten und darLeitplanken " handeln? Durch die prinzipielle Domangigkeit kann die Casie-Architektur f anenunabhur jedes denkbare Einsatzgebiet kon guriert werden. Somit kann Casie auch f ur diese Art von Notfall-und Krisenprozessen hilfreich eingesetzt werden. Neben Krisenszenarien ist Casie auch zur Sicherstellung der Prozessqualit at einsetzbar. Bei der Einfatsmanagementsystems (QMS) (z. B. gem uhrung eines Qualitaß der ISO-9000 Normenreihe) stellt sich die Frage, wie die Einhaltung der dort zugesicherten und dokumentierten Prozesse  uber die Zeit sichergestellt werden kann. Es gilt, Abweichungen von den SOPs mauchliches Vorgehen im Qualit oglichst zu vermeiden. Ein gebratsmanagement stellt die Standardisierung dar. Konkret werden detaillierte Verfahrensanweisungen f ur bestimmte Arbeitsg ange erarbeitet. Diese Anweisungen sind jedoch eher zur Schulung als zur Assistenz in der Praxis gedacht. Sie k onnen allein noch nicht sicherstellen, dass die Mitarbeiter nichts Wichtiges vergessen. Der in dieser Arbeit erarbeitete L osungsansatz ist zur ¨ Uberpr ufung dieser Prozesse geeignet und kann somit mit Blick auf ein QMS ein wichtiges Hilfsmittel zur Qualit atssicherung darstellen. 116 Kapitel 8 Zusammenfassung Die vorliegende Arbeit beantwortet die Frage, inwieweit eine Computerunterst utzung in komplexen Arbeitsbereichen zu einer Harmonisierung der Handlungsabl aufe und zur Verhinderung von Fehlern (z. B. Ged achtnisfehlern) beitragen kann. Eine Analyse des Arbeitsbereiches deutscher Beh orden und Organisationen mit Sicherheitsaufgaben (BOS) zeigt, dass vor allem der Informationsmangel und die nicht selten auftretenden Handlungsfehler wesentliche Grundprobleme in einer Groschadenslage darstellen. Die Untersuchung existierender Forschungsarbeiten zum Thema ergab, dass sich die dort vorgeschlagenen Latze nur schwer in den Arbeitsprozess deutscher BOS ubertragen lassen. Es osungsans mangelt ihnen an einem praktikablen, d. h. den Anforderungen einer Groschadenslage angepassten Interaktionskonzept mit den Einsatzkr aften, das eine Computerassistenz am Einsatzort ermosungsansatz bietet genau dies. oglicht. Der in dieser Arbeit vorgestellte L Motiviert durch den groen Erfolg von Checklisten (CL) in der Luftfahrt und in der Inten¨ sivmedizin, schlUbertragung des Checklisten-Prinzips auf agt die Arbeit eine systematische den deutschen BOS-Bereich vor. Die Dynamik der Einsatzlage, die Vernetztheit der Aufgaben und die ggf. geographische Verteilung der Einsatzkr afte am Einsatzort erschweren ¨ jedoch eine 1:1-Ubertragung des CL-Prinzips in den BOS-Bereich. Um diese Merkmale zu adressieren, schl agt die Arbeit eine computerintegrierte Umsetzung vernetzter proaktiver Checklisten vor. Dadurch werden zum einen die Probleme vermieden, die beim Einsatz papierbasierter Checklisten zu verzeichnen sind, und zum anderen erschlieen sich damit weitere n utzliche Einsatzgebiete einer Computerassistenz, deren Potential bis heute in der BOS-Praxis kaum ausgesch opft wird (vgl. Kapitel 2). Um alle Anforderungen an ein Checklistensystem f ur den BOS-Bereich zu adressieren, wird in dieser Arbeit ein Rahmenwerk eines intelligenten elektronischen Checklisten-Assistenzsystems (Casie) erarbeitet und bewertet. Die Funktionalitat der computerintegrierten Checklisten geht dabei weit  uber eine bloe elektronische Abbildung hinaus. Vielmehr werden beim Abhaken der Items einer Checkliste wichtige Informationen angigkeit der so uber die Einsatzlage aggregiert. In Abh aufgebauten Informationslage wird im Gegenzug die Checklistendarbietung selbst dynamisch gesteuert. Die dadurch entstehenden erweiterten elektronischen Checklisten werden in Casie intelligente elektronische Checklisten (ICLs) genannt. Die Arbeit zeigt, dass neben dem Haupte ekt der Fehlervermeidung (These 1, siehe S. 45) Casie zusuberwachung der Standardhandlungsroutinen (Standard atzlich zur Prozess Operation Procedures, SOPs) und zum Aufbau eines einheitlichen Lagebildes dienen kann (These 2, S. 45). Daratzlichen Nutzen Casie im uber hinaus wird dargelegt, welchen zus BOS-Alltag und waften bieten kann (These ahrend einer Groschadenslage den Einsatzkr 3, S. 45). Inwieweit Casie die zu Beginn von Kapitel 5 herausgearbeiteten Anforderun 117 118 KAPITEL 8. ZUSAMMENFASSUNG gen an eine elektronische Checklisten-Assistenz erfur Punkt ullt, ist im Folgenden Punkt f zusammengefasst. Wahlfreiheit gewahrleisten: Casie ermoglicht den Einsatzkrzu aften jeder Zeit einen wahlfreien Zugriff auf alle vorkon gurierten ICLs. Die automatischen Vorgaben, die Casie auf Basis der zuvor von der Einsatzkraft eingenommenen Rolle (Aufgabenbereich) anbietet, konnen jederzeit  uberstimmt werden. Der Nutzer kann das Assistenzangebot von Casie nutzen, muss es aber nicht. Ein exibler Wechsel zwischen verschiedenen Checklisten ist dem Anwender zu jeder Zeit m oglich. Ruft er jedoch z. B. eine Checkliste auf, die nicht in sein durch die Rolle bestimmten Aufgabenbereich f allt, so kann Casie ihn auf diesen Sachverhalt hinweisen. Dadurch, dass Checklisten nur kritische Aspekte einer SOP ber ucksichtigen und nureine Erinnerungsfunktion anbieten, bleibt die gewat “ unschte Flexibilit ” in den Handlungen erhalten. Die Anwender k onnen weiterhin frei agieren und werden durch die Checklisten lediglich auf einen groben Handlungsrahmen aufmerksam gemacht. Organisationsaufbau ber ucksichtigen: Da in Casie explizite Rollenzuordnungen unterst oglich, die Checklisten gem utzt werden, ist es maß eines beliebigen (in der Ontologie) vorkon gurierten Organisationsaufbaus auf die unterschiedlichen Zust andigkeitsbereiche zu organisieren und zu verteilen. Dar uber hinaus kann Casie erkennen, ob ein anderer Nutzer genau dieselbe Checkliste bereits bearbeitet, und dies dem Nutzer mitteilen. Einem versehentlichen Mehrfachausf uhren von SOPs kann so e ektiv vorgebeugt werden, wodurch die These 1 untermauert wird. Komplexitoglichkeit zur Aufteilung und Hierarchisierung von Check at handhaben: Die M listen tr agt in Casie dazu bei, dass komplexe Checklisten mittels der Angabe von Sub- Checklisten fubersichtlicher) gestaltet werden k ur die Einsatzkraft handhabbarer (onnen. Komplexe SOPs k onnen somit aufgabengerecht in kleinere aufgeteilt und im Einsatz wieder automatisch zu einer CL-Hierarchie verbunden werden. Die Berechung einer Checklistenhierarchie orientiert sich an der sogenannten Reduktion eines hierarchischen Tasknetzwerks in der HTN-Planung. Dynamik ber ucksichtigen: Die Dynamik einer Einsatzlage wird in Casie wie folgt ber  ucksichtigt. (1) Es werden automatisch ICLs vorgeschlagen, wenn deren Anwendungsbedingungen erfunglich gel ullt sind. (2) Im Gegenzug wird darauf hingewiesen, wenn urspr tende Anwendungsbedingungen nicht mehr gelten. (3) Ereignisse anderer Nutzer k onnen mitbeachtet werden (z. B. Item wurde bereits an einer anderer Stelle erf ullt). Problem des Informationsmangels: Weil Checklisten-Items zum einen mit Nachbedingungen annotiert und zum anderen Daten an geeigneter Stelle  uber die query-Items abgefragt und im System aufgenommen werden kagt Casie zur Verbesserung des onnen, tr Aufbaus eines einheitlichen Lagebildes bei. Da des Weiteren die Informationen, die sich  uber die ICLs gewinnen lassen, Konzepten aus der Ontologie zugeordnet sind, ist deren ¨ Bedeutung klar de niert. Daruber hinaus gibt das Prozessmonitoring einen Uberblick  uber die eigene Lage“ der Einsatzkr afte. Dies untermauert die These 2. " Dokumentation & Backup: Der in Casie vorgesehene automatische Logbookmechanismus erf ullt die Praxisanforderung einer Dokumentationsp icht, indem detaillierte Informationen  uber die Bearbeitung der SOPs automatisch protokolliert und festgehalten werden k onnen. Die Frage, wer was wann eingeleitet und mit welchem Erfolg abgeschlossen hat, l asst sich somit leicht und zu jeder Zeit beantworten. Zugri /Organisation von Zusatzressourcen: Die in der BOS-Praxis vorhandenen elektronischen Dokumente (Gebane, Einsatzpl audeplane, Funkschemata und Telefonnummernregister) kaften, gem onnen in Casie den Einsatzkraß ihres Aufgabenkontextes, direkt an den Stellen des Arbeitsprozesses automatisch zug anglich gemacht werden, an denen sie KAPITEL 8. ZUSAMMENFASSUNG eine Hilfestellung bieten. Zusatzinformationen zu einem Item oder auch zu einer ganzen Checkliste kuber die vernetzten Checklisten bereitgestellt werden. onnen so ebenfalls leicht ¨ Einfache Bedienung: Eine der St¨ arken von Casie liegt in der Art und Weise, wie die Anwender mit dem System interagieren. Sie arbeiten zur Einsatzzeit ausschlielich mit den Checklisten, die f ur sie ein wohlvertrautes bzw. leicht zu verstehendes Konzept darstellen. Dadurch wird zur Laufzeit im Wesentlichen vom Nutzer nur eine minimale Interaktion mit dem System erwartet. Lediglich die Eingabe konkreter Daten bei query-Items verlangt vom Nutzer mehr Aufwand. Einheitliches Vokabular: Die Forderung, f ur die Texte der Items und die Beschreibungen ein mutzt Casie dahingehend, dass oglichst einheitliches Vokabular zu verwenden, unterst den Einsatzkr aften durch die Formulierung einer BOS-Ontologie solch ein einheitliches Vokabular zur Verfur die Erstellung der Texte zu den Items herangezogen ugung steht, das f werden kann. Letztendlich obliegt es jedoch den Einsatzkr aften selbst, eine ausreichende Konsistenz bei der Wahl der Begriichkeiten einzuhalten. Unterschiedliche Benutzergruppen: Dadurch, dass Casie durch die Einsatzkr afte selbst frei kon gurierbar ist, d. h., jeder Nutzer ICLs seiner Wahl im Repository hinterlegen kann, steht auch einer Personalisierung der einzelnen Checklisten nichts im Wege. Damit unterschiedliche ICLs f ur ein und dieselbe SOP im Einsatz auch entsprechend zugreifbar sind, bedarf es lediglich einer zuvor hinterlegten Nutzerkennung. Die dafotigten Informa ur ben tionen sind im Wesentlichen bereits dadurch gegeben, dass sich jeder Nutzer an seinem CL-Client explizit mit seinem Namen anmeldet und so automatisch die f ur ihn hinterlegten Checklisten dargeboten bekommt. Als Ergebnis der Arbeit steht interessierten Anwendern mit Casie ein Rahmenwerk eines neuartigen Checklisten-Assistenzsystems zur Verf ugung. Erst durch die ICLs, als elektronische Checklisten, erschliet sich ein Mehrwert gegen uber klassischen papierbasierten Checklisten. Neuartig ist vor allem der Ansatz, computerintegrierte Checklisten untereinander zu vernetzten und mit einer formalen Wissensbasis zu kombinieren, um ein maschinelles Schlieen oglichen. Dadurch k uber Fakten einer Einsatzlage zu ermonnen Informationen  uber die Einsatzlage gesammelt, protokolliert und vom Computer automatisch entsprechend ihrer Bedeutung ausgewertet werten. Um ein f ur die Problemstellung angemessenes Rahmenwerk zu erarbeiten, wurden in dieser Arbeit folgende Aufgabengebiete bearbeitet: 1. Umfassende Analyse des Checklistenprinzips aus einer Human-Factors-Perspektive 2. Erarbeitung der Anforderungen an eine elektronische Checklisten-Assistenz 3. Entwicklung eines technologischen Rahmenwerkes (Modellierung, Architektur, Technologieauswahl, Dynamik, Kon guration von Checklisten als prozedurale Wissensrepr  asentation) 4. Entwicklung (beispielhaft) einer formalen BOS-Ontologie [BOS-O] als terminologische Wissensrepr asentation Damit eine konkrete Casie-Instanz in der Praxis erfolgreich genutzt werden kann, gilt es aus informatischer Sicht, noch eine Reihe von weiteren Herausforderungen zu meistern. Neben der Realisierung eines Basiskommunikationssystems, das f ur die Anwendung von Casie vorausgesetzt wurde, werden geeignete Softwarewerkzeuge ben otigt, die dem Anwender das Erstellen und die Wartung der ICL-Beschreibungen auf eine bequeme Art und 120 KAPITEL 8. ZUSAMMENFASSUNG Weise ermatzlich bedarf es weiterer Forschung hinsichtlich geeigneter Benut oglichen. Zus zerschnittstellen, die das volle Potential von Casie aussch opfen und den Anforderungen eines Einsatzes in einer Groschadenslage genussen. Eine weitere noch o ene Frage ugen m stellung betri t den Abgleich der individuellen Wissensbasen unterschiedlicher CL-Clients. Hier gilt es, m ogliche Inkonsistenzen und versteckte Redundanzen zu vermeiden bzw. geeignet zu behandeln. Des Weiteren sind die heutigen Programmierschnittstellen zur Ontologieunterst  utzung (siehe z. B. [OWL-API]), zum Reasoning (z. B. [FaCT++]) und zur Realisierung einer Wissensbasis noch unhandlich und erfordern viel Know-how, um sie zu beherrschen und geeignet miteinander in einer Praxisanwendung zu verbinden. Die Bereitstellung eines technischen Assistenzsystems allein garantiert jedoch noch nicht, dass der angestrebte Haupte ekt der Fehlervermeidung erreicht wird. Damit die L osung nicht zum Problem wird, bedarf es weiterer Untersuchungen, wie ein Assistenzsystem wie Casie in der Praxis genau eingefur welche Bereiche ICLs geeignet sind und uhrt wird und f fur matzlich zu den technischen Problemstellungen folgende ur welche nicht. Hierfussen zus Aufgaben gemeistert werden: • Erarbeitung einer Fehlerkultur und unterschiedlicher Anwendungsphilosophien, • Latze f osungsansur die Akzeptanzproblematik, • Beachten der Arbeitsumgebung bei der Anwendung von Checklisten, • Aspekte der Fehlbenutzung und deren Auswirkungen, • Kulturwandel bei Nutzung von Checklisten im Arbeitsprozess, • m ogliche E ekte bei Abweichung von Checklisten und • die Erarbeitung geeigneter Evaluationskriterien und -konzepte. Vor allem der Checklisteneinsatz f ur Nichtexperten stellt ein kaum untersuchtes Forschungsgebiet dar, da er von der Einsatzphilosophie anderer Hochsicherheitsbereiche abweicht, in denen Checklisten ausschlielich die Experten bei komplexen Arbeitsschritten unterst utzen. Jedoch ist gerade in Anbetracht wenig trainierter Einsatzkr afte eine Lockerung dieser Forderung sinnvoll. Immer dort, wo Mitarbeiter zum Einsatz kommen, die (aus unterschiedlichen Gronnen unden) unsicher in dem sind, was und wie sie etwas zu tun haben, k Checklisten zur Orientierung beitragen. Es gilt aber, Situationen vorzubeugen, in denen Einsatzkruberlegen, blind den Checklisten folgen: afte, ohne selbst zu Ja, aber laut Check " liste sollte ich doch ...\. Solch eine Reaktion o enbart, dass das Prinzip hinter den Checklisten entweder falsch vermittelt wurde oder aber Checklisten als ausschlielich normatives Mittel zur Prozesssteuerung gebraucht werden. In beiden F allen ist zu bezweifeln, dass der E ekt der Fehlervermeidung wirklich eintritt. Dem gilt es, durch ein geeignetes Training und eine begleitende Einf uhrung der Checklisten in den Praxisbetrieb vorzubeugen. Der zunehmende Einsatz von Computern im BOS-Bereich ermunftig neuar oglicht es, zuk tige Assistenzsoftware am Einsatzort einzusetzen. Mit Casie stellt diese Arbeit ein Rahmenwerk bereit, in dem genau solch eine neuartige Assistenz beschrieben wird. Die Arbeit stellt einen Ausgangspunkt fuhrender (interdisziplin ur eine Reihe weiterfarer) Forschungsarbeiten dar. Weiterhin soll sie die BOS-Einsatzkr afte dazu motivieren, eine elektronische Checklisten-Assistenz auf Basis des Casie-Rahmenwerkes in ihrem Bereich einzusetzen, zu testen und zu evaluieren. In Anbetracht der vielen Vorteile, die Casie in der Praxis bieten KAPITEL 8. ZUSAMMENFASSUNG kann, und der immer komplexer werdenden Arbeitsumgebungen sollte jede Organisation mit Sicherheitsaufgaben daran interessiert sein, solch ein System im Praxisbetrieb einzusetzen. So wie die Luftfahrt aus ihren Fehlern gelernt hat, so sollten auch die BOS den Einsatz neuartiger Technologie zur Fehlervermeidung bedenken. Die ben otigten Grundtechnologien sind bereits vorhanden, sie mnur“ geeignet kombiniert und richtig eingesetzt werden, ussen ” dann lane Leben retten. Auch wenn der asst sich in der hier fokussierten Anwendungsdom Weg zu einer erfolgreichen Etablierung einer elektronische Checklistenassistenz m uhsam erscheint, die Aussicht auf nur ein gerettetes Menschenleben sollte Motivation genug sein, diesen Weg zu gehen. 122 Literatur [ACF+05a] Marc de la Asunci´ Knowledge on, Luis Castillo, Juan Fdez-Olivares u. a. " and plan execution management in planning re ghting operations\. In: Planning, Scheduling and Constraint Satisfaction: From Theory to Practice. IOS PRESS, 2005, S. 149{158 (siehe S. 26). [ACF+05b] Marc de la Asunci´ SIADEX: An on, Luis Castillo, Juan Fdez-Olivares u. a. ” interactive knowledge-based planner for decision support in forest re ghting\. In: AI Communications 18.4 (2005). Volume 18, Issue 4 (December 2005), Binding Environmental Sciences and AI, S. 257{268 (siehe S. 21, 25). [AGP04] Marc de la Asunci´ a-P´ on, Oscar Garcerez und Francisco Palao. SIADEX: A Real World Planning Approach for Forest Fire Fighting Introduction. 2004 (siehe S. 25). [AH04] Grigoris Antoniou und Frank Harmelen. A Semantic Web Primer (Cooperative Information Systems). The MIT Press, 2004 (siehe S. 81). [Amm05] Stefanie Ammon. uberzeugung und Commitment, Leistungsmotivation, Kontroll " erlebter T¨ aftigten in unternehmen und Beh atigkeitsspielraum von Beschorden im Vergleich\. Diss. Fachbereich Kultur-und Sozialwissenschaften der FernUniversit at in Hagen, 2005 (siehe S. 67). [Ark06] Debby Arkell. From safe to safer: Boeing's Electronic Checklist marks 10 years of " enhanced safety for pilots and travelers\. In: Boing Frontiers (online) 04.11 (2006). http://www.boeing.com/news/frontiers/archive/2006/april/i ca3. html (abgerufen am 20.12.2013) (siehe S. 39, 44). [Ars08] Emilija Arsenova. Unterstutzung der Prozessmodellierung im Notfallmanagement. Gesellschaft f ur Informatik (Ed.) Informatiktage 2008. B-IT Bonn-Aachen, International Center for Information Technology, Bonn, Gesellschaft f ur Informatik. 2008 (siehe S. 19, 106). [Bar05] Martin Bartonitz. BPMS, BPML, BPEL, BPMN, WMS, XPDL, Am, Alles ist ¨ " so sch on bunt hier\. In: PROJECT CONSULT Newsletter (2005), S. 8{13 (siehe S. 18). [BBD+05] Stefan Brockmann, Christoph Brodesser, Bernd Domres u. a. Gefahrenabwehr bei Groveranstaltungen. Hrsg. von Klaus Maurer und Hanno Peter. Verlagsgesellschaft Stumpf + Kossendey, Edewecht, Wien, 2005 (siehe S. 10). [BBK10] Schutzkommission beim Bundesministerium des Innern, Bundesamt f ur Bev olkerungsschutz und Katastrophenhilfe, Bonn. Katastrophenmedizin – Leitfaden farztliche Versorgung im Katastrophenfall¨ . ur die Bonifatius GmbH, Druck – Buch – Verlag, Paderborn. 5. vuberarbeitete Au age , M ollig unchen 2010. 2010 (siehe S. 10). [BCM+03] Franz Baader, Diego Calvanese, Deborah McGuinness u. a. The Description Logic Handbook: Theory, Implementation and Applications. Cambridge, UK: Cambridge University Press, 2003 (siehe S. 82, 86). [BCM+07] Franz Baader, Diego Calvanese, Deborah McGuinness u. a. The Description Logic Handbook: Theory, Implementation and Applications (2nd Edition). Cambridge, UK: Cambridge University Press, 2007 (siehe S. 82, 83, 86). 123 LITERATUR [BH89] D. B. Beringer und P. A. Hancock. Exploring situational awareness: A review " and the e ects of stress on rectilinear normalisation.“ In: In Proceedings of the Fifth International Symposium on Aviation Psychology. Bd. 2. Columbus: Ohio State University. 1989, S. 646{651 (siehe S. 40, 111). [BH91] Franz Baader und P. Hanschke. A Scheme for Integrating Concrete Domains " into Concept Languages\. In: Proceedings of the 12th International Joint Conference on Arti cial Intelligence, IJCAI-91. Sydney (Australia), 1991, S. 452{457 (siehe S. 84). [BHG+01] Sean Bechhofer, Ian Horrocks, Carole Goble u. a. OilEd: a Reason-able ” Ontology Editor for the Semantic Web\. In: Proceedings of KI2001, Joint German/ Austrian conference on Arti cial Intelligence. Lecture Notes in Computer Science 2174. Vienna: Springer-Verlag, 2001, S. 396{408 (siehe S. 96). [BHL08] Petra Badke-Schaub, Gesine Hofinger und Kristina Lauche, Hrsg. Human Factors: Psychologie sicheren Handelns in Risikobranchen. 1. Au . Springer Medizin Verl., Heidelberg, 2008 (siehe S. 1, 39). [BHS08] Franz Baader, Ian Horrocks und Ulrike Sattle. Description Logics\. In: Hrsg. " von V. Lifschitz Edited by F. van Harmelen und B. Porter. Handbook of Knowledge Representation. Elsevier B. V., 2008. Kap. 3, S. 135{176 (siehe S. 83, 85). [BLK11] T. Becker, B.-S. Lee und R. Koch. utzung im Eziente Entscheidungsunterst " Krisenfall durch interaktive Standard Operating Procedures.“ In: Software Engineering (Workshops). Hrsg. von Ralf Reussner, Alexander Pretschner und Stefan J ahnichen. Bd. 184. LNI. GI, 2011, S. 217{224 (siehe S. 20, 28, 34, 41, 43, 46). [BMBF] Bundesministerium f ur Bildung und Forschung (BMBF). Bewilligte Projekte aus dem Themenfeld Schutz und Rettung von Menschen der Programmlinie Szena ” rienorientierte Sicherheitsforschung\. http:// www.bmbf.de/ de/ 13091.php (abgerufen am 20.12.2013). 2010 (siehe S. 2). [Boo01a] Daniel Boorman. Safety Bene ts of Electronic Checklists: An analysis of Com " mercial Transport Accidents\. In: Boeing Commercial Airplanes (2001). Boeing Commercial Airplanes, Seattle, Washington (siehe S. 39, 44). [Boo01b] Daniel Boorman. Today's electronic checklists reduce likelihood of crew errors " and help prevent mishaps.“ In: ICAO Journal, International Civil Aviation Organization 56.1 (2001), S. 17{20 (siehe S. 39). [BOS-O] Uwe Krasentation uger. Beispielmodellierung einer terminologischen Wissensrepr der Domane deutscher BOS (Beh orden und Organisationen mit Sicherheitsauf gaben). http: // sourceforge. net/ projects/ bos-ontology/ (abgerufen am 20.12.2013). 2013 (siehe S. 50, 72, 84, 86, 87, 95, 96, 100, 119). [Bos07] Christiane Bosold. Polizeiliche at als Erkl ¨ Ubergri e: Aspekte der Identitarungsfaktoren polizeilicher Ubergri sintentionen – Eine handlungspsychologische Perspekti ¨ ve. Nomos Verlag, Baden-Baden, 2007 (siehe S. 67). [BP07] Cornelius Buerschaper und Michale St. Pierre. Teamarbeit in der Anasthesie  ” – Entwicklung einer Checkliste\. In: Hrsg. von Stefan Strohschneider. Bd. 2. Menschen in kritischen Situationen – Schriftenreihe der Plattform Menschen in komplexen Arbeitswelten e. V. Verlag f ur Polizei-Wissenschaft, 2007. Kap. 3, S. 25– 38 (siehe S. 33, 37, 39). [Bra10] Tom Brabant. The simple genius of checklists -Boeing's experience using check " lists is helping many other professions\. In: BOEING FRONTIERS October (2010), S. 42{43 (siehe S. 39, 40). [BS01] Susanne Biundo und Bernd Schattenberg. From Abstract Crisis to Concrete ” Relief -A Preliminary Report on Combining State Abstraction and HTN Planning\. In: Proceedings of the 6th European Conference on Planning (ECP-01). Springer Verlag, 2001 (siehe S. 21, 26, 27). LITERATUR 125 [Bur05] ¨ Richard G. B urmann. Ezientes Prozessmanagement im Katastrophenschutz. 1. Europuherkennung, Alarmierung, Ko aischer Katastrophenschutzkongress; 2005: Fr ordination; Bad Godesberg; (IDS Scheer AG). 2005 (siehe S. 18). ´ [CFG+06] Luis Castillo, Juan Fdez-Olivares, Oscar Garca-P´ u. a. Eciently erez " handling temporal knowledge in an HTN planner\. In: In 16th International Conference on Automated Planning and Abstract Reasoning for Planning and Cooerdination Scheduling (ICAPS-06). AAAI, 2006, S. 63{72 (siehe S. 25). [CG05] Ulrich Cimolino und Arvid Graeger. Standardeinsatzregel. Ubersicht der verof- ¨ fentlichten Brosch uren www.standardeinsatzregel.org (abgerufen 01.12.2013). 2005 (siehe S. 14, 15, 37, 51). [Che76] P. Pin-Shan Chen. The entity-relationship modeltoward a uni ed view of data\. " In: ACM Trans. Database Syst. 1.1 (M arz 1976), S. 9{36 (siehe S. 102). [CP07] Udo B. Crespin und Hanno Peter, Hrsg. Handbuch f ur den Organisatorischen Leiter. Stumpf + Kossendey Verlagsgesellschaft mbH, 2007 (siehe S. 14). [DAML] DAML: The DARPA Agent Markup Language Homepage. http:// daml .org (abgerufen 20.12.2013) (siehe S. 83). [DHS06] DHS. Writing Guide for Standard Operating Procedures. U.S. Department of Homeland Security (DHS). 2006 (siehe S. 51). [DIN13050] DIN 13050. Rettungswesen – Begri e (Emergency services – Terms and de nitions). DIN Deutsches Institut fur: DIN ur Normung e. V., Beuth-Verlag. Ersatz f 13050:1996-06. 2009 (siehe S. 10). [DLCN] Evgeny Zolin. The Description Logic Complexity Navigator: Complexity of reasoning in Description Logics. http:// www .cs.man.ac.uk/ ~ezolin/ dl/ (abgerufen am 20.12.2013) (siehe S. 84). [DW90] Asaf Degani und Earl L. Wiener. Human Factors of Flight-Deck Checklists: The Normal Checklist. Techn. Ber. NASA contractor report; NASA CR-177549, National Aeronautics & Space Administration, Ames Research Center, 1990 (siehe S. 2, 34, 35, 37). [DW91] Thomas L. Dean und Michael P. Wellman. Planning and control. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 1991 (siehe S. 33). [DW93] A. Degani und E. L. Wiener. Cockpit Checklists: Concepts, Design, and Use.“ " In: Human Factors 35 (1993), S. 345{359 (siehe S. 2, 34, 35, 37). [DD. Dosen als Informationsverarbeitung. Stuttgart: Kohlhammer, or75] orner. Probleml¨ 1975 (siehe S. 1). [EHN94a] Kutluhan Erol, James A. Hendler und Dana S. Nau. HTN Planning: Comple " xity and Expressivity\. Englisch. In: AAAI. 1994, S. 1123{1128 (siehe S. 21). [EHN94b] Kutluhan Erol, James A. Hendler und Dana S. Nau. UMCP: A Sound and ” Complete Procedure for Hierarchical Task-Network Planning.“ In: Proceedings of the 2nd International Conference on Arti cial Intelligence Planning Systems (AIPS94). 1994, S. 249{254 (siehe S. 21). [Ell11] Klaus Ellinger. Kursbuch Notfallmedizin: Orientiert am bundeseinheitlichen Curriculum Zusatzbezeichnung Notfallmedizin. Deutscher Arzte-Verlag, 2011 (siehe S. 15). ¨ [End00] M. R. Endsley. Theoretical underpinnings of situation awareness: a critical re " view\. In: Situation Awareness Analysis and Measurement. Hrsg. von M. R. Endsley und D. J. Garland. Mahwah, NJ, USA: Lawrence Erlbaum Associates, 2000 (siehe S. 111). [Ero96] Kutluhan Erol. Hierarchical Task Network planning: formalization, analysis, and " implementation\. Advisors: Nau, D. and Hendler, J. Diss. University of Maryland, 1996 (siehe S. 22). LITERATUR [FaCT++] FaCT++: OWL-DL Reasoner. Department of Computer Science, University of Manchester, http://owl.man.ac.uk/factplusplus/ (abgerufen am 20.12.2013) (siehe S. 85, 120). [FCG+06] Juan Fdez-Olivares, Luis Castillo, Oscar Garca-P´ Bringing Users erez u. a. " and Planning Technology Together. Experiences in SIADEX\. In: Proc. 16th International Conference on Automated Planning and Scheduling (ICAPS). AAAI Press, 2006, S. 11{20 (siehe S. 25). [FEM99] FEMA. Developing E ective Standard Operating Procedures For Fire and EMS Departments. Hrsg. von Federal Emergency Management Agency's United States Fire Administration (FEMA). United States Fire Administration, 1999 (siehe S. 51). [FG97] Dieter Frey und Siegfried Greif. Sozialpsychologie: Ein Handbuch in Schlusselbegri en. Bd. 4. BeltzPVU, 1997 (siehe S. 66{69). [Fox97] Maria Fox. Natural Hierarchical Planning Using Operator Decomposition\. In: " Proceedings of the 4th European Conference on Planning: Recent Advances in AI Planning. ECP '97. London, UK: Springer-Verlag, 1997, S. 195{207 (siehe S. 21). [FwDV100] Feuerwehr-Dienstvorschrift 100. Projektgruppe Feuerwehr-Dienstvorschriften des Ausschusses f ur Feuerwehrangelegenheiten, Katastrophenschutz und zivile Verteidigung (AFKzV), 1999, (siehe S. 6, 10, 13, 111). [Gaw10] Atul Gawande. The Checklist Manifesto: How to Get Things Right. Pro le Books, 2010 (siehe S. 2, 34, 35, 37, 40, 44). [Gei95] K. Geihs. Client-Server-Systeme. Thomson's aktuelle Tutorien. Internat. Thomson Publ., 1995 (siehe S. 77). [GF95] Michael GrMethodology for the Design and Evaluauninger und Mark S. Fox. " tion of Ontologies\. In: 1995 (siehe S. 95, 97). [GFC04] Asunciomez-P´ andez-L´ on Gerez, Mariano Fernopez und O. Corcho-Garcia. Ontological Engineering: With examples from the areas of Knowledge Management, e-Commerce and the Semantic Web (Advanced Information and Knowledge Processing). Springer, Berlin, 2004 (siehe S. 95). [GHA+05] J. Gancet, G. Hattenberger, R. Alami u. a. Task Planning and Control for " a multi-UAV system: architecture and algorithms\. In: IEEE International Conference on Intelligent Robots and Systems, Edmonton (Canada). 2005 (siehe S. 21). [GIL98] Melinda T. Gervasio, Wayne Iba und Pat Langley. Case-Based Seeding for " an Interactive Crisis Response Assistant\. In: In D.W. Aha & J.J. Daniels (Eds.) Case-Based Reasoning Integrations: Papers from the 1998 Workshop (Technical Report WS-98-15). Menlo. AAAI Press, 1998 (siehe S. 22). [GKB10] Michael R. GrMarkus Kohler und Giancarlo Buono.unninger, Too much ” plane for one man to y – Checklsits\. In: Bart International 125 (2010), S. 78{79 (siehe S. 32). [GKM+11] A. Gabdulkhakova, B. Kahler u. a. onig-Ries, M. MIdentifying and Sup " porting Information Needs in Mass Casualty Incidents – an Interdisciplinary Approach\. In: Proceedings of the 8th International ISCRAM Conference. Lisbon, Portugal. 2011 (siehe S. 50). [GLB86] E. Grochla, H. Lippold und J. Breithardt. Pru isten zur Schwachstellenermittlung in B uro und Verwaltung. Maschinenbau-Verlag, 1986 (siehe S. 32). [GNT04] Malik Ghallab, Dana Nau und Paolo Traverso. Automated Planning: Theory and Practice. Morgan Kaufmann Publishers, 2004 (siehe S. 21{23, 64, 65). [Gro04] Gudela Grote. Uncertainty management at the core of system design\. In: Annual " Reviews in Control 28.2 (2004), S. 267{274 (siehe S. 39). [Gru03] David Grusenmeyer. Developing E ective Standard Operating Procedures\. In: " (2003). Sr. Extension Associate PRO-DAIRY, Cornell Universit (siehe S. 51, 105). LITERATUR 127 [Gru93] Thomas R. Gruber. A translation approach to portable ontology speci cations\. " In: Knowledge Acquisition 5 (1993), S. 199{220 (siehe S. 81). [Hac06] Achim Hackstein. Einsatztaktik – Rettungsdienst kompakt Band 2. Hrsg. von Frank Flake und Klaus Runggaldier. Stumpf + Kossendey Verlagsgesellschaft mbH, 2006 (siehe S. 11). [Hac97] Winfried Hacker. Allgemeine Arbeitspsychologie. Psychische Regulation von Arbeitst  atigkeiten. Huber, Bern, 1997 (siehe S. 67). [HB11] Matthew Horridge und Sean Bechhofer. The OWL API: A Java API for OWL ” ontologies\. In: Semantic Web 2.1 (Jan. 2011), S. 11{21 (siehe S. 85). [HBS13] M. Hofmann, H. Betke und S. Sackmann. A Novel Architecture for Disaster ” Response Work ow Management Systems\. In: Proceedings of the Information Systems for Crisis Response and Management conference (ISCRAM). 2013, S. 338– 343 (siehe S. 21). [Hei09] Rudi Heimann. Entscheidungs ndung in polizeilichen Einsatzlagen – Softwareun " terst utztes Informations-und Kommunikationsmanagement\. In: Lecture Notes in Informatics, INFORMATIK 2009 – udiger Rei- Im Focus das Leben. Hrsg. von R schuk (ed.) Stefan Fischer (ed.) Erik Maehle (ed.) Gesellschaft f ur Informatik, Bonn. 2009, S. 1378{1392 (siehe S. 16). [HJW94] C. W. Holsapple, V. S. Jacob und Andrew B. Whinston. Operations Research and Arti cial Intelligence. Ablex Publishing Corporation, 1994 (siehe S. 60). [HMW01] Volker Haarslev, Ralf MThe Description Logic oller und Michael Wessel. " ALCNHR+ extended with Concrete Domains: A Practically Motivated Approach\. In: In Proceedings of International Joint Conference on Automated Reasoning, IJCAR' 2001. Springer, 2001, S. 29{44 (siehe S. 84). [HP06] B. M. Hales und P. J. Pronovost. The checklist – a tool for error management " and performance improvement\. In: Journal of Critical Care 21 (2006), S. 231{235 (siehe S. 35, 40). [HPK+12] A. Von der Heyde, P. Presting, A. Kluge u. a. Social norms and their impact " on safety-related rule violations in process control: Does it make a di erence if operators are aware that residents will be injured?“ In: Proceedings of the 56th Annual Meeting of the Human Factors and Ergonomics Society (HFES). 2012 (siehe S. 15). [HPM+07] Ian Horrocks, Peter F. Patel-Schneider, Deborah L. McGuinness u. a. OWL: ” a Description Logic Based Ontology Language for the Semantic Web\. In: The Description Logic Handbook: Theory, Implementation, and Applications (2nd Edition). Hrsg. von Franz Baader, Diego Calvanese, Deborah McGuinness u. a. Cambridge University Press, 2007. Kap. 14 (siehe S. 84). [HS98] A. R. Hale und P. Swuste. Safety rules: procedural freedom or action cons " traint?“ In: Safety Science 29.3 (Aug. 1998), S. 163{177 (siehe S. 39). [Jab95] Stefan Jablonski. Work ow-Management-Systeme: Modellierung und Architektur. International Thomson Publishing, 1995 (siehe S. 18, 76). [Jac98] Peter Jackson. Introduction to Expert Systems. 3rd. Boston, MA, USA: Addison- Wesley Longman Publishing Co., Inc., 1998 (siehe S. 20). [KG12] Annette Kluge und Britta Grauel. Checklisten und Arbeitshilfen ("Job Aids") – " ist die Gestaltung wichtig?“ In: Wirtschafts-& Organisationspsychologie, Komplexit – ur Organisationales Lernen, Simulation und Trai at und Lernen Newsletter f ning. 24. Fachbereich Wirtschafts-und Organisationspsychologie, Fakultur In at f genieurwissenschaften, Fachbereich Informatik und Angewandte Kognitionswissen schaft & OPSY – HSG, 2012 (siehe S. 31). 128 LITERATUR [KGB12] A. Kluge, B. Grauel und D. Burkolter. " Combining principles of Cognitive Load Theory and diagnostic error analysis for designing job aids: E ects on motivation and diagnostic performance in a process control task\. In: Applied Ergonomics (2012). Elsevier, 2012 (siehe S. 31). [KGK+10] U. Kruger, A. Gabdulkhakova, B. Konig-Ries u. a. ” Semantic Service Infrastructure for Intelligent Checklist Support Systems\. In: International Workshop on Emergency Management through Service Oriented Architectures. Ghent, 2010 (siehe S. 3, 20, 45, 56, 75). [KHK+06] K. G. Kanz, P. Hornburger, M. V. Kay u. a. " mSTaRT-Algorithmus fur Sichtung, Behandlung und Transport bei einem Massenanfall von Verletzten\. In: Notfall + Rettungsmedizin 3.3 (2006). Springer Medizin Verlag, S. 264{270 (siehe S. 1). [Kla01] Joachim Klausner. " Planen und intelligentes Work ow-Management\. Diss. Friedrich- Schiller-Universitat Jena, 2001 (siehe S. 18, 76). [KNS92] G. Keller, M. Nuttgens und A. W. Scheer. " Semantische Prozemodellierung auf der Grundlage Ereignisgesteuerter Prozeketten (EPK)\. In: Wirtschaftsinformatik 89 (1992), S. 1579{1587 (siehe S. 18, 106). [KPC06] Stasinos Konstantopoulos, Georgios Paliouras und Symeon Chatzinotas. " SHARE-ODS: An Ontology Data Service for Search and Rescue Operations\. Englisch. In: SETN. 2006, S. 525{528 (siehe S. 20). [KPS+08] S. Konstantopoulos, J. Pottebaum, J. Schon u. a. " Ontology-Based Rescue Operation Management\. In: Mobile Response. 2008, S. 112{121 (siehe S. 99). [Kry72] K. D. Kryter. " Speech communication\. In: Human engineering guide to equipment design, H. Van Cott and R. G. Kinkade (1972). Washington, DC: U.S. Government Printing Oce. (siehe S. 37). [KWB12] U. Kruger, F. Wucholt und C. Beckstein. " Electronic Checklist Support for Disaster Response\. In: 9th Internat. Conference on Information Systems for Crisis Response and Management, Human Experiences in the Design of Crisis Response and Management Services and Systems. Vancouver, Canada, 2012 (siehe S. 3, 17, 45, 78). [Lan11] Laura Landro. " The Secret to Fighting Infections\. In: The Wall Street Journal (online) (2011). Dow Jones and Company, Inc. (siehe S. 35). [LI09] Vita Lanfranchi und Neil Ireson. " User requirements for a collective intelligence emergency response system\. In: Proceedings of the 23rd British HCI Group Annual Conference on People and Computers: Celebrating People and Technology. BCSHCI '09. Cambridge, UK: British Computer Society, 2009, S. 198{203 (siehe S. 44). [Lip09] Roland Lipp. Lehrbuch fur praklinische Notfallmedizin (LPN) Bd.4 Berufskunde und Einsatztaktik. Stumpf + Kossendey Verlagsgesellschaft mbH, 2009 (siehe S. 5). [LPK09] Christian Lindemann, Stephan Prodel und Rainer Koch. Modellierung von Prozessen in der Feuerwehrdomane zur Identi kation von Informationsbedarfen. Workshop: IT-Unterstutzung von Rettungskraften, Jenaer Schriften zur Mathematik und Informatik Math/Inf/03/09. 2009 (siehe S. 18, 20). [LSB13] Shuangyan Liu, Duncan Shaw und Christopher Brewster. " Ontologies for Crisis Management: A Review of State of the Art in Ontology Design and Usability\. In: Proceedings of the Information Systems for Crisis Response and Management conference (ISCRAM). 2013, S. 349{359 (siehe S. 98). [Lut03] Carsten Lutz. " Description Logics with Concrete Domains – A Survey\. In: Advances in Modal Logics Volume 4. King's College Publications, 2003 (siehe S. 84, 102). [Lud07] Sascha Rolf Luder. Recht und Praxis der nichtpolizeilichen Gefahrenabwehr. BWV Berliner-Wissenschaft (August 31, 2007), 2007 (siehe S. 9). LITERATUR 129 [MAB+99] Hnoz-Avila, David W. Aha, Len Breslow u. a. HICAP: An Interactive ector Mu~ Case-Based Planning Architecture and its Application to Noncombatant Evacuation Operations. 1999 (siehe S. 22, 23). [Man09] Tanja Manser. Komplexitat handhaben – Handeln vereinheitlichen – Organi " sationen sicher gestalten\. In: Human Factors. Hrsg. von Petra Badke-Schaub, Gesine Hofinger, u. a. Springer Berlin Heidelberg, 2009. Kap. 17, S. 273{288 (siehe S. 1, 30). [MBM+07] David Martin, Mark Burstein, Drew McDermott u. a. Bringing Semantics to " Web Services with OWL-S\. In: World Wide Web 10.3 (2007), S. 243{277 (siehe S. 98). [Min75] Marvin Minsky. A Framework for Representing Knowledge\. In: The Psychology " of Computer Vision. Hrsg. von P. Winston. McGraw-Hill, New York, 1975, S. 211– 277 (siehe S. 83). [Mit97] Steven W. Mitchell. A hybrid architecture for real-time mixed-initiative plan " ning and control\. In: Proceedings of the fourteenth national conference on arti cial intelligence and ninth conference on Innovative applications of arti cial intelligence. AAAI'97/IAAI'97. Providence, Rhode Island: AAAI Press, 1997, S. 1032– 1037 (siehe S. 22). [MSH09] Boris Motik, Rob Shearer und Ian Horrocks. Hypertableau Reasoning for De " scription Logics\. In: Journal of Arti cial Intelligence Research 36 (2009), S. 165– 228 (siehe S. 87). [NAI+03] D. S. Nau, T.-C. Au, O. Ilghami u. a. SHOP2: An HTN Planning System\. In: " Journal of Arti cial Intelligence Research 20 (2003), S. 379{404 (siehe S. 25). [NK95] Bernhard Nebel und Jana Koehler. Plan Reuse Versus Plan Generation: A ” Theoretical and Empirical Analysis\. In: Arti cial Intelligence 76.1-2 (1995), S. 427– 454 (siehe S. 68). [NKW08] Ulrich Natke, Tobias Kramer und Kirsten Wolff. STABOS@IG NRW – Ein " Meldewesen unterst utzt die Krisenstabsarbeit bei der nichtpolizeilichen Gefahren abwehr und der Polizei in Nordrhein-Westfalen\. In: 2 (2008). Schriftenreihe der Landesdatenverarbeitungszentrale (LDVZ) Nordrhein-Westfalen, S. 17{18 (siehe S. 16). [NM01] Natalya F. Noy und Deborah L. McGuinness. Ontology Development 101: A Guide to Creating Your First Ontology. Techn. Ber. Technical Report KSL-0105 and Stanford Medical Informatics Technical Report SMI-2001-0880. Stanford Knowledge Systems Laboratory, 2001 (siehe S. 83, 95, 97, 98). [NMAC+01] Dana Nau, Hector Munoz-Avila, Yue Cao u. a. Total-Order Planning with Par " tially Ordered Subtasks\. In: Seventeenth International Joint Conference on Arti cial Intelligence (IJCAI-2001), Seattle, August 2001. 2001 (siehe S. 69). [Nor88] Donald A. Norman. The Psychology Of Everyday Things. Basic Books, Juni 1988 (siehe S. 29). [OWL-API] W3C. OWL API: Java API for OWL Ontololies. W3C Member Submission. http: //www.w3.org/Submission/OWL-S (letzter Abruf: Aug. 2013). 2004 (siehe S. 120). [OWL-S] W3C. OWL-S: Semantic Markup for Web Services. W3C Member Submission. http://www.w3.org/Submission/OWL-S (abgerufen am 20.12.2013). 2004 (siehe S. 24). [OWL2] OWL 2 Web Ontology Language, W3C Recommendation 11 December 2012. W3C. http://www.w3.org/TR/owl2-overview/ (abgerufen am 20.12.2013) (siehe S. 84). LITERATUR [Par10] C. Park. The Case for Electronic Checklists in Hospitals. The Hospital Management. net. www.hospitalmanagement.net/features/ feature85551 (abgerufen am 20.12.2013). 2010 (siehe S. 39). [PD91] E. Palmer und A. Degani. Electronic checklists: Evaluation of two levels of auto ” mation.“ In: Proceedings of the Sixth International Aviation Psychology Symposium. Columbus, Ohio: The Ohio State University, 1991, pp. 178{183 (siehe S. 44). [PDV100] PDV100 – Polizeidienstvorschrift: Fuhrung und Einsatz der Polizei (VS-NfD). Verlag Deutsche Polizeiliteratur (VDP) GmbH. 1999 (siehe S. 7). [Pellet] Pellet: OWL 2 Reasoner for Java. Clark & Parsia, LLC. http:// clarkparsia. com/pellet (abgerufen am 20.12.2013) (siehe S. 85). [Pet62] Carl Adam Petri. Kommunikation mit Automaten\. ger. Diss. Universitat Ham- " burg, 1962 (siehe S. 18). [PM01] Hanno Peter und Klaus Maurer. Die Leitstelle beim MANV. Hrsg. von Hanno Peter und Klaus Maurer. Stumpf + Kossendey Verlagsgesellschaft mbH, 2001 (siehe S. 5, 6, 8, 58, 61). [PMU01] Hanno Peter, Thomas Mitschke und Theodor Uhr. Notarzt und Rettungsassistent beim MANV – SEGmente 3. Hrsg. von Klaus Maurer und Hanno Peter. Stumpf + Kossendey Verlagsgesellschaft mbH, 2001 (siehe S. 8, 13). [PR09] Gertraud Peinel und Thomas Rose. ur das Notfallmana-Prozessmodellierung f gement. Kurzbeitrutzung von Rettungskru age zum Workshop: IT-Unterstaften. L beck. Fraunhofer FIT, Schloss Birlinghoven. 2009 (siehe S. 18, 19, 28, 106). [Protege] Protege – a free, open source ontology editor and knowledgebase framework. Stanford Center for Biomedical Informatics Research. http:// protege.stanford.edu/ (abgerufen am 20.12.2013) (siehe S. 85). [PRW12a] G. Peinel, T. Rose und A. Wollert. The Myth of Business Process Modelling " for Emergency Management Planning\. In: 9th International Conference on Information Systems for Crisis Response and Management. Track Research Methods. Vancouver, Canada, 2012 (siehe S. 19, 44). [PRW12b] Gertraud Peinel, Thomas Rose und Alexander Wollert. Cross-Organizational " Preplanning in Emergency Management with IT-Supported Smart Checklists\. In: 7th Security Research Conference, September 4th -6th, 2012. 2012 (siehe S. 19, 21, 28, 41, 45, 78, 88). [Racer] Racer Systems GmbH & Co. KG. Renamed ABox and Concept Expression Reasoner. http:// www.racer-systems.com/ (abgerufen am 20.12.2013) (siehe S. 85). [Ras82] Jens Rasmussen. Human errors. A taxonomy for describing human malfunction in " industrial installations\. In: Journal of Occupational Accidents 4.2-4 (1982), S. 311– 333 (siehe S. 29). [Rea90] James T. Reason. Human Error. Cambridge University Press, 1990 (siehe S. 1, 29, 31, 107). [Rea94] James T. Reason. Menschliches Versagen: Psychologische Risikofaktoren und moderne Technologien. Spektrum Psychologie. Spektrum Akademischer Verlag, 1994 (siehe S. 1). [Rei07] Ralph Reinwarth. Standard Operating Procedures als Entscheidungsgrundla " ge in der Luftfahrt.“ In: Hrsg. von Stefan Strohschneider. Bd. 2. Menschen in kritischen Situationen – Schriftenreihe der Plattform Menschen in komplexen Arbeitswelten e. V. Verlag fPolizei-Wissenschaft, 2007. Kap. 2, S. 14{23 (siehe ur S. 43). [RG91] A. Rossett und J. Gautier-Downes. A handbook of job aids. Pfei er, 1991 (siehe S. 31). LITERATUR 131 [Ros04] Patrick Ross. Human Factors Issues of the Aircraft Checklist\. In: JAAER 13.2 ” (2004), S. 9{14 (siehe S. 37, 40). [RPA08] Thomas Rose, Gertraud Peinel und Emilija Arsenova. Process Management " Support for Emergency Management Procedures\. In: Proceedings of Collaboration and the Knowledge Economy: Issues, Applications, Case Studies. Pt.2 : eChallenges e-2008 Conference. Hrsg. von P. Cunningham. October. IOS Press, Amsterdam, NL, 2008, S. 1069{1076 (siehe S. 15, 18). [RS08] John Robillard und Roger Sambrook. USAF Emergency and Incident Management Systems: A Systematic Analysis of Functional Requirements. en. University of Colorado, Colorado Springs (UCCS). 2008 (siehe S. 44). [RW07] Uwe RImproving emergency management by uppel und Armin Wagenknecht. " formal dynamic process-modelling\. In: Proceedings of the 24th Conference on Information Technology in Construction (W78), Maribor, Slovenia. 2007, S. 559{564 (siehe S. 21). [Sac73] Earl D. Sacerdoti. Planning in a hierarchy of abstraction spaces\. In: Proceedings " of the 3rd international joint conference on Arti cial intelligence. Stanford, USA: Morgan Kaufmann Publishers Inc., 1973, S. 412{422 (siehe S. 21). [Sac75] Earl David Sacerdoti. A structure for plans and behavior.“ Diss. Stanford, CA, " USA, 1975 (siehe S. 64). [SB02] Bernd Schattenberg und Susanne Biundo. On the Identi cation and Use of ” Hierarchical Resources in Planning and Scheduling\. In: Proceedings of the 6th International Conference on AI Planning and Scheduling (AIPS'02). Hrsg. von Malik Ghallab, Joachim Hertzberg und Paolo Traverso. Toulouse, France: AAAI Press, Menlo Park, California, 2002, S. 263{272 (siehe S. 26). [SBB08] Bernd Schattenberg, Susanne Biundo und Julien Bidot. ut-Werkzeugunterst " zung f¨ anenmodelle\. In: Proceedings of the 22nd Workshop on ur konsistente Dom Planen, Scheduling und Kon gurieren, Entwerfen (PuK 2008). 2008 (siehe S. 27). [SBG+09] Bernd Schattenberg, Julien Bidot, Sascha Geler u. a. A Framework For ” Interactive Hybrid Planning\. In: KI 2008: Advances in Arti cial Intelligence, Proceedings of the 32nd Annual German Conference on AI. Hrsg. von B arbel Mert sching, Marcus Hund und Zaheer Aziz. Bd. 5803. Lecture Notes in Arti cial Intelligence. Paderborn, Germany: Springer, 2009, S. 17{24 (siehe S. 26). [SBI85] James G. Schmolze, Bolt Beranek und Newman Inc. An overview of the KL ” ONE knowledge representation system\. In: Cognitive Science 9 (1985), S. 171{216 (siehe S. 83). [SBQ+09] M. Soboll, B. Binder, C. Quix u. a. Vorgehensmodelle und Implementierungs " fragen – Akquisition – Lokalisierung – soziale Manahmen – Werkzeuge: 16. Workshop der Fachgruppe WI-VM der Gesellschaft f ur Informatik e. V. (GI)\. In: Hrsg. von Reinhard HShaker Verlag, 2009. Kap. Prozessmo ohn und Oliver Linssen. dellierung der mobilen Datenerfassung f¨ ur den Rettungsdienst bei einer Groschadenslage, S. 97{108 (siehe S. 10, 18). [Sch06] H. Schaub. adie der Psychologie C/II/8: Denken und Probleml Enzyklop¨ osen\. In: " Hrsg. von J. Funke (Hrsg.) G¨ orungen und Fehler ottingen: Hogrefe, 2006. Kap. St beim Denken und Probleml osen, S. 447{478 (siehe S. 1). [Sch07] JUberUMANV). Rheinische Projekt ¨ org Schmidt. Einsatzkonzept MANV ortlich ( ¨ gruppe "MANV Uberoln. Einsatzkonzept zur Bew ortlich", Kaltigung von Groschadenslagen mit 500 -1200 Patienten durch ortliche Unterst uberutzung, Zusammenarbeit mit der BF K oln. 2007 (siehe S. 19). [Sch08] Daniel Schlier. Fehlerquelle Mensch: Ein industrie ubergreifendes Problem: Human Factors und die "Dirty Dozenn luftfahrtfremden Arbeitsprozessen. Vdm Verlag Dr. M uller (April 2008), 2008 (siehe S. 26, 27). LITERATUR [Scr07] Michael Scriven. The Logic and Methodology of Checklists. Western Michigan University. http://www.wmich.edu/evalctr/archive checklists/papers/ logic&methodology dec07.pdf (abgerufen am 20.12.2013). 2007 (siehe S. 32). [Sim62] Herbert A. Simon. The architecture of complexity\. In: Proceedings of the Ameri " can Philosophical Society. Bd. 106. 6. American Philosophical Society, Philadelphia, 1962, S. 467{482 (siehe S. 1). [SMS10] S. Schumann, M. MDie machen ihren eigeahler und S. Strohschneider. ” nen Stiefel: Interorganisationale Zusammenarbeit von Beh orden und Organisationen mit Sicherheitsaufgaben\. In: Polizei & Wissenschaf 3 (2010), S. 41{49 (siehe S. 114). [SS04] Ste en Staab und Rudi Studer, Hrsg. Handbook on Ontologies. International Handbooks on Information Systems. Springer, 2004 (siehe S. 83). [Sta10] Susanne Starke. F uhrungskultur in High Risk Environments: Eine empirische Un tersuchung in den Arbeitsfeldern Polizei, Medizin, Business Continuity Manage ment. Verlag f ur Polizei-Wissenschaft, 2010 (siehe S. 115). [StadtVS06] Stadt Villingen-Schwenningen, B urgeramt, Feuerwehr und Katastrophenschutz. Standard-Einsatz-Regeln – Handlungsanweisungen f ur die Aus-, Fort bildung und den Einsatz. www.feuerwehr-vs.de/standard einsatz regeln ff vs.pdf (abgerufen am 20.12.2013). 2006 (siehe S. 52, 138). [Sus75] Gerald Jay Sussman. A Computer Model of Skill Acquisition\. Diss. MIT, 1975 " (siehe S. 69). [Tat00] Austin Tate. Intelligible AI Planning – Generating Plans Represented as a Set of " Constraints\. In: proceedings of ES2000, The Twentieth British Computer Society Special Group on Expert Systems International Conference on Knowledge Based Systems and Applied Arti cial Intelligence. Springer, 2000, S. 3{16 (siehe S. 23). [Tat76] Austin Tate. Project Planning Using a Hierarchic Non-linear Planner. Techn. Ber. Department of Arti cial Intelligence Research Report No 25, University of Edinburgh, Edinburgh, 1976 (siehe S. 21). [TDB+04] Austin Tate, Jeff Dalton, Je rey M. Bradshaw u. a. Coalition Search and Rescue – Task Support: Intelligent Task Achieving Agents on the Semantic Web. Techn. Ber. Arti cial Intelligence Applications Institute The University of Edinburgh & Florida Institute for Human & Machine Cognition (IHMC), 2004 (siehe S. 21, 23, 24). [TDD96] Austin Tate, Brian Drabble und Jeff Dalton. O-Plan: a Knowledge-Based Planner and its Application to Logistics. 1996 (siehe S. 23). [TDS02] A. Tate, J. Dalton und J. Stader. I-P2 – Intelligent Process Panels to Support " Coalition Operations\. In: Proceedings of the Second International Conference on Knowledge Systems for Coalition Operations (KSCO-2002), Toulouse, France, 2002 (siehe S. 109). [Ten88] Josh D. Tenenberg. Abstraction in planning\. Order No: GAX88-16885. Diss. " Rochester, NY, USA, 1988 (siehe S. 21). [ThurRettG] ThuRettG). Th uringer Rettungsdienstgesetz (Thuringer Staatsanzeiger Nr. 8. 2008 (siehe S. 6). [UBJ+03] A. Uszok, J. Bradshaw, R. Jeffers u. a. KAoS Policy and Domain Services: " Toward a Description-Logic Approach to Policy Representation, Decon iction, and Enforcement\. In: Proceedings of the 4th IEEE International Workshop on Policies for Distributed Systems and Networks. POLICY '03. Washington, DC, USA: IEEE Computer Society, 2003 (siehe S. 23). [UBJ+04] Andrzej Uszok, Je rey M. Bradshaw, Matthew Johnson u. a. KAoS Policy " Management for Semantic Web Services\. In: IEEE Intelligent Systems 19 (2004), S. 32{41 (siehe S. 23). LITERATUR 133 [UG96] Mike Uschold und Michael GrOntologies: Principles, Methods and uninger. " Applications\. In: Knowledge Engineering Review 11 (1996), S. 93{136 (siehe S. 97, 101). [Vol83] Walter Volpert. Das Modell der hierarchisch-sequentiellen Handlungsorganisati " on\. In: Kognitive und motivationale Aspekte der Handlung; hrsg. von W. Hacker, W. Volpert und M. von Cranach. Bern: Huber, 1983, S. 38{58 (siehe S. 68). [Wag06] U. Wagner. ur den Rettungsdienst\. In: Ret- Situation Awareness: Ein Konzept f " tungsdienst 29 (2006). Stumpf + Kossendey Verlag, S. 766{771 (siehe S. 111). [Wan06] Hai Wang. Frames and OWL side by side. The University of Manchester. Presentation to Protege, http : / / protege . stanford . edu / conference / 2006 / submissions/ slides/ 7.2wang protege2006.pdf (abgerufen am 20.12.2013). 2006 (siehe S. 96). [WD92] David Wilkins und Roberto V. Desimone. Applying an AI Planner to Military " Operations Planning\. In: Intelligent Scheduling. Morgan Kaufmann, 1992, S. 685– 709 (siehe S. 21). [Wei02] Robert Weihmann. Kriminalistik, ein Grundriss fur Studium und Praxis. 6. Auflage. Verlag deutsche Polizeiliteratur, 2002 (siehe S. 7). [Wic84] Christopher D. Wickens. Engineering psychology and human performance. Merrill, 1984 (siehe S. 37). [Wie94] G. Wiendieck. Arbeits-und Organisationspsychologie. Berlin, Munchen: Quintessenz, 1994 (siehe S. 67). [Wil10] Robert M. Williamson. Checklists: The Often Overlooked Tool\. In: (2010). ” Strategic Work Systems, Inc. Columbus, NC (siehe S. 35). [WKK11] F. Wucholt, U. Kr uger und S. Kern. Mobiles Checklisten-Support-System im Einsatzszenario einer Groschadenslag. Lecture Notes in Informatics, Band P192, Informatik 2011, Workshop IT-Unterstur Rettungskr utzung fafte, Berlin. 2011 (siehe S. 3, 12, 19, 45). [WM11] Alexander Wollert und Ganga Mannabeth. Plan Authoring Applications for Emergency Management. Workshop: IT-Unterstaften. 2011 utzung von Rettungskr (siehe S. 19). [WMY11] F. Wucholt, M. MFramework conditions ahler und Y. Yildirim-Krannig. ” and elds of application of an IT-Rescue Management Support System (IT-RMSS) for authorities and organizations with safety responsibilities (BOS) in mass casualty incident (MCI).“ In: Lecture Notes in Informatics (LNI)-Proceedings. Informatik 2011, Workshop IT-Unterstutzung fur Rettungskrafte, Berlin, 2011. 2011 (siehe S. 44, 48, 114). [WP10] Gerhard Wickler und Stephen Potter. Standard Operating Procedures: Col" laborative Development and Distributed Use\. In: 7th International Conference on Information Systemsfor Crisis Response and Management, Seattle, USA, 2010 (siehe S. 24). [WTP06] Gerhard Wickler, Austin Tate und Stephen Potter. Using the " Constraint Model as a Shared Representation of Intentions for Emergency Response\. In: Proceedings of the First International Workshop on Agent Technology for Disaster Management (ATDM), at the Fifth International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS 2006), Future. 2006, S. 8{12 (siehe S. 24, 28, 76). [WYM+11] F. Wucholt, Y. Yildirim-Krannig, M. Mahler u. a. Cultural Analysis and " Formal Standardised Language – a Mass Casualty Incident Perspectiv\. In: 8th International Conference on Information Systems for Crisis Response and Management. User Centred Design Process for Emergency Management Information Systems, Lisbon, Portugal, 2011 (siehe S. 3, 17, 73). LITERATUR [YM94] R. Michael Young und Johanna D. Moore. " DPOCL: A Principled Approach to Discourse Planning\. In: In Proceedings of the 7th International Workshop on Natural Language Generation. 1994, S. 13{20 (siehe S. 21). [YP+94] R. Michael Young, Martha E. Pollack, u. a. " Decomposition and Causality in Partial-Order Planning\. In: In 2nd Int. Conf. on AI Planning Systems: AIPS-94. 1994, S. 188{193 (siehe S. 21). [Fer99] M. Fernandez-L´ opez. " Overview of Methodologies for Building Ontologies\. In: Proc. Workshop on Ontologies and Problem-Solving Methods. 1999 (siehe S. 95). Photonachweise Abbildung 4.5: Rodger Johnson, Quelle: http://www.united-virtual.com/forum/viewtopic.php? f=36&t=15885, http://i225.photobucket.com/albums/dd159/rodgerjohnson/DSCF2186.jpg (abgerufen am 20.12.2013), 2008, (siehe S. 38). Abbildung 4.4: Kent Wien, 2009, Lizenz: CC BY-NC 2.0, Quelle: http://farm3.static. ickr.com/2046/ 2186148441 8452d1c610 b.jpg (abgerufen am 20.12.2013), (siehe S. 38). Abbildungsverzeichnis 2.1 MANV-Stufen versus Regelbetrieb (aus Sicht des Rettungsdienstes). . . . . . . 9 2.2 Reihenfolge des Eintre ens bestimmter Einsatzkr11 afte und Einsatzphasen. . . . . 2.3 Klassisches Modell des F13 uhrungsvorgangs (nach [FwDV100]). . . . . . . . . . . 2.4 GelehrterF. . . . . uhrungsvorgang aus Sicht der Feuerwehr (Quelle: [CP07]). 14 3.1 Zwei Ansur manuelle vs. automatische Handlungsplanung. . 17 atze: IT-Assistenz f 3.2 Anzeige der Task-Hierarchien im HICAP-Benutzerinterface. (Quelle: [MAB+99]) 23 3.3 Einzelne Komponenten des CoSAR-TS GUI. (Quelle: [TDB+04]) . . . . . . . . 24 3.4 Der sog. lifecycle von SIADEX in einem Waldbrandszenario. (Quelle: [FCG+06]) 25 3.5 Auszug einer Task-Hierarchie aus Sicht des THW. (Quelle: [BS01]) . . . . . . . 27 4.1 Grundlegende Strategien im Umgang mit Unsicherheit (Quelle: [Man09]). . . . . 30 4.2 Checklistenf................ ur unterschiedliche Situations-Klassen. 34 4.3 GradederSicherheitsanforderungen. ........................ 35 4.4 Teil einer MCL (Take-Off ) in einer Boeing 757................... 38 4.5 Elektronische Checkliste im Cockpit einer Boeing 777................ 38 4.6 Zusammenhang zwischen Leitlinien\, SOPs und Checklisten. . . . . . . . . . . 41 " 4.7 Arten der Korrespondenzen zwischen einer Checkliste und ihrer SOP. . . . . . . 41 5.1 Beispiel einer de nierten Rollenstruktur (aus [BOS-O]). . . . . . . . . . . . . . 50 5.2 Beispiel einer Konkretisierung eines abstrakten Items. . . . . . . . . . . . . . . 57 5.3 Schema einer Konkretisierung abstrakter Items. . . . . . . . . . . . . . . . . . . 58 5.4 Rollenbegrenzung in einer Checklistenhierarchie. . . . . . . . . . . . . . . . . . . 59 5.5 EntwicklungeinerCLHalsAND/OR-Graph. . . . . . . . . . . . . . . . . . . . 60 5.6 Grundprinzip der Angabe von alternativen Sub-Checklisten. . . . . . . . . . . . 61 5.7 Auspr62 agungeinerChecklistenhierarchie(1/2). . . . . . . . . . . . . . . . . . . . 5.8 Auspr63 agungeinerChecklistenhierarchie(2/2). . . . . . . . . . . . . . . . . . . . 5.9 DasPrinzipderTask-Dekomposition......................... 65 5.10 Beispielhafter Auszug einer HTN-Planungs-Dom66 ane als AND/OR-Graph. . . . 5.11 Beispiel einer hierarchischen Aufgabendekodierung nach Hacker [Hac97]. . . . 67 5.12 Die Zyklische Einheit nach Volpert 1982[FG97]. ................ 68 5.13 Das hierarchisch-sequenzielle Modell der Handlungsregulation [FG97]. . . . . . 69 135 ABBILDUNGSVERZEICHNIS 5.14 Zuordnung der Aufgaben/Tasks . uber die Beschreibungen zu den Checklisten. 70 5.15 Auszug eines MANV-Organisationsaufbaus. . . . . . . . . . . . . . . . . . . . . 71 5.16 Annotation des Konzeptes Bereitstellungsraum“ (siehe [BOS-O]). . . . . . . . . 72 " 5.17KulturanalyseundKnowledgeEngineering. . . . . . . . . . . . . . . . . . . . . 73 6.1 Meta-Architekturskizze der wichtigsten Casie-Komponenten. .......... 75 6.2 Architektur eines WfMS (nach Klausner [Kla01])................. 76 6.3 Maten. ......................... 78 ogliche Klassen von Endger 6.4 Eigene Studie eines m78 oglichenGUI(vgl.[KWB12]).. . . . . . . . . . . . . . . . 6.5 DieKomponentedesCL-Repository. ........................ 80 6.6 DieKomponentedesCL-Logbooks.......................... 81 6.7 Architektur eines Knowledge Base Systems (KBS) (nach Baader [BCM+03]). 82 6.8 OWL-Konstruktoren vs. DL (Quelle: [BHS08]). . . . . . . . . . . . . . . . . . . 85 6.9 OWL-Axiomevs.DL(Quelle:[BHS08]). ...................... 85 6.10 TBox-Auszug der BOS-De nitionen aus [BOS-O]. . . . . . . . . . . . . . . . . . 86 6.11 Beispiel eines Reasoningergebnisses (Protege). . . . . . . . . . . . . . . . . . . . 87 6.12 Explanation Schlussfolgerungsergebnis (Protege). . . . . . . . . . . . . . . . . . 87 6.13 Diagramm der moglichen Zustandsuberg. . . . . . . . . . . . . ange einer ICL. 88 6.14 Diagramm der Zustandsange eines Items. 89 uberg.................. 6.15Singel-User-vs.Multi-User-Modus. ......................... 91 6.16 Aktivit92 atsdiagramm des reaktiven Systemverhaltens von Casie.......... 6.17 Schritte der Ontologieentwicklung nach McGuinness etal.[NM01]. . . . . . . 95 6.18 Das GUI von Protege (4.*) mit geladener BOS-Ontologie [BOS-O]. . . . . . . . 96 6.19 Beispielhafter Ausschnitt aus der BOS-Ontologie [BOS-O]. . . . . . . . . . . . . 100 6.20 Auszug einer Rollende nition der BOS-Ontologie in Protege. .......... 101 6.21VonSOPszuChecklistenundzuruck. ....................... 103 6.22BeispielschemaeinesProzessskeletts. . . . . . . . . . . . . . . . . . . . . . . . . 106 7.1 SchemadesProzessmonitorings. ........................... 109 7.2 a) F111 uhrungsvorgang vs. b) Situation Awareness im Entscheidungsprozess. . . . Anhang Please note: A checklist is NOT a teaching tool or an algorithm ACHECKLI STFORCHECAA C H E C K L I S T F O R C H E C KLISTTTTK L I S TSS DevelopmentD e v e l o p m e n t ..Do you have clear, concise objectives for your checklist? Is each item: ..A critical safety step and in great danger of being missed? ..Not adequately checked by other mechanisms? ..Actionable, with a specific response required for each item? ..Designed to be read aloud as a verbal check? ..One that can be affected by the use of a checklist? Have you considered: ..Adding items that will improve communication among team members? ..Involving all members of the team in the checklist creation process? DraftingD r a f t i n g l i iDoes the Checklist: ..Utilize natural breaks in workflow (pause points)? ..Use simple sentence structure and basic language? ..Have a title that reflects its objectives? ..Have a simple, uncluttered, and logical format? ..Fit on one page? ..Minimize the use of color? Is the font: ..Sans serif? ..Upper and lower case text? ..Large enough to be read easily? ..Dark on a light background? ..Are there fewer than 10 items per pause point? ..Is the date of creation (or revision) clearly marked? VadatonV a l i d a t i o n Have you: ..Trialed the checklist with front line users (either in a real or simulated situation)? ..Modified the checklist in response to repeated trials? Does the checklist: ..Fit the flow of work? ..Detect errors at a time when they can still be corrected? ..Can the checklist be completed in a reasonably brief period of time? ..Have you made plans for future review and revision of the checklist? Checkliste f¨ ur eine Checkliste. Quelle: www.projectcheck.org/checklist-for-checklists.html (abgerufen am 20.12.2013) 137 138 ABBILDUNGSVERZEICHNIS ChclseuerzVreeernedalgn,Qee[tdS6. ekitf¨rdnPoes ssoghnbiBadmlenae“ul ll:SatV0] ” ABBILDUNGSVERZEICHNIS 139 Boig7740NrmlCekit en4-0oahcls Pre-Flight ParkingBrake…………………………………………………. .....On Bat tterySwitch…………………………………………. ..………. ..On StandbyPower…………….…………………………………. ..Auto EECSwitches…………….…….…….………. ..……………. ...Norm BusTieSwitches……………………………. ..……………….Auto GENCONTSwitches…………………………………. ...PushedIn HydraulicDemandPumps…. ..………………….……………. ...Of ff EngineHydraulicPumps………. ..……………. ...…. ..………….On ExternalPower………………………. ..……….………….……. ..On TurnOnExternalPower#1|TurnOnExternalPower#2IfAvailable UtilityBusSwitches(L&R)…………………….……………….On NAVLight…………………………………. ..……………. ...……. ...On EmergencyLightSwitch………………………….………….ARM AlternateFlapSelector………………. ...……………………….Of ff FlapLever/PositionIndicator………. ..……………. ..Up/Agree LandingGear………………………………………. ..………. ..Down IRSModeSelectors……………….…………………………. ..NAV FMCInitialization…………………. ...………. ..……EnterPosition FuelCrossfeeds…………. ...…………………………………….On FuelPumps…………………….…………………. ...…………….Of ff Nacel lleAnti-Ice…………………………………………….…….Of ff WingAnti-Ice……………………………………………….…….Of ff ExteriorLights………………………………….…….AsRequired NAVLightsAndLogoLightsOn|Al llOtherLightsShouldBeOf ff WindowHeat…………………………………………. ...………. ...On WindshieldWiperSwitches……………………………. ..…….Of ff PassengerOxygenSwitch………………………………….Norm YawDamperSwitches…………………………………. ..……. ...On APUBleedSwitch…………………………………………. ..…. ..Of ff APU……………………………………………………. ..………. ..Start WhenAPUAVAILlightsIl lluminate-PressAPUGeneratorSwitches(1&2) OutflowValves……………. ..………………………. ..………. ..Open LandingAltitudeSwitch………………………………….…. ..Auto OutflowValveManualSwitches……………………………. ....Of ff CainAttduoSlcoo bliueAteetr……………………………. ....Nrm PassengerTemp……………………………………………. ....Auto FlightDeckTemp……………………………. ..……………. ....Auto TrimAirSwitch…………………………………………………. ..On RecircFanSwitches(UPR&LWR)…………………………. ..On AFTCargoHeatSwitch………………………………………. ...Of ff EquipmentCoolingSelector……………………………. .....Norm IfOATIsLessThan70*SetToNORM|IfOATIsAbove70*SetToOVRD Hglic.………Of ff ihFowSwth………………………………………. GasperSwitch…………………………………………………. ...On PackSwitches(1-2-3)………………. ..…………………. ..…. ..Norm ISLNSwitches………………………………………….……. ..Open APUBleedSwitch…………………………………………. ...…. ..On Al llowAPUToOperateOneMinuteBeforeActivatingAPUBleedSwitch EngineBleedSwitches………………………………………. ....On FMC……………………………………………………. ...….Program ModeControlPanel(MCP)…………………………………. .....Set FlgtDrcoic.………………O ihietrSwth………………………….n AutoThrot ttle…………………………………………….……….Of ff IAS/MACH…………………………………….………. ...…….V2+10 LNAV/VNAV…………………………………………………. ......Arm HDG…………………………………………………….………….Set EnterRunwayHeading ALT……………………………………………………. ..………….Set EnterYourClearedAltitude AutoPilotDisengageBar…………………………. ...………….Up Altimeter…………………………………………………………. ..Set LowerCRTSelector………………………………………….Norm InboardCRTSelector……………………………….……….Norm Trim…………………………………………………………….….Set SpeedBrake………………………. ...………………………. ..Down Throt ttles………………………………………………………….Idle ReverseThrustLevers………………………………. ..…….Down FuelControlSwitches……………………………….……. ..Cutof ff StabTrim……………………………………………Auto/Guarded CommunicationsPanel………………………………………. ...Set AudioPanel……………………………………………….……. ...Set AutoBrakeSelector………………………………………. ..….RTO PassengerSigns……………………………………. ..………. ..Auto FlightDeckDoor…………………………………………. ...Locked Aileron/RudderTrim…………………………. ..…………….Set0 TCAS/ATC……………………………………………. ..……Test/Set SetTCASToTheFol llowing AboveDuringTakeof ff|NDuringCruise|BelowDuringDescent GroundProximityLight……………………………Extinguished GrudPoimtlpOer rrdic. ...………….Of ff onrxiyFavieSwth….…… GroundProximityConfig/GearOver rrideSwitch…………. ..Of ff GroundProximityTer rrainOver rrideSwitch………….……. ..Of ff AlternateFlapsSelector………………………………….…….Of ff AlternateFlapsArmSwitch…………………………….……. ..Of ff AlternateGearExtendSwitches……………………………. ...Of ff FuelPumps……………………………………………………….On OnlyTurnOnFuelPumpsfortanksthatcontainfuel FuelCrossfeeds……. ...………………………………………….Set IfFuelTankQuantityInTank#2IsMoreThan#1And#3IsMoreThan#4 TurnAl llFuelCrossfeedsOn IfFuelTankQuantityInTank#2IsLess/EqualTo#1And#3IsLess/EqualTo#4 TurnCrossfeeds1&4of ff|TurnOver rridePumps2&3Of ffAircraftDoors……. ...…. ..……………………………………Closed ConfirmAl llDoorsSecurePriorToPushback Pushback HydraulicDemandPumps……. ...…. ..……………….…Auto/Aux SetHydraulicDemandPumpSelectors#1-#2-#3ToAuto SetHydraulicDemandPumpSelector#4toAux RedAnti-Col llisionLights(Beacon)……………………. ..…. ...On PackSwitches……………………………………………Norm/Of ffLeavePackSwitch#1OnNorm-TurnPackSwitches#2And#3Of ffEICAS(Recal llBut tton)……………….……………………….Push ConfirmOnlyAppropriateAlertMessagesDisplayedOnEICAS EICAS(CancelBut tton)…………….……………. ..………….Push MaulEgntr nanieSat AutostartSelector…….……….……………. ..…………. ...…….Of ff ContinuousIgnition…………………………………. ...………. ...On —————————————————————————————————————— EngineStartSelector#4……………………………….……. ...Pul ll FuelControlSwitch#4……………………………. ...………. ...Run WhenN2ReachesMagentaStartLine-Set#4FuelControlSelectorToRun EICASEngineIndicator…………………………………. ..Monitor VeiyEgntrt52#utreetrl lliainEtnuse rfnieSatA0%N-4Pl llSatSlcoIumntoxigihd —————————————————————————————————————— EngineStartSelector#1……………………………….……. ...Pul ll FuelControlSwitch#1……………………………. ...………. ...Run WhenN2ReachesMagentaStartLine-Set#1FuelControlSelectorToRun EICASEngineIndicator…………………………………. ..Monitor VeiyEgntrt52#utreetrl lliainEtnuse rfnieSatA0%N-1Pl llSatSlcoIumntoxigihd —————————————————————————————————————— EngineStartSelector#3……………………………….……. ...Pul ll FuelControlSwitch#3……………………………. ...………. ...Run WhenN2ReachesMagentaStartLine-Set#3FuelControlSelectorToRun EICASEngineIndicator…………………………………. ..Monitor VerifyEngineStartAt50%N2-#3Pul llStartSelectorIl lluminationExtinguished —————————————————————————————————————— EngineStartSelector#2……………………………….……. ...Pul ll FuelControlSwitch#2……………………………. ...………. ...Run WhenN2ReachesMagentaStartLine-Set#2FuelControlSelectorToRun EICASEngineIndicator…………………………………. ..Monitor VeiyEgntrt52#utreetrl lliainEtnuse rfnieSatA0%N-2Pl llSatSlcoIumntoxigihd AfterEngineStart APU…………………………………………………………. ..…….Of ffHydraulicDemandPump#4……. ...…. ..……….………….…Auto Nacel lle/WingAnti-Ice……………………. ..……….AsRequired UseIfTemperatureIsBelow10DegreesCelsius&VisibleMoistureIsObserved AFTCargoHeat………………………………. ..………………. ...On IsolationSwitches…………………. ...……………………. .....Open PackSwitches……………. ...………………………………….Auto DoNotEngagePacksUntilTheEnginesHaveStabilizedAtIdleFor2Minutes EICASCaution-Advisory-StatusMessages…. ..Check/Cor rrect EnsureAl llCautionaryMessagesHaveBeenAddressedPriorToTakeof ffGroundEquipment……………………………. ..…….Disconnect Taxi Flaps……………………………………. ...……………………. .....Set FlightControls……………………………………. ..………. ...Check Takeof ffPerformance…………………………. ...Confirm/Update CabinCrewNotification…………………. .....………Accomplish RunwayTurnof ffLights/TaxiLights……………. ...………….On Boig7740Cekitf¨roaeoki-rzdrnul ll:ht tt:/wwwsr.om ens4-0hclseunrml“CcptPoeue.Qeep/.cibdc/ ” do/11308oig7740Chclsagrfnam2.221) c1641/Ben-4-0-ekit(beue01.03 ABBILDUNGSVERZEICHNIS WHO surgical safety checklist and implementation manual. SURGICAL SAFETY CHECKLIST (FIRST EDITION) Before induction of anaesthesia Before skin incision Before patient leaves operating room SIGN IN TIME OUT SIGN OUT PATIENT HAS CONFIRMED CONFIRM ALL TEAM MEMBERS HAVENURSE VERBALLY CONFIRMS WITH THE • IDENTITY INTRODUCED THEMSELVES BY NAME ANDTEAM: • SITE ROLE • PROCEDURE THE NAME OF THE PROCEDURE RECORDED • CONSENT SURGEON, ANAESTHESIA PROFESSIONALAND NURSE VERBALLY CONFIRM THAT INSTRUMENT, SPONGE AND NEEDLESITE MARKED/NOT APPLICABLE• PATIENTCOUNTS ARE CORRECT (OR NOT SITE• APPLICABLE) ANAESTHESIA SAFETY CHECK COMPLETED• PROCEDURE HOW THE SPECIMEN IS LABELLEDPULSE OXIMETER ON PATIENT AND FUNCTIONINGANTICIPATED CRITICAL EVENTS(INCLUDING PATIENT NAME) DOES PATIENT HAVE A: SURGEON REVIEWS: WHAT ARE THE WHETHER THERE ARE ANY EQUIPMENT CRITICAL OR UNEXPECTED STEPS,PROBLEMS TO BE ADDRESSEDKNOWN ALLERGY?OPERATIVE DURATION, ANTICIPATEDNOBLOOD LOSS? SURGEON, ANAESTHESIA PROFESSIONAL YES AND NURSE REVIEW THE KEY CONCERNS ANAESTHESIA TEAM REVIEWS: ARE THEREFOR RECOVERY AND MANAGEMENT DIFFICULT AIRWAY/ASPIRATION RISK?ANY PATIENT-SPECIFIC CONCERNS?OF THIS PATIENT NOYES, AND EQUIPMENT/ASSISTANCE AVAILABLE NURSING TEAM REVIEWS: HAS STERILITY (INCLUDING INDICATOR RESULTS) BEENRISK OF >500ML BLOOD LOSS CONFIRMED? ARE THERE EQUIPMENT(7ML/KG IN CHILDREN)?ISSUES OR ANY CONCERNS? NOYES, AND ADEQUATE INTRAVENOUS ACCESS HAS ANTIBIOTIC PROPHYLAXIS BEEN GIVENAND FLUIDS PLANNED WITHIN THE LAST 60 MINUTES? YESNOT APPLICABLE IS ESSENTIAL IMAGING DISPLAYED? YESNOT APPLICABLE THIS CHECKLIST IS NOT INTENDED TO BE COMPREHENSIVE. ADDITIONS AND MODIFICATIONS TO FIT LOCAL PRACTICE ARE ENCOURAGED. ABBILDUNGSVERZEICHNIS Einsatzstichworte für BrandeinsätzeAlarmdurchsage ErstalarmierungEinsatzstichwort Meldebild Einsatztaktische Parameter Zusätzliche Einsatzmittelnach Lage F GAS 1 Brand -einzelner Gasflaschen-einer Gasleitung wie F 2+ Löschpulver + Wärmeschutzbekleidung + Ex-Warngerät + P 250 (FwA) +RW F GAS 2 Brand-eines Gastanks-eines Gastankfahrzeugs -eines Gaskesselwagens wie F 3+ Löschpulver+ Wärmeschutzbekleidung + Ex-WarngerätRettungsdienst-Stichwort: R 2 + P 250 (FwA) +RW F LKW Brand-eines LKW wie F 2, aber 5.000 Liter Wasser+ 120 Liter Schaummittel + weitere Tanklöschfahrzeugebei Gefahrgut: + wie H Gefahr 2 F SCHIFF 1 Brand-eines Sportboots-einer Yacht-eines Segelboots wie F 2+ 2 RTB / MZB + TauchergruppeRettungsdienst-Stichwort: R 1 + weitere RTB / MZB+ Gerätewagen-Gefahrgut, Ölsperre+ GW-Wasserrettung Beispielauszug aus einer Einsatzstichwortliste. Quelle: http://www.ffsemd.de (abgerufen am 20.12.2013) Ehrenwarung ortliche Erkl Hiermit erklare ich, • dass mir die geltende Promotionsordnung der Fakultur Mathematik und Informaat f¨ tik der Friedrich-Schiller-Universit¨ at Jena bekannt ist, • dass ich die Dissertation selbst angefertigt habe, keine Textabschnitte oder Ergebnisse eines Dritten oder eigener Prufungsarbeiten ohne Kennzeichnung  ubernommen und alle von mir benutzten Hilfsmittel, pers onliche Mitteilungen und Quellen in meiner Arbeit angegeben habe, • dass die Hilfe eines Promotionsberaters nicht in Anspruch genommen wurde und dass Dritte weder unmittelbar noch mittelbar geldwerte Leistungen von mir f ur Arbeiten erhalten haben, die im Zusammenhang mit dem Inhalt der vorgelegten Dissertation stehen, • dass ich die Dissertation noch nicht als Prur eine staatliche oder andere ufungsarbeit f¨ wissenschaftliche Pr¨ ufung eingereicht habe, und • dass ich die gleiche, eine in wesentlichen Teilen  ahnliche oder eine andere Abhandlung nicht bei einer anderen Hochschule als Dissertation eingereicht habe. Jena, den 21.12.2013 ABBILDUNGSVERZEICHNIS Ver o entlichungen U. Kr uger und F. Wucholt: Fehlervermeidung durch Checklisten-Assistenz in Groschadensereignissen – Potenzial und Vorteile elektronischer Checklisten, Buchreihe, In: Plattform e.V. 2012/2013. Entscheiden in kritischen Situationen: Neue Perspektiven und Erkenntnisse. Herausgeber: Rudi Heimann, Stefan Strohschneider und Harald Schaub, Plattform Menschen in komplexen Arbeitswelten e. V., Verlag f ur Polizeiwissenschaft, Frankfurt, 2013. U. Kr uger, F. Wucholt and C. Beckstein: Electronic Checklist Support for Disaster Response, In: Proceedings of the 9th International Conference on Information Systems for Crisis Response and Management, Human Experiences in the Design of Crisis Response and Management Services and Systems, Vancouver, Canada, April 2012. F. Wucholt, U. Kr uger und S. Kern: Mobiles Checklisten-Support-System im Einsatzszenario einer Groschadenslage, Informatik 2011, Workshop IT-Unterstur Ret utzung f tungskr afte, Berlin, Oktober 2011. F. Wucholt, Y. Yildirim-Krannig, M. Mahler, U. Kr uger, and C. Beckstein: Cultural Analysis and Formal Standardised Language — a Mass Casualty Incident Perspectiv, In: Proceedings of the 8th International Conference on Information Systems for Crisis Response and Management (ISCRAM), User Centred Design Process for Emergency Management Information Systems, Lisbon, Portugal, May 2011. U. Kr uger, A. Gabdulkhakova, V. Schau, and C. Beckstein: Information and Management Support for Mass Casualty Incident Scenarios, 2. Workshop IT-Unterst utzung fafte im Rahmen der INFORMATIK 2010, Leipzig, September 2010. ur Rettungskr U. Kronig-Ries, and C. Beckstein: Semantic Seruger, A. Gabdulkhakova, B. K vice Infrastructure for Intelligent Checklist Support Systems, In: Proceeding of the 2010 international Conference on Towards a service-based internet, International Workshop on Emergency Management through Service Oriented Architectures, ServiceWave'10, Ghent, December 2010. H. Sack, U. Kr uger, and M. Dom: A Knowledge Base on NP-complete Decision Problems and its Application in Bibliographic Search, In: Proceedings of Berliner XML-Tage 2006, Berlin, September 2006. 143