Altium Vault eBook

(1)

(2)

(3)

www.altium.com

www.altium.com ii

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

be waiting for your next data management criss. And when it occurs, will you know management criss. And when it occurs, will you know what to do? Many of us what to do? Many of us don’t, and thedon’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 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 pil

unattended, unmanaged, and devoid of any real intelligence. And as data comes in, it piles up, and all we’re left to see ies up, and all we’re left to see is thes 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.Limited insight.More often than not, we only get a limited perspective of our data as it travels through our designMore often than not, we only get a limited perspective of our data as it travels through our design workow. But what happens if we miss a critical piece of information like availability or pricing?

workow. But what happens if we miss a critical piece of information like availability or pricing?



 Unknown details.Unknown details. For those of you reading this primer that are in charge of the design review process, what happens 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

in that last-minute crunch to push a design out the door? Are all design out the door? Are all of your BOMs validated with approved of your BOMs validated with approved components?components?

And are you in compliance with RHOS, REACH, or any other of the myriad of certications for your industry?



 Scattered Scattered organizatioorganization.n. What happens if a change needs to be made to your design? And more importantly, how are 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

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 DAT

SOLVING YOUR DATA MANAGEMENT A MANAGEMENT DILEMMASDILEMMAS

What we really need from a new, rened data management process is three primary components, including:

1.

1. More controlMore controlover how our design data ows through our engineering workows.over how our design data ows through our engineering workows.

2.

2. More visibilityMore visibility over what changes are made to our design data and what state they are in at any given moment. over what changes are made to our design data and what state they are in at any given moment.

3.

3. And more organizational powerAnd more organizational power to allow our teams to all remain on the same page and share information freely. 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 unied

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 exibility, allowing design teams to implement a fully automated data

management system. But since there’s no right or wrong way to

management system. But since there’s no right or wrong way to manage design data this presents a rather steep learningmanage 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:

(4)

Section 2: What the Altium Vault is

Section 2: What the Altium Vault is All AboutAll About

This section will dive into the specics of what the Altium Vault actually is and how it can benet the eciency of your

design team.

Section 3: How the Altium Vault and Altium Designer Work Together

This section provides a high-level overview of how

This section provides a high-level overview of how the typical PCB design process can both integrate and benet from thethe typical PCB design process can both integrate and benet from the

Altium Vault.

Section 4: Basic Installation and Settings

This section dives into the specics of

This section dives into the specics of installing the Altium Vault on your netwoinstalling the Altium Vault on your network, backing up your design and componentrk, backing up your design and component

data, and accessing the Vault’s web interface.

Section 5: Building Your

Section 5: Building Your Library Management StrategyLibrary 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 dening le

creation strategies and dening le organization schemes.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

Section 7: Project ManagemeManagement Basicsnt 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 nal release for manufacturing.

Section 8: Dening 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

Section 9: Expanding the Altium Vault PossibilitiesVault Possibilities

Need from exibility 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 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 ocial company policy or opinion.

Here’s to discovering the true engineering potential

Here’s to discovering the true engineering potential in your data management system. May this primer save you countlessin 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

(5)

www.altium.com iii 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.

(6)

Introduction...

Problems Altium Vault Solves Altium Content Vault

What Altium Vault Is All About... Altium Vault and Altium Designer... Installation and Settings...

Backup

Maintenance and Upgrades Web Interface

Library Management...

Strategy

Building Your Library Library Processes Handling Errors

Folders and Items...

Items

Folders

Item Naming and Revisions

Project Management... Storage Places Templates Project Development Existing Projects Project Release Lifecycle Management... States Management Other Options...

Altium Vault Enterprise Edition

Using Altium Vault with Other Management Systems

Conclusion ... 1 3 4 6 9 12 17 23 26 29

(7)

www.altium.com 1 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 eort, with a variety of dierent engineers on a number of dierent 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 rst 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 x an error in the component library, but it continues to come up on other boards, again and again, sometimes for years after the x.

 One of your team members is out of the oce, and you need to access their work in order to complete the project by deadline. You go through their les and immediately get lost in a bizarre and complex le naming system that includes suxes 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 dierent 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 notication 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 nding 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 nd quickly, saving time and money. Whil e 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 o greatly in the months and years to come.

