Normalisation des données capteurs : construire un modèle de données défense canonique

Un moteur de fusion n'est efficace que dans la mesure où les données qui l'alimentent le sont, et ces données sont presque toujours imparfaites. Un radar signale une portée en mètres et un relèvement en mils ; un récepteur AIS signale une position en degrés décimaux WGS84 et une vitesse en nœuds ; un produit imagery porte un timestamp d'acquisition en heure locale ; une interception SIGINT ne porte aucune géolocalisation. Avant toute corrélation, pistage ou analyse, chacune de ces sorties hétérogènes doit être transformée en une représentation interne unique et cohérente. Cette transformation est la normalisation des données capteurs, et la représentation unique qu'elle cible est le modèle de données canonique. Cet article explique comment concevoir le modèle canonique, construire les adaptateurs par source qui y correspondent, normaliser les unités, les coordonnées et le temps, transporter la provenance à travers chaque enregistrement, et faire évoluer le schéma sur des années sans casser les consommateurs qui en dépendent.

Pourquoi un modèle de données canonique

L'approche naïve d'un système multi-capteurs est de laisser chaque consommateur comprendre directement chaque format source. Le moteur de fusion analyse les messages radar, puis les messages AIS, puis les détections imagery, et ainsi de suite. Cela fonctionne pour deux ou trois sources et s'effondre sous le poids de la quatrième. Chaque nouveau type de capteur force un changement du code de fusion, de la couche de stockage, du rendu du COP et de chaque analyse qui touche les données. Le couplage est quadratique : N sources fois M consommateurs.

Un modèle de données canonique brise ce couplage. On définit un schéma interne unique — une observation normalisée — et on exige que chaque source y soit mappée avant d'entrer dans le pipeline. Le moteur de fusion, le magasin de pistes et la couche d'analyse ne consomment que le modèle canonique et ne voient jamais un format natif de capteur. Ajouter un nouveau capteur signifie écrire un adaptateur ; aucun composant en aval ne change. Le couplage passe de N fois M à N plus M.

Le modèle canonique n'est pas un format au plus petit dénominateur commun. C'est un sur-ensemble délibérément riche : il porte les champs dont tout consommateur pourrait avoir besoin — cinématique, identité, confiance, incertitude, classification et provenance — même lorsqu'une source donnée n'en peuple qu'un sous-ensemble. Un contact radar et un rapport HUMINT sont structurellement identiques dans le modèle canonique ; ils ne diffèrent que par les champs présents et la confiance accordée à chacun.

Anatomie d'une observation normalisée

Une observation canonique bien conçue possède cinq groupes de champs, chacun ayant un objectif précis.

Identité et type. Un ID d'observation globalement unique, un code de type d'entité tiré d'une taxonomie contrôlée (véhicule terrestre, navire de surface, aéronef, émetteur, fantassin démonté), et toute identité affirmée par la source telle qu'un numéro de piste, un MMSI ou un indicatif. La taxonomie de types doit être partagée entre toutes les sources afin qu'un navire signalé par AIS et un navire détecté par radar correspondent au même type canonique.

Cinématique. Position dans le référentiel de coordonnées canonique, vitesse et cap en unités canoniques, et altitude ou profondeur le cas échéant. Chaque champ cinématique porte une incertitude associée — une covariance ou, au minimum, un rayon d'erreur — car les algorithmes de fusion ne peuvent pas pondérer une observation qu'ils ne peuvent pas borner.

