Połączenie informacji wywiadowczych z SIGINT, IMINT, HUMINT i OSINT w jeden spójny obraz brzmi w założeniu prosto. W praktyce jest to jeden z najtrudniejszych problemów inżynieryjnych w infrastrukturze danych sektora obronnego. Każda dyscyplina wytwarza dane w innym tempie, w innym formacie i z innym modelem pewności — a system, który jedynie agreguje te strumienie bez rzeczywistej korelacji, tworzy obraz bardziej zaszumiony niż dobrze zarządzany strumień z pojedynczego INT, a nie lepszy. Poważna integracja danych na potrzeby wywiadu obronnego wymaga architektury zaprojektowanej od podstaw wokół właściwości każdego typu źródła, a nie generycznej hurtowni danych z doczepionymi adapterami INT.

Artykuł przedstawia pełną architekturę systemu wieloźródłowej fuzji w czasie rzeczywistym — od warstwy pozyskiwania strumieni, która przyjmuje heterogeniczne dane, przez rozpoznawanie encji i silnik korelacji, po ocenę pewności i publikację wzbogaconego obrazu wywiadowczego dla systemów C2. Każda sekcja omawia konkretne decyzje projektowe, które odróżniają fuzję klasy produkcyjnej od systemów prototypowych, które wyglądają poprawnie w demonstracji, lecz zawodzą w skali operacyjnej.

Problem wieloźródłowej fuzji informacji wywiadowczych — dlaczego fuzja SIGINT/IMINT/HUMINT/OSINT jest trudniejsza, niż się wydaje

Trzy problemy strukturalne sprawiają, że fuzja wieloźródłowa jest jakościowo trudniejsza niż przetwarzanie dowolnego pojedynczego INT w dużej skali. Ich ignorowanie — traktowanie fuzji jedynie jako problemu potoku danych — jest najczęstszym błędem architektonicznym i prowadzi do powstania systemu, którego nie da się naprawić, gdy dane zaczynają płynąć w wolumenie produkcyjnym.

Heterogeniczność formatów to najbardziej widoczny problem. Zapis przechwycenia ELINT zawiera częstotliwość emitera, interwał powtarzania impulsów, typ skanowania, namiar oraz dane różnicy czasów przybycia sygnału. Detekcja IMINT zawiera ramkę ograniczającą, wskaźnik pewności w przestrzeni pikseli, rozdzielczość terenową (ground sample distance) oraz współrzędną UTM z powiązanym CEP. Narracyjny wyciąg HUMINT zawiera swobodny tekst, ocenę źródła nadaną przez analityka, nazwaną lokalizację oraz okno czasowe mierzone w godzinach lub dniach. Te trzy rekordy mogą odnosić się do tego samego obiektu ze świata rzeczywistego — pojazdu radarowego — ale nie mają wspólnego pola, wspólnej konwencji układu współrzędnych ani wspólnego identyfikatora. Znormalizowanie ich do jednego kanonicznego schematu wymaga adapterów zbudowanych specjalnie dla każdego typu źródła oraz kanonicznego modelu encji, który pomieści je wszystkie bez zatarcia ich semantyki. Warstwę kanoniczną szczegółowo omawia projekt modelu danych dla wojskowej fuzji czujników multi-INT.

Niezgodność miar pewności jest subtelniejsza, ale powoduje więcej błędów analitycznych. Każdy INT stosuje własny model pewności. Geolokalizacja SIGINT niesie CEP (błąd kołowy prawdopodobny, Circular Error Probable) w metrach — geometryczne oszacowanie dokładności. Detekcja IMINT niesie prawdopodobieństwo klasyfikatora — wyjściowy logit sieci neuronowej dla klasy obiektu. HUMINT niesie ocenę wiarygodności według skali admiralicji — sześciostopniową skalę oceny dokonywanej przez człowieka. Te trzy liczby znaczą zasadniczo różne rzeczy. Naiwny system fuzji, który je uśrednia, daje liczbę matematycznie poprawną, lecz analitycznie pozbawioną znaczenia. Poprawny model pewności musi najpierw przełożyć pewność natywną dla każdego źródła na wspólne ramy probabilistyczne, a następnie agregować dane z wielu źródeł za pomocą schematu bayesowskiego lub schematu łączenia dowodów (takiego jak Dempstera-Shafera), który poprawnie obsługuje dowody zależne i niezależne.

