Integracja live-virtual-constructive (LVC) w szkoleniach obronnych

Szkolenia zbiorowe na dużą skalę — tego rodzaju, które przygotowują sztaby brygad do synchronizowania ognia, manewrów i logistyki w wielodomenowej przestrzeni walki — nie mogą być prowadzone tanio wyłącznie z udziałem sił rzeczywistych. Ćwiczenia rzeczywiste zużywają amunicję, niszczą pojazdy i wymagają dekonfliktowania tysięcy kilometrów kwadratowych przestrzeni powietrznej i terenu. Wirtualne symulatory kompresują geografię i eliminują koszty materiałów eksploatacyjnych, ale nie mogą odtworzyć tarcia, opóźnień komunikacyjnych i fizycznego wyczerpania rzeczywistych operacji. Symulacja konstruktywna skaluje się tanio do poziomu dywizji lub korpusu, ale generowane przez nią jednostki to sterowane komputerowo abstrakcje, nie żołnierze. Każda domena oddaje część obrazu szkoleniowego. Integracja live-virtual-constructive (LVC) próbuje połączyć wszystkie trzy w jednym spójnym środowisku syntetycznym — zapewniając uczestnikom szkolenia realistyczne połączenie sił rzeczywistych, symulatorów z załogą i jednostek generowanych komputerowo jednocześnie. Architektura, która to umożliwia, jest tematem niniejszego artykułu.

Co oznaczają pojęcia live, virtual i constructive

Terminy te są definiowane przez stopień udziału człowieka w pętli sterowania. Live (rzeczywiste) oznacza prawdziwych ludzi obsługujących rzeczywisty sprzęt w środowisku fizycznym. Pluton czołgów prowadzący wozy M1A2 na poligonie to element rzeczywisty. Instrumentacja — lokalizatory GPS, symulatory efektów uzbrojenia jak MILES, radia głosowe — pozwala systemowi kontroli ćwiczenia obserwować i rejestrować działania elementów rzeczywistych, ale same siły są fizycznie obecne. Elementy rzeczywiste są złotym standardem realizmu szkolenia na poziomie indywidualnym i załogowym; są kosztowne i trudne do skalowania.

Virtual (wirtualne) oznacza operatora ludzkiego wchodzącego w interakcję z symulowaną platformą wewnątrz symulatora. Operator jest prawdziwy i ćwiczy prawdziwe umiejętności poznawcze i proceduralne, ale platforma i środowisko są syntetyczne. Steel Beasts Pro PE, Prepar3D i lotnicze symulatory misji to środowiska wirtualne. Elementy wirtualne są mniej kosztowne za godzinę szkolenia niż rzeczywiste, mogą reprezentować platformy rzadkie lub w naprawie i mogą być natychmiast resetowane do dowolnego stanu scenariusza. Ich ograniczeniem jest to, że symulowana fizyka i modele czujników, niezależnie od szczegółowości, są nadal przybliżeniami.

Constructive (konstruktywne) oznacza jednostki generowane komputerowo, sterowane przez oprogramowanie — AI, skryptowe modele zachowań lub kontrolerów ćwiczenia działających jako siły zbiorcze. Żaden indywidualny człowiek nie jest w pętli dla każdej jednostki. OneSAF, JCATS i WARG to konstruktywne systemy symulacyjne. Symulacja konstruktywna skaluje się do ćwiczeń na poziomie korpusu z dziesiątkami tysięcy jednostek za ułamek kosztu równoważnych sił rzeczywistych lub wirtualnych. Kompromisem jest zmniejszony realizm na poziomie poszczególnych jednostek i mniejsze zaangażowanie uczestników szkolenia w zadania wymagające prawdziwego obciążenia poznawczego ze strony sił przeciwnika.

Integracja LVC łączy wszystkie trzy. Ćwiczenie brygady może mieć rzeczywisty batalion piechoty na prawdziwym poligonie, wirtualne załogi śmigłowców latające na symulowanych helikopterach z centrum symulatorowego oraz konstruktywny OPFOR o rozmiarach pułku, którego zachowaniem kieruje mały zespół kontroli ćwiczenia. Wartość szkoleniowa połączonego środowiska przewyższa to, co mogłaby zapewnić każda z domen z osobna: rzeczywisty batalion napotyka taktycznie spójną presję ze strony dużego, realistycznie zachowującego się konstruktywnego OPFOR-u, skoordynowanego z wirtualnym wsparciem lotniczym reagującym na zdarzenia naziemne w czasie zbliżonym do rzeczywistego.

