Intégration live-virtual-constructive (LVC) pour la formation militaire

La formation collective à grande échelle — celle qui prépare les états-majors de brigade à synchroniser les feux, la manœuvre et la logistique sur un champ de bataille multi-domaine — ne peut pas être réalisée à moindre coût avec des forces réelles seules. Les exercices réels consomment des munitions, usent les véhicules et nécessitent la déconfliction de milliers de kilomètres carrés d'espace aérien et terrestre. Les simulateurs virtuels compressent la géographie et éliminent les coûts en consommables, mais ils ne peuvent pas reproduire la friction, la latence des communications et la fatigue physique des opérations réelles. La simulation constructive monte en charge à moindre coût jusqu'au niveau division ou corps, mais les entités qu'elle génère sont des abstractions contrôlées par ordinateur, pas des soldats. Chaque domaine capture une partie du tableau d'entraînement. L'intégration live-virtual-constructive (LVC) tente de combiner les trois dans un environnement synthétique cohérent unique — offrant au public d'entraînement une combinaison réaliste de forces réelles, de simulateurs avec équipage et d'entités générées par ordinateur simultanément. L'architecture permettant ce fonctionnement fait l'objet de cet article.

Ce que signifient live, virtual et constructive

Les termes sont définis par le degré d'implication humaine dans la boucle. Live signifie de vraies personnes opérant de vrais équipements dans l'environnement physique. Un peloton de chars conduisant des M1A2 sur un champ de tir est un élément live. L'instrumentation — traceurs GPS, simulateurs d'effets d'armes comme MILES, radios vocales — permet au système de contrôle d'exercice d'observer et d'enregistrer ce que font les éléments réels, mais les forces elles-mêmes sont physiquement présentes. Les éléments réels constituent la référence en termes de réalisme pour la formation individuelle et en équipage ; ils sont coûteux et difficiles à mettre à l'échelle.

Virtual signifie qu'un opérateur humain interagit avec une plateforme simulée dans un simulateur. L'opérateur est réel et exerce de vraies compétences cognitives et procédurales, mais la plateforme et l'environnement sont synthétiques. Steel Beasts Pro PE, Prepar3D et les simulateurs de mission aérienne sont des environnements virtuels. Les éléments virtuels sont moins coûteux par heure de formation que les éléments réels, peuvent représenter des plateformes rares ou en maintenance, et peuvent être réinitialisés à n'importe quel état de scénario instantanément. Leur limite est que les modèles de physique et de capteurs simulés, aussi détaillés soient-ils, restent des approximations.

Constructive signifie des entités générées par ordinateur contrôlées par un logiciel — IA, modèles de comportement scriptés, ou contrôleurs d'exercice humains agissant comme forces agrégées. Aucun humain individuel n'est dans la boucle pour chaque entité. OneSAF, JCATS et WARG sont des systèmes de simulation constructive. La simulation constructive monte en charge jusqu'aux exercices au niveau corps avec des dizaines de milliers d'entités à une fraction du coût des forces réelles ou virtuelles équivalentes. Le compromis est une réalisme réduit au niveau de l'entité individuelle et un engagement moindre avec le public d'entraînement sur les tâches qui nécessitent une véritable charge cognitive de la part de la force adverse.

L'intégration LVC combine les trois. Un exercice de brigade pourrait avoir un bataillon d'infanterie réel sur un champ de tir réel, des équipages de rotary-wing virtuels pilotant des hélicoptères simulés depuis une installation de simulateur, et un OPFOR constructif de taille régimentaire dont le comportement est guidé par une petite équipe de contrôle d'exercice. La valeur d'entraînement de l'environnement combiné dépasse ce que n'importe quel domaine seul pourrait fournir : le bataillon réel fait face à une pression tactiquement cohérente d'un grand OPFOR constructif au comportement réaliste, coordonné avec un soutien aérien virtuel qui réagit aux événements au sol en quasi-temps réel.

Le défi de l'interopérabilité

Combiner les trois domaines est architecturalement non trivial car chaque domaine a été développé indépendamment et utilise des protocoles, des bases de temps et des modèles d'entités différents. Les forces réelles communiquent via LINK 16, VMF, NFFI (NATO Friendly Force Information) ou des flux Cursor on Target (CoT) provenant de systèmes d'instrumentation. Les simulateurs virtuels parlent généralement DIS (Distributed Interactive Simulation, IEEE 1278) ou HLA (High Level Architecture, IEEE 1516). Les systèmes de simulation constructive parlent HLA — généralement la variante RPR-FOM (Real-time Platform Reference Federation Object Model) — ou TENA (Test and Training Enabling Architecture) dans les contextes d'instrumentation de champ de tir.

