nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Limitations of the causal metamodel in FMEAs

medini_1050701002

Hi, I am using this thread as a conversation starter for what is our only problem with Medini so far (everything else has been great!). The problem we experience is that the Occurence [0-10] attribute and the Safety Mechanism are only natively associated to the causes of a failure in the FMEA. What we usually experience in our FMEA is that the lowest level is the components (let's say a Resistor). The failure mode (e.g. short-circuit) is the lowest level where we can have occurence data (based on the failure rates of the components). We can add probable causes (an overcurrent could be the cause to that resistor short-circuit) but we have no idea of the occurence of such events. Similarly for the detection methods (modeled as Safety Mechanisms) we can often detect the failures (we can implement a test to detect the short-circuit) but we cannot detect the overcurrent and predict it will cause the short-circuit. For both those reasons we had to find workarounds based on customizing and profiling but it doesn't allow us to use some of Medini built-in features (risk tables, control groups...). Does anyone here already encountered this problem and what was your workaround?

Find more posts tagged with

medini

medini legacy

Accepted answers

All comments

medini_1024169437

Hi Gerard, I have seen your post a while back but hesitated to write a comment. Main reason is twofold, I may not get your problem right but I also have to good answer yet. Maybe we can drive the discussion by breaking the problem a bit down to single issues and maybe also see how you tried to solve that. What do you think? Jan

medini_1050701002

Thank you for your answer. I’ll start
by saying again this is not a big problem for us (as we have workarounds) and
it doesn’t exactly need “solving”. I’ll
explain what we experience further with a simple example. Before
using Medini we delivered FME(C)A like this to our customers: With the Occurrence
computed directly with the failure rate of the failure mode. In Medini
it now looks like this: The facts
that now the effects are directly in front of the level their refer to doesn’t
bother us, the way we used to do it before was mainly constrained by Excel. What
bothers us is that we can no longer compute the criticality (SxO in the
first table) for the failure modes of the components. This is because you
cannot access the cells in red if you don’t put a Potential failure cause
in the table. The Occurrence
can then no longer be computed with the cells in green. We could do
it at the higher level (cells in blue), but then it doesn’t match our
customers’ need to analyse our products at the electronic component level. What we’ve
done as a workaround is add another column for Occurrence and SxO
to do our computations. This is not ideal for us because we lose some Medini
features like the Risk tables. --- As I said
this is a simplified example, in practice we have failure causes (like
Overcurrent, Ageing) for our electronic components’ failure modes. But their
occurrence is impossible to evaluate (how would you evaluate the ageing of a
component?). I’ll try to provide an example with the failure causes for the two
tables. Also, this
problem is replicated with the Current Design Controls Detection column
(and the Detection value), similarly these columns are related to the Potential
Failure Causes and we used to have them related to the Potential
Failures (failure modes).

medini_1024169437

Got it. That need some internal discussion here with the POs. Once I have some valuable answer, I'll post it here. Stay healthy Jan

medini_1039539557

Hello Jan, I hope you and your family are safe and healthy in these strange days. I would like to ask if you have any updated on this since we experienced quite the same difficulty and couldn't find an easy workaround ( see my post from last year) Gerard, Thank you for raising it up here. Best regards, Alon

medini_1024169437

Hi Alon, yeah, all good here, strange times indeed. Hope you are healthy as well. I unfortunately have no real update here, but will take this as a trigger to keep discussion alive, it was a bit "silent" lately :-) Greetings Jan

medini_1024121064

Hi Gerard and Alon, the problem of "shifting the failure window" in an FMEA at the lowest level is also something that other users struggle with. However, there is no easy solution or other workaround than you described I guess. We had discussed internally several times to provide some sort of "HW FMEA" for the failure modes itself, but there are two reasons we hesitated to do this: Providing access to the Occurrence value is not enough as you pointed out. The Detection value would be needed to compute the RPN and this not available at the failure or measure, but at the measure group(s) of each cause. So lifting just the Occ. is not enough, but we would need to show also the controls (measure groups) of the failure mode itself. But in this case, we "shift" the complete analysis simply one level upwards - you can do the same by deriving an FMEA worksheet simply from the next higher level. The only limitation is that the FMEA worksheet view might need to be split since different models might exist at that level. Having an option to select "RPN of FM" could be an alternative solution, say switch the complete Occurrence and Detection columns to the failure mode. This would somewhat "flatten" the failure net and omit the causes completely (or say: make them informative only). We haven't worked out the details, but we thought this can a) either be achieved in an FMEA at the next higher level with a profile column for the causes (so same as above) or b) better based on an RPN option in an FMEDA worksheet (which is flat anyway). The FMEDA would currently not provide a split in the effect column, but anything else is already there, except editing of measure groups. Any thoughts or something we have overlooked? Greetings, Michael

medini_1050701002

Hi Michael, Thank you for your answer. Regarding (1) is it possible to exclude some elements of a derived FMEA? I know it is possible to exclude the leaves or to select a max level in the settings but that doesn't work very well for us because our models do not have unified levels (sometimes the components will be at level 3, sometimes at 4 in the same project, depending on the logistical structure of our products). Greetings, Adrien