Budowa pipeline'u fuzji obronnej, część 1: źródła, schematy i warstwa adapterów

Pipeline fuzji, który działa niezawodnie pod obciążeniem, nie jest projektowany; jest iterowany. Pierwsza iteracja prawie zawsze zawodzi z tego samego powodu: niewystarczającej dyscypliny w warstwie źródeł i schematów. Adaptery przeciekają koncepcje specyficzne dla źródła w górę strumienia, schemat śladów nie jest wystarczająco stabilny, by wspierać ewolucję, model kanoniczny miesza koncepcje, które powinny pozostać rozdzielone, a sześć miesięcy później zespół przepisuje silnik fuzji, podczas gdy operatorzy nadal używają zepsutego. Ta czteroczęściowa seria pokazuje, jak uniknąć takiego scenariusza. Część 1 obejmuje fundament: katalogowanie źródeł, projektowanie kanonicznego schematu śladów i warstwę adapterów, która utrzymuje czystość wszystkiego pozostałego.

Architektoniczne ramy dla tej serii znajdują się w Kompletnym przewodniku po fuzji danych obronnych. Odpowiednik po stronie C2 — budowa pełnego stosu C2 z fuzją jako jednym z komponentów — to seria równoległa, zaczynająca się od Budowy systemu C2 od zera, część 1. Niniejsza seria koncentruje się wąsko na podsystemie silnik-fuzji-plus-warstwa-danych.

Krok 1: skataloguj źródła, zanim napiszesz kod

Najbardziej dźwigniową aktywnością na początku programu fuzji jest katalog źródeł — dokument opisujący każdy sensor, kanał wywiadu i wejście zewnętrzne, które platforma będzie ingestować. Katalog jest nieciekawy do tworzenia, nieciekawy do czytania i krytyczny, by go zrobić poprawnie. Staje się kontraktem, od którego zależy każdy komponent downstream.

Katalog rejestruje dla każdego źródła:

• Tożsamość źródła — stabilny identyfikator, przyjazna nazwa, organizacja właściciel.
• Format wire — kategoria i wersja ASTERIX, wydanie STANAG 4586, AIS NMEA 0183, wersja schematu CoT XML, wersja NITF itd.
• Transport — UDP multicast, TCP unicast, temat MQTT, webhook HTTP, file drop. Obejmuje adresowanie, uwierzytelnianie, postawę szyfrowania.
• Kadencja — wskaźnik wiadomości przy obciążeniu nominalnym, wskaźnik szczytowy, oczekiwane interwały ciszy.
• Profil latencji — czas obserwacji vs. czas raportu vs. czas ingestu. Niektóre źródła są czasu rzeczywistego; inne mają opóźnienia wsadowe mierzone w godzinach.
• Dokładność i niepewność — co twierdzi specyfikacja, co pokazują dane operacyjne, jak wyglądają tryby awarii.
• Postawa klasyfikacji — na jakim poziomie klasyfikacji działa źródło, jakie kompartmenty mają zastosowanie, jakie reguły dopuszczenia do udostępnienia rządzą danymi.
• Znane tryby awarii — utrata łącza, przestoje po stronie źródła, stopniowa degradacja, możliwości celowej manipulacji.
• Mapowania schematów — jak każde pole źródła mapuje się na kanoniczny schemat śladów (uzupełniane, gdy schemat już istnieje).

Katalog jest artefaktem wersjonowanym, przechowywanym w repozytorium obok kodu źródłowego, recenzowanym przez zespół inżynierski oraz (tam, gdzie to właściwe) przez społeczność operacyjną, której sensory zasilają system. Nowe źródło nie jest „zintegrowane", dopóki nie ma wpisu w katalogu; sama ta dyscyplina zapobiega najczęstszemu wieloletniemu refaktorowi w projektach fuzji.

Szczegółowe omówienie wyzwań integracji źródeł, szczególnie semantyki multi-INT, która ujawnia się w obronie, znajduje się w Wyzwaniach integracji danych obronnych.

