Die meisten militärischen Ausbildungsveranstaltungen bringen bessere Kommandeure und leistungsfähigere Einheiten nur dann hervor, wenn die in der Übung angelegten Lehren tatsächlich extrahiert, verstanden und bewahrt werden. Doch der traditionelle After-Action-Review-Prozess ist genau bei diesem Extraktionsschritt schwer beschädigt. Beobachter rekonstruieren Ereignisse aus handgeschriebenen Notizen von Stunden zuvor. Die Teilnehmer erinnern, was sie tun wollten, statt was sie taten. Kommandeure, die in einem Schlüsselmoment schlecht entschieden haben, beschreiben die Entscheidung, die sie gern getroffen hätten — ohne bewusste Täuschung: Das menschliche Gedächtnis rekonstruiert tatsächlich, statt wiederzugeben. Das Ergebnis ist ein Debriefing, das in kollektiver Fiktion statt in Fakten verankert ist und aus dem Lehren gezogen werden, die dem tatsächlichen Geschehen mehr oder weniger entsprechen.

After-Action-Review-Software (AAR) ersetzt die Erinnerung durch einen faktischen Datensatz. Indem die Plattform Ereignisse während der Übung automatisch erfasst — Entity-Positionen aus Simulationsdatenströmen, Waffeneinsätze und Trefferereignisse von instrumentierten Schießplätzen, Zeitstempel der Inject-Übermittlung aus den mobilen Werkzeugen der Observer-Controller —, erzeugt sie eine präzise Zeitlinie, die der Debriefing-Moderator mit jeder Geschwindigkeit abspielen, zu jedem Moment springen, auf jede Einheit oder jeden Ereignistyp filtern und in Echtzeit mit Findings annotieren kann. Die Debriefing-Diskussion ist in dem verankert, was tatsächlich geschah. Entscheidungspunkte werden sichtbar. Lücken zwischen geplanten und tatsächlichen Handlungen werden quantifiziert statt strittig gemacht. Und Lehren, die während der Sitzung erfasst werden, fließen direkt in das führende Lessons-Learned-System ein, statt in einem Berichtsdokument zu verschwinden, das niemand liest.

Dieser Artikel behandelt den vollständigen Fähigkeitsstapel von AAR-Software: Architekturen der Ereigniserfassung, Zeitlinien-Replay und Entity-Wiedergabe, strukturierte Debriefing-Durchführung, Entscheidungsanalyse, Übermittlung von Lessons Learned an JLLIS sowie die besonderen Überlegungen, die für verteilte Übungen an mehreren Orten gelten.

Der AAR-Zyklus in der militärischen Ausbildung — strukturierte Phasen, formal versus informell

Der After-Action-Review ist eine formale Ausbildungsmethodik, nicht bloß eine Debriefing-Diskussion. Die US-Heeresdoktrin (FM 7-0) und entsprechende Publikationen der Verbündeten definieren das AAR als strukturierten Prozess mit vier getrennten Phasen, die der Reihe nach abzuschließen sind: durchgehen, was geplant war; feststellen, was geschah; analysieren, warum es geschah; und bestimmen, was künftig anders gemacht wird. Jede Phase erfüllt eine eigene Funktion, und das Zusammenziehen oder Überspringen von Phasen erzeugt genau die oberflächlichen Debriefings, die Soldaten durchweg als Zeitverschwendung erkennen.

Die Phase was geplant war legt die gemeinsame Baseline fest, an der die tatsächliche Leistung gemessen wird. Der Moderator stellt den ursprünglichen Befehl, die Absicht des Kommandeurs und das Manöverkonzept vor — nicht aus dem Gedächtnis, sondern aus den tatsächlichen Planungsunterlagen. Diese Phase wird oft unterschätzt, weil die Teilnehmer annehmen, sie erinnerten den Plan. Tun sie nicht. Zeitdruck, Stress und der Nebel der Durchführung verzerren die Erinnerung an den Plan innerhalb von Stunden nach Übungsende. Das erneute Vorstellen des ursprünglichen Befehls und des Manöverkonzepts stellt sicher, dass der spätere Vergleich zwischen Plan und Ausführung von einer akkuraten Baseline ausgeht.

