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:
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).
DO-178C Basics
DO-178C inherits the DO-178B core document, principles and processes, while adding support for high-level modeling, object oriented programming, and formal methods, with an emphasis on two-way traceability from model to executable code and back. DO-178C also provides a tools supplement for addressing the qualification and capabilities of the tools used for modeling, object-oriented programming, and formal methods.
As software becomes more complex, it becomes hard to manage the design of that software at the code level.Objected oriented programming (C++, Ada, Java) and modeling (UML, mathematical, etc.) simplify the development of complex software by enabling designers to conceptualize, architect and encapsulate their design at a higher level. Formal methods, which are related to model-based development, make it easier to assess correctness of complex software functions like control loops.
Like DO-178B, DO-178C specifies a multi-tiered development hierarchy. Tier 1 includes the high-level requirements provide by the airframe manufacturer, or what the system needs to do (keep the aircraft straight and level). At Tier 2, these requirements are boiled down by prime contractors into models, formal methods, and software specs, the artifacts that form the basis of the actual implementation. Tier 3 specifies the code creation process, the generation of source and executable code, either by hand or via automated modeling tools. Tiers 4 and five address verification, tier 4 for software developed on the host, and tier 5 for verification of the executable code that runs on the target system. Most testing is done at the target tier level.
Enhanced VerificationTechnology
The incorporation of advanced modeling and object oriented programming techniques places new demands on verification. The system must be verifiable and traceable at the model level, and verification evidence at the model level must be available to the broader verification and traceability framework.
In DO-178B, traceability is one-way and top-down, from the requirements to the target code, and provides no support for high-level modeling or object oriented programming. DO-178C introduces a distributed and collaborative two-way traceability mechanism that enables designers to trace from their models and requirements down to each line of code, and back from the code to the requirements and model, including all interceding work products and test cases.
DO-178C defines traceability requirements for all of the safety integrity levels, from Level D to Level A. At Level D, where no coverage analysis is required, designers need onlybe able to trace to the high-level requirements. At levels A, B, and C, where coverage analysis is introduced, designers must be able to trace all the way from the high- and low-level requirements to source code and back to low- and high-level requirements. Level A adds another level of traceability, also found in DO-178B, which requires traceability from the source code to the executable object code.
Traceability also requires that the executable code be intact relative to the source code. Many compilers, for example, add branch points in the executable code that are not present in the original source code. These branch points must be identified and tested. Conversely, some optimizations can remove constructs, data in particular, especially static data.
Automated Tools for DO-178C Development
High-level tools from companies are already available to automate the DO-178C verification process, including two-way traceability. LDRA'stoolset, for example,automates the mapping of requirements in whatever form they're captured, be it a formal requirements traceability solution, a formal requirements capture solution, or informal documentation (such as Word documents, PDFs, text files, etc.). The tools also provide a core framework for establishing traceability forwards and backwards, from requirements down through the decomposition tree, onto the executable code and back again. Requirements can also be traced to the actual verification tasks that are used to ensure that code meets the minimum standard for the desired certification level.
Automated analysis tools are also available to speed the verification process. Dynamic analysis tools, for example, provide coverage analysis at the statement, decision and MC/DC level. From the code creation perspective, static analysis tools allow you to do code standards enforcement and identify latent defects in your code. These defects (such as variables that are declared but not initialized before use, and array out of bounds)may not come up during testing, but hurt you when the system is in service. Static analysis also provides visibility into the complexity of the code, identifying areas of unnecessary complexity that complicate testing and verification. All of the results from static and dynamic analysis can be brought back into the requirements traceability matrix.
Full Turn DO-178C Certification Services
Automated tools greatly reduce the time and cost associated with developing DO- 178-compliant software. DO-178 certification, however, is still an expensive, time consuming and arduous process. To help expedite this process for avionics equipment makers, companies like DDC-I offer safety-critical RTOS platforms that have already undergone the most rigorous DO-178B Level A certification processes and been deployed in real-world commercial and military avionics systems. They also offer turnkey development and certification services for both DO-178B and DO-178C. \\[\\[Editor's note, companies such as Lynuxworks and Green Hills Software also offer DO-178 platforms and services.\\]\\]
DO-178C is welcome news for developers of complex avionics software that must by certified to the highest levels of safety criticality. DO-178C simplifies the development process by embracing high-level modeling and object oriented techniques that enable designers to conceptualize and encapsulate their software at a higher level. It also streamlinesthe verification and certification process by providing two-way traceability that extends from the models and requirements to the executable code and back again. These enhancements, together with automated development and certification tools, DO- 178B/C-certifiable real-time operating system platforms, and turnkey certification services, greatly reduce the time, cost and risk associated with developing, certifying, and deploying complex safety-critical avionics software.