Live-virtual-konstruktive (LVC) Integration für die Verteidigungsausbildung

Großangelegte kollektive Ausbildung — die Art, die Brigadestäbe darauf vorbereitet, Feuer, Manöver und Logistik über ein multidomänes Gefechtsfeld hinweg zu synchronisieren — kann mit realen Kräften allein nicht kosteneffizient durchgeführt werden. Live-Übungen verbrauchen Munition, verschleißen Fahrzeuge und erfordern die Dekonfliktierung von Tausenden von Quadratkilometern Luft- und Bodenraum. Virtuelle Simulatoren komprimieren die Geographie und eliminieren Verbrauchskosten, können jedoch die Reibung, Kommunikationslatenz und körperliche Erschöpfung realer Operationen nicht replizieren. Konstruktive Simulation skaliert kostengünstig auf Divisions- oder Korpsgröße, aber die generierten Entitäten sind computergesteuerte Abstraktionen, keine Soldaten. Jede Domäne erfasst einen Teil des Ausbildungsbildes. Live-virtual-konstruktive (LVC) Integration versucht, alle drei in einer einzigen kohärenten synthetischen Umgebung zu kombinieren — und gibt dem Ausbildungspublikum eine realistische Kombination aus realen Kräften, bemannten Simulatoren und computergenerierten Entitäten gleichzeitig. Die Architektur, die das ermöglicht, ist Gegenstand dieses Artikels.

Was live, virtuell und konstruktiv jeweils bedeutet

Die Begriffe werden durch den Grad der Human-in-the-Loop-Operation definiert. Live bedeutet, dass echte Menschen echtes Gerät in der physischen Umgebung bedienen. Ein Panzerzug, der M1A2s auf einem Truppenübungsplatz fährt, ist ein Live-Element. Instrumentierung — GPS-Tracker, Waffenwirkungssimulatoren wie MILES, Sprechfunkgeräte — ermöglicht es dem Übungskontrollsystem, zu beobachten und aufzuzeichnen, was Live-Elemente tun, aber die Kräfte selbst sind physisch präsent. Live-Elemente sind der Goldstandard für individuelle und besatzungsebene Ausbildungsrealismus; sie sind teuer und schwer skalierbar.

Virtuell bedeutet, dass ein menschlicher Bediener mit einer simulierten Plattform innerhalb eines Simulators interagiert. Der Bediener ist real und übt echte kognitive und prozedurale Fähigkeiten, aber Plattform und Umgebung sind synthetisch. Steel Beasts Pro PE, Prepar3D und Flugmissionsimulatoren sind virtuelle Umgebungen. Virtuelle Elemente sind pro Ausbildungsstunde weniger teuer als Live-Elemente, können Plattformen darstellen, die selten oder in Wartung sind, und können sofort in jeden Szenariozustand zurückgesetzt werden. Ihre Einschränkung besteht darin, dass die simulierte Physik und die Sensormodelle, so detailliert sie auch sein mögen, immer noch Annäherungen sind.

Konstruktiv bezeichnet computergenerierte Entitäten, die durch Software gesteuert werden — KI, skriptgesteuerte Verhaltensmodelle oder menschliche Übungsleiter, die als aggregierte Kräfte agieren. Für jede Entität ist kein einzelner Mensch in der Schleife. OneSAF, JCATS und WARG sind konstruktive Simulationssysteme. Konstruktive Simulation skaliert auf Korps-Ebene mit Zehntausenden von Entitäten zu einem Bruchteil der Kosten äquivalenter Live- oder virtueller Kräfte. Der Kompromiss ist eine reduzierte Realismus auf der Ebene der einzelnen Entität und eine reduzierte Auseinandersetzung mit dem Ausbildungspublikum bei Aufgaben, die echte kognitive Belastung durch die gegnerische Kraft erfordern.

LVC-Integration kombiniert alle drei. Eine Brigadeübung könnte ein Live-Infanteriebataillon auf einem echten Übungsgelände haben, virtuelle Drehflügler-Besatzungen, die simulierte Hubschrauber von einer Simulationsanlage aus fliegen, und eine konstruktive OPFOR in Regimentsstärke, deren Verhalten von einem kleinen Übungsleitungsteam gesteuert wird. Der Ausbildungswert der kombinierten Umgebung übertrifft das, was jede einzelne Domäne bieten könnte: das Live-Bataillon steht unter taktisch kohärentem Druck durch eine große, realistisch verhaltende konstruktive OPFOR, koordiniert mit virtueller Luftunterstützung, die nahezu in Echtzeit auf Bodenereignisse reagiert.