Przesunięcie czasowe to problem, który w najbardziej widoczny sposób rozbija architektury fuzji w czasie rzeczywistym. Różne źródła mają skrajnie różne opóźnienia od wystąpienia zdarzenia do dotarcia danych do potoku. Przechwycenie SIGINT może dotrzeć do potoku w ciągu sekund od transmisji. IMINT z satelity, któremu zlecono zadanie, może wymagać 60–90 minut przetwarzania obrazów, zanim powstanie rekord detekcji. Raport HUMINT opisujący wczorajsze zdarzenia może zostać pozyskany w dniu D+2. Silnik fuzji, który koreluje rekordy według znacznika czasu nadejścia do potoku, będzie systematycznie błędnie kojarzył zdarzenia — nie powiąże przechwycenia SIGINT z potwierdzeniem IMINT, ponieważ dotarły one w odstępie 90 minut, mimo że opisują to samo zdarzenie. Architektura musi rozdzielać czas zdarzenia (event time; kiedy zdarzenie zaszło w rzeczywistości) od czasu przyjęcia (ingestion time; kiedy komunikat dotarł do potoku) i przeprowadzać całą korelację czasową na czasie zdarzenia, wykorzystując czas przyjęcia wyłącznie do monitorowania wydajności potoku.

Architektura pozyskiwania strumieni — Kafka a Pulsar dla strumieni wywiadowczych, rejestr schematów dla heterogenicznych typów komunikatów, obsługa przeciążenia (backpressure)

Warstwa pozyskiwania strumieni musi obsługiwać komunikaty napływające w tempie od kilku raportów HUMINT na godzinę do milionów rekordów SIGINT na godzinę z pojedynczego systemu zbierania, wszystkie trafiające do tego samego potoku fuzji. Projekt musi absorbować ruch impulsowy ze źródeł o wysokiej szybkości napływu bez przenoszenia tego przeciążenia (backpressure) na źródła o niskiej szybkości napływu i wysokim priorytecie — raport HUMINT, który nadchodzi w serii razem z lawiną SIGINT, nie może być opóźniony tylko dlatego, że potok jest nasycony.

Główny wybór architektoniczny na tej warstwie dotyczy decyzji między Apache Kafka a Apache Pulsar. Oba są rozproszone, odporne na awarie i sprawdzone w skali systemów klasy obronnej. Kafka ma większy ekosystem i ściślejszą integrację z frameworkami przetwarzania strumieniowego — zarówno Kafka Streams, jak i Apache Flink mają pierwszorzędne konektory źródłowe Kafka. Pulsar oferuje natywną wielodzierżawność, izolację tematów na poziomie przestrzeni nazw oraz architekturę z rozdzielonymi warstwami obliczeniową i przechowywania danych. Dla platformy fuzji jednodzierżawnej, działającej w obrębie jednej domeny klauzul tajności, pragmatycznym wyborem jest Kafka. Dla platformy, która musi izolować strumienie według poziomu klauzuli tajności, obsługiwać odłączone wysunięte węzły synchronizujące się asynchronicznie z klastrem na zapleczu albo obsługiwać wiele organizacji-dzierżawców, architektura Pulsara zapewnia czystsze prymitywy izolacji bez doraźnych obejść.

Niezależnie od wyboru brokera struktura tematów musi wymuszać jeden temat na typ źródła, a nie jeden temat na dyscyplinę INT:

# Konwencja nazewnictwa tematów: {classification}.{int-type}.{source-id}.raw ts.sigint.comint-system-alpha.raw ts.sigint.elint-collection-bravo.raw ts.imint.uav-sensor-charlie.raw ts.imint.sat-proc-delta.raw ts.humint.field-reports.raw ts.osint.ais-feed.raw ts.osint.social-monitor.raw # Znormalizowane tematy wyjściowe (po adapterze) ts.fusion.observations.normalized ts.fusion.entities.enriched ts.fusion.correlations.output

Rejestr schematów jest obowiązkowy dla znormalizowanych tematów wyjściowych. Bez wymuszanych schematów pojedynczy zniekształcony komunikat z dowolnego adaptera może uszkodzić kontekst deserializacji odbiorcy w dalszym etapie przetwarzania i zatrzymać cały potok fuzji. Rejestr wymusza schematy Avro lub Protobuf przy każdym zapisie do tematów fuzji i odrzuca komunikaty, które nie przechodzą walidacji, zanim dotrą do brokera. Reguły zgodności schematów — BACKWARD, FORWARD lub FULL — należy ustawiać dla każdego tematu w zależności od tego, jak ewoluują odbiorcy. Dla schematu znormalizowanych obserwacji odpowiednia jest zgodność BACKWARD: nowe wersje schematu mogą dodawać pola opcjonalne, a starsi odbiorcy, którzy nie rozumieją nowych pól, będą nadal działać poprawnie.

