Failure mode and effect analysis: don’t solely trust your experts

S-FMEAs (System Failure Mode and Effects Analysis) and dysfunctional analysis in general are becoming cornerstones of product development when it comes to autonomous vehicles. As an example, functional safety standards like ISO 26262 and 15998 are more and more adopted by OEMs and suppliers to ensure their products’ reliability and safety.

In this blog post we explain why current Excel-based S-FMEA process can be error-prone and why connecting it to Simcenter Amesim can improve its overall quality.

Based on my experience, the process of working with S-FMEA is the following:



  1. At the beginning of a given project, reliability team asks system responsibles to update their S-FMEAs.

  2. The S-FMEA update is done through several brainstorming meetings with reliability engineer, system responsible, software engineer, hardware engineer… The aim is to determine the failures, their causes and effects and their importance using the Risk Priority Number (RPN) = Severity x probability of Occurrence x probability of Detection.

  3. Once the RPN is defined for all the failures listed, a report is shared with the project manager who decides for countermeasures. It can be either new requirements, new software calibration, new component sourcing, …

  4. The action plan to deploy these countermeasures is then handled by the project manager.

  5. S-FMEA is to be complete at a given project milestone (typically when product design is frozen).


Quite often, the S-FMEA is done using Microsoft Excel and stored in a shared repository (typically Sharepoint).

This way of working causes two main drawbacks:



  1. The Excel-based S-FMEA is not always up-to-date with respect to design changes. It is “backward looking” as would say @MarkS in his blog post: Model-based Product Safety & Reliability: forward vs backward looking design … 

  2. The content of S-FMEA strongly depends on human factor and so is error-prone. If one expert leave, the knowledge can vanish; if the expert don’t think out of the box, he may miss some failures; if one team member cannot join all the brainstorming sessions, the S-FMEA might be incomplete…


To avoid these drawbacks, a solution is to leverage the Simcenter Amesim digital twin of the product developed and used by CAE teams.

Let’s see how it works considering the Battery Management System S-FMEA of a given vehicle.


  1. The first step of the “digital twin-assisted S-FMEA” is, as before, to identify the failure modes and causes of the system through brainstorming sessions1_SFMEA_determining failure modes and causes.pngS-FMEA failure modes and causes identification


  2. Then, with the support of the Simcenter Amesim model owner (typically the system engineer or the simulation engineer), determine how these failures could be simulated on the Battery Management System model. This can be done through the Simcenter Amesim Excel Add-in by drag-and-dropping the selected Amesim parameters:

    (view in My Videos)



  3. Once the connection is done, define some failure values to selected parameters (either in Excel or in Amesim) and run simulations to see their effects dynamically on BMS performances.


    3_SFMEA_simulation_results.pngAmesim simulation results


  4. Finally, by analyzing these results, fill-in the S-FMEA effects columns so as the Severity and Probability of detection ratings. This step can be automated using Simcenter Amesim post-processing and scripting capabilities. Regarding the Occurrence rating, it requires a statistical approach that is not part of Amesim native capabilities:4_S-FMEA_RPN_calculation.pngS-FMEA RPN calculation




 We end up with much more reliable S-FMEA outputs that include the following benefits:





      • Quantitative results

      • Combinatorial failure effects easier to understand

      • Bi-directional connection between S-FMEA and digital twin (Through Simcenter Amesim Excel Add-in)




Then, the identified hazards can be followed-up by the project management team using Teamcenter or any other PLM solution.

A similar example of model-based fault diagnosis is depicted by Salim et al., 2017 [1].

Is this way of working similar to yours? Do you think it could help maximizing the value of your digital twin? Do you see any limitation to this methodology? Please comment or reach out to me.

[1] R; Salim et al., Fault Diagnosis of a Commercial PEM Fuel Cell System using Simcenter Amesim, IEEE 2017