Going Virtual In Automotive Electronics Development

Developing the electrical/electronic (E/E) systems in automobiles and other vehicles has always been challenging due to the rough environmental conditions experienced on the road and the high expectations for safety and reliability. In recent years, these challenges have been exacerbated by several industry trends. They have triggered a revolution in how electronic control units (ECUs) are designed, verified, and validated at the system level.

The first trend is the greatly increased role of electronics in modern cars. Processing power has become as important as horsepower. In-vehicle infotainment (IVI), electric and hybrid powertrains, and advanced driver assistance systems (ADAS) have far higher computing requirements than traditional ECUs with simple microcontrollers. Autonomous drive (AD) vehicles with artificial intelligence (AI) capabilities take these requirements even further.

The processors used in today’s automobiles are some of the largest and most advanced chips in the world. They are supported by sophisticated E/E architectures and increasing software content with millions of lines of code. In fact, the term “software defined vehicle” is often used. Continuous over-the-air (OTA) updates of software enable better reliability through bug fixes, more operational flexibility, and longer product lifespans, but add complexity to the design.

Layers of automotive software.

The expanded electronic content in fully electric and self-driving vehicles has led to venture investment in numerous startups challenging traditional automakers. Their aggressive schedules increase competitive pressure and the need to accelerate the start of production (SOP). Both traditional and startup manufacturers have suffered supply chain slowdowns and chip shortages, pushing even more content into software and making OTA updates more important than ever.

Safety and security risks have also increased. OTA updates introduce new vulnerabilities that didn’t exist in unconnected vehicles, as does reliance on the cloud for data collection and some types of computation. The rigorous ISO 26262 functional safety standard has become well known, with all players in the supply chain and even end users demanding compliance. The job of automotive electronics developers is much harder than it was just a few years ago.

The result is that traditional bench-based testing and validation no longer suffice:

• Lab bench setups are costly to build, maintain, and replicate
• More software content means that more programmers need access to test platforms
• Software development must start early, well before physical hardware is available
• Bugs found in lab the lead to very expensive chip turns that further delay SOP

The automotive electronics industry must replace lengthy development cycles with a faster and more agile approach. This is accomplished by going virtual: moving from software development and validation using physical ECUs and benches to digital twins using simulation of virtual ECUs (vECUs). vECUs enable front-loading of the validation effort, greater testing scalability, and better ecosystem collaboration.

Digital twins provide a highly productive validation environment early in the development process. They provide more productive system testing and validation because issues can be reproduced deterministically and debugged with high visibility. vECUs support fault injection difficult or impossible with physical hardware, key for validating functional safety. They also enable easy supply chain collaboration due to their software nature.

The simulation of vECUs has found rapid adoption in ECU development, but the industry lacks a standardized terminology to describe the different variations in use today. Synopsys recommends that the software layers be designated as Applications, Middleware, and Operating System (OS). If a hypervisor exists, it is considered part of the OS. The software runs on two distinct types of vECUs: host compiled and target compiled.

In a host compiled vECU, the ECU software is cross compiled to the simulation host (typically an Intel x86 server or desktop). The vECU contains no model of the ECU hardware and does not execute the lower, hardware dependent software layers. Thus, software modification is required for certain layers and the vECU is not running full production code. Host compiled vECUs are faster but less accurate than target compiled vECUs.

A target compiled vECU uses the compiler for the specific target automotive processors, such as Arm, RH850, or TriCore. The vECU uses—and therefore requires—detailed simulation models to represent the ECU hardware. This allows the production software to be compiled exactly as it would be in the actual vehicle and run with no modifications. Target compiled vECUs are slower but more accurate than host compiled vECUs.

VCU types and abstraction levels.

The figure above shows the recommended classification of VCU types and the abstraction levels they support:

• Level 0 focuses on the design of the algorithm model, typically written in C++ code or using the MathWorks MATLAB environment. The code is simulated on the host as host compiled code or via an interpreter.
• Level 1 focuses on testing the production application, or a module of it. The Middleware software layer is replaced with basic run-time and I/O simulation code. The application or module is compiled into a host executable.
• Level 2 expands the scope to a complete application and brings in the interfaces from the application to the Middleware. The production code of the complete application is used, but the Middleware is replaced by a simulation equivalent.
• Level 3 adds more production software to the bottom of the stack. Production Middleware is included, and the device drivers are substituted with a simulation equivalent. All the hardware independent software layers can be validated.
• Level 4b uses production code for all the software layers: Application, Middleware, and OS. No simulation substitutions are required. The same compiler used for the physical ECU produces the identical binary target executable.
• Level 4a is a unique approach introduced by Synopsys. It is like Level 4b except that select software functions in the full stack are bypassed and executed on the host. This speeds up the vECU simulation and reduces the number of models required.
• Level 5 is the traditional bench approach with the physical ECU running the full production software stack as target compiled code. This is also the way that the actual vehicle operates in the field.

There are many more dimensions to this classification, including the ability to mix vECU levels in a single simulation. A recently published white paper provides much more information on the use of digital twins and vECUs to accelerate and improve the validation of automotive electronics.

There is no single vECU level that addresses all the challenges. As part of providing the industry’s broadest and most robust automotive solution, Synopsys fully supports the complete range of vECU levels in a single framework. There is no better way to develop functionally correct, robust, safe, and secure automotive electronics.