Estimated reading time: 6 minutes

Elementary, Mr. Watson: The Five Pillars of Your Library, Part 5—Traceability

We have reached the end of this series regarding the five pillars of the component library. We now have a robust library that is flexible enough to grow with the company and meet the evolving needs of this industry.  

Before we look at putting all this together to see how the five pillars interact with each other, here is a short review of the SMART acronym:

• S: Singularity     
• M: Managed
• A: Architecture
• R: Review
• T: Traceability

Through each of these pillars, we strengthen our component library. But unfortunately, we can't pick and choose which ones we will follow; each one is required.

Now, let’s examine traceability, the final pillar in the library. In the sense of our component library, what do I mean by traceability? It is both on a micro and macro level. First, it means identifying the revision of the components and their pieces, such as their models. Then, on the macro level, we identify which components are used on which products.

Why is traceability so essential? Why is it considered a pillar of our library? Each pillar supporting your library is not the end-all but the beginning of your library. In architecture, you use pillars to help a specific building section. They support explicitly what is above them. The five pillars are the foundational principles for creating every component, which become the building blocks of the PCB design. That means there is an inherent interconnect inside the PCB design itself where everything is connected and dependent on the other information and items.

Additionally, the specific data of the components of information, sourcing, and sometimes even the symbols and footprints models can and probably will change. I have heard a few of you say that it’s especially the sourcing. When that happens, the results are the proverbial ripples in the pond. How far out do the waves go? What product lines are impacted, and how badly? At the beginning of the series, I said each pillar of your library is required; pulling out even one weakens our entire library structure. Why? Because it weakens the quality of the components and, ultimately, the quality of our PCB design. The problem is only compounded by not knowing where those components are used and in what product lines.

When changes occur predominantly on the components level, we must first manage that change. We accomplish that through an excellent review process (fourth pillar). From the initial quality control process,  the review and quality control checks ensure that your components are the highest quality. That is a routine procedure in every sound library I have seen. But our fifth pillar of traceability is where we get a clear picture of the impact of those changes.

Furthermore, changes will not only impact a single component or design. For example, if I change a footprint used in multiple components, those changes get similarly pushed into the PCB designs. A great example of this is the whole problem with component sourcing as companies are shifting from new product development to sustaining old products. We quickly see this principle of “where-used.” When I find that a component is going obsolete, the first thing I want to know is how many product lines will be down because of the shortage. From there, I can decide how to move forward. That is all a result of traceability.

Traceability is also important because it's most likely a requirement of compliance standards. Having a complete record of the exact makeup down to the component level of every product is frankly required. That is where our second pillar (managed) comes into play. Maintaining a specific revisioning and lifecycle scheme for each component is priceless. Along with that is keeping secure custody of all revisions of components. This will create a rather large database of components but that is the very foundation of traceability.

I know some of you may be saying that this is all fine and good, and we have an entire team of people who handle all of this sustaining stuff. Why should this be a concern for our side? Because of any design issues, we must ensure that information goes full circle and is updated in the library. The first pillar of singularity is still standing strong, developing and protecting your single-source of truth.

Putting It All Together
We can, as they say, wrap this all up in a pretty little bow. But, after seeing these five pillars developed in countless companies over many years, I've noticed the interaction and unique relationship between them, which again enforces the requirement of needing all the pillars.

First Pillar: Singularity
We began this journey by seeing the importance, even the necessity, of having a single library. Having multiple libraries brings an inherent risk of errors into your design. The first pillar is about developing the single-source of truth and focus in the sense of a point of concentration. When you are creating and operating from a single library, it forces you to focus. This is the most difficult step for some who like having their own individual libraries and frequently cannot get through this first step. Also, please begin to see that each pillar depends on the strengths of the other pillars next to them.

Second Pillar: Managed
With our single library established, you must develop a detailed revision and lifecycle scheme, the basis for your management plan. Furthermore, under your second pillar is the revisioning system. That allows you to store all versions of a component, model, and design so you can quickly identify which version of a component was used, where, and what changes are required to bring it current.

Third Pillar: Architecture
The architecture is far more than just an excellent location in your categories, families, and sub-families library. When combined with solid models and component naming conventions, you're tackling the problem of duplicate information. Singularity is not just a "single library," but making sure the individuality of the data inside the library is singular.

Fourth Pillar: Review
We focus on dealing with changes inside the library with the remaining final pillars. All the information collected will change at some point. Ultimately it will run through its lifecycle (pillar two: managed) and go obsolete. We must prepare for this by having a plan to identify and implement those changes. With the fourth pillar (review), something transformational occurs with your library. It goes from being just a "static pile" of information to becoming dynamic, shifting, and changing like our industry.

Fifth Pillar: Traceability
Traceability looks at it as determining the scope of change from our review process; we identified what we do. With traceability, we know the interconnection of these big puzzle pieces.

All five pillars are interconnected and depend on each other. I wouldn't have any specific one of them without the others.

One final point: How do we implement and start using this information throughout this five-part series? It will take time, so be persistent. Take steps each week to establish these five pillars and principles in your company's library. None of this happens on its own. Warning: At first, you may feel like you're pushing the boulder up the hill, but keep going. What you are building is a technological infrastructure that will last longer than any of us.

John Watson, CID, is a customer success manager at Altium. 

Download The Printed Circuit Designer’s Guide to… Design for Manufacturing by David Marrakchi. You can also view other titles in our full I-007eBook library here.