Програмні шлюзи для трансляції тактичних каналів передачі даних: Link 16, VMF, CoT та NFFI

Коаліційне об'єднане оперативне угруповання функціонує в умовах несумісних мов даних. Авіаційний компонент розмовляє Link 16 — J-серійні повідомлення MIL-STD-6016 через хвильову форму JTIDS/MIDS. Наземні сили обмінюються позиціями та наказами у VMF (Variable Message Format) через тактичні радіостанції або у NFFI (NATO Friendly Force Information) через IP між системами C2 рівня бригади. Піхотні солдати та офіцери управління вогнем відправляють події CoT (Cursor-on-Target) через IP з планшетів ATAK. Розвідувальні системи публікують треки у власному XML або у стандарті обміну інформацією MIP. Жоден з цих форматів не розмовляє рідно з іншими. Програмний шлюз — це те, що забезпечує їх сумісність: приймаючи кожен формат, транслюючи семантичний вміст в інший формат, управляючи ідентичностями результуючих треків, застосовуючи правила фільтрації та доставляючи переведені дані в межах бюджету затримки, що зберігає тактичну корисність спільної оперативної картини. У цій статті розглядається, як шлюзи тактичних каналів передачі даних (TDL) функціонують і де вони регулярно не виправдовують очікувань.

Ландшафт каналів передачі даних

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

Link 16 — визначений у MIL-STD-6016 — це хвильова форма з часовим розділенням доступу, розроблена для повітряної боротьби. Його J-серійні повідомлення несуть треки спостереження, дані PPLI (Precise Participant Location and Identification), повідомлення управління місією та вміст координації зброї. Link 16 є компактним, зашифрованим, малозатримковим і стійким до перешкод за конструкцією. Його пропускна здатність ділиться між усіма терміналами в мережі через часові слоти TDMA, що накладає жорстку стелю на кількість треків, якими можна ділитися з якою частотою оновлення. Мережа Link 16 — це не мережа IP загального призначення; це спеціалізована шина повідомлень з фіксованою ємністю та жорсткою схемою повідомлень. Докладніше про архітектуру Link 16 дивіться в нашому аналізі тактичних каналів передачі даних Link 16.

VMF (Variable Message Format, MIL-STD-2045-47001) є стандартом сухопутних військ США та об'єднаних сил для цифрових тактичних повідомлень. Повідомлення VMF кодуються двійково і оптимізовані для вузькосмугових радіоносіїв — конструктивне рішення, що дозволяє їм переноситися на каналах радіо HF або VHF з пропускною здатністю в кілобіти на секунду. VMF охоплює широкий спектр типів повідомлень: доповіді про ситуаційну обізнаність, цифрові накази, запити вогневої підтримки, логістичні повідомлення та інше. Двійкове кодування робить VMF компактним, але негнучким; додавання нового типу повідомлення вимагає формальної зміни специфікації.

CoT (Cursor-on-Target) — це XML-схема подій, розроблена для екосистеми TAK (Team Awareness Kit). Подія CoT — це мінімальна, розширювана структура: унікальний ідентифікатор (UID), географічна позиція, тип події, взятий з таксономії (включаючи коди символів MIL-STD-2525), час існування та необов'язкові елементи деталей. CoT був розроблений простим і рідним для IP, читабельним як людьми, так і машинами, розширюваним без зламу парсерів і достатньо малим для проходження через тактичний радіоканал. Він став де-факто спільною мовою спільноти піхотного солдата та офіцера управління вогнем, і дедалі більше — операторів БпЛА та сил спеціальних операцій.

NFFI (NATO Friendly Force Information, STANAG 5527) — це натівський стандарт для обміну даними про позицію та ідентичність дружніх сил між наземними системами C2 через IP. Він визначає набір повідомлень для доповіді про трек, управління треком і передачі повноважень. NFFI є каналом даних вибору для систем C2 рівня бригади та вище, яким необхідно обмінюватися треками наземних сил з союзними системами — він забезпечує спільну мову для наземної картини на оперативному рівні так, як Link 16 (розроблений для повітряної картини) не робить.

Що насправді робить шлюз TDL

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

Розбір повідомлень і нормалізація

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

Нормалізація — це місце, де відбуваються перші семантичні втрати. Повідомлення стеження J3.0 Link 16 несе число якості треку за визначеною шкалою; CoT не має еквівалентного поля. Розділ деталей події CoT може нести коди символів, але та сама платформа може бути описана по-різному в треці Link 16. Шлюз повинен документувати, що він зберігає і що втрачає в кожному напрямку трансляції — і оператори повинні бути проінформовані про ці обмеження.

