​Combler une lacune de couverture critique dans la validation des caméras ADAS/AD

Les systèmes avancés d’aide à la conduite basés sur la vision font partie intégrante des véhicules modernes et complètent la vision du monde du véhicule dans le spectre électromagnétique visible. Ils fournissent d’importantes fonctions d’autonomie, améliorant la sécurité routière grâce à la planification automatisée de la trajectoire des véhicules basée sur la détection et la classification d’objets. Au cœur de nombreuses unités de contrôle électronique (ECU) ADAS se trouve un ASIC accélérant le réseau neural (NN) sur les données sensorielles. Mobileye Global, Inc., fournit l’un des chipsets les plus utilisés pour ces sous-systèmes basés sur les réseaux neuronaux.

Pour les constructeurs et les fournisseurs automobiles, la validation et l’homologation de ces systèmes constituent une nouvelle catégorie de défis. Parmi les méthodes classiques d’assurance qualité, seuls les tests sont effectivement applicables aux ECU ADAS basées sur les réseaux neuronaux. De nombreux investissements sont réalisés dans la phase de test avant le début de la production des véhicules. Une approche populaire pour des raisons économiques et de reproductibilité consiste à effectuer des tests fonctionnels dans un environnement de laboratoire, en regroupant les ECU pertinentes dans une configuration hardware-in-the-loop (HIL), alors que le reste du bus du véhicule est simulé. Le stimulus du capteur est ensuite injecté dans les ECU par voie numérique.

​Figure 1 : Architecture typique d’un système de caméra ADAS (simplifiée)

Les ECU ADAS responsables des fonctions de sécurité critiques pour le véhicule doivent diagnostiquer elles-mêmes les défaillances et céder le contrôle du véhicule de manière sûre (sûreté intégrée). Par conséquent, pour une ECU de vision, l’observation de l’état opérationnel du ou des capteurs d’image et la validation du flux vidéo fourni doivent se faire en temps réel.

Les capteurs d’image modernes offrent plusieurs façons de sécuriser les chemins de données vers et depuis le processeur vidéo en aval contre les erreurs : Certains fabricants activent les sommes de contrôle CRC sur les transactions à canal latéral. Le flux vidéo peut être configuré pour inclure des compteurs actifs et des instantanés de l’état de configuration dans l’image. Certains capteurs disposent d’une broche de sortie d’interruption ERROR. La spécification MIPI CSI2 prévoit en outre des gardes CRC et des compteurs de trames au niveau du protocole.

Ces mesures de protection, ainsi que d’autres, sont utilisées pour s’assurer que les véhicules autonomes peuvent céder rapidement le contrôle au conducteur afin d’éviter de suivre une trajectoire fantôme due à des défauts dans la trajectoire de l’image. Le simple fait d’injecter un flux vidéo ou un enregistrement antérieur dans une ECU déclenchera donc le mécanisme de sûreté intégré.

Ce problème est connu depuis le premier jour et la solution évidente était de désactiver complètement la surveillance de l’état du logiciel ECU et la validation de l’état. Cet état est mieux connu sous le nom de « mode HIL » pour les ECU de vision, et il est également pris en charge par Mobileye et d’autres fournisseurs tels que Bosch ou Continental. Bien qu’il s’agisse d’un mécanisme valable pour permettre de tester la couche de perception et des logiciels d’application, l’inconvénient inhérent à cette approche est que la version logicielle testée n’est pas le logiciel qui sera déployé sur le terrain plus tard. Par conséquent, les tests de validation ne prennent pas compte de certaines parties de la couverture des tests, qui ne sont présentes que dans le logiciel de production.

Une solution consiste faire de l’ingénierie inverse et à émuler le comportement du capteur d’images en temps réel pour permettre le test du logiciel de l’ECU dans sa version de production.

​Figure 2 : Vue simplifiée d’un capteur d’images et d’un composant de vision en aval

La figure 2 présente un modèle conceptuel simplifié d’un capteur d’images agissant comme source vidéo et d’un composant de vision connecté comme récepteur vidéo. Au niveau logique, les images numériques sont produites dans le capteur d’images et consommées par le composant de vision.

Chaque image entrante est analysée avant d’être transmise à la couche de perception. Les propriétés spécifiques de l’image, telles que la luminosité moyenne, l’histogramme, etc., sont fournies à un module de contrôle chargé de régler le capteur d’images pour produire des images correctement exposées et adaptées à la classification des objets.

La surveillance de l’état extrait les compteurs actifs et valide l’état de configuration du capteur en extrayant des informations des données embarquées dans l’image. Avec ce module, il est difficile de fournir un flux vidéo générique à l’ECU dans un environnement HIL sans utiliser un logiciel de préversion, comprenant le « mode HIL» de l’ECU.

Un système d’injection doit émuler le comportement de plusieurs sous-composants de capteurs en temps réel pour éviter de déclencher des mesures de sûreté intégrée dans le composant de vision et produire des résultats de test fiables pour les performances de détection.

