Integrarea live-virtual-constructiv (LVC) pentru antrenamentul de apărare

Antrenamentul colectiv la scară largă — cel care pregătește state majore de brigadă pentru a sincroniza focul, manevra și logistica pe un câmp de luptă multi-domeniu — nu poate fi realizat ieftin doar cu forțe reale. Exercițiile reale consumă muniție, uzează vehiculele și necesită deconflictarea a mii de kilometri pătrați de spațiu aerian și terestru. Simulatoarele virtuale comprimă geografia și elimină costurile cu consumabilele, dar nu pot replica frecarea, latența comunicațiilor și epuizarea fizică ale operațiunilor reale. Simularea constructivă se scalează ieftin până la nivelul de divizie sau corp de armată, dar entitățile pe care le generează sunt abstracții controlate de computer, nu soldați. Fiecare domeniu surprinde o parte din tabloul antrenamentului. Integrarea live-virtual-constructiv (LVC) încearcă să combine toate trei într-un singur mediu sintetic coerent — oferind publicului de antrenament o combinație realistă de forțe reale, simulatoare cu echipaj și entități generate de computer simultan. Arhitectura care face ca aceasta să funcționeze constituie subiectul acestui articol.

Ce înseamnă live, virtual și constructiv

Termenii sunt definiți prin gradul de operare cu om în buclă. Live înseamnă persoane reale care operează echipamente reale în mediul fizic. Un pluton de tancuri care conduce M1A2-uri pe un poligon de antrenament este un element real. Instrumentarea — trackere GPS, simulatoare de efecte ale armelor precum MILES, radio-uri vocale — permite sistemului de control al exercițiului să observe și să înregistreze ce fac elementele reale, dar forțele în sine sunt prezente fizic. Elementele reale reprezintă standardul de aur pentru realismul antrenamentului individual și la nivelul echipajului; sunt scumpe și greu de scalat.

Virtual înseamnă un operator uman care interacționează cu o platformă simulată în interiorul unui simulator. Operatorul este real și exersează abilități cognitive și procedurale reale, dar platforma și mediul sunt sintetice. Steel Beasts Pro PE, Prepar3D și simulatoarele de misiune aeronautică sunt medii virtuale. Elementele virtuale sunt mai puțin costisitoare pe oră de antrenament decât cele reale, pot reprezenta platforme rare sau aflate în mentenanță și pot fi resetate la orice stare de scenariu instantaneu. Limitarea lor constă în faptul că modelele simulate de fizică și senzori, oricât de detaliate, rămân aproximări.

Constructiv înseamnă entități generate de computer controlate de software — AI, modele de comportament scriptate sau controlori de exercițiu umani care acționează ca forțe agregate. Niciun om individual nu este în buclă pentru fiecare entitate. OneSAF, JCATS și WARG sunt sisteme de simulare constructivă. Simularea constructivă se scalează la exerciții la nivel de corp de armată cu zeci de mii de entități la o fracțiune din costul forțelor echivalente reale sau virtuale. Compromisul este realismul redus la nivelul entității individuale și angajamentul redus cu publicul de antrenament pe sarcini care necesită o sarcină cognitivă autentică din partea forței adverse.

Integrarea LVC le combină pe toate trei. Un exercițiu de brigadă poate avea un batalion de infanterie real pe un poligon real, echipaje virtuale de rotorcraft care zboară cu elicoptere simulate dintr-o facilitate simulator, și un OPFOR constructiv de dimensiunea unui regiment al cărui comportament este ghidat de o mică echipă de control al exercițiului. Valoarea de antrenament a mediului combinat depășește ceea ce ar putea oferi oricare domeniu individual: batalionul real se confruntă cu presiune tactică coerentă din partea unui OPFOR constructiv mare, cu comportament realist, coordonat cu sprijin aerian virtual care reacționează la evenimentele terestre aproape în timp real.

Provocarea interoperabilității

Combinarea celor trei domenii este netrivială din punct de vedere arhitectural, deoarece fiecare domeniu a fost dezvoltat independent și utilizează protocoale, baze de timp și modele de entități diferite. Forțele reale comunică prin LINK 16, VMF, NFFI (NATO Friendly Force Information) sau fluxuri Cursor on Target (CoT) din sistemele de instrumentare. Simulatoarele virtuale vorbesc de obicei DIS (Distributed Interactive Simulation, IEEE 1278) sau HLA (High Level Architecture, IEEE 1516). Sistemele de simulare constructivă vorbesc HLA — de obicei varianta RPR-FOM (Real-time Platform Reference Federation Object Model) — sau TENA (Test and Training Enabling Architecture) în contextele de instrumentare a poligoanelor.

