Leveraging FACE Conformance Artifacts to Support Airworthiness

Airworthiness Standards

The previous article in this series focused on partitioning in multicore processors. It also looked at guidance for safety certification of Avionics Systems based on multicore processors, including multicore aspects of partitioning, particularly from the FAA CAST-32A position paper. There are several other standards that one may also want to consider, including:

• RTCA DO-178C “Software Considerations in Airborne Systems and Equipment Certification” – describes the process of developing software that will be flight certified
• RTCA DO-254 “Design Assurance Guidance for Airborne Electronic Hardware” – describes the process of developing complex electronic hardware that will be flight certified. Referenced by AC 20-152.
• RTCA DO-248C “Supporting Information for DO-178C and DO-278A” – provides additional details on concepts in DO-178C, including using previously developed software, MC/DC coverage, independence, and partitioning
• RTCA DO-297 “Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations” – describes roles and processes for developing IMA systems, and the importance of partitioning
• ARINC 653 Part 1, Supplement 5 – adds support for multicore, but in terms of partitioning and assurance it is clear that “It must not be construed that compliance to ARINC 653 assures robust partitioning”
• FAA AC 20-193 “Use of Multi-Core Processors“ – formalizes the objectives from CAST-32A related to certifying avionics systems based on multicore processors. A draft of this Advisory Circular was released in October 2020. After a comment period, the final version is expected to be published in 2021.
• US DoD MIL-HDBK-516C “Airworthiness Certification Criteria” – provides guidance for certification of avionics systems (including hardware and software). An update is in progress to address multicore considerations, but this has not yet been published.
• US Army “Multi-Core Processor (MCP) Airworthiness Requirements” – this guidance is in draft form and has not yet been formally released.

FACE Conformance is not Airworthiness

As explained in previous articles in this series, certification of FACE conformance only guarantees that a Unit of Conformance (UoC) honors the FACE standard. It is not intended as a solution for meeting airworthiness requirements. Indeed, the FACE standard recognizes that some systems do not require safety certification, such as systems built on the FACE General Purpose profile using Linux as the operating system. The Safety- and Safety-Extended profiles intentionally limit the breadth of functionality included in a FACE UoC, which can help limit the scope of effort needed to generate certification evidence, but using this profile is simply a starting point.

This brings us to some important conceptual difference when comparing FACE conformance to flight certification (approval of airworthiness). Conformance to the FACE standard is granted to a component, not to an entire system. The FACE Verification Authority (VA) verifies conformance for a UoC, which may be a FACE architectural segment, or part of a segment. A UoC cannot span more than one architectural segment, though a “UoC Package” can be comprised of UoCs that span certain FACE segments to form a single logical entity. Thus, FACE conformance is not granted to the entire system, even if it is made up partially or entirely of FACE conformant UoCs. Only the individual UoCs can be claimed to be conformant.

On the other hand, airworthiness is granted to an entire system, not to components. Certification artifacts may be associated with one component, such as the OS, and these artifacts may be accumulated into the overall certification package for the aircraft. An individual component can be described as certifiable, or perhaps as certified within a named system, but the stand-alone component cannot be labeled as “certified”.

For example, certification artifacts for Wind River VxWorks 653 v2.5 on PowerPC (which is FACE conformant to the Safety Base Profile against Technical Standard v2.0) include all documentation required to satisfy the requirements of RTCA DO-178C, consisting of over 65,000 hyperlinked files. This includes items such as the Plan for Software Aspects of Certification (PSAC) and Software Accomplishment Summary (SAS) along with all design reviews, code review, test reviews, functional tests and coverage results. In addition to supporting evidence for the OS, there is also evidence for qualified development tools, and for newer releases, evidence supporting CAST-32A for Multicore.

FACE Conformance Supports Airworthiness

