Część 1 wybrała zakres, ustaliła czterowarstwową architekturę i zaprojektowała kanoniczny schemat śladu. Część 2 buduje silnik, który zamienia raporty sensorów w wiarygodne ślady: adaptery wprowadzające źródła, algorytmy korelacji decydujące, które raporty odnoszą się do tego samego fizycznego obiektu, zarządzanie cyklem życia informujące COP, że ślad stał się nieaktualny, oraz magazyn śladów stanowiący kotwicę całości. Pod koniec Części 2 platforma produkuje operacyjnie użyteczne ślady; po prostu nie ma jeszcze gdzie ich wyświetlić.

Konceptualnym punktem odniesienia dla wszystkiego w Części 2 jest Kompletny przewodnik po fuzji danych obronnych, który omawia tę dyscyplinę. Tutaj podejmujemy konkretne decyzje dla bieżącej przykładowej platformy.

Krok 1: Wzorzec adaptera, rygorystycznie

Każdy sensor produkuje dane we własnym formacie. Radary mówią ASTERIX; UAV mówią STANAG 4586; odbiorniki AIS emitują NMEA 0183; klienci ATAK mówią CoT; cywilne źródła ADS-B emitują inny protokół binarny; ręcznie raportowane obserwacje przychodzą przez formularz webowy. Zadaniem warstwy adapterów jest przetłumaczenie wszystkich tych źródeł na kanoniczny schemat śladu zdefiniowany w Części 1.

Zasada 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 nieszczelną architekturę. Jeśli twój magazyn śladów ma kolumnę dla typów komunikatów AIS, masz nieszczelną architekturę. Adaptery są jednokierunkowymi konwerterami danych ze ścisłą izolacją; eksponują w górę wyłącznie kanoniczne ślady.

Pragmatyczna struktura adaptera dla każdego źródła:

  • Transport — konektor do źródła (gniazdo UDP, subskrypcja MQTT, webhook HTTP, obserwator plików). Odporny na awarie po stronie źródła: ponowne łączenia, backoff, rozliczanie utraconych komunikatów.
  • Parser — tłumaczy format przewodowy na silnie typowaną strukturę w procesie. Waliduje względem specyfikacji formatu. Odrzuca błędne dane głośno, a nie po cichu.
  • Normalizator — mapuje pola specyficzne dla źródła na pola kanoniczne. Konwersja układu współrzędnych (zwykle do WGS84). Normalizacja znaczników czasu (UTC, z dyscypliną trzech znaczników czasu z Części 1).
  • Emiter — publikuje kanoniczną aktualizację śladu na szynie komunikatów. Taguje identyfikatorem źródła, klasyfikacją źródła, releasability.

Każdy adapter to oddzielna usługa lub proces. Współdzielą wygenerowaną z kodu bibliotekę klienta dla schematu kanonicznego, ale żadnych innych ścieżek kodu. Dodanie nowego typu sensora oznacza napisanie nowego adaptera, a nie modyfikowanie jakiegokolwiek innego komponentu. Szczegółowe wzorce integracji dla typowych źródeł znajdują się w Integracja AIS i ADS-B w obrazie wojskowym, a strona CoT w Cursor on Target (CoT): standard XML stojący za aplikacjami świadomości taktycznej.

Krok 2: Podłącz szynę komunikatów

Adaptery publikują do trwałego, uporządkowanego, partycjonowanego logu. Usługi fuzji konsumują z niego. Tak samo robi usługa audytu, usługa odtwarzania historycznego oraz wszelka analityka downstream. Szyna komunikatów jest rdzeniem kręgowym platformy.

Dla bieżącego przykładu używamy Kafki z topikiem-na-typ-źródła oraz dodatkowymi topikami dla wyjść fuzji. Adaptery publikują do raw.source-type; silnik fuzji konsumuje je i publikuje do tracks.updates oraz tracks.lifecycle. Audyt subskrybuje wszystko. Wzorzec szyny, w tym kompromisy między przepustowością a trwałością, opisany jest w Kolejki komunikatów w potokach danych obronnych.

Decyzja architektoniczna warta wyróżnienia: nie wywołuj HTTP między komponentami fuzji. Synchroniczne sprzężenie request-response czyni potok fuzji kruchym. Skok obciążenia sensorów, który zatrzymuje jednego konsumenta, nie może zatrzymywać każdego producenta upstream. Szyna z backpressure jest rozwiązaniem strukturalnym; HTTP między komponentami fuzji jest powracającym źródłem awarii.

Krok 3: Korelacja track-to-track (korelacja śladów)

Sercem silnika fuzji jest algorytm decydujący, czy przychodzący raport jest aktualizacją istniejącego śladu, czy narodzinami nowego. Pomyl się — operator zobaczy „zupę śladów" (tysiąc symboli tam, gdzie powinno być sto) lub ślady-duchy (duplikaty, które powinny były się scalić). Trafnie — COP staje się wiarygodny.

