Altium Vault Ebook

FOREWARD
My fellow engineers,
Does the prospect of managing all of your design data overwhelm you? That’s how many of us feel every day as we grapple
with the challenge of managing thousands of components and hundreds of design projects with the constant pressure of
deadlines and budgets.
At any given moment in a day, whether you’re managing a design team or making your own electronics, you might just
be waiting for your next data management criss. And when it occurs, will you know what to do? Many of us don’t, and the
impending last-minute scramble to glue a project together when we’ve found an obsolete component is no way to run a
design project. But what’s the alternative? That’s what this primer aims to explores with the Altium Vault.
DATA MANAGEMENT FROM 10,000 FEET
The real problem with data management is this - we’re limited in both our visibility, control, and organization of our
most valuable design assets. The building blocks to our most cherished electronic designs, the components, often sit
unattended, unmanaged, and devoid of any real intelligence. And as data comes in, it piles up, and all we’re left to see is the
scattered bits and pieces of it all. Some of the problems that engineers face everyday when managing their components
and design data includes:
Limited insight. More often than not, we only get a limited perspective of our data as it travels through our design
workflow. But what happens if we miss a critical piece of information like availability or pricing?
Unknown details. For those of you reading this primer that are in charge of the design review process, what happens
in that last-minute crunch to push a design out the door? Are all of your BOMs validated with approved components?
And are you in compliance with RHOS, REACH, or any other of the myriad of certifications for your industry?
Scattered organization. What happens if a change needs to be made to your design? And more importantly, how are
you keeping track of all those changes? If you’re like many engineers, you’ve most likely got spreadsheets and folders
everywhere.
If there’s one beautiful thing about engineering problems, it’s that they’re all universally similar. And when it comes to
solutions, there’s a common answer to address all of our engineering data management needs with the Altium Vault.
SOLVING YOUR DATA MANAGEMENT DILEMMAS
What we really need from a new, refined data management process is three primary components, including:
1. More control over how our design data flows through our engineering workflows.
2. More visibility over what changes are made to our design data and what state they are in at any given moment.
3. And more organizational power to allow our teams to all remain on the same page and share information freely.
Ultimately we need a way to tie all of the disconnected elements of our data management processes into one unified
system that captures and controls data from its conception to completion. And we can do this with the Altium Vault.
The Altium Vault has an incredible degree of flexibility, allowing design teams to implement a fully automated data
management system. But since there’s no right or wrong way to manage design data this presents a rather steep learning
curve to get your foundation started.
To solve this learning curve, Altium has teamed up with Petr Tosovsky to create the Altium Vault Implementation Primer,
a complete guide for building your own data management system with the Altium Vault from an engineer’s perspective.
Here’s a quick overview at what’s inside:
www.altium.com i
Section 1: How the Altium Vault Can Solve Your Data Management Problems
This section provides an overview of the most common data management problems that engineers face, and how the
Altium Vault solves them in a systematic, controlled environment.
Section 2: What the Altium Vault is All About
This section will dive into the specifics of what the Altium Vault actually is and how it can benefit the efficiency of your
design team.
Section 3: How the Altium Vault and Altium Designer Work Together
This section provides a high-level overview of how the typical PCB design process can both integrate and benefit from the
Altium Vault.
Section 4: Basic Installation and Settings
This section dives into the specifics of installing the Altium Vault on your network, backing up your design and component
data, and accessing the Vault’s web interface.
Section 5: Building Your Library Management Strategy
With the Vault installed, this section will guide you on getting your design data in order including symbol and footprint
creation strategies and defining file organization schemes.
Section 6: Organizing Your Folders and Items
This section will dive into the intricacies of folders and items in the Altium Vault, and how to work with both. This will
include an overview of the basic item types you can store in the Vault, and how to create an organized folder system.
Section 7: Project Management Basics
This section deals with the higher-level management of an entire project, including utilizing templates, storing design data
in a centralized location, and guiding the project development process to a final release for manufacturing.
Section 8: Defining Your Lifecycles
This section deals with the day-to-day management of lifecycle states for your components. You’ll discover some best
practices for creating a lifecycle state system to avoid placing any obsolete or end of life components on your board.
Section 9: Expanding the Altium Vault Possibilities
Need from flexibility from your Altium Vault? This section dives into unique deployment options including enterprise
settings, enabling team collaboration, and using the Altium Vault with other management systems.
HOW TO USE THIS PRIMER

One thing to keep in mind as you read this primer - while the information presented within is incredibly valuable, it’s
also one individual’s method on how to set up the Altium Vault, but it’s not the only way. When reading your Altium Vault
Implementation Primer, we encourage you to experiment, explore the information within, and measure it against your
own needs in a data management system.
And one last legal disclaimer, the views and opinions expressed in this primer are solely those of the original author, not
Altium. Anything written in this primer is not considered as an official company policy or opinion.
Here’s to discovering the true engineering potential in your data management system. May this primer save you countless
hours and give you more time doing what you love - designing electronics.
Thank you,
Daniel Fernsebner
Corporate Director, Technology Partnerships and Business Development at Altium
www.altium.com ii
About the Author
Petr Tosovsky, MSEE
Petr is an electronics design enthusiast and has been exploring programming

logic and industry trends for the past 15 years. In past studies he spent time at the
German Aerospace Center DLR and CERN where he developed his professional
design skills. Petr is currently a Field Applications Engineer where he provides
technical support, training, and consultations for Altium Designer. In his free time,
Petr enjoys exploring graphic design, marketing, web design, and photography.
He also has an EE lab in his home where he enjoys tinkering and exploring new
ideas in electronics design.
www.altium.com iii
TABLE OF CONTENTS
Introduction................................................................................................ 1
Problems Altium Vault Solves
Altium Content Vault
What Altium Vault Is All About................................................................... 3
Altium Vault and Altium Designer.............................................................. 4
Installation and Settings............................................................................ 6

Backup
Maintenance and Upgrades
Web Interface
Library Management.................................................................................. 9
Strategy
Building Your Library
Library Processes
Handling Errors
Folders and Items....................................................................................... 12