Krok 2: zaprojektuj kanoniczny schemat śladów

Ślad jest centralną strukturą danych każdej platformy fuzji. Każdy adapter produkuje ślady; każda decyzja fuzji aktualizuje ślady; każdy konsument czyta ślady. Schemat jest kontraktem, z którym platforma żyje przez całe życie operacyjne, typowo 15–20 lat. Poświęć sprint, by go dobrze zrobić; poświęć tydzień, by go udokumentować.

Minimalny żywotny schemat obejmuje:

Identyfikator śladu (Track ID). Globalnie unikalny, stabilny przez całe życie śladu, nigdy nie używany ponownie. UUIDv7 lub typowany prefiks-plus-UUID jest bezpiecznym ustawieniem domyślnym. ID jest nieprzezroczyste — nie koduje źródła, tożsamości ani żadnego innego atrybutu, który może się zmienić.

Tożsamość. Strukturyzowany typ z trzema podpolami: taksonomia typu (jednostka pływająca, samolot, pojazd, osoba, oddział, sygnał, niesklasyfikowane-inne), podtyp (drobniejsza klasyfikacja w domenie) i atrybuty identyfikacyjne (numer kadłuba, numer ogonowy, callsign, MMSI, ID transpondera). Tożsamość jest aktualizowana przez fuzję w miarę gromadzenia dowodów; ID nie.

Pozycja i niepewność. Szerokość, długość, wysokość w WGS84 domyślnie. Niepewność reprezentowana jako macierz kowariancji (preferowana dla fuzji kinematycznej) lub oś większa/mniejsza z azymutem (akceptowalne dla prostszych przypadków). Nigdy pojedyncza liczba niepewności — traci informację geometryczną, której fuzja potrzebuje.

Stan kinematyczny. Wektor prędkości, prędkość zakrętu, wyprowadzony kurs/prędkość do wyświetlenia. Otagowane czasem chwili estymacji.

Zbiór źródeł. Które adaptery wniosły obserwacje do tego śladu, z klasyfikacją per-źródło, dopuszczeniem do udostępnienia i pewnością. Zbiór źródeł jest fundamentem propagacji klasyfikacji i audytu. Szczegółowe omówienie w Wojskowej fuzji danych wyjaśnionej.

Trzy znaczniki czasu. Czas obserwacji (kiedy sensor zobaczył obiekt), czas raportu (kiedy wiadomość opuściła sensor), czas ingestu (kiedy platforma ją otrzymała). Mieszanie tych trzech jest najczęstszym źródłem błędów w inżynierii fuzji. Operatorzy potrzebują czasu obserwacji; analityka odtwarzania potrzebuje czasu ingestu; różnica między nimi ujawnia latencję sensora do monitorowania.

Stan cyklu życia. Tymczasowy, potwierdzony, dojrzały, zanikający, utracony. Szczegóły maszyny stanów pojawiają się w Części 2.

Koperta klasyfikacji. Efektywna klasyfikacja obliczona ze zbioru źródeł. Tagi dopuszczenia do udostępnienia obliczone z przecięcia dopuszczeń źródeł. Oznaczenia kompartmentów, gdzie ma to zastosowanie.

Pewność i niepewność. Pewność na poziomie śladu jako pojedynczy skalibrowany wynik. Niepewność per-atrybut, gdy materialnie się różni — na przykład ślad może mieć wysoką pewność pozycji, ale tymczasową tożsamość.

Krok 3: zobowiąż się do addytywnej ewolucji schematu

Schemat będzie ewoluował. Pojawi się potrzeba nowych atrybutów; ujawnią się rzadkie przypadki, których oryginalny projekt nie przewidywał. Dyscypliną, która utrzymuje platformę operacyjną przez tę ewolucję, jest wersjonowanie tylko addytywne.

Reguły:

