Każdy wojskowy ekran mapowy w NATO renderuje te same podstawowe rzeczy: kompanię własnej piechoty, wrogi batalion pancerny, nieznany kontakt nawodny, planowany rejon działań ogniowych. Sposób, w jaki te rzeczy wyglądają, regulują dwa standardy — natowski APP-6 i amerykański MIL-STD-2525. Mają wspólnego przodka, pokrywają się w mniej więcej dziewięćdziesięciu pięciu procentach i rozchodzą się dokładnie w tych miejscach, które psują wasz renderer. Jeśli budujecie oprogramowanie C2 dla odbiorcy koalicyjnego, prędzej czy później wypuścicie kod, który musi mówić oboma. Oto inżynierskie porównanie: korzenie, krajobraz wersji, kod identyfikacji symbolu, zestawy symboli, amplifikatory, renderowanie i przypadki brzegowe konwersji, które dają się we znaki.

1. dwa standardy, jeden przodek

MIL-STD-2525 to standard Departamentu Obrony USA dotyczący wspólnej symboliki bojowej. APP-6 — Allied Procedural Publication 6, promulgowany w ramach STANAG 2019 — to standard NATO. Wywodzą się z tego samego wysiłku z lat 90., aby dać siłom połączonym i koalicyjnym jeden wizualny język wspólnego obrazu operacyjnego, i przez większość swojej historii były celowo utrzymywane w synchronizacji. MIL-STD-2525A i APP-6A były rodzeństwem; 2525B zrównano z APP-6B. Dokument amerykański zwykle przodował, NATO ratyfikowało ściśle pasującą wersję rok lub dwa później, a systemy narodowe wdrażały tę, której wymagał ich łańcuch akredytacji.

Rozejście się, które ma znaczenie, nastąpiło na granicy pokoleń. USA opublikowały MIL-STD-2525C w 2008 roku jako dojrzały stan końcowy pierwotnej architektury. NATO przejęło następnie inicjatywę nad przeprojektowaniem nowej generacji, a obie społeczności wspólnie opracowały nowy model, który ukazał się jako MIL-STD-2525D (2014) i APP-6(D) (2017). Tak więc linia rodowa się odwraca: dla starszej generacji przodowały USA; dla nowoczesnej generacji standardy ponownie zbiegły się we wspólnie zaprojektowanym rozwiązaniu. Praktyczną konsekwencją jest to, że 2525D i APP-6(D) są znacznie bliższe równoważności bajt po bajcie niż jakakolwiek wcześniejsza para — ale wciąż macie w terenie dużą zainstalowaną bazę systemów 2525C i APP-6(B), które używają całkowicie odmiennej struktury kodu.

2. krajobraz wersji

Traktujcie te standardy jako dwie rodziny. Rodzina starsza to MIL-STD-2525B/2525C oraz APP-6(A)/(B): 15-znakowy kod identyfikacji symbolu, hierarchiczny schemat liter i cyfr oraz katalog symboli zorganizowany wokół wymiarów pola walki. Rodzina nowoczesna to MIL-STD-2525D/2525E oraz APP-6(D): 20-cyfrowy kod numeryczny, płaska architektura zestawów symboli oraz znacznie rozszerzony katalog encji.

Semantycznie zgodne pary to 2525C ↔ APP-6(B) po stronie starszej oraz 2525D ↔ APP-6(D) po stronie nowoczesnej. 2525E (2022) rozszerza model nowoczesny o dodatkowe zestawy symboli — w szczególności bogatsze encje kosmiczne, cyberprzestrzenne i bezzałogowe — bez naruszania struktury 20-cyfrowej, dzięki czemu renderer APP-6(D) poprawnie odczytuje większość kodów 2525E i po prostu cofa się do nieznanej encji dla nowych. Wiedza o tym, którą parę wdraża dany system partnera, to pierwsze pytanie, na które trzeba odpowiedzieć przy każdej integracji, ponieważ decyduje ono o tym, czy wykonujecie czyste mapowanie pole-na-pole, czy translację międzypokoleniową.

3. struktura SIDC

Kod identyfikacji symbolu (SIDC) to serce obu standardów i zmienił się on całkowicie między pokoleniami. Starszy SIDC to ciąg 15-znakowy. Pozycja 1 to schemat kodowania, pozycja 2 to przynależność (przyjazny, wrogi, neutralny, nieznany, plus warianty zakładany/podejrzany), pozycja 3 to wymiar pola walki (powietrze, ląd, powierzchnia morza, pod powierzchnią, kosmos, SOF), pozycja 4 to status. Pozycje od 5 do 10 to identyfikator funkcji — hierarchiczny kod literowy, w którym każdy znak zawęża encję, więc pancerno-zmechanizowany pododdział piechoty i ogólny pododdział piechoty współdzielą prefiks i różnią się znakami końcowymi. Pozostałe pozycje niosą modyfikatory symbolu oraz wskaźnik szczebla. Jest zwarty i czytelny dla człowieka, gdy się go zapamięta, ale jest sztywny: nie zostaje miejsca, by dodać nowe encje bez ponownego użycia slotów.

