DO-178B and DO-178C software certification standards serve as a guide for producing airworthy air systems. First published in 1992, DO-178B (Software Considerations in Airborne Systems and Equipment Certification) was an important document considered for obtaining necessary certification from commercial authorities such as EASA (European Union Aviation Safety Agency) and FAA (Federal Aviation Administration) for software-based air systems. However, Federal Aviation Regulations accepted DO-178C as a method demonstrating airworthiness compliance in 2013. For more general information about DO-178B and DO-178C standards, you can read this article.
DO-178B or DO178C standards must be met by the following example documents and more.
- PSAC (Plan for Software Aspects of Certification)
- SDP (Software Development Plan)
- SVP (Software Verification Plan)
- SCMP (Software Configuration Management Plan)
- SQAP (Software Quality Assurance Plan)
- SAS (Software Accomplishment Summary)
The documents required to meet DO-178B and DO-178C standards are not limited to these. There are numerous other documents that will enrich airworthiness. You can check and purchase these documents here.
DO178 Documents
PSAC Document
PSAC (Plan for Software Aspects of Certification) document, in addition to producing lifecycle data, explains the necessary standards, processes, protocols, and methodologies to be followed. Thus, DO-178 standards can be met. PSAC also specifies the software development schedule and overall system status. Both the approving authority and the applicant benefit from this document. PSAC must be produced during the initial software planning process and approved by the certification authority. Please click here to check our PSAC document.
SDP Document
SDP (Software Development Plan) document aims to check whether necessary information such as development procedures, protocols, standards, lifecycles, and development environment have been determined. The SDP document is an important part of the software planning process. Please click here to check our SDP document.
SVP Document
SVP (Software Verification Plan) document specifies the required test scenarios and coverage, procedures, protocols, requirements verification, and source code verification while providing appropriate version control. SVP is also an important part of the planning process. Please click here to check our SVP document.
SCMP Document
SCMP (Software Configuration Management Plan) document is another important element of the planning process. The initial plan prepared throughout the software development process often undergoes changes. SCMP helps us detect, control, maintain, and track these changes. It is applied throughout the software development process. SCMP aims to minimize errors and maximize efficiency. Team members must make efforts to report and notify each other of changes. Please click here to check our SCMP document.
SQAP Document
SQAP (Software Quality Assurance Plan) document contains the tools, methods, and techniques used to ensure that a product or service meets the specifications given in the SRS (Software Requirement specification). SQAP explains how Software Quality Assurance Activities will be conducted in the project. The SQA team establishes milestones and evaluates the quality of the project at each milestone. SQA is conducted throughout the software lifecycle. Please click here to check our SQAP document
SAS Document
SAS (Software Accomplishment Summary) summarizes every step of software components during development and verification processes. SAS should include a summary of findings from verification tool qualification. The FAA should be informed about SAS. This provides the certification authority with validation of the verification data findings and serves as evidence of the tool's qualification status. Please click here to check our SAS document
ARP4754 Standards and DO178 Standards
ARP4754 stands for "Aerospace Recommended Practice ARP4754A Guidelines for Development of Civil Aircraft and Systems." ARP4754 Standards provide guidance for aircraft systems as a whole, while DO178 Standards are used only for flight software. Both standards are accepted by authorities such as FAA and EASA.
ARP4754 was developed and published by SAE (Society of Automotive Engineers) in 1996. In 2010, SAE published ARP4754A, which stands for Guidelines for Development of Civil Aircraft and Systems. ARP4754A enriches the idea of design assurance used at aircraft and system levels, and also standardizes the use of the term development assurance. ARP4754 was approved by the FAA in November 2011.
ARP4754 covers the entire aircraft development cycle from requirements identification to the end of integration and verification processes. ARP4754 provides abstraction for aircraft, systems, and components. For component design, ARP4754 explicitly refers to DO-178 and DO-254. ARP4754 focuses on safety assessment through different processes such as development, design, and verification. However, it should be noted that ARP4754 does not include the specific scope of software or electronic hardware development, in-service safety activities, and the aircraft structural development process.
Design Phases
Preliminary Design Review (PDR)
Preliminary design is an important phase of the software development process. During preliminary design, high-level requirements and use cases are identified to form the system architecture. Documents for interface, database, and architecture, and diagrams for component relationships can be used in the design. Preliminary design will provide a visual depiction of the system at the beginning of the project based on these inputs. Preliminary design also lays the groundwork for the following more detailed design phases. It can be seen as a draft.
Preliminary Design Review (PDR) concludes the preliminary design phase of the project. The PDR must provide sufficient assurance to proceed with detailed design. The purpose of PDR is to ensure that the preliminary design and basic system architecture are complete, and that there is technical confidence that requirements can be met within budget and schedule.
Critical Design Review (CDR)
Critical Design Review (CDR) concludes the critical design phase of the project. Final designs are presented through CDR via comprehensive analysis, simulations, schematics, software code, and test data. CDR ensures that the system can proceed to test and production. It also states that the requirements in question can be met within budget and timeline. The resulting comprehensive drawings and specifications provide a final baseline along with an initial product baseline. CDR must be broad in scope and detailed.
Final Design Phase
Final Design Phase provides detailed architectural and engineering drawings of each component in the project. For some projects, a final design report may need to be created. Identified design problems must be resolved before the final design phase is completed. Drawings and reports must provide sufficient detail to enable planned estimates. The final design report should include an updated timeline, cost estimates, and specifications. It must also be confirmed that the project is economically feasible. Any changes made during the Final Design Phase are more costly compared to other phases. Therefore, they must be carried out very carefully.
SOI (Stages of Involvement)
To evaluate the DO-178B compliance of projects, SOI evaluations are conducted by aviation authorities of the relevant countries at various stages of the project, such as planning, development, and verification. Ideally, a total of four SOI reviews are planned.
The first SOI evaluation covers the planning phase of the project's certification compliance work. The second SOI review focuses on the project's development phases. Starting with the development of high-level software requirements, it questions whether the design, low-level software requirements, and source code have been produced in compliance with DO178B. The third SOI review focuses on verification phases. Not only test activities, but all activities performed for verification purposes are reviewed. The fourth SOI is the closing evaluation conducted towards the end of the project, questioning whether there are any outstanding activities and whether any new issues have arisen since the previous evaluations.
The expectation of DO-178B from software products produced in the planning phase is to agree on a common set of rules between the authority and the company performing it, and to adhere to this set of rules throughout the project. In other words, when writing plans and standards, the company not only determines its own processes but also writes the rules on how the authority will evaluate itself throughout the certification process.
Author: Can Önal ([email protected])
