Véhicule autonome : Mentor croit en la fusion de données brutes de capteurs, centralisée sur FPGA

Dans la course technologique actuelle qui se tient autour de la conception des futurs systèmes de contrôle embarqués dans les véhicules autonomes, Mentor, désormais dans le giron de Siemens, apporte sa pierre à l’édifice ...en proposant une plate-forme de développement et de prototypage matériel/logiciel bâtie sur une approche en rupture avec les solutions traditionnelles.

Sur cette plate-forme du nom de DRS360, l'éditeur parie sur une architecture centralisée où un FPGA traite en temps réel et à haute vitesse des données brutes issues de divers capteurs (caméras, radars, lidars…) ; c’est l’opération dite de fusion de capteurs. Une fois ce traitement réalisé via des blocs d’IP implantés au sein du FPGA, ce dernier envoie les données prétraitées vers des processeurs ou SoC en charge d’exécuter des algorithmes propres aux systèmes d’aide à la conduite automatisés (ADAS, Advanced Driver Assistance Systems), y compris des logiciels d’apprentissage automatique profond (deep learning) bâtis sur une approche neuronale. En fin de chaîne, des microcontrôleurs ont pour tâche de mettre à profit les informations issues de ces algorithmes pour gérer les fonctions sécurisées de commande des organes de conduite du véhicule (accélération, freinage, actions sur les roues…).

Cette approche, on le voit, repose sur la mise en œuvre d’un FPGA centralisé, clé de voûte du système, en l’occurrence ici, dans cette première version de la DRS360, un circuit MPSoC Zynq UltraScale+ de Xilinx gravé en technologie 16 nm. Un circuit qui combine matrice de FPGA, processeur quadricœur 64 bits ARM Cortex-A53 cadencé à 1,5 GHz, sous-système temps réel à double cœur ARM Cortex-R5, moteur de gestion de la sécurité, unité graphique ARM Mali-400MP et codec vidéo H.265.

Cette architecture prônée par Mentor vise, selon la société, à réaliser une véritable fusion des données brutes issues des capteurs alors que, dans les architectures distribuées où chaque capteur possède sa propre unité de traitement en local, il y a une déperdition d’informations qui amène à une moindre précision dans les calculs qui suivent. Sans compter, toujours selon l'Américain, qu’avec ces architectures distribuées les temps de latence liés au réseau embarqué utilisé (Ethernet temps réel par exemple) sont importants et nuisent à la réactivité du système global.

Enfin, Mentor souligne qu’en ne s’intéressant pas aux données brutes des capteurs, mais à des données déjà prétraitées, les résultats des algorithmes de fusion de données manquent de précision et de fiabilité, affectant de fait la sécurité d’un véhicule autonome. De ce point de vue, l'éditeur affirme d’ailleurs que sa plate-forme est conçue nativement pour faciliter le respect des exigences de sûreté des voitures autonomes liées aux spécifications ISO 26262 Asil D.

 

Cette vision pose toutefois quelques questions sur la réalisation concrète de la solution dans une perspective industrielle. On peut se demander notamment quelle technologie sera mise en œuvre au niveau des liens haute vitesse entre les capteurs issus de divers constructeurs et le FPGA, ainsi qu’entre le FPGA et les processeurs en charge des logiciels de traitement des données. Ensuite, même si Mentor met l’accent sur la relative sobriété énergétique d’une telle approche au niveau global, un MPSoC Zynq consomme environ 100 W, une valeur qui semble incompatible avec un système embarqué dans un véhicule autonome produit à des millions d'exemplaires. De plus, d’autres types d’architectures de calcul pourraient se prévaloir de se poser en alternatives crédibles, comme par exemple les processeurs massivement multicoeurs du français Kalray qui s’intéresse de près à ce marché des véhicules autonomes. A suivre donc.