Interoperabiliteit

NAVO C2-informatiemodel: NCIM-implementatie en data-uitwisseling

Door Corvus Intelligence Engineering Team · Over het team →

25 juni 2026 12 min leestijd

Het NAVO C2-informatiemodel — NCIM — is de canonieke semantische fundering onder de standaarden voor command-and-control-data-uitwisseling van de Alliantie. Waar ADATP-34-datastructuren berichtformaten definiëren en de MIP4 IES NAVO-grondstandaard uitwisselingsprotocollen voor landstrijdkrachten definieert, staat NCIM één laag boven beide: het definieert welke soorten dingen bestaan in een C2-operatie, hoe die dingen zich tot elkaar verhouden en welke data over elk van hen moet worden vastgelegd. Elke NAVO-implementatiestandaard die operationele data uitwisselt, beeldt zijn structuren af op NCIM. NCIM begrijpen is daarmee niet optioneel voor engineers die het bredere landschap van NAVO-C2-standaarden willen navigeren — het is de gedeelde referentie die de rest van de complete gids over NAVO-interoperabiliteit samenhangend maakt.

Wat NCIM is en waarom het bestaat

Het C2-interoperabiliteitsprobleem van de Alliantie in de jaren 1990 was in de eerste plaats geen protocolprobleem — het was een semantisch probleem. NAVO-landen hadden C2-systemen geïmplementeerd die berichten uitwisselden, maar hetzelfde veld in de systemen van twee landen betekende iets anders. Een “eenheidsstatus” van “OPERATIONAL” in het ene systeem dekte een andere gereedheidsdrempel dan in het andere. Wanneer systemen data uitwisselden, werden de bytes ontvangen maar de betekenis niet gedeeld. Dit is het probleem waarvoor NCIM is gecreëerd.

NCIM (NATO C2 Information Model) is het canonieke conceptuele en logische datamodel van de Alliantie voor command-and-control-informatie. Het definieert de typen entiteiten die deelnemen aan C2-operaties, de relaties tussen die entiteiten en de attributen — met hun datatypes en waardedomeinen — die over elk entiteitstype moeten worden vastgelegd om operationele informatie-uitwisseling te ondersteunen. Het definieert geen wire-formats, netwerkprotocollen of serialisatie — dat is de verantwoordelijkheid van implementatiestandaarden die NCIM als hun semantische autoriteit refereren.

De afstamming van NCIM loopt via verschillende voorgangers. JC3IEDM (Joint Consultation, Command and Control Information Exchange Data Model) was het eerste allesomvattende C2-datamodel van de Alliantie, eind jaren 1990 collaboratief door NAVO-landen ontwikkeld als formeel gespecificeerd relationeel model dat het volledige spectrum aan operationele data dekte. JC3IEDM werd opgevolgd door NC2IEDM (NATO C2 Information Exchange Data Model), dat het entiteitsmodel verfijnde en uitbreidde naar gezamenlijke operaties in alle domeinen. NCIM vertegenwoordigt de huidige evolutie: een model met afzonderlijke conceptuele en logische lagen, uitgelijnd op moderne principes van informatiearchitectuur en ontworpen als moedermodel waaruit domeinspecifieke implementatiestandaarden als profielen worden afgeleid.

De relatie tot andere NAVO-datastandaarden is direct. Het MIP4-datamodel — dat Unit, Equipment, Task en verwante entiteitstypes definieert voor C2-uitwisseling van landstrijdkrachten — is een landdomeinprofiel van NCIM. De berichtstructuren in ADatP-34 zijn georganiseerd volgens NCIM-semantiek: elk ADatP-34-berichttype correspondeert met een patroon van NCIM-entiteitsinstanties. C-BML (Coalition Battle Management Language), de XML-taal voor machineverwerkbare bevelen, gebruikt de entiteitstypes Activity en Plan van NCIM als semantische fundering. De entiteitstypehiërarchie en relatie-semantiek van NCIM begrijpen levert daarmee het gedeelde referentiekader om MIP4, ADatP-34 en C-BML als één samenhangend systeem te navigeren in plaats van als drie onafhankelijke standaarden.

NCIM-entiteitstypehiërarchie

NCIM definieert zes entiteitstypes op het hoogste niveau. Deze zes typen dekken samen elke categorie informatie die in een NAVO-C2-operatie voorkomt, en elke entiteit in een datamodel op implementatieniveau herleidt tot precies één ervan.

Activity is het entiteitstype voor geplande of werkelijke acties. Missies, taken, fasen van een operatie, gevechtscontacten en gemelde gebeurtenissen zijn allemaal Activities in NCIM. Activity heeft subtypen voor verschillende actiecategorieën: Task (een gerichte actie toegewezen aan een Organisation of Resource), Mission (een richtlijn op hoger niveau die meerdere Tasks omvat) en Event (een spontane gebeurtenis die wordt gemeld in plaats van toegewezen). De Activity-hiërarchie is de primaire structuur waarmee operationele bevelen worden gerepresenteerd in op NCIM gebaseerde systemen.

OperationalObject dekt entiteiten die worden gevolgd, als doelwit aangemerkt of gemonitord, maar zelf geen actoren zijn. Doelen, interessegebieden, genomineerde punten, dreigingsbeoordelingen en inlichtingenrapporten over vijandelijke eenheden zijn OperationalObjects. Het onderscheid met Organisation en Resource (die bevriende of neutrale entiteiten met bekende identiteit vertegenwoordigen) is significant: een OperationalObject kan een onzekere identiteit en onzekere locatie hebben en kan een hypothese zijn in plaats van een bevestigde waarneming.

