We All Dislike Library Management Because Our Parts Aren’t Complete

I’ve worked in many engineering departments in my time, and regardless of where I end up, one thing is constant – the way we engineers manage our component libraries is a complete mess. My job has been to fix these terrible piles of data wherever I go, which mostly resembles the organization of a landfill, into something that’s usable and efficient. This process is never easy, and at the end of the day I keep asking myself – how did it even end up like this in the first place?

Our Methods Are Broken

To be honest, how we build and manage our part libraries is a bit broken. And unfortunately for many engineers like myself, this is just what we learned at the beginning of our careers, without knowing any better. You store your components on your desktop, throw a symbol and footprint together, and cross our fingers that it can all be sourced when it’s time to make your board.

Oh no, where did I put all those part libraries again?!

While it’s easy to exist in this assembly-line state-of-mind, of letting our procurement team handle the mess, somewhere down the line someone is going to be having a dreadful night because of our choices. But why does this even need to happen? Because we have years of legacy that we cannot throw away, and we do not want two different data sources.  One data source is bad enough. And let’s face it, as engineers the last thing we want to be doing is fiddling with data and organization. We just want to design.

Should the beast of burden be placed on us to keep things organized, find pricing data, and make sure our parts are available? Isn’t that procurement’s job? This is an old engineering mentality that needs to go. We need to own up to the fact that while library management isn’t our favorite, it’s imperative and worth doing right for the sake of the bigger picture and everyone’s sanity. To begin to do things right, we first need to understand what makes a component complete, by having the right data.

What Makes a Component Complete?

Ask a hundred different engineers what a complete component is, and you’ll probably get a hundred different answers. To some, it’s just a symbol and footprint, and to others, the picture might get a little bigger with 3D models and pricing data. But more often than not, many of us misunderstand what a complete component is, and what kind of data needs to be included to make it so.

A complete component has a ton of connected parts and data, do you have them all in your libraries?

Here’s our definition of a complete component – It’s not just a symbol on a schematic, or a footprint on a PCB layout. It includes a complete spectrum of data, from the minute you first place your symbol to the last leg of the journey when that part is ordered and soldered onto your board by a pick-and-place machine. All of this data can be broken down into two categories, static and dynamic data.

Static Data – A Snapshot in Time

Static data includes all the data taken in a snapshot in time that won’t change as your design process moves along. Think about all of the information you do just to get a schematic populated, and you’ll likely wind up with a bunch of data points, including:

• Symbols
• Footprints
• 3D mechanical models
• Certifications (RoHS, REACH)
• Part specifications
• Internal part numbers
• Datasheets

Dynamic Data – Keeping Things Moving

Unlike static data, dynamic data keeps changing as your design process continues. Whether you’re creating a simple board that takes a week or something more complex that takes months or years, it’s likely that in that span of time your part availability and pricing can change. Dynamic data is what engineers typically leave out of their parts libraries, if only because it can be hard to monitor. This information can include:

• Pricing
• Availability
• Part lifecycles
• Approved suppliers
• Part usage across projects
• Manufacturing lead times

Some Guiding Principles to Live By

After creating and managing libraries from scratch time and time again, you tend to establish some guiding principles to keep yourself grounded. Before I even start to create new components for a company, I look at the data they currently have and see how it stacks up to my standards:

• Quality – How accurate is the component data in these libraries? Are part numbers complete? Does every part have a datasheet reference?
• Organization – Has there been an attempt made to keep parts organized? Are they labeled by revision, or just all thrown in a folder haphazardly?
• Usability – Are all of these parts usable as of this moment? Do they have all the parametric data I need to be able to order them?
• Consistency – Do all the parts follow a consistent naming and lifecycle scheme? Do they all have a similar visual appearance?
• Quantity – Are there even enough parts in this library to complete an average design project? Or are we going to have to keep making new parts?

If any of these standards aren’t up to par, then I know I have my job cut out for me and will likely need to recreate most if not all of these libraries from scratch. To put all of this theory into practice, here’s a part that I recently had to re-create and the steps I took:

Texas Instruments – MSP430 Microprocessor

Building the Static Data

My first job was to create a complete static data profile for this part with the data that I had available to me. This process included:

1. First, I headed over to Digikey to gather all of the needed parametric text and datasheets that I’ll need for this part.
2. Next, I created a symbol and footprint in EAGLE. There’s a ton of parts that already exist from community-created parts libraries that can make this process easy.
3. And last, I downloaded the 3D model for this part and saved it in my project folder. This will be important if I ever need to send my design over to an MCAD tool for verifying fit.

As you can see below, I’ve got all of the static information added for this part in EAGLE, with a linked datasheet in the description field in case I ever need to reference it in the future. Next up I needed to build my dynamic data.

Putting together all of the static information for my newly created part in EAGLE.

Building the Dynamic Data

Next up, I had to find all of the dynamic data for my part. For this stage of the process, I relied heavily on Newark’s database as my reference point. As you can see below, doing a simple search in Digikey’s database for MSP430 found just the part I needed, along with its stock, price, and availability.

With all of this information gathered, I can now mentally check off this part as ready to go for a design project.

So is All This Really Worth It?

The answer to that question depends on your needs, and your mindset. As an engineer, the last thing I want to be worrying about is whether a part I chose is going to be available come production time. I’ve experienced enough late nights in my career trying to swap out parts that weren’t available when I needed them, to know that I never want to deal with this problem again.

Does all of this take a bit more time? Absolutely. But I think it’s time well spent when you consider your parts libraries as the building block of your entire design process. You wouldn’t create a house on a shaky foundation, so why would you do the same for which something you’re about to pour months of hard work? When it comes down to it, creating quality parts and managing them like a professional, starts with having the right data.

With Autodesk EAGLE, it’s easy to manage all of your parts in one easy to access location. Ready to get started? Try Autodesk EAGLE for free today.