ADatP-3 (STANAG 5500): formatele de mesaje text ale NATO, explicate

ADatP-3 — Allied Data Publication 3, promulgată prin STANAG 5500 — este sistemul NATO de formatare a mesajelor text, cunoscut ca FORMETS: regulile, construcțiile și vocabularul cu care se construiește fiecare mesaj formatat al NATO, de la un raport de situație până la ordinul de misiuni aeriene. Cele aproximativ 400 de mesaje construite după aceste reguli sunt catalogate în APP-11 — 407 Message Text Formats în ediția curentă — iar din 2008 fiecare dintre ele există și ca XML-MTF.

Ce este ADatP-3 (STANAG 5500)?

Formal, publicația poartă titlul NATO Message Text Formatting System (FORMETS) — Concept of FORMETS (CONFORMETS). O veți găsi scrisă ADatP-3 sau ADatP-03; ambele desemnează aceeași Allied Data Publication. Versiunea curentă este Edition A Version 4, promulgată la 1 iulie 2021 în cadrul acordului acoperitor STANAG 5500 Edition 8. Standardul este întreținut de echipa de capabilități NATO pentru formate de mesaje text (MTF CaT), iar edițiile promulgate sunt listate în baza de date publică a Oficiului de Standardizare al NATO.

Ceea ce specifică standardul se citează cel mai bine din rezumatul NATO însuși: FORMETS oferă „sintaxa și regulile care guvernează reprezentarea definițiilor conceptuale convenite (câmpurile) și aranjarea acestor câmpuri în propoziții (seturi) și texte de mesaj” și este destinat tuturor mesajelor formatate orientate pe caractere din comandă și controlul NATO. Cu alte cuvinte, ADatP-3 este gramatica mesageriei formatate NATO. El nu definește mesajele individuale — aceasta este sarcina catalogului APP-11 descris mai jos.

Obiectivul de proiectare explică longevitatea sa. Un mesaj formatat trebuie să fie lizibil pentru un operator pe un terminal minimal, analizabil de software pe un server modern și suficient de compact pentru o legătură tactică limitată. Textul orientat pe caractere, delimitat prin bare oblice, satisface pe toate trei — de aceea traficul ADatP-3 curge și în 2026, alături de tot restul stivei standardelor de interoperabilitate NATO.

ADatP-3, APP-11, ADatP-34, APP-6: care standard este care

Aceste patru sunt confundate constant — inclusiv în marketingul furnizorilor — iată deci corespondența corectă, verificată împotriva registrilor publici de standardizare ai NATO:

Relația dintre primele două este precisă. Conform propriei descrieri NISP a NATO, baza de date ADatP-03 conține toate formatele de mesaje text sub controlul de configurație al grupului de lucru pentru formate de mesaje, iar „MTF-urile convenite, odată publicate într-o linie de bază, vor fi inserate regulat în STANAG 7149, Catalogul de mesaje NATO — APP-11”. ADatP-3 este gramatica; APP-11 este dicționarul mesajelor scrise în acea gramatică. ADatP-34 stă cu un nivel deasupra ambelor: NISP le spune programelor și spiralelor Federated Mission Networking (FMN) ce standarde să folosească — inclusiv ADatP-3 și APP-11 — și nu definește niciun mesaj. Rolul NISP în selectarea profilurilor îl tratăm în articolul nostru despre structurile de date ADatP-34, iar partea de simbologie în APP-6 versus MIL-STD-2525.

Structura unui mesaj formatat: seturi, câmpuri, delimitatori

Fiecare mesaj MTF este o secvență de seturi; fiecare set este un identificator de set urmat de câmpuri. Trei convenții poartă aproape toată sintaxa:

• Un set începe cu identificatorul său — un mnemonic precum MSGID, REF sau NARR — urmat de o bară oblică.
• Câmpurile sunt separate printr-o singură bară oblică /. Un câmp este o intrare codată cu format fix (un grup dată-oră precum 011800Z, o poziție precum 4040N01100E) sau o intrare codată cu etichetă precum LM:4040N01100E.
• Un set se termină cu o bară oblică dublă //. Seturile lungi continuă pe liniile următoare fără a repeta identificatorul.

Exemplul de mai jos — un raport tactic în stilul documentației USMTF publice, simplificat pentru claritate și nefiind un mesaj operațional — arată pe toate trei:

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//