Trei lacune de interoperabilitate fac integrarea LVC dificilă în practică. Prima este heterogenitatea protocoalelor: un mesaj de urmărire LINK 16 și o actualizare a atributului EntityState HLA RPR-FOM reprezintă conceptual același lucru (poziția și starea unei entități militare), dar în formate binare complet diferite, cu semantici diferite ale câmpurilor și prin mecanisme de transport diferite. Un gateway trebuie să traducă între ele fără a pierde informații sau a introduce ambiguitate.

A doua lacună este nepotrivirea latenței. O urmărire GPS reală de la un vehicul instrumentat se actualizează la 1 Hz. Un simulator virtual de tanc își actualizează starea entității la 20-30 Hz folosind dead-reckoning între actualizări. O simulare constructivă care rulează în timp real poate actualiza pozițiile entităților la rate variabile în funcție de activitatea entităților. Când aceste fluxuri ajung într-un mediu sintetic comun, pozițiile entităților trebuie să fie amestecate coerent — un vehicul real care se actualizează la 1 Hz va părea că sare dacă poziția sa este pur și simplu transmisă la rata de actualizare reală, în loc să fie netezită cu extrapolare dead-reckoning consistentă cu pasul de timp al simulării.

A treia lacună este identitatea entităților. Același tanc fizic care apare în domeniul real, urmărit de instrumentarea poligonului, reprezentat de un echipaj de simulator virtual și replicat ca entitate constructivă pentru conștientizarea forței adverse trebuie identificat corect ca o singură entitate în toate domeniile — nu ca trei entități separate care se întâmplă să ocupe aceeași locație. Gestionarea identității la granițele dintre domenii, în special când entitățile tranzitează între reprezentarea reală și cea constructivă în timpul unui exercițiu, este unul dintre cele mai expuse la erori aspecte ale arhitecturii LVC.

HLA ca coloană vertebrală LVC

HLA (High Level Architecture, IEEE 1516) este standardul dominant de federație pentru conectarea componentelor LVC deoarece oferă serviciile necesare pentru a gestiona un mediu de simulare multi-federat la scară. Protocolul HLA în sine este acoperit în detaliu separat; aici accentul este pus pe modul în care HLA funcționează specific într-un context LVC.

Într-o federație LVC, fiecare componentă majoră — sistemul de simulare constructivă, fiecare site de simulator virtual și fiecare adaptor gateway pentru fluxurile de forțe reale — se alătură federației HLA ca federat. RTI (Run-Time Infrastructure) gestionează comunicarea între federați utilizând FOM (Federation Object Model) al federației, bazat de obicei pe SISO RPR-FOM 2.0 pentru interoperabilitate NATO.

Gestionarea federației gestionează ciclul de viață al exercițiului: crearea federației, alăturarea și retragerea federaților, punctele de sincronizare (utilizate pentru a coordona pornirea, pauza și repornirea scenariului în toate componentele) și distrugerea federației. Într-un exercițiu LVC multi-site, punctele de sincronizare sunt critice — fără ele, un federat poate începe să avanseze timpul scenariului în timp ce altul se inițializează încă, corupând starea entităților la limita de demarcație.

Gestionarea timpului într-o federație LVC este configurată de obicei ca timp real best-effort, mai degrabă decât simulare strict gestionată temporal, deoarece forțele reale nu pot fi oprite sau încetinite pentru a acomoda granturi de avans temporal. RTI rulează în modul timp real; federatele constructive și virtuale publică actualizări cu marcaj temporal, dar nu blochează avansul temporal al federației pentru date reale care sosesc cu întârziere. Aceasta înseamnă că componentele constructive și virtuale trebuie să tolereze actualizări ocazionale de stare a entităților în afara ordinii de la gateway-urile reale.

Gestionarea Distribuției Datelor (DDM) este esențială la scara LVC. Un exercițiu la nivel de corp de armată poate avea mii de entități pe o zonă geografică de sute de kilometri. Fără DDM, fiecare federat primește fiecare actualizare de stare a entităților — o lățime de bandă și o sarcină de procesare care va copleși simulatoarele de post de comandă interesate doar de un rază tactică de 50 km. Regiunile de abonament DDM, configurate pentru a corespunde zonei de interes operațional a fiecărui federat, reduc aceasta la un volum gestionabil.

DIS în LVC: încă relevant pentru componentele virtuale

