{"id":14889,"date":"2026-02-02T11:07:05","date_gmt":"2026-02-02T10:07:05","guid":{"rendered":"https:\/\/www.iese.fraunhofer.de\/blog\/?p=14889"},"modified":"2026-06-18T19:04:13","modified_gmt":"2026-06-18T17:04:13","slug":"hypervisor-validation-for-the-automotive","status":"publish","type":"post","link":"https:\/\/www.iese.fraunhofer.de\/blog\/hypervisor-validation-for-the-automotive\/","title":{"rendered":"Hypervisor Validation for the Automotive: From Physical Labs to Virtual Testbeds"},"content":{"rendered":"

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Emulating Automotive Hardware in Practice<\/h2>\n

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.<\/p>\n

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.<\/p>\n

\"\"
Testbed Architectures in Comparison: HiL Testbed (left) vs. vHiL Testbed (right)<\/figcaption><\/figure>\n

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.<\/span><\/p>\n

Pre-Kernel Hypervisor Initialization Explained<\/h2>\n

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.<\/p>\n

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).<\/p>\n

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.<\/p>\n

Comparative Analysis: Physical vs. Virtual Validation<\/h2>\n

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:<\/p>\n\n\n\n\n\t\n\n\t\n\t\n\t\n\t\n\t
Aspect<\/th>Physical Testbed (GoldBox-based)<\/th>Virtual Testbed (QEMU-based)<\/th>\n<\/tr>\n<\/thead>\n
Resource Availability<\/td>Limited (resource allocation required, e.g., lab infrastructure)<\/td>Near-unlimited (concurrent deployment of virtual resource replicas)<\/td>\n<\/tr>\n
Setup Time<\/td>Extended (a.o., cabling, device calibration, access provisioning)<\/td>Minimal (instantaneous disk image loading on generic local computers)<\/td>\n<\/tr>\n
Portability<\/td>Static (execution environment tied to specific physical location\/s)<\/td>Dynamic (location-independent \"Lab in a File\" operation)<\/td>\n<\/tr>\n
Risks<\/td>Severe (hardware failures induce repair\/replacement costs)<\/td>Negligible (continuous software snapshot\/restore strategies applicable)<\/td>\n<\/tr>\n
Platform Dependecy<\/td>High (specialized base and interfacing hardware\/software required)<\/td>Low (OS-agnostic operation on common Windows\/Linux distributions)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n

Transforming Validation: The Impact of Virtualization<\/h2>\n

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.<\/p>\n