DO-178 Introduction Whitepaper
Avionics certification explained
FOR ENGINEERS AND MANAGERS
Avionics certification explained – the big picture. The roles of Safety (ARP4761A), Systems (ARP4754A) and the avionics development ecosystem are fully described along DO-178C’s and DO-254’s relationship facts.
DO-178 has an innocuous title: ”Software Considerations in Airborne Systems and Equipment Certification.” But it’s best not to judge the book by its cover. In reality. ‘178,’ as Industry slang calls it. is largely considered the bible of avionics software development. Interestingly, since it was first developed in the 80’s (a time in which there was relatively little software in safety-critical systems), it has become the de facto embodiment for much of those systems. In fact, a careful examination of standards within Military aviation, medical devices, railroads, automotive, and nuclear power will reveal striking similarities with 178. An accidental coincidence? Hardly. Was 178 the first such standard? That answer hardly matters. except that history is important. And why is history important in the case of DO-178? Because 178 has evolved via three subsequent iterations and it’s important to understand the reasons for those changes.
Remember the parable about the seven blind men and the elephant? Each touched a different part of the elephant and tried to describe what they were touching without knowing anything about the other parts of the elephant. An impossible task indeed, yet it’s an easy trap to tall into within aviation: aircraft and their systems are so complex that no single person can fully understand all the intricacies. In other words. without enlightenment. we’re all little better than the blind men. DO-178 attempts to lay a framework so that development personnel and certification authorities can work with full vision and leave residual blindness behind. 178 does succeed in providing such a framework. However, it doesn’t guarantee clarity of vision and certainly not perfection. What. avionics software is not perfect? Of course not. DO-178 isn’t perfect? Hardly. In fact, paraphrasing Winston Churchill’s famous quotation concerning democracy. ‘DO-178 is the worst standard in the world except tor all the others!”
Development Assurance (Criticality) Levels:
First, you need to understand the Development Assurance Level (DAL) of the software you are developing for DO-178. The rigor applied to planning, development, and correctness of your software is directly associated with its DAL—often referred to as “criticality level.” There are five levels, with increasing rigor from Level E to the most stringent Level A, as depicted below. Note that the assigned level is dependent upon type of aircraft; the following is for Part 25 aircraft, e.g. larger aircraft and applies to both DO-178, DO-254, DO-178B, and DO-178C:
Required Independence versus DAL for DO-178 & DO-254
DO-178 has specific objectives based upon the criticality level of the software. Higher DAL’s must satisfy more DO-178 objectives than lower levels. After the software criticality level has been determined, you examine DO-178 to determine exactly which objectives must be satisfied for the software. Now you are ready for planning. This is where DO-178 is similar to building a house: you’ve performed geographic analysis to determine what type of foundation is required—that is your “safety assessment”. Then you need a Planning Process, followed by a Development Process. A concurrent Correctness Process is ongoing throughout both Planning and Development. Avionics software engineering under DO-178 is thus the same as building a house and follows the same three-phased process approach.
DO-178 & DO-254 have three integral processes: Planning, Development, and Correctness:
As can be seen in the above figure: the DO-178 Planning process comes first, and when complete is followed by a larger DO-178 Development process. In the background the largest process, Correctness (Integral Processes: QA, CM, Verification, FAA Certification Liaison), is performed continuously. What is meant by Planning, Development, and Correctness? Here is a brief summary.
Planning Process. Before development, or before re-using pre-existing or legacy software, you need to plan your activities. Just like building a house, the building inspectors first need to inspect a set of plans followed by regular inspections of the house as it’s being built: foundation, walls, electrical, plumbing, roof, and the finished building. DO-178 is similar. There are five plans and three standards associated with the Planning Process:
- Plan for Software Aspects of Certification (PSAC): an overall synopsis for how your software engineering will comply with DO-178, and the roles for FAA certification and EASA certification.
- Software Quality Assurance Plan (SQAP): details how DO-178’s quality assurance objectives will be met for this project.
- Software Configuration Management Plan (SCMP): details how DO-178’s change management and baseline/storage objectives will be performed on this project.
- Software Development Plan (SDP): summarizes how software requirements, design, code, and integration will be performed in conjunction with the usage of associated tools to satisfy DO-178’s development objectives.
- Software Verification Plan (SVP): summarizes the review, test, and analysis activities, along with associated verification tools, to satisfy DO-178’s verification objectives.
- Software Requirements Standard: provides criteria for the decomposition and assessment of System Requirements into software high-level requirements and high-level to low-level requirements; including derived and safety related requirements.
- Software Design Standard: provides criteria for defining and assessing the software architecture and design.
- Software Coding Standard: provides criteria for implementing and assessing the software source-code.
Figure: DO-178C’s Five Plans & Three Standards (reprint from AFuzion’s DO-178C Training)
DO-178C Plans, Standards, and Checklists are not provided by FAA/EASA since they are tailored for specific systems. DO-178C five plans are theoretically equally important but AFuzion ranks them in the following order of importance:
- 1. PSAC: the DO-178C Plan for Software Aspects of Consideration is the #1 document and always submitted to certification authority.
- 2. SQAP: the DO-178C Software Quality Assurance Plan defines your independent proof of conformance and audit strategy to prove that conformance.
- 3. SCMP: the DO-178C Software Configuration Management Plan documents your strategy to control baselines, versions, changes, and ability to recreate software.
- 4. SDP: the DO-178C Software Development Plan defines your strategy for developing safe software requirements, design, implementation, and integration.
- 5. SVP: the DO-178C Software Verification Plan defines the strategy to review, test, and analysis the corresponding software requirements and code.
Each of the above DO-178C Plans typically requires 40-50 pages each. While established avionics companies have their own plans, over 300 new and smaller companies procured AFuzion’s DO-178C Plan templates which are in used by 7,500 engineers worldwide – more information (and free samples of DO-178C Plans) are available here: https://afuzion.com/plans-checklists/#do-178c-plan-templates
First Focus: DO-178 Tests Based Upon Requirements (E.g. Functional Testing)
DO-178C testing is a unique blend of traditional “black-box” (test the requirements, not the implementation) and “white-box” (test the actual software design/code). DO-178C requires four basic testing techniques as depicted in the following figure:
Figure: DO-178C’s Four Basic Test Categories (reprint from AFuzion’s DO-178C Training)
Under the former DO-178B, software testing was often “execution” based, meaning not explicitly traced to software requirements. However, the DO-178B upgrade to DO-178C emphasizes “requirements-based” testing, where DO-178C High Level Requirements, Low Level Requirements, Code, and Tests have verified bi-directional traceability as depicted in the following DO-178C Traceability Figure:
Figure: DO-178C’s Bi-Directional Traceability (reprint from AFuzion’s DO-178C Training)
For additional information on DO-178C traceability, download AFuzion’s “DO-178C Traceability” paper here: https://afuzion.com/traceability/
DO-178C also requires proof of deterministic software design, inclusive of software data flow, control flow, and coupling analysis. DO-178C’s data coupling is quite mainstream; however DO-178C’s control coupling is often misunderstood. AFuzion’s advanced DO-178C training covers all of data flow, control flow, and DFCF coupling analysis but the following two graphics more fully explain DO-178C control coupling:
It’s imperative to remember that DO-178C requires reviews of software requirements, design, code and tests; DO-178C reviews should be performed independently for DAL’s B and A. But proof of DO-178C reviews needs to be retained including both DO-178C engineering review and DO-178C Quality assurance audits with DO-178C transition criteria. In aviation, activities are checklist based (just ask any pilots!) so checklists are universally applied for DO-178C reviews. For details on DO-178C checklists and a free DO-178C checklist sample, see details here: https://afuzion.com/plans-checklists/#do-178c-checklists
First, testing is based upon requirements for DO-178 (the latest version, DO-178C, goes further by stating all major code segments should trace to at least one requirement). Since DO-178 does not provide subjective thresholds for requirement granularity, testing of requirements is dependent upon the requirements themselves. However, DO-178 compensates for potentially weak requirements by requiring, for Level A through C, software to undergo additional robustness testing and structural coverage assessment. If you have good DO-178 requirements, testing those requirements should typically yield 90% coverage of the requisite robustness cases and 80% of the code for Level B. Why? Because good requirements provide good detail for low-level functionality and potential robustness conditions; such can be gleaned from the requirements thus test cases can cover 80-90% of the necessary conditions just by assessing the requirements and writing test cases for them. However, if you have weak DO-178 requirements, then writing test cases from those weak requirements may only yield 50-60% of the requisite coverage; in that case, you will discover the missing requirement detail during testing structural coverage activity (though not required Level D and E) and be required to go back and add requirements. Clearly, like most things in real-life, it’s much more cost-effective in DO-178C to do it well the first time instead of going back to improve it and do it again. So, if there is a lesson learned to be shared here: invest in good DO-178 (and DO-254) requirements up front and support them with structured reviews and checklists; this is particularly important for DO-178 FAA certification and ED-12 EASA certification.
It’s imperative to note that DO-178’s five criticality levels call for significantly more software testing as the criticality level increases. For the software development, criticality level has less impact but not so for testing as the following figure summarizes the testing required per DAL.
Major Testing Differences Between DO-178 Criticality Levels:
For the remaining 14 pages of this AFuzion DO-178 Introduction Technical Whitepaper, please download below.
Information Request Form
Please provide the following information to receive your full WhitePaper