Paquets de données et paquets de mission TAK : structure et distribution

L'écosystème TAK véhicule une grande quantité de contenu qui n'est pas une piste Cursor on Target : surimpressions, imagerie, géo-clôtures, plans d'itinéraire, mises à jour de plugins et lots de certificats. Le mécanisme qui transporte tout cela est le paquet de données — un simple fichier zip accompagné d'un manifeste. Comprendre le format de paquet, c'est la différence entre une flotte qui partage proprement une image opérationnelle commune et une autre qui se noie sous des surimpressions périmées et des couches cartographiques discordantes. Voici une présentation technique de la structure des paquets de données et des paquets de mission, de la manière dont TAK Server les synchronise et de la façon de les générer dans un pipeline.

1. ce qu'est un paquet de données

Un paquet de données TAK est une archive zip contenant un unique fichier obligatoire — MANIFEST.xml — et un ensemble arbitraire de fichiers de charge utile référencés par ce manifeste. C'est là toute la définition. Le zip est le conteneur de transport ; le manifeste est l'index qui indique à ATAK, WinTAK ou iTAK ce qui se trouve à l'intérieur et comment traiter chaque élément à la réception. Comme le format se réduit à un zip plus un descripteur XML, un paquet de données est l'unité universelle d'échange de contenu dans toute la famille TAK : tout ce qu'un client peut afficher ou installer peut y être encapsulé.

Lorsqu'un client importe un paquet, il le décompresse dans le répertoire de travail de l'application, analyse le manifeste et achemine chaque entrée de contenu vers le sous-système qui en a la charge. Un KML va au gestionnaire de surimpressions, un CoT XML est placé sur la carte sous forme d'éléments cartographiques, un fichier d'imagerie va au magasin de données, un APK va à l'installateur de plugins. Le paquet lui-même est éphémère — une fois importé, le client conserve les artefacts extraits, pas le zip. Cette seule décision de conception (l'aiguillage piloté par le manifeste) est ce qui permet à un même conteneur de transporter un lot hétérogène et de faire atterrir chaque pièce au bon endroit.

2. le MANIFEST.xml

Le manifeste est un petit document XML comportant deux sections de premier niveau sous l'élément racine <MissionPackageManifest>. La première est <Configuration>, une liste d'éléments <Parameter> qui décrivent le paquet dans son ensemble. Les deux qui apparaissent toujours sont uid (un identifiant unique, conventionnellement un UUID, que le client utilise pour dédupliquer et remplacer les imports antérieurs) et name (l'étiquette lisible affichée dans l'importateur de paquets). Un troisième paramètre courant est onReceiveDelete — un booléen qui, lorsqu'il vaut true, indique au client récepteur de supprimer automatiquement le contenu du paquet lorsque le paquet est retiré, plutôt que de laisser ses artefacts derrière lui.

La seconde section est <Contents>, une liste d'entrées <Content>. Chaque entrée possède un attribut zipEntry donnant le chemin du fichier de charge utile à l'intérieur du zip, et un attribut ignore qui détermine si le client traite le fichier comme un contenu importé ou simplement comme une ressource de support. Les entrées de contenu peuvent également porter des paramètres imbriqués — par exemple, un fichier CoT peut déclarer son propre uid afin que le client le rattache à un élément cartographique précis. Un manifeste minimal ressemble à ceci :

<MissionPackageManifest version="2"><Configuration><Parameter name="uid" value="b3f1…"/><Parameter name="name" value="OP GRANITE overlay"/><Parameter name="onReceiveDelete" value="true"/></Configuration><Contents><Content ignore="false" zipEntry="overlay.kml"/><Content ignore="false" zipEntry="aoi.cot"/></Contents></MissionPackageManifest>

L'attribut version="2" a son importance : il sélectionne le schéma de manifeste que le client utilise pour l'analyse, et se tromper à ce sujet est la cause la plus fréquente pour qu'un paquet construit à la main échoue silencieusement à l'import.

3. paquets de données vs paquets de mission

