Virtual ECUs are one of the most talked-about topics in automotive software development today. They are often positioned as the natural successor to HIL - faster, cheaper, and scalable enough to replace large parts of hardware-based testing. That narrative creates confusion.

A “virtual ECU” is not a single technology. It is an umbrella term covering different levels of virtualization, ranging from lightweight functional models used for early system integration to highly detailed models that are close to the real hardware. 

These levels are not incremental steps of the same solution. A high-fidelity model is not a “better” version of a functional one - they are designed for different purposes. When teams default to the highest level of virtualization, they often introduce unnecessary complexity, slower feedback loops, and higher costs - without gaining meaningful insight.

Emil Dautovic (RemotiveLabs) interviews Florian Rohde (iProcess) together with RemotiveLabs CEO Per Sigurdson. The conversation explores common misconceptions around virtual ECUs, different levels of virtualization, and how they are best applied in real-world automotive software development - drawing on experience from Continental, Tesla, Nio, and modern tooling platforms.

Choosing the right level instead of the highest one

The key question is not how realistic a virtual ECU is - but what you are trying to achieve and validate.

If the goal is system-level integration, communication, or vehicle topology validation, detailed transistor-level behavior rarely adds value. What matters instead is speed, scalability, and the ability to connect many components early in the development process.

This is where lower levels of virtualization are particularly effective. They allow teams to shift integration testing left, run tests continuously in CI pipelines, and resolve system-level issues long before hardware is available.

High-fidelity virtualization still has an important role - especially for ECU-specific behavior, performance analysis, and edge cases. But it should be applied deliberately, not everywhere by default.

Virtual ECUs do not replace hardware testing. They amend it - just as HIL once augmented manual testing. The real benefit comes from combining virtual and physical testing in a way that removes friction across the development flow.

‍

[nfobox]

Fact box: Virtual ECUs 

What virtual ECUs enable

• Earlier system integration testing
• Faster feedback through CI pipelines
• Reduced dependency on physical hardware
• Scalable validation without increased hardware cost

What they don’t replace

• Final hardware validation
• Performance and timing verification
• Physical system behavior testing

Key takeaway
There is no “best” virtual ECU - only the right level for the job.

[/nfobox]

‍

How RemotiveLabs approaches virtual ECUs

At RemotiveLabs, we approach virtual ECUs from a system and integration perspective, rather than as a one-size-fits-all abstraction. With RemotiveTopology, teams can mock, orchestrate, and connect ECUs at system level, allowing developers to:

• Validate integration and behavior early
• Work without waiting for full hardware availability
• Run virtual setups consistently across developer machines and CI pipelines
• Combine virtual components with hardware where it makes sense
• Add other virtual ECU models and Integrate high-fidelity software simulations

The goal is not to replace HIL rigs or real vehicles, but to reduce late integration surprises and enable faster feedback throughout development from SIL to HIL.

‍

About Florian Rohde and iProcess

Florian Rohde is one of the most experienced voices in modern automotive software development. With a background from Continental, Tesla, NIO etc, his work focuses on bridging traditional automotive processes with modern, feature-oriented and software-driven development models.

Through his company iProcess, Florian helps automotive organizations assess their current development setup - from processes and culture to tooling and test strategies - and define concrete steps toward Software Defined Vehicles and feature-oriented platforms. This conversation builds on themes explored in our expert interview with Florian Rohde, iProcess: Succeeding with feature-oriented platforms

‍