Голосовий радіозв'язок був основою координації авіаційної підтримки (CAS) з часів Другої світової війни. Авіаційний контролер наведення (JTAC) зачитує дев'ятилінійний брифінг по КВ або УКВ пілоту, пілот повторює його, і якщо всі дев'ять полів витримали перешкоди і фонетичний алфавіт без помилок транскрипції — атака виконується. Позірна простота процедури оманлива: рівень помилок під час реальних операцій суттєво вищий, ніж на навчаннях, повторна зачитка займає хвилини, а візуального підтвердження того, що пілот і JTAC бачать одну й ту саму цілу точку на землі, немає.
Програмне забезпечення цифрової координації CAS вирішує всі три проблеми одночасно. Структурована форма замінює вільний текст радіопередачі, місцезнаходження цілі прив'язується до маркера на живій картині оперативної обстановки (COP), а ланцюжок затвердження — від JTAC до AFAC до уповноваженого органу — залишає незмінний журнал аудиту від початкового запиту до оцінки результатів удару. Ця стаття розглядає, як побудувати таке програмне забезпечення: модель даних, архітектуру інтеграції з COP, шаблони робочого процесу затвердження та логіку деконфліктації.
Там, де це доречно, стаття посилається на те, як TAKpilot вирішує ці проблеми в робочому процесі CAS на основі TAK.
Проблема робочого процесу JTAC: чому голосовий 9-лінійний запит не працює під тиском
Стандартний формат дев'ятилінійного запиту CAS передає саме ту інформацію, яка потрібна пілоту для знаходження, ідентифікації та ураження цілі: початкова точка та зміщення, курс атаки, відстань, висота цілі, опис цілі, місцезнаходження цілі, тип позначення, позиція дружніх сил та маршрут виходу. В контрольованих умовах формат працює добре. В операційних умовах помилки накопичуються на кожному етапі ланцюжка передачі.
Поле місцезнаходження цілі — найважливіше поле брифінгу — є рядком координат, як правило, у форматі MGRS. Вимовлене по деградованому радіоканалу при високому темпі операцій, шестизначна координатна прив'язка може бути почута неправильно. Стандартна процедура повторного зачитування виловлює грубі помилки, але не тонкі транспозиції. Цифрове програмне забезпечення CAS усуває фонетичне зачитування координат, автоматично заповнює місцезнаходження цілі з маркера COP і відображає зону ураження на спільній карті, яку одночасно бачать JTAC та уповноважений орган.
Цифрова структура 9-лінійного повідомлення: від вільного тексту до типізованої схеми
Перше інженерне рішення в системі цифрової координації CAS — модель даних для 9-лінійного запису. Кожне з дев'яти полів відповідає структурованому типу з правилами валідації, що застосовуються під час введення.
Рядок 1 — IP/Зміщення. Початкова точка зберігається як UID об'єкта COP або координата з міткою. Зміщення — це пеленг у градусах магнітного азимуту та відстань у метрах.
Рядок 2 — Курс. Цілочисельний пеленг у градусах магнітного азимуту. Система відображає вісь атаки у вигляді стрілки на накладці зони ураження.
Рядок 3 — Відстань. Цілочисельна відстань у метрах від IP до цілі. Автоматично розраховується, коли обидва поля заповнені з COP.
Рядок 4 — Висота цілі. Цілочисельна висота у футах над рівнем моря. Автоматично заповнюється з бази даних рельєфу для координат цілі.
Рядок 5 — Опис цілі. Структурований тип: первинна категорія (транспортний засіб, особовий склад, споруда, обладнання) з вторинною класифікацією та полем для приміток у вільному тексті.
Рядок 6 — Місцезнаходження цілі. Найважливіше поле. Зберігається у форматах MGRS та десяткових градусах. При введенні координат система відображає точку на карті та просить JTAC підтвердити візуально.
Рядок 7 — Тип позначення. Перелік: лазер (з кодом), ІЧ-вказівник, дим (з кольором), GPS, координата, відсутнє.
Рядок 8 — Дружні сили. Повідомлене місцезнаходження найближчого дружнього підрозділу відносно цілі. Перехресно валідується з реальними позиціями треків у COP.
Рядок 9 — Маршрут виходу. Запланований напрямок виходу літака після атаки. Зберігається як кардинальний напрямок або UID запланованого маршруту.
Інтеграція з COP: прив'язка 9-лінійного запиту до живої карти
Цифрова форма 9-лінійного запиту не є корисною ізольовано. Її цінність полягає в інтеграції з картиною оперативної обстановки. Коли JTAC подає запит, програмне забезпечення координації створює набір об'єктів COP: маркер місцезнаходження цілі, накладку зони ураження, стрілку курсу атаки та відрізок лінії IP-ціль. Всі накладки передаються на сервер TAK та відображаються на всіх підключених клієнтах ATAK або WinTAK. AFAC та уповноважений орган бачать ту саму геометрію, що й JTAC.
Інтеграція треку літака додає ще один рівень ситуаційної обізнаності. Якщо координуючий літак передає своє місцезнаходження, його трек відображається у накладці зони ураження під час заходу на атаку. Інтеграція COP також забезпечує виявлення конфліктів у реальному часі: як тільки з'являється накладка зони ураження, система запитує всі маркери дружніх сил у межах бічного радіусу.
Робочий процес затвердження: від запиту JTAC до перевірки AFAC та дозволу SMEAC
Ланцюжок затвердження в операції CAS існує для того, щоб відповідний орган перевірив ціль, підтвердив геометрію та прийняв відповідальність за удар. Цифрове програмне забезпечення координації CAS повинно реалізовувати цей ланцюжок суворо.
Робочий процес відрізняється для запланованого та термінового CAS. Запланований CAS проходить повний ланцюжок SMEAC. JTAC подає завершений 9-лінійний запит, який передається AFAC для тактичної перевірки. AFAC підтверджує геометрію цілі на COP, перевіряє конфлікти з дружніми силами, перевіряє відповідність ПВД та схвалює запит. Схвалений запит потім передається до органу управління повітряним простором для остаточного дозволу.
Терміновий CAS скорочує ланцюжок. JTAC подає спрощений брифінг, а AFAC надає негайний дозвіл. Цифрова система забезпечує цю відмінність шляхом маршрутизації термінових запитів у окрему чергу з коротшим таймаутом.
Деконфліктація: повітряний простір, запобігання дружньому вогню та відповідність ПВД
Деконфліктація в цифровому програмному забезпеченні CAS діє на трьох рівнях: повітряний простір, запобігання дружньому вогню та правила ведення вогню (ПВД).
Деконфліктація повітряного простору. Перед затвердженням 9-лінійного запиту висотний блок зони ураження перевіряється на відповідність активним резервуванням повітряного простору. Конфлікти відображаються як накладки геозахисту на карті затвердження.
Запобігання дружньому вогню. Автоматична перевірка всіх дружніх треків у COP проти геометрії зони ураження виконується в момент затвердження, не лише під час подачі. Трек, який був поза зоною ураження під час подачі, але перемістився всередину на момент надання дозволу, генерує термінове попередження в останній момент.
Відповідність ПВД. Структурована класифікація поля опису цілі забезпечує автоматичні перевірки ПВД. Якщо опис цілі потрапляє в категорію, що вимагає додаткового дозволу, робочий процес маршрутизації додає крок перевірки ПВД.
Інтеграція TAKpilot: від запиту природною мовою до структурованого 9-лінійного запиту
Одна з найбільш оперативно корисних можливостей TAKpilot — здатність генерувати структурований чернетковий 9-лінійний запит із запиту природною мовою. JTAC може написати або сказати "уразити транспортний засіб в координаті 37T EL 441528, лазер 1688, дружні сили 300 м на південь", і TAKpilot витягне місцезнаходження цілі, тип позначення, код лазера та інформацію про дружні сили для попереднього заповнення форми.
Після підтвердження попередньо заповненої форми TAKpilot подає 9-лінійний запит на робочий процес затвердження та одночасно передає маркер місцезнаходження цілі та накладку зони ураження до CloudTAK через REST API сервера TAK. Інтерфейс затвердження показує зону ураження на карті, стрілку курсу атаки, всі дружні треки в районі та попередньо розраховані результати перевірки деконфліктації. Надання дозволу — це одна навмисна дія, що вимагає від уповноваженого органу побачити зону ураження на карті перед активацією кнопки.
Оцінка результатів бомбардування: фіксація картини після удару
Форма введення оцінки бойових пошкоджень (BDA) активується автоматично, коли статус вильоту переходить у стан "атака завершена". JTAC вводить: час удару (UTC), тип та кількість зброї, спостережуваний ефект, місцезнаходження воронки в MGRS, оцінку PT/PT та попередню оцінку супутніх втрат.
Якщо перша атака не досягла бажаного ефекту, запис BDA ініціює новий 9-лінійний запит, попередньо заповнений оновленим місцезнаходженням цілі. Всі дані BDA прив'язані до початкового 9-лінійного запиту через ідентифікатор вильоту та архівуються як частина незмінного запису вильоту.
Після операції: журнал вильотів, архів 9-лінійних запитів та відновлення хронології
Журнал вильотів надає хронологічний огляд усієї активності CAS: подані запити, затверджені запити, відхилені запити (із зазначенням причини відхилення), виконані атаки та результати BDA. Відновлення хронології для розбору використовує часові мітки переходів стану для генерації хронології подій, яку можна накласти на архів треків COP. Аудиторія розбору може переглядати виліт посекундно: коли було подано 9-лінійний запит, коли з'явилась зона ураження на COP, коли дружні сили були всередині або поза зоною, коли було надано дозвіл та коли зафіксовано BDA.