CoT und NATO-Standards verbinden: TAK in einem koalitionären Datennetz

Zwei Standards dominieren den taktischen Rand, und sie sprechen nicht nativ miteinander. Auf der einen Seite steht Cursor on Target (CoT) – das kompakte XML-Ereignisformat, das jeder TAK-Client aussendet, um Position, Identität und interessante Punkte zu teilen. Auf der anderen Seite stehen die NATO-Koalitionsstandards: die MIP Information Exchange Specification (MIP4-IES), aufgebaut auf dem JC3IEDM-Datenmodell, und das ADatP-34 NATO Friendly Force Information (NFFI)-Profil für die Freund-Kraft-Verfolgung über eine Föderation. Wenn eine nationale TAK-Enklave an ein Koalitionsbild angebunden werden muss, muss etwas zwischen ihnen übersetzen. Dieser Artikel untersucht, wie CoT in NATO-Standards überführt und ein TAK-Einsatz in ein koalitionäres Datennetz eingebunden wird, ohne dabei Spuridentität, Positionsqualität oder Freigabemarkierungen zu verlieren.

Warum CoT und NATO-Standards divergieren

CoT und die NATO-C2-Standards wurden für unterschiedliche Betriebspunkte konzipiert, und dieser Unterschied erklärt, warum eine Brücke notwendig ist – keine bloße Konfigurationsoption. CoT ist ein flaches, selbstbeschreibendes XML-Ereignis: ein einzelnes <event>-Element enthält eine eindeutige Kennung, einen Typ-String, einen Punkt mit Breite/Länge/Höhe und Fehlerschätzungen, eine Reihe von Zeitfeldern und einen offenen <detail>-Teilbaum. Es wurde für Verbindungen mit geringer Bandbreite und Endbenutzergeräte optimiert sowie für ein Publish-Subscribe-Muster, bei dem Tausende kleiner Ereignisse kontinuierlich fließen. Der gesamte Sinn von CoT besteht darin, dass jeder Client es ohne gemeinsames relationales Schema parsen kann.

JC3IEDM – das Datenmodell unter MIP4-IES – ist das entgegengesetzte Design. Es ist ein normalisiertes relationales Modell mit Hunderten von Objekttypen, strenger referenzieller Integrität und einer expliziten Berichts-und-Aufgaben-Semantik, die für die domänenübergreifende C2-Föderations zwischen nationalen Hauptquartiersystemen gedacht ist. ADatP-34 NFFI liegt zwischen den beiden: Es ist enger gefasst als JC3IEDM, konzentriert sich speziell auf die Positions-Meldung von Freundkräften und verwendet ein XML-Nachrichtenformat, das für die direkte Abbildung aus CoT geeigneter ist. Jeden TAK-Client zu zwingen, JC3IEDM direkt auszugeben, würde das Drahtformat und das Gerät über das hinaus belasten, was der taktische Rand verkraften kann. Die pragmatische Architektur hält CoT am Rand und übersetzt in einem Gateway.

Das Abbildungsproblem: CoT auf NFFI und MIP

Das Herzstück der Brücke ist eine Feldebenen-Abbildung zwischen dem CoT-Ereignismodell und dem Ziel-NATO-Schema. Jedes CoT-Ereignis hat einen kleinen, klar definierten Satz von Feldern, der ohne Bedeutungsverlust übertragen werden muss.

Identität. CoT identifiziert eine Entität durch ihre uid – einen opaken, quellzugewiesenen String. NFFI und JC3IEDM erwarten beide eine stabile Spur- oder Objektelement-Kennung, die dem meldenden Verband zugeordnet ist. Das Gateway kann die CoT-uid nicht einfach durchleiten; es muss eine Identitätskarte pflegen, die jede CoT-uid mit einer deterministischen netzseitigen Kennung verknüpft, sodass dieselbe physische Entität dieselbe Identität über die Brücke und über Wiederverbindungen hinweg behält.

