2. Requirements flow-down and validation planning

Vehicle-level safety targets are written in language that no single component can satisfy on its own. A target such as "occupant chest deflection shall not exceed 50 mm in a 56 km/h frontal ODB impact" is a system outcome produced by the interaction of structure, restraints, geometry, and timing. The engineering task of this chapter is to convert that outcome into subsystem and component specifications that can be designed, tested, and signed off — and to build the traceability and gate structure that keeps the conversion honest.

From Vehicle Targets to Subsystem Specifications

Flow-down is not a copy-and-paste exercise. It is a decomposition in which each level receives a requirement it can actually own, with a measurable acceptance criterion and a defined interface. A practical decomposition for a frontal restraint system follows four levels:

• Vehicle level: regulatory and consumer-metric targets — FMVSS 208 injury criteria (HIC15, chest deflection, femur load), Euro NCAP or C-NCAP star thresholds, and internal targets set below the legal limit to preserve margin.
• System level: the restraint system as a whole — airbag deployment timing, seat belt load limiting, pretensioner firing, and the energy balance between structure and occupant.
• Subsystem level: airbag module, seat belt assembly, steering column, seat structure, and occupant classification sensor, each with its own performance envelope.
• Component level: inflator output, fabric permeability, retractor lock timing, webbing strength, and connector retention.

The critical discipline is allocation with margin. If the vehicle target is HIC15 ≤ 700 and the structure is expected to absorb a defined share of the energy, the restraint subsystem receives a tighter budget — for example HIC15 ≤ 600 at the system level — so that component tolerances and build variation do not consume the entire legal margin. Each allocated requirement must state the value, the tolerance, the test condition, and the verification method. A requirement without a verification method is not a requirement; it is an intention.

DVP&R Structure

The Design Validation Plan and Report (DVP&R) is the controlling document that links each requirement to the test that proves it. It is a living record: the "Plan" columns are filled before testing, and the "Report" columns are completed as evidence accumulates. A workable column set is:

Two structural decisions matter more than the column names. First, the DVP&R must cover every requirement, including those verified by analysis or inspection rather than physical test — analysis is a legitimate verification method when its correlation to test is documented. Second, the sample size and build configuration must be chosen to expose variation, not to confirm a golden sample. A DVP&R that tests only nominal builds will pass and then fail in production.

Traceability from Requirements to Test Cases

Traceability is bidirectional. Forward traceability answers "what test proves this requirement?" Backward traceability answers "why does this test exist?" Both directions must be maintained in a single database or linked spreadsheet, because auditors and gate reviewers will ask both questions.

A practical traceability chain for a seat belt retractor looks like this:

VEH-SAF-001  Vehicle frontal occupant protection, HIC15 <= 700
  └─ SYS-RST-014  Restraint system HIC15 budget <= 600
       └─ SUB-BLT-007  Retractor lock time <= 15 ms at 0.7 g
            └─ CMP-RTR-022  Lock pawl engagement force >= 40 N
                 └─ TEST-RTR-105  Component bench test, 30 samples,
                                  acceptance: 100% lock within 15 ms

When a requirement changes, the chain tells you exactly which tests are invalidated. When a test fails, the chain tells you which vehicle-level target is at risk. Without this link, a component failure becomes an isolated event and the safety impact is invisible.

Sign-Off Criteria and Gate Reviews

Validation planning is only effective if it is enforced at defined gates. A typical gate structure for restraint DV/PV is:

1. Design freeze gate: all requirements flowed down, DVP&R complete in plan form, traceability verified, no open requirement without a verification method.
2. DV exit gate: all design-validation tests complete, failures dispositioned with root cause and corrective action, correlation between CAE and physical test documented.
3. PV exit gate: production-intent tooling and process used, capability (Cpk) demonstrated on critical characteristics, all DVP&R items closed or formally waived with engineering justification.
4. Production release gate: control plan aligned with the validated configuration, PPAP or equivalent evidence complete, and any residual risk accepted by the responsible signatory.

Sign-off criteria must be objective. "Test passed" is not a criterion; "all 30 samples locked within 15 ms, with the slowest sample at 13.8 ms" is. Where a requirement cannot be met, the waiver must state the deviation, the compensating evidence, the residual risk, and the approver — a waiver is a decision, not a deletion.

Worked Example: Allocating a Chest Deflection Budget

Assume a vehicle-level target of chest deflection ≤ 50 mm, with an internal design target of 42 mm to preserve margin. The system team allocates the budget across contributors: belt load limiting (18 mm), airbag interaction and bag pressure (12 mm), seat and structure compliance (8 mm), and a residual allowance of 4 mm for build variation and measurement uncertainty. Each subsystem then receives its share as a testable requirement — for example, the retractor load limiter must hold peak belt force within a defined band across the deployment temperature range, verified on a sled with a specified dummy and a defined filtering per SAE J211.

The value of this exercise is not the specific numbers, which are illustrative. It is that every millimeter of the vehicle target is owned by a named subsystem, tested by a named method, and reviewed at a named gate. That is what makes a validation program defensible.

The diagram above shows the two directions that must both be maintained: requirements flow down from vehicle to component, while evidence flows back up through the DVP&R and gate reviews. A validation program is only as strong as the weakest link in that loop — and the most common weak link is a requirement that was never given a test, or a test that was never traced back to a requirement.