Verification & Validation

Verification and validation are distinct obligations distributed across ISO 26262 Parts 4, 6 and 8. Verification checks that each work product correctly implements its inputs - unit tests against the unit design, integration tests against the architecture, system tests against the technical safety requirements - answering "did we build it right?". Validation checks the item against its safety goals at vehicle level, answering "did we build the right thing?". The V-model pairs every left-side development activity with a right-side verification activity, each with defined verification criteria, coverage requirements scaled by ASIL, and independence requirements for who performs the check.

ISO 26262-6 scales structural coverage with ASIL through its method tables. At unit level, statement coverage is the baseline for lower ASILs, branch coverage is highly recommended from ASIL B upward, and MC/DC (modified condition/decision coverage) is highly recommended at ASIL D. At the architectural level, function and call coverage apply. Coverage is evidence, not the goal: gaps must be analyzed and justified - dead code, defensive code, or missing tests - and requirements-based test derivation comes first, with structural coverage measuring how thoroughly those tests exercised the code. The guide covers how to achieve MC/DC in practice and how tools measure it.

Back-to-back testing runs the same stimuli through two representations of the software - typically a validated simulation model and the generated or hand-written production code - and compares the outputs automatically. It is the workhorse verification method for model-based development: the model is verified against requirements once, and back-to-back testing then demonstrates the code behaves equivalently, catching code generation, fixed-point scaling and platform differences. To be credible, the comparison needs defined tolerances, coverage measured on both sides, and stimuli rich enough to exercise the equivalence claim - a lazy stimulus set proves nothing about the cases that matter.

They are three execution environments along the V. MIL (model-in-the-loop) runs the controller model against a plant model entirely in simulation - fastest iteration, earliest availability, no target hardware effects. SIL (software-in-the-loop) executes the compiled production code on a host PC against the plant model, exposing code generation and arithmetic effects. HIL (hardware-in-the-loop) runs the real ECU with real interfaces against a real-time plant simulation, enabling fault injection on actual signals, timing verification and testing of scenarios too dangerous for a vehicle. A sound ISO 26262 V&V plan assigns each requirement to the cheapest environment that can credibly verify it.

The guide has 14 chapters spanning V&V fundamentals, the V-model, unit, integration, system and vehicle testing, MC/DC coverage, independence requirements, test case derivation, back-to-back testing, MIL/SIL/HIL environments, fault injection, review and inspection, and evidence capture. A worked example builds the complete V&V plan for an ASIL D brake control software, including its verification matrix. A free account starts you off, and the Pro and Expert plans unlock more of the library.