Wyzwanie interoperacyjności

Łączenie trzech domen jest architektonicznie nietrywialnym zadaniem, ponieważ każda domena była rozwijana niezależnie i używa różnych protokołów, podstaw czasowych i modeli jednostek. Siły rzeczywiste komunikują się przez LINK 16, VMF, NFFI (NATO Friendly Force Information) lub kanały Cursor on Target (CoT) z systemów instrumentacji. Wirtualne symulatory zazwyczaj używają DIS (Distributed Interactive Simulation, IEEE 1278) lub HLA (High Level Architecture, IEEE 1516). Konstruktywne systemy symulacyjne używają HLA — zazwyczaj wariantu RPR-FOM (Real-time Platform Reference Federation Object Model) — lub TENA (Test and Training Enabling Architecture) w kontekstach instrumentacji poligonowej.

Trzy luki interoperacyjności sprawiają, że integracja LVC jest w praktyce trudna. Pierwszą jest heterogeniczność protokołów: komunikat śledzenia LINK 16 i aktualizacja atrybutu EntityState HLA RPR-FOM reprezentują koncepcyjnie to samo (pozycję i stan jednostki wojskowej), ale w zupełnie różnych formatach binarnych, z różną semantyką pól i przez różne mechanizmy transportowe. Brama musi tłumaczyć między nimi bez utraty informacji ani wprowadzania niejednoznaczności.

Drugą luką jest niezgodność opóźnień. Ślad GPS z instrumentowanego pojazdu aktualizuje się z częstotliwością 1 Hz. Wirtualny symulator czołgu aktualizuje stan swojej jednostki z częstotliwością 20–30 Hz, używając ekstrapolacji dead-reckoning między aktualizacjami. Symulacja konstruktywna działająca w czasie rzeczywistym może aktualizować pozycje jednostek z różnymi częstotliwościami w zależności od aktywności jednostki. Gdy te kanały docierają do wspólnego środowiska syntetycznego, pozycje jednostek muszą być spójnie mieszane — pojazd rzeczywisty aktualizujący się z częstotliwością 1 Hz będzie wydawał się skakać, jeśli jego pozycja jest po prostu przekazywana dalej z częstotliwością aktualizacji rzeczywistej, zamiast być wygładzona ekstrapolacją dead-reckoning spójną z krokiem czasowym symulacji.

Trzecią luką jest tożsamość jednostek. Ten sam fizyczny czołg widoczny w domenie rzeczywistej, śledzony przez instrumentację poligonową, reprezentowany przez załogę wirtualnego symulatora i replikowany jako jednostka konstruktywna dla świadomości sił przeciwnika, musi być poprawnie identyfikowany jako jedna jednostka we wszystkich domenach — nie jako trzy oddzielne jednostki zajmujące tę samą lokalizację. Zarządzanie tożsamością ponad granicami domen, szczególnie gdy jednostki przechodzą między reprezentacją rzeczywistą a konstruktywną podczas ćwiczenia, jest jednym z najbardziej podatnych na błędy aspektów architektury LVC.

HLA jako szkielet LVC

HLA (High Level Architecture, IEEE 1516) jest dominującym standardem federacyjnym do łączenia komponentów LVC, ponieważ zapewnia usługi potrzebne do zarządzania wielofederatowym środowiskiem symulacyjnym w skali. Sam protokół HLA jest szczegółowo omówiony oddzielnie; tutaj skupiamy się na tym, jak HLA funkcjonuje konkretnie w kontekście LVC.

W federacji LVC każdy główny komponent — konstruktywny system symulacyjny, każde stanowisko wirtualnego symulatora i każdy adapter bramkowy dla kanałów sił rzeczywistych — dołącza do federacji HLA jako federat. RTI (Run-Time Infrastructure) zarządza komunikacją między federatami używając FOM (Federation Object Model) federacji, zazwyczaj opartego na SISO RPR-FOM 2.0 dla interoperacyjności NATO.