• Nowe pola są opcjonalne. Istniejący konsumenci ignorują je, dopóki nie zostaną zaktualizowani. Producenci wypełniają je, gdy istotne dane są dostępne.
• Istniejące pola nigdy nie zmieniają semantyki. Pole, które dziś znaczy „prędkość w m/s", musi znaczyć „prędkość w m/s" na zawsze. Zmiana znaczenia wymaga nowego pola, a nie zmiany w miejscu.
• Usunięcia to deprecjacje. Pole oznaczone jako deprecated nadal jest w schemacie; nowi producenci przestają je zapisywać; nowi konsumenci przestają je czytać; stare dane nadal działają w nieskończoność.
• Zmiany łamiące to skoki wersji major. Zdarzają się — rzadko. Gdy się zdarzą, migracja jest udokumentowana, przetestowana i skoordynowana między wszystkimi konsumentami. Zmiana łamiąca powinna wystąpić co najwyżej raz w całym życiu platformy, a nie raz na release.

Opakuj schemat w generowaną z kodu bibliotekę kliencką współdzieloną przez każdy język konsumencki. Schema-as-code zapobiega powolnej dywergencji, która w innym wypadku produkuje „platformę fuzji v3.4 w usłudze A, v3.6 w usłudze B, v4.0 w usłudze C" — operacyjny koszmar, na który każdy program fuzji natrafi bez tej dyscypliny.

Krok 4: zbuduj warstwę adapterów ze ścisłą izolacją

Warstwa adapterów tłumaczy natywny format każdego źródła na kanoniczny schemat śladów. Reguła architektoniczna jest brutalna i warta zapamiętania: żadna koncepcja specyficzna dla sensora nie przecieka poza adapter. Jeśli kod twojego silnika fuzji odwołuje się do kategorii ASTERIX, masz architekturę przeciekającą. Jeśli twój magazyn śladów ma kolumnę dla typów wiadomości AIS, masz architekturę przeciekającą. Reguła jest strukturalna — złam ją raz, a koszt narasta przez lata.

Struktura dobrze zaprojektowanego adaptera, w czterech warstwach:

Transport. Łącznik do źródła. Socket UDP, listener TCP, subskrypcja MQTT, webhook HTTP, file watcher. Odporny na awarie po stronie źródła: automatyczne ponowne łączenie z backoffem, księgowanie odrzuconych wiadomości, telemetria eksportowana do stosu monitoringu platformy.

Parser. Tłumaczy format wire na silnie typowaną strukturę w-procesową. Waliduje wobec specyfikacji formatu. Odrzuca źle uformowane wejście głośno, ze strukturyzowanym logowaniem, które ujawnia malformację, identyfikator źródła i znacznik czasu. Ciche odrzucanie złego wejścia jest złym domyślnym ustawieniem — ukrywa problemy operacyjne, które powinny być ujawnione.

Normalizator. Mapuje pola specyficzne dla źródła na pola kanonicznego schematu. Konwersja układu współrzędnych (typowo do WGS84). Normalizacja znaczników czasu do UTC z dyscypliną trzech znaczników. Normalizacja pól tożsamości pomiędzy różnymi sposobami, w jakie ten sam numer kadłuba czy callsign może być sformatowany w różnych źródłach.

Emiter. Publikuje kanoniczną aktualizację śladu na szynę komunikatów platformy, otagowaną identyfikatorem źródła, klasyfikacją źródła, dopuszczeniem do udostępnienia i świeżym znacznikiem czasu ingestu. Emiter jest jedynym komponentem w adapterze, który wie o platformie; wszystko upstream od niego to kod specyficzny dla źródła, izolowany.

Każdy adapter działa jako odrębna usługa lub proces. Współdzielą generowaną z kodu bibliotekę kliencką dla kanonicznego schematu, ale żadne inne ścieżki kodu. Dodanie nowego źródła oznacza napisanie nowego adaptera; nie dotyka żadnego innego komponentu. Szczegółowe wzorce integracyjne dla najczęstszych źródeł obronnych znajdują się w Integracji AIS i ADS-B w obraz wojskowy, a strona CoT w Cursor on Target (CoT).

Krok 5: podłącz adaptery do trwałej szyny komunikatów

