Simulation en temps réel pour la validation des systèmes autonomes et des systèmes d'aide à la conduite avancés (ADAS)

Principaux enseignements

• Les essais sur route et sur piste ne permettent pas de couvrir l'ensemble des cas critiques pour la sécurité ; c'est pourquoi la majeure partie de la validation doit désormais s'appuyer sur des simulations instrumentées et reproductibles.
• Une exécution déterministe en temps réel et Simulation HIL sont nécessaires pour valider la synchronisation, la latence et le comportement des E/S avec les calculateurs de série.
• Choisissez des solutions de simulation ADAS fondées sur le déterminisme en boucle fermée, la fidélité des interfaces, le contrôle des scénarios et la traçabilité des données, puis effectuez des tests de régression rigoureux afin d'éviter toute fausse assurance.

Les essais physiques restent importants, mais ils ne peuvent pas assumer à eux seuls toute la charge de validation des systèmes avancés d'aide à la conduite et de la conduite autonome. La combinaison de situations critiques pour la sécurité peu fréquentes, de calendriers de mise sur le marché serrés et de configurations de capteurs complexes oblige les équipes à transférer la majeure partie de l'apprentissage vers un processus de simulation ADAS fonctionnant en continu et pouvant être répété à la demande. Une analyse de la RAND datant de 2016 estimait à environ 11 milliards de miles de conduite pour prouver, avec un haut niveau de confiance statistique, qu'un véhicule automatisé est plus sûr qu'un conducteur humain.

« La simulation en temps réel vous permettra de valider les systèmes ADAS de manière reproductible, sans exposition aux risques liés à la conduite sur route. »

En pratique, le principe est simple : les essais sur route doivent confirmer ce que l'on sait déjà, tandis que la simulation déterministe en temps réel et Simulation HIL doivent permettre de détecter les défauts, d'affiner les commandes et de tester les conditions limites dès le début du processus. Les équipes qui considèrent le simulateur de conduite autonome comme leur principal outil de validation rencontrent moins de surprises de dernière minute, disposent d'arguments de sécurité plus solides et bénéficient d'une traçabilité plus rigoureuse, depuis les spécifications jusqu'aux preuves.

Les objectifs de validation dépassent ce que les essais sur route permettent de couvrir

Les essais sur route ne permettent pas d'atteindre le niveau de couverture, de reproductibilité et d'observabilité requis pour la validation des systèmes d'aide à la conduite avancés (ADAS). Il est impossible de programmer à la demande des interactions rares, de reproduire exactement le même scénario au centimètre près après une modification du code, ni de pousser les défaillances à leurs limites en toute sécurité. Les flottes physiques brouillent également les liens de causalité, car les conditions de circulation, la météo et les actions du conducteur ne se reproduisent jamais exactement de la même manière.

Les critères de validation ne se limitent plus à de simples vérifications de fonctionnement « par temps ensoleillé ». On attend désormais de vous que vous démontriez les performances du système malgré les variations des capteurs, la charge du véhicule, le vieillissement des actionneurs et les différents scénarios d'exploitation, tout en conservant une trace d'audit rigoureuse. Ces exigences font que le problème du kilométrage ne se résume plus à une simple question de kilomètres, mais relève davantage de la combinatoire, où un petit ensemble de variables génère des milliers de points de test pertinents.

La simulation comble cette lacune lorsque vous la considérez comme un système de mesure et non comme un jeu vidéo. Vous instrumentez chaque signal, enregistrez des horodatages précis et associez une logique de réussite/échec aux exigences. La validation devient ainsi une boucle d'ingénierie que vous pouvez exécuter chaque nuit, plutôt qu'un événement ponctuel dépendant des horaires de piste, des pilotes et des conditions météorologiques.

Pourquoi les systèmes ADAS et la conduite autonome ont besoin d'une simulation déterministe en temps réel

