Comment les laboratoires de défense optimisent la validation grâce à des plateformes de simulation en temps réel

Principaux enseignements

• Les laboratoires de défense procèdent à une validation à grande échelle lorsqu’ils transposent les problèmes de synchronisation, de contrôle et de défaillances des installations sur des bancs d’essai déterministes avant de passer aux essais sur le terrain.
• Les modèles réutilisables, les plateformes ouvertes et la mise en œuvre précoce de la simulation HIL permettent de réduire les retouches, car les résultats restent cohérents à chaque étape de validation.
• Les règles de sécurité, les droits relatifs aux données et la traçabilité des preuves influencent autant la rapidité d'adoption que la fidélité du simulateur.

Les laboratoires de défense accélèrent la validation lorsqu'ils intègrent la détection des défaillances dans une simulation déterministe en temps réel.

Cette évolution est importante car la disponibilité des véhicules, les contraintes de sécurité et les contraintes de calendrier limiteront toujours les essais sur piste et en mission. La proposition de budget de la Défense américaine pour l’exercice 2025 a fixé le financement consacré à la recherche, au développement, aux essais et à l’évaluation à 143,2 milliards de dollars. Les laboratoires capables de mener davantage d’essais en laboratoire réduiront plus tôt les retouches, recourront à des essais sur le terrain pour confirmation et concentreront les ressources matérielles limitées sur les problèmes pertinents.

La simulation en temps réel permet de combler les lacunes avant les essais sur le terrain

La simulation en temps réel comble le fossé avant les essais sur site, car elle permet de détecter les défaillances de contrôle, les erreurs d'interaction entre les équipements et les décalages temporels alors que le matériel se trouve encore sur le banc d'essai. Vous bénéficiez ainsi d'une injection de défauts reproductible, de tests de limites en toute sécurité et de cycles de réexécution courts. Cela permet de consacrer le temps de piste, une ressource rare, à la validation plutôt qu'au débogage de base.

Un contrôleur de freinage destiné à un véhicule à chenilles affiche clairement cette valeur. En l’espace d’un après-midi sur un banc d’essai, le contrôleur peut être confronté à une perte soudaine de traction, à une baisse de la pression hydraulique et à des coupures du capteur de vitesse de roue. La même séquence sur une piste d’essai nécessiterait du temps de travail de l’équipe, la préparation du véhicule, des contrôles de sécurité et plusieurs essais successifs qui, malgré tout, ne donneraient pas de résultats parfaitement identiques.

« Vous bénéficiez d'une injection de défauts reproductible, de tests de limites en toute sécurité et de cycles de réexécution courts. »

Les essais en laboratoire ne permettent pas de rendre compte pleinement du comportement des équipes, des variations du terrain ou de l'usure des véhicules. Ils permettent toutefois d'identifier les défaillances qui font perdre du temps sur le terrain, en particulier lorsque les logiciels et les composants électroniques évoluent encore d'une semaine à l'autre.

La simulation de défense évolue à mesure que les modèles d'usine restent réutilisables

La simulation dans le domaine de la défense s'adapte lorsque le même modèle de système passe des premières étapes de développement logiciel aux bancs d'essai HIL, puis à la validation des sous-systèmes, avec un minimum de retouches. Les modèles réutilisables garantissent la cohérence de l'objectif des tests d'une phase à l'autre. Ils facilitent également considérablement la comparaison des défauts, car la logique du système n'a pas été reconstruite pour chaque laboratoire.

Le modèle de chaîne cinématique d’un véhicule est un domaine typique où la réutilisation peut soit faire gagner des mois, soit semer le chaos. Une équipe peut commencer par un modèle de bureau pour la logique de la boîte de vitesses, puis connecter ce même modèle de base à un banc d’essai de contrôleur de moteur, avant d’y ajouter le matériel de refroidissement et le trafic réseau pour effectuer des vérifications au niveau du système. Si chaque étape nécessite de réécrire le modèle séparément, vos résultats ne seront pas cohérents.

La réutilisation ne fonctionne que lorsque la propriété des modèles, les limites des solveurs et les contrats d'interface sont clairement définis. Les laboratoires qui considèrent la gouvernance des modèles comme une discipline technique évolueront bien plus efficacement que les équipes qui se contentent de se transmettre des fichiers en espérant que tout reste cohérent. C'est là que la simulation robotique et la simulation de véhicules militaires commencent à partager les mêmes règles d'exécution.

Les simulateurs de véhicules militaires nécessitent des performances d'entrée-sortie déterministes

