3. Data acquisition and preprocessing for restraint design

Explainable models for restraint design are only as trustworthy as the data pipeline feeding them. A restraint system — whether a vehicle seatbelt and airbag package, a child safety seat, or an occupant-protection harness in an aircraft or industrial machine — is validated through a combination of physical sensor measurements and simulation outputs. The explainability requirement adds a constraint that ordinary machine-learning pipelines often ignore: every feature entering the model must remain traceable to a physical quantity, a sensor location, and a documented transformation. If a feature cannot be explained to a safety engineer in physical terms, it cannot support a defensible design decision.

This section covers the three data sources that dominate restraint design work, the preprocessing steps that make them comparable, and the feature engineering patterns that keep models interpretable without sacrificing predictive power.

Sensor Data: Sled Tests, Dummies, and On-Body Instrumentation

The primary empirical source is the crash sled or drop-tower test, instrumented with anthropomorphic test devices (ATDs) and additional on-body sensors. Typical channels include:

• Accelerometers at the sled buck, seat frame, and ATD head, chest, and pelvis, sampled at 10–20 kHz to capture the high-frequency content of the crash pulse.
• Load cells in seatbelt webbing (belt force) and in the seat cushion or anchor points.
• Potentiometers and string pots for belt payout and occupant excursion.
• Pressure sensors in airbag inflators and, in some setups, in the seat cushion for occupant detection.

Raw channels are rarely usable directly. The first preprocessing step is channel alignment: all channels must share a common time zero, usually defined by the sled trigger or a contact switch. A common failure symptom is a belt-force curve that appears to rise before the sled pulse begins — almost always a trigger offset of a few milliseconds, not a physical effect. Cross-correlating the sled accelerometer with the belt load cell and correcting the lag resolves it.

The second step is filtering. Crash signals are conventionally low-pass filtered per SAE J211 (Channel Frequency Class 60 for most occupant channels, CFC 180 or 1000 for accelerometers where high-frequency content matters). Applying the wrong CFC class changes peak values measurably; document the class used for every channel, because a model trained on CFC 60 data will not transfer to CFC 180 inputs.

The third step is segmentation and normalization. Each test yields a time series of varying duration. For feature extraction, segment the window from trigger to occupant rebound (typically 0–200 ms) and resample to a fixed rate, for example 1 kHz, using anti-aliased decimation. Normalize amplitudes only when physically justified — for instance, expressing belt force per unit occupant mass — and record the normalization factor as metadata so predictions can be inverted to engineering units.

Simulation Outputs: Finite Element and Lumped-Parameter Models

Physical tests are expensive and sparse; simulation fills the design space. Restraint design typically uses explicit finite element models (LS-DYNA, PAM-CRASH, Radioss) of the occupant and restraint, or faster lumped-parameter models for early trade studies. Simulation outputs mirror sensor channels — nodal accelerations, belt element forces, contact pressures — but carry additional metadata that must be preserved: solver version, mesh density, material card revisions, and contact definitions.

Two preprocessing issues dominate. First, sampling and filtering consistency: FE output is often written at the integration time step or at a coarse output interval. Resample simulation channels to the same 1 kHz grid and apply the same CFC filter as the test data, otherwise a model trained on mixed sources learns the filter difference rather than the physics. Second, correlation and bias correction: simulation systematically under- or over-predicts certain channels. Compute a per-channel correction factor from paired test–simulation runs and store it as an explicit, auditable transform rather than silently rescaling the data.

Feature Engineering for Explainable Models

Explainability is largely decided at feature-construction time. Raw time series are opaque to most interpretable model families; hand-crafted features with physical meaning are not. The table below summarizes a practical feature set for a belt-force and head-acceleration channel pair, with the physical interpretation that makes each feature defensible.

Derived features should be computed by a versioned, tested function — not ad hoc in a notebook — so that any prediction can be traced back through the exact transformation. A useful pattern is to store, alongside each feature vector, a JSON record of the source file, channel, filter class, and feature-function version. When an engineer asks "why did the model flag this design?", the answer can then cite the peak belt force and its rise rate with their physical units, not an anonymous embedding index.

Interaction features deserve caution. Products such as belt force × occupant mass, or ratios such as head excursion divided by available clearance, are physically meaningful and improve interpretability. Arbitrary polynomial expansions of many channels are not: they inflate dimensionality, obscure attribution, and make SHAP or partial-dependence explanations unreadable. Prefer a small set of physically motivated interactions, each documented with a one-line rationale.

Worked Example: Building a Traceable Feature Set

Consider a paired dataset of 40 sled tests and 200 FE runs varying load-limiter force (2.5–4.5 kN) and pretensioner stroke (40–80 mm). A reproducible pipeline proceeds as follows. Load each channel with its metadata; align to the trigger; apply CFC 60 filtering to belt force and CFC 180 to head acceleration; resample to 1 kHz; segment 0–200 ms. Compute the six features in the table above using a versioned function, and attach the provenance record. Then split by test configuration — not by individual run — so that the same design does not appear in both training and validation sets.

Verification is straightforward and should be done before any model is trained. Plot the reconstructed belt-force curve from the stored features against the filtered original; the peak and time-to-peak should match to within one sample. Check that the distribution of peak belt force for simulation runs, after bias correction, overlaps the test distribution rather than sitting in a separate cluster. If the two distributions remain separated, the correction factor is wrong or a filter class was mismatched — a common symptom is a simulation cluster shifted by a constant offset, which points to a normalization error rather than a physics discrepancy.

The output of this stage is not merely a feature matrix. It is a feature matrix plus a provenance record per row, a documented filter and resampling policy, an explicit test–simulation correction, and a small set of physically named features. That combination is what allows the explainable model in later chapters to attribute a restraint design decision to a measurable quantity — peak belt force, rise rate, head excursion — rather than to an opaque coordinate in a learned space.