Your browser does not support JavaScript! Skip to main content
Free 30-day trial DO-178C Handbook RapiCoupling Preview DO-178C Multicore Training Multicore Resources
Rapita Systems
 

Industry leading verification tools & services

Rapita Verification Suite (RVS)

  RapiTest - Unit/system testing  RapiCover - Structural coverage analysis  RapiTime - Timing analysis (inc. WCET)  RapiTask - Scheduling visualization  RapiCoverZero - Zero footprint coverage analysis  RapiTimeZero - Zero footprint timing analysis  RapiTaskZero - Zero footprint scheduling analysis  RapiCouplingPreview - DCCC analysis

Multicore Verification

  MACH178  MACH178 Foundations  Multicore Timing Solution  RapiDaemons

Engineering Services

  V&V Services  Data Coupling & Control Coupling  Object code verification  Qualification  Training  Consultancy  Tool Integration  Support

Industries

  Civil Aviation (DO-178C)   Automotive (ISO 26262)   Military & Defense   Space

Other

RTBx Mx-Suite Software licensing Product life cycle policy RVS Assurance issue policy RVS development roadmap

Latest from Rapita HQ

Latest news

SAIF Autonomy to use RVS to verify their groundbreaking AI platform
RVS 3.22 Launched
Hybrid electric pioneers, Ascendance, join Rapita Systems Trailblazer Partnership Program
Magline joins Rapita Trailblazer Partnership Program to support DO-178 Certification
View News

Latest from the Rapita blog

How to certify multicore processors - what is everyone asking?
Data Coupling Basics in DO-178C
Control Coupling Basics in DO-178C
Components in Data Coupling and Control Coupling
View Blog

Latest discovery pages

control_tower DO-278A Guidance: Introduction to RTCA DO-278 approval
Picture of a car ISO 26262
DCCC Image Data Coupling & Control Coupling
Additional Coe verification thumb Verifying additional code for DO-178C
View Discovery pages

Upcoming events

Avionics and Testing Innovations 2025
2025-05-20
DASC 2025
2025-09-14
DO-178C Multicore In-person Training (Fort Worth, TX)
2025-10-01
DO-178C Multicore In-person Training (Toulouse)
2025-11-04
View Events

Technical resources for industry professionals

Latest White papers

Mitigation of interference in multicore processors for A(M)C 20-193
Sysgo WP
Developing DO-178C and ED-12C-certifiable multicore software
DO178C Handbook
Efficient Verification Through the DO-178C Life Cycle
View White papers

Latest Videos

Rapita Systems - Safety Through Quality
Simulation for the Motorola 68020 microprocessor with Sim68020
AI-driven Requirements Traceability for Faster Testing and Certification
Multicore software verification with RVS 3.22
View Videos

Latest Case studies

GMV case study front cover
GMV verify ISO26262 automotive software with RVS
Kappa: Verifying Airborne Video Systems for Air-to-Air Refueling using RVS
Supporting DanLaw with unit testing and code coverage analysis for automotive software
View Case studies

Other Resources

 Webinars

 Brochures

 Product briefs

 Technical notes

 Research projects

 Multicore resources

Discover Rapita

Who we are

The company menu

  • About us
  • Customers
  • Distributors
  • Locations
  • Partners
  • Research projects
  • Contact us

US office

+1 248-957-9801
info@rapitasystems.com
Rapita Systems, Inc.
41131 Vincenti Ct.
Novi
MI 48375
USA

UK office

+44 (0)1904 413945
info@rapitasystems.com
Rapita Systems Ltd.
Atlas House
Osbaldwick Link Road
York, YO10 3JB
UK

Spain office

+34 93 351 02 05
info@rapitasystems.com
Rapita Systems S.L.
Parc UPC, Edificio K2M
c/ Jordi Girona, 1-3
Barcelona 08034
Spain

Working at Rapita

Careers

Careers menu

  • Current opportunities & application process
  • Working at Rapita
Back to Top Contact Us

Leveraging FACE Conformance Artifacts to Support Airworthiness

Breadcrumb

  1. Home
Alex Wilson (Wind River) and Steven H. VanderLeest (Rapita)
2021-01-14

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 MACH178 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)

DO-178C webinars

DO178C webinars

White papers

Mitigation of interference in multicore processors for A(M)C 20-193
Sysgo WP Developing DO-178C and ED-12C-certifiable multicore software
DO178C Handbook Efficient Verification Through the DO-178C Life Cycle
A Commercial Solution for Safety-Critical Multicore Timing Analysis

Related blog posts

Assured Multicore Partitioning for FACE Systems

.
2020-11-10

Assured Partitioning for FACE Systems

.
2020-10-12

FACE Components: Interchangeable but not Equal

.
2020-08-03

How the Operating System Segment fits into the FACE architecture

.
2020-07-17
  • Solutions
    • Rapita Verification Suite
    • RapiTest
    • RapiCover
    • RapiTime
    • RapiTask
    • MACH178

    • Verification and Validation Services
    • Qualification
    • Training
    • Integration
  • Latest
  • Latest menu

    • News
    • Blog
    • Events
    • Videos
  • Downloads
  • Downloads menu

    • Brochures
    • Webinars
    • White Papers
    • Case Studies
    • Product briefs
    • Technical notes
    • Software licensing
  • Company
  • Company menu

    • About Rapita
    • Careers
    • Customers
    • Distributors
    • Industries
    • Locations
    • Partners
    • Research projects
    • Contact
  • Discover
    • Multicore Timing Analysis
    • Embedded Software Testing Tools
    • Worst Case Execution Time
    • WCET Tools
    • Code coverage for Ada, C & C++
    • MC/DC Coverage
    • Verifying additional code for DO-178C
    • Timing analysis (WCET) & Code coverage for MATLAB® Simulink®
    • Data Coupling & Control Coupling
    • Aerospace Software Testing
    • Automotive Software Testing
    • Certifying eVTOL
    • DO-178C
    • AC 20-193 and AMC 20-193
    • ISO 26262
    • What is CAST-32A?

All materials © Rapita Systems Ltd. 2025 - All rights reserved | Privacy information | Trademark notice Subscribe to our newsletter