Live-virtual-constructive (LVC) -integraatio puolustuskoulutukseen

Laajamittainen yhteistoimintakoulutus — sellainen, joka valmistelee prikaatien esikuntia koordinoimaan tulta, manööveriä ja logistiikkaa monidimensioisella taistelumaastolla — ei onnistu halvalla pelkästään reaalisilla joukoilla. Reaaliset harjoitukset kuluttavat ammuksia, kuluttavat ajoneuvoja ja vaativat tuhansien neliökilometrien ilmatilan ja maa-alueen käytön koordinointia. Virtuaaliset simulaattorit tiivistävät maantiedettä ja poistavat kulutuskustannukset, mutta ne eivät pysty jäljittelemään todellisten operaatioiden hankausta, viestintäviivettä ja fyysistä uupumusta. Konstruktiivinen simulaatio skaalautuu halvalla divisioonan tai armeijakunnan kokoiseen harjoitukseen, mutta sen generoimat entiteetit ovat tietokoneohjailtuja abstraktioita, eivät sotilaita. Jokainen toimialue tallentaa osan harjoituskuvasta. Live-virtual-constructive (LVC) -integraatio pyrkii yhdistämään kaikki kolme yhteen yhtenäiseen synteettiseen ympäristöön — tarjoten harjoitusjoukoille realistisen yhdistelmän reaalisista joukoista, miehitetyistä simulaattoreista ja tietokonegeneroiduista entiteeteistä samanaikaisesti. Tämän toteuttamisen arkkitehtuuri on tämän artikkelin aihe.

Mitä live, virtual ja constructive tarkoittavat

Termit määritellään ihmisen ohjauksen asteen perusteella. Live tarkoittaa todellisia ihmisiä, jotka käyttävät todellista kalustoa fyysisessä ympäristössä. Panssarivaunukomppania, joka ajaa M1A2-vaunuilla harjoitusalueella, on live-elementti. Instrumentointi — GPS-seuraimet, asevaikutussimulaattorit kuten MILES, puheradiot — mahdollistaa harjoituksen johtamisjärjestelmän seurata ja tallentaa live-elementtien toimintaa, mutta joukot ovat fyysisesti läsnä. Live-elementit ovat yksilö- ja miehistötason harjoitusrealismin kultainen standardi; ne ovat kalliita ja vaikea skaalata.

Virtual tarkoittaa ihmisoperaattoria, joka on vuorovaikutuksessa simuloidun alustan kanssa simulaattorin sisällä. Operaattori on todellinen ja harjoittelee todellisia kognitiivisia ja proseduraalisia taitoja, mutta alusta ja ympäristö ovat synteettisiä. Steel Beasts Pro PE, Prepar3D ja lentokoneiden tehtäväsimulaattorit ovat virtuaaliympäristöjä. Virtuaaliset elementit ovat halvempia koulutustuntia kohden kuin reaaliset, ne voivat edustaa harvinaisia tai huollossa olevia alustoja ja ne voidaan nollata mihin tahansa skenaariotilaan välittömästi. Niiden rajoitus on, että simuloidut fysiikka- ja sensorivirhemallit ovat, kuinka yksityiskohtaisia tahansa, silti approksimaatioita.

Constructive tarkoittaa ohjelmiston hallitsemia tietokonegeneroituja entiteettejä — tekoälyä, skriptattuja käyttäytymismalleja tai harjoituksen johtamistiimiä, joka toimii aggregoitujen joukkojen roolissa. Yksittäisellä ihmisellä ei ole kontrollia jokaisesta entiteetistä. OneSAF, JCATS ja WARG ovat konstruktiivisia simulaatiojärjestelmiä. Konstruktiivinen simulaatio skaalautuu armeijakunnan kokoisiin harjoituksiin kymmenillä tuhansilla entiteeteillä murto-osalla vastaavien reaali- tai virtuaalijoukkojen kustannuksista. Kompromissina on vähentynyt realismi yksittäisen entiteetin tasolla ja vähentynyt harjoitusvaikutus tehtävissä, jotka vaativat aitoa kognitiivista kuormitusta vastustajan joukolta.

