4. Requirements risk management

Vehicle-level safety requirements rarely fail because they are wrong in isolation. They fail because the intent expressed at the vehicle level is silently distorted as it cascades into the restraint system, the subsystem, and finally the component specification. A requirement such as "the occupant shall be protected in a 56 km/h frontal ODB impact" is meaningful to a program manager, but it is not directly testable by a seatbelt retractor supplier. Requirements risk management is the discipline of controlling that translation so that every downstream specification remains traceable to a vehicle-level safety goal and carries verification criteria that can actually be executed.

Why Cascading Creates Risk

Each level of decomposition introduces three predictable failure modes. First, intent loss: a vehicle-level performance target becomes a component-level dimensional or material requirement that no longer reflects the original occupant protection objective. Second, orphan requirements: a component specification exists with no parent, meaning no one can justify why it is there or what happens if it is relaxed. Third, verification gaps: a requirement is written without a method, acceptance threshold, or responsible party, so it cannot be closed out.

These failures are not theoretical. A restraint control module (RCM) may be specified to trigger at a particular deceleration threshold, but if the vehicle-level requirement was actually about occupant injury criteria (HIC, chest deflection, femur load), the threshold alone does not guarantee the outcome. The cascade must preserve the why, not just the what.

The Four-Level Cascade Structure

A workable cascade for restraint programs typically uses four levels:

  • Vehicle level (V): Occupant protection outcomes under defined crash modes — e.g., "In a 56 km/h 40% ODB frontal impact, the 50th percentile male occupant shall not exceed HIC 700, chest deflection 42 mm, and femur load 6.8 kN."
  • System level (S): Restraint system performance that produces those outcomes — e.g., "The restraint system shall deploy the driver airbag within 25 ms of impact detection and limit belt force to 4.5 kN ± 0.5 kN during the ride-down phase."
  • Subsystem level (SS): Subsystem behavior that enables system performance — e.g., "The seatbelt pretensioner shall achieve 80 mm of webbing retraction within 15 ms of receiving the fire command."
  • Component level (C): Component characteristics that enable subsystem behavior — e.g., "The retractor torsion bar shall yield at 4.2 kN ± 0.3 kN and maintain load limiting for at least 120 mm of webbing payout."

Each level must carry a unique identifier, a parent link, a verification method, and an acceptance criterion. The identifier scheme should encode the level and the parent so that traceability is visible in the number itself — for example, V-FR-001 cascading to S-FR-001-01, then SS-FR-001-01-A, then C-FR-001-01-A-1.

Restraint Requirements Cascade with Traceability and Verification VEHICLE LEVEL — V-FR-001 Occupant outcome: HIC ≤ 700, chest deflection ≤ 42 mm, femur load ≤ 6.8 kN Verification: Full vehicle ODB test, 56 km/h, 50th percentile male decomposes to SYSTEM LEVEL — S-FR-001-01 Restraint system: airbag deploy ≤ 25 ms, belt force limit 4.5 kN ± 0.5 kN Verification: Sled test with instrumented dummy, high-speed video decomposes to SUBSYSTEM LEVEL — SS-FR-001-01-A Pretensioner: 80 mm retraction within 15 ms of fire command Verification: Bench test with load cell and displacement sensor decomposes to COMPONENT LEVEL — C-FR-001-01-A-1 Torsion bar: yield 4.2 kN ± 0.3 kN, load limiting ≥ 120 mm payout Verification: Tensile test per component specification, 3 samples TRACEABILITY CHAIN

Writing Verification Criteria That Close the Loop

A requirement without a verification criterion is a wish. Each cascade level should specify four fields: the verification method (test, analysis, inspection, or demonstration), the acceptance threshold, the sample size or confidence basis, and the responsible function. For restraint systems, the most common methods are:

Level Typical Method Acceptance Basis Responsible
Vehicle Full vehicle crash test Injury criteria from instrumented dummy Vehicle safety integration
System Sled test Deployment timing, belt force profile Restraint system engineering
Subsystem Bench test Displacement, timing, force output Subsystem supplier
Component Material / component test Yield force, dimensional tolerance Component supplier

The acceptance basis must be unambiguous. "Belt force shall be limited" is not verifiable. "Belt force shall not exceed 4.5 kN ± 0.5 kN for at least 80 mm of webbing payout, measured at the retractor anchor point" is verifiable. The measurement location matters because force varies along the belt path; specifying the anchor point removes ambiguity.

Managing Change and Orphan Detection

Requirements risk is not static. When a vehicle-level target changes — for example, a mid-program decision to increase the ODB speed from 56 km/h to 64 km/h — every downstream requirement must be re-evaluated. A practical mechanism is a traceability matrix that links each requirement to its parent and flags any requirement whose parent has changed but whose own text has not been reviewed.

Orphan detection is equally important. Any component or subsystem requirement without a valid parent link should be treated as a risk item. It may be a legacy requirement from a previous platform, a supplier-proposed addition, or a genuine gap in the cascade. In all three cases, it needs a disposition: retain with justification, revise to link to a parent, or delete.

Common pitfall: Cascading only the numerical targets and dropping the boundary conditions. A component requirement that says "yield at 4.2 kN" without specifying temperature range, loading rate, and webbing payout distance may pass component testing but fail in the vehicle because the real operating conditions differ. Always cascade the boundary conditions alongside the target value.

Practical Cascade Example: Frontal Restraint

Consider a frontal restraint program. The vehicle-level requirement V-FR-001 states the occupant injury targets. The system-level requirement S-FR-001-01 translates this into airbag deployment timing and belt force limiting. The subsystem requirement SS-FR-001-01-A specifies pretensioner retraction distance and timing. The component requirement C-FR-001-01-A-1 specifies the torsion bar yield force and load-limiting travel.

At each step, the verification method changes from full vehicle test to sled test to bench test to component test. The acceptance criteria become progressively more specific and more directly measurable. The traceability chain ensures that if the component test passes but the vehicle test fails, the program can trace back to identify which cascade link was incorrectly translated.

Review checkpoint: Before design freeze, verify that every component-level requirement has a parent at the subsystem level, every subsystem requirement has a parent at the system level, and every system requirement has a parent at the vehicle level. Any break in the chain is a requirements risk that must be resolved or explicitly accepted with documented rationale.

Requirements risk management in restraint programs is ultimately about preserving intent through decomposition. The cascade is not a paperwork exercise; it is the mechanism that ensures a component supplier's torsion bar specification actually contributes to the occupant protection outcome that the vehicle program committed to. Traceability and verification criteria are the two tools that make that preservation auditable and enforceable.

← Previous 📖 Contents Next →