The advancement of Software-Defined Vehicles (SDVs) requires continuous and rigorous validation of complex, safety-critical software stacks. However, development teams frequently encounter bottlenecks due to reliance on specialized infrastructure for physical system components, such as ECUs/domain controllers based on dedicated hardware devices. This dependency limits scalability, extends integration cycles, and restricts concurrent as well as continuous testing.
To address these limitations, we at Fraunhofer IESE are advancing quality assurance methods to efficiently decouple software verification and validation from physical test environments by means of, e.g., hardware emulation. In this article, we outline a framework that combines QEMU emulation with a pre-kernel EFI initialization strategy to achieve high-performance hypervisor validation in a fully virtualized setting. Furthermore, we illustrate how this virtual testbed was actively utilized in our recent collaboration with Perseus Co., Ltd., a provider of automotive virtualization solutions and developer of the PEGASUS hypervisor. By shifting the evaluation process from a hardware-centric (e.g., NXP GoldBox) to a scalable software-based environment, we demonstrate a robust path for testing complex architectures and accelerating the validation of both open-source and proprietary hypervisors without hardware constraints.
As automotive E/E architectures evolve toward SDVs, hypervisors are increasingly becoming a foundational technology for enabling hardware-software decoupling, mixed-criticality workload consolidation, and lifecycle-independent software deployment. In this context, automotive-grade hypervisors such as PEGASUS from Perseus Co., Ltd. are emerging as key building blocks for next-generation SDV architectures.
Emulating Automotive Hardware in Practice
To systematically address the constraints of hardware-focused test benches, our approach leverages the Quick Emulator (QEMU) to construct a high-fidelity virtual testbed. QEMU acts as a cross-architecture bridge, enabling generic x86 host systems to accurately execute the ARM64 instruction set, which is native to modern automotive silicon. The primary objective is to establish a virtualized execution environment that remains completely transparent to the software stack, rendering the physical and virtual environments functionally indistinguishable from the perspective of the software code to be deployed.
As illustrated in the figure below, our methodology involves deploying the emulator on a common host operating system (OS), such as Microsoft Windows, to establish a virtualized „bare metal“ foundation. Directly upon this layer, any type-1 hypervisor can be initialized, irrespective if it is an open-source implementation of Xen or a proprietary industrial solution such as the PEGASUS hypervisor from Perseus Co., Ltd.
Within this emulated environment, the hypervisor executes its core system-level functions exactly as it would on physical hardware. It manages memory allocation, handles hardware interrupts, and successfully instantiates the privileged domain (Dom0). This architectural setup ensures that critical project deliverables, including target hypervisor images and API integrations, can be rigorously developed and quality-assured in a stable, fully software-defined runtime environment.
Pre-Kernel Hypervisor Initialization Explained
Establishing the architectural stack for a virtual testbed presents a specific initialization challenge. Commonplace virtualization environments and standard Extensible Firmware Interface (EFI) implementations are inherently optimized to boot a conventional OS directly. Consequently, the default boot sequence expects to hand over system control to an OS kernel, rather than a bare-metal hypervisor. To successfully deploy the hypervisor layer within the QEMU environment, it is therefore necessary to intercept and redirect this standard execution flow before the primary OS is initialized.
Rather than implementing intrusive modifications to the emulator’s core source code, our approach focus on adapting the EFI firmware layer, which is the initial interface executed upon system power-on. Specifically, we reconfigured the boot sequence by designating the compiled hypervisor binary as the default boot application (BootAA64.efi).
Through this pre-kernel initialization hack, the QEMU virtual machine systematically loads the hypervisor first. Upon execution, the hypervisor assumes full architectural control: it parses its configuration parameters, initializes the emulated hardware interfaces, and subsequently bootstraps the Linux kernel as a privileged guest domain (Dom0). By the time the Dom0 environment is fully active, and the default login interface appears, the hypervisor is already established as the foundational management layer, transparently orchestrating system resources.
Comparative Analysis: Physical vs. Virtual Validation
Transitioning from a hardware-centric to a virtualized test-driven development model yields improvements in operational efficiency. The following table contrasts traditional hardware-in-the-loop (HiL) approaches with our QEMU-based virtual HiL (vHiL) solution:
| Aspect | Physical Testbed (GoldBox-based) | Virtual Testbed (QEMU-based) |
|---|---|---|
| Resource Availability | Limited (resource allocation required, e.g., lab infrastructure) | Near-unlimited (concurrent deployment of virtual resource replicas) |
| Setup Time | Extended (a.o., cabling, device calibration, access provisioning) | Minimal (instantaneous disk image loading on generic local computers) |
| Portability | Static (execution environment tied to specific physical location/s) | Dynamic (location-independent „Lab in a File“ operation) |
| Risks | Severe (hardware failures induce repair/replacement costs) | Negligible (continuous software snapshot/restore strategies applicable) |
| Platform Dependecy | High (specialized base and interfacing hardware/software required) | Low (OS-agnostic operation on common Windows/Linux distributions) |
Transforming Validation: The Impact of Virtualization
This virtualized approach is not merely a workaround for hardware scarcity; it represents a prototype for the next generation of scalable continuous software engineering. Specifically, it aligns with several key trends in the automotive industry.
-
Shift-Left Validation & CI/CD Integration
By encapsulating the entire environment (hypervisor, kernel, and configurations) into a single, shareable disk image (a „Lab in a File“), development teams can integrate hypervisor testing directly into automated Continuous Integration/Continuous Deployment (CI/CD) pipelines. Validation occurs concurrently and iteratively with code repository commits, long before physical integration becomes inevitable.
-
Hardware-Agnostic Workflows
The QEMU layer acts as an equalizer, ensuring that regardless of a developer’s local workstation (e.g., Windows desktop or Linux server), the underlying emulated ARM64 environment remains strictly consistent. This guarantees deterministic validation results across distributed teams and versioned system increments.
-
Safe Test-driven System Development
Engineers can deliberately inject faults, corrupt boot loaders, and execute critical failure scenarios to validate the hypervisor’s resilience. Because the environment is virtual, these rigorous tests carry zero risk in terms of damaging any hardware components.
These key trends indicate the transition of automotive systems engineering into a software-centric counterpart requiring any methodologies used to validate those constantly evolving systems to mature accordingly.
Towards Virtual Continuous Engineering for SDVs: From Lab to Laptop
As automotive platforms move toward software-defined architectures, validating safety-critical hypervisors becomes increasingly important. Our virtual testbed provides an efficient framework for accelerating the development and quality assurance of advanced automotive virtualization platforms such as PEGASUS, that is an automotive Type-1 hypervisor specifically designed by Perseus Co., Ltd. for safety-critical vehicle platforms. Supporting both CPU and MCU architectures, it enables deterministic execution, mixed-criticality workload consolidation, and strong isolation required by next-generation SDV architectures. The platform has been engineered to satisfy stringent automotive functional safety requirements and represents a practical foundation for hardware-software decoupling across the vehicle E/E architecture.
Our jointly established solution enables engineers to evaluate complex SDV architectures earlier, faster, and at significantly lower cost while maintaining confidence in system safety, security, and determinism. In this context, the combination of QEMU’s cross-architecture capabilities with corresponding EFI boot configurations, solves a fundamental bottleneck in hypervisor validation. Therefore, QEMU-based emulation now serves as a critical, foundational component within our virtual testbed ecosystem, establishing a robust, highly scalable environment that mirrors physical constraints while offering the flexibility of virtual solutions.
Building upon the virtual testbed concept described in this article, our upcoming blog posts will gradually introduce the complete validation framework. Jointly developed by Fraunhofer IESE and Perseus Co., Ltd., the final testing environment will leverage this exact QEMU-based environment to systematically validate the PEGASUS hypervisor. By enabling advanced fault injection and granular system monitoring entirely in software, the collaborative results of this project will empower engineers to iterate faster and build unprecedented trust into safety-critical vehicle architectures. In addition, PEGASUS will demonstrate how automotive hypervisors can serve as a foundational layer for realizing hardware-software decoupling across both CPU and MCU domains, enabling the long-term vision of software-defined vehicles.
Accelerate Your SDV Development
Are you looking to streamline your software-defined vehicle development by mitigating hardware dependencies and establishing scalable virtual testbeds? Contact our Virtual Engineering team to explore our simulation capabilities and hypervisor validation expertise.
