4. Verification and validation strategy
In occupant restraint verification programs, the terms verification and validation are frequently used interchangeably in casual conversation, yet they answer fundamentally different questions. Confusing them leads to evidence gaps that only surface during regulatory review or litigation. This section establishes a precise working distinction, shows how to define program-level evidence, and demonstrates how to construct a verification cross-reference matrix (VCRM) that ties every requirement to its evidence source.
Verification vs. Validation: Two Different Questions
Verification asks: "Did we build the restraint system right?" It is a conformance activity — comparing the design output against its specified requirements. Verification evidence includes component-level test reports, CAE correlation studies, drawing compliance checks, and material certifications. It is largely analytical and test-based, and it is performed against the requirement baseline, not against the real-world environment.
Validation asks: "Did we build the right restraint system?" It is a fitness-for-purpose activity — confirming that the verified design actually performs as intended in the operational environment. Validation evidence includes full-scale sled tests, vehicle-level crash tests, and in-vehicle occupant response data. Validation is performed against the operational need, not against the specification.
A useful mnemonic: verification is specification-centric; validation is mission-centric. A seatbelt retractor can pass every verification test (lock-up time, webbing elongation, cycle durability) and still fail validation if the pretensioner timing is wrong for the actual crash pulse. Both activities are necessary; neither substitutes for the other.
Defining Program-Level Evidence
Program-level evidence is the consolidated body of objective proof that the restraint system satisfies all applicable requirements across the full V&V lifecycle. It is not a single test report; it is a structured collection that spans analysis, component testing, subsystem testing, and full-system validation. For an occupant restraint program, program-level evidence typically includes:
- Requirements traceability records — each requirement linked to its source (regulation, internal standard, customer specification) and to its verification method.
- Analysis evidence — CAE models, correlation metrics, and sensitivity studies that justify analytical predictions.
- Component and subsystem test evidence — test plans, raw data, pass/fail criteria, and deviation records.
- Full-system validation evidence — sled and vehicle crash test results with occupant injury metrics (HIC, chest deflection, femur load, etc.).
- Configuration records — the exact build level, software calibration, and hardware revision associated with each piece of evidence.
The critical discipline is that evidence must be traceable, current, and configuration-controlled. An outdated test report from a previous build level is not program-level evidence; it is historical data. The program must define, in advance, what constitutes acceptable evidence for each requirement category and who is authorized to approve it.
Building the Verification Cross-Reference Matrix
The VCRM is the single most important tool for managing V&V evidence. It is a living matrix that maps every requirement to its verification method, evidence source, status, and responsible owner. The matrix prevents the two most common program failures: requirements with no evidence, and evidence with no requirement.
A practical VCRM for an occupant restraint program contains the following columns:
| Column | Purpose | Example Entry |
|---|---|---|
| Requirement ID | Unique identifier from the requirements baseline | REQ-OR-014 |
| Requirement Text | Concise statement of the requirement | Driver airbag must deploy within 30 ms of crash pulse onset |
| Verification Method | Test, Analysis, Inspection, or Demonstration (TAID) | Test |
| Evidence Source | Specific document, test ID, or model file | TR-AB-022, Rev C |
| Acceptance Criteria | Pass/fail threshold | Deployment time ≤ 30 ms |
| Status | Open, In Progress, Pass, Fail, Waived | Pass |
| Owner | Responsible engineer or organization | Restraint Systems Lead |
| Configuration | Build level or calibration associated with evidence | Build 7.2, Cal 4.1 |
When populating the VCRM, the verification method must be chosen deliberately. Test is preferred when the requirement is safety-critical and the physics are not fully understood. Analysis is acceptable when validated models exist and the requirement is parametric. Inspection is used for physical attributes (e.g., labeling, routing). Demonstration is used for operational sequences that cannot be fully instrumented.
Worked Example: VCRM Entry for a Pretensioner Requirement
Consider requirement REQ-OR-027: "The seatbelt pretensioner shall reduce webbing slack by at least 80 mm within 15 ms of receiving the deployment signal." The verification method is Test. The evidence source is sled test ST-2024-018, which used a 50th-percentile male ATD at 56 km/h frontal impact. The acceptance criterion is a measured slack reduction ≥ 80 mm at t = 15 ms. The test data showed 92 mm reduction at 14.2 ms, so the status is Pass. The configuration is Build 7.2, Cal 4.1. The owner is the Restraint Systems Lead.
If the same requirement were verified by analysis instead, the VCRM would reference the CAE model file and its correlation report, and the acceptance criterion would be the predicted slack reduction with a defined margin. The key is that the method, evidence, and criteria are explicit and auditable.
Common Pitfalls and How to Avoid Them
Three pitfalls recur in restraint V&V programs. First, method substitution: using analysis to verify a requirement that demands test evidence, often to save cost. This is acceptable only if the analysis is validated against physical test data for the same failure mode. Second, evidence drift: citing a test report from an earlier build level without confirming that the current configuration is equivalent. Third, orphan requirements: requirements that appear in the baseline but never appear in the VCRM. A quarterly reconciliation between the requirements database and the VCRM catches these before they become audit findings.
The VCRM is not a static document. It evolves as requirements change, as test results arrive, and as the design matures. Its value lies in its completeness and its currency. A program that maintains a rigorous VCRM can demonstrate, at any moment, that every requirement has a defined verification path and that every piece of evidence is traceable to a requirement.
The matrix above illustrates the essential structure: requirements flow into verification and validation activities, and all evidence converges into a single cross-reference matrix. The status column is the program's early-warning system — a "Fail" entry on REQ-OR-041 (chest deflection) immediately triggers a corrective action, while an "In Progress" entry on REQ-OR-033 (HIC analysis) signals that validation evidence is not yet complete. The configuration column ensures that every piece of evidence is tied to a specific build level, preventing the evidence-drift problem described earlier.
In practice, the VCRM should be reviewed at each phase gate: after requirements freeze, after component testing, after subsystem testing, and after full-system validation. At each review, the program lead confirms that every requirement has a current status, that failed items have corrective action plans, and that no requirement has been silently dropped. This discipline transforms V&V from a paperwork exercise into a genuine risk-management tool for occupant restraint programs.