Obsługa backpressure wymaga limitów częstotliwości dla każdego typu źródła wraz z klasyfikacją priorytetów. Źródła o wysokim priorytecie — SIGINT i IMINT z systemów zbierania danych w czasie rzeczywistym — nigdy nie mogą podlegać limitom częstotliwości. Źródła o niskim priorytecie — hurtowe pobieranie OSINT, ładowanie historycznych danych HUMINT — powinny mieć jawne wagi priorytetów, które pozwalają brokerowi ograniczać jego konsumentów, gdy przepustowość potoku jest ograniczona. W Kafka realizuje się to przez kwoty grup konsumentów i strategie przydzielania partycji. W Pulsar równoważną kontrolę zapewniają limity częstotliwości i kwoty wysyłki dla poszczególnych przestrzeni nazw. Wzorce architektury wojskowego potoku danych wywiadowczych szczegółowo omawiają zarządzanie kolejkami i projektowanie grup konsumentów.

Rozstrzyganie encji i deduplikacja — strategie blokowania generowania kandydatów encji, punktowanie podobieństwa oparte na uczeniu maszynowym, łączenie encji na podstawie grafu

Rozstrzyganie encji to składnik, który przekształca strumień niezależnych obserwacji — z których każda opisuje wykryty obiekt lub zgłoszone zdarzenie — w zbiór zunifikowanych rekordów encji, w których scaliły się wszystkie obserwacje dotyczące tego samego obiektu w świecie rzeczywistym. To najtrudniejszy do poprawnego działania składnik i najbardziej podatny na cichą degradację: system o słabym rozstrzyganiu encji nie ulega awarii; generuje obraz z nadmierną liczbą encji (rozdrobnione ślady) lub zbyt małą (fałszywe scalenia), a błędy te kumulują się w czasie, ponieważ fuzja buduje na zanieczyszczonym stanie encji.

Podejście naiwne — porównywanie każdej napływającej obserwacji z każdą istniejącą encją — jest obliczeniowo niewykonalne w realistycznej skali. System zbierania ELINT produkujący 10 000 rekordów przechwycenia na minutę wobec korpusu 50 000 aktywnych śladów encji wymagałby 500 milionów porównań na minutę przed jakimkolwiek punktowaniem podobieństwa. Strategie blokowania ograniczają to do wykonalnego zbioru kandydatów, wykorzystując strukturę danych wywiadowczych:

  • Blokowanie według komórek geo — indeksowanie każdej encji według jej szacowanej lokalizacji przy użyciu heksagonalnej siatki H3 na poziomie rozdzielczości 9 (komórki o powierzchni ok. 0,1 km²). Napływająca obserwacja generuje pary kandydujące wyłącznie wobec encji w tej samej komórce i jej sześciu bezpośrednich sąsiadach. Ten jeden klucz blokowania eliminuje ponad 99,9% par kandydujących dla danych przestrzennych, zachowując wysokie pokrycie rzeczywiście współlokalizowanych obserwacji.
  • Blokowanie czasowe — ograniczenie kandydatów do encji, których przedział czasu ważności nakłada się na konfigurowalne okno wokół czasu zdarzenia obserwacji. Dla poruszającego się pojazdu okno musi uwzględniać maksymalną wiarygodną prędkość między lokalizacją ostatniej obserwacji a lokalizacją bieżącej obserwacji — czołg nie może pokonać 50 km w 5 minut. Blokowanie czasowe bez blokowania według komórek geo generuje ogromne zbiory kandydatów dla dowolnej encji aktywnej globalnie; oba mechanizmy działają razem jako klucz złożony.
  • Blokowanie według identyfikatorów twardych — grupowanie wszystkich rekordów współdzielących deterministyczny identyfikator (IMSI, wynik OCR tablicy rejestracyjnej, skrót biometryczny kod transpondera Mode-S statku powietrznego) w jeden klaster kandydatów niezależnie od lokalizacji i czasu. Identyfikatory twarde omijają całe pozostałe blokowanie i są traktowane jako definitywne sygnały scalenia, do czasu sprawdzenia deduplikacji samego identyfikatora.
  • Blokowanie według powinowactwa typów INT — niektóre pary między typami INT są strukturalnie mało prawdopodobne i nie powinny być punktowane. Obserwacja emisji SIGINT z obszaru morskiego nie powinna być punktowana wobec śladu IMINT pojazdu lądowego. Reguły powinowactwa, definiowane dla każdego typu encji, eliminują strukturalnie nieprawdopodobne pary kandydujące przed punktowaniem.

