DO-178B is a standard for developing embedded software for aircraft. It outlines 5 assurance levels based on the effect of failure and processes for planning, development, verification, configuration management, and quality assurance. The processes require documentation like requirements, design documents, test plans, results, and configuration management records. Following DO-178B helps ensure safe, requirements-based software for avionics.

1. Overview of DO-178B
Swamy S M
Engineer – Test & Quality
Captronic Systems

2. Contents
• Introduction
• History of DO-178B
• Evolution of DO-178B
• DO-178B Assurance Levels
• DO-178B Process Overview

3. Introduction
• Titled “Software Considerations in Airborne Systems and Equipment Certification”.
• It’s European equivalent is ED-12B.
• A document that addresses the life process of developing embedded software in
aircraft systems.
• It is a commonly accepted standard worldwide for regulating safety in the integration
of software in aircraft systems.

4. History of DO-178B
• Software in avionics has been around since the 1970’s
• The RTCA creates DO-178 in 1980, while EUROCEA works on ED-35.
• The merged result is DO-178 / ED-12: the first common certification criteria for
production of avionics software.

5. Evolution of DO-178B
• In 1985, revisions and updates were made to produce DO-178A / ED-12A.
• The documents became a worldwide basis for software certification in the aviation industry.
• DO-178B / ED-12B started in 1989 and finalized in 1992.

6. DO178B Assurance Levels
• DO-178B requires that all system requirements be mapped to one of
the five software levels.
Software Level Objectives Failure Level
Level A 66 Catastrophic
Level B 65 Hazardous
Level C 57 Major
Level D 28 Minor
Level E 0 No Effect

7. DO178B process overview
• DO-178B is divided into different processes
• Planning process
• Development process
• Integral process
– Verification process
– Configuration management
– Quality assurance process
– Certification liaison process

8. DO178B process overview

9. Software Planning Process
• Purpose is to determine what will be done to produce safe, requirements-based
software
• Activities addressing system requirements and certification levels
• Inter-relationships between processes, sequencing, feedback, and transition criteria
• Lifecycle environment, including methods and tools

10. Output Documents
• Plan for Software Aspects of Certification (PSAC)
• Software Development Plan (SDP)
• Software Verification Plan (SVP)
• Software Configuration Management Plan (SCMP)
• Software Quality Assurance Plan(SQAP)
• Software Requirements, Design & Coding Standards (SRDCS)

11. Development Process
• The software development process is broken into four sub-processes:
• Software Requirements Process
– High-level requirements in relation to function, performance, interface and safety.
• Software Design Process
– Low-level requirements used to implement the source code.
• Software Coding Process
– Production of source-code from the design process.
– Integration of code into a real-time environment.

12. 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

13. Verification process
• The purpose is to identify and report any errors resulting from the development
process.
• The verification process objectives can be met with reviews, walkthroughs, unit
testing, integration testing, and more.
• 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).

14. Output Documents
• 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

15. Configuration Management
Process
• The purpose is to establish secure and effective configuration control for all artifacts.
• 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

16. Output Documents
• The following activities are done within the process:
– Configuration Identification
– Change Control
– Baseline establishment
– Archiving of the software
• Outputs
– Software configuration index (SCI)
– Software life cycle environment configuration index (SECI)

17. Quality Assurance Process
• The purpose is to provide assurance that the software life cycle process is going to
yield quality software.
• This process performs reviews and audits to show compliance with DO-178B
• Each process is analyzed to show that each process is producing the expected
outputs.
• Any changes from originally proposed plans are reported, evaluated, and resolved to
ensure process integrity.

18. Output Documents
• Outputs
– Software quality assurance records (SQAR)
– Software conformity review (SCR)
– Software accomplishment summary (SAS)

19. Certificate Liaison
• Communication and understanding between the applicant and the certification
authority is established
• The means of compliance is proposed, and agreement with the plan for software
aspects of certification is obtained
• Compliance substantiation is provided
• Typically a Designated Engineering Representative (DER) reviews technical data as
part of the submission to the FAA for approval.

20. Summary
• History of DO-178B
• Evolution of DO-178B
• DO-178B Assurance Levels
• DO-178B Process Overview