Summary of Differences between DO-178B and DO-178C
For a brief summary of the changes in DO-178C. For more comprehensive information on this topic Patmos also offers a training class called “Certification of Software (DO-178C)”
Errors and Inconsistencies:
DO-178C addressed DO-178B’s known errors and inconsistencies. For example, DO-178C has addressed the errata of DO-178B and has removed inconsistencies between the different tables of DO-178B Annex A. In removing an inconsistency regarding software standards for Level D software, DO-178B objective A-9 #1 addressing plans and standards was split into two DO-178C objectives, specifically:
- Assurance is obtained that software development and integral processes comply with approved software plans. (Table A-9 #2)
- Assurance is obtained that software development and integral processes comply with approved software standards. (Table A-9 #3)
Consistent Terminology:
DO-178C addressed DO-178B’s issues with the use of specific terms such as “guidance”, “guidelines”, “purpose”, “goal”, “objective” and “activity” by expanding the Glossary and changing the text accordingly so that the use of those specific terms was consistent throughout the document.
Wording Improvements:
DO-178C made wording improvements throughout the document. All such changes were made simply to make the document more precise; they were not meant to change the original intent of DO-178B.
Objectives and Activities:
DO-178C reinforced the point that, in order to fully understand the recommendations, the full body of this document should be considered. For example, Annex A now includes references to each activity as well as to each objective; and Section 1.4, titled “How to Use This Document” reinforces the point that activities are a major part of the overall guidance.
Technology Supplements:
DO-178C recognized that new software development methodologies may result in new issues. Rather than expanding text to account for all the current software development methodologies (and being revised yet again to account for future software development methodologies), DO-178C acknowledged that one or more technology supplements may be used in conjunction with DO-178C to modify the guidance for specific technologies or methodologies. Section 12’s addressing of tool qualification and alternative methods was heavily impacted since planned technology supplements more completely address such technologies. They include Model-Based Development, OOT, Formal Methods and Tools.
Coordinated System/Software Aspects:
DO-178B updated Section 2, which provides system aspects relating to software development, to reflect current system practices. The updates were based upon coordination with other organizations which were updating their system-level guidance at the same time SC-205/WG-71 was updating DO-178B’s software-level guidance.
DO-178B “Hidden” Objectives:
DO-178C added the so-called “hidden objectives” to Annex A:
- A means for detecting object code that is not directly traceable to the source code and a means to ensure its verification coverage are defined. (Table A-1 #4)
- Assurance is obtained that software plans and standards are developed and reviewed for consistency. (Table A-9 #1)
DO-178B Topic Omissions:
DO-178C addressed a few general topics that resulted in changes to several sections of the document. The topics included a variety of subjects such as oversight of suppliers, Parameter Data Items and traceability. In addressing these topics, two additional objectives were added to Annex A:
- Parameter Data Item file to be loaded complies with Low-Level Requirements. (Table A-6 #6)
- Verification coverage of Parameter Data Item Elements. (Table A-7 #9)
- Added Trace Data as required Lifecycle Data to be provided and verified (Section 11.21)
DO-178B Gaps and Clarifications:
DO-178C addressed several specific issues that resulted in change to only one or two paragraphs. Each such change may have an impact upon the applicant as these changes either addressed clear gaps in DO-178B or clarified guidance that was subject to differing interpretations.
Examples of gaps addressed include:
- The “Modified Condition/Decision Coverage” definition changed. Masking MC/DC and Short Circuit, as well as DO-178B’s Unique-Cause MC/DC, are now allowed. (Glossary)
For Level A, added that “if a compiler, linker or other means generates additional code that is not directly traceable to Source Code statements, then additional verification should be performed to establish the correctness of such generated code sequences.” (6.4.4.2.b) - Derived requirements should now be provided to the system processes, including the system safety assessment process (rather than just provided to the system safety assessment process) (5.1.1.b; 5.2.1.b)
Examples of clarifications include:
- Clarified that the structural coverage analysis of data and control coupling between code components should be achieved by assessing the requirements-based tests. (6.4.4.2.c)
- Clarified that all tests added to achieve structural coverage are based on requirements. (6.4.4.2.d)
Clarified the types of code that may be classified as Deactivated Code. (6.4.4.3.d)