Systemy prób misji: architektura symulacji przedoperacyjnej

Symulator szkoleniowy uczy jednostkę, jak walczyć ogólnie. System prób misji (MRS) pozwala tej samej jednostce ćwiczyć konkretną operację, którą zamierza przeprowadzić – w wiernej cyfrowej reprodukcji rzeczywistego obszaru działań, przeciwko rzeczywistemu zagrożeniu, zgodnie z rzeczywistym planem. To rozróżnienie nie jest kosmetyczne. Zmienia dane wpływające do systemu, szybkość, z jaką musi być gotowy użyteczny scenariusz, oraz sposób mierzenia sukcesu. Niniejszy artykuł omawia pełną architekturę systemu prób misji: sposób pobierania danych o terenie i zagrożeniach, tworzenia scenariusza na podstawie planu misji, synchronizacji rozproszonych uczestników oraz rejestrowania przeglądu po akcji, tak aby próba rzeczywiście poprawiła plan.

Czym jest system prób misji – i czym nie jest

Doktryna prób jest stara. Przed każdą operacją o znaczeniu dowódcy próbują plan – historycznie jako przejście przez stolik z piaskiem lub ćwiczenie próby koncepcji (ROC), gdzie podwładni dowódcy fizycznie przesuwają znaczniki po skalowanym modelu terenu, aby potwierdzić schemat manewru i zsynchronizować harmonogram. System prób misji jest cyfrowym następcą tego ćwiczenia o wyższej wierności. Zachowuje cel – ujawnienie luk koordynacyjnych i sytuacji awaryjnych przed wykonaniem – ale zastępuje statyczny model terenu interaktywnym środowiskiem syntetycznym, obejmującym symulowane czujniki, łączność, pogodę i reaktywną siłę przeciwną.

Wyróżniającą właściwością MRS, oddzielającą go od ogólnej platformy symulacji szkoleniowej, jest to, że jest on specyficzny dla misji i aktualny w zakresie danych. Symulator szkoleniowy działa na standardowej mapie i generycznym przeciwniku; celem jest powtarzalny rozwój umiejętności. System prób misji działa na tej konkretnej dolinie, z tym konkretnym ugrupowaniem obrony przeciwlotniczej, w nocy planowanej operacji. Ten wymóg – aktualność ponad ogólność – napędza każdą późniejszą decyzję architektoniczną, ponieważ zmusza system do pobierania świeżych danych źródłowych i przekształcania ich w gotowy do próby scenariusz w operacyjnych ramach czasowych, a nie przez tygodnie, jakich może wymagać ręcznie zbudowany scenariusz szkoleniowy.

Przegląd architektury: pięć podsystemów

System prób misji składa się z pięciu podsystemów, z których każdy odpowiada etapowi cyklu życia próby:

1. Pobieranie terenu i środowiska. Konwertuje źródłowe dane wysokościowe, obrazowe i opisowe dotyczące obszaru działań na skorelowane środowisko syntetyczne. Jest to podsystem o najdłuższym czasie realizacji i dlatego najczęściej wstępnie przygotowywany.

2. Pobieranie zagrożeń i wiązanie zachowań. Importuje aktualny szablon sytuacji wroga i wiąże każdy element zagrożenia z modelem zachowania, tak aby siła przeciwna reagowała zamiast stać w bezruchu.

3. Tworzenie scenariusza. Importuje przyjazny plan misji – grafiki, harmonogram, wyzwalacze – i składa go w działający, wersjonowany scenariusz.

4. Rozproszony czas wykonania symulacji. Federuje wszystkie uczestniczące obiekty w jeden zsynchronizowany scenariusz, utrzymując spójny obraz sytuacji i czas na łączach o zmiennej jakości.

5. Rejestracja i przegląd po akcji. Nagrywa pełny przebieg do dziennika z indeksem czasowym i odtwarza go, aby przeprowadzić przegląd po akcji, zamykając pętlę z powrotem do planu.

Podsystemy są sekwencyjne w cyklu życia, ale sprzężone w modelu danych: wszystkie rozwiązują się względem jednego wspólnego obrazu sytuacji – pobranego terenu – tak aby obliczenia linii obserwacji, zasięgów broni, zasięgów czujników i pozycji elementów były przeprowadzane względem tej samej powierzchni, przez którą będą przemieszczać się siły przyjazne.

Pobieranie terenu i środowiska

Teren jest fundamentem i to tutaj próby misji są realizowane lub padają ze względu na czas realizacji. Potok pobierania przyjmuje dane wysokościowe – DTED poziom 2 jako minimum, DEM o wyższej rozdzielczości tam, gdzie jest dostępny – wraz z danymi obrazowymi lub wektorowymi opisującymi materiały powierzchni, roślinność, sieci dróg i struktury. Na ich podstawie buduje skorelowane środowisko 3D: pole wysokości, sklasyfikowaną mapę materiałów napędzającą przejezdność i zachowanie radaru/EO oraz dyskretne elementy, takie jak budynki i mosty, wpływające na osłonę, maskowanie i mobilność.

