How the Operating System Segment fits into the FACE architecture

Overview

The Future Airborne Capability Environment (FACE™) consortium will host their annual Technical Interchange Meeting and Exhibition in September 2020. Leading up to this event, Wind River and Rapita Systems are providing some background on the FACE architecture with a focus on our “one stop shopping” ecosystem for Units of Portability (UoP) and the tools to test, integrate, and certify systems based on the FACE Technical Standard.

The US Department of Defense continues to push for the use of open architecture solutions as a means to get better avionics hardware into the field more quickly and at lower cost. One source of such solutions is the Future Airborne Capability Environment (FACE™) consortium, founded in 2010 to develop an open architecture technical standard as well as business models for implementing FACE standards in systems. The consortium is managed by the Open Group, and has members from government, education, and industry sectors.  Member organizations must be incorporated in the US and individual members must be US citizens, though the annual FACE Technical Interchange Meeting typically includes an exhibition that is open to all.  The publications released by the FACE Consortium are also publicly available and free to download.  There are currently 91 organizations and over 1,000 individuals with membership. The consortium sponsors four general working sessions a year, called the FACE F2F.  Volunteer members do the detailed work of the consortium through technical and business working groups overseen by a steering committee and advisory board.

One of the most significant products of the FACE consortium has been the development of a technical standard, which is currently at revision 3.0  According to the FACE website, “The FACE Technical Standard is the open avionics standard for making military computing operations more robust, interoperable, portable and secure. The standard enables developers to create and deploy a wide catalog of applications for use across the entire spectrum of military aviation systems through a common operating environment.”

In this first entry of our 4-part blog series, we will summarize the FACE architecture to illustrate how the Operating System Segment (OSS) provides a foundation to the other segments. Later blogs will explore the Wind River OSS in more detail as well as the Rapita Systems tools that support validation and verification.

FACE Architectural Segments

The concept of the FACE standard is to provide a reference architecture based on segments, which can be composed to meet the final system requirements. Variations in the content of the segments, including application code, allows the system architect flexibility in designing and building the end system. FACE provides the logical interfaces between these segments to allow for portability and re-use. FACE Technical Standard (TS) V3 shows in Figure 1 how the segments are related:

 

The five segments are:

1. Operating System Segment (OSS) – foundational services provided by an Operating System; we will cover this in more detail below.  The remaining four segments depend on the OSS and thus it is shown beneath the others in the diagram.
2. I/O Services Segment (IOSS) – normalizes the interface to I/O devices
3. Platform-Specific Services Segment (PSSS) – provides platform services, such as data services, logging, health management and graphics (interface to GPU)
4. Transport Services Segment (TSS) – provides communication services
5. Portable Components Segment (PCS) – offers capability or business logic

Key to constructing the system are the interfaces between these segments defined by the FACE TS. For the OSS we are interested in the supported APIs, and these fit into different profiles. These are Security, Safety, and General Purpose.

• Security is most restricted and has a minimal set of Application Programming Interfaces (APIs) for high assurance applications.
• Safety profile is a superset of the security profile, with more APIs, and is intended for applications that require safety certification, this also has 2 further profiles, Base and Extended.
• General Purpose profile has most APIs and supports applications that do not necessarily need RT or deterministic response.

To maintain commonality across different FACE component suppliers, solutions are tested against these API sets and given a certificate of conformance. For example, Wind River has FACE 2.1 conformance for VxWorks 653 Safety Base Profile, FACE 3.0 conformance for Helix Virtualization Platform (Security & Safety Base Profile) and FACE 3.0 for Wind River Linux (General Purpose Profile).
In fact, Wind River VxWorks 653 was the first product to go through FACE certification, and Wind River Linux is the only Linux to achieve FACE Conformance.

The FACE standard builds on existing standards rather than creating new ones, so for the OSS it builds on the POSIX and ARINC 653 standards.

Partitioning

The FACE standard also calls for support for Partitioning, depending on the profile. This techniques is used in many types of computing systems, a good white paper on this is “Enabling the migration to Future Aerospace & Defense Systems” Partitioning supports modularity, including support for the concept of Integrated Modular Avionics (IMA).  The isolation properties provided by the partitioning of distinct applications are essential to achieve the promise of the FACE standard.  Why is this? First, interoperability and smooth integration require isolation so that there are no surprises (due to unanticipated interactions) when we add new independent functions in the system. Second, certification of mixed-criticality systems is founded on the isolation of partitions.

The General Purpose profile uses space partitioning, while the safety and security profiles require both time and space partitioning. These requirements stem from the ARINC 653 standard for the safety profiles, from the standard “Time partitioning must be used when running Safety Profile-based software components that are dependent upon an ARINC 653 operational environment.”

With the advent of powerful multi-core processors, the drive to use partitioning to separate critical application is accelerating. With single core processors, the ability to host applications at different criticalities was achieved using Time & Space Partitioning, in an Integrated Modular Avionics (IMA) architecture developed to overcome issues of Space, Weight, and Power (SWaP) in commercial aircraft. This was needed to meet the increasing requirements for more and more capability within the airframes at the time, such as the Airbus A380 and Boeing 787.

However, what this basically did was “share” the CPU resource across multiple applications, and while this achieved the goals of an IMA Architecture, it also impacted the performance allocated to applications. With the latest multicore applications however, this performance impact can be mitigated by allocation across multiple cores. These systems are breaking ground on safety certification of complex systems

No Performance Requirements

The FACE standard intentionally avoids dictating performance or quality of applications, focusing instead on a standard interface with defined behavior.  This open standards approach has a significant benefit, leveling the playing field. All vendors must meet the same API and must then compete on performance, quality, tools support, depth of airworthiness evidence, etc. For example, multiple vendors might provide a FACE OSS that has been certified conformant to the FACE technical standard, with each providing the same expected API to interface with other elements of the system. However, the timing characteristics – such as response time, partition window jitter, etc. – may vary widely between systems produced by different vendors. Some vendors might provide a package of flight certification artifacts, while others do not, and the strength of the tools ecosystem related to the OSS may vary significantly between vendors.

Wrap up

Wind River and Rapita Systems can help you build your FACE system with our “one stop shopping” ecosystem, starting with the Wind River OSS and including the tools to test/integrate/certify systems based on the FACE Technical Standard, such as the Rapita Systems Verification Suite and MACH¹⁷⁸ solution.  Watch for a few more blogs on this topic leading up to the FACE TIM in September.

About the Authors

Alex Wilson is Director of Aerospace and Defence Market Segment for Wind River, he is responsible for A&D market Segment in EMEA, APAC, and Japan. As part of the Wind River Aerospace & Defence Industry Solutions Team, Alex is responsible for business strategy including product requirements, sales growth strategy and ecosystem development.

Steven H. VanderLeest is a Principal Engineer for Multicore Solutions at Rapita Systems. He has published on topics related to avionics safety and security in the IEEE Digital Avionics Systems Conference as well as SAE Aerotech.  Dr. VanderLeest is also the vice-chair of the FACE EA-25 committee on airworthiness.

Note: The views expressed in this blog are the sole opinion of the authors and do not represent official positions of the FACE consortium.