Vault-Driven Electronics Design - FAQs

Parent article: Vault-Driven Electronics Design

Use the following links to browse through frequently asked questions relevant to Altium's Vault-Driven Electronics Design methodology. For further, more detailed information on aspects of Altium's Design Data Management System, use the links available in the panel to the right.

What is the methodology?

Put simply, the methodology is an evolving approach to design that leverages Altium's electronics design systems in the manner in which they were designed to be used. And it is an approach that also incorporates intelligent design and management processes, to arrive at a fundamentally solid path by which to design electronics in a streamlined, consistent way. A methodology that creates a highly productive, high-quality design flow, based on the concept of Designing for Reuse, and facilitated by the high-integrity and lifecycle management features offered by Altium Vault Technology.

How did this new approach to design come about?

Altium's Hardware Design Team use Altium tools and technologies to design various real-world boards, in-house. And in doing so, they have faced the same design and data management challenges that Altium's users also face in their day-to-day design lives. So it is this very design work that prompted the development and adoption of techniques to streamline the design flow. The result is a best-practice design methodology that, while still evolving, has been tried and tested with real results and marked gains in quality and productivity.

In short, the Team are honing the optimal way to design electronics using Altium tools and technologies moving forward, based on their own experiences and reinforced by the experiences of Altium's 40,000+ users.

What exactly is 'Designing for Reuse' and how can it help me?

Designing for reuse is a concept that entails capturing and configuring all elements of design so that they can be easily reused across any new future designs. By only ever designing with design elements that have been released into an Altium Vault, and using lower level design elements to build those at a higher level, the workflow of designing for reuse naturally falls out as being spiral-like in nature, with each building block being created in the Design Area and then released into a vault, to be used in the creation of a building block at the next higher level of abstraction. So models that can be reused in a new component, components that can be reused in functional sub-circuits, functional sub-circuits that can be reused in the design of a modular assembly, and then ultimately reusing a modular assembly in a larger design itself.

Eliminating the repetition of design effort, a designer is no longer starting from scratch, or re-inventing the proverbial 'wheel' as it were. By adopting this concept, an engineering team will not only nurture and grow an impressive repository of reusable design elements, but also benefit from the ability to build future designs expediently through their availability. And safe in the knowledge that all of these design reusables are securely managed, audited and ratified for use – and available to the entire design organization from a single point.

What is a module board?

This is a PCB that features an ensemble of system level elements to provide higher level design functionality in a 'satellite' fashion. Such a board can later be placed, just like any other component, onto a larger PCB assembly. This makes it possible to prototype complete systems with higher level building blocks and to really speed up the development process.

Why is this approach termed 'Vault-Driven"?

"Vault-driven design" can be thought of as the catchphrase for the key mantra that all elements in a design must be sourced from an Altium Vault. Designing for reuse builds a range of design building blocks at various levels of design abstraction, with all of these blocks released securely into a vault. In the vault, each of these unique design items attracts the benefits of lifecycle-management. And established rules ensure that no higher-level building block can ever have a more mature lifecycle state than the elements used in its creation. The result is that a designer can come to the vault to reuse any of these design elements, safe in the knowledge that they have been fully validated during their release to the vault, and subsequently ratified for use through management of their lifecycles.

Not only is design effort greatly reduced, since the designer is not re-inventing multiple wheels over and over again, with no 'loose canon' design elements sourced from outside a vault, the final product can be released to manufacturing with much greater confidence.

Will adopting this methodology enhance productivity?

In a word, YES. Design productivity ramps up as more design content is created, released to and subsequently approved for reuse from, a vault. Future designs become quicker to implement as the vault of design 'building blocks' grows, and required circuit functionality becomes available for placement in modular fashion. And with templates and common files in-place, a designer can simply browse through project templates, choose the one that matches the requirements of their next design project and, quite literally in a single click, open a new project in Altium Designer with all base-level design documents brought-in. They are no longer distracted with having to set up these documents, they are right there from the start. The designer can simply get down to the business of designing – making good use of a myriad of reusable vault-managed design items to build that next lucrative, cutting-edge electronic product! Even junior designers can create products that rival those of seasoned designers; all by standing on the shoulders of the work that has preceded them.

How important is the use of Version Control in this methodology?

Version control plays a key (and vital) role in this design methodology. It is a version control repository – or Design Repository – that stores the design-side source, the source that gets incrementally changed by a design team on a day-by-day basis, and released (and re-released) into an Altium Vault as a series of evolutionary revisions of linked design items.

By using a version-controlled Design Repository, you have the integral assurance that no revision of a design is ever lost, allowing for safe collaboration on the same design between members of a team that can be geographically diverse in their locations. The very nature of the version control system provides an important audit trail that documents how design elements have evolved prior to being released into a vault. Changes made by any member of the design team are recorded the instant they commit that change to the version control repository, providing recorded evidence of who changed what, in which document, and when. So the version control system can keep tabs on all the minor revisions of a design element that culminate in major releases being made to the vault. Full accountability and transparency.

