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.<\/p>\n
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\u2019s limitations when it comes to individual SoCs; a car takes us beyond even the billion-gate level in terms of complexity.<\/p>\n
Over those 8.8B miles, you must become able to guarantee that all the vehicle\u2019s components \u2013 hardware and software \u2013 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 \u2013 and that the right decisions will be taken as a result.<\/p>\n
You can break down the necessary verification task into three data processing stages: Sense, Compute and Actuate (Figure 1).<\/p>\n
![\"Figure](\"https:\/\/www.techdesignforums.com\/practicefiles\/2018\/10\/ADAS-digital-twin-fig1.jpeg\")
<\/a>Figure 1. The three data processing stages of autonomous driving (Mentor)<\/p><\/div>\n
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.<\/p>\n
These all existed before the Mentor became a Siemens company. However, the way in which they have been \u2013 and continue to be \u2013 aligned illustrates how benefits cited when the deal was first announced are being realized. And that alignment answers Toyota\u2019s challenge.<\/p>\n
The Digital Twin<\/strong><\/h3>\nThe Digital Twin is an important concept. Siemens defines it as \u201ca virtual representation of a physical product or process, used to understand and predict the physical counterpart\u2019s performance characteristics\u201d.<\/p>\n
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.<\/p>\n
This is how each tool contributes toward forming that digital twin.<\/p>\n
PreScan<\/strong><\/a> 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.<\/p>\n![\"Figure](\"https:\/\/www.techdesignforums.com\/practicefiles\/2018\/10\/ADAS-digital-twin-fig2-1024x534.jpeg\")
<\/a>Figure 2. PreScan overview (Mentor)<\/p><\/div>\n
Veloce<\/strong><\/a> 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.<\/p>\nIt 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.).<\/p>\n
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.<\/p>\n
![\"Figure](\"https:\/\/www.techdesignforums.com\/practicefiles\/2018\/10\/ADAS-digital-twin-fig3-1024x521.jpeg\")
<\/a>Figure 3. PreScan feeds Veloce (Mentor)<\/p><\/div>\n
<\/a>Figure 2. PreScan overview (Mentor)<\/p><\/div>\n
Veloce<\/strong><\/a> 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.<\/p>\n 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.).<\/p>\n 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.<\/p>\n Figure 3. PreScan feeds Veloce (Mentor)<\/p><\/div>\n<\/a>