Géofencing pour les applications militaires de terrain : alertes par zone et contrôle d'accès

Une limite de zone franchie sans alerte est un échec de sécurité. Que cette limite marque une ligne de contact des troupes alliées, un couloir d'accès restreint, une zone d'exclusion autour d'une infrastructure critique ou un périmètre de point de ralliement, la valeur opérationnelle de cette limite dépend entièrement du système détectant le franchissement et notifiant les bonnes personnes en quelques secondes. Le logiciel de géofencing militaire met en œuvre cette détection à grande échelle : évaluation de centaines d'entités suivies par rapport à des dizaines ou des centaines de définitions de zones en continu, sur des appareils pouvant avoir une connectivité réseau intermittente, fonctionnant sur du matériel soldat avec des budgets CPU et mémoire limités. Cet article couvre les algorithmes géométriques, l'architecture d'évaluation hors ligne, la gestion du cycle de vie des zones, l'acheminement des alertes, l'intégration TAK et les caractéristiques de performance qui font du géofencing une capacité tactique fiable plutôt qu'une fonctionnalité d'arrière-plan au mieux.

Cas d'usage opérationnels du géofencing militaire

Le géofencing dans les applications militaires de terrain répond à un ensemble d'exigences plus large que les services de localisation commerciaux. Le cas d'usage le plus courant est la surveillance des limites : détecter quand un actif allié franchit une ligne de contact des forces alliées (FLOT), entre dans une zone de menace connue ou quitte une zone d'opérations désignée. Dans chaque cas, l'alerte doit parvenir au bon destinataire -- l'appareil ATAK d'un chef de section, un veilleur C2 ou un système de journalisation automatisé -- sans délai et sans que l'actif surveillé n'ait à effectuer aucune action. L'entité surveillée diffuse sa position via le flux CoT standard ; la couche de géofencing évalue cette position silencieusement et déclenche des alertes uniquement lors des transitions d'état.

Le contrôle d'accès est le deuxième cas d'usage majeur. Les zones restreintes -- points de stockage de munitions, postes de commandement, équipements de transmission -- peuvent être entourées de zones géofence configurées pour alerter sur toute entité non autorisée entrant dans le périmètre. La configuration de zone spécifie quelles catégories d'entités sont autorisées (alliées, indicatifs spécifiques, UID d'unité spécifiques) et lesquelles déclenchent des alertes (inconnues, hostiles ou toute entité ne figurant pas sur la liste autorisée). Cela exige que le moteur de géofencing évalue non seulement la position mais aussi les métadonnées de l'entité issues du flux CoT : le code de type CoT, l'indicatif de l'entité et le champ d'affiliation qu'ATAK dérive des préfixes de type CoT.

Un troisième cas d'usage est l'alerte de proximité pour la déconfliction : avertir une unité quand elle approche de la limite d'une mission de tir d'artillerie active, d'un couloir de vol UAV ou de la zone d'opérations assignée d'une autre unité. Ici la géométrie de zone est dynamique -- le polygone de la mission de tir évolue au fur et à mesure de la mission -- et le moteur de géofencing doit gérer les mises à jour de zones arrivant en cours de mission sans perturber l'évaluation des alertes en cours. La combinaison de zones dynamiques, de filtres d'entités et de multiples canaux d'alerte rend le géofencing militaire substantiellement plus complexe qu'une simple implémentation « ce point est-il dans ce polygone ».

Algorithmes géométriques : point-dans-polygone, confinement circulaire et zones par azimut-distance

