Virtual validation of eMobility control units: challenges and solutions in the SIL context

In a short period of time, the electrification of the drivetrain has fundamentally changed mobility and brought about a new generation of networked, safety-relevant control unit architectures. For function developers, this not only means additional complexity, but also stricter requirements for verifiability, deterministic behavior, and verification throughout the entire development cycle. Software-in-the-loop (SIL) methods are already an indispensable part of the development process, enabling function developers to validate functions early and repeatedly in a controlled, reproducible environment.

By frontloading testing into the virtual environment, error-related costs are reduced, development cycles are accelerated, and dependency on scarce hardware-in-the-loop (HIL) resources is reduced. It is crucial that SIL is not considered in isolation; its full potential is realized through close integration with CI/CT processes, clearly defined artifacts, and developer responsibilities.

Preparing for SIL simulation environments involves more than just delivering code: This requires that requirements are translated into testable scenarios, the behavior of the ECU is clearly defined, acceptance criteria are explicitly specified, peripheral accesses can be easily bypassed, and test vectors for both normal and error cases are provided.

In the context of the V-cycle shown in the figure above, this means that SIL artifacts must be directly linked to requirements documents, architecture models, and verification plans, so that each requirement has a traceable test hierarchy down to the SIL level. A fully implemented V-cycle delivers measurable benefits–faster error detection, reduced HIL dependency, and better verification management. As the central stage, SIL enables early validation and risk reduction.

Consequently, function developers must ensure that their modules are not only functionally correct, but also ‘SIL-capable’: Interfaces must be described in a stable manner, register accesses and direct memory access (DMA) behavior must be documented, and deterministic timing behavior must be specified. This requires close coordination with system and test engineers so that hardware abstractions and simulation APIs form a common basis. This is the only way to reliably integrate automated SIL tests into the CI/CT pipeline and ensure that every commit immediately generates reproducible feedback that can be seamlessly traced back to the requirements in the V-cycle.

At the same time, hardware-related functions pose particular challenges in virtualization. Timing, interrupt behavior, and synchronous peripheral access are often the sources of hard-to-find errors. Classic software-centric tests often model latencies, priority changes, or register semantics inadequately, so that race conditions, priority inversions, or worst-case latencies only become visible at HIL or vehicle level. If this level of detail is missing, error detection is shifted to integration phases, which significantly extends debugging and time-to-fix.

This is where SIL testing can become an effective tool. Depending on the degree of virtualization of the electronic control unit shown in the figure above, different use cases can be covered. Based on hands-on experience, Level 3 virtualization has proven to be the optimal compromise. In contrast to the instruction set simulation required for Level 4, Level 3 virtualization can be implemented with reasonable effort while at the same time offering significantly deeper test coverage than the Level 1 and Level 2 approaches.

Concrete use cases from the field of electromobility make the requirements and benefits of SIL tangible. In the case of charging communication, it is crucial to provide communication functionalities for CAN, PLC, or Ethernet, to model state machines in such a way that allows timeouts and retransmissions to be tested reproducibly, and to define realistic error injections, such as cancelled sessions or delayed confirmations. Only in this way can race conditions in session handling and deadlocks be detected at an early stage. 

For battery management systems (BMS), in addition to the general system behavior, mapping communication to the cell supervision circuits (CSCs) poses a particular challenge for virtualization. Hardware-close, isolated communication solutions with very high transmission speed (MBaud and faster) are frequently used. Virtualization of the CSC, including isolated communication, is essential to avoid changes to production code and to achieve the most comprehensive test coverage possible. 

A special aspect in this context is the validation of control units for electric motors. Due to the inverters used, the control signals are high-frequency, and control is therefore often based on interrupt-triggered events. Accordingly, developers must implement interrupt emulations with prioritization and latency parameters in order to test priority changes and worst-case scenarios and thus detect timing-related instabilities at an early stage. These examples highlight the particular challenges of SIL testing in electromobility. 

Modern simulation concepts contribute substantially to increasing test coverage through SIL testing in the field of electromobility, thereby improving validation efficiency and shortening development cycles. The dSPACE Smart Charging SIL Solution, for example, enables the simulation of communication controllers between the vehicle and charging station, including power-line communication (PLC), thereby realistically mapping the timing behavior of all data packets.

In the case of isolated communication in the BMS, components such as the CSCs can be simulated and executed within the hardware abstraction layer of the virtual ECU, as shown in the figure above. This means that the production code remains unchanged, while high-frequency communication with increased simulation performance is possible. In addition to the CSCs, further models for other areas of application can also be embedded in this hardware emulation layer, such as inverters. This makes it possible to react to events with modern SIL simulation and integration platforms such as dSPACE VEOS and thus map interrupt behavior.

For users with high performance requirements, solutions are available that couple FPGAs with VEOS for deterministic co-simulation. In all cases, the focus is on the consistency of HIL and SIL applications – be it through identical user interfaces, reusability of plant models, common test frameworks, or consistent QA coverage metrics. This makes it possible to combine the best of both worlds and to establish a CI/CT pipeline that provides developers with powerful tools with clear acceptance criteria for merge decisions. Ultimately, this leads to faster error identification, shorter development times, and reduced overall costs to bring vehicles safely onto the road.

Looking ahead, virtual homologation and validation across the entire V-cycle are no longer a utopian dream. With precise hardware abstractions, robust SIL workflows, and tight integration into CI/CT pipelines, significant portions of testing tasks can be frontloaded; pilot projects and field use indicate frontloading rates of up to 80%.

The interaction between SIL and HIL remains crucial: SIL provides early, deterministic validation and reduces the error volume, whereas HIL validates the real-world behavior and covers test cases that can only be realized in SIL with considerable additional effort. For function developers, this means better reproducibility, earlier error detection, clearly defined verification responsibility, and faster, reduced-risk releases. In practice, it is advisable to define SIL readiness as a mandatory delivery condition and to establish CI/CT pipelines for automated SIL runs. In this way, electrification can be used to increase the quality, speed, and safety of vehicle functions.