DO-178C, Software Considerations in Airborne Systems

---

DO-178C, Software Considerations in Airborne Systems and Equipment Certification is the primary document by which the certification authorities such as FAA, EASA and Transport Canada approve all commercial software-based aerospace systems. The document is published by RTCA, Incorporated, in a joint effort with EUROCAE, and replaces DO-178B. The new document is called DO-178C/ED-12C and was completed in November 2011 and approved by the RTCA in December 2011. It became available for sale and use in January 2012.

The FAA approved AC 20-115C on 19 Jul 2013, making DO-178C a recognized "acceptable means, but not the only means, for showing compliance with the applicable airworthiness regulations for the software aspects of airborne systems and equipment certification."

 The Software Level, also known as the Development Assurance Level (DAL) or Item Development Assurance Level (IDAL) as defined in ARP4754 (DO-178C only mentions IDAL as synonymous with Software Level[10]), is determined from the safety assessment process and hazard analysis by examining the effects of a failure condition in the system. The failure conditions are categorized by their effects on the aircraft, crew, and passengers.

• Catastrophic - Failure may cause deaths, usually with loss of the aircraft.
• Hazardous - Failure has a large negative impact on safety or performance, or reduces the ability of the crew to operate the aircraft due to physical distress or a higher workload, or causes serious or fatal injuries among the passengers.
• Major - Failure significantly reduces the safety margin or significantly increases crew workload. May result in passenger discomfort (or even minor injuries).
• Minor - Failure slightly reduces the safety margin or slightly increases crew workload. Examples might include causing passenger inconvenience or a routine flight plan change.
• No Effect - Failure has no impact on safety, aircraft operation, or crew workload.

DO-178C alone is not intended to guarantee software safety aspects. Safety attributes in the design and as implemented as functionality must receive additional mandatory system safety tasks to drive and show objective evidence of meeting explicit safety requirements. The certification authorities require and DO-178C specifies the correct DAL be established using these comprehensive analyses methods to establish the software level A-E. "The software level establishes the rigor necessary to demonstrate compliance" with DO-178C.[10] Any software that commands, controls, and monitors safety-critical functions should receive the highest DAL - Level A.

The number of objectives to be satisfied (some with independence) is determined by the software level A-E. The phrase "with independence" refers to a separation of responsibilities where the objectivity of the verification and validation processes is ensured by virtue of their "independence" from the software development team. For objectives that must be satisfied with independence, the person verifying the item (such as a requirement or source code) may not be the person who authored the item and this separation must be clearly documented.

Level     Failure condition     Objectives     With independence:

 A                        Catastrophic                71                              30

 B                        Hazardous                    69                              18

 C                        Major                               62                                5

 D                        Minor                              26                                 2

 E                        No Safety Effect            0                                  0
 

Processes are intended to support the objectives, according to the software level (A through D—Level E was outside the purview of DO-178C). Processes are described as abstract areas of work in DO-178C, and it is up to the planners of a real project to define and document the specifics of how a process will be carried out. On a real project, the actual activities that will be done in the context of a process must be shown to support the objectives. These activities are defined by the project planners as part of the Planning process.

This objective-based nature of DO-178C allows a great deal of flexibility in regard to following different styles of software life cycle. Once an activity within a process has been defined, it is generally expected that the project respect that documented activity within its process. Furthermore, processes (and their concrete activities) must have well defined entry and exit criteria, according to DO-178C, and a project must show that it is respecting those criteria as it performs the activities in the process.

The flexible nature of DO-178C's processes and entry/exit criteria make it difficult to implement the first time, because these aspects are abstract and there is no "base set" of activities from which to work. The intention of DO-178C was not to be prescriptive. There are many possible and acceptable ways for a real project to define these aspects. This can be difficult the first time a company attempts to develop a civil avionics system under this standard, and has created a niche market for DO-178C training and consulting.

For a generic DO-178C based process, Stages of Involvements (SOI) are the minimum gates that a Certification Authority gets involved in reviewing a system or sub-system as defined by EASA on the Certification Memorandum SWCEH – 002: SW Approval Guidelines and FAA on the Order 8110.49: SW Approval Guidelines.

DO-178C PLANS & STANDARDS

📷

DO-178C PLANS & STANDARDS

•  DO-178C plans and standards are guidelines and templates that help ensure the safe development of software for aviation systems. The Radio Technical Commission for Aeronautics (RTCA) developed DO-178C.  

· DO-178C Plan for Software Aspects of Certification (PSAC)

•  The Plan for Software Aspects of Certification (PSAC) document describes the methodology used and the evidence created for the Government certification of software compliance within similar civil performance standards for RTCA/DO-178C "Software Considerations in Airborne Systems and Equipment". The PSAC is the primary means used by the certification authority for determining whether an applicant is proposing a software life cycle that is commensurate with the rigor required for the level of software being developed. 

· DO-178C Plan for Software Software Aspects of Certification (PSSAC)

•  A "Plan for Safety Software Aspects of Certification" (PSSAC) document is a critical document used in the development of safety-critical software systems, outlining the specific strategies and processes that will be employed to ensure the software meets the necessary safety standards and requirements for certification, typically following guidelines like RTCA DO-178C in aviation systems.  

