Simulating the Whole Car with Multi-Domain Simulation

Next significant automotive blog in a string I will be posting (see here for the previous blog).

In the semiconductor world, mixed simulation means mixing logic sim, circuit sim, virtual sim (for software running on the hardware we are designing) along with emulation and FPGA prototyping. While that span may seem all-encompassing, in fact, it’s still a provincial view. OEMs like auto companies develop complete products in which software plays an outsize role, governing what in effect is a highly distributed compute system across the car. Developing and testing this software on (software-based) digital twins allows for faster experimentation and high levels of parallelism than possible with hardware prototypes but requires collaboration between many kinds of domain specific simulators. A very diverse group of companies are planning to launch a working group under Accellera to define an enabling standard to serve this “Federated Simulation” need.

Who Wants Federated Simulation and Why?

At DVCon I met with an impressive group: Mark Burton (Vice-Chair of the proposed working group, also Qualcomm), Yury Bayda (Principal Software Engineer at Ford Motor Company, previously Intel), Trevor Wieman (System Level Simulation Technologist at Ford Motor Company, also previously Intel), Lu Dai (Accellera Chair and Qualcomm) and Dennis Brophy (needs no introduction). What follows is primarily a synopsis of inputs from Mark, Yury and Trevor.

A car is a network of interconnected computers developed by multiple suppliers; the auto OEM software team must develop/refine and debug software to make this whole system run correctly. Perhaps the infotainment system is based on a Qualcomm chip, communicating with zonal controllers, in turn talking to edge sensors, drivetrain MCUs and other devices around the car, all communicating through CAN or automotive Ethernet. To meet acceptable software simulation times this total system model must run on abstracted virtual models for each component. Suppliers provide such models in a variety of formats: proprietary instruction set simulators or representations based on different virtual modeling tools.

Which raises the perennial problem of blending all these different models into a unified virtual runtime. Maybe someday all suppliers will provide models with TLM-compliant interfaces but until then, can we build better bridges/wrappers to couple between all these models? That’s what the Federated Simulation initiative aims to address. Yury provided a compelling example for why we need to make this work. Over the Air (OTA) software updates are a must-have for software-defined vehicles but what happens if something goes wrong in an update – if the update bricks your car or some part of your car? System-level scenarios like this must be considered during design to mitigate such problems and must tested exhaustively.

Bottom-line, system software development must start early before hardware is available and is completely dependent on reliable high-level simulation abstractions to underpin total system simulations.

Not just for electronic systems

A car is not just electronic circuits; neither is a plane or a spacecraft or an industrial robot. Still, electronics plays an increasing role, now interacting with mechanical systems and with the surrounding environment. Antilock braking must behave appropriately under different levels of traction on a dry road, in rain or in snow. From ADAS to autonomy, driving systems must be tested against a vast array of scenarios. The CARLA simulator is an important component of such testing, modeling urban and other layouts across many environment conditions and providing streaming video, LIDAR, and other sensor data as input to full system simulations.

A federated simulation solution must couple to simulators like CARLA. Ultimately it must also couple with standards in other verticals such as OpenCRG to describe road surfaces, VISTAS/VHTNG for avionics, SMP2 for space applications, and FMUs for mechatronics. Each is well established in its own domain and unlikely to be displaced. A federated simulation standard must respect and smoothly interoperate with these standards – I’m guessing in incremental steps. That said there is already enthusiastic support from many quarters to be involved in this effort.

Core team membership for the initial definition

 What will it take?

This is an ambitious goal but it’s worth noting that the US DoD launched a similar effort called HLA in the 1990s which has continued to grow. Airbus has built their own architecture with similar intent, including a physical prototype of an aircraft for hardware in the loop testing. At the electronic systems level, Mark, Yury and Trevor have all previously been involved in multi-simulator projects at Intel and Qualcomm, and more recently with Ford (Yury and Trevor). They do not see this as an impossible goal though I’m guessing it will likely evolve from modest expectations through multiple releases.

The core concept as described to me is based on cloud deployment with a container instance for each simulation and Kubernetes for resource allocation (CPUs, GPUs, hardware accelerators, etc.) and orchestration. The Accellera team don’t plan to reinvent any standards (or emerging standards) that already work well. Instead they intend to leverage existing transport layers, adding only applications layers above that level such that a simulator instance can publish streams of activity to other subscribing simulators, and subscribers can be selective about what data they want to see.

Very interesting. You can learn more HERE and HERE

Also Read:

An Accellera Functional Safety Update

DVCon Europe is Coming Soon. Sign Up Now

Accellera and Clock Domain Crossing at #60DAC