What the standards actually require of structural coverage
Four regimes, one requirement, slightly different words each time - and the part that is a measurement rather than an argument.
Structural coverage appears in several major software-assurance frameworks - but the applicable activity, recommendation strength, lifecycle stage and required disposition differ by framework and edition. The table below is a navigation aid across four of them; the pattern it shows is where the useful reading is.
The four regimes
| Standard | Domain | Structural coverage expectation |
|---|---|---|
| DO-178C / ED-12C | Avionics | Structural coverage objectives vary by software level; MC/DC is associated with Level A objectives, decision coverage with Level B, statement coverage with Level C |
| ISO 26262-6 | Automotive | Coverage methods recommended with strength depending on ASIL and development activity; MC/DC associated with ASIL D at unit level |
| IEC 61508-3 | Industrial functional safety | Test-coverage techniques recommended according to safety-integrity context |
| EN 50716 | Rail | Verification methods and coverage expectations depend on software integrity context |
These summaries are navigation aids, not substitutes for the licensed standards; cite the applicable edition and table in a project context.
Read the right-hand column and the pattern is obvious: the same ladder of metrics, applied at the point where the consequences of failure justify it.
What “highly recommended” means
In the IEC-derived standards - ISO 26262, IEC 61508, EN 50128 - the tables use highly recommended rather than shall. This is regularly misread as optional.
Where an applicable table labels a technique highly recommended, the standard’s own rules for alternatives and justification apply: deviating requires a written rationale, and the resulting burden is framework-, lifecycle- and assessment-specific. It is not a free choice; it is a choice you have to argue for, with the burden on you. Teams that treat it as optional tend to discover this late.
The part that is measurement, and the part that is argument
This is the distinction worth internalizing, because it decides where your effort goes.
Measurement: which code was executed by which tests, at which structural level. This is mechanical. A tool produces it. It is either done or not.
Argument: everything else the standards ask around it -
- that the tests are derived from requirements, not from the code;
- that the coverage was measured on something representative of what ships;
- that the code not covered is accounted for - a shortcoming in the requirements-based tests, an inadequacy in the requirements themselves, dead code, or deactivated code - after evidence problems such as trace loss or unresolved mapping have been separated out;
- that the tool producing the measurement is trustworthy for that purpose.
Most of the effort in a certification campaign goes into the second list. And the second list is where measuring on a build that is not the shipped one costs you: the representativeness of the measured artifact becomes an argument you have to construct, rather than a fact you can state.
Where the levels differ in kind, not degree
Two thresholds change the nature of the work rather than its amount.
The MC/DC threshold. Higher assurance levels commonly introduce MC/DC in specified contexts - DO-178C associates it with Level A objectives, ISO 26262 with ASIL D at unit level; the exact objective comes from the applicable edition, table and lifecycle process, not from a cross-standard shorthand. Below that threshold, coverage is essentially a counting exercise. At it, the measurement needs the decision structure to be observable, which is where the object-code problem starts.
The object-code threshold (DO-178C level A, section 6.4.4.2 b). If the compiler produces object code that is not directly traceable to source statements, additional verification is required on the object code itself. This is the clause that turns a source-level activity into a binary-level one.
The question behind the checklist
An assessor is not verifying your percentage. They are trying to establish whether you know what your software does.
That reframing explains several things that otherwise look like bureaucracy: why they ask what you did about the code your tests did not reach; why they want to know how the measurement relates to the delivered artifact; why a report with a documented gap is received better than one that looks perfect.
A number that cannot be traced back to a method is not evidence, it is a claim.
Practical consequences
- Know which metric your level demands, and measure it rather than something adjacent.
- Decide early where you measure. Host unit tests and on-target integration tests answer different questions, and only one of them involves the binary you ship.
- Plan for the residue. The code your tests do not reach is a deliverable question, not an embarrassment - see dead code and deactivated code.
- Ask about tool qualification early. A qualified or certified downstream tool may provide qualified processing within its stated scope, but importing data does not by itself qualify the upstream measurement or transfer - which makes the interface between them part of your plan.
Sources
The requirements described above are stated in the standards themselves. All three are licensed publications and are therefore cited by section and table rather than linked:
- RTCA DO-178C / EUROCAE ED-12C, cited by section;
- ISO 26262-6, cited by table;
- IEC 61508-3 and EN 50128 / EN 50716, cited by table.
Related: dead code, deactivated code and the rest · our standards overview