Zarządzanie federacją obsługuje cykl życia ćwiczenia: tworzenie federacji, dołączanie i odchodzenie federatów, punkty synchronizacji (używane do koordynacji startu, pauzy i restartu scenariusza we wszystkich komponentach) oraz niszczenie federacji. W wielostanowiskowym ćwiczeniu LVC punkty synchronizacji są kluczowe — bez nich jeden federat może zacząć posuwać czas scenariusza naprzód, podczas gdy inny wciąż się inicjalizuje, psując stan jednostek na granicy.

Zarządzanie czasem w federacji LVC jest zazwyczaj skonfigurowane jako best-effort w czasie rzeczywistym, a nie ścisła symulacja zarządzana czasem, ponieważ sił rzeczywistych nie można pauzować ani spowalniać, aby uwzględnić przyznania awansów czasowych. RTI działa w trybie czasu rzeczywistego; konstruktywne i wirtualne federaty publikują aktualizacje ze znacznikami czasu, ale nie wstrzymują federacyjnego awansu czasowego dla późno przychodzących danych rzeczywistych. Oznacza to, że komponenty konstruktywne i wirtualne muszą tolerować sporadyczne aktualizacje stanu jednostek poza kolejnością z bramek rzeczywistych.

Zarządzanie dystrybucją danych (DDM) jest niezbędne w skali LVC. Ćwiczenie na poziomie korpusu może obejmować tysiące jednostek na obszarze geograficznym rozciągającym się na setki kilometrów. Bez DDM każdy federat otrzymuje każdą aktualizację stanu jednostki — obciążenie przepustowością i przetwarzaniem, które przytłoczy symulatory stanowisk dowodzenia zainteresowane tylko promieniem taktycznym 50 km. Regiony subskrypcji DDM, skonfigurowane tak, aby pasowały do obszaru zainteresowania operacyjnego każdego federatu, redukują to do zarządzalnego wolumenu.

DIS w LVC: nadal istotny dla komponentów wirtualnych

Mimo architektonicznych przewag HLA, DIS (IEEE 1278) pozostaje obecny w środowiskach LVC, ponieważ duża zainstalowana baza wirtualnych symulatorów natywnie mówi DIS i nie może być opłacalnie zintegrowana z HLA. Steel Beasts Pro, wiele starszych symulatorów lotniczych i starsze narzędzia do ćwiczeń stanowisk dowodzenia zostały zaprojektowane dla środowisk DIS. Zastąpienie ich nie jest możliwe w ramach większości budżetów programowych.

Rozwiązaniem jest most DIS-do-HLA: brama uczestnicząca w sieci multicast DIS jako uczestnik DIS i jednocześnie jako federat HLA, tłumacząca PDU DIS na aktualizacje stanu jednostek RPR-FOM i odwrotnie. Most musi ostrożnie obsługiwać różnice semantyczne. Jednostkowe PDU Stanu (Entity State PDU) DIS używają algorytmów dead-reckoning (zdefiniowanych w standardzie) do wygładzania pozycji między aktualizacjami; most musi stosować to samo dead-reckoning na przychodzących danych DIS przed publikowaniem do HLA, aby uniknąć nieciągłości pozycji. Most musi również mapować kody typów jednostek DIS (które używają hierarchicznego wyliczenia zdefiniowanego w SISO ENUM-70) na atrybuty EntityType HLA RPR-FOM używając tego samego wyliczenia — niezgodności w kodowaniu typów jednostek powodują, że konstruktywny OPFOR błędnie klasyfikuje wirtualne przyjazne platformy.

Zarządzanie częstotliwością PDU jest praktyczną kwestią. Środowisko DIS z 200 wirtualnymi symulatorami, z których każdy publikuje z częstotliwością 30 Hz, generuje 6000 PDU na sekundę w sieci multicast. Most DIS-do-HLA musi filtrować to za pomocą progów deadband — przekazując aktualizacje tylko wtedy, gdy pozycja, prędkość lub orientacja zmienią się powyżej zdefiniowanego progu — aby uniknąć nasycania federacji HLA aktualizacjami reprezentującymi nieistotny ruch.