The methodology also relies heavily on version control as the dwelling place of design templates and to implement the concept of common files that are shared by design projects. So a structure of project template files and applicable linked source documents. The designer comes to the version control repository to checkout these files locally, and use the project templates as a means to get the ball rolling for any new design project that comes along.

How can I be sure a designer uses a common linked Output Job file without making changes on-the-fly?

A designer shouldn't need to change these files. They are configured to produce the right manufacturing information from the start. But, should a file need to be modified in any way, its storage within the version-controlled Design Repository comes into play. Since the board release process – releasing a configuration of a board design to a new revision of a linked Item in a target vault – checks out and works with the HEAD revision of the source project from the Design Repository, a file must be checked back in for any change to 'take effect'. The instant a file is checked in, it is stamped with who modified it, and when. So there is full accountability, no circumventing the system!

Why not include the panel document as part of the board design project?

Panel files are not stored as part of the board-level design projects, but in their own, separate projects. The reason for this is that a panel is rarely ever used to fabricate a single board – and one panel may be used to fabricate a number of different boards. So a panel is conceptually very different to a standard board-level design, in terms of what is ultimately being manufactured, and is therefore released to the vault as a distinct item in its own right.

Why does the structure in the vault need to match that in the version control repository?

Best practice is to have a 1-to-1 match between the structure in the version-controlled Design Repository and that in the Altium Vault. This keeps a direct (and clean) relationship between source in VCS and the corresponding linked managed items in the vault, making it easy for anyone in the design team to move between the two and find what they need.

Why do managed sheets need a 2-level revision naming scheme in the vault?

For a model or component, any change is going to be significant, so a 1-level scheme suits this. For a managed sheet, two levels of design 'change' can be experienced –  minor revisions (text changes for example) and major revisions, something that changes the circuit or functionality of that circuit substantially. Therefore a 2-level scheme is employed to reflect this.

How should I store my domain models?

Although a single library can contain multiple models, from a version control perspective it is best practice to have one model per library file. This allows you to check out and modify just the models you need to modify, without registering a version change to an entire, single source. The design methodology therefore adheres to one schematic symbol per Schematic Library file (*.SchLib), and one PCB 2D/3D Component model per PCB Footprint Library file (*.PcbLib).

Why is a generic symbol named differently to that of a vendor-specific symbol?

Since the symbol is to be used generically, across vendors and also by generic components, it cannot have a vendor prefix or be 'locked-in' as a specific part. Rather its name is kept generic, simply providing three key pieces of information:

• The functionality or type of component that is being represented by the symbol.
• The functionality of each pin of the device – its pin assignment.
• How many pins the device has.

These three elements provide all the relevant information a designer needs to know, by looking at that symbol's name, exactly what type of component that symbol can be used for, and how that symbol is used, without having pin assignments explicitly drawn as part of the symbol.

How are managed sheets partitioned?

The functional sub-circuits implemented through managed schematic sheets need to be created in a way that maximizes the likelihood of their later reuse. For example, rather than creating a single block of, say 9 LEDs, its probably more advantageous to create a single LED design block that can be placed 9 times. In both instances the functional intent is fulfilled but the single LED block can be more readily reused across other designs. Ideally:

• Each managed sheet should feature a single or small group of key components focusing on a specific function.
• All possible supporting circuitry should be included in the sheet.
• Parts of the design that can be configured in multiple ways can be refactored to parent or sub-sheet within reason, allowing the sub-sheet behavior to be configured from the parent without adding unnecessary structural overhead.

The exact determination of how to partition reusable design blocks will fall to the experience of the designer but it is also one of the single biggest areas where future design efficiencies can be gleaned.

I read somewhere that all projects adhere to the use of strict hierarchy? Where is that configured?

That's right. The use of strict hierarchy for all projects allows names to be defined differently for any two connected objects, at different levels of the design hierarchy, because their connection is explicit. And this explicit connectivity negates the need for Net Labels at the managed sheet level (since doing so makes it harder to manage connectivity through the design in which the managed sheet is used). This type of connectivity is defined on the Options tab of the Options for Project dialog (Project » Project Options). In the Net Identifier Scope field, select the entry Strict Hierarchical (Sheet entry <-> port connections, power ports local).

What is the best way to get data to the manufacturer?

There are two ways to get data into the hands of the Supply Chain – fabrication data to the Fab House and Assembly data to the Assembly House. One is to define a Publishing Destination and then upload released data for the required Item Revision to that destination. This destination – and its data – can then be shared with the relevant parties.

But a more streamlined approach is to simply allow these parties controlled access directly to the generated data in the vault itself. Not only more convenient, but also far more secure, since they are accessing the data in the vault, without it having been published into the outside world. By careful configuration of vault sharing and folder-level access permissions, you can fully control who is able to see what content in your vault – giving the right people, the right access, to the right data.

The streamlined efficiency of Altium's design methodology reaches out of the vault and makes the data readily available to the manufacturing and assembly teams. You are free to continue designing, safe in the knowledge that your board will be fabricated and assembled exactly the way you intended – 'Built as Designed' so-to-speak.