---

There is a gap between the software you test and the software you ship, and it is not where most people look for it.

Unit-level and integration-level evidence answer different questions

Source-instrumented unit tests are an established and effective way to verify isolated software units. They usually run on a test-specific executable because the purpose is to exercise unit behavior and obtain detailed source-level feedback. Integration and system tests have a different purpose: they exercise optimized, linked software in its hardware and scheduling context. At that level, differences between the measured executable and the delivered executable may require a separate representativeness argument.

Instrumentation can change the conditions an integration test is intended to reproduce

The effect is configuration-dependent and should be measured, not assumed. Relevant mechanisms include:

• Execution and scheduling: added instructions, register pressure, memory traffic or changed layout can affect path timing, interrupt latency and task interaction.
• Footprint and placement: additional code and data can change section placement, cache behavior or whether the executable fits the production memory map.
• Optimization and mapping: instrumentation can alter optimization decisions and therefore the relationship between source constructs, object code and the measured execution.

None of these effects makes instrumented testing invalid in general. They determine what the result can represent and which additional evidence is needed.

The usual answer is to accept the compromise: measure at unit level, and argue the rest. Projects commonly address the difference through configuration control, complementary object-code analysis or additional test evidence. The required effort depends on the assurance objective, the magnitude of the differences and the project’s accepted verification strategy.

The alternative: don’t touch the binary

Many modern processors can emit compressed instruction trace through dedicated debug and trace infrastructure. The exact information and timing precision depend on the implemented trace source, its configuration and the available path off chip or into an on-chip sink.

A decoder combines the valid trace stream with the corresponding program image to reconstruct executed control flow. This can provide coverage and timing evidence for the measured executable without inserting application-side coverage counters. Source-level results remain subject to the available trace semantics, compiler mapping and the chosen analysis mode.

That is what CEDARtools^® does.

Why this is not only a certification argument

DO-178C and ISO 26262 define structural-coverage objectives or recommended methods within their respective assurance frameworks. They do not generally prescribe that every coverage result be collected from the exact delivered executable. Measuring the executable used at integration or system level can nevertheless reduce the representativeness argument that arises when evidence is collected from a separately instrumented build.

That is where the methods came from. But the reason to want such evidence is older and more general than any standard: evidence about the artifact you deliver is worth more than evidence about a proxy for it.

Wherever failure is expensive - and that is most production software, certified or not - the same argument applies. The reason it has not been applied everywhere is cost, not principle.

---

Next: how it works · is my target supported?

Review the gap in your current evidence chain

Send us the target, build configuration, test level and the evidence you currently collect. We will identify where the measured artifact changes and which parts can be observed directly.

Review your evidence chain

Sources

The external references on this page are:

• gcov, documented in the GCC manual;
• RTCA DO-178C / EUROCAE ED-12C, cited by section (licensed publication);
• ISO 26262-6, cited by table (licensed publication).

Public references support the standards and tool descriptions on this page. Statements about Accemic products and measurements are supported by the linked product documentation or Accemic measurement records. Interpretive statements are identified as engineering analysis rather than attributed to a standard.