Verification and Validation (V&V)
Activity
Topic overview
Quick facts
- Definition of Verification and Validation in functional safety
- Verification and Validation in depth
- The case for Verification and Validation
- Verification and Validation in practice
- Where teams get Verification and Validation wrong
- Verification and Validation and its standards
- Industries where Verification and Validation applies
- Ask our team about Verification and Validation
- Terms related to Verification and Validation
The distinction is the two questions: verification asks did we build the thing right, each work product checked against its specification, while validation asks did we build the right thing, the end system checked against the real need and hazard analysis in realistic conditions.
A safety function can verify perfectly against a wrong requirement; validation is what catches the wrong requirement. Safety standards require both, phase by phase: requirements are verified against the hazard analysis, design against requirements, code against design, and finally the integrated system is validated against the safety requirements specification and intended use.
Methods span test, analysis, inspection, and demonstration, and good V&V planning assigns the right method per requirement rather than defaulting everything to test: timing budgets may be proven by worst-case analysis, fault reactions by fault injection, usability assumptions by demonstration with real operators.
Coverage expectations scale with integrity level, from structural code coverage criteria in software (MC/DC at the highest levels in some domains) to mandated technique tables in and .
Independence is the other axis assessors care about: at higher integrity levels the people verifying and validating must be independent of those who built, up to organizational independence, because the author of a design is structurally the worst person to find its flaws.
Independent V&V is a certification expectation at higher SILs, and V&V planning defines methods and coverage for each requirement up front.
The case for Verification and Validation
V&V is typically the largest single cost block in a safety program, often exceeding development itself at higher integrity levels, so its planning quality directly sets program economics: an unplanned test-everything approach burns budget on easy requirements while leaving hard ones (timing, fault behavior) weakly covered.
It is also the evidence engine, most of what a safety case cites is V&V output, so gaps here become certification blockers at the worst possible time. Schedule realism matters too: validation needs the real integrated system, making it the natural victim of upstream slips unless leadership protects it.
Verification and Validation in practice
V&V within the lifecycle
A V&V plan is written early, alongside the safety plan, mapping every safety requirement to a method, a coverage criterion, an environment, and a responsible (and sufficiently independent) party.
Verification runs continuously through development, reviews, static analysis, unit and integration testing against specifications, while validation runs on the integrated system in realistic conditions: measured stop times, fault injection against the fault list, scenario testing at the boundaries of the or operating envelope.
Results are recorded traceably against requirements, and failures loop back through change control.
Assessors sample the traceability matrix end to end: requirement to method to result, checking that coverage criteria were met, that the tested configuration matches the release under assessment, that independence held, and that failed results were resolved rather than quietly retested into passing.
Where teams get Verification and Validation wrong
Verification and Validation and its standards
Verification and Validation is defined and governed by IEC 61508 - the umbrella functional safety standard defining the safety lifecycle, sil levels, and requirements for electrical, electronic, and programmable systems.
Verification and Validation is defined and governed by EN 50128 - software for railway control and protection systems, defining software sil requirements and lifecycle.
Verification vs validation
| Aspect | Verification | Validation |
|---|---|---|
| Question | Built right? | Right product? |
| Reference | Specifications of prior phase | User needs, hazard analysis |
| When | Every phase transition | End of integration, on target |
| Typical methods | Review, static analysis, unit test | System trials, scenario testing |
| Performed by | Verifier (independent per SIL) | Validator (independent per SIL) |
Industries where Verification and Validation applies
In robotics & automation, Verification and Validation comes up in nearly every certification conversation: industrial robots, cobots, amrs, and automated warehousing systems.
In rail & transit, Verification and Validation comes up in nearly every certification conversation: freight and passenger rail signaling, train control, and transit systems.
Ask our team about Verification and Validation
Ben TwomblyFounder & CEOLeads CSA's functional-safety, certification, and engineering programs for safety-critical products and organizations. His assessor-side background informs practical programs that connect standards, engineering work, and credible evidence.
Jeff Twombly, PEExecutive, Rail SafetyProvides executive and technical leadership for rail-safety programs, assessments, and complex transit-system work. His experience spans safety assurance, transportation-safety leadership, signaling, and independent review.
Tom CyrPrincipal Safety Engineer, IFSPSupports industrial and rail functional-safety programs with safety analysis, requirements, lifecycle planning, and certification-readiness guidance.Terms related to Verification and Validation
How each connects to Verification and Validation:
Safety Case is the natural next concept after Verification and Validation; assessors expect teams to connect the two.
Both Verification and Validation and Functional Safety sit under IEC 61508, so evidence for one usually references the other.
IEC 61508 connects the two: Verification and Validation and SIL are assessed against the same lifecycle.
Both Verification and Validation and Safety Function sit under IEC 61508, so evidence for one usually references the other.
Safe Torque Off is governed by IEC 61508 as well, which is why the two show up together in audits.
IEC 61508 connects the two: Verification and Validation and PFH are assessed against the same lifecycle.
FMEA is governed by IEC 61508 as well, which is why the two show up together in audits.
Both Verification and Validation and FMEDA sit under IEC 61508, so evidence for one usually references the other.
Both Verification and Validation and Fault Tree Analysis sit under IEC 61508, so evidence for one usually references the other.
CENELEC Rail Standards is governed by EN 50128 as well, which is why the two show up together in audits.
Safety Management System is governed by IEC 61508 as well, which is why the two show up together in audits.
Both Verification and Validation and Functional Safety Plan sit under IEC 61508, so evidence for one usually references the other.