SERVICES
IoT and Digital Engineering
Bringing Together IoT and Digital Engineering to Create Rich Experiences
Highlights
- Automotive software has evolved from a supporting function to become the primary driver of innovation, safety, and customer experience.
- The rise of software-defined vehicles has accelerated the demand for scalable, efficient, and cost-effective development, positioning ECU virtualisation at the core of this transformation.
- By enabling faster testing, hardware-accurate simulation, and seamless integration, virtualisation is redefining how the industry designs, validates, and delivers next-generation mobility solutions.
On this page
On this pageinpage
Changing foundations
The automotive industry has long relied on methods such as Model-in-the-Loop (MIL) and Software-in-the-Loop (SIL) testing as the backbone of Electronic Control Unit (ECU) development, particularly when software was simpler and ECUs were far less complex than they are today. Back then, with fewer interdependencies and straightforward systems, testing standalone algorithms and ECUs was enough to catch issues early and prevent surprises during integration. However, as vehicle electronics grow more advanced and interconnected, the approach to ECU development and virtualisation is rapidly evolving.
Fast forward to today, and the industry is experiencing a dramatic shift. The emergence of software defined vehicles (SDV), high-performance computing (HPC), and zonal architectures has resulted in a surge in software complexity. Rather than assigning a dedicated ECU for each function, designers are now utilizing HPCs orchestrated by hypervisors and containers. This architectural evolution necessitates more advanced virtualisation strategies.
Virtualisation levels
The automotive developers’ community has been using Levels 0, 1, and 2 in the form of MIL and SIL. Level 3+ virtualisation is a game-changer, enabling the validation of HPCs running hypervisors. Here, each application operates in its own container, enabling developers to test multi-OS environments that seamlessly combine AUTOSAR (Automotive Open System Architecture) and non-AUTOSAR features on a single ECU.
Certain situations, however, require deeper exploration, which is where Level 4 virtualisation comes in. For features relying on dedicated hardware accelerators, such as those in Autonomous Driving (AD) and Advanced Driver Assistance Systems (ADAS), Level 4 ensures correct hardware usage. It also proves invaluable for safety-critical applications, penetration testing, and leveraging safety features like safety islands.
Leap to Level 4
Advancing from Level 0 to Level 3 is a gradual journey with steady improvements in tools, skills, and investments. However, reaching Level 4 is a significant leap. Unlike earlier stages that rely on host-simulated environments, Level 4 requires cycle-accurate silicon models and precise target simulations. This demands early collaboration with silicon vendors and auto OEMs, as development cannot progress without access to virtual hardware models.
While hardware simulation for SDVs may seem at odds with the idea of hardware-agnostic systems, true independence can only be achieved through rigorous, multi-platform software validation. Level 4 virtualisation enables early testing of software portability and compatibility across different hardware, ensuring robust performance from the design stage.
Level 4 virtualisation comes at a cost. It requires unique tools, licensing virtual prototypes from silicon vendors, and robust compute infrastructure—on-premises or in the cloud. This means investments soar compared to Level 3.
Complicating matters further, most vendors offer hardware models only for their central System on Chip (SoCs). At the same time, real-world ECUs are often systems-on-modules that incorporate multiple peripherals, such as Analog-to-Digital Converters (ADCs), memory, and various interfaces. Modeling these additional chips slows down simulations, making it essential to choose virtualisation levels judiciously for each application.
Figure 1
Levels of Virtualisation- Need for Level 3.X
Figure 1
Flexible strategies
Not all developers require the latest cutting-edge technology. Those who aren't working near the hardware level can opt for Level 3 or intermediate solutions. More industry experts are investigating methods that lie between Level 3 and Level 4, such as:
- “ARM on ARM” simulation – ECU virtualisation on local machines with ARM CPU to perform instructions set compatible simulation for ARM based SoC.
- “SoC in Cloud” using ARM-based Virtual Machines (VMs) – Using Cloud-based Virtual Machines with ARM processor (e.g. Amazon EC2 – Elastic Compute Cloud) closely matching with target platform to simulate ARM-based SoC
- Custom simulation models built on open-source components – Integrate open-source models from GITHUB processors, GPUs and peripherals to create a close replica of the target SoC
- System C-based designs – Create a custom-built behavioural model of the target SoC using System C
These hybrid strategies allow targeted, detailed hardware modelling where it matters most, and lighter simulation elsewhere, a smart balance of accuracy and efficiency.
The future
ECU virtualisation is shaping the future of mobility, and open collaboration is the key to unlocking its full potential. By embracing open-source platforms and modular simulation systems, the industry can deliver testing solutions that are smarter, faster, and tailored to the unique needs of every developer and application.
ECU virtualisation is evolving rapidly in tandem with advancements in automotive technology. By comprehending the challenges and opportunities present at each level and through collaborative efforts to develop flexible, open tools, the industry can drive the development of faster, safer, and more innovative vehicles into the future.