4. Cross-functional team formation for DRBFM

DRBFM (Design Review Based on Failure Mode) is only as strong as the diversity of the perspectives sitting at the review table. A restraint system change — whether it is a new retractor pretensioner, a revised anchor bracket, a seat-belt routing adjustment, or an airbag inflator variant — propagates across structural, occupant-kinematics, manufacturing, and regulatory domains simultaneously. If the review team is composed only of design engineers, the analysis will systematically miss the failure modes that matter most: process-induced variation, test-rig artifacts, and field-usage edge cases. This chapter defines who must be in the room, what each function contributes, and how the team operates so that the DRBFM produces a defensible change-risk assessment rather than a design-justification exercise.

Why the team composition is itself a design decision

DRBFM works by forcing the team to articulate what changed, what the change touches, and how the touched functions could fail. Each of those questions is answered differently depending on the functional lens applied. Design owns the intent of the change and the geometry/interface definition. CAE owns the predictive physics — occupant kinematics, structural integrity, and the sensitivity of those predictions to the changed parameters. Test owns the physical evidence and the validity of the test setup. Manufacturing owns the process capability and the variation that the change introduces on the line. Quality owns the linkage to field data, regulatory compliance, and the verification/validation closure logic. Remove any one of these and the DRBFM loses a class of failure modes.

A useful way to see the division of labor is to map each function to the DRBFM questions it is best positioned to answer. The diagram below shows this mapping as a working structure, not a sequence — the functions interact continuously throughout the review.

Design: owner of change intent and interface definition

The design engineer is the change owner and typically chairs the DRBFM. The design role is not to defend the change but to make it fully legible to the other functions. Concretely, design must bring: the change description with before/after geometry or specification; the interface list (what the changed part touches — anchor points, webbing path, buckle stalk, seat frame, trim, inflator connector); the tolerance and stack-up analysis for any dimensional change; and an explicit statement of what is not intended to change. That last item is frequently skipped and is the source of many missed failure modes — if the team does not know the intended boundary of the change, it cannot judge whether an observed effect is in-scope or a surprise.

In a restraint context, design should also flag any change that alters the load path into the vehicle body, because that is where restraint changes most often create cross-system effects. For example, moving a seat-belt anchor 15 mm outboard to improve comfort may change the belt-to-occupant angle at the shoulder, which changes chest deflection in a frontal impact, which changes the CAE boundary conditions and the test dummy positioning. Design must surface that chain, not wait for CAE or test to discover it.

CAE: predictive physics and sensitivity

CAE's contribution is to convert the change into predicted effects and, critically, to state how confident those predictions are. For a restraint change, the relevant CAE work is occupant-simulation (frontal, side, or rear depending on the change), structural simulation of the anchor/bracket, and a sensitivity study on the changed parameters. The sensitivity study is the part that most directly feeds DRBFM: if a ±2 mm anchor position shift produces a 3 mm change in chest deflection, that tells the team the failure mode "anchor position variation" deserves a control; if it produces negligible change, the team can deprioritize it with evidence.

CAE must also declare model validity limits. A restraint model correlated to a 50th-percentile frontal sled test does not automatically predict 5th-percentile or out-of-position occupant behavior. When the change touches an area outside the correlated envelope, CAE should say so explicitly, and the team should treat the corresponding failure modes as "prediction uncertain — test evidence required" rather than "predicted acceptable."

Test: physical evidence and rig validity

Test owns the physical verification and, in DRBFM, also owns a question the other functions cannot answer: is the test setup still valid after the change? A restraint change can invalidate a rig in subtle ways — a revised buckle stalk may change dummy seating, a new pretensioner may change the timing of belt load, a modified anchor may require a different fixture. Test must review the change against the existing DVP&R and identify which tests remain valid, which need re-baselining, and which new tests are required to cover failure modes that CAE cannot resolve.

Test also brings the failure-mode detection perspective: what does a marginal failure look like on the rig, and would the current pass/fail criteria catch it? For example, if the change is a revised webbing routing, the relevant observable may be belt slip or edge wear rather than a peak-load number, and the test engineer should propose the inspection method that makes that failure mode visible.

Manufacturing: process capability and line variation

Manufacturing is the function most often under-represented in DRBFM and the one that most often supplies the failure modes that reach the field. The manufacturing representative should bring process capability data for the changed feature (Cpk, or at minimum the observed distribution from the line), the fixture and tooling implications of the change, and any assembly-induced stress or distortion the change introduces. A restraint anchor bracket that is dimensionally correct on the drawing but requires a new weld sequence can introduce residual stress that changes the load path — a failure mode invisible to design and CAE but obvious to manufacturing.

Manufacturing should also state the variation the team must design against. If the changed feature has a Cpk of 1.0 on the current line, the DRBFM should treat the tolerance-limit condition as a realistic operating condition, not a theoretical worst case, and CAE/test should evaluate at that condition.

Quality: field linkage, compliance, and closure

Quality connects the review to the outside world. Its inputs are field and warranty data on the current design (what has actually failed, at what rate, under what conditions), the regulatory requirements the change touches (FMVSS 208/209/210, ECE R16/R94, or the applicable market requirements), and the closure logic for the DVP&R — what evidence will be accepted as proof that each identified failure mode is controlled. Quality also owns the traceability: each failure mode in the DRBFM should map to a verification action, an owner, and a completion criterion.

Operating the team: cadence, decision rights, and a working review record

The team should meet in a structured DRBFM session rather than a general change meeting. A workable pattern is a two-stage review: a first session where design presents the change and each function contributes its question class (the diagram above), producing a candidate failure-mode list; and a second session where the team dispositions each failure mode — accept with evidence, control by design, control by process, or verify by test — and assigns an owner and a closure criterion. Between sessions, CAE and test run the targeted analyses needed to resolve open items.

Decision rights should be explicit. Design owns the change definition; CAE owns the prediction and its stated confidence; test owns the physical evidence and rig validity; manufacturing owns process capability; quality owns the acceptance of closure evidence and regulatory sign-off. No single function should be able to close a failure mode that another function owns the evidence for. The review record should capture, for each failure mode: the changed element, the affected function, the failure mode description, the contributing function's assessment, the disposition, the owner, and the closure evidence reference.

Common team-formation failure patterns

• Design-only review: produces a change justification, not a risk assessment; process and field failure modes are absent.
• CAE as the sole technical authority: predictions are treated as evidence; uncorrelated regimes and rig-validity issues go unchallenged.
• Manufacturing invited late: process-induced failure modes surface after tooling is committed, forcing expensive late changes.
• Quality absent from the working sessions: closure criteria are defined after the fact, and regulatory impact is assessed by whoever remembers to raise it.
• No named change owner: the review drifts into a status meeting; failure modes are discussed but not dispositioned or tracked.

The team is not a formality attached to the DRBFM method — it is the mechanism by which the method sees beyond any single discipline. A restraint change reviewed by a complete, empowered, and explicitly-roled team will surface the failure modes that matter; the same change reviewed by design alone will produce a document that looks like a DRBFM but functions as an approval memo.