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

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. Modified Condition/Decision Coverage is the most rigorous structural coverage metric in common use, and it is the metric that 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:

Statement coverage: every statement in the function has been executed at least once. This is the minimum, it tells you that no code is completely dead, but it says nothing about whether all branches have been tested.

Branch coverage: every branch (if/else, switch cases, loop entry/exit) has been taken at least once. Stronger than statement coverage because it ensures both the true and false outcomes of each decision have been exercised.

Decision coverage: every decision (boolean expression that controls program flow) has evaluated to both true and false. For simple conditions, this is equivalent to branch coverage. For compound conditions, it is subtly different.

MC/DC (Modified Condition/Decision Coverage): every atomic condition within a compound decision has been shown to independently affect the decision outcome. This is the key metric for ASIL D and DAL A.

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).

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 Table 9 recommends MC/DC for 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.

DO-178C Table A-7 requires MC/DC for DAL A structural coverage. Aviation safety has mandated MC/DC for the highest criticality level since DO-178B (1992), making it the most established MC/DC requirement in the industry.

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. TESSY handles coupled conditions through its MCC (Modified Condition Combination) metric, which provides exhaustive combination coverage 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 Gap Analysis

When MC/DC coverage is below 100%, TESSY’s Hyper Coverage feature (in TESSY 5.x) identifies exactly which conditions are uncovered and suggests the input combinations needed to close the gap. This reduces the manual analysis effort significantly, instead of studying truth tables by hand, engineers see the specific gaps highlighted in the source code.

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 India’s 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 →