Les termes sont employés de façon souple, mais la distinction est réelle et architecturale. Un paquet de données est l'artefact générique zip-plus-manifeste — un lot ad hoc que l'on remet à un autre opérateur. Un paquet de mission est ce même artefact lorsqu'il est rattaché à une mission persistante, hébergée sur le serveur, sur TAK Server. Le format du conteneur est identique ; ce qui diffère, c'est le cycle de vie et la propriété.

Un paquet de données ad hoc fonctionne en mode « tire et oublie » : vous le construisez, vous l'envoyez, le destinataire l'importe, et il n'existe plus aucune relation entre la copie de l'expéditeur et celle du destinataire. Un paquet de mission vit à l'intérieur d'une mission — une collection nommée, à accès contrôlé, sur le serveur, à laquelle les clients s'abonnent. Lorsque la mission change, chaque abonné est notifié et récupère le delta. Utilisez un paquet de données ad hoc lorsque vous avez besoin d'un transfert ponctuel entre deux ou trois opérateurs sur le terrain. Utilisez une mission lorsque vous avez besoin d'une image partagée, à l'échelle de l'unité, continuellement mise à jour, que les nouveaux arrivants peuvent récupérer intégralement et qui survit à une réinstallation du client.

4. le contenu des paquets

Un paquet peut transporter pratiquement tout artefact que les clients TAK savent interpréter. Les charges utiles courantes :

Événements CoT. Du XML Cursor on Target statique — points, zones, itinéraires — qui se matérialisent en éléments cartographiques à l'import. C'est ainsi que l'on diffuse un ensemble préétabli de mesures de coordination ou un dispositif fixe de positions amies.

Surimpressions KML/KMZ. Des surimpressions vectorielles pour les limites, les lignes de phase, les zones d'interdiction de tir et les corridors. Le KMZ embarque sa propre imagerie référencée et son style, il voyage donc bien à l'intérieur d'un paquet.

Imagerie et fonds de carte. Des jeux de tuiles GeoTIFF, MBTiles et GeoPackage pour une couverture cartographique hors ligne d'une zone d'opérations — fréquemment l'élément le plus volumineux d'un paquet, et de loin, et la raison pour laquelle la discipline sur la taille des paquets compte.

Géo-clôtures. Un événement CoT doté d'attributs de géo-clôture que le client arme comme une limite d'alerte — les notifications de franchissement et d'entrée se déclenchent localement sur l'appareil. Un paquet de géo-clôture est un moyen standard de diffuser des zones d'alerte permanentes à une escouade.

Certificats. Des lots d'enrôlement client et de magasin de confiance, utilisés pour intégrer un appareil à un TAK Server avec la bonne chaîne d'AC et le bon certificat client en un seul import.

APK de plugins. Des binaires de plugins ATAK, diffusés afin qu'un opérateur puisse installer ou mettre à jour une capacité sans passer par une boutique d'applications. La construction de ces plugins est une discipline à part entière — voir notre note sur l'ingénierie des plugins ATAK/WinTAK — mais leur distribution n'est qu'une entrée de contenu de plus dans un manifeste.

5. la synchronisation des données TAK Server

Côté serveur, la machinerie qui sous-tend les missions est le magasin Enterprise Sync — un magasin d'objets adressé par contenu, indexé par le hachage du fichier. Chaque artefact téléversé vers le serveur est stocké une seule fois sous son hachage ; les missions référencent alors ces hachages plutôt que de détenir des copies. Une mission, ce sont des métadonnées plus une liste de références de contenu et un flux de changements.

Les clients interagissent via un petit ensemble d'API de mission. Un client s'abonne à une mission, puis reçoit les événements du flux de changements — contenu ajouté, contenu retiré, détail de mission mis à jour — sous forme de messages CoT par sa connexion serveur existante. Lorsqu'un changement pertinent arrive, le client récupère le nouveau contenu depuis Enterprise Sync par hachage. Comme le magasin est adressé par contenu, un fichier déjà présent sur l'appareil n'est jamais re-téléchargé : la correspondance de hachage court-circuite le transfert. C'est ce qui permet à une mission de passer à l'échelle d'une unité entière — seuls les deltas circulent, et les artefacts identiques sont dédupliqués de bout en bout.

6. les voies de distribution