Les simulateurs de véhicules militaires nécessitent des performances d'entrée/sortie déterministes, car la validation en boucle fermée repose sur une synchronisation constante plutôt que sur une synchronisation moyenne. Un contrôleur qui semble stable en présence de gigue sur un ordinateur de bureau peut présenter des défaillances une fois que les retards liés au matériel, aux bus et aux actionneurs sont pris en compte. Le déterminisme vous garantit des résultats fiables d'une exécution à l'autre.

Le système de direction et de freinage d’un véhicule blindé en est la parfaite illustration. Si les données de vitesse des roues arrivent en retard lors d’un cycle et en avance lors du suivant, le contrôleur peut donner l’impression d’osciller uniquement lors de certaines manœuvres. Un simulateur présentant une latence stable au niveau des flux de données des capteurs, du trafic réseau et des commandes des actionneurs permettra de mettre en évidence le problème avant que l’équipe de test n’attribue la faute à des problèmes mécaniques ou d’étalonnage.

Ici, il ne s'agit pas de rechercher la vitesse pour elle-même. Il s'agit de préserver la causalité tout au long de la boucle. Lorsque la synchronisation entre les entrées et les sorties est perturbée, l'isolation des défaillances devient plus difficile, les journaux de bord perdent tout leur sens et les ingénieurs passent des jours à débattre pour déterminer où se situe le bug. L'exécution déterministe permet de fonder la simulation de défense sur des preuves concrètes plutôt que sur des conjectures.

Les tests HIL permettent de détecter les défauts de synchronisation avant plateforme

Les tests HIL permettent de détecter les défauts de synchronisation avant plateforme , car ils obligent le code embarqué à interagir avec une installation réelle dans le cadre de contraintes de temps fixes. Cela met en évidence les glissements du planificateur, les conflits d'interruption, la charge du bus et les problèmes de séquencement au démarrage que les tests purement logiciels ne permettent pas de détecter. Vous détectez ainsi les défauts à un stade où leur isolation est encore peu coûteuse.

Un contrôleur de transmission hybride destiné à un véhicule de combat à roues en est un bon exemple. Le code peut réussir les tests logiciels avec des demandes de couple nettes et une réponse idéale de la batterie. Cependant, dès que le contrôleur est testé sur un banc HIL qui simule des retards de contacteurs, un temps mort de l’onduleur et un retour de courant bruité, des défauts de démarrage apparaissent souvent en l’espace de quelques minutes.

Ces défauts ont leur importance car leurs répercussions ne se limitent pas à un niveau local. Un léger décalage temporel dans l’arbitrage du couple peut se répercuter sur les limites thermiques, la logique de traction et les alarmes de gestion de l’alimentation dans le reste du véhicule. C’est pourquoi les laboratoires de défense recourent aux essais HIL dès les premières phases et de manière répétée, et non pas comme une simple étape finale à cocher avant plateforme .

La simulation en robotique doit modéliser les capteurs en respectant les délais d'exécution

La simulation robotique doit modéliser les capteurs en respectant les délais d'exécution, car les piles d'autonomie agissent sur des données de perception horodatées plutôt que sur des flux de données de capteurs idéaux. Si les données provenant des caméras, du lidar, du radar ou du système inertiel arrivent en retard ou dans le désordre, les résultats de la planification d'itinéraire et du contrôle perdent tout leur sens. La synchronisation des capteurs fait partie intégrante du système testé.

Un robot de déblayage de route illustre bien ce principe. Le système de perception peut combiner les données lidar, les images de caméra et les mises à jour inertelles pour classer les obstacles situés près du bord de la route. Si, lors d’un virage serré, le flux de paquets lidar accuse un retard par rapport à l’estimation de la position, le planificateur peut localiser un obstacle à plusieurs mètres de sa position réelle.

Les laboratoires privilégient souvent la fidélité visuelle en premier lieu, car le résultat obtenu semble convaincant. Or, les délais d’exécution sont plus importants. On ne peut pas obtenir de simulation robotique utile à partir de scènes esthétiques associées à un timing imprécis. Les équipes qui modélisent le bruit des capteurs, l’ordre des paquets et la synchronisation détecteront les défaillances de l’autonomie que les essais sur le terrain ne révèlent généralement que bien plus tard, et à un coût bien plus élevé.

Les plateformes ouvertes permettent de réduire les retouches dans les programmes de validation du secteur de la défense

« Les laboratoires rigoureux considèrent la simulation de défense comme la production de preuves, avec la même rigueur que celle qu’ils appliquent à l’exécution des tests. »

Les plateformes ouvertes réduisent les retouches dans les programmes de validation du secteur de la défense, car elles permettent aux équipes de réutiliser des modèles, du code et des interfaces d’un banc d’essai à l’autre, au lieu de tout reconstruire autour du flux de travail figé d’un seul fournisseur. Cela garantit la portabilité des ressources de validation, depuis les contrôles des sous-systèmes jusqu’aux bancs d’essai de véhicules complets. Vous consacrez ainsi moins de temps à l’adaptation des outils et davantage à la collecte de données probantes.

