• Subscribe
  • Magazine
  • Videos
  • White Papers
  • Webinars
  • Buyer's Guide
  • EDGE Awards
  • Innovators Awards
    1. Commercial Aerospace

    DO-178C nears finish line: credit ahead for modern tools and technologies

    Sept. 1, 2010
    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, according to one member of 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.
    Pennwell web 120 96
    Pennwell web 120 96
    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, according to one member of 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 the 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 Adminsitration'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. (For more on the changes see "DO-178C core changes.")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. DO-178B's purpose is to assure that software developed for avionics systems is reliable and safe to use in flight. But the avionics software development landscape has changed markedly since 1992, when the B version was originally released. One of the most obvious changes is that software programs have become far larger and more complex. The Airbus A320, 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, according to 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. Although companies who find that they have been misinterpreting the language of the core standard after clarifications have been made 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 are labor-saving and widely used in other industries, tools, methods, and languages that were not generally available when DO-178B was released are not accorded formal credit under it. It is ok to use them, but significant manual verification is still required 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, which model systems in very high-level, domain-specific languages, are often used to automatically generate source code directly from the model. Both the model and the generated code currently have to be verified via DO-178B, Hilderman says. There are currently no qualified, automated tools to test the model although that testing is relatively straightforward since the model exists at a higher level of abstraction. But 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, such as formal methods tools and model 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, since 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 has to do in order to qualify his tools, says Cyrille Comar, Adacore's managing director in Paris, France. 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 criteria for higher-criticality-level tools. 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 and that the model-based design, the object-oriented code and the formal methods proofs have been "traced within a closed-loop," he adds. 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 that are 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. Over time, this technique has been proved to be effective in verifying the math-to-software translation as is the top-down (integrated) testing currently required by DO-178B, he adds. The hope is that, because formal methods allow you to verify that code components are good, the integrated testing phase will be less manually intensive, Hilderman says. Others assert that formal methods can be used instead of top-down, or integrated testing. Formal methods allow you to look at the parts as well as the whole of the code, and its true intent, thus enabling the software verification process to begin earlier, reducing development risk, among other things, Hilderman says. Because formal methods will have verified the software components as they are developed, the components won’t need to be completely re-verified during integration testing. One of the issues with integrated testing is that it typically cannot start until the software program has been almost completed. Under DO-178C, however, developers will be allowed to use testing results from earlier in the process as formal results. But formal methods tools are most helpful with really 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.

    Voice your opinion!

    To join the conversation, and become an exclusive member of Military Aerospace, create an account today!

    Continue Reading

    Sponsored Recommendations

    New

    Most Read

    Sponsored

    View All Companies >