Standaryzacja modeli danych C2: dlaczego schematy własne fragmentują świadomość przestrzeni walki

Dwie sojusznicze jednostki zajmują sąsiednie sektory. Oba posiadają nowoczesne systemy C2 zasilające wspólny obraz operacyjny. Jednak wspólny obraz jest niepełny: systemy jednego państwa raportują identyfikatory jednostek jako oznaczniki NATO STANAG 2019, podczas gdy drugie używa krajowych kodów alfanumerycznych. Jedno koduje lokalizację w MGRS, drugie w dziesiętnych stopniach WGS-84. Jedno oznacza zdarzenia czasowo w UTC z rozdzielczością milisekundową, drugie używa czasu lokalnego z rozdzielczością sekundową. Skutkiem jest to, że ślad utworzony w jednym systemie albo nie pojawia się w drugim, albo pojawia się jako duplikat z kolidującą pozycją. To nie jest problem sieciowy. To jest problem schematu, który powtarza się we wszystkich operacjach koalicyjnych, gdzie systemy C2 były pozyskiwane niezależnie. Niniejszy artykuł analizuje techniczne źródła tej fragmentacji i podejścia standaryzacyjne, które ją rozwiązują -- zaczynając od fundamentalnych decyzji dotyczących modelu danych, które determinują, czy system C2 może w ogóle osiągnąć interoperacyjność.

Koszt własnych modeli danych w operacjach koalicyjnych

Każde większe ćwiczenie koalicyjne od lat 90. produkowało raporty pokontrolne wskazujące na awarie wymiany danych bezpośrednio związane z niezgodnością schematów. Wzorzec jest spójny: każde państwo pozyskuje system C2 zgodnie z własnymi wymaganiami, dostawca implementuje własny model danych zoptymalizowany pod kątem doktryny i struktury sił tego państwa, a system działa sprawnie podczas krajowych ćwiczeń. Problemy ujawniają się w momencie, gdy dwa lub więcej takich systemów musi dzielić wspólny obraz operacyjny. Pola reprezentujące logicznie identyczne koncepcje -- status operacyjny jednostki, raportowana pozycja śladu, przypisany priorytet zadania -- są kodowane odmiennie w każdym schemacie własnym. Konwersja między nimi wymaga warstwy translacji, której żaden dostawca pierwotnie nie planował i którą trzeba przeprojektowywać dla każdej nowej pary systemów.

Koszty operacyjne kumulują się na dwa sposoby. Pierwszym jest opóźnienie: każdy krok translacji, który nie może być zautomatyzowany, dodaje czas do pętli od sensora do niszczyciela. Ślad propagujący się przez 45 sekund od węzła sensorowego do wyświetlacza sojuszniczego dowódcy jest taktycznie bezużyteczny w dynamicznym starciu. Drugim kosztem jest utrata wierności: pola niemające odpowiednika w schemacie docelowym są po cichu pomijane. Status operacyjny zakodowany jako "TACON" (taktyczna kontrola) w jednym systemie staje się pustym polem lub ogólną flagą "aktywny" w innym, pozbawiając odbierającego dowódcę informacji obecnych w źródle. W skali dużego ćwiczenia lub operacji ta skumulowana utrata danych degraduje świadomość sytuacyjną w sposób trudny do zmierzenia, lecz operacyjnie istotny.

Koszty ekonomiczne są również znaczące. Szacunki z wielonarodowych programów integracji C2 konsekwentnie wykazują, że dedykowane dwustronne warstwy translacji -- budowane raz na parę systemów, utrzymywane oddzielnie dla każdej aktualizacji wersji -- pochłaniają 20-40% całkowitego budżetu integracyjnego koalicyjnego programu C2. Te zasoby są wydawane na pracę, która nie wytwarza żadnych nowych możliwości: jedynie kompensuje brak wspólnego schematu.

Ustalone standardy: JC3IEDM, APP-6, MIP Data Model -- zakres i luki