Die Phase was geschah ist der Punkt, an dem AAR-Software ihren deutlichsten Nutzen liefert. Die Plattform spielt die tatsächlichen Ereignisse der Übung ab — Entity-Positionen, Waffenereignisse, Kommunikation, Inject-Übermittlungen und Beobachtungen der Observer-Controller — auf einer synchronisierten Zeitlinie. Die Teilnehmer sehen, was die Übung tatsächlich aufgezeichnet hat, nicht was sie erinnern. Diese Phase muss dem Drift zur Diskussion widerstehen: Die Aufgabe des Moderators ist es, den faktischen Datensatz festzustellen, bevor die Analyse beginnt. Voreilige Analyse in dieser Phase erzeugt durchweg Rechtfertigung statt ehrlicher Bewertung.

Die Phase warum es geschah ist der analytische Kern des AAR. Mit dem feststehenden faktischen Datensatz arbeitet der Moderator jedes Schlüsselereignis durch und identifiziert die ursächlichen Faktoren: die verfügbaren Informationen, die getroffene Entscheidung, die daraus folgende Handlung und wie diese Handlung im Vergleich zu den Doktrinstandards und der Absicht des Kommandeurs abschnitt. Hier sind Werkzeuge der Entscheidungsanalyse — die dem Moderator erlauben, das Replay in einem kritischen Moment anzuhalten und die Informationsumgebung zu untersuchen, die in diesem Augenblick bestand — am unmittelbarsten nützlich.

Die Phase was künftig anders gemacht wird wandelt Analyse in umsetzbare Ergebnisse. Jede identifizierte Lücke erzeugt ein spezifisches Finding: eine Empfehlung, verknüpft mit einer verantwortlichen Organisation, einem Zieltermin und einer Einordnung der Art der nötigen Änderung — eine Änderung der TTP der Einheit, eine Anpassung des Ausbildungsplans, eine Ausstattungsanforderung oder ein Vorhaben, das an die Lessons-Learned-Stelle eines übergeordneten Hauptquartiers eskaliert werden muss. Dieser strukturierte Output unterscheidet ein produktives AAR von einer Diskussion, die keine dauerhafte Veränderung bewirkt.

Die Militärdoktrin unterscheidet formale AARs und informelle AARs. Formale AARs finden nach bedeutenden Ausbildungsveranstaltungen statt — Gefechtsübungen auf Brigadeebene, scharfe Schießen auf Bataillonsebene, Stabsübungen — und erfordern eigene Moderation, Replay-Infrastruktur und strukturierte Ergebnisse. Informelle AARs folgen kürzeren Ereignissen — einer Gruppenpatrouille, einer Besatzungsqualifikation, einer Planungsübung — in einem vereinfachten Vier-Fragen-Format ohne Replay-Werkzeuge. AAR-Software unterstützt in erster Linie formale AARs. Leichte mobile Werkzeuge jedoch, mit denen Observer-Controller strukturierte Beobachtungen im Feld erfassen und die ein zusammenfassendes Ereignisprotokoll für die informelle Auswertung erzeugen, erweitern den Nutzen der Plattform auch auf den informellen Kontext.

Automatisierte Ereigniserfassung während Übungen — DIS/HLA-Recorder-Integration, Positions- und Ereignis-Zeitlinie aus der Live-Instrumentierung, Video-Zeitstempelung

Der faktische Datensatz, der ein replaybasiertes AAR ermöglicht, wird während der Übung aufgebaut, nicht danach. Die Ereigniserfassung muss kontinuierlich, passiv und umfassend sein — der Recorder muss jedes Ereignis erfassen, unabhängig davon, ob jemand, der die Übung beobachtet, es für bedeutsam hält. Bedeutsamkeit wird im Debriefing bestimmt; der Recorder kann dieses Urteil nicht vorab treffen.

