3. Crash safety target hierarchy

Crash safety development does not begin with a CAE model or a sled test. It begins with a translation problem: regulatory and consumer-rating requirements are written at the level of a complete vehicle in a specific impact configuration, while the engineering work that actually delivers those results happens at the level of body structures, restraint systems, and individual components. The target hierarchy is the mechanism that connects the two. It converts an externally imposed pass/fail or star-rating obligation into a cascade of internally owned, measurable, and verifiable engineering targets.

A well-constructed hierarchy has four levels, each with a distinct owner, a distinct measurement, and a distinct verification method. Confusing these levels — for example, assigning a component-level intrusion target to a system engineer, or treating a legal limit as a design target — is one of the most common sources of late-stage program failure.

The Four Levels and What Each One Owns

Level	Typical target form	Owner	Verification
Regulatory / rating	Pass/fail criterion, star score, e.g. FMVSS 208, Euro NCAP MPDB	Homologation / safety attribute	Certification test, official rating test
Vehicle-level	Occupant response at the vehicle level: HIC, chest deflection, femur load, intrusion	Vehicle safety attribute	Full-vehicle crash test, full-vehicle CAE
System-level	Restraint performance, structure crush force, airbag timing, seat belt load	System / subsystem engineer	Sled test, subsystem CAE, component rig
Component-level	Material grade, gauge, geometry, weld/spot pattern, energy absorption	Component / body engineer	Material test, quasi-static crush, component CAE

The critical discipline is margin allocation. A legal limit is not a target; it is a floor. If FMVSS 208 permits a HIC of 700, a vehicle target of 700 leaves zero margin for production variation, test-to-test scatter, and aging. In practice, vehicle-level targets are set with an explicit margin below the legal or rating threshold, and that margin is then decomposed across the levels below.

Translating a Rating Requirement into a Vehicle Target

Consider a frontal offset requirement. Euro NCAP's MPDB test evaluates occupant protection through a star score derived from dummy injury criteria. The translation proceeds in three steps.

1. Identify the binding criterion. Determine which injury parameter actually limits the score — often chest deflection or HIC for the driver, and femur or tibia load for the passenger. The binding criterion, not the overall score, drives the target.
2. Apply a margin. If the rating threshold for full score corresponds to a chest deflection of 22 mm, a vehicle target of 18–19 mm is typical, reserving roughly 15–20% margin for variation.
3. Express the target in vehicle terms. The vehicle-level target is stated as a dummy response at a defined seating position, impact speed, and barrier configuration — for example, "driver chest deflection ≤ 19 mm at 50 km/h MPDB, 50th percentile male."

This vehicle-level target is the anchor. Everything below it must be traceable back to it.

Decomposing to System and Component Level

The vehicle-level occupant response is the result of two interacting systems: the restraint system (belt, airbag, seat, steering column) and the body structure (front-end crush, occupant compartment integrity). The decomposition must respect this interaction, because a change in one shifts the requirement on the other.

A practical decomposition for the chest deflection target above:

• Restraint system target: belt force limited to a defined peak through load limiter, airbag deployment timing within a window, seat belt anchor geometry fixed. The system engineer owns the belt force–time curve and the airbag pressure–time curve.
• Body structure target: occupant compartment intrusion at the toe pan and dash panel limited to a value that keeps the restraint geometry effective — for example, dash panel intrusion ≤ 120 mm at the target impact.
• Component targets: front rail crush force, material grade and gauge for the dash panel, spot-weld pattern, and the crash box energy absorption. These are the parameters a component engineer can actually change.

The decomposition is not a one-way cascade. It is iterative: a component change that reduces intrusion may increase deceleration, which changes the restraint requirement. The hierarchy must therefore be maintained as a linked set of targets with defined interfaces, not a static list.

Worked Example: Setting a Component Target from a Vehicle Target

Suppose the vehicle-level target is dash panel intrusion ≤ 120 mm at 50 km/h MPDB. The front structure is a dual-rail system. A simplified allocation:

Vehicle target: dash panel intrusion ≤ 120 mm
  ├─ Front rail contribution: ≤ 70 mm
  │    ├─ Crash box crush: 35 mm (energy absorber)
  │    └─ Rail bending/axial crush: 35 mm
  ├─ Dash panel / cowl contribution: ≤ 30 mm
  └─ Margin / interaction: ≤ 20 mm

Component target (crash box):
  - Material: DP590, gauge 1.6 mm
  - Trigger geometry: 45° notch, 2 per side
  - Target mean crush force: 85 kN ± 8 kN
  - Target energy absorbed: 3.0 kJ at 50 mm stroke
  - Verification: quasi-static crush at 10 mm/min, 3 samples

These component numbers are illustrative and must be confirmed by CAE and physical test. The point is that each number is traceable upward: the crash box crush force exists because the rail must absorb a defined amount of energy, which exists because the dash panel must not intrude beyond 120 mm, which exists because the restraint system needs a defined occupant compartment geometry to meet the chest deflection target, which exists because the rating requires it.

Verification and the Role of the Hierarchy

Each level is verified by a different method, and the hierarchy is only credible if the verification methods are correlated. A component crush test that does not correlate with the component's behavior in the full-vehicle CAE model breaks the chain. This is why correlation targets are themselves part of the hierarchy: for example, "component CAE crush force within ±10% of physical test" is a target owned by the CAE team.

The hierarchy also drives change management. When a late design change occurs — a new material, a supplier change, a styling-driven geometry shift — the engineer can trace which targets are affected and which verification steps must be repeated. Without the hierarchy, every change triggers a full-vehicle test, which is both slow and expensive.

Practical Construction Sequence

1. List all applicable legal and rating requirements for the target markets.
2. For each, identify the binding injury or performance criterion and the threshold.
3. Set vehicle-level targets with explicit margin below the threshold.
4. Decompose into restraint and structure system targets, defining the interface quantities.
5. Decompose system targets into component parameters with measurable acceptance criteria.
6. Define verification method and correlation target for each level.
7. Freeze the hierarchy at a program gate and manage changes through impact assessment.

The hierarchy is not a document to be filed. It is the working contract between the safety attribute, the system engineers, and the component engineers. Its quality determines whether the program discovers a shortfall in CAE at month 18 or in a physical test at month 30.

The diagram above shows the four-level cascade and, critically, the feedback path. The red dashed arrow represents the reality that component-level changes propagate upward: a material substitution that reduces mass may also reduce crush force, which changes the deceleration pulse, which changes the restraint requirement, which changes the vehicle-level occupant response. The hierarchy is only useful if this feedback is managed explicitly rather than discovered late.

In the next stage of the program, this hierarchy becomes the basis for the CAE and test plan: each target at each level maps to a verification activity, a responsible engineer, and a gate. The quality of the initial translation — particularly the margin allocation and the interface definitions — determines how much rework the program absorbs later.