Live-virtual-constructive (LVC) інтеграція для оборонного навчання

Масштабне колективне навчання — таке, що готує штаби бригад до координації вогню, маневру та логістики у багатодоменному просторі бою — неможливо провести дешево лише з живими силами. Живі навчання витрачають боєприпаси, зношують техніку і вимагають розмежування тисяч квадратних кілометрів повітряного та наземного простору. Віртуальні симулятори стискають географію та усувають витрати на витратні матеріали, але не можуть відтворити тертя, затримки зв'язку та фізичне виснаження реальних операцій. Конструктивна симуляція дешево масштабується до рівня дивізії або корпусу, але генеровані нею сутності є комп'ютерно керованими абстракціями, а не солдатами. Кожен домен охоплює частину навчальної картини. Live-virtual-constructive (LVC) інтеграція намагається поєднати всі три в єдиному узгодженому синтетичному середовищі — надаючи аудиторії навчання реалістичне поєднання реальних сил, пілотованих симуляторів та комп'ютерно-генерованих сутностей одночасно. Архітектурі цього підходу і присвячена ця стаття.

Що означають «живе», «віртуальне» та «конструктивне»

Терміни визначаються ступенем участі людини в контурі управління. Живе означає реальних людей, які керують реальним обладнанням у фізичному середовищі. Танковий взвод на M1A2 на навчальному полігоні — це живий елемент. Інструментація — GPS-трекери, імітатори зброєних ефектів на кшталт MILES, голосові радіостанції — дозволяє системі управління навчаннями спостерігати та фіксувати дії живих елементів, але самі сили присутні фізично. Живі елементи є золотим стандартом реалізму навчання на індивідуальному та екіпажному рівнях; вони дорогі і важко масштабуються.

Віртуальне означає оператора-людину, що взаємодіє з симульованою платформою всередині тренажера. Оператор є реальним і відпрацьовує реальні когнітивні та процедурні навички, але платформа та середовище є синтетичними. Steel Beasts Pro PE, Prepar3D і авіаційні навчальні симулятори є віртуальними середовищами. Віртуальні елементи обходяться дешевше за навчальну годину порівняно з живими, можуть представляти платформи, яких мало або які на обслуговуванні, та можуть бути миттєво скинуті до будь-якого стану сценарію. Їхнє обмеження полягає в тому, що змодельована фізика та моделі сенсорів, якими б детальними вони не були, залишаються наближеннями.

Конструктивне означає комп'ютерно-генеровані сутності під управлінням програмного забезпечення — ШІ, скриптованих моделей поведінки або людей-операторів навчання, що діють як агреговані сили. Жодна окрема людина не перебуває в контурі управління для кожної сутності. OneSAF, JCATS та WARG є конструктивними системами симуляції. Конструктивна симуляція масштабується до навчань на рівні корпусу з десятками тисяч сутностей за долю вартості еквівалентних живих або віртуальних сил. Компроміс полягає у зниженні реалізму на рівні окремої сутності та зменшенні залучення аудиторії навчання до завдань, що вимагають реального когнітивного навантаження від сил противника.

LVC-інтеграція поєднує всі три. Бригадне навчання може включати живий піхотний батальйон на реальному полігоні, віртуальні екіпажі гвинтокрилів, що летять на симульованих вертольотах із тренажерного центру, та конструктивний OPFOR розміром з полк, поведінкою якого керує невелика команда управління навчаннями. Навчальна цінність комбінованого середовища перевищує те, що може забезпечити будь-який окремий домен: живий батальйон стикається з тактично узгодженим тиском великого, реалістично поведінкового конструктивного OPFOR, скоординованого з віртуальною авіаційною підтримкою, яка реагує на наземні події майже в реальному часі.

Виклик сумісності

Поєднання трьох доменів є архітектурно нетривіальним завданням, оскільки кожен домен розроблявся незалежно та використовує різні протоколи, часові бази й моделі сутностей. Живі сили спілкуються через LINK 16, VMF, NFFI (NATO Friendly Force Information) або потоки Cursor on Target (CoT) від систем інструментації. Віртуальні симулятори зазвичай використовують DIS (Distributed Interactive Simulation, IEEE 1278) або HLA (High Level Architecture, IEEE 1516). Конструктивні системи симуляції використовують HLA — зазвичай варіант RPR-FOM (Real-time Platform Reference Federation Object Model) — або TENA (Test and Training Enabling Architecture) в контекстах полігонної інструментації.