La simulation de la couche optique est du ressort de l’ordinateur hôte qui génère les données d’entrée du capteur. Dans le cadre des tests de régression en boucle ouverte, un enregistrement antérieur provenant d’une ECU de caméra similaire est rejoué sur le DUT. La génération de données synthétiques en direct à l’aide d’un outil de visualisation permet des tests en boucle fermée pour l’exploration de scénarios, pour les tests fonctionnels et les tests de performance. La qualité des données générées est directement liée à la fidélité du modèle de capteur optique.

Les propriétés optiques qui sont généralement couvertes, à des degrés divers, dans une simulation synthétique sont présentées dans la figure 3.

​Figure 3 : Effets sur la voie opto-électrique

Sur la couche logique, l’essentiel des efforts d’émulation sera généralement dominé par la manipulation d’images numériques en ligne. Certains systèmes de vision permettent au capteur de recadrer dynamiquement l’image et de placer la fenêtre de lecture sur la matrice de pixels actifs. Les capteurs avec filtres de couleur fournissent une amplification individuelle des canaux de couleur pour l’ajustement de la balance des blancs dans des environnements lumineux différents.

L’intensité de la lumière incidente peut parfois dépasser la capacité des photodiodes à capturer toute la gamme dynamique de la scène, en particulier la nuit. Pour augmenter la gamme dynamique capturée, les capteurs modernes permettent plusieurs conversions analogiques/numériques pendant la période d’exposition. Chaque conversion individuelle produit 12 bits d’informations relatives à la luminosité, qui sont ensuite empilées en interne pour former une image numérique finale de 20 bits. Pour économiser la bande passante, l’image 20 bits peut ensuite être compressée en 12 ou 16 bits en utilisant une fonction de transfert non linéaire configurable dynamiquement.

Les processeurs en aval peuvent dépendre des statistiques d’image fournies par le capteur pour contrôler correctement le temps d’exposition. Les capteurs d’image peuvent générer des histogrammes configurables de manière dynamique avec la sortie image.

La couche numérique est façonnée par un protocole de bas niveau et des paramètres électriques. Bien que ces derniers dictent aussi la conception du PCB pour l’interface de l’ECU, les paramètres de configuration pertinents internes au capteur incluent la configuration en ligne du module de communication MIPI CSI-2 et les fréquences d’horloge générées par la boucle à verrouillage de phase (PLL), qui déterminent en fin de compte la fréquence d’images de sortie. De plus, des sorties sensibles du fichier de registre doivent être fournies, telles que les lectures de capteur de température et des indicateurs d’état.

Les systèmes embarqués en temps réel sont soumis à de fortes contraintes de temps (latence et débit) qui doivent être respectées lors de la construction d’interfaces d’instrumentation. En plus d’émuler le capteur d’image sur le plan fonctionnel, il convient de veiller à répondre aux demandes et à fournir des flux de données en respectant les contraintes temporelles du DUT.

Le portefeuille de solutions de NI couvre tous les sujets susmentionnés et fournit des systèmes de test modulaires et personnalisables pour les ECU ADAS/AD (voir la figure 4).

Grâce à un solide réseau de partenaires, NI peut fournir des interfaces d’instrumentation personnalisées pour toutes les ECU, à l’exception de celles qui sont les plus étroitement intégrées.

Le noyau en temps réel de l’émulation IP du capteur d’images est réalisé sur une plate-forme matérielle évolutive haute performance dédiée, capable de fournir plusieurs flux vidéo UHD en parallèle, couvrant ainsi les besoins des systèmes de vision automobile modernes. Par ailleurs, le noyau d’émulation est capable d’insérer délibérément des fautes dans diverses étapes de traitement pour permettre de tester les mécanismes de traitement des erreurs dans le DUT.

Du côté de la simulation, le matériel NI est évolutif et ouvert aux simulations logicielles de tiers qui peuvent être connectées à la boucle via un RDMA bidirectionnel à large bande passante via une liaison de données Converged Ethernet. La compatibilité avec des outils de simulation tiers optionnels est assurée par l’adaptation des sources de données HDMI.

​Figure 4 : Architecture système NI HIL pour l’injection directe de données à l’aide du logiciel de l’ECU en version de production

En résumé, les ECU ADAS, qui sont des systèmes critiques pour la sécurité, utilisent des dispositifs de surveillance d’état qui font de l’injection vidéo une tâche non triviale. Un modèle d’émulation de capteur d’images en temps réel, multicouche et sophistiqué doit être utilisé pour satisfaire aux contrôles de validité dans l’ECU et pour générer des flux vidéo qui induisent un comportement de la couche de perception semblable à celui d’une conduite test dans le monde réel.

La simulation optique sophistiquée et l’émulation en temps réel des capteurs d’images de NI permettent une vérification complète des calculateurs ADAS/AD actuels et futurs basés sur la vision dans le monde entier. Les solutions NI permettent de réaliser des tests de validation basés sur des logiciels de production pour les calculateurs de vision, ce qui comble une lacune dans la couverture qui existait depuis l’introduction du « mode HIL » en utilisant des logiciels de préversion.

• Lire la suite dans le NI Automotive Journal
• En savoir plus sur la manière dont NI innove en matière de validation ADAS/AD
• Explorez les moyens de rationaliser les tests fonctionnels de l’ECU
• Passage à gauche : l’évolution des tests de validation automobile