Relier CoT et les normes NATO : TAK dans un tissu de données de coalition

Deux normes dominent la périphérie tactique, et elles ne se parlent pas nativement. D'un côté se trouve Cursor on Target (CoT) — le format d'événement XML compact qu'émet tout client TAK pour partager sa position, son identité et ses points d'intérêt. De l'autre côté se trouvent les normes de coalition NATO : la spécification MIP Information Exchange (MIP4-IES) construite sur le modèle de données JC3IEDM, et le profil ADatP-34 NATO Friendly Force Information (NFFI) utilisé pour le suivi des forces amies au sein d'une fédération. Lorsqu'une enclave TAK nationale doit se connecter à une image de coalition, quelque chose doit traduire entre ces deux univers. Cet article examine comment relier CoT aux normes NATO et intégrer un déploiement TAK dans un tissu de données de coalition sans perdre l'identité des pistes, la qualité de position ou les marquages de diffusion en chemin.

Pourquoi CoT et les normes NATO divergent

CoT et les normes C2 NATO ont été conçus pour des points de fonctionnement différents, et cette différence explique pourquoi une passerelle est nécessaire plutôt qu'une option de configuration. CoT est un événement XML plat et auto-descriptif : un seul élément <event> porte un identifiant unique, une chaîne de type, un point avec latitude/longitude/hauteur et estimations d'erreur, un ensemble de champs temporels, et un sous-arbre <detail> ouvert. Il a été optimisé pour les liaisons à faible bande passante et les appareils utilisateurs, ainsi que pour un modèle publish-subscribe où des milliers de petits événements s'écoulent en continu. Tout l'intérêt de CoT est que n'importe quel client peut l'analyser sans schéma relationnel partagé.

JC3IEDM — le modèle de données sous MIP4-IES — est la conception opposée. C'est un modèle relationnel normalisé avec des centaines de types d'objets, une intégrité référentielle stricte et une sémantique de rapport et de tasking explicite destinée à la fédération C2 interdomaines entre les systèmes de quartier général national. ADatP-34 NFFI se situe entre les deux : plus étroit que JC3IEDM, focalisé spécifiquement sur le rapport de position des forces amies, et utilisant un format de message XML plus directement mappable depuis CoT. Forcer un client TAK à émettre du JC3IEDM directement alourdirait le format filaire et l'appareil au-delà de ce que la périphérie tactique peut supporter. L'architecture pragmatique conserve CoT en périphérie et traduit au niveau d'une passerelle.

Le problème de mappage : CoT vers NFFI et MIP

Le cœur de la passerelle est un mappage champ par champ entre le modèle d'événement CoT et le schéma NATO cible. Chaque événement CoT possède un petit ensemble bien défini de champs qui doivent être transportés sans perte de sens.

Identité. CoT identifie une entité par son uid — une chaîne opaque assignée par la source. NFFI et JC3IEDM attendent tous deux un identifiant stable de piste ou d'élément d'objet scoped à l'unité de rapport. La passerelle ne peut pas simplement transmettre l'uid CoT ; elle doit maintenir une carte d'identité associant chaque uid CoT à un identifiant déterministe côté tissu, afin que la même entité physique conserve une identité unique à travers la passerelle et entre les reconnexions.

Type et symbologie. L'attribut CoT type encode une hiérarchie dérivée de MIL-STD-2525 (par exemple, a-f-G-U-C pour une unité de combat terrestre amie). NFFI porte un champ de code symbole qui s'aligne étroitement avec le 2525, donc le mappage est largement mécanique. JC3IEDM est plus difficile : le type 2525 doit être résolu en une catégorie d'objet plus le sous-type pertinent et une affiliation, ce qui constitue une recherche un-à-plusieurs plutôt qu'une copie directe.

Géométrie et qualité. Le <point> CoT porte la latitude, la longitude, la hauteur au-dessus de l'ellipsoïde (hae), l'erreur circulaire (ce) et l'erreur linéaire (le). Les consommateurs NATO veulent une qualité de position quantifiée, de sorte que les valeurs ce/le doivent être traduites dans les champs de précision du format cible plutôt qu'ignorées — une piste qui arrive sans estimation d'erreur est traitée comme peu fiable par un moteur de fusion.