Три прогалини сумісності роблять LVC-інтеграцію складною на практиці. Перша — неоднорідність протоколів: повідомлення треку LINK 16 та оновлення атрибута EntityState HLA RPR-FOM представляють концептуально одне й те саме (положення та стан військової сутності), але в абсолютно різних бінарних форматах, з різною семантикою полів та через різні транспортні механізми. Шлюз повинен транслювати між ними без втрати інформації або введення неоднозначності.

Друга прогалина — невідповідність затримок. Живий GPS-трек від інструментованої машини оновлюється з частотою 1 Гц. Симулятор віртуального танка оновлює стан своєї сутності з частотою 20–30 Гц з використанням dead-reckoning між оновленнями. Конструктивна симуляція в реальному часі може оновлювати позиції сутностей із змінною частотою залежно від активності сутності. Коли ці потоки надходять у спільне синтетичне середовище, позиції сутностей повинні бути узгоджено зведені — жива машина, що оновлюється з частотою 1 Гц, буде виглядати такою, що стрибає, якщо її позиція просто пересилається з живою частотою оновлення, а не згладжується екстраполяцією dead-reckoning, узгодженою з кроком часу симуляції.

Третя прогалина — ідентичність сутностей. Той самий фізичний танк, що з'являється в живому домені, відстежується полігонною інструментацією, представляється кабіною екіпажу віртуального симулятора і тиражується як конструктивна сутність для обізнаності сил противника, має бути правильно ідентифікований як єдина сутність у всіх доменах — а не як три окремі сутності, що займають одне місце. Управління ідентичністю через межі доменів, особливо коли сутності переходять між живим і конструктивним представленням під час навчань, є одним із найбільш схильних до помилок аспектів LVC-архітектури.

HLA як кістяк LVC

HLA (High Level Architecture, IEEE 1516) є домінуючим стандартом федерації для підключення LVC-компонентів, оскільки надає сервіси, необхідні для управління середовищем симуляції з кількома федератами в масштабі. Сам протокол HLA детально розглядається окремо; тут акцент зроблено на тому, як HLA функціонує саме в LVC-контексті.

У LVC-федерації кожен основний компонент — система конструктивної симуляції, кожен об'єкт віртуального симулятора та кожен шлюзовий адаптер для потоків живих сил — приєднується до HLA-федерації як федерат. RTI (Run-Time Infrastructure) управляє комунікацією між федератами за допомогою FOM (Federation Object Model) федерації, як правило, заснованого на SISO RPR-FOM 2.0 для сумісності в рамках NATO.

Управління федерацією обслуговує життєвий цикл навчання: створення федерації, приєднання та вихід федерата, точки синхронізації (що використовуються для координації початку, паузи та перезапуску сценарію між усіма компонентами) та знищення федерації. У багатомісцевому LVC-навчанні точки синхронізації є критичними — без них один федерат може почати просування часу сценарію, поки інший ще ініціалізується, що спотворює стан сутностей через межу.

Управління часом у LVC-федерації зазвичай налаштовується як максимально можлива імітація реального часу, а не строго керована часова симуляція, оскільки живі сили не можуть бути призупинені або сповільнені для отримання дозволу на просування часу. RTI працює в режимі реального часу; конструктивні та віртуальні федерати публікують оновлення з часовою міткою, але не затримують просування часу федерації через дані від живих шлюзів, що надійшли із запізненням. Це означає, що конструктивні та віртуальні компоненти повинні толерувати випадкові оновлення стану сутностей не в порядку надходження від живих шлюзів.

Data Distribution Management (DDM) є необхідним у масштабі LVC. Навчання на рівні корпусу може мати тисячі сутностей на географічній ділянці в сотні кілометрів. Без DDM кожен федерат отримує кожне оновлення стану сутності — пропускна здатність і обчислювальне навантаження, що перевантажить симулятори командного пункту, які цікавляться лише тактичним радіусом 50 км. Регіони підписки DDM, налаштовані відповідно до зони оперативного інтересу кожного федерата, зводять це до керованого обсягу.

DIS у LVC: все ще актуальний для віртуальних компонентів