Punktowanie podobieństwa par kandydujących wykorzystuje model gradient boosting (XGBoost lub LightGBM) wytrenowany na oznakowanych parach dopasowanie/niedopasowanie z historycznych danych wywiadowczych. Wektory cech obejmują: odległość przestrzenną znormalizowaną niepewnością położenia, odległość czasową znormalizowaną obwiednią prędkości typu encji, wynik nakładania atrybutów dla atrybutów typowanych (klasa encji, przynależność, typ wyposażenia) oraz wagę zgodności typów INT. Model zwraca prawdopodobieństwo dopasowania w przedziale [0, 1]. Pary powyżej wysokiego progu (zwykle 0,85–0,92) są scalane automatycznie; pary ze środkowego przedziału trafiają do przeglądu analityka; pary poniżej niskiego progu są traktowane jako odrębne encje.

Łączenie encji na podstawie grafu obsługuje przypadek wielodrożny — gdy trzy lub więcej obserwacji musi zostać rozstrzygniętych do tej samej encji. Utrzymywany jest graf, w którym węzłami są rekordy obserwacji, a krawędziami decyzje scalenia z przypisanymi wynikami wiarygodności. Spójne składowe grafu reprezentują klaster kandydatów encji. Złoty rekord dla każdego klastra jest obliczany przez zastosowanie zdefiniowanej polityki scalania do wszystkich wnoszących obserwacji. Gdy dodawana jest nowa krawędź o wysokiej wiarygodności łącząca dwa wcześniej rozłączne składniki, składniki są scalane, a ich złote rekordy łączone. Reprezentacja grafowa umożliwia również operacje podziału: usunięcie krawędzi o wysokiej wiarygodności i ponowne obliczenie spójnych składowych jest mechanizmem korygowania fałszywego scalenia.

Referencja architektury
Potok rozstrzygania encji — przepływ etapów
1
Blokowanie — generowanie par kandydujących przez klucze komórek geo, czasowe i identyfikatorów twardych. Cel pokrycia: >99,5% prawdziwych dopasowań w zbiorze kandydatów.
2
Ekstrakcja cech — obliczanie odległości przestrzennej, delty czasowej, nakładania atrybutów i zgodności typów INT dla każdej pary kandydującej.
3
Punktowanie ML — model gradient boosting zwraca prawdopodobieństwo dopasowania dla każdej pary. Pary z identyfikatorami twardymi omijają punktowanie i trafiają bezpośrednio do scalenia.
4
Routing progowy — wynik ≥ 0,88: automatyczne scalenie. 0,55–0,87: kolejka przeglądu analityka. < 0,55: odrzucenie (odrębne encje).
5
Scalanie grafowe — aktualizacja grafu encji o nowe krawędzie; ponowne obliczenie złotych rekordów spójnych składowych; emisja zaktualizowanych encji do wzbogaconego strumienia encji.
Pięcioetapowy potok rozstrzygania encji — od generowania kandydatów po publikację złotego rekordu.

Projekt silnika korelacji — korelacja okienkowa (bliskość czasowa), korelacja przestrzenna (grupowanie według komórek geo), korelacja semantyczna (dopasowanie atrybutów encji)

Tam gdzie rozstrzyganie encji pyta „czy te obserwacje dotyczą tego samego obiektu?”, silnik korelacji pyta „czy te zdarzenia dotyczące różnych obiektów tworzą sensowny wzorzec?”. Pojazd wykryty w pobliżu składu logistycznego, 20 minut później ten sam pojazd na punkcie tankowania, a następnie przechwyt SIGINT rozmowy radiowej zgodny z meldunkiem o położeniu jednostki z punktu tankowania — te trzy zdarzenia dotyczą tego samego pojazdu, ale opisują też wzorzec sytuacyjny (działania zaopatrzeniowe), który analitycznie jest istotniejszy niż jakakolwiek pojedyncza obserwacja. Silnik korelacji wytwarza ten obiekt wywiadowczy wyższego rzędu.

Korelacja działa równolegle w trzech płaszczyznach:

Korelacja czasowa grupuje zdarzenia w okna według ich znacznika czasu zdarzenia i poszukuje wzorców współwystępowania w każdym oknie. Definicja okna jest konfigurowalna dla każdej reguły: reguła wykrywająca jednoczesne rozpoczęcie zagłuszania i przerwanie łączności własnej może używać okna 30-sekundowego; reguła wykrywająca pojazd na punkcie orientacyjnym, a następnie inny pojazd na tym samym punkcie — okna 2-godzinnego. Okna przesuwne (nakładające się na połowę czasu trwania okna) gwarantują, że zdarzenia na granicach okien nie zostaną pominięte. Okienkowanie zdarzeń w czasie zdarzeń z watermarks w Apache Flink jest standardowym wyborem implementacyjnym, ponieważ poprawnie obsługuje napływ zdarzeń poza kolejnością — kluczowe dla potoku, w którym IMINT i HUMINT mają bardzo różne opóźnienia pobierania.

