Innovations en matière de validation ADAS/AD : évolution des architectures HIL chez Valeo en collaboration avec NI

​​Au cœur de la révolution de la mobilité

​Le remplacement des conducteurs humains par des systèmes autonomes avancés est la promesse d’une productivité accrue, d’un plus grand confort et d’une réduction du nombre d’accidents sur nos routes. Cet objectif ambitieux s’accompagne néanmoins de nombreux défis et préoccupations, en particulier en ce qui concerne les problèmes critiques de sécurité et de défaillance des systèmes. Il convient de réaliser des tests complets par rapport à un nombre quasi infini de scénarios en situation réelle pour parvenir à une automatisation supérieure des véhicules.

Pour relever ce défi, les constructeurs automobiles s’efforcent de développer sans cesse des technologies et des stratégies de test de validation. Valeo, l’un des leaders mondiaux des solutions technologiques pour l’automobile, compte parmi les entreprises qui s’y consacrent. La société a joué un rôle de pionnier en façonnant le paysage de l’électrification, des systèmes avancés d’aide à la conduite (ADAS) et de la conduite autonome (AD). Marquée par une tradition d’innovation et un engagement à fournir des solutions de pointe, la collaboration entre Valeo et NI évolue sans cesse vers un avenir plus sûr.

Présentation de l’ADAS et du stationnement automatisé (AP)

​À mesure que la complexité des systèmes ADAS augmente, il devient de plus en plus difficile de tester ces systèmes uniquement sur des véhicules réels. La validation virtuelle progresse dans le secteur, car il faut réduire la durée et les coûts des tests, sans oublier la capacité à tester des scénarios extrêmes difficiles à mettre en œuvre dans des conditions réelles.

​Ce défi est plus que d’actualité pour les systèmes AP. Ils s’appuient en effet sur la fusion de capteurs pour créer une carte virtuelle de l’environnement du véhicule afin de réaliser des manœuvres de stationnement autonomes. Une validation approfondie est nécessaire compte tenu de la complexité de ces systèmes. Cela implique des milliers de cas de test pour chaque version du logiciel. Cependant, il est souvent impossible de tester l’ensemble du système dans le véhicule cible qui est rarement disponible avant son lancement sur le marché.

Figure 1 : ^{Architecture de l’unité de commande électronique (ECU) de stationnement automatisé Valeo}

​

​Pour surmonter ces défis, l’équipe Driving Vision Systems (DVS) de Valeo s’appuie sur une approche de test complète basée sur la technologie hardware-in-the-loop (HIL) en boucle ouverte et fermée. Il s’agit de tester le logiciel en cours d’exécution sur l’unité de commande électronique (ECU) à l’extérieur du véhicule, à l’aide d’un banc de tests dédié au sein du laboratoire :

• ​Open-Loop Replay HIL : cette méthode consiste à injecter dans l’ECU des données préenregistrées réelles sur les routes. Elle est principalement utilisée pour tester les algorithmes de vision artificielle et les taux de détection.
• ​Closed-Loop Virtual HIL : les données synthétiques des capteurs sont générées et introduites dans l’ECU. Cette configuration permet d’obtenir une rétroaction de l’ECU et de simuler avec précision le comportement du véhicule.

​Les tests embarqués permettent d’obtenir des dynamiques et des environnements réels, mais ils sont coûteux, chronophages et soumis à diverses contraintes. Les tests HIL virtuels présentent également des avantages en termes d’évolutivité, d’automatisation et de rentabilité, mais ils ne sont pas aussi réalistes que les scénarios réels. Il est important de noter que plus la fidélité de votre environnement de simulation augmente, plus vos tests HIL se rapprochent de la réalité.

​Le rôle de l’équipe DVS de Valeo

L’équipe DVS de Valeo joue un rôle crucial dans le développement de systèmes de vision panoramique pour les véhicules grâce aux caméras automobiles dotées d’objectifs fisheye, aux capteurs à ultrasons et aux ECU. Ces systèmes font partie des fonctions AP et d’aide à la conduite. L’équipe Test Tools and Infrastructure de Valeo est chargée de fournir des outils de validation tout au long du cycle de développement des produits, depuis la conception en R&D jusqu’à l’enregistrement dans le véhicule, les tests HIL et de fin de ligne (EOL) en production.

Évolution des architectures HIL dans la validation des ADAS/AD

​Le paysage dynamique dans ce domaine a favorisé l’évolution continue des architectures HIL. Ces systèmes se sont adaptés pour répondre aux besoins changeants de l’industrie, ce qui permet de s’assurer qu’ils restent à la pointe des nouvelles avancées technologiques et des exigences toujours plus pointues.

​L’équipe DVS de Valeo utilise actuellement trois architectures HIL développées en collaboration avec NI, chacune apportant des capacités de test uniques.

​Interface d’extension multisystème (MXI) basée sur HIL

​Cette première génération du système HIL développé par l’équipe DVS de Valeo utilise un moteur de simulation interne appelé Vosstrex, qui est adapté à l’ensemble des capteurs de Valeo. Le système se compose de différents modèles de caméra avec objectif fisheye et de capteurs à ultrasons qui transmettent les données synthétiques du PC de simulation basé sur Windows au système PXI de NI et à l’ECU.

