FACE Components: Interchangeable but not Equal

Introduction

The Future Airborne Capability Environment (FACE™) consortium will host its annual Technical Interchange Meeting and Exhibition in March 2021. 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 first article covered “How the Operating System Segment fits into the FACE architecture.” This is the second blog in the series.

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, which publishes an open architecture technical standard as well as business models for implementing the standard in avionics systems. The publications released by the FACE Consortium are also publicly available and free to download.

In this second blog of the series, we focus on the benefits of modularity in an open architecture and discuss the features that distinguish offerings by different vendors, with a focus on the Operating System Segment (OSS) component of the FACE architecture. In relation to OSS, Wind River provides a competitive advantage while maintaining modularity. Part of that advantage is a rich ecosystem of tools to validate the performance of the system and provide assurance evidence for airworthiness. Since the OSS is foundational to the architecture, it is important that the ecosystem for it is closely aligned with the operating system. For example, flight certification of multicore avionics systems require assurance that multicore interference channels have been mitigated. The Rapita Systems CAST-32A Compliance Package provides that assurance with tools and artifacts that validate and verify the system.

FACE Modularity leads to Interchangeability

The modular concepts of the FACE standard provide a reference architecture based on segments that can be integrated to meet final system requirements. Variations in the content of each segment, including application code, allows the system architect flexibility in designing and building the end system out of compatible modules. The FACE standard defines the logical interfaces between these segments to allow for modularity.  This promotes the re-use of software components and enables common functionality across military systems. By using the defined API standards (as described in our previous blog) this allows components to be easily moved between conformant systems developed by different vendors.

In order to ensure the segments can be used in a modular fashion, it is vital that components are tested against the applicable FACE Standard. Conformance is verified by checking that a component conforms to the FACE Technical standard as a “Unit of Conformance” or “UoC”. (The term “Unit of Portability” is sometimes used instead of “Unit of Conformance” to highlight the portable aspects of these components.) This is done by running a FACE Conformance Test Suite, achieving certification of conformance through reviews by a FACE Verification Authority and a FACE Certification Authority, and registering the result on the FACE Registry with the FACE Library Administrator

Two examples of certificates of conformance for Units of Conformance (UoCs) tested against different FACE Profiles are shown below:

If a system architect starts designing a system and needs to use an OS with a specific profile, then they can look at the FACE Registry and choose one of the UoCs that have been certified against that profile.  There are multiple revisions of the FACE Technical Standard, so a Version Number is also specified for each product in the registry. The certificates shown are for UoCs for the “General Purpose Profile” and “Safety Base Profile”, both against “Technical Standard 3.0”.

A System Architect will typically choose several UoCs that will integrate into the final software system. Of note here is that several UoCs could coexist within the same processor address space, and so integration considerations and coordination of these UoC is vital. This is particularly true of performance and interference challenges at integration time. FACE conformance testing only checks the UoC against an OSS profile and within a single segment, and so will not check all software behavior or performance. It’s also worth noting that if you have several UoCs, then you would need UoC to UoC communications, which requires use of the FACE Transport Services Interface. Inter-UoC communication is illustrated in the figure below from the FACE Technical Standard 3.0.

Benefits of Interchangeability

The FACE approach aligns well with the concept of Open Systems Architectures (OSA). The OSA approach enables several business drivers:

• Better buying power
• More affordability
• Faster time to deploy
• Rapid capability injection
• Software reuse

One interesting aspect of the FACE Consortia was the early decision to develop not only a Technical Standard, but also a Business Standard that provides Guidance in the Value Proposition and Business Case for the FACE Approach. This is currently at Version 2.0 and is available on the FACE Documents Web Site.

Being certified conformant to UoC in the FACE standard provides confidence that system integrators have choices – they can drop a particular UoC from any vendor into their system and it should work “out of the box” with other components  This fulfills several of the business drivers, reuse of components, rapid capability injection, and more affordability as the cost of development of the UoC is spread across several programs. An added benefit is that the system integration cost should also be lower due to the well-defined layers between UoC within the standard.

Competition is generated between vendors to provide their value -add and capability expertise, while still conforming to the FACE standard. This in turn gives government procurement agents better buying power when looking for alternative or complementary solutions.

At the same time, it means that the Government is no longer stuck with one vendor and breaks out of vendor lock-in, choosing the best solution rather than being forced into using the same vendor.

For vendors producing products, this also provides benefits of standardization across projects, reducing development cost risk and schedule slips that could impact multiple programs. The reuse of components means better return on investment, and allows vendors to focus on their core strengths and innovation.

However, having functional components that adhere to the standard does not provide all you need.  Each will have different performance, quality, certification artifacts, and tools. Each will also have different business models and lifecycle support solutions. Theses must be taken into account when making final selections.

Interchangeability is the Minimum

