The Evolution of Smart Car Driving: Analysis of Virtual ECU Types and Pros and Cons

The price of safer, more comfortable, and smarter modern cars is the rapid growth of the number of on-board ECUs (Electronic Control Units). Correspondingly, the scale of software on ECUs is getting larger and larger, and software development costs account for a large part of vehicle manufacturing costs. The proportion is getting higher and higher. Car companies can solve the above problems from two perspectives: rules and methods:

• Grasp the rules with one hand: AUTOSAR, the automotive open system architecture;

• One-handed approach: Build a virtual ECU through simulation modeling technology to realize the "digital twin" of the car.

Based on this, this article will analyze the various types of virtual ECUs based on the AUTOSAR architecture and their advantages and disadvantages in the evolution of smart car driving.

01. Automobile open system architecture AUTOSAR

AUTOSAR (AUTomotive Open System ARchitecture) originated in 2003. It is an automotive open system architecture alliance jointly established by world-renowned automobile manufacturers, component suppliers, and other electronics, semiconductor, and software system companies. The specifications introduced by the alliance are called It is an AUTOSAR specification, which improves the compatibility, reusability and reliability of automotive ECUs by standardizing the definition of automotive basic software.

AUTOSAR follows a top-down development method, that is, system design is carried out first, then development and implementation are carried out separately, and system integration is finally carried out. Mainly did the following three things:

• Standardize the interface between application software and underlying software and between application software;

• Give a controller software reference architecture;

• Standardize the exchange format in the distributed development process.

According to the data of AUTOSAR GBR. AUTOSAR layer software architecture R4.4.0, its overall framework is a layered design, with the middleware RTE (Runtime Environment, RTE) as the boundary, isolating the upper application layer (Application Layer, APPL) and the lower layer Basic Software (Basic Software, BSW).

▲AUTOSAR software architecture

After 20 years of long-term development, the AUTOSAR architecture has become mature, and the coupling degree of software and hardware of automotive embedded systems has been greatly reduced. Up to now, AOTOSAR has been widely used in ECU software development and automotive electronic design, such as automotive chassis control systems. Development, low-level communication software design, vehicle electrical and electronic architecture design, automotive electronic diagnostic system development, and motor control system design provide new solutions to meet the growing needs of users for intelligent driving.

02. Analysis of the types and pros and cons of virtual ECU

According to different levels of the AUTOSAR framework, virtual ECUs can be divided into the following four categories:

▲Virtual ECU classification

The first category: only contains ASW and RTE (RTE may contain an OS)

• It only simulates the RTE environment, and can only test the basic functions of ASW, ignoring the communication details in the basic software.

• If the ASW's code is AUTOSAR compatible, the ASW code can be tested.

**This type of virtual ECU has a relatively simple structure because it does not involve hardware, but it cannot guarantee the same execution behavior as a real ECU.

The second category: includes ASW, RTE and virtual BSW.

• This type of virtual ECU is more realistic than the first type, and can test ASW and RTE codes.

• The function of the virtual BSW is to abstract and encapsulate the characteristics and complexity of the underlying hardware, and provide simplified interfaces and functions for the upper-layer application software, thereby realizing the virtualization of the underlying hardware.

** Some actual implementation behavior on real hardware cannot be tested.

The third category: OS and a virtual MCAL (Microcontroller Abstraction Layer) are added on the basis of the above.

• Compared with the second type, it is more realistic and can test task scheduling and BSW functions.

• Virtual MCAL is responsible for encapsulating the access of the underlying hardware, completing hardware-related functions through software simulation, and providing a unified interface to the upper-layer software, so that software developers can write applications more conveniently without worrying about the differences in the underlying hardware.

**It is worth noting that virtual MCAL also brings some problems:

Performance loss: Since the virtual MCAL realizes the virtualization of the underlying hardware functions through software simulation, the simulation performance may be relatively lower than that of direct access to the actual hardware, especially in application scenarios with high real-time requirements-may appear Latency issues.

Adaptability problem: Because it needs to be developed and adapted for different underlying hardware to achieve simulation, the original virtual MCAL has a high probability of not being able to fully cover all the underlying hardware features and functions. Once customized development is involved, the cost will increase .

Complexity and maintenance cost: The development and maintenance of virtual MCAL may require a large investment of manpower and resources. Although virtual MCAL can provide an abstract and unified interface, its underlying implementation is hardware-related and requires engineers to have a deep understanding of hardware specifications to implement maintenance. The complexity and cost of development and maintenance will also increase.

Functional limitations: Since the simulation implementation of virtual MCAL may not be able to fully reproduce the functions of all underlying hardware, it will be limited in some complex functions and cannot meet the needs of all application scenarios, especially in some complex hardware functions and characteristics.

Poor flexibility: This type of virtual ECU cannot directly run the binary code of the real ECU, and it lacks support for Complex Device Drivers (CDD). 

Category 4 (Best): Same as Category 3, but MCAL is real hardware MCAL.

• Full emulation is implemented, enabling nearly identical real hardware behavior.

• The direct operation of [the same binary code as the real ECU] can be realized by completely simulating the ECU processor, related peripherals, bus and other facilities.

• On this basis, fault injection that cannot be achieved by real hardware can be realized to test the security and reliability of the software.

• It has strong flexibility and can increase the modeling and simulation of CDD.

**Due to the need to simulate the technical details of the hardware, there is a certain modeling workload and modeling cycle; at the same time, in order to ensure a certain real-time performance, the construction of this type of virtual ECU often has high technical difficulty.

Virtual ECU solution based on SkyEye

SkyEye, the domestic self-controllable all-digital real-time simulation software of Tianmu , as a hardware behavior-level simulation platform based on visual modeling, supports the construction of the fourth type of virtual ECU, which can highly simulate the real controller. In addition to the original advantages of the fourth type of virtual ECU, the virtual ECU solution based on SkyEye also has the following characteristics:

• Development tasks can be offloaded from drive testing and benchtops to Windows/Linux PCs for efficient software-in-the-loop (SIL) development of ECU software.

• The system itself is also a powerful experimental environment, which can interact with the simulation models of various tools (including running MATLAB/Simulink and other tools through the standardized FMI interface) through the co-simulation bus platform tool.

• The related configuration of the virtual ECU can be copied and expanded quickly, the copy cost is low, and it is much easier than the real hardware.

• Each engineer can have a personal development environment without occupying scarce resources such as HIL benches or test vehicles, avoiding the problem of long R&D cycles caused by tight hardware resources, and more engineers can benefit from it.

Overall, the SkyEye-based virtual ECU solution has the following advantages:

• Software development, integration and testing can be carried out in the early development stage, speeding up the entire development process and improving development efficiency.

• Reduce the demand for actual vehicle testing, reduce the cost and time of testing, and reduce the risks and losses caused by actual vehicle testing.

• Provides visualized simulation results to help developers understand the behavior and performance of the control system more intuitively.

• The test can be carried out in a simulated environment, which improves the accuracy and repeatability of the test, and reduces the human error in the test.

As an innovative technology, virtual ECU has important practical significance for ECU software development. It not only improves the development efficiency and reusability of automotive software, but also facilitates system integration and verification. It also provides a better environment for software development and testing, and plays an important role in the safety and isolation of automotive ECU software. important safeguarding role. Virtual ECU will play an increasingly important role in the development of future automotive electronic systems, driving the automotive industry towards a smarter and safer future.