ADatP-3 (STANAG 5500): tekstberichtformaten van de NAVO uitgelegd

ADatP-3 — Allied Data Publication 3, afgekondigd via STANAG 5500 — is het opmaaksysteem voor tekstberichten van de NAVO, bekend als FORMETS: de regels, constructies en woordenschat waarmee elk geformatteerd NAVO-bericht wordt opgebouwd, van een situatierapport tot een luchttaakorder. De ongeveer 400 berichten die volgens die regels zijn opgebouwd, staan in de catalogus APP-11 — 407 Message Text Formats in de huidige editie — en sinds 2008 bestaat elk daarvan ook als XML-MTF.

Wat is ADatP-3 (STANAG 5500)?

Officieel draagt de publicatie de titel NATO Message Text Formatting System (FORMETS) — Concept of FORMETS (CONFORMETS). U ziet hem geschreven als ADatP-3 of ADatP-03; beide verwijzen naar dezelfde Allied Data Publication. De huidige versie is Edition A Version 4, afgekondigd op 1 juli 2021 onder de dekkende overeenkomst STANAG 5500 Edition 8. Het standaardwerk wordt onderhouden door het NAVO-capabilityteam voor tekstberichtformaten (MTF CaT), en de afgekondigde edities staan in de openbare database van het NAVO-standaardisatiebureau.

Wat de standaard specificeert, citeert u het beste uit de samenvatting van de NAVO zelf: FORMETS biedt „de syntaxis en de regels voor de representatie van overeengekomen conceptuele definities (velden), en de rangschikking van die velden in zinnen (sets) en berichtteksten”, en is bedoeld voor alle geformatteerde, tekengeoriënteerde berichten in command & control van de NAVO. Met andere woorden: ADatP-3 is de grammatica van het geformatteerde NAVO-berichtverkeer. Het definieert geen afzonderlijke berichten — dat is de taak van de hieronder beschreven catalogus APP-11.

Het ontwerpdoel verklaart de levensduur. Een geformatteerd bericht moet leesbaar zijn voor een operator op een kale terminal, parseerbaar door software op een moderne server, en compact genoeg voor een beperkte tactische verbinding. Tekengeoriënteerde, door schuine strepen gescheiden tekst voldoet aan alle drie — daarom stroomt ADatP-3-verkeer in 2026 nog steeds mee, naast al het andere in de stack van NAVO-interoperabiliteitsstandaarden.

ADatP-3, APP-11, ADatP-34, APP-6: welke standaard is welke

Deze vier worden voortdurend door elkaar gehaald — ook in leveranciersmarketing — dus hier de juiste mapping, geverifieerd tegen de openbare standaardisatieregisters van de NAVO:

De relatie tussen de eerste twee is precies. Volgens de eigen NISP-beschrijving van de NAVO bevat de ADatP-03-database alle tekstberichtformaten onder configuratiebeheer van de werkgroep berichtformaten, en „de overeengekomen MTF's worden, zodra ze in een baseline zijn gepubliceerd, regelmatig ingevoegd in STANAG 7149, NAVO-berichtencatalogus — APP-11”. ADatP-3 is de grammatica; APP-11 is het woordenboek van de berichten die in die grammatica zijn geschreven. ADatP-34 staat een niveau boven beide: de NISP zegt programma's en Federated Mission Networking(FMN)-spiralen welke standaarden ze moeten gebruiken — waaronder ADatP-3 en APP-11 — en definieert zelf geen berichten. De rol van de NISP in profielkeuze behandelen we in ons artikel over ADatP-34-datastructuren, en de symboliekzijde in APP-6 versus MIL-STD-2525.

Structuur van een geformatteerd bericht: sets, velden, scheidingstekens

Elk MTF-bericht is een reeks sets; elke set is een setidentificatie gevolgd door velden. Drie conventies dragen vrijwel de hele syntaxis:

• Een set begint met zijn identificatie — een mnemotechniek zoals MSGID, REF of NARR — gevolgd door een schuine streep.
• Velden worden gescheiden door één schuine streep /. Een veld is een gecodeerde invoer met vast formaat (een datum-tijdgroep zoals 011800Z, een positie zoals 4040N01100E) of een gelabelde code zoals LM:4040N01100E.
• Een set eindigt op een dubbele schuine streep //. Lange sets lopen door op volgende regels zonder de identificatie te herhalen.

Het voorbeeld hieronder — een tactisch rapport in de stijl van de openbare USMTF-documentatie, vereenvoudigd voor de duidelijkheid en geen operationeel bericht — laat alle drie zien:

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

Bepaalde generieke sets keren terug in operationeel en administratief verkeer: MSGID (berichtidentificatie — type, afzender, volgnummer), EXER en OPER (identificatie van oefening en operatie), REF met zijn gezel NARR (referenties en hun narratieve uitwerking), SUBJ, POC en GENTEXT, dat algemene tekst draagt onder een inhoudsaanduiding (GENTEXT/REMARKS/…//). De exacte setsamenstelling van elk bericht — welke sets, in welke volgorde, hoe vaak — is per bericht gedefinieerd in APP-11.

Elke set in een catalogusentry bevat informatie over voorkomen (verplicht, of voorwaardelijk afhankelijk van andere inhoud) en over herhaalbaarheid (hoe vaak hij mag voorkomen — een bericht met drie referenties draagt drie REF-sets). Velden hebben voorgeschreven formaten en, voor gecodeerde velden, gedefinieerde waardetabellen. Fysiek worden sets lineair uitgezet (velden lopen door na de identificatie, zoals in het voorbeeld) of als kolomsgewijze regels — de taakregels van de luchttaakorder zijn het klassieke kolomvoorbeeld: één uitgelijnde, door schuine strepen gescheiden regel per missie of vlucht. Alles is tekst in hoofdletters, tekengeoriënteerd, in een beperkt printbaar tekenrepertoire — precies waardoor hij elke terminal en elk dragermedium overleeft.

Baselines en edities: op welke catalogus richt uw parser zich

„Op welke ADatP-3-versie zit u?” is de eerste interoperabiliteitsvraag. De berichtcatalogus evolueert via geversioneerde baselines, en het uitgerolde park beslaat twee decennia ervan:

Deze tijdlijn is samengesteld uit de openbare editiegeschiedenis die door de onderhoudsgemeenschap van de catalogus wordt gepubliceerd en uit de openbare registers van de NAVO. Twee APP-11(E)-wijzigingen tellen voor implementatoren: WGS 84 werd het enige toegestane geodetische datum voor positie-informatie (de optie om een ander datum te kiezen is verwijderd), en voorheen gecodeerde geografische entiteiten werden vrije tekst, gereguleerd door operationspecifieke lijsten. Achter de catalogus verhuisde het reglement zelf van STANAG 5500 Edition 4 (het tijdperk van de baseline van 1999) via Edition 7 (2010) naar de huidige Edition 8, waaronder ADatP-03 Edition A Version 4 in 2021 werd afgekondigd.

Operationeel wordt de geldende baseline vastgesteld door de aansturingsketen — het operatieplan, de maritieme of luchtaansturingsberichten, of de FMN-spiraalspecificatie waaraan een operatie is gelieerd. Het FMN-profiel voor luchtoperaties verplaatste de ondersteuning van geformatteerde berichten bijvoorbeeld van de legacy ATO/ACO-definities van Baseline 11 (gedocumenteerd in oudere geallieerde publicaties) naar APP-11(E). Dezelfde aansturingsdiscipline geldt voor datalinkoperaties, waar de OPTASK LINK het hele netwerk voorziet — zie hoe de OPTASK LINK Link 16 aanstuurt.

XML-MTF: hetzelfde bericht in XML

Tot 2008 bestonden geformatteerde berichten alleen als tekst met schuine strepen. Sindsdien bevat de APP-11-catalogus ook XML-MTF-definities, met een bewuste één-op-één-mapping tussen de tekstuele en de XML-representatie — het bandbreedtevoordeel van de tekstvorm blijft behouden, terwijl standaard XML-tooling bruikbaar wordt. Het conceptdeel van ADatP-3 (CONFORMETS) specificeert de familie XML-MTF-technische specificaties zoals die worden toegepast op ADatP-03-MTF's om equivalente afgeleide XML-formaten te verkrijgen.

Twee praktische gevolgen voor ingenieurs:

• Standaard XML-tooling werkt. Catalogusschema's kunnen validerende parsers, XPath-extractie en XSLT-rendering aansturen in plaats van op maat geschreven berichtcode.
• Naamgeving is geregeld. De NAVO registreerde een formele URN-naamruimte (urn:nato:) in RFC 7467, met tekstberichtformaat-artefacten als benoemd resourcetype, zodat XML-naamruimten en schema's persistente, botsingsvrije identifiers krijgen.

De XML-representatie is ook het onderhoudspad: het huidige cataloguswerk omvat het bijwerken van de XML naar de nieuwste NAVO-naamgevings- en ontwerpregels en de introductie van een JSON-variant van de berichten. Komt u uit de TAK-wereld, bedenk dan dat XML-MTF een veel zwaardere conventie is dan de Cursor on Target-XML die tactische bewustzijnsapps uitwisselen — geannoteerde CoT-voorbeelden laten zien hoe minimaal dat formaat vergeleken is, en gateways tussen beide werelden zijn een eigen integratieproject.

USMTF (MIL-STD-6040): de Amerikaanse tegenhanger en de relatie ermee

De Verenigde Staten draaien een eigen programma voor tekstberichtopmaak, USMTF, geregeld door MIL-STD-6040 (sinds 2008 de MIL-STD-6040B-serie, met de catalogus geleverd als XML-MTF-schema's) en beheerd onder de instructie van de voorzitter van de Joint Chiefs of Staff CJCSI 6241.04E (oktober 2023). De instructie is expliciet over de mapping: het NAVO-equivalent van de MIL-STD-6040-regels en -conventies is ADatP-3, en APP-11 is het equivalent van de USMTF-berichtencatalogus. USMTF is verplicht voor alle vereisten voor uitwisseling van geformatteerde, tekengeoriënteerde berichten in Amerikaanse systemen, tenzij een multinationale overeenkomst dat expliciet uitsluit.

De twee regelsets liggen dicht bij elkaar: gepubliceerde richtlijnen van de onderhoudsgemeenschap beschrijven de regels als zeer gelijkend met slechts kleine verschillen, en een aantal berichten is geharmoniseerd tussen beide catalogi. Uitgerolde USMTF-baselines (1998, 2000 en 2004 in legacysystemen) lopen parallel aan de NAVO-baselinegeschiedenis. Voor de implementator is de praktische conclusie dat één MTF-engine beide kan verwerken — maar hij moet worden aangedreven door het juiste cataloguspakket, NAVO APP-11 of USMTF, voor de baseline die de partner daadwerkelijk draait. En verwar ze niet met VMF (MIL-STD-6017), een binair, bitgeoriënteerd formaat voor radioverbindingen, geen tekengeoriënteerd berichtformaat.

Hoe software MTF verwerkt: parser, validator, generator — en de weg naar het C2-beeld

Formeel berichtenverkeer is payload, geen transport: het rijdt op militaire berichtenverwerking (MMHS, STANAG 4406), op legacy-doorgifte via ACP 127, of gewoon als bijlage van een e-mail of chat — de FMN-profielen staan geformatteerde berichten expliciet toe als payload over meerdere transporten. Ons begeleidende stuk over militaire berichtenuitwisseling van de NAVO behandelt de verwerkingslaag. Wat het C2-systeem het bericht verschuldigd is bij aankomst, is een verwerkingspijplijn:

• Grammatica-gedreven parsing. Tokeniseer de tekst in sets op identificatie, splits velden op het scheidingsteken, voeg vervolgregels weer samen en bouw een berichtboom. De grammatica is stabiel over de hele catalogus, dus één parser behandelt elk berichttype.
• Catalogus-gedreven validatie. Identificeer het berichttype uit MSGID, controleer dan setvolgorde, voorkomen en herhaalbaarheid, veldformaten en gecodeerde waarden tegen de definities van de overeengekomen baseline. Fouten moeten worden gemeld met set- en veldpositie, want de afzender moet ze kunnen vinden.
• Conversie en mapping. Converteer tussen tekst met schuine strepen en XML-MTF (één-op-één), map dan velden naar het datamodel van het systeem. De NAVO onderhoudt daarvoor referentiemodellen — het NAVO C2-informatiemodel (NCIM) en de MIP-specificaties — en concrete mappings bestaan al in standaarden: de standaard voor friendly force tracking ADatP-36 specificeert de mapping tussen FFI-berichtformaten en NFFI, en een FMN-mediatiestrofiel vertaalt FFI-MTF naar het datamodel van de soldaat te voet.
• Generatie via dezelfde catalogus. Uitgaand dwingen op formulieren gebaseerde editors, gegenereerd uit catalogussjablonen, verplichte velden en waardetabellen af bij invoer; de generator serialiseert naar tekst of XML-MTF, valideert de volledige cyclus en voorziet het bericht van datum-tijdgroep, prioriteit en adressering.

Omdat beide richtingen worden aangedreven door dezelfde machineleesbare definities, is de catalogus feitelijk het contract tussen zender en ontvanger — daarom is de uitwisseling van geformatteerde berichten een volwaardig testpunt op het jaarlijkse interoperabiliteitsevenement van de NAVO, waar FMN-profielen voor lucht-, zee-, cyber- en medische evacuatie-berichtformats worden geoefend. Zich daarop voorbereiden is een eigen discipline: zie onze CWIX-certificeringsgids en hoe we coalitietestresultaten zichtbaar maken in het Interoperability Dashboard.

Valkuilen die MTF-interoperabiliteit breken

De meeste uitval van geformatteerde berichten is niet exotisch:

• Baseline-mismatch. Een partner die nog op APP-11(D) zit, stuurt een bericht dat uw APP-11(E)-validator afwijst — of accepteert terwijl hij een afgeschafte veld stilletjes verkeerd leest. De APP-11(E)-overgang schafte 40 berichten af en maakte WGS 84 het enige toegestane datum; een parser die nog andere datums honourt, zal coördinaten corrumperen. Leg de baseline vast in de verbindingsinstructies van de operatie en detecteer de baseline van de afzender uit de berichtidentificatie.
• Nationale uitbreidingen. Landen voegen sets en velden toe in nationale varianten. De robuuste strategie is accepteren-en-markeren: parse wat de catalogus kent, zet wat hij niet kent in quarantaine en log het, en toon het verschil aan een operator — nooit stilletjes laten vallen.
• Misbruik van vrije tekst. Gestructureerde data in GENTEXT- of NARR-proza duwen omdat de gecodeerde velden „niet passen”, vernielt machineverwerking voor elke ontvanger. Als informatie voor automatisering telt, hoort die in gecodeerde velden; als er echt een nieuw gecodeerd veld nodig is, is dat een wijzigingsvoorstel aan de catalogus, geen lokale hack.
• Verouderde editorsjablonen. Formulieren die niet opnieuw zijn gegenereerd uit de huidige baseline laten operators nieuw verplichte velden overslaan; validatie faalt dan stroomafwaarts bij de partner in plaats van bij invoer.