Items
Folders
Item Naming and Revisions
Project Management.................................................................................. 17
Storage Places
Templates
Project Development
Existing Projects
Project Release
Lifecycle Management............................................................................... 23
States Management
Other Options.............................................................................................. 26
Altium Vault Enterprise Edition
Using Altium Vault with Other Management Systems
Conclusion ................................................................................................. 29
www.altium.com iv
ALTIUM VAULT IMPLEMENTATION PRIMER
Altium Vault is an invaluable resource to PCB designers. It allows your teams to store a vast array of projects and
components and access them instantly whenever you need them. But how does Altium Vault work? How do you
implement it in your company and get your design teams to use it? Here’s a guide to everything you need to know
about using Altium Vault.
The Problems Altium Vault Solves
Before we get into how to use Altium Vault, we should look at why. What role does Altium Vault play in PCB design, and why
do you need it? Well, design is a collaborative effort, with a variety of different engineers on a number of different teams,
all working simultaneously towards the same goal. It’s important to have some form of centralized data management, to
get everyone on the same page.
Centralized data management should be of interest to any type of collaborative team. However, there is often a lack of
motivation to implement it, since projects are usually on a tight deadline, and centralized data doesn’t visibly speed up the
process at first glance. In fact, taking extra steps to store data in the system for the rest of the team can even slow things
down. That’s only in the short term, though. In the long run, centralized data eliminates a number of common problems
that cause design projects to slow or get stuck. Have any of the following ever happened to your design teams?
You fix an error in the component library, but it continues to come up on other boards, again and again, sometimes
for years after the fix.
One of your team members is out of the office, and you need to access their work in order to complete the project by
deadline. You go through their files and immediately get lost in a bizarre and complex file naming system that includes
suffixes like “Old,” “New,” “NewNew,” and “NewNew1,” making it virtually impossible to access the project you need.
A new team member is building their own library, separate from the rest of the team and the rest of the project. Or
they’re using the circuits that are common to your company, but with slightly different components, creating issues
when combined with the rest of the team’s work.
The manufacturing data for a new PCB release accidentally overwrites an older revision, which is still valid and in
production.
You receive notification that a particular component is not currently available, and therefore shouldn’t be used in
your circuit design. But you neglect to pass this information on to your team right away, and your colleagues continue
development with that component for several more days before finding out that they have to go back and change
things.
These are just a few common examples of how poor communication among team members can lead to time-consuming
problems and project delays. You probably have at least a few of your own stories as well. These are the problems that
Altium Vault solves. By creating a centralized database for your team’s work, it improves communication, making the
components and other data you need easy to find quickly, saving time and money. While it’s true that data management
has some requirements during its building that make it daunting to implement, it’s an investment with a short return cycle,
which will pay off greatly in the months and years to come.
www.altium.com 1
Altium Content Vault
This answers the question of why centralized data is necessary in general. But why Altium Vault specifically? In addition to
the local Vault, Altium also offers the Altium Content Vault. Hosted on an Amazon S3 server, it’s your resource for Altium’s
own content, putting a wide array of component specs at your disposal. So the question is, with the Altium Content Vault
at your fingertips, why do you need the local Altium Vault at all?
The Altium Content Vault contains several hundred thousand components. But it’s a read only database. You can’t upload
your own components there. There are tens of millions of component types currently on the market, not to mention
the components that you and your team may design yourselves over the course of a project. The Content Vault is an
invaluable resource, but you’ll clearly need more than just what’s offered there.
You also likely have different standards and requirements for how components must be created, in terms of style, colors,
user parameters, checking procedures, source documentation, naming, usage of mechanical layers, etc. No matter how
comprehensive the library, it couldn’t possibly fit every variation you would need or want. Not to mention the information
you need that’s specific to your design team: i.e., which components have been used in which projects.
It’s important to have all of this information in a central location that’s easy to access when you need it. Therefore, it’s
necessary to have a single, personal database, which you can add to at will, which stores all the components you and your
team want to use. The Altium Vault provides that. You can find general components that you want to use in the Content
Vault, and then copy them to your local vault using Content Cart, where you can finish the design according to your specific
needs and have it at your disposal whenever you want it.
www.altium.com 2
WHAT ALTIUM VAULT IS ALL ABOUT
So, what IS Altium Vault? How, exactly, does it help with PCB design? In short, Altium Vault provides active company
data storage, as well as an archive for any data that your team creates in or uses with Altium Designer. An independent
product from Altium Designer, it was introduced in 2011 and has since progressed to its current version, Altium Vault 2.5
(7/2015). The development of the Vault has enhanced PCB design in a number of ways and created an ergonomy of usage.
However, basic principles remain the same. Let’s take a look at those.
Some people dismiss the Vault as difficult to understand. There are a number of instructional and educational materials
on it, but they don’t really explain what it’s all about in a simple, straightforward manner. It is not an easy task to explain
Vault concisely. It’s not a simple software program like Altium Designer, where you click a particular function and get
immediate results. Instead, this software is all about filling in the gaps that appear when Altium Designer is used for
teamwork. Therefore, to understand Altium Vault, you must first understand your team’s needs.
Vault’s core purpose is data management, such as processes and rules, for team leaders to set functional and easily
maintainable infrastructure for their colleagues. This infrastructure must be flexible enough to be able to cover any
situation which can occur during PCB development. Software is only part of that infrastructure: the part which is able to
store, track and find data. As such, software alone is not enough for a comprehensive data management plan, since many
sources of information related to the data are not available in digital form.
For example, one team member may be notified that the latest version of their device is not working properly. They will
naturally perform the necessary steps to fix it, but they also need to follow other prescribed steps, which were designed
to prevent the error from occurring again in the future. Data management is an approach to product development as a
whole. Rather than focusing on one project at a time, it provides a better perspective for the team as a whole, and their
projects in general, past, present, and future.
Vault is the central location for all data related to PCB development. You can store schematic symbols, footprints,
component libraries, reusable schematic sheets (Managed Sheets), schematic templates, batch files for output generation
(OutputJobs), project source data, manufacturing data and much more, all to be easily recalled for later use. Almost all
of this data comes from Altium Designer. After being developed in Designer, the data is loaded into Vault, which guards
against unwanted changes.
Vault takes care to give unique names to each file, so that the data from one design can be used again in Altium Designer,
as the building block for a higher level design. Symbols and footprints form the basis for components; components are
used to create circuits in Managed Sheets; and sheets and components together are used to create entire projects. But
how, exactly, does Altium Vault work together with Altium Designer, to provide you with easy access to all of the data and
designs that your team is working on? Let’s take a look.
www.altium.com 3
ALTIUM VAULT AND ALTIUM DESIGNER
The graphic above shows the design flow for a printed circuit board, from Designer to Vault, and ultimately to production.
This design flow allows your team to track the relationships between different kinds of data, and manage these relationships
with the Where Used function. This way it is possible, for example, to find out which project contains a particular SMPS
driver, by localizing that component in the library. You can also find out where the component is used by employing
reusable Managed Sheets from your colleagues. That way, you can save time, as you don’t need to design and test the
circuit from scratch.
In the same way, you can utilize these relationships to see when a particular circuit on a PCB has the wrong footprint.
The project in the Vault knows what circuit it is, and which footprint is used. You can fix the footprint and update both the
component and the project. But you can also check which other components are using the same footprint and fix them
also. These components can then be marked as not valid, to let an entire team know that something is wrong, both now
and going forward. This is one of the main benefits of using Altium Vault and proper data management.
The main characteristic of Vault is that it stores data as distinct items. An item can be auto-named or manually named, but
either way, each item receives its own, unique name, before being placed in storage for data revisions. The item is empty
until data is loaded into it, and your first revision is established. Subsequent changes of data won’t overwrite existing data,
but will establish a new revision, with a higher revision number, under the same item. Once a revision is loaded there is no
way to modify the data. If someone from the team needs to modify schematic symbols to comply with a new datasheet,
you can simply open and modify the symbol, and it will be loaded to the same item with a new revision number.
Old projects will be linked to the previous revision, and new projects will use the New symbol. This way, there are no
nasty issues that arise from modifying the library over time. There is also a simple way to upgrade old revisions in existing
projects, but again, the project still needs to be released under a new revision as well. Altium Vault preserves all previous
modifications, in case they’re needed down the line. Once data is loaded, it is stored forever, and there is no way to modify
or to add something to it, except by making a new revision.
www.altium.com 4
Items in the Vault are organized into main folders/zones and subfolders, the same as on your hard drive. These folders are
used for setting access rights, auto-naming and a variety of other applications. The key difference between these folders
and the ones on your hard drive, though, is that in the Vault, folder structure doesn’t define a link to an item. When any
item from Vault is used, the link is simply the name of the item, including its revision number. But there is no complex path
to that folder. Because of that, you can move items between Vault folders, and the links to your data remain unchanged.
This folder structure can be used as a flexible sorting tool, which is capable of fitting your team’s current needs. On the
other hand, since the folder doesn’t define the path to an item, you can’t use the same name for two different items in
different folders. Rather, each item name must be unique in the entire Vault. That’s where auto-naming comes in handy.
Another basic property of Vault is that every revision (not each item, but each revision) has a Lifecycle state. This state
represents validity of the data: whether or not it can be used, and for what. States can be labeled as Empty, Loaded,
Checked, Error, etc. The aim is to inform team members in a simple, straightforward way, which revisions can be used
and which cannot, and subsequently to forbid certain operations based on its state.
States are fully customizable and can be designated by name, color, allowed state changes/transitions, and who is allowed
to proceed with the state change. A state change is the only modification which can be performed without releasing a new
revision. Each state change can be extended by a short text note with an explanation as to why the change is needed (e.g.,
what error has been found, which component can be used as a direct replacement, how the data was tested, etc.). And
again, everything in the Vault is tracked, so all state changes are recorded into item history including the details of when
and by whom they were initiated. Full item history helps to clear possible misunderstandings.
www.altium.com 5
INSTALLATION AND SETTINGS
So, now that you know a bit about how Altium Vault works, let’s get into some of the more specific aspects of using the
Vault. We’ll begin with installation. The standard way of providing server oriented services like the Vault these days is to
do so via virtualized servers. That means starting with a real server to run whatever operating system you like, and on that
operating system installing and starting a new virtual server with a Windows-based operating system in it. That virtual
server is going to be dedicated solely to the Altium Vault. This approach makes tasks such as backup, future re-hosting,
upgrading of server hardware and upgrading the Vault, easy and safe. The parameters of the virtual server should follow
Vault’s system requirements. Once the environment is ready, you can work on the Vault itself.
All editions of the Vault have the same installation file, which can be found in the Altium Downloads section. The installation
process is well described in the documentation, along with some IT details.
The installation wizard takes care of all of the necessary steps. The only information you need to input is where to install
the Vault, where to place the data folders, and which database type and network TCP port number (network endpoint)
should be used. The database type is always Firebird, unless you are already using Oracle. The port is 9780 by default.
This port must be opened in the firewall of the server, which can be done by checking the documentation of your firewall.
The address of the Vault in your company network will then be http://ServerName:9780. When you need to access the
Vault via the Internet, it’s a good idea to establish VPN access into the company network first, and then access the Vault
in the standard way.
The data folder is where things become interesting. Vault is set up so that application itself and user data are strictly
separated. It’s great for IT guys to have it this way, because the app is not going to grow rapidly but the data folder contains
all user data, including the database, project data, library data, templates, user settings, SVN repositories, etc.
Files released from Altium Designer are stored in the revisions folder (formerly a subfolder of the data folder). You can
place the data folder anywhere in the server where you have enough free space. Of course, “enough” is a bit vague, so
here are at least some rough numbers based on Vault editions. With the Component edition you likely won’t need much
more than 2GB. With the Workgroup edition, 20GB will be OK, at least for the first years. With the Enterprise edition, it
depends on NIS service usage (centralized installation and upgrade service for Altium Designer). If you are going to use
NIS, you should probably use a space with around 100GB free. Without NIS you can stick with the Workgroup edition
number, which can vary in relation to the size of your team.
The application folder, in contrast to the data folder, contains the app, licenses and some settings related to the server
(Windows domain used, ports used, database type, etc.). In the end you can simply recover everything with a new Vault
installation. You should have at least 2GB of free space on the system drive for an app folder. These numbers don’t,
however, account for backups, which are discussed below.
Once installation is done, you need to activate Vault with your license files. Your license files can be accessed via Altium
Dashboard, under Server Applications, which has both the main Vault licenses and CAL licenses. Open them both and
download the ALF license files by clicking the Activate button. Then put the license files into the app installation folder. Vault
checks these files periodically, but put them in manually, by using the inetmgr Windows command, then clicking the Restart
button in the IIS Manager. IIS is a hosting platform of Altium Vault, and restarting the platform will restart the Vault also.
www.altium.com 6
When you type http://ServerName:9780 into your web browser, you should see the Vault login page:
After using admin/admin credentials you should be able to enter the Vault and see the administration interface. The most
common issues with these last two steps are firewall, installation problems (check the install log), not running the IIS
platform, or having the wrong license files.
Backup
Once everything is installed, you’ll likely want to upload a test component or project to see how it works. Before doing
anything else, though, you need to set up the backup. Especially for your first tests, you may appreciate the option of going
back to a clean installation.
Backup is done in the data folder. In order for the backup to be valid, you first need to close the database and any running
sessions. Altium Vault includes a dedicated backup utility that can perform the task for you. It can be found in the Vault app
installation folder, in the subfolder BackupTool\avbackup.exe. Follow the instructions in the documentation of the utility.
The backup tool will put all of your data into a convenient ZIP package, which is also capable of restoring all of that data. If
you want to revert to a prior version of Vault, after installing a newer version, the newer version must first be uninstalled,
and the old version installed again.
You can also achieve periodic, systematic backups automatically by scheduling them as a regular task in Windows. Just
don’t forget that the utility must be running under an Administrator’s account in order to work. Using a virtual server allows
you the opportunity to create a backup of the entire server instead of just the Vault. Platforms for virtualizations usually
offer the ability to create snapshots of the server state, including all of its data. This is the best way to go about backing up
the server, because it generates backup for both the operating system of the virtual server, as well as its settings.
Maintenance and Upgrades
Once the Altium Vault is installed and backed up, the next step is performing regular maintenance. Fortunately, there’s not
a lot to worry about. As long as backups are scheduled automatically, the only thing you have to worry about is updating
the CAL License file with each upgrade. This is done about once a year.
www.altium.com 7
Upgrades from AV 2.1 and up are simple and straightforward. The installation wizard recognizes the previously installed
version, and will offer to perform a backup, followed by an upgrade. The upgrade will remove the previous version of
Altium Vault, and then install the new one, while preserving your settings from the old version.
The upgrade also makes any necessary modifications in the data folder, to comply with the new version. As a side effect
of this process, there is no option to downgrade back to your previous version. As previously mentioned, in order to
revert to a previous version, you need to uninstall and reinstall. Therefore, pay attention to the upgrade and be sure to
perform tests of any and all new features before beginning to use the upgraded version in earnest, to be sure they comply
with your processes. Virtual servers are a convenient method of doing this, as a snapshot of the server can allow you to
perform tests simply, thoroughly, and risk free.
Web Interface
Basic setup of the Vault can also be performed with a web interface. This will usually be done by the IT department, as they
generally maintain user databases, and are therefore the best qualified to provide access to specific users as part of the
installation. Since the basic setup is done through a web interface, the IT department doesn’t even need access to Altium
Designer, only to the Vault. To access the web interface for administration, first input the address ServerName:9780 into your
web browser and login with the default user name admin and password admin. After you log in, you can see the interface
with the menu at the top. Menu item access depends on license type and user permissions, so each user can only access the
functions specifically made available to them.
Once web interface setup is complete, the first thing you’ll want to do is change the default admin user to yourself (or
whomever you want to be the admin for the program). This can be accomplished in the Users menu. It provides a simple list
of users that can be modified in a standard way.
Once the user is selected, they must be authenticated. A built-in authentication means all you need to do is enter in a password
to complete the process. From there, Altium Vault will connect to the network domain (if you are using one) and passwords
will be synchronized. As a result, Vault will accept the same password as the one you use for login into the Windows on your
work station—provided you use the same username in Vault that you do in Windows. However, as an administrator, you’ll
want to keep at least one backup user account for yourself, which is not linked to a Windows account. That way, if there are
ever issues with Windows, or your user accounts, you’ll still be able to log into Vault and change settings when you need to.
Users in Altium Vault are organized into Roles (previously categorized as Groups). One of the most important roles is that
of Administrator. Making a user an administrator provides them with access to all settings and data in the Vault. Aside from
administration, you can also define your own roles, based on your team and projects—e.g., Designers, Layout, Librarians,
Supervisors, etc. You can determine how much access and what kind to grant each role, and adjust this based on the project,
or the size of the team.
No matter how you choose to set up roles and access, you need to make sure your processes and standards are clearly
defined, to keep all data compatible and valid. Defining your workflow according to your current needs, without regard to the
future, can cause problems down the road, as data is used for different projects. You can assign multiple roles to each user if
needed, and change their roles at any time, based on the project. Taking on multiple roles is particularly common in smaller
teams, wherein certain roles can be underutilized. It’s also helpful to assign multiple people to the same role. One can serve
as backup, and the two can keep each other on task throughout the process.
You can assign whatever roles to whichever team members you feel are best suited to them. However, as a general rule,
the Admin role should be kept separate from the others. Whatever role the administrator plays in the project aside from
administration should be done with a separate user account. That way, they can’t inadvertently make major changes to the
system while under stress.
www.altium.com 8
LIBRARY MANAGEMENT
Now that basic setup has been taken care of, let’s take a look at your use of Altium Vault on a day to day basis. We’ll start
with Library management. Library 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 library 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 common, 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 library 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 library 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 library
and data at any given time.
Maintenance procedures for a database library 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 library generally doesn’t provide
any new functionality for components. It’s simply an updated incarnation of the traditional file library.
In contrast, library management in the Vault 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 Vault is specifically designed for PCB design
projects, and is customizable for whatever you need.
Strategy
How do you manage your component library? 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 library:
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 library, 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.
www.altium.com 9
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 BOM 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.
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.
Changes are made throughout the course of the project, and in the end, you’re left with a whole library full of components
that you’ve never used. If it takes extra time to have a new component approved for use, it can cause team members to
evaluate their need for that component more carefully. Is this component really necessary to the project, or will an existing
component do just as well?
Building Your Library
Now let’s take a look at the life of a component in the Vault. (A detailed, step by step tutorial can be found in the
documentation.) The difference between the Altium Vault library workflow and that of Altium Designer is that, with the
Vault library, all models - symbols, footprints, simulation models - are prepared as standalone objects before being
released into the Vault. In order to link a model with an emerging component, it must first be released. Components in the
Vault consist mainly of links to existing Vault model items and user defined text parameters. It’s a similar approach to that
of database libraries, which means the links and parameters are set via a text oriented table.
Components are built in Altium Designer using a dedicated Component Library file. The table used to do this is similar to the
database entry which creates a new component item in the Vault. Table rows represent individual components and columns
represent component models and parameters. CmpLib file content can be partially predefined by a component template
item. This allows you to define a common subset of component parameters, in order to have unified project outputs.
Component templates are a parameter of the altium-component-library folder type, which allows you to define which
template to use for components created in that folder. Along with the option to set the template, you also have options
to control visibility of component parameters in schematic sheets. You need to have at least one component released in
a particular folder to see available parameters for enabling the visibility.
www.altium.com 10
Library Processes
The processes for creating components and models are pretty straightforward. The only question is how to start that
process. There should be clear rules defined for who can decide that a new library component is needed, and under which
conditions. The project leader generally has the most comprehensive knowledge and information about the components
already being used in the company, and whether or not there’s an existing component that can serve the project’s purpose
as well as a new one.
Knowledge aside, though, there’s usually also a formal check for existing components before approving a new one. The
most efficient method is to check the models and the components used in those models at the same time. This way, you
can simply place the component into an empty project, synchronize the test schematic sheet with the test PCB and then
cross probe all pins to their pads. You can’t do that with models alone.
After that you should open the BOM generator and run test outputs to view component parameters in output files. All
the steps after the manual pin cross probe can be covered with one Output Job file to streamline the check. Checking
simulation models requires building a simulation test circuit but it’s still the best way to be sure the component is ready
for use. Once the supervisor determines that a component has passed all tests, they can set an appropriate lifecycle state,
and the team will know the component is approved.
Handling Errors
What if, during the component check—or in any other stage of the process, for that matter—an error is detected? First,
you need to set the error state in the library. Information about the error must be spread as soon as possible, so that the
rest of the team (and other teams also working with the Vault) are made aware of it, and know not to use that component
until the error is resolved. You should also take into account that an error in a component probably means there is
an error in the component’s parent items as well, such as managed sheets, sheet templates, or even entire projects,
depending on the nature of the error.
You need to check the Where-used view of Vault Explorer for these parent items, and set error states for all affected
revisions. Once you’ve located and marked all affected data, the only data you need to worry about is that which hasn’t
been released to the Vault yet. Obviously, the Vault has no control over data that’s not yet released. However, project
release should catch any errors, or the project designers can detect them easily via the Item Manager tool, where revisions
and updates can also be done.
After setting your error states, you can then start on fixing them. When the error is located in a component definition,
you can fix the problem by releasing a new component revision. However, if the error is on the model level, you need to
release a new revision not only of that model, but also of all components linked to it. This may seem daunting, but it’s
made easier with the Where-Used view.
When the fix is finally released, you can start the component check over, repeating all the steps until you have an error-
free component. The same process is used if an error is detected later on during production. If there’s an error which can’t
be fixed, such as an incorrect lifecycle definition or revision naming scheme for an item, you must establish a new item
and set all revisions of the existing item into error state.
www.altium.com 11
FOLDERS AND ITEMS
Now that we’ve discussed the library as a whole, let’s take a look at the folders and items that go into it. Data such
as components, footprints, projects, etc. are stored as items. Those items are then grouped together as folders, which
become part of an overarching folder structure. Let’s take a closer look at how this works.
Items
Items are data containers which hold together all revisions. They’re snapshots of your data as it evolves over time and is
changed by users. Once a revision is uploaded and released by a user, that revision is created, filled with the necessary
data, and locked against further changes. The only way to make any change in that data is to release new revision. All of
those revisions are then displayed under the item that’s been revised.
Create Item Dialog
Each item has a name (e.g., CMP-00238). Revisions are named based on their item, along with a revision naming scheme,
which allows separation between the item name and that of each revision.
Each revision has its own lifecycle state, which represents the current state of data validation by color coded text label,
e.g., Error. Users can set the appropriate state from those that are available in the lifecycle definition scheme. An item
defines lifecycle definitions that have been used for each revision, but the item itself has no lifecycle state of its own. The
state of the item is copied from its latest revision.
Revisions form a hierarchical structure with Parent-Child relationships. Some items can be parents to certain items, and
children of other items at the same time. For example, a component is parent to its footprint, but that same component
can be a child in several other projects. You can check the parents of a particular revision with the Where-Used view.
There is no count limit in building these relationships, so a single footprint revision can be used in as many components
as necessary. But some items, such as project items, can’t be used as children, simply because they are at the top of the
hierarchical structure, with nothing above to be its parent.
www.altium.com 12
Items can be created automatically during the release of the data from Altium Designer. Or you can create them manually
by right clicking on Item View in Vault Explorer. Items have item types, and folders have folder types as well. The folder type
affects what item types are available during a manual creation process, but that can be changed in the item’s properties to
whatever item type you need, before releasing the first revision in that item. Item types can be divided into several groups:
Models (altium-symbol, altium-simulation-model, altium-pcb-component, altium-3d-model) - Building blocks for

