Software Considerations in Airborne 

Systems and Equipment Certification

Latest version December 1, 1992

Organization RTCA SC-167

EUROCAE WG-12

Domain Aviation

Abbreviation DO-178B

ED-12B

DO-178B

From Wikipedia, the free encyclopedia

DO-178B, Software Considerations in Airborne Systems and Equipment 

Certification is a document dealing with the safety of software used in certain 

airborne systems.

The FAA applies DO-178B as the document it uses for guidance to determine if the 

software will perform reliably in an airborne environment,[1] when specified by the 

Technical Standard Order (TSO) for which certification is sought. The introduction of 

TSOs into the airworthiness certification process, and by extension DO-178B, is 

explicitly established in 14 Code of Federal Regulations (CFR) Part 21, Subpart O.

It was published by RTCA, Incorporated, and development was a joint effort with 

EUROCAE who publish the document as ED-12B.

Contents

◾ 1 Software level

◾ 2 Processes and documents 

◾ 2.1 Planning

◾ 2.2 Development

◾ 2.3 Verification

◾ 2.4 Configuration management

◾ 2.5 Quality assurance

◾ 2.6 Certification liaison

◾ 3 Tools

◾ 4 Requirements management

◾ 5 Criticism

◾ 6 Resources

◾ 7 See also

◾ 8 References

◾ 9 External links

Software level

The Software Level, also known as the Design Assurance Level (DAL) or also '"Item Development Assurance Level"' (IDAL)[2]is 

determined from the safety assessment process and hazard analysis by examining the effects of a failure condition in the system. The 

failure conditions are categorized by their effects on the aircraft, crew, and passengers.

◾ Catastrophic – Failure may cause a crash. Error or loss of critical function required to safely fly and land aircraft.

DO-178B - Wikipedia, the free encyclopedia Page 1 of 6

file:///C:/Program%20Files%20(x86)/Documentum/CTS/docbases/ProDocbase/config/temp_sessions/210230761... 3/23/2015
◾ Hazardous – Failure has a large negative impact on safety or performance, or reduces the ability of the crew to operate the 

aircraft due to physical distress or a higher workload, or causes serious or fatal injuries among the passengers. (Safety-significant)

◾ Major – Failure is significant, but has a lesser impact than a Hazardous failure (for example, leads to passenger discomfort rather 

than injuries) or significantly increases crew workload (safety related)

◾ Minor – Failure is noticeable, but has a lesser impact than a Major failure (for example, causing passenger inconvenience or a 

routine flight plan change)

◾ No Effect – Failure has no impact on safety, aircraft operation, or crew workload.

DO-178B alone is not intended to guarantee software safety aspects. Safety attributes in the design and as implemented as functionality 

must receive additional mandatory system safety tasks to drive and show objective evidence of meeting explicit safety requirements. 

Typically IEEE STD-1228-1994 Software Safety Plans are allocated and software safety analyses tasks are accomplished in sequential 

steps (requirements analysis, top level design analysis, detailed design analysis, code level analysis, test analysis and change analysis). 

These software safety tasks and artifacts are integral supporting parts of the process for hazard severity and DAL determination to be 

documented in system safety assessments (SSA). The certification authorities require and DO-178B specifies the correct DAL be 

established using these comprehensive analyses methods to establish the software level A-E. Any software that commands, controls, and 

monitors safety-critical functions should receive the highest DAL - Level A. It is the software safety analyses that drive the system 

safety assessments that determine the DAL that drives the appropriate level of rigor in DO-178B. The system safety assessments 

combined with methods such as SAE ARP 4754A determine the after mitigation DAL and may allow reduction of the DO-178B 

software level objectives to be satisfied if redundancy, design safety features and other architectural forms of hazard mitigation are in 

requirements driven by the safety analyses. Therefore, DO-178B central theme is design assurance and verification after the prerequisite 

safety requirements have been established.

The number of objectives to be satisfied (eventually with independence) is determined by the software level A-E. The phrase "with 

independence" refers to a separation of responsibilities where the objectivity of the verification and validation processes is ensured by 

virtue of their "independence" from the software development team. For objectives that must be satisfied with independence, the person 

verifying the item (such as a requirement or source code) may not be the person who authored the item and this separation must be 

