Software Integrity Blog


Making the skies safe and secure with DO-178C compliance

Making the skies safe and secure with DO-178C compliance
A little background on DO-178

We live with software failure every day—from cell phones and laptops that crash or hang to headline-grabbing stories of personal data breaches. Software has been used in safety-critical airborne applications for decades, but fatalities caused by software are unheard of in civil aviation. Why this difference? The reason is the way airborne software is certified, following the objectives defined in DO-178.

DO-178, whose full title is Software Considerations in Airborne System and Equipment Certification, is a standard first issued in 1981 by Radio Technical Commission for Avionics (RTCA), a U.S. nonprofit public-private partnership that produces recommendations on a wide range of aviation issues, with contributions from the European Organisation for Civil Aviation Equipment (EUROCAE).

DO-178C, released in 2012, defines objectives for 10 software life cycle processes, activities that can satisfy those objectives, and descriptions of the evidence required to show that the objectives have been satisfied. Meeting different objectives requires varying levels of effort, as some are harder than others. DO-178C defines objectives for the following processes:

Process # of objectives
Software planning 7
Software development 7
Software requirements 7
Software design 13
Software coding and integration 9
Integration 5
Verification 9
Configuration management 6
Quality assurance 5
Certification liaison 3

Not all airborne software is equally critical; for example, the code in triply redundant fly-by-wire computers is much more important than the code in entertainment systems. DO-178 defines four operative software levels, A–D, that describe the rigor of inspection required for code based on the potential impact of its failure (level E is nonoperative). Each software unit is assigned a level as the result of a system safety assessment process. The levels are as follows:

Level Definition
A Software failure results in a catastrophic failure condition for the aircraft
B Software failure results in a hazardous failure condition for the aircraft
C Software failure results in a major failure condition for the aircraft
D Software failure results in a minor failure condition for the aircraft
E Software failure has no effect on operational capability or pilot workload

Where static analysis fits

DO-178C defines 22 documentation datasets that “plan, direct, explain, define, record, or provide evidence of activities.” In a perfect waterfall world, all the planning, standards, requirements, design, and test case documentation would be written before the first line of code. Other documents, such as test results and configuration data, would be artifacts of the software development life cycle itself. But no world is perfect. As much as 85% of the time, a significant portion of the required documentation is reverse engineered from the code, especially when existing nonairborne code is integrated into an airborne application. Oftentimes, this reverse engineering is done by specialists, rather than the original developers, as they create the evidence artifacts required for DO-178 certification.

As the specialists analyze the code, they often find issues that need to be addressed and then interact with the developers to change it. When this happens, parts of the software life cycle process must be repeated. These additional “round-trips” inject uncertainty, schedule risk, and sometimes significant unforeseen extra costs into the certification effort. Finding defects earlier in the software development life cycle saves money in terms of hours expended to mitigate the defect. Static analysis also reduces both budget and schedule risk.

Coverity by Synopsys has proven to be an effective mitigation against round-trip risk. When used during development, Coverity enables developers to submit code that’s as clean as possible to the artifact writers. There still might be round trips—situations where the code is doing incorrect things, as opposed to doing things incorrectly—but the number of trips will be minimized because potentially questionable or erroneous code will have already been identified and addressed by the developers.

Commodity software vs. safety-critical software

The contrast between commodity software and safety-critical software certified according to DO-178 exists because the two kinds of software have different objectives—being first to market versus operating safely under all foreseeable conditions. Software safety is a culture and mindset among all its practitioners. Organizations creating safety-critical software consciously commit to making significant investments to ensure that software is safe, because the consequences of failure could be unthinkable. DO-178 is the consensus process for certifying that airborne software is safe in the way it’s going to be used. Coverity has shown itself to be a productivity-enhancing and risk-reducing tool in many use cases; it’s proven itself to be especially valuable in attaining safety certifications.

Learn more about how Coverity can support DO-178C compliance.
Read the white paper now.