For years, avionics architects measured success through consolidation. If multiple functions could share a processor, the design was considered efficient. Integrated Modular Avionics (IMA), multicore processors, and increasingly capable systems-on-chip have accelerated that trend, allowing more applications, suppliers, and criticality levels to coexist on a common hardware platform.
Consolidation has delivered significant benefits. It has reduced size, weight, and power (SWaP), lowered hardware costs, and simplified physical system architectures. But as multicore platforms become the foundation for modern avionics and mission systems, a more important question is emerging.
The answer matters because every component placed in the trusted base becomes part of the certification burden. Every line of code at the foundation of the system must be specified, verified, configuration-managed, maintained, and ultimately justified to certification authorities throughout the life of the program. The question is no longer simply how many applications can coexist on a processor, it's how much software must stand between them.
Two Different Philosophies
There are two fundamentally different approaches to building a virtualized, mixed-criticality system. The first relies on a large, feature-rich hypervisor that actively manages the environment. Such platforms often provide scheduling services, device virtualization, health monitoring, shared-resource management, and a broad collection of runtime capabilities intended to support multiple guest operating systems.
The second takes a different approach. Rather than adding services to the foundation, it seeks to minimize the foundation itself. A separation kernel establishes strict boundaries between partitions, assigns resources according to a fixed configuration, and relies on hardware mechanisms to enforce isolation. Everything that is not essential to separation is pushed out of the trusted base. Both approaches can support multiple workloads on a common processor. The difference lies in how much software must be trusted to make that possible.
Why Trusted Base Size Matters
The size of the trusted base has implications that extend far beyond implementation details. In safety-critical systems, trusted software is not merely operational software. It becomes part of the certification argument. As functionality accumulates within a virtualization layer, so does the scope of what must be analyzed and verified. Schedulers, resource managers, device emulation services, monitoring functions, and communication mechanisms all become elements whose behavior must be understood and justified. A larger trusted base may provide additional flexibility, but it also expands the amount of software that carries high-assurance responsibilities. Over the lifetime of a program, that responsibility can become expensive.
Where the Certification Costs Actually Appear
The consequences of architectural choices are often difficult to see during initial integration. They become much more visible when systems evolve, certification activities begin, or modifications are introduced years later.
A large virtualization layer concentrates significant functionality into a common foundation. Because that foundation participates directly in isolation, resource management, and system behavior, a substantial amount of software becomes part of the trusted computing base.
A minimal separation kernel takes a different approach. By focusing exclusively on partitioning and isolation, it limits the amount of functionality that must be included in the highest-assurance portion of the system. The result is not merely a smaller attack surface from a cybersecurity perspective. It is also a smaller verification surface from a certification perspective.
Partitioning and Worst-Case Timing
Timing analysis has always been challenging in safety-critical systems. Multicore processors have made it significantly more complex. When isolation depends heavily on runtime software decisions, schedulers and resource managers become part of the timing argument. Their behavior must be understood under both normal and worst-case operating conditions. Architectures based on static allocation simplify that picture. When processor resources, memory regions, and I/O assignments are defined before runtime and remain fixed throughout operation, fewer software elements participate in the timing path. The certification effort does not disappear, but the number of variables that must be analyzed is reduced.
Multicore Certification
This distinction becomes even more important on modern multicore processors. Certification guidance such as CAST-32A and AMC 20-193 has shifted the industry's focus toward demonstrating freedom from unintended interference. The challenge is no longer simply proving that an application performs its intended function. Engineers must also demonstrate that neighboring applications, shared resources, and contention mechanisms cannot compromise that behavior.
Architectures that rely extensively on runtime mediation must account for the behavior of the mediating software itself. Resource managers, schedulers, and shared infrastructure become part of the interference analysis. Architectures based on static allocation and hardware-enforced separation begin from a different position. By minimizing runtime decision-making and reducing shared infrastructure, they narrow the scope of what must be analyzed and justified.
The certification challenge remains substantial, but the argument becomes more explicit and easier to bound.
Requirements and Traceability
Certification is ultimately built on requirements. As trusted infrastructure grows, isolation requirements, resource-management requirements, and safety assumptions tend to spread across multiple components and interfaces. Traceability becomes more extensive because the architectural responsibility is distributed across a larger collection of software elements. A smaller foundation concentrates responsibility in fewer places. The isolation model becomes more explicit, and the resulting certification evidence can often be more straightforward to maintain over time.
Delta Certification
Perhaps the most significant differences appear during system evolution. Every long-lived platform changes. New sensors are added. Security updates are introduced. Mission capabilities evolve. Hardware is refreshed. The cost of these changes is rarely determined by the modification itself. It is determined by how far the effects of that modification propagate through the architecture. When substantial functionality is concentrated in a common layer, changes to that layer can have broad implications across the system. Verification activities expand because multiple functions depend on the same infrastructure.
Architectures that minimize shared dependencies naturally limit the scope of change. Updates remain more tightly bounded because fewer functions rely on common runtime services. Over the lifetime of a program, this containment can become one of the most valuable characteristics of the architecture.
Isn't One Function Per Partition Just More Complexity?
A common criticism of highly partitioned systems is that they create too many independent environments to manage. At first glance, the concern appears reasonable. More partitions seem to imply more operating environments, more configurations, and more complexity. But partition count is not necessarily the right metric. The real certification burden is driven by trusted software, assurance level, and verification scope.
A collection of small, tightly bounded partitions running only the software they require may represent a significantly smaller certification effort than a handful of large environments supported by an extensive common infrastructure layer. The critical question is not how many partitions exist.
The critical question is how much software must be trusted, verified, and maintained within the certification boundary. Counting partitions is often measuring the wrong thing. Counting what must be certified is usually measuring the right thing.
The Principle That Matters
Virtualization itself is not the issue. The industry has clearly demonstrated the value of consolidating multiple workloads onto shared computing platforms. That trend will continue as multicore processors become even more capable.
The more important question is architectural. What belongs in the trusted base? Every function placed into the foundation becomes a long-term commitment. It becomes software that must be verified, maintained, assessed for cybersecurity impact, evaluated for interference effects, and justified during future certification activities.
In a world of increasing multicore consolidation, tighter schedules, and growing assurance requirements, the most sustainable architectures are not necessarily the ones that do the most in the foundation. They are the ones that require the foundation to do the least. Because when it comes to high-assurance systems, less in the trusted base often means less to certify.
For More Information, Click Here