Deactivated code was mainly addressed in DO-178B/ED-12B as something to be considered during the integration process and while resolving the structural coverage analysis issues. This was not fully consistent as the “means to ensure that deactivated code cannot be enabled in the target computer” was expected as part of the design data (§11.10), while no guidance was provided in the Design Process.
An approach leading to keep some deactivated code in the final software should be considered much earlier in the project, during the planning process of course, and then in the early phases of the development processes.
As a result, a new approach is introduced in DO-178C/ED-12C, starting with an enhancement of the definition, providing examples of what is and what is not deactivated code. The definition also clearly states that the deactivated code is really intentional, as it is traceable to requirements.
An activity description (new section §5.2.4) was added in the scope of the design process. This new section highlights the need to design and implement a protection mechanism, and also to develop the deactivated code in the same way that the rest of the code.
In the section about structural coverage analysis resolution, the “two” categories of deactivated code are clarified. Particularly for deactivated code that is not intended to be executed in any configuration, the text opens the door to develop this code at a lower software level, and/or to alleviate the verification activities on this code. See §18.104.22.168