NAVO-interop-implementatie doorloop, deel 1: STANAG-selectie en ADatP-34-profielafstemming

De meest bepalende beslissing in een NAVO-interoperabel defensiesoftwareprogramma is welke STANAG's te implementeren — en cruciaal, welke niet. De lijst van NATO-standaardiseringsovereenkomsten loopt in de duizenden; de relevante subset voor een gegeven platform is begrensd maar van buitenaf nooit vanzelfsprekend. Een programma dat een te smalle STANAG-envelop kiest, mislukt coalitie-inzet zes maanden later; een programma dat een te brede envelop kiest, zinkt engineeringtijd in compliancewerk zonder operationele klant. Deze vierdelige serie legt uit hoe deze beslissingen goed te nemen. Deel 1 behandelt de basis: STANAG-selectie en ADatP-34-profielafstemming.

Het architectonisch kader voor deze serie staat in De complete gids voor NAVO-interoperabiliteit. De bijbehorende engineering doorloop voor het C2-platform dat deze standaarden gebruikt, staat in Een C2-systeem van scratch bouwen. Deze serie gaat specifiek in op het interop-subsysteem.

Stap 1: Stel de conformiteitsenvelop in voordat u iets anders doet

De conformiteitsenvelop is de set STANAG's die het platform zich verbindt te implementeren. De envelop is net zo goed een aanbestedingsdocument als een engineeringdocument — het verschijnt in RFP-antwoorden, in accreditatiedossiers en in de scoping van coalitie-oefeningen. Zet het vroeg goed neer en het engineeringswerk heeft duidelijke grenzen; zet het verkeerd neer en de werkscope verschuift gedurende de levensduur van het platform.

De vragen die de envelop definiëren:

• Echelon. Brigadeniveau en lager heeft andere STANAG-prioriteiten dan korps- of strategisch niveau. Een tactisch platform moet Link 16 en CoT spreken; een strategisch platform heeft dat misschien niet nodig maar moet MIP4 en de bredere staf-niveau catalogus spreken.
• Domein. Land, maritiem, lucht, gezamenlijk of multi-domein. Elk trekt verschillende STANAG-families aan — luchtafweer brengt Link 16 plus de omringende tijdsdistributie en berichtformaat STANAG's; maritiem brengt COMPD en AIS-integratie; grond brengt MIP4-IES.
• Coalitiepartners. Een platform dat bilateraal met de VS opereert, heeft andere behoeften dan een platform dat multilateraal over de NAVO opereert. Bilaterale relaties werken vaak met smallere subsets; multilaterale coalitie-inzet vereist de bredere ADatP-34-profielen.
• Classificatieplafond. Hogere classificatieniveaus brengen STANAG 4774/4778-bindingsvereisten met zich mee die platforms met lagere classificatie kunnen uitstellen.
• Tijdshorizon. Een platform dat over twee jaar in gebruik wordt genomen, kan de huidige STANAG-edities als doel stellen; een platform dat over vijf jaar in gebruik wordt genomen, moet de volgende spiral volgen en budget reserveren voor de versietransitie.

Schrijf de antwoorden op. Tag elk architectuurticket met welke envelop beslissing het dient. Het meest voorkomende faalpatroon in NAVO-interop-programma's is stille envelop-drift — een programma begint met het doel "tactische NAVO-interop" en eindigt met de implementatie van elke STANAG waarnaar wordt verwezen in RFI-antwoorden, zonder rationale voor welke operationeel vereist zijn.

Stap 2: Bouw de relevante STANAG-catalogus

De NAVO publiceert duizenden STANAG's; de softwarerelevante subset is in de lage honderden; de subset relevant voor een platform is gewoonlijk 20-40. Bouw de catalogus expliciet.

De catalogus legt voor elke kandidaat-STANAG vast:

• STANAG-nummer en editie. Versie is belangrijk: STANAG 4559 Editie 4 verschilt wezenlijk van Editie 3.
• Vriendelijke naam en omvang. Wat de norm in operationele termen beheerst — niet alleen "beeldenuitwisseling" maar "het uitwisselen van ISR-beelden van nationale bron tussen coalitie-C2-systemen".
• Operationele driver. Waarom dit platform het nodig heeft. "Vereist door aanbestedings-RFP" is niet voldoende; de operationele use case telt ook.
• Implementatie-inspanningsschatting. Ruwe categorisering: licht (minder dan 2 persoons-maanden), matig (2-6), zwaar (6-18), extreem (meer dan 18). De schatting is ruw; het doel is de kosten-batenverhouding vroeg naar boven te brengen.
• Bron van conformiteitstest. Waar de conformiteitstest wordt uitgevoerd — interne CI, NAVO CWIX, bilateraal met een specifieke partner, door leverancier geleverde testharness.
• Implementatiestatus. Niet gestart, in uitvoering, conformiteitsgetest, ingezet.

