MC/DC Coverage Explained: What It Is, Why You Need It, and How TESSY Achieves 100%

If you are working on an ISO 26262 ASIL D automotive project or a DO-178C DAL A avionics project, your safety plan almost certainly requires MC/DC coverage for unit testing. It is the most rigorous structural coverage metric in common use, and the one safety assessors examine most carefully during certification reviews.

This guide explains MC/DC from first principles, what it measures, why safety standards require it, and how Razorcat TESSY helps engineering teams achieve 100% MC/DC on real embedded codebases.

The Coverage Hierarchy

Structural coverage metrics form a hierarchy, from weakest to strongest. MC/DC sits at the top of the set that is practical to require on production code.

What MC/DC Actually Measures

Consider this compound condition from a motor controller:

if (motor_temp > TEMP_LIMIT && speed > 0 && enable_flag == true)
{
    activate_thermal_protection();
}

This decision has three atomic conditions:

• A: motor_temp > TEMP_LIMIT
• B: speed > 0
• C: enable_flag == true

MC/DC requires demonstrating that each condition independently affects the decision outcome. For condition A, you need two test cases where:

• B and C are held constant (both true)
• A changes from false to true
• The decision outcome changes accordingly

Similarly for conditions B and C. The minimum number of test cases for MC/DC on N conditions is N+1 (for this example, 4 test cases).

Written out in full, this is the MC/DC test set for the decision above:

Four test cases, N+1 for N=3, and each of the three conditions has an independence pair that differs in that condition alone. Note that the set also survives C’s short-circuit semantics: in T4 both A and B are true, so enable_flag is genuinely evaluated, and in T1 it is evaluated as well. A test set that flipped C only in a case where B was already false would never execute C at all and would prove nothing about it.

The key word is independently. Branch coverage only requires that the overall decision evaluates to true in one test and false in another. MC/DC requires proving that each individual condition matters. This catches defects where a condition is present in the code but never actually influences the outcome, often a sign of a logic error or dead condition.

Why Safety Standards Require MC/DC

Safety standards require MC/DC because it provides the strongest practical evidence that the control flow logic is correct. Specifically:

ISO 26262 Part 6 gives MC/DC its strongest recommendation at ASIL D unit testing. The rationale: ASIL D functions have the highest criticality, and any defect in their control flow logic could lead to a hazardous event. MC/DC ensures that every condition in every decision has been proven relevant. It is a recommendation and not a mandate, because the standard has no “mandatory” rating and the unit-level coverage metrics are alternative entries, so an ASIL D project applies an appropriate combination and gives a rationale for the combination it selected.

DO-178C requires MC/DC for DAL A structural coverage. Aviation safety has mandated MC/DC for the highest criticality level since DO-178B (1992), which makes it the longest-standing MC/DC mandate of the three standards listed here.

IEC 61508 Part 3 recommends MC/DC for SIL 3 and SIL 4 software. Industrial safety controllers, emergency shutdown systems, and railway interlocking all benefit from MC/DC-level testing.

The Challenge: Achieving 100% MC/DC

Statement coverage and branch coverage are relatively straightforward to achieve, a moderate set of test cases typically reaches high coverage. MC/DC is harder because:

Complex boolean expressions require more test cases. A decision with 5 atomic conditions (common in fault detection logic) needs a minimum of 6 MC/DC test cases, but identifying the right combinations requires careful analysis.

Short-circuit evaluation complicates MC/DC. In C, && and || use short-circuit evaluation, if the first operand of && is false, the second is not evaluated. This means some condition combinations are unreachable, and the MC/DC analysis must account for this.

Compiler optimization can change condition evaluation. At higher optimization levels, the compiler may restructure boolean expressions, merge conditions, or eliminate redundant checks. MC/DC measured on the source must map to the compiled code’s actual behaviour.

Coupled conditions arise when two conditions share a variable (e.g., x > 0 && x < 100). Changing one condition may unavoidably change the other, making independent demonstration difficult. Per Razorcat, TESSY provides Multiple Condition Coverage (MCC), which requires every combination of condition outcomes in a decision to be invoked, giving exhaustive combination coverage evidence for these cases.

How TESSY Achieves 100% MC/DC

TESSY provides a systematic workflow for reaching full MC/DC coverage:

Step 1: Classification Tree Design

The Classification Tree Editor (CTE) helps engineers decompose the input space into equivalence classes and boundary values. For each atomic condition in a decision, the CTE defines the true/false input ranges, boundary values, and error conditions. This systematic approach ensures that MC/DC-relevant test vectors are generated as part of the test design, not discovered ad hoc during coverage gap analysis.

Step 2: Automated Coverage Measurement

TESSY instruments the code at the condition level, tracking which atomic conditions have been evaluated to true and false, and which have been shown to independently affect the decision outcome. Coverage results display as colour-coded source annotations, green for covered conditions, red for uncovered.

Step 3: Hyper Coverage from Hardware Trace

Per Razorcat, TESSY’s Hyper Coverage feature (in TESSY 5.x) integrates the Accemic Technologies hardware trace port analysis tool: FPGA-based online trace data processing acquires branch and MC/DC coverage data directly during system and integration testing. Imported into TESSY, that coverage appears at source file level in the Test Cockpit, closing gaps a unit test bench alone cannot reach, the paths that only execute once the target runs as a system.

Step 4: Iterative Test Addition

Engineers add targeted test cases to close MC/DC gaps. TESSY’s tabular test data editor makes it efficient to add test cases for specific condition combinations without disrupting existing test suites.

Practical Tips for Indian Teams

For teams in Pune and Bengaluru working on ASIL D AURIX-based ECUs, or teams in Hyderabad targeting IEC 61508 for industrial controllers:

• Start with systematic test design (CTE) rather than ad hoc testing followed by coverage gap filling. Systematic design reaches higher initial MC/DC coverage and produces better audit evidence.
• Test with the production compiler. MC/DC measured under GCC on x86 does not prove coverage on TASKING-compiled TriCore code. Use TESSY with your project’s cross-compiler.
• Track MC/DC trends in CI. Set coverage gates in your Jenkins/GitLab pipeline so regressions are caught immediately, do not let MC/DC coverage slip during development.

Why Buy from GSAS

GSAS Micro Systems is the authorized Razorcat partner, providing TESSY licensing and MC/DC coverage consulting for ISO 26262, IEC 61508, and DO-178C projects. Our functional safety engineers in Bengaluru, Hyderabad, Chennai, Pune, Mumbai, and Delhi NCR train teams on the Classification Tree Method, configure TESSY for their target toolchain, and help achieve 100% MC/DC coverage on safety-critical modules.

Request a TESSY MC/DC workshop →