Програмне забезпечення для термінового ураження цілей: архітектура для скорочених петель прийняття рішень у ланцюзі знищення

Швидкість є ключовою вимогою до проектування програмного забезпечення для термінового ураження цілей. Мобільна, короткочасна або чутлива до часу ціль зникне до завершення ланцюга знищення, якщо програмне забезпечення активно не скорочує кожну передачу. Складність полягає в тому, що швидкість не може досягатися коштом підзвітності: кожне ураження має бути відстежуване до конкретного органу влади, перевірене щодо правил застосування сили та деконфліктоване щодо дружніх сил і захищених об'єктів. Ці дві вимоги -- швидке виконання та авторизована перевіреність -- архітектурно суперечать одна одній, і те, як система вирішує це протиріччя, визначає, чи є вона оперативно придатною або лише теоретично правильною. Ця стаття охоплює архітектурні шаблони, що роблять обидва підходи можливими: проектування автомата станів для відстеження ланцюга знищення, бюджети затримок у часових рамках від сенсора до виконавця, робочі процеси деконфліктингу вогню, делегування повноважень на ураження, розміщення шлюзів участі людини в циклі прийняття рішень та інтеграція з JTAC і API рівня управління бойовими діями.

Що терміновe ураження цілей вимагає від програмної архітектури

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

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

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

Часові рамки від сенсора до виконавця: бюджети затримок для кожної ланки ланцюга

