Стандартизація моделей даних C2: чому пропрієтарні схеми фрагментують ситуаційну обізнаність на полі бою

Два союзних підрозділи займають суміжні сектори. Обидва мають сучасні системи C2, що передають треки до спільної оперативної картини. Проте спільна картина є неповною: системи однієї країни повідомляють ідентифікатори підрозділів у вигляді позначень STANAG 2019, іншої — у вигляді національних буквено-цифрових кодів. Одна кодує місцезнаходження в MGRS, інша — у десяткових градусах WGS-84. Одна позначає події мітками часу в UTC з мілісекундною точністю; інша — за місцевим часом із секундною точністю. В результаті трек, створений в одній системі, або не з'являється в іншій, або з'являється як дублікат із суперечливою позицією. Це не мережева проблема. Це проблема схеми, і вона відтворюється в кожній коаліційній операції, де системи C2 закуповувалися незалежно. Ця стаття розглядає технічні корені такої фрагментації та підходи до стандартизації, що її усувають — починаючи з фундаментальних рішень щодо моделі даних, які визначають, чи може система C2 взагалі забезпечити інтероперабельність.

Вартість пропрієтарних моделей даних у коаліційних операціях

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

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

Економічна вартість також є значною. Оцінки багатонаціональних програм інтеграції C2 стабільно показують, що спеціалізовані двосторонні трансляційні рівні — побудовані один раз для кожної пари систем та окремо підтримувані для кожного оновлення версії — складають 20–40% загального бюджету інтеграції коаліційної програми C2. Ці ресурси витрачаються на роботу, яка не створює нових можливостей: вони лише компенсують відсутність спільної схеми.

Усталені стандарти: JC3IEDM, APP-6, MIP Data Model — охоплення та прогалини

Багатостороння програма інтероперабельності (MIP) розробила найбільш широко прийняті стандарти моделей даних для коаліційних систем C2. JC3IEDM (Joint Command, Control and Consultation Information Exchange Data Model), ратифікований як стандарт ISO, визначає нормалізовану реляційну схему, що охоплює підрозділи, техніку, об'єкти, дії, плани та їхні оперативні зв'язки. Його структура сутність-зв'язок розроблена для обміну між базами даних, де обидві системи зберігають копії однакових реляційних таблиць і синхронізують зміни через визначений протокол реплікації. JC3IEDM досяг значного поширення в середині 2000-х як канонічна схема для інтеграції коаліційних систем C2, зокрема в програмах за участю кількох європейських сухопутних сил.

APP-6 (NATO Military Symbols for Land Based Systems) вирішує вужчу проблему: як узгоджено представляти піктограми військових підрозділів та їхні атрибути на дисплеях союзників. APP-6D визначає структуру коду ідентифікації символу (SIDC), ієрархію типів підрозділів від рівня ешелону до типу техніки, а також стандартні модифікатори стану, розміру та приналежності. Хоча APP-6 є суто стандартом умовних позначень, а не повною моделлю даних, він визначає набори перерахувань, на які повинна спиратися модель даних C2 для однозначного представлення типів підрозділів. Система C2, що використовує SIDC за APP-6 як канонічний ідентифікатор типу підрозділу, може обмінюватися умовними позначеннями з будь-якою союзною системою, що робить те саме, без будь-якої трансляції перерахувань.

MIP Data Model (MIM), наступник JC3IEDM, застосовує структуру об'єктної моделі на основі UML, що більш безпосередньо відповідає шаблонам обміну, орієнтованим на повідомлення, у сучасних архітектурах C2. Замість того щоб вимагати спільного доступу до бази даних, MIM визначає XML-прив'язування, що дозволяє відповідним системам обмінюватися даними через стандартні транспортні протоколи. MIM також запроваджує формальне версіонування та модульну структуру груп концептів, яка спрощує процес розширення. Однак MIM зберігає значну складність: повна інформаційна модель містить кілька сотень класів концептів, а реалізація відповідного інтерфейсу MIM все одно вимагає місяців інтеграційної роботи. Національні розширення — які кожна країна-реалізатор додала — означають, що дві системи, що відповідають MIM, можуть все одно некоректно обмінюватися даними, якщо одна використовує національне розширення, яке інша не реалізувала.

Як розбіжність схем створює затримки в циклах від датчика до стрільця

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

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

Сукупний ефект полягає в тому, що індукована схемою затримка в багатоланковому коаліційному ланцюжку C2 — від датчика до національної системи, від національної системи до коаліційного шлюзу, від коаліційного шлюзу до союзної національної системи, від союзної системи до дисплея — може легко досягати 30–90 секунд для треку, який має поширюватися менш ніж за дві секунди. Для цілей, чутливих до часу, та загроз, критичних за часом, це різниця між корисним треком і архівним записом. Як обговорюється в контексті обґрунтування дизайну формату Cursor on Target, найефективніші формати обміну — це ті, що мінімізують відстань трансляції між вихідною схемою та форматом передачі.

