Master the design and verification of next gen transport: Part Four – emulation
Emulation at the system-of-systems level is the focus of the fourth and final part of this series on the design and verification of next generation transportation systems. It moves on from the Tiny YOLO case study featured in the second (design, optimization and verification) and third (functional safety at the silicon level) parts to consider how such tasks as object classification are then integrated within broader environments both within the vehicle and beyond.
The first part of this series considers the main advantages of emulation and (as previously described) high-level synthesis. It can be found here.
Emulation within the automotive digital twin
One observation best helps in understanding the value of emulation – and, indeed, all the technologies that will be needed to verify and validate automotive systems – on the road toward Level-5 autonomy. It is the often-cited claim by Toyota CEO Akio Toyoda that a fully autonomous vehicle will need to undergo 14.2 billion km (8.8 billion m) of test. Is that even possible in the real world? For a car driven at, say, 55mph, that implies a total real-world (and non-stop) test-time of 18 years and 4 months.
Obviously, the idea is not for the tests to be carried out on a single vehicle, but even if huge fleets are assembled, the option to undertake much of the work in a robust and accelerated virtual environment that faithfully reproduces real-world conditions is obviously attractive – even necessary.
This is where the concept of the ‘digital twin’ comes in. As envisioned by Siemens, such a twin is not just a copy of a single product or system, but “a complete representation of a product as it sits out in the field.”
Emulators, such as the Veloce line from the Siemens company Mentor, can be located at the heart of such twins, making the tools they work with even more efficient. Two examples are described below, but first, here are some of the particular challenges that face automotive design at the system-of-systems level.
Increasingly complex automotive system-of-systems
Figure 1 shows six technologies that need to converge within any type of smart vehicle. These are already being deployed together before full autonomy has become commonplace.
Even within each of the discrete areas within the figure, there can be multiple forms of interaction, and all must also interface with the traditional mechanical parts of a design.
There are systems within systems simply within any vehicle. But in addition, as shown in Figure 2, there is also the question of how the vehicle reacts to its surroundings. This challenge can be seen broadly in terms of communication with other vehicles and roadside infrastructure providing local and cloud information, and also of the vehicle’s physical surroundings.
Given all these elements – and their own inherent complexity – it would be naïve to suggest that Toyoda-san has overstated the scale of the verification and validation required.
How does emulation contribute toward resolving that challenge?
Emulation in advanced automotive verification and validation
Example 1. ECU verification in the vehicle
Figure 3 shows what is chiefly an in-vehicle verification plan. It is based on the verification of five ECU systems (dashboard, engine control, transmission control, braking, automated driver assistance control) in a holistic digital twin.
![Figure 3. Verification of automotive system of systems with multiple ECUs (Mentor/Accellera – click to enlarge)](https://www.techdesignforums.com/wp-content/uploads/2019/10/4advanced-transportation_fig3-950x515.png)
Figure 3. Verification of automotive system of systems with multiple ECUs (Mentor/Accellera – click to enlarge)
It involves a combination of five different tools operating across a single network, with the emulator primarily handling transmission control. There are multiple models drawing data from different stimuli to simulate various driving scenarios (speed, braking, evasive maneuvers, etc).
In this environment, the emulator acts as an accelerator for time-to-market, and also provides extra system visibility to enable any debug that almost certainly will be needed across as evidently tangled a series of interactions.
Moreover, as seen earlier with HLS, the ability to conduct ECU verification in this environment enables a ‘shift left’ in development, at the very least helping in the capture of issues before the design goes to physical prototype.
Example 2. Sense-control-actuate
The first example draws on inputs that simulate real-world conditions but emulators’ contribution toward the ‘in the field’ aspect of a digital twin is more clearly illustrated by the ‘Sense-control-actuate’ model shown in Figure 4. Here we can see a more simplified flow in which the multiple levels of ECU simulation and verification above are brought into a virtualized environment.
Three tools are in focus for this example:
- Tass PreScan provides virtualized inputs to represent sensor readings and external traffic conditions.
- Veloce handles the electronic hardware computation, translating and combining the inputs before issuing commands to various vehicle controls.
- AMESim within Siemens Simcenter then simulates how those controls respond in a mechanical simulation environment.
All three tools interact with one another directly and in a loop to provide a continuous ‘digital twin’ simulation during an extended driving scenario.
This methodology is already in use. It is, for example, aiding the development of such ADAS assistance systems as emergency braking. Developers are taking advantage of emulation at this system-of-systems level as well as in its more traditional role for the verification of individual ICs.
Emulation thus helps address increasing complexity. It fits into systems that can verify and validate both performance and, within virtualized scenarios, safety. Then, it contributes toward accelerating the delivery of next generation automotive designs.
Conclusion
This series has concentrated mainly on two contributors to an advanced automotive design flow, HLS and emulation. But it is clear that they are to used in combination with a variety of other tools. Notably, some of these are traditional EDA tools, but others come from domains once seen as largely separate, such as the mechanical.
HLS and emulation have been the focus here, though, because through abstraction and/or acceleration they enable a productive ‘shift left’ in design processes for one of the most onerous system design tasks facing technology today. After all, automotive projects can now run across areas such as artificial intelligence, advanced sensing technologies and 5G communication.
These articles have been based on a presentation by David Aerne, Jacob Wiltgen and Richard Pugh at Mentor. It is being delivered during Accellera’s DVCon series of design and verification conferences, including the upcoming DVCon Europe in Munich, Germany More details for attendees can be found here.
Richard Pugh provides a further Expert Insight on emulation in automotive design here.