Multilateral Interoperability Programme (MIP) opracował najszerzej przyjęte standardy modeli danych dla koalicyjnego C2. JC3IEDM (Joint Command, Control and Consultation Information Exchange Data Model), ratyfikowany jako standard ISO, definiuje znormalizowany schemat relacyjny obejmujący jednostki, sprzęt, obiekty, działania, plany i ich relacje operacyjne. Jego struktura encja-relacja została zaprojektowana do wymiany baza-baza, gdzie oba systemy utrzymują kopie tych samych tabel relacyjnych i synchronizują zmiany przez zdefiniowany protokół replikacji. JC3IEDM osiągnął znaczące przyjęcie w połowie lat 2000. jako kanoniczny schemat integracji koalicyjnego C2, szczególnie w programach obejmujących wiele europejskich sił lądowych.

APP-6 (NATO Military Symbols for Land Based Systems) rozwiązuje węższy problem: jak konsekwentnie reprezentować ikony jednostek wojskowych i ich atrybuty na wyświetlaczach sojuszniczych. APP-6D definiuje strukturę kodu identyfikacji symbolu (SIDC), hierarchię typów jednostek od szczebla związku taktycznego po typ sprzętu oraz standardowe modyfikatory statusu, wielkości i przynależności. Choć APP-6 jest ściśle standardem symboliki, a nie pełnym modelem danych, definiuje zbiory wyliczeniowe, z których model danych C2 musi czerpać przy reprezentowaniu typów jednostek bez niejednoznaczności. System C2 używający SIDC z APP-6 jako kanonicznego identyfikatora typu jednostki może wymieniać symbolikę jednostek z każdym sojuszniczym systemem czyniącym to samo, bez żadnej translacji wyliczeniowej.

MIP Data Model (MIM), następca JC3IEDM, przyjmuje strukturę modelu obiektowego opartą na UML, która bardziej bezpośrednio odwzorowuje się na wzorcach wymiany zorientowanych na komunikaty nowoczesnych architektur C2. Zamiast wymagać wspólnego dostępu do bazy danych, MIM definiuje wiązanie XML umożliwiające zgodnym systemom wymianę danych przez standardowe transporty. MIM wprowadza również formalne wersjonowanie i modularną strukturę grup konceptualnych upraszczającą proces rozszerzeń. MIM zachowuje jednak znaczną złożoność: pełny model informacyjny zawiera kilkaset klas konceptualnych, a implementacja zgodnego interfejsu MIM nadal wymaga miesięcy pracy inżynierskiej przy integracji. Rozszerzenia krajowe -- które każde wdrażające państwo dodało -- oznaczają, że dwa systemy zgodne z MIM mogą nadal nie wymieniać danych poprawnie, jeśli jedno używa rozszerzenia krajowego, którego drugie nie zaimplementowało.

Jak rozbieżność schematów tworzy opóźnienie w pętlach od sensora do niszczyciela

Ścieżka od wykrycia przez sensor do użytecznego śladu na wyświetlaczu sojuszniczym przechodzi przez kilka kroków transformacji danych, a rozbieżność schematów może wnosić opóźnienia na każdym z nich. Rozważmy radar naziemny, który wykrywa ślad pojazdu i raportuje go do krajowego systemu C2. System C2 przechowuje ślad we własnym schemacie, a następnie próbuje udostępnić go sojuszniczemu systemowi przez łącze koalicyjne. Jeśli łącze koalicyjne używa zdefiniowanego formatu wymiany (takiego jak komunikat J-series Link 16 lub instancja XML MIM), krajowy system C2 musi najpierw przetłumaczyć swój wewnętrzny schemat na format wymiany. Jeśli ta translacja nie jest zaimplementowana poprawnie -- lub jeśli schemat krajowy zawiera pola niemające odpowiednika w formacie wymiany -- krok translacji albo kończy się po cichu niepowodzeniem, albo traci dane.

Po stronie odbierającej sojuszniczy system C2 musi przetłumaczyć przychodzący format wymiany na własny schemat wewnętrzny. Jeśli system odbierający używa innej wersji standardu wymiany lub dodał rozszerzenia krajowe, których nadawca nie wypełnia, odebrany ślad może być przechowywany z brakującymi lub domyślnie wartościowanymi polami. Pozycja śladu przychodząca w formacie MGRS, lecz przechowywana wewnętrznie w UTM, zostanie przeliczona poprawnie tylko wtedy, gdy logika konwersji obsługuje wszystkie graniczne przypadki stref UTM -- wymóg brzmiący banalnie, lecz powodujący rzeczywiste błędy we wdrożonych systemach w pobliżu granic stref. Każdy z tych kroków translacji pochłania czas: dobrze zaimplementowana translacja automatyczna dodaje milisekundy; źle zaimplementowana, wymagająca kolejkowania niepewnych rekordów do weryfikacji przez operatora, może dodawać minuty.

