PCB Data Management System Structures

Adopt the SMART rules of PCB Data Management and avoid additional cost and/or lost design time.

Whenever we begin to look in more detail of how to do anything it becomes a little problematic. The reason is, with the various organizational structures in yours and countless other companies, can almost guarantee that there will not be a “single” answer or solution to the question at hand. My intention is not to give a ‘sole’ method or structure to accomplish something but rather give a detailed explanation that will give an example of how it ‘could’ be done. Than to allow each of you to adjust it as required. My aim is to give the bird’s eye view of this whole thing with the hope to point you in the right direction. As a school teacher use to tell me…. “your mileage may vary”.

The unfortunate rule of the universe is... when things are left to take their own devices, they gravitate towards chaos. Which out necessity forces us to put into place the opposite and do some actual planning (preferably beforehand). The same especially applies toward any PCB Data Management system and how it is structured. We should take to heart the words of Benjamin Franklin as the warning it is. If we fail to plan than we are planning to fail. It is never anyone’s intention to start anything with the hope of failing but it does happen.

Experienced this first hand recently, when I was organizing a PCB Data Management system for an international company. There happen to be several areas that were NOT planned out and wouldn’t you know it, the harsh rule of the universe hit us right between the eyes.

Resulted in us painting ourselves into the proverbial corner needing to restart several times with that world famous “Plan B”.

The Five Pillars of all PCB Data Management Systems

There are several key principles that are NOT optional but rather required. Not to have them in place, will substantially increase the possibility of failure. Which we know by now translates for us as PCB Designers into additional cost and/or lost design time and several other very nasty things. These can be described as the SMART rules of the PCB Data Management Area. To help us remember these principles will use the acronym S.M.A.R.T.

Understand in the forefront, that these five pillars are may not be particularly tangible physical items but rather could better described as ideologies. Like a pillar in a building has the main function of providing support and structure. They will provide the same for what will follow. The support and structure of our entire PCB Data System.

Additionally, each one of these pillars are required. To a pull one out results in the toppling of the others.

5 - Pillars of PCB Data Management

S. - Singularity           

M. - Managed

A. - Architecture

R. - Review

T. - Tailored

S- Singularity

Singularity of what? Singularity mainly of Data and Process’. When working with a team that are working from different data and following different procedures, doesn’t take a psychic to determine the results of that. There is absolutely no way to control the outcome or results. Multiple people starting at different locations, going in all different directions, with all different maps… ending up at the same location? NOPE.

I have seen, more times than I wish to count, the problems caused by what is called “Rogue Libraries”. Rogue libraries are component libraries that are not controlled or verified. Consider the massive amounts of work to prepare a PCB design. The engineering, layout, fabrication process and then as you get into Assembly the notorious unwanted phone calls begin. Apprising you that they were hitting “snags”. Such problems as parts not going onto the PCB because of wrong footprints or other components tombstoning or falling off. When you start to investigate the problem, only to find that someone’s personal “Rogue Library was used. Resulting in the entire fabrication being scrapped. At this point, you begin that long walk to the manager office to explain the situation. Not a good feeling.

Several years back, I joined a company where although they had existed for many years and successfully. The PCB design area had absolutely no structure or organization. It would be an understatement to say it was in total disarray. It was evident by how many spins of boards designs were being done. I remember going over to one of the designers, where he opened a desk drawer filled with Bare PCB boards. Letting me know that those were the designs that did NOT make it through Assembly due to some problem on the design. It was like I got kicked in the gut by a mule. When I investigated further, determined that we had a total of around 1123 PCB libraries being used. All different kinds and sizes of course. Multiple footprints with the same name. Every designer with their personal library. No wonder there were problems.

Our hope in every design can be summed to a single word…. Integrity. What is meant by that? It is defined as” the state of being whole and undivided.”. That is a great mental picture of a PCB Design. To be unbroken and undivided. I like that. When we were working from a thousand libraries, we were starting from a possible thousand different places and possible problems. Even worst, we were not starting from what would be considered strong and verified data for a design.

There is an old saying, “To get something you have never had you need to do something you have never done”. I knew the solution to fix the problem although it was a radical step. My solution was simple. On a Friday evening after everyone went home, went onto the server and DELETED ALL THE LIBRARIES. Must say that was an interesting Monday morning. Said it was radical but necessary. In a short period of time after that, we began to see great improvements in the PCB designs. It began with getting control of the source of information and making it singular in nature. The moral of the story is ...to have integrity in the PCB Designs, we had to first have integrity in our Information and process’.

