---

Recalls and liability are the expensive end of an automotive software defect, and the schedule pressure at the cheap end is relentless. Both push in the same direction: find it before it ships, without adding a test phase.

Coverage where the code is real

ISO 26262 recommends structural-coverage methods with strength depending on ASIL and development activity. Measuring production-representative software on target can strengthen integration evidence, but the standard does not prescribe one universal measurement architecture.

Trace-based measurement moves the same metrics to integration and system level, on the ECU, on the optimized build - not as a replacement for unit testing, but as evidence for the level that was previously argued rather than measured.

Automotive evidence must identify the software variant, calibration, boot and security state, multicore configuration and compiler/linker build. Coverage from one variant is not transferred to another without an explicit equivalence or impact argument.

AURIX^™

For Infineon^® AURIX^™ the vendor’s MCDS mechanism provides the trace source; CEDARtools.SmartTrace reads it on documented TC3xx and TC4xx configurations - support is a property of the exact configuration, not of the family name.

Trace-derived timing is an observation for the named hardware and workload. It does not by itself establish a safe execution-time bound across voltage, temperature, cache state, interference and product variants.

For Arm^®-based ECUs, target support is answered per configuration.