Коли команди розробників оборонного ПЗ говорять про архітектуру злиття даних, вони майже неминуче посилаються на модель JDL — незалежно від того, використовують вони цю назву чи ні. Модель JDL (Joint Directors of Laboratories), спочатку розроблена у 1985 році та суттєво переглянута у 1990-х та 2004 році, надає канонічну декомпозицію злиття даних на ієрархію рівнів обробки. Розуміння того, що кожен рівень вимагає в програмних термінах, є необхідним для розробки систем злиття, що ефективно працюють на практиці.

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

Походження та структура моделі JDL

Підгрупа зі злиття даних Joint Directors of Laboratories опублікувала оригінальну модель у 1985 році як основу для розмірковування над проблемою злиття в оборонних розвідувальних системах. Початкова модель визначала чотири рівні (від 0 до 3). Перегляд 2004 року авторства Blasch, Bosse та Lambert розширив її до шести рівнів (від 0 до 5), додавши Рівень 0 (оцінка субоб'єктів) та Рівень 5 (вдосконалення з боку користувача) для кращого охоплення повного конвеєра обробки.

Рівень 0: Оцінка даних субоб'єктів

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

У програмних термінах Рівень 0 охоплює процедури обробки сигналів та вилучення ознак. Для радара це включає компресію імпульсів, доплерівську обробку, порогування виявлення CFAR (постійного рівня хибних тривог) та вилучення параметрів виявлення: дальності, азимуту, висоти, доплерівської швидкості та оцінки ЕПР.

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

Рівень 1: Уточнення об'єктів

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

Основна задача Рівня 1 має два компоненти: асоціація даних та оцінка стану.

Асоціація даних — це задача вирішення, яке виявлення від якого датчика відповідає якому наявному треку. Стандартні алгоритми включають: найближчий сусід (NN) — простий, але відмовляє при високому засміченні; спільна ймовірнісна асоціація даних (JPDA) — обчислює ймовірності асоціації спільно для всіх виявлень і треків; відстеження з множинними гіпотезами (MHT) — підтримує кілька гіпотез щодо відповідності виявлень трекам, відсікаючи малоймовірні з часом.

Оцінка стану — оновлення оцінки стану треку при новому асоційованому виявленні. Стандартний алгоритм — фільтр Калмана та його нелінійні розширення. Для нелінійного руху цілі (наприклад, скоординованих поворотів) використовується Розширений фільтр Калмана (EKF) або Фільтр Калмана без запаху (UKF).

Рівень 2: Уточнення ситуації

Рівень 2 розміщує окремі треки в оперативний контекст. Його вхід — картина треків Рівня 1. Його вихід — картина ситуації: треки з приписаними ідентичностями, класифікованими намірами та зрозумілими зв'язками.

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

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

Рівень 3: Уточнення впливу/загроз

Рівень 3 проєктує поточну ситуацію вперед у часі для оцінки загроз. Його вхід — картина ситуації Рівня 2. Його вихід — оцінки загроз: прогнози майбутніх дій противника та їх потенційного впливу на дружні операції.

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

Рівні 4 і 5: Вдосконалення процесу і користувача

Рівень 4 (Вдосконалення процесу) — це метарівень, який контролює сам процес злиття та адаптує збір для покращення його якості. В ПЗ це реалізується як модуль управління датчиками, що отримує метрики якості злиття та виводить запити на завдання датчикам.

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

Ключовий висновок: На практиці більшість операційних систем злиття повністю реалізують рівні 0–2, частково — рівень 3, і реалізують рівні 4–5 лише у дослідницьких або високорівневих програмах. Розробка системи відповідно до повної моделі JDL є розумною архітектурною метою, але команди повинні чітко визначати, які рівні входять до обсягу кожного приросту програми.