Skumulowany efekt jest taki, że indukowane przez schemat opóźnienie w wieloskokowym koalicyjnym łańcuchu C2 -- od sensora do systemu krajowego, z systemu krajowego do bramy koalicyjnej, z bramy koalicyjnej do sojuszniczego systemu krajowego, z systemu sojuszniczego do wyświetlacza -- może łatwo osiągnąć 30-90 sekund dla śladu, który powinien propagować się w czasie poniżej dwóch sekund. Dla celów wrażliwych czasowo i zagrożeń krytycznych pod względem czasu to różnica między użytecznym śladem a zapisem historycznym. Jak omówiono w kontekście uzasadnienia projektowego formatu Cursor on Target, najskuteczniejsze formaty wymiany to te, które minimalizują odległość translacji między schematem źródłowym a formatem przewodowym.

Ontologie OWL/RDF jako ścieżka ku interoperacyjności semantycznej

Relacyjne i oparte na UML modele danych takie jak JC3IEDM i MIM definiują strukturę -- jakie pola istnieją i jak się odnoszą -- lecz nie definiują znaczenia w formie, którą maszyny mogą przetwarzać. Dwa pola o różnych nazwach w dwóch schematach mogą reprezentować tę samą koncepcję; dwa pola o identycznych nazwach mogą reprezentować subtelnie różne koncepcje. Wykrywanie i rozwiązywanie tych semantycznych równoważności i distinkcji wymaga albo ekspertyzy ludzkiej, albo formalnej warstwy semantycznej czyniącej relacje czytelnymi maszynowo. OWL (Web Ontology Language) i RDF (Resource Description Framework) dostarczają tej warstwy.

Ontologia OWL dla wojskowych danych C2 może reprezentować taksonomię encji JC3IEDM jako hierarchię klas z formalnymi relacjami subsumpcji. Może twierdzić, że "ARMD-REGT" (pułk pancerny w taksonomii typów jednostek JC3IEDM) jest podklasą "LAND-UNIT", która jest podklasą "MILITARY-UNIT". System odbierający, który zna tylko koncepcję "MILITARY-UNIT", może nadal poprawnie obsłużyć przychodzący rekord o typie "ARMD-REGT", ponieważ aksjomaty subsumpcji ontologii mówią systemowi wnioskującemu, że każdy "ARMD-REGT" jest "MILITARY-UNIT". Ta zdolność wnioskowania jest szczególnie cenna przy obsłudze krajowych rozszerzeń do standardowych taksonomii: typ rozszerzenia zdefiniowany przez system C2 jednego państwa może być odwzorowany na najbliższą standardową klasę nadrzędną we współdzielonej ontologii, umożliwiając systemom odbierającym, które nie znają rozszerzenia, obsłużenie go z wdziękiem zamiast odrzucania rekordu.

Praktyczne przyjęcie OWL/RDF w operacyjnych systemach C2 było ograniczone obawami dotyczącymi wydajności i narzędzi. Wnioskowanie OWL nad dużymi operacyjnymi zbiorami danych jest kosztowne obliczeniowo, a opóźnienie wnioskowania jest niekompatybilne z przetwarzaniem śladów w czasie rzeczywistym. Bardziej praktycznym podejściem jest używanie ontologii OWL na etapie projektowania do weryfikacji i generowania reguł translacji kompilowanych następnie do wydajnego kodu czasu wykonania -- wykorzystując formalną semantykę ontologii do wychwytywania błędów odwzorowania przed wdrożeniem, a nie podczas operacji. Kilka programów badawczych NATO wykazało to podejście, produkując zestawy reguł translacji wywiedzionych z ontologii, które przewyższają ręcznie pisane odwzorowania zarówno pod względem kompletności, jak i poprawności.

Wzorce API gateway dla translacji schematów w czasie wykonania

