Платформа WARG: технічна архітектура ІІ-варгеймінгу

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

Платформа WARG — це реалізація цієї архітектури від Corvus Intelligence, розроблена для планувальних вправ на рівні бригади і вище. Технічні рішення, описані тут, відображають те, що ця категорія систем повинна робити, щоб бути оперативно корисною — не маркетингові твердження, а інженерні вимоги, що випливають з реальних потреб програм оборонного навчання та аналізу. Для ширшого контексту щодо того, як варгеймінг із підтримкою ІІ порівнюється з форматами ручного фасилітованого варгеймінгу, дивіться супутню статтю про ІІ-варгеймінг проти ручного Крігшпіля.

Поведінкове моделювання OpFor на основі ІІ

Якість ІІ-платформи для варгеймінгу значною мірою визначається якістю моделі сил противника. OpFor, який поводиться передбачувано, не здатний адаптуватися до маневрів гравця або переслідує цілі тактично незрозумілим чином, тренує командирів проти солом'яного опудала — і досвідчені командири розпізнають це протягом перших тридцяти хвилин вправи та розумово відключаються від навчального сценарію. Правильне налаштування OpFor — це не косметична функція; це основний аналітичний продукт платформи.

Ієрархічна архітектура прийняття рішень

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

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

Точність поведінки та кодування доктрини

Кодування доктрини конкретного противника в модель OpFor вимагає більшого, ніж вибір загального поведінкового пресету «атакуючий». Різні структури сил противника і доктрини виробляють характерні тактичні підписи — характерні геометрії підходу, патерни застосування вогневої підтримки, темп розвитку успіху і логістичну дисципліну. Ці підписи кодуються через поєднання конфігурації параметрів (переваги дальності ураження, пороги відходу, тригери введення резерву) і навчальних даних, що включають специфічні для доктрини приклади. Результатом є OpFor, який не тільки б'ється компетентно, але й б'ється в спосіб, який навчальна аудиторія впізнає як конкретний тип противника.

Архітектура рушія сценаріїв

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

Цикл симуляції та конвеєр оцінювання

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

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

Масштабованість від взводу до оперативного рівня

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

Конвеєр даних про карту та місцевість

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

Надходження та нормалізація даних

Практичний конвеєр місцевості повинен мати можливість приймати дані з різних джерел і нормалізовувати їх до загального внутрішнього представлення. Геопросторові дані для оперативних районів надходять у кількох форматах і проєкціях — GeoTIFF для растрових даних про висоту, Shapefile або GeoJSON для векторних об'єктів, DTED для оборонно-стандартних продуктів висоти. Модуль надходження конвеєра нормалізує всі вони до внутрішнього тайлового формату платформи, оптимізованого для просторових запитів, які генерує рушій оцінювання: запити дальності та пеленга для розрахунків прямої видимості, площинні запити для розрахунків щільності підрозділів і запити шляху для маршрутизації руху. Нормалізація включає координатну проєкцію до узгодженої системи і повторну вибірку роздільної здатності, де вихідні дані мають іншу роздільну здатність, ніж тайловий формат платформи.

Реальна проти синтетичної місцевості

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

Аналітичний рушій AAR

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

Виявлення та анотація точок прийняття рішень

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

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

Статистичний аналіз за кількома запусками

Повна аналітична потужність ІІ-платформи для варгеймінгу доступна лише тоді, коли сценарій виконується кілька разів за різних умов. Статистичний модуль рушія AAR обробляє набір результатів із кількох запусків і генерує: розподіли ймовірностей результатів (яка частка запусків призвела до кожного визначеного стану результату), аналізи чутливості (які початкові умови або змінні рішень найбільше прогнозували результати), коефіцієнти обміну силами як функцію вхідних рішень, і криві споживання логістики, що визначають умови, за яких постачання стало лімітуючим чинником. Цей аналіз доступний на цьому рівні статистичної достовірності лише тоді, коли платформа може виконувати сотні ітерацій сценарію без участі людини — обчислювальні інвестиції в моделювання OpFor на основі ІІ окупаються тут, оскільки вони забезпечують цю аналітичну можливість, яку формат ручного Крігшпіля структурно надати не може. Дивіться також статтю про варгеймінг у розвитку військової доктрини щодо аналітичних вимог, що зумовлюють цю можливість.

Інтеграція з навчальними середовищами C2

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

Обмін даними та архітектура API

Інтеграція C2 досягається через рівень адаптера симуляції платформи — набір інтерфейсів, що перекладають між внутрішнім станом симуляції платформи і форматами повідомлень, які навчальні системи C2 споживають і видають. Стандартні формати обміну даними в навчальних середовищах оборони включають формати звітування про відстеження для оновлень позиції і статусу, і структуровані протоколи обміну наказами для командних інструкцій. Адаптер симуляції публікує оновлення відстеження в шині повідомлень у міру зміни стану симуляції, дозволяючи підключеним системам C2 відображати змодельовані позиції підрозділів так само, як вони відображають реальні дані відстеження. Адаптер також підписується на повідомлення про накази від систем C2, перекладає їх у команди симуляції і маршрутизує їх до відповідних агентів підрозділів у моделях OpFor або дружніх сил.

Управління вправами та федерація

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

Критерії вибору платформи для закупівлі

Для офіцерів із закупівель і директорів з навчання, що оцінюють ІІ-платформи для варгеймінгу, технічні архітектурні питання, наведені вище, безпосередньо перекладаються в критерії закупівлі. По-перше: чи виробляє модель OpFor платформи тактично пов'язану поведінку противника, чи вона виробляє очевидні патерни, які досвідчені командири відкинуть? Це можна оцінити, запустивши платформу протягом кількох годин із досвідченими операторами і спостерігаючи, чи генерує OpFor несподіванки. По-друге: чи виробляє рушій AAR аналітичні продукти у формі, що скорочує час підготовки ведучого, чи він вимагає великого ручного аналізу необроблених журналів? По-третє: чи приймає конвеєр місцевості реальні геопросторові дані для конкретних оперативних районів, які програма потребує опрацювати? По-четверте: чи масштабується платформа до ешелону, якого вимагає програма, використовуючи ті самі структури даних і інструменти управління сценарієм на різних рівнях масштабу? По-п'яте: чи використовує архітектура інтеграції C2 стандартні формати даних, чи вона вимагає індивідуальної інтеграційної роботи, яка прив'язує програму до одного постачальника платформи?

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