DO-178C meets the FACE Technical Standard: High assurance and reusability for airborne software

Story

March 16, 2020

Benjamin Brosgol

AdaCore

The DO-178C and FACE [Future Airborne Capability Environment] approaches form a natural union, enabling developers to combine best practices for airborne software production from both the military and commercial arenas. By developing and verifying software components based on the guidance offered in DO-178C and its supplements, FACE component providers can meet their FACE portability goals while achieving high-DAL [Design Assurance Level] reliability and safety.

The FACE [Future Airborne Capability Environment] approach is a government-industry software standard and business strategy for acquiring affordable software systems, designed to promote innovation and rapid integration of portable capabilities across global defense programs and to thereby reduce system life cycle costs. However, the FACE Technical Standard does not directly address issues of quality or fitness for purpose. In particular, although the FACE Technical Standard defines assurance-related language subsets (“safety capability sets”), a software component’s adherence to one of these sets does not necessarily imply that the relevant level of assurance is achieved. Demonstrating such assurance in a military context involves following the guidance of standards such as MIL-HDBK-516C (airworthiness certification criteria) or MIL-STD-882E (safety practice).

These standards, for their part, are not focused completely on software issues and they do not address the challenges (or opportunities) offered by modern technologies such as model-based engineering, object-oriented programming, and formal methods. An approach that can be leveraged by FACE component developers to help achieve the relevant level of assurance is to follow the principles embodied in the RTCA DO-178C standard (and its supplements) for commercial airborne systems. These standards are software-focused and cover modern technologies, identifying potential issues and their resolution. Even if formal certification under DO-178C is not undertaken, the standards can help developers meet the most demanding assurance requirements for reliability and safety while realizing the cost savings that come from the reuse of FACE application components. These benefits are amplified when using programming language technologies, such as Ada and SPARK, that best support the development and verification of high-assurance systems.

The FACE Technical Standard

The FACE Technical Standard, an open standard produced under the auspices of The Open Group FACE Consortium, is available from https://publications.opengroup.org/. The current version is Edition 3.0; several earlier editions (2.0, 2.1, 2.1.1) are also in use and supported. The FACE Technical Standard defines a reference architecture comprising five segments (Figure 1) and a data architecture:

The Operating System Segment (OSS) provides the software foundation for the other segments, with services such as partitioning, process/thread management, and memory management.
The Input/Output Services Segment (IOSS) defines interfaces to the platform’s IO devices from the PSSS.
The Platform-Specific Services Segment (PSSS) defines the interfaces to the IOSS from the PCS, for example for graphics support.
The Transport Services Segment (TSS) defines communications interfaces between FACE components.
The Portable Components Segment (PCS) supplies application functionality and achieves portability by using only the interfaces defined in the other segments.

Figure 1 | The FACE Technical Standard defines a reference architecture comprising five segments and a data architecture.

The foundation of the FACE Reference Architecture is the OSS, which exposes a standard interface through ARINC 653 and POSIX APIs [application programming
interfaces]. A programming language’s run-time libraries are also typically part of the OSS, although they are invoked not through API calls (which might not be portable across different compiler implementations) but rather through source language syntax.

Since FACE-conformant components can be deployed in contexts with varying requirements for safety and/or security, the FACE Technical Standard defines several profiles for the OSS interface:

General-purpose – for components not requiring high levels of assurance: real-time determinism not guaranteed, time partitioning optional, space partitioning required.
Safety – for components that need safety assurance: real-time determinism, time/space partitioning required. Sub-profiles safety-base and safety-extended reflect which APIs are permitted.
Security – for components that need safety and security assurance: real-time determinism, time/space partitioning required.

FACE components can realize run-time functionality through language syntax rather than explicit calls on ARINC 653 or POSIX APIs, and the FACE Technical Standard therefore defines language restrictions (“capability sets”) analogous to the OSS profiles. General-Purpose, Safety-Extended, Safety-Base, and Security capability sets are defined for C, C++, Ada, and Java. (The FACE Technical Standard Edition 3.0 defines Safety and Security capability sets for Ada 95; Edition 3.1 is adding these sets for Ada 2012.)

