3. Requirements flowdown

Occupant restraint verification rarely fails because a team cannot run a sled test. It fails because the requirement that the sled test was supposed to prove was never translated into something a component engineer could design against. A regulation such as FMVSS 208 or ECE R94 states an outcome at the vehicle level — a head injury criterion limit, a chest deflection limit, a belt force ceiling. A retractor supplier, a seat structure analyst, and a buckle manufacturer cannot design to "HIC ≤ 700." Requirements flowdown is the discipline that converts these top-level, vehicle-level obligations into allocated, measurable, and traceable specifications at the subsystem and component level, with margins that account for the uncertainty of the integration chain.

Why Flowdown Is Not Just Decomposition

Naive decomposition assigns each child requirement a fraction of the parent budget. Real flowdown must handle three complications. First, load paths are shared: belt force is reacted by the retractor, the buckle, the anchorages, and the seat frame in parallel, so a single force budget cannot simply be divided. Second, the parent metric is nonlinear: HIC is a function of resultant head acceleration over a time window, so allocating "half the HIC" to the seat and "half" to the airbag is physically meaningless. Third, regulations and consumer protocols differ in boundary conditions — barrier type, impact angle, seat position, dummy size, and pass/fail metric — so the same physical hardware may face several distinct requirement sets that must be reconciled before allocation.

A workable flowdown therefore proceeds in four movements: normalize the source requirements into a common set of load cases and metrics; identify the physical load paths and energy-absorbing elements; allocate targets with explicit margins and assumptions; and express each allocation as a specification that can be verified by a defined method at the correct level of assembly.

Step 1 — Normalize the Source Requirements

Start by building a requirement register that captures, for every applicable regulation and rating program, the load case and the acceptance metric. The table below is an illustrative extract for a mid-size passenger car; actual values must always be taken from the current published regulation or protocol text.

Normalization means converting each metric into a common currency where possible. For restraint hardware, the most useful currency is belt force at the retractor and buckle, because it is the physical quantity that the belt system actually controls and that the seat and body structure must react. Injury metrics such as HIC and chest deflection are then treated as response targets that the belt force profile must produce, verified later by sled or CAE.

Step 2 — Map the Load Paths

Before allocating numbers, draw the physical path from the occupant to the ground. In a three-point belt system the lap and shoulder portions share the occupant's kinetic energy; the shoulder load passes through the D-ring, the retractor, and the B-pillar or seat-back structure; the lap load passes through the buckle, the buckle stalk, and the seat frame or floor anchorages. Each element in that chain has its own stiffness, strength, and failure mode, and each will be a specification owner.

Step 3 — Allocate with Explicit Margins

Allocation is where engineering judgement must be documented, not hidden. Suppose the vehicle-level target is a chest deflection of 40 mm for the 50th percentile occupant in the 56 km/h frontal case, and CAE sensitivity studies show that a 1 kN reduction in shoulder belt force reduces chest deflection by approximately 3 mm. The restraint system therefore needs a shoulder belt force envelope that keeps the peak below a value consistent with the 40 mm target, with margin for build variation and dummy positioning.

A defensible allocation records four things for every child requirement: the allocated value, the margin (how much of the parent budget is held back for integration uncertainty), the assumption (e.g., "seat frame stiffness contributes 15% of total chest loading"), and the verification method (component test, subsystem sled, or full vehicle). For example:

Requirement ID: RS-RET-014
Parent:        RS-SYS-003 (shoulder belt force envelope, 56 km/h frontal)
Allocated:     Load limiter plateau 4.0 kN ± 0.4 kN, sustained 40–80 ms
Margin:        0.6 kN held at system level for seat/trim interaction
Assumption:    Retractor payout ≤ 15 mm before lock; no spool slip above 6 kN
Verification:  Component tensile test per internal spec TS-114, 5 samples,
               plus subsystem sled confirmation at vehicle level
Owner:         Retractor engineering

The margin is not padding. It is the quantified allowance for the fact that the component will be tested in isolation but will perform inside a system whose stiffness, geometry, and timing differ from the component test fixture. Without a stated margin, the first full-vehicle test becomes the discovery mechanism, which is the most expensive possible place to learn.

Step 4 — Make Each Specification Verifiable

A specification is verifiable when it names a measurable quantity, a tolerance, a test condition, and an acceptance criterion. "Retractor must be robust" is not verifiable. "Retractor shall lock within 15 mm of webbing payout when subjected to 0.7 g deceleration in the vehicle longitudinal axis, verified by five samples on the deceleration sled per TS-114" is verifiable. The same discipline applies to the buckle, the seat frame, and the anchorages.

Reconciling Conflicting Source Requirements

FMVSS, ECE, and consumer protocols often pull in different directions. A load limiter plateau that is low enough to reduce chest deflection in the consumer frontal test may increase head excursion in the FMVSS 208 offset case, because the occupant moves further forward before the belt engages fully. The flowdown must therefore carry both constraints into the same component specification and resolve them explicitly — for example, by specifying a two-stage load limiter whose switching threshold is a function of belt payout, or by tightening the pretensioner firing window so that the effective restraint onset is earlier without raising the plateau.

This is why the requirement register must be maintained as a living document. When a source requirement changes, the affected allocations, margins, and verification methods must be re-examined, and the traceability from component specification back to regulation must remain intact. A component that passes its own test but cannot be traced to the vehicle-level requirement it supports is a verification gap waiting to surface in the final vehicle test.

In practice, the flowdown is complete when every vehicle-level requirement has at least one allocated subsystem requirement, every subsystem requirement has at least one component specification, and every component specification has a named verification method and an owner. The traceability matrix that results is not paperwork — it is the map that tells the verification team exactly which test proves which requirement, and where the remaining margin sits if a test comes back marginal.