Korelacja przestrzenna grupuje encje według ich szacowanej lokalizacji, stosując grupowanie według komórek geo o rozdzielczości skalibrowanej do skali przestrzennej reguły korelacji. Rozdzielczość H3 o poziomie 8 (ok. 0,7 km²) jest odpowiednia do wykrywania pojazdów działających w tej samej strefie; rozdzielczość H3 o poziomie 6 (ok. 36 km²) — do wykrywania wzorców aktywności w skali regionu. W przeciwieństwie do blokowania według komórek geo w rozstrzyganiu encji (które wymaga wysokiego pokrycia), przestrzenne grupowanie korelacji wymaga precyzji zdefiniowanej w regule: reguła korelacji wykrywająca współlokalizację pojazdu dowodzenia z pojazdem logistycznym powinna używać ciaśniejszej komórki niż reguła wykrywająca aktywność zaopatrzeniową w skali obszaru. Reguły kodują własny parametr rozdzielczości przestrzennej zamiast dziedziczyć ustawienie globalne.

Korelacja semantyczna dopasowuje encje na podstawie wartości atrybutów, a nie bliskości przestrzennej czy czasowej. Encja sklasyfikowana jako radar obrony powietrznej, która zaczyna emitować, skorelowana z encją sklasyfikowaną jako samolot bojowy wchodzący w strefę pokrycia radaru — korelacja jest sterowana semantyką atrybutów (typ radaru wobec typu samolotu i trajektorii), nie ich współlokalizacją. Reguły semantyczne kodują predykaty atrybutów dla typów encji: entity.type == EQUIPMENT AND entity.attributes.role == AIR_DEFENSE AND entity.activity_state == EMITTING. Te wyrażenia predykatów są ewaluowane przez procesor strumieniowy dla każdego zdarzenia aktualizacji encji; gdy wszystkie predykaty reguły zostaną spełnione w oknie, korelacja zostaje uruchomiona.

Reguły korelacji są przechowywane jako deklaratywne definicje w rejestrze reguł, a nie jako zakodowana na sztywno logika. Pozwala to analitykom wywiadu tworzyć nowe reguły bez udziału inżynierów oraz stosować zmiany reguł bez ponownego wdrażania silnika korelacji:

# Przykładowa definicja reguły korelacji (YAML) rule_id: RESUPPLY-PATTERN-001 name: "Wykrywanie sekwencji zaopatrzenia pojazdu" description: "Wykrywa wizytę pojazdu w węźle logistycznym, a następnie na punkcie tankowania w oknie" confidence_weight: 0.72 spatial_resolution: H3_LEVEL_8 temporal_window_minutes: 90 events: - alias: VEH entity_type: EQUIPMENT attribute_predicates: - "attributes.platform_class IN [APC, IFV, TRUCK, LOGISTICS_VEHICLE]" - alias: NODE_VISIT entity_type: EVENT attribute_predicates: - "attributes.event_class == LOCATION_VISIT" - "attributes.location_type IN [LOGISTICS_NODE, DEPOT, FUEL_POINT]" linked_entity: VEH temporal_order: AFTER VEH.last_seen output: entity_type: SITUATION situation_class: RESUPPLY_ACTIVITY contributing_entity_refs: [VEH.entity_id, NODE_VISIT.entity_id]

Każda uruchomiona korelacja wytwarza encję Situation — nowy obiekt wywiadowczy na warstwie JDL Level 2, który odwołuje się do UUID-ów wnoszących encji, zawiera ID reguły i wagę wiarygodności reguły oraz jest publikowany do wzbogaconego strumienia encji obok standardowych aktualizacji encji.

Punktowanie wiarygodności i pochodzenie — macierz wiarygodności źródła × wiarygodności informacji (system admiralicji NATO), propagacja wiarygodności przez fuzję encji

Każda encja na scalonej mapie niesie wynik wiarygodności, ale wiarygodność w systemie fuzji wieloźródłowej nie jest pojedynczą liczbą — jest wartością złożoną, którą należy rozłożyć na kilka wymiarów, aby była analitycznie użyteczna. Wynik 0,73 uzyskany na podstawie trzech wzajemnie potwierdzających się zapisów SIGINT znaczy coś zupełnie innego niż wynik 0,73 pochodzący z jednego niewiarygodnego meldunku HUMINT i niczego więcej. Architektura musi zachowywać rozkład, a nie tylko wartość zbiorczą.