(8)

Altium Content Vault

This answers the question of why centralized data is necessary in general. But why Altium Vault specically? In addition to the local Vault, Altium also oers 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 ngertips, why do you need the local Altium Vault at all?

The Altium Content Vault contains seve ral 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 oered there.

You also likely have dierent 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 t every variation you would need or want. Not to mention the information you need that’s specic 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 nd 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 nish the design according to your specic needs and have it at your disposal whenever you want it.

(9)

www.altium.com 3 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 w ays 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 dicult 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 lling in the gaps that appear when Altium Designer is used for teamwork. Therefore, to understand Altium Vault, you must rst 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 exible 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 nd 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 notied that the latest version of their device is not working properly. They will naturally perform the necessary steps to x 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 les 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 le, 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 wi th Altium Designer, to provide you with e asy access to all of the data and designs that your team is working on? Let’s take a look.

(10)

ALTIUM VAULT AND ALTIUM DESIGNER

The graphic above shows the design ow f or a printed circuit board, from Designer to Vault, and ultimately to production. This design ow allows your team to track the relationships between dierent kinds of data, and manage these relationships with the Where Used function. This way it is possible, for example, to nd out which project contains a particular SMPS driver, by localizing that component in the library. You can also nd 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 i s, and which footprint is used. You can x the footprint and update both the component and the project. But you can also check which other components are using the same footprint and x 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 benets 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 rst 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 ol d revisions in existing projects, but again, the project still needs to be released under a new revision as well. Altium Vault preserves all previous modications, 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.

(11)

