Live-virtual-constructive (LVC) integratie voor defensietraining

Grootschalige collectieve training — het soort dat brigadestaven voorbereidt op het synchroniseren van vuursteun, manoeuvres en logistiek in een multi-domein strijdtoneel — kan niet goedkoop worden uitgevoerd met alleen live strijdkrachten. Live oefeningen verbruiken munitie, slijten voertuigen en vereisen het deconflicteren van duizenden vierkante kilometer luchtruim en grondgebied. Virtuele simulatoren comprimeren geografie en elimineren verbruikskosten, maar ze kunnen de wrijving, communicatielatentie en fysieke uitputting van echte operaties niet repliceren. Constructieve simulatie schaalt goedkoop op tot divisie- of korpsomvang, maar de entiteiten die ze genereert zijn computergestuurde abstracties, geen soldaten. Elk domein legt een deel van het trainingsplaatje vast. Live-virtual-constructive (LVC) integratie probeert alle drie te combineren in één coherente synthetische omgeving — en geeft trainingsdeelnemers een realistische combinatie van echte strijdkrachten, bemande simulatoren en computergegenereerde entiteiten tegelijkertijd. De architectuur om dat te realiseren is het onderwerp van dit artikel.

Wat live, virtueel en constructief elk betekenen

De termen worden gedefinieerd door de mate van menselijke betrokkenheid in de lus. Live betekent echte mensen die echte uitrusting bedienen in de fysieke omgeving. Een tankpeloton dat M1A2's rijdt op een oefenterrein is een live element. Instrumentering — GPS-trackers, wapenwerksimulatoren zoals MILES, spraakradio's — stelt het oefencontrolesysteem in staat te observeren en vast te leggen wat live elementen doen, maar de strijdkrachten zelf zijn fysiek aanwezig. Live elementen zijn de gouden standaard voor realisme bij individuele en ploegtraining; ze zijn duur en moeilijk op te schalen.

Virtueel betekent een menselijke operator die interageert met een gesimuleerd platform in een simulator. De operator is echt en oefent echte cognitieve en procedurele vaardigheden, maar het platform en de omgeving zijn synthetisch. Steel Beasts Pro PE, Prepar3D en vliegtuigmissiesimulators zijn virtuele omgevingen. Virtuele elementen zijn minder kostbaar per trainingsuur dan live elementen, kunnen platforms vertegenwoordigen die zeldzaam zijn of in onderhoud, en kunnen onmiddellijk worden teruggezet naar elke scenario-toestand. Hun beperking is dat de gesimuleerde fysica en sensormodellen, hoe gedetailleerd ook, nog steeds benaderingen zijn.

Constructief betekent computergegenereerde entiteiten die worden bestuurd door software — AI, gescripteerde gedragsmodellen of menselijke oefencontrollers die optreden als geaggregeerde strijdkrachten. Geen individuele mens zit in de lus voor elke entiteit. OneSAF, JCATS en WARG zijn constructieve simulatiesystemen. Constructieve simulatie schaalt op tot oefeningen op korpsniveau met tienduizenden entiteiten voor een fractie van de kosten van equivalente live of virtuele strijdkrachten. De afweging is verminderd realisme op het niveau van individuele entiteiten en minder betrokkenheid met het trainingspubliek bij taken die oprechte cognitieve belasting van de tegenstander vereisen.

LVC-integratie combineert alle drie. Een brigade-oefening kan een live infanteriebataljon op een echt oefenterrein hebben, virtuele rotorwiekcrew's die gesimuleerde helikopters vliegen vanuit een simulatorfaciliteit, en een constructieve OPFOR van regimentale omvang waarvan het gedrag wordt gestuurd door een klein oefencontroleteam. De trainingswaarde van de gecombineerde omgeving overtreft wat elk afzonderlijk domein kan bieden: het live bataljon staat bloot aan tactisch coherente druk van een grote, realistisch gedragende constructieve OPFOR, gecoördineerd met virtuele luchtsteun die in bijna real-time reageert op grondgebeurtenissen.

De interoperabiliteitsuitdaging

Het combineren van de drie domeinen is architecturaal niet triviaal, omdat elk domein onafhankelijk is ontwikkeld en verschillende protocollen, tijdbases en entiteitsmodellen gebruikt. Live strijdkrachten communiceren via LINK 16, VMF, NFFI (NATO Friendly Force Information) of Cursor on Target (CoT)-feeds van instrumenteringssystemen. Virtuele simulatoren spreken doorgaans DIS (Distributed Interactive Simulation, IEEE 1278) of HLA (High Level Architecture, IEEE 1516). Constructieve simulatiesystemen spreken HLA — gewoonlijk de RPR-FOM (Real-time Platform Reference Federation Object Model)-variant — of TENA (Test and Training Enabling Architecture) in instrumenteringsomgevingen op schietbanen.