Die Interoperabilitätsherausforderung

Die Kombination der drei Domänen ist architektonisch nicht trivial, da jede Domäne unabhängig entwickelt wurde und unterschiedliche Protokolle, Zeitbasen und Entitätsmodelle verwendet. Reale Kräfte kommunizieren über LINK 16, VMF, NFFI (NATO Friendly Force Information) oder Cursor on Target (CoT) Feeds von Instrumentierungssystemen. Virtuelle Simulatoren sprechen typischerweise DIS (Distributed Interactive Simulation, IEEE 1278) oder HLA (High Level Architecture, IEEE 1516). Konstruktive Simulationssysteme sprechen HLA — üblicherweise die RPR-FOM (Real-time Platform Reference Federation Object Model) Variante — oder TENA (Test and Training Enabling Architecture) in Bereichsinstrumentierungskontexten.

Drei Interoperabilitätslücken machen LVC-Integration in der Praxis schwierig. Die erste ist Protokollheterogenität: Eine LINK 16 Track-Nachricht und ein HLA RPR-FOM EntityState-Attribut-Update repräsentieren konzeptionell dasselbe (Position und Zustand einer militärischen Entität), aber in völlig unterschiedlichen Binärformaten, mit unterschiedlicher Feldsemantik und über unterschiedliche Transportmechanismen. Ein Gateway muss zwischen ihnen übersetzen, ohne Informationen zu verlieren oder Mehrdeutigkeiten einzuführen.

Die zweite Lücke ist Latenz-Mismatch. Ein Live-GPS-Track von einem instrumentierten Fahrzeug aktualisiert sich mit 1 Hz. Ein virtueller Panzersimulator aktualisiert seinen Entitätszustand mit 20–30 Hz und verwendet Dead-Reckoning zwischen Aktualisierungen. Eine konstruktive Simulation, die in Echtzeit läuft, kann Entitätspositionen mit variablen Raten aktualisieren, je nach Entitätsaktivität. Wenn diese Feeds in einer gemeinsamen synthetischen Umgebung ankommen, müssen die Entitätspositionen kohärent gemischt werden — ein Live-Fahrzeug, das sich mit 1 Hz aktualisiert, wird zu springen scheinen, wenn seine Position einfach mit der Live-Aktualisierungsrate weitergeleitet wird, anstatt mit Dead-Reckoning-Extrapolation geglättet zu werden, die mit dem Zeitschritt der Simulation konsistent ist.

Die dritte Lücke ist Entitätsidentität. Derselbe physische Panzer, der in der Live-Domäne erscheint, von der Bereichsinstrumentierung verfolgt wird, von einer virtuellen Simulator-Besatzung dargestellt wird und als konstruktive Entität für das Bewusstsein der gegnerischen Kraft repliziert wird, muss über alle Domänen hinweg korrekt als einzelne Entität identifiziert werden — nicht als drei separate Entitäten, die zufällig denselben Ort einnehmen. Identitätsmanagement über Domänengrenzen hinweg, insbesondere wenn Entitäten während einer Übung zwischen Live- und konstruktiver Darstellung wechseln, ist einer der fehleranfälligsten Aspekte der LVC-Architektur.

HLA als LVC-Backbone

HLA (High Level Architecture, IEEE 1516) ist der dominante Föderationsstandard für die Verbindung von LVC-Komponenten, da es die Dienste bereitstellt, die zur Verwaltung einer Multi-Föderaten-Simulationsumgebung im großen Maßstab benötigt werden. Das HLA-Protokoll selbst wird separat ausführlich behandelt; hier liegt der Fokus darauf, wie HLA speziell in einem LVC-Kontext funktioniert.

In einer LVC-Föderation tritt jede Hauptkomponente — das konstruktive Simulationssystem, jede virtuelle Simulatorseite und jeder Gateway-Adapter für Live-Kraft-Feeds — als Föderierter in die HLA-Föderation ein. Die RTI (Run-Time Infrastructure) verwaltet die Kommunikation zwischen Föderatenbeteiligten über das FOM (Federation Object Model) der Föderation, typischerweise basierend auf SISO's RPR-FOM 2.0 für NATO-Interoperabilität.

