Architektura blue force tracking: raportowanie pozycji na dużą skalę

Blue force tracking brzmi jak rozwiązany problem: każda przyjazna jednostka raportuje, gdzie się znajduje, a mapa rysuje dla niej punkt. W ćwiczeniu plutonu z dwudziestoma radiostacjami ten opis jest trafny. W operacji na szczeblu korpusu z dziesiątkami tysięcy platform, pieszych żołnierzy i samolotów raportujących jednocześnie przez zdegradowane łącza radiowe naiwny projekt zawodzi – sieć nasyca się, przestarzałe punkty pozostają jakby aktualne, a mapa zamienia się w nieczytelną mieszaninę nakładających się symboli. Inżynieria systemu blue force tracking (BFT) dotyczy niemal wyłącznie luki między tymi dwiema skalami. Niniejszy artykuł omawia cały potok: jak raporty pozycji są generowane i pobierane, jak strojone są częstotliwości aktualizacji, jaki transport sieciowy je przenosi oraz jak tysiące przyjaznych śladów są użytecznie renderowane na wspólnym obrazie operacyjnym.

Czym jest blue force tracking i dlaczego skala stanowi najtrudniejszy problem

Blue force tracking to ciągłe zbieranie, transportowanie, dekonfliktowanie i wyświetlanie pozycji jednostek przyjaznych na wspólnej mapie. Jego cel operacyjny jest dwojaki: unikanie bratobójczego ognia – dowódca, który widzi dokładnie, gdzie znajdują się siły przyjazne, nie skieruje na nie ognia – oraz skoordynowany manewr, w którym jednostki dostosowują ruch do bieżącej dyspozycji sąsiednich elementów. BFT to warstwa sił przyjaznych w COP, a zarazem warstwa, którą użytkownicy oglądają najczęściej.

Skala dominuje w projektowaniu dlatego, że obciążenie BFT rośnie jednocześnie na dwóch osiach. Liczba raportujących podmiotów rośnie wraz z wielkością sił, a częstotliwość raportowania rośnie wraz z tempem operacji. Obraz garnizonowy w czasie pokoju może obejmować kilkaset powoli aktualizowanych śladów; operacja o wysokiej intensywności może dotyczyć dziesiątek tysięcy podmiotów, z których wiele porusza się na tyle szybko, że wymaga aktualizacji częstszych niż co pięć sekund. Iloczyn tych dwóch liczb to wskaźnik raportów, które system musi pobierać, transportować i renderować, a może się on różnić o cztery rzędy wielkości między przypadkiem łatwym a trudnym.

Każda z poniższych decyzji architektonicznych – projektowanie schematu, adaptacyjna kontrola częstotliwości, wybór transportu, filtrowanie serwerowe, strategia renderowania – istnieje po to, aby system był użyteczny na najwyższym poziomie bez nadmiernego inżynierowania dla niskiego. Przewodnim motywem wszystkich jest to, że raport pozycji to mała, samokorygująca się, idempotentna rzecz, a architektura BFT traktująca go w ten sposób będzie się skalować, podczas gdy taka, która traktuje każdy raport jako cenny, nie będzie.

Pobieranie raportów pozycji i kanoniczny schemat śladu

Raport pozycji to mała wiadomość: co najmniej identyfikator jednostki, szerokość i długość geograficzna WGS84 oraz znacznik czasu. Raporty produkcyjne dodają kurs, prędkość, wysokość, czas wygaśnięcia, szczebel lub przynależność jednostki oraz etykietę klasyfikacji. Pierwszą decyzją architektoniczną jest zdefiniowanie jednego kanonicznego schematu śladu dla całego systemu i przetłumaczenie każdego źródła wejściowego na ten schemat na krawędzi.

Źródła są niejednorodne. Piesi żołnierze używający ATAK i urządzeń końcowych emitują zdarzenia Cursor on Target. Pojazdy z systemami zarządzania walką emitują NFFI (NATO Friendly Force Information) lub ich krajowe odpowiedniki. Samoloty mogą raportować przez Link 16 lub specyficzne dla platformy łącza danych. Każde z nich ma własny zestaw pól, konwencję współrzędnych i kadencję aktualizacji. Zadaniem adaptera pobierającego jest walidacja wiadomości przychodzącej, konwersja współrzędnych i jednostek, przypisanie lub zachowanie stabilnego UID oraz emisja kanonicznego rekordu śladu do warstwy fuzji i przechowywania.

Bezwzględna reguła jest taka, że surowe formaty źródłowe nigdy nie mogą propagować się poza adapter. Jeśli zdarzenie CoT, wiadomość NFFI i ramka zastrzeżonego BMS dotrą do magazynu śladów w ich natywnej formie, każdy konsument dalszego przetwarzania – fuzja, filtrowanie, renderowanie – musi rozumieć wszystkie trzy, a system staje się niemożliwy do rozszerzenia lub debugowania. Jeden kanoniczny schemat wchodzi, wiele rendererów wychodzi.

