Virtualization Levels for embedded/IoT Software (SIL1~4)

 

In modern embedded systems, automotive ECUs, and industrial IoT platforms, hardware virtualization enables faster, safer, and more cost-effective development. Traditional ECU testing requires physical hardware, which is costly and often unavailable early in development.

Software-in-the-Loop (SIL) virtualization allows running AUTOSAR Classic and Adaptive software on a standard PC or laptop, providing fast execution and low memory use. This lets engineers test functions, interfaces, and integration without physical ECUs, using the same tools and workflows across SIL, evaluation boards, and real hardware. Transitioning from SIL to real hardware is streamlined by replacing hardware-dependent modules and adding hardware-specific tests, maximizing reuse and minimizing time and cost. This approach accelerates development while maintaining high test coverage from early stages.


By virtualizing the target environment, developers can replicate hardware behavior and test control software without needing the physical ECU. This process can be structured into four distinct virtualization levels 1~4, categorized by the depth of simulation and the extent to which the virtual environment replicates hardware control layers.

According to the Prostep Ivip White Paper(https://www.ps-ent-2023.de/fileadmin/prod-download/WhitePaper_V-ECU_2020_05_04-EN.pdf)  on Virtual Electronic Control Units (V-ECUs), the abstraction levels from 0 to 4 are defined as follows:

 
 

Level 0 V-ECU: Controller Model

  • Content: Pure control algorithm model or C code generated from modeling tools such as Simulink/FM.

  • Purpose: Suitable for verifying the control logic itself, independent of ECU software infrastructure.

Level 1 V-ECU: Application Level

  • Content: Includes deployed application software with RTE and OS replaced by simplified test stubs.

  • Communication: Supports only signal-level data exchange, without full bus communication.

  • Purpose: Early-stage functional validation of distributed application logic.

Level 2 V-ECU: Simulation BSW

  • Content: Extends Level 1 by adding simulated Basic Software (BSW) modules such as COM, NVRAM, and diagnostic services.

  • Communication: Enables bus-level or network-level simulation (e.g., CAN, Ethernet).

  • Purpose: Integration testing of application software with selected BSW functions, rest-bus simulation, and debugging.

Level 3 V-ECU: Production BSW

  • Content: Includes the application software and the production BSW (hardware-independent parts, such as upper layers of MCAL, OS, and some CDDs).

  • Hardware-dependent parts can be replaced with simulation if required.

  • Purpose: Full hardware-independent software validation without the physical ECU, ECU network simulation, and rest-bus environments.

Level 4 V-ECU: Target Binary

  • Content: The complete production binary, including MCAL, exactly as flashed to the real ECU.

  • Execution: Runs on an Instruction Set Simulator (ISS) to replicate ECU hardware behavior on a host PC.

  • Purpose: High-precision performance analysis, multicore load testing, and pre-HIL validation.

Previous
Previous

Dynamic load management, and ​ ​the necessity for atomic updates and fail-proof OTA software updates

Next
Next

Virtualization on AUTOSAR for automotive software