DO-178 Projects

DO-178 Software Development & Certification

DO-178 Software Considerations in Airborne Systems & Equipment Certification
For nearly a decade, CERTON has provided services and solutions to customers across the Aerospace Industry from
General Aviation to Space Flight focused on certification of Airborne Software compliant with RTCA/DO-178 Software
Considerations in Airborne Systems & Equipment guidelines. CERTON can work closely with you to ensure successful
TSO and/or Type Certification during any phase of the software project lifecycle under DO-178B.
DO-178 Design Assurance Level (DAL)
For systems and equipment using software to fulfill a safety related aircraft function, the FAA Advisory Circular 20-115B
cites RTCA/DO-178 as a means of compliance to the Federal Aviation Regulations (FARs) Part 21, 23, 25, 27, 29 and 33.
The FAA defines RTCA/DO-178B as a means, but not the only means, of compliance to the FARs. It is an extremely rare
exception that an alternative means of compliance is used for software in avionics applications
In order to certify safety-critical airborne software using the RTCA/DO-178 guidelines, the system safety assessment
process will identify the applicable DAL according to the five failure conditions categories necessary for safe operation
identified in the table below.
DAL

Condition

Level A

Catastrophic

Software that would cause or contribute to a failure of the system function resulting in conditions that would prevent
continued safe flight and landing.
Level B

Hazardous/Severe-Major

Software that would cause or contribute to a failure of the system function resulting in reducing the capability of the aircraft
or the ability to the crew to cope with adverse operating conditions so that there would be a large reduction in safety
margins of functional capabilities.
Level C

Major

Software that would cause or contribute to a failure of the system function resulting in reducing the capability of the aircraft
or crew with adverse operating conditions that would create a significant reduction in safety margins or functional
capabilities, a significant increase in crew workload, possibly including injuries.
Level D

Minor

Software that would cause or contribute to a failure of the system function which would involve crew action that are well
within their capabilities that causes slight reductions in safety margins or functional capabilities and slight increase in crew
workload.
Level E

No Effect (DO-178B Objectives Do Not Apply)

Software that would cause or contribute to a failure of the system function which has no affect the operational capability of
the aircraft or increase workload.
CERTON has the expertise to develop and certify airborne software for any DAL using the RTCA/DO-178 guidelines for
compliance and Certification Authority approval.

The CERTON DO-178 Compliant Model

The DO-178 Software Development Lifecycle is made up of six main phases, Project Planning, Validation & Verification,
Requirements, Design & Architecture, Implementation & Integration, and Delivery. Each phase in the software
development lifecycle consist of guidelines and activities to achieve compliance with the certification objectives that need
to be filled in order for phase completion.
In CERTONs model of the DO-178 Software Development Lifecycle, the Validation & Verification Phase encompasses
activities during all of the development phases once the plans have been approved by a Certification Authority (FAA,
EASA, ANAC, Transport Canada, etc.). This is the key to successfully managing the risk on a DO-178 project and the
V&V team members should contribute to the development of these plans that will affect the entire program as it evolves.

Software Development projects that fall victim to schedule and budget overruns can almost always be attributed to not
having a trained and experienced V&V team in place early and actively involved during all phases of the software
lifecycle. DO-178 projects are requirements based, and CERTON has the expertise and experience to contribute valuable
input related to System Requirements, High Level Requirements, and Low Level Requirements Design and Architecture
that will support streamlined implementation and integration, V&V, and Delivery.
Errors in the Requirements, Design and Architecture have to be identified and resolved as they are created by the
Development team early in the project. Otherwise, the inevitable consequence of detection by V&V after implementation
and integration is complete rework from the top all the way down. These avoidable errors become very costly to a
program with milestone deadlines, such as First Flight (SOF), Type Inspection Authorization (TIA), and Certification.
Project Planning Phase
At the start of the DO-178 Software Development Lifecycle, the objective of the DO-178 Planning Phase must be
addressed for compliance. [DO-178B Table A-1] This Software Planning Process involves creating plans and standards to
govern the development, verification, configuration management, quality assurance, and delivery of software in
compliance with DO-178 guidelines. In this phase, the Software Development Plan (SDP), Plan for Software Aspects of
Certification (PSAC), Software Quality Assurance Plan (SQAP), Software Configuration Management Plan (SCMP),

