2. Requirements flow-down and traceability

Vehicle-level safety targets are almost never stated in terms that a restraint engineer can implement directly. A program target such as "meet FMVSS 208 belted and unbelted frontal occupant protection with a 5-star US NCAP driver score" is a system outcome, not a design instruction. Requirements flow-down is the disciplined process of decomposing that outcome into progressively more specific, verifiable requirements at the subsystem and component levels, while traceability preserves the bidirectional link between every component specification and the vehicle-level target it ultimately serves. Without this discipline, a restraint program can pass every component test and still fail the vehicle-level requirement, because no one can prove which component behavior was supposed to deliver which portion of the occupant protection.

The Flow-Down Chain and Its Interfaces

A typical restraint flow-down chain has four levels. At the vehicle level, targets are expressed as occupant injury criteria measured in full-vehicle crash tests: HIC15, chest deflection, chest acceleration (3 ms clip), neck Nij, femur axial force, and, for side impact, rib deflection and abdominal force. At the restraint system level, these become system requirements: airbag deployment timing windows, seat belt load-limiter force levels, pretensioner stroke and timing, and occupant classification thresholds. At the subsystem level, they become module requirements: airbag module inflator output mass flow versus time, cushion volume and venting, retractor spool-out characteristics, buckle strength. At the component level, they become supplier specifications: inflator propellant mass and burn profile, fabric permeability and seam strength, pyrotechnic initiator firing characteristics, and sensor ASIC threshold tolerances.

The critical engineering insight is that flow-down is not a simple allocation of numbers. Each level introduces its own design freedom, and the allocation must be negotiated against physical feasibility. For example, a vehicle-level requirement to reduce driver chest deflection by 8 mm might be allocated as a 1.5 kN reduction in load-limiter force plus a 20 ms earlier pretensioner firing. Whether that allocation is achievable depends on retractor packaging, buckle geometry, and the occupant's expected position at deployment — factors that live at lower levels and must feed back upward.

Key principle: Flow-down defines what each lower level must deliver; traceability proves why each lower-level requirement exists and which upper-level target would be at risk if it changed.

Writing Verifiable Requirements

A requirement that cannot be verified is not a requirement. Each flowed-down specification should state the parameter, the condition, the tolerance, and the verification method. Consider a load-limiter requirement:

REQ-RS-0142 (Restraint System Level)
The driver seat belt load limiter shall limit belt web force to
3.5 kN ± 0.4 kN at the retractor anchor during spool-out,
measured per SAE J211 filtering (CFC 60) in a sled test at
50 km/h delta-v, 0 ms to 120 ms window.

Verification method: Sled test, 3 samples, all within tolerance.
Parent requirement: REQ-VEH-0007 (driver chest deflection
≤ 42 mm in FMVSS 208 belted frontal, 56 km/h rigid barrier).

The parent-requirement field is what makes this traceable. When a supplier later proposes changing the load-limiter force to 4.0 kN to reduce cost, the change request can be evaluated immediately against REQ-VEH-0007: does the higher force still keep chest deflection within 42 mm? If the answer is unknown, the change cannot be approved without a sled test.

Managing Change Control and Configuration Baselines

Restraint programs run for three to five years, and requirements change constantly — regulatory updates, supplier process changes, vehicle mass growth, and crash-test discoveries all drive revisions. Configuration baselines are the mechanism that keeps this controlled. A baseline is a frozen, identified snapshot of all requirements, CAD models, CAE decks, and test reports at a defined program milestone. Common baselines include:

  • Concept baseline — vehicle targets and preliminary system architecture frozen.
  • Design baseline — subsystem and component specifications released to suppliers.
  • Verification baseline — the exact configuration that will be tested for homologation.
  • Production baseline — the configuration released for series manufacturing.

Every change after a baseline is frozen must go through a change control board (CCB) with a documented impact analysis. The impact analysis must answer three questions: which parent requirements are affected, which verification tests must be repeated, and which other components or systems share the interface. A change to inflator output, for instance, affects cushion pressure, which affects both occupant injury values and the airbag module's structural validation — so a single inflator change can invalidate multiple test reports.

Common failure mode: A supplier changes a propellant lot without notifying the OEM. The inflator still meets its mass-flow specification at the nominal test temperature, but at −35 °C the burn rate shifts, delaying deployment by 8 ms. The vehicle-level test fails, and because the change was never baselined, the root cause takes weeks to isolate. Traceability would have flagged the propellant lot as a controlled characteristic.

Practical Traceability Matrix and Change Impact

The working tool for traceability is a requirements traceability matrix (RTM). It is not a bureaucratic artifact — it is the fastest way to answer "what breaks if this changes?" A minimal restraint RTM has one row per requirement and columns for the requirement ID, level, parent ID, verification method, verification status, and baseline. The SVG below shows how a vehicle-level target decomposes into subsystem and component requirements, and how a single component change propagates upward through the traceability links to the affected vehicle-level verification.

Restraint Requirements Flow-Down and Change Propagation VEHICLE LEVEL REQ-VEH-0007 Driver chest deflection ≤ 42 mm SYSTEM LEVEL REQ-RS-0142 Load limiter 3.5 kN ± 0.4 kN COMPONENT LEVEL REQ-COMP-0311 Torsion bar diameter 4.2 mm flow-down flow-down CHANGE REQUEST Torsion bar 4.2 → 4.6 mm (cost reduction proposal) CR-2024-0087 impact? force ↑ chest deflection risk IMPACT ANALYSIS — REQUIRED BEFORE CCB APPROVAL 1. Parent requirements affected: REQ-RS-0142 (load limiter force), REQ-VEH-0007 (chest deflection) 2. Verification to repeat: sled test at 50 km/h, 3 samples; full-vehicle FMVSS 208 belted frontal 3. Shared interfaces: retractor spool, webbing routing, buckle load path — confirm no revalidation needed CONFIGURATION BASELINE UPDATE If approved: REQ-COMP-0311 rev B, REQ-RS-0142 rev C, verification baseline re-frozen, supplier PPAP updated If rejected: CR closed with rationale; original baseline remains valid and traceable

Making Traceability Work in Practice

Traceability fails when it is treated as documentation rather than engineering. Three practices keep it effective. First, link requirements to verification evidence, not just to each other. A traceability matrix that shows REQ-COMP-0311 → REQ-RS-0142 → REQ-VEH-0007 is incomplete unless it also shows which test report, at which baseline, verified each link. Second, control characteristics, not just part numbers. The propellant lot example above shows that a material or process characteristic can be as safety-critical as a geometry dimension; these must be flagged in the specification and monitored in the supplier's control plan. Third, re-baseline deliberately. Every approved change should trigger a baseline update with a clear revision history, so that a test report from six months ago can be matched to the exact configuration it validated.

When these practices are in place, a restraint program can answer the two questions that regulators, customers, and internal auditors always ask: "How do you know this component meets the vehicle target?" and "What happens if this component changes?" The answer is a traceable chain from the component specification to the vehicle-level injury criterion, with verification evidence at every link and a controlled change path for anything that moves.

← Previous 📖 Contents Next →