În ciuda avantajelor arhitecturale ale HLA, DIS (IEEE 1278) rămâne prezent în mediile LVC deoarece o bază instalată mare de simulatoare virtuale vorbește DIS nativ și nu poate fi re-integrată cost-eficient la HLA. Steel Beasts Pro, multe simulatoare de zbor moștenite și instrumente mai vechi de exerciții de post de comandă au fost proiectate pentru medii DIS. Înlocuirea lor nu este fezabilă în cadrul majorității bugetelor de program.

Soluția este un bridge DIS-la-HLA: un gateway care participă în rețeaua multicast DIS ca participant DIS și simultan ca federat HLA, traducând PDU-urile DIS în actualizări de stare a entităților RPR-FOM și invers. Bridge-ul trebuie să gestioneze cu atenție diferențele semantice. PDU-urile DIS Entity State utilizează algoritmi de dead-reckoning (definiți în standard) pentru a netezi poziția între actualizări; bridge-ul trebuie să aplice același dead-reckoning pe datele DIS de intrare înainte de a publica în HLA pentru a evita discontinuitățile de poziție. Bridge-ul trebuie să mapeze și codurile de tip entitate DIS (care utilizează o enumerare ierarhică definită în SISO ENUM-70) la atributele EntityType HLA RPR-FOM folosind aceeași enumerare — neconcordanțele în codificarea tipului de entitate fac ca OPFOR-ul constructiv să clasifice greșit platformele virtuale prietenoase.

Gestionarea ratei PDU este o preocupare practică. Un mediu DIS cu 200 de simulatoare virtuale fiecare publicând la 30 Hz generează 6.000 de PDU-uri pe secundă pe rețeaua multicast. Bridge-ul DIS-la-HLA trebuie să filtreze aceasta folosind praguri deadband — transmitând actualizări doar când poziția, viteza sau orientarea depășesc un prag definit — pentru a evita saturarea federației HLA cu actualizări care reprezintă mișcări nesemnificative.

Arhitectura gateway-ului LVC

Nivelul gateway este arhitectural cea mai critică și mai predispusă la eșec componentă a unei integrări LVC. Un gateway adaptează o sursă de date reale — LINK 16, NFFI, CoT, instrumentare poligon — în federația HLA. Fiecare gateway trebuie să îndeplinească mai multe funcții simultan.

Traducerea protocolului convertește formatul mesajului de intrare în actualizări de atribute RPR-FOM. Aceasta nu este pur mecanică: mesajele J-series LINK 16 codifică poziția entității în coordonate geodezice WGS-84, în timp ce HLA RPR-FOM utilizează un sistem de coordonate cartezian geocentric (centrat pe Pământ, fix pe Pământ). Gateway-ul trebuie să efectueze transformarea sistemului de coordonate pentru fiecare actualizare de poziție. Vectorii de viteză, dacă sunt prezenți în fluxul real, trebuie transformați consistent. Maparea tipului de entitate din codurile de tip de emisie LINK 16 la valorile EntityType RPR-FOM necesită un tabel de traducere întreținut — tipurile de echipamente noi trebuie adăugate explicit, iar codurile ambigue (unde un tip LINK 16 se mapează la mai multe tipuri de platforme) necesită rezolvare euristică.

Gestionarea ciclului de viață al entităților gestionează apariția, persistența și dispariția entităților reale în federația HLA. Când gateway-ul vede prima dată o urmărire, creează o instanță de obiect HLA și preia proprietatea acesteia. Când urmărirea este pierdută (pana GPS, vehicul mascat de teren), gateway-ul trebuie să decidă dacă să mențină o estimare de poziție dead-reckoned pe o perioadă de grație sau să elimine imediat obiectul. Eliminarea prematură urmată de re-înregistrare rapidă creează discontinuități de identitate a obiectelor care confundă logica de țintire a OPFOR-ului constructiv. Dead-reckoning-ul extins al urmăririlor pierdute creează entități fantomă care degradează tabloul situațional al publicului de antrenament.

Adaptarea ratei potrivește cadența de actualizare a sursei reale cu așteptările simulării. Un tracker GPS care se actualizează la 1 Hz nu poate injecta actualizări la rata de 20-30 Hz pe care o folosesc entitățile constructive; gateway-ul trebuie să publice la rata reală și să configureze parametrii de dead-reckoning (viteză și accelerație) în starea entității HLA astfel încât federatele care primesc să poată extrapola poziția între actualizări. Parametrii de dead-reckoning trebuie setați realist — un vehicul pe șenile nu poate fi atribuit modelului de dead-reckoning al unei aeronave.