Trudnym problemem inżynieryjnym jest korelacja. Każdy podsystem i każdy uczestniczący klient musi obliczać względem tego samego obrazu sytuacji – jeśli klient manewrowy i klient wsparcia ogniowego różnią się co do wysokości grzbietu o dziesięć metrów, ich obliczenia linii obserwacji będą się różnić i próba wygeneruje fantomowe lub brakujące starcia. Potok musi zatem tworzyć jedną autorytatywną bazę danych terenu ładowaną przez wszystkie węzły, zamiast umożliwiać każdemu klientowi samodzielne wyprowadzanie powierzchni. Szczegółowy potok od danych źródłowych do pola wysokości w czasie wykonywania jest omówiony w naszym artykule o generowaniu terenu do symulacji wojskowej.

Środowisko to druga połowa wierności. Muszą zostać zastosowane warunki pogodowe i oświetlenie dla okna wykonania: oświetlenie i oświetlenie księżyca do nocnego szturmu, widoczność i pułap do ruchu lotniczego, opady i stan gruntu do oceny przejezdności. Próba prowadzona w jasnym dziennym świetle dla operacji planowanej we mgle i bez oświetlenia trenuje złe oczekiwania.

Pobieranie zagrożeń i wiązanie zachowań

Próba przeciwko statycznemu zagrożeniu niewiele różni się od ćwiczenia na mapie. Wartość MRS tkwi w próbie przeciwko przeciwnikowi reagującemu na działania przyjazne, tak aby plan był testowany pod kątem prawdopodobnych odpowiedzi wroga, a nie zamrożonego migawki.

Podsystem zagrożeń importuje aktualny szablon sytuacji wroga: znane i podejrzane pozycje, obwiednie obrony przeciwlotniczej, pasy przeszkód, zasoby wsparcia ogniowego i wyróżnione obszary zainteresowania. Każdy element zagrożenia jest geolokalizowany na pobranym terenie, tak aby pokrycie czujnikami i zasięgi broni były obliczane względem rzeczywistego terenu. Co istotne, każdy element jest następnie wiązany z modelem zachowania z utrzymywanej biblioteki zagrożeń – doktrynalnie ugruntowane modele sposobu, w jaki jednostki tego przeciwnika przemieszczają się, zajmują pozycje i angażują. To tutaj próby misji łączą się z szerszą dyscypliną sił generowanych komputerowo; modele zachowań używane tutaj należą do tej samej rodziny omówionej w naszym opracowaniu na temat AI przeciwnika opartego na doktrynie, przeskalowanej do konkretnych jednostek obecnych w tym obszarze działań.

Szablonowe biblioteki zagrożeń

Ponieważ próby misji są ograniczone czasowo, obraz zagrożeń jest składany z wstępnie zbudowanej biblioteki, a nie tworzony od podstaw. Utrzymywana biblioteka zawiera sparametryzowane typy jednostek przeciwnika – każdy z czujnikami, bronią, mobilnością i profilem zachowania – dzięki czemu komórka wywiadowcza instancjonuje je i pozycjonuje na terenie, zamiast modelować każdą z nich od zera. Biblioteka jest żywym zasobem: w miarę jak obraz zagrożeń ewoluuje, modele są aktualizowane i wersjonowane, a każda próba zapisuje dokładnie, na której wersji biblioteki działała, co umożliwia późniejsze odtworzenie lub audyt próby.

Tworzenie scenariusza z planu misji

Podsystem tworzenia scenariusza to miejsce, w którym składana jest przyjazna strona próby. Jego celem projektowym jest konsumowanie planu misji w jego istniejącej formie, a nie zmuszanie planistów do jego odtwarzania. Grafiki operacyjne jednostki – granice, linie fazowe, cele, osie natarcia, miary koordynacji wsparcia ogniowego – są importowane bezpośrednio do narzędzia autorskiego. Ręczne przerysowywanie jest zarówno powolne, jak i źródłem błędów, ponieważ ręcznie przerysowana grafika może odbiegać od rozkazu, który jednostka faktycznie wykona.

Na podstawie importowanych grafik autor koduje logikę czasową próby: harmonogram, wyzwalacze inicjujące każdą fazę, warunki przesuwające scenariusz i gałęzie, które muszą być ćwiczone. Dobry scenariusz MRS nie jest pojedynczym liniowym skryptem, lecz małym drzewem decyzyjnym – próba powinna być w stanie podążać za podstawowym biegiem działań, a także rozgałęziać się w sytuacje awaryjne, które plan musi uwzględniać. Uczestnicy są następnie przypisywani do elementów i ról, przy czym każde stanowisko jest oznaczane jako kontrolowane przez człowieka lub przez komputer.

