Open standards for driverless cards

DR. LUCA CASTIGNANI | MSC SOFTWARE

Why unsafe autonomous vehicle systems are passing undetected during development.

In February, McAfee exposed the alarming gap between the road test and real-world performance of autonomous vehicle sensors. In a demonstration, McAfee was able to fool a Tesla car into accelerating to 85 mph in a 35 mph zone using a piece of duct tape.

Such a fault could affect the 40 million vehicles using similar image-recognition systems. More troubling, it is also likely that many other latent defects afflicting autonomous vehicle systems lie waiting to be exposed. So why do such serious safety defects continue to go undetected during design, engineering and pre-production?

Virtual worlds were once equated with computer simulations involving avatars and multiplayer video games. Now, the term is more likely to be associated with tools that create problems for autonomous vehicles to solve. This view is from VTD, for virtual test drive. It is used for the development of ADAS and automated driving systems as well as the core for training simulators. It can generate 3D content, simulate complex traffic scenarios, and simulate sensors. It is used in SiL, DiL, ViL and HiL applications and may also be operated as a co-simulation with third-party packages.

The answer is complex but lies partly in the litany of real-world events which simply cannot be covered with real-world road testing. Incidents such as a speed sign being altered with duct tape form what autonomous carmakers call “edge cases,” rare scenarios that autonomous vehicles are unlikely to encounter in road testing but that may nonetheless happen in reality.

Autonomous systems may not understand situations outside the context of their training data, so edge cases that humans can readily handle may fool an autonomous driving system. For example, if you train a system on road signs in Europe and export the vehicle to the U.S., you must be sure it can understand the different national traffic laws.

An autonomous driving system trained to recognise a road sign in English would need to be trained so it could recognise the Japanese equivalent. Not so hard perhaps – but what happens when the same traffic light signals are interpreted differently in another country? In the U.S., you can make a right turn when the lights are red, but in Italy drivers would expect an additional light to filter traffic turning right.

To ensure vehicles can respond to all known circumstances, regional differences must be accounted for. If handled through road testing, regional differences would require carefully planned test campaigns in every export country, quickly rendering the approach unfeasible. There will always be scenarios such as road markings that reflect in a tunnel or a traffic light failure that vehicles never see during road tests but which could leave an autonomous system blind-sided in the real world.

The Road Network Editor (ROD) lets developers design roads having an unlimited number of lanes, complex intersections, comprehensive signs and signalling. Virtual worlds can be designed from scratch or compiled from existing database tiles. Various import and export formats as well as large libraries of 3D models and country specific signs/signals accelerate the creation process. All logic data is exported compliant to the OpenDRIVE format.

Nevertheless, road tests can help find outlier scenarios. What could be more realistic than driving through a tunnel in the rain to see how the automated diving system copes? The problem – ironically – is that it’s impossible to then replicate those same conditions (weather, traffic, etc.) a week later to test if the updated system gives the desired response. No two real-world road conditions or hazards are ever precisely the same. But virtual testing makes it possible to replicate the exact same scenarios to validate the system’s safe response.

The VIRES VTD software, for example, is used to test Advanced Driver Assistance Systems (ADAS) and autonomous driving systems by simulating scenarios so manufacturers and technology companies can test vehicles and their component systems. To test autonomous vehicles, companies use the software to replicate known situations by importing 3D scans of road tests. But developers can also test for edge cases that they have devised – from a moose running into the road during a snowstorm to a tram crossing traffic in a busy city.

Simulation also helps companies determine how V2I infrastructure and V2V network systems should be designed. Such infrastructure holds great promise for autonomous vehicle safety because communication between vehicles with sensors effectively gives vehicle computers more inputs, providing more data for selfdriving cars to make decisions. Again, this additional input brings new complexities that the AI must be taught to interpret.

Training is where driverless vehicle testing quickly diverges from conventional engineering. Vehicle dynamics engineers can simulate the response of a vehicle under prescribed conditions to find out if suspension modifications improve the handling – it’s cause and effect. However, to test how an AI algorithm responds we must create a diverse virtual world that exposes it to as many scenarios as possible – from its perception in all weather to traffic scenarios to connected vehicle errors. Running thousands of simulations simultaneously in the cloud makes it possible to examine car behavior over millions of miles a day to identify unique scenarios that can teach the autonomous driving system something new and prove it functions as intended under all conditions.

Users of VTD may customize the soft ware on various levels. Customization tools include SDKs, templates for sensor simulati on (object-list based and physics based), dynamics simulation and image generati on. VTD incorporates open interfaces for run-time data and simulati on control making it modular and scalable.

Yet, feeding vehicles diverse datasets requires simulation software that’s interoperable so time is spent in high-value tasks such as designing and testing new scenarios rather then in converting data. Pioneering carmakers are now adopting open standards such as ASAM OpenDRIVE, OpenCRG, and OpenScenario that enable software, ADAS and mechanical engineering functions to collaborate. Initiatives like these are reducing barriers to development and test throughout the supply chain.

Open standards should be extended to road surveys and maps so data producers, industry stakeholders and developers can easily share them to accelerate the development of technology and regulation. Open standards would make it easier to access public surveys or license commercial data, accessing large base datasets and more diverse data representing global roads and environmental conditions. While test results may be tightly guarded IP, we can likely expect to see more OEMs cooperating to capture road data and avoid reinventing the wheel. Such cooperation will let OEMs focus their resources on researching and designing effective tests strategies to improve the safety and comfort of their products.

Bringing safe autonomous vehicles to market is a big technology challenge, and we are giving ourselves years – not decades – to achieve it. Open standards offer autonomous vehicle developers in Silicon Valley and Stuttgart alike the opportunity to accelerate R&D with more data and a greater diversity of scenarios than they can hope to get in isolation. Open standards are already facilitating efficient testing of systems and hardware throughout the supply chain. Perhaps most importantly, open standards provide a much-needed common language for highway agencies producing data, certification agencies and insurance providers progress in tandem with industry to put autonomous vehicles on our roads.

REFERENCES: MSC Software, www.mscsoftware.com