LVC găzduit în cloud: arhitectură și buget de latență

Mutarea componentelor back-end LVC într-un mediu cloud guvernamental — Azure Government sau un echivalent clasificat IL5/IL6 — este atractivă operațional deoarece elimină necesitatea de a transporta și configura infrastructura fizică de server la fiecare site de exercițiu. O federație de simulare constructivă găzduită în cloud poate deservi mai multe site-uri de exercițiu dispersate geografic simultan, cu facilități de simulator virtual și gateway-uri de forțe reale la locații diferite, toate federând într-o federație HLA comună găzduită în cloud.

Constrângerea critică este latența. Gestionarea timpului HLA în modul timp real acordă avansuri temporale la intervale determinate de configurația lookahead și de ciclul de bătaie al RTI-ului. Pentru o federație LVC în timp real, cerința practică este că actualizările de stare a entităților să ajungă la toți federatele abonate în 100-150 ms de la generare — dincolo de acel prag, logica de manevră a OPFOR-ului constructiv începe să acționeze pe date de poziție depreciate, iar echipajele simulatoarelor virtuale văd entitățile reale teleportându-se în loc să se miște lin.

Un RTI găzduit în cloud care deservește federatele la site-uri dispersate geografic trebuie să fie localizat pentru a minimiza latența worst-case dus-întors. Regiunile Azure Government din Statele Unite continentale ating aproximativ 20-40 ms dus-întors către majoritatea site-urilor de antrenament CONUS pe căi de rețea guvernamentale dedicate (nu internet public). Site-urile de antrenament europene care ajung la o regiune cloud din SUA se confruntă cu 80-120 ms dus-întors. Aceasta se încadrează în pragul de 150 ms pentru componentele constructive și virtuale, dar este marginal pentru gateway-urile de forțe reale care trebuie să răspundă la fluxuri de senzori cu rată ridicată.

Arhitectura recomandată împarte federația HLA pe niveluri geografice. Simularea constructivă, gestionarea scenariilor și înregistrarea AAR rulează în cloud. Simulatoarele virtuale și gateway-urile de forțe reale rulează la fiecare site de exercițiu cu un proxy RTI local care se conectează la federația cloud. Proxy-ul local memorează în cache starea entităților pentru zona de interes a site-ului local, servind actualizări federaților locali din cache în loc să necesite un dus-întors la RTI-ul cloud pentru fiecare actualizare de atribut. Aceasta menține interacțiunile local-la-local sub 5 ms, sincronizând în același timp starea globală a federației prin backbone-ul cloud.

Implicații pentru componentele de simulare constructivă

Componenta de simulare constructivă dintr-o federație LVC are responsabilități dincolo de simpla generare a comportamentului entităților. Trebuie să mențină starea coerentă a entităților la granița LVC — identificând corect care entități sunt reale, care sunt virtuale și care sunt constructive, și aplicând regulile de angajare și logica de angajare corespunzătoare fiecărei categorii. Un element OPFOR constructiv ar trebui să poată angaja atât entitățile prietenoase reale, cât și cele virtuale cu logică consistentă; dar nu trebuie să încerce să angajeze entitățile care sunt artefacte de instrumentare (urmăriri reale duplicate, entități de test injectate pentru depanarea integrării).

Comportamentul AI constructiv trebuie să țină cont și de latența și incertitudinea inerente datelor entităților reale. Un sistem constructiv proiectat pentru un mediu în întregime constructiv presupune cunoaștere perfectă a tuturor pozițiilor entităților, actualizate la propriul pas de timp al simulării. Când datele entităților reale sosesc la 1 Hz cu goluri ocazionale, AI-ul constructiv trebuie să utilizeze poziții extrapolate pentru deciziile de țintire și manevră — și trebuie să degradeze grațios când urmăririle reale se sting, în loc să trateze pierderea urmăririi ca distrugere a entității.

Nivelul de gestionare a scenariilor al simulării constructive conduce și deciziile de control al exercițiului care afectează domeniul real: când să introducă întăriri, când să degradeze comunicațiile, când să treacă de la OPFOR constructiv la OPFOR real pentru o fază specifică a exercițiului. Exercițiile de planificare pentru state majore folosind simulare constructivă beneficiază de această flexibilitate — echipa de control a exercițiului poate injecta stimuli în domeniul real prin nivelul constructiv fără a întrerupe libertatea de acțiune a forței reale.