One of the greatest banes of PCB design is the maintenance of component libraries. There are over 1 billion electrical components on the market according to SiliconExpert. Although there are numerous ways of obtaining components, each company must organize their components to fit their needs and workflow.
In Altium Designer, the default library provided in the tool is what we at Nine Dot Connects call a “symbol-centric” library. In addition to the symbolic graphical representation of the component, it is also given a name, description, and parametric information. Furthermore, other models may be attached, such as footprints, 3D, and SPICE simulation models.
This approach comes from Altium’s beginning when its founder, Nick Martin, wanted a tool for the makers, hobbyists, and small businesses. For this market, the tool was designed for a single user. However, as Altium grew in popularity, other library methods were needed to address the ability to share and collaborate. We commonly refer to these types of libraries as centralized libraries. Altium, Nine Dot Connects, and other third parties provide such solutions.
From a high-level view, a centralized library allows for several advantages:
1. It collects all the components used by all members of the team. If a designer spent the time to create it, it makes sense to make it available for other team members. Re-inventing the wheel is redundant and inefficient.
2. It provides for a consistent look, feel and functionality. There are features that can be built into the symbols and footprints that can greatly ease the creation of manufacturing documentation across all projects.
3. It can track the life cycle status of the component. In today’s component market, products are declared obsolete in short order.
However, symbol-centric libraries do not lend themselves to collaboration. The libraries are simply files. This requires team members to coordinate to keep the file up to date and consistent. All too often, this effort falls by the wayside when projects need to be turned quickly. Granted, if there is a single individual who plays the role of the full-time librarian, the use of a symbol-centric library would be sufficient if it is well organized with a workflow that is established through programs, scripts, and communication channels outside of Altium Designer.
Symbol-Centric libraries have several nontrivial disadvantages:
1. Each symbol has its own graphics. Therefore, if there are 100 resistors in the library, each component is provided its own graphical symbolic representation. This can easily lead to inconsistencies in the length, color and orientation of each component.
2. It’s not necessarily easy to ensure that the parametric data is consistent in each of the components. There are tools to handle this; yet there are too many opportunities to improperly add parametric information, let alone leave it blank. For example, if one component uses the name manufacturer and the other uses the name mfg, this information not going to line up in the bill of materials. Even if the parameter names match between components, it is highly likely that the formats of the values will be different. For example, think of all the ways one can write one-thousand ohms: 1k, 1K, 1000, 1,000, etc. This doesn’t account for the use of the Greek symbol omega (Ω) or the various ways of formatting the word Ohms. A lack of consistency will impact the ability to sort the list when searching for a component.
If multiple users are planning to contribute to the library, there needs to be some file-sharing coordination. The use of a version control system like SVN can help but it does not prevent coordination mix-ups because everyone still needs to be accountable for following the proper workflow.
Is there a better way? This leads to the consideration of a database type library. In such libraries, each row of information in the database represents the component while each column represents the parameter. The components are viewed as a table. The formatting used for different parameters is visible and allows for better consistency. In addition, existing symbol graphics can be reused. For example, if a new resistor is introduced into the database, one can simply point it to the existing symbol graphic that the other resistors are using.
There are different approaches to a database library. Each has its advantages and disadvantages. Universally speaking, databases have three disadvantages:
1. All databases need an administrator. Currently, there are no systems which can manage themselves. We must consider the analogy of a vegetable garden. One cannot throw seeds onto a plot of land and expect it to maintain itself. Same holds true with component libraries. We need to methodically set things up and remain consistent in our efforts to maintain them. “Libraries by anarchy” will fare no better than our bespoke vegetable garden.
2. All databases are textual in nature. Therefore, the symbol and footprint graphics are maintained outside of the database. Because of this arrangement, the creation of new components can be tricky, especially if the designer creates the symbol, makes use of it in their design and then declares it in the database. There still needs to be a synchronization between the part placed on the schematic and the database. The longer the designer waits, the more difficult it will be to accomplish this synchronization.
3. All databases need to be hosted on a platform, whether this is on an internal server or in the cloud. This usually entails the skillset of an individual versed in internet technology (IT).
With this in mind, let’s look at each database type a bit closer.
DATABASE APPROACH
These are simply databases that can be deployed, setup, and managed as per the needs of the company. This includes everything from MS Access and SQL to Oracle and IBM.
Advantages:
1. Easily reuse the graphics. For example, if there are 100 resistors listed, they can all point to the same graphic for reuse.
2. If a new component is similar to an existing component, it is a matter of copying the component to the database and making the appropriate modifications.
3. The parametric information can be seen for multiple components, allowing the user to emulate the formatting and wording already used for the parameters. For example, if the manufacturer’s name column uses TI instead of Texas Instruments, then the pattern can be recognized and followed.
Disadvantages:
1. Without any graphical user interfaces for the users to follow, they will need direct access to the database. This seems reasonable in theory; however, the reality is starkly different. Would you give database access to a user who has little to no knowledge as to how a database is maintained?
2. The creation of graphical user interfaces requires someone well versed in databases and in programming. This also requires the deployment of these interfaces to all members of the team. More importantly, there is no out-of-the-box workflow. This needs to be developed, and once developed followed to the letter.
3. A database does not contain revision control. If revision control is necessary, a separate version control system will need to be implemented. Even something as simple as a status in a database must be continually maintained by the database administrator.
L9 MANAGER – NINE DOT CONNECTS SOLUTION
The L9 Manager was created to overcome some of the headaches and hassles of setting up and managing a database library. It contains graphical user interfaces that were designed to assist the designer in creating and finding components.
The advantages are the same as those listed for a database. In addition:
1. The graphical interfaces are part of the L9 offering. It’s simply a matter of having a web browser available for each designer.
2. L9 provides revision control as part of its workflow.
3. L9 provides a workflow for the entering and validation of new components.
CONCORD PRO
Concord Pro, though touted as a component management system, is a file management system. In addition to components, it can store any Altium based file. Therefore, it can also store templates and projects as well.
Advantages:
1. Unlike databases and L9, Altium removes the administrative hassles associated with linking symbols and footprints to the component. Concord Pro purposely avoids having the user save a file in a local directory. The intent is to have the user work on the component and then push it into Concord Pro’s file system when it is ready to be released. Any saving that needs to be done in the interim prior to releasing to the server is handled by Concord Pro.
2. Concord Pro can make use of its part choice feature which allows it to display dynamic information such as lead times, price and stock in real time.
Disadvantages:
1. A thorough, well planned and executed setup is crucial to getting it right the first time. Simply dumping components into Concord Pro will not resolve any of the organizational issues that may have already existed in the libraries.
2. Concord Pro is procedural in nature. This is due to the way Concord Pro breaks the component into a minimum of three revision-controlled files – a component file, a symbol file and a footprint file. If a change is made to a symbol, the component will need to be revised as well.
3. Concord Pro is Altium centric. Though non-Altium related files can be uploaded into Concord Pro such as Word or Excel files, it is limited to its ability to edit or modify the files.
PDM – PRODUCT DATA MANAGEMENT
PDM (Product Data Management) is a combination of a database, and a file directory system similar to what one would find in any operating system. Because PDM contains a database, it allows for the creation of scripts and graphical user interfaces for workflow and other company driven procedures.
In fact, Concord Pro could be categorized as a PDM system since it contains both a directory management system and a database. However, unlike a raw PDM system, Concord Pro has been restricted to keeping the graphical user interfaces and the scripting capabilities within the Altium environment.
A PDM solution should be considered if the intention is to have a file system that works for all engineering related documentation, regardless of which software was used to create it.
Advantages:
* A universal solution for all documentation, regardless of which tools were used to create the files. This can be very useful for companies needing tight integration between different engineering teams working on the same project.
Disadvantages:
* Administration of a PDM system is full time job. It goes far beyond library management.
In conclusion, there are solutions out there to assist with library component management. They do require some time for proper setup, training, buy-in from the design team, and most importantly, the continued upkeep of the library. No matter what product is used for component management, someone must take ownership. Like a vegetable garden, there must be a gardener to make sure it is properly attended.