Normalizacja danych z czujników: budowanie kanonicznego modelu danych obronnych

Silnik fuzji jest tak dobry, jak dobre są dostarczane do niego dane — a dane te prawie nigdy nie są czyste. Radar raportuje zasięg w metrach i namiar w milach; odbiornik AIS raportuje pozycję w stopniach dziesiętnych WGS84 i prędkość w węzłach; produkt zobrazowania niesie znacznik czasu akwizycji według czasu lokalnego; przechwyt SIGINT nie zawiera geolokalizacji w ogóle. Zanim będzie mogła działać jakakolwiek korelacja, śledzenie czy analityka, każde z tych heterogenicznych danych wyjściowych musi zostać przekształcone w jedną, spójną wewnętrzną reprezentację. To przekształcenie to normalizacja danych z czujników, a jedyna reprezentacja, do której zmierza, to kanoniczny model danych. Ten artykuł omawia, jak zaprojektować model kanoniczny, zbudować adaptery dla poszczególnych źródeł mapujące do niego dane, normalizować jednostki, współrzędne i czas, utrzymywać proweniencję przez każdy rekord oraz ewoluować schemat przez lata bez zrywania zależności odbiorców.

Dlaczego kanoniczny model danych

Naiwne podejście do systemu wieloczujnikowego polega na tym, by każdy odbiorca bezpośrednio rozumiał format każdego źródła. Silnik fuzji parsuje komunikaty radarowe, potem komunikaty AIS, potem wykrycia z zobrazowania itd. Sprawdza się to przy dwóch lub trzech źródłach i załamuje pod ciężarem czwartego. Każdy nowy typ czujnika wymusza zmianę w kodzie fuzji, warstwie pamięci masowej, rendererze COP i każdej analizie, która dotyka danych. Sprzężenie jest kwadratowe: N źródeł razy M odbiorców.

Kanoniczny model danych zrywa to sprzężenie. Definiujesz jeden wewnętrzny schemat — znormalizowaną obserwację — i wymagasz, aby każde źródło było do niego mapowane, zanim trafi do potoku. Silnik fuzji, magazyn śladów i warstwa analityczna konsumują wyłącznie model kanoniczny i nigdy nie widzą natywnego formatu czujnika. Dodanie nowego czujnika oznacza napisanie jednego adaptera; żaden komponent niższego szczebla nie ulega zmianie. Sprzężenie spada z N razy M do N plus M.

Model kanoniczny nie jest formatem najmniejszego wspólnego mianownika. Jest celowo bogatym nadzbiorem: niesie pola, których może potrzebować dowolny odbiorca — kinematykę, tożsamość, pewność, niepewność, klasyfikację i proweniencję — nawet jeśli dane źródło wypełnia tylko ich podzbiór. Kontakt radarowy i raport HUMINT wyglądają strukturalnie identycznie w modelu kanonicznym; różnią się jedynie tym, które pola są obecne i jak pewne jest każde z nich.

Anatomia znormalizowanej obserwacji

Dobrze zaprojektowana obserwacja kanoniczna ma pięć grup pól, każda o wyraźnym przeznaczeniu.

Tożsamość i typ. Globalnie unikalny identyfikator obserwacji, kod typu encji zaczerpnięty z kontrolowanej taksonomii (pojazd naziemny, jednostka nawodna, statek powietrzny, emiter, żołnierz pieszy) oraz wszelka tożsamość potwierdzona przez źródło, jak numer śladu, MMSI lub znak wywoławczy. Taksonomia typów musi być współdzielona przez wszystkie źródła, aby jednostka raportowana przez AIS i wykryta przez radar mapowały się do tego samego kanonicznego typu.

Kinematyka. Pozycja w kanonicznej ramce współrzędnych, prędkość i kurs w kanonicznych jednostkach oraz wysokość lub głębokość tam, gdzie ma to zastosowanie. Każde pole kinematyczne niesie powiązaną niepewność — kowariancję lub co najmniej promień błędu — ponieważ algorytmy fuzji nie mogą ważyć obserwacji, której nie mogą ograniczyć.

Czas. Czas zdarzenia (kiedy obserwacja miała miejsce), odróżniony od czasu pozyskania (kiedy potok ją otrzymał). Czas zdarzenia jest podstawą wszelkiej korelacji; czas pozyskania służy do diagnostyki i pomiaru opóźnień. Każdy znacznik czasu niesie granicę niepewności.

Pewność. Znormalizowany wynik pewności i, oddzielnie, własna ocena wiarygodności źródła. Wykrycie o wysokiej pewności z niewiarygodnego źródła to nie to samo co wykrycie o umiarkowanej pewności z zaufanego — model kanoniczny musi zachować obydwa jako rozróżnialne.

