4. Building the occupant safety requirements hierarchy

Occupant safety requirements rarely fail because engineers cannot write a sentence containing the word "shall." They fail because the hierarchy that connects a stakeholder's expectation to a component's acceptance criterion is broken somewhere in the middle: a regulatory threshold is copied verbatim into a subsystem specification without decomposition, a crash pulse assumption is lost between system and component level, or a component supplier receives a force target with no statement of the boundary conditions under which it applies. This chapter describes how to construct a coherent, verifiable requirements hierarchy for occupant safety, moving from stakeholder needs through system requirements to subsystem and component specifications, and how to keep the links between those levels traceable.

The four-level structure and what each level owns

A workable occupant safety hierarchy has four levels, each with a distinct ownership and a distinct vocabulary. The levels are not arbitrary; each one answers a different question and is verified by a different class of evidence.

The critical discipline is that each level must be derived from the level above, not restated from it. A stakeholder need such as "the occupant must be protected in a 56 km/h frontal barrier impact in accordance with FMVSS 208" is not a system requirement. The system requirement states what the vehicle must achieve, for example a head injury criterion (HIC15) value below a defined limit for the 50th-percentile male dummy in the driver position, measured under a specified barrier, speed, and pulse. The subsystem requirement then allocates part of that budget to the airbag, part to the seat belt, and part to the structure, with explicit interface conditions. The component specification finally states what the airbag module must deliver: mass flow, vent size, inflator output versus time and temperature, and deployment timing.

Decomposition: turning a need into an allocated budget

Decomposition is where most traceability value is created or destroyed. A useful technique for occupant safety is performance budgeting: the vehicle-level injury metric is treated as a budget that is allocated across contributing subsystems, with each allocation carrying an explicit assumption about the others.

Consider a frontal impact example. The system requirement might be stated as: for the driver position in a 56 km/h frontal barrier test, HIC15 shall not exceed 700 and the chest deflection shall not exceed 50 mm. The engineering team then decomposes this into contributions. Structure and restraint together determine the occupant's forward excursion and the timing of restraint engagement; the airbag determines head deceleration; the belt determines chest loading. A representative allocation (illustrative values, not measured results) might assign the structure a target of limiting intrusion at the toe pan and steering column to a stated value, the belt a chest deflection contribution of no more than 40 mm at the subsystem level, and the airbag a head acceleration profile consistent with the remaining HIC budget.

The allocation must record the coupling assumptions. If the belt allocation assumes a force limiter set at 4 kN, that value becomes an interface condition that the belt subsystem requirement must carry and the airbag requirement must be consistent with. When the force limiter is later changed to 3.5 kN, the trace link tells the team which airbag and structure requirements must be re-examined. Without that link, the change propagates silently and the hierarchy becomes fiction.

Writing requirements that survive verification

At subsystem and component level, the most common defect is a requirement that is technically true but unverifiable. "The airbag shall protect the occupant" is unverifiable. "The airbag module shall deploy within 25 ms of receiving the firing command at 23 °C ± 5 °C" is verifiable, but incomplete unless the measurement point, the definition of "deploy" (for example, bag fully inflated to a defined pressure or volume), and the tolerance are stated.

A well-formed component specification for occupant safety typically contains: the performance parameter and its target with tolerance; the test condition (temperature, state of charge, mounting orientation, input pulse or command); the measurement method and instrumentation; the acceptance criterion; and the trace reference to the parent subsystem requirement. The following is an illustrative specification fragment for a seat belt retractor with a force limiter, showing the level of detail expected:

Component: Seat belt retractor, driver, part family R-214
Parent subsystem requirement: SUB-RS-017 (belt chest contribution)

Performance:
  Force limiter level ......... 4.0 kN ± 0.4 kN, measured at the shoulder
                                belt outlet, 100 mm from the retractor
  Spool-out characteristics ... force limiter active from 2 kN belt force,
                                continuous spool-out to 120 mm minimum
  Locking ..................... lock within 50 mm of belt withdrawal at
                                0.3 g vehicle deceleration

Test conditions:
  Temperature ................. -35 °C, 23 °C, +85 °C (three samples each)
  Input ....................... sled pulse per SUB-RS-017 Annex B
  Dummy ....................... Hybrid III 50th percentile male

Acceptance:
  All samples within tolerance; no belt slip exceeding 25 mm after lock

Trace: SUB-RS-017 -> SYS-RS-004 -> SN-FMVSS208-01

Note that the specification does not restate the vehicle-level injury target. It carries only what the component must do, plus the trace reference that allows a reader to walk upward. This keeps each level readable and prevents the hierarchy from becoming a stack of duplicated text that drifts out of sync.

Keeping the hierarchy traceable

Traceability in this context means that for every component specification there is an unbroken, documented path to a stakeholder need, and that every stakeholder need is covered by at least one system requirement. Two link types matter: derivation links (this requirement was decomposed from that one) and verification links (this test evidence demonstrates satisfaction of that requirement). A requirement with a derivation link but no verification link is an open item; a verification result with no derivation link is orphaned evidence.

The figure below shows the hierarchy for a frontal occupant protection example, including the allocation of the injury-metric budget and the interface conditions that must be carried downward.

Change propagation and the value of the hierarchy

The hierarchy earns its cost when something changes. Suppose the force limiter is revised from 4.0 kN to 3.5 kN to reduce chest loading. With a maintained hierarchy, the change is entered at the belt subsystem requirement, and the trace links immediately identify: the retractor component specification (force limiter level and spool-out), the airbag subsystem requirement (because the coupling assumption of 4.0 kN is now invalid and the head budget must be re-checked), and the system requirement verification plan (because the full-vehicle test correlation may shift). Without the hierarchy, the retractor is updated, the airbag is not re-examined, and the discrepancy surfaces only in the next full-vehicle test — or worse, in the field.

Two governance practices keep the hierarchy honest. First, every requirement must have a named owner at its level; the system requirement owner is accountable for the allocation, not the component engineer. Second, the hierarchy is reviewed at defined gates against a coverage check: each stakeholder need has at least one system requirement, each system requirement has at least one subsystem allocation summing to its budget, and each subsystem requirement has at least one component specification with a verification method. Gaps found at the gate are cheaper than gaps found at the barrier.

The result of a well-built hierarchy is not paperwork. It is the ability to answer, for any component on the vehicle, why it has the performance it has, what happens to occupant safety if that performance changes, and which test will demonstrate that the requirement was met. That is the working definition of requirements traceability in occupant safety, and it is what the remaining levels of this course build upon.