ADatP-34 (NISP): Interoperabiliteitsstandaarden en -profielen van de NAVO, uitgelegd

ADatP-34 is het documentnummer van de Interoperabiliteitsstandaarden en -profielen van de NAVO (NISP) — de meestercatalogus van het bondgenootschap met de technische standaarden en interoperabiliteitsprofielen die communicatie- en informatiesystemen moeten gebruiken om samen te werken. Het is geen berichtcatalogus en geen data link-standaard: het is de driedelige referentie die een programma vertelt welke standaarden het moet implementeren, in welke editie en hoe sterk elk ervan bindt. Als u de NAVO-berichtformaten zocht: die leven in ADatP-3 (STANAG 5500) en APP-11 — ADatP-34 zegt tegen welke editie daarvan u moet bouwen.

Wat ADatP-34 is: de Interoperabiliteitsstandaarden en -profielen van de NAVO

Formeel is ADatP-34 een Allied Data Publication waarvan de inhoud het NISP is. Het schrijft de technische standaarden en profielen voor die nodig zijn voor interoperabiliteit van communicatie- en informatiesystemen (CIS) ter ondersteuning van de missies en operaties van de NAVO, en geeft de drie rollen die er dagelijks uit leven richting: capaciteitsplanners, programmamanagers en testmanagers. De huidige publiek uitgebrachte editie is ADatP-34 Edition N Version 2 (NISP version 15, 18 augustus 2023), genoteerd door de C3-raad van de NAVO en uitgebracht als vervanging van Edition N Version 1 (NISP v14, 2021).

Het NISP groeide uit de NATO C3 Technical Architecture (NC3TA), waarvan de laatste versie in 2005–2006 werd afgerond; het eerste NISP volgde in december 2006 en sindsdien wordt het document in een ruwweg jaarlijkse cyclus herzien. Waar de NC3TA een architectuurdocument was, is het NISP een catalogus met juridische tanden: conform de C3-strategie van het bondgenootschap houden alle entiteiten van het NATO Enterprise zich aan de verplichte standaarden en profielen uit zijn deel 2, en die standaarden binden de gezamenlijk gefinancierde systemen van de NAVO (het bredere STANAG/APP-landschap beschrijft interoperabiliteitsstandaarden van de NAVO voor software).

Het NISP verschijnt als drie delen in HTML en PDF, ondersteund door een doorzoekbare standaardendatabase en een gegevensexport in ArchiMate-formaat voor architectuurtools. De database achter de editie van 2023 bevat ongeveer 1.280 standaarden van zo'n 70 organisaties — IETF-rfc's, W3C-, OASIS-, OGC- en ISO-specificaties naast NAVO-STANAG's en geallieerde publicaties — plus zo'n 400 dienstprofielen. Het meeste is niet door de NAVO geschreven: het NISP neemt volwassen niet-NAVO-standaarden over en bindt ze in NAVO-profielen.

Wie onderhoudt ADatP-34: de C3-raad, de IP CaT en STANAG 5524

Het NISP wordt ontwikkeld door de Interoperability Profiles Capability Team (IP CaT) onder gezag van de NAVO-raad voor consultatie, commando en controle (C3B) — het hoogste multinationale orgaan voor het C3- en interoperabiliteitsbeleid van de NAVO. In december 2023 keurde de Noord-Atlantische Raad de hernoeming van de C3-raad naar het Comité voor Digitaal Beleid (DPC) goed, en het team voor interoperabiliteitsprofielen werkt onder dat comité door; in actuele NAVO-overzichten figureert het als het team van het DPC voor interoperabiliteitsstandaarden en -profielen (de NISP-database noteert het als "DPC IP iCaT"). Vroege NISP-edities werden geproduceerd door de NATO Open Systems Working Group, voordat het werk naar het toegewijde capabilityteam ging.

Het onderhoudsritme is jaarlijks en voorspelbaar, en dat telt bij roadmapplanning:

• Iedereen — een land, een NAVO-orgaan, een programma — dient bij de IP CaT een wijzigingsverzoek (RFC) in.
• RFC's die vóór 1 september binnenkomen, zijn gericht op de volgende release; de IP CaT bespreekt ze met de verantwoordelijke normalisatie-instanties.
• De nieuwe versie wordt na interne review vóór het einde van het jaar aan de C3-raad (nu DPC) aangeboden.
• Na goedkeuring wordt het NISP de NAVO-standaard gedekt door STANAG 5524, die de overeenkomst van de deelnemende landen vastlegt om zijn verplichte standaarden en profielen te gebruiken.

De levende database van de IP CaT — niet de een keer per jaar verschijnende pdf — is de definitieve bron voor de actuele status van elke standaard of elk profiel; conceptedities worden doorlopend bijgewerkt tussen officiële releases.

De delen van het NISP: wat deel 1, 2 en 3 bevatten

Sinds het midden van de jaren 2010 heeft het NISP een stabiele driedelige structuur (oudere edities waren anders ingedeeld — standaarden op korte en lange termijn, profielen en ontwerpregels in aparte delen). Elk deel heeft een eigen taak:

• Deel 1 — Inleiding. Basisconcepten (wat een standaard in NISP-termen is, wat een profiel is), het beheer- en configuratiebeheerframework, het RFC-proces en de richtlijnen voor profielontwikkeling in de bijlage. Lees het één keer: het is kort en definieert de woordenschat waarop de andere delen voortbouwen.
• Deel 2 — Overeengekomen interoperabiliteitsstandaarden en -profielen. De normatieve kern: de standaarden en profielen die verplicht zijn voor de gezamenlijk gefinancierde systemen van de NAVO, georganiseerd volgens de C3-taxonomie van de NAVO (baseline 5.0) onder koppen als User Applications, COI Services, Core Services en Communications Services. Het bevat ook de overeengekomen profielen, waaronder de Federated Mission Networking (FMN)-profielen Spiral 3 en Spiral 4 en enkele tientallen service-interfaceprofielen.
• Deel 3 — Kandidaat-interoperabiliteitsstandaarden en -profielen. Informatieve richting: standaarden en profielen die rijp genoeg zijn om er programma's tegen te plannen die binnen één à twee jaar starten, maar nog niet verplicht.

Deel 2 is normatief voor gezamenlijk gefinancierde NAVO-systemen; deel 3 is informatief. Die ene zin is precies het punt waar inkoopdocumenten meestal onopgemerkt de mist in gaan.

Verplicht versus kandidaat: de categorieën die bepalen wat u moet bouwen

Het NISP wijst elke opgenomen standaard en elk profiel een verplichtingsstatus met precieze betekenis toe:

• Verplicht (deel 2) — de toepassing van de standaard of het profiel wordt afgedwongen voor gezamenlijk gefinancierde NAVO-systemen bij planning, implementatie en tests. Landen zijn verplicht het NISP te gebruiken bij het ontwikkelen van capaciteiten die de missies van de NAVO ondersteunen, en worden uitgenodigd dezelfde regels nationaal toe te passen.
• Kandidaat (deel 3) — de standaard of het profiel mag alleen worden gebruikt voor tests en programmaplanning. Het moet voldoende rijp zijn en zal naar verwachting in de afzienbare toekomst verplicht worden; de eigen vuistregel van het NISP: een kandidaat hoort niet langer dan drie jaar in deel 3 te zitten.

Twee verdere onderscheidingen behoeden teams voor het verkeerd lezen van de catalogus. Ten eerste, verplichting is niet hetzelfde als levenscyclus: de eigen volwassenheid van een standaard (in studie/ratificatie, afgekondigd, vervangen — of, voor niet-NAVO-standaarden, emerging/mature/fading/obsolete) wordt gevolgd door het ontwikkelende orgaan, en voor NAVO-standaarden leven de gezaghebbende status en de nationale voorbehouden in de database van het NATO Standardization Office, niet in het NISP. Ten tweede, toepasbaarheid is geen conformiteit: het Basisstandaardenprofiel van het NISP koppelt standaarden aan elementen van de C3-taxonomie, maar of een standaard geldt voor een dienst die u implementeert, wordt beoordeeld in de context van uw project — het NISP zelf merkt op dat gegevensuitwisseling tussen C2- en logistieke systemen mogelijk slechts een subset van JC3IEDM-concepten (STANAG 5525) nodig heeft.

