Professional Documents
Culture Documents
DO 178 Project
DO 178 Project
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
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.
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
Schedule
Additional Considerations
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
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
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
Change Control
Change Review
Transition Criteria
SCM Data
Supplier Control
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.
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
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:
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:
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:
The outputs to the DO-178 Software Design & Architecture Phase are as follows:
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.
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:
The outputs to the DO-178 Implementation & Integration Phase are as follows:
Source 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.