Avionics software designers are gearing up for the release of the update to the DO-178B software certification standard-DO-178C, which accommodates modern technologies, such as formal methods and object-oriented programming.
BY Charlotte Adams
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.
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.
|The F-35 Joint Strike Fighter's avionics code is certified to DO-178B.|
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 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.
|The DO-178C tools supplement becomes especially important as third-party tools facilitate two of the three technology supplements.|
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.
|Complex avionics software in future Boeing 787 cockpits will be certified under the upcoming DO-178C standard.|
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 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.
|Avionics software certification is critical for next-generation business jet cockpits such as the Bombardier Q400.|
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.
DO-178C core changes
The accommodation of modern software tools and technologies receives the most attention in press accounts of the upgrade to DO-178C, yet revisions to the body of the standard also are important. Although these revisions should not make the standard more or less difficult to follow, it should make the playing field "more level," stopping the exploitation of certain ambiguities, says George Romanski, chief executive officer of Verocel, a software verification company in Westford, Mass.
One such area involves modified condition and decision coverage (MC/DC) testing. DO-178B clearly requires MC/DC testing for Level A software with a requirement for several conditions, Romanski explains. The idea is to test every condition independently that has an effect on the outcome. The issue is whether requirements with several different conditions must undergo MC/DC testing at lower levels of criticality. The revised document will spell out where MC/DC testing is necessary in cases involving multiple conditions, regardless of the software level, he says.
Vance Hilderman, co-founder and advisor at HighRely in Phoenix, takes a different view. "MC/DC is definitely only required for Level A," he says. Nevertheless, for cases where low-level software requirements call out specific conditions and corresponding outputs, complete testing of such requirements "essentially emulates full MC/DC testing." He foresees "at least a subset of MC/DC testing at lower criticality levels."
Another issue involves traceability between software artifacts, Romanski says. The revised standard requires traceability not only from requirement to design to code to test, but in the reverse direction, from test to code to design to requirements. This revision seeks to eliminate practices such as embedding traceability information in the operational or test code, which makes the links hard to follow and traceability more difficult to verify.
DO-178B certification challenges for real-time Java applications
BY John McHale
Real-time operating system (RTOS) designers have succeeded at certifying respective operating systems to the Federal Aviation Administration's DO-178B safety certification standard, but certifying real-time Java to DO-178B still has challenges.
"DO-178B has not offered a straightforward path for certifying Java or any other object-oriented code," says Nat Hillary, field applications engineer at LDRA Software Technology in San Bruno, Calif. DO-178C offers guidance for certifying object-oriented code to the DO-178C standard. The maturity of Java for embedded devices and the soon-to-be-released standard offered good timing for LDRA to announce a Java version of its tool suite.
"Boeing and Airbus have both publicly stated that certification costs are becoming exorbitantly high," Hillary says. "The only way for the industry to reduce this increasingly excessive cost factor is by better management of the software development process. Java offers many time-savings features as well as having additional rigor as a language, which ensures that programmers do not make some of the errors that are quite easily made in C. Better quality code leads to fewer errors and less debug time.
"There are two fundamental challenges to certifying Java," Hillary continues. "The first is the fact that it is dependent on a run-time environment, so it is not possible to certify the program itself; the program needs to be certified in concert with the Java run time." The second challenge involves verifying and documenting the actual source code of the program.
"The biggest challenge is that standard Java, as a modern programming language, supports very high levels of abstraction," says Kelvin Nilson, chief technology officer for Java technology at Atego in San Diego. "While this abstraction makes it easy for developers to create and maintain data processing software, the abstraction complicates safety certification because each line of Java code can represent a large amount of functionality, all of which needs to be carefully scrutinized in the certification effort.
"The JSR-302 expert group is defining a simpler subset of Java that enables more economical certification of safety-critical Java applications," Nilson continues. "Intended to decrease impact on mainstream Java developers, the key changes from traditional Java are no automatic garbage collection because all temporary objects will be allocated on a run-time stack instead of from a garbage collected heap; significant pruning of the standard Java libraries available to developers of safety-critical Java applications; no dynamic class loading; and precise semantic requirements on task scheduling and task synchronization."
As with C, C++, and Ada, any Java implementations used in avionics systems has to go through the same level of testing rigor, including the use of coverage analysis to assess overall test effectiveness, Hillary says. "This is complicated by the object-oriented data types and constructs that are available within Java, so it is imperative that any verification and/or coverage analysis process and/or solution have full awareness of the language and object-oriented concepts."
To date, there is not an official safety-critical Java standard, yet the upcoming DO-178C object-oriented guidelines will complement Java, Hillary continues.
"The safety-critical Java specification also introduces certain capabilities not supported by traditional Java, such as the ability to directly read and write I/O ports, and the ability to implement first-level interrupt handlers in Java," Nilson says. "However, the key challenges in certifying Java for DO-178B are that it is too big and too abstract, and these challenges are being effectively addressed in the emerging JSR-302 standard."