components or for direct usage in a PCB document (currently only available in 3D models).
Components (altium-component, altium-schematic-sheet) - Items that can be placed directly into the schematic sheet.
Templates (altium-outputjob, altium-schematic-template, altium-component-template) - Predefined settings which

are used to preserve unified results generated from a design.
Project data (altium-pcb-blank, altium-pcb-assembly, altium-pcb-design) – A set of project source data,

manufacturing data (PCB manufacturing assembly), and documentation in one item. Each item is allowed to contain
just one set of assembly data, which means that assembly variants for a particular project must be stored in
individual items.
Part choice data (altium-part-choice-list) - Items managed via Supply Chain Solutions. There is no direct interaction
expected with these items.
Other data (altium-binary-file, altium-designer-preferences) - Standalone items with data for special usage, which
aren’t directly linked to other items or revisions in the Vault.
Folders
Folders in Altium Vault can be created by right clicking on Folder View in Vault Explorer. They are used to organize items for
easier localization and grouping, as well as for setting access control. Each folder has the option to set access permissions
via the Sharing button, and those permissions can be inherited by all the items and subfolders it contains. Excluding
obvious and already discussed fields there is only one new option. The Item Naming Scheme aims to set auto-naming
of new items which are created and placed into the folder. That helps to keep names consistent. Folders need to have a
name, description, folder type, item naming scheme, and permission set.
www.altium.com 13
A folder’s name should, naturally, express its content. This is why there are currently no dedicated tools for sorting folders
in Vault Explorer. Rather, folders are sorted alphabetically. It’s important to consider this when naming folders. If you’d
rather have custom sorting, try putting a 3-digit number at the beginning of each name, and number by tens: e.g., 010
Resistors, 020 Capacitors, 030 Inductors, etc. By numbering the folders and subfolders, you can place them in any order
you wish. A leading zero allows you to have more than 10 subfolders—otherwise, 10 would be placed between 1 and 2,
and so on. The trailing zero allows you to insert up to 9 other folders later, in between, say, 010 and 020, without having
to renumber/rename the entire list.
The folder description can be used for further specification of what belongs in a particular folder. The description is
displayed under the folder name when browsing in item view, allowing you to see at a glance which folder is which. This
can be helpful if, for example, you want to be sure that your suppressor diodes go into the Protections folder, rather than
the Diodes folder.
Another hint for folder content is the folder type. There are several dedicated types for specific content, such as the
component library (components), the PCB component library (footprints), the schematic template catalog (place to put
all schematic templates), etc. The type will change what folder icon is displayed, define what item types will be offered in
the folder, and in some cases, enable additional options like visibility of component parameters in a schematic or the
definition of component template. Use dedicated folder types accordingly. There is a general folder (blue folder icon) with
no dedicated content.
Now that we’ve covered how items and folders work, let’s take a look at folder structure. The general rule in Altium Vault
is to keep everything simple. Many companies and teams end up using dozens of folders and subfolders, just for the
component library. The problem is that so fine-grained a grouping of items creates confusion as to where to place a new
component, as it can often fit into multiple folders.
It also causes confusion when browsing for components. A user may check half a dozen different folders in searching for
the item they want, wasting time in the process. Your folder structure may be sophisticated and meticulous, but it’s not
suited to the reality of day to day tasks.
Folder structure can be changed at any time without any consequences for the items themselves, because, as we covered
previously, the folder path isn’t used for addressing items. This allows you to start with a simple structure, which can be
elaborated on as time goes on, according to your needs.
The first step is to create what’s called Top Level Folders. These are the folders at the root of the folder structure. By
default, only users in the Administrator role are allowed to create these. There are also special folder types for top level
folders called zones. Subfolders in the zones should always have the appropriate folder type, as well as content related
to its particular zone.
Let’s look at a simple structure that can be adapted to your needs. We start with the empty Vault. From there, we’ll
define 4 zones: Library, Projects, Templates, and Circuit Blocks. Use a unified item naming scheme for all zones and their
subfolders, with the exception of Projects.
Library. Most teams generally have an existing component library, which they can import into the Vault. Even
so, the Vault’s library structure should be created from the ground up. Most libraries get split into subfolders
according to component functions. Subfolder names come from those functions, and can include the sorting
prefixes discussed earlier (010, 020, etc.). The initial plan is usually to use fine-grained structure, which, as
we’ve discussed, isn’t the best approach. The general goal is to minimize the number of component types
used across all projects. Having an entire series of resistors in the component library is very comfortable,
but it goes against this effort. Preparing components in an entire series is also very time consuming,
because you need complete components, to which you then add individual manufacturer part numbers.
www.altium.com 14
Generally, components should be divided into fewer than 20 folders and populated only by components that are
directly being used. When you do need an entire series of components in your library, it’s important to have subfolders
for each of them. Other than that, your number of categories should remain low.
Sample folder structure
Projects. Project data usually consists of multiple items. Therefore, it’s a good idea to have a subfolder for each
project in the Projects folder. There is no specific folder type for these project folders; however you may use a generic-
folder. Item naming in project folders is an exception. Item names affect the names of output files. Besides that,
projects usually have pre-existing names which come from other company systems or needs. Items in the project
folder are never created automatically during the project release process, so the name can be manually changed. A
project release process targets a single altium-pcb-design item (PDE, manufacturing and assembly data) when you are
not using assembly variants. When you are using variants, the release process targets single altium-pcb-blank items
(PBL, manufacturing data) and multiple altium-pcb-assembly items (PAS, assembly data). You can also use altium-
binary-file items (ABF, external documentation, firmware files, etc.) and altium-3d-model items (A3D, case or cable
models) for these projects. Access permissions depend on company policy. Team members typically are granted
read-only access. Once the project is established, an administrator or supervisor creates a project folder in Projects
with either an Anybody can view or Private setting. Then all project collaborators are listed and roles are defined,
along with access permissions, based on who is responsible for what on the team. Don’t forget that collaborators also
have to be allowed to release project item types in Operation Permissions.
www.altium.com 15
Templates. The average team has a low number of Vault templates (generally 10 or fewer), but component and
schematic template icons aren’t always clear. It can help to use the subfolders Schematic Templates (altium-
schematic-template-catalog), OutputJob Templates (altium-outputjob-catalog), and Component Templates
(altium-component-library), to keep templates separate. Each subfolder is dedicated to altium-schematic-template
(SCHDOT), altium-outputjob (OUT), and altium-component-template (CMPT) item types, respectively. Templates are
usually managed by Administrators, which means sharing is set to read-only for all other users.
Circuit Blocks. Along with the component library, you can also have a library of schematic sheets in the Vault. There
are many similar aspects for Managed sheets and for components. It makes sense to have subfolders also organized
according to their function, including numbering of folder names. Don’t omit the word circuits or some equivalent
when naming these folders, which may prevent them from mixing with library folders.
Some users like to use a Trash folder as a place for unwanted data to be stored. They’re used to this in most of their other
computing applications. However, as we’ve discussed, Vault isn’t structured for deleting files, but rather for creating and
archiving revisions. Of course, a Trash folder can still be used, to allow you to clean up other folders, and stop using invalid
items in the process. This is a valid solution in and of itself. However, be aware that users can still reach these items, and
when an item is placed in the Trash, it can sometimes be overlooked in searches. It’s much easier to indicate that an item
or folder is obsolete by changing its lifecycle. However, those who prefer to use a Trash folder are welcome to.
Item Naming and Revisions
We’ve talked a bit about item naming conventions already. The fact that folders aren’t included in the item’s naming path
means that we can move items around in the Vault where we need them, and external links to them remain preserved.
That’s particularly helpful in building the component library. The library changes and evolves over time, while project
documents remain properly linked to their components. The price we must pay for this freedom is that item names must
be unique in the entire Vault, regardless of item type.
Fortunately, this doesn’t have to pose a problem, as each folder and item type can be named automatically, using a
formula in Item Naming Scheme in folder settings, or in item release dialogs. There are predefined formulas containing
$CONTENT_TYPE_CODE and $FOLDER_TYPE_CODE parameters, to reach the item and folder codes, followed by a number
in brackets that denotes the counter field with the desired number of digits, starting from the number + 1.
The rest of the formula is plain text, which you can freely use to reach any desired names. For example, the new component
item in the folder with a $CONTENT_TYPE_CODE-001-{0000} item naming formula will create an item named CMP-001-
0001. Of course, it will only do so if that name does not already exist anywhere the Vault. Otherwise, the counter will be
set to the first unoccupied number.
You don’t have to use the automatic item name generator. Some users like to identify their items in more detail, e.g., CMP-
IC-LM555. This is fine, but remember that since it’s not possible to generate such names automatically, they must be typed
by hand. This in turn leaves a margin for error. It can also be difficult to find a pattern which will fit for each and every data
variation, both now and in the future. And it’s not possible to put the name together without reading a large amount of
documentation. You’ll most likely end up with something like CMP-IC-LM555-A, CMP-IC-LM555-B, etc. Down the line, it may
not be clear anymore which one is which.
As we saw already with folder structure, simpler is better. Use a scheme like $CONTENT_TYPE_CODE-{00000}, which will
result in component items named CMP-00001, CMP, and so on. You can use the item comment field to specify item
content in more friendly terms. The item name is how the computer identifies an item. The description is how the team
identifies it.
www.altium.com 16
PROJECT MANAGEMENT
Now that you understand items and folders, let’s get into projects as a whole. Project management can be a very broad
topic that can include time, budget, resources, etc. However, by project management in the Vault, we’re referring to the
management of project source data (i.e., Altium Designer files), together with manufacturing and assembly data (Gerbers,
ODB++, Pick&Place, etc.), documentation (e.g., schematic prints, assembly drawings, BOM, results of DRC) and a few other
project outputs, such as PCB 3D models or AutoCAD files. Basically, it encompasses all project-related files and all outputs
of projects and their storage. Processes connected with things like releases, approvals, and fixes are also part of project
management.
Project data management is available in Workgroup and Enterprise Vault editions.
Storage Places
Altium Vault has two separate storage places for projects with different purposes. The first is SVN server, where you want
to have all live project source data. That’s where development and collaboration on the project take place. The SVN server
is part of Vault installation and can be administered through VCS tab in the Vault web interface. There you can create new
repositories (one per project preferably), set access rights, and (in special cases) delete unneeded repositories. It is also
possible to link external SVN repositories there. The advantage of managing all these repositories through the Vault is that
their settings are distributed to Altium Designer automatically and listed in available SVN repositories.
It’s not necessary to use Vault SVN versioning to proceed to Vault project releases. It can be replaced by a shared drive or
by cloud services, which will help to distribute project files. Still, it’s highly recommended that you use versioning. Dealing
only with project releases is half a solution at best. Conflicts caused by simultaneous modifications by two or more users
at the same time can occur, and there’s no aid in solving them.
However, when using versioning, you are notified about the conflict and provided with suggested ways to resolve the
situation by detecting document differences (PCB has other specialized options). Altium Designer is capable of working
with the SVN versioning system directly, which is also evident in the option to place a data version into all schematic sheets
and into a PCB document in the form of a VersionControl_RevNumber parameter. This is the recommended method of
linking project releases with their documentation printouts using the versioning system.
The second storage place is the main Vault folder structure, which stores items and revisions: specifically finished
project revisions. When a project gets to its final stage of manufacturing (or at least to a prototype), you can begin the
project release process. At the end of this process you will have a project item in the Vault which contains a snapshot of
project source data and all output data, as defined by the project Output Job files.
This way, you never have to worry about, for example, having documentation generated for a different revision than the
manufacturing data. All data is released at the same time from the same project sources. You also have one storage place
for all your data along with the source data which was used to generate it. Thus, there are no questions of where the
sources are for any specific revision.
Templates
We discussed templates a little bit already in Library Management, but now let’s discuss it in more detail with regards to
projects. Model templates - empty model files with presets - are hosted by a dedicated SVN repository with files linked
into New Document Defaults in Preferences of Altium Designer, because there are no other specialized templates for these
files. Regarding PCB projects, the Vault supports templates both for schematic sheets and for Output Job files. Both can be
stored and used directly from their Vault items. Other templates must be managed in a similar way.
www.altium.com 17
Schematic templates are templates that allow you to switch them during the development process without affecting the
content of your schematic sheets. You can imagine the template as a separate background layer of schematic sheets, with
a few other underlying settings. The template is created as an empty schematic sheet with manually drawn title blocks
linked to project, variant, system or sheet parameters. Templates are defined by paper size and by title block version.
Releasing is similar to the release of simulation models where the template file is linked to a new item (altium-schematic-
template type) in the Vault template folder. Schematic sheets can be linked to the template by going to Design » Set
Template from Vault. This applies to lifecycle states and revisions also.
Output Job files are similar with regards to managing revisions, managing states, and releasing them. Regarding your
content, you need to consider that the file can be used in many different projects. Released Output Jobs are read-only, so
they must be fully universal in order to cover different requirements of individual projects.
Output Jobs have a few options to accomplish this using universal data sources like [PCB Document], controlling outputted
layers by layer classes in a source PCB document, using project parameters for output naming, BOM sorting and filtering
functions, and more. All output containers must be designated as Release Managed and all variant settings will be
overridden by release process. It’s generally effective to split different operations into individual Output Jobs. This means
there are Output Jobs like Validation, Outputs, Outputs HDI, Outputs 3D only, etc. This way, we can have unified Validation
operation, which can then be merged during the release with the appropriate output’s generation, because the release
process enables more Output Jobs for one target item.
When it’s expected that each project will have its very own Output Job, you should place the Output Job files into an SVN
template repository instead of a Vault item, and copy and modify them on the project level instead. Output Jobs can use
certain documents, such as Excel templates for BOM outputs, which should be part of all projects. These additional files
should also be in the SVN template repository and part of project templates.
The naming of schematic templates and Output Jobs can follow the auto-naming conventions of target folders, but there’s
usually a very low number of these templates, so we can break the rule and name these items manually (just this once!).
This makes it much easier to select them in some AD dialogs, where only the template revision name is presented. The
name of the source template file is then used as a revision comment.
Project templates and PCB templates can’t be used directly from Vault items, so instead, you might use the same approach
as with model items, and place them in an SVN template repository.
PCB templates are again just empty PCB documents with all presets completed, which are then used in New Document
Defaults. Or you can simply copy the required PCB template into an existing project when it’s needed.
The presets are mechanical layers, layer stacks, layer pairs, drill pairs, design rules (including Online and Batch processing),
predefined classes linked to rules, title blocks, dimensions, and documentation information (layer table, drill drawing
legend, and other legends). PCB templates are not real templates, but rather just predefined starting points for new PCB
documents. Therefore, it’s not possible to switch the PCB template once layout has begun. The change must be done
manually by changing all the settings.
Project templates can be created simply by creating an empty PCB project, and again making all presets and linking to
default sets of project documents. The documents are usually the most commonly used for Output Jobs and their BOM
templates, single PCB templates and top level schematic sheets, most commonly based on landscape schematic templates.
When a new project is created, the New Project wizard will copy all linked files into the target project folder, at which
point these files will be local copies that you can modify when needed. Default project settings in the Project Options of
an empty PCB project are viable, so the need for modifications is rare. User settings must be set in the Parameters tab.
There, you can define project parameters which can be used in all project documents from then on. This way, you can have
a single place where you define project name, PCB name, etc. and it will be listed in all documents with the same value. All
project document templates use these parameters.
www.altium.com 18
Apart from parameters, it’s recommended that you create one assembly variant named, for example, “Fully populated”
or “Default,” which can then be used for marking additional components such as spare footprints on a PCB or other “just
in case” components. Otherwise, you need to define slightly different processes for projects which are using variants and
for those without variants.
Each PCB template has its own project template, which means you can select both of these templates in a single step when
starting a new project. Of course, it’s not clear for every project which PCB template will be used from the beginning, but
PCB templates and related Output Job files can be changed afterwards when needed. It’s best to do that just before you
start a PCB layout.
All project templates must be located on a path defined by Preferences » Data Management » Templates, in order to have
them listed in the New Project wizard. The path should point to a local or shared working copy of the template repository,
in order to have the same list of templates available to all team members.
Project Development
Project development isn’t much different from the standard Altium Designer workflow. Components can be placed from
Vault Explorer, or you can link your Vault library folders to the standard Libraries panel, to use classic component selection
and placing capabilities. Managed sheets can be placed from Vault Explorer only. The Vault also has several searching
features to facilitate the selection of components.
Every user should respect revision lifecycle states during placement. Forbidding the use of components that are in an
error state is a great option here. All project designers should monitor the states of used item revisions, which can be
easily done using Item Manager in the Tools menu of the schematic editor. You should probably use this tool at least
during major PCB project milestones: just before starting your PCB layout, before making the final DRC, and of course
before releasing the project to the Vault. Noticing error states, new components, or sheets revisions early can save a lot
of time during the schematic design phase, and even more during the PCB layout.
There is currently no option to place components into a PCB document directly, so all components must be placed into
schematic sheets in order to have them on your PCB. Unfortunately, this can create some difficulties when you need to
place PCB-only oriented components, such as mounting holes, fiducials, or other referencing or documentation objects.
These PCB-only components can have a dedicated parameter e.g., Technology set to, say, AUX value, which enables you
to filter them out of BOM. But the components will remain in the Pick & Place file. That is the requested state for fiducials:
their coordinates in P&P file are used by assembly machines to reference other components. Other components like
mounting holes will also be present in the P&P file as well. This is usually not an issue, but if it becomes one, you can remove
these components using a Not-fitted state set in all used variants. Both Vault-managed projects and PCB documents can
technically contain unmanaged components placed from standard libraries, but this is bad design practice, which defeats
the purpose of library management.
Now let’s talk about BOM management, which we’ve discussed a bit already. BOM management can be handled by
the ActiveBOM feature, represented by the BOM document (BomDoc file extension, File » New » BOM Document). The
main purpose of this document is to select a suitable Supply Chain solution for the specific needs of your project. Vault
components provide the document with all known solutions that have been given by enabled vendors or from company
stock via ODBC. The user selects between one and three possible solutions by ranking them. This can be also enhanced
by the definition of alternative components from the Vault.
www.altium.com 19
BOM management should take place before starting a PCB layout. It’s best when the BOM document is established
together with the first schematic sheet and managed along with the emerging project. The BOM document also has
the capability to add processes (time and budget planning) and additional components into the BOM. The additional
components are only listed in the BOM, not in the schematics or the PCB. This can be used for the definition of additional
mechanical components, such as screws, jumpers and so on. One such component should be the PCB itself.
Stock management systems need to have all items including the PCB listed in BOM, but PCB design tools usually don’t
consider the board to be a component. However, you can fix that in the BOM document by choosing Add New Item »
Reserved (Extra-Reserved type), and manually filling in the PCB item revision name (which doesn’t yet exist), where the
manufacturing data of the PCB is released.
An alternative solution is to have a general PCB component defined in the Library (mechanical component type), which will
have a Value parameter linked to a specific project parameter. This way, you have a PCB available in BOM, even without
using a BOM document. In both cases you need to update the field with every new release of a PCB project, which means
it should be listed in the pre-release checklist.
When the PCB item is using 2 or 3-level revision naming according to the discussed rules, it’s best to omit the lowest level
(Base) in PcbRevisionName. That level represents non-critical modifications which can be performed without affecting the
manufacturing process. Therefore, we don’t need to change BOM because of them. The latest available modification of
the PCB will be used for assembly.
When the BOM document is used, all BOM generators in Output Jobs should use [BOM document] as the data source for
that document, instead of data from schematic sheets. You should also be aware of the fact that component parameters,
which are used for BOM outputs, can be incorrectly modified on schematic sheet level. This should never happen to
prevent releasing unchecked component data into the project outputs, as this is an unacceptable state. The modified state
can be detected only by using the Item Manager to update the project components from the Vault.
Existing Projects
The Item Manager has an Auto-Match function to update all unmanaged components (i.e., components from any non-
Vault library) to their respective Vault imprints. This is used to help migrate old projects to the Vault’s data management.
Components are matched by their component name field, along with their component revision Comment field. When
component names change while being imported to the Vault, then the function fails and components must be selected
manually in Item Manager.
Components are more than simply modifications which must be performed to fit a project into the Vault. You need
to synchronize your project settings, switch your schematic templates, update your components into PCB documents,
synchronize the settings of your PCB document, and finally replace used Output Jobs with the one used for Vault release.
All of these steps, excluding switching schematic templates, are done using manual modifications of all necessary settings.
This process can be very time-consuming, and as such it’s carried out only when there’s a guaranteed return on investment.
Previous projects are usually left unmanaged, and teams convert them into a managed state only when they need to
release a new revision of the product (e.g., PCB re-design, component update etc.).
www.altium.com 20
Project Release
When a project is finished you need to initiate Item Manager, to check and see if all the items you used over the course
of the project are up to date. After that, it’s important to check schematics, BOM, and PCB. Once you’ve determined that
everything is functioning properly and free of errors, you need save all documents, including project files. Then you can
start the project release process.
First, set your target items by going to Project » Configuration Manager. The release of projects can be done in several
predefined user variants - Configurations. The configurations are presented as tabs in Release View, and you can proceed
with the release of only one configuration at a time.
Each Configuration has its own name, a list of applicable Output Job files used with the project during its release, zero
or one assembly variant defined, and a target project item revision. You can’t select more assembly variants in one
configuration or merge multiple configurations into a single item revision. This means that once your project is using more
than one assembly variant, you need to release each variant separately into separated items in the Vault, preferably using
the corresponding number of configurations.
Unfortunately, these items are completely standalone datasets, without any links between them. Each item contains its
own project source data, and it’s not easy to recognize when multiple items are coming from the same project. It’s a good
idea to have project folders in the Vault to keep all related items together.
It’s common to try to reduce the revisions of PCBs as much as possible due to manufacturing costs. Unfortunately,
because of the concept of separate items for assembly variants, each release of a variant would contain a new set of
PCB manufacturing data, with no information that other revisions of other assembly variants could use for the same
PCB. Because of that, it’s better to separate manufacturing data into different items. The structure would then consist of
one item for PCB manufacturing data (PCL, altium-pcb-blank item type) and two or more items with assembly data (PAS,
altium-pcb-assembly).
In contrast to a revision which changes the PCB, items released into the PCL must always be followed by the re-release of
all PAS items. Once the PCB is changed, all assembly data must be generated again to fit the PCB. To link the PAS revisions
to appropriate PCL revisions, you can use the approach recommended above with the BOM document or with a dedicated
PCB component linked to a project parameter where you define the name of a PCL item revision.
To get complete project data for the project organized into PAS and PCL items, you need to download data from a PAS
revision and check its BOM, where you will see the PCL revision name. Then you need download the data of the PCL item
revision also. This way, it’s perfect for ERP/PLM systems. A PCB is considered to be a separate component, so it has its own
designation and manufacturing data in a separate item.
Assembly data always defines exactly which PCB/component is used. Output Jobs must be separated into Manufacturing,
Assembly and Validation parts, where the PCL item will be released by Manufacturing and Validation Job files and PAS
items will use Assembly and Validation Job files. Each PCL and PAS contains a complete set of project source data, which
means that it’s not clear where to make changes.
If you don’t use assembly variants, you can skip the proposed recommendation and have just one item (PDE, altium-pcb-
design) per project released by one configuration, making everything nice and simple.
Output Job files are used as recipes for configurations and for project release processes, respectively. To list all the
options for outputs would be a bit dense and time-consuming, but let’s focus for a moment specifically on Validation
outputs. These are where you can find basic ERC and DRC checks, as well as Differences reports which check to see if the
schematic sheets are properly synchronized with the project PCB document. A component states check is also an essential
part of the project release, to control the usage of components that haven’t been approved.
www.altium.com 21
Components that are approved for prototyping should be considered as approved here as well, because products in the
prototype stage also need to be released. When components are approved for full production, the prototype project
release can then be shifted into the production state without releasing its new revision (as long as there are no issues with
the project itself, of course). Successful results of all of these outputs are used as prerequisites to the project’s ultimate
release. If validation fails, the release should not continue.
Once all configuration settings are completed, save the project file where these settings are located. After that, you must
process commit the entire project into its SVN repository. When the commit is successful, then it’s time to initiate the first
steps of the release. These are divided into two parts: Validate Design and Generate Outputs, in the default Design Mode.
Design Mode is intended merely as a “test drive,” to see the results.
Anyone who proceeds with the release should repeat these two steps until both are reported without any issue and all
generated output files are error-free. Once the project is in an error-free state, the Release View can be switched into Release
Mode. Now we have several more steps: Design Snapshot, Validate Design, Generate Outputs, and Commit Release.
By running these steps, Altium Designer will check out any new working copy of the project, which is used for validation
and output generation. When results are again generated without any error, the snapshot and all generated files are sent
into target item revision and the project release is done. An evaluation of the released data connected with the setting of
the appropriate lifecycle state should take place immediately after any project release.
Unfortunately, the PCB Release process removes links to the SVN repository from the released project snapshot. This
means that the source data in the project is archived, but the data is difficult to use for future development, in case of a
project re-design. Therefore, instead, you need to rely on the Vault SVN repository of the project for that purpose. Simple
ZIP archives, with snapshot of the entire project folder and its working copy, can also provide a solution for this situation
but it’s best used only as a backup, in case the Vault SVN repository fails.
Keeping the live project source data in a single place (i.e., the SVN repository) helps to prevent unwanted branching of
the project when, for example, one modification is performed in one assembly item and another modification is done in
another one. All modifications must be performed only upon the data in the repository. This means that all variants are
generated from a single source.
When there is a need to go back and to perform further modifications of an old revision, it’s generally best to download
the source snapshot from the corresponding project revision in the Vault and establish a new SVN repository dedicated
solely to the development of this older revision as an intended project branch. It’s not a clean solution but this situation
isn’t very frequent, and it will do in a pinch.
www.altium.com 22
LIFECYCLE MANAGEMENT
We’ve talked a bit already about lifecycle management of your project, but now it’s time to go into it in more depth. It’s
probably the most interesting feature of Altium Vault. When all is said and done, it’s nothing more than just a text label
attached to each item revision, which can be selected from a predefined list. That label is the lifecycle state, which we’ve
also discussed. What we haven’t mentioned, though, is that you can’t simply select whatever state you want from that
list. Choosing a new state for an item depends upon that item’s previous state. This probably doesn’t sound especially
important in and of itself, but a short, simple, and (most importantly) clear representation of the current state of our data
at any given point in the project is a revolutionary new innovation in our field.
States Management
Each revision has to have at least two stages. The first is the initial state, where the revision is before the release of the
data. This state is by default called Planned. You can also call it Empty, or something else, if you prefer. It’s marked by a
color scheme of dark grey text on a light grey background.
The second state is automatically set after the data’s release, and it is always the first state in the definition (the top-left
position in the editor). The default name used to be “Released,” but this can be a bit misleading. A name like Not Checked
or Not Validated might suit this state better. Change the name to whatever works for you. The color scheme is black on
light yellow.
How do you come up with other appropriate states for your project? First of all, you need to model the path of each item
type through your team. There are some points of interest you need to capture on this path, which will help you define
your states. Here’s one example:
www.altium.com 23
A footprint is created by a librarian, confirmed by a supervisor, and used in some component by another librarian. The
purchasing department indicates that the component is readily available, after which it is used in a project, which is
successfully manufactured. How do you denote this journey in states? When the footprint is created, it’s a Draft. When it’s
confirmed by the supervisor, it’s Checked. Then it’s Used in a component, which is then marked Available. The ensuing
project goes to manufacturing, at which point it’s Verified. On the other hand, a mistake somewhere in the process could
lead to an Error state, which we’ve already discussed. Or a sudden shortage could turn an Available state into a Not
Available state.
That’s just one, albeit basic, example. There are all sorts of paths that an item or footprint can take, and a variety of other
states it can end up in. You can define them based on what fits best with your own workflow. In the meantime, this chart
can give you a more detailed picture of the path of states and processes in your project:
Names of states should be short, clear, and to the point. It’s not easy to choose a single word to represent the situation
or sentiment that you wish to express. For example, take this situation: A formal check was done, and the item can be
used for prototyping, but availability must be checked before full production starts. Now, what state can you assign to
that situation?
Of course, you can always make compromises. Based on the detailed descriptions of all states that are in the guidelines,
plus any additional state change notes, you should be able to define states that accurately represent what has happened
(Checked), what should happen (To Check), or what the data should be used for (For Prototypes). The state name you
choose doesn’t have to be perfect. What it does have to be is consistent. Its job is to indicate to any team member exactly
what’s going on with this particular item. Changing perspectives or second guessing yourself can lead to confusion and
doubts over what a particular state actually indicates.
www.altium.com 24
The color theme of each state is also very important for identifying a specific situation. Again, you can code the colors
in whatever way works for you, as long as it’s consistent, and easily identifiable for your team. One way of doing that is
using traffic light colors. Green can represent fully functional and approved states, orange represents data that can be
used under some conditions but not all, and red means error states. When additional color coding is necessary for an
intermediate state, blue can work as well—say for states just on the brink of being fully approved, or in some decision
process. Darker shades of each color for the state text and lighter colors for the state background help improve visibility
and make each state stand out better.
States have two additional flags: Visible in Vault panels and Allowed to be used in designs. The first will hide all revisions from
the user when Vault Explorer is set not to show hidden revisions. Many consider this to be bad practice, as it can make it
seem to the user like there’s no data at all, which can lead them to begin building needlessly again from scratch. Therefore,
try to avoid this flag when you can. The second flag marks the data as unwanted for future use. Thus Vault Explorer won’t
allow you to place the data into a project.
www.altium.com 25
OTHER OPTIONS
Now that we’ve covered all the basics of how Altium Vault works, what makes it unique, and the ways in which you can use
it, let’s talk about some of the other options that it offers, beginning with the Enterprise Edition.
Altium Vault Enterprise Edition
The version of Altium Vault we’ve discussed thus far is the Workgroup edition, geared mainly towards medium sized
design teams. But what about larger teams? For that, Altium Vault Enterprise Edition is what you’re looking for. It’s mostly
the same in terms of its setup and data management, but there are a few key differences in the development phase that
make it better suited to a grander scale.
The main difference that larger design teams bring with them is the need to control setup of user workstations.
Enterprise Edition contains a Network Installation Service (NIS) which is capable of preparing custom installation files from
Altium Designer, which allows you to select installed Extensions and predefined connections to the license server running
on a company server. Another function of NIS is a local distribution of Altium Designer updates. NIS monitors the global
Altium Designer installation repository, allowing you to clone required updates into the company Vault.
The upshot of this is that new features of the latest version of Altium Designer can be tested beforehand by management
and team leaders, and then released to the team after successful integration of those features in the data management.
This not only facilitates the transition between one version and the next, but allows you strict control over which version
of the program your team members are using.
The Enterprise edition is also capable of hosting Altium Designer Preferences. When you’re signed into the Vault under a
user account with an Administrator role, then you have access to a Preferences dialog, enriched by two additional buttons
called Release to Vault and Load from Vault. These preferences items are meant to be used in the Configurations tab and
managed via the Vault web interface.
A configuration can be attached to one or more user roles. As you can likely anticipate, the item from Preferences can be
loaded into any Altium Designer installation, once a user with a specific role signs into Vault according to the configuration.
That means everybody who has that particular role will have the same working environment. The configurations can also
define which schematic templates and Output Jobs (both stored in Vault items) can be used by a particular user based on
role. This also helps to unify the outputs of projects designed in this controlled environment.
The validation outputs of Output Jobs contain a Compliance test, which aims to check whether desired settings (schematic
templates, Output Jobs, Preferences, and all components from Vault) were followed in the moment of a project’s release. A
complete version of this test can be enacted only with the Enterprise edition, as your Preferences can be checked against
a particular Vault item.
The other thing that the Enterprise edition focuses on is team collaboration. It provides Managed Projects which are built
upon the Vault SVN server. These managed projects make it much easier to work with projects that are hosted in SVN. You
can simply open all existing projects by going to File » Open » Open Managed Project, and Altium Designer will handle the
SVN checkout operation.
However, what really sets Enterprise edition apart is the real-time commenting system that comes with Managed Projects.
Local copies of managed projects are connected to each other through the Altium Vault, which is used as a communication
hub. Anybody can select an area, point, or component and leave a comment related to the selected area. That comment
is then placed into any schematic sheet or project PCB document where it’s relevant, and will appear immediately in all
the copies.
www.altium.com 26
You can imagine how this can streamline discussions between a project designer and a PCB layout person, or how it
can aid in solving a schematic issue, especially when the team is spread out amongst different locations. Once an issue
is sorted out, you can flag the comment as Resolved to let the team know. Comment History is then stored in the Vault,
allowing you to access it anytime for reference.
If your design team has more than five people on it, particularly if they’re not all working from the same office, then the
Altium Vault Enterprise Edition is the one you want.
Using Altium Vault with Other Management Systems
It’s clear that Altium Vault will streamline your design process and help you become more efficient and organized. But will
implementing it require you to uproot your existing system? We’ve talked about using Altium Vault in conjunction with
Altium Designer. But what about other management systems? Can Altium Vault function with them?
First of all, integration in these other systems isn’t as readily accessible as it is with Altium. Company systems are, more
often than not, standalone solutions, where communication between systems is done mainly by file exchange (generated
by scripts), using a specified folder whose name specifies the purpose or target item. In the worst cases, all exchanges are
done manually, and information must be entered into each system separately (providing a much greater opportunity for
error). So can Altium co-exist with these systems?
Altium Vault can be classified together with all other EDA/CAD solutions, as source points in the hierarchy of company
systems. CAD systems generate documents out of nothing but ideas and specifications. In fact, that is the purpose of CAD
systems. There isn’t much information which you could use as input from any other company system, for building a new
product. The only exception is the component library.
The library of components should be always created with a PCB design tool, after which other systems should take over
those components and manage them. It can vary but the usual feeling is that components must be released into, for
example, the company ERP system, once they are created. This is, in fact, a huge waste of company resources.
There’s no way to tell if every component from the component library is being used in products—or if there’s a component
that will never be used. The ERP system needs to be notified about each component just in the moment of the project
release (or slightly before, to prevent delays). This can be accomplished by generating a BOM report. You can set a dedicated
Output Job file called, say, Notify ERP, where you define one (rather verbose) BOM report to list all the parameters of all
project components intended for purchase.
The report must have a fixed target folder, and the folder must be monitored by the ERP import tool. ERP will load the file
and generate new items for unknown/new components which are awaiting further processing. The new ERP component
items need to have a parameter with the name of the component in Altium Vault—specifically, the component item
revision name, which is used for matching components from BOM with ERP.
It’s best when an ERP item can have not just one name of source component, but an entire list of names, since one ERP item
can be used for further revisions of a component in the Vault. The designer can initiate this process whenever it’s needed
(maybe several times per project). When it’s properly set, the company’s purchasing team has the time to prepare everything
for the project. Data from ERP (stock amount, price) can be displayed back in Vault components via ODBC.
www.altium.com 27
That was the input side of the Vault. The output side is, in the end, just a bunch of packages with released data. ERP
systems usually need to have PCB manufacturing data loaded as one item and assembly data as a second item. This
comes from the conventions of mechanical CAD systems. The approach complies with the concept of separated PCL and
PAS items, presented in project management. Publishing released documents into the ERP import folder again establishes
new items in the ERP structure. When assembly data from the Vault contains a simple BOM (CSV or XML) format, then
the ERP system is usually capable of linking all ERP component items and the ERP PCB item (published from the PCL Vault
item) within the new ERP assembly item. When a project item needs metadata, it can be prepared with a script output in
the project.
Another object for data exchange can be lifecycle states. This again can vary. It can have unidirectional or bidirectional
synchronization, with rules ranging from easy to very complicated. This is because each system generally has different
meanings for its states.
The Altium Vault has no embedded tool for this task, but it can be handled using Altium Vault API (non-public). That means
there can be a custom Vault synchronization application developed, which will stand between the Vault and an ERP/
PLM/PDM system. Its general purpose is to monitor both systems for changes and to synchronize them.
Of course, this isn’t limited to lifecycle states. API has almost the same options for access to the Vault that a Vault user has.
However, the main question is one of development costs. So in weighing the costs and benefits, ask yourself how often the
situation being considered for automation is supposed to happen—not during the initial building of data management,
but afterwards, when the Vault is up and running in standard conditions. This perspective helps to optimize the amount
of custom development rapidly.
www.altium.com 28
CONCLUSION
There is, of course, much more to say about Altium Vault, how it works, and how best to use it for your own purposes.
However, this isn’t a users’ manual. It’s only a basic introduction to the Vault and how it can benefit you. If you’re looking
for an out-of-the-box solution, then Altium Vault isn’t it. It requires extensive customization and personalization to get it to
work properly. However, that customization and personalization is what makes Altium stand out from other management
systems. It’s designed to fit in with your existing workflow and adapt to how your team does things, not the other way
around. Every company, every team, and every designer, works in their own way. Altium Designer accommodates all of
those different methods of working, and Altium Vault helps you organize them into a single source, that’s easy to use and
easy to access. How can Altium Vault help make YOUR company’s design teams more efficient and more productive?
www.altium.com 29

