DO-178C Core changes

WESTFORD, Mass., 1 Sept. 2010. The accommodation of modern software tools and technologies receives the most attention in press accounts of the upgrade to the RTCA certification standard DO-178B -- DO-178C, however revisions to the body of the standard are also important. These revisions should not make the standard harder or easier to follow, says George Romanski, chief executive officer of Verocel, a software verification company in Westford, Mass. But it should make the playing field "more level," stopping the exploitation of certain ambiguities.

By Charlotte Adams

WESTFORD, Mass., 1 Sept. 2010. The accommodation of modern software tools and technologies receives the most attention in press accounts of the upgrade to the RTCA certification standard DO-178B --DO-178C, however revisions to the body of the standard are also important. These revisions should not make the standard harder or easier to follow, says George Romanski, chief executive officer of Verocel, a software verification company in Westford, Mass. But it should make the playing field "more level," stopping the exploitation of certain ambiguities.

One such area involves modified condition/decision coverage (MC/DC) testing. DO-178B clearly requires MC/DC testing for Level A software where you have a requirement with multiple conditions, Romanski explains. The idea is to independently test every condition that has an effect on the outcome. The issue is whether requirements with multiple conditions need to go through MC/DC at lower levels of criticality. The revised document will spell out the need for MC/DC testing where requirements have 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 is whether or not traceability between software artifacts has to be bidirectional, Romanski says. The revised standard says that there must be bidirectionality -- 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 is intended to eliminate practices such as embedding traceability information in the operational code, or test code, which makes the links hard to follow and traceability more difficult to verify. Some people, for example, would embed a comment in a function, or piece of test code, saying that this function satisfies such and such a requirement. The result of this practice is that "you have to search through all the tests to find the requirements being tested."

More in Home