Three Tools Help Put Safe Vehicles On The Road

By Richard Pugh and Gabriele Pulini

As the ultimate systems-of-systems, automated vehicles present an enormous verification task, requiring verification of complex sensing, computing, and actuating functions. This can be accomplished only by virtualizing the entire system: the vehicle and the environment it moves through.

It also requires a combination of realistic scenario modeling, hardware emulation, and mechatronic verification to get new cars on the road quickly, efficiently, and safely. This article describes a verification tool flow that enables faster development and safer, more secure vehicles.

The automotive systems-of-systems-of-systems
The road to thorough vehicle verification starts with the individual sensors and integrated circuits that combine and interact to create a multitude of larger subsystems. These subsystems in turn work together to create a much greater, heterogeneous system: the vehicle itself. Yet our verification journey is not complete until we consider the even bigger system: the world the vehicle moves through, including other vehicles, pedestrians, transportation infrastructure, and even the Cloud.

In addition, automobiles are the loci of a vast convergence of technologies: electrification, sensors, connectivity, cloud computing; big data, and artificial intelligence. All of which are wrapped up with functional safety, driver-assist features for autonomous vehicles, vehicle-to-anything (V2X) communication, and infotainment electronics.

Figure 1. Vehicles are systems of systems of systems of systems.

These automated vehicle systems must perform three tasks.

• Sensing: the vehicle must be able to sense its environment. In addition, there are many internal conditions that must be sensed in order to assure correct operation.
• Computing: those sensor outputs must be evaluated to make decisions.
• Actuating: those decisions must control some part of the vehicle or some aspect of its operation.

These three capabilities must be included in any comprehensive autonomous vehicle verification process. Not surprisingly, this presents a significant challenge, since there is no time to do physical prototyping using trial-and-error to find issues, and we certainly can’t test safety and security thoroughly on the road in a physical vehicle. OEMs, such as Toyota, estimate it would require 14 billion miles to road test a Level 5 autonomous vehicle. This is clearly impractical as it would take over 100 years to do drive this many miles. Thus, the only way we can do comprehensive verification is to virtualize the entire system — both the environment and vehicle.

This means we need tools that:

1. Model real-world environmental conditions and the sensors responding to them
2. Verify the circuits that perform decision-making computations
3. Apply these computed decisions to virtualized versions of the mechanical systems they control and make sure they work as expected

Hitting the road with real world modeling
Physics-based simulation platforms, such as the PreScan tool, from Siemens’ Tass division, perform the first task. They can extensively model vehicle infrastructure like roads (or portions of roads), bridges, and intersections; physical objects like trees, buildings, and traffic signs; other vehicles and pedestrians; and weather conditions. PreScan also offers an extensive library of modeled sensors, including cameras, radar, LiDAR, ultrasonic sensors, infrared sensors, V2X communications, and GPS.

These elements work together to allow modeling of realistic roadway conditions, with variants provided for time of day, weather, color of vehicles or pedestrian clothing, pedestrian features, and the numerous other ways these scenarios can be tested. Together, these virtual scenarios produce the signals generated by the various vehicle sensors as they react to the scenario. Those signals can then be used to test the integrated circuits that are responsible for responding to the sensors.

Figure 2. Modeling a wide range of real-world scenarios.

Making sure circuits are safe and sound
Much of the functionality at the chip level is implemented in software, which is practically impossible to simulate because it is too slow.

Unlike simulators, which use computer instructions to do their work, emulators implement the circuit in specialized logic chips. In Veloce emulators, those logic chips can handle any digital design up to 15 billion gates, effectively removing design size as a constraint. So, while you’re not running the actual final silicon chip – which hasn’t been built yet – you’re still able to use hardware instead of software, and that speeds things up by 1000-10,000 times.

One key requirement of any verification approach is visibility deep into circuits so that, if something goes wrong, you can figure out exactly where and why it happened. You can’t do that with a real, physical circuit because the overwhelming majority of the signals never leave the chip — i.e., they’re not visible. Emulators provide the needed visibility, but with far faster execution speeds than simulation.

The circuit that you build inside an emulator acts as a digital twin of the real circuit that you’re designing, so there’s no need to wait for actual silicon to do verification. More critically, you can find any problems before committing to silicon, dramatically reducing the chances of an expensive and time-consuming mask re-spin and raising confidence when you move into production.

Importantly, scenarios and results can be traced back to requirements. This lets you converge on a complete, correct design more quickly, since the verification plan and results remain connected to the requirements that drove the design in the first place.

Figure 3. Emulators allow debugging of both hardware and software.

Safety tests mean understanding what will happen when something goes wrong. There are two ways things can go awry: through systematic faults or random faults.

Emulation helps with systematic faults by raising the level of verification coverage. It provides enough performance to put the circuit through all of its paces, ensuring maximal coverage. Emulation helps with random faults by testing what happens when random faults are inserted. Unlike the situation with systematic faults, where you’re fixing circuit bugs if you find them, there aren’t bugs to fix with random faults. Instead, you’re trying to prove that, if one of these unexpected events does occur, that the system can recover into a safe state.

Verifying stimulus and response
The integrated circuits process the sensor inputs and make decisions. It’s important to verify that those decisions will have the intended effect. But the decisions affect mechanical systems that aren’t available in an emulator. A different tool is required to take the emulator outputs the rest of the way through the system.

Siemens’ AMEsim tool provides just such a capability, using functional mock-up units (FMUs) to simulate the effects of the emulator outputs. This is still a virtualized environment – you’re driving digital twins of major mechanical components like the engine, the transmission, the brakes, and the steering.

Figure 4. Simulation of mechanical systems in response to emulator outputs.

For example, if a scenario shows a pedestrian jumping unexpectedly in front of the car, the camera and other sensor signals that observe this happening are run through the emulator. The emulator will make a decision – say, to make an evasive steering maneuver, or to apply the brakes, or both. The logical signals indicating the decision can then be sent to AMEsim, where the steering wheel will turn by the requested amount, or the brakes will be applied the requested amount, or both.

An end-to-end verification flow
Together, these tools provide the end-to-end verification that’s so critical for ensuring that vehicles perform correctly. Because it’s done virtually there are no delays waiting for prototypes to be built.

Virtual emulation provides the performance to run through millions upon millions of scenarios. And not only can you test scenarios faster in a virtual environment, you can also test scenarios that would be impossible to do with a real vehicle.

A full automotive verification tool flow will give you the confidence that the vehicles you design will perform as expected, behave in a safe manner, operate and communicate securely, and meet the cost expectations required to successfully take to the road.

Gabriele Pulini is a Product Marketing Manager in the Mentor’s Emulation Division. He has more than 25 years of EDA experience, with today’s focus on verification solutions dedicated to self-driving vehicles and artificial intelligence applications.