Wersjonowanie jest wymogiem pierwszoplanowym. Próba ujawni problemy, a poprawki są wprowadzane z powrotem zarówno do planu, jak i do scenariusza. Narzędzie autorskie musi umożliwiać dodanie gałęzi lub dostosowanie harmonogramu bez niszczenia linii bazowej i musi rejestrować, która wersja scenariusza wygenerowała który przebieg próby.

Rozproszony czas wykonania symulacji

Elementy, które muszą razem próbować – manewr lądowy, lotnictwo, wsparcie ogniowe i stanowisko dowodzenia – prawie nigdy nie są ulokowane razem przed operacją. Uczestnictwo rozproszone jest zatem nie opcjonalną funkcją, lecz podstawowym wymogiem i jest źródłem większości złożoności czasu wykonania systemu.

Czas wykonania federuje wszystkie uczestniczące obiekty w jeden zsynchronizowany scenariusz przy użyciu transportu symulacji rozproszonej. Ustalonymi standardami są DIS (Distributed Interactive Simulation) i HLA (High Level Architecture); nowoczesna implementacja może zamiast tego używać magistrali wiadomości publish-subscribe z warstwą zarządzania zainteresowaniami. Niezależnie od transportu muszą być spełnione dwa niezmienniki: każdy węzeł współdzieli ten sam obraz sytuacji i każdy węzeł zgadza się co do czasu. Rozbieżność w którymkolwiek z nich powoduje najgorszą klasę niepowodzenia próby – taką, w której uczestnicy widzą różne wersje rzeczywistości i wyciągają pewne, ale sprzeczne wnioski.

Utrzymanie tych niezmienników na łączach taktycznych o zmiennym opóźnieniu i przepustowości – czasem obejmujących zdegradowane sieci, na których jednostka faktycznie będzie walczyć – jest centralnym wyzwaniem inżynieryjnym. Zarządzanie zainteresowaniami ogranicza ruch każdego węzła do elementów, które może postrzegać; prognozowanie ruchu wygładza ruch elementów między aktualizacjami o niskiej częstotliwości; a pojedyncze autorytatywne źródło czasu zapobiega dryfowi zegara, który po cichu korumpuje rozstrzyganie starć. Przypadek użycia próby misji korzysta również ze zdolności modelowania rzeczywistych warunków łączności operacji, tak aby próba mogła celowo narzucić degradację łącza, jakiej oczekuje jednostka, zamiast działać w zidealizowanej sieci.

Rejestracja po akcji i pętla sprzężenia zwrotnego

Próba, która nie jest przeglądana, jest próbą wykonaną w połowie. Podsystem rejestracji nagrywa cały przebieg – każdą trasę elementu, starcie, zdarzenie łączności i decyzję operatora – do dziennika z indeksem czasowym. Objętość jest znaczna, więc dziennik jest zorganizowany do selektywnego odtwarzania, a nie jako nieprzezroczyste zrzuty: analityk musi być w stanie przewinąć do danego momentu, odtworzyć go z perspektywy dowolnego uczestnika i z widoku z lotu ptaka oraz odpowiedzieć, dlaczego doszło do niepowodzenia koordynacyjnego.

Przegląd po akcji to miejsce, w którym próba uzasadnia swój koszt. Ujawnia luki koordynacyjne, problemy z harmonogramem i pominięte sytuacje awaryjne zawarte w planie i robi to, gdy są jeszcze tanie do naprawienia. Wynikiem nie jest ocena, lecz zestaw zmian – do planu, macierzy synchronizacji i samego scenariusza. Zmiany te są wprowadzane z powrotem, a dotknięte gałęzie są ponownie uruchamiane, aby potwierdzić, że poprawki utrzymują się. Ta zamknięta pętla, działająca w operacyjnych ramach czasowych, jest całym celem systemu. Ta sama mechanika rejestracji i odtwarzania leży u podstaw powiązanych zdolności, takich jak cyfrowy bliźniak sprzętu wojskowego, gdzie zarejestrowane zachowanie napędza zarówno szkolenie, jak i analizę predykcyjną.

Miejsce prób misji w stosie symulacji

System prób misji nie jest tyle samodzielnym produktem, co wyspecjalizowaną konfiguracją szerszej platformy symulacyjnej. Współdzieli potok terenu, rozproszony czas wykonania i narzędzia przeglądu po akcji z konstruktywnymi i wirtualnymi systemami szkoleniowymi; tym, co dodaje, jest dyscyplina aktualności – świeże dane, scenariusze specyficzne dla misji i czas realizacji mierzony w godzinach. Organizacja, która już eksploatuje zdolną infrastrukturę symulacji szkoleniowej, może rozszerzyć ją o próby misji, inwestując w szybkie pobieranie danych, utrzymywaną bibliotekę zagrożeń i narzędzie do tworzenia scenariuszy, które mówi językiem grafik operacyjnych. Organizacja budująca MRS w izolacji, bez tej wspólnej podstawy, ma tendencję do złego odbudowywania tych samych podsystemów.