Nowoczesny SIDC to 20 cyfr, czysto numeryczny i pozycyjny. Cyfry 1–2 to wersja. Cyfra 3 to kontekst tożsamości standardowej (rzeczywistość, ćwiczenie, symulacja). Cyfry 5–6 wybierają zestaw symboli — najważniejsze pojedyncze pole, ponieważ kieruje wszystkim, co następuje po nim. Cyfra 7 niesie status, 8 wskaźnik dowództwa/grupy zadaniowej/pozoranta, 9–10 deskryptor amplifikatora. Cyfry 11–16 to encja / typ encji / podtyp encji — trzypoziomowa hierarchia numeryczna. Cyfry 17–18 i 19–20 to dwa sloty modyfikatorów. Kluczowy wniosek z perspektywy parsera: nowoczesny kod to rekord o stałych przesunięciach, a nie parsowany ciąg, co czyni go znacznie łatwiejszym do walidacji i znacznie trudniejszym do nadużycia niż starsza hierarchia identyfikatora funkcji.

Kluczowy wniosek: Kod 15-znakowy i kod 20-cyfrowy to nie dwa kodowania tych samych danych — to dwa różne modele danych. Starszy SIDC łączy przynależność, wymiar i funkcję w jeden hierarchiczny ciąg; nowoczesny SIDC rozdziela tożsamość standardową, zestaw symboli i numeryczną hierarchię encji na niezależne pola o stałej szerokości. Nie da się jednego przepisać na drugie wyrażeniem regularnym. Potrzebujecie tabeli przeglądowej, a to właśnie ta tabela jest miejscem, gdzie mieszka każdy błąd konwersji.

4. zestawy symboli i encje

W modelu nowoczesnym zestaw symboli (cyfry 5–6) jest kluczem dyspozytorskim. Zdefiniowane zestawy obejmują powietrze, pocisk powietrzny, kosmos, pocisk kosmiczny, pododdział lądowy, ludność cywilną na lądzie, sprzęt lądowy, instalację lądową, środki kontroli, powierzchnię morza, pod powierzchnią morza, działania minowe, aktywności, wywiad radioelektroniczny oraz kilka zestawów bezzałogowych i cyberprzestrzennych dodanych w późniejszych rewizjach. Zestaw symboli określa jednocześnie geometrię ramki, prawidłowe kody encji oraz dostępne pola amplifikatorów. Symbol pododdziału lądowego używa rodziny ramek prostokątnych/czworobocznych; symbol nawodny używa ramki w kształcie kadłuba statku; symbol powietrzny używa półzaokrąglonej ramki „powietrznej”.

To czystsze rozdzielenie niż starsze pole wymiaru pola walki, które łączyło kształt ramki i domenę encji. W modelu nowoczesnym ramka pochodzi z przynależności plus zestawu symboli, podczas gdy ikona wewnątrz pochodzi z hierarchii encji. Ta ortogonalność jest dokładnie tym, co czyni renderer sterowany danymi praktycznym: budujecie ramkę z garstki danych wejściowych i niezależnie wyszukujecie glif ikony z cyfr encji. To ta sama dyscyplina rozdzielenia odpowiedzialności, którą opisujemy w naszej szczegółowej analizie inżynierii symboliki z MIL-STD-2525.

5. amplifikatory i modyfikatory

Glif to tylko połowa symbolu wojskowego. Druga połowa to zestaw amplifikatorów — tekstowe i graficzne dekoracje umieszczane wokół ramki, w standardzie oznaczone polami od A do Y. Pole B to wskaźnik szczebla lub mobilności rysowany nad ramką (kropki drużyny/sekcji, kreski plutonu/kompanii/batalionu, znaki X brygady/dywizji). Pole T to unikalne oznaczenie — nazwa lub numer pododdziału. Pole H to informacja dodatkowa, pole W to grupa data-czas, pole J to ocena wiarygodności, pole C to liczebność, pole Q to strzałka kierunku ruchu, pole AA to wskaźnik specjalnego dowództwa sztabowego.

Status (obecny a przewidywany/planowany) renderowany jest jako ramka ciągła a przerywana — drobny szczegół, który ogromna liczba rendererów błędnie obsługuje, ponieważ musi on dotyczyć obrysu ramki bez wpływania na wypełnienie ani ikonę. Wskaźnik dowództwa wysuwa linię sztabową w dół od ramki; wskaźnik grupy zadaniowej otacza ramkę nawiasem; wskaźnik pozoranta/demonstracji dodaje przerywane przedłużenie. Szczebel, dowództwo, grupa zadaniowa i status to niezależne flagi w nowoczesnym SIDC, co oznacza, że wasz silnik amplifikatorów musi je komponować, a nie przełączać się na podstawie pojedynczego wyliczonego typu symbolu.

6. renderowanie

