4. Corridor selection criteria

Once a candidate set of correlation corridors has been generated — whether from historical incident traces, simulation sweeps, or expert elicitation — the engineering problem shifts from generation to selection. A corridor is only useful if it can be defended against four competing pressures: it must catch the safety-relevant responses it was designed for, it must not fire on benign behavior, it must keep working when the operating envelope drifts, and it must fit inside the compute budget of the target ECU. These four pressures are not independent, and treating them as a single "score" is the most common source of bad corridor decisions. This section defines each metric operationally, shows how to compute it from a labeled response set, and explains how to combine them into a defensible selection rule.

Coverage: What the Corridor Actually Catches

Coverage answers a single question: of all safety-relevant responses that should be detected, what fraction does the corridor actually flag? Formally, for a labeled evaluation set with N_pos positive (safety-relevant) events, coverage is the ratio of true positives to N_pos. The subtlety is that "positive" must be defined at the level of the response, not the raw signal. A corridor that triggers on a transient spike but misses the sustained deviation that actually precedes the hazardous event has high signal-level coverage and near-zero response-level coverage.

In practice, coverage should be reported per operating region rather than as a single global number. A corridor tuned on highway cruise data may show 0.94 global coverage while achieving only 0.61 coverage in low-speed parking maneuvers — precisely the region where the safety response matters most. The recommended practice is a coverage matrix indexed by operating region and by response class, so that weak cells are visible before selection rather than after deployment.

False-Positive Rate: The Cost of Being Wrong

False-positive rate (FPR) is the fraction of benign events incorrectly flagged. It is the metric that most directly determines whether a corridor survives production, because a corridor with a 2% FPR on a signal sampled at 100 Hz will generate roughly two spurious triggers per second — enough to desensitize downstream logic or trip a diagnostic trouble code. FPR should be measured on a benign-only holdout set that is statistically independent of the tuning set; reusing tuning data to estimate FPR systematically understates it.

Two refinements matter. First, distinguish event-level FPR (did any trigger occur during a benign episode?) from sample-level FPR (what fraction of samples exceeded the corridor?). Event-level FPR is the operationally meaningful figure for response gating; sample-level FPR is useful for tuning the corridor width. Second, report FPR with a confidence interval. With only 200 benign episodes, an observed FPR of 0.5% has a 95% upper bound near 2.7% — a corridor that looks acceptable on point estimate may be unacceptable on the bound.

Robustness: Behavior Under Drift and Perturbation

Robustness captures how much the corridor's coverage and FPR degrade when the input distribution shifts. Three perturbation families are worth measuring explicitly: signal-level (sensor noise, quantization, sample-rate jitter), environmental (temperature, load, road surface), and temporal (aging of components, firmware version changes). A practical robustness score is the worst-case coverage retention across a defined perturbation grid:

robustness = min over perturbations p of ( coverage(p) / coverage(baseline) )

A corridor with robustness 0.95 keeps at least 95% of its baseline coverage under every tested perturbation. Values below roughly 0.85 usually indicate the corridor is over-fitted to a narrow operating point and should be widened or re-parameterized. Robustness is expensive to measure because it multiplies the evaluation set by the perturbation grid, so it is typically computed on a stratified subsample rather than the full set.

Computational Overhead: Fitting the Budget

Overhead is the cost of evaluating the corridor per sample, expressed in cycles, memory footprint, and worst-case latency. For a corridor defined as a band around a reference trajectory with K breakpoints, the per-sample cost is dominated by interpolation and comparison; a typical embedded implementation runs in the low hundreds of cycles, but a corridor with per-region adaptive widths and hysteresis can easily exceed the budget of a 1 ms control loop. Overhead must be measured on the target, not estimated from a desktop prototype — cache behavior and floating-point support change the answer by an order of magnitude.

The selection rule should treat overhead as a hard constraint rather than a soft score. A corridor that exceeds the worst-case execution time budget is disqualified regardless of its coverage, because a late trigger is functionally equivalent to a missed one in most safety responses.

Combining the Metrics: A Selection Procedure

The four metrics form a constrained optimization, not a weighted sum. The recommended procedure is: (1) filter out corridors whose worst-case overhead exceeds the budget; (2) filter out corridors whose event-level FPR upper confidence bound exceeds the acceptable limit for the response class; (3) among survivors, rank by coverage subject to a minimum robustness floor (e.g., 0.85); (4) break ties by lower overhead. This ordering reflects the asymmetry of consequences: a missed safety response is usually worse than a slightly higher compute cost, but an unstable corridor is worse than a slightly lower coverage.

Worked Example: Selecting Among Three Corridors

Consider three candidate corridors evaluated on a labeled set of 1,200 safety-relevant events and 4,000 benign episodes, with a worst-case execution budget of 400 cycles per sample. The measured values are illustrative and would need to be reproduced on the actual target:

Applying the procedure: C3 is disqualified at Filter 1 because its 520-cycle WCET exceeds the 400-cycle budget. C2 passes Filter 1 but its FPR upper bound of 4.2% exceeds a 2% class limit, so it is disqualified at Filter 2. C1 survives both filters with coverage 0.88 and robustness 0.91, and is selected. Note that C2 has the highest raw coverage — a naive ranking by coverage alone would have selected the corridor most likely to desensitize the downstream response. The filter ordering is what prevents that outcome.

Common Pitfalls in Metric Definition

• Estimating FPR on tuning data. This systematically understates the true rate; always hold out an independent benign set.
• Reporting coverage as a single global number. Region-stratified coverage exposes weak cells that a global average hides.
• Treating robustness as optional. A corridor that passes on the nominal dataset but drops below 0.85 under temperature drift will fail in the field, not in the lab.
• Estimating overhead on a desktop. Cache and FPU differences between host and target routinely change the measured cost by 5–10×.
• Averaging the four metrics into one score. This hides the hard constraints and lets a high-coverage corridor with unacceptable FPR win on arithmetic.

The selection criteria defined here are the contract between corridor generation and corridor deployment. Once coverage, FPR, robustness, and overhead are measured on a common labeled set with a fixed filter ordering, corridor selection becomes a reproducible engineering decision rather than a judgment call — and the resulting corridor can be defended in a safety case with numbers rather than assertions.