The job of the FACE UoC supplier is to provide the software as well as associated certification artifacts. The job of the system integrator includes pulling together FACE UoCs to form the overall avionics system design. If acting as the certification applicant, they must also collate the certification artifacts for each UoC into the overall certification package for the system.

The FACE Consortium has two committees whose work helps smooth this process. First, the Technical Working Group (TWG) on Software Safety has been active since nearly the beginning of the consortium. Currently led by Glenn Carter and Joe Wlad, this committee has a mandate to ensure that each edition of the FACE Technical Standard does not interfere with subsequent efforts to obtain flight certification. That is, this group uses a “do no harm” approach, employing preventative measures and eliminating potential airworthiness issues from the technical standard. Second, the EA-25 Airworthiness committee was formed about a year ago, with a mandate to augment the preventative maintenance of the TWG Safety group, by further identifying how the effort toward FACE Conformance could be leveraged to aid in demonstrating airworthiness. The deliverable for this team is a white paper identifying activities and associated design artifacts generated while pursuing FACE conformance that map to evidence appropriate to support flight certification. Thus “do no harm” is expanded to “do some good”. The white paper from this committee is expected sometime in 2021.

One high-level example of FACE conformance supporting airworthiness can be found in the FACE reference architecture, which is illustrated below. Both civilian and military airworthiness guidance typically require a software architecture to be defined. A system designed using FACE UoCs inherently builds on a reference architecture that has been publicly reviewed and standardized. The documentation of the architecture, its interfaces, and specification are all artifacts that can contribute to meeting the architecture definition expectations for airworthiness. The system integrator still has some work to do to demonstrate that the architecture is implemented correctly and to ensure architecture-related requirements are reviewed and pass normal verification and validation.

A more specific example of FACE conformance supporting airworthiness can be found in the FACE technical standard requirements for time partitioning and space partitioning under the safety and security profiles. The isolation provided by partitioning not only contributes to portability and reusability but also eases certification for Integrated Modular Avionics (IMA) systems. A number of airworthiness standards expect partitioning as a means of breaking down a complex system into separate logical components that can be independently and incrementally assured. Partitioning cannot be an afterthought. It is a fundamental mechanism of the computing hardware and RTOS and thus must be part of the design philosophy from the beginning. Because the FACE technical standard requires it, this helps ensure that a development program starts out on the right track. The OSS supplier provides much of the evidence to verify and validate the partitioning environment. The system integrator then must demonstrate that the partitioning environment is implemented and configured appropriately so that the supplier evidence can be accepted. In addition, the system integrator must allocate system resources to partitions and demonstrate that the total resource usage is within the system capacity. Resource allocations include a portion of time on one or more processor cores, a portion of main memory, etc.

Tools

Flight certifying a system comprised of FACE conformant elements can be a daunting task. Wind River can support your efforts by supplying the Operating System Segment (OSS) along with certification artifacts (as listed in the FACE library/registry) including DO-178 plans such as the PSAC and Software Development Plan (SDP) as well as verification evidence, such as Software Verification Test Cases and Procedures, and Software Test Results. A qualified development tools suite is also included that allows you to develop, configure, build, debug, test, re-test, and certify each independent application independently, incrementally, and asynchronously.

Rapita Systems can support your certification efforts with its suite of verification tools that automate much of the Verification & Validation (V&V) process, including tools for generating unit and system tests, automating test runs and reporting, analyzing structural and decision coverage, and measuring and reporting timing behavior. For multicore systems, Rapita also provides a MACH¹⁷⁸ solution that addresses airworthiness for avionics systems by verifying that multicore interference channels are properly mitigated.

Learn about the FACE standard and how to comply with it in our blog series:

Part 1: How the Operating System Segment fits into the FACE architecture
Part 2: FACE Components - Interchangeable but not Equal
Part 3: Assured Partitioning for FACE Systems
Part 4: Assured Multicore Partitioning for FACE Systems
Part 5: Leveraging FACE Conformance Artifacts to Support Airworthiness (this post)