Drie interoperabiliteitshiaten maken LVC-integratie in de praktijk moeilijk. Het eerste is protocolheterogeniteit: een LINK 16-trackbericht en een HLA RPR-FOM EntityState-attribuutupdate vertegenwoordigen conceptueel hetzelfde (de positie en toestand van een militaire entiteit), maar in volledig verschillende binaire indelingen, met verschillende veldsemantiek en via verschillende transportmechanismen. Een gateway moet hiertussen vertalen zonder informatie te verliezen of ambiguïteit te introduceren.

Het tweede hiaat is latentiemismatch. Een live GPS-track van een geïnstrumenteerd voertuig wordt bijgewerkt met 1 Hz. Een virtuele tanksimulator werkt zijn entiteitstoestand bij met 20-30 Hz, met dead-reckoning tussen updates. Een constructieve simulatie die in real-time draait, kan entiteitsposities bijwerken met variabele frequenties afhankelijk van entiteitsactiviteit. Wanneer deze feeds aankomen in een gedeelde synthetische omgeving, moeten de entiteitsposities coherent worden gemengd — een live voertuig dat bijwerkt met 1 Hz zal lijken te springen als zijn positie simpelweg wordt doorgestuurd op de live updatefrequentie in plaats van te worden gladgestreken met dead-reckoning-extrapolatie die consistent is met de tijdstap van de simulatie.

Het derde hiaat is entiteitsidentiteit. Dezelfde fysieke tank die verschijnt in het live domein, gevolgd door schietbaaninstrumentering, vertegenwoordigd door een virtuele simulatorcrew en gerepliceerd als een constructieve entiteit voor bewustzijn van tegenstanders, moet over alle domeinen heen correct worden geïdentificeerd als één enkele entiteit — niet als drie afzonderlijke entiteiten die toevallig dezelfde locatie bezetten. Identiteitsbeheer over domeinsgrenzen, met name wanneer entiteiten tijdens een oefening overgaan tussen live en constructieve representatie, is een van de meest foutgevoelige aspecten van LVC-architectuur.

HLA als de LVC-ruggengraat

HLA (High Level Architecture, IEEE 1516) is de dominante federatiestandaard voor het verbinden van LVC-componenten, omdat het de diensten biedt die nodig zijn om een multi-federate simulatieomgeving op schaal te beheren. Het HLA-protocol zelf wordt elders in detail behandeld; hier ligt de focus op hoe HLA specifiek functioneert in een LVC-context.

In een LVC-federatie sluit elk groot component — het constructieve simulatiesysteem, elke virtuele simulatorsite en elke gateway-adapter voor live strijdkrachtfeeds — zich aan bij de HLA-federatie als een federaat. De RTI (Run-Time Infrastructure) beheert de communicatie tussen federaten met behulp van het FOM (Federation Object Model) van de federatie, doorgaans gebaseerd op SISO's RPR-FOM 2.0 voor NATO-interoperabiliteit.