L'algorithme de lancer de rayon est la méthode standard pour le test de confinement dans un polygone arbitraire. Étant donné un point de test P et un polygone défini par une liste ordonnée de sommets, l'algorithme projette un rayon depuis P dans une direction fixe (généralement vers l'est le long de la ligne de latitude constante) et compte le nombre de fois où le rayon coupe les arêtes du polygone. Un nombre impair de croisements signifie que P est à l'intérieur du polygone ; pair signifie à l'extérieur. Pour les coordonnées géographiques, les croisements d'arêtes requièrent une arithmétique géodésique plutôt que des mathématiques euclidiennes planes : une arête de grand cercle ne correspond pas à une ligne droite dans une projection plane, et l'utilisation de coordonnées projetées introduit des erreurs qui augmentent avec la taille du polygone et la distance depuis le centre de projection. À des échelles tactiques -- polygones couvrant des dizaines à des centaines de kilomètres -- l'utilisation de coordonnées géodésiques WGS84 avec des formules de croisement d'arêtes sur Terre sphérique maintient les erreurs en dessous d'un mètre sans la surcharge d'un calcul ellipsoïdal complet.

L'algorithme du nombre d'enroulements est une alternative qui gère correctement les polygones auto-intersectants et évite le cas limite numérique où le rayon passe exactement par un sommet. Pour un test du nombre d'enroulements, l'algorithme calcule l'angle total sous-tendu au point de test par la frontière du polygone lorsque la frontière est parcourue. Un nombre d'enroulements non nul indique que le point est à l'intérieur. Le test du nombre d'enroulements coûte environ 30 % de calcul supplémentaire par test par rapport au lancer de rayon pour les polygones convexes, mais est numériquement plus stable près des sommets et gère les dégénérescences de polygones qui surviennent lorsque les auteurs de zones créent des limites à la main sur des appareils tactiles. Pour les zones convexes -- qui couvrent la majorité des cas d'usage militaires tels que les zones de patrouille circulaires et les couloirs rectangulaires -- un test demi-plan contre chaque arête est plus rapide que l'un ou l'autre des algorithmes généraux et se prête à la vectorisation SIMD sur les processeurs ARM.

Le confinement circulaire est le cas dégénéré utilisé pour les zones de proximité et les zones d'exclusion circulaires. Tester si un point se trouve dans un cercle ne nécessite qu'un seul calcul de distance géodésique : si la distance Haversine entre le point de test et le centre du cercle est inférieure ou égale au rayon, le point est à l'intérieur. Le calcul de la distance Haversine sur un processeur ARM Cortex-A prend environ 200 nanosecondes, rendant les tests circulaires environ cinq fois plus rapides que les tests de polygone pour un polygone à 12 sommets. Les zones par azimut-distance -- éventails ou secteurs définis par un point central, une portée et un écart angulaire -- sont évaluées en combinant un test de confinement circulaire avec une vérification d'azimut : l'azimut de l'entité depuis le centre de zone doit se situer dans les limites angulaires de la zone. Ces zones sont courantes pour les zones d'emploi des armes (ZEA) et les zones de couverture des capteurs.

Évaluation géofence hors ligne sur les appareils soldats

La connectivité dans les environnements tactiques est intermittente par conception. Les marges de liaison radio sont gérées, les fréquences sont modifiées et les plans PACE supposent des périodes de communications dégradées ou déniées. Une implémentation de géofencing qui dépend d'un moteur d'évaluation côté serveur n'offre aucune protection pendant ces pannes. L'architecture hors ligne exige que toute décision d'évaluation que l'appareil soldat devra prendre -- confinement de zone, classification d'entité, envoi d'alerte -- soit exécutable en utilisant des données déjà présentes sur l'appareil.

Implémenter le géofencing hors ligne signifie que le jeu complet de zones doit être stocké localement, et non récupéré à la demande. Les zones sont chargées dans la base de données locale de l'appareil (SQLite est le magasin de données standard dans les applications de la famille ATAK) lorsque l'appareil les reçoit depuis le TAK Server, et elles persistent entre les redémarrages d'application. La boucle d'évaluation lit les zones depuis le magasin local, et non depuis le réseau, de sorte qu'un appareil hors ligne depuis six heures continue d'évaluer toutes les zones reçues avant la panne. La seule capacité dégradée est celle des mises à jour de zones : les zones révisées ou créées sur le serveur après la déconnexion de l'appareil ne sont pas évaluées tant que l'appareil ne se reconnecte pas et ne reçoit pas le jeu de zones mis à jour.

La boucle d'évaluation elle-même doit être suffisamment efficace pour s'exécuter en continu sur un appareil Android alimenté par batterie sans provoquer de limitation thermique ni de décharge de batterie que l'opérateur remarquera. Une boucle bien implémentée qui traite 1 000 positions d'entités par rapport à 200 zones en utilisant le pré-filtrage par boîte englobante et un index spatial R-tree consomme moins de 5 % d'un CPU ARM Cortex-A moderne à une fréquence de mise à jour de 1 Hz. L'index spatial est construit une seule fois lors du chargement des zones et mis à jour de manière incrémentielle lorsque des zones sont ajoutées, modifiées ou supprimées -- une reconstruction complète n'est jamais requise pour les deltas de zones. Les positions des entités sont traitées dans l'ordre d'arrivée depuis le flux CoT sans bloquer le thread UI, en utilisant un worker d'évaluation en arrière-plan qui ne publie les résultats d'alerte sur le thread principal que lorsqu'une transition de confinement est détectée.

Gestion du cycle de vie des zones : création, distribution, expiration et révocation

Une zone géofence qui survit à son objectif opérationnel est une source de fausses alertes et de confusion pour les opérateurs. La gestion du cycle de vie des zones couvre l'arc complet de la création à la suppression : chaque zone a un temps d'expiration défini, un identifiant de version et un enregistrement de provenance indiquant quel opérateur ou système l'a créée. Ces attributs sont portés dans la représentation KML ou CoT XML de la zone et stockés dans la base de données locale de zones de l'appareil aux côtés de la géométrie.

La distribution des zones dans les déploiements de l'écosystème TAK utilise des paquets de données -- des archives ZIP contenant des fichiers KML de zones, des images associées et un manifeste -- envoyés aux appareils connectés via l'API de paquets TAK Server. Le manifeste répertorie l'identifiant, le numéro de version et l'horodatage d'expiration de chaque zone. Lorsqu'un appareil reçoit un paquet de données, il compare la version de chaque zone avec la version dans son magasin local : les zones avec des versions serveur plus récentes remplacent les copies locales, les nouvelles zones sont insérées, et les zones présentes localement mais absentes du manifeste serveur sont signalées pour examen (non supprimées automatiquement, pour éviter les conditions de course avec les livraisons partielles). Le développement de plugins ATAK pour les flux de travail de géofencing personnalisés peut s'accrocher à cet événement de réception de paquet pour déclencher une logique de configuration de zone spécifique à la mission.

La révocation des zones doit se propager rapidement lorsqu'une zone active devient invalide -- une mission de tir terminée, un couloir compromis ou une zone créée avec une géométrie incorrecte. TAK Server prend en charge la suppression de zone via un événement CoT de suppression : un message CoT périmé ou de suppression standard référençant l'UID de la zone amène tous les appareils connectés à supprimer immédiatement la zone. Les appareils qui étaient hors ligne au moment de la révocation reçoivent la suppression lors de la reconnexion, en comparant leur jeu de zones local avec le manifeste actuel du serveur et en élaguant les zones que le serveur ne tient plus pour actives. Les horodatages d'expiration fournissent une solution de repli : même si un message de révocation est perdu, une zone expirée est automatiquement désactivée quand son horodatage passe, empêchant l'accumulation indéfinie de zones obsolètes sur les appareils au cours d'une longue opération.

Acheminement des alertes : de la détection de violation à la notification C2

Détecter un franchissement de limite et notifier le bon destinataire sont deux problèmes d'ingénierie distincts. Sur l'appareil qui détecte la violation, le chemin de notification est simple : la boucle d'évaluation publie un événement de transition vers le répartiteur d'alertes, qui active le canal de notification configuré pour la zone. Les canaux comprennent les alertes de superposition à l'écran (une bannière ou un changement de marqueur cartographique dans ATAK), des signaux audio (une tonalité configurable ou un indicatif parlé) et la journalisation silencieuse dans le registre d'incidents local de l'appareil. Pour les zones avec transfert vers C2 configuré, le répartiteur d'alertes construit également un événement CoT de violation et le met en file d'attente pour transmission au TAK Server.

L'événement CoT de violation porte des données structurées dans son bloc de détail : l'UID de zone, le type de violation (entrée ou sortie), l'UID et l'indicatif de l'entité en violation, l'horodatage de la transition, la position de l'entité au moment du franchissement et le nom de l'appareil rapporteur. TAK Server reçoit l'événement de violation et le transmet à tous les abonnés dont le filtre de type correspond au type CoT de l'événement de violation. Les postes de travail C2 exécutant des logiciels de cartographie ou d'image opérationnelle commune reçoivent les événements de violation en temps réel et peuvent les acheminer vers des tableaux de bord d'officiers de surveillance, déclencher des réponses automatisées ou les journaliser dans un registre d'incidents.

Intégration TAK et CoT pour les événements de violation de géofence

Le schéma Cursor on Target (CoT) est le format de données qui connecte les décisions de géofencing à chaque autre élément de l'écosystème TAK. Un événement de violation de géofence est un message CoT avec un code de type tiré de la taxonomie CoT, un triplet temps/début/péremption qui définit sa fenêtre de validité, et un bloc de détail qui porte les données de violation structurées décrites ci-dessus. Des événements de violation bien formés s'intègrent proprement avec l'infrastructure d'abonnement et de routage CoT que l'optimisation des performances TAK Server optimise pour les environnements à forte charge d'entités : les mêmes mécanismes de diffusion qui distribuent les rapports de position distribuent les événements de violation à tous les consommateurs C2 abonnés.

La géométrie de zone elle-même est représentée en CoT comme un élément de forme dans le bloc de détail, utilisant soit une liste de points de polygone soit une paire centre/rayon de cercle. Cela permet aux zones d'être créées dans ATAK, publiées sur TAK Server comme messages CoT et souscrites par d'autres appareils -- faisant de la distribution de zones une partie du flux de données CoT standard plutôt qu'un mécanisme séparé. Les appareils qui reçoivent des messages CoT de zone les stockent dans la base de données locale de zones et commencent à les évaluer immédiatement, sans redémarrage d'application requis. Les messages CoT de zone incluent un temps de péremption correspondant à l'horodatage d'expiration de la zone, de sorte que la collecte automatique des événements périmés de TAK Server supprime automatiquement les zones expirées de l'ensemble actif du serveur.

Pour les plugins ATAK qui implémentent une logique de géofencing personnalisée, l'API de plugin expose directement le modèle de données CoT : les plugins peuvent enregistrer des écouteurs pour les événements CoT correspondant à des codes de type ou des UID spécifiques, écrire des événements CoT dans le magasin local et s'abonner au système de couches cartographiques pour afficher des superpositions de zones personnalisées. Un plugin de géofencing qui doit évaluer des types de zones non standard -- un éventail azimut-distance, une zone d'exclusion limitée dans le temps ou une zone avec des règles d'autorisation spécifiques à l'entité -- implémente sa propre boucle d'évaluation aux côtés du géofencing intégré à la plateforme, en utilisant le même flux de position CoT comme entrée.

Performances sous charge : évaluation de milliers de pistes par rapport à des centaines de zones

Les environnements opérationnels avec de nombreuses entités et de nombreuses zones poussent la boucle d'évaluation dans un territoire où les choix algorithmiques importent. Une évaluation naïve O(N x M) de N zones par rapport à M pistes ne passe pas à l'échelle : avec 800 zones et 2 000 pistes se mettant à jour à 2 Hz, l'approche naïve nécessite 3,2 millions de tests de confinement par seconde. Sur un appareil Android de gamme intermédiaire avec un processeur ARM Cortex-A75, chaque test de confinement de polygone prend 0,5 à 2,0 microsecondes selon le nombre de sommets, plaçant le pire cas naïf à 6,4 secondes par cycle de mise à jour -- clairement impraticable.

Un index spatial R-tree sur les boîtes englobantes de zones réduit l'ensemble de candidats pour chaque piste de O(N) à O(log N + k), où k est le nombre de zones avec des boîtes englobantes chevauchantes -- généralement 1 à 5 dans un jeu de zones bien conçu où les zones ne se chevauchent pas de manière extensive. Avec un R-tree, le scénario à 800 zones et 2 000 pistes se réduit à environ 2 000 recherches d'index plus un petit nombre de tests de confinement exacts par cycle, s'achevant bien en dessous de 100 millisecondes sur le même matériel. Le R-tree est maintenu de manière incrémentielle : les insertions et suppressions de zones mettent à jour l'index en temps O(log N) sans nécessiter de reconstruction.

Une optimisation supplémentaire sépare la fréquence d'évaluation de la fréquence d'alerte. Toutes les entités n'ont pas besoin d'être évaluées à chaque tick TAK Server. Les entités qui sont immobiles depuis plus d'un seuil configurable (généralement 30 secondes) sont déprioritisées : leur état de confinement de zone est vérifié à une fréquence plus faible (une fois toutes les 10 secondes plutôt qu'une fois par seconde) jusqu'à ce qu'une mise à jour de position indique un mouvement. Les entités dynamiques -- celles avec des changements de position récents et significatifs -- sont toujours évaluées à la fréquence de mise à jour complète. Cette planification adaptative réduit la charge CPU de 40 à 60 % dans les scénarios opérationnels typiques où une fraction significative des entités suivies est stationnaire à un moment donné. Les mêmes principes de gestion de charge qui régissent l'abonnement aux entités du TAK Server s'appliquent directement à la boucle d'évaluation de géofencing côté client.