LVC-integraatio yhdistää kaikki kolme. Prikaatiharjoituksessa saattaa olla reaali-jalkaväkipataljoona oikealla harjoitusalueella, virtuaaliset rotarisiipimiehistöt, jotka lentävät simuloituja helikoptereita simulaattorilaitoksesta, ja konstruktiivinen OPFOR rykmentinkokoisena, jonka käyttäytymistä ohjaa pieni harjoituksen johtamistiimi. Yhdistetyn ympäristön harjoitusarvo ylittää sen, mitä mikään yksittäinen toimialue voisi tarjota: reaali-pataljoonaa kohtaa taktisesti koherentti paine suurelta, realistisesti käyttäytyvältä konstruktiiviselta OPFOR:ilta, koordinoituna virtuaalisen ilmatuen kanssa, joka reagoi maatapahtumiin lähes reaaliajassa.

Yhteentoimivuuden haaste

Kolmen toimialueen yhdistäminen on arkkitehtuurisesti ei-triviaalia, koska jokainen toimialue on kehitetty itsenäisesti ja käyttää eri protokollia, aikapohjia ja entiteettimalleja. Reaaliset joukot viestivät LINK 16:lla, VMF:llä, NFFI:llä (NATO Friendly Force Information) tai Cursor on Target (CoT) -syötteillä instrumentointijärjestelmistä. Virtuaaliset simulaattorit käyttävät tyypillisesti DIS:ää (Distributed Interactive Simulation, IEEE 1278) tai HLA:ta (High Level Architecture, IEEE 1516). Konstruktiiviset simulaatiojärjestelmät käyttävät HLA:ta — yleensä RPR-FOM (Real-time Platform Reference Federation Object Model) -varianttia — tai TENA:a (Test and Training Enabling Architecture) alueellisen instrumentoinnin yhteyksissä.

Kolme yhteentoimivuuden aukkoa tekevät LVC-integraation käytännössä vaikeaksi. Ensimmäinen on protokollaheteroogeenisuus: LINK 16 -seurantaviesti ja HLA RPR-FOM EntityState -attribuuttipäivitys edustavat käsitteellisesti samaa asiaa (sotilaallisen entiteetin sijainti ja tila), mutta täysin eri binäärimuodoissa, eri kenttäsemantiikalla ja eri kuljetusmekanismeilla. Gatewayn on käännettävä niiden välillä menettämättä tietoa tai aiheuttamatta epäselvyyttä.

Toinen aukko on viivelähentymätön. Instrumentoidun ajoneuvon reaali-GPS-seuranta päivittyy 1 Hz:n taajuudella. Virtuaalinen panssarivaunusimulaattori päivittää entiteettitilansa 20–30 Hz:n taajuudella käyttäen dead-reckoning-menetelmää päivitysten välillä. Reaaliajassa toimiva konstruktiivinen simulaatio saattaa päivittää entiteettien sijainteja vaihtelevilla nopeuksilla riippuen entiteetin toiminnasta. Kun nämä syötteet saapuvat jaettuun synteettiseen ympäristöön, entiteettien sijainnit on sekoitettava koherentisti — reaali-ajoneuvo, joka päivittyy 1 Hz:llä, näyttää hyppivän, jos sen sijainti yksinkertaisesti välitetään live-päivitysnopeudella eikä sitä tasoiteta simulaation aika-askelta vastaavalla dead-reckoning-ekstrapolaatiolla.

Kolmas aukko on entiteetti-identiteetti. Sama fyysinen panssarivaunu, joka esiintyy live-toimialueella, seurataan harjoitusalueen instrumentoinnin avulla, edustettuna virtuaalisimulaattorin miehistön toimesta ja replikoituna konstruktiivisena entiteettinä vastustajan joukkojen tietoisuutta varten, on tunnistettava yhdeksi entiteetiksi kaikissa toimialueissa — ei kolmeksi erilliseksi entiteetiksi, jotka sattuvat olemaan samassa sijainnissa. Identiteetinhallinta toimialueiden rajojen yli, erityisesti kun entiteetit siirtyvät live- ja konstruktiivisen representaation välillä harjoituksen aikana, on yksi LVC-arkkitehtuurin virhealttiimmista osa-alueista.

HLA LVC-runkona

HLA (High Level Architecture, IEEE 1516) on hallitseva federaatiostandardi LVC-komponenttien yhdistämiseen, koska se tarjoaa palvelut, joita tarvitaan moni-federaatin simulointiympäristön hallintaan laajassa mittakaavassa. HLA-protokolla itsessään on käsitelty yksityiskohtaisesti erikseen; tässä keskitytään siihen, miten HLA toimii erityisesti LVC-kontekstissa.

