Why Your Root Cause Analysis Starts with Component Traceability
At this point, we’ve reached a significant milestone. Having followed through the last article, we now have a very stable and, more importantly, reliable PCB library. Since we can safely use the data in designs, many people decide not to go beyond the review process. You should, however, continue to the fifth pillar if you want to ensure success.
So, why the fifth pillar? Because although we have a great structure, we must take the information and improve it. The other reason is that the acronym would only spell out S.M.A.R.—and I’m not exactly sure what that is.
As an analogy, during the process of refining metal with fire, the primary process purifies the metal alloy by burning out the impurities, and with additional processing, even more can be removed.
The refining process is not just for metals. You can do it with anything, including PCB library data. The greatest PCB libraries are those that are continuously improved and refined.
To allow for changes to occur in your libraries, and to build traceability in, you may require a change in your PCB design process and attitude. Many people stop at creating the PCB library without reviewing it. Others make even more progress, and stop at the review process with no tailoring. Remember, we cannot remove any of the library management’s pillars, as pulling one out will collapse the whole structure.
We need a major change of attitude with regard to how we look at PCB design process. Some mistakenly believe that the PCB design process concludes when it is fabricated and assembled. They believe that if we have reached the finish line, our job is done. However, I would argue that while this may be intuitive, it is not the case. Since nothing can achieve perfection, there is no finish line to this constant improvement, traceability will support inquiries into why things are the way they are.
The fifth pillar is the culmination of all other pillars before it. Only when we have a single, tightly-managed PCB library, with a structured architecture that is reviewed according to a set standard, can we KNOW that we have a PCB library of the highest possible quality. It is this high-quality PCB library that we seek to make, and that becomes an asset to the profitability of a company.
Skills Needed for the Traceability Process
When you begin the PCB library traceability process (refining), the reports, as we will see, are not just for the library alone. They are a combination of used parts and the PCB layout. Using a root cause analysis on the data in these reports, we can evaluate them to determine if a problem is a library issue or a layout issue.
The review process was verification while the traceability process allows validation. In the same way as there were reports for the review process, though, there are specific reports and sources of data that we can evaluate for this process. The following are not in any way a full list, but should serve as a guideline to how the process should be handled.
PCB Fabrication Reports
The first report on our list is the PCB Fabrication Report. While the Fab house generally completes this for you, it tends to be more about the layout, making it essential for the support of the other reports.
Design for Manufacturing Report (DFM)
A Design for Manufacturing Report (DFM) looks at a design and how it will impact the manufacturability of a PCB, especially those items that would cause delays in the manufacturing timeline. Given the fact that any fallout from the assembly process is actually paid for by the customer, it is imperative to have the highest possible number of designs being done with the lowest number of problems.
An outside DFM house usually completes these reports to evaluate the Gerber set and parts used. With a set of ‘Design Rules’ fed in as algorithms into the board, the report provides a list of possible problems or issues.
Once you get the report, it is essential to walk through each issue raised to determine if they are Layout issues, or Component issues that relate back to the libraries. But, keep in mind that what we really need is the root cause.
We were having long-time issues with our DFM reports claiming component crowding. At first, we believed the root cause was the layout, but this belief turned out not to be true.
An electronic component was missing some vital information in the PCB library. One of the more important ones being the component placement courtyard. This set grid box is present around all components and goes on a mechanical layer to aid the placement of components.
Because this information was missing, we had no guide to help the PCB layout person to properly place the component. Once fixed, the problem went away. I think a good rule of thumb is always to assume that if a DFM raises an issue, it is NOT a layout issue but a component issue.
Assembly Build Finding Reports
DFM reports are very specific to both the Design Rules they use and the specific component library. So, unless the DFM uses your design rules and components, they have a flawed starting point.
A better report comes from the assembly house’s Assembly Build Findings Report. This report actually evaluates how your components place on a bare PCB. You will still need the same analysis process to find and determine the root cause of an issue.
Field Service Failures
Many people ignore the Field Service Failures Report. Nevertheless, good library management should minimize field service failures. You do not need a bad reputation from unit failures delivered to your customers.
I think the reason many choose to bypass this report is the amount of effort required to determine the root cause of the issue, especially if it was library-related. But if you are willing to go through the steps, the results would be phenomenal and will have a considerable impact on the PCB library quality.
Six months after a particular unit was being installed, we had a sudden high failure rate. We found that the root cause was a specific IC on the PCB. After further tests, we found that the component was getting hot and therefore malfunctioning. We figured that the numerous cycles of the unit ultimately popped that chip. However, we found that the component placed on the PCB was the type used for a thermal pad after doing the root cause analysis. To only make the situation worse, we ordered the component from another vendor, who did not have a thermal pad on the component, causing poor thermal dissipation, and ultimately causing the chip to “burn out.”
Let’s have a little exercise here regarding the root cause. What seems to be the root cause? The primary reason was the result of the process which impacted several different areas. A specific component requiring a thermal pad, but with alternative components that did not. The issue was a direct link from the component used and its sourcing information. Also, it was a result of not following the process of relying on multiple datasheets from various vendors to verify a component.
Many times, it is the little things that have a significant impact on multiple areas of design, which we do not fully realize until it’s too late.
Working with alternate components
One of the problems with the above example was using an alternate component without asking the engineer if the substitute was viable.
We already discussed the final report within the Reliability Pillar: the IPC Standards. I think it is safe to say that every IPC will be revised in some way at some point. Therefore, it is vital that we have the set of IPC standards we used to develop our library and components on hand along with its revision status. Connecting your PCB library to IPC and knowing when to revise it will save a lot of headaches down the road.
A great example was the one given with the review process where pad shapes changed from rectangular to a rounded rectangular. As these changes occur in the IPC standard, it is best to implement them to keep the library in sync with the standard.
Revisioning Process for Components
The procedure we use to revise components should be a standard process. When we review a component and change its state to “release”, we can use it safely in designs. But when further changes are done, the component state reverts to “new,” flagging it to be reviewed once again before returning to a released state.
Circle of Success
The path of success for a PCB design is not a straight line. Ultimately, what happens is that each of the reports is fed back into the library to draw out as much data as possible to improve the library. This creates a cycle of success for the library. Like a ring, there is no starting or ending point, and for the cycle to be complete, the vast amounts of information harvested must be brought back in.
Begin to have Fabrication Reports done on at least the first PCB build for all new designs.
Begin to pull in Build Finding Reports.
Begin to use Field Service Failure Reports if possible
Join IPC and continuously keep up with the standards that are being updated and revised.