Коаліційна повітряно-морська картина рідко передається по єдиному каналу. Учасники з бойовою авіацією та засобами протиповітряної оборони обмінюються треками по Link 16; морські тактичні групи та учасники за горизонтом дедалі частіше передають свої треки по Link 22. Щойно обом спільнотам потрібно бачити одне одного, між двома мережами має бути щось, що переміщує треки — приймає J-серійне повідомлення по одному каналу, переформатує його для іншого і ретранслює, щоб контакт, зафіксований з будь-якого боку, правильно відображався в обох мережах. Це «щось» і є шлюз Link 16/Link 22, і правильна реалізація логіки трансляції та пересилання — одна з найвибагливіших задач у інтеграції тактичних каналів передачі даних. Ця стаття розповідає, як шлюз приєднується до обох мереж, як він транслює між двома середовищами J-серійних повідомлень і як пересилає треки без дублювання, зациклення або мовчазних втрат.

Навіщо взагалі потрібен шлюз

Link 16 і Link 22 — не конкуруючі стандарти, а взаємодоповнюючі, і порівняння між ними детально розглянуто у статті про Link 22 проти Link 16. Link 16 — це високотемповий канал прямої видимості для повітряної картини: точно синхронізована структура TDMA на терміналах JTIDS/MIDS у діапазоні 960–1215 МГц, що забезпечує оновлення треків кожні кілька секунд для швидкорухомих учасників. Link 22 створювався як сучасний наступник застарілого Link 11 для зв'язку за межами прямої видимості: організовує термінали в Super Network через HF та UHF із динамічним доступом до середовища, добре придатний для розосереджених морських сил і зв'язку за горизонтом.

Оскільки два канали обслуговують різні дальності, середовища і склад платформ, реальні операції часто виконуються з одночасним використанням обох. Корабель протиповітряної оборони в повітряній картині Link 16 і фрегат, що звітує по Link 22, належать до однієї бойової групи, і їхнім командирам потрібна єдина узгоджена картина. Шлюз — це вузол, що робить це можливим: він одночасно є учасником обох мереж, і його єдине завдання — підтримувати узгодженість двох картин, транслюючи та пересилаючи треки, які кожна зі сторін не може почути самостійно.

Спільна основа: J-серійні повідомлення

Причина, чому крос-канальна трансляція взагалі можлива, полягає в тому, що як Link 16, так і Link 22 передають одне й те саме сімейство повідомлень — каталог J-серій, визначений у сімействі стандартів MIL-STD-6016. Повітряний трек J2-серії по Link 16 і повітряний трек J2-серії по Link 22 описують один і той самий концептуальний об'єкт з однаковими концептуальними полями: положення, швидкість, висота, ідентичність, IFF та номер треку. Отже, трансляція — це переважно перевідображення, а не повне переформатування, що є суттєвим спрощенням порівняно з мостуванням двох принципово різних сімейств повідомлень.

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

Що переноситься без змін, а що потрібно перепакувати

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

Приєднання до обох мереж і вирівнювання часу

Перш ніж можна буде переслати хоча б один трек, шлюз повинен бути справним учасником обох мереж. З боку Link 16 це означає термінал класу MIDS, призначений набір TDMA-тайм-слотів для передачі, правильне криптографічне ключування та жорстку синхронізацію з часовим репером мережі. З боку Link 22 це означає акредитований термінал Link 22, приєднаний до Super Network, зі своїм ключуванням та синхронізацією часу мережі.

Вирівнювання часу — не формальність. Кожен J-серійний трек є значущим лише щодо часу вимірювання, і зведена картина корелює треки з кількох джерел, порівнюючи їх стани з часовою міткою. Якщо шлюз ненадійно синхронізований з будь-якого боку, введені ним треки матимуть неправильні часові мітки відносно нативних треків у приймаючій мережі, і приймаючий рівень злиття або відхилить їх як застарілі, або — що ще гірше — неправильно скорелює їх. Шлюз повинен синхронізувати свій годинник з часовим репером мережі Link 16, вирівняти час мережі Link 22 і проставляти часові мітки на кожному пересланому треку відповідно до реперу цільової мережі, а не власного вільнохідного годинника.

Конвеєр трансляції

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

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

Пересилання без дублювання і зациклення

Найскладніша проблема коректності будь-якого шлюзу пересилання — запобігти дублюванню, множенню або зворотному зацикленню треку. Три механізми працюють разом, щоб це запобігти.

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

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

Кореляція за ідентичністю і кінематичними параметрами. Один фізичний літак або корабель може незалежно з'явитися на обох каналах, якщо його чують нативно учасники кожної мережі. Якби шлюз наївно переслав обидва, зведена картина показала б два маркери для одного об'єкта. Кореляція за ідентичністю Mode 5/Mode S, де вона доступна, миттєво зводить їх до одного треку; там, де спільного ключа ідентичності немає, кінематична кореляція перевіряє, чи можуть два треки бути одним і тим самим об'єктом на основі узгодженого положення та швидкості. Ця кореляція — та сама дисципліна злиття, що застосовується щоразу, коли кілька джерел живлять одну картину, і ширше розглядається у статті про стандарти сумісності NATO.

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

Управління номерами треків у різних числових просторах

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

Класифікація, ключування та зона відповідальності програмної команди

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

Розподіл відповідальності варто сформулювати чітко. Логіка трансляції, пересилання, кореляції та управління треками — це звичайна розробка програмного забезпечення, вимоглива, але реалізована досвідченою командою. Обмежувальними елементами є акредитовані термінали (класу MIDS для Link 16, акредитовані термінали Link 22 для Link 22), національне криптографічне ключування та проектування мережі, що виділяє шлюзу його слоти і числові блоки. Це питання програмних і національних органів, що взаємодіють через процесор тактичного каналу передачі даних і стандартні хост-інтерфейси — та сама схема акредитації, що регулює наземні стандарти, такі як MIP4-IES.

Зроблений добре, шлюз є непомітним: морський контакт по Link 22 просто з'являється у повітряній картині Link 16, а трек швидкісного літака по Link 16 просто з'являється для морських сил за горизонтом — кожен з правильною ідентичністю, правильною часовою міткою і рівно одним маркером.

Об'єднайте Link 16 і Link 22 в одну узгоджену картину

Interoperability Dashboard зводить канали Link 16, Link 22 та інші тактичні канали передачі даних в єдину скорельовану загальну оперативну картину — із вбудованою дедублікацією треків шлюзового рівня та придушенням зациклення.

Переглянути Interoperability Dashboard → Замовити брифінг

Цей аналіз підготовлений інженерами Corvus Intelligence, що створюють місійно-критичне програмне забезпечення для забезпечення сумісності та тактичних каналів передачі даних для оборонних і урядових організацій. Дізнатися про нашу команду →