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

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

Виклик 1: Застарілі протоколи — Link 16, NFFI та Cursor on Target

Більшість тактичних каналів передачі даних у силах, що відповідають стандартам Альянсу, використовують протоколи, що передували сучасній архітектурі програмного забезпечення. Link 16 (STANAG 5516) кодує інформацію у вигляді повідомлень серії J фіксованої ширини — J2.0 для повітряних треків, J3.0 для наземних треків, J12.0 для даних радіоелектронної боротьби. Кожне повідомлення є бінарно-пакованою структурою з бітовим кодуванням, визначеним у специфікації STANAG. Жодного JSON, XML, самоописаного формату. Повідомлення J3.2 для наземного треку виділяє 3 біти для якості треку, 15 бітів для широти (в одиницях 0,0000537 градуса) і 15 бітів для довготи — конвенції, що сягають 1970-х років, коли ці формати проєктувалися для радіоканалів з обмеженою пропускною здатністю.

NFFI (NATO Friendly Force Information) використовує XML, але схема складна і залежить від версії. Різні нації реалізують різні профілі NFFI, і одне і те саме поле може нести різну семантику залежно від узгодженого профілю. Елемент Name у записі підрозділу NFFI може містити позивний, позначення підрозділу або тип техніки залежно від конвенції нації-постачальника — і у схемі немає прапора, який би вказував, яка інтерпретація використовується.

Cursor on Target (CoT) — це XML-схема, розроблена для обміну даними БпЛА і нині широко використовується для обміну треками в системах армії США. CoT є більш читабельним, ніж Link 16, але має власні труднощі розбору: елемент detail є нетипізованим полем вільного тексту, де додатки вбудовують пропрієтарні під-схеми як XML всередині XML без стандартизованої структури.

Практичне рішення: Патерн адаптера. Напишіть окремий парсер для кожного протоколу, який нормалізує вивід до канонічної внутрішньої схеми перед будь-якою подальшою обробкою. Бібліотека парсерів обробляє всю бітову математику для серії J, всі варіації профілів NFFI, всі варіанти під-схем елемента detail CoT. Решта системи бачить лише канонічну схему і ніколи не взаємодіє з форматами дротяного рівня. Тестуйте кожен адаптер на бібліотеці захопленого реального трафіку, а не лише синтетичних тестових повідомлень.

Виклик 2: Рівні класифікації та мережева сегментація

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

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

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

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

Виклик 3: Компроміс між затримкою та повнотою

Оборонні продукти даних існують на спектрі між оперативними треками в реальному часі та обдуманими розвідувальними продуктами. Оновлення радарного треку повинно надійти до COP менш ніж за 2 секунди — затримка робить його оперативно марним. Завершена розвідувальна оцінка, що синтезує HUMINT, SIGINT та IMINT, може займати 4 години і бути цілком дійсною при доставці.

Проблема виникає, коли конвеєр інтеграції намагається обслуговувати обидві вимоги єдиною архітектурою. Потокова обробка (Apache Kafka з Flink або Kafka Streams) забезпечує необхідну затримку для тактичних треків, але не має стативності та складних можливостей міркування, потрібних для виробництва розвідки. Пакетна обробка (ETL-конвеєри, сховища даних) обробляє складний багатоджерельний аналіз, але вводить затримки, неприпустимі для тактичних даних у реальному часі.

Практичне рішення: Лямбда-архітектура. Швидкісний рівень обробляє дані треків у реальному часі з коротким зберіганням. Пакетний рівень обробляє повну історію для розвідувальних продуктів. Обслуговуючий рівень об'єднує обидва для запитів. Явно визначте SLA для кожного типу продукту даних на початку проєкту і розробляйте кожен конвеєр незалежно для досягнення свого SLA.

Виклик 4: Версіювання схем і зворотна сумісність

Військові системи мають тривалі цикли розгортання. Система C2, розгорнута у 2015 році, може бути активною у 2030 році. Нова система датчиків, введена в експлуатацію у 2024 році, потребує інтеграції як зі старою системою C2 2015 року, так і з рушієм злиття сучасного покоління. Ці системи побудовані з різними версіями схем, різною семантикою полів і різними припущеннями щодо наявних даних.

Еволюція схем в оборонних системах ускладнюється тим, що визначення полів часто специфіковані контрактом або доктринально. Зміна визначення поля у повідомленні, що відповідає STANAG, потребує дії органу зі стандартизації. Зміна поля у національній системі потребує зміни до документа контролю інтерфейсу (ICD) — формального контрактного артефакту. Команди розробників не можуть просто мігрувати схеми, як це може робити команда веб-API.

Практичне рішення: Маршрутизація повідомлень з урахуванням версій з реєстром схем. Кожне вхідне повідомлення позначається ідентифікатором системи-джерела та версією. Реєстр схем зіставляє кортежі (джерело, версія) з конфігураціями парсерів. Ніколи не ігноруйте мовчки поля з вхідних даних — реєструйте всі нерозпізнані поля.

Виклик 5: Канонізація та рівень нормалізації

Кожна система-джерело має власне представлення принципово однакових концепцій. Трек у Link 16 кодує позицію в бітових полях, похідних від ECEF. Трек у CoT використовує десяткові градуси широти/довготи. Звіт HUMINT використовує координати MGRS. Канал AIS використовує десяткові градуси WGS84 з іншим порядком полів, ніж CoT. Перш ніж будь-який алгоритм злиття зможе працювати, всі представлення позицій мають бути у одній системі координат з однаковою точністю.

Нормалізація часу представляє власні виклики. GPS-час — це не UTC: він відрізняється на поточну кількість секунд координації (наразі 18 секунд). Системи, що змішують GPS-час і UTC без корекції, вносять систематичні 18-секундні помилки в результати кореляції. Деякі застарілі системи використовують час відносно місії (секунди від початку навчань), а не реальний час, вимагаючи зміщення початкової епохи для перетворення до абсолютних міток часу.

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

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