Standardisierung von C2-Datenmodellen: warum proprietäre Schemata das Lagebild fragmentieren

Zwei verbündete Verbände besetzen benachbarte Abschnitte. Beide verfügen über moderne C2-Systeme, die Tracks in ein gemeinsames Lagebild einspeisen. Doch das gemeinsame Bild ist unvollständig: Die Systeme der einen Nation melden Verbandskennungen als NATO-STANAG-2019-Bezeichner, die der anderen als nationale alphanumerische Codes. Eine kodiert den Standort in MGRS, die andere in Dezimalgrad-WGS-84. Eine versieht Ereignisse mit UTC-Zeitstempeln in Millisekundenauflösung; die andere verwendet Ortszeit mit Sekundenauflösung. Das Ergebnis ist, dass ein in einem System erstellter Track im anderen entweder gar nicht erscheint oder als Duplikat mit widersprüchlicher Position auftaucht. Das ist kein Netzwerkproblem. Es ist ein Schemaproblem, und es zeigt sich in jeder Koalitionsoperation, in der C2-Systeme unabhängig voneinander beschafft wurden. Dieser Artikel untersucht die technischen Wurzeln dieser Fragmentierung und die Standardisierungsansätze, die ihr begegnen – beginnend mit den grundlegenden Datenmodellentscheidungen, die darüber bestimmen, ob ein C2-System überhaupt interoperabel sein kann.

Die Kosten proprietärer Datenmodelle in Koalitionsoperationen

Jede größere Koalitionsübung seit den 1990er-Jahren hat After-Action-Reports hervorgebracht, die Datenfreigabefehler anführen, die sich direkt auf Schemainkompatibilität zurückführen lassen. Das Muster ist konsistent: Jede Nation beschafft ein C2-System nach ihren eigenen Anforderungen, der Hersteller implementiert ein proprietäres Datenmodell, das für die Doktrin und Streitkräftestruktur dieser Nation optimiert ist, und das System funktioniert in nationalen Übungen gut. Die Probleme treten in dem Moment auf, in dem zwei oder mehr solcher Systeme ein gemeinsames Lagebild teilen müssen. Felder, die logisch identische Konzepte darstellen – der operative Status eines Verbands, die gemeldete Position eines Tracks, die zugewiesene Priorität einer Aufgabe – werden in jedem proprietären Schema unterschiedlich kodiert. Die Umwandlung zwischen ihnen erfordert eine Übersetzungsschicht, die keiner der Hersteller ursprünglich eingeplant hat und die für jede neue Systempaarung neu konstruiert werden muss.

Die operativen Kosten summieren sich auf zwei Arten. Die erste ist Latenz: Jeder Übersetzungsschritt, der nicht automatisiert werden kann, fügt der Sensor-to-Shooter-Schleife Zeit hinzu. Ein Track, der 45 Sekunden braucht, um von einem Sensorknoten zur Anzeige eines verbündeten Befehlshabers zu gelangen, ist in einem schnell ablaufenden Gefecht taktisch nutzlos. Die zweite Kostenart ist Treueverlust: Felder, die im Zielschema kein Äquivalent haben, werden stillschweigend verworfen. Ein in einem System als "TACON" (taktische Kontrolle) kodierter operativer Status wird in einem anderen zu einem leeren Feld oder einem generischen "aktiv"-Flag und beraubt den empfangenden Befehlshaber von Informationen, die in der Quelle vorhanden waren. Über eine große Übung oder Operation hinweg verschlechtert dieser kumulierte Datenverlust das Lagebewusstsein auf Weisen, die schwer zu messen, aber operativ bedeutsam sind.

Auch die wirtschaftlichen Kosten sind erheblich. Schätzungen aus multinationalen C2-Integrationsprogrammen zeigen durchweg, dass maßgeschneiderte bilaterale Übersetzungsschichten – einmal pro Systempaar gebaut, separat für jedes Versionsupgrade gewartet – 20 bis 40 % des gesamten Integrationsbudgets eines Koalitions-C2-Programms ausmachen. Diese Ressourcen werden für Arbeit aufgewendet, die keine neue Fähigkeit hervorbringt: Sie kompensieren lediglich das Fehlen eines gemeinsamen Schemas.

Etablierte Standards: JC3IEDM, APP-6, MIP Data Model – Abdeckung und Lücken