Typ und Symbologie. Das CoT-type-Attribut kodiert eine von MIL-STD-2525 abgeleitete Hierarchie (zum Beispiel a-f-G-U-C für eine befreundete Bodenkampfeinheit). NFFI enthält ein Symbolcode-Feld, das eng mit 2525 übereinstimmt, sodass die Abbildung weitgehend mechanisch ist. JC3IEDM ist schwieriger: Der 2525-Typ muss in eine Objektelement-Kategorie plus den relevanten Untertyp und eine Zugehörigkeit aufgelöst werden – eine Eins-zu-viele-Suche statt einer direkten Kopie.

Geometrie und Qualität. Der CoT-<point> enthält Breite, Länge, Höhe über dem Ellipsoid (hae), kreisförmigen Fehler (ce) und linearen Fehler (le). NATO-Nutzer möchten eine quantifizierte Positionsqualität, daher müssen die ce/le-Werte in die Genauigkeitsfelder des Zielformats übersetzt werden – nicht verworfen werden. Eine Spur, die ohne Fehlerschätzungen ankommt, wird von einer Fusionsmaschine als wenig vertrauenswürdig behandelt.

Zeit und Veralterung. CoT-Ereignisse tragen time-, start- und stale-Zeitstempel. Das stale-Feld ist semantisch am stärksten belastet: Es teilt Nutzern mit, wann sie die Spur verwerfen sollen. NFFI und JC3IEDM drücken Gültigkeit unterschiedlich aus, sodass das Gateway die CoT-Veralterung in die Meldezeit plus ein Gültigkeits- oder Ablaufzeitfenster des Zielformats übersetzen und bei jedem Update neu stempeln muss.

Der Detail-Teilbaum

Das offene CoT-<detail>-Element enthält Rufzeichen, Teamfarbe, Rolle, Anmerkungen und sensorspezifische Erweiterungen. Die Abbildung von Detail ist der Teil der Brücke, der nie vollständig abgeschlossen ist, weil CoT-Detail per Design erweiterbar ist und verschiedene TAK-Plugins unterschiedliche Unterelemente ausgeben. Ein Produktions-Gateway bildet die bekannten Detail-Kindknoten (<contact>-Rufzeichen, <__group>-Team und -Rolle, <remarks>) auf ihre NFFI- oder JC3IEDM-Äquivalente ab und trägt nicht abgebildetes Detail als opake Annotation – statt es zu verwerfen – damit ein Rückweg in TAK keinen vom Operator eingegebenen Kontext stillschweigend verliert.

Gateway-Architektur im Datennetz

Ein koalitionäres Datennetz ist die logische Schicht, die es Daten aus vielen nationalen und funktionalen Systemen ermöglicht, über eine Föderation hinweg entdeckt, zugänglich gemacht und fusioniert zu werden – ohne eine Punkt-zu-Punkt-Integration für jedes Systempaar aufzubauen. Das CoT-zu-NATO-Gateway ist ein Knoten in diesem Netz und sitzt genau an der Grenze zwischen einer nationalen TAK-Enklave und den Koalitionsschnittstellen.

Das Gateway hat drei parallele Datenpfade. Der Eingangspfad abonniert den TAK-Server, parst CoT in ein kanonisches internes Modell und normalisiert Koordinaten und Fehlerschätzungen. Der Übersetzungs-und-Veröffentlichungs-Pfad bildet das kanonische Modell in das Ziel-NATO-Schema ab und veröffentlicht es im Netz – als NFFI-Dienst-Feed, MIP-Austausch oder Nachricht an den Publish-Subscribe-Broker des Netzes. Der Rückpfad empfängt Koalitionsspuren aus dem Netz, übersetzt sie in CoT und injiziert sie zurück in die TAK-Enklave, damit das TAK-Display des Operators das vollständige Koalitionsbild zeigt und nicht nur national erzeugte Spuren.

