3. Crash sensing and event data

Airbag and seatbelt restraint tuning is fundamentally a data-driven activity. Before a calibration engineer can decide whether a deployment threshold is too aggressive or a pretensioner fires too late, the system must first see the crash correctly. This chapter examines the sensing chain that produces the raw evidence for tuning: the accelerometers and safing sensors that generate signals, the crash pulse that those signals represent, and the acquisition and conditioning practices that turn noisy electrical output into trustworthy event data.

From Physical Event to Digital Signal

A frontal crash is a rapid deceleration of the vehicle body. The restraint control module (RCM) measures this through one or more accelerometers, typically a central tunnel-mounted main sensor plus satellite sensors at the B-pillars or front rails. Each accelerometer is a MEMS capacitive element whose proof mass deflects under acceleration, producing a differential capacitance that an ASIC converts to an analog voltage and then to a digital value sampled at a fixed rate. Typical automotive crash sensors sample at 1–10 kHz; a common configuration is 2 kHz for the main channel with higher-rate satellite channels for early discrimination.

Two conventions must be fixed before any tuning discussion. First, the sign convention: acceleration is normally defined positive in the vehicle's forward direction, so a frontal impact produces a large negative longitudinal acceleration (deceleration). Second, the reference frame: sensor output is in the sensor's own axis, and mounting orientation must be documented so that a −40 g reading on a satellite is not mistaken for a positive pulse. Every calibration file and every plot in this course uses forward-positive, deceleration-negative unless stated otherwise.

Alongside the main accelerometer, most systems include a safing sensor — a mechanical or independent electronic switch that must close before deployment is enabled. The safing function is a deliberate redundancy: it prevents a single faulty main sensor from commanding deployment. In tuning terms, the safing threshold and its timing relative to the main sensor's discrimination window are themselves calibration parameters, and they must be validated against the same crash pulse data used for the main algorithm.

Characterizing the Crash Pulse

The crash pulse is the time history of vehicle deceleration during impact. It is not a single number but a shape, and the shape determines what the restraint system can and cannot do. Engineers characterize it with several descriptors:

• Peak deceleration — the maximum magnitude, often 30–60 g in a 50 km/h rigid barrier test, but highly dependent on structure and test mode.
• Pulse duration — the time from impact to the point where deceleration returns near zero, typically 80–150 ms for a full frontal event.
• Time to peak — how quickly the pulse rises; a short time-to-peak demands faster discrimination and earlier deployment decisions.
• Delta-v (Δv) — the integral of deceleration over time, representing the velocity change. A 50 km/h barrier test yields roughly 50 km/h Δv, and the Δv curve is often the most robust discriminator between severities.
• Energy or crush proxy — derived quantities such as the integral of squared acceleration, used to separate high-energy from low-energy events.

These descriptors are computed from the acquired signal, so the quality of acquisition directly limits the quality of characterization. A pulse sampled at 500 Hz will alias the high-frequency content that distinguishes a pole impact from a soft barrier hit; a pulse with an unremoved DC offset will produce a drifting Δv integral that never returns to zero.

Acquisition and Conditioning Practice

Crash test data acquisition typically uses a standalone data logger synchronized with the vehicle's event trigger, sampling accelerometers, seatbelt load cells, pressure sensors, and video at a common time base. The practical workflow for tuning-grade data is:

1. Verify channel integrity before the test. Check sensor zero offsets with the vehicle stationary; a main sensor reading more than ±0.5 g at rest indicates a mounting or calibration problem.
2. Record raw and filtered channels. Keep the unfiltered signal for forensic review and apply the standard channel filter (commonly a 4-pole Butterworth low-pass at 100–300 Hz, per the applicable SAE J211 class) for algorithm evaluation.
3. Confirm the trigger and time zero. The event trigger should be derived from a known physical event (e.g., barrier contact switch) so that all channels share a defensible t = 0.
4. Integrate to Δv with drift correction. Numerically integrate the filtered deceleration and apply a baseline correction so that Δv returns to zero after the event; residual drift indicates offset or integration error.
5. Export a tuning dataset. Store the conditioned pulse, its descriptors, and the test metadata (mode, speed, barrier type, sensor locations) in a form the calibration tool can ingest.

Consider a worked example. A 50 km/h full frontal rigid barrier test produces a main-channel pulse with a peak of −42 g at 38 ms, a duration of 110 ms, and an integrated Δv of 49.6 km/h. The residual Δv after baseline correction is 0.3 km/h, which is acceptable. A second test at 25 km/h produces a peak of −18 g at 52 ms and Δv of 24.8 km/h. The tuning question is whether the algorithm's discrimination window separates these two cleanly; the data above shows a clear separation in both peak and Δv, so a threshold placed between them is defensible — but only if the acquisition was clean enough to trust the numbers.

Reading the Sensing Chain as a Whole

The figure below traces the path from physical impact through sensor, conditioning, and characterization to the tuning dataset. It is deliberately a signal-chain view rather than a process checklist: the point is to show where each tuning-relevant quantity originates and where acquisition errors enter.

The chain makes one point explicit: the tuning dataset is not the physical crash, it is a conditioned representation of it. Every filter, offset correction, and trigger decision is a modeling choice. When a calibration behaves unexpectedly in a new test mode, the first diagnostic question is not "is the threshold wrong?" but "was the pulse represented faithfully?" A drifting Δv, an aliased peak, or a misaligned t = 0 will each produce a plausible-looking but misleading dataset, and thresholds tuned against it will not generalize.

Practical Data-Quality Checks

Before a pulse enters the tuning dataset, run a short acceptance check. Confirm the stationary zero offset is within tolerance. Confirm the filtered and raw peaks differ by a documented, expected amount. Confirm the Δv integral returns to within a small residual after the event. Confirm the trigger time is consistent across channels. Confirm the test metadata — mode, speed, barrier, sensor locations, filter class — is attached. A pulse that fails any of these checks should be flagged, not silently averaged into the dataset. In practice, a small number of rejected tests with clear reasons is far more valuable than a large dataset of unverified pulses, because the calibration engineer needs to know which evidence is trustworthy when a deployment decision is challenged.

With a clean, characterized dataset in hand, the next step is to use it: comparing pulses across severities, locating the discrimination window, and setting thresholds that separate deploy from no-deploy events with margin. That work depends entirely on the sensing and acquisition discipline described here — the algorithm can only be as good as the signal it is tuned against.