Bei simulationsbasierten Übungen ist die primäre Datenquelle die Simulationsföderation. Übersicht militärischer Simulationsplattformen behandelt die großen Simulationsarchitekturen ausführlich; die Rolle des AAR-Recorders ist in jeder von ihnen die eines passiven Zuhörers im Datenaustauschnetz. In einer Distributed-Interactive-Simulation-Umgebung (DIS) — IEEE 1278 — abonniert der Recorder die Multicast-Adresse der Übung und erfasst jede gesendete Protocol Data Unit (PDU): Entity-State-PDUs, die alle fünf Sekunden (oder bei Zustandsänderung) Position, Orientierung und Geschwindigkeit jedes Entity übermitteln; Fire-PDUs, die jeden Waffeneinsatz aufzeichnen; Detonation-PDUs, die jedes Trefferereignis aufzeichnen; sowie Collision-, Logistics-, Signal- und Transmitter-PDUs, die unterstützende Ereignisse erfassen. In einer High-Level-Architecture-Umgebung (HLA) — IEEE 1516 — tritt der Recorder der Föderation als passiver Federate bei, der alle relevanten Objektklassen und Interaktionsklassen abonniert.

Das rohe PDU- oder HLA-Interaktionsprotokoll ist die führende Datenquelle. Aus diesem Protokoll baut das AAR-System strukturierte Ereignistabellen: Positionsspuren jedes Entity, interpoliert in festem Zeitschritt; diskrete Ereigniseinträge für jedes Fire/Detonation-Paar, verknüpft über die Entity-ID der Munition; und Zeitlinieneinträge für jede Signal- und Logistikinteraktion. Dieser Verarbeitungsschritt ist rechenintensiv, wird aber offline nach Übungsende ausgeführt und muss daher nicht in Echtzeit laufen.

Für live instrumentierte Ausbildungsumgebungen — Schießplätze mit GPS-basierten Kräfte-gegen-Kräfte-Systemen, Laser-Erfassungssets oder instrumentierten Zielen — sind die Datenquellen andere, doch das Integrationsprinzip bleibt dasselbe. Der Daten-Server des Schießplatzes sendet Positionsupdates und Gefechtsereignisse über eine LAN-Schnittstelle. Der AAR-Recorder abonniert diesen Feed und erfasst dieselben Datenkategorien wie der Simulationsrecorder: Positionsspuren, Waffeneinsatzereignisse und Verlustbeurteilungen. Werden mehrere Schießplatzsysteme gleichzeitig genutzt — etwa eine Live-Virtual-Constructive-Übung, die physische Truppen auf einem Schießplatz mit virtuellen Fahrzeugbesatzungen in Simulatoren und konstruktiven Kräften in einer Simulation verbindet —, muss der Recorder Ströme aus mehreren Quellen zu einer einzigen synchronisierten Zeitlinie zusammenführen. Das erfordert Zeitstempelabgleich über Uhrquellen hinweg, der verwaltet wird, indem für jede Quelle ein globaler Zeitabgleich-Offset der Übungsuhr gepflegt wird.

Die Video-Zeitstempelung fügt dem quantitativen Ereignisprotokoll eine qualitative Ebene hinzu. Kameras der Observer-Controller und feste Schießplatzkameras erzeugen Videostreams, die beim Aufzeichnen gegen die Übungsuhr gestempelt werden. Das AAR-System verknüpft Videosegmente mit der Ereignis-Zeitlinie, sodass der Moderator von einer Replay-Positionsspur zur Kamerabildaufnahme desselben Moments springen kann. Das ist besonders wertvoll, wo die quantitativen Daten einen Ausgang verzeichnen — ein Fahrzeug stoppte seine Bewegung —, das Video aber die Ursache zeigt — die Besatzung verließ das Fahrzeug und suchte Deckung —, die die Simulation nicht abbildete.

Zeitlinien-Replay und Entity-Wiedergabe — 2D/3D-kartenbasiertes Replay, Geschwindigkeitssteuerung, Entity-Filteransichten, Ereignis-Annotationsoverlay

