2. Simulation model lifecycle

A crash simulation model is not a one-off artifact. It is a governed asset whose credibility must be established, maintained, and eventually retired in a controlled manner. The simulation model lifecycle provides the framework for this governance. It defines the stages a model passes through, the entry and exit criteria for each stage, and the evidence that must be produced before a model is allowed to influence a design decision. Without a lifecycle framework, CAE models proliferate, versions diverge, and the same physical structure is modeled inconsistently across teams.

The lifecycle described here is adapted from established systems engineering and V&V standards, particularly ASME V&V 10 and 20, and is tailored to the specific demands of explicit crash simulation using tools such as LS-DYNA, Pam-Crash, or Radioss. The stages are: requirements definition, model planning, model construction, verification, validation, deployment, in-service monitoring, and retirement. Each stage produces defined deliverables and must satisfy exit criteria before the next stage begins.

Requirements Definition

The lifecycle begins not with meshing but with a clear statement of what question the model must answer. Requirements definition translates a program need — for example, "demonstrate that the battery enclosure does not intrude into the cell modules during a 50 km/h side pole impact" — into simulation-specific requirements. These include the physical phenomena that must be captured (large deformation, contact, material failure, strain-rate sensitivity), the output quantities of interest (intrusion, acceleration, energy absorption), and the accuracy threshold that constitutes acceptable agreement with physical reality.

A common failure mode is to skip this stage and begin modeling immediately. The result is a model that may be numerically stable but is not fit for the decision it is meant to support. Requirements should be documented in a Simulation Requirements Specification (SRS) that is traceable to the program's validation plan. The SRS should state, at minimum: the load case, the boundary conditions, the material models expected to be active, the mesh resolution regime, and the acceptance criteria expressed as quantitative tolerances.

Model Planning

Model planning converts requirements into a technical strategy. This is where the analyst decides on model fidelity, element formulation, time step strategy, and the validation hierarchy. A key concept here is the validation pyramid: component-level tests validate material and joint models, subsystem tests validate assembly behavior, and full-vehicle tests validate the integrated model. Planning must allocate validation evidence to each level so that the final full-vehicle model rests on a foundation of validated lower-level models.

Planning also addresses computational resources. A full-vehicle crash model with 10–15 million elements may require 24–72 hours on a 128-core cluster. The plan should specify the target cycle time, the mass scaling strategy (if any), and the acceptable added mass percentage — typically kept below 1–2% for production crash models. These are not arbitrary numbers; they are governance constraints that prevent schedule pressure from silently degrading model quality.

A well-written model plan includes a "known limitations" section. Explicitly listing what the model does not capture — for example, weld failure beyond the heat-affected zone, or fluid-structure interaction in a fuel tank — prevents downstream misuse and sets honest expectations with decision-makers.

Model Construction and Verification

Model construction is the meshing, assembly, and boundary condition definition phase. Verification asks a narrower question than validation: "Are we solving the equations correctly?" Verification activities include mesh convergence studies, energy balance checks, time step stability analysis, and comparison against analytical solutions for simplified cases. A model that passes verification is numerically sound; it may still be physically wrong.

Energy balance is the single most important verification check in crash simulation. The total energy should remain approximately constant, with the sum of internal energy, kinetic energy, and hourglass energy accounting for the initial kinetic energy minus energy absorbed by boundary conditions. Hourglass energy should remain below 5% of internal energy; if it exceeds this, the model has spurious deformation modes that invalidate results. Similarly, added mass from mass scaling should be reported and kept within the planned limit.

Validation

Validation asks: "Are we solving the right equations?" It compares simulation predictions against physical test data. The comparison must be quantitative, not visual. Common metrics include peak acceleration, intrusion at defined points, force-displacement curves, and energy absorption. The CORA (Correlation and Analysis) metric is widely used in the automotive industry to produce a single numerical score for curve correlation, with a score above 0.8 typically considered acceptable for full-vehicle crash models.

Validation is not a single event. It is a hierarchical process. A material model for a high-strength steel may be validated against tensile and shear tests. A spot weld model may be validated against lap-shear and coach-peel tests. Only after these component validations are complete should the full-vehicle model be validated against a sled or barrier test. Skipping levels in the hierarchy produces a model that cannot be diagnosed when it fails.

Deployment and In-Service Monitoring