Trois lacunes d'interopérabilité rendent l'intégration LVC difficile en pratique. La première est l'hétérogénéité des protocoles : un message de trace LINK 16 et une mise à jour d'attribut EntityState HLA RPR-FOM représentent conceptuellement la même chose (la position et l'état d'une entité militaire), mais dans des formats binaires entièrement différents, avec des sémantiques de champ différentes, et sur des mécanismes de transport différents. Une passerelle doit traduire entre eux sans perte d'information ni ambiguïté.

La deuxième lacune est le décalage de latence. Une trace GPS réelle provenant d'un véhicule instrumenté se met à jour à 1 Hz. Un simulateur de char virtuel met à jour l'état de son entité à 20-30 Hz en utilisant la prédiction par extrapolation entre les mises à jour. Une simulation constructive fonctionnant en temps réel peut mettre à jour les positions des entités à des taux variables selon l'activité des entités. Lorsque ces flux arrivent dans un environnement synthétique partagé, les positions des entités doivent être fusionnées de manière cohérente — un véhicule réel qui se met à jour à 1 Hz semblera sauter si sa position est simplement transmise au taux de mise à jour réel plutôt que lissée avec une extrapolation par prédiction cohérente avec le pas de temps de la simulation.

La troisième lacune est l'identité des entités. Le même char physique apparaissant dans le domaine réel, suivi par l'instrumentation du champ de tir, représenté par un équipage de simulateur virtuel, et répliqué comme entité constructive pour la conscience de la force adverse, doit être correctement identifié comme une entité unique dans tous les domaines — pas comme trois entités séparées qui occupent le même emplacement. La gestion de l'identité à travers les frontières de domaine, en particulier lorsque les entités transitent entre la représentation réelle et constructive durant un exercice, est l'un des aspects les plus sujets aux erreurs de l'architecture LVC.

HLA comme colonne vertébrale LVC

HLA (High Level Architecture, IEEE 1516) est le standard de fédération dominant pour connecter les composants LVC car il fournit les services nécessaires pour gérer un environnement de simulation multi-fédéré à grande échelle. Le protocole HLA lui-même est couvert en détail séparément ; ici l'accent est mis sur la façon dont HLA fonctionne spécifiquement dans un contexte LVC.

Dans une fédération LVC, chaque composant majeur — le système de simulation constructive, chaque site de simulateur virtuel, et chaque adaptateur de passerelle pour les flux de forces réelles — rejoint la fédération HLA en tant que fédéré. Le RTI (Run-Time Infrastructure) gère la communication entre les fédérés en utilisant le FOM (Federation Object Model) de la fédération, généralement basé sur le RPR-FOM 2.0 de SISO pour l'interopérabilité OTAN.

La gestion de la fédération gère le cycle de vie de l'exercice : création de la fédération, adhésion et retrait des fédérés, points de synchronisation (utilisés pour coordonner le démarrage, la pause et le redémarrage du scénario entre tous les composants), et destruction de la fédération. Dans un exercice LVC multi-sites, les points de synchronisation sont essentiels — sans eux, un fédéré peut commencer à avancer le temps du scénario tandis qu'un autre est encore en cours d'initialisation, corrompant l'état des entités à travers la frontière.

La gestion du temps dans une fédération LVC est généralement configurée en temps réel au mieux possible plutôt qu'en simulation strictement gérée par le temps, car les forces réelles ne peuvent pas être mises en pause ou ralenties pour accommoder les octrois d'avance temporelle. Le RTI fonctionne en mode temps réel ; les fédérés constructifs et virtuels publient des mises à jour horodatées mais ne bloquent pas l'avance temporelle de la fédération pour les données réelles arrivant en retard. Cela signifie que les composants constructifs et virtuels doivent tolérer des mises à jour d'état d'entité occasionnellement hors séquence provenant des passerelles réelles.

La gestion de la distribution des données (DDM) est essentielle à l'échelle LVC. Un exercice au niveau corps peut avoir des milliers d'entités sur une zone géographique couvrant des centaines de kilomètres. Sans DDM, chaque fédéré reçoit chaque mise à jour d'état d'entité — une charge en bande passante et en traitement qui submergerait les simulateurs de poste de commandement n'intéressés que par un rayon tactique de 50 km. Les régions d'abonnement DDM, configurées pour correspondre à la zone d'intérêt opérationnel de chaque fédéré, réduisent cela à un volume gérable.