Das Zeitlinien-Replay ist das visuelle Herzstück der AAR-Software. Moderator und Teilnehmer sehen die Übung auf einer Kartenanzeige ablaufen, mit Entity-Symbolen, die sich mit vom Moderator gesteuerter Geschwindigkeit entlang ihrer aufgezeichneten Spuren bewegen. Das Replay muss flüssig genug sein, um die Dynamik des Gefechts zu vermitteln, steuerbar genug, um an Schlüsselmomenten anzuhalten, und filterbar genug, um die Elemente zu isolieren, die für die aktuelle Phase der Debriefing-Diskussion relevant sind.

Die Karten-Basisdarstellung ist typischerweise eine 2D-Gefechtskartenanzeige — eine digitale Geländedarstellung in einem für das Übungsgebiet passenden Maßstab, mit militärischer Standardkartenzeichenung (MIL-STD-2525) für die Entity-Symbole. Die Geländeanzeige sollte der Referenzkarte entsprechen, die die Teilnehmer während der Übung nutzten, damit sie sich orientieren können, ohne eine neue Karte zu erlernen. Für die Luftstreitkräfte, die Artillerie und bestimmte verbundene Übungen bietet eine 3D-Umgebungsansicht — Entities in einem dreidimensionalen Geländemodell — zusätzliche Klarheit über die Lage. Die Plattform sollte sowohl 2D- als auch 3D-Ansichten unterstützen und dem Moderator erlauben, ohne Unterbrechung der Replay-Sitzung zwischen ihnen zu wechseln.

Die Geschwindigkeitssteuerung erlaubt dem Moderator, das Replay mit komprimierten Zeitverhältnissen zu fahren — 2x, 4x oder 8x Echtzeitgeschwindigkeit —, um rasch durch Phasen geringer Aktivität zu kommen, und auf 0.5x oder 0.25x zu verlangsamen, um die detaillierte Dynamik eines schnell bewegten Gefechts zu untersuchen. Eine Pause ist jederzeit verfügbar, und der Moderator kann in einem Gefecht mit hohem Tempo Schritt für Schritt durch die Entity-Positionen gehen, um den genauen Moment zu bestimmen, in dem eine Einheit eine Phasenlinie überschritt, eine Waffe eingesetzt wurde oder eine Formation den Kontakt löste.

Entity-Filteransichten erlauben dem Moderator, spezifische Teilmengen der Gesamtmenge der Entities isoliert anzuzeigen. Übliche Filter sind: Einheitsbezeichnung (nur die dem 2. Bataillon zugewiesenen Einheiten der Blauen Kräfte zeigen), Entity-Typ (nur Radfahrzeuge zeigen), Zeitfenster (Positionen nur zwischen H+2 und H+4 zeigen) und Ereignistyp (nur Waffeneinsatzereignisse zeigen). Filterkombinationen erlauben dem Moderator, exakt das Bild darzustellen, das zum aktuellen Debriefing-Thema gehört — etwa den Logistikfluss zu einem vorgeschobenen Unterstützungsbereich —, ohne die Anzeige mit irrelevanten Entities aus anderen Einheitsbereichen zu überladen.

Der Ereignis-Annotationsoverlay zeigt die strukturierten Ereignisse aus dem Ereignisprotokoll als kartenüberlagerte Marker: Orte der Inject-Übermittlung, Beobachtungspunkte der OC, Ursprungsorte von Waffeneinsätzen und Trefferpunkte. Jeder Marker ist zeitkodiert und mit seinem Ereigniseintrag verknüpft. Ein Klick auf einen Marker in der Replay-Anzeige öffnet den vollständigen Ereigniseintrag — den Inject-Text, die OC-Beobachtungsnotiz, die Kette des Waffeneinsatzes —, ohne die Kartenansicht zu verlassen. Moderatoren können eigene Annotationsebenen hinzufügen: etwa eine geplante Phasenlinie neben die tatsächlichen Einheitspositionen zeichnen, damit die Lücke zwischen Plan und Ausführung für die Teilnehmer unmittelbar sichtbar wird.

Strukturierte Debriefing-Durchführung — Folienerzeugung aus Ereignisdaten, Workflows zum Kennzeichnen von Problemen, Annotationswerkzeuge für Teilnehmer