Voor niet-NAVO-standaarden past de IP CaT expliciete overnamecriteria toe — implementaties bij meerdere leveranciers, consensusgedeelde ontwikkeling, vrijheid van IP-belemmeringen, openheid, stabiliteit en testbaarheid — plus één conflictdie de moeite waard is om te onthouden: waar een overgenomen niet-NAVO-standaard conflicteert met een relevante NAVO-standaard, prevaleert de NAVO-definitie.

Interoperabiliteitsprofielen, SIOP's en hoe FMN-spiralen het NISP gebruiken

Standaarden alleen interopereren niet — profielen wel. In NISP-termen definiëren profielen het specifieke gebruik van standaarden op een service-interoperabiliteitspunt (SIOP), een referentiepunt in een architectuur waar een of meer service-interfaces worden geïnstantieerd, zodat systemen die dezelfde dienst over verschillende protocollen leveren kunnen samenwerken. De gedetailleerde technische specificatie van een SIOP ligt in een service-interfaceprofiel (SIP). Een profiel identificeert zijn capaciteitseisen en ondersteunende NAF-architectuurweergaven, de kenmerkende protocollen, implementatieopties, de technische standaarden, de SIOP's en zijn relaties met andere profielen — en profielen mogen naar andere profielen verwijzen om hergebruik te maximaliseren.

Profielen zijn uitdrukkelijk dynamisch: ze moeten worden bijgewerkt wanneer een standaard waarnaar ze verwijzen verandert, en profieleigenaren moeten ze elke twee jaar herzien. Hier ontmoet het NISP Federated Mission Networking. Elke FMN Spiral Specification bundelt architectuur, instructies, profielen en eisen voor een federatie-increment, en het NISP is de plek waar die profielen zichtbare verplichtingen worden: de FMN-profielen Spiral 3 en Spiral 4 staan als overeengekomen profielen in deel 2 van de editie 2023, terwijl het voorgestelde FMN Spiral 5-profiel als kandidaat in deel 3 zat. De FMN Management Group keurde de definitieve Spiral 6-specificatie in november 2025 goed, en haar profielen zullen vermoedelijk via dezelfde weg het NISP binnenkomen — als overeengekomen profielen in deel 2 na aanname (hoe de profielenset van een spiraal er in de praktijk uitziet, leest u in FMN Spiral 4-eisen).

Het NISP noemt ook de plekken waar profielconformiteit wordt bewezen: de eigen beoordelingscriteria vragen verantwoordelijke partijen of problemen met een standaard zijn vastgesteld tijdens testevenementen zoals CWIX en CIAV. Als u daarheen gaat, lees dan parallel de CWIX-voorbereidingsgids — de oefening test de profielen, niet de pdf.

ADatP-34 versus ADatP-3, APP-11, APP-6 en STANAG

Deze aanduidingen worden in eisendocumenten voortdurend door elkaar gehaald, dus hier is de ontdubbelingstabel. Kort: ADatP-34 is de catalogus; ADatP-3 en APP-11 zijn het militaire berichtenpaar waarnaar hij wijst; APP-6 is symbologie; STANAG is het ratificatie-instrument. Alle vier de publicaties staan zelf binnen ADatP-34 deel 2, met de exacte editie waaraan NAVO-systemen gebonden zijn.

Er bestaat dus zoiets niet als een "ADatP-34-bericht". De berichten die uw gateway parst, zijn ADatP-3/APP-11-berichttekst, J-seriewoorden van Link 16 (STANAG 5516 — zie Link 16 en tactische data links), VMF of een service-payload zoals MIP4; de symbologie die uw kaart tekent, wordt bepaald door APP-6 (vergelijking met zijn Amerikaanse tweeling: APP-6 versus MIL-STD-2525). De taak van ADatP-34 is te zeggen welke editie van elk daarvan actueel en bindend is, in welke profielcombinatie en op welke interface. Over het gegevensmodel van de landmacht dat dezelfde rol speelt in de wereld van beelduitwisseling: MIP4-IES.

