This is one of those things you really need to understand from the get-go. DO-254 and DO-178C are Top-Down processes. This means you start the project with compliance in mind and work it from the very start of the program through to the end. Why is this so important to understand?

One of the things I see and hear frequently from development teams is “we can finish that certification stuff later.”  Many people believe that you can just add the compliance data items to the project after you get the design working. This bottom-up approach to Certification compliance under DO-254 and DO-178 is in direct opposition to why these design assurance documents were drafted.

Before I explain this further, let me be clear: while there is room for a rapid prototyping flow within the constraints of these design assurance documents, this sort of flow is only used as a way to validate and confirm that you have the right set of requirements.

A bottom-up compliance effort does not equal top-down process assurance, and you should not employ it unless you have relatively simple functionality.  Design assurance processes described by DO-254 and DO-178C are both in place to acknowledge the complexity of avionics systems and the inherent knowledge that if you wait to perform verification and validation on the final image you will be faced with the inability to show you adequately identified potential errors in the design.  Today’s complex software and hardware systems are extremely challenging to design, and the chances of having bugs in the design are very high. Following the top-down processes makes you focus on ensuring you are always looking for potential errors/problems, and by doing so, the assurance the design will operate as expected increases. That’s the point.

This concept is discussed as the Complexity Barrier [Beizer90] principle: Software complexity (and therefore that of bugs) grows to the limits of our ability to manage that complexity. This is why the DO-254 design assurance standard was written primarily for “complex” hardware and there is an acknowledgment that for “simple” systems the majority of DO-254 does not apply.  DO-178C section 12.3.2 allows for “exhaustive input testing” of your software if it is truly simple as an alternate means of compliance.   Top-Down design assurance defined in DO-254 and DO-178C hinges on the concepts of supporting/integral processes (which are monitoring the processes and data items) and transition criteria (which ensures proper flow and completion of key criteria) throughout the development. It also include levels of independence and process assurance that help to identify design errors earlier and throughout development.

In other words, the whole purpose of “design assurance,” be it in software or hardware, is to demonstrate that during the process, you have taken all pertinent steps to ensure you are catching and/or eliminating design errors at every step of the design (i.e., development) process.

Ensure as you engage in your first DO-254 or DO-178C program, that you understand the basics of the design assurance philosophy in addition to the contents of the standard and how to apply it to your program. Taking training from a qualified instructor is a good first step. We offer on-demand training: click here. We also offer customized/live training from our consulting website www.patmos-eng.com.