Safety-critical software for mission-critical applications to get boost with release of DO-178C

By Charlotte Adams

Software engineers who specialize in mission-critical applications are gearing up for the release of an update to DO-178Bsafety-critical software certification standard in the form of DO-178C, which accommodates modern software engineering technologies such as formal methods and object-oriented programming.

After five years, RTCA and EUROCAE -- the U.S. and European avionics standards organizations -- are nearing the finish line in updating DO-178B, the bible for developers of safety-critical software. A cast of 1,000-plus people have observed or participated in the process and about 100 people show up at every meeting, says one member of the RTCA Special Committee 205 (SC-205). The industry expects the final package -- DO-178C -- to be released in the first quarter of 2011 and be mandated six to nine months after ratification.

For more on safety-critical software, see Framers of DO-178C safety-critical software standard seek to plug loopholes in compliance testing, and Certifying Java software to DO-178B safety-critical standards poses serious challenges.

Although participants in the standards process say that DO-178C will be merely an upgrade to DO-178B -- its 18-year-old predecessor -- this is perhaps too modest a claim. People are said to be rushing their project plans to fit under the DO-178B umbrella, out of reluctance to be the Federal Aviation Administration’s (FAA's) guinea pig while the agency is finding its way with the new standard.

The new standard will allow credit for modern technologies such as formal methods, object-oriented programming (OOP) languages, and model-based development, actions long sought by developers and vendors. Credit means that when a certain technology is used, some other certification requirements are reduced.

The new features will be introduced largely in supplements to the core document. DO-178C also contains a software tools supplement, which may end up as a separate DO document. Finally, there are changes to the main body of DO-178B, designed to eliminate some of its ambiguities.

Although DO-178B's purpose is to assure that software developed for avionics systems is reliable and safe to use in flight the avionics software development landscape has changed markedly since 1992, when the B version was originally released. One of the most obvious changes involves software programs that have become far larger and more complex during that time. The Airbus A320 jetliner, for example, a major product of the DO-178B era, contains a total of 800,000 lines of code in all of its avionics systems, points out Nat Hillary, field applications engineer with LDRA Software Technology, a software tool supplier in San Bruno Calif. By contrast the Boeing 777, a newer aircraft, features around 4 million lines of code.

Avionics is defined to include all onboard electronics, including non-flight-critical cabin systems. DO-178C has been crafted specifically to handle the "sheer escalation in the amount of software" required by modern aircraft avionics, Hillary says.

Experts in some companies find they have been misinterpreting the language of the core standard after clarifications have been made. As a result, they may have to change the way they write code and revise existing programs. Those in compliance will not have to recertify software simply because there is a new version of the standard. "There will be a grandfather clause, so that everything that's been previously certified will be allowed to continue flying, as long as it hasn't been changed," says Vance Hilderman, co-founder and advisor at HighRely, a software services and certification tool supplier in Phoenix. Nevertheless the content of the DO-178 documents is so complex that ongoing debates will probably continue after ratification.

Modern times

Software tools, languages, and techniques have evolved during the last 18 years. Although some of them save labor and are widely used in other industries, those that were not generally available when DO-178B was released do not receive formal credit. It is all right to use them, but significant manual verification is still necessary under the current standard. These technologies, addressed in supplements to the new standard, include formal methods, object-oriented programming, and model-based development.

Model-based development tools model systems in very high-level, domain-specific languages, and often are used to generate source code automatically from the model. The model and the generated code must be verified via DO-178B, Hilderman says. There are no qualified, automated tools to test the model -- even though that testing is relatively straightforward since the model exists at a higher level of abstraction. Nevertheless, allowing credit for model-based development tools should make software development more efficient by reducing typically manually intensive, and less relevant, low-level component testing, he adds.

DO-178C also will provide "some very nice criteria" to prove that new automated verification tools have been properly qualified and can be trusted, Hilderman continues. Right now the qualification of tools for formal methods and modeling is a "very nebulous, very subjective" process, he says. There are no specific allowances for such within the current certification standards. DO-178C will make tool qualification more objective, which is the reason that so many software tool companies have participated in the revision process.

The tools supplement explains what a tool provider must do to qualify his tools, says Cyrille Comar, Adacore's managing director in Paris. What needs to be done will vary in relation to how tools will be used.

Tool qualification will change in the revised standard -- in some cases significantly, Hilderman says. DO-178C designates new categories of tool types and requires more stringent qualification.

DO-178C will provide a more formal, more prescriptive approach for qualifying formal methods and model-based tools and for verifying the capabilities of object-oriented languages, Hillary notes. This will allow a more consistent approach to developing and certifying safety-critical software.

Although requirements traceability tools are already commonplace, these tools have steadily improved and are now at least partially automated, so that they will play well with the new technologies, Hilderman says. Traceability tools from various vendors allow developers to show that all the requirements have been implemented.

DO-178C also comes to terms with OOP languages like C++ and Ada. These are popular because they are at a higher level of abstraction than other languages and therefore promote re-use and promise more efficient development. DO-178C allows a restricted model of object-oriented design, says Robert Dewar, chief executive officer and president of Adacore in New York. There are also good theoretical models for how to structure object-oriented hierarchies so that they can be verified and understood, he adds.

Formal methods

Formal methods are a class of mathematically based techniques used for the specification, development, and verification of avionics software. Formal methods tools, for example, are used to represent an aircraft's mathematically expressed control laws and their translation into software code for the aircraft's computers. Formal methods can be used to "prove that software is an accurate representation of the mathematical expressions," Hillary says.

Because formal methods enable software engineers to verify the value of software components, experts say they hope the integrated testing phase will be less manually intensive, Hilderman says.

Formal methods enable software engineers to look at the parts as well as the whole of the code, and help get the software verification process started earlier. Formal methods help verify software components as they are developed, which reduces the need for reverification during integration and testing, which typically cannot start until the software is nearly complete. Under DO-178C, developers will be able to use testing results from earlier in the process as formal results.

Formal methods tools are most helpful with large and complex software programs -- 50,000 or more lines of code containing advanced algorithms, Hilderman says. Not many people use them now and it will be some time before they become mainstream.