Un laboratoire chargé de valider à la fois un simulateur de véhicule militaire et un robot terrestre autonome doit souvent combiner du code de contrôle, des bus de communication, des capteurs sur mesure et des modèles fournis par des partenaires. L'utilisation d'outils propriétaires transforme chaque intégration en une nouvelle tâche de portage. OPAL-RT répond aux besoins de ces programmes lorsque les ingénieurs ont besoin d'une exécution modulaire, de délais serrés et de la flexibilité nécessaire pour intégrer leur propre chaîne d'outils sans avoir à reconstruire l'environnement de test à chaque fois que les exigences évoluent.

Une architecture ouverte nécessite tout de même une certaine discipline. Les équipes doivent s'en tenir à une nomenclature stable, à un contrôle des versions et à des référentiels d'interface, sans quoi cette même flexibilité entraînera des divergences. Les avantages sont considérables lorsqu'un programme passe d'un banc d'essai de sous-système à un laboratoire équipé de plusieurs bancs d'essai et de bibliothèques de modèles partagées.

Les droits relatifs aux données de sécurité influencent les processus d'achat plus tôt que ne le pensent les équipes

Les questions de sécurité et de droits sur les données influencent les décisions d'achat bien plus tôt que ne le pensent les équipes, car les plateformes de validation se situent à la croisée des modèles sensibles, des interfaces de mission et de la propriété intellectuelle des partenaires. Si ces règles sont floues, les laboratoires perdront en réutilisabilité, retarderont l'intégration ou accepteront des modèles de type « boîte noire » qu'ils ne peuvent pas vérifier. Les choix en matière d'achat fixent des limites techniques bien avant le début de l'exécution des tests.

Un maître d'œuvre peut fournir un modèle de chaîne cinématique sous forme de fichier binaire protégé, sans aucune visibilité sur les hypothèses, la synchronisation ou les points de détection des défaillances. Un laboratoire public peut l'exécuter, mais ne peut ni le modifier pour l'adapter à une nouvelle variante de véhicule, ni analyser les causes d'une défaillance survenue lors d'un test de régression. Le simulateur se transforme alors en simple poste d'observation, au lieu d'être un outil de validation.

• Vérifiez à qui appartient chaque modèle après la réception.
• Définir des règles relatives au traitement des données classifiées et soumises à des contrôles à l'exportation.
• Accès requis aux paramètres de synchronisation et aux points d'injection de défauts.
• Vérifiez comment les modèles de nos partenaires s'adaptent à vos bancs existants.
• Préciser quelles données la plateforme conserver à des fins d'audit.

Vous ne pourrez pas combler ces lacunes par la suite, même en améliorant le script de test. Les questions relatives à la sécurité, à l’accès aux modèles et à la réutilisation doivent figurer dès les premiers documents d’appel d’offres, car elles déterminent toutes les étapes suivantes.

Des résultats de tests traçables permettent une validation plus rapide à chaque étape clé

Des preuves de test traçables facilitent une validation plus rapide à chaque étape clé, car les équipes de révision ont besoin de preuves établissant un lien entre les exigences, les versions du modèle, les conditions temporelles et les résultats au sein d’une même chaîne. Une traçabilité claire réduit les répétitions de tests et limite les litiges concernant ce qui a réellement été testé. Elle transforme les résultats de simulation en éléments de validation, plutôt qu’en simples notes internes.

Les grands programmes d'acquisition de défense américains, selon l'évaluation du GAO pour 2024, représentaient environ 2 400 milliards de dollars de coûts prévisionnels répartis sur 59 programmes. À cette échelle, une révision de modèle omise, un paramètre de latence non documenté ou un journal des défaillances insuffisant ne resteront pas un problème confiné à un laboratoire local. L’examen d’un sous-système de mobilité peut être bloqué parce que la commission d’évaluation ne parvient pas à établir un lien entre un résultat de test réussi et la version logicielle exacte ainsi que la configuration de l’installation qui l’ont généré.

Les laboratoires rigoureux considèrent la simulation de défense comme la production de données probantes, avec la même rigueur que celle qu’ils appliquent à l’exécution des tests. C’est ce discernement qui distingue une validation évolutive d’un simple « banc d’essai » surchargé. OPAL-RT trouve toute sa place dans ce débat lorsqu’une équipe a besoin d’une exécution déterministe, de modèles réutilisables et de rapports qui conservent toute leur pertinence plusieurs mois plus tard, lors de la revue de réception.