Languages
DE
One of the key challenges in software development for automotive control units is the increasing complexity of both hardware and software, as well as that of the surrounding systems. Modern vehicles contain dozens to hundreds of Electronic Control Units (ECUs) that are interconnected via bus systems such as CAN, LIN, FlexRay and Ethernet and execute highly complex control algorithms.
Particularly in the context of automated driving, it is clear that the sheer number of necessary tests can no longer be handled solely through real-world test drives or Hardware-in-the-Loop (HiL) systems. Validation through “virtual testing” is therefore increasingly becoming an indispensable complement to traditional testing methods. The introduction of virtual ECUs makes it possible to test ECU software earlier and more intensively, thereby improving software quality and identifying safety risks at an early stage of development.
A virtual electronic control unit (vECU) is an artifact that contains all the software components needed to simulate the essential aspects of a real electronic control unit. The software does not require ECU hardware but runs on a PC-based simulation platform.
More precisely: A vECU consists of C code that was either generated from a controller model, originates as production code from ECU software development, or is available as pre-compiled binary code. It is typically used to test ECU software—in this case, the vECU is the “System under Test” (SUT). Additionally, a vECU can also be used to generate input for other ECUs, i.e., as a realistic bus simulation. This allows already integrated software to be tested before the target hardware is available.
Since large portions of the software in the vECU are already available as production code, its subsequent transfer to the real ECU is easy to implement. Virtual ECUs can also be easily scaled through the use of computing power and run in the cloud, for example—a decisive advantage over physical test setups.
Depending on the application, vECUs can be used with varying degrees of realism and corresponding complexity. A classification method developed by prostep ivip prostep ivip ranges from Level 0 to Level 4:
Level 0 – Controller Model: The simplest vECU contains only the controller model itself (e.g., as a MATLAB/Simulink model) or the C code generated from it (e.g., as an FMU). It contains no production code and no parts of the base software. This type is suitable exclusively for testing the control algorithm itself.
Level 1 – Application Level: The Level 1 vECU contains the production code of the application software. The software components are supplemented by lower-layer functions created specifically for the vECU (e.g., RTE and operating system in AUTOSAR). The vECU communicates at the signal level, without bus or network communication. It is suitable for testing application functionalities across multiple components.
Level 2 – Simulation BSW: Level-2 vECUs additionally offer simulated basic software (BSW) functionalities created specifically for simulation purposes—such as a COM stack, NVRAM functionality, or diagnostic functions. Unlike Level 1, Level 2 vECUs can communicate at the bus or network level (e.g., via simulated CAN or Ethernet).
Level 3 – Production BSW: Level 3 vECUs contain not only the application’s production code but also the production code for the base software. Both the application and base software must be hardware-independent. In the AUTOSAR context, this includes everything above the Microcontroller Abstraction Layer (MCAL), the operating system, and hardware-independent parts of complex drivers. This level is currently the most widely used.
Level 4 – Target Binary: The Level 4 vECU contains the production code compiled for the real target ECU, including any hardware dependencies. Instruction set simulation is required for execution on a simulation platform. For this vECU type, an identical build process is used for both simulation and the real ECU—no code changes are required.
To understand what goes into a vECU, it is helpful to look at the layer model of a real ECU. Using the AUTOSAR Classic Platform as an example, the software is divided into the following layers:
The application layer contains the actual control algorithm and is, in most cases, the “system under test.” Below this lies the Runtime Environment (RTE), which acts as a connection layer between the application and the base software and is generated differently depending on how the software components are distributed across various ECUs. The base software (BSW) provides services for bus communication, memory, and input/output. Hardware-dependent components are encapsulated in the Microcontroller Abstraction Layer (MCAL). If complete decoupling from hardware dependencies is not possible, so-called complex drivers are used, which connect the application software directly to the microcontroller.
For simulation, certain parts of these layers must be replaced or adapted. For example, hardware drivers for vECUs must be implemented differently than the drivers for real ECUs. Depending on which layers are included in the vECU and in what form (production code or simulated replacement implementation), the corresponding vECU level is determined.
The creation, management, and commissioning of vECUs are carried out using toolchains from various vendors, such as dSPACE, Vector Informatik, and Synopsys. These tools provide capabilities for bus simulation (CAN, LIN, Ethernet), support for AUTOSAR development, environmental simulation, test automation, and continuous integration. The tools can be seamlessly integrated into existing toolchains for ECU development, allowing tests to run on the same platform and be reused for the actual ECU. On the standardization side, two approaches play a key role:
The Functional Mock-up Interface (FMI) simplifies model exchange between OEMs and suppliers via a standardized C-API. An FMU (Functional Mock-up Unit) is a compressed file containing an XML description as well as source code or precompiled binaries. FMI is well-suited for Level 0 and Level 1 vECUs. For higher levels, however, the standard reaches its limits: The current version 2.0 supports only scalar data types and offers no efficient way to represent bus communication such as CAN, FlexRay, or Ethernet.
AUTOSAR standardizes the software architecture of ECUs and defines a clear interface between hardware-dependent and hardware-independent code components—particularly through the OS and MCAL. This interface could serve as the basis for a vECU standard. AUTOSAR covers both the Classic Platform and the Adaptive Platform (for more dynamic architectures that can be configured at runtime).
The use of virtual ECUs offers measurable advantages throughout the entire development process:
Early error detection: Many software errors that previously only became apparent during HiL and vehicle testing can now be identified and corrected in advance. This significantly reduces costly late-stage errors.
Scalability: vECUs can be easily scaled by utilizing additional computing power and run in the cloud—ideal for extensive regression tests or load tests.
Efficiency through reuse: Tests created in SIL mode with vECUs can, in many cases, be directly reused in subsequent HiL operations with the real ECU.
Regulatory-compliant archiving: A vECU can be easily archived and put back into operation as needed—for example, to demonstrate compliance with regulatory requirements such as ISO 26262 or UN-ECE regulations.
Earlier availability of the test object: Since no real ECU is required for testing, software development and validation can begin independently of the hardware delivery date.
Virtual ECUs are no longer a topic for the future—they are now a crucial component of modern, efficient ECU development. Those who adopt vECU-based test strategies early on benefit from shorter development cycles, higher software quality, and more robust compliance with regulatory requirements.
If you would like to learn more about the potential use of virtual ECUs in your development process or need advice on selecting a suitable tool environment, we are happy to assist you. ITPower Solutions has many years of experience in the field of ECU testing, extensive tool expertise with leading providers, and helps you implement the most demanding test environments and perform safety-critical tests efficiently and in compliance with regulations.
I am your sales representative and will be happy to advise you on all questions relating to our services and products! Get in touch or simply make an appointment for a free consultation call.
Sebastian Stritz
E-Mail: sebastian.stritz@itpower.de
Phone: +49 (0)30 6098501-17