Interoperabilität

NATO C2 Information Model: NCIM-Implementierung und Datenaustausch

Von Corvus Intelligence Engineering Team · Über das Team →

25. Juni 2026 12 Min. Lesezeit

Das NATO C2 Information Model — NCIM — ist die kanonische semantische Grundlage unter den Datenaustauschstandards des Bündnisses für Führung und Kontrolle. Wo ADATP-34-Datenstrukturen Nachrichtenformate definieren und MIP4 IES NATO ground standard Austauschprotokolle für Landstreitkräfte, liegt NCIM eine Schicht über beiden: Es definiert, welche Arten von Dingen es in einer C2-Operation gibt, wie diese Dinge zusammenhängen und welche Daten zu jedem erfasst werden müssen. Jeder NATO-Implementierungsstandard, der operative Daten austauscht, bildet seine Strukturen auf NCIM ab. NCIM zu verstehen ist für Ingenieure, die sich im breiteren Landschaft der NATO-C2-Standards zurechtfinden wollen, daher nicht optional — es ist die gemeinsame Referenz, die den Rest des vollständigen Leitfadens zur NATO-Interoperabilität zusammenhängend macht.

Was NCIM ist und warum es existiert

Das Interoperabilitätsproblem des Bündnisses bei C2 war in den 1990er-Jahren kein reines Protokollproblem — es war ein Semantikproblem. Die NATO-Nationen hatten C2-Systeme implementiert, die Nachrichten austauschten, aber dasselbe Feld bedeutete in den Systemen zweier Nationen Verschiedenes. Ein „unit status“ von „OPERATIONAL“ deckte in einem System eine andere Bereitschaftsschwelle ab als in einem anderen. Als Systeme Daten austauschten, kamen die Bytes an, die Bedeutung war jedoch nicht geteilt. Dieses Problem sollte NCIM lösen.

NCIM (NATO C2 Information Model) ist das kanonische konzeptionelle und logische Datenmodell des Bündnisses für Führungsinformation. Es definiert die Typen der Entitäten, die an C2-Operationen teilnehmen, die Beziehungen zwischen diesen Entitäten und die Attribute — mit ihren Datentypen und Wertebereichen —, die zu jedem Entitätstyp erfasst werden müssen, um den operativen Informationsaustausch zu unterstützen. Es definiert keine Wire-Formate, Netzwerkprotokolle oder Serialisierung — das ist Aufgabe der Implementierungsstandards, die NCIM als semantische Autorität heranziehen.

Die Abstammung von NCIM führt durch mehrere Vorgänger. JC3IEDM (Joint Consultation, Command and Control Information Exchange Data Model) war das erste umfassende C2-Datenmodell des Bündnisses; es wurde Ende der 1990er-Jahre gemeinsam von den NATO-Nationen als formell spezifiziertes relationales Modell über das volle Spektrum operativer Daten entwickelt. Auf JC3IEDM folgte NC2IEDM (NATO C2 Information Exchange Data Model), das das Entitätsmodell verfeinerte und auf gemeinsame Operationen über alle Domänen hinweg ausdehnte. NCIM ist die aktuelle Entwicklungsstufe: ein Modell in getrennten konzeptionellen und logischen Schichten, ausgerichteten an modernen Prinzipien der Informationsarchitektur und als Elternmodell angelegt, aus dem domänenspezifische Implementierungsstandards als Profile abgeleitet werden.

Die Beziehung zu anderen NATO-Datenstandards ist direkt. Das MIP4-Datenmodell — das Unit, Equipment, Task und verwandte Entitätstypen für den C2-Austausch von Landstreitkräften definiert — ist ein Profil der Landdomäne von NCIM. Die Nachrichtenstrukturen in ADatP-34 sind nach NCIM-Semantik geordnet: Jeder ADatP-34-Nachrichtentyp entspricht einem Muster von NCIM-Entitätsinstanzen. C-BML (Coalition Battle Management Language), die XML-Sprache für maschinenverarbeitbare Befehle, nutzt die Entitätstypen Activity und Plan von NCIM als semantische Grundlage. Die Hierarchie der NCIM-Entitätstypen und die Beziehungssemantik zu verstehen, liefert daher den gemeinsamen Bezugsrahmen, um MIP4, ADatP-34 und C-BML als kohärentes System zu behandeln statt als drei unabhängige Standards.

Hierarchie der NCIM-Entitätstypen

NCIM definiert sechs übergeordnete Entitätstypen. Diese sechs Typen decken zusammen jede Kategorie von Information ab, die in einer NATO-C2-Operation vorkommt, und jede Entität in einem Datenmodell auf Implementierungsebene lässt sich auf genau einen davon zurückführen.

Activity ist der Entitätstyp für geplante oder tatsächliche Handlungen. Aufträge, Tasks, Phasen einer Operation, Gefechte und gemeldete Ereignisse sind in NCIM allesamt Activity. Activity hat Untertypen für verschiedene Handlungskategorien: Task (eine befohlene Handlung, die einer Organisation oder Resource zugewiesen ist), Mission (eine übergeordnete Weisung, die mehrere Tasks umfasst) und Event (ein spontanes Vorkommen, das gemeldet und nicht zugewiesen wird). Die Activity-Hierarchie ist die Hauptstruktur, über die operative Befehle in NCIM-basierten Systemen dargestellt werden.

