Standards
Where structural coverage requirements come from, what trace-based measurement contributes to them, and what it does not.
Structural coverage appears as an objective, required activity or recommended method in several assurance frameworks. The applicable level, software scope, development stage and strength of recommendation differ by standard and project classification.
| Document | Domain | Website-safe summary |
|---|---|---|
| DO-178C / ED-12C | airborne software | Structural coverage objectives vary by software level; MC/DC is associated with Level A objectives. Additional verification may be needed where source coverage does not account for generated object code. |
| ISO 26262-6 | automotive software | Structural coverage methods are recommended with strength depending on ASIL and development activity; MC/DC is associated with ASIL D at unit level. The standard does not make one coverage tool or one measured executable universally mandatory. |
| IEC 61508-3 | industrial functional safety | Test-coverage techniques are recommended according to safety-integrity context and lifecycle activity. |
| EN 50716 | railway software | Software verification methods and coverage expectations depend on software integrity context and the applicable lifecycle evidence. |
| EASA AMC 20-193 | airborne multi-core processors | Provides an acceptable means of compliance for identifying and managing multi-core interference and related verification concerns. |
These summaries are navigation aids, not substitutes for the licensed standards or project compliance plans.
What trace-based measurement contributes
Evidence from the executable that ran. Trace-based measurement can collect evidence from the executable used in an integration or system test, avoiding application-side coverage counters in passive mode. This can reduce, but does not eliminate, the project argument relating the measured artifact, source structure and delivered executable.
Object-code accountability. For airborne software at the applicable assurance level, the project may need to determine whether object code not directly traceable to source structure has been adequately verified. Accemic reports unmapped or otherwise unresolved object-code regions explicitly. The exact obligation and accepted method must be taken from the applicable DO-178C/ED-12C objective and project guidance, not inferred from this website summary alone.
Timing observations from real silicon, as an input to the multi-core interference analysis for which AMC 20-193 provides an acceptable means of compliance.
What it does not contribute
A percentage that means something on its own. MC/DC summaries depend on the defined obligation model, treatment of coupled or infeasible conditions, exclusions, aggregation level and denominator policy. Accemic therefore reports obligation counts and dispositions alongside any percentage and keeps the calculation method explicit.
Tool-qualification evidence. A measurement is not a qualification argument. Whether a tool needs qualification, and to what level, follows from its role in the project and from the errors it could introduce or fail to detect - it does not follow from the quality of what it measures. Where that boundary runs
Safety standards provide demanding and useful assurance frameworks, but evidence accepted in one domain is not automatically sufficient in another. The underlying practices - traceability, configuration control, explicit limitations and reviewable evidence - can still be valuable outside regulated development.
Why this matters outside certified development
The reason to want evidence about the software you actually ship does not come from a regulation. It comes from the cost of the failure. Most software where failure is expensive is not certified at all, and the methods work there just as well. The observability gap