clearly documented.[3] In some cases, an automated tool may be equivalent to independence.[4] However, the tool itself must then be 

qualified if it substitutes for human review.

Level Failure condition Objectives[5] With independence

A Catastrophic 66 25

B Hazardous 65 14

C Major 57 2

D Minor 28 2

E No Effect 0 0

Processes and documents

Processes are intended to support the objectives, according to the software level (A through D—Level E was outside the purview of DO178B). Processes are described as abstract areas of work in DO-178B, and it is up to the planners of a real project to define and 

document the specifics of how a process will be carried out. On a real project, the actual activities that will be done in the context of a 

process must be shown to support the objectives. These activities are defined by the project planners as part of the Planning process.

This objective-based nature of DO-178B allows a great deal of flexibility in regard to following different styles of software life cycle. 

Once an activity within a process has been defined, it is generally expected that the project respect that documented activity within its 

process. Furthermore, processes (and their concrete activities) must have well defined entry and exit criteria, according to DO-178B, and 

a project must show that it is respecting those criteria as it performs the activities in the process.

DO-178B - Wikipedia, the free encyclopedia Page 2 of 6

file:///C:/Program%20Files%20(x86)/Documentum/CTS/docbases/ProDocbase/config/temp_sessions/210230761... 3/23/2015
The flexible nature of DO-178B's processes and entry/exit criteria make it difficult to implement the first time, because these aspects are 

abstract and there is no "base set" of activities from which to work. The intention of DO-178B was not to be prescriptive. There are 

many possible and acceptable ways for a real project to define these aspects. This can be difficult the first time a company attempts to 

develop a civil avionics system under this standard, and has created a niche market for DO-178B training and consulting.