Das Debriefing-Modul der AAR-Software verbindet die technische Replay-Fähigkeit mit dem Ausbildungsprozess. Ein Replay-Werkzeug ohne Durchführungsstruktur artet in eine Zusammenstellung der Höhepunkte der Übung aus, statt eine produktive Lernveranstaltung zu sein. Das Durchführungsmodul erzwingt Struktur, erfasst Findings in Echtzeit und erzeugt Ergebnisse, die nach dem Ende der Sitzung fortbestehen.

Die automatisierte Folienerzeugung extrahiert Schlüsselereignisdaten aus dem Übungsprotokoll und erzeugt ein strukturiertes Briefing-Paket für den Moderator. Das Standardpaket umfasst: eine Zeitlinienübersicht mit allen bedeutsamen Ereignissen in chronologischer Reihenfolge, Zusammenfassungen der Einheitspositionen zu Schlüsselzeitpunkten der Übung, Statistiken zur Abdeckung der Ausbildungsziele (welche Ziele ausgelöst wurden, wie oft und mit welchem Ergebnis) sowie eine Liste der Ereignisse, die Observer-Controller während der Übung mit Lesezeichen versehen haben. Dieses Paket entsteht automatisch binnen Minuten nach Übungsende und gibt dem Moderator einen strukturierten Ausgangspunkt statt einer leeren Präsentation, die von Grund auf neu zu bauen wäre.

Der Workflow zum Kennzeichnen von Problemen erlaubt dem Moderator und den teilnehmenden Beobachtern, Ereignisse während der Replay-Sitzung als Findings zu markieren. Jede Markierung erfasst: die Ereigniszeit, die betroffene Einheit, die Finding-Kategorie (Stärke, Verbesserungsbereich, Sicherheitshinweis, systemisches Problem), das verknüpfte Ausbildungsziel und eine Textbeschreibung. Das Markieren ist auf Tempo ausgelegt — ein Tastenkürzel oder ein Tipp auf einen Touchscreen —, sodass der Moderator den Diskussionsfluss nicht unterbricht, um ein Finding festzuhalten. Markierungen sammeln sich in einer Findings-Liste, die während der Sitzung in einer Seitenleiste sichtbar ist und nach dem Ende der Sitzung die Grundlage des Lessons-Learned-Exports bildet.

Annotationswerkzeuge für Teilnehmer erlauben den Teilnehmern selbst, während der Sitzung Beobachtungen beizutragen. In einem formalen AAR steuert der Moderator das Replay und führt die Diskussion, doch Teilnehmer können im Replay Dinge sehen, die der Moderator übersehen hat. Eine Teilnehmer-Annotationsschnittstelle — typischerweise eine Tablet-Anwendung, die alle Teilnehmer während der Sitzung nutzen — erlaubt ihnen, ein Ereignis in ihrer eigenen Replay-Ansicht anzutippen und eine Anmerkung in die Warteschlange des Moderators zu senden. Der Moderator prüft eingehende Anmerkungen und entscheidet, ob er sie in die Haupt-Diskussion des Debriefings einbindet oder zur Offline-Verfolgung vermerkt.

Analyse der Entscheidungspunkte — verzweigendes Replay, geplante versus tatsächliche Handlungen der Einheit, kontrafaktische Exploration

Die Analyse der Entscheidungspunkte ist die analytisch ergiebigste Fähigkeit der AAR-Software und diejenige, die dem Lernziel der militärischen Ausbildung am unmittelbarsten dient. Es genügt nicht zu zeigen, dass das Handeln einer Einheit vom Plan abwich — wirksame Ausbildung verlangt, dass der Kommandeur die Informationsumgebung versteht, die zum Zeitpunkt der Entscheidung bestand, warum er die getroffene Entscheidung fällte und welche Folgen eine alternative Entscheidung gehabt hätte.

