DO-178C

July 5, 2022 12:16 PM

• Published in 2011
• More objectives added to DALs A to C
• Clearer and unambiguous language
• Added following supplements
○ Software Tool Qualification (DO-330)
○ Model-based Development (DO-331)
○ Object Oriented Software (DO-332)
○ Formal Methods (DO-333)
• Tool Qualification Levels (TQL)
○ TQL 1 to 4 with decreasing criticality
○ TQL 5 not critical

• DO 178C Software Life Cycle

Standards Page 1
○

Standards Page 2
 •

Key Concepts
• Dead Code
○ executable (binary) software that will never be executed during runtime operations
○ Dead code does not trace to any software requirements, hence does not perform any
required functionality
○ unreferenced variables or functions which are not called (hence are unreferenced)
elsewhere in the program are usually removed via the compiler or linker. Since they are not
present in the binary executable load image, they are not dead code per DO-178B
○ Unused library functions cannot be considered as dead code.
• Deactivated Code
○ Two types
 Piece of code which is traceable to the requirement but is not used under the any
configuration
 Piece of code which is traceable to the requirements and only meant for the execution
under a particular configuration
○ executable (binary) software that will not be executed during runtime operations of a
particular software version within a particular avionics box; however the code may be
executed during maintenance or special operations or be executed within a different or
future version of the software within a different configuration or avionics box
○ deactivated code may be left in the source baseline. Special DO-178B deactivated code
aspects must be followed
○ Following are not considered as deactivated code:
 Defensive Code Structure inserted for robustness
 Compiler inserted code for range and array index checks

Standards Page 3
  Compiler inserted code for range and array index checks
 Error or exception handling routines
 Code for Bound checking
○ Deactivated Code could be found as part of the Structural Coverage Analysis. An
analysis/testing needs to be performed to prove that the deactivated code will not execute
accidentally and will not affect the normal execution of the software.
• Requirements Traceability
○ correlation of individual requirements to the design, code, and test elements affiliated with
implementing and verifying each requirement
○ can be many-to-one, and one-to-many
○ Bi-directional traceability
 Top-Down/top-to-bottom
□ requirements -> design -> code
□ requirements -> test
□ proves that all requirements have corresponding design elements, source-code,
and tests
 Bottom-Up/bottom-to-top
□ tests -> requirements
□ code -> design -> requirements
□ proves that all code, design, and test elements are necessary and have
requirements which they implement or verify.
○ Traceability can be either explicit (thru traceability metrices) or implicit (thru file naming
conventions)
• DO-178B emphasizes code consistency, visibility, determinism, defensive coding, robustness,
requirements and design traceability, software peer reviews per detailed checklists, thorough
testing via structural coverage and real-world asynchronous testing.
• DO-178B Certifiability - designation of an avionics component to meet a defined subset of the
DO-178B certification requirements, with the remaining certification requirements to be achieved
subsequently
○ requires all software components of a system to be completed, with each component, and
the system, fully meeting all DO-178B requirements
○ in the absence of a completed system, an individual software component (RTOS, graphics
library, communications protocol, etc) can be designated certifiable by subjecting that
component to all DO-178B requirements
• Top Ten Do-178b Certification Risks
○ inadequate DO-178B low-level software requirements
○ vagueness within the five key DO-178B process plans prior to initiating those lifecycles
○ insufficient independence of DO-178B reviews
○ insufficient DO-178B checklists for reviews
○ inadequate DO-178B traceability between components
○ insufficient advance FAA coordination/approvals
○ incomplete DO-178B structural coverage for decision condition and MCDC coverage
○ over doing DO-178B tool qualification
○ not applying DO-254 to hardware
○ avionics outsourcing without a clear DO-178B Project Plan covering details for the avionic
outsource team
• DO-178B specifies that each line of code is required and tested, and that no unused code exists in
the application program build.
• Testing must be done to the entire product as a whole. If you happen to uncover a bug during
certification testing, and have to change your code at all, the entire certification tests must be re-
run to be compliant.
• Stages of Involvement (SOI)
○ SOI 1 - Software Planning Review
○ SOI 2 - Software Development Review
SOI 3 - Software Verification Review

Standards Page 4
 ○ SOI 3 - Software Verification Review
○ SOI 4 - Final Certification Review
• Coupling - degree of interdependence among different software component
○ Data Coupling - The dependence of a software component on data not exclusively under the
control of that software component.
○ Control Coupling - The manner or degree by which one software component influences the
execution of another software component.
○ Can be satisfied only thru integration testing
• Multiple Version Dissimilar Software
○ Aka N-version programming technique
○ popular technique used for safety-critical civil aviation software to avoid the common errors
○ allows two or N number of software instances with different implementation to provide the
same operational output, based on same requirements
○ Voting ensures agreement
• Robustness Test Case - to validate the software behaviour under abnormal conditions and
extreme/invalid inputs.
• Fault Tolerance - allows the system to continue its execution and provide correct output even
after a limited number of software/hardware failures
• ED-12B/C - equivalent to DO178B for European aviation industry published by EUROCAE
• there could be 50-350% of additional cost to follow the DO-178C guidelines and meet the
DO-178C objectives
• FAA’s position is that if an applicant provides evidence to satisfy the objectives, then the software
is DO-178B compliant
• Previously Developed Software
○ One of the 4 categories
 Commercial off-the-shelf software (COTS)
 Airborne software developed to other standards (e.g., MIL-STD-498)
 Airborne software that predates DO-178B (e.g., developed to the original DO-178 or
DO-178A)
 Airborne software previously developed at a lower software level.
○ Use of them should be planned in PSAC and gap analysis to be done where objectives are
not met
• Formal Methods - Mathematical techniques used for specification, development and verification
of a software/avionics software.
○ can be used to prove that software is an accurate representation of the mathematical
expressions
• Single point of failure (SPOF) - a part of a system or a component that, if it fails, will stop the entire
system from working
○ Redundant implementation can minimize or eliminate it
 Control redundancy
□ N-version programming;
□ recovery blocks;
□ exception handling.
 Data redundancy
○ Error detecting/correcting codes and checksum agreements can be used for data fault
tolerance
○ Fault tree analysis can help in determining single point failures.
• The base set of required documentation and life cycle artifacts include:
○ Plan for Software Aspects of Certification (PSAC)
○ Software Quality Assurance Plan
○ Software Configuration Management Plan
○ Configuration Control Procedures
○ Software Code Standard
○ Software Design Standard
Software Requirements Standard

Standards Page 5
○ Software Requirements Standard
○ Software Development Plan
○ Software Verification Plan
○ Source, Executable Object Code, SCI and SECI
○ Software Design Document
○ Software Requirements Document
○ Traceability
○ Test Cases and Procedures
○ Verification Results
○ Quality Assurance Records
○ Configuration Management Records
○ Problem Reports
○ Software Accomplishments Summary

Standards Page 6