Avec les systèmes qui dépendent de capteurs d’environnement, il est possible de rencontrer des situations débouchant sur des violations des objectifs de sécurité malgré un système pourtant exempt de dysfonctionnement au sens des aléas matériels ou de défauts systématiques. En effet, dans un environnement ouvert, et en fonction du cas d’usage et du contexte opérationnel, il est possible qu’une source extérieure au système vienne bruiter le signal perçu par le capteur ou encore que l’algorithme de traitement n’interprète pas correctement son environnement et prenne une décision dangereuse. Les exemples sont nombreux, comme avec les variations de luminosité pour les capteurs optiques (caméras) ou la réflexion des ondes sur des objets métalliques dans le cas des radars.
Au regard de l’infinité des potentielles situations, ce constat pose la question de l’exhaustivité des tests, ou en tout cas de la couverture suffisante pour démonter l’atteinte des objectifs de sécurité, dans les différentes phases de conception et de validation. Face à ce défi, l’idée d’utiliser des environnements simulés permettant d’appliquer une variabilité sur les différents paramètres et de construire un plan d’expérience semble donc adaptée dans une approche complémentaire aux essais physiques en environnement ouverts ou sur des pistes contrôlées. Néanmoins cette solution n’est pas exempte de difficultés, et plusieurs facteurs sont à prendre en compte, ce qui implique une réflexion plus approfondie dont nous allons donner un aperçu dans cet article.
Le test des systèmes par simulateur
Une première approche Hardware In the Loop / Vehicle in the Loop (HIL/VIL) consiste à tester les systèmes de perception de façon réaliste, non pas au travers des essais physiques (roulages) mais à l’aide d’un simulateur. Ces dispositifs sont conditionnés par la possibilité de réaliser des stimuli capables de leurrer les capteurs de perception. Pour au moins deux capteurs, les radars et caméras, des avancées récentes semblent permettre de fournir de tels stimuli.
Cette approche a été choisie par l’Université de Warwick dans « Drive-in, Driver-in-the-loop, multi-axis driving simulator (3xD) », où on y émule l’environnement avec de vrais véhicules et de vrais humains en temps réel. Dans cette approche, la difficulté consiste à recréer totalement un environnement simulé et cohérent. En effet, le dispositif devra dérouler des scènes filmées, fournir au système véhicule sous test le scan 3d-Lidar de la scène enregistrée dans un flux synchronisé avec le film, émuler les signaux radios (3G/4G, WLAN, etc.) reçus et disposer d’un système permettant de contrôler les capteurs, par exemple le GPS afin de contrôler la localisation du véhicule en temps réel.
Même dans l’hypothèse où toutes ces conditions sont rencontrées et le simulateur HIL/VIL opérationnel, le fait que les capteurs optiques du véhicule se comportent de la même façon face au simulateur et dans les conditions réelles reste à démontrer.
Cette approche nécessite de dépenser une énergie considérable à recréer un environnement réaliste sans pour autant valider le comportement du véhicule autonome dans des situations non prévues à l’avance. Néanmoins, elle présente l’avantage d’éviter des roulages et offre surtout la possibilité de « rejouer » les scènes dans un environnement répétable et instrumenté, avec différents systèmes sous tests.
Afin de bénéficier des avantages d’une option entièrement numérique pour assurer la variabilité des tests dans les phases de conception, il existe une approche qui nécessite de développer des modèles pour l’environnement, les capteurs et les systèmes à tester. La validation du système peut intervenir très tôt dans le cycle de conception (MIL, Model In the Loop) afin de valider les spécifications des systèmes autonomes. Elle implique de disposer de la spécification du système, des modèles des lois de commandes construites sur base de la spécification et des modèles des capteurs utilisés. On pourra ainsi vérifier que le comportement dynamique du système véhicule est bien le comportement spécifié pour les systèmes d’aide à la conduite dans tous les « Contextes Opérationnels ».
La question du modèle d’environnement réaliste peut être posée comme dans l’approche HIL/VIL. Néanmoins dans cette approche entièrement numérique, on se passe des capteurs physiques pour fournir au modèle du capteur la sémantique des informations nécessaires sans nécessairement avoir besoin de créer des scènes réalistes. En effet, si le modèle de capteur est qualifié correctement, on peut introduire les perturbations nécessaires à la demande.
L’importance du contexte opérationnel
Lors du voyage d’étude avec les membres du groupe de travail « moyens d’essais et homologation » du plan Véhicule Autonome France, organisé par Business France et CARA, j’ai eu à la fois l’opportunité de visiter plusieurs sites d’essais comme Gomentum à côté de San-Francisco et j’ai également eu la chance de discuter avec le Pr. Stephen E. Shladover à Berkeley, de l’importance du concept de « Contexte Opérationnel », connu en anglais sous le terme Operational Design Domain (ODD).
Le concept d’ODD est essentiel puisqu’il permet de définir dans quelles conditions le système a été conçu pour permettre l’automatisation de la conduite. Il permet donc de spécifier les conditions opérationnelles à valider. Ce concept recouvre les dimensions du contexte : conditions climatiques, de luminosité ou l’exigence sur le parcours, etc. Pour bien comprendre ce concept, le niveau ultime de l’automatisation de la conduite (niveau 5) signifie que le véhicule devra être capable de rouler « partout et en toutes circonstances, par tous les temps sur n’importe quelle route, chemin ». Il existe dans l’industrie une grande confusion autour de cette définition des niveaux d’automatisation. Certains acteurs dans une volonté de simplification ou de positionnement marketing ayant associé le niveau 5 à un véhicule sans volant et sans pédales… alors qu’il s’agit en général d’un robot avec un niveau 4 et un ODD très limité. Autant dire que personne ne travaille aujourd’hui sur le niveau 5.
Note : Le Pr. Stephen E. Shladover, est un des pionnier des ITS (Intelligent Transportation Systems) et a participé à la création du “California PATH”, le premier programme de recherche aux Etat Unis sur les ITS en 1986. Il est aussi un des rédacteurs de la norme SAE avec les 5 niveaux d’autonomie. Pour en savoir plus : http://www.path.berkeley.edu/
Vers des modèles probabilistes de perturbation
Le problème est alors déporté sur la représentativité de ces modèles. En effet, cette approche nécessite d’abord de disposer de modèles de capteurs qualifiés qui soient représentatifs du comportement des capteurs… y compris face à des perturbations. C’est un premier verrou que le projet Simulation pour la sécurité du Véhicule Autonome (SVA) de l’IRT SystemX tente d’adresser aujourd’hui pour les capteurs optiques et les radars afin de mettre au point des modèles probabilistes de perturbation.
Afin de mettre au point les modèles qualifiés avec un niveau de représentativité maximal, il apparaît nécessaire de pouvoir « Court-Circuiter » la partie physique des capteurs à modéliser pour alimenter directement l’algorithme de traitement à partir d’un environnement émulé, sous réserve de disposer de ce module fournisseur ce qui n’est pas le cas aujourd’hui. Ceci nous permettrait de construire des modèles probabilistes ou éventuellement d’exploiter directement ces modules probablement sous réserve des contraintes du temps réel.
Dans le cas où on ne dispose pas de cet accès direct à la couche de traitement, un modèle « oracle » ou boite noire du capteur pourra être mis au point, ce travail est actuellement en cours pour la caméra. On peut imaginer que les équipementiers pourraient eux-mêmes fournir des modèles de capteurs qualifiés permettant de les tester en MIL.
L’avantage considérable de cette approche est l’aspect temporel et parallélisable des tests. Il devient possible d’imaginer informatiquement un passage à l’échelle massif afin de jouer des milliards de tests en continu.
Afin que ces tests soient représentatifs des conditions opérationnelles réelles, on peut s’appuyer sur les retours d’expériences des essais physiques sur pistes ou sur routes ouvertes afin de collecter les paramètres et d’avoir une approche probabiliste de leur distribution selon les cas d’usage.
Dans une approche numérique, les cas d’usage servant à la validation du véhicule autonome sont construits soit à partir de situations créées dans la phase de conception du système, soit à partir de retours d’expériences. En Allemagne, une forte activité est déployée pour définir et créer une base de données regroupant des cas tests. Notamment au travers du projet PEGASUS qui vise à définir les scénarios à risque à tester en simulation : les accidents répertoriés en Allemagne (Base GIDAS) servent de sources de données, permettant la reconstruction des scénarios dans un environnement de synthèse (IPG Carmaker).
La méthodologie développée dans le projet SVA de l’IRT SystemX et des partenaires (All4Tec, Apsys, Assystem, CEA, Continental, Inria, LNE, Optis, Oktal, PSA Peugeot Citroën, Renault, Sector, Université de Versailles Saint-Quentin-en-Yvelines, Valeo) consiste à construire une bibliothèque de scénarios et de terrains associés. Ces scénarios sont ensuite instanciés pour valider le système à tester comme par exemple un Traffic Jam chauffeur ou un Highway Pilot. Cette instanciation en fonction du système et de la variabilité de l’environnement permet de constituer les fiches de test pour la validation MIL (Model in the Loop), SIL (Software In the loop) et HIL (Hardware in the Loop).
Des systèmes automatisés d’aide à la conduite tels que Traffic Jam Chauffeur et Highway Pilot ne sont pas conçus pour le même contexte opérationnel (ODD) et leur validation doit être adaptée : dans le cas du Traffic Jam Chauffeur, on spécifie la vitesse maximale à 70km/h autorisant donc en cas de problème une manœuvre de mise en sécurité par un simple arrêt sur la voie de circulation.
La bibliothèque de scénarios de tests pour la voiture autonome, construite dans le cadre du projet SVA, est partiellement fondée sur les scénarios fonctionnels de haut niveau spécifiés par des experts décrivant les situations auxquelles le véhicule sera confronté (cut-in, insertion, etc.). Une étude de sensibilité des paramètres permet de produire des scénarios logiques avec une variabilité cohérente à partir d’une situation initiale donnée.
Le projet SVA complète la construction des scénarios de haut niveau décrits ci-dessus par des scénarios issus des enregistrements réalisés sur route (projet Moove de VEDECOM) et de la base d’accidentologie « VOIESUR » mise à jour régulièrement par le LAB et le CEESAR. L’analyse de ces enregistrements et l’exploitation des bases d’accidentologie fournissent des données statistiques sur la répartition des paramètres laissés variables dans les descriptions de haut niveau, comme par exemple : les positions des marquages et des acteurs ainsi que les vitesses et les accélérations des acteurs. Ces données statistiques permettent de mettre au point des scénarios concrets, en fixant l’ensemble des paramètres, pour réaliser des simulations représentatives.
Par ailleurs, le projet SVA propose une approche formelle complémentaire qui vise à générer automatiquement des cas tests à partir d’une formalisation mathématique et d’une analyse comportementale en sûreté de fonctionnement.
« Tests augmentés » et stratégie industrielle de validation tout au long du cycle de conception
Un challenge supplémentaire est de tester les décisions prisent par l’AD (Automated Driving) qui peuvent avoir une influence sur le comportement du véhicule (piloté par l’AD) dans son environnement. Il faut alors introduire une rétroaction. En effet dans ce cas, suivant le comportement du véhicule (piloté par l’AD) dans l’environnement les données fournies par les capteurs peuvent varier. Par exemple, si les données utilisées vont servir à détecter si le système demande un freinage d’urgence ou non dans une situation donnée, il n’est pas nécessaire de mettre en place une boucle de rétroaction. Cependant, si on veut suivre l’évolution dans le temps, par exemple suivre comment l’AD suit le véhicule qui le précède, il faut mettre en place une boucle de rétroaction qui permet de réinjecter, de façon itérative et selon un pas de temps donné, la vitesse du véhicule sous test dans la simulation de l’environnement afin d’adapter le comportement des acteurs aux consignes données par le système de décision.
Finalement, on devra se poser plusieurs questions avant de se lancer dans une virtualisation des essais pour les systèmes de conduite automatisés :
- Le système sous test est-il une boite noire : intègre t’il les capteurs et la fusion des données de façon modulaire ?
- Est-il possible d’injecter des données au niveau du traitement du signal des capteurs et d’accéder aux données qui seront fournies à l’AD avant la phase de fusion ?
Selon quel domaine/context (ODD) doit on valider la “Safety of the Intended Function” (SOTIF) ?
Il existe bien entendu une multitude d’options visant à offrir un « mix » entre l’approche MIL et HIL afin de remplacer, au fur et à mesure de la maturité des systèmes à tester, les modèles par des capteurs. Dans ces approches hybrides, il conviendra de toujours se poser la question de la représentativité de la réaction des capteurs face à une scène simulée.
Dans l’hypothèse où l’on parvient à intégrer des perturbations représentatives ou des obstacles virtuels réalistes dans des scènes numériques issues d’essais réels afin de réaliser une validation, on pourrait alors parler de « Augmented testing »/« Tests Augmentés » comme on parle déjà de « Augmented reality »/«Réalité augmentée ».
Il apparaît que Waymo met au point un système de simulation entièrement numérique permettant de plus de produire une variabilité des scènes virtuelles à partir de situations et de données enregistrées. Ils annoncent ainsi faire fonctionner 25 000 voitures virtuelles sur les rues numérisées d’Austin, de Phoenix et de Mountain View. D’après eux toujours, ces simulations réalisent chaque jour près de 13 millions de kilomètres. Soit au total 4 milliards de kilomètres ont été parcourus en 2016. En comparaison, les voitures de tests n’ont roulé que 5 millions de kilomètres pendant la même période.
Il semble donc que Google combine des données récupérées sur route avec celle provenant de pistes en fonction des scenarios qui posent problèmes à ces voitures. Une fois suffisamment de données emmagasinées, les ingénieurs fabriquent un environnement spécifique pour y entrainer le logiciel.
De quoi étudier des cas de figures inimaginable sur route : vitesse élevée, accidents, milieu urbain très dense… comportement irrationnels d’autres conducteurs.
Sur la base de ce principe il devient imaginable de numériser des environnements classiques et de se focaliser sur les zones géographiques ou les contextes opérationnels (jour, nuit, météo) étant les plus intéressants au sens de l’incidentologie.
À la suite de l’accident impliquant un véhicule Uber en Arizona en mars 2018, le CEO de Waymo a donné quelques chiffres intéressants sur le nombre de kilomètres entre 2 reprises en mains avec en moyenne 1 reprise en main tous les 5600 miles contre 1 tous les 13 miles pour le véhicule Uber.
Le nombre et la qualité (et le coût) des capteurs est certainement à l’origine de cet extraordinaire écart avec 7 lidars, 7 radars, et 20 caméras pour Waymo contre 1 lidar, 10 radars et 7 caméras pour le véhicule Volvo modifié par Uber.
Néanmoins, on peut aussi légitimement poser la question de l’influence de la méthodologie de « simulation augmentée » sur l’amélioration des performances de Waymo en matière de reprise en main.
La stratégie de validation des véhicules autonomes passera par une articulation fine entre les essais sur route ouverte, les tests virtuels et essais sur pistes contrôlées.
