DO-178B and DO-178C software certification standards serve as a guideline to produce airworthy airborne systems. DO-178B (Software Considerations in Airborne Systems and Equipment Certification), first published in 1992, was the predominant document taken into account to get the certification from authorities like EASA (European Union Aviation Safety Agency) and FAA (Federal Aviation Administration) for commercial software-based airborne systems. However, The Federal Aviation Regulations acknowledged DO-178C as a method of demonstrating airworthiness conformance in 2013. For more general information about DO-178B and DO-178C standards, you can read this article.
DO-178B or DO-178C standards should be satisfied by documents such as:
- 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)
These are not the only documents required to satisfy DO-178B and DO-178C standards. There are a sheer number of other documents to enrich the airworthiness. You can check and buy these documents from here.
DO178 Documents
PSAC Document
PSAC (Plan for Software Aspects of Certification) document describes the necessary standards, processes, protocols, and methodologies to be followed as well as it brings out the lifecycle data. Thus, the goals of the DO-178 documents can be fulfilled. PSAC also specifies the software development schedule and system overview. Both the certifying authority and the applicant make use of this document. PSAC should be produced in the initial software planning process and get approved by the authority. To check our PSAC Document, please click here.
SDP Document
SDP (Software Development Plan) document aims to check whether necessary information such as software development procedures, protocols, standards, lifecycles, and development environment is specified. SDP document is an essential part of the software planning period. To check our SDP Document, please click here.
SVP Document
SVP (Software Verification Plan) document specifies the necessary test cases and coverages, procedures, protocols, requirement verification, source code verification with a proper version control. SVP is also a key element of the planning process. To check our SVP Document, please click here.
SCMP Document
SCMP (Software Configuration Management Plan) document is another key aspect of the planning period. During the development process of the software, it is often the case that initial plan changes. SCMP helps us to detect, control, maintain and track those changes. It is applied throughout the software development process. SCMP aims to minimize mistake and maximize productivity. Team members must give the effort to report and notify the changes. To check our SCMP Document, please click here.
SQAP Document
SQAP (Software Quality Assurance Plan) document includes 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 the Software Quality Assurance Activities will be conducted in the project. The SQA team establish milestones and evaluates the quality of the project at each milestone. SQA is conducted throughout the software lifecycle. To check our SQAP Document, please click here.
SAS Document
SAS (Software Accomplishment Summary) document sums up software components’ each step during the development and verification. SAS should include the recap of the findings of verification tools qualification. The FAA should be notified of the SAS. That permits the certification authority to validate the verification data findings and serves as proof of the tool’s qualification status. To check our SAS Document, please click here.
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 complete aircraft systems whereas DO178 Standards are used 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 broadens the idea of design assurance for usage at the aircraft and system levels, as well as standardizes the use of the word development assurance. ARP4754 acknowledged by FAA in November 2011.
From requirements through integration and verification, ARP4754 covers the whole aircraft development cycle. ARP4754 provides abstraction for aircraft, system, and item. For the item design, ARP4754 makes explicit reference to DO-178 and DO-254. ARP4754 focuses safety assessment throughout different processes such as development, design, and verification. Nevertheless, it should be noted that ARP4754 does not include the specific scope of software or electronic hardware development, in-service safety activities and aircraft structural development.
Design Phases
Preliminary Design Review (PDR)
Preliminary design is an essential phase of the software development process. During the preliminary design, high level requirements and use cases are specified to build the system architecture. Documents for interface, database, and architecture and diagrams for component relationships can be utilized in the design. The preliminary design will offer a visual depiction of the system at the start of the project based on these inputs. Preliminary design also creates the groundwork for the following more detailed design phases. It can be seen as a blueprint.
Preliminary Design Review (PDR) ends the preliminary design phase of the project. To move forward with detailed design, PRD should offer enough assurance. The purpose of the PDR is to assure that the preliminary design and basic system architecture are complete, that there is technical confidence that the requirements can be met within budget and schedule.
Critical Design Review (CDR)
Critical Design Review (CDR) ends the critical design phase of the project. The final designs are presented with CDR through comprehensive analysis, simulations, schematics, software code, and test data. CDR assures that the system can move forward to testing and production. It also expresses that the mentioned requirements can be met within budget and schedule. The comprehensive drawings and specifications that arise provide an initial product baseline, with a final baseline. CDR should be thorough and exhaustive.
Final Design Phase
Final Design Phase provides detailed architectural and engineering drawings of each component in the project. For some projects, it might be necessary to create a final design report. Detected design problems must be solved before finishing final design phase. The drawings and report must offer enough detail to enable for reasonably accurate estimates of construction and operating costs, as well as construction timing. The final design report should include an updated timetable, cost estimates, and specifications. Also, it should be approved that the project is economically feasible. Any change during the Final Design Phase is more costly compared to other phases. Thus, it should be carried out with a lot of attention.
SOI (Stages of Involvement)
Stages of Involvement (SOI) evaluations are made by the aviation authorities of the relevant countries at various stages of the project such as planning, development, and verification in order to evaluate the DO-178B compliance of projects. In ideal cases, a total of four SOI reviews are planned.
The initial assessment, which is the first SOI, includes the planning phase of the project’s certification compliance studies. The second SOI review focuses on the development phases of the project. Beginning with the development of high-end software requirements, it questions whether the design, low-level software requirements, and source code are produced in accordance with DO178B. The third SOI review focuses on the validation phases. Not just testing activities, but all activities carried out for verification purposes are examined. The fourth SOI, on the other hand, is the closing assessment conducted near the end of the project, questioning whether there is any activity left in the open and whether a new problem has arisen since the previous assessments.
DO-178B’s expectation from the software products produced during the planning phase is to agree on a common rule set between the authority and the company making it and to comply with this rule set throughout the project. In other words, when writing plans and standards, the company not only determines its own processes but also writes the rules for how the authority will evaluate itself throughout the certification process.
Author: Can Önal ([email protected])
Mor Teknoloji