​Cela signifie très spécifiquement qu’ils restituent les données synthétiques à partir du moteur de simulation sur le capteur de la caméra ; les données passent par une communication entre processus vers une application LabVIEW, puis vers le système NI PXI à l’aide de MXI-Express. Dans le système PXI, les FPGA FlexRIO servent d’interface entre le logiciel et le matériel et émulent les signaux authentiques de la caméra et les données de bas niveau qui sont ensuite transmises à l’ECU.

^{Figure 2 : Diagramme représentant l’architecture HIL basée sur la boucle fermée MXI}

​L’architecture répond efficacement à leur principal cas d’utilisation, à savoir les manœuvres à faible vitesse comme le stationnement, ce qui convient bien à leurs besoins spécifiques. En outre, leur simulation Vosstrex constitue une base solide pour de futures améliorations tout en offrant une fidélité visuelle suffisante.

​Cette architecture fait toutefois face à certains défis. Le principal est la limitation du débit de l’interface MXI, ce qui restreint les taux de transfert de données. L’absence de synchronisation temporelle entre les trois composants clés (caméras, données ultrasons et statistiques du véhicule) constitue elle aussi une limite. Malgré ces défis, le système reste fonctionnel pour les applications à faible vitesse prévues et les progrès des moteurs de simulation tiers offrent des possibilités de simulation encore plus réalistes pour l’avenir.

​Valeo dispose actuellement d’une cinquantaine de testeurs HIL répartis sur neuf sites de la société dans le monde qui servent à réaliser des tests pour plus de 12 projets OEM. Ce système HIL a permis d’établir un framework de validation du dispositif à un stade précoce du projet et a donné à Valeo la pleine propriété du code source. La capacité de développement dans LabVIEW permet d’améliorer encore l’ensemble du système, y compris l’implémentation FPGA et le moteur de simulation, au fil de l’évolution des projets.

^{​Figure 3 : Ferme HIL sur le site de Valeo}

​HIL basé sur HDMI

​La nécessité de faire évoluer le système d’architecture HIL basé sur MXI est née d’une exigence d’un OEM européen de premier plan. Il souhaitait notamment simuler 12 caméras à haute résolution, ce qui implique de quadrupler la bande passante du système précédent et d’utiliser deux moteurs de simulation différents exécutés sous Linux. Les partenaires NI et Valeo ont conçu une solution qui répond à ces critères.

^{Figure 4 : Architecture de simulation dotée de douze caméras}

La configuration de la Figure 4 utilise 4 PC et 12 cartes graphiques, chaque GPU étant dédié à la simulation d’une caméra individuelle. Un PC basé sur Linux exécute la simulation ainsi que le modèle de capteur de caméra pour chacun de ces 12 dispositifs. Les sorties physiques du GPU sont reliées aux FPGA PXI à l’aide de connexions HDMI, ce qui nécessite plusieurs conversions dans ce chemin de transmission. Cette configuration comprend notamment une conversion initiale de HDMI à Serial Digital Interface (SDI), suivie d’une conversion ultérieure de SDI à MIPI CSI. Un FPGA supplémentaire est introduit dans le flux de travail afin de faciliter le processus de conversion. Une fois ces conversions terminées, les données peuvent être transmises à l’interface vidéo automobile pour FPD-Link III (PXIe-1486) et GMSL2 (PXIe-1487), les FPGA servant d’interfaces logicielles-matérielles cruciales pour l’émulation des signaux des capteurs qui jouent le rôle d’entrées à l’ECU.

^{​Figure 5 : Simulation de capteur de caméra basé sur HDMI}

Pour ce qui est de la bande passante, le système fonctionne à une vitesse de 4,5 gigaoctets par seconde afin d’injecter des données vidéo dans l’ECU. L’un des avantages notables de cette configuration est son agnosticisme en matière de simulation. Bien que dans ce cas le moteur de simulation basé sur Linux soit utilisé, le même chemin de données pourrait prendre en charge des données issues d’autres fournisseurs de simulation. Le FPGA supplémentaire requis pour la conversion HDMI->SDI accroît les coûts, mais il ajoute également la capacité de traitement supplémentaire des données d’image dans ce nouveau chemin de données. 

Cette configuration s’accompagne toutefois de certaines limites. La première est que l’interface HDMI présente des difficultés, car elle nécessite une chaîne d’outils de conversion assez complexe pour passer de HDMI à SDI, puis à CSI. Elle présente finalement les mêmes limites que la configuration précédente, à savoir qu’il n’y a pas de synchronisation entre les données de la caméra et les ultrasons ou la simulation supplémentaire du bus du véhicule. Plus important encore, ce système HIL ne peut pas être utilisé efficacement comme un système HIL de relecture en boucle ouverte. Il n’est donc pas adapté à la relecture de données pré-capturées à l’aide des GPU.

^{​Figure 6 : Architecture en pipeline d’injection vidéo}

HIL basé sur RDMA

