AImotive Blog

Tamás Csizmadia – Safety Defines Autonomous Development


July 12, 2018

Functional safety is, without a doubt, the most crucial factor in safety-critical environments such as automotive development. Not only because you gain the trust of customers but because you would put the health and safety of test drivers and more importantly everyone in public areas at risk by ignoring state of the art methods. Therefore, AImotive is making safety its highest priority. I spoke about how our Safety Team works alongside development teams to guarantee the safety of everyone on the roads while we test at the Autonomous Testing China conference in Shanghai recently, below is a brief overview of my presentation.

Since launching the AImotive Blog we have covered the safety of autonomous vehicles and testing in some detail. In my last post I offered some insight into the safety of testing processes we have in place behind the scenes, while László, our CEO, went into detail about how simulation is a part of our development pipeline. Recently, our Chief Scientist also stressed the importance of redundancy. I recommend you run through those posts to better understand the whole safety ecosystem we have, because today I want to take a step back and look at how safety plays a central role from the beginning of our development cycle, and how it continuously influences the work our development teams do.

Our group of safety and system experts continuously analyze industrial standards, national regulations, calculating safety limitations with responsible engineering judgement. Relating to functional requests, we will lay out a set of functional, performance and safety requirements that are in-line with laws and standards. The results are quite similar to a customer’s requirements specification. Working with development teams we find technical solutions that adhere to the defined requirements. As a result, safety considerations are a part of our development process from the very beginning. Moving forward simulation testing provides a host of information for our teams, both about the maturity of the solutions and even new safety consideration that should be taken into account.

The graph showcases how AImotive's Safety Department acs as a customer in internal development by defining the requirements new solutions must meet , and  how safety cionsidferations affect development.
Throughout development our team of safety experts behaves almost like a customer, continously defining requirements that comply with regulations and standards.

We use two different kinds of scenarios to test new features. The first are defined to specifically verifying new features based on laws and standards. These are created at the same time as the functional and technical requirements and focus on testing all or certain elements of these. We were prudent in designing a concept to maintain consistency and traceability between work items using an ASIL D certified ALM tool. Scenarios of the second type are taken from the real-world. They are based on incidents from large international databases, such as the NHTSA Fatality Analysis Reporting System, and are selected either to stress test the whole self-driving solutions or because they can be used to test the specific functionality being developed. This verification and validation concept, which leads to thousands of test results a day helps us maintain traditional requirements-based development, while our agile workflows and automated evaluation create a process that is safe in an automotive environment, while allowing us to compete with tech startups rushing to rapid prototyping.

Beyond testing how well our technology can handle certain situations these scenarios also help us pinpoint where any faults could be. We achieve this through modular testing. A module is an element of aiDrive that is responsible for a single task, for example lane recognition. In modular testing ground truth data can be fed into the aiDrive system from aiSim, our simulator for autonomous vehicles, for every module other than lane recognition. As a result, our teams gain an immediate understanding of which module is responsible for a fault, or failing scenario pass criteria.

A visualization of a few example modules (perception, model space) and how these can be replaced bvy GT (ground truth).
In modular testing the information received by the self-driving system from any module can be replaced with ground truth data allowing us to pinpoint the areas that need further development.

Modular testing not only shortens iteration times, it allows us to allocate the right amount of resources to the right tasks and challenges. This is a safety consideration, as our team can concentrate on areas of aiDrive that need to be improved immediately. While continuously developing the software stack as a whole is vital, knowing which areas of certain functionalities have to be improved before road testing commences places a safety barrier between public roads and our development. Only sufficiently stable and mature solutions are tested on public roads, and through modular and scenario testing our team will now what to be aware of while testing on the road.

Simulation plays an important role in our whole development pipeline, indeed, the process outlined above is just a small cross-section of our work. Naturally, testing must also happen in the real world on closed tracks and public roads and our Safety Team has work to do there as well.