DO-178B

 

Although DO-178B is referred to as a Guidance Document, it is treated as a standard that imposes requirements on the development and verification of airborne avionic systems.  A Federal Aviation Regulation lists DO-178B as a means of compliance that is acceptable to the regulators of software in the avionics community.  (In the US, the regulatory body is the Federal Aviation Authority - FAA).  DO-178B is not the only means of compliance.  However, if a different approach is used, compliance with the objectives of DO-178B must be shown. 

In Europe, similar statutory regulations call out ED-12B, which is published by EUROCAE.  This is the same document as DO-178B, and was produced by an International consensus-based committee representing practitioners as well as regulators. 

The intent of DO-178B is to describe the objectives of software life cycle processes, describe the process activities, and describe the evidence of compliance required at different software levels.  The software levels are chosen by determining the severity of failure conditions that may affect the aircraft and its occupants (AC 25-1309-1A, Advisory Circular, Federal Aviation Administration).  The failure conditions are named, and have corresponding levels that are identified by letters.  For each level, there is a set of process objectives that must be satisfied.  An example of a DO-178B process objective is A-7.3 “Test Coverage of low-level requirements is achieved.”  The number of process objectives by software level is shown in the table below. 

 

Failure Condition	DO-178B Software Level	Process Objectives
Catastrophic	A	66
Hazardous	B	65
Major	C	57
Minor	D	28
No Effect	E	0

 

Since its publication in December 1992, there have been many requests to the certification agencies for clarification of the intent of DO-178B.  A consensus-based committee was formed called SC-190, (and WG-52 in Europe) and tasked to propose clarifying the DO-178B text.  After four years of work by 150 registered members, a document called The Annual Report for Clarification of DO-178B (DO-248B) was published by RTCA, Inc. (DO-248B, Annual Report for Clarification of DO-178B, RTCA, October 12, 2001.)  This document provides corrections (typographical and editorial), answers to Frequently Asked Questions (FAQs), and discussion papers. 

 

Typical FAQs published in DO-248B include (shortened in the interest of brevity):

Q: Is recursion permitted in airborne applications?

A: Yes!  But it must be bounded.

Q: Is source-code to object-code traceability required?

A: Yes!  If applicant is providing coverage analysis at the source code level and the assurance is at level A.  No!  If coverage analysis is provided at the machine code level. 

Q: If some run-time functions are inlined, is coverage still required of the run-time functions?

A: Yes!  Coverage analysis is required of all of the code, which may be reached within the address space. 

Q: Can compiler features be used to simplify coverage analysis at object code?

A: Yes!  For example, short circuit conditions may be used.  However, as the compiler feature is being used as a verification tool, this feature of the compiler must be qualified as a verification tool.  (Qualification is the process of assuring that a tool can be used in place of a verification activity performed manually) 

 

One of the topics resulting in the most discussion is the use of Previously Developed Software (PDS).  Commercial Off The Shelf (COTS) software is considered PDS, as it may be developed independently of any specific airborne application.  Operating systems (OS) may be considered COTS software, and may have been developed using in-house development processes that are not necessarily compliant with the requirements of DO-178B.  This poses a burden on the user of the OS to re-engineer the verification evidence required, unless it is made available by the OS developer.  DO-178B makes provisions for re-engineering requirements, design information, tests, and review of all artifacts in accordance with the objectives of DO-178B.  The processes must be documented in a set of plans, and evidence must be available to show that this was performed in a controlled way.  DO-178B provides an “alternative means” mechanism allowing developers to present evidence that is not typical.  The developer has the burden of proof that the materials presented are acceptable alternatives to a risk adverse audience.