DIS dans LVC : toujours pertinent pour les composants virtuels

Malgré les avantages architecturaux de HLA, DIS (IEEE 1278) reste présent dans les environnements LVC car une grande base installée de simulateurs virtuels parle DIS nativement et ne peut pas être réintégrée de manière rentable vers HLA. Steel Beasts Pro, de nombreux simulateurs de vol hérités et d'anciens outils d'exercice de poste de commandement ont été conçus pour les environnements DIS. Les remplacer n'est pas faisable dans la plupart des budgets de programme.

La solution est un pont DIS vers HLA : une passerelle qui participe au réseau multicast DIS en tant que participant DIS et simultanément en tant que fédéré HLA, traduisant les PDU DIS en mises à jour d'état d'entité RPR-FOM et vice versa. Le pont doit gérer soigneusement les différences sémantiques. Les PDU Entity State DIS utilisent des algorithmes de prédiction par extrapolation (définis dans la norme) pour lisser la position entre les mises à jour ; le pont doit appliquer la même extrapolation sur les données DIS entrantes avant de publier vers HLA pour éviter les discontinuités de position. Le pont doit également mapper les codes de type d'entité DIS (qui utilisent une énumération hiérarchique définie dans SISO ENUM-70) vers les attributs EntityType HLA RPR-FOM en utilisant la même énumération — des discordances dans le codage du type d'entité amènent l'OPFOR constructif à mal classer les plateformes amies virtuelles.

La gestion du taux de PDU est une préoccupation pratique. Un environnement DIS avec 200 simulateurs virtuels publiant chacun à 30 Hz génère 6 000 PDU par seconde sur le réseau multicast. Le pont DIS vers HLA doit filtrer cela en utilisant des seuils de bande morte — ne transmettant les mises à jour que lorsque la position, la vitesse ou l'orientation dépassent un seuil défini — pour éviter de saturer la fédération HLA avec des mises à jour représentant des mouvements insignifiants.

Architecture de la passerelle LVC

La couche de passerelle est architecturalement le composant le plus critique et le plus sujet aux défaillances d'une intégration LVC. Une passerelle adapte une source de données réelle — LINK 16, NFFI, CoT, instrumentation de champ de tir — dans la fédération HLA. Chaque passerelle doit remplir plusieurs fonctions simultanément.

La traduction de protocole convertit le format de message entrant en mises à jour d'attributs RPR-FOM. Ce n'est pas purement mécanique : les messages de la série J LINK 16 encodent la position des entités en coordonnées géodésiques WGS-84, tandis que HLA RPR-FOM utilise un système de coordonnées cartésiennes geocentriques (centré sur la Terre, fixe par rapport à la Terre). La passerelle doit effectuer la transformation du référentiel de coordonnées pour chaque mise à jour de position. Les vecteurs de vitesse, s'ils sont présents dans le flux réel, doivent être transformés de manière cohérente. Le mappage du type d'entité des codes de type d'émission LINK 16 vers les valeurs EntityType RPR-FOM nécessite une table de traduction maintenue — les nouveaux types d'équipements doivent être ajoutés explicitement, et les codes ambigus (où un type LINK 16 correspond à plusieurs types de plateformes) nécessitent une résolution heuristique.

La gestion du cycle de vie des entités gère l'apparition, la persistance et la disparition des entités réelles dans la fédération HLA. Lorsque la passerelle voit une trace pour la première fois, elle crée une instance d'objet HLA et en prend possession. Lorsque la trace est perdue (panne GPS, véhicule masqué par le terrain), la passerelle doit décider de maintenir une estimation de position extrapolée pendant une période de grâce ou de supprimer immédiatement l'objet. Une suppression prématurée suivie d'un ré-enregistrement rapide crée des discontinuités d'identité d'objet qui perturbent la logique de ciblage de l'OPFOR constructif. Une extrapolation prolongée des traces perdues crée des entités fantômes qui dégradent la situation opérationnelle du public d'entraînement.

L'adaptation de taux fait correspondre la cadence de mise à jour de la source réelle aux attentes de la simulation. Un traceur GPS se mettant à jour à 1 Hz ne peut pas injecter des mises à jour au taux de 20-30 Hz qu'utilisent les entités constructives ; la passerelle doit publier au taux réel et configurer les paramètres de prédiction par extrapolation (vitesse et accélération) dans l'état d'entité HLA pour que les fédérés récepteurs puissent extrapoler la position entre les mises à jour. Les paramètres d'extrapolation doivent être définis de manière réaliste — un véhicule chenillé ne peut pas se voir attribuer le modèle d'extrapolation d'un aéronef.

