4. Signal preprocessing for CORA

CORA (Correlation and Analysis) does not compare raw signals directly. Before any corridor, cross-correlation, or metric computation runs, both the test and CAE curves pass through a preprocessing chain that determines whether the subsequent rating is meaningful or misleading. A well-correlated physical response can still score poorly if the two curves are sampled at different rates, offset by a few milliseconds, or carry different DC bias. Conversely, aggressive preprocessing can artificially inflate a CORA score by smoothing away real discrepancies. This chapter covers the three preprocessing operations that dominate practical CORA workflows — filtering, time alignment, and normalization — and explains how to apply them reproducibly.

Why preprocessing is part of the rating, not a cosmetic step

CORA decomposes correlation into a phase (progression) component and a magnitude (corridor) component, each weighted by user-defined weights. Both components are sensitive to preprocessing choices:

• Filtering changes the frequency content that enters the corridor width and the cross-correlation. Low-pass filtering removes test noise but also removes genuine high-frequency CAE content; the cutoff must be justified by the physical bandwidth of interest, not chosen to improve the score.
• Time alignment directly controls the phase/progression metric. A constant time shift of even 2–3 ms on a chest acceleration pulse can move the progression rating by a full grade.
• Normalization (amplitude scaling, DC removal, sign convention) affects the magnitude metric and the corridor tolerance interpretation. Mixing normalized and unnormalized curves between test and CAE invalidates the comparison.

The governing principle is symmetry: whatever operation is applied to the test signal must be applied identically to the CAE signal, and the operation must be documented so the rating is reproducible. CORA itself provides preprocessing options (filter type, filter order, cutoff frequency, time-shift search window, normalization mode), and the chosen settings belong in the correlation report alongside the score.

Filtering: matching bandwidth before comparison

Airbag and restraint signals — chest acceleration, head acceleration, belt force, airbag pressure — are typically acquired at 10 kHz or higher in test and exported at 1–10 kHz from CAE. The first filtering decision is the cutoff frequency. A common convention is to low-pass both signals at a cutoff consistent with the occupant-response bandwidth of interest (often 300–1000 Hz for accelerations, lower for belt forces). The cutoff should be stated explicitly; CORA's default filter settings are a starting point, not a universal answer.

Two practical rules apply. First, use the same filter type and order on both channels — a 4th-order Butterworth applied to test but a 2nd-order applied to CAE introduces a phase and amplitude mismatch that the correlation will attribute to the model. Second, apply the filter forward-backward (zero-phase) where the tool supports it, so the filter does not introduce a group delay that masquerades as a time shift. If only a causal forward filter is available, the resulting delay must be accounted for before time alignment, otherwise the alignment step will "correct" a filter artifact and distort the phase metric.

Time alignment: separating physical lag from acquisition offset

Time alignment has two distinct jobs that are often conflated. The first is removing a known acquisition or export offset — for example, a trigger delay, a channel-specific t=0 definition, or a CAE output written on a different time base. This is a deterministic correction and should be applied first. The second is estimating the residual physical lag between the responses, which is itself a quantity of interest: an airbag that inflates 5 ms late is a real modeling error, not a preprocessing nuisance.

CORA's progression metric uses a time-shift search to find the lag that maximizes correlation, within a user-defined window. The window matters. Too narrow and a genuine lag is clipped, flattering the model; too wide and the search can lock onto a secondary peak (for example, matching the rebound phase of one curve to the loading phase of another). A defensible workflow is:

1. Remove any known deterministic offset from the CAE channel so both curves share a common t=0 definition.
2. Run the CORA time-shift search with a window sized to the expected physical tolerance (e.g., ±10 ms for restraint forces, ±5 ms for accelerations), and record the reported shift.
3. Inspect the shift against engineering expectation. A shift at the edge of the window is a signal that the window, not the model, is controlling the result.
4. Only if the shift is a known, documented acquisition artifact should it be removed before rating; a physical lag should be reported, not erased.

For multi-channel evaluations (head, chest, pelvis, belt), alignment is per-channel. Applying a single global shift across all channels hides channel-specific lags and is a common source of inflated overall scores.

Normalization: amplitude, offset, and sign convention

Normalization covers three separate operations that are easy to blur together:

For most restraint evaluations, no amplitude normalization should be applied: the absolute magnitude is part of what CORA is meant to assess, and the corridor width is defined in physical units. Amplitude normalization is appropriate only when the question is purely shape-related (e.g., comparing a normalized belt force profile across different pretensioner settings). DC offset removal is almost always appropriate for accelerations, where integration and sensor bias accumulate; it should be applied identically to both channels. Sign convention must be fixed before any correlation run and stated in the report — a flipped sign is the single most common cause of a "model that looks completely wrong" that is actually a preprocessing error.

Putting the chain together: a reproducible example

Consider a driver-side frontal evaluation with four channels: head X acceleration, chest X acceleration, pelvis X acceleration, and shoulder belt force. The test data are exported at 10 kHz; the CAE output is at 1 kHz. A reproducible preprocessing sequence is:

# Per channel, applied identically to test and CAE
1. Resample both to a common rate (e.g., 1 kHz) using zero-order hold or
   anti-aliased decimation — never naive sample dropping.
2. Low-pass filter: Butterworth, 4th order, 600 Hz, zero-phase.
3. Remove known deterministic offset (trigger delay, t=0 definition).
4. CORA time-shift search: window ±10 ms (forces), ±5 ms (accelerations).
5. DC offset removal on accelerations; sign convention verified (+X forward).
6. No amplitude normalization; corridor width in physical units.
7. Record (filter tuple, shift window, reported shift, normalization mode)
   in the correlation report.

Expected observable outcomes: the reported per-channel shifts should be small and physically plausible (a few milliseconds), the filtered curves should retain the loading and rebound peaks without visible ringing, and the corridor metric should reflect genuine amplitude differences rather than offset or sign errors. Typical failure symptoms and their causes:

• Progression score near zero despite visually similar curves — likely a sign flip or a shift search that locked onto a secondary peak; check sign convention and narrow the window.
• Corridor metric uniformly poor across all channels — suspect a DC offset applied to only one side, or mismatched units between test and CAE.
• Shift reported at the window edge — the window is controlling the result; widen it or investigate a real modeling lag.
• High-frequency oscillation in the filtered curve — filter order too high for the cutoff, or forward-only filtering introducing phase distortion; switch to zero-phase or lower the order.

The preprocessing chain is therefore not a preamble to the rating; it is the first half of the rating. Filtering defines what frequency content is being judged, time alignment defines what phase relationship is being judged, and normalization defines what amplitude relationship is being judged. Fix all three symmetrically, document them with the score, and the CORA result becomes a defensible statement about the model rather than an artifact of the tool settings.