Skip to content

Structural Coverage & MC/DC (ISO 26262-6)

Provadyne evaluates structural coverage against ISO 26262-6:2018: statement, branch, and MC/DC (Modified Condition/Decision Coverage) at the software-unit level (Table 9), and function and call coverage at the software-architectural level (Table 12). MC/DC is highly recommended for ASIL D. The feature gives you a pass/fail gate and a gap report for your safety case.

Provadyne does not instrument or run your code. You produce coverage with your own toolchain (the data you already generate for testing); Provadyne ingests it, normalizes it, and evaluates it. This keeps your build authoritative and the tool auditable.

Pro feature: structural_coverage.

1. Produce coverage data

GCC (gcov)

# Compile with coverage + MC/DC (condition coverage needs GCC 14+)
gcc --coverage -fcondition-coverage -O0 -o test_runner your_sources.c test_main.c
./test_runner                      # run your tests
# -b/-a enrich the JSON with branch + call data (call coverage is gcov-only)
gcov -b -a --json-format --stdout *.gcno > coverage.json

Clang / LLVM (llvm-cov)

clang -fprofile-instr-generate -fcoverage-mapping -fcoverage-mcdc \
      -O0 -o test_runner your_sources.c test_main.c
LLVM_PROFILE_FILE=run.profraw ./test_runner
llvm-profdata merge -sparse run.profraw -o run.profdata
llvm-cov export ./test_runner -instr-profile=run.profdata > coverage.json

MC/DC only appears if you compiled with -fcondition-coverage (GCC) / -fcoverage-mcdc (Clang). Without it, MC/DC is reported as not measured (never silently 0%).

2. Evaluate (CLI)

python -m engine.structcov.cli --input coverage.json --asil D

Structural coverage — ISO 26262-6 Table 9 (ASIL D): FAIL
  metric       rec   measured  required  status
  statement    +        80.0%      100%  WARN
  branch       ++       75.0%      100%  GAP
  mcdc         ++       75.0%      100%  GAP
  function coverage (info, Table 12): 66.7% (2/3)
  • --format auto|gcov|llvmcov — input format (auto-detected by default).
  • --asil A|B|C|D — target ASIL (default D).
  • --threshold mcdc=90,branch=85 — override the required percent per metric.
  • --report text|json|markdown — output format.
  • --output report.json — write to a file instead of stdout.

Exit code is non-zero when a highly-recommended (++) metric is below threshold — wire it straight into CI as a gate.

3. Evaluate (daemon API)

curl -X POST http://localhost:9400/api/v1/coverage/evaluate \
  -H 'Content-Type: application/json' \
  -d '{"coverage_path":"/path/under/allowed/coverage.json","asil":"D"}'

The path must be inside ALLOWED_ANALYZE_DIR. The response is the same JSON the CLI emits with --report json.

4. Requirements-based coverage (ISO 26262-6 Clause 9)

Join coverage to a traceability matrix (from the tracer / /api/v1/trace/matrix) to see whether the code implementing each requirement is covered to the target ASIL:

python -m engine.structcov.cli --input coverage.json \
    --requirements trace_matrix.json --asil D

Requirements-based coverage — ISO 26262-6 (ASIL D)
  requirements: 2 | with coverage: 1 | passing: 0 | failing: 1

  [  FAIL] REQ-1  Brake pressure clamp
           files: 1/1 covered · mcdc 75.0%
  [NO COV] REQ-2  Watchdog reset
           no coverage data for: src/unmeasured.c

The daemon endpoint takes the same input via requirements_path. Coverage files are matched to requirement files by path suffix, so absolute coverage paths line up with repo-relative requirement paths. Exit code / failing count is non-zero when any requirement's code falls short — requirements-based test-coverage adequacy evidence for the safety case.

5. How the ISO 26262-6 mapping works

engine/structcov/iso26262_coverage.json encodes the per-ASIL recommendation levels from Table 9 (++ highly recommended, + recommended):

Unit level (Table 9):

Metric A B C D
statement ++ ++ + +
branch + ++ ++ ++
MC/DC + + + ++

Architectural level (Table 12):

Metric A B C D
function + + ++ ++
call + + ++ ++

Status per metric: a ++ metric below threshold (or unmeasured) is a hard gap (fails the gate); a + metric is a warning. The overall result fails if any metric in either table is a hard gap; unit_passed / architectural_passed report each table separately. Call coverage comes from gcov (-b); llvm-cov does not emit it, so it reads as not measured there.

6. Honest limits

  • We ingest coverage you produced; we do not instrument or run code.
  • MC/DC fidelity is entirely your compiler's; we never synthesize it from line/branch data.
  • The numeric thresholds are Provadyne defaults (the full target); the authoritative source is the standard, and coverage gaps may be acceptable with documented rationale. Tailoring and the safety case remain yours.