Model wiarygodności składa się z trzech warstw wejściowych. Po pierwsze, waga wiarygodności źródła wyprowadzona z admiralicjnej oceny wiarygodności źródła NATO: A=1.0, B=0.8, C=0.6, D=0.4, E=0.2, F=0.1. Ta waga skaluje wkład każdej obserwacji ze źródła w obliczenia fuzji. Po drugie, waga wiarygodności informacji wyprowadzona z admiralicjnej oceny wiarygodności informacji: 1=1.0, 2=0.8, 3=0.6, 4=0.4, 5=0.2, 6=0.1. Tę wagę stosuje się do każdej obserwacji niezależnie od wiarygodności źródła, ponieważ wiarygodne źródło może zgłaszać informacje niepewne. Po trzecie, wynik zgodności między źródłami — ułamek niezależnie potwierdzających źródeł, które zgadzają się co do wartości kluczowego atrybutu, ważony ich wiarygodnością źródła. Wartość położenia potwierdzona przez trzy źródła o ocenie A z informacjami o ocenie B2 punktuje zupełnie inaczej niż potwierdzona przez dwa źródła o ocenie E z informacjami o ocenie D4.

Złożona wiarygodność atrybutu wynosi:

# Wzór wiarygodności dla każdego atrybutu wynikowego fuzji # Dla każdej wnoszącej obserwacji i: # w_i = waga_wiarygodnosci_zrodla(ocena_admiralicji_A_do_F) # × waga_wiarygodnosci_informacji(ocena_admiralicji_1_do_6) # # Ważony wynik zgodności: # agreement = suma(w_i dla i w źródłach potwierdzających) # / suma(w_i dla i we wszystkich wnoszących źródłach) # # Wiarygodność fuzji: # confidence = agreement × source_coverage_penalty # # gdzie source_coverage_penalty obniża potwierdzenie z jednego typu INT: # 1.0 jeśli ≥ 2 różne typy INT potwierdzają # 0.75 jeśli dokładnie 1 typ INT z ≥ 2 źródłami # 0.5 jeśli łącznie dokładnie 1 źródło

Propagacja wiarygodności na encje pochodne przebiega według reguły rozcieńczenia: encja Situation wyliczona przez silnik korelacji z dwóch wnoszących złotych rekordów encji nie może mieć wyższej wiarygodności niż encja wnosząca o niższej wiarygodności. Wiarygodność może wzrosnąć tylko wtedy, gdy do encji wnoszących dodane zostaną dodatkowe niezależne obserwacje potwierdzające. Zapobiega to sztucznemu zawyżaniu wiarygodności przez silnik korelacji przez łączenie encji o niskiej jakości.

Pochodzenie jest przechowywane jako łańcuch: każdy złoty rekord odwołuje się do UUID-ów obserwacji, które się do niego przyczyniły; każda obserwacja odwołuje się do swojego ID źródła, systemu zbierania i ocen admiralicji. Łańcuch jest niezmienny — nigdy nie jest aktualizowany w miejscu. Gdy źródło wnoszące zostanie później ocenione jako niewiarygodne lub wprowadzające w błąd, łańcuch dostarcza pełnego zbioru encji, które należy ponownie ocenić z wyłączeniem wkładu tego źródła. Wycofanie źródła jest operacją pierwszej kategorii, a nie procedurą awaryjną.

Publikacja obrazu wywiadowczego — publikacja wzbogaconych encji do systemów C2 przez CoT/NIEM, cele opóźnień dla wywiadu wrażliwego czasowo

Wzbogacony strumień encji jest reprezentacją wewnętrzną. Publikacja przekształca tę reprezentację w formaty transmisyjne, które systemy C2 i odbiorcy nadrzędni faktycznie rozumieją. Dla większości wdrożeń obronnych oznacza to Cursor on Target (CoT) dla danych o śladach oraz formaty komunikatów oparte na NIEM dla ustrukturyzowanych meldunków wywiadowczych.

Publikacja CoT mapuje każdą aktualizację wzbogaconej encji na zdarzenie CoT. Mapowanie musi obsługiwać trzy typy aktualizacji: aktualizacje położenia (nowe współrzędne ze zaktualizowaną niepewnością), aktualizacje atrybutów (zmiana wiarygodności, zmiana stanu aktywności, zmiana oceny przynależności) oraz zdarzenia cyklu życia encji (tworzenie encji, wycofywanie oraz zdarzenia podziału i scalenia). Aktualizacje położenia są proste — tłumaczą się na zdarzenie punktowe CoT ze szacowanym położeniem encji i wiarygodnością położenia zakodowaną w polu błędu CoT. Aktualizacje atrybutów tłumaczą się na uwagi CoT lub aktualizacje elementu detail istniejącej encji. Zdarzenia cyklu życia — zwłaszcza scalenie i podział — wymagają specjalnej obsługi: zdarzenie scalenia wycofuje ślad CoT encji o niższej wiarygodności i aktualizuje detail CoT przetrwałej encji informacją o pochodzeniu; zdarzenie podziału tworzy nowy ślad CoT dla nowo wyodrębnionej encji.