OperationalObject umfasst Entitäten, die verfolgt, bekämpft oder überwacht werden, selbst aber keine Akteure sind. Ziele, Interessengebiete, festgelegte Punkte, Bedrohungsbewertungen und Aufklärungsmeldungen über feindliche Verbände sind OperationalObjects. Der Unterschied zu Organisation und Resource (die freundliche oder neutrale Entitäten mit bekannter Identität darstellen) ist bedeutsam: Ein OperationalObject kann eine unsichere Identität, eine unsichere Position haben und eine Hypothese statt einer bestätigten Beobachtung sein.

Organisation stellt strukturierte Personengruppierungen mit Führungsbeziehungen dar. Militärische Verbände aller Ebenen (Zug, Kompanie, Bataillon, Brigade, Division) sind Organisations. Die Organisations-Hierarchie bildet die Führungsstruktur über Eltern-Kind-Beziehungen zwischen Organisation-Instanzen ab; jede Organisation hat eine Standardbezeichnung, einen Organisationstyp aus der NATO-ORBAT-Taxonomie und eine Führungsbeziehung zu ihrer übergeordneten Organisation (command, support, operational control, tactical control).

Resource umfasst Materiell und Personal als Einzelgegenstände und nicht als organisierte Gruppen. Ein bestimmtes Fahrzeug, ein Waffensystem, ein Kommunikationsgerät oder eine Einzelperson in einer bestimmten Rolle ist eine Resource. Resources sind über Zuweisungs- und Ausstattungsbeziehungen mit Organisations verbunden — ein Bataillon (Organisation) hat zugeordnete Fahrzeuge (Resource), und die Ausstattungsbeziehung trägt den Zuweisungsstatus und den Zeitraum. Die Unterscheidung zwischen Organisation und Resource entspricht ungefähr der Unterscheidung zwischen Verbänden und Gerät in einer Ordnung der Schlachtordnung.

Location ist der Entitätstyp für alle Positions- und Geometrieinformationen. Die Designentscheidung von NCIM, Location als eigenständigen Entitätstyp zu führen — statt Koordinaten als Attribute in andere Entitätstypen einzubetten — hat wichtige Folgen für die Implementierung. Eine Location-Instanz trägt die Geometrie (point, polyline, polygon, corridor oder composite), das Koordinatenreferenzsystem, eine Schätzung der Positionsunsicherheit, ein Gültigkeitszeitfenster und eine Positionsquellenangabe. Andere Entitätstypen verweisen über die Kennung auf Location, statt Koordinaten einzubetten. Dieses Design erlaubt es, dass dieselbe Location von mehreren Entitäten referenziert wird, unterstützt die Anbindung von Unsicherheits- und Gültigkeitsmetadaten an Positionsdaten und ermöglicht es, die Positionshistorie als Folge von Location-Instanzen zu modellieren, die einer einzelnen Organisation oder Resource zugeordnet sind.

Plan ist der Entitätstyp für operative Planungsprodukte. Ein Operationsplan, ein Teilbefehl, ein Phasenübergangsbefehl oder ein Dokument zur Operationsführung ist in NCIM ein Plan. Der Entitätstyp Plan hat Untertypen für verschiedene Kategorien von Planungsprodukten und führt Beziehungen zu den Activities, die er anweist, den Organisations, denen er Aufträge erteilt, und den Locations, die er als Ziele zuweist.

Die Vererbungsstruktur innerhalb dieser sechs Typen ist für die Implementierung bedeutsam. Innerhalb von Activity lautet die vollständige Vererbungskette etwa: Activity → Task → ControlMeasureTask (eine Task, die die Errichtung oder den Abbau einer Kontrollmaßnahme anweist) — jede Ebene fügt Attribute hinzu, die für den jeweiligen Untertyp spezifisch sind, und erbt alle Attribute des Elterntyps. Implementierungsstandards wählen die benötigte Vererbungstiefe: MIP4 implementiert Task und mehrere seiner Untertypen; C-BML implementiert die vollständige Activity-Hierarchie bis hinab zu elementaren Task-Typen aus der NATO-Taxonomie taktischer Aufträge.

Strukturen operativer Planungsprodukte in NCIM

Der Entitätstyp Plan und seine Beziehungen zu Activity-Instanzen bilden das Rückgrat der NCIM-Darstellung operativer Planungsprodukte. Diese Struktur zu verstehen ist unverzichtbar für die Implementierung jedes NATO-C2-Systems, das Pläne, Befehle oder deren Ausführungsstatus austauschen muss.

Auf der obersten Ebene stellt eine Plan-Instanz ein vollständiges operatives Planungsprodukt dar — einen OPLAN, OPORD, FRAGO oder CONOPS. Ein Plan trägt eine eindeutige Kennung, eine Einstufungs- und Freigabemarkierung, eine Ausgabestelle (die Organisation, die ihn erlassen hat), einen Gültigkeitszeitraum und einen Status (Entwurf, genehmigt, abgelöst). Pläne sind über eine Ablösekette miteinander verknüpft: Ein FRAGO, der einen bestehenden OPLAN ändert, verweist auf den OPLAN, den er ablöst, und erzeugt so eine Planungshistorie, die es Systemen erlaubt, die Entwicklung der operativen Planung nachzuvollziehen.

Ein Plan ist in Phase-Instanzen gegliedert — jede Phase stellt eine abgegrenzte Einsatzperiode mit definierten Übergangsbedingungen dar. In NCIM ist Phase ein Untertyp von Activity, der über eine planContains-Beziehung einem Plan zugeordnet ist. Phase-Instanzen werden über Übergangsbedingungen in eine Folge gebracht: Eine Phase-B-Instanz hat eine startCondition, die sich entweder auf eine Zeit (D+3) oder ein Ereignis (Abschluss des Ziels von Phase A) bezieht. Strukturen auf Phasenebene erscheinen im OPLAN-Nachrichtenformat von ADatP-34 und sind unmittelbar in der Befehlsdarstellung von C-BML implementiert.