De catalogus is een levend document, opgeslagen in de programmarepositorium naast broncode, beoordeeld door engineering- en aanbestedingsleiders. De gedetailleerde behandeling van de grote STANAG-families — Link 16, MIP4, STANAG 4559, ADatP-34 — staat in NAVO-interoperabiliteitsnormen voor software.

Stap 3: Afstemmen op een ADatP-34-profiel

ADatP-34 is de NAVO-mastercatalogus van interoperabiliteitsprofielen. Waar individuele STANAG's normen afzonderlijk definiëren, definieert ADatP-34 combinaties — "tactisch brigadeprofiel", "operationeel korpsprofiel", "strategisch gezamenlijk profiel" — die de normen bundelen die samen worden gebruikt in echte operationele contexten.

De strategische implicatie: stem de conformiteitsenvelop van het platform af op een of meer ADatP-34-profielen, niet op ad-hoc STANAG-combinaties. Een platform dat beweert "wij implementeren Link 16, MIP4 en STANAG 4559" zonder het ADatP-34-profiel te noemen waarop het is afgestemd, maakt een niet-afgebakende claim die aanbestedingsevaluatoren moeilijk kunnen verifiëren.

De gedetailleerde analyse van ADatP-34 — inclusief de structurele anatomie, het profielversiebeheermodel en de aanbestedingsimplicaties — staat in ADatP-34-gegevensstructuren: wat NAVO-interoperabiliteit werkelijk vereist.

Voor het lopende voorbeeldplatform — een tactisch C2-systeem op brigadeniveau gericht op NAVO RESTRICTED coalitie-inzet — is het geschikte ADatP-34-profiel het tactisch operationeel profiel dat Link 16, MIP4-IES, CoT, STANAG 4559 (consumentzijde) en de ondersteunende catalogus van tijdsdistributie-, berichtformaat- en classificatie-STANAG's bundelt. Andere scopekeuzen zouden de profielkeuze verschuiven, maar niet de architectonische redenering.

Stap 4: Beslissen over FMN-spiralafstemming

Federated Mission Networking (FMN) Spiral is een aparte maar aangrenzende aanbestedingszorg. Waar ADatP-34 profielbundels definieert, definieert FMN een missie-netwerkcapaciteit die ze integreert met beveiligings- en serviceprofielvereisten. De huidige operationele spiral is Spiral 4; Spiral 5 is in ontwikkeling.

De vragen voor het programma:

Heeft het platform FMN-compliance nodig? Coalitie missie-netwerk inzet — Resolute Support-opvolgmissies, Allied Reaction Force, equivalenten — vereist FMN. Nationale inzet misschien niet. De programmabeslissing bepaalt de kostenenvelop aanzienlijk.

Welke spiral? Als inzet binnen 18 maanden, richt u zich op Spiral 4. Als inzet daarna, richt u zich op Spiral 5 met expliciete bewustheid dat de vereisten nog in beweging zijn. Een spiral overslaan is zelden haalbaar; het upgradewerk wordt een eigen meerjarig project.

Wat is het conformiteits testpad? FMN-compliance wordt bepaald door NAVO-conformiteitstest, niet door zelfbeoordeling. Testslots zijn beperkt en lang van tevoren gepland. Een programma gericht op Spiral 4 moet 12-18 maanden voor de beoogde inzet in de NAVO-conformiteitswachtrij staan.

De gedetailleerde FMN Spiral 4 engineeringvereisten staan in FMN Spiral 4: vereisten en implementatienotities.

Stap 5: Beslissen over niet-NAVO bilaterale vereisten

De meeste defensieplatforms opereren ook naast niet-NAVO-partners — Oekraïne, Israël, Japan, Australië, Korea onder anderen. Deze relaties introduceren normen buiten de NAVO-catalogus maar werken samen met de interop-envelop van het platform.

De meest voorkomende niet-NAVO-invoeren:

Oekraïense Delta en DZVIN-integratie. Bilaterale gegevensuitwisseling met Oekraïense C2-platforms gebruikt formaten buiten de NAVO-catalogus. Het engineeringpatroon, inclusief de Delta-formaatdetails en integratiebenadering, staat in Delta-formaat en Oekraïense militaire integratie. De Brave1-ecosysteemcontext staat in Het Brave1 defensie-ecosysteem.

Alleen-FVEY-protocollen. Five Eyes-partners delen inlichtingen over protocollen buiten de NAVO-catalogus. Platforms gericht op zowel NAVO als FVEY-contexten moeten de dubbele-track conformiteit verwerken.

Bilaterale nationale normen. De VS hebben aanvullende protocollen (CRD, JREAP-varianten) die niet formeel NAVO-normen zijn maar voorkomen in bilaterale programma's. Het VK, Frankrijk en Duitsland hebben nationale overlays. Elk is een programmaspeficieke beslissing.

De niet-NAVO-invoeren vervangen de NAVO-conformiteitsenvelop niet; ze breiden hem uit. Documenteer ze in de catalogus naast STANAG's, met hun eigen implementatiestatus en conformiteits testpad.

Stap 6: STANAG-versie en spiral strategie

STANAG's evolueren. Edities veranderen, berichtformaten breiden uit, vereisten worden strenger. Het platform moet een expliciete strategie hebben voor de versietransities die zullen plaatsvinden gedurende zijn operationele levensduur.

Het patroon dat werkt:

Volg huidige operationele edities. Het platform implementeert de edities die huidige NAVO-operationele inzetten vereisen. Oudere edities blijven ondersteund voor achterwaartse compatibiliteit; nieuwere edities worden gevolgd maar niet geïmplementeerd totdat operationeel vereist.

Plan transities expliciet. Wanneer een nieuwe editie operationeel vereist wordt, is de transitie een gepland project met zijn eigen engineeringbudget, conformiteitshertesten en accreditatie-update. Het behandelen van de transitie als routineonderhoud levert meerjarige vertraging op.

Onderhoud dual-editieondersteuning tijdens transities. Echte inzetten overspannen edities. Het platform ondersteunt beide voor de duur van het coalitietransitievenster.

Neem deel aan het standaarden-ontwikkelingsproces. Leveranciers met significante programma-exposure nemen deel aan NAVO-standaarden-werkgroepen. De deelname brengt aankomende wijzigingen vroeg naar boven, geeft het team een stem in de vereisten en biedt inlichtingen die aanbestedingsconcurrenten niet hebben.

Stap 7: Repositoriumstructuur voor interop-code

Interop-code is gevoelig — het verkeerd aanraken breekt coalitie-inzet. Repositoriumdiscipline vermindert het risico.

De structuur die werkt:

• interop/stanags/<stanag-id>/ — één map per STANAG, met zijn eigen implementatie, conformiteitstesten en documentatie.
• interop/profiles/<adatp-34-profiel>/ — profielaggregaties die individuele STANAG-implementaties samenvoegen.
• interop/conformance-tests/ — geautomatiseerde testsuites, met submappen die overeenkomen met de conformiteitstest bron (CI, CWIX-voorbereiding, bilaterale testplannen).
• interop/catalogue.md — de levende STANAG-catalogus.
• interop/profile-decisions/ — Architectuurbeslisrecords die de keuzes van de conformiteitsenvelop documenteren.

De structuur maakt het interop-werk controleerbaar, laat individuele STANAG's onafhankelijk evolueren en ondersteunt de conformiteits-test workflow die releases bewaakt.

Wat volgt

Deel 1 heeft het interop-subsysteem ingekaderd. Conformiteitsenvelop afgebakend, STANAG-catalogus gebouwd, ADatP-34-profielafstemming gekozen, FMN-spiralbeslissing genomen, bilaterale vereisten gedocumenteerd, versiestrategie expliciet, repositoriumstructuur vastgesteld. Het platform heeft nu een verdedigbaar aanbestedingsverhaal; het implementatiewerk volgt.

Deel 2 gaat in op de implementatie van de tactische datalinkverbindingen die de meeste NAVO-interoperabele platforms verankeren — Link 16, CoT, MIP4. Hardware-integratie, berichtmarshalling, bouw van conformiteitsharness en de engineeringdisciplines die coalitie-oefeningen overleven.