3. Deriving occupant safety requirements from FMVSS, ECE, and NCAP

Regulatory and consumer-test documents are written to define acceptable outcomes, not to tell an engineering team what to build. FMVSS 208 states that an occupant in a frontal crash must not exceed certain injury criteria; it does not specify the airbag vent size, the seat belt load limiter force, or the pretensioner stroke. The derivation task is therefore a translation problem: convert outcome-based legal and rating language into verifiable system requirements, then decompose those into component requirements that can be allocated, designed, and tested. This chapter shows how to perform that translation systematically, using a frontal-impact example that runs from regulatory text to a component-level specification.

Step 1: Classify the source and extract the binding statement

Not all source documents carry the same obligation. FMVSS requirements are legally binding in the United States; ECE regulations are binding for type approval in contracting markets; NCAP protocols are voluntary but commercially decisive. Before parsing, tag each clause with its obligation class, because this determines whether a requirement is a hard constraint or a design target with margin.

Take FMVSS 208, S5.1 (frontal barrier impact at 56 km/h with unbelted 50th-percentile male Anthropomorphic Test Device, ATD). The binding statement is a pass/fail condition on measured ATD responses: head injury criterion (HIC) ≤ 700, chest deflection ≤ 63 mm, and axial femur force ≤ 10 kN, each evaluated over the prescribed test window. The first extraction step is to record the test condition (impact speed, barrier type, ATD, belt status, seat position) alongside the acceptance criterion. A criterion without its condition is not a requirement — it is an unverifiable claim.

Step 2: Convert criteria into requirement statements with tolerance and verification method

Each extracted criterion becomes a system-level requirement written in a verifiable form. A workable pattern is: Under [condition], [system] shall [performance] within [tolerance], verified by [method]. For the frontal case:

  • SR-FR-01: Under the FMVSS 208 S5.1 unbelted 56 km/h frontal barrier condition, the restraint system shall limit driver HIC to ≤ 700, verified by full-scale sled or barrier test per the regulation's instrumentation and filtering requirements.
  • SR-FR-02: Under the same condition, the restraint system shall limit driver chest deflection to ≤ 63 mm.
  • SR-FR-03: Under the ECE R94 belted 56 km/h offset deformable barrier (ODB) condition, the restraint system shall limit driver HIC to ≤ 1000 and chest deflection to ≤ 75 mm (the ECE acceptance values differ from FMVSS — do not merge them).
  • SR-FR-04: Under the Euro NCAP frontal MPDB 50 km/h protocol, the restraint system shall achieve a dummy injury score consistent with a 5-star rating target, treated as a design objective with defined margin.

Note the deliberate separation of FMVSS and ECE criteria into distinct requirements. A common derivation error is to collapse them into a single "worst case" number, which loses the fact that the two tests use different barriers, belt states, and ATDs. The system must satisfy both, and the design must be verified against each condition separately.

Step 3: Decompose system requirements into component requirements

System-level injury criteria are emergent outcomes of several subsystems: seat belt (webbing geometry, load limiter, pretensioner), airbag (volume, venting, inflator output, deployment timing), seat structure (energy absorption, recline stiffness), and steering column (collapse stroke). Decomposition allocates a portion of the system budget to each contributor. This is where engineering judgment enters, and where traceability must be explicit.

For example, SR-FR-01 (HIC ≤ 700) can be allocated as: airbag module shall provide a cushion pressure–time profile that, in combination with the belt load limiter, keeps head deceleration below a derived envelope. The airbag requirement then becomes concrete: CR-AB-07: The driver airbag shall vent such that internal cushion pressure at 40 ms after deployment is 1.4 ± 0.15 bar at 23 °C, verified by static deployment pressure measurement. The load limiter requirement becomes: CR-BL-03: The retractor load limiter shall limit belt force to 4.0 ± 0.3 kN at 100 mm of payout, verified by tensile test.

Each component requirement must carry a derivation link back to the system requirement it serves, and a verification method that is achievable at the component level. If a component requirement cannot be verified without a full vehicle test, it is not yet decomposed far enough.

A useful discipline: for every component requirement, ask "if this requirement is met in isolation, does it demonstrably contribute to the parent system requirement?" If the link is only asserted, not argued, the traceability is cosmetic.

Step 4: Handle NCAP targets as objectives, not pass/fail

