Your organization gets information, feedback, and requests from customers all the time.  It’s up to you to do some preliminary analysis and determine what the customer really wants.  Do they want to buy something?  Do they want to complain about something?  Do they have a need for which no one has a solution?  All these areas represent opportunities for your organization.  But one area is particularly important for functional safety products: the complaint.

When a product is developed for functional safety use, it goes through the extra rigor of a process compliant with IEC 61508.  But no process can drive out all types of product faults.  Random failures occur.  People make mistakes.  The key is to find out what went wrong and fix it so it won’t happen again.  Unless you find the “root cause”, the problem has a likelihood of repeating.  (If your field failure analysis process is not written down, that is the first thing to address.  While root cause analysis is a general good engineering practice, I’m surprised how often it isn’t used!)  Naturally, you’d need some way to identify safety function problems from those that were not safety problems.  A problem or fault that affects functional safety means a hazard or event could turn into a catastrophe.

One of the first things to do is get more information about the problem from the customer. Because “it’s broke” doesn’t give you much to go on.  Even when a more detailed description is available, it often helps to talk to people onsite for a first-hand account of what happened.  Armed with this information, you need a way to reproduce what the customer is telling you.  Find out if the customer properly installed and configured the product.  If not, the problem may be incorrect or inadequate instructions.  This can be easy to fix, but your entire customer base may still need to be notified.  If instructions were correct and followed properly, including ambient environmental conditions, the problem could be due to a random component failure.  A certain number of random failures can be expected and if you can isolate the fault to one component, you’re done.  But make sure you’re not getting an avalanche of field reports about the same problem.  The issue might be due to a systematic error by your suppler (like a contaminated batch of capacitors).  What you really want to look for is any sign that your own systematic errors are responsible.  This includes poor training, bad requirements, inadequate design, software bugs, and production process errors.  Once these errors are isolated, you can begin to fix the process that caused the problem.  You should continue to pursue the root cause of the systematic error to correct the process causing the failure.  Once these errors are properly fixed, they should never occur again.

Note:

The “Five Whys” is one method you can use to get past the layers of symptoms to uncover the root cause of a problem.  Fishbone diagrams are also helpful to align brainstorming activity with the “6 Ms” (Materials, Manpower, Methods, Measurement, Machines, Mother Nature).