Level A software developers have been tasked with the verification of object code that is directly untraceable to source code since the introduction of RTCA/DO-178B in 1992. This type of object code consists of executable statements that “[introduce] branches or side effects that are not immediately apparent at the Source Code level” [DO-178C 6.4.4.2.b note], including such things as compiler-generated array index boundary checks.

DO-178C corrected what many saw as an oversight by including this so-called “hidden objective” in Table A-7 of Annex A. The requirement to perform the activity remained the same, but was finally made explicit in the Annex tables.

But DO-178C also opened the door for using newer techniques for identifying and verifying object code not directly traceable to source code.

History of the “Hidden Objective”

As discussed extensively during RTCA Special Committee SC-205, DO-178C Annex A Table A-7 Objective #9 is not really “new”. It is simply the revelation of one of DO-178B’s “hidden objectives”, which were called out in the body of the document but were omitted from specific mention in Annex A. As such, it should not be considered controversial, even though its addition was considered necessary due to instances of industry resistance to its substance.

DO-178C Objective A7-9 reads “Verification of additional code, that cannot be traced to Source Code, is achieved. (Ref. 6.4.4.c; Activity 6.4.4.2.b)”.

Before delving into the practical effects of the revealed “hidden objective”, it is instructive to first consider the textual basis on which it is constructed.

Background

Get in touch