Pragmatyczny wzorzec wykorzystuje dwustopniowy filtr.

Etap 1: bramkowanie regułowe. Dla każdego przychodzącego raportu obliczamy zbiór kandydujących istniejących śladów w zasięgu kinematycznym — bramka pozycja-czas mówiąca: „ślad poruszający się z prędkością nie większą niż V m/s mógłby pokonać dystans od ostatniej znanej pozycji do pozycji tego raportu w tym przedziale czasu". Priorytety tożsamości filtrują dalej: raport oznaczony „statek" nie może pasować do śladu „samolot". Filtry kompatybilności źródła: raport z radaru naziemnego nie może pasować do śladu powietrznego ani do platformy podwodnej. Etap regułowy obsługuje 90% wejść tanio i jednoznacznie.

Etap 2: asocjacja probabilistyczna. Dla przypadków spornych — wielu kandydatów wewnątrz bramki, niejednoznaczna tożsamość, gęste scenariusze z przecinającymi się trajektoriami — wywołujemy probabilistyczną asocjację danych. Joint Probabilistic Data Association (JPDA) dla umiarkowanej gęstości; Multiple Hypothesis Tracking (MHT) dla najtrudniejszych przypadków. Obie metody obliczają prawdopodobieństwo, że przychodzący raport należy do każdego z kandydujących śladów, i aktualizują ślady ważone tym prawdopodobieństwem.

Pełen model teoretyczny z implikacjami inżynierskimi znajduje się w Model fuzji danych JDL: praktyczne odniesienie inżynierskie. Niuanse inżynierskie, kiedy stosuje się każdą technikę i jaki tuning jest wymagany, opisane są w Wojskowa fuzja danych wyjaśniona.

Konkretna pułapka warta podkreślenia: MHT generuje wykładniczą liczbę hipotez bez pruningu. Polityka przycinania — ile hipotez zachować, kiedy łączyć, kiedy usuwać — jest ważniejsza niż sam algorytm rdzeniowy. Domyślnie stosuj agresywne przycinanie; rozluźniaj tylko wtedy, gdy obraz zagrożeń tego wymaga.

Krok 4: Zarządzanie cyklem życia śladu

Ślad nie jest statycznym rekordem. Rodzi się, jest potwierdzany, starzeje się, gaśnie i umiera. Silnik fuzji zarządza cyklem życia jawnie; COP wyświetla stan cyklu życia, aby operatorzy wiedzieli, którym śladom ufać.

Maszyna stanów dla bieżącego przykładu:

  • Wstępny (tentative) — pierwsza obserwacja; nie wyświetlany jeszcze w operacyjnym COP, chyba że zażądano tego jawnie. Zanika do usunięcia, jeśli nie nastąpi kontynuacja w konfigurowalnym oknie czasowym.
  • Potwierdzony (confirmed) — dwa lub więcej skorelowanych raportów, zachowana spójność kinematyczna. Promowany z wstępnego. To domyślny stan dla wyświetlanych śladów.
  • Dojrzały (mature) — potwierdzony i utrzymujący się przez co najmniej N minut ze spójnymi aktualizacjami. Używany przez analitykę downstream wymagającą stabilnej tożsamości.
  • Gasnący (fading) — brak aktualizacji w oczekiwanym interwale rewizyty. Wyświetlany ze znacznikiem nieaktualności. Konfigurowalny per klasa źródła (30-sekundowy ślad morski jest w porządku; 30-sekundowy ślad powietrzny gaśnie).
  • Utracony (lost) — brak aktualizacji przez dłuższy okres. Usuwany z aktywnego wyświetlania, ale zachowywany w magazynie śladów do audytu i analizy historycznej.

Każde przejście stanu jest logowane. Usługa audytu konsumuje strumień przejść i zapisuje niezmienne rekordy — temat Event sourcing dla śladów audytu obronnego. Przejścia są również eksponowane na szynie, aby COP mógł renderować stan cyklu życia bez pollingu.

Kluczowy wniosek: Operatorzy tolerują brakujący ślad. Nie tolerują pewnie wyświetlanego nieaktualnego śladu. Zarządzanie cyklem życia to warstwa, która robi różnicę. Zbuduj ją zanim algorytm fuzji zostanie w pełni dostrojony — jest tania i zwraca się za każdym razem, gdy zerwie się link do sensora.

Krok 5: Autorytatywny magazyn śladów

Fuzja produkuje strumień aktualizacji śladów i przejść cyklu życia. Magazyn śladów jest zmaterializowanym widokiem: bieżącym stanem każdego aktywnego śladu, odpytywalnym przez COP i analitykę. Decyzja architektoniczna warta podjęcia wcześnie: magazyn śladów to model odczytu, a nie źródło autorytatywne. Źródłem autorytatywnym jest log zdarzeń na szynie komunikatów. Magazyn śladów jest odbudowywany z logu na żądanie.

