De NAVO-berichtencatalogus — formeel Allied Data Publication 34 (ADatP-34) — is de normatieve referentie voor de datastructuren die worden gebruikt bij NAVO-commando- en controleberichtuitwisseling. Het definieert de informatieobjecten, hun attributen, toegestane waardensets en de relaties tussen hen die de C2-berichtuitwisseling binnen de Alliantie ondersteunen. Voor softwareontwikkelaars die systemen bouwen die data moeten uitwisselen met NAVO C2-infrastructuur of met nationale systemen die NAVO-normen implementeren, is ADatP-34 een verplichte referentie — en een die zorgvuldige studie beloont.
Wat ADatP-34 is en zijn rol in NAVO C2
ADatP-34 wordt gepubliceerd door het NAVO Communications and Information Agency (NCIA) en wordt onderhouden als een levend document met regelmatige updates. Het heet formeel de "NAVO-berichtencatalogus" omdat het alle berichttypen catalogiseert die worden gebruikt bij NAVO C2-operaties: operationele rapporten, orders, intelligentieberichten, logistieke verzoeken, luchtopdrachtorders, maritieme situatierapporten en vele anderen. Elk berichttype in de catalogus is gespecificeerd met zijn datavelden, datatypes, verplichte en optionele elementen en bedrijfsregels die geldige veldcombinaties regelen.
De catalogus wordt gebruikt als normatieve databron voor twee gerelateerde maar verschillende doeleinden. Ten eerste definieert het de berichten die menselijke operators verzenden over NAVO-communicatienetwerken — de inhoud en het formaat van een operatierapport verzonden via het NAVO SECRET WAN moet voldoen aan de ADatP-34-specificatie voor dat berichttype. Ten tweede biedt het het datamodel waarvan machineleesbare data-uitwisselingsformaten worden afgeleid: het MIP (Multilateral Interoperability Programme)-datamodel voor C2-data-uitwisseling van grondtroepen is direct afgeleid van ADatP-34-berichtinhoud, net als het JC3IEDM (Joint Consultation, Command and Control Information Exchange Data Model) en zijn opvolger, het NATO C2 Information Exchange Data Model (NC2IEDM).
Deze dubbele rol betekent dat ADatP-34-kennis van toepassing is op zowel ontwikkelaars die berichtafhandelingssystemen bouwen (gestructureerde C2-berichten parseren en genereren) als op ontwikkelaars die datamodelimplementaties bouwen (databaseschema's of service-API's ontwerpen die zijn afgestemd op NAVO-data-uitwisselingsnormen).
Belangrijkste berichttypen: ORBAT, Tracks, CAS, Logistiek
De catalogus bevat honderden berichttypen. Een praktische implementatiebenadering begint met de berichttypen die het meest relevant zijn voor het toepassingsdomein. De meest geïmplementeerde berichttypen vallen in vier categorieën.
Order of Battle (ORBAT)-berichten beschrijven de samenstelling en dispositie van militaire strijdkrachten — wie is waar, welke uitrusting zij hebben en hoe eenheden zich verhouden in de bevelspiramide. De ORBAT-berichtfamilie omvat het Unit Disposition Report (UDISREP), het Equipment Status Report en het Commander's Appreciation of the Situation. ORBAT-data stuurt de krachtenweergavelaag van elke C2-applicatie aan en is de primaire invoer voor sterktecalculaties en logistieke planningshulpmiddelen.
Trackberichten dragen positie-informatie voor entiteiten — voertuigen, vliegtuigen, vaartuigen en vijandige contacten — in real-time of bijna real-time. De trackberichtfamilie omvat Air Situation Report (AIRSIT), Maritime Surface Summary (MARSURSUM) en het Ground Situation Report (GROUNDSIT). Trackdata is de primaire invoer voor het Gemeenschappelijk Operationeel Beeld en wordt typisch verzonden met hoge frequentie (vliegtuigtracks elke paar seconden, grondentiteitstracks elke 30–60 seconden afhankelijk van bewegingsstatus).
Close Air Support (CAS)-berichten coördineren de inzet van vliegtuigen voor grondsteun — een van de meest protocolintensieve processen bij gezamenlijke operaties. De CAS-berichtfamilie omvat het Air Support Request (AIRSUPREQ), de CAS Brief, het BDA (Battle Damage Assessment)-rapport en het 9-line CAS brief-formaat. CAS-automatisering is een hoge prioriteit integratievereiste voor elke gecombineerde vuuraplicatie.
Logistieke berichten bestrijken bevoorradingsverzoeken, coördinatie van medische evacuatie, onderhoudsverzoeken en rapportage van voorraadbezit. De logistieke berichtfamilie is groot en complex en bestrijkt tactische logistieke coördinatie van individuele eenheidsbevoorradingsverzoeken tot planningen voor ondersteuning op theateerniveau. Voor ontwikkelaars zijn de meest geïmplementeerde logistieke berichten het Request for Supply (REQSUP), het Supply Situation Report (SUPSIT) en MEDEVAC-verzoekberichten.
Versierealiteit: ADatP-34-edities zijn niet altijd achterwaarts compatibel. Een systeem gebouwd op basis van Editie 5 kan Editie 7-berichten tegenkomen van een coalitie-partner met gewijzigde velddefinities of nieuwe verplichte elementen. Defensiesoftwareteams moeten berichtversiedetectie implementeren als een kernarchitectuuronderdeel — niet als bijzaak — en berichtparsers ontwerpen om gracieus te degraderen bij het tegenkomen van onbekende velden uit latere edities.
Parseren en serialisatie: bibliotheken en benaderingen
ADatP-34-berichten worden uitgedrukt in meerdere syntactische vormen, afhankelijk van het transportnetwerk en het tijdperk van implementatie. Verouderde NAVO-netwerken gebruiken Variable Message Format (VMF) — een compact binair coderingsformaat geoptimaliseerd voor smalbandige tactische radioverbindingen. Moderne IP-gebaseerde netwerken gebruiken steeds meer XML-codering conform de NATO XML Message Specification (NXMS), die dezelfde berichtsemantiek biedt als VMF maar in een voor mensen leesbare, schemagedateerde vorm. Ontwikkelaars moeten mogelijk beide vormen verwerken, met name in systemen die verouderde radiogebaseerde netwerken overbruggen met moderne IP-infrastructuur.
Voor VMF-parseren in C++ en Java zijn de primaire commerciële bibliotheken geleverd door Cubic Defense Systems en Northrop Grumman's Battle Management Solutions; open-source alternatieven zijn beperkt en typisch onvolledig in berichtdekking. Voor XML/NXMS-berichten zijn standaard XML-verwerkingsbibliotheken (libxml2 in C++, JAXB in Java, lxml in Python) voldoende, maar de ADatP-34 XML-schema's moeten worden verkregen bij NCIA en correct worden gerefereerd in de parseeringsrij. Schemavalidatie tijdens parseren is verplicht voor operationele systemen — misgevormde berichten stilzwijgend accepteren creëert data-integriteitsproblemen die moeilijk te diagnosticeren zijn in productie.
Codegeneratie vanuit de XML-schema's (met behulp van tools zoals Apache XMLBeans of JAXB's xjc-compiler) produceert getypte Java- of C++-klassen voor elk berichttype die handmatig velddingen elimineren en compile-time typeveiligheid bieden voor toegang tot berichtvelden. Deze benadering wordt sterk aanbevolen voor nieuwe ontwikkeling; handgecodeerde parsers voor ADatP-34-berichttypen zijn duur te onderhouden over catalogusedities.
Versieringsuitdagingen met verschillende catalogusedities
ADatP-34 wordt regelmatig bijgewerkt — de huidige editie in 2026 is Editie 9. Elke editie introduceert nieuwe berichttypen, wijzigt bestaande berichtstructuren en deprekeert of wijzigt soms de semantiek van bestaande velden. Coalitie-oefeningen bevatten routinematig systemen gebouwd op verschillende catalogusedities, wat compatibiliteitsuitdagingen creëert die op de applicatielaag moeten worden beheerd.
De praktische benadering is het implementeren van een berichtversie-onderhandelingslaag: wanneer een communicatiesessie tot stand wordt gebracht met een peersysteem, wisselen de systemen cataloguseditiemogelijkheden uit en stemmen af op de maximale editie die beide kunnen ondersteunen. Berichten worden vervolgens gegenereerd op het onderhandelde editieniveau. Dit vereist het onderhouden van editiespecifieke berichtserializers — niet slechts een enkele serializer bijgewerkt naar de huidige editie — wat complexiteit toevoegt maar onvermijdelijk is voor systemen die moeten samenwerken met een diverse set partnersystemen in de coalitie.
Cataloguseditiebeheer is ook een configuratiebeheeruitdaging: de ADatP-34 XML-schema's voor elke editie moeten versiebeheert worden in de systeemrepository, de parseerbibliotheek moet editiebewust zijn en regressietesten moeten interoperabiliteit dekken met vorige edities die partnersystemen mogelijk nog draaien. Teams die cataloguseditiebeheer behandelen als een kleine versiebeheertaak, ondervinden routinematig integratiefouten in coalitie-oefeningen die duur zijn om te diagnosticeren en corrigeren onder oefentijdsdruk.