Il existe trois moyens pratiques pour que le contenu atteigne un appareil. Le premier est le transfert entre pairs — la voie QuickPic / « envoyer à un contact », où un client compresse un paquet et le pousse directement vers un autre client par le maillage TAK ou via le serveur en relais. C'est la voie de circonstance sur le terrain : pas de mission, pas d'abonnement, juste un opérateur qui remet un lot à l'opérateur voisin.

Le deuxième est le téléversement et téléchargement serveur. Un opérateur ou un système externe téléverse un paquet vers TAK Server ; d'autres clients le téléchargent à la demande depuis la liste des paquets de données. Cela découple le producteur du consommateur dans le temps — le paquet attend sur le serveur jusqu'à ce que quelqu'un le récupère.

Le troisième est l'import automatique de mission. Un abonné à une mission reçoit automatiquement les nouveaux paquets de mission : le flux de changements notifie le client, le client récupère le contenu, et celui-ci apparaît sur la carte sans action de l'opérateur. Pour une unité exploitant une mission partagée, c'est la voie qui maintient tout le monde à jour sans que personne n'envoie manuellement de fichiers. Les serveurs fédérés étendent encore ce principe — voir la fédération TAK Server pour comprendre comment les missions et leur contenu se propagent au travers d'une frontière de fédération.

7. versionnage et intégrité

Le hachage qui sous-tend Enterprise Sync est aussi la garantie d'intégrité : le contenu d'un paquet est identifié par son hachage, de sorte qu'un fichier corrompu ou altéré ne correspondra tout simplement pas à la référence et ne sera pas accepté. Côté client, le uid du paquet est le levier de versionnage. Réimportez un paquet avec le même uid et le client remplace l'import antérieur plutôt que d'empiler un doublon — c'est ainsi que l'on diffuse une surimpression mise à jour sans laisser l'ancienne derrière soi.

Ce comportement de remplacement n'est fiable que si vous l'utilisez délibérément. La défaillance classique sur le terrain est la prolifération de surimpressions périmées : chaque révision d'un plan est diffusée avec un nouveau uid, si bien que l'appareil accumule douze surimpressions de limites légèrement différentes et l'opérateur ne sait plus laquelle est la plus à jour. Les disciplines qui l'évitent sont simples — conservez un uid stable par artefact logique à travers les révisions, fixez onReceiveDelete="true" pour que le retrait d'un paquet nettoie son contenu, et traitez l'espace de noms uid du manifeste comme un actif géré, pas comme un UUID aléatoire généré à chaque export.

8. construire des paquets de manière programmatique

Générer des paquets à la main dans le client convient à un seul opérateur ; cela ne passe pas à l'échelle d'un pipeline qui doit pousser des produits de planification vers une centaine d'appareils selon un calendrier. La bonne nouvelle, c'est que le format est trivialement automatisable. Construire un paquet de manière programmatique se fait en trois étapes : assembler les fichiers de charge utile, écrire un MANIFEST.xml avec la bonne version, un uid stable et une entrée <Content> par charge utile, puis les compresser avec le manifeste au chemin attendu par le client (conventionnellement sous un répertoire MANIFEST/).

Pour l'automatisation côté serveur, les API de mission et d'Enterprise Sync permettent à un pipeline de téléverser du contenu par hachage, de créer ou mettre à jour une mission et d'y rattacher du contenu — le tout sans intervention humaine. Un système de planification peut générer une surimpression, l'empaqueter, la téléverser dans une mission, et chaque appareil abonné se met à jour en quelques secondes. Le schéma qui fonctionne consiste à traiter la génération de paquets comme une étape de build : des manifestes déterministes, des UID stables associés au produit logique, et un téléversement adressé par contenu pour que les ré-exécutions produisant des octets identiques soient des no-op sur le réseau.

La leçon architecturale reflète ce que nous disons de toute intégration TAK : gardez le générateur de paquets hors de votre modèle de domaine central. Votre système de planification doit posséder les plans ; un adaptateur fin doit traduire un plan en un manifeste et un zip. Lorsque la révision du schéma de manifeste change ou qu'un nouveau type de contenu est ajouté, vous mettez à jour l'adaptateur, pas le planificateur — et le reste de la chaîne de distribution, d'Enterprise Sync jusqu'à l'appareil, n'a jamais besoin d'en avoir connaissance.