Software Verification Plan (SVP), and Software Requirements, Design & Coding Standards (SRDCS) documents are
written and reviewed in preparation for the first Stage of Involvement (SOI) Audit with the Certification Authority. These
documents are explained in further detail below.
CERTON has the experience and expertise to help you develop the plans that will be approved by the Certification
Authority and govern your successful DO-178 project.
Plan for Software Aspects of Certification (PSAC)

The purpose of the PSAC is to provide the primary means used by the Certification Authority for determining
whether an applicant is proposing a software lifecycle that is commensurate with the rigor required for the DAL of
software being developed (DO-178B Section 11.1). The PSAC should include the following, at a minimum:

System Overview

Software Overview

Certification Considerations

Software Lifecycle

Software Lifecycle Data

Schedule

Additional Considerations

Software Development Plan (SDP)

The purpose of the SDP is to identify the objectives, standards, and software lifecycle(s) to be used in the
software development processes, ref. DO-178B Section 11.2. It can be included in the PSAC and should contain the
following, at a minimum:

Standards

Software Lifecycle

Software Development Environment

Software Verification Plan (SVP)

The SVP is a description of the verification procedures to satisfy the software verification process objectives,
ref. DO-178B Section 11.3. The procedures vary by software DAL as defined in the Tables of DO-178B Annex A. The
SVP should contain the following, at a minimum:

Organization

Independence

Verification Methods

Verification Environment

Transition Criteria

Software Configuration Management Plan (SCMP)

The Software Configuration Management Plan establishes the methods to be used to achieve the objectives of
the software configuration management (SCM) process throughout the software lifecycle, ref. DO-178B Section 11.4. The
SCMP should contain the following, at a minimum:

Problem Reporting

Environment

Activities

Configuration Identification

Baselines and Traceability

Change Control

Change Review

Configuration Status Accounting

Archive, Retrieval, and Release

Software Load Control

Software Lifecycle Environment Controls

Software Lifecycle Data Controls

Transition Criteria

SCM Data

Supplier Control

Software Quality Assurance Plan (SQAP)

The purpose of the SQAP is to establish the methods to be used to achieve the objectives of the software quality
assurance (SQA) process, ref. DO-178B Section 11.5. The SQAP should contain the following, at a minimum:

Environment

Authority

Activities

Transition Criteria

Timing

SQA Records

Supplier Control

CERTON provides expert Quality Assurance assessment for compliance with DO-178B. Click here to view our Corporate
Quality Assurance page.
Software Requirements, Design & Coding Standards (SRDCS)
The purpose the Software Requirements, Design, and Coding Standards is to establish a set of methods, rules, and tools
that will be used in the development of the software item to promote consistency among processes, outputs, and artifacts.
These standards will provide the constraints necessary to enforce clarity and consistency between developers and
streamline the activities associated with requirements, design, and code development, validation, and verification
throughout the software lifecycle to prevent errors that could cause safety issues, schedule impact, and budget overruns.

DO-178 Verification & Validation Phase

The most important phase in the development of DO-178 Software is the Validation & Verification Phase. The V&V
phase provides assurance for satisfying the RTCA/DO-178B objectives identified in Tables A-2 through A-9 have been
satisfied according to the objectives in Table A-1. The majority of effort involved in a DO-178 project is associated with
this phase of the software development lifecycle, beginning with the Requirements Phase and ending with the Delivery
Phase. Developing testable requirements is crucial to streamlining the DO-178 Verification & Validation processes.

Validation Process
The Validation process in this phase provides assurance that the correct software requirements and code have been
developed according to the intended functions described in the System Requirements. The High Level Requirements are
aligned with and validated against the System Requirements, the Design (Low Level) Requirements are aligned with and
validated against the High Level Requirements, and the Code Implementation is aligned with and validated against the
Design (Low Level) Requirements.
Verification Process