For a generic DO-178B based process, a visual summary (http://upload.wikimedia.org/wikipedia/commons/4/4f/DO178B_Process_Visual_Summary_Rev_A.pdf) is provided including the Stages of Involvement (SOIs) defined by FAA on the "Guidance 

and Job Aids for Software and Complex Electronic Hardware".

Planning

System requirements are typically input to the entire project.

The last 3 documents (standards) are not required for software level D.

Development

DO-178B is not intended as a software development standard; it is software assurance using a set of tasks to meet objectives and levels 

of rigor.

The development process output documents:

◾ Software requirements data (SRD)

◾ Software design description (SDD)

◾ Source code

◾ Executable object code

Traceability from system requirements to all source code or executable object code is typically required (depending on software level).

Typically used software development process:

◾ Waterfall model

◾ Spiral model

◾ V model

Verification

Document outputs made by this process:

◾ Software verification cases and procedures (SVCP)

◾ Software verification results (SVR): 

◾ Review of all requirements, design and code

◾ Testing of executable object code

◾ Code coverage analysis

Analysis of all code and traceability from tests and results to all requirements is typically required (depending on software level).

This process typically also involves:

DO-178B - Wikipedia, the free encyclopedia Page 3 of 6

file:///C:/Program%20Files%20(x86)/Documentum/CTS/docbases/ProDocbase/config/temp_sessions/210230761... 3/23/2015
◾ Requirements based test tools

◾ Code coverage analyzer tools

Other names for tests performed in this process can be:

◾ Unit testing

◾ Integration testing

◾ Black-box and acceptance testing

Configuration management

Documents maintained by the configuration management process:

◾ Software configuration index (SCI)

◾ Software life cycle environment configuration index (SECI)

This process handles problem reports, changes and related activities. The configuration management process typically provides archive 

and revision identification of:

◾ Source code development environment

◾ Other development environments (for e.g. test/analysis tools)

◾ Software integration tool

◾ All other documents, software and hardware

Quality assurance

Output documents from the quality assurance process:

◾ Software quality assurance records (SQAR)

◾ Software conformity review (SCR)

◾ Software accomplishment summary (SAS)

This process performs reviews and audits to show compliance with DO-178B. The interface to the certification authority is also handled 

by the quality assurance process.

Certification liaison

Typically a Designated Engineering Representative (DER) reviews technical data as part of the submission to the FAA for approval.

Tools

Software can automate, assist or otherwise handle or help in the DO-178B processes. All tools used for DO-178B development must be 

part of the certification process. Tools generating embedded code are qualified as development tools, with the same constraints as the 

embedded code. Tools used to verify the code (simulators, test execution tool, coverage tools, reporting tools, etc.) must be qualified as 

verification tools, a much lighter process consisting in a comprehensive black box testing of the tool.

DO-178B - Wikipedia, the free encyclopedia Page 4 of 6

file:///C:/Program%20Files%20(x86)/Documentum/CTS/docbases/ProDocbase/config/temp_sessions/210230761... 3/23/2015
A third party tool can be qualified as a verification tool, but development tools must have been developed following the DO-178 

process. Companies providing these kind of tools as COTS are subject to audits from the certification authorities, to which they give 

complete access to source code, specifications and all certification artifacts.

Outside of this scope, output of any used tool must be manually verified by humans.

◾ A problem management tool can provide traceability for changes.

◾ SCI and SECI can be created from logs in a revision control tool.

Requirements management

Requirements traceability is concerned with documenting the life of a requirement. It should be possible to trace back to the origin of 

each requirement and every change made to the requirement should therefore be documented in order to achieve traceability. Even the 

use of the requirement after the implemented features have been deployed and used should be traceable.

Criticism

VDC Research notes that DO-178B has become "somewhat antiquated" in that it is not adapting well to the needs and preferences of 

today's engineers. In the same report, they also note that DO-178C seems well-poised to address this issue.

Resources

◾ FAR Part 23/25 §1301/§1309

◾ FAR Part 27/29

◾ AC 23/25.1309

◾ AC 20-115B

◾ RTCA/DO-178B

◾ FAA Order 8110.49 Software Approval Guidelines

See also

◾ DO-178C

◾ Avionics software

◾ ARP4761 (Safety assessment process)

◾ ARP4754 (System development process)

◾ DO-248B (Final Report for clarification of DO-178B)

◾ DO-254 (similar to DO-178B, but for hardware)

◾ Requirements management (too general to be "directly applied" to DO-178B)

◾ IEC 61508

◾ ISO/IEC 12207 (software life cycle process development standard)

◾ ED-153 (Guidelines for ANS software safety assurance)

◾ Modified_condition/decision_coverage

DO-178B - Wikipedia, the free encyclopedia Page 5 of 6

file:///C:/Program%20Files%20(x86)/Documentum/CTS/docbases/ProDocbase/config/temp_sessions/210230761... 3/23/2015
References

1. FAA Advisory Circular 20-115B 

(http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgAdvisoryCircular.nsf/0/dcdb1d2031b19791862569ae007833e7/$FILE/AC20-

115B.pdf)

2. RTCA/DO-178B "Software Considerations in Airborne Systems and Equipment Certification", p. 7

3. RTCA/DO-178B "Software Considerations in Airborne Systems and Equipment Certification", p. 82

4. RTCA/DO-178B "Software Considerations in Airborne Systems and Equipment Certification", p.82

5. RTCA/DO-178B "Software Considerations in Airborne Systems and Equipment Certification", Annex A

External links

◾ AC 25.1309-1A 

(http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgAdvisoryCircular.nsf/0/50bfe03b65af9ea3862569d100733174/

$FILE/AC25.1309-1A.pdf)

◾ AC 20-115B 

(http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgAdvisoryCircular.nsf/0/dcdb1d2031b19791862569ae007833e7/

$FILE/AC20-115B.pdf)

◾ FAA Order 8110.49 

(http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgOrders.nsf/0/640711b7b75dd3d486256d3c006f034f/

$FILE/Order8110.49.pdf)

<img src="//en.wikipedia.org/wiki/Special:CentralAutoLogin/start?type=1x1" alt="" title="" width="1" height="1" style="border: none; 

position: absolute;" />

Retrieved from "http://en.wikipedia.org/w/index.php?title=DO-178B&oldid=638913299" 

Categories: Avionics Safety Embedded systems Software requirements RTCA standards Computer standards

◾ This page was last modified on 20 December 2014, at 14:52.

◾ Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this site, 

you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a 

non-profit organization.

DO-178B - Wikipedia, the free encyclopedia Page 6 of 6

file:///C:/Program%20Files%20(x86)/Documentum/CTS/docbases/ProDocbase/config/temp_sessions/210230761... 3/23/2015