4. Occupant restraint performance requirements

Restraint performance requirements are the technical contract between a vehicle program and the regulatory or consumer-information bodies it must satisfy. In a coordinated global program, these requirements are not a single document but a layered set of targets: regulatory minima (FMVSS 208, ECE R94/R95, GB 11551), consumer-rating thresholds (US NCAP, Euro NCAP, C-NCAP, Latin NCAP), and internal corporate targets that typically exceed both. Program coordination translates this layered set into verifiable deliverables — test matrices, CAE correlation criteria, hardware sign-off gates, and evidence packages — so that a single vehicle architecture can be certified in multiple markets without redundant or contradictory development loops.

Load Cases and Protection Targets

Four load cases dominate occupant restraint development. Each has distinct kinematics, distinct injury criteria, and distinct verification evidence.

Frontal protection targets are usually expressed as a set of dummy-response corridors rather than single pass/fail numbers. For a 50th-percentile male Hybrid III in a 56 km/h full-frontal rigid barrier test, a common internal target set is HIC₁₅ ≤ 500, chest deflection ≤ 40 mm, and femur axial force ≤ 6 kN per leg, with regulatory limits set higher (HIC₁₅ ≤ 700, chest deflection ≤ 63 mm). The gap between internal and regulatory targets is deliberate: it absorbs build variation, CAE-to-test correlation error, and late design changes.

Side impact targets are more sensitive to architecture because there is far less crush space. A typical internal target for a 50th-percentile ES-2re in a 50 km/h MDB test is rib deflection ≤ 28 mm and abdominal force ≤ 2.0 kN, with the pole test adding head HIC₁₅ ≤ 500. Rear impact targets center on whiplash metrics: NIC ≤ 15 m²/s² and N_km ≤ 0.30 for the 50th-percentile BioRID II. Rollover targets combine structural and restraint requirements — roof strength-to-weight ratio (SWR) ≥ 4.0 for internal targets, plus curtain airbag coverage sufficient to prevent head ejection through the side glazing.

From Targets to Verifiable Deliverables

The coordination challenge is that these targets must be verified with evidence that is acceptable in every market. A program coordination function therefore defines a deliverable set that is common across markets, with market-specific addenda only where regulations genuinely diverge.

A practical deliverable structure for a frontal load case includes:

• Test matrix: barrier type, impact speed, dummy size and position, seat position, belt configuration, airbag state, and temperature preconditioning.
• CAE correlation criteria: acceptable deviation between simulation and test for each injury metric, typically ±15% for HIC and ±10% for chest deflection, with documented model updates when exceeded.
• Hardware sign-off gates: sled test at component level, full-vehicle test at system level, and production-representative confirmation.
• Evidence package: raw sensor data, filtered channels, dummy certification records, and a traceability matrix linking each target to its verification result.

For side impact, the deliverable set adds intrusion measurement at defined door and B-pillar locations, airbag deployment timing windows, and curtain coverage maps. For rear impact, it adds seatback moment-rotation curves and head restraint geometry measurements. For rollover, it adds roof crush force-deflection curves and curtain deployment coverage relative to the occupant head position.

Worked Example: Translating a Frontal Target into a Sled Test Deliverable

Consider a program targeting Euro NCAP and FMVSS 208 compliance for a mid-size SUV. The coordination team defines a frontal sled test deliverable as follows.

Inputs: body-in-white with production seat, belt, and driver airbag; 50th-percentile Hybrid III; sled pulse derived from a 64 km/h ODB full-vehicle simulation; ambient temperature 21 ± 3 °C.

Execution: the sled pulse is applied, and the following channels are recorded at 10 kHz: head acceleration (three axes), upper neck forces and moments, chest deflection, and femur loads. The test is repeated three times to establish repeatability.

Observable verification criteria: HIC₁₅ ≤ 500, chest deflection ≤ 40 mm, femur force ≤ 6 kN, and channel-to-channel variation ≤ 5% across repeats. If any criterion is exceeded, the deliverable is not accepted, and the CAE model is updated to reflect the observed behavior before the next iteration.

Typical failure symptoms and troubleshooting: if HIC is high but chest deflection is within target, the likely cause is head contact with the airbag at an unfavorable angle or timing — check airbag venting and tether configuration. If chest deflection is high but HIC is acceptable, the likely cause is belt loading path or seatback stiffness — check belt geometry and load limiter setting. If femur force is high, check knee bolster stiffness and occupant packaging.

Rollover and Rear Impact: Coordination-Specific Considerations

Rollover and rear impact are often under-coordinated because they are less prominent in consumer ratings. However, they are increasingly regulated (FMVSS 216a, ECE R17) and are frequent sources of late-program surprises. The coordination deliverable for rollover should include a roof crush simulation correlated to a quasi-static test, plus a dynamic rollover or curtain deployment test that verifies head containment. For rear impact, the deliverable should include a seat structure test and a whiplash sled test with BioRID II, with head restraint geometry verified in the production seat position.

Injury Criteria Reference and Consistency

Injury criteria must be applied consistently across markets. HIC₁₅ is defined identically in FMVSS 208 and ECE R94, but the filtering and windowing can differ. Chest deflection is measured at different locations on different dummies. Neck injury criteria (Nij, N_km, NIC) are not interchangeable. The coordination deliverable should therefore include a criteria mapping table that states, for each market, which criterion is used, which dummy provides the measurement, and which filter class applies.

The diagram above shows the four-layer translation from requirements to verification. The requirement layer feeds the load-case layer, which feeds the deliverable layer, which feeds the verification layer. Each layer is a coordination artifact: the requirement layer is a negotiated target set, the load-case layer is a common test matrix, the deliverable layer is a set of evidence formats, and the verification layer is the pass/fail decision with traceability.

Closing the Loop: What Makes a Deliverable Verifiable

A deliverable is verifiable when it specifies the object under test, the input conditions, the measured channels, the acceptance criteria, and the evidence format. In a coordinated program, the same deliverable template is used across markets, with market-specific fields filled in as needed. This ensures that a test conducted for one market can be reused as evidence for another, reducing cost and schedule risk. The coordination function's role is to maintain this template, resolve conflicts between market requirements, and ensure that every target has a corresponding verification result before the program passes its final gate.