Föderationsmanagement behandelt den Übungslebenszyklus: Föderationserstellung, Föderatenbeitritt und -austritt, Synchronisationspunkte (zur Koordination von Szenariostart, -pause und -neustart über alle Komponenten hinweg) und Föderationsauflösung. In einer mehrstandörtigen LVC-Übung sind Synchronisationspunkte kritisch — ohne sie kann ein Föderant mit dem Vorrücken der Szenariozeit beginnen, während ein anderer noch initialisiert, was den Entitätszustand über die Grenze hinweg korrumpiert.

Zeitmanagement in einer LVC-Föderation ist typischerweise als Best-Effort-Echtzeit konfiguriert statt als strikte zeitgesteuerte Simulation, da Live-Kräfte nicht pausiert oder verlangsamt werden können, um Time-Advance-Grants zu berücksichtigen. Die RTI läuft im Echtzeitmodus; konstruktive und virtuelle Föderaten veröffentlichen zeitgestempelte Aktualisierungen, halten aber den Föderations-Time-Advance nicht für spät eintreffende Live-Daten an. Das bedeutet, dass die konstruktiven und virtuellen Komponenten gelegentlich außer Reihenfolge ankommende Entitätszustandsaktualisierungen von Live-Gateways tolerieren müssen.

Data Distribution Management (DDM) ist im LVC-Maßstab unerlässlich. Eine Übung auf Korps-Ebene kann Tausende von Entitäten in einem geografischen Bereich von Hunderten von Kilometern umfassen. Ohne DDM empfängt jeder Föderant jede Entitätszustandsaktualisierung — eine Bandbreiten- und Verarbeitungsbelastung, die Gefechtsstandsimulatoren überfordern würde, die nur an einem taktischen Radius von 50 km interessiert sind. DDM-Abonnementregionen, die dem operativen Interessenbereich jedes Föderanten entsprechend konfiguriert sind, reduzieren dies auf ein handhabbares Volumen.

DIS in LVC: weiterhin relevant für virtuelle Komponenten

Trotz der architektonischen Vorteile von HLA ist DIS (IEEE 1278) in LVC-Umgebungen weiterhin präsent, da eine große Installationsbasis virtueller Simulatoren nativ DIS spricht und nicht kosteneffizient in HLA re-integriert werden kann. Steel Beasts Pro, viele ältere Flugsimultoren und ältere Übungstools für Gefechtsstände wurden für DIS-Umgebungen entwickelt. Ihr Ersatz ist in den meisten Programmbudgets nicht realisierbar.

Die Lösung ist eine DIS-zu-HLA-Brücke: ein Gateway, das im DIS-Multicast-Netzwerk als DIS-Teilnehmer und gleichzeitig als HLA-Föderant partizipiert und DIS-PDUs in RPR-FOM Entitätszustandsaktualisierungen übersetzt und umgekehrt. Die Brücke muss die semantischen Unterschiede sorgfältig behandeln. DIS Entity State PDUs verwenden Dead-Reckoning-Algorithmen (im Standard definiert) zur Positionsglättung zwischen Aktualisierungen; die Brücke muss dasselbe Dead-Reckoning auf eingehende DIS-Daten anwenden, bevor sie in HLA veröffentlicht werden, um Positionsunstetigkeiten zu vermeiden. Die Brücke muss auch DIS-Entitätstyp-Codes (die eine hierarchische Aufzählung gemäß SISO ENUM-70 verwenden) auf HLA RPR-FOM EntityType-Attribute abbilden — Nichtübereinstimmungen bei der Entitätstypkodierung führen dazu, dass konstruktive OPFOR virtuelle freundliche Plattformen falsch klassifiziert.

PDU-Ratenverwaltung ist ein praktisches Anliegen. Eine DIS-Umgebung mit 200 virtuellen Simulatoren, die jeweils mit 30 Hz publizieren, erzeugt 6.000 PDUs pro Sekunde im Multicast-Netzwerk. Die DIS-zu-HLA-Brücke muss dies mit Deadband-Schwellwerten filtern — nur Aktualisierungen weiterleiten, wenn Position, Geschwindigkeit oder Orientierung einen definierten Schwellenwert überschreiten — um die HLA-Föderation nicht mit Aktualisierungen zu sättigen, die unwesentliche Bewegungen darstellen.

