Towards the Virtual Vehicle
PreviousDetailed Validation: SDVs and SimulationNextCase Study: Multi-Supplier Collaboration on Virtual Platform
Last updated
Last updated
The evolution from vehicle simulation to a fully virtualized vehicle, including virtual ECUs and virtual bus systems, enables comprehensive testing of software and system integration in a digital environment, accelerating development while reducing dependency on physical prototypes.
Virtualization allows software or hardware to run on generalized, widely available hardware, such as consumer-grade systems, instead of specific, high-cost controllers. By virtualizing components like controllers, developers can replace limited, specialized hardware with scalable solutions running on Windows or Linux environments. This approach reduces costs, improves resource availability, and accelerates development cycles. It enables faster iterations, as engineers can test and validate systems without waiting for physical controllers, making software-defined vehicle development more efficient and accessible.
Virtualization plays a pivotal role in the SDV development lifecycle by bridging the gap between simulation and physical testing. It allows application code to run seamlessly in both virtual ECUs (vECUs) and real hardware ECUs, enabling environmental parity for consistent development and validation. This approach significantly reduces hardware dependencies, accelerates development timelines, and improves collaboration for globally distributed teams. Moreover, virtualization supports cloud-based management of test environments, simplifying tasks like cloning and scaling, ultimately enhancing efficiency and flexibility across the development process.
The different virtualization levels represent a gradual progression from abstract simulations to fully realistic, hardware-level testing. This progression is necessary to balance speed, cost-efficiency, and accuracy as development advances.
Level 0 (Controller Model): Simulates the controller logic at a high abstraction level, focusing on basic functionality validation.
Level 1 (Application Level): Introduces software applications, testing interactions within the application layer.
Level 2 (Simulation BSW): Adds a simulated basic software (BSW) layer for more detailed behavior testing.
Level 3 (Production BSW): Tests production-grade BSW, ensuring compatibility and integration.
Level 4 (Target Binary): Deploys the actual target binary, validating software in near-real conditions.
This tiered approach ensures early-stage development is fast and cost-effective while allowing a gradual transition to higher-fidelity testing closer to physical hardware.
The following example illustrates the integration of virtualization into different types of ECUs within a Software-Defined Vehicle (SDV). On the left, a Virtual High-Performance Compute ECU runs on standard hardware with a Linux-based environment, enabling applications to interact through a Vehicle API. This abstraction allows flexibility, as the virtualized system mimics real hardware behavior while being cost-efficient and scalable.
On the right, a Virtual Endpoint ECU, such as AUTOSAR Classic, runs on a simulated microcontroller stack. It mirrors the structure of real embedded ECUs, with abstraction layers, service layers, and drivers. Communication between these systems happens over virtual buses like vCAN or vETH, enabling seamless interaction.
Together, these setups reduce dependencies, speed up development, and allow testing across distributed environments. By combining virtual high-performance compute units with virtual microcontroller-based ECUs, teams can validate cross-domain functionality and optimize vehicle behavior cost-effectively and early in the development process.
In co-simulation of multiple virtual ECUs (vECUs), time synchronization is critical to ensure consistent communication and execution across all components. The goal is not to match real-world speed but to maintain a unified time domain so that all sub-systems, regardless of complexity, run on the same relative timeline. Without proper synchronization, the simulated components may drift out of sync, leading to misaligned data exchanges, invalid test results, and incomplete validation of interactions between systems.
Virtual buses, such as vCAN or vETH, facilitate synchronized communication between the vECUs. These buses ensure that inputs, outputs, and messages are transmitted in a harmonized manner, reflecting the intended interactions of the physical system. Even if the simulation operates slower than real-world execution, all components must adhere to the same simulated time. This is especially vital for validating event-driven systems, where delays or timing mismatches can introduce unintended behavior, reducing the reliability of test results.
Ultimately, accurate time synchronization guarantees that the overall system behaves as a cohesive unit, enabling precise testing, validation, and verification in complex SDV simulations.
