Since its introduction in 1992, DO-178B has become the defacto standard for certifying all new aviation software. Subsequently, however, avionics software complexity has increased dramatically, software development technology has improved by leaps and bounds, and DO-178B has lagged behind.
DO-178C will bring safety-critical software development into the modern era, adding support for advanced techniques such as UML and mathematical modeling, object-oriented programming, and formal methods. DO-178C will also introduce backwards and forwards traceability, which will make it easier for designers to verify that software developed using these advanced techniques achieves the desired level of safety criticality.
DO-178B Basics
The main intent behind DO-178B is to ensure that the software does what it's supposed to do, doesn't do anything else, and provides an appropriate level of confidence that it won't do anything unsafe. DO-178B envisions a traditional waterfall lifecycle development process with five fundamental processes: planning development, verification, configuration management and quality assurance. It also defines five levels of design assurance (Level A to Level E), with Level A being the most stringent.
Software that can result in a catastrophic design failure and loss of life must meet Level A, where theprobability of failure cannot exceed more than one in 109/operating hour. An example would be the software that controls an airplane's tail rudder, where failure in this software could cause the aircraft to flip upside down. At the other end of the design assurance spectrum is Level E, which applies to software that can't impact safe operation of the aircraft, such as collecting maintenance data.
DO-178B defines 66 objectives (i.e., documentation and testing for every requirement)to meet those assurance levels. Of the 66 objectives, 24 must be met with independence, meaning that the same person who wrote the code cannotreview it; a different set of eyes is more likely to catch errors. There are no objectives required for Level E, as this software does not impact safety criticality.
Verification Methodology
Verification is used to detect and report errors that have been introduced during the software development process and ensure that software performs its intended function to appropriate degree of confidence.
Verification ensures that:
All system requirements have been developed into software requirements that satisfy those system requirements
Software requirements have been developed into a software architecture that satisfies those requirements
The source code satisfies the software requirements and the architecture
Executable code derived from the source code satisfies the software requirements.
Verification consists of three activities: review, testing and analysis. Review is a qualitative assessmentof compliance with requirements, architecture and verifiability to ensure accuracy, correctness, consistency and completeness.
Testing demonstrates that the software meets requirements, and to a given degree of confidence, that errors that could lead to unacceptable failure conditions (i.e., incorrect software, incorrect requirements, incorrect test case) have been removed. Hardware/software integration tests verify correct operation in the target environment. Software integration testsverify software interfaces and interdependencies such as initialization, control and data coupling.
Analysis is a quantitative assessment of accuracy, correctness, consistency and completeness that utilizes test analysis, coverage analysis, and traceability analysis. The purpose of structural coverage analysis, which encompasses statement coverage, decision coverage, and modified condition decision coverage (MC/DC), is to ensure adequacy of the test set, that sufficient testing has been done for the desired assurance level.
Statement coverage, which is required for Level C and higher, ensures that every statement has been executed at least once. Decision coverage, which is required for Level B or higher, ensures that every decision has taken all outcomes at least once. MC/DC, which is required for Level A, ensures that everycondition in a decision has taken every possible outcome at least once, that every decision has taken all possible outcomes at least once, and that each condition in a decision has been shown to independently affect that decision's outcome.
Traceability analysis is used to ensure that every requirement is implemented and tested, and that every line of code has a reason to be (all code traces to at least one requirement). Common gaps in traceability include: the requirement has no associated test (missing trace info or test); the requirement has no associated source code (missing trace info, missing code, or extraneous requirement); and the source code doesn't trace to requirements (missing trace info, extraneous code).