📚 Course ContentsChapter 2 CAE verification and validation fundamentals

2. CAE verification and validation fundamentals

Before a single finite element model is built, the crashworthiness engineer must answer a deceptively simple question: what exactly are we proving, and to whom? In physical crash testing, the answer is usually unambiguous — a barrier impact at a specified velocity produces a measurable occupant response, and the test either passes or fails a regulatory threshold. In CAE, the same question becomes layered, because a simulation result is only as trustworthy as the chain of assumptions, discretization choices, and material laws that produced it. Verification and validation (V&V) is the discipline that makes that trust explicit, auditable, and defensible. This chapter establishes the vocabulary and the regulatory context that the rest of the course builds upon.

Verification and Validation Are Not the Same Activity

The most common source of confusion in engineering practice is the conflation of verification with validation. They answer different questions and are performed against different references.

Verification asks: Are we solving the equations correctly? It is a mathematics and software-quality activity. Verification compares the computational solution against an analytical solution, a manufactured solution, or a converged reference mesh. It is entirely internal to the model — no physical test data is involved. A typical verification activity in crash CAE is a mesh convergence study on a simple hat-section rail under axial crush: the engineer refines the element size from 8 mm to 5 mm to 3 mm and confirms that the predicted peak force and mean crush force stabilize within an acceptable tolerance (for example, less than 5% change between the two finest meshes). If the force continues to drift with refinement, the model is not verified, and any subsequent correlation with test data is meaningless.

Validation asks: Are we solving the right equations for the real physical system? It is an empirical activity that compares simulation output against physical test measurements, with quantified uncertainty in both. Validation is always scoped: a model is never "validated" in general, only validated for a specific intended use, over a specific range of conditions. A full-vehicle frontal model correlated at 50 km/h against a rigid barrier is not thereby validated for 64 km/h offset deformable barrier impact, oblique pole, or rear impact. This scoping principle is the single most important concept in the entire V&V framework, and it is the one most frequently violated in industrial practice.

Key distinction: Verification is a comparison of code against mathematics. Validation is a comparison of code against physical reality. Calibration is the adjustment of model parameters to improve agreement with test data — and calibration is not validation. A model tuned to match one test can always be made to fit that test; the question is whether it predicts a test it was not tuned to.

A third term, uncertainty quantification (UQ), underpins both. Every validation comparison involves uncertainty on two sides: experimental uncertainty (sensor accuracy, fixture compliance, specimen-to-specimen material variation, test-to-test repeatability) and numerical uncertainty (discretization error, time-step size, contact algorithm choice, material parameter scatter). A validation metric that ignores these bands is not a validation metric — it is a curve-fitting exercise. The ASME V&V 10 and 20 standards formalize this by requiring validation comparisons to be expressed with uncertainty intervals, and by requiring that the validation metric (often a combination of relative error and area-under-curve difference) be evaluated against an acceptance threshold defined before the comparison is run.

The Terminology Chain: From Intended Use to Predictive Capability

Regulatory and OEM engineering processes use a consistent vocabulary that connects a simulation to a decision. The chain runs as follows. The intended use defines the decision the model will support — for example, "support the selection of a front rail gauge for the 2026 model year program prior to physical prototype availability." The validation domain defines the conditions over which the model has been compared to test (velocity range, impact configuration, occupant size, temperature). The application domain defines the conditions over which the model will actually be used. If the application domain extends beyond the validation domain, the model must be used with explicit extrapolation justification, or additional testing must be performed. The validation hierarchy — component, subsystem, full system — determines the order in which evidence is accumulated: a material card is validated on coupon tests, a rail on component drop-tower tests, a front structure on sled tests, and the full vehicle on barrier tests. Skipping levels in the hierarchy is the most common cause of a full-vehicle model that correlates poorly despite excellent component-level agreement.

The Regulatory Landscape: What the Model Must Ultimately Serve

Crash CAE does not exist in a vacuum; it exists to support compliance and rating decisions. The regulatory landscape therefore defines the validation targets. In the United States, FMVSS 208 governs frontal occupant protection, with the rigid barrier test at 56 km/h (35 mph) as the anchor condition, evaluated against injury criteria such as HIC 15, chest deflection, and femur axial force for both belted and unbelted occupants. FMVSS 214 covers side impact via a moving deformable barrier, and FMVSS 226 addresses ejection mitigation. In Europe, UN Regulation 94 specifies the 40% offset deformable barrier test at 64 km/h, UN R95 the side impact, and UN R137 the frontal offset requirements harmonized under the 1998 Agreement. Beyond regulation, consumer programs — Euro NCAP, IIHS, and C-NCAP — impose stricter and more varied load cases, including small overlap, oblique pole, and far-side occupant protection, which frequently become the binding constraint on vehicle design.

The practical consequence for the CAE engineer is that the validation matrix is not chosen freely. Each regulatory or rating load case defines a required validation point, and the model must be correlated against physical tests at those conditions before it can be used to certify a design. A model correlated only at 56 km/h rigid barrier cannot be used to sign off a UN R94 offset case without additional validation evidence. This is why OEMs maintain a correlation matrix — a table mapping each load case to the physical tests performed, the model version used, the validation metric achieved, and the resulting credibility level.

Credibility: The Currency of CAE Evidence

The ASME V&V 20 standard introduces the concept of a credibility assessment: a structured judgment of how much confidence can be placed in a simulation result for a given intended use. Credibility is built from several factors — code verification evidence, solution verification (mesh and time-step convergence), validation comparison against test with uncertainty, sensitivity analysis showing which parameters dominate the response, and the pedigree of the input data (material cards, geometry, boundary conditions). The output is a credibility level — often expressed as a score or a qualitative rating — that the decision-maker uses to weigh the simulation against the cost and schedule of physical testing.

This is where V&V becomes a business tool rather than an academic exercise. A high-credibility model can reduce the number of physical prototypes; a low-credibility model cannot, regardless of how closely its curves appear to match a single test. The engineer's job is to build and document credibility deliberately, load case by load case, so that when the program asks "can we skip the third prototype?", the answer rests on evidence rather than on a visually pleasing overlay plot.

Practical rule of thumb: Before running any correlation study, write down the intended use, the validation domain, and the acceptance metric with its threshold. If you cannot state all three in one sentence, the study is not yet scoped and its result will not be defensible in a design review.

With this vocabulary established — verification versus validation, calibration versus prediction, validation domain versus application domain, and credibility as the structured output of the V&V process — the engineer is equipped to plan physical crash tests that actually serve the model, rather than tests that merely satisfy a regulatory checkbox. The next sections translate these definitions into the concrete test-planning decisions that determine whether CAE evidence will hold up under scrutiny.