Innerhalb jeder Phase stellen Task-Instanzen zugewiesene Handlungen dar. Eine NCIM-Task trägt: eine eindeutige Kennung, einen Task-Typ aus der NATO-Taxonomie taktischer Aufträge (SEIZE, ATTACK, DEFEND, SCREEN, COVER, SUPPORT BY FIRE und dutzende weitere), die beauftragte Organisation oder Resource, die Ziel-Location (die ein Punkt, ein Gebiet oder ein benannter Ort sein kann), die Zeitvorgaben (frühester Beginn, spätester Beginn, geforderter Abschluss), die ausgebende Stelle und den Verweis auf den erlassenden Plan. Die Task-zu-Organisation-Beziehung ist der NCIM-Ausdruck von „Verband X erhält den Auftrag, Ziel Y zu sichern“ — der grundlegende C2-Informationsaustausch.

Objective-Instanzen in NCIM präzisieren den Zweck der Task: Ein Objective trägt das konkrete operationsleitende Ziel, das die Task erreichen soll, ausgedrückt als herzustellende Bedingung (Gelände erobert, Feind vernichtet, Strecke geräumt) und nicht nur als geographische Position. Die Unterscheidung ist wichtig für maschinenverarbeitbare Befehle: Ein C-BML-System, das einen Auftrag erhält, kann den Bedingungstyp des Objective nutzen, um festzustellen, wann die Task abgeschlossen ist, und so eine automatisierte Fortschrittsmeldung ohne menschliche Interpretation ermöglichen.

Constraint-Instanzen hängen einschränkende Bedingungen an Tasks und Pläne. Constraints sind in NCIM typisiert: Eine zeitliche Einschränkung begrenzt das Zeitfenster für eine Aktivität; eine geographische Einschränkung begrenzt das Gebiet, in dem eine Resource eingesetzt werden darf; eine Ressourceneinschränkung legt fest, welche Mittel für eine Task verwendet werden dürfen. Constraints werden sowohl von Task-Instanzen (für eine bestimmte Task) als auch von Plan-Instanzen (für den gesamten Einsatz) referenziert. Das NCIM-Constraint-Modell ist die semantische Grundlage für die Kodierung von Einsatzregeln in koalitionären C2-Systemen, die mit nationalen Einsatzregel-Policies interoperabel bleiben müssen.

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

Modellierung von Resource und Ausrüstung

Die Resource-Entitätstyp-Hierarchie in NCIM liefert die Strukturen, um Plattformen, Gerätssätze und Organisationseinheiten als Einzelmateriell und Personal darzustellen. Die Resource-Modellierung ist entscheidend für koalitionäre C2-Systeme, die Ordnungsdaten einschließlich Gerätestatus und Fähigkeitserklärungen austauschen müssen.

Platform ist der primäre Untertyp von Resource für physische Systeme — Fahrzeuge, Luftfahrzeuge, Schiffe und Waffensysteme. Eine Platform-Instanz in NCIM trägt einen Plattformtyp-Verweis (aus einem kontrollierten Vokabular, abgestimmt auf die NATO-Klassifizierungscodes für Gerät), eine Serien- oder Zulassungskennung, einen Einsatzstatuscode (fully mission capable, partially mission capable, non-mission capable) und einen Verweis auf die aktuelle Location. Platform-Instanzen sind über eine Equipage-Beziehung mit Organisation-Instanzen verknüpft, die den Zuweisungszeitraum und den Zuweisungstyp (organic, attached, operational control) trägt. Das ist der NCIM-Ausdruck eines Ordnungsschlachtordnungseintrags: Die Organisation ist das Bataillon, die Platform-Instanzen sind die Fahrzeuge, und die Equipage-Beziehungen halten fest, welche Fahrzeuge derzeit welchen Verbänden zugeordnet sind.

Für Fälle, in denen einzelne Plattformen nicht getrennt verfolgt werden (üblich bei Handwaffen, Kommunikationsgerät und einigen Versorgungsgütern), bietet NCIM EquipmentSet: einen Untertyp von Resource, der eine Menge gleichartiger Gegenstände darstellt statt individuell verfolgter Einzelstücke. Ein EquipmentSet trägt den Gegenstandstyp, eine Menge, eine Maßeinheit und einen aggregierten Bereitschaftszustand. EquipmentSet-Instanzen treten in Szenarien der Logistikmeldung auf, in denen Bruttomengen operationsrelevanter sind als die Verfolgung einzelner Gegenstände.

OrganisationUnit überbrückt die Entitätstypen Resource und Organisation für Fälle, in denen ein bestimmtes Team, eine Besatzung oder ein Trupp zugleich als Resource (mit Gerät) und als Organisationselement (mit Führungsbeziehungen) dargestellt werden muss. Eine Hubschrauberbesatzung ist beispielsweise eine OrganisationUnit: Sie hat ein zugeordnetes Luftfahrzeug (Resource-Beziehung) und eine Meldewegehierarchie (Organisation-Beziehung). Der Untertyp OrganisationUnit von NCIM erlaubt diese Doppelidentität, ohne Widersprüche im Datenmodell zu erzeugen.

