Welcome back to the Altium Primer series. In Part 2 we talked about how to unify your design and data management processes by combining both Altium and Altium into one unified solution. In Part 3 we’ll be covering how to get started with Altium by strategizing your day-to-day management process with your design team.
Management Overview in the Altium
management is a crucial part of PCB development. PCB projects are often MIMO type of work - Mess In, Mess Out. That is, if your project and data are disorganized from the beginning, then the finished product will be a mess as well. In order to get reliable results, components in the must have unified definitions and style.
Component libraries as a general concept are used in all professional PCB development tools. Each has its own way of storing, sharing, and maintaining data. The most , and the most basic, is probably a file oriented style. This means that data is grouped together by files, categorizing related components.
All files are, or should be, distributed to all team members. However, this can cause issues wherein the isn’t correctly synchronized for all team members. As a result, teams end up with multiple, separate project libraries, or even team members who keep their own, personal libraries apart from the rest of the group. This kind of disorganization can cause a great deal of extra expense for the project, and ultimately leave it unmanageable.
More advanced management is based not on files, but on databases, wherein a text oriented table is used to list components. Databases can then be easily shared and centralized, to provide all team members with the same and data at any given time.
Maintenance procedures for a database can vary, depending on its features. However, in general, maintenance requires a fair amount of expertise, and can be costly as well. Also, in the end, a database generally doesn’t provide any new functionality for components. It’s simply an updated incarnation of the traditional file .
In contrast, management in the is inspired by modern data management systems. Rather than simply lists of components, their designs are enriched by revisions, lifecycle management and traceability of relationships between models, components, and projects. Centralization is also improved with newer technologies, along with usability and flexibility. Rather than being simply a general purpose database, Altium is specifically designed for PCB design projects, and is customizable for whatever you need.
Creating a Management Strategy
How do you manage your component ? There are a number of strategies. It’s best to begin with the assumption that there is a dedicated person or persons involved in creation and management for each individual component. From there, we can consider 3 possible scenarios for who on your team is allowed to make changes to the :
- All users. This is particularly helpful for small teams, who wish to let all team members create the components they need. All models and components can be stored and accessed by whoever needs to use them. This is, unfortunately, not very efficient. Each team member must be trained to use the , including all standards and processes related to it. It’s better to have at least two designated supervisors, who can manage the lifecycle states of models and components, and approve the change from one state to another.
- Librarians only. The opposite approach to granting all users complete access is to have dedicated librarians. Users send in their requests for changes and updates to component files, and the librarians process and approve them. This also is not an ideal approach, as it can create bottlenecks in the system. Many new components are required for any given project, and forcing each one to be reviewed and approved will slow down the entire process.
- All users create components but librarians finish them. This last strategy is a hybrid that combines the good elements of both previous strategies. It allows all users to create new components, but generally utilize only rough, incomplete definitions, and no footprint. These components can be immediately used in projects under development (specifically in the schematic development phase). However, once the component is needed for generation or PCB layout, librarians must approve the component, so it can be fleshed out and completed. All instances of incomplete components are automatically marked as out of date whenever a newer revision is available, and these components must also be supported by an error state, set to the incomplete revision.
This way the team can work in parallel. Once the incomplete component definition is ready, the project can continue development. Then when the development of the schematic part is nearing the end, librarians can start on completion of needed components without blocking further project development. The project is updated to include new revisions just before its next step. This allows the entire design process to be greatly expedited. However, it’s also a more complex process in general, and leaves more room for mistakes.
To avoid these mistakes, this method requires careful planning and collaboration of the entire team. Therefore, this strategy should generally only be implemented by advanced teams.
Deciding Which Strategy to Choose
Which strategy you use depends on your team, but for most teams, the best scenario is simply to use dedicated librarians to create all components. It’s true that this can take time and cause delays in your project, but then so can component creation in general. Creating a new component every time one is needed takes a lot of time—time which will have been wasted if that component turns out not to be used. After all, the components a PCB is ultimately made with are rarely the same ones it was initially designed with.
After choosing a basic strategy, you can then dive into the specifics of building out your structure, creating components, and handling errors in your management process. All of this information and more can be learned in our free Primer ebook - download it now.
About the AuthorMore Content by Petr Tosovsky