Pole stale_time w CoT jest naturalnym mechanizmem zarządzania TTL po stronie odbiorcy C2. Każde opublikowane zdarzenie CoT ustawia stale_time na entity_publication_time + entity_TTL. Odbierający system C2 (ATAK, CURSOR lub podobny) usuwa encję ze swojego wyświetlacza, gdy stale_time minie bez odświeżenia. System fuzji musi zapewnić, że encje z aktywnymi obserwacjami otrzymują zdarzenia odświeżenia CoT w odstępie krótszym niż ich TTL — zwykle przy 50% TTL — aby zapobiec znikaniu poprawnych encji z mapy podczas normalnej pracy.

Cele opóźnień determinują, jak warstwa publikacji musi być zaimplementowana. Dla przepływów pracy namierzania wrażliwych czasowo opóźnienie end-to-end od zdarzenia z sensora do wyświetlacza C2 musi wynosić poniżej 30 sekund. Osiągnięcie tego wymaga: asynchronicznych, nieblokujących pracowników publikacji; zrównoleglonej serializacji CoT w poprzek partycji encji; priorytetowych kolejek wyjściowych, które dają pierwszeństwo ruchomym śladom o wysokiej wiarygodności przed aktualizacjami encji statycznych; oraz bezpośredniej dostawy TCP multicast do odbiorców C2 zamiast odpytywania przez REST API. Dla ogólnej świadomości sytuacyjnej na szczeblu operacyjnym opóźnienie 60–120 sekund jest zazwyczaj akceptowalne, co umożliwia prostsze synchroniczne wzorce publikacji wsadowej.

Publikacja NIEM obsługuje odbiorców meldunków wywiadowczych — systemy, które potrzebują ustrukturyzowanych, czytelnych maszynowo ocen wywiadowczych, a nie danych o śladach. Encja Situation wygenerowana przez silnik korelacji jest publikowana jako NIEM Intelligence Message z UUID-ami encji wnoszących jako odwołaniami, klasą sytuacji jako tematem oraz danymi o wiarygodności i pochodzeniu w bloku metadanych komunikatu NIEM. Odbiorcami NIEM są między innymi wielodomenowe platformy wymiany wywiadu, bramy interoperacyjności do systemów państw partnerskich oraz systemy archiwizacji wymagające ustrukturyzowanego pochodzenia dla zgodności audytowej.

Obsługa niepewności czasowej i nieaktualnego wywiadu — zarządzanie TTL dla encji wywiadowczych, krzywe zaniku wiarygodności położenia i aktywności, wyzwalacze ponownej oceny

Wywiad jest nietrwały. Meldunek o położeniu śladu pojazdu, który był dokładny 20 minut temu, jest teraz mniej dokładny — pojazd mógł się przemieścić. Ocena aktywności oparta na pojedynczym przechwycie SIGINT sprzed 4 godzin może już nie odzwierciedlać bieżącego zachowania. System fuzji, który nie modeluje tej degradacji i nie propaguje jej na publikowany obraz, spowoduje, że analitycy będą podejmować decyzje w oparciu o nieaktualne informacje z wysokimi wynikami wiarygodności, które zostały zdobyte przez starsze obserwacje.

Zarządzanie TTL zaczyna się od przypisania TTL przy tworzeniu encji. Wartości TTL są specyficzne dla typu encji i poziomu wiarygodności:

  • Ślad poruszającego się pojazdu o wysokiej wiarygodności (wiarygodność ≥ 0.80, klasa mobilności = WHEELED/TRACKED): TTL 8–15 minut
  • Ślad poruszający się o średniej wiarygodności (wiarygodność 0.50–0.79): TTL 4–8 minut
  • Wstępny ślad o niskiej wiarygodności (wiarygodność < 0.50): TTL 2–4 minut
  • Obiekt stały o wysokiej wiarygodności (wiarygodność ≥ 0.80, klasa mobilności = STATIC): TTL 24–72 godziny
  • Encja personelu (oparta na aktywności, nie na położeniu): TTL 30–120 minut w zależności od typu ostatniej aktywności
  • Encja sytuacji (korelacja pochodna): TTL równy najkrótszemu TTL dowolnej encji wnoszącej, z górnym limitem 60 minut

