Situation

A development team needed to validate ECU software before target hardware was available, and wanted the test to cover the software exactly as it would ship. Level 3 was not enough for this purpose, because the driver layer would have been replaced by stubs — and the driver layer was where a meaningful part of the risk sat.

Approach

The team built a virtual MCU in QEMU, an open-source instruction-set emulator. Because QEMU emulates the processor itself, the software does not need to be changed or rebuilt for it. The same binary that would be flashed to the real ECU is loaded into the virtual one and starts executing from its reset vector, exactly as it would on silicon.

Building the virtual MCU followed five steps:

–   Board definition. Board initialisation, system clocks and the fixed-frequency system clock.

–   SoC structure. Memory regions (program flash, data flash, SRAM), the peripheral set, and the interrupt request lines that connect peripherals to the CPU.

–   QEMU integration. Registering the new board and SoC in the QEMU build configuration.

–   Peripheral modelling. Each peripheral written in C and modelled at register level, following the vendor's technical reference manual, then integrated into QEMU.

–   Peripheral verification. Checking each virtual peripheral against expected behaviour before it is used for software testing.

In the reference engagement, an Arm Cortex-M7 automotive MCU (NXP S32K358 class) was virtualized with a periodic interrupt timer, ADC, GPIO, low-power UART, CAN FD and PWM. A later engagement virtualized a dual-core Arm-based MCU, adding SPI. In principle any peripheral of an SoC can be modelled; the set is chosen to match what the software under test actually uses.

Embedded and IoT — validating the final binary without recompiling

Nothing is rebuilt for the host and no layer is swapped out. What runs in the virtual environment is the final image for the final target, exactly as it will be programmed into the device. This is the main reason to choose Level 4: the artefact under test is the deliverable itself, not a host build that resembles it.

Because the emulation happens at processor level, what sits on top does not matter — bare-metal firmware, an RTOS image or an embedded Linux build are all just binaries. Device drivers, board support code and every other hardware-dependent layer execute as they are, which is the part that is hardest to cover any other way. For embedded and IoT products whose hardware dependency reaches deep into the stack, and for teams shipping the same product across several different OS environments, this makes it possible to check the real deliverable before any hardware exists.

Why this matters for AUTOSAR

In an AUTOSAR Classic stack, the MCAL is the layer that touches the hardware registers directly. At Level 3 it has to be replaced. At Level 4 it does not: the production MCAL, the BSW, the OS, the RTE and the application software components all run together as one image, without recompilation and without a single line of adaptation. This means the complete ECU software can be validated without an ECU, and test cases originally written for the real ECU can be executed against the virtual one without being rewritten.

What it enables

Once the virtual MCU is in place, it becomes a normal test target. Unit, integration, functional and regression testing all run against it, as does firmware and bootloader testing, timing and resource analysis, debugging and tracing. Two things become possible that are difficult on real hardware: fault injection, where memory corruption or CPU exceptions can be triggered on demand, and security testing of mechanisms such as secure boot. Because the virtual ECU is just a process, it also scales in CI/CD — every commit can be tested on a pipeline, with no hardware bench to share or book.

Level 3 and Level 4 compared