Exemples de messages CoT : XML Cursor on Target annoté pour ATAK et TAK

Chaque message Cursor on Target (CoT) est un document XML unique dont l'élément racine, <event>, porte un code de type, un identifiant unique, trois horodatages UTC et une position <point> ; tout le reste voyage dans le conteneur ouvert <detail>. Cette forme unique fait circuler positions, marqueurs, chat, routes, tracés, alertes et demandes médicales entre ATAK, WinTAK, iTAK et TAK Server. Cette page est la bibliothèque à copier-coller : du CoT XML annoté et syntaxiquement valide pour les messages que les systèmes tactiques échangent réellement, chacun avec une note sur ce que le client TAK récepteur en fait.

Pour l'histoire et la conception du format, lisez notre panorama du format Cursor on Target ; pour une analyse champ par champ, le passage en revue approfondi du schéma CoT ; cet article reste volontairement au niveau « montrez-moi le XML ». Les noms d'éléments et d'attributs ci-dessous ont été vérifiés auprès de la documentation publique du schéma d'événement de base CoT de MITRE et des définitions de types CoT publiées avec les clients TAK. Les indicatifs, UID et coordonnées sont fictifs ; les horodatages sont des valeurs ISO-8601 UTC illustratives.

L'anatomie d'un message CoT

Un événement CoT minimal et valide exige sept attributs <event>, exactement un <point> et, en option, un <detail> :

<event version="2.0" uid="ANDROID-9c2f71a4" type="a-f-G-U-C" how="m-g"
       time="2026-10-07T06:12:44.000Z" start="2026-10-07T06:12:44.000Z"
       stale="2026-10-07T06:13:14.000Z">
  <point lat="50.450112" lon="30.523398" hae="152.4" ce="4.5" le="9.0"/>
  <detail>
    <contact callsign="GRIF-2" endpoint="*:-1:stcp"/>
    <__group name="Cyan" role="Team Member"/>
    <status battery="78"/>
    <takv platform="ATAK-CIV" version="5.2.0" device="Samsung SM-G975F" os="34"/>
    <track speed="1.4" course="270.0"/>
    <precisionlocation geopointsrc="GPS" altsrc="GPS"/>
  </detail>
</event>

Ce que chaque partie pilote chez le client récepteur :

Trois propriétés de <point> piègent régulièrement les intégrateurs. hae est la hauteur au-dessus de l'ellipsoïde WGS-84, pas au-dessus du niveau moyen de la mer. ce et le sont les bornes d'erreur horizontale et verticale à 1 sigma en mètres, exigées par le schéma même inconnues — la valeur 9999999.0 est la sentinelle convenue pour « inconnu », préférable à un 0.0 trop assuré. Et lat/lon sont des degrés décimaux signés, six décimales donnant environ 0,1 m de résolution ; pas d'option MGRS ni UTM en CoT.

Codes de type CoT et valeurs how : l'aide-mémoire

L'attribut type est un chemin séparé par des tirets dans une taxonomie dont le premier jeton dit quel genre d'événement c'est :

Pour les atomes, le deuxième jeton est l'appartenance et le troisième la dimension de bataille ; la suite descend l'arbre des fonctions MIL-STD-2525 en majuscules, les minuscules étant réservées aux extensions CoT :

