Verteilte Fuhrungsinformationssysteme (German Edition)

Verteilte Führungsinformationssysteme

Michael Wunder  Jürgen Grosche (Hrsg.)

Verteilte Führungsinformationssysteme

123

Herausgeber: Dr.-Ing. Michael Wunder FGAN – Forschungsinstitut für Kommunikation, Informationsverarbeitung und Ergonomie (FKIE) Wachtberg Neuenahrer Str. 20 53343 Wachtberg Deutschland Prof. Dr. Jürgen Grosche FGAN – Forschungsinstitut für Kommunikation, Informationsverarbeitung und Ergonomie (FKIE) Wachtberg Neuenahrer Str. 20 53343 Wachtberg Deutschland

ISBN 978-3-642-00508-4 e-ISBN 978-3-642-00509-1 DOI 10.1007/978-3-642-00509-1 Springer Dordrecht Heidelberg London New York Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © Springer-Verlag Berlin Heidelberg 2009 Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Satz und Herstellung: le-tex publishing services GmbH, Leipzig Einbandentwurf: WMXDesign GmbH, Heidelberg Gedruckt auf säurefreiem Papier Springer ist Teil der Fachverlagsgruppe Springer Science+Business Media (www.springer.de)

Alle aufeinander folgenden Akte eines Krieges sind sonach nicht prämeditierte Ausführungen, sondern spontane Akte, geleitet durch militärischen Takt. Es kommt darauf an in lauter Spezialfällen die in den Nebel der Ungewissheit gehüllte Sachlage zu durchschauen, das Gegebene richtig zu würdigen, das Unbekannte zu erraten, einen Entschluß schnell zu fassen und dann kräftig und unbeirrt durchzuführen. Helmut von Moltke1

1

Von Moltke, H., „Über Strategie“. In Stumpf, R. (Hrsg.), Kriegstheorie und Kriegsgeschichte (= Bibliothek der Geschichte und Politik, Band 23). Frankfurt am Main: Deutscher Klassiker Verlag, 1993, S. 430.

Vorwort

Die Qualität einer Führungsentscheidung ist abhängig von der Güte der Informationsbasis, auf der diese Entscheidung beruht. Somit ist der Zugriff auf die entscheidungsrelevanten Informationen ein Schlüsselelement im Führungsprozess. Hängen von der Entscheidung und deren Umsetzung Menschenleben ab, wird die Bedeutung der zeitgerechten und möglichst vollständigen Versorgung mit Information besonders deutlich. Es ist daher selbstverständlich, dass man sich im militärischen Bereich mit der Aufgabe der Beschaffung, Verteilung und Aufbereitung von Informationen in besonders intensiver Weise auseinandersetzt. Dabei spielten schon immer die technischen Voraussetzungen zur Lösung dieser Aufgabe eine dominierende Rolle. Dank der Entwicklung moderner Informations- und Kommunikationstechniken stehen heute Hilfsmittel zur Verfügung, deren Nutzung die Qualität der Führungsentscheidung entscheidend verbessern kann. Die Untersuchungen zum Einsatz dieser Technologien begannen in unserem Institut schon in den frühen 60er Jahren und fokussierten sich zunächst auf die Integration von Informationen aus der Luftraumüberwachung (Digitalisierung der Radardaten) und der europaweiten Flugplanung (Vernetzung der Kontrollzentren an den Flughäfen). Erste innovative Ansätze für Aufgabenstellungen in der Bundeswehr führten im Jahre 1965 zur Einrichtung einer eigenen Abteilung Rechner und Führungssysteme. Deren Aufgabenstellung bestand darin, eine optimale Architektur und Verfahrensgestaltung für Führungsinformationssysteme zu finden. An dieser Aufgabe hat sich vom Grundsatz her nichts geändert, allerdings haben sich Schwierigkeitsgrad und Komplexität deutlich erhöht. Die Herausforderung besteht darin, auf die sich permanent und mit hoher Dynamik verändernden Randbedingungen adäquat zu reagieren und den bestmöglichen Nutzen aus den verfügbaren Technologien zu ziehen. Informationsdominanz wird heute als eine wesentliche Voraussetzung für den Erfolg einer Operation angesehen. Insofern hat auch hier eine technische Neuerung wie schon häufig in der Vergangenheit nicht nur zu einer Verbesserung eingeführter Systeme geführt, sondern eine andere Denkweise ausgelöst und eine neue Dimension in der Bewältigung von Konflikten eröffnet. Simultane Abläufe im militärischen Entscheidungszyklus (Beobachten, Orientieren, Entscheiden, Handeln) führen zu immer kürzeren Durchlaufzeiten – „near

vii

viii

Vorwort

real-time“ heißt das Ziel. Gleichzeitig wächst das Informationsangebot dramatisch, wobei die Informationen aufgrund der Verbesserung von Sensoren und anderen Quellen immer aktueller und feiner werden. Dies erschwert aber deren Wahrnehmung im Entscheidungszyklus, da aus dem gesamten Informationsangebot für eine bestimmte Entscheidung nur eine Auswahl relevanter Informationen benötigt wird. Diese gilt es zu identifizieren und dem Entscheider situationsangepasst zum richtigen Zeitpunkt und in geeignet aufbereiteter Form zu präsentieren. Unverzichtbare Grundlage für Situational Awareness ist damit die Beherrschung des sogenannten globalen Informationsraumes, der die Gesamtheit aller verfügbaren Informationen und Zusammenhänge darstellt. Es kommt daher darauf an, eine für den Nutzer optimale Sicht auf diesen Raum anzubieten, d.h. ein umfassendes, ebenenübergreifendes, rollengerechtes und für alle Beteiligten konsistentes Lagebild zu erzeugen. Nur so können Entscheider Handlungsalternativen erwägen und Maßnahmen ergreifen, die – auf der Faktenlage basierend – zielführend und nachvollziehbar sind. Im industriellen Bereich versucht man, die Informationsflut mit Hilfe von Managementinformationssystemen (MIS) und Data Warehouse Systemen (DWS) in den Griff zu bekommen. Im militärischen Bereich heißt die Lösung Führungsinformationssystem (FüInfoSys). Während bei MIS bzw. DWS der Wettbewerbsvorteil gegenüber der Konkurrenz im Vordergrund steht, ist es bei FüInfoSys die Informationsüberlegenheit gegenüber dem Gegner. Die Terminologie beider Bereiche ist aber vielfach ähnlich bis identisch. Trotz unterschiedlicher Schwerpunktsetzung auf den höheren militärischen Entscheidungsebenen im Vergleich zu unternehmerischen Entscheidungen – z. B. bei Produktplanung und -entwicklung – gibt es viele wichtige Gemeinsamkeiten. In beiden Fällen handelt es sich um komplexe, dynamische und zum Teil „schwach strukturierte“ Führungsprozesse, die unter hohem Zeitdruck bei einem hohen Risiko für Fehlentscheidungen durch kooperierende Akteure ausgeführt werden. Eine Besonderheit stellt die taktische Ebene des militärischen Bereiches mit ihren sehr spezifischen Randbedingungen und technischen Restriktionen dar, die zusätzliche, sehr spezielle Anforderungen an die FüInfoSys stellen. Da es im zivilen Umfeld nichts Vergleichbares gibt, sind von dort keine Erfahrungen und Lösungen übertragbar und somit spezielle militärische Entwicklungen notwendig. Ein weiteres Unterscheidungsmerkmal ist die Relevanz der Interoperabilität bei der Koppelung heterogener Systeme. Interoperabilität ist eine unverzichtbare Forderung, wenn der Erfolg bei der Auftragserfüllung nur bei reibungslosem Zusammenwirken verschiedener, eher autark aufgestellter Bereiche weitgehend unabhängiger Organisationen gewährleistet ist. Im militärischen Bereich wird dies mit den Begriffen „joint“ und „combined“ beschrieben. Unter aktuellen Einsatzrandbedingungen heißt das: Mehrere Nationen, organisiert in verschiedenen Allianzen, stellen militärische Kräfte verschiedener Truppengattungen mit ihren jeweiligen Ausrüstungen in dynamisch veränderbaren Konstellationen bereit. Erwartet wird ein geordnetes, aufgabenangepasstes und erfolgreiches Vorgehen aller Beteiligten, basierend auf einem optimalen Informationsfluss. Um die Bedeutung dieser Aufgabenstellung herauszustellen, werden seit einigen Jahren Begriffe wie Network Centric Warfare (NCW), Network Enabled Capabilities (NEC) oder Vernetzte Operationsführung (NetOp-

Vorwort

ix

Fü) verwendet. Dabei wird der oben genannte technologische Trend adressiert, der auch in der Vergangenheit die Dynamik in der Verbesserung von FüInfoSys wesentlich bestimmt hat und nunmehr im Mittelpunkt der technischen und operationellen Überlegungen steht. Nicht zuletzt diese Entwicklung hat uns ermutigt, mit diesem Buch eine Bestandsaufnahme zu versuchen. In der Einführung werden die Bedeutung und der Realisierungsgang von Führungsinformationssystemen aus ministerieller Sicht erläutert sowie im Rückblick die oben genannten Anfänge der wissenschaftlichen Arbeiten und ihre Entwicklung aus der Perspektive unseres Institutes beschrieben. Im ersten Teil werden konzeptionelle Grundlagen zur Interoperabilität, zur Systemarchitektur, zum Informationsmanagement sowie zur Verteilung, Filterung und Darstellung von Informationen beschrieben. Dabei werden auch die besonderen technischen und operativen Herausforderungen auf den unteren militärischen Führungsebenen herausgearbeitet. Der zweite Teil ist speziellen Assistenzsystemen gewidmet, mit denen im Rahmen der Führungsunterstützung dem Nutzer wesentliche Hilfsmittel bei Informationsgewinnung, Auswertung und Informationsfusion zur Verfügung gestellt werden. Im dritten Teil werden die zur Herstellung von Interoperabilität wichtigsten militärischen Standards geschildert und eine Reihe von Schlüsselprojekten beschrieben, die beispielhaft das breite Spektrum der Probleme und Lösungen im Bereich moderner FüInfoSys beleuchten. Schließlich stellt sich die Frage nach zukünftigen Entwicklungen – nicht im Sinne von Einzelthemen, zu denen werden in den Beiträgen der Autoren viele Hinweise gegeben, sondern im Hinblick darauf, wie die großen Linien, die bestimmenden Trends aussehen, die als Herausforderungen bei der Gestaltung von Führungssystemen zukünftig zu bewältigen sein werden. In der Informatik sind in den derzeitigen Trendanalysen Schlagworte wie SOA, Web 2.0, semantic web, ubiquitous computing, mobile ad-hoc-Netze, HIP, next generation internet, virtuelle Welten usw. zu finden – je nach fachlicher Ausprägung der Autoren mit unterschiedlicher Bewertung. Im Fähigkeitsspektrum der Bundeswehr spielen die Begriffe Autonomie und Mobilität eine besondere Rolle. Dabei wird unter Autonomie natürlich nicht der Kampfroboter aus der Science-Fiction-Welt verstanden. Es werden realistische Zielsetzungen verfolgt, wie z. B. die Erhöhung des Autonomiegrades bei unbemannten Systemen. In allen Entscheidungsprozessen spielt aber nach wie vor der Mensch die zentrale Rolle. Das muss im Führungssystem entsprechende Berücksichtigung finden mit Auswirkungen auf die Funktionsaufteilung Mensch und Maschine, auf die Gestaltung der Schnittstellen, auf das Informationsmanagement und auf die inneren Abläufe und Verfahren. Mobilität hat Konsequenzen für die Kommunikationsstruktur aufgrund der Forderung nach Erreichbarkeit (auch in der Bewegung), nach Verfügbarkeit, nach Robustheit und nach Flexibilität. Für ein Führungsinformationssystem bedeutet dies, auf die situationsabhängige Qualität der Informationsübertragung zu reagieren. Anzubieten ist also eine situationsadaptive Entscheidungsunterstützung mit allen damit verbundenen Konsequenzen. Lernende Systeme, intelligente Agenten oder auch wissensbasierte Informationsfusion sind Themenbereiche, die Lösungsmöglichkeiten bieten und uns sicher in Zukunft weiter beschäftigen werden.

x

Vorwort

Natürlich ist diese kurze Betrachtung der technischen Aspekte zukünftiger Entwicklungen unvollständig und eher am Ist orientiert. Abhandlungen über Trends in der Informationstechnik gibt es zwar bereits in großer Zahl, leider mangelte es in der Vergangenheit häufig an der Prognosegenauigkeit. Wir halten uns deshalb bewusst zurück, zumal jeder von uns die dramatische Durchdringung unseres Alltags mit Informations- und Kommunikationstechnik registriert und jedem klar ist, dass ein Ende dieser Entwicklung nicht in Sicht ist – mit entsprechenden Konsequenzen auf die Gestaltung von Informationssystemen. Wir möchten uns abschließend bei allen Autoren bedanken, die mit ihren Beiträgen zum Gelingen dieses Buches beigetragen haben. Der Hauptteil der Arbeiten wurde naturgemäß von den Mitarbeitern des Forschungsinstituts für Kommunikation, Informationsverarbeitung und Ergonomie erbracht, aber erst die intensive Unterstützung durch die Autoren außerhalb unseres Institutes hat die Realisierung dieses Buches ermöglicht. Ihnen gebührt daher unser besonderer Dank. Beim SpringerVerlag möchten wir uns bedanken, dass er uns bei der Erstellung des Buches sehr unterstützt und die Umsetzung unseres Vorhabens tatkräftig begleitet hat. Wachtberg-Werthhoven, im Februar 2009 Die Herausgeber

Inhaltsverzeichnis

1

Einführung : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Stephan Söffing, Gerhard Bühler und Michael Wunder 1.1 Militärische Führungsinformationssysteme . . . . . . . . . . . . . . . . . . . . 1.2 Rückblick auf die technische Entwicklung militärischer Führungsinformationssysteme am Beispiel des FKIE . . . . . . . . . . .

Teil I Softwarearchitektur und übergreifende Aspekte 2

Grundlagen der Interoperabilität : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Ulrich Schade und Michael Gerz 2.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Stufen der Interoperabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Fehlende Interoperabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Dateninteroperabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Syntaktische Interoperabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Semantische Interoperabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7 Pragmatische Interoperabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

Konzeption verteilter Führungsinformationssysteme : : : : : : : : : : : : : : Marc Spielmann 3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Allgemeine Anforderungen an FüInfoSys . . . . . . . . . . . . . . . . . . . . . 3.3 Übergeordnete Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

Management verteilter Führungsinformationssysteme : : : : : : : : : : : : : Norman Jansen und Marc Spielmann 4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Services und Service-Instanzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Modell eines Service-Managements . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xi

xii

Inhaltsverzeichnis

5

Integration von heterogenen Quellen : : : : : : : : : : : : : : : : : : : : : : : : : : : : Thomas Nitsche und Andreas Wotzlaw 5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Integrationskonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Architekturkonzept des Integrationsportals . . . . . . . . . . . . . . . . . . . . 5.4 Schlussfolgerungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

Anbindung von Geoinformationssystemen an FüInfoSys : : : : : : : : : : : Daniel Krämer 6.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Konzeption einer Präsentationsschicht . . . . . . . . . . . . . . . . . . . . . . . 6.3 Anforderungen an die Visualisierungsfunktionalität GIS . . . . . . . . . 6.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

Dynamische Verteilung von Daten in taktischen Netzen : : : : : : : : : : : : Norman Jansen und Marc Spielmann 7.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Übersicht über das Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Detaillierung des Modells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

Intelligente Daten-Filterung in FüInfoSys : : : : : : : : : : : : : : : : : : : : : : : : Thomas Nitsche 8.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Ansätze zur Datenfilterung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Verwaltung der Interessengebiete mittels Gebietsmanagern . . . . . . 8.4 Schlussfolgerungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Teil II Assistenzsysteme 9

Wissens- und Workflowmanagement : : : : : : : : : : : : : : : : : : : : : : : : : : : : Jürgen Kaster, Wolf-Dieter Huland und Sascha Huy 9.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Wissenschaftliche Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4 Anwendungsbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10 Auftragsmanagement : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Jürgen Kaster und Daniel Schaefer 10.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Auftragsmanagement als zyklischer Prozess . . . . . . . . . . . . . . . . . . . 10.4 Operationelles Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5 Der Prozess der Auftragsabwicklung . . . . . . . . . . . . . . . . . . . . . . . . .

Inhaltsverzeichnis

10.6 10.7 10.8 10.9 10.10

Nutzerrollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Struktur eines Informationsersuchens . . . . . . . . . . . . . . . . . . . . . . . . . Interoperabilität im multinationalen Informationsverbund . . . . . . . . Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11 Grafische Aktionsplanung : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Marc Spielmann 11.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Maschineninterpretierbare Operationsskizzen . . . . . . . . . . . . . . . . . . 11.3 Grafisch unterstützte Befehlsbearbeitung . . . . . . . . . . . . . . . . . . . . . . 11.4 Ebenenübergreifende Befehlsgebung . . . . . . . . . . . . . . . . . . . . . . . . . 11.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Multilinguale Textinhaltserschließung auf militärischen Texten : : : : : Matthias Hecking 12.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Informationsextraktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3 Das multilinguale ZENON-System . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4 Das KFOR-Korpus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Sprachverarbeitung militärisch relevanter Audiodaten : : : : : : : : : : : : Corinna Harwardt 13.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2 Verarbeitung gesprochener Sprache . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3 Darstellung relevanter Sprachverarbeitungstechnologien für militärische Anwendungsbereiche . . . . . . . . . . . . . . . . . . . . . . . . 13.4 Sprechererkennungstechnologie als Assistenzsystem in Führungsinformationssystemen . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.5 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . Teil III Interoperabilität, Standards und Projekte 14 Überblick über Interoperabilitätsstandards : : : : : : : : : : : : : : : : : : : : : : Michael Gerz und Ralf Heckmann 14.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2 Allied Data Publication 3 (ADatP-3) . . . . . . . . . . . . . . . . . . . . . . . . . 14.3 NATO Friendly Force Information (NFFI) . . . . . . . . . . . . . . . . . . . . 14.4 Over the Horizon Targeting GOLD (OTH-T GOLD) . . . . . . . . . . . . 14.5 Multilateral Interoperability Programme (MIP) . . . . . . . . . . . . . . . . 14.6 MMHS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.7 ASCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.8 Datenintegration mittels Mediation . . . . . . . . . . . . . . . . . . . . . . . . . .

xiii

xiv

Inhaltsverzeichnis

15 Architekturrahmenwerke : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Ralf Kreibich 15.1 Bedeutung von Architekturrahmenwerken . . . . . . . . . . . . . . . . . . . . . 15.2 Anforderungen an Architekturrahmenwerke . . . . . . . . . . . . . . . . . . . 15.3 Aufbau von Architekturrahmenwerken . . . . . . . . . . . . . . . . . . . . . . . 15.4 Vergleich verschiedener Architekturrahmenwerke . . . . . . . . . . . . . . 15.5 Anwendungsfälle für Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . 15.6 Das NATO Architecture Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 15.7 Architekturen in der Bundeswehr . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Das Joint Consultation Command and Control Information Exchange Data Model : : : : : : : : : : : : : : : : : : Michael Gerz und Ulrich Schade 16.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.2 Geschichtliche Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.3 Informationsaustauschanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . 16.4 Struktur des Datenmodells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.5 Geschäfts- und Implementierungsregeln . . . . . . . . . . . . . . . . . . . . . . 16.6 Nutzung des JC3IEDM in verwandten Projekten . . . . . . . . . . . . . . . 16.7 UML und modellgetriebene Architektur . . . . . . . . . . . . . . . . . . . . . . 16.8 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Battle Management Language : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Ulrich Schade und Michael R. Hieb 17.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.2 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.3 Entwicklung der BML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.4 Die formalen Konstruktionsprinzipien der BML . . . . . . . . . . . . . . . . 17.5 Sprachbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.6 Anwendungsbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Interoperabilität in der Lagebearbeitung : : : : : : : : : : : : : : : : : : : : : : : : Jürgen Kaster und Claus J. Weber 18.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.2 Wahrnehmen – Verstehen – Projizieren . . . . . . . . . . . . . . . . . . . . . . . 18.3 Anforderungen an das Lagebild . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.4 Defizite bestehender Formalisierungen . . . . . . . . . . . . . . . . . . . . . . . 18.5 Kontextbezogene Zuordnung von Einzelbeobachtungen . . . . . . . . . 18.6 Austauschformat für militärische Lageinformationen . . . . . . . . . . . 18.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 MAJIIC – ISR-Interoperabilität für weiträumige Bodenaufklärung : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Wolfgang Koch, Marion Sielemann und Martin Ulmke 19.1 ISR-Aufklärungssysteme und Interoperabilität . . . . . . . . . . . . . . . . .

Inhaltsverzeichnis

19.2 19.3

Schritte zur ISR-Interoperabilität: MAJIIC in der Praxis . . . . . . . . . Entscheidungsunterstützung durch MAJIIC-Systeme . . . . . . . . . . . .

20 Sichere Kommunikation in heterogenen militärischen Netzen : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Thorsten Aurisch, Peter Sevenich und Jens Tölle 20.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20.2 Herausforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20.3 Sichere Koalitionsnetze am Beispiel INSC . . . . . . . . . . . . . . . . . . . . 20.4 Die Struktur eines sicheren Netzes . . . . . . . . . . . . . . . . . . . . . . . . . . 20.5 Einbindung von INSC in weitere Aktivitäten . . . . . . . . . . . . . . . . . . 20.6 Untersuchte Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20.7 IT-Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20.8 Netzmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20.9 Bewertung der Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20.10 Empfehlungen aufgrund der gewonnenen INSC-Ergebnisse . . . . . . 20.11 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Testen der semantischen Interoperabilität von Führungsinformationssystemen : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Michael Gerz, Michael Glauer und Nico Bau 21.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Interoperabilitäts- und Konformitätstests . . . . . . . . . . . . . . . . . . . . . . 21.3 Testspezifikationen für Konformitätstests . . . . . . . . . . . . . . . . . . . . . 21.4 MIP Test Reference System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sachverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xv

Mitarbeiter

Sofern nicht anders gekennzeichnet, sind die Autor(inn)en tätig in der Abteilung Informationstechnik für Führungssysteme (ITF) am Forschungsinstitut für Kommunikation, Informationsverarbeitung und Ergonomie (FKIE), Neuenahrer Straße 20, 53343 Wachtberg-Werthhoven. AURISCH , T HORSTEN , D R . Abteilung Kommunikationssysteme (KOM) BAU , N ICO B ÜHLER , G ERHARD G ERZ , M ICHAEL , D R . G LAUER , M ICHAEL G ROSCHE , J ÜRGEN , P ROF. D R . Direktor des FKIE H ECKING , M ATTHIAS , D R . H ARWARDT, C ORINNA H ECKMANN , R ALF Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr H IEB , M ICHAEL R., P ROF. D R . Center of Intelligence in C4I, George Mason University, Fairfax, VA 22030, USA H ULAND , W OLF -D IETER H UY, S ASCHA JANSEN , N ORMAN K ASTER , J ÜRGEN KOCH , W OLFGANG , D R . Abteilung Sensordaten- und Informationsfusion (SDF) xvii

xviii

Mitarbeiter

K RÄMER , DANIEL K REIBICH , R ALF Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr N ITSCHE , T HOMAS , D R . S CHADE , U LRICH , P ROF. D R . S CHAEFER , DANIEL S EVENICH , P ETER Abteilung Kommunikationssysteme (KOM) S IELEMANN , M ARION Bundesministerium der Verteidigung S ÖFFING , S TEPHAN Bundesministerium der Verteidigung S PIELMANN , M ARC , D R . T ÖLLE , J ENS , D R . Abteilung Kommunikationssysteme (KOM) U LMKE , M ARTIN , D R . Abteilung Sensordaten- und Informationsfusion (SDF) W EBER , C LAUS J. W OTZLAW, A NDREAS , D R . W UNDER , M ICHAEL , D R .

Abkürzungen

ADatP-3 API APP APP-6A ATCCIS BMVg BML BPM BSD Bw C2IEDM CAESAR C-BML CCIRM CD&E CLAN CPDD COI CoNSIS COTS CROP CSD CWID DEM EER ETB GMTI GPS

Allied Data Publication 3 Application Programming Interface Allied Procedural Publication APP Military Symbols for Land Based Systems Army Tactical Command and Control Information System Bundesministerium der Verteidigung Battle Management Language Business Process Management Berkley Software Distribution (Unix) Bundeswehr Command and Control Information Exchange Data Model Coalition Aerial Surveillance and Reconnaissance Coalition Battle Management Language Collection, Coordination, and Intelligence Requirements Management Concept Development and Experimentation Coalition LAN Collection, Processing, Dissemination, Direction (Aufklärungszyklus) Community of Interest Coalition Networks for Secure Information Sharing Commercial of the Shelf Common Relevant Operational Picture (dt. GREL) Coalition Shared Database Coalition Warrior Interoperability Demonstration MIP Data Exchange Mechanism Equal Error Rate, Gleichfehlerrate Einsatztagebuch Ground Moving Target Indicator Global Positioning System (dt. Globales Positionsbestimmungssystem)

xix

xx

GREL FKIE

Abkürzungen

Gemeinsames Rollenorientiertes Einsatzlagebild (engl. CROP) Forschungsinstitut für Kommunikation, Informationsverarbeitung und Ergonomie FüInfoSys Führungsinformationssystem FüZBw Führungszentrum Bundeswehr HIP Host Identity Protocol HMTI Hochmobiles taktisches Intranet IDEF Integrated Definition Methods (Gruppe von Modellierungssprachen) IAGFA Integrierte Arbeitsgruppe Fähigkeitsanalyse IKE Internet Key Exchange INSC Interoperable Networks for Secure Communications IntPortal Integrationsportal INTSUM Intelligence Summary IP Internet Protocol IPsec IP security (Sicherheitsprotokollsuite) IPv4 Internet Protocol in der Version 4 IPv6 Internet Protocol in der Version 6 ISAF International Security Assistance Force ISO International Organization for Standardization ISR Intelligence, Surveillance, Reconnaissance IuK Information und Kommunikation JASMIN Joint Analysis System Military Intelligence JC3IEDM Joint Consultation, Command, and Control Information Exchange Data Model KFOR Kosovo Force KMobKommH Konzept für die mobile Kommunikation im Heer KMNB Kabul Multinational Brigade LAN Local Area Network LC2IEDM Land Command and Control Information Exchange Data Model LISI Levels of Information Systems Interoperability MAJIIC Multisensor Aerospace-Ground Joint ISR Interoperability Coalition MANET Mobiles Ad-hoc-Netz MDA Model-Driven Architecture MFCC Mel-Frequenz-Cepstrum-Koeffizienten MFP Multicast Forwarding Protocol MIKE Multicast Internet Key Exchange MIRD MIP Information Resource Dictionary MIP Multilateral Interoperability Programme/Mobile IP MIPL Mobile IPv6 for Linux MobKommSysBw Mobiles Kommunikationssystem der Bundeswehr MoU Memorandum of Understanding MSDL Military Situation Discription Language

Abkürzungen

xxi

MTRS NAT NCDM NEMO NetOpFü NG&A NNEC NID NRF OCL OGC OID OIG OLSR OMG OODA OWL P_MUL QoS REMINET RFC RFI SA SATCOM SCA SCIP SDR SINA SOA STANAG

MIP Test Reference System Network Address Translation NATO Corporate Data Model Network Mobility Vernetzte Operationsführung Nachrichtengewinnung und Aufklärung NATO Network Enabled Capabilites NATO Interoperability Directive NATO Response Forces Object Constraint Language Open Geospacial Consortium Objektidentifikator Operational Information Group Optimized Link State Routing Object Management Group Observe, Orient, Decide, Act (Führungszyklus) Web Ontology Language Multicast-Protokoll Quality of Service Resource Management in Mobile Military Networks Request For Comment Request For Information (Informationsersuchen) Situation(al) Awareness Satellite Communication Software Communications Architecture Secure Communications Interoperability Protocol Software Defined Radio Sichere Inter-Netzwerk Architektur Serviceorientierte Architektur Standardization Agreement (NATO-Standardisierungsübereinkommen) Streitkräfte-gemeinsame verbundfähige Funkgeräteausstattung Tactical Communication Standards for Joint Operations Transmission Control Protocol Implementation of Ipv6 Protocol for Tactical Interoperable Communications Networks User Datagram Protocol Unified Modeling Language Very High Frequency Zusammenfügung aus dem engl. voice und encoder Voice over IP Virtual Private Network Web Feature Service Web Services Information Environment Wireless Local Area Network

SVFuA TACOMS TCP TIC-NET UDP UML VHF Vocoder VoIP VPN WFS WISE WLAN

xxii

WNet WWM XML ZDv ZMilNw

Abkürzungen

Wireless Network (Ad-hoc-Routing-Protokoll) Wissens- und Workflowmanagement Extensible Markup Language Zentrale Dienstvorschrift Zentrale Militärisches Nachrichtenwesen

Kapitel 1

Einführung Stephan Söffing, Gerhard Bühler und Michael Wunder

1.1 Militärische Führungsinformationssysteme Befasst man sich intensiver mit dem Thema Führungsinformationssysteme, kommt fast zwangsläufig die Frage auf, welche Bedeutung diesen Systemen eigentlich zukommt. Sind sie wirklich von so immenser Bedeutung, wie aus ihrer Priorisierung bei Beschaffungsvorhaben hervorzugehen scheint? Oder ließe sich der Führungsvorgang womöglich schneller, stabiler und sicherer gestalten, wenn sich der militärische Führer stattdessen auf Tabellen, Meldungen in Papierform und die Darstellung der aktuellen Lage auf Folie vor einer Landkarte stützt? Tatsächlich ist diese Frage schnell beantwortet, denn ohne ein informationstechnisches Instrumentarium, das die Aufbereitung der Informationen, die Darstellung der strategischen und taktischen Lage in einem geeigneten Informationsraum ermöglicht, ist heute jeder Einsatz von der Hilfe bei Katastrophen bis hin zum friedenerhaltenden bzw. friedenerzwingenden Einsatz unvorstellbar. Die Möglichkeit der lückenlosen Berücksichtigung aller verfügbarer Informationen in einem Einsatz kann nicht hoch genug bewertet werden. Nur wer umfassende Informationen über die eigenen Kräfte, über die Lage des Gegenübers und weitere relevante Randbedingungen (Ortskenntnisse, politische Zusammenhänge, Wetter uvm.) besitzt, kann die richtigen Schlüsse ziehen. Vor jedem Einsatz steht daher eine intensive, ausreichende und möglichst allumfassende Lagebewertung, auf deren Grundlage Entscheidungen zu fällen sind. Ohne technische Hilfsmittel, die die Vielzahl der Informationen zusammenfassen, auswerten und aufbereiten, wäre die resultierende Informationsflut selbst in trainierten Stäben nicht mehr beherrschbar, wodurch wiederum Entscheidungen behindert, verzögert oder sogar unmöglich würden. Für die Stabsarbeit wird ein System benötigt, welches nicht nur Daten mit kurzfristiger Relevanz verwaltet, aufbereitet und präsentiert, sondern den militärischen Führer bei der Lagebeurteilung unter Einbeziehung der Historie, also in einem erweiterten Kontext, unterstützt. Dabei muss das Gesamtsystem den jeweiligen Anforderungen an das Informationsmanagement auf der strategischen, operativen und taktischen Ebene Rechnung tragen. Führungsinformationssysteme spielen im Gedankengut der Transformation eine tragende Rolle. Bei der Vernetzten OperationsM. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

1

2

S. Söffing, G. Bühler und M. Wunder

führung (NetOpFü) sind sie die Spinne im Netz, nämlich Dreh- und Angelpunkt der Informationen. Ein Muss in jedem Einsatzszenario.

1.1.1 Historie Lässt man die letzten dreißig bis vierzig Jahre der Entwicklung von Führungsinformationssystemen Revue passieren, zeigt sich deren deutlich verbesserte Leistungsfähigkeit. Dies wurde möglich durch intensive Nutzung der Vorteile, die Informationstechnik bietet. Die Gestaltung von Führungsmitteln ohne konsequente Berücksichtigung der Möglichkeiten moderner IT ist heute nicht mehr vorstellbar. In den 70er Jahren konzentrierten sich Forderungen der Nutzer auf die Entwicklung von Funktionsblöcken z. B. zur Textverarbeitung, Tabellenkalkulation sowie der Darstellung der taktischen Lage auf einem Kartenhintergrund. Ziel war die Umstellung der Datenverarbeitung von der Schreibmaschine und dem 6-B-Stift auf die moderne Technik sowie die Beschleunigung der Informationsübertragung. Der Führungsvorgang selbst sollte dabei möglichst 1:1 abgebildet werden. Überlegungen, Arbeitsabläufe mithilfe der neuen Technologien anders zu gestalten, kamen fast nicht vor. Stattdessen hatte man bei der Entwicklung insbesondere mit technischen Restriktionen zu kämpfen, welche die Möglichkeiten der elektronischen Datenverarbeitung beschränkten. Beispielsweise war es früher zwingend erforderlich, mit dem Hauptspeicher besonders sparsam umzugehen. Wer es verstand, in seinen Programmen den begrenzten Hauptspeicher optimal zu nutzen, war im Vorteil. Diese Einschränkung spielt heute bei den meisten Anwendungsfällen keine Rolle mehr. Es ließen sich weitere technische Einschränkungen (z. B. Datenspeichervolumina, Platzbedarf) aufzählen, die durch die Weiterentwicklung der Informationstechnologien inzwischen mehr oder weniger belanglos geworden sind. Früher dominierten militärische Entwicklungen viele IT-Standards. Dass später der zivile Markt die Standards setzen würde und militärische Forderungen an die Textbearbeitung wie auch bei vielen vergleichbaren Modulen aufgrund der dominierenden Nachfrage des zivilen Marktes bei Produktherstellern keine Rolle mehr spielen würden, war in den 70er Jahren nicht vorhersehbar. Ein Beispiel für ein Ziel, das aus damaliger Sicht zweckmäßig bzw. aufgrund begrenzter Fähigkeiten oder mangelnder Verfügbarkeit damaliger IT-Technologien nahe liegend war, ist die Eigenentwicklung militärischer Rechner für den Einsatz in Führungsinformationssystemen. Heute werden Funktionen, die durch kommerziell verfügbare Produkte unterstützt werden, von einzelnen begründeten Ausnahmen (beispielsweise im Rahmen der Informationssicherheit) abgesehen, nicht mehr in militärischen Eigenentwicklungen realisiert. Die Erkenntnis, dass es nicht sinnvoll war, die vorhandenen Abläufe unverändert in Führungsinformationssystemen abzubilden, sondern dass es viel besser ist, zur Nutzung der Möglichkeiten und Chancen der neuen Technik gleichzeitig Organisationsstrukturen und Prozesse zu ändern, setzte sich nur langsam durch. Dieser Veränderungsprozess ist auch heute noch nicht abgeschlossen und man erkennt mitunter immer noch, dass bei der Formulierung von Forderungen nicht der Blick

1 Einführung

3

nach vorne, sondern der Status Quo Pate gestanden hat. Auch wuchs das Ziel einer bereichsübergreifenden Unterstützung von Abläufen (Geschäftsprozessen) und damit der Möglichkeit eines Datenaustauschs zwischen einzelnen Systemen erst langsam mit der Verfügbarkeit entsprechender Möglichkeiten der IT heran. So forderten die Teilstreitkräfte, ja sogar einzelne Truppengattungen, individuelle, eigenständige Systeme. Mit der Erkenntnis, dass Informationen geteilt werden müssen, nahmen Schnittstellenkonferenzen im Rahmen der Projektrealisierung einen breiteren Raum ein. In diesem Zusammenhang gewann auch die Standardisierung der Daten, die nicht nur national, sondern ganz besonders im Rahmen der NATO betrieben wurde, eine wesentliche Bedeutung. Die heutigen Herausforderungen liegen eher in der Komplexität der zu unterstützenden Prozesse, die zudem nicht mehr als unabhängig voneinander betrachtet werden können. Die Gliederung des Führungsprozesses in die kreisförmig angeordneten Phasen Lagefeststellung, Planung, Befehlsgebung und Kontrolle ist auch heute noch gültig, allerdings sind die Anforderungen hinsichtlich Verarbeitungsgeschwindigkeit, Genauigkeit und natürlich auch die zu bewältigenden Informationsmengen überhaupt nicht mehr mit der Situation in den 70er und 80er Jahren vergleichbar. Durch die ebenfalls erheblich gestiegene Anzahl von Informationsquellen und Sensoren werden inzwischen enorme Menge an Daten erzeugt. Die Möglichkeiten zur Führungsunterstützung haben sich allerdings dank der Informationstechnik ebenfalls gravierend geändert. Was hinsichtlich Verarbeitungsgeschwindigkeit, bewältigbarer Informationsmenge und Präzision gestern noch Utopie war, ist heute längst Realität. Damals wie heute sind dagegen die grundsätzlichen Anforderungen an ein Führungsinformationssystem weitgehend dieselben. Mit seiner Hilfe soll der Führungsprozess unterstützt, verbessert und beschleunigt werden. Die altbekannte Aussage „der Nutzer soll zu jeder Zeit an jedem Ort über die für seine Situation erforderlichen Informationen verfügen“ hat nach wie vor Gültigkeit. Um seine Bedürfnisse zu konkretisieren, muss der Nutzer seine Anforderungen aus operativer Sicht formulieren und dabei die zugrunde liegenden Prozesse beschreiben. Module, die einzelne Prozessschritte unterstützen, sind schließlich zu einem durchgängigen Gesamtsystem. Bei der Formulierung der Anforderungen an militärische Führungsinformationssysteme muss eine Vielzahl von Randbedingungen berücksichtigt werden. Eine wesentliche Bedeutung hat der Raum, in dem ein militärischer Einsatz erfolgt. Mit dem Begriff Raum wird nicht nur der geografische Bereich verstanden. Es geht vielmehr um einen Informationsraum, der sich über die militärisch relevante Gesamtsituation vom politischen Verständnis und Auftrag an die Streitkräfte, die Einbettung in militärische Bündnisse und Strukturen, die Verbindung zu nicht militärischen Einrichtungen, die Beteiligung von Teilstreitkräften mit ihren unterschiedlichen Kenntnissen, Expertisen, Fähigkeiten und Waffensystemen bis hin zum einzelnen Soldaten erstreckt. Dieser Informationsraum soll allen an einem Einsatz beteiligten Führungselementen und Personen einen geregelten Zugriff auf die relevanten und konsistenten Informationen ermöglichen, um eine gemeinsame Sicht auf die Lage als Voraussetzung für ein abgestimmtes Handeln zu erhalten.

4

S. Söffing, G. Bühler und M. Wunder

Mit Beendigung der Phase des Kalten Krieges und der damit verbundenen Veränderung der gesamten Sicherheitslage haben sich die Anforderungen an unsere Streitkräfte gewandelt. Das veraltete Bild des großen vaterländischen Konfliktes, das sich zwangsläufig in den Anforderungen an die IT-Systeme widerspiegelte, ist einem ganz neuen Anforderungsprofil gewichen. Aktuelle und zukünftige Szenarien sind geprägt durch internationale Bündnisse mit gemeinsam durchgeführten Einsätzen, in denen die beteiligten Nationen enger zusammen arbeiten, ihre militärischen Strukturen variabler sind und in denen die Grenzen zwischen den Teilstreitkräften verwischen. Integrierte Verbände werden aus Kontingenten mehrerer Nationen gebildet. Daraus resultieren gänzlich neue Herausforderungen für Führungsinformationssysteme. Diese müssen nicht nur den Informationsaustausch gemäß der bisher gewohnten, nationalen Befehlshierarchien unterstützen, sie müssen sich ebenso im Rahmen von so genannten Joint and Combined Operations in internationale Systemverbünde einfügen und sich flexibel an die sich während des Einsatzes ändernde Unterstellungsverhältnisse anpassen. Nur Informationssysteme, die diesen Ansprüchen genügen, können die Führung vor Ort und global in allen Belangen ausreichend unterstützen. Die Realisierung einer weitgehenden Interoperabilität zwischen den Führungsinformationssystemen wird besonders dringlich. Das zukünftig bereitzustellende System muss in den strategischen, operativen und taktischen Führungsebenen einsetzbar sein. Die sich hieraus ergebenden unterschiedlichen Anforderungsprofile sollen je nach Einsatzbedingungen und Führungsebene nach dem Prinzip des „Legosteinbaukastens“ durch individuell konfigurierbare Systeme realisiert werden. Wesentliche Attribute dabei sind: stationär, verlegefähig und mobil. Hinzu kommt eine mögliche Autarkie der auszustattenden Elemente. Außerdem sind die zur Verfügung stehenden Kommunikationsmittel und Bandbreiten bei der Konzeption und Implementierung zu beachten. Moderne Führungsinformationssysteme müssen für neue Einsatzszenarien geeignet sein und dabei auch die Zuständigkeiten ziviler Organisationen berücksichtigen. Die Zusammenarbeit mit dem Bundeskanzleramt, dem Bundesministerium der Verteidigung, dem Bundesministerium des Inneren, dem Bundesministerium für Verkehr, Bau und Stadtentwicklung sowie dem Auswärtigen Amt muss unterstützt werden.

1.1.2 Regelwerke, Projektelemente Der gesamte Lebenszyklus eines IT-Systems wird durch ein Regelwerk eingerahmt und erstreckt sich von der ersten Idee, der Feststellung der Fähigkeitslücke über die Realisierung bis hinein in die Nutzung. Die Beachtung des Regelwerkes bedeutet für das Projektmanagement eine ständige Optimierungsaufgabe. Neben der Berücksichtigung der vom Nutzer an das Führungsinformationssystem gestellten Forderungen müssen weitere Rahmenbedingungen beachtet werden, von denen hier einige der wichtigsten angesprochen werden.

1 Einführung

5

 Eine wesentliche Bedeutung bei der Realisierung von Führungsinformationssystemen hat die IT-Sicherheit aufgrund ihres querschnittlichen Charakters. Außerdem werden im internationalen Umfeld mit Sicherheitsabkommen zwischen den einzelnen Staaten und Institutionen besondere Forderungen an die Interoperabilität zwischen den Systemen bzw. an die Verbindung zwischen zwei Informationsdomänen gestellt. Die daraus resultierenden Einschränkungen führen dazu, dass die Systeme nicht ohne Weiteres zusammengeschaltet werden können, selbst wenn die technischen Voraussetzungen dafür gegeben wären.  Zur Gewährleistung eines stabilen Gesamtsystems während des Lebenszyklusses muss frühzeitig ein gut funktionierendes Lizenzmanagement aufgebaut werden. Mit der fast ausschließlichen Verwendung fertiger, am Markt verfügbarer Produkte und dem damit verbundenen Verzicht auf eigene Softwarerealisierungen kann zwar ein Entwicklungsrisiko reduziert werden, allerdings handelt man sich unter Umständen andere Nachteile ein. Um eine Abdeckung eines Gesamtprozesses zu erreichen, müssen mehrere Produkte kombiniert werden, die meist von mehreren Herstellern angeboten werden, die ihre eigenen Produktphilosophien verfolgen. Daraus resultieren besondere Anforderungen an das Versionsmanagement und das Lizenzmanagement. Insbesondere die unterschiedlichen Lizenzierungsformen der Produktanbieter müssen in einer sehr detaillierten Konfigurationskontrolle überwacht werden, damit sichergestellt wird, dass möglichst genau die Anzahl der erworbenen Lizenzen genutzt wird. Die Versionswechsel von Produkten, aber auch die Anpassung von Releaseständen der eingesetzten Standards, müssen für das gesamte IT-System koordiniert werden, wodurch die Freiheitsgrade der einzelnen Systeme reduziert werden. Im Übrigen ist auch die Interoperabilität der einzelnen Produkte eine besondere Herausforderung.  Eine Freigabe, die für alle zu betrachtenden Systeme in einem vorgegebenen Zeitrahmen erfolgt, bedeutet auch, dass die erforderliche Kapazität zum Prüfen und Austesten einer neuen Produktversion oder eines neuen Standardreleases zur Verfügung stehen muss. Bevor die Implementierung eines fortgeschriebenen internationalen Standards, wie z. B. ADatP-3 (Allied Data Publication Number 3. NATO standard for formatted messages), APP-6 (Allied Procedural Publication Number 6. NATO standard for military map marking symbols), MIP (Multilateral Interoperability Programme, 2008a) bzw. des NATO Datenmodells JC3IEDM (Joint Command Control and Consultation Information Exchange Data Model) freigegeben wird, muss eine Planung erfolgen, die neben der erforderlichen Implementierungszeit genauso die Bereitstellung der notwendigen Haushaltsmittel berücksichtigt. Des Weiteren müssen nicht nur nationale Entwicklungen, sondern soweit wie möglich auch die internationale Systemlandschaft beachtet werden.  Eine frühzeitige Planung der notwendigen Regeneration mag am Anfang eines Projektes nebensächlich erscheinen, nimmt aber einen hohen Stellenwert ein, wenn das System erst einmal in Nutzung ist. Gerade bei langen Realisierungszeiten und stufenweisen Entwicklungsschritten müssen die Projektleitung und die Nutzungsleitung eng miteinander abgestimmt eine Regenerationsplanung erarbeiten, damit ein kontinuierlicher Betrieb des Systems gewährleistet wird.

6

S. Söffing, G. Bühler und M. Wunder

 Enorm wichtig während der Realisierung des Systems sind die Konzeption und Planung der Ausbildung von Nutzern und Administrationspersonal. Schlechte oder schlecht vorbereitete Ausbildungsmaßnahmen, ein fehlendes Ausbildungskonzept oder auch eine unterlassene Einplanung von Ausbildungsanlagen können für ein Führungsinformationssystem das „Aus“ bedeuten, noch bevor es in die eigentliche Nutzung überführt wurde. Nur mit ausgebildeten Nutzern und einem ausgebildeten Systemadministrator kann die notwendige Effektivität eines Führungsinformationssystems erreicht werden.

1.1.3 Ministerielle Entscheidungsprozeduren Der Startschuss für ein neues Projekt wird in der Regel mit der Feststellung einer Fähigkeitslücke gelegt. Anschließend folgt die Beschreibung in einer Initiative, die der IAGFA (Integrierte Arbeitsgruppe Fähigkeitsanalyse) zur Bewertung und Entscheidung vorgelegt wird. Bestätigt diese das Vorhandensein der Fähigkeitslücke, wird ein Auftrag zur Erstellung eines Phasendokumentes erteilt, das als haushaltbegründendes Dokument zur ministeriellen Mitzeichnung und Billigung vorgelegt wird. Außerdem wird der Mittelbedarf im Rahmen der Bundeswehrplanung festgestellt und anschließend in den entsprechenden Haushalt eingebracht. Zwischen der Angebotsphase und dem Vertragsabschluss kann je nach Volumen der Beschaffung eine Parlamentsvorlage liegen. Anschließend folgt die Realisierungsphase. In Summe können zwischen der Feststellung der Fähigkeitslücke und dem ersten Rollout mehrere Jahre liegen. Um unvertretbar lange Pausen bei der kontinuierlichen Weiterentwicklung eines Systems in einem Folgeprojekt zu vermeiden, müssen die entsprechenden Beschlüsse bereits lange bevor die Entwicklung der vorangegangenen Entwicklungsstufe beendet ist, getroffen werden. Würde man erst das Entwicklungsergebnis der vorangegangenen Stufe und die Bewertung des Nutzers und die daraus resultierenden Forderungen abwarten, bevor man mit der Erarbeitung des Folgephasendokumentes beginnt, entstünden enorme Verzögerungen zwischen zwei Projektschritten. Angesichts der Geschwindigkeit, in der der IT-Markt mit Innovationen aufwartet oder sich die Randbedingungen und die Forderungslage ändern, sind die Zeiträume bis zum Vertragsabschluss, ab dem die Realisierung erfolgen kann und anschließend bis zur Bereitstellung der vom Nutzer geforderten Funktionalität, vergleichsweise lang. Als erste Maßnahme der Verbesserung werden Projekte zur Minimierung von Realisierungsrisiken und zur besseren Nutzung von Innovationen verstärkt in Teilprojekte untergliedert.

1.1.4 Ausblick Mit dem Ziel der Befähigung zur vernetzten Operationsführung verfolgt die Bundeswehr die Harmonisierung der existierenden Führungsinformationssysteme und

1 Einführung

7

teilweise der Führungs- und Waffeneinsatzsysteme zu einem gemeinsamen Führungsinformationssystem. Die infolge der geänderten Bedrohungslagen entstandenen Herausforderungen sollen mit dem gemeinsamen, skalierbaren, modularen und flexiblen Führungsinformationssystem gemeistert werden. Unter gemeinsam wird dabei verstanden, dass alle Basisforderungen der auszustattenden Bereiche in einem Grundsystem bereitgestellt werden. Mit der angestrebten Skalierbarkeit sollen sich die im Rahmen eines Auftrages ergebenden Größenveränderungen, vom Vorkommando bis hin zu einem mehrere 100 Arbeitsplätze umfassenden Stab, problemlos erreichen lassen. Unter modular ist zu verstehen, dass das System je nach Anforderung in Form von Modulen für den einzelnen Einsatz und die Führungsebene auszulegen und zusammenzustellen ist. Durch die freie Konfigurierbarkeit kann das System je nach Führungsebene und den einsatzbedingten Forderungen flexibel angepasst werden. Flexibel bedeutet aber auch, dass das System auf wechselnde Anforderungen im Bereich der Informationsbedürfnisse reagieren kann. Um den zukünftigen Herausforderungen der Bundeswehr gerecht zu werden, muss insbesondere auch die Interoperabilität in einem internationalen Umfeld gewährleistet sein. Gelingt dieser Ansatz, ist die Bundeswehr für die anstehenden Aufgaben gewappnet. Wichtig ist, dass die Struktur und die Architektur so gestaltet sind, dass neue Ideen und Technologien jederzeit Eingang in die Führungsinformationssysteme finden können.

1.2 Rückblick auf die technische Entwicklung militärischer Führungsinformationssysteme am Beispiel des FKIE In diesem Abschnitt soll die Historie in der Entwicklung militärischer Führungsinformationssysteme am Beispiel der jahrzehntelangen Forschungsaktivitäten des Forschungsinstituts für Kommunikation, Informationsverarbeitung und Ergonomie (FKIE) anschaulich gemacht werden. Damit wird noch einmal deutlich gemacht, aus welchen Ursprüngen sich die in den nachfolgenden Kapiteln beschriebenen Technologien entwickelt haben. Im Jahre 1964 trat das Referat TII3 des BMVtg1 (Bundesministerium für Verteidigung) an den Direktor des Forschungsinstituts für Funk und Mathematik (FFM)2 der Gesellschaft zur Förderung der astrophysikalischen Forschung e. V.3 mit dem sehr allgemein gefassten Auftrag heran, das Gebiet Command and Control zu bearbeiten. Dies führte schließlich 1966 – nach Genehmigung eines Stellenplanes und Bereitstellung entsprechender Mittel durch das BMVtg – zur Gründung einer neuen Abteilung Command and Control im FFM. Bereits im Gründungsjahr versuchten ein Abteilungsleiter und fünf Wissenschaftler (drei Nachrichtentechniker, ein Elektrotechniker, ein Physiker und ein Mathematiker) zu ergründen, was es in diesem 1 2 3

Später wurde daraus das BMVg (Bundesministerium der Verteidigung). Später wurde daraus zusammen mit dem Forschungsinstitut für Anthropotechnik das FKIE. Später in Forschungsgesellschaft für angewandte Naturwissenschaften (FGAN) umbenannt.

8

S. Söffing, G. Bühler und M. Wunder

Themenbereich zu erforschen gibt und wie die gefundenen Probleme mit Hilfe von elektronischen Rechenanlagen gelöst werden könnten. Da man zu dieser Zeit noch nicht „googeln“ konnte, waren umfangreiche und aufwendige Literaturrecherchen notwendig, um sich dem Themenbereich anzunähern. Ausgangsthemenbereich war Operations Research. Aber zum Thema Command and Control war in diesem Umfeld äußerst wenig zu finden. Vom BMVtg wurde den Wissenschaftlern eine militärische Beratergruppe zur Seite gestellt, die aus fünf Stabsoffizieren bestand. Gemeinsam wurde schließlich nach Besuchen bei deutschen und internationalen Stäben festgestellt, dass sich hinter Command and Control im Wesentlichen nichts anderes als Führung verbarg und es die Aufgabe war, den Führungsprozess durch Einsatz von Rechnern zu unterstützen. Nach dieser Erkenntnis wurde die Abteilung umgetauft: sie nannte sich fortan Rechner und Führungssysteme (RuF). Ein wichtiges Hilfsmittel zur Unterstützung des Führungsprozesses ist die grafische Darstellung der militärischen Lage. Aus diesem Grund wurde damit begonnen, ein Reihe von Programmen zu entwickeln, um eine solche Lagedarstellung zu realisieren. Zur Verfügung stand dafür ein Großrechner vom Typ Telefunken TR4 (Sapper, 2008)4. Der Rechner hatte als Hauptspeicher einen richtigen Kernspeicher von 32 768 Worten à 52 Bits, wovon 48 zur Informationsdarstellung, zwei zur Typenkennung und zwei als Paritätsbits verwendet wurden. Die Peripherie des Rechners bestand aus sechs Magnetbandgeräten, Schnelldrucker, Lochstreifenleser und -stanzer, Lochkartenleser und -stanzer sowie einer Kontrollschreibmaschine. Offline stand noch ein Zeichengerät vom Typ Graphomat Zuse Z64 (Zuse, 2008) zur Verfügung, das durch Lochstreifen gesteuert wurde. Programmiert wurde der Rechner mittels der höheren Programmiersprache ALGOL60 und der Assemblersprache TEXAS (Telefunken Externcode Assembler). Ein kleines Betriebssystem war ebenfalls vorhanden, das vor allem einen bequemen Zugriff auf die Peripherie und die Steuerung eines geordneten sequentiellen Ablaufs von Programmen ermöglichte. Auf dieser Rechenanlage wurde das so genannte TR4-Demonstrationssystem entwickelt. Es bot Funktionen        

4

zum Erfassen von Daten der eigenen und feindlichen Einheiten, zum Erfassen der Standorte der Einheiten, zum Erfassen der Grenzen der Einheiten, zum Erfassen von besonderen Führungslinien, zum Erfassen von Material und Personal sowie zur Ausgabe von Standardberichten und für spezielle Abfragen, die in ALGOL60 formuliert werden mussten sowie zum Erstellen eines Lochstreifens mit den Daten der grafischen Lagedarstellung und zur Steuerung des Graphomaten Z64. Dort wurde die Lage auf Klarsichtfolie im Format 1,2 m  1,4 m ausgegeben, die dann auf eine entsprechende Karte geheftet wurde.

Da der Rechner in sechs Schränken aus edelstem Teakholz untergebracht war, wurde er auch „Teak-Rechner“ genannt.

1 Einführung

9

Die Steuerung des gesamten Systems geschah im Dialog an der Kontrollschreibmaschine. Die einzelnen übersetzten Programmkomponenten und die Daten waren auf Magnetbändern gespeichert und wurden von hier bei Bedarf in den Hauptspeicher geladen. Das System war wegen des sequentiellen Zugriffs auf die Datensätze auf den Magnetbändern sehr langsam. Den Abschluss dieser Arbeiten bildete schließlich eine erfolgreiche Vorführung des Systems für den stellvertretenden Generalinspekteur der Bundeswehr und seinen Stab. Mittlerweile hatte man aus dem BMVtg die Information erhalten, dass die 7. US Army in Heidelberg das Command and Control System TOS (Tactical Operations System) betrieb. Eine Firma, die maßgeblich an der Implementierung des Systems mitgewirkt hatte, war die amerikanische Firma Bunker Ramo Corporation, Canoga Park, CA. Mit dieser Firma schloss das BMVtg schließlich einen Vertrag über die Entwicklung eines experimentellen Führungsinformationssystems für die oberste Führung der Bundeswehr, wobei die Federführung in diesem Projekt die Abteilung RuF des FFM hatte. Mitbeteiligt an dieser Entwicklung wurde auch die deutsche Industrie, hier die Siemens AG mit Mitarbeitern der Zweigniederlassung Köln. Ein zweites Ziel dieses Projektes sollte nämlich auch ein Wissenstransfer sein, um später solche Systeme auch ohne amerikanische Hilfe entwickeln zu können. Zeitweise arbeiteten in diesem Projekt 70 Personen, 40 Mitarbeiter der Firma Bunker Ramo, 10 Mitarbeiter der Firma Siemens und 20 Mitarbeiter aus der Abteilung RuF des FFM. Zunächst verfasste ein Team der Firma Bunker Ramo mehrere Aktenordner umfassende Systemspezifikationen für Hard- und Software. Die Hardware sollte eine CDC 3600 der Firma Control Data Corporation sein, was nicht weiter verwunderlich war, da das TOS auf der kleineren CDC 3300 betrieben wurde. Außerdem sollte im Rahmen des Projektes auch noch ein passendes Betriebssystem entwickelt werden. Am Ende wurde das System auf einem und für einen Rechner Siemens 4004/45 unter dem Standardbetriebssystem PBS (Plattenbetriebssystem) entwickelt. Der Rechner hatte 256 Kilo Bytes Hauptspeicher und als Peripherie eine Kontrollschreibmaschine, Lochkartenleser und -stanzer, sechs Wechselplattenspeicher für Stapel mit einer Kapazität von ca. 6,25 Mega Bytes, vier Magnetbandgeräte und einen Schnelldrucker. Für den Anschluss von Sichtgeräten stand zunächst eine Datenübertragungssteuerung, später ein Datenübertragungsvorrechner, zur Verfügung. Das PBS, das im Laufe der Zeit zum BS1000 weiterentwickelt wurde, war ein Betriebssystem, das bis zu 14 unabhängige Programme im Mehrprogrammbetrieb ablaufen lassen konnte, wobei allerdings Voraussetzung war, dass der Code aller Programme und des Betriebssystems gleichzeitig im Hauptspeicher Platz hatten; Betriebssysteme mit Verwaltung von virtuellem Speicher gab es zu dieser Zeit noch nicht (obwohl Fritz-Rudolf Güntsch den virtuellen Speicher im Rahmen seiner Dissertation bereits 1957 erfunden hatte). Das Betriebssystem selbst benötigte lediglich 10 Kilo Bytes, wobei die ersten 8 Kilo Bytes für residenten Code reserviert waren, während die restlichen 2 Kilo Bytes als so genannter Overlay-Bereich dienten, in den bei Bedarf weiterer, selten benötigter Code des Betriebssystems geladen wurde, wie etwa Fehlerbehandlungsroutinen für Ein/Ausgabe-Geräte. Das zu entwickelnde Führungsinformationssystem für die oberste Bundeswehrführung erhielt den Namen Experimentelles Militärisches FührungsInformations-

10

S. Söffing, G. Bühler und M. Wunder

System (EMFIS; Storz et al., 1973). Entsprechend den erarbeiteten Spezifikationen sollte das System aus den folgenden Komponenten bestehen:  Anwendungsprogramme  Steuerung der Anwendungsprogramme  Sammlung von Unterprogrammen mit Funktionen, die von den Anwendungsprogrammen immer wieder benötigt wurden  Verwaltung der EMFIS-spezifischen Daten  Steuerung der EMFIS-spezifischen Ein-/Ausgabefunktionen  Steuerung der abgesetzten E/A-Geräte (z. B. Sichtgeräte). Diese Komponenten wurden zu Programmen zusammengefasst, die dann im Mehrprogrammbetrieb, vom Betriebssystem gesteuert, ablaufen sollten. Die Anordnung der Programme bzw. Programmteile im Hauptspeicher ist in Abb. 1.1 dargestellt. Die Zahl in der rechten unteren Ecke gibt die Hauptspeichergröße an, die der Komponente zugewiesen wurde. Sehr bald stellte sich aber heraus, dass keine der Komponenten mit dem zugewiesenen Speicherplatz auskam. Deshalb mussten weitere 256 KB Hauptspeicher beschafft werden, nachdem vorhandene Hardware für diese Hochrüstung umgebaut worden war. Datenübertragungsprogramm (DP). Dieses Programm wurde aus vom Hersteller bereitgestellten Makros generiert. Mit diesen Makros wurde die Hardwarekonfiguration beschrieben, die sich „hinter“ der Datenübertragungssteuerung befand (also Sichtgeräte und Drucker, aber auch Art des Anschlusses dieser Geräte, Leitungsgeschwindigkeiten und verwendete Protokolle). Input Output Coordinator (IOC). Dieses Programm war für alle Ein-/Ausgaben zuständig, gleich, ob es sich um lokale oder abgesetzte Geräte handelte. Das IOC

PBS (Betriebssystem) 10 KB Datenübertragungsprogramm (DP) 50 KB Input Output Coordinator (IOC) 40 KB Data Base Operating Program (DBOP) 40 KB Transaction Processing Executive (TP Exec)

Transaction Processing Area

20 KB Data Manipulation Subroutines (DMS) 20 KB Initial Transaction Overlay Region (ITOR) 24 KB Transaction Overlay Region 1 (TOR1) 24 KB Transaction Overlay Region 2 (TOR2) 24 KB

Abb. 1.1 Die Komponenten von EMFIS

1 Einführung

11

empfing Daten vom DP bzw. von den lokalen Geräten (außer Plattenspeichern) und leitete sie an den Transaction Processing Executive weiter und umgekehrt. Data Base Operating Program (DBOP). Das DBOP realisierte ein Datenbankverwaltungssystem. Das relationale Datenbankmodell war noch nicht veröffentlicht und bezahlbare Systeme, die auf anderen Datenbankarchitekturen basierten, waren auf dem Markt nicht zu finden. Transaction Processing Area (TPA). In der TPA war lediglich das Transaction Processing Executive (TP EXEC) mit den Data Manipulation Subroutines (DMS) als Anhängsel als Programm geladen. Daneben gab es noch drei Hauptspeicherbereiche, ITOR, TOR1 und TOR2, in die vom TP EXEC bei Bedarf weiterer Programmcode geladen und ausgeführt wurde. Es gab sieben solcher Programme (BISP, Basic Information System Program):  Programm zur Bearbeitung der Kommandos des EMFIS-Systemadministrators. Dieses Programm lief immer im ITOR-Bereich ab.  Programm, das eine erste Überprüfung der Eingaben, die ein EMFIS-Benutzer am Sichtgerät gemacht hatte, durchführte. Eingaben wurden immer in so genannte Formate gemacht.  Programm, das die Fehlerbehandlung übernahm, wenn bei der Bearbeitung solcher Formatinhalte Fehler auftraten.  zwei Programme, die die durch die Formatbearbeitung notwendigen Operationen in der Datenbank initiierten. Dabei war eines für das Bereitstellen von Daten aus der Datenbank und das andere für das Update der Datenbank zuständig.  Programm, das für das Sortieren, Mischen und Summieren von Daten im Hauptspeicher zuständig war.  Programm, das die Daten, die das Ergebnis der Bearbeitung eines Formates vom Abfragetyp waren, für die Ausgabe auf dem Sichtgerät und/oder einem abgesetzten oder lokalen Drucker aufbereitete. Alle Bearbeitungsaufträge für EMFIS wurden durch Ausfüllen von vorgegebenen Formaten beschrieben. Es gab zwei Typen von Formaten: Abfragen und Meldungen. Mit Abfragen konnten Daten aus der Datenbank erfragt werden, mit Meldungen die Daten in der Datenbank auf den neuesten Stand gebracht werden. Die Bearbeitung der Formate wurde zunächst offline in einer speziell für EMFIS definierten Sprache EPOS (EMFIS ProblemOrientierte Sprache) beschrieben. Diese Bearbeitungsvorschriften wurden dann mittels eines Compilers in einen Zwischencode übersetzt und auf den Plattenspeichern gesichert. Wenn dann die Bearbeitung des entsprechenden Formates bzw. der vom Benutzer in den Feldern des Formates gemachten Angaben anstand, wurde dieser Zwischencode vom Hintergrundspeicher in den Hauptspeicher geladen, von den BISPs entsprechend interpretiert und so das Format mit seinen Inhalten bearbeitet. Neben den BISPs gab es noch Spezialprogramme – z. B. ein Programm zur Erzeugung einer Lagedarstellung auf einem Plotter – deren Funktionen nicht in EPOS formulierbar waren und deshalb in Assembler oder FORTRAN geschrieben waren, aber aus EPOS-Programmen heraus aufrufbar waren.

12

S. Söffing, G. Bühler und M. Wunder

Nachdem sich 1974 der Bundesrechnungshof in seinem Prüfbericht sehr kritisch zu den hohen Ausgaben für die Entwicklung von Führungsinformationssystemen im Bereich der Bundeswehr geäußert hatte und u. a. die sofortige Einstellung der Entwicklung von EMFIS gefordert hatte, hatte dies natürlich auch Auswirkungen auf die Abteilung RuF und deren Arbeiten: die Abteilung wurde verkleinert und die Entwicklung von EMFIS hin zu einem operativen System wurde eingestellt. Allerdings lebte EMFIS unter neuem Etikett weiter: für den Einsatz bei Alarmierung und Mobilmachung wurden neue EPOS-Programme geschrieben und zusammen mit der Systemsoftware von EMFIS entstand so VAMOG (Verfahren zur Unterstützung der Alarmierung, Mobilmachung und der Operationellen Grundlagen). An dieses System waren über Datenleitungen verschiedene Referate bzw. Dienststellen des Verteidigungsministeriums, des Innenministeriums und des Bundeskanzleramtes angeschlossen. Außerdem kam VAMOG regelmäßig an den zu dieser Zeit üblichen WINTEX-Übungen zum Einsatz. Als die Firma Siemens die Wartung für das Betriebssystem BS1000 einstellte, wurde das System von Mitarbeitern der Abteilung RuF auf das Betriebssystem BS2000 portiert und so der Einsatz von VAMOG für weitere Jahre gesichert. Während des Aufbaus von EMFIS war die Kopplung mit anderen Systemen sehr oft ein wichtiges Thema. Es blieb bei Überlegungen, da sich die zu koppelnden Systeme auf die proprietären Übertragungsprotokolle der Herstellerfirmen der Rechner stützten. Bei verschiedenen USA-Reisen hatten Mitarbeiter der Abteilung RuF Bekanntschaft mit dem Arpanet (Advanced Research Projects Agency Network) und seinen Protokollen gemacht. Das Arpanet war im Auftrag der DARPA (Defense Advanced Research Projects Agency) aufgebaut worden und verband zu jener Zeit bereits mehrere hundert Rechner von Universitäten und Forschungsinstituten in den USA miteinander mit dem Ziel, die knappen Rechenkapazitäten durch Datenaustausch optimal zu nutzen. Das Arpanet war der Vorgänger des heutigen Internet. Im Rahmen der Forschungsarbeiten zum Arpanet wurden in den USA auch Packet Radio Networks (PRN) untersucht und entsprechende Protokolle (Jubin & Tornow, 1987) definiert. Diese Netze ließen sich problemlos als Subnetze ins Arpanet integrieren. Da solche Funknetze natürlich im militärischen Bereich von großer Bedeutung waren, erhielt die Abteilung RuF im Jahre 1982 vom BWB (Bundesamt für Wehrtechnik und Beschaffung) den Auftrag, gemeinsam mit dem Stanford Research Institute (SRI, 2008, heute SRI International), der Siemens AG und der DFVLR in Oberpfaffenhofen den Einsatz solcher Netze in Führungsinformationssystemen zu demonstrieren. Da die Hardware des PRN von SRI Frequenzen benutzte, die in der Bundesrepublik für Behörden reserviert waren, konnte ein derartiges Netz nicht in der Bundesrepublik aufgebaut werden, sondern es musste ein Netz bei SRI in den USA benutzt werden. Das Führungsinformationssystem, das eingesetzt werden sollte, war – natürlich – EMFIS. Um dieses System in den USA betreiben zu können, hätte man dort die entsprechende Hardware, einen Rechner der 7700er Reihe der Siemens AG, installieren müssen. Da dies zu aufwändig und zu teuer erschien, wurde eine andere Lösung realisiert: der „EMFIS-Rechner“ im Rechenzentrum des FFM wurde „einfach“ an das Arpanet angeschlossen, einfach allerdings nur aus

1 Einführung

13

heutiger Sicht, denn das Arpanet war in Deutschland weitgehend unbekannt und es gab höchstens eine Handvoll angeschlossener Rechner. Voraussetzung für den Anschluss eines Rechners war, dass das Betriebssystem die Arpanet-Protokolle TCP (Transmission Control Protocol) und IP (Internet Protocol) beherrschte. Da das Betriebssystem BS2000 diese Protokolle nicht kannte, wurden sie von Mitarbeitern der Zweigniederlassung Köln der Siemens AG und der Abteilung RuF implementiert. Nachdem der FGAN dann noch eine IP-Adresse zugeteilt worden war, konnte das Experiment durchgeführt werden: Auf einem Übungsgelände in Kalifornien fuhr ein Mitarbeiter der Abteilung RuF in einem LKW „spazieren“ und machte Eingaben an einem Sichtgerät vom Typ DEC VT100, die über das Arpanet zum EMFIS-Rechner im Rechenzentrum des FFM übertragen und dort verarbeitet wurden. Nach geraumer Zeit erhielt der EMFIS-Bediener auf seinem LKW auf dem gleichen Weg eine Antwort zurück. Übertragungstechnisch ging es über das Funknetz in den USA zu einem Gateway in das leitungsgebundene Arpanet zu einem Knoten des Atlantic Packet Satellite Network (SATNET). Von dort ging es per Satellit weiter nach Raisting nahe München und per Standleitung zur DFVLR in Oberpfaffenhofen. Von hier schließlich über eine Datex-P-Leitung zum EMFIS-Rechner in Werthhoven. Diese Arbeiten bildeten letztlich die Keimzelle für die Abteilung Kommunikation (KOM), die später aus Teilen der Abteilung RuF gebildet wurde. Zu Beginn der 80er Jahre wurde in der Abteilung RuF des FFM mit dem Aufbau des Experimentellen FührungsInformationssystems auf der Grundlage Eines Rechnernetzes (EIGER) begonnen. Ziel dabei war es, ein Testbett für verschiedene Forschungsarbeiten in der Abteilung zur Verfügung zustellen und, wenn möglich, zusammenzuführen. Zu diesen Themen zählten u. a. Schutzsysteme, Protokolle, verteilte Datenbanken, Replikationsmechanismen, Mailsysteme auf X.400-Basis, grafische Lagedarstellung, „militärischer Desktop“. Die Dislozierung der Organisationsteile der Bundeswehr legte eine verteilte Implementierung des Systems nahe. Mit Sicht auf die Hardware sollte das System aus einer Reihe von Rechnern als Verarbeitungsknoten, den Teilsystemen, bestehen, die durch ein Kommunikationssystem miteinander verbunden sind. Dabei wurden über die Rechner und deren Betriebssysteme sowie die Art der Vernetzung nur wenige Annahmen gemacht. Die Rechner von Organisationseinheiten, die auf denselben Daten arbeiten, sollten über ein lokales Netzwerk miteinander verbunden sein. Die Teilsysteme einer Organisationseinheit bildeten einen Bereich. Jedes Teilsystem bestand selbst wieder aus einer Reihe von Prozesssystemen. Im Mittelpunkt stand dabei das Kernsystem, das die zentrale Steuerungsfunktion eines Teilsystems enthielt und die eigentliche Verarbeitungskapazität eines Teilsystems zur Verfügung stellte (siehe Abb. 1.2). Jedes Teilsystem war ein Teilhabersystem, d. h. viele Benutzer sollten gleichzeitig mit dem System kommunizieren können. Der Zugang zum Teilsystem wurde dem Benutzer über das Darstellungssystem EMMI (EIGER Man Machine Interface) möglich gemacht. Jedem Benutzer war dabei ein solches Darstellungssystem zugeordnet. Das Kernsystem erzeugte bzw. verarbeitete die Daten, die von den Darstellungssystemen visualisiert wurden bzw. von ihnen als Ergebnis von Benutzerak-

14

S. Söffing, G. Bühler und M. Wunder Darstellungssystem

Mailsystem

. . .

Kernsystem

Darstellungssystem

Datenbanksystem

Abb. 1.2 Struktur eines Teilsystems

tionen angeliefert wurden. Diese Darstellungssysteme und das Kernsystem von EIGER brauchten nicht auf demselben Rechner abzulaufen, aber natürlich mussten die Rechner durch ein irgendwie geartetes Kommunikationsnetz miteinander verbunden sein. Exemplarisch wurde als Kommunikationsnetz das Internet gewählt und das Darstellungssystem als Java-Applet implementiert. Die Kernsysteme aller Teilsysteme eines Bereiches hatten Zugriff zu einer relationalen Datenbank, in der die für diese Organisationseinheit relevanten Daten gespeichert waren. Außerdem stand in jedem Bereich ein Message Handling System nach X.400 zur Verfügung, das von jedem Teilsystem des Bereiches aus erreichbar war. Im Zentrum eines Teilsystems stand das Kernsystem, das die eigentliche Verarbeitungskapazität des Systems bereitstellte. Die zentralen Komponenten waren hier die Auftragsverarbeitungen, die aufgrund der Aufträge eines Benutzers über das Darstellungssystem gestartet werden konnten (siehe Abb. 1.3). Für die Bearbeitung solcher Aufträge wurden Dienste benötigt, wie etwa Zugriffe zur Datenbank oder Zugriff auf die Felder eines Formulars im Dialogdokument. Alle diese Dienste wurden von der Komponente Auftragssteuerung erbracht. Daneben hatte die Auftragssteuerung auch die Aufgabe, die Zulässigkeit der Dienstanforderung sowie die korrekte Gruppierung von Diensten zu überwachen. Die Auftragssteuerung erbrachte allerdings die wenigsten dieser Dienste selbst, sondern nutzte dabei die Dienstleistungsangebote weiterer Komponenten eines Kernsystems: Sitzungssteuerung, Datenbank und Briefkasten. Die unterste Schicht des Kernsystems, Babsy, stellte den übrigen Komponenten allgemeine Dienste zur Verfügung. Der zentrale Teil dieser Komponente war das Basiskommunikationssystem (BKS), das den übri-

Auftrag 1

Auftragn Auftragsteuerung

BSS

Sitzungssteuerung

Datenbank

Briefkasten

Babsy Ada-Runtimesystem

Kommunikationssystemsystem Betriebssystem

Abb. 1.3 Struktur eines Kernsystems

BKS

1 Einführung

15

gen Komponenten des Kernsystems die Dienste zum gegenseitigen Datenaustausch zur Verfügung stellte. Daneben existierte noch das Basisschutzsystem (BSS), das den Datenfluss zwischen den einzelnen Komponenten überwachte und den Systemprozessen die Basismechanismen für den Aufbau eines Schutzsystems lieferte. Das System war zunächst vollständig in Ada 83 geschrieben, lediglich einige Schnittstellen wie etwa zu TCP (Transmission Control Program) waren in C entwickelt worden. Nachdem Ada 95-Compiler verfügbar waren, wurde das gesamte System einer Neustrukturierung unterzogen. Dabei wurden die Prinzipien der objektorientierten Programmierung konsequent angewandt. Im Jahre 1976 hatte der NATO-Militärausschuss die militärische Forderung nach Interoperabilität zwischen EDV-Systemen verabschiedet. Diese Forderung führte im Jahre 1980 zum Start des ATCCIS-Programms (Army Tactical Command and Control Information System, 2008), das durch den damaligen Deputy Supreme Allied Commander Europe (DSACEUR), den deutschen General Gerd Schmückle, veranlasst wurde. Dabei handelte es sich nicht um ein formales NATO-Programm, sondern um eine freiwillige und von SHAPE (Supreme Headquarters Allied Powers Europe) geförderte Aktivität der teilnehmenden Nationen. Die Aufgabe des Programms war festzustellen, ob Interoperabilität zu minimierten Kosten erreicht werden und auf der Basis von Standards, die von den teilnehmenden Nationen festgelegt und von der NATO vorgeschrieben werden, eingerichtet werden kann. Die Zielsetzung war schließlich, eine minimale Menge von Spezifikationen solcher Funktionen festzulegen, die in einem Führungsinformationssystem vorhanden sein müssen, um die Interoperabilität zwischen diesen Systemen zu gewährleisten. Die Grundidee der ATCCIS-Lösung war, den Meldungsaustausch über ADatP-3 durch einen automatisierten Informationsaustausch zu ersetzen, wobei die Anforderungen an die auszutauschende Information durch das Spektrum der Joint and Combined Land Operations vorgegeben war. Das führte einerseits zur Spezifikation eines Datenmodells, des viel beachteten ATCCIS Generic Hub (später LC2IEDM = Land Command and Control Information Exchange Data Model) und des ATCCIS-Replikationsmechanismus (ARM = ATCCIS Replication Mechanism) mit den Übertragungsprogrammen zum Austausch dieser Informationen. Während bei vielen Nationen die Ergebnisse des ATCCIS-Programms in die Entwicklung der nationalen Führungsinformationssysteme einflossen, zeigte man sich bei der Bundeswehr und der involvierten Industrie sehr zurückhaltend. Ein deutscher Offizier brachte es einmal auf den Punkt: „Datenmodell, naja; aber automatisierter Datenaustausch: niemals!“ Bereits seit Beginn des ATCCIS-Programms waren zwei Mitarbeiter der damaligen Abteilung RuF im Auftrag des BWB an der Erarbeitung dieser Spezifikationen beteiligt. Als schließlich die ATCCIS-Nationen zum „proof of concept“ durch nationale Implementierungen der Ergebnisse in ihre nationalen Führungsinformationssysteme aufgefordert worden waren, wurde im Jahre 1996 die FKIE-Abteilung ITF vom IT-Amt der Bundeswehr beauftragt, den Replikationsmechanismus im System EIGER zu implementieren und an den nachfolgenden internationalen Tests und der abschließenden Demonstration in Ede (Niederlande) teilzunehmen.

16

S. Söffing, G. Bühler und M. Wunder

Nachdem im Jahre 1998 die Ergebnisse des ATCCIS-Programms in die Arbeiten von MIP (Multilateral Interoperability Programme) eingeflossen waren, was in 2001 schließlich mit der Vereinigung der beiden Programme endete, wurde in das System EIGER auch der von MIP modifizierte Replikationsmechanismus, jetzt DEM (Data Exchange Mechanism) genannt, eingebaut und das System außerdem für die Bedürfnisse der in MIP vorgesehenen Tests abgespeckt. Das „neue“ System erhielt den Namen INFIS (Integrationsplattform für FührungsInformationsSysteme). Die Abteilung ITF hat mit dieser Implementierung der MIP-Schnittstelle in den Jahren 2004 und 2005 erfolgreich an den MIP-Interoperabilitätstests teilgenommen. Danach wurde der Protokollstack des Replikationsmechanismus aus INFIS herausgelöst und auf CORBA-Basis unter Verwendung von Java neu implementiert. Im Rahmen des Technologietransfers mit der wehrtechnischen Industrie wurde die DEMProtokollstack-Implementierung des FKIE in HEROS 2.1, 2. Los, der Firma ESG integriert.

Literaturverzeichnis ATCCIS – Army Tactical Command & Control Information System (2008). ATCCIS Web Site. www.mip-site.org/01-Atccis/ATCCIS_Home.htm. Jubin, J. & Tornow, J. (1987). The DARPA Packet Radio Network Protocols. In Proceedings of the IEEE 75 (1). MIP – Multilateral Interoperability Programme (2008a). MIP Home Page. http://www.mip-site. org. Sapper, G. R. (2008). Rechenanlage TELEFUNKEN TR4. www.qslnet.de/member/dj4kw/tr4.htm. SRI International (2008). Stanford Research Institute. http://www.sri.com/. Storz, W., Bühler, G., Göbel, R., Markmann, G., Riechmann, C., & andere (1973). Beschreibung der technischen Eigenschaften des experimentellen Führungsinformationssystems EMFIS. FFM-Bericht Nr. 194, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Zuse, H. (2008). Graphomat Z64. www.horst-zuse.homepage.t-online.de/z64.html.

Kapitel 2

Grundlagen der Interoperabilität Ulrich Schade und Michael Gerz

2.1 Einleitung Die Diskussion um die Transformation der Streitkräfte hat ihren Ursprung in der Idee, dass die in einer militärischen Operation agierenden Einheiten untereinander vernetzt sind und dass diese Vernetzung den zeitverzugsarmen Austausch von Informationen zwischen den Einheiten ermöglicht. Damit gewinnen die Einheiten einen Informationsvorsprung gegenüber einem möglichen Gegner. Dieser Vorsprung ist dann wiederum in eine verbesserte Wirkfähigkeit umzusetzen, wodurch letztlich die Effektivität des Einsatzes gesteigert wird. Neue Möglichkeiten ergeben sich z. B. dann, wenn ein Element ein Ziel erkennen und identifizieren, aber nicht selbst bekämpfen kann. Wird die gewonnene Information über dieses Ziel automatisiert einem Effektor (also einem anderen Element, welches das Ziel zwar bekämpfen, aber nicht selbst erkennen und identifizieren kann) übermittelt, so kann die Bekämpfung des Ziels direkt, also im Prinzip ohne Zeitverzögerung erfolgen. Die Vermeidung von zeitlichen Verzögerungen ist insbesondere bei Operationen in einem asymmetrischen Kontext zwingend erforderlich, weil die Gelegenheiten zur Bekämpfung von Gegnern oft schnell vergehen („fleeting opportunities“). Das Konzept der vernetzten Operationsführung geht von einer Vernetzung der Führungsinformationssysteme der beteiligten Einheiten aus, wobei dann über das Netz die Informationen ausgetauscht werden. Der Ansatz selbst ergab sich als Adaption der sogenannten Network Centric Warfare (NCW) aus dem US-amerikanischen Command and Control Research Program (CCRP). Als wichtigste grundlegende Schriften gelten dabei Network Centric Warfare (Alberts et al., 1999) und Power to the Edge (Alberts & Hayes, 2003). Die Fähigkeit von Führungsinformationssystemen, Informationen so auszutauschen, dass der Nutzer des empfangenden Systems diese Information so versteht

M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

19

20

U. Schade und M. Gerz

(und entsprechend agiert), wie dies vom Nutzer des sendenden Systems intendiert wurde, bezeichnet man als Interoperabilität der beteiligten Systeme. In diesem Kapitel sollen die Grundlagen der Interoperabilität erläutert werden. Insofern können diese dann für die folgenden Kapitel des Teil I dieses Buches als bekannt vorausgesetzt werden. Eine weiterführende Analyse von Interoperabilität bietet Teil III des Buches. Dieser präsentiert, erläutert und diskutiert dabei insbesondere die zur Erreichung von Interoperabilität vorgeschlagenen und realisierten Standards. Diese Standards sind in Teil I, in welchem Fragen der Softwarearchitektur von Führungsinformationssystemen behandelt werden, von untergeordneter Bedeutung, solange nur gewährleistet ist, dass vernetzte Führungsinformationssysteme in der Tat zueinander interoperabel sind. Die Interoperabilität von Führungsinformationssystemen ist ein komplexes Themenfeld, wobei sich diese Komplexität aus zwei Aspekten ergibt. Nach der offiziellen NATO-Definition ist Interoperabilität „the ability of systems, units, or forces to provide services to and accept services from other systems, units, or forces, and to use the services so exchanged to enable them to operate effectively together“ (vgl. Blad & Potts, 2003). Aus dieser Definition ergibt sich, dass sich Interoperabilität nicht nur auf Systeme bezieht. Es ist stets zu beachten, dass die Nutzer der Systeme unter Umständen Interoperabilitätsdefizite der von ihnen genutzten Systeme ausgleichen können, so dass Einheiten trotzdem effektiv zusammenarbeiten können. Dies setzt aber in der Regel voraus, dass die Zusammenarbeit trainiert und eingespielt ist. Bei aktuellen Einsätzen, bei denen die Einsatzkräfte von einer Koalition gestellt werden, kann davon jedoch nicht ausgegangen werden. Zur Fähigkeit, in Koalitionen zusammenzuarbeiten, bemerkte schon General Eisenhower: „History testifies to the ineptitude of coalitions in waging war. Allied failures have been so numerous and their inexcusable blunders so common that professional soldiers had long discounted the possibility of effective allied action unless available resources were so great as to assure victory by inundation.“ (Eisenhower, 1984). Da die operationelle Fähigkeit zur Zusammenarbeit der jeweiligen Nutzer nicht vorausgesetzt werden kann und da zudem gilt, dass ein hoher Grad an SystemInteroperabilität den Nutzern erlaubt, verstärkt ihren eigentlichen Aufgaben nachzugehen, ist der Fokus auf die Interoperabilität der Systeme zu setzen. Wir betrachten daher die Grundlagen der Interoperabilität von Führungsinformationssystemen. Auf die Interoperabilität zwischen Einheiten kommen wir lediglich dann zu sprechen, wenn wir fragen, wie Nutzer eventuelle Interoperabilitätsdefizite bei den Systemen ausgleichen können. Ein weiterer Aspekt, der zur Komplexität des Begriffs Interoperabilität beiträgt, betrifft die unterschiedlichen Ausprägungen, in denen Interoperabilität vorliegen bzw. nicht vorliegen kann. Im Folgenden sollen diese Ausprägungen, die Stufen der Interoperabilität, genauer betrachtet und diskutiert werden.

2 Grundlagen der Interoperabilität

21

2.2 Stufen der Interoperabilität Die Ausprägungen bzw. Stufen von Interoperabilität in Bezug auf Systeme sind als „degrees“ durch die NATO Interoperability Directive (NID) definiert. Wir werden die durch dieses Dokument vorgegebenen fünf Stufen vorstellen, diese aber in Beziehung setzen zu der Einteilung von Interoperabilität, wie sie sich aus dem Standardwerk zur NCW – Power to the Edge (Alberts & Hayes, 2003) – und aus unserer eigenen Analyse (Schade & Dürr, 2005a,b) ergibt. Die NID nennt die unterste Stufe Isolated Interoperability. Wir behandeln diese unter der Bezeichnung Fehlende Interoperabilität in Abschn. 2.3. Die nächste Stufe, die wir als Dateninteroperabilität bezeichnen, wird in der NID als Connected Interoperability geführt. Auf diese gehen wir in Abschn. 2.4 ein. Darauf folgt die Behandlung der Syntaktischen Interoperabilität (NID: Functional Interoperability) in Abschn. 2.5, die der Semantischen Interoperabilität (NID: Domain Interoperability) in Abschn. 2.6 und schließlich die der Pragmatischen Interoperabilität (NID: Enterprise Interoperability) in Abschn. 2.7.

2.3 Fehlende Interoperabilität Die NID verwendet für die niedrigste Stufe von Interoperabilität (Degree 0) die sonderbare Bezeichnung Isolated Interoperability und definiert sie als „Degree 0 – Isolated Interoperability in a Manual Environment. The key feature of Level 0 is human intervention to provide interoperability where systems are isolated from each other.“ Um Daten und Informationen austauschen zu können, müssen zwei Systeme wenigstens physikalisch miteinander verbunden sein. Ist dies nicht der Fall, muss der Austausch über eine „menschliche Drehstuhlschnittstelle“ gewährleistet werden. Der Mensch nimmt Daten, die von einem System an ein anderes übermittelt werden sollen, auf und gibt sie in das zweite System ein. Aus Systemsicht ist Interoperabilität hier nicht vorhanden; die Zusammenarbeit wird vollständig durch den Menschen sichergestellt. Fehlt die Kompensation durch den Menschen, treten massive Probleme auf: Die Einheiten sind weder in der Lage, koordiniert zu agieren, noch sind sie in der Lage, nicht intendierte Konflikte zu vermeiden. Diese können etwa dadurch auftreten, dass zwei Einheiten versuchen, auf dieselben Ressourcen zuzugreifen. Unter Umständen benötigen dabei zwei Einheiten für die Durchführung ihrer jeweiligen Aufgaben sowohl Ressource A als auch Ressource B. Verfügt nun die eine Einheit über die Ressource A und die andere über die Ressource B, so kann keine der beiden Einheiten agieren. Die Verständigung über ein koordiniertes Nutzen der Ressourcen kann nicht erfolgen, weil der Daten- und Informationsaustausch zwischen den Einheiten nicht stattfindet. Das gravierendste Problem, das sich aus der fehlenden Möglichkeit, Daten und Informationen auszutauschen, ergeben kann, ist „friendly fire“.

22

U. Schade und M. Gerz

2.4 Dateninteroperabilität Die grundlegende Bedingung für die Interoperabilität von Systemen ist also, dass diese physikalisch verbunden sind und über ihre Verbindung Daten austauschen. Entsprechend der NID ergibt sich daraus die nächste Stufe der Interoperabilität, welche wie folgt definiert ist: „Degree 1 – Connected Interoperability in a Peer-to-Peer Environment. The key feature of Degree 1 is physical connectivity providing direct interaction between systems.“ Die Gewährleistung eines Datenaustauschs zwischen zwei Systemen bedeutet allerdings nicht, dass das Empfänger-System die eingehenden Daten in irgendeiner Art und Weise verarbeiten kann. Beispielsweise könnte es eine Datei empfangen, für deren Ansicht (oder Entpackung) ihm die notwendige Funktionalität fehlt. Zwar ist es möglich, eine Datei mit einem einfachen Texteditor zu öffnen, allerdings ist deren Inhalt möglicherweise nicht lesbar bzw. zur automatisierten Weiterverarbeitung ungeeignet. Unter Umständen kann der Nutzer auch in diesem Fall dem Interoperabilitätsdefizit entgegen wirken, indem er etwa eine Konvertierung der entsprechenden Datei in ein Format durchführt, das im Empfänger-System die weitere Verarbeitung erlaubt. Die Fähigkeiten der Nutzer gewährleisten also häufig, dass Teileinheiten als Gesamtkraft wirken, sofern sie nur verbunden und damit technisch in der Lage sind, Daten auszutauschen. Scheitern kann das Zusammenwirken in Bezug auf Einheiten trotz einer existierenden Verbindung aber noch an unterschiedlichen Sprachen. Entsprechend formulieren Alberts & Hayes (2003, S. 122ff.), die weniger auf die Systeminteroperabilität als vielmehr auf die Interoperabilität zwischen den Einheiten selbst fokussieren, folgende Möglichkeiten zum Erreichen einer höheren Interoperabilitätsstufe:  Informationsaustausch in einer Sprache, die sowohl Sender als auch Empfänger beherrschen.  Informationsaustausch vermittelt durch eine Übersetzung von der Sprache des Senders in die Sprache des Empfängers.  Nutzung einer Referenzsprache, die sowohl dem Sender als auch dem Empfänger über Übersetzungen zugänglich ist. In sogenannten „combined operations“, die von Einheiten mehrerer Nationen durchgeführt werden, wird häufig Englisch als eine Referenzsprache angesehen, wobei aber anzumerken ist, dass auch Unterschiede in den Kenntnissen dieser Referenzsprache Probleme nach sich ziehen können. Trotzdem bietet der Bezug auf die Sprache eine angemessene Möglichkeit, auch hinsichtlich Systemen darzulegen, was die Stufen der Interoperabilität ausmacht, die über die reine Dateninteroperabilität hinausgehen.

2 Grundlagen der Interoperabilität

23

2.5 Syntaktische Interoperabilität Liegt Dateninteroperabilität vor, so ergibt sich die nächste Interoperabilitätsstufe aus der Anforderung, dass die vom Sender übermittelten Daten auch direkt vom Empfänger verwendet und weiterverarbeitet werden können. In der NID heißt es dazu: „Degree 2 – Functional Interoperability in a Distributed Environment. The key feature of Degree 2 is the ability of independent applications to exchange and use independent data components in a direct or distributed manner among systems.“ Der wichtige Aspekt in Bezug auf diese Stufe der Interoperabilität ist also, dass die ausgetauschten Daten und Informationen funktional sind. Die Bezeichnungen der NID für die Stufe 1 (connected interoperability) und die Stufe 2 (functional interoperability) sind also durchaus angemessen. Da aber die Bezeichnungen für die folgenden Stufen weniger angemessen sind und weniger Erklärungspotential bieten, soll hier der Bezug auf Sprache als Austauschmedium genutzt werden. Die Stufen werden entsprechend mit den linguistischen Termen als syntaktisch, semantisch und pragmatisch bezeichnet. Die Stufe der syntaktischen Interoperabilität entspricht dabei der Stufe 2 der NID. Syntaktische Interoperabilität besagt, dass die Struktur bzw. das Format, in dem die Daten ausgetauscht werden, festgelegt ist. In Bezug auf eine natürliche Sprache heißt dies, dass festgelegt ist, welche Wörter verwendet werden und nach welchen Regeln diese zu Sätzen verknüpft werden. In Bezug auf Systeme gilt im Prinzip dasselbe: Das Datenaustauschformat wird vorgegeben, etwa durch ein XMLSchema. Ein Beispiel für einen solchen auf XML aufsetzenden Ansatz bietet die in Abschn. 18.6 vorgestellte Military Scenario Description Language. Daten, die unter dieser Voraussetzung ausgetauscht werden, können damit durch das empfangende System genutzt werden. Unklar bleibt auf dieser Stufe aber noch die Bedeutung der ausgetauschten Information. Für zahlreiche Anwendungen jedoch genügt genau diese Stufe der Interoperabilität, nämlich dann, wenn die Interpretation der ausgetauschten Daten bei der Weiterverarbeitung ausschließlich durch den Nutzer erfolgt.

2.6 Semantische Interoperabilität Die dritte Stufe der Interoperabilität fordert, dass Systeme Informationen nicht nur so austauschen, dass eine Weiterverarbeitung erfolgen kann, sondern dass die Interpretation der ausgetauschten Informationen durch Sender und Empfänger gleich ist. Hierfür wird z. B. bei Heflin & Hendler (2000) und Wikipedia (2009a) der Begriff semantische Interoperabilität verwendet. Die Bezeichnung Syntax zielt auf die Struktur und der Begriff Semantik auf die Bedeutung eines Ausdrucks. In Bezug auf

24

U. Schade und M. Gerz

Interoperabilität geht es also um ein strukturell einheitliches (syntaktische Interoperabilität) bzw. um ein inhaltlich einheitliches Verständnis (semantische Interoperabilität) von ausgetauschten Daten. Aus der Definition der NID ist dies nur bedingt erkennbar: „Degree 3 – Domain Interoperability in an Integrated Environment. The key feature of Degree 3 is a domain perspective that includes domain data models and procedures where data is shared among the independent applications which may begin to work together in an integrated fashion.“ Es ist korrekt, dass Führungsinformationssysteme, die semantisch interoperabel sind, „integrativer“ zusammenarbeiten können. Dies ist letztlich ja auch das Ziel der Herstellung von möglichst umfassender Interoperabilität. Es ist auch korrekt, dass ein einheitliches Datenmodell bei diesem Unterfangen sehr hilfreich ist, da dann die ausgetauschten Informationen unter Bezug auf dieses Datenmodell interpretiert werden können. Das Joint C3 Information Exchange Data Model (JC3IEDM; siehe Kap. 16) stellt beispielsweise für alle Entitäten, Attribute und Domänwerte eine Definition zur Verfügung, die zumindest dem menschlichen Nutzer eindeutig vorgibt, wie diese zu verstehen sind. Diesem Grundgedanken entspricht auch die Rahmenregelung zur Datenmodellierung und zum Einrichten einer Datenmanagementorganisation der Bundeswehr: „Um grundlegend Interoperabilität zwischen InfoSys sicherzustellen, dient das Kerndatenmodell Bw als Referenzmodell für die Beschreibung von Daten im Rahmen der Datenmanagementorganisation“ (BMVg – IT Direktor, 2005). Dieser Ansatz ist jedoch nur mit Mühe zu verwirklichen. Zunächst einmal ist es entwicklungshistorisch schwierig, für unterschiedliche, vorliegende Systeme im Nachhinein durchzusetzen, dass diese ein gemeinsames Datenmodell nutzen. Aber auch wenn zwei Systeme auf der Grundlage desselben Datenmodells arbeiten, bedeutet dies noch nicht, dass sie die ausgetauschten Informationen in derselben Weise auswerten, weil häufig Definitionen zwar durch Dokumentationen erfasst sind, sie aber nicht für die Systeme explizit umgesetzt werden. Beispielsweise lautet im Standarddatenmodell JC3IEDM für das Attribut landweapon-type-category-code die Definition des Wertes tank: „An armoured vehicle whose principle weapon is a direct fire gun optimised for the destruction of armoured vehicles.“ Nach dieser Definition ist ein Panzer unter anderem ein Fahrzeug. In der expliziten Auflistung aller Fahrzeugtypen (siehe dazu die Werte des Attributs vehicle-type-category-code) sind Panzer aber ausdrücklich ausgeschlossen. Die explizite Implementierung widerspricht damit der in der Dokumentation vorgegebenen Definition des Wertes. Entsprechend kann ein Führungsinformationssystem Folgerungen, die für Fahrzeuge gelten, z. B. Abschätzungen darüber, wie weit sie sich bei gegebenem Straßennetz in einer bestimmten Zeit bewegen können, zunächst einmal nicht auf Panzer anwenden. Generell gilt, dass alles, was nicht explizit implementiert ist, auch nicht zur semantischen Interoperabilität zwischen den Systemen beiträgt. Die semantische Festlegung von Werten durch ein Dokument, ohne dass solches explizit gemacht wird, ist für automatisierte Prozesse in den Systemen wertlos.

2 Grundlagen der Interoperabilität

25

Semantische Interoperabilität geht über die Nutzung eines gemeinsamen Datenmodells hinaus. Es genügt nicht, dass die Bedeutung eines jeden verwendeten Terms im gemeinsamen Datenmodell definiert ist. Auch die Verknüpfung der Terme, also etwa deren Nutzung innerhalb eines vorgegebenen XML-Schemas, muss so festgelegt sein, dass sich für die beteiligten Systeme die Gesamtbedeutung der ausgetauschten Information eindeutig aus den durch das Datenmodell festgelegten Einzelbedeutungen ergibt. Alberts & Hayes (2003, Kapitel 7) ordnen den Prozess, der einer Information ihre Bedeutung zuordnet, dem kognitiven Bereich („cognitive domain“) zu. Sie erklären entsprechend: „Level 3 [of interoperability] requires that entities be interoperable not only in the information domain, but also in the cognitive domain, so that shared awareness can be achieved.“ (ebd., Seite 110) Das Erreichen der semantischen Interoperabilität setzt allerdings noch nicht voraus, dass der Empfänger auf der Grundlage der erhaltenen Information genau so handelt, wie dies vom Sender intendiert ist. Welche Handlung eine Information auslösen kann, hängt bei Menschen – und damit auch bei Organisationen – nicht nur von der Bedeutung der Information, sondern auch von sozialen und kulturellen Gesichtspunkten, Erfahrungen und Einstellungen ab. So kann beispielsweise die Information, dass an einer bestimmten Stelle Verwundete liegen, je nach sozialer und kultureller Einstellung als Aufforderung verstanden werden, diese zu retten, oder aber auch als Warnung, sich an diese Position zu begeben. Die Zuordnung der reinen Bedeutung zu der Information ist dabei in beiden Fällen gleich.

2.7 Pragmatische Interoperabilität Die pragmatische Interoperabilität bildet – wenn auch jeweils unter anderem Namen – in der NID und in der Klassifikation von Alberts und Hayes die höchste Stufe von Interoperabilität. Sie bezieht sich nicht nur auf die Zuordnung von Bedeutung, sondern auch auf ein identisches Verständnis davon, zu welchen Handlungen die Information führt. Erst pragmatische Interoperabilität schafft also die Grundlage für das nahtlose Zusammenwirken von Systemen bzw. von militärischen Einheiten. Dies ist allerdings aus der Definition nach NID kaum zu entnehmen: „Degree 4 – Enterprise Interoperability in a Universal Environment. The key feature of Degree 4 is a top-level perspective that includes enterprise data models and procedures, where data is seamlessly shared among the applications that work together across domains in a universal access environment.“ Im Gegensatz dazu definieren Alberts und Hayes pragmatische Interoperabilität genau in dem von uns genannten Sinn: „Level 4 requires interoperability in the social domain so that actions can be dynamically self-synchronized.“ (Alberts & Hayes, 2003, Seite 110)

26

U. Schade und M. Gerz

Pragmatische Interoperabilität bedeutet für Systeme somit, dass sie in einer Art und Weise operieren, als seien sie Module eines übergeordneten Gesamtsystems. Führungsinformationssysteme, die derart verknüpft sind, können als Instanzen eines einzigen Führungsinformationssystems angesehen werden, welches die Gesamtoperation optimal unterstützt.

Literaturverzeichnis Alberts, D. S., Garstka, J. J., & Stein, F. P. (1999). Network Centric Warfare. Washington, DC: CCRP. Alberts, D. S. & Hayes, R. E. (2003). Power to the Edge. Washington, DC: CCRP. Blad, T. & Potts, D. (2003). The Big Issue: Command and Combat in the Information Age, chapter Beyond Interoperability: Part 1, (pp. 139–150). CCRP: Washington, DC. BMVg – IT Direktor (2005). Rahmenregelung zur Datenmodellierung und zum Einrichten einer Datenmanagementorganisation der Bundeswehr. Eisenhower, D. D. (1984). Crusade in Europe. New York: Doubleday. Heflin, J. & Hendler, J. A. (2000). Semantic Interoperability on the Web. In Proceedings of Extreme Markup Languages Alexandria, VA, USA. Schade, U. & Dürr, G. (2005a). Die Stufen der Interoperabilität. Strategie und Technik, 1-2005, 16–18. Schade, U. & Dürr, G. (2005b). Over the Edge: Die Stufen der Interoperabilität II. Strategie und Technik, 9-2005, 39–41. Wikipedia (2009a). Semantic Interoperability. http://en.wikipedia.org/wiki/Semantic_ interoperability (13.01.2009).

Kapitel 3

Konzeption verteilter Führungsinformationssysteme Marc Spielmann

3.1 Einleitung Das veränderte Einsatz- und Aufgabenspektrum der Bundeswehr erfordert die Entwicklung neuer Führungsinformationssysteme (FüInfoSys). Waren in der Vergangenheit eher klassische Einsatzszenarien („vaterländischer Krieg“) zu unterstützen – die Systeme wurden für umfangreiche, dafür aber auch relativ statische Führungshierarchien mit festgelegten Informationsaustauschbeziehungen und Geschäftsprozessen konzipiert – so haben sich die Anforderungen an FüInfoSys heute grundlegend gewandelt. Die zu unterstützenden Führungshierarchien sind flacher und flexibler geworden. Zum Teil ergibt sich der Informations- und Unterstützungsbedarf der eingebundenen Elemente (Personen, Organisationseinheiten, Truppenteile, Sensoren, Effektoren etc.) ad hoc aus der Situation heraus mit der Konsequenz, dass Informationsaustauschbeziehungen und Geschäftsprozesse von den Systemen dynamisch – also insbesondere zur Laufzeit – neu eingerichtet oder in modifizierter Form unterstützt werden müssen. Kurzum, die Systeme müssen sich zur Laufzeit strukturell umkonfigurieren lassen. Die Anforderungen an FüInfoSys werden verschärft durch den Umstand, dass die heutige Einsatzrealität multinational (combined) und teilstreitkräfteübergreifend (joint) ist, wodurch insbesondere die Frage nach der Interoperabilität (vgl. Kap. 2) der Systeme an Bedeutung gewinnt. Der Begriff „Interoperabilität“ zielt dabei nicht nur auf den semantisch korrekten Austausch von Daten zwischen den Systemen. Letztendlich ist für den Nutzer die korrekte Abwicklung von Geschäftsprozessen wichtig. Da sich viele Geschäftsprozesse aber über Systemgrenzen hinweg erstrecken, ist aus Sicht des Nutzers vor allem die semantisch korrekte Verzahnung von (Teil-)Geschäftsprozessen an den Systemgrenzen wichtig. Bei der Konzeption und Entwicklung zukünftiger FüInfoSys muss also nicht nur der veränderte Informations- und Unterstützungsbedarf der Nutzer berücksichtigt werden. Es gilt, die technische Voraussetzung für die Interoperabilität der Systeme im Sinne einer semantisch-prozeduralen Integration zu schaffen.

M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

27

28

M. Spielmann

Eine weitere Problematik ergibt sich aus den verschiedenen Anforderungen an FüInfoSys selbst. Bestimmte Anforderungen sind scheinbar widersprüchlich: Einerseits soll gemäß des Konzeptes der Vernetzten Operationsführung (NetOpFü; BMVg, 2006) ein gemeinsamer virtueller Informationsraum geschaffen werden. Andererseits muss auf der taktischen Ebene mit Kommunikationsproblemen bis hin zum Totalausfall einzelner Verbindungen gerechnet werden, so dass sich das Entstehen verschiedener, teilweise inkonsistenter „Informationsinseln“ kaum vermeiden lässt. Eine weitere Diskrepanz betrifft die üblichen Qualitätsanforderungen, wie z. B. Verfügbarkeit, Fehlertoleranz, Sicherheit, Skalierbarkeit, Performanz, Wartbarkeit etc. Um diesen Anforderungen nachzukommen, sollte eine möglichst zentrale Datenhaltung angestrebt werden. Auf der anderen Seite besteht die Forderung nach zeitweise autarken Installationen oder Endgeräten (vgl. z. B. IT-AmtBw & Heeresamt, 2004), eine Forderung, die nur mit einer – zumindest zeitweise – verteilten Datenhaltung realisierbar ist. Aufgrund der Vielzahl der Anforderungen und der vermeintlichen Widersprüchlichkeit bestimmter Anforderungen wurden in der Vergangenheit die Konzeption und Entwicklung von FüInfoSys teilstreitkräfte- und/oder ebenenspezifisch ausgerichtet. Dabei wurden wichtige technische Fragestellungen hinsichtlich einer späteren Integration der verschiedenen Systeme nur nachrangig behandelt oder ganz vernachlässigt, nicht zuletzt aufgrund beschleunigter Beschaffungsprozesse. Eine nachträgliche Harmonisierung (im Sinne einer sukzessiven Anpassung) von getrennt entwickelten Systemen gestaltet sich aber im Allgemeinen schwierig. Häufig verhindert eine mangelnde oder technisch nicht mögliche bzw. nachträglich zu kostspielige Angleichung von Datenmodellen, Schnittstellenformaten und Protokollen einen semantisch-konsistenten Informationsaustausch zwischen den Systemen und damit auch die notwendige Verzahnung der durch die einzelnen Systeme unterstützten (Teil-)Geschäftsprozesse. Interoperabilität durch frühzeitige Abstimmung Es stellt sich die Frage, wie in Zukunft die technische Voraussetzung für die Interoperabilität der Systeme geschaffen bzw. angestrebt werden kann. Dabei muss insbesondere berücksichtigt werden, dass die Systeme aufgrund ihrer Komplexität im Rahmen verschiedener Konzeptions- und Entwicklungsprozesse entstehen und diese Prozesse aufgrund unterschiedlicher zeitlicher, monetärer, technischer oder kundenspezifischer Anforderungen nur schwer korreliert werden können. Neben organisatorischen Maßnahmen (welche außerhalb des Fokus dieses Beitrags liegen) ist die folgende technische Maßnahme von zentraler Bedeutung: Es muss eine frühzeitige Abstimmung der Systemarchitekturen der zu integrierenden Systeme stattfinden. Dies kann auf vielfältige Weise geschehen, beispielsweise mittels eines detaillierten technischen Abgleichs der verschiedenen Systemarchitekturen mit besonderem Augenmerk auf Systemschnittstellen. Sind die Systeme sehr komplex und befinden sich diese jeweils in verschiedenen Konzeptions- und Entwicklungsphasen, so scheidet diese Möglichkeit allerdings aus, da sich die einzelnen Systemarchitekturen in der Regel ebenfalls in verschiedenen Entwicklungsphasen befinden, sowohl

3 Konzeption verteilter Führungsinformationssysteme

29

hinsichtlich ihres jeweiligen Detaillierungsgrads als auch hinsichtlich ihres jeweiligen Entwicklungsstandes. (Die Architektur eines Systems zeichnet ein abstraktes Bild der Hard- und Software des betrachteten Systems. Ändern sich Nutzerforderungen oder Randbedingungen, so unterliegt die Architektur – wie das System selbst – einem evolutionären Prozess. Es lässt sich eine Analogie zu militärischen Operationen herstellen: Ähnlich wie bei der Entwicklung einer Systemarchitektur gibt es auch bei der ebenenübergreifenden Befehlsgebung im Rahmen einer militärischen Operation verschiedene Detaillierungsgrade und Entwicklungsstände. Diese sind notwendig, um die verschiedenen Zielsetzungen und zeitlichen Entwicklungen von Teiloperationen, welche es zu koordinieren gilt, adäquat beschreiben zu können. Vergleiche auch Kap. 11.) In einer solchen Situation bietet es sich an, eine Architekturstrategie zu entwickeln (vergleichbar mit einer Strategie zur Durchführung einer militärischen Operation), welche einen allgemeinen Rahmen für die Entwicklung der Systemarchitekturen der später zu integrierenden Systeme bietet. Eine solche Architekturstrategie könnte beispielsweise eine bestimmte Grundgliederung für die noch zu entwickelnden Systemarchitekturen vorgeben. Dabei könnten Schnittstellen zwischen einzelnen Komponenten, Schichten oder (Teil-)Systemen (vor-)spezifiziert werden, je nach Bedarf bis zu einem bestimmten Detaillierungsgrad. Die entsprechenden Schnittstellenbeschreibungen könnten die Verwendung bestimmter Schnittstellenformate, Protokolle oder Datenmodelle vorschreiben. Dort, wo es der Architekturstrategie nicht möglich ist, detaillierte technische Vorgaben zu formulieren (z. B. weil diese erst zum Zeitpunkt einer Systemarchitekturentwicklung oder gar einer Systementwicklung bestimmt werden können), könnten geeignete Abstimmungsprozesse vorgeschrieben werden. Denkbar wären beispielsweise Abstimmungsprozesse zwischen den Design- und Entwicklungsteams zweier Systeme zusammen mit Vertretern des Architekturstrategieteams. Durch solche Maßnahmen ließen sich potentielle semantisch-prozedurale „Brüche“ an Systemgrenzen frühzeitig erkennen, ggf. bewerten und im Rahmen von Abstimmungsprozessen beheben oder zumindest in kontrollierter Art und Weise überbrücken. Grundsätzlich könnte eine solche Architekturstrategie als Treiber langfristiger, mittelfristiger und kurzfristiger Architekturentscheidungen fungieren. Architekturrahmen für die Entwicklung von Softwarearchitekturen In diesem Beitrag wird eine übergeordnete Softwarearchitektur als ein möglicher Bestandteil einer solchen noch zu erarbeitenden Architekturstrategie vorgestellt. Die übergeordnete Softwarearchitektur kann auch als Architekturrahmen für die Entwicklung der Softwarearchitekturen der später zu integrierenden Systeme gesehen werden: Durch sukzessive Verfeinerung und Instantiierung lässt sich die übergeordnete Softwarearchitektur in die konkreten Softwarearchitekturen teilstreitkräfteund/oder ebenenspezifischer FüInfoSys überführen. Die Zugrundelegung eines solchen Architekturrahmens bei der Konzeption und Entwicklung von FüInfoSys verspricht den folgenden Mehrwert: Die auf dem Rahmen basierenden FüInfoSys sind nach einem ähnlichen Grundmuster aufgebaut,

30

M. Spielmann

d. h. die Systeme setzen sich aus ähnlichen funktional-logischen Einheiten (Komponenten) in ähnlicher Weise zusammen. Dadurch kann eine gewisse Gleichartigkeit bzw. Vergleichbarkeit sowohl der verschiedenen Sichten (Abstraktionen) als auch der internen und externen Schnittstellen der Systeme erreicht werden. Dies ist für projektübergreifende Abstimmungsprozesse von zentraler Bedeutung. Darüber hinaus wird so der Wiederverwendbarkeit einzelner Systemkomponenten Vorschub geleistet, da sich bestimmte funktional-logische Einheiten ggf. in Form von Standardservices implementieren und bereitstellen lassen. Bemerkung. Der hier vorgestellte Architekturrahmen – die übergeordnete Softwarearchitektur – ist nicht mit einem Architekturrahmenwerk (vgl. Kap. 15) zu verwechseln. Architekturrahmenwerke bieten allgemeine Methodiken und Formalismen (z. B. Vorgehens- und Beschreibungsmodelle) zur Entwicklung und Darstellung von Systemarchitekturen. Sie stellen jedoch keine konkreten funktionalen, technischen oder operationellen Anforderungen an die mit ihrer Hilfe zu entwickelnden bzw. darzustellenden Architekturen. Die übergeordnete Softwarearchitektur hingegen formuliert derartige Anforderungen als Rahmen für die Entwicklung von FüInfoSys-Softwarearchitekturen, ohne dafür ein bestimmtes Architekturrahmenwerk heranzuziehen. Bei Bedarf kann für die Beschreibung der übergeordneten Softwarearchitektur ein solches Architekturrahmenwerk (z. B. das NATO Architecture Framework, kurz NAF; vgl. Kap. 15) verwendet werden. Gliederung. Der Rest des Beitrags ist wie folgt gegliedert: Im nächsten Abschnitt werden eine Reihe grundlegender Anforderungen an FüInfoSys formuliert. Diese dienen dann in Absch. 3.3 als Randbedingungen für die Entwicklung der übergeordneten Softwarearchitektur. Der Beitrag schließt mit einer kurzen Zusammenfassung in Abschn. 3.4.

3.2 Allgemeine Anforderungen an FüInfoSys Die zu entwickelnde übergeordnete Softwarearchitektur soll einen möglichst konkreten Rahmen für die Herleitung von FüInfoSys-Softwarearchitekturen bieten und sollte demzufolge möglichst viele Anforderungen der später zu integrierenden Systeme berücksichtigen. Wie aber in der Einleitung bereits angedeutet wurde sind die Anforderungen an die verschiedenen teilstreitkräfte- und/oder ebenenspezifischen FüInfoSys sehr vielfältig und zum Teil widersprüchlich. Folglich können diese systemspezifischen Anforderungen in Gänze nicht als Basis für die Entwicklung der übergeordneten Architektur dienen. Allerdings ergeben sich viele der systemspezifischen Anforderungen nicht unmittelbar aus technischen Randbedingungen, sondern werden aufgrund zeitlicher oder monetärer Randbedingungen bei der Projektierung der Systeme formuliert. Beispielsweise ist es nicht erforderlich, ein FüInfoSys, welches primär auf der strategischen und den oberen operativen Führungsebenen eingesetzt wird, mit Endgeräten auszustatten, die zeitweise autark betrieben werden können.

3 Konzeption verteilter Führungsinformationssysteme

31

In diesem Abschnitt werden allgemeine (technische) Anforderungen an FüInfoSys formuliert. Die Anforderungen bringen entweder grundsätzliche Eigenschaften von FüInfoSys zum Ausdruck oder reflektieren ebenenspezifische Randbedingungen für die Entwicklung einzelner FüInfoSys. Zugleich ist die Gesamtheit dieser Anforderungen (noch) nicht widersprüchlich und kann somit als Ausgangspunkt für die Entwicklung der übergeordneten Architektur dienen. Es sei angemerkt, dass, obwohl die übergeordnete Architektur die Gesamtheit der Anforderungen erfüllt, dies nicht zwingend auch für die aus der übergeordneten Architektur ableitbaren systemspezifischen Architekturen gelten muss. Vielmehr kann bei der Herleitung einer systemspezifischen Architektur auf die Umsetzung einzelner Anforderungen verzichtet werden, falls dies aufgrund konkreter Projektvorgaben notwendig wird.

3.2.1 Situationsbezogener Zugang zu heterogenen Quellen Eine zentrale technologische Forderung von NetOpFü ist die Schaffung eines gemeinsamen Informationsraumes. Hintergrund ist der durch die Transformation der Streitkräfte eingeleitete Paradigmenwechsel, bei dem neue Einsatzszenarien mit sehr flachen und äußerst flexiblen Führungshierarchien in den Vordergrund rücken. Dementsprechend wird eine weitere Flexibilisierung der Kommunikations- und ITSysteme gefordert, mit dem Ziel, jeden Nutzer (hier: Person, Rolle, Organisationseinheit, Truppenteil, Sensor, Effektor etc.) mit  jedem anderen Nutzer und  jeder vom System bereitgestellten Funktionalität (Service) verbinden zu können, wenn die jeweilige Situation und der Kontext der Arbeitsabläufe dies erfordern und wenn die vorhandenen Kommunikationsmittel dies grundsätzlich zulassen. Selbst wenn der hiermit implizit geforderte Grad an Konnektivität und Verfügbarkeit mit den heute zur Verfügung stehenden Kommunikationsmitteln nicht erreicht werden kann, sollte bei der Konzeption und Entwicklung zukünftiger FüInfoSys dieses Ziel für einen möglichst großen Nutzerkreis angestrebt werden. Klammern wir die Kommunikationsproblematik aus – diese ist Gegenstand von Abschn. 3.2.3 – und interpretieren wir das Verbinden von Nutzern mit anderen Nutzern als eine spezielle Form von FüInfoSys-Funktionalität, so lässt sich die folgende Anforderung an FüInfoSys formulieren: Situationsbezogener Zugang zu heterogenen Quellen. Jeder Nutzer muss Zugang zu jeder vom System bereitgestellten Funktionalität (Service) erhalten können, wenn die jeweilige Situation und der Kontext der Arbeitsabläufe dies erfordern. Eine attraktive, weil kostengünstige und technisch überschaubare Möglichkeit, dieser Anforderung nachzukommen, bietet die Portaltechnik. Die Vor- und Nachteile von Portalen beim Einsatz in FüInfoSys werden in Kap. 5 diskutiert. In dem Beitrag wird auch ein alternativer Ansatz in Form einer neuartigen Portalkomponente für

32

M. Spielmann

FüInfoSys vorgestellt. Mit jener Portalkomponente lassen sich die GREL-Anteile verschiedener Services in einer gemeinsamen Lagedarstellung visualisieren. Bemerkung. Grundsätzlich gilt, dass der situationsbezogene Zugang auch zu externen Services, also über die Systemgrenzen eines FüInfoSys hinaus, möglich sein muss.

3.2.2 Modularität und Fernnutzung Aufgrund mangelnden Konsenses in der Literatur hinsichtlich der genauen Bedeutung der Begriffe „Service“ und „serviceorientiertes System“ werden die beiden Begriffe im Folgenden für die Zwecke dieses Beitrags präzisiert. Eine Softwarekomponente, deren Funktionalität (semi-)formal spezifiziert ist und mittels einer (semi-)formal spezifizierten und zugleich netzwerktauglichen Schnittstelle genutzt werden kann, bezeichnen wir als Service. Ein Service (bzw. dessen Funktionalität) kann einerseits von anderen Services, Anwendungen oder Systemkomponenten verwendet werden. Andererseits ist auch eine Verwendung unmittelbar durch Nutzer mittels einer vom Service bereitgestellten wie auch immer gearteten Nutzerschnittstelle möglich. Die Nutzung eines Services ist dabei nicht notwendigerweise auf den Server, auf dem der Service ausgeführt bzw. die ServiceFunktionalität bereitgestellt wird, beschränkt, sondern kann auch über ein Netzwerk erfolgen (Fernnutzung). Ein System, dessen grundlegende Funktionalitäten in Form von Services bereitgestellt werden, bezeichnen wir auch als serviceorientiertes System. Bemerkung. In der Tat ist die Möglichkeit zur Fernnutzung, beispielsweise via eines Service-Busses, ein wesentliches Unterscheidungsmerkmal zwischen einem Service und einem (klassischen) Softwaremodul im Sinne der Modularen Programmierung. Die Entwicklung eines Services umfasst eine präzise, möglichst formale Beschreibung sowohl der Funktionalität als auch aller Schnittstellen des Services. Beispielsweise sind die folgenden Fragestellungen hinsichtlich des Betriebs und der Nutzung eines Services detailliert zu dokumentieren:  Welche Funktion (formale Abbildung) wird durch den Service implementiert?  Auf welchen anderen Services, Anwendungen, Datenbanken, Teilsystemen etc. setzt der Service wie auf? Welche technischen Randbedingungen sind dabei zu beachten?  Wie lässt sich der Service betreiben und nutzen? Welche Protokolle sind dabei jeweils einzuhalten? Für ein umfassendes Verständnis solcher Protokolle müssen ggf. der interne Aufbau, die internen Zustände und die interne Abläufe des Services dokumentiert werden. Allerdings würde eine konsequente Offenlegung all dieser Informationen bei vielen komplexen Services (man denke an eine MIP-Schnittstelle eines FüInfoSys;

3 Konzeption verteilter Führungsinformationssysteme

33

vgl. auch Kap. 21) faktisch einer Komplettbeschreibung der betreffenden Services gleichkommen. Aufgrund des enormen Aufwandes bzw. der damit verbundenen Kosten ist das Anfertigen einer entsprechend detaillierten Dokumentation bei komplexen Services also nicht praktikabel. Ungeachtet dessen sollte bei der Konzeption und Entwicklung von FüInfoSys eine Serviceorientierung zumindest angestrebt werden, da die damit verbundene (und bei den Herstellern einzufordernde) Dokumentation von Services die Transparenz des Systems insgesamt erhöht. Das setzt eine entsprechende Qualitätskontrolle bei der Beauftragung und Entwicklung von Services voraus. Mittel- bis langfristig könnten sich so die folgenden (abgeleiteten) Vorteile ergeben:  Die Wiederverwendbarkeit einzelner Softwarekomponenten (Services) wird unterstützt bzw. erst ermöglicht, wodurch sich die Herstellungskosten ggf. reduzieren lassen.  Die Abhängigkeit von spezifischen Herstellern wird gemindert.  Es ergeben sich zusätzliche Möglichkeiten zum Monitoring der Systeme und zur Fehleranalyse (auch durch Dritte), wodurch die Qualitätssicherung vereinfacht wird.  Im Vorgriff auf eine spätere Dokumentation können bereits im Rahmen der Architekturentwicklung Servicemodelle und Schnittstellenbeschreibungen angefertigt werden. Dadurch können Abstimmungsprozesse (vgl. Paragraph „Interoperabilität durch frühzeitige Abstimmung“ in der Einleitung in Abschn. 3.1) vereinfacht und so die Interoperabilität der Systeme verbessert werden. Mit Blick auf den letzten Punkt sei angemerkt, dass eine Beschreibung von Services, welche auf Geschäftsobjekte zugreifen und diese manipulieren, bedingt, dass zuvor die Semantik dieser Geschäftsobjekte hinreichend detailliert beschrieben wurde. Insbesondere Datenmodelle, Schnittstellenformate und Protokolle, welche die Interaktion von Services tangieren, sollten durch ein Architekturstrategieteam mitgesteuert oder gar vorgegeben werden. Dies würde die Gefahr von Missverständnissen vermindern und neue Möglichkeiten zur Qualitätssicherung eröffnen.

3.2.3 Verteilung und Reorganisation Die Leistungsfähigkeit von FüInfoSys wird maßgeblich durch die Leistungsfähigkeit der den Systemen zugrunde liegenden Kommunikationsinfrastruktur bestimmt. Letztendlich sind durch Parameter wie Verfügbarkeit, Bandbreite und Stabilität von Kommunikationsverbindungen absolute quantitative und qualitative Obergrenzen für die von FüInfoSys prinzipiell realisierbare Informationsversorgung vorgegeben. Beispielsweise ist die Beantwortung von Fragestellungen wie „Welche Informationen lassen sich mit welcher Güte wann wohin übertragen? und „Bei welcher Verteilung von Datensätzen (Datentopologie) lässt sich die Konsistenz der Daten wahren?“ unmittelbar von den Leistungsparametern der einzelnen Kommunikationsverbindungen im Gesamtnetzwerk abhängig.

34

M. Spielmann

Nun sind Kommunikationsnetze, welche FüInfoSys zugrunde liegen, sehr heterogen und unterscheiden sich zum Teil deutlich von Kommunikationsnetzen im zivilen Bereich. Insbesondere auf der taktischen Ebene, zum Teil aber auch auf den unteren operativen Ebenen, stehen häufig ausschließlich militärische Kommunikationsnetze zur Verfügung. Selbst wenn zivile Kommunikationsnetze existieren, ist ein Rückgriff auf diese Netze risikobehaftet und wird teilweise aus operativen Erwägungen bewusst vermieden. Da militärische Kommunikationsnetze im Einsatzgebiet weitestgehend unabhängig von der zivilen Infrastruktur operieren bzw. prinzipiell dazu in der Lage sein müssen, sind diese Netze in der Regel mobil oder zumindest verlegefähig (transportabel), wodurch deren Leistungsfähigkeit eingeschränkt wird. Des Weiteren operieren die Netze häufig in nicht-kooperativen Umgebungen und unterliegen demzufolge zusätzlichen Einschränkungen. Neben gezielten Störeinwirkungen müssen auch passive Störeinflüsse, wie z. B. Abschirmung durch zivile Infrastruktur in urbanen Gebieten oder auch innerhalb von Gebäuden kompensiert oder zumindest berücksichtigt werden. Bei militärischen Kommunikationsnetzen ist das Problem von inhärenter Natur: Es muss grundsätzlich davon ausgegangen werden, dass Kommunikationsverbindungen instabil sind oder ganz ausfallen, auch über einen längeren Zeitraum hinweg. Eine unmittelbare Konsequenz ist, dass das Netzwerk, auf dem ein betroffenes FüInfoSys aufsetzt, prinzipiell in verschiedene Fragmente zerfallen kann, unabhängig davon, ob dieses Netzwerk auf unzuverlässigen militärischen oder zivilen Kommunikationsnetzen basiert. Man vergleiche dazu Abb. 3.1. Das Bild auf der linken Seite zeigt das Netzwerk mit angeschlossenen Endgeräten (letztere symbolisiert durch Kreise) unter der Annahme, dass die Kommunikationsverbindungen sowohl innerhalb des Netzwerks (d. h. zwischen den einzelnen Netzwerk-Servern) als auch zwischen dem Netzwerk und den Endgeräten hinreichend stabil sind und über ausreichende Bandbreite verfügen. Im Gegensatz dazu berücksichtigt das Bild auf der rechten Seite die oben geschilderte Kommunikationsproblematik: In der Realität kann das Netzwerk in verschiedene Netzwerkfragmente zerfallen, jedes bestehend aus einem Kommunika-

Idealisierte Sicht

Fragmentiertes Netzwerk

Netzwerk basierend auf idealem Kommunikationsnetz

Abb. 3.1 Idealisiertes Netzwerk (links) und dessen Fragmentierung (rechts) aufgrund eingeschränkter Kommunikationsmittel: Jedem Fragment liegt ein Teilnetzwerk mit ausreichenden Kommunikationsressourcen zugrunde. Zwischen den verschiedenen Fragmenten ist die Kommunikation potentiell instabil und/oder kostenintensiv

3 Konzeption verteilter Führungsinformationssysteme

35

tionsteilnetz und der innerhalb dieses Teilnetzes vorhandenen IT-Infrastruktur (also z. B. den dort betriebenen Netzwerk-Servern). Beispiele für Netzwerkfragmente sind der Kommandostand in einem Gefechtsfahrzeug, die verlegefähige Installation eines Kontingentführers und das Intranet der Bundeswehr. Innerhalb jedes einzelnen Netzwerkfragmentes lässt sich – für eine gewisse Dauer – eine stabile kostengünstige Kommunikation (z. B. mittels LAN) einrichten. Im Gegensatz dazu sind die verschiedenen Fragmente über potentiell instabile und/oder kostenintensive Kommunikationsmittel (z. B. Funk oder Satellit, in der Abbildung symbolisiert durch rote Pfeile) miteinander verbunden. Man beachte, dass Endgeräte nicht notwendigerweise als Bestandteil eines Netzwerkfragmentes zu werten sind, da manche Endgeräte ebenfalls nur über eingeschränkte Kommunikationsmittel mit dem System verbunden sind. Diese Problematik wird in Abschn. 3.2.4 adressiert. Bei der Konzeption und Entwicklung kommunikationseingeschränkter FüInfoSys – damit sind FüInfoSys gemeint, deren Netzwerk prinzipiell von dem Problem der Fragmentierung betroffen ist – müssen daher besondere Vorkehrungen getroffen werden. Da es nicht immer möglich ist, von einem Endgerät, welches sich in einem bestimmten Netzwerkfragment befindet, auf einen Server innerhalb eines anderen Fragmentes zuzugreifen, müssen Redundanzen in das System eingeführt werden: Je nachdem, welche FüInfoSys-Funktionalitäten (Services) in einem Fragment in welcher Qualität benötigt werden, müssen in dem Fragment geeignete „Kopien“ der Funktionalitäten (Services) vorgehalten werden (vgl. Abb. 3.2). Aus der Notwendigkeit, Redundanzen einzuführen, lässt sich die folgende Anforderung an kommunikationseingeschränkte FüInfoSys ableiten: Verteilung des Systems. Die grundlegenden Funktionalitäten (Services) des Systems werden nicht durch zentral gehaltene Softwarekomponenten realisiert, sondern ergeben sich aus dem Zusammenspiel von im Netzwerk verteilten Softwarekomponenten. Ein klassisches Beispiel für ein System, welches diese Anforderung erfüllt, ist ein verteiltes Datenbanksystem: In einem solchen System werden die üblichen Funktionalitäten einer zentralen Datenbank durch einen Verbund von möglicherweise teilredundanten lokalen Datenbanken realisiert. Durch geeignete DatenaustauschIdealisierte Sicht

Fragmentiertes Netzwerk

Service Service Service

Abb. 3.2 Die Kommunikationsproblematik macht eine (teil-)redundante Bereitstellung von FüInfoSys-Anteilen in den verschiedenen Netzwerkfragmenten erforderlich

36

M. Spielmann

und Datenabgleichmechanismen, welche auf den lokalen Datenbanken aufsetzen und für deren Datenkonsistenz sorgen, wird eine konsistente Sicht der Gesamtheit aller in den verschiedenen lokalen Instanzen gehaltenen Daten erzeugt. Auf Basis dieser logischen Datensicht wird dem Nutzer eine virtuelle zentrale Datenbank zur Verfügung gestellt. Eine weitere Anforderung an kommunikationseingeschränkte FüInfoSys wird von verteilten Datenbanksystemen dagegen in der Regel nicht erfüllt. Die Anforderung wird im Folgenden formuliert. Eine unmittelbare Konsequenz aus der Mobilität bzw. Verlegefähigkeit militärischer Kommunikationsnetze ist, dass sich die Topologien und Leistungsparameter dieser Netze während des Betriebs – also z. B. während eines Einsatzes – ändern können. Je nach Netztyp und Einsatzszenar können diese Änderungen schnell und unerwartet auftreten. Bei kommunikationseingeschränkten FüInfoSys hat dies natürlich Einfluss auf die Netzwerkfragmentierung: Auch hier können sich Topologie und Übertragungskapazitäten zwischen den einzelnen Netzwerkfragmenten ändern. Die Systeme müssen auf solche Änderungen reagieren können, indem sie bei Bedarf die Verteilung und das Zusammenspiel ihrer Softwarekomponenten an neue Netzwerktopologien und -kapazitäten anpassen. Im Idealfall ist dies während des Betriebs und mit nur geringen Einbußen bei den bereitgestellten Funktionalitäten möglich. Die folgende Anforderung an (verteilte) kommunikationseingeschränkte FüInfoSys bringt diese Fähigkeit zur strukturellen Reorganisation eines Systems zum Ausdruck: Reorganisation des Systems. Das System kann auf Veränderungen der Netzwerktopologie und -kapazitäten durch Reorganisation der Verteilung und des Zusammenspiels seiner Softwarekomponenten möglichst eigenständig reagieren oder unterstützt zumindest eine solche Reorganisation. Beispiele für Systeme mit eigenständiger Reorganisationsfähigkeit stellen verteilte Informationssysteme basierend auf dezentralen P2P-Filesharing-Protokollen (z. B. Gnutella) dar. Diese Systeme passen sich automatisch an jede beliebige Netzwerktopologie an (garantieren dafür aber bei Suchanfragen weder die Vollständigkeit noch die Konsistenz der gelieferten Resultate). Ein interessanter Aspekt ergibt sich bei der Betrachtung verteilter serviceorientierter Systeme (vgl. die obige Forderung nach Verteilung und die Beschreibung serviceorientierter Systeme in Abschn. 3.2.2). Zunächst einmal ist festzuhalten, dass die Tatsache, dass ein System serviceorientiert ist, noch nichts über die Verteilung von Services bzw. einzelner Servicekomponenten aussagt. Als Beispiel betrachte man nochmals das oben skizzierte verteilte Datenbanksystem. Je nach Nutzungsart ist es sinnvoll die Abfragefunktionalitäten des Systems entweder als zentralen Service bereitzustellen, beispielsweise auf einem einzelnen Applikationsserver (vgl. Abb. 3.3, links), oder aber in verteilter Form, z. B. wie folgt: Jede lokale Datenbank-Instanz wird zu einer eigenständigen Service-Instanz mit eigener Service-Schnittstelle ausgebaut (vgl. Abb. 3.3, rechts). Im diesem Fall kann man von einem verteilten Service sprechen, welcher durch die Gesamtheit der einzelnen Service-Instanzen gebildet wird. Welche der beiden dargestellten Implementie-

3 Konzeption verteilter Führungsinformationssysteme

37

Zentraler Service

Verteilter Service

Service

Service Applikationsserver ServiceInstanz

... lokale DB

ServiceInstanz

... lokale DB

lokale DB

lokale DB

Abb. 3.3 Die Bereitstellung der Abfragefunktionalitäten eines verteilten Datenbanksystems in Form eines Services kann sowohl zentral auf einem Applikationsserver geschehen (links) als auch dezentral in Form von Service-Instanzen, welche unmittelbar bei den lokalen Instanzen der verteilten Datenbank bereitgestellt werden

rungsvarianten effizienter ist, hängt u. a. vom Typ der zu beantwortenden Datenbankabfragen ab. Ein wichtiges Kriterium bei der Wahl der Verteilung eines Services ist die Minimierung ressourcenintensiver Datenflüsse (man denke an die Replikation von Datenbanken, welche sich in verschiedenen Netzwerk-Fragmenten befinden). Allerdings ist das Auftreten solcher Datenflüsse in der Regel nicht ausschließlich von absoluten Größen abhängig, sondern wird maßgeblich durch dynamische Parameter beeinflusst, wie der natürlichen Verteilung der Daten (Wo werden Daten generiert?), der Verweisdichte und der Verweisstruktur der Daten (Wie viele Referenzen verweisen wohin?) sowie der Art und Weise der Nutzung der von einem Service bereitgestellten Funktionalität (Wird primär nur auf lokale Daten zugegriffen? vs. Sind häufig globale Sichten zu erzeugen?). Eine adäquate Softwarearchitekturbeschreibung eines verteilten serviceorientierten Systems muss also auch Verteilungssichten der Services des Systems umfassen. Beschreibungen der Services als modulare Einheiten (mit bestimmten Funktionalitäten und diversen Schnittstellen) allein sind nicht ausreichend. Vielmehr muss der Begriff des Services weiter verfeinert werden. Für komplexe Services, deren Funktionalitäten nur durch ein Zusammenspiel von im Netzwerk verteilten Softwarekomponenten (z. B. Service-Instanzen) realisiert werden kann (man denke an eine serviceorientierte Bereitstellung lagerelevanter Daten auf Basis einer über mehrere Netzwerkfragmente verteilten Datenbank), sind Beschreibungen der folgenden Aspekte unabdingbar:  die interne Gliederung eines Services in funktional-logische Einheiten, welche für die Verteilung des Services und das Zusammenspiel der resultierenden Komponenten relevant sind,  mögliche Verteilungen oder Verteilungsstrategien für den Service bzw. dessen Komponenten und  Vorschriften für das Zusammenspiel der Komponenten (im weitesten Sinne Orchestrierung).

38

M. Spielmann

In Abschn. 3.3.2 wird eine funktional-logische Gliederung von Services vorgestellt, welche als Grundlage für die Beschreibung von Verteilungsstrategien für Services genutzt werden kann.

3.2.4 Anbindung der Endgeräte Bei der Konzeption und Entwicklung von Softwarelösungen zur Anbindung von Endgeräten an FüInfoSys müssen, je nach Einsatzumfeld des betrachteten FüInfoSys, die folgenden Randbedingungen berücksichtigt werden: 1. Heterogenität der Endgeräte: Unter Umständen muss eine Vielzahl unterschiedlicher Endgerättypen unterstützt werden, von leistungsstarken Workstations zur Lagebearbeitung bis hin zu Handheld-Devices (beispielsweise zur Versorgung mit rudimentären Lageinformationen). Bei der Entwicklung einer geeigneten Softwarearchitektur für die Endgerät-Anbindung müssen die unterschiedlichen Eingabe- und Ausgabemöglichkeiten (Tastatur vs. Touchscreen, Größe der Anzeige etc.) der anzubindenden Endgeräte berücksichtigt werden. 2. Eingeschränkte Kommunikationsressourcen: Je nach Einsatzumfeld eines FüInfoSys kann die im vorhergehenden Unterabschnitt beschriebene Kommunikationsproblematik auch bestimmte Endgerät-Netzwerk-Verbindungen betreffen. Die Eigenschaften der für diese Verbindungen herangezogenen Kommunikationsmittel müssen von der Endgerät-Anbindung berücksichtigt werden (Bandbreite, Schwankungen, Ausfallwahrscheinlichkeit etc.). Sind gemäß Randbedingung (1) viele unterschiedliche Endgerättypen zu unterstützen, so besteht die Gefahr eines „Wildwuchses“ an endgerätspezifischen Softwarekomponenten in der Präsentationsschicht des Systems, mit entsprechend negativen Folgen für die Wartbarkeit des Systems. Um dieses Problem zu vermeiden bzw. zu mindern, sollten betroffene FüInfoSys die folgende Anforderung erfüllen: Einheitliche Zugangssoftware. Der Zugang zum System erfolgt mittels einer einheitlichen, möglichst standardisierten Softwarekomponente, welche auf dem Endgerät installiert wird (beispielsweise vor dessen Inbetriebnahme). Eine Umsetzung dieser Anforderung kann wie folgt aussehen: Vor Beginn einer Sitzung ermittelt die Zugangssoftware die Eingabe- und Ausgabemöglichkeiten des Endgeräts in Form eines Endgerätprofils. In Abhängigkeit von diesem Endgerätprofil wird von dem System eine auf das Profil des aktuellen Nutzers (dessen Rolle, Auftrag, Fähigkeiten etc.) zugeschnittene Nutzerschnittstelle ausgewählt und mittels der Zugangssoftware auf dem Endgerät dargestellt. Die von dem Nutzer während der Sitzung getätigten Eingaben werden von der Zugangssoftware aufgenommen und zur Weiterverarbeitung an geeignete Stellen im System weitergeleitet. Als Beispiel betrachte man die Zugangssoftware eines Ultra-Thin-Clients: Einmal auf einem Endgerät installiert, ermöglicht die Zugangssoftware die Darstellung beliebiger Bildschirminhalte (vgl. Abb. 3.4, links). Allerdings sind Ultra-Thin-

3 Konzeption verteilter Führungsinformationssysteme

39

Clients aufgrund ihrer Anforderungen an die Kommunikationsverbindung zu einem Server (Stabilität, Bandbreite) für Endgerät-Anbindungen mit eingeschränkten Kommunikationsressourcen (gemäß Randbedingung 2 oben) ungeeignet. Das Vorkommen solcher Einschränkungen motiviert die folgende Anforderung (vgl. auch IT-AmtBw & Heeresamt, 2004): Zeitweise Autarkie von Endgeräten. Bei dedizierten Endgerät-Netzwerk-Verbindungen müssen Leistungsschwankungen der eingesetzten Kommunikationsmittel berücksichtigt und – falls möglich – kompensiert werden können. In manchen Fällen muss es möglich sein, Endgeräte zeitweise autark zu betreiben, zumindest mit eingeschränkten Qualitätsmerkmalen. Diese Anforderung kann mit Hilfe von Smart-Clients erfüllt werden (vgl. Abb. 3.4, rechts): Ist absehbar, dass während eines bevorstehenden Einsatzes gravierende Leistungsschwankungen drohen (z. B. weil sich im Einsatzgebiet Störsender befinden), so werden – möglichst transparent für den Nutzer – essentielle Software- und Datenmodule (z. B. Module zur Erzeugung einer rudimentären Blue-Force-RedForce-Anzeige) auf das Endgerät übertragen und dort bei Bedarf aktiviert. Die übertragenen Module werden mittels Updates auf dem aktuellen Stand gehalten, solange es die zur Verfügung stehenden Kommunikationsressourcen zulassen. Wird ein bestimmter Schwellenwert für die Updaterate unterschritten, so wird mit den Modulen eine rudimentäre Informationsversorgung auf dem Endgerät sichergestellt, bis wieder eine ausreichende Versorgung mit Kommunikationsressourcen gewährleistet werden kann. Ein entsprechendes Architekturkonzept wird im FKIE-Bericht (Käthner & Spielmann, 2005) beschrieben. Ein offensichtlicher Nachteil von Smart-Clients ist, dass sie technisch aufwendig sind (z. B. im Vergleich zu Ultra-Thin-Clients) und daher vergleichsweise hohe

(Ultra-)Thin-Client N1 N2

Smart-Client Service

N1 N2

Service

Abb. 3.4 Bei einer (Ultra-)Thin-Client-Lösung (links) wird von jedem zu nutzenden Service eine geeignete Nutzerschnittstelle (N) bereitgestellt, welche von der Endgerät-Anbindung auf das Endgerät übertragen und dort dem Nutzer präsentiert wird. Im einfachsten Fall ist diese Nutzerschnittstelle „ultra-thin“, d. h. sie besteht lediglich aus einem virtuellen Blick auf die eigentliche Benutzeroberfläche, welche beim Service im Netzwerk verbleibt. Bei einer Smart-Client-Lösung (rechts) kann das Endgerät neben der Nutzerschnittstelle zusätzliche Software- und Datenmodule vom Service erhalten, welche sich auf dem Endgerät bei Bedarf ausführen bzw. dort verwenden lassen

40

M. Spielmann

Entwicklungs- und Wartungskosten verursachen. Zudem ist eine Übertragung von Software- und Datenmodulen auf ein mobiles Endgerät aus Sicht der IT-Sicherheit grundsätzlich problematisch. In der Tat lässt sich der folgende Zusammenhang beobachten: Je mehr Komplexität im Netzwerk verbleibt (d. h. je „schmaler“ die Client-Software ausfällt), desto einfacher lassen sich die üblichen Qualitätsanforderungen wie z. B. Fehlertoleranz (z. B. Datenkonsistenz), Sicherheit, Skalierbarkeit, Performanz, Wartbarkeit etc. sicherstellen, vorausgesetzt, es stehen ausreichende Kommunikationsressourcen zwischen Endgerät und Netzwerk zur Verfügung. Die in diesem Abschnitt formulierten technischen Anforderungen an FüInfoSys dienen nun im nächsten Abschnitt als Ausgangspunkt für die Entwicklung der übergeordneten Softwarearchitektur.

3.3 Übergeordnete Softwarearchitektur Die im Folgenden präsentierte übergeordnete Softwarearchitektur skizziert schematisch die Softwarearchitektur eines abstrakten, potentiell verteilten, serviceorientierten FüInfoSys. Die diesem abstrakten System zugrundeliegende funktional-logische Gliederung kann als grundlegendes Schema für die Softwarearchitekturen zukünftig zu entwickelnder (und zu integrierender) FüInfoSys dienen. Bei der Konzeption der Gliederung wurden alle im vorhergehenden Abschnitt aufgeführten Anforderungen berücksichtigt, auch solche, die nur für spezielle FüInfoSys relevant sind. Damit soll eine möglichst breite Basis für die Entwicklung zukünftiger FüInfoSys geschaffen werden. Bei einer konkreten Realisierung kann dann aufgrund projektspezifischer Randbedingungen von bestimmten Anforderungen abgewichen werden.

3.3.1 Logische Sicht Die übergeordnete Softwarearchitektur gliedert sich in vier funktional-logische Gruppen, im Folgenden Segmente genannt: 1. ein Segment zur Bereitstellung von Rechen-, Speicher-, Kommunikations- und Software-Ressourcen, 2. ein Segment, welches die eigentliche Funktionalität des Gesamtsystems in Form von Services bereitstellt, 3. ein Segment zur Präsentation dieser Funktionalität auf den Endgeräten und 4. ein Segment für die Zugriffskontrolle. Die Aufgaben und Funktionen der einzelnen Segmente werden nachfolgend kurz skizziert. Auf eine umfassende Darstellung der übergeordneten Softwarearchitektur muss an dieser Stelle aus Platzgründen verzichtet werden (vgl. Spielmann, in Bearbeitung).

3 Konzeption verteilter Führungsinformationssysteme

41

Jedes der ersten drei Segmente „Ressourcen“, „Services“ und „Präsentation“ besteht aus mehreren funktional-logischen Einheiten (FLE; vgl. Abb. 3.5). Prinzipiell können die Leistungsmerkmale jeder FLE durch das vierte Segment, die Zugriffskontrolle, beeinflusst werden. In diesem Sinne realisiert die Zugriffskontrolle eine querschnittliche Funktionalität. Ressourcensegment. Das Ressourcensegment kapselt die Rechen-, Speicher- und Kommunikationsressourcen des Gesamtsystems und stellt diese in Form von (möglichst) plattformunabhängigen Diensten zur Verfügung. Bis zu einem gewissen Grad lässt sich dadurch eine Entkopplung der anderen Segmente von einer spezifischen Hardware-, Betriebssystem- und Netzwerk-Ausstattung erreichen. Die Verfügbarkeit von gekapselten Ressourcen im Gesamtsystem hängt dabei entscheidend von der Topologie des zugrundeliegenden Kommunikationsnetzes ab. Beispielsweise kann in einem ausreichend dimensionierten LAN-Verbund von Servern eine objektorientierte Middleware wie z. B. CORBA oder Java-RMI standardmäßig zur Verfügung stehen. Dagegen ist die Verwendung derselben Middleware über eine taktische Truppenfunkverbindung aufgrund der eingeschränkten Leistungsfähigkeit der Verbindung in der Regel nicht sinnvoll. Auch die Verwaltung von Software-Ressourcen wird hier abgebildet. Ein Beispiel hierfür liefert das in Kap. 4 beschriebene Konzept zur Konfiguration, Verteilung, Initialisierung und Verknüpfung von ServiceKomponenten. Service-Segment. Dieses Segment stellt die eigentlichen Funktionalitäten eines FüInfoSys in Form von Services bereit. Bei der Herleitung einer Softwarearchitektur aus der übergeordneten Architektur werden die einzelnen FLE dieses Segmentes in Form von Services oder ganzen Service-Familien instanziiert. Eine besondere Rolle spielt dabei die FLE „Lagegenerierung“ bzw. die aus dieser Einheit abzuleitende Service-Familie. Primäre Aufgabe dieser Service-Familie, welche im Folgenden kurz Lage-Services genannt wird, ist die Bereitstellung eines systemweit einheitli-

nutzerspezifische Instanzen 1, ..., n Zugriffskontrolle

Endgerät-Anbindung Visualisierung

n 1

Befehlsanwendungen, Assistenzsysteme etc.

Assistenzsysteme ...

Ressourcen Services

Präsentation

Zugriffskontrolle

Befehlsanwendungen

EndgerätAnbindung

Visualisierung

Lage-Generierung Lagegenerierung

Lagegenerierung Ressourcenmanagement

Ressourcenmanagement Kommunikation

Abb. 3.5 Übersicht über die funktional-logischen Gruppen und Einheiten (FLE) der übergeordneten Softwarearchitektur, links in Form eines Schichtenmodells, rechts in Form einer logischen Sicht mit mehreren nutzerspezifischen Instanzen (vgl. Abschn. 3.3.2). Durch die Gruppierung der FLE in der logischen Sicht wird das unmittelbare Zusammenspiel der verschiedenen FLE angedeutet: Gemeinsame Kanten weisen auf primäre Schnittstellen hin

42

M. Spielmann

chen Objektraumes für die Erzeugung und Verwaltung lagerelevanter Daten. Das Vorhandensein eines solchen Objektraumes ist eine wesentliche Voraussetzung für die Entwicklung semantisch aufeinander abgestimmter Services: Nur wenn die verschiedenen Sichten der einzelnen Nutzer aus demselben Objektraum abgeleitet werden – d. h. nur wenn die Daten, aus denen diese Sichten generiert werden, in einer gemeinsamen logischen Datenhaltungsschicht verwaltet werden – kann ein semantisch konsistentes und damit gemeinsames Verständnis der Lage (GREL) entstehen und darauf aufbauend die Absicht der übergeordneten Führung (z. B. in einem Befehl) formuliert und später nicht nur vom Menschen, sondern auch vom System korrekt interpretiert werden. Zusammenfassend lässt sich der von den Lage-Services bereitgestellte Objektraum als Integrationsbasis für alle anderen Services bezeichnen. Die konkrete Ausprägung dieses Raumes hängt maßgeblich von den zu integrierenden Services ab. Er ist in jedem Fall aber ein entscheidender Faktor für den prinzipiell erreichbaren Integrationsgrad des Gesamtsystems. Aufgrund der Verteilung eines realen FüInfoSys wird sich hinter den Lage-Services letztendlich ein verteiltes Datenhaltungs- und Datenmanagement-System verbergen (vgl. auch Kap. 7). Präsentationssegment. Die FLE „Endgerät-Anbindung“ des Präsentationssegmentes realisiert die in Abschn. 3.2.4 geforderte einheitliche Zugangssoftware und ggf. die zeitweise Autarkie von Endgeräten. Die FLE „Visualisierung“ stellt, unter Einbeziehung der Zugriffskontrolle (vgl. unten), innerhalb jedes Netzwerkfragmentes den in Abschn. 3.2.1 geforderten situationsbezogenen Zugang zu heterogenen Quellen sicher (vgl. auch die Kap. 5 und 6). Zugriffskontrolle. Dieses Segment ist für die Sicherstellung der Integrität, der Vertraulichkeit und der Verfügbarkeit bzw. der Nicht-Verfügbarkeit von Ressourcen, von Services und von Informationen und Funktionalitäten (dargestellt in der vom Präsentationssegment bereitgestellten Benutzeroberfläche) verantwortlich. Letztendlich handelt es sich hierbei um eine (verteilte) Komponente, welche alle Bereiche des Gesamtsystems durchdringt.

3.3.2 Verteilungssichten Die Architekturbeschreibung eines verteilten Systems umfasst üblicherweise auch eine oder mehrere Verteilungssichten. Verteilungssichten können, je nach Abstraktionsniveau und Darstellungsintention,  die Zuordnung einzelner Systemelemente (z. B. Prozesse oder Datenbanken) zu funktionalen, logischen und/oder physikalischen Einheiten (z. B. ServiceInstanzen, logische Datenschichten oder Rechnern) verdeutlichen oder  die Untergliederung einzelner Komponenten in Teilkomponenten und deren Verteilung auf bestimmte Hardware- oder Software-Komponenten beschreiben.

3 Konzeption verteilter Führungsinformationssysteme

43

Darüber hinaus können – ähnlich wie bei logischen Sichten – auch direkte Abhängigkeiten zwischen einzelnen Systemelementen bzw. Teilkomponenten angedeutet werden (z. B. mittels Schnittstellen), wobei hier aber primär der Kommunikationsaspekt im Vordergrund steht. Im Folgenden wird am Beispiel der Lage-Services eine Strategie zur Verteilung von Services und Service-Instanzen auf verschiedene Laufzeitumgebungen vorgestellt. Die Laufzeitumgebungen können vom Ressourcensegment auf verschiedenen, räumlich getrennten Rechnern bereitgestellt werden, welche sich möglicherweise auch in verschiedenen Netzwerkfragmenten befinden. Bemerkung. Die Verteilung eines Services auf verschiedene Laufzeitumgebungen ist nicht mit einer Verteilung des Services auf bestimmte Schichten einer MehrSchichten-Architektur zu verwechseln. Prinzipiell kann jeder Service aus mehreren solchen Schichten aufgebaut sein. Diese müssen zur Laufzeit geeigneten Komponenten des Ressourcensegmentes zugeordnet werden. Die dazu notwendigen Zuordnungs- und Verteilungsstrategien können im Ressourcensegment entweder fest kodiert sein oder aber dynamisch erfolgen (vgl. auch Kap. 4). Nutzerspezifische Instanzen. Zur Laufzeit zerfallen alle FLE des Service-Segmentes und alle FLE des Präsentationssegmentes konzeptionell wie folgt in Teilkomponenten: Für jeden Nutzer wird jeweils eine nutzerspezifische Instanz jeder dieser FLE angelegt (vgl. Abb. 3.5, rechts). Zur Laufzeit bildet die Gesamtheit aller Instanzen einer FLE (zusammen mit einem Kernanteil zur Verwaltung der einzelnen Instanzen) die betreffende FLE selbst (logische Sicht). Der Zeitpunkt der Erzeugung einer neuen Instanz hängt von der Funktionalität der jeweiligen FLE ab. Beispielsweise kann eine neue nutzerspezifische Instanz der Endgerät-Anbindung jeweils vor Beginn einer neuen Sitzung erzeugt werden. Nach Beendigung der Sitzung kann die Instanz wieder entfernt werden. Andererseits gibt es Services, deren nutzerspezifische Instanzen nach Möglichkeit immer im System präsent sein sollten, selbst wenn einzelne Nutzer nicht angemeldet sind, da jede fehlende Instanz dieser Services unter Umständen Informationsverlust für andere Nutzer bedeutet (vgl. auch Kap. 7). Die oben beschriebene Zerlegung einer FLE in nutzerspezifische Instanzen ist eine rein konzeptionelle Gliederung, welche a priori losgelöst von einer realen Verteilung der FLE zu sehen ist. Zum Beispiel lässt sich eine Stand-Alone-Applikation, welche auf einem einzelnen Server installiert ist, wie folgt gliedern: Bei jedem Starten der Applikation wird ein neuer nutzerspezifischer Prozess inklusive nutzerspezifischer Speicherressourcen auf dem ausführenden Server erzeugt. Jeder dieser Prozesse repräsentiert eine nutzerspezifische Instanz im Sinne der beschriebenen konzeptionellen Gliederung. Dennoch sind alle diese Prozesse Teil derselben Laufzeitumgebung. In anderen Fällen kann dagegen die Zerlegung einer FLE in nutzerspezifische Instanzen stark mit einer Verteilung der FLE auf verschiedene Laufzeitumgebungen korrelieren, wie die folgende Strategie zur Verteilung eines Lage-Services zeigt (vgl. Abb. 3.6): In einer Phase relativer Netzwerkstabilität, d. h. wenn weder bei der Netzwerkfragmentierung noch bei der Endgerät-Anbindung gravierende Änderungen zu erwarten sind, sollte eine Instanz des betreffenden Lage-Services genau in

44

M. Spielmann Verteilungssicht eines Lage-Services und …

… dessen nutzerspezifische Instanzen

Lage

Lage Lage

Lage

Lage

Lage

Lage

Lage Lage

Lage

Lage Lage

Abb. 3.6 Links: In jedem Netzwerkfragment wird eine Kopie eines Lage-Services gehalten (einschließlich eines Kernanteils zur Verwaltung nutzerspezifischer Instanzen des Services). Rechts: In einer Phase relativer Netzwerkstabilität findet jeder Nutzer die mit ihm assoziierte Instanz des Services im „lokalen“ Netzwerkfragment

dem Netzwerkfragment ausgeführt werden, in dem sich der mit der Instanz assoziierte Nutzer via Endgerät-Anbindung befindet (Lokalitätsprinzip). In diesem Fall korreliert die konzeptionelle Gliederung des Services in nutzerspezifische Instanzen mit der räumlichen Verteilung des Services auf verschiedene Netzwerkfragmente. Um die Validität und Praktikabilität der hier dargelegten Überlegungen zu überprüfen, wurde die übergeordnete Softwarearchitektur zu einer konkreten Softwarearchitektur verfeinert und schließlich in Form eines Experimental-FüInfoSys implementiert (FKIE-Projekt „PLATO“). Für weiterführende Literatur zu diesen Arbeiten sei der Leser auf die Kap. 4, 5, 6, 7, 8 und 11 und auf die dort genannten Referenzen verwiesen.

3.4 Zusammenfassung Das veränderte Einsatz- und Aufgabenspektrum der Bundeswehr stellt neue Anforderungen an FüInfoSys. Es gilt, die Systeme insgesamt flexibler zu gestalten und dabei einen hohen Grad an (semantischer) Interoperabilität zu gewährleisten. Aufgrund der sich stetig wandelnden Randbedingungen werden in Zukunft Systeme benötigt, deren Struktur und deren Merkmale weitestgehend parametrisiert sind und zur Laufzeit an neue Randbedingungen angepasst werden können. In Anlehnung an die Eigenschaften von Software-Defined-Radios lässt sich auch von SoftwareDefined-Systems sprechen. Mit Blick auf den geforderten Grad an Interoperabilität der Systeme muss festgestellt werden, dass bereits bei der Konzeption und Entwicklung der Systeme zentrale technische Fragestellungen hinsichtlich einer späteren Integration in den Vordergrund gerückt und im Rahmen umfangreicher Abstimmungsprozesse zwischen den beteiligten Personen adressiert werden müssen. Die Verwendung bestimmter Standards (z. B. bei Datenmodellen und Schnittstellenformaten) bei der Systementwicklung alleine ist nicht ausreichend, um einen semantisch konsistenten Informationsaustausch zwischen den Systemen und damit die notwendige Verzahnung der durch

3 Konzeption verteilter Führungsinformationssysteme

45

die einzelnen Systeme unterstützten (Teil-)Geschäftsprozesse zu gewährleisten. Eine mögliche unterstützende Maßnahme zur Systematisierung von Abstimmungsprozessen ist die Entwicklung einer allgemeinen Architekturstrategie, welche einen formalen Rahmen für die frühzeitige Abstimmung der Systemarchitekturen der später zu integrierenden Systeme bietet. Als ein möglicher Bestandteil einer solchen Architekturstrategie wurde in diesem Beitrag eine übergeordnete Softwarearchitektur für netzwerkbasierte serviceorientierte FüInfoSys vorgestellt. Die übergeordnete Softwarearchitektur kann bei der Entwicklung der Softwarearchitekturen zukünftig zu entwickelnder und zu integrierender FüInfoSys als Rahmen fungieren. Als Ausgangspunkt für die Entwicklung der übergeordneten Softwarearchitektur wurden eine Reihe technischer Anforderungen formuliert, welche grundsätzliche Eigenschaften von FüInfoSys zum Ausdruck bringen oder ebenenspezifische Randbedingungen für die Entwicklung einzelner FüInfoSys widerspiegeln. Alle diese Anforderungen wurden bei der Erarbeitung der übergeordneten Softwarearchitektur berücksichtigt. Damit wird dem Gedanken Rechnung getragen, eine möglichst breite Basis für die Entwicklung zukünftiger FüInfoSys bereitzustellen. Bei einer konkreten Realisierung kann aufgrund projektspezifischer (z. B. zeitlicher oder monetärer) Randbedingungen von bestimmten Anforderungen abgewichen werden. Das übergeordnete Ziel ist, bei allen beteiligten Personen ein entsprechendes Problembewusstsein für die technischen Anforderungen anderer FüInfoSys und damit letztendlich ein gemeinsames Verständnis im Sinne einer allgemeinen Architekturstrategie zu erreichen.

Literaturverzeichnis BMVg (2006). Teilkonzeption Vernetzte Operationsführung. IT-AmtBw & Heeresamt (2004). Abschließende funktionale Forderung für den Infanteristen der Zukunft – Erweitertes System. Käthner, S. & Spielmann, M. (2005). Service-skalierbare Endgerät-Anbindung für netzwerkbasierte serviceorientierte FüInfoSys. FKIE-Bericht Nr. 99, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Spielmann, M. (in Bearbeitung). Konzeption verteilter Führungsinformationssysteme zur Unterstützung der Vernetzten Operationsführung. FKIE-Bericht, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg.

Kapitel 4

Management verteilter Führungsinformationssysteme Norman Jansen und Marc Spielmann

4.1 Einleitung Ein wesentliches Ziel der Transformation der Bundeswehr ist die Befähigung zur Vernetzten Operationsführung (NetOpFü, BMVg, 2006). Die Vernetzte Operationsführung bedingt die Schaffung eines gemeinsamen Informationsverbundes aller teilnehmenden Elemente (Sensoren, Führung und Effektoren). Eine Herausforderung bei der Bildung dieses gemeinsamen Informationsverbundes ist die Anbindung der taktischen Ebene. Taktische Kommunikationsnetze sind üblicherweise Funknetze im UHF- bzw. VHF-Band mit teils sehr geringen und schwankenden Bandbreiten. Zudem können Netzwerkverbindungen aufgrund von physikalischen Effekten der Funkübertragung (Interferenz, Abschattung etc.) zeitweise ausfallen und zu einer Partitionierung des Netzes führen. Unter diesen Randbedingungen ist es notwendig, im FüInfoSys Funktionalitäten und Informationen redundant vorzuhalten, um deren Verfügbarkeit zu gewährleisten. Zur Abmilderung der Kommunikationsproblematik sollten zukünftige FüInfoSys ihre Systemfunktionalitäten in der Form von Softwarekomponenten, die im Netzwerk verteilt sind, bereitstellen. Wir betrachten serviceorientierte, netzwerkbasierte FüInfoSys. In einer serviceorientierten Architektur werden die Systemfunktionalitäten durch lose gekoppelte Softwarekomponenten (Services genannt; vgl. unten) bereitgestellt. Services können (relativ) flexibel zu einem Gesamtsystem kombiniert und auf die Knoten des Netzwerks verteilt werden. Somit kann die Verwendung einer serviceorientierten Architektur die Flexibilität des Systems in Hinblick auf die Zusammensetzung des Systems und die Verteilung seiner Funktionalitäten im Netzwerk erhöhen. Neben Mechanismen zur Verteilung von Services sollten FüInfoSys auch Mechanismen für die Verwaltung der Services bereitstellen. Diese Anforderung resultiert aus dem breiten Spektrum möglicher Einsatzszenarien (traditionelle Kriegsführung, friedenserhaltende Maßnahmen, Einsätze bei asymmetrischen Bedrohungen usw.), welche es zu unterstützen gilt. Daher sollten zukünftige FüInfoSys möglichst flexibel sein und schnell an verschiedene Einsatzszenarien angepasst werden können. M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

47

48

N. Jansen und M. Spielmann

Unter anderem muss die Zusammensetzung des Systems aus einzelnen Services, die Konfiguration dieser Services sowie deren Verteilung auf Knoten (z. B. Rechner) im Netzwerk möglichst flexibel an die aktuelle Situation angepasst werden können. Da die Verwaltung von Services und ihrer Verteilung eine komplexe Aufgabenstellung ist, wird ein Unterstützungssystem zur Verwaltung von Services benötigt. In diesem Beitrag stellen wir ein Konzept eines Service-Managements vor. Das Konzept umfasst Mechanismen für die flexible Konfiguration, Initialisierung und Verwendung von Services eines netzwerkbasierten FüInfoSys. Die Mechanismen erlauben es Systemadministratoren, 1. die Zusammensetzung des Systems aus einzelnen Services, 2. die Verteilung der Services auf Knoten (z. B. Rechner) im Netzwerk und 3. die Initialisierung der einzelnen Services bzw. der im Netzwerk verteilten Service-Instanzen zu spezifizieren und zu steuern. Auf diese Weise wird es einem Administrator ermöglicht, das FüInfoSys einfach zu konfigurieren und schnell an neue Situationen, wie z. B. eine Änderung des operativen Ziels oder eine neue Netzwerktopologie, anzupassen.

4.2 Services und Service-Instanzen „SOA ist ein Paradigma für die Strukturierung und Nutzung verteilter Funktionalität, die von unterschiedlichen Besitzern verantwortet wird.“ (vgl. MacKenzie et al., 2006) In einer serviceorientierten Architektur (SOA) werden die Systemfunktionalitäten in Form von Softwarekomponenten (Services genannt) bereitgestellt. Es sei angemerkt, dass es keine allgemein akzeptierte Definition der Begriffe SOA und Service gibt. Wir verstehen im Folgenden unter einem Service eine Softwarekomponente, die eine Funktionalität kapselt und diese über eine (semi-)formal definierte, veröffentlichte Schnittstelle anderen Services in einem Netzwerk zur Verfügung stellt (vgl. Kap. 3). Die konsequente Verwendung einer SOA erhöht die Flexibilität hinsichtlich der Zusammensetzung des Gesamtsystems und der Verteilung der Systemfunktionalitäten im Netzwerk. Um eine noch größere Flexibilität zu erreichen, unterteilen wir einen Service konzeptionell in mehrere Service-Instanzen. Unter einer Service-Instanz verstehen wir eine Spezialisierung eines Services hinsichtlich der von dem Service bereitgestellten Funktionalität. Beispielsweise kann ein Service zur Erzeugung nutzerspezifischer Sichten auf das GREL für einen einzelnen Nutzer zu einer Service-Instanz „spezialisiert“ werden, welche ausschließlich für diesen Nutzer geeignete Sichten auf das GREL generiert (z. B. in Abhängigkeit von der aktuellen Rolle und des aktuellen Auftrags dieses Nutzers). Ein Service kann mehrfach instanziiert werden, wobei die einzelnen Instanzen dieses Services auf beliebige Knoten im Netzwerk verteilt werden können.

4 Management verteilter FüInfoSys

49

Netzwerkknoten n1 app1

DB (n1)

app2

DB Netzwerkknoten n2 app3

Netzwerkknoten n3 DB (n2)

DB (n3)

app4

app5 app6

Abb. 4.1 Ein verteilter Datenbank-Service, welcher aus lokalen Service-Instanzen besteht. Die Service-Instanzen sind auf Knoten des Netzwerks verteilt

Als Beispiel betrachte man eine verteilte Datenbank, welche aus mehreren lokalen Datenbank-Instanzen besteht (vgl. Abb. 4.1). Jede Datenbank-Instanz wird auf einem Knoten des Netzwerks ausgeführt. Jede lokale Datenbank-Instanz verwaltet die Daten des zugehörigen Knotens (und eventuell zusätzlich Daten von Nachbarknoten). Die von der verteilten Datenbank bereitgestellte Funktionalität (d. h. Datenspeicherung und Zugriff auf Daten) kann als (systemweiter) Service angesehen werden, während die lokalen Datenbank-Instanzen als lokale Service-Instanzen gedeutet werden können. Der (Gesamt-)Service resultiert hierbei aus der Interaktion der einzelnen Service-Instanzen. Eine Anwendung nutzt die Funktionalität des Datenbank-Services, indem sie auf die lokale Service-Instanz ihres Knotens zugreift. Man beachte, dass eine Koordination zwischen den verschiedenen lokalen Service-Instanzen notwendig ist, wenn Daten einer Instanz des Datenbank-Services in einer anderen Instanz benötigt werden. Somit setzt sich die globale Datenbank aus der Gesamtheit der Instanzen des Datenbank-Services und den Replikationsverbindungen zwischen den einzelnen Instanzen zusammen. Die Verfügbarkeit der Funktionalität eines Services hängt von der Verfügbarkeit seiner Instanzen ab. Im Falle des Datenbank-Services müssen die Instanzen demnach permanent erreichbar (online) sein, damit der Datenbank-Service seine Funktionalität bereitstellen kann.

4.3 Modell eines Service-Managements In diesem Abschnitt wird ein Modell eines Service-Managements vorgestellt. Das Modell umfasst Mechanismen für die flexible Konfiguration, Initialisierung und Verwendung von Services eines FüInfoSys. Unser Modell unterscheidet zwischen einer Initialisierungsphase und der eigentlichen Laufzeitphase des Systems. Wir stellen sowohl Konzepte für die Initialisierungsphase, die sich mit dem Starten und der Initialisierung von Service-Instanzen beschäftigt, als auch ein Konzept für die Verwaltung der Lebenszyklen der Service-Instanzen zur Laufzeit des Systems vor. Ausgangspunkt ist eine Konfiguration des Systems.

50

N. Jansen und M. Spielmann

4.3.1 Abstrakte Konfigurationen Eine abstrakte Konfiguration ist eine formale Repräsentation der Systemkonfiguration und beschreibt, 1. wie sich das Gesamtsystem aus einzelnen Service-Instanzen zusammensetzt, 2. wie diese Service-Instanzen im Netzwerk verteilt werden sollen und 3. wie die einzelnen Service-Instanzen während der Initialisierung des Systems parametrisiert werden sollen. Die Anteile (1–3) können jeweils für verschiedene Einsatzszenarien in der abstrakten Konfiguration vorliegen. Konzeptionell unterscheiden wir bei einer abstrakten Konfiguration Anteile zur Verteilung und Anteile zur Initialisierung des FüInfoSys.

4.3.1.1 Anteile zur Verteilung Wir gehen zunächst auf Verteilungsaspekte in der abstrakten Konfiguration ein. Sie beschreibt unter anderem, wie Service-Instanzen auf konkrete Knoten der Netzwerktopologie abgebildet werden. Beispiele für die Verteilung von ServiceInstanzen in einem FüInfoSys sind in Abb. 4.2 und Abb. 4.3 dargestellt. Hier und im Folgenden werden Service-Instanzen als weiße Ellipsen dargestellt. Darüber hinaus bezeichne „GREL“ einen Service, welcher die Daten, die für das Gemeinsame Rollenorientierte Einsatzlagebild relevant sind, speichert. Jedem Nutzer (beispielsweise Truppenteil: Division, Bataillon oder Kompanie) ist eine Instanz dieses Services zugeordnet. Eine Instanz des GREL-Services verwaltet die Daten, die für den zugehörigen Nutzer (Truppenteil) relevant sind. VIS bezeichnet einen Service, der

XX

(GREL, Div) MN

(VIS, Div))

II 332

GE

I 2

(GREL, Btl) (VIS, Btl))

(GREL, Kp) 332

(VIS, Kp)

Abb. 4.2 Beispiel für die Verteilung von Service-Instanzen: Die Service-Instanzen (GREL, x) und (VIS, x) eines Nutzers x werden jeweils auf dem Knoten des Nutzers ausgeführt

4 Management verteilter FüInfoSys

51

Abb. 4.3 In diesem Beispiel sind die Service-Instanzen aller Nutzer einem einzelnen Knoten (Server) zugeordnet

für die reine Visualisierung (d. h. nicht für die Speicherung) georeferenzierter Daten, an denen der Nutzer interessiert ist, zuständig ist. Abbildung 4.2 zeigt eine Verteilung, bei der verschiedene Service-Instanzen eines Nutzers auf dem gleichen Knoten ausgeführt werden (dem lokalen Host des Nutzers). Abbildung 4.3 zeigt eine alternative Verteilung, die alle Service-Instanzen des Systems einem einzelnen Knoten (Server) zuordnet. Üblicherweise wird eine reale Konfiguration zwischen diesen beiden Extremen zu finden sein. Um das System möglichst flexibel an Änderungen in der Netzwerktopologie anpassen zu können, ist in der abstrakten Konfiguration eine Abstraktion von der konkreten Netzwerktopologie, die aus konkreten Knoten mit IP-Adressen oder HostNamen besteht, vorgesehen. Neben dieser nutzen wir eine abstrakte Netzwerktopologie, in der jeder Knoten einen beliebigen aber festen Knoten (z. B. Rechner) des Netzwerks repräsentiert. Dadurch können Service-Instanzen unabhängig von der jeweiligen Einsatzumgebung beschrieben werden. Weiterhin können verschiedene (Standard-)Konfigurationen in einer abstrakten Weise beschrieben werden. Eine abstrakte Konfiguration enthält zwei Abbildungen. Die Topologie-Abbildung ordnet jeder Service-Instanz einen (abstrakten) Knoten einer abstrakten Netzwerktopologie zu. Jeder abstrakte Knoten wird wiederum durch die Knoten-Abbildung auf einen physikalischen (realen) Knoten abgebildet. Aus einer Verknüpfung der beiden Abbildungen kann für jede Service-Instanz abgeleitet werden, auf welchem Knoten des Netzwerks sie gestartet werden soll. Das Prinzip der abstrakten Konfiguration zeigt Abb. 4.4. Hier wird beispielsweise die Service-Instanz s3 über den abstrakten Knoten a3 auf den Knoten n1 abgebildet. Da die Topologie-Abbildung nur die prinzipielle Verteilung der Service-Instanzen beschreibt, muss bei einer Verlegung eines Systems in ein grundlegend gleich strukturiertes Netz demnach lediglich die Knoten-Abbildung angepasst werden.

52

N. Jansen und M. Spielmann

Konfiguration: Service-Instanzen:

s11

abstrakte Knoten:

TopologieAbbildung:

Knoten:

KnotenAbbildung: a11 n1

s22 a22 s3

n2 a33

s44

Abb. 4.4 Schematische Darstellung einer abstrakten Konfiguration: Eine abstrakte Konfiguration bildet Service-Instanzen auf abstrakte Knoten und abstrakte Knoten auf Knoten des Netzwerks ab Konfiguration: Service-Instanzen: (GREL, Div)

abstrakte Knoten:

Knoten:

Div-Knoten

Div-Host

Btl-Knoten

Btl-Host

Kp-Knoten

Kp-Host

Div

(VIS, Div) (GREL, Btl)

Btl

(VIS, Btl) (GREL, Kp) (VIS, Kp)

Kp

Abb. 4.5 Eine abstrakte Konfiguration, die die Service-Instanzen eines Nutzers (Truppenteils) jeweils bündelt und auf einen Knoten des Netzwerks abbildet

Ein Beispiel für eine abstrakte Konfiguration, die die Service-Instanzen eines Nutzers zusammenfasst und sie auf einen konkreten Knoten des Netzwerks abbildet (entsprechend der Verteilung in Abb. 4.2), zeigt Abb. 4.5. 4.3.1.2 Anteile zur Initialisierung Neben der Verteilung von Service-Instanzen beschreibt eine abstrakte Konfiguration die Initialisierung von Services und Service-Instanzen. Wir unterscheiden permanente Services und sitzungsbezogene Services. Erstere sind Services, deren Instanzen automatisch während der Initialisierungsphase des Systems gestartet werden. Letztere sind Services, deren Instanzen nur bei Bedarf gestartet werden (vgl. Spielmann, in Bearbeitung). In obigem Beispiel (Abb. 4.5) sind die permanenten ServiceInstanzen als weiße Ellipsen mit durchgezogener Linie dargestellt, während sitzungsbezogene Services als weiße Ellipsen mit gestrichelter Linie dargestellt werden. Der Grund für diese Unterscheidung von Services ist, dass manche Services

4 Management verteilter FüInfoSys

53

wie der VIS-Service bei Bedarf (beispielsweise wenn der Nutzer eine neue Sitzung startet) gestartet werden können, während andere Services permanent verfügbar sein müssen (wie in Abschn. 4.2 beschrieben). Zur Parametrisierung der Service-Instanzen werden Konfigurationsparameter in der abstrakten Konfiguration gespeichert. Drei Arten von Konfigurationsparametern sind vorgesehen. Globale Parameter sind für alle Services gültig. Service-Parameter sind nur für einen speziellen Service und szenariospezifische Service-Parameter nur für einen speziellen Service in einem ausgewählten Einsatzszenario gültig. Durch die szenariospezifischen Parameter können verschiedene Einsatzszenarien des Systems bereits vor dem Einsatz vorgesehen werden. Zusätzlich zur Definition von Parametern für mehrere Szenarien enthält die abstrakte Konfiguration die Information, welches Szenario zurzeit ausgewählt ist. Dadurch wird festgelegt, welche Parameter in der aktuellen Konfiguration gültig sind.

4.3.2 Initialisierung von Service-Instanzen In diesem Abschnitt betrachten wir die Initialisierungsphase eines FüInfoSys. Wir beschreiben ein Konzept für das Starten und die Initialisierung der Service-Instanzen eines FüInfoSys gemäß einer vorliegenden abstrakten Konfiguration. Als Teil unseres Modells führen wir ein Service-Management ein. Das ServiceManagement ist als verteiltes System konzipiert, welches für die Initialisierung der Service-Instanzen und die Verwaltung ihrer Lebenszyklen zuständig ist. An jedem Knoten des Netzwerks wird eine lokale Instanz des Service-Managements ausgeführt. Diese ist dafür zuständig, die Lebenszyklen der Service-Instanzen, die diesem Knoten zugeordnet sind, zu verwalten. Abbildung 4.6 zeigt als Beispiel den Einsatz eines Service-Managements in einem Netzwerk mit drei Knoten. Der Verlauf der Initialisierungsphase ist wie folgt: Zuerst liest das ServiceManagement die abstrakte Konfiguration, um zu ermitteln, welche Service-Instanzen gestartet werden sollen, wann sie gestartet werden sollen (während der Initialisierung oder bei Bedarf) und mit welchen Parametern sie initialisiert werden sollen. Anschließend werden die Instanzen der Services, die in der abstrakten Konfiguration als permanente Services kategorisiert sind, gestartet und gemäß den in der

Netzwerkknoten n1 s11

SM (n1)

s22

Netzwerkknoten n2 s33 s44

SM (n2)

Netzwerkknoten n3 SM (n3)

Abb. 4.6 Das Service-Management (SM) in einem Netzwerk mit drei Knoten

s55 s66

54

N. Jansen und M. Spielmann

abstrakten Konfiguration vorgesehenen Parametern konfiguriert. Dies sind die globalen Parameter, die Parameter des Services und die szenariospezifischen ServiceParameter.

4.3.3 Verwaltung der Lebenszyklen der Service-Instanzen In diesem Abschnitt betrachten wir die Laufzeitphase eines FüInfoSys. Die Konzepte für die Laufzeitphase des Systems beschreiben unter anderem, wie zur Laufzeit des Systems auf Service-Instanzen zugegriffen wird. Wenn eine Service-Instanz eine Funktionalität einer anderen Service-Instanz nutzen möchte, muss sie deren Adresse im Netzwerk (IP-Adresse oder Host-Name) kennen. Da die Service-Instanz allerdings auf einem beliebigen Knoten des Netzwerks liegen kann, ist der anfragenden Service-Instanz die Adresse grundsätzlich nicht bekannt. In unserem Modell wird daher für die Adressierung einer Service-Instanz ein abstrakter Identifikator (SID genannt) verwendet, der die Service-Instanz eindeutig bezeichnet. Formal ist eine SID ein Paar bestehend aus dem Namen des Services, der initiiert wurde, und einem Service-spezifischen Instanzbezeichner. Als Beispiel sei auf Abb. 4.5 verwiesen, in der Service-Instanzen durch (a, b), d. h. beispielsweise (GREL, Btl) bezeichnet werden. Eine SID hat keinen direkten Bezug zu Netwerkknoten, sondern abstrahiert von technischen Details wie der Konfiguration und der Netzwerktopologie. Somit kann eine Service-Instanz auf Funktionalitäten anderer Service-Instanzen zugreifen, ohne deren aktuelle (IP-)Adresse (oder Position im Netzwerk) kennen zu müssen. Die zugehörige (IP-)Adresse kann mit Hilfe der SID beim Service-Management erfragt werden. Wenn die angefragte Service-Instanz noch nicht ausgeführt wird, kann sie automatisch durch das ServiceManagement gestartet werden. Abbildung 4.7 zeigt den Nachrichtenfluss beim Senden einer Nachricht von einer Service-Instanz s1 zu einer Service-Instanz s2 . Die Adresse von s2 ist in diesem Beispiel s1 (noch) unbekannt. Weiterhin ist s2 noch nicht gestartet worden. Zuerst erfragt s1 bei der lokalen Instanz des ServiceManagements mit Hilfe der SID die (IP-)Adresse von s2 (vgl. Schritt 1 in Abb. 4.7). Die lokale Service-Management-Instanz ermittelt mittels der abstrakten Konfiguration, auf welchem Knoten n2 die Service-Instanz s2 vorgesehen ist, und startet die Service-Instanz mit Hilfe der Service-Management-Instanz, die auf Knoten n2 ausgeführt wird (Schritte 2 und 3). Hierbei werden die aktuell für den Service gültigen Parameter aus der abstrakten Konfiguration gelesen und an die neue ServiceInstanz übergeben. In Schritt 4 registriert sich die Service-Instanz bei ihrer lokalen Service-Management-Instanz auf Knoten n2 . Diese Registrierung wird an das Service-Management auf Knoten n1 propagiert (Schritt 5), welches die Adresse von s2 an s1 übergibt. Durch Kenntnis der Adresse von s2 kann s1 nun direkt eine Nachricht an s2 senden (Schritt 7). Die Schritte 2 bis 5 fallen nicht an, wenn die Service-Instanz bereits ausgeführt wird. Der Prozess der Adressabfrage (vgl. Abb. 4.7) sollte von einer Middleware übernommen werden und somit transparent für die Service-Instanz sein. Auf diese Weise

4 Management verteilter FüInfoSys

55

Netzwerkknoten n1 s1 (SID1)

Netzwerkknoten n2

SM (n1)

SM (n2)

1: getAddress (SID2) 2: instantiate (SID2)

read parameters 3: create (SID2, params)

s2 (SID2)

4: register (SID2) 5: address (SID2, n2) 6: address (SID2, n2) 7: send (message)

Abb. 4.7 Nachrichtenfluss bei der Abfrage der Adresse einer Service-Instanz beim lokalen Service-Management. Die Anfrage führt zum automatischen Starten der Service-Instanz

können Service-Instanzen miteinander interagieren, ohne Konfigurationsdetails des Gesamtsystems kennen zu müssen. Dies führt zu einer hohen Flexibilität des FüInfoSys, da prinzipiell die dynamische Migration von Service-Instanzen innerhalb des Netzwerks ermöglicht wird. Beispielsweise könnten die Service-Instanzen abhängig von den verfügbaren Kommunikationsbandbreiten so auf die Rechner des Netzwerks verteilt werden, dass die Lastverteilung und die Verfügbarkeit der Daten optimiert wird.

4.4 Zusammenfassung und Ausblick Das in diesem Beitrag vorgestellte Service-Management ist ein verteiltes System, welches die flexible Konfiguration, Initialisierung und Verwendung von Services (bzw. Service-Instanzen) eines serviceorientierten, netzwerkbasierten FüInfoSys ermöglicht. Somit erleichtert das Service-Management die Anpassung des FüInfoSys an verschiedene operative Anforderungen (z. B. Einsatzszenarien, Netzwerktopologien etc.). Dies wird durch die Einführung abstrakter Konfigurationen, bei denen es sich um abstrakte Beschreibungen möglicher Konfigurationen des FüInfoSys handelt, erreicht. Eine abstrakte Konfiguration beschreibt für verschiedene Einsatzszenarien, welche Service-Instanzen Teil des Systems sind, wie sie parametrisiert werden sollen und wie sie im Netzwerk verteilt werden sollen. In der Konfiguration abstrahieren wir durch die Einführung einer abstrakten Netzwerktopologie von der eigentlichen (konkreten) Netzwerktopologie. Hierdurch wird eine abstrakte

56

N. Jansen und M. Spielmann

Beschreibung der Verteilung von Service-Instanzen unabhängig von der konkreten Netzwerktopologie möglich. Weiterhin enthält unser Modell ein Konzept für die Initialisierung des Systems gemäß der abstrakten Konfiguration und ein Konzept für das Auffinden von Service-Instanzen. Der Vorgang der Adressabfrage ist hierbei für den Service transparent. Ausblick. Eine noch zu klärende Fragestellung ist, wie die Adressen von ServiceInstanzen innerhalb des verteilten Service-Managements effizient verwaltet werden können. Die Verwendung einer zentralen Instanz innerhalb des Service-Managements, die für die Verwaltung der Lebenszyklen der Service-Instanzen zuständig ist, wäre eine naheliegende aber zugleich ineffiziente Lösung. Da alle Adressanfragen bei dieser Lösung an die zentrale Instanz gerichtet werden müssten, würde diese in Szenarien mit hunderten oder tausenden Service-Instanzen einen Engpass bzgl. der Kommunikation darstellen. Außerdem wäre die Verfügbarkeit des Gesamtsystems von der Verfügbarkeit bzw. Erreichbarkeit dieser Instanz abhängig. Die Situation verschärft sich noch, wenn wir die dynamische Migration von Services zur Laufzeit des Systems betrachten. In diesem Fall müssten alle Service-Instanzen von der zentralen Instanz des Service-Managements über die geänderten Adressen anderer Service-Instanzen informiert werden. Zur Lösung dieses Problems sollte demnach ein dezentraler Ansatz, in dem die Adressen von Service-Instanzen zwischen den Instanzen des Service-Managements verteilt werden, gewählt werden. Hierfür wird eine Strategie für die effiziente Verteilung der Adressen zwischen den einzelnen Instanzen des Service-Managements benötigt. Ein möglicher Ansatz ist die Anpassung von Protokollen, welche in Peer-toPeer-Systemen verwendet werden, um die Orte von Ressourcen (d. h. die Adressen von Rechnern, die die Ressourcen verwalten) zu propagieren. In solchen Protokollen wird der Ort (die Adresse) einer Ressource ermittelt, indem eine Anfrage mit einer abstrakten ID, welche die gesuchte Ressource repräsentiert, gestellt wird. Durch die Nutzung von SIDs (abstrakten Bezeichnern für Service-Instanzen; vgl. Abschn. 4.3.3) anstelle dieser Ressourcen-IDs könnten diese Protokolle in dem Service-Management zur Abfrage von Adressen von Service-Instanzen verwendet werden. Besonders interessant erscheinen uns Protokolle, die auf verteilten Hashtabellen basieren (vgl. Ratnasamy et al., 2001). In diesem Ansatz werden die Adressen von Ressourcen nicht zentral gespeichert, sondern auf die Knoten des Netzwerks verteilt und dort teilredundant gespeichert. Ein Beispiel für ein solches Protokoll ist Kademlia (vgl. Maymounkov & Mazières, 2002), welches in vielen Peer-to-Peer-Systemen für die Speicherung und die Abfrage von Ressourcen-Adressen verwendet wird. Bei Verwendung dieses Protokolls kann garantiert werden, dass eine Ressource auch in großen Netzen effizient gefunden wird. Weiterhin hat dieses Protokoll geringe Anforderungen an die zur Verfügung stehende Bandbreite und kann mit dem dynamischen Hinzukommen und dem Weggang von Knoten umgehen. Die Verwendung von Protokollen, die auf verteilten Hashtabellen basieren, kann daher einen möglichen Ansatz zur effizienten Adressverteilung zwischen den Instanzen des Service-Managements darstellen. Hierbei ist allerdings zu prüfen, ob in stark eingeschränkten Umgebungen wie takti-

4 Management verteilter FüInfoSys

57

schen Netzen Erweiterungen bzw. Anpassungen der Konzepte, die verteilten Hashtabellen zugrunde liegen, notwendig sind.

Literaturverzeichnis BMVg (2006). Teilkonzeption Vernetzte Operationsführung. MacKenzie, C. M., Laskey, K., McCabe, F., Brown, P., & Metz, R. (2006). Reference Model for Service Oriented Architecture 1.0. OASIS. Maymounkov, P. & Mazières, D. (2002). Kademlia: A Peer-to-Peer Information System Based on the XOR Metric. In 1st International Workshop on Peer-to-Peer Systems (IPTPS) (pp. 53–65). Ratnasamy, S., Francis, P., Handley, M., Karp, R., & Schenker, S. (2001). A Scalable ContentAddressable Network. In SIGCOMM ’01: Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications (pp. 161–172). New York, USA: ACM. Spielmann, M. (in Bearbeitung). Konzeption verteilter Führungsinformationssysteme zur Unterstützung der Vernetzten Operationsführung. FKIE-Bericht, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg.

Kapitel 5

Integration von heterogenen Quellen Thomas Nitsche und Andreas Wotzlaw

5.1 Einleitung Die bei Führungsinformationssystemen zu bewältigende Heterogenität resultiert daraus, dass bestehende Applikationen, Dienste und Subsysteme, welche häufig aus völlig verschiedenen Entwicklungs- und Anwendungsumgebungen stammen, zu einem Gesamtsystem zu integrieren sind. Für die vernetzte Operationsführung (NetOpFü, vgl. BMVg, 2006; Alberts & Hayes, 2003), d. h. die Führung von Streitkräften unter Nutzung eines gemeinsamen, ebenenübergreifenden Kommunikations- und Informationsraums, ist der Zusammenschluss der Informationssysteme aller beteiligten Elemente erforderlich. Dabei ist eine Integration der meist heterogenen Systeme insbesondere bei den lagerelevanten Teilen der FüInfoSys eine enorme Herausforderung. Die Datenformate, welche die Geschäftsobjekte der verschiedenen Anwendungsservices beschreiben und sich in Syntax und Semantik unterscheiden, erschweren die Realisierung des gemeinsamen, homogenen Informationsraums. Die Anpassung der Strukturen der logischen Datenmodelle der verschiedenen Systeme scheidet aufgrund mangelnder Möglichkeiten zur Einflussnahme auf die beteiligten Systeme oder aufgrund des damit verbundenen erheblichen Aufwandes meist aus. Portaltechnologie Mittels Portaltechnik (siehe z. B. NATO – North Atlantic Treaty Organization, 2003) wird versucht, die Integration auf einfache Weise zu realisieren. Dabei werden die jeweiligen Benutzeroberflächen (GUIs, Graphical User Interfaces) der einzelnen Applikationen in verschiedenen Fenstern auf einem Sichtgerät nebeneinander oder hintereinander wiedergegeben. Dem Nutzer bleibt es überlassen, die in den getrennten Fenstern befindlichen Informationen irgendwie zusammenzuführen (siehe Abb. 5.1). Die Verwendung von Portalen im Bereich der FüInfoSys birgt aber aus Nutzersicht eine Reihe von Nachteilen: M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

59

60

T. Nitsche und A. Wotzlaw Portal GUI1

GUI

...

...

GUIn

GUI

Backend

Backend

Applikation1

Applikationn

Abb. 5.1 Grundprinzip der Portaltechnik

1. Mangelnde Geschäftsprozess-Unterstützung. Da die Handlungsabläufe bei der Verwendung eines Portals „applikationsgetrieben“ sind, muss der Nutzer seine Arbeitsschritte an die verfügbaren Funktionen der im Portal eingebundenen Applikationen anpassen. Die daraus resultierenden Geschäftsprozesse sind aus Nutzersicht möglicherweise umständlich und wenig intuitiv. Der Nutzer sieht die Vielschichtigkeit des Systems und muss zur Unterstützung seiner Bearbeitungsschritte die jeweils passende Applikation auswählen. Ziel muss es aber sein, die Komplexität der IT-Technik vor dem Nutzer zu verbergen und ihm stattdessen die für einen Geschäftsprozess benötigten Funktionen automatisch zur Verfügung zu stellen. 2. Mangelnde Anpassung an die aktuelle Lage. Es ist nur schwer möglich, die Funktionalitäten der eingebundenen Applikationen sowie die von den Applikationen bereitgestellten Nutzerschnittstellen an die aktuellen Informationsbedürfnisse des Nutzers (z. B. an dessen aktuellen Auftrag, dessen Absicht, an die ihm zurzeit zur Verfügung stehenden Kommunikationsmittel etc.) anzupassen, weil die eingebundenen Applikationen dafür i. d. R. nicht vorgesehen sind. Die folgenden beiden Nachteile beziehen sich auf die Visualisierung georeferenzierter Daten in Portalen. Ursächlich für die beiden Nachteile ist die Tatsache, dass in einem Portal mehrere Applikationen eingebundenen sein können, welche jeweils eigene, applikationsspezifische Nutzerschnittstellen für die Visualisierung georeferenzierter Daten bereitstellen. 3. Inhomogenität von Sichten. Unterschiedliche Applikationen können unterschiedliche Komponenten (z. B. Geo-Informationssysteme – GIS) zur Visualisierung georeferenzierter Daten verwenden. Dadurch kann sich die Darstellung dieser Daten in den einzelnen applikationsspezifischen Nutzerschnittstellen unterscheiden. Der Nutzer muss also die verschiedenen Darstellungsweisen und Symbolisierungsarten mental abgleichen und ineinander führen, was Belastung erzeugen und zu Fehlinterpretationen führen kann. 4. Fragmentierung der Gesamtsicht. Selbst wenn alle Applikationen dieselben Komponenten zur Visualisierung georeferenzierter Daten verwenden, muss der Nutzer ein visuelles Matching (Abgleichung) von Symbolen und Grafiken sowie deren Positionen und möglicherweise auch Bewegungen und Änderungen (man denke an eine automatisch generierte Forward Line of Own Troops) in den ver-

5 Integration von heterogenen Quellen

61

schiedenen applikationsspezifischen Anzeigen durchführen, um ein (mentales) Gesamtbild der Lage zu erhalten. Dieses visuelle Matching ist eine zusätzliche, mögliche Quelle für Missverständnisse und Fehlinterpretationen. Integrationsportal Zur Beseitigung dieser Schwächen wurde ein neuartiges Portal, im Folgenden Integrationsportal oder kurz IntPortal genannt, entwickelt, welches (Teil-)Lagesichten verschiedener Services in einer integrierten Lagedarstellung vereint und serviceübergreifende Anwenderprozesse unterstützt. Ziel ist eine einheitliche Nutzersicht, die durch ihre reduzierte Komplexität die Entscheidungsprozesse des Nutzers erleichtern und mögliche Fehlinterpretationen vermindern kann (vgl. Ruff-Stahl, 2008). Grundlage für das IntPortal ist eine Integration von (Teil-)Lagesichten verschiedener Applikationen bzw. Services auf Ebene der Visualisierung (Präsentationsschicht). Dabei verwendet man weder eine Integration auf „Pixelebene“, bei welcher die verschiedenen und möglicherweise inkonsistenten GUIs der einzelnen Services unmittelbar dargestellt werden (siehe Abb. 5.1), noch eine vollständige, aber erheblich teurere und aufwendigere semantische Integration der Geschäftsobjekte auf Ebene der Datenhaltungsschicht (Geschäftsobjektschicht). Das IntPortal liegt zwischen diesen beiden Extremen. Das Integrationsportal unterscheidet sich von herkömmlichen Portalen insofern, als dass eine vorherige Angleichung und ggf. Integration der Datenmodelle der partizipierenden Services nicht erforderlich ist. Die Integrationsidee beruht darauf, lediglich die zur Visualisierung erforderlichen Anteile der Geschäftsobjekte zu vereinheitlichen und im IntPortal für die jeweiligen Services gemeinsam darzustellen (siehe Abb. 5.2). Im Kontext des IntPortals wird unter einem Service eine Anwendung verstanden, die einen bestimmten Dienst zur Verfügung stellt. Im militärischen Bereich kann man als Beispiel die Lage-Services zur verteilten Datenhaltung und zum Datenmanagement für lagerelevante Daten in einem FüInfoSys (siehe Kap. 7 sowie Jansen & Nitsche, 2008) oder Befehlsanwendungen (siehe Kap. 11 sowie Spielmann, 2007) nennen. Beispielsweise könnte ein BlueForce-Tracking-Service als ein Service zur Lagegenerierung im globalen Informationsraum des verteilten FüInfoSys die aktu-

GUI Integrationsportal GUI

Backend Applikation1

Abb. 5.2 Grundidee des Integrationsportals

...

GUI

Backend Applikationn

62

T. Nitsche und A. Wotzlaw

elle Lage realisieren, welche z. B. die aktuellen Positionen der eigenen Truppenteile oder die der aufgeklärten, feindlichen Einheiten umfasst. Unser Ansatz ermöglicht es den Services, die zu visualisierenden Anteile ihrer Geschäftsobjekte in Form von zu visualisierenden Elementen (siehe Abschn. 5.2) an das IntPortal zu übergeben. Dieses stellt dafür eine gemeinsame, serviceübergreifende GUI für den Nutzer bereit, in der diese zu visualisierenden Elemente dargestellt werden. In dieser GUI kann der Nutzer die zur Realisierung von Geschäftsprozessen benötigten Funktionen einfach im Kontext der visualisierten Geschäftsobjekte aufrufen. Dadurch können Geschäftsprozesse des Nutzers über Applikationsgrenzen hinweg realisiert und somit aus Nutzersicht intuitiver gestaltet werden. Das IntPortal wird für jeweils einen speziellen Nutzer instanziiert, um ihm seine individuelle Sicht auf das FüInfoSys zu bieten. Dafür wird ein Sitzungsprofil verwendet, welches neben den nutzerspezifischen Zugriffsrechten auch das durch die aktuelle Rolle bzw. Aufgabe des Nutzers bestimmte Interessengebiet festlegt, um eine Informationsüberflutung zu vermeiden (vgl. Kap. 8). Ferner enthält das Sitzungsprofil auch Daten über den Typ und die Kapazität des dem Nutzer zur Verfügung stehenden Endgerätes (vgl. Käthner & Spielmann, 2004). Darüber hinaus soll das IntPortal möglichst viele für die Visualisierung und Manipulation von georeferenzierten Daten benötigte Funktionalitäten und Komponenten von FüInfoSys kapseln. Dazu zählen insbesondere Anteile aus GIS, wie beispielsweise Komponenten zur effizienten Skalierung und Darstellung von Geobasisdaten (z. B. Rasterkarten und Vektordaten) und bereits kommerziell erhältliche Komponenten zur Erzeugung taktischer Symbole und Grafiken. Neben georeferenzierten Daten sollen sich auch andere Fachdaten im IntPortal visualisieren lassen, sofern geeignete Darstellungsmethoden bereitgestellt werden. Die Zugriffsrechte auf Funktionalitäten zur Manipulation georeferenzierter Daten werden dem Nutzer entsprechend seiner jeweiligen Rolle bzw. Aufgabe zur Verfügung gestellt. Das IntPortal ermöglicht eine schrittweise Migration der Applikationen und Services. Dabei werden sukzessive diejenigen Services ins IntPortal integriert, welche die Visualisierung ihrer Geschäftsobjekte bereits durch das IntPortal erledigen lassen, während die anderen Applikationen noch auf herkömmliche Weise in das Portal eingebunden sind. Gounin & Guyard (2005) beschreiben am Beispiel ihres Knowledge Portals, wie eine Anbindung von Applikationen mittels Web-Services realisiert werden kann.

5.2 Integrationskonzept Die Heterogenität der anzubindenden Services impliziert, dass eine Vielzahl unterschiedlicher Geschäftsobjekte zu integrieren ist. Das Integrationskonzept sieht nun vor, diese heterogenen Geschäftsobjekte in der Verantwortung der Services zu belassen und lediglich die zur Visualisierung erforderlichen Anteile dieser Geschäftsobjekte im IntPortal zu vereinheitlichen und darzustellen. Das IntPortal ermöglicht jedem angebundenen Service, visualisierbare Anteile seiner Geschäftsobjekte in Form von zu visualisierenden Objekten oder kurz

5 Integration von heterogenen Quellen

63

V-Objekten im IntPortal zu hinterlegen und in der Präsentationsschicht des IntPortals visualisieren zu lassen (siehe Abb. 5.3). So lassen sich beispielsweise militärische Einheiten durch georeferenzierte V-Objekte repräsentieren und vom IntPortal in einer gemeinsamen Lagekarte als taktische Symbole darstellen. In der Praxis können sich die zu visualisierenden Daten aus den betroffenen Geschäftsobjekten von Service zu Service unterscheiden. Grundsätzlich entscheidet jeder Service selbst darüber, welche Anteile seiner Geschäftsobjekte im IntPortal dargestellt werden. Dazu ist es erforderlich, dass jeder Service seine zu übergebenden Objekte in passende V-Objekte umwandelt. Bei vorhandenen COTS-Systemen ohne Zugriffsmöglichkeit auf den Sourcecode ist dies durch eine zusätzliche Wrapper-Komponente zu realisieren. Die zur Erfüllung der IntPortal-Schnittstelle erforderliche Anpassung der vorhandenen Systeme (bzw. die Entwicklung der Wrapper-Komponente) ist der Preis, der für die bessere Integration zu zahlen ist. Die Hauptaufgabe des IntPortals besteht nun darin, diese servicespezifischen, heterogenen Daten effizient zu verwalten und korrekt und ergonomisch darzustellen. In der Praxis kommt es oft vor, dass verschiedene Geschäftsobjekte eines Services in einer thematischen Beziehung zueinander stehen. Da diese Beziehungen für den Nutzer von großer Bedeutung sein können, werden sie im IntPortal als Informationsgruppen (Info-Gruppen) zusammengefasst. Diese erleichtern dem Nutzer den Überblick über die verschiedenen Arten von V-Objekten und ermöglichen eine Strukturierung der V-Objekte. Als Beispiel kann man alle V-Objekte betrachten, die eigene Truppenteile darstellen sollen („Blue Forces“). Deren Hierarchiestrukturen können dem Nutzer im IntPortal als Info-Gruppen präsentiert werden. In Abb. 5.3 ist beispielsweise eine Info-Gruppe „Blue Force“ mit militärischen Einheiten und deren Beziehungen aus einem BlueForce-Tracking-Service dargestellt. Zur Unterstützung applikationsübergreifender Geschäftsprozesse werden Service-Funktionen verwendet, die im Kontext von V-Objekten aus dem IntPortal her-

V-Objekte Btl 2

BlueForce Tracking Service

Kp 8

Btl 34

Kp 3

Kp 5

Zug 1

IntPortal

Zug 2 Zug 3 Kp 11

Send Mail

Info-Gruppen

Get Status

Blue Force

Blue Force Btl 2

Service-Funktionen

Kp 3

Btl 34

Kp 8

Kp 5

Get Status Zug 1

Wrapper

Mail Service

service output data

Zug 2

Send Mail

Abb. 5.3 Übergabe von V-Objekten, Info-Gruppen und Service-Funktionen ans Integrationsportal

64

T. Nitsche und A. Wotzlaw Zoom in

Zoom out

Move to

Send mail

Peacekeeping in Kabul

FGAN

Straßen

request

Hauptstraßen Straße 1

To:

Straße 2 Autobahn

Zug 1, Zug 2

Mail-Service

Blue Force TaskForce PzGrentBtl332 Kp2

Play Stop Force -element Symbol ID: SFGPBA Istnt : USAF ground scan Name: USAF Parent : ground scan Component : active Info: none

Send mail Get status Info

Zug 1

CC:

Zug 2 Patrouille Straßen Hauptstraßen

Subject:

Warnung

Straße 1 Straße 2 Autobahn Zug 2

PLATO information

S e n d

Text:

Am …

...

... Cancel

I

8./34

II

8./34

Abb. 5.4 Aufruf einer Service-Funktion im Integrationsportal

aus aufgerufen werden. Diese Services sind innerhalb der vorhandenen Systeme implementiert und werden auch dort ausgeführt. Beispielsweise könnte ein MailService die Funktion „Send mail“ für alle eigenen Kräfte (V-Objekte der InfoGruppe „Blue Force“, vgl. Abb. 5.3) bereitstellen, um den durch die V-Objekte repräsentierten Einheiten eine Nachricht senden zu können (siehe Abb. 5.4). Die zu visualisierenden Elemente des IntPortals umfassen die oben beschriebenen V-Objekte, Informationsgruppen sowie Service-Funktionen.

5.3 Architekturkonzept des Integrationsportals Im Folgenden wird das Architekturkonzept für das IntPortal vorgestellt. Für eine ausführliche Darstellung verweisen wir auf (Nitsche & Wotzlaw, 2008). Bei der Konzipierung des IntPortals wurden die folgenden Anforderungen berücksichtigt:  Effiziente Verwaltung von großen und sich schnell ändernden Mengen von zu visualisierenden Elementen.  Entwicklung geeigneter Schnittstellen für die Kommunikation zwischen dem IntPortal und den Services, um die zu visualisierenden Elemente ans IntPortal zu übertragen, zu modifizieren, zu löschen etc.  Bereitstellung von Lösungsstrategien bei Ressourcenkonflikten. Da die verschiedenen Services auf eine einzige GUI zugreifen, müssen die Anfragen der einzelnen Services sowie der verschiedenen Services untereinander im IntPortal derart bearbeitet werden, dass das IntPortal nicht überlastet wird. Wichtige Informationen (z. B. Warnmeldungen) sollen den Nutzer dabei möglichst zeitnah erreichen.  Effiziente Darstellung der zu visualisierenden Elemente in der Nutzerschnittstelle, auch unter Berücksichtigung mobiler Endgeräte.  Geeignete Visualisierung verschiedener Typen von V-Objekten (z. B. taktische Symbole für militärische Einheiten oder Tabellendarstellungen für Statistiken).  Einbindung externer Komponenten an das IntPortal (z. B. GIS).

5 Integration von heterogenen Quellen

65

5.3.1 Aufbau des Integrationsportals Wie bereits erwähnt wird für jeden Nutzer eine eigene Instanz des IntPortals erzeugt. Sie besteht jeweils aus drei Softwarekomponenten (vgl. Abb. 5.5): 1. einem Visual Object Manager zur Verarbeitung der Anfragen der Services und deren zu visualisierenden Elementen, 2. einem Display Manager zur Verwaltung der zu visualisierenden Elemente und deren Vorbereitung für die Darstellung sowie 3. einem Graphical User Interface (GUI) zur Darstellung der zu visualisierenden Elemente und für die Interaktion mit dem Nutzer. Das Instanziieren des IntPortals wird für jeden Nutzer vom IntPortal Manager (vgl. Abb. 5.5) durchgeführt. Dieser wird beim Starten des FüInfoSys erzeugt und steht für alle Instanzen des IntPortals zur Verfügung. Neben der Erzeugung und Initialisierung des IntPortals verwaltet er auch die Nutzerpräferenzen, d. h. die jeweiligen Einstellungen des Nutzers im IntPortal. Beim Abmelden des Nutzers vom System werden diese Nutzerpräferenzen durch den IntPortal Manager gespeichert, während bei der Erzeugung eines IntPortals diese durch den IntPortal Manager mit dem Sitzungsprofil und ggf. mit den früher gespeicherten Nutzerpräferenzen initialisiert werden. Ein sich aus dieser Aufteilung ergebender Vorteil ist die Möglichkeit, das IntPortal an die jeweiligen Bedingungen wie die verfügbare Kommunikationsbandbreite und Kapazität des Endgerätes anpassen zu können, indem die einzelnen Komponenten entsprechend im Netz verteilt werden können. Während die eigentliche GUI direkt auf dem Endgerät des Benutzers ausgeführt wird, können die anderen Teile (insbesondere der Visual Object Manager) bei Bedarf vom Endgerät auf andere Server verlagert werden. Die von den Services ans IntPortal übergebenen Elemente können aufgrund der Heterogenität der Services unterschiedlich zu visualisierende Anteile enthalten. Während die Struktur von Info-Gruppen als Baum darstellbar ist, kann bei V-Objekten je nach Art der in ihnen übergebenen Daten jeweils eine unterschied-

IntPortal

Service 1

GUI

…

Visual Object Manager

Zoom in

Zoom out

Move to Peacekeeping in Kabul

Display Manager

Service n

IntPortal Manager

Abb. 5.5 Aufbau des Integrationsportals und Anbindung der Services

FGAN

Straßen Hauptstraßen Straße 1 Straße 2 Autobahn

Blue Force TaskForce PzGrentBtl332 Kp2

Play Stop

Zug 1 Zug 2

Force -element

Patrouille Straßen

Symbol ID: SFGPBA Istnt : USAF ground scan Name: USAF Parent : ground scan Component : active Info: none

Hauptstraßen Straße 1 Straße 2 Autobahn Zug 2

PLATO information

S e n d

66

T. Nitsche und A. Wotzlaw

liche Visualisierungsart erforderlich sein. Militärische Einheiten lassen sich beispielsweise durch eine geeignete 2D-Darstellung der taktischen Symbole vor dem Hintergrund geeigneten Kartenmaterials darstellen, während andere Arten von VObjekten, z. B. Wetterdaten, Statistiken oder Logistikdaten, eine andere Visualisierung erfordern, beispielsweise in Form von Diagrammen. Zudem können einzelne V-Objekte auch mehrere verschiedene Visualisierungen besitzen, je nach den in ihnen enthaltenen Daten. Um diese Vielfalt der Visualisierungsmöglichkeiten im gemeinsamen IntPortal den Services und dem Nutzer zur Verfügung stellen zu können, werden verschiedene Visualisierungskomponenten zur Darstellung jeweils unterschiedlich zu visualisierenden Arten (bzw. Anteile) von V-Objekten verwendet. Durch die Einbindung von Visualisierungskomponenten können beliebige Arten von V-Objekten im IntPortal visualisiert werden. Ein Beispiel für eine Visualisierungskomponente ist in (Krämer, 2008) beschrieben. Durch dieses Konzept ist das IntPortal auch für zukünftige Visualisierungsarten von Geschäftsobjekten vorbereitet und kann flexibel an neue Services und Darstellungsmöglichkeiten angepasst werden.

5.3.2 Anbindung der Services Die Hauptaufgabe des IntPortals besteht darin, die von Services im IntPortal definierten Objekte (d. h. alle V-Objekte, Info-Gruppen und Service-Funktionen) zu visualisieren. Dies erfolgt mit Hilfe unterschiedlicher Anfragen. Eine Anfrage hat immer als Ziel, eine ihr zugeordnete Aufgabe zu erfüllen (z. B. Aktualisierung von vorgegebenen V-Objekten im IntPortal). Jede Anfrage hat ihren Erzeuger (z. B. einen Service), der sie generiert und an einen Empfänger (z. B. das IntPortal) weiterleitet. Mit jeder Anfrage wird eine Antwort assoziiert, die der Empfänger nach der Bearbeitung einer Anfrage an den Erzeuger sendet. Beispielsweise kann dem Erzeuger der Anfrage im Falle einer fehlgeschlagenen Anfrage eine Fehlermeldung geliefert werden. Es gibt drei Gruppen von Anfragen, die das IntPortal bedienen bzw. erzeugen kann: 1. Service-Anfragen, welche die Services an das IntPortal schicken. Die Services verwenden diese Anfragen, um mit dem IntPortal zu kommunizieren (vgl. Abb. 5.5). Durch diese Anfragen werden im Wesentlichen die zu visualisierenden Elemente im IntPortal hinterlegt oder modifiziert. 2. IntPortal-Anfragen, die vom IntPortal ausgehen und an die Services und den IntPortal Manager gesendet werden. Die Anfragen an die Services dienen dem Aufruf von Service-Funktionen sowie der serviceübergreifenden Integration. Zur Verwaltung des IntPortals (z. B. zur Speicherung der Nutzerpräferenzen) werden Anfragen an den IntPortal Manager verwendet. 3. Manager-Anfragen, die der IntPortal Manager ans IntPortal sendet. Sie unterstützen alle Verwaltungsaufgaben des IntPortals, d. h. alles was Erzeugung, Initialisierung und Modifizierung der jeweiligen, nutzerspezifischen Instanzen betrifft.

5 Integration von heterogenen Quellen

67

Eine ausführliche Darstellung der zugehörigen Protokolle ist in (Nitsche & Wotzlaw, 2008) zu finden.

5.3.3 Kapselung von GIS Für die Darstellung der zu visualisierenden Elemente werden datentyp-spezifische Visualisierungskomponenten verwendet. Georeferenzierte Elemente in Lagekarten lassen sich mit bestehenden GIS visualisieren. Deren Anzeigefunktionalitäten werden in einer speziell dafür entwickelten GIS-Visualisierungskomponente gekapselt. Ziel ist dabei eine möglichst produktunabhängige Anbindung von GIS. Dabei wurde eine allgemeine Schnittstelle entwickelt, über welche diverse GIS-Anteile (z. B. Bibliotheken mit grundlegenden, immer wiederkehrenden Funktionalitäten) möglichst flexibel und serviceunabhängig in FüInfoSys eingebunden werden können. Entsprechend der Grundidee des Integrationsportals (vgl. Abb. 5.2) können dadurch mittel- oder langfristig redundante, applikationsspezifische Visualisierungsanteile in der Präsentationsschicht von FüInfoSys sukzessive eliminiert und im IntPortal gekapselt werden. Dies ermöglicht den dynamischen Austausch von GIS und vereinfacht dadurch die Wartbarkeit bzw. Erweiterbarkeit des Systems. Ferner wird die Komplexität der FüInfoSys-Architektur sowie der einzelnen angebundenen Services reduziert, da diese von Veränderungen am GIS durch die Modularisierung nicht beeinflusst werden. Ein Konzept für eine produktunabhängige Anbindung von GIS bzw. von GISAnteilen in das Integrationsportal wird in (Krämer, 2008) sowie in Kap. 6 detailliert dargestellt.

5.3.4 Konfliktlösungsstrategien Zur Laufzeit können im IntPortal unterschiedliche Ressourcenkonflikte auftreten, die aufgrund eines gemeinsamen und oft gleichzeitigen Zugriffs verschiedener Services auf eine einzige GUI zurückzuführen sind. Die Anfragen der einzelnen Services sowie der verschiedenen Services untereinander müssen im IntPortal derart bearbeitet werden, dass das Endgerät bzw. die GUI nicht überlastet werden. Insbesondere wichtige Elemente (wie z. B. Warnmeldungen) müssen den Nutzer möglichst zeitnah erreichen und dürfen nicht durch die Bearbeitung anderer zu visualisierender Elemente unnötig verzögert werden. Die Lösungsstrategien können daher auch als Optimierungsstrategien angesehen werden, um verschiedene ServiceAnfragen gemäß deren Wichtigkeit bearbeiten zu können. Die vom IntPortal bereitgestellten Konfliktlösungen umfassen Priorisierungsstrategien und Updatestrategien (vgl. Nitsche & Wotzlaw, 2008).

68

T. Nitsche und A. Wotzlaw

Priorisierungsstrategien Die Reihenfolge der empfangenen zu visualisierenden Elemente wird im IntPortal derart abgeändert, dass „wichtige“ Elemente bevorzugt zur Visualisierung weitergeleitet werden. Dazu kann ein Service seinen Anfragen unterschiedliche Prioritätswerte gemäß geltender Priorisierungsstrategie geben, die dann vom IntPortal berücksichtigt werden. Ferner können die einzelnen Services selbst unterschiedlich priorisiert werden. Der Visual Object Manager des IntPortals (siehe Abb. 5.5) verfügt über Mediatoren, welche die Reihenfolge der in ihren Warteschlangen angesammelten Anfragen gemäß deren Priorität anordnen. Jeder Mediator ändert dabei die Reihenfolge der Anfragen in der ihm unterstellten Warteschlange derart, dass die Anfragen mit höherer Priorität schneller als diejenigen mit geringer Priorität zur Visualisierung geliefert werden. Die Priorisierungsstrategien ergeben sich nun indirekt aus den Prioritäten, welche den Services von einer übergeordneten Instanz (z. B. Zugriffskontrolle) verliehen werden. Updatestrategien Ein Service kann möglicherweise sehr viele Updates für seine V-Objekte übermitteln. Da jedoch im Regelfall nur der aktuelle Zustand eines V-Objektes für den Nutzer relevant ist, können ältere, noch nicht an die GUI weitergeleitete Updates eines V-Objektes gelöscht werden und direkt durch den aktuellsten Zustand dieses V-Objektes (d. h. die zeitlich letzte Update-Anfrage) ersetzt werden. Dies vermeidet eine Überlastung der Visualisierungskomponenten der GUI aufgrund zu vieler Änderungen einzelner Objekte. Im IntPortal wird jede Update-Anfrage für V-Objekte einer zusätzlichen Prüfung gemäß einer Updatestrategie unterzogen. Dadurch wird gewährleistet, dass die ankommenden Update-Anfragen nach ihrer Wichtigkeit und Aktualität behandelt werden. Betrachten wir den Fall, dass ein Service seine Anfragen relativ häufig, z. B. mehrmals pro Sekunde, an das IntPortal abschickt. Ein Beispiel dafür wäre ein BlueForce-Tracking-Service (siehe Jansen & Spielmann, 2008; Jansen & Nitsche, 2008), der nicht optimal eingestellt ist. Möchte der Nutzer beispielsweise schnell über mögliche Änderungen von Objekten informiert werden, ohne dass die verwendete Hardware die gewünschte hohe Update-Geschwindigkeit realisieren kann, würde dies zu Problemen führen. Der Service würde nun versuchen, das IntPortal über die Positionsänderungen einer Einheit zu informieren, die er automatisch von einem Tracking-Sensor bekommt. In dieser Situation könnte das IntPortal mit immer neuen Positionsdaten für diese bestimmte Einheit in kurzer Zeit überlastet werden. Dadurch würde die gesamte Leistung der Bearbeitung im IntPortal stark beeinträchtigt. Die Updatestrategie im IntPortal sorgt jedoch dafür, dass dies nicht geschieht und sich im Visual Object Manager stets höchstens eine Update-Anfrage für jedes V-Objekt befindet. Diese Anfrage wird dann immer die aktuellsten Daten für dieses V-Objekt beinhalten, d. h. Daten, die aus allen im IntPortal angekommenen Update-Anfragen als letzte

5 Integration von heterogenen Quellen

69

vom Service für dieses bestimmte V-Objekt generiert wurden, beispielsweise mit den letzten Positionsdaten.

5.4 Schlussfolgerungen Das beschriebene Integrationsportal vereint (Teil-)Lagesichten verschiedener Services in einer gemeinsamen Lagedarstellung und unterstützt serviceübergreifende Anwenderprozesse. Dabei wird eine Integration auf Ebene der Visualisierung verwendet, bei der die Services die zu visualisierenden Anteile ihrer Geschäftsobjekte beim IntPortal zur gemeinsamen Visualisierung hinterlegen können. Mit dem erstellten Architekturkonzept können die folgenden Ziele erreicht werden: 1. Bereitstellung einer zentralen Benutzeroberfläche, in der die zu visualisierenden Daten aller angebundenen Services gemeinsam und serviceübergreifend dargestellt werden. Die Services müssen dadurch zum einen keine eigene GUI bereitstellen. Zum anderen werden durch die zentrale Benutzeroberfläche die Geschäftsobjekte der verschiedenen Services in einer einheitlichen Weise dem Nutzer präsentiert. Dies gilt vor allem für die Lagedarstellung, in der die georeferenzierten V-Objekte aller Services zusammen dargestellt werden, wobei der Nutzer die jeweils sichtbaren Elemente durch die Informationsgruppen auswählen kann. 2. Unterstützung von Geschäftsprozessen: Der Nutzer hat die Möglichkeit, aus dem IntPortal heraus Service-Funktionen aufzurufen. Die dafür benötigten Argumente können direkt im IntPortal vom Nutzer eingegeben werden, z. B. durch direkte Auswahl bestimmter V-Objekte, in dessen Kontext die Funktion ausgeführt werden soll. Dadurch können die einzelnen Applikationen bzw. Services in den Hintergrund treten und perspektivisch die applikationsgetriebenen Geschäftsprozesse durch stärker nutzerorientierte, serviceübergreifende Prozesse abgelöst werden. 3. Kapselung von GIS-Anteilen: Durch die Einbindung von Visualisierungskomponenten ins IntPortal können diverse Funktionalitäten zur Visualisierung von Geschäftsobjekten aus bereits bestehenden Systemen gekapselt und (mittels Wrapper) verwendet werden. Vor allem gilt dies für die Kapselung von GIS-Anteilen, welche die Funktionalitäten bestehender GIS ins IntPortal einbinden. Dadurch können redundante, applikationsspezifische Visualisierungsanteile in der Präsentationsschicht sukzessive eliminiert und die Komplexität der Gesamtarchitektur von FüInfoSys reduziert werden. Langfristig kann zudem untersucht werden, ob das Integrationsportal um einen einheitlichen Mechanismus zum Import bzw. zur systeminternen Referenzierung von Geobasisdaten in FüInfoSys erweitert werden kann. Ein solcher Mechanismus würde die Daten- und Prozessintegration in FüInfoSys noch stärker als in dem vorgestellten Konzept erleichtern.

70

T. Nitsche und A. Wotzlaw

Literaturverzeichnis Alberts, D. S. & Hayes, R. E. (2003). Power to the Edge. Washington, DC: CCRP. BMVg (2006). Teilkonzeption Vernetzte Operationsführung. Gounin, D. & Guyard, A. B. (2005). COP: From Knowledge Webs to Knowledge Portals. In Proceedings of the 10th International Command and Control Research and Technology Symposium McLean, VA. Jansen, N. & Nitsche, T. (2008). LaGe-Service. Technischer Bericht 2008/1, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Jansen, N. & Spielmann, M. (2008). Architecture Concept for a Distributed Database and Data Management System for Disadvantaged Communication Networks. In Proceedings of the Military Communications and Information Systems Conference Krakau, Polen. Krämer, D. (2008). Modulare Anbindung von Geoinformationssystemen an FüInfoSys. FKIEBericht Nr. 170, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Käthner, S. & Spielmann, M. (2004). A base component for future C4ISR systems. In Coalition C4ISR Architectures and Information Exchange Capabilities (RSO-IST-042-RSY-014). Den Haag, Niederlande. NATO – North Atlantic Treaty Organization (2003). WISE Web Information Service Environment. System Architecture Guide. Version 1.1. Norfolk, VA, USA: Allied Command Transformation. Nitsche, T. & Wotzlaw, A. (2008). Konzeption eines Portals zur Integration von Daten aus heterogenen Quellen. FKIE-Bericht Nr. 167, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Ruff-Stahl, H.-J. (2008). Der menschliche Faktor im zukünftigen Kriegsbild – Situation Awareness und Entscheidungsunterstützung in komplexen Systemen. Strategie und Technik, 6-2008, 40–46. Spielmann, M. (2007). Befehlsbearbeitung in Führungssystemen unter Nutzung graphischer Elemente. FKIE-Bericht Nr. 138, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg.

Kapitel 6

Anbindung von Geoinformationssystemen an FüInfoSys Daniel Krämer

6.1 Einleitung Oft ist das Geoinformationssystem (GIS) untrennbar mit Anteilen des FüInfoSys zu einem monolithischen Block verschmolzen. Durch die mangelnde Modularität kann es bei nachträglichen Änderungen oder Erweiterungen des Gesamtsystems zu erheblichen Aufwänden kommen. Solche Änderungen können notwendig sein, um das FüInfoSys an technische (z. B. verfügbare Ressourcen, unterschiedliche Endgerätetypen), operative Gegebenheiten oder Nutzerforderungen anzupassen. Bei gegebener Modularität wäre es dagegen denkbar, für verschiedene Anwendungsbereiche des FüInfoSys unterschiedliche GIS zu verwenden. In Situationen, in welchen nur grundlegende Anzeigefunktionalität benötigt wird, kommt die Nutzung eines frei verfügbaren (kostenlosen) OpenSource-GIS infrage. Wenn also komplexe Analysefunktionalitäten nicht erforderlich sind und einfache GIS-Funktionen ausreichen, könnten durch die Nutzung von OpenSource-GIS meist teure Lizenzgebühren für kommerzielle GIS eingespart werden. Die Qualität von frei verfügbaren OpenSource-GIS ist mittlerweile so gut, dass sie in vielen Punkten Vergleiche mit kommerziellen GIS-Produkten bestehen. Eine modulare Anbindung würde eine Produkt- und Herstellerunabhängigkeit ermöglichen, so dass vorhandene GIS mit wenig Aufwand durch leistungsfähigere ersetzt werden könnten. Außerdem könnten leicht neuere GIS-Versionen installiert werden, ohne dass andere, weite Teile des FüInfoSys betroffen wären. In diesem Kapitel wird ein Ansatz zur produktunabhängigen Anbindung von GIS-Funktionalitäten vorgestellt. Damit ist es möglich, „beliebige“ GIS-Anteile (z. B. Bibliotheken mit grundlegenden, immer wiederkehrenden Funktionalitäten) flexibel und unabhängig von anderen Komponenten in FüInfoSys zu integrieren. Der dynamische Austausch von GIS-Funktionalitäten – sogar zur Laufzeit – wird ermöglicht und die Wartbarkeit bzw. Erweiterbarkeit des Systems wird vereinfacht, da andere Komponenten des FüInfoSys von Veränderungen am GIS durch die Modularisierung nicht beeinflusst werden. Kernpunkt der Anbindung ist eine objektspezifische Anzeigesteuerung. Neben der Anzeige und Steuerung ganzer Karten M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

71

72

D. Krämer

können damit auch einzelne (taktisch relevante) Geofachdaten zur Anzeige hinzugefügt und aktualisiert werden, wodurch eine flexible Erzeugung und Aktualisierung des Gemeinsamen Rollenbasiertes EinsatzLagebildes (GREL) ermöglicht wird.

6.2 Konzeption einer Präsentationsschicht Die Anbindung von GIS-Funktionalitäten erfolgt in der Präsentationsschicht eines FüInfoSys. Um die GIS-Anforderungen aus Abschn. 6.3 nachvollziehen zu können, folgt in diesem Abschnitt zunächst eine Erläuterung der Arbeitsweise einer solchen, für eine GIS-Anbindung geeigneten Präsentationsschicht. Eine ausführlichere Beschreibung findet sich in (Nitsche & Wotzlaw, 2008). Die Präsentationsschicht eines FüInfoSys visualisiert Elemente, die von den angebundenen Systemen (z. B. Legacy-Systemen) bereitgestellt werden, in einer grafischen Nutzeroberfläche (Graphical User Interface: GUI). Militärische Einheiten etwa lassen sich durch eine geeignete 2D- oder 3D-Darstellung der taktischen Symbole oder Grafiken vor dem Hintergrund geeigneten Kartenmaterials visualisieren, da sie über eine Ortsangabe verfügen, wie in der Lage- und Übersichtskarte in Abb. 6.1 gezeigt wird. Andere Arten von Elementen, beispielsweise Wetterdaten, Statistiken oder Logistikdaten, erfordern andere Formen der Visualisierung, beispielsweise in Form von Funktionsverläufen oder Diagrammen. Um derartige unterschiedliche Anteile der Elemente visualisieren zu können, werden externe Software-Plugins benötigt. Diese Plugins, nachfolgend als Visualisierungskomponenten (VisKomps) bezeichnet, füllen jeweils einen Teil der GUI mit einer eigenen Hintergrundanzeige, auf deren Basis sie die an sie übermittelten Elemente visualisieren. Neben der Anzeige der Elemente verarbeiten sie Nutzerereignisse und leiten diese bei Bedarf weiter, etwa, wenn der Nutzer ein Element

Zoom in

Zoom out

Move to Peacekeeping in Kabul

FGAN

Straßen Hauptstraßen Straße 1 Straße 2 Autobahn

Visuelle Meldungen Systeminformationen

Blue Force TaskForce PzGrentBtl332 Kp2

Play Stop

Zug 1 Zug 2

Force -element

Info-Gruppen (z.B. Militärische Hierarchie)

Patrouille Straßen

Symbol ID: SFGPBA Istnt : USAF ground scan Name: USAF Parent : ground scan Component : active Info: none

Hauptstraßen Straße 1 Straße 2 Autobahn Zug 2

PLATO information

S e n d

Statistiken (z.B. Anzahl der Anschläge)

Übersichtskarte

Lagekarte

Abb. 6.1 Beispiel einer graphischen Nutzerschnittstelle (GUI) eines FüInfoSys

6 Anbindung von Geoinformationssystemen an FüInfoSys Wrapper

Legacy System 1

…

Präsentationsschicht

Zugriffskontrolle

Wrapper

Legacy System n

73

Services aus Sicht der Präsentationsschicht

Wrapper Bib 1 (z.B. GisVF)

…

Wrapper

Bib k

externe VisualisierungsKomponenten (z.B. VisKompGisVF)

Abb. 6.2 Visualisierungskomponenten werden an die Präsentationsschicht eines FüInfoSys angebunden

per Mausklick ausgewählt hat. Die Erzeugung und Steuerung der GUI sowie die Kommunikation mit den Services erfolgt durch eine zentrale Steuereinheit der Präsentationsschicht, an welche die Visualisierungskomponenten über eine allgemeine Schnittstelle (vgl. die schwarzen Balken in Abb. 6.2) angebunden werden. Eine Visualisierungskomponente besteht zum einen aus externen Softwarebibliotheken, auf die über eine Programmierschnittstelle (vgl. blaue Balken in Abb. 6.2) zugegriffen wird. Zum anderen enthält jede Visualisierungskomponente einen zusätzlich zu leistenden Implementierungs-Anteil (Wrapper), der die von der Softwarekomponente bereitgestellte Programmierschnittstelle auf die allgemeine Schnittstelle abbildet. Eine zentrale Visualisierungskomponente in FüInfoSys besteht aus GIS-Anteilen, nämlich der Visualisierungs-Funktionalität eines GIS (GisVF). Um den Aufwand für die Realisierung eines entsprechenden Wrappers zu minimieren, muss die von der GisVF bereitgestellte Programmierschnittstelle bestimmte Anforderungen erfüllen. Die Definition dieser Anforderungen ist zentrales Thema von Abschn. 6.3. Dabei wird vorausgesetzt, dass die Geodaten in Datenbanken gespeichert vorliegen, die sich sowohl auf Servern verteilt im Netz befinden können als auch lokal auf dem Endgerät, und dass diese der Präsentationsschicht von Services in Form von Referenzen übermittelt werden.

6.2.1 Steuerung der Präsentationsschicht Ein zu visualisierendes Element, z. B. eine militärische Einheit, soll unter Umständen unterschiedlich in mehreren Visualisierungskomponenten dargestellt werden, möglicherweise als Zeichen in der Lagekarte und gleichzeitig als Eintrag in einer Email-Adressliste. Trotzdem müssen alle Visualisierungen eines Elements dassel-

74

D. Krämer

Wrapper+GisVF

GUI

Menu1

Menu2

Menu3

Menu4 Peacekeeping in Kabul

FGAN

Straßen Hauptstraßen

VisKomp1

Straße 1 Straße 2 Autobahn

Blue Force TaskForce PzGrentBtl332

VisKomp2

Display Manager

VisKomp3 VisKomp4

… VisKompn

Kp2

Play Stop

Zug 1 Zug 2

Force -element

Patrouille Straßen

Symbol ID: SFGPBA Istnt : USAF ground scan Name: USAF Parent : ground scan Component : active Info: none

Hauptstraßen Straße 1 Straße 2 Autobahn Zug 2

PLATO information

S e n d

Abb. 6.3 Die Panels der GUI werden von verschiedenen Visualisierungskomponenten gefüllt. Diese zeigen unterschiedliche Typen von Elementen an

be Geschäftsobjekt referenzieren. Des Weiteren bestehen teilweise Abhängigkeiten zwischen visualisierten Elementen, etwa derart, dass eine Teileinheit nur angezeigt werden soll, wenn die übergeordnete Einheit auch angezeigt wird. Um dies gewährleisten zu können, verwaltet eine zentrale Steuerungskomponente der Präsentationsschicht, nachfolgend als Display Manager (DM) bezeichnet, die zu visualisierenden Elemente und leitet die für die Visualisierung benötigten Anteile weiter an die entsprechenden Visualisierungskomponenten. Diese füllen dann die Panels der GUI (vgl. Abb. 6.3). Die zu visualisierenden Elemente werden aus Effizienzgründen in Form von strukturierten Gruppen (den in Abschn. 6.3 erläuterten Informationsgruppen) an den Display Manager übertragen. Dieser verwaltet die Informationsgruppen und stellt sie in der GUI in Form von Baumstrukturen dar (vgl. Abb. 6.4). Der Nutzer kann nach dem Häkchenauswahlverfahren (vgl. Abb. 6.4 oder Abb. 6.6) per Checkbox diejenigen Elemente in der Baumdarstellung selektieren, die in einer Visualisierungskomponente angezeigt werden sollen. Die zu visualisierenden Anteile der selektierten Elemente werden dann vom Display Manager an die Visualisierungskomponente geschickt, die diese in den ihr zur Verfügung gestellten Panels einblendet. In Abb. 6.4 wurden die selektierten Elemente an die Visualisierungskomponente GisVF geschickt, welche diese in Form von taktischen Symbolen in der Lagekarte anzeigt. Der Vorteil der angestrebten Lösung, also einer zentralen Verwaltungsinstanz für alle zu visualisierenden Objekte gegenüber herkömmlichen Portallösungen ist, dass die einzelnen Visualisierungskomponenten nicht Service-spezifisch arbeiten. Daher genügt es, eine einzige Visualisierungskomponente GisVF für die Visualisierung aller georeferenziert darstellbaren Anteile von Geschäftsobjekten aller Services zu verwenden, und nicht etwa eine Visualisierungskomponente GisVF pro Service,

6 Anbindung von Geoinformationssystemen an FüInfoSys

75

GIS

Zoom in

Zoom out

Move to

TreePanel Peacekeeping

Straßen Hauptstraßen Straße 1 Straße 2 Autobahn

Blue Force TaskForce PzGrentBtl332 Kp2 Zug 1 Zug 2 Patrouille Straßen Hauptstraßen Straße 1 Straße 2 Autobahn Zug 2

Abb. 6.4 Die in der Baumdarstellung per Häkchen selektierten Elemente des Baumes werden in der Karte angezeigt

wie oftmals bei einer herkömmlichen Portallösung erforderlich. Dadurch wird zum einen eine homogene Darstellung aller Geodaten erreicht, zum anderen ist es nun möglich, alle georeferenzierten Elemente in einem (Gesamt-)Lagebild anzuzeigen. Weiteres Fehlerpotential wird dahingehend minimiert, dass Veränderungen eines Geschäftsobjektes, wie z. B. Status-Änderungen im Objekt selber in der lokalen Datenhaltung des Display Managers gespeichert und damit in allen Visualisierungskomponenten gleichzeitig wirksam werden. Somit können durch mehrdeutige Darstellungen verursachte Fehlinterpretationen vermieden werden, indem eine zeitliche Synchronisation der Visualisierungen durch den Display Manager erfolgt (vgl. Abschn. 6.3.3).

6.3 Anforderungen an die Visualisierungsfunktionalität GIS In diesem Abschnitt werden die grundlegenden Anforderungen, die die Visualisierungsfunktionalität GIS (GisVF) für eine erfolgreiche Anbindung an die in Abschn. 6.2 beschriebene Präsentationsschicht erfüllen muss, erläutert. Dies sind

76

D. Krämer

z. B. Funktionalitäten, die es ermöglichen, die Kartenanzeige in eine bestehende Oberfläche zu integrieren, eine objektspezifische Anzeigesteuerung der Geodaten und die Synchronisation der Anzeige mit anderen Visualisierungskomponenten. Außerdem wird auf die Darstellungsreihenfolge bei überlappenden Objekten sowie eine Kontext-Menu-Funktionalität zur verbesserten Unterstützung Serviceübergreifender Geschäftsprozesse eingegangen. Eine ausführliche Beschreibung der Anforderungen findet sich in (Krämer, 2008).

6.3.1 Integration in eine bestehende Oberfläche Im Rahmen einer Initialisierungsphase der Präsentationsschicht wird vom Display Manager die GUI mit zunächst leeren Panels erstellt, welche dann von der Visualisierungskomponente GisVF bzw. den anderen Visualisierungskomponenten gefüllt werden. Dabei sind Panels unterschiedlicher Typen vorgesehen, u. a. ein (großes) Hauptkartenfenster mit dem aktuell angezeigten Kartenausschnitt, ein (kleineres) Übersichtkartenfenster zur Steuerung des großen Kartenausschnittes, ein Navigationspanel mit Navigationswerkzeugen sowie ein Toolbarpanel mit Editierfunktionalität für Geodaten. Die GisVF ist dafür verantwortlich, dass die Kartenanzeigen aller ihr zugewiesenen Panels synchronisiert sind. Das bedeutet, dass sich beispielsweise eine vom Nutzer durchgeführte Navigation in der Karte automatisch auf Hauptkartenfenster und Übersichtskartenfenster auswirkt, gleichgültig von wo aus diese gesteuert wird. Ebenso werden vom Display Manager initiierte Veränderungen an Elementen in allen Panels übernommen. Für die initialisierten Panels muss die GisVF eine eigene Event-Verwaltung bereitstellen, so dass beispielsweise Mausklicks erkannt und entsprechend verarbeitet werden. Klickt der Nutzer auf eine Grafik, so muss diese Auswahl an den Display Manager weitergeleitet werden. Dieser erkennt dann, welcher Service das vom Nutzer ausgewählte Geschäftsobjekt bereitstellt, und leitet bei Bedarf die Auswahl an diesen weiter.

6.3.2 Objektspezifische Anzeigesteuerung Mit zunehmender Informationsmenge ist es von großer Wichtigkeit, die Menge der anzuzeigenden Geodaten einschränken bzw. flexibel steuern zu können. Oftmals werden vorgefertigte Gruppierungen von Geodaten, so genannte Layer, bei Generierung des GREL übereinander gelegt. Eine derartige „layerweise“ Anzeigesteuerung ist jedoch nur bedingt flexibel und effizient, da Geodaten nicht einzeln aktualisiert bzw. zur Anzeige hinzugefügt werden können. Falls beispielsweise Geodaten unterschiedlicher Typen (und damit aus unterschiedlichen Layern) gleichzeitig angezeigt werden sollen, so müssen die entsprechenden Layer, selbst wenn nur wenige Daten

6 Anbindung von Geoinformationssystemen an FüInfoSys

77

wirklich von Interesse sind, jeweils vollständig eingeblendet werden, was rasch zu einer Informationsüberflutung führen kann. In einem GREL gibt es unter Umständen relevante Geodaten aus vielen verschiedenen Layern. Als Beispiel wird in Abb. 6.5 ein Patrouillenszenario betrachtet, in welchem unterschiedliche Typen von Geodaten relevant sind, die aus unterschiedlichen Layern stammen. Neben einer Rasterkarte map1 aus einem Rasterlayer werden die Straßen road1, road2 und road3 aus einem Vektorlayer und militärische Symbole, bestehend aus eigenen, feindlichen und neutralen Kräften, die als blaue, rote und gelbe Objekte symbolisiert werden, benötigt. Natürlich sollten nur die für die Patrouille relevanten Geodaten eingeblendet werden und nicht etwa die fünf vollständigen Layer. Des Weiteren kann sich zum einen die Relevanz während eines Einsatzes ändern, d. h. es muss beispielsweise eine strategisch wichtige Brücke angezeigt werden, die vorher nicht von Interesse war. Zum anderen ändert sich unter Umständen auch die Granularität der anzuzeigenden Daten. Ein Trupp, welcher einen wichtigen Befehl ausführt, soll womöglich angezeigt werden, ohne dass alle anderen Trupps des Layers eingeblendet werden. Möglicherweise ändern sich manche Geodaten auch häufiger als andere. Es ist beispielsweise sinnvoll, die Position eines Kampfflugzeugs häufiger zu aktualisieren als die eines Flugzeugträgers, da dieser seine Position nur relativ langsam ändert. Trotzdem könnten aber beide Objekte in einem Layer gespeichert sein, da sie vom Typ „Punkt“ sind. Eine objektspezifische Anzeigesteuerung ist daher eine zentrale Bedingung, die an die GisVF gestellt wird. Bedingt durch die Vielzahl der zu visualisierenden Elemente und Visualisierungsanteile werden die Elemente in (Nitsche & Wotzlaw, 2008) statt in vorgefertigte Layer in beliebig strukturierbare Informationsgruppen (vgl. Abb. 6.6) zusammengefasst. Informationsgruppen können zur Laufzeit sowohl vom Nutzer als auch von

map1 map2 map3 …

road1 road2 road3 …

entity1 entity2 entity3 …

aircraft vehicle1 vehicle2 …

„Patrouille“ ambush

map1 entity1 road2

aircraft road1 road3

Abb. 6.5 Beispiel „Patrouillenszenario“

ambush tank aircraft …

78

D. Krämer

Peacekeeping

Straßen Hauptstraßen Straße 1 Straße 2 Autobahn

Blue Force TaskForce PzGrentBtl332 Kp 2 Zug 1 Zug 2 Patrouille Straßen Hauptstraßen Straße 1 Straße 2 Autobahn Zug 2 Abb. 6.6 Mit Hilfe des Informationsgruppenbaumes kann die Anzeige von Geodaten in der Karte gesteuert werden

Services erzeugt und verändert sowie vom Display Manager verwaltet werden. Die „Häkchenselektion“ auf den Knoten der Informationsgruppen steuert die Anzeige in den Visualisierungskomponenten, z. B. die Kartenanzeige der GisVF. Dieses Konzept ermöglicht es, beliebige Gruppierungen von Geodaten anzulegen und Teilmengen dieser Gruppen bei Bedarf einzublenden. Um das Informationsgruppenkonzept umsetzen zu können, muss die GisVF in der Lage sein, die Anzeige objektspezifisch zu steuern. Neben vollständigen Layern müssen daher einzelne

6 Anbindung von Geoinformationssystemen an FüInfoSys

79

Grafiken erzeugt bzw. ein- und ausgeblendet werden können. Außerdem können mit dem Informationsgruppenkonzept bekannte flexible Steuerungsmuster wie z. B. ein Email-Ordner-System oder ein Bookmark-Manager umgesetzt werden, vorausgesetzt die entsprechenden Visualisierungskomponenten sind verfügbar.

6.3.3 Zeitliche Synchronisation von Visualisierungskomponenten Um die verschiedenen Visualisierungen eines Geschäftsobjektes, nachfolgend Grafiken genannt, gleichzeitig in allen Visualisierungskomponenten ein- bzw. auszublenden, bedarf es einer Synchronisationsstrategie. Wir unterscheiden zwischen der Erzeugung und der eigentlichen Anzeige einer Grafik, da in exemplarisch betrachteten GisVF festgestellt wurde, dass der Vorgang zur Erzeugung einer Grafik teilweise länger dauerte als der Anzeige- bzw. der Ausblende-Vorgang. Die Geschwindigkeit, mit der eine Visualisierungskomponente eine Grafik erzeugen und anzeigen bzw. ausblenden kann, hängt von zahlreichen, zum Teil unbekannten Faktoren ab. Beispielsweise spielt die Leistung des Endgerätes (die wiederum beeinflusst wird durch Speicherkapazität, Taktung, Chipsatz, Caching-Strategien usw.) eine Rolle. Ein anderer wichtiger Faktor ist die Systemauslastung, die wiederum von anderen laufenden Prozessen abhängig ist. Zudem bringt eine hochkomplexe Synchronisationsstrategie Performanceeinbußen mit sich, so dass sie ab einer bestimmten Granularität für Echtzeitanwendungen nicht mehr verwendbar sein kann. Die GisVF muss daher die Mechanismen für die Umsetzung einer beliebigen vorgegebenen Synchronisationsstrategie bereitstellen. Der vorgesehene Mechanismus arbeitet folgendermaßen: Jede Visualisierungskomponente wird zunächst aufgefordert, die Grafik zu erzeugen und zwei mehr oder weniger genaue Zeitwerte an den Display Manager zurückzuliefern. Diese Zeitwerte geben die Zeiträume an, die die Komponente voraussichtlich braucht, um die erzeugte Grafik vollständig zu zeichnen bzw. wieder auszublenden. Der Display Manager fordert, nachdem er von allen Komponenten Rückmeldung erhalten hat, die Komponenten auf, die Grafik anzuzeigen (bzw. auszublenden). Dabei übergibt er einen nach einer beliebigen Strategie berechneten Verzögerungszeitwert. Die langsamste Komponente beginnt dann zuerst mit dem Zeichen- bzw. Ausblendevorgang, die anderen entsprechend ihrer benötigten Zeit später, so dass alle gleichzeitig (nach Ablauf der durch den Verzögerungszeitwert definierten Zeitspanne) fertig sind. Die Effizienz dieses Mechanismus hängt von der Strategie sowie der Wahl geeigneter Abbruchkriterien ab. Beispielsweise wäre es denkbar, in Systemen mit großen Performanceschwankungen der einzelnen Visualisierungskomponenten (wenn es z. B. nur eine langsame Komponente gibt, die anderen jedoch alle annährend gleich schnell sind), eine obere Schranke für den Verzögerungszeitwert einzuführen oder die langsame Komponente ganz aus der Synchronisationsstrategie herauszunehmen.

80

D. Krämer

6.3.4 Darstellungsreihenfolge überlappender Grafiken Die Reihenfolge, in welcher überlappende Grafiken dargestellt werden, sollte vom Nutzer modifizierbar sein, da es unter Umständen sinnvoll ist, eine verdeckte Grafik, welche plötzlich im Rahmen einer veränderten Lagesituation bedeutend ist, in den Vordergrund zu holen. Dabei reicht es nicht aus, alle gleichartigen Grafiken (etwa alle Straßen eines Layers) in den Vordergrund zu holen, da dadurch wiederum andere wichtige Grafiken verdeckt werden könnten. Andererseits ist es aber in der Regel auch nicht notwendig, explizit die Gesamtordnung aller aktuell angezeigten (unter Umständen mehreren tausend) Elemente ändern zu können, wenn sich nur wenige Elemente überlappen. Vielmehr muss gewährleistet werden, dass die Darstellungsreihenfolge von ausgewählten Elementen zumindest innerhalb einer lokalen, relativ kleinen Umgebung vom Nutzer verändert werden kann. Auf der Menge aller Elemente sollte eine „gröbere“ Ordnung ausreichen, beispielsweise in Form einer Ordnung der angezeigten Informationsgruppen. Diese gröbere Ordnung kann initial vom Display Manager erzeugt werden, indem er die einzelnen Grafiken in der entsprechenden Reihenfolge weiterleitet und diese dann übereinander gezeichnet werden. Eine Möglichkeit, dem Nutzer die Modifikation zur Laufzeit zu ermöglichen, wäre es, die GisVF eine Zwischenablage zur Verfügung stellen zu lassen, in welcher der Nutzer Grafiken als Liste gemäß ihrer Darstellungsreihenfolge festhalten und diese modifizieren kann. Denkbar wäre es, beliebige Elemente per Mausklick oder Auswahlrechteckwerkzeug in der Karte auszuwählen und in die Zwischenablage zu kopieren. Auf dieser lokalen Auswahl könnte der Nutzer dann die Darstellungsreihenfolge der Grafiken modifizieren, indem er die Liste entsprechend ordnet. Die Grafiken würden dann von der GisVF in der neuen Reihenfolge vor allen anderen (nicht ausgewählten) Grafiken in der Karte angezeigt. Bei erneuter Auswahl würde der beschriebene Vorgang wiederholt. Die Veränderung der Darstellungsreihenfolge ist ein GisVF-interner Vorgang, die neue Reihenfolge sollte jedoch trotzdem an den Display Manager übermittelt werden, damit diese z. B. bei einer späteren Sitzung wiederhergestellt werden kann.

6.3.5 Kontext-Menu-Funktionalität Um serviceübergreifende Geschäftsprozesse besser unterstützen zu können, sieht es das Konzept der Präsentationsschicht vor, an einzelne Elemente Servicefunktionen zu heften, auf die der Nutzer im Rahmen eines Kontext-Menus zugreifen kann. Dann kann beispielsweise über ein Element in der Lagedarstellung eine EmailFunktionalität, die von einem Email-Service bereitgestellt wird, aufgerufen werden. Der Service kann dann einen Email-Editor mit der entsprechenden Email-Adresse des zugehörigen Geschäftsobjektes öffnen. Zu diesem Zweck muss die GisVF eine Kontext-Menu-Funktionalität bereitstellen und es ermöglichen, neben bereits

6 Anbindung von Geoinformationssystemen an FüInfoSys

81

vorhandenen GisVF-internen Funktionseinträgen eigene Einträge zu den KontextMenus einzelner Grafiken hinzuzufügen. Zusätzliche Funktionalitäten, die die GisVF bereitstellen muss, sind u. a. die Möglichkeit, den angezeigten Kartenausschnitt, Projektionsart und Skalierungsfaktor zu steuern. Des Weiteren werden Mechanismen zur Umsetzung vertrauter Verhaltensweisen, wie etwa das Unterlegen (highlighten) einzelner Elemente oder das Erscheinen von Tooltips bei Mauszeigerberührung benötigt.

6.4 Zusammenfassung Mit Hilfe der Kapselung von Visualisierungsfunktionalität GIS (GisVF) wird eine produktunabhängige Anbindung sowie der einfache Austausch (beliebiger) GisVF in FüInfoSys erreicht. Es wird dabei Funktionalität betrachtet, die es ermöglicht, die Anzeige von Geodaten mit Hilfe einer externen Komponente (dem Display Manager) zu steuern, sie mit anderen Visualisierungskomponenten zu synchronisieren und Servicefunktionen per Kontext-Menu über georeferenzierte Objekte in der Lagekarte aufzurufen. Eine objektspezifische Anzeigesteuerung ermöglicht die Umsetzung eines flexiblen Strukturierungskonzeptes (vgl. Informationsgruppenkonzept in (Nitsche & Wotzlaw, 2008)) sowie der initialen Steuerung der Darstellungsreihenfolge bei überlappenden Grafiken. Die Darstellungsreihenfolge kann in diesem Fall vom Nutzer zur Laufzeit verändert werden, z. B. mit Hilfe einer Zwischenablage. Weiterhin können von der GisVF bereitgestellte Zooming-, Analyse- und Filterfunktionen auf den angezeigten Geodaten in gewohnter Weise ausgeführt werden, sie werden jedoch nicht extern gesteuert. Dennoch kann eine Auswahl von Geodaten z. B. mit Hilfe von Filterfunktionen getroffen werden, die dann vom Display Manager erkannt und weiterverarbeitet wird. Eine ausführliche Erläuterung sowie die Ergebnisse einer exemplarischen Untersuchung verschiedener GIS im Hinblick auf die beschriebene Kapselung findet sich in (Krämer, 2008).

Literaturverzeichnis Krämer, D. (2008). Modulare Anbindung von Geoinformationssystemen an FüInfoSys. FKIEBericht Nr. 170, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Nitsche, T. & Wotzlaw, A. (2008). Konzeption eines Portals zur Integration von Daten aus heterogenen Quellen. FKIE-Bericht Nr. 167, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg.

Kapitel 7

Dynamische Verteilung von Daten in taktischen Netzen Norman Jansen und Marc Spielmann

7.1 Einleitung Aufgrund des veränderten Einsatz- und Aufgabenspektrums der Bundeswehr im internationalen Umfeld ergeben sich zur Unterstützung der Vernetzten Operationsführung (NetOpFü; BMVg, 2006) neue Anforderungen an FüInfoSys. Eine wesentliche Aufgabe zukünftiger FüInfoSys ist hierbei die verzugsarme und unterbrechungsfreie Informationsversorgung auf und zwischen allen Truppenteilen, d. h. die Schaffung eines streitkräftegemeinsamen, ebenenübergreifenden Kommunikations- und Informationsraums (BMVg, 2006). Für die Realisierung eines solchen gemeinsamen Informationsraums ist eine vollständige Integration aller Truppenteile auf allen Führungsebenen in ein durchgängiges Gesamtsystem notwendig. Insbesondere die nahtlose Integration der taktischen Ebene hat einen besonderen Stellenwert, da grundlegende Informationen wie bspw. die Positionen und Status eigener Truppenteile ursprünglich von dieser Ebene bereitgestellt werden. Demnach muss die Architektur des FüInfoSys die besonderen Randbedingungen der taktischen Ebene berücksichtigen. So handelt es sich bei taktischen Netzwerken üblicherweise um Funknetze im UHF- bzw. VHF-Band. Diese zeichnen sich aufgrund der verwendeten Funkgeräte und der physikalischen Effekte der Funkübertragung (Interferenz, Abschattung etc.) durch sehr schmalbandige, oft unzuverlässige Kommunikationsverbindungen mit einer hohen und variablen Latenz aus. Aufgrund der Mobilität der Teilnehmer und der variierenden Kommunikationseigenschaften muss im taktischen Bereich von einer dynamischen Netzwerktopologie, in der Teilnehmer ad hoc miteinander kommunizieren, ausgegangen werden. Es liegen also mobile Ad-hoc-Netze (MANETs) vor, die eine besondere Herausforderung an die Kommunikationssysteme darstellen. Auch im zivilen Bereich zeichnet sich der Trend hin zu mobilen Endgeräten ab. Allerdings beschränkt sich die Dynamik der Netzwerktopologie im zivilen Bereich üblicherweise auf die Anbindung der Endgeräte. So sind beispielsweise die Endgeräte in heutigen Mobilfunknetzen über stationäre Basisstationen angebunden. Weiterhin stehen im zivilen Bereich zunehmend höhere Bandbreiten zur Verfügung (beispielsweise durch Technologien wie UMTS, WiM. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

83

84

N. Jansen und M. Spielmann

MAX), während die Einschränkungen der militärischen Netze auf absehbare Zeit hinsichtlich Übertragungskapazität bestehen bleiben. Aus den genannten Gründen sind Technologien aus dem zivilen Bereich zurzeit nur bedingt auf den militärischen Bereich übertragbar. Für die Realisierung des von NetOpFü geforderten ebenenübergreifenden Informationsraums sind unter oben beschriebenen Kommunikationseinschränkungen neue Lösungsansätze notwendig. Da die Erreichbarkeit von einzelnen Teilnehmern/Knoten aufgrund der Kommunikationsproblematik nicht gewährleistet werden kann, müssen Redundanzen in das System eingeführt werden, um die systemweite Verfügbarkeit von Informationen zu sichern. Eine zentrale Datenhaltung hätte zwar die Vorteile eines geringen Wartungsaufwands und leicht zu realisierender Datenkonsistenz, ist aber aufgrund der eingeschränkten Kommunikation und der Forderung nach zeitweise autarken Endgeräten ungeeignet. Stattdessen sollte eine verteilte Datenbank eingesetzt werden. Diese besteht aus lokalen Datenbankinstanzen, die auf verschiedene Knoten des Netzwerks verteilt sind. Wegen der Einschränkungen der taktischen Ebene muss besondere Sorgfalt getroffen werden, um die zwischen den Knoten zu übertragende Datenmenge, die für die Sicherstellung der Konsistenz der Daten notwendig ist, gering zu halten. Deshalb sollte jeder Truppenteil stets nur mit den Informationen versorgt werden, die er in der aktuellen Situation benötigt. Dies gestaltet sich unter den Randbedingungen von NetOpFü schwierig, da sich die Informationsbedarfe der verschiedenen Truppenteile dynamisch mit der Auftragssituation ändern können. Aus diesem Grund sollte die Datenverteilung einfach konfiguriert werden können. Zur Konfiguration des Systems wird ein Datenmanagement-System benötigt, welches insbesondere festlegt, welche Daten zwischen welchen Nutzern des Systems ausgetauscht werden. Mit Hilfe des Datenmanagement-Systems kann eine dezentrale Organisationseinheit zum Datenmanagement (Datenadministratoren) das System netzwerkbasiert mit einem geringen Aufwand, insbesondere ohne Programmierung, an geänderte Auftragslagen (und damit geänderte Informationsbedarfe) anpassen. In diesem Beitrag wird ein Modell eines verteilten Datenhaltungs- und Datenmanagement-Systems vorgestellt. Das Modell kann als Grundlage für die Entwicklung von Datenmanagement-Systemen für militärische Netzwerke dienen. Wesentliches Merkmal des Modells ist eine verteilte Datenhaltung, die an die besonderen Randbedingungen militärischer Netzwerke angepasst ist. Zur Konsistenthaltung der lokalen Instanzen der verteilten Datenhaltung stellen wir ein Replikationsverfahren, welches in Netzen mit geringen Bandbreiten und instabilen Verbindungen eingesetzt werden kann, vor. Darüber hinaus umfasst das Modell DatenmanagementMechanismen zur Steuerung der Initialisierung des Systems und zur Steuerung der Verteilung (Replikation) der Daten zwischen den lokalen Instanzen der verteilten Datenhaltung. Damit ist eine einfache Konfiguration des Systems durch Datenadministratoren möglich. Der Beitrag gliedert sich wie folgt: Die wesentlichen Aspekte des Modells werden im nächsten Abschnitt beschrieben. Eine Detaillierung folgt in Abschn. 7.3. Der Beitrag schließt mit einer Zusammenfassung und einem Ausblick auf zukünftige Arbeiten in Abschn. 7.4.

7 Dynamische Verteilung von Daten in taktischen Netzen

85

7.2 Übersicht über das Modell Zentrale Aufgabe eines verteilten Datenhaltungs- und Datenmanagement-Systems für militärische Netze ist die Steuerung der Verteilung sowie die Wahrung der Konsistenz von Datenobjekten. Aufgrund der Kommunikationsbeschränkungen in militärischen Netzen sollten die Datenobjekte so verteilt werden, dass jede Anwendung möglichst lokal auf die von ihr benötigten Datenobjekte zugreifen kann. Die Verteilung der Datenobjekte bietet jedoch nur Vorteile, wenn der Mehraufwand für die Wahrung der Konsistenz (Replikation) die Vorzüge der lokalen Speicherung nicht übersteigt. Mit dieser Zielsetzung wurde das folgende Modell entwickelt. Lokale Objektdatenbanken. Konzeptionell wird jedem Nutzer (Person, Truppenteil, Rolle, Organisationseinheit etc.) eine lokale Datenbankinstanz zugeordnet. In dieser lokalen Datenbankinstanz sind die für den Nutzer relevanten Daten gespeichert. Der Nutzer greift ausschließlich über seine (lokale) Datenbankinstanz auf die Daten zu. Möchte der Nutzer auf Daten zugreifen, die nicht in seiner Datenbankinstanz vorgehalten werden, werden diese Daten zu seiner Instanz repliziert. Wir setzen voraus, dass die Anwendungen eines Nutzers und die Datenbankinstanz des Nutzers auf dem selben Knoten im Netzwerk ausgeführt werden. Außerdem setzen wir voraus, dass die Daten gemäß eines objektorientierten Datenmodells (vgl. Abschn. 7.3.1) repräsentiert sind. Wir bezeichnen daher im Folgenden die Datenbankinstanz eines Nutzers als Objektdatenbank (kurz: ODB). Man beachte, dass unsere Annahme, dass jedem Nutzer eine eigene ODB zugeordnet ist, nicht bedeutet, dass ODBs verschiedener Nutzer zwangsläufig auf verschiedenen Knoten des Netzwerks liegen müssen. Vielmehr handelt es sich bei ODBs um logische Einheiten, die beliebig auf Knoten des Netzwerks verteilt werden können. Dieser Sachverhalt ist in Abb. 7.1 dargestellt. Ein Rechteck repräsentiert eine ODB eines Nutzers mit seinen zugehörigen Anwendungen. In der ODB sind die Datenobjekte gespeichert, die für den Nutzer (bzw. die zugehörigen Anwendungen) Nutzer A Anwendung A1 API ODB (A)

Anwendung Ak

Nutzer B Anwendung B1 API ODB (B)

Anwendung Bl

Nutzer C Anwendung C1 API ODB (C)

Anwendung Cm

Abb. 7.1 Schematische Darstellung der ODBs von drei verschiedenen Nutzern

86

N. Jansen und M. Spielmann

relevant sind. Die Datenobjekte werden mittels eines Replikationsverfahrens, welches Gegenstand von Abschn. 7.3.2 ist, zwischen den einzelnen ODBs verteilt. Auf die in der Abbildung rot dargestellten Kommunikationsverbindungen wird weiter unten eingegangen. Initialisierungskomponente. Wir unterscheiden zwischen einer Initialisierungsphase und der eigentlichen Laufzeitphase. Die Initialisierungsphase wird durch eine Initialisierungskomponente (vgl. Abb. 7.2) gesteuert. In der Initialisierungsphase werden zuerst initiale Grunddaten, die in der Initialisierungskomponente verwaltet werden, zu den einzelnen ODBs repliziert. Hierfür besitzt die Initialisierungskomponente ebenfalls eine ODB. Nach der Initialisierungsphase befinden sich alle ODBs in einem wohldefinierten Anfangszustand. Das System wechselt unmittelbar darauf in die Laufzeitphase, in der Daten zwischen den (eigentlichen) ODBs repliziert werden. Die beiden Phasen werden in Abschn. 7.3.3 genauer betrachtet. Kommunikationsverbindungen. In unserem Modell wird zwischen Kommunikationsverbindungen, die zur Laufzeit des Systems für die Replikation verwendet werden (in Abb. 7.2 rot dargestellt) und Kommunikationsverbindungen, die für die Initialisierung des Systems bzw. einzelner ODBs genutzt werden (grün dargestellt), unterschieden. Die zur Laufzeit für die Replikation verwendeten Verbindungen werden aufgrund der Einschränkungen der taktischen Ebene als schmalbandig und instabil angenommen, während die zur Initialisierung des Systems genutzten Verbindungen als stabil und breitbandig angenommen werden. Die Anwendungen können über eine spezielle Schnittstelle (API) auf ihre jeweilige ODB zugreifen. Diese Schnittstelle sollte Methoden für den Zugriff auf Datenobjekte und für die Erstellung, Änderung und das Löschen von Datenobjekten bereitstellen. Des Weiteren sollte die Schnittstelle Methoden für die Konfiguration der ODB vorsehen.

Nutzer A Anwendung A1 API ODB (A) Init

Anwendung Ak

Nutzer B Anwendung B1 ODB ODB(Init) (Init)

API ODB (B) Init

DB DB

InitialisierungsInitialisierungskomponente komponente

Anwendung Bl

Nutzer C Anwendung C1 API ODB (C) Init

Anwendung Cm

Abb. 7.2 In der Initialisierungsphase erhält jede ODB durch die Initialisierungskomponente initiale Grunddaten. Man beachte, dass Kommunikationsverbindungen zwischen ODBs als durchgezogene Pfeile dargestellt sind, im Gegensatz zu lokalen Datenbankzugriffen, welche durch gestrichelte Pfeile repräsentiert werden

7 Dynamische Verteilung von Daten in taktischen Netzen

87

7.3 Detaillierung des Modells In diesem Abschnitt werden die wesentlichen Aspekte des Modells ausführlicher dargestellt. Dazu werden im nächsten Unterabschnitt einige Grundbegriffe aus dem Bereich der objektorientierten Datenmodelle wiederholt bzw. neu eingeführt. Das bereits oben angedeutete Replikationsverfahren und die DatenmanagementMechanismen zur Steuerung der Initialisierung des Systems und zur Steuerung der Replikation der Daten sind Gegenstand der darauf folgenden Unterabschnitte.

7.3.1 Objektorientiertes Datenmodell Im Folgenden setzen wir voraus, dass die Informationen gemäß eines objektorientierten Datenmodells repräsentiert sind. Da die hier beschriebenen Konzepte weitgehend unabhängig von der exakten Definition des gewählten objektorientierten Datenmodells anwendbar sind, führen wir hier nur die grundlegende Terminologie von objektorientierten Datenmodellen auf. Dabei stützen wir uns auf den Standardisierungsvorschlag ODMG 3.0 der Object Data Management Group (vgl. Cattell & Barry, 2000), der von vielen Herstellern objektorientierter Datenbanksysteme verwendet wird. Objekte. Ein Objekt ist eine Entität bestehend aus  einem Objektidentifikator (kurz OID), der das Objekt eindeutig identifiziert,  einer Menge von Attributen (siehe unten) und  einer Menge von Methoden (siehe unten). Attribute. Ein Attribut hat einen Wert aus einer zugeordneten Wertmenge. Die zugeordnete Wertmenge wird als der Datentyp des Attributs bezeichnet. Jeder Datentyp ist entweder    

ein atomarer Datentyp (zum Beispiel: integer, real, char oder string), eine Referenz auf ein anderes Objekt, eine Liste von Referenzen oder eine aus atomaren Datentypen zusammengesetzte (endliche) Struktur (zum Beispiel: Liste, Menge).

Methoden. Methoden sind auf Objekten ausführbare Operationen (Programme). Typen. Ein Typ (auch Klasse genannt) spezifiziert eine Menge von Attributen und eine Menge von Methoden. Intuitiv bestimmt ein Typ die Struktur und das Verhalten (durch die Methoden) von Objekten. Jedem Objekt ist hierfür ein Typ zugeordnet. Ein Objekt wird als Instanz des zugehörigen Typs bezeichnet. Spezialisierung. Eine Spezialisierung ist eine Beziehung zwischen zwei Typen. Der spezialisierte (abgeleitete) Typ erbt alle Attribute und Methoden des Obertyps und

88

N. Jansen und M. Spielmann

ergänzt diese eventuell durch neue Attribute und Methoden. Wir erlauben keine Mehrfachspezialisierung (Mehrfachvererbung). Das heißt wir gehen davon aus, dass jeder Typ höchstens einen Obertyp besitzt. Durch die Spezialisierungsbeziehungen können die Klassen in Hierarchien angeordnet werden. Objektnetze. Objekte können zusammen mit ihren Referenzen auf andere Objekte als Graph aufgefasst werden. Jedes Objekt entspricht dabei einem Knoten des Graphen. Eine Referenz von einem Objekt zu einem anderen wird als eine beschrifte Kante zwischen den zugehörigen Knoten dargestellt. Als Beschriftung der Kante dient hierbei der Name des referenzierenden Attributs. Wir bezeichnen im Folgenden einen solchen Graphen als Objektnetz. Abb. 7.3 zeigt ein Objektnetz, das (einen Teil) einer Führungshierarchie (Blue-Force-Hierarchie) modelliert. In dem Objektnetz steht der Knoten „Btl“ für ein Objekt, das ein Bataillon repräsentiert (Attribute sind aus Platzgründen nicht dargestellt). Die Position des Bataillons ist in einem separaten Objekt, welches im Objektnetz als Knoten „absPt59“ dargestellt ist, repräsentiert (man beachte die mit „position“ beschriftete Kante, welche vom Knoten „Btl“ zum Knoten „absPt59“ führt). Der Gefechtsstand des Bataillons wird durch ein weiteres Objekt, welches als Knoten „Btl_CmdPost“ dargestellt ist, repräsentiert (man beachte die Kanten „unit“ und „commandPost“ zwischen den Knoten „Btl“ und „Btl_CmdPost“). Auf die gleiche Weise sind zwei Kompanien, die dem Bataillon unterstellt sind, modelliert. Das Bataillon und die unterstellten Truppenteile sind durch entsprechende Objektreferenzen, die das Unterstellungsverhältnis nachbilden, miteinander verbunden (vgl. die Kanten „commands“ und „underCommandOf“). Pfade. Ausgehend von einem Objekt ist es möglich, in einem Objektnetz über die Objektreferenzen zu anderen Objekten zu gelangen. Man spricht hierbei von einem navigierenden Zugriff auf die Daten. Die Liste der Namen der Referenzen (bzw. Namen von Attributen, die die Referenz als Wert haben) auf diesem Weg bezeichnen

BlueForce Btl Kp s.1 f nd a dO an mm m co om rC de un

position

absPt71

1Kp_CmdPost

position

absPt61

absPt59

co mm an un ds de .2K rC om p ma nd Of

2Kp commandPost

commandPost

unit

1Kp

position

position

absPt72

position

absPt73

unit

unit

commandPost

Btl_CmdPost

2Kp_CmdPost

Abb. 7.3 Ein Objektnetz, welches militärische Einheiten repräsentiert

position

absPt74

7 Dynamische Verteilung von Daten in taktischen Netzen

89

wir als Pfad. So erreicht man beispielsweise (vgl. Abb. 7.3) ausgehend vom Objekt „2Kp“ durch das Folgen des Pfades „underCommandOf.commandPost.position“ das Objekt „absPt61“. Pfadausdrücke. Ein Pfadausdruck ist ein regulärer Ausdruck, der aus  dem Namen einer Objektreferenz (entspricht einer Kante in einem Objektnetz),  dem Symbol " (steht für den leeren Pfad) und  dem Symbol ‹ (ist ein Platzhalter für eine beliebige Objektreferenz (Kante im Objektnetz)) mittels Konkatenation .:/, Alternative .C/ und Repetition . / aufgebaut ist. Ein Pfadausdruck spezifiziert eine Menge von Pfaden. Ein Beispiel für einen wohlgeformten Pfadausdruck ist: „commandPost.position C position“. Die folgenden Begriffe benötigen wir, um unser Replikationsverfahren (vgl. Abschn. 7.3.2) und unsere Datenmanagement-Mechanismen (vgl. Abschn. 7.3.3) zu beschreiben. Datenkategorien. Für den Zugriff auf ein Objekt der Datenhaltung wird der Objektidentifikator (OID) des Objekts benötigt. Da dieser der Anwendung üblicherweise nicht bekannt ist, bietet sich die Verwendung von mnemonischen (einprägsamen) Bezeichnungen für Objekte an. Wir nennen derartige Bezeichnungen Datenkategorien. So ist in Abb. 7.3 beispielsweise eine Datenkategorie „BlueForce“, die für das Objekt „Btl“ steht, dargestellt. Der Begriff Datenkategorie resultiert aus der Idee, dass das Objekt, welches einer Datenkategorie zugeordnet ist, als Wurzelobjekt eines Objektnetzes, das Daten einer speziellen Kategorie enthält, angesehen werden kann. So sind in obigem Beispiel ausgehend von dem Objekt „Btl“ durch das Folgen von Objektreferenzen alle Datenobjekte, die der Kategorie „BlueForce“ angehören, erreichbar. Durch Angabe einer Datenkategorie und eines Pfadausdrucks kann eine Teilmenge der Datenkategorie spezifiziert werden. Der Pfadausdruck beschreibt hierbei Pfade, die von dem Wurzelobjekt der Datenkategorie ausgehen. So werden beispielsweise in Abb. 7.3 durch Angabe der Datenkategorie „BlueForce“ und des Pfadausdrucks „commandPost.position + position“ die Objekte „absPt61“ und „absPt59“ spezifiziert. Besitzer. Wir gehen davon aus, dass jedem Objekt ein Besitzer zugeordnet ist. Nur der Besitzer eines Objekts ist befugt, dieses Objekt zu verändern. Besitzer ist üblicherweise die ODB, die das Objekt erzeugt hat. Klone. Um die Änderung von Objekten, die zu einer ODB repliziert wurden (und damit nicht dieser ODB gehören), zu ermöglichen, sehen wir das „Klonen“ von Objekten vor: Ein Klon eines Objektnetzes (bzw. eines Teils eines Objektnetzes) ist eine Kopie dieses Objektnetzes und ist im Besitz der ODB, die den Klon erstellt hat.

90

N. Jansen und M. Spielmann

7.3.2 Replikationsverfahren In diesem Unterabschnitt beschreiben wir unser Replikationsverfahren, welches mit der Zielsetzung entwickelt wurde, den Kommunikationsbedarf, der für die Konsistenthaltung von replizierten Objekten anfällt, möglichst gering zu halten. Eine Möglichkeit, den Kommunikationsbedarf einzuschränken, ist es, zu jeder ODB nur die Objekte zu replizieren, die in dieser ODB benötigt werden. Somit fallen geringere Kommunikationskosten für die Konsistenthaltung der Objekte an. Aus diesem Grund erlauben wir Datenadministratoren vergleichsweise feingranular zu spezifizieren, welche Teilmengen der Objekte zwischen den verschiedenen ODBs repliziert werden sollen. Weiterhin lockern wir die Konsistenzbedingungen, um eine weitere Reduzierung des Kommunikationsbedarfs zu erzielen. Dies erreichen wir durch die Verwendung einer speziellen Strategie für die Aktualisierung von Objekten (Update-Strategie). Im Folgenden beschreiben wir die von uns als UpdateStrategie verwendete Primärkopie-Strategie.

7.3.2.1 Update-Strategie Ein wesentliches Unterscheidungsmerkmal von Replikationsverfahren ist die verwendete Update-Strategie. Diese bestimmt, wie replizierte Objekte (Kopien genannt) aktualisiert werden. Allgemein stellt eine Update-Strategie stets einen Kompromiss zwischen der maximalen Verfügbarkeit von Daten und der Datenkonsistenz im Gesamtsystem dar. So können beispielsweise bei dem Read-One-Write-AllVerfahren (ROWA-Verfahren; vgl. Beuter & Dadam, 1996) Leseoperationen stets lokal durchgeführt werden, da alle Kopien stets auf dem aktuellen Stand gehalten werden. Dies wird aber durch einen hohen Aufwand für die Konsistenthaltung der Daten erkauft. Jede Schreiboperation muss hier auf allen Kopien gleichzeitig durchgeführt werden. Dies bedeutet, dass bei der Nicht-Erreichbarkeit einer einzelnen Kopie (d. h. Datenhaltung) keine Schreiboperation durchgeführt werden kann. Eine entgegengesetzte Strategie ist die Verwendung einer zentralen Datenbank. Hier entstehen keine Inkonsistenzen, da Schreiboperationen stets nur auf einer einzigen Kopie durchgeführt werden. Im Gegenzug ist die Verfügbarkeit der Daten sehr eingeschränkt, da Leseoperationen nur durchgeführt werden können, wenn die zentrale Datenbank erreichbar ist. Eine Beschreibung von weiteren Update-Strategien findet sich in (Beuter & Dadam, 1996; vgl. auch Jansen & Spielmann, 2007). Als Beispiel für ein im militärischen Bereich verwendetes Replikationsverfahren sei der im Multilateral Interoperability Programme (MIP; vgl. Kap. 16) verwendete Data Exchange Mechanism (DEM; MIP, 2008b) erwähnt. Hierbei handelt es sich um ein Publish-Subscribe-basiertes Replikationsverfahren. Es ist zu beachten, dass dieses Replikationsverfahren nicht für die Verwendung in taktischen Netzen geeignet ist, da bei der Konzeption des DEM ein Datenaustausch zwischen verschiedenen Nationen auf strategischer bzw. operativer Ebene Zielsetzung war. So unterstützt der DEM beispielsweise nur TCP als Transportprotokoll und unterstützt somit kein Broadcast bzw. Multicast. Die Verwendung von Broadcast bzw. Multicast ist jedoch

7 Dynamische Verteilung von Daten in taktischen Netzen

91

in taktischen Netzen von großer Bedeutung, da sie den Bandbreitenbedarf bei einer Gruppenkommunikation deutlich reduzieren kann. Eine weitere Einschränkung des DEM ist, dass nur eine Menge von vordefinierten operativen Informationsgruppen (OIGs) abonniert werden kann, was für die taktische Ebene nicht feingranular genug ist. Das hier vorgestellte Replikationsverfahren verwendet als Update-Strategie eine Primärkopie-Strategie (Beuter & Dadam, 1996). Bei dieser Strategie wird jede Änderung eines Objekts stets auf einer ausgezeichneten Kopie (Primärkopie) durchgeführt. Die anderen Kopien werden bei einer Änderung der Primärkopie asynchron aktualisiert. Wir gehen davon aus, dass sich jedes Objekt im Besitz einer ausgezeichneten ODB befindet (vgl. Abschn. 7.3.1). Die Primärkopie eines Objekts wird in dieser ODB gespeichert. Schreibanfragen einer Anwendung an die Primärkopie eines Objekts werden direkt von der besitzenden ODB ausgeführt und anschließend asynchron an die ODBs, die ebenfalls Kopien des Objekts halten, propagiert. Durch die Verwendung einer Primärkopie-Strategie werden Inkonsistenzen der Daten bei gleichzeitiger Bearbeitung durch mehrere Nutzer vermieden, da jedes Objekt stets nur in der besitzenden ODB bearbeitet werden kann. Wir haben diese Update-Strategie gewählt, da sie den Bandbreitenbedarf im Netzwerk reduziert. Lesetransaktionen können stets effizient auf der lokal vorliegenden ODB ohne Netzwerkkommunikation durchgeführt werden. Dies gilt analog für Schreiboperationen auf „eigenen“ Objekten, da diese lokal in der „eigenen“ ODB (als Primärkopien) vorliegen. Ein Nachteil unserer Update-Strategie ist, dass Objekte zeitweise in einigen ODBs veraltet sein können, da in unserem Ansatz Updates asynchron übertragen werden. Ein weiterer Nachteil ist, dass ein Nutzer keine Objekte bearbeiten kann, die er nicht besitzt. Um dieses Problem zu umgehen, nutzen wir das Konzept des Klonens (vgl. Abschn. 7.3.1). Es bleibt zu untersuchen, ob die beschriebenen Nachteile angesichts der speziellen Einschränkungen taktischer Netze zugunsten einer schnelleren Zugriffsmöglichkeit und besseren Verfügbarkeit akzeptierbar sind. 7.3.2.2 Subscribe/Download-Verfahren Um den Bandbreitenbedarf weiter zu reduzieren, nutzt unser Replikationsverfahren den Umstand aus, dass ein Nutzer üblicherweise nicht an allen Objekten, die im Netzwerk verfügbar sind, interessiert ist. Wir führen ein spezielles Publish/Subscribe-Verfahren (Subscribe/DownloadVerfahren genannt) ein. In diesem Verfahren bezeichnen wir dateninteressierte Nutzer als Subscriber und Anbieter von Daten als Publisher. Ein Subscriber kann eine Teilmenge der Datenobjekte eines Publishers abonnieren. Nach einer Änderung von Objekten beim Publisher werden nur Änderungsinformationen über Objekte, die der Subscriber abonniert hat, asynchron zu seiner ODB repliziert. Ein Publisher von Objekten muss nicht zwangsläufig der Besitzer dieser Objekte sein. Zudem kann jeder Nutzer gleichzeitig als Subscriber und Publisher von Objekten agieren. Abbildung 7.4 zeigt einen typischen Nachrichtenfluss des Subscribe/DownloadVerfahrens. Zuerst abonniert der Subscriber mittels einer Subscription (Abonne-

92

N. Jansen und M. Spielmann

ment) eine Menge von Objekten beim Publisher (siehe Schritt 1 in Abb. 7.4). Wird ein abonniertes Objekt vom Publisher modifiziert, schickt dieser allen ODBs, die dieses Objekt abonniert haben, mittels eines Push-Verfahrens eine Änderungsbenachrichtigung (Schritt 2). Man beachte, dass die Änderungsbenachrichtung im Vergleich zu einer Aktualisierungsnachricht (Update) sehr klein ist. Anschließend kann der Subscriber bei Bedarf die Änderungen (Update) mittels eines Pull-Verfahrens herunterladen (Schritte 3, 4). Eine Subscription (vgl. Abb. 7.4, Schritt 1) besteht aus einer Datenkategorie und einem Filter. Der Filter ist ein Pfadausdruck und bestimmt die Teilmenge der Objekte der Datenkategorie, an welcher der Subscriber interessiert ist (vgl. Abschn. 7.3.1). Dadurch können die zu replizierenden Objekte feingranular bestimmt werden, wodurch der Bandbreitenbedarf reduziert werden kann. Während Updates bei den bekannten Publish/Subscribe-Verfahren üblicherweise mittels eines Push-Verfahrens zu den Subscribern gesendet werden, kombinieren wir die Vorteile eines Push- mit denen eines Pull-Verfahrens. Unser Ansatz hat den Vorteil, dass der Subscriber entscheiden kann, welche Objekte er zu welchem Zeitpunkt herunterladen möchte. Dies erlaubt eine Priorisierung von „wichtigen“ Daten im Falle von eingeschränkten Kommunikationsressourcen. Mechanismen für die Priorisierung von Objekten sind jedoch nicht Gegenstand dieses Beitrags. Zur weiteren Reduzierung der über das Netzwerk zu übertragenden Daten sollte ein Publisher einen Subscriber über Änderungen eines Objekts nur einmal informieren, auch wenn es in der Zwischenzeit mehrfach geändert wurde. Somit wird ein Subscriber, der momentan an einem Objekt nicht interessiert ist, nicht laufend über die Änderung dieses Objekts informiert. Wenn der Subscriber zu einem späteren Zeitpunkt wieder ein Update des Objekts anfragt, erhält er nur die Änderungsinformationen, die er benötigt, um den aktuellen Zustand des Objekts zu erhalten.

Abb. 7.4 Subscribe/Download-Verfahren (UML-Sequenzdiagramm)

7 Dynamische Verteilung von Daten in taktischen Netzen

93

7.3.3 Datenmanagement Während unser Replikationsverfahren eine flexible, technische Basis für die Replikation von Datenobjekten bildet, bleibt zu spezifizieren, welche Objekte für welche Nutzer (beispielsweise Truppenteile) relevant sind und welche Objekte zwischen welchen ODBs repliziert werden sollen. In diesem Unterabschnitt stellen wir erste Ansätze zur Entwicklung von Datenmanagement-Mechanismen vor, mit deren Hilfe die Initialisierung des Systems und die Konfiguration der Verteilung der Daten (Replikation) zwischen den ODBs gesteuert werden kann. Ziel dieser Mechanismen ist es, die Konfiguration des Systems zu vereinfachen und es Datenadministratoren zu ermöglichen, die Verteilung der Datenobjekte schnell an geänderte Situationen anzupassen. Dies ist insbesondere bei der Vernetzten Operationsführung (NetOpFü), die zu schnelleren Führungs- und Entscheidungsprozessen und damit zu einer höheren Dynamik der Informationsbedarfe der einzelnen Truppenteile führt, wichtig. 7.3.3.1 Konfiguration und Initialisierung Grundlage der Konfiguration des Systems bilden Konfigurationsregeln, die es ermöglichen, die initiale Verteilung der Daten zu beschreiben und die Replikation zwischen den ODBs zu konfigurieren. Diese Konfigurationsregeln sind durch Datenadministratoren in Vorbereitung eines Einsatzes des Systems zu erstellen. Dem eigentlichen Einsatz des Systems (Laufzeitphase) ist eine Initialisierungsphase vorgeschaltet. Die Initialisierungsphase wird durch eine Initialisierungskomponente (vgl. Abb. 7.2) gesteuert. Sie nutzt für die Steuerung der Initialisierung eine spezielle Schnittstelle der ODB. Im ersten Schritt der Initialisierung überträgt die Initialisierungskomponente initiale Grunddaten und eine Menge von Konfigurationsregeln zu den einzelnen ODBs. Anschließend wertet jede ODB ihre Konfigurationsregeln aus und konfiguriert den Replikationsmechanismus anhand dieser Regeln. In der Laufzeitphase werden Daten zwischen den ODBs der verschiedenen Nutzer repliziert. 7.3.3.2 Konfigurationsregeln Die Konfigurationsregeln beschreiben den Informationsbedarf der einzelnen Truppenteile. Hierfür beschreibt eine Regel für einen Nutzer (beispielsweise Truppenteil) und für verschiedene operative Situationen, welche Informationen für den Nutzer in der jeweiligen Situation relevant sind. Dies ermöglicht es Datenadministratoren, die Informationsbedarfe von Truppenteilen einfach (insbesondere ohne Programmcodeanpassungen) festzulegen. Weiterhin können Konfigurationsregeln schnell angepasst werden, wenn neue operative Situationen entstehen. Für jede ODB wird ein Regelsatz für die Initialisierungsphase und ein Regelsatz für die Laufzeitphase des Systems verwaltet. Bei einem Regelsatz handelt es sich um eine Sequenz von Konfigurationsregeln. In einem ersten Schritt werden Konfigurationsregeln entworfen, welche beschreiben,

94

N. Jansen und M. Spielmann

 von welchen ODBs welche Daten zur eigenen ODB zu replizieren sind,  wie replizierte Daten zu manipulieren sind (z. B. mittels Aggregation) bevor diese in die eigene ODB integriert werden und  wie replizierte und ggf. manipulierte Daten in die eigene ODB zu integrieren sind. Im Folgenden stellen wir eine Auswahl von Konfigurationsregeln vor (eine umfassendere Beschreibung findet sich in Jansen & Spielmann, 2007). Eine SUBSCRIBE-Regel beschreibt, welche Datenobjekte von welchen ODBs repliziert werden sollen. Eine solche Regel ist wie folgt aufgebaut: DestCategory = SUBSCRIBE ( Publisher, Category, Filter ), wobei die vier Bezeichner DestCategory, Publisher, Category und Filter die folgende Bedeutung haben:  Publisher ist eine Beschreibung der ODBs, von denen Daten bezogen werden sollen,  Category beschreibt die Datenkategorie, aus der Daten bezogen werden sollen,  Filter spezifiziert die Objekte der Datenkategorie, die für den Nutzer relevant sind,  DestCategory gibt die Datenkategorie an, unter der die replizierten Datenobjekte in der eigenen ODB abgelegt werden sollen. Als Beispiel betrachte man Abb. 7.5, in der zwei Truppenteile (ein Bataillon und eine unterstellte Kompanie) in Form von Datenobjekten dargestellt sind. Jeder Truppenteil besitzt eine eigene ODB, welche die lagebildbezogenen Daten dieses Truppenteils verwaltet. In der Initialisierungsphase soll die Blue-Force-Hierarchie erzeugt und in den ODBs der Truppenteile gespeichert werden. Zunächst ist nur die Repräsentation des eigenen Truppenteils (und des zugehörigen Gefechtsstands) in der entsprechenden ODB gespeichert (siehe Abb. 7.5). Der eigene Truppenteil wird jeweils durch eine Datenkategorie „BlueForce“ referenziert. Nehmen wir an, dass folgende Regel von der ODB des Bataillons ausgeführt wird, um Objekte von der Kompanie zum Bataillon zu replizieren:

absPt61

Btl_CmdPost

BlueForce commandPost

ndPost commandPost

position

unit

Btl

BlueForce

ODB(Kp)

position

absPt59

Kp

position

absPt62

unit

ODB(Btl)

Kp_CmdPost

position

absPt58

Abb. 7.5 Ausführung einer SUBSCRIBE-Regel (Anfangssituation). Anfangs sind in den ODBs von Bataillon und Kompanie nur die eigenen Truppenteile repräsentiert

7 Dynamische Verteilung von Daten in taktischen Netzen

95

BlueForceChild = SUBSCRIBE ( ODB(Kp), BlueForce,  C posi ti on ). Die Regel beschreibt, dass das Bataillon an allen Objekten interessiert ist, die sich ausgehend vom Wurzelobjekt der Kategorie „BlueForce“ durch das Folgen von Pfaden, die mit dem Pfadausdruck „" C posi ti on“ spezifiziert werden, erreichen lassen. Da der leere Pfad „"“ für das Wurzelobjekt der Kategorie („Kp“) steht und die Referenz „position“ zu dem Objekt „absPt62“ führt, welches die Position der Kompanie repräsentiert, werden diese beiden Objekte zu dem Bataillon repliziert und dort in der Kategorie „BlueForceChild“ abgelegt (siehe Abb. 7.6). Jede Positionsänderung der Kompanie, die in der ODB der Kompanie durchgeführt wird, wird nun mittels Subscribe/Download-Verfahren zu dem Bataillon übertragen. Somit ist das Bataillon stets über die aktuelle Position der Kompanie informiert. Eine weiterer Typ von Konfigurationsregeln ist die MODIFY-Regel. Eine solche Regel beschreibt, wie Datenobjekte automatisiert modifiziert werden sollen und ist wie folgt aufgebaut: MODIFY ( Trigger, Operation, DestCategory ), wobei die Bezeichner Trigger, Operation und DestCategory die folgende Bedeutung haben:  Trigger hat die Form {Category1 , ..., Categoryn g, wobei Categoryi eine Datenkategorie bezeichnet,  Operation bezeichnet eine Methode und  DestCategory bezeichnet eine Datenkategorie. Die Semantik dieser Regel ist wie folgt: Wenn ein Datenobjekt einer der angegebenen Datenkategorien (Category1 , ..., Categoryn ) in der eigenen ODB geändert wird, wird die angegebene Operation ausgeführt und das Ergebnis dieser Operation unter der Datenkategorie DestCategory abgelegt.

Btl_CmdPost BlueForce Child

absPt61

Kp

position

position

absPt59

BlueForce

Kp

position

absPt62

unit

position

unit

Btl commandPost

BlueForce

ODB(Kp)

commandPost

ODB(Btl)

N IO AT IK L position P Kp_CmdPost RE

absPt58

absPt62

Abb. 7.6 Ausführung einer SUBSCRIBE-Regel (Fortsetzung). Die Objekte, die die Kompanie repräsentieren, werden von der ODB der Kompanie zur ODB des Bataillons repliziert

96

N. Jansen und M. Spielmann

Als Beispiel für die Anwendung einer MODIFY-Regel betrachten wir die in Abb. 7.7 dargestellte Situation. In der ODB eines Bataillons ist (analog zum vorherigen Beispiel) die Blue-Force-Hierarchie repräsentiert. Die Datenkategorie „BlueForce“ verweist auf den eigenen Truppenteil. „BlueForceChild0“ und „BlueForceChild1“ sind technische Hilfskategorien, die auf zwei Truppenteile (Kompanien), die dem Bataillon unterstellt sind, verweisen. Wir betrachten folgende MODIFY-Regel: MODIFY ( {BlueForceChild0, BlueForceChild1}, geometricMean, BlueForce ) Die Regel beschreibt die Berechnung der Position des Bataillons durch Aggregation der Positionen der unterstellten Truppenteile. Bei jeder Änderung eines Objekts einer der angegebenen Kategorien „BlueForceChild0“ oder „BlueForceChild1“ wird die Operation „geometricMean“ ausgeführt. Die einzelnen Schritte der Ausführung der MODIFY-Regel sind in Abb. 7.8 dargestellt. Ausgelöst wird die MODIFY-Regel in diesem Beispiel durch eine replizierte Änderung der Position der 2. Kompanie (Objekt „absPt73“, vgl. Schritt 1 in Abb. 7.8). Dies führt zur Ausführung der Operation „geometricMean“. Diese liest die Positionen der unterstellten Truppenteile (Objekte „absPt73“ und „absPt71“, vgl. Schritte 2, 3), berechnet aus

ODB(Btl) Objekte: Btl_CmdPost BlueForce

BlueForceChild0

1.Kp

1.Kp_CmdPost

geometricMean

absPt59

Btl

absPt71 absPt72

Operationen: absPt61

2.Kp

BlueForceChild1 absPt73

2.Kp_CmdPost

absPt74

Abb. 7.7 Beispiel der Ausführung einer MODIFY-Regel (Anfangssituation)

ODB(Btl) Objekte: Btl_CmdPost BlueForce

BlueForceChild0

1.Kp

1.Kp_CmdPost

Btl

absPt71 absPt72

Operationen: alisiere (4) aktu se (3) le

absPt61 absPt59

2.Kp

geometricMean

)l (2

BlueForceChild1 absPt73

2.Kp_CmdPost

absPt74

Abb. 7.8 Beispiel der Ausführung einer MODIFY-Regel (Fortsetzung)

e es

(1) Ä nde durc rung der h Re plika Position tion

7 Dynamische Verteilung von Daten in taktischen Netzen

97

diesen das geometrische Mittel und schreibt das Ergebnis in das Objekt „absPt59“, welches die Position des Bataillons repräsentiert (Schritt 4).

7.4 Zusammenfassung und Ausblick Aufgrund der besonderen Einschränkungen militärischer Netzwerke (insbesondere auf der taktischen Ebene) sind beim Entwurf zukünftiger, verteilter FüInfoSys spezielle Lösungsansätze notwendig. In diesem Beitrag wurde ein Modell eines objektorientierten, verteilten Datenbanksystems vorgestellt, in dem Datenobjekte teilredundant in lokalen Objektdatenbanken (ODBs) gespeichert werden. Jedem Nutzer (z. B. Person, Truppenteil, Rolle oder Organisationseinheit) wird dazu eine eigene ODB zugeordnet. Diese ODB verwaltet die Datenobjekte, die für diesen Nutzer relevant sind. Das Modell umfasst ein Replikationsverfahren (Subscribe/DownloadVerfahren), welches an die besonderen Anforderungen taktischer Netze angepasst ist. Das Replikationsverfahren erlaubt es, feingranular zu spezifizieren, welche Datenobjekte zwischen welchen ODBs repliziert werden sollen. Somit reduziert das Replikationsverfahren die Kommunikationskosten für den Zugriff auf Objekte und für die Synchronisierung der Objekte. Das Modell enthält darüber hinaus Datenmanagement-Mechanismen zur Konfiguration der ODBs. Die Mechanismen ermöglichen es Datenadministratoren mittels Konfigurationsregeln festzulegen, wie das System initialisiert wird und welche Datenobjekte zur Laufzeit zwischen welchen ODBs repliziert werden. Exemplarisch haben wir eine Auswahl von Konfigurationsregeln vorgestellt. Ausblick. Als Erweiterung der hier vorgestellten Konzepte bietet sich die Entwicklung einer formalen Sprache für die Konfiguration des Systems an. Diese Sprache muss einerseits ausdrucksmächtig genug sein, um die Informationsbedarfe von Truppenteilen für verschiedene Auftragssituationen beschreiben zu können und andererseits hinreichend einfach sein, um es Datenadministratoren zu ermöglichen, das Systemverhalten schnell an neue operative Bedürfnisse anzupassen. Eine sinnvolle Erweiterung der hier vorgestellten Regelsprache ist die Unterstützung von bedingten Konfigurationsregeln. Hierbei wird jede Regel mit einer Bedingung versehen, welche angibt, ob die Regel in der aktuellen Situation gültig ist. Dadurch wäre es möglich, den Informationsbedarf eines Truppenteils für verschiedene operative Situationen zu beschreiben. Das FüInfoSys könnte demnach die Replikation automatisch anpassen, wenn antizipierte Änderungen dynamischer Parameter (wie der operativen Situation oder des aktuellen Interessengebiets (area of interest)) stattfinden.

Literaturverzeichnis Beuter, T. & Dadam, P. (1996). Prinzipien der Replikationskontrolle in verteilten Datenbanksystemen. Informatik – Forschung und Entwicklung, 11(4), 203–212.

98

N. Jansen und M. Spielmann

BMVg (2006). Teilkonzeption Vernetzte Operationsführung. Cattell, R. G. G. & Barry, D. K. (2000). The Object Data Standard: ODMG 3.0. Morgan Kaufmann Publishers. Jansen, N. & Spielmann, M. (2007). Konzeption eines verteilten Datenhaltungs- und Datenmanagement-Systems für lagerelevante Daten in FüInfoSys. FKIE-Bericht Nr. 142, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. MIP – Multilateral Interoperability Programme (2008b). MIP Technical Interface Design Plan (MTIDP), Edition 3.8. http://www.mip-site.org.

Kapitel 8

Intelligente Daten-Filterung in FüInfoSys Thomas Nitsche

8.1 Einleitung Die vernetzte Operationsführung (NetOpFü, vgl. BMVg, 2006; Alberts & Hayes, 2003; Wilson, 2004), d. h. die Führung von Streitkräften unter Ausnutzung eines streitkräftegemeinsamen, ebenenübergreifenden Kommunikations- und Informationsraumes, ist ein wesentlicher Bestandteil der Transformation der Bundeswehr. Ziel ist die Verbesserung der militärischen Effektivität durch Erreichen von Informationsüberlegenheit (vgl. Alberts & Hayes, 2003), weil militärische Aktionen dadurch präziser und effektiver durchgeführt werden können. Kruse et al. (2005) beschreiben beispielsweise die Zeitgewinne durch die Nutzung von NetOpFü bei Luftwaffeneinsätzen während der Operation Enduring Freedom (OEF). Das verbesserte Situationsbewusstsein (engl.: Situational Awareness) ermöglichte es den Offizieren, „mehr taktische und strategische Überlegungen anzustellen“ (Kruse et al., 2005, S. 6). Technische Basis für die Realisierung von NetOpFü ist der globale, teilstreitkräfte- und ebenenübergreifende Informationsraum (Global Information Grid – GIG). Er basiert auf der allumfassenden Vernetzung aller Nutzer und Systeme, von Aufklärungssystemen und Sensoren über Führungssysteme bis hin zu den Waffensystemen. Als miteinander vernetzte Elemente umfasst ein FüInfoSys im Sinne von NetOpFü deshalb alle beteiligten Personen sowie militärischen Einheiten, aber auch Sensoren, Effektoren und andere Systeme. Prinzipiell kann jedes System oder jeder Nutzer mit jedem anderen kommunizieren und Zugang zu entfernten Services und Daten haben. Im globalen Informationsraum kann die Gesamtmenge der verfügbaren Informationen folglich von den verschiedenen Nutzern gemeinsam genutzt werden, vorausgesetzt, dass die jeweils erforderlichen Sicherheitskriterien erfüllt sind. Die vernetzte Operationsführung ermöglicht deshalb durch den Zusammenschluss aller militärischen Einheiten und Systeme einen Informationsaustausch zwischen beliebigen Elementen. Dieser Informationsaustausch und die resultierende bessere Informationsversorgung der Nutzer ermöglicht ein erhöhtes SituationsbeM. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

99

100

T. Nitsche

wusstsein (vgl. Alberts & Hayes, 2003; Kuper et al., 2003; National Commission, 2004, S. 417).

8.1.1 Problem der Informationsüberflutung Dies gilt jedoch nur, solange der militärische Entscheider nicht mit der Gesamtheit aller verfügbaren Daten im globalen Informationsraum überlastet wird. So kann die Anzahl der Elemente innerhalb eines FüInfoSys – seien es militärische Einheiten oder andere georeferenzierte Elemente (wie z. B. Brücken oder Straßen) – zu groß werden, um sie alle direkt betrachten zu können. Dies führt zu einer Überflutung mit Informationen (vgl. Denning, 2006), die nicht mehr vernünftig durch Mensch (und Maschine) behandelt werden kann (vgl. Ruff-Stahl, 2008, sowie Kap. 9 in diesem Buch). Das FüInfoSys muss deshalb entsprechende Filtermechanismen und -funktionen bereitstellen, um die Menge der verfügbaren Informationen auf nutzer- und einsatzrelevante Anteile zu reduzieren (vgl. Hayes-Roth, 2006; Nitsche, 2006). Darüber hinaus sind die beschränkten Kapazitäten der Endgeräte und Kommunikationskanäle, insbesondere auf taktischer Ebene, zu berücksichtigen (vgl. Spielmann, in Bearbeitung; Wilson, 2004, S. 23). Diese erfordern ebenfalls eine Beschränkung der übertragenen sowie der lokal gespeicherten Daten.

8.1.2 Interessengebiete Die nutzer- und einsatzrelevante Datenfilterung kann beispielsweise die Position bzw. die Umgebung der jeweiligen Einheit berücksichtigen. Weitere Filterkriterien sind u. a. die militärische Einsatzhierarchie, die zeitliche Relevanz von Informationen sowie Art oder Quelle von Informationen (vgl. Hayes-Roth, 2006; Jansen & Spielmann, 2007; Nitsche, 2006). Dies führt zu einem nutzerdefinierten Lagebild, bei dem entsprechend der Nutzereinstellungen die jeweiligen Informationen ausgewählt und dargestellt werden (vgl. Mulgund & Landsmann, 2007). Interessengebiete („Areas of Interest“, AOI) sind ein Filterkonzept, bei dem Informationen über militärische Einheiten und andere Elemente aus einem bestimmten Bereich geliefert werden. Im Folgenden beschränken wir uns auf geografische Gebiete.1 Das Interessengebiet eines Nutzers umfasst im Allgemeinen sein Operationsgebiet bzw. das seiner zugehörigen Einheit. Ferner sind oft auch angrenzende Gebiete von Bedeutung, um das Verhalten benachbarter Einheiten überwachen zu können. Dabei können neben den eigenen sowie den feindlichen Kräften, welche die Erfüllung des eigenen Auftrages beeinflussen, auch nicht mobile, aber militärisch 1 Das Prinzip lässt sich auf allgemeine Informationen wie z. B. Wetterdaten, Ausrüstungs- und Statusinformationen oder Aufklärungsergebnisse erweitern.

8 Intelligente Daten-Filterung in FüInfoSys

101

relevante Elemente wie Brücken oder Straßen lagerelevant sein. Durch die Definition eines Interessengebietes kann der militärische Entscheider folglich seinen Fokus auf ausgewählte Gebiete legen und dabei z. B. alle Elemente in einem bestimmten Umkreis um ihn herum bzw. angrenzend an sein Operationsgebiet überwachen. Definiert wird das Gebiet im Allgemeinen durch die entsprechenden Grenz- und Führungslinien der einzelnen Einheiten im Operationsraum (vgl. Abb. 8.1). Neben den Einheiten, die sich innerhalb des Interessengebietes befinden, sind auch Elemente zu betrachten, die auf das Interessengebiet von außen einwirken können. Ein Beispiel sind im FüInfoSys erfasste feindliche Elemente, die aufgrund der Reichweite ihrer Waffen für den militärischen Entscheider relevant sind. Der Wirkungsbereich kann aus den Eigenschaften der Waffensysteme bzw. Einheiten wie deren Geschwindigkeit, Bewegungsrichtung oder Waffenreichweite ermittelt werden. Diese Eigenschaften bestimmen den Umkreis, innerhalb dessen eine Einheit (im Falle von Feindkräften) eine potentielle Bedrohung darstellt bzw. (im Falle eigener Kräfte) unterstützend wirken kann. In Abb. 8.2 rechts sind beispielsweise alle diejenigen Elemente weggelassen, die sich außerhalb des Interessengebietes befin-

x 1.2

xxx

x 1.1

x xx x

xxx

1.3

x

xx

48h

xxx

xx x

xx

2.2

x

x

2.1

x

xx

x

48h

2.3

xxx VZL VZL t+24h VRV t+36h

VZL SL t

Abb. 8.1 Interessengebiet (grau markiert) eines Nutzers (z. B. eines Truppenteils) basierend auf seinem Operationsgebiet mit dessen Führungslinien Interessenbereich

ASS

Filterung

ASS

Wirkungsbereich

Abb. 8.2 Interessengebiet eines Truppenteils unter Berücksichtigung des Wirkungsbereichs feindlicher Einheiten

102

T. Nitsche

den und deren Wirkungsbereiche sich nicht mit ihm überschneiden. Dadurch werden in diesem Beispiel nur die zwei oberen Elemente innerhalb des Interessengebietes sowie die Feindkräfte (rechts unten) als relevant angesehen und dargestellt. Darüber hinaus können auch zukünftige Positionen der eigenen Einheiten gemäß Plänen und Befehlen2 berücksichtigt werden. Bei einer Patrouille oder einem Luftwaffeneinsatz können so die eigenen Kräfte sowie potentielle feindliche Bedrohungen (wie z. B. Flugabwehrstellungen) entlang der Patrouillenroute oder dem Flugplan in das Lagebild aufgenommen werden (vgl. Kuper et al., 2003, Abb. 2).

8.2 Ansätze zur Datenfilterung Um das Einsatzlagebild für den jeweiligen Nutzer zu erzeugen, müssen die Positionen und Wirkungsbereiche der jeweiligen Elemente bekannt sein. Im Falle von Funkkommunikation auf der taktischen Ebene bildet die begrenzte Reichweite der Funkkreise eine natürliche Nachbarschaftsgruppierung. Diese lässt sich ausnutzen, um Informationen über benachbarte Einheiten zu erhalten. Bachran et al. (2001) beschreiben ein spezielles Routingprotokoll für mobile Ad-hoc-Netze (MANETs), bei dem neben den Nutzdaten zusätzlich GPS-Positionen der Einheiten übermittelt werden. In multinationalen Verbänden lassen sich solche nicht-standardisierten Protokolle jedoch nur schwerlich einsetzen, da die zusammenarbeitenden Einheiten der verschiedenen Nationen sowie eventuelle zivile Organisationen oft mit unterschiedlichem Equipment ausgestattet sind, welches solche Protokolle nicht notwendigerweise unterstützt. Hier ist für eine reibungslose Zusammenarbeit die Verwendung internationaler Standards zum Datenaustausch wie beispielsweise aus dem Multilateral Interoperability Programme (MIP, vgl. auch Kap. 16) erforderlich. Man beachte, dass eine IP-basierte Positionsbestimmung wie in (Shin et al., 2006) ebenfalls nicht ausreichend ist. Aufgrund der verschiedenen am Einsatz beteiligten Nationen und Organisationen mit ihren jeweils eigenen Teilnetzen und Einsatzhierarchien entspricht die geografische Nachbarschaft nicht notwendigerweise derjenigen im Netzwerk. Dies gilt auch für die Funkkommunikation auf der taktischen Ebene, da – abgesehen von einer einfachen Freund-Feind-Kennung – weitergehende Informationen über den Status einer Einheit in der Regel nicht direkt ausgetauscht werden (sondern evtl. zukünftig über zentrale MIP-Gateways zwischen den nationalen FüInfoSys). Direkt benachbarte Einheiten können dadurch im Einsatz über weiter entfernte Kommunikationswege miteinander verbunden sein. Bei beiden oben dargestellten Ansätzen der Nachbarschaftsermittlung lassen sich außerdem die Wirkungsbereiche der Einheiten nicht adäquat abbilden, um auch weiter entfernte, aber trotzdem für den Nutzer relevante Elemente behandeln zu können.

2

Diese Informationen können in maschineninterpretierbarer Form beispielsweise dem MIPDatenmodell JC3IEDM (vgl. Kap. 16) oder der stärker formalisierten Battle Management Language (BML, vgl. Kap. 17) entnommen werden.

8 Intelligente Daten-Filterung in FüInfoSys

103

8.2.1 Verwaltung der Positionen und Wirkungsbereiche von Einheiten Im FüInfoSys müssen folglich die Positionen und Wirkungsbereiche der Einheiten und anderer georeferenzierter Elemente explizit verwaltet werden. Dazu sind zu jedem Element dessen Eigenschaften (wie aktuelle Position, Status und Wirkungsbereich) zu speichern. Dabei müssen die Besonderheiten der taktischen Ebene, wie begrenzte Kommunikationsbandbreite (vgl. Wilson, 2004, S. 23) sowie zeitweise, partielle Netzwerkfragmentierung und die damit verbundene Nichterreichbarkeit zentraler Dienste und Daten, mit berücksichtigt werden. Dies legt eine Verteilung der Daten und deren verteilte Bearbeitung innerhalb des FüInfoSys nahe (vgl. Jansen & Spielmann, 2007), macht jedoch deren Bearbeitung gleichzeitig auch komplexer.

8.2.2 Serviceorientierte FüInfoSys Im Folgenden gehen wir von einer serviceorientierten Architektur des FüInfoSys aus (vgl. Kap. 3 sowie Spielmann, in Bearbeitung). Die Funktionalität des FüInfoSys wird in Form von Services bereitgestellt. Diese können nutzerspezifische Instanzen bilden, welche auf verschiedene Rechner innerhalb des Gesamtnetzes verteilt werden und dadurch eine dezentrale, verteilte Bearbeitung innerhalb des FüInfoSys ermöglichen (vgl. Kap. 4 sowie Jansen et al., 2007). Die Daten des globalen, streitkräfte- und ebenenübergreifenden Informationsraumes können innerhalb des Gesamtnetzes auf die verschiedenen Service-Instanzen aufgeteilt werden, wobei jede von ihnen nur einen ausgewählten Teil der Gesamtdaten enthält (vgl. Kap. 7 sowie Jansen & Spielmann, 2007). Für das Positionsmanagement sind die Services zur Lagegenerierung (kurz: Lage-Services) von Bedeutung. Deren nutzerspezifische Service-Instanzen enthalten die Daten über den jeweiligen Nutzer, insbesondere dessen aktuellen Status, seine Position und seinen Wirkungsbereich. Diese Informationen können an andere Instanzen mittels Publish-Subscribe verteilt werden. Dadurch kann die Lage-Instanz eines Nutzers diese Daten bei den jeweils lagerelevanten Elementen abonnieren und z. B. automatisch über deren Position und deren zukünftige Änderungen informiert werden (vgl. Abschn. 7.3.2). Andere Elemente wie Einheiten anderer Nationen oder auch im FüInfoSys hinterlegte, bereits aufgeklärte feindliche Kräfte lassen sich analog behandeln. Dabei können im eigenen FüInfoSys den fremden Einheiten, deren Daten beispielsweise per MIP-Schnittstelle übermittelt werden, konzeptionell ebenfalls Instanzen des Lage-Services zugeordnet werden. Da die Verteilung der Lage-Instanzen im Netz beliebig konfiguriert werden kann, können diese sowohl auf einem zentralen Server gespeichert, als auch auf die Gefechtsstände oder mobilen Rechner in Führungsfahrzeugen verteilt werden (vgl. Jansen et al., 2007).

104

T. Nitsche

8.3 Verwaltung der Interessengebiete mittels Gebietsmanagern Zur Unterstützung einer effizienten Planung und Überwachung militärischer Aktionen in einem Interessengebiet kann im FüInfoSys das Konzept von Gebietsmanagern verwendet werden. Im Folgenden beschreiben wir das Grundkonzept, welches auf der Zerlegung des Einsatzgebietes beruht, sowie die während eines Einsatzes erfolgenden Anpassungen der Informationsbeziehungen. Für weitergehende Details verweisen wir auf (Nitsche, 2007a,b,c).

8.3.1 Zerlegung des Einsatzgebietes Die Verwaltung der Interessengebiete mittels Gebietsmanagern basiert auf der Zerlegung des gesamten Einsatzgebietes (bzw. des im FüInfoSys vorgehaltenen Weltausschnitts) in Teilgebiete, die wir als Regionen bezeichnen. Man kann sich diese Regionen als ein (oder je nach Größe auch mehrere) Planquadrate einer Lagekarte vorstellen (vgl. Abb. 8.3). Die Zerlegung des Einsatzgebietes in Regionen richtet sich nach den Operationsräumen bzw. Verantwortungsbereichen der einzelnen Einheiten (vgl. Abb. 8.1). Um nicht jede Einheit einzeln verwalten zu müssen, wird dabei die Größe der Regionen derart gewählt, dass sich im Regelfall mehrere Einheiten in ihnen befinden, beispielsweise die unterstellten Truppenteile ab einer bestimmten Hierarchieebene. Die gewählte Größe der Regionen ist dabei das Ergebnis der Abwägung zwischen einer einfachen Verwaltung (mit wenigen, möglichst großen Regionen) und einer effektiven Filterung (durch möglichst kleine Regionen). Die (initiale) Zerlegung des Einsatzgebietes in Regionen kann dabei während der Einsatzplanung gewählt werden. Zur Laufzeit kann diese initiale Zerlegung an dynamische Truppenbewegungen angepasst werden (vgl. Abschn. 8.3.4). Der Zerlegungsprozess lässt sich automatisieren, indem die Operationsräume der Truppen-

Lage: E1

Region: NW

Region: NO

Lage: E2 ASS

Lage: E3

ASS

Region: SO

Region: SW Lage: E4

Abb. 8.3 Gebietsmanager enthalten Informationen über die Elemente innerhalb ihrer Region

8 Intelligente Daten-Filterung in FüInfoSys

105

teile bis zu einer (als Parameter wählbaren) Hierarchiestufe als Grundlage für die Regionen verwendet werden.3 Zur Verwaltung der Positionen und Wirkungsbereiche der Einheiten verwenden wir Gebietsmanager. Diese sind für eine bestimmte geografische Region zuständig und verwalten alle militärisch relevanten Elemente, die sich innerhalb dieser Region befinden oder von weiter entfernten Gebieten auf diese einwirken (vgl. Abb. 8.3). Die Gebietsmanager stellen einen weiteren Service innerhalb des FüInfoSys bereit. Dieser kann analog zum Lage-Service als verteilte Datenverwaltung angesehen werden. Während die Instanzen des Lage-Service u. a. Statusinformationen der einzelnen Einheiten enthalten, verwalten die Gebietsmanager jeweils alle Einheiten und andere georeferenzierte Elemente einer bestimmten Region. Um nun die für das Interessengebiet eines Nutzers relevanten, mobilen Elemente zu ermitteln, brauchen lediglich diejenigen Regionen betrachtet zu werden, welche sich mit dem aktuellen Interessengebiet überlappen. Diese Regionen bzw. deren zugehörige Gebietsmanager enthalten lediglich eine kleine, begrenzte Anzahl von benachbarten Elementen. Für das Interessengebiet eines Nutzers braucht nur noch diese kleine Teilmenge aller im FüInfoSys vorhandenen Elemente berücksichtigt zu werden, was eine effiziente Vorfilterung der für den Nutzer relevanten Elemente bewirkt.

8.3.2 Regionenbasierte Lageermittlung Das Vorgehen bei der Ermittlung der für das Interessengebiet eines Nutzers relevanten Elemente und damit der Feststellung der aktuellen Lage ist in Abb. 8.4 dargestellt. (a)

(b)

(c) 3

Zunächst registrieren sich alle Elemente bzw. deren Lage-Services bei den Gebietsmanagern derjenigen Regionen, innerhalb derer sie sich befinden bzw. auf die sie einwirken können (vgl. Abb. 8.4 (a)). Dies geschieht in der Initialisierungsphase des FüInfoSys. Spätere Änderungen dieser RegionenZuordnung aufgrund der Bewegung mobiler Einheiten werden weiter unten in Abschn. 8.3.4 beschrieben. Für jeden Nutzer des FüInfoSys können, beispielsweise durch seine zugehörige Lage-Instanz, anhand der aktuell vom Nutzer gewählten Form und Größe seines Interessengebietes diejenigen relevanten Regionen ermittelt werden, welche dem aktuellen Interessengebiet hinterlegt sind. In Abb. 8.4 (b) ist beispielsweise das Interessengebiet des Nutzers E1 als blaues Polygon dargestellt. Von den Gebietsmanagern dieser relevanten Regionen können die benachbarten Elemente (bzw. die auf diese Regionen einwirkenden Truppenteile) ausge-

Um die Berechnung innerhalb des FüInfoSys zu optimieren, kann dabei die Form der Regionen vereinfacht werden, indem beispielsweise anstelle der genauen Grenzlinien einfache Rechtecke verwendet werden. Dies führt ggf. zu einer leicht modifizierten Regionenzuordnung, beeinflusst jedoch nicht die Funktionsfähigkeit des Positionsmanagements und die Verwaltung der Interessengebiete.

106

T. Nitsche

a

b

Registrierung Lage: E1

Region: NW

Region: NO

Region: NW

ASS

Registrierung

Lage: E1

Region: NO Interessengebiet

Registrierung (Wirkung)

Lage: E2

Relevante Regionen

Lage: E2

Lage: E3

ASS

Lage: E3

Registrierung

ASS

ASS

Region: SO

Region: SW Registrierung

Lage: E4

Lage: E4

c Subscription Region: NW

Region: SO

Region: SW

d Lage: E1

Region: NO

Lage: E1

Region: NW

Region: NO Subscription

Lage: E2

Lage: E2 ASS

Lage: E3

ASS

ASS

ASS

Region: SO

Region: SW

Lage: E3

Region: SO

Region: SW

Lage: E4

Lage: E4

e Region: NW

Lage: E1

Region: NO

Lage: E2 Lage: E3 ASS

Region: SO

Region: SW Lage: E4

Abb. 8.4 Vorgehen bei der regionenbasierten Lagefeststellung

(d)

(e)

lesen werden. Durch Aufbau von Abonnements (Subscription-Beziehungen) zu den relevanten Gebietsmanagern lassen sich Aktualisierungen infolge von Positionsänderungen von Einheiten automatisch übertragen (vgl. Abb. 8.4 (c) sowie Kap. 7). Zu den ermittelten benachbarten Elementen (bzw. deren Lage-Instanzen) werden ebenfalls Abonnements aufgebaut, um von ihnen jeweils Informationen über Position und aktuellen Status zu beziehen sowie bei deren Änderungen automatisch benachrichtigt zu werden (Abb. 8.4 (d)) Die aktuelle Lage mit den für den jeweiligen Nutzer relevanten Elementen kann anhand ihrer Positions- und Statusinformationen jeweils direkt angepasst und für den Nutzer visuell dargestellt werden (vgl. Kap. 5). Dabei müssen diejenigen Elemente weggelassen werden, die sich zwar in einer der relevanten

8 Intelligente Daten-Filterung in FüInfoSys

107

Regionen befinden, nicht aber innerhalb des Interessengebietes des Nutzers (siehe blaues Polygon in Abb. 8.4 (e)). Aufgrund der Vorfilterung der benachbarten Elemente innerhalb des FüInfoSys durch die relevanten Regionen betrifft dies jedoch nur wenige Elemente. Die Hauptarbeit dieses zweistufigen Filterungsprozesses erfolgt somit bereits durch die Regionen, wodurch jeweils nur ein Bruchteil der Elemente innerhalb des FüInfoSys überhaupt für die Lageermittlung betrachtet werden muss.

8.3.3 Positionsänderungen und Anpassung der Informationsbeziehungen Wird ein Element innerhalb des aktuellen Interessengebietes eines Nutzers von diesem überwacht, so wird er automatisch über Positions- und Statusänderungen in seiner Lagedarstellung informiert. Verlässt jedoch eine Einheit ihre aktuelle Region, so sind ggf. die Informationsbeziehungen zwischen den Elementen anzupassen. In Abb. 8.5 bewegt sich beispielsweise die Einheit E2 von der Region SW nach NW und damit in das (blau markierte) Interessengebiet des Nutzers E1 . Die dadurch erforderlichen Anpassungen der Informationsbeziehungen lassen sich wie folgt realisieren:

b

a Lage: E1

ASS

Region: NW

ASS

Aktualisierung

Region: NW

Region: NO

Lage: E1

Region: NO

Registrierung Lage: E2

Lage: E2 ASS

ASS

Lage: E3

Lage: E3

Deregistrierung ASS

Region: SO

Region: SW

Lage: E4

Lage: E4

c

d

ASS ASS

Lage: E1

Region: NW

Region: SO

Region: SW

Region: NO

ASS ASS

Lage: E1

Region: NW

Region: NO

Subscription Lage: E2

ASS

Lage: E2

ASS

Lage: E3

Region: SO

Region: SW Lage: E4

Abb. 8.5 Dynamische Bewegung von Einheiten

Lage: E3

Region: SO

Region: SW Lage: E4

108

T. Nitsche

(a)

Eine Einheit, welche ihre aktuelle Region verlässt, ändert in diesem Fall ihre Registrierung, d. h. sie meldet sich beim Gebietsmanager der neu betretenen Region an (vgl. Abb. 8.5 (a)). Sofern diese neu betretene Region für das Interessengebiet eines Nutzers relevant ist, wird er über die neu ins Gebiet eingetroffene Einheit vom Gebietsmanager informiert. Zwecks genauer Positions- und Statusermittlung kann der Nutzer (bzw. dessen Lage-Instanz) diese Daten direkt bei diesem neuen Nachbar-Element abonnieren. Schließlich wird das Lagebild entsprechend aktualisiert.

(b)

(c)

(d)

8.3.4 Anpassung der Zerlegung des Einsatzgebietes Zu beachten ist, dass die einzelnen Einheiten typischerweise nicht gleichmäßig über das Einsatzgebiet verteilt sind, sondern sich in bestimmten Teilgebieten auf dem Gefechtsfeld bzw. an bestimmten kritischen Punkten konzentrieren. So ist beispielsweise die Anzahl der Truppen im Großraum Kabul deutlich höher als in anderen Teilen Afghanistans. Das bedeutet, dass die Anzahl der Elemente, die sich innerhalb der verschiedenen Regionen befinden, deutlich voneinander abweichen kann. Um diese Ungleichheit in der Verteilung auszugleichen, kann die Zerlegung des Einsatzgebietes entsprechend an die reale Truppenverteilung angepasst werden. Dazu wird zunächst, basierend auf den geplanten Einsätzen und dadurch erwarteten Positionen und Bewegungen der einzelnen Einheiten, vorab das Einsatzgebiet entsprechend den jeweiligen Operationsräumen zerlegt. Die Einsatzhierarchie bewirkt dabei eine hierarchische Struktur der Operationsräume und damit auch der Regionen (vgl. Abb. 8.6). Diese vorherbestimmte Zerlegung des Einsatzgebietes kann während des Einsatzes weiter verfeinert werden, um auf eine zu starke Konzentration von Einheiten innerhalb eines Gebietes zu reagieren. In einem solchen Fall werden die einzelnen Einsatzgebiet NW NO

SW

SO

Abb. 8.6 Hierarchie von Regionen entsprechend der Operationsgebiete und damit der Verteilung der Einheiten auf dem Gefechtsfeld

8 Intelligente Daten-Filterung in FüInfoSys

109

Regionen in Teilregionen aufgeteilt, die von jeweils eigenen Gebietsmanagern verwaltet werden (vgl. Nitsche, 2007a). Dies ermöglicht eine dynamische Anpassung an die jeweiligen Truppenkonzentrationen und -bewegungen.

8.3.5 Verteilung der Service-Instanzen Wie in (Jansen et al., 2007) sowie in Kap. 4 beschrieben, kann die Verteilung der verschiedenen Services und deren nutzerspezifischer Instanzen im Netz prinzipiell beliebig konfiguriert werden. Wenn jedoch die potentiellen Kommunikationseinschränkungen auf der taktischen Ebene berücksichtigt werden, ist es sinnvoll, die Lage-Service-Instanz eines mobilen Nutzers lokal laufen zu lassen, z. B. direkt auf seinem mobilen Endgerät, im Führungsfahrzeug oder im Gefechtsstand, damit der Nutzer auch im Falle einer gestörten Kommunikationsverbindung sein Lagebild (zumindest partiell) darstellen kann. Im Falle partieller Netzwerkfragmentierung ist bei einer solchen Serviceverteilung zu erwarten, dass die Mehrzahl der räumlich benachbarten Elemente im lokalen Netzwerkfragment, beispielsweise per Funk, erreichbar ist. Die Lage-ServiceInstanz eines Nutzers innerhalb der Region kann folglich über die Status- und Positionsänderungen (der Mehrzahl) der direkt benachbarten Elemente bei Bedarf informiert werden, während weiter entfernt liegende Einheiten möglicherweise keine aktualisierten Informationen an den Nutzer senden können. (Die vorherigen, möglicherweise zum Teil veralteten Informationen liegen jedoch noch weiter vor, so dass zumindest eine Teillage dem Nutzer dargestellt werden kann.) Damit die regionenbasierte Lageermittlung jedoch weiterhin funktioniert, sollte sich der für die lokale Region zuständige Gebietsmanager ebenfalls innerhalb der Region und deren Netzwerkfragment befinden. Eine der Einheiten innerhalb der jeweiligen Region, beispielsweise ein Gefechtsstand, sollte deshalb ebenfalls den lokalen Gebietsmanager verwalten. Bei erwarteter Netzwerkfragmentierung könnte dieser ggf. auch als Cache dienen, um neben der Liste der in der Region enthaltenen Elemente auch Statusinformationen von diesen Einheiten zwischenzuspeichern. Dies gilt insbesondere für weiter entfernt liegende Einheiten, die jedoch auf die Region einwirken und folglich für die Lageermittlung relevant sind. Falls eine Einheit, welche den Gebietsmanager verwaltet, selbst die entsprechende Region verlässt, sollte der entsprechende Gebietsmanager zu einem anderen Rechner (möglichst einer der innerhalb der Region verbleibenden Einheiten zugehörig) migrieren.

8.4 Schlussfolgerungen Bei der Vernetzten Operationsführung (NetOpFü) muss die Menge an verfügbarer Information auf jeweils einsatzrelevante Teilmengen reduziert werden können, um z. B. eine Datenüberflutung zu vermeiden.

110

T. Nitsche

Die für einen Einsatz in einem bestimmten geografischen Interessengebiet relevanten Informationen sind dabei aus der Gesamtheit aller verfügbaren Informationen herauszufiltern und dem militärischen Entscheider in einem Einsatzlagebild anzubieten. Innerhalb dieses Interessengebietes sind lagerelevant sowohl alle mobilen Elemente wie Einheiten, als auch nicht mobile, militärisch relevante Objekte wie Brücken, die sich in einem bestimmten Umkreis um den Entscheider bzw. angrenzend an sein Operationsgebiet befinden. Das betrifft auch die im FüInfoSys erfassten feindlichen Elemente, die auf das Interessengebiet infolge ihrer Waffenoder Bewegungsreichweite von außen einwirken können. Zur Unterstützung einer effizienten Planung und Überwachung militärischer Aktionen in einem Interessengebiet kann im FüInfoSys das Konzept von Gebietsmanagern verwendet werden. Diese verwalten alle militärisch relevanten Elemente, die sich innerhalb einer bestimmten Region (z. B. einem oder mehreren Planquadraten einer Karte) befinden oder aus weiter entfernten Regionen auf diese einwirken können. Die für das Interessengebiet relevanten, mobilen Elemente lassen sich dadurch effizient vorfiltern. Dazu werden lediglich diejenigen Elemente betrachtet, welche aufgrund ihrer Position oder Reichweite zu denjenigen Regionen gehören, welche dem aktuellen Interessengebiet unterlegt sind. In einem serviceorientierten FüInfoSys können für die nutzerspezifischen Lagedarstellungen Abonnements gezielt zu den oben genannten, für das aktuelle Interessengebiet relevanten Elementen aufgebaut werden. So lassen sich automatisch Informationen über deren Position und aktuellen Status beziehen. Bei Positionsänderungen sind dann lediglich die Informationsbeziehungen zu den vergleichsweise wenigen Elementen anzupassen, welche eine vom Interessengebiet berührte Region verlassen oder neu betreten.

Literaturverzeichnis Alberts, D. S. & Hayes, R. E. (2003). Power to the Edge. Washington, DC: CCRP. Bachran, T., Bongartz, H. H. J., & Tiderko, A. (2001). A Framework for Multicast and Quality based Forwarding in MANETs. In CCN’05: Proceedings of the 3rd IASTED International Conference on Communications and Computer Networks Marina del Raym, CA: ACTA Press. BMVg (2006). Teilkonzeption Vernetzte Operationsführung. Denning, P. J. (2006). Infoglut. Communications of the ACM, 49(7), 15–19. Hayes-Roth, F. (2006). Two Theories of Process Design for Information Superiority: Smart Pull vs. Smart Push. In Proceedings of the Command and Control Research and Technology Symposium (CCRTS) San Diego, CA. Jansen, N., Nitsche, T., Spielmann, M., & Trautwein, I. (2007). Managing Services in Networkbased Command and Control Information Systems. In Military Communications and Information Systems Conference (MCC’2007) Bonn. Jansen, N. & Spielmann, M. (2007). Konzeption eines verteilten Datenhaltungs- und Datenmanagement-Systems für lagerelevante Daten in FüInfoSys. FKIE-Bericht Nr. 142, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Kruse, J., Adkins, M., & Holloman, K. A. (2005). Network Centric Warfare in the U.S. Navy’s Fifth Fleet – Web-Supported Operational Level Command and Control in Operation Enduring Freedom. In Proceedings of the 38th Hawaii International Conference on System Sciences (HICSS): IEEE Computer Society.

8 Intelligente Daten-Filterung in FüInfoSys

111

Kuper, S. R., Eggleston, R. G., & Scott, R. (2003). Using Work-Centered Support System Technology to Enhance Command and Control. In Proceedings of the 8th International Command and Control Research and Technology Symposium (ICCRTS) Washington, DC. Mulgund, S. & Landsmann, S. (2007). User Defined Operational Pictures for Tailored Situational Awareness. In Proceedings of the 12th International Command and Control Research and Technology Symposium (ICCRTS) Newport, RI. National Commission on Terrorist Attacks upon the United States (2004). The 9/11 Commission Report. Nitsche, T. (2006). Information Access in Tactical Command and Control Information Systems. In Proceedings of the 11th International Command and Control Research and Technology Symposium (ICCRTS) Cambridge, UK. Nitsche, T. (2007a). Evaluating Region-Based Location Management Schemes for ServiceOriented Command and Control Information Systems. In Military Communications and Information Systems Conference (MCC’2007) Bonn. Nitsche, T. (2007b). Location Management in Distributed, Service-Oriented Command and Control Information Systems. In Proceedings of the International Conference on Software and Data Technologies (ICSOFT) Barcelona, Spanien. Nitsche, T. (2007c). Managing Areas of Interest in Command and Control Information Systems. In Proceedings of the 12th International Command and Control Research and Technology Symposium (ICCRTS) Newport, RI. Ruff-Stahl, H.-J. (2008). Der menschliche Faktor im zukünftigen Kriegsbild – Situation Awareness und Entscheidungsunterstützung in komplexen Systemen. Strategie und Technik, 6-2008, 40–46. Shin, S. Y., Park, S.-H., Jung, B. H., & Kim, C. (2006). Dynamic Location Management Scheme Using Agent in a Ubiquitous IP-Based Network. In Management of Convergence Networks and Services (APNOMS 2006), volume 4238 of LNCS (pp. 491–500).: Springer. Spielmann, M. (in Bearbeitung). Konzeption verteilter Führungsinformationssysteme zur Unterstützung der Vernetzten Operationsführung. FKIE-Bericht, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Wilson, C. (2004). Network Centric Warfare: Background and Oversight Issues for Congress. CRS Report for Congress RL32411.

Kapitel 9

Wissens- und Workflowmanagement Jürgen Kaster, Wolf-Dieter Huland und Sascha Huy

„In den grundlegenden Fragen muss man naiv sein. Und ich bin der Meinung, dass die Probleme der Welt und der Menschheit ohne Idealismus nicht zu lösen sind. Gleichwohl glaube ich, dass man zugleich realistisch und pragmatisch sein sollte.“ Helmut Schmidt

9.1 Einleitung Datenmengen wachsen explosionsartig, Algorithmen werden komplexer, Netzwerke verbinden Menschen und Maschinen weltweit. In diesem sich ständig verändernden Umfeld ist eine umfassende Informationsversorgung aller Entscheidungsträger für den erfolgreichen Einsatz der Streitkräfte eine große Herausforderung. Für das Erreichen des Kernziels „Informationsüberlegenheit“ ist ein systematisches, zielorientiertes Zusammenwirken aller Beteiligten in einem komplexen und weit reichenden Informationsverbund zwingende Voraussetzung. Die Bewältigung dieser Anforderung erfordert „intelligente“ Systemlösungen. Diese Intelligenz wird in vielen Anwendungsbereichen nur durch eine symbiotische Zusammenarbeit von Mensch und Maschine erreicht. Unter dieser Prämisse hat die Qualität der Interaktionsgestaltung einen besonderen Einfluss auf die Leistungsfähigkeit des Gesamtsystems. Wissens- und Workflowmanagement sind dabei als zwei untrennbar verwobene, sich ergänzende Themenkomplexe anzusehen. Am FKIE entstanden im Bereich der Nachrichtengewinnung und Aufklärung (NG&A) eine Reihe von prototypischen Unterstützungssystemen für den militärischen Führungsprozess, die diese Sichtweise konsequent berücksichtigen. Nach einer Diskussion der Problemstellung sowie der Erläuterung der wissenschaftlichen Zielsetzung bei deren Bewältigung werden in Abschn. 9.4 grundsätzliche Lösungsansätze aufgezeigt.

M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

115

116

J. Kaster, W.-D. Huland und S. Huy

9.2 Problemstellung Im Folgenden werden zunächst die Bedeutung eines tragfähigen Konzeptes für das Wissensmanagement in der Bundeswehr sowie einige der sich daraus ergebenden Schwerpunktfragen hervorgehoben. Nach einer Darstellung des Sachstands anhand typischer Beispiele werden Strategien zur Bewältigung bestehender Fähigkeitslücken vorgestellt.

9.2.1 Wissensmanagement – Stellenwert in der Bundeswehr Unter Ausnutzung aktueller Entwicklungen von leistungsfähigen IuK-Technologien wird Wissen im militärischen Umfeld zur entscheidenden Ressource für verbesserte Sicherheit, Zukunftsfähigkeit und Prosperität. In der Konzeption der Bundeswehr (BMVg, 2004) wird dessen Bedeutung für die Einsatzfähigkeit der Streitkräfte betont und die Einbindung und Nutzung expliziten und impliziten Wissens für eine erfolgreiche Auftragserfüllung gefordert. Dementsprechend gewinnt der Transformationsprozess hin zu einem erfolgreichen Wissensmanagement in der Bundeswehr zunehmend an Dynamik. Eine förderliche „Bundeswehr-Unternehmenskultur“ wurde in Grundlagen bereits durch neue Grundsätze der Inneren Führung geschaffen. Beispielsweise haben Dezentralisierung, Delegation von Verantwortung, Auftragstaktik u. ä. in Bezug auf Wissensmanagement eine steigende Bedeutung erfahren. Die Umsetzung der damit verbundenen Anforderungen stellt jedoch keine einmalige Aktivität mit einem definierten Einführungstermin dar. Anforderungen ändern sich, neue Wege müssen beschritten werden. Effizientes Wissensmanagement ist ein fortlaufender Prozess, der ständig Anpassungen erfordert. Langfristig ist eine bundeswehreinheitliche Lösung eines der wichtigsten Ziele. In dieser Hinsicht besteht ein Bedarf an tragfähigen und übergreifend abgestimmten konzeptionellen Grundlagen (vgl. auch „Militärische Führungsinformationssysteme: Einführung“, Abschn. 1.1).

9.2.2 Schwerpunktfragen Effizientes und umfassend angelegtes Informations- und Wissensmanagement sind noch weitgehend ungelöste Herausforderungen für den Einsatz von Streitkräften. Militärischen Entscheidungsträgern stehen zwar heutzutage zur Erfüllung ihres Auftrags auf allen Ebenen riesige Mengen von Daten und Informationen zur Verfügung. Solange diese jedoch nicht optimal aufbereitet, bewertet und verteilt werden, überlasten sie oftmals den menschlichen Bearbeiter und nützen besonders in zeitkritischen Situationen nur wenig.

9 Wissens- und Workflowmanagement

117

Will man diese Situation verbessern, so sind zumindest folgende Schwerpunktfragen zu beantworten: Welchen Einfluss hat das moderne IT-gestützte Informationsund Wissensmanagement auf den Führungsprozess?1 Welche Anforderungen müssen an die Kommunikations- und Informationssysteme gestellt werden, um ein leistungsfähiges Informations- und Wissensmanagement im Einsatz zu gewährleisten?

9.2.3 Fähigkeitslücken und Strategien zu ihrer Bewältigung „Wenn wir nur wüssten, was wir wissen!“ – so noch vor wenigen Jahren die Klage eines hochrangigen Militärs im Zentrum für Nachrichtenwesen der Bundeswehr (ZNBw). Er spielte damit auf Mängel im Informationsmanagement seiner Dienststelle an, bei der die gesammelten Datenbestände aus der Historie heraus auf viele Anwendungen, Systeme, Datenträger usw. verteilt waren. Noch kurz zuvor hatte er in seiner Eigenschaft als oberster G2 einer anderen Dienststelle2 beklagt, dass die riesige Informationsflut aus den Einsatzgebieten mit den verfügbaren Mitteln kaum zu beherrschen ist. Besonders hohe Anforderungen an eine optimierte Verarbeitung und Kommunikation von Daten, Informationen und Wissen ergeben sich im Bereich Nachrichtengewinnung und Aufklärung (NG&A), der durch den Umgang mit unsicherem und unvollständigem Wissen über nichtkooperative Elemente und deren Handlungen bzw. Handlungsabsichten geprägt ist. NG&A ist in besonderem Maße dadurch gekennzeichnet, dass das vorliegende Wissen in einem ständigen Aufwuchs begriffen ist, dabei aber immer unscharf und unvollständig bleiben wird. Eine effiziente und umfassende Meldungsversorgung ist umso mehr eine unabdingbare Voraussetzung für die sich daran anschließende Informationsverdichtung und die Erarbeitung kontextbezogener Auswertungen (BMVg, 2001). Der für die Zukunft angestrebte Verbund NG&A wird allerdings ein hochkomplexes, dynamisch vernetztes Arbeitssystem sein, dessen Nutzung von wechselnden Aufgabenstellungen, unterschiedlichen Benutzerqualifikationen und der Forderung nach intensiver Kommunikation und Kooperation bestimmt ist. Die Qualität von ebenen- und bereichsübergreifenden Führungsinformationssystemen ist allgemein nicht auf dem Stand, dass alle identifizierten Fähigkeitslücken kurzfristig geschlossen werden können. Harmonisierungs- und Integrationsbemühungen geraten angesichts der großen Komplexität der Systeme an ihre Grenzen. Die Sicherstellung einer hohen Interoperabilität verlangt vielfältige klare Schnittstellendefinitionen, eine Betrachtungsweise, die in der langen Entwicklungsgeschichte der FüInfoSys oftmals vernachlässigt wurde.

1

Man denke dabei an die neuen Ansätze durch Web 2.0 Technologien, die zu einer Verselbstständigung des Wissensmanagement-Prozesses im Sinne der Nutzung einer „kollektiven Intelligenz“ führen. Oder an die Frage: Welches Potential bietet eine SOA-basierte Prozessgestaltung im Sinne einer Straffung von Arbeitsprozessen? 2 Es handelt sich um das Heeresführungskommando (HFüKdo); Bereich G2-Wehrlage.

118

J. Kaster, W.-D. Huland und S. Huy

Im Grunde besteht die Problematik in der adäquaten Zusammenführung von Nutzerforderungen (bzw. der hieraus ableitbaren Semantik) und der technischen Umsetzung durch IT-Verfahren. Die Herausforderungen liegen hierbei primär auf der organisatorischen und fachlichen Ebene und erst in zweiter Linie in der Herstellung technischer Lösungsverfahren. Zwei Kernprobleme treten in den eingangs dieses Abschnitts zitierten Aussagen zutage: Ein eingeschränkter Zugriff auf den vorhandenen Informationsbestand einerseits sowie eine Informationsüberflutung durch die hohen Datenraten andererseits; riesige Datenbestände als Arbeitsgrundlage, aber diese weder vollständig noch adäquat sortiert. Nun wird aber von modernen FüInfoSys, deren Aufgabe die technische Unterstützung im gesamten Führungszyklus ist, erwartet, dass sie derartige Problemstellungen ohne weiteres eliminieren können. Wenn dennoch an manchen Stellen (vermeintlich technische) Fähigkeitslücken zu bemängeln sind (zu langsam, keine ausreichende Kommunikationsverbindung, fehlende Interoperabilität u. a. m.), so stellt sich die Frage, ob bei der Entwicklung der FüInfoSys in jedem Fall die richtigen Fragen im Mittelpunkt stehen. Wie entscheidend ist es, mehr „Rechenleistung“ als Grundlage für die Informationsverarbeitung zur Verfügung zu stellen? Wie vordringlich ist es, „intelligente Spezialsysteme“ im Bereich der NG&A zu fordern? Die Liste der kritischen Fragen ist lang. Übertragen auf die FüInfoSys der Bundeswehr bedeutet dies, dass zunächst die Basisforderungen zu analysieren und zu bekämpfen sind, bevor aufwändige Speziallösungen in den Fokus der Entwicklungen gerückt werden. Eine solche Grundsatzlösung zu schaffen, war vor einigen Jahren die Prämisse für die Entwicklung einer Meldungsdatenbank für das HFüKdo mit dem Ziel, „Ordnung“ in die Meldungsflut aus den Balkaneinsätzen zu kommen. Es sollte ein Verfahren konzipiert werden, das einerseits den schnellen Zugriff auf das gesamte vielfältige Meldungsaufkommen ermöglichte, andererseits aber situationsbezogen nur die Dokumente zur Verfügung stellen würde, die für einen Bearbeiter aktuell Bedeutung haben. Die Auswertung sollte weitgehend den Anwendern überlassen bleiben, da diese mit ihrer breiten Fachexpertise und ihrem „Weltwissen“ bezüglich der Einsatzlage in dieser Hinsicht der Maschine sowieso überlegen wären.3 Damit war der Weg vorgezeichnet: weg von Dokumentenwirrwarr in weit gefächerten Dateiverzeichnissen, hin zu einem systematischen Dokumentenmanagement in einer Datenbank, die nicht nur das systematische Speichern aller Arten von Dokumenten und Meldungen erlaubt, sondern vor allem das kontextbezogene „Suchen & Finden“ im gesamten Datenbestand als zentrale Unterstützungsleistung realisiert. Im Ergebnis entstand ein Verfahren für ein konsolidiertes Management der vielfältigen Meldungen aus den Einsatzgebieten. Der Lösungsansatz ist in Abschn. 9.4.2 beschrieben.

3

Ganz abgesehen davon, dass in den kritischen militärischen Situationen dem jeweils verantwortlichen Befehlshaber immer „das letzte Wort“ vorbehalten bleiben muss.

9 Wissens- und Workflowmanagement

119

9.3 Wissenschaftliche Zielsetzung Professionelles Wissensmanagement ist für den militärischen Führungsprozess ein unerlässlicher Erfolgsfaktor. Entscheidend für die Wirksamkeit von Wissensmanagementvorhaben ist die Koordination der Faktoren Unternehmenskultur, Aufbauund Ablauforganisation, Personalmanagement sowie Informations- und Kommunikationstechnik. Die adäquate Bilanzierung und die gemeinsame Ausrichtung dieser Faktoren sind erfolgskritisch. Organisationen wie die Bundeswehr müssen hierzu das zugreifbare Wissen und die Kompetenzen aller beteiligten Mitarbeiter wirksam bündeln (BMVg, 2004). Bei diesem Umgang mit Wissen und Kompetenzen lassen sich drei Ebenen unterscheiden: die organisatorisch-gesellschaftliche Ebene, die individuelle Ebene und die mediale, technische Ebene. Auf allen Ebenen sind adäquate Lösungen zu suchen. Wissenschaftliche Zielsetzung der nachfolgend beschriebenen Lösungsansätze sind daher die Konzeption, Entwicklung und Demonstration effizienter Verfahren zu einem kombinierten Wissens- und Workflowmanagement. Es sollen leistungsfähige Arbeitshilfen im Informationsverbund in der Breite zur Verfügung gestellt und eine aufgabenangemessene Kommunikation und Zusammenarbeit der militärischen Nutzer (Sachbearbeiter, Entscheidungsträger, Manager) erleichtert werden. Die Qualität der Arbeitsergebnisse soll verbessert, die Bearbeitungszeit verkürzt, die Belastung von Operateuren besonders in zeitkritischen Situationen vermindert sowie der Ausbildungsaufwand reduziert werden. Erfolgversprechend sind Ansätze, die die „lernende Organisation“ fördern, mit möglichst flacher Hierarchie und einer netzartigen Struktur, die Wissen akquiriert, generiert und transferiert sowie das eigene Verhalten an neue Erkenntnisse anpassen kann. Für die jeweilige Aufgabe und Systemumgebung wird ein anpassbares Workflowmanagement benötigt, das den Informations- und Arbeitsfluss zeit- und sachgerecht gemäß geeigneter Rollenkonzepte regelt. Verfahren zum Wissensmanagement sollen Funktionen für den in den Arbeitsprozess integrierten Umgang mit Daten, Informationen und Wissen bereitstellen. Die Komponenten eines Wissensmanagementsystems sind allerdings vielschichtig, wie nachstehende Aufzählung verdeutlicht (Tochtermann, 2006):         

Wissenssuche und Wissenszustellung, Wissensrepräsentation und Visualisierung, Wissensspeicherung, -publizierung, -strukturierung, automatische Wissenseinbringung und -klassifikation, Wissenskommunikation und -kooperation, computerunterstütztes Lehren und Lernen, Benutzerverwaltung und Sicherheitsaspekte, Integrationsfähigkeit und Erweiterungsmöglichkeiten, technische Plattform und Kompatibilität zur IT-Infrastruktur.

120

J. Kaster, W.-D. Huland und S. Huy

9.3.1 Wissensmanagement als Führungsaufgabe In der praktischen Anwendung ist zwischen explizitem Wissen (z. B. konkrete Beobachtungen, Ereignisse) und implizitem, nicht formalisierbarem Wissen zu unterscheiden. Diese Dualität – und die daraus abzuleitenden Schwerpunkte der Wissensmanagement-Strategie – hat im Führungsprozess eine große Bedeutung. Während explizites Wissen formal beschrieben und damit in Dokumenten und Datenbanken vorgehalten werden kann (engl.: „People-to-Document“), sind zur Weitergabe von implizitem Wissen weitergehende Kommunikationsverfahren im Sinne einer „People-to-People“-Strategie erforderlich. Erst die Kombination beider Sichtweisen bietet die Voraussetzung, ein Lageverständnis im Sinne eines „gemeinsamen mentalen Modells“ zu erzeugen. Klassisches Wissensmanagement, das fixiert ist auf die Verlinkung von Informationen und die Optimierung der Suchalgorithmen, stößt zwangsläufig dann an die Grenzen, wenn – wie es in einem Teilstreitkräfte-übergreifenden und multinationalen Umfeld (joined und combined) die Regel ist – vielfältige Organisationen und Wissensträger an einem gemeinsamen Wertschöpfungsprozess beteiligt sind. Über die Bereitstellung von modernen IT-Systemen hinaus ist Wissensmanagement eine Führungsaufgabe, die organisatorische Maßnahmen und damit einen intensiven Austausch zwischen allen beteiligten Dienststellen und Handlungsträgern erfordert. Kompetenzen und Fähigkeiten der Fachbearbeiter rücken in den Mittelpunkt. Die IT-Verantwortlichen müssen die Bundeswehr als sozio-technisches System begreifen, in der das soziale und das technische System in einer Wechselwirkung stehen. Der dringend notwendige Transformationsprozess ist also eine Managementaufgabe, die sich in mehrere Themenbereiche gliedert, u. a. Organisationsstruktur, Informationstechnologie und Wissensbilanzierung. Wissensmanagement ist also mehr als bloße IT-Optimierung. Es muss die Wechselwirkungen zwischen Organisationsstrategie und Informationstechnologie adäquat berücksichtigen. Dies erfordert die Integration von Methoden und Werkzeugen im Geschäftsprozess der jeweiligen Anwendungsumgebung. Daten müssen kontextbezogen geordnet, aufbereitet, dargestellt und gespeichert werden. Bei diesen Fragen geht es jedoch nie um die reine Technik. Immer zu berücksichtigen sind die Faktoren Mensch und Organisation. Dies ist – um nur ein Beispiel zu nennen – für die Bundeswehr bei einem Kontingentwechsel von größter Bedeutung, wenn es darum geht, das Wissen der im Einsatz erfahrenen Soldaten über die Gegenseite nutzbar zu machen und auf deren Nachfolger zu übertragen. Die neuen Mitarbeiter müssen nicht nur in ihre Aufgaben, sondern auch in die Fachkompetenzen eingeführt werden. Der Wissenstransfer ist hierbei in sechs Arbeitsschritte gegliedert: 1. 2. 3. 4. 5. 6.

Identifizieren von Mitarbeitern mit hoher Fachkompetenz (Wissensgeber), Identifizieren der Wissensempfänger, Identifizieren der kritischen Erfahrungen, die zu übertragen sind, inhaltliche, zeitliche, methodisch-didaktische Planung des Wissenstransfers, Durchführung des Wissenstransfers, Erfolgskontrolle hinsichtlich Fähigkeiten und Fertigkeiten der neuen Mitarbeiter.

9 Wissens- und Workflowmanagement

121

9.3.2 Wissensmanagement und Workflowmanagement – symbiotisches Zusammenwirken Offensichtlich handelt es sich bei diesem Wissenstransfer nur vordergründig um einen technisch geprägten Vorgang. Der Begriff „Wissen“ impliziert, dass entscheidungsrelevantes Situationsbewusstsein erst durch Sichtweise und Bewertung des Betrachters entsteht, der Mensch also der eigentliche Wissensträger ist, nicht die Technik. In analoger Weise betrifft „Workflow“ nicht das Kommunizieren von Maschinen, sondern umfasst Arbeitsabläufe, die erst durch das Zusammenwirken personeller Ressourcen und Expertisen einen Mehrwert schaffen. In beiderlei Hinsicht kann (und muss) IuK-Technik die Unterstützungsmöglichkeiten ausschöpfen, beispielsweise bei der Verarbeitung von Massendaten, durch effiziente Filter-, Suchund Recherchehilfen sowie durch Übernahme von Routinefunktionen. Von einer durchgängigen Nutzung „maschineller Intelligenz“ sind wir aber noch weit entfernt. Die Technologie nimmt also lediglich die Rolle eines „Enablers“ für Wissensmanagement ein, löst aber die anstehenden Probleme nicht. Um die Vielfalt der individuellen Kompetenzen nutzbar zu machen, ist eine optimale Gruppenkommunikation erfolgskritisch. Wissens- und Workflowmanagement sind also untrennbar miteinander verwoben. Dies ist der Ausgangspunkt für eine Reihe von Lösungsansätzen, die in den letzten Jahren mit Schwerpunkt im Umfeld der NG&A entwickelt wurden.

9.4 Anwendungsbeispiele Die in diesem Abschnitt vorgestellten prototypischen Einsatzunterstützungskonzepte stellen Grundsatzlösungen dar, die aufbauend auf einem weit reichenden Informationsverbund ebenen- und bereichsübergreifende Kooperationsprozesse nutzerzentriert gestalten und informationstechnisch optimieren. Die Anwendungsbeispiele wurden in den Jahren ab 2000 im FKIE entwickelt. Sie folgen den gleichen Entwicklungsgrundsätzen und basieren auf bundeswehrweit verfügbaren GroupwareInstallationen4.

9.4.1 Einsatztagebuch Das Einsatztagebuch (ETB) für das Führungszentrum der Bundeswehr (FüZBw) war ein erstes Anwendungsbeispiel, mit dem das methodische Vorgehen zur Kombination von Wissens- und Workflowmanagement demonstriert wurde (Kaster, 2001). Es handelt sich hierbei um eine Musterlösung, bei der die Erstellung von Einsatzdokumentationen in einem mehrstufigen Koordinierungs- und Genehmigungsprozess abgewickelt wird. Kernobjekt in diesem Prozess ist der Tagebucheintrag, der eine Strukturierung entsprechend den vorgegebenen Kommunikations-, Dokumentations- und Auswerteanforderungen aufweist. Der Meldungsteil umfasst Sachverhalte, Vorgangsbe4

Lotus Notes-Installationen der Bundeswehr

122

J. Kaster, W.-D. Huland und S. Huy

Abb. 9.1 Anwendung Einsatztagebuch: Der generische Arbeitsprozess beruht auf einem linearen Prozessmodell, das auf vergleichbare Anwendungen leicht übertragen werden kann

schreibungen, Bewertungen, Ergebnisse und Maßnahmen; in den Metadaten finden sich alle Gliederungsmerkmale für die thematische Zuordnung der Meldung sowie weitere Angaben für die Dokumentverwaltung. Struktur und Bearbeitungsregeln dieser Metadaten sind entscheidend dafür, ob der jeweilige Tagebucheintrag (der im Kern aus nur bedingt automatisch verarbeitbaren Text- und Grafikanteilen besteht) in späteren Analysen kontextbezogen gefunden und verwendet werden kann.5 Der Arbeitsablauf wird durch ein Rollen- und Rechtekonzept gesteuert und derart umgesetzt, dass die Fachbearbeiter im Rahmen ihrer Zuständigkeiten verzugsarm kooperieren können. Das Anwendungskonzept ist gemäß dem Ergonomiekriterium Handlungsangemessenheit optimiert und beinhaltet die folgenden Grundelemente: ein Verfahren zur Erstellung, Prüfung und Genehmigung von Tagebucheinträgen, das eigentliche operative Tagebuch und ein Archivierungskonzept. In einer Client-Server-Umgebung kann das ETB – je nach Fokus der Anwendung – von vielen Fachbearbeitern und Dienststellen im Rahmen ihrer Aufgabenstellungen genutzt werden. Der Abgleich der Datenbanken zwischen den beteiligten Dienststellen erfolgt durch automatische Datenreplikation. Die Anforderungen an den einzelnen Arbeitsplatz (präziser: an die einzelne Rolle) sind gering, wo5 Die thematische Zuordnung wird in diesem Anwendungsbeispiel durch ein dreistufiges Schlüsselwortverfahren abgebildet (Pflichtfelder). Das ist feingranular genug, um eine Diskriminierung von Texten zu erreichen, andererseits nicht so tief geschachtelt, dass die sich ergebende Struktur für den Anwender verwirrend ist.

9 Wissens- und Workflowmanagement

123

durch eine hohe Mitarbeiterkompetenz bei einfacher Erlernbarkeit (zweites zentrales Ergonomiekriterium!) sichergestellt wird. Der Nutzwert des Einsatztagebuchs ergibt sich sowohl aus der einfachen Prozessstruktur im Erstellungsgang der Tagebucheinträge als auch aus deren zweckdienlichem Aufbau, der effiziente Selektionsverfahren und vielfältige Analysen nach unterschiedlichsten Dimensionen und Kriterien ermöglicht (Kaster & Kaster, 2000).

9.4.2 Einsatzdatenbanken im Meldewesen der Bundeswehr Im Themenfeld Unterstützung Meldewesen Bundeswehr stellt die kontinuierliche Verbesserung der Kommunikation im Bereich Nachrichtengewinnung und Aufklärung die zentrale Aufgabe dar. Aufgabe ist die Aufnahme, Verarbeitung und Auswertung der vielfältigen Aufklärungsmeldungen und -ergebnisse aus den Einsatzgebieten der Bundeswehr. Mit der Datenbank Einsatz (DBEins) entstand ein Konzept für das Management, den Transport und die Aggregation von Einsatzdaten und -meldungen über die militärischen Führungsebenen hinweg (Kaster et al., 2003). Das Verfahren systematisiert und unterstützt die Erfassung, Bearbeitung, Auswertung, Speicherung und Lagebildgenerierung und kann als Standardlösung für die strukturierte Nutzung von G2-Meldungen aus Krisen- und Einsatzgebieten gesehen werden. In einem durchgängigen Prozess werden diverse Dokumenttypen verwaltet, die das komplette Spektrum von der Freitext-Meldung über die schwach strukturierte Meldung bis hin zur formatierten Meldung abdecken. Für die breite Einsatzfähigkeit ist es entscheidend, dass kein Meldungstyp a priori ausgeklammert wird (was eine zwingende, aber nicht einfach zu realisierende Anforderung an den operationellen Betrieb darstellt). Das Verfahren basiert auf dem Konzept des Einsatztagebuchs (s. Abschn. 9.4.1). Vorwiegend frei formulierte Beobachtungen und Sachverhalte werden durch Metadaten gezielt angereichert, damit sich eine sachorientierte Datenhaltung ergibt, in der sich kontextbezogene Filter-, Such- und Rechercheverfahren anwenden lassen. Aufgrund der im Vergleich zum Einsatztagebuch höheren Aktualität hat die Qualität der Metadatenstruktur allerdings eine noch größere Bedeutung. Die DBEins erfüllt darüber hinaus im Hinblick auf den Meldungsdurchsatz vom Soldaten im Einsatzgebiet bis hoch zur obersten Führungsebene weitere verfahrensspezifische Anforderungen, die in Zusammenarbeit mit dem Heeresführungskommando (HFüKdo) ermittelt und validiert wurden. Dazu gehören Konfigurationsverfahren zur Abbildung der konkreten Einsatzerfordernisse auf die Datenbankstruktur, umfassende Sicherheits- und Kommunikationskonzepte sowie dedizierte Bearbeitungsfunktionen in den jeweiligen Fachbereichen bzw. Führungsebenen. Der Bearbeitungsprozess ist in vier grundsätzliche Schritte aufgeteilt (Abb. 9.2): 1. Während der Eingangsbearbeitung werden neue Dokumente entweder formgerecht erstellt (Nutzung von Vorlagen) oder vorhandene Dokumente qualitativ angereichert (importierte Meldung mit evtl. zusätzlicher Verschlagwortung). 2. Ein leistungsfähiges, stabiles und organisiertes Informationsmanagement wird durch den Einsatz einer leistungsfähigen Datenbankplattform und -anwendung

124

J. Kaster, W.-D. Huland und S. Huy

Abb. 9.2 Anwendung Datenbank Einsatz: Der Bearbeitungsprozess ist in vier Schritte aufgeteilt: (1) Eingangsbearbeitung zur Dokumenterstellung; (2) Info-Management und Meldungsauswertung für die Lagefeststellung; (3) transparente Selektionsverfahren für den Zugriff auf die Dokumente, (4) Visualisierung im Lagebild

sichergestellt. Für die Prozesse Meldungsauswertung und Lagefeststellung stehen effiziente Recherche- und Fusionsverfahren zur Verfügung. 3. Transparente Selektionsverfahren optimieren den Zugriff auf die Datenbestände. 4. Georeferenzierte Daten werden auf Knopfdruck im Lagebild visualisiert. Das Konzept wurde in mehreren Führungsinformationssystemen umgesetzt, u. a. FüInfoSys SK und JASMIN II. In militärischen Übungen wurde zudem die Nutzbarkeit der Spezialisierungen Militärische Situations-Datenbank (MilSit) und Military Book (MilBook) demonstriert, die Daten aus standardisierten Meldungsformaten (ADatP-3) und generalisierten Austauschmodellen (MIP, JC3IEDM) verarbeiten.6

9.4.3 DV-Unterstützung für die Auftragssteuerung Zukunftsorientierte Ansätze im Sinne des kombinierten Wissens- und Workflowmanagements werden auch mit der DV-Unterstützung für die Auftragssteuerung 6

Hierzu liegen diverse Erfahrungsberichte u. a. aus den Teilnahmen im Rahmen der NATO-Übung CWID (Coalition Warrior Interoperability Demonstration) in den Jahren 2004–2008 vor (Kaster, 2006; Kaster, 2008).

9 Wissens- und Workflowmanagement

125

(DV-AS) verfolgt (Kaster, 2007). Diese Anwendung verbindet Verfahren zur Wissensgenerierung mit der koordinierten Abwicklung von Informationsersuchen. Eine detaillierte Beschreibung findet sich im nachfolgenden Kap. 10. Die DV-AS setzt die organisatorischen Vorgaben zur Abarbeitung von Aufträgen in einen technisch unterstützten Arbeitsablauf um (vgl. Abb. 9.3): Berechtigte Dienststellen oder Bedarfsträger formulieren Rechercheaufträge (engl.: Request for Information, RFI). Die DV-AS nimmt diese entgegen, leitet sie an zuständige Fachbereiche bzw. federführende Bearbeiter weiter und überwacht die termingerechte Bearbeitung der Anfragen. Die verantwortlichen Bearbeiter versenden das Ergebnis (RFI-Produkt) zeit- und sachgerecht an den jeweiligen Bedarfsträger bzw. an weitere Interessenten. Zudem archivieren sie das Produkt in der kontinuierlich wachsenden „Wissensdatenbank“. Der Prozess findet bei Bedarf mehrstufig unter Einbeziehung iterativer Schleifen statt, so dass federführende Verantwortliche ein Gesamtprodukt unter Einbeziehung von weiteren Zuarbeiten (Teilprodukten) entwickeln können. Die DV-AS wird seit Anfang 2003 im operationellen Umfeld des ZNBw (System JASMIN I) bzw. dessen Nachfolgeorganisationen eingesetzt und validiert. Im Jahr 2007 wurde die Anwendung so erweitert, dass sie auch für die Vergabe von Aufträgen an externe Dienststellen genutzt werden kann. 2008 wurde die DV-AS in JASMIN II integriert, indem die Auftragssteuerung über verschiedene Web-Services an die Datenhaltung in JASMIN II angebunden wurde.

Abb. 9.3 Anwendung Auftragsmanagement: DV-AS ist ein System zur Steuerung und Überwachung der Abarbeitung von Auftragseingängen (z. B. Informationsersuchen, RFI). Es setzt die organisatorischen Vorgaben zur Abarbeitung von Aufträgen in einen DV-technisch unterstützten Arbeitsablauf um

126

J. Kaster, W.-D. Huland und S. Huy

9.4.4 DV-Unterstützung in der Zentrale MilNW Mit den Entwicklungen, die durch Begriffe wie „asymmetrische Kriegsführung“, „terroristische Bedrohung“ oder „Aufklärung irregulärer Kräfte“ gekennzeichnet sind, wuchs die Notwendigkeit, in den Gefechtsständen der Einsatzkontingente eine Zentrale für das militärische Nachrichtenwesen (ZMilNW) einzurichten. Mit der Systemfähigkeitsforderung Verbund Nachrichtengewinnung und Aufklärung wurde das Vorliegen einer diesbezüglichen Fähigkeitslücke im Jahr 2001 formal festgestellt. Das Heeresamt wurde beauftragt, diese in einem Anforderungskatalog zu konkretisieren und Lösungsvorschläge zu erarbeiten (IT-AmtBw & Heeresamt, 2006). Eine Analyse der in den vorherigen Abschnitten dargestellten Ansätze7 ergab, dass sich aus diesen Vorhaben im Rahmen eines Einsatzbedingten Sofortbedarfs eine umfassende DV-Unterstützung für die ZMilNW mit überschaubarem Weiterentwicklungsaufwand realisieren ließe. Daraufhin entwickelte das FKIE einen Prototypen, der – nach einigen auftragsspezifischen Erweiterungen – die vorgenannten Ansätze in einer Gesamtarchitektur zusammenfasste und die Erfassung, Auswertung und Verteilung aller Meldungsformate in einer Aufklärungszentrale ermöglichen sollte. Es entstand die DV-Unterstützung für die Zentrale MilNW (DVU ZMilNW) als generisches Drei-Schichten-Modell der Wissensverarbeitung mit umfangreichen Aggregations-, Fusions- und Analyseverfahren (Kaster, 2004b). Der Funktionsumfang ergab sich auch hier mit Schwerpunkt aus den Anforderungen, die sich im Transformationsprozess der Bundeswehr aus potentiellen Einsatzszenarien (z. B. NATO Response Forces, NRF) ableiten lassen. Eine der Kernkomponenten der modularen DVU ZMilNW ist die Datenbank Einsatz, die die Verarbeitung der vielfältigen nicht oder nur schwach strukturierten Aufklärungsmeldungen in Kombination mit spezifischen Sensordaten ermöglicht. Dieses Verfahren wurde in Abschn. 9.4.2 beschrieben. Die Erweiterung um wissensbasierte Verfahren kann in Zukunft die Leistungsfähigkeit einer Aufklärungszentrale weiter erhöhen. Wie beispielsweise zukünftig die Auswertung von Textbausteinen durch multilinguale Inhaltserschließung stärker automatisiert werden kann, beschreibt Kap. 12. Beispiele für eine intelligente Datenfilterung finden sich in Kap. 8. Das Basissystem DVU ZMilNW kam bereits in den Jahren 2002 und 2003 als Teil des Gefechtsstandskonzepts der Bundeswehr-geführten Kabul Multinational Brigade (KMNB) bei ISAF erfolgreich zum Einsatz (Kaster & Huland, 2002). Bearbeitungsfunktionalitäten und Schnittstellenoptionen wurden in den Folgejahren in nationalen und internationalen Übungen8 und Einsätzen9 kontinuierlich weiterentwickelt und ausgewertet. Im zivil-militärischen Umfeld gibt es Erfahrungen im Bereich des Katastrophenschutzes (Kaster, 2004a). Mittlerweile kann aufgrund der 7

konkret: Untersuchungen während der Übungsteilnahmen „Roter Luchs“ III und IV, die im Jahr 2001 im Auftrag des Heeresamtes durchgeführt wurden. 8 Feldstudien: CWID (Coalition Warrior Interoperability Demonstration, NATO-Übung), Roter Luchs III und IV, Klarer Kiel II, Arche 05, Leuchtturmprojekt CD&E 9 Beispiel sind: Einsätze: ISAF, SFOR, KFOR, Operation Enduring Freedom

9 Wissens- und Workflowmanagement

127

fortgeschrittenen Ausstattung der Verbände und des hohen Interoperabilitätsstandes eine Integration der DVU ZMilNW in bestehende FüInfoSys (z. B. FüInfoSys H) ohne besonderen Aufwand durchgeführt werden. Durch das Heeresamt wird auf diese Weise eine Systemverbesserung in den Gefechtsständen auf Divisions- und Brigadeebene angestrebt. Dies soll zu einer Erweiterung des Funktionsumfangs bestehender Systeme im Hinblick auf ihre erfolgskritischen G2- bzw. J2-Fähigkeiten beitragen.

9.4.5 Einzelaspekte der Führungsunterstützung Den bis hierher vorgestellten Lösungsansätzen ist gemeinsam, dass die von einem Auftraggeber geforderten Dokumente zielorientiert in einem mehrstufigen Koordinierungs- und Genehmigungsprozess entstehen und am Ende der Bearbeitungskette als „Produkte“ in einer konsolidierten Datenhaltung gespeichert werden. Während das unterlegte technische Konzept in allen Anwendungen weitgehend gleich ist, berücksichtigen die Lösungen jedoch unterschiedliche organisatorische Rahmenbedingungen und beruhen daher auf verschiedenen Prozessmodellen:  Das ETB realisiert einen konkreten Dokumentendurchlauf als Entstehungsgang von Tagebucheinträgen, bei dem Rückkopplungsschleifen zur Vermeidung von Fehlläufen eingebettet sind.  Die DBEins organisiert den Meldefluss in der gesamten Hierarchie von den Einsatztruppen bis in die Führungszentren.  In JASMIN II übernimmt die DV-AS die Ablaufsteuerung in der RFI-Abarbeitung, die Produkte werden im dortigen Dokumentenmanagementsystem gespeichert.  Die DVU ZMilNW schafft eine integrierte Arbeitsumgebung für die komplexe Auswertetätigkeit in Aufklärungszentralen. Durch systematische Archivierung der Produkte wächst jeweils eine umfassende Informationsquelle heran, die von allen zugriffsberechtigten Nutzern für ihre Recherchetätigkeiten genutzt werden kann. Die Übernahme ausgewählter Produkte in ein zentrales Informationssystem (manchmal als „Wissensdatenbank“ bezeichnet) ergänzt die bestehenden Ansätze im Sinne einer Integrationslösung. Nachfolgend werden weitere Komponenten dargestellt, die die Führungsunterstützung in einigen speziellen Gesichtspunkten fördern.

9.4.5.1 Dynamische Lagedarstellung – Sichtbarkeit von Raum, Zeit, Inhalt Ein zentraler Bestandteil der Führungsunterstützung in Operationszentralen wie z. B. der vorgenannten ZMilNW ist die Lagedarstellungskomponente, die mit Hilfe von (geo-)grafischen Projektionen von Objekten, Ereignissen und anderen lagerele-

128

J. Kaster, W.-D. Huland und S. Huy

vanten Darstellungen einen essentiellen Beitrag zu einem hohen Lagebewusstsein der Führungsebene leistet.10 Eine solche Lagedarstellungskomponente, von der vielfältige Abbildungsmöglichkeiten erwartet werden, muss mit konfigurierbaren Schnittstellen auf Basis etablierter Standards (u. a. XML, WFS, WMS, WCS; vgl. Kap. 18) ausgestattet sein (Kaster & Weber, 2006). Das AGeoBw ermöglicht beispielsweise bereits heute den Zugriff auf einen OGC-Standard-konformen GeoInfoServer, so dass die dort zur Verfügung gestellten Produkte unmittelbar für die interaktive Lagebearbeitung genutzt werden können. Weiterhin müssen Wege für eine komfortable und schnelle Anbindung an vielfältige Datenquellen sowie eine kombinierte Darstellung von lagerelevanten Fakten, Ereignissen, Meldungen usw. eröffnet werden.

9.4.5.2 Anbindung von Sensorsystemen In einem weiteren FKIE-Projekt wird eine Verbesserung der Führungsfähigkeit angestrebt, indem sensornahe Aufklärungsergebnisse aus dem Interoperabilitätsvorhaben MAJIIC (Details vgl. Kap. 19) verzugsarm als Beitrag zum Lagebild für die oberen Führungsebenen nutzbar gemacht werden. Aufgabe ist die Beschleunigung der Kollaborations- und Meldungsprozesse (Kaster & Huy, 2008). Als Bezugsrahmen dient auch hier der iterative Zyklus der NG&A, der im Krisen- und Bedrohungsfall mehrfach zeitkritisch zu durchlaufen ist, damit das gewünschte Aufklärungsergebnis erzielt wird. Die durch die MAJIIC-Komponenten gelieferten Auswerteprodukte (z. B. GMTI-Tracks) werden in der Bodenauswertestation aufbereitet und an die DVU ZMilNW übermittelt. Dort stehen sie zur Verfügung, um in den aktuellen Auswertestand integriert zu werden und in Verbindung mit anderweitig verfügbaren Intelligence-Informationen einen weiteren Nachrichtengewinnungs- bzw. Aufklärungszyklus zu initiieren.11

9.4.5.3 Portaltechnik als Integrationsplattform für Anwendungen Führungsunterstützung im Rahmen multinationaler Kommandostrukturen dient dem Ziel, das Bewusstsein der militärischen Führer über die aktuelle Lage zu schärfen und sie in ihrer Entscheidungsfindung zu unterstützen. Dieses Situationsbewusstsein ist dabei als ein „mentales Abbild“ der Einsatzlage zu sehen, das sich aus vielen Komponenten zusammensetzt. Eine wesentliche Aufgabe war es daher, ein umfassendes Führungsportal (Military Business Intelligence-Portal) mit allen einsatzrelevanten Dokumenten, Meldungen, Auswertungen und Produkten zu entwickeln und 10

Die unmittelbare Abbildung georeferenzierter Daten in einer Lagedarstellung, z. B. Einheiten repräsentiert als APP-6A-Symbolik, sollte heutzutage den Status einer „Trivialität“ haben. Wie zukünftig auch semantisch sinnvolle Lagebilder aus Datenbeständen entwickelt werden können, ist Thema in Kap. 18. 11 Ein Anwendungsbeispiel „Non-combatant Evacuation Operation“ (NEO) findet sich in (Kaster, 2008).

9 Wissens- und Workflowmanagement

129

Fachbearbeitern sowie Entscheidungsträgern in einer optimierten Form anzubieten (Kaster & Weber, 2005). Durch die kombinierte und kontextbezogene Verarbeitung von formatierten und unformatierten Daten sowie durch eine leistungsfähige Kombination von Auswertefunktionen können aus diesem Portal heraus komplexe Recherchen über den gesamten Datenbestand durchgeführt werden. Somit wurde eine weitere Stufe in Richtung des Gemeinsamen Rollenorientierten Einsatzlagebildes (GREL) erreicht (zur Definition des GREL siehe Kap. 18). Die inhaltliche Struktur des Portals folgt der Gliederung der Zentrale Militärisches Nachrichtenwesen (vgl. Abschn. 9.4.4) mit den Bereichen Aufklärung, Lage, Geowesen und Sicherheit. Der Funktionsumfang orientiert sich auch hier an den Anforderungen, die sich aus potentiellen Einsatzszenarien ergeben. Um die Integrierbarkeit in beliebige Zielsysteme und damit eine hohe Interoperabilität zu demonstrieren, wurden unabhängige Portallösungen auf Basis moderner MiddlewarePlattformen realisiert, u. a. WISE (Web Information Services Environment; NATOACT, 2005, vgl. auch Kaster, 2003), WPS (WebSphere Portal Server; IBM, 2009), abaXX-Portal (BPM-Suite; Cordys, 2009).

9.4.6 Einbettung in ein modulares Gesamtkonzept Alle in diesem Kapitel vorgestellten Verfahren dienen der rollenbasierten Verarbeitung und Verteilung von Informationen und Wissen in einem Netzverbund. Zielsetzung ist jeweils die bereichsübergreifende Interpretation und Verdichtung der im jeweiligen Anwendungsbereich anfallenden großen Informationsmengen sowie die Erzeugung eines umfassenden Lagebildes in aktuellen Bundeswehreinsätzen. Die Integration bzw. Interoperabilität derartiger unabhängiger Anwendungen unter einem einheitlichen Zugangssystem ist eine besondere Herausforderung (Kaster, 2000). Abbildung 9.4 zeigt eine Gesamtarchitektur, in der die zuvor beschriebenen Systemansätze in einem modularen Konzept zusammengefasst sind. In der jeweiligen Anwendungsumgebung können genau die Module eingesetzt werden, die den dort geltenden Anforderungsprofilen entsprechen.12 Das Bild illustriert (von unten nach oben gesehen) die Verdichtung von eingehenden Rohdaten (Sachbearbeiter-Ebene) bis zu fertigen Produkten, die der Unterstützung der Entscheidungsträger dienen. Auf der Eingabeseite ist allen Anwendungsbeispielen ein effizientes Dokumentenmanagement gemeinsam. Es enthält die jeweils benötigten Auswertefunktionen sowie eine Prozesssteuerung, die die Arbeitsabläufe kanalisiert und für den jeweiligen Nutzer (genauer: die jeweilige Nutzerrolle) einfach beherrschbar macht. Auf der Ausgabeseite finden sich Produkte wie „Wissensdatenbank“ mit Aufklärungsergebnissen (Intelligence Summaries), umfassende Lagedarstellungsfunktionalitäten 12

Erfahrungsberichte liegen u. a. vor von: HFüKdo (2001), Heeresamt (2001), DSO (2002), ITAmtBw (2004, 2005), NATO ACT (2005), USNORTHCOM (2004).

130

J. Kaster, W.-D. Huland und S. Huy

Abb. 9.4 Modulares Gesamtkonzept für die Einbettung von Anwendungen im Bereich Wissensund Workflow-Management. Anwendungsbereiche auf der Eingabe-Seite [Ebene Sachbearbeiter]: (1) Einsatztagebuch (ETB); (2) Datenbank Einsatz (DBEins); (2-6) DV-Ustg Zentrale Mil. Nachrichtenwesen (DVU ZMilNW); (7) DV-Ustg Auftragssteuerung (DV-AS); (8) LFS (Lagefeststellung); (9) Anbindung Common Shared Database (CSD aus MAJIIC). Zugangskonzepte auf der Ausgabe-Seite [Ebene Entscheidungsträger, Portal-Zugang gemäß Rollen- und Sicherheitskonzept]: (1) Wissensdatenbank mit Intelligence Summaries (INTSUM); (2) Lagedarstellung; (3) Produktdatenbank (Finished Intelligence Products, Reports etc.); (4) Lagebeiträge (LVU, LVE)

(im Sinne des bedarfsorientierten, dynamischen Lagebildes), Produktdatenbanken (Finished Intelligence Products, Reports etc.) und Lagebeiträge (LVU, LVE). Alle Komponenten sind in eine diensteorientierten Infrastruktur durch sich ergänzende Softwaremodule eingebettet, die mit anderen Komponenten nach Bedarf Daten austauschen können. Der Zugriff erfolgt über ein Portalsystem, das gemäß dem Informationsbedürfnis des jeweiligen Nutzers personalisiert werden kann. Das Konzept einer serviceorientierten Architektur (SOA) ist ein viel versprechender Ansatz für die Entwicklung verteilter Systeme, der eine Reihe von neuen Möglichkeiten für die Konsolidierung heterogener Systeme und Datenbestände bietet (MacKenzie et al., 2006). Wesentlich ist hierbei, dass die Dienste aufgrund akzeptierter Standards lose miteinander verbunden werden, miteinander kommunizieren und somit zur Unterstützung komplexer Geschäftsabläufe „choreographiert“ werden können.13 Bei der Entwicklung kann im Rahmen der Prozessanalyse der 13

Überlegungen zu einer übergeordneten Softwarearchitektur für FüInfoSys finden sich in Kap. 3. Das Management von Services in verteilten FüInfoSys wird in Kap. 4 behandelt.

9 Wissens- und Workflowmanagement

131

gesamte Arbeitsablauf von Anfang an im Auge behalten werden, während die Realisierung in kleinen Schritten mit flexibel verknüpfbaren Einzelmodulen vorgenommen wird. Da beim Design der Fokus in besonderem Maß auf die Arbeitsabläufe und die Schnittstellengestaltung der Komponenten gelegt werden kann, wird durch den SOA-Ansatz dem Interoperabilitätsgedanken verstärkt Rechnung getragen. Ein weiterer Vorteil liegt in der Gestaltung einer flexiblen Aufbau- und Ablaufstruktur, so dass die Methodik auch für die Umsetzung und Optimierung der Workflow-Modelle in diversen Anwendungsdomänen besonders geeignet scheint. Es ist zu erwarten, dass durch SOA die Erstellung qualitativ hochwertiger WorkflowAnwendungen zukünftig stark gefördert wird. Wenn diese Prognose zutrifft, werden Integrationsbemühungen unterstützt, die die Zusammenführung relevanter Daten und Dokumente aus den einzelnen Anwendungen in einer Zielarchitektur (Informationsverbund mit einer breiten „Wissensbasis“) zum Ziel haben.

9.5 Zusammenfassung Engpässe heutiger Informationsversorgung liegen nicht primär in dem Fehlen „intelligenter“ IT-Lösungen, sondern sind bereits in der unzureichend organisierten Bereitstellung benötigter Informationen bei gleichzeitiger Reizüberflutung mit irrelevanten Daten zu suchen. Umfassende konsolidierte Datenhaltung, ausgestattet mit schnellen, aufgabenangemessenen Filterverfahren, zur Verfügung gestellt an einer intuitiv und nutzerorientiert gestalteten Mensch-Maschine-Schnittstelle, das sind Funktionalitäten, die die Soldaten im Einsatz auf allen Führungsebenen am vordringlichsten benötigen. Eine Vernetzung über alle Ebenen, der Einsatz bundeswehrweit verfügbarer Standards, gezielt an der jeweiligen Aufgabe ausgerichtete Extraktions- und Aggregationsverfahren, effiziente Filtermöglichkeiten nach Themen und Relevanz, ausgestattet mit einer „einfachen“ Abbildung von Raum- und Zeitbezug in einer Lagedarstellung: diese Unterstützungsfunktionen sind mit heutigen Mitteln „im Prinzip“ ohne weiteres erreichbar. Da für militärische Einsätze spezifische Randbedingungen und Einschränkungen gelten, können prototypische Lösungsansätze für ein integriertes Wissens- und Workflowmanagement zielorientiert am besten anhand konkreter Szenarien in Feldstudien und bei operationellen Einsätzen untersucht und validiert werden. Die diesbezüglichen Arbeiten am FKIE führten zu einer Reihe von konkreten Einsatzunterstützungskonzepten, die jeweils einen eigenständigen, aufeinander abgestimmten Beitrag zu der Zielsetzung „Informationsüberlegenheit in den Führungszentralen“ leisten. Diese Verfahren bilden natürlich nicht das Ende der Entwicklungslinien. Dies werden nicht zuletzt die nachfolgenden Beiträge im Teil II dieses Buches zeigen. Die in diesem Kapitel vorgestellten Anwendungen stellen jedoch grundsätzliche Schritte zur Bewältigung heute vorhandener Problemfelder dar. Wie sagte doch Altkanzler Helmut Schmidt: „In den grundlegenden Fragen muss man naiv sein. [...] Gleichwohl glaube ich, dass man zugleich realistisch und pragmatisch sein sollte.“

132

J. Kaster, W.-D. Huland und S. Huy

Literaturverzeichnis ACT (2005). CWID 2005 NATO Final Report. NATO Allied Command Transformation, Virginia, USA. German CliCC - Special Recognition. p. 25. BMVg (2001). Teilkonzeption Aufklärung der Bundeswehr. Bonn. BMVg (2004). Konzeption der Bundeswehr. Berlin. Cordys (2009). www.abaXX.de. DSO (2002). Erfahrungsbericht: Einsatz der DVU Zelle Aufklärung bei ISAF. Division Spezielle Operationen, Leiter KMNB J2, Regensburg. Heeresamt (2001). Erfahrungsbericht: DBEins während Roter Luchs III und IV. Heeresamt I 3, Köln. HFüKdo (2001). Erfahrungsbericht: Einsatz DBEins bei KFOR und SFOR. HFüKdo G2 – Wehrlage, Koblenz. IBM (2009). www.ibm.com/websphere/portal. IT-AmtBw (2004). Erfahrungsbericht zu JWID 2004. ITAmtBw, Koblenz. IT-AmtBw (2005). Erfahrungsbericht zu CWID 2005. ITAmtBw, Koblenz. IT-AmtBw & Heeresamt (2006). Abschließende funktionale Forderung/Realisierungsgenehmigung für die Datenverarbeitungsunterstützung Zentrale Militärisches Nachrichtenwesen. Kaster, J. (2000). IntraNet Bw – Neue Chancen für einen militärischen Informationsverbund. ITReport 2000, Report-Verlag, Bonn, (pp. 53–56). Kaster, J. (2001). Einsatztagebuch FüZBw (v1.0). Technischer Bericht 2000/3, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Kaster, J. (2003). Die Datenbank Einsatz als WebService im NATO-BICES-System. Technischer Bericht 2003/2, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Kaster, J. (2004a). DV-Unterstützung und Lagebearbeitung in der OPZ der Einsatzorganisation WBK I Küste. Technischer Bericht 2004/11, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Kaster, J. (2004b). Multinational Intelligence Center – Integrated Services for Situation Assessment. Technischer Bericht 2004/4, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Kaster, J. (2006). Erfahrungen mit der DVU ZMilNW bei CWID 2006. Technischer Bericht 2008/9, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Kaster, J. (2007). Datenverarbeitung Auftragssteuerung – Konzept und Realisierung (v2.0). Technischer Bericht 2007/5, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Kaster, J. (2008). Erfahrungen mit der DVU Zentrale MilNW bei CWID 2008. Forschungsinstitut für Kommunikation, Informationsverarbeitung und Ergonomie (FKIE). Kaster, J. & Huland, W.-D. (2002). DV-Unterstützung Zelle Aufklärung bei KMNB ISAF – Systemkonzept. Technischer Bericht 2002/6, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Kaster, J., Huland, W.-D., & Huy, S. (2003). Dokumentenverwaltung in der G2-Datenbank Einsatz (v2.0). Abschlussbericht der Studie „DBEins“(IT-Amt Bw) 2003/4, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Kaster, J. & Huy, S. (2008). Integration von Simulationskomponenten MAJIIC in die DVUUnterstützung für das Militärische Nachrichtenwesen. Technischer Bericht 2008/3, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Kaster, J. & Kaster, A. (2000). Componentware Approaches in Management Information. In N. RTO/RTA (Ed.), Proceedings of the NATO RTO Symposium HFM-049/SY-005: Usability of Information in Battle Management Operations Wachtberg. Kaster, J. & Weber, C. J. (2005). Entwicklung von Führungsportalen mit dem NATO-Toolset WISE v1.0. Technischer Bericht 2005/5, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg.

9 Wissens- und Workflowmanagement

133

Kaster, J. & Weber, C. J. (2006). Interaktive Lagebearbeitung: Handbuch xIRIS. Nutzeranleitung und Schnittstellenbeschreibungen. Technischer Bericht 2006/5, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. MacKenzie, C. M., Laskey, K., McCabe, F., Brown, P., & Metz, R. (2006). Reference Model for Service Oriented Architecture 1.0. OASIS. NATO-ACT (2005). NATO C3 Technical Architecture (NC3TA), V5: NC3 Common Operating Environment (NCOE) v7.0, A2: NCOE Basket of Products - Infrastructure Services. NATOACT User Support Branch. Tochtermann, K. (2006). Der Service-basierte Knowledge Desktop. Wissensmanagement, 6, 34–36. USNORTHCOM (2004). Joint Warrior Interoperability Demonstration 2004 Final Report: German Multinational Intelligence Center (MNIC). https://www.cwid.js.mil/public/cwid05fr/htmlfiles/ c216intr.html.

Kapitel 10

Auftragsmanagement Jürgen Kaster und Daniel Schaefer

„Wir denken selten an das, was wir haben, aber immer an das, was uns fehlt.“ Arthur Schopenhauer

10.1 Einleitung Militärische Führungsinformationssysteme sollen ein systematisches, zielorientiertes Zusammenwirken aller Funktionsträger ermöglichen und ihnen nach Bedarf die benötigten Informationen zeit- und sachgerecht zur Verfügung stellen. Effiziente Zugriffsverfahren zu den Datenquellen müssen hierzu die eigenständige Recherche nach vielfältigen Daten im gesamten Informationsraum unterstützen. Darüber hinaus werden jedoch weitergehende Rechercheverfahren benötigt, die die Möglichkeiten der einzelnen Nutzer ausweiten. Dazu gehören Informationsersuchen, die ein Bearbeiter an das Führungsinformationssystem richtet, um über diesen Weg benötigte Informationen von anderen Experten zu erfragen. Damit ein als Anfrage formuliertes Problem eines Bedarfsträgers in einem Informationsverbund den richtigen Ansprechpartner findet, ist ein rechnergestütztes Auftragsmanagementsystem ein unverzichtbares Hilfsmittel. Solch ein System kann Benutzeranfragen (engl.: Request for Information; RFI) entgegennehmen, verwalten und zielgerichtet an die entsprechenden Experten weiterleiten. Auf der Basis der gelieferten Ergebnisse kann der Auftraggeber Informationslücken schließen, die anderweitig zu einer Beeinträchtigung seiner Entscheidungsfähigkeit führen. Auftragsmanagement wird in diesem Beitrag als ein zyklisch zu durchlaufender Arbeitsprozess verstanden, der sich an den Prinzipien des Lean-Ansatzes orientiert, mit dem eine Verschlankung von Prozessen angestrebt wird (vgl. Abschn. 10.4). Die Bearbeitung eines Auftrags erfolgt nach dem Teile-und-herrsche-Prinzip, also durch Aufsplittung eines Problems in mehrere Teilprobleme, die jeweils unabhängig bearbeitet werden und nach Aggregation zum Gesamtergebnis beitragen.

M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

135

136

J. Kaster und D. Schaefer

Weiterhin wird erläutert, dass die Auftragsabwicklung statusgetrieben anhand eines dedizierten Prozessmodells und eines im Anwendungsbereich zu definierenden Rollenkonzeptes erfolgt. Die Autoren zeigen, wie durch Verschachteln von wiederkehrenden Prozessschleifen komplexe Ergebnisse mit im Grunde einfachen, generischen Vorgehensweisen erarbeitet werden können. Anschließend werden die Hauptanwendungsfälle beschrieben, die der Bearbeitung eines zentralen Geschäftsobjektes – des RFI-Templates – dienen. Der Beitrag schließt mit einer Betrachtung der Auswirkungen des vorgestellten Ansatzes auf Interoperabilitätsbemühungen, die im militärischen Bereich nicht zuletzt aufgrund der multinationalen Einsatzumgebungen eine besondere Bedeutung haben.

10.2 Aufgabenstellung „Ein Problem ist halb gelöst, wenn es klar formuliert ist.“ So banal diese Behauptung des amerikanischen Philosophen und Pädagogen John Dewey (1859–1952) klingen mag, so bedeutsam ist sie. Wie schnell passiert es, dass Lösungswege eingeschlagen werden, die vollkommen in die Irre führen, weil sie gar nicht zu der Problemstellung passen? Schließlich kann bereits die Beschreibung eines Problems eine Herausforderung für sich sein. Und dann, wenn das Problem formuliert ist, wie findet man dann denjenigen, der es tatsächlich lösen kann? Diese Frage stellt sich gerade im militärischen Umfeld mit seinen komplexen Strukturen und Systemen, die ein Geflecht von verschiedenen Ressourcen, Zuständigkeiten, Kompetenzen und Verpflichtungen bilden. Oft wissen die Auftraggeber eines Informationsersuchens nicht, ob und wo die von ihnen benötigten Informationen vorliegen. Die Bedeutung dieser Problematik zeigt sich in den aktuellen Bundeswehreinsätzen, in denen die zeitnahe Informationsversorgung aller Entscheidungsträger eine hohe Kritikalität für den erfolgreichen Einsatz der Streitkräfte hat.1 An der Bearbeitung von Informationsersuchen sind zumeist unterschiedliche Dienststellen oder Fachbereiche beteiligt. Auch das angefragte Ergebnis (im Folgenden auch als „Produkt“ bezeichnet) kann sehr unterschiedlicher Natur sein: Aufträge können konkrete Einzelthemen betreffen oder komplexe Analysen bedingen; Antworten können bereits irgendwo vorliegen oder müssen erst erarbeitet werden; Nachfragen können einmalig notwendig sein oder ereignisbezogen bzw. periodisch anfallen. Die sich hieraus ergebenden, vielfältigen Variationen der Koordination und Kontrolle von Informationsflüssen beherrschbar zu machen ist die Aufgabe eines Auftragsmanagementsystems (Gizanis, 2006; Rohweder, 1996; Schreiner, 2004). Es entspricht einer der jeweiligen Systemumgebung angepassten Workflowkoordination, die den zeit- und sachgerechten Informations- und Arbeitsfluss zur Behandlung von Informationsersuchen gemäß geeigneter Rollenkonzepte ermöglicht (Deutschle, 1995; Frese & Noetel, 1992). 1

Unter „Kritikalität“ wird im V-Modell XT (IT-Rat, 2008) die Bedeutung verstanden, die dem Fehlverhalten eines Systems oder einer anderen Betrachtungseinheit beigemessen wird. Fehlverhalten von Funktionen mit „hoher Kritikalität“ können zum Verlust von Menschenleben führen.

10 Auftragsmanagement

137

10.3 Auftragsmanagement als zyklischer Prozess Militärische Fachbearbeiter und Entscheidungsträger sind stetig mit neuen Aufgaben konfrontiert, die ein zielgerichtetes und schnelles, aber überlegtes Handeln erfordern. Die eigenen Aktivitäten müssen dabei auf einer soliden, durch hinreichende Informationen abgesicherten Grundlage erfolgen. Die operationellen Ziele bestimmen den Informationsbedarf, der als notwendiger Beitrag zur Entscheidungsfindung gedeckt werden muss. Der Bearbeiter wird zunächst auf den ihm zugänglichen Bestand an Informationen zurückgreifen. Besteht nach der individuellen Recherche auch weiterhin eine Informationslücke, die nicht mit eigenen Mitteln und Fähigkeiten geschlossen werden konnte, ist der Rückgriff auf weitere Kräfte und Mittel notwendig. Von diesen sind ergänzende Informationen und Analysen als Produkte zu erarbeiten und zu liefern. Dieses neu generierte Wissen wird an den Auftraggeber übermittelt, der auf der nun erweiterten Grundlage entsprechende Entscheidungen treffen oder weiteren Informationsbedarf ableiten kann. Für einen Fachbearbeiter bietet ein mit einem Auftragsmanagement ausgestattetes System somit eine Anlaufstelle für Anfragen und einen konsolidierten Zugangskanal zu den benötigten Informationen, an dessen Schnittstelle die Ergebnisse verschiedener Leistungserbringer gebündelt und als kompaktes Produkt bereitgestellt werden (Vujasinovic, 2008). Der beschriebene Verarbeitungsgang im Aufklärungszyklus, der in Abb. 10.1 in seinen vier grundsätzlichen Phasen skizziert ist, orientiert sich an der jeweiligen Aufgabenstellung des Bedarfsträgers und wird in der Regel zyklisch durchlaufen. Während die Ableitung von Entscheidungen den handelnden Personen vorbehalten bleiben muss, kann der Prozess der Sammlung, Verarbeitung und Verteilung von Informationen durch ein Auftragsmanagementsystem technisch unterstützt werden. Der Grundgedanke eines solchen Systems ist die auftragsgebundene Informationsversorgung, d. h., ein Bedarfsträger formuliert einen Auftrag, mit dem er seinen Informationsbedarf konkretisiert. Die Aufgabe eines Auftragsmanagementsystems ist es, den Arbeitsprozess zu koordinieren, die einzelnen Arbeitsschritte zu überwachen, den zeitlichen Verlauf transparent zu machen und – falls zutreffend – früh-

Entscheiden

Verteilen

EINSATZ

Auswerten Abb. 10.1 Die vier Phasen des Aufklärungszyklus

Sammeln

138

J. Kaster und D. Schaefer

zeitig zeitkritische Bearbeitungsvorgänge zu identifizieren. Von Bedeutung ist dabei, dass durch den Einsatz des Systems vorwiegend Routineschritte automatisiert werden, der Bearbeiter in seiner selbstständigen Arbeit jedoch nicht eingeschränkt werden darf. Neben der Auftragsdefinition, -erstellung und -priorisierung werden ebenso die Zuordnung von Aufgaben und die Koordination der Ergebnisbereitstellung vom Auftragsmanagementsystem unterstützt. Die Koordination verschiedener Leistungserbringer als Zuarbeiter zur Erfüllung eines Informationsersuchens ermöglicht eine kooperative Auftragsabwicklung, bei der eine durchgängige Zusammenarbeit interner und externer Geschäftseinheiten und Personen zentral koordiniert und überwacht werden kann. Eine parallele Ausführung verschiedener ineinander geschachtelter Zyklen sollte möglich sein. Dadurch können bereits weitere Informationsersuchen initiiert und bearbeitet werden, während die Auswertung zuvor gesammelter Informationen noch läuft. Mit dieser Verschachtelung wird die Bearbeitung auch hoch komplexer Vorgänge möglich, allerdings steigt der Aufwand für die Synchronisation der einzelnen Bearbeitungsschritte (Küttelwesch et al., 2003).

10.4 Operationelles Konzept Die Basis für eine koordinierte Abarbeitung bildet ein definierter Arbeitsablauf, in dem die Arbeitsteilung durch ein Rollen- und Rechtekonzept geregelt ist. Das nachfolgend vorgestellte Konzept einer bedarfsorientierten, auftragsgebundenen Informationsgewinnung nimmt Bezug auf den Lean-Ansatz (Womack et al., 1991), der eine Verschlankung von Prozessen anstrebt und eine „Just-In-Time“-Lieferung nach Bedarf vorsieht. Damit kann eine termingerechte Lieferung von Ergebnissen bei gleichzeitiger Optimierung des Einsatzes von technischen und personellen Ressourcen erfolgen. Die Wertschöpfungskette wird derart organisiert, dass nur die notwendigen Prozessschritte verbleiben, die tatsächlich einen Wert für den Bedarfsträger generieren. Die zu liefernden Produkte entstehen zweckorientiert in einem mehrstufigen Herstellungs- und Genehmigungsprozess, in dem ein federführender Verantwortlicher das Ergebnis unter Einbeziehung von weiteren Zuarbeitern entwickelt (Kaster, 2007). Hierzu fließt zum einen sein eigenes und das ihm direkt zur Verfügung stehende Wissen in das Produkt ein, zum anderen kann er auf die Expertise von weiteren Kräften zurückgreifen, wenn Informationen fehlen. Die Bearbeitung eines Auftrags erfolgt nach dem Teile-und-herrsche-Prinzip (engl.: Divide-and-Conquer), also durch Aufsplittung eines Problems in mehrere Teilprobleme, die jeweils unabhängig voneinander bearbeitet werden und nach Aggregation zum Gesamtergebnis beitragen. Dies kann durch einen zentralistischen Ansatz realisiert werden, bei dem ein Anwender in direktem Kontakt mit weiteren Bearbeitern steht, um Teilergebnisse von diesen anzufordern (vgl. Abb. 10.2, links). Aus allen gelieferten Bestandteilen wird an zentraler Stelle eine Gesamtlösung zusammengesetzt. Effizienter ist die Bearbeitung in einem mehrstufigen, hierarchischen Prozess, in dem Teilinformationen auf Zwischenstufen aggregiert werden, bevor sie dem fe-

10 Auftragsmanagement

139

Abb. 10.2 Zentralisierte versus hierarchische Bearbeitung (nach Frackenpohl, 2002)

derführenden Bearbeiter übergeben werden (vgl. Abb. 10.2, rechts). Diese Konstellation ergibt sich beispielsweise, wenn auf Grund der Komplexität eines Teilproblems von einem Zuarbeiter eine weitergehende Aufsplittung vorgenommen wird. Die mehrfache Delegation von Zuständigkeiten führt dann zu einer Arbeitserleichterung für den Gesamtverantwortlichen, da dieser sich auf die Aggregation der Teillösungen konzentrieren kann.

10.5 Der Prozess der Auftragsabwicklung Der Prozess der Auftragsabwicklung ist gekennzeichnet durch einen bidirektionalen Strom von Aufträgen und Produkten. Der Auftragsstrom fließt von den Auftraggebern („Bedarfsträgern“) zu den Bearbeitern („Bedarfsdeckern“) und erfährt in jedem Arbeitsschritt eine „Auftragsveredelung“ in Form einer Anreicherung um weitere Attribute und Kommentare sowie einer fortschreitenden Kategorisierung und Verschlagwortung. In entgegengesetzter Richtung erfolgt ein Produktstrom von den Bearbeitern zu den Auftraggebern. Auch diese Produkte erfahren eine „Veredelung“, da auf jeder Verarbeitungsstufe die Teilergebnisse der jeweiligen Unteraufträge aggregiert werden und somit höherwertige Dokumente entstehen. Die Koordination der beiden Informationsflüsse, der rollenbasierte, statusabhängige Zugriff auf Aufträge und Produkte und die Überwachung zeitlicher Bearbeitungsrichtlinien erfolgen durch das Auftragsmanagementsystem. Dem Prozess liegt ein definiertes Prozessmodell (Workflow) zu Grunde, das dafür sorgt, dass eine eindeutige Bearbeitungsreihenfolge eingehalten und auf Nutzeraktionen entsprechend reagiert wird. Ein typischer Ablauf ist in Abb. 10.3 skizziert. Der Prozess startet auf Anfrage eines Bedarfsträgers (BT) mit einem neuen

140

J. Kaster und D. Schaefer

BT

AM

[Bedarfsträger]

FB

BD

[Auftragmanager] [Fachbereichs-Leiter] [Bedarfsdecker]

Auftrag Auftrag Auftrag

Produkt erzeugen

Überwachung Produkt

Freigabe Produkt

Produkt

DB

Abb. 10.3 Workflow und Rollenkonzept zur Bearbeitung eines RFI

Auftrag, der automatisch zur Steuerungs- und Kontrollinstanz des Systems (Auftragsmanager, AM) geleitet wird. Nach einer Eingangsprüfung wird der Auftrag einem zuständigen Fachbereich (FB) zugeleitet. Innerhalb eines Fachbereichs erfolgt eine Zuteilung an einen freien, kompetenten Bedarfsdecker (BD), der für die termingerechte Bearbeitung die Verantwortung übernimmt. Der Bedarfsdecker erstellt ein dem Auftrag entsprechendes Produkt, welches (evtl. nach gesonderter Freigabe) an den Auftraggeber übergeben wird. Die Abfolge der Prozessschritte wird mit Hilfe des Status-Attributs des Auftrags gesteuert. Bei Erreichen eines definierten Endzustandes ist der Prozess beendet. Die effektive Anzahl an Zuständen entspricht der in der jeweiligen Anwendungsdomäne definierten Anzahl von Zuständigkeiten und Bearbeitungsschritten. Das Prozessmodell kann dementsprechend konfiguriert werden. Im Zuge der Auftragsverarbeitung erfolgt nicht immer nur eine Weiterleitung von Aufträgen innerhalb einer Organisationshierarchie an zuständige Fachbereiche und Bedarfsdecker. Unter Umständen ist eine Einbeziehung von externen Ressourcen notwendig, wodurch der eigene Organisations- und Zuständigkeitsbereich verlassen wird. Bei Involvierung von Ressourcen aus anderen Organisationsbereichen erfolgt keine Weiterleitung des bestehenden Auftrags, vielmehr wird ein eigener Unterauftrag erstellt. Es ergibt sich ein rekursiv geschachtelter Workflow, die Vorgänge werden dadurch entkoppelt. Unteraufträge stellen in sich abgeschlossene Bearbeitungsgänge dar, die einen Teilaspekt des Oberauftrags abdecken. Sie können als eigenständige Vorgänge behandelt werden, für deren Bearbeitung der gleiche Ablauf gilt wie für den Hauptauftrag. Es ist lediglich eine entsprechende zeitliche und inhaltliche Synchronisation und Koordination vorzusehen. Diese Konzeption reduziert die Komplexität des Workflows und erlaubt dennoch eine beliebige Verschachtelungstiefe. Eine explizite Anpassung des Prozessschemas für jede Anwendungsdomäne

10 Auftragsmanagement

141

entfällt. Ein weiterer Vorteil besteht darin, dass ein Teilergebnis für sich genommen auch zu anderen Aufträgen ein Ergebnis beisteuern kann. Die generische Gestaltung des Prozessmodells ist von spezifischen militärischen Randbedingungen weitgehend unabhängig und erlaubt eine einfache Übertragung auf unterschiedliche Anwendungsdomänen.

10.6 Nutzerrollen Im Lebenszyklus eines Auftrags von der Erstellung bis zur Lieferung eines Arbeitsergebnisses werden verschiedene Nutzer aktiv, die mit dem System interagieren und gemäß ihren Aufgaben an einem Produkt arbeiten. Abhängig von ihrer Zuständigkeit und ihren Aufgaben werden allen Nutzern Rollen zugeordnet, durch die die Zuteilung von Aufgaben und ein über Rechte gesteuerter Zugriff auf Dokumente ermöglicht werden können. Im Wesentlichen kann die Zahl der beteiligten Rollen auf drei „Protagonisten“ beschränkt bleiben:  die Rolle des Bedarfsträgers (Auftraggeber),  die Rolle des Bedarfsdeckers (Bearbeiter) und  eine Kontrollinstanz (Auftragsmanager). Um die organisatorischen Gegebenheiten (z. B. Befehlshierarchie) innerhalb von Organisationen abbilden zu können, kann es notwendig sein, dass zwischen Auftragsmanager und Bearbeiter eine Instanz zwischengeschaltet wird, die einen Fachbereichsleiter repräsentiert, der die Bearbeiter in seinem Zuständigkeitsbereich „verpflichten“ kann. Das idealtypische Zusammenspiel der erwähnten Nutzerrollen wird nachfolgend skizziert. Hierbei werden auch die Situationen dargestellt, die im Fehlerfall oder bei sonstigen Abweichungen vom Idealfall durchlaufen werden. Erstellt ein Anwender aufgrund eines Informationsdefizits eine Anfrage, so wird er zum Bedarfsträger (BT) dieses Auftrags. Der Auftrag wird mittels der Eingangsbearbeitung des Auftragsmanagementsystems erfasst und an einen Auftragsmanager (AM) geleitet, der den Auftrag an den zuständigen Fachbereich (FB) weiterleitet. Der Fachbereichsleiter bzw. ein beauftragter Vertreter hat die Aufgabe, eine Ressourcenkoordination in seinem Verantwortungsbereich vorzunehmen. Im Falle eines Engpasses muss er abwägen, ob eine Bearbeitung der Anfrage zeitgerecht möglich ist oder ob der Auftrag mit entsprechender Begründung abgelehnt werden muss. Für seine Bewertung spielen Parameter wie Dringlichkeit und Fertigstellungstermin eine wesentliche Rolle. So kann eine priorisierte Bearbeitung notwendig werden, indem andere, bereits laufende Aufträge zurückgestellt werden. Bei Annahme eines Auftrags wird dieser an einen Kreis von Experten weitergeleitet, die sich unter der Rolle Bedarfsdecker (BD) zusammenfassen lassen. Diese Rolle sollte eine Gruppe von Bearbeitern repräsentieren und nicht etwa eine einzelne Person, damit in Abwesenheitsfällen eine Bearbeitung eingehender Aufträge auch ohne explizite Vertreterregelung garantiert bleibt. Der in diesem Sinne definierte

142

J. Kaster und D. Schaefer

Bedarfsdecker ist für die Erfüllung des Auftrags zuständig. Er muss ihn aus seiner Fachexpertise heraus auf Plausibilität und Machbarkeit prüfen, kann aber eine Annahme auch (begründet) ablehnen. Im Normalfall jedoch bearbeitet er den Auftrag mit den ihm zur Verfügung stehenden Mitteln. Dazu ist es – wie bereits dargestellt – mitunter nötig, dass er seinerseits einen (Teil-)Auftrag formuliert und für diesen Anteil somit zum Bedarfsträger in einem neuen Bearbeitungszyklus wird. Mit dieser Möglichkeit der Verschachtelung von Aufträgen wird die Rolle eines „Zuarbeiters für Teilaufträge“ obsolet. Damit eine Synchronisation sich ergänzender Vorgänge möglich wird, muss die Beziehung des in Abhängigkeit vom Hauptauftrag erstellten Folgeauftrags protokolliert werden. Als Ergebnis des Arbeitsprozesses wird ein Produkt erstellt, welches entweder die benötigten Informationen beinhaltet oder aber eine negative Rückmeldung, dass keine Ergebnisse erarbeitet werden konnten.

10.7 Anwendungsfälle 10.7.1 Auftragserteilung Mit der Auftragserteilung formuliert ein Nutzer eine Anfrage, die an das Auftragsmanagementsystem geleitet wird. Solche Anfragen können von konkreten Fragen (z. B. nach Objekten, Personen, Orten oder Ereignissen) bis hin zu allgemein gehaltenen Themenstellungen reichen, die einen gewissen Interpretationsfreiraum zulassen. Ein System zur Aufnahme und Verwaltung von Informationsersuchen muss daher entsprechend den jeweiligen Anforderungen angepasste Schnittstellen bereitstellen, über die ein Auftrag formuliert werden kann. Dies können z. B. formularbasierte Web-Seiten sein, auf denen ein Auftrag direkt ins System eingegeben wird. Je nach Kommunikationserfordernissen ist auch das Versenden von formatierten Aufträgen als Anhang an eine Email denkbar. In einem solchen Fall sollte das Auftragsmanagementsystem über entsprechende Importmechanismen die Aufnahme des Neuauftrags automatisieren.

10.7.2 Auftragsbearbeitung Für die Auftragsbearbeitung sind Bedarfsdecker zuständig, die im Vergleich zum Auftraggeber über weitergehende Fachexpertisen, Informationsquellen oder Beschaffungsmittel verfügen. Sind die angefragten Informationen nicht verfügbar, so muss die resultierende Informationslücke ermittelt und konkretisiert werden. Dies definiert den Bedarf an Informationen, die zur Erfüllung des Auftrags neu generiert werden müssen. Hierfür kann es notwendig sein, dass der Bedarfsdecker seinerseits Informationsersuchen verschickt, diesmal jedoch gezielt an spezialisierte Bearbeiter, die mittels vorhandener Fähigkeiten, Verfahren und Sensorik die benötigten Informationen beschaffen können. Die Wahl dieser Bearbeiter erfolgt abhängig von

10 Auftragsmanagement

143

Auftrag, Dringlichkeit und verfügbaren Kapazitäten, da der Einsatz von Experten und Spezialtechnik einen hohen Aufwand und Kostenfaktor darstellt. Das Auftragsmanagementsystem unterstützt die zielgerichtete Abarbeitung von Informationsersuchen von zentraler Stelle aus. Es ist für die korrekte Weiterleitung des neuen Auftrags an die Bedarfsdecker zuständig, es bietet integrierte Suchfunktionen, ermöglicht die Generierung von Unteraufträgen zu vorhandenen Anfragen und bietet Hilfen für die Auswahl von geeignetem Fachpersonal. Dies geschieht z. B. mit Hilfe einer Ressourcendatenbank, die dem Auftragsmanager mit Hilfe gewichteter Faktoren geeignete und zur Verfügung stehende Kräfte und Mittel vorschlägt. Das Auftragsmanagementsystem koordiniert darüber hinaus die Abarbeitung der verschiedenen Aufträge und Unteraufträge, hilft, zur Ressourcenschonung Aufträge zu vergleichen, zeitlich abzustimmen oder zu aggregieren, und reagiert auf die Fertigstellung eines Auftrags gemäß des definierten Workflows.

10.7.3 Auftragsmanagement Da nicht alle Anwendungsfälle aufgrund von Mehrdeutigkeiten, Unschärfen etc. automatisch abgearbeitet werden können, ist im Regelfall ein Auftragsmanager notwendig, der erweiterte Koordinierungs- und Auswerteaufgaben übernimmt. Zu seinen Aufgaben gehört es vordringlich, Status und Terminvorgaben aller Aufträge einzusehen und softwareunterstützt Auswertungen und Kontrollen durchzuführen. Er überwacht und koordiniert somit die Auftragslisten und Arbeitsabläufe und sorgt für eine Qualitätssicherung der Produkte. Bei Störungen im Ablauf muss er entsprechend den vorgegebenen Regeln intervenieren. Für die Ermittlung eines geeigneten Bedarfsdeckers steht ihm idealerweise eine Ressourcendatenbank mit einer Liste von Experten und deren Fähigkeitsprofilen zur Verfügung („Gelbe Seiten“). Sofern er einen Bedarfdecker nicht unmittelbar beauftragen kann oder darf, schaltet er einen Fachbereichsleiter ein, der den Auftrag einem geeigneten Bearbeiter zuweist.

10.7.4 Produkterstellung und Lieferung Das Ergebnis der Arbeit eines Bedarfsdeckers sind ein oder mehrere Dokumente („Produkte“), welche im Idealfall das Informationsbedürfnis des Bedarfsträgers decken. Dieses Produkt stellt eine Aggregation aller gesammelten Informationen dar. Es ist somit als ein höherwertiges Ergebnis anzusehen als die Summe der Einzelelemente. Die Rücklieferung des Produktes an den Bedarfsträger kann durch verschiedene Mechanismen realisiert werden. Eine gängige Methode ist das Versenden per Email; alternativ kann ein Verweis auf einen Datenbankeintrag oder eine andere Quelle übermittelt werden, der den Zugang zu den gewünschten Informationen ermöglicht. Unabhängig von der Wahl der Zustellung müssen Versand und Empfang protokolliert werden, damit der Dokumentenfluss jederzeit nachvollzogen und belegt werden kann.

144

J. Kaster und D. Schaefer

In manchen Anwendungsdomänen ist vor der Auslieferung eine Freigabe durch die nächsthöhere Instanz notwendig. Das Auftragsmanagement muss in diesem Fall einen Genehmigungsprozess beinhalten, der entweder durch systeminterne Komponenten oder durch organisatorische Maßnahmen realisiert wird. Durch konsequente Dokumentation und Archivierung der erstellten Produkte wächst mit der Produktdatenbank eine umfassende Wissensquelle, die von allen zugangsberechtigten Bearbeitern für ihre Recherchetätigkeiten genutzt werden kann und somit zur Vermeidung von redundanten Beauftragungen zum gleichen Thema beiträgt.

10.8 Struktur eines Informationsersuchens Bearbeitungsgegenstand von Aufträgen sind Informationsersuchen, die von berechtigten Bedarfsträgern beauftragt werden. Dienstrechtlich handelt es sich bei diesen Anfragen im Allgemeinen um verbindliche Weisungen, wobei den Bearbeitern die Wahl der Mittel und die Art der Durchführung freigestellt ist (Vujasinovic, 2008). Zur Unterstützung der weisungsgerechten Ausführung werden die Aufträge systemtechnisch verarbeitet und gespeichert. Damit dies weitgehend automatisiert erfolgen kann, müssen Struktur und Syntax von Aufträgen einem vordefinierten Schema entsprechen. Ein international unter Streitkräften anerkanntes Schema ist das von der NATO standardisierte Austauschformat für Aufträge mit der Bezeichnung „STANAG 2149: Request for Information“ (NATO, 2003). Die Nutzung dieses Formats garantiert eine hohe Kompatibilität und Interoperabilität mit Auftragsmanagementsystemen der NATO und ihrer Partner. Die typische Struktur eines Informationsersuchens wird nachfolgend am Beispiel dieses NATO-Standards beschrieben. STANAG 2149 macht sowohl hinsichtlich der Bearbeitung als auch des Aufbaus eines RFI konkrete Vorgaben (NATO, 2006). Zur Identifikation muss jeder Auftrag eine eigene Identifikationsnummer besitzen. Bevor er verschickt werden kann, muss er in vielen Fällen von einer autorisierten Person gegengeprüft werden. Die Prüfung soll z. B. sicherstellen, dass die erfragte Information nicht schon anderweitig vorhanden ist und dass der Auftrag relevant für die Erfüllung der Aufgaben des Auftragsstellers ist. Nur zulässige Aufträge werden weitergeleitet. Dieses Vorgehen ist allerdings nicht immer verpflichtend und kann daher in einer Anwendungsdomäne auch entfallen. Zum Zwecke der Vereinfachung ist dieser Prüfschritt im vorliegenden Geschäftsprozessmodell (vgl. Abb. 10.3) nicht explizit aufgeführt. Ein RFI unterteilt sich gemäß STANAG 2149 in elf Abschnitte, die sowohl zwingend erforderliche als auch optionale Attribute enthalten. Abbildung 10.4 zeigt einen Ausschnitt aus einer standardkonformen RFI-Vorlage. Der erste Abschnitt umfasst die wichtigsten Attribute zur Adressierung eines RFI und muss vollständig ausgefüllt werden. Neben dem Absender („originator“) und einer Liste von adressierten Bearbeitern („for action“) können optional weitere Produktempfänger angegeben werden, für die das Thema ebenfalls interessant sein könnte („for information“). Weitere Attribute sind ein Betreff („subject“), Erfassungszeitpunkt („time recorded“) sowie die Kennung des Prüfers („validated by“).

10 Auftragsmanagement

145

Abb. 10.4 RFI-Formular nach STANAG 2149 (Auszug)

Abschnitt zwei enthält Angaben für die Verwaltung und Prozesssteuerung. Hier werden der Status des Auftrags („status“ mit den Werten „in action“, „stopped“ und „completed“) und die Priorität („priority“ mit den Ausprägungen „routine“, „priority“, „immediate“ und „flash“) mitgeführt. Der dritte Abschnitt ist optional und für Objektkoordinaten („coordinates“) und Lageangaben („location“) vorgesehen. Der vierte Abschnitt („information required“) ist letztendlich für die Formulierung der Anfragen reserviert. Es sollen laut STANAG nicht mehr als sechs Einzelfragen gestellt werden, ansonsten ist eine Aufteilung in mehrere RFIs vorzusehen. Die nicht im Bild gezeigten Abschnitte enthalten folgende Angaben:  zeitliche Rahmenbedingungen der Informationsbeschaffung zur Festlegung von Sammelzeitraum und Wiederholungsraten,  Randbedingungen bezüglich der geografischen Zuordnung von Objektdaten,  Begründung der Anfrage,

146

J. Kaster und D. Schaefer

 Angabe, welche Quellen bereits konsultiert wurden,  Festlegung von Rückgabeart, Produkttyp und VS-Einstufung.

10.9 Interoperabilität im multinationalen Informationsverbund In den vorherigen Abschnitten wurde erläutert, dass Teil- bzw. Unteraufträge je nach Komplexität auch dienststellenübergreifend bearbeitet werden müssen. Dies bedeutet, dass Aufträge aus einem bestehenden Auftragsmanagementsystem an externe Systeme weiterzuleiten sind, sofern die angesprochenen Einheiten über ein eigenständiges System verfügen. Die Offline-Übergabe von Auftrags- und Produktdaten würde dem Verbundgedanken widersprechen und eine Reihe von Übertragungsproblemen (Zeitverzug, Fehleranfälligkeit) hervorrufen. Aus diesem Grund müssen für ein durchgängiges Auftragsmanagementsystem Schnittstellen definiert werden, über die eine direkte Kommunikation und Interaktion mit externen Systemen möglich ist. Je nach Implementierung kann es sich hierbei um direkte Zugänge über eine Programmierschnittstelle (API) handeln oder um netzwerkweit angebotene „Dienste“, die Daten bereitstellen oder annehmen. Letztere Methode gewinnt im Zusammenhang mit der Entwicklung von Systemen, die auf serviceorientierten Architekturen beruhen, stetig an Bedeutung. Durch den Einsatz offener Standards können verschiedene Dienststellen in einem durchgängigen Workflow interagieren und kollaborieren. Die Nutzung von gemeinsamen Protokollen und standardisierten Konzepten zur Realisierung einer Servicearchitektur (vgl. DGIWG, 2006) ist auch im Hinblick auf die zunehmende Rolle der Bundeswehr in multinationalen Einsätzen von Bedeutung, um einen Daten-, Auftrags- und Produktaustausch zwischen verschiedenen Nationen zu erleichtern.

10.10 Zusammenfassung In Zeiten asynchroner Bedrohungslagen wird eine breite Informationsversorgung als erfolgbringender Einsatzfaktor immer wichtiger. Da eine allumfassende Informationsgewinnung nicht möglich ist, sollten Führungs- und andere Kommunikationssysteme mit einem Auftragsmanagement ausgestattet sein, durch das operationsbezogen und auftragsgebunden Informationsersuchen erstellt und bearbeitet werden können. Zu den Kernaufgaben eines solchen Systems gehört es, vielfältige Ressourcen miteinander zu verbinden. Diese können sowohl technischer als auch personeller Natur sein. Auftragsmanagementsysteme koordinieren und steuern workflowbasiert den mehrstufigen Prozess der Informationssammlung, Informationsanreicherung und Wissensgenerierung. Durch eine optimierte Prozesskette und eine Straffung der Informationswege leisten sie einen wichtigen Beitrag zu einer termingerechten Lieferung, einer Reduzierung der Aufwände sowie einer Dokumentation

10 Auftragsmanagement

147

der Bearbeitungsschritte. Durch den Verbleib produzierter Wissensdokumente in einer Datenbank wird zudem ein Wissensfundus für Recherchen aufgebaut, auf den zugangsberechtigte Entscheidungsträger jederzeit zugreifen können. Der vorliegende Beitrag beschreibt das Konzept eines erweiterbaren, flexiblen Auftragsmanagementsystems, welches die Bearbeitung von Aufträgen unter Einbeziehung vorhandener Ressourcen koordiniert und die rollenbasierte Verarbeitung und Verteilung von Informationen und Wissen unterstützt. Die generische Struktur des Prozessmodells erlaubt eine einfache Übertragung auf unterschiedliche Anwendungsdomänen. Eine derartige Anwendung leistet in einem Informationsverbund einen wichtigen Beitrag zur Wissenserweiterung und Entscheidungsunterstützung. Jetzt muss der Fragesteller nur noch den eingangs zitierten Grundsatz von John Dewey beherzigen: „Ein Problem ist halb gelöst, wenn es klar formuliert ist!“

Literaturverzeichnis Deutschle, U. (1995). Prozessorientierte Organisation der Auftragsabwicklung in mittelständischen Unternehmen. Springer Verlag, Berlin, Heidelberg. DGIWG (2006). Request For Information Service Specification Edition 2.0. Technischer Bericht, Digital Geospatial Information Working Group (DGIWG). Frackenpohl, D. (2002). Agentenbasiertes Auftragsmanagement für die Multiressourcen-Montage. Dissertation, Universität Hannover. Frese, E. & Noetel, W. (1992). Kundenorientierung in der Auftragsabwicklung. Strategie, Organisation und Informationstechnologie. VDI-Verlag GmbH, Düsseldorf, Schäffer-Poeschel Verlag, Stuttgart. Gizanis, D. (2006). Kooperative Auftragsabwicklung. Architektur, Praxisbeispiele und Nutzenpotentiale. Universität St. Gallen, Dissertation Nr. 3131, Difo-Druck GmbH, Bamberg. IT-Rat (2008). Das V-Modell XT v1.2.1.1. IT-Rat der Bundesregierung. http://www.v-modell-xt. de. Kaster, J. (2007). Datenverarbeitung Auftragssteuerung – Konzept und Realisierung (v2.0). Technischer Bericht 2007/5, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Küttelwesch, H., Huy, S., & Kaster, J. (2003). Datenverarbeitung Auftragssteuerung. Konzept und Realisierung. Technischer Bericht, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. NATO (2003). STANAG 2149 INT (Edition 6). Request For Information. NATO (2006). User Guide for RFIMS v4.0. NATO CIS Services Agency. Rohweder, D. (1996). Informationstechnik und Auftragsabwicklung. Potentiale zur Gestaltung und flexiblen kundenorientierten Steuerung des Auftragsflusses in und zwischen Unternehmen. Unternehmensführung und Logistik – Band 9, Erich Schmidt Verlag GmbH & Co., Berlin. Schreiner, P. (2004). Charakterisierung von Dienstleistungsprozessen und empirische Implikation für die kundenorientierte Gestaltung. Vom Kunden zur Dienstleistung. Methoden, Instrumente und Strategien zum Customer-related Service Engineering, Zahn, E., Spath, D., Scheer, A. (Hrsg), Fraunhofer IRB Verlag, Stuttgart. Vujasinovic, A. (2008). Erstellung eines Konzeptes für eine IT-basierte Auftragssteuerung für mehrstufige und komplexe Informationsersuchen. Masterarbeit, Fachhochschule Koblenz, RheinAhrCampus Remagen. Womack, J., Jones, D., & Roos, D. (1991). The Machine that changed the world. HarperPaperbacks.

Kapitel 11

Grafische Aktionsplanung Marc Spielmann

11.1 Einleitung Für ein koordiniertes Vorgehen unterschiedlicher Elemente (Personen, Organisationseinheiten, Truppenteile etc.) im Rahmen einer gemeinsamen Unternehmung (wie z. B. einer militärischen Operation) in einem komplexen, dynamischen Umfeld ist es essentiell, dass alle beteiligten Elemente ein gemeinsames Verständnis haben. Nur wenn die Elemente hinsichtlich ihres jeweiligen Verständnisses  der aktuellen Lage (Ist-Zustand),  des zu erreichenden Ziels (Soll-Zustand) und  des für die Erreichung des Ziels geplanten Vorgehens (Strategie) aufeinander abgestimmt sind, ist ein schnelles und flexibles Reagieren auf sich ändernde Parameter, wie z. B. unvorhergesehene Ereignisse oder im Vorfeld nicht präzise zu erfassende Randbedingungen, möglich. Das gilt umso mehr, je dynamischer das Umfeld, je zahlreicher die Elemente, je größer die Abhängigkeiten der Elemente untereinander und je umfangreicher die zu bewältigende Aufgabe ist. Dementsprechend ist die Herstellung und die Aufrechterhaltung eines solchen gemeinsamen Verständnisses aller Elemente während einer gemeinsamen Unternehmung das zentrale Anliegen von Führung. Folglich wird bei der Führung bzw. bei den dabei ablaufenden Prozessen ein beträchtlicher Anteil der zur Verfügung stehenden Ressourcen für die Erarbeitung (z. B. Gewinnung, Aufbereitung, Aggregation etc.) und das Kommunizieren der Führungsinformationen „Lage“, „Ziel“ und „Vorgehen“ genutzt. Zur Beschleunigung und zur besseren Abstimmung von Führungsprozessen werden heutzutage IT-Systeme eingesetzt, welche die Erarbeitung und das Kommunizieren von Führungsinformationen unterstützen. Eine wichtige Rolle dabei spielen Systeme zur Verarbeitung von Informationen, welche in Form von Texten oder Grafiken vorliegen. Das Spektrum der für die Verarbeitung dieser Informationen eingesetzten IT-Systeme reicht heute von einfachen Anwendungen zum Austausch von

M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

149

150

M. Spielmann

Kurznachrichten (Chat) über Bürokommunikationssysteme (z. B. MS-Office, Lotus Notes und Sametime) bis hin zu verteilten Datenbankanwendungen mit Anbindung an Geoinformationssysteme. Auf die verschiedenen Möglichkeiten zur Verarbeitung von Informationen, welche in Form von gesprochener Sprache vorliegen, soll hier nicht weiter eingegangen werden. Stattdessen sei auf Kap. 13 verwiesen. Systeminterne Strukturierung von Informationen Ein wichtiges Unterscheidungsmerkmal dieser IT-Systeme ist der Grad der systeminternen Strukturierung der verarbeiteten Informationen. Mit systeminterner Strukturierung ist hier nicht die Strukturierung von Informationen aus Sicht des Nutzers (z. B. die inhaltliche Gliederung eines Textes) gemeint, sondern die Strukturierung der Informationen aus Sicht eines IT-Systems, genauer die Strukturierung der Daten, welche die Informationen bei der systeminternen Verarbeitung letztendlich repräsentieren. Beispielsweise muss zu einer Information, die in einer Datenbank gespeichert werden soll, zuvor ein Datensatz gefunden werden, der die Information in der Datenbank repräsentieren kann. Handelt es sich bei der Datenbank um eine relationale Datenbank, so könnte der Datensatz die Form einer neuen Tabellenzeile innerhalb einer Datenbanktabelle haben. Die Struktur des Datensatzes, d. h. dessen Aufbau aus elementaren Datentypen, wird dabei durch das Datenmodell (oder Schema) der Datenbank bestimmt. Das Datenmodell kann auch als eine Strukturierungsvorschrift für das Speichern von Informationen in der Datenbank gesehen werden. Inwieweit die dadurch vorgegebene systeminterne Strukturierung von Informationen aus Nutzersicht sinnvoll ist, ist für die informationstechnische Verarbeitung zunächst einmal unerheblich. Der oben erwähnte Grad der systeminternen Strukturierung von Informationen zielt nun auf die Granularität und die Komplexität der verwendeten systeminternen Strukturierung. IT-Systeme, welche Informationen in einer hohen Auflösung speichern und viele semantische Verknüpfungen zwischen Teilinformationen anlegen, können die zu verarbeitenden Informationen präziser analysieren und aufbereiten und so letztendlich dem Nutzer eine bessere Unterstützung bieten. Als Beispiel betrachte man zwei Systeme zur Verarbeitung militärischer Meldungen. Das erste System nutze zur internen Repräsentation von Meldungen das MIP-Referenzdatenmodell (vgl. Kap. 16), ein Datenmodell von hoher Granularität und Komplexität. Das zweite System verarbeite Meldungen in Form von Freitexten; damit sind Zeichenfolgen gemeint, die keine zusätzlichen, vom System unmittelbar auswertbaren Informationen über den Inhalt eines Textes enthalten. Diese vergleichsweise einfache Repräsentationsart hat eine minimale Granularität und Komplexität. Im ersten System lassen sich aufgrund der durch das MIP-Datenmodell vorgegebenen Struktur eines Datensatzes bestimmte Teilinformationen einer militärischen Meldung einfach aus dem Datensatz auslesen und weiterverarbeiten. Ganz anders stellt sich die Situation im zweiten System dar. Der algorithmische Aufwand zur Gewinnung derselben Teilinformationen aus der in Form eines Freitextes vorliegenden Meldung ist in der Regel deutlich größer (vgl. auch Kap. 12).

11 Grafische Aktionsplanung

151

Bei der Entwicklung von IT-Systemen zur Unterstützung von Führungsprozessen sollte also ein hoher Strukturierungsgrad bei der systeminternen Verarbeitung von Informationen angestrebt werden. Teilformatierte Texte und Grafiken Das Auffinden geeigneter systeminterner Strukturierungen (Datenmodelle, Formate, Strukturierungsvorschriften etc.) für eine Reihe wichtiger Führungsinformationen ist jedoch im Allgemeinen schwierig. Häufig sind Führungsinformationen, insbesondere dann, wenn es sich um die Einschätzung der aktuellen Lage, die Darstellung des zu erreichenden Ziels oder die Beschreibung des geplanten Vorgehens handelt, inhaltlich sehr komplex und variieren, je nach Rolle und Aufgabe des adressierten Elements, in ihrer Ausprägung (z. B. im Umfang, im Detaillierungsgrad oder in der Darstellungsform). Aus diesem Grund werden für die Erarbeitung und das Kommunizieren derartiger Führungsinformationen vorzugsweise teilformatierte Texte und Grafiken verwendet. Mit teilformatierten Texten sind hier Texte gemeint, die zwar gemäß einer bestimmten Formatvorgabe gegliedert sind, bei denen aber noch substantielle Textanteile Freitexte sind. Als Beispiel betrachte man Email-Nachrichten mit den üblichen vordefinierten Feldern „Von“, „An“, „Betreff“ etc. Obwohl durch die vordefinierten Felder eine Grobgliederung vorgegeben ist, kann der Nutzer den eigentlichen Text – also letztlich den Inhalt einer Nachricht – beliebig gestalten. Ganz ähnlich verhält es sich mit teilformatierten Grafiken. Als typisches Beispiel lassen sich hier Powerpoint-Folien nennen. Auch bei Powerpoint-Folien gibt es bestimmte vordefinierte Felder (z. B. „Titel“, „Autor“ und „Notizen“). Dennoch sind die eigentlichen Grafiken „Freigrafiken“, d. h. sie enthalten keine zusätzlichen, von einem IT-System unmittelbar auswertbaren Informationen über die Bedeutung der Grafiken. Die strukturierten Anteile teilformatierter Texte und Grafiken können, je nach zugrundeliegender Formatvorgabe, für eine mehr oder minder ausgeprägte WorkflowUnterstützung genutzt werden (vgl. Kap. 9). Eine qualitativ hochwertige Geschäftsprozessunterstützung scheitert aber oftmals an der Tatsache, dass wichtige Führungsinformationen nur in den eingebetteten Freitexten und -grafiken enthalten sind, und daran, dass für diese Informationen noch keine praktikablen systeminternen Strukturierungen entwickelt wurden (Untersuchungen in diese Richtung mit Blick auf die in Freitext-Meldungen enthaltenen Informationen sind Gegenstand von Kap. 17). Dementsprechend werden die eingebetteten Freitexte und -grafiken von den meisten Systemen als „Black Boxes“ behandelt: Zwar wird die Erstellung, Verteilung und Verwaltung von Freitexten und -grafiken in elektronischer Form unterstützt, eine weitere Aufbereitung und Analyse der darin enthaltenen Informationen bleibt aber in der Regel aus. Eine Alternative dazu können neuere Ansätze zur Informationsextraktion aus militärischen Freitext-Meldungen bieten (vgl. Kap. 12). Der damit verbundene technische Aufwand ist allerdings – im Vergleich zur Nutzung einer bereits bei der Systementwicklung berücksichtigten systeminternen Strukturierung – groß und die damit erzielbaren Ergebnisse hängen von der Textsorte und der Komplexität der zu extrahierenden Informationen ab.

152

M. Spielmann

Bemerkung. In der Tat lässt sich der folgende Zusammenhang beobachten: Je mehr Aufwand bei der Systementwicklung in eine systeminterne Strukturierung der später zu verarbeitenden Informationen investiert wird, desto weniger Ressourcen müssen nachträglich für eine Informationsextraktion aufgewendet werden, also letztendlich für eine nachträgliche Strukturierung der Informationen entweder automatisch durch das System oder teilautomatisch mit Unterstützung durch den Nutzer. Militärische Operationsskizzen In diesem Beitrag wird ein Ansatz zur Strukturierung von Operationsskizzen des Heeres vorgestellt. Operationsskizzen stellen ein wichtiges Führungsmittel bei der Befehlsgebung des Heeres dar. Mit Hilfe der Skizzen lassen sich die Führungsinformationen „Lage“, „Ziel“ und „Vorgehen“ bis zu einem bestimmten Detaillierungsgrad grafisch repräsentieren. Dadurch erhält der Betrachter eine intuitive und schnell erfassbare Darstellung zentraler Aspekte einer geplanten Operation. Die Skizzen werden sowohl bei der schriftlichen als auch bei der mündlichen Befehlsgebung eingesetzt. Bei der schriftlichen Befehlsgebung finden die Skizzen entweder in schriftlichen Operationsbefehlen (vgl. BMVg, 1998, Anlage 15) als kompakte Übersicht über die geplante Operationsführung oder in grafischen Operationsbefehlen (vgl. BMVg, 1998, Anlage 18) als Hauptbeschreibungsmittel Verwendung. Dabei wandelt sich die Rolle der Skizzen von „Übersicht“ hin zu „Hauptbeschreibungsmittel“ beim Übergang von der operativen Ebene zur taktischen Ebene. Auf den unteren Führungsebenen, also dort, wo die Befehlsgebung aufgrund der harten zeitlichen Anforderungen überwiegend mündlich geschieht, sind die Skizzen schließlich ein unverzichtbares Führungsmittel. Heutige IT-Systeme zur Unterstützung des Befehlsgebungsprozesses des Heeres verarbeiten Operationsbefehle in Form von teilformatierten Texten und Grafiken. Dabei werden Operationsskizzen entweder als Freigrafiken (vgl. oben) oder als teilformatierte Grafiken mit einer rudimentären systeminternen Strukturierung verarbeitet. A priori lassen sich für Operationsskizzen (genauer für die durch die Skizzen repräsentierten Informationen) drei Strukturierungsgrade definieren: 1. Zugang zu Entitäten: Die in Operationsskizzen vorkommenden militärisch relevanten Entitäten (Truppenteile, Führungslinien, Räume etc.) werden systemintern mit entsprechenden Geschäftsobjekten verknüpft, z. B. durch das Anlegen elektronischer Referenzen auf die betreffenden Datensätze. Dem System wird dadurch ermöglicht, auf Basis der in einer Operationsskizze vorkommenden Entitäten einfache Konsistenzprüfungen automatisch durchzuführen sowie dem Nutzer noch während der Befehlsbearbeitung weiterführende Funktionalitäten anzubieten. 2. Zugang zur Planung: Zusätzlich zu den o. g. Entitäten werden bei diesem Strukturierungsgrad die in Operationsskizzen beschriebenen geplanten zeitlichen und räumlichen Beziehungen und Aktionen von Entitäten systemintern gespeichert. Dadurch erhalten die verarbeitenden Systeme die Möglichkeit, qualitativ höherwertige Konsistenzprüfungen durchzuführen. Beispielsweise lassen sich die

11 Grafische Aktionsplanung

153

in einem grafischen Marschbefehl enthaltenen Angaben über Marschroute, Ablaufzeit, Marschdauer, Marschfolge etc. so aufbereiten, dass die Daten vom System direkt ausgewertet werden können. Mit dem Wissen über eine beabsichtigte Truppenverlegung kann das System eine Reihe von höherwertigen Konsistenzprüfungen automatisch durchführen. Zum Beispiel kann das System für alle in der Marschfolge aufgeführten Truppenteile prüfen, ob diese über eine für die Durchführung des Marsches ausreichende Betriebsstoffmenge verfügen. Gegebenenfalls kann das System auf einen drohenden Betriebsstoffmangel hinweisen und optional entsprechende Unterstützungsaufträge an die Logistik vorschlagen. Darüber hinaus kann das System besonders kritische Wegstrecken und Gefahrenpunkte entlang der Marschroute identifizieren und systemintern markieren. Eingehende Meldungen, welche im Zusammenhang mit der Marschroute stehen (z. B. „Brücke auf Marschroute beschädigt“), können dann mit Priorität an die betreffenden Truppenteile weitergeleitet werden. 3. Zugang zur Intention: Aufbauend auf den ersten beiden Strukturierungsgraden werden bei diesem Strukturierungsgrad zusätzlich Informationen über Strategien und Intentionen des Befehlsgebers in einer maschineninterpretierbaren Form gespeichert. Mit diesen Informationen kann das System sehr komplexe Konsistenzprüfungen durchführen und mit Rückgriff auf Experten- und Simulationssysteme Handlungsoptionen erarbeiten bzw. bewerten. Denkbar wäre z. B. eine Bewertung der Erfolgsaussicht der Strategie des Befehlsgebers im Kontext der aktuellen Lage. Unter Umständen lassen sich auch alternative Strategien auf Basis vorangegangener Operationen mit ähnlicher Zielsetzung und unter vergleichbaren Randbedingungen generieren. Wie oben angedeutet, erreichen heutige IT-Systeme zur Unterstützung des Befehlsgebungsprozesses des Heeres bestenfalls Strukturierungsgrad (1). Eine Ausnahme bildet das Verkehrsführungssystem HEROS-5, welches die militärische Verkehrsführung bei der Erstellung und Bearbeitung von Marschinformationen unterstützt. Die mit dem System berechneten Marschwege, Belegungsübersichten und -pläne können als Grundlage für die Erstellung von Marschbefehlen dienen. Leider ist es nicht möglich, die erzeugten Daten in den Gesamtprozess „Befehlsgebung“ so einzubetten, dass die Strukturierung der Daten erhalten bleibt: Der von HEROS-5 partiell erreichte Strukturierungsgrad (2) endet an den Systemgrenzen von HEROS-5 zu anderen Systemen (vgl. auch Abschn. 11.4). Der hier vorgestellte Ansatz zur Strukturierung von Operationsskizzen erreicht Strukturierungsgrad (2) und ist nicht auf den Befehlstyp „Marsch“ beschränkt. Kerngedanke ist es, den in Operationsskizzen vorkommenden Symbolen und Grafiken einen semantischen Überbau beizustellen: Letztendlich werden die Skizzen mit Metadaten angereichert, welche einen inhaltlichen Zusammenhang zwischen den einzelnen, in den Skizzen vorkommenden Symbolen und Grafiken herstellen. Diese Metadaten erlauben es dann den verarbeitenden IT-Systemen, die in den Skizzen enthaltenen Führungsinformationen zu analysieren und mit anderen im System gespeicherten Informationen in Beziehung zu setzen.

154

M. Spielmann

Erzeugung von Metadaten Es stellt sich nun die Frage nach der Herkunft der Metadaten (Wer erzeugt die Metadaten wann und wie?). Eine zufriedenstellende Antwort auf diese Frage hat einen entscheidenden Einfluss auf die Praktikabilität des Ansatzes. (Dies gilt im Übrigen für alle Strukturierungsansätze, welche auf der Einführung neuer Metadaten basieren!) Drei Optionen für die Erzeugung von Metadaten fallen sofort ins Auge: 1. Explizite Eingabe: Der Nutzer gibt die Metadaten direkt ein, z. B. mit Hilfe entsprechender Eingabemasken. 2. Implizite Eingabe: Bei der Eingabe von Informationen durch den Nutzer (z. B. beim Zeichnen einer Operationsskizze) werden die Metadaten systemintern und für den Nutzer transparent erzeugt. 3. Informationsextraktion: Aus den bereits im System vorliegenden Informationen werden die Metadaten automatisch durch das System oder teilautomatisch unter Einbeziehung des Nutzers erzeugt. Eine manuelle Eingabe der Metadaten durch den Nutzer (Option 1) birgt die Gefahr von fehlerhaften und unvollständigen Datensätzen. Sind die einzugebenden Daten umfangreich oder für den Nutzer nicht intuitiv, leidet zusätzlich die Nutzerakzeptanz, mit entsprechender Auswirkung auf die Qualität der Daten. Dies kann die Praktikabilität des Ansatzes insgesamt in Frage stellen. Das andere Extrem, eine vollautomatische Generierung der Metadaten durch das System (Option 3), ist wünschenswert, aber nicht immer in ausreichender Qualität der Metadaten sicherzustellen. Dies gilt in besonderem Maße für komplexe Führungsinformationen. Bei dem hier verfolgten Strukturierungsansatz lassen sich die Metadaten bei der Befehlserstellung und -bearbeitung automatisch und für den Nutzer transparent generieren (Option 2). Dafür muss die etablierte Praxis der grafischen Eingabe und Bearbeitung militärischer Operationsskizzen nur geringfügig abgewandelt bzw. ergänzt werden. Beispielsweise kann eine grafische Benutzeroberfläche konzipiert werden, welche die Befehlserstellung und -bearbeitung unterstützt und gleichzeitig die Generierung der Metadaten im Hintergrund sicherstellt. Gliederung. Der Rest des Beitrags ist wie folgt gegliedert: Im nächsten Abschnitt wird der beschriebene Ansatz zur systeminternen Strukturierung militärischer Operationsskizzen vorgestellt. Die in den resultierenden, maschineninterpretierbaren Operationsskizzen enthaltenen Metadaten lassen sich mittels einer Benutzeroberfläche zur grafisch unterstützten Befehlserstellung und -bearbeitung für den Nutzer transparent erzeugen. Ein entsprechendes Konzept wird in Abschn. 11.3 skizziert. Der Mehrwert der hier vorgeschlagenen Strukturierungsmaßnahme wird insbesondere im Kontext der ebenenübergreifenden Befehlsgebung deutlich. Eine entsprechende Einordnung ist Gegenstand von Abschn. 11.4. Der Beitrag schließt mit einer kurzen Zusammenfassung der Ergebnisse in Abschn. 11.5.

11 Grafische Aktionsplanung

155

11.2 Maschineninterpretierbare Operationsskizzen Im Folgenden wird ein Formalismus zur Repräsentation militärischer Operationsskizzen in Form semi-strukturierter Daten vorgestellt. Der Formalismus lässt sich zu einem semi-strukturierten Datenmodell erweitern, welches dann zur systeminternen Darstellung von Operationsskizzen in FüInfoSys verwendet werden kann. Kern des Formalismus ist eine kontextfreie Grammatik (Hopcroft et al., 2000) zur Repräsentation georeferenzierter Aufträge, das sind, im Prinzip, räumliche Konfigurationen, welche mit militärischen Aufträgen verbunden sind. Darauf aufbauend lassen sich dann zeitliche Aspekte wie Nebenläufigkeiten und sequenzielle Abfolgen in den Formalismus integrieren. Dies geschieht durch eine Erweiterung der kontextfreien Grammatik um Zeittafeln, welche eine Kombination von georeferenzierten Aufträgen zu komplexen Plänen ermöglichen (vgl. Abb. 11.1).

11.2.1 Operationsskizzen Operationsskizzen ermöglichen es dem Befehlsgeber, die geplante Operationsführung (Wer, Wo, Was, Wann) in einer kompakten grafischen und für den Befehlsempfänger unmittelbar zugänglichen und intuitiven Art und Weise darzustellen. Als Beispiel betrachte man die stark vereinfachte Operationsskizze eines Bataillons in Abb. 11.2. Die Skizze liest sich wie folgt: Auf der rechten Seite der mit „AL“ gekennzeichneten Linie wird ein koordinierter Angriff befohlen, an dem drei Kompanien (1–3) teilnehmen. Dies wird durch die Angriffspfeile, welche von den taktischen Symbolen der Kompanien (die mit „I“ gekennzeichneten Rechtecke) ausgehen, symbolisiert. Der Angriff der drei Kompanien ist im folgenden Sinne koordiniert: 1. Räumlich: Jeder Kompanie ist ein Gefechtsstreifen zugeordnet, welcher durch die Ablauflinie (mit „AL“ gekennzeichnet), durch eine oder durch zwei Kompaniegrenzen (mit „I“ gekennzeichnet) und, je nach Kompanie, durch eine Bataillons- oder Brigadegrenze (mit „II“ bzw. „X“ gekennzeichnet) begrenzt wird.

maschineninterpretierbare Operationsskizzen

Abb. 11.1 Schematischer Aufbau des Formalismus zur Repräsentation von Operationsskizzen (und darauf aufbauend Operationsbefehlen) in IT-Systemen

156

M. Spielmann

Obj

ZZ x

I

I

1

II

Obj

I

I

2

ZZ

I

II

3

Obj

II

AL

Abb. 11.2 Schematische Darstellung der Operationsskizze eines Bataillons (II), welchem drei Kampfkompanien (I) unterstellt sind. Die angedeuteten taktischen Symbole (Bataillonsgefechtsstand, Kompanien) und Grafiken (Truppengrenzen und Ablauflinie AL) sind georeferenziert und würden in einer realen Skizze vor dem Hintergrund einer Karte dargestellt werden

Während des Angriffs operieren alle an dem Angriff beteiligten Truppenteile einer Kompanie innerhalb des der Kompanie zugeordneten Gefechtsstreifens. Dadurch wird gewährleistet, dass sich im kompanieeigenen Operationsgebiet keine kompaniefremden (eigenen) Truppenteile aufhalten. 2. Zeitlich: Bei Beginn des Angriffs sollen alle drei Kompanien die (ggf. von einer höheren Führungsebene) vorgegebene Ablauflinie (AL) zur gleichen Zeit überschreiten. Unter Umständen ist der Zeitpunkt der Überschreitung durch eine mit der Ablauflinie assoziierten Zeitmarke (entweder absolut oder dynamisch, z. B. „auf Befehl“) vorgegeben. Diese Konvention soll einen koordinierten gleichförmigen Vormarsch der eigenen Kräfte sicherstellen und so das Entstehen offener Flanken verhindern. Auf der linken Seite der Ablauflinie wird jeder Kompanie ein Verfügungsraum zugeordnet, in dem sich die Kompanie auf den Angriff vorbereiten soll. Darüber hinaus ist die Position bzw. der Raum des Bataillonsgefechtsstands (symbolisiert durch die mit „II“ gekennzeichnete Fahne) bestimmt. Weiterhin lassen sich Informationen über die Einsatz- und Führungsunterstützung in einer Operationsskizze vermerken. Auf solche Aspekte kann in diesem Beitrag aus Platzgründen allerdings nicht eingegangen werden.

11.2.2 Georeferenzierte Aufträge Als kleinste semantisch zusammenhängende Einheiten, aus denen sich Operationsskizzen zusammensetzen lassen, verwendet der hier vorgestellte Formalismus georeferenzierte Aufträge. Intuitiv lassen sich mit georeferenzierten Aufträgen die in Operationsskizzen enthaltenen „Wo“- und „Was“-Anteile (Wo ist welcher Auftrag zu erfüllen?) formal spezifizieren. Die „Wer“- und „Wann“-Anteile (Wer erfüllt einen Auftrag wann?) werden im nächsten Unterabschnitt in Form von Zeittafeln

11 Grafische Aktionsplanung

157

hinzugefügt. Bei den folgenden Betrachtungen beschränken wir uns auf den Auftragstyp „Angriff“. Für andere Auftragstypen (z. B. Verzögerung, Verteidigung und Marsch) sei der Leser auf den FKIE-Bericht (Spielmann, 2007) verwiesen. Ein grafischer Angriffsauftrag an einen Truppenteil beinhaltet die folgenden Informationen: 1. einen Verfügungsraum, in dem sich der Truppenteil für den Angriff positioniert, 2. eine Ablauflinie zur räumlichen und zeitlichen Koordinierung des Angriffsbeginns, 3. eine Menge von Angriffsachsen, welche die Stoßrichtungen, Zwischenziele und Primärziele des Angriffs bestimmen, und 4. eine linke und eine rechte Grenze zwecks räumlicher Koordinierung mit benachbarten Truppenteilen. Als Beispiel betrachte man die Operationsskizze in Abb. 11.3. Das Operationsgebiet des dort blau markierten Angriffsauftrags an die Kompanie „1“ wird links durch die Brigadegrenze (X) und rechts durch die Kompaniegrenze (I) begrenzt. Der Auftrag beinhaltet die Bildung einer Angriffsachse (vgl. die Angriffspfeile). Durch die Angriffsachse wird einerseits die Stoßrichtung für die angreifenden Kräfte vorgegeben und andererseits die Reihenfolge, in der das Zwischenziel (ZZ) und das Primärziel (Obj) bekämpft werden sollen, bestimmt. Zur Modellierung georeferenzierter Aufträge und deren inneren Struktur (z. B. zwecks Verarbeitung in einem FüInfoSys) verwenden wir kontextfreie Grammatiken (Hopcroft et al., 2000). Um den notwendigen Formalismus auf ein Minimum zu reduzieren, beschränken wir uns bei der Präsentation solcher Grammatiken auf die Angabe der dazugehörigen Produktionsregeln. Die folgenden Produktionsregeln induzieren eine kontextfreie Grammatik zur formalen Repräsentation georeferenzierter Angriffsaufträge: GeoRefAngriff ! VfgRaum, AblaufLinie, AngriffsAchsen, LinkerRand, RechterRand VfgRaum ! GeoCoordRef(OpRaum)

Obj

ZZ x

I

I

1

II

Obj

I

I

2

ZZ

I

Obj

II

3

II

AL

Abb. 11.3 Die blau markierten Anteile bilden das Gerüst eines georeferenzierten Angriffsauftrags für die Kompanie 1

158

M. Spielmann

AblaufLinie ! GeoCoordRef(FüLinie) AngriffsAchsen ! SetOf(AngriffsAchse) AngriffsAchse ! (AngriffsLinie, ZwischenZiel)*, AngriffsLinie, AngriffsZiel AngriffsLinie ! ... wobei „GeoCoordRef“ einen speziellen Referenzoperator und „SetOf“ den üblichen Mengenoperator repräsentieren. Für eine weitere Detaillierung der Grammatik sei der Leser auf den FKIE-Bericht (Spielmann, 2007) verwiesen. Man beachte, dass in der obigen Grammatik Ablauflinien nicht mit Zeitmarken assoziiert sind. In einer realen Operationsskizze werden Ablauflinien aber häufig mit Zeitmarken versehen, um den Beginn eines Angriffs zu terminieren. Durch eine Erweiterung des Formalismus im nächsten Unterabschnitt um zeitliche Aspekte wie Beginn und Ende eines Auftrags werden derartige Zeitmarken für unsere Zwecke implizit eingeführt und integriert.

11.2.3 Zeittafeln und Pläne In diesem Abschnitt wird der bisher erarbeitete Formalismus um die in Operationsskizzen enthaltenen „Wer“- und „Wann“-Anteile erweitert. Die zeitliche Dimension („Wann“) wird in Form von Zeittafeln repräsentiert. Zeittafeln ermöglichen eine Kombination von georeferenzierten Aufträgen zu komplexen Plänen. Da mit Zeittafeln zeitliche Abhängigkeiten und Nebenläufigkeiten präzise beschrieben werden können, sind die resultierenden Pläne in gewissem Sinne ausdrucksstärker als (konventionelle) Operationsskizzen. Die folgende Grammatik definiert die Menge der Zeittafeln: ZeitTafel ! PO-SetOf(ZeitIntervall) ZeitIntervall ! Beginn, Ende Beginn, Ende ! Undef | ZeitPunkt | ZeitConstraint ZeitPunkt ! AbsoluteTime | ZeitRef, [ZeitOffset] ZeitConstraint ! . . . wobei „PO-SetOf“ für eine endliche, partiell geordnete Menge von Zeitintervallen steht. Auch hier sei wieder auf den FKIE-Bericht (Spielmann, 2007) für eine Detaillierung der Grammatik verwiesen. Als Beispiel betrachte man die in Abb. 11.4 skizzierte Zeittafel. Diese besteht aus den drei Zeitintervallen I1 , I2 und I3 . Intervall I1 beginnt um 10:00 (absolute Zeitangabe). Die Dauer von I1 ist unbestimmt. Intervall I2 beginnt unmittelbar im Anschluss an Intervall I1 und dauert höchstens 48 Stunden. Intervall I3 beginnt zum selben Zeitpunkt wie I1 (10:00) und endet frühestens 12 Stunden, nachdem I1 beendet wurde. Mit diesen Angaben lassen sich bis auf die Endpunkte von I2 und I3 alle Anfangs- und Endpunkte zeitlich in Relation setzen. Wir kommen nun zur Definition komplexer Pläne, basierend auf georeferenzierten Aufträgen. Ein solcher Plan kann eine oder mehrere (klassische) Operationsskizzen repräsentieren. Intuitiv besteht ein Plan aus einer Zeittafel, bei der jedes

11 Grafische Aktionsplanung

159 = Ref(Beginn I2) + 12h

Abb. 11.4 Zeittafel bestehend aus drei Intervallen

Intervall mit einer Menge von Aktivitäten assoziiert ist, wobei jede Aktivität durch einen Truppenteil (Wer) und einen georeferenzierten Auftrag (Was, Wo) bestimmt ist. Räumliche Koordinierungselemente – damit sind Truppengrenzen, Führungslinien, operative Räume etc. gemeint – nehmen hierbei eine Sonderrolle ein, da diese unter Umständen mehrere, zeitlich nicht koordinierte Aktivitäten betreffen und aus diesem Grund nicht Bestandteil der Zeittafel sind, sondern mit dieser nur assoziiert werden. Die folgende Grammatik definiert nun die Menge der Pläne: ! RaumKoordElemente, PO-SetOf(ZeitKoordAktivitäten) ZeitKoordAktivitäten ! ZeitIntervall, SetOf(Aktivität) Aktivität ! UnitRef, GeoRefAuftrag GeoRefAuftrag ! GeoRefAngriff | GeoRefVzg | . . . Plan

Der hier vorgestellte Formalismus kann zu einem Formalismus zur Repräsentation von Operationsbefehlen erweitert werden (Spielmann, 2007). Einerseits lassen sich die oben dargestellten Produktionsregeln so ergänzen, dass ein Befehlsgeber die verschiedenen Elemente einer Operationsskizze mit schriftlichen Erläuterungen und Ergänzungen anreichern kann. Andererseits lassen sich zusätzliche Produktionsregeln formulieren, welche es einem Befehlsgeber ermöglichen, Beurteilungen, Strategien und Intentionen in Form teilformatierter Texte anzufügen (vgl. Abb. 11.1). Werden diese angefügten teilformatierten Texte in BML (vgl. Kap. 17) abgefasst, so liegt auch deren Inhalt als strukturierte Information vor und steht damit ergänzend für automatisierte Prozesse zur höherwertigen Konsistenzprüfung zur Verfügung.

11.3 Grafisch unterstützte Befehlsbearbeitung Für die Praktikabilität und Nutzerakzeptanz des oben dargestellten Strukturierungsansatzes ist die Bereitstellung einer Benutzeroberfläche, welche eine möglichst einfache Eingabe und Bearbeitung maschineninterpretierbarer Operationsskizzen erlaubt, von zentraler Bedeutung. Im Folgenden wird eine grafische Benutzeroberfläche, mit der sich die Skizzen durch einfache grafische Manipulationen erstellen und modifizieren lassen, beschrieben. Bei der Verwendung der Benutzeroberfläche werden die in den Skizzen implizit enthaltenen Metadaten (deren Struktur letztendlich

160

M. Spielmann

durch die oben angedeuteten Produktionsregeln definiert ist) automatisch generiert bzw. manipuliert. Für die Darstellung der verschiedenen Aspekte einer maschineninterpretierbaren Operationsskizze werden drei inhaltlich koordinierte Anzeigen (vgl. Abb. 11.5) verwendet: 1. Zeittafelanzeige (in der Abbildung oben links): Diese Anzeige enthält eine grafische Darstellung der Zeittafel eines Plans und unterstützt die folgenden Funktionen: Durch das Markieren einer Aktivität wird die Aktivität in der Aktivitätsanzeige (vgl. unten) visualisiert. Zusätzlich werden alle mit der Aktivität assoziierten räumlichen Elemente in der georeferenzierten Anzeige (vgl. unten) hervorgehoben. Durch das Markieren eines Zeitintervalls werden alle mit diesem Zeitintervall assoziierten Aktivitäten in der georeferenzierten Anzeige hervorgehoben. Darüber hinaus werden eventuell vorhandene, mit dem Zeitintervall assoziierte schriftliche Ergänzungen und Erläuterungen in Textform eingeblendet. Durch das Ziehen eines „Reiters“ auf der Zeitachse werden alle zu dem so markierten Zeitpunkt potentiell ablaufenden Aktivitäten in der georeferenzierten Anzeige hervorgehoben.

Undef

A21, A22

A11, A12

Undef

A11:

x

verzögert

1

LR

>= TTRef(Beginn A11, A12) + 48h

xx

SL

RR

x

1

x

1

x

t

VRV +36 +24

48h

xx

xx

x x

x

2

2

x

48h xx

VRV

VZL VZL t SL VZL t+24 t+36

Abb. 11.5 Skizze einer grafischen Nutzeroberfläche zur Darstellung und Manipulation maschineninterpretierbarer Operationsskizzen

11 Grafische Aktionsplanung

161

2. Aktivitätsanzeige (in der Abbildung oben rechts): In dieser Anzeige werden zu einer in der Zeittafel markierten Aktivität der jeweilige Akteur und Auftrag sowie die einzelnen Bestandteile des Auftrags symbolisch und in reduzierter Form dargestellt. Zusätzlich werden eventuell vorhandene schriftliche Ergänzungen und Erläuterungen in Textform eingeblendet. Durch das Markieren eines Symbols (z. B. Akteur, linker Rand, rechter Rand etc.) wird das mit dem Element assoziierte räumliche Element in der georeferenzierten Anzeige hervorgehoben. 3. Georeferenzierte Anzeige (in der Abbildung unten): In dieser Anzeige werden alle räumlichen Elemente (einschließlich Auftragssymbole) vor dem Hintergrund geeigneten Kartenmaterials grafisch dargestellt. Durch das Markieren eines räumlichen Elements werden alle mit dem Element assoziierten Aktivitäten in der Zeittafel hervorgehoben. Optional können die so bestimmten Aktivitäten zusätzlich in einer oder mehreren Aktivitätsanzeigen visualisiert werden. Für die Eingabe und Bearbeitung einer Skizze werden die folgenden Funktionen (z. B. in Form kontextsensitiver Menüs) bereitgestellt:  Eingabe räumlicher Koordinierungselemente: Die einem räumlichen Koordinierungselement zugrundeliegende geometrische Figur (Punkt, Linie, Polygonzug oder Raum) lässt sich zunächst in der georeferenzierten Anzeige deklarieren. Dies kann entweder durch die direkte georeferenzierte Eingabe einer neuen Figur, durch das Markieren einer bereits existierenden Figur oder durch das Markieren von Geobasisdaten (z. B. Straßenabschnitte, Ortsgebiete etc.) in der Hintergrundkarte (z. B. einer Vektorkarte eines Geoinformationssystems) geschehen. Die so deklarierte Figur kann dann im Anschluss als räumliches Koordinierungselement eines bestimmten Typs definiert werden.  Eingabe und Modifikation von Zeitintervallen: In der Zeittafelanzeige werden Funktionen zur grafischen Eingabe und Modifikation von Zeitvektoren bereitgestellt, z. B. Funktionen zum Anlegen neuer Vektoren sowie zum Verschieben und Verbinden von Anfangs- und Endpunkten von Vektoren. Ähnliches gilt für Zeitpunkte. Für das Einfügen und Bearbeiten von Zeit-Constraints werden Bildschirmmasken mit vordefinierten Operatorbausteinen angeboten.  Eingabe und Modifikation von Aktivitäten: In der Aktivitätsanzeige werden Funktionen zur grafischen Eingabe und Modifikation von Aktivitäten angeboten. Zum Beispiel kann beim Erstellen einer neuen Aktivität das taktische Symbol des Akteurs aus der aktuellen Lagedarstellung (z. B. via einer Zwischenablage) an die entsprechende Stelle in der Aktivitätsanzeige kopiert werden. Nachdem der Auftragstyp festgelegt wurde, werden in der Aktivitätsanzeige die noch zu bestimmenden Bestandteile des Auftrags (z. B. Ränder, Zeitmarken etc.) symbolisch reduziert dargestellt. Der Nutzer kann nun sukzessive die Bestandteile des Auftrags bestimmen, indem er für jeden Bestandteil dessen Darstellung mit einem räumlichen Element im Gesamtbild assoziiert. Analog können neu erzeugte Aktivitäten mit einem Zeitintervall in der Zeittafel verknüpft werden. Abschließend sei darauf hingewiesen, dass die hier skizzierte Benutzeroberfläche in komplexer Wechselwirkung mit anderen Komponenten eines Gesamtsystems zur

162

M. Spielmann

Führungsunterstützung stehen muss. Beispielsweise werden für die Erzeugung der georeferenzierten Anzeige originäre Funktionalitäten eines militärischen Geoinformationssystems benötigt. Dazu gehören sowohl Funktionalitäten für die Darstellung von Karten, von militärischen Symbolen und von Grafiken als auch Funktionalitäten für das Anlegen von Verweisen auf Geobasisdaten (z. B. bei der Eingabe räumlicher Koordinierungselemente). Darüber hinaus werden Funktionalitäten von Systemen zur Erzeugung des Gemeinsamen Rollenorientierten Einsatzlagebildes (GREL) benötigt, z. B. um Daten des Ist-Zustands als Ausgangspunkt für eine Planung bereitzustellen. Außerdem sollte die Einbindung weiterer externer Funktionalitäten wie z. B. „Logistik“, „Sanitätsdienst“, „Aufklärung“ etc. angestrebt werden.

11.4 Ebenenübergreifende Befehlsgebung Der Mehrwert einer weiterführenden Strukturierung von Führungsinformationen (wie z. B. der hier beschriebenen maschineninterpretierbaren Operationsskizzen) wird insbesondere dann sichtbar, wenn alle an einer Operation beteiligten Elemente ihre Führungsinformationen in einem Verbund von IT-Systemen verarbeiten und wenn alle dort angebundenen Systeme die weiterführende Strukturierung durchgängig unterstützen. In diesem Fall stellt sich der Mehrwert wie folgt dar: 1. Effiziente Abwicklung von Geschäftsprozessen zwischen Elementen: Bei der Übertragung von Führungsinformationen von einem Element zu einem anderen muss das empfangende Element eingehende Informationen in der Regel zunächst interpretieren und dann ggf. für die eigenen Zwecke aufbereiten und in die eigene Datenhaltung einpflegen. Dies ist umso zeitintensiver und fehleranfälliger, je geringer der Strukturierungsgrad der übertragenen Führungsinformationen ist. Bei einem hohen Strukturierungsgrad lassen sich diese Schritte informationstechnisch besser unterstützen bzw. automatisieren, wodurch eine effizientere Abwicklung der Geschäftsprozesse zwischen den Elementen möglich wird. 2. Höherwertige Konsistenzprüfungen: Unterstützen alle angebundenen Systeme die weiterführende Strukturierung von Führungsinformationen, so lassen sich elektronische Querbezüge zwischen den Führungsinformationen verschiedener Elemente herstellen, entweder automatisch im Hintergrund oder teilautomatisch mit Unterstützung einzelner Elemente. Plant beispielsweise ein Element eine Aktion (z. B. die Verlegung eines Truppenteils von A nach B) und ein anderes Element, welches keine Kenntnis von dieser Planung hat, beobachtet ein Ereignis, welches die Planung in Frage stellen könnte (z. B. verdächtige Aktivitäten im Bereich der Wegstrecke von A nach B), so können die IT-Systeme der beiden Elemente die vorliegenden Informationen im Hintergrund abgleichen, mögliche Widersprüche zwischen Planung und aktueller Lage feststellen und ggf. einen Warnhinweis ausgeben. 3. Überblick über die Gesamtplanung: Umfasst die weiterführende Strukturierung auch Planungen oder Planungsanteile, so kann aus den im Gesamtsystem vorlie-

11 Grafische Aktionsplanung

163

genden Führungsinformationen unter Umständen eine Gesamtplanung generiert werden, in der die Planungen oder Planungsanteile der verschiedenen Elemente eingebettet bzw. fusioniert sind. Das eröffnet zusätzlich die Möglichkeit für Konsistenzprüfungen auf der Planungsebene (Ist die Gesamtplanung mit dem geplanten Vorgehen bzw. der vorgegebenen Strategie konform?). Der Mehrwert der in diesem Beitrag vorgeschlagenen Strukturierungsmaßnahme lässt sich am Beispiel der ebenenübergreifenden Befehlsgebung des Heeres verdeutlichen: Wie bereits angedeutet (vgl. den letzten Absatz von Abschn. 11.2), kann die hier vorgestellte Strukturierung von Operationsskizzen zu einer Strukturierung von Operationsbefehlen erweitert werden. Die Befehle des resultierenden Befehlsformats sind im folgenden Sinne maschineninterpretierbar: Die Grafikanteile eines solchen Befehls haben Strukturierungsgrad (2), d. h. die in den Operationsskizzen vorkommenden Entitäten und Planungsaspekte sind systemintern mittels Metadaten explizit hinterlegt und lassen sich von einem IT-System auswerten bzw. mit entsprechenden Geschäftsobjekten in der Datenhaltung verbinden. Die in den Befehlen enthaltenen Textanteile (z. B. für die Beschreibung der Intention des Befehlsgebers) sind teilformatiert und haben Strukturierungsgrad (1), d. h. die in den Texten erwähnten Entitäten sind ebenfalls systemintern mittels Metadaten explizit hinterlegt und verweisen ggf. auf bereits im Grafikanteil vorkommende Entitäten. Es folgt eine kurze Darstellung einer möglichen Nutzung maschineninterpretierbarer Operationsbefehle bei der Abwicklung des ebenenübergreifenden Befehlsgebungsprozesses. Dabei lässt sich der oben genannte Mehrwert (1–3) beobachten. Um eine durchgängige Strukturierung zu gewährleisten, wird das neue Befehlsformat sowohl bei der Befehlserstellung als auch bei der Befehlsübermittlung auf bzw. zwischen allen Führungsebenen verwendet. Die Erstellung eines neuen Befehls wird, abgesehen von wenigen Spezialfällen, als Verfeinerung (d. h. Detaillierung, Ergänzung, Einbringung eigener Ideen, Anpassung an eigene Vorstellungen etc.) eines bereits existierenden Befehls – in der Regel der Befehl der übergeordneten Führung – verstanden: Aus dem existierenden Befehl lassen sich Entitäten und Planungsanteile in den neuen Befehl einblenden (mittels elektronischer Verweise) und bei Bedarf modifizieren. Durch das Anlegen elektronischer Verweise werden Redundanzen vermieden und spätere Konsistenzprüfungen vereinfacht. Befehle des neuen Befehlsformats lassen sich aufgrund ihres hohen Anteils strukturierter Informationen sehr effizient als Datensätze speichern und übertragen, was insbesondere auf der taktischen Ebene wichtig ist. Die Übertragung kann mittels Datenreplikation geschehen, wodurch eine zeitintensive und fehleranfällige (Wieder-)Eingabe auf der Empfängerseite entfällt. Die grafischen und zum Teil interaktiven Darstellungsmöglichkeiten der neuen Befehle lassen sich für eine schnelle und intuitive Erfassung der in einem Befehl enthaltenen Führungsinformationen nutzen, wodurch sich die Gefahr von Missverständnissen und Fehlinterpretationen reduziert (vgl. Mehrwert 1). Durch eine direkte Anbindung der in den Befehlen vorkommenden Entitäten und Planungsaspekte an die Datenhaltungen anderer Unterstützungssysteme (man denke z. B. an die Bereiche Aufklärung und Logistik) können höherwertige Konsistenzprü-

164

M. Spielmann

fungen realisiert werden, wie z. B. die zeitnahe Ableitung von Bedrohungspotentialen bei geplanten oder laufenden Operationen (vgl. Mehrwert 2). Aufgrund der Tatsache, dass der ebenenübergreifende Befehlsgebungsprozess streng hierarchisch organisiert ist und jedem Truppenteil eine eigene Planungsdomäne zugeordnet ist, können die durch die verschiedenen Truppenteile erstellten Planungen bzw. Planungsanteile nach der Abwicklung des Prozesses für die Erzeugung einer Gesamtplanung genutzt werden (vgl. Mehrwert 3). In dieser Gesamtplanung sind sowohl die verschiedenen Grobplanungen der höheren Führungsebenen wiederzufinden als auch die Detailplanungen auf den unteren Führungsebenen. Eine Realisierung des hier vorgestellten Ansatzes (z. B. in Form eines verteilten FüInfoSys-Services) würde einem Befehlsgeber neue Einblicke in die gesamte Planungslage sowie zusätzliche Konsistenzprüfungen mit Blick auf die beabsichtigte Operationsführung erlauben.

11.5 Zusammenfassung Für eine qualitativ hochwertige Unterstützung von Geschäftsprozessen durch ITSysteme ist der Grad der systeminternen Strukturierung der verarbeiteten Informationen von zentraler Bedeutung. Systeme, welche Informationen in einer hohen Auflösung (z. B. mittels eines feingranularen Datenmodells) speichern und semantische Verknüpfungen zwischen Teilinformationen anlegen, können die zu verarbeitenden Informationen präziser analysieren und nutzerspezifischer aufbereiten. Sind die Systeme zusätzlich semantisch harmonisiert (verwenden diese beispielsweise dasselbe Datenmodell), so lässt sich die Übermittlung von Führungsinformationen zwischen verschiedenen Elementen (Personen, Organisationseinheiten, Truppenteilen etc.) informationstechnisch besser unterstützen bzw. automatisieren, wodurch eine effizientere Abwicklung von elementübergreifenden Geschäftsprozessen möglich wird. Der hier vorgestellte Ansatz zur weiterführenden Strukturierung militärischer Operationsskizzen soll eine Möglichkeit zur besseren Integration von Operationsbefehlen in die IT-Systeme des Heeres aufzeigen. Der Ansatz kann als Ausgangspunkt für die Entwicklung von FüInfoSys-Services zur semantisch durchgängigen Unterstützung des ebenenübergreifenden Befehlsgebungsprozesses dienen (FKIEProjekt „PLATO“, vgl. auch die Kap. 3, 4, 5, 6, 7 und 8). Kern des Ansatzes ist ein Datenmodell zur formalen Repräsentation von Operationsbefehlen in IT-Systemen. Die resultierenden maschineninterpretierbaren Operationsbefehle geben den Systemen Aufschluss über wichtige Aspekte der geplanten Operationsführung. Dadurch werden die Systeme in die Lage versetzt, höherwertige Konsistenzprüfungen automatisch im Hintergrund durchzuführen und den Nutzer ggf. auf mögliche Inkonsistenzen hinzuweisen, entweder bereits während der Planung oder später bei der Durchführung. Darüber hinaus eröffnet sich die Möglichkeit, aus den Einzelplanungen der verschiedenen Führungsebenen eine Gesamtplanung erzeugen zu lassen, mit neuen Einblicken in die gesamte Planungslage.

11 Grafische Aktionsplanung

165

Ein interessanter Ansatzpunkt für weiterführende Untersuchungen ergibt sich bei der Betrachtung von Planungsprozessen im Bereich der Fertigungsplanung. Auch hier lassen sich in bestimmten Bereichen grafische Pläne zur räumlichen und zeitlichen Koordinierung von Fertigungsprozessen einsetzen. Es gilt zu untersuchen, inwieweit eine Übertragung des hier dargestellten Ansatzes möglich ist.

Literaturverzeichnis BMVg (1998). Heeresdienstvorschrift 100/200, Führungsunterstützung im Heer (TF/FU). Hopcroft, J. E., Motwani, R., & Ullman, J. D. (2000). Introduction to Automata Theory, Languages and Computability. Boston: Addison-Wesley, 2nd edition. Spielmann, M. (2007). Befehlsbearbeitung in Führungssystemen unter Nutzung graphischer Elemente. FKIE-Bericht Nr. 138, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg.

Kapitel 12

Multilinguale Textinhaltserschließung auf militärischen Texten Matthias Hecking

12.1 Einleitung Zur Vorbereitung und Durchführung militärischer Einsätze müssen große Mengen von Freiformtexten1 mit dem Ziel bearbeitet werden, die für den Einsatz relevanten Informationen aufzufinden und aufzubereiten. Eines dieser Informationsprodukte sind z. B. länderspezifische Informationen, d. h. Informationen über die Geografie, die Bevölkerungszusammensetzung, das medizinische System, das Klima etc. Diese wichtigen Informationen müssen aus der großen Flut der Texte herausgefunden und einsatzspezifisch aufbereitet werden. Als Quellen dieser Informationen kommen neben den herkömmlichen schriftlichen Quellen das Web, Blogs, militärische Meldungen und andere militärisch relevante Informationskanäle in Frage. Neben der Multimodalität der Quellen spielt die Multilingualität der anfallenden Texte eine große Rolle. So gibt es ca. 6 900 lebende Sprachen (Gordon, 2005). Ein beträchtlicher Teil davon sind Schriftsprachen, die aufgrund der weltweiten Einsätze der Bundeswehr relevant werden können. Z. B. existieren in der Demokratischen Republik Kongo 214 lebende Sprachen und es gibt folgende nationale/offizielle Sprachen: Koongo, Lingala, Luba-Kasai, Congo Swahili und Französisch. Im Zusammenhang mit der Multimodalität tauchen zwei Probleme auf. Erstens kann aus Personal- und/oder Zeitmangel die große Flut an Texten inhaltlich nicht ausgewertet werden. Zweitens können aus Mangel an kompetenten Sprachmittlern nicht alle Texte inhaltlich erschlossen werden, die in selten gelehrten und gesprochenen Sprachen formuliert sind. Hier stellt sich unmittelbar die Frage, welche technologischen Mittel vorhanden sind, um diesen Zustand zumindest abzumildern. Aus den Forschungsbereichen der Computerlinguistik (Carstensen et al., 2004) und der Linguistik sind Konzepte, Methoden und Techniken zur inhaltlichen Analyse verfügbar, die zumindest einen Teil der auftretenden semantischen Phänomene behandeln können. Der nachfolgend verwendete Ansatz der Informationsextraktion (IE) erlaubt die partielle inhaltliche Analyse von Texten. Im Gegensatz zu Ansätzen 1

Freiformtexte sind Texte, die nur wenige Strukturierungen hinsichtlich ihres Inhalts aufweisen.

M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

167

168

M. Hecking

der Klassifikation und des Clusterings sollen in der IE keine groben inhaltlichen Kategorisierungen der Texte vorgenommen werden. Vielmehr ist es das Ziel, Fakten über Tatsachen, Ereignisse und Handlungen zu bestimmen und formal zu repräsentieren. Diese Formalisierung der Bedeutung ist Voraussetzung für die nachfolgende einsatzspezifische Zusammenstellung der automatisch bestimmten Inhalte. Bereits im NATO-Bericht „Potentials of Speech and Language Technology Systems for Military Use: an Application and Technology Oriented Survey“ (Steeneken, 1996) wurde die Notwendigkeit der Erforschung von computerlinguistischen Ansätzen für militärische Zwecke hervorgehoben. Dieser Bericht verweist auf die Verarbeitung der natürlichen Sprache (nicht nur gesprochene, sondern auch geschriebene; zur gesprochenen Sprache s. Kap. 13) als eine kritische Fähigkeit für zukünftige militärische Führungssysteme. Obwohl es sich primär um ein Forschungsthema handelt, gibt es bereits Systeme, die mit (rudimentären) computerlinguistischen Modulen im Einsatz sind bzw. waren, z. B. CommandTalk (Stent et al., 1999), der Phraselator (VoxTec, 2006) oder das IraqComm-System (Precoda et al., 2007), das von den US-Streitkräften im Irak eingesetzt wird. Im Forschungsinstitut für Kommunikation, Informationsverarbeitung und Ergonomie (FKIE) wurde in den letzten Jahren Forschung zur semantischen Analyse militärischer Texte durchgeführt. Die Basis für diese Inhaltserschließung bildet der Ansatz der Informationsextraktion. Es wurden Prototypen und Module für die Verarbeitung militärischer Texte in deutscher (Projekt SOKRATES, Hecking 2004c) und englischer Sprache (Hecking, 2008) und in Dari (Hecking & Schwerdt, 2008) entwickelt. Der nachfolgend vorgestellte ZENON2 -Prototyp führt in der 1. Version eine partielle semantische Analyse englischer Meldungen aus dem KFOR-Einsatz der Bundeswehr mit Hilfe der Informationsextraktion durch (Hecking, 2006b). Das System ist in der Lage, aus vielen englischen Texten relevante Informationen zu Aktionen und Entitäten zu extrahieren, diese analysezielspezifisch zu fusionieren und anzureichern, um sie schließlich grafisch in einem Entitäten-Aktivitäten-Netzwerk zugänglich zu machen. In der 2. Version wurde der Prototyp um Funktionalitäten zur Informationsextraktion für die Sprache Dari (Hecking & Schwerdt, 2008) erweitert. Nachfolgend wird zuerst eine kurze Einführung in das Gebiet der Informationsextraktion gegeben (s. Abschn. 12.2). Im darauffolgenden Abschn. 12.3 wird der multilinguale ZENON-Prototyp ausführlich dargestellt. Im Zuge der Arbeiten am ZENON-Prototypen wurde das KFOR-Korpus erstellt. Das Korpus wird im Anschnitt 12.4 beschrieben. Abschn. 12.5 enthält die Zusammenfassung.

12.2 Informationsextraktion Bei der Informationsextraktion (IE) handelt es sich um einen Ansatz (Appelt & Israel, 1999; Carstensen et al., 2004, S. 502ff) zur Inhaltserschließung auf Freiformtexten aus dem Bereich der Computerlinguistik. Jedes IE-System wird auf einen bestimmten Anwendungsbereich hin entwickelt. Es wird eine flache syntaktische 2

benannt nach: Zenon von Kition, * um 336 v. Chr., † 264 v. Chr., Begründer der Schule der Stoa

12 Multilinguale Textinhaltserschließung auf militärischen Texten

169

Analyse durchgeführt, d. h. nur die für die Anwendung interessanten Teile der Sätze (chunks) werden mit Hilfe kaskadierter endlicher Automaten (Transducer) verarbeitet. Während der IE werden Informationen zum Wer, Was, Wann etc. identifiziert, normalisiert und formal repräsentiert. Durch die Programmierung der Transducer wird explizit gemacht, welche Satzteile erkannt (Wenn-Seite der Grammatikregel) und wie die erkannten Informationen (Dann-Seite der Regel) repräsentiert werden sollen. Im ZENON-System werden für diese Repräsentation typisierte Merkmalsstrukturen (typed feature structures) verwendet. Um ein IE-System aufzubauen, sind sprachliche Ressourcen (z. B. Lexika, Grammatiken, Ontologien, Wortnetze) und entsprechende Analyse-Software notwendig. Die Beschränkung der Textinhaltserschließung auf eine flache Analyse hat den Nachteil, dass möglicherweise nicht alle relevanten Informationen analysiert werden. Der Vorteil ist dagegen eine hohe Analysegeschwindigkeit und die Fähigkeit des IE-Ansatzes, auch grammatikalisch unkorrekte Sätze analysieren zu können. Bei der Programmierung von IE-Systemen wird auf Toolboxen zurückgegriffen. Im ZENON-Projekt wird GATE (General Architecture for Text Engineering; Cunningham et al., 2002) verwendet. GATE ist ein Architekturkonzept zur Integration sprachverarbeitender Funktionalität (z. B. Morphologie, Part-of-Speech-Tagging) und bietet bereits einen großen Vorrat dieser Funktionalitäten. GATE ist als OpenSource-Framework (SDK) angelegt und bietet auch eine grafische Schnittstelle für die Erstellung von IE-Systemen und die Bearbeitung von Texten.

12.3 Das multilinguale ZENON-System Ausgehend von englischen HUMINT-Meldungen aus dem KFOR-Einsatz der Bundeswehr wurde die 1. Version des ZENON-Systems realisiert. Das System ist in der Lage, eine (partielle) Inhaltserschließung auf diesen Meldungen durchzuführen (Hecking, 2003a, 2004a, 2005a, 2006c,a). Unter Einsatz von linguistischen Ressourcen (z. B. Grammatiken, Namenslisten) und ausprogrammierten kaskadierten endlichen Automaten wurde eine flache syntaktische Analyse (Chunk-Parsing) realisiert. Hierbei wurde auf den von GATE gelieferten Verarbeitungsfunktionalitäten (z. B. englische Morphologie) aufgebaut. Die verarbeiteten KFOR-Meldungen haben die Form A MEETS B, A MARRIES C, A SHOOTS B etc. und beinhalten Informationen über Aktivitäten/Ereignisse und involvierte Entitäten (Sammelbegriff für reale und ideelle Gegenstände, Prozesse etc.). Diese Informationen werden anwendungsspezifisch kombiniert (z. B. alle Informationen zu einer Person) und zu einem Entitäten-Aktivitäten-Netzwerk zusammengefasst. Der Analyst kann dieses Netzwerk verwenden, um durch den Inhalt der Meldungen zu navigieren. In der 1. Version des ZENON-Systems werden relevante Informationen über Entitäten und Aktionen/Ereignisse aus Texten extrahiert, die in Englisch verfasst sind. Die Hauptidee der multilingualen Informationsextraktion ist die Extraktion von Informationen über spezifische Entitäten und Aktionen/Ereignisse aus Dokumenten, die in unterschiedlichen Sprachen verfasst sind. Für die Realisierung der multilingualen IE werden Sprachenressourcen und Verarbeitungsfunktionalitäten für jede

170

M. Hecking

genutzte Sprache benötigt. Neben sprachenspezifischen Wörterbüchern, Grammatiken, morphologischen Analysekomponenten etc. muss auch eine Menge gemeinsamer Konzepte (Ontologie) vorhanden sein, auf die sich die Extraktionsergebnisse beziehen. Daher ist auch eine anwendungsspezifische Ontologie notwendig. Die 2. Version des ZENON-Systems berücksichtigt bei der Inhaltserschließung neben englischen Texten auch solche der Sprache Dari. Dari gehört zur iranischen Sprachfamilie, wird in Nord-Afghanistan gesprochen und mit einem modifizierten arabischen Alphabet geschrieben.

12.3.1 Die Architektur des ZENON-Systems In Abb. 12.1 wird die Arbeitsweise des ZENON-Systems dargestellt. In der oberen Hälfte der Abbildung wird die Verarbeitung der englischen Texte visualisiert. Die Named-Entities (z. B. Namen von Personen oder militärischen Einheiten) und Aktionstypen werden ausgehend von Namenslisten (sog. Gazetteer) und sprachenspezifischen Grammatiken bestimmt. In der Inhaltsanalyse werden die Aktionen mit den Named-Entities verknüpft. Hierdurch wird bestimmt, welche Entitäten welche semantische Rolle (z. B. wer ist Subjekt der Handlung) ausfüllen. Das Ergebnis der beiden Verarbeitungsschritte ist die formale Repräsentation der Aktionen, Entitäten

Abb. 12.1 Aufbau des ZENON-Systems

12 Multilinguale Textinhaltserschließung auf militärischen Texten

171

und der Gesamtaussage der Sätze in Form typisierter Merkmalsstrukturen (typed feature structures; Hecking, 2004a). Die formale Ausgabe der Dokumente wird entsprechend den Analyseerfordernissen mit Hilfe von XSLT (Extensible Stylesheet Language Transformations) gefiltert und fusioniert. Danach kann das Ergebnis direkt genutzt werden oder in grafischer Form in einem Entitäten-Aktivitäten-Netzwerk zugänglich gemacht werden. Die grundlegenden Konzepte der Domäne werden in einer anwendungsspezifischen Ontologie beschrieben, die in den Verarbeitungsschritten genutzt wird. In der unteren Hälfte der Abbildung wird die Verarbeitung der Dari-Dokumente illustriert. Äquivalente linguistische Ressourcen und Verarbeitungsfunktionalitäten sind vorhanden. Die Bestimmung der semantischen Rollen der Named-Entities ist z. Zt. nur rudimentär ausgearbeitet. Die formale Repräsentation des Inhalts der DariDokumente kann in den Filterungs- und Fusionierungsprozess eingebracht werden. Hierdurch kommt es zu einer Verbindung extrahierter Inhalte, die aus unterschiedlich sprachlichen Dokumenten stammen. Voraussetzung für diesen Verarbeitungsschritt ist die Verwendung der selben Ontologie, d. h. Named-Entities und Aktionstypen, die in unterschiedlichen Sprachen codiert sind, können nur dann miteinander in Beziehung gesetzt werden, wenn sie während des Extraktionsprozesses auf die selben Konzepte der Ontologie abgebildet werden. In der Dari-Verarbeitungskomponente ist zusätzlich eine Wort-zu-Wort-Übersetzung als rudimentäre Übersetzungshilfe integriert.

12.3.2 Extraktion der Named-Entities Ein wichtiger Schritt bei der Inhaltserschließung ist die Extraktion der domänenund anwendungsspezifischen Named-Entities. Hierzu sind im ZENON-System Namenslisten (Gazetteer) und Grammatiken vorhanden. Ausgehend von den erkannten Namen der Gazetteer werden die komplexeren Named-Entities durch die Grammatiken identifiziert. Für den Dari-Teil des ZENON-Systems liegen mehr als 1 800 Namen vor. Hierbei enthält der Dari-Gazetteer die folgenden Named-Entities-Typen (mit Anzahl der Einträge in Klammern): CITY _ AFGH (28), CITY _ WORLD (126), COUNTRY _ WORLD (171), DAYS (7), FEMALE _ NAMES (708), MALE _ NAMES (829), MONTHS (12), NUMBERS (11), ORDINALS (10), und PROVINCE _ AFGH (34). Für jeden der genannten Namenstypen sind Grammatikregeln zur Erkennung der komplexeren Namen vorhanden (Schwerdt, 2007).

12.3.3 Extraktion der Verbphrasen, Aktionstypen und Satzinhalte Um die extrahierten Entitäten mit den Aktionstypen in Verbindung bringen zu können, müssen zuerst die Verbphrasen analysiert werden. Nachfolgend wird dies für

172

M. Hecking

die Verarbeitung der englischen Texte gezeigt. Die von GATE zur Verfügung gestellten Transducer wurden so erweitert, dass nicht nur finite und nicht-finite Verbphrasen, sondern auch Modalkonstruktionen, Partizipien und spezielle Verbkonstruktionen erkannt werden. Als Beispiel sei auf Abb. 12.2 verwiesen. Die Regel FVGP RE P ER PAS N EG (finite verb group, present perfect, passive, negative) erkennt Verbphrasen wie z. B. „hasn’t been eaten“ (negative present perfect passive). Aus der Regel ist ersichtlich, dass folgende Abfolge zur Anwendung der Regel notwendig ist: „has“ oder „have“, eine Negation, „been“, ein oder mehrere Adverbien und ein Verb im Partizip Perfekt. Sind die genannten Bedingungen erfüllt, wird der rechte Teil der Regel ausgeführt. In diesem Fall Java Code, in dem die formale Repräsentation der erkannten Verbphrase erzeugt wird. Ausgehend von den extrahierten Infinitiven der Verbgruppen können die Aktionstypen identifiziert werden, z. B. von einem der Infinitive „murder“, „kill“, „drown“, „decapitate“, . . . die Aktionsklasse „kill“. Nach der Extraktion der Named-Entities, der Identifikation des Aktionstyps und sonstiger relevanter Satzteile (z. B. Zeit- und Ortsergänzungen) muss bestimmt werden, welche Entität welche semantische Rolle des Aktionstyps (z. B. wer ist Subjekt, wer erleidet die Handlung) ausfüllt. Im ZENON-Projekt werden als Grundlage hierfür die semantischen Frames des FrameNet-Projekts (FrameNet, 2007) genutzt. Semantische Frames sind schematische Repräsentationen von Situationstypen (z. B. Ess-Situation, Informations-Situation) mit Listen von Teilnehmern, Objekten und sonstigen Beschreibungen der modellierten Situation. Diese Beschreibungen heißen Frame-Elemente. In Abb. 12.3 ist als Beispiel das Frame K ILLING abgebildet. Die notwendigen Frame-Elemente sind C AUSE, K ILLER und V ICTIM. Im Beispielsatz füllt „John“ die semantische Rolle K ILLER und „Martha“ die Rolle V ICTIM. Zur Frame-Beschreibung gehören typische syntaktische Realisierungen der FrameElemente. Diese Beispiele, erweitert um Beispiele aus dem KFOR-Korpus, dienten

RULE : FVGP RE P ER PAS N EG //R ECOGNIZES : P RESENT P ERFECT PASSIVE N EGATIVE : // E . G . "hasn’t been eaten" //PATTERN : (has | have) not been VBN //O UTPUT: VG{ ADVERB , INFINITIVE , NEG =’ YES ’, // TENSE =’P RE P ER ’, TYPE =’FVG’, VOICE =’ PASSIVE ’} ( ( {T OKEN . STRING == "has"}| {T OKEN . STRING == "have"} ) (N EGATION ) {T OKEN . STRING == "been"} (A DVS ): ADVERB ) ({T OKEN . CATEGORY == VBN}): VERB ): X ==> {... JAVA CODE . . . } Abb. 12.2 Regel FVGP RE P ER PAS N EG

12 Multilinguale Textinhaltserschließung auf militärischen Texten

173

Semantischer Frame K ILLING : A K ILLER or C AUSE causes the death of the V ICTIM. Notwendige Frame-Elemente: C AUSE, K ILLER , V ICTIM Optionale Frame-Elemente: D EGREE , D EPICTIVE , I NSTRUMENT, M ANNER , M EANS , P LACE , P URPOSE , R EASON , R ESULT, T IME Beispielsatz: [John KILLER ] drowned [Martha V IC TIM ]. Abb. 12.3 Frame K ILLING

als Grundlage für die Konstruktion der Grammatiken, die als Ergebnis die formale Repräsentation der Gesamtaussage des Satzes erzeugen. Äquivalent zur Analyse der englischen Verben wurde eine morphologische Analyse der wichtigsten Verben für das Dari realisiert. Zwei Vollformen-Lexika wurden erstellt. Das erste beinhaltet 39 552 flektierte Vergangenheitsformen der 8 818 Verben des Dari-Deutsch-Wörterbuches. Das zweite Lexikon beinhaltet 6 592 Formen des Partizip Perfekts. Aufgrund der irregulären Bildung der Präsensformen in Dari ist die morphologische Analyse dieser Formen auf die 84 am häufigsten verwendeten Verben beschränkt worden. Die Analyse liefert Informationen über den Wortstamm, den Modus (Indikativ, Konjunktiv, Imperativ), den Numerus, das Tempus, die Negation, das Genus verbi (Aktiv, Passiv) und die Übersetzung des Infinitivs. Zusammengesetzte Zeiten (z. B. Plusquamperfekt) werden ebenfalls erkannt. Die Zuordnung der semantischen Rollen zu den Aktionstypen ist für das Dari z. Zt. in Entwicklung.

12.3.4 Die rudimentäre Dari-Deutsch-Übersetzung Im multilingualen ZENON-System ist für das Dari eine rudimentäre Übersetzungshilfe integriert (Schwerdt, 2007, S. 63ff). Diese Wort-zu-Wort-Übersetzung bzw. Phrasen-zu-Phrasen-Übersetzung (Termsubstitution) liefert eine Rohübersetzung. Für seltene Sprachen oder solche, die nicht in lateinischer Schrift geschrieben sind, hat selbst eine rudimentäre Übersetzung dann einen Sinn, wenn der Analyst dadurch in die Lage versetzt wird, den Inhalt einzelner Dari-Dokumente einschätzen zu können. Nachfolgend kann er dann bei Bedarf eine qualitativ hochwertige Human-Übersetzung beauftragen. Technisch realisiert wurde die Übersetzung durch die Integration eines Vollformenwörterbuchs mit mehr als 48 000 Einträgen über Gazetteer-Listen. Jeder Eintrag enthält die folgenden 16 beschreibenden Attribute (zumeist syntaktische und semantische Informationen): Identifikator, Herkunft, Sachgebiet, deutsche Übersetzung, deutsche Wortart, deutscher Genus, Anzahl der deutschen Wörter, Dari-Lemma, Dari-Numerus, englische Übersetzung, Quelle, Dari-Wortart, Dari-Wortanzahl, DariDialekt, Beschreibung und Häufigkeit. Nicht alle Attribute sind für alle Wörterbucheinträge vorhanden. Die gefundenen Übersetzungen werden als eigenständige Merkmale abgespeichert. Ein Beispiel wird in Abb. 12.4 gezeigt.

174

M. Hecking

Abb. 12.4 Beispiel der Anwendung der Dari-Deutsch-Übersetzungshilfe

12.3.5 Navigation im Bedeutungsraum Wie in Abb. 12.1 verdeutlicht, werden die anwendungsspezifischen Informationen aus englischen und Dari-Texten selektiert und miteinander fusioniert (z. B. alle Informationen über eine bestimmte Person). Hierbei werden die grundlegenden Informationseinheiten über Aktivitäten, Ereignisse und Entitäten über komplexe Filter zusammengebracht. Diese Filter können für jedes Szenario definiert werden. Die Filterfunktionalität ist mit Hilfe von XSLT (Extensible Stylesheet Language Transformation) implementiert worden. Das Ergebnis der Filterung sind ebenfalls XMLcodierte typisierte Merkmalsstrukturen. Die hierbei entstandene formale Struktur spannt den Bedeutungsraum auf. Der Analyst muss in der Lage sein, die relevanten Informationen in diesem Raum möglichst schnell zu erfassen und bei weiterem Interesse auf die zugrundeliegenden Dokumente (einschließlich rudimentäre Übersetzung für Dari-Texte) zugreifen zu können. Hierzu wird in einem ersten Schritt das Entitäten-Aktivitäten-Netzwerk visuell dargestellt (Beispiel s. Abb. 12.5). Eine Navigation in diesem Netz ist möglich.

12.4 Das KFOR-Korpus Bei der Realisierung von inhaltserschließenden Systemen kann die Leistungsfähigkeit der Informationsextraktion quantitativ gemessen werden. Hierzu ist ein Textkorpus notwendig. Dieser besteht aus Texten des betrachteten Anwendungsbereichs ergänzt um Annotationen. Als Beispiel sei der Satz „The bomb did not ignite in the station of Koblenz.“ genannt. Die zusätzliche Information CITY [40, 47, { NAME = KOBLENZ }] bildet die semantische Annotation für die Zeichenkette „Koblenz“, d. h. diese Zeichenkette ist der Name einer Stadt, der Name beginnt ab Position 40 und endet in Position 47.

12 Multilinguale Textinhaltserschließung auf militärischen Texten

175

Abb. 12.5 Bedeutungsraum Location-action

Zur Evaluierung des englischen Anteils des ZENON-Systems wurde ausgehend von realen Meldungen aus dem KFOR-Einsatz der Bundeswehr das KFOR-Korpus (Hecking, 2006b) erstellt. Ausgangspunkt waren 4 498 militärische Meldungen (zumeist in englischer Sprache). 800 dieser Meldungen wurden manuell annotiert und bilden das KFOR-Korpus. Das Korpus umfasst 886 000 Token (Wörter, Ziffernfolgen, Satzzeichen) und enthält die Annotationen in verschiedenen Schichten. Folgende Schichten sind vorhanden:  Original markups: Hier werden die Teile der Meldung annotiert, die bereits formatiert vorliegen. Hierunter finden sich Angaben zu Empfänger, Thema, Quelle etc.  Token: Diese Schicht enthält die Annotationen, die der Tokenizer und der Partof-Speech-Tagger liefern.  Gazetteer: Hier werden die Ausdrücke ausgezeichnet, die über Namenslisten identifiziert wurden.  Sentence: Diese Annotationen verweisen auf Satz- und Kommentargrenzen.  Named-Entities: Hier werden verschiedene Eigennamen (s. Abschn. 12.3.2) ausgezeichnet.  Verbalgruppe: Die im Englischen vorkommenden verbalen Ausdrücke werden gekennzeichnet. In jeder Annotationsschicht sind verschiedene Annotationstypen vorhanden. In der Schicht der Named-Entities sind dies: City, Company, Coordinates, Colour, CountryAdj, Currency, Date, DocumentID, GeneralOrg, MilDateTime, MilitaryOrg, Number, Percent, Person, PoliticalOrg, Province, Region, River, Time, Title. Das KFOR-Korpus mit seinen manuell erstellten Annotationen ist der Maßstab, mit dem die durch die automatische Informationsextraktion erzeugten Annotationen verglichen werden. Die so bestimmten Maßzahlen dokumentieren die Leistungsfähigkeit der Informationsextraktion und geben Hinweise darauf, für welche Annota-

176

M. Hecking

tionstypen die Grammatiken weiter ausgebaut werden müssen. Ein solcher Einsatz des Korpus wird in (Hecking, 2007) gezeigt.

12.5 Zusammenfassung Das in diesem Kapitel vorgestellte ZENON-System ist in der 1. Version in der Lage, eine partielle semantische Analyse englischer Meldungen aus dem KFOREinsatz der Bundeswehr mit Hilfe der Informationsextraktion durchzuführen. Hierbei können aus einer großen Anzahl von Meldungen relevante Informationen zu Aktionen und Entitäten extrahiert und analysezielspezifisch kombiniert werden, um sie schließlich grafisch in einem Entitäten-Aktivitäten-Netzwerk zugänglich zu machen. In der 2. Version wurde das System um Funktionalitäten zur Informationsextraktion für die Sprache Dari erweitert. Die formalen Ergebnisse der Analyse der unterschiedlich sprachlichen Texte können miteinander verbunden werden, so dass der Analyst auch Zugang zu solchen Informationen hat, die in einer von ihm nicht beherrschten Sprache verfasst sind. Im Einzelnen wurde nach der Einführung der Ansatz der Informationsextraktion erläutert. Dann wurde auf das multilinguale ZENON-System näher eingegangen. Der Aufbau, die Extraktion der NamedEntities, die Extraktion der Verbphrasen, Aktionstypen und Satzinhalte, die rudimentäre Dari-Deutsch-Übersetzung und die Navigation im Bedeutungsraum wurden erläutert. Abschließend wurde kurz auf das KFOR-Korpus, das im Zuge des ZENON-Projektes erstellt wurde, eingegangen. Das multilinguale ZENON-System befindet sich in ständiger Weiterentwicklung. So wird an der Erweiterung der Dari-Funktionalität gearbeitet. Speziell soll die Bestimmung der semantischen Rollen realisiert werden. Zusätzlich soll durch die Einbeziehung des Tadschikischen die Verarbeitungsmöglichkeit auf eine dritte Sprache ausgedehnt werden.

Literaturverzeichnis Appelt, D. E. & Israel, D. J. (1999). Introduction to information extraction technology: A tutorial prepared for IJCAI-99. Carstensen, K., Ebert, C., Endriss, C., Jekat, S., & Klabunde, R. (2004). Computerlinguistik und Sprachtechnologie. Eine Einführung. Heidelberg, Berlin: Spektrum Akademischer Verlag, 2nd edition. Cunningham, H., Maynard, D., Bontcheva, K., & Tablan, V. (2002). GATE: A framework and graphical development environment for robust NLP tools and applications. In Proceedings of the 40th Anniversary Meeting of the Association for Computational Linguistics Philadelphia, USA. FrameNet (2007). FrameNet. http://framenet.icsi.berkeley.edu/index.php (14.01.2009). Gordon, R. G., Ed. (2005). Ethnologue: Languages of the World. Intl Academic Bookstore, 15th edition edition.

12 Multilinguale Textinhaltserschließung auf militärischen Texten

177

Hecking, M. (2003a). Analysis of Free-form Battlefield Reports with Shallow Parsing Techniques. In Proceedings of the RTO IST Symposium on ’Military Data and Information Fusion’ Prague, Czech Republic. Hecking, M. (2004a). How to Represent the Content of Free-form Battlefield Reports. In Proceedings of the 2004 Command and Control Research and Technology Symposium San Diego. Hecking, M. (2004c). Informationsextraktion aus militärischen Freitextmeldungen. FKIE-Bericht Nr. 74, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Hecking, M. (2005a). Domänenspezifische Informationsextraktion am Beispiel militärischer Meldungen. In A.B. Cremers, R. Manthey, P. Martini, V. Steinhage (Hrsg.) INFORMATIK 2005, Band 2, Lecture Notes in Informatics, Volume P-68. Hecking, M. (2006a). Content Analysis of HUMINT Reports. In Proc. of the 2006 Command and Control Research and Technology Symposium (CCRTS) ’The State of the Art and the State of the Practice’ San Diego, California. Hecking, M. (2006b). Das KFOR-Korpus als Ergebnis semantisch annotierter militärischer Meldungen. FKIE-Bericht Nr. 124, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Hecking, M. (2006c). Navigation through the Meaning Space of HUMINT Reports. In Proceedings of the 11th International Command and Control Research and Technolgy Symposium Cambridge, UK. Hecking, M. (2007). The KFOR Text Corpus. In Proceedings of the 12th International Command and Control Research and Technolgy Symposium (ICCRTS) Newport, USA. Hecking, M. (2008). System ZENON – Semantic Analysis of Intelligence Reports. In Proceedings of the LangTech 2008 Rome, Italy. Hecking, M. & Schwerdt, C. (2008). Multilingual Information Extraction for Intelligence Purposes. In Proceedings of the 13th International Command and Control Research and Technolgy Symposium (ICCRTS) Bellevue, WA, USA. Precoda, K., Zheng, J., Vergyri, D., Franco, H., Richey, C., Kathol, A., & Kajarekar, S. (2007). IraqComm: A Next Generation Translation System. In INTERSPEECH-2007 (pp. 2841–2844). Schwerdt, C. (2007). Analyse ausgewählter Verbalgruppen der Sprache Dari zur multilingualen Erweiterung des ZENON-Systems. FKIE-Bericht Nr. 146, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Steeneken, H. J. M. (1996). Potentials of Speech and Language Technology Systems for Military Use: an Application and Technology Oriented Survey. Technical Report AC/243(Panel 3)TP/21, NATO. Stent, A., Dowding, J., Gawron, J. M., Bratt, E. O., & Moore, R. (1999). The CommandTalk Spoken Dialogue System. In Proc. of the 37th Annual Meeting of the ACL (pp. 183–190). University of Maryland, College Park, MD: ACL. VoxTec (2006). The phraselator P2. http://www.phraselator.com/products.htm (14.01.2009).

Kapitel 13

Sprachverarbeitung militärisch relevanter Audiodaten Corinna Harwardt

13.1 Einleitung Um ausreichend Informationen zur Generierung eines umfassenden Lagebilds zur Sicherung der Führungsfähigkeit bereitstellen zu können, müssen alle verfügbaren Informationsquellen genutzt werden. Eine wichtige Informationsquelle sind Audiodaten. Bei militärisch relevanten Daten aus der Aufklärung oder anderen Quellen, wie beispielsweise dem Internet, handelt es sich meistens um große Datenaufkommen, die nicht komplett manuell erfassbar und verarbeitbar sind. Der Einsatz sprachverarbeitender Systeme kann zur Selektion wichtiger Audiodateien genutzt werden und damit der Entlastung der vorhandenen Bearbeiter dienen. Verschiedene Formen sprachverarbeitender Systeme können eine Kategorisierung der Audiodateien leisten, welche ohne diese Systeme manuell erfolgen müsste. Die Anzahl der bearbeiteten Daten kann somit schon durch automatische Kategorisierungen wie die Zuordnung der Landessprache oder die Sortierung nach Sprechern gesteigert werden. Systeme, die eine komplette oder partielle Verschriftung liefern, können bei entsprechender Leistungsfähigkeit, die Grundlage für eine automatische Inhaltserschließung bilden (siehe Kap. 12). Die Verarbeitung gesprochener Sprache beschäftigt sich mit der Informationsgewinnung aus Audiodaten. Das Ziel der Informationsgewinnung kann sehr unterschiedlich sein. Dies schlägt sich in verschiedenen Applikationen der Verarbeitung gesprochener Sprache nieder. In diesem Kapitel werden verschiedene dieser Applikationen sowie ihre Relevanz als Assistenzsystem in Führungsinformationssystemen erläutert. Im Folgenden wird zunächst der Begriff Sprachverarbeitung eingeführt, um dann einen Überblick über bisherige Arbeiten im Bereich der Sprachverarbeitung im militärischen Kontext zu geben. Anschließend werden die Applikationen Spracherkennung, Landessprachenerkennung und Sprechererkennung näher erläutert. Ein besonderer Fokus wird auf den Anwendungsbereich automatische Sprechererkennung gelegt. Es werden der Stand der Technik und die Leistungsfähigkeit einzelner Sprechererkennungssysteme auf militärisch relevanten Audiodaten dargestellt. M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

179

180

C. Harwardt

13.2 Verarbeitung gesprochener Sprache Der Begriff Sprachverarbeitung kann auf vielfältige Art und Weise definiert werden. Er kann sich sowohl auf die geschriebene als auch auf die gesprochene Sprache beziehen. In diesem Kapitel wird Sprachverarbeitung als Sammelbegriff für die Verarbeitung gesprochener Sprache im Sinne des englischen Speech Processing verwendet. Die Verarbeitung gesprochener Sprache kann, wie in (Schukat-Talamazzini, 1995), als die Manipulation digitaler Repräsentationen von Signalformen sprachlicher Äußerungen, mit dem Fokus auf deren Analyse und Synthese, definiert werden. Für den Einsatz von Sprachverarbeitung im militärischen Kontext ist die Sprachsynthese weniger dringlich, so dass im Folgenden mit Sprachverarbeitung die Analyse gesprochener Sprache bezeichnet wird. Unter Applikationen zur Analyse von Audiosignalen können Anwendungen mit dem Fokus auf die Informationsgewinnung hinsichtlich des Inhalts, des Sprechers bzw. Sprechermerkmale, der Sprache oder der Signalcharakteristika zusammengefasst werden. Als Hauptanwendung zur Inhaltsanalyse ist die Spracherkennung zu nennen. Spracherkennung ist hierbei als Prozess zu verstehen, durch den ein akustisches Signal in Form einer sprachlichen Äußerung als Wortfolge dargestellt wird. Weitere Möglichkeiten zur Analyse gesprochener Sprache bieten Applikationen wie Schlüsselworterkennung, Themenerkennung, Landessprachenerkennung, Sprechererkennung, Sprechersegmentierung, Detektion von Störgeräuschen, Sprach-Pause-Detektion, Geschlechts- und Emotionserkennung. Eine für stark gestörte Signale, wie sie im militärischen Umfeld häufig zu finden sind, interessante Form der Manipulation von Audiosignalen ist die Sprachverbesserung.

13.3 Darstellung relevanter Sprachverarbeitungstechnologien für militärische Anwendungsbereiche Sprachverarbeitungstechnologien können im militärischen Kontext in verschiedensten Anwendungsbereichen eingesetzt werden. Die Aufgabenbereiche können grob in Kommando- bzw. Eingabesysteme, sicherheitsüberprüfende und Aufklärungssysteme unterteilt werden. Spracherkennung kann beispielsweise zur Unterstützung der Steuerung von Fahrzeugen, zur Verschriftung von Aufklärungsdaten oder in einem mobilen Computer zur komfortablen Eingabe per Sprache auf dem Gefechtsfeld genutzt werden. Sprechererkennung kann in sicherheitsrelevanten Bereichen als Zugangskontrolle oder zur Identifikation bestimmter Sprecher in großen Audiomengen verwendet werden. Die Landessprachenerkennung ermöglicht eine Vorsortierung von Audiomaterialien, so dass jedes Audiosignal einem Spracherkenner oder einem Bearbeiter bzw. Übersetzer der richtigen Landessprache zugeordnet werden kann. Diese verschiedenen Einsatzbereiche sind meist durch Audiosignale verschiedenster, meist sehr schlechter Qualität charakterisiert. Es ist ratsam, sprachverar-

13 Sprachverarbeitung gesprochener Sprache

181

beitende Systeme speziell für den einzelnen Einsatzbereich zu erstellen oder zu adaptieren, da gebräuchliche Standardsysteme häufig nicht zu den gewünschten Ergebnissen führen. Als Beispieluntersuchung hierzu ist (Harwardt, 2007) zu nennen. Hier wurde ein kommerziell erhältlicher, nicht adaptierter Spracherkenner auf militärisch relevanten Funksprüchen, welche in einem Gefechtsfahrzeug aufgenommen worden waren, getestet. Die Ergebnisse mit dem Standardsystem waren nicht zufriedenstellend. Eine Adaption des Systems auf die gegebene Signalqualität ist demnach unumgänglich. Um eine solche Adaption möglich zu machen, müssen den Entwicklern einsatznahe Daten zur Verfügung gestellt werden. Dies stellt auf Grund der Sicherheitsbestimmungen häufig ein Problem dar. Aus diesem Grund ist die Forschung für Sprachverarbeitung militärisch relevanter Signale leider noch immer ein sehr herausfordernder und zu wenig erforschter Bereich. Um diesen Missstand zu ändern, wurde ein für Forschungszwecke frei erhältliches Korpus von Audiodaten der militärischen Luftverkehrskommunikation erstellt (nnMATC Korpus: siehe Pigeon et al. (2007)). Das Korpus ist für die Entwicklung von Spracherkennungssystemen mit dem Schwerpunkt Spracherkennung von Nicht-Muttersprachlern für das Englische, Schlüsselworterkennung (Erkennung der Rufzeichen) und Sprechersegmentierung geeignet. Ein Korpus, das für Sprechererkennung im militärischen Kontext genutzt werden kann, ist das NATO N4 Korpus (Benarousse et al., 2003). Eine Institution, die Forschungsarbeiten im Bereich militärischer Sprachverarbeitung veröffentlicht, ist die NATO Research and Technology Organisation (RTO), die in ihren Berichten (Benarousse et al., 2003 und Pigeon et al., 2005) sowohl einen guten Überblick über die Einsatzbereiche von Sprachtechnologie für militärische Applikationen bietet als auch den derzeitigen Stand der Technik verschiedener Sprachverarbeitungstechnologien beleuchtet. Ein Überblick über den derzeitigen Stand der Technik in der Spracherkennung militärischer Signale, der Landessprachenerkennung und der Sprechererkennung wird in den folgenden Unterabschnitten gegeben.

13.3.1 Spracherkennung Spracherkennung befasst sich mit der Transformation eines unbekannten akustischen Signals in eine geschriebene Wortfolge. Als eine der ersten größeren Untersuchungen zur Spracherkennung ist das vom amerikanischen Verteidigungsministerium finanzierte ARPA (Advanced Research Projects Agency) Speech Understanding Project zu nennen. Ein Überblick über die im Rahmen dieses Projekts entstandenen vier Spracherkenner wird in (Klatt, 1977) gegeben. Vom deutschen Verteidigungsministerium wurde bereits in den 60er Jahren ein Projekt zur Worterkennung finanziert. Das hierbei entstandene DAWID-System wurde am IPK (Institut für Phonetik und Kommunikationsforschung) der Universität Bonn entwickelt. Hierbei handelt es sich um einen ersten Worterkenner, der noch nicht speziell für militärische Einsatzdaten geeignet war und der ein Vokabular von lediglich 20 Wörtern umfasste (Glave, 1974).

182

C. Harwardt

Die Hauptaktivitäten der Forschung für Spracherkennung im militärischen Kontext, die in der Literatur beschrieben werden, stammen aus der Luftfahrt. Ein gutes Beispiel für den Einsatz von Spracherkennungstechnologie in der Luftfahrt ist das Direct Voice Input (DVI) System im Eurofighter (Eurofighter GmbH, 2008). Eine Arbeit die, ganz eindeutig die Notwendigkeit der Spezialisierung der sprachverarbeitenden Systeme auf die spezifische Aufgabe zeigt, ist (Englund, 2004). Sie verdeutlicht, dass Spracherkennung in einem Flugzeug mit wechselnden Bedingungen und teilweise hohen G-Belastungen (bis zu 8G) nur durch Adaption des Spracherkenners auf die akustischen Gegebenheiten zu verwertbaren Ergebnissen führt. Wird eine solche Adaption durchgeführt, so kann die Erkennungsleistung des Systems um bis zu 50% verbessert werden. Ein weiterer Anwendungsbereich der Spracherkennung ist die Steuerung von teilautonomen Robotern, wie sie in (Ahluwalia, 2008) beschrieben wird. Bei dieser Aufgabenstellung ist besonders der Einsatz in Außenumgebungen interessant, da im realen Einsatz keine Spracherkennung ohne Hintergrundgeräusche oder Störungen möglich ist. Der Einfluss verschiedener Außengeräusche inklusive Gefechtslärm wie z. B. Maschinengewehrgeräusche wurde in (Ahluwalia, 2008) untersucht. Wie aus den oben beschriebenen Beispielen ersichtlich ist, wird bei Spracherkennungsaufgaben im militärischen Bereich häufig keine komplette Verschriftung von Audiodaten mit unbegrenztem bzw. sehr großem Vokabular angestrebt. Stattdessen werden solche Aufgaben für die Spracherkennung gewählt, die ein begrenztes Vokabular bzw. eine begrenzte Domäne (z. B. Reiseplanung, Sport, Gefechtsfeld...) umfassen, da sie leichter zu guten oder zumindest zufriedenstellenden Ergebnissen führen. Möchte man für eine Aufgabe mit unbegrenzter Domäne automatische Verfahren zur Verschriftung verwenden, so gibt es die Möglichkeit, auf die automatische Schlüsselworterkennung auszuweichen. Statt das komplette Signal zu transkribieren, wird hier nur nach bestimmten Schlüsselwörtern im Audiomaterial gesucht. Dies empfiehlt sich besonders dann, wenn man möglichst schnell ein unterstützendes Sprachverarbeitungssystem für eine Sprache mit wenig sprachlichen Ressourcen benötigt. Der größte Vorteil der Schlüsselworterkennung ist, dass der enorme Arbeitsaufwand, der für die Erstellung eines Spracherkenners mit großem Vokabular notwendig ist, bei der automatischen Schlüsselworterkennung stark reduziert ist. Auf diese Weise kann mit deutlich weniger Aufwand eine partielle Analyse des Signals für große Audiomengen neuer Einsatzsprachen realisiert werden.

13.3.2 Landessprachenerkennung Landessprachenerkennung befasst sich mit der Klassifikation eines Sprachsignals hinsichtlich der gesprochenen Landessprache. Ein möglicher Einsatzbereich von Landessprachenerkennung im militärischen Kontext kann beispielsweise die Unterscheidung zwischen Englisch und der jeweiligen Muttersprache von Piloten sein, wie es für das Spanische von (Fernández et al., 2004) beschrieben wird. Diese Unterscheidung liefert die Basis für die Weiterverarbeitung der Spracheingabe mit einem

13 Sprachverarbeitung gesprochener Sprache

183

Spracherkenner. Weiterhin ist es denkbar, Landessprachenerkennung zur Vorverarbeitung auf zur Übersetzung ausstehenden Audiodaten der Aufklärung anzuwenden. Die Landessprachenerkennung führt in diesem Fall eine Zuordnung der Signale zum richtigen Übersetzer durch, ohne dabei menschliche Ressourcen nutzen zu müssen. Systeme zur automatischen Landessprachenerkennung können auf unterschiedlichste Weise realisiert werden. Zu den momentan verwendeten Standardtechniken zählen Gauß’sche Mischverteilungsmodelle (Gaussian mixture model, GMM), die Stützvektormethode (Support Vector Machine, SVM) und die parallele Phonemerkennung mit anschließender Erstellung von Sprachmodellen (Parallel Phone Recognition and Language Modeling, PPRLM). Bei der Modellierung der verschiedenen Landessprachen mit GMMs werden Merkmale extrahiert, die sich auf die akustischen Eigenschaften der Landessprache beziehen. Es handelt sich also um einen akustisch basierten Ansatz. Nutzung einer SVM bedeutet, die Trainingsdaten als Vektor in einem Vektorraum darzustellen und die Daten der verschiedenen Klassen durch mehrdimensionale Hyperebenen voneinander abzugrenzen. Die Testdaten werden dann den verschiedenen Klassen zugeordnet. Die SVM ist ein so genannter diskriminativer Ansatz. PPRLM ist eine Technik, bei der zunächst mit Hilfe mehrerer Phonemerkenner Transkriptionen auf Phonebene für die Audiodaten erstellt werden, welche dann für die Erstellung von Sprachmodellen (Language Models, LMs) verwendet werden. Mit Hilfe der LMs und der Transkriptionen der Testdaten können die Testdaten den verschiedenen Sprachmodellen zugeordnet bzw. Wahrscheinlichkeiten für die Zugehörigkeit zu verschiedenen Sprachmodellen bestimmt werden. Die Ausgaben, die mit den einzelnen Phonemerkennern erzielt werden, müssen abschließend zu einer Punktzahl zusammengefasst werden. Die PPRLM Methode ist linguistisch motiviert, da linguistische Einheiten (Phoneme) und deren Kombination (Phonotaktik) für die Klassifikation genutzt werden. Als besonders erfolgreich haben sich fusionierte Systeme bestehend aus mehreren Einzelsystemen gezeigt. Der Grund hierfür ist, dass bei fusionierten Systemen Informationen verschiedener Art kombiniert werden. Zum Beispiel kann die Kombination eines GMM Klassifikators mit einem PPRLM System sehr sinnvoll sein, da hier sowohl akustische als auch linguistische Informationen genutzt werden. Die Umsetzung dreier Landessprachenerkenner mit den drei oben genannten Methoden (GMM, SVM, PPRLM) sowie die Leistung eines daraus fusionierten Systems werden in (Singer et al., 2003) beschrieben. Wie zu erwarten, liefert das fusionierte System in fast allen Tests die besten Ergebnisse. Um die Leistungsfähigkeit von Landessprachenerkennungssystemen zu messen und die Forschung in diesem Bereich weiter voranzutreiben, führt das National Institute of Standards and Technology (NIST) circa alle zwei Jahre eine Evaluation durch, an der jedes Landessprachenerkennungssystem teilnehmen kann. Dieses Angebot wird von Forschungseinrichtungen und Firmen auf der ganzen Welt genutzt. Die Ergebnisse werden in anonymisierter Form auf der NIST Webseite (NIST, 2008) veröffentlicht. Bei den Sprachdaten, die für diese Evaluationen verwendet werden, handelt es sich um Telefonsprache. Eine Vorhersage der Leistung der in den NIST Evaluationen getesteten Landessprachenerkenner im militärischen Kontext ist nicht ohne weiteres möglich. Deswegen wurde eine solche Evaluation am

184

C. Harwardt

Forschungsinstitut für Kommunikation, Informationsverarbeitung und Ergonomie (FKIE) mit militärischen Einsatzdaten, sowohl für die Landessprachen- als auch für die Sprechererkennung, durchgeführt. Die Ergebnisse dieser Evaluation (FKIE Evaluation) sind in (Harwardt et al., 2008) nachzulesen. Allgemein lässt sich festhalten, dass die Leistung der Systeme auf militärisch relevanten Daten insgesamt tendenziell schlechter ist als die Leistung der an der NIST Evaluation teilnehmenden Systeme. Da zwei Systeme an beiden Evaluationen teilnahmen und beide Systeme bei der NIST Evaluation bessere Leistung erbrachten als bei der FKIE Evaluation, kann daraus geschlossen werden, dass eine zuverlässige Landessprachenerkennung für militärisch relevante Audiosignale der weiteren Entwicklung bedarf. Um dies optimal durchführen zu können, müssen den Entwicklern einsatznahe Daten zur Verfügung gestellt werden.

13.3.3 Sprechererkennung Als automatische Sprechererkennung bezeichnet man den Prozess, ein unbekanntes Sprachsignal hinsichtlich des Sprechers zu analysieren. Die Aufgaben der Sprechererkennung können grob in zwei Bereiche unterteilt werden: die textabhängige und die textunabhängige Sprechererkennung. Textabhängige Sprechererkennung deckt Aufgaben wie z. B. die Zugangskontrolle ab, bei der ein kooperativer Sprecher mit dem System interagiert. In diesem Fall wird ein vorgegebener Text abgelesen oder ein dem System bekanntes Passwort oder ein Satz gesprochen. Die Erkennungsraten sind für solche Systeme in der Regel höher als für textunabhängige Systeme. Die Aufgabe ist bzgl. des Anwendungsbereichs jedoch auch sehr viel eingeschränkter. Die textunabhängige Sprechererkennung ist für die Analyse von Sprachsignalen nicht kooperativer Sprecher gedacht. Das Trainings- und das Testsignal müssen nicht die gleiche sprachliche Äußerung enthalten. Dadurch ist ein solches System flexibel in verschiedensten Anwendungsbereichen einsetzbar, es ergeben sich aber auch viele Schwierigkeiten, die bei textabhängigen Systemen auf Grund des Anwendungsbereichs nicht oder nur in Maßen auftreten (z. B. Schwierigkeiten bei verschiedenen Aufnahmekanälen). Die Auswirkungen verschiedener Kanalcharakteristika auf die Erkennungsergebnisse, erzielt mit verschiedenen Merkmalen der Vorverarbeitung, werden in (von Zeddelmann, 2008) untersucht. Die Anwendungsmöglichkeiten der Sprechererkennung im militärischen Kontext sind sehr vielfältig. Zunächst wäre eine relativ einfache Anwendung wie die Zugangskontrolle für zugangsbeschränkte Bereiche oder Informationen denkbar. Weiterhin könnte die Sprechererkennung zur Suche bestimmter Sprecher in einem vorhandenen Datenpool genutzt werden. Auf diese Weise könnte Sprechererkennung im Rahmen der Terrorbekämpfung genutzt werden.

13 Sprachverarbeitung gesprochener Sprache

185

13.4 Sprechererkennungstechnologie als Assistenzsystem in Führungsinformationssystemen Zur Vervollständigung der Feindlage in einem Führungsinformationssystem ist es von Vorteil, möglichst viele Informationskanäle zu nutzen. Ein möglicher Informationsfluss kann die Analyse von Audiodateien sein. Die gezielte Suche nach Sprachsignalen ausgewählter Sprecher bzw. die Zuordnung mehrerer Sprachsignale zu einem Sprecher kann wichtige Zusatzinformationen liefern. Für eine solche Informationsgewinnung ist ein textunabhängiges Sprechererkennungssystem zu verwenden. In den folgenden Unterabschnitten werden zunächst der Aufbau eines Sprechererkennungssystems und die gängigen Techniken der textunabhängigen Sprechererkennung erläutert. Abschließend wird die Konzeption eines auf Standardverfahren basierenden Forschungsprototypen kurz dargestellt. Die Ergebnisse eines Tests dieses Prototyps auf militärisch relevanten Daten werden präsentiert und mit den Ergebnissen von Systemen verglichen, welche im Jahr 2007 für die FKIE Evaluation bereitgestellt wurden.

13.4.1 Aufbau eines Sprechererkennungssystems Um die gängigen Techniken der Sprechererkennung darstellen zu können, muss zunächst der Aufbau eines Sprechererkenners beschrieben werden. Der Aufbau eines typischen Sprechererkennungssystems wird in Abb. 13.1 dargestellt. Hierbei wird zunächst zwischen der Trainings- und der Testphase unterschieden. Die Trainingsphase umfasst die Merkmalsextraktion, das Training eines Hintergrundmodells und der Sprechermodelle sowie das Zusammenstellen eines Klassifikators aus den trainierten Modellen. Die Merkmalsextraktion ist ein Verfahren, das die zu trainierenden Sprachsignale in eine Sequenz von Merkmalsvektoren transformiert. Diese Merkmalsvektoren werden für das Training der Modelle benötigt. Verschiedene Verfahren der Merkmalsextraktion werden in dem Unterabschn. 13.4.2 erläutert. Ein Hintergrundmodell (Universal Background Model, UBM), auch Weltmodell genannt, ist ein Modell, welches das sprachliche Verhalten einer Sprecherpopulation abbildet. Es dient der Überprüfung der These, dass es sich bei dem getesteten Sprachsignal nicht um den bzw. einen der Referenzsprecher handelt. Die ausgewählte Population und die Qualität der Audiodaten sollte den Gegebenheiten der Signale im späteren Erkennungsprozess möglichst ähnlich sein. Eine interessierende Population könnte beispielsweise folgende sein: deutschsprachige, männliche Sprecher zwischen 20 und 40 Jahren, Telefonsprache. Das UBM wird mit Daten möglichst vieler verschiedener Sprecher der interessierenden Population trainiert. Lässt sich die Population für die spätere Verwendung des Systems nicht einschränken, so müssen möglichst vielfältige Daten verwendet werden. Die Vielfältigkeit bezieht sich auf die Anzahl der Sprecher sowie auf Signalcharakteristika wie z. B. das Geschlecht, die Kanalcharak-

186

C. Harwardt

Trainingsphase

UBM Training Merkmalsextraktion

Klassifikator Sprechermodelladaption

Testphase

A U Merkmalsextraktion

Klassifikator

Normalisierung

S G A B E

Abb. 13.1 Typischer Aufbau eines Sprechererkennungssystems

teristika, die Landessprache, das Alter usw. Außerdem sollte der Umfang der Daten der verschiedenen Charakteristika ähnlich sein. Als Sprechermodelle werden die Modelle bezeichnet, die mit den Daten der zu klassifizierenden Referenzsprecher trainiert wurden. Sie dienen der Überprüfung der These, dass es sich bei dem getesteten Sprachsignal um den bzw. einen der Referenzsprecher handelt. Für das Training eines Sprechermodells wird das UBM als Grundlage verwendet; hiervon wird per Adaptionsverfahren ein auf den Sprecher zugeschnittenes Modell adaptiert. Als Adaptionstechnik wird häufig der maximum a posteriori Ansatz (MAP) verwendet (Reynolds & Campbell, 2008). Der Klassifikator ist der Teil des Systems, der die Einteilung in Klassen vornimmt. Wie viele Klassen vorhanden sind, ist von der Aufgabe des Sprechererkennungssystems abhängig. Man kann zwischen zwei Hauptaufgabenbereichen unterscheiden, der Identifikation und der Verifikation. Bei einer Identifikation wird ein Sprachsignal gegen mehrere Sprechermodelle getestet. Die Fragestellung lautet: Um welchen der interessierenden Sprecher handelt es sich? Eine Rückweisung, also die Aussage, dass es sich um keinen dieser Sprecher handelt, ist je nach Systemkonzeption ebenfalls möglich. Systeme, die eine solche Rückweisung erlauben, werden open-set Systeme genannt. Systeme, die lediglich eine Zuordnung zu einem der trainierten Sprecher vornehmen, ohne eine Rückweisung zuzulassen, werden closed-set Systeme genannt. Die Verifikation dagegen prüft jedes Sprachsignal nur gegen ein Sprechermodell. Die Leitfrage lautet hier: Handelt es sich um den fraglichen Sprecher oder nicht?

13 Sprachverarbeitung gesprochener Sprache

187

In der Testphase werden die Merkmale der fraglichen Sprachsignale extrahiert und gegen die vorhandenen Modelle getestet. Anschließend werden die von den Modellen generierten Punktzahlen normalisiert. Je nach Art des Systems wird dann entweder eine Aussage bezüglich der Sprecheridentität getroffen, oder es wird eine Punktzahl ausgegeben, die angibt, mit welcher Wahrscheinlichkeit es sich um einen bestimmten Sprecher handelt. Möglich ist auch die Ausgabe der Entscheidung und der Punktzahl. Die Ausgabe der Punktzahlen ist wichtig, um ein System an neue Korpora anpassen und evaluieren zu können.

13.4.2 Gängige Techniken der Sprechererkennung In diesem Abschnitt werden einige der momentan gängigen Techniken der Merkmalsextraktion, und der Modellierung (für Hintergrund- und Sprechermodelle) sowie die zugehörige Vertiefungsliteratur vorgestellt. In der Merkmalsextraktion werden sehr häufig durch Kurzzeitanalyse gewonnene spektrale Merkmale verwendet. Spektrale Merkmale beziehen sich auf Informationen über die physikalischen Gegebenheiten des Vokaltrakts des Sprechers. Als Standardmerkmal sind hier die Mel-Frequenz-Cepstrum-Koeffizienten (MFCC) zu nennen. Die menschliche Stimme enthält jedoch mehr Informationen über den Sprecher als nur die physikalischen Gegebenheiten. Die Art der Information im Sprachsignal unterscheidet sich je nach Merkmal und kann in einem Kontinuum zwischen der so genannten niedrigen Informationsebene (Low-Level) und der hohen Informationsebene (High-Level) eingeordnet werden. Spektrale Merkmale werden der niedrigen Informationsebene zugeordnet. Als Methoden höherer Informationsebenen werden solche Methoden bezeichnet, die entweder linguistisch motiviert sind oder sich auf Signalabschnitte beziehen, die länger sind als die bei spektralen Methoden üblichen ca. 20–25 ms. High-Level Merkmale sind meistens erlernte Merkmale, wie beispielsweise der Dialekt des Sprechers. Einen guten Überblick über den derzeitigen Stand der Forschung solcher HighLevel Methoden wird in (Shriberg, 2007) gegeben. Ein Projekt, welches intensiv verschiedenste High-Level Methoden erforscht hat, ist das Super-SID Projekt (Reynolds et al., 2002). Der Vorteil der High-Level Merkmale ist, dass sie die Robustheit des Systems verbessern können, da sie häufig nicht so anfällig für Verschlechterungen der Signalqualität sind. Leider sind sie häufig mit größerem Rechenaufwand verbunden, so dass für jede einzelne Applikation geprüft werden muss, ob es sinnvoll ist, diese Merkmale einzusetzen. Sie liefern dem System jedoch auch zusätzliche Informationen, welche durch die ausschließliche Verwendung spektraler Merkmale nicht erzielt werden können. Um eine optimale Abdeckung der verschiedenen Informationsebenen zu erzielen, empfiehlt es sich, Systeme basierend auf Merkmalen unterschiedlicher Ebenen zu fusionieren. Zur Modellierung des Hintergrundmodells und der Sprechermodelle gibt es ebenfalls verschiedene Ansätze. Der klassische Ansatz ist ein GMM basierter Klassifikator. Dieser Ansatz wird detailliert in (Reynolds et al., 2000) beschrieben. Als

188

C. Harwardt

zweites Standardverfahren ist, wie in der Landessprachenerkennung, die SVM zu nennen. Sie modelliert Grenzen zwischen verschiedenen Klassen (Sprechern) im Vektorraum. Die Grundlagen der SVM sowie die Realisierung eines SVM basierten Klassifikators wird in (Reynolds & Campbell, 2008) beschrieben. Einen umfassenden Überblick über den momentanen Stand der Technik und ausführlichere Erläuterungen zur Merkmalsextraktion und zur Modellierung geben (Reynolds & Campbell, 2008).

13.4.3 Tests mit militärisch relevanten Audiodaten Wie in (Harwardt et al., 2008) beschrieben, wurde mit der FKIE Evaluation im Jahr 2008 eine vergleichende Evaluation verschiedener kommerziell erhältlicher Sprechererkenner und Forschungssysteme durchgeführt. Für diese Evaluation wurden vier Korpora verschiedener Sprachen genutzt, welche ausschließlich militärisch relevante Audiodaten enthalten. Um die Leistung der Systeme einordnen zu können, wurde am FKIE ein Forschungsprototyp ähnlich dem Konzept von (Reynolds et al., 2000) erstellt. Es handelt sich um ein GMM basiertes System, welches in der Vorverarbeitung 48 Merkmale für den MFCC Merkmalsvektor sowie einen Telefonfilter nutzt. In dem in Abb. 13.2 dargestellten Testdurchlauf wurde der Prototyp ohne Sprach-Pause-Detektion verwendet, da für die gegebene Datenqualität bisher kein

Vergleich Forschungsprototyp - Evaluationsteilnehmer 95 Forschungsprototyp bestes System schlechtestes System

90 80

50

20

5

1

0.1

0.1

1

5

20

50

80

90

95

False Alarm Rate

Abb. 13.2 Vergleich des Forschungsprototypen mit dem besten und schlechtesten System der FKIE Evaluation 2008

13 Sprachverarbeitung gesprochener Sprache

189

robuster Klassifikator vorliegt. Die Ergebnisse sind trotzdem mehr als zufriedenstellend. Die Kurve in Abb. 13.2 ist eine so genannte DET-Kurve (Detection Error Tradeoff). Eine solche Kurve wird standardmäßig zur Darstellung der Leistung von Sprecher- und Landessprachenerkennungssystemen verwendet. Als Bewertungskriterium wurde in der FKIE Evaluation die Equal Error Rate (Gleichfehlerrate, EER) genutzt. Die EER ist der Wert, bei dem die beiden auf den Achsen eingezeichneten Fehler gleich sind. Je kleiner die EER, desto besser ist das System. Beim Vergleich der EER der Kurven aus Abb. 13.2 zeigt sich, dass für das hier betrachtete Korpus mit dem oben beschriebenen FKIE Forschungsprototypen vergleichbare Ergebnisse zu dem besten teilnehmenden System der FKIE Evaluation erreicht werden können. Auch für die anderen Korpora werden gute Ergebnisse erzielt. Bezieht man alle Korpora in die Auswertung mit ein, so liegt die Leistung des Forschungssystems im guten Mittelfeld. Die weitere Entwicklung und Anpassung des Systems lassen zusätzliche Verbesserungen erwarten. Diese Anpassungsmöglichkeiten an die Daten konnte den Teilnehmern der Studie nicht eingeräumt werden, da es sich bei den Daten um sicherheitsrelevantes Material handelt. Der Vergleich in Abb. 13.2 zeigt, dass weiterer Forschungsbedarf besteht, da die EER des untersuchten Korpus von über 20% für militärische Einsatzbereiche nicht akzeptabel ist. Des Weiteren zeigt sich, dass die Entwicklung eines Systems direkt auf den Daten des späteren Einsatzbereichs, wie es für das Forschungssystem der Fall ist, schon mit relativ wenig Aufwand zum Erfolg führt. Dies bestätigt die These aus Abschn. 13.3, dass sprachverarbeitende Systeme für den militärischen Einsatzbereich immer direkt auf Einsatzdaten entwickelt werden sollten.

13.5 Zusammenfassung und Ausblick Dieser Artikel soll dem Leser einen Eindruck über die Einsatzmöglichkeiten sprachverarbeitender Technologien im militärischen Kontext vermitteln. Dafür wurden zunächst alle erforderlichen Grundlagen erläutert, um dann konkrete Anwendungsszenarien und Forschungsbereiche aufzuzeigen. Es wurden die Grenzen der Forschung auf Grund der eingeschränkten Möglichkeiten der Entwicklung auf sicherheitsrelevanten Daten dargestellt und öffentlich erhältliche Korpora vorgestellt, die einen ersten Lösungsansatz für dieses Problem bieten. Weiterhin wurde die aktuelle Situation der Militärforschung für Spracherkennung, Landessprachenerkennung und Sprechererkennung dargestellt. Ein besonderer Fokus lag hierbei auf dem Anwendungsbereich Sprechererkennung. Es wurden detailliert der Aufbau sowie die gängigen Techniken der Sprechererkennungstechnologie gezeigt. Abschließend wurde durch einen Test mit militärisch relevantem Audiomaterial die Notwendigkeit verdeutlicht, sprachverarbeitende Systeme direkt auf einsatzszenarionahen Daten zu entwickeln.

190

C. Harwardt

Literaturverzeichnis Ahluwalia, R. (2008). Entwicklung und Evaluation einer Sprachsteuerung zur Navigation einer Gruppe teilautonomer unbemannter Roboter. Magisterarbeit, Universität Bonn. Benarousse, L., Geoffrois, E., Grieco, J., Series, R., Steeneken, H., Stumpf, H., Swail, C., & Thiel, D. (2003). The NATO Native and Non-Native (N4) Speech Corpus. In Multilingual Speech and Language Processing – (Le traitement multilingue de la parole et du langage), volume RTOMP-066: NORTH ATLANTIC TREATY ORGANISATION – RESEARCH AND TECHNOLOGY ORGANISATION. Englund, C. (2004). Speech recognition in the JAS 39 Gripen aircraft – adaption to speech at different G-loads. Master’s thesis, KTH Speech, Music and Hearing, Stockholm. Eurofighter GmbH (2008). http://www.eurofighter.com/austria/td_co.asp?srcx=dev1 (18.09.2008). Fernández, F., de Córdoba, R., Ferreiros, J., Sama, V., D’Haro, L. F., & Macías-Guarasa, J. (2004). LANGUAGE IDENTIFICATION TECHNIQUES BASED ON FULL RECOGNITION IN AN AIR TRAFFIC CONTROL TASK. In Interspeech 2004. Glave, R. D. (1974). Das Bonner DAWID-Projekt: Konzeption und Entwicklung. In Bierfert, Fritsche, v. d. Giet, R. D. Glave, K. Kotten, & D. Lancé (Eds.), Automatische Klassifikation phonetischer Signale nach linguistisch-relevanten und sprechergebundenen Merkmalen. Institut für Kommunikationsforschung und Phonetik. Harwardt, C. (2007). Spracherkennung auf militärischen Funksprüchen. FKIE-Bericht Nr. 127, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Harwardt, C., Feiser, H., Kawaletz, S., & Hecking, M. (2008). Untersuchung und Bewertung von Klassifikatoren der Sprachverarbeitung. Abschlußbericht zur Studie, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. VS-NFD. Klatt, D. H. (1977). Review of the ARPA Speech Understanding Project. Journal of the Acoustical Society of America, 62(6). NIST (2008). http://www.nist.gov/speech/tests/ (06.10.2008). Pigeon, S., Shen, W., Lawson, A., & van Leeuwen, D. A. (2007). Design and characterization of the Non-native Military Air Traffic Communications database (nnMATC). In Interspeech 2007. Pigeon, S., Swail, C., Geoffrois, E., Bruckner, C., van Leeuwen, D., Teixeira, C., Orman, O., Collins, P., Anderson, T., Grieco, J., & Zissman, M. (2005). Use of Speech and Language Technology in Military Environments. RTO TECHNICAL REPORT TR-IST-037 AC/323(IST037)TP/22, NORTH ATLANTIC TREATY ORGANISATION – RESEARCH AND TECHNOLOGY ORGANISATION. Reynolds, D., Andrews, W., Campbell, J., Navrátil, J., Peskin, B., Adami, A., Jin, Q., Klusácek, D., Abrahamson, J., Mihaescu, R., Godfrey, J., Jones, D., & Xiang, B. (2002). SuperSID Project Final Report – Exploiting High-Level Information for High-Performance Speaker Recognition. Technical report, Department of Defense; National Science Foundation. http://www.clsp.jhu.edu/ws2002/groups/supersid/, (02.04.07). Reynolds, D. & Campbell, W. (2008). Text-Independent Speaker Recognition. In Springer Handbook of Speech Processing. Benesti,Sondhi, Huang. Reynolds, D., Quatieri, T., & Dunn, R. (2000). Speaker Verification Using Adapted Gaussian Mixture Models. Digital Signal Processing, 10, 19–41. Schukat-Talamazzini, E. G. (1995). Automatische Spracherkennung – Statistische Verfahren der Musteranalyse. Vieweg Verlag. Shriberg, E. (2007). Higher-Level Features in Speaker Recognition. In Speaker Classification 1 – Fundamentals, Features, and Methods. Christian Müller. Singer, E., Torres-Carrasquillo, P., Gleason, T., Campbell, W., & Reynolds, D. (2003). Acoustic, Phonetic, and Discriminative Approaches to Automatic Language Identification. In Eurospeech 2003. von Zeddelmann, D. (2008). Entwicklung und Untersuchung eines textunabhängigen Sprecherverifikationssystems auf der Basis Gauß’scher Mischverteilungsmodelle. Magisterarbeit, Universität Bonn.

Kapitel 14

Überblick über Interoperabilitätsstandards Michael Gerz und Ralf Heckmann

14.1 Einleitung Die Interoperabilität von Führungsinformationssystemen ist eine zentrale Voraussetzung für die vernetzte Operationsführung. Bei internationalen Einsätzen ergibt sich jedoch die Problematik, dass Führungsinformationssysteme verschiedener Nationen im Verbund verwendet werden sollen, die sich sowohl unter operationellen als auch unter technischen Gesichtspunkten unterscheiden können. Sie wurden in der Regel nur für die Verwendung innerhalb eines Anwendungsbereiches (Domäne) entwickelt und optimiert, nicht aber für die Verwendung über Domänengrenzen hinweg. Die wesentliche Herausforderung der kommenden Jahre ist es daher, diese bisherigen Interoperabilitätsgrenzen zu überschreiten. Im militärischen Bereich haben sich verschiedene Standards für spezifische Interoperabilitätsbedarfe etabliert, die unterschiedliche technische und operationelle Teilbereiche abdecken. So berücksichtigen bestimmte Standards z. B. die Bedürfnisse einzelner Teilstreitkräfte oder bieten Lösungen für einzelne Schichten des OSISchichtenmodells, die mit anderen Standards kombiniert werden müssen. Historisch begründet unterscheidet man im militärischen Bereich zwischen Standards für einen zeichenorientierten und für einen bitorientierten Informationsaustausch. Beim zeichenorientierten Informationsaustausch (ZOIA) können dabei der Austausch und die anschließende Auswertung durch eine IT-Anwendung, aber auch noch manuell erfolgen (d. h. die empfangenen Daten sind durch einen Operateur lesbar und interpretierbar). Letzteres ist bei einem bitorientierten Austausch nicht möglich. Gebräuchliche Standards für den Informationsaustausch mittels militärischer Führungsinformationssysteme und ihre Einordnung in das OSI-7-Schichtenmodell sind in Abb. 14.1 dargestellt.1 Die Standards ADatP-3, NFFI, OTH-T Gold, MIP,

1 Die Abb. 14.1 und 14.2 wurden mit freundlicher Genehmigung von Herrn Ulrich Ritgen zur Verfügung gestellt.

M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

193

194

M. Gerz und R. Heckmann

OSI-Layer

Übersicht Informationsaustausch-Standards

X.400 MHS

MIP MEM

ADatP-3 CONFORMETS

XML

XML/XSD

MIP DEM

SGML

Presentation ISO 8824 ASN.1 STANAG 5525 JC3IEDM

ACP 117 Routing Indicator ACP 100 Collective Addr

DNS IP1

IP2

Transmission Standards AWCIES

ISO 8327 COSP

4 Transport

TCP

3

IPv4

Network

X.25 Packet Switching Network

E.g. Ethernet, ISDN, Radio Emission

Data Link

1

Symbols Text

Text Text

Related Set of Standards Military Standard

Dependency

Connectors, Electrical, Electromagnetic and Optical Signals

Physical

STANAG 4202

Civil Standard

Relation

Cable

STANAG 5045 Teleprinter

Radio

2

TCP or UDP

UDP

Optional Transmission

5 Session

ACP 127 and NATO SUPP-3 Message Relay Procedures

STANAG 2245 (ASCA) CTIR CTIDP

STANAG 4175 (MIDS)

6

MILSTD 3011 (JREAP)

NFFI Wrapper

Link 16

STANAG 5516 (LINK 16)

FTP

ASCA

Interface Requirements Specification AWCIES

OIG

WMO Pub #306 Manual on Codes

XML-MTF

AWCIES

MIPMEM MTFs

ACCS XML

MTF

MIP

EUROCONTROL OLDI

SMTP OTHT Gold

STANAG 4406 MMHS Gateway

7 Application

MMHS

NFFI Payload

MilASTERIX

Web-Services e.g. SOAP

EUROCONTROL ADEXP

NFFI

APP-11 NATO Message Catalogue

EUROCONTROL ASTERIX

FORMETS

© 2009, U. Ritgen

Abb. 14.1 Standards für den Informationsaustausch

MMHS und ASCA werden in den Abschn. 14.2 bis 14.7 kurz skizziert.2 Fragestellungen, die sich aus der Nutzung unterschiedlicher Standards ergeben, werden in Abschn. 14.8 diskutiert.

14.2 Allied Data Publication 3 (ADatP-3) Die umfangreichsten und am meisten genutzten Standards für den zeichenorientierten Informationsaustausch sind die Allied Data Publication 3 (ADatP-3) und die Allied Procedural Publication 11 (APP-11). Der Zusammenhang zwischen beiden Standards ist in Abb. 14.2 dargestellt. ADatP-3, auch CONFORMETS (Concept of NATO Message Text Formatting Systems) genannt, ist mit dem Standardization Agreement (STANAG) 5500 ratifiziert (NSA, 2006). Es liefert ein Regelwerk für die Definition von zeichenorientierten Meldeformaten (engl.: Message Text Formats; MTFs). Jede ADatP-3-konforme Meldung setzt sich aus geordneten Sätzen (engl.: sets) von direkt verbundenen Informationen zusammen. Ein Satz ist wiederum eine Gruppe von zusammengehörigen Feldern. Ein auszutauschender Meldetext ist gemäß 2

Die Air Command and Control System (ACCS) Wide Common Information Exchange Standards (AWCIES) werden im Rahmen dieses Buches nicht weiter betrachtet. Für Informationen zu Link 16 sei auf (Teege et al., 2007) verwiesen.

14 Überblick über Interoperabilitätsstandards

195

Abb. 14.2 Formatierungssprache und Meldeformate

dem entsprechenden Meldetextformat aufgebaut, das analog hierarchisch aus geordneten Satz- und Feldformaten konstruiert ist. Zusätzlich können aufeinander folgende Sätze zu sogenannten Segmenten zusammengefasst werden. Für alle Elemente eines Meldeformats wird festgelegt, ob sie verpflichtend, operationell bestimmt (d. h. je nach konkretem Einsatzbedarf erforderlich) oder in Abhängigkeit vom Inhalt anderer Elemente erforderlich sind. Ein Feldformat definiert die Werte, die in einem Feld verwendet werden dürfen. Ein Feldformat unterstützt entweder ein atomares Konzept wie Name einer Einheit oder logisch eng miteinander verbundene Konzepte wie Datum und Uhrzeit. Meldetext-, Satz- und Feldformate besitzen Bezeichner (Schlüsselwörter) und Namen, um sie in Meldetexten eindeutig zu identifizieren. Feldformate können und sollen in unterschiedlichen Meldetextformaten wiederverwendet werden. Da aber nicht alle gültigen Werte eines Feldformats in allen Kontexten sinnvoll sind, werden für jedes Feldformat ein oder mehrere Field Use Designators (FUDs) spezifiziert. Die Bedeutung eines Felds in einem Meldetext ergibt sich aus der Position des Felds in seinem Satz und dem Kontext, der sich aus den Satz- und Feldformaten ableitet. Zum Beispiel kann dieselbe Datumszeitgruppe als Datentyp sowohl als Start als auch als Ende eines definierten Zeitraums verwendet werden; ein derart dargestellter Zeitraum kann sowohl als Gültigkeitszeitraum einer Information, als auch als Zeitraum für eine Aktivität genutzt werden. Zusätzlich zu diesen – auch in anderen Formatierungssprachen üblichen – Beschreibungsmöglichkeiten für Strukturelemente erlaubt es ADatP-3, mittels einer eigenen Beschreibungssprache strukturelle Abhängigkeiten zu spezifizieren. Die sogenannten Structural Relationship Rules können durch spezielle Software zu einer weitergehenden Konsistenzprüfung der Inhalte einer Meldung verwendet werden. Die Syntax von Feldern, Sätzen und Meldungen für den Datenaustausch ist durch ADatP-3 ebenfalls definiert. Die einzelnen Elemente werden dabei z. B. durch

196

M. Gerz und R. Heckmann

spezielle Markierungen (//, / und Zeilenumbrüche) eingeleitet. Beginnend mit der ADatP-3-Baseline 13.1 wurde erstmals XML als Grundlage der Spezifikation und als Alternative zur bisherigen Repräsentation von Meldeformaten eingeführt (XMLMTF). ADatP-3 definiert hierzu Abbildungsregeln, um aus Meldetexten äquivalente XML-MTF-Instanz-Dokumente zu erzeugen. Meldetextformate werden durch entsprechende XML-MTF-Schemata gemäß W3C XML Schema (W3C, 2004) spezifiziert. Die vorhandenen Meldeformate werden regelmäßig auf der Basis operationeller Anforderungen aktualisiert und erweitert. Ihr aktueller Stand wird bei Bedarf eingefroren und als sogenannte Baseline veröffentlicht. Aus einer Baseline leitet sich wiederum der APP-11 NATO Message Catalogue (NATO, 2008) ab, der die im Rahmen der NATO verbindlichen Meldungen festlegt.3 APP-11 wird als STANAG 7149 geführt und umfasst gegenwärtig 400 Meldeformate, darunter 360 MTFs. ADatP-3 selbst definiert keine technische Lösung für die Übertragung formatierter Meldungen. Daher muss zu diesem Zweck auf externe Kommunikationsprotokolle wie ACP-127, E-Mail, Web-Services o. ä. zurückgegriffen werden. Dies bedeutet jedoch auch, dass allein durch die Verwendung von Meldungen einer bestimmten Version der APP-11 bzw. ADatP-3 die Interoperabilität zweier Systeme noch nicht notwendigerweise gegeben ist.

14.3 NATO Friendly Force Information (NFFI) Der Interim NATO Friendly Force Information (NFFI) Standard for Interoperability of Force Tracking Systems (FTS) (NATO, 2006) wurde im Jahr 2005 unter Leitung des Allied Command Transformation (ACT) initiiert. Ein Force Tracking System ist ein System, das die Eigenposition eines Fahrzeugs, Flugzeugs oder eines Soldaten genau bestimmt und verfolgt und die Position sowie ggf. weitere Statusinformationen automatisiert an die übergeordnete Führung weiterleitet. Dort wird das Lagebild eigener Kräfte aggregiert bzw. verdichtet und kann allen angeschlossenen Systemen wieder zur Verfügung gestellt werden. Im Fokus von NFFI sind dabei insbesondere landbasierte Systeme. Da die auszutauschenden Daten von den FTSs in der Regel automatisiert, d. h. ohne manuelle Eingaben generiert werden, werden im Rahmen von NFFI auch nur solche Datenelemente berücksichtigt, die potentiell vom einem FTS erzeugt werden. Bereits im Jahr 2004 hatte das ACT eine Arbeitsgruppe eingerichtet, um die Fähigkeit zum Verfolgen eigener Kräfte für die NATO Response Forces bis 2008 und NATO-weit bis 2010 umzusetzen. Aufgrund der geänderten operationellen Anforderungen wurde jedoch zwischenzeitlich eine schnelle („quick-win“) Interoperabilitätslösung für die internationale Sicherheitsunterstützungstruppe (International Security Assistance Force; ISAF) in Afghanistan erforderlich. Hierzu wurde der 3 Neben MTFs umfasst APP-11 u. a. auch sogenannte Voice Templates (VTs) für die Übertragung von Sprachmeldungen sowie Meldungen, die nicht konform zu den Regel von ADatP-3 sind.

14 Überblick über Interoperabilitätsstandards

197

NFFI-Standard in der Version 1.3 spezifiziert. Er wird als sogenanntes D-Dokument geführt mit dem Ziel, dieses künftig als NATO STANAG 5527 zu verabschieden. Der NFFI-Standard umfasst verschiedene Aspekte: Zunächst definiert NFFI ein Meldeformat für den Informationsaustausch, welches in Form eines XML-Schemas spezifiziert ist. Um NFFI gemeinsam mit anderen Interoperabilitätsstandards einsetzen zu können, werden Abbildungen vom NFFI z. B. auf das MIP Command and Control Information Exchange Data Model (C2IEDM; MIP, 2004) und relevante ADatP-3- und Link 16-Meldeformate betrachtet. Darüber hinaus spezifiziert der Standard zwei Kommunikationsprofile für den Austausch von NFFI-Meldungen, die das Push-Prinzip umsetzen und auch für Netzwerke mit geringer Bandbreite geeignet sind. Das Interface Protocol 1 (IP1) erlaubt es zwei Kommunikationspartnern, Informationen zuverlässig in beide Richtungen zu übertragen. Hierzu wird eine unicast-Verbindung mit Hilfe von TCP und IPv4 eingerichtet. Für die Adressierung von Knoten mittels Namen (anstelle von IP-Adressen) wird ein Domain Name Server vorausgesetzt. Das Interface Protocol 2 (IP2) dagegen bietet einen unzuverlässigen Dienst für die Kommunikation in eine Richtung. Dabei kann ein Netzwerkknoten eine Meldung sowohl an einen (unicast) oder mehrere (broadcast) Adressaten schicken. Als unzuverlässiger Dienst sollte IP2 nur dann eingesetzt werden, wenn die garantierte Übermittlung von Meldungen zugunsten eines geringeren Protokoll-Overheads aufgegeben werden kann (z. B. bei der Übermittlung häufiger Positionsangaben in Nahe-Echtzeit). In den letzten Jahren wurde zudem das sogenannte Service Interoperability Profile 3 (SIP3) entwickelt, welches gegenwärtig als Entwurf vorliegt. SIP3 soll NFFI zukünftig als einen Web-Service bereitstellen und dabei sämtliche Funktionalitäten von IP1 und IP2 abdecken. SIP3 wurde bereits auf der Coalition Warrior Interoperability Demonstration (CWID) 2006 bis 2008 mit Erfolg getestet.

14.4 Over the Horizon Targeting GOLD (OTH-T GOLD) Die Operational Specification Over The Horizon Targeting GOLD (OS OTH-T GOLD; siehe U.S. Navy Center for Tactical Systems Interoperability, 2004) ist ein USamerikanischer Standard zur Übermittlung von Lageinformationen, der im Bereich der Marine eingesetzt wird und in mehreren Revisionsständen vorliegt. OTH-T GOLD findet z. B. Anwendung im Maritime Command Control and Information System (MCCIS) der NATO und dessen Recognized Maritime Picture (RMP), aber auch im Rahmen des Führungsinformationssystems der Streitkräfte (FüInfoSysSK; IT-AmtBw, 2008). MCCIS wird zudem von der deutschen Marine als Bestandteil des Führungs- und Informationssystems Marine (FüInfoSysM) genutzt. Ein GOLD-Report ist ein Datenformat, mit dem Lageinformationen ausgetauscht werden können. Eine entsprechende Meldung kann über verschiedene Kommuni-

198

M. Gerz und R. Heckmann

kationsmittel, z. B. als Email oder Fernschreiben, übertragen werden. OS OTH-T GOLD definiert derzeit insgesamt 18 Meldungsformate.

14.5 Multilateral Interoperability Programme (MIP) Ziel des Multilateral Interoperability Programme (MIP) ist es, „internationale Interoperabilität von Führungsinformationssystemen auf allen Ebenen vom Korps bis zum Bataillon, oder der niedrigsten geeigneten Ebene, zu erreichen, um multinationale (einschließlich NATO) und teilstreitkräftegemeinsame Operationen zu unterstützen“ (MIP, 2006). MIP ist ein partnerschaftliches Programm ohne gemeinsame Finanzierung, an dem 27 Nationen und die NATO teilnehmen. MIP definiert Spezifikationen für den automatisierten Informationsaustausch, die unabhängig von einem spezifischen System und auf der Basis von Konsens unter den MIP-Mitgliedern entwickelt und kontinuierlich fortgeschrieben werden. Die für die operationelle Nutzung freigegebene MIP Baseline 2 wird national in den Systemen FüInfoSysH und HEROS 2.1, 2. Los eingesetzt. Die MIP-Spezifikation umfasst operationelle, technische und prozedurale Aspekte. Dies spiegelt sich auch in der umfassenden Dokumentation wider, die folgende Produkte umfasst:  Operationelle Anforderungen an die MIP-Lösung;  Systemanforderungen;  Handbücher für den operativen Nutzer (Stabsoffizier) und den technischen Nutzer (MIP-Gateway-Administrator);  Testspezifikationen für Systemtests und operationelle Tests;  Sicherheitsanforderungen;  Spezifikation eines gemeinsamen Datenmodells und zugehöriger Anwendungsregeln;  Spezifikation von Austauschmechanismen. Der Ansatz der MIP-Lösung ist in Abb. 14.3 dargestellt. Heterogene, nationale FüInfoSys (engl.: C2IS) tauschen dabei Informationen über eine gemeinsame Schnittstelle aus (MIP Common Interface – MCI), auch wenn sie systemseitig eine proprietäre operationelle Datenbank (ODB) verwenden. Um die semantische Interoperabilität zu erreichen, definiert MIP ein gemeinsames Datenmodell. Dessen Bezeichnung in den verschiedenen Entwicklungsphasen der MIP-Lösung gibt einen Hinweis auf den wachsenden Umfang des Datenmodells: Operativ eingesetzt wird derzeit das Command and Control Information Exchange Data Model (C2IEDM). Dieses wurde in Kooperation mit der NATO unter der Bezeichnung Joint Consultation, Command and Control Information Exchange Data Model (JC3IEDM) weiterentwickelt, um auch teilstreitkräfteübergreifende Aspekte abzudecken. Das JC3IEDM 3.1 wird Bestandteil der MIP Baseline 3

14 Überblick über Interoperabilitätsstandards

199

Abb. 14.3 Die MIP-Lösung (modifizierte Fassung aus dem MIP Standard Briefing; MIP, 2006)

sein, die 2009 für die operative Anwendung freigegeben werden soll. Aufgrund seines Einflusses auch auf andere Projekte wird das JC3IEDM in Kap. 16 ausführlich behandelt. Für den Datenaustausch definiert MIP zwei Verfahren, den Data Exchange Mechanism (DEM) und den Message Exchange Mechanism (MEM). Der Data Exchange Mechanism (DEM) ist ein Publish-Subscribe-Ansatz, bei dem ein MIP-Gateway die zum Informationsaustausch angebotenen Gruppen eines anderen MIP-Gateways abonniert. Jede Organisation kann ihre Informationen in sechs vordefinierten Kategorien sogenannter Operationeller Informationsgruppen (OIGs) anbieten. Die mit dem DEM ausgetauschten Daten entsprechen dem JC3IEDM. Das für den DEM verwendete Replikationsverfahren stellt dabei sicher, dass die Regeln der referenziellen und semantischen Vollständigkeit beim Datenaustausch berücksichtigt werden. Der DEM-Protokollstack setzt auf TCP auf. Neben dem DEM existiert mit dem Message Exchange Mechanism (MEM) ein auf dem Extended Simple Mail Transfer Protocol (ESMTP) beruhender, meldungsbasierter Ansatz. Dieser wird für die Übertragung einiger weniger, vordefinierter Meldungen verwendet.

14.6 MMHS Beim Military Message Handling System (MMHS) handelt es sich um eine Erweiterung des X.400-Standards, die eine Nachrichtenübermittlung unter den besonderen Anforderungen eines militärischen Umfelds sicherstellen soll. Sie ist als NATO STANAG 4406 verabschiedet. Zu den Eigenschaften, die im zivilen Bereich fehlen, zählt eine verpflichtende Zugangskontrolle durch Sicherheitseinstufungen von Nachrichten (beispielsweise Classified/Secret/Top Secret), die Angabe eines Meldungstyps und die der Priorität einer Nachricht; E-Mails mit höherer Priorität werden folglich von den Kompo-

200

M. Gerz und R. Heckmann

nenten des MMHS bevorzugt verarbeitet. Mit Hilfe des MMHS-Standards war es zudem seinerzeit erstmals möglich, signierte Meldungen auszutauschen. STANAG 4406 definiert ferner Protokolle, um einen Meldungsaustausch auch bei sehr niedriger Bandbreite, beispielsweise bei HF-Netzen, bei hoher Latenz und bei zeitweiligem Sendeverbot des Empfängers zu ermöglichen. Darüber hinaus stellt die STANAG 4406 die Konformität zum bestehenden Fernschreibbetriebsverfahren durch zusätzliche Attribute her. Das FKIE hat in der Vergangenheit eine experimentelle Implementation entwickelt, die alle von der STANAG 4406 geforderten Eigenschaften erfüllt und eines der ersten lauffähigen Systeme in der NATO war. Während der Implementierung wurde intensiv auf NATO-Ebene an der Entstehung der oben genannten STANAG mitgearbeitet. Der ISO-Standard X.400 ist heutzutage im zivilen Bereich weitgehend von den im Internet verbreiteten E-Mail-Standards (z. B. SMTP, POP3, IMAP4) verdrängt worden. Untersuchungen am FKIE haben gezeigt, dass zur Erfüllung der Anforderungen an MMHS die aktuellen E-Mail-Standards in einem vergleichbaren Umfang angepasst werden müssten wie seinerseits der X.400-Standard (Schmeing & Haak, 2005; Schmeing, 2006).

14.7 ASCA Artillery Systems Cooperation Activities (ASCA) ist ein Programm mehrerer Nationen mit dem Ziel, die Interoperabilität von Führungs- und Waffeneinsatzsystemen (FüWES) ihrer Artillerie herzustellen. Zu diesem Zweck werden die operationellen Anforderungen harmonisiert und eine gemeinsame, echtzeitfähige Schnittstelle spezifiziert. Die Umsetzung des ASCA-Standards in den jeweiligen nationalen FüWES ist – analog zu MIP – Aufgabe der einzelnen Nationen. Um die Interoperabilität der beteiligten Systeme nachzuweisen, werden gemeinsame technische und operationelle Tests auf der Basis entsprechender Testspezifikationen durchgeführt. An der ASCA-Schnittstelle werden Datentelegramme aus einem nationalen FüWES automatisch in den internationalen Standard und dann vom Partnersystem ebenfalls automatisch in dessen Meldungsformat umgesetzt. Damit kann z. B. ein Artilleriebeobachter Feuerunterstützung anfordern und leiten, die von Feuereinheiten anderer Nationen geleistet wird. ASCA erarbeitet sowohl operationelle als auch technische Spezifikationen. Die ASCA-Dokumentation beschreibt die Zielsetzung und Strategie des Programms, definiert gemeinsame operationelle und daraus abgeleitete technische Anforderungen, spezifiziert die technische Schnittstelle und liefert ergänzende Prozeduren für die Nutzung der Schnittstelle durch den Operateur und die Durchführung von Aufgaben durch den militärischen Führer. Die Kommunikation bei ASCA setzt auf Truppenfunk bzw. Feldkabel auf. Die Kommunikationsverfahren sind ebenso wie die verwendeten Meldeformate im sogenannten Common Technical Interface Design Plan (CTIDP) definiert. ASCAMeldungen sind zeichenorientiert und damit nicht nur automatisch verarbeitbar,

14 Überblick über Interoperabilitätsstandards

201

sondern auch lesbar. Sie unterstützen die Planung, Durchführung und Kontrolle des artilleristischen Feuerkampfes sowie das Berichten von NBC-Ereignissen (Nuclear, Biological, Chemical). In Deutschland wurde die ASCA-Schnittstelle im FüWES ADLER implementiert und ist seit 2003 in der Nutzung. Zukünftige Funktionserweiterungen der ASCASchnittstelle sind der Einsatz und die Führung alliierter Aufklärungsmittel (z. B. Radar und Drohnen) und der Einsatz intelligenter Munition.

14.8 Datenintegration mittels Mediation Alle beschriebenen Interoperabilitätsstandards sind jeweils ein wichtiger Beitrag für den Austausch führungsrelevanter Informationen in den spezifischen Anwenderbereichen, den so genannten Domänen. Alle sind sie für den Bedarf, für den sie entwickelt wurden, geeignet, alle sind sie aber auch auf die Verwendung in ihren Domänen beschränkt. Zunehmend steigt die Notwendigkeit, Daten aller Art und aus unterschiedlichsten Quellen nicht nur innerhalb dieser einzelnen Domänen austauschen zu können, sondern sie auch domänenübergreifend rechtzeitig und gemeinsam an den entscheidenden Stellen verfügbar zu haben und (möglichst automatisiert) weiterverarbeiten zu können. Hierzu gehören in immer stärkerem Maße auch Daten aus nichtmilitärischen Quellen und Metadaten z. B. zu Objekten aus Video- oder Bilderportalen im Internet. Die zu berücksichtigenden Daten unterscheiden sich oft stark in Umfang und Detaillierungsgrad, aber auch in Struktur und Format – und sehr oft in ihrer Semantik.4 Die Integration solch uneinheitlicher Daten aus unterschiedlichen autonomen Datenquellen zu einer gemeinsamen Informationsplattform sowie deren konsistente weitergehende Nutzung ist von essentieller operativer Bedeutung. Die Herausforderung liegt daher in der möglichst vollständigen und effizienten Zusammenführung der operativ benötigten Daten zu einer gemeinsamen strukturierten Datenbasis als eine Grundlage für die Führung. Eine Rahmenbedingung dieser Zusammenführung ist, dass die am Datenaustausch beteiligten Systeme und deren eigene Datensemantiken und -strukturen nicht ohne weiteres durch neue und einheitliche Semantiken und Strukturen für alle beteiligten Systeme, also einen neuen gemeinsamen Standard, ersetzt werden können. Die Forderung nach einer solchen einheitlichen Datenbasis – die nicht notwendigerweise nur eine Datenbank ist – soll eine harmonisierte und damit effizientere und effektivere Datennutzung erlauben, als lediglich die unmittelbare Nutzung durch einen parallelen und direkten Zugriff auf die verschiedenen Quellen ohne jegliche Harmonisierung der Daten selbst. Ziel der Integration von Daten unterschiedlicher Herkunft in einer einheitlichen operativen Datenbasis ist es, verdichtete und damit vollständigere Daten, und aus 4 Oft kommt auch noch das Sicherheitsgefälle hinzu, welches die Weitergabefähigkeit von Daten beeinflusst.

202

M. Gerz und R. Heckmann

diesen vollständigere Informationen verfügbar zu haben. Aufgrund der wachsenden Menge von Daten sowie steigenden Anforderungen an die Qualität muss diese Integration nach Möglichkeit automatisiert erfolgen. Bei der Integration sind nicht nur die Daten an sich, sondern auch deren Strukturen (Schemata, Taxonomien, Ontologien o. Ä.) zu berücksichtigen. Ziel ist es, vorhandene Semantiken und Strukturen nach Möglichkeit nicht zu ändern; sie sollen „nur“ gegenseitig genutzt werden können. Diese Integration der Daten bezeichnen wir als Datenabbildung. Voraussetzung für eine solche Abbildung ist, dass zwischen den jeweiligen Daten und ihren Strukturen eine ausreichende inhaltliche und strukturelle Ähnlichkeit besteht. Ohne grundsätzliche Gemeinsamkeiten in den jeweiligen Schemata können diese Daten nicht verlustfrei aufeinander abgebildet werden. Besteht aber eine solche Redundanz zwischen den Daten der einzelnen Quellen, können die jeweiligen Daten aus den einzelnen Quellen nicht nur aufeinander abgebildet werden, sondern auch dazu genutzt werden, einen Datensatz zu komplettieren. Im Ergebnis stehen dann zu den einzelnen Objekten mehr Informationen zur Verfügung als in den jeweiligen einzelnen Quellen, d. h. die Gesamtinformation wird vollständiger und kann für unterschiedliche Fragestellungen anforderungsgerecht aggregiert werden. Immer dann, wenn die Voraussetzung der Abbildbarkeit nicht gegeben ist, d. h. wenn keine verlustfreie Abbildung möglich ist, muss eine Harmonisierung der Semantiken und der Strukturen geprüft, realisiert und implementiert werden. Aufgrund des damit verbundenen Aufwandes und des zwingenden Eingriffs in bestehende Implementierungen sollte vor einer Anpassung und Änderung der betroffenen Strukturen immer erst kritisch geprüft werden, ob überhaupt ein gegenseitiger Informationsaustauschbedarf besteht oder ob es sich nur um einen angenommenen Bedarf handelt. Wenn kein dringender Bedarf zum Austausch besteht, dann besteht auch keine zwingende Notwendigkeit zur Harmonisierung von Daten und Strukturen! Wenn der Bedarf tatsächlich besteht und aufgrund der Inkompatibilitäten nicht durch Abbildung5 gelöst werden kann, dann müssen nicht die Symptome, sondern die Ursachen bekämpft werden: die Semantiken und die Strukturen müssen im notwendigen Umfang miteinander harmonisiert und standardisiert werden. Ohne eine solche Harmonisierung und Standardisierung und dem damit verbundenen Eingriff in die vorhandenen Definitionen und Strukturen wird ein Informationsaustausch in der gewünschten Qualität nicht möglich sein. Konzeptionell wird bei der Abbildung von Daten zwischen Mediation und Mapping unterschieden.6

5

Auch Abbildungen können beliebig komplex werden; im Extremfall ist eine Harmonisierung zur Steigerung der Effizienz der Abbildung notwendig. 6 Die Verwendung dieser beiden Begriffe in der angegebenen Bedeutung ergibt sich aus der Notwendigkeit, aus der Vielfalt der verwendeten und immer wieder unterschiedlich belegten (zumeist englischen) Begriffe im Kontext der Abbildung von Daten ((data) mapping, (data) transformation, (data) translation, (data) mediation, (data) conversion, usw.) eine Auswahl zu treffen.

14 Überblick über Interoperabilitätsstandards

203

Der Begriff Mediation beschreibt die Durchführung der Integration der Daten, d. h. das tatsächliche Überführen von Informationsinstanzen eines Systems aus ihrer spezifischen Struktur in die Struktur eines anderen Systems. Mapping ist das Abbilden der Bedeutung (Semantik) einzelner Elemente oder mehrerer Elemente einer bestimmten Datenstruktur auf wiederum einzelne Elemente oder Kombinationen von Elementen einer anderen Datenstruktur. Die Ergebnisse dieser Abbildungen werden mithilfe von Abbildungsregeln und -funktionen beschrieben. Damit ist prinzipiell sichergestellt, dass eine Information aus einem System über die Abbildung der Bedeutung der Daten und ihrer Zusammenhänge auch in einem Zielsystem genutzt werden kann, das eine andere innere Datenstruktur aufweist. Bei der Abbildung ist zu entscheiden, ob diese zwischen zwei Systemen direkt und unmittelbar realisiert werden soll, oder ob eine Standardsemantik zwischen mehreren Systemen zur Anwendung kommen soll. Die Verwendung einer Standardsemantik entspricht der Nutzung beispielsweise des Englischen als gemeinsamer Sprache, wenn mehrere Personen miteinander kommunizieren müssen, aber jeweils nicht die Sprache des anderen sprechen. Und wie in der gesprochenen Sprache ist davon auszugehen, dass nicht alle Feinheiten ausgetauscht werden können. . . Die Implementierung des Mechanismus zur Transformation der Daten aus einer Datenstruktur in Daten einer anderen Struktur wird als Mediator bezeichnet. Ein Mediator wird dabei durch die Regeln, die im Mapping-Prozess für die zwei betreffenden Datenstrukturen erarbeitet wurden, gesteuert. Für eine Mediation sind mehrere Schritte notwendig:  Analyse der Quell- und Ziel-Datenstrukturen zur Erfassung der unterschiedlichen Informationsräume;  Ggf. Erweiterung der Ziel-Datenstruktur, um eine maximale Überschneidung aller relevanten Teilaspekte der unterschiedlichen Quell-Informationsräume zu erreichen;  Festlegung eines Regelwerks, das eine (möglichst) verlustfreie Abbildung der Quell-Strukturen in die Ziel-Strukturen definiert;  Entwurf und Realisierung der Mediationssoftware, die die Integration gemäß den erstellten Regeln automatisiert durchführt. Die Datenstrukturen der Quellen als auch des Ziels müssen miteinander verglichen werden. Das Ergebnis der Analyse zeigt auf, inwieweit sich die Informationsräume der unterschiedlichen Datenmodelle überlappen, was zwischen diesen Informationsräumen ausgetauscht werden kann und welche Änderungen und Ergänzungen in der Zielstruktur, ggf. aber auch in der Quellstruktur, notwendig sind, damit eine Integration der Daten möglichst verlustfrei erfolgen kann. Das Regelwerk als Grundlage für den Mediator soll nicht nur die Automatisierung der Datenabbildung ermöglichen, sondern im Idealfall auch automatisch erstellt werden können. Die Erstellung dieser Regeln kann je nach Quell- und Ziel-Datenstruktur sehr komplex sein und weit über ein relativ einfaches SchemaMapping hinausgehen. Das macht ein manuelles Erarbeiten aufwändig und fehleranfällig. Unterschiedliche Strukturen in den einzelnen Modellen können dazu zwin-

204

M. Gerz und R. Heckmann

gen, Strukturen des Quellschemas aufbrechen zu müssen und zu neuen, Zielschemakonformen Strukturen umzugruppieren. Transformationen sind oft nicht nur auf der Schema-Ebene, sondern auch auf der Daten-Ebene notwendig, wenn z. B. die Daten des Quellsystems in einer anderen Einheit oder einem anderen Format vorliegen als im Zielsystem. Für die Automatisierung der Abbildung und der Mediation wird es erforderlich sein, vorhandene Strukturen um solche Elemente anzureichern, die für einen automatisierbaren semantischen Vergleich verwendet werden können. Hierfür werden Ontologien als Erfolg versprechender Lösungsansatz erachtet.

Literaturverzeichnis IT-AmtBw (2008). NetOpFü mit dem Experimentalsystem Taktische Datenlinks der Bundeswehr im internationalen Rahmen nachgewiesen. http://www.it-amtbw.de/portal/a/itamtbw/aktuel/ cwid (23.01.2009). MIP – Multilateral Interoperability Programme (2004). The C2 Information Exchange Data Model (C2IEDM Main), Edition 6.15. http://www.mip-site.org. MIP – Multilateral Interoperability Programme (2006). MIP Standard Briefing. http://www. mip-site.org. NATO – North Atlantic Treaty Organization (2006). Interim NATO Friendly Force Information (NFFI) Standard for Interoperability of Force Tracking Systems (FTS). D-document. NATO – North Atlantic Treaty Organization (2008). APP-11(C) NATO Message Catalogue. NSA – NATO Standardization Agency (2006). ADatP-3 NATO Message Text Formatting System (FORMETS) – Concept of FORMETS (CONFORMETS) Change 4. Schmeing, M. (2006). SMTP Priorities for MMHS Over Narrow-bandwidth Links. FKIE-Bericht Nr. 125, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Schmeing, M. & Haak, N. (2005). Applicability of Internet-email for military High-grade Messaging. FKIE-Bericht Nr. 93, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Teege, G., Eggendorfer, T., Eiseler, V., & Göhner, M. (2007). Militärische mobile Kommunikationsnetze. Bericht 2007-02, Institut für Informationstechnische Systeme (IIS), Universität der Bundeswehr München, Neubiberg. U.S. Navy Center for Tactical Systems Interoperability (2004). Operational Specification for OverThe-Horizon Targeting GOLD (OS OTH-T GOLD). W3C (2004). XML Schema Part 0: Primer Second Edition). http://www.w3.org/TR/2004/ REC-xmlschema-0-20041028/.

Kapitel 15

Architekturrahmenwerke Ralf Kreibich

15.1 Bedeutung von Architekturrahmenwerken Unternehmensarchitekturen (engl.: Enterprise Architectures) dienen der Beschreibung komplexer soziotechnischer Systeme. Sie stellen die einzelnen Komponenten dieser Systeme, ihre Aufgaben bzw. Funktionen, die Beziehungen zwischen den Komponenten und die Charakteristika der Systeme dar. Der Ansatz der Unternehmensarchitektur hat sich dabei aus zwei verschiedenen Richtungen entwickelt und zwar aus  der klassischen IT-Architektur, die Kommunikations- und Informationssysteme beschreibt und die Hard- und Softwarekomponenten, die Funktionen und die Beziehungen zwischen diesen Elementen darstellt und  der klassischen Prozessmodellierung, die Aufgaben bzw. Aktivitäten, die Aufbauund Ablauforganisation und die entstehenden Austauschbeziehungen darstellt. Unternehmensarchitekturen verbinden beide Richtungen. Neben einer besseren Dokumentation des Gesamtsystems sollen sie vor allem Zusammenhänge zwischen Geschäftsprozessen und der IT-Architektur an sich darstellen und die Unterstützung der Geschäftsprozesse durch die Informationstechnik verdeutlichen. Dies kann sowohl durch Entwicklung neuer Systeme bzw. Systemelemente als auch durch Auswahl und Anpassung bestehender Systemelemente geschehen. Damit Architekturen dieses Ziel erreichen können, müssen sie nach bestimmten Grundsätzen aufgebaut werden. Eine einheitliche Strukturierung von Architekturen erhöht weiterhin die Verständlichkeit und Weiter- bzw. Wiederverwendbarkeit von Architekturprodukten. Diese Strukturierung – und damit die Vorgabe eines Beschreibungsmodells – wird durch Architekturrahmenwerke (engl.: Architecture Frameworks) vorgenommen.

M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

205

206

R. Kreibich

15.2 Anforderungen an Architekturrahmenwerke Sowohl Unternehmensstrukturen als auch die implementierte IT-Unterstützung erreichen heutzutage leicht eine Größenordnung, die eine vollständige und ausreichend detaillierte Darstellung in einer einzigen Ansicht nicht mehr zulässt. Daher müssen die Inhalte einer Architektur strukturiert werden. Diesem Gedanken einer Strukturierung kommt die Tatsache entgegen, dass bestimmte Personengruppen – z. B. Management, Nutzer, Entwickler, Betriebspersonal – im Regelfall nur bestimmte, nicht aber alle Informationen über ein System benötigen. Weiterhin ist festzustellen, dass sich nicht nur die Inhalte, sondern auch der erforderliche Detaillierungsgrad nach den Anforderungen der Nutzergruppen (z. B. Management im Vergleich zu einem Datenbankadministrator) richten. Trotz des unterschiedlichen, meist exakt abgrenzbaren Informationsbedarfs sind jedoch die in einer Architektur beschriebenen Elemente in einem Zusammenhang zu betrachten. Gegenseitige Wechselwirkungen – auch über Interessengruppen hinaus – sind zwingend in einer Architektur darzustellen, um die angestrebte Zielstellung zu erreichen. Bereits hier werden grundlegende Anforderungen an Modelle zur Beschreibung komplexer technischer Systeme deutlich:  Sie müssen geeignet sein, ein System aus verschiedenen Blickwinkeln – dem des Entwicklers, Konstrukteurs, Nutzers, Wartungstechnikers – darzustellen. Dabei werden verschiedene, dem Betrachtungsgegenstand angepasste Darstellungsformen genutzt. Diese verschiedenen Beschreibungen – Sichten genannt – weisen gemeinsame, teilweise jedoch auch unterschiedliche Inhalte auf. Erst zusammen ergeben sie eine vollständige Beschreibung des Systems.  Sie müssen geeignet sein, sowohl die innere Struktur eines Systems als auch seine Einbindung in einen Systemverbund darzustellen. Das erfordert die Möglichkeit, detaillierte Informationen zu übersichtlichen Darstellungen zu aggregieren oder aus generischen Darstellungen detaillierte Beschreibungen abzuleiten.  Die Beschreibung komplexer Systeme erfordert taxonomische Vorgaben, die die Beschreibung strukturieren und damit überhaupt lesbar und außerdem über diese Strukturierung Systeme vergleichbar machen.  Verständlichkeit und breite Nutzbarkeit derartiger Beschreibungen erfordern ein standardisiertes Beschreibungsmodell mit einem vereinheitlichten Zeichenvorrat.

15.3 Aufbau von Architekturrahmenwerken Allen Architekturrahmenwerken ist gemeinsam, dass sie eine möglichst vollständige Beschreibung komplexer IT-Systeme ermöglichen sollen. Dies umfasst neben der Beschreibung der IT-Architektur, ihrer Funktionen und Schnittstellen auch die Beschreibung der zu unterstützenden Prozesse und der notwendigen Ablauforganisation.

15 Architekturrahmenwerke

207

Zur stringenten Ableitung der Forderungen an die IT-Systeme und auch zur übersichtlichen Darstellung wird dabei die Beschreibung in unterschiedliche Sichten aufgeteilt. Eine Sicht fasst dabei die für eine Anwendergruppe relevanten Inhalte zusammen. Anwendergruppen können z. B. Systementwickler, Nutzer, Betriebspersonal, aber auch das Management sein. Selbst innerhalb einer Sicht sind die darzustellenden Informationen zu komplex und zu umfangreich, als dass sie sich in einem einzigen Diagramm darstellen ließen. Deshalb erfolgt eine weitere Unterteilung in so genannte Teilsichten (engl.: Subviews). Subviews dienen der Strukturierung der Informationen. Sie grenzen den Inhalt auf bestimmte Aspekte ein. In den Subviews werden die Informationen im Regelfall in Diagrammen dargestellt. Die grafische Darstellung trägt zu einer höheren inhaltlichen Konsistenz bei, ermöglicht sie doch die Darstellung von Zusammenhängen, die rein verbal kaum oder gar nicht zu beschreiben sind. Wesentlicher Träger der Informationen sind dabei Objekte, die auf den Diagrammen angeordnet sind. Ein Objekt kann z. B. ein Prozessschritt, ein Organisationselement, eine Systemkomponente oder eine Systemfunktion sein. Diese Objekte werden durch Attribute näher beschrieben, z. B. Namen, Beschreibung und Referenzdokumente. In einer Architektur werden diese Objekte miteinander verknüpft. So ist zum Beispiel ein Prozessschritt (oder eine Aktivität) durch Informationen mit anderen Prozessschritten verbunden: Eine Aktivität benötigt bestimmte Eingangsinformationen, die in anderen Aktivitäten generiert werden. Andererseits lassen sich die durchzuführenden Aktivitäten bestimmten Elementen der Ablauforganisation zuordnen. Die Prozessschritte sind durch Systemfunktionen der eingesetzten Hard- und Software zu unterstützen, der Austausch von Informationen durch entsprechende Kommunikationsverbindungen – mit bestimmten Schnittstellen, Standards und Protokollen. Insgesamt ergibt sich eine vielfältige Verknüpfung der verschiedenen Objekte innerhalb eines Diagramms als auch über die Grenzen einer (Teil-)Sicht hinaus. Wie diese Verknüpfungen ausgestaltet werden, also welche Objekttypen zueinander in Beziehung gesetzt werden, wird im Architekturrahmenwerk beschrieben. Meist wird zur Darstellung dieser Zusammenhänge ein Metamodell benutzt.

15.4 Vergleich verschiedener Architekturrahmenwerke Architekturen können und sollen einen sehr breiten Anwendungsbereich abdecken, der grundsätzlich vom Kleinunternehmen bis zu einem multinationalen Konzern reicht. Dies führt einerseits zu einem sehr großen Vorrat an nutzbaren Diagrammen, Objekten und Attributen, andererseits ergeben sich sehr komplexe Metamodelle. Je nach Unternehmensgröße und Komplexität der Geschäftsprozesse wird es jedoch in vielen Fällen nicht notwendig sein, ein derart komplexes Beschreibungsmodell zu wählen. In diesen Fällen kann eine Architektur auch ohne die explizite Nutzung eines Rahmenwerks erstellt werden, in welchem die zu beschreibenden Objekte, ihre At-

208

R. Kreibich

tribute und ihre Beziehungen definiert werden. Dieser Ansatz stößt jedoch bei steigender Komplexität der Geschäftsprozesse und/oder der IT-Landschaft schnell an seine Grenzen.

15.4.1 Prozessmodelle und Architekturrahmenwerke Grundsätzlich ist auch die Nutzung bestehender Prozessmodelle und deren anschließende Erweiterung um Anteile zur Darstellung von IT-Architekturen denkbar. In diesem Fall erfolgt die Darstellung der IT-Architektur meist getrennt vom eigentlichen Prozessmodell und im Regelfall auch unter Nutzung anderer Modellierungswerkzeuge. Damit ist aber auch die logische, stringente und konsistente Verknüpfung der Unternehmensprozesse mit der IT-Architektur nur schwer möglich. Der obige Ansatz ist stark auf die Prozessmodelle zur Darstellung der Unternehmensprozesse fokussiert. Kurzfristig können sich damit durchaus Vorteile ergeben, da in vielen Fällen bereits erstellte Prozesslandschaften bzw. Synergieeffekte bei Beschaffung und Nutzung der entsprechenden Werkzeuge zur Anwendung kommen. Allerdings sind die vorhandenen Metamodelle meist sehr starr und können – im Gegensatz zu den Metamodellen eines „echten“ Architekturrahmenwerkes – nur schwer auf die Erfordernisse des jeweiligen Unternehmens angepasst werden. Daher gestaltet sich die Darstellung der Wechselwirkungen zwischen Geschäftsprozessen und IT-Unterstützung – also der eigentliche Inhalt einer Unternehmensarchitektur – als schwierig.

15.4.2 IT-Architekturen und Architekturrahmenwerke Wie bereits dargestellt, sollen mit Hilfe von Architekturrahmenwerken komplexe soziotechnische Systeme in einem ganzheitlichen Ansatz beschrieben werden. Herkömmliche IT-Architekturen (auch Softwarearchitekturen usw.) sind jedoch auf Hard- bzw. Software, ihre Funktionen und ihre Verbindungen fokussiert und lassen daher diesen ganzheitlichen Ansatz vermissen. Grundsätzlich ist auch hier eine Erweiterung in Richtung der Darstellung von Unternehmensprozessen möglich, allerdings treten ähnliche Probleme wie bei der Nutzung herkömmlicher Prozessmodelle auf. Letztendlich wird man dabei nicht vermeiden können, mit erheblichem Aufwand ein Metamodell zur Beschreibung komplexer soziotechnischer Systeme zu entwickeln – welches jedoch in Form verschiedener Architekturrahmenwerke bereits vorliegt.

15.4.3 Zivile Architekturrahmenwerke Den Ausgangspunkt für die Entwicklung der Architekturrahmenwerke bildet das 1987 von John Zachman vorgestellte Zachman Framework (Zachman International,

15 Architekturrahmenwerke

209

2008). Zachman fasste zum ersten Mal alle für die Beschreibung eines Systems relevanten Informationen in einem Beschreibungsmodell zusammen und strukturierte Erarbeitung und Darstellung in verschiedenen Sichten. Ein weiterer Entwicklungsschritt war das von The Open Group vorgestellte The Open Group Architecture Framework (TOGAF; The Open Group, 2009). Neben einem veränderten Zuschnitt der einzelnen Sichten und den unterschiedlichen Objekten und Attributen ist vor allem bemerkenswert, dass es sich um einen offenen Standard handelt und dass TOGAF dynamisch weiterentwickelt wird. Zudem erweitert das TOGAF den Ansatz von Zachman um ein Vorgehensmodell für die Weiterentwicklung von Architekturen (Architecture Development Method – ADM). In den USA sind mit dem Treasury Enterprise Architecture Framework (TEAF; Department of the Treasury, 2000) und dem Federal Enterprise Architecture Framework (FEAF; OMB, 2009) Architekturrahmenwerke entwickelt worden, die auf eine Anwendung im Bereich der öffentlichen Verwaltung abzielen. Die genannten Architekturrahmenwerke wurden vorrangig für den zivilen Bereich entwickelt und bieten grundsätzlich die Möglichkeit, auch komplexe Unternehmensstrukturen und die notwendige IT-Unterstützung zu beschreiben. Dennoch haben sich im zivilen Bereich auch andere Ansätze durchgesetzt, bis hin zur Architekturmodellierung ohne Nutzung eines bestimmten Frameworks.

15.4.4 Militärische Architekturrahmenwerke Neben den oben beschriebenen Architekturrahmenwerken haben sich im militärischen Bereich weitere Architekturrahmenwerke etabliert. Dabei können grundsätzlich drei Entwicklungslinien unterschieden werden:  das Architekturrahmenwerk des britischen Ministry of Defence – Ministry of Defence Architecture Framework (MoDAF, U.K. Ministry of Defence, 2008)  das Architekturrahmenwerk des amerikanischen Department of Defense – Department of Defense Architecture Framework (DoDAF; U.S. Department of Defense, 2007)  das Architekturrahmenwerk der NATO – NATO Architecture Framework (NAF; NC3B, 2004)). Die genannten Architekturrahmenwerke werden ständig weiterentwickelt und liegen mittlerweile in verschiedenen Versionen vor. Sie weisen starke inhaltliche Überschneidungen auf und nähern sich in ihren letzten Versionen stark aneinander an. Grund für die Entwicklung eigenständiger militärischer Rahmenwerke waren die besonderen Anforderungen im militärischen Bereich. Einige Sichten bzw. Objekte der zivilen Frameworks waren für den militärischen Bereich entbehrlich bzw. in bisheriger Form nicht verwendbar. Aufgrund der ursprünglich starken Ausrichtung auf militärisch einsatzrelevante Anwendungsfälle hat z. B. die NATO anfänglich auf die Darstellung haushalterischer und planerischer Aspekte verzichtet, sie aber mittlerweile, allerdings an Vorgaben und Rahmenbedingungen der NATO ausgerichtet, aufgenommen.

210

R. Kreibich

Weiterhin weisen militärische Strukturen eine ausgeprägte Orientierung auf die Aufbauorganisation auf, die Ablauforganisation weicht je nach Aufgabenstellung und Rahmenbedingungen stark von dieser ab. Typischerweise können einem Element der Aufbauorganisation in verschiedenen Szenarien/Missionen unterschiedliche Rollen in der Ablauforganisation zugewiesen werden. So kann z. B. eine Jägerkompanie der Bundeswehr bei einem Angriff, aber auch an einem Checkpoint eingesetzt werden. Aufgaben, Rahmenbedingungen, Binnengliederung und Informationsaustauschbeziehungen sowohl inner- als auch außerhalb der Kompanie unterscheiden sich in beiden Fällen erheblich. Militärische Rahmenwerke müssen die Darstellung derartig flexibler Szenarien und Missionen ermöglichen, während im zivilen Umfeld Aufgaben und Rahmenbedingungen für eine Organisationseinheit im Betrachtungszeitraum weitgehend konstant bleiben. Dabei entspricht – zumindest für die Betrachtung des Kerngeschäfts – die Aufbauorganisation weitgehend der Ablauforganisation. Größe und Komplexität militärischer Organisationen, besonders multinationaler Organisationen wie der NATO, lassen im Regelfall eine zentrale Er- und Bearbeitung von Architekturmodellen nicht zu. Diese erfolgt meist dezentral in verschiedenen Organisationselementen durch unterschiedlich ausgebildetes Personal. Neben dem hohen Grad an Verbindlichkeit müssen daher militärisch nutzbare Architekturrahmenwerke auch weitergehende taxonomische Vorgaben – z. B. zur Strukturierung von Diensten oder Systemfunktionen – aufweisen. Schließlich besitzen militärische Bereiche meist eine sehr große, sehr komplexe, vernetzte Unternehmensarchitektur, die zur Unterstützung ebenfalls sehr komplexe und vernetzte IT-Systeme – unter Berücksichtigung entsprechender Kommunikationssysteme – benötigt. Gerade diese Ausrichtung macht militärische Architekturrahmenwerke aber wiederum für die Anwendung in großen und komplex aufgebauten Unternehmen interessant. Auch bei Nutzung militärischer Architekturrahmenwerke wird jedoch ein Zuschneiden auf den konkreten Anwendungsfall – das so genannte Tailoring – zwingend erforderlich sein.

15.4.5 Abstraktion und Detaillierung Architekturrahmenwerke fassen, wie bereits dargestellt, in unterschiedlichen Sichten die für eine Benutzergruppe relevanten Informationen zusammen. Aber auch innerhalb einer Anwendergruppe werden Umfang und Detaillierungsgrad der dargestellten Informationen sehr schnell so groß, dass sie sich nicht mehr vernünftig aufbereiten und darstellen lassen. In der Praxis ergibt sich daher sehr schnell die Notwendigkeit, die Inhalte einer Architektur zu abstrahieren, um sie für höhere Managementebenen rollengerecht aufzubereiten. Umgekehrt müssen strategische Zielvorgaben des Managements – sowohl im Bereich der Unternehmensprozesse als auch der IT-Unterstützung – weiter detailliert und konkretisiert werden.

15 Architekturrahmenwerke

211

Architekturrahmenwerke müssen also sicherstellen, dass  in einem Top-Down-Ansatz strategische Vorgaben detailliert und konkretisiert werden können und  in einem Bottom-Up-Ansatz detaillierte Darstellungen zu grundsätzlichen Aussagen abstrahiert werden können. Im Bereich der NATO waren derartige Vorgaben ursprünglich nicht im eigentlichen Architekturrahmenwerk – dem NAF – enthalten. Die NATO Interoperability Directive (NID) gibt hier so genannte Architektursichten vor, die sich in Umfang, Detaillierungsgrad und Zeithorizont unterscheiden.

15.4.6 Vorgehensmodelle Während Zachman in seinem Framework noch auf ein Vorgehensmodell verzichtete, wurde im TOGAF mit der Method of Architecture Development (MAD) das Vorgehen zur Erstellung einer Architektur beschrieben. Auch das NAF weist mittlerweile Vorgaben zur Erstellung von Architekturen auf. Die Nutzung von Vorgehensmodellen setzt die Anpassung der Unternehmensstrukturen voraus. Kann dies nicht geschehen, z. B. im militärischen Bereich, können sie nur empfehlenden Charakter tragen. In der Bundeswehr existieren z. B. mit dem Customer Product Management (CPM; BMVg Org 1, 2004) und dem Vorgehensmodell (V-Modell) Verfahrensvorschriften für Bedarfsermittlung und -deckung. Sollen Architekturen hier genutzt werden, muss sich ihre Erstellung, aber auch ihre weitere Nutzung, an den Vorgaben des CPM bzw. des V-Modells ausrichten.

15.5 Anwendungsfälle für Architekturen Architekturen dienen zur Beschreibung komplexer Systeme, ihrer Bestandteile und deren Beziehungen. Mit dieser Definition ist bereits ein Anwendungsbereich von Architekturen genannt: die Dokumentation. Sowohl Unternehmensprozesse als auch IT-Architekturen sind heutzutage komplex, umfangreich, voneinander abhängig und unterliegen sehr schnellen Änderungen. Bisherige Beschreibungsmodelle leiden entweder unter dem Verzicht auf wesentliche Aspekte (Fokussierung auf Unternehmensprozesse oder IT-Architektur), an fehlenden Abstraktions- bzw. Detaillierungsmöglichkeiten oder lassen u. U. die Beschreibung komplexer Sachverhalte überhaupt nicht mehr zu. Dies führt in der Praxis dazu, dass wesentliches Wissen nur in den Köpfen der Mitarbeiter zur Verfügung steht, was eine unternehmensweite Nutzung des Wissens erschwert. Organisationsänderungen oder Fluktuation der Mitarbeiter führen

212

R. Kreibich

zu weiteren Wissensverlusten. Architekturen bieten demgegenüber den ganzheitlichen Ansatz, lassen sich verteilt und damit unternehmensweit erstellen, bearbeiten und nutzen und an veränderte Aufgabenstellungen und Technologien anpassen. Architekturen bieten damit die Chance einer Dokumentation, die mit dem Unternehmen wächst. Ein weiterer Anwendungsfall, der klassischerweise auch immer zur Erläuterung der Methode der Architekturmodellierung genutzt wird, ist die Entwicklung von Systemen und Systemverbünden. Die stringente Ableitung von Forderungen aus den Geschäftsprozessen an die IT-Unterstützung vermeidet Fehlinvestitionen, bietet die Chance der Nutzung bereits vorhandener Systeme, Services und Funktionen, eröffnet die Möglichkeit einer anwenderseitig zielgerichteten Weiterentwicklung der IT-Landschaft (stellt damit eine Umkehr des bisher vorherrschenden technologiegetriebenen Ansatzes dar) und verbessert damit letztendlich die Nutzung der meist begrenzt vorhandenen Ressourcen. Folgerichtig ergibt sich hier der nächste Anwendungsfall: die Analyse bestehender Systeme. Einerseits stellt sich gerade in größeren Unternehmen sehr oft die Frage, ob die vorhandene IT-Architektur die Geschäftsprozesse ausreichend unterstützt, wo Anpassungsbedarf besteht und welche Bereiche der IT-Architektur optimiert – ggf. sogar eliminiert – werden können. Stehen verschiedene technische Lösungsansätze zur Auswahl, kann mit Hilfe einer Architektur bewertet werden, welcher Lösungsansatz die Vorgaben am besten erfüllt. Neben dieser auf die Weiterentwicklung der IT-Landschaft gerichteten Anwendung können Architekturen für die Optimierung des Betriebs der IT-Systeme genutzt werden. Mit Hilfe von Architekturen kann festgestellt werden, welche Auswirkungen die Nichtverfügbarkeit bestimmter Systeme, Systemkomponenten, Services und Systemfunktionen auf die Geschäftsprozesse eines Unternehmens hat. In den letzten Jahren hat sich mit der Geschäftsprozessanalyse für Architekturen ein weiterer Anwendungsfall erschlossen. In Unternehmen implementierte Geschäftsprozesse (einschließlich der Ablauforganisation und der Informationsaustauschbeziehungen) können untersucht und optimiert, neue Geschäftsprozesse konzipiert, modelliert und auf Tauglichkeit geprüft werden. Grundsätzlich wäre diese Aufgabe auch mit den hinlänglich bekannten Methoden zur Prozessmodellierung zu erfüllen. Architekturen bieten jedoch den Vorteil, dass die IT-Unterstützung nach Validierung und Bestätigung des entsprechenden Geschäftsmodells direkt, ohne Verzögerung und Medienbrüche, entwickelt werden kann. Auch ermöglicht die Methode eine Untersuchung, ob neue Aufgabenfelder überhaupt bzw. mit angemessenem Aufwand durch die Informationstechnik unterstützt werden können. Daneben kann über diesen Ansatz auch ein einheitliches Verständnis über wahrzunehmende Aufgaben, Führungsverfahren und -organisation entwickelt werden.

15 Architekturrahmenwerke

213

15.6 Das NATO Architecture Framework Das NAF liegt seit Ende 2007 in der Version 3.0 vor. Im Folgenden soll zunächst kurz auf die Version 2.0 eingegangen werden, da an ihr die grundsätzlichen Prinzipien des Aufbaus des NAF verdeutlicht werden können.

15.6.1 NATO C3 Systems Architecture Framework Version 2 Das NAF v2.0 ist auf die Beschreibung von Kommunikations- und Informationssystemen und deren Anwendung ausgerichtet. Es dient zur Darstellung der Aufbau- und Ablauforganisation, der durchzuführenden Aktivitäten, der Informationsaustauschbeziehungen und der daraus abgeleiteten systemtechnischen Lösungen. Aspekte der Weiterentwicklung bzw. der Finanzplanung werden hier weitgehend vernachlässigt. Das NAF v2.0 sieht drei Sichten vor:  Die Operationelle Sicht – NATO Operational View (NOV)  Die Systemsicht – NATO System View (NSV)  Die Technische Sicht – NATO Technical View (NTV). Übergreifende Aspekte der Architektur werden im NATO All View (NAV) dargestellt. Im Operational View werden Aufbau- und Ablauforganisation, durchzuführende Aktivitäten und die Informationsaustauschbeziehungen dargestellt. Dazu finden im NOV verschiedene Teilsichten Verwendung. Im Folgenden sollen die wesentlichen Inhalte des Operational View kurz vorgestellt werden. Kern des NOV ist die Darstellung der Aktivitäten und ihrer Verknüpfung durch Informationsaustauschbeziehungen. Diese Darstellung erfolgt im NOV-5 Operational Activity Diagram. Der Grundgedanke ist, dass jegliche Aktivität bestimmte Informationen als Eingangsgröße benötigt, wenn sie ausgeführt werden soll. Weiterhin generiert jede Aktivität aber auch Informationen, die von anderen Aktivitäten benötigt werden. Daneben existieren noch weitere Informationstypen – Trigger und Mechanismen – die die Informationsverarbeitung steuern bzw. ermöglichen. Durch die Verknüpfung der Aktivitäten mittels Informationen ergibt sich damit eine Darstellung der durchzuführenden Aktivitäten – und damit der wahrzunehmenden Aufgaben – und die Darstellung der Informationsflüsse. Im Unterschied zu einem Prozessmodell erfolgt jedoch keine zeitliche Taktung, auch werden logische Verzweigungen und Verknüpfungen nicht dargestellt. Bestehende Prozessmodelle lassen sich jedoch in Aktivitäten überführen, auch ist die Erweiterung des Aktivitätenmodells zu einem Prozessmodell durchaus möglich. Die Notierung erfolgt in einer IDEF-0-Notation, die Verwendung von UML ist jedoch ebenfalls möglich. Im Operational View werden Informationen beschrieben, die durch Name, Inhalt, Medientyp und ggf. strukturelle Vorgaben (z. B. Meldeformate) gekennzeichnet sind, nicht jedoch auszutauschende Daten und deren Formate. Auch innerhalb einer Architektur (und damit auf der Ebene eines Architekturtyps) wird im Regelfall eine Abstraktion bzw. eine Detaillierung erforderlich sein.

214

R. Kreibich

Bestimmte generische Aktivitäten lassen sich in einzelne, weiter detaillierte Aktivitäten auflösen, detaillierte Aktivitäten wiederum zu generischen Aktivitäten zusammenfassen. Derartige Beziehungen zwischen Aktivitäten werden im NOV-5 Operational Activity Hierarchy Diagram dargestellt. Die Darstellung der Zuordnung erfolgt in einer hierarchischen Baumstruktur. Bislang erstreckte sich die Modellierung auf die Beantwortung der Frage, was zu tun ist. Im NOV-2 Operational Node Connectivity Diagram werden nun die modellierten Aktivitäten bestimmten Elementen der Ablauforganisation, den Operational Nodes, zugeordnet. Operational Nodes können Organisationselemente, deren Untergliederungen, einzelne Rollen, aber auch Plattformen, Sensoren und Aktivitäten sein. Da nun aber die Aktivitäten durch Informationen miteinander verknüpft sind, müssen nach erfolgter Zuordnung der Operational Activities zu Operational Nodes diese Informationen ausgetauscht werden. Der Informationsaustausch erfolgt über Informationsaustauschbeziehungen (Information Exchanges), denen eine oder mehrere auszutauschende Informationen zugeordnet werden. Die Information Exchanges werden auf so genannten Needlines angeordnet, die im weitesten Sinne Kommunikationskanäle darstellen. Die zusammenfassende Darstellung der Information Exchange Requirements erfolgt in der NOV-3 Information Exchange Requirements Matrix in Form einer Tabelle. Das NOV-3 wird im Regelfall aus anderen Bestandteilen der Architektur generiert und gibt Auskunft darüber, welche Information (mit welchen konkreten Charakteristika) von wem zur Erfüllung welcher Aufgabe benötigt bzw. generiert wird. Im NOV-4 Organisation Relationships Chart wird die Organisationsstruktur, also die Aufbauorganisation, dargestellt. Gerade im militärischen Bereich kann ein Element der Aufbauorganisation in verschiedenen Szenarien/Missionen unterschiedliche Aufgaben wahrnehmen, also unterschiedlichen Operational Nodes zugeordnet werden. Andererseits kann ein bestimmter Operational Node von unterschiedlichen Elementen der Aufbauorganisation gestellt werden. Diese Zuordnung erfolgt ebenfalls im NOV-2. In Verbindung mit dem System View ermöglicht diese Zuordnung einen Ausblick auf die Ausrüstungsplanung. Aber bereits im Operational View werden über die Zuordnung zu bestimmten Operational Nodes und damit bestimmten Aufgaben Erfordernisse für Ausbildung und Einsatzvorbereitung verdeutlicht. Im System View werden die systemtechnischen Lösungsansätze dargestellt. Dazu müssen die Systeme, ihre Bestandteile und Funktionen, ihre Beziehungen untereinander und ihre Zuordnung zu den Elementen des Operational Views dargestellt werden. Das Äquivalent zu den Operational Nodes bilden die System Nodes. Im Regelfall wird ein System Node einem Operational Node zugeordnet (wobei einem Operational Node wiederum mehrere System Nodes zugeordnet werden können). Unter Umständen kann die Zuordnung eines System Node zu einem Operational Node jedoch nicht erfolgen, nämlich dann, wenn der System Node lediglich aus technischen bzw. betrieblichen Zwecken erforderlich ist, den Inhalt der Informationen jedoch nicht verändert.

15 Architekturrahmenwerke

215

Jedem System Node werden wiederum Systeme zugeordnet. Dabei können Systeme wiederum auf mehreren Ebenen in einzelne Bestandteile aufgelöst werden. Diese Zuordnung erfolgt im NSV-1 Systems Interface Description. Systeme verfügen über so genannte Systemfunktionen (engl.: System Functions). Die Gliederung der Systemfunktionen wird im NSV-4 System Functions Description analog zum NOV-5 Node Tree für operationelle Aktivitäten dargestellt. Zur Unterstützung einer bestimmten Aktivität werden im Regelfall Systemfunktionen benötigt. Diese Zuordnung wird in der NSV-5 Operational Activity to System Function Traceability Matrix vorgenommen. Über Operational Node – Operational Activity – System Function – System – System Node – Operational Node ergibt sich eine Zuordnungskette, die in beiden Richtungen durchlaufen werden kann. Ausgehend von den einem Organisationselement zugeordneten Aufgaben können die erforderlichen Systemfunktionen ermittelt bzw. festgelegt werden. Daraus kann abgeleitet werden, welche Systemfunktionen in welchem System zu implementieren sind. Dieses System wird wiederum einem System Node und damit implizit einem Operational Node zugeordnet. Im Rahmen einer Analyse bestehender Systemverbünde oder der Prüfung auf deren Eignung für die Unterstützung bestimmter Aufgaben lassen sich somit Defizite ermitteln und darstellen. Eine weitere Möglichkeit ist der Vergleich verschiedener Systemlösungen. Ähnlich der oben angegebenen Zuordnung lassen sich Information Exchanges zu so genannten Data Exchanges zuordnen. Diese Zuordnung dient der Realisierung des Datenaustausches und erlaubt es, Kommunikationsanteile abzubilden. Diese Zuordnung erfolgt im NSV-2 System Communications Description. Im Technical View werden die verwendeten Schnittstellen, Standards, Protokolle, Produkte usw. und deren Beziehungen dargestellt und detailliert beschrieben. Die Zuordnung der in den einzelnen Diagrammen beschriebenen Elemente zu den Systemen und deren Bestandteilen erfolgt in der Regel im System View.

15.6.2 NATO Interoperability Directive Bereits innerhalb einer Architektur kommen im Regelfall mehrere Abstraktionsebenen zur Anwendung. Umfang und Komplexität selbst „einfacher“ IT-Projekte erreichen schnell eine Größenordnung, die eine vollständige und detaillierte Darstellung zugleich nicht zulässt. Dies erfordert die Abstraktion detaillierter Aussagen zu grundsätzlichen Darstellungen und unterstützt umgekehrt die Ableitung detaillierter Inhalte aus grundsätzlichen Vorgaben. Die NATO Interoperability Directive (NID) führt diesen Gedanken weiter und definiert drei Architekturtypen, die sich in Umfang, Granularität und Zeithorizont unterscheiden:  Die Overarching Architecture gibt für einen Zeitraum von typischerweise 12–15 Jahren die Zielvorstellungen möglichst umfassend, aber auf einem hohen Abstraktionsniveau vor.

216

R. Kreibich

 Die Reference Architecture schränkt den Betrachtungsgegenstand ein und detailliert ihn für einen Betrachtungszeitraum von 6–8 Jahren.  Die Target Architecture stellt für einen Zeitraum von 2–4 Jahren einzelne Realisierungsschritte detailliert dar. Die Inhalte einer Overarching Architecture werden in mehreren, zeitlich parallel oder aufeinander folgenden Reference Architectures umgesetzt. Diese wiederum werden in verschiedenen, ebenfalls zeitlich parallel oder aufeinander folgenden Target Architectures realisiert. Mit den Vorgaben der NID ist eine Formulierung strategischer Zielsetzungen, die Ableitung von Fähigkeitsforderungen und schließlich deren Detaillierung in einzelne Projekte bzw. Projektschritte nach CPM möglich.

15.6.3 NATO Architecture Framework Version 3.0 Das NAF in der Version 2 zielt auf die Entwicklung komplexer, vernetzter ITSysteme ab. Mit der mittlerweile vorliegenden Version 3 wurde diese Beschränkung aufgehoben. Die Methode ist nun grundsätzlich für alle denkbaren Anwendungsfälle, also auch außerhalb der Kommunikations- und Informationstechnik, geeignet. Gleichzeitig wurden mit dem Capability View und dem Program View zwei neue Sichten eingeführt, die projektübergreifend und langfristig die Bereitstellung von Fähigkeiten unterstützen und die dazu erforderlichen Maßnahmen planen helfen. Wesentlichste Neuerung ist jedoch der Service Oriented View, der den Gedanken der Service- bzw. Dienstorientierung aufgreift. Nach dem Verständnis des Frameworks sind hier Services nicht auf IT-Services im eigentlichen Sinne beschränkt. Die Inhalte der NID wurden im Wesentlichen in das Framework integriert.

15.7 Architekturen in der Bundeswehr Es ist offensichtlich, dass die Architekturmodellierung – bei allen Chancen und Möglichkeiten, die sie bietet – einen nicht unerheblichen Aufwand erfordert. Besonders die stark strukturierte und formalisierte Darstellung der Inhalte erfordert neben konzeptionellen Vorarbeiten auch die Bereitstellung entsprechender betrieblicher Mittel, und sie verbraucht nicht unerhebliche Ressourcen.

15.7.1 Architekturbasierter Ansatz und Anwendung von Architekturrahmenwerken Der Grundgedanke lässt sich jedoch auch in einem architekturbasierten Ansatz – unter Vernachlässigung formaler Aspekte und unter weitgehendem Verzicht auf eine Werkzeugunterstützung – verwirklichen. Wesentlich sind dabei zum einen der

15 Architekturrahmenwerke

217

gesamtheitliche Ansatz, der sowohl Geschäftsprozesse, IT-Unterstützung als auch deren gegenseitige Abhängigkeiten beschreibt, und die Strukturierung der Darstellung in Sichten, die der Verantwortung und damit dem Informationsbedarf bestimmter Anwendergruppen folgt. Im Vergleich zum beispielsweise in der Bundeswehr im Bereich der Bedarfsermittlung und -deckung verfolgten Ansatz, der auf einer textuellen Darstellung und lose verknüpften grafischen Dokumenten, IT-Architekturen usw. beruht, ergibt sich bereits bei Anwendung eines architekturbasierten Ansatzes sowohl eine stringentere Form der Darstellung als auch eine logischere Darstellung der zu implementierenden Systeme, Systemkomponenten, Services und Funktionen.

15.7.2 Bedarfsermittlung und -deckung im Verantwortungsbereich des IT-Direktors Die Methode der Architekturmodellierung kann und soll in der Bundeswehr in einem breiten Rahmen eingesetzt werden. Dieser reicht von der Begleitung konzeptioneller Arbeit, wie etwa der Entwicklung von Teil- und Einzelkonzeptionen bis zu den einzelnen Phasen eines Projektes nach CPM. Für den Verantwortungsbereich des IT-Direktors der Bundeswehr lässt sich für den Bereich der Führungsinformationssysteme kurz folgender Ansatz skizzieren: In einer Overarching Architecture wird im Operational View dargestellt, wie sich Führungsverfahren und Führungsorganisation sowie daraus abgeleitet die Informationsaustauschbeziehungen langfristig entwickeln. In einem System View wird festgelegt, welche Führungsinformationssysteme mit welchen Systemfunktionen wo genutzt werden sollen. Im Technical View wird aufgeführt, welche Standards und Protokolle im Betrachtungszeitraum zur Anwendung kommen sollen. Aus dem Vergleich der Inhalte dieser Architektur mit dem gegenwärtigen Zustand des IT-Systems Bw (Honekamp, 2006) leitet sich die Migrationsstrategie ab. In der Reference Architecture wird – inhaltlich und zeitlich begrenzt – dargestellt, wie sich einzelne Führungsinformationssysteme entwickeln. Dazu werden die Vorgaben der Overarching Architecture weiter detailliert. Die Ebene der Reference Architecture bildet damit die Migrationsplanung des IT-Systems Bw ab. In der Target Architecture sind einzelne, zeitlich, haushalterisch und technisch beherrschbare Projekte bzw. Projektschritte abgebildet. Abgeleitet wird die Target Architecture aus den Vorgaben der Reference Architecture. Ihre Erstellung erfolgt in den einzelnen Phasen des CPM. Während in der Analysephase im Wesentlichen die Inhalte des Operational View zu befüllen sind, wird in der Projektierungsphase der System View erstellt. Architekturprodukte ermöglichen hier sowohl die Ableitung von Systemlösungen aus den funktionalen Forderungen als auch den Vergleich unterschiedlicher Lösungsvarianten. Sie dienen ebenso als Grundlage für Leistungsbeschreibungen, Pflichten- und Lastenhefte, ermöglichen die Bewertung der Angebote verschiedener Auftraggeber und dienen als Ausgangspunkt für durchzuführende Tests und Prüfungen.

218

R. Kreibich

Mit der Anwendung der Methode im Verantwortungsbereich des IT-Direktors sollen im Wesentlichen folgende Ziele erreicht werden:  Einzelne Projekte werden aus langfristigen, strategischen Vorgaben abgeleitet bzw. in diese eingebettet. Damit wird erstmals eine ganzheitliche Betrachtung des IT-Systems Bw möglich.  Dies ermöglicht einen Vergleich verschiedener Projekte, ihre Bewertung vor dem Hintergrund der Auftragserfüllung der Bundeswehr insgesamt und schlussendlich eine Priorisierung.  Abhängigkeiten und Wechselwirkungen zwischen einzelnen Projekten, auch außerhalb des Verantwortungsbereichs des IT-Direktors treten deutlich hervor.  Die Projekte des IT-Systems Bw lassen sich inhaltlich und zeitlich besser strukturieren und damit in zeitlich, finanziell und haushalterisch beherrschbaren Schritten realisieren.  Operationelle Forderungen werden konsistent dargestellt. Damit wird eine stringente Ableitung von Lösungsansätzen sowie der Vergleich verschiedener Lösungsansätze im Hinblick auf die Erfüllung operationeller Forderungen möglich.  Gleiche bzw. ähnliche Forderungen sowie vorhandene Lösungen werden deutlicher sichtbar; damit lassen sich Synergieeffekte nutzen.  Die projektübergreifende Identifizierung gleicher bzw. ähnlicher Forderungen ist schließlich Voraussetzung für den Übergang zu einer Serviceorientierten Architektur (SOA). Es werden im Verantwortungsbereich des IT-Direktors nicht unerhebliche Anstrengungen notwendig sein, um diese Methode zu etablieren. Die Anwendung der Methode eröffnet jedoch die Möglichkeit, das IT-System Bw schnell, effizient und an den Forderungen der Bedarfsträger orientiert weiterzuentwickeln.

Literaturverzeichnis BMVg Org 1 (2004). Customer Product Management (CPM) – Verfahrensbestimmungen für die Bedarfsermittlung und Bedarfsdeckung in der Bundeswehr. http://www.bwb.org/ 02DB022000000001/vwContentByKey/W26GXEDT127INFODE/$File/CPM.pdf. Department of the Treasury – Chief Information Officer Council (2000). Treasury Enterprise Architecture Framework Version 1. http://www.eaframeworks.com/TEAF/teaf.doc. Honekamp, W. (2006). Das IT-System der Bundeswehr. Strategie und Technik, (November). NC3B – NATO C3 Board (2004). NATO C3 System Architecture Framework v2 (NAF v2). AC/322-D(2004)0041. OMB – U.S. Office of Management and Budget (2009). Federal Enterprise Architecture. http:// www.whitehouse.gov/omb/egov/a-1-fea.html. The Open Group (2009). The Open Group Architecture Framework (TOGAF). http://www. opengroup.org/togaf/. U.K. Ministry of Defence (2008). MOD Architecture Framework Version 1.2. http://www.modaf. org.uk/. U.S. Department of Defense (2007). DoD Architecture Framework Version 1.5. www. defenselink.mil/dbt/products/2008_BEA_ETP/bea/products/DoDAF_Volume_I.pdf, www. defenselink.mil/dbt/products/2008_BEA_ETP/bea/products/DoDAF_Volume_II.pdf und www.defenselink.mil/dbt/products/2008_BEA_ETP/bea/products/DoDAF_Volume_III.pdf. Zachman International (2008). The Zachman Framework. http://www.zachmaninternational.com/.

Kapitel 16

Das Joint Consultation Command and Control Information Exchange Data Model Michael Gerz und Ulrich Schade

16.1 Einleitung Grundlage für die semantische Interoperabilität heterogener Führungsinformationssysteme ist ein gemeinsames und verbindliches Informationsaustausch-Referenzmodell, das sowohl für den Sender als auch für den Empfänger einer Nachricht die Bedeutung des Inhalts eindeutig definiert. Zur Beschreibung eines Referenzmodells können je nach Anforderungen verschiedene Beschreibungstechniken und -sprachen verwendet werden. So können z. B. XML-Schemata, relationale und objektorientierte Modelle, Ontologien, aber auch natürliche Sprache zum Einsatz kommen. Die Definition eines gemeinsamen semantischen Standards und die dazu erforderliche Konsensbildung innerhalb und insbesondere zwischen unterschiedlichen Communities of Interest (COIs) stellt eine große politische und technische Herausforderung dar. Dies gilt umso mehr für Anwendungsgebiete, in denen sich in der Vergangenheit eigenständige, proprietäre Lösungen entwickelt haben, da mit der Einführung eines gemeinsamen Standards teils umfangreiche Anpassungen an den bestehenden technischen Systemen verbunden sind. Nicht selten sind zur Definition einer gemeinsamen Semantik auch kulturelle Unterschiede und verschiedene Doktrinen abzugleichen. Für den Bereich der militärischen Führungssysteme hat sich mit dem Joint Consultation, Command and Control Information Exchange Data Model (JC3IEDM; MIP, 2008c) ein internationaler Standard entwickelt, der in den vergangenen Jahren zunehmend an Bedeutung für den Informationsaustausch zwischen FüInfoSys unterschiedlicher Nationen gewonnen hat. Das JC3IEDM wird im Rahmen einer Kooperation des Multilateral Interoperability Programme (MIP) mit der NATO entwickelt. MIP ist ein freiwilliges und nicht dem Management der NATO unterstelltes Programm, an dem 27 Nationen und das NATO Allied Command Transformation (ACT) beteiligt sind. Beim JC3IEDM handelt es sich um ein Entity-Relationship-Modell, das militärisch relevante Objekte und deren Eigenschaften mit Hilfe von Entitäten und deren M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

219

220

M. Gerz und U. Schade

Beziehungen, Attributen und Domänen beschreibt. Die Semantik des Datenmodells ist durch Definitionen für sämtliche Elemente, durch Geschäftsregeln und eine umfangreiche Begleitdokumentation beschrieben. Ziel des JC3IEDM ist es, den Informationsaustauschbedarf auf internationaler Ebene zu definieren, nicht jedoch die Gesamtheit aller Informationen, die in den jeweiligen nationalen Systemen benötigt werden. Im Folgenden geben wir einen kurzen Überblick über das Joint C3 Information Exchange Data Model. Nach einem kurzen historischen Abriss in Abschn. 16.2 stellen wir in Abschn. 16.3 die wichtigsten Informationsaustauschanforderungen vor, die in das JC3IEDM eingeflossen sind. Ein Überblick über den technischen Aufbau des JC3IEDM folgt in Abschn. 16.4. Das Entity-Relationship-Modell wird durch eine Vielzahl von Geschäfts- und Implementationsregeln ergänzt, die in Abschn. 16.5 erläutert werden. Das JC3IEDM wird mittlerweile nicht nur innerhalb von MIP, sondern auch in anderen militärischen und zivilen Projekten verwendet. Einige ausgewählte Beispiele sind in Abschn. 16.6 kurz beschrieben. Schließlich wird in Abschn. 16.7 aufgezeigt, wie durch einen modellgetriebenen Ansatz und die Unified Modeling Language (UML) zukünftig die Modellierung und Nutzung des JC3IEDM vereinfacht werden soll. Eine Zusammenfassung und ein kurzer Ausblick schließen dieses Kapitel ab.

16.2 Geschichtliche Entwicklung Das JC3IEDM kann auf eine lange Geschichte zurückblicken, während der das Modell sich nicht nur inhaltlich weiterentwickelt hat, sondern auch mehrmals umbenannt wurde. Die Notwendigkeit der Interoperabilität wurde bereits 1980 erkannt und führte zunächst zur Einrichtung des Programms Army Tactical Command and Control Information System (ATCCIS), welches ein Datenmodell zunächst unter der Bezeichnung Generic Hub (GH) entwickelte (vgl. historischer Rückblick in Kap. 1.2 auf Seite 7). Der Titel resultierte aus dem Ziel, ein flexibles Kernmodell zu spezifizieren, das sich an neue Informationsaustauschanforderungen anpassen lässt. Im Jahr 1999 wurde dieses Modell in Land Command and Control Information Exchange Data Model (LC2IEDM) umbenannt. Das Multilateral Interoperability Programme wurde 1998 gestartet. Aufgrund weitreichender inhaltlicher Übereinstimmung von ATCCIS und MIP wurden beide Programme im Jahr 2002 vereinigt. Für die MIP Baseline 1 wurde das LC2IEDM in der Version 2.2 verwendet. Im Zuge der nachfolgenden Aktivitäten flossen erste Belange der Marine in das Datenmodell ein und das Präfix Land wurde gestrichen. Die Ende 2005 verabschiedete, finale Spezifikation für die MIP Baseline 2 trägt die Bezeichnung C2IEDM 6.1e (MIP, 2004). Parallel zu MIP hat die NATO das NATO Corporate Data Model (NCDM) entwickelt und das LC2IEDM als sogenanntes View Model des NCDM im Sinne einer

16 JC3IEDM

221

COI-spezifischen Implementierungsgrundlage akzeptiert. Um die Kräfte zu bündeln, wurde Anfang 2004 in einem Memorandum of Agreement vereinbart, das Referenzmodell des NCDM mit dem C2IEDM unter der Regie von MIP zu einem einheitlichen Modell zu verschmelzen und das Ergebnis gemeinsam weiter zu entwickeln. Heeresspezifische Informationsaustauschanforderungen an das JC3IEDM werden dabei direkt innerhalb von MIP identifiziert und umgesetzt. Anforderungen der Luftwaffe und Marine werden über die NATO Data Management Services Working Group (NDMSWG) eingebracht. Das Modell wird seit der Fusion unter der Bezeichnung Joint C3 Information Exchange Data Model weiterentwickelt und von der NATO als Standardization Agreement (STANAG) 5525 geführt. Die aktuelle Version 3.1 des Datenmodells liegt gegenwärtig als Entwurfsspezifikation vor und ist Bestandteil der MIP Baseline 3, welche nach Abschluss der Testphase voraussichtlich im Mai 2009 verabschiedet wird.1

16.3 Informationsaustauschanforderungen In die Entwicklung des Datenmodells sind im Laufe der Jahre unterschiedlichste Informationsaustauschanforderungen eingeflossen. Grundlage des Datenmodells bildeten sowohl die persönliche Expertise der beteiligten Modellierer als auch zahlreiche Referenzdokumente, wie z. B. NATO STANAGs. Die Quelle ist häufig durch Metainformationen im Datenmodell vermerkt, so dass sie sich zurückverfolgen lässt. Zahlreiche Anforderungen lassen sich auf ADatP-3-Meldungsformate wie OWNSITREP (Own Land Force Situation Report), ENSITREP (Enemy Situation Report) oder ROEREQ (Rule Of Engagement Request) zurückführen. Eine detaillierte Beschreibung aller eingearbeiteten Meldungsformate würde bei Weitem den Rahmen dieses Beitrags übersteigen, insbesondere da einzelne Formate sehr unterschiedliche Informationen abdecken. Im Falle von ENSITREP sind dies z. B. Informationen über feindliche Kräfte wie Positionen, Grenzen, Statusangaben und die Gefechtsgliederung (engl.: Order of Battle). Für die eigenen und die feindlichen Kräfte können mit dem JC3IEDM nicht nur die Art und Anzahl der Kräfte, sondern auch ihr aktueller Status, ihre Fähigkeiten (z. B. für die logistische Unterstützung und Transportmöglichkeiten), die verfügbaren Waffensysteme und die Systeme für Führung, Fernmelde-, Computer- und Nachrichtenwesen mit ihren jeweiligen Fähigkeiten spezifiziert werden. Neben Informationen über die Truppen können auch Angaben über Umgebungsbedingungen gemacht werden. Informationen über die physikalische Beschaffenheit schließen sowohl natürliche geographische und meteorologische Eigenschaften als auch von Menschen geschaffene Gebäude und Infrastrukturen (Straßen, Brücken, 1

Das JC3IEDM 3.1 wird während der Tests auf Basis der gesammelten Erkenntnisse fortgeschrieben, wobei fehlerkorrigierte Fassungen durch Anfügen eines Kleinbuchstabens gekennzeichnet sind (3.1a, 3.1b etc.).

222

M. Gerz und U. Schade

Kommunikationsverbindungen etc.) ein. Berücksichtigt werden die Beschaffenheit von Land und See ebenso wie die niederen und höheren Schichten der Atmosphäre. Darüber hinaus können Informationen über die politische, kulturelle (Sprache, Gesetze, Religion, . . . ) und ökonomische Situation mit Hilfe des JC3IEDM ausgetauscht werden. In Bezug auf Einsätze können u. a. die Einsatzrichtlinien (engl.: Rules of Engagement), der Status der Vorbereitung sowie Zeitbedingungen angegeben werden. Weitere austauschbare Informationen betreffen das Führungs- und Meldewesen (z. B. Truppeneinteilung, Planung, Interoperabilität von Systemen), die Aufklärung und Ziele. Zudem können Informationen über die räumliche Verteilung, die Bewegungen und Manöver von Kräften, die Sicherung der rückwärtigen Gebiete und die logistische Unterstützung ausgetauscht werden. Das Datenmodell ist sowohl bei Operationen nach Artikel V der NATO als auch bei Krisenreaktionsoperationen (engl.: Crisis Response Operations – CRO2 ) anwendbar. Für letztere wurden zusätzliche Informationsaustauschanforderungen beispielsweise zu den Themengebieten Verhaftungen, Camps, Grenzübergänge, Massengräber und Flüchtlinge umgesetzt. Obwohl ursprünglich als Austauschmodell ausschließlich für das Heer konzipiert, sind zwischenzeitlich auch zahlreiche Anforderungen für einen Informationsaustausch in teilstreitkräfteübergreifenden (Joint) Operationen eingeflossen. In den letzten Jahren lag der Schwerpunkt der Arbeiten u. a. in den Bereichen Air Tasking Order (ATO), Maritime Mine Warfare (MMW) und Chemical Biological Radiological Nuclear (CBRN). Mit den Operationellen Informationsgruppen (OIGs) wurde in das C2IEDM 6.15e ein Konzept für die Gruppierung und Verteilung von Daten aufgenommen. Das Datenmodell sieht dabei eine Klassifizierung der operationellen Informationen in sechs vordefinierte Kategorien vor:3  Informationen über freundliche und neutrale Kräfte (organisatorische & nichtorganisatorische Informationen)  Informationen über feindliche und unbekannte Kräfte (unkorreliert & korreliert)  Global signifikante Informationen  Pläne und Befehle. Die wichtigste Neuerung des JC3IEDM 3.1 gegenüber seinen Vorgängermodellen stellt die Beschreibung von Plänen und Befehlen gemäß STANAG 2014, Edition 9, dar. Hierbei wurde ein Modellierungsansatz gewählt, der es ermöglicht, textuelle Bestandteile eines Plans mit strukturierten Anteilen zu kombinieren. Eine detaillierte Beschreibung aller Neuerungen im JC3IEDM findet man in (Bau et al., 2007b). 2 Der Term Crisis Response Operations hat im Laufe der Geschichte die Begriffe Peacetime Support Operations (PSO) und Military Operations Other Than War (MOOTW) ersetzt. 3 Das OIG-Konzept im Datenmodell ist eng mit dem in MIP entwickelten Data Exchange Mechanism (DEM) verknüpft. Der DEM folgt dem Publish-Subscribe-Paradigma, wobei jede Organisation ihre Informationen gemäß den vordefinierten operationellen Informationsgruppen anbietet.

16 JC3IEDM

223 1600

1460

1400 1200

1021

1000 800

644

600 400 200

149 157

203 188

LC2IEDM 2.2 (Baseline 1)

C2IEDM 6.15e (Baseline 2)

271 233

0

Entitäten

Relationen

JC3IEDM 3.1 (Baseline 3)

Attribute

Abb. 16.1 Evolution des MIP-Datenmodells

Durch die Berücksichtigung von neuen Informationsanforderungen ist das Datenmodell im Laufe der Jahre kontinuierlich gewachsen, wobei jedoch die grundlegenden Strukturen, insbesondere beim Übergang vom C2IEDM 6.15e zum JC3IEDM 3.1, nicht verändert wurden. Ein quantitativer Vergleich zwischen den Datenmodellen der bisherigen MIP Baselines ist in Abb. 16.1 dargestellt.4 Das ursprüngliche Konzept eines schlanken Kerns („Generic Hub“), der gemeinsame Informationskonzepte verschiedener funktionaler Bereiche (z. B. Feuerunterstützung, Luftunterstützung, Logistik, elektronischer Kampf) vereint und die Basis eines föderierten Datenmodells bildet, ist zunehmend in den Hintergrund gerückt. Es hat sich gezeigt, dass eine scharfe Abgrenzung des Hubs nicht möglich ist und dass einzelne COIs ihre Anforderungen direkt in das JC3IEDM einbringen, um das Modell für sie unmittelbar nutzbar zu machen.

16.4 Struktur des Datenmodells Aus den Informationsanforderungen ist ein Datenmodell entstanden, das aus wenigen, generischen Entitäten aufgebaut ist. Das JC3IEDM 3.1 beruht auf einem Entity-Relationship-Modell, welches in der Notation IDEF1X (IEEE, 1998a) beschrieben ist. Normativer Bestandteil der JC3IEDM-Spezifikation ist das sogenannte MIP Information Resource Dictionary (MIRD), eine Metadatenbank im MS Access-Format, die die logische und die physikalische Sicht des JC3IEDM und des JC3IEDM-Metamodells beschreibt. Das MIRD enthält die Definitionen aller Entitäten, Attribute, Relationen und Domänen sowie die Werte aller Aufzählungstypen. Das JC3IEDM gliedert sich – wie oben bereits angedeutet – in eine konzeptionelle, eine logische und eine physikalische Sicht, um unterschiedlichen Nutzern (z. B. 4

Der Vergleich beruht auf den logischen Sichten der Datenmodelle. In den physikalischen Sichten sind zusätzliche Attribute enthalten, die im Rahmen der MIP-Datenreplikation benötigt werden. Hinsichtlich der Relationen sind ferner Subtyp-Beziehungen nicht erfasst.

224

M. Gerz und U. Schade

Stabsoffizieren und Systementwicklern) den Zugang zum Modell auf verschiedenen Abstraktionsniveaus zu ermöglichen. Leider wurden aber die Vorteile, die sich prinzipiell durch die Definition verschiedener Sichten ergeben, bislang nicht ausgeschöpft. So sind die logische und die physikalische Sicht strukturgleich und unterscheiden sich primär in den Namenskonventionen für Entitäten, Attribute und Domänen sowie in einigen wenigen zusätzlichen Attributen in der physikalischen Sicht, die für die Replikation mittels MIP DEM benötigt werden (siehe auch die Diskussion in Abschn. 16.7). Eine konzeptionelle Sicht auf das JC3IEDM, welche nur die unabhängigen Entitäten des Modells umfasst, ist in Abb. 16.2 dargestellt. Der mit Abstand größte Teil des Datenmodells dient der Beschreibung von Objekten. Ein Überblick über die im JC3IEDM vorhandenen Objekttypen ist in Abb. 16.3 gegeben. Hierzu zählen einerseits „physikalische“ Objekte wie Einheiten, Ausrüstung oder Gebäude und andererseits abstrakte Entitäten wie z. B. Grenzen und Routen (sog. CONTROL-FEATUREs). Das JC3IEDM unterscheidet zwischen Objekttypen (OBJECT-TYPEs) und Objektinstanzen (OBJECT-ITEMs), die jeweils durch eine eigene Hierarchie repräsentiert sind. In einer Typdefinition werden (statische) Eigenschaften einer Klasse von Objekten beschrieben. Beispielsweise lassen sich damit die Eigenschaften des Panzertyps Marder erfassen. Mit einer Objektinstanz hingegen werden spezifische Eigenschaften eines individuellen, „real existierenden“ Panzers spezifiziert. Jedes

RULE-OF-ENGAGEMENT

CANDIDATE-TARGET-LIST

REPORTING-DATA

REFERENCE CAPABILITY

ACTION SECURITY-CLASSIFICATION

CONTEXT COMPONENT-HEADER-CONTENT

PLAN-ORDER

COMPONENT-TEXT-CONTENT OBJECT-TYPE

OBJECT-ITEM

LOCATION

VERTICAL-DISTANCE RELATIVE-COORDINATE-SYSTEM

AFFILIATION

GROUP-CHARACTERISTIC

ADDRESS

Abb. 16.2 Unabhängige Entitäten des JC3IEDM (MIP, 2008c, Seite 28)

16 JC3IEDM

225 OBJECT-TYPE object-type-category-code

FACILITY-TYPE

PERSON-TYPE

facility-type-category-code AIRFIELD-TYPE

FEATURE-TYPE

MATERIEL-TYPE materiel-type-category-code

feature-type-category-code

CONSUMABLE-MATERIEL-TYPE

BRIDGE-TYPE

CONTROL-FEATURE-TYPE control-feature-type-category-code

HARBOUR-TYPE

ROUTE-TYPE consumable-materiel-type-category-code

MILITARY-OBSTACLE-TYPE AMMUNITION-TYPE ORGANISATION-TYPE organisation-type-category-code

GEOGRAPHIC-FEATURE-TYPE

BIOLOGICAL-MATERIEL-TYPE CHEMICAL-MATERIEL-TYPE RADIOACTIVE-MATERIEL-TYPE

CIVILIAN-POST-TYPE EQUIPMENT-TYPE GROUP-ORGANISATION-TYPE

equipment-type-category-code AIRCRAFT-TYPE

PRIVATE-SECTOR-ORGANISATION-TYPE

CBRN-EQUIPMENT-TYPE

GOVERNMENT-ORGANISATION-TYPE

ELECTRONIC-EQUIPMENT-TYPE government-organisation-type-category-code ENGINEERING-EQUIPMENT-TYPE MILITARY-ORGANISATION-TYPE

MARITIME-EQUIPMENT-TYPE MISCELLANEOUS-EQUIPMENT-TYPE

military-organisation-type-category-code

RAILCAR-TYPE UNIT-TYPE WEAPON-TYPE MILITARY-POST-TYPE TASK-FORMATION-TYPE

EXECUTIVE-MILITARY-ORGANISATION-TYPE

VEHICLE-TYPE VESSEL-TYPE

vessel-type-category-code SUBSURFACE-VESSEL-TYPE SURFACE-VESSEL-TYPE

Abb. 16.3 Object-Type-Hierarchie (MIP, 2008c, Seite 31)

OBJECT-ITEM muss dabei einem semantisch kompatiblen OBJECT-TYPE zugeordnet sein.5 Durch OBJECT-TYPEs wurden somit gewissermaßen Meta-Entitäten in das Modell eingeführt. Eine direkte Umsetzung des JC3IEDM in eine Ontologie – vgl. zu einem entsprechenden kanadischen Ansatz etwa (Dorion et al., 2005) – kann dadurch zur Verletzung der Regeln führen, die beim Aufbau einer Ontologie zu beachten sind (vgl. dazu Guarino & Welty, 2004). Dies liegt in erster Linie daran, dass die abgeleiteten Hierarchien nicht vollständig der objektorientierten Sicht mit der Unterscheidung in Klassen und Objektinstanzen und der daraus resultierenden Hierarchie (d. h. der Taxonomie) entsprechen.

5

Gültige ITEM/TYPE-Kombinationen sind durch entsprechende Geschäftsregeln definiert.

226

M. Gerz und U. Schade

Dagegen erlaubt die Unterscheidung zwischen Objekttypen und Objektinstanzen im Modell selbst, z. B. in Bezug auf Ausstattung und Fähigkeiten zwischen Soll und Ist zu differenzieren. Typinformationen und ihre Beziehungen untereinander können der Stärke- und Ausrüstungsnachweisung (StAN) dienen. In der Regel wird diese Art der Informationen bereits vor einem Einsatz zwischen den beteiligten Einheiten ausgetauscht. Sowohl OBJECT-TYPEs als auch OBJECT-ITEMs können mittels der Entität CAPABILITY und ihren Subentitäten verschiedene Fähigkeiten zugeordnet werden. Ferner kann für sie die Zugehörigkeit (AFFILIATION) zu Staaten, ethnischen Gruppen etc. spezifiziert werden (siehe Abb. 16.2). Für die Beschreibung georeferenzierter Objekte bietet das JC3IEDM ein eigenes Submodell, mit dem relative und absolute Punkte, verschiedene Arten von Flächen (z. B. Korridore und durch Polygone begrenzte Gebiete) und Körper beschrieben werden können (vgl. Entität LOCATION in Abb. 16.2). Pläne und Befehle gemäß STANAG 2014 werden durch die Entität PLANORDER und weitere abhängige und unabhängige Entitäten beschrieben. Für die Beschreibung der strukturierten Informationsanteile eines Plans oder Befehls sowie für die Spezifikation von Anforderungen und Aktionen bietet das JC3IEDM das ACTION-Submodell. Auch feindliche Aktionen und natürliche Ereignisse wie Erdbeben lassen sich hiermit beschreiben. Die Nutzung des ACTION-Submodells für die Befehlsbearbeitung wurde in (Schade, 2003) eingehend untersucht. Zu allen Daten, die während eines Einsatzes erfasst werden, können MetaAngaben zur Informationsquelle und deren Glaubwürdigkeit, zur Genauigkeit der Informationen, zum Zeitpunkt der Berichterstattung und zum Zeitraum, in dem die Informationen „wirksam“ sind, gemacht werden (REPORTING-DATA). Informationen können ferner nach beliebigen Gesichtspunkten in einer Gruppe zusammengefasst werden (Entität CONTEXT). Diese kann dann selbst wiederum zur näheren Beschreibung von Aktionen und Objekten herangezogen werden. Die Entität CONTEXT – bzw. ihr Subtyp OIG – wird typischerweise zur Beschreibung der in Abschn. 16.3 erwähnten operationellen Informationsgruppen verwendet. Eine weitere wichtige Anwendung von CONTEXT ist die Repräsentation grafischer Overlays. Mit Hilfe der Entität GROUP-CHARACTERISTIC können Personen ferner nach Kriterien wie Alter, Geschlecht, Sprache oder Krankheiten gruppiert werden.

16.5 Geschäfts- und Implementierungsregeln In Ergänzung zum Entity-Relationship-Modell sind für das JC3IEDM eine Vielzahl sogenannter Geschäftsregeln (engl.: Business Rules) definiert. Diese Geschäftsregeln spezifizieren zusätzliche Einschränkungen, die mit Hilfe von IDEF1X grundsätzlich nicht ausgedrückt bzw. aufgrund des Designs des JC3IEDM in diesem spezifischen IDEF1X-Modell nicht beschrieben werden können. Die Einhaltung der Integritätsregeln durch die Nutzer und Systeme stellt sicher, dass die Aufgaben der

16 JC3IEDM

227

Anwendungsdomäne (in diesem Fall die der militärischen Führung) sinnvoll durchgeführt werden können. Zu den Integritätsregeln zählen Festlegungen für gültige Wertekombinationen von Attributen innerhalb einer Entität. So sind beispielsweise nur bestimmte Attributwertekombinationen zur Klassifizierung von Flugzeugtypen sinnvoll (siehe Tabelle 16.1). Diese Art von Geschäftsregeln definiert quasi Subtypbeziehungen, ohne dass hierfür explizit neue Entitäten eingeführt werden müssen. Darüber hinaus existieren Regeln für gültige Assoziationen. Diese resultieren aus den generischen Strukturen des Datenmodells, bei denen Relationen zumeist zwischen unabhängigen Entitäten, also auf oberster Ebene der Entität-Hierarchien, definiert sind. Mit Hilfe der Assoziation HOLDING (dt.: Bestand) lassen sich z. B. beliebige OBJECT-ITEMs und OBJECT-TYPEs miteinander in Beziehungen setzen. Nur eine Teilmenge aller möglichen Beziehungen ist jedoch tatsächlich semantisch sinnvoll. Eine Organisation kann z. B. mit Personal ausgestattet werden, nicht jedoch umgekehrt (vgl. Tabelle 16.2). Alternativ zur Definition von Integritätsregeln wäre es möglich gewesen, generische many-to-many-Assoziationen in mehrere, spezifischere Assoziationen aufzulösen. Dies hätte zu einer Vielzahl zusätzlicher Entitäten geführt, oftmals aber auch zu einem besseren Verständnis des Modells beigetragen. Die obigen Regeln sind in Form von Tabellen beschrieben. Sie sind zudem im MIRD erfasst, um die Umsetzung in den nationalen Systemen zu unterstützen, etwa

Tabelle 16.1 Gültige Kombinationen von Domänwerten für Flugzeugtyp-Attribute (MIP, 2008c, Annex G2) aircraft-type-category-code aircraft-type-airframe-design-code (Mandatory) (Optional) Fixed wing

Lighter than air

Rotary wing

Space vehicle

Not known Not otherwise specified

Bomber Fighter Glider Transport Not known Not otherwise specified [NULL] Balloon Dirigible Not otherwise specified [NULL] Autogyro Helicopter Transport Not known Not otherwise specified [NULL] Satellite Not otherwise specified [NULL] [NULL] [NULL]

228

M. Gerz und U. Schade

Tabelle 16.2 Gültige Beziehungen für die Ausstattung von Objekten (MIP, 2008c, Annex G2) OBJECT-TYPE that is held by OBJECT-ITEM OBJECT-ITEM

FACILITY- MATERIEL- ORGANISATION- PERSONTYPE TYPE TYPE TYPE p p p p FACILITY p MATERIEL NA NA NA p p p p ORGANISATION p PERSON NA NA NA WX = corridor-area-width-dimension Second point

Abb. 16.4 Geometrie der Aktion Angriff (MIP-Implementierungsregel)

für die Gestaltung flexibler Nutzerschnittstellen, bei denen dem Nutzer nur die jeweils erlaubten Werte angezeigt werden, und zur Prüfung der Integrität von Daten, die von einem fremden System empfangen werden. Daneben existieren Geschäftsregeln, die in der aktuellen Version des JC3IEDM nur in textueller Form vorliegen. Im Rahmen der in Abschn. 16.7 beschriebenen Arbeiten an einem UML-Modell wurden viele dieser Regeln in der Object Constraint Language (OCL) formalisiert. Für Führungsinformationssysteme ist die Darstellung taktischer Zeichen von großer Bedeutung. Als international anerkannter Standard hat sich dabei APP-6A etabliert (Thibault, 2005). Da das JC3IEDM eine andere Klassifikation als APP-6A verwendet, hat MIP umfangreiche Transformationsregeln definiert, die beschreiben, wie Kombinationen von Attributwerten des JC3IEDM auf semantisch äquivalente APP-6A-Symbole abzubilden sind. Wo kein APP-6A-Äquivalent verfügbar ist, wird auf ein generisches Symbol bzw. auf den MIL-STD-2525B ausgewichen. Abbildung 16.4 verdeutlicht, dass für die semantische Interoperabilität auch die Geometrie von Objekten und Aktionen berücksichtigt werden muss. So legt die MIP-Lösung fest, dass ein Angriff durch eine sogenannte Corridor Area zu beschreiben ist, wobei der zweite Punkt die Spitze des Angriffs repräsentiert.

16.6 Nutzung des JC3IEDM in verwandten Projekten Das JC3IEDM hat auch außerhalb der MIP-Community zunehmend an Bedeutung gewonnen. Verschiedene Projekte sowohl im militärischen als auch im zivilen Bereich wurden durch das Datenmodell beeinflusst oder verwenden dieses, wobei der ebenfalls in MIP definierte Austauschmechanismus für Datenbankreplikation nicht

16 JC3IEDM

229

notwendigerweise genutzt wird. Hinzu kommen eine Vielzahl nationaler Aktivitäten. In diesem Abschnitt sollen einige Projekte skizziert werden, um die Nutzungsmöglichkeiten des JC3IEDM aufzuzeigen. SOPES. Ziel der Initiative Shared Operational Picture Exchange Services (SOPES) der Object Management Group (OMG) ist es, für Rettungskräfte, Regierungen und sowohl militärische als auch zivile Organisationen ein vollständiges, korrektes und zeitnahes gemeinsames, operationelles Lagebild zur Verfügung zu stellen. SOPES ermöglicht es Nutzern, Informationen selektiv und organisationsübergreifend auszutauschen. Im Rahmen eines Request for Proposal (OMG, 2004) wurden seitens der OMG C4I Domain Task Force (http://c4i.omg.org/) Vorschläge für ein plattformunabhängiges Modell für den Informationsaustausch angefordert. Das US DoD hat diese Anfrage aufgegriffen und sponsert einen Vorschlag, der auf dem JC3IEDM beruht. Kern des SOPES-Vorschlags ist eine Spezifikation, die beschreibt, wie auf der Basis eines UML-Modells des JC3IEDM semantisch und referenziell vollständige „Informationspakete“ definiert werden können, die unabhängig von einem konkreten Austauschprotokoll oder -dienst sind (z. B. RDBMS-Replikation, WebServices, OMG Data Distribution Service, CORBA etc.). OASIS. Das Open Advanced System for Disaster & Emergency Management (OASIS; OASIS, 2008), ein von der europäischen Union unterstütztes Projekt, entwickelte von 2004 bis 2008 ein Rahmenwerk für ein europäisches Katastrophen- und Notfallmanagementsystem. Ziel war die Unterstützung von Operationen, die das Zusammenspiel sowohl lokaler als auch internationaler Rettungsorganisationen erfordern. Das Konsortium mit Teilnehmern aus 9 Staaten hat eine offene Architektur – und darauf aufbauend erste Applikationen – entwickelt und Standards vorgeschlagen, um die Interoperabilität der Systeme zu verbessern. In die Definition der Tactical Situation Objects sind dabei auch Konzepte des MIP-Datenmodells eingeflossen. JC3IEDM-enhanced Tactical Collaboration (JTC). JTC ist ein prototypisches C2-System der US-Marine, das vom Naval Undersea Warfare Center (NUWC) entwickelt wurde, um operationelle Aufgaben (OpTasks) und Beobachtungen von Aktivitäten erfassen zu können (Chaum & Christman, 2008). Es kombiniert dabei klassische FüInfoSys-Fähigkeiten (Darstellung einer Lagekarte etc.) mit der Möglichkeit, unstrukturierte Informationen via Chat auszutauschen. JTC verwendet das JC3IEDM sowohl als internes Datenmodell als auch für den Austausch der taktischen Meldungen. Hierzu wird das objektorientierte XML-Schema des JC3IEDM eingesetzt (Gerz et al., 2007). Coalition Battle Management Language (C-BML). Eine Battle Management Language (kurz: BML; vgl. auch Kap. 17) ist eine Sprache, mit der militärische Kommunikation, also insbesondere Befehle und Meldungen, semantisch eindeutig formuliert werden können. Eine BML erlaubt eine automatisierte Verarbeitung und kann daher genutzt werden, um aus Führungsinformationssystemen heraus in einem Simulationssystem abgebildete Einheiten zu befehligen. In der NATO RTO wurde 2006 die NATO MSG-048 Coalition Battle Management Language gegründet,

230

M. Gerz und U. Schade

um eine BML zu definieren und zu standardisieren. Aufgrund der verbreiteten Nutzung des JC3IEDM in den Führungsinformationssystemen wurde im Rahmen der MSG-048 festgelegt, die im JC3IEDM benutzten Attribute und deren Werte als lexikalische Einheiten von BML, also als Wörter dieser Sprache, zu verwenden. Dies erleichtert nicht nur die gleichzeitige Verwendung des JC3IEDM und der BML (das JC3IEDM wird dabei für die Spezifikation von Daten und die BML für die Kommunikation genutzt); die Abbildung der lexikalischen Elemente der BML auf das JC3IEDM hat ferner den Vorteil, dass für die lexikalischen Elemente verbindliche Definitionen vorliegen, nämlich die, die durch das JC3IEDM gegeben sind. Simulation (C2SimProxy). Die Anforderung, Simulationssysteme und Führungsinformationssysteme zu koppeln, um zu Trainingszwecken oder als Entscheidungsunterstützung angenommene oder vorliegende Lagen im Simulationssystem durchspielen zu können, gab es bereits vor dem Aufkommen der BML. So wurden beispielsweise im Programm Simulation & C2 Information Systems Connectivity Experiments (SINCE), für das derzeit eine deutsch-französische Variante (SINCE II) entwickelt wird, deutsche und amerikanische Führungsinformationssysteme mit Simulationssystemen beider Nationen gekoppelt (Mayk et al., 2005). Der Datenaustausch zwischen den Führungsinformationssystemen erfolgte dabei unter Nutzung des LC2IEDM, der Austausch zwischen den Simulationssystemen über die High-Level Architecture (HLA). Für den Datenaustausch zwischen den deutschen Führungsinformationssystemen HEROS 2/1 und FAUST einerseits und den deutschen Simulationssystemen SIRA und PABST 2000 andererseits wurde der sogenannte C2SimProxy gemeinsam von der ESG und der IABG entwickelt (Menzler et al., 2001, 2008). Dieser kommuniziert simulationsseitig via HLA und verhält sich damit aus Sicht der Simulationssysteme wie ein weiteres Simulationssystem. Der Datenaustausch mit den Führungsinformationssystemen erfolgt über die MIPSchnittstelle mittels LC2IEDM bzw. in der neuesten Version unter Verwendung des JC3IEDM.

16.7 UML und modellgetriebene Architektur Im Jahr 2007 hat MIP eine Arbeitsgruppe initiiert, um die Möglichkeiten der modellgetriebenen Architektur (engl.: Model-Driven Architecture; MDA) im Kontext des JC3IEDM zu untersuchen. Ziel der MDA ist eine striktere Trennung zwischen Funktionalität und Technik. Zu diesem Zweck soll ein Modell auf verschiedenen Abstraktionsschichten beschrieben werden:    

Fachliches Modell (Computation Independent Model; CIM) Plattformunabhängiges Modell (Platform Independent Model; PIM) Plattformspezifisches Modell (Platform Specific Model; PSM) Codemodell (Zielplattform).

Während der Übergang vom CIM zum PIM noch primär durch den Modellierer erfolgen muss, wird mit Hilfe von Generatoren eine möglichst automatisierte Abbil-

16 JC3IEDM

231

dung des PIM in ein PSM (und schließlich des PSM in das Codemodell) angestrebt. Soll die Transformation vollständig automatisiert erfolgen, so müssen alle Plattformspezifika entweder im Generator als feste Regeln kodiert werden oder bereits im plattformunabhängigen Modell vorhanden sein. Mögliche PSMs sind Schemata für relationale oder objektorientierte Datenbanken, XML-Schemata und Quellcode für beliebige Programmiersprachen wie Java, C# oder C++. Heutige (UML-)Tools stellen für die gängigsten Plattformen bereits entsprechende Generatoren zur Verfügung und erlauben es darüber hinaus dem Nutzer, eigene Generatoren zu definieren. Bereits in der Vergangenheit wurden aus dem JC3IEDM unterschiedliche Produkte abgeleitet. So hat das FKIE maßgeblich am Design eines objektorientierten XML-Schemas und eines entsprechenden Generators mitgewirkt (Gerz et al., 2006, 2007). Da in die logische Sicht des JC3IEDM – welche konzeptionell einem PIM gleichzusetzen ist – jedoch technische Aspekte einer relationalen Datenbank eingeflossen sind, musste bei der Generierung des XML-Schemas als Zwischenschritt eine Abstraktion vorgenommen werden. Im Rahmen der MIP-Arbeitsgruppe wurde ein PIM auf der Basis der Unified Modeling Language (UML) entwickelt. Im Zuge der Umstellung auf UML wurde von technischen Details abstrahiert, die in dem bisherigen relationalen Modell enthalten waren. So wurden bei der Transformation von IDEF1X nach UML sämtliche Schlüsselattribute (Primärschlüssel als Identifier und Fremdschlüssel für Beziehungen) aus dem JC3IEDM entfernt, da diese keine operationelle Bedeutung haben und primär im Kontext eines Datenbankschemas (d. h. eines plattformspezifischen Modells) relevant sind.6 Entsprechend konnten auch die sogenannten Discriminator Codes, die der Spezifikation des Subtyps in einer relationalen Datenbank dienen, entfernt werden. Schließlich wurden strukturelle Vereinfachungen hinsichtlich der Modellierung von many-to-many-Assoziationen vorgenommen. In Sinne der MDA wurden Generatoren entwickelt bzw. genutzt, um verschiedene Produkte aus dem JC3IEDM PIM automatisiert zu generieren. Hierzu zählen neben dem bisherigen MIP Information Resource Dictionary auch XML-Schemata, ein OWL-Schema und Dokumentation. Eine weitere Motivation der MIP-Community bei der Umstellung auf die UML war die Vereinfachung des Konfigurationsmanagements. Das JC3IEDM wurde bislang in verschiedenen Dokumenten spezifiziert (logische und physikalische Sicht des Datenmodells im Modellierungstool, Dokumentation einschließlich Business Rules und Beispielen in Textdateien, Metadaten (MIRD) in einer Datenbank). Aufgrund der eingeschränkten Toolunterstützung und der fehlenden Integration der einzelnen Artefakte mussten Änderungen bislang an verschiedenen Stellen redundant nachgezogen werden. Angesichts der Größe des Datenmodells verursachte diese Vorgehensweise einen sehr hohen manuellen Aufwand und führte leicht zu Inkonsistenzen. Bei der Verwendung von UML und entsprechender Werkzeuge sind – je nach Integrationsgrad – Änderungen ggf. nur noch an einer Stelle vorzunehmen. Zudem existieren Werkzeuge, um beispielsweise Inkonsistenzen zwischen dem Klas6

Aus Gründen der Rückwärtskompatibilität zum IDEF1X-Modell werden Namen und Metadaten der Schlüsselattribute bis auf Weiteres in einer Metadatentabelle vorgehalten, welche zur Generierung des MIRD genutzt wird.

232

M. Gerz und U. Schade

senmodell einerseits und den zugehörigen Business Rules und Beispieldaten (letztere in Form von Objektmodellen/-diagrammen) andererseits automatisch zu erkennen. Die Umstellung auf die UML bringt zahlreiche weitere Vorteile mit sich. An erster Stelle sei hier das erweiterte Angebot an verfügbaren Werkzeugen zu nennen, die die UML und das Austauschformat XML Metadata Interchange (XMI) unterstützen. Während man bei der Entwicklung und Pflege des relationalen Datenmodells auf ein Produkt festgelegt war, existiert für die UML eine Vielzahl von Werkzeugen. Mit Hilfe von XMI können UML-Modelle prinzipiell zwischen verschiedenen Tools ausgetauscht werden, wenngleich in der Praxis toolspezifische Anpassungen erforderlich sein können. Die UML unterstützt ferner sogenannte Profile und Stereotypen, mit denen Datenelementen (Klassen, Attributen, Domänenwerten etc.) in Form von Tagged Values zusätzliche Meta-Informationen zugeordnet werden können. Hiermit ist es möglich, Metadaten im UML-Modell toolunabhängig zu beschreiben. Zahlreiche Modellierungstools, die auf der UML beruhen, bieten zudem auch Erweiterungen für Architekturrahmenwerke (vgl. Kap. 15), was zukünftig einen integrierten Modellierungsansatz ermöglicht. Aufgrund der breiten Akzeptanz der UML im Softwarebereich ist auch mit einer größeren Akzeptanz des JC3IEDM in der Entwicklergemeinde zu rechnen. Ein weiterer Vorteil von UML ist die Integration der Object Constraint Language (OCL). Mit Hilfe von OCL können auch komplexe Geschäftsregeln formalisiert und auf Konsistenz mit dem Klassenmodell geprüft werden. Im Rahmen der Umstellung des JC3IEDM auf UML wurden alle Business Rules in OCL formalisiert. Dies führte zu einer formalen Semantik und ermöglicht den Systementwicklern eine automatische Generierung von „Prüfcode“.

16.8 Zusammenfassung und Ausblick Das JC3IEDM stellt einen wichtigen Schritt hin zu einer Harmonisierung der Führungsinformationssysteme dar. Systeme, die intern auf einem proprietären Datenmodell basieren, sind dabei so anzupassen, dass für den Informationsaustausch eine korrekte und möglichst verlustfreie Abbildung auf das JC3IEDM und umgekehrt gewährleistet ist. Gegenwärtig werden mehr als 25 Führungsinformationssysteme von den an MIP teilnehmenden Nationen interoperabel gemacht, um sie in multinationalen Einsätzen gemeinsam nutzen zu können. (Für das Testen der semantischen Interoperabilität auf der Grundlage der MIP-Lösung siehe auch Kap. 21.) Eine Herausforderung bei der Weiterentwicklung des JC3IEDM stellt dessen wachsende Größe und Komplexität dar. Durch die Umstellung des JC3IEDM auf die UML wurde ein wichtiger Schritt vollzogen, um das Management des Datenmodells und seiner zugehörigen Produkte zu vereinfachen. Zukünftig wird das JC3IEDM zudem im Kontext spezifischer operationeller Fähigkeiten und deren Geschäftsprozesse zu betrachten sein. So ist es sinnvoll, für einzelne operationelle Aktivitäten

16 JC3IEDM

233

bzw. für die dafür genutzten Dienste jeweils relevante Teilsichten auf das JC3IEDM zu definieren.

Literaturverzeichnis Bau, N., Gerz, M., Glauer, M., & Schüller, H. (2007b). Multilateral Interoperability Programme – Advancements in MIP Baseline 3. In Twelfth International Command and Control Research and Technology Symposium (12th ICCRTS) Newport, RI, USA: Office of the Assistant Secretary of Defense, Command and Control Research Program (CCRP). Chaum, E. & Christman, G. (2008). Making Stability Operations Less Complex While Improving Interoperability. In 13th International Command and Control Research and Technology Symposium (13th ICCRTS) – C2 for Complex Endeavors Bellevue, WA. Dorion, E., Matheus, C. J., & Kokar, M. (2005). Towards a formal ontology for military coalitions operations. In Proceedings of the 10th International Command and Control Research and Technology Symposium (ICCRTS) McLean, VA. Gerz, M., Loaiza, F., & Chaum, E. (2006). An Object-Oriented XML Schema for the MIP Joint Command, Control, and Consultation Information Exchange Data Model. In 2006 Command and Control Research and Technology Symposium (2006 CCRTS) San Diego, CA, USA: Office of the Assistant Secretary of Defense, Command and Control Research Program (CCRP). Gerz, M., Loaiza, F., & Chaum, E. (2007). An Object-Oriented XML Schema for the MIP JC3IEDM 3.1. FKIE-Bericht Nr. 129, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Guarino, N. & Welty, C. A. (2004). Handbook on Ontologies, chapter An Overview to OntoClean, (pp. 151–172). Springer: Berlin. IEEE – Institute of Electrical and Electronics Engineers (1998a). IEEE 1320.2 Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject). http:// electronics.ihs.com/document/abstract/FCSTFBAAAAAAAAAA. Mayk, I., Klose, D., Chan, A., Mai, M., & Nearan, H. (2005). Technical and Operational Design, Implementation and Execution Results for SINCE Experiment 1. In Proceedings of the 10th International Command and Control Research and Technology Symposium McLean, VA, USA. Menzler, H.-P., Muschik, H. J., & Neugebauer, E. (2008). The C2SimProxy Concept: Fostering M&S and CCIS Interoperability. In Proceedings of the 2008 Euro Simulation Interoperability Workshop Edinburgh, UK. Menzler, H.-P., Tolk, A., Kuite, J., & Weyrath, T. (2001). Command and Control to Simulation Proxy Solution (C2SimProxy) – Loose Coupling of Disparate Worlds. In Proceedings of the 2001 European Simulation Interoperability Workshop London, UK. MIP – Multilateral Interoperability Programme (2004). The C2 Information Exchange Data Model (C2IEDM Main), Edition 6.15. http://www.mip-site.org. MIP – Multilateral Interoperability Programme (2008c). The Joint C3 Information Exchange Data Model. Edition 3.1d. http://www.mip-site.org. OASIS – Open Advanced System for Disaster & Emergency Management (2008). WWW Home Page. http://www.oasis-fp6.org/. OMG – Object Management Group (2004). Shared Operational Picture Exchange Services Information Exchange Data Model (IEDM) – Request For Proposal. OMG Document C4I-200406-27, http://www.omg.org/docs/c4i/04-06-27.pdf. Schade, U. (2003). Erweiterungsmöglichkeiten des Standardmodells LC2IEDM zur Befehlsbearbeitung. FKIE-Bericht Nr. 68, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Thibault, D. (2005). Commented APP-6A – Military symbols for land based systems – NATO’s current military symbology standard. Technical Note 2005-222, Defence R&D Canada, Valcartier.

Kapitel 17

Battle Management Language Ulrich Schade und Michael R. Hieb

17.1 Einleitung Die Anforderung, eine so genannte Battle Management Language (kurz BML) zu entwickeln, entstammt dem Bereich „Modeling and Simulation“, also dem Bereich, der sich mit der Entwicklung von militärischen Simulationssystemen beschäftigt. Simulationssysteme sind aus Sicht der Führungsinformationssysteme wenigstens in zweierlei Hinsicht von Interesse, in Bezug auf das Training von Stäben und als Teil einer Entscheidungsunterstützungskomponente. Beim Trainieren von Stäben können Simulationssysteme das reale Geschehen abbilden. In diesem Fall sollen die beübten Stäbe auf der Grundlage einer vorliegenden und sich weiterentwickelnden Situation Befehle an die unterstellten Einheiten absetzen sowie von diesen simulierten Einheiten Meldungen erhalten, die über die Fortentwicklung der Situation Auskunft geben. Die Befehle, die ein beübter Kommandostab erstellt, werden also nicht von realen Einheiten, sondern von simulierten Kräften entgegen genommen und innerhalb der Simulation ausgeführt. Auf diese Weise kann man nicht nur Kosten sparen, da Simulationsläufe weniger Aufwand und Kosten verursachen als tatsächlich im Gelände operierende Einheiten; die Übungen selbst können auch effektiver ablaufen, sofern die Simulationssysteme so mit den Stäben interagieren, dass diese Interaktion in ausreichender Weise real erscheint. Die Effektivität der Nutzung einer Simulation ergibt sich beispielsweise dadurch, dass die inhaltsarmen Phasen der Übung in Zeitraffer ablaufen können oder dass sich bestimmte kritische Situationen wiederholen lassen, so dass die Stäbe die Ausführungen der möglichen Befehlsalternativen erleben können, was über den Vergleich ein wirksameres Lernen erlaubt. Damit die beübten Stäbe mit den Mitteln trainieren, die sie auch in der realen Situation zur Verfügung hätten, muss gewährleistet sein, dass die Befehle mit Hilfe des eingesetzten Führungsinformationssystems formuliert und abgesetzt werden und dass die aus der Simulation eingehenden Meldungen so das Führungsinformationssystem erreichen, wie dies auch bei realen Meldungen der Fall ist. Damit die abgesetzten Befehle korrekt durch das nachgeschaltete Simulationssystem bzw. durch die darin simulierten Einheiten umgesetzt werden, müssen die Befehle in ein Format transformiert werden, welches Simulationssysteme generell korrekt interpretieM. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

235

236

U. Schade und M. R. Hieb

ren können. In gleicher Weise müssen die Meldungen, die dem Simulationssystem entnommen werden, in ein Format gebracht werden, über welches die Eingabe in Führungsinformationssysteme möglich wird. BML soll als Standard für ein solches Format dienen. Dies bedeutet, dass BML – wenn möglich – als Standard zu etablieren ist, der sowohl in Standardformate von Führungsinformationssystemen als auch von Simulationssystemen umgewandelt werden kann. Liegt BML als ein Standard im angesprochenen Sinne vor, so können über diesen auch Simulationssysteme in Entscheidungsunterstützungskomponenten von Führungsinformationssystemen genutzt werden (vgl. auch Tolk & Kunde, 2003; Schade & Hieb, 2007b). Die Idee dabei besteht darin, dass die aktuell im Führungssystem repräsentierte Lage in ein Simulationssystem überführt wird. Danach werden in dem Führungssystem Befehlsalternativen zu dieser Lage ausformuliert und mittels BML an die Entscheidungsunterstützungskomponente übermittelt. Die Simulationssysteme „rechnen“ dann die gegebene Lage mit den entsprechenden Befehlen durch und präsentieren die jeweiligen Ergebnisse dem militärischen Führer, der auf diese Weise Fortentwicklungsmöglichkeiten der aktuellen Situationen präsentiert bekommt. In dem vorliegenden Kapitel sollen einige Aspekte von BML, in erster Linie solche, die mit Führungsinformationssystemen in Zusammenhang stehen, dargestellt und diskutiert werden. Nach einer Definition des Begriffs BML (Abschn. 17.2) folgt ein kurzer Abriss dazu, wie und woraus sich BML entwickelt hat (Abschn. 17.3). Danach werden die formalen Konstruktionsprinzipien von BML erläutert (Abschn. 17.4) und mit einem Beispiel illustriert (Abschn. 17.5). Den Abschluss dieses Kapitels bildet eine Diskussion der Anwendungsmöglichkeiten von BML in Bezug auf die Weiterentwicklung der Führungsinformationssysteme (Abschn. 17.6).

17.2 Definition Unter dem Begriff „Battle Management Language (BML)“ versteht man eine Sprache, die für die automatisierte Kommunikation zwischen Führungsinformationssystemen untereinander, aber auch für die Kommunikation von Führungsinformationssystemen mit Simulationssystemen oder sogar mit so genannten „Robotic Forces“ Verwendung finden soll. Dies geht offensichtlich über die ursprünglichen Ziele einer BML-Entwicklung hinaus, die sich auf die Kommunikation zwischen Führungsinformationssystemen und Simulationssystemen bezogen (vgl. dazu Abschn. 17.3). Der umfassendere Anspruch an eine BML ist jedoch insofern naheliegend, als dass BML allgemein in der Lage sein sollte, automatisierte militärische Kommunikation abzubilden, sofern die Kommunikation zwischen einem Führungssystemen und einem Simulationssystemen durch BML realisiert werden kann. Grundsätzlich muss eine BML eindeutig sein, damit eine korrekte automatisierte Verarbeitung von BML-Ausdrücken gewährleistet ist. Eindeutigkeit ist aber keine notwendige Eigenschaft von Sprachen. In natürlichen Sprachen treten beispielsweise auf unterschiedlichen linguistischen Ebenen Mehrdeutigkeiten (Ambiguitäten) auf. Sie werden besonders deutlich in Bezug auf das Lexikon. Beispielsweise gibt

17 Battle Management Language

237

es etwa Homonyme, also Wörter wie „Bank“ oder „Leopard“, die mehrere deutlich unterscheidbare Bedeutungen tragen. Daneben gibt es Wörter wie „Himmel“, die über unterschiedliche Bedeutungsschattierungen verfügen, für die es dann in anderen Sprachen unter Umständen verschiedene Lexikonelemente gibt („sky“ vs. „heaven“). In aller Regel gelingt es dem Menschen, solche Mehrdeutigkeiten unter Zuhilfenahme des Äußerungskontextes aufzulösen. Dies gilt nicht nur für lexikalische Mehrdeutigkeiten – im Kontext Zoo ist mit „Leopard“ die Raubkatze gemeint, im militärischen Kontext der Kampfpanzer. Dies gilt auch für komplexere Mehrdeutigkeiten. Im Beispiel „Claudia hat eine Brille in ihrer Tasche, die sie zum Lesen nutzt“ bezieht der Mensch das Relativpronomen „die“ auf die Brille, wohingegen Computer dazu tendieren, das Relativpronomen auf die Tasche zu beziehen, solange sie nicht über eine Repräsentation des Wissens verfügen, das besagt, dass eine Brille, nicht aber eine Tasche als Instrument der Aktion des Lesens möglich ist. Interpretationsproblemen, die durch Mehrdeutigkeiten verursacht werden, beugt die Forderung zur Eindeutigkeit einer BML effektiv vor. Natürliche Sprachen sind vor allem deshalb nicht eindeutig, weil damit eine höhere Ausdrucksmächtigkeit erzielt werden kann. Der Forderung nach Eindeutigkeit bei einer BML steht damit die Forderung nach einer ausreichenden Ausdrucksmächtigkeit entgegen. Militärische Führer sollen mittels BML all das, was sie für relevant erachten, in Meldungen, Anforderungen und Befehlen ausdrücken können. Unter dem Gesichtspunkt der Ausdrucksmächtigkeit sind Formate wie ADatP-3 auszuschließen, die im Sinne einer automatisierten Verarbeitung die möglichen Ausdrücke sehr stark einschränken und sich auf nur vergleichsweise wenige Formulierungsmuster beschränken. Eine ausdrucksmächtige BML zieht dann aber auch die Forderung nach sich, dass Systeme, insbesondere auch Simulationssysteme und zukünftige „Robotic Forces“, eine Vielzahl von möglichen Ausdrücken in all ihren Aspekten semantisch korrekt auswerten und interpretieren können. Die dritte wichtige Anforderung, die man neben automatisierter Verarbeitbarkeit, der daraus ableitbaren Eindeutigkeit und der dem bedingt entgegenstehenden Ausdrucksmächtigkeit derzeit für eine BML formuliert, ist die Notwendigkeit, dass ein BML-Standard geschaffen wird. Ohne einen solchen Standard ist ein wichtiges Ziel von BML, nämlich auch einen interoperablen Informationsaustausch zwischen C2-Systemen zu ermöglichen, nicht zu erreichen. Nur wenn BML als standardisierte Sprache vorliegt, kann erwartet werden, dass BML als gemeinsame Sprache genutzt wird, um die Interoperabilität zwischen den Systemen zu erhöhen. Die Entwicklung einer standardisierten Sprache zum Austausch von Information gehört auch zum ursprünglichen Ziel der BML-Anstrengungen, wie im folgenden Kapitel erläutert wird.

17.3 Entwicklung der BML Die Idee, eine BML zu definieren, geht zurück auf Arbeiten des US Army’s Simulation-to-C4I Interoperability Overarching Integrated Product Team (SIMCI OIPT), vgl. dazu Carey et al. (2001). In einem ersten Ansatz wurden die Handbücher

238

U. Schade und M. R. Hieb

der US Army auf die darin enthaltenen Einsatzgrundsätze (Doctrines) hin analysiert, um auf dieser Grundlage eine eindeutige Sprache zu entwickeln, in der man Befehle hätte formalisiert notieren können. Mit Ausdrücken aus dieser Sprache sollten dann simulierte Einheiten befehligt werden. In dem Analyseprozess wurden über siebzig dieser Handbücher berücksichtigt, insbesondere das Field Manual 3.0 zur Operationsführung und die US Joint Staff’s Universal Joint Task List, aber auch Handbücher der einzelnen Truppengattungen wie die Field Manuals der Feldartillerie (Field Artillery), der Flugabwehr (Air Defense Artillery), der Pioniere (Engineers) und der Militärpolizei (Military Police). Grundsätzlich wurden dabei immer sämtliche Einsatzebenen bis hinab zur Zugebene betrachtet. Aus dieser Analysearbeit entstand ein eineindeutiges Format für Operationsbefehle, wobei die als traditionell angesehenen „5 W“ (Wer, Was, Wann, Wo, Warum) als grundlegend eingeschätzt wurden. Entsprechend wurde angenommen, dass mit den „5 W“ die Zuordnung von militärischen Aufgaben (Tasks) an einzelne Einheiten zu formulieren sei (Sudnikovich et al., 2004). Unter der Schirmherrschaft des US Defense Modeling and Simulation Office (DMSO) und des US Joint Forces Command (JFCOM) wurde dann das Projekt „Extensible BML (XBML)“ ins Leben gerufen, um ausgehend von den beschriebenen Analysearbeiten zwei weitere Ziele zu erreichen. Erstens sollte die Anforderung erfüllt werden, die SOA-Technologie für den Austausch von BML-Befehlen zwischen den Systemen (insbesondere zwischen einem C2-System und einem Simulationssystem) nutzbar zu machen. Zweitens sollte die zu entwickelnde BMLVariante auf dem Standarddatenmodell, zu jener Zeit also auf dem C2IEDM – dem Vorgänger des JC3IEDM (s. Kap. 16) – basieren, um so BML an den MIP-Standard anzukoppeln. Aus dieser Arbeit heraus ergaben sich letztlich drei Stränge zur Weiterentwicklung und zur Standardisierung von BML. Zum Ersten entstand mit Unterstützung von JFCOM J7 die Air Operations BML (AOBML) mit dem Ziel auszuloten, inwieweit der durch die Army entwickelte BML-Ansatz auch auf Luftoperationen übertragbar sei. Im Rahmen dieses Ansatzes konnten das Theater Battle Management Control System (TBMCS) und die Air Warfare Simulation (AWSIM) erfolgreich verknüpft werden (Perme et al., 2005). Zum Zweiten wurde das Ziel der Entwicklung einer BML, die den im ersten Kapitel formulierten Vorgaben genügen sollte, in die Simulation Interoperability Standardization Organization (SISO) eingebracht. Innerhalb der SISO wurde daraufhin die „Project Group Coalition BML“ gegründet, deren Ziel eben genau die Standardisierung von BML ist. Ein erster, früher Zwischenbericht dieser Gruppe wurde 2005 vorgestellt (Blais et al., 2005). Trotz ursprünglich deutlich ambitionierterer Vorgaben konnte diese Gruppe aber erst 2008 die Vorversion eines Standards vorlegen, welcher allerdings so umstritten war, dass eine Verabschiedung ausgesetzt wurde. Probleme dieser Vorversion liegen unter anderem darin, dass sie ohne den Bezug auf eine Grammatik formuliert wurde und dass sie keinerlei Beispiele enthält, die ihre Anwendungsmöglichkeiten illustriert hätten. Die SISO hat inzwischen eine Gruppe eingesetzt, die den Vorschlag sowie Alternativen dazu evaluieren soll, um das weitere Vorgehen zu koordinieren.

17 Battle Management Language

239

Die wichtigste Alternative für einen BML-Standard entstammt dem dritten Entwicklungsstrang. Im Bereich der NATO wurde im Jahr 2005 ein so genanntes Exploratory Team (NATO RTO MSG-040 – ET-016 Coalition Battle Management Language) gegründet, um auszuloten, inwiefern im Rahmen einer NATO RTO Forschungsgruppe ein BML-Standard entwickelt und nutzbar gemacht werden könnte. Ein erstes Experiment zur BML-Kopplung von Führungsinformationssystemen und Simulationssystemen beruhte auf XBML (Sudnikovich et al., 2006). Das gelungene Experiment trug wesentlich dazu bei, dass in 2006 eine entsprechende NATO RTO Forschungsgruppe (NATO RTO MSG-048 Coalition Battle Management Language) gegründet werden konnte. Mitarbeitende Nationen waren Frankreich (Chair), USA (Co-Chair), Dänemark, Deutschland, Großbritannien, Kanada, Niederlande, Norwegen, Spanien und Türkei. Die Gruppenmitglieder gehörten zum Teil auch der SISO-Gruppe an, womit ursprünglich ein aufeinander abgestimmtes Arbeiten dieser Gruppen gewährleistet werden sollte. Im November 2007 präsentierte die Gruppe ein Experiment auf der I-ITSEC (Orlando, Florida, USA). Bei diesem Experiment (vgl. dazu auch de Reus et al., 2008; Pullen et al., 2008) wurden simulierte Einheiten in drei unterschiedlichen Simulationssystemen von drei unterschiedlichen Führungsinformationssystemen aus mit BML befehligt. Die genutzte BML-Variante beruhte dabei auf einer Grammatik (vgl. dazu die folgenden Abschnitte), und die Kommunikation wurde mittels Web-Services geführt. Insgesamt war damit die durch die NATO MSG-048 der SISO als Standard vorgeschlagene BML-Variante am weitesten ausgearbeitet und am besten evaluiert.

17.4 Die formalen Konstruktionsprinzipien der BML Aufgrund der Forderung nach automatisierter Verarbeitbarkeit muss eine BML als formale Sprache konzipiert werden. Eine formale Sprache ergibt sich im Sinne der Linguistik – die Untersuchung automatisierter Sprachverarbeitung ist Gegenstandsbereich der Computerlinguistik, die auf Grundlagen der Informatik und der Linguistik zurückgreift – als die Menge aller Wortfolgen (Sätze), die mit einer Grammatik generiert werden können. Eine Grammatik ist ein Viertupel, bestehend aus einer endlichen Menge so genannter terminaler Symbole (den Wörtern der Sprache), einer endlichen Menge von nicht-terminalen Symbolen (den Bezeichnungen für „sinnvolle“ Sequenzen von Wörtern, den Konstituenten, beispielsweise „Satz“), einem Startsymbol und einer endlichen Menge von Produktionsregeln, nach denen die Wörter zu Sequenzen, zum Beispiel zu Sätzen, zusammengefügt werden dürfen. Verkürzt gesagt besteht eine Grammatik, die eine Sprache definiert, aus einem Lexikon und einer Menge von Produktionsregeln (Grammatikregeln). Die BML-Grammatik, die in den folgenden Unterabschnitten erläutert werden soll, ist die so genannte „Command and Control Lexical Grammar“ (C2LG), die innerhalb der NATO MSG-048 „Coalition BML“ (s. auch die Abschn. 17.3 und 17.6), aber auch für die BML Bw als zugrundeliegende Grammatik genutzt wird.

240

U. Schade und M. R. Hieb

17.4.1 Aufbau der grundlegenden BML-Ausdrücke Grundlegend für den Aufbau der BML-Ausdrücke ist die Befehlszeile, mit der einer Einheit eine Aufgabe (Task) zugewiesen wird. Die Regeln für diese Zuweisung werden Befehlsbasisregeln (OB wie „Order Basic“) genannt. Sie folgen dem durch Beispiel 17.1 vorgegebenen Format: Beispiel 17.1. OB ! Verb Tasker Taskee (Affected|Action) Where StartWhen (EndWhen) Why Mod Label Das durch Beispiel 17.1 vorgegebene Format ist wie folgt zu lesen: Am Anfang einer Befehlsbasisregel (OB) steht immer das Verb, welches die Aufgabe (die „Task“) bezeichnet, die die Einheit Tasker der ihr unterstellten Einheit Taskee zur Ausführung befiehlt. An diese Grundsequenz (Verb – Tasker – Taskee) schließen sich weitere Konstituenten an: Affected oder Action, sofern die Aufgabe jemanden oder etwas (im Fall von Affected) beeinflusst oder sich auf eine andere Aufgabe (im Fall von Action) bezieht; eine Angabe zur räumlichen Verortung der Aufgabe (Where); zwei Angaben zur zeitlichen Verortung: Wann soll mit der Erfüllung der befohlenen Aufgabe begonnen werden (StartWhen) und wann soll die Aufgabe erfüllt sein (EndWhen); eine Angabe zum Zweck, dem die Erfüllung der Aufgabe dient (Why); eine Wildcard (Mod), mit der Modifikatoren zu der zu erfüllenden Aufgabe angefügt werden können, und ein Label (Label), über das in anderen BML-Ausdrücken auf diese Aufgabenzuweisung verwiesen werden kann. Beispiele für Regeln, die dem Format von Beispiel 17.1 folgen, sind im Beispiel 17.2 aufgeführt. Beispiel 17.2. (a) OB ! advance Tasker Taskee RouteWhere StartWhen (EndWhen) Why Mod Label (b) OB ! ambush Tasker Taskee Affected AtWhere StartWhen (EndWhen) Why Mod Label (c) OB ! assist Tasker Taskee Action AtWhere StartWhen (EndWhen) Why Mod Label (d) OB ! rest Tasker Taskee AtWhere StartWhen (EndWhen) Why Mod Label Diese Regeln weichen in Einzelaspekten von einander ab. So enthält nur Beispiel 17.2(b) ein Affected. Dies liegt daran, dass von der Aktion „ambush“, nicht aber von den anderen drei genannten Aktionen eine andere Einheit, in diesem Fall die Einheit, der der Hinterhalt gilt, direkt betroffen ist. Der Befehl eines „assist“ (Beispiel 17.2(c)) verlangt statt des Affected ein Action, also eine Referenz auf die zu unterstützende Aktion. Die Regeln unterscheiden sich auch in der Art des zu nutzenden Where. Die Aktion „advance“ (Beispiel 17.2(a)) schließt eine Bewegung ein und verlangt daher ein RouteWhere, mit welchem dann die räumlichen Aspekte der Bewegung repräsentiert werden können. Im Gegensatz dazu verlangen die anderen Aktionen eine einfache Ortsangabe, wofür das AtWhere verwendet wird.

17 Battle Management Language

241

Das genaue Aussehen einer Befehlsbasisregel ergibt sich aus seinem Verb, also der befohlenen Task. Umfasst etwa die Task eine Bewegung, so enthält die Regel zu dieser Task ein RouteWhere. Anderenfalls enthält sie ein AtWhere. Entsprechendes gilt für das Vorhandensein von Affected und für einige weitere Variationen. Da sich das genaue Aussehen der Regeln in Abhängigkeit von lexikalischen Elementen ergibt, ist die so definierte BML-Grammatik lexikalisch bestimmt („lexically driven“). Die Grammatik erfüllt damit auch eine der Voraussetzungen für eine LFG (Lexical Functional Grammar; Kaplan & Bresnan, 1982; Bresnan, 2001). In der Tat ist die postulierte Grammatik zusammen mit dem Algorithmus, der die Konstituenten auf die thematischen Rollen (Sowa, 2000) abbildet, eine LFG-Variante. Die Lexikalisierung der Befehlsbasisregeln und der Umsetzungsalgorithmus sorgen auch dafür, dass die für eine LFG wichtigen linguistischen Grammatikprinzipien der Vollständigkeit und der Kohärenz beachtet werden. Details zu der grammatiktheoretischen Einordnung der postulierten Grammatik als LFG-Variante finden sich in Schade & Hieb (2007a).

17.4.2 Aufbau von BML-Befehlen und BML-Meldungen Für Operationsbefehle gilt der NATO-Standard STANAG 2014. Ein Operationsbefehl verfügt danach über fünf Hauptabschnitte (Paragraphen), wobei in Paragraph 3 „Execution“ die Zuweisung der Aktionen erfolgt. In der BML gibt es daher die in Beispiel 17.3 angeführte Regel, die die Erstellung von Paragraph 3 eines Operationsbefehls bestimmt. Darin steht CI für Command Intent (Concept of Operations), OB für die mit den Befehlbasisregeln erstellte Zuweisung von Aufträgen (Aktionen) an die unterstellten Einheiten, CS für Befehle zur räumlichen und CT für Befehle zur zeitlichen Koordination. Beispiel 17.3. OrderParagraph3 ! CI OB CS CT Ein Command Intent besteht in BML aus der Angabe von so genannten „Key Tasks“ und von den zu erreichenden Zielzuständen (Desired End States), s. Beispiel 17.4. Beispiel 17.4. CI ! KeyTask EndState Ein KeyTask wird als Befehl formuliert und folgt daher dem Muster einer Befehlsbasisregel. Ein EndState wird als Meldung formuliert, wobei der zugehörige Meldungszeitpunkt in der Zukunft liegt und die Angabe zur Verlässlichkeit der Meldung auf sicher („fact“) gesetzt wird. Ein Zielzustand sieht damit aus wie die Meldung, die nach dessen Erreichen von der ausführenden Einheit abgesetzt werden sollte. Damit wäre nun noch zu klären, wie in BML Meldungen aussehen. Meldungen werden unterschieden in a) Meldungen zu militärischen Aktionen, b) Meldungen zu Ereignissen, die keine militärischen Aktionen darstellen, und c) Statusmeldungen, zu denen auch die Meldungen zu Positionen von Einheiten zählen. Dementsprechend gibt es drei Regelformate, mit denen Einzelmeldungen (Report Basic – RB)

242

U. Schade und M. R. Hieb

erzeugt werden können: Das Format für Meldungen zu militärischen Aktionen, gegeben in Beispiel 17.5(a), welches dem Format für die Befehlsbasisregeln gleicht, das Format für Meldungen zu Ereignissen, dargestellt in Beispiel 17.5(b), und das Format für Statusmeldung in Beispiel 17.5(c). Insgesamt besteht eine Meldung aus einer Anzahl dieser Einzelmeldungen, denen ein Header, der auf Absender, Empfänger, Meldezeit etc. verweist, vorausgestellt wird. Beispiel 17.5. (a) RB ! [Task-Report] Verb Executer (Affected|Action) Where When (Why) Certainty Mod Label (b) RB ! [Event-Report] EventVerb (Affected|Action) Where When Certainty Mod Label (c) RB ! [Status-Report] Hostility Regarding (Identification Status-Value) Where When Certainty Mod Label Das Verb im Meldungsformat für die Meldung von militärischen Aktionen (TaskReport) entspricht dem Verb in dem Format für die Basisbefehle; das EventVerb im Meldungsformat für Ereignismeldungen denotiert das Ereignis, z. B. „flood“, und Regarding in dem Format für Statusmeldungen bezeichnet die Art des gemeldeten Status (genereller Status, Personalstatus, Materialstatus, Position). Meldungen sind in BML daran zu erkennen, dass sie einen Verlässlichkeitseintrag (Certainty) beinhalten, mit dem Angaben über die Quelle der gemeldeten Information sowie über die Verlässlichkeitseinschätzung zur Quelle und zum Inhalt der Meldung mit übermittelt werden können. Im folgenden Abschnitt wird ein kurzes Sprachbeispiel vorgestellt und erläutert, aus welchem sich das tatsächliche Aussehen von BMLBefehlen und BML-Meldungen ergibt.

17.5 Sprachbeispiele Um aufzuzeigen, wie Befehle und Meldungen, die in BML verfasst sind, tatsächlich aussehen, soll in diesem Abschnitt ein Beispiel vorgestellt werden. Dieses (Beispiel 17.6) zeigt Teile des Inhalts eines Befehls. Mit den ersten drei Zeilen wird der situative Kontext festgestellt: Eine eigene Patrouille (PLT) ist von mehreren feindlichen Heckenschützen am Kontrollpunkt 3 unter Feuer genommen worden. Diesem Gegner wird mit der ersten BML-Zeile das Label „label-en-1“ zugeschrieben. Als Folge des Angriffs sind zwei Dingos nicht mehr fahrbereit. Die Soldaten der Patrouille sind aber derzeit noch alle unverletzt. Mit der vierten Zeile befiehlt der Bataillonskommandeur (BltL), dessen dritte Kompanie die Patrouille stellt, seiner zweiten Kompanie (COY2), der Patrouille sofort zu Hilfe zu eilen, um in den Feuerkampf einzugreifen und den Gegner zu vernichten. Beispiel 17.6. ambush team hostile sniper label-en-1 PTL at ControlPoint3 at now fact labeltr-1;

17 Battle Management Language

243

friend status-material 2 Dingo immobilized at ControlPoint3 at now fact label sr-1; friend status-personnel 16 Enlisted fit at ControlPoint3 at now fact label-sr-2; relieve BtlL COY2 PTL at ControlPoint3 start at now in-order-to destroy labelen-1 label-o-1; Das hier angeführte Beispiel vermittelt natürlich nur einen ersten Eindruck, wie BML-Befehle und BML-Meldungen aussehen. Weitere und ausführlichere Beispiele finden sich in Schade & Hieb (2006b), Schade & Hieb (2006a) und Schade & Hieb (2007b).

17.6 Anwendungsbeispiele Die BML-Version, die für die Bundeswehr entwickelt wird (BML Bw), folgt weitgehend der BML, wie sie im Rahmen der NATO RTO MSG-048 „Coalition Battle Management Language“ realisiert wurde (vgl. dazu Abschn. 17.3). Auch in Bezug auf die Anwendungen von BML Bw stehen derzeit wie bei der MSG-048 solche Applikationen im Mittelpunkt, bei denen BML genutzt wird, um simulierten Einheiten Befehle zu erteilen. Wichtige Beispiele solcher Applikationen sind Demonstrationssysteme, in denen die Verbindung zu den Simulationssystemen mit BML realisiert ist. Für das Demonstrationssystem der MSG-048 wurde das vom FKIE (Deutschland) entwickelte GUI zur Eingabe von BML-Befehlen und BML-Meldungen in die Führungsinformationssysteme ISIS (TNO – Niederlande) und NoRTAC C2IS (FFI – Norwegen) integriert. Die BML-Befehle und BML-Meldungen folgen dabei dem vorgestellten Ansatz für die BML-Grammatik. Die BML-Befehle werden nach ihrer Eingabe in das JBML-Format umwandelt. Auch dieses Format ist durch die vorgestellte Grammatik und das Standarddatenmodell JC3IEDM geprägt. Befehle im JBML-Format werden dann über entsprechende Web-Services an Simulationssysteme übermittelt. Die Web-Services (sowie das JBML-Format) wurden durch das Center of Excellence for C4I der George Mason University, Fairfax, Virginia, USA, entwickelt. Im Fall des MSG-048 Demonstrationssystems wurden als Simulationssysteme JSAF (USA), SCIPIO (Thales – Frankreich) und SIMBAD (Isdefe – Spanien) genutzt. Eine erste Version des Demonstrationssystems wurde im November 2007 und eine weiterentwickelte Version im Dezember 2008 jeweils während der I-ITSEC in Orlando, Florida, eingesetzt. Ausführliche Beschreibungen der ersten Demonstration finden sich in Pullen et al. (2008) und de Reus et al. (2008). Die so mittels BML realisierte Verbindung zwischen den Führungsinformationssystemen und Simulationssystemen erlaubt, wie bereits erwähnt wurde, simulationsgestützte und damit kostengünstigere Übungen zum Training von Führungsabläufen. Des Weiteren ist die Realisierung dieser Verbindung ein wichtiger Schritt hin zu einer Nutzung der Simulationssysteme in einem Entscheidungsunterstützungsmodul von Führungsinformationssystemen.

244

U. Schade und M. R. Hieb

Beide Funktionalitäten können durch eine weitere interessante und zukunftsträchtige Applikation von BML verbessert werden. Diese Applikation besteht darin, die Agenten in einem agentenbasierten Simulationssystem mittels BML kommunizieren zu lassen. Ist das Simulationssystem dann auch mittels BML an ein Führungsinformationssystem angebunden, können vergleichsweise jederzeit leicht einzelne der simulierten Einheiten durch reale Einheiten ersetzt werden. Die Kommunikation zum übergeordneten Führungssystem sowie zu anderen Einheiten, mögen sie dann real oder „nur“ simuliert existieren, wird in allen Fällen über BML abgewickelt, so dass sich die Art der militärischen Kommunikation nicht ändert, wenn der angesprochene Austausch erfolgt. Das von FhG-IAIS im Auftrag des Bundesamtes für Informationsmanagement und Informationstechnik der Bundeswehr entwickelte Multi-Agenten-Simulationssystem ITSimBw nutzt entsprechend dieser Vision schon BML als Kommunikationssprache (Hügelmeyer et al., 2007). Ein analoger Ansatz wird auch durch das TNO (Niederlande) verfolgt und umgesetzt (Borgers et al., 2008).

Literaturverzeichnis Blais, C., Galvin, K., & Hieb, M. R. (2005). Coalition Battle Management Language (C-BML) Study Group Report. In Proceedings of the 2005 Fall Simulation Interoperability Workshop Orlando, FL, USA. Borgers, E., Spaans, M., Voogd, J., Hieb, M., & Bonse, R. (2008). Using a Command and Control Language to Simulate Operations in a Multi-Agent Environment. In Proceedings of the 13th International Command and Control Research and Technology Symposium Bellevue, WA, USA. Bresnan, J. (2001). Lexical-Functional Syntax. Malden, MA: Blackwell. Carey, S., Kleiner, M., Hieb, M. R., & Brown, R. (2001). Standardizing Battle Management Language – A Vital Move Towards the Army Transformation. In Proceedings of the 2001 Fall Simulation Interoperability Workshop Orlando, FL, USA. de Reus, N., de Krom, P., Mevassvik, O., Alstad, A., Sletten, G., Schade, U., & Frey, M. (2008). BML-enabling of national C2 systems for coupling to Simulation. In Proceedings of the 2008 Spring Simulation Interoperability Workshop Providence, RI, USA. Hügelmeyer, P., Schade, U., & Zöller, T. (2007). Application of BML to inter-agent communication in the ITSimBw simulation environment. In S. Henderson, B. Biller, M. Hsieh, J. Shortle, J. Tew, & R. Barton (Eds.), Proceedings of the 2007 Winter Simulation Conference Washington, DC, USA. Kaplan, R. & Bresnan, J. (1982). The Mental Representation of Grammatical Relations, chapter Lexical-Functional Grammar: A formal system for grammatical representation. MIT Press: Cambridge, MA. Perme, D., Hieb, M., Pullen, M., Sudnikovich, W., & Tolk, A. (2005). Integrating Air and Ground Operations within a Common Battle Management Language. In Proceedings of the 2005 Fall Simulation Interoperability Workshop Orlando, FL, USA. Pullen, M., Carey, S., Cordonnier, N., Khimeche, L., Schade, U., de Reus, N., Legrand, N., Mevassvik, O. M., Cubero, S., Godoy, S. G., Powers, M., & Galvin, K. (2008). NATO MSG-048 Coalition Battle Management Language Initial Demonstration. In Proceedings of the 2008 Spring Simulation Interoperability Workshop Providence, RI, USA. Schade, U. & Hieb, M. R. (2006a). Development of Formal Grammars to Support Coalition Command and Control: A Battle Management Language for Orders, Requests, and Reports. In Proceedings of the 11th International Command and Control Research and Technology Symposium Cambridge, UK.

17 Battle Management Language

245

Schade, U. & Hieb, M. R. (2006b). Formalizing Battle Management Language: A Grammar for Specifying Orders. In Proceedings of the 2006 Spring Simulation Interoperability Workshop Huntsville, AL, USA. Schade, U. & Hieb, M. R. (2007a). Battle Management Language: A Grammar for Specifying Reports. In Proceedings of the 2007 Spring Simulation Interoperability Workshop Norfolk, VI, USA. Schade, U. & Hieb, M. R. (2007b). Improving Planning and Replanning: Using a Formal Grammar to Automate Processing of Command and Control Information for Decision Support. The International C2 Journal, 1(2), 69–90. Sowa, J. F. (2000). Knowledge Representation – Logical, Philosophical, and Computational Foundations. Pacific Groves, CA: Brooks and Cole. Sudnikovich, W., Pullen, M., M.Kleiner, & Carey, S. (2004). Extensible Battle Management Language as a Transformation Enabler. Simulation, 80, 669–680. Sudnikovich, W., Ritchie, A., de Champs, P., Hieb, M., & Pullen, M. (2006). NATO Exploratory Team 016 – Integration Lessons Learned for C2IEDM and C-BML. In Proceedings of the 2006 Spring Simulation Interoperability Workshop San Diego, CA, USA. Tolk, A. & Kunde, D. (2003). Innovations in Decision Support Systems, chapter Decision Support Systems in Defence, (pp. 175–205). AKI: Innovations in Decision Support Systems.

Kapitel 18

Interoperabilität in der Lagebearbeitung Jürgen Kaster und Claus J. Weber

Interoperability: „. . . the ability of systems, units or forces to provide services to and accept services from, other systems, units or forces and to use the services so exchanged to enable them to operate effectively together without altering or degrading the information exchanged.“ DoD, NATO, ADF C&C Information Systems Plan (1995/6)

18.1 Einleitung Die vernetzte Operationsführung „NetOpFü“ bedeutet Führung und Einsatz von Streitkräften auf der Grundlage eines streitkräftegemeinsamen, ebenenübergreifenden und interoperablen Kommunikations- und Informationsverbundes, der alle Truppenteile und Einrichtungen sowie Sensoren und Effektoren geeignet miteinander verbindet. In jedem militärischen Führungszyklus (z. B. OODA1 ), besonders auch im Aufklärungszyklus der Nachrichtengewinnung und Aufklärung (CPDD2 ), ist die Erlangung von Informationsüberlegenheit ein grundsätzliches Ziel. Die Schaffung eines umfassenden, zeit- und sachgerechten Lageverständnisses ist somit eine Kernaufgabe militärischen Handelns. Aufgrund der besonderen Bedeutung von zeit- und ortsbezogenen Zusammenhängen ist der grafischen Lagedarstellung georeferenzierter Informationen eine zentrale Rolle beizumessen. Dies spiegelt sich unmittelbar in der „Konzeption der Bundeswehr“ (KdB; BMVg, 2004) wider: „Der Informationsbedarf wird durch eine zentrale, streitkräftegemeinsame Lagebearbeitung sichergestellt, bei der die Erkenntnisse aus der NG&A der Streitkräfte 1 2

OODA: Observation, Orientation, Decision and Action Loop (Führungszyklus) CPDD: Collection, Processing, Dissemination, Direction (Aufklärungszyklus)

M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

247

248

J. Kaster und C. J. Weber

mit den Ergebnissen der Nachrichtenbeschaffung und aus internationalen Kontakten zusammengeführt, zu einem gemeinsamen, aktuellen Lagebild verdichtet und als Lagefeststellung und -beurteilung in den Führungsprozess eingebracht werden. [. . . ] Voraussetzung hierfür ist die enge arbeitsteilige Zusammenarbeit aller lagebearbeitenden Organisationselemente des nationalen MilNW.“ (BMVg, 2004) So wird z. B. von dem Führungsinformationssystem Streitkräfte (FüInfoSys SK) erwartet, „auf dem Rechnerbildschirm am Arbeitsplatz – vom Bundesministerium der Verteidigung bis in das Einsatzland – ein gemeinsames Lagebild abrufen zu können. Es soll innerhalb aller Organisationsbereiche und über mehrere Führungsebenen hinweg die Voraussetzungen für eine einheitliche Lagebearbeitung schaffen.“ (IT-AmtBw, 2008). Gefordert wird somit die Möglichkeit einer durchgängigen, medienbruchfreien Lagebearbeitung – von der Erfassung vor Ort über das Ergreifen von Erstmaßnahmen, gesteuert durch die Operationszentrale, bis zur Lagebewältigung in einer überregionalen Befehlsstelle. In den oben angeführten Definitionen wird der verzugslose Informationsaustausch zwischen lageführenden Organisationselementen und damit implizit die Forderung nach hoher Interoperabilität der IT-Systeme besonders betont. Dieser Aspekt und die sich daraus ergebenden Konsequenzen werden im Folgenden näher beleuchtet.

18.2 Wahrnehmen – Verstehen – Projizieren Die Wahrnehmung der für eine definierte Aufgabensituation relevanten Information, verdichtet zu einem Verständnis der aktuellen Situation und ihres Kontextes, als Grundlage für die Entscheidungsfindung für zukünftige Handlungen, wird mit dem Begriff „Situationsbewusstsein“ (engl. Situation Awareness, daher oft abgekürzt mit SA) am treffendsten beschrieben (Human Factors, 1995; Widdel et al., 2006). Die Erzeugung der SA kann im OODA-Zyklus als Prozessschritt angesehen werden, der zwischen Beobachtung des Zustandes der Umwelt und der Entscheidungsfindung anzusiedeln ist. Nach (Endsley, 1995) läuft der Prozess, der zu einem richtigen Situationsbewusstsein führt, in drei Phasen ab:  Phase 1: Wahrnehmung von Elementen der Umgebung innerhalb einer definierten Zeit- und Raumausdehnung;  Phase 2: Aufbau eines Verständnisses der Bedeutung der einzelnen Elemente und der gesamten Szene;  Phase 3: Projektion des aktuellen Zustandes in die Zukunft, d. h. Vorhersage der zukünftigen Entwicklung des Szenarios. In dieser Modellvorstellung treten die wesentlichen Komponenten der Situation Awareness zutage: Raum-, Zeit- und Navigationsbewusstsein (entspricht im ITBereich einer thematischen Einordnung), was wiederum unmittelbar mit der militärischen Forderung nach einem raum-, zeit- und sachgerechten Lagebild korrespon-

18 Interoperabilität in der Lagebearbeitung

249

diert. Die Vielfalt der Anforderungen zur Erlangung der SA wird an Anwendungsfällen im Bereich der Nachrichtengewinnung und Aufklärung (NG&A) besonders augenfällig, der sich mit dem Aufnehmen und Erfassen der Feindlage befasst und aufgrund der nicht-kooperativen Umgebung im Wesentlichen unsicheres und unvollständiges Wissen verarbeiten muss. Die Befähigung eines Systems, Situation Awareness auf dieser hochkomplexen Basis zu fördern, muss dementsprechend in vielfältigen Betrachtungsdimensionen bewertet werden. In Bezug auf die Anforderung „Interoperabilität“ sind zudem unterschiedliche Abstraktionsebenen zu betrachten [vgl. auch Kap. 2: Grundlagen der Interoperabilität]. Diese werden in der NATO im LISI-Referenzmodell3 definiert. Die Klassifizierung benennt fünf technologische Ebenen, denen die organisatorischen Aspekte aus dem Blickwinkel der Anwender gegenübergestellt werden können (Clark & R. Jones, 1999). Daraus wiederum können die bestimmenden Attribute als Messlatte für den Begriff „Verständnis“ in Bezug zu der erreichten Interoperabilitätsstufe gesetzt werden (vgl. Tabelle 18.1). Aus dem Situationsbewusstsein ist eine „Situationsbewertung“ abzuleiten. Dieser Begriff ist nach (Federico, 1995) zu definieren als: Abschätzen einer Situation, Verstehen einer Situation, Definieren des Problems, Kategorisieren der Sachlage, Erstellen einer Repräsentation der Situation, Bilden eines mentalen Modells der Situation, Kreieren eines Abbildes der Sachlage. Aus dieser Definition wird die Überlappung von Situationsbewusstsein und Situationsbewertung deutlich, da beide die Beschreibungen „Verstehen einer Situation“ und „Bilden eines mentalen Modells der Situation“ als Definitionselemente enthalten. In Krisen- und Konfliktsituationen ist eine möglichst treffende Situationsbewertung unabdingbar. Hieraus ergibt sich unmittelbar, dass militärische Entscheidungsträger an der Realisierung einer möglichst hohen Interoperabilitätsstufe interessiert sind, wobei jeweils die niedrigeren Stufen als Basis vorausgesetzt werden müssen. Allerdings ist zu beobachten, dass die heutigen wehrtechnischen Systeme Kernforderungen der Ebenen 3 und 4 (z. B. „Sophisticated Collaboration“ oder „Simultaneous Interaction“) nur unzureichend umsetzen und Interoperabilität im Entwick-

Tabelle 18.1 Vergleich LISI-Klassifizierung mit organisatorischen Aspekten sowie Bezug zu Nutzerforderungen Ebene LISI-Definition

3

4 3

Enterprise Domain

Organisatorischer Aspekt Unified Combined

2

Functional

Collaborative

1

Connected

Ad hoc

0

Isolated

Independent

„Verständnis“ als Messlatte für die erreichte Interoperabilitätsebene Einheitliche Wissensbasis Gemeinsame Wissensbasen; gute Kommunikationsverfahren Gemeinsamer Informationsverbund; gemeinsamer Informationsraum Technische Kommunikation möglich; selektiver Datenaustausch nach Bedarf „Drehstuhlschnittstelle“

LISI = Levels of Information Systems Interoperability

250

J. Kaster und C. J. Weber

lungsgang vorwiegend als technische Anforderung – anzusiedeln bis Ebene 2 – verstanden wird. Folgt man hingegen dem Grundsatz „Quality always beats Quantity“, so würde man einen Informationsaustausch viel stärker auf einer höheren semantischen oder pragmatischen Ebene (Ebenen 3 bzw. 4) optimieren müssen. Damit einher ginge die verstärkte Realisierung vielfältiger, aufgabenangepasster Filter- und Aggregationsfunktionen bereits an der Datenquelle, wodurch Kommunikationsanforderungen an den Netzverbund und aufwändige Suchverfahren im Zielsystem minimiert würden. Die Bedeutung derartiger Filter- und Aggregationsfunktionen zwischen Datenerfassung an der Quelle und Auswertung im Zielsystem soll nachfolgend am Beispiel der Thematik „Lagebearbeitung“ diskutiert werden. Geeignete Filter an der Quelle und Aggregationen im Zielsystem ergeben sich hier aus dem Kontext, in den die Lage eingebettet ist. Unter Berücksichtigung dieses Paradigmas soll ein wichtiger Schritt zur Annäherung an das „relevante Einsatzlagebild“ aufgezeigt werden. Bevor der Begriff „Kontext“ näher untersucht wird, werden zunächst die grundsätzlichen Anforderungen an ein Lagebild sowie die Defizite heutiger Formalisierungen, die die Kriterien für den Datenaustausch festlegen, herausgearbeitet.

18.3 Anforderungen an das Lagebild Aus den vorangegangenen Erläuterungen wird deutlich, dass sich die konkreten Anforderungen an Lagedarstellung, -bearbeitung und -bewertung erst aus dem jeweiligen Einsatzszenario ergeben. Es stellt sich zunächst die Frage, welche Bedeutung dies für den Austausch von Lageinformationen und die diesbezüglichen Standardisierungsbemühungen hat. Offensichtlich sind die Anforderungen an ein Bewusstsein förderndes Lagebild umfassender, als dass sie durch eine Auflistung punktueller Einzelforderungen abgedeckt werden könnten. Diese Form der Spezifikation ist aber in der Vergangenheit die Regel gewesen, wenn die Anforderungen der Führungsinformationssysteme in Bezug auf Lagebearbeitung spezifiziert wurden. Daraus resultierten eingeschränkte Standards, singuläre Forderungen und unvollständige Schnittstellenbeschreibungen. Damit in einem Lagebild die aktuelle Situation im Sinnzusammenhang vollständig beschrieben werden kann, ist die Klarstellung der Einsatzumgebung, in dem es zu erstellen und zu bewerten ist, notwendig. Ohne diese semantische Einordnung kann nur bedingt auf Auswirkungen von Einzelbeobachtungen auf das militärische Problemfeld geschlossen werden. Umgekehrt legt eine genauere Betrachtung von Nutzerforderungen nahe, dass lagerelevante Informationen mehrfach verwendbar sein müssen. Das heißt es gibt je nach Aufgabenstellung unterschiedliche Sichtweisen, Prioritäten oder Filterungen bezogen auf einen darzustellenden Sachverhalt. Weiterhin muss mit dem Ziel eines klaren Situationsbewusstseins eine Klassifizierung und damit Gruppierung nach inhaltlichen Gesichtspunkten vorgenommen werden. Erst nach einer derartigen Klärung des Umfeldes können einzelne Objekte mit ihrer jeweiligen Beschreibung in dieses eingebettet werden.

18 Interoperabilität in der Lagebearbeitung

251

Typische Elemente einer Lage sind: Punktobjekte (Symbole, Marker etc.), Linienobjekte (Frontverläufe, Grenzen etc.) und Flächenobjekte (Verfügungsräume etc.), die jeweils auf einen Kartenhintergrund zu projizieren sind. Auch Geodaten können unmittelbar lagerelevant sein (Beispiel: ein Straßenzug, der für Verlegeoperationen genutzt wird). Zu Beschreibung eines Lageobjektes gehören z. B. Identifikatoren, lagerelevante Attribute sowie Quellenangabe und Historie der Beobachtung (z. B. um Mehrdeutigkeiten auflösen zu können). Verknüpfungen zwischen einzelnen Lageelementen spielen für die Auswertung eine besondere Rolle. Hinsichtlich der Beschreibung dieser Lageobjekte sind Standards soweit möglich einzuhalten, damit die Interoperabilität zu Fremdsystemen gewahrt bleibt. Bei einem System zur Lagebearbeitung ist die Definition der Schnittstellen ebenso wichtig wie der interne Aufbau und die funktionale Ausstattung der Anwendung. Dies wird aber sowohl bei der Spezifikation als auch bei der Entwicklung seit Jahren vernachlässigt. Das Ergebnis sind immer wieder sog. „Insellösungen“, die dem Anspruch nach Interoperabilität nicht gerecht werden.

18.4 Defizite bestehender Formalisierungen Bestehende Verfahren zur Formalisierung von militärischen Lagen verfolgen nur eingeschränkt die oben formulierten Ziele. Die Ansätze sind entweder zu stark auf die Visualisierung von Einzelobjekten fokussiert oder im Gegenteil derart generisch ausgelegt, dass konkrete Abbildungsvorschriften nur schwer abzuleiten sind. Nachfolgend werden einige Standards exemplarisch aus der Sicht eines Lagebearbeiters beleuchtet. Ausführliche Dokumentationen zu bestehenden Interoperabilitätsstandards finden sich in Kap. 14. So definiert die Zentrale Dienstvorschrift (ZDv) 1/11 „Taktische Zeichen“ (Bundeswehr, 1990) ausschließlich die grafische Symbolform für die Darstellung von Truppen, Einheiten, Geometrien oder Anweisungen, aber dies aufgrund vieler Mehrdeutigkeiten für eine computergestützte Automatisierung nicht einmal eindeutig. Innerhalb der NATO gilt die Allied Procedural Publication APP-6 „Military Symbols for Land Based Systems“ (NATO, 1999), die ebenfalls rein auf die formale Darstellung von taktischen Zeichen abhebt. In diesen Beschreibungen sind keine Anweisungen enthalten, wie der Bezug einer Einheit in Relation zu einer anderen festgehalten wird, eine Bezugnahme zu einem Lagekontext ist ebenfalls nicht vorgesehen. Als Austauschformat für formatierte Nachrichten (Beobachtungen, Meldungen etc.) wurde der Standard ADatP-3 (NATO, 1994) entwickelt. ADatP-3 definiert das NATO Message Text Formatting System (kurz FORMETS) als Austauschformat zwischen den Systemen, Einheiten und Streitkräften. FORMETS umfasst die Regeln, Konstruktionen und das Vokabular für ein standardisiertes Message Text Format (MTF), das sowohl in manuellen als auch in computerunterstützten Umgebungen genutzt werden kann. Hier können Objekte z. B. zu einer Eigen- oder Feindlage zumindest in Listenform zusammengefasst und ansatzweise in Bezug zu einem Szenario (Einsatz oder Übung) gebracht werden. Weiterhin können in einer Meldung

252

J. Kaster und C. J. Weber

der Einsatzrahmen benannt werden, Zeitbezüge festgelegt oder Unterstellungsverhältnisse angegeben werden. Typische Meldungsbeispiele sind der OWNSITREP (Eigenlage Heer) oder der ENSITREP (Feindlage Heer). Die MTF sind zwar sehr detailliert, lassen aber den Situationsbezug außer Acht. Ein deutlich weitergehender Ansatz wird mit dem „Multilateral Interoperability Programme“ (MIP, 2008a) verfolgt. MIP stellt im Rahmen verteilter, heterogener Führungsinformationssysteme die Grundlage für einen vollautomatisierten, kontextbezogenen Informationsaustausch dar und legt die Semantik für die Bezeichnung militärisch relevanter Objekte, Aktionen etc. und deren Beziehungen in eindeutiger Weise fest (Details zu MIP in Kap. 16). Im Rahmen der MIP-Lösung wurde der Data Exchange Mechanism (DEM) spezifiziert, welcher eine (Teil-)Replikation von operationellen Informationen unter Berücksichtigung ihrer Zugehörigkeit zu einer bestimmten Operationellen Informationsgruppe (OIG) und deren Verteilungsregeln erlaubt. Als problematisch in Bezug auf die in diesem Kapitel behandelte Thematik ist anzusehen, dass die Austauschregeln zwischen MIP-Systemen festgelegt werden, die Datenübergabe „nach außen“, z. B. die grafische Abbildung im Sinne einer Wiedergabe der Gesamtsituation, dagegen weitgehend den jeweiligen Anwendungssystemen vorbehalten bleibt. Zwar sieht MIP vor, dass gemäß Nutzersicht zusammengehörende Objekte in logischen Gruppen zusammengefasst werden können, jedoch gibt es keine einfachen Anleitungen, wie aus dem vorhandenen Datenbestand das einem aktuellen Betrachtungsfokus entsprechende Lagebild zusammengestellt werden kann. Auch in den für bestehende FüInfoSys vorliegenden Anforderungskatalogen zur Lagedarstellung wird nur rudimentär die grundsätzliche Struktur eines Lagebildes angesprochen. Beispielsweise werden zumeist pauschal „Multi-Layer“Darstellungen gefordert, aber keine logische Einbettung von solchen Darstellungsebenen in ein Szenario definiert oder gar die semantische Bedeutung von Layern festgelegt. Auch typische militärische Grundforderungen, z. B. die Forderung nach einer interaktiven, objektorientierten Bearbeitbarkeit von Einzelelementen in einer Lage, werden nicht immer ausreichend berücksichtigt.

18.5 Kontextbezogene Zuordnung von Einzelbeobachtungen Ein Lagebild ist im operationellen Sinne kein „Bild“, das man sich unmittelbar auf dem Bildschirm anschaut, sondern vielmehr ein „mentales Abbild“ der Situation, das sich im Kopf des Auswerters bildet.4 Ebenso muss auch der Begriff des „Gemeinsamen Rollenorientierten Einsatzlagebildes“ (kurz GREL) als abstraktes Konstrukt verstanden werden, das in der Lagedarstellung nur ein unzureichendes Abbild erfahren kann. Sowohl in der deutschen Abkürzung „GREL“ als auch in der entsprechenden englischen Abkürzung „CROP“ (Common Relevant Operational Picture) 4

Hier wird eine Analogie zum Begriff „Wissen“ deutlich, der sich von „Information“ in ähnlicher Weise abhebt.

18 Interoperabilität in der Lagebearbeitung

253

findet sich das aus Nutzersicht bedeutsame „R“. Es bedeutet einerseits „rollenorientiert“ und im anderen Fall „relevant“.5 Hier spiegelt sich das Vorhandensein unterschiedlicher Nutzersichten bei der Bewertung der Lage wider. In den folgenden Abschnitten wird der Frage nachgegangen, wie die „Rolle“ im GREL beziehungsweise die „Relevanz“ im CROP in einer Anwendung konkretisiert werden kann. Hier soll die Einführung der Begriffe „Lagekontext“, „Objektkontext“, „Kontexttaxonomie“ und „Relevanzkontext“ für Klarheit sorgen.

18.5.1 Lagekontext und Objektkontext Für einen Einsatz wird der Lagekontext durch die Umgebungsbedingungen, die Aufgaben und die Betrachtungsweisen der jeweiligen Nutzer bestimmt. Zum Kontext gehören beispielsweise Angaben über den Einsatz (Name, Mission, Area, Order Of Battle, usw.) sowie Hintergrundinformationen (Road To Crisis, Rules Of Engagement, Time Frame). Ein Lagebild ist hierbei einer Krise, einer bestimmten Ereignisfolge und weiteren thematischen Kategorien zugeordnet. Zur Bildbeschreibung gehören Angaben wie Titel, Bildtyp (Hotspot, Historie etc.), Struktur (Lageebenen), Thema (Führungsgrundgebiet, Objektarten etc.), Zeitbezug (Gültigkeitszeitraum etc.), Raumbezug und Sicherheitsfragen. Objekte eines militärischen Lagebildes existieren somit in einem definierten Rahmen. Sie besitzen einen konkreten Raum- und Zeitbezug und können gemäß ihrer Bedeutung verschiedenen Themen (Kategorien) zugeordnet werden. Diese Bezüge bilden zusammen mit Informationen über Herkunft und Qualität, internen und externen Verknüpfungen sowie weiteren Metainformationen den Objektkontext eines einzelnen Lageobjektes. Beim Austausch von Lageinformationen sind diese Bezüge mitzuführen oder zu referenzieren, damit die semantische Einordnung nicht verloren geht. Die Verknüpfungen erlauben beispielsweise die Auswertung von Objektrelationen im Lagebild, wodurch eine wesentliche Forderung zukunftsweisender Auswertesysteme erfüllt wird. Zur Definition eines Einsatzlagebildes, speziell bei der Bestimmung der für die jeweilige Rolle relevanten Lageobjekte, können die vorgenannten Bezugsgrößen herangezogen werden. Der thematischen Einordnung einer militärischen Lage und der enthaltenen Objekte kommt hierbei besondere Bedeutung zu. Hier bieten sich zwei einfach zu handhabende Modelle an: eine (oder mehrere) Hierarchien von Kategorien und die Verwendung von Schlagworten.

18.5.2 Kontexttaxonomie Hierarchiebäume ermöglichen eine schnelle, zielgerichtete Orientierung innerhalb der Kategorien. Ein typisches Beispiel für den hierarchischen Aufbau von themati5

Die Begriffe „rollenbasiert“ und „relevant“ werden in der Praxis durchaus synonym gehandhabt, da sich aus der Nutzerrolle unmittelbar die Relevanz ergibt.

254

J. Kaster und C. J. Weber

schen Kategorien findet sich in der „Datenbank Einsatz Bw“, die im Meldewesen der Bundeswehr Anwendung findet (vgl. Kaster et al., 2003). Der Dokumentkopf einer entsprechenden Meldung mit den Attributen u. a. zur thematischen Einordnung ist in Abb. 18.1 dargestellt. Zur flexiblen Handhabung werden in der Datenbank die zugehörigen Kategorien in Wertelisten (im Bild erkennbar an den DropDown-Schaltflächen hinter den Eingabefeldern) verwaltet. Diese werden in einem zentral administrierten Repository verwaltet, da eine freie Vergabe rasch zu einer Unübersichtlichkeit und sogar Instabilität der Themenliste führen würde. Auf der ersten Hierarchieebene kann die Art des Meldungstyps festgelegt werden. In aktuellen Szenarien sind folgende Informationsarten von Bedeutung: Ereignismeldung, Zwischenfall, Einheit, Personenmeldung, Organisation, Liegenschaft, Geoinformationen, Aufklärung usw.6 Diesen werden in einem Einsatz relevante Haupt- und Unterthemen zugeordnet. In der praktischen Anwendung hat sich diese Dreistufigkeit der verwendeten Kategorien als sehr vorteilhaft herausgestellt (vgl. Kap. 9). Zusätzlich besteht die Möglichkeit, Kategorien über frei wählbare Schlagworte zu definieren. Es empfiehlt sich, diese Schlagworte in einem zentral administrierten

Abb. 18.1 Template aus der „Einsatzdatenbank Bw“ (Ausschnitt aus dem Meldungskopf) 6

Beispielhafte Aufzählung ohne Anspruch auf Vollständigkeit. Eine ausführliche Auflistung von Meldungsarten findet sich z. B. in (EinsFüKdoBw, 2002).

18 Interoperabilität in der Lagebearbeitung

255

Wörterbuch (Dictionary) zu verwalten. Dies bietet den Vorteil, den Bezugsrahmen im laufenden Einsatz nach Bedarf an neue Sachverhalte und Zustände anpassen zu können. Eine sinnvolle thematische Klassifizierung der Lageobjekte besteht folgerichtig aus einer kombinierten Verwendung von Hierarchien und Schlagwortlisten. Der Vorteil einer festen Struktur bei gleichzeitig hoher Flexibilität im Anwendungsbezug bleibt erhalten. So kann sichergestellt werden, dass im Einsatz jede Lageinformation in eine oder mehrere Kategorien eingeordnet werden kann. Diese Klassifizierung gemäß Herkunft, Qualität, Raum- und Zeitbezug sowie thematischer Kategorien wird mit dem Begriff Kontexttaxonomie bezeichnet. Ein Objektkontext lässt sich als konkrete Instanziierung der Kontexttaxonomie auffassen. Er zählt für ein einzelnes Lageobjekt genau diejenigen Hierarchieknoten und Schlagworte auf, denen das Lageobjekt thematisch zugeordnet ist.

18.5.3 Relevanzkontext Die Kontexttaxonomie spiegelt sich – mehr oder weniger ausgeprägt – in dem Datenmodell einer militärischen Lagedatenbank wider. Auf dieser Basis lassen sich für eine Lagedatenbank in sich geschlossene Anfragen realisieren, also Anfragen, die gezielt die Objektkontexte in der Datenbank auswerten. Die Anfrage basiert dabei auf einem oder mehreren Kontextfiltern. Ein Kontextfilter entspricht rein formal ebenfalls einer Instanziierung der Kontexttaxonomie. Er definiert Raum und Zeit, Herkunft, Qualität und Kategorien. Nur diejenigen Lageobjekte passieren den Filter, deren Objektkontext alle Kriterien des Kontextfilters erfüllen. Die Realisierung eines GREL bedeutet, dass sich jeder Nutzer auf genau die Informationen konzentrieren kann, die er für die Erfüllung seiner Aufgabe benötigt. Das bedeutet, dass neben der räumlichen, zeitlichen und thematischen Filterung zusätzlich ein rollenorientierter Objektfilter auf das Lagebild angewendet werden muss. Ein solcher an der Nutzerrolle orientierter Filter kann mit Hilfe eines so genannten Relevanzkontextes realisiert werden, der einer Verknüpfung von einzelnen Kontextfiltern entspricht. Folgende formale Kombinationsarten sind möglich: Die UND-Verknüpfung zweier Kontextfilter stellt sicher, dass nur Objekte den Filter passieren, die alle Kriterien zugleich erfüllen. ODER-Verknüpfungen ermöglichen das „Durchreichen“ von Objekten, die mindestens einen der Kontextfilter erfüllen. Es gibt weitere Operatoren (z. B. den NICHT-Operator und den Klammer-Operator), die eine weitere Anpassung der Objektauswahl gemäß den Nutzerintentionen ermöglichen. Ein entscheidendes Merkmal des hier vorgestellten Relevanzkontextes ist, dass die Realisierung flexibel und systemunabhängig ist. Die Definition des Relevanzkontextes selbst lässt sich in einem offenen, standardisierten Format, beispielsweise im XML-Format, ablegen. Dies erlaubt die systemunabhängige Implementierung des GREL-Konzepts. Die Nutzerrollen sind einsatzspezifisch, können aber aus der Erfahrung heraus weitgehend a priori definiert werden. Dies bedeutet auch, dass zu den im Einsatz

256

J. Kaster und C. J. Weber

benötigten Rollen ihr Relevanzkontext im Voraus bestimmt werden kann. Die Realisierung der rollenorientierten Filter erlaubt jedoch auch eine dynamische Anpassung der Relevanzkontexte (und damit des GREL) während des Einsatzes.

18.5.4 Übertragungskonzept für Situationsbeschreibungen Das Zusammenspiel von Kontext, Kontexttaxonomie und Relevanzkontext wird anhand der Abb. 18.2 deutlich. Die Meldungen werden in entsprechenden Datenhaltungssystemen verwaltet („DB“). Für die grafische Abbildung stellt die Anwendungsumgebung eine an den Nutzerforderungen ausgerichtete Anzahl von thematischen Ansichten (entspricht einzelnen Lagebildern; z. B. „Areas of Interest“, „Military Intelligence“) zur Verfügung („LD“). Die Filterung, welche Objekte zu einem definierten Thema gehören, wird durch die Kontexttaxonomie („KT“) festgelegt. Die Zusammenfassung, welche Objekte zu einem bestimmten Lagebild gehören, ist durch den Relevanzkontext („RK“) bestimmt. Beide zusammen definieren die Transformation von Datenhaltung zu Lagebild. Sie ermöglicht es, aus einer Vielfalt von Datenquellen wiederum eine Vielfalt von nutzerorientiert aufbereiteten Lagebildern zu generieren. Wenn dieser Prozess ohne Zeitverzug und automatisiert stattfinden kann, ist die Realisierung eines rollenorientierten, dynamischen Einsatzlagebildes – basierend auf der aktuellen Meldungslage – möglich. Aus dem Kontext des Einsatzschwerpunktes („Hotspot“) oder einer Aufgabe („Mission“) wird dreierlei abgeleitet:  er gibt vor, welche Metadaten in den Eingangsdaten zu erfassen sind;

Abb. 18.2 „Kontext“ als inhaltliche Klammer für Datenbankeinträge, Lagebilder und dazwischengeschaltete Filtermechanismen. Kontexttaxonomie und Relevanzkontext bilden gemeinsam die Transformation von der Datenhaltung zur Lagedarstellung

18 Interoperabilität in der Lagebearbeitung

257

Abb. 18.3 Beispiel für ein Lagebild, bei dem der Kontext aus der Datenbank mit übertragen wurde. Taxonomie-Anteile: Waffenfunde, Übergriffe. Relevanz-Anteile: Einsatzbereiche, Kartenauswahl

 er definiert den „Rahmen“ des jeweiligen Lagebildes (thematischer Bezug);  er ermöglicht die Ableitung der Filter- und Aggregationsregeln für den „Transformator“, der aus Kontexttaxonomie und Relevanzkontext besteht.

18.6 Austauschformat für militärische Lageinformationen Bestehenden Formalisierungen für den Austausch von Lageinformationen ist – wie in Abschn. 18.4 ausgeführt – gemeinsam, dass sie die vorgenannten anwendungsbezogenen Anforderungen an kontextsensitive Lagebilder nicht berücksichtigen können. Während bestehende Spezifikationen einerseits auf die Visualisierung von Einzelobjekten ausgerichtet sind, lassen andere durch ihre hohe Normalisierung in der Beschreibung von Objekten und ihrer Relationen konkretisierbare Abbildungsvorschriften vermissen. Im Folgenden wird versucht, durch Ableitung eines Austauschformates für Lageinformationen eine Brücke zwischen beiden Sichtweisen zu schlagen. Dieses Austauschformat soll die Aufgaben und Intentionen eines Lagebearbeiters im Sinne eines „nutzerzentrierten Designs“ in den Mittelpunkt stellen.

258

J. Kaster und C. J. Weber

18.6.1 Kriterien für ein Austauschformat von Lageinformationen Kontextsensitive Lagedaten werden entweder zwischen verschiedenen Datenhaltungssystemen übertragen oder zwischen einem Datenhaltungssystem und einem angeschlossenen Lagedarstellungssystem. An ein formales Austauschformat müssen u. a. folgende Kriterien angelegt werden:      

Kompatibilität zu militärischen Standards, Berücksichtigung der Schnittstellen nationaler und internationaler FüInfoSys, eindeutige Identifizierung von Objekten und ihren Abhängigkeiten, Mitführen der Einsatzbezüge und der Lagehistorie, Beibehaltung der Quellenangaben und ihrer Bewertung sowie Vollständigkeit aller Informationen zur Visualisierung des Lagebildes.

Unabhängig von einem konkreten Austauschformat und dessen Qualität muss berücksichtigt werden, dass einer Lagebeschreibung keine objektive Gültigkeit zuerkannt werden kann. Dies gilt besonders in dem nicht-kooperativen Umfeld der Nachrichtengewinnung und Aufklärung (vgl. Kap. 9). Der Grund liegt in vielerlei Unsicherheiten, die im Datenbestand nicht zu vermeiden sind. Kritisch ist beispielsweise – angesichts der heutzutage enormen Datenmengen und der damit verbundenen Schwierigkeit, die wichtigen Informationen von den weniger wichtigen zu trennen – die Bewertung der Nachhaltigkeit von Einzelbeobachtungen. Deutlich wird dies am Beispiel der Glaubwürdigkeit („Authenticity“) einer Nachricht oder der Zuverlässigkeit („Reliability“) einer Quelle. Da eine militärische Lage in der Regel ein Agglomerat von Daten aus unterschiedlichsten Quellen ist, haben die enthaltenen Informationen in Bezug auf diese Kennwerte einen ganz unterschiedlichen Status. Ein weiterer Unsicherheitsfaktor ist, dass eine Datenbank nicht aufgelöste bzw. nicht erkannte Duplizitäten enthalten kann, da dasselbe Ereignis, dieselbe Einheit etc. möglicherweise von unabhängigen Quellen mehrfach gemeldet wurden. Bei der Zusammenstellung und Bewertung einer militärischen Situation müssen derartige spezifische Eigenarten militärischer Lagen berücksichtigt werden.

18.6.2 Die „Military Situation Description Language“ (MSDL) Als formales Austauschformat für derartige Lageinformationen wird die Entwicklung einer Beschreibungssprache „Military Situation Description Language“ (MSDL) postuliert.7 Diese soll einerseits dem Zweck des Austauschs von Lageinformationen dienen, aber darüber hinaus geeignet sein, inhaltlich vollständige militärische Lagen mitsamt ihrer zeitlichen Entwicklung zu beschreiben (Weber &

7

nicht zu verwechseln mit: „Military Scenario Definition Language“ (MSDL) (SISO, 2008)

18 Interoperabilität in der Lagebearbeitung

259

Meister, 2008).8 Als wesentliche Eigenschaft wird gefordert, dass alle Objekte ihre Kontextinformationen mit sich führen oder zumindest darauf verweisen. Als technische Grundlage für MSDL bietet sich die „erweiterbare Auszeichnungssprache“ XML (engl. Extensible Markup Language) an. XML (W3C, 2006) selbst spezifiziert eine Metasprache zur Modellierung von textbasierten Auszeichnungssprachen. Eine XML implementierende Auszeichnungssprache besitzt den Vorteil, über eine standardisierte Schnittstelle maschinell interpretierbar zu sein. Sie eignet sich damit zur automatisierten Lageverarbeitung, beispielsweise zur Kommunikation zweier Lagedatenbanken untereinander. Ein weiterer Vorteil XMLbasierter Formate liegt in der einfachen Definition von Umwandlungsregeln. Mittels einer Extensible StyleSheet Language Transformation (XSLT; W3C, 1999a) lässt sich ein XML-Dokument in ein anderes XML-Format umwandeln. Die Anbindung des Austauschformats an fremde Lagedatenbanken oder Führungsinformationssysteme ist somit über die XML-Schnittstelle dieser Systeme realisierbar. Fremdsysteme müssen nicht notwendigerweise das Austauschformat MSDL selbst implementieren. Zur Vereinfachung von Stylesheet-Transformationen, aber auch generell mit der Zielsetzung hoher Interoperabilität, müssen die Bausteine des MSDL-Formats verbreitete, offene XML-Standards implementieren. Da die Objekte in einer militärischen Lage zu einem hohen Anteil durch georeferenzierte Vektordaten repräsentiert werden können, haben die im GIS-Sektor9 etablierten Standards besondere Bedeutung für die MSDL. Hier ist vor allem die Geography Markup Language (GML) zu nennen, die vom Open Geospatial Consortium (OGC, 2007) publiziert wird und seit der Version 3.2.1 auch als eigener ISO-Standard 19136 (ISO, 2007) etabliert ist. Die GML-Spezifikation definiert eine Sammlung von XML-Schemata inklusive einer umfangreichen Datentypisierung, die die Struktur eines XML-Dokuments mit geographischen Objektrepräsentationen festlegen. Da GML eine umfangreiche Sammlung von Schemata ist, die sehr viele Aspekte der Objektmodellierung abdeckt, wird von einer Anwendung nicht erwartet, den kompletten Umfang umzusetzen. In der Praxis wird eine konkrete Anwendung eine konsistente Teilmenge der GML-Schemata implementieren, ein sogenanntes GML-Profil. MSDL implementiert ein solches GML-Profil. Es beinhaltet alle Geometrien, die zur Abbildung einer militärischen Lage benötigt werden. Ein weiteres Schema aus der GML-Sammlung, das GML-Schema „temporal“, liefert XML-Konstrukte für die Beschreibung von Zeitpunkten und Zeitdauern. Auch dieses Schema ist Teil des GML-Profils der MSDL. Mit Hilfe der verfügbaren Elemente wird die Lage zeitlich eingeordnet und eine Historie mitgeführt. Da GML beispielsweise in der verbreiteten Spezifikation Web Feature Service WFS (OGC, 2005b) Anwendung 8 Hier grenzt sich MSDL zu Ansätzen wie der Battle Management Language (BML, Kap. 17) ab: BML ist eine formale Sprache, mit der einzelne Befehle, Meldungen und Anforderungen maschineninterpretierbar formuliert werden können. Diese Informationen werden zwischen Führungsund Simulationssystemen bzw. zwischen Führungssystemen untereinander ausgetauscht. BML ist im Gegensatz zu MSDL nicht dazu ausgelegt, vollständige Lagen zu übertragen oder Kontextzusammenhänge bezogen auf ein rollenorientiertes Lagebild zu definieren. 9 (GIS = Geographisches Informationssystem)

260

J. Kaster und C. J. Weber

findet, ebenfalls ein OGC-Standard, ist eine Anwendung, die MSDL implementiert, in einer modernen, serviceorientierten Umgebung leicht umsetzbar. In den folgenden Abschnitten werden die wesentlichen Bausteine des MSDLFormats, insbesondere die Implementierung des Objektkontextes, kurz vorgestellt. Eine vollständige Formatbeschreibung findet sich in (Weber & Meister, 2008).

18.6.2.1 Feature-Modellierung in MSDL Den Kern der Bildbeschreibungssprache MSDL bildet das generische Element „Feature“. Ein Feature besitzt einige wenige, feste Eigenschaften, die in Abb. 18.4 dargestellt sind. Jedes Lageobjekt wird in MSDL durch ein Feature implementiert. Es wird durch einen Identifikator („id“) und den Namen („name“) eindeutig referenzierbar. Die Eigenschaft Kontext („context“) beinhaltet alle semantischen Bezüge oder Referenzen darauf. Die Geometrie („geometry“) wird zur Georeferenzierung des Objekts in einem GML-Profil definiert. Die Attribute („attributes“) enthalten die im Schlüssel-Wert-Format abgelegte Objektsemantik, während die Stilangaben („styles“) alle notwendigen Informationen für die korrekte Visualisierung beinhalten. Einem Feature können weitere Features („features“) untergeordnet werden. In der resultierenden Baumstruktur werden beispielsweise Unterstellungsverhältnisse militärischer Einheiten implementiert. Das Feature-Element erlaubt es außerdem, abstrakte Aggregationen (Zusammenfassungen) abzubilden. So lassen sich auch semantische Zusammenhänge mehrerer Features abbilden. Eine solche Aggregation besitzt in der Regel selbst keine Geometrie. Ihr Kontext, ihre Attribute und Stilangaben werden jedoch an ihre „Kinder“ vererbt. Militärische Einheiten sind die zentralen Komponenten eines militärischen Lagebildes. Sie symbolisieren die zugehörigen real existierenden Objekte und beschreiben diese näherungsweise durch Angabe einzelner Attributwerte. Eine Einheit wird

Abb. 18.4 Feature-Modellierung in XML (erstellt mit XMLSpy)

18 Interoperabilität in der Lagebearbeitung

261

beispielsweise über ihren Namen, ihre Funktion, eine Referenz-ID, Unterstellungsverhältnisse usw. definiert. In einer Auszeichnungssprache wie MSDL werden diese Attribute in einer Schlüssel-Wert-Kombination abgelegt. Hierbei bestimmt die Herkunft der Daten die Schlüsselwörter. So wird eine ADatP-3-Meldung andere Schlüssel als eine MIP-Datenquelle erzeugen. Einige dieser Attribute sind in einer Anwendungsumgebung bekannt, andere nicht. Das MSDL-Format legt daher die Auswahl der Schlüssel nicht fest, sondern fordert lediglich, dass es sich bei dem Schlüsselnamen um ein gültiges XML-Attribut handeln muss. Entscheidend für den Austausch von Lagebildern mittels MSDL ist, dass sich Sender und Empfänger über die Semantik der einzelnen Attribute verständigen können. Zu diesem Zweck definiert MSDL eine Reihe von Namensräumen mit jeweils einer festen Liste von Schlüsseln. Sender und Empfänger müssen vor dem Austausch einen oder mehrere Namensräume und gegebenenfalls zusätzliche Attributschlüssel aushandeln. Kennt der Empfänger die Schlüssel des verwendeten Namensraums, weiß er, wie er den entsprechenden Wert zu interpretieren hat. Dies garantiert die korrekte Interpretation der Daten und ermöglicht eine maschinelle Auswertung der Lage im Sinne einer höheren „semantischen Interoperabilität“. Ein Namensraum für militärische Lageobjekte lässt sich aus der NATO-Spezifikation APP-6A (Military Symbols for Land Based Systems; NATO, 1999) ableiten. APP-6A hat sich als Standard zur Visualisierung von militärischen Lagesymbolen durchgesetzt. Ein allgemeines Austauschformat für militärische Lagen darf sich zwar nicht an einer konkreten Visualisierung orientieren, dennoch können angelehnt an die APP-6A von der Visualisierung unabhängige Schlüssel definiert werden. Hier findet sich neben Schlüsseln wie „mil:UniqueDesignation“, „mil:Size“, „mil:Affiliation“ auch eine umfangreiche Hierarchie „mil:Hierarchy“, die die Funktion bzw. die Bedeutung von Lageobjekten beschreibt. Auch Objekte wie Verfügungsräume, Verlegeoperationen etc. finden ihre Repräsentation in dieser Hierarchie. Die beschriebenen Schlüssel bilden zusammen den Namensraum „mil“. MSDL definiert ebenso einen Namensraum „milgeo“ für lagerelevante, geographische Objekte. Für den Bereich der zivil-militärischen Zusammenarbeit ist ein Namensraum „cimic“ definiert, im Bereich Katastrophenschutz/Alarmierung der Namensraum „katal“.

18.6.2.2 Kontext-Modellierung in MSDL Jedem Lageobjekt muss in MSDL ein Kontext zugeordnet werden. Das Diagramm in Abb. 18.5 zeigt den Aufbau dieses Objektkontextes als XML-Schema. Eine zentrale Aufgabe der MSDL ist es, derartige Informationen über Lageobjekte verlustfrei zu kommunizieren. Ein typischer Meldungskopf mit den entsprechenden Attributen, wie er in der Anwendung „Einsatzdatenbank Bw“ genutzt wird, wurde bereits in Abb. 18.1 dargestellt. Die Bezüge zum hier vorgestellten Objektkontext sind offensichtlich: Zentrales Konzept ist die Kategorisierung („categories“) mit referenzierten Hierarchieknoten („hierarchy“) und Schlagworten („keyword“). Referenzen („reference“)

262

J. Kaster und C. J. Weber

Abb. 18.5 Kontext-Modellierung für Lagebeschreibung in XML (erstellt mit XMLSpy)

und Links („link“) werden separat geführt, um eine größtmögliche Flexibilität zu erreichen. Die weiteren Parameter sind Standard im Meldewesen. So beinhalten „id“, „author“, „creationdate“ und „source“ administrative Informationen für die weitere Klassifizierung einer Meldung, „credibility“ und „classification“ sind notwendige Kennwerte für die Auswertesteuerung. Raum- und Zeitbezug werden in „area“ bzw. „lifetime“ gehalten. Bei einer Abfrage an eine Lagedatenbank werden die Objektkontexte mit dem Relevanzkontext der Abfrage abgeglichen. Die „qualifizierten“ Lageobjekte wer-

18 Interoperabilität in der Lagebearbeitung

263

den mitsamt ihren semantischen Bezügen im MSDL-Format an die Lagebearbeitung übertragen, so dass im Lagebild problemorientierte Auswertungen, z. B. durch Verfolgung interner und externer Verlinkungen, durchgeführt werden können.

18.6.2.3 Bisherige Erfahrungen Die vorgestellten Formalismen finden Anwendung in der Entwicklung eines prototypischen Frameworks für GIS-Anwendungen (Weber et al., 2008). Dieses Framework wurde konzipiert, um unterschiedlichste Datenquellen unter Berücksichtung des Kontextes an ein plattformunabhängiges, skalierbares, militärisches Lagedarstellungssystem anzubinden. Beispielsweise kann die Datenbank Einsatz (vgl. Kap. 9) kontextsensitive Lageobjekte über eine in dem Framework realisierte, offene Web-Service-Schnittstelle zu einem rollenorientierten Lagebild beisteuern. Ein ideales Umfeld für die Bewertung der Fähigkeit zur Interoperabilität in der Lagebearbeitung ist die von den US-Streitkräften 1993 initiierte Interoperabilitätsund Technologiedemonstration CWID (Coalition Warrior Interoperability Demonstration). Dies ist eine jährliche Großveranstaltung mit Durchführung eines weltweiten Rollenspiels für Multinational Task Forces. Übergeordnetes Ziel ist die Verbesserung der Interoperabilität alliierter Führungssysteme untereinander – basierend u. a. auf einem Common Relevant Operational Picture (CROP). Die Übung ist zeitlich auf Zyklen der NRF (NATO Response Forces) abgestimmt, um so den Systemen der assignierten Verbände die geeignete Testumgebung vor dem eigentlichen Einsatz zu bieten. Die Koordinierung der teilnehmenden deutschen Systeme obliegt IT-AmtBw A3. Bei den CWID-Übungen konnten in den Jahren 2004–2008 intensive Erfahrungen mit der Erstellung und Visualisierung kontextsensitiver Lagen – in dem in diesem Beitrag dargestellten Sinne – gesammelt und dokumentiert werden. Bei CWID 2008 wurde zudem die Struktur eines deutschen Brigade-Gefechtsstandes nachgebildet, indem fünf lageführende Systeme miteinander verbunden wurden, um symbiotisch (als System of Systems) diese Operationszentrale darzustellen. Eines dieser Systeme war der o. g. Prototyp des FKIE. In den ersten Experimenten wurden die Lagebilder für die spezifischen Rollen gemäß „intern verdrahteten“, festen Zuordnungen von Datenquellen und Lagebildern befüllt. Dies führte zu einer Vielfalt von dynamisch angepassten Lagebildern, wobei sich die Struktur der Benutzungsoberfläche am Aufbau der „Zentrale MilNW“ orientierte. Abbildung 18.6 zeigt als Muster eine Seite des in WISE (Web Information Service Environment; NATO-ACT, 2005) realisierten Zugangsportals, in dem authentifizierte Nutzern Lagebilder nach Bedarf abfragen konnten. Insgesamt war diese Art der Zuordnung allerdings zu starr, um universell verwendet zu können. Vor diesem Hintergrund wurde das Konzept des Relevanzkontextes mit dem Ziel entwickelt, eine höhere Flexibilität und Anpassbarkeit der Lagebilder zu ermöglichen.

264

J. Kaster und C. J. Weber

Abb. 18.6 Beispiel eines Zugangs zur „DVU ZMilNW“ über ein WISE-Portal. Auf der obersten Ebene erfolgt eine Unterteilung in vier Teilbereiche (Intelligence Cell, Military Situation, Geoinformation, Security). Die Startseite im Bereich Military Situation unterteilt sich weiter in Military Book, Units, History usw. Sie gibt u. a. Zugriff auf die aktuellen Eigen- und Feindmeldungen, die Lagebilder in verschiedenen AOIs (Area of Interest) sowie auf verfügbares Kartenmaterial. Das Portal ist verwendbar in einer SOA-Umgebung und hat einen über SSO (Single-Sign-On) gesicherten Zugang

18.7 Zusammenfassung Der militärische Lagebearbeiter steht einer Flut von Informationen gegenüber. Um hieraus die für ihn relevanten Daten zu extrahieren, müssen ihm geeignete Mittel an die Hand gegeben werden. Im Beitrag wurde dazu ein Konzept zur Definition kontextsensitiver Lagebilder vorgestellt. Für die Beschreibung und den Austausch solch kontextsensitiver Lagedaten wurde das Konzept der Military Situation Description Language (MSDL) entwickelt. Der Kontext militärischer Lageobjekte besteht hierbei aus ihrem Raum- und Zeitbezug, ihrer Herkunft, Qualität, internen und externen Verknüpfungen und aus ihrer thematischen Einordnung in Kategorien. Kategorien können durch Knoten einer definierten Hierarchie und durch Verschlagwortung der Meldungen abgebildet werden. Die Abbildung von Inhalten einer Datenquelle auf zugehörige Lagebilder geschieht in zwei Schritten mit Hilfe von Filter- und Aggregationsverfahren:  Eine Kontexttaxonomie beschreibt die einsatzspezifische Definition der Objektklassifizierung und wird zur Filterung von „relevanten“ Objekten aus der Datenquelle genutzt.

18 Interoperabilität in der Lagebearbeitung

265

 Mit Hilfe von Relevanzkontexten, die für einen Einsatz rollenbasiert definiert werden, lassen sich kontextsensitive Anfragen an eine Datenquelle formulieren, die in einer Aggregation von „relevanten“ Lageobjekten bestehen. Ein Lagedarstellungssystem, das Kontextinformationen in dem vorgestellten Sinne verwalten und an die Nutzerrollen dynamisch anpassen kann, erlaubt ein flexibles Zusammenstellen des Lagebildes im Sinne eines universellen „Gemeinsamen Rollenorientierten Einsatzlagebildes“. Es leistet damit einen grundsätzlichen Beitrag zu einem klareren „Situationsbewusstsein“ im Rahmen der militärischen Lagebearbeitung.

Literaturverzeichnis BMVg (2004). Konzeption der Bundeswehr. Berlin. Bundeswehr (1990). ZDv 1/11, Taktische Zeichen. Clark, T. & R. Jones, D. (1999). Organisational Interoperability Maturity Model for C2. Technical report, http://www.dodccrp.org/events/1999_CCRTS/pdf_files/track_5/049clark.pdf. EinsFüKdoBw (2002). Befehl für die Nutzung und Befüllung der Datenbanken Einsatz. Einsatzführungskommando der Bundeswehr. J2 Az 62-28-00/DBEins. Endsley, M. (1995). Toward a theory of situation awareness in dynamic systems. Human Factors, 37, 65–84. Federico, P. (1995). Expert and novice recognition of similar situations. Human Factors, 37, 105–122. Human Factors (1995). Special issue: Situation awareness. ISO (2007). ISO Standard 19136: Geographic Information. Geography Markup Language (GML). IT-AmtBw (2008). Information zum Führungsinformationssystem Streitkräfte (FüInfoSys SK). http://www.it-amtbw.de/portal/. Kaster, J., Huland, W.-D., & Huy, S. (2003). Dokumentenverwaltung in der G2-Datenbank Einsatz (v2.0). Abschlussbericht der Studie „DBEins“(IT-Amt Bw) 2003/4, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. MIP – Multilateral Interoperability Programme (2008a). MIP Home Page. http://www.mip-site. org. NATO (1994). ADatP-3 NATO Message Text Formatting System (FORMETS). NATO (1999). STANAG 2019 APP-6A (Edition 4). Military Symbols for Land Based Systems. NATO-ACT (2005). NATO C3 Technical Architecture (NC3TA), V5: NC3 Common Operating Environment (NCOE) v7.0, A2: NCOE Basket of Products – Infrastructure Services. NATOACT User Support Branch. OGC (2005b). OpenGIS Web Feature Service (WFS) Implementation Specification v 1.1.0. http:// www.opengeospatial.org/standards/wfs. OGC (2007). OpenGIS Geography Markup Language (GML) Encoding Standard v.3.2.1. http:// www.opengeospatial.org/standards/gml. SISO (2008). Military Scenario Definition Language (MSDL). SISO-STD-007-2008. Draft. Technical report, Simulation Interoperability Standards Organization (SISO). W3C (1999a). W3C XSL Transformations (XSLT) v1.0. http://www.w3.org/TR/xslt. W3C (2006). W3C Extensible Markup Language (XML) v 1.0 (Edition 4). http://www.w3.org/ XML/. Weber, C. J. & Meister, M. (2008). Military Situation Description Language (MSDL) Schema (Draft). Technical report, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg.

266

J. Kaster und C. J. Weber

Weber, C. J., Meister, M., & Marchand, Y. (2008). DIZZY - Das GIS Framework. Referenzhandbuch. (Draft). Technical report, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Widdel, H., Motz, F., Tietze, H., Grandt, M., Dalinger, E., & Sedlmayr, B. (2006). MEBS Entwicklung eines Methodeninventars zur Erfassung und Bewertung des Situationsbewusstseins bei der Lagebewertung. Technical report, FGAN.

Kapitel 19

MAJIIC – ISR-Interoperabilität für weiträumige Bodenaufklärung Wolfgang Koch, Marion Sielemann und Martin Ulmke

19.1 ISR-Aufklärungssysteme und Interoperabilität Als skalierbare, modular und flexibel angelegte „System of Systems“ müssen verteilte Führungsinformationssysteme insbesondere auch technische Aufklärungsmittel ebenenübergreifend in Entscheidungsprozesse integrieren. Der militärische Nutzen der dadurch verfügbaren Information gewinnt jedoch nicht allein durch Weiterentwicklung einzelner Sensorsysteme an Bedeutung. Entscheidend ist vielmehr die Vernetzung der Aufklärungssensorik zu umfassenden ISR-Verbundsystemen (ISR: Intelligence, Surveillance, Reconnaissance). Da räumlich verteilte Netze heterogener Sensoren eine Vielzahl einander ergänzender Aspekte eines militärischen Gesamtgeschehens erfassen, können aus den Sensordaten realzeitnahe, konsistente und vor allem hinreichend vollständige und detaillierte Lagebilder gewonnen werden, die unverzichtbare Grundlage für aufeinander abgestimmtes militärisches Handeln sind. ISR-Verbundsysteme bilden daher einen der Grundpfeiler, auf denen verteilte Führungsinformationssysteme ruhen. ISR-Verbundsysteme basieren auf hoch entwickelter Kommunikations-, Navigations- und Informationstechnologie, die im Wesentlichen bereits verfügbar ist. Aufgrund dieser Infrastruktur werden auch weiträumig verteilte Aufklärungsmittel auf stationären, verlegefähigen oder mobilen Trägerplattformen realzeitnah einer intelligenten Auswertung im ISR-Verbund zugänglich. Die konkret eingesetzten Sensoren arbeiten nach unterschiedlichen physikalischen Prinzipien und liefern eine Fülle aktueller Einzelinformationen über Position, Bewegungsverhalten, Typ oder sonstige Besonderheiten militärisch relevanter Einzelobjekte, Objektgruppen oder größerer Objektansammlungen im Luftraum, auf See oder am Boden. „Der Mensch als Sensor“ und in Datenbanken abgelegtes Kontextwissen sind weitere Informationsquellen, die mit den Sensordaten verknüpft werden müssen. Vorläufig ermittelte Teillagen wirken sich auf die Informationsgewinnung aus und sind Ausgangspunkt für optimiertes Sensormanagement und adaptive Missionsplanung mit dem Ziel, die verfügbaren Aufklärungsmittel möglichst effizient einzusetzen.

M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

267

268

W. Koch, M. Sielemann und M. Ulmke

19.1.1 Das Interoperabilitätsvorhaben MAJIIC Die NATO-Einsätze im Verlauf des Balkan-Konflikts haben deutlich gemacht, dass die Realisierung umfassender, koalitionsübergreifender ISR-Aufklärungsverbünde noch erheblicher Anstrengungen bedarf. Als Grundproblem wurde vor allem mangelhafte Interoperabilität der eingesetzten Sensor-, Kommunikations- und Auswertekomponenten identifiziert. Dies beeinträchtigte nicht nur die Interaktion unterschiedlicher ISR-Systeme der beteiligten Koalitionspartner, sondern betraf auch die Teilstreitkräfte-übergreifende Nutzung nationaler Aufklärungsmittel. Konkret verhinderten hauptsächlich Defizite hinsichtlich technischer und prozeduraler Interoperabilität, dass wesentliche Aufklärungsinformationen nicht, nicht rechtzeitig oder nur unvollständig übermittelt, ausgewertet und den im Koalitionsverbund operierenden Einsatzkräften zu Verfügung gestellt wurden. Die in der Folge durchgeführten Analysen ergaben konkrete Anforderungskataloge sowohl für einen verbesserten Zugriff auf die multisensoriellen Aufklärungssysteme, die von den Koalitionspartnern eigenverantwortlich eingesetzt und betrieben werden, als auch für die Integration dieser Systeme in vorhandene ISR-Systeme der NATO. Zu diesem Zweck sollte eine geeignete NATO-C3-Infrastruktur geschaffen werden (C3: Command, Control, and Communications). Die Aufgabe des multinationalen Technologievorhabens MAJIIC (Multi-Sensor Aerospace-Ground Joint ISR Interoperability Coalition) ist es, die angesprochenen technischen und prozeduralen Interoperabilitätsprobleme in Koalitionseinsätzen zu lösen und eine prototypische Realisierung einer ISR-adäquaten C3-Infrastruktur bereitzustellen (Janssen, 2007; Pocock, 2008). Darüber hinaus sollen die durch MAJIIC hervorgebrachten Fähigkeiten zu operationeller Interoperabilität durch gemeinsame Nutzung nationaler ISR-Systeme in Koalitionsübungen demonstriert werden. An dem Vorhaben MAJIIC beteiligen sich Deutschland, Frankreich, Großbritannien, Italien, Kanada, die Niederlande, Norwegen, Spanien und die USA.

19.1.2 Operationelle und technologische Zielsetzung Durch MAJIIC soll das Situationsbewusstsein der verschiedenen militärischen Führungsebenen durch kollaborative Nutzung interoperabler ISR-Sensor- und Auswertekapazitäten verbessert werden. Im Zentrum steht daher die Entwicklung und Demonstration so genannter Concepts of Employment (CONEMPs) und der zugehörigen militärischen Handlungsvorgaben (TTP: Tactics, Techniques, and Procedures), auf deren Grundlage technologische Hilfsmittel für Collection, Coordination, and Intelligence Requirements Management (CCIRM) konzipiert werden. Sie werden in den MAJIIC-Arbeitspaketen identifiziert, entwickelt und implementiert und unterstützen folgende Teilaufgaben, die im Rahmen von MAJIIC als zentral angesehen werden: Targeting & Target Development, Dynamic Tasking of ISR Assets, Time Sensitive Operations, Reporting & Track Management, Cross Cueing. Unter der Randbedingung, vorhandene ISR-Systemkomponenten der MAJIICPartner nicht wesentlich zu verändern, stehen folgende Aspekte im Vordergrund:

19 ISR-Interoperabilität

269

1. Die Erarbeitung von Standards zur Verteilung sensorieller Daten umfasst nicht nur die Definition und Implementierung gemeinsamer Daten- und Metadatenformate für MAJIIC-Aufklärungsmittel und -Systemarchitekturen, sondern auch Implementierungsentscheidungen und ein angemessenes Sicherheitskonzept. 2. Neben der Sensordatenauswertung im engeren Sinn werden auch Werkzeuge und Prozeduren zur Koregistrierung heterogener Sensorsysteme, für CrossCueing zwischen Sensoren innerhalb der ISR-Systeme, zwischen Sensoren verschiedener Systeme und zwischen Sensoren und Effektoren sowie zum TrackManagement, zur Darstellung des Coalition Ground Picture (CGP), zu koordinierter Missionsplanung und Tasking & Monitoring der MAJIIC-Systeme entwickelt. 3. Der Aufbau MAJIIC-spezifischer Kommunikationsnetze, einschließlich der Implementierung von Schnittstellen, Architekturen und operationellen Features, orientiert sich an kommerziell verfügbarer Internet- und Krypto-Technologie. 4. Vor allem aus operationeller Sicht sind Planung, Durchführung und Auswertung von Interoperabilitätsexperimenten sowie der Transfer der durch MAJIIC erworbenen Fähigkeiten in nationale und Koalitionssysteme besonders wichtige Ziele.

19.1.3 Funktionales Gefüge der MAJIIC-Systeme Generell ist das durch MAJIIC erarbeitete Interoperabilitätskonzept so angelegt, dass es vom Netzwerktyp und der vorhandenen Kommunikationsbandbreite weitgehend unabhängig ist. Damit ist es auf die Anforderungen unterschiedlicher militärischer Bedürfnisse adaptierbar. Im funktionalen Gefüge der MAJIIC-Systeme lassen sich folgende Gruppen unterscheiden: 1. Basierend auf individuellen Informationsanforderungen der Einsatzkräfte erstellen CCIRM-Systeme gemäß übergeordneter Prioritäten Aufklärungs- und Missionspläne und beauftragen die Sensorsysteme mit der Datenerfassung. Anschließend veranlassen sie die Auswertung der produzierten Sensordatenströme mit dem Ziel, aus ihnen die benötigten Aufklärungsinformationen zu gewinnen, und die Rückmeldung der Informationen. 2. Die MAJIIC-Sensorsysteme (einschließlich der Bodenkontrollstationen) umfassen sowohl luft- als auch bodengestützte Aufklärungssensoren. Konkret werden bei MAJIIC folgende Sensortypen eingesetzt: Bewegt-Ziel-Radar (GMTI: Ground Moving Target Indicator), Radar mit synthetischer Apertur (SAR: Synthetic Aperture Radar), elektro-optische und Infrarot-Sensoren (E/O- und IRSensorik), die Standbilder und Videos (Still & Motion Imagery) liefern, ESMSensoren (ESM: Electronic Support Measures) und Artillerieortungsradar. 3. In den unten näher erörterten Data Exploitation Systems werden die Sensordaten entsprechend dem Auftrag ausgewertet und daraus Aufklärungsinformationen generiert. Diese werden zusammen mit den ursprünglichen Anforderungen für

270

W. Koch, M. Sielemann und M. Ulmke

den Sensoreinsatz (Sensor Service Request) und den relevanten Sensordaten an das beauftragende CCIRM-System weitergeleitet. 4. Die Collaboration Tools ermöglichen sowohl Ad-hoc-Kommunikation zwischen den beteiligten Nutzern als auch den Austausch strukturierter Information. Dazu werden XML-Schemata entwickelt, die eine automatische Verarbeitung der Sensor Requests, die Anforderung der Auswerteleistung und die Weitergabe der Auswertungsergebnisse an berechtigte Nutzer ermöglichen. 5. Die zentralen Informationsverteilerknoten des MAJIIC-ISR-Verbunds bilden die Coalition Shared Database (CSD) Server, in denen sowohl die Sensordaten als auch die ausgewerteten Aufklärungsinformationen gespeichert werden. Data-Mining- und Data-Retrieval-Verfahren sind Bestandteil aller MAJIICDatenauswertesysteme und ermöglichen, in den CSD-Servern gezielt nach Daten und Informationen zu suchen, sie zu bestellen oder zu abonnieren.

19.2 Schritte zur ISR-Interoperabilität: MAJIIC in der Praxis Basierend auf grundlegenden Erfahrungen und Ergebnissen der Vorläuferaktivitäten PIE (Paris Interoperability Experiment, 1997) und CAESAR (Coalition Aerial Surveillance and Reconnaissance, 2000–2004, siehe Bond, 2003) führt MAJIIC den dort begonnenen Aufbau einer interoperablen ISR-Aufklärungsinfrastuktur weiter (Mahaffey & Skaar, 2005; Kreitmair et al., 2005). Während dem Vorhaben CAESAR für die weiträumige Bodenaufklärung ausschließlich luftgestützte GMTI- und SAR-Radarsensorik zugrunde liegen, wurde die Sensorsuite bei MAJIIC vor allem um bildgebende E/O- und IR-Sensorsysteme ergänzt. Die bereitgestellten Bilddaten sind sowohl als Einzelbilder als auch in Form von Videos auszuwerten. Außerdem unterstützt MAJIIC unterschiedliche TrackMeldungsformate, die typischerweise über taktische Datenlinks, in der Regel als Link-16-Reports realisiert, ausgetauscht werden. Auch ESM-Meldungen und Artillerieortungsergebnisse durch akustische Sensorik werden betrachtet und ebenfalls als Track-Meldungen behandelt.

19.2.1 Standardisierung der MAJIIC-Sensorprodukte Zur Gewährleistung technischer ISR-Interoperabilität wird im Rahmen von MAJIIC eine Reihe von NATO Standardization Agreements (STANAGs) umgesetzt. Umgekehrt fließen wichtige praktische Erfahrungen aus den MAJIIC-Experimenten in die Weiterentwicklung der nachfolgend aufgeführten STANAGs ein: STANAG 4607 STANAG 5516 STANAG 4545 STANAG 4609

Ground Moving Target Indicator Format (Radar) Link 16 (Air-/Ground-PPLI, Air-/Ground-Tracks) NTIF (Still Images) Video Imaging.

19 ISR-Interoperabilität

271

Abb. 19.1 Überblick über die MAJIIC-Systemarchitektur und die eingesetzten Sensortypen

Die an MAJIIC beteiligten Nationen stellen eine umfassende Palette vielfältiger Sensorsimulatoren zur Verfügung. Dadurch steht der Standardisierung der MAJIICSensorprodukte eine exzellente Ausgangsbasis zur Verfügung. Von besonderer Bedeutung für die weiträumige Bodenaufklärung sind vor allem die nachfolgend aufgeführten GMTI- und SAR-Radarsimulatoren: CAN: FRA: GBR: USA:

Coyote light armored vehicle, RADARSAT 2 COSMOS/SIDM MALE UAV, HORIZON-Helikopter Airborne Stand-Off Radar (ASTOR) Global Hawk, JSTARS, U2

Zur optischen und Infrarot-Aufklärung stehen unterschiedliche taktische UAVSimulatoren zur Verfügung. Von deutscher Seite seien Simulatoren für die Systeme LUNA (Luftgestützte Unbemannte Nahaufklärungs-Ausstattung) und das KZO (Kleinfluggerät Zielortung) hervorgehoben. Außerdem können Air-Tracks und ESMMeldungen des E3-AWACS-Systems simuliert, durch das MAJIIC-Netzwerk verteilt und zur Auswertung genutzt werden. Als Realsysteme wurden in der Übung Trial Quest 2007 als GMTI-Sensorik der französische HORIZON-Hubschrauber (Hélicoptère d’Observation Radar et d’Investigation sur Zone) und das kanadische Coyote-Aufklärungsfahrzeug genutzt, für die optische und IR-Aufklärung die fliegende deutsche Plattform OPALE, der deutsche RECCE-Tornado und das amerikanische Cyberbug UAV. Die unterschiedlichen Sensorprodukte gelangen, gegebenenfalls bereits vorausgewertet, von den jeweiligen Bodenstationen entweder über die CSD-Server oder zusätzlich über direkte UDP-Verbindungen (GMTI- und Link-16-Daten) zu den verschiedenen Auswertestationen, die von den beteiligten Nationen jeweils in eigener Verantwortung entwickelt werden. Die je nach konkretem Auftrag der Station gewonnenen Auswerteergebnisse werden in Form formatierter Textmeldungen an die

272

W. Koch, M. Sielemann und M. Ulmke

nächst höhere militärische Hierarchieebene gemeldet. Alle Sensor- und Auswerteprodukte sind standardisiert und durch die CSD-Server für jeden Teilnehmer im MAJIIC-Netzwerk abrufbar.

19.2.2 Zur deutschen MAJIIC-Auswertestation IIES Ein wesentlicher deutscher Beitrag zu MAJIIC ist der Aufbau der ISR-Auswertestation IIES (Interoperable ISR Exploitation Station). Aufgabe der IIES ist es, alle im Rahmen von MAJIIC unterstützten Sensor- und Auswerteprodukte geeignet zu fusionieren, sie weiter zu verarbeiten und dem Auswerter mit Hilfe geeigneter Benutzerschnittstellen für eine weitere Auswertung verfügbar zu machen. Dabei werden insbesondere die oben erwähnten NATO-Standards unterstützt. Die folgenden MAJIIC-Funktionalitäten seien betont:  Die Auswertestation stellt Collaborative Tools für Messaging, Chat und Group Chat zur Verfügung und unterstützt die Erstellung des Collection and Exploitation Plan (CXP) durch die graphische Darstellung der jeweiligen Areas of Interest und die Anzeige der zugrunde liegenden Information Requests.  Alle Sensordaten und vorausgewerteten Sensorprodukte können georeferenziert und zeitgeordnet, online oder offline in einer Kartendarstellung bereitgestellt werden. So genannte History-Darstellungen und zeitliches Verschieben der Plattform- und GMTI-Sensordaten sind ebenfalls möglich. Die Kartendarstellung unterstützt verschiedene Raster- und Vektorkartenformate.  Vollständig integriert in die IIES ist als wesentliche Auswertungskomponente der vom FKIE entwickelte Multisensor-Multihypothesen-Tracker, der eine robuste und realzeitfähige Verfolgung einer Vielzahl bewegter Zielobjekte ermöglicht (Koller & Ulmke, 2007; Koch et al., 2006; Koch, 2004). Der Tracker wird von der IIES-Oberfläche aus gestartet und konfiguriert. Die produzierten Tracks werden in der Kartendarstellung visualisiert, können interaktiv ausgewählt und gegebenenfalls manuell oder automatisch als Link-16-Meldung im MAJIIC-Netzwerk verteilt werden. Der Multisensor-Multihypothesen-Tracker erlaubt insbesondere die zentrale Fusion mehrerer Missionen unterschiedlicher GMTI-Sensorplattformen. Auch hier ist sowohl Online-Verarbeitung unmittelbar während einer Übung oder eines Einsatzes möglich als auch eine spätere Offline-Analyse der Daten. Die produzierten Tracks werden aus den GMTI-Radardaten vollautomatisch extrahiert und beim Eingang neuer Daten automatisch nachgeführt. Das Multihypothesen-Verfahren erlaubt die Anwendung auf Situationen mit hohen Falschalarmraten durch Radar-Restclutter und geringen Detektionswahrscheinlichkeiten. Es können weiträumige Szenarien mit einer großen Anzahl von Sensormeldungen und Tracks in Realzeit verarbeitet werden. Die Verarbeitung von Doppler-Messungen ist ebenso implementiert wie die prototypische Integration digitaler Straßenkarten zur Verbesserung der Trackqualität und Trackkontinuität.

19 ISR-Interoperabilität

273

19.2.3 Erfahrungen aus Interoperabilitätsübungen Ausgehend von dem CAESAR Technical Integration Experiment (TIE 2005) wurden im Rahmen von MAJIIC seit 2005 drei simulierte Übungen (SIMEX 2006, MAJEX 2007 und MAJEX 2008) sowie eine Realübung Trial Quest 2007 durchgeführt. Die ISR-Demonstration Trial Quest war Bestandteil der NATO-Übung Bold Avenger, die vom 3.–14. September 2007 in Norwegen stattfand. Ziel der Übungen ist es, die im Rahmen von MAJIIC entwickelten technischen, architektonischen und operationellen Konzepte und Verfahren in einer Umgebung zu testen und zu evaluieren, die den operationellen Verhältnissen möglichst nahe kommt. Dazu finden zunächst umfangreiche technische Tests im Hinblick auf Kompatibilität und Interoperabilität der verschiedenen von den Nationen eingebrachten Sensor- und Auswertestationen statt. Nach der Einweisung des militärischen Auswertepersonals in die Bedienung der jeweiligen ISR-Systeme werden dann in einem simulierten oder real durchgespielten Übungsszenario die Datenauswerte- und Kommunikationstools einer eingehenden Prüfung unterzogen. Die Bewertung der aufgebauten MAJIIC-Systeme durch die militärischen Auswerter und ihre Erfahrungsberichte liefern unverzichtbare Hinweise für die Verbesserung und Weiterentwicklung der an MAJIIC beteiligten Systeme und Verfahren. Die MAJIIC-Fähigkeitsentwicklung durch ein Gefüge von Übungen im Sinne eines CD&E-Prozesses ist schematisch in Abb. 19.2 dargestellt.

19.2.3.1 Live-Experiment „Trial Quest 2007“ Von besonderem Wert für das MAJIIC-Vorhaben war vor allem die Realübung Trial Quest 2007, die an zwei Standorten stattfand. An der militärischen Rahmenübung Bold Avenger nahmen etwa 1500 Personen sowie mehr als 100 Flugzeuge (Tank-, Kampf-, Aufklärungsflugzeuge) aus 13 NATO-Nationen teil. Die Luftoperationen wurden überwiegend in Ørland, die Bodenoperationen um Rena durchgeführt. An beiden Standorten und in Gardermoen waren ISR-Plattformen stationiert. Dabei handelt es sich um das OPALE-Aufklärungsflugzeug mit Videound IR-Sensorik, zwei RECCE-Tornados, das Cyberbug-UAV sowie das kanadische COYOTE-System und den französischen HORIZON-Helikopter, die beide mit GMTI-Radar ausgerüstet waren. Die ISR-Auswertestationen befanden sich

Abb. 19.2 Prozess der MAJIIC-Fähigkeitsentwicklung durch ein Gefüge von Übungen

274

W. Koch, M. Sielemann und M. Ulmke

auf dem Luftwaffenstützpunkt in Ørland. Im Rahmen der Übung konnte die ISRInteroperabilität im MAJIIC-Netzwerk und ein Sortiment effizienter Auswertetools erfolgreich demonstriert werden. Die GMTI-Daten wurden in Realzeit getrackt; die über taktische Linkverbindungen verteilten Trackergebnisse wurden direkt für das Time Sensitive Targeting eingesetzt. Auch hier lieferte die operative Anwendung wertvolle Hinweise, die vor allem zu einer Verbesserung des Trackmanagements und der Trackeindeutigkeit bei mehreren Auswertestationen geführt haben.

19.2.3.2 CWID: Coalition Warrior Interoperability Demonstration Während bei MAJIIC in erster Linie die technische Interoperabilität innerhalb des ISR-Verbunds im Vordergrund steht, zielt die technische Demonstration CWID (Coalition Warrior Interoperability Demonstration) vorwiegend auf die Interoperabilität alliierter Führungsinformationssysteme untereinander (C2: Command & Control) und mit ISR-Aufklärungsverbünden. In der Vergangenheit wurden bereits mehrfach ausgewählte MAJIIC-Komponenten auch in CWID-Übungen verwendet, vor allem für die Verteilung von ISR-Aufklärungsdaten. Darüber wesentlich hinausgehend wurde in den CWID-Übungen 2007 und 2008 das Zusammenspiel eines C2-Systems mit der MAJIIC-Auswertestation IIES auf Grundlage eines vergleichsweise überschaubaren Szenarios durchgespielt. Als Modell einer Aufklärungszentrale diente das vom FKIE entwickelte CliCC-System (Collaboration in Command & Control).1 Die ebenfalls vom FKIE realisierte Simulation umfasste ein Evakuierungsszenario mit einem Flüchtlings-Konvoi und sonstigem Straßenverkehr, eine luftgestützte Aufklärungsplattform mit GMTI-Radarsensorik und anschließendem Multihypo-

Abb. 19.3 Architekturschema zur Integration der MAJIIC-Station IIES in CWID 1

CliCC ist synonym für die DVU ZMilNW, die in Kap. 10.3 vorgestellt wird. Vgl. auch (Kaster, 2004b).

19 ISR-Interoperabilität

275

thesen-Tracking der GMTI-Radardaten. Die Auswertezelle wurde von der Intelligence Cell über ein Request for Information beauftragt, die Auswerteergebnisse (vor allem Tracks) wurden zum einen über einen Web-Service im XML-Format für das CliCC-System verfügbar gemacht, zum anderen über einen Datenlink an das LINSE-System (IBM) gesandt. Auf andere Produkte, insbesondere Bilddaten (z. B. Screenshots), konnte über die MAJIIC-eigene Coalition Shared Database (CSD) zugegriffen werden. Die Produkte der Auswertestation wurden unmittelbar in die Lagedarstellung des CliCC-Systems umgesetzt. Abb. 19.3 veranschaulicht die Integration der MAJIIC-Auswertestation IIES in CWID.

19.3 Entscheidungsunterstützung durch MAJIIC-Systeme Die Datenströme des interoperablen MAJIIC-ISR-Verbunds dürfen die Entscheidungsträger nicht überwältigen. Um als Entscheidungsunterstützung auf den beteiligten Hierarchieebenen dienlich zu sein, müssen die Daten vielmehr zu hochwertigen Auswerteergebnissen verdichtet werden, aus denen realzeitnahe Lagebilder eines sich dynamisch entwickelnden Bodengeschehens aufgebaut werden. Die auszuwertenden Sensordaten sind jedoch in der Regel ungenau, unvollständig, mehrdeutig oder nicht auflösbar. Die Messdaten können falsch oder durch gegnerische Maßnahmen verfälscht sein. Darüber hinaus ist zu integrierende Kontextinformation in der Regel nur schwer formalisierbar. Die angesprochenen Defizite sind in der Regel unvermeidlich. Die Extraktion von Lageinformation ist daher keineswegs trivial, sondern bedarf einer anspruchsvollen wissenschaftlichen Methodik, der Multisensordatenfusion (Liggins et al., 2008; Koch, 2007). Datenfusion ist ein raum-zeitlicher Prozess der Informationsverarbeitung, in dem insbesondere logische Querbezüge sowie inhärente Komplementarität und Redundanz ausgenutzt werden, um im Rahmen eines statistischen Ansatzes relevante Zielzustandsgrößen zu schätzen. Sensorbasierte Entscheidungsunterstützung ist vor allem in zeitkritischen Situationen oder Situationen mit hohem Entscheidungsrisiko wichtig, in denen charakteristische menschliche Defizite durch automatisch oder interaktiv arbeitende Auswerte-Tools ausgeglichen werden können (Kompensation abnehmender Aufmerksamkeit in Routinesituationen, Fokussierung der Aufmerksamkeit auf anomale oder seltene Ereignisse, Unterstützung begrenzter Gedächtnis-, Reaktions- oder Kombinationsfähigkeiten). Neben den Vorteilen, die sich aus der Reduktion der Arbeitslast bei Routine- oder Massenaufgaben ergeben, erschließen die automatisierten MAJIIC-Auswerte-Tools durch Fusion komplementärer Daten Information, die nur auf diese Weise zugänglich ist.

276

W. Koch, M. Sielemann und M. Ulmke

19.3.1 Tracking als grundlegende Auswertefunktionalität Tracking-Algorithmen fusionieren Sensordaten, die zu verschiedenen Zeitpunkten erfasst wurden. Da bei MAJIIC vor allem dynamische Bodenszenarien aufzuklären sind, besitzen unter den MAJIIC-Auswerteprodukten Ziel-Tracks eine besondere Bedeutung. Sie repräsentieren aktuell verfügbares Wissen über relevante, zeitvariable Größen, die den augenblicklichen Zustand individueller Ziele oder Zielgruppen kennzeichnen. Durch Tracking wird auch die Zustandshistorie zugänglich. Soweit wie möglich soll eine eindeutige Zuordnung zwischen den tatsächlich vorhandenen Zielen im Erfassungsbereich der Aufklärungssensoren und den Tracks etabliert und solange wie möglich bewahrt bleiben (Track-Kontinuität). Die erzielbare TrackQualität hängt nicht nur von der Performance der eingesetzten Aufklärungsmittel ab, sondern auch von Zieleigenschaften, Einsatzbedingungen im jeweils aufzuklärenden Szenario und verfügbaren Kommunikationsbandbreiten. Primär schätzen Tracking-Verfahren kinematische Zieleigenschaften wie Position, Geschwindigkeit über Grund oder Beschleunigung. In anderen Worten, StandardTracking-Anwendungen gewinnen „JDL-Level-1“-Information gemäß der etablierten Terminologie des so genannten „JDL-Modells der Informationsfusion“ (siehe Liggins et al. 2008, Kapitel 2, und die dort zitierte Literatur). Kinematische Daten dieser Art sind jedoch bei weitem nicht die einzigen Informationen, die aus Ziel-Tracks zu extrahieren sind. In vielen Fällen kann verlässliche und qualitativ hochwertige Information im Sinne der JDL-Terminologie gewonnen werden.

19.3.2 Beispiele für höherwertige MAJIIC-Lageinformation Die erste Klasse hochwertiger Information, die auf der Basis von Tracks erschlossen werden kann, beruht auf einer Analyse der Track-Historie, also der zeitlichen Folge der Zielzustandsschätzungen. Die dadurch abgeleiteten Aussagen beziehen sich typischerweise auf Objekteigenschaften, die entweder zeitinvariant sind oder sich auf einer größeren Zeitskala als die kinematischen Eigenschaften ändern.  Geschwindigkeitshistorie. Die Analyse präzise rekonstruierter Geschwindigkeitshistorien kann zur Zielklassifikation beitragen. Wenn die mit hinreichender Genauigkeit geschätzte Geschwindigkeit bestimmte Schwellen über- oder unterschreitet, sind bestimmte Zielklassen verlässlich auszuschließen, etwa wenn bei der Alternative Hubschrauber oder Starrflügler die Geschwindigkeitshistorie eine Bahngeschwindigkeit „Null“ aufweist.  Beschleunigungshistorie. Ähnliche Überlegungen gelten für Beschleunigungshistorien. So geben etwa hohe Querbeschleunigungen Hinweise auf ein Kampfflugzeug. Darüber hinaus kann man sicher schließen, dass Kampfflugzeuge, die mit hohen Querbeschleunigungen beobachtet wurden, nicht (mehr) über eine bestimmte Bewaffnung verfügen. Die Analyse kinematischer Tracks ermöglicht also Aussagen über den Bedrohungsgrad bestimmter Zielobjekte.

19 ISR-Interoperabilität

277

 Kurs, Aspektwinkel. Präzise Zielkursschätzungen sind nicht nur wichtiger Input für Waffeneinsatzsysteme, sondern liefern auch zu bestimmten Zeiten den Aspektwinkel eines Objekts bezüglich anderer Sensoren, etwa solcher, die hochauflösende Entfernungs- oder Doppler-Spektren produzieren. Sie sind fundamental für die Fusion zeitversetzter Spektren und tragen dadurch zur Zielklassifikation oder gar -identifikation bei. Eine zweite Klasse von Higher-JDL-Level-Information bezieht sich auf Interobjektrelationen und kann durch Multiobjekt-Tracking gewonnen werden:  Gemeinsame Historie. Durch Multiobjekt-Tracking kann man feststellen, ob Ziele einer Zielgruppe angehören (z. B. Formation, Fahrzeugkonvoi). Auch wenn sich etwa eine Formation nach einer Phase der Penetration auflöst, bleibt die Interrelation zwischen den Einzelzielen erhalten und ist eine wertvolle Information, wenn sich z. B. eines der Ziele als feindlich erweist. Offenbar sind dann auch alle anderen Ziele der früheren Formation als feindlich anzusehen.  Zielquellen und -senken. Die Analyse einer großen Anzahl von Ziel-Tracks kann Quellen und Senken von Strömen bewegter Ziele erkennen. Auf diesem Wege sind gewisse Areale etwa als Flughäfen oder als Gebiete zu identifizieren, in denen sich militärische Kräfte konzentrieren. In Verbindung mit Kontextinformation liefert eine derartige Track-Analyse auch Beiträge zur Zielklassifikation (Classification by Origin/Destination).  Evaluierung von Split-off-Ereignissen. Ebenfalls durch Multiobjekt-Tracking werden gewisse Split-off-Ereignisse als Missile-Launch von diesem Objekt aus interpretierbar. Derartige Ereignisse haben nicht nur Auswirkungen auf die Klassifikation etwa als Kampfflugzeug, sondern ermöglichen eine Art „Buchhaltung“. So kann etwa durch Zählen der Launches die verbleibende Feuerkraft abgeschätzt werden mit direkten Implikationen für potentielle Gegenmaßnahmen. Eine dritte Klasse von Schlussfolgerungen aus JDL-Level-1-Information zielt auf charakteristische Zieleigenschaften.  Erkennung von Fahrzeug-Stops. Bei GMTI-Radar kann man das Phänomen der Doppler-Blindheit nutzen, um zu erkennen, ob ein Ziel anhält, vorausgesetzt dies wird durch geeignete Sensormodelle beschrieben (Koch, 2004). Wenn das Ziel ein Missile-Launcher ist, deuten die ausfallenden Daten möglicherweise auf die Vorbereitung eines Abschusses hin, woraus sich unmittelbar Konsequenzen für weitere Maßnahmen ergeben (SAR-Bild, Bekämpfung). In Verbindung mit anderen Tracks kann ein anhaltendes Ziel auch neue Objektinterrelationen etablieren, wenn etwa ein Ziel auf ein anderes wartet und dann beide gemeinsam weiterfahren.  Off- und On-Road-Ziele. In Bodenszenarien sind meist digitale Straßenkarten verfügbar (Ulmke & Koch, 2006). Dies ermöglicht insbesondere, die Hypothese „Off-road-Ziel“ gegen „On-road-Ziel“ zu testen und umgekehrt. Offensichtlich ist ein Ergebnis wie „On-road-Ziel bewegt sich ab jetzt off-road“ hochwertige Information mit Implikationen für den Fahrzeugtyp und mögliche Absichten. Ferner können präzise und aktuelle Straßenkarten, d. h. Higher-Level-

278

W. Koch, M. Sielemann und M. Ulmke

Kontextinformation, durch Analyse von Straßenzielen gewonnen werden (Koch et al., 2006).  Detektion seltener Ereignisse. Schließlich ist die Analyse von JDL-Level-1Tracks der Schlüssel zur Detektion seltener oder anomaler Ereignisse, indem Tracks mit Kontextinformation wie annotierten digitalen Karten und allgemeinen Verhaltensregeln fusioniert werden. Ein einfaches Beispiel ist die Produktion einer Alarmmeldung, wenn ein Lastwagen zu einer unüblichen Zeit auf einem Waldweg in Grenznähe beobachtet wird.

Literaturverzeichnis Bond, S. J. (2003). Coalition Aerial Surveillance and Reconnaissance: the CAESAR project. Military Intelligence Professional Bulletin, (January–March). Janssen, J. (2007). NATO Live Flying Trial To Enhance Coalition Intelligence Interoperability – NATO’s Majiic project aims to prevent data and exploitation bottlenecks. Aviation Week & Space Technology, (September), 60ff. Kaster, J. (2004b). Multinational Intelligence Center – Integrated Services for Situation Assessment. Technischer Bericht 2004/4, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Koch, W. (2004). Ground Target Tracking with STAP Radar: Selected Tracking Aspects. In R. Klemm (Ed.), The Applications of Space-Time Adaptive Processing chapter 15. IEE Publishers. Koch, W. (2007). Sensor Data Fusion: Methods, Applications, Examples. In E. Lefebvre (Ed.), Advances and Challenges in Multisensor Data and Information Processing, NATO Security through Science Series. IOS Press. Koch, W., Koller, J., & Ulmke, M. (2006). Ground Target Tracking and Road Map Extraction. ISPRS Journal on Photogrammetry & Remote Sensing, (61), 197–208. Koller, J. & Ulmke, M. (2007). Data fusion for ground moving target tracking. Aerospace Science and Technology, (11), 261–270. Kreitmair, T., Ross, J., & Skaar, T. (2005). Experimentation Activities with Aerospace Ground Surveillance. In Proceedings of the Command and Control Research and Technology Symposium (CCRTS): U.S. DoD, CCRP. Paper 23. Liggins, M. E., Llinas, J., & Hall, D. L. (2008). Handbook of Multisensor Data Fusion: Theory and Practice. CRC Press, 2nd edition. Mahaffey, J. & Skaar, T. (2005). Observations on the Dissemination of ISR Data Employing Network-Enabled Capabilities in the Coalition Environment. In Proceedings of the Command and Control Research and Technology Symposium (CCRTS): U.S. DoD, CCRP. Paper 129. Pocock, C. (2008). MAJIIC data – NATO intelligence repositories could solve access woes. C4 ISR Journal – The Magazine for Net-centric Warfare, (November). Ulmke, M. & Koch, W. (2006). Road-Map Assisted Ground Moving Target Tracking. IEEE Transactions on Aerospace and Electronic Systems (T-AES), 42(4), 1264–1274.

Kapitel 20

Sichere Kommunikation in heterogenen militärischen Netzen Thorsten Aurisch, Peter Sevenich und Jens Tölle

20.1 Einleitung Eine der wesentlichen Herausforderungen beim Einsatz militärischer Systeme ist die Gewährleistung einer robusten und sicheren Kommunikation der einzelnen Geräte sowohl untereinander in taktischen Netzen als auch mit strategischen Netzen. Robustheit und Sicherheit sind Anforderungen, die im Rahmen der Netzwerkarchitektur eine hohe Priorität haben müssen. Einerseits ist sichere Kommunikation wertlos, wenn die Kommunikationsverbindungen die notwendige Robustheit und Zuverlässigkeit vermissen lassen und damit unter Umständen selbst elementare Kommunikationsanforderungen im Einsatz nicht erfüllt werden können. Andererseits ist eine einseitige Fokussierung auf die Robustheit des Kommunikationsnetzes kritisch, wenn elementare Sicherheitsanforderungen wie zum Beispiel die Vertraulichkeit oder die Integrität der übertragenen Nachrichten nicht sichergestellt werden können. Sicherheit und Robustheit militärischer Kommunikation müssen immer zusammen betrachtet werden. Dieses Kapitel widmet sich beiden Aspekten unter dem Blickwinkel der Kommunikation mit dem Internet-Protokoll IP.

20.2 Herausforderungen Die Absicherung militärischer Kommunikation stellt insbesondere im taktischen Umfeld große Herausforderungen an die eingesetzten Verfahren und Protokolle. Für die meisten Schutzziele gibt es zwar seit vielen Jahren geeignete und allgemein anerkannte Verfahren, jedoch bietet das taktische Umfeld besondere Herausforderungen. Eine übliche Annahme bei der alltäglichen Kommunikation im Internet ist, dass sowohl eine annähernd bitfehlerfreie Übertragung stattfindet als auch typischerweise ausreichend Bandbreite zur Verfügung steht. Insbesondere der letzte Punkt M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

279

280

T. Aurisch, P. Sevenich und J. Tölle

zeigt sich darin, dass auch bei der Internet-Übertragung von Video- und AudioDatenströmen an viele Empfänger sehr häufig jeder Empfänger mit einem eigenen Datenstrom versorgt wird. Das taktische Umfeld bietet im Gegensatz dazu deutlich ungünstigere Rahmenbedingungen. In taktischen Netzen muss aufgrund der Mobilitätsanforderungen häufig auf Funkübertragung zurückgegriffen werden. Bei der klassischen Internet-Kommunikation wird beispielsweise mit WLAN bei der Vernetzung über Accesspoints sowohl im kommerziellen Umfeld als auch bei privaten Internetanschlüssen ein Funknetz eingesetzt. Dies erfolgt allerdings nur über kurze Strecken und mit hohen Datenraten, so dass erkannte Bitfehler durch Paketwiederholung problemlos behoben werden können. Beim taktischen Einsatz von HF-Verbindungen oder auch in mobilen Ad-hoc-Netzen ist das oftmals nicht möglich (Sevenich et al., 2007). Hier sind die großen Herausforderungen eine erhöhte Bitfehlerrate und eine geringere zur Verfügung stehende Datenrate. Die Übertragungsfehlerwahrscheinlichkeit wird außerdem erhöht, weil in Ad-hoc-Netzen durch Veränderung der Positionen der Relayknoten zueinander Routingänderungen und Verbindungsabbrüche auftreten können, die sich durch Reihenfolgevertauschungen und insbesondere Paketverluste äußern können. Zur effizienten Nutzung geringer zur Verfügung stehender Datenraten bietet sich daher die Nutzung von Multicast-Übertragungstechnik an. Diese erfordert jedoch Anpassungen und Erweiterungen der eingesetzten Sicherheitsprotokolle. An einem konkreten Beispiel lassen sich viele der Herausforderungen moderner militärischer Kommunikation gut veranschaulichen. Die folgenden Abschnitte stellen die aktuellen Konzepte zur Vernetzung heutiger und zukünftiger heterogener militärischer Netze am Beispiel des INSC-Projektes (Interoperable Networks for Secure Communications) dar. Dazu gehören auch die Darstellung von Sicherheitsherausforderungen sowie die Darstellung geeigneter Lösungskonzepte.

20.3 Sichere Koalitionsnetze am Beispiel INSC Das Memorandum of Understanding (MoU) Interoperable Networks for Secure Communications (INSC) wurde im Feb. 2001 von den NATO-Staaten Kanada, Vereinigte Staaten von Amerika, Frankreich, Deutschland, Großbritannien, Norwegen, die Niederlande und Italien für 5 Jahre ratifiziert. Die Phase I des MoU wurde Anfang 2004 abgeschlossen. Mit einem Amendment zum MoU wurde dieses mit einer weiterführenden, auf Phase I aufbauenden Aufgabenbeschreibung, bis Feb. 2007 unter der Bezeichnung INSC Phase II, verlängert. Die Arbeiten werden seit Beginn 2008 unter dem Namen CoNSIS (Coalition Networks for Secure Information Sharing) weitergeführt. Ziel von INSC Phase I und II war es, eine transparente Netzwerkarchitektur auf Basis von IPv6-Technologie (Goode, 2006) zu schaffen, die einen barrierefreien (seamless) und sicheren Informationsaustausch zwischen allen Hierarchieebenen

20 Kommunikation in verteilten FüInfoSys

281

(vertikaler Ansatz1 ) und mit Koalitionspartnern (horizontaler Ansatz) in der militärischen Kommunikation ermöglicht und somit eine verlässliche und sichere Infrastruktur als Basis moderner Führungsinformationssysteme bietet. Zu diesem Zweck wurde auf der Basis von militärischen Szenarien eine Systemarchitektur entwickelt, die aus einer strategischen, operationellen und taktischen Ebene besteht. Aufgrund der Modularität der INSC-Systemarchitektur kann diese an neue Rahmenbedingungen einfach und schnell angepasst und damit für neue Koalitionen szenarspezifisch zusammengestellt werden (Goode et al., 2006).

20.4 Die Struktur eines sicheren Netzes Im INSC-Projekt wurde ein multinationales, durchgehend IPv6-fähiges Test- und Demonstrationsnetz aufgebaut, das aus einem schwarzen2 Transportnetz (z. B. nationale Internet Service Provider (ISPs), mil. SATCOM, HF-Funk) und verteilten, roten Zugangsnetzen besteht. Letztere stellen die nationalen Coalition LANs (CLAN) dar, die mittels IPsec abgesichert werden. CLANs (z. B. Führungsgefechtsstände) können hierbei sowohl auf klassische Weise bzw. ortsgebunden als auch hochmobil mittels neuer Technologien realisiert sein, die für zukünftige, mobile, taktische Netze (z. B. mobile Ad-Hoc Netze (MANET)) vorgeschlagen werden. Statt CLAN hat sich mittlerweile auch die Bezeichnung Red Domain eingebürgert, da dadurch ausgedrückt wird, dass auch nationale Teilnetze, die nicht Bestandteil des Koalitionsnetzes sind, entsprechend an der Vernetzung beteiligt sein können. Alle Untersuchungen, die im Rahmen von INSC in den beteiligten Nationen vorgenommen wurden, wurden in diesem IPv6 Test- und Demonstrationsnetz, basierend auf verschiedenen ISPs und militärischen Übertragungsstrecken, unmittelbar implementiert und erprobt. Zur Verwaltung eines solchen Netzverbundes wurden Mittel geschaffen, die es erlauben, einerseits die eigenen nationalen Ressourcen autonom zu verwalten und andererseits im Verbund Kenntnisse über die Ressourcenverfügbarkeit auch von Koalitionspartnern zu erhalten. Besonderer Wert wurde bei der Durchführung des Projektes auf den aktuellen nationalen wie internationalen Wissenstransfer von Erkenntnissen und Ergebnissen aus dem INSC-Projekt schon während der Laufzeit gelegt.

20.5 Einbindung von INSC in weitere Aktivitäten Beispiele für den Wissenstransfer aus dem INSC-Projekt hinein in andere Projekte/Aktivitäten und Produktentwicklungen sind: 1

z. B. zwischen dem Einsatzführungskommando der Bundeswehr in Potsdam, einem Führungsgefechtsstand im Einsatzland und einzelnen Soldaten auf dem Gefechtsfeld 2 In der Kommunikationswelt ist es üblich, ungeschützte Netzelemente als schwarz und geschützte Netzelemente als rot zu bezeichnen.

282

T. Aurisch, P. Sevenich und J. Tölle

 STANAG 4591, 4622, 4644, 5067, 5524 (siehe Abschn. 20.9.4).  NNEC FS: INSC hat die wesentliche Architekturgrundlage für die Feasibility Study geliefert, insbesondere hinsichtlich Netzwerktransparenz und Sicherheitskonzept im Netzwerk.  IPv4/v6 Migration Bw: Die vorgeschlagenen Maßnahmen zur Migration IPv4 nach IPv6 stammen aus dem Projekt INSC und wurden dort verifiziert.  MobKommSysBw: Die technische Realisierungsmöglichkeit wurde innerhalb von INSC verifiziert (CLAN-Konzept und Black-Core-Network).  KMobKommH: Die Forderungslage des Konzepts baut auf den Mobiluntersuchungen aus INSC auf.  TACOMS (exkl. IPsec): Der IP-Anteil aus TACOMS beruht auf der INSCArchitektur, der IPv6-Bezug aus INSC wird als Grundlage für eine Phase 2 von TACOMS angesehen.  Konzept IT-Sicherheit im IT-System der Bundeswehr: Die Sicherheitsarchitektur aus INSC wurde vollständig in das neue Sicherheitskonzept übernommen.  NetOpFü für Legacy-Funksysteme: Die prototypische Realisierung des IP-Adapters für die VHF-FuGerFam SEM 70/80/90 (HMTI) wurde innerhalb von INSC implementiert.  Prototyp IPv6-fähige SINA-Box: FF BSI; der IPv6-Teil der SINA-Box wurde innerhalb von INSC realisiert.  Taktisches X.400: Die protokolltechnischen Erweiterungen, insbesondere P_MUL, zur Verwendung von X.400 in Funksystemen wurde innerhalb von INSC implementiert.  SVFuA: INSC hat einen Ansatz für eine Breitbandwellenform zur Realisierung von MANETs bereitgestellt. Um die Vielzahl der Aufgaben im Rahmen von INSC innerhalb einer kurzen Projektlaufzeit realisieren zu können, hat INSC grundsätzlich auf verfügbaren offenen Standards und damit zugänglichen offenen Implementierungen aufgesetzt, um langwierige Spezifikations- und Implementierungszeiten zu vermeiden.

20.6 Untersuchte Technologien INSC hat signifikante technische Ansätze von Netzwerktechnologien untersucht und weiterentwickelt, die eine Verbesserung der operationellen Fähigkeiten versprechen. Eine der wesentlichen Zielsetzungen war es hierbei zu untersuchen, inwieweit eine auf IPv6 basierende Netzwerktechnologie besser geeignet ist, militärische Anforderungen an ein transparentes Internetzwerk für Koalitionseinsätze zu unterstützen, als das bisher zivil genutzte IPv4. Zur Nachweisführung und um keine technologischen Inseln entstehen zu lassen, war es erforderlich, die notwendigen Übergangsfunktionen zwischen IPv4 und IPv6 zu realisieren und zu testen. Im Folgenden sind die wichtigsten Technologien und Vorgehensweisen aus dem Projekt als eine Art Katalog von Modulen für das Design moderner sicherer Koalitionsnetze zusammengefasst.

20 Kommunikation in verteilten FüInfoSys

283

20.6.1 Migration von IPv4 nach IPv6 Es ist davon auszugehen, dass eine Migration von den heutigen IPv4-basierten Netzen hin zu IPv6-Netzen nicht in einem Schritt und insbesondere nicht homogen in allen Nationen vollzogen werden kann, sondern einen länger dauernden Übergangsprozess mit sich bringen wird. Darüber hinaus gibt es Fälle, die keine Umstellung verlangen oder gar zulassen (z. B. bei Software, die aus organisatorischen oder technischen Gründen nicht mehr angepasst werden kann). Aus diesem Grund wurden unterschiedliche Migrationsansätze entwickelt und untersucht. Die drei Grundtypen umfassen: Dual Stack: Der IP-Stack unterstützt sowohl IPv4 als auch IPv6 und kann daher IPv4- und IPv6-Anwendungen simultan bedienen. Der größte Vorteil hierbei ist die Rückwärtskompatibilität und die Möglichkeit einer schrittweisen Migration. Voraussetzung hierfür ist, dass Dual Stack vom Betriebssystem und zumindest vom jeweiligen Access-Netz unterstützt wird. Tunneling: Hierbei wird wahlweise IPv4-Verkehr in IPv6 oder IPv6-Verkehr in IPv4 gekapselt (vgl. IP-over-IP-Tunneling). Tunnelendpunkte können sowohl auf dedizierten Gateways als auch direkt auf den Endgeräten platziert werden. Vorteil hierbei ist die einfache schrittweise Migration und die Unterstützung von legacy Anwendungen. Außerdem bestehen keine weiteren Anforderungen an das Übertragungsnetz. Einzige Voraussetzung ist der Tunneling-Support im entsprechenden Endgerät bzw. Gateway. Translation: Für diese Methodik gibt es verschiedene Ansätze hinsichtlich der Platzierung und Umsetzung, z. B.  im IP-Stack ! Bump in the wire,  in der Anwendungsschicht ! Bump in the API,  als eigene Anwendung ! NAT-PT-Proxy (Network Address Translation – Protocol Translation). Allen drei Ansätzen ist gemein, dass eine Übersetzung des Netzverkehrs vorgenommen wird. Diese Übersetzung kann jedoch nicht einheitlich für alle Verbindungen bzw. Anwendungen durchgeführt werden, da neben dem IP-Header u. U. auch höhere Protokollschichten mit betrachtet oder gar angepasst werden müssen (z. B. das File Transfer Protocol). Diese Migrationsansätze sind in Abhängigkeit des jeweiligen Einsatzfalles unterschiedlich gut geeignet und einsatzfähig. Im Rahmen von INSC wurde zum einen in einer theoretischen Analyse die Eignung der jeweiligen Methoden in den verschiedenen relevanten Szenarien und Architekturen untersucht. Zum anderen wurden aber auch vorhandene Implementierungen dieser Ansätze praktisch evaluiert und getestet. Prinzipiell ist festzustellen, dass die zwei Varianten Dual Stack und Tunneling einfach und ohne großen Aufwand nachträglich in eine bestehende Infrastruktur eingebracht werden können. Translation hingegen ist nur bedingt einsetzbar, da diese sehr stark von den eingesetzten Plattformen, Betriebssystemen und Anwendungen abhängt.

284

T. Aurisch, P. Sevenich und J. Tölle

Die in Rahmen von INSC erarbeiteten Grundlagen und die aus dem internationalen Testbetrieb gewonnenen Erkenntnisse bilden eine wesentliche nationale Wissensbasis zum Einsatz von IP und insbesondere IPv6 in militärischen Netzen. Aus INSC heraus wurde die nationale IPv6-Migration initiiert und die Erarbeitung des IPv4/6-Migrationsrahmenkonzeptes Bw und des IPv4/6-Adressierungskonzeptes Bw wesentlich unterstützt.

20.6.2 Zielarchitektur für Koalitionsnetze Neben der Untersuchung der technischen und konzeptionellen Auswirkungen einer Migration von IPv4 nach IPv6 in einem militärischen Umfeld (siehe oben) waren vor allem die folgenden Aufgaben von maßgeblichem Interesse:  Design einer einfachen und flexiblen Architektur für ein IP-basiertes, verteiltes Koalitionsnetz mit mobilen Anteilen ! Overlay Network, das aus einem schwarzen WAN (Core Network) und vielen, flexiblen roten LANs (Secure Access Networks) besteht.  Verfügbarkeit der Lösungen, Verwendung von COTS und Abstützung auf bzw. Integration von öffentlichen ISP Netzen.  Ein wesentliches Merkmal des INSC-Projektes war es, von Beginn an ein Sicherheitskonzept in die Architektur zu integrieren. Der INSC-Ansatz „Nutzer in roten Koalitionsnetzen (national oder gemischt) kommunizieren verschlüsselt durch IPsec Gateways über ein schwarzes vermaschtes Koalitionsnetz“ erfreut sich internationaler Akzeptanz und wurde in der NNEC FS aufgegriffen. Aus deutscher Sicht sind diese Ansätze in die Vorhaben Verlegefähige Access-Netze und MobKommSysBw bzw. im Konzept für die mobile Kommunikation im Heer (KMobKommH) eingeflossen.

20.6.3 Mobilität Im Bereich Mobilität wurden die folgenden drei, grundsätzlich unterschiedlichen Ansätze untersucht und weiterentwickelt.

20.6.3.1 Mobile IP Ziel der Untersuchungen war es festzustellen, inwieweit die Ansätze zum Mobile IP (und hierbei insbesondere des Mobile IPv6 (MIPv6)) geeignet sind, die Mobilität einzelner Knoten in einem taktischen Netz und zwischen verschiedenen Netzen zu unterstützen.

20 Kommunikation in verteilten FüInfoSys

285

Zur Unterstützung einer wahlfreien Mobilität der Knoten wurde prinzipiell auf den Fähigkeiten von IPv6 aufgesetzt, um auf Ersatzelemente wie dem Foreign Agent (zur Unterstützung der Entdeckung von mobilen Knoten im Netz) verzichten zu können. Die Tests, die zwischen verschiedenen Partnern im INSC-Netz durchgeführt wurden, bezogen sich auch auf die Mobilitätsunterstützung über verschiedene CLAN-Domänen von Partnernationen hinweg (z. B. Gefechtsstandswechsel einzelner Soldaten). Alle Tests zu Mobile IP bezogen sich primär auf eine frei verfügbare MIPv6Implementierung (MIPL), die auch alle optionalen Protokollelemente des Mobile IPv6 enthält und somit die folgenden funktionalen Untersuchungen erlaubte:     

movement detection; binding registration; return routability; route optimization; Kommunikation zwischen mobilen Knoten (MN, mobile nodes) und anderen MNs bzw. korrespondierenden Knoten (CN, corresponding nodes) und Knoten ohne MIPv6-Funktionalität.

In den einzelnen Tests innerhalb von INSC konnte nachgewiesen werden, dass sich mobile Knoten (weltweit, unabhängig von den jeweils genutzten Netzen eines Partners bzw. eines zivilen Service Providers) in unterschiedlichsten Netzwerkarchitekturen frei bewegen konnten, solange der zugeordnete Home Agent (HA) erreichbar war; des Weiteren war es möglich, mit der Option route optimization die Netzlast zwischen HA, MN und CN auf ein Minimum zu reduzieren und bei direkter MNMN-Kommunikation durch Nutzung der Option return routability den Overhead ganz zu vermeiden. Es wurde nachgewiesen, dass eine bestehende Verbindung zu mobilen Knoten zwischen unterschiedlichen Anwendungen (Sprache, Videoverbindung, Email, File Transfer) in der Bewegung aufrecht erhalten werden kann. Insbesondere diese optionalen Protokollelemente im MIPv6 bieten eine Funktionalität an, die in kapazitätsbeschränkten militärischen Netzen unabdingbar ist und eine Verwendung von mobilem IPv4 aus Performance-Gesichtspunkten stark einschränkt.

20.6.3.2 Mobile Ad-hoc Netze (MANET) Bei diesem Ansatz handelt es sich um die Realisierung eines Ad-hoc-Verhaltens vornehmlich für WLAN basierte Netze. Diese können nicht nur ihre Topologie eigenständig aufbauen, sondern sich auch dynamisch an aktuelle Umstrukturierungen der Netzwerkknoten (z. B. entsprechend der geographischen Position auf dem Gefechtsfeld) anpassen. Die INSC-Untersuchungen konzentrierten sich auf das pro-aktive Routing-Protokoll OLSR (Optimized Link State Routing), das eine enge Verwandtschaft zu dem bei Festnetzen eingesetzten dynamischen Routing-Protokoll OSPF (Open Shortest

286

T. Aurisch, P. Sevenich und J. Tölle

Path First) hat, und realisierten die erste IPv6-fähige Implementierung des OLSRProtokolls (Gulder & Déziel, 2003). Zusätzlich wurden die neuen, schichtenübergreifenden MANET-Protokolle WNet und MFP entwickelt und getestet, die durch Berücksichtigung der Güte des Funkkanals eine effizientere Nutzung des Funkmediums gerade unter wechselnden und widrigen Funkbedingungen erlauben (CrossLayer-Design) (Bongartz et al. 2006). Damit liefert INSC für den militärischen Einsatz optimierte MANET-Protokolle und entsprechende Testergebnisse aus umfangreichen Feldversuchen, die in der ebenfalls Cross-Layer-orientierten SCA-Architektur eines SDR umgesetzt werden können und als Vorentwicklung für entsprechende Waveformen dieser zukünftigen Funkgerätegeneration dienen. Die Anbindung an feste Netzanteile wurde in INSC durch so genannte MANETGateways realisiert, die auch eine Übersetzung der Routing-Informationen übernehmen. Diese Komponente ist jedoch erst spät in die RFC-Standardisierung eingeflossen und lässt daher einige Fragen unbeantwortet und Anforderungen offen, wie z. B. die Unterstützung von redundanten Gateways zur Erhöhung der Verfügbarkeit und des Durchsatzes bzw. die Unterstützung vieler simultaner Verbindungen. In INSC wurde daher OLSR um die Fähigkeit erweitert, verfügbare MANET-Gateways dynamisch zu erkennen und in Abhängigkeit ihrer Auslastung für den Transfer auszuwählen. Darüber hinaus wurde OLSR auch um die Unterstützung von mobilen, d. h. lokalen, an einem MANET-Knoten angehängten Sub-Netzen erweitert, in dem die Verarbeitung und dynamische Verteilung von HNA (Host and Network Association)Nachrichten in die Routing-Informationen integriert wurde. Wichtig für den taktischen Einsatz ist auch die effiziente Punkt-zu-MultipunktÜbertragung von Daten (Multicast). Da OLSR nicht für Multicast-Übertragungen geeignet ist, wurden sowohl Erweiterungen von OLSR (SMF) getestet als auch die im Rahmen von INSC entwickelten MANET-Protokolle MFP und WNet von vornherein auf Multicast-Übertragung optimiert. Für die Nutzung existierender militärischer Funkkomponenten wurde eine MANET-Variante für schmalbandige Systeme realisiert (Basis: taktische VHF-Funkgeräte). Aufgrund der gering verfügbaren Nutzbandbreite konnte hier kein proaktives Routing-Protokoll eingesetzt werden. Deshalb wurde ein re-aktives Verfahren auf Basis von AODV (Ad-hoc on demand distance vector) integriert und getestet. Basierend auf den INSC-Ergebnissen wurde das nationale Projekt HMTI (HochMobiles Taktisches Intranet) zur Nutzung von MANET auf schmalbandigen VHFFunkgeräten initiiert. Ein wesentliches Ergebnis war die prototypische Realisierung einer IP-Fähigkeit der VHF-FuGerFam SEM 70/80/90 zur gleichzeitigen Übertragung von Daten und Sprache (VoIP). Aufbauend auf den positiven Ergebnissen der HMTI-Studie wurde das F&T-Vorhaben NetOpFü für Legacy-Funksysteme initiiert (FF C3). Mit diesem Forschungs- und Technologie-Vorhaben soll untersucht werden, inwieweit der IP-fähige, produktnahe Prototyp als Interims-Lösung und Migrationsschritt bis SVFuA (Streitkräftegemeinsame verbundfähige Funkanlage) verfügbar ist und realisiert werden kann.

20 Kommunikation in verteilten FüInfoSys

287

20.6.3.3 Netzwerkmobilität (NEMO) NEMO ist eine Erweiterung von MobileIP und ermöglicht die Mobilität ganzer Netze bzw. bietet ein Verfahren für das Roaming aggregierter Teilnetze (Devarapalli et al., 2005). Wie MobileIP benötigt auch NEMO die zentrale Instanz des Home Agents (HA), der in größeren, verteilten Netzen für den mobilen Knoten bzw. das mobile Netz einen Ankerpunkt darstellt und eine eindeutige und feste Heim-Adresse bereitstellt. Über diese ist ein mobiler Knoten bzw. ein mobiles Netz im RoamingFall global erreichbar. Im Fall von NEMO wird ein Mobile Router (MR) eingesetzt, an den lokale Knoten angeschlossen sind. Für letztere gestaltet sich das Netz und die Mobilität des MR als Ganzes transparent. NEMO überträgt die Vorteile von MobileIP auf ganze in Bewegung befindliche Netze und nicht nur auf individuelle Knoten. Dies bewirkt eine Minimierung des für die Signalisierung benötigten Verkehrs (Overhead). Im Rahmen der Untersuchungen in INSC wurden die zwei derzeit einzigen verfügbaren Implementierungen untersucht:  NEMO Open-Source für Linux/BSD  NEMO für CISCO IOS. Da der Erweiterungsmodus, der die Optimierung des Routing unterstützt, noch nicht detailliert spezifiziert ist, konnte die Funktionalität von Nested NEMOs (Kaskadierung mehrerer mobiler Netze) nur bedingt mittels zusätzlicher IP-Tunnel zwischen den MRs und dem HA realisiert werden.

20.7 IT-Sicherheit IT-Sicherheit lässt sich in zwei Kategorien einteilen. Die Mechanismen der ersten Kategorie ermöglichen einen sicheren Datenaustausch zwischen mehreren Netzknoten, während die Methoden der zweiten Kategorie den Schutz des Netzes zum Ziel haben. Die fundamentalen Themenbereiche Umsetzung von Sicherheitsrichtlinien und Schlüsselmanagement sind in beiden Kategorien der IT-Sicherheit zu betrachten. Schwerpunkt der weiteren Ausführungen sind Konzepte zum Schutz des Datenaustauschs. Hierbei werden zunächst mögliche Bedrohungen für die Datenübertragung genannt und anschließend die VPN-Technologie (Virtual Private Network) als mögliche Gegenmaßnahme beschrieben. Die Gewährleistung von Vertraulichkeit, Authentizität und Integrität für den Datenaustausch ist eine erforderliche Eigenschaft der Kommunikation, falls diese über offene Netze betrieben wird. Das Schutzziel des Sicherheitsdienstes Vertraulichkeit besteht in der Geheimhaltung von Daten, um ein Abhören durch unberechtigte Nutzer zu verhindern. Durch die Verteilung des zum Schutz verwendeten Schlüssels an autorisierte Nutzer kann somit eine Zugriffskontrolle realisiert werden. Schutzziel des Dienstes Integrität ist die Erkennung einer Fälschung bzw. die Unversehrtheit von Dateninhalten. Eng verwandt mit dem Sicherheitsdienst Integrität ist der Dienst

288

T. Aurisch, P. Sevenich und J. Tölle

Authentizität, d. h. die sichere Identifikation des Absenders. Bei authentischen Daten lässt sich eindeutig feststellen, von wem diese gesendet oder erzeugt wurden. Ist die Authentizität von Daten gewährleistet, kann der Absender die Herkunft der Informationen nicht leugnen.

20.7.1 Netzsicherheit Die VPN-Technologie ist eine Methode, um Informationen bei der Übertragung vor unerwünschten Zugriffen zu schützen. Hierzu werden durch kryptografische Mechanismen geschützte Tunnel durch unsichere Netze aufgebaut. Dadurch entsteht eine sichere, flächendeckende Netzinfrastruktur, bei der private Netze (z. B. lokale/taktische Netze im Einsatzland oder strategische Netze in der Heimat) über ein öffentliches Netz (z. B. das Internet) sicher miteinander kommunizieren können. Die Nutzung des öffentlichen Netzes bleibt für die Nutzer transparent. Oftmals werden die privaten Netze auch als rote Netze oder Domänen bezeichnet, während man die unsicheren Netze als schwarze Netze bzw. Domänen darstellt. Die IP Security (IPsec) Architektur ist eine Methode zur Realisierung von VPNs. Der IPsec-Standard wurde von der IETF (Internet Engineering Task Force) entwickelt und in so genannten Request for Comments (RFCs) festgelegt. Die ursprünglichen IPsec-RFCs 2401 bis 2412 werden dabei durch eine Reihe von späteren RFCs ergänzt (Kent & Seo, 2005), die zusätzlich den Einsatz bestimmter Algorithmen spezifizieren. Der Vorteil von IPsec ist die Bereitstellung von Sicherheitsdiensten auf der Netzwerkschicht. Aus diesem Grund muss kein Anwendungsprogramm angepasst werden und IPsec kann über eine beliebige Kombination von Kommunikationsmitteln betrieben werden. Wegen dieser Vorteile wurde IPsec in dem Projekt INSC als Sicherheitsmechanismus ausgewählt. Die Systemarchitektur von IPsec setzt sich aus mehreren Bestandteilen zusammen. Durch das IPsec-Modul des Betriebssystems wird der Datenverkehr mit Sicherheitsdiensten ausgestattet. Zu ihrer Etablierung sind in IPsec die zwei Protokolle Authentication Header (AH) (Kent, 2005a) und Encapsulation Security Payload (ESP) (Kent, 2005b) definiert. AH stellt Authentizität und verbindungslose Integrität für das gesamte IP-Paket zur Verfügung. ESP wird für Vertraulichkeit, Authentizität und verbindungslose Integrität der Nutzdaten eines IP-Pakets eingesetzt. Durch eine Kombination der Protokolle AH und ESP wird das gewünschte Sicherheitsniveau eingestellt. Das IPsec-Modul wird über zwei IPsec-Datenbanken gesteuert. Ein Parametersatz, der beschreibt, wie eine Datenübertragung geschützt werden soll, wird als Security Association (SA) bezeichnet. SAs werden in der Security Association Database (SAD) gespeichert. SAs werden vom Internet Key Exchange (IKE) oder von der überarbeiteten Version des Schlüsselmanagements Internet Key Exchange Version 2 (IKEv2) verwaltet. Der Schutz, den IPsec für eine Datenübertragung bereitstellt, basiert auf den Regeln, die in der Security Policy Database (SPD) definiert sind. Diese Datenbank wird von einem Administrator manuell verwaltet. Mit der Sicheren Inter-Netzwerk Architektur (SINA) steht eine vom Bundesamt für Sicherheit in der Informationstechnik (BSI) zertifizierte Implementierung von

20 Kommunikation in verteilten FüInfoSys

289

IPsec zur Verfügung. Mit der Hardware-Variante (SINA-Box H) können Informationen bis zur Einstufung STRENG GEHEIM transportiert werden. Hierbei wird der hierzu eigens entwickelte Kryptochip PLUTO eingesetzt. Mit der Software-Variante (SINA-Box S) können Informationen bis zur Einstufung VS-VERTRAULICH sicher übertragen werden. Insbesondere in taktischen Netzumgebungen, aber auch in strategischen Netzen, besteht die Erfordernis, IPsec-basierte VPNs vollkommen automatisch, ohne den Eingriff eines Administrators aufzubauen. An dieser Stelle setzt das IPsec Discovery Protocol (IDP) an. Es dient der automatischen Lokalisierung von verfügbaren IPsecInstanzen und deren automatischer Konfiguration. In taktischen Netzumgebungen stehen oftmals nur geringe Datenübertragungsraten zur Verfügung. Werden VPNs mittels IPsec aufgebaut, werden die Nutzdaten inklusive des Headers des IP-Pakets verschlüsselt. Anschließend wird ein zusätzlicher IP-Header für den Transport ergänzt. Hierdurch entsteht ein Overhead, der sich gerade bei Anwendungen, die viele kleine Pakete (z. B. VoIP) austauschen, negativ auswirkt. Aus diesem Grund wurde IPsec für den Einsatz in militärischen Netzen um einen effizienten Kompressionsmechanismus ergänzt, der den ursprünglichen IP-Header noch vor der Verschlüsselung entfernt und durch ein individuelles Etikett ersetzt. Wichtiger Bestandteil der militärischen Kommunikation ist neben der Punkt-zuPunkt-Kommunikation die gruppenorientierte Kommunikation. Technisch kann diese durch den Multicast-Dienst der Internet-Technologie realisiert werden. Wie bereits dargestellt, werden im Fall der Punkt-zu-Punkt-Kommunikation die von IPsec benötigten SAs von dem Schlüsselmanagement IKE bzw. IKEv2 bereitgestellt. Soll IPsec auch zum Schutz der Multicast-Kommunikation eingesetzt werden, muss IPsec um einen Mechanismus erweitert werden, der einen gemeinsamen Schlüssel in Gruppen etabliert. Zur Verwaltung eines dynamischen Gruppenschlüssels wurde deshalb das Konzept Multicast Internet Key Exchange (MIKE; vergl. Aurisch, 2008) eingeführt. MIKE ist ein Schlüsselmanagementkonzept, welches zwei Verfahren zur Schlüsselbereitstellung beinhaltet. Das Konzept stellt die zwei Betriebsmodi Key Agreement und Key Distribution zur Verfügung. Die Entwicklung des Betriebsmodus Key Agreement wurde mit dem Ziel der Gewährleistung einer hohen Ausfallsicherheit durchgeführt, da zur militärischen Kommunikation häufig mobile Ad-hoc-Netze (MANET) eingesetzt werden. Kernpunkt des Betriebsmodus ist der Verzicht auf eine Gruppenschlüsselbereitstellung durch eine zentrale und leicht störbare Instanz. Der zweite Modus stellte die Skalierbarkeit des Konzepts sicher, d. h., er erlaubt die Bereitstellung eines Gruppenschlüssels auch in großen Gruppen.

20.7.2 Anwendungssicherheit mittels des Secure Communications Interoperability Protocols (SCIP) Neben der datenorientierten Kommunikation müssen noch realzeitorientierte Anwendungen betrachtet werden. Als ein möglicher Vertreter hierbei ist das Secure

290

T. Aurisch, P. Sevenich und J. Tölle

Communications Interoperability Protocol zu benennen, das die Möglichkeit für eine applikationsgesicherte Kommunikation für verschiedene Anwendungen vorsieht und derzeit vornehmlich für eine anwendungsgesicherte Sprachübertragung genutzt wird. SCIP gilt als das Standardverfahren für die sichere Sprachkommunikation innerhalb der US-Regierung und soll zukünftig im NATO-Umfeld eingesetzt werden (Tölle & Schmidt, 2006). SCIP basiert auf dem Protokoll Future Narrowband Digital Terminal (FNBDT). Die wichtigste Fähigkeit von SCIP besteht darin, dass es auf eine Vielzahl von Netzen übertragbar ist. Die Ursache hierfür ist, dass die minimale Anforderung an den verwendeten Kanal eine Bandbreite von lediglich 2400 Bits/s bei einer Bitfehlerrate von bis zu 1% ist. SCIP enthält neben den Mechanismen zum Schutz der Daten auch ein Schlüsselmanagement. Dieses handelt, nachdem zwischen zwei SCIP-Endgeräten ein Übertragungskanal aufgebaut wurde, gemäß einer vordefinierten Sicherheitsvorschrift die für eine sichere SCIP-Kommunikation benötigten Parameter und Schlüssel aus. Somit kommt es, abhängig von der Fähigkeit beider Terminals und den vorkonfigurierten Einstellungen, zu einer von beiden Seiten akzeptierten Verbindung. In einer Studie konnte gezeigt werden, dass eine Kopplung von IPsec und SCIP möglich ist.

20.7.3 Public Key Infrastructure (PKI) Die bei IPsec und anderen Sicherheitsmechanismen eingesetzten Authentifizierungsbzw. Zugriffskontrolldienste basieren meistens auf asymmetrischen kryptographischen Verfahren. Damit diese verwendet werden können, muss eine PKI realisiert werden. Dazu werden für IT-Systeme (z. B. PCs, VoIP-Telefone) Gerätezertifikate und für Personen sowie Rollen Benutzerzertifikate ausgestellt. Diese werden anschließend auf den Systemen installiert bzw. auf SmartCards für Personen hinterlegt. Die Zertifikate bestehen aus durch die Certificate Authority (CA) der PKI signierten öffentlichen und privaten Schlüsseln. Die PKI übernimmt die Erzeugung, Verwaltung und Verteilung von Zertifikaten sowie der zugehörigen kryptografischen Schlüssel. Hierzu werden Key-Server oder Directory-Server verwendet. Die Dienste der PKI werden in so genannten Trust Centern erbracht, welche gemäß der Sensibilität der dort verarbeiteten Daten und Informationen hohen infrastrukturellen, technischen und organisatorischen Sicherheitsanforderungen unterliegen. Unter Umständen ist eine Gliederung in der PKI notwendig. Dieses beinhaltet insbesondere die Etablierung von SubCA, die unterschiedliche Sicherheitsebenen bis zu dedizierten Anwendungen beinhalten können. Bei Kompromittierungen von einzelnen SubCAs besteht die Möglichkeit, diese zu sperren, ohne die PKI des Gesamtsystems zu beeinflussen. In der Kommunikation bei einem Koalitionseinsatz (z. B. innerhalb der NATO) kommt eine separate einsatzbezogene PKI zum Einsatz. Diese erzeugt für die am Einsatz beteiligten Systeme, Personen und Rollen entsprechende Zertifikate. Diese Lösung ermöglicht eine mit allen Partnern abgestimmte Sicherheitsrichtlinie. So-

20 Kommunikation in verteilten FüInfoSys

291

mit kann für den Einsatz eine Sicherheitsrichtlinie verwendet werden, die von der nationalen Sicherheitsrichtlinie abweicht.

20.8 Netzmanagement Ziel der Aktivitäten im Umfeld Netzmanagement war eine Machbarkeitsuntersuchung für ein rollen- bzw. nutzerorientiertes Managementsystem auf Basis kommerzieller Implementierungen des Internet-Protokolls SNMP (simple network management protocol). Die in der neuesten Version SNMPv3 verfügbaren Mechanismen zur Authentifizierung und Verschlüsselung wurden hierbei als prinzipiell nutzbar für ein verteiltes Management in einem Koalitionseinsatz, auch für den Durchgriff von Managementinstanzen aus einem geschützten Netzwerkbereich (CLAN) auf ungeschützte (schwarze) Netzelemente, angesehen. Zum Zeitpunkt der Durchführung der Untersuchung war SNMPc das einzige repräsentative COTS-Netzwerkmanagement (große Verbreitung), das SNMPv3 im vollem Umfang unterstützte. Der Nachteil war jedoch, dass es keine IPv6-Unterstützung bot. Die Kommunikation der Agenten mit dem Management-Server wurde daher mittels IPv4/v6-Tunneling ermöglicht, was gleichzeitig auch als Nachweis für die praktische Verwendbarkeit des Migrationsansatzes Tunneling diente (siehe Abschn. 20.6.1). Neben SNMPc wurde auch die freie Implementierung NET-SNMP für Linux untersucht. Diese unterstützt IPv6, bringt jedoch kein grafisches Tool zur Programmierung und Auswertung mit sich. Da derzeit noch keine eindeutige Lösung für den rot-schwarz-Übergang von Managementinformationen besteht, konnten nur potentielle Ansätze untersucht werden.

20.9 Bewertung der Ergebnisse Die Ergebnisse aus INSC können in folgende Kategorien eingeordnet werden:

20.9.1 Art der Zusammenarbeit Die Art der Kooperation in einem multinationalen Projekt hat sich als effizienter erwiesen als auf der Basis von NATO-Arbeitsgruppen:  Die Koordination nationaler Interessen erfolgt schneller auf der Basis kleiner Gruppen.  Primäres Ziel ist die Generierung von realen Ergebnissen anhand implementierter Funktionsnachweise. Die Abbildung der Ergebnisse in Form von STANAGs wird als zu langwierig erachtet. Dennoch bringen einige beteiligte Nationen

292

T. Aurisch, P. Sevenich und J. Tölle

INSC-Ergebnisse in neue STANAGs ein bzw. modifizieren diese aufgrund der gewonnenen Ergebnisse.  Durch die Zuordnung von nationalen Projekten (bzw. deren Ressourcen) zum multinationalen Projekt entfällt die Notwendigkeit einer gemeinsamen Budgetverwaltung.

20.9.2 Umsetzung von Ergebnissen in nationalen Programmen Die gemeinsame Aufgabenstellung wurde primär durch das Einbringen nationaler Anforderungen vorangetrieben. Durch die (gemeinsame) Lösung ergab sich unmittelbar ein Ergebnis, das direkt auf die nationalen Belange abgebildet werden konnte (im deutschen Umfeld z. B. KMobKommH, MobKommSysBw bzw. EGV-SAL).

20.9.3 Generelle Ergebnisse aus INSC Der Nutzen und die Machbarkeit einer einheitlichen Architektur für die sichere Kommunikation auf Basis von Virtuellen Privaten Netzen (VPNs) über verschiedenartige Trägernetze ist das wesentliche Ergebnis des Projektes. Durch den Einsatz von interoperablen Sicherungsmitteln auf der Netzwerkebene konnte eine durchgängige Sicherung des Informationsflusses bis zur Stufe Geheim bzw. NATO SECRET erreicht werden. Die während der Projektlaufzeit verfügbaren Implementierungen auf Basis von IPv6 konnten eingehend getestet und deren erweiterter Nutzen gegenüber herkömmlicher IP-Technik (auf Basis IPv4) nachgewiesen werden (inklusive des Übergangs zwischen diesen Techniken). Der voraussichtlich lange Übergang von IPv4 nach IPv6 in implementierten Systemen der beteiligten Nationen wurde durch die Untersuchung der verschiedenen Transitionsmöglichkeiten und der Realisierung der Techniken auf verschiedenen Plattformen (z. B. Windows, Linux) unterstützt. Um den Protokoll-Overhead besonders in schmalbandigen Netzen unter IPv6 zu reduzieren, wurde erfolgreich die Nutzung von Header-Reduction-Protokollen erprobt und in einigen Bereichen (z. B. VoIP, HMTI) als unbedingt notwendig postuliert. Im Bereich des Netzwerkmanagements wurde eine sich über alle VPNDomänen der beteiligten Partner erstreckende Managementkomponente zur Darstellung des Ist-Zustandes und zur (eingeschränkten) Steuerung einzelner Parameter (mittels der Funktionalitäten des SNMPv3) auch in dezidierten Bereichen eines Partnernetzes erfolgreich eingesetzt. Dabei wurden zwei verschiedene Ansätze untersucht:  Zentralisiertes Management (eine Managementkomponente für alle VPNs)  Verteiltes Management (korrespondierendes Management mit einer Managementkomponente pro VPN).

20 Kommunikation in verteilten FüInfoSys

293

Es hat sich aber gezeigt, dass es derzeit noch keine zufriedenstellende technische Lösung für ein gemeinsames Management über mehrere, unterschiedlich klassifizierte Netzwerkdomänen hinweg gibt. Im Bereich der diensteabhängigen Qualitätsunterstützung wurde nachgewiesen, dass ein durchgängiges QoS-Konzept auch unter hoher Netzbelastung einzelnen Diensten (wie VoIP, VTC) eine gute Netzwerkunterstützung erlaubt (zu Lasten anderer, geringer priorisierter Dienste). Damit können auch Dienste mit Realzeitanforderungen in einem IP-Netz mit genügender Dienstgüte im Lastfall betrieben werden. Die durchgängige Unterstützung der Dienstgüte wurde auch über verschiedene miteinander gekoppelte Partnernetze hinweg erprobt. Diese Möglichkeit wurde für unterschiedliche Prioritätslevel in militärisch nutzbaren Anwendungen nachgewiesen, die in unterschiedliche Verkehrsklassen in Koalitionsnetzen eingeteilt wurden. Höher priorisierte Informationen werden mit einer niedrigeren Wahrscheinlichkeit verworfen bzw. verzögert, falls ein Router mit Paketen überflutet wird. Diese Fähigkeit erfordert allerdings, dass alle zugehörigen Anwendungen modifiziert werden müssen, indem eine Markierung im IP-Header in der zugehörigen Diensteklasse erfolgt. Durch die mit den relevanten Sicherheitsinstanzen (u.a. dem BSI) abgesprochene Modifikation der IPsec-Geräte wurde zusätzlich eine Ende-zu-Ende-Unterstützung der Prioritäten bzw. der Dienstgüte gewährleistet. IP-Netze sind stark abhängig von der Verfügbarkeit eines DNS-Services (Domain Name System). Das heißt, in der vernetzten Operationsführung muss eine robuste DNS-Infrastruktur zu Erfüllung einer Mission verfügbar sein. Im Projekt INSC wurde eine Methode zur Verbesserung der Robustheit des DNS-Services (mittels direkter anstatt hierarchischer Replizierung) aufgezeigt und im Koalitions-IP-Netz erprobt. Dieselbe Methode kann ebenfalls für die Verbesserung der Robustheit in nationalen Netzen verwendet werden. Für die Unterstützung der Mobilität wurde eine neue IP-Routing-Technologie angewandt, die für den Einsatz in hoch mobilen drahtlosen Szenarien (z. B. in taktischen drahtlosen Sensornetzen) geeignet war. Diese neue Funktionalität basiert auf einem sich selbst konfigurierenden, mobilen Ad-hoc-Netz (MANET) und IPTechnologie und unterstützt neue militärische Anwendungsmöglichkeiten für Einsätze in hochdynamischen oder mobilen drahtlosen Szenarien. Das für effizientes MANET-Routing entwickelte Cross-Layer-Protokoll WNet wird erfolgreich in anderen Experimentalsystemen (z. B. einem Multi-RoboterSystem zur Kommunikation mobiler autonomer Einheiten mit einer Kommandozentrale) eingesetzt. Die Ende-zu-Ende-Interoperabilität zwischen verschiedenen heterogenen mobilen Netzen, die an verschiedenen Orten innerhalb eines sicheren Koalitions-WANs eingesetzt waren, wurde ebenfalls dargestellt.

20.9.4 Militärische Relevanz Die Ergebnisse aus INSC sind auf vielfältige Weise bei der NATO und in Projekte (z. B. KMobKommH, MobKommSysBw, Konzept für die IT-Sicherheit im ITSystem Bw) eingeflossen.

294

T. Aurisch, P. Sevenich und J. Tölle

Viele Elemente der INSC-Architektur finden sich auch in den Architekturkonzepten der NNEC wieder, wie z. B. im Protected Black Core Network und in der Idee des Zusammenschlusses von (Koalitions-)Netzen. Die erzielten INSC-Ergebnisse haben weiterhin verschiedene STANAGs und deutsche Konzepte initiiert, beeinflusst oder Einzug in diese gefunden:  STANAG 5067: Die Anforderungen an den Physical Layer für Multimediakommunikation über IPv6-Netze werden hier zusammengefasst.  STANAG 5524: NATO Interoperability Standards and Profiles. Vor allem die Ergebnisse der MANET-Untersuchungen sind hier wiederzufinden.  STANAG 4622 SBS (Satellite Broadcast Services): Der wesentliche Beitrag von INSC zu diesem STANAG ist die Empfehlung, das IP-Encapsulation-Protokoll von MPE (Multi-Protocol Encapsulation) auf ULE (Ultra Light Encapsulation) zu ändern. Dies gestattet der NATO die Migration hin zu IPv6.  STANAG 4644: Die in INSC entwickelte Lösung zur Zuweisung von DSCPWerten an verschiedene Verkehrsklassen bzw. Servicetypen wurde vom TP2KProjekt übernommen und hat Einzug in diesen Standard genommen.  STANAG 4591: INSC hat wesentlich dazu beigetragen, diese STANAG zur Standardisierung von NATO-Schmalbandvocodern zügig umzusetzen. Innerhalb INSC wurden die ersten Implementierungen dieser Vocoder in demonstrierbare VoIP-Software durchgeführt.  Das Konzept für die mobile Kommunikation im Heer (KMobKommH) basiert weitgehend auf dem INSC-Ansatz.  Das Sicherheitsmodell aus INSC wurde in das Konzept IT-Sicherheit im ITSysBw übernommen. INSC ist ein innovatives Projekt, welches sicherstellt, dass Deutschland im Bereich der militärischen Nutzung von IP Technologie international den Anschluss hält und von den Koalitionspartnern, insbesondere den großen NATO-Nationen, als kompetenter Partner angesehen wird. Darüber hinaus können für die deutschen Lösungen und Vorgehensweisen die internationale Akzeptanz und Kompatibilität im Hinblick auf Koalitionseinsätze geprüft werden.

20.10 Empfehlungen aufgrund der gewonnenen INSC-Ergebnisse Die Ergebnisse aus INSC haben einen Reifegrad erreicht, der es erlaubt, folgende Empfehlungen für reale militärische Kommunikationssysteme aufzustellen:  Nutzung von geschützten schwarzen Transitnetzwerken mit durchgehend einheitlicher Adressierung und einheitlichem Routing, homogenen Sicherheitselementen und Netzmanagementeinrichtungen über alle Netzdomänen hinweg.  Nutzung von dynamischen Discovery-Mitteln zum Aufspüren aktiver Sicherungselemente im Netzwerk (PMIDP) inkl. einer dynamischen Gruppenschlüsselverwaltung (MIKE).

20 Kommunikation in verteilten FüInfoSys

295

 Nutzung von MANET-Profilen in hochmobilen, drahtlosen Netzwerken.  Ausdehnung von MANET-Profilen auf weitere taktische Funksysteme, ggf. unter Änderung des Routingverfahrens (OLSR oder AODV).  Nutzung der Testergebnisse aufgrund der erfolgten Feldversuche, insbesondere im Bereich MANET, in anderen Projekten (als Entscheidungsgrundlage für Beschaffungen bzw. als Validierungsgrundlage bei weiteren Systemspezifikationen).  Integration eines Policy-basierten Managementsystems über alle Netzdomänen hinweg zur Unterstützung eines Ende-zu-Ende QoS-basierten Informationsaustauschs.  Implementierung eines automatisierten, dynamischen Level Agreements zur Unterstützung eines zeitnahen Systemmanagements bei Änderungen im Koalitionsnetz.  Unterstützung von Dual Stack (IPv4 und IPv6) und Network Address Translation als Migrationselement.  Mögliche Weiternutzung von existierenden Schmalbandfunksystemen durch deren Einbindung in eine netzübergreifende taktische IP-Infrastruktur (z. B. HMTI, abhängig von deren operationeller Verwendbarkeit).  Nutzung der Ergebnisse (z. B. auch weiterverwendbarer Softwareanteile aus den Bereichen PC-Phone, P_mul, Headerkompression und MANET-Protokolle) bei den breitbandigen Funksysteme z. B. im Projekt SVFuA.  Nutzung der Ergebnisse in anderen internationalen Projekten (TICNET, REMINET, NATO QoS Initiative, NATO IPv6 Initiative).

20.11 Ausblick Im Rahmen einer Nachfolgephase des Projektes stehen insbesondere  die konkrete Ausformulierung aller Schnittstellen in taktischen Systemen (eine Präzisierung des Interoperabilitätspunktekonzeptes (IOP) aus der NNEC Feasibility Study der NC3A),  die netzseitige Unterstützung zur Auffindung von Diensten und Informationen in einem Koalitionsnetz und  die Sicherheitsbetrachtungen in einem solchen Verbundnetz (realisierbare Lösungen für die Bereitstellung und den Schutz eigener Informationen über nationale Grenzen hinweg) im Vordergrund. Ein weiterer Schwerpunkt wird die Fragestellung sein, wie die gewonnenen Erkenntnisse in eine Service-orientierte Architektur (SOA) in einem taktischen Umfeld eingebracht werden können.

296

T. Aurisch, P. Sevenich und J. Tölle

Literaturverzeichnis Aurisch, T. (2008). Baumbasiertes Dualmodeschlüsselmanagement für die Multicast-Kommunikation. Dissertation, Rheinische Friedrich-Wilhelms-Universität Bonn. Bongartz, H., Bachran, T., de Waal, C., & Frank, M. (2006). Uni- and multicast performance evaluation of the proactive link quality based MANET routing protocol WNet. Technischer Bericht, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Devarapalli, V., Wakikawa, R., Petrescu, A., & Thubert, P. (2005). Network Mobility (NEMO) Basic Support Protocol. RFC 3963. Goode, R. (2006). IPv6 in the Defence Sector. In Proceedings of the IPv6 EU Expert Conference Wien, Österreich. Goode, R., Guivarch, P., & Sevenich, P. (2006). IPv6 for Coalition Network Enabled Capability. In Proceedings of the Military Communications Conference (MILCOM) (pp. 1–6). Washington, USA: IEEE. Gulder, S. & Déziel, M. (2003). Quality of Service Mechanisms for MANET using Linux. In Proceedings of the INSC Symposium 2003 Den Haag, Niederlande: NATO C3 Agency. Kent, S. (2005a). IP Authentication Header. RFC 4302. Kent, S. (2005b). IP Encapsulating Security Payload (ESP). RFC 4303. Kent, S. & Seo, K. (2005). Security Architecture for the Internet Protocol. RFC 4301. Sevenich, P., Lies, M., Bongartz, H., & Aurich, T. (2007). Sichere Uni-/Multicastübertragung in mobilen taktischen Ad-hoc Netzwerken. Abschlußbericht zur Studie, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg. Tölle, J. & Schmidt, H. (2006). SCIP-IPsec-Interoperabilität. Abschlussbericht zur Studie, Forschungsgesellschaft für Angewandte Naturwissenschaften e.V., Wachtberg.

Kapitel 21

Testen der semantischen Interoperabilität von Führungsinformationssystemen Michael Gerz, Michael Glauer und Nico Bau

21.1 Einleitung Im Informationszeitalter ist die Interoperabilität von Führungsinformationssystemen (FüInfoSys) von entscheidender Bedeutung für den Ausgang militärischer Operationen. Semantische Interoperabilität ist dabei erreicht, wenn die beteiligten Systeme Daten nicht nur strukturiert austauschen, sondern diese auch einheitlich interpretieren (vgl. Abschn. 2.6 auf Seite 23). Sollen unterschiedliche FüInfoSys in einem IT-Verbund genutzt werden, wie dies bei internationalen Einsätzen erforderlich ist, kann semantische Interoperabilität mit Hilfe eines gemeinsamen Standards für den Informationsaustausch erreicht werden. Die Implementierung eines verteilten Systems ist eine komplexe und fehleranfällige Aufgabe. In Hinblick auf FüInfoSys gilt dies insbesondere für bestehende Legacy-Systeme mit proprietären Datenmodellen und Austauschverfahren, die nachträglich mit einer standardisierten Schnittstelle versehen werden sollen. Hierfür sind nicht nur entsprechende Softwarekomponenten für den Datenaustausch (z. B. Kommunikationsprotokolle) zu implementieren, sondern insbesondere auch umfangreiche semantische Abbildungen zwischen den intern und extern genutzten Datenmodellen erforderlich. Diese sind in der Regel nicht bijektiv und somit verlustbehaftet. Schmitt (2005) hat darüber hinaus aufgezeigt, dass für die korrekte Umsetzung eines Interoperabilitätsstandards eine reine Schnittstellen-Lösung nicht ausreichend ist, sondern vielmehr Änderungen in einer Vielzahl von Komponenten bis hin zur Nutzerschnittstelle erforderlich sein können. Diese Problematik wird noch verschärft, wenn mehrere Standards parallel unterstützt werden sollen. Die korrekte Umsetzung eines Standards kann sowohl durch konstruktive als auch durch analytische Qualitätssicherungsmaßnahmen unterstützt werden. Ein wesentlicher Bestandteil des Software-Entwicklungsprozesses stellt dabei das Testen dar. Ein Softwaretest ist eine analytische, jederzeit wiederholbare Maßnahme, um die Funktionalität einer Software bzgl. ihrer Anforderungen zu prüfen und ihre Qualität zu messen. Softwaretests dienen dem Aufdecken von Fehlern; man kann mit

M. Wunder, J. Grosche (Hrsg.), Verteilte Führungsinformationssysteme DOI 10.1007/978-3-642-00509-1, © Springer 2009

297

298

M. Gerz, M. Glauer und N. Bau

ihnen aufgrund der Komplexität heutiger Programme aber niemals die Abwesenheit von Fehlern und damit die Korrektheit der Software beweisen. Aufgrund der Kritikalität des hier betrachteten militärischen Anwendungsbereichs – eine falsch interpretierte oder fehlende Information im Führungsinformationssystem kann Leben kosten! – spielt die Qualitätssicherung eine besondere Rolle. Daher ist es notwendig, Tests mit einer möglichst guten Abdeckung zu spezifizieren und durchzuführen. Dabei sollte das Verhalten der Systeme auch in Ausnahmesituationen (z. B. bei fehlerhaften Eingaben) und unter Last untersucht werden. Verschiedene Quellen schätzen, dass bis zu 50% der Softwareentwicklungskosten auf das Testen entfallen (vgl. Myers, 2004). Somit trägt eine Verbesserung des gesamten Testprozesses wesentlich zum Erfolg von IT-Vorhaben bei. Im Folgenden zeigen wir auf, wie Verbesserungen des Testmanagements und entsprechende Werkzeuge dazu beitragen, die semantische Interoperabilität von FüInfoSys zu verbessern. Die vorliegenden Arbeiten sind im Rahmen des Multilateral Interoperability Programme (MIP) entstanden1; die Ergebnisse und Erkenntnisse lassen sich jedoch im Kern auch auf andere Projekte übertragen. In MIP definieren 27 Nationen und die NATO systemunabhängige Spezifikationen basierend auf Konsens, mit dem Ziel, „internationale Interoperabilität von FüInfoSys auf allen Ebenen von Korps bis Bataillon, oder der niedrigsten geeigneten Ebene, zu erlangen, um multinationale (einschließlich NATO), Combined- und Joint-Operationen zu unterstützen [. . . ]“ (MIP, 2006). Die MIP-Spezifikationen decken dabei operationelle, prozedurale und technische Aspekte ab. Die MIP-Lösung basiert technisch auf dem Data Exchange Mechanism (DEM; MIP, 2008b), einem Publish-Subscribe-Mechanismus, mit dem Datenbankinhalte repliziert werden können. Jedes MIP-Gateway bietet dabei verschiedene, vordefinierte operationelle Informationsgruppen (OIGs) an. Als gemeinsames Datenmodell definiert MIP das Joint Consultation, Command, and Control Information Exchange Data Model (JC3IEDM; MIP, 2008c), welches in Kap. 16 auf Seite 219 ausführlich beschrieben wird. MIP entwickelt seine Spezifikationen kontinuierlich weiter, um neue operationelle Anforderungen zu unterstützen und die Erkenntnisse vorangegangener Interoperabilitätsübungen zu berücksichtigen. Die vorliegenden Arbeiten beruhen auf der MIP Baseline 3 (verabschiedet 2009). Das vorliegende Kapitel ist wie folgt strukturiert: In Abschn. 21.2 erläutern wir zunächst die wesentlichen Konzepte und Herausforderungen beim Testen der semantischen Interoperabilität und verdeutlichen insbesondere den Unterschied zwischen Interoperabilitäts- und Konformitätstests. Für die verschiedenen funktionalen Aspekte der MIP-Lösung werden in Abschn. 21.3 unterschiedliche Testansätze vorgestellt. Mit dem MIP Test Reference System (MTRS) präsentieren wir in Abschn. 21.4 ein Werkzeug für die automatisierte Durchführung von Konformitätstests. In Abschn. 21.5 geben wir schließlich eine Zusammenfassung und einen Ausblick.

1 Die Arbeiten wurden durch das Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr, Abteilung D2, gefördert.

21 Testen der semantischen Interoperabilität

299

21.2 Interoperabilitäts- und Konformitätstests Softwaretests können hinsichtlich verschiedener Kriterien klassifiziert werden (vgl. Schmitt, 2003). Im vorliegenden Kontext ist insbesondere die Unterscheidung zwischen Interoperabilitäts- und Konformitätstests von Bedeutung. Ein Interoperabilitätstest ist ein funktionaler Test, der die Fähigkeit eines Softwareprodukts bewertet, mit einer oder mehreren spezifizierten Komponenten oder Systemen zu interagieren. Für die Durchführung von Interoperabilitätstests im internationalen Kontext werden nicht nur Systeme verschiedener Nationen benötigt, sondern auch entsprechend ausgebildetes Testpersonal, das in der Lage ist, die Systeme zu bedienen und die Tests auszuwerten. Insbesondere in den früheren Phasen der Entwicklung, in denen möglicherweise auch die zugrunde liegenden Spezifikationen noch nicht ausgereift sind, ist ferner die Teilnahme der Implementierer und der Standardisierer (häufig in Personalunion) ratsam. Interoperabilitätstests erfolgen typischerweise im Rahmen bi- und multilateraler Testsitzungen, die entweder räumlich verteilt oder an einem gemeinsamen Ort stattfinden. Im Rahmen von MIP testen die Nationen ihre Implementierungen über das Internet und bei der Wehrtechnischen Dienststelle (WTD) 81 in Greding, Bayern. Als Grundlage für Interoperabilitätstests dienen Testspezifikationen, die idealerweise bereits im Rahmen der Standardisierung entwickelt werden. Während der Interoperabilitätstests werden die beteiligten FüInfoSys durch ihre nationalen Testoperateure bedient und das Verhalten der Systeme wird mit dem in den Testdokumenten spezifizierten, zu erwartenden Verhalten verglichen. Dabei müssen die Testoperateure ihre Aktionen synchronisieren – bei Tests über das Internet beispielsweise mit Hilfe eines Chat-Tools – und gemeinsam das Testergebnis bestimmen. Alle Tests müssen ggf. mehrmals durchgeführt werden, damit jedes FüInfoSys jeweils jede Rolle in einer vorgegebenen Testkonfiguration einnimmt. Der obige Testansatz hat in der Vergangenheit verschiedene Probleme offenbart:  Die Testausführung gestaltet sich zeitintensiv, da sich die Testoperateure vor und während der Testsitzungen abstimmen müssen.  Umfangreiche Regressionstests bei Änderungen an einer Implementierung (z. B. infolge einer Änderung an den Entwurfsspezifikationen) sind aus Zeitgründen praktisch unmöglich.  Im Falle eines Fehlers in einem der beteiligten FüInfoSys muss die Testsitzung unter Umständen für unbestimmte Zeit unterbrochen werden.  Das Verhalten von FüInfoSys bei fehlerhaften Eingaben kann nur bedingt getestet werden, da die beteiligten FüInfoSys in der Regel nicht in der Lage sind, fehlerhafte Ausgaben zu produzieren.  Die Möglichkeiten zur Fehlerdiagnose sind eingeschränkt, wenn die FüInfoSys keine geeigneten Informationen über ihren internen Zustand liefern. Zudem ist im Falle eines Problems zunächst unklar, welches der beteiligten Systeme den Fehler produziert hat.  Fehler bleiben unentdeckt, wenn die an den Tests beteiligten Systeme dasselbe fehlerhafte Verhalten aufweisen (welches sich damit nivelliert). Dieses Problem

300

M. Gerz, M. Glauer und N. Bau

wird teilweise dadurch behoben, dass das eigene FüInfoSys mit möglichst vielen anderen FüInfoSys getestet wird (bei MIP 3 bis 5 Systeme je nach Testkategorie). Im Gegensatz zum Interoperabilitätstest steht der Konformitätstest, bei dem ein Softwareprodukt gegen einen Standard geprüft wird. Ein Konformitätstest ist ein funktionaler Black-Box-Test, der ohne Kenntnisse über die innere Funktionsweise und Struktur des zu testenden Systems entwickelt und durchgeführt wird. Nur das nach außen beobachtbare Verhalten der Black Box fließt in die Testurteile ein. Die Prüfung der Konformität kann mit unterschiedlichen Testmethoden erfolgen (vgl. ISO, 1994). Der für MIP verwendete Ansatz entspricht der sogenannten Remote-Testmethode des OSI Conformance Testing Methodology and Framework (CTMF), die in Abb. 21.1 dargestellt ist. Diese Testmethode berücksichtigt, dass die von MIP vorgegebene Schnittstelle die einzige standardisierte Schnittstelle ist, über die die Implementierung unter Test, d. h. der Anteil des FüInfoSys, der die MIP-Lösung realisiert, geprüft werden kann. Nicht jede funktionale Eigenschaft der MIP-Lösung kann jedoch ausschließlich über den Austausch von MIP DEM-Protokolldatenheiten (engl.: Protocol Data Units; PDUs) getestet werden. Für die Ansteuerung und Beobachtung der zu testenden Implementierung „von oben“ ist ein manueller Eingriff des Testoperateurs erforderlich, da FüInfoSys keine standardisierte Nutzerschnittstelle besitzen. Abbildung 21.1 verdeutlicht zudem, dass die zu testende Implementierung nur als Teil des Gesamtsystems geprüft werden kann und somit z. B. keine einzelnen Schichten bzw. Protokollebenen isoliert untersucht werden können. Konformitätstests können automatisiert mit Hilfe eines Testsystems durchgeführt werden. Dies setzt jedoch voraus, dass die Testspezifikationen in einer formalen Sprache, d. h. in ausführbarer Form vorliegen. Hierzu sind, je nach Art der Tests, geeignete abstrakte Testnotationen zu entwerfen und im Testsystem zu unterstützen. Die Formalisierung der Tests ermöglicht es, automatisiert objektive Testergebnisse zu ermitteln, die für die verschiedenen FüInfoSys vergleichbar sind. Im Rahmen der Entwicklung des MIP Test Reference System (siehe Abschn. 21.4) wurde eine eigene Testsprache definiert und umgesetzt, die auf Java basiert und Konzepte

Konformitätstestsystem

Testoperator Testkoordinierung

Tester

FüInfoSys

(untere Schnittstelle)

(System unter Test) DEMPDUs

TCP-Dienstprimitive

(obere Schnittstelle)

MIPImplementierung unter Test

Kommunikationsnetz (TCP/IP)

Abb. 21.1 Remote-Testmethode

21 Testen der semantischen Interoperabilität

301

der Testing and Test Control Notation 3 (TTCN-3; ETSI, 2008) und von JUnit (Object Mentor, 2009) kombiniert. Die Testsprache und Beispiele sind in (Bau et al., 2008a,b) erläutert.

21.3 Testspezifikationen für Konformitätstests Eine Interoperabilitätslösung umfasst verschiedene technische Aspekte, für die jeweils spezifische Testansätze erforderlich sind. In MIP werden – gemäß der Architektur der MIP-Lösung – Systemtests in drei Kategorien unterteilt, die als System Level Test (SLT) 1 bis 3 bezeichnet werden (MIP, 2007):  SLT1: Test der Kommunikationsprotokolle des MIP Data Exchange Mechanism  SLT2: Test der Replikation von Datenbankinhalten gemäß JC3IEDM  SLT3: Test der korrekten Abbildung operationeller Daten. Darüber hinaus wird anhand des Operational Level Test (OLT) die MIP-Lösung selbst im Kontext eines Szenarios hinsichtlich der an sie gestellten operationellen Anforderungen bewertet. Die Zuordnung der einzelnen Testkategorien zur MIPLösung ist in Abb. 21.2 dargestellt.

21.3.1 Test der Kommunikationsprotokolle (SLT1) Für den Austausch von Informationen sind Protokolle erforderlich, die die Kommunikation zwischen den Partnern regeln. Der in MIP definierte Data Exchange Mechanism (DEM) setzt auf TCP auf und verwendet einen Publish-Subscribe-Ansatz

Abb. 21.2 Zuordnung der Testkategorien zur MIP-Lösung

302

M. Gerz, M. Glauer und N. Bau

mit Punkt-zu-Punkt-Verbindungen. Darüber hinaus existiert ein auf UDP basierender Broadcast-Mechanismus, mit dem ein neues FüInfoSys seine Verbindungsinformationen automatisiert an alle anderen Systeme im LAN mitteilen kann. Netzwerkprotokolle werden üblicherweise in Form von State Charts oder Zustandsübergangstabellen spezifiziert (jeweils für Sender- und Empfängerseite). Liegt eine Protokollbeschreibung in formaler Form vor, können daraus systematisch Testfälle abgeleitet werden. Ziel ist es dabei, eine Implementierung hinsichtlich zweier Fehlermodelle zu prüfen:  Ein Transfer-Fehler tritt auf, wenn bei einem Zustandsübergang die Implementierung einen falschen Zielzustand einnimmt.  Ein Ausgabe-Fehler tritt auf, wenn die Implementierung in einem gegebenen Zustand auf eine bestimmte Eingabe eine falsche Ausgabe erzeugt. Es existieren verschiedene Verfahren auf der Basis (erweiterter) endlicher Automaten, um entsprechende Tests automatisiert aus Protokollspezifikationen abzuleiten (für einen Überblick siehe Schmitt, 2003). Aufgrund der Tatsache, dass die MIPProtokolle als eingebettete Komponenten eines FüInfoSys getestet wurden und zudem keine geeignete Toolunterstützung zur Verfügung stand, wurden diese Tests im Rahmen der MIP-Arbeiten jedoch manuell erzeugt. Darüber hinaus sind weitere Fehlerklassen abzudecken. So ist es notwendig, die Verarbeitung syntaktisch und semantisch fehlerhafter Protokolldateneinheiten zu prüfen, die von den FüInfoSys gemäß Spezifikation zurückzuweisen bzw. zu verwerfen sind. Entsprechende Tests können zum Teil auf Basis der für die Protokolle vorgegebenen Grammatiken erstellt werden. Auch die Anbindung an die unteren Protokollebenen ist zu prüfen. So bereitete es einigen MIP-Systemen zunächst Probleme, DEM PDUs zu verarbeiten, die in Form von mehreren TCP-Paketen empfangen wurden, bzw. TCP-Pakete zu segmentieren, die mehrere DEM PDUs enthielten. Ebenso wichtig sind Tests, mit denen das korrekte Zusammenspiel mehrerer MIP-Gateways geprüft wird. Beispiel: Gateway C abonniert eine operationelle Informationsgruppe von Gateway A, die ihm indirekt via Gateway B bereitgestellt wird. Beendet A nun das Abonnement von B, so muss B ebenfalls das Abonnement von C beenden. Für derartige Tests sind Konfigurationen mit drei MIP-Gateways (System unter Test und 2 Tester-Gateways) notwendig. Für das vom FKIE entwickelte MIP Test Reference System bedeutet dies, dass es zur Laufzeit zwei MIPGateways dynamisch erzeugen muss (vgl. Abb. 21.3).

21.3.2 Datenbank-Replikation (SLT2) Während in SLT1 die Protokolle getestet werden, geht SLT2 auf die übertragenen Inhalte ein. Dabei wird primär geprüft, ob operationelle Daten (gemäß JC3IEDM) hinsichtlich der Regeln des Replikationsverfahrens korrekt ausgetauscht und auf

21 Testen der semantischen Interoperabilität

303

Datenbankebene verarbeitet werden. Die operationelle Bedeutung der Inhalte – sofern diese nicht die Replikation beeinflusst – wird erst im Rahmen von SLT3 ausgewertet. Für den in MIP spezifizierten Publish-Subscribe-Mechanismus werden u. a. folgende Aspekte überprüft:  Partielle Replikation von Datenbankinhalten unter Berücksichtigung semantischer und referenzieller Integrität  Handhabung von Synchronisationspunkten bei der Replikation  Erkennung von syntaktischen und semantischen Fehlern in den operationellen Daten (z. B. fehlerhafte Kompression, Verletzungen der referenziellen Integrität, Wertebereichsverletzungen, unzulässig modifizierte Daten, fehlerhafte Verknüpfung von Daten mit operationellen Informationsgruppen)  Verarbeitung sehr großer und sehr vieler Transaktionen (Lasttests)  Zeitgefilterte Replikation operationeller Daten. Viele der Tests beruhen technisch auf dem Prinzip, dass zunächst eine Menge vorgegebener Testdaten offline in das zu testende FüInfoSys eingelesen wird. Das Testsystem abonniert anschließend eine Informationsgruppe des FüInfoSys, infolge dessen eine genau spezifizierte Teilmenge der Testdaten durch das FüInfoSys repliziert werden muss. Das Testsystem prüft dann auf das Vorhandensein bzw. NichtVorhandensein der testrelevanten Daten in der Datenbank seines eigenen Gateways. Je nach Testfall wird dieser Vorgang mehrmals wiederholt. Dabei kann der Fall eintreten, dass in einem späteren Schritt Daten repliziert werden müssen, die zu einem früheren Zeitpunkt nicht repliziert werden durften, da diese beispielsweise zuvor (noch) keiner Informationsgruppe zugeordnet waren. Im Rahmen von MIP ist eine umfangreiche Sammlung an annotierten Testdaten entstanden, aus denen automatisiert sowohl sogenannte MIP Offline Updates (MOUs) als standardisierte Eingabe für die zu testenden FüInfoSys, als auch entsprechende SQL-Prüfskripte für ein Testsystem abgeleitet werden. Das FKIE hat hierzu ein Konzept und ein entsprechendes Werkzeug entwickelt. Tests zur Erkennung von syntaktischen und semantischen Fehlern in den operationellen Daten können ebenfalls automatisiert abgeleitet werden, wenn ein entsprechendes Metamodell verfügbar ist. So entwickelte Kondev (2008) ein Tool, das auf der Basis des MIP Information Resource Dictionary (MIRD) automatisiert (fehlerhafte) Testdaten für das JC3IEDM generiert. Somit war es u. a. möglich, Tests für unterschiedliche Arten von Integritätsverletzungen direkt aus der MIP-Spezifikation abzuleiten.

21.3.3 Abbildung operationeller Daten (SLT3) Wie bereits in Abschn. 21.1 erläutert, müssen viele FüInfoSys für die Unterstützung eines Interoperabilitätsstandards eine Abbildung der internen Datenstrukturen

304

M. Gerz, M. Glauer und N. Bau

auf semantisch äquivalente Strukturen des Informationsaustauschmodells und umgekehrt vornehmen. Zusätzlich werden in jedem FüInfoSys die Nutzereingaben und -ausgaben und die internen Datenstrukturen aufeinander abgebildet. In SLT3 wird die Korrektheit eben dieser Abbildungen überprüft. Dabei kann das zu testende System sowohl die Rolle eines Datenerzeugers als auch eines Datenempfängers annehmen. Im Falle, dass das FüInfoSys als Datenerzeuger agieren soll, muss der Testoperateur Nutzereingaben am Führungsinformationssystem vornehmen. Das FüInfoSys muss diese Eingaben intern in Datenstrukturen gemäß dem Informationsaustauschmodell (hier: JC3IEDM) umsetzen und die Daten dann an das Testsystem senden. Das Testsystem vergleicht anschließend die empfangenen Daten mit den gemäß Spezifikation erwarteten Daten. Dieser Vergleich ist komplex:  Zum Zeitpunkt der Testspezifikation sind die erwarteten Daten nicht vollständig bekannt, da ein FüInfoSys beispielsweise die Werte für künstliche Schlüssel automatisch zur Laufzeit vergibt. Daher muss die Testbeschreibungssprache es z. B. ermöglichen, Beziehungen zwischen einzelnen Datenelementen unabhängig von konkreten Schlüsselwerten auszudrücken.  Der Testfall darf nicht zu viele Details gleichzeitig testen, sondern sollte sich möglichst nur auf den Testzweck beziehen. Dies bedeutet, dass in Bezug auf die erwarteten Daten nicht alle operationell sinnvollen Felder im Testfall spezifiziert werden dürfen, wenn diese nicht für den Testzweck relevant sind.  Da die Abbildung der operationellen Informationen von der internen Datenstruktur des FüInfoSys auf die Austauschdatenstruktur nicht zwingend rechtseindeutig ist und Informationen u. U. mit unterschiedlicher Granularität verwaltet werden, ist ein FüInfoSys möglicherweise nicht in der Lage, ausschließlich die im Testfall geforderten Daten zu senden. Das Testsystem muss daher die für den Testfall relevanten Informationen aus allen empfangenen Daten herausfiltern. Eine zusätzliche Schwierigkeit besteht darin, dass, je nach verwendetem Replikationsmechanismus, nicht immer eine klare zeitliche Abfolge der Datenübertragung gewährleistet ist. So ist es möglich, dass Informationen, die bereits zu einem früheren Zeitpunkt übertragen wurden, aus Effizienzgründen während der Testdurchführung nicht erneut repliziert oder für den Testfall erwartete Informationen erst zu einem späteren Zeitpunkt übertragen werden. Aus diesem Grund muss der Testfall in der Präambel beschreiben, welche Datenstrukturen in der Datenbank des Testsystems vorhanden sein müssen, bevor der eigentliche Testzweck überprüft werden kann. Die Testauswertung wird daher solange verzögert, bis die entsprechenden Daten vorliegen oder ein Replikationsfehler auftritt. Der eigentliche Test überprüft dann lediglich die Werte der für den Testfall als relevant identifizierten Daten. Das Testsystem sollte neben dem im Testfall formalisierten Testzweck beim Empfang der Daten zusätzlich die Einhaltung aller Integritäts- und Geschäftsregeln implizit überprüfen, um sicherzustellen, dass das zu testende System diese Regeln einhält, auch wenn diese gar nicht im aktuell ausgeführten Test formalisiert sind. Beim Testen des Systems als Datenempfänger muss der Testoperateur verifizieren, dass sein FüInfoSys die vom Testsystem gesendeten Daten korrekt anzeigt. Dies

21 Testen der semantischen Interoperabilität

305

kann, je nach Art der übertragenen Daten, beispielsweise durch den Vergleich eines dargestellten Symbols mit einem Referenzbild geschehen. Diese Art der Testauswertung ist notwendig, wenn man das zu testende System als Black Box betrachtet und keine standardisierte „obere“ Schnittstelle spezifiziert ist (siehe auch Abbildung 21.1 auf Seite 300). Eine weitere Möglichkeit ist der Vergleich der empfangenen bzw. dargestellten Daten mit einer textuellen Beschreibung der ausgetauschten Informationen. Um Tests durchführen zu können, bei denen das FüInfoSys als Empfänger auftritt, müssen entsprechende Testdaten verfügbar sein. Da diese Daten sehr komplex sein können, ist eine manuelle Erstellung zeitaufwändig und fehleranfällig. Das MIP Test Reference System unterstützt die Testspezifikation, indem es für jeden erfolgreichen SLT3-Test, bei dem ein FüInfoSys die Rolle des Datensenders übernimmt, alle relevanten, empfangenen Daten protokolliert. Diese können dann anderen FüInfoSys für Tests in die Gegenrichtung zur Verfügung gestellt werden. So kann ein FüInfoSys die Daten anderer Systeme vom MTRS empfangen und der Testoperateur die Daten mit der textuellen Beschreibung des Testfalls vergleichen.

21.3.4 MIP-Testsuite Das FKIE hat in Zusammenarbeit mit den MIP-Arbeitsgruppen eine umfangreiche Testsuite mit formalen Testskripten erstellt. So können mit dem MIP Test Reference System 107 Protokolltests, 170 Tests für Datenbankreplikation, 321 Tests zur Abbildung operationeller Daten sowie 467 Symboltests, die eine Sonderform der SLT3-Tests darstellen, durchgeführt werden. Im Vergleich zur MIP Baseline 2, für die nur 17 SLT1- und 20 SLT2-Tests zur Verfügung standen, bedeutet dies einen signifikant erweiterten Testumfang. Die große Anzahl an Testfällen wurde durch Verbesserungen des Testmanagements ermöglicht. Ein wichtiger Aspekt ist das Konfigurationsmanagement der Testspezifikationen, da sich Tests aufgrund von Fehlern, aber auch aufgrund von Modifikationen an den zugrunde liegenden Spezifikationen selbst, häufig ändern können. Dies gilt umso mehr für ein Programm wie MIP, bei dem Erkenntnisse aus den Tests unmittelbar in die Entwurfsspezifikationen zurückfließen. Das FKIE hat daher verschiedene Lösungen entwickelt, die das Testmanagement erleichtern und für alle Beteiligen transparenter machen. Eine wesentliche Voraussetzung für den effizienten Umgang mit den MIP-Testspezifikationen war die Einrichtung eines gemeinsamen Repository, in dem alle Testdokumente unter Versionskontrolle gestellt sind (MIP, 2009). Hierdurch war es erstmals möglich, in einem größeren Team an der Erstellung der Testspezifikationen verteilt zu arbeiten und dabei gleichzeitig jede Änderung auf der Ebene einzelner Tests zu identifizieren. Um die Auswirkungen von Testfalländerungen zu beschreiben, werden alle Testskripte mit einer Versionsnummer versehen, die sich aus einer Hauptversionsnummer und einer Nebenversionsnummer zusammensetzt. Die Nebenversionsnummer

306

M. Gerz, M. Glauer und N. Bau

wird immer dann inkrementiert, wenn eine Änderung die erneute Testdurchführung bei zuvor erfolgreichem Testlauf nicht erfordert, aber die Änderung einen Fehler behebt, der in der Vergangenheit möglicherweise zu fehlgeschlagenen Testläufen geführt hat. Die Hauptversionsnummer hingegen wird nur dann erhöht, wenn der Testfall erweitert wurde, sich die Semantik grundlegend geändert hat oder für das erfolgreiche Bestehen striktere Bewertungskriterien eingeführt wurden. Die Evaluation der Versionsnummern wird durch das MIP Test Reference System unterstützt, d. h. der Testoperateur bekommt automatisch alle neu durchzuführenden Testfälle angezeigt. Die Testfallversionierung stellt somit sicher, dass alle FüInfoSys gegen die neuesten Testspezifikationen testen. Die Vollständigkeit einer Testsuite lässt sich üblicherweise anhand verschiedener Abdeckungskriterien bestimmen; bei Black-Box-Tests beziehen sich diese auf die Abdeckung der Spezifikation. Für die in MIP spezifizierten Protokolltests ist dies eine durchaus sinnvolle Herangehensweise, da die Spezifikation der Protokolle in einer semiformalen Notation vorliegt und daher die Abdeckung der laut Spezifikation vorgesehenen Zustände und Zustandsübergänge bestimmt werden kann. Aufgrund der systematischen Erarbeitung der Testfälle ergibt sich für die Protokolltests eine Testabdeckung von 100% aller Zustandsübergänge. Zudem wird das Verhalten der Systeme bei der Kommunikation mit mehreren Systemen gleichzeitig in ausgewählten Szenarien geprüft. Wesentlich schwieriger ist eine konkrete Aussage über die Abdeckung der Replikationstests, da die Regeln des Replikationsmechanismus in textueller Form vorliegen, wodurch eine systematische Ableitung von Testfällen erschwert wird. Eine Aussage über die Abdeckung der verwendeten operationellen Daten hinsichtlich des Datenmodells ist nur in Bezug auf bestimmte Test- oder Fehlerklassen sinnvoll. Für diese ergibt sich dann allerdings eine niedrige Testabdeckung, da – aufgrund der Größe des JC3IEDM – nicht alle Elemente des Datenmodells für jede Fehlerklasse getestet werden können. Stattdessen hat man sich in der Praxis darauf beschränkt, für die identifizierten Test- und Fehlerklassen repräsentative Beispiele zu finden. Für die Abbildungstests (SLT3) ist es einfach möglich, eine Testabdeckung zu ermitteln, da diese Tests auf dem Datenmodell beruhen. Die mehr als 300 vorliegenden Tests decken über 90% aller im JC3IEDM enthaltenen Entitäten ab. Hinsichtlich der Relationen und Attribute ergibt sich eine Abdeckung von ca. 70% bzw. 20%. Um die Verwendung aller Attribute und Relationen zu testen, müsste die Anzahl der Testfälle deutlich erhöht werden. Dabei ist zu beachten, dass einige Attribute Freitexte enthalten, während andere Attribute operationelle und systemtechnische Prozesse beeinflussen und daher detailliert (d. h. auf Ebene einzelner Domänenwerte) getestet werden müssen. In der vorliegenden Testsuite wurde dieser Aspekt entsprechend berücksichtigt. Während der Testdurchführung hat sich gezeigt, dass viele FüInfoSys nicht das gesamte Datenmodell verwenden, da dieses viele operationelle Informationsaustauschanforderungen umsetzt, die nicht in allen Systemen benötigt werden. Damit scheint eine hundertprozentige Abdeckung aller Attribute nicht nur zu einer umfangreichen und komplexen Testsuite zu führen, sondern die zu testenden Systeme

21 Testen der semantischen Interoperabilität

307

hätten auch eine höhere Durchfallquote, ohne dass dadurch zwingend ein Einfluss auf ihre Interoperabilität bestünde. Es stellt sich daher die Frage, wie man die getesteten FüInfoSys bewerten oder vergleichen kann. Hinsichtlich der Kommunikationsprotokolle und des Replikationsverfahrens sollten alle Tests durch ein FüInfoSys bestanden werden, da diese grundlegende und querschnittliche Systemfunktionalitäten überprüfen. Für die Abbildungstests steht man hingegen vor dem Problem, dass ein (operationalisiertes) System nicht alle Aspekte des Datenmodells berücksichtigen muss und daher eine quantitative Aussage bzgl. der (nicht) bestandenen Tests nur geringe Aussagekraft hat. Stattdessen ist es wichtig zu erkennen, welche operationellen Bereiche das FüInfoSys vollständig unterstützt und welche Bereiche nicht oder nur rudimentär unterstützt werden. Dazu ist eine Kategorisierung der vorhandenen Testfälle hinsichtlich operationeller Kriterien (z. B. Befehlsebene, Teilstreitkraft, Truppengattung) erforderlich. Diese ermöglicht nicht nur Aussagen über die Fähigkeiten einzelner FüInfoSys, sondern gibt auch Aufschluss über die Interoperabilität verschiedener Systeme.

21.4 MIP Test Reference System Um die Konformität von FüInfoSys hinsichtlich der MIP-Spezifikation effizient prüfen zu können, hat das FKIE ein entsprechendes Testsystem konzipiert und entwickelt. Ziel ist es, durch eine weitgehende Automatisierung sowohl den Testaufwand zu reduzieren als auch zu objektiven Testergebnissen zu gelangen. Das Testsystem wird seit September 2007 als MIP Test Reference System (MTRS) für die offiziellen MIP System Level Tests eingesetzt. Es wird allen beteiligten Nationen als kostenloser Service bereitgestellt.2

21.4.1 Systemarchitektur Das MIP Test Reference System wurde als Client-Server-Applikation entworfen. Die Architektur des MTRS ist in Abb. 21.3 dargestellt. Der Testoperateur steuert mit Hilfe eines Testclients den zentralen Testserver. Er kann so u. a. Testfälle ausführen und Testergebnisse abrufen. Eine detaillierte Beschreibung des Clients folgt in Abschn. 21.4.3. Der Server gliedert sich konzeptionell in einen Test-Manager, der für die Ausführung und Auswertung der Testfälle und die Verwaltung der Testergebnisse verantwortlich ist, und einen MIP-spezifischen Anteil, der die für den jeweiligen Testfall 2

Das Testsystem testet den Datenaustausch via MIP Data Exchange Mechanism (DEM). Der ebenfalls in MIP eingesetzte Message Exchange Mechanism (MEM), der auf dem Extended Simple Mail Transfer Protocol (ESMTP) beruht, wird nicht unterstützt, da er für den Austausch operationeller Daten in MIP nur noch eine untergeordnete Rolle spielt und sich technisch sehr stark vom DEM unterscheidet.

308

M. Gerz, M. Glauer und N. Bau

Abb. 21.3 Architektur des MTRS

benötigte MIP-Gateway-Funktionalität in feingranularen Komponenten bereitstellt (siehe Abschn. 21.4.2). Ein Nutzermanagement ermöglicht die parallele Ausführung von Testfällen für verschiedene FüInfoSys und von Testfällen für verschiedene Testoperateure des gleichen FüInfoSys, die jeweils über eine eigene Testinstanz des FüInfoSys verfügen. Je nach Testfall sind unterschiedliche Testkonfigurationen erforderlich. Aufgabe des Testmanagers ist es, die im Testskript definierten Testkomponenten zu instanziieren, ihr Verhalten zu steuern, zu kontrollieren und zu synchronisieren sowie die Komponenten nach Beendigung des Testfalls wieder zu beenden. Als Werkzeug für Konformitätstests betrachtet das Testsystem die zu testenden FüInfoSys als eine Black Box, die mit Eingaben angesteuert und deren beobachtete Antworten über die MIP-Schnittstelle mit dem gemäß Testspezifikation zu erwartenden Verhalten verglichen werden. Der Austausch zwischen dem MTRS-Server und den nationalen FüInfoSys erfolgt somit ausschließlich über die MIP-Schnittstelle. Während der Testausführung ist es in der Regel erforderlich, bestimmte NutzerAktionen am FüInfoSys anzustoßen. Hierbei kann es sich z. B. um die Einrichtung eines Abonnements für eine bestimmte operationelle Informationsgruppe oder das Erzeugen eines militärischen Objekts über die grafische Oberfläche handeln. Ferner kann es notwendig sein, die Anzeige des FüInfoSys abzufragen, um das Testergebnis zu ermitteln. Da für diese Aktionen keine standardisierten Schnittstellen in den FüInfoSys vorhanden sind, sendet der Testserver während der Testausführung Aktionsanforderungen an den Testclient. Nach entsprechender Rückmeldung durch den Testoperateur wird die Testausführung fortgesetzt. Unter Nutzung der Programmierschnittstelle (API) des MTRS ist es möglich, diese manuellen Schritte durch ein nationales, einfach aufgebautes Testwerkzeug durchführen zu lassen, das das zu testende FüInfoSys über eine proprietäre Schnitt-

21 Testen der semantischen Interoperabilität

309

stelle oder über seine grafische Oberfläche steuert. Diese Möglichkeit nutzte eine Nation, um ihre Regressionstests vollautomatisch auszuführen. Für die Durchführung der MIP-Tests wurde am FKIE ein zentraler Host mit einem MTRS-Server eingerichtet, auf den alle MIP-Nationen (bzw. deren Testoperateure) parallel zugreifen können. Dieser Ansatz bietet zahlreiche Vorteile:  Die Integrität der Testfälle und Testergebnisse wird durch eine zentrale Datenhaltung sichergestellt. Eine versehentliche oder absichtliche Änderung ist nicht möglich.  Da die Testergebnisse FüInfoSys-übergreifend vorliegen, ist es möglich, für die Testkoordinatoren Berichte zu erstellen, aus denen der aktuelle Stand aller Systeme und der Fortschritt der Testaktivitäten hervorgeht.  Änderungen am Testmanager, den MIP-Gateway-Komponenten und den Testfällen müssen nur auf einer Maschine vorgenommen werden; eine Verteilung der Software an die einzelnen Nationen ist nicht erforderlich. Bei häufigen Änderungen an den Entwurfsspezifikationen bedeutet dies eine deutliche Erleichterung.  Die Installation und Konfiguration des Servers sowie die Archivierung der Datenbanken muss nicht durch die einzelnen Nationen vorgenommen werden. Dies reduziert den Administrations- und Betreuungsaufwand.

21.4.2 MIP-Gateway-Komponenten Zur Implementierung der für die Tests benötigten MIP-Gateway-Funktionalitäten wurde eine modulare Architektur aus feingranularen Komponenten entworfen. Je nach Testfall können somit unterschiedliche funktionale Elemente eines oder mehrerer MIP-Gateways miteinander verknüpft werden. Beispielsweise ist bei Tests der DEM-Protokolle die Nutzung einer JC3IEDM-Datenbank nicht notwendig. Der modulare Ansatz ermöglicht es ferner, syntaktisch und semantisch ungültige oder inopportune Daten auf jeder Ebene zu erzeugen und an das FüInfoSys zu senden. Bei der Entwicklung der MIP-Komponenten mussten eine Reihe von Faktoren berücksichtigt werden, die spezifisch für die Anforderungen eines Testsystems sind. So werden sämtliche Protokoll-Informationen – ggf. auch für mehrere MIPGateways – pro Testfallausführung zentral im Testmanager zusammengefasst. Potentiell können Tests für mehrere FüInfoSys parallel auf dem Testserver durchgeführt werden. Für die MIP-Komponenten bedeutet dies, dass sie keine global definierten Elemente referenzieren dürfen. Ferner ist es notwendig, zur Laufzeit effizient neue Instanzen von JC3IEDM-Datenbanken generieren und diese ggf. am Ende eines Testfalls wieder löschen zu können.

21.4.3 Testclient Bei der Entwicklung des Clients wurde auf eine intuitive und leicht bedienbare Nutzerschnittstelle geachtet. Abbildung 21.4 zeigt einen Screenshot der grafischen

310

M. Gerz, M. Glauer und N. Bau

Abb. 21.4 MTRS-Testclient

Oberfläche. Die Benutzerschnittstelle präsentiert eine hierarchische Übersicht über alle verfügbaren Testgruppen, Testfälle und ausgeführten Testläufe. In dieser Übersicht wird der aktuelle Stand der Testaktivitäten durch Farben und Symbole angezeigt und auf Testgruppen-Ebene aggregiert. Zudem werden für einen ausgewählten Testfall Metainformationen wie z. B. Name, Version und Testzweck angezeigt. Für jeden Testlauf werden der Status (laufend, beendet, abgebrochen etc.), das Testurteil, die Testdauer und zahlreiche weitere Informationen präsentiert. Zusätzlich werden für jeden Testlauf sämtliche Status-Informationen der einzelnen MIP-Gateway-Komponenten auf dem MTRS-Server sowie der Datenfluss zwischen den Komponenten als Sequenzdiagramm oder als zeitlich geordnete Tabelle dargestellt. Mit Hilfe der angezeigten Abläufe innerhalb der MIP-Gateways ist es im Falle eines fehlgeschlagenen Tests möglich, eine detaillierte Fehleranalyse durchzuführen. Der MTRS-Client ist weitgehend generisch und enthält keine Softwareanteile eines MIP-Gateways. Das bedeutet, dass z. B. für die Ausgabe der oben genannten Datenflüsse keine Metainformationen über die verfügbaren Gateway-Komponenten und die ausgetauschten Meldungen benötigt werden. Auch die Schnittstelle zum Testserver und der Testmanager selbst sind – soweit möglich – unabhängig von der MIP-Spezifikation. Dies ermöglicht es prinzipiell, den Client und Teile des Servers auch für andere Projekte einzusetzen. Darüber hinaus muss nicht bei jeder Ände-

21 Testen der semantischen Interoperabilität

311

rung der MIP-Spezifikation bzw. der Gateway-Implementation eine neue Version des MTRS-Clients verteilt werden. In Anlehnung an OSI CTMF unterstützt das MTRS die Testurteile pass (bestanden), fail (fehlgeschlagen) und inconclusive (unentscheidbar). Letzteres zeigt an, dass das FüInfoSys sich zwar gemäß MIP-Spezifikation korrekt verhalten hat, aber der eigentliche Testzweck nicht erfüllt wurde. Dieser Fall kann z. B. bei Netzwerkproblemen eintreten oder wenn der Testoperateur den Test frühzeitig abbricht. Darüber hinaus wird ein Testfall/Testlauf als outdated gekennzeichnet, wenn er auf einer veralteten Version des Testscripts beruht (vgl. Abschn. 21.3.4). Da die zu testenden FüInfoSys über sehr unterschiedliche Fähigkeiten verfügen, kann es sein, dass nicht alle Testfälle bestanden werden können. Der Testoperateur hat daher zusätzlich die Möglichkeit, einen Test als not implemented zu markieren. Um die in Abschn. 21.3.4 beschriebene Kategorisierung von Testfällen zu ermöglichen, können letztere im MTRS mit Schlüsselwörtern annotiert werden. Im MTRS-Client ist der Nutzer dadurch in der Lage, die in der Testsuite nach technischen Gesichtspunkten hierarchisch gruppierten Testfälle hinsichtlich operationeller oder anderer Kriterien zu filtern. So können z. B. alle SLT3-Tests ausgewählt werden, die Systemfähigkeiten testen, welche für das Szenario des MIP Operational Level Test relevant sind. Um die Auswertung der Testergebnisse durch die einzelnen Nationen zu unterstützen, wurden in den MTRS-Client Export-Funktionen für die Generierung von PDF- und XML-Dokumenten integriert. Die Testoperateure sind darüber hinaus in der Lage, zu einzelnen Tests einen Kommentar abzugeben, um so beispielsweise auf einen vermeintlichen Fehler im Testskript hinzuweisen. Bei Änderungen an der Testspezifikation werden sie automatisch informiert.

21.5 Zusammenfassung und Ausblick Das MIP Test Reference System wurde Ende August 2007 veröffentlicht und steht seitdem allen an MIP beteiligten Nationen für Tests zur Verfügung. Die offiziellen MIP System Level Tests haben im September 2007 über das Internet begonnen. Bis Januar 2009 haben bereits 23 FüInfoSys aus 19 Nationen das MTRS für Tests genutzt. Die gesamte Nutzungsdauer betrug dabei über 8.600 Stunden. In dieser Zeit wurden mehr als 51.000 Tests durchgeführt, wobei in Spitzenzeiten bis zu 10 Systeme gleichzeitig mit dem MTRS getestet wurden. Dank seiner Verfügbarkeit rund um die Uhr, der Möglichkeit, mehrere Systeme parallel zu testen, und des hohen Grads der Automatisierung konnten Tests in einem bislang nicht gekannten Umfang durchgeführt werden. Während der Implementierung des MTRS und der anschließenden Testphase wurden zahlreiche Problemfelder in den Entwurfsspezifikationen identifiziert. Die Möglichkeit, noch während der Tests auf die Entwicklung der Spezifikationen Einfluss zu nehmen, hat deutlich zur Stabilität der MIP-Lösung für Baseline 3 beigetragen.

312

M. Gerz, M. Glauer und N. Bau

Infolge der kontinuierlichen Verbesserungen der Entwurfspezifikationen waren zwangsläufig Änderungen an den in Entwicklung befindlichen Systemen erforderlich. Es wurde daher untersucht, welchen Störeinfluss Änderungen an der MIPSpezifikation und Korrekturen an den MIP-Testdokumenten/-testdaten haben. Hierzu wurden die Testergebnisse der einzelnen FüInfoSys ausgewertet. Unter Berücksichtigung der jeweils genutzten Testfallversion ergibt sich, dass – je nach Interpretation der Daten – zwischen 83,5% und 92,7% der Tests erfolgreich waren oder auf Fehler in den FüInfoSys selbst hindeuteten. Dies bedeutet, dass die regelmäßigen Änderungen an den (Test-)Spezifikationen letztlich einen akzeptablen Mehraufwand für die Testoperateure verursachten. Dank des MTRS konnten die Testzeiten für die einzelnen FüInfoSys von den starren Zeitplänen für die bi- und multilateralen Interoperabilitätstests entkoppelt werden. Zukünftig wird es möglich sein, noch in Entwicklung befindlichen oder geplanten Systemen eine geeignete Testumgebung zur Verfügung zu stellen. Konformitätstests mit Hilfe eines Testwerkzeugs sind sowohl in den frühen Phasen der Entwicklung, in denen die Systeme noch nicht ausgereift sind, als auch für die spätere, automatisierte Durchführung von Regressionstests sehr hilfreich. Interoperabilitätstests sollten jedoch ergänzend durchgeführt werden, da in den FüInfoSys, die gemeinsam im Einsatz genutzt werden sollen, möglicherweise sehr unterschiedliche operationelle Anteile der Gesamtspezifikation umgesetzt sind und aufgrund der Komplexität der zugrunde liegenden Spezifikationen nicht alle Aspekte erschöpfend getestet werden können. Die Auswertung der Konformitätstests – durch Gruppierung von Tests nach operationellen Kriterien – bietet aber zukünftig die Möglichkeit, Fähigkeitsmatrizen zu erstellen.

Literaturverzeichnis Bau, N., Gerz, M., & Glauer, M. (2008a). Ensuring interoperability of command and control information systems – new ways to test conformance to the MIP solution. Journal of Telecommunications and Information Technology, (2), 5–13. Bau, N., Gerz, M., & Glauer, M. (2008b). Testing C2 Interoperability – Advancements in Testing of the MIP Baseline 3 Solution. In Proceedings of the 13th International Command and Control Research and Technology Symposium (ICCRTS) Bellevue, WA, USA. ETSI – European Telecommunications Standards Institute (2008). ES 201 873-1 – Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN-3 Core Language; Version 3.4.1. http://www.ttcn-3.org/. ISO – International Organization for Standardization & IEC – International Electrotechnical Commission (1994). International Standard 9646: Information technology – Open Systems Interconnection – Conformance testing methodology and framework. Parts 1 to 7. ISO/IEC, Geneva, Switzerland. Kondev, S. (2008). Konzeption und Implementierung eines Testdatengenerators für das JC3IEDM. Abschlussarbeit im Bachelor Studiengang im Fachbereich Informatik, Fachhochschule BonnRhein-Sieg, Sankt Augustin. MIP – Multilateral Interoperability Programme (2006). MIP Standard Briefing. http://www. mip-site.org. MIP – Multilateral Interoperability Programme (2007). MIP Test and Evaluation Master Plan (MTEMP). Edition 3.2. http://www.mip-site.org.

21 Testen der semantischen Interoperabilität

313

MIP – Multilateral Interoperability Programme (2008b). MIP Technical Interface Design Plan (MTIDP), Edition 3.8. http://www.mip-site.org. MIP – Multilateral Interoperability Programme (2008c). The Joint C3 Information Exchange Data Model. Edition 3.1d. http://www.mip-site.org. MIP – Multilateral Interoperability Programme (2009). Test Repository. https://trac.fkie.fgan.de/ MTRS/wiki/Repository (26.01.2009). Myers, G. J. (2004). The Art of Software Testing. John Wiley & Sons Inc., 2. edition. Object Mentor (2009). Junit.org. http://junit.org/ (26.01.2009). Schmitt, M. (2003). Automatic Test Generation Based on Formal Specifications – Practical Procedures for Efficient State Space Exploration and Improved Representation of Test Cases. Dissertation zur Erlangung des Doktorgrades, Georg-August-Universität zu Göttingen, Göttingen. Schmitt, M. (2005). Integration of the MIP Command and Control Information Exchange Data Model into National Systems. In 10th International Command and Control Research and Technology Symposium (10th ICCRTS) McLean, Virginia, USA.

Sachverzeichnis

Interoperabilität, semantische

23

abaXX-Portal 129 Abbild, mentales 129 Ada 15 ADatP-3 5, 125, 194, 237, 251 Aggregation 135, 139, 250 Aktionen, formale Repräsentation von 170 Analyse, flache syntaktische 169 Analyse, inhaltliche 167 Analyse, morphologische 173 Analyse, semantische 168 Anforderungsprofil 130 Annotation 175 AOI siehe Area of Interest APP-11 194 APP-6A 251 Architekturrahmenwerke 205, 206 Area of Interest 100, 272 Artillery Systems Cooperation Activities 200 ASCA siehe Artillery Systems Cooperation Activities asymmetrische Kriegsführung 19 ATCCIS 15, 220 Aufklärungszentrale 126 Aufklärungszyklus 129, 137, 247 Auftragsmanagement 125, 135, 138, 146 Ausbildungskonzept 6 Authentizität 258, 287 Battle Management Language 235 Bedeutungserschließung 167 Bedeutungsraum 174 Bildbeschreibungssprache 260 BML siehe Battle Management Language BML-Standard 237

C2IEDM siehe Command and Control Information Exchange Data Model, 220 C2LG siehe Command and Control Lexical Grammar CAESAR 270 CCIRM 268 CliCC siehe Collaboration in Command and Control Coalition Ground Picture 269 Coalition Networks for Secure Information Sharing 280 Coalition Shared Database 130 Coalition Warrior Interoperability Demonstration 197, 263, 274 Collaboration in Command and Control 274 Command and Control Information Exchange Data Model 197, 199 Command and Control Lexical Grammar 239 CommandTalk 168 Common Relevant Operational Picture 252 Computerlinguistik 167, 239, 241 CoNSIS siehe Coalition Networks for Secure Information Sharing CPM siehe Customer Product Management CROP siehe Common Relevant Operational Picture CSD siehe Coalition Shared Database Customer Product Management 211 CWID siehe Coalition Warrior Interoperability Demonstration Dari 168 Dari-Deutsch-Wörterbuch 173 Data Exchange Mechanism 199, 222, 298 Datenabbilddung 202 Datenbank Einsatz 123, 254, 261

315

316 Datenfilterung 99 Datenfusion 275 Datenkategorie 89 Datenmodell, s. auch JC3IEDM 24 Datenverarbeitungsunterstützung Zentrale Militärisches Nachrichtenwesen 127, 264 DBEins siehe Datenbank Einsatz DEM siehe Data Exchange Mechanism Department of Defense Architecture Framework 209 DoDAF siehe Department of Defense Architecture Framework Dokumentenmanagement 130 Doppler-Blindheit 277 Dual Stack 283 DVU ZMilNW siehe Datenverarbeitungsunterstützung Zentrale Militärisches Nachrichtenwesen EIGER siehe Experimentelles FührungsInformationssystem auf der Grundlage Eines Rechnernetzes Einsatztagebuch 121 Einsatzunterstützungssystem 132 Electronic Support Measures 269 EMFIS siehe Experimentelles Militärisches FührungsInformationsSystem Entitäten, formale Repräsentation von 170 Entitäten-Aktivitäten-Netzwerk 168, 174 Entity-Relationship-Modell 219 Entscheidungsunterstützungskomponente 235 ESM siehe Electronic Support Measures ETB siehe Einsatztagebuch Experimentelles FührungsInformationssystem auf der Grundlage Eines Rechnernetzes 13 Experimentelles Militärisches FührungsInformationsSystem 10 Extensible Markup Language 174, 259 Fähigkeitslücke 6, 117 Führungsinformationssystem Streitkräfte 124, 248 Führungsportal 129 FüInfoSys SK siehe Führungsinformationssystem Streitkräfte FEAF siehe Federal Enterprise Architecture Framework Feature-Modellierung 260 Federal Enterprise Architecture Framework 209 Filterfunktion 100, 250

Sachverzeichnis Frame-Elemente 172 FrameNet-Projekt 172 Frames, semantische 172 GATE 169 Gazetteer 170 Gebietsmanager, Datenfilterung 104 Gemeinsames Rollenorientiertes EinsatzLagebild 72, 129, 252 Genehmigungsprozess 121, 127, 138 Geography Markup Language 259 GeoInfoServer 128 georeferenzierte Elemente 100 Gesamtarchitektur 130 Geschäftsprozess 120 Global Positioning System 102 Globaler Informationsraum 99 GML siehe Geography Markup Language GMTI siehe Ground Moving Target Indicator GPS siehe Global Positioning System Grammatik 171, 238–242 Graphical User Interface 59, 61, 72 GREL siehe Gemeinsames Rollenorientiertes EinsatzLagebild Ground Moving Target Indicator 269 Gruppenkommunikation 121 GUI siehe Graphical User Interface Heterogenität 59 High Level Architecture 230 HLA siehe High Level Architecture HMTI siehe Hoch-Mobiles Taktisches Intranet Hoch-Mobiles Taktisches Intranet 286, 292 Human Language Technology 167 IAGFA siehe Integrierte Arbeitsgruppe Fähigkeitsanalyse IDEF-0 213 IDEF1X 223 INFIS siehe Integrationsplattform für FührungsInformationsSysteme Informationsbeziehungen 107 Informationsersuchen siehe Request for Information, 144 Informationsextraktion 167, 168 Informationsfilterung 99 Informationsgruppe, Integrationsportal 63 Informationslücke 143 Informationsraum 99 inhaltliche Analyse 167 INSC siehe Interoperable Networks for Secure Communications

Sachverzeichnis Integrationsplattform für FührungsInformationsSysteme 16 Integrationsportal 61 Integrierte Arbeitsgruppe Fähigkeitsanalyse 6 Integrität 287 Intelligence 130, 267 Intelligenz, maschinelle 121 Interessengebiet, Datenfilterung 100 Internet-Protokoll 279 Interoperabilität 20, 117, 131, 136, 144, 237, 248, 261 Interoperabilität, pragmatische 25 Interoperabilität, syntaktische 23 Interoperabilitätsstufen 20 Interoperabilitätstest 299 Interoperable Networks for Secure Communications 280 IntPortal siehe Integrationsportal IP siehe Internet-Protokoll IPv4/6-Migrationsrahmenkonzept 284 IPv6-Migration 284 IraqComm-System 168 IT-Sicherheit 287 IT-System Bw 217 JASMIN 124 JC3IEDM 5, 24, 125, 199, 219, 238, 243, 298 Joint and Combined Operations 4 Kabul Multinational Brigade 127 KdB siehe Konzeption der Bundeswehr Kernspeicher 8 KFOR-Einsatz 168 KFOR-Korpus 175 KMNB siehe Kabul Multinational Brigade Konformitätstest 300 Kontext, Lage- 253 Kontext, sprachlicher 237 Kontexttaxonomie 253 Kontingentwechsel 120 Konzeption der Bundeswehr 116, 247 Koordinierungsprozess 121 Lagebearbeitung 124, 248, 250 Lagedarstellung 250 Lagefeststellung 124, 130 Lagevortag zur Unterrichtung 131 Lagevortrag zur Vorbereitung einer Entscheidung 131 LC2IEDM 220 Linguistik 167, 236, 239, 241 LISI-Referenzmodell 249

317 Lizenzmanagement 5 Lochkarte 8 LVE siehe Lagevortrag zur Vorbereitung einer Entscheidung LVU siehe Lagevortag zur Unterrichtung MAJIIC 128, 130, 268 Mapping 202 MDA siehe Model-Driven Architecture Mediation 202 Meldewesen Bundeswehr 123 Meldungsauswertung 124 Merkmalsstrukturen, typisierte 169 Message Text Format 194 Middleware-Plattform 129 Military Intelligence 256 Military Message Handling System 199 Military Situation Description Language 258 Ministry of Defence Architecture Framework 209 MIP siehe Multilateral Interoperability Programme MIP Test Reference System 298 MMHS siehe Military Message Handling System MoDAF siehe Ministry of Defence Architecture Framework Model-Driven Architecture 230 Modeling and Simulation 235 Modell, mentales 120 Modell, mentales 249 morphologische Analyse 173 MSDL siehe Military Situation Description Language MTF siehe Message Text Format MTRS siehe MIP Test Reference System Multicast 280 Multilateral Interoperability Programme 5, 16, 102, 125, 198, 219, 238, 252, 298 Multilingualität 167 Multiobjekt-Tracking 277 Multisensordatenfusion 275 Nachrichtengewinnung und Aufklärung 117, 247 NAF siehe NATO Architecture Framework Named-Entities 170 Namenserkennung 171 NATO Architecture Framework 209 NATO Corporate Data Model 220 NATO Friendly Force Information 196 NATO Interoperability Directive 21, 211, 215

318 NCDM siehe NATO Corporate Data Model NCW siehe Network Centric Warfare NetOpFü siehe Vernetzte Operationsführung Network Centric Warfare 19 NFFI siehe NATO Friendly Force Information NG&A, NGuA siehe Nachrichtengewinnung und Aufklärung NID siehe NATO Interoperability Directive Object Constraint Language 228 Object Management Group 229 Objektidentifikator (OID) 87 Objektnetz 88 OCL siehe Object Constraint Language OGC siehe Open Geospatial Consortium OIG siehe Operationelle Informationsgruppe OMG siehe Object Management Group Ontologie 170 Open Geospatial Consortium 259 Operational View 217 Operationelle Informationsgruppe 199, 222, 298 Operationszentrale 128, 248 OTH-T GOLD 197 PDU siehe Protocol Data Unit Phasendokumente 6 Phraselator 168 PKI siehe Public Key Infrastructure Portal, Portaltechnologie 59 Positionsänderung, Auswirkung 107 Produktdatenbank 144 Projekt SOKRATES 168 Projekt ZENON 169 Protocol Data Unit 300 Prozessmodell 136, 141, 147, 208 Prozesssteuerung 130 Public Key Infrastructure 290 Rechercheverfahren 125, 135 Rechtekonzept 122, 138 Reconnaissance 267 Region, Datenfilterung 104 Relevanzkontext 253 Reliabilität 258 Request for Information 125, 135, 144, 274 Ressourcen, externe 140 Ressourcendatenbank 143 Ressourcenkoordination 141 RFI siehe Request for Information Rolle, semantische 172 Rollenkonzept 122, 136, 138

Sachverzeichnis SAR siehe Synthetic Aperture Radar Schlüsselmanagement 287 Selektionsverfahren 124 Semantik 169 semantische Analyse 168, 241 Service-Funktion, Integrationsportal 64 Service-Instanz 48, 103 Serviceorientierte Architektur 131, 218, 238, 260 Situationsbewertung 249 Situationsbewusstsein 99, 121, 248, 265 Skalierbarkeit 7 SOA siehe Serviceorientierte Architektur SOKRATES-Projekt 168 Sprachen, selten gelehrte 167 Sprachverarbeitung 167 StAN 226 STANAG 2014 222, 241 STANAG 2149: Request for Information 144 Stufen der Interoperabilität 20 Surveillance 267 syntaktische Analyse 169 Syntax 169 Synthetic Aperture Radar (SAR) 269 System of Systems 3, 267 Tadschikisch 176 TEAF siehe Treasury Enterprise Architecture Framework Termsubstitution 173 Texte, militärische 167, 168 Textinhaltserschließung 127, 167 thematische Rollen 241 Time Sensitive Targeting 274 TOGAF 209 Track 268 Tracking Algorithmen 276 Transducer 172 Transformationsprozess 116, 126 Translation 283 Treasury Enterprise Architecture Framework 209 Tunneling 283 Übersetzung, Wort-zu-Wort- 170 Übersetzungshilfe 173 UML siehe Unified Modeling Language Unified Modeling Language 220, 231 Unternehmensarchitekturen 205 V-Modell 211 V-Objekt, Integrationsportal Verb-Phrasen 171

63

Sachverzeichnis Verlegefähige Access-Netze 284 vernetzte Elemente 99 Vernetzte Operationsführung 2, 19, 83, 99 Versionsmanagement 5 Visualisierungskomponenten 72 Wörterbuch 173 Web Feature Service 260 Web Information Services Environment 129 Web-Service 125, 196, 197 WebSphere Portal Server (WPS) 129 WFS siehe Web Feature Service Wirkungsbereich von Einheiten oder Waffensystemen 101 WISE siehe Web Information Services Environment Wissensdatenbank 125, 131 Wissensmanagement 115, 119 Wissensverarbeitung 126

319 Workflowmanagement 115, 136 WPS siehe WebSphere Portal Server Wrapper, Integrationsportal 63 XML siehe Extensible Markup Language XML Stylesheet Language Transformation 259 XML Stylesheet Transformation 170, 174 XML-MTF 196 XSLT siehe XML Stylesheet Language Transformation Zachman Framework 208 ZDv 1/11 251 Zeichenorientierter Informationsaustausch 193 ZENON-System 168 Zerlegung des Einsatzgebietes 104, 108