Незважаючи на архітектурні переваги HLA, DIS (IEEE 1278) залишається присутнім у LVC-середовищах, оскільки велика інстальована база віртуальних симуляторів нативно підтримує DIS і не може бути економічно ефективно переінтегрована на HLA. Steel Beasts Pro, багато застарілих авіаційних симуляторів та старіші інструменти тренувань командного пункту були розроблені для DIS-середовищ. Їхня заміна неможлива в рамках більшості програмних бюджетів.

Рішенням є DIS-to-HLA міст: шлюз, що бере участь у DIS-мультикастній мережі як учасник DIS та одночасно як HLA-федерат, транслюючи DIS PDU в оновлення стану сутностей RPR-FOM і навпаки. Міст повинен ретельно обробляти семантичні відмінності. DIS Entity State PDU використовують алгоритми dead-reckoning (визначені в стандарті) для згладжування позиції між оновленнями; міст повинен застосовувати той самий dead-reckoning до вхідних DIS-даних перед публікацією в HLA, щоб уникнути розривів позиції. Міст також повинен відображати коди типів сутностей DIS (що використовують ієрархічну нумерацію, визначену в SISO ENUM-70) на атрибути EntityType HLA RPR-FOM за допомогою тієї ж нумерації — невідповідності в кодуванні типів сутностей призводять до того, що конструктивний OPFOR неправильно класифікує віртуальні дружні платформи.

Управління частотою PDU є практичною проблемою. DIS-середовище з 200 віртуальними симуляторами, кожен з яких публікує з частотою 30 Гц, генерує 6 000 PDU на секунду в мультикастній мережі. DIS-to-HLA міст повинен фільтрувати це за допомогою порогів дедбенду — пересилаючи оновлення лише тоді, коли зміни позиції, швидкості або орієнтації перевищують визначений поріг — щоб не насичувати HLA-федерацію оновленнями, що представляють незначний рух.

Архітектура LVC-шлюзу

Рівень шлюзу є архітектурно найбільш критичним і найбільш схильним до відмов компонентом LVC-інтеграції. Шлюз адаптує живе джерело даних — LINK 16, NFFI, CoT, полігонну інструментацію — до HLA-федерації. Кожен шлюз повинен виконувати кілька функцій одночасно.

Трансляція протоколу перетворює вхідний формат повідомлення на оновлення атрибутів RPR-FOM. Це не є суто механічним процесом: J-серія повідомлень LINK 16 кодує позицію сутності в геодезичних координатах WGS-84, тоді як HLA RPR-FOM використовує геоцентричну декартову систему координат (Earth-centered, Earth-fixed). Шлюз повинен виконувати перетворення системи координат для кожного оновлення позиції. Вектори швидкості, якщо вони присутні в живому потоці, повинні бути перетворені узгоджено. Відображення типів сутностей з кодів емісії LINK 16 на значення EntityType RPR-FOM вимагає підтримуваної таблиці трансляції — нові типи обладнання повинні бути додані явно, а неоднозначні коди (де один тип LINK 16 відображається на кілька типів платформ) потребують евристичного вирішення.

Управління життєвим циклом сутностей обробляє появу, збереження та зникнення живих сутностей у HLA-федерації. Коли шлюз вперше бачить трек, він створює екземпляр об'єкта HLA і бере на нього право власності. Коли трек втрачається (відмова GPS, машина за рельєфом), шлюз повинен вирішити, чи підтримувати оцінку позиції з dead-reckoning протягом пільгового періоду, або негайно видалити об'єкт. Передчасне видалення з подальшим швидким повторним реєстром створює розриви ідентичності об'єктів, які плутають логіку цілевизначення конструктивного OPFOR. Тривалий dead-reckoning втрачених треків створює примарні сутності, що погіршують картину ситуаційної обізнаності аудиторії навчання.

Адаптація частоти узгоджує каденцію оновлення живого джерела з очікуваннями симуляції. GPS-трекер, що оновлюється з частотою 1 Гц, не може вводити оновлення з частотою 20–30 Гц, як конструктивні сутності; шлюз повинен публікувати з живою частотою та налаштовувати параметри dead-reckoning (швидкість і прискорення) в стані сутності HLA, щоб приймаючі федерати могли екстраполювати позицію між оновленнями. Параметри dead-reckoning повинні бути встановлені реалістично — гусенична машина не може отримати модель dead-reckoning літального апарату.

