ADatP-3 (STANAG 5500): Textnachrichtenformate der NATO erklärt

ADatP-3 — Allied Data Publication 3, verkündet durch STANAG 5500 — ist das Textnachrichten-Formatierungssystem der NATO, bekannt als FORMETS: die Regeln, Konstruktionen und das Vokabular, mit denen jede formatierte NATO-Nachricht aufgebaut wird, von der Lagemeldung bis zum Einsatzbefehl für Luftoperationen. Die rund 400 nach diesen Regeln konstruierten Nachrichten sind im APP-11 katalogisiert — 407 Message Text Formats in der aktuellen Ausgabe — und seit 2008 existiert jede davon auch als XML-MTF.

Was ist ADatP-3 (STANAG 5500)?

Offiziell trägt die Publikation den Titel NATO Message Text Formatting System (FORMETS) — Concept of FORMETS (CONFORMETS). Sie werden die Schreibweisen ADatP-3 oder ADatP-03 sehen; beide bezeichnen dieselbe Allied Data Publication. Die aktuelle Version ist Edition A Version 4, verkündet am 1. Juli 2021 unter der deckenden Vereinbarung STANAG 5500 Edition 8. Gepflegt wird der Standard vom NATO-Fähigkeitsteam für Textnachrichtenformate (MTF CaT); die verkündeten Ausgaben sind in der öffentlichen Datenbank des NATO-Standardisierungsamts gelistet.

Was der Standard festlegt, lässt sich am besten mit der eigenen Zusammenfassung der NATO zitieren: FORMETS stellt „die Syntax und die Regeln für die Darstellung vereinbarter konzeptioneller Definitionen (Felder) und die Anordnung dieser Felder zu Sätzen („Sentences“) und Nachrichtentexten“ bereit und ist für alle formatierten, zeichenorientierten Nachrichten im Führungswesen der NATO bestimmt. Mit anderen Worten: ADatP-3 ist die Grammatik des formatierten NATO-Nachrichtenverkehrs. Es definiert keine einzelnen Nachrichten — das ist die Aufgabe des unten beschriebenen Katalogs APP-11.

Das Entwurfsziel erklärt seine Langlebigkeit. Eine formatierte Nachricht muss für einen Bediener an einem nackten Terminal lesbar, von Software auf einem modernen Server parsbar und kompakt genug für ein begrenztes taktisches Netz sein. Zeichenorientierter, schrägstrichgetrennter Text erfüllt alle drei Bedingungen — deshalb fließt ADatP-3-Verkehr auch 2026 noch neben allem anderen im Stack der NATO-Interoperabilitätsstandards.

ADatP-3, APP-11, ADatP-34, APP-6: welcher Standard ist welcher

Diese vier werden ständig verwechselt — auch im Anbietermarketing —, daher hier die korrekte Zuordnung, abgeglichen mit den öffentlichen Standardisierungsunterlagen der NATO:

Das Verhältnis der ersten beiden ist präzise. Nach der eigenen NISP-Beschreibung der NATO enthält die ADatP-03-Datenbank alle Textnachrichtenformate unter der Konfigurationskontrolle der Arbeitsgruppe für Nachrichtenformate, und „die vereinbarten MTFs werden nach Veröffentlichung in einer Baseline regelmäßig in STANAG 7149, den Nachrichtenkatalog der NATO — APP-11, eingefügt“. ADatP-3 ist die Grammatik; APP-11 ist das Wörterbuch der in dieser Grammatik geschriebenen Nachrichten. ADatP-34 liegt eine Ebene darüber: Das NISP sagt Programmen und Federated-Mission-Networking-(FMN-)Spiralen, welche Standards zu verwenden sind — darunter ADatP-3 und APP-11 — und definiert selbst keine Nachrichten. Die Rolle des NISP bei der Profilauswahl behandeln wir in unserem Artikel zu den ADatP-34-Datenstrukturen, die Symbolikseite in APP-6 vs. MIL-STD-2525.

Aufbau einer formatierten Nachricht: Sätze, Felder, Trennzeichen

Jede MTF-Nachricht ist eine Folge von Sätzen; jeder Satz ist eine Satzkennung, gefolgt von Feldern. Drei Konventionen tragen nahezu die gesamte Syntax:

• Ein Satz beginnt mit seiner Satzkennung — einem Mnemonic wie MSGID, REF oder NARR —, gefolgt von einem Schrägstrich.
• Felder sind durch einen einzelnen Schrägstrich getrennt /. Ein Feld ist ein kodierter Eintrag mit festem Format (eine Datum-Zeit-Gruppe wie 011800Z, eine Position wie 4040N01100E) oder ein kodierter Eintrag mit Kennung wie LM:4040N01100E.
• Ein Satz endet mit einem doppelten Schrägstrich //. Lange Sätze werden in den folgenden Zeilen fortgesetzt, ohne die Kennung zu wiederholen.

Das Beispiel unten — eine taktische Meldung im Stil der offen publizierten USMTF-Dokumentation, der Klarheit halber vereinfacht und keine operativ genutzte Nachricht — zeigt alle drei:

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

Bestimmte universelle Sätze kehren im operativen wie im administrativen Verkehr wieder: MSGID (Nachrichtenidentifikation — Typ, Urheber, Seriennummer), EXER und OPER (Identifikation von Übung und Operation), REF mit dem zugehörigen NARR (Referenzen und ihre narrative Ausführung), SUBJ, POC sowie GENTEXT, das allgemeinen Text unter einem Inhaltskennzeichner trägt (GENTEXT/REMARKS/…//). Die genaue Satzkomposition jeder Nachricht — welche Sätze, in welcher Reihenfolge, wie oft — ist pro Nachricht in APP-11 definiert.

Jeder Satz in einem Katalogeintrag trägt Angaben zum Auftreten (obligatorisch oder bedingt in Abhängigkeit von anderem Inhalt) und zur Wiederholbarkeit (wie oft er vorkommen darf — eine Nachricht mit drei Referenzen trägt drei REF-Sätze). Felder haben vorgeschriebene Formate und, für kodierte Felder, definierte Wertetabellen. Physisch werden Sätze linear angeordnet (Felder laufen hinter der Kennung weiter, wie im Beispiel) oder als spaltenförmige Zeilen — die Auftragzeilen des Einsatzbefehls für Luftoperationen sind das klassische spaltenförmige Beispiel: eine ausgerichtete, schrägstrichgetrennte Zeile pro Einsatz oder Flug. All das ist Text in Großbuchstaben, zeichenorientiert, in einem beschränkten druckbaren Zeichensatz — genau das lässt ihn jedes Terminal und jeden Übertragungsweg überstehen.

Baselines und Ausgaben: Auf welchen Katalog zielt Ihr Parser

„Auf welcher ADatP-3-Version stehen Sie?“ ist die erste Interoperabilitätsfrage. Der Nachrichtenkatalog entwickelt sich über versionierte Baselines, und die eingesetzte Flotte verteilt sich auf zwei Jahrzehnte davon:

Diese Zeitleiste ist aus der von der Katalog-Pflegegemeinschaft veröffentlichten öffentlichen Ausgabengeschichte und aus den öffentlichen Unterlagen der NATO kompiliert. Zwei APP-11(E)-Änderungen sind für Implementierer relevant: WGS 84 wurde das einzige zugelassene geodätische Datum für Positionsangaben (die Option, ein anderes Datum zu wählen, entfiel), und zuvor kodierte geografische Einheiten wurden zu Freitext, regiert durch operationsbezogene Listen. Hinter dem Katalog wanderte das Regelwerk selbst von STANAG 5500 Edition 4 (Ära der Baseline von 1999) über Edition 7 (2010) zur aktuellen Edition 8, unter der 2021 ADatP-03 Edition A Version 4 verkündet wurde.

Operativ wird die wirksame Baseline von der Befehlskette gesetzt — dem Operationsplan, den maritimen oder lufttaktischen Botschaften oder der FMN-Spiralenspezifikation, der sich eine Operation anschließt. Das FMN-Profil für Luftoperationen etwa verlagerte die Unterstützung formatierter Nachrichten von den Legacy-Definitionen ATO/ACO der Baseline 11 (dokumentiert in älteren Bündnispublikationen) zu APP-11(E). Dieselbe Befehlsdisziplin regiert Datenlink-Operationen, bei denen die OPTASK LINK das gesamte Netz ausstattet — siehe wie die OPTASK LINK Link 16 regiert.

XML-MTF: dieselbe Nachricht in XML

Bis 2008 existierten formatierte Nachrichten nur als schrägstrichgetrennter Text. Seitdem enthält der APP-11-Katalog auch XML-MTF-Definitionen, mit einer bewusst eins-zu-eins-Abbildung zwischen der textuellen und der XML-Darstellung — der Bandbreitenvorteil der Textform bleibt erhalten, und gleichzeitig wird Standard-XML-Werkzeug nutzbar. Der Konzeptteil von ADatP-3 (CONFORMETS) spezifiziert die Familie der XML-MTF-Technischen Spezifikationen in der Form, in der sie auf ADatP-03-MTFs angewendet werden, um äquivalente abgeleitete XML-Formate zu erzeugen.

Zwei praktische Konsequenzen für Ingenieure:

• Standard-XML-Werkzeug funktioniert. Katalog-Schemata können validierende Parser, XPath-Extraktion und XSLT-Darstellung antrieben, statt handgeschriebenen Nachrichtencode.
• Namensgebung ist geregelt. Die NATO hat einen formalen URN-Namespace (urn:nato:) in RFC 7467 registriert, mit Textnachrichtenformat-Artefakten als benanntem Ressourcentyp, sodass XML-Namespaces und Schemata persistente, kollisionsfreie Bezeichner erhalten.

Die XML-Darstellung ist auch der Pfad der Pflege: Die aktuelle Katalogarbeit umfasst die Aktualisierung des XML auf die neuesten NATO-Namens- und Entwurfsregeln und die Einführung einer JSON-Variante der Nachrichten. Wenn Sie aus der TAK-Welt kommen: XML-MTF ist eine weit schwerere Konvention als das Cursor-on-Target-XML, das Anwendungen für taktische Lagebewusstsein austauschen — kommentierte CoT-Beispiele zeigen, wie minimal dieses Format im Vergleich ist, und Gateways zwischen beiden Welten sind ein eigenes Integrationsprojekt.

USMTF (MIL-STD-6040): das US-Pendant und sein Verhältnis dazu

Die Vereinigten Staaten betreiben ein eigenes Programm für Textnachrichtenformate, USMTF, geregelt durch MIL-STD-6040 (seit 2008 die MIL-STD-6040B-Serie, mit dem Katalog als XML-MTF-Schemata geliefert) und verwaltet unter der Weisung des Vorsitzenden der Vereinigten Generalstabschefs CJCSI 6241.04E (Oktober 2023). Die Weisung ist über die Abbildung explizit: das NATO-Äquivalent der MIL-STD-6040-Regeln und -Konventionen ist ADatP-3, und APP-11 ist das Äquivalent des USMTF-Nachrichtenkatalogs. USMTF ist verbindlich für alle Anforderungen an den Austausch formatierter, zeichenorientierter Nachrichten in US-Systemen, sofern nicht durch multinationale Vereinbarung ausdrücklich ausgenommen.

Die beiden Regelwerke liegen eng beieinander: Publizierte Leitlinien der Pflegegemeinschaft beschreiben die Regeln als sehr ähnlich mit nur geringfügigen Unterschieden, und eine Reihe von Nachrichten wurde über beide Kataloge hinweg harmonisiert. Eingesetzte USMTF-Baselines (1998, 2000 und 2004 in Altsystemen) verlaufen parallel zur NATO-Baseline-Geschichte. Für den Implementierer lautet der praktische Befund: Eine MTF-Engine kann beide verarbeiten — sie muss aber vom korrekten Katalogpaket, NATO-APP-11 oder USMTF, für die Baseline angetrieben werden, die der Partner tatsächlich fährt. Und verwechseln Sie keines von beiden mit VMF (MIL-STD-6017) — einem binären, bitorientierten Format für Funknetze, keinem zeichenorientierten Nachrichtenformat.

Wie Software MTF verarbeitet: Parser, Validator, Generator — und der Weg in das C2-Lagebild

Formeller Nachrichtenverkehr ist Nutzdaten, kein Transport: Er reitet auf militärischer Nachrichtenbearbeitung (MMHS, STANAG 4406), auf dem Legacy-Relais ACP 127 oder schlicht als E-Mail- oder Chat-Anhang — die FMN-Profile erlauben formatierte Nachrichten ausdrücklich als Nutzdaten über mehreren Transporten. Unser Begleittext zur militärischen Nachrichtenübermittlung der NATO behandelt die Bearbeitungsschicht. Was das C2-System der Nachricht beim Eintreffen schuldet, ist eine Verarbeitungskette:

• Grammatikgetriebenes Parsen. Tokenisieren Sie den Text in Sätze nach Kennung, trennen Sie Felder am Trennzeichen, fügen Sie Fortsetzungszeilen wieder zusammen und bauen Sie einen Nachrichtenbaum. Die Grammatik ist über den gesamten Katalog stabil, daher verarbeitet ein Parser jeden Nachrichtentyp.
• Kataloggetriebene Validierung. Bestimmen Sie den Nachrichtentyp aus MSGID, prüfen Sie dann Satzreihenfolge, Auftreten und Wiederholbarkeit, Feldformate und Codewerte gegen die Definitionen der vereinbarten Baseline. Fehler müssen mit Satz- und Feldposition gemeldet werden, weil der Absender sie finden muss.
• Konvertierung und Mapping. Konvertieren Sie zwischen schrägstrichgetrenntem Text und XML-MTF (eins zu eins), bilden Sie dann Felder auf das Datenmodell des Systems ab. Die NATO pflegt dafür Referenzmodelle — das NATO-C2-Informationsmodell (NCIM) und die MIP-Spezifikationen — und konkrete Abbildungen existieren bereits in Standards: Der Standard zur Lagedarstellung eigener Kräfte ADatP-36 spezifiziert das Mapping zwischen FFI-Textnachrichtenformaten und NFFI, und ein FMN-Mediationsprofil übersetzt FFI-MTF in das Datenmodell des abgesessenen Soldaten.
• Generierung über denselben Katalog. Ausgehend werden formularbasierte Editoren, generiert aus Katalogvorlagen, Pflichtfelder und Wertetabellen bei der Eingabe erzwingen; der Generator serialisiert in Text oder XML-MTF, validiert den Rundlauf und stempelt Datum-Zeit-Gruppe, Dringlichkeit und Adressierung.

Weil beide Richtungen von denselben maschinenlesbaren Definitionen angetrieben werden, ist der Katalog de facto der Vertrag zwischen Sender und Empfänger — deshalb ist der Austausch formatierter Nachrichten ein vollwertiger Prüfpunkt bei der jährlichen NATO-Interoperabilitätsveranstaltung, wo FMN-Profile für Luft-, See-, Cyber- und MedEvac-formatierte Nachrichten geübt werden. Die Vorbereitung darauf ist eine eigene Disziplin: siehe unser CWIX-Zertifizierungshandbuch und wie wir Koalitionstestergebnisse im Interoperability Dashboard sichtbar machen.

Stolperfallen, die MTF-Interoperabilität brechen

Die meisten Ausfälle formatierter Nachrichten sind nicht exotisch:

• Baseline-Mismatch. Ein Partner, der noch auf APP-11(D) steht, sendet eine Nachricht, die Ihr APP-11(E)-Validator zurückweist — oder annimmt, während er ein ausgesondertes Feld still falsch liest. Der APP-11(E)-Übergang hat 40 Nachrichten ausgesondert und WGS 84 zum einzigen zulässigen Datum gemacht; ein Parser, der weitere Datumswertere berücksichtigt, verfälscht Koordinaten. Fixieren Sie die Baseline in den Verbindungsanweisungen der Operation und erkennen Sie die Baseline des Absenders aus der Nachrichtenidentifikation.
• Nationale Erweiterungen. Nationen fügen Sätze und Felder in nationalen Varianten hinzu. Die robuste Strategie ist Annehmen-und-Kennzeichnen: parsen, was der Katalog kennt, in Quarantäne stellen und protokollieren, was er nicht kennt, und den Unterschied einem Bediener zeigen — niemals still verwerfen.
• Freitext-Missbrauch. Strukturierte Daten in GENTEXT- oder NARR-Prosa zu schieben, weil die kodierten Felder „nicht passen“, zerstört die maschinelle Verarbeitung für jeden Empfänger. Wenn Information für die Automatisierung zählt, gehört sie in kodierte Felder; wenn ein neues kodiertes Feld wirklich gebraucht wird, ist das eine Änderungsvorschlag an den Katalog, kein lokaler Hack.
• Veraltete Editor-Vorlagen. Formulare, die nicht aus der aktuellen Baseline neu generiert wurden, lassen Bediener neu obligatorische Felder auslassen; die Validierung scheitert dann nachgelagert beim Partner statt bei der Eingabe.