2. Neural emulator role in crash pulse prediction
In vehicle safety design, the crash pulse is the acceleration–time history measured at a structural reference point (typically the B-pillar base or rocker) during a barrier impact. It governs occupant restraint timing, airbag deployment thresholds, and the entire sled-test specification. A neural crash pulse emulator is a trained surrogate model that maps a vector of design variables — material grades, gauge thicknesses, bead patterns, joint stiffnesses — directly to the resulting pulse, replacing a full explicit finite-element (FE) simulation with a forward pass that costs milliseconds instead of hours. This chapter explains what that surrogate does, how it is built and validated, how it enables real-time and hardware-in-the-loop use, and how it reshapes design space exploration.
Why a Surrogate Is Needed
A single full-frontal LS-DYNA or PAM-CRASH run on a detailed body-in-white model with 8–12 million elements typically consumes 6–20 CPU-hours on a 64-core node. A design-of-experiments (DOE) study with 12 variables at three levels would demand thousands of runs — computationally infeasible inside a program timing window measured in weeks. The surrogate collapses this cost structure. Once trained, evaluating 10,000 candidate designs takes minutes, which changes the engineering question from "which three designs can we afford to run?" to "where is the feasible optimum, and how sensitive is it?"
The trade-off is fidelity. A surrogate is only trustworthy inside the domain it was trained on, and it inherits every bias in the training sampler. Treating it as a replacement for FE sign-off is a category error; treating it as a screening and exploration engine that feeds a small number of confirmation runs is correct practice.
Surrogate Modeling: From Design Vector to Pulse
The emulator input is a normalized design vector x ∈ R^n. Typical variables for a frontal pulse study include:
- Front rail gauge (e.g., 1.4–2.2 mm) and yield strength (340–780 MPa)
- Shotgun and apron reinforcement thickness
- Bumper beam section height and material grade
- Crash box trigger geometry (bead depth, notch radius)
- Powertrain mount stiffness and cradle tie-bar layout
- Mass scaling factor and added mass (battery pack, powertrain)
The output is not a scalar but a curve. Two representations dominate. The first discretizes the pulse into m time samples (commonly 2 ms spacing over 0–150 ms, so m = 76) and regresses each sample, giving a multi-output model. The second projects each pulse onto a low-dimensional basis — principal component analysis (PCA) or a cubic B-spline with 8–12 control points — and regresses the coefficients. The basis approach is usually preferred because it enforces smoothness and reduces the effective output dimension from 76 to roughly 10, which materially improves generalization with limited training data.
Model families in current practice include Gaussian process regression (excellent uncertainty estimates, poor scaling beyond ~2,000 samples), polynomial chaos expansion (efficient when the response is smooth in the inputs), and neural networks — multilayer perceptrons or temporal convolutional networks — which handle 10–30 inputs and thousands of samples well. A practical hybrid is a neural network that predicts PCA coefficients, with a Gaussian process on the residual for uncertainty quantification.
Validation Criteria That Matter
Aggregate error metrics such as RMSE over the whole curve are misleading, because the pulse's engineering content is concentrated in a few features. Validate against these instead:
| Metric | Definition | Typical acceptance |
|---|---|---|
| Peak acceleration error | |a_peak,pred − a_peak,FE| / a_peak,FE | < 5% |
| Time-to-peak error | |t_peak,pred − t_peak,FE| | < 3 ms |
| Pulse duration error | Deviation in the 5 g crossing time | < 5 ms |
| Velocity change error | |∫a dt − Δv_target| / Δv_target | < 2% |
| Curve correlation | Pearson r over 0–150 ms | > 0.97 |
The velocity-change check is non-negotiable: a pulse that integrates to the wrong Δv is physically inconsistent regardless of how well it matches the shape. Always verify it before accepting a surrogate.
Real-Time Simulation and HIL
Once validated, the emulator's millisecond inference latency unlocks two capabilities that FE cannot provide. The first is hardware-in-the-loop (HIL) restraint testing: the emulator runs on the real-time target, receives the current design state, and streams a pulse to the sled controller or airbag ECU at 1 kHz. This lets engineers evaluate restraint calibration against thousands of pulse variants without a physical sled. The second is driver-in-the-loop and occupant-simulation coupling, where the pulse must update within the 10–20 ms budget of the co-simulation step.
Latency budget matters. A 12-input MLP with two hidden layers of 128 units executes in well under 1 ms on a modern x86 core, but the surrounding pipeline — input normalization, PCA reconstruction, output filtering — can dominate. Profile the full chain, not just the network. If the emulator is deployed via a Python runtime, expect 5–15 ms overhead; a compiled C++ or ONNX Runtime deployment typically achieves 0.3–1 ms end-to-end.
Design Space Exploration
With a fast surrogate, the exploration workflow shifts. A typical loop:
- Sample 50,000–200,000 design points across the variable bounds using Sobol or a space-filling criterion.
- Evaluate all points through the emulator, recording predicted pulse features (peak, time-to-peak, Δv) and the uncertainty estimate.
- Filter to the feasible region: peak acceleration below the occupant injury threshold, Δv within target, mass below the program budget.
- Rank by a scalarized objective (e.g., minimize mass subject to pulse constraints) and extract the Pareto front.
- Select 3–5 designs spanning the front and run full FE confirmation.
Sensitivity analysis falls out of the same data. By computing partial derivatives of the predicted peak acceleration with respect to each input — or by training a gradient-boosted model on the surrogate outputs — you can rank variables by influence. In a typical frontal pulse study, front rail gauge and yield strength dominate, followed by added mass; bead geometry matters mainly for the early-time trigger. This ranking tells the CAE team where to spend their remaining FE budget.
Practical Failure Modes
Three problems recur. First, training data contamination: FE runs that terminate early or exhibit hourglassing produce non-physical pulses. Filter by checking energy balance and termination status before adding to the training set. Second, mode collapse in the basis: if the PCA is fit on pulses that all share a similar shape, the basis cannot represent a genuinely different crash mode (e.g., a design that triggers a different collapse sequence). Inspect the reconstruction error on held-out pulses; if it exceeds 8%, the basis is too narrow. Third, overfitting to the DOE: a model with low training error but poor leave-one-out cross-validation error will fail in exploration. Always hold out 15–20% of runs and report cross-validated metrics, not training metrics.
The emulator is a lens, not a verdict. Used correctly — trained on clean data, validated against feature-level criteria, deployed with uncertainty, and confirmed by FE — it compresses a design cycle from months to days while keeping the engineer in control of the final decision.