Онтології OWL/RDF як шлях до семантичної інтероперабельності

Реляційні та UML-засновані моделі даних на зразок JC3IEDM і MIM визначають структуру — які поля існують і як вони співвідносяться — але не визначають значення у формі, придатній для машинного логічного виводу. Два поля, названі по-різному в двох схемах, можуть представляти один і той самий концепт; два поля з однаковими назвами можуть представляти тонко відмінні концепти. Виявлення та вирішення цих семантичних еквівалентностей і відмінностей вимагає або людської експертизи, або формального семантичного рівня, що робить зв'язки доступними для машинного читання. OWL (Web Ontology Language) та RDF (Resource Description Framework) забезпечують цей рівень.

OWL-онтологія для військових даних C2 може представляти таксономію сутностей JC3IEDM як ієрархію класів з формальними відношеннями підпорядкування. Вона може стверджувати, що "ARMD-REGT" (бронетанковий полк у таксономії типів підрозділів JC3IEDM) є підкласом "LAND-UNIT", який є підкласом "MILITARY-UNIT". Система-споживач, що знає лише концепт "MILITARY-UNIT", може все одно коректно обробити вхідний запис, типізований як "ARMD-REGT", оскільки аксіоми підпорядкування онтології повідомляють механізму виводу, що кожен "ARMD-REGT" є "MILITARY-UNIT". Ця можливість виводу особливо цінна для обробки національних розширень стандартних таксономій: тип розширення, визначений системою C2 однієї країни, може бути відображений на найближчий стандартний батьківський клас у спільній онтології, дозволяючи системам-споживачам, що не знають розширення, коректно обробляти його, а не відхиляти запис.

Практичне застосування OWL/RDF в оперативних системах C2 обмежувалося проблемами продуктивності та інструментарію. Логічний вивід OWL на великих оперативних наборах даних є обчислювально дорогим, а затримка виводу несумісна з обробкою треків у реальному часі. Більш практичним підходом є використання онтологій OWL на етапі проєктування для перевірки та генерації правил трансляції, які потім компілюються в ефективний виконуваний код — використання формальної семантики онтології для виявлення помилок відображення до розгортання, а не під час операцій. Кілька дослідницьких програм НАТО продемонстрували цей підхід, отримавши набори правил трансляції, похідних від онтологій, що перевершують рукописні відображення як за повнотою, так і за коректністю.

Шаблони API-шлюзу для трансляції схем у реальному часі

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

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

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

Управління: хто є власником канонічної моделі даних у коаліції

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

Модель управління MIP є корисним орієнтиром. MIP функціонує через програмну раду з національними представниками, раду контролю конфігурацій, яка переглядає та затверджує зміни схем, і опублікований цикл випусків із визначеними зобов'язаннями щодо зворотної сумісності. Зміни до основної схеми вимагають консенсусу кількох країн; національні розширення дозволяються, але мають бути зареєстровані в спільному реєстрі розширень та переглянуті на предмет можливого включення до основної схеми в кожному циклі випусків. Ця модель управління підтримувала JC3IEDM і MIM протягом більш ніж двох десятиліть оперативного використання в десятках країн-реалізаторів, що свідчить про її працездатність навіть за умов координаційних труднощів багатонаціональної програми.

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

Поетапна міграція: обгортання застарілих систем без їх переписування

Більшість зусиль зі стандартизації моделей даних C2 стикається з однаковим обмеженням: застарілі системи, які потребують інтероперабельності, не можуть бути переписані. Вони закуплені за довгостроковими контрактами, несуть у собі роки оперативного налаштування, а терміни їх заміни вимірюються десятиліттями. Будь-який підхід до стандартизації, що вимагає повного переписування системи, реалізований не буде. Єдиним життєздатним шляхом є поетапна міграція через рівні адаптерів — шаблон strangler-fig, застосований до інтеграції військових систем C2.

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

Практичні труднощі цього підходу зосереджені на кроці аудиту схеми. Застарілі системи C2 часто мають незадокументовані поля, неявні угоди, закодовані в логіці застосунку, а не в схемі, та проблеми якості даних, які трансляційний адаптер повинен коректно обробляти — обрізані рядки, числові значення поза діапазоном, нульові поля, які ніколи не мають бути нульовими. Надійний трансляційний адаптер повинен включати логіку перевірки та санітизації, що перехоплює ці проблеми на межі і або виправляє їх (для добре розуміних випадків, таких як кінцеві пробіли або неправильний регістр), або реєструє їх для перегляду людиною (для випадків, де коректна інтерпретація є неоднозначною). Побудова цієї логіки перевірки вимагає прямого доступу до даних застарілої системи протягом певного часу роботи в тіньовому режимі — виконання адаптера паралельно з наявним шляхом обміну та порівняння виходів поле за полем до тих пір, доки рівень відповідності для оперативно критичних полів не буде достатньо високим для обґрунтування переходу.