4. Planning and preparation

A DFMEA that begins with a spreadsheet and a meeting invitation will almost always drift. For CAE-driven restraint system analysis, the failure modes, load paths, and interface assumptions are too tightly coupled to simulation models to be captured by a generic template. Planning and preparation is therefore not administrative overhead — it is the phase where the analysis object, the physical and analytical boundaries, and the decision-making authority are fixed before any RPN or Action Priority is assigned. This chapter explains how to define those elements so that the DFMEA remains traceable to the CAE work products that support it.

1. Anchoring the scope to a defined system and a defined model

Scope in a restraint DFMEA has two dimensions that must be declared together: the physical system boundary and the analysis boundary. The physical boundary identifies which components are inside the DFMEA — for example, the driver airbag module, seat belt retractor and pretensioner, buckle, anchor plates, clock spring, and the restraint control module (RCM) calibration set. The analysis boundary identifies which CAE models, load cases, and occupant positions are in scope. A common planning error is to declare the physical boundary but leave the analysis boundary implicit, which later produces failure modes that no simulation actually addresses.

A practical way to fix both is to write a scope statement in the form of a structured sentence and then validate it against the model tree. For a frontal driver restraint system, a workable statement is:

System in scope: driver frontal restraint subsystem (DAB module, retractor/pretensioner,
buckle, anchor, clock spring, RCM frontal calibration)
Occupant models: Hybrid III 50th percentile male, 5th percentile female
Load cases: FMVSS 208 25 mph rigid barrier, 35 mph full frontal, 40% ODB at 35 mph
Analysis boundary: LS-DYNA occupant model v3.2, sled correlation status = validated
Out of scope: side airbag, curtain, rear occupant, pedestrian protection

The value of this statement is that it can be checked mechanically. Every failure mode entered later must map to a component inside the physical boundary and to at least one load case inside the analysis boundary. If a failure mode cannot be mapped, either the scope is wrong or the failure mode belongs to a different DFMEA.

2. Drawing boundaries that CAE can actually defend

Boundaries in restraint DFMEA are usually expressed as interfaces: the seat structure, the steering column, the vehicle body anchor points, the electrical architecture, and the occupant. Each interface is a potential source of failure modes that are easy to miss because they sit between teams. The planning task is to decide, for each interface, whether the DFMEA owns the failure mode or merely consumes an assumption from another team.

A useful convention is to classify each interface as owned, shared, or assumed. An owned interface means the restraint team is responsible for the failure mode and its detection. A shared interface means the failure mode is jointly analyzed and the DFMEA references the partner DFMEA. An assumed interface means the restraint DFMEA takes a fixed input — for example, a validated steering column collapse force — and does not analyze its failure. Recording this classification prevents the two classic boundary failures: duplicated failure modes across DFMEAs, and unowned failure modes that fall between teams.

3. Structuring the analysis object before the team meets

Before team composition can be decided, the analysis object must be decomposed into a structure the team can review. For restraint systems, a three-level decomposition works well: subsystem, component, and function. The function level is where CAE evidence attaches most naturally, because simulation outputs are usually expressed as performance against a requirement — occupant injury criteria, deployment timing, belt force, or bag pressure.

The following structure is a representative planning artifact for a driver frontal restraint subsystem. It is an example structure, not a measured result.

This table is deliberately built before the DFMEA worksheet is opened. It forces the team to agree on what "function" means at each level, and it exposes components whose CAE evidence is weak — a component with no credible evidence type is a planning risk, not a later surprise.

4. Composing a team that can close the CAE-to-DFMEA loop

Team composition for a CAE-driven restraint DFMEA differs from a conventional DFMEA team because the analysis must be able to challenge simulation assumptions. A workable core team includes a DFMEA facilitator, a restraint system design engineer, a CAE/occupant simulation engineer, a test and validation engineer, and a representative from the RCM or restraint electronics function. Supporting members are added for specific interfaces: seat structure, steering column, body anchor points, and manufacturing.

The critical role is the CAE engineer, and the critical question is authority, not attendance. The CAE engineer must be able to state, for each failure mode, whether the current model can detect it, whether the model is correlated for that load case, and what the model's known limitations are. If the CAE engineer is present only to supply numbers on request, the DFMEA will record failure modes that the simulation cannot actually support.

5. A planning checklist that produces a usable DFMEA header

The output of this phase should be a short, reviewable planning record rather than a long narrative. The following checklist is structured so that each item produces a field that later appears in the DFMEA header or the interface register. It is a template, not a record of a completed analysis.

• System statement: one sentence naming the subsystem, the vehicle program, and the variant or calibration set.
• Physical boundary: component list with part numbers or CAD references; explicit out-of-scope list.
• Analysis boundary: occupant models, load cases, model version, and correlation status for each load case.
• Interface register: each interface classified as owned, shared, or assumed, with the partner DFMEA or assumption source named.
• Function decomposition: subsystem, component, and function levels agreed and reviewed by design and CAE.
• Team roster: named individuals, roles, and the specific authority of the CAE engineer to challenge evidence.
• Evidence gaps: failure modes or components with no credible CAE evidence, flagged as planning risks with an owner.
• Review cadence: when the scope and boundary will be re-confirmed, and what triggers a re-review.

6. Common planning failures and how they surface later

Three planning failures recur in restraint DFMEAs and are worth recognizing early. The first is an analysis boundary that is narrower than the physical boundary: the DFMEA lists a component but no load case exercises it, so its failure modes are rated on engineering judgment alone. The symptom appears during review as severity ratings with no supporting evidence. The fix is to add the missing load case or to move the component out of scope explicitly.

The second is an assumed interface treated as owned: the restraint team analyzes a steering column collapse behavior that is actually the column team's responsibility, producing duplicated failure modes and conflicting severity ratings. The symptom is two DFMEAs with the same failure mode and different ratings. The fix is the owned/shared/assumed classification applied before the worksheet is populated.

The third is a CAE engineer without challenge authority: the simulation engineer supplies numbers but cannot flag that a failure mode is undetectable in the current model. The symptom is a detection rating that implies simulation coverage where none exists. The fix is to make the evidence check an explicit agenda item, with the CAE engineer's assessment recorded against each failure mode.

When these planning elements are in place, the DFMEA worksheet becomes a record of decisions that can be traced back to a defined system, a defined model, and a named owner for every interface. That traceability is what allows the analysis to survive a design change, a model re-correlation, or a program review — and it is the reason planning deserves its own phase rather than a single kickoff meeting.