LVC-federaatiossa jokainen pääkomponentti — konstruktiivinen simulaatiojärjestelmä, jokainen virtuaalisimulaattoripaikka ja jokainen gateway-adapteri live-joukkojen syötteille — liittyy HLA-federaatioon federaattina. RTI (Run-Time Infrastructure) hallitsee viestintää federaattien välillä käyttäen federaation FOM:ia (Federation Object Model), joka perustuu tyypillisesti SISO:n RPR-FOM 2.0:aan NATO:n yhteentoimivuuden osalta.

Federaation hallinta käsittelee harjoituksen elinkaaren: federaation luomisen, federaatin liittymisen ja eroamisen, synkronointipisteet (joita käytetään koordinoimaan skenaarion käynnistys, tauko ja uudelleenkäynnistys kaikkien komponenttien välillä) ja federaation tuhoamisen. Monipaikka-LVC-harjoituksessa synkronointipisteet ovat kriittisiä — ilman niitä yksi federaatti saattaa alkaa edistää skenaarion aikaa, kun toinen on vielä alustumassa, korruptoiden entiteettitilan rajan yli.

Aikahallinta LVC-federaatiossa on tyypillisesti konfiguroitu parhaana mahdollisena reaaliaikana eikä tiukkana aikaohjattuna simulaationa, koska reaaliset joukot eivät voi pysähtyä tai hidastua aikaedistämislupien odottamiseksi. RTI toimii reaaliajassa; konstruktiiviset ja virtuaaliset federaatit julkaisevat aikaleimattuja päivityksiä, mutta eivät pidätä federaation aikaedistämistä myöhään saapuvien live-datan takia. Tämä tarkoittaa, että konstruktiiviset ja virtuaaliset komponentit on sallittava toleroimaan satunnaisia järjestyksestä poikkeavia entiteettitila-päivityksiä live-gatewayilta.

Data Distribution Management (DDM) on välttämätön LVC-mittakaavassa. Armeijakunnan kokoisessa harjoituksessa saattaa olla tuhansia entiteettejä maantieteellisellä alueella, joka kattaa satoja kilometrejä. Ilman DDM:ää jokainen federaatti saa jokaisen entiteettitila-päivityksen — kaistanleveys- ja prosessointikuorma, joka ylittää komentopaikkasimulaattorien kapasiteetin, jotka ovat kiinnostuneita vain 50 km:n taktisesta säteestä. DDM-tilausalueet, jotka on konfiguroitu vastaamaan kunkin federaatin operationaalisen kiinnostuksen aluetta, vähentävät tämän hallittavaan volyymiin.

DIS LVC:ssä: edelleen relevantti virtuaalikomponenteille

HLA:n arkkitehtuurisista eduista huolimatta DIS (IEEE 1278) on edelleen läsnä LVC-ympäristöissä, koska suuri asennettu kanta virtuaalisimulaattoreita puhuu DIS:ää natiivisti eikä niitä voi kustannustehokkaasti integroida uudelleen HLA:han. Steel Beasts Pro, monet vanhat lentäjäsimulaattorit ja vanhemmat komentopaikkaharjoitustyökalut on suunniteltu DIS-ympäristöihin. Niiden korvaaminen ei ole mahdollista useimpien ohjelmien budjeteissa.

Ratkaisu on DIS-HLA-silta: gateway, joka osallistuu DIS-multicast-verkkoon DIS-osallistujana ja samanaikaisesti HLA-federaattina, kääntäen DIS PDU:t RPR-FOM-entiteettitila-päivityksiksi ja päinvastoin. Sillan on käsiteltävä semanttiset erot huolellisesti. DIS Entity State PDU:t käyttävät dead-reckoning-algoritmeja (standardissa määritelty) sijainnin tasoittamiseen päivitysten välillä; sillan on sovellettava samaa dead-reckoningia saapuvaan DIS-dataan ennen HLA:han julkaisemista sijaintikatkosien välttämiseksi. Sillan on myös kartoitettava DIS-entiteettityyppikoodit (jotka käyttävät SISO ENUM-70:ssä määriteltyä hierarkkista luettelointia) HLA RPR-FOM EntityType -attribuuteiksi käyttäen samaa luettelointia — entiteettityypin koodauksen epäsopivuudet aiheuttavat konstruktiivisen OPFOR:n väärin luokittelevan virtuaaliset ystävälliset alustat.

PDU-nopeuden hallinta on käytännön huolenaihe. DIS-ympäristö, jossa on 200 virtuaalisimulaattoria, joista kukin julkaisee 30 Hz:llä, generoi 6 000 PDU:ta sekunnissa multicast-verkossa. DIS-HLA-sillan on suodatettava tämä deadband-kynnysarvojen avulla — välittämällä päivityksiä vain silloin, kun sijainti, nopeus tai suuntaus ylittää määritetyn kynnyksen — välttääkseen HLA-federaation kyllästämisen päivityksillä, jotka edustavat merkityksetöntä liikettä.

