Reflections on the future of automated driving safety homologation/certification have been very active recently, based on the general consensus that existing validation approaches have to be significantly modified. At the United Nation level, a dedicated group has been set up on Automated and Connected Vehicles named VMAD (WP29/GRVA/VMAD). At the EU level, the Commission has launched a working group on the future of approvals approaches, led by the Joint Research Center.
This paper, presented at VMAD meeting on January 2020, is a French contribution to on-going reflections on automated driving safety homologation/certification. It has been written by experts from the French authorities in charge of vehicle regulation and transports, in concertation with the French automated driving eco-system, i.e. “France Véhicules Autonomes”. Though this concertation is still on going, so that this document is still a draft, it provides some background to feed ongoing reflections on new homologation/certification approaches and try to cover as many Automated Driving Systems types (e.g. Traffic Jam Chauffeur Level 3, Urban Shuttle L4, Valet Parking L4 etc) as possible.
Artificial Intelligence is becoming ubiquitous in today’s world. One of the most impacted sectors, a major field of study at IRT SystemX, is Autonomous Transportation. While autonomous cars have garnered the most media attention, trains have recently joined the race towards autonomy. In this blogpost, we present the challenges that the rail industry must defeat in order to make driverless trains a reality.
Take a look at the timeline of fundamentally important discoveries and inventions which have changed the course of history. It is straightforward to pinpoint the most disruptive ones. As the consensus would have it, the top of the list features, in chronological order, fire, the wheel, and electricity.
Merely a century and a half after the invention of the light bulb, our world is witnessing a new revolution through the medium of technology. Forget science fiction. According to Andrew Ng, one of the world’s leading figures in Artificial Intelligence (AI) development, « AI is the new electricity ». Just as 100 years ago electricity transformed industry after industry, AI’s impact on our daily life grows by the second and is becoming preponderant. A recent report by PwC estimates that AI will add $15 trillion to the world economy by 2030.
AI’s Projected Impact on Global GDP
One of the most impacted sectors, a major field of study at IRT SystemX, is Autonomous Transportation. The multiplicity of projects involving autonomous vehicles around the world attest to the fact that there is a marked tendency towards automating our daily tasks and making our lives easier thanks to intelligent technology. Therefore, it is of no surprise to read that the autonomous car industry is set to be worth $6.2 trillion euros in 2050.
Cars are far from being the only vehicle of interest in the quest towards automation: trains have recently joined the race. According to the Transparency Market Research, the market for autonomous trains will grow at a CAGR[1] of 12.70% by 2025. Even though trains are behind time in terms of vehicular automation, there is a crude sense of excitement when learning about the initiatives being spearheaded at national and international levels:
The German Railways (Deutsche Bahn) is planning to make a portion of its network fully autonomous by 2023.
The Swiss Federal Railways (SBB) and the Südostbahn AG (SOB) have already tested automation technologies without passengers.
East Japan Railway is confident of successfully running driverless trains in the future.
Last, but not least, France’s national railway company SNCF expects to see semi-autonomous trains running on the French rail network by 2020 and fully automatic trains within five years, following the establishment of two consortia of suppliers and research institutes to develop and implement the technology.
As it happens, SNCF, along with Alstom, Systra and Université de Technologie de Compiègne (UTC), has partnered with IRT SystemX on the TAS project (Safe Autonomous Land Transport) in order to provide a proof of concept for the replication of a train driver’s observational capabilities. The project, launched in April 2017 for a two-year period, focuses on recognizing the state of railway traffic lights, and detecting obstacles on the railway. Note that the content of this article does not reflect the results of the project.
SNCF Train
According to the International Association of Public Transport, there are four Grades of Automation (GoA) of trains:
GoA1: The first grade is manual train operation, where the train driver controls starting and stopping, operation of doors and handling of emergencies or sudden diversions.
GoA2: The second handles operations like changing tracks, starting, and stopping.
GoA3: The third grade is driverless train operation where there are no drivers, but an attendant is onboard in order to take control in case of an emergency.
GoA4: Finally, the fourth grade corresponds to unattended train operation, which is true automation without any staff on board.
Trains’ Grades of Automation (GoA)
In order to achieve full autonomy, trains will be equipped with advanced (and/or intelligent) cameras, high-precision sensors, and state-of-the-art positioning systems. These components may feature AI technology and Machine Learning capabilities that should comply with safety requirements.
Readers of this blog who are well versed in autonomous cars, may think that the presence of railways renders the challenge easier. Not so quick! Multiple factors make the train a unique problem, which cannot be solved by a simple transposition of the solutions found for other types of vehicles. Here are some illustrative examples:
One of the main difficulties lies in the complex interaction of the various subsystems when the train is running: monitoring the status of the railway track, the position of other trains and the physical integrity of the train, and determining the space required to brake safely. If any subsystem cannot judge the situation accurately, it will perform defensively by slowing or stopping, which hinders transport performance.
The variability of use cases in the rail industry is much more important than for cars:
Railway signalling in France
Railway signalling is diverse and features multiple types of signals and state combinations. For example, a signalling device of type ‘H’ is configured to show up-to 18 different states, using eight light bulbs.
There exists a plethora of train types with matching infrastructure. Thus, an autonomous system that applies to one type of trains may not necessarily generalize to another. While there is a will for unification, overhauling a country’s entire rail infrastructure is a daunting long-term project that comes at high cost.
The stopping distance of a train is function of its body weight, cargo, and speed: a 10-car passenger train moving at 100 km/h requires about 500 meters to come to a halt. Therefore, it is imperative to detect obstacles and recognize the state of traffic lights well in advance before making a calculated stop.
A special emphasis is given on passenger safety and system dependability. Without proof of the computer system’s reliability, security, and robustness, autonomous trains cannot be certified, let alone commercialized.
Testing the system in situ requires access to railway infrastructure, which is not as trivial a matter compared to regular roads.
These bottlenecks may be holding GoA4 trains back today, but there is no doubt that we are on the brink of a breakthrough that will revolutionize public transportation as we know it. Both freight and passenger trains will benefit from full autonomy: driverless operations increase system availability, network capacity and operational efficiency.
One thing is certain: it is but a matter of time before we reach industrial maturity in this area. Indeed, autonomous trains are expected to mark the beginning of the third “rail revolution”, after electric traction and high-speed rail. Moreover, they will cement AI’s reputation for being the biggest disruption of the modern era.
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.
Intégration des essais virtuels dans la stratégie globale de validation du VA
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) ?
Les questions à poser avant de mettre en œuvre des essais virtuels
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.