Federatiebeheer handelt de oefenlevenscyclus af: aanmaken van de federatie, toetreding en afmelding van federaten, synchronisatiepunten (gebruikt om scenario's te coördineren bij start, pauze en herstart over alle componenten heen) en vernietiging van de federatie. In een multi-site LVC-oefening zijn synchronisatiepunten cruciaal — zonder hen kan één federaat beginnen met het voortschrijden van de scenario-tijd terwijl een ander nog initialiseert, wat de entiteitstoestand over de grens corrumpeert.

Tijdbeheer in een LVC-federatie is doorgaans geconfigureerd als best-effort real-time in plaats van strikte tijdbeheerde simulatie, omdat live strijdkrachten niet kunnen worden gepauzeerd of vertraagd om time-advance grants te accommoderen. De RTI draait in real-time modus; constructieve en virtuele federaten publiceren tijdgestempelde updates maar houden de federatietijdsvoortgang niet vast voor laat-aankomende live data. Dit betekent dat de constructieve en virtuele componenten af en toe out-of-order entiteitsstatusupdates van live gateways moeten tolereren.

Data Distribution Management (DDM) is essentieel op LVC-schaal. Een oefening op korpsniveau kan duizenden entiteiten hebben verspreid over een geografisch gebied van honderden kilometers. Zonder DDM ontvangt elk federaat elke entiteitsstaatupdate — een bandbreedte- en verwerkingsbelasting die commandopostsimulators zal overweldigen die alleen geïnteresseerd zijn in een tactische straal van 50 km. DDM-abonnementsregio's, geconfigureerd om overeen te komen met het operationele interessegebied van elk federaat, verminderen dit tot een beheersbaar volume.

DIS in LVC: nog steeds relevant voor virtuele componenten

Ondanks de architecturale voordelen van HLA blijft DIS (IEEE 1278) aanwezig in LVC-omgevingen, omdat een grote geïnstalleerde basis van virtuele simulatoren DIS van nature spreekt en niet kosteneffectief kan worden geherintegreerd naar HLA. Steel Beasts Pro, veel oudere vluchtsimulatoren en oudere commandopost-oefentools waren ontworpen voor DIS-omgevingen. Vervanging ervan is niet haalbaar binnen de meeste programmabudgetten.

De oplossing is een DIS-naar-HLA-brug: een gateway die deelneemt aan het DIS-multicast-netwerk als DIS-deelnemer en tegelijkertijd als HLA-federaat, die DIS PDU's vertaalt naar RPR-FOM-entiteitsstatusupdates en vice versa. De brug moet de semantische verschillen zorgvuldig afhandelen. DIS Entity State PDU's gebruiken dead-reckoning-algoritmen (gedefinieerd in de standaard) om positie tussen updates glad te strijken; de brug moet dezelfde dead-reckoning toepassen op inkomende DIS-gegevens voordat ze naar HLA worden gepubliceerd, om positiediscontinuïteiten te vermijden. De brug moet ook DIS-entiteitstypecodes (die een hiërarchische opsomming gebruiken zoals gedefinieerd in SISO ENUM-70) toewijzen aan HLA RPR-FOM EntityType-attributen met behulp van dezelfde opsomming — mismatches in entiteitstypecodering zorgen ervoor dat constructieve OPFOR virtuele vriendschappelijke platforms verkeerd classificeert.

PDU-frequentiebeheer is een praktisch aandachtspunt. Een DIS-omgeving met 200 virtuele simulatoren die elk publiceren met 30 Hz genereert 6.000 PDU's per seconde op het multicast-netwerk. De DIS-naar-HLA-brug moet dit filteren met deadband-drempelwaarden — alleen updates doorsturen wanneer positie, snelheid of oriëntatie een gedefinieerde drempel overschrijdt — om te voorkomen dat de HLA-federatie verzadigd raakt met updates die onbeduidende bewegingen vertegenwoordigen.

LVC gateway-architectuur

De gatewaylaag is architecturaal het meest kritische en meest faalanfällige component van een LVC-integratie. Een gateway past een live gegevensbron — LINK 16, NFFI, CoT, schietbaaninstrumentering — aan naar de HLA-federatie. Elke gateway moet meerdere functies tegelijkertijd uitvoeren.

Protocolvertaling converteert het inkomende berichtformaat naar RPR-FOM-attribuutupdates. Dit is niet puur mechanisch: LINK 16 J-serie berichten coderen entiteitspositie in WGS-84 geodetische coördinaten, terwijl HLA RPR-FOM een geocentrisch Cartesiaans coördinatensysteem gebruikt (aardgericht, aardvast). De gateway moet de coördinaatreferentiekadertransformatie uitvoeren voor elke positieupdate. Snelheidsvectoren, indien aanwezig in de live feed, moeten consistent worden getransformeerd. Entiteitstypemapping van LINK 16-emissietypecodes naar RPR-FOM EntityType-waarden vereist een onderhouden vertaaltabel — nieuwe uitrustingstypes moeten expliciet worden toegevoegd, en ambigue codes (waarbij één LINK 16-type overeenkomt met meerdere platformtypen) vereisen heuristische resolutie.

Entiteitslevenscyclusbeheer handelt het verschijnen, voortbestaan en verdwijnen van live entiteiten in de HLA-federatie af. Wanneer de gateway een track voor het eerst ziet, maakt het een HLA-objectinstantie aan en neemt het eigendom ervan over. Wanneer de track verloren gaat (GPS-uitval, voertuig gemaskeerd door terrein), moet de gateway beslissen of het een dead-reckoned positieschatting gedurende een respijtperiode wil handhaven of het object onmiddellijk wil verwijderen. Vroegtijdige verwijdering gevolgd door snelle herregistratie creëert objectidentiteitsdiscontinuïteiten die de targetinglogica van constructieve OPFOR verwarren. Langdurige dead-reckoning van verloren tracks creëert spookeniteiten die het situatiebewustzijn van het trainingspubliek aantasten.

Frequentieadaptatie stemt de updatecadans van de live bron af op de verwachtingen van de simulatie. Een GPS-tracker die bijwerkt met 1 Hz kan geen updates injecteren op de 20-30 Hz-frequentie die constructieve entiteiten gebruiken; de gateway moet publiceren op de live frequentie en dead-reckoning-parameters (snelheid en versnelling) configureren in de HLA-entiteitstoestand, zodat ontvangende federaten de positie tussen updates kunnen extrapoleren. De dead-reckoning-parameters moeten realistisch worden ingesteld — een gevolgd voertuig kan niet het dead-reckoning-model van een vliegtuig toegewezen krijgen.

Cloud-gehoste LVC: architectuur en latentiebudget

Het verplaatsen van LVC-back-endcomponenten naar een overheidscloudumgeving — Azure Government of een geclassificeerd IL5/IL6-equivalent — is operationeel aantrekkelijk omdat het de noodzaak elimineert om fysieke serverinfrastructuur naar elke oefensite te verschepen en te configureren. Een cloud-gehoste constructieve simulatiefederatie kan meerdere geografisch verspreide oefensites tegelijkertijd bedienen, met virtuele simulatorfaciliteiten en live strijdkrachtgateways op verschillende locaties die allemaal federeren in een gemeenschappelijke cloud-gehoste HLA-federatie.

De kritische beperking is latentie. HLA-tijdbeheer in real-time modus verleent tijdsvoortgang in intervallen die worden bepaald door de lookahead-configuratie en de heartbeat-cyclus van de RTI. Voor een real-time LVC-federatie is de praktische eis dat entiteitsstatusupdates alle abonnerende federaten bereiken binnen 100-150 ms na generatie — voorbij die drempel begint de constructieve OPFOR-manoeuvrelogica te handelen op verouderde positiegegevens, en virtuele simulatorcrew's zien live entiteiten teleporteren in plaats van soepel bewegen.

Een cloud-gehoste RTI die federaten bedient op geografisch verspreide sites moet worden gelokaliseerd om de worst-case round-trip latentie te minimaliseren. Azure Government-regio's in het continentale deel van de Verenigde Staten bereiken ongeveer 20-40 ms round-trip naar de meeste CONUS-trainingssites via speciale overheidsnetworkpaden (niet het openbare internet). Europese trainingssites die een Amerikaanse cloudregio bereiken, staan voor 80-120 ms round-trip. Dit valt binnen de drempel van 150 ms voor constructieve en virtuele componenten, maar is marginaal voor live-strijdkrachtgateways die moeten reageren op hoog-frequente sensorfeeds.

De aanbevolen architectuur splitst de HLA-federatie over geografische lagen. Constructieve simulatie, scenariobeheer en AAR-opname draaien in de cloud. Virtuele simulatoren en live-strijdkrachtgateways draaien op elke oefensite met een lokale RTI-proxy die een brug slaat naar de cloud-federatie. De lokale proxy slaat entiteitstoestand op voor het interessegebied van de lokale site, waarbij updates aan lokale federaten worden geleverd vanuit de cache in plaats van een round-trip naar de cloud-RTI te vereisen voor elke attribuutupdate. Dit houdt lokale-naar-lokale entiteitsinteracties onder 5 ms terwijl de globale federatietoestand nog steeds wordt gesynchroniseerd via de cloud-ruggengraat.

Implicaties voor constructieve simulatiecomponenten

Het constructieve simulatiecomponent in een LVC-federatie heeft verantwoordelijkheden die verder gaan dan simpelweg entiteitsgedrag genereren. Het moet coherente entiteitstoestand handhaven over de LVC-grens — correct identificeren welke entiteiten live zijn, welke virtueel en welke constructief, en passende regels van betrokkenheid en engagementlogica toepassen op elke categorie. Een constructief OPFOR-element moet zowel live als virtuele vriendschappelijke entiteiten kunnen aanpakken met consistente logica; maar het mag niet proberen entiteiten te engageren die instrumentatie-artefacten zijn (dubbele live tracks, testentiteiten geïnjecteerd voor integratiedebugging).

Constructief AI-gedrag moet ook rekening houden met de latentie en onzekerheid die inherent zijn aan live entiteitsdata. Een constructief systeem dat is ontworpen voor een volledig constructieve omgeving, gaat uit van perfecte kennis van alle entiteitsposities, bijgewerkt op de tijdstap van de simulatie. Wanneer live entiteitsdata aankomt met 1 Hz met af en toe hiaten, moet de constructieve AI geëxtrapoleerde posities gebruiken voor targeting- en manoeuvrebeslissingen — en graceful degraderen wanneer live tracks uitvallen, in plaats van trackverlies te behandelen als vernietiging van de entiteit.

De scenario-beheerlaag van de constructieve simulatie stuurt ook oefencontrolebeslissingen die het live domein beïnvloeden: wanneer versterkingen in te voeren, wanneer communicatie te degraderen, wanneer over te schakelen van constructieve OPFOR naar live OPFOR voor een specifieke fase van de oefening. Stafplanningsoefeningen met constructieve simulatie profiteren van deze flexibiliteit — het oefencontroleteam kan via de constructieve laag stimuli injecteren in het live domein zonder de handelingsvrijheid van de live strijdkrachten te onderbreken.