4. Mapping physical test requirements to virtual coverage

Physical test coverage planning only becomes actionable when each physical test requirement can be traced, link by link, into a simulation scenario and a measurable acceptance criterion. This chapter describes how to build that traceability chain: from a test objective expressed in engineering language, through the physical test that realizes it, into a virtual scenario that reproduces the same stimulus and observation points, and finally into acceptance criteria that are equivalent in intent even if not identical in mechanism. The goal is not to replace physical testing with simulation, but to make the two comparable, auditable, and mutually reinforcing.

Why traceability is the core artifact

A virtual validation program is only credible if a reviewer can answer three questions for any simulation run: Which physical test requirement does this scenario cover? What exactly is being stimulated and observed? What result counts as a pass? Without an explicit traceability structure, simulation coverage degenerates into a collection of scenarios that happen to run, and gaps in physical coverage are silently inherited rather than deliberately closed.

Traceability should be modeled as a directed chain with stable identifiers at each node. A practical structure uses four linked entities:

• Test objective (TO) — the engineering intent, e.g. "verify that the braking controller detects a wheel-speed sensor open circuit within the required detection time."
• Physical test case (PT) — the bench or vehicle test that realizes the objective, with its stimulus, instrumentation, and pass/fail limits.
• Virtual scenario (VS) — the simulation configuration that reproduces the relevant stimulus and observation points, including plant model fidelity assumptions.
• Acceptance criterion (AC) — the measurable condition in the virtual run that demonstrates the objective is met.

Each link must record not only the reference but also the transformation: what was abstracted, what was substituted, and what fidelity assumption justifies the substitution. This is where most traceability efforts fail — the links exist, but the reasoning behind them is undocumented, so equivalence cannot be defended during review.

Decomposing a test objective into observable quantities

The first concrete step is to rewrite the test objective as a set of observable quantities with units, tolerances, and timing. A test objective is rarely directly simulatable; it must be decomposed into signals that both the physical test and the simulation can produce.

Consider the wheel-speed sensor open-circuit example. The physical test applies a harness break at a defined moment, logs the sensor signal, the controller's diagnostic status, and the warning lamp request. The decomposition yields:

This table is the working heart of the mapping. Note that the fault injection instant and the detection time are defined identically in both domains, while the signal plausibility is where fidelity assumptions matter most: the plant model must reproduce the open-circuit behavior (signal drop to a defined level, or a pull-up-dependent offset) closely enough that the controller's diagnostic algorithm sees an equivalent input.

Building the traceability chain

With observables defined, the chain can be instantiated. A minimal but complete record for one requirement looks like this:

TO-0142  Detect wheel-speed sensor open circuit within 200 ms
  PT-0142-A  HIL bench, harness break at 40 km/h steady state
    stimulus: relay opens at t = 5.000 s
    instrumentation: CAN log 10 ms, scope on sensor line
    pass: DTC set within 200 ms, lamp request within 250 ms
  VS-0142-A  SIL scenario, same speed and injection timing
    plant: wheel-speed model with open-circuit output stage
    injection: fault event at t = 5.000 s
    observation: DTC status, lamp request, sensor node voltage
  AC-0142-A  DTC set time ≤ 200 ms; lamp request ≤ 250 ms;
             sensor node voltage within 0.2 V of physical log

The acceptance criterion deserves particular attention. It should be expressed in the same units and against the same limits as the physical test wherever the mechanism is shared, and it should add an explicit fidelity check where the mechanism differs. In the example, the timing limits are carried over unchanged because the diagnostic algorithm and its clock are identical; the sensor node voltage comparison is added because the plant model, not the real harness, now produces that signal.

Handling requirements that cannot be mapped one-to-one

Not every physical requirement has a clean virtual counterpart. Three patterns recur and each needs a deliberate treatment:

• Split mapping — one physical test covers several objectives (e.g. a single brake test exercises ABS, EBD, and diagnostics). The virtual side should split into separate scenarios so each objective has its own acceptance criterion, while the physical test ID is referenced by all of them.
• Partial mapping — only part of the physical stimulus is reproducible (e.g. thermal effects, sensor aging). The virtual scenario covers the reproducible portion and the traceability record explicitly marks the residual as "physical-only," so coverage reporting does not overstate what simulation proves.
• Surrogate mapping — the physical mechanism is replaced by an equivalent stimulus (e.g. a real road profile replaced by a synthetic road input). The record must state the equivalence argument and, ideally, a validation run comparing surrogate and physical response at the interface.

The following diagram shows how these mapping patterns coexist within a single traceability structure, with the fidelity annotations that keep the chain defensible.

Acceptance criteria that survive review

An acceptance criterion is the weakest link in most traceability chains because it is easy to write something that passes but proves nothing. Three rules keep criteria meaningful:

1. Same quantity, same unit, same limit where the mechanism is shared. If the physical test requires DTC set within 200 ms, the virtual criterion must use the same 200 ms limit and the same definition of the start event. Changing the limit "because simulation is faster" destroys comparability.
2. Explicit fidelity check where the mechanism differs. When the plant model replaces a real component, add a criterion that compares the interface signal against the physical log within a stated tolerance. This is what converts a plausible simulation into evidence.
3. Negative criteria for what must not happen. Many requirements are about absence — no false DTC, no unintended actuation, no oscillation. These must be written as explicit "shall not" conditions with observation windows, otherwise a passing run can hide a spurious event outside the logged interval.

Closing the loop: coverage reporting from the chain

Once the chain is populated, coverage reporting becomes a query rather than a manual exercise. For each test objective, the report should state: whether a physical test exists, whether a virtual scenario exists, whether the acceptance criterion has been executed and passed, and what residual (if any) remains physical-only. Objectives with a physical test but no virtual scenario are visible gaps; objectives with a virtual scenario but no fidelity check are visible risks. This is the practical payoff of traceability — it turns coverage from a claim into an auditable structure, and it makes the boundary between what simulation proves and what only physical testing can prove explicit, defensible, and stable across program reviews.