The first step that must be taken whenever outsourcing an FA job - even before a lab has been selected - is the construction of a detailed background information set describing the problem. Designers and manufacturers have access to a wealth of information: design specifications, drawings and computer models of the device’s layout, in-depth schematics, and simulation data are all things that a manufacturer may take for granted that are unavailable to external labs, yet may be key to uncovering the root cause of the problem. Similarly, manufacturers generally have the “whole picture” of how a device may have failed - they know how long the sample was in service, whether the failure of the device appears to be an isolated incident or representative of an epidemic, and so forth. Like any other scientific pursuit, failure analysis does not occur in a vacuum (except for the rare cases calling for failure analysis on vacuum cleaners); this type of background knowledge can be vital in determining the course an analysis may take, as an analyst may be cued to look for different root causes depending on the history of a device. As an example, environmental contamination may be a relatively unlikely cause for failure for a device that broke down in a tightly-controlled cleanroom; however, for a cheap consumer device like a remote control or an MP3 player, there are innumerable sources for potential contaminants to force their way into the circuits of a device.
Just as an in-depth history is vital for an analyst to quickly and efficiently drive a failure to resolution, an accurate, concise description of the issue plaguing a device is absolutely necessary. Just like taking a car into the mechanic, a failure analyst can diagnose an issue more efficiently if the problem description is more in-depth than “funny noise when driving”. Any problem reported by the client will, at some point, need to be translated into a testable condition by the FA team - providing the most complete description of the problem possible will allow an analyst to properly design a test program to isolate the root cause of the failure. In the same vein, it is often beneficial to provide a sample that is working properly along with the failing sample; by giving a golden unit to compare against, it is possible to employ techniques that greatly increase sensitivity to small defects, by allowing analysts to separate normally-occurring phenomena from those stemming from the failure of the device. For so-called “functional failures”, in which cases a device is still mostly operational (i.e. is not short- or open-circuited), but may not give a correct output, the use of a correlation sample is almost mandatory, since the normal operation of such a device will often create many of the indicators (photoemission, thermal hot-spots, et cetera) that analysts use to isolate failure sites - in order to find the true failure, they must have some way of filtering out those sites that are inherent to the normal operation of the device.
Once the initial data about a failure has been collected and filtered for any unnecessary or sensitive data in order to ensure the best results from a given failure analysis job, the next step is to evaluate and choose a lab to handle the project. In part two of this series, we will discuss the sorts of things to look for when choosing a lab, in order to provide the greatest probability that a given issue will be resolved successfully.
Derek Snider is a failure analyst at Insight Analytical Labs, where he has worked since 2004. He is currently an undergraduate student at the University of Colorado, Colorado Springs, where he is pursuing a Bachelors of Science degree in Electrical Engineering.