SIL-3, Level 3 virtual ECU: Production Application + BSW with virtual MCAL

Situation

A vehicle control ECU had to be developed while the hardware was on a long lead time. Software integration testing could not wait for the bench. The software was tightly coupled to its peripherals — application components driving CAN communication, ADC-based sensor polling and SPI actuator commands — so simple stubs would not have proved anything useful. The programme ran to an ISO 26262 ASIL-B target on a 300 MHz TriCore-class MCU.

Approach

A Level 3 virtual ECU was set up with a commercial vECU tool, running the full production BSW stack with a virtual MCAL underneath. The virtual ECU was connected to a network simulation tool that provided restbus simulation, signal stimulus and fault injection, with test cases authored in the matching test design tool.

The important part was not the initial setup but keeping it alive. The virtual ECU ran in parallel with BSW development for about eighteen months. The BSW configuration tool's module configuration directly drove stub template generation, so each sprint followed the same loop: the BSW module configuration was updated, stub templates were regenerated from it, the virtual ECU was rebuilt, the SIL test suite ran, and defects were reported — all within the same sprint. The virtual environment therefore never drifted away from the production configuration.

The programme ran in three phases: BSW bring-up and first stub generation, core integration with the communication and diagnostic stack exercised live, and pre-SOP validation with the stack frozen and full regression on every commit.

Virtual peripheral handling

–   ADC. Stub generated from the ADC module configuration, preserving group definitions and result buffers. Sensor stimulus injected through system variables, with fault scenarios — out-of-range values, signal dropout, slow drift — exercised safely in software.

–   SPI. Handler stub regenerated at each configuration change, with a lightweight responder model on the host validating command framing, transfer sequencing, synchronous and asynchronous modes, and DMA handoff notifications.

–   CAN. Full restbus simulation of the surrounding vehicle network. Messages validated against the DBC, with bus-off, missing-message timeout and diagnostic trouble code generation all tested in software.

–   GPIO. Mode selection and error indicator signals mapped to simulation variables and validated without hardware wiring.

The whole set ran headlessly from a Jenkins pipeline: every commit compiled the ARXML and application source, ran the SIL regression suite, and published pass/fail and coverage results to a dashboard.

Tooling CAN be flexible for various AUTOSAR platform

Level 3 does not depend on one product. Engagements have been delivered with Vector vVIRTUALtarget and with Siemens Virtualizer AUTOSAR Classic, on Infineon AURIX TC3xx and Renesas RH850 targets. The tool is chosen to fit the AUTOSAR toolchain a customer already uses, so the virtual ECU fits the existing configuration and test workflow. The target AUTOSAR platform can vary: Vector, Mobilgene, ETAS, Elektrobit, and Siemens.

Results

BSW configuration defects — PDU Router mismatches, SPI handler sequencing errors, ADC group configuration gaps — were found in the sprint that introduced them, and none reached hardware bring-up. Sensor fault scenarios were covered without specialised injection hardware, and when hardware arrived, the test scripts, signal definitions and restbus models transferred directly to the bench with no re-engineering.

Known limits

Level 3 cannot prove what the real MCAL and the real silicon do; that is what Level 4 and the hardware bench are for. Those boundaries are documented as part of the work, so test cases are scoped to what SIL can actually prove and the remaining gaps are flagged for hardware bring-up.

Level 3 and Level 4 compared