1. DRBFM fundamentals for restraint systems
Design Review Based on Failure Modes (DRBFM) is a disciplined engineering method for examining a design before a change is released, with the explicit goal of finding the ways the change could introduce new failure modes or reactivate old ones. In automotive restraint systems — airbags, seat belts, pretensioners, buckle switches, occupant classification sensors, and the electronic control unit (ECU) that orchestrates them — the method matters more than in most domains because the product is a life-safety device that sits dormant for years and must function correctly in a few tens of milliseconds. A restraint that deploys late, deploys with the wrong energy, or fails to deploy is not a quality defect; it is an injury or fatality risk. DRBFM exists to make the consequences of design change visible while there is still time to act.
Core Principles
DRBFM rests on a small number of principles that distinguish it from a generic design review or a late-stage FMEA.
- Change is the unit of analysis. The review is scoped to what is different — a new connector, a revised inflator curve, a changed mounting bracket, a software calibration update — rather than re-auditing the entire design. This keeps the review focused and makes it feasible to run on every change.
- Good design is preserved, not re-litigated. Existing, validated design elements are treated as known-good baseline. The question is not "is this part good?" but "does this change disturb something that was good?"
- Every change is examined for its effect on function. The team asks what the changed element is supposed to do, how it does it, and what happens to that function when the change is present.
- Failure modes are reasoned from the change, not from a checklist. A generic FMEA checklist will not tell you that moving a crash sensor 40 mm changes its response to a low-speed pole impact. DRBFM forces the team to reason about the specific geometry, timing, and interface consequences of the change.
- Cross-functional, evidence-based review. Design, validation, manufacturing, and supplier representatives examine the change together, and conclusions are supported by analysis, test data, or explicit engineering rationale — not by consensus alone.
Terminology in the Restraint Context
DRBFM borrows vocabulary from FMEA but applies it with restraint-specific meaning. The table below defines the terms as they are used in this course.
| Term | Meaning in restraint design |
|---|---|
| Change point | A specific, identifiable difference from the previous released design: a dimension, material, connector, calibration value, mounting location, or software parameter. |
| Function | What the element must do in the restraint system, e.g. "transmit crash pulse to ECU within 2 ms," "retain buckle tongue under 15 kN," "classify occupant as adult." |
| Failure mode | The manner in which the function fails: no deployment, late deployment, over-aggressive deployment, false buckle-latch indication, misclassification. |
| Effect | The consequence at vehicle level: increased injury risk, out-of-position deployment, failure to meet FMVSS 208 / 209 / 214 or ECE R94 / R16 requirements. |
| Cause | The design or process reason the failure mode could occur, e.g. connector contact resistance drift, bracket resonance, calibration table truncation. |
| Prevention control | Design measures that make the cause unlikely: derating, redundancy, tolerance stack analysis, robust connector selection. |
| Detection control | Verification that would reveal the failure before release: sled test, component bench test, HIL simulation, EOL (end-of-line) test. |
| Severity / Occurrence / Detection | FMEA-style ratings (typically 1–10) used to prioritize which change-induced risks need action first. |
Two terms deserve emphasis. A change point is not the same as a design revision number; it is the smallest unit of difference that could plausibly affect function, and a single revision often contains several change points that must be reviewed separately. Detection in restraint work is often weak: a failure mode that only appears in a specific crash configuration may not be caught by the standard validation matrix, which is precisely why DRBFM pushes teams to strengthen prevention rather than rely on detection.
The Role of Design Change Analysis in Automotive Safety
Restraint systems are developed under a regime of type approval and self-certification. Once a system is validated against the applicable regulations and internal requirements, any change reopens the question of conformity. Regulators do not review every change; the manufacturer carries the burden of demonstrating that the changed design still meets the requirement. DRBFM is the engineering instrument that makes this burden manageable: it produces a documented, traceable argument that each change point was examined, its potential failure modes were identified, and controls were defined and verified.
The safety case for DRBFM is strongest where change interacts with rare, high-consequence events. Consider a supplier-driven change from one airbag squib connector to a lower-cost equivalent. The connector still mates, still passes continuity check at end-of-line, and still fires in a nominal deployment test. But the new contact system has a different contact force and a different susceptibility to fretting corrosion over the vehicle life. A generic review may pass it; a DRBFM review asks specifically how the change affects the function "maintain squib circuit continuity over 15 years and 250,000 km," identifies contact resistance drift as a cause, and requires a vibration-plus-thermal-cycle qualification rather than a single bench continuity check. The value of the method is in that specificity.
How a DRBFM Review Is Structured
A practical DRBFM session for a restraint change follows a repeatable structure. The team first establishes the baseline: the released design, its validated functions, and the evidence that supports them. It then enumerates change points and, for each, states the affected function. For every change-point/function pair, the team reasons about what could go wrong, why, and what would prevent or reveal it. The output is a review record with actions, owners, and verification evidence — not a meeting minutes document.
A Worked Example: Sensor Bracket Relocation
To make the method concrete, consider a plausible change: the front crash sensor bracket on a body-on-frame vehicle is relocated 40 mm rearward to clear a new cooling package. The baseline function is "detect frontal deceleration and transmit a signal to the ECU within the required time window for the applicable crash modes." The change point is the bracket position and, implicitly, its stiffness and the sensor's orientation relative to the vehicle axis.
The team reasons about function impact. The sensor's mounting angle changes by approximately 3°, which alters the component of deceleration projected onto its sensing axis. For a 50 km/h full-frontal barrier event, the projected signal is reduced by roughly 0.1% — negligible. But for an oblique or offset event, the change in orientation and the change in local structural stiffness can shift the timing of the signal by several milliseconds, and the bracket's first bending mode may move closer to a frequency band excited by the new cooling package. The failure mode is not "sensor fails"; it is "deployment timing shifts outside the calibration window for a subset of crash modes."
Prevention controls include a tolerance and stiffness analysis of the new bracket, a check that the sensor axis remains within the calibration assumption, and a design change to the bracket ribbing if the modal analysis shows insufficient separation. Detection controls include a sled test in the affected crash configuration and a hardware-in-the-loop run with the updated sensor mounting model. The review record captures the analysis, the test evidence, and the residual risk. If the sled test shows timing within the calibration window, the change is closed; if not, the calibration or the bracket is revised and the review repeats.
What Good DRBFM Practice Looks Like
Effective DRBFM in restraint organizations shares several traits. Change points are enumerated at a granularity that matches the physics — a connector material change and a connector position change are separate change points even if they arrive in the same drawing revision. Functions are stated in measurable terms, with the crash mode and the acceptance window named. Failure reasoning is done by people who understand the sensing and deployment chain, not only by the person who made the change. Controls are assigned with owners and due dates, and verification evidence is attached to the review record rather than referenced by memory. Finally, the review is timed early enough that a finding can still change the design; a DRBFM completed after tooling release is documentation, not risk reduction.
The method's value in automotive restraint work is ultimately traceability under uncertainty. A restraint system cannot be fully tested against every occupant, every crash mode, and every service life condition. DRBFM provides a structured, auditable argument that each design change was examined against the functions it could affect, that credible failure modes were identified, and that the chosen controls are proportionate to the risk. That argument is what allows a change to be released with confidence — and what allows the next change to build on a baseline that is genuinely understood.