Simulation Credibility

A result is a number a computer produced: the braking distance was a certain value, the fault was detected in a certain time, a whole campaign passed. Evidence is that result plus a credibility argument, a documented reason to believe the number says something true about the real vehicle, for this question, in this domain. Results are cheap, because a cluster produces them by the million overnight; the argument is the expensive part and the only part an assessor buys. Break any link in the chain, and the claim drops from evidence back to anecdote while the dashboard stays exactly as green as before.

No, and reading the platform matrix row-wise shows why. Hardware in the loop has the real ECU behind its real connector, but its plant model is usually simpler than an offline one because it must complete every step inside a real-time frame. Software in the loop has no timing truth but can run enormous scenario campaigns faster than real time. Processor in the loop buys real instruction timing and almost nothing else. So the honest question is never which rung is higher; it is whether the claim leans on the elements a given platform makes real, which is a sentence that belongs in the verification strategy.

It is validating a model on the same data used to tune it. Calibration adjusts parameters until outputs match reference data, which is part of building the model; validation measures how well the finished model matches data it has never seen, which is part of judging it. The two acts use identical machinery, which is exactly why they get merged. A calibrated match to the calibration data carries almost no information about predictive power, because the optimizer would have produced a match whether or not the physics was right, and flexible models make it worse by absorbing more noise and structural error into the fit.

No, and the seam between the two is where assessors probe. Tool qualification addresses tool malfunction: the solver computing something other than its own specification, the automation skipping cases, the script summing the wrong column. It says nothing about whether the model being solved is a valid stand-in for reality. A fully qualified solver faithfully executing its numerics on a plant model whose behaviour is wrong outside the calibrated range produces results that are precise, repeatable, qualified and false. Both territories are required and neither substitutes for the other.

Only what its sampling scheme supports, against a denominator it has to name. A campaign covers a modelled parameter space under a chosen sampling scheme; it does not cover reality. Three gaps separate the two: the logical scenario may omit parameters that matter, the exposure distribution used for drawing may misweight the world, and whole scenario classes may be missing from the catalog, which is the residual that performance-limitation analysis exists to chase. The guide states the strongest honest claim per campaign type and computes the zero-failure bound, so run counts stop being reported without their fine print.

It runs 13 chapters: why simulation became load-bearing and what separates a result from evidence, the platform ladder and the real-time contract, intended use and risk-scaled rigor with the validity domain, verification before validation with step size and event detection, calibration discipline and identifiability, uncertainty propagation and sensitivity, correlation to physical tests with decomposed agreement ratings, scenario coverage and the claims each campaign supports, fault injection fidelity per platform, tool confidence applied to the whole virtual stack including the scoring script, configuration manifests and reproducibility, the argument that weighs the evidence, and a worked campaign for one driver assistance function with a pitfalls checklist. Every number in the figures is either from a named public source or labelled illustrative.