Das Multilateral Interoperability Programme (MIP) hat die am weitesten verbreiteten Datenmodellstandards für Koalitions-C2 hervorgebracht. JC3IEDM (Joint Command, Control and Consultation Information Exchange Data Model), als ISO-Standard ratifiziert, definiert ein normalisiertes relationales Schema, das Verbände, Ausrüstung, Einrichtungen, Aktionen, Pläne und ihre operativen Beziehungen abdeckt. Seine Entitäts-Beziehungs-Struktur wurde für den Datenbank-zu-Datenbank-Austausch konzipiert, bei dem beide Systeme Kopien derselben relationalen Tabellen führen und Änderungen über ein definiertes Replikationsprotokoll synchronisieren. JC3IEDM erreichte Mitte der 2000er-Jahre eine bedeutende Verbreitung als kanonisches Schema für die Koalitions-C2-Integration, insbesondere in Programmen mit mehreren europäischen Landstreitkräften.

APP-6 (NATO Military Symbols for Land Based Systems) befasst sich mit einem engeren Problem: wie man militärische Verbandssymbole und ihre Attribute über alliierte Anzeigen hinweg konsistent darstellt. APP-6D definiert eine Struktur für den Symbol-Identifikationscode (SIDC), eine Hierarchie von Verbandstypen von der Gliederungsebene bis hinunter zum Ausrüstungstyp sowie Standardmodifikatoren für Status, Größe und Zugehörigkeit. Obwohl APP-6 streng genommen ein Symbologiestandard und kein vollständiges Datenmodell ist, definiert es die Enumerationssätze, auf die ein C2-Datenmodell zurückgreifen muss, um Verbandstypen eindeutig darzustellen. Ein C2-System, das APP-6-SIDCs als kanonische Verbandstyp-Kennung verwendet, kann Verbandssymbologie mit jedem alliierten System austauschen, das dasselbe tut, ohne jede Enumerationsübersetzung.

Das MIP Data Model (MIM), Nachfolger von JC3IEDM, übernimmt eine UML-basierte Objektmodellstruktur, die direkter auf die nachrichtenorientierten Austauschmuster moderner C2-Architekturen abbildet. Anstatt gemeinsamen Datenbankzugriff zu erfordern, definiert MIM eine XML-Bindung, die es konformen Systemen ermöglicht, Daten über Standardtransporte auszutauschen. MIM führt außerdem eine formale Versionierung und eine modulare Konzeptgruppenstruktur ein, die den Erweiterungsprozess vereinfacht. MIM behält jedoch eine erhebliche Komplexität bei: Das vollständige Informationsmodell enthält mehrere Hundert Konzeptklassen, und die Implementierung einer konformen MIM-Schnittstelle erfordert nach wie vor Monate an Integrationsarbeit. Nationale Erweiterungen – die jede implementierende Nation hinzugefügt hat – bedeuten, dass zwei MIM-konforme Systeme dennoch keine Daten korrekt austauschen können, wenn eines eine nationale Erweiterung verwendet, die das andere nicht implementiert hat.

Wie Schemadivergenz Latenz in Sensor-to-Shooter-Schleifen erzeugt

Der Weg von einer Sensorerkennung zu einem handlungsrelevanten Track auf einer alliierten Anzeige durchläuft mehrere Datentransformationsschritte, und Schemadivergenz kann bei jedem davon Verzögerungen einschleusen. Betrachten Sie ein Bodenradar, das einen Fahrzeug-Track erkennt und ihn an sein nationales C2-System meldet. Das C2-System speichert den Track in seinem proprietären Schema und versucht dann, ihn über einen Koalitionslink mit einem alliierten System zu teilen. Wenn der Koalitionslink ein definiertes Austauschformat verwendet (etwa eine Link-16-J-Series-Nachricht oder eine MIM-XML-Instanz), muss das nationale C2-System zunächst sein internes Schema in das Austauschformat übersetzen. Wenn diese Übersetzung nicht korrekt implementiert ist – oder wenn das nationale Schema Felder führt, die im Austauschformat kein Äquivalent haben – schlägt der Übersetzungsschritt entweder stillschweigend fehl oder verliert Daten.