Der Moderator identifiziert Entscheidungspunkte während der Replay-Vorbereitungsphase und versieht jeden mit einer kurzen Moderatorennotiz, die den Entscheidungskontext beschreibt. In der Sitzung führt der Moderator das Replay bis kurz vor den Entscheidungspunkt und hält an. Die Plattform zeigt die Informationsumgebung dieses exakten Moments: die Einheitspositionen, die dem Kommandeur auf Grundlage des Aufklärungsbildes jener Zeit sichtbar waren (nicht die wahren Entity-Positionen, die auch Entities einschließen, die die Einheit des Kommandeurs noch nicht erfasst hatte), die bis zu diesem Punkt eingegangenen Meldungen und Befehle sowie den Fernmeldeverkehr der vorangegangenen Minuten. Diese Sicht der Informationsumgebung unterscheidet die Entscheidungsanalyse vom einfachen Replay — sie zeigt, was der Kommandeur wissen konnte, nicht nur, was geschah.

Der Vergleich geplanter und tatsächlicher Handlungen der Einheit wird durch Overlay-Anzeigen unterstützt, die das ursprüngliche Manöverkonzept — Phasenlinien, Angriffsachsen, zugewiesene Ziele — neben die tatsächlichen Entity-Spuren legen. Die Abweichung zwischen geplanten und tatsächlichen Positionen wird je Zeitschritt quantifiziert: die Distanz zwischen geplanter und tatsächlicher Position für jede Einheit zu jedem Schlüsselzeitpunkt der Übung. Diese Quantifizierung verwandelt die Aussage „wir waren zu langsam auf dem Weg zum Ziel“ in „zum Zeitpunkt H+2 lag die 1. Kompanie 1.8 km hinter der geplanten Phasenlinie“ — eine spezifische, messbare Aussage, die schwerer zu bestreiten und gezielter anzugehen ist.

Die kontrafaktische Exploration erlaubt dem Moderator, „Was-wäre-wenn“-Fragen mit rechnerischer Unterstützung zu stellen. An einem verzweigenden Entscheidungspunkt kann der Moderator eine hypothetische alternative Entscheidung einführen — der Kommandeur fordert statt des Manövers einen Feuerauftrag an —, und die Simulation entwickelt von diesem Zustand aus weiter und zeigt den wahrscheinlichen Ausgang unter der Alternative. Das erfordert die Integration einer live laufenden Simulationsinstanz statt einer rein aufgezeichneten Wiedergabe und ist daher eine fortgeschrittenere Fähigkeit, die nicht alle AAR-Plattformen besitzen. Wo verfügbar, ist sie besonders wirksam für die Ausbildung von Kommandeuren in der Feuerunterstützungsplanung, der Wegwahl und den Timing-Entscheidungen der Logistik, wo die Folgen von Alternativen quantifizierbar sind.

Diese Fähigkeit integriert sich naturgemäß in Architekturen des Live-Virtual-Constructive-Trainings, bei denen die Simulationsumgebung der Übung auf einen historischen Zustand zurückgesetzt und mit veränderten Eingaben weitergeführt werden kann — das ermöglicht eine echte kontrafaktische Ausführung statt einer ungefähren Schätzung des alternativen Ausgangs.

Erfassung von Lessons Learned und JLLIS-Integration — AAR-Findings in Lessons-Learned-Einträge überführen, Übermittlungs-Workflow, Validierung und Genehmigung

Ein Lessons-Learned-Finding ist nicht dasselbe wie eine AAR-Beobachtung. Eine Beobachtung beschreibt, was geschah. Ein Lessons-Learned-Finding umfasst eine Beobachtung, eine Analyse, warum es geschah, eine Empfehlung, was sich ändern soll, eine verantwortliche Organisation, die die Änderung umsetzt, und einen Zieltermin für die Behebung. Die Unterscheidung ist wichtig, weil Beobachtungen ohne Analyse und Empfehlung keinen institutionellen Wandel bewirken können — sie werden abgelegt und vergessen.

AAR-Software unterstützt die Erfassung von Lessons Learned durch ein strukturiertes Finding-Formular, das Vollständigkeit erzwingt. Der Moderator kann ein Finding nicht übermitteln, ohne alle Pflichtfelder zu füllen: Beobachtungstext, Diskussion (die Analyse der Ursachen), Empfehlung, verantwortliche Organisation, Zieltermin zur Behebung, Einordnung in der fachlichen Taxonomie und die Verknüpfung mit mindestens einem Ausbildungsziel. Diese Erzwingung verhindert das verbreitete Fehlerbild eines AAR, das eine Liste von Beobachtungen ohne Analyse oder umsetzbare Empfehlungen erzeugt.