The benefits of interchangeable parts are clear in everyday society.  Metric wrenches all fit a metric socket.  Street legal automobiles all fit on public roads. The benefits of such standardization are clear for wrenches and cars.  The benefits for software are also clear.  However, interchangeable parts set the minimum expectation. All wrenches should fit their sockets and all automobiles should fit the road. All wrenches, however, vary in strength and durability and all cars vary in top speed and fuel efficiency. So too, interchangeability for standardized software is the minimum. An OSS that is certified to be conformant to the FACE Technical standard has merely been shown to “fit the road”. Specifically, the Application Programming Interface (API) specified by the standard confirms that the software components that make up the system will fit together and communicate with each other correctly. This compatibility in itself, however, does not indicate anything about the quality of the component, such as its speed or efficiency.

Thus, interchangeability through conformance to standards such as the FACE Technical Standard is the ticket for entry to the FACE market, but this is the minimum. Vendors that meet this starting criterion for a specific FACE UoC compete on a level playing field. For example, customers seeking a FACE OSS will likely make decisions on purchasing based on the following:

• Performance: Components produced by different vendors will vary in the performance metrics, such as end-to-end latency, response time, determinism, reliability, etc.
• Certification: Conformance to the FACE technical standard may provide some testing and artifacts that may be useful for demonstrating airworthiness, but this is only a start. The packages offered by vendors in support of flight certification will vary. On this note, the FACE EA-25 subcommittee is currently working on a white paper to provide more detailed advice on which FACE activities and artifacts may contribute to flight certification evidence.
• Ecosystem: The tools associated with each vendor will vary widely. Especially for the OSS, a rich ecosystem of tools is important to the successful development and integration of the system. The standardization provided by the FACE technical standard can sometimes mean that tools work across any vendor offering, but this is not always the case, as tools may need to connect “under the hood” as well.  Example tools include the Integrated Development Environment (IDE), debugging tools, testing tools (including unit, system, requirements-based), structural coverage analysis tools, timing analysis tools, requirements traceability tools, and etc.

Wind River, together with ecosystem partners such as Rapita Systems can help you build a FACE system with the performance and determinism you need, along with the assurance artifacts you need to achieve flight authorization cost-effectively.

Assuring Partitioning

The FACE Standard Requires Partitioning

The FACE standard calls for support for time and space partitioning in its Safety and Security Profiles. Partitioning is an isolation technique used in many types of computing systems.  This technique supports modularity, for example through Integrated Modular Avionics (IMA).  The separation properties provided by the partitioning of distinct applications are essential to achieve the promise of the FACE standard.

With the advent of powerful multi-core processors, the drive to use partitioning to separate critical applications 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 common airframes at the time, such as the Airbus A380 and Boeing 787. However, on a unicore system, the CPU resource was shared (time-sliced) 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, this performance impact can be mitigated by allocation across multiple cores. At the same time, the use of multicore introduces new challenges to assuring airworthiness.

The FACE Standard does not Assure Partitioning

Although the FACE technical standard requires partitioning in several of its defined profiles, the standard only requires an interface to a partitioned operating environment (ARINC 653). It does not require assurance that the environment correctly implements the isolation mechanisms that provide the primary benefit of partitioning. This makes sense as the FACE technical standard is intended to foster interchangeability and modularity. It is not a substitute for flight certification, but only a starting point. The FACE EA-25 Airworthiness subcommittee is currently working on a white paper to “ensure that FACE conformant software, associated artifacts, and the process to produce them … contribute towards evidence of Air Worthiness where possible, explicitly citing common requirements, processing and guidance.”

The system integrator would be wise to consider the significant hurdles to prove airworthiness from the earliest stages of design, especially for features central to the overall architecture, such as partitioning. When implemented correctly, partitioning simplifies integration and certification because each partition can be considered one at a time.  However, this approach requires that the partitioning itself is proven to a very high level of rigor. Rigorous isolation of partitions is not something that can be tacked on at the end: it must be incorporated as a fundamental design feature from the beginning.  Certification of software for Civilian flight in the US and Europe is guided by the RTCA DO-178C/ED-12C standard. The DO-297 and ARINC 653 standards provide guidance on partitioning environments to isolate independent software functions. Military airworthiness authorities use similar approaches to evaluate software.

The challenge to assure the isolation of partitions is even greater for computing platforms that use multicore processors. On a unicore processor, only one partition can run at a time, providing some natural isolation. On a multicore processor, partitions can run simultaneously on different cores, creating multiple channels of potential interference between functions. Multicore interference can degrade the isolation between partitions and thus must be mitigated. This is a relatively new technology.  The US Federal Aviation Administration (FAA) currently provides guidance for assuring multicore systems in a position paper, CAST-32A.  Further guidance is expected from the FAA and the European Union Aviation Safety Agency (EASA) sometime in the next year.

Wrap up

Conformance to the FACE technical standard demonstrates compatibility and interchangeability, forming the basis for a level playing field of competitive products. Smart OSS buyers will require such conformance, but then will carefully evaluate conformant products on characteristics such as performance, robustness of partitioning, and quality of flight certification artifacts.

This may lead us to questions like the following. What are the steps toward assurance of partitioning in a system composed of FACE UoCs?  What are the best practices that can lead to a cost-effective approach that is successfully certified for flight? This is the subject of the next blog in this series. Stay tuned!

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 CAST-32A Compliance Package.  Watch for a few more blogs on this topic leading up to the next FACE TIM.

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.