Die Fähigkeitserklärung ist ein wichtiger Anwendungsfall für die Resource-Modellierung in der Koalition. NCIM unterstützt Capability als Attributkategorie sowohl bei Organisation als auch bei Resource und nutzt dafür ein kontrolliertes Vokabular, abgestimmt auf die NATO-Fähigkeitstaxonomie. Die Fähigkeitserklärung eines Verbands — welche Auftragstypen er ausgerüstet und geschult auszuführen vermag — wird als Menge von Capability-Verweisen auf der Organisation-Instanz dargestellt. Bei der Planung in der Koalition nutzt der Zuweisungsprozess Task-zu-Organisation diese Capability-Verweise, um Aufträge an geeignete Verbände zu verteilen. In automatisierten C2-Systemen kann dieser Abgleich maschinell erfolgen; in bedienergeführten Systemen stützen sich die Fähigkeitsdaten die Verbandswahl im Auftragsworkflow.

<!-- 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- und JSON-Serialisierung

NCIM ist ein konzeptionelles und logisches Modell — es definiert Semantik, nicht Bytes. Die Serialisierung in Wire-Formate ist Aufgabe der Implementierungsstandards, die NCIM als Elternmodell verwenden. Für Entwickler, die Austauschschichten zwischen koalitionären Systemen bauen, ist es unverzichtbar zu verstehen, wie die NCIM-Semantik auf XML und zunehmend auch auf JSON abgebildet wird.

Das primäre Serialisierungsformat für den NCIM-basierten Austausch ist XML. Das NCIM-XML-Schema ist als Satz von XSD-Modulen strukturiert, eines pro Gruppe von NCIM-Entitätstypen, geordnet unter einer gemeinsamen Namensraumhierarchie. Der übergeordnete Namensraum ist urn:int:nato:ncim:3 (für NCIM Version 3.x), mit Unternamensräumen für jedes Domänenmodul: urn:int:nato:ncim:3:core für die Kern-Entitätstypen, urn:int:nato:ncim:3:land für Erweiterungen der Landdomäne und so weiter. Implementierungsstandards, die Profile von NCIM sind, definieren eigene Namensräume, die die relevanten NCIM-Module importieren und implementierungsspezifische Einschränkungen hinzufügen (Pflichtfelder, Beschränkungen durch kontrolliertes Vokabular, Verschärfung der Kardinalität).

Die Namensraumverwaltung in NCIM-XML ist eine praktische Herausforderung. Eine typische koalitionäre C2-Nachricht, die Entitäten aus mehreren NCIM-Modulen referenziert, trägt fünf bis acht aktive Namensraumdeklarationen im Rootelement. Das Risiko sind Kollisionen von Namensraumpräfixen, wenn Nachrichten aus mehreren Quellen zu einem gemeinsamen Bild zusammengeführt werden: Zwei Nachrichten können beide das Präfix ncim deklarieren, es aber auf verschiedene NCIM-Modulnamensräume abbilden. Der richtige Ansatz ist, die Namensraumpräfixe bei der Nachrichtenaufnahme zu normalisieren — alle Namensraumdeklarationen auf ihre kanonische URI aufzulösen und durch die gesamte Verarbeitungskette URI-schlüsselte statt präfixschlüsselter Namensraumabbildungen zu verwenden.

Für taktische Netze mit begrenzter Bandbreite ist die Ausführlichkeit von XML ein erheblicher Nachteil. Eine NCIM-Entität, die als vollständiges XML mit allen Namensraumdeklarationen und öffnenden/schließenden Tags serialisiert ist, kann vier- bis sechsmal größer sein als die eigentlichen Nutzdaten. In der Praxis werden drei Ansätze verwendet:

EXI (Efficient XML Interchange): eine binäre XML-Kodierung des W3C, die die volle XML-Semantik erhält und die Größe je nach Schemadichte um 80–95 % reduziert. EXI ist der bevorzugte Ansatz für begrenzte taktische Strecken, wenn XML-Round-Trip-Fähigkeit erforderlich ist. NCIM-Schemata sind ohne Änderung EXI-kompatibel.
Schemaunterstützte Kompression: Anwendung einer schemabewussten DEFLATE- oder LZ4-Kompression auf den XML-Bytestrom. Erzielt gute Kompressionsraten (60–75 % Größenreduktion) bei geringerem Rechenaufwand als EXI, jedoch ohne echte Portabilität eines Binärformats.
JSON-Serialisierung: Die RESTful-Bindung von MIP4-IES verwendet JSON für die Darstellung einzelner Objekte und bildet NCIM-Entitätsattribute auf JSON-Objekteigenschaften ab. JSON-Nutzdaten sind 30–40 % kleiner als entsprechendes XML und fügen sich natürlicher in moderne REST-Client-Bibliotheken ein. Der Kompromiss: JSON-Schema-Werkzeuge für NCIM sind weniger ausgereift als XSD-Werkzeuge, und die Round-Trip-Validierung gegen das normative NCIM-Modell erfordert ein sorgfältiges Schema-Management.

// 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 in einem koalitionären C2-System implementieren

Die meisten koalitionären C2-Systeme gelangen auf einem von zwei Wegen zur NCIM-Implementierung: ein Neusystem, das von Anfang an um die NCIM-Semantik herum entworfen wird, oder ein nationales Altsystem, das für die Interoperabilität in der Koalition angepasst wird. Der zweite Fall ist weitaus häufiger und anspruchsvoller.

