Introduction to DO-178B PDF Print E-mail

By Eduardo Trejos, Quality Engineer and Jose Lopez, Software Engineer, Avionyx.

Summary

This paper provides a brief introduction to DO-178B. It discusses software airworthiness and how DO-178B was created as a tool to comply with certification requirements, including an overview of the software criticality levels and the number of objectives to be satisfied for each of them. Finally, it provides an overview of the development and integral processes along with their objectives and respective software life-cycle data.

History

Avoiding aircraft accidents and providing air safety has always been a priority in aviation systems development. The rapid increase in the use of software in airborne systems and equipment used on aircraft and engines in the early 1980s resulted in a need for industry accepted guidance for satisfying airworthiness requirements and the creation of DO-178, later followed by DO-178A.

With the evolution of glass cockpits, highly integrated systems that require real-time operating systems and millions of lines of code, DO-178B provides the guidance necessary to assure software runs reliably under all normal and abnormal conditions. 

What are the software guidelines for avionics?

RTCA in cooperation with the European Organisation for Civil Aviation Equipment (EUROCAE) established special committees and working groups to develop and document the software practices that would support the development of software-based airborne systems. These practices were gathered in a document that evolved into DO-178B: Software Considerations in Airborne Systems and Equipment Certification (1992).

The U.S. Department of Transportation’s Federal Aviation Administration (FAA), recognizes DO-178B as a means of evaluating software for the purposes of complying with the regulations in their Advisory Circular AC 20-115B. In Europe, the Joint Aviation Authority (JAA) recognizes ED-12B via Temporary Guidance Leaflet Number 4 (TGL No. 4).

DO-178B‘s software quality assurance guidelines are approved by the FAA and the European Aviation Safety Agency (EASA) and other  aviation authorities worldwide that approve the certification of all commercial aircraft produced.

The Certification Authorities Software Team (CAST) Position Paper CAST-5 (Guidelines for Proposing Alternate Means of Compliance to DO-178B) establishes that if an applicant proposes a non-traditional approach to one or more of the DO-178B objectives, they still must show how that approach meets the “intent” of the DO-178B objectives. Many of the DO-178B objectives relate to completeness and rigor of development and verification processes in specific terms, whereas the generalized process models such as the Software Engineering Institute (SEI) Capability Maturity Model (CMM) and Software Process Improvement Capability Evaluation (SPICE) are focused on business process measurement and improvement. Those models stipulate and assess against many process attributes that are necessary but not sufficient conditions for high product integrity and safety. For example, the SEI CMM has no process activities, capabilities or metrics associated with verification (including review, analysis or test coverage). This is very important in DO-178B guidance because verification is a key factor in system safety.

DO-178B at a glance

The purpose of DO-178B is “to provide guidelines for the production of software for airborne systems and equipment that performs its intended function with a level of confidence in safety that complies with airworthiness requirements.”

Not all avionics systems have the same criticality. Some systems may not require following a very rigorous development process since their malfunction may not affect safety at all. To reflect this, DO-178B defines different failure condition categories. The failure condition category of a system is established by determining the severity of failure conditions on the aircraft and its occupants. The software level is based upon the contribution of software to potential failure conditions as determined by the system safety assessment process. Table 1 shows the software level per failure condition and the amount of DO-178B objectives associated to each. It also shows the number of objectives that have to be satisfied with independence. Independence refers to a separation of responsibilities where the people who verify an objective must not be the developers of the item in question.


SW LevelFailure Condition CategoryFailure Condition DescriptionObjectives With independence
 
ACatastrophicConditions which would prevent continued safe flight and landing.6625
BHazardous/Severe-MajorConditions which would reduce aircraft safety margin/functional capabilities, produce a higher workload to the flight crew or have serious adverse effects on occupants.6514
CMajorConditions which would significantly reduce aircraft safety, crew ability to work under adverse operation, or produce discomfort to occupants.
572
DMinorConditions which would not significantly reduce aircraft safety, slight increase in crew workload, or produce some inconvenience to occupants.
282
ENo EffectConditions which do not affect the aircraft operation or crew workload.
00
Table 1. DO-178B SW levels and characteristics

DO-178B establishes processes that are intended to support the objectives, according to the software level. In general, there’s Integral and Development processes as shown in Figure 1.

DO-178B Software Life Cycle Process

Figure 1. DO-178B Software Life Cycle Process

The processes of a software life cycle may be iterative as represented by the dotted lines in the Software Development Processes in Figure 1.

The objective for each process and its respective Software Life Cycle Data are further explained in Table 2.

Software
Life Cycle
Process
Objective
Software Life Cycle Data
(process outputs)
 
Planning
Produce the software plans and standards that direct the software development processes and the integral processes
PSAC

SDP

SVP

SCMP

SQAP
SRS

SDS

SCS
Plan for SW Aspects of Certification
SW Development Plan
SW Verification Plan
SW Config Management Plan
SW Quality Assurance Plan
SW Requirements Standards
SW Design Standards
SW Code Standards
Requirements
Develop the high-level requirements
SRD
SW Requirements Data
Design
Develop the software architecture and low-level requirements from the high-level requirements
SDD

SECI
SW Design Description
SW Environment Config Index
Coding
Implement the source code from the software architecture and the low-level requirements
SRC
Source Code
Integration
Build the executable object code and load it into the target hardware to detect and report errors/bugs that may have been introduced during the software development processes by creating test cases, test procedures and analyses
EOC

SVCP

SVR

SCA

SCI

SAS
Executable Object Code
SW Verification Cases & Proc.
SW Verification Results
Structural Coverage Analysis
SW Configuration Index
SW Accomplishment Summary
Configuration Management
Provide a defined and controlled configuration of the software throughout the software life cycle and to provide the ability to consistently replicate the Executable Object Code
-
SCM Records
Problem Reports
Verification
Detect and report errors/bugs that may have been introduced during the development processes
-
Review Records
Quality Assurance
Provide confidence that the software life cycle processes produce software that conforms to its requirements by assuring that these processes are performed in compliance with the approved software plans and standards
-
SW Conformity Review
SQA Records
Certification Liaison
Establish communication and understanding between the applicant and the certification authority throughout the software life cycle to assist the certification process
-
PSAC, SAS, SCI
Table 2. SW Life Cycle Processes Objectives and Data


 
AddThis Social Bookmark Button