Architektura bramy LVC

Warstwa bramkowa jest architektonicznie najważniejszym i najbardziej podatnym na awarie komponentem integracji LVC. Brama adaptuje źródło danych rzeczywistych — LINK 16, NFFI, CoT, instrumentacja poligonowa — do federacji HLA. Każda brama musi jednocześnie pełnić kilka funkcji.

Translacja protokołów konwertuje przychodzący format wiadomości na aktualizacje atrybutów RPR-FOM. Nie jest to czysto mechaniczne: komunikaty J-series LINK 16 kodują pozycję jednostki we współrzędnych geodezyjnych WGS-84, podczas gdy HLA RPR-FOM używa geocentrycznego kartezjańskiego układu współrzędnych (earth-centered, earth-fixed). Brama musi wykonywać transformację układu współrzędnych dla każdej aktualizacji pozycji. Wektory prędkości, jeśli są obecne w kanale rzeczywistym, muszą być spójnie transformowane. Mapowanie typów jednostek z kodów emisji LINK 16 na wartości EntityType RPR-FOM wymaga utrzymywanej tabeli translacji — nowe typy sprzętu muszą być dodawane explicite, a niejednoznaczne kody (gdzie jeden typ LINK 16 mapuje na wiele typów platform) wymagają heurystycznej rozdzielczości.

Zarządzanie cyklem życia jednostek obsługuje pojawienie się, utrzymanie i zniknięcie rzeczywistych jednostek w federacji HLA. Gdy brama po raz pierwszy widzi ślad, tworzy instancję obiektu HLA i przejmuje jej własność. Gdy ślad jest utracony (awaria GPS, pojazd zasłonięty przez teren), brama musi zdecydować, czy utrzymywać szacowaną pozycję dead-reckoning przez okres karencji, czy natychmiast usunąć obiekt. Przedwczesne usunięcie, po którym następuje szybka ponowna rejestracja, tworzy nieciągłości tożsamości obiektów, które dezorientują logikę namierzania konstruktywnego OPFOR-u. Rozszerzone dead-reckoning utraconych śladów tworzy jednostki-duchy, które degradują obraz sytuacyjny uczestników szkolenia.

Adaptacja częstotliwości dopasowuje rytm aktualizacji źródła rzeczywistego do oczekiwań symulacji. Lokalizator GPS aktualizujący się z częstotliwością 1 Hz nie może wstrzykiwać aktualizacji z częstotliwością 20–30 Hz, której używają jednostki konstruktywne; brama musi publikować z częstotliwością rzeczywistą i konfigurować parametry dead-reckoning (prędkość i przyspieszenie) w stanie jednostki HLA tak, aby odbierające federaty mogły ekstrapolować pozycję między aktualizacjami. Parametry dead-reckoning muszą być ustawione realistycznie — śledzonemu pojazdowi nie można przypisać modelu dead-reckoning samolotu.

LVC hostowane w chmurze: architektura i budżet opóźnień

Przeniesienie komponentów zaplecza LVC do rządowego środowiska chmurowego — Azure Government lub sklasyfikowanego odpowiednika IL5/IL6 — jest operacyjnie atrakcyjne, ponieważ eliminuje potrzebę transportowania i konfigurowania fizycznej infrastruktury serwerowej w każdym miejscu ćwiczenia. Hostowana w chmurze federacja symulacji konstruktywnej może jednocześnie obsługiwać wiele geograficznie rozproszonych stanowisk ćwiczenia, przy czym stanowiska symulatorów wirtualnych i bramki sił rzeczywistych w różnych lokalizacjach federują się we wspólną federację HLA hostowaną w chmurze.

Krytycznym ograniczeniem jest opóźnienie. Zarządzanie czasem HLA w trybie czasu rzeczywistego przyznaje awanse czasowe w odstępach określonych przez konfigurację lookahead i cykl heartbeat RTI. W federacji LVC czasu rzeczywistego praktyczny wymóg to dotarcie aktualizacji stanu jednostek do wszystkich subskrybujących federatów w ciągu 100–150 ms od wygenerowania — powyżej tego progu logika manewrowania konstruktywnego OPFOR zaczyna działać na przestarzałych danych pozycji, a załogi wirtualnych symulatorów widzą teleportujące się zamiast płynnie poruszające się rzeczywiste jednostki.

