Over the past decade, the Software-Defined Vehicle (SDV) has moved from a buzzword to a baseline for most automotive companies. Hardware-led innovation is becoming harder to sustain, while software-driven differentiation is opening up entire markets and delivering real competitive advantage.  As with many advances that don’t come for free, however, testing and validating software integration in the actual vehicle has become a major bottleneck. For many automotive programs, this directly impacts delivery timelines, quality, and engineering effort.  At Intellias, we have been researching this challenge closely for our clients, with the goal of offering a bespoke testing approach that leverages Software-in-the-Loop (SIL). 

Augmenting hardware testing 

The most mature OEMs stopped relying solely on benches and mule cars  for good reason. Physical rigs are scarce and serialize work, which means defects tend to surface late — exactly when changes are most expensive. You simply can’t parallelize thousands of scenario runs  on limited hardware, and reproducing edge cases becomes a constant struggle, and  critical network behaviour (CAN, FlexRay, Ethernet, DoIP) often goes untested until late integration phases. 

Hardware constraints introduce additional friction. Swapping components, dealing with flaky harnesses, and competing for limited lab slots can turn CI pipelines into calendar management exercises rather than fast engineering feedback loops. Compliance also suffers: evidence is scattered across lab logs, spreadsheets, and notebooks instead of being generated consistently per build. 

VECUs flip  this equation, allowing teams to run production code at the right abstraction level,  and mirror vehicle communications early — often in the cloud. Physical labs remain essential for what only hardware can prove, but everything else can shift left, become repeatable and reproducible, and scale efficiently. In this model, traceability becomes a byproduct of the process rather than a separate goal. A flexible combination of VECUs and a cloudbased pipeline enables earlier integration while leaving labs to focus on true hardware problems. Below is a practical, nohandwaving implementation using real tools and interfaces. 

How and why it works 

A VECU is a softwareintheloop representation of an ECU that allows OEMs to integrate, test, and debug software independently of physical rigs. Mature platforms now support multiple abstraction levels  — application, middleware, and OS — along with  standard automotive interfaces. This makes it possible to perform meaningful integration testing early and continue doing so at scale in CI. 

The flow is straightforward. A change lands, and the pipeline kicks off automatically, pulling the latest ECU code and associated tests. The build process produces an artifact the virtual ECU can execute, and a clean software model of the ECU spins up alongside a simulated invehicle network. Tests run in parallel in the cloud, so work that previously queued behind scarce benches now completes in minutes. 

As results come in, logs and metrics are captured automatically and linked to  relevant requirements. This creates clear, auditready evidence for safety and security with no additional overhead. If  a change fails to meet the quality bar, it is stopped at the gate; if it passes, it moves forward.  The loop is simple: commit, exercise the software in a faithful virtual environment, collect proof, and only ship green. 

The reference stack 

VECU runtime Several providers enable VECU solutions across abstraction levels 0 through 3. Synopsys Silver is  explicit about VECUs for application, middleware, and OS integration. It is commonly used for early testing and virtual integration ahead of hardware availability. 

On the platform side, the ongoing collaboration between Synopsys and AWS  supports the development of complex testing systems, helping delivery teams gain deeper insight into chip health across the entire lifecycle.  ETAS’ VECUBUILDER generates virtual ECUs as FMI 2.0/3.0 cosimulation FMUs,  making them portable across test toolchains (and easy to slot into existing SIL rigs).  When AUTOSARcentric workflows are required, it can also be paired with ISOLAREVE. 

 Network and restbus simulation 

 Elektrobit EB Assist is a tooling and hardware family  designed for ADAS and automated driving development and testing. It  supports data capture and replay, bus and rest bus simulation, and a modular framework for building, visualizing, and validating perception and control pipelines. 

 In a VECU context, EB Assist provides the surrounding restbus and network simulation — such as CAN, FlexRay, and Ethernet feeds — along with logging and data I/O. ADTF hosts and coordinates the overall processing pipeline around the VECU or SIL setup. 

Cloud and compliance backbone  On the platform and compliance side, the stack becomes more generic. Using AWS Graviton for ARMbased workloads, combined with managed, scalable artifact and logmanagement services and containerized, reproducible runners, creates an efficient and robust testing environment.  Polarion Automotive  serves as the ALM backbone, unifying requirements, change and variant management, test management, and auditready evidence across the lifecycle. It preserves endtoend traceability and offers prebuilt templates for ISO 26262, ASPICE, and ISO/SAE 21434. 

Design choices that pay off 

• Time-to-first-test  Keep it to single-digit minutes after a commit. Fast feedback changes behavior and quality more than any dashboard.  

• Shift left  Virtualize the bulk of integration tests before rigs. L1–L3 vECUs (e.g., Silver) and FMU flows (e.g., ETAS) enable you to retire “bench-first” setups without compromising fidelity.  

• Pick the right abstraction  Don’t over-model. Most programs see the best ROI at L2/L3—OS, no full plant model required.  

• Mirror the buses early  Many “late surprises” are really CAN/FlexRay/Ethernet mismatches. Cal/XCP and EB Assist toolboxes de-risk communications before hardware shows up.  

• Keep cloud and car close  If the vehicle targets Arm, run  Graviton in CI and follow SOAFEE-style patterns. Architectural parity = fewer porting headaches.  

• Make traceability a by-product  Aim for ~99% of tests linked to requirements and safety/security work items. When evidence is auto-generated per build, audits become exports — not projects.  

Closing 

VECUs won’t replace the lab, but  they fundamentally change how it is used.  Today, VECUs are already augmenting the workflows of many automotive organisations. As the technology matures, it will support even more configurations across additional programmes. We are at a stage where companies can meaningfully reduce latestage surprises, experience calmer release weeks, and improve overall quality by frontloading defects, mirroring network behaviour early, and turning compliance evidence into a pushbutton artefact.  

About Author

Alexander Horbachenko is a delivery leader at Intellias with over 10 years of experience driving digital transformation for enterprises and ventures, particularly within the mobility and cloud domains. Currently leading the Mobility Cloud Practice, he specializes in delivering innovative cloud solutions for OEMs, Tier 1 suppliers, and mobility providers.