Unele seturi de uz general revin în tot traficul operațional și administrativ: MSGID (identificarea mesajului — tip, autor, număr de serie), EXER și OPER (identificarea exercițiului și a operației), REF cu însoțitorul său NARR (referințele și dezvoltarea lor narativă), SUBJ, POC și GENTEXT, care poartă text general sub un specificator de conținut (GENTEXT/REMARKS/…//). Compoziția exactă în seturi a fiecărui mesaj — ce seturi, în ce ordine, de câte ori — este definită per mesaj în APP-11.

Fiecare set dintr-o intrare de catalog poartă informații de apariție (obligatorie sau condiționată de alt conținut) și de repetabilitate (de câte ori poate apărea — un mesaj care citează trei referințe poartă trei seturi REF). Câmpurile au formate prescrise și, pentru câmpurile codate, tabele de valori definite. Fizic, seturile sunt așezate liniar (câmpurile continuă după identificator, ca în exemplu) sau ca rânduri în coloane — liniile de misiuni din ordinul de misiuni aeriene sunt exemplul clasic în coloane: un rând aliniat, delimitat prin bare oblice, per misiune sau zbor. Totul este text cu majuscule, orientat pe caractere, într-un set restrâns de caractere imprimabile — exact ce îi permite să supraviețuiască oricărui terminal și oricărui purtător.

Linii de bază și ediții: pe ce catalog țintește parserul dumneavoastră

„Pe ce ADatP-3 sunteți?” este prima întrebare de interoperabilitate. Catalogul de mesaje evoluează prin linii de bază versionate, iar flota desfășurată este răspândită pe două decenii dintre acestea:

Această cronologie este compilată din istoricul public al edițiilor publicat de comunitatea de întreținere a catalogului și din registrul public al NATO. Două modificări APP-11(E) contează pentru implementatori: WGS 84 a devenit singurul datum geodezic permis pentru informația de poziție (opțiunea de a selecta alt datum a fost eliminată), iar entitățile geografice anterior codate au devenit text liber, guvernate de liste specifice operației. În spatele catalogului, însuși corpul de reguli a trecut de la STANAG 5500 Edition 4 (epoca liniei de bază din 1999) prin Edition 7 (2010) la Edition 8 curentă, sub care ADatP-03 Edition A Version 4 a fost promulgată în 2021.

Operațional, linia de bază în vigoare este fixată de lanțul de mandate — planul operației, mesajele de mandatare maritimă sau aeriană sau specificația spiralei FMN la care operația se afiliază. Profilul FMN al operațiilor aeriene, de exemplu, a mutat suportul pentru mesaje formatate de la definițiile moștenite ATO/ACO ale liniei de bază 11 (documentate în publicații aliate mai vechi) la APP-11(E). Aceeași disciplină a mandatelor guvernează operațiunile pe legături de date, unde OPTASK LINK echipază întreaga rețea — vedeți cum guvernează OPTASK LINK legătura Link 16.

XML-MTF: același mesaj în XML

Până în 2008, mesajele formatate existau doar ca text delimitat prin bare oblice. De atunci, catalogul APP-11 include și definiții XML-MTF, cu o corespondență deliberată unu-la-unu între reprezentările textuală și XML — avantajul de lățime de bandă al formei textuale se păstrează, în timp ce instrumentele XML standard devin utilizabile. Partea de concept a ADatP-3 (CONFORMETS) specifică familia de specificații tehnice XML-MTF așa cum sunt ele aplicate MTF-urilor ADatP-03 pentru a produce formate XML derivate echivalente.

Două consecințe practice pentru ingineri:

• Instrumentele XML standard funcționează. Schemele catalogului pot conduce parsere cu validare, extragerea XPath și randarea XSLT în locul de cod de mesaje confecționat manual.
• Denumirea este gestionată. NATO a înregistrat un spațiu de nume URN formal (urn:nato:) în RFC 7467, cu artefactele formatelor de mesaje text ca tip de resursă numit, astfel încât spațiile de nume și schemele XML primesc identificatori persistenți și fără coliziuni.

Reprezentarea XML este și calea de întreținere: lucrările curente la catalog includ actualizarea XML la cele mai recente reguli de denumire și proiectare ale NATO și introducerea unei variante JSON a mesajelor. Dacă veniți din lumea TAK, rețineți că XML-MTF este o convenție mult mai grea decât XML-ul Cursor on Target pe care aplicațiile de conștientizare tactică îl schimbă — exemplele CoT adnotate arată cât de minimal este acel format prin comparație, iar porțile între cele două lumi sunt un proiect de integrare în sine.

USMTF (MIL-STD-6040): echivalentul american și relația cu acesta

Statele Unite derulează propriul program de formatare a mesajelor text, USMTF, guvernat de MIL-STD-6040 (din 2008 seria MIL-STD-6040B, cu catalogul livrat ca scheme XML-MTF) și gestionat sub instrucțiunea președintelui Șefilor de Stat Major Combinat CJCSI 6241.04E (octombrie 2023). Instrucțiunea este explicită despre corespondență: echivalentul NATO al regulilor și convențiilor MIL-STD-6040 este ADatP-3, iar APP-11 este echivalentul Catalogului de mesaje USMTF. USMTF este obligatoriu pentru toate cerințele de schimb de mesaje formatate orientate pe caractere din sistemele americane, cu excepția excluderii exprese printr-un acord multinațional.

Cele două seturi de reguli sunt apropiate: îndrumările publicate de comunitatea de întreținere descriu regulile ca foarte similare, cu doar diferențe minore, iar o serie de mesaje au fost armonizate între cele două cataloage. Liniile de bază USMTF desfășurate (1998, 2000 și 2004 în sistemele moștenite) sunt paralele cu istoria liniilor de bază NATO. Pentru implementator, concluzia practică este că un singur motor MTF poate procesa ambele — dar trebuie condus de pachetul de catalog corect, APP-11 al NATO sau USMTF, pentru linia de bază pe care partenerul o rulează efectiv. Și nu confundați niciunul dintre ele cu VMF (MIL-STD-6017), un format binar orientat pe biți pentru legături radio, nu un format de mesaje orientat pe caractere.

Cum procesează software-ul MTF: parser, validator, generator — și drumul către imaginea C2

Traficul formal de mesaje este payload, nu transport: călătorește pe gestionarea mesajelor militare (MMHS, STANAG 4406), pe retransmisia moștenită ACP 127 sau pur și simplu ca atașament de e-mail sau chat — profilurile FMN permit explicit mesajele formatate ca payload peste mai multe transporturi. Articolul nostru însoțitor despre mesageria militară NATO acoperă stratul de gestionare. Ceea ce sistemul C2 datorează mesajului la sosire este o linie de procesare:

• Parsare condusă de gramatică. Tokenizați textul în seturi după identificator, despărțiți câmpurile la delimitator, reuniți liniile de continuare și construiți arborele mesajului. Gramatica este stabilă în tot catalogul, deci un singur parser acoperă fiecare tip de mesaj.
• Validare condusă de catalog. Identificați tipul de mesaj din MSGID, apoi verificați ordinea seturilor, apariția și repetabilitatea, formatele câmpurilor și valorile codate împotriva definițiilor liniei de bază convenite. Erorile trebuie raportate cu poziția setului și a câmpului, pentru că expeditorul trebuie să le găsească.
• Conversie și mapare. Convertiți între textul cu bare oblice și XML-MTF (unu la unu), apoi mapați câmpurile în modelul de date al sistemului. NATO menține modele de referință pentru aceasta — Modelul informațional C2 al NATO (NCIM) și specificațiile MIP — iar mapări concrete există deja în standarde: standardul de urmărire a forțelor proprii ADatP-36 specifică maparea dintre formatele de mesaje text FFI și NFFI, iar un profil de mediere FMN traduce FFI MTF în modelul de date al soldatului descărcat.
• Generare prin același catalog. La ieșire, editoarele pe formulare, generate din șabloanele catalogului, impun câmpurile obligatorii și tabelele de valori la introducere; generatorul serializează în text sau XML-MTF, validează ciclul dus-întors și aplică grupul dată-oră, prioritatea și adresarea.

Deoarece ambele direcții sunt conduse de aceleași definiții mașină-lizibile, catalogul este efectiv contractul dintre expeditor și destinatar — de aceea schimbul de mesaje formatate este un element de testare de prim rang la evenimentul anual de interoperabilitate al NATO, unde se exersează profiluri FMN pentru mesaje formatate aeriene, maritime, cibernetice și de evacuare medicală. Pregătirea pentru el este o disciplină în sine: vedeți ghidul nostru de certificare CWIX și modul în care punem în evidență rezultatele testelor de coaliție în Interoperability Dashboard.

Capcanele care rup interoperabilitatea MTF

Cele mai multe defecțiuni ale mesajelor formatate nu sunt exotice:

• Nepotrivirea liniilor de bază. Un partener încă pe APP-11(D) trimite un mesaj pe care validatorul dumneavoastră APP-11(E) îl respinge — sau îl acceptă citind în tăcere greșit un câmp retras. Tranziția APP-11(E) a retras 40 de mesaje și a făcut din WGS 84 singurul datum permis; un parser care onorează încă alte datumuri va corupe coordonatele. Fixați linia de bază în instrucțiunile de comunicații ale operației și detectați linia de bază a expeditorului din identificarea mesajului.
• Extensiile naționale. Națiunile adaugă seturi și câmpuri în variante naționale. Strategia robustă este acceptă-și-semnalează: parsați ce cunoaște catalogul, puneți în carantină și jurnalizați ce nu cunoaște și arătați diferența unui operator — niciodată să nu renunțați în tăcere la date.
• Abuzul de text liber. Împingerea datelor structurate în proza GENTEXT sau NARR pentru că câmpurile codate „nu se potrivesc” distruge prelucrarea automată pentru fiecare destinatar. Dacă informația contează pentru automatizare, locul ei este în câmpuri codate; dacă un nou câmp codat este cu adevărat necesar, aceasta este o propunere de modificare la catalog, nu un aranjament local.
• Șabloane de editor învechite. Formularele neregenerate din linia de bază curentă lasă operatorii să omită câmpuri recent obligatorii; validarea eșuează atunci în aval, la partener, în loc să eșueze la introducere.