M- Managed

The second pillar giving us the required support and structure is M-Managed. This may sound as a novice idea. It cannot be assumed because you’re operating from a single source of information that it is managed or controlled. Controlled by several characteristics at a minimum the following management controls:

Roles

As we will see coming up in the next chapter various information is needed at various stages of the design process by various people in that process. Each of those individuals have various roles and inputs into the design process. A good PCB Data systems first controls who has access. The best systems can setup a very strong hierarchy with innumerable levels of access to allow a tailored approach to who can go where.

Permissions

Connected very closely to the roles is permission levels. If Roles is who can have access, the permissions would answer the question What can they do?

For example: some will only have the need to view various information. Others might need to use that information in some way, yet others might be required to verify or be required to edit information. With these roles/permission levels, it keeps things managed and in control of who and what. There is a belief in some companies that it is better to allow everyone the access to edit information such as items in the component library. That may not be the best practice instead having that permission fall on a select few is a better approach. By doing it that way, can easily manage who and what is done.

Revision scheme

Each PCB Management system must have some sort of revisioning system. This will vary from company to company. A very popular system is an Numeric Alpha system. For example: 1.A. The Numeric is changed with Major changes and the Alpha is changed with minor changes. It is left up to interpretation what constitutes a major and minor change. What is most important here is to use a system structure that is flexible enough to cover the types of changes that will be made.

More important it is best to determine that Revision scheme beforehand changing this in mid-stream does cause problems and confusion.

Lifecycle

Not to be confused with the Revisioning scheme. The lifecycle stages are something separate. It is used to describe the maturity of a specific item. There are usually six common part product lifecycle stages: introduction, growth, maturity, decline, phase‐out, and obsolescence.

The individual names for each stage may vary in your situation. The best managed systems are those that change the lifecycle stage automatically. Secondly, whenever changes occur the lifecycle automatically returns to introduction state. In this way, all changes will be realized and can be scrutinized. As we will see shortly, these changes must be reviewed and go through and audit process. Those automatic lifecycle changes are useful as markers of the items up for review.

Also, important to keep in mind that the lifecycle does not just apply to components. Anything in the database can have a lifecycle.

A- Architecture

What is meant when speaking of architecture? It is the specific structure of the database that governs what data is collected, how it is stored, arranged, and used in a database system. This system will always vary depending on the individual needs in your specific environment. The commonality between most databases is the ability to setup a folder structure.

The more the structure the better. As you have seen, there are endless types of electronic components available on the market. How to organize them in a way that makes it easy to find a certain component quickly is vital. A common way I have used is to break all the components down according to Category and Family.

To help organize the Categories they can be numbered with 100 Series. The Families are Numbered with a single numbered.

For Example,

R- Reviewable

I have seen some elaborate PCB Data Management systems. But, the best systems are not dependent on the size but rather the quality of the information. That old axiom it is not “Quantity but rather Quality”. To assure the quality of a database means to conduct constant audits. As mentioned before, a good system will have the characteristic that whenever changes occur that the lifecycle would automatically change to a new state. At this point, to assure the quality of the information is a good time to conduct an audit. Matter of fact, a good rule would be not to use those components or trust the information until that audit has been completed.

Off the coast of a rather very rugged area of North Carolina there stands three Lighthouses. Against what you might think, a Ship captain when he is coming into port does not go from lighthouse to lighthouse. Rather he lines up all three, so that he only sees a single light coming into port. Much in the same way, during the auditing process we are verifying that all the lights are lined up and we should only see a single light. Our document for all truth is the component Datasheet everything must line up with that. If not then we are setting ourselves up for problems down the road.

T- Tailored

The final pillar that must be in every PCB Database is T-Tailored. As we saw in Chapter-2, there is a massive paradigm shift that is occurring within the entire electronics industry. That forces us not to set anything in stone. The Database system must be flexible enough to adjust with the changing tide of our industry.

As this information shifts need to be prepared to identify the changes and how they will be implemented. In doing so, the Lifecycle will revert the item back to the introduction state where it can then go through the Review (Audit) Stage. No changes that impact the information should be done without some sort documentation as a form of validation to the change.