3. Quality assurance fundamentals for crash simulation
Crash simulation quality assurance rests on four measurable pillars: accuracy, robustness, repeatability, and reproducibility. These terms are often used interchangeably in engineering discussions, but they answer fundamentally different questions. Accuracy asks whether the model matches physical reality. Robustness asks whether the solution survives perturbations in inputs and solver conditions. Repeatability asks whether the same analyst, same model, and same hardware produce identical results across runs. Reproducibility asks whether a different analyst, different hardware, or different software version can arrive at the same conclusion. A model that is accurate but not repeatable cannot be trusted for design decisions; a model that is repeatable but not accurate is merely consistently wrong.
Accuracy: Correlation with Physical Tests
Accuracy in crash simulation is quantified through correlation metrics against physical test data. The most common metrics include peak force error, intrusion error, energy absorption error, and time-history correlation coefficients. For a frontal impact simulation, a typical acceptance criterion might require peak deceleration within ±10% of the sled test, maximum intrusion within ±5 mm, and a CORrelation metric (COR) above 0.85 for the occupant compartment acceleration pulse.
Consider a full-frontal rigid barrier test at 56 km/h. The physical test records a peak B-pillar acceleration of 42.3 g at t = 68 ms. The simulation predicts 39.8 g at t = 71 ms. The peak error is (39.8 − 42.3) / 42.3 = −5.9%, which passes a ±10% criterion. However, the time-to-peak error is 3 ms, which may exceed a ±2 ms requirement. This illustrates that accuracy is multi-dimensional: magnitude, timing, and pulse shape all matter. A common composite metric is the ISO/TS 18571 objective rating scheme, which combines corridor, phase, and magnitude scores into a single normalized value.
Example correlation calculation (ISO/TS 18571 simplified):
Given:
Test curve: a_test(t), peak = 42.3 g at t = 68 ms
Sim curve: a_sim(t), peak = 39.8 g at t = 71 ms
Step 1 — Magnitude score:
ratio = 39.8 / 42.3 = 0.941
magnitude_score = 1 - |1 - 0.941| = 0.941
Step 2 — Phase score:
dt = |71 - 68| = 3 ms
phase_score = max(0, 1 - 3/10) = 0.700
Step 3 — Corridor score (assume 90% of points inside corridor):
corridor_score = 0.900
Composite = 0.5*magnitude + 0.25*phase + 0.25*corridor
= 0.5*0.941 + 0.25*0.700 + 0.25*0.900
= 0.4705 + 0.1750 + 0.2250 = 0.8705
Interpretation: composite ≥ 0.85 is typically "good"; 0.70–0.85 requires engineering review; below 0.70 indicates the model needs rework.
Robustness: Stability Under Perturbation
Robustness measures how sensitive the simulation is to small, legitimate variations in inputs. These variations include mesh density changes, time-step size, contact stiffness, material parameter scatter, and initial velocity tolerances. A robust model produces results that remain within acceptable bounds when these inputs vary within their specified tolerances.
A practical robustness test is a one-factor-at-a-time (OFAT) perturbation study. For a side impact model, you might vary the following:
- Mesh size at the B-pillar: 5 mm, 6 mm, 7 mm
- Strain-rate scaling factor for DP600: 0.9, 1.0, 1.1
- Contact thickness offset: 0.8 mm, 1.0 mm, 1.2 mm
- Initial velocity: 50.0 km/h, 50.5 km/h, 51.0 km/h
For each perturbation, record the peak intrusion and the maximum plastic strain. If the coefficient of variation (CV = standard deviation / mean) exceeds 5% for any critical response, the model is considered sensitive and requires either tighter input controls or a more robust modeling approach (e.g., adaptive remeshing, penalty stiffness tuning).
Repeatability: Same Input, Same Output
Repeatability is the tightest form of consistency: running the identical deck on the identical solver build on the identical hardware should produce bitwise-identical or numerically negligible differences. In explicit finite element solvers such as LS-DYNA or Radioss, non-repeatability typically arises from:
- Non-deterministic parallel reduction order in multi-threaded runs
- Randomized contact search algorithms
- Floating-point accumulation differences across core counts
- Adaptive time-step adjustments triggered by transient conditions
A repeatability test protocol runs the same model five times with identical settings and computes the maximum relative difference in key outputs. For a typical vehicle model, a repeatability threshold of 0.1% on peak force and 0.05 mm on intrusion is achievable with deterministic solver settings. If differences exceed 1%, the solver configuration or hardware environment must be investigated.
Reproducibility: Different Environment, Same Conclusion
Reproducibility is the most demanding requirement because it spans different analysts, different hardware, and potentially different software versions. It is assessed through round-robin studies or blind predictions. In a round-robin, multiple teams receive the same CAD, material data, and test setup, then independently build and run the simulation. The spread of their results defines the reproducibility envelope.
A reproducibility metric commonly used in automotive OEMs is the normalized standard deviation across teams:
For N teams, each reporting peak intrusion x_i:
mean = (1/N) * sum(x_i)
std = sqrt( (1/(N-1)) * sum((x_i - mean)^2) )
reproducibility_index = std / mean
Target: reproducibility_index < 0.05 for peak intrusion
reproducibility_index < 0.08 for peak force
If the reproducibility index exceeds these thresholds, the root cause is usually ambiguous modeling guidelines rather than solver differences. Common culprits include inconsistent spotweld representations, different hourglass control settings, and varying material card choices for the same alloy.
Practical QA Protocol and Acceptance Gates
The four pillars are operationalized through a staged verification protocol. The following table summarizes a representative acceptance gate structure used in a production crash simulation program. All thresholds are illustrative and should be calibrated to the specific vehicle program and regulatory requirements.
| QA Dimension | Metric | Typical Threshold | Verification Method | Failure Action |
|---|---|---|---|---|
| Accuracy | Peak force error | ≤ ±10% | Test-sim overlay | Review material card |
| Accuracy | ISO/TS 18571 composite | ≥ 0.85 | Automated correlation script | Adjust contact / mesh |
| Robustness | CV of peak intrusion | ≤ 5% | OFAT perturbation (3 levels) | Tighten input tolerance |
| Repeatability | Max relative difference | ≤ 0.1% | 5 identical runs | Check solver determinism |
| Reproducibility | Cross-team index | ≤ 0.05 | Round-robin (≥3 teams) | Update modeling guidelines |
Common pitfall: Teams often conflate repeatability with reproducibility. A model can be perfectly repeatable on one workstation but fail reproducibility across sites due to different solver patch levels or compiler optimizations. Always document the exact solver version, hardware architecture, and thread count in the QA report.
Diagnosing Failures: Symptom-to-Cause Mapping
When a QA gate fails, the symptom pattern points to the root cause. High repeatability error with low accuracy error suggests a solver or hardware issue. High robustness sensitivity with acceptable accuracy suggests the model is tuned too tightly to one configuration. High reproducibility spread with good repeatability suggests ambiguous modeling guidelines. The following diagnostic sequence is recommended:
- Isolate the dimension: Run the repeatability test first. If it fails, no other QA metric is meaningful until the solver environment is stabilized.
- Check determinism settings: In LS-DYNA, set
*CONTROL_TERMINATIONwith fixedDTMINand disable adaptive time-stepping if not physically required. In Radioss, use/DT/NODA/CSTwith a fixed time step. - Quantify sensitivity: If repeatability passes but robustness fails, run a screening DOE (e.g., Plackett-Burman) to identify which input drives the variance.
- Audit guidelines: If reproducibility fails, compare the modeling decks from each team. Differences in spotweld definitions, contact thickness, or hourglass energy are the most frequent causes.
Quality assurance in crash simulation is not a one-time check; it is a continuous discipline. Every model update, every solver upgrade, and every new analyst joining the team is an opportunity for quality drift. The four pillars provide the measurement framework, but the governance process — documented guidelines, version-controlled decks, and automated regression suites — provides the enforcement mechanism. Without both, simulation results become opinions rather than engineering evidence.