Applying DO-178C principles

Although DO-178C and its supplements were developed for application to commercial airborne systems, these standards are not necessarily specific to military or commercial aviation, and can be used in other safety-critical domains. The guidance basically relates to three main goals:

Reliability – the system does what it is supposed to do (no failures)
Safety – the system does not do what it is not supposed to do (no hazards)
Good software engineering practice – configuration management, quality assurance, etc.

The standard does not dictate specific development processes, approaches to hazard assessment, or programming languages/tools, but rather defines objectives that – when satisfied – offer confidence that the software meets these goals. Indeed, most of the objectives relate to the verification process: manual reviews, automated analysis, and requirements-based testing to show with appropriate confidence that the output of each life cycle process is correct with respect to its input. The degree of confidence (and the effort required to achieve it) depend on the software’s design assurance level (DAL).

Formal DO-178C certification of a software component can be expensive, especially at the higher DALs. However, outside the domain of commercial aviation where such certification is required, DO-178C can be regarded more generally as a specification of “best practices” for producing safety-critical systems. Seen in this light, the guidance is orthogonal to and consistent with the FACE Technical Standard’s requirements. By adopting and/or adapting the DO-178C guidance based on the software’s DAL, FACE application developers – more specifically, developers of software for the Portable Components Segment – can gain much of the benefit that DO-178C offers without undertaking a formal certification. (Figure 2.)

Figure 2 | DO-178C and its supplements were developed for use in airborne systems and other safety-critical domains.

Programming-language technology

The “Software Life Cycle Environment Planning” section of DO-178C captures the essence of error prevention:

… choose requirements development and design methods, tools, and programming languages that limit the opportunity for introducing errors, and verification methods that ensure that errors introduced are detected.

Since early error detection is key to reducing development and verification costs, FACE application developers need to carefully consider which language(s) and tools to employ. Of the languages with capability sets defined in the FACE Technical Standard, Ada enforces the most extensive checking, both at compile time and run time. The formally analyzable SPARK subset of Ada goes even further, statically detecting large classes of errors (including incorrect information flows and buffer overruns) without a flood of “false alarms.”

Language and API restrictions

The applicability of DO-178C guidance to FACE component development is evidenced in the FACE capability sets. Although the General-Purpose set may be appropriate for software at a low DAL, components at DALs C through A will likely need to be constrained to a simple language subset (Safety-Extended, Safety-Base, or Security) in order to ensure deterministic execution and simple run-time support. The requirements for determinism and simplicity apply both to the application code itself, and to any run-time libraries (supplied by the RTOS or compiler vendor) that are implicitly linked with the application.

As an example, the Safety-Extended capability set for Ada 95 in FACE Technical Standard Edition 3.0 prohibits asynchronous transfer of control, dynamic storage deallocation, and much of the predefined standard libraries; it also restricts concurrency (tasking) support to the constructs defined in the Ravenscar profile. The Safety-Base and Security capability set further constrains run-time functionality, limiting exception support to a “last-chance” handler and prohibiting dynamic allocation. Adhering to the capability set restrictions (or to the POSIX and ARINC 653 APIs defined for the Operating System Segment profiles) helps simplify verification of safety-critical software while also meeting the FACE requirements.

Qualified, trusted tools

Using a software tool to automate, reduce or eliminate an activity can lower costs and prevent errors, but only if the tool can be trusted. In DO-178C parlance, the tool must be qualified at an appropriate level. DO-178C defines five Tool Qualification Levels, TQL-5 (lowest) through TQL-1 (highest), based on the impact of a tool anomaly and the DAL of the software component. A tool whose impact is limited to failing to detect an error needs to be qualified against the requirements for TQL-5, regardless of the DAL. At the other extreme, a tool whose output is part of DAL A airborne software must be qualified at TQL-1. (Since an anomaly in the tool can result in erroneous code in the executable, high confidence in the absence of such anomalies is required.) The specific requirements for the various TQLs are defined in the DO-330 Tool Qualification Considerations standard that complements DO-178C.