Hoe een softwareteam het NISP gebruikt: van profiel naar conformiteitsmatrix

In de praktijk consumeert een C2-productteam het NISP in vier stappen, en het artefact dat dat oplevert — een conformiteitsmatrix — is wat beoordelaars, accreditatiemedewerkers en CWIX-planners daadwerkelijk vragen:

1. Map uw interfaces op SIOP's. Elke externe interface die uw product aanbiedt of verbruikt (spooruitwisseling, formele berichtgeving, chat, kaartdiensten, beveiligingslabeling) is een service-interoperabiliteitspunt. Geef ze namen; ze verankeren alles wat volgt.
2. Zoek elk op in deel 2. Vind het C3-taxonomieknooppunt voor die dienst in de standaardtabellen — elke rij geeft de titel, het publicatienummer, de profielen waarin de standaard wordt gebruikt en de verantwoordelijke partij die de NAVO erover adviseert. Mik uw programma op een FMN-federatie, begin dan bij het FMN-profiel en neem zijn standaardenlijst over. Bekijk deel 3 voor wat u midden in het programma treft.
3. Bouw de matrix. Noteer per SIOP de standaard, de exacte editie, uw conformiteitsscope (volledig of de subset die het NISP toestaat te rechtvaardigen), de verplichtingsstatus en het bewijs dat u zult leveren.
4. Bewijs het. Veranker de matrix in uw conformiteitstestsuite en oefen hem op een coalitietestevenement. Een matrixrij zonder testbewijs is een bewering, geen conformiteit.

Een conformiteitsmatrix voor een coalitie-C2-product tegen de editie 2023 ziet er ongeveer zo uit:

Versieer de matrix tegen de NISP-editie waaruit hij is opgebouwd en stel hem jaarlijks opnieuw in als baseline — het jaarlijkse releaseritme betekent dat edities onder lange programma's verschuiven. Voor de architectuurweergaven die de matrix begeleiden: de profielelementen van het NISP verwijzen naar het NATO Architecture Framework (NAF 4), en voor de informatiemodellaag onder MIP4 het NATO C2 Information Model.

Veelgemaakte fouten van ingenieurs met ADatP-34

• "ADatP-34-berichten" parsen. Die bestaan niet. De berichtinhoud is ADatP-3/APP-11 (zie de uitleg van ADatP-3 / STANAG 5500) of een tactische data link; ADatP-34 citeert ze slechts. Een "ADatP-34-parser" bouwen is een categoriefout die teams echte maanden heeft gekost.
• Onbegrensd "NISP-conformiteit" claimen. Conformiteit geldt per SIOP, per profiel, per editie. Een aanbieding met "NISP-compliant" zonder matrix leest voor een beoordelaar als ruis; een aanbieding met matrix niet.
• Alles op volledige conformiteit implementeren — of deel 2-standaarden als optioneel overslaan. Toepasbaarheid is geen conformiteit (subsets zijn te rechtvaardigen), maar verplicht betekent verplicht voor gezamenlijk gefinancierde NAVO-systemen op de SIOP's.
• Tegen een verouderde editie bouwen. Edition M, Edition N Ver 1 en Edition N Ver 2 verschillen in geciteerde edities van de onderliggende standaarden; een matrix die aan een vervangen editie vastgenageld is, overleeft de review niet. Volg de jaarlijkse release en de RFC-drempel van 1 september.
• Deel 3 negeren. Kandidaatstandaarden zijn juist degene die midden in een programma verplicht worden — het NISP verwacht dat kandidaten binnen ongeveer drie jaar doorgroeien. Plan ze in de roadmap, niet in het wijzigingsverzoek.
• Het NISP als statusregister behandelen. Ratificatiestatus en nationale voorbehouden van STANAG's leven in de database van het NATO Standardization Office; het NISP dupliceert ze bewust niet.

Krijgt u dit op orde, dan houdt ADatP-34 op een ondoorzichtig acroniem te zijn en wordt het wat het ontworpen was: dé checklist die "wij zijn interoperabel met de NAVO" omzet in een toetsbare engineeringstelling.