How to Best Learn from Previous Products
Abstract
Kirk and Fred discussing the problem of getting failure data from predecessor products for many companies. Without detailed useful and verified failure data, it is difficult to improve reliability
Key Points
Join Kirk and Fred as they discuss
Topics include:
- Suppliers common failure analysis results such as EOS (Electrical Over-stress) that may not be detailed information
- Prevention of field failures does not get as much attention as the the field service department that rescues the customer by getting the system working again.
- Many times failure data and tribal knowledge gets lost in the dynamic movement of the engineering work force
Enjoy an episode of Speaking of Reliability. Where you can join friends as they discuss reliability topics. Join us as we discuss topics ranging from design for reliability techniques, to field data analysis approaches.
SOR 363 How to Best Learn from Previous ProductsKirk Gray
- Social:
- Link:
- Embed:
Show Notes
For more information on the newest discovery testing methodology here is a link to the book “Next Generation HALT and HASS: Robust design of Electronics and Systems” written by Kirk Gray and John Paschkewitz.
My best (worst) example of experience with tribal (and even documented) knowledge being lost was when I was working as a principal engineer. My company at the time was using a custom IC that was being provided by a fabless design house.
We were starting to experience large numbers of field failures of a certain product, and since the initial troubleshooting pointed to the abovementioned custom IC I was brought in to help the reliability engineer with the failure analysis (I had a semiconductor process background from the distant past).
Turned out the issue was an EEPROM array failure on the custom IC, and by looking at the chip fabrication characteristics I became highly suspicious that the foundry was one of my previous (more than a decade earlier) employers.
A meeting with the fabless design house was arranged where they revealed that my suspicions were correct, and the foundry was indeed one of my previous employers.
At the start of the subsequent meeting with the foundry I asked their engineers two questions about their EEPROM process. They answered “Yes” to both questions. “Then that’s the problem” I told them.
“How do you know that?” was their response. “Read the technical report we wrote on this stuff 10+ years ago” was the answer.
To make a long story short that was the problem and the process had to be modified, which solved the reliability issue.
An extreme example of making the same mistake over again, even when it was documented (but not incorporated as a “design rule” in the IC process development) – plus an extremely serendipitous failure analysis.