ADatP-3 (STANAG 5500): formaty komunikatów tekstowych NATO — jak to działa

ADatP-3 — Allied Data Publication 3, ogłoszony w ramach STANAG 5500 — to system formatowania komunikatów tekstowych NATO, znany jako FORMETS: zbiór reguł, konstrukcji i słownika, za pomocą których buduje się każdy sformatowany komunikat NATO — od raportu sytuacyjnego po rozkaz zadań lotniczych. Około 400 komunikatów zbudowanych według tych reguł skatalogowano w APP-11 — 407 formatów komunikatów tekstowych w aktualnej edycji — a od 2008 roku każdy z nich istnieje również jako XML-MTF.

Czym jest ADatP-3 (STANAG 5500)?

Oficjalnie publikacja nosi tytuł NATO Message Text Formatting System (FORMETS) — Concept of FORMETS (CONFORMETS). Spotyka się zapisy ADatP-3 lub ADatP-03 — oba oznaczają tę samą Allied Data Publication. Aktualna wersja to Edition A Version 4, ogłoszona 1 lipca 2021 roku w ramach umowy STANAG 5500 Edition 8. Standardem opiekuje się Zespół ds. możliwości formatów komunikatów tekstowych NATO (MTF CaT), a ogłoszone edycje są wymienione w publicznej bazie Biura Standaryzacji NATO.

Najlepiej oddaje to podsumowanie samego NATO: FORMETS definiuje „składnię i reguły dotyczące reprezentacji uzgodnionych definicji pojęciowych (pól) oraz porządkowania tych pól w zdania (zestawy) i teksty komunikatów” i jest przeznaczony dla wszystkich sformatowanych komunikatów znakowych w systemach dowodzenia i sterowania NATO. Innymi słowy, ADatP-3 to gramatyka sformatowanych komunikatów NATO. Nie definiuje pojedynczych komunikatów — to zadanie katalogu APP-11 opisanego poniżej.

O trwałości tego rozwiązania decyduje cel projektowy. Sformatowany komunikat musi być czytelny dla operatora na gołym terminalu, przetwarzalny przez oprogramowanie na nowoczesnym serwerze i wystarczająco zwarty dla ograniczonego łącza taktycznego. Tekst znakowy rozdzielony ukośnikami spełnia wszystkie trzy wymagania — dlatego ruch ADatP-3 w 2026 roku nadal płynie obok wszystkiego innego w stosie standardów interoperacyjności NATO.

ADatP-3, APP-11, ADatP-34, APP-6: który dokument za co odpowiada

Te cztery publikacje są bez końca mylone — również w materiałach marketingowych dostawców — dlatego poniżej poprawne rozróżnienie, zweryfikowane względem publicznych rejestrów standaryzacji NATO:

Relacja dwóch pierwszych dokumentów jest precyzyjna. Zgodnie z opisem NISP samego NATO baza danych ADatP-03 zawiera wszystkie formaty komunikatów tekstowych pod kontrolą konfiguracyjną grupy roboczej ds. formatów komunikatów, a „uzgodnione MTF po opublikowaniu w wersji bazowej będą regularnie włączane do STANAG 7149, Katalogu Komunikatów NATO — APP-11”. ADatP-3 to gramatyka; APP-11 to słownik komunikatów napisanych tą gramatyką. ADatP-34 stoi poziom wyżej: NISP mówi programom i spiralom Federated Mission Networking (FMN), których standardów używać — w tym ADatP-3 i APP-11 — i sam nie definiuje żadnego komunikatu. Rolę NISP w doborze profili omawiamy w naszym artykule o strukturach danych ADatP-34, a stronę symboliki w porównaniu APP-6 i MIL-STD-2525.

Struktura komunikatu sformatowanego: zestawy, pola, separatory

Każdy komunikat MTF to sekwencja zestawów; każdy zestaw to identyfikator zestawu, po którym następują pola. Prawie całą składnię niosą trzy konwencje:

• Zestaw zaczyna się od identyfikatora — mnemoniki takiego jak MSGID, REF czy NARR — po którym następuje ukośnik.
• Pola są rozdzielone pojedynczym ukośnikiem /. Pole to zakodowany wpis o ustalonym formacie (grupa data-czas jak 011800Z, pozycja jak 4040N01100E) albo wpis z etykietą, np. LM:4040N01100E.
• Zestaw kończy się podwójnym ukośnikiem //. Długie zestawy są kontynuowane w kolejnych wierszach bez powtarzania identyfikatora.

Poniższy przykład — raport taktyczny w stylu publikowanej otwarcie dokumentacji USMTF, uproszczony dla czytelności — nie jest komunikatem operacyjnym — pokazuje wszystkie trzy:

MSGID/TACREP/CTF 124//
MAROP/011800Z/1/US/SUB/CL:WASHINGTON/NAME:SEAROVER/
LM:4040N01100E//
OPSUP/ACTTYP:ASW//
AIROP/020200Z/6/US/FTR/F15/TN:401/LM:4130N01000E/
CRS:180/SPD:600KPH/ALT:12000FT//

Niektóre zestawy ogólnego przeznaczenia powtarzają się w ruchu operacyjnym i administracyjnym: MSGID (identyfikacja komunikatu — typ, nadawca, numer seryjny), EXER i OPER (identyfikacja ćwiczenia i operacji), REF z towarzyszącym NARR (odniesienia i ich narracyjne rozwinięcie), SUBJ, POC oraz GENTEXT, który przenosi tekst ogólny pod specyfikatorem treści (GENTEXT/REMARKS/…//). Dokładny skład zestawów każdego komunikatu — które zestawy, w jakiej kolejności, jak często — jest zdefiniowany dla każdego komunikatu w APP-11.

Każdy zestaw w wpisie katalogu ma informację o wystąpieniu (obowiązkowe albo warunkowe względem innej treści) oraz o powtarzalności (ile razy może się pojawić — komunikat z trzema odniesieniami niesie trzy zestawy REF). Pola mają narzucone formaty, a dla pól kodowanych — zdefiniowane tabele wartości. Fizycznie zestawy są zapisywane liniowo (pola biegną po identyfikatorze, jak w przykładzie) albo jako wiersze kolumnowe — wiersze zadań rozkazu zadań lotniczych to klasyczny przykład kolumnowy: jeden wyrównany wiersz rozdzielony ukośnikami na każde zadanie lub lot. Całość to tekst wielkimi literami, zorientowany znakowo, w ograniczonym zbiorze znaków drukowalnych — właśnie dlatego potrafi przejść przez każdy terminal i każdy nośnik.

Wersje bazowe i edycje: na jaki katalog celuje wasz parser

„Na jakim ADatP-3 jesteście?” to pierwsze pytanie o interoperacyjność. Katalog komunikatów rozwija się przez wersjonowane linie bazowe, a wdrożona flota systemów rozłożona jest na dwa dziesięciolecia takich linii:

Tę oś czasu zestawiono z publicznej historii edycji publikowanej przez społeczność utrzymującą katalog oraz z publicznych rejestrów NATO. Dla twórców systemów istotne są dwie zmiany APP-11(E): WGS 84 stał się jedynym dozwolonym układem odniesienia dla danych pozycyjnych (opcja wyboru innego układu została usunięta), a wcześniej kodowane jednostki geograficzne stały się tekstem swobodnym rządzonym listami specyficznymi dla operacji. Poza katalogiem sam zbiór reguł przeszedł drogę od STANAG 5500 Edition 4 (era linii bazowej z 1999 roku) przez Edition 7 (2010) do aktualnej Edition 8, w ramach której w 2021 roku ogłoszono ADatP-03 Edition A Version 4.

Operacyjnie obowiązywającą wersję bazową ustala łańcuch taskowania — plan operacji, morskie lub lotnicze komunikaty taskowe albo specyfikacja spirali FMN, do której operacja się afiliuje. Profil operacji powietrznych FMN przeniósł np. obsługę komunikatów sformatowanych ze starych definicji ATO/ACO z Baseline 11 (udokumentowanych w starszych publikacjach sojuszniczych) do APP-11(E). Ta sama dyscyplina taskowania obowiązuje w operacjach łączy danych, gdzie OPTASK LINK zaopatruje całą sieć — zobacz, jak OPTASK LINK rządzi Link 16.

XML-MTF: ten sam komunikat w XML

Do 2008 roku komunikaty sformatowane istniały tylko jako tekst z ukośnikami. Od tego czasu katalog APP-11 zawiera także definicje XML-MTF ze świadomie przyjętym odwzorowaniem „jeden do jednego” między reprezentacją tekstową i XML — zachowana zostaje przewaga formy tekstowej w przepustowości, a jednocześnie dostępny staje się standardowy zestaw narzędzi XML. Część koncepcyjna ADatP-3 (CONFORMETS) specyfikuje rodzinę specyfikacji technicznych XML-MTF w postaci, w jakiej są one stosowane do MTF ADatP-03 w celu uzyskania równoważnych pochodnych formatów XML.

Dla inżynierów mają to dwa praktyczne skutki:

• Działa standardowy zestaw narzędzi XML. Schematy katalogu mogą napędzać walidujące parsery, ekstrakcję XPath i renderowanie XSLT zamiast autorskiego kodu obsługi komunikatów.
• Zarządzanie nazewnictwem. NATO zarejestrowało formalną przestrzeń nazw URN (urn:nato:) w RFC 7467, z artefaktami formatów komunikatów tekstowych jako nazwanym typem zasobu, dzięki czemu przestrzenie nazw XML i schematy otrzymują trwałe, bezkolizyjne identyfikatory.

Reprezentacja XML to także ścieżka utrzymania: bieżące prace nad katalogiem obejmują aktualizację XML do najnowszych reguł nazewnictwa i projektowania NATO oraz wprowadzenie wariantu JSON komunikatów. Jeśli pochodzisz ze świata TAK, zauważ, że XML-MTF to znacznie cięższa konwencja niż XML Cursor on Target wymieniany przez aplikacje świadomości taktycznej — opatrzone komentarzem przykłady CoT pokazują, jak minimalny jest ten format w porównaniu, a bramy między dwoma światami to osobny projekt integracyjny.

USMTF (MIL-STD-6040): amerykański odpowiednik i jego związek z NATO

Stany Zjednoczone prowadzą własny program formatowania komunikatów tekstowych — USMTF, rządzony przez MIL-STD-6040 (od 2008 roku serię MIL-STD-6040B, z katalogiem dostarczanym jako schematy XML-MTF) i zarządzany w ramach instrukcji Przewodniczącego Kolegium Połączonych Szefów Sztabów CJCSI 6241.04E (październik 2023). Instrukcja jednoznacznie określa odwzorowanie: odpowiednikiem reguł i konwencji MIL-STD-6040 w NATO jest ADatP-3, a APP-11 jest odpowiednikiem Katalogu Komunikatów USMTF. USMTF jest obowiązkowy dla wszystkich wymogów wymiany sformatowanych komunikatów znakowych w systemach USA, o ile umowa wielonarodowa wyraźnie nie stanowi inaczej.

Oba zbiory reguł są bliskie: publikowane wytyczne społeczności utrzymującej opisują je jako bardzo podobne, z jedynie drobnymi różnicami, a część komunikatów zharmonizowano między oboma katalogami. Wdrożone wersje bazowe USMTF (1998, 2000 i 2004 w systemach starszych generacji) są równoległe do historii linii bazowych NATO. Praktyczny wniosek dla realizatora: jeden silnik MTF może przetwarzać oba — ale musi nim sterować właściwa paczka katalogu, NATO APP-11 albo USMTF, dla wersji bazowej, którą partner faktycznie eksploatuje. I nie myl żadnego z nich z VMF (MIL-STD-6017) — binarnym, zorientowanym bitowo formatem dla łączy radiowych, a nie znakowym formatem komunikatów.

Jak oprogramowanie przetwarza MTF: parser, walidator, generator — i droga do obrazu C2

Sformalizowany ruch komunikatów to ładunek, nie transport: płynie wojskową obsługą komunikatów (MMHS, STANAG 4406), starszą retransmisją ACP 127 albo po prostu jako załącznik e-maila lub czatu — profile FMN wprost dopuszczają komunikaty sformatowane jako ładunek kilku transportów. Nasz towarzyszący tekst o wojskowej wymianie komunikatów NATO opisuje warstwę obsługi. To, co system C2 winien jest komunikatowi po jego nadejściu, to potok przetwarzania:

• Parsowanie sterowane gramatyką. Podziel tekst na zestawy po identyfikatorach, rozdziel pola po separatorze, połącz wiersze kontynuacji i zbuduj drzewo komunikatu. Gramatyka jest stabilna w całym katalogu, więc jeden parser obsługuje każdy typ komunikatu.
• Walidacja sterowana katalogiem. Rozpoznaj typ komunikatu z MSGID, po czym sprawdź kolejność zestawów, wystąpienia i powtarzalność, formaty pól i wartości kodowane względem definicji uzgodnionej wersji bazowej. Błędy trzeba raportować z pozycją zestawu i pola, bo nadawca musi je odnaleźć.
• Konwersja i mapowanie. Konwertuj między tekstem z ukośnikami a XML-MTF (jeden do jednego), a potem mapuj pola do modelu danych systemu. NATO utrzymuje w tym celu modele odniesienia — model informacyjny C2 NATO (NCIM) i specyfikacje MIP — a konkretne odwzorowania już istnieją w standardach: standard śledzenia sił własnych ADatP-36 definiuje mapowanie między komunikatowymi formatami tekstowymi FFI a NFFI, a profil mediacji FMN tłumaczy FFI MTF na model danych żołnierza pieszego.
• Generowanie przez ten sam katalog. W kierunku wychodzącym edytory formularzowe generowane z szablonów katalogu pilnują pól obowiązkowych i tabel wartości przy wpisie; generator serializuje do tekstu lub XML-MTF, waliduje pełny cykl i stempluje grupę data-czas, pierwszeństwo i adresowanie.

Ponieważ oboma kierunkami sterują te same definicje maszynowo czytelne, katalog jest w praktyce kontraktem między nadawcą a odbiorcą — dlatego wymiana komunikatów sformatowanych to pełnoprawny punkt testowy na dorocznym wydarzeniu interoperacyjności NATO, gdzie ćwiczy się profile FMN dla komunikatów sformatowanych lotniczych, morskich, cybernetycznych i ewakuacji medycznej. Przygotowanie do niego to osobna dyscyplina: zobacz nasz przewodnik po certyfikacji CWIX oraz to, jak udostępniamy wyniki testów koalicyjnych w Interoperability Dashboard.

Pułapki, które psują interoperacyjność MTF

Większość awarii komunikatów sformatowanych nie jest egzotyczna:

• Niedopasowanie wersji bazowej. Partner wciąż na APP-11(D) wysyła komunikat, który wasz walidator APP-11(E) odrzuca — albo przyjmuje, po cichu źle czytając wycofane pole. Przejście na APP-11(E) wycofało 40 komunikatów i uczyniło WGS 84 jedynym dozwolonym układem odniesienia; parser, który wciąż honoruje inne układy, przekłamie współrzędne. Zepnijcie wersję bazową w instrukcji łączności operacji i rozpoznawajcie wersję bazową nadawcy z identyfikacji komunikatu.
• Rozszerzenia narodowe. Narody dodają zestawy i pola w wariantach narodowych. Stabilna strategia to „przyjmij i oznacz”: parsuj to, co katalog zna, poddawaj kwarantannie i loguj to, czego nie zna, a różnicę pokazuj operatorowi — nigdy nie odrzucaj po cichu.
• Nadużywanie tekstu swobodnego. Wpychanie danych ustrukturyzowanych w prozę GENTEXT lub NARR, bo pola kodowane „się nie mieszczą”, niszczy przetwarzanie maszynowe u każdego odbiorcy. Jeśli informacja ma znaczenie dla automatyzacji, jej miejsce jest w polach kodowanych; jeśli nowe pole kodowane jest naprawdę potrzebne, to wniosek o zmianę do katalogu, a nie lokalny hack.
• Nieaktualne szablony edytora. Formularze nie przegenerowane z aktualnej wersji bazowej pozwalają operatorom pominąć nowe pola obowiązkowe; walidacja wywodzi się wtedy u partnera, a nie przy wpisie.