LVC-Gateway-Architektur

Die Gateway-Schicht ist architektonisch die kritischste und fehleranfälligste Komponente einer LVC-Integration. Ein Gateway passt eine Live-Datenquelle — LINK 16, NFFI, CoT, Bereichsinstrumentierung — an die HLA-Föderation an. Jedes Gateway muss gleichzeitig mehrere Funktionen ausführen.

Protokollübersetzung konvertiert das eingehende Nachrichtenformat in RPR-FOM-Attributaktualisierungen. Dies ist nicht rein mechanisch: LINK 16 J-Serie Nachrichten kodieren die Entitätsposition in WGS-84 geodätischen Koordinaten, während HLA RPR-FOM ein gezentrisches kartesisches Koordinatensystem (erdmittelpunktzentriert, erdfest) verwendet. Das Gateway muss für jede Positionsaktualisierung die Koordinatenrahmentransformation durchführen. Geschwindigkeitsvektoren, falls im Live-Feed vorhanden, müssen konsistent transformiert werden. Die Entitätstyp-Abbildung von LINK 16 Emissionstyp-Codes auf RPR-FOM EntityType-Werte erfordert eine gepflegte Übersetzungstabelle — neue Gerätetypen müssen explizit hinzugefügt werden, und mehrdeutige Codes (bei denen ein LINK 16 Typ mehreren Plattformtypen entspricht) erfordern heuristische Auflösung.

Entitätslebenszyklus-Management behandelt das Erscheinen, die Persistenz und das Verschwinden von Live-Entitäten in der HLA-Föderation. Wenn das Gateway zum ersten Mal einen Track sieht, erstellt es eine HLA-Objektinstanz und übernimmt deren Eigentümerschaft. Wenn der Track verloren geht (GPS-Ausfall, Fahrzeug durch Gelände verdeckt), muss das Gateway entscheiden, ob eine Dead-Reckoning-Positionsschätzung für eine Toleranzperiode aufrechterhalten oder das Objekt sofort entfernt werden soll. Vorzeitige Entfernung gefolgt von schneller Neuregistrierung erzeugt Objektidentitätsunstetigkeiten, die die Ziellogik der konstruktiven OPFOR verwirren. Ausgedehnte Dead-Reckoning verlorener Tracks erzeugt Geister-Entitäten, die das Lagebildbild des Ausbildungspublikums beeinträchtigen.

Ratenanpassung passt die Aktualisierungsfrequenz der Live-Quelle an die Erwartungen der Simulation an. Ein GPS-Tracker mit 1 Hz Aktualisierung kann keine Aktualisierungen mit der Rate von 20–30 Hz injizieren, die konstruktive Entitäten verwenden; das Gateway muss mit der Live-Rate veröffentlichen und Dead-Reckoning-Parameter (Geschwindigkeit und Beschleunigung) im HLA-Entitätszustand konfigurieren, damit empfangende Föderaten die Position zwischen Aktualisierungen extrapolieren können. Die Dead-Reckoning-Parameter müssen realistisch gesetzt werden — ein Kettenfahrzeug kann kein Dead-Reckoning-Modell eines Flugzeugs zugewiesen werden.

Cloud-gehostetes LVC: Architektur und Latenzbudget

Die Verlagerung von LVC-Backend-Komponenten in eine Regierungs-Cloud-Umgebung — Azure Government oder ein klassifiziertes IL5/IL6-Äquivalent — ist operativ attraktiv, da dadurch die Notwendigkeit entfällt, physische Serverinfrastruktur an jedem Übungsstandort zu versenden und zu konfigurieren. Eine cloud-gehostete konstruktive Simulationsföderation kann mehrere geografisch verteilte Übungsstandorte gleichzeitig bedienen, wobei virtuelle Simulationsanlagen und Live-Kraft-Gateways an verschiedenen Standorten alle in eine gemeinsame cloud-gehostete HLA-Föderation föderieren.