Da das Gateway bidirektional ist, ist Schleifenverhinderung nicht optional. Eine Spur, die die TAK-Enklave als CoT verlässt, übersetzt und veröffentlicht wird und dann über den Rückpfad zurückkommt, darf nicht als zweiter, doppelter Kontakt re-injiziert werden. Die Standardtechnik ist ein deterministischer uid-Namensraum pro Quelle kombiniert mit einem Herkunfts-Tag im CoT-Detail-Teilbaum, der beim Eingang geprüft wird: Erkennt das Gateway eine selbst erzeugte Spur, unterdrückt es die Neu-Übersetzung.

Identität, Herkunft und Freigabemarkierung

Der Austausch von Koalitionsdaten wird ebenso stark durch Richtlinien wie durch Protokolle geregelt, und das Gateway ist der Durchsetzungspunkt für beides. Jede Spur, die das Gateway im Netz veröffentlicht, muss eine Freigabemarkierung und die Wissensbedarfs-Vorbehalte tragen, die bestimmen, welche Koalitionspartner sie einsehen dürfen. CoT selbst hat kein standardisiertes Klassifizierungsfeld, daher wird die Markierung am Gateway gemäß der Freigaberichtlinie der Enklave angewendet – typischerweise gesteuert durch die Quellgruppe, den Spurtyp oder eine explizite Operator-Markierung im Detail-Teilbaum.

Herkunft reist mit der Markierung. Ein fusioniertes Koalitionsbild ist nur dann vertrauenswürdig, wenn jede Spur zu ihrem Ursprungssystem zurückverfolgt werden kann, weil eine Spur unbekannter Herkunft bei der Fusion nicht korrekt gewichtet oder gegen andere Quellen korreliert werden kann. Das Gateway versieht jede ausgehende Spur mit der Identität der Ursprungs-Enklave und dem Übersetzungszeitstempel und bewahrt diese Herkunft auf dem Rückpfad, damit ein TAK-Operator erkennen kann, dass ein Kontakt von einem Koalitionspartner und nicht von einem nationalen Sensor stammt. Der breitere Satz politischer und technischer Hindernisse – Vorbehalte, domänenübergreifende Übertragung und Vertrauen – wird in unserer Analyse der Herausforderungen beim Austausch von Koalitionsdaten behandelt.

Konformität: die Brücke gegen die Standards testen

Eine CoT-zu-NATO-Brücke ist nur dann nützlich, wenn ihre Ausgabe konform ist, und Konformität muss gegen die tatsächlichen NATO-Spezifikationen getestet werden – nicht gegen eine bequeme Interpretation davon. Für NFFI wird die Ausgabe des Gateways gegen das ADatP-34-Schema validiert und gegen einen NFFI-Referenz-Empfänger ausgeführt, um zu bestätigen, dass Symbolcodes, Identitäten und Gültigkeitszeitfenster wie beabsichtigt interpretiert werden. Für MIP ist die Konformität aufwändiger: Die JC3IEDM-Abbildung muss referenzielle Integrität und die MIP4-IES-Meldungssemantik erfüllen, weshalb die MIP-Integration typischerweise in einer strukturierten Übung und nicht auf dem Prüfstand validiert wird.

Die Abbildungstabelle selbst sollte versioniert und nachvollziehbar sein. CoT-Typencodes entwickeln sich, NFFI und JC3IEDM werden überarbeitet, und eine undokumentierte Änderung an einer einzigen Typabbildung kann stillschweigend einen feindlichen Kontakt über eine gesamte Koalition als unbekannt umkennzeichnen. Die Abbildung als geprüftes, versioniertes Artefakt zu behandeln – nicht als Konstanten, die im Übersetzer vergraben sind – macht die Brücke über Standardüberarbeitungen hinweg wartbar. Für die breitere Standardlandschaft, der die Brücke entsprechen muss, siehe unsere Übersicht über MIP4-IES und den NATO-Bodenkraft-Standard.

Durchsatz, Drosselung und das Tempo-Missverhältnis

