You are three weeks from software freeze on an ASIL D braking controller and the verification team asks: do we need MC/DC coverage on every module, or just the safety-relevant ones? The answer determines whether you have two weeks of test work left or six. ISO 26262-6 Table 12 gives you the answer — but only if you know how to read it.

This article covers the coverage requirements precisely: what each level means technically, which ASILs require which coverage, how ASIL decomposition affects the calculation, and what an assessor actually expects to see as evidence.

ISO 26262-6 Table 12: The Coverage Requirements Grid

ISO 26262-6 Clause 9.4 defines software unit testing requirements. Table 12 specifies the applicable test methods by ASIL. The table uses a two-tier recommendation system: ++ (Highly Recommended) and + (Recommended). A method marked "o" carries no recommendation — you can use it, but it provides no credit toward the standard's requirements.

The coverage requirements from Table 12:

Coverage Method ASIL A ASIL B ASIL C ASIL D
Statement Coverage (SC) ++ ++ ++ ++
Branch Coverage (DC) + ++ ++ ++
Modified Condition/Decision Coverage (MC/DC) o o + ++

The practical read: for ASIL D, all three methods are required (++ = Highly Recommended, which in ISO 26262 means "must have a documented justification if not applied"). For ASIL C, MC/DC is recommended (+). For ASIL A and B, statement and branch coverage are sufficient; MC/DC provides no mandatory credit.

One critical clarification the standard does not make explicit: these are structural coverage requirements on the software unit implementation. They do not replace requirements-based testing, which is mandated separately by ISO 26262-6 Clause 9.4.1. You cannot substitute 100% MC/DC coverage for requirements-based test cases. You need both.

What MC/DC Actually Means — and Why It Is Harder Than It Sounds

Statement coverage requires that every executable statement in the code runs at least once. Branch coverage (also called Decision Coverage) requires that every branch from each decision point — the true and false outcomes of every if, while, for, case — is exercised at least once.

Modified Condition/Decision Coverage goes further. For every boolean decision with multiple conditions, MC/DC requires that:

  1. Each condition in the decision takes both a true and false value at least once.
  2. Each condition must independently affect the outcome of the decision — i.e., there exists at least one test where changing that single condition changes the overall decision outcome, with all other conditions held constant.

The critical word is "independently." Consider this condition:

if (brakePressed && (vehicleSpeed > 5) && !faultActive)

This decision has three conditions. Branch coverage requires testing a case where the whole expression is true and a case where it is false. MC/DC requires much more: for each of the three conditions, you need a pair of tests where only that condition changes and the decision outcome changes accordingly. For three conditions, the minimum number of MC/DC-compliant tests is N+1 = 4 (where N is the number of conditions). For a decision with six conditions, minimum is 7 tests.

In practice, decisions with correlated conditions — where A && B is never true when C is true, due to system state logic — can make it impossible to independently vary some conditions. These situations require either a restructured test approach with a documented justification, or architectural changes to the code to decouple the conditions.

For ASIL D modules, every boolean decision in safety-relevant functions must meet MC/DC. This includes decisions inside library functions, HAL drivers, and RTOS calls that are part of the safety-relevant path — unless those components carry their own functional safety qualification (ISO 26262-8 Clause 12 qualification for pre-existing software).

Branch Coverage in Practice

Branch coverage catches a class of defects that statement coverage misses entirely. If a function has an if statement with no else branch, and the false path skips an initialization step, statement coverage will pass even if no test ever exercises the false path. Branch coverage forces the false path to be tested.

For ASIL B, C, and D, branch coverage is Highly Recommended (++). Meeting it typically requires:

  • Explicit false-path tests: Every if block that lacks an else must have a test case where the condition is false.
  • Loop boundary tests: while and for loops must be tested with zero iterations, one iteration, and maximum iterations.
  • Switch/case completeness: Every case label must execute, including default.
  • Short-circuit evaluation awareness: In A && B, if A is false, B is never evaluated. Branch coverage tools typically count the short-circuit paths separately. Your test strategy must cover them.

A branch coverage gap that commonly fails ASIL assessment: error handling branches. The if (errorCode != OK) branches in sensor read functions almost never execute under normal bench testing. If those branches are on the safety-relevant path, you need fault injection tests — typically via hardware fault simulation or software stubs that return error codes — to achieve branch coverage on error paths.