Altium Vault Ebook

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Altium Vault Ebook

Diunggah oleh

Hak Cipta:

Format Tersedia

FOREWARD

DATA MANAGEMENT FROM 10,000 FEET

SOLVING YOUR DATA MANAGEMENT DILEMMAS

Section 2: What the Altium Vault is All About

Section 4: Basic Installation and Settings

Section 5: Building Your Library Management Strategy

Section 6: Organizing Your Folders and Items

Section 7: Project Management Basics

Section 8: Defining Your Lifecycles

Section 9: Expanding the Altium Vault Possibilities

HOW TO USE THIS PRIMER

Petr Tosovsky, MSEE

Petr is an electronics design enthusiast and has been exploring programming

What Altium Vault Is All About................................................................... 3

Altium Vault and Altium Designer.............................................................. 4

Installation and Settings............................................................................ 6

Folders and Items....................................................................................... 12

The Problems Altium Vault Solves

Altium Content Vault

WHAT ALTIUM VAULT IS ALL ABOUT

ALTIUM VAULT AND ALTIUM DESIGNER

INSTALLATION AND SETTINGS

Maintenance and Upgrades

 All users create components but librarians finish them

Building Your Library

FOLDERS AND ITEMS

Create Item Dialog

 Models (altium-symbol, altium-simulation-model, altium-pcb-component, altium-3d-model) - Building blocks for

 Templates (altium-outputjob, altium-schematic-template, altium-component-template) - Predefined settings which

 Project data (altium-pcb-blank, altium-pcb-assembly, altium-pcb-design) – A set of project source data,

Sample folder structure

Item Naming and Revisions

Project data management is available in Workgroup and Enterprise Vault editions.

Altium Vault Enterprise Edition

Using Altium Vault with Other Management Systems

Anda mungkin juga menyukai

All users create components but librarians finish them

Models (altium-symbol, altium-simulation-model, altium-pcb-component, altium-3d-model) - Building blocks for

Templates (altium-outputjob, altium-schematic-template, altium-component-template) - Predefined settings which

Project data (altium-pcb-blank, altium-pcb-assembly, altium-pcb-design) – A set of project source data,