CoT und die NATO-Standards unterscheiden sich nicht nur in der Struktur – sie unterscheiden sich im Tempo, und eine Brücke, die dieses Missverhältnis ignoriert, überflutet entweder das Koalitionsnetz oder verhungert es. Eine ausgelastete TAK-Enklave kann einen hochfrequenten Strom von CoT-Updates erzeugen: Ein fahrendes Fahrzeug mit GPS-Feed kann jede Sekunde ein Positionsereignis ausgeben, und hundert solcher Spuren erzeugen einen kontinuierlichen Schwall kleiner Ereignisse. JC3IEDM-basierte C2-Systeme hingegen erwarten Meldungen in einem Rhythmus, der in Zehnten von Sekunden gemessen wird, weil jedes Update eine relationale Transaktion mit referenziellen Integritätsprüfungen bedeutet – kein Fire-and-Forget-Broadcast.

Das Gateway muss daher ein aktiver Ratenmanager sein, kein passiver Übersetzer. Das Standardmuster ist Dezimierung pro Spur: Das Gateway hält den letzten CoT-Zustand für jede uid und veröffentlicht im Netz in einem festen Rhythmus – oder wenn sich eine Spur um mehr als eine Schwellentfernung bewegt, je nachdem, was zuerst eintritt – statt jedes eingehende Ereignis weiterzuleiten. Dies bewahrt die operativ bedeutsamen Updates (eine Spur, die sich tatsächlich bewegt), während die redundanten hochfrequenten stationären Meldungen zusammengefasst werden, die andernfalls einen MIP-Empfänger überfordern würden. Die Dezimierungsrichtlinie gehört in die Konfiguration, weil der richtige Rhythmus von der Verbindung und dem empfangenden System abhängt – nicht von einem fest im Übersetzer kodierten Wert.

Der Rückpfad braucht die umgekehrte Disziplin. Koalitionsspuren, die aus dem Netz einlaufen, haben typischerweise einen langsameren Rhythmus, sodass ihre direkte Injektion in TAK dazu führen kann, dass sie zwischen weit auseinander liegenden Positionen zu springen scheinen. Glättung durch Koppelnavigations-Extrapolation zwischen Netz-Updates – Verwendung der gemeldeten Geschwindigkeit zur Interpolation der Position – gibt dem TAK-Operator eine flüssige Anzeige statt einer Spur, die in jedem Meldeintervall teleportiert. Die Extrapolation muss begrenzt sein und nach einem verpassten Update klar degradiert werden, damit eine veraltete Koalitionsspur nie als zuverlässige aktuelle Position präsentiert wird.

Resilienz ist genauso wichtig wie Durchsatz. Die Verbindung zwischen einer nationalen Enklave und dem Koalitionsnetz ist selten so zuverlässig wie ein kabelgebundenes LAN, daher muss das Gateway ausgehende Spuren über kurze Unterbrechungen hinaus puffern und die Identität bei der Wiederverbindung abgleichen – indem es den aktuellen Zustand jeder aktiven Spur neu veröffentlicht, statt den gesamten Rückstand der Zwischenereignisse abzuspielen. Auf der TAK-Seite sollte das Gateway koalitionserzeugte Spuren umgehend als veraltet markieren, wenn die Netzverbindung abbricht, damit ein Operator nie durch ein Koalitionsbild irregeführt wird, das nicht mehr aktualisiert wird.

Der Lohn für eine korrekt aufgebaute Brücke ist operativ, nicht theoretisch: Ein Soldat mit einem Endbenutzergerät sieht dasselbe Koalitionsbild wie ein nationales Hauptquartier, das ein JC3IEDM-basiertes C2-System betreibt, und ein von einem nationalen Sensor gemeldeter Kontakt erscheint – korrekt typisiert, korrekt markiert und nachverfolgbar – auf dem Display jedes Partners. Das ist es, was ein koalitionäres Datennetz leisten soll, und das CoT-zu-NATO-Gateway ist die Komponente, die den taktischen Rand zu einem gleichberechtigten Teilnehmer darin macht.