Logiciels de reconnaissance UAV : du capteur à la décision de l'opérateur

Un UAV embarque des capteurs. Un capteur produit des données. Les données deviennent des informations lorsqu'elles sont fusionnées avec du contexte et placées devant un opérateur capable d'agir. La distance entre ces deux extrémités — la capture par le capteur et la décision de l'opérateur — est la boucle capteur-décision, et les logiciels de reconnaissance UAV sont ce qui en gouverne la latence, la fidélité et la fiabilité. Cet article examine l'ensemble du pipeline : depuis la configuration du capteur embarqué en passant par la liaison descendante, la station sol, le pipeline d'analyse vidéo, jusqu'à l'image opérationnelle commune affichée aux officiers S2 et S6 sur le terrain.

La boucle capteur-décision : vue d'ensemble de l'architecture

La boucle comporte cinq étapes discrètes, chacune introduisant de la latence et représentant un point de défaillance potentiel :

1. Capteur embarqué et encodage. Les charges utiles électro-optiques (EO), infrarouges (IR), radar à synthèse d'ouverture (SAR) et SIGINT produisent des données brutes qui doivent être compressées et multiplexées pour la transmission. Pour les charges utiles vidéo, l'encodage H.264 ou H.265 s'effectue sur la carte encodeur vidéo de l'UAV. Les métadonnées KLV MISB (Motion Imagery Standards Board) — position de la plateforme, attitude, champ de vue du capteur — sont intégrées dans le flux de transport à cette étape. La latence d'encodage sur du matériel performant est typiquement de 30 à 80 ms.

2. Liaison de données. Le flux de transport encodé est transmis par voie hertzienne via la liaison C2 (liaison montante de commandement et contrôle) et une liaison descendante de renseignement à plus grande largeur de bande. Les types de liaison descendante courants comprennent le Tactical Common Data Link (TCDL) en bande C ou Ku pour les plateformes MALE et HALE, et les liaisons point à point 2,4 GHz ou 5,8 GHz pour les UAS tactiques. La latence de liaison pour un système en visibilité directe bien conçu est de 10 à 50 ms ; le relais satellitaire ajoute 500 à 600 ms dans un sens (géostationnaire) ou 20 à 80 ms (orbite basse terrestre), ce qui modifie considérablement le budget de latence pour l'engagement de cibles sensibles au temps.

3. Réception et décodage en station sol. Le terminal de données sol (GDT) reçoit le signal RF et produit un flux de transport MPEG-2 STANAG 4609 sur Ethernet ou interface série. Le logiciel de la station sol décode le flux, démultiplexe les métadonnées KLV du flux élémentaire vidéo et transmet les deux aux consommateurs en aval. Une pile de réception bien implémentée ajoute moins de 100 ms de latence de traitement à cette étape.

4. Analyse et géolocalisation. Les trames décodées sont transmises au pipeline d'analyse vidéo — détection, classification et pistage — tandis que les métadonnées KLV extraites simultanément alimentent le moteur de géolocalisation. La sortie de cette étape est un ensemble de détections géolocalisées et classifiées publiées comme événements sur le réseau tactique. La latence d'analyse dépend de la complexité du modèle et du matériel ; un modèle de taille YOLOv8 sur un poste de travail équipé d'un GPU traite des trames 1080p plus vite que le temps réel, à moins de 20 ms par trame. Sur du matériel de périphérie sans GPU, le même modèle peut nécessiter 80 à 150 ms par trame.

5. Affichage opérateur et décision. L'opérateur visionne le flux vidéo, la superposition d'empreinte du capteur sur la carte et les marqueurs de détection analytique dans l'image opérationnelle commune. La latence de décision — le temps entre l'affichage et un commandement ou un rapport — est un facteur humain que nul logiciel ne peut pleinement maîtriser, mais réduire la latence d'affichage et améliorer la densité d'information diminue directement la charge cognitive et raccourcit le cycle de décision.

STANAG 4609 et MISB KLV : le contrat de données

Le STANAG 4609 est le contrat de données fondamental pour les images de mouvement UAV dans les cadres d'interopérabilité des alliances. Il spécifie que la vidéo UAV doit être transportée sous forme de flux de transport MPEG-2 avec des métadonnées MISB Local Set (LS) 0601 intégrées. Le LS 0601 définit environ 140 éléments de données balisés couvrant chaque paramètre dont un analyste ou un système automatisé a besoin pour géolocaliser du contenu dans l'image : position du capteur, cap de la plateforme, tangage, roulis, angles de champ de vue, portée oblique, angle d'obliquité, et bien d'autres.

L'encodage KLV (Key-Length-Value) utilisé par MISB est un format binaire compact. Chaque élément de métadonnée est identifié par une clé de 1 ou 2 octets, suivie d'un champ de longueur, puis de la valeur dans un encodage standardisé en virgule flottante ou entier. Un paquet KLV minimal conforme pour une trame vidéo peut faire 80 à 120 octets. À 30 images par seconde, cela ajoute environ 3 à 4 kbps de surcharge au flux de transport — négligeable sur n'importe quelle liaison de données tactique.