Auf der Empfängerseite muss das alliierte C2-System das eingehende Austauschformat in sein eigenes internes Schema übersetzen. Wenn das empfangende System eine andere Version des Austauschstandards verwendet oder nationale Erweiterungen hinzugefügt hat, die der Sender nicht befüllt, kann der empfangene Track mit fehlenden oder mit Standardwerten belegten Feldern gespeichert werden. Eine Track-Position, die im MGRS-Format ankommt, aber intern in UTM gespeichert wird, wird nur dann korrekt umgewandelt, wenn die Umwandlungslogik alle UTM-Zonen-Grenzfälle behandelt – eine Anforderung, die trivial klingt, aber in eingesetzten Systemen nahe Zonengrenzen reale Fehler verursacht hat. Jeder dieser Übersetzungsschritte kostet Zeit: Eine gut implementierte automatisierte Übersetzung fügt Millisekunden hinzu; eine schlecht implementierte, die unsichere Datensätze zur menschlichen Überprüfung in eine Warteschlange stellen muss, kann Minuten hinzufügen.

Der kumulative Effekt ist, dass schemainduzierte Latenz in einer mehrstufigen Koalitions-C2-Kette – Sensor zu nationalem System, nationales System zu Koalitions-Gateway, Koalitions-Gateway zu alliiertem nationalem System, alliiertes System zur Anzeige – leicht 30 bis 90 Sekunden für einen Track erreichen kann, der sich in unter zwei Sekunden ausbreiten sollte. Für zeitkritische Ziele und zeitkritische Bedrohungen ist dies der Unterschied zwischen einem nützlichen Track und einem historischen Datensatz. Wie im Zusammenhang mit der Designbegründung des Cursor-on-Target-Formats erörtert, sind die effektivsten Austauschformate jene, die die Übersetzungsdistanz zwischen Quellschema und Wire-Format minimieren.

OWL/RDF-Ontologien als Weg zur semantischen Interoperabilität

Relationale und UML-basierte Datenmodelle wie JC3IEDM und MIM definieren Struktur – welche Felder existieren und wie sie zusammenhängen – aber sie definieren Bedeutung nicht in einer Form, über die Maschinen schlussfolgern können. Zwei in zwei Schemata unterschiedlich benannte Felder können dasselbe Konzept darstellen; zwei identisch benannte Felder können subtil unterschiedliche Konzepte darstellen. Das Erkennen und Auflösen dieser semantischen Äquivalenzen und Unterschiede erfordert entweder menschliches Fachwissen oder eine formale semantische Schicht, die die Beziehungen maschinenlesbar macht. OWL (Web Ontology Language) und RDF (Resource Description Framework) liefern diese Schicht.

Eine OWL-Ontologie für militärische C2-Daten kann die JC3IEDM-Entitätstaxonomie als Klassenhierarchie mit formalen Subsumtionsbeziehungen darstellen. Sie kann behaupten, dass "ARMD-REGT" (ein Panzerregiment in der Verbandstyp-Taxonomie von JC3IEDM) eine Unterklasse von "LAND-UNIT" ist, die wiederum eine Unterklasse von "MILITARY-UNIT" ist. Ein aufnehmendes System, das nur das Konzept "MILITARY-UNIT" kennt, kann einen eingehenden, als "ARMD-REGT" typisierten Datensatz dennoch korrekt verarbeiten, weil die Subsumtionsaxiome der Ontologie dem Reasoner mitteilen, dass jedes "ARMD-REGT" eine "MILITARY-UNIT" ist. Diese Inferenzfähigkeit ist besonders wertvoll für die Handhabung nationaler Erweiterungen von Standardtaxonomien: Ein von dem C2-System einer Nation definierter Erweiterungstyp kann der nächstgelegenen Standard-Elternklasse in der gemeinsamen Ontologie zugeordnet werden, sodass aufnehmende Systeme, die die Erweiterung nicht kennen, sie elegant verarbeiten, anstatt den Datensatz abzulehnen.

Die praktische Übernahme von OWL/RDF in operativen C2-Systemen wurde durch Leistungs- und Werkzeugbedenken eingeschränkt. OWL-Reasoning über große operative Datensätze ist rechenintensiv, und die Reasoning-Latenz ist mit der Echtzeit-Track-Verarbeitung unvereinbar. Der praktischere Ansatz besteht darin, OWL-Ontologien zur Entwurfszeit zu verwenden, um die Übersetzungsregeln zu verifizieren und zu generieren, die dann in effizienten Laufzeitcode kompiliert werden – wobei die formale Semantik der Ontologie genutzt wird, um Zuordnungsfehler vor der Bereitstellung statt während des Einsatzes abzufangen. Mehrere NATO-Forschungsprogramme haben diesen Ansatz demonstriert und ontologisch abgeleitete Übersetzungsregelsätze hervorgebracht, die handgeschriebene Zuordnungen sowohl in Vollständigkeit als auch in Korrektheit übertreffen.

