4. Frontal impact load cases

Frontal crash load cases form the backbone of any model qualification program because they exercise the longitudinal load path, the occupant restraint system, and the structural energy-management strategy simultaneously. Within the frontal family, three configurations dominate regulatory and consumer-testing practice: the full-width rigid barrier (FRB), the offset deformable barrier (ODB), and the small overlap frontal (SOF). They are not interchangeable. Each one loads a different portion of the vehicle front end, produces a different deceleration signature, and therefore stresses a different set of model assumptions. A model that correlates well in FRB can still fail badly in SOF, and vice versa. This chapter explains what each configuration physically does to the structure, how to set it up in a simulation model, and how to judge whether the model is qualified for that case.

What each configuration actually loads

The full-width rigid barrier test drives the entire front face of the vehicle into a flat, non-deforming wall. Because the barrier does not yield, essentially all of the vehicle's kinetic energy must be absorbed by the vehicle itself, and the load is distributed across the full width of the front structure — both longitudinal rails, the bumper beam, the cradle, and the lower front bulkhead. The result is a relatively symmetric, high-magnitude, short-duration deceleration pulse. In model terms, FRB is the cleanest test of the primary longitudinal load path and of the restraint system under a severe, well-distributed pulse. It is also the most forgiving to modeling errors in the front structure because the load is shared so widely.

The offset deformable barrier test, by contrast, presents a honeycomb-faced deformable element covering only part of the vehicle width — typically 40% overlap on the driver side in the widely used protocol. The barrier deforms and absorbs a substantial fraction of the energy, while the vehicle is loaded asymmetrically. One longitudinal rail takes the brunt of the impact, the structure is forced into a combined axial-bending mode, and the vehicle yaws. This is where the model's ability to capture rail buckling, spot-weld and joint failure, and the resulting asymmetric occupant kinematics is really tested. ODB is the classic discriminator between a model that merely "looks right" in a symmetric crash and one that has genuine predictive capability.

The small overlap frontal test loads only the outer 25% of the vehicle width, outboard of the longitudinal rail. The primary rail is largely bypassed, so the load must be carried by the wheel, suspension, fender, hinge pillar, and the A-pillar/sill path. This produces intense local deformation, wheel intrusion into the footwell, and a strong rotational component. SOF is the most demanding case for body-in-white joint modeling, because the load path runs through connections — the hinge pillar to A-pillar joint, the sill-to-floor junction — that are often simplified in coarse models. It is also the case where barrier geometry and vehicle yaw at impact matter most.

Setting up the three cases in a qualification model

Before any of the three cases can be run, the model must be brought to a consistent, documented state. The following setup sequence applies to all three, with case-specific parameters called out afterward.

1. Define the coordinate convention and impact direction. Adopt a single global convention for the whole program — for example, vehicle forward is +X, impact velocity is applied as an initial condition in −X, and the barrier is fixed. State this convention in the model documentation and keep it identical across FRB, ODB, and SOF so that results are directly comparable. If a solver or protocol uses a different sign convention, convert explicitly and note the conversion.
2. Set the impact velocity. Use the velocity specified by the target protocol. Common values are 56 km/h for FRB and ODB in many consumer programs, and 64 km/h for SOF in the widely referenced protocol; confirm the exact value against the protocol revision you are qualifying to, because these numbers change between revisions.
3. Build or import the barrier. For FRB and SOF, the barrier is a rigid wall — model it as a rigid body with a fixed boundary condition and a contact surface. For ODB, the barrier is a deformable honeycomb element; it must be modeled with a validated material model (typically a crushable foam or honeycomb formulation) and a calibrated force–deflection characteristic, not as a rigid block. A rigid ODB barrier is a common and serious setup error because it removes the energy absorption that defines the test.
4. Position the barrier and vehicle to achieve the correct overlap. FRB: full width, centered. ODB: 40% overlap, driver side, with the barrier face aligned to the vehicle centerline offset. SOF: 25% overlap, with the barrier edge positioned outboard of the longitudinal rail. Verify overlap by measuring the lateral distance between the barrier edge and the vehicle centerline in the model, not by eye.
5. Apply initial velocity and gravity, and initialize contact. Assign the impact velocity as an initial velocity field to the vehicle, apply gravity, and ensure all contact interfaces (barrier-to-bumper, tire-to-ground if modeled, occupant-to-restraint) are initialized before the run. Check for initial penetrations; a small initial penetration in the barrier contact can produce a spurious early pulse.
6. Define the output requests before running. At minimum: barrier force, vehicle center-of-gravity (CG) acceleration in the impact direction, longitudinal rail deformation, occupant compartment intrusion at the footwell and dash, and restraint system outputs (belt force, airbag pressure, dummy injury metrics). These are the quantities you will compare against test data.

Reading the results and judging qualification

Qualification is not a single number. For each case, compare the model against test data on three levels, in order of increasing sensitivity:

The order matters. If the global pulse does not correlate, the structural and occupant comparisons are not meaningful — fix the energy management first. A model that matches the pulse but shows the wrong deformation mode (for example, rail buckling in the wrong location, or a hinge-pillar joint that stays intact when the test shows separation) is not qualified even if the intrusion numbers happen to fall within tolerance. Mode correlation is a prerequisite, not a bonus.

Case-specific failure signatures are worth memorizing. In FRB, the most common model error is an over-stiff front structure that produces a pulse peak that is too high and too early; check bumper-beam and cradle modeling first. In ODB, the common errors are a mis-calibrated barrier (discussed above) and under-modeled spot-weld or adhesive failure in the impacted rail, which lets the rail absorb more energy than it should and under-predicts intrusion. In SOF, the dominant error is a load path that is too continuous — the model carries load through the rail when the real structure bypasses it — which under-predicts wheel intrusion and A-pillar rotation; check the wheel, suspension, and hinge-pillar connections specifically.

A minimal qualification record for the frontal cases

The following fields are the minimum needed to make a frontal-case qualification traceable and reproducible. Fill one row per case.

Case ID:            FRONTAL-FRB-01 / FRONTAL-ODB-01 / FRONTAL-SOF-01
Protocol revision:  [e.g., consumer program + revision number]
Impact velocity:    [value, km/h]
Overlap:            [100% / 40% driver / 25% driver]
Barrier:            [rigid wall / deformable honeycomb, calibrated]
Coordinate conv.:   [+X forward, impact in -X]
Model version:      [commit hash or revision]
Global pulse:       peak [g], duration [ms], correlation [pass/fail]
Structural mode:    [rail buckling location, intrusion values], [pass/fail]
Occupant metrics:   [key metrics], [pass/fail]
Open issues:        [list or "none"]

Used consistently, this record makes it obvious at a glance which frontal configurations a given model revision has actually been qualified against, and it prevents the most common program-level failure: treating a single successful FRB run as evidence that the model is ready for ODB and SOF. The three cases are complementary probes of the same structure, and a credible qualification covers all three with independent correlation evidence.