@Tigertom: That's a very good point. For those of us who are materials engineers, there's a temptation not only to take apart assemblies, but to cut parts up so that we can look at the microstructure. We end up with beautiful micrographs, but the original part falls victim to the chop saw.
As you point out, it's very important to get all of the information you can before taking apart an assembly. Once you get to the component level, it's also important to get all of the information you can from non-destructive testing before proceeding to destructive testing.
More than once, I've been in the position of realizing that I wanted to check something on a part after I had already performed a destructive test on it. As Homer Simpson says: D'oh!
Can I suggest one more big mistake to add to your list?
6. Quickly dismantle a failed assembly. If you have an assembly that doesn't work, it's very tempting to take it apart to see what's broken. You probably have one or two theories as to what might be broken inside. But if you dismantle it and nothing is broken, then you're in real trouble. When you re-assemble, the chances are it will work perfectly, and you've destroyed the bug you've been commissioned to identify.
Instead, before you dismantle, get every relevant bit of information you can from the failed assembly. What are the resistances and capacitances at the terminals, or what is the frictional torque to move it, or how much does it weigh, or does it rattle when shaken etc. etc. If possible, x-ray. Develop a list of failure modes that could produce the observed symptoms, and see if you can prove or disprove any before dismantling. As you dismantle, measure the torque on bolts, look for dirt or misassembled components and for parts that have moved to unexpected positions. Once the disassembly is complete, all these clues will have been lost.
Dave. I couldn't agree more. Thanks for a dose of sanity. I too have been part of similar investigative teams. As noted, it seems that one of the biggest issues that pops up is getting management (or the customer) to be patient while the investigation proceeds. There are no shortcuts for a good analysis.
Great Article, Dave.I found myself thinking back to many different scenarios over the years, after reading each of your points, 1 thru 5.One which loudly resonates is touched upon in both your #2, andyour #5 – jumping to conclusions, and management pressure to fix it quickly. Many times, I have dealt with a manager who forced his suggestion to be the fix, without going thru the necessary trials to prove it.I preach again and again, "a sample of one doth not constitute a statistical lot".
Product failure analysis covers two different types of products, those that have been working properly for a long time, and those that don't have a history of having worked. The failure analysis of the two types would be a bit different, at least after the start. The first question would be "did it ever work correctly?", since if it did not, then the design may be suspect. But it is also possible that the design is good but the part was not made to the design. Amazingly, not every design is produced faithfully the first time.
The conclusion, then, is that in order to correctly understand why some part failed, it is mandatory to understand just how the system including that part was supposed to work. Having an adequate understanding of a system is seldom a trivial task, but it is important. A part will fail because it was subjected to forces beyond it's strengths. That is the fact in a majority of instances. At that point the question becomes one of: was the part made to the design specification, or was the specification adequate? Again, in order to be able to answer correctly there must be an adequate understanding of the system.
Interestingly enough, sometimes the problem is caused by there not being an adequuate understanding of the system from the very beginning. And I am not sure how to solve that problem.
One of the other key points I think when solving problems is not to focus on one area or not focus on one area. If you are in design don't automatically focus on if the part is to print and then point the finger at quality. If you are in quality don't ignore if the part is to print and focus on the design.
True problem solving is a skill that takes a lot of patience and discipline. You must let the data lead you but still be open to engineering decisions and insight. As well as remembering the problem is that the part is breaking. We are all together in trying to solve this problem. Not point fingers at who caused the problem.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.