Нормалізація даних сенсорів: побудова канонічної оборонної моделі даних

Двигун злиття не кращий за дані, що надходять до нього, а дані, що до нього надходять, майже ніколи не є чистими. Радар повідомляє дальність у метрах, а пеленг — у тисячних; приймач AIS повідомляє позицію в десяткових градусах WGS84, а швидкість — у вузлах; знімальний продукт несе мітку часу отримання за місцевим часом; перехоплення SIGINT не має геолокації взагалі. Перш ніж може виконуватися будь-яка кореляція, відстеження чи аналітика, кожен із цих різнорідних вихідних даних має бути переформатований в єдине, узгоджене внутрішнє представлення. Це переформатування і є нормалізацією даних сенсорів, а єдине представлення, до якого вона прагне, — канонічна модель даних. У цій статті розглядається, як спроектувати канонічну модель, побудувати адаптери для кожного джерела, що відображають до неї, нормалізувати одиниці, координати і час, зберігати походження у кожному записі та розвивати схему протягом років, не ламаючи споживачів, що від неї залежать.

Навіщо потрібна канонічна модель даних

Наївний підхід до багатосенсорної системи полягає в тому, щоб дозволити кожному споживачу безпосередньо розуміти кожен формат джерела. Двигун злиття розбирає повідомлення радара, потім повідомлення AIS, потім виявлення знімальних продуктів тощо. Це працює для двох або трьох джерел і руйнується під вагою четвертого. Кожен новий тип сенсора змушує змінювати код злиття, рівень зберігання, рендерер COP і кожен аналітичний модуль, що торкається даних. Зв'язок квадратичний: N джерел помножити на M споживачів.

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

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

Анатомія нормалізованого спостереження

Добре спроектоване канонічне спостереження має п'ять груп полів, кожна з чіткою метою.

Ідентичність і тип. Глобально унікальний ідентифікатор спостереження, код типу сутності, взятий з контрольованої таксономії (наземний транспортний засіб, надводне судно, літальний апарат, випромінювач, піхотинець), і будь-яка ідентичність, підтверджена джерелом, наприклад номер треку, MMSI або позивний. Таксономія типів має бути спільною для всіх джерел, щоб судно, про яке повідомляє AIS, і судно, виявлене радаром, відображалися до одного канонічного типу.

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

Час. Час події (коли відбулося спостереження), на відміну від часу прийому (коли конвеєр його отримав). Час події є основою для всієї кореляції; час прийому — для діагностики та вимірювання затримок. Кожна мітка часу несе межу невизначеності.

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

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

Адаптери: де живе специфічна для джерела складність

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

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

Маппінг схем на практиці

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

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

Одиниці, координати і час

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

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

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

Час. Конвертуйте кожну мітку часу до єдиної авторитетної бази — GPS-синхронізований UTC є стандартом — і зберігайте її як час події, а не час прибуття. Застарілі сенсори з вільно працюючими або локальними годинниками вимагають таблиць корекції зміщення на джерело, і кожна мітка часу має нести явну межу невизначеності. Спостереження, невизначеність мітки часу яких перевищує налаштований поріг, слід позначати або відхиляти перед тим, як вони досягнуть корелятора, оскільки хибно позначене за часом спостереження пов'язується з неправильним об'єктом і пошкоджує трек, до якого приєднується.

Походження: забезпечення підзвітності злитого результату

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

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

Розвиток схеми без порушення роботи споживачів

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

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

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

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