What is the purpose of Failure Mode and Effect Analysis ?

[jani12]

Our embedded controller is Advanced Drive Assist Systems(ADAS). It basically has Two software layers. Application software and low-level software.

Our controller has many low-level functions such as different communications protocols, different types of memory, Digital outputs, PWM Outputs, and so much more.

What might be the benefit of performing Failure Mode and Effect Analysis(FMEA) on these low-level functions? Is the purpose of this exercise to catch low-level software design problems? Also, would this analysis help in debugging?

How to perform thorough FMEA on low-level software for a typical Automotive ADAS Controller?
For example, one Failure mode may be Loss of I2C communication or intermittent I2C communication. How to come up with all possible potential effects of this failure? How to come up with all possible Potential Causes of Failure?

How to identify all possible Failure Modes?

 

[wwfeldman]

the purpose of FMEA, or FMECA (failure mode, effects, criticality analysis) is to examine the hardware and software
for potential failures and their effect on operation and safety of the machine and humans.

the benefit is the discovery of degraded and failed modes of operation and safety
it is hard (impossible?) to design out all issues. the more different people look at the
machine, the more likely it is that a serious design flaw will be found.

That's why the designer(s) shouldn't do the reliability analysis or the FMECA.

basic modes of operation: normal, intermittent, incorrect, failed for anything
as you said, regarding I2C: total loss (like wires cut / or shorted / or inverted / wrong data rate at one end ),
intermittent (like bad connection, bad driver, bad receiver, multiple sources on at same time ... )

list all of the potential failures.
since there is a circuit involved, pins of an IC can be open, shorted to +VCC, shorted to GND,
they can oscillate (usually at the worst possible frequency)
if there is a transistor involved, each pin can be open or shorted to one of the other pins,
or it can oscillate, or anything else you can think of.

this should be useful
https://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis

don't forget to review some of the works in the biblography

 

[dick_freebird]

While DFMEA looks like a worthwhile "challenge process"
in my experience it turns into an worthless mound of
stuff to check and it never gets entirely done. A room
full of people can generate more "unfunded mandates"
than you can clear off in reasonable time, and this
design-process "gate" happens too late, like right
before tapeout (if you're talking IC development).
It's "a simple check-box" that ends up being the
opposite.

The "criticality" and "severity" and "probability" together
ought to give you priorities, but good luck with the
validity that these get assigned by their proponents.

Criteria for getting past this "gate" I have found pretty
arbitrary or nonexistent variously. What's "good enough"?

I sure do like working for myself and having no such
garbage "standard procedures" to deal with anymore.

 

[wwfeldman]

i must agree with dick_freebird
the few times i had to do FMECA, it was due the next day (or so)
and once we did it, it was over and we never heard anything more about it
and maybe once we found something that needed fixing before starting production

 

[ftsolutions]

As with anything, I think that the process has merit, and can even be critically important... but it is often misapplied or mis-scheduled in the development process to be effective - and thus some may consider it a useless task. Consider how proper, methodical effects analysis might have averted something like, 737MAX flight control system misbehavior when the sensor input is bad, how it was enunciated to the user interface, and what was necessary to disable it? On the other hand, FMEA of a simpler device like a screwdriver or bicycle pump is often not needed. Depending on the application and product complexity, it may be very valuable, as well as part of the customer's deliverables.

 

[wwfeldman]

and then there's the Challenger Space Shuttle
the engineers at Morton Thiokol said don't lauch, and we all know what happened

 

[schmitt trigger]

Don’t blame the tool. Blame the people who mis-use it.

Me, like Dick above, have suffered my share of poorly implemented DFMEAs.
Almost always because the powers who pull the strings don’t provide for the time and resources to do it correctly.
Or to implement the corrective actions that are identified.

Someone mentioned the Challenger. NASA had actually done a proper DFMEA and had properly identified the O ring brittleness at reduced temperatures. The engineers had actually seen failures and started the redesign but were never provided with the resources to implement them due to a very intense launch schedule.

Instead, they were requested to figure a containment action, which was not to launch if the ambient temperature was below certain value.

And we all know what happened, under intense political pressure, the Challenger’s launch was waived although all the booster specialists were fully aware of a potential failure.