Adapterdesign für nationale Datenmodelle ist der praktische Ansatz für die Integration von Altsystemen. Statt das interne Datenmodell eines nationalen C2-Systems an NCIM anzugleichen — ein mehrjähriges Vorhaben mit erheblichem Einsatzrisiko — konzentriert das Adaptermuster alle NCIM-Mapping-Entscheidungen in einer eigenen Adapterkomponente. Der Adapter übersetzt für alle externen Datenaustausche zwischen dem nationalen Modell und NCIM-konformen Darstellungen: eingehende Koalitionsdaten werden für die interne Nutzung ins nationale Modell übersetzt; ausgehende nationale Daten werden für den Austausch in der Koalition ins NCIM übersetzt. Der Adapter ist die Interoperabilitätsgrenze und die einzige Komponente, die bei einer Aktualisierung der NCIM-Baseline geändert werden muss.

Die wichtigste Entscheidung im Adapterdesign ist festzulegen, welche NCIM-Entitätstypen vollständig und welche nur oberflächlich übersetzt werden müssen. Vollständige Übersetzung — bei der jedes NCIM-Attribut eine entsprechende interne Abbildung hat — ist für Entitätstypen erforderlich, die im bidirektionalen Datenaustausch vorkommen. Oberflächliche Übersetzung — bei der nur Schlüsselkennungen und Statuscodes abgebildet werden — ist akzeptabel für Entitätstypen, die das System konsumiert, aber nie ändert oder anlegt. Priorisieren Sie die vollständige Übersetzung für Organisation, Resource (Platform), Activity (Task) und Location; für Constraint und Objective genügt auf Adaptorebene in der Regel die oberflächliche Übersetzung.

NCIM-zu-CoT-Mapping ist für Systeme erforderlich, die mit Plattformen Daten austauschen, die Cursor on Target (CoT) verwenden — das XML-Schema von ATAK, WinTAK und verwandten Werkzeugen zur Lageaufklärung. CoT ist nicht aus NCIM abgeleitet, eine Zuordnung beider ist in der Praxis jedoch gut definiert. Das CoT-Element <event> wird auf NCIM Resource (für Plattformen und Personal) oder OperationalObject (für Spuren und Kontakte) abgebildet; das Attribut type bildet den NCIM-Entitätstyp und den Plattformtyp-Verweis ab. Das CoT-Element <point> wird auf NCIM Location (Untertyp Point) abgebildet, bei Bedarf mit Koordinatentransformation (CoT verwendet WGS-84 in Dezimalgrad, passend zum Basiskoordinatenreferenzsystem von NCIM). Der wesentliche strukturelle Unterschied: CoT bettet Positionsdaten in das Event-Element ein, während NCIM sie als Location-Entität auslagert — der Adapter muss bei der eingehenden Übersetzung aus jedem CoT-Point eine Location-Instanz erzeugen und bei der ausgehenden Übersetzung die Koordinaten der referenzierten Location in den CoT-Point einbetten.

NCIM-zu-MIP-Bridging ist die häufigste Anpassungsanforderung der Koalition für Land-C2-Systeme. Das MIP4-Datenmodell ist ein Profil der Landdomäne von NCIM; die Abbildung ist daher keine Übersetzung zwischen unabhängigen Modellen, sondern eine Projektion von einem breiteren Modell (NCIM) auf ein eingeschränktes Profil (MIP4). Die wesentlichen Unterschiede, die Mapping-Logik erfordern: MIP4 verwendet OID (UUID-basierte global eindeutige Kennung) als primäre Kennung, während NCIM eine generische UniqueId verwendet, die in anderen Implementierungsstandards anders kodiert sein kann; das Inaktivierungsmodell von MIP4 BaseObject (Gültigkeitsflag) bildet das Gültigkeitsattribut der NCIM-Entität ab; und das Location-Modell von MIP4 verwendet eine etwas andere Darstellung der Unsicherheit als der NCIM-Typ GeometricExtent. Diese Unterschiede sind ohne Datenverlust überbrückbar, erfordern aber eine sorgfältige Implementierung der Sonderfälle.

Test auf semantische Äquivalenz: Vor jeder CWIX-Teilnahme sollten Systeme einen Test auf semantische Äquivalenz durchführen — einen standardisierten Satz von NCIM-Entitätsinstanzen mit einem Partnersystem austauschen und prüfen, dass die interne Darstellung der empfangenen Daten beim Partner der Absicht des Senders entspricht. Syntaktische Konformität (gültiges XML, korrektes Schema) garantiert keine semantische Äquivalenz (gleiche Bedeutung). Operative Fehler durch semantische Abweichung — etwa wenn der Status eines Verbands als OPERATIONAL gelesen wird, während der Sender DEPLOYED AWAITING ORDERS meinte — sind schwerer zu entdecken und folgenschwerer als syntaktische Fehler.

NCIM-Entwicklung und Governance

NCIM wird vom NATO C3 Board (C3B) gepflegt, dem Governance-Gremium des Bündnisses für Standards der Kommunikations- und Informationssysteme. Das C3B arbeitet über eine Arbeitsgruppenstruktur: Die C2 Information Exchange Working Group (C2IEWG) ist für die Pflege von NCIM zuständig, unter Beteiligung der Verteidigungsministerien der NATO-Nationen, nationaler Verteidigungs-ICT-Behörden und von Industrievertretern über den NATO-Industriekonsultationsprozess.

