Злиття військових даних — це обчислювальний процес поєднання розвідки з кількох різнорідних джерел в узгоджене, несуперечливе та точне представлення оперативного середовища. Коли воно працює, командир бачить один трек з міткою «танк Т-80, достовірність 87%, оновлено 14 секунд тому». Коли ні — три конфліктуючих треки, кожен від різного датчика, кожен з іншою позицією, і жодного способу дізнатися, який правильний.

Правильне злиття є одним з найбільш технічно складних завдань в оборонному програмному забезпеченні. Вхідні дані зашумлені, затримані та часто суперечать одне одному. Вивід має бути достатньо надійним для прийняття рішень на його основі.

Модель JDL: основа для рівнів злиття

Модель групи інформації злиття даних (DFIG) — широко відома як модель JDL за її походженням з Joint Directors of Laboratories — визначає злиття як ряд рівнів обробки, кожен з яких будується на попередньому.

Рівень 0 — Асоціація та оцінка даних субоб'єктів. Необроблені сигнали датчиків обробляються та очищуються. Зображення на рівні пікселів попередньо обробляються; акустичні дані оцифровуються; радіочастотні сигнали демодулюються. Вивід — потік спостережень, ще не співвіднесених з жодним об'єктом.

Рівень 1 — Уточнення об'єктів. Окремі спостереження об'єднуються для отримання треків. Кілька радарних відбиттів від одного фізичного об'єкта асоціюються та зливаються в один кінематичний трек. Цей рівень вирішує основну задачу злиття треків: при п'яти радарних попаданнях за 30 секунд оцінити позицію об'єкта, швидкість та курс з пов'язаним еліпсом невизначеності. Використовувані алгоритми: фільтрація Калмана, відстеження з множинними гіпотезами (MHT) та спільна ймовірнісна асоціація даних (JPDA).

Рівень 2 — Уточнення ситуації. Окремі треки розміщуються в контекст. Цей рівень відповідає на питання «що означає це формування?» — розпізнаючи, що три танки, що рухаються клином з артилерією позаду, становлять спробу прориву, а не патрулювання. Злиття рівня 2 потребує кореляції треків з доктриною, базами даних бойового порядку та історичними патернами.

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

Джерела даних та їх програмні виклики

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

Продукти IMINT є виводом розвідки зображень — або автоматичної (виявлення за допомогою комп'ютерного зору з потоків БпЛА), або ручної (анотації аналітиків зображень). Виклик полягає в точності міток часу: зображення, отримане о 09:47, що показує транспортний засіб у координатах X, корисне лише якщо рушій злиття знає, що воно отримане о 09:47, а не оброблене та подане о 11:15.

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

Потоки датчиків радіоелектронної боротьби надають дані про електронні випромінювання — набори параметрів радарів, частоти зв'язку, сигнатури форм сигналів. При кореляції з даними треків вони дозволяють ідентифікацію платформ: трек, що рухається зі швидкістю 60 км/год, відповідний сигнатурі випромінювання радара БМП-2, стає ідентифікацією БМП-2 з високою достовірністю.

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

Виклики нормалізації: прихована складність

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

Нормалізація системи координат: датчики повідомляють позиції в WGS84, MGRS, місцевій сітці або координатних системах, залежних від висоти. Усі повинні бути перетворені до канонічного представлення перед тим, як стане можливою кореляція. Похибка 10 метрів, введена перетворенням координат, є оперативно значущою.

Нормалізація міток часу: різні датчики використовують час GPS, UTC, місцевий час або порядкові номери. Рушій злиття потребує авторитетних міток часу в єдиній системі відліку. Мітка часу, синхронізована з GPS, є стандартом, але не всі застарілі датчики її підтримують.

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

Кореляція та деконфліктація

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

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

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

Як злиття живить COP

Рушій злиття виробляє авторитетне сховище треків, що відображає загальна оперативна картина (COP). Рівень COP запитує сховище треків через API, підписується на події оновлення через WebSocket та поступово відображає зміни. Якість COP повністю залежить від якості рівня злиття під ним.

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