Introduction
In the article on Software-Defined Vehicles (SDVs), we explored how the automotive industry is entering a new era — one where software plays a central role in vehicle functionality, adaptability, and innovation. As we look toward the development of future vehicles, it’s no longer enough to understand only mechanical systems; understanding software development processes has become equally essential. Unlike traditional hardware development, which has long followed the structured V-model, software development in the SDV context is increasingly a hybrid of V-model and DevOps methodologies. While the strengths of the V-model — particularly in safety-critical systems — remain highly relevant, DevOps principles such as continuous integration, testing, and deployment are becoming vital in managing the fast-paced and iterative nature of A key component of this evolution is testing and validating SDV software (SDV.SW-DEV) – the software that will eventually run on the vehicle’s onboard systems (SDV.onboard). However, development cycles often outpace hardware readiness. This creates a challenge: how to test software when the physical vehicle or ECU hardware isn’t yet available?automotive software. The answer lies in virtual ECUs (vECUs) and virtual environments — powerful tools that enable early-stage testing and continuous validation throughout the development cycle.
This article will take a closer look at how this works, and what such a testing setup requires. It is structured as follows:
- An overview of a scalable, modern test infrastructure suited for SDV development
- Classic Autosar software stack and vECU level’s
- Comparison of hardware-based- and vECU testing
Classic Autosar software stack and vECU level’s
The development and testing of software using virtual Electronic Control Units (vECUs) has become a key enabler for accelerating vehicle development cycles. By allowing early software verification without relying on physical hardware, vECUs significantly enhance productivity and reduce time-to-market in the era of SDV’s. Before diving into the different abstraction levels of a vECU, it is essential to understand the AUTomotive Open System ARchitecture (AUTOSAR). AUTOSAR provides a standardized architecture aimed at improving software reuse, scalability, and interoperability across the automotive industry — key goals aligned with the SDV vision. The architecture is built around this core layers:
- Application Software (ASW): Software components (SWC) communicate with other components and/or services via the RTE.
- Runtime Environment (RTE): Provides communication services for the application software. Makes Software Components independent from the mapping to a specific ECU.
- Basic Software (BSW): Provision of common system services for the application layer. Enabling the advanced functions of the vehicle such as ADAS, diagnostics and communication systems. Ensuring smooth communication between hardware and applications
- Microcontroller Abstraction Layer (MCAL): Makes higher software independent of Microcontroller
- Services Layer: Offers Memory Services, Diagnostic Services, ECU state management. Provides basic services for application and basic software modules
Depending on the depth and purpose of testing, vECUs are categorized into different maturity levels. These levels define how close the virtual representation is to the production ECU environment. Below is a summary of the vECU levels commonly used in the industry:
Each higher level of vECU adds more integration, fidelity and testing capability, making them invaluable tools in both software development and hardware-software integration.
Comparison of hardware-based- and vECU testing
One of the most compelling reasons why vECUs are crucial in software development—especially in the context of SDVs—is the significant time savings they offer throughout the development lifecycle. Figure 2 illustrates a typical vehicle development timeline, mapping the different vECU stages in comparison to traditional hardware-based testing. It clearly demonstrates how testing and validation can start significantly earlier than in conventional, hardware-dependent development processes.
Testing with vECU Level 1 can begin as early as 24 months before SOP (Start of Production). At this stage, developers focus on the application layer of the software. A basic operating system (Services Layer) provides the necessary runtime support to validate early software components.
Level 1 is particularly suitable for testing Software Components (SWCs) that require minimal input from lower software layers, hardware interfaces, or signals from other ECUs or sensors. A typical example would be in-vehicle applications that operate independently of sensor data or vehicle network communication.
As development progresses to vECU Levels 2 and 3, more realistic and production-near software and hardware components are integrated. These levels allow for the simulation of vehicle network communication, enabling the reception of signals from Restbussimulation or even other vECUs (as well as cloud-based interfaces). In the Connected Car and Infotainment domains, this allows for comprehensive testing of use cases such as eSIM connectivity, Core Services, MQTT messaging and other online features which requires as basic the Online Enabler.
The most advanced vECU Level 4, closely replicates a production-ready ECU, making it possible to perform system-level integration testing. This level enables multiple vECUs to interact with each other, simulating real-world in-vehicle network behavior. It becomes feasible to test interconnected services such as Remote Battery Charging, Remote Lock/Unlock, data collection systems and other cloud-connected features. This level not only boosts software robustness but also enables the simulation of end-to-end use cases prior to hardware availability.
In traditional V-model-based development, software implementation and validation are completed at the SOP. However, in the SDV world, development continues after SOP, as updates, bug fixes, and feature enhancements must be delivered to customers throughout the vehicle’s lifecycle. This requires a seamless interplay between Development, Continuous Integration (CI), and Continuous Testing (CT) to ensure that new features meet high quality standards quickly and reliably.
Finally, it’s important to emphasize once more the time savings enabled by vECUs. In traditional hardware-based development, teams often had to wait for prototype hardware to test and validate their software—delaying feedback loops and increasing the risk of integration issues close to SOP. While this may be acceptable for simple functions, it becomes a major bottleneck for complex features. Without early validation through vECUs, the software maturity needed for SOP might not be achievable on time.
An overview of a scalable test infrastructure suited for SDV development
After having introduced the classic automotive software stack and the various vECU levels with their respective application scenarios, Figure 3 presents a high-level schematic view of how a test infrastructure for SDVs could be organized in practice.
Figure 3 is structured into two major parts:
Right Side – vECU Hardware Infrastructure
On the right-hand side, the vECU infrastructure is illustrated. This infrastructure can be flexibly configured based on project needs:
- It may consist of pure S/HiL hardware setups,
- a cloud-based virtual test environment, or
- a hybrid solution that combines both physical and virtual resources.
All these setups are interconnected and orchestrated by a middleware layer, ensuring seamless communication and interoperability between distributed components.
Left Side – Modeler- and Testing Team
On the left-hand side, we see the consumers of the test infrastructure, which typically include developers, integration teams, and validation engineers. TE Force supports and assists customers according to their specific requirements in these areas, providing expertise especially in testing and validation activities. However, depending on the test objectives and abstraction levels, the following software components can be modeled and tested within this environment:
- ASW: Functional modules such as comfort features, diagnostic logic, or Connected Car applications.
- RTE: The simulation of the software communication layer between ASW and BSW to test signal flow and logical interactions.
- BSW: Components like the operating system, communication stacks (e.g., CAN, Ethernet), memory management, and diagnostics—either in full or simplified form, depending on the vECU level.
- Communication Interfaces: Simulation of both in-vehicle networks (e.g., CAN, LIN, FlexRay) and cloud communication protocols (e.g., MQTT, HTTP) for testing online features and backend integration.
- Networked Features: Use-case driven testing of complex, interconnected functionalities involving multiple virtual ECUs—such as Remote Services (e.g., “Remote Lock/Unlock”, “Remote Battery Charge”) or Over-the-Air Updates.
- Test Logic and Fault Behavior: Integration of automated test cases, fault injection scenarios, restbus simulations, and hooks for Continuous Integration (CI) and Continuous Testing (CT) pipelines.
Interconnectivity Between Systems
The left and right sides of the architecture are connected using modern interfaces, such as Ethernet-based communication or browser-based user interfaces. This enables developers and testers to access the entire environment remotely from a single workstation, configure virtual ECUs, inject faults, monitor signals, and execute test campaigns—all without needing physical hardware on their desk.
Our Commitment
As a company specializing in the field of SDV, we support our customers in successfully bringing it to the market. We accompany them from the early development phase through to series production, help with the overall integration and ensure that all safety and quality requirements are met. With our expertise in the integration of software and hardware, we enable companies to make the most of the benefits of SDVs and future-proof their vehicles.
Source
- AUTOSAR. AUTOSAR. Available online: https://www.autosar.org (accessed on 08 April 2025).
- .Jeong,S., Kwak,Y., Lee,W.J. Software-in-the-loop simulation for early-stage testing of autosar software component. In Proceedings of the 2016 Eighth International Conference on Ubiquitous and Future Networks (ICUFN), Vienna, Austria, 5–8July 2016; pp.59–63.
- King, P., Copp, D Hardware in the loop for automotive vehicle control systems development. In Proceedings of the 2004 Mini Symposia UKACC Control, IET, Bath, UK, 6–9 September 2004; pp.75–78.
- Jordan, Y.; von Wissel, D.; Dolha, A. ; Mauss, J. Virtual ECUs Used to Develop Renault’s Engine Management Software. ATZelektronik Worldw. 2018,13,36–39. [CrossRef]
- Vector. vTeststudio—The Authoring Environment for Test Development. Available online: vTESTstudio für das Testdesign von Steuergeräten | Vector (accessed on 23 April 2025).
- Vector. vVIRTUALtarget-Virtual Test Environment. Available online: Virtuelle Steuergeräte mit vVIRTUALtarget einfach erstellen | Vector (accessed on 23 April 2025).
- Kompilieren von Automobilsoftware zu eigenständigen virtuellen Steuergeräten. Available Online: VECU-BUILDER zur Erzeugung virtueller Steuergeräte | ETAS (accessed on 8 April 2025).
- Lauterbach. PowerDebug System-High-End Debugger. Available online: https://www.lauterbach.com/products/debugger/ powerdebug-system (accessed on 25 April 2025).
- Setting the foundation for Software-Defined Validation & Verification (V&V) , Available online: Software-defined validation and verification – Bosch SDS (accessed 27 April 2025)
