DO-178B

November 26, 2020 12:05 PM

• Software Considerations in Airborne Systems and Equipment Certification

• DO-178 -> DO-178A (1985) -> DO-178B (1992) -> DO-178C (2011)
• It is a guideline document - org standards to incorporate these guidelines in its own processes
• Key features
○ Represents consensus of aviation industry
○ Objective based - does not prescribe any process - not process/evidence based
○ 5 s/w levels
○ Requirement based testing
○ Structural Coverage analysis
○ Traceability - bidirectional
○ Avoids making quantitative claims for software failure rates
• Developed based on industry experience - not mandated by law, but represent a consensus of the
aviation community
• DO-248B - supporting document with clarifications published in 2001
• Guidance for determining in a consistent manner and with acceptable level of confidence that
software aspects of airborne systems and equipment comply with airworthiness requirements.
○ Sole focus on design assurance
○ Management scope and schedule is out of scope
• guidelines are in the form of:
○ Objectives for software life cycle processes.
○ Descriptions of activities and design considerations for achieving those objectives
○ Descriptions of the evidence that indicate that the objectives have been satisfied.
• Document Organisation

Standards Page 1
 ○

○ 12 sections, 2 annexes and 4 appendices

 Annex A - Objectives
• For each software level, certain objectives are defined, which needs to be met for a software
developed with a particular level -
○ aka Design Assurance Levels (DAL)
 Level A - 66 objectives to be satisfied
□ software whose anomalous behavior, as shown by the system safety
assessment process, would cause or contribute to a failure of system function
resulting in a catastrophic failure condition for the aircraft
□ Failure of DO-178B Level A software could be typified by total loss of life
□ Approximately 20-30% of avionics systems and 40% of avionics software code

Standards Page 2
 □ Approximately 20-30% of avionics systems and 40% of avionics software code
must meet DO-178B Level A criteria.
 Level B - 65 objectives to be satisfied
□ software whose anomalous behavior would cause or contribute to a failure of
system function resulting in a hazardous/severe-major failure condition for the
aircraft
□ could be typified by some loss of life
□ Approximately 20% of avionics systems and 30% of avionics software code
 Level C - 57 objectives to be satisfied
□ software whose anomalous behavior would cause or contribute to a failure of
system function resulting in a major failure condition for the aircraft
□ typified by serious injuries
□ Approximately 25% of avionics systems and 20% of avionics software code
 Level D - 28 objectives to be satisfied
□ would cause or contribute to a failure of system function resulting in a minor
failure condition for the aircraft
□ typified by minor injuries
□ Approximately 20% of avionics systems and 10% of avionics software code
 Level E - None
□ would cause or contribute to a failure of system function with no effect on
aircraft operational capability or pilot workload
□ no impact on passenger or aircraft safety
□ Approximately 10% of avionics systems and 5% of avionics software code
○ based upon the contribution of the associated software to potential failure conditions
○ Categorization of failure conditions, definition of software levels, and software level
determination is defined in Section 2.2
○ Each avionics system has one defined criticality level (and must be approved by the FAA);
however different components within that system can have differing criticality levels subject
to certain guidelines.

• Each of the software levels have defined acceptable failure probability

○ DAL A (Catastrophic): 109hrs/failure = 114077 years
○ DAL B (Hazardous): 107hrs/failure = 1141 years
○ DAL C (Major): 105hrs/failure = 11 years
○ DAL D (Minor): 103hrs/failure = 42 days
• Not a software development standard - focuses on aspects like traceability and verification (most
focus).
• Requirement based test approach
• PSAC - Plan for Software Aspects of Certification
○ Complete blueprint of the certification process - commitment to the certifying agencies
regarding what will be delivered for the software certification
○ PSAC will be sent to the certifying agency and they should approve it. Once approved it
becomes the base for all further activities in the development lifecycle
○ Any change in PSAC will necessitates a re-approval of it from the certifying authority
○ No template is defined for PSAC document in the standard. We are free to adopt any
• DO178B does not prescribe any specific life cycle model. We can choose any model as long as all
the objectives for the defined level are met.
• Transition criteria for each process/activity needs to be defined clearly, which includes
Entry criteria