The Verification process in this phase provides assurance that the

executable object code performs the intended functions described by the validated High Level and Low Level
Requirements while executing in the target operational environment. Test Cases are developed and reviewed for complete
coverage (normal range and robustness) of the High Level Requirements (DAL A, B,C and D) and Low Level
Requirements (DAL A, B, and C). Test Procedures are developed and reviewed to correctly and completely implement
the Test Cases in a test environment according to the approved Software Verification Plan (SVP). The Software
Verification Cases & Procedures document (SVCP) details how to reproduce the test setups and execution, along with a
trace matrix for complete requirements based test coverage.
The Verification process checks that expected results from the written requirements are equal to the actual results
produced from the Black Box or Actual Flight Code. CERTON has developed CertSAFE and CertBENCH for Test
Case development and fully automated Test Procedure execution against Black Box LRU, Circuit Cards, or SDK boards
with the target processor.

Structural Coverage Analysis

Structural Coverage Analysis at the source code level is broken down into three categories:

Statement Coverage during execution of requirements based testing, every statement in the program should be
invoked at least one time.

Decision Coverage during execution of requirements based testing, every point of entrance and exit in the
program should be invoked at least once, and every decision in the program should take on all possible outcomes
at least once.

Modified Condition/Decision Coverage (MC/DC) during requirements based testing, every point of entry and
exit in the program should be invoked at least once, every decision should take all possible outcomes at least
once, every condition in a decision should take all possible outcomes at least once, and each condition in a
decision should be shown to independently affect the outcome of that decision.

Code structures identified during Structural Coverage Analysis that are not exercised during requirements based testing
may be the result of one or more of the following, ref. DO-178B Section 6.4.4.3:

Shortcomings in the requirements based test cases and/or procedures

Missing or inadequate in software requirements

Dead Code

Deactivated Code

The Structural Coverage Analysis activity should also confirm the data coupling and control coupling between the code
components.
Note: Requirements based test coverage for data and control coupling should be identified as part of the separate data and
control coupling analysis activities.
Also, reference DO-248B, Section 3.43:
Sections 6.4.4.2 and 6.4.4.3 of DO-178B/ED-12B define the purpose of structural coverage analysis and the possible
resolution for code structure that was not exercised during requirements-based testing.
The purpose of structural coverage analysis with the associated structural coverage analysis resolution is to complement
requirements-based testing as follows:
1. Provide evidence that the code structure was verified to the degree required for the applicable software level;
2. Provide a means to support demonstration of absence of unintended functions;
3. Establish the thoroughness of requirements-based testing.
Source to Object Code Trace Analysis (Level A Only)
The compiler converts the Source Code into assembly object code before it is compatible with the target computer. For
DAL A software, it is required to provide assurance that all assembly object code generated by the compiler is traceable to
the source code. Any assembly object code that is not traceable directly to the source code requires additional verification
to be performed in order to provide safety assurance and the absence of unintended behavior.
DO-178 Requirements Phase
The Requirements Phase uses the outputs of the System Lifecycle Process to develop the High Level Requirements. These
High Level Requirements include functional, performance, interface, and safety-related requirements, ref. DO-178B
Section 5.1.
The inputs to the Requirements Phase are as follows:

System Requirements Data (SRD) allocated to software

Hardware Interfaces and System Architecture

Software Development Plan

Software Requirements, Design, and Coding Standards (SRDCS)

The outputs to the Requirements Phase are as follows:

Software High Level Requirements Document (SHLRD)

Software High Level Signal Dictionary (SHLSD)

Software High Level Requirements Document (SHLRD)

The Software High Level Requirements Document partitions and lists the high level requirements of the
software item using functional decomposition to differentiate the functionality of the subcomponents. This includes
operational, behavioral, and functional requirements. Derived high level requirements should be provided to the system
safety assessment process. The V&V phase activities should commence as soon as a baseline of the SHLRD can be
established in CM, including reviews for clarity, consistency, and most important testability.
Software High Level Signal Dictionary (SHLSD)

