📚 Course ContentsChapter 2 Build the Restraint System Function Tree and Requirements Traceability

Chapter 1 Define Occupant Restraint System Boundaries and Interfaces for DFMEA
Chapter 2 Build the Restraint System Function Tree and Requirements Traceability
Chapter 3 Perform Severity and Occurrence Ranking for Airbag Inflator Failure Modes
Chapter 4 Develop Detection Ratings for Seatbelt Pretensioner and Load Limiter Failure Modes
Chapter 5 Construct the DFMEA Worksheet for the Seatbelt Retractor Subsystem
Chapter 6 Derive Design Verification Plan and Report (DVP&R) Test Cases from DFMEA High-Risk Rows
Chapter 7 Analyze Field Return and Warranty Data to Validate DFMEA Occurrence Assumptions
Chapter 8 Conduct a DFMEA Review for a Seatbelt Buckle Redesign and Capture Action Items
Chapter 9 Link DFMEA Causes to Design FMEA Prevention and Detection Controls for the Clock Spring
Chapter 10 Prepare the DRBFM Pre-Meeting Package from an Engineering Change Request
Chapter 11 Identify Concerned Engineering Characteristics for a Seatbelt Anchor Point Change
Chapter 12 Facilitate a DRBFM Workshop for an Airbag Cover Tear-Seam Change
Chapter 13 Apply the DRBFM 'Good-Bad' Analysis to a Retractor Web Sensor Modification
Chapter 14 Evaluate DRBFM Findings Against Existing DFMEA Coverage and Update the DFMEA
Chapter 15 Design a Validation Test for a DRBFM-Identified Failure Mode in the Pretensioner
Chapter 16 Perform a DRBFM for a Software Calibration Change in the Occupant Classification System
Chapter 17 Assess Supplier-Initiated Changes Using the DRBFM Process for an Inflator Component
Chapter 18 Integrate DRBFM Outputs into the Design Verification Plan for a Seatbelt System Change
Chapter 19 Conduct a DFMEA and DRBFM Consistency Audit Across a Restraint System Program
Chapter 20 Use DFMEA and DRBFM to Support a Safety Case for an Airbag Suppression Feature
Chapter 21 Analyze a Field Failure Using DFMEA and DRBFM to Determine Root Cause and Corrective Action
Chapter 22 Develop a DRBFM for a Manufacturing Process Change Affecting Restraint Performance
Chapter 23 Create a DFMEA for an Adaptive Restraint System with Multiple Deployment Stages
Chapter 24 Perform a DRBFM for a Change in the Restraint Control Module Mounting Location
Chapter 25 Quantify Risk Reduction from DFMEA Actions Using RPN and Action Priority
Chapter 26 Design a DRBFM Workshop Agenda and Facilitation Plan for a Cross-Functional Team
Chapter 27 Evaluate the Effectiveness of DFMEA Detection Controls Through Test Coverage Analysis
Chapter 28 Apply DRBFM to a Regulatory Compliance Change for Seatbelt Reminder Systems
Chapter 29 Integrate DFMEA and DRBFM with ISO 26262 Functional Safety Analysis for a Restraint System
Chapter 30 Conduct a Lessons-Learned Review of DFMEA and DRBFM Effectiveness on a Completed Restraint Program

2. Build the Restraint System Function Tree and Requirements Traceability

Why a Function Tree Must Precede Failure Analysis

DFMEA asks a single disciplined question: how can this function fail? That question is unanswerable until the function itself is written down at the right granularity. In a restraint system, "protect the occupant" is not a function — it is a mission statement. A function tree decomposes that mission into verifiable sub-functions, each with a measurable performance parameter, and then traces every leaf back to a vehicle-level requirement and a regulatory or consumer-test target. The traceability chain is what makes later severity, occurrence, and detection ratings defensible: a failure mode inherits its severity from the requirement it violates, not from engineering intuition.

This case builds that tree for a driver airbag and seatbelt restraint system, using the boundary established in the prior boundary/interface work. The deliverable is a traceability matrix in which every leaf function carries an ID, a performance parameter, a vehicle-level requirement, and a test target — so that when failure modes are enumerated later, each one maps to exactly one defined function.

Decomposition Logic: Four Functional Branches

Restraint performance is conventionally decomposed along the occupant's kinematic timeline. Four branches cover the driver-side system without overlap:

F1 — Occupant positioning: hold the occupant in the design seating position before and during the crash pulse (belt geometry, buckle engagement, pretensioner take-up).
F2 — Energy absorption: dissipate kinetic energy through controlled deformation and belt/airbag interaction so that occupant deceleration stays within injury-tolerance corridors.
F3 — Load limiting: cap the force transmitted to the chest through the belt and to the head/neck through the airbag, trading ride-down distance against peak load.
F4 — Deployment timing: trigger and stage the airbag and pretensioner so that the restraint is fully presented at the correct instant relative to occupant motion.

Each branch decomposes into two or three leaves. The leaves are deliberately written as functions with parameters, not as components — a component list ("inflator", "retractor") belongs in the boundary document, not the function tree. This separation is what allows a single component to serve multiple functions (the retractor contributes to both F1 and F3) and a single function to be served by multiple components.

Function Tree and Traceability Structure

The diagram below shows the four branches, their leaf functions with performance parameters, and the traceability links to vehicle-level requirements and test targets. Note that F4's leaves carry timing parameters in milliseconds, while F2 and F3 carry force and displacement parameters — the parameter type is a direct consequence of what the function must deliver.

Writing Leaf Functions That Survive DFMEA

The most common failure in this step is a leaf function that is too vague to fail in a specific way. "Provide restraint" cannot generate a meaningful failure mode; "F3.1 Torsion-bar force limit — belt force plateau 3.5–4.5 kN" can, because the failure mode "force plateau exceeds 4.5 kN" is immediately testable and immediately traceable to a chest-deflection requirement. Three rules keep leaves DFMEA-ready:

One verb, one parameter. Each leaf states what the function does and the parameter that proves it. If a leaf needs two parameters, it is probably two leaves.
Parameter must be measurable on a test. "Adequate" and "sufficient" are not parameters. Use the unit and the band that the validation test will actually record.
Trace to a requirement ID, not a document name. "FMVSS 208" is a regulation; "VR-SAF-021: HIC₁₅ ≤ 700 in 56 km/h ODB" is a requirement that a failure mode can violate. The requirement ID is what the severity rating will reference.

Building the Traceability Matrix

The matrix is the working artifact. For the driver system, populate it with the columns below. The example rows use the same IDs as the diagram so the two stay consistent.

Function ID	Function statement	Performance parameter	Vehicle requirement	Test target	Verification method
F1.1	Maintain belt fit and buckle engagement	Lap/shoulder gap ≤ 25 mm	VR-SAF-012	FMVSS 208 / NCAP slip check	Static fit check + sled
F1.2	Remove belt slack via pretensioner	Slack removal ≥ 60 mm	VR-SAF-014	FMVSS 209 / sled take-up	Sled with belt-pull sensor
F2.1	Absorb head energy in airbag cushion	HIC₁₅ ≤ 700	VR-SAF-021	FMVSS 208 / Euro NCAP ODB	Sled + full-vehicle ODB
F2.2	Provide belt ride-down	Chest deflection ≤ 50 mm	VR-SAF-022	FMVSS 208 chest criterion	Sled with chest potentiometer
F3.1	Limit belt force via torsion bar	Plateau 3.5–4.5 kN	VR-SAF-025	Sled force-plate	Sled force-plate measurement
F3.2	Relieve airbag pressure	Peak head accel ≤ 80 g	VR-SAF-026	FMVSS 208 head corridor	Sled + head accelerometer
F4.1	Sense crash and trigger deployment	Fire time 15–25 ms post-t0	VR-SAF-030	Sled timing / OOP	Sled with current probe
F4.2	Stage inflator output	Stage-2 delay 5–15 ms	VR-SAF-031	NCAP adaptive assessment	Sled with dual-stage current trace

Before moving to failure-mode enumeration, run a completeness check: every leaf must have a non-empty requirement ID and a test target. A leaf with a blank requirement column is a function nobody asked for — either find its requirement or delete it. A requirement with no leaf is a gap in the tree that will surface later as an unrated failure mode.

Verification and Common Pitfalls

Verify the tree by walking it in both directions. Top-down: does every vehicle-level requirement in the restraint scope land on at least one leaf? Bottom-up: does every leaf trace to a requirement that a customer or regulator actually imposes? A tree that passes both directions is ready to feed DFMEA structure analysis.

Typical failure symptoms at this stage: (1) leaves named after components ("inflator function") rather than functions — this collapses the tree into a BOM and destroys the ability to rate severity against requirements; (2) parameters without units or bands — these produce failure modes like "insufficient force" that cannot be ranked; (3) traceability to a document rather than a requirement ID — severity ratings then become subjective; (4) missing the timing branch entirely, which is common when the team thinks of restraint as purely structural, and which leaves deployment-timing failure modes orphaned. If any of these appear, correct the tree before proceeding — the cost of a bad function tree is paid in every downstream severity and detection rating.