Krzywe zaniku wiarygodności modelują, jak wiarygodność położenia i aktywności degraduje się między potwierdzającymi obserwacjami. Zamiast binarnego stanu aktywny/nieaktualny krzywa zaniku dostarcza ciągłą funkcję wiarygodności w czasie od ostatniej obserwacji:

# Zanik wiarygodności położenia — model wykładniczy # c(t) = c_0 × exp(-λ × t) # gdzie: # c_0 = wiarygodność w chwili ostatniej obserwacji potwierdzającej # t = czas upływu od ostatniej obserwacji (sekundy) # λ = stała zaniku, specyficzna dla typu encji # # Stałe zaniku (ilustracyjne): # TRACKED_VEHICLE: λ = 0.003 (okres półtrwania ≈ 3,8 min) # WHEELED_VEHICLE: λ = 0.004 (okres półtrwania ≈ 2,9 min) # SLOW_MOVER: λ = 0.001 (okres półtrwania ≈ 11,5 min) # STATIC_SITE: λ = 0.00001 (okres półtrwania ≈ 19 godzin) # MARITIME_SURFACE: λ = 0.002 (okres półtrwania ≈ 5,8 min) # # Encja przechodzi w stan STALE, gdy c(t) < staleness_threshold # (zwykle 0,15 dla śladów poruszających się, 0,05 dla obiektów stałych)

Wyzwalacze ponownej oceny uruchamiają się, gdy napływa nowa obserwacja przestrzennie i czasowo zgodna z nieaktualną encją. Zamiast tworzyć nową encję dla nowej obserwacji, wyzwalacz kieruje ją przez potok rozstrzygania encji wobec nieaktualnej encji jako kandydata. Jeśli wiarygodność dopasowania przekroczy próg scalenia, nowa obserwacja odświeża nieaktualną encję: zegar TTL zostaje wyzerowany, wiarygodność jest przeliczana z nowej obserwacji (możliwie w górę od wartości zanikłej, jeśli nowa obserwacja ma silną wiarygodność), a encja wraca ze stanu STALE do statusu ACTIVE. Odświeżenie jest rejestrowane jako zdarzenie aktualizacji w ścieżce audytu encji.

Model zaniku musi być również komunikowany odbiorcom C2, a nie tylko stosowany wewnętrznie. Publikowanie położenia o wysokiej wiarygodności do CoT bez sygnalizowania, że położenie ma 18 minut, powoduje, że wyświetlacz C2 pokazuje ostry, pewny symbol śladu, który analityk może zinterpretować jako obserwację w czasie rzeczywistym. Dwa mechanizmy to rozwiązują: pole CoT stale_time (omówione wcześniej) gwarantuje, że encja znika z wyświetlacza, gdy jest definitywnie nieaktualna; a pole wieku od ostatniej obserwacji publikowane w elemencie detail CoT daje analitykowi wgląd w czasie rzeczywistym w to, jak stara jest leżąca u podstaw obserwacja, nawet dla encji, które jeszcze nie osiągnęły swojego czasu nieaktualności. Niektóre systemy C2 wykorzystują to pole do modulowania wizualnej reprezentacji wiarygodności — zmieniając przezroczystość lub rozmiar symbolu śladu w funkcji wieku obserwacji.

Razem siedem składowych architektonicznych opisanych w tym artykule — heterogeniczne przyjmowanie strumieni, normalizacja wymuszona schematem, rozstrzyganie encji oparte na blokowaniu i uczeniu maszynowym, wielopłaszczyznowy silnik korelacji, warstwowe punktowanie wiarygodności, publikacja CoT/NIEM oraz zarządzanie zanikiem TTL — stanowi kompletną platformę fuzji wywiadu wieloźródłowego w czasie rzeczywistym. Żadna z tych składowych nie jest samodzielnie nowatorska. O tym, że architektura jest klasy produkcyjnej, decyduje jawne zaprojektowanie interfejsów między nimi: kanoniczny schemat obserwacji, który produkuje normalizacja i zużywa rozstrzyganie encji; format grafu encji, który produkuje rozstrzyganie encji i zużywa silnik korelacji; wzbogacony strumień encji, do którego zapisują zarówno rozstrzyganie encji, jak i silnik korelacji, i który czyta warstwa publikacji. System, w którym te interfejsy są niejawne lub niedokumentowane — w którym każda składowa zakłada określone zachowanie od swojej warstwy nadrzędnej — jest kruchy dokładnie w tych punktach, w których dane wywiadowcze są najbardziej zmienne w charakterze.