2. Virtual test model lifecycle

A virtual test model is not a single artifact but a governed lifecycle. The model that eventually supports a regulatory claim or an internal design decision begins as a question — "can we predict this behavior without a physical test?" — and passes through a sequence of engineering and evidentiary stages before it earns the right to be trusted. The central discipline of this chapter is that intended use is defined early and refined continuously, while verification, validation, and claim substantiation are planned from the outset rather than retrofitted after the simulation results look convincing.

The lifecycle can be understood as six coupled stages: model conception, intended use specification, model development, verification, validation, and claim substantiation. These are not strictly sequential — validation evidence often feeds back into the intended use statement, and a failed verification can force a return to model conception. The diagram below shows the stages, their principal outputs, and the feedback paths that make the lifecycle iterative.

Model conception: framing the question before the equations

Model conception is where engineering judgment matters most and where many programs quietly fail. The team must decide what physical behavior the model represents, which scales and boundary conditions are in scope, and what fidelity is actually needed. A common error is to build the most detailed model the software allows, then search for a use for it. The disciplined approach is the reverse: start from the decision the model must support. If the decision is "does this bracket survive a 30 g shock pulse?", a lumped-parameter model with a calibrated damping ratio may be sufficient; if the decision is "where does fatigue cracking initiate?", a detailed finite-element model with local stress gradients is required.

Conception should produce a short conception memo recording the engineering question, candidate modeling approaches, the physical reference data that could later support validation, and known risks. This memo is not bureaucracy — it is the seed of the traceability chain that claim substantiation will later depend on.

Intended use specification: the contract the model must honor

The intended use statement converts the conception question into an explicit, testable contract. A well-formed statement answers four things: what the model predicts, for which system and operating envelope, with what accuracy, and to support which decision. Vague statements such as "the model predicts thermal behavior" are unusable because no validation experiment can confirm or refute them.

Consider a worked example. A team is developing a virtual test model for a lithium-ion battery pack's thermal response under fast charging. A weak intended use reads: "Predict pack temperatures during charging." A defensible version reads:

Notice that the acceptance criterion (3 °C) is stated before any simulation is run. This ordering is essential: if the criterion is chosen after seeing the results, validation becomes a negotiation with oneself rather than an objective test. The intended use also fixes the validation domain — the operating envelope in which physical reference data must exist.

Development, verification, and validation: three distinct questions

These three stages are frequently conflated, yet they answer different questions and require different evidence.

Verification is a mathematical and numerical activity. For the battery thermal model, verification might include a mesh convergence study showing that doubling the mesh density changes the predicted maximum temperature by less than 0.2 °C, and a comparison against a published analytical solution for a simplified single-cell geometry. Verification failures are usually visible as non-convergence, sensitivity to discretization, or disagreement with benchmark solutions — symptoms that point to implementation or numerical issues, not to physics.

Validation is an empirical activity and must use data the model was not tuned against. If the same test data were used to calibrate the convective heat-transfer coefficient and then to "validate" the model, the exercise is circular. A sound practice is to split reference data: calibration cases and held-out validation cases. For the battery example, calibration might use a 1C test at 25 °C, while validation uses 2C and 3C tests at 15 °C and 35 °C. The validation report then states the observed error against the 3 °C criterion for each held-out case, for example a maximum deviation of 2.1 °C at 3C/35 °C and 1.4 °C at 2C/15 °C — both within criterion, supporting the claim within the stated envelope.

Claim substantiation: assembling the evidence chain

Claim substantiation is the final stage in which the accumulated evidence is assembled into a defensible package. It is not a new analysis; it is an audit of whether the intended use statement is fully supported. A practical substantiation dossier contains: the intended use statement, the model documentation and version identifier, the verification report, the validation report with held-out cases and error statistics, a traceability matrix linking each claim element to its supporting evidence, and a statement of limitations and residual risk.

The traceability matrix is the most useful working tool. Each row corresponds to one element of the intended use — predicted quantity, operating range, accuracy criterion — and each column records where the supporting evidence lives. If any row has an empty evidence cell, the claim is not yet substantiated. This simple check catches the most frequent defect in virtual test programs: a claim that quietly outruns its evidence.

The lifecycle therefore closes where it began — with the engineering question — but now with documented evidence that the question can be answered within a stated envelope and accuracy. The next chapters examine each stage in depth, beginning with how to write intended use statements that survive both engineering scrutiny and regulatory review.