Proweniencja. Identyfikator źródła pochodzenia, typ czujnika, natywny identyfikator wiadomości, adapter i wersja schematu, które wyprodukowały rekord, oraz klasyfikacja i zastrzeżenia odziedziczone po źródle. Proweniencja sprawia, że każde twierdzenie niższego szczebla jest możliwe do prześledzenia.

Adaptery: gdzie żyje złożoność specyficzna dla źródła

Adapter jest jedynym miejscem w systemie, które rozumie natywny format czujnika. Parsuje surowy komunikat, wyodrębnia odpowiednie pola, wykonuje wszystkie konwersje, dołącza proweniencję i emituje kanoniczną obserwację. Wszystko, co jest osobliwe w danym źródle — jego zastrzeżony układ binarny, brakujące pola, nieregularny rytm aktualizacji, dryf zegara — jest absorbowane wewnątrz adaptera i nigdy nie wycieka niżej. Jest to ta sama dyscyplina separacji odpowiedzialności, na której opiera się architektura fuzji wieloczujnikowej: rdzeń fuzji pozostaje ogólny właśnie dlatego, że adaptery wykonują brudną robotę.

Adaptery powinny być małe, niezależnie testowalne i bezstanowe wszędzie, gdzie to możliwe. Bezstanowy adapter mapujący jeden komunikat wejściowy na jedną kanoniczną obserwację jest trywialny do testowania jednostkowego na zarejestrowanych próbkach komunikatów. Gdy adapter musi utrzymywać stan — na przykład, aby interpolować pozycję między rzadkimi aktualizacjami lub stosować krocząca korektę przesunięcia zegara — stan ten powinien być jawny i ograniczony, nigdy niejawną akumulacją dryfującą przez długą misję.

Mapowanie schematów w praktyce

Mapowanie schematów to tłumaczenie pole po polu ze struktury natywnej źródła na obserwację kanoniczną. Najtrudniejsza część to rzadko pola mapujące jeden do jednego; to rozbieżności. Źródło może pakować dwa kanoniczne koncepty w jedno pole lub dzielić jeden kanoniczny koncept na kilka. Źródło może używać wyliczenia bez kanonicznego odpowiednika, wymagając tabeli przeglądowej i udokumentowanej wartości domyślnej dla nierozpoznanych wartości. Źródło może pomijać pole, które model kanoniczny traktuje jako obowiązkowe, zmuszając adapter do jego wywnioskowania, oznaczenia obserwacji jako częściowej lub jej odrzucenia.

Samo mapowanie powinno być wyrażone deklaratywnie tam, gdzie to możliwe — tabela mapowania lub konfiguracja stwierdzająca „natywne pole X z jednostką U staje się kanonicznym polem Y" — tak aby translacja była audytowalna, a zmiany nie wymagały rekompilacji silnika. Kod imperatywny jest zarezerwowany dla naprawdę złożonych transformacji, których tabela nie może wyrazić. Te same problemy heterogeniczności leżą u źródła szerszych wyzwań integracji danych w systemach obronnych, a zdyscyplinowana warstwa mapowania to najskuteczniejsza pojedyncza metoda ich łagodzenia.

Jednostki, współrzędne i czas

Trzy zadania normalizacji powodują więcej cichych, trudnych do zdiagnozowania błędów niż cokolwiek innego w potoku fuzji: konwersja jednostek, transformacja współrzędnych i wyrównanie czasu. Każde produkuje dane wyjściowe, które wyglądają wiarygodnie, będąc błędnymi.

Jednostki. Wybierz jeden kanoniczny układ jednostek — SI to konwencjonalny wybór: metry, metry na sekundę, radiany lub stopnie w sposób spójny — i konwertuj każdą przychodzącą wartość na granicy adaptera. Węzły stają się metrami na sekundę; stopy stają się metrami; kursy magnetyczne są konwertowane do rzeczywistych przy użyciu lokalnej deklinacji magnetycznej. Niebezpieczeństwo tkwi nie w arytmetyce konwersji, która jest trywialna, lecz w nieskonwertowanym polu, które prześlizguje się, ponieważ jednostka źródła była zakładana, a nie sprawdzana. Pole prędkości pozostawione w węzłach i traktowane jako metry na sekundę daje ślad poruszający się z mniej więcej dwukrotnie większą prędkością niż rzeczywista — ślad, który koreluje błędnie i jest trudny do wykrycia, ponieważ nie jest absurdalny, jedynie błędny.

Współrzędne. Czujniki raportują w geodezyjnych WGS84, MGRS, lokalnych siatkach tangencjalnych lub ramkach względnych platformy. Wszystkie muszą zostać przetransformowane do jednej kanonicznej ramki odniesienia przed korelacją. Używaj sprawdzonej biblioteki geodezyjnej, a nie samodzielnie napisanej trygonometrii; niezgodność datumu lub błąd znaku w transformacji współrzędnych wprowadza błędy pozycji rzędu dziesiątek metrów, które są operacyjnie istotne i notoryjnie trudne do prześledzenia do ich źródła.

