DO-178C Explained: New Avionics Testing Considerations For Avionics Software per DO178C (by Vance Hilderman)

There has been much controversy, in fact almost an uproar in the normally staid avionics engineering community, about DO-178C's alleged requirement to perform MCDC coverage analysis on Level C software. Is it true? Let's take a look at the facts.

Please note that this topic is partially addressed within the book "Avionics Certification - A Complete Guide To DO-178 & DO-254" which has sold thousands of copies. Vance Hilderman, the principal author of that book states:

"My DO-178 book chapter on this topic is limited in scope and like all books, simply cannot be 'all things to all people'. The book is meant as an overview, as it was generally written from the DO-178 Training developed during my 2004-2005 sabbatical. MCDC (rather Modified Condition Decision Coverage) is a formally required objective for DO-178C's Level A software. In an all-too-brief synopsis, MCDC structural coverage attempts to affirm that each source code statement has been verified to ensure that each condition within that statement has been verified to confirm that each condition properly, and independently, affects the outcome of that statement. More details are provided in my DO-178C Verification Whitepaper, but here is an extract:

As an example, consider the following logic:

Park_ Status = (Engines_Off && Brakes_Set ) || (Weight_On_Wheels || Parked_Discrete);

Clearly, the True/False value of Park_Status is a function of four conditions:

- Engines_Off
- Brakes_Set
- Weight_On_Wheels
- Parked_Discrete

Each of the above four conditions can independently affect the value of Park_Status. Level A requires MCDC coverage, meaning a minimum of N+1 test cases where N equals the number of conditions. Therefore, there are clearly sixteen possible test cases (2**4) for the above line of code and Level A requires execution and analysis of at least five of them (N+1, where N is the number of conditions).

Now, Level C merely requires statement coverage, meaning each statement must be executed. Therefore, one could imply that only one of the sixteen possible test cases require execution for Level C. So, which is correct: does Level C require just one test case for the above line of code? Two test cases? Three test cases? Four test cases? Or five test cases? Can I simply decide for myself? The answer requires a true knowledge of the intent of DO-178.

First, DO-178C Level C requires both high- and low-level requirements, and verification of those requirements, with the intent that such low-level requirements cover normal operating conditions and algorithms. Both high- and low-level requirements must be written, uniquely identified, traced, and verified (reviewed and tested). The above logic block is clearly a normal operating condition expressed via an algorithm. Ideally then there should be low-level requirements (note the plural form) describing the above logic.

For example, the high-level requirements could state "The capability shall be provided to determine the plane's parking status based upon the status of engines, brakes, weight-on-wheels, and parking mode." A corresponding low-level requirement might be "Parking Status shall be set to Parked when the engines are off and the brakes are set." Another associated low-level requirement might be "Parking status shall be set to Parked when both the plane's Parked discrete is set to Parked and its weight-on-wheels status is positive."

If the low-level requirements were not completely elucidated like the above, or if the software verifier missed the intent of such low-level requirements, then test cases could potentially be missing on a Level C project. In that case, any combination of the four conditions which yielded a Park_Status of True would satisfy the DO-178C Level C structural coverage objective. And such could be rationalized under the seemingly innocent claim that "this isn't a life-critical Level A or B system, since it's designated Level C". And there's the paradox: by fully verifying properly elucidated Level C requirements, many or all of the MCDC test cases normally reserved for Level A would be executed via Level C. And that is a good thing. But it is simply not required. Remember: DO-178C has five distinct criticality levels, even though everyone recognizes that systems, and the aircraft, would be safer if we simply developed all logic to Level A standards. The five different criticality levels are provided simply because "not all systems are created equal" in terms of contribution to flight safety.

Level C systems or components are not as critical to flight safety as their Level A or B counterparts. Should your requirements standard and verification plan require such stringent verification for Level C? "I personally believe so", states Vance Hilderman. Does DO-178C mandate such? "Not specifically, however 'good practices' imply such", explains Vance Hilderman.

This is but one of many "gray areas" which DO-178C helped to illuminate but still left open for interpretation within individual projects. There are many criteria by which projects adhere to DO-178C criteria, and the certification authorities or oversight entities have the responsibility to clarify on a case-by-case basis for each project. For more details, request a copy of the DO-178C Verification whitepaper.