3. Linking DFMEA to simulation requirements

A DFMEA that stops at a severity ranking and a detection rating has not yet produced engineering value. The real payoff comes when each failure mode is converted into a simulation requirement that a CAE engineer can execute without further interpretation. This chapter describes how to perform that conversion systematically: how a failure mode becomes a load case specification, how boundary conditions are derived from the design's actual interfaces, and how acceptance criteria are written so that a result can be judged pass or fail rather than merely "reviewed."

The central principle is traceability. Every load case in the simulation plan should be traceable back to a specific failure mode in the DFMEA, and every failure mode with a meaningful severity should be traceable forward to at least one load case or to a documented justification for why simulation is not applicable. When this bidirectional link is intact, a design review can ask "which load case covers this failure mode?" and receive a concrete answer.

From failure mode to load case specification

A DFMEA failure mode is usually written in functional language, for example: "Battery pack enclosure fails to maintain structural integrity under rear impact, allowing cell intrusion into the occupant compartment." This statement contains the ingredients of a load case but not the specification. To convert it, decompose the failure mode into four questions:

• What is the loading event? Rear impact, curb strike, torsional twist over a diagonal ditch, thermal expansion restrained by mounts, vibration over a durability profile.
• What is the magnitude and direction? A velocity change, an acceleration pulse, a force, a displacement, or a pressure, with a defined sign convention and coordinate system.
• What is the boundary condition? Which interfaces are fixed, which are sliding, which carry preload, and what the surrounding structure contributes.
• What is the failure threshold? The measurable quantity that distinguishes acceptable from unacceptable response.

Consider a worked example. A DFMEA line reads: Mode: enclosure weld seam cracks at the rear mounting bracket; Effect: loss of pack retention, severity 9; Cause: insufficient weld throat under combined rear impact and vertical bending. The conversion produces a load case specification such as: apply a rear impact pulse of 30 g peak, 80 ms duration, positive X direction (vehicle forward defined as +X, rearward impact therefore applied as a negative-X acceleration of the supported mass), with the pack mounted through its production bushings at the four body attachment points, bushing stiffness taken from the supplier curve at 23 °C, and the body-side attachments represented as rigid fixtures at the body mounting faces. The acceptance criterion is: no weld element exceeds the material's ultimate strain, and peak relative displacement between pack and body at the bracket does not exceed 12 mm.

Note what has happened. The vague failure mode has become a pulse, a direction, a mounting representation, a material property set, and two measurable thresholds. That is the level of specificity a CAE engineer needs.

Deriving boundary conditions from the design, not from convenience

Boundary conditions are where most DFMEA-to-simulation links break down. It is tempting to fix the mounting points and move on, but a fixed boundary is itself an assumption that can mask or manufacture failure. The correct approach is to derive boundary conditions from the interface control document and the DFMEA's own cause analysis.

For each attachment, ask: is this interface bolted, welded, bonded, clipped, or sliding? Does it carry preload? Is the mating structure stiff relative to the component, or compliant enough that its flexibility changes the load path? A pack mounted to a body-in-white through rubber bushings should not be modeled with rigid spiders at the bolt holes, because the bushing compliance is precisely what determines the bracket load. Conversely, a component welded directly to a stiff casting can often be represented with a fixed region, provided the fixed region is placed far enough from the region of interest that Saint-Venant effects do not contaminate the result.

Document the boundary condition rationale alongside the load case. A short note such as "body-side attachments fixed at body mounting faces; bushing compliance included via CBUSH elements with stiffness from supplier curve REV-C" is worth more than a page of prose, because it tells the next engineer exactly what was assumed and what to change if the assumption is challenged.

Writing acceptance criteria that can actually fail

An acceptance criterion is only useful if a result can violate it. "Stress below yield" is weak because it does not say where, under which load case, at which confidence, or with what margin. A defensible criterion names the quantity, the location or region, the threshold, and the basis for the threshold.

Typical forms include: maximum principal strain in the weld heat-affected zone below 8% (based on coupon testing); peak acceleration at the cell module interface below 60 g (based on cell crush data); relative displacement at the bracket below 12 mm (based on clearance to adjacent structure); first natural frequency above 35 Hz (based on road input spectrum and shaker capability); and fatigue life above 2× the durability target (based on the S-N curve with a safety factor).

Where a threshold is not yet established, the criterion should state the basis explicitly, for example "provisional: 8% strain, to be confirmed by coupon test T-114." A provisional criterion is honest; a missing criterion is not.

Structuring the traceability

The table below shows a compact traceability structure that links DFMEA lines to load cases and criteria. It is deliberately narrow: only the fields needed to make the link auditable.

The SVG below illustrates the conversion logic as a signal-and-structure diagram rather than a linear process: the DFMEA failure mode feeds a load case specification, which splits into loading definition and boundary condition derivation, both of which converge on the acceptance criterion, with a feedback path when the criterion cannot be met or the boundary assumption is challenged.

Common failure patterns in the conversion

Three patterns recur when teams attempt this link. First, the orphan failure mode: a high-severity DFMEA line with no corresponding load case and no documented justification. This is usually discovered late, during design review, and forces a rushed simulation. Second, the orphan load case: a simulation that has been run for years but no longer maps to any current failure mode, often because the DFMEA was revised and the simulation plan was not. Third, the unfalsifiable criterion: a criterion phrased as "stress acceptable" or "no significant deformation," which cannot be judged and therefore cannot trigger a design change.

A practical countermeasure is to review the traceability table at every DFMEA revision and at every simulation plan update, checking both directions. The review is short if the table is maintained; it is expensive if the table is reconstructed after the fact.

What a complete conversion looks like

A complete conversion has five properties. The failure mode is stated in functional terms with a severity. The load case specifies the event, magnitude, direction, and coordinate convention. The boundary conditions are derived from the interface definition and documented with their rationale. The acceptance criterion names a quantity, a location, a threshold, and a basis. And the whole chain is recorded in a traceability structure that survives revision. When these five properties are present, the DFMEA is no longer a paperwork exercise; it is the specification from which the simulation is built, and the simulation result can be read directly against the risk it was meant to address.