A tool that meets the relevant TQL can be trusted for use in FACE component development or verification; the qualification evidence can justify relying on the tool without needing to manually verify the tool’s output. For example, one of the DO-178C objectives is “Source Code conforms to standards,” and for a safety-critical FACE component the relevant standard would be the associated Capability Set definition (Safety-Extended, Safety-Base, Security), possibly augmented with project-specific restrictions. A qualified static-analysis tool that checks that the source code stays within the resulting subset can reduce verification effort.

Source code accuracy and consistency

One of the critical verification objectives in DO-178C concerns the reviews and analyses of the source code:

Accuracy and consistency. The objective is to determine the correctness and consistency of the Source Code, including stack usage, memory usage, fixed-point arithmetic overflow and resolution, resource contention and limitations, worst-case execution timing, exception handling, use of uninitialized variables, cache management, unused variables, and data corruption due to task or interrupt conflicts. The compiler (including its options), the linker (including its options), and some hardware features may have an impact on worst-case execution timing and this impact should be assessed.

FACE component developers need to be alert to these issues and recognize the importance of choosing appropriate programming languages and tools. For example, integer and fixed-point overflow are detected at run time in Ada, and using the Ravenscar profile for concurrency (which is permitted in all Ada capability sets and is supported by run-time libraries certifiable at DO-178C DAL A) can help prevent data corruption. The SPARK static-analysis tool can detect uses of uninitialized variables, occurrences of unused variables, the potential for integer and fixed-point overflow, and many other errors.

Use of previously developed software

The FACE approach is based on reuse; where high assurance is required, the issue is how to achieve a sufficient level of confidence when a software component is used in a context different from the one in which it was originally certified.

One question is the determination of a component’s DAL (and thus, for a FACE component, the OSS profile/language capability set to be used) and the consequent life cycle requirements. For maximum reusability, the component should be developed and verified at the highest DAL for which its usage is envisioned.

Another substantive issue is how to gain confidence that a component that has been shown to satisfy the relevant life cycle objectives in one system will satisfy the relevant objectives in a different system. DO-178C offers specific guidance for several scenarios: When the reuse involves software modification, a change of aircraft installation, a change in application or development environment, or an upgrade to a development baseline. The underlying activity for each of these is a thorough impact analysis to identify, across the software life cycle, the effect of the component’s redeployment in the new context (including an analysis of known problems). For example, porting the same source code to a new processor will require reverification of worst-case execution time assumptions, sufficient stack space reservation, and similar properties. Such reverification can be mitigated by the use of qualified tools.

Specialized technologies

Modern software technologies such as model-based engineering, object orientation, and formal methods bring many benefits to developers of airborne software, but they can also cause complications. For example, dynamic binding simplifies some design patterns but also makes it more difficult to demonstrate correct data dependences. DO-178C’s technology supplements address these issues directly and show how to navigate the potential problems.

The FACE approach is focused on software portability of discrete reusable software components, delegating reliability and safety requirements to other standards. DO-178C is focused on software reliability and safety at the system or subsystem level, treating portability (use of previously developed software) not as a requirement but rather as an “additional consideration” with associated issues. These two approaches are complementary and consistent. By developing and verifying software components based on the guidance offered in DO-178C and its supplements, FACE component providers can meet the FACE portability goals while achieving high-DAL reliability and safety.

A key element of the DO-178C guidance is early detection of errors. Software engineering-oriented languages like Ada and SPARK, supported by qualified tools and certifiable run-time libraries such as those provided by AdaCore, can simplify safety certification while enabling FACE component reuse. The DO-178C and FACE approaches form a natural union, allowing developers to combine best practices for airborne software production from both the commercial and military arenas.

Dr. Benjamin Brosgol is a senior member of the technical staff at AdaCore. He has been involved with programming language design and implementation throughout his career, concentrating on languages and technologies for high-assurance systems with a focus on Ada and safety certification (DO-178B/C). Dr. Brosgol is an active member of The Open Group FACE Consortium’s Technical Work Group. Readers may reach him at [email protected].

AdaCore
www.adacore.com