Die kritische Einschränkung ist Latenz. HLA-Zeitmanagement im Echtzeitmodus gewährt Time-Advances in Intervallen, die durch die Lookahead-Konfiguration und den Heartbeat-Zyklus der RTI bestimmt werden. Für eine Echtzeit-LVC-Föderation besteht die praktische Anforderung darin, dass Entitätszustandsaktualisierungen alle abonnierenden Föderaten innerhalb von 100–150 ms nach der Generierung erreichen — jenseits dieses Schwellenwerts beginnt die konstruktive OPFOR-Manöverlogik auf veralteten Positionsdaten zu agieren, und virtuelle Simulator-Besatzungen sehen Live-Entitäten teleportieren statt sich reibungslos bewegen.

Eine cloud-gehostete RTI, die Föderaten an geografisch verteilten Standorten bedient, muss so positioniert sein, dass die worst-case Round-Trip-Latenz minimiert wird. Azure Government Regionen in den kontinentalen Vereinigten Staaten erreichen über dedizierte Regierungsnetzwerkpfade (nicht öffentliches Internet) ungefähr 20–40 ms Round-Trip zu den meisten CONUS-Übungsstandorten. Europäische Übungsstandorte, die eine US-Cloud-Region erreichen, sehen 80–120 ms Round-Trip. Dies liegt innerhalb des 150-ms-Schwellenwerts für konstruktive und virtuelle Komponenten, ist aber für Live-Kraft-Gateways knapp, die auf hochfrequente Sensor-Feeds reagieren müssen.

Die empfohlene Architektur teilt die HLA-Föderation über geografische Ebenen auf. Konstruktive Simulation, Szenariomanagement und AAR-Aufzeichnung laufen in der Cloud. Virtuelle Simulatoren und Live-Kraft-Gateways laufen an jedem Übungsstandort mit einem lokalen RTI-Proxy, der zur Cloud-Föderation überbrückt. Der lokale Proxy speichert den Entitätszustand für den Interessenbereich des lokalen Standorts im Cache und bedient Aktualisierungen für lokale Föderaten aus dem Cache, anstatt für jede Attributaktualisierung einen Round-Trip zur Cloud-RTI zu erfordern. Dadurch werden lokale Interaktionen unter 5 ms gehalten, während der globale Föderationszustand weiterhin über das Cloud-Backbone synchronisiert wird.

Auswirkungen auf konstruktive Simulationskomponenten

Die konstruktive Simulationskomponente in einer LVC-Föderation hat Verantwortlichkeiten, die über die bloße Generierung von Entitätsverhalten hinausgehen. Sie muss kohärenten Entitätszustand über die LVC-Grenze hinweg aufrechterhalten — korrekt identifizieren, welche Entitäten live, welche virtuell und welche konstruktiv sind, und jeder Kategorie geeignete Einsatzregeln und Engagementlogik anwenden. Ein konstruktives OPFOR-Element sollte sowohl live als auch virtuelle freundliche Entitäten mit konsistenter Logik engagieren können; es darf jedoch nicht versuchen, Entitäten zu engagieren, die Instrumentierungsartefakte sind (duplizierte Live-Tracks, für Integrations-Debugging injizierte Test-Entitäten).

Das konstruktive KI-Verhalten muss auch die Latenz und Unsicherheit berücksichtigen, die inhärent in Live-Entitätsdaten sind. Ein konstruktives System, das für eine rein konstruktive Umgebung ausgelegt ist, geht von perfektem Wissen über alle Entitätspositionen aus, die im eigenen Zeitschritt der Simulation aktualisiert werden. Wenn Live-Entitätsdaten mit 1 Hz und gelegentlichen Lücken ankommen, muss die konstruktive KI für Ziel- und Manöverentscheidungen extrapolierte Positionen verwenden — und muss graceful degradieren, wenn Live-Tracks dunkel werden, anstatt Track-Verlust als Entitätszerstörung zu behandeln.

Die Szenariomanagement-Ebene der konstruktiven Simulation steuert auch Übungsleitungsentscheidungen, die die Live-Domäne betreffen: wann Verstärkungen einzuführen sind, wann Kommunikation zu degradieren ist, wann von konstruktiver OPFOR zu Live-OPFOR für eine bestimmte Übungsphase überzugehen ist. Stabsplanungsübungen mit konstruktiver Simulation profitieren von dieser Flexibilität — das Übungsleitungsteam kann Stimuli in die Live-Domäne über die konstruktive Schicht injizieren, ohne die Handlungsfreiheit der Live-Kräfte zu unterbrechen.