How ASIL Decomposition Affects Coverage Requirements

ASIL decomposition (ISO 26262-9 Clause 5) splits an ASIL requirement into two independent elements, each carrying a reduced ASIL. The coverage requirement applies per-element at the decomposed ASIL, not at the original ASIL.

Original ASIL Decomposition Options Coverage Required per Element
ASIL D ASIL D(D) = ASIL B + ASIL B Branch coverage on each (MC/DC not required)
ASIL D ASIL D(D) = ASIL A + ASIL C Branch coverage (A), Branch + MC/DC (C)
ASIL C ASIL C(C) = ASIL A + ASIL B Branch coverage on each
ASIL B ASIL B(B) = ASIL A + ASIL A Statement + Branch on each

The decomposition benefit is real but comes with a cost: the two elements must be sufficiently independent, per ISO 26262-9 Clause 6 (Dependent Failure Analysis). If you decompose an ASIL D requirement to avoid MC/DC on both channels, you must prove that the two software channels cannot share a common cause failure — different compilers, different library versions, or a certified freedom-from-interference partition between them.

A team that implements ASIL D(D) decomposition to reduce coverage overhead, without performing the required DFA to validate the independence claims, will encounter this gap in assessment. The coverage reduction is legitimate; the independence evidence is not optional.

The Toolchain Qualification Problem

Code coverage is typically measured by instrumented builds or coverage-capable debuggers. ISO 26262-8 Clause 11 requires that software tools used in the development of safety-relevant software be qualified if their output can affect the safety of the system without independent verification.

A coverage tool that reports "100% MC/DC achieved" when coverage is actually 87% creates a systematic error in the safety case. ISO 26262-8 Table 4 classifies coverage measurement tools — depending on how the output is used, the tool may require qualification at TCL2 or TCL3.

The practical implication: if your coverage tool is not qualified, your coverage results carry a qualification caveat in the safety case. Assessors ask for tool qualification documentation routinely. The tool qualification report must show: what erroneous output the tool could produce, what confidence level is achieved, and what mitigations (manual checks, diverse tool comparison) are in place.

Demonstrating Coverage to an Assessor

An assessment of software unit verification coverage typically involves four evidence types:

Coverage report: A per-module breakdown of statement, branch, and MC/DC coverage percentages, generated by the qualified coverage tool. For ASIL D, 100% MC/DC is the target. Any gap requires a documented deviation with technical justification — typically that the uncovered path is unreachable dead code (which itself requires proof via static analysis), or that the path is in non-safety-relevant code with a documented scope boundary.

Traceability matrix: Each unit test case must trace to the software unit requirement it is testing (requirements-based testing) and to the coverage elements it exercises (structural coverage). The assessor verifies that the coverage was achieved through purposeful test design, not incidentally through functional testing that happened to touch the code.

Fault injection evidence: Error-handling paths that cannot be reached by normal functional tests require evidence that fault injection tests were performed. The test setup, injected fault, observed response, and pass/fail criteria must be documented.

Tool qualification record: Documentation that the coverage measurement tool was used within its qualified operating conditions — including compiler version, target platform, and instrumentation settings that match the qualified configuration.

How ISO WIZ Tracks Software Unit Verification

Software unit verification traceability is one of the most time-consuming documentation tasks in a 26262 program. Test cases must trace to software unit requirements, which trace to software safety requirements, which trace to technical safety requirements, which trace to safety goals in the HARA. That is a four-level traceability chain, and every level must be consistent.

ISO WIZ maintains this chain as a live data model. Software unit test results — including coverage percentages and any deviation justifications — are linked directly to the software unit requirements they verify. When a requirement changes, the linked test cases are flagged for re-review. When a coverage gap is documented as a deviation, ISO WIZ links the deviation rationale to the specific requirement and tracks it to the safety case.

For programs running ASIL decomposition, ISO WIZ tracks the decomposed ASIL per software element, applies the correct coverage requirement automatically, and flags elements where the claimed decomposition independence has not been validated by DFA. The traceability gap between coverage reduction and independence evidence — the gap that trips most decomposition-based programs in assessment — surfaces as an open finding before the assessment, not during it.

Software unit verification is where many programs discover late that their test coverage strategy does not match their ASIL architecture. Building the traceability correctly from the start — requirement by requirement, unit by unit — is what ISO WIZ is designed to support.