CEDARtools.Coverage
Structural coverage measured from the trace port on the optimized executable under test - available at integration and system level, not only in units.
In brief
CEDARtools.Coverage measures structural coverage from the processor’s trace port - on the optimized executable under test, on real hardware, at operational speed, without a single coverage counter in the application. When configuration control establishes identity, that executable is the one you ship.
That is not only a cleaner way to do what instrumentation does. It is what makes coverage available at integration and system level, where instrumentation is usually impractical and the evidence is therefore argued rather than measured.
Where the evidence is usually missing
Unit-level coverage is the part everyone has. It is measured on a host, on a separately built executable, in isolation - and it is comparatively cheap to obtain.
The expensive question sits one level up: was this code exercised when it ran integrated, on the target, in the build that ships? Instrumenting that build changes it, and at integration and system level the instrumented executable is often not the one anyone wants to argue about. So the gap is usually closed by argument - unit coverage plus a justification for why the rest is acceptable.
Measuring from the trace port removes the reason for that argument. The observation is passive, so the measured executable can be the delivered one, and the same measurement works whether the test that drives it is a unit test, an integration test or a full system run.
No standard prescribes the test level at which structural coverage has to be measured, and unit-level measurement with a documented justification can remain a compliant route under the applicable objectives and the judgment of the approval authority. What changes is the quality of the evidence: a measurement on the integrated build is not the same claim as an argument about it.
Coverage levels
| Level | How it is observed |
|---|---|
| Object-code execution | directly from the trace, for the valid observed scope |
| Statement / line | object observations mapped to source via debug information |
| Branch / decision | where outcomes are distinguishable in the object control flow |
| Condition and MC/DC | from the trace where observable; CEDARtools.Anchor supplements the rest with disclosed anchors |
Which observation mode yields which evidence on which trace path - the full matrix - is on the capability matrix.
What sets it apart
- Object code back to source, with the ambiguity shown. Trace observes object code; a coverage obligation lives in source. Optimization sits between the two and merges, moves or removes the distinctions that carry the mapping. Accemic reports what remains passively observable, what is ambiguous, and what is unresolved - it does not resolve a doubtful mapping by picking the likely answer. How the mapping works
- MC/DC evidence survives optimization. Where the required source outcomes are not recoverable from the optimized object control flow, CEDARtools.Anchor adds explicit, named observation anchors and reports their measured effect separately - the application still maintains no coverage state.
- The optimized executable under test - in passive mode, the binary you ship. Trace analysis inserts no coverage counters, logging calls or measurement runtime into the application instruction stream. The trace infrastructure still has to be configured, and the physical trace path consumes pins, bandwidth and power.
- No fixed capture limit. Coverage is counted live in the CEDARbox instead of filling a capture buffer - subject to sustained lossless delivery and the verified limits of the named configuration.
Two problems it is bought for
Test prioritization - knowing which tests touch which code at integration level, and prioritizing the tests with the most impact; on the desktop, tools like Teamscale made this standard practice. Coverage for test prioritization
Integration evidence - the certification argument one level above unit tests, on the optimized, linked, real thing. Coverage for integration evidence
Export formats
| Format | Use |
|---|---|
| HTML | reading and review |
| CSV | your own pipeline |
| AsciiDoc | inclusion in generated documents |
| Gcov intermediate coverage | hand-off to tools that read gcov output |
| TESSY Hyper Coverage | merge with unit-level coverage from Razorcat’s tool |
| Teamscale (native line coverage) | trend analysis and test-gap analysis |
Honest limitations
- The trace data has to get off the board. Which route is available depends on the silicon and on how the board was laid out, and that part is settled at PCB design time. It is a question for the feasibility review rather than a verdict - a workable route exists far more often than the first look suggests. Supported targets describes what the review checks and what to send.
Tool qualification
Certification projects often need qualification evidence for the tools in their verification chain - tool qualification data under DO-330, a tool confidence level argument under ISO 26262. Whether a kit applies and what it has to cover depends on your standard, your target configuration and the role the tool plays in your process. If you are interested in a tool qualification kit for CEDARtools.Coverage, contact our support - we will discuss scope and certification context with you.