Temps. Un temps d'événement (quand l'observation s'est produite), distinct du temps d'ingestion (quand le pipeline l'a reçue). Le temps d'événement est la base de toute corrélation ; le temps d'ingestion sert aux diagnostics et à la mesure de latence. Chaque timestamp porte une borne d'incertitude.

Confiance. Un score de confiance normalisé et, séparément, la propre cote de fiabilité de la source. Une détection à haute confiance provenant d'une source peu fiable n'est pas la même chose qu'une détection à confiance modérée provenant d'une source de confiance, et le modèle canonique doit garder les deux distinguables.

Provenance. L'ID de source d'origine, le type de capteur, l'ID de message natif, l'adaptateur et la version de schéma qui ont produit l'enregistrement, et la classification et les mises en garde héritées de la source. La provenance est ce qui rend toute assertion en aval traçable.

Adaptateurs : là où vit la complexité spécifique à la source

L'adaptateur est le seul endroit du système qui comprend le format natif d'un capteur. Il analyse le message brut, extrait les champs pertinents, effectue toutes les conversions, joint la provenance et émet une observation canonique. Tout ce qui est particulier à une source — sa disposition binaire propriétaire, ses champs manquants, sa cadence de mise à jour irrégulière, sa dérive d'horloge — est absorbé dans l'adaptateur et ne fuit jamais en aval. C'est la même discipline de séparation des préoccupations sur laquelle repose l'architecture de fusion multi-capteurs : le cœur de fusion reste générique précisément parce que les adaptateurs font le travail difficile.

Les adaptateurs doivent être petits, testables indépendamment et sans état dans la mesure du possible. Un adaptateur sans état qui mappe un message d'entrée vers une observation canonique est trivial à tester unitairement contre des messages d'exemple enregistrés. Lorsqu'un adaptateur doit maintenir un état — par exemple, pour interpoler une position entre des mises à jour espacées, ou pour appliquer une correction de décalage d'horloge glissant — cet état doit être explicite et borné, jamais une accumulation implicite qui dérive sur une longue mission.

Mappage de schéma en pratique

Le mappage de schéma est la traduction champ par champ de la structure native d'une source vers l'observation canonique. La partie difficile n'est rarement les champs qui correspondent un à un ; ce sont les inadéquations. Une source peut regrouper deux concepts canoniques dans un seul champ, ou répartir un concept canonique sur plusieurs. Une source peut utiliser une énumération sans équivalent canonique, nécessitant une table de correspondance et une valeur par défaut documentée pour les valeurs non reconnues. Une source peut omettre un champ que le modèle canonique traite comme obligatoire, forçant l'adaptateur à soit le dériver, soit marquer l'observation comme partielle, soit la rejeter.

Le mappage lui-même doit être exprimé de manière déclarative dans la mesure du possible — une table de mappage ou une configuration qui indique « le champ natif X avec l'unité U devient le champ canonique Y » — afin que la traduction soit auditable et que les changements ne nécessitent pas de recompilation du moteur. Le code impératif est réservé aux transformations genuinement complexes qu'une table ne peut pas exprimer. Ces mêmes problèmes d'hétérogénéité sont à l'origine des défis d'intégration des données dans les systèmes de défense, et une couche de mappage disciplinée est la mitigation la plus efficace.

Unités, coordonnées et temps

Trois tâches de normalisation causent plus d'erreurs silencieuses et difficiles à diagnostiquer que tout autre chose dans un pipeline de fusion : la conversion d'unités, la transformation de coordonnées et l'alignement temporel. Chacune produit une sortie qui semble plausible tout en étant erronée.

Unités. Choisir un système d'unités canonique unique — le SI est le choix conventionnel : mètres, mètres par seconde, radians ou degrés de manière cohérente — et convertir chaque valeur entrante à la limite de l'adaptateur. Les nœuds deviennent des mètres par seconde ; les pieds deviennent des mètres ; les caps magnétiques sont convertis en caps vrais en utilisant la déclinaison magnétique locale. Le danger n'est pas l'arithmétique de conversion, qui est triviale, mais le champ non converti qui passe parce que l'unité de la source a été supposée plutôt que vérifiée. Un champ de vitesse laissé en nœuds et traité comme des mètres par seconde produit une piste se déplaçant à environ deux fois sa vitesse réelle — une piste qui corrèle mal et est difficile à repérer parce qu'elle n'est pas absurde, simplement incorrecte.

Coordonnées. Les capteurs rapportent en géodésique WGS84, MGRS, grilles tangentes locales ou référentiels relatifs à la plateforme. Tous doivent être transformés vers un référentiel de référence canonique avant la corrélation. Utiliser une bibliothèque de géodésie testée plutôt qu'une trigonométrie faite maison ; un décalage de datum ou une erreur de signe dans une transformation de coordonnées introduit des erreurs de position de dizaines de mètres qui sont opérationnellement significatives et notoirement difficiles à retracer jusqu'à leur source.

Temps. Convertir chaque timestamp en une base faisant autorité unique — l'UTC synchronisée GPS est la norme — et le stocker comme temps d'événement, non comme temps d'arrivée. Les capteurs hérités avec des horloges libres ou locales nécessitent des tables de correction de décalage par source, et chaque timestamp doit porter une borne d'incertitude explicite. Les observations dont l'incertitude de timestamp dépasse un seuil configuré doivent être marquées ou rejetées avant d'atteindre le corrélateur, car une observation temporellement mal étiquetée s'associe avec le mauvais objet et corrompt la piste qu'elle rejoint.

Provenance : rendre la sortie fusionnée responsable

Lorsqu'une piste fusionnée est présentée à un commandant, la question qui suit inévitablement est « d'où vient cela ? » Si la réponse est « le moteur de fusion l'a affirmé », cela ne suffit pas pour un système qui informe des décisions de ciblage ou d'accréditation. La provenance est la chaîne de preuves qui répond correctement à la question : cette piste a été construite à partir de ces trois observations, produites par ces deux capteurs, normalisées par ces versions d'adaptateur, à ces temps d'événement, portant ces classifications.

La provenance doit être jointe à la normalisation, non reconstituée ultérieurement. Chaque observation canonique porte son ID de source, son type de capteur, son ID de message natif, l'adaptateur et la version de schéma, et la classification et les mises en garde de la source. Lorsque le moteur de fusion combine des observations en une piste, il accumule leur provenance plutôt que de la supprimer, de sorte que la classification composite de la piste est la plus restrictive de ses entrées et sa liste de sources est l'union des leurs. Le besoin d'en connaître est alors appliqué au moment de la requête contre cette classification composite — jamais à l'ingestion, car la sensibilité éventuelle d'un enregistrement dépend de ce avec quoi il est ultérieurement combiné. C'est la même discipline de responsabilité sur laquelle s'appuient les pipelines de données défense basés sur les files de messages pour rendre chaque événement traçable au fur et à mesure qu'il se déplace entre les étapes.

Faire évoluer le schéma sans casser les consommateurs

Un modèle canonique est un contrat à long terme. De nouveaux types de capteurs arrivent, de nouveaux attributs deviennent pertinents, et le modèle doit les absorber sans forcer un redéploiement synchronisé de chaque consommateur du système. La discipline qui rend cela possible est le changement additif et versionné.

Additif signifie que les nouveaux champs sont toujours optionnels et dotés de valeurs par défaut, de sorte qu'un consommateur qui ne comprend pas un nouveau champ l'ignore simplement. Les champs existants ne sont jamais réutilisés et jamais supprimés en place — réutiliser un champ est le moyen le plus rapide de corrompre silencieusement un consommateur qui n'a pas été mis à jour. Versionné signifie que chaque observation est étiquetée avec la version de schéma sous laquelle elle a été produite, et chaque consommateur déclare la version minimale de schéma qu'il requiert. Un producteur peut commencer à émettre un nouveau champ optionnel le jour où il est ajouté ; les consommateurs l'adoptent selon leur propre calendrier.

Lorsqu'un changement cassant est inévitable, il est introduit comme une nouvelle version majeure de schéma qui fonctionne en parallèle avec l'ancienne. Les producteurs émettent les deux, ou un shim de traduction rétrograde les nouveaux enregistrements vers l'ancienne forme, jusqu'à ce que chaque consommateur ait migré ; seulement alors l'ancienne version est retirée. Cette discipline de fonctionnement en parallèle est peu spectaculaire mais c'est ce qui permet à un réseau de capteurs de croître continuellement — de la même manière qu'une architecture de réseau de capteurs IoT militaire bien conçue intègre de nouveaux types de nœuds — sans jamais arrêter le pipeline pour une bascule coordonnée.

Le versionnement de schéma est également rentable en termes de tests. Comme chaque enregistrement porte sa version et sa provenance, une capacité de relecture peut ingérer des données brutes enregistrées, les faire passer par un nouvel adaptateur ou une nouvelle version de schéma, et comparer la sortie canonique avec une référence connue. Les changements d'adaptateur sont validés contre des entrées enregistrées réelles avant de toucher jamais des données en direct, et les régressions apparaissent lors de la relecture plutôt que sur le terrain.