First published in 1992, DO-178B/ED-12B is now being updated to DO-178C/ED-12C. This update is being carried out by a joint RTCA special committee and EUROCAE working group called SC-205/WG-71. This committee comprises roughly 150 active participants representing avionic software suppliers and certification authorities. This committee was formed in 2005 and aims to publish DO-178C/ED-12C in 2010.
The means by which text changes are approved for incorporation into DO-178C/ED-12C is as follows. An Issue Paper is developed presenting the proposed text change and the rationale for the change. The Issue Paper is then voted on in plenary (a meeting of all the committee members present). If the Issue Paper achieves consensus, it is accepted into the approved DO-178C/ED-12C text. If it is rejected, the Issue Paper is either reworked or abandoned. Consensus is currently defined as 97% approval.
One such Issue Paper was IP217, which was written by 12 people called (appropriately enough) the IP217 Tiger Team. IP217 addressed a number of related issues:
- What is a high-level requirement?
- What is a low-level requirement?
- What is the relationship between the software architecture and the low-level requirements?
- When, if ever, is it permissible to merge the high-level and low-level requirements?
- Can there be intermediate levels of requirements?
- What is a derived requirement?
- Which requirements need to be provided to the system safety assessment process?
- What is the intent of Modified Condition/Decision Coverage (MC/DC)?
- What is the exact definition of MC/DC when applied to source code?
- What is the relationship between MC/DC coverage of source code and MC/DC coverage of object code?
- How is MC/DC affected by the use of model-based approaches?
Members of the committee that originally wrote DO-178B/ED-12B explained that the original concept of multiple levels of requirements and design had been simplified in the final text because it was felt, back in 1992, that the airborne software engineering community was not mature enough to handle more than two levels of requirements. In hindsight, some of those members believed the simplification had been a mistake, and had caused more confusion than it had avoided.
IP217 defined a generalized, rigorous model of requirements and design that could be applied to all levels of system and software design.
IP217 was finally rejected at the Phoenix plenary in November 2008. Many committee members were of the opinion there was insufficient time remaining to develop the concepts to sufficient maturity to incorporate in the text of DO-178C/ED-12C, but encouraged further development of the IP217 concepts. This project aims to develop those concepts as part of the Open-DO initiative.