DO-178 Introduction Whitepaper
Avionics certification explained
FOR ENGINEERS AND MANAGERS
Read Excerpt Below, or Click Here To Download Full 10-20 Page Paper
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:
Plans:
- 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.
Standards:
- 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.
First Focus: DO-178 Tests Based Upon Requirements (E.g. Functional Testing)
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.
Free: Download Remaining 10+ Page Paper Here