Der Standards-Lebenszyklus von NCIM folgt dem Standardprozess des Bündnisses: Ein Änderungsvorschlag wird mit Begründung und Folgenabschätzung bei der C2IEWG eingereicht; die Arbeitsgruppe prüft den Vorschlag auf Konsistenz mit den abhängigen Standards (da eine Änderung an NCIM auf MIP4, ADatP-34 und C-BML durchschlägt, muss die Folgenabschätzung alle drei abdecken); nach der Freigabe durch die Arbeitsgruppe durchläuft der Vorschlag eine Kommentierungsfrist der Mitgliedsländer; und nach der Auswertung der Kommentare geht die Änderung in die nächste NCIM-Revision ein und wird über NCIA veröffentlicht. Größere Versionssprünge (NCIM 2.x auf 3.x) haben mehrjährige Vorlaufzeiten wegen der Auswirkungen auf die Implementierungsstandards; kleinere Überarbeitungen innerhalb einer Hauptversion erscheinen jährlich.

Der Profilmechanismus ist das Hauptwerkzeug für einsatzspezifische Erweiterungen ohne Änderung des Basismodells. Ein Profil ist eine formell definierte, eingeschränkte oder erweiterte Sicht auf NCIM für eine bestimmte Domäne oder einen bestimmten Auftragstyp. Profile werden vom C3B als Anlagen zu NCIM veröffentlicht und durchlaufen denselben Prüf- und Genehmigungsprozess wie Änderungen am Basismodell. Der Vorteil des Profilmechanismus: einsatzspezifische Anforderungen können berücksichtigt werden — etwa Schiffstyp-Attribute für ein maritimes C2-Profil oder Kontaktattribute der elektronischen Kampfführung für ein EW-Bild-Profil —, ohne dass das Basismodell aufgebläht oder Inkompatibilitäten zwischen Systemen mit verschiedenen Profilen entstehen. Systeme, die mehrere Profile implementieren, müssen die Vereinigung ihrer Entitätstypmengen verwalten und den Fall sauber behandeln, dass ein Partnersystem nur eine Teilmenge der genutzten Profile implementiert.

Das NATO Interoperability Test Toolkit (NITT) ist das Hauptwerkzeug zur Validierung der Konformität NCIM-basierter Implementierungen. NITT enthält Testskripte, geordnet nach NCIM-Entitätstyp und nach Austauschszenario (bilateraler Austausch des Bodenbilds, OPORD-Verteilung, Logistikstatusmeldung). Jedes Testskript legt die exakten NCIM-Entitätsinstanzen fest, die ausgetauscht werden müssen, das Serialisierungsformat und die Bedingungen, die auf Empfängerseite erfüllt sein müssen. NITT-Ergebnisse sind der Hauptbeitrag zur CWIX-Einsatzbereitschaftsbewertung: Systeme, die in einem Szenario bei NITT durchfallen, werden für dieses Szenario bei CWIX nicht freigegeben.

Für Programmteams, die die NCIM-Entwicklung verfolgen, lautet die praktische Empfehlung: Abonnieren Sie die C2IEWG-Publikationen über Ihre nationale Verteidigungsstandardisierungsbehörde, prüfen Sie Änderungsvorschläge schon in der Vorschlagsphase auf Auswirkungen auf Ihre Adapterschicht (auf Änderungen zu reagieren ist vor der Genehmigung weitaus günstiger) und behandeln Sie die Angleichung an die NCIM-Version als vertraglichen Punkt in Vereinbarungen für koalitionäre Übungen — die Festlegung der NCIM-Baseline, die alle beteiligten Systeme implementieren müssen, verhindert die semantische Drift, die entsteht, wenn Partner auf verschiedenen kleineren Versionen stehen.

Die weiterführende Entwicklung der NCIM-Governance spiegelt den Kurswechsel des Bündnisses hin zu serviceorientierten und datenzentrischen Architekturen. Die jüngste NCIM-Entwicklung hat sich auf die Angleichung an den FMN-(Federated Mission Networking)-Servicerahmen, eine ausdrückliche Unterstützung der JSON-Serialisierung neben XML und die Einführung von Linked-Data-Mustern (RDF/OWL-Darstellungen der NCIM-Entitätstypen) konzentriert, die die semantische Web-Integration für den verbündeten Datenaustausch über Einstufungsgrenzen hinweg unterstützen. Diese Richtungen zeigen, dass NCIM an Umfang und Relevanz weiter wachsen wird, während sich die C2-Informationsinfrastruktur der NATO modernisiert — und damit zu einer immer wichtigeren Referenz für alle Verteidigungssoftwareprogramme wird, die auf Interoperabilität in der Koalition abzielen.

Ihr Projekt besprechen

Wir entwerfen und implementieren NCIM-konforme Datenschichten und Integrationsadapter für koalitionäre C2-Systeme für Verteidigungsprogramme, die auf NATO-Interoperabilität abzielen.

C2-Entwicklung → Briefing buchen

Diese Analyse wurde von Ingenieuren der Corvus Intelligence erstellt, die betriebskritische Software für Verteidigungs- und Regierungsorganisationen bauen. Erfahren Sie mehr über unser Team →

Häufig gestellte Fragen

Was ist das NATO C2 Information Model (NCIM)?

NCIM ist das kanonische konzeptionelle und logische Datenmodell des Bündnisses für den Austausch von Informationen der Führung und Kontrolle. Es definiert Entitätstypen, Beziehungen und Attributsemantik, die alle NATO-C2-Datenstandards tragen — einschließlich MIP4, ADatP-34 und C-BML —, und etabliert einen gemeinsamen Informationsrahmen, sodass Daten, die unter verschiedenen NATO-Standards ausgetauscht werden, über Koalitionspartner hinweg eindeutig interpretiert werden können. NCIM definiert keine Übertragungsformate; es steht über den Protokollspezifikationen als die geteilte semantische Referenz, auf die Implementierungsstandards abbilden.