Pour les intégrateurs, le point d'implémentation critique est que les métadonnées KLV doivent être extraites en synchronie avec les trames vidéo qu'elles décrivent. Les paquets KLV sont intégrés dans le flux de transport comme des PID de données privées aux côtés du PID vidéo. Un analyseur qui traite les deux PID de manière asynchrone — ou qui retarde l'affichage vidéo sans retarder l'application des métadonnées — produira des erreurs de géolocalisation qui augmentent avec la vitesse de la plateforme et le taux de déplacement du cardan. À 60 nœuds de vitesse sol et 1 seconde de décalage de métadonnées, l'erreur de géolocalisation peut dépasser 30 mètres.

Champs LS 0601 obligatoires pour la géolocalisation

Les 140+ champs LS 0601 ne sont pas tous requis pour la géolocalisation de base. L'ensemble minimal nécessaire pour calculer où un pixel de l'image se situe sur le sol comprend : latitude du capteur (balise 13), longitude du capteur (balise 14), altitude vraie du capteur (balise 15), cap vrai de la plateforme (balise 5), angle de tangage de la plateforme (balise 6), angle de roulis de la plateforme (balise 7), champ de vue horizontal du capteur (balise 16), champ de vue vertical du capteur (balise 17), azimut relatif du capteur (balise 18), angle d'élévation relatif du capteur (balise 19), roulis relatif du capteur (balise 20) et portée oblique (balise 21). Tous les autres champs sont complémentaires — utiles pour l'analyse mais non requis pour le calcul de géolocalisation en temps réel.

Pipeline d'analyse vidéo : détection et classification

La détection automatique d'objets est l'étape la plus dépendante de l'ingénierie spécifique au domaine. Les modèles de détection à usage général entraînés sur des images civiles sont peu performants sur les images militaires prises en perspective UAV — l'angle de vue, l'échelle, le camouflage et la diversité des cibles sont tous différents. Un modèle utilisé en production doit être affiné sur un ensemble de données étiquetées représentatif de l'environnement opérationnel : types de cibles (véhicules, personnel, emplacements), plage d'altitude, type de capteur (EO vs. IR) et classes d'arrière-plan (urbain, rural, boisé, mixte).

L'architecture standard pour l'analyse vidéo UAV en temps réel utilise un pipeline en deux étapes : un détecteur rapide à un seul passage (YOLOv8 ou équivalent) fonctionnant à la fréquence d'images complète pour la détection et la classification grossière, alimentant les détections vers un modèle de classification plus lent mais plus précis qui confirme la classe et attribue la confiance. Le détecteur rapide privilégie le rappel — capturer toutes les cibles potentielles même au prix de faux positifs. Le classificateur filtre la liste de détection et attribue l'étiquette finale. Cette séparation permet au système de fonctionner à la fréquence d'images vidéo tout en appliquant plus de calcul aux détections confirmées.

Géolocalisation des détections

Chaque boîte englobante de détection doit être convertie en coordonnée WGS84 sur le plan sol avant de pouvoir être publiée comme événement géospatial. Le calcul utilise les coordonnées pixel du centroïde de la détection, la géométrie du capteur issue des métadonnées KLV et un modèle d'élévation du terrain (DTED Niveau 1 ou Niveau 2). L'approche standard consiste à projeter un rayon depuis le capteur à travers le pixel du plan image et à l'intersecter avec la surface du terrain. Sans MNT, une approximation de terre plate utilisant la portée oblique introduit des erreurs dépendant de l'élévation qui deviennent significatives en terrain accidenté ou montagneux.

Pour le pistage des détections — relier les détections entre les trames pour produire des pistes persistantes — un filtre de Kalman ou l'algorithme SORT (Simple Online and Realtime Tracking) est la norme en production. Les pistes persistantes réduisent la charge cognitive de l'opérateur par rapport aux détections par trame : au lieu d'une carte qui clignote avec de nouveaux marqueurs à chaque trame, l'opérateur voit un petit nombre de marqueurs stables et mobiles avec un historique de confiance.

Intégration en station sol et architecture de la liaison C2

La station sol est le nœud central de la boucle capteur-décision. Une station sol de production pour un programme d'UAS tactique fait généralement tourner plusieurs composants logiciels en parallèle : le récepteur de flux de transport et le démultiplexeur, l'application d'affichage vidéo (avec enregistrement de mission), l'extracteur de métadonnées KLV, le pipeline d'analyse et l'éditeur CoT/réseau tactique.