Czas. Konwertuj każdy znacznik czasu do jednej autorytatywnej bazy — synchronizowany z GPS UTC jest standardem — i przechowuj go jako czas zdarzenia, nie czas przybycia. Starsze czujniki z zegarami swobodnie biegnącymi lub lokalnymi wymagają tabel korekt przesunięcia dla poszczególnych źródeł, a każdy znacznik czasu musi nieść jawną granicę niepewności. Obserwacje, których niepewność znacznika czasu przekracza skonfigurowany próg, powinny być oznaczane lub odrzucane przed dotarciem do korelatora, ponieważ obserwacja błędnie oznaczona czasowo wiąże się z niewłaściwym obiektem i korumpuje ślad, do którego dołącza.

Proweniencja: odpowiedzialność za dane wyjściowe fuzji

Gdy ślad fuzji jest prezentowany dowódcy, pytanie, które w końcu pada, brzmi: „skąd to pochodzi?" Jeśli odpowiedź brzmi „silnik fuzji to stwierdził", to nie wystarczy dla systemu, który informuje decyzje o ataku lub akredytacji. Proweniencja to łańcuch dowodów, który właściwie odpowiada na to pytanie: ten ślad został zbudowany z tych trzech obserwacji, wyprodukowały go te dwa czujniki, znormalizowały je te wersje adaptera, w tych czasach zdarzeń, niosąc te klasyfikacje.

Proweniencja musi być dołączana podczas normalizacji, a nie rekonstruowana później. Każda kanoniczna obserwacja niesie identyfikator źródła, typ czujnika, natywny identyfikator wiadomości, wersję adaptera i schematu oraz klasyfikację i zastrzeżenia źródła. Gdy silnik fuzji łączy obserwacje w ślad, akumuluje ich proweniencję zamiast ją odrzucać, tak że złożona klasyfikacja śladu jest najbardziej restrykcyjną spośród jego wejść, a lista źródeł jest sumą ich list. Zasada need-to-know jest następnie egzekwowana w czasie zapytania wobec tej złożonej klasyfikacji — nigdy podczas pozyskiwania, ponieważ ostateczna wrażliwość rekordu zależy od tego, z czym zostanie później połączony. Jest to ta sama dyscyplina odpowiedzialności, na której opierają się zdyscyplinowane potoki danych obronnych oparte na kolejkach komunikatów, aby każde zdarzenie było możliwe do prześledzenia w miarę przemieszczania się między etapami.

Ewolucja schematu bez zrywania zależności odbiorców

Model kanoniczny to długotrwały kontrakt. Przybywają nowe typy czujników, pojawiają się nowe istotne atrybuty, a model musi je absorbować bez wymuszania zsynchronizowanego ponownego wdrożenia każdego odbiorcy w systemie. Dyscyplina, która to umożliwia, to addytywna, wersjonowana zmiana.

Addytywna oznacza, że nowe pola są zawsze opcjonalne i domyślne, tak aby odbiorca, który nie rozumie nowego pola, po prostu je ignorował. Istniejące pola nigdy nie są repurposowane i nigdy nie są usuwane w miejscu — repurposowanie pola to najszybszy sposób na ciche skorumpowanie odbiorcy, który nie został zaktualizowany. Wersjonowana oznacza, że każda obserwacja jest oznaczona wersją schematu, pod którą została wyprodukowana, a każdy odbiorca deklaruje minimalną wersję schematu, której wymaga. Producent może zacząć emitować nowe opcjonalne pole w dniu jego dodania; odbiorcy adopują je według własnego harmonogramu.

Gdy naprawdę niezbędna jest zmiana łamiąca kompatybilność, jest ona wprowadzana jako nowa główna wersja schematu, działająca równolegle ze starą. Producenci emitują obie, lub shim translacyjny downgrade'uje nowe rekordy do starego kształtu, dopóki wszyscy odbiorcy nie zostaną zmigrowani; dopiero wtedy stara wersja jest wycofywana. Ta dyscyplina równoległego działania jest nieefektowna, ale pozwala sieci czujników rosnąć w sposób ciągły — tak jak dobrze zaprojektowana wojskowa sieć czujników IoT wdraża nowe typy węzłów — bez zatrzymywania potoku dla skoordynowanego przełączenia.

Wersjonowanie schematu przynosi też korzyści w testowaniu. Ponieważ każdy rekord niesie swoją wersję i proweniencję, możliwość odtwarzania może pobrać zarejestrowane surowe dane, przepuścić je przez nowy adapter lub wersję schematu i porównać kanoniczne dane wyjściowe z poznaną linią bazową. Zmiany adaptera są walidowane na rzeczywistych zarejestrowanych danych wejściowych, zanim kiedykolwiek dotkną danych na żywo, a regresje ujawniają się podczas odtwarzania, a nie w terenie.