2. Restraint system architecture
DRBFM (Design Review Based on Failure Mode) is only as good as the boundary you draw around it. Before any change can be analyzed, the review team must agree on exactly which physical and functional elements constitute the restraint system under review, how those elements interact, and which interfaces carry the highest consequence if a change propagates through them. This chapter establishes that scope: the seat belt system, the airbag system, the pretensioner subsystem, and the child restraint anchorage points, together with the electrical, mechanical, and occupant-state interfaces that bind them into a single safety function.
Why Scope Definition Precedes Failure Analysis
A restraint system is not a collection of independent parts; it is a coordinated occupant protection function that must deploy, restrain, and release within a tightly bounded time window. A change to one element — a new webbing material, a revised airbag inflator, a relocated anchorage — rarely stays local. It alters load paths, timing, occupant kinematics, and the assumptions embedded in every neighboring component. DRBFM's core discipline is to ask, for each change, "what did the design intent assume, and what does this change invalidate?" That question is unanswerable until the system boundary and its interfaces are explicit.
In practice, scope definition produces three artifacts that drive the rest of the review: a system boundary statement (what is in, what is out), an interface register (every connection across which a change can propagate), and a function allocation (which element delivers which protective function). The SVG below maps these relationships for a typical frontal-restraint architecture.
The Four Subsystems and Their Design Intent
Seat belt system. The belt is the primary restraint in nearly every crash mode. Its design intent is to couple the occupant to the seat and vehicle deceleration while limiting peak chest load through load-limiting retractors and controlled webbing payout. The elements that matter for DRBFM are the retractor (spool, locking mechanism, torsion bar or load-limiting profile), the webbing (material, width, elongation, routing through the D-ring), the tongue and buckle (latch strength, buckle switch signal), and the anchorages (B-pillar and floor attachment points). A change to webbing elongation, for example, shifts the timing of occupant forward excursion and therefore changes the airbag's required stand-off distance — a classic cross-subsystem propagation.
Airbag system. Airbags supplement the belt by distributing restraint loads over a larger area and managing head and thorax deceleration. The scope includes the driver and passenger frontal modules, side thorax and curtain airbags, and knee airbags, each with its own inflator, module housing, tear seam, and venting strategy. The design intent is defined by deployment timing, fill rate, vent area, and module position relative to the occupant. For DRBFM, the critical question is whether a change to inflator output, module geometry, or venting alters the pressure-time curve that the occupant interacts with — and whether that interaction remains within the injury-criteria targets assumed at the system level.
Pretensioner subsystem. Pretensioners remove belt slack within milliseconds of a detected crash, pulling the occupant into the correct position before the load-limiting phase begins. They may be pyrotechnic or motor-driven, mounted at the buckle, the retractor, or both. Their design intent is a specific slack-removal distance and timing relative to airbag deployment. Because pretensioners and load limiters act on the same webbing, a change to one almost always requires re-validation of the other; this coupling is one of the most frequently missed interfaces in change reviews.
Child restraint anchorages. ISOFIX/LATCH lower anchors and top tether anchors are structural interfaces that transfer child-seat loads directly into the body-in-white. Their design intent is defined by anchor strength, position tolerance, and accessibility. A change to seat frame geometry, floor reinforcement, or trim packaging can alter anchor position or load introduction, which in turn affects both child-seat compatibility and the structural validation basis.
Interfaces as the Real Unit of DRBFM Analysis
The subsystems above are easy to list; the difficulty lies in the interfaces between them. DRBFM treats each interface as a place where design intent can be silently invalidated. The table below captures the interface register that a review team should populate before analyzing any specific change.
| Interface | What crosses it | Typical change that stresses it | DRBFM concern |
|---|---|---|---|
| Belt ↔ Airbag | Occupant position, load sharing, timing | Webbing elongation or retractor lock profile | Airbag stand-off and pressure-time assumptions |
| Pretensioner ↔ Retractor | Slack removal distance, spool rotation | Tensioner stroke or firing delay | Load-limiter engagement timing |
| Anchorage ↔ BIW | Anchor loads, position tolerance | Floor or pillar reinforcement change | Structural validation basis and child-seat fit |
| ACU ↔ All pyrotechnics | Firing command, stage timing | Algorithm calibration or sensor relocation | Deployment decision and out-of-position risk |
| Buckle switch ↔ ACU | Belt status signal | Buckle redesign or switch type | Suppression logic and reminder function |
Translating Scope into a Review Boundary
A practical way to close scope definition is to write a boundary statement that names the elements inside the review, the elements explicitly outside it, and the interfaces that will be examined. For a change to, say, a revised passenger airbag module, the boundary might read: in scope — passenger frontal module, inflator, venting, module mounting, ACU passenger-stage calibration; out of scope — driver module, side airbags, belt hardware; interfaces under review — belt-to-airbag load sharing, module-to-instrument-panel mounting, ACU firing command. This statement prevents two common failures: analyzing a change in isolation and missing its propagation, or expanding the review so broadly that it loses focus.
With the architecture and interface register established, the review team has a defensible technical scope. Every subsequent change analysis can now be anchored to a named element, a stated design intent, and a specific interface — which is precisely the condition DRBFM requires to produce findings that are traceable rather than speculative.