Organisation vertegenwoordigt gestructureerde groeperingen van personeel met commandorelaties. Militaire eenheden op alle echelons (peloton, compagnie, bataljon, brigade, divisie) zijn Organisations. De Organisation-hiërarchie legt de commandostructuur vast via ouder-kindrelaties tussen Organisation-instanties, waarbij elke Organisation een standaardaanduiding heeft, een organisatietype uit de NAVO-ORBAT-taxonomie en een commandorelatie tot zijn bovenliggende Organisation (command, support, operational control, tactical control).

Resource dekt materieel en personeel als afzonderlijke items in plaats van georganiseerde groepen. Een specifiek voertuig, een wapensysteem, een communicatieapparaat of een individuele persoon die in een specifieke rol optreedt, is een Resource. Resources zijn via toewijzings- en uitrustingsrelaties verbonden met Organisations — een bataljon (Organisation) heeft bijbehorende voertuigen (Resource), en de uitrustingsrelatie draagt de toewijzingsstatus en het datumbereik. Het onderscheid tussen Organisation en Resource komt ongeveer overeen met het onderscheid tussen eenheden en uitrusting in een orde van slag.

Location is het entiteitstype voor alle positionele en geometrische informatie. De ontwerpbeslissing van NCIM om Location een eersteklas entiteitstype te maken — in plaats van coördinaten als attributen op andere entiteitstypen in te bedden — heeft belangrijke gevolgen voor de implementatie. Een Location-instantie draagt geometrie (punt, polylijn, polygoon, corridor of composiet), het coördinaatreferentiesysteem, een schatting van de positionele onzekerheid, een geldigheidstijdvenster en een indicator van de positiebron. Andere entiteitstypen refereren Location bij identifier in plaats van coördinaten in te bedden. Dit ontwerp stelt dezelfde Location in staat door meerdere entiteiten te worden gerefereerd, ondersteunt het koppelen van onzekerheids- en geldigheidsmetadata aan positiedata en maakt het mogelijk positiegeschiedenis te modelleren als een reeks Location-instanties verbonden met één Organisation of Resource.

Plan is het entiteitstype voor operationele planningsproducten. Een operatieplan, een fragmentarisch bevel, een faseovergangsbevel of een concept of operations-document is in NCIM een Plan. Het entiteitstype Plan heeft subtypen voor verschillende categorieën planningsproducten en draagt relaties naar de Activities die het aanstuurt, de Organisations die het taakstelt en de Locations die het als doelen toewijst.

De overervingsstructuur binnen elk van deze zes typen is significant voor de implementatie. Binnen Activity is de volledige overervingsketen bijvoorbeeld: Activity → Task → ControlMeasureTask (een taak die het plaatsen of verwijderen van een controlemaatregel aanstuurt) — elk niveau voegt attributen toe die specifiek zijn voor dat subtype terwijl alle attributen van de ouder worden geërfd. Implementatiestandaarden selecteren de overervingsdiepte die zij nodig hebben: MIP4 implementeert Task en enkele van zijn subtypen; C-BML implementeert de volledige Activity-hiërarchie tot aan elementaire taaktypen uit de NAVO-taxonomie van tactische taken.

Operationele planstructuren in NCIM

Het entiteitstype Plan en zijn relaties met Activity-instanties vormen de ruggengraat van de representatie van operationele planningsproducten in NCIM. Deze structuur begrijpen is essentieel voor de implementatie van elk NAVO-C2-systeem dat plannen, bevelen of hun uitvoeringsstatus moet uitwisselen.

Op het hoogste niveau representeert een Plan-instantie een volledig operationeel planningsproduct — een OPLAN, OPORD, FRAGO of CONOPS. Een Plan draagt een unieke identifier, een classificatie- en vrijgavelabel, een autoriteit (de Organisation die het uitgaf), een geldigheidsperiode en een status (concept, goedgekeurd, vervangen). Plans zijn onderling verbonden via een vervangingsketen: een FRAGO die een bestaande OPLAN wijzigt, refereert de OPLAN die hij vervangt, waarmee een plangeschiedenis ontstaat waarmee systemen de evolutie van het operationele plan kunnen reconstrueren.

Een Plan is gestructureerd in Phase-instanties — elke Phase vertegenwoordigt een afgebakende periode van operaties met gedefinieerde overgangsvoorwaarden. In NCIM is Phase een subtype van Activity dat via een planContains-relatie met een Plan is verbonden. Phase-instanties worden gesequenceerd via overgangsvoorwaarden: een Phase B-instantie heeft een startCondition die refereert aan een tijdstip (D+3) of een gebeurtenis (voltooiing van het doel van Phase A). Structuren op faseniveau komen voor in het OPLAN-berichtformaat van ADatP-34 en zijn rechtstreeks geïmplementeerd in de bevelrepresentatie van C-BML.

Binnen elke Phase vertegenwoordigen Task-instanties toegewezen acties. Een NCIM-Task draagt: een unieke identifier, een taaktype uit de NAVO-taxonomie van tactische taken (SEIZE, ATTACK, DEFEND, SCREEN, COVER, SUPPORT BY FIRE en tientallen andere), de getaakste Organisation of Resource, de doel-Location (een punt, gebied of benoemde locatie), de tijdsbeperkingen (vroegste start, laatst mogelijke start, vereiste voltooiing), de uitgevende autoriteit en de referentie naar het uitgevende Plan. De relatie tussen Task en Organisation is de NCIM-uitdrukking van “eenheid X heeft als taak doel Y” — de fundamentele C2-informatie-uitwisseling.