Wie hängt NCIM mit MIP4 und ADatP-34 zusammen?

NCIM ist das übergeordnete Modell, von dem sowohl MIP4 als auch ADatP-34 abgeleitet sind. Das Datenmodell von MIP4 — es deckt Unit, Equipment, Task und verwandte Entitätstypen für das C2 der Landstreitkräfte ab — ist ein auf die Landdomäne beschränktes Profil von NCIM. Der Nachrichtenkatalog von ADatP-34 strukturiert seine Felder nach der NCIM-Semantik. Ein Entwickler, der die Entitätstyphierarchie von NCIM versteht, findet sich in MIP4 und ADatP-34 viel schneller zurecht, als wenn er sie als unabhängige Standards behandelt. Die Zuordnung zwischen MIP4-Objekten und ADatP-34-Nachrichtenfeldern ist im Wesentlichen eine Frage des Durchlaufens von NCIM-Beziehungen.

Welche übergeordneten Entitätstypen gibt es in NCIM?

NCIM definiert sechs Entitätstypen der obersten Ebene: Activity (geplante oder tatsächliche Handlungen, einschließlich Aufgaben, Missionen und Ereignissen), OperationalObject (Ziele, Interessensgebiete und gemeldete Kontakte), Organisation (Befehlshierarchien und organisatorische Einheiten), Resource (Plattformen, Ausrüstungssätze und Personal), Location (geografische Positionen, Gebiete, Korridore und Grenzen) und Plan (operative Pläne, Phasen und die Beziehungen zwischen ihnen). Jede Entität in einem NATO-C2-Datenaustausch lässt sich auf genau einen dieser sechs Typen zurückführen.

Welche Serialisierungsformate unterstützt NCIM?

NCIM selbst ist formatunabhängig — es ist ein konzeptionelles Modell, keine Serialisierungsspezifikation. Implementierungsstandards definieren eigene Serialisierungen: MIP4-IES verwendet XML mit einer RESTful-JSON-Bindung, ADatP-34 verwendet VMF-Binär für herkömmliche Funkstrecken und die NATO XML Message Specification für IP-Netze, und C-BML verwendet ein spezielles XML-Format. Beim Aufbau eines koalitionären C2-Systems wählt der Implementierer die zum Zielnetzwerk und zu den Partnern passende Serialisierung; alle Serialisierungen bilden jedoch dieselben zugrunde liegenden NCIM-Entitäten ab.

Wie werden NCIM-Profile für einsatzspezifische Erweiterungen verwendet?

NCIM unterstützt einen Profilmechanismus, der einsatz- oder domänenspezifische Erweiterungen ohne Änderung des Basismodells erlaubt. Ein Profil legt eine eingeschränkte oder erweiterte Sicht auf NCIM für einen bestimmten Anwendungsfall fest — ein maritimes C2-Profil fügt beispielsweise schiffsspezifische Attribute zum Entitätstyp Resource hinzu, während Attribute der Landdomäne außerhalb des Geltungsbereichs bleiben. Profile werden formell beim NATO C3 Board registriert und folgen einem definierten Lebenszyklus. Implementierungsteams müssen feststellen, welche genehmigten NCIM-Profile für ihr Programm gelten, und nur die Attribute und Entitätstypen im Geltungsbereich implementieren.

Was ist der Unterschied zwischen der konzeptionellen und der logischen Schicht von NCIM?

NCIM ist in zwei Schichten strukturiert. Die konzeptionelle Schicht definiert übergeordnete Entitätstypen und ihre Beziehungen mittels UML-Klassendiagrammen — sie beantwortet die Frage „Welche Arten von Dingen gibt es in einer NATO-C2-Operation?“. Die logische Schicht verfeinert jeden Entitätstyp zu Attributen mit definierten Datentypen, Kardinalitätsbeschränkungen und Verweisen auf Wertebereiche — sie beantwortet die Frage „Welche Daten müssen zu jeder Entität erfasst werden?“. Softwareentwickler arbeiten bei der Implementierung von Datenmodellen vor allem mit der logischen Schicht; Systemarchitekten nutzen die konzeptionelle Schicht, um die semantische Äquivalenz der Datenmodelle zweier Systeme vor dem Test des Datenaustauschs zu prüfen.

Wie behandelt NCIM Position und Geometrie?

Location ist in NCIM ein eigenständiger Entitätstyp und kein Attribut anderer Entitäten. Eine Unit hat kein Koordinatenattribut — sie hat eine Beziehung zu einer Location-Entität, die die Koordinate, die Unsicherheitsschätzung, das Gültigkeitszeitfenster und die Positionsquelle trägt. Dieselbe Location-Entität kann von mehreren Activity-, Organisation- und Resource-Entitäten referenziert werden. Geometrietypen sind Point, Polyline, Polygon, Corridor und der abstrakte GeometricExtent. Koordinatenreferenzsysteme folgen ISO 19111; WGS-84 ist das Basiskoordinatenreferenzsystem für den Austausch in der Koalition.

Was ist C-BML und wie hängt es mit NCIM zusammen?

C-BML (Coalition Battle Management Language) ist eine XML-basierte Sprache zum Ausdruck militärischer Aufträge, Befehle und Meldungen in maschinenverarbeitbarer Form. Sie soll es C2-Systemen ermöglichen, einen Befehl automatisch zu parsen und die darin enthaltenen Aufträge zu extrahieren. Die Auftrags- und Befehlsstrukturen von C-BML basieren auf den Entitätstypen Activity und Plan von NCIM; C-BML-XML-Elemente bilden NCIM-Attribute direkt ab. Ein System, das C-BML für den Befehlsaustausch und MIP4-IES für den Austausch des Bodenbilds implementiert, verwendet in beiden Fällen dieselbe zugrunde liegende NCIM-Semantik. Das macht die datenseitige Integration über Protokollgrenzen hinweg erheblich handhabbarer.