Das Joint Lessons Learned Information System (JLLIS) ist das führende System des US-Verteidigungsministeriums für Lessons Learned über alle Teile der Streitkräfte hinweg. Es wird vom Joint Staff J7 betrieben und ist allen US-Teilstreitkräften, den Kampfkommandos und vielen Verbündeten zugänglich. JLLIS nutzt ein definiertes Datenschema für Lessons-Learned-Einträge, und AAR-Software, die JLLIS integriert, kann Findings direkt in diesem Schema exportieren, statt eine manuelle Neuerfassung zu verlangen. Der Integrations-Workflow ist:

  1. Der Moderator vervollständigt und genehmigt Findings in der AAR-Software während oder unmittelbar nach der Sitzung.
  2. Eine genehmigende Stelle — typischerweise der Ausbildungsoffizier der Einheit oder der Übungsleiter — prüft die Findings und kennzeichnet sie als zur Übermittlung genehmigt.
  3. Die AAR-Software erzeugt eine Exportdatei im JLLIS-Schema, die alle genehmigten Findings enthält.
  4. Der Export wird über die autorisierte Übermittlungsschnittstelle an JLLIS übertragen (typischerweise ein Webdienst-Endpunkt im klassifizierten Netzwerk).
  5. JLLIS vergibt Verfolgungsnummern für jedes übermittelte Finding und benachrichtigt die verantwortliche Organisation über den ihr zugewiesenen Maßnahmenpunkt.
  6. Die verantwortliche Organisation aktualisiert den Status des Findings in JLLIS im Zuge der Umsetzung der Empfehlung, mit einem abschließenden Validierungseintrag, sobald die Änderung in einer Folgeübung verifiziert wurde.

Die Validierungs- und Genehmigungsebene innerhalb von JLLIS stellt sicher, dass Lehren nicht einfach übermittelt und vergessen werden. Jedes Finding durchläuft einen Workflow mit definierten Zuständen: übermittelt, in Prüfung, zugewiesen, in Bearbeitung, behoben und validiert. Die Validierung — die Bestätigung, dass die empfohlene Änderung umgesetzt wurde und das Problem nicht mehr auftritt — erfordert Nachweise aus einer Folgeübung und schließt damit die Ausbildungsrückkopplung über Übungszyklen hinweg.

Für Einheiten, deren Ausbildungsprogramm über eine Plattform für militärische Ausbildungsmanagementsysteme geführt wird, kann der JLLIS-Export durch einen direkten Feed in das Ausbildungsmanagementsystem ergänzt werden, das den Ausbildungsplan der Einheit auf Grundlage identifizierter Lücken automatisch aktualisiert — Ausbildungsveranstaltungen priorisiert, die die Ziele adressieren, bei denen im AAR Lücken festgestellt wurden.

AAR-Software für verteilte Übungen — föderiertes AAR über mehrere Orte, bandbreiteneffiziente Telemetrie-Aggregation, ferngesteuerte Debriefing-Durchführung

Verteilte Übungen — bei denen sich teilnehmende Einheiten an verschiedenen geografischen Orten befinden, teils über Staatsgrenzen hinweg — bringen Datenaggregations- und Durchführungsherausforderungen mit sich, die AAR-Software architektonisch lösen muss.

Die Datenaggregationsherausforderung entsteht, weil Ereignisdaten gleichzeitig an mehreren Orten erzeugt werden. Jeder Übungsknoten — ein Simulationszentrum in einer Stadt, ein Gefechtsstand an einem vorgeschobenen Ort, ein Simulatorstandort — erzeugt seinen eigenen Datenstrom. Das AAR-System muss diese Ströme zu einem einzigen synchronisierten Ereignisprotokoll zusammenführen, Zeitstempelunterschiede zwischen Uhren auflösen, die womöglich nicht perfekt synchron sind, und den Fall behandeln, dass eine Netzpartition während der Übung bewirkt, dass die Daten eines Knotens ungeordnet oder mit Lücken eintreffen.