Корисна архітектура TCT починається з конкретної моделі часових рамок. Для мобільної наземної цілі, проти якої потрібне скорочене ураження, реалістичний бюджет розбиває ланцюг на фази: виявлення сенсором і підтвердження траси (ціль з'являється на каналі ISR, вік траси перевищує мінімальний поріг якості) може виділяти 20-30 секунд; ідентифікація цілі та оцінка супутнього збитку виділяють ще 15-25 секунд; отримання дозволу на ураження виділяє 10-20 секунд; призначення зброї, обчислення даних стрільби та передача виконавцю виділяють фінальні 5-15 секунд. Загальний час від підтвердження траси до готовності вогню може становити менше 90 секунд для заздалегідь запланованих категорій цілей при відповідному попередньому делегуванні -- значно довше для динамічних цілей у складних середовищах, але бюджетна модель принаймні робить вузькі місця видимими.

Кожен розподіл бюджету перетворюється на конкретну вимогу до програмного забезпечення. Вікно підтвердження траси в 20-30 секунд вимагає, щоб рівень злиття сенсорів дедублікував і оцінював якість вхідних трас у близькому до реального часу режимі, а не з 30-секундним циклом опитування. Вікно дозволу на ураження в 10-20 секунд вимагає, щоб запит на затвердження надходив на екран командира, що затверджує, з уже зібраними всіма допоміжними даними -- зображенням цілі, історією траси, оцінкою супутнього збитку, статусом деконфліктингу -- щоб крок прийняття рішення не передував кроку збирання даних. Програмне забезпечення не може контролювати, наскільки швидко командири приймають рішення, але може забезпечити, щоб кожна секунда вікна дозволу була часом прийняття рішення, а не навігацією по екрану.

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

Відстеження ланцюга знищення: проектування автомата станів для багатосуб'єктних уражень

Ланцюг знищення є по суті робочим процесом з кількома одночасними суб'єктами, впорядкованими залежностями та обов'язковими шлюзами авторизації. Автомат станів є природною моделлю. Кожне ураження існує як об'єкт в одному з визначеного набору станів -- Виявлено, Ідентифіковано, Номіновано, Затверджено, Призначено, Уражено, Оцінено за результатами бойових дій -- а переходи між станами ініціюються конкретними діями суб'єктів, що надають необхідні дані та несуть автентифіковану ідентичність суб'єкта як запис авторизації. Автомат станів забезпечує, щоб жоден крок не був пропущений: ураження не може досягти стану «Призначено» без проходження через «Затверджено», а перехід «Затверджено» вимагає підпису авторизації від ролі з дійсними повноваженнями на ураження для цієї категорії цілі та місцезнаходження.

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

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

Делегування повноважень на ураження та забезпечення дотримання правил застосування сили в програмному забезпеченні

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

Забезпечення дотримання правил застосування сили (ROE) в програмному забезпеченні діє поряд із рівнем делегування повноважень, але розглядає інше питання. Делегування повноважень відповідає на питання «хто може затвердити це ураження?» Забезпечення дотримання ROE відповідає на питання «чи є це ураження взагалі допустимим відповідно до поточних постійних наказів?» Правила ROE кодуються як передумови переходів між станами: ураження, що завдало б удару в межах визначеної відстані від захищеного об'єкта, не може перейти до стану «Затверджено» незалежно від того, чи має командир, що затверджує, повноваження на делегування. Перевірки ROE запускаються автоматично, коли ураження входить у стан «Номіновано», і знову на кроці затвердження, представляючи результати командиру, що затверджує, у вигляді структурованого резюме відповідності, а не бінарного «пройшов або не пройшов».

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

Деконфліктинг вогню: запобігання дружньому вогню в автоматизованих робочих процесах цілевказання

Деконфліктинг вогню є обчислювально прямолінійним, але організаційно складним: дані, необхідні для перевірки конфліктів -- позиції дружніх сил, активні резервації повітряного простору, записи списку заборонених ударів, інші активні ураження, межі FSCM -- надходять з кількох окремих систем, якими керують різні ешелони, і кожне джерело має власну затримку оновлення. Механізм деконфліктингу, що перевіряє за застарілими даними, є таким самим небезпечним, як відсутність деконфліктингу взагалі. Архітектура повинна розглядати актуальність даних як першочергову проблему, відображаючи мітку часу кожного джерела даних поряд з результатами деконфліктингу, щоб оператор міг оцінити, чи ґрунтується результат «чисто» на актуальній інформації або на даних, що мають кілька хвилин давнини.

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

Шлюзи участі людини в циклі прийняття рішень: де програмне забезпечення зупиняється для авторизації

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

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

Архітектурна напруга на шлюзах HITL полягає між точністю авторизації та оперативним темпом. Шлюз, що представляє командиру щільний, неналаштований дамп даних, не дійсно підтримує обґрунтоване прийняття рішень під тиском часу -- він підштовхує командира до формального затвердження для підтримки темпу. Добре спроектований екран авторизації представляє мінімальні дані, необхідні для прийняття конкретного рішення, що вимагається на цьому шлюзі: ідентифікацію цілі та впевненість, оцінку супутнього збитку, резюме статусу деконфліктингу та конкретну необхідну дію авторизації. Всі допоміжні деталі доступні, але не нав'язані в основний вигляд. Мета полягає в тому, щоб зробити правильне рішення швидким рішенням, а не прискорити прийняття рішення шляхом мінімізації його когнітивного змісту.

Інтеграція з JTAC, координацією CAS та API рівня управління бойовими діями

Авіаційна підтримка (CAS) та ураження за підтримки JTAC додають вимір інтеграції, якого не вимагає чиста координація вогню: система цілевказання повинна обмінюватися даними з авіаційними платформами та терміналами JTAC, що працюють за різними стандартами каналу передачі даних. API рівня управління бойовими діями (BML), що з'єднує ці системи -- реалізований як повідомлення Link 16 J-серії, JREAP-C, коаліційний веб-сервіс BML або канал даних на основі TAK -- визначає як затримку, так і точність цифрового обміну даними 9-рядкового брифінгу. Система цілевказання, що вимагає від JTAC повторного введення координат цілі, що вже є в записі ланцюга знищення, додає ручний крок, ризик помилки транскрипції та витрачений час, який слід усунути прямим відображенням даних. Архітектура інтеграції для цього робочого процесу детально описана в архітектурі та інтеграції програмного забезпечення координації JTAC і CAS.

На рівні моделі даних цифровий 9-рядковий брифінг чисто відображається на поля, які система TCT вже підтримує: місцезнаходження цілі (рядок 1), тип маркування (рядок 2), місцезнаходження дружніх сил (рядок 3), висота цілі (рядок 4), опис цілі (рядок 5), маркування цілі (рядок 6), місцезнаходження дружніх сил (рядок 7), напрямок відходу (рядок 8) та примітки (рядок 9). Адаптер інтеграції автоматично перекладає запис ураження ланцюга знищення в ці поля, залишаючи JTAC підтверджувати точність та додавати геометрію наведення, а не складати брифінг з нуля. Вхідне підтвердження від JTAC -- підтвердження реєстрації літака, завершення наведення та дозвіл на атаку -- аналізується назад у запис ланцюга знищення, просуваючи автомат станів та фіксуючи мітку часу кожного кроку для сліду аудиту.

Поза обміном 9-рядковим, інтеграція CAS вимагає від системи цілевказання знання позиції літака CAS, доступності боєприпасів та профілю польоту для виконання значущого деконфліктингу повітряного простору. Інтеграція CAS, що знає лише останню повідомлену позицію літака, не може перевірити, чи конфліктуватиме запланований захід атаки з активним завданням вогню поверхня-поверхня в тому самому районі. Архітектура інтеграції повинна отримувати оновлення стану літака з максимально доступною швидкістю -- зазвичай кожні 2-12 секунд на Link 16, або субсекундно на прямому каналі TAK -- і робити їх доступними для механізму деконфліктингу як постійно оновлюваний шар дружніх авіаційних трас. Інтеграція цього з підтримкою прийняття рішень за допомогою ШІ в системах C2 може додатково автоматизувати крок виявлення конфліктів, виводячи конфлікти повітряного простору координатору вогню до того, як JTAC запитує дозвіл на атаку, а не після.