Verification of automotive systems is an enormous task

Future vehicles rely on the convergence of a huge range of technologies. Electrification; sensors; connectivity; cloud computing; big data; AI – they’re all intimately connected in the functional safety and driver-assist features for autonomous vehicles.

At the lowest levels, individual sensors and integrated circuits interact in the various subsystems of the vehicle. But it doesn’t stop there, the vehicle is part of an overall environment that includes other vehicles, pedestrians, infrastructure, and even the cloud. This makes the verification of automotive systems an enormous task.

There are literally millions of scenarios to be checked out. And each of those scenarios has variations. For example, one scenario might have the car approaching a pedestrian in a crosswalk. But that could be at different times of day, with different weather, and with different pedestrian clothing. All of this is a verification project that, realistically, could never be accomplished using physical means. All of these demands join the usual challenges of getting a cost-competitive product to market as quickly as possible. The problem is a perfect fit for verification tools that can make this process manageable. A combination of realistic scenario modeling, simulation, and mechatronic verification aim to get a new vehicle on the road quickly and efficiently.

Figure 1: Vehicles are systems of systems, of systems of systems.

For an autonomous vehicle to function, its systems must perform three tasks:

• Sense: the vehicle must be able to sense its environment. In addition, there are many internal conditions that must be sensed to assure correct operation
• Decide: those sensor outputs must be evaluated to make decisions
• Actuate: those decisions must control some part of the vehicle or some aspect of its operation All three of these elements need to be included in any comprehensive verification process.

And that presents a significant challenge, since there is no time to do physical prototyping using trial-and-error to find issues. And it’s impossible to test safety and security thoroughly in a real, physical vehicle. The only way to do extensive verification is to virtualize the entire system – environment and vehicle. This means that we need tools to:

• Simulate real-world environmental conditions and the outputs of sensors responding to them
• Verify the circuits that perform the decision-making computations, given the sensor inputs
• Take the computed decisions and apply them to virtualized versions of the mechanical systems that those decisions control

Figure 2: Veloce emulators take a design that’s been compiled for the emulator, execute the design, and allow debugging of both hardware and software.

Modeling the driving environment

In the first task, a tool extensively models the 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. It also has 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.

Verifying the integrated circuits

When it comes to verifying circuits, simulation is a common tool used extensively for checking out pieces of the circuit. But when it comes to verifying an entire chip, simulation is far too slow. Much of the functionality will be implemented in software, which is practically impossible to simulate – again, because it would take an extraordinary amount of time to do so. But there’s a faster way to verify silicon: hardware emulators. Unlike simulators, which use computer instructions to do their work, an emulator implements the circuit being verified in logic chips that make up the heart of the emulator. In the Siemens hardware emulator, Veloce, those logic chips have been designed to allow them to implement any digital design within the size constraints of the emulator. So, while you’re not running the actual final silicon chip – which hasn’t yet been built – you’re still using hardware instead of software, and that can speed things up by 1000-10,000 times.

One key requirement of any verification approach is visibility. You need to be able to see deep inside the 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 – so they’re not visible. Simulators give good visibility, since everything is modeled in software, but, as we’ve seen, they’re too slow. Critically, hardware emulators also provide the needed visibility making it possible to peer into the circuits in the same way that simulation allows, but with far faster execution speeds. The circuit that you build inside an emulator acts as a digital twin of the real circuit. It allows you to develop a high-quality circuit much more quickly.

This makes verification much more efficient because you’re testing the circuit before it’s built. This means that there’s no need to wait for actual silicon to do the 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: Together, Simcenter PreScan, Veloce and Simcenter Amesim provide end-to-end vehicle verification.

Verifying the response to calculations

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 hardware emulator outputs the rest of the way through the system. Siemens has a tool that 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 – where testing the activity of major mechanical components like the engine, the transmission, the brakes, and the steering can be done. So, 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 decides – 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 the mechanical component simulation tool, where the steering wheel will turn by the requested amount, or the brakes will be applied the requested amount, or both.

Verifying from stimulus to response

Together, these tools provide the end-to-end verification that’s so critical for ensuring that your vehicle will perform correctly regardless of the scenario and regardless of which parts of the vehicle are affected. And it’s done completely virtually, meaning no delays for building prototypes. One need only create models – and many of them already exist in the tool libraries.

Jean-Maire Brunet, senior director of product management and engineering for the Scalable Verification Solutions Division at Siemens EDA

—————————————-

Jean-Marie Brunet is the senior director of product management and engineering for the Scalable Verification Solutions Division at Siemens EDA. He has served for more than 20 years in application engineering, marketing, and management roles in the EDA industry, and has held IC design and design management positions at STMicroelectronics, Cadence, and Micron among others. Jean-Marie holds a Master’s degree in Electrical Engineering from I.S.E.N Electronic Engineering School in Lille, France. Jean-Marie Brunet can be reached at jm_brunet@mentor.com