Test What You Fly: Trace-Based Code Coverage for Safety-Critical Certification

Introduction

In aerospace and defense software, verification demands are written into the standards. DO-178C requires structural coverage evidence, with DO-330 covering tool qualification. That evidence grows more rigorous by level: statement, branch/decision, and Modified Condition/Decision Coverage (MC/DC).

The challenge is how the evidence is collected. Traditional coverage tools instrument the software: They insert probes into source or object code to record execution, so the verified artifact is no longer the binary that flies.

For flight controllers, drone systems, or satellite payloads, that gap matters. The goal is to validate real production code, not a modified version. Lauterbach’s TRACE32® hardware trace enables this. It captures runtime behavior non-intrusively, supporting coverage on unmodified binaries. The same logic applies under ISO 26262 and IEC 62304.

Why Instrumentation Is a Liability in Safety-Critical Code

Instrumentation works by adding measurement code to the program. Each probe records that a statement, branch, or condition was reached, and the accumulated data becomes the coverage report. For general application development, this is often acceptable; in safety-critical systems, it introduces real problems.

The code size and memory footprint change; even more importantly, timing alters upon addition of probes. This "probe effect" can mask genuine concurrency defects or introduce race conditions absent from the shipped software. Since the instrumented build differs from the final build, evidence gathered on one does not cleanly transfer to the other, often forcing another round of verification on the uninstrumented binary.

The certification consequence is direct: coverage measured on instrumented code may not faithfully represent the deployed system, weakening the assurance argument where it needs to be strongest. Trace addresses this by observing execution rather than altering it.

How Trace-Based Code Coverage Works

Lauterbach’s hardware trace uses dedicated on-chip logic to emit a stream describing program execution: instruction flow, branches taken, and related events, while the processor runs the unmodified application. External tooling records that stream and reconstructs it against the program image, so no measurement code is added to the binary.

Within TRACE32®, three components map onto this workflow:

1. PowerView is the debugger and analysis front end, where captured execution becomes coverage results.
2. PowerDebug System is the modular run-control hardware system connecting the host to the debug interface of the target.
3. PowerTrace System is the modular high-bandwidth hardware extension that captures off-chip trace data.

Once a trace is recorded, TRACE32® correlates it with the binary to produce statement, branch/decision, and MC/DC coverage directly from production code. The toolchain supports Ada, C, C++, and Rust, reflecting the language mix found across safety-critical projects.

On-Chip vs. Off-Chip Trace: The Engineering Tradeoff

The way trace escapes the chip shapes influences the entire coverage strategy. Many devices provide an on-chip trace buffer that stores execution data in internal memory. It needs no extra pins and keeps hardware cost low, but its depth is limited: capture windows are short, and on high-throughput or multicore workloads the buffer can overflow and lose data.

Off-chip trace streams execution data through a dedicated trace port to external capture memory, as provided by PowerTrace. This offers far higher bandwidth and much deeper history, suiting long coverage runs and the analysis of multiple cores in parallel. The primary consideration for buyers is that off-chip trace depends on the silicon exposing a suitable parallel or serial trace port, a capability that varies between chips and even between package variants of the same device.

Deep, continuous capture is what makes it practical to demonstrate coverage over realistic execution and to perform multicore timing analysis under CAST-32A, including worst-case execution time (WCET).

Test What You Fly – Fitting Into Certification Workflows and the Tool Ecosystem

TRACE32® is built to serve as a core solution while integrating with the wider verification environment rather than acting as a closed silo. Coverage and trace data feed into qualification and analysis tools such as Rapita RVS, LDRA ToolSuite, VectorCAST, and Parasoft C/C++test, letting teams retain existing investments.

TRACE32® integrates with Rapita's ZeroTools suite for deep on-target debugging and trace plus automated, qualification-grade testing in one workflow. Rapita and Lauterbach are hosting a dedicated webinar on this integration, where they will deep dive into the topic of multicore interference analysis. 

Register here for the free live webinar on 24th November at 15:00 (GMT)  

Prequalification reduces effort further. Tools prequalified for DO-178C and DO-330 lower the tool-qualification burden the project would otherwise carry, and support for CI/CD alongside SaaS and hardware-as-a-service models allows automated, repeatable runs from pre-silicon development through in-field analysis. Combining trace-based coverage with a qualified workflow this way can save up to 50% of the certification effort typically required — a figure that depends on program specifics but indicates where the savings originate.

Practical Platform Verification for Decision-Makers

For the manager deciding what a team should standardize on, one practical check comes first: confirm the intended target is actually supported. Lauterbach maintains a chip database covering more than 15,000 FPGAs, SoCs, and MCUs across over 150 architectures — including Arm, PowerPC, AURIX TriCore, and x86 — and it indicates which trace method each device supports.

Checking trace-port availability per device variant early is worthwhile, because that single detail constrains the on-chip versus off-chip decision and the coverage strategy that follows. Selecting a target without confirming trace support can quietly foreclose the most efficient path to certification evidence.

Conclusion

In safety-critical development, verification evidence is only as trustworthy as the artifact it is collected from. Instrumentation compromises that link by changing the code under test; trace preserves it by observing the unmodified binary as it runs; that is the substance behind "test what you fly".

For technical decision-makers, the takeaway is a toolchain that captures coverage non-intrusively, scales from pre-silicon to in-field, and integrates with established qualification tools while reducing certification effort — provided platform and trace support are confirmed at the outset.