Niezależnie od wybranego kanonicznego modelu danych, praktycznym wyzwaniem jest przeprowadzanie translacji schematów z prędkością, jakiej wymaga środowisko operacyjne. Wzorzec API gateway -- usługa translacji siedząca między każdym systemem źródłowym a magistralą kanonicznego schematu -- dostarcza rozwiązania najbardziej sprawdzonego operacyjnie. Integracja każdego systemu źródłowego jest ujęta w dedykowanym adapterze tłumaczącym w czasie rzeczywistym z natywnego schematu tego systemu na schemat kanoniczny. Adapter jest jedynym komponentem, który musi znać własny format systemu źródłowego; wszystkie pozostałe komponenty w architekturze koalicyjnego C2 posługują się wyłącznie schematem kanonicznym.

Rejestr schematów jest krytycznym komponentem infrastruktury czyniącym wzorzec API gateway możliwym do utrzymania w skali. Każda wersja schematu -- zarówno systemów źródłowych, jak i modelu kanonicznego -- jest rejestrowana z identyfikatorem wersji. Każda reguła translacji jest oznaczona konkretną parą (wersja-źródłowa, wersja-docelowa), do której się odnosi. Gdy system źródłowy aktualizuje schemat, tylko adapter dla tego systemu wymaga aktualizacji; schemat kanoniczny i wszystkie pozostałe adaptery pozostają niezmienione. Rejestr schematów służy również jako ścieżka audytu: każdy rekord przechodzący przez warstwę translacji niesie metadane proweniencji -- identyfikator systemu źródłowego, wersja schematu źródłowego, wersja reguły translacji, znacznik czasu -- umożliwiające retrospektywne badanie wszelkich problemów z jakością danych.

W środowiskach koalicyjnych, gdzie kanoniczny schemat sam podlega krajowym rozszerzeniom, API gateway musi obsługiwać również kierunek odwrotny: translację ze schematu kanonicznego z powrotem na własny schemat krajowy systemu do konsumpcji. To dwukierunkowe wymaganie translacji podwaja zestaw reguł translacji i wprowadza dodatkowe wyzwanie reprezentowania pól kanonicznych niemających odpowiednika w docelowym schemacie krajowym. Standardowym podejściem jest kodowanie takich pól w ustrukturyzowanym blob rozszerzenia dołączonym do rekordu docelowego, zachowując dane na potrzeby ewentualnej przyszłej aktualizacji systemu docelowego, jednocześnie zapewniając, że bieżący system może wciąż wczytać rekord bez błędów. Wybór architektury magistrali komunikatów bezpośrednio wpływa na to, jak czysto te bloby rozszerzeń mogą być dołączane i przekazywane dalej.

Zarządzanie: kto jest właścicielem kanonicznego modelu danych w koalicji

Techniczne rozwiązania dla interoperacyjności schematów są konieczne, lecz niewystarczające. Każdy skuteczny program standaryzacji koalicyjnych modeli danych wymagał struktury zarządzania definiującej: kto może proponować zmiany w kanonicznym schemacie, kto je zatwierdza, jak rejestruje się i udostępnia rozszerzenia krajowe oraz jaki jest proces rozwiązywania konfliktów między wymaganiami krajowymi. Bez zarządzania kanoniczny schemat dryfuje: każdy krajowy zespół integracyjny dokonuje lokalnych modyfikacji uwzględniających wymagania własnego systemu, modyfikacje nigdy nie są propagowane z powrotem do wspólnego standardu, a w ciągu dwóch lat "kanoniczny" schemat ma tyle wariantów, ile państw go implementuje.

Model zarządzania MIP oferuje użyteczny punkt odniesienia. MIP działa przez radę programową z krajowymi przedstawicielami, radę kontroli konfiguracji przeglądającą i zatwierdzającą zmiany schematów oraz opublikowany cykl wydań z określonymi zobowiązaniami dotyczącymi wstecznej kompatybilności. Zmiany w kanonicznym schemacie wymagają consensusu wielonarodowego; rozszerzenia krajowe są dozwolone, lecz muszą być rejestrowane we wspólnym rejestrze rozszerzeń i przeglądane pod kątem potencjalnego włączenia do schematu kanonicznego przy każdym cyklu wydań. Ten model zarządzania podtrzymał JC3IEDM i MIM przez ponad dwie dekady operacyjnego użytkowania w dziesiątkach wdrażających państw, co stanowi dowód, że model jest wykonalny nawet wobec wyzwań koordynacyjnych programu wielonarodowego.

