Virtualization: A FACE lift for vehicle control

Story

March 15, 2021

Recent experience in working with vehicle-control projects – particularly those based on multicore processors – has proven the use of CPU virtualization as a powerful tool that compliments operating systems in resolving integration conflicts between software components with platform requirements that differ greatly in terms of API [application programming interface] compatibility and architectural assumptions.

The Future Airborne Capability Environment (FACE) standard views virtualization as primarily a hardware-consolidation tool. But as the world presses forward in the development of unmanned vehicles, the need to integrate vehicle-control and mission-system computing will become mandatory and the concerns more pertinent. Given its capacity to deliver on core FACE principles where hard real-time control is essential, virtualization deserves further consideration.

The vision of FACE

For many years, military systems have largely been based upon proprietary applications, middleware, operating systems, and/or hardware. This situation resulted in problems that included long lead times, high costs, and few opportunities to reuse existing technologies. Putting system modifications out to competitive tender has been impossible because the only suppliers equipped to make changes have been the suppliers of the original system.

The FACE Consortium – a partnership between industry suppliers, government experts, academia, and customers – was formed to address those issues. Standardizing approaches for using open standards within military avionics systems promised to lower implementation costs, accelerate development, ensure robust architecture and consistently high-quality software implementation, and maximize opportunities for reuse.

Virtualization in avionics systems

Many of the benefits of multicore virtualization in embedded avionics systems are well documented. The ability to consolidate multiple legacy single-board computers (SBCs) with various operating systems and applications into a single, multicore, virtualized SBC is widely acknowledged to be the most tangible benefit to next-generation avionics. However, the capacity of CPU virtualization and hypervisors to provide benefits relating to real-time performance, software composability, and architectural robustness are less well-known to the veteran embedded software community. The following sections discuss these benefits as applied within the context of the FACE reference architecture: Dedicated partitioning segment, simplifying space for real time, and increasing portability and reuse.

Dedicated partitioning segment

Over the last ten years, there have been considerable advances in the ability to run multiple operating systems on a single processor through CPU virtualization. While popularized and universally adopted in the IT world, the underlying hardware has features that are just as appealing to embedded engineers concerned with robustness and predictability.

In traditional platform software design, each processor hosts a single operating system (OS) kernel that is responsible for managing memory allocation, execution scheduling, interrupt routing, exception handling, peripheral control, and bus multiplexing. Now, virtualization-enabled multicore hardware is now capable of accommodating many kernels, with each kernel allocated subsets of resources of varying types and sizes. Multiple independent software runtimes can therefore be implemented on a single device without the interference of a common kernel and consequentially common mode failure hazards. Such capabilities enhance fundamental architectural properties relating to safety and security concerns.

From a security perspective, the use of built-in CPU virtualization features to isolate hardware-security functions, and separate application-runtime services from hardware control interfaces, goes a long way to assure system robustness. Such design techniques eliminate commonly exploited threat vectors that result in security-policy bypass, privilege escalation, and loss of CPU control altogether.

From a safety perspective, upholding threshold design principles – predictability, integrity, and high availability – is greatly aided using virtualization partitioning features such as:

• DMA channel isolation
• Shared last-level cache partitioning
• Memory bus bandwidth allocation
• Independent interrupt, event, and exception handling

The ability for software partitions to be fortified and controlled with greater fidelity at hardware levels aligns with FACE ideals. The diagram shown in Figure 1 introduces the notion of a “Hardware Partitioning Segment” fulfilled by a hypervisor to the FACE reference architecture. The depiction shows a hypervisor isolating two sets of software on two different CPU cores. Each set is configured with FACE-conformant components. Each set of software is granted greater partitioning properties over a single OS-hosted design where the device drivers and internal service are separated.

[Figure 1 | Example FACE configuration with CPU virtualization-assisted hardware partitioning segment.]

Simplifying space for real time

