Авіаційний навідник (JTAC) діє на найбільш відповідальному перехресті сучасної бойової авіації: там, де наземне спостереження, можливості доставки авіаційних боєприпасів і правила застосування зброї зходяться в одній точці для санкціонування відкриття вогню в кількох сотнях метрів від власних сил. Процедури, що регулюють цей процес, — 9-рядковий брифінг CAS, ланцюжок дозволу, підтвердження типу мітки — були розроблені для голосового радіозв'язку і більш-менш успішно функціонують впродовж десятиліть. Цифрові інструменти не замінюють ці процедури; вони змінюють середовище, у якому процедури виконуються, і тим самим усувають конкретні збої, яких голосове радіо позбутися не в змозі.
У цій статті розглядається, як ці цифрові інструменти виглядають на практиці: як працює автоматичне формування 9-рядкового запиту, як координати цілі потрапляють до екіпажу без голосового зачитування, як забезпечується деконфліктація повітряного простору без ручного перехресного звірення, як відеозображення з ROVER інтегрується із наземною обстановкою, як програмне забезпечення координації вогню деконфліктує CAS із непрямою вогневою підтримкою через AFATDS і що відбувається з цифровим робочим процесом під час відмови мережі. Описана тут архітектура однаково застосовна як до JTAC, що управляють ударними літаками із нерухомим крилом, так і до спостерігачів об'єднаних вогневих ударів (JFO), що викликають непрямий вогонь, — базова модель даних і логіка деконфліктації є спільними.
Робочий процес JTAC від виявлення цілі до застосування боєприпасу
Виліт CAS проходить передбачувану послідовність фаз незалежно від типу платформи чи цілі. Розуміння того, де втручаються цифрові інструменти, а де — ні, вимагає точного картографування робочого процесу.
Виліт починається з виявлення цілі: JTAC спостерігає ціль через пряму оптику, отримує цифрову передачу від сенсорної платформи або виявляє ціль на відеозображенні ROVER. У цифровому робочому процесі це спостереження одразу фіксується як попередній маркер COP — координати MGRS, тип цілі зі структурованої таксономії, час виявлення та рівень впевненості. Маркер COP є вихідним записом для всього, що настане далі.
Потім JTAC формує 9-рядковий брифінг. У голосовому процесі це розумова вправа, що виконується за запам'ятованим форматом. У цифровому процесі форма 9 рядків відкривається з попередньо заповненими даними з маркера COP: розташування цілі, розрахована відстань і курс від визначеної початкової точки, висота цілі з бази даних рельєфу. JTAC перевіряє та заповнює поля, що залишилися, — тип мітки, опис цілі, розташування своїх сил — і подає запит через ланцюжок затвердження.
Ланцюжок затвердження — від JTAC до авіаційного передового авіанавідника (AFAC) і до уповноваженого органу при запланованому CAS, або від JTAC безпосередньо до AFAC при терміновому CAS — існує на спільних картографічних даних у цифровому процесі. Уповноважений орган бачить ту саму геометрію зони ураження, яку зібрав JTAC, а не рядок координат, який він має ментально проектувати на карту. Затвердження є навмисною дією, пов'язаною з видимим просторовим відображенням, а не голосовим підтвердженням, яке може відображати, а може й не відображати повне розуміння геометрії цілі.
Після затвердження координата цілі надсилається до навігаційної системи літака через канал передачі даних там, де є така можливість, а JTAC позначає ціль призначеним типом мітки — лазером, ІЧ-покажчиком або координатами GPS. Літак атакує. JTAC спостерігає через відео ROVER, якщо є, і фіксує оцінку бойових пошкоджень у записі про виліт. Якщо потрібна повторна атака, запис BDA формує новий 9-рядковий запит з попередньо заповненим оновленим розташуванням цілі.
Цифрові інструменти втручаються на п'яти з цих фаз: фіксація виявлення, формування 9-рядкового запиту, візуалізація затвердження, передача координат і запис BDA. Фаза виконання атаки — фізична дія маркування та спостереження — повністю залишається в руках JTAC. Ця межа є навмисною: цифровий CAS розширює можливості людини на фазах обробки інформації; він не автоматизує рішення про термінальне управління.
Програмне забезпечення для 9-рядкового запиту CAS
Форма 9-рядкового запиту CAS є найбільш чутливим до помилок документом при авіаційній підтримці. Одна помилка в полі — переставлена цифра MGRS у рядку 6, неправильний курс у рядку 2, занижена відстань до своїх сил у рядку 8 — може направити боєприпас на неправильну ціль або на власні війська. Цифрове програмне забезпечення для 9-рядкового запиту усуває цей ризик, замінюючи передачу вільного тексту голосом структурованою схемою, яка перевіряє типи, контролює узгодженість і забезпечує візуальне підтвердження кожного критичного поля.
Автоматичне заповнення координат. Коли JTAC відкриває форму 9 рядків з активним маркером цілі COP, рядок 6 (розташування цілі) автоматично заповнюється з координат маркера в MGRS і десятковому форматі широта-довгота. Система автоматично конвертує між форматами і зберігає обидва подання з явним тегом датуму (WGS84). Запит візуального підтвердження відображає координату як точку на карті і запитує JTAC: «Чи це правильне розташування цілі?» Крок підтвердження є обов'язковим — поле не може бути прийняте без нього — і підтвердження фіксується з ідентифікатором оператора JTAC і міткою часу.
Розрахунок відстані та курсу. Рядки 2 і 3 (курс атаки і відстань від початкової точки до цілі) автоматично розраховуються з полів початкової точки і розташування цілі, коли обидва заповнені з COP. Розраховані значення відображаються поряд із полями форми у вигляді просторової діаграми — початкова точка, стрілка осі атаки та точка цілі відображаються на міні-карті, вставленій у форму, — щоб JTAC міг переконатися, що геометрія відповідає його розумінню геометрії атаки перед поданням. Ручне перевизначення дозволяється, але фіксується як відхилення від розрахункового значення.
Висота цілі з бази даних рельєфу. Рядок 4 (висота цілі у футах над рівнем моря) автоматично заповнюється з бази даних рельєфу для координати цілі. Джерело і дата даних рельєфу відображаються поряд із полем — набір даних DTED рівня 1 від 2019 року потребує більшої обережності, ніж нещодавно отримана ЦМР. JTAC приймає або змінює значення бази даних; зміна вимагає введення підстав для оцінки JTAC (пряме спостереження ознак рельєфу, нещодавні знімки тощо).
Структурований опис цілі. Рядок 5 використовує ієрархічну таксономію замість вільного тексту: основна категорія (транспортний засіб, особовий склад, споруда, обладнання, інфраструктура), вторинна класифікація у межах цієї категорії та поле приміток для деталей, що не вписуються в таксономію. Структурована класифікація дозволяє автоматично перевіряти правила застосування зброї під час подання — система може позначити, чи належить тип цілі до попередньо дозволених категорій, чи вимагає додаткового маршруту затвердження.
Перехресна перевірка розташування своїх сил. Рядок 8 (розташування своїх сил відносно цілі) є полем з найвищим ризиком дружнього вогню у 9-рядковому запиті. JTAC вводить азимут і відстань — «300 метрів на південь» — і система перехресно перевіряє цей запис із фактичними позиціями дружніх об'єктів COP. Якщо найближчий дружній об'єкт у COP знаходиться на 150 метрів на південь, а не на 300, розбіжність генерує попередження. JTAC повинен явно підтвердити розбіжність і підтвердити, яке значення є правильним. Ця перехресна перевірка не блокує подання — JTAC має наземну реальність, яку COP може не відображати, — але виявляє розбіжність, а не мовчки приймає потенційно некоректне поле.
Перевірка помилок конвертації координат. Будь-який запис координат — чи то MGRS, широта-довгота, чи UTM — аналізується за правилами допустимості для відповідної системи координат і перехресно перевіряється з обмежувальним прямокутником оперативного району. Координатна прив'язка, що виходить за межі театру воєнних дій або не проходить перевірку контрольної суми, генерує блокуючу помилку перед тим, як JTAC може подати запит. Це перехоплює найпоширенішу категорію помилок транскрипції: цифру, яка технічно є дійсною координатою, але розміщує ціль у неправильному квадраті MGRS 100 км.
Передача координат цілі та інтеграція лазерного/RFID маркування
Передача координат цілі від JTAC до екіпажу є кроком, де голосовий процес вводить останній і найкритичніший ризик транскрипції: пілот вручну вводить координату в навігаційну систему за голосовим зачитуванням. Цифрова передача повністю усуває цей крок для платформ із сумісними каналами передачі даних.
Передача точки наведення через канал даних. Після затвердження 9-рядкового запиту система надсилає координату цілі до бортового комп'ютера літака як точку наведення через відповідний для платформи канал даних: Link 16 для коаліційних реактивних літаків із авіонікою JTIDS, SADL (Situational Awareness Datalink) для штурмовиків A-10 і деяких гвинтокрилих платформ або платформно-специфічні хвильові форми для авіації сил спеціальних операцій. Переданій точці наведення присвоюється ідентифікатор вильоту, щоб і JTAC, і пілот могли підтвердити, що вони посилаються на один і той самий запис цілі. Підтверджувальне повідомлення від літака — «точка наведення отримана, координата підтверджена» — замикає петлю передачі в цифровому записі.
Коли пряма передача через канал даних недоступна — для старих літаків, коаліційних платформ без сумісних хвильових форм — система генерує форматований файл завантаження точки наведення, сумісний із системою планування польоту літака, або структурований голосовий брифінг, відформатований для мінімізації помилок при зачитуванні. У будь-якому випадку координата цілі в затвердженому 9-рядковому записі є авторитетним джерелом, і будь-яке відхилення між цим записом і завантаженою точкою наведення позначається, якщо канал зворотного підтвердження пілота підтримує це.
Інтеграція лазерного коду SOFLAM і IZLID. Коли тип мітки в рядку 7 — лазер, лазерний код — чотиризначний код PRF, який система лазерного виявлення літака використовує для розпізнавання правильного позначувача серед інших лазерів на полі бою, — має дістатися до літака без помилок голосової передачі. Цифрові інструменти вирішують цю проблему, зберігаючи лазерний код у профілі обладнання JTAC, автоматично заповнюючи його в поле рядку 7 форми 9 рядків і включаючи його до передачі через канал даних на літак. Якщо доступна інтеграція SOFLAM або IZLID через цифровий інтерфейс (деякі варіанти підтримують USB або послідовне з'єднання), система може запитати поточне налаштування коду позначувача і автоматично підтвердити відповідність коду в 9-рядковому запиті коду, запрограмованому на пристрої.
Відображення зони цілі і точки наведення на ROVER. Коли термінал ROVER JTAC має можливість накладення «курсор-на-ціль» — програмна функція, доступна в ROVER 6 і пізніших поколіннях, — затверджений маркер цілі COP прив'язується до відеопотоку ROVER. Розташування цілі відображається у вигляді перехрестя поверх відеозображення, що дозволяє JTAC візуально перевірити, чи спрямований сенсор літака на правильну точку прицілювання перед наданням дозволу. Якщо перехрестя і очевидна точка прицілювання літака розходяться, JTAC отримує прямий візуальний індикатор помилки прицілювання до скидання зброї.
Деконфліктація повітряного простору для CAS
Деконфліктація повітряного простору для CAS — це не одноразова перевірка, а безперервний процес, що охоплює від визначення зони ураження до звільнення повітряного простору після удару. Програмне забезпечення деконфліктації повітряного простору автоматизує найбільш трудомісткі елементи цього процесу: перехресне звірення зони ураження з активними заходами контролю повітряного простору, розрахунок висотних блоків та послідовне розмежування конфліктуючих користувачів у часі.
Визначення зони ураження по горизонталі і вертикалі. Зона ураження визначається центральною точкою (розташуванням цілі з рядка 6), бічним радіусом (визначається типом зброї, оцінкою супутнього збитку та рельєфом) і висотним блоком (мінімальна та максимальна висота для атакувального заходу). Ці три параметри разом визначають тривимірний об'єм, який має бути деконфліктований з усіма іншими користувачами повітряного простору до того, як JTAC може перейти до затвердження.
Координація з заходами контролю повітряного простору. Заходи контролю повітряного простору — заборонені зони, маршрути мінімального ризику, заборонені для польотів зони, зони спільного застосування зброї та зони вільного вогню — підтримуються на рівні управління повітряним простором і оновлюються на основі стрічок ATO та ACO. Модуль деконфліктації накладає запропоновану зону ураження на всі активні заходи контролю на момент подання. Будь-яке перекриття генерує конкретний звіт про конфлікт: який захід порушено, хто є контролюючим органом, який дійсний часовий діапазон і чи може запит на координацію бути надісланий цифровим способом до цього органу. Для тимчасово обмежених районів і витримок ATC запит координації є автоматизованим — система надсилає запит до цифрового інтерфейсу контролюючого органу і чекає на схвалення або призначення альтернативного вікна.
Управління висотним блоком. Висотний блок зони ураження має бути скоординований не лише зі статичними заходами контролю, а й з усіма динамічними користувачами повітряного простору: іншими вильотами CAS у тому ж районі, траєкторіями артилерії (деконфліктованими через вогневий рівень), платформами ISR, що затримуються на середній висоті, і будь-яким радарним покриттям ППО, яке потребує сповіщення перед входом літаків у визначений об'єм. Модуль деконфліктації підтримує актуальну картину розподілу висотних блоків і призначає запитуваному вильоту CAS висотне вікно, що не конфліктує з наявними резервуваннями. Якщо запитуваний JTAC висотний блок не може бути виділений без конфлікту, модуль пропонує наступне доступне вікно і відображає час очікування.
Деконфліктація у часі. Коли два вильоти CAS потребують перекриваючихся об'ємів повітряного простору, але не одночасно, часова деконфліктація призначає вікна виконання замість горизонтального або вертикального поділу. Перший виліт отримує вікно від T+0 до T+8 хвилин; другий виліт утримується і займає T+10 до T+18 хвилин. JTAC бачить своє призначене вікно на інтерфейсі затвердження і відповідно планує виконання атаки. Виліт, що виходить за межі вікна, генерує сповіщення як JTAC, так і менеджеру повітряного простору, оскільки перевищення створює конфлікт з наступним виділеним вильотом.
Інтеграція ROVER/TRAC для CAS
ROVER (Remotely Operated Video Enhanced Receiver) дає JTAC те, чого не забезпечує жоден інший інструмент: той самий візуальний образ, який оператор сенсора літака використовує для виявлення і ураження цілі. При голосовому процесі JTAC і пілот дивляться на спільну координату, але не на спільне зображення — JTAC спостерігає за землею через бінокль, пілот — через прицільний pod, і ці два зображення можуть не збігатися щодо того, яка ознака є передбачуваною ціллю. ROVER усуває цей розрив.
Накладення «курсор-на-ціль». Цифрова інтеграція між ROVER і програмним забезпеченням C2 для CAS додає накладення «курсор-на-ціль» до відеопотоку: затверджений маркер цілі COP прив'язується до кадру відео ROVER за допомогою метаданих сенсора літака (похила дальність, кут гімбала, положення та висота літака). Розташування цілі відображається як символ перехрестя на відео. Якщо перехрестя знаходиться на іншій будівлі, ніж та, на яку спрямований сенсор пілота, JTAC може виявити розбіжність перед наданням дозволу і ініціювати наведення для коригування прицілювання літака.
Відображення лазерного плями. Варіанти ROVER, що включають систему відстеження лазерного плями (LST), виявляють лазерне пляма JTAC на відеозображенні і відображають його розташування як другий символ на накладенні «курсор-на-ціль». JTAC може бачити в режимі реального часу, чи знаходиться лазерне пляма на ознаці цілі, позначеній перехрестям, чи зміщений від неї — поширена проблема, коли рельєф перекриває пряму видимість між JTAC і ціллю. Якщо лазер не потрапляє в ціль, JTAC коригує підсвічування без необхідності голосового обміну з пілотом.
Програмно визначений ROVER (інтеграція TRAC). TRAC (Tactical Remote Viewing System) і наступні програмно визначені реалізації приймача відеосигналу дозволяють передавати відеопотік сенсора літака на будь-який мережевий пристрій — захищений планшет, ноутбук, смартфон у надзвичайній ситуації — а не вимагати виділеного апаратного терміналу ROVER. Програмне забезпечення C2 для CAS отримує відеопотік через стандартний транспорт RTSP або STANAG 4609, сумісний із MISB, і відображає його в тому ж інтерфейсі, що й форма 9 рядків і відображення COP. Один екран одночасно показує JTAC статус 9-рядкового запиту, зону ураження COP і відеопотік літака — усуваючи перемикання погляду між терміналом ROVER, картою і радіо, що характеризувало координацію CAS попереднього покоління.
Синхронізація вогню з AFATDS і FDC
Авіаційна підтримка рідко здійснюється ізольовано від непрямого вогню. Артилерійські і мінометні засоби можуть придушувати суміжні ворожі позиції, забезпечувати вогонь придушення ППО (SEAD) до заходу літака CAS, або прикривати маршрут відходу JTAC після удару. Деконфліктація цих одночасних засобів ураження — забезпечення того, щоб артилерійський снаряд не увійшов у висотний блок CAS, поки літак перебуває на бойовому заході, — вимагає цифрового з'єднання між інструментом координації CAS JTAC і системою командування і управління вогнем.
Цифровий запит вогню з COP. Коли JTAC або JFO викликає непряму вогневу підтримку з того самого запису цілі, що використовується для CAS, цифрове повідомлення CFF генерується з наявного маркера COP — та сама координата MGRS, та сама таксономія опису цілі, той самий ідентифікатор вильоту для перехресного посилання. CFF маршрутизується до пункту управління вогнем (FDC) через AFATDS, доповнюючи облікові дані спостерігача вогню та метод спостереження (наземний спостерігач, БПЛА, літак). Якщо та сама ціль отримує і запит CAS, і запит CFF, обидва пов'язуються у рівні координації вогню за спільним ідентифікатором вильоту, створюючи єдиний запис синхронізації вогню.
Деконфліктація між CAS і непрямим вогнем. AFATDS підтримує чергу активних і запланованих вогневих місій із їхніми траєкторіями, часовими вікнами удару та висотними конвертами. Модуль деконфліктації CAS запитує цю чергу перед затвердженням висотного блоку CAS. Якщо траєкторія будь-якої активної вогневої місії входить у висотний блок CAS над районом цілі під час запланованого вікна атаки, модуль деконфліктації генерує запит на утримання до FDC: «Утримати вогонь по місії [ID] — конфлікт висотного блоку CAS з T+3 до T+9». FDC коригує час і звільняє висотний блок CAS. Утримання і звільнення фіксуються з мітками часу у записі синхронізації вогню.
Координація SEAD. Придушення засобів ППО противника перед атаковим заходом CAS вимагає послідовного розміщення вогню SEAD, щоб він прибував до того, як літак CAS увійде в прикрите угрупування, і вщухав до того, як літак вийде — а не до того, як він увійде. Цифрові інструменти підтримують запис часу SEAD, пов'язаний з вильотом CAS: розташування і тип загрозливих засобів ППО, призначена вогнева місія SEAD для їх придушення і вікно, протягом якого придушення підтверджено активним. Процес затвердження CAS перевіряє, що вогневі місії SEAD підтверджені в черзі AFATDS, перш ніж дозволити вхід літака CAS. Вогнева місія SEAD, яка затримується або скасовується, генерує затримку у ланцюжку затвердження CAS, і JTAC бачить конкретно, яка місія SEAD блокує дозвіл.
Архітектура синхронізації вогню також обробляє зворотний випадок: вогневі місії непрямого вогню, які повинні деконфліктувати з активними висотними блоками CAS, вже зарезервованими на рівні управління повітряним простором. Інтеграція AFATDS із потоком даних управління повітряним простором дозволяє FDC бачити активні висотні блоки CAS перед прийняттям нової вогневої місії та прокладати нові місії через траєкторії, що уникають зайнятих висотних блоків, не покладаючись на те, що JTAC виявить конфлікт і оголосить припинення вогню.
Уроки впровадження цифрового CAS
Цифрові інструменти CAS застосовуються в оперативних умовах вже достатньо довго, щоб виявити стійкі характер відмов, що впливають як на архітектуру, так і на підготовку. Ці уроки не є гіпотетичними — вони відображають повторювані спостереження з розборів польотів при операціях CAS, де цифрові інструменти були частиною ланцюга ураження.
Обмеження зв'язку у зонах радіоелектронного протиборства. Електромагнітне середовище, що погіршує зв'язок, також погіршує канали передачі даних, від яких залежать цифрові інструменти CAS. Відео ROVER є найбільш пропускомісткою компонентою і відмовляє першою; накладення «курсор-на-ціль» стає недоступним без відеопотоку. Синхронізація COP в TAK потребує вузькішого каналу і деградує більш плавно — картина COP заморожується, а не зникає, відображаючи останні відомі позиції дружніх об'єктів. Подання форми 9 рядків і затвердження повідомлень можуть працювати через дуже вузькі MANET-канали і мережі збереження та пересилання. Повідомлення AFATDS CFF, як правило, використовують стійкий тактичний радіоканал передачі даних. Інструменти мають бути спроектовані, а JTAC — підготовлені таким чином, щоб розуміти, які саме можливості деградують при яких порогових значеннях ширини смуги, і переходити до відповідних процедур деградованого режиму, не чекаючи повної відмови каналу.
Самозаспокоєність при автоматизації. Автоматично заповнені поля — розташування цілі з COP, відстань з геометрії, висота з бази даних рельєфу — знижують когнітивне навантаження під час інтенсивного ураження цілей, але створюють новий режим відмови: JTAC приймає попередньо заповнене значення без його перевірки. У розборах польотів випадки неправильного розташування цілі були пов'язані з помилками розміщення маркерів COP, яких JTAC не помітив, оскільки автоматично заповнена координата «виглядала правильно» без навмисної перевірки. Дизайн інтерфейсу повинен візуально відрізняти автоматично заповнені поля від введених вручну, вимагати явного підтвердження для кожного критично важливого поля та відображати джерело даних поля, щоб JTAC знав, що він підтверджує.
Плутанина режимів у процесах затвердження. Заплановані та термінові CAS вимагають принципово різних процесів затвердження, і JTAC під часовим тиском стабільно намагається спрямувати термінові запити через черги запланованого CAS, коли інтерфейс не робить відмінність очевидною. Перемикання режиму з запланованого на терміновий CAS має бути стійким, видимим станом інтерфейсу — а не пунктом меню або прапорцем форми — оскільки JTAC, який одночасно керує радіозв'язком, спостерігає за ціллю і координується з літаком, не має когнітивної пропускної здатності помічати тонку різницю у стані інтерфейсу. Якщо режим неправильний, виліт займе на три хвилини більше, ніж дозволяє вікно ураження.
Процедури деградованого режиму як базові навички. JTAC, що проходять навчання виключно на цифрових інструментах і вважають голосовий 9-рядковий запит резервним навичком, який «згадають, коли знадобиться», стабільно показують погані результати при відмові цифрових каналів у навчальних вправах — і розрив у результатах в умовах оперативного стресу гірший, ніж при навчанні. Цифрові інструменти CAS повинні впроваджуватись як прискорювач для JTAC, що вже вільно володіє голосовим навиком, а не як його замінник. Програми підготовки, що використовують цифрові інструменти з першого дня кваліфікації CAS, готують JTAC, які вільно володіють інструментами, але не можуть ефективно діяти, коли інструменти недоступні. Дисципліна розгляду роботи в деградованому режимі як базового навику — а не контингентного — є найважливішим уроком з людського фактору при впровадженні цифрового CAS.