Deployment is the release of a validated model into production use. This requires more than copying files to a shared drive. Deployment includes version control, documentation of the exact solver version and settings, and a clear statement of the model's validated domain. A model validated for frontal impact at 50 km/h is not automatically valid for side impact or for a different vehicle variant.

In-service monitoring tracks model usage and performance over time. If a model is used outside its validated domain, or if solver updates change results, the model must be re-validated or restricted. This is where many organizations fail: a model is validated once, then used for years without re-checking as the vehicle design, material suppliers, or solver versions change.

Retirement

Retirement is the formal end-of-life for a model. It occurs when the vehicle program ends, when the model is superseded by a higher-fidelity replacement, or when accumulated changes make the original validation evidence irrelevant. Retirement should include archiving the model, its validation evidence, and its usage history in a form that remains accessible for regulatory or legal purposes. Simply deleting files is not retirement; it is data loss.

Simulation Model Lifecycle — Crash Safety Application Requirements SRS, load cases, acceptance criteria Model Planning Fidelity, validation pyramid, resources Construction Mesh, assembly, boundary conditions Verification Energy balance, convergence, stability Validation Test correlation, CORA, hierarchy Deployment Version control, validated domain In-Service Monitoring Usage tracking Retirement Archive model, evidence, history Validation failure → revise model plan or requirements Domain change or solver update → re-validate Key Governance Artifacts by Stage Requirements: SRS, validation plan | Planning: model plan, resource estimate | Construction: mesh quality report, deck Verification: energy balance log, convergence study | Validation: correlation report, CORA scores | Deployment: release note, version tag In-Service: usage log, re-validation trigger | Retirement: archive record, supersession note

Practical Example: Side Pole Impact Model

Consider a side pole impact model for a battery electric vehicle. The requirements specify a 50 km/h impact against a 254 mm diameter rigid pole, with the pole positioned to strike the B-pillar. The quantity of interest is the maximum intrusion into the battery enclosure, with an acceptance threshold of 120 mm. The model plan selects a mesh size of 5 mm in the B-pillar and rocker, 8 mm in the battery enclosure, and 10 mm in the floor. Mass scaling is limited to 1.5% added mass. The validation hierarchy includes coupon tests for the battery enclosure aluminum, lap-shear tests for structural adhesive, and a full-vehicle pole test for final correlation.

During verification, the energy balance shows hourglass energy at 7% of internal energy — above the 5% threshold. The analyst investigates and finds that the battery enclosure uses under-integrated shell elements with insufficient hourglass control. Switching to fully integrated shells or increasing the hourglass coefficient resolves the issue, but increases runtime by 18%. This is a verification finding that feeds back into the model plan, not a validation failure. The distinction matters: verification failures are fixed by changing the numerical setup; validation failures require revisiting the physical assumptions.

After validation, the model achieves a CORA score of 0.86 for the intrusion curve and 0.82 for the B-pillar acceleration. The model is deployed with a version tag and a validated domain statement: "Valid for side pole impact at 45–55 km/h, pole diameter 250–260 mm, for vehicle variants with identical battery enclosure and B-pillar design." Any deviation from this domain triggers a re-validation requirement.

A model that passes validation but is deployed without a validated domain statement is a governance liability. It will inevitably be used outside its intended scope, and the resulting predictions will carry false confidence.

Lifecycle Governance in Practice

Effective lifecycle governance requires three things: a defined process, a configuration management system, and a review gate at each stage transition. The process defines what must be done. Configuration management ensures that the model, its inputs, and its evidence are versioned together. Review gates ensure that no stage is skipped and that exit criteria are objectively assessed.

The most common governance failure is not a technical error but a process shortcut: a model is validated for one load case and then used for another without re-validation, or a solver version is updated without re-running the validation suite. These shortcuts are invisible in the short term but accumulate as technical debt. When a regulatory submission or a legal challenge arrives, the organization cannot demonstrate that its simulation predictions were credible at the time they were made.

The lifecycle framework is not bureaucracy for its own sake. It is the mechanism by which simulation earns the right to influence safety-critical decisions. Each stage produces evidence; each transition is a checkpoint; each model carries its validation history with it. When the model is retired, that history is archived so that past decisions remain defensible. This is what distinguishes a governed simulation capability from a collection of analysis files.

← Previous 📖 Contents Next →