Ten wzorzec — stan z event sourcing z projekcjami modeli odczytu — ma trzy korzyści operacyjne. Magazyn można wyczyścić i odbudować bez utraty danych. Wiele modeli odczytu o różnych kształtach może współistnieć (jeden dla COP, jeden dla analityki, jeden dla zewnętrznego API). Zapytania w stylu „podróży w czasie" stają się trywialne: odtwórz log do wybranego momentu, aby zrekonstruować, w co platforma wówczas wierzyła.

Sam magazyn to PostgreSQL z PostGIS do indeksowania geoprzestrzennego. Gorące ślady żyją w pamięci lub w warstwie Redis przed PostgreSQL dla odczytów poniżej milisekundy; magazyn relacyjny obsługuje zapytania o długim ogonie i gwarancje trwałości. Szczegółowy widok inżynierski znajduje się w PostGIS dla obronnych danych geoprzestrzennych.

Oprzyj się pokusie dodania bazy grafowej „na relacje". Relacje między śladami — detekcja konwojów, rozpoznawanie szyków, sieci kontaktów — to fuzja Poziomu 2 wg JDL, oddzielny problem od utrzymania śladów Poziomu 1. Najpierw zbuduj Poziom 1, uruchom go w operacjach przez rok, potem wróć do Poziomu 2 z operacyjnymi dowodami w ręku.

Krok 6: Testuj realistycznymi danymi wejściowymi

Silnik fuzji testowany tylko z zabawkowym obciążeniem przechodzi testy integracyjne i pada w operacjach. Dyscypliny, które wyłapują problemy przed wdrożeniem:

Stanowiska testowe do odtwarzania (replay). Przechwytuj rzeczywiste ślady sensorów podczas developmentu i odtwarzaj je z pełną szybkością przeciw silnikowi fuzji. Ślady służą jako pakiet testów regresji: nowy algorytm lub zmiana schematu musi produkować równoważne lub lepsze wyniki na istniejących śladach, a nie tylko na obciążeniu syntetycznym.

Wejścia adwersaryjne. Sfałszowane komunikaty AIS z nieprawdopodobną kinematyką. Błędne XML CoT. Ploty radarowe naruszające fizykę (naziemne ślady Mach 5). Silnik fuzji musi je odrzucić lub oflagować, nie spanikować, nie crashować, nie produkować pewnych-ale-błędnych śladów. Dyscyplina jest taka sama jak szersza dyscyplina testowa w Testowanie krytycznych dla misji systemów C2.

Detekcja wzorca życia (pattern-of-life). Gdy podstawowa fuzja działa, dołóż analitykę PoL — patrz Analiza wzorca życia w wywiadzie wojskowym. Usługa PoL konsumuje te same topiki szyny; produkuje wzbogacone adnotacje stanu śladu, zamiast konkurować z silnikiem fuzji.

Krok 7: Cele wydajnościowe i zapas

Opóźnienie fuzji ma konsekwencje operacyjne. Cele dla bieżącej przykładowej platformy: 95. percentyl end-to-end opóźnienia fuzji poniżej 500 ms (od przyjęcia raportu sensora do komunikatu aktualizacji śladu na szynie); 99. percentyl poniżej 1,5 s; przepustowość utrzymywana na poziomie 10 000 raportów na sekundę przy jednocyfrowym procencie zapasu CPU.

To są cele dla brygady taktycznej. Platformy strategiczne mają luźniejsze tolerancje opóźnień i wyższe sufity przepustowości. Cele napędzają decyzje architektoniczne: unikaj synchronicznych wywołań między usługami na ścieżce gorącej; pre-alokuj stan gorących śladów; batchuj tylko tam, gdzie pozwala szyna; instrumentuj każdy etap potoku, aby regresje opóźnień ujawniały się w CI, a nie w operacjach.

Co dalej

Część 2 zbudowała silnik. Adaptery sensorów konwertują do kanonicznych śladów; szyna komunikatów przenosi zdarzenia; silnik fuzji koreluje raporty w ślady; zarządzanie cyklem życia trzyma operatorów w ryzach co do świeżości; magazyn śladów eksponuje bieżący stan. Platforma produkuje teraz wiarygodne dane śladów. Po prostu nie ma żadnej powierzchni dla operatora.

Część 3 buduje wspólny obraz operacyjny — frontend zamieniający ślady w mapę, której operator faktycznie używa. Symbolika, aktualizacje w czasie rzeczywistym, filtrowanie oparte na rolach oraz decyzje inżynierskie, które determinują, czy platforma zostanie zaadoptowana w terenie.