Objective-instanties in NCIM verfijnen het doel van de Task: een Objective draagt het specifieke operationele doel dat de Task moet bereiken, uitgedrukt als een te vestigen toestand (terrein veroverd, vijand vernietigd, route vrijgemaakt) in plaats van alleen een geografische locatie. Het onderscheid is van belang voor machineverwerkbare bevelen: een C-BML-systeem dat een taak ontvangt, kan het conditiontype van het Objective gebruiken om te bepalen wanneer de taak voltooid is, wat geautomatiseerde voortgangsrapportage mogelijk maakt zonder menselijke interpretatie.

Constraint-instanties koppelen beperkende voorwaarden aan Tasks en Plans. Constraints in NCIM zijn getypeerd: een temporele constraint beperkt het tijdvenster voor een activiteit; een geografische constraint beperkt het gebied waarbinnen een resource mag opereren; een resource-constraint beperkt welke middelen voor een taak gebruikt mogen worden. Constraints worden gerefereerd vanuit zowel Task-instanties (beperking van een specifieke taak) als Plan-instanties (geldig over de hele operatie). Het NCIM-constraintmodel is de semantische basis voor de codering van rules of engagement in coalitie-C2-systemen die interoperabiliteit met nationaal rules-of-engagement-beleid moeten afdwingen.

<!-- NCIM Plan / Phase / Task hierarchy — simplified XSD sketch -->
<xs:complexType name="PlanType">
  <xs:sequence>
    <xs:element name="planId"      type="ncim:UniqueIdType"/>
    <xs:element name="authority"   type="ncim:OrganisationRefType"/>
    <xs:element name="phase"       type="ncim:PhaseType" minOccurs="1"
                                   maxOccurs="unbounded"/>
    <xs:element name="constraint"  type="ncim:ConstraintType"
                                   minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="PhaseType">
  <xs:sequence>
    <xs:element name="phaseId"         type="ncim:UniqueIdType"/>
    <xs:element name="phaseNumber"     type="xs:integer"/>
    <xs:element name="startCondition"  type="ncim:ConditionType"/>
    <xs:element name="task"            type="ncim:TaskType"
                                       minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="TaskType">
  <xs:sequence>
    <xs:element name="taskId"        type="ncim:UniqueIdType"/>
    <xs:element name="taskType"      type="ncim:TacticalTaskCodeType"/>
    <xs:element name="taskedUnit"    type="ncim:OrganisationRefType"/>
    <xs:element name="objectiveLoc"  type="ncim:LocationRefType"/>
    <xs:element name="timeWindow"    type="ncim:TimeWindowType"/>
    <xs:element name="objective"     type="ncim:ObjectiveType"
                                     minOccurs="0"/>
  </xs:sequence>
</xs:complexType>

Resource- en uitrustingmodellering

De hiërarchie van het entiteitstype Resource in NCIM levert de structuren om platforms, uitrustingsets en organisatieonderdelen te representeren als afzonderlijke materieelitems en personeel. Resource-modellering is kritiek voor coalitie-C2-systemen die orde van slag-data moeten uitwisselen, inclusief uitrustingsstatus en capabilityverklaringen.

Platform is het primaire subtype van Resource voor fysieke systemen — voertuigen, vliegtuigen, schepen en wapensystemen. Een Platform-instantie in NCIM draagt een referentie naar het platformtype (uit een gecontroleerde woordenlijst in lijn met NAVO-classificatiecodes voor uitrusting), een serie- of registratie-identifier, een operationele statuscode (fully mission capable, partially mission capable, non-mission capable) en een referentie naar de huidige Location. Platform-instanties zijn via een Equipage-relatie verbonden met Organisation-instanties; die relatie draagt de toewijzingsperiode en het toewijzingstype (organisch, toegewezen, operationele controle). Dit is de NCIM-uitdrukking van een entry in de orde van slag: de Organisation is het bataljon, de Platform-instanties zijn de voertuigen, en de Equipage-relaties registreren welke voertuigen op dit moment aan welke eenheden zijn toegewezen.

Voor gevallen waarin afzonderlijke platforms niet apart worden gevolgd (gebruikelijk bij handvuurwapens, communicatie-uitrusting en bepaald steunmaterieel), biedt NCIM EquipmentSet: een subtype van Resource dat een hoeveelheid gelijksoortige items vertegenwoordigt in plaats van afzonderlijk gevolgde items. Een EquipmentSet draagt het itemtype, een hoeveelheid, een maateenheid en een geaggregeerde gereedheidstoestand. EquipmentSet-instanties verschijnen in logistieke rapportagescenario's waar brutte hoeveelheden operationeel relevanter zijn dan het volgen van afzonderlijke items.

OrganisationUnit overbrugt de entiteitstypen Resource en Organisation voor gevallen waarin een specifiek team, bemanning of sectie zowel als resource (met uitrusting) als als organisatorisch element (met commandorelaties) moet worden gerepresenteerd. Een helikopterbemanning is bijvoorbeeld een OrganisationUnit: zij heeft een toegewezen vliegtuig (Resource-relatie) en een rapportagehiërarchie (Organisation-relatie). Het subtype OrganisationUnit van NCIM maakt deze dubbele identiteit mogelijk zonder inconsistentie in het datamodel te creëren.