Stabilna tożsamość i deduplikacja

Ta sama fizyczna platforma czasami raportuje przez więcej niż jedną ścieżkę – pojazd, którego załoga nosi również EUD, generuje na przykład dwa ślady dla jednego obiektu. Warstwa pobierająca musi przypisywać i zachowywać stabilny UID, tak aby silnik fuzji mógł rozpoznać i połączyć je w jeden autorytatywny ślad zamiast malować dwa punkty odległe o kilka metrów. Gdy globalny UID nie jest dostępny, deduplikacja opiera się na korelacji przestrzenno-czasowej: raporty w małym promieniu i oknie czasowym, ze spójnym kursem i prędkością, są traktowane jako ten sam podmiot. Właściwa identyfikacja przy pobieraniu zapobiega całej klasie problemów z fantomowymi śladami w dalszych etapach przetwarzania.

Strojenie częstotliwości aktualizacji: największy mechanizm kontroli obciążenia

Najskuteczniejszym sposobem kontroli obciążenia sieci BFT jest kontrolowanie częstotliwości raportowania przez każdy podmiot. Naiwne systemy używają stałego interwału – każda jednostka transmituje co N sekund niezależnie od tego, co robi. Marnuje to większość transmisji na jednostki stacjonarne, których pozycja nie uległa zmianie, jednocześnie będąc zbyt wolnym dla szybkich obiektów, których pozycja zmienia się znacząco między raportami.

Adaptacyjne, zdarzeniowe raportowanie rozwiązuje oba problemy. Każde urządzenie końcowe samo decyduje, kiedy raportować na podstawie własnego ruchu: emituje nowy raport, gdy przemieszczenie od ostatniego raportu przekroczy próg odległości, gdy zmiana kursu przekroczy próg kątowy lub gdy upłynie maksymalny cichy interwał (bicie serca) bez ruchu. Zatrzymany pojazd raportuje wtedy raz na bicie serca – być może co 60 do 120 sekund – wyłącznie w celu potwierdzenia, że nadal działa, podczas gdy ten sam pojazd poruszający się z prędkością raportuje co kilka sekund, ponieważ stale przekracza próg przemieszczenia.

Efekt przepustowości jest znaczny. W mieszanych siłach, w których większość jednostek jest statyczna lub porusza się powoli w danym momencie, adaptacyjne raportowanie powszechnie redukuje przesyłany wolumen raportów o 60 do 80 procent w porównaniu z raportowaniem ze stałą częstotliwością, bez utraty wierności taktycznej – szybkie, ważne obiekty nadal aktualizują się często, a stacjonarne po prostu przestają marnować łącze. Typowe bazowe kadencje przed adaptacją to 30 do 120 sekund dla piechoty pieszej, 10 do 30 sekund dla pojazdów oraz 1 do 5 sekund dla samolotów i szybkich obiektów.

Transport sieciowy dla raportów pozycji

Na taktycznej krawędzi dominującym transportem jest Cursor on Target przesyłany przez multicast UDP w sieci radiowej mesh. Multicast jest właściwą prymitywą, ponieważ jedna transmisja dociera do każdego odbiorcy w segmencie – gdy pojazd nadaje swoją pozycję, każdy inny węzeł w zasięgu otrzymuje ją bez konieczności indywidualnego adresowania przez nadawcę każdego równorzędnego węzła. Na ograniczonej przepustowością sieci taktycznej ta efektywność jeden-do-wielu jest decydująca.

Multicast UDP wymienia niezawodność na wydajność: nie ma retransmisji ani gwarancji dostarczenia. Dla BFT jest to właściwa wymiana, właśnie dlatego że raporty są idempotentne. Utracony raport jest zastępowany przez następny w ciągu jednego interwału raportowania, więc warstwa aplikacji powinna tolerować utratę, a nie z nią walczyć. Agresywna retransmisja danych pozycji jest antywzorcem – pochłania rzadką przepustowość, aby dostarczyć informacje, które są już przestarzałe w momencie dotarcia.

Gdy istnieje łącze backhaul, węzły krawędziowe przesyłają również raporty przez TCP do serwera TAK, który agreguje lokalny obraz i przekazuje go do wyższych szczebli i innych serwerów przez federację. Na szczeblu brygady i powyżej agregacja zazwyczaj przenosi się do brokera publish/subscribe lub magistrali komunikatów, która rozdziela ślady subskrybentom według tematu. Transport zmienia zatem charakter w miarę wspinania się po szczeblach: stratny multicast na krawędzi dla wydajności, niezawodne połączenia punkt-punkt i pośredniczone pub/sub wyżej, gdzie łącza są grubsze i ważniejsza jest kompletność.

Skalowanie obrazu: filtrowanie, delty i renderowanie