API-Gateway-Muster für die Schemaübersetzung zur Laufzeit

Unabhängig vom gewählten kanonischen Datenmodell besteht die praktische Herausforderung darin, die Schemaübersetzung in der Geschwindigkeit auszuführen, die die operative Umgebung verlangt. Ein API-Gateway-Muster – ein Übersetzungsdienst, der zwischen jedem Quellsystem und dem kanonischen Schemabus sitzt – bietet die operativ am besten erprobte Lösung. Die Integration jedes Quellsystems wird in einem dedizierten Adapter gekapselt, der vom nativen Schema dieses Systems in Echtzeit in das kanonische Schema übersetzt. Der Adapter ist die einzige Komponente, die das proprietäre Format des Quellsystems kennen muss; alle anderen Komponenten in der Koalitions-C2-Architektur sprechen ausschließlich das kanonische Schema.

Die Schema-Registry ist die kritische Infrastrukturkomponente, die das API-Gateway-Muster im großen Maßstab wartbar macht. Jede Schemaversion – sowohl für Quellsysteme als auch für das kanonische Modell – wird mit einer Versionskennung registriert. Jede Übersetzungsregel ist mit dem spezifischen Paar (Quellversion, Zielversion) markiert, auf das sie sich bezieht. Wenn ein Quellsystem sein Schema aktualisiert, muss nur der Adapter für dieses System aktualisiert werden; das kanonische Schema und alle anderen Adapter sind nicht betroffen. Die Schema-Registry dient auch als Prüfpfad: Jeder Datensatz, der die Übersetzungsschicht durchläuft, trägt Provenienz-Metadaten – Quellsystemkennung, Quellschemaversion, Übersetzungsregelversion, Zeitstempel – die eine nachträgliche Untersuchung jedes Datenqualitätsproblems ermöglichen.

Für Koalitionsumgebungen, in denen das kanonische Schema selbst nationalen Erweiterungen unterliegt, muss das API-Gateway auch die umgekehrte Richtung handhaben: die Übersetzung vom kanonischen Schema zurück in das proprietäre Schema eines nationalen Systems zur Verwendung. Diese bidirektionale Übersetzungsanforderung verdoppelt den Übersetzungsregelsatz und bringt die zusätzliche Herausforderung mit sich, kanonische Felder darzustellen, die im nationalen Zielschema kein Äquivalent haben. Der Standardansatz besteht darin, solche Felder in einem strukturierten Erweiterungs-Blob zu kodieren, der an den Zieldatensatz angehängt wird, wodurch die Daten für jedes künftige Upgrade des Zielsystems erhalten bleiben und gleichzeitig sichergestellt wird, dass das aktuelle System den Datensatz weiterhin fehlerfrei aufnehmen kann. Die Wahl der Nachrichtenbus-Architektur beeinflusst direkt, wie sauber diese Erweiterungs-Blobs angehängt und weitergeleitet werden können.

Governance: wem das kanonische Datenmodell in einer Koalition gehört

Technische Lösungen für die Schemainteroperabilität sind notwendig, aber nicht hinreichend. Jedes erfolgreiche Programm zur Standardisierung von Koalitionsdatenmodellen hat eine Governance-Struktur erfordert, die definiert, wer Änderungen am kanonischen Schema vorschlagen kann, wer sie genehmigt, wie nationale Erweiterungen registriert und geteilt werden und wie der Prozess zur Lösung von Konflikten zwischen nationalen Anforderungen aussieht. Ohne Governance driftet das kanonische Schema: Das Integrationsteam jeder Nation nimmt lokale Änderungen vor, um den Anforderungen seines Systems gerecht zu werden, die Änderungen werden nie an den gemeinsamen Standard zurückgespielt, und innerhalb von zwei Jahren hat das "kanonische" Schema so viele Varianten, wie es implementierende Nationen gibt.

Das MIP-Governance-Modell bietet eine nützliche Referenz. MIP arbeitet über ein Programme Board mit nationalen Vertretern, ein Configuration Control Board, das Schemaänderungen prüft und genehmigt, und einen veröffentlichten Release-Zyklus mit definierten Abwärtskompatibilitätszusagen. Änderungen am Kernschema erfordern einen Mehr-Nationen-Konsens; nationale Erweiterungen sind erlaubt, müssen aber in einer gemeinsamen Erweiterungs-Registry registriert und bei jedem Release-Zyklus auf eine mögliche Aufnahme in das Kernschema geprüft werden. Dieses Governance-Modell hat JC3IEDM und MIM durch mehr als zwei Jahrzehnte operativer Nutzung in Dutzenden implementierender Nationen getragen, was ein Beleg dafür ist, dass das Modell selbst unter den Koordinationsherausforderungen eines multinationalen Programms funktionsfähig ist.