LVC-gateway-arkkitehtuuri

Gateway-kerros on arkkitehtuurisesti kriittisin ja virhealttisin komponentti LVC-integraatiossa. Gateway sovittaa live-datalähteen — LINK 16:n, NFFI:n, CoT:n, alueinstrumentoinnin — HLA-federaatioon. Jokaisen gatewayn on suoritettava useita toimintoja samanaikaisesti.

Protokollamuunnos muuntaa saapuvan viestimuodon RPR-FOM-attribuuttipäivityksiksi. Tämä ei ole puhtaasti mekaanista: LINK 16 J-sarjan viestit koodaavat entiteetin sijainnin WGS-84-geodeettisissa koordinaateissa, kun taas HLA RPR-FOM käyttää geosentrisiä karteesisia koordinaatteja (maanskeskinen, maahan kiinnitetty). Gatewayn on suoritettava koordinaattijärjestelmämuunnos jokaista sijaintipäivitystä varten. Nopeusavoktorit, jos ne ovat läsnä live-syötteessä, on muunnettava yhdenmukaisesti. Entiteettityyppikartoitus LINK 16 -emissiotyppikoodeista RPR-FOM EntityType -arvoihin vaatii ylläpidetyn käännöstaulukon — uudet kalustoyksiköt on lisättävä eksplisiittisesti, ja monitulkintaiset koodit (joissa yksi LINK 16 -tyyppi kartoittuu useisiin alustatyyppeihin) vaativat heuristisen ratkaisun.

Entiteettielinkaaren hallinta käsittelee live-entiteettien ilmestymisen, pysymisen ja katoamisen HLA-federaatiossa. Kun gateway näkee seurannan ensimmäisen kerran, se luo HLA-objekti-instanssin ja ottaa sen omistuksen. Kun seuranta menetetään (GPS-katkos, maastoon peitattu ajoneuvo), gatewayn on päätettävä, pidetäänkö dead-reckoned-sijaintiestimaatti voimassa armonaikana vai poistetaanko objekti välittömästi. Ennenaikainen poisto ja nopea uudelleenrekisteröinti luo objekti-identiteettikatkoksia, jotka hämmentävät konstruktiivisen OPFOR:n maalitusloogiikkaa. Pitkittynyt dead-reckoning menetetyistä seurannoista luo haamuEntiteettejä, jotka heikentävät harjoitusjoukkojen tilannetietoisuuskuvaa.

Nopeussovitus sovittaa live-lähteen päivitystahdin simulaation odotuksiin. GPS-seuratin, joka päivittyy 1 Hz:llä, ei voi injektoida päivityksiä 20–30 Hz:n nopeudella, jota konstruktiiviset entiteetit käyttävät; gatewayn on julkaistava live-nopeudella ja konfiguroitava dead-reckoning-parametrit (nopeus ja kiihtyvyys) HLA-entiteettitilassa niin, että vastaanottavat federaatit voivat ekstrapoloida sijainnin päivitysten välillä. Dead-reckoning-parametrien on oltava realistisia — telaketjuajoneuvolle ei voi asettaa lentokoneen dead-reckoning-mallia.

Pilvi-isännöity LVC: arkkitehtuuri ja viivelimitbudjetti

LVC-taustapalvelukomponenttien siirtäminen valtion pilviympäristöön — Azure Government tai luokiteltu IL5/IL6-vastine — on operationaalisesti houkuttelevaa, koska se poistaa fyysisen palvelininfrastruktuurin toimittamisen ja konfiguroinnin tarpeen jokaiselle harjoituspaikalle. Pilvi-isännöity konstruktiivinen simulaatiofederaatio voi palvella useita maantieteellisesti hajautettuja harjoituspaikkoja samanaikaisesti, kun virtuaalisimulaattorilaitteet ja live-joukkojen gatewayt eri sijainneissa kaikki federoidaan yhteiseen pilvi-isännöityyn HLA-federaatioon.

Kriittinen rajoitus on viive. HLA-aikahallinta reaaliaikaisessa tilassa myöntää aikaedistyksiä lookahead-konfiguraation ja RTI:n sydänlyöntisyklin määräämissä väleissä. Reaaliaika-LVC-federaatiolle käytännön vaatimus on, että entiteettitila-päivitykset saavuttavat kaikki tilaavat federaatit 100–150 ms:n kuluessa generoinnista — tuon kynnyksen yli konstruktiivinen OPFOR-manööverilogiikka alkaa toimia vanhentuneella sijaintidatalla, ja virtuaalisimulaattorien miehistöt näkevät live-entiteettien teleporttaavan liikkeen sijaan.