LVC hébergé dans le cloud : architecture et budget de latence

Déplacer les composants back-end LVC vers un environnement cloud gouvernemental — Azure Government ou un équivalent classifié IL5/IL6 — est opérationnellement attrayant car il élimine la nécessité d'expédier et de configurer une infrastructure serveur physique sur chaque site d'exercice. Une fédération de simulation constructive hébergée dans le cloud peut servir plusieurs sites d'exercice géographiquement dispersés simultanément, avec des installations de simulateurs virtuels et des passerelles de forces réelles à différents endroits se fédérant dans une fédération HLA commune hébergée dans le cloud.

La contrainte critique est la latence. La gestion du temps HLA en mode temps réel accorde des avances temporelles à des intervalles déterminés par la configuration du lookahead et le cycle de battement de cœur du RTI. Pour une fédération LVC en temps réel, l'exigence pratique est que les mises à jour d'état d'entité atteignent tous les fédérés abonnés dans les 100-150 ms suivant leur génération — au-delà de ce seuil, la logique de manœuvre de l'OPFOR constructif commence à agir sur des données de position périmées, et les équipages de simulateurs virtuels voient les entités réelles se téléporter plutôt que se déplacer en douceur.

Un RTI hébergé dans le cloud servant des fédérés sur des sites géographiquement dispersés doit être situé pour minimiser la latence aller-retour dans le pire cas. Les régions Azure Government dans le continent américain atteignent environ 20-40 ms aller-retour vers la plupart des sites d'entraînement CONUS via des chemins réseau gouvernementaux dédiés (pas l'internet public). Les sites d'entraînement européens atteignant une région cloud américaine font face à 80-120 ms aller-retour. C'est dans le seuil de 150 ms pour les composants constructifs et virtuels, mais marginal pour les passerelles de forces réelles qui doivent répondre à des flux de capteurs à taux élevé.

L'architecture recommandée divise la fédération HLA en niveaux géographiques. La simulation constructive, la gestion des scénarios et l'enregistrement AAR fonctionnent dans le cloud. Les simulateurs virtuels et les passerelles de forces réelles fonctionnent sur chaque site d'exercice avec un proxy RTI local qui relie la fédération cloud. Le proxy local met en cache l'état des entités pour la zone d'intérêt du site local, servant les mises à jour aux fédérés locaux depuis le cache plutôt qu'un aller-retour vers le RTI cloud pour chaque mise à jour d'attribut. Cela maintient les interactions locales à locales en dessous de 5 ms tout en synchronisant l'état global de la fédération via l'infrastructure cloud.

Implications pour les composants de simulation constructive

Le composant de simulation constructive dans une fédération LVC a des responsabilités au-delà de la simple génération de comportement d'entité. Il doit maintenir un état d'entité cohérent à travers la frontière LVC — identifier correctement quelles entités sont réelles, lesquelles sont virtuelles et lesquelles sont constructives, et appliquer des règles d'engagement et une logique d'engagement appropriées à chaque catégorie. Un élément OPFOR constructif doit être capable d'engager des entités amies à la fois réelles et virtuelles avec une logique cohérente ; mais il ne doit pas tenter d'engager des entités qui sont des artefacts d'instrumentation (traces réelles dupliquées, entités de test injectées pour le débogage de l'intégration).

Le comportement de l'IA constructive doit également tenir compte de la latence et de l'incertitude inhérentes aux données d'entité réelle. Un système constructif conçu pour un environnement entièrement constructif suppose une connaissance parfaite de toutes les positions d'entités, mise à jour au propre pas de temps de la simulation. Lorsque les données d'entité réelle arrivent à 1 Hz avec des lacunes occasionnelles, l'IA constructive doit utiliser des positions extrapolées pour les décisions de ciblage et de manœuvre — et doit se dégrader gracieusement lorsque les traces réelles s'éteignent, plutôt que de traiter la perte de trace comme une destruction d'entité.

La couche de gestion des scénarios de la simulation constructive pilote également les décisions de contrôle d'exercice qui affectent le domaine réel : quand introduire des renforts, quand dégrader les communications, quand faire la transition d'un OPFOR constructif à un OPFOR réel pour une phase spécifique de l'exercice. Les exercices de planification d'état-major utilisant la simulation constructive bénéficient de cette flexibilité — l'équipe de contrôle d'exercice peut injecter des stimuli dans le domaine réel via la couche constructive sans interrompre la liberté d'action de la force réelle.