3. Risk assessment frameworks for simulation pipelines

Simulation pipelines in automotive engineering are not single tools but chains of preprocessing, solver execution, post-processing, and data handoff. A failure anywhere in that chain—an inverted normal, a diverged turbulence model, a corrupted result file—can propagate silently into design decisions. Risk assessment frameworks give engineering teams a structured way to identify where a CAE or CFD pipeline can fail, how severe the consequence would be, and which controls deserve priority. Three complementary methods dominate practice: Failure Mode and Effects Analysis (FMEA), Fault Tree Analysis (FTA), and hazard analysis. Each answers a different question, and mature simulation teams use them together rather than choosing one.

FMEA: Bottom-Up Failure Identification

FMEA works inductively. It enumerates each component or step in the pipeline, asks how it can fail, and traces the effect upward to the simulation result and the engineering decision it supports. For a CFD workflow, a "component" might be the CAD geometry import, the mesh generation step, the boundary condition assignment, the turbulence model selection, or the solver convergence monitor. The standard scoring uses three dimensions: Severity (S), Occurrence (O), and Detection (D), each on a 1–10 scale, combined into a Risk Priority Number (RPN = S × O × D).

Consider a concrete example from an underhood thermal CFD analysis. The mesh generation step can produce highly skewed cells near the heat exchanger. The failure mode is "excessive cell skewness." The local effect is degraded gradient resolution; the system-level effect is underpredicted heat rejection, which could lead to an undersized cooling package. If severity is rated 8 (safety-adjacent thermal margin), occurrence 6 (common with complex fin geometry), and detection 4 (skewness metrics are checked but thresholds are loose), the RPN is 192—high enough to demand action. The recommended control might be tightening the maximum skewness threshold from 0.90 to 0.85 and adding an automated mesh quality gate before solver launch.

The strength of FMEA is coverage: it forces the team to walk every step and ask "what if." Its weakness is that it treats failures as independent. In reality, a single root cause—say, a unit conversion error in the CAD export—can trigger multiple failure modes across meshing, loading, and post-processing simultaneously. That is where FTA becomes necessary.

FTA: Top-Down Root Cause Tracing

FTA starts from an undesired top event and decomposes it deductively using Boolean logic gates. For simulation pipelines, a typical top event is "simulation result leads to incorrect design decision." The tree branches into contributing events connected by AND gates (all must occur) and OR gates (any one suffices).

Take a structural CAE example: a crash simulation predicts occupant injury metrics below the regulatory threshold, but the physical test later exceeds it. The top event is "false-negative safety prediction." An OR gate might connect two branches: (1) incorrect material model calibration, and (2) numerical instability masking a real response. The first branch further decomposes via AND gates into "stress-strain curve input error" AND "failure to validate against coupon test." The second branch decomposes into "time step too large" OR "hourglass energy exceeding 5% of internal energy without review."

FTA produces a minimal cut set—the smallest combinations of basic events that cause the top event. This is directly actionable: if the minimal cut set is {material curve error, no coupon validation}, then adding a mandatory coupon validation gate eliminates that entire path. Unlike FMEA's RPN, FTA gives a logical, not just numerical, priority.

Hazard Analysis: Linking Simulation to Physical Risk

Hazard analysis shifts the lens from "what can go wrong in the tool" to "what physical hazard does a wrong simulation result enable." In automotive context, hazards include thermal runaway, structural collapse, brake fade, and aero instability. A hazard analysis for a CFD-based brake cooling study would identify that an overpredicted cooling flow could lead to a design that overheats in track conditions. The analysis then traces backward to which simulation assumptions—inlet boundary condition, radiation model, or conjugate heat transfer coupling—most influence that hazard.

This backward linkage is what makes hazard analysis distinct. It does not score every failure mode; it prioritizes the ones that connect to a credible physical hazard. The output is typically a hazard-to-simulation traceability matrix that maps each hazard to the simulation parameters that govern it and the verification activities that bound the risk.

Integrating the Three Frameworks

The three methods are not competitors. A practical integration for a simulation pipeline runs as follows. First, hazard analysis identifies the physical hazards the simulation informs and the parameters that most affect them. Second, FTA is built for each high-priority hazard, tracing the logical paths from simulation error to hazard. Third, FMEA is applied to the pipeline steps that appear in the minimal cut sets, scoring and controlling them in detail. This avoids the common failure of applying FMEA uniformly across hundreds of steps and drowning in low-value RPNs.

Applying the Framework: A Worked CFD Example

Suppose a team is running an external aerodynamics CFD study to support a drag reduction decision. The hazard analysis identifies "overpredicted drag reduction leading to insufficient cooling airflow" as a credible hazard. The governing parameters are mesh resolution in the wake region, turbulence model choice (k-ω SST vs. realizable k-ε), and inlet turbulence intensity. The verification activity is correlation against wind tunnel data at two yaw angles.

FTA for the top event "drag reduction overpredicted by more than 5 counts" yields a minimal cut set: {wake mesh too coarse, turbulence model mismatch}. FMEA then targets those two steps. For wake mesh, the failure mode is "insufficient cell count in recirculation zone," severity 7, occurrence 5, detection 3, RPN 105. The control is a mesh independence study with three refinement levels and a GCI (Grid Convergence Index) below 3%. For turbulence model, the failure mode is "model not validated for separated flow," severity 8, occurrence 4, detection 2, RPN 64. The control is a model comparison run against wind tunnel pressure taps.

Common Pitfalls and Practical Guidance

• RPN inflation: Teams often assign high occurrence scores defensively, inflating RPNs and diluting priority. Calibrate occurrence against actual pipeline failure logs, not intuition.
• Ignoring detection: A failure mode with low severity but near-zero detection (e.g., a silent unit error) can be more dangerous than a high-severity mode that is always caught. Detection scores must reflect real monitoring, not assumed checks.
• Static FMEA: Simulation pipelines change with solver versions, mesh tools, and hardware. An FMEA that is not reviewed after a solver upgrade is a liability. Trigger a review on any change to solver version, turbulence model defaults, or meshing algorithm.
• FTA without minimal cut sets: Drawing a fault tree without computing minimal cut sets produces a diagram, not an analysis. The cut sets are the actionable output.

The integration of hazard analysis, FTA, and FMEA turns simulation risk management from a checklist exercise into a traceable engineering argument: this hazard matters, these logical paths lead to it, these specific pipeline steps are controlled, and these verification activities bound the residual risk. That traceability is what allows a CAE or CFD result to be defended in a design review—not just presented.