RTI hostowane w chmurze obsługujące federaty w geograficznie rozproszonych stanowiskach musi być zlokalizowane tak, aby minimalizować najgorszy przypadek opóźnienia round-trip. Regiony Azure Government w kontynentalnych Stanach Zjednoczonych osiągają około 20–40 ms round-trip do większości stanowisk szkoleniowych CONUS przez dedykowane rządowe ścieżki sieciowe (nie publiczny internet). Europejskie stanowiska szkoleniowe sięgające do regionalnego centrum chmury w USA mierzą się z opóźnieniem round-trip 80–120 ms. Mieści się to w progu 150 ms dla komponentów konstruktywnych i wirtualnych, ale jest marginesowe dla bramek sił rzeczywistych, które muszą reagować na kanały czujników o wysokiej częstotliwości.

Zalecana architektura dzieli federację HLA na warstwy geograficzne. Symulacja konstruktywna, zarządzanie scenariuszami i rejestrowanie AAR działają w chmurze. Wirtualne symulatory i bramki sił rzeczywistych działają w każdym stanowisku ćwiczenia z lokalnym serwerem proxy RTI, który łączy się z federacją chmurową. Lokalny serwer proxy buforuje stan jednostek dla obszaru zainteresowania lokalnego stanowiska, obsługując aktualizacje lokalnych federatów z pamięci podręcznej zamiast wymagać round-trip do chmurowego RTI dla każdej aktualizacji atrybutu. Utrzymuje to lokalne interakcje jednostek poniżej 5 ms przy jednoczesnej synchronizacji globalnego stanu federacji przez szkielet chmurowy.

Implikacje dla konstruktywnych komponentów symulacyjnych

Konstruktywny komponent symulacyjny w federacji LVC ma obowiązki wykraczające poza samo generowanie zachowań jednostek. Musi utrzymywać spójny stan jednostek ponad granicą LVC — poprawnie identyfikując, które jednostki są rzeczywiste, które wirtualne, a które konstruktywne, i stosując odpowiednie reguły zaangażowania i logikę angażowania do każdej kategorii. Element konstruktywnego OPFOR-u powinien być w stanie angażować zarówno rzeczywiste, jak i wirtualne przyjazne jednostki ze spójną logiką; ale nie może próbować angażować jednostek będących artefaktami instrumentacji (zduplikowane ślady rzeczywiste, jednostki testowe wstrzykiwane podczas debugowania integracji).

Konstruktywne zachowanie AI musi również uwzględniać opóźnienia i niepewność nieodłącznie związane z danymi rzeczywistych jednostek. System konstruktywny zaprojektowany dla środowiska całkowicie konstruktywnego zakłada doskonałą znajomość pozycji wszystkich jednostek, aktualizowaną we własnym kroku czasowym symulacji. Gdy dane rzeczywistych jednostek docierają z częstotliwością 1 Hz z okazjonalnymi przerwami, konstruktywna AI musi używać ekstrapolowanych pozycji dla decyzji namierzania i manewrowania — i musi gracefully degradować, gdy ślady rzeczywiste zanikają, zamiast traktować utratę śladu jako zniszczenie jednostki.

Warstwa zarządzania scenariuszem symulacji konstruktywnej napędza również decyzje kontroli ćwiczenia wpływające na domenę rzeczywistą: kiedy wprowadzić posiłki, kiedy degradować łączność, kiedy przejść z konstruktywnego OPFOR-u do rzeczywistego OPFOR-u dla określonej fazy ćwiczenia. Ćwiczenia planowania sztabowego z wykorzystaniem symulacji konstruktywnej korzystają z tej elastyczności — zespół kontroli ćwiczenia może wstrzykiwać bodźce do domeny rzeczywistej przez warstwę konstruktywną bez przerywania swobody działania sił rzeczywistych.