Les systèmes ADAS et les piles logicielles autonomes nécessitent une simulation en temps réel déterministe, car la synchronisation fait partie intégrante de leur fonctionnement. Si votre planificateur, votre contrôleur, vos capteurs et vos actionneurs ne restent pas synchronisés, le système peut sembler fonctionner correctement lors d'une lecture hors ligne, mais échouer lors d'une conduite en boucle fermée. L'exécution déterministe vous permet d'être certain que toute variation des résultats provient de votre logiciel, et non d'une synchronisation variable des calculs.

Le temps réel est primordial dès lors que l'on tient compte des boucles de rétroaction. Le réglage des contrôleurs dépend de délais précis, la latence de perception influe sur la distance de freinage, et les fluctuations de synchronisation peuvent déstabiliser les transferts entre fonctions. Un simulateur ADAS fonctionnant plus rapidement que le temps réel peut s'avérer utile pour la recherche et la génération de données, mais une boucle déterministe reste nécessaire pour valider le comportement réel de l'ECU lorsque le véhicule est en mouvement.

Le déterminisme permet également de mettre en place des processus de validation fiables. Vous pouvez enregistrer une version de scénario, une configuration de simulateur et un hachage de build d'ECU, puis réexécuter exactement le même test plusieurs mois plus tard, lors de la révision d'un dossier de sécurité. Ce type de traçabilité est difficile à obtenir lorsque les principales données proviennent d'essais routiers ponctuels et de séquences vidéo marquées manuellement comme « bonnes exécutions ».

Simulation HIL le fossé entre les modèles et les calculateurs

Simulation HIL constituent le lien entre des modèles qui semblent corrects et des contrôleurs embarqués qui se comportent correctement dans le respect des contraintes de synchronisation et d'E/S. Ils mettent en évidence les problèmes liés aux débordements, à la quantification, à la planification, à la charge du bus et au comportement du chien de garde, qui n'apparaissent pas lors d'une simulation sur ordinateur de bureau. Ils obligent également votre simulation ADAS à respecter les mêmes horloges et interfaces que celles utilisées par le véhicule.

Voici à quoi ressemble un processus concret : l'ECU de production chargé de la fonction de freinage se connecte via CAN ou Ethernet automobile à un simulateur en temps réel qui génère les données des capteurs et la dynamique du véhicule, tandis qu'un système d'injection de défauts simule des pertes de signal des capteurs et des variations de synchronisation. Les ingénieurs peuvent alors vérifier que l'ECU respecte toujours les limites en matière de distance de freinage et de stabilité lorsque le même scénario est reproduit avec des variations contrôlées des paramètres, sans mettre en danger un pilote d'essai.

C'est au cours de cette étape dite de « boucle fermée avec du matériel réel » que de nombreuses équipes spécialisées dans l'autonomie se heurtent aux problèmes les plus coûteux en phase finale. Les marges de latence apparaissent clairement, les hypothèses relatives aux interfaces sont corrigées et les contrôleurs de sécurité sont réglés à l'aide de déclencheurs mesurables plutôt que sur la base de suppositions. Les systèmes OPAL-RT sont souvent utilisés à ce stade, car leur modèle d'exécution repose sur des E/S en temps réel déterministes, ce dont votre laboratoire a besoin lorsque les calculateurs doivent fonctionner exactement comme ils le font dans un véhicule.

Les principaux scénarios que les simulateurs doivent reproduire pour inspirer confiance

Un simulateur renforce la confiance lorsqu'il soumet le système à des contraintes à ses limites, et non lorsqu'il reproduit des conditions de fonctionnement nominales. Il faut une couverture qui englobe les limites du domaine de conception opérationnel, l'incertitude des capteurs et la complexité des interactions, ainsi que la capacité à effectuer des injections de défauts sans perdre le déterminisme. La confiance naît de la démonstration d'un comportement stable face à des variations contrôlées, puis de la confirmation de ces mêmes schémas lors d'essais physiques limités.

La qualité d'un scénario dépend de trois facteurs : la fidélité, la variabilité et l'observabilité. La fidélité signifie que les modèles des capteurs et du véhicule sont suffisamment précis pour que les erreurs de contrôle et de perception apparaissent pour les bonnes raisons. La variabilité signifie que l'on peut faire varier les conditions initiales, les comportements des acteurs, les frottements et le bruit des capteurs de manière structurée. L'observabilité signifie que chaque signal interne est enregistré afin de pouvoir expliquer et corriger les défaillances.