Für kleinere Koalitionen oder bilaterale Programme, die keine MIP-große Governance-Struktur tragen können, ist eine leichtgewichtigere Alternative die Rolle eines benannten Datenmodellverwalters innerhalb einer der teilnehmenden Organisationen, mit einem formalen Änderungsantragsprozess, der die Freigabe aller betroffenen Systemeigentümer erfordert, bevor eine Schemaänderung bereitgestellt wird. Die zentrale Anforderung ist, dass der Änderungsmanagementprozess dokumentiert und konsequent befolgt wird – eine undokumentierte Änderung am kanonischen Schema, die den Übersetzungsadapter einer Nation ohne Vorwarnung beschädigt, ist genau die Art von Ereignis, das das Vertrauen in das Standardisierungsprogramm untergräbt und Nationen zurück zu maßgeschneiderten bilateralen Lösungen treibt.

Inkrementelle Migration: Legacy-Systeme umhüllen, ohne sie neu zu schreiben

Die meisten Bemühungen zur Standardisierung von C2-Datenmodellen stehen vor derselben Einschränkung: Die Legacy-Systeme, die interoperabel sein müssen, können nicht neu geschrieben werden. Sie wurden unter langfristigen Verträgen beschafft, sie tragen Jahre operativer Anpassungen, und ihre Ablösungszeitpläne werden in Jahrzehnten gemessen. Jeder Standardisierungsansatz, der eine vollständige Neuentwicklung des Systems erfordert, wird nicht umgesetzt werden. Der einzige gangbare Weg ist eine inkrementelle Migration durch Adapterschichten – ein Strangler-Fig-Muster, angewendet auf die militärische C2-Integration.

Der Strangler-Fig-Ansatz funktioniert wie folgt. Ein Übersetzungsadapter wird neben dem Legacy-System bereitgestellt. Der Adapter stellt allen externen Verbrauchern einen standardkonformen API-Endpunkt zur Verfügung – der das kanonische Schema spricht. Intern liest der Adapter aus der Datenbank oder dem Nachrichtenbus des Legacy-Systems, wendet die während des Schema-Audits dokumentierten feldbezogenen Übersetzungsregeln an und veröffentlicht konforme Nachrichten im kanonischen Schema an den gemeinsamen Broker. Externe Systeme integrieren sich gegen die kanonische Schnittstelle des Adapters, niemals direkt gegen das Legacy-Schema. Das Legacy-System läuft unverändert weiter. Mit der Zeit, wenn einzelne funktionale Subsysteme innerhalb der Legacy-Plattform das Ende ihrer Lebensdauer erreichen, können sie durch neue Implementierungen ersetzt werden, die das kanonische Schema nativ sprechen, und die entsprechenden Übersetzungsregeln im Adapter werden ausgemustert. Schließlich kann der Adapter vollständig ausgemustert werden, aber die externen Schnittstellen sind durchgehend stabil geblieben.

Die praktischen Herausforderungen dieses Ansatzes konzentrieren sich auf den Schema-Audit-Schritt. Legacy-C2-Systeme haben häufig undokumentierte Felder, implizite Konventionen, die in der Anwendungslogik statt im Schema kodiert sind, und Datenqualitätsprobleme, die der Übersetzungsadapter elegant handhaben muss – abgeschnittene Strings, Zahlenwerte außerhalb des gültigen Bereichs, Null-Felder, die niemals null sein dürften. Ein robuster Übersetzungsadapter muss eine Validierungs- und Bereinigungslogik enthalten, die diese Probleme an der Grenze abfängt und sie entweder korrigiert (für gut verstandene Fälle wie nachgestellte Leerzeichen oder falsche Groß-/Kleinschreibung) oder zur menschlichen Überprüfung protokolliert (für Fälle, in denen die korrekte Interpretation mehrdeutig ist). Der Aufbau dieser Validierungslogik erfordert direkten Zugriff auf die Daten des Legacy-Systems für einen Zeitraum des Shadow-Modus-Betriebs – wobei der Adapter parallel zum bestehenden Austauschpfad läuft und die Ausgaben Feld für Feld verglichen werden, bis die Übereinstimmungsrate bei operativ kritischen Feldern hoch genug ist, um die Umstellung zu rechtfertigen.