Renderowanie symbologii w TAK: MIL-STD-2525 na mapach mobilnych

Mapa wojskowa jest tak użyteczna, jak symbole na niej umieszczone. Gdy operator TAK rzuca okiem na ekran urządzenia przenośnego przy słabym oświetleniu, kształt, kolor i wypełnienie każdej ikony muszą w ułamku sekundy przekazać przynależność, typ, szczebel i status – i muszą odpowiadać temu, co posterunek dowodzenia widzi na swojej ścianie. Tę zgodność ma gwarantować standard MIL-STD-2525, a jego poprawne renderowanie na ograniczonym urządzeniu mobilnym to pozornie prosty, lecz w rzeczywistości wymagający problem inżynieryjny. W artykule omawiamy, jak klienci TAK przekształcają zwięzły kod symbolu w pikselowo doskonałą, wydajną ikonę: kod identyfikacji symbolu, generowanie w stylu milsymbol, strategie buforowania utrzymujące wysoką liczbę klatek na sekundę w skali, niestandardowe zestawy ikon oraz dyscyplinę niezbędną do zachowania spójności z szerszym obrazem C2.

Kod identyfikacji symbolu: kontrakt danych

Wszystko w symbologii TAK zaczyna się od kodu identyfikacji symbolu – SIDC. SIDC to krótki, standaryzowany ciąg znaków, który jednoznacznie nazywa symbol wojskowy: jego przynależność (przyjazny, wrogi, neutralny, nieznany), wymiar bojowy (lądowy, powietrzny, morska powierzchnia, podwodny, kosmiczny), status (obecny lub przewidywany) oraz konkretny podmiot w zestawie symboli. W MIL-STD-2525C SIDC jest 15-znakowym ciągiem alfanumerycznym; w MIL-STD-2525D i ściśle powiązanym zestawie symboli NATO APP-6(D) jest to 20-znakowy kod numeryczny zorganizowany w strukturę par cyfr.

SIDC stanowi kontrakt między każdym systemem w obrazie. Serwer C2, stacjonarny pulpit i przenośny klient TAK, które uzgadniają dany SIDC, wyrenderują ten sam symbol – tę samą formę ramki, ten sam kolor wypełnienia, ten sam glif ikony. Dlatego właśnie po sieci przesyłany jest SIDC, a nie gotowy obraz. Przesyłanie bitmapy zamrażałoby symbol w jednym rozmiarze, jednym motywie i w interpretacji jednego klienta; przesyłanie kodu pozwala każdemu węzłowi końcowemu renderować natywnie przy własnej rozdzielczości i gęstości pikseli. Inżynieria symbologii na poziomie pulpitu – temat naszego towarzyszącego artykułu o MIL-STD-2525 w praktyce – to ta sama dyscyplina stosowana na drugim końcu przewodu.

Jak TAK przenosi SIDC przez Cursor on Target

TAK domyślnie nie transmituje surowego pola SIDC przy każdym zdarzeniu. Zamiast tego Cursor on Target (CoT) koduje przynależność i wymiar bojowy w atrybucie type zdarzenia – hierarchicznym ciągu z kropkami, np. a-f-G-U-C-I dla przyjaznej jednostki piechoty naziemnej. Wiodące a oznacza atom (obiekt rzeczywisty), drugi token to przynależność, a pozostałe tokeny schodzą w hierarchię 2525. Renderer mapuje ten typ CoT na kanoniczny SIDC przed generowaniem.

Gdy potrzebny jest bogatszy symbol – pełna wierność 2525D, modyfikatory szczebla lub konkretne podtypy podmiotów – system wytwarzający dodaje rozszerzenie szczegółów do zdarzenia CoT niosące jawny 20-znakowy kod. Klient TAK odczytuje rozszerzenie, gdy jest obecne, i wraca do wyprowadzenia kodu z typu CoT, gdy go nie ma. Praktyczna lekcja dla integratorów brzmi: nigdy nie zakładaj, że SIDC dotarł jako czyste pole – buduj krok normalizacji, który z dowolnego zdarzenia produkuje jeden kanoniczny kod.

Generowanie glifu: renderowanie w stylu milsymbol

Gdy kanoniczny SIDC jest już dostępny, klient musi zamienić go w piksele. Dominującym podejściem w ekosystemie TAK i w webowych klientach C2 jest silnik symbologii przyjmujący SIDC wraz z zestawem modyfikatorów i emitujący symbol wektorowy – biblioteka milsymbol jest najbardziej znaną otwartą implementacją tego modelu, a kilka rendererów TAK stosuje tę samą architekturę, nawet gdy korzysta z innej bazy kodu.

