{"id":4393,"date":"2018-10-18T02:13:28","date_gmt":"2018-10-18T09:13:28","guid":{"rendered":"https:\/\/blogs.plm.automation.siemens.com\/t5\/Simcenter-Blog\/Failure-mode-and-effect-analysis-don-t-solely-trust-your-experts\/ba-p\/510679"},"modified":"2026-03-26T05:56:01","modified_gmt":"2026-03-26T09:56:01","slug":"failure-mode-and-effect-analysis-dont-solely-trust-your-experts","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/simcenter\/failure-mode-and-effect-analysis-dont-solely-trust-your-experts\/","title":{"rendered":"Failure mode and effect analysis: don’t solely trust your experts"},"content":{"rendered":"

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<\/A> and 15998 are more and more adopted by OEMs and suppliers to ensure their products’ reliability and safety.<\/P><\/p>\n

In this blog post we explain why current Excel-based S-FMEA process can be error-prone<\/STRONG> and why connecting it to Simcenter Amesim can improve its overall quality<\/STRONG>.<\/P><\/p>\n

Based on my experience, the process of working with S-FMEA is the following:<\/P>
\n


    \n
  1. At the beginning of a given project, reliability team asks system responsibles to update their S-FMEAs.<\/LI>
    \n
  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.<\/LI>
    \n
  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, …<\/LI>
    \n
  4. The action plan to deploy these countermeasures is then handled by the project manager.<\/LI>
    \n
  5. S-FMEA is to be complete at a given project milestone (typically when product design is frozen).<\/LI>
    \n<\/OL>
    \n

    Quite often, the S-FMEA is done using Microsoft Excel and stored in a shared repository (typically Sharepoint).<\/P><\/p>\n

    This way of working causes two main drawbacks:<\/P>
    \n


      \n
    1. The Excel-based S-FMEA is not always up-to-date with respect to design changes<\/STRONG>. It is “backward looking” as would say @MarkS<\/a> in his blog post: Model-based Product Safety & Reliability: forward vs backward looking design …<\/A> <\/LI>
      \n
    2. The content of S-FMEA strongly depends on human factor and so is error-prone<\/STRONG>. 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…<\/LI>
      \n<\/OL>
      \n

      To avoid these drawbacks, a solution is to leverage the Simcenter Amesim digital twin of the product developed and used by CAE teams.<\/P><\/p>\n

      Let’s see how it works considering the Battery Management System S-FMEA<\/STRONG> of a given vehicle.<\/P><\/p>\n


        \n
      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 sessions\"1_SFMEA_determiningS-FMEA failure modes and causes identification<\/span><\/span><\/LI>
        \n

      2. \n

        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:<\/P><\/p>\n

        \n
        <\/div>\n