Wie sind Konformität und Testen von NCIM-Implementierungen organisiert?

Die NCIM-Konformität wird über die Implementierungsstandards getestet, die NCIM verwenden. Die NATO Coalition Warrior Interoperability Exercise (CWIX) ist der zentrale Ort, an dem NCIM-basierte Implementierungen gegeneinander getestet werden. Das NATO Interoperability Test Toolkit (NITT) bietet automatisierte Testskripte für MIP4-IES- und C-BML-Austausch, die die semantische Konformität gegen die NCIM-Definitionen prüfen — nicht nur die syntaktische Validität des XML. Programme müssen mindestens an einem CWIX-Zyklus teilnehmen, um die operative Konformität nachzuweisen; nationale Konformitätstests zuvor werden dringend empfohlen.

Welches Gremium pflegt NCIM und wie oft wird es aktualisiert?

NCIM wird vom NATO C3 Board (C3B) über die C2 Information Exchange Working Group (C2IEWG) gepflegt, unter Beteiligung der Verteidigungsministerien der NATO-Nationen, nationaler Verteidigungs-ICT-Behörden und Industrievertreter. Größere Versionssprünge haben mehrjährige Vorlaufzeiten, weil sich die Änderungen auf MIP4, ADatP-34 und C-BML auswirken; kleinere Überarbeitungen erscheinen jährlich. Implementierungsteams sollten die C2IEWG-Publikationen über ihre nationale Verteidigungsstandardisierungsbehörde abonnieren und die Angleichung an die NCIM-Version als vertraglichen Punkt in Vereinbarungen für koalitionäre Übungen behandeln.

Wie behandelt NCIM Einstufung und Datenfreigabe?

NCIM enthält in jedem Entitätstyp ein Confidentiality-Attribut, das eine Einstufungsmarkierung in Übereinstimmung mit den NATO-Einstufungsstufen (UNCLASSIFIED, NATO RESTRICTED, NATO CONFIDENTIAL, NATO SECRET, COSMIC TOP SECRET) trägt, sowie ein Releasability-Merkmal, das festlegt, welche Nationen oder Gruppen die Entität erhalten dürfen. Diese Attribute sind der Ausdruck auf NCIM-Ebene der Markierungen, die STANAG 4774 (Confidentiality Metadata Label) und STANAG 4778 (Metadata Binding) vorschreiben. Bei der Serialisierung von NCIM-Entitäten zu XML für den Austausch in einem koalitionären Netzwerk muss der Serialisierungsstandard diese Markierungen an einer Position und in einem Format übertragen, die es dem empfangenden System erlauben, Weitergabefilter anzuwenden, bevor an Partnersysteme weitergeleitet wird. Ein System, das NCIM-Vertraulichkeitsattribute entfernt oder ignoriert, ist nicht konform und birgt ein Risiko der Informationsweitergabe.

Kann NCIM außerhalb der NATO eingesetzt werden — zum Beispiel im C2-Ökosystem der Ukraine?

Ja, und das ist zunehmend üblich. Nationen, die keine NATO-Mitglieder sind, aber in einer Koalition mit Streitkräften des Bündnisses operieren, nutzen NCIM-abgeleitete Standards für die Interoperabilität im Datenaustausch. Die Verteidigungstechnologieprogramme der Ukraine, einschließlich der Systeme im Verteidigungstechnologie-Cluster Brave1, verwenden MIP4-IES- und ADatP-34-Schnittstellen — beide implementieren die NCIM-Semantik —, um operative Daten mit NATO-Partnersystemen auszutauschen. Die praktische Konsequenz für Entwickler außerhalb der NATO ist dieselbe wie für Bündnismitglieder: das interne Datenmodell an die NCIM-Entitätstypen und -Beziehungen angleichen, das relevante Profil für den Zielstandard des Datenaustauschs implementieren und bei CWIX oder einer Interoperabilitätsveranstaltung eines Partnerlandes validieren.

Welche Werkzeuge gibt es für die Arbeit mit NCIM-Schemata und -Modellen?

Der wichtigste Werkzeugsatz für die NCIM-Arbeit ist das NATO Interoperability Test Toolkit (NITT) mit Schemavalidatoren, Nachrichtengeneratoren und automatisierten Testsequenzen für MIP4-IES und C-BML. Für die Datenmodellarbeit ist das NCIM-UML-Modell im XMI-Format veröffentlicht und kann in Eclipse-basierten Modellierungswerkzeugen oder Sparx Enterprise Architect zur Navigation und Lückenanalyse geladen werden. XML-Schema-Definitionen für NCIM-basierte Austauschformate werden über das Standards-Repository von NCIA verteilt. Kommerzielle Werkzeuge von Systematic (SitaWare), General Dynamics Mission Systems und Thales integrieren NCIM-konforme Datenschichten und können als Referenzimplementierungen für die Adapterentwicklung dienen — auch wenn ihre APIs proprietär sind, müssen die beobachtbaren Datenstrukturen, die sie austauschen, der NCIM-Semantik entsprechen und können als Konformitätsreferenz verwendet werden.

Wie verhält sich NCIM zu MIP4 und ADatP-34?

Was sind die Entitätstypen der obersten Ebene in NCIM?