Adding yet another segment into FACE would be a significant undertaking. Introducing another class of technology and layer of software beneath an OS may seem counterproductive to real-time and safety-conscious developers wary of complexity. But the hardware partitioning and multiplexing capabilities presented by CPU virtualization presents the opportunity to encapsulate and map subsets of runtime features for critical tasks on a processor that is simultaneously hosting applications with inherently richer runtime and service dependencies.

For example, suppose a vehicle-control health-monitor application, such as a high-­frequency majority-voting CBIT [continuous built-in test] needed for TMR [triple-­modular redundancy] error detection must run alongside a flight-planning application on a multicore processor. Using a hypervisor-based solution rather than implementing both applications concurrently on the same OS sharing the same network stack and kernel, the health-monitor application (shown in Figure 2) can be:

• Mapped to a separate CPU core
• Mapped to a separate Ethernet MAC
• Run according to an independent thread-scheduling algorithm
• Isolated from orthogonal interrupts and blocking semaphores
• Isolated from DMA and OS kernel memory-access errors
• Run on an optimized, minimalistic POSIX-compliant runtime environment

[Figure 2 | Example FACE configuration with independent real-time partition.]

The result is an ideal scenario for a real-time programmer looking to simplify analysis of worst-case execution time (WCET). Yet at the line-replaceable unit (LRU) level, the platform retains the ability to host applications with richer Transport Services Segment (TSS) and Operating System Segment (OSS) capability requirements that are less ­concerned about timing and integrity hazards.

Portability and reuse

Military programs are often stuck with board-support package (BSP) non-recurring engineering (NRE) costs that could be avoided if internal platform software were more portable. Low-level code modules (particularly drivers) are notoriously problematic in providing valued properties of reuse and interoperability.

Standardizing OS internal kernel interfaces is impractical due to their unique design and (in many cases) proprietary nature. However, several classes of device drivers that are naturally independent from core services and require minimal OS feature support (such as the file system) can be isolated by a hypervisor and integrated with applications over standard inter-process communication (IPC) interfaces.

It is demonstrable that devices can be controlled independently from operating systems and integrated with other components without embedding proprietary OS dependencies. Consider an OpenGL UA application that simply needs drivers with access to the GPU device interface. Another example: A self-contained MIL-STD-1553 service with TSS-compatible I/O interfaces made available to PCS [portable component segment] applications (see Figure 3).

[Figure 3 | Example of standalone Units of Conformance (UoCs.]

Instead of relying on OS implementations of resource mapping and IPC transports, the TSS layer and local application runtime software can have sufficient capabilities to locate dependent modules and integrate with the use of standard hypervisor-provided interfaces and services. Such an approach can even follow the FACE Unit of Conformance (UoC) packaging requirements. This vision is not farfetched, given virtualization standards such as OASIS “VIRTIO” already exist and is well-established. Just as FACE relies on POSIX to uphold standard specifications for the OSS, VIRTIO can similarly support the proposed Hardware Partitioning Segment.

Virtualization works for FACE

FACE is a resounding success. But to date, the portability and interoperability benefits of FACE have been generally limited to the mission-system software hosted by operating systems above the TSS layer.

Exacerbating that situation, the targeting of military avionics towards the development of unmanned systems is likely to see the underlying boundaries of mission system versus vehicle-control computing domains diminish, with the limitations of FACE becoming more of an irritation.

To fulfill its charter, FACE must accommodate the needs of vehicle-control software. Recent experience on vehicle-control subsystems has proven virtualization as a means to reduce platform software complexity carving out low-level hardware-control access while providing the well-appreciated architectural benefits of partitioning and interoperability interfaces. Pressing into the standardization of these low-level capabilities can bridge the gap of FACE-compliance feasibility for vehicle-control development without tarnishing the undoubted benefits of existing FACE provisions for mission-system development.

In his role as chief technical officer for Lynx Software Technologies, Will Keegan leads the technology direction across all the Lynx product lines. He has been instrumental in the development of key security technologies within Lynx to broaden the reach of the existing products, with a focus on cybersecurity, cryptography, and virtualization. Keegan holds a Bachelor of Science degree in computer science from University of Texas.

Lynx Software Technologies • https://www.lynx.com/