The Hidden Certification Cost of Ad Hoc Virtualization in Integrated Modular Avionics

Modern avionics programs are increasingly drawn to virtualization patterns inspired by the cloud. Organizations manage one application per virtual machine (VM) with minimal operating system images per workload and strong isolation between functions.

However, the way virtual machines are designed and supported by the underlying hypervisor is critical in the context of a DO-178C and DO-297 certification environment. Applying this model in an integrated modular avionics (IMA) context without careful planning can quietly increase the project schedule, expand verification effort, and complicate delta certification across the life of the system.

Any avionics project should carefully consider which path makes the most sense to meet its goals.

The unikernel approach

As engineers started to introduce multi-core architectures in safety-critical implementations more than a decade ago, they needed Type 1 hypervisors to support deterministically virtualizing hardware resources across one-to-many VMs. 

This capability provides a new element to the traditional IMA implementation. Multiple guest operating systems or single-purpose applications can now co-exist on the same hardware, yet maintain a safe, secure, and robust means of isolation from VM to VM. For this type of IMA evolution to succeed, however, it’s necessary to integrate traditional ARINC 653 features and certifiability into the hypervisor.

Recently, systems architects have been considering using unikernels – small, lightweight, single-address-space operating systems with the kernel included as a library within the application. In terms of facilitating IMA, the structure changes in a fundamental way if each ARINC 653 partition and/or real-time process within each partition is replaced with its own virtual machine. Instead of a single certified platform supporting many thin applications, the result is a growing number of VM stacks.

Although unikernels offer many benefits, the approach introduces several certification challenges for anyone operating in an IMA sphere.

Requirements and traceability expand. Responsibilities that were once handled in one place now need to be specified, analyzed, and verified across every VM image, along with system interactions that govern time and space partitioning (e.g., hypervisors). Traceability must extend from system safety requirements through every relevant layer of each tech stack.

Managing common and variant software becomes arduous. If multiple VMs share a common operating system, each VM must be verified across all configurations. If the VMs diverge by using different drivers, runtimes, or build options, the organization ends up managing multiple baselines, each with its own verification evidence and configuration identity.

Partitioning and interference analysis grows in scope. Timing behavior in one VM can depend on activity in others. The number of allowable VMs on one hardware architecture may differ significantly across other (e.g., ARM vs Intel vs RISC-V vs PPC). Virtualized device access introduces additional interaction paths that the customer must analyze and test. Not to mention the unique hardware behaviors that tend to vary system to system.

Multi-core processors make this even more complex. Interference can occur across cores, across VMs, and within each VM at the same time. That makes worst-case timing analysis harder to bound.

The result? More requirements to manage, more verification to perform, more baselines to track, and more work every time something changes.

But that isn’t the only issue.

Delta certification makes everything even more painful 

DO-178C delta certification allows incremental updates without repeating the entire certification effort, but only if changes can be clearly contained and shown not to affect the rest of the system. In a loosely structured unikernel approach, that containment becomes harder over time. Among the reasons:

• Application changes often affect the full VM image, including the operating system, drivers, toolchains, and runtime.
• Changes to the hypervisor potentially affect every VM that depends on it for partitioning and timing behavior.
• Multiple VM baselines create ongoing tracking and justification challenges with certification authorities, quality assurance teams, and configuration managers.

Virtualization is not the issue. The issue is how it is applied. 

In some cases, it can still be reasonable to use the approach of a single VM per application. For example, a small number of high-assurance applications, tightly controlled and stable guest operating system environments, or programs with strong automation for configuration management and regression testing can justify it. (Think of a VM for AI workloads that requires continuous tuning after deployment.) It can also be useful when combining legacy and modern systems or when stronger separation is needed than a shared operating system can realistically provide.

However, even in these cases, success depends on using a platform designed for certification rather than assembling a solution from general-purpose components. A platform designed for aviation certification keeps the assurance work in one place and makes it reusable instead of spreading it across many VM images. 

Helix Virtualization Platform, the hypervisor from Wind River, is built with this approach. It provides a single foundation where certification evidence, role boundaries, and system behavior are clearly defined and reusable across programs.

Helix Virtualization Platform is the result of Wind River prior investment and industry leadership for certifiable DO-178C DAL A evidence, Day 1, that can be reused as a software component under AC 20-148, alignment with DO-297 roles, and a structured approach to multi-core behavior and timing. It supported the first FAA Technical Standard Order (TSO) for a multi-core component.

Helix Platform includes planning data such as usage assumptions, constraints, and credit arguments. That gives certification applicants a clear starting point for reuse rather than expecting them to build everything from scratch.

Helix Platform also supports Independent Build, Link, and Load (IBLL), an avionics software development methodology that can be used to streamline delta-certification for ARINC-653 and DO-297 certification environments. IBLL, developed with the roles defined by DO-297 in mind, addresses the challenges associated with delta certification by allowing developers to compile, link, and configure system partitions separately across VMs so they can deliver against a stable certified platform without forcing a full system rebuild. 

IBLL permits additional spare VMs to be provisioned for future use. For instance, next-generation radio requires rapid integration after initial baseline is fielded. The practice isolates components so changes can be made without requiring the entire aircraft platform to be retested and recertified. Changes stay contained within the guest component rather than spreading across the full stack.

The practical effect is simple. Certification effort stays concentrated in one place instead of being repeated across many VM stacks. That reduces development project risk and overall time-to-market. 

Learn more about the features that Helix Virtualization Platform provides, and how it can help avionics projects.