· DO-178C Software Quality Assurance Plan (SQAP)

•  The DO-178C Software Quality Assurance Plan (SQAP) is a document that outlines how to meet quality assurance objectives for software in airborne systems. It's one of several plans required to comply with DO-178C, an industry standard for aviation software.  

· DO-178C Software Configuration Management Plan (SCMP)

•  The DO-178C Software Configuration Management Plan (SCMP) is a document that outlines how to manage software configuration throughout the development process. The SCMP is used to ensure that software is properly identified, controlled, and audited.  

· DO-178C Software Development Plan (SDP)

•  A DO-178C Software Development Plan (SDP) is a detailed document outlining the strategy and processes a software development team will use to create airborne software, ensuring compliance with the DO-178C standard, which sets strict guidelines for developing safety-critical software in the aviation industry; it describes the software life cycle, development methodologies, verification and validation plans, configuration management practices, and quality assurance activities to be employed throughout the project, all tailored to meet the specific requirements of the DO-178C standard 

· DO-178C Software Verification Plan (SVP)

•  A DO-178C Software Verification Plan (SVP) is a detailed document outlining the strategies, methods, and tools that will be used to verify software developed for avionics systems, ensuring it meets the rigorous safety standards set by the DO-178C standard, which governs the development of critical airborne software; essentially, it describes how the software will be reviewed, tested, and analyzed to confirm its functionality and compliance with requirements throughout the development lifecycle.  

· DO-178C Software Traceability (ST)

•  A "DO-178C Software  Traceability refers to the ability to track and document the history, location, and application of software requirements and products throughout their lifecycle, from design and development to manufacturing, testing, and deployment.  

· DO-178C Software Requirement Standard (SRS)

•  A "DO-178C Software Requirement Standard (SRS)" refers to a set of requirements defined within the DO-178C standard, which outlines the criteria for developing and verifying software used in critical airborne systems in commercial aviation, ensuring that the software meets stringent safety standards and is suitable for its intended use in aircraft systems; essentially, it specifies the necessary functions and attributes that the software must possess to be considered airworthy.  

· DO-178C Software Design Standard (SDS)

•  DO-178C is a standard that provides guidance for developing software for avionics systems. It's used to ensure that software is safe and meets regulatory standards. The standard covers the entire software lifecycle, including planning, development, and verification.  

· DO-178C Software Coding Standard (SCS)

•  DO-178C is a standard for software development in the aerospace and defense industries. It's used to certify that software for airborne systems meets airworthiness regulations.  

· DO-178C Software Accomplishment Summary (SAS)

•  A DO-178C Software Accomplishment Summary (SAS) is a comprehensive document that details all the steps taken during the software development and verification process for an airborne system, demonstrating compliance with the DO-178C standard, which outlines requirements for critical software used in aviation systems; essentially, it serves as a summary of the compliance efforts undertaken to certify the software against aviation safety standards, including verification results, methodologies used, and any deviations from the standard process.

DO-178C Stage of Involvement (SOI)

• · DO-178C Stage of Involvement #1

1.  Stage of Involvement (SOI) #1 for DO-178C is the planning phase, which includes reviewing plans and standards to ensure they meet objectives.  

• · DO-178C Stage of Involvement #2

1.  Stage of Involvement (SOI) #2 is a review that happens during the development phase of the DO-178C process. It's part of a series of reviews that certification authorities perform to ensure compliance with DO-178C.  

• · DO-178C Stage of Involvement #3

1.  In the context of DO-178C, "Stage of Involvement #3" (SOI #3) refers to the verification review stage where the certification authority primarily focuses on examining the software verification process itself, including test cases, procedures, results, and coverage analyses, to ensure the software meets the required safety standards; essentially, verifying that the verification process was conducted properly and provides sufficient evidence of software correctness.  

• · DO-178C Stage of Involvement #4

1.  Stage of Involvement (SOI) #4 in DO-178C is the final certification review. It's a key milestone in the development process that assesses the software's compliance with airworthiness regulations.  

DO-178C CHECKLISTS for PLANS & STANDARDS

📷

DO-178C CHECKLISTS

• · DO-178C Plan for Software Aspects of Certification
• · DO-178C Software Quality Assurance Plan
• · DO-178C Software Configuration Management Plan
• · DO-178C Software Development Plan
• · DO-178C Software Verification Plan
• · DO-178C Software Requirements Standard
• · DO-178C Software Design Standard
• · DO-178C Software Coding Standard
• · DO-178C Software Configuration Index
• · DO-178C Software Requirements
• · DO-178C Software Design Data
• · DO-178C Source Code Review
• · DO-178C Software Test Procedures
• · DO-178C Software Verification Results
• · DO-178C Software Verification Analysis (including Traceability)
• · DO-178C Software Accomplishment Summary

DO-178C Stage of Involvement (SOI)

• · DO-178C Stage of Involvement #1
• · DO-178C Stage of Involvement #2
• · DO-178C Stage of Involvement #3
• · DO-178C Stage of Involvement #4