Adaptery publikują do trwałego, uporządkowanego, partycjonowanego logu. Usługi fuzji konsumują z niego. Tak samo audyt, historyczne odtwarzanie i analityka downstream. Szyna jest rdzeniem kręgowym platformy fuzji.

Wzorzec, który skaluje się: Kafka lub NATS JetStream jako trwały log zdarzeń; temat-na-typ-źródła po stronie wejścia; temat-na-typ-wyjścia po stronie fuzji. Adaptery publikują do raw.<source-type>; silnik fuzji konsumuje je i publikuje do tracks.updates, tracks.lifecycle, tracks.classification. Konsumenci subskrybują te tematy, których potrzebują.

Szczegółowe kompromisy między Kafką a NATS, dyscyplina modelowania tematów i kwestie operacyjne znajdują się w Kolejkach komunikatów dla pipeline'ów danych obronnych.

Reguła architektoniczna warta wydobycia: nie wywołuj HTTP między komponentami fuzji. Synchroniczne sprzężenie request-response między adapterami, usługami fuzji i konsumentami czyni pipeline kruchym. Skok obciążenia sensora, który zatrzymuje jednego konsumenta, nie może zatrzymać strony producenta. Szyna z obsługą backpressure jest rozwiązaniem strukturalnym; HTTP między komponentami fuzji to powtarzające się źródło awarii.

Krok 6: przetestuj katalog źródeł wobec rzeczywistości

Katalog źródeł jest hipotezą, dopóki nie zostanie przetestowany. Dyscypliny, które go walidują, zanim pipeline wejdzie do operacji:

Odtwarzanie nagranych danych. Dla każdego źródła przechwyć dni lub tygodnie rzeczywistego ruchu w formacie wire do pliku. Odtwórz plik wobec adaptera w tempie oryginalnym i w tempie przyspieszonym. Adapter, który obsługuje rzeczywiste dane przy 10× prędkości, to adapter, który obsługuje operacyjne skoki sensorów; adapter, który obsługuje tylko syntetyczne dane z katalogu, nie jest jeszcze gotowy.

Testowanie wejść adwersarialnych. Wstrzykuj zniekształcone wiadomości, sfałszowane AIS, ploty radarowe naruszające fizykę (ślady naziemne Mach 5), CoT XML z naruszeniami schematu. Adapter musi odrzucać je głośno, nie zawieszać się, nie cicho propagować. Dyscyplina ta przenosi się na sam silnik fuzji, omówiony w Wojskowej fuzji danych wyjaśnionej.

Testy schematu round-trip. Każdy adapter musi być w stanie wykonać round-trip swojego natywnego wejścia przez kanoniczny schemat i z powrotem, zachowując pola istotne operacyjnie. Stratny adapter to porażka projektowa, która ujawnia się przy testach zgodności miesiące później.

Audyt katalogu wobec rzeczywistych danych produkcyjnych. Gdy pipeline już działa w pilotażowym wdrożeniu, zaudytuj katalog źródeł wobec rzeczywistych danych ingestu. Źródła, które produkują atrybuty, których katalog nie przewidywał, latencje przekraczające oczekiwania katalogu lub tryby awarii, których katalog nie udokumentował — to wnioski, które aktualizują katalog, adapter lub oba.

Co dalej

Część 1 omówiła fundament. Źródła skatalogowane, kanoniczny schemat śladów zaprojektowany z addytywną ewolucją, adaptery zbudowane ze ścisłą izolacją, szyna komunikatów podłączona oraz dyscypliny testowe, które walidują tę warstwę. Pipeline teraz ingestuje dane źródłowe i produkuje kanoniczne obserwacje śladów na szynie — ale te obserwacje nie są jeszcze skorelowane w ślady.

Część 2: korelacja śladów i zarządzanie cyklem życia bierze kanoniczny strumień obserwacji i buduje serce silnika fuzji. Bramkowanie oparte na regułach, probabilistyczna asocjacja danych (JPDA, MHT), maszyna stanów cyklu życia i magazyn śladów jako event-sourced read model.