8.8 billion miles to verify

By Philip Vanness |  No Comments  |  Posted: October 26, 2018
Topics/Categories: EDA - Verification  |  Tags: , , , , , , , ,  | Organizations: ,

Philip Vanness is a product marketing manager at Mentor, a Siemens business.Philip Vanness is a product marketing manager at Mentor, a Siemens business.

This article has two themes. One looks at delivering the digital twin for automotive design today, and how that challenge will likely have wider implications. The other illustrates how Mentor’s EDA offering is being integrated into the wider Siemens systems-of-systems infrastructure for those digital twins.

Exhaustive verification

Toyota believes that a car will need to undergo the equivalent of 14.2B kilometers (8.8B miles) of test to verify all the safety, performance and functionality requirements for Level 5 autonomy, the point where no human input is needed to drive or control a vehicle.

Such a requirement is beyond any conceivable real-world solution. By the time you had completed a physical test that long, the car would be obsolete. Moreover, the requirement exceeds the capacity of traditional simulation. We know about simulation’s limitations when it comes to individual SoCs; a car takes us beyond even the billion-gate level in terms of complexity.

Over those 8.8B miles, you must become able to guarantee that all the vehicle’s components – hardware and software – will work in harmony, that all the ECUs within the vehicle will talk to one another over their different interfaces, that all the sensors will provide the data that they should – and that the right decisions will be taken as a result.

You can break down the necessary verification task into three data processing stages: Sense, Compute and Actuate (Figure 1).

Figure 1. The three data processing stages of autonomous driving -digital twin feature

Figure 1. The three data processing stages of autonomous driving (Mentor)

You can then assign three tools from Siemens to each of those stages: the PreScan sensor and environmental simulation platform, the Mentor Veloce emulation platform, and the AmeSim mechatronic simulation platform.

These all existed before the Mentor became a Siemens company. However, the way in which they have been – and continue to be – aligned illustrates how benefits cited when the deal was first announced are being realized. And that alignment answers Toyota’s challenge.

The Digital Twin

The Digital Twin is an important concept. Siemens defines it as “a virtual representation of a physical product or process, used to understand and predict the physical counterpart’s performance characteristics”.

You can apply this to various stages in a design flow. In this specific case, we want to apply the idea to the verification of advanced automotive systems of systems.

This is how each tool contributes toward forming that digital twin.

PreScan allows you to build the virtual environment. It has within it the models needed to create various scenarios. Its sensor models are building blocks. They allow you to replicate the data regarding lane changes, pedestrians, traffic signals coming into the car or that should be coming in.

Figure 2. PreScan overview - digital twin feature

Figure 2. PreScan overview (Mentor)

Veloce is the compute horsepower. This is where the pre-prototype RTL model of your SoC sits, running many thousands of times faster than it would in traditional simulation. But acceleration is not the only reason why emulation is vital here.

It provides greater observability than, say, a FPGA prototype. The FPGA may run faster, but the prototyping board will not have the granularity needed to meet the absolute certainty required under automotive standards that what your test just exercised will actually work. Emulators also give you stop-start options to dig deeper into single-event interruptions (e.g., EMI, register flips, stuck-ats, etc.).

Mentor provides transactors and Veloce apps to recreate fault scenarios (systematic and random) within the emulator and make sure that the verification accounts for all of those automotive protocols (e.g., CAN, LIN, Flexray). Where PreScan provides external context, Veloce builds internal context on top.

Figure 3. PreScan feeds Veloce (Mentor)

Figure 3. PreScan feeds Veloce (Mentor)

AmeSim helps to virtually implement the decisions made by the RTL within Veloce. When your SoC decides to, say, operate the brakes or turn the steering wheel, AmeSim has the models to simulate the behavior of the relevant physical systems. When the computation is complete, now how does the car react?

AmeSim draws on more than 5,000 models. These covers control systems, mechanical, fluid, and heat processes – indeed, just about everything you need to virtualize a mechanical system.

Figure 4. AmeSim libraries - digital twin feature

Figure 4. AmeSim libraries (Mentor)

These products have been around for a while. But with them all now within Siemens, they have been brought together in a coherent flow, and their interactions continue to be optimized.

They also sit within the broader automotive tool infrastructure provided Mentor, all of which is qualified to the critical ISO26262 functional safety standard. Its elements include Questa (since there are areas you may wish to simulate and you can also take advantage of formal verification to prune your test cases), Calypto (allowing you to leverage high-level synthesis for complex algorithm and SoC definition) and Tessent (bringing full test into the flow).

In addition, the Mentor Safe program helps user ensure compliance with ISO26262 particularly when it coms to the documentation of design processes, particularly those for verification and test.

Going back to PreScan, Veloce and AmeSim, it is worth noting that all three interface to designs through the same Functional Mock-up Interface (FMI) protocol. This allows users to encapsulate virtually anything they want to. Taking the example of an automotive project, it allows components and blocks from different suppliers to be easily integrated within a digital twin, as well as those developed internally.

Figure 5. The digital twin within automotive verification (Mentor)

Figure 5. The digital twin within automotive verification (Mentor)

Virtual solutions to very real problems

The flow described here already exists: Compute -> Sense -> Actuate on interconnected systems of different abstractions. We expect to make significant enhancements soon in areas such as security. The safety of a vehicle depends on its resistance to being corrupted or hacked. Automobiles are becoming mobile datacenters with multiple access points that need to be secured.

One way of looking at safety analysis for automotive is that OEMs must be satisfied with a vehicle’s operation over a million scenarios, all constructed from different events. To have confidence in the use of the digital twin concept, they therefore need to see that it can be implemented to handle those Sense, Compute and Actuate stages efficiently and accurately.

Then broadening our view to address wider systems-of-systems challenges, we can also reasonably argue that the complexities arising in the automotive market today will soon be seen in others. For example, how safe will drones have to become to make home deliveries? What might be coming in AI-driven surgery? The ability to build digital twins – many of will may be broader than that described here – is already becoming increasingly important to many more markets than the self-driving car.

Comments are closed.

PLATINUM SPONSORS

Synopsys Cadence Design Systems Siemens EDA
View All Sponsors