Le comportement humain est l'un des principaux facteurs à l'origine des situations auxquelles les systèmes ADAS doivent faire face, et les statistiques en expliquent clairement la raison. Les choix humains contribuent à 94 % des accidents graves. Un bon simulateur de conduite autonome permettra de tester sous pression la manière dont votre système réagit à des actions imprévisibles, tout en garantissant que le test reste reproductible, mesurable et sûr pour votre équipe.

Comment évaluer une plateforme de simulateurs de conduite ADAS

« Cela met en évidence les problèmes de débordement, de quantification, de planification, de charge du bus et de comportement du chien de garde qui n'apparaissent pas lors d'une simulation sur ordinateur. »

La qualité d'une plateforme de simulation de conduite ADAS dépend entièrement de sa capacité à effectuer des tests en boucle fermée, à intégrer votre chaîne d'outils et à produire des résultats que vous pouvez justifier. Vous devez l'évaluer comme une infrastructure de laboratoire, et non comme une simple démonstration. Concentrez-vous sur la synchronisation déterministe, la couverture des interfaces, la gestion des scénarios et l'intégrité des données, puis assurez-vous que votre équipe est en mesure de la maintenir sans effort surhumain.

Commencez par définir vos objectifs de validation, puis déterminez en amont les exigences en matière de puissance de calcul, de fidélité et de connectivité. Si votre objectif est la validation au niveau de l'ECU, le simulateur doit prendre en charge l'exécution en temps réel avec les mêmes bus et les mêmes contraintes de synchronisation que ceux que vous rencontrerez sur le banc d'essai. Si votre objectif est le développement de la perception, le simulateur doit prendre en charge des modèles de capteurs, des données de référence et des pipelines d'annotation reproductibles qui correspondent à vos indicateurs de performance.

• Planification déterministe en temps réel avec une latence de bout en bout mesurable
• Prise en charge matérielle des E/S pour vos bus, capteurs et interfaces d'actionneurs
• Gestion des versions des scénarios, balayages de paramètres et automatisation des tests de régression
• Des limites de validité clairement définies pour les modèles de capteurs et de dynamique, documentées à des fins d'audit
• Enregistrement des données reliant les exigences aux résultats de réussite ou d'échec et aux versions traçables

Erreurs courantes commises par les équipes dans l'utilisation de la simulation ADAS et problèmes qui leur échappent

Les équipes passent à côté de certains problèmes lorsqu'elles considèrent la simulation comme une simple vitrine plutôt que comme un système de test rigoureux. Des graphismes attrayants peuvent masquer une observabilité insuffisante, des exécutions non reproductibles et des dérives de configuration non suivies. La simulation n'est utile que si elle permet de reproduire les défaillances, d'en déterminer la cause profonde et de démontrer que la correction apportée reste valable dans le cadre de variations contrôlées.

Une cause fréquente d'échec réside dans le fait de mélanger des objectifs de validation dont le niveau de fidélité n'est pas adapté. Les tests de planification de haut niveau effectués sur des capteurs idéaux peuvent aboutir à un résultat positif, alors que le contrôleur embarqué échoue dès que des variations de synchronisation et des anomalies d'interface apparaissent. Une autre cause est la prolifération des scénarios, où les équipes accumulent des milliers de cas sans modèle de couverture, de sorte que des lacunes persistent même lorsque le nombre de tests augmente.

Les équipes les plus performantes assurent une coordination étroite entre les spécifications, la conception des scénarios et la qualité des données, puis réservent les rares essais sur route à la validation et à l'étalonnage. C'est précisément ce mode de fonctionnement qu'OPAL-RT vise à soutenir dans la pratique : une simulation déterministe en temps réel qui s'intègre dans un flux de travail en laboratoire, produit des résultats reproductibles et met l'accent sur la validation du comportement du système plutôt que sur l'accumulation de kilomètres.