Altium Vault eBook
Short Description
sagdgsd sdf gdfsg sdf gdf gdfsg dfg jbdfkjbjdfbjahbjkdfvdfjkbvdfjkbv d lkdn d v dfv df dvklbd jkbdjn kldn sdf gdsf ...
Description
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 pil es up, and all we’re left to see i s 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 workow. But what happens if we miss a critical piece of information like availability or pricing?
Unknown details. For 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 certications for your industry?
Scattered organizatio organization. n. What 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 DATA MANAGEMENT DILEMMAS What we really need from a new, rened data management process is three primary components, including: 1. More control over how our design data ows through our engineering workows. 2. More visibility over 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 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 unied 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 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 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 specics of what the Altium Vault actually is and how it can benet the eciency 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 benet from the Altium Vault. Section 4: Basic Installation and Settings This section dives into the specics of installing the Altium Vault on your netwo rk, 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 dening le 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 Manageme Management nt 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: Dening 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 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 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 ocial 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 eort, with a variety of dierent engineers on a number of dierent 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 oce, 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 suxes 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 dierent 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 notication 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.
www.altium.com
1
ALTIUM VAULT IMPLEMENTATION PRIMER
Altium Content Vault This answers the question of why centralized data is necessary in general. But why Altium Vault specically? In addition to the local Vault, Altium also oers 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 oered there. You also likely have dierent 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 specic 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 specic needs and have it at your disposal whenever you want it.
www.altium.com
2
ALTIUM VAULT IMPLEMENTATION PRIMER
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 dicult 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 notied 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.
www.altium.com
3
ALTIUM VAULT IMPLEMENTATION PRIMER
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 dierent 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 benets 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 modications, in case they’re needed down the line. Once data is loaded, it is stored forever, and there is no way t o modify or to add something to it, except by making a new revision.
www.altium.com
4
ALTIUM VAULT IMPLEMENTATION PRIMER
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 dierence between these folders and the ones on your hard drive, though, is that in the Vault, folder structure doesn’t dene 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 dene the path to an item, you can’t use the same name for two dierent items in dierent 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 modication 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.
www.altium.com
5
ALTIUM VAULT IMPLEMENTATION PRIMER
INSTALLATION AND SETTINGS So, now that you know a bit about how Altium Vault works, let’s get into some of the more specic 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 cl icking 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.
www.altium.com
6
ALTIUM VAULT IMPLEMENTATION PRIMER
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 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 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 oer 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.
www.altium.com
7
ALTIUM VAULT IMPLEMENTATION PRIMER
Upgrades from AV 2.1 and up are simple and straightforward. The installation wizard recognizes the previously installed version, and will oer 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 modications in the data folder, to comply with the new version. As a side eect 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 qualied to provide access to specic 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 specically 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 modied 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 dene 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 dened, to keep all data compatible and valid. Dening your workow according to your current needs, without regard to the future, can cause problems down the road, as data is used for dierent 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
ALTIUM VAULT IMPLEMENTATION PRIMER
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 unied denitions 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 specically 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 ecient. 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.
www.altium.com
9
ALTIUM VAULT IMPLEMENTATION PRIMER
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 denitions, and no footprint. These components can be immediately used in projects under development (specically 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 denition 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 dierence between the Altium Vault library workow 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 wit h an emerging component, it must rst be released. Components in the Vault consist mainly of links to existing Vault model items and user dened 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 predened by a component template item. This allows you to dene a common subset of component parameters, in order to have unied project outputs. Component templates are a parameter of the altium-component-library folder type, which allows you to dene 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
ALTIUM VAULT IMPLEMENTATION PRIMER
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 dened 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 ecient 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 aected revisions. Once you’ve located and marked all aected 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 denition, 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 errorfree 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 denition 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
ALTIUM VAULT IMPLEMENTATION PRIMER
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 denition scheme. An item denes lifecycle denitions 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
ALTIUM VAULT IMPLEMENTATION PRIMER
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 aects 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) - Predened settings which are used to preserve unied 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.
www.altium.com
13
ALTIUM VAULT IMPLEMENTATION PRIMER
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 specication 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 specic 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, dene what item types will be oered in the folder, and in some cases, enable additional options like visibility of component parameters in a schematic or the denition 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 dierent 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 dene 4 zones: Library, Projects, Templates, and Circuit Blocks. Use a unied 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 prexes 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 eort. 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
ALTIUM VAULT IMPLEMENTATION PRIMER
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 specic folder type for these project folders; however you may use a genericfolder. Item naming in project folders is an exception. Item names aect 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 altium-pcb-assembly items (PAS, assembly data). You can also use altiumbinary-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 dened, 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
ALTIUM VAULT IMPLEMENTATION PRIMER
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 (altiumschematic-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 predened 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-0010001. 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., CMPIC-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 dicult 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 identies an item. The description is how the team identies it.
www.altium.com
16
ALTIUM VAULT IMPLEMENTATION PRIMER
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 dierent 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. Conicts caused by simultaneous modications 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 notied about the conict and provided with suggested ways to resolve the situation by detecting document dierences (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: specically 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 dened by the project Output Job les. This way, you never have to worry about, for example, having documentation generated for a dierent 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 specic 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.
www.altium.com
17
ALTIUM VAULT IMPLEMENTATION PRIMER
Schematic templates are templates that allow you to switch them during the development process without aecting 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 dened 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-schematictemplate 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 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 dierent projects. Released Output Jobs are read-only, so they must be fully universal in order to cover dierent 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 eective to split dierent 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 unied 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), predened 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 predened 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 modications is rare. User settings must be set in the Parameters tab. There, you can dene project parameters which can be used in all project documents from then on. This way, you can have a single place where you dene 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
ALTIUM VAULT IMPLEMENTATION PRIMER
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 dene slightly dierent 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 les can be changed afterwards when needed. It’s best to do that just before you start a PCB layout. All project templates must be lo cated on a path dened 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 dierent from the standard Altium Designer workow. 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 nal 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 diculties when you need to place PCB-only oriented components, such as mounting holes, ducials, 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 lter them out of BOM. But the components will remain i n the Pick & Place le. That is the requested state for ducials: their coordinates in P&P le are used by assembly machines to reference other components. Other components like mounting holes will also be present in the P&P le as well. This is usually not an issue, but if it becomes one, you can remove these components using a Not-tted state set in all used variants. Both Vault-managed projects and PCB documents can technically contain unmanaged components placed from standard li braries, 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 le extension, File » New » BOM Document). The main purpose of this document is to select a suitable Supply Chain solution for the specic 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 denition of alternative components from the Vault.
www.altium.com
19
ALTIUM VAULT IMPLEMENTATION PRIMER
BOM management should take place before starting a PCB layout. It’s best when the BOM document is established together with the rst 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 denition 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 x that in the BOM document by choosing Add New Item » Reserved (Extra-Reserved type), and manually lling 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 P CB component dened in the Library (mechanical component type), which will have a Value parameter linked to a specic 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 eld with every new release of a PCB project, whi ch 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 modications which can be performed wi thout aecting the manufacturing process. Therefore, we don’t need to change BOM because of them. The latest available modication 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 modied 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 modied 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 nonVault 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 eld, along with their component revision Comment eld. 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 modications which must be performed to t 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 nally replace used Output Jobs with the one used for Vault release. All of these steps, excluding switching schematic templates, are done using manual modications 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 inve stment. 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
ALTIUM VAULT IMPLEMENTATION PRIMER
Project Release When a project is nished 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 les. Then you can start the project release process. First, set your target items by going to Project » Conguration Manager. The release of projects can be done in several predened user variants - Congurations. The congurations are presented as tabs in Release View, and you can proceed with the release of only one conguration at a time. Each Conguration has its own name, a list of applicable Output Job les used with the project during its release, zero or one assembly variant dened, and a target project item revision. You can’t select more assembly variants in one conguration or merge multiple congurations 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 i nto separated items in the Vault, preferably using the corresponding number of congurations. 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 dierent 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 t the PCB. To link the PAS revisions to appropriate PCL revisions, you can use the approach recommended above wi th the BOM document or with a dedicated PCB component linked to a project parameter where you dene 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 fo r 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 denes 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 les and PAS items will use Assembly and Validation Job les. 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-pcbdesign) per project released by one conguration, making everything nice and simple. Output Job les are used as recipes for congurations 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 specically on Validation outputs. These are where you can nd basic ERC and DRC checks, as well as Dierences 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
ALTIUM VAULT IMPLEMENTATION PRIMER
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 i ssues 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 conguration settings are completed, save the project le 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 rst steps of the release. These are divided into t wo 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 les 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 les 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 dicult 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 modication is performed in one assembly item and another modication is done in another one. All modications 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 modications 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
ALTIUM VAULT IMPLEMENTATION PRIMER
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 predened 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 re presentation of the current state of our data at any given point in the project is a revolutionary new innovation in our eld.
States Management Each revision has to have at least two stages. The rst 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 rst state in the denition (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 dene your states. Here’s one example:
www.altium.com
23
ALTIUM VAULT IMPLEMENTATION PRIMER
A footprint is created by a librarian, conrmed 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 i s created, it’s a Draft. When it’s conrmed 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 Veried. 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 dene them based on what ts best wi th your own workow. 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 dene 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. W hat 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
ALTIUM VAULT IMPLEMENTATION PRIMER
The color theme of each state is also very important for identifying a specic situation. Again, you can code the colors in whatever way works for you, as long as it’s consistent, and easily identiable for your team. One way of doing that is using trac 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 ags: Visible in Vault panels and Allowed to be used in designs. The rst 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 ag when you can. The second ag 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
ALTIUM VAULT IMPLEMENTATION PRIMER
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 oers, 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 dierences in the development phase that make it better suited to a grander scale. The main dierence 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 les from Altium Designer, which allows you to select installed Extensions and predened 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 late st 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 Congurations tab and managed via the Vault web interface. A conguration 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 specic role signs into Vault according to the conguration. That means everybody who has that particular role will have the same working environment. The congurations can also dene 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 i s 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
ALTIUM VAULT IMPLEMENTATION PRIMER
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 dierent locations. Once an issue is sorted out, you can ag 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 ve people on it, particularly if they’re not all working from the same oce, 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 ecient 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 le exchange (generated by scripts), using a specied folder whose name species 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 classied 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 specications. 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 notied 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 le called, say, Notify ERP, where you dene one (rather verbose) BOM report to list all the parameters of all project components intended for purchase. The report must have a xed target folder, and the folder must be monitored by the ERP import tool. ERP will l oad the le 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—specically, 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
ALTIUM VAULT IMPLEMENTATION PRIMER
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 dierent meanings for its states. The Altium Vault has no embedded t ool 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 benets, 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
View more...
Comments
