Five and a half years down the road of revising the rules for writing safety-critical code — and three years past the anticipated deadline — RTCA in December approved the new core document, DO-178C, and four supplements a 700-page manifesto that many in the industry are still trying to sift through.
Updating the two-decade-old DO-178B was necessary to clear up old ambiguities and make way for new technologies such as model-based development, object-oriented programming, formal methods and advanced development tools. A lot has changed in the software world since 1992, when DO-178B was released, particularly with the advent of tools that can help verify requirements and generate code. Many of these tools have been used in the interim period, but there has been no agreed-upon method of determining what credit they can provide in a certification project.
The new package is a substantial improvement from the older guidance. It will confer benefits such as reducing the amount of manual verification required to use the new technologies. But it’s not a perfect 10, and actually probably closer to a seven, according to some industry insiders.
“It’s actually above average, so there are many more positive than negative aspects,” said Vance Hilderman, president of Atego-High-Rely, a software product and services company and DO-178B/C training consultant.
There’s a lot of self-interest involved in standards exercises, as each player tries to save his company’s ox from being gored. The government members of these committees are expected to exert a balancing influence.
But DO-178C is a different ball game. The new guidance dives into the low-level intricacies of specifying, designing and writing code instead of sticking to the high ground of systems and processes. Since FAA isn’t manned by coding experts, the agency ran the risk of delegating too much responsibility to industry “experts” who have a strong incentive to put their own interests first, implicitly if not explicitly, in this highly competitive, $3 billion market.
According to some observers, that’s what happened, at least to some degree. “I did not see FAA exercise a lot of control,” says one participant. There’s a perception among some self-described “peons” that, because of the complexities involved and the heavy participation of software tool vendors, the playing field, particularly in the area of model-based development, is a little less level than it used to be. According to another observer, that’s just part of the game.
Once the committee and its subgroups set off into the weeds, as perhaps they had to do, it was probably inevitable that the “experts” would play outsized roles. They know their turf better than the broader-based airframers, integrators, avionics manufacturers and regulators do.
The process in some ways was like letting children decide their own bedtimes and then have Twinkies for breakfast, jokes Hilderman. So now maybe it’s time to steer the kids towards a more healthy diet.
The process of writing DO-178C was like letting children decide their own bedtimes and then have Twinkies for breakfast. Now maybe it’s time to steer the kids towards a more healthy diet.
It may be a good thing that implementation of DO-178C and its supplements will not be immediate. Although the guidance has been published, it’s still months away from prime time. Indeed, FAA does not expect to issue advisory circular (AC 20-115C) and the revision of Order 8110.49 on this subject until sometime next year. Much will depend on how the certification authorities decide to interpret the material.
FAA still has to educate its employees on DO-178C. Designated engineering representatives have to bone up on the material. The agency has to develop check lists for inspectors and set adoption dates. And perhaps most importantly, FAA will have to establish a consensus with other certification authorities about practical implementation.
In response to my inquiries, agency officials said they are aware of concerns surrounding the model-based development supplement and are working to address them. They said they have “every intention of applying a level playing field to all applicants.”
So there is still time to examine unintended consequences and perhaps add a little more parity in the safety-critical software development market.
Charlotte Adams has covered embedded electronics and software standardization issues for more than a decade.