Dla mniejszych koalicji lub programów dwustronnych, które nie mogą podtrzymać struktury zarządzania w skali MIP, lżejszą alternatywą jest wyznaczona rola opiekuna modelu danych w jednej z uczestniczących organizacji, z formalnym procesem wniosków o zmianę wymagającym akceptacji od wszystkich właścicieli systemów, których zmiana dotyczy, przed wdrożeniem jakiejkolwiek zmiany schematu. Kluczowym wymaganiem jest, aby proces zarządzania zmianami był udokumentowany i konsekwentnie przestrzegany -- nieudokumentowana zmiana w kanonicznym schemacie psująca bez ostrzeżenia adapter translacji jednego państwa to dokładnie ten rodzaj zdarzenia, który podważa zaufanie do programu standaryzacji i skłania państwa do powrotu do własnych rozwiązań dwustronnych.

Migracja przyrostowa: opakowywanie systemów dziedzicznych bez ich przepisywania

Większość wysiłków standaryzacji modeli danych C2 napotyka to samo ograniczenie: dziedziczne systemy wymagające interoperacyjności nie mogą być przepisane. Zostały pozyskane w ramach długoterminowych kontraktów, niosą lata operacyjnych dostosowań, a harmonogramy ich wymiany liczone są w dekadach. Każde podejście standaryzacyjne wymagające pełnego przepisania systemu nie zostanie wdrożone. Jedyną realną ścieżką jest migracja przyrostowa przez warstwy adapterów -- wzorzec strangler-fig zastosowany do integracji wojskowego C2.

Podejście strangler-fig działa następująco. Adapter translacji jest wdrażany równolegle z dziedzicznym systemem. Adapter udostępnia punkt końcowy API zgodny ze standardami -- posługujący się schematem kanonicznym -- dla wszystkich zewnętrznych odbiorców. Wewnętrznie adapter czyta z bazy danych lub magistrali komunikatów dziedzicznego systemu, stosuje reguły translacji na poziomie pola udokumentowane podczas audytu schematu i publikuje zgodne komunikaty o schemacie kanonicznym do wspólnego brokera. Systemy zewnętrzne integrują się z kanonicznym interfejsem adaptera, nigdy bezpośrednio ze schematem dziedzicznym. Dziedziczny system kontynuuje działanie bez zmian. Z biegiem czasu, gdy poszczególne podsystemy funkcjonalne w dziedzicznej platformie osiągają koniec życia, mogą być zastępowane nowymi implementacjami posługującymi się kanonicznym schematem natywnie, a odpowiadające reguły translacji w adapterze są wycofywane. Ostatecznie adapter może być całkowicie wycofany, lecz przez cały ten czas zewnętrzne interfejsy pozostały stabilne.

Praktyczne wyzwania tego podejścia koncentrują się na kroku audytu schematu. Dziedziczne systemy C2 często mają nieudokumentowane pola, niejawne konwencje zakodowane w logice aplikacji zamiast w schemacie oraz problemy z jakością danych, które adapter translacji musi obsługiwać z wdziękiem -- obcięte ciągi znaków, wartości numeryczne poza zakresem, pola null, które nigdy nie powinny być null. Solidny adapter translacji musi zawierać logikę walidacji i oczyszczania wychwytującą te problemy na granicy i albo korygującą je (dla dobrze rozumianych przypadków jak końcowe białe znaki lub nieprawidłowy zapis wielkimi literami), albo rejestrującą je do przeglądu przez człowieka (dla przypadków, gdzie prawidłowa interpretacja jest niejednoznaczna). Budowanie tej logiki walidacji wymaga bezpośredniego dostępu do danych dziedzicznego systemu przez okres operacji w trybie cienia -- uruchamiania adaptera równolegle z istniejącą ścieżką wymiany i porównywania wyjść pole po polu, dopóki wskaźnik zgodności dla operacyjnie krytycznych pól nie będzie wystarczająco wysoki, aby uzasadnić przełączenie.