LVC у хмарі: архітектура та бюджет затримки

Перенесення LVC-бекенд компонентів до урядового хмарного середовища — Azure Government або класифікованого еквівалента IL5/IL6 — є оперативно привабливим, оскільки усуває необхідність відправляти та налаштовувати фізичну серверну інфраструктуру на кожному полігоні. Конструктивна федерація симуляції на хмарній основі може обслуговувати кілька географічно розосереджених полігонів одночасно, при цьому центри з віртуальними симуляторами та шлюзи живих сил у різних місцях федеруються в спільну хмарну HLA-федерацію.

Критичним обмеженням є затримка. Управління часом HLA в режимі реального часу надає дозволи на часове просування в інтервалах, що визначаються конфігурацією lookahead і циклом heartbeat RTI. Для LVC-федерації реального часу практична вимога полягає в тому, щоб оновлення стану сутностей надходили до всіх федератів-підписників протягом 100–150 мс від моменту генерації — за цим порогом логіка маневру конструктивного OPFOR починає діяти на застарілих даних позиції, а екіпажі віртуальних симуляторів бачать живі сутності, що телепортуються, а не рухаються плавно.

Хмарний RTI, що обслуговує федерати на географічно розосереджених полігонах, повинен бути розміщений так, щоб мінімізувати затримку найгіршого випадку за принципом «туди й назад». Регіони Azure Government на континентальній частині США досягають приблизно 20–40 мс у режимі «туди й назад» до більшості тренувальних полігонів CONUS по виділених урядових мережевих шляхах (не публічний інтернет). Європейські тренувальні полігони, що звертаються до хмарного регіону США, стикаються з 80–120 мс «туди й назад». Це вкладається в поріг 150 мс для конструктивних і віртуальних компонентів, але є граничним для шлюзів живих сил, що повинні реагувати на потоки від сенсорів з високою частотою.

Рекомендована архітектура розділяє HLA-федерацію за географічними рівнями. Конструктивна симуляція, управління сценарієм і запис AAR виконуються в хмарі. Віртуальні симулятори та шлюзи живих сил працюють на кожному полігоні з локальним RTI-проксі, що з'єднується з хмарною федерацією. Локальний проксі кешує стан сутностей для зони інтересу локального полігону, обслуговуючи оновлення для локальних федератів із кешу замість необхідності звернення до хмарного RTI для кожного оновлення атрибута. Це підтримує взаємодію локально-локальних сутностей нижче 5 мс, одночасно синхронізуючи глобальний стан федерації через хмарний кістяк.

Наслідки для компонентів конструктивної симуляції

Компонент конструктивної симуляції в LVC-федерації має відповідальність, що виходить за рамки простого генерування поведінки сутностей. Він повинен підтримувати узгоджений стан сутностей через межу LVC — правильно ідентифікуючи, які сутності є живими, які є віртуальними, а які є конструктивними, та застосовуючи відповідні правила взаємодії та логіку залучення до кожної категорії. Елемент конструктивного OPFOR повинен бути здатним залучати як живі, так і віртуальні дружні сутності з узгодженою логікою; але він не повинен намагатися залучати сутності, що є артефактами інструментації (дублікати живих треків, тестові сутності, введені для налагодження інтеграції).

Поведінка конструктивного ШІ також повинна враховувати затримку та невизначеність, властиві даним живих сутностей. Конструктивна система, розроблена для суто конструктивного середовища, передбачає досконале знання позицій всіх сутностей, оновлених на власному кроці часу симуляції. Коли дані живих сутностей надходять з частотою 1 Гц з випадковими пропусками, конструктивний ШІ повинен використовувати екстрапольовані позиції для рішень щодо цілевизначення та маневру — і повинен коректно знижувати продуктивність при втраті живих треків, а не трактувати втрату треку як знищення сутності.

Рівень управління сценарієм конструктивної симуляції також управляє рішеннями керування навчаннями, що впливають на живий домен: коли вводити підкріплення, коли погіршувати зв'язок, коли переходити від конструктивного OPFOR до живого OPFOR для певної фази навчання. Навчання штабного планування з використанням конструктивної симуляції отримують вигоду від цієї гнучкості — команда управління навчаннями може вводити стимули в живий домен через конструктивний рівень, не порушуючи свободи дій живих сил.