Temps et obsolescence. Les événements CoT portent les horodatages time, start et stale. Le champ stale est le plus sémantiquement chargé : il indique aux consommateurs quand supprimer la piste. NFFI et JC3IEDM expriment la validité différemment, donc la passerelle doit traduire l'obsolescence CoT en temps de rapport du format cible plus une fenêtre de validité ou d'expiration, et elle doit re-tamponner à chaque mise à jour.

Le sous-arbre detail

L'élément CoT <detail> ouvert est l'endroit où vivent le callsign, la couleur d'équipe, le rôle, les remarques et les extensions spécifiques aux capteurs. Mapper le detail est la partie de la passerelle qui n'est jamais entièrement complète, parce que le detail CoT est extensible par conception et que différents plugins TAK émettent des sous-éléments différents. Une passerelle de production mappe les enfants detail bien connus (<contact> callsign, <__group> équipe et rôle, <remarks>) vers leurs équivalents NFFI ou JC3IEDM et transporte le detail non mappé comme annotation opaque plutôt que de le supprimer, afin qu'un aller-retour vers TAK ne perde pas silencieusement le contexte saisi par l'opérateur.

Architecture de la passerelle dans le tissu de données

Un tissu de données de coalition est la couche logique qui permet aux données de nombreux systèmes nationaux et fonctionnels d'être découvertes, accessibles et fusionnées au sein d'une fédération sans construire une intégration point à point pour chaque paire de systèmes. La passerelle CoT vers NATO est l'un des nœuds de ce tissu, se situant précisément à la frontière entre une enclave TAK nationale et les interfaces de coalition.

La passerelle possède trois chemins de données concurrents. Le chemin d'ingestion s'abonne au TAK Server, analyse les CoT en un modèle interne canonique, et normalise les coordonnées et les estimations d'erreur. Le chemin de traduction et publication mappe le modèle canonique vers le schéma NATO cible et le publie sur le tissu — sous forme de flux de service NFFI, d'échange MIP ou de message vers le courtier publish-subscribe du tissu. Le chemin inverse consomme les pistes de coalition du tissu, les traduit en CoT et les injecte dans l'enclave TAK afin que l'affichage TAK de l'opérateur montre l'image complète de la coalition, pas seulement les pistes d'origine nationale.

Parce que la passerelle est bidirectionnelle, la prévention des boucles n'est pas optionnelle. Une piste qui quitte l'enclave TAK sous forme de CoT, est traduite et publiée, puis revient via le chemin inverse ne doit pas être réinjectée comme un second contact doublon. La technique standard est un espace de nommage uid déterministe par source combiné à un marqueur de provenance dans l'arbre detail de CoT, vérifié à l'ingestion : si la passerelle voit une piste qu'elle a originée, elle supprime la re-traduction.

Identité, provenance et marquage de diffusion

Le partage de données de coalition est régi autant par la politique que par le protocole, et la passerelle est le point d'application des deux. Chaque piste que la passerelle publie sur le tissu doit porter un marquage de diffusion et les caveats de besoin d'en connaître qui déterminent quels partenaires de coalition peuvent la voir. CoT lui-même n'a pas de champ de classification standardisé, donc le marquage est appliqué au niveau de la passerelle selon la politique de diffusion de l'enclave — typiquement déterminée par le groupe source, le type de piste ou un marquage explicite de l'opérateur dans l'arbre detail.

La provenance voyage avec le marquage. Une image de coalition fusionnée n'est fiable que si chaque piste peut être tracée jusqu'à son système d'origine, parce qu'une piste d'origine inconnue ne peut pas être pondérée correctement lors de la fusion ni corrélée avec d'autres sources. La passerelle estampille chaque piste sortante avec l'identité de l'enclave d'origine et l'horodatage de traduction, et préserve cette provenance sur le chemin inverse afin qu'un opérateur TAK puisse voir qu'un contact provient d'un partenaire de coalition plutôt que d'un capteur national. L'ensemble plus large des obstacles politiques et techniques — caveats, transfert interdomaines et confiance — est traité dans notre analyse des défis du partage de données de coalition.

Conformité : tester la passerelle par rapport aux normes