Silnik komponuje symbol z warstwowych prymitywów: ramki (zewnętrzny kształt kodujący przynależność – prostokąt dla przyjaznych, romb dla wrogich, kształt z prostymi narożnikami dla neutralnych, czterolistna koniczynka dla nieznanych), koloru wypełnienia, centralnego glifu ikony identyfikującego typ podmiotu oraz pierścienia opcjonalnych modyfikatorów tekstowych i graficznych – kresek szczebla powyżej ramki, wskaźnika obsady lub mobilności poniżej, kreskowania statusu dla podmiotów przewidywanych oraz pól swobodnego tekstu, takich jak unikalne oznaczenie lub formacja nadrzędna. Wyjściem jest zazwyczaj plik SVG, ponieważ wyjście wektorowe skaluje się płynnie w szerokim zakresie gęstości pikseli spotykanych na taktycznym sprzęcie z Androidem.

Od SVG do znacznika mapy

Mapa na żywo nie może sobie pozwolić na ponowne parsowanie i rasteryzowanie pliku SVG w każdej klatce. Standardowy potok rasteryzuje wygenerowany SVG dokładnie raz, w docelowym rozmiarze pikseli urządzenia, tworząc bitmapę, którą silnik mapy traktuje jako niezmienialny obraz znacznika. Bitmapa jest zakotwiczona w punkcie aktywnym symbolu – geometrycznym środku ramki, a nie dolnej krawędzi jak przy łezkowatej szpilce – dzięki czemu ikona siedzi dokładnie nad geolokalizacją podmiotu. Nieprawidłowe zakotwiczenie to częsty i subtelny błąd: symbol przesunięty o połowę swojej wysokości wygląda dobrze w stanie nieruchomym i zauważalnie odbiega od prawdy, gdy podmiot się porusza.

Wydajność w skali: pamięć podręczna jako architektura

Generowanie glifu MIL-STD-2525 jest obliczeniowo kosztowne – przechodzi przez zestaw symboli, komponuje kilka warstw, rozmieszcza modyfikatory tekstowe i rasteryzuje ścieżki wektorowe. Na średniej klasy wytrzymałym urządzeniu z Androidem wygenerowanie kilkuset unikalnych symboli przy uruchomieniu jest odczuwalne; regenerowanie ich przy każdym przesunięciu mapy uczyniłoby klienta bezużytecznym. Dlatego najważniejszą decyzją architektoniczną w mobilnym renderowaniu symbologii jest pamięć podręczna.

Kluczem pamięci podręcznej jest kanoniczny SIDC połączony z rozmiarem renderowania i wszelkimi modyfikatorami zmieniającymi piksele (szczebel, status, wskaźnik kierunku ruchu). Dwa znaczniki dzielące klucz dzielą jedną bitmapę. W realistycznym obrazie taktycznym liczba różnych symboli jest znacznie mniejsza niż liczba podmiotów: pięćdziesiąt przyjaznych znaczników piechoty sprowadza się do jednego buforowanego glifu. Dobrze dostrojony klient osiąga współczynnik trafień w pamięci podręcznej zdecydowanie powyżej dziewięćdziesięciu procent podczas normalnej pracy, co oznacza, że koszt generowania symbologii jest ponoszony raz i amortyzowany przez całą sesję.

Trzy kolejne techniki utrzymują pętlę renderowania w granicach budżetu klatek. Po pierwsze, wstępne renderowanie najczęstszych ramek – przyjaznych i wrogich symboli lądowych i powietrznych – przy uruchomieniu aplikacji, aby pierwsze rysowanie mapy nigdy nie było blokowane. Po drugie, grupowanie i redukcja przy niskim powiększeniu: gdy setki znaczników sprowadzają się do kilku pikseli ekranu, rysowanie ich wszystkich to stracona praca – gęste formacje należy zwinąć w jeden reprezentatywny symbol lub odznakę z licznikiem. Po trzecie, renderowanie przy stałych rozmiarach pikseli urządzenia i pozostawienie silnikowi mapy skalowania w obrębie pasma powiększenia, zamiast regenerowania bitmap przy każdym szczypaniu. Te zagadnienia dotyczące silnika map są lustrzanym odbiciem szerszych kompromisów renderowania omówionych w naszym artykule o renderowaniu map w czasie rzeczywistym dla wojskowych C2.

Niestandardowe ikony i niestandardowe podmioty

