vECU Abstraction Levels
Virtual ECUs exist at various abstraction levels, ranging from early functional models to full system virtualization. Each level supports specific validation objectives throughout the development lifecycle.
- Level 0 – Model‑in‑the‑Loop (MiL): Developers use this level for early concept and algorithm development. It relies on pure functional models without production code or hardware dependency.
- Level 1 – Software‑in‑the‑Loop (SiL): This level validates application software logic. It runs production application code compiled for a PC, with hardware interactions stubbed or simulated.
- Level 2 – Virtualized Basic Software: Developers use this level for software integration testing. Application software runs on a virtual OS or AUTOSAR Basic Software, enabling middleware, diagnostics, and communication behavior testing.
- Level 3 – Instruction Set Simulation (ISS): This level supports high‑fidelity software validation. It executes the target‑compiled production binary on a simulated processor to validate timing, memory, and compiler‑specific behavior.
- Level 4 – Full System Virtualization: This level enables complete ECU validation without hardware. It virtualizes the processor and peripherals to test low‑level drivers and hardware‑dependent software.
The classification of Virtual Electronic Control Units (vECUs) follows a standardized approach based on abstraction levels and the software layers included in the simulation. These levels, ranging from Level 0 to Level 4, determine simulation fidelity and suitability for different stages of the automotive V-model.
Level 0: Pure Functional Model (Model-in-the-Loop - MiL)
At Level 0, virtualization focuses exclusively on the mathematical representation of control logic. Developers typically represent the software as a block diagram (e.g., MATLAB/Simulink) or high-level code.
Characteristics: The model excludes production code and remains hardware-independent.
Use Case: Developers use this level for early algorithm development and verification of control strategies against a plant model.
Advantages: It enables rapid prototyping and simplifies debugging of logical errors.
Level 1: Application Software (Software-in-the-Loop - SiL)
Level 1 involves compiling actual Application Software (ASW) code for a Windows or Linux host environment.
Characteristics: Developers compile the code using a host compiler (e.g., MSVC or GCC) instead of the target cross-compiler. Hardware-specific dependencies and Basic Software (BSW) are replaced by “wrappers” or “stubs.”
Use Case: This level tests functional software components and integration between different application modules.
Advantages: It offers high execution speed and eliminates the need for target microcontroller knowledge.
Level 2: Virtualized Basic Software (V-BSW)
Level 2 introduces parts of the AUTOSAR Basic Software or a simplified Operating System (OS) layer. This level enables testing of software that relies on middleware services.
Characteristics: The ASW runs on a virtualized BSW stack. Communication (CAN/Ethernet) and memory management are simulated functionally.
Use Case: Developers use this level for integration testing, focusing on interactions between the application and middleware.
Advantages: It balances performance and functional depth, allowing testing of diagnostic sequences and communication stacks.
Level 3: Target Binary Compatibility (Instruction Set Simulation)
Level 3 provides high fidelity by using an Instruction Set Simulator (ISS) to mimic the target microcontroller’s processor (e.g., Infineon AURIX or ARM Cortex).
Characteristics: Developers compile production code using the actual target cross-compiler. The simulation executes the resulting binary file, emulating the processor’s registers and instruction set.
Use Case: This level verifies compiler-specific behavior, stack usage, and low-level software-hardware interactions.
Advantages: It delivers extremely high accuracy and identifies issues related to memory alignment and processor-specific execution.
Level 4: Full System Virtualization
Level 4 represents the most complex tier, virtualizing the entire ECU hardware, including the processor, specialized peripherals (Timers, ADCs), and complex drivers.
Characteristics: Digital twins of hardware peripherals integrate with the ISS. This level replicates the physical ECU’s behavior as closely as possible.
Use Case: Developers use this level for the development and validation of low-level drivers (MCAL) and complex device drivers (CDD).
Advantages: It supports full “closed-loop” testing of the entire software stack without physical hardware.