Bandbreiteneffiziente Telemetrie-Aggregation ist unverzichtbar für verteilte Übungen über Weitverkehrs-Netzverbindungen mit begrenzter Bandbreite. Entity-Positionsdaten sind der voluminöseste Strom: Eine Simulation mit 500 Entities, die Entity-State-PDUs in 5-Sekunden-Intervallen sendet, erzeugt rund 1.5 Mbps an rohem PDU-Verkehr. Für entlegene Orte, die über Satellitenverbindungen mit 256 kbps angebunden sind, ist das nicht machbar. Zwei Kompressionstechniken beheben das. Die Dead-Reckoning-Unterdrückung übermittelt ein Positionsupdate nur, wenn die tatsächliche Position der Entity erheblich von dem abweicht, was die Fortschreibung des zuletzt gemeldeten Geschwindigkeitsvektors der Entity über die Zeit vorhersagen würde — eine Entity, die sich geradlinig mit konstanter Geschwindigkeit bewegt, erzeugt womöglich nur alle 60-90 Sekunden ein Positionsupdate statt alle 5. Die ereignisgesteuerte Übertragung gilt diskreten Ereignissen (Waffeneinsatz, Logistiktransaktionen), die unmittelbar beim Auftreten übermittelt werden statt in festem Takt.

Die ferngesteuerte Debriefing-Durchführung erlaubt Teilnehmern an verschiedenen Orten, an derselben AAR-Sitzung teilzunehmen, ohne physisch beisammen zu sein. Der AAR-Server hostet eine gemeinsame Replay-Sitzung: Der Moderator steuert die Wiedergabe, und alle verbundenen Teilnehmer sehen dieselbe synchronisierte Kartenanzeige. Eine Sprach- oder Videokonferenzverbindung läuft parallel, sodass die Teilnehmer während des Debriefings sprechen können. Das Teilnehmer-Annotationswerkzeug funktioniert so wie in einer Sitzung am selben Ort — ein Teilnehmer an einem entfernten Standort sendet eine Anmerkung über seinen lokalen Client, und sie erscheint in der Warteschlange des Moderators am Hauptort.

Die größte Durchführungsherausforderung in einem verteilten Debriefing ist die Steuerung der Beteiligung physisch verteilter Gruppen, deren zwischenmenschliche Dynamik der Moderator nicht unmittelbar beobachten kann. Bewährte Praxis ist, an jedem entfernten Standort einen lokalen Ko-Moderator zu benennen, der die lokale Beteiligung lenkt — er stellt sicher, dass entfernte Teilnehmer zu Wort kommen, signalisiert, wenn ein lokaler Teilnehmer einen Beitrag leisten will, und erfasst lokale Beobachtungen, die den Hauptmoderator über den Anmerkungskanal womöglich nicht erreichen. Der lokale Ko-Moderator verwaltet auch die lokale Technik — er stellt sicher, dass die gemeinsame Replay-Sitzung korrekt angezeigt wird und die Audioqualität für eine wirksame Teilnahme ausreicht.

Die verteilte AAR-Architektur ermöglicht auch die asynchrone Auswertung: Teilnehmer, die an der live gehaltenen Debriefing-Sitzung nicht teilnehmen konnten, greifen nach der Sitzung über die AAR-Plattform auf die aufgezeichnete Wiedergabe und das Anmerkungsprotokoll zu. Sie können eigene Beobachtungen hinzufügen und Findings zur Prüfung durch den Ausbildungsoffizier der Einheit markieren. Asynchrone Teilnahme ist kein Ersatz für die moderierte Live-Sitzung, doch sie erweitert den Nutzen des Replay-Protokolls auf Teilnehmer, die zum Debriefing-Zeitpunkt nicht verfügbar waren, und stellt sicher, dass deren Perspektive — die Beobachtungen von Einheitspositionen enthalten kann, die der Moderator in der Live-Sitzung nicht behandelte — in den Lessons-Learned-Eintrag eingeht.