Nie każdy obiekt na mapie taktycznej ma czystą reprezentację MIL-STD-2525. Konkretna platforma BSP, nazwany środek cywilny, sprzęt inżynieryjny lub znacznik specyficzny dla jednostki może wymagać bespoke glifu. TAK obsługuje to za pomocą niestandardowych zestawów ikon – spakowanych kolekcji ikon bitmapowych wywoływanych przez ścieżkę względną zawartą w szczegółach CoT. Klient ładuje zestaw ikon, rozwiązuje ścieżkę i umieszcza bitmapę tak jak każdy inny obraz znacznika.

Niestandardowe ikony kupują elastyczność prezentacji za realną cenę: ścieżka bitmapy nie niesie żadnego strukturalnego znaczenia. SIDC 2525 mówi każdemu systemowi odbiorcy, że podmiot jest wrogi, powietrzny i przewidywany; ścieżka do custom/quadcopter.png nie mówi nic czytelnego maszynowo. Zdyscyplinowanym wzorcem jest utrzymywanie ważnego SIDC pod niestandardową prezentacją – kodowanie przynależności i wymiaru w typie CoT nawet gdy wyświetlana jest niestandardowa ikona – tak aby filtrowanie, alertowanie i rozumowanie między systemami nadal działały. Niestandardowa ikona jest wtedy kosmetycznym nadpisaniem na czytelnym maszynowo fundamencie, a nie jego zamiennikiem.

Spójność z obrazem C2

Najtrudniejsze problemy symbologii rzadko dotyczą jednego klienta; dotyczą uzgodnienia między wieloma. Operator z urządzeniem przenośnym i oficer dyżurny w posterunku dowodzenia muszą widzieć tę samą przynależność, tę samą ramkę i ten sam szczebel dla tego samego podmiotu – rozbieżność tutaj to nie wada kosmetyczna, lecz potencjalne ryzyko ostrzelania przez własne siły. Spójność opiera się na dwóch zasadach.

Po pierwsze, ustaw autorytatywny SIDC raz, w źródle, i nigdy nie wyprowadzaj go ponownie lokalnie. Jeśli aplikacja obserwatora wysunięcia i serwer C2 niezależnie próbują odgadnąć przynależność z niekompletnych danych, w końcu się rozejdą. System wytwarzający jest właścicielem kodu; każdy dalszy renderer traktuje go jako niezmienalne wejście.

Po drugie, renderuj ze wspólnej edycji standardu. Klient implementujący MIL-STD-2525C i serwer implementujący 2525D mogą generować subtelnie różne ramki i wypełnienia dla tego samego konceptualnego podmiotu, ponieważ zestawy symboli ewoluowały między edycjami. Gdy wdrożenie musi mieszać edycje – co jest powszechne, gdyż sprzęt w polu opóźnia standardy – wstaw warstwę translacji, która deterministycznie mapuje SIDC między edycjami. Tabela translacji, a nie doraźna logika per-klient, staje się jedynym miejscem, gdzie różnice edycji są uzgadniane, więc operator nigdy nie widzi wrogiego rombu tam, gdzie posterunek dowodzenia pokazuje przyjazny prostokąt.

Praca w trybie offline dodaje jeszcze jedno ograniczenie: pełny zestaw symboli i wszelkie niestandardowe zestawy ikon muszą być wstępnie załadowane na urządzenie, ponieważ klient TAK w środowisku z ograniczoną łącznością nie może pobierać brakującego glifu na żądanie. Zasoby symbologii podróżują razem z pakietem map offline, obok danych kafelków omówionych w naszym przewodniku po pakowaniu map offline dla zastosowań taktycznych.

Podsumowanie

Solidny mobilny potok symbologii to zatem krótka, zdyscyplinowana sekwencja: znormalizuj to, co niesie zdarzenie CoT, do jednego kanonicznego SIDC, sprawdź pamięć podręczną SIDC-plus-rozmiar przed wykonaniem jakiejkolwiek pracy, generuj z silnika w stylu milsymbol tylko przy braku trafienia, rasteryzuj raz i zakotwicz w punkcie aktywnym, inteligentnie grupuj przy niskim powiększeniu i uzgadniaj edycje z obrazem C2 przez jedną warstwę translacji. Każdy krok jest prosty w izolacji; wartość polega na konsekwentnym stosowaniu ich wszystkich, tak aby obraz pola walki z tysiącem podmiotów renderował się natychmiast i wyglądał identycznie od urządzenia przenośnego po posterunek dowodzenia.