Nachrichten

[A. Heil]

Hello,

Thank you for your particularly interesting contribution to the FMEA-MSR. I would like to add a few more questions and a somewhat longer explanation of my point of view on the subject of “reducing the S-rating”.

Does the FMEA-MSR completely replace the previous mechatronic FMEA? Theoretically, there are small differences in the link between the detection measures and the type of error (as it was in the mechatronic FMEA) and the link to the cause of the error (as it is now in the FMEA MSR). But actually the idea of ​​monitoring the system during operation is the same.

The article mentions that a significance with S = 10 may only be reduced if the monitoring is so good that it can be rated with M = 1 (approx. At 11:30 minutes). This is so up-to-date under the AP table in Note 1. Doesn’t this contradict other parts of the MSR instructions?

Example from „4.5.7 Monitoring (M)“: Here in Figure 4.5-3 you can find a representation in which not so good monitoring is rated with an M = 6. According to the evaluation catalog for M = 6, the error is 90% discovered and 10% not discovered. I would continue to interpret this in such a way that 90% of this path now have a S = 6, F = 3 and M = 6 and thus receive an AP = N. The remaining 10% still have a S = 10, F = 3 and M = 6 thus an AP = H. This would now have to be processed further or concluded as sufficient with a reason. For example: „It is an ASIL B system that allows an SPFM of 90%“ (even if this does not necessarily have to be a hardware error, one could possibly argue this way.) Otherwise it would not make a sense to enter an M = 6 measure at all here (and, if necessary, to implement it), if everything still has to be rated with a S = 10 and the AP = H remains.

You set up a similar example in your lecture. I currently see the display of the S-max with S = 6 in the failure network as correct, since this path is taken if the monitoring measure is effective. If the measure does not work, the unsecured path takes effect.

In addition, Figure C2-1 (in the third illustration) shows that an M = 2 … 9 can also be used, which means that the paths are split up and there are two different S-evaluations. If M = 1, the path in the second representation in Figure C2-1 is effective and the entire S-weighting is reduced. In this case the basic DFMEA has to be adapted to represent it better.

In my opinion, the FMEA-MSR instructions in the AIAG / VDA manual are not yet fully developed and in some cases are still incorrectly described. This can also be seen when comparing the AP matrices for S = 10 and S = 9. According to this, it would take more effort to get a good AP for S = 9 than for S = 10. It is not logical.

It is also noticeable that in the examples in Figures 4.5-1, 4.5-2 and 4.5-3, the monitoring is linked to the type of error, as it was trained in the „Mechatronic FMEA“ taught by APIS. If you look at the sample forms (Figure B2.8-2), you can see the connection between the monitoring and the cause of the error, as was also implemented in APIS-IQ.

Greetings from Germany

Alexander Heil

[Moderator BT2020]

Quote Mr. Chad Johnson:

„Alexander, I appreciate your detailed comments on the presentation and welcome any further thoughts, comments, or suggestions as we forge our way into this “brave new world” of MSR! Please feel free to reach out to me directly at Chad.Johnson@apis-iq.com

Your question: “Does the FMEA-MSR completely replace the previous mechatronic FMEA?” is a good question. I think this has not been fully determined yet. The “mechatronic FMEA” was never really a formal entity with AIAG or VDA, and as such it does not have a solid reference point. The only thing was that it began the use of the mechatronic objects (error detection, response, and operating conditions), but not a great way to display them outside of the failure nets. I think the end result (just my opinion), is that the MSR-FMEA will ultimately replace the Mechatronic-FMEA.

Your statement: “In my opinion, the FMEA-MSR instructions in the AIAG / VDA manual are not yet fully developed and in some cases are still incorrectly described.” I completely agree. This was definitely an intention of mine in the presentation to show where things remain unclear. It was not a very clear set of requirements to build this MSR content in the IQ-Software. The IQ-Software developers did an outstanding job of putting this concept to the test. As practitioners and engineers, we must now flush out the bugs in the logic and rules. – Chad“

[Autor]

Beiträge