2. Restraint system architecture and functions

A DFMEA is only as good as the system boundary it is built on. Before a single failure mode is written, the team must agree on what the restraint system is, what it does, and where its interfaces end. In an automotive occupant protection context, that means decomposing the system into its functional blocks — seat belts, airbags, pretensioners, and occupant detection — and expressing each block as a set of functions with measurable performance expectations. This chapter establishes that architecture and shows how to convert it into a defensible DFMEA scope.

Functional decomposition of the occupant restraint system

The restraint system is best treated as a layered architecture rather than a flat list of parts. At the top sits the system-level function: in a crash event, restrain occupants within the survival space defined by the vehicle structure, while managing deceleration loads to levels the human body can tolerate. That top function decomposes into four functional groups, each with its own sensing, actuation, and energy-management responsibilities.

• Seat belt system — provides continuous, low-level restraint in normal driving and moderate events; routes crash loads through the pelvis and thorax; includes buckle, retractor, webbing, and anchorages.
• Pretensioner — removes belt slack within milliseconds of a detected event, coupling the occupant to the restraint earlier and reducing excursion.
• Airbag system — provides supplemental, event-specific energy absorption for frontal, side, and curtain coverage; deployment must be timed to the occupant's position and crash severity.
• Occupant detection — classifies occupant presence, position, and size (e.g., child seat, small adult, out-of-position) and supplies the suppression/enable logic that gates airbag deployment.

Each group is a function carrier in DFMEA terms. The scope statement should name the carrier, its function, and the performance requirement it must meet — not the part number. For example: "Pretensioner shall retract ≥ 60 mm of webbing within 15 ms of a valid deployment command, without exceeding 4 kN peak belt force on the occupant." That sentence is already a DFMEA-ready function statement because it contains an action, a quantity, and a limit.

Interfaces are where most failure modes live

Restraint systems fail at boundaries far more often than inside components. The DFMEA scope must therefore explicitly capture the interfaces between functional blocks and between the restraint system and the rest of the vehicle. The most consequential interfaces are:

For each interface, the DFMEA should record the expected signal or load and the tolerance band within which the receiving function still performs. A useful discipline is to write the interface as a contract: "ACU supplies 1.75 A ± 0.15 A for 2 ms to each frontal initiator; the initiator must fire within 1 ms of current onset." Any deviation outside that contract becomes a candidate failure mode at the interface, not inside either component.

From architecture to DFMEA scope: a worked example

Consider a frontal restraint system for a mid-size passenger car. The team begins with the system function and walks the architecture top-down, assigning each function to a carrier and each carrier to a design responsibility. The output is a scope table that becomes the skeleton of the DFMEA worksheet.

Scope item S-03: Driver frontal airbag module
  Function:  Absorb occupant kinetic energy in 40–100 km/h frontal impacts
             by controlled venting, keeping chest deflection ≤ 50 mm.
  Carrier:   Driver airbag module (inflator + cushion + housing + trim door)
  Interfaces:
    - ACU firing loop (electrical, 1.75 A / 2 ms)
    - Steering wheel hub (mechanical, retention)
    - Cushion vent path (pneumatic, vent area 2 × 28 mm)
  Performance limits:
    - Time to 90% fill: ≤ 35 ms at 23 °C
    - Residual pressure at 80 ms: 0.4–0.7 bar
  Out of scope: steering column collapse (covered by S-07)

This block is deliberately narrow. It names the carrier, states the function with numbers, lists the three interfaces that matter, and explicitly excludes the steering column so that the column's own DFMEA does not double-count the same failure mode. That exclusion line is as important as the inclusions — overlapping scope is one of the most common causes of duplicated or contradictory failure modes across sub-team worksheets.

Occupant detection: the gating function

Occupant detection deserves separate treatment because it does not absorb energy — it decides whether other functions are allowed to act. Its DFMEA scope must therefore be written in terms of decision correctness, not physical performance. The relevant functions are presence detection, classification (e.g., 5th-percentile female, 50th-percentile male, child restraint), position sensing (in-position vs. out-of-position), and the suppression logic that maps classification to deployment permission.

A practical scoping technique is to enumerate the decision states the detection system can output and treat each transition as a function to be analyzed. For a passenger seat, the states are typically: empty, child seat present, small occupant, adult in position, adult out of position. The DFMEA then asks, for each state, what happens if the system reports the wrong state — for example, reporting "empty" when a child seat is present, which would suppress a deployment that should have occurred, or reporting "adult" when a rear-facing child seat is installed, which would enable a deployment that must be inhibited. These are the failure modes that matter, and they are invisible unless the architecture is decomposed into decision states first.

Visualizing the functional architecture

The diagram below shows the restraint system as a signal-and-load architecture. Sensing and decision paths run along the top; energy-absorption and load paths run along the bottom. The ACU sits at the junction, receiving classification and crash signals and issuing firing commands. Reading the diagram left to right traces the event sequence from detection to restraint; reading top to bottom separates the decision layer from the physical layer — a separation that maps directly onto the DFMEA's distinction between functional failure and hardware failure.

Scoping rules that keep the DFMEA coherent

Three rules keep the architecture-to-scope translation consistent across a large program. First, one carrier, one owner: every scope item must map to a single design-responsible engineer, so that failure modes are not orphaned or duplicated. Second, functions carry numbers: a function statement without a measurable limit cannot be assessed for severity or detection, and will produce vague failure modes. Third, interfaces are scoped once: when two subsystems share an interface, the interface is assigned to the subsystem that owns the receiving function, and the other subsystem references it rather than re-analyzing it.

Applying these rules to the example above, the driver airbag module owns the ACU-to-initiator interface because it contains the initiator; the ACU worksheet references that interface but does not duplicate its failure modes. The steering column collapse is explicitly out of scope, so the column team owns it. The result is a scope that is complete enough to be auditable and narrow enough to be finished.

With the architecture decomposed and the scope table populated, the team has what the DFMEA needs: a bounded system, named carriers, quantified functions, and explicit interfaces. The next analytical step — assigning severity, occurrence, and detection ratings to the failure modes that emerge from this structure — depends entirely on the clarity achieved here. A scope built on measurable function statements and single-owner interfaces will produce a DFMEA that supports design decisions; a scope built on part lists will produce a document that merely records them.