As noted in the Avionics June 2008 Editor’s Note regarding RTCA Special Committee 205, which is working to update DO-178B, “The best-laid plans and remedies may not work as hoped or expected.” One could argue that this is a gross understatement.
For many of us who have been involved with this effort from the start, SC-205 has proven to be both ineffective and, in this author’s opinion, in danger of releasing products that will do more harm than good for our industry.
A brief bit of history highlights the enormous challenges faced by today’s safety-critical software developers who have to comply with DO-178B, which was published in 1992. DO-178B was intended to be technology independent and to reflect the best software engineering practices as they were understood at the time. Its release coincided with the emergence of RISC-based processor architectures and the very early forays of our industry into Integrated Modular Avionics (IMA). The use of Ada programming language was still widespread, not yet having been supplanted by C or C++. Structured development and the waterfall model were everywhere.
Fast-forward to 2008. Ada is largely a distant memory, highly integrated avionics systems are the norm, and complex tool-based, model-driven development is standard. Complicating this picture even further is that today’s airspace is a complex system of systems where there is no compelling reason to evaluate and assure ground, space and onboard software using different rules. In fact, doing so could lead to safety issues since our modern airspace is only as safe as its weakest link.
Those of us on the original ad-hoc committee that drafted the terms of reference for SC-205 naively thought that all of this could be addressed through a “minimal change” update to the core DO-178B and the creation of a small number of technology-specific supplements. The ground and space-based aspect would be addressed by updates to DO-278, a sister document to DO-178B released in 2002. The last three years of SC-205 deliberations have attempted to implement this approach. With regards to the DO-278 issue, the Plenary repeatedly voted in favor of merging DO-178B and DO-278 into a single set of software assurance guidelines, something that the committee who wrote DO-278 had proposed as the next logical step.
This last topic deserves special attention. Although other RTCA committees have taken an airspace-wide, holistic view (e.g., SC-189’s DO-264), the current SC-205 leadership, backed by the RTCA Program Management Committee (PMC), has not. The RTCA PMC, at the urging of the SC-205 chair, voted to overrule the will of the SC-205 Plenary and to require two separate documents. Their position, as expressed by the FAA PMC voting members, was that divergence in software assurance objectives between ground, airborne and space-based systems is not only OK, it should be expected because ground and space-based suppliers are not as mature and thus not necessarily able to meet the more stringent airborne objectives.
As a member of the flying public, I find this position to be highly disturbing for two reasons. First, less mature suppliers should imply more stringent rules, not less, to preserve safety. Second, what will prevent an airborne equipment supplier demanding that DO-278 be allowed for their system as it provides the same function within the airspace, just from a different origination point? I contend that the RTCA PMC’s action was made for both political and economic reasons that, in this case, are clearly not aligned with safety.
While the Editor’s Note suggested SC-205 remains on a successful path, albeit slightly delayed, there are many of us who feel that this committee is fundamentally broken and that the overall products may not be usable, will likely increase the cost of compliance, and may, in fact, negatively impact safety.
SC-205 needs both new leadership and a new direction to address the challenges before it and our industry. SC-205 must take into consideration, to a degree not yet accomplished to date, the significant changes that have occurred in avionics development and software engineering since DO-178B was released.
With DO-178B open for revision for the first time in 15 years, we cannot afford to miss this opportunity to get it right.
Tom Ferrell is the president and co-founder of FAA Consulting Inc., based in Keswick, Va. He has been a part of committee efforts associated with DO-178B and DO-278, including SC-205. He is a FAA Software Designated Engineering Representative. Views expressed are those of the author and do not represent Avionics Magazine.