La taxonomie étant décodable par préfixe, un client qui ne comprend que a-h-G dessine malgré tout une icône générique hostile au sol pour a-h-G-E-V-A-T. Chaînes fréquentes dans le trafic réel : a-f-G-U-C (allié, sol, combat — le type d'appareil ATAK par défaut), a-f-A-M-F-Q / a-f-A-M-H-Q (drone allié à aile fixe / à voilure tournante), a-u-G (sol inconnu), b-m-p-s-m (marqueur spot map), b-t-f (GeoChat), b-m-r (route), b-r-f-h-c (demande médicale 9-line). Le passage des icônes aux symboles est traité dans le rendu de la symbologie dans TAK et la comparaison des normes dans APP-6 contre MIL-STD-2525.

L'attribut how consigne la provenance, et les systèmes de fusion pondèrent les rapports selon lui :

Règles de temps : time, start et stale sont en ISO 8601 UTC, terminés par Z (les fractions de seconde sont optionnelles). time est le moment de production de l'événement ; start–stale est la fenêtre de validité. Mettre stale avant start est la convention MITRE d'origine pour « abandonner la piste » — même si, dans les réseaux TAK, une tâche de suppression explicite (ci-dessous) est plus fiable.

Rapports de position : PLI allié et marqueurs hostiles/neutres

L'exemple en haut de cette page est un rapport de position propre (PLI) : ATAK le rejoue toutes les quelques secondes avec le même uid, fixe stale à environ deux à quatre intervalles de rapport plus une marge, et laisse chaque autre client retirer le marqueur si les mises à jour s'arrêtent. Les marqueurs alimentés par capteurs ou posés par un opérateur utilisent la même forme d'événement avec un type différent et un stale plus long :

<event version="2.0" uid="E-20261007-0413" type="a-h-G-E-V-A-T" how="h-g-i-g-o"
       time="2026-10-07T06:41:02.000Z" start="2026-10-07T06:41:02.000Z"
       stale="2026-10-07T18:41:02.000Z">
  <point lat="50.412220" lon="30.591054" hae="9999999.0" ce="25.0" le="9999999.0"/>
  <detail>
    <contact callsign="K-41"/>
    <remarks source="BAO.F.ATAK.ANDROID-9c2f71a4">Hull-down at treeline, 2 vehicles</remarks>
    <usericon iconsetpath="COT_MAPPING_2525C/a-h/a-h-G-E-V-A-T"/>
    <link uid="ANDROID-9c2f71a4" type="a-f-G-U-C" relation="p-p"/>
    <archive/>
  </detail>
</event>

Ce que font les récepteurs : le type peint le losange rouge du char ; contact/callsign devient l'étiquette ; usericon épingle l'entrée exacte du jeu d'icônes (la forme COT_MAPPING_2525C/<affiliation>/<type> est celle qu'émet la palette 2525 d'ATAK) ; link relation="p-p" crédite le producteur ; <archive/> demande aux clients de conserver le marqueur au lieu de le laisser expirer avec stale. Les contacts inconnus utilisent simplement a-u-G ; l'icône jaune à point d'interrogation apparaît sans autre changement. Pour une simple épingle colorée sans codage 2525, ATAK utilise un marqueur spot map :

<event version="2.0" uid="9405e320-9356-41c4-8449-f46990aa17f8"
       type="b-m-p-s-m" how="h-g-i-g-o"
       time="2026-10-07T06:55:10.000Z" start="2026-10-07T06:55:10.000Z"
       stale="2026-10-08T06:55:10.000Z">
  <point lat="50.456090" lon="30.563750" hae="9999999.0" ce="9999999.0" le="9999999.0"/>
  <detail>
    <contact callsign="R 1"/>
    <color argb="-65536"/>
    <usericon iconsetpath="COT_MAPPING_SPOTMAP/b-m-p-s-m/-65536"/>
  </detail>
</event>

Ici, l'icône est choisie par usericon dans la palette spot map et par la valeur de couleur ARGB (un entier signé 32 bits, -65536 étant le rouge opaque) plutôt que par un code de symbologie — utile pour les annotations alliées qui ne doivent pas sous-entendre une identité 2525.

Messages GeoChat (b-t-f)

Le chat dans le monde TAK n'est pas un protocole à part : une ligne GeoChat est un événement CoT de type b-t-f dont le texte voyage dans <remarks> et l'adressage dans <__chat>/<chatgrp> :

<event version="2.0"
       uid="GeoChat.ANDROID-9c2f71a4.All Chat Rooms.3f8c2b1e-77d3-4c9a-9e21-5b0f6a2d4e88"
       type="b-t-f" how="h-g-i-g-o"
       time="2026-10-07T07:02:31.000Z" start="2026-10-07T07:02:31.000Z"
       stale="2026-10-08T07:02:31.000Z">
  <point lat="0.0" lon="0.0" hae="0.0" ce="9999999.0" le="9999999.0"/>
  <detail>
    <__chat id="All Chat Rooms" chatroom="All Chat Rooms" groupOwner="false"
            senderCallsign="GRIF-2"
            messageId="3f8c2b1e-77d3-4c9a-9e21-5b0f6a2d4e88">
      <chatgrp uid0="ANDROID-9c2f71a4" uid1="All Chat Rooms" id="All Chat Rooms"/>
    </__chat>
    <link uid="ANDROID-9c2f71a4" type="a-f-G-U-C" relation="p-p"/>
    <remarks source="BAO.F.ATAK.ANDROID-9c2f71a4"
             time="2026-10-07T07:02:31.000Z">Bearing 085, treeline, over.</remarks>
  </detail>
</event>

Lecture : l'uid de l'événement est conventionnellement GeoChat.<sender>.<conversation>.<message-uuid>, ce qui rend la déduplication au rejeu triviale ; chatgrp/uid0 est l'expéditeur et uid1 la destination — l'UID d'un destinataire unique pour un message direct, le nom du salon pour une diffusion ; remarks/@to porte l'UID du destinataire dans les messages directs ; stale est posé à un jour parce que le chat doit survivre au store-and-forward, contrairement aux positions. Les accusés de livraison et de lecture reviennent avec les types b-t-f-d et b-t-f-r. Le point de l'événement peut ancrer le message à un lieu sur la carte ; ATAK relaie aussi la position en direct de l'expéditeur, sauf si l'opérateur la désactive. Pour le tableau complet store-and-forward et bande passante, voir le chat tactique et la stratégie de données dans TAK.

Routes, tracés et lignes distance-azimut

Une route est un événement b-m-r dont les points de passage sont des enfants <link> — b-m-p-w pour les points nommés, b-m-p-c pour les points de contrôle de forme — suivis d'un bloc de style <link_attr> :

<event version="2.0" uid="9017073e-5658-42e7-baa8-b98f3c9c1622" type="b-m-r" how="h-e"
       time="2026-10-07T07:20:00.000Z" start="2026-10-07T07:20:00.000Z"
       stale="2026-10-08T07:20:00.000Z">
  <point lat="0.0" lon="0.0" hae="9999999.0" ce="9999999.0" le="9999999.0"/>
  <detail>
    <link uid="f3acf150-d75c-407d-be43-e401ab40fe74" callsign="SP"
          type="b-m-p-w" point="50.443353,-77.054400" remarks="" relation="c"/>
    <link uid="820ebf04-1300-4c3a-a368-d6f1e21a5ddb" callsign=""
          type="b-m-p-c" point="50.436413,-77.045642" remarks="" relation="c"/>
    <link uid="f6926af1-deec-44f4-ae06-46065c829887" callsign="CP1"
          type="b-m-p-w" point="50.446574,-77.040572" remarks="" relation="c"/>
    <link_attr planningmethod="Infil" color="-1" method="Driving" prefix="CP"
               type="Vehicle" stroke="3" direction="Infil" routetype="Primary"
               order="Ascending Check Points"/>
    <strokeColor value="-1"/>
    <strokeWeight value="3.0"/>
    <contact callsign="ROUTE ALFA"/>
    <remarks></remarks>
    <archive/>
    <labels_on value="true"/>
  </detail>
</event>

ATAK rend la liste des link point comme géométrie de la route, promeut les entrées b-m-p-w en marqueurs de points de passage avec leurs propres indicatifs et lit link_attr pour le mode de déplacement (Driving|Walking|Flying|Swimming|Watercraft), le sens (Infil|Exfil) et le type de route (Primary|Secondary). Le point propre de l'événement est la sentinelle 0/0 — la géométrie vit entièrement dans le detail.

Les tracés suivent le même motif « géométrie dans le detail ». Un cercle est une ellipse à axes égaux dans un <shape> :

<event version="2.0" uid="6d09b6f6-720a-4eef-a197-183012512316"
       type="u-d-c-c" how="h-e"
       time="2026-10-07T07:35:12.000Z" start="2026-10-07T07:35:12.000Z"
       stale="2026-10-08T07:35:12.000Z">
  <point lat="50.437376" lon="30.572999" hae="9999999.0" ce="9999999.0" le="9999999.0"/>
  <detail>
    <shape>
      <ellipse major="300.0" minor="300.0" angle="360"/>
      <link uid="6d09b6f6-720a-4eef-a197-183012512316.Style"
            type="b-x-KmlStyle" relation="p-c">
        <Style>
          <LineStyle><color>ffffffff</color><width>4.0</width></LineStyle>
          <PolyStyle><color>96ffffff</color></PolyStyle>
        </Style>
      </link>
    </shape>
    <strokeColor value="-1"/>
    <strokeWeight value="4.0"/>
    <fillColor value="-1761607681"/>
    <contact callsign="PATROL AREA"/>
    <labels_on value="true"/>
  </detail>
</event>

Le point est le centre, major/minor sont en mètres, et le bloc façon KML imbriqué sous un lien de type b-x-KmlStyle porte le trait et le remplissage. Un rectangle abandonne l'élément shape et liste ses coins comme enfants <link point="lat,lon"/> de type u-d-r ; une ligne à main levée fait de même avec le type u-d-f, en refermant le polygone par la répétition du premier point à la fin. Une ligne distance-azimut est encore différente : type u-rb-a, le point est l'ancre, et le vecteur est numérique :

<event version="2.0" uid="58df2fcd-e33e-414f-a718-b18b50cd3137"
       type="u-rb-a" how="h-e"
       time="2026-10-07T07:44:03.000Z" start="2026-10-07T07:44:03.000Z"
       stale="2026-10-08T07:44:03.000Z">
  <point lat="50.420806" lon="30.554945" hae="9999999.0" ce="9999999.0" le="9999999.0"/>
  <detail>
    <range value="886.14"/>
    <bearing value="45.6"/>
    <inclination value="0.0"/>
    <rangeUnits value="1"/>
    <bearingUnits value="0"/>
    <northRef value="0"/>
    <strokeColor value="-65536"/>
    <strokeWeight value="3.0"/>
    <contact callsign="R&amp;B 1"/>
  </detail>
</event>

Les unités sont encodées en petits entiers : rangeUnits 0=km, 1=mètres, 2=miles, 3=yards, 4=pieds, 5=milles nautiques ; bearingUnits 0=degrés, 1=mils, 2=radians ; northRef 0=nord vrai, 1=magnétique, 2=quadrillage. ATAK recalcule à l'import la position de la pointe de flèche à partir de l'ancre et du vecteur.

Alertes d'urgence et demandes CASEVAC/MEDEVAC

Les balises d'urgence sont de petits événements pressants : type b-a-o-tbl pour une alerte 911 générale, stale à dix secondes seulement (la balise est rediffusée, pas laissée en suspens), et une convention d'UID <device-uid>-9-1-1 :

<event version="2.0" uid="ANDROID-9c2f71a4-9-1-1" type="b-a-o-tbl" how="h-g-i-g-o"
       time="2026-10-07T08:01:57.000Z" start="2026-10-07T08:01:57.000Z"
       stale="2026-10-07T08:02:07.000Z">
  <point lat="50.448620" lon="30.531104" hae="160.0" ce="8.0" le="12.0"/>
  <detail>
    <link uid="ANDROID-9c2f71a4" type="a-f-G-U-C" relation="p-p"/>
    <contact callsign="GRIF-2-Alert"/>
    <emergency type="911 Alert">GRIF-2</emergency>
  </detail>
</event>

Les chaînes emergency/@type et leurs types CoT, tels qu'ATAK les définit :

À réception, les clients recherchent le marqueur via link/@uid, lèvent l'alerte avec distance et azimut vers la position de la victime et maintiennent la balise en vie ; TAK Server la rediffuse périodiquement. Une annulation réutilise le même uid d'événement et bascule le detail :

<event version="2.0" uid="ANDROID-9c2f71a4-9-1-1" type="b-a-o-can" how="h-g-i-g-o"
       time="2026-10-07T08:07:22.000Z" start="2026-10-07T08:07:22.000Z"
       stale="2026-10-07T08:07:32.000Z">
  <point lat="50.448620" lon="30.531104" hae="160.0" ce="8.0" le="12.0"/>
  <detail>
    <emergency cancel="true">GRIF-2</emergency>
  </detail>
</event>

La demande MEDEVAC/CASEVAC 9-line est un marqueur de type b-r-f-h-c dont le detail porte un élément <_medevac_> (notez les tirets bas) contenant les neuf lignes en attributs. Un sous-ensemble sûr et largement compris :

<event version="2.0" uid="7b1e0c52-2f4d-4f18-9c6e-0d4a2b9f5c31"
       type="b-r-f-h-c" how="h-g-i-g-o"
       time="2026-10-07T08:10:40.000Z" start="2026-10-07T08:10:40.000Z"
       stale="2026-10-07T09:10:40.000Z">
  <point lat="50.448620" lon="30.531104" hae="160.0" ce="8.0" le="12.0"/>
  <detail>
    <contact callsign="GRIF-2"/>
    <_medevac_ casevac="false" title="GRIF-2 9LINE" freq="41.50"
              urgent="1" priority="0" routine="0"
              litter="1" ambulatory="0"
              security="2" hlz_marking="2"
              equipment_none="true">
      <zMistsMap>
        <zMist title="MIST 1" z="Z1" m="GSW"
               i="left thigh" s="HR 110, BP 100/60" t="tourniquet, TXA"/>
      </zMistsMap>
    </_medevac_>
    <remarks>Pickup at gravel yard, wind 310/8</remarks>
  </detail>
</event>

Décodage : les nombres de patients par priorité vivent dans urgent/priority/routine ; la ligne 5 dans litter/ambulatory ; security est un indice 0–3 (N pas d'ennemi, P possible, E ennemi dans la zone, X escorte requise) ; hlz_marking indexe A panneaux, B pyrotechnie, C fumée, D aucun, E autre ; l'équipement spécial apparaît en drapeaux booléens (hoist, extraction_equipment, ventilator) ; le rapport clinique MIST s'imbrique sous zMistsMap. ATAK rend à partir de cet élément la carte 9-line complète et les outils de zone d'atterrissage. Le flux opérationnel autour est traité dans le logiciel de coordination CASEVAC.

Champ de capteur et liens vidéo

Le sous-schéma capteur de MITRE attache un champ de vision orientable à n'importe quel marqueur. Au sein de l'événement de position de la plateforme elle-même — ici un drone allié à voilure tournante, type a-f-A-M-H-Q — ajoutez :

<event version="2.0" uid="UAV-ZP-07" type="a-f-A-M-H-Q" how="m-g"
       time="2026-10-07T08:22:05.000Z" start="2026-10-07T08:22:05.000Z"
       stale="2026-10-07T08:22:15.000Z">
  <point lat="50.437120" lon="30.552870" hae="820.0" ce="12.0" le="15.0"/>
  <detail>
    <contact callsign="ZP-07" endpoint="*:-1:stcp"/>
    <sensor azimuth="127.0" fov="30.0" vfov="22.0" range="2200.0"
           elevation="-18.0" model="EO/IR turret"/>
    <__video url="rtsp://192.168.4.60:8554/live.sdp"/>
  </detail>
</event>

azimuth est en degrés du nord vrai, elevation l'inclinaison (négatif vers le bas), fov/vfov les champs horizontal et vertical en degrés, range la distance oblique en mètres — ensemble, ils permettent à ATAK de dessiner le cône du capteur sur la carte. L'enfant <__video> lie le marqueur à une URL de flux, si bien qu'ouvrir le marqueur ouvre le flux. Les enregistrements de caméra autonomes voyagent comme événements propres de type b-i-v portant un <ConnectionEntry> avec address, port, protocol et attributs de syntoniseur associés, qui remplissent le gestionnaire vidéo de chaque client. Pour le pipeline au sens large — cadences de télémétrie, métadonnées KLV, pointage — voir l'intégration de télémétrie de drone avec TAK.

Supprimer des marqueurs et le ping/pong de maintien

CoT n'a pas de suppression intégrée ; TAK en superpose une comme événement de taskage de type t-x-d-d dont le <link> nomme la cible :

<event version="2.0" uid="6650d1ee-4b17-4d02-8c95-13a1f2e9b0aa"
       type="t-x-d-d" how="h-g-i-g-o"
       time="2026-10-07T08:31:19.000Z" start="2026-10-07T08:31:19.000Z"
       stale="2026-10-07T08:31:29.000Z">
  <point lat="0.0" lon="0.0" hae="9999999.0" ce="9999999.0" le="9999999.0"/>
  <detail>
    <link uid="E-20261007-0413" relation="p-p" type="a-h-G-E-V-A-T"/>
    <__forcedelete/>
  </detail>
</event>

Sans <__forcedelete/>, ATAK marque seulement l'élément référencé comme périmé localement et le retire selon les réglages de l'utilisateur ; avec lui, l'élément est supprimé d'office sur chaque client qui reçoit la tâche. L'importateur exige que link/@uid, @relation et @type soient présents et non vides, donc gardez les trois. Le keepalive est plus petit encore — les clients TAK pinguent un serveur resté silencieux une quinzaine de secondes, en répétant toutes les quelques secondes, et traitent le pong de type t-x-c-t-r comme un message de contrôle qui n'atteint jamais la carte :

<event version="2.0" uid="ANDROID-9c2f71a4-ping" type="t-x-c-t" how="m-g"
       time="2026-10-07T08:33:50.000Z" start="2026-10-07T08:33:50.000Z"
       stale="2026-10-07T08:34:00.000Z">
  <point lat="0.0" lon="0.0" hae="0.0" ce="9999999.0" le="9999999.0"/>
</event>

Si vous construisez une passerelle, reflétez ce comportement : un événement <uid>-ping à chaque intervalle auquel la connexion doit être vérifiée, et rejet silencieux des pongs.

Générer du CoT valide : horodatages, stale, UID, échappement

Les bogues récurrents des émetteurs CoT sont prévisibles, et tous sont bon marché à prévenir :

• UTC, toujours. Chaque horodatage se termine par Z ; des décalages locaux ou un Z manquant décalent les marqueurs de plusieurs heures dans le passé ou le futur. Les fractions de seconde sont optionnelles et toute précision est légale.
• Discipline de stale. Piste mobile : deux à quatre intervalles de rapport plus marge. Marqueurs statiques : des heures à des jours, avec <archive/> s'ils doivent persister. Ne laissez jamais stale sur sa valeur par défaut dans un futur lointain pour une piste en vie — les marqueurs fantômes sont la plainte numéro un du terrain.
• UID stables. Déduisez l'uid de l'entité (numéro de série, numéro de piste, empreinte du contenu), pas du message. Deux pistes réelles partageant un uid fusionnent en un marqueur clignotant.
• Erreurs honnêtes. Si vous ignorez l'altitude ou la précision, émettez 9999999.0, pas 0. Les moteurs de fusion lisent 0 comme une affirmation.
• Coordonnées. Degrés décimaux signés, WGS-84 ; six décimales suffisent amplement. Tronquer à quatre décimales (environ 10 m) est un choix de bande passante légitime que font certaines bibliothèques — mais faites-le de façon cohérente.
• Échappement XML. Échappez &, <, > dans les valeurs d'attribut et le texte — les indicatifs et remarques contiendront un jour une esperluette. Un seul < égaré dans un champ remarks tue tout le document dès l'analyseur.
• Validez une fois, faites confiance ensuite. Passez au peigne fin la sortie de votre émetteur contre le XSD d'événement CoT publié pendant le développement. Le XSD n'attrape pas les erreurs sémantiques (stale avant start, queues de type sans sens), donc ajoutez ces contrôles comme assertions dans l'encodeur.

Envoyer du CoT : multicast mesh contre TAK Server

Deux transports couvrent presque tout déploiement. Le mesh SA sans serveur multidiffuse chaque document XML comme un datagramme UDP unique vers l'adresse TAK standard 239.2.3.1:6969 (GeoChat a aussi utilisé historiquement 224.10.10.1:17012) ; chaque client du segment entend tout, et il n'y a pas de store-and-forward. Dans le modèle serveur, les clients se connectent au TAK Server en TCP — port 8087 en clair, 8089 TLS avec certificats clients — qui diffuse le XML dans les deux sens, distribue les événements avec filtrage par groupes et missions et peut réencoder le flux au format TAK protobuf compact négocié par connexion. Les détails d'encodage et de négociation, y compris quand protobuf casse les outils, sont traités dans le protocole TAK : CoT XML contre protobuf ; le routage au-delà des frontières de serveurs dans l'architecture TAK Federation Hub, et l'image de coalition dans le pont entre CoT et normes OTAN.

Une règle empirique tranche entre eux : si les récepteurs sont sur le même segment RF et que la perte est tolérable, le multicast est gratuit ; si quiconque est hors segment, sur un autre réseau ou a besoin de rejeu en mode déconnecté, il vous faut le serveur — comme à tout ce qui exige une piste d'audit.