Standards Page 3
 ○ Entry criteria
○ Exit criteria
• E-T-V-X model
○ Entry Criteria
○ Tasks
○ Verification
○ Exit Criteria
• Error prevention is the main focus due to which high importance is given to planning phase to
define standards and processes to be followed well in advance.
• Following plans to be defined to achieve the objectives of DO178B
○ Plan for Software Aspects of Certification (PSAC)(11.1)
○ Software Development Plan (SDP)(11.2)
○ Software Verification Plan (SVP)(11.3)
○ Software Configuration Management Plan (SCMP)(11.4)
○ Software Quality Assurance Plan (SQAP)(11.5)
• These plans should include consideration of methods, languages, standards, and tools to be used
during the development.
• Software Lifecycle Environment Planning (4.4)
○ Defines the methods, tools, procedures, programming languages and hardware that will be
used to develop, verify, control and produce the software lifecycle data and software
product.
○ Helps to enforce standards, detect errors and implement error prevention and fault
tolerance methods
○ Software Development Environments: languages, compilers, tools
○ Software Test Environment: target/host computers, emulators/simulators
• Software Development Process include requirements, design and integration
• Integral processes span across the complete software lifecycle.
• Verification defined as a combination of
○ REVIEW: Provide a qualitative assessment of correctness - include requirements reviews,
design reviews and test procedure reviews
○ ANALYSIS: Provide repeatable evidence of correctness
 algorithmic or procedural in nature
 Eg: timing, stack, data flow, and control flow analyses
○ TESTING: Demonstrate with confidence that the software satisfies its high and low level
requirements
 structural coverage analysis
□ Level A - MCDC + Level B
□ Level B - Decision Coverage + Level C
□ Level C - Statement Coverage
□ Level D,E - No coverage req
□ Structural coverage analysis may be performed on source code only to the
extent that the source code can be shown to map directly to object code - since
some compilers may introduce code or structure that is different from source
code
 normal range and abnormal inputs (robustness test)
• Software Quality Assurance
○ provide oversight of the entire DO-178B process
○ require independence at all levels
○ Guarantees detection of plans and standards, deviated during development process are
recorded, evaluated, tracked and resolved
• Certification Liaison Process
○ 3 data items specific to certifying authority
 Plan for Software Aspects of Certification (PSAC)
 Software Configuration Index
 Software Accomplishment Summary
○ Other data items are requested by the certification authority if necessary
• Independence in satisfying the objectives
attribute of separate development and review authority applied to different DO-178B

Standards Page 4
 ○ attribute of separate development and review authority applied to different DO-178B
lifecycle process steps
○ the objective should be satisfied by an independent person other than the once who
actually did the software development activity.
○ Can be a different person in the same team, or from different team, department or even
company
• Control category level - software configuration management control
○ Two CC levels
 CC1 - 13 process objectives
 CC2 - 6 process objectives
○ Objectives include traceability, protection against unauthorised changes etc
• Tool Qualification
○ Tools cannot be certified for DO178B
○ The tool vender can provide the qualification data and artifacts and it needs to be qualified
as a part of the project for each DO178B software
• DO-178b Gap Analysis
○ evaluation of your current avionics software engineering process and artifacts as contrasted
to those required by DO-178B
○ DO-178B Compliance is near-certification but does not require FAA involvement and several
of the formal DO-178B requirements are lessened
○ typically performed by trained DO-178B consultants or Designated Engineering
Representatives
○ DO-178B Gap Analysis RoadMap assesses all of the software processes and artifacts. It
provides details for filling the gap to meet DO-178B compliance or certification
requirements.
• Some issues:
○ There is not a clear criteria for acceptance of software reuse, new techniques like object-
oriented technology and automated tools - covered in DO-178C
○ Phases like installation, maintenance and operation are not discussed in DO-178B
○ does not assure that the system requirements are correct.
○ sometimes misunderstood as software development standard rather than an assurance
standard

Standards Page 5