The High level signal dictionary is used to capture a consolidated and universal list of all Input and Output
signals to the software from a board level perspective in order to generate requirements that are testable from end to
end. Ideally, this signal dictionary would be directly traceable to system level signals and schematics with a standardized
naming convention for all signals.
DO-178 Software Design & Architecture Phase
The DO-178 Software Design & Architecture Phase uses the outputs of the Requirements Phase to develop the low level
requirements. These low level requirements include details on the design and architecture that can be used to implement
Source Code, ref. DO-178B Section 5.2.
The inputs to the DO-178 Software Design & Architecture Phase are as follows:

Software High Level Requirements Document (SHLRD)

Software High Level Signal Dictionary (SHLSD)

Software Development Plan

Software Requirements, Design, and Coding Standards (SRDCS)

The outputs to the DO-178 Software Design & Architecture Phase are as follows:

Software Low Level Requirements Document (SLLRD)

Software Low Level Signal Dictionary (SLLSD)

Software Low Level Requirements Document (SLLRD)

The software low level requirements document identifies how the requirements are partitioned and lists the low
level requirements of the software item. Low level requirements may contain implementation specific details of how the
software will implement the functionality and behavior described in the high level requirements. Derived low level
requirements should be provided to the system safety assessment process. The V&V phase activities should commence as
soon as a baseline of the SHLRD can be established in CM, including reviews for clarity, consistency, and most important
testability.

Software Low Level Data Dictionary (SLLDD)

The low level data dictionary contains a list of the input and output signals used in the SLLRD. This document
also describes the attributes of the signals. This includes: the signal names, signal data types, operational ranges
(min/max), memory map addresses, units, etc. Ideally, this data dictionary would be directly traceable to the Software
High Level Signal Dictionary (SHLSD) with a standardized naming convention for all data.
Implementation & Integration Phase
The DO-178 Implementation & Integration Phase uses the outputs of the Design & Architecture Phase to develop the
Source Code, ref. DO-178B Section 5.2. This Source Code will be compiled and loaded onto the target computer for
verification.
The inputs to the DO-178 Implementation & Integration Phase are as follows:

Software Low Level Requirements Document (SLLRD)

Software Low Level Data Dictionary (SLLDD)

Software Development Plan

Software Requirements, Design, and Coding Standards (SRDCS)

The outputs to the DO-178 Implementation & Integration Phase are as follows:

Source Code

Executable Object Code

Source Code

This is the Source Code implementation developed from the software architecture and low level requirements
using the approved programming language specified in the SDP. This will be traceable to the low level requirements and
reviewed in order to validate the correct Source Code has been developed.
Executable Object Code

This is the assembly object code generated by the compiler from the Source Code that will be loaded onto the
target computer as part of the integration process and verified using the the requirements based test cases and procedures,
including HW/SW integration testing. For DAL A software, this will need to be shown to be directly traceable to the
Source Code from which it was generated by the compiler.
Delivery Phase
The project delivery data should be maintained in the approved CM system, which is essential for satisfying the objectives
of DO-178. In some cases, the final delivery data may be extracted from CM and burned to an electronic media format for
final delivery to the customer. At this point the project is complete and ready for certification audit (SOI-4), assuming all
other phases have been completed.
Software Configuration Index (SCI)

The primary purpose of the Software Configuration Index is to identify the configuration of the Software
product with specific information needed to produce the software item, including versions of source code files, build
instructions, software load instructions, tools, etc.
Software Environment Configuration Index (SECI)

The SECI lists the configurations of the environments used to develop and verify the software item. (For
example: OS, compiler, linker, loader, libraries, emulator, etc) This document should also be used to list the tools and
versions used in the development and verification of the software item. This may include design tools, verification tools,
requirements management tools, and test environments.
Software Accomplishment Summary (SAS)

The primary purpose of this Software Accomplishment Summary is to show compliance to the plans and
processes set forth in the PSAC. The SAS demonstrates to the Certification Authority that the objectives set forth in the
planning documents have been achieved. Any deviation from the plans that has not been approved by the Certification
Authority needs to be clearly described in the SAS.