W praktyce niemal nikt nie rysuje tych symboli z surowych plików PDF standardów. Ekosystem webowy ustandaryzował się na milsymbol — otwartoźródłowej bibliotece JavaScript utrzymywanej przez Månsa Beckmana, która generuje symbol wojskowy jako wbudowane SVG bezpośrednio z SIDC plus obiektu opcji z wartościami amplifikatorów. Podajecie jej 20-cyfrowy (lub starszy 15-znakowy) kod oraz zestaw wartości pól, a ona zwraca warstwowe SVG: ścieżkę ramki, wypełnienie przynależności, ikonę encji oraz otaczający tekst i grafikę amplifikatorów, każde jako oddzielny element, który możecie stylować.

To warstwowość czyni to szybkim. Ponieważ ramka, wypełnienie, ikona i amplifikatory to niezależne warstwy SVG, renderer może buforować kosztowne części (geometrię ikony encji) i przeliczać tylko tanie części (amplifikatory tekstowe, kolor), gdy ślad się aktualizuje. W skali C2 — tysiące śladów aktualizujących się kilka razy na sekundę — nie regenerujecie całego symbolu przy każdej aktualizacji położenia; transformujecie buforowaną grupę SVG i przepisujecie tylko zmieniony tekst amplifikatora. Połączenie wyjścia SVG milsymbolu z warstwą symboli canvas lub WebGL to standardowe podejście do renderowania map w czasie rzeczywistym na ruchomym wspólnym obrazie operacyjnym. milsymbol obsługuje zarówno style ramek 2525, jak i APP-6 za pomocą jednej opcji, co jest najtańszym sposobem zaspokojenia klienta koalicyjnego, który chce natowskiego wariantu ramki, a nie amerykańskiego.

7. pułapki wzajemnej konwersji

Mapowanie starszego 15-znakowego SIDC na nowoczesny 20-cyfrowy kod to konwersja, którą napiszecie, i jest ona stratna w obu kierunkach. Pole przynależności mapuje się wystarczająco czysto — przyjazny, wrogi, neutralny, nieznany mają bezpośrednie odpowiedniki — ale tożsamości zakładany-przyjazny i podejrzany oraz warianty ćwiczebne joker/faker nie wszystkie przetrwają podróż w obie strony w nienaruszonym stanie. Wymiar pola walki musi zostać wyrażony na nowo jako zestaw symboli, a to nie jest relacja jeden-do-jednego: starszy wymiar „ląd” rozkłada się w modelu nowoczesnym na pododdział lądowy, sprzęt lądowy i instalację lądową, więc nie możecie wywnioskować docelowego zestawu symboli z samej cyfry wymiaru — musicie zbadać identyfikator funkcji.

Hierarchia identyfikatora funkcji to najgorszy winowajca. Kilka starszych encji nie ma dokładnego nowoczesnego odpowiednika, a kilka nowoczesnych encji (zwłaszcza nowsze zestawy cyberprzestrzenne i bezzałogowe) nie ma w ogóle starszego kodu, więc degradują się do ogólnej encji w drodze w dół. Szczebel zwykle przetrwa; wskaźniki mobilności czasami nie. Bezpieczną postawą inżynierską jest przechowywanie oryginalnego SIDC dosłownie jako zapisanego atrybutu i traktowanie skonwertowanego kodu jako pochodnej wyznaczanej w czasie renderowania, nigdy jako systemu źródłowego — w ten sposób przyszła korekta waszej tabeli mapowania renderuje cały obraz na nowo bez migracji danych.

8. wybór dla waszego produktu C2

Decyzja rzadko dotyczy tego, który standard jest „lepszy” — kodują tę samą doktrynę. Chodzi o to, kto konsumuje wasze wyjście. Jeśli wasi operatorzy i partnerzy koalicyjni używają systemów NATO, renderujcie domyślnie wariant ramki APP-6; jeśli ściśle integrujecie się z programami USA, ustawcie domyślnie MIL-STD-2525. Tutaj liczy się też zwalnialność: sama symbolika jest niejawna jedynie w niewielkim stopniu, ale encje, którymi ją wypełniacie, oraz warianty SIDC, które obsługujecie, powinny śledzić to, co faktycznie renderują akredytowane systemy waszych partnerów, abyście nie wysłali symbolu, który pojawi się jako pusty na ekranie sojusznika.

Wzorzec, który dobrze się starzeje, to strategia podwójnego renderowania: przechowujcie każdy ślad z jego nowoczesnym 20-cyfrowym SIDC jako kanoniczną tożsamością, trzymajcie flagę stylu ramki (2525 a APP-6) jako preferencję wyświetlania i pozwólcie warstwie symboli emitować dowolny z nich na żądanie. Ponieważ milsymbol przełącza style ramek z poziomu jednej opcji, przyrostowy koszt obsługi obu jest bliski zeru, gdy wasz model danych jest czysty. Zbudujcie potok symboli jako cienką, dobrze przetestowaną warstwę mapowania nad pojedynczym kodem kanonicznym, traktujcie tabele konwersji jako wersjonowane dane, a nie zaszyte na sztywno reguły, a wchłoniecie kolejną rewizję — 2525F, APP-6(E) — jako aktualizację tabeli zamiast przepisywania. Szerszy kontekst architektoniczny znajdziecie w naszym kompletnym przewodniku po systemach C2.