PCBA Hardware Component different failure types - How to rate detection?

[Cephissus]

Hello all,

Let's say that a PCBA uses a specific Resistor in it.

We identified in the FMEA two different failure modes:

- Resistance too low: This is a design issue in which we wrongly calculate the Resistance value of the component
- Short circuit due to silver migration: This is a common failure of a component. Note that in this case the Resistance value was perfectly designed, but the component failed regardless of the defined initial value.

In the first case, Resistance too low, I can rate a low Occurrence value on the fact that we have used this PCBA design multiple times, that we have successfully dimensioned this specific Resistor several times, that we have good calculation sheet to determine its value.
I can also rate a low Detection value based on the fact that we have standard and effective testing method to verify whether the right Resistance value was selected.

In the second case, however, I can rate the occurrence value based on the standard FIT value given for this component based on its environment.

The question is: how do I rate detection for this second form of failure mode?

 

[yodon]

Apologies for the delay (work, vacation...)

I don't use detection in a design FMEA. Where a component can fail such that a hazardous situation is exposed, the design needs to incorporate updates to mitigate. This could be through redundancy (inherent safety by design) or taking action to prevent harm (protective measures like alarms).

 

[GRP]

Hello all,

Let's say that a PCBA uses a specific Resistor in it.

We identified in the FMEA two different failure modes:

- Resistance too low: This is a design issue in which we wrongly calculate the Resistance value of the component
- Short circuit due to silver migration: This is a common failure of a component. Note that in this case the Resistance value was perfectly designed, but the component failed regardless of the defined initial value.

In the first case, Resistance too low, I can rate a low Occurrence value on the fact that we have used this PCBA design multiple times, that we have successfully dimensioned this specific Resistor several times, that we have good calculation sheet to determine its value.
I can also rate a low Detection value based on the fact that we have standard and effective testing method to verify whether the right Resistance value was selected.

In the second case, however, I can rate the occurrence value based on the standard FIT value given for this component based on its environment.

The question is: how do I rate detection for this second form of failure mode?

I suggest you do use detection and to start by defining the requirement, i.e. PCBA to last for n hours under normal operating conditions ("normal" being defined somewhere).

The failure mode is identified: short circuit due to silver migration
The cause: depending on how you frame the analysis, you can remove silver migration from the FM and put it here. Otherwise decide if you will put the cause of silver migration and/or other causes going deeper.

The prevention, state what feature of your design prevents the PCBA failing before the defined requirement

The detection, state how are you going to detect if your PCBA will meet or not your requirement. If you look at J1739 you can basically perform pass/fail test, test to failure or degradation with measurements before and after. These tests rank 8-6 if this happens after release and 5-3 if it is before release. Bear always in mind this comes from a table which is a guideline.

I think that if you start by properly defining the requirement then you will see how to apply the detection controls.

Let me know if you are still following the subject and we can continue sharing views

 

[Bev D]

Let’s think about the detection of silver migration in a slightly different way. When are you going to try to detect it? During design validation or during use? Do you know what causes Silver migration? Are you intending to try to detect the causes of silver migration?

 

[Cephissus]

Thanks Yodon. If you don't use Detection, how do you rank it in D? How is the RPN calculated?

Thanks GRP. You make me realize that Silver Migration should be described at lower cause levels. Maybe in the material properties of the Resistor or something. But still you talk about a detection of the PCBA failure, not about the Silver Migration failure itself.

Thanks Bev D. So since I know already that the part is going to fail sometimes because of Silver Migration, it's almost like I don't need to detect it. Yes that's it I guess. Detection should be ranked to 1 because everybody knows it's going to happen and you don't even have to test it. Therefore Occurence is a 10 because you also know its a system with problems. Since there is nothing you can do to decrease this occurrence ranking, you must modify the Design to decrease the Severity. !!

Thank you all for your thought provoking inputs

 

[yodon]

Just to be clear, I don't use detection on product or design-related analyses (e.g., SHA, DFMEA); I do use it on process related analyses (e.g., PFMEA).

On the design side, detection could either be by the system or the user (or operator or some other individual). If the system can detect it, the design should incorporate something to deal with it (controls). If the user (or whomever) is expected to detect it (which is a big assumption), you can't necessarily expect they'll do the right thing to deal with it (so saying the user would detect it and act appropriately is, to me, not a control).

RPN is based strictly on severity and likelihood of occurrence.

 

[GRP]

Yodon, could you kindly share your views on not using detection in a DFMEA?

I mean, imagine you design a product and you conduct a DFMEA. So you have a list of all the functions the product should fulfill if manufactured as per print, with a list of potential failure modes and different causes for each failure mode. Although prevention is the way to go, sure, but at no point do you think how a cause and/or failure mode is detected (analytical or physical methods) before release?

Does your DFMEA provide no output to a design validation plan? In spite of redundancy or alarms, the design improvement does not call for a test to see if it is effective?

 

[yodon]

Does your DFMEA provide no output to a design validation plan? In spite of redundancy or alarms, the design improvement does not call for a test to see if it is effective?

That's a bit of a leap! For our medical device work, we follow ANSI/AAMI/IEC 62366 for usability engineering. Alarms would be part of the user interface and would be assessed (for effectiveness) through some usability study.

 

[Bev D]

I'll take this a bit further... I don't use detection in calculating an RPN (I don't use occurrence either but that's a different topic). Detection is a mitigation and is far more complicated than a simple rating scale could ever quantify.

Severe failure modes will drive validation testing. (and the occurrence requirement will drive sample size and type of study design).
Severe failure modes will also drive the development, validation and implementation of manufacturing (release) testing. In particular manufacturing test and inspection methods must also pass an MSA.