NCAP protocols assign points across body regions and combine them into a star rating. Deriving requirements from NCAP therefore requires converting a rating target into injury-response targets. A practical approach is to back-calculate from the rating thresholds: if a 5-star frontal result requires a combined dummy score above a defined value, allocate per-region response budgets (head, neck, chest, femur) that sum to that score with margin. These become design objectives with a stated margin (e.g., 10% response margin below the threshold), not legal pass/fail criteria. Mark them distinctly in the requirements database so that a design change that trades NCAP margin for FMVSS compliance is visible to the safety team.

Step 5: Close the loop with verification planning

Derivation is only complete when each requirement has a verification event. The verification matrix maps requirement ID to method (analysis, component test, sled test, full vehicle test), to the responsible team, and to the acceptance evidence. For the frontal example, CR-AB-07 is verified by static deployment pressure measurement at the supplier; SR-FR-01 is verified by full-scale barrier test at the OEM proving ground. The matrix exposes gaps: a system requirement with no component-level verification path is a risk, and a component requirement with no parent is scope creep.

Source documents FMVSS 208 Binding (US) 56 km/h barrier, unbelted HIC ≤ 700, chest ≤ 63 mm ECE R94 Binding (type approval) 56 km/h ODB, belted HIC ≤ 1000, chest ≤ 75 mm Euro NCAP Voluntary / rating 50 km/h MPDB Star-rating score target System requirements SR-FR-01 Driver HIC ≤ 700, unbelted Verify: full-scale barrier test SR-FR-02 Chest deflection ≤ 63 mm Verify: full-scale barrier test SR-FR-03 ECE R94: HIC ≤ 1000, chest ≤ 75 mm Verify: ODB test SR-FR-04 (objective) NCAP 5-star score target 10% response margin Component requirements CR-AB-07 · Airbag module Cushion pressure 1.4 ± 0.15 bar @ 40 ms Verify: static deployment pressure test CR-BL-03 · Belt load limiter Force 4.0 ± 0.3 kN @ 100 mm payout Verify: tensile test CR-ST-02 · Seat structure Recline energy absorption 1.2 kJ ± 10% Verify: component crush test CR-SC-01 · Steering column Collapse stroke 90 ± 5 mm Verify: axial crush test Verification matrix (excerpt) Requirement Method Responsible Evidence Status SR-FR-01 Full-scale barrier Vehicle safety Test report Planned CR-AB-07 Static deployment Airbag supplier Pressure trace Planned

Common derivation failures and how to catch them

Three failure modes recur in practice. First, condition stripping: a requirement is copied as "HIC ≤ 700" without the test condition, so it cannot be verified and may be applied to the wrong ATD or belt state. Second, criterion merging: FMVSS and ECE limits are combined into one number, hiding the fact that the two tests demand different restraint behavior — an unbelted FMVSS test and a belted ECE test pull the load limiter in opposite directions. Third, orphan components: a component requirement exists with no traceable parent, usually introduced by a supplier's existing design, which consumes budget without serving a system goal.

A practical check is to run the traceability both ways. Forward: every source clause maps to at least one system requirement. Backward: every component requirement maps to a system requirement, and every system requirement maps to a verification event. Any break in either direction is a finding to resolve before design freeze.

Do not treat NCAP-derived objectives as legal pass/fail criteria in the same database field as FMVSS requirements. Mixing obligation classes causes teams to over-constrain legal compliance or to under-invest in rating margin. Keep separate fields for obligation class, target value, and margin.

Worked example: from clause to component specification

Consider ECE R94's chest deflection limit of 75 mm for the belted ODB test. The system requirement SR-FR-03 captures it. Decomposition allocates the chest deflection budget across belt force limiting and airbag cushion support. A derived component requirement might read: CR-BL-05: The load limiter shall maintain belt force at 3.5 ± 0.3 kN between 50 mm and 150 mm of payout, verified by tensile test at 23 °C. The traceability record links CR-BL-05 → SR-FR-03 → ECE R94 clause, with the verification method and the responsible supplier recorded. When a later design change proposes a 4.5 kN limiter to improve FMVSS unbelted performance, the traceability record immediately shows the conflict with the ECE chest budget, and the trade study can be conducted with both constraints visible.

This is the practical value of disciplined derivation: not paperwork, but the ability to see, at the moment of a design decision, which regulatory and rating obligations are affected and by how much.

← Previous 📖 Contents Next →