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 fail 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.

 
Gordon Uchenick

Posted by

Gordon Uchenick

Gordon Uchenick

Gordon Uchenick started writing software in 1968, mostly working on embedded systems in mission-critical and safety-critical applications. His experience includes some of the first systems in computer graphics, online data acquisition, computerized industrial controls, and high-speed data movement for employers as diverse as the Social Security Administration and Texas Instruments. In 1998, feeling that 30 years of programming was enough, Mr. Uchenick became a Field Application Engineer at Wind River Systems, addressing the needs of customers with simultaneous requirements for high-assurance software certifications for both airworthiness and multi-level security. In 2004, he became a Senior Mentor and Principal Engineer with Objective Interface Systems, addressing customer needs for high assurance, multi-level secure communications. While with OIS, Mr. Uchenick was a member of the USAFRL MILS team, writing several papers on the subject and presenting them at conferences worldwide. He was a Session Chair and later Track Chair at the Digital Avionics Systems Conference. He also founded the Layered Assurance Workshop, serving as Program Chair and Coordinator. The Layered Assurance Workshop investigated total system safety and security assurance properties derived from the individual non-homogeneous assurance of the components. In 2010, convinced that applications had become the low hanging fruit for safety and security system penetrations, Mr. Uchenick joined Coverity and became the company’s lead sales engineer for Aerospace and Defense with special emphasis on customers with safety and security certification requirements. Synopsys acquired Coverity in 2014. In 2017 Mr. Uchenick semi-retired, now working on software taxonomies, representing Synopsys in Washington DC area standards committee meetings, and developing approaches for product and service offerings that enable customers to attain safety and security certifications. His personal interests include riding his bicycle in charity events and playing the bassoon.


More from Security news and research