www.altium.com 5 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 dierence between these folders and the ones on your hard drive, though, is that in the Vault, folder structure doesn’t dene 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 exible sorting tool, which is capable of tting your team’s current needs. On the other hand, since the folder doesn’t dene the path to an item, you can’t use the same name for two dierent items in dierent 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, allo wed state changes/transitions, and who is allowed to proceed with the state change. A state change is the only modication 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 nee ded (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.

(12)

INSTALLATION AND SETTINGS

So, now that you know a bit about how Altium Vault works, let’s get into some of the more specic 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 le, 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 rewall of the server, which can be done by checking the documentation of your rewall. 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 rst, 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 rst 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 les. Your license les 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 les by clicking the Activate button. Then put the license les into the app installation folder. Vault checks these les 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.

(13)

www.altium.com 7 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 ente r the Vault and see the administration interface. The most common issues with these last two steps are rewall, installation problems (check the install log), not running the IIS platform, or having the wrong license les.

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 rst 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 rst need to close the database and any running sessions. Altium Vault includes a dedicatedbackup 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 rst 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 oer the ability to create snapshots of the server state, including all of its data. This i s 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 le with each upgrade. This is done about once a year.

(14)

Upgrades from AV 2.1 and up are simple and straightforward. The installation wizard recognizes the previously installed version, and will oer 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 modications in the data folder, to comply with the new version. As a side eect 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 qualied to provide access to specic 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, rst 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 specically made available to them.

Once web interface setup is complete, the rst 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 modied in a standard way.

Once the user is selected, they must be authenticated. A built-in authentic ation 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 dene 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 dened, to keep all data compatible and valid. Dening your workow according to your current needs, without regard to the future, can cause problems down the road, as data is used for dierent 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.

(15)

www.altium.com 9 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 nished product will be a mess as well. In order to get reliable results, components in the library must have unied denitions 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 le oriented style. This means that data is grouped together by les, categorizing related components. All les 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 les, 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 le 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 exibility. Rather than being simply a general purpose database, Altium Vault is specically 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 ecient. 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 les, 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.

(16)

 All users create components but librarians nish them

This last strategy is a hybrid that combines the good elements of both previous strategies. It all ows all users to create new components, but generally utilize only rough, incomplete denitions, and no footprint. These components can be immediately used in projects under development (specically 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 eshed 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 denition 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 i nclude 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 fo r 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 dierence between the Altium Vault library workow 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 rst be released. Components in the Vault consist mainly of links to existing Vault model items and user dened 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 le. 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 le content can be partially predened by a component template item. This allows you to dene a common subset of component parameters, in order to have unied project outputs.

Component templates are a parameter of the altium-component-library folder type, which allows you to dene 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.

(17)

www.altium.com 11 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 dened for who can de cide that a new library component is needed, and under whi ch 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 ecient 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 les. All the steps after the manual pin cross probe can be covered with one Output Job le 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 aected revisions. Once you’ve located and marked all aected 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 xing them. When the error is located in a component denition, you can x 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 x is nally 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 xed, such as an incorrect lifecycle denition or revision naming scheme for an item, you must establish a new item and set all revisions of the existing item into error state.

(18)

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, lled 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 denition scheme. An item denes lifecycle denitions 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.

(19)

www.altium.com 13 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. Ite ms have item types, and folders have folder types as well. The folder type aects 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 rst revision i n 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) - Predened settings which

are used to preserve unied 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-le, 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 elds 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.

(20)

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 specication 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 specic 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, dene what item types will be oered in the folder, and in some cases, enable additional options like visibility of component parameters in a schematic or the denition of component template. Use dedicated fol der 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 ne-grained a grouping of items creates confusion as to where to place a new component, as it can often t into multiple folders.

It also causes confusion when browsing for components. A user may check half a dozen dierent 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 rst 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 dene 4 zones: Library, Projects, Templates, and Circuit Blocks. Use a unied 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 prexes discussed earlier (010, 020, etc.). The initial plan is usually to use ne-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 eort. 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.

(21)

www.altium.com 15 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 specic folder type for these project folders; however you may use a generic-folder. Item naming in project folders is an exception. Item names aect the names of output les. 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 pcb-assembly items (PAS, assembly data). You can also use altium-binary-le items (ABF, external documentation, rmware les, 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 dened, 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.

(22)

 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 les, 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 predened 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 eld 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. F or 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 rst 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 ne, 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 dicult to nd a pattern which will t 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 eld to specify item content in more friendly terms. The item name is how the computer identies an item. The description is how the team identies it.

(23)

www.altium.com 17 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 les), 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 Auto CAD les. Basically, it encompasses all project-related les and all outputs of projects and their storage. Processes connected with things like releases, approvals, and xes 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 dierent purposes. The rst is SVN server, where you want to have all live project source data. That’s where development and collaboratio n 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 i s 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 les. Still, it’s highly recommended that you use versioning. Dealing only with project releases is half a solution at best. Conicts caused by simultaneous modications 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 notied about the conict and provided with suggested ways to resolve the situation by detecting document dierences (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: specically nished project revisions. When a project gets to its nal 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 dened by the project Output Job les.

This way, you never have to worry about, for example, having documentation generated for a dierent 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 specic 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 les with presets - are hosted by a dedicated SVN repository with les linked into New Document Defaults in Preferences of Altium Designer, because there are no other specialized templates for these les. Regarding PCB projects, the Vault supports templates both f or schematic sheets and for Output Job les. Bo th can be stored and used directly from their Vault items. Other templates must be managed in a similar way.

(24)

Schematic templates are templates that allow you to switch them during the development process without aecting 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 dened by paper size and by title block version. Releasing is similar to the release of simulation models where the template le is linked to a new item (altium-schematic-template type) in the Vault (altium-schematic-template folder. Schematic sheets can be linked to the (altium-schematic-template by going to Design » Set Template from Vault. This applies to lifecycle states and revisions also.

Output Job les are similar with regards to managing revisions, managing states, and releasing them. Regarding your content, you need to consider that the le can be used in many dierent projects. Released Output Jobs are read-only, so they must be fully universal in order to cover dierent 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 ltering 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 eective to split dierent 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 unied 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 les 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 les 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 le is then used as a revision comment.

Project templates and PCB templates can’t be used directly from Vault i tems, 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), predened 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 predened 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 les into the target project folder, at which point these les 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 modications is rare. User settings must be set in the Parameters tab. There, you can dene project parameters which can be used in all project documents from then on. This way, you can have