4. Sensing and discrimination algorithms

An airbag ECU does not fire an airbag because it "detects a crash." It fires because a chain of signal processing, integration, and threshold comparison has concluded that a specific, sufficiently severe impact has occurred, and that conclusion has been independently confirmed by a second, slower decision path. This chapter examines that decision chain: how raw accelerometer signals become a severity estimate, how velocity change (Δv) is integrated from acceleration, and how the two-tier architecture of primary and safing thresholds prevents both missed deployments and spurious ones.

From Acceleration to Severity: The Signal Chain

The front airbag ECU typically carries a primary accelerometer in the passenger compartment (often on the tunnel or under the center console) and may use satellite sensors at the front crush zone. The primary sensor measures longitudinal deceleration in the vehicle frame. By convention used throughout this course, the positive axis points forward in the direction of travel, so a frontal impact produces a negative longitudinal acceleration. All thresholds and integrals below are stated in that convention; if a datasheet uses the opposite sign, the comparison logic must be inverted consistently.

Raw acceleration is not used directly. The signal passes through an anti-alias filter, then a band-pass or low-pass crash filter that removes road-induced vibration (typically above 200–400 Hz) while preserving the crash pulse energy (roughly 0–150 Hz for a frontal event). The filtered signal feeds two parallel computations: a severity metric and a velocity change integral.

Severity estimation is not a single number. Production algorithms combine several features computed over a moving window: filtered acceleration amplitude, the integral of acceleration (Δv), jerk (rate of change of acceleration), and sometimes a "crash energy" measure such as the integral of acceleration squared. A common approach is a weighted sum or a lookup-table mapping of these features to a severity index, calibrated against sled tests at multiple impact speeds and barrier types. The severity index is then compared against a speed-dependent firing threshold.

Velocity Change Integration

Velocity change is the time integral of the filtered acceleration:

Δv(t) = ∫ a_filtered(τ) dτ   from t0 to t

In discrete firmware running at, say, 1 kHz, this becomes a running sum:

dv += a_filtered * dt;   // dt = 0.001 s
if (dv < 0) dv = 0;      // clamp: only deceleration counts toward firing

The clamp is important. Without it, a rebound phase (positive acceleration after the initial deceleration) would subtract from the accumulated Δv and could mask a genuine severe event. Most production algorithms accumulate only the negative-going contribution, or reset the integrator when the sign reverses beyond a small deadband. The integrator is also reset at ignition-on and after a defined quiet period, so that a parked vehicle with sensor bias does not slowly accumulate a false Δv.

Δv alone is a useful but insufficient severity measure. A low-speed parking-lot impact and a high-speed barrier impact can produce similar peak Δv over different durations; the shape of the pulse matters. This is why severity estimation combines Δv with amplitude and jerk features rather than relying on the integral alone.

Primary versus Safing Thresholds

The firing decision uses two independent paths. The primary (also called firing or discrimination) path runs the full severity algorithm and decides whether the event warrants deployment. The safing path is a simpler, slower, independent check that confirms a genuine crash is in progress. Deployment requires both the primary decision and the safing confirmation, typically within a defined time window.

The rationale is architectural, not just algorithmic. The primary path is tuned for timely detection and is therefore more exposed to sensor faults, EMI, and calibration errors. The safing path uses a separate sensor or a separate, heavily filtered channel with a higher threshold and a longer confirmation time. A single-point fault — a stuck sensor, a harness short, a corrupted ADC reading — is unlikely to satisfy both paths simultaneously. This is the practical implementation of fail-safe redundancy: the safing path is the "second opinion" that converts a single-channel decision into a two-channel one.

Timing matters as much as level. A typical frontal algorithm must decide within roughly 15–30 ms of impact for a 50 km/h barrier event to deploy the bag before the occupant moves into the deployment zone. The safing path must confirm within a window that still allows deployment — often 5–15 ms after the primary decision. If the safing confirmation arrives too late, the deployment is inhibited, which is why safing filter time constants are calibrated jointly with the primary path, not independently.

Worked Example: Threshold Comparison

Consider an illustrative calibration (values are representative teaching assumptions, not measured data). The primary path fires when the severity index S exceeds a speed-dependent threshold, and the safing path requires filtered acceleration to exceed 8 g sustained for 4 ms. At 30 km/h into a rigid barrier, the primary path may reach its threshold at t = 18 ms with Δv ≈ 12 km/h, while the safing channel crosses 8 g at t = 14 ms and confirms at t = 18 ms — deployment proceeds. At a 12 km/h parking impact, the primary path may briefly approach threshold but the safing channel never sustains 8 g, so deployment is correctly inhibited. The table below summarizes the decision logic.

The last row is the key diagnostic case. A stuck-high primary sensor produces a persistent high reading that the primary path may interpret as a severe crash, but the independent safing channel — fed by a different sensor or a differently filtered signal — does not confirm. The ECU sets a diagnostic trouble code and inhibits deployment. This is exactly the behavior the two-tier architecture is designed to produce.

Practical Calibration and Verification Notes

Calibration is performed against a matrix of sled and barrier tests spanning impact speeds, barrier types (rigid, deformable, offset), and occupant positions. Each test yields the acceleration trace, from which the primary and safing features are computed offline. The calibration must satisfy two constraints simultaneously: no-deploy in all must-not-fire events (low-speed, rough road, misuse) and deploy within the timing budget in all must-fire events. The margin between the two populations is the calibration's robustness envelope.

During verification, watch for these failure symptoms. If deployment is late, check whether the safing confirmation window is the limiting factor rather than the primary threshold. If spurious deployments occur on rough roads, examine the safing filter cutoff and the primary path's jerk feature — road inputs often have high jerk but low sustained Δv. If a sensor fault produces a deploy command, verify that the safing path is truly independent (separate sensor or separate signal chain) rather than a re-filtered copy of the same channel. Independence is a wiring and signal-path property, not just a software flag.

The diagram above shows the decision structure: the accelerometer feeds two independent processing paths, each with its own filter and threshold, and deployment requires both to assert within the timing window. The inhibit branch captures the fault and low-severity cases where only one path asserts. In practice, the ECU also logs the time of each assertion and the peak Δv, which are the primary data used during post-event analysis and calibration refinement.