Capabilityverklaring is een belangrijk gebruiksdoel voor coalitie-Resource-modellering. NCIM ondersteunt Capability als attributencategorie op zowel Organisation als Resource, met een gecontroleerde woordenlijst in lijn met de NAVO-capabilitytaxonomie. De capabilityverklaring van een eenheid — welke missietypen zij is toegerust en getraind om uit te voeren — wordt gerepresenteerd als een set Capability-referenties op de Organisation-instantie. Bij coalitieplanning gebruikt het proces dat Task aan Organisation toewijst de Capability-referenties om taken te matchen met voldoende capabele eenheden. In geautomatiseerde C2-systemen kan deze matching machinaal worden uitgevoerd; in operatorgedreven systemen ondersteunen de capabilitydata de eenheidskeuze van de operator in het taakstellingsproces.

<!-- NCIM Resource / Equipage — illustrative XML fragment -->
<ncim:Resource xsi:type="ncim:PlatformType">
  <ncim:resourceId>{a4c12f88-3e7b-4d1a-b962-9f0d55c12e34}</ncim:resourceId>
  <ncim:platformType>NATO_EQPT_CODE:CV90</ncim:platformType>
  <ncim:serialId>SE-CV90-0147</ncim:serialId>
  <ncim:operationalStatus>FMC</ncim:operationalStatus>
  <ncim:currentLocation ref="{loc-uuid-0a1b2c}"/>
  <ncim:confidentiality>NATO RESTRICTED</ncim:confidentiality>
  <ncim:releasability>NATO</ncim:releasability>
</ncim:Resource>

<ncim:Equipage>
  <ncim:organisation ref="{org-uuid-battalion-42}"/>
  <ncim:resource     ref="{a4c12f88-3e7b-4d1a-b962-9f0d55c12e34}"/>
  <ncim:assignmentType>ORGANIC</ncim:assignmentType>
  <ncim:validPeriod>
    <ncim:startDTG>2026-06-01T06:00:00Z</ncim:startDTG>
  </ncim:validPeriod>
</ncim:Equipage>

XML- en JSON-serialisatie

NCIM is een conceptueel en logisch model — het definieert semantiek, geen bytes. Serialisatie naar wire-formats is de verantwoordelijkheid van de implementatiestandaarden die NCIM als moedermodel gebruiken. Begrijpen hoe NCIM-semantiek op XML en in toenemende mate op JSON wordt afgebeeld, is essentieel voor ontwikkelaars die uitwisselingslagen tussen coalitiesystemen bouwen.

Het primaire serialisatieformaat voor op NCIM gebaseerde uitwisseling is XML. Het NCIM XML-Schema is opgebouwd als een set XSD-modules, één per groep NCIM-entiteitstypen, georganiseerd onder een gemeenschappelijke namespace-hiërarchie. De namespace op het hoogste niveau is urn:int:nato:ncim:3 (voor NCIM-versie 3.x), met sub-namespaces voor elke domeinmodule: urn:int:nato:ncim:3:core voor de kern-entiteitstypen, urn:int:nato:ncim:3:land voor landdomein-uitbreidingen, enzovoort. Implementatiestandaarden die profielen van NCIM zijn, definiëren eigen namespaces die de relevante NCIM-modules importeren en beperkingen op implementatieniveau toevoegen (verplichte velden, beperkingen op gecontroleerde woordenlijsten, aanscherping van cardinaliteiten).

Namespacebeheer in NCIM-XML is een praktische uitdaging. Een typisch coalitie-C2-bericht dat entiteiten uit meerdere NCIM-modules refereert, draagt vijf tot acht actieve namespace-declaraties in het rootelement. Het risico zijn botsende namespace-prefixen wanneer berichten uit meerdere bronnen tot een gecombineerd beeld worden samengevoegd: twee berichten kunnen beide het prefix ncim declareren maar het op verschillende NCIM-module-namespaces afbeelden. De juiste aanpak is het normaliseren van namespace-prefixen bij het binnenhalen van berichten — resolveer alle namespace-declaraties naar hun canonieke URI en gebruik door de hele verwerkingspijplijn heen op URI geïndexeerde namespace-maps in plaats van op prefix geïndexeerde maps.

Voor tactische netwerken met beperkte bandbreedte is de breedsprakigheid van XML een aanzienlijk nadeel. Een als volledige XML geserialiseerde NCIM-entiteit met alle namespace-declaraties en opening- en sluittags kan vier tot zes keer groter zijn dan de essentiële nuttige data. In de praktijk worden drie benaderingen gebruikt:

EXI (Efficient XML Interchange): een W3C-binaire XML-codering die de volledige XML-semantiek behoudt en de grootte met 80–95% vermindert, afhankelijk van de schemadichtheid. EXI is de voorkeursbenadering voor beperkte tactische links wanneer XML-round-tripbaarheid vereist is. NCIM-schema's zijn zonder aanpassing EXI-compatibel.
Schema-geïnformeerde compressie: schema-bewuste DEFLATE- of LZ4-compressie toepassen op de byte-stream van de XML. Behaalt goede compressieverhoudingen (60–75% groottevermindering) tegen lagere rekenkosten dan EXI, maar zonder echte portabiliteit van een binair formaat.
JSON-serialisatie: de RESTful binding van MIP4-IES gebruikt JSON voor de representatie van afzonderlijke objecten, waarbij NCIM-entiteitsattributen op JSON-objecteigenschappen worden afgebeeld. JSON-payloads zijn 30–40% kleiner dan equivalente XML en integreren natuurlijker met moderne REST-clientbibliotheken. De afweging is dat JSON-schematooling voor NCIM minder volwassen is dan XSD-tooling, en round-trip-validatie tegen het normatieve NCIM-model vraagt zorgvuldig schemabeheer.

