3. Decomposition of the credibility plan

A credibility plan is only useful if it can be executed. A monolithic statement such as "the crash model shall be validated" is unactionable: it does not say which model, for which loading scenario, against which physical evidence, or with what tolerance. Decomposition converts the plan into a set of bounded, verifiable units. The three activities in this chapter — scope definition, use-case specification, and identification of critical simulation responses — form the logical spine of that decomposition. They are performed in that order, because each constrains the next: scope bounds the use cases, and use cases determine which responses matter.

Scope definition: bounding the model and the decision it supports

Scope definition answers three questions before any validation activity begins. First, what physical system is represented — the vehicle body-in-white plus closures, the occupant restraint system, a battery enclosure, or a full vehicle with dummies. Second, what decision the simulation informs — concept selection, design release sign-off, regulatory certification support, or root-cause investigation of a field failure. Third, what is explicitly excluded — for example, high-speed pole impacts above 64 km/h, occupant injury prediction for out-of-position occupants, or durability loading below 5 km/h.

The decision context is the most frequently neglected element. A model used to rank concept variants needs only relative fidelity; a model used to support a certification submission needs absolute fidelity against a defined test protocol. Writing the decision into the scope statement prevents the common failure of validating to a tolerance that is irrelevant to how the result will be used.

A practical scope statement also records the model baseline: solver and version, mesh size regime, material card source, and the configuration management identifier of the deck. Without this, a validation result cannot be reproduced or traced. For example, a scope entry might read: "LS-DYNA R13.1, baseline B-2024-07, shell mesh 5 mm nominal in the front structure, 10 mm in the rear, material cards from the internal MAT database revision 12."

Use-case specification: turning scope into discrete, testable scenarios

Each use case is a single loading scenario paired with a single physical reference. The specification must be concrete enough that two engineers would set up the same run. The essential fields are: impact configuration and boundary conditions, initial velocity and direction, the physical test that provides the reference data, and the acceptance metric family that will be applied.

Consider a frontal offset deformable barrier (ODB) case at 64 km/h with 40% overlap. The specification should state the barrier face properties, the ground friction assumption, the vehicle attitude at impact, and the exact test report or database record used as reference. A side impact case would instead specify the moving deformable barrier mass and velocity, the impact point relative to the occupant compartment, and the dummy or sled configuration. These are not interchangeable: the barrier, the impactor, and the boundary conditions are part of the use case, not incidental setup details.

Use cases should be enumerated as a controlled list, each with a unique identifier, so that validation evidence can be attached to it. A typical decomposition for a body structure program might include: full frontal rigid barrier at 50 km/h; ODB 40% at 64 km/h; side MDB at 50 km/h; rear moving barrier at 80 km/h; and a low-speed bumper case at 8 km/h. Each identifier then carries its own reference data set and its own response list.

Identifying critical simulation responses

Not every output of a crash model deserves a credibility threshold. Critical responses are those that (a) drive the decision identified in the scope, (b) are sensitive to modeling assumptions that are themselves uncertain, and (c) can be compared against physical measurement with acceptable uncertainty. Responses that fail any of these tests may still be reported, but they should not anchor the acceptance decision.

For a frontal ODB case, the critical response set typically includes: longitudinal deceleration at the sill or tunnel, occupant compartment intrusion at defined section cuts, steering column rearward displacement, and the force–displacement characteristic of the front rail. Each is tied to a specific measurement location in the physical test, and each has a known sensitivity — intrusion, for instance, is strongly sensitive to spot-weld failure modeling and material strain-rate calibration, which makes it a high-value validation target.

The identification step should also record, for each response, the comparison method: time-history correlation (for example, a correlation metric or an area-based measure), peak-value comparison, or a scalar metric such as maximum intrusion. Mixing methods across responses without recording them makes the eventual acceptance decision ambiguous. A response that is compared only at its peak is a different claim from one compared over its full history.

The following table illustrates a response register for one use case. The values are illustrative and intended to show structure, not measured results.

How the three activities connect

The dependency runs in one direction and should be enforced in reviews. A response that cannot be traced to a use case, and a use case that cannot be traced to the scope decision, is either out of scope or evidence of an incomplete decomposition. The figure below shows this traceability chain together with the feedback loop that occurs when a critical response proves untestable or insensitive — in which case the use case or the response set is revised, not the acceptance threshold.

Common decomposition failures

Three failure patterns recur in practice. The first is scope creep through the response list: engineers add responses because they are easy to extract from the solver output, not because they inform the decision. The result is a validation matrix that is expensive to populate and does not sharpen the acceptance judgment. The second is use cases defined by solver setup rather than by physical scenario, which makes it impossible to attach reference data and therefore impossible to validate. The third is responses without a fixed comparison method, which allows the same data to be presented as passing or failing depending on which metric is chosen after the fact.

A short review checklist catches most of these: does each use case have a named physical reference and a unique identifier? Does each critical response state its measurement location and comparison method? Can every response be traced upward to a scope decision? If any answer is no, the decomposition is incomplete and the credibility plan should not proceed to threshold setting until it is resolved.