Cursor on Target ist das kleinste Schema, das in moderner taktischer Software die meiste Arbeit leistet. Ein einziges XML-Dokument — wenige hundert Bytes — trägt eine Position, eine Identität, eine Konfidenz und eine Lebensdauer, und dieses Dokument genügt, um auf jeder Karte in einem Mesh-Netzwerk eine Markierung zu setzen. Es entstand als MITRE-Initiative, die es einem Operator ermöglichen sollte, ein Ziel mit einer buchstäblichen Cursor-Geste von einem System an ein anderes weiterzureichen, und wurde zur Lingua franca des TAK-Ökosystems. Dies ist eine Feld-für-Feld-Betrachtung des Cursor-on-Target-Formats: das event-Modell, die Typtaxonomie, die point-Geometrie, der detail-Container und die Realitäten, es korrekt zu erzeugen und zu validieren.
1. das CoT-event-Modell
Jede CoT-Nachricht ist ein einzelnes <event>-Element. Es gibt keinen Umschlag, keinen Header, kein separates Registry für Nachrichtentypen — das Wurzelelement ist die Nachricht. Dies ist die bewusste Designentscheidung, die CoT günstig macht: Ein einziges rekursives Schema trägt einen befreundeten Soldaten, ein feindliches Fahrzeug, einen Geofence, eine Chatnachricht, ein Notsignal und einen Sensor-Track, ohne einen pro Nachrichtentyp eigenen Codepfad auf der Leitung.
Das event enthält genau ein <point>-Kind (wo sich das Objekt befindet) und ein optionales <detail>-Kind (alles Übrige darüber). Die Semantik eines events wird vollständig durch seine Attribute plus den offenen Inhalt von <detail> bestimmt. Ein Parser, der die vier Kernattribute und den point versteht, kann jede CoT-Nachricht auf einer Karte darstellen, ohne eine einzige detail-Erweiterung zu verstehen — diese Eigenschaft des anmutigen Abbaus (graceful degradation) ist der Grund, warum CoT über Hersteller hinweg skaliert, die sich nie abgestimmt haben.
Es lohnt sich, bei dem zu verweilen, was nicht im Modell steht. Es gibt keine schemaseitige Unterscheidung zwischen einer Einheit, einer Markierung, einer Chatnachricht und einem Sensor-Track — das sind alles events, unterschieden allein durch ihren type und die detail-Kinder, die sie tragen. Es gibt keine Bestätigung, keine Sequenznummer und keine Session. CoT ist fire-and-forget; Zuverlässigkeit, Reihenfolge und Zustellung werden auf den Transport (TCP, TLS oder Multicast-UDP) und die darüberliegende Anwendung verlagert. Dieser Minimalismus ist die definierende Eigenschaft des Schemas: Es tut eine Sache — für eine begrenzte Zeit sagen, wo etwas ist und was es ist — und weigert sich, einen eigenen Protokollstapel auszubilden.
2. event-Attribute
Das <event>-Element trägt eine feste Menge an Attributen. version ist die Schemaversion, fast immer 2.0. uid ist der global eindeutige Bezeichner für das beschriebene Objekt — nicht die Nachricht, das Objekt. Beim erneuten Senden einer aktualisierten Position für dieselbe Entität wird dieselbe uid wiederverwendet; so weiß ein Empfänger, dass er eine bestehende Markierung bewegen und nicht eine neue erzeugen soll. UIDs sind frei formulierbare Zeichenketten, aber TAK-Clients verwenden konventionell einen stabilen gerätebezogenen Bezeichner (z. B. ANDROID-serial) für Selbstmeldungen.
type ist die MITRE-Typzeichenkette (Abschnitt 3). how beschreibt die Herkunft der Daten — wie die Position abgeleitet wurde. Übliche Werte sind h-g-i-g-o (human, GPS-derived, manuell eingegeben) und m-g (machine, GPS). Das how-Feld ist das, was es einer Fusion-Engine erlaubt, eine handeingegebene Lagemeldung anders zu gewichten als einen Live-GPS-Feed.
Die Lebenszyklus-Triade ist time, start und stale, allesamt ISO-8601-UTC-Zeitstempel. time ist, wann die Nachricht erzeugt wurde. start ist, wann die Information gültig wird. stale ist, wann sie abläuft. Das Fenster zwischen start und stale ist die Gültigkeitslebensdauer des events: Nachdem stale verstrichen ist, muss ein konformer Empfänger das event als abgelaufen behandeln und die Markierung entfernen oder ausgrauen. Eine Selbstpositionsmeldung einer sich bewegenden Einheit könnte stale auf time + 75 Sekunden setzen; ein statischer Vermessungspunkt könnte es Stunden in die Zukunft setzen. Diese Triade richtig hinzubekommen, ist die mit Abstand häufigste Quelle von „Geistermarkierungen“ — setzt man stale zu weit in die Zukunft, verharren tote Tracks; setzt man es zu kurz, flackern lebende Tracks.
Kerngedanke: CoT hat keine explizite Löschnachricht. Man zieht einen Track zurück, indem man ihn verfallen lässt, oder indem man eine letzte Aktualisierung sendet, deren stale-Zeit bereits in der Vergangenheit liegt. Zustandsverwaltung in einem CoT-Netzwerk ist daher ein Timeout-Problem, kein Transaktionsproblem — jeder Empfänger betreibt unabhängig Garbage-Collection nach seiner eigenen Uhr, weshalb Uhrenversatz zwischen Knoten eine betriebliche Gefahr ist, keine kosmetische.
3. die MITRE-Typhierarchie
Das type-Attribut kodiert was das Objekt ist mit MITREs gepunkteter, mit Bindestrichen versehener Taxonomie. Die wichtigste Familie ist der Atom-Typ, mit dem Präfix a-. Ein Atom-Typ liest sich als eine Folge bindestrichgetrennter Token: a-f-G-U-C.
Das erste Token nach a ist die Zugehörigkeit: f freund, h feindlich, n neutral, u unbekannt, p ausstehend, dazu Varianten für angenommen/verdächtig. Das nächste Token ist die Gefechtsdimension: G Boden, A Luft, S Oberfläche (See), U Unterwasser, P Weltraum, F SOF. Die verbleibenden Token gehen die MIL-STD-2525-Symbolhierarchie hinunter — a-f-G-U-C ist eine befreundete Bodeneinheit, Kampf, und so weiter. Ein Platzhalter a-f-G-* bedeutet „ein befreundetes Bodenobjekt, darüber hinaus unspezifiziert“, und Renderer greifen auf das nächstgelegene definierte Symbol zurück. Nicht-Atom-Familien verwenden andere Präfixe: b- für Bits (Sensor-/Geometriedaten, z. B. b-m-p-s-p-i für einen Sensor-Point-of-Interest), t- für Tasking und y- für Antworten. Das Geniale an der gepunkteten Taxonomie ist, dass sie präfixdekodierbar ist: Ein Client, der nur a-f-G kennt, kann immer noch ein generisches Freund-Boden-Icon platzieren und beim nicht erkannten Rest anmutig degradieren.
4. das point-Element
Das <point>-Element ist verpflichtend und trägt fünf Attribute, alle erforderlich. lat und lon sind WGS-84-Dezimalgrad. hae ist die Höhe über dem Ellipsoid in Metern — beachten Sie „über dem Ellipsoid“, nicht über dem mittleren Meeresspiegel; das Vermischen von HAE und orthometrischer Höhe (der Geoid-Offset kann 30 m überschreiten) ist ein klassischer Vertikalfehler, wenn CoT auf ein System trifft, das MSL erwartet.
ce ist der Kreisfehler (circular error) — der horizontale 1-Sigma-Unsicherheitsradius in Metern. le ist der Linearfehler (linear error) — die vertikale Unsicherheit in Metern. Zusammen erlauben sie einem Empfänger, einen Genauigkeitsring statt eines trügerisch präzisen Punkts zu zeichnen. Der Sentinel-Wert 9999999 (oft als 9999999.0 geschrieben) bedeutet „unbekannt“ — es ist keine echte Messung, es ist das Null des Schemas. Ein manuell gesetzter Punkt ohne vermessene Genauigkeit trägt ce="9999999" le="9999999", und die Fusionslogik muss diesen Wert sonderbehandeln, statt ihn als Fehler von zehntausend Kilometern zu behandeln.
Da jedes Attribut erforderlich ist, gibt es so etwas wie einen point ohne Höhe oder ohne Fehlerschätzung nicht — das Schema zwingt den Erzeuger, eine Aussage zu treffen, selbst wenn diese Aussage „unbekannt“ lautet. Das ist eine still und leise gute Designentscheidung: Ein Empfänger muss nie raten, ob ein fehlendes Feld null, unbekannt oder Standard bedeutet. Er hat entweder eine echte Zahl oder den Sentinel, und die beiden sind eindeutig. Der Preis ist, dass faule Encoder für alles hae="0.0" hartkodieren, was schlimmer ist als der Sentinel, weil es wie eine echte Meereshöhenmessung aussieht. Wenn Sie die Höhe nicht kennen, sagen Sie das mit 9999999; behaupten Sie nicht null.
5. das detail-Element
Das <detail>-Element ist der offene Erweiterungscontainer, und hier lebt das CoT-Ökosystem tatsächlich. Das Schema legt seinen Kindern keine Beschränkung auf — jedes wohlgeformte XML ist zulässig —, was es TAK erlaubte, ein reiches Anwendungsprotokoll auf ein generisches SA-Format zu legen, ohne es zu forken.
Die konventionellen Unterelemente werden weithin beachtet. <contact> trägt ein menschenlesbares callsign und, für TAK, Endpunkt-Adressierung für Direktnachrichten. <track> trägt course und speed für sich bewegende Entitäten und verwandelt einen statischen Punkt in einen Vektor. <remarks> ist Freitext. <status> meldet Dinge wie den Batteriestand. <__group> (doppelter Unterstrich) ordnet die Einheit einer TAK-Teamfarbe und -Rolle zu — Cyan, Team Member — und steuert so die Farbe des Icons auf dem Bildschirm jedes Teammitglieds. <takv> meldet die TAK-Client-Version, das Gerät und die Plattform. Weil detail offen ist, überspringt ein Empfänger einfach die Kinder, die er nicht erkennt, was die gesamte Grundlage der CoT- und TAK-Interoperabilität über heterogene Clients hinweg ist.
6. CoT vs. Link 16 und VMF
CoT besetzt denselben konzeptionellen Raum wie die J-Serie und VMF, aber mit gegensätzlichen Designprioritäten. Link-16-J-Messages sind festformatige, bit-gepackte Wörter, bemessen für einen TDMA-Slot; VMF (MIL-STD-6017) ist ein variables, aber eng bitorientiertes Format für bandbreitenarme Träger. CoT ist ausführliches XML, gebaut für IP-Netze, in denen Bytes günstig sind und Entwicklerzeit nicht.
Die Abbildung von CoT auf eine J-Message ist in beide Richtungen verlustbehaftet. CoTs Zugehörigkeit und Gefechtsdimension bilden sich sauber auf J3.x-Track-Felder und auf VMF-Identitätsfelder ab, und lat/lon/hae übersetzen sich direkt. Die Impedanzfehlanpassung liegt in Präzision und Semantik: Eine Track-Qualität der J-Serie ist ein diskreter aufgezählter Wert, wo CoTs ce/le kontinuierliche Meter sind; CoTs offenes <detail> hat kein festformatiges Gegenstück und wird an einem Gateway vollständig verworfen. Umgekehrt haben J-Serien-Felder wie spezifische IFF-Modi oder PPLI-abgeleitete Netzteilnahme keinen nativen CoT-Slot und müssen in benutzerdefinierte detail-Erweiterungen geschmuggelt werden. Gateways, die CoT und taktische Datenlinks überbrücken, tragen daher eine meinungsbehaftete, von Hand gepflegte Feldabbildung — dasselbe Übersetzer-mit-Meinung-Problem, das überall in der NATO-C2 auftaucht.
7. Streaming und TAK
In der Produktion ist CoT ein Stream, kein Dokument. TAK Server multiplext CoT-events zwischen Clients: Die Selbstpositionsmeldung einer Einheit fließt über eine persistente TCP- (oft TLS-)Verbindung mit konfigurierbarer Rate nach oben — üblicherweise alle 1 bis 10 Sekunden, abhängig von der Bewegung und der „dynamic reporting“-Einstellung — und der Server verteilt sie an Abonnenten, optional gefiltert nach Mission, Gruppe oder Geofence. Mesh SA, der serverlose Modus, multicastet dieselben events über UDP im lokalen Netz, sodass ein Trupp ohne Infrastruktur operiert.
Nachrichtenraten treiben das Engineering. Eine Übung mit 200 Knoten, bei der jeder alle 2 Sekunden meldet, ergibt allein an Selbstposition 100 events/Sekunde, noch vor Sensor-Tracks. Der Server unterhält für nichts davon ein Löschprotokoll; stattdessen betreibt jeder Client unabhängig Garbage-Collection anhand der stale-Zeitstempel, die er gesehen hat. Stale-gesteuerte Garbage-Collection ist elegant — kein Leader, kein Konsens —, aber sie bedeutet, dass ein Client, der die Konnektivität verliert, zusehen wird, wie sein gesamtes Lagebild planmäßig altert und verschwindet, was meist das richtige Verhalten und gelegentlich eine böse Überraschung während eines Funkausfalls ist.
8. CoT validieren und erzeugen
Das Wire-Format ist nachsichtig, was es einfach macht, subtil fehlerhaftes CoT zu emittieren. Validieren Sie während der Entwicklung gegen das veröffentlichte Event.xsd-Schema, kennen Sie aber dessen Grenzen: Das XSD prüft, dass point existiert und dass die Lebenszyklus-Attribute vorhanden und wohltypisiert sind, aber es kann Ihnen nicht sagen, dass Ihr stale vor Ihrem start liegt, dass Ihr type-Token bedeutungslos ist oder dass Ihr hae eine Geoid-Höhe ist, die sich als Ellipsoid-Höhe ausgibt.
Die wiederkehrenden Fehler bei fehlerhaften Nachrichten sind vorhersehbar. Zeitstempel ohne abschließendes Z oder mit Lokalzonen-Offsets — CoT-Zeit ist UTC, Punkt, und ein fehlendes Z schickt Markierungen in die Vergangenheit oder Zukunft. Invertierte Lebensdauern, bei denen stale vor start liegt, erzeugen events, die bei Ankunft bereits tot sind. Die Wiederverwendung einer einzigen uid für verschiedene Entitäten, was zwei echte Tracks in eine flackernde Markierung kollabieren lässt. Das Emittieren eines echt aussehenden ce statt des 9999999-Sentinels für einen unvermessenen Punkt, was die Fusion dazu verleitet, Müll zu vertrauen. Wenn Sie einen CoT-Encoder bauen, machen Sie die Lebenszyklus-Triade zu einem erstklassigen Typ, der start ≤ stale erzwingt und UTC mit dem Z rendert, erzeugen Sie UIDs aus einem stabilen Entitätsschlüssel statt aus einem pro-Nachricht-Zähler, und emittieren Sie den Unbekannt-Sentinel explizit. Bringen Sie diese vier Invarianten richtig hin, und Ihr CoT wird mit Clients interoperieren, die Sie nie gesehen haben — was der ganze Sinn des Formats ist.