La dernière génération proposée par NI est appelée système HIL RDMA et elle utilise l’accès direct et distant à la mémoire sur Ethernet convergent (RoCE). Ce système s’appuie sur RDMA, une interface utilisée pour l’échange transparent de données entre le PC hôte et NI PXI. RDMA établit une connexion basée sur Ethernet qui facilite le transfert de données vidéo avec une faible latence et une large bande passante. Il n’est donc plus nécessaire de copier la mémoire et un lien direct est établi entre la mémoire de l’ordinateur et celle du contrôleur en temps réel PXI. D’un point de vue architectural de haut niveau, le flux de données part du PC de simulation, puis il est transmis par RDMA au contrôleur en temps réel PXI situé dans un châssis PXI qui abrite les FPGA nécessaires à l’alimentation de l’ECU. Ce système fonctionne dans une configuration en boucle ouverte et fermée, ce qui permet de rejouer les données capturées au préalable et d’intégrer le retour d’information dans le contrôleur en temps réel.

^{Figure 7 : Relecture en boucle ouverte RDMA HIL}

Cette architecture offre les performances de débit les plus élevées observées à ce jour, avec un seul module RDMA capable de fournir jusqu’à 6,25 gigaoctets par seconde de transfert de données. Un autre avantage important réside dans l’architecture unifiée pour les configurations HIL en boucle ouverte et fermée : la distinction tourne principalement autour de la sélection de la source de données, qu’elle provienne de fichiers de stockage ou d’une simulation, ce qui favorise la réutilisation. Le principal avantage réside toutefois dans l’introduction de mécanismes de synchronisation précis qui permettent d’aligner les données vidéo de manière transparente sur les signaux du bus du véhicule. Cette synchronisation s’étend au-delà des caméras et couvre divers capteurs et permet d’obtenir un ensemble de données complet et synchronisé. Valeo, par exemple, évalue activement l’incorporation de ces systèmes HIL susceptibles de remplacer les systèmes HIL MXI existants dans le cadre de sa stratégie future.

Il convient toutefois de prendre certains facteurs en compte lors de l’utilisation de RDMA. Votre moteur de simulation doit être compatible avec RDMA, ce qui nécessite l’appel d’une bibliothèque DLL client RDMA à partir du moteur de simulation. Si l’intégration d’une DLL externe à votre moteur de simulation est impossible, vous pouvez également utiliser des convertisseurs HDMI-to-RDMA. Cette approche crée essentiellement une configuration hybride qui combine des éléments de la configuration précédente. Elle présente toutefois l’inconvénient d’introduire une latence et une variation en plus liées à l’étape de conversion supplémentaire (HDMI-to-RDMA).

Solution complète : kit de développement logiciel NI AD (SDK)

Le système HIL basé sur RDMA de NI est conçu pour s’adapter aux simulateurs et répondre à toutes les exigences des clients. C’est l’utilisation du kit de développement logiciel (SDK) NI AD qui permet cette polyvalence. Le kit de développement logiciel (SDK) facilite l’intégration rapide entre les logiciels d’émulation de bus et de simulation des capteurs. Le kit de développement logiciel AD fourni est un ensemble de plug-ins qui offrent une interface cohérente et simplifie l’intégration entre le fournisseur du simulateur et le système HIL AD. S’appuyant sur LabVIEW et le support gRPC, le kit de développement logiciel propose une API de simulation et une interface bien définie pour une intégration transparente. Grâce à cette approche, les sociétés de simulation tierces travaillent avec leurs outils habituels et créent des points de test simples qui prennent en charge les processus de mise au point et de CI/CD. Cela contribue simplifie la communication entre le logiciel de simulation et le système HIL ADAS. L’utilisateur final peut ainsi choisir le fournisseur de simulateur auquel il souhaite faire appel.

Collaboration entre NI et Valeo

Le partenariat entre NI et Valeo se traduit par une collaboration en R&D, un accès anticipé aux prototypes NI, des services d’ingénierie et le développement d’un système HIL clé en main. Cette collaboration a permis à Valeo de rester à la pointe de la validation ADAS.

Grâce à la plate-forme PXI de NI, l’équipe Valeo bénéficie de systèmes de validation standardisés dans le monde entier et réutilise les composants de test en tirant parti de la modularité, de la synchronisation temporelle précise et de la prise en charge des interfaces automobiles essentielles fournies par la plate-forme.

Conclusion

L’évolution des systèmes HIL chez Valeo, en collaboration avec NI, montre qu’il est essentiel d’adapter les méthodologies de test pour relever les défis posés par des systèmes ADAS/AD de plus en plus complexes. Le système HIL basé sur RDMA représente une avancée significative, car il offre un débit élevé et des capacités de synchronisation. Valeo s’engage encore et toujours à exploiter les systèmes NI pour répondre aux besoins changeants de la validation ADAS/AD, afin de garantir la satisfaction de ses clients dans une industrie automobile en constante évolution.

La marque déposée Linux® est utilisée selon les termes d’une sous-licence de LMI, le détenteur exclusif de la licence de Linus Torvalds, propriétaire de la marque au niveau mondial.