Pilvi-isännöidyn RTI:n, joka palvelee maantieteellisesti hajautettuja federaatteja, sijainti on optimoitava pahimman tapauksen edestakaisviiveen minimoimiseksi. Azure Government -alueet Yhdysvaltain mantereella saavuttavat noin 20–40 ms:n edestakaisviiveen useimmille CONUS-harjoituspaikoille omistettuja valtion verkkoyhteyksiä (ei julkista internetiä) käyttäen. Eurooppalaiset harjoituspaikat, jotka ottavat yhteyttä US-pilvipalvelualueeseen, kohtaavat 80–120 ms:n edestakaisviiveen. Tämä on 150 ms:n kynnyksen sisällä konstruktiivisille ja virtuaalisille komponenteille, mutta marginaalinen live-joukkojen gatewayille, joiden on reagoitava suuren taajuuden sensorisyötteisiin.

Suositeltu arkkitehtuuri jakaa HLA-federaation maantieteellisiin kerroksiin. Konstruktiivinen simulaatio, skenaariohallinta ja AAR-tallennus toimivat pilvessä. Virtuaaliset simulaattorit ja live-joukkojen gatewayt toimivat jokaisella harjoituspaikalla paikallisen RTI-proxyn kanssa, joka silloittaa pilvi-federaatioon. Paikallinen proxy välimuistittaa entiteettitilan paikallisen paikan kiinnostusalueelle, tarjoten päivityksiä paikallisille federaateille välimuistista eikä vaadi pyöreää matkaa pilvi-RTI:hin jokaiselle attribuuttipäivitykselle. Tämä pitää paikallisten entiteettien vuorovaikutukset alle 5 ms:ssa samalla kun globaali federaation tila synkronoidaan pilvipohjaisen rungon kautta.

Vaikutukset konstruktiivisille simulaatiokomponenteille

LVC-federaation konstruktiivisella simulaatiokomponentilla on vastuita pelkän entiteettikäyttäytymisen generoimisen lisäksi. Sen on ylläpidettävä koherentti entiteettitila LVC-rajan yli — tunnistettava oikein, mitkä entiteetit ovat live-, mitkä virtuaali- ja mitkä konstruktiivisia, ja sovellettava asianmukaisia taistelullisia sääntöjä ja sitomisloogiikkaa jokaiseen kategoriaan. Konstruktiivisen OPFOR-elementin tulisi kyetä sitomaan sekä live- että virtuaalisia ystävällisiä entiteettejä johdonmukaisella logiikalla; mutta sen ei pidä yrittää sitoa entiteettejä, jotka ovat instrumentointiartifakteja (päällekkäiset live-seurannat, testitestientiteetit, jotka on injektoitu integraation debuggausta varten).

Konstruktiivisen tekoälyn käyttäytymisen on myös otettava huomioon live-entiteettidatalle ominainen viive ja epävarmuus. Kaikkivoipainen konstruktiivinen järjestelmä, joka on suunniteltu kaikki-konstruktiiviseen ympäristöön, olettaa täydellisen tiedon kaikkien entiteettien sijainneista, päivitettynä simulaation omalla aika-askeleella. Kun live-entiteettidata saapuu 1 Hz:llä satunnaisten aukkojen kera, konstruktiivisen tekoälyn on käytettävä ekstrapoloituja sijainteja kohdistus- ja manööverisuunnitteluun — ja sen on hajoittava sulavasti, kun live-seurannat katoavat, eikä kohdeltava seurannan menetystä entiteetin tuhoutumisena.

Konstruktiivisen simulaation skenaariohallintakerros ohjaa myös harjoituksen johtamispäätöksiä, jotka vaikuttavat live-toimialueeseen: milloin tuoda lisää vahvennuksia, milloin heikentää viestintää, milloin siirtyä konstruktiivisesta OPFOR:sta live-OPFOR:iin harjoituksen tietyssä vaiheessa. Esikuntasuunnitteluharjoitukset konstruktiivisella simulaatiolla hyötyvät tästä joustavuudesta — harjoituksen johtamistiimi voi injektoida ärsykkeitä live-toimialueeseen konstruktiivisen kerroksen kautta keskeyttämättä live-joukkojen toimintavapautta.