Управління треками і кореляція повідомлень

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

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

Кореляція стає особливо складною, коли треки Link 16 — що оновлюються кожні два-дванадцять секунд і несуть геодезичні позиції високої точності — корелюються з треками CoT від пристроїв TAK, які можуть оновлюватися рідше і нести позиції, що відображають точність GPS, а не точність, злиту з датчиків радарного треку. Наземний датчик, що доповідає про рухоме транспортне засіб в CoT, і трек спостереження Link 16 для того самого транспортного засобу можуть бути розділені десятками метрів на момент порівняння, навіть якщо обидві доповіді є точними. Пороги кореляції повинні бути встановлені достатньо широкими, щоб охопити ці випадки, не генеруючи хибних кореляцій між близькими, але різними об'єктами.

Правила фільтрації та розкриття

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

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

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

Бюджет затримки

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

Затримка в шлюзі накопичується з кількох джерел: глибина вхідної черги при перевищенні швидкості обробки швидкістю надходження повідомлень, час обробки кореляції для складних сценаріїв кореляції «багато-до-багатьох», час серіалізації виходу для великих пакетів, і час транзиту мережею до споживача. Найгірший випадок — сплеск оновлень Link 16 під час інтенсивного повітряного бою, всі з яких вимагають кореляції з великою існуючою базою даних треків — це саме той момент, коли затримка має найбільше значення. Проектувальники шлюзів повинні проводити стрес-тести під реалістичними пікових навантажень сценаріями, а не лише орієнтирами за середнім навантаженням, і вказувати 99-відсоткову затримку, а не середню.

Відкриті стандарти та екосистема шлюзів

Ринок шлюзів TDL включає як власні військові системи, так і реалізації, побудовані на відкритих або опублікованих специфікаціях. На відкритій стороні, схема CoT опублікована та широко реалізована; екосистема TAK виробила відкриті референсні реалізації, що лежать в основі багатьох шлюзів, розроблених урядами. NFFI (STANAG 5527) є натівським стандартом, доступним для країн-членів. MIL-STD-6016 та MIL-STD-2045-47001 є стандартами США з контрольованим розповсюдженням, але їх формати повідомлень достатньо задокументовані, що незалежні реалізації існують в оборонній промисловій базі.

XMPP (Extensible Messaging and Presence Protocol) виник як транспортний рівень вибору для розповсюдження CoT в екосистемі TAK та в FMN, як тому що він забезпечує семантику надійного обміну повідомленнями через IP, так і тому що його федеративна архітектура масштабується до коаліційного використання без єдиного центрального брокера. Кілька національних реалізацій служб обміну повідомленнями FMN побудовані на XMPP з CoT як корисним навантаженням, створюючи де-факто шар розповсюдження треків коаліції під більш формальною архітектурою NFFI. Шлюзи, що підтримують XMPP як вхід і вихід, можуть обслуговувати як спільноту наземних сил, орієнтованих на TAK, так і спільноту коаліційних систем C2, орієнтованих на FMN, з єдиної точки інтеграції. Ширша роль CoT у сумісності НАТО розглядається в нашій статті про CoT і TAK у сумісності НАТО.

Шаблон шлюзу API — надання трансляції TDL як служби через API REST або gRPC, а не як власний бінарний інтерфейс — набирає популярності, оскільки архітектури коаліцій рухаються до сервісно-орієнтованих проектів. Шлюз TDL на основі API може інтегруватися з платформами обміну коаліційними даними, включаючи шаблони шлюзу API для обміну коаліційними даними, описані в нашому суміжному аналізі, без необхідності спеціальної низькорівневої інтеграції для кожної системи-споживача. Компроміс у тому, що HTTP/REST додає затримку відносно прямого бінарного підключення — що може або не може вкладатися в бюджет затримки залежно від варіанту використання.

Стандарт MIP4 та IES — модель даних наземних сил НАТО — визначає семантичний рівень, який повинні використовувати наземні системи C2 при обміні силовою інформацією. Повноцінний коаліційний шлюз повинен вміти відображати до і від канонічних об'єктів і відносин MIP, а не лише до формату повідомлень NFFI. Для отримання детальної інформації про MIP4 та IES, дивіться наш аналіз MIP4 та IES: стандарт даних наземних сил НАТО.