Efektywny transport raportów to tylko połowa problemu. Drugą połową jest prezentowanie dziesiątek tysięcy śladów operatorowi bez nasycania ani łącza sieciowego klienta, ani jego renderera. Trzy techniki zastosowane razem sprawiają, że jest to wykonalne.

Serwerowe filtrowanie obszarowe i szczeblowe. Autorytatywny magazyn śladów znajduje się na serwerze, a każdy klient otrzymuje tylko ślady dla niego istotne – te w jego geograficznym obszarze zainteresowania i dozwolone przez jego poziom uprawnień i szczebel. Punkt dowodzenia kompanii nie potrzebuje i nie powinien otrzymywać pełnego obrazu dywizji. Indeksowanie przestrzenne (quadtree lub siatka geohash nad magazynem śladów) sprawia, że zapytanie „daj mi każdy przyjazny ślad w tym prostokącie ograniczającym" jest tanie, a zestaw wyników jest ograniczony przez widok operatora, a nie przez łączną wielkość sił. To mechanizm, który utrzymuje przepustowość na klienta w przybliżeniu stałą nawet w miarę wzrostu globalnej liczby śladów.

Aktualizacje przyrostowe (delta) przez publish/subscribe. Klienci powinni subskrybować strumień zmian zamiast odpytywać o pełny stan. Po początkowej migawce widocznego obszaru serwer wypycha tylko delty – nowe ślady, aktualizacje pozycji i usunięcia – przez WebSocket lub kanał pub/sub. Odpytywanie o pełny stan na dużą skalę to klasyczny błąd: zmusza serwer do serializowania całego widocznego obrazu w każdym interwale, mnożąc obciążenie przez liczbę klientów. Delty utrzymują stały ruch proporcjonalny do rzeczywistego wskaźnika zmian, a nie do rozmiaru obrazu.

Grupowanie po stronie klienta i renderowanie GPU. Po stronie wyświetlania rysowanie każdego śladu jako elementu DOM zawodzi na długo przed tysiącem znaczników. Produkcyjne klienty COP renderują przy użyciu sprzętowo przyspieszonego WebGL – Cesium, MapLibre lub niestandardowej warstwy – co pozwala rysować dziesiątki tysięcy symboli na klatkę z interaktywnymi prędkościami. Gęste obszary są grupowane w symbole zbiorcze, które rozwijają się w miarę jak operator powiększa widok, więc obszar zgrupowania brygady wyświetla się jako jeden klaster z licznikiem przy powiększeniu teatru i rozdziela się na poszczególne platformy przy powiększeniu taktycznym. Grupowanie zarządza zarówno kosztem renderowania, jak i czytelnością dla człowieka jednocześnie.

Nieaktualność, ostatnia znana pozycja i uczciwy wyświetlacz

Przyjazny ślad jest tylko tak dobry, jak jego świeżość, a wyświetlacz musi mówić prawdę na ten temat. Każdy ślad nosi czas wygaśnięcia ustawiony podczas generowania raportu. Gdy ten czas upłynie bez nowego raportu, renderer musi widocznie zdegradować ślad – przyciemnić go, dodać przerywaną aureolę lub przekonwertować na jawny znacznik ostatniej znane pozycji z etykietą wieku – a po dłuższym interwale usunąć go całkowicie z aktywnego obrazu.

Ma to znaczenie, ponieważ symbol narysowany z pełną jasnością sugeruje bieżące ustalenie pozycji. System BFT malujący godzinną pozycję jak gdyby była aktualna jest nie tylko bezużyteczny; aktywnie wprowadza dowódcę w błąd, skłaniając go do ufania punktowi, który może znajdować się o kilometry od rzeczywistości. Jawny znacznik „ostatnio widziany 47 minut temu" jest znacznie bezpieczniejszy niż pewny, ale błędny punkt. Uczciwa obsługa nieaktualności to wymóg poprawności, a nie kosmetyczna preferencja, i należy ona do warstwy renderowania każdego projektu BFT.

Złożenie potoku w całość

Widziana od końca do końca architektura BFT to lejek, który rozszerza się i zwęża we właściwych miejscach. Rozszerza się przy pobieraniu, przyjmując wiele niejednorodnych źródeł i normalizując je do jednego schematu. Zwęża się na krawędzi przez adaptacyjne raportowanie, transmitując tylko to, co znacząco się zmieniło. Jedzie na tolerującym utratę transporcie multicastowym, który wykorzystuje idempotencję danych pozycji. Rozszerza się ponownie na serwerze w autorytatywny, przestrzennie indeksowany magazyn, a następnie zwęża na klienta przez filtrowanie obszarowe i szczeblowe oraz strumieniowanie delt. Na koniec renderuje przy użyciu akceleracji GPU, grupowania i uczciwych wskazówek nieaktualności, tak aby operator widział czytelny, godny zaufania obraz sił przyjaznych niezależnie od tego, czy siły liczą setki czy dziesiątki tysięcy.