La liaison montante C2 — les commandes de l'opérateur vers l'UAV — et la liaison descendante de renseignement sont logiquement séparées mais partagent souvent le même système RF. L'intégrité de la liaison C2 est plus difficile à protéger que la liaison descendante : les messages de commande sont petits mais doivent arriver avec une latence très faible et une haute fiabilité. L'architecture standard pour l'intégrité de la liaison C2 utilise une liaison montante à bande étroite dédiée à une fréquence séparée de la liaison descendante de renseignement à large bande, avec chiffrement AES-256 et FHSS (étalement de spectre par saut de fréquence) pour la résilience au brouillage. Le logiciel de la station sol doit surveiller les métriques de qualité de la liaison C2 — taux d'erreur binaire, latence d'accusé de réception de commande aller-retour — et alerter l'opérateur avant que la dégradation de la liaison ne provoque une perte de contrôle de l'appareil.

Patron de plugin ATAK pour les flux UAV

L'intégration d'un flux UAV dans ATAK — l'application standard de conscience situationnelle tactique — suit une architecture de plugin bien établie. Un plugin d'intégration UAV comporte trois composants fonctionnels qui opèrent de manière concurrente.

Composant panneau vidéo. Un panneau adossé à un SurfaceView à l'intérieur de la fenêtre du plugin ATAK rend le flux vidéo décodé. Le décodeur vidéo fonctionne dans un fil d'exécution en arrière-plan, poussant les trames vers la surface à la fréquence native du flux. Le panneau doit inclure des annotations de superposition (boîtes de cibles issues du pipeline d'analyse) rendues via Canvas sur une couche transparente au-dessus de la surface vidéo, synchronisées avec la trame affichée.

Composant superposition d'empreinte. Les quatre coordonnées de coin de l'empreinte du capteur — calculées à partir des champs de géométrie MISB et du modèle de terrain — sont publiées comme événement polygone CoT et rendues sur la carte ATAK comme un trapèze semi-transparent. Le polygone d'empreinte se met à jour au taux des métadonnées KLV (généralement 1 à 10 Hz pour la plupart des systèmes). À des taux de mise à jour plus lents, l'empreinte peut sembler en retard sur l'affichage vidéo lors de déplacements rapides du cardan ; le correctif consiste à extrapoler la position de l'empreinte en utilisant le taux de changement d'attitude de la plateforme entre les mises à jour de métadonnées.

Composant éditeur de détections. Les détections géolocalisées issues du pipeline d'analyse sont publiées comme événements point CoT sur TAK Server avec les codes de type CoT appropriés. Les pistes de détection avec une identité persistante sont publiées avec un UID cohérent entre les mises à jour, de sorte que les clients ATAK les affichent comme des marqueurs mobiles plutôt qu'une séquence d'événements indépendants. Le plugin doit permettre à l'opérateur de confirmer ou de rejeter une détection — les détections confirmées sont promues vers un type CoT de plus haute confiance ; les détections rejetées sont retirées de l'image.

Budgets de latence pour les cibles sensibles au temps

L'engagement de cibles sensibles au temps — le processus de détection, d'identification et d'engagement d'une cible qui se présente sur une courte fenêtre temporelle — impose les exigences de latence les plus strictes à la pile de logiciels de reconnaissance UAV. La doctrine militaire applicable spécifie un cycle d'engagement inférieur à 30 minutes pour le ciblage délibéré ; l'engagement sensible au temps compresse cela à des minutes ou des secondes selon le type de menace.

Au sein du pipeline logiciel, les allocations de budget de latence les plus importantes sont :

Latence d'affichage vidéo : inférieure à 500 ms au total, de la capture du capteur à l'affichage opérateur. Cela signifie encodage (80 ms) + liaison (50 ms, ligne de mire) + décodage (30 ms) + pipeline d'affichage (20 ms) = environ 180 ms pour un système bien optimisé. La mise en mémoire tampon pour le streaming à débit adaptatif ou la compensation de la gigue ajoute souvent 200 à 500 ms en plus — les paramètres de tampon agressifs sont la source la plus courante de latence d'affichage inacceptable.

Latence détection-vers-CoT : inférieure à 3 secondes depuis la détection dans le pipeline d'analyse jusqu'à l'événement CoT visible sur les clients ATAK connectés. Ce budget couvre l'inférence de détection (20 à 150 ms), le calcul de géolocalisation (10 ms), la construction et publication de l'événement CoT (5 ms), le relais TAK Server (50 à 200 ms selon les sauts de fédération) et la mise à jour du client ATAK (100 à 500 ms selon l'intervalle d'interrogation de mise à jour).

Latence opérateur-vers-C2 : inférieure à 2 secondes depuis la désignation d'une cible par l'opérateur dans le plugin ATAK jusqu'à ce qu'une commande atteigne l'opérateur UAV ou l'élément de contrôle de tir. Il s'agit principalement d'une latence réseau et système C2 — la contribution du plugin d'intégration UAV est négligeable s'il publie le CoT immédiatement sur l'action de l'opérateur.

Pour un traitement plus approfondi de l'architecture de vision par ordinateur utilisée dans le pipeline d'analyse, consultez l'article sur la vision par ordinateur pour les drones ISR.