Une passerelle CoT vers NATO n'est utile que si sa sortie est conforme, et la conformité doit être testée par rapport aux spécifications NATO réelles plutôt que par rapport à une interprétation commode de celles-ci. Pour NFFI, la sortie de la passerelle est validée par rapport au schéma ADatP-34 et exercée sur un consommateur NFFI de référence pour confirmer que les codes symboles, les identités et les fenêtres de validité sont interprétés comme prévu. Pour MIP, la conformité est plus lourde : le mappage JC3IEDM doit satisfaire l'intégrité référentielle et la sémantique de rapport MIP4-IES, c'est pourquoi l'intégration MIP est généralement validée dans un exercice structuré plutôt que sur banc de test.

La table de mappage elle-même doit être versionnée et auditable. Les codes de type CoT évoluent, NFFI et JC3IEDM sont révisés, et un changement non documenté dans un seul mappage de type peut silencieusement reclasser un contact hostile comme inconnu sur l'ensemble d'une coalition. Traiter le mappage comme un artefact révisé et versionné — et non comme des constantes enfouies dans le traducteur — est ce qui rend la passerelle maintenable à travers les révisions de normes. Pour le panorama plus large des normes auxquelles la passerelle doit se conformer, voir notre aperçu de MIP4-IES et la norme des forces terrestres NATO.

Débit, limitation et le décalage de cadence

CoT et les normes NATO ne diffèrent pas seulement en structure — elles diffèrent en tempo, et une passerelle qui ignore ce décalage va soit inonder le tissu de coalition, soit le priver de données. Une enclave TAK active peut produire un flux haute fréquence de mises à jour CoT : un véhicule en mouvement avec un flux GPS peut émettre un événement de position chaque seconde, et une centaine de telles pistes génèrent un torrent continu de petits événements. Les systèmes C2 basés sur JC3IEDM, en revanche, s'attendent à des rapports à une cadence mesurée en dizaines de secondes, parce que chaque mise à jour implique une transaction relationnelle avec des vérifications d'intégrité référentielle plutôt qu'une diffusion en mode fire-and-forget.

La passerelle doit donc être un gestionnaire de débit actif, pas un traducteur passif. Le modèle standard est la décimation par piste : la passerelle conserve le dernier état CoT pour chaque uid et publie sur le tissu à une cadence fixe — ou lorsqu'une piste se déplace de plus d'une distance seuil, selon ce qui se produit en premier — plutôt que de relayer chaque événement entrant. Cela préserve les mises à jour opérationnellement significatives (une piste qui bouge réellement) tout en condensant les rapports stationnaires redondants à haute fréquence qui submergeraient sinon un consommateur MIP. La politique de décimation appartient à la configuration, parce que la cadence adéquate dépend de la liaison et du système consommateur, pas d'une valeur codée en dur dans le traducteur.

Le chemin inverse nécessite la discipline inverse. Les pistes de coalition arrivant du tissu sont généralement à cadence plus lente, donc les injecter dans TAK telles quelles peut les faire apparaître comme sautant entre des positions très espacées. Le lissage par extrapolation à l'estime entre les mises à jour du tissu — en utilisant la vitesse rapportée pour interpoler la position — donne à l'opérateur TAK un affichage fluide plutôt qu'une piste qui se téléporte à chaque intervalle de rapport. L'extrapolation doit être bornée et clairement dégradée après une mise à jour manquée, afin qu'une piste de coalition périmée ne soit jamais présentée comme une position actuelle fiable.

La résilience compte autant que le débit. La liaison entre une enclave nationale et le tissu de coalition est rarement aussi fiable qu'un réseau local câblé, donc la passerelle doit mettre en tampon les pistes sortantes lors de courtes déconnexions et réconcilier l'identité à la reconnexion — en republiant l'état actuel de chaque piste active plutôt qu'en rejouant l'intégralité de l'arriéré d'événements intermédiaires. Côté TAK, la passerelle doit marquer rapidement comme périmées les pistes d'origine coalition lorsque le lien avec le tissu tombe, afin qu'un opérateur ne soit jamais induit en erreur en faisant confiance à une image de coalition qui n'est plus mise à jour.

Le bénéfice d'une passerelle correctement construite est opérationnel, pas théorique : un soldat portant un appareil utilisateur voit la même image de coalition qu'un quartier général national exploitant un système C2 basé sur JC3IEDM, et un contact rapporté par le capteur d'une nation apparaît — correctement typé, correctement marqué et traçable — sur l'affichage de chaque partenaire. C'est ce qu'un tissu de données de coalition est censé délivrer, et la passerelle CoT vers NATO est le composant qui fait de la périphérie tactique un participant de premier plan en son sein.