3. Traceability and linkage

In a subsystem-to-vehicle validation program, evidence rarely fails because a single test was executed poorly. It fails because the link between a requirement, the test that exercises it, and the artifact that proves it was never made explicit. Traceability is the discipline that keeps those three objects connected as work moves from a component supplier's bench to a vehicle-level proving ground. Without it, a passing subsystem test cannot be shown to satisfy a vehicle-level requirement, and a vehicle-level failure cannot be decomposed back to the responsible subsystem behavior.

The core object model is small but must be applied consistently. A requirement is a uniquely identified, verifiable statement (for example, a braking ECU requirement that wheel-slip control must reduce stopping distance by a stated margin under a defined surface). A test case is a procedure with defined inputs, preconditions, and pass/fail criteria that exercises one or more requirements. An evidence artifact is the recorded output of executing that test case: a log file, a measurement trace, a signed report, a calibration record. Traceability is the set of typed links among these objects, plus the links that cross the subsystem/vehicle boundary.

Key distinction: A link is not a mention. Writing "covers braking requirement" in a test report is not traceability. A traceable link is a machine-checkable reference from a test case ID to a requirement ID, and from an evidence artifact to the test case execution that produced it, with a timestamp and configuration identity.

Why the boundary is the hard part

Within a single subsystem, traceability is usually a local database problem. The difficulty appears at the boundary, where three things change at once: the owner of the requirement (system engineering vs. component team), the level of abstraction (vehicle-level performance vs. subsystem-level signal behavior), and the configuration baseline (which software build, which harness, which vehicle build). A vehicle-level requirement such as "the ADAS feature shall not command braking when no obstacle is present" is satisfied only through a chain: vehicle requirement → subsystem requirement on the perception module → test case on the perception bench → evidence from that bench run → integration test on the vehicle → vehicle-level evidence. Each hop must be explicit, or the chain is unverifiable.

The practical consequence is that traceability must be modeled as a directed graph with typed edges, not a flat spreadsheet. The most useful edge types are: derives (parent requirement to child requirement), verifies (test case to requirement), produces (test execution to evidence artifact), and integrates (subsystem evidence to vehicle-level test case). A requirement with no incoming verifies edge is unverified; a test case with no outgoing verifies edge is orphaned; an evidence artifact with no produces edge back to an execution is unattributable.

subsystem / vehicle boundary Vehicle level VR-014 No unintended braking Vehicle requirement · ADAS feature TC-V-021 Vehicle false-brake test Proving ground · 60 km/h · clear lane EV-V-021 Vehicle log + report Build V2.3.1 · signed · 2024-06-11 Subsystem level (perception) SR-207 No target above threshold Subsystem requirement · perception TC-S-207 Bench false-target test HIL bench · injected clear scene EV-S-207 HIL trace + verdict SW build 4.8.2 · trace · 2024-05-28 verifies produces verifies produces derives integrates intra-level link derives (parent→child) integrates (subsystem evidence→vehicle test) Every requirement needs an incoming verifies edge; every evidence artifact needs a produces edge back to an execution.

Making the links machine-checkable

The graph above is only useful if the links are stored as data, not prose. A workable minimum is a link table with the fields source_id, target_id, link_type, baseline, and created_by. The baseline field is what makes cross-boundary traceability auditable: it records which configuration the link was valid for. When the perception software moves from build 4.8.2 to 4.9.0, every integrates edge that referenced 4.8.2 evidence must be re-evaluated, not silently inherited.

source_id,target_id,link_type,baseline,created_by
VR-014,SR-207,derives,VEH-V2.3,se-team
SR-207,TC-S-207,verifies,PER-SW-4.8.2,perception-test
TC-S-207,EV-S-207,produces,PER-SW-4.8.2,perception-test
EV-S-207,TC-V-021,integrates,VEH-V2.3,integration-lead
VR-014,TC-V-021,verifies,VEH-V2.3,vehicle-test
TC-V-021,EV-V-021,produces,VEH-V2.3,vehicle-test

With this table, three queries answer most traceability questions. First, coverage: which requirements have no incoming verifies edge? Second, orphans: which test cases verify nothing? Third, staleness: which integrates edges point to evidence whose baseline no longer matches the current vehicle baseline? The third query is the one that catches the most expensive defects, because it detects the case where a subsystem was re-flashed after its evidence was accepted.

Worked example: closing a boundary gap

Consider the chain in the figure. The perception team runs TC-S-207 on the HIL bench with an injected clear scene and records EV-S-207, a trace showing zero targets above the confidence threshold for the full 120-second run. The integration lead then links EV-S-207 to TC-V-021 with an integrates edge at baseline VEH-V2.3. The vehicle test is executed on the proving ground at 60 km/h in a clear lane, and EV-V-021 is produced.

Now suppose the perception software is updated to 4.9.0 to fix an unrelated latency issue, and the vehicle build is re-flashed. A staleness query returns the integrates edge from EV-S-207 because its baseline PER-SW-4.8.2 no longer matches the vehicle's embedded perception build. The correct response is not to delete the edge but to mark it superseded and require a re-run of TC-S-207 at 4.9.0 before TC-V-021 can be re-accepted. This is the concrete mechanism by which traceability prevents a stale subsystem result from silently propping up a vehicle-level claim.

Practical rule: Treat the integrates edge as a claim that "this subsystem evidence is valid input to this vehicle test at this baseline." If you cannot state the baseline, you cannot make the claim.

Common failure symptoms and how to diagnose them

  • Passing vehicle test, failing field behavior. Usually an integrates edge pointing at evidence from a different software build. Run the staleness query against the current vehicle baseline.
  • Requirement marked "verified" with no artifact. A verifies edge exists but no produces edge reaches an evidence artifact. The requirement is covered on paper only.
  • Duplicate or conflicting evidence. Two evidence artifacts claim to support the same test case at different baselines. Keep both, mark the older one superseded, and record which one the acceptance decision used.
  • Boundary ambiguity. A requirement is owned by the system team but verified only at subsystem level, with no vehicle-level confirmation. Add the missing integrates edge or explicitly record a justified waiver.

What "done" looks like for a traceability review

A traceability review is complete when, for every in-scope vehicle requirement, you can walk a continuous path from the requirement through at least one verifies edge to a test case, through a produces edge to an evidence artifact, and — where the requirement is satisfied only through subsystem behavior — through an integrates edge to the vehicle-level test that confirms the integrated result. Every edge on that path must carry a baseline that matches the configuration under review. Gaps are recorded as explicit open items with an owner, not left implicit. When that walk succeeds for the full requirement set, the evidence hierarchy is not merely documented; it is defensible.

← Previous 📖 Contents Next →