// NCIM Organisation — JSON representation (MIP4-IES REST binding)
{
  "@type": "ncim:Organisation",
  "objectId": "b7e4a312-9c0f-4a1e-8d53-1f3a8b0c9e21",
  "creatorId": "SYS-NLD-C2-01",
  "createdDTG": "2026-06-25T08:00:00Z",
  "modifiedDTG": "2026-06-25T09:14:37Z",
  "validity": "ACTIVE",
  "designation": "42 BN 1 INF BDE",
  "organisationType": "NATO_ORG:INFANTRY_BATTALION",
  "parentOrganisation": {"ref": "org-uuid-brigade-1"},
  "commandRelationship": "ORGANIC",
  "operationalStatus": "OPERATIONAL",
  "currentLocation": {"ref": "loc-uuid-7f3c2d"},
  "capability": ["CAP:DIRECT_FIRE", "CAP:DEFENSIVE_OPERATIONS"],
  "confidentiality": "NATO CONFIDENTIAL",
  "releasability": ["NLD", "DEU", "POL", "NATO"]
}

NCIM implementeren in een coalitie-C2-systeem

De meeste coalitie-C2-systemen bereiken NCIM-implementatie via een van twee paden: een nieuw systeem dat vanaf het begin rond NCIM-semantiek is ontworpen, of een nationaal legacy-systeem dat voor coalitie-interoperabiliteit wordt aangepast. Het tweede geval is verreweg het meest voorkomend en het meest uitdagend.

Adapterontwerp voor nationale datamodellen is de praktische benadering voor integratie van legacy-systemen. In plaats van het interne datamodel van een nationaal C2-systeem te refactoren naar NCIM — een meerjarige inspanning met aanzienlijk operationeel risico — concentreert het adapterpatroon alle NCIM-mappingbeslissingen in een afzonderlijk adaptercomponent. De adapter vertaalt voor alle externe data-uitwisselingen tussen het nationale model en NCIM-conforme representaties: inkomende coalitiedata wordt voor intern gebruik naar het nationale model vertaald; uitgaande nationale data wordt voor coalitie-uitwisseling naar NCIM vertaald. De adapter is de interoperabiliteitsgrens en het enige component dat moet wijzigen wanneer de NCIM-basislijn wordt bijgewerkt.

De belangrijkste beslissing in het adapterontwerp is bepalen welke NCIM-entiteitstypen volledige vertaling nodig hebben en welke oppervlakkige. Volledige vertaling — waarbij elk NCIM-attribuut een corresponderende interne representatie heeft — is vereist voor entiteitstypen die voorkomen in bidirectionele data-uitwisseling. Oppervlakkige vertaling — waarbij alleen sleutel-identifiers en statuscodes worden afgebeeld — is acceptabel voor entiteitstypen die het systeem consumeert maar nooit wijzigt of aanmaakt. Geef prioriteit aan volledige vertaling voor Organisation, Resource (Platform), Activity (Task) en Location; oppervlakkige vertaling is op adapterniveau doorgaans voldoende voor Constraint en Objective.

NCIM-naar-CoT-mapping is vereist voor systemen die data uitwisselen met platforms die Cursor on Target (CoT) gebruiken, het XML-schema van ATAK, WinTAK en verwante tools voor situatiebewustzijn. CoT is niet van NCIM afgeleid, maar een mapping tussen beide is in de praktijk goed gedefinieerd. Het CoT-element <event> beeldt af op NCIM Resource (voor platforms en personeel) of OperationalObject (voor tracks en contacten), waarbij het attribuut type wordt afgebeeld op het NCIM-entiteitstype en de platformtypereferentie. Het CoT-element <point> beeldt af op NCIM Location (subtype Point) met coördinaattransformatie indien nodig (CoT gebruikt WGS-84 decimale graden, consistent met de basis-CRS van NCIM). Het belangrijkste structurele verschil is dat CoT positiedata in het event-element inbedt, terwijl NCIM deze externaliseert als Location-entiteit — de adapter moet bij inkomende vertaling uit elke CoT-point een Location-instantie creëren en bij uitgaande vertaling de coördinaten van de gerefereerde Location in de CoT-point inbedden.

NCIM-naar-MIP-bridging is de meest voorkomende coalitie-adaptatie-eis voor land-C2-systemen. Het datamodel van MIP4 is een landdomeinprofiel van NCIM, dus de mapping is geen vertaling tussen ongerelateerde modellen — het is een projectie van een breder model (NCIM) naar een beperkt profiel (MIP4). De belangrijkste verschillen die mappinglogica vereisen zijn: MIP4 gebruikt OID (een op UUID gebaseerde wereldwijd unieke identifier) als primaire identifier, terwijl NCIM een generieke UniqueId gebruikt die in andere implementatiestandaarden een andere codering kan hebben; het inactivatiemodel van MIP4's BaseObject (geldigheidsvlag) beeldt af op het entiteitsgeldigheidsattribuut van NCIM; en het Locatiemodel van MIP4 gebruikt een iets andere representatie van onzekerheid dan het type GeometricExtent van NCIM. Deze verschillen zijn overbrugbaar zonder dataverlies, maar vereisen zorgvuldige implementatie van de randgevallen.

Semantische-equivalentietests: Vóór deelname aan CWIX moeten systemen semantische-equivalentietests uitvoeren — een gestandaardiseerde set NCIM-entiteitsinstanties met een partnersysteem uitwisselen en verifiëren dat de interne representatie van de ontvangen data bij de partner overeenkomt met de intentie van de zender. Syntactische conformiteit (geldige XML, correct schema) garandeert geen semantische equivalentie (dezelfde betekenis). Operationele fouten door semantische mismatch — een eenheidsstatus gelezen als OPERATIONAL terwijl de zender DEPLOYED AWAITING ORDERS bedoelde — zijn moeilijker te detecteren en hebben grotere gevolgen dan syntactische fouten.

NCIM-evolutie en -governance

NCIM wordt onderhouden door de NATO C3 Board (C3B), het governance-orgaan van de Alliantie voor standaarden voor communicatie- en informatiesystemen. De C3B werkt via een werkgroepstructuur: de C2 Information Exchange Working Group (C2IEWG) is het orgaan dat verantwoordelijk is voor het onderhoud van NCIM, met deelname van de ministeries van Defensie van NAVO-landen, nationale defensie-ICT-agentschappen en industriële vertegenwoordigers via het NATO-industrieforumproces.

De standaardenlevenscyclus van NCIM volgt het standaardproces van de Alliantie: een wijzigingsvoorstel wordt met rationale en impactanalyse bij de C2IEWG ingediend; de werkgroep toetst het voorstel op consistentie met afhankelijke standaarden (omdat een wijziging aan NCIM doorwerkt in MIP4, ADatP-34 en C-BML, moet de impactanalyse alle drie dekken); na goedkeuring door de werkgroep volgt een commentaarperiode voor lidstaten; en na afhandeling van de commentaren wordt de wijziging opgenomen in de volgende NCIM-revisie en via NCIA gepubliceerd. Grote versie-incrementen (NCIM 2.x naar 3.x) hebben meerjarige doorlooptijden vanwege de cascaderende impact op implementatiestandaarden; kleine revisies binnen een grote versie verschijnen jaarlijks.

Het profielmechanisme is het belangrijkste instrument voor missiespecifieke uitbreidingen zonder het basismodel te wijzigen. Een profiel is een formeel gedefinieerde, beperkte of uitgebreide weergave van NCIM voor een specifiek domein of missietype. Profielen worden door de C3B gepubliceerd als bijlagen bij NCIM, na hetzelfde beoordelings- en goedkeuringsproces als wijzigingen aan het basismodel. Het voordeel van het profielmechanisme is dat missiespecifieke eisen kunnen worden opgevangen — attributen voor vaartuigtypes voor een maritiem C2-profiel, of attributen voor contacten van elektronische oorlogsvoering voor een EW-beeldprofiel — zonder het basismodel op te blazen of incompatibiliteiten te creëren tussen systemen die verschillende profielen implementeren. Systemen die meerdere profielen implementeren, moeten de unie van hun entiteitstypesets beheren en het geval correct afhandelen waarin een partnersysteem slechts een subset van de gebruikte profielen implementeert.

De NATO Interoperability Test Toolkit (NITT) is het primaire instrument voor het valideren van de conformiteit van op NCIM gebaseerde implementaties. NITT bevat testscripts, georganiseerd per NCIM-entiteitstype en per uitwisselingsscenario (bilaterale uitwisseling van het grondbeeld, OPORD-distributie, rapportage van logistieke status). Elk testscript specificeert de exacte NCIM-entiteitsinstanties die moeten worden uitgewisseld, het serialisatieformaat en de beweringen die aan de ontvangende zijde moeten gelden. NITT-resultaten zijn de belangrijkste input voor CWIX-gereedheidsbeoordelingen: systemen die voor een scenario falen op NITT, worden voor dat scenario op CWIX niet vrijgegeven.

Voor programmateams die de evolutie van NCIM volgen luidt het praktische advies: abonneer u via uw nationale standaardisatieautoriteit voor defensie op C2IEWG-publicaties, beoordeel voorgestelde wijzigingen in het voorstelstadium op de impact op uw adapterlaag (reageren is veel goedkoper vóór goedkeuring) en behandel NCIM-versie-uitlijning als contractueel punt in afspraken over coalitieoefeningen — het specificeren van de NCIM-basislijn die alle deelnemende systemen moeten implementeren, voorkomt de semantische drift die optreedt wanneer partners op verschillende kleine versies zitten.

De bredere trajektorie van de NCIM-governance weerspiegelt de verschuiving van de Alliantie naar service-georiënteerde en datagerichte architecturen. De recente evolutie van NCIM heeft zich geconcentreerd op uitlijning op het FMN-dienstframework (Federated Mission Networking), expliciete ondersteuning van JSON-serialisatie naast XML, en de introductie van linked-data-patronen (RDF/OWL-representaties van NCIM-entiteitstypen) die semantische webintegratie ondersteunen voor geallieerde datadeling over classificatiegrenzen heen. Deze richtingen geven aan dat NCIM qua omvang en relevantie blijft groeien naarmate de C2-informatie-infrastructuur van de NAVO moderniseert — waardoor het een steeds belangrijkere referentie wordt voor alle defensiesoftwareprogramma's die op coalitie-interoperabiliteit mikken.

Bespreek Uw Project

Wij ontwerpen en implementeren NCIM-conforme datalagen en integratieadapters voor coalitie-C2 voor defensieprogramma's die op NAVO-interoperabiliteit mikken.

C2-ontwikkeling → Boek een briefing

Deze analyse is opgesteld door engineers van Corvus Intelligence die missiekritieke software bouwen voor defensie- en overheidsorganisaties. Meer over ons team →

Veelgestelde vragen

Wat is het NAVO C2-informatiemodel (NCIM)?

NCIM is het canonieke conceptuele en logische datamodel van de Alliantie voor command-and-control-informatie-uitwisseling. Het definieert entiteitstypes, relaties en attribuutsemantiek die alle NAVO-C2-datastandaarden dragen — waaronder MIP4, ADatP-34 en C-BML — en vestigt een gemeenschappelijk informatieframework zodat data die onder verschillende NAVO-standaarden wordt uitgewisseld, eenduidig geïnterpreteerd kan worden door coalitiepartners. NCIM definieert geen wire-formats; het staat boven de protocolspecificaties als de gedeelde semantische referentie waarnaar implementatiestandaarden worden afgebeeld.

Hoe verhoudt NCIM zich tot MIP4 en ADatP-34?

NCIM is het moedermodel waaruit zowel MIP4 als ADatP-34 zijn afgeleid. Het datamodel van MIP4 — dat Unit, Equipment, Task en verwante entiteitstypes voor C2 van landstrijdkrachten dekt — is een profiel van NCIM, beperkt tot het landdomein. De berichtencatalogus van ADatP-34 structureert haar velden volgens NCIM-semantiek. Een ontwikkelaar die de entiteitstypehiërarchie van NCIM begrijpt, navigeert zowel MIP4 als ADatP-34 veel sneller dan door ze als onafhankelijke standaarden te behandelen. Het in kaart brengen van MIP4-objecten op ADatP-34-berichtvelden is in wezen een kwestie van NCIM-relaties doorlopen.

Wat zijn de entiteitstypes op het hoogste niveau in NCIM?

NCIM definieert zes entiteitstypes op het hoogste niveau: Activity (geplande of werkelijke acties, waaronder taken, missies en gebeurtenissen), OperationalObject (doelen, interessegebieden en gemelde contacten), Organisation (commandostructuren en organisatorische eenheden), Resource (platforms, uitrustingsets en personeel), Location (geografische posities, gebieden, corridors en grenzen) en Plan (operationele plannen, fasen en de relaties daartussen). Elke entiteit in een NAVO-C2-data-uitwisseling herleidt tot precies één van deze zes types.

Welke serialisatieformaten ondersteunt NCIM?

NCIM zelf is formaatonafhankelijk — het is een conceptueel model, geen serialisatiespecificatie. Implementatiestandaarden definiëren hun eigen serialisaties: MIP4-IES gebruikt XML met een RESTful JSON-binding, ADatP-34 gebruikt VMF-binair voor legacy-radiolinks en de NATO XML Message Specification voor IP-netwerken, en C-BML gebruikt een gespecialiseerd XML-formaat. Bij de bouw van een coalitie-C2-systeem kiest de implementator de serialisatie die past bij het doelnetwerk en de partnersystemen, maar alle serialisaties beelden af op dezelfde onderliggende NCIM-entiteiten.

Hoe worden NCIM-profielen gebruikt voor missiespecifieke uitbreidingen?

NCIM ondersteunt een profielmechanisme dat missie- of domeinspecifieke uitbreidingen mogelijk maakt zonder het basismodel te wijzigen. Een profiel specificeert een beperkte of uitgebreide weergave van NCIM voor een bepaald gebruiksdoel — bijvoorbeeld een maritiem C2-profiel dat vaartuigspecifieke attributen toevoegt aan het entiteitstype Resource terwijl attributen voor het landdomein buiten beschouwing blijven. Profielen worden formeel geregistreerd bij de NATO C3 Board en volgen een gedefinieerde levenscyclus. Implementatieteams moeten vaststellen welke goedgekeurde NCIM-profielen op hun programma van toepassing zijn en alleen de attributen en entiteitstypes implementeren die binnen het bereik vallen.

Wat is het verschil tussen de conceptuele en de logische laag van NCIM?

NCIM is opgebouwd uit twee lagen. De conceptuele laag definieert entiteitstypes op hoog niveau en hun relaties met UML-klassediagrammen — zij beantwoordt de vraag “welke soorten dingen bestaan er in een NAVO-C2-operatie?”. De logische laag verfijnt elk entiteitstype naar attributen met gedefinieerde datatypes, cardinaliteitsbeperkingen en verwijzingen naar waardedomeinen — zij beantwoordt “welke data moet over elke entiteit worden vastgelegd?”. Softwareontwikkelaars werken bij de implementatie van datamodellen primair met de logische laag; systeemarchitecten gebruiken de conceptuele laag om semantische equivalentie tussen de datamodellen van twee systemen te verifiëren voordat data-uitwisseling wordt getest.

Hoe behandelt NCIM locatie en geometrie?

Locatie is in NCIM een entiteitstype op zichzelf, geen attribuut van andere entiteiten. Een Unit heeft geen coördinaatattribuut — zij heeft een relatie met een Location-entiteit die de coördinaat, de onzekerheidsschatting, het geldigheidstijdvenster en de positiebron draagt. Dezelfde Location-entiteit kan door meerdere Activity-, Organisation- en Resource-entiteiten worden gerefereerd. Geometrietypes omvatten Point, Polyline, Polygon, Corridor en het abstracte GeometricExtent. Coördinaatreferentiesystemen volgen ISO 19111 met WGS-84 als basis-CRS voor coalitie-uitwisseling.

Wat is C-BML en hoe verhoudt het zich tot NCIM?

C-BML (Coalition Battle Management Language) is een op XML gebaseerde taal voor het uitdrukken van militaire taken, bevelen en rapporten in machineverwerkbare vorm, ontworpen zodat C2-systemen automatisch een bevel kunnen parseren en de taken eruit kunnen halen. De taak- en bevelstructuren van C-BML zijn geworteld in de entiteitstypes Activity en Plan van NCIM, waarbij C-BML-XML-elementen rechtstreeks op NCIM-attributen worden afgebeeld. Een systeem dat C-BML implementeert voor beveluitwisseling en MIP4-IES voor uitwisseling van het grondbeeld gebruikt in beide dezelfde onderliggende NCIM-semantiek, waardoor data-integratie over protocollen heen aanzienlijk hanteerbaarder wordt.

Hoe zijn NCIM-implementatieconformiteit en -tests georganiseerd?

NCIM-conformiteit wordt getest via de implementatiestandaarden die het gebruiken. De NATO Coalition Warrior Interoperability Exercise (CWIX) is de belangrijkste locatie waar op NCIM gebaseerde implementaties tegen elkaar worden getest. De NATO Interoperability Test Toolkit (NITT) biedt geautomatiseerde testscripts voor MIP4-IES- en C-BML-uitwisselingen die semantische conformiteit ten opzichte van NCIM-definities verifiëren — niet alleen de syntactische geldigheid van de XML. Programma's moeten aan ten minste één CWIX-cyclus deelnemen om operationele conformiteit te demonstreren; nationaal conformiteitsonderzoek vooraf wordt sterk aanbevolen.

Welk governance-orgaan onderhoudt NCIM en hoe vaak wordt het bijgewerkt?

NCIM wordt onderhouden door de NATO C3 Board (C3B) via de C2 Information Exchange Working Group (C2IEWG), met deelname van de ministeries van Defensie van NAVO-landen, nationale defensie-ICT-agentschappen en industriële vertegenwoordigers. Grote versie-incrementen hebben meerjarige doorlooptijden vanwege de cascaderende impact op MIP4, ADatP-34 en C-BML; kleine revisies verschijnen jaarlijks. Implementatieteams dienen zich via hun nationale standaardisatieautoriteit voor defensie te abonneren op C2IEWG-publicaties en NCIM-versie-uitlijning als contractueel punt op te nemen in afspraken over coalitieoefeningen.

Hoe behandelt NCIM classificatie en vrijgave van data?

NCIM kent elk entiteitstype een Confidentiality-attribuut toe met een classificatielabel in lijn met NAVO-classificatieniveaus (UNCLASSIFIED, NATO RESTRICTED, NATO CONFIDENTIAL, NATO SECRET, COSMIC TOP SECRET) en een Releasability-indicator die aangeeft welke naties of groepen de entiteit mogen ontvangen. Deze attributen zijn de NCIM-uitdrukking van de labels die STANAG 4774 (Confidentiality Metadata Label) en STANAG 4778 (Metadata Binding) voorschrijven. Bij serialisatie van NCIM-entiteiten naar XML voor uitwisseling over een coalitienetwerk is de serialisatiestandaard verplicht deze labels zodanig mee te geven dat het ontvangende systeem vrijgavefilters kan toepassen voordat wordt doorgestuurd naar partnersystemen. Een systeem dat NCIM-vertrouwelijkheidsattributen stript of negeert, is niet-conform en vormt een risico op ongecontroleerde informatievrijgave.

Kan NCIM buiten de NAVO worden gebruikt — bijvoorbeeld in het C2-ecosysteem van Oekraïne?

Ja, en dat gebeurt steeds vaker. Landen die geen NAVO-lid zijn maar in coalitie met troepen van de Alliantie opereren, gebruiken van NCIM afgeleide standaarden om interoperabiliteit van data-uitwisseling te bereiken. De defensietechnologieprogramma's van Oekraïne, waaronder systemen die deelnemen aan het Brave1-defensietechnologiecluster, gebruiken MIP4-IES- en ADatP-34-interfaces — beide implementeren NCIM-semantiek — om operationele data uit te wisselen met NAVO-partnersystemen. De praktische implicatie voor niet-NAVO-ontwikkelaars is dezelfde als voor leden van de Alliantie: lijn het interne datamodel uit op NCIM-entiteitstypes en -relaties, implementeer het relevante profiel voor de doeluitwisselingsstandaard en valideer op CWIX of bij een interoperabiliteitsevenement van een partnerland.

Welke tools zijn beschikbaar voor het werken met NCIM-schema's en -modellen?

De primaire toolset voor NCIM-werk is de NATO Interoperability Test Toolkit (NITT), met schemavalidatoren, berichtgeneratoren en geautomatiseerde testsequenties voor MIP4-IES en C-BML. Voor datamodelwerk wordt het UML-model van NCIM in XMI-formaat gepubliceerd en kan het worden geladen in op Eclipse gebaseerde modelleringstools of Sparx Enterprise Architect voor navigatie en gap-analyse. XML-Schema-definities voor op NCIM gebaseerde uitwisselingsformaten worden verspreid via de standaardenrepository van NCIA. Commerciële tools van Systematic (SitaWare), General Dynamics Mission Systems en Thales integreren NCIM-conforme datalagen en kunnen dienen als referentie-implementaties voor adapterontwikkeling — hoewel hun API's propriëtair zijn, moeten de waarneembare datastructuren die zij uitwisselen voldoen aan NCIM-semantiek en kunnen zij dienen als conformiteits-grondwaarheid.