In the previous instalment of Envision we introduced Altium Designer’s new high-integrity data management capabilities, available in our latest software release – Altium Designer Release 10.
You can read that Envision article here, and you’ll find the webinar it’s based by selecting the Smart Data Management entry in our growing collection of Altium Designer Release 10 videos.
To briefly recap, the discussion covered the need for rigorous design data management, and how the conventional approach to achieving this introduces barriers to design innovation and slows project development. Altium has taken on the challenge of developing the synchronization, tracking and storage features that are needed for a highly robust, high integrity data management process that doesn’t stand in the way of innovation.
The result is a groundbreaking new set of data management capabilities in Altium Designer Release 10 – productivity and design freedom can now exist in harmony with high-integrity data management. It introduces a design data management model that allows a formal definition of the links between the design world and the supply chain that’s ultimately responsible for building the actual products. From an electronics design perspective, the product production items are genrally blank and assembled boards.
To follow up on that previous discussion and webinar we’re now taking a more detailed look at the design release process in Altium Designer Release 10. Again, this is based on a great new webinar video – it's titled High Integrity Releases, and can be found in the Altium Designer Release 10 videos collection. It recaps the key concepts involved the release process, shows you how it all works in practice, gives context to the terms used and shows you how to manage flow from design through to release.
High integrity design releases
In the past, the processes of releasing electronic design data to production has been largely relegated to an informal series of steps tacked on the end of the design process. But the fundamental mechanisms of electronic product design have changed, and this ad-hoc approach is no longer adequate. In the modern electronics industry, manufacturing and design functions are now much more separated, so an engineer can’t just duck over to the production floor to solve an assembly problem or see a manufacturing bottleneck, like we used to.
What’s more common is working with geographically, and even linguistically, distant manufacturers, and this can bring a lot of uncertainty to the process of getting a product to market. Indeed, the data integrity doubts and problems that generate uncertainty will be familiar to most engineers.
For example, you might send a PCB fabricator a set of Gerbers and later regenerate a new set after a few design changes, but how do you know the fabricator is going to use the right version? Or perhaps the board fabrication is fine, and we send the pick-and-place files and Bill of Materials off to the assembler in another country. But how do we overcome the nervous feeling that those manufacturing instructions may not exactly match the boards we are getting made?
In this global landscape of electronics design, the variables and risks can be largely mitigated with a good, rigorous data management process. The only solution to this until now has involved a whole lot of restrictive hand-tying and rigid manual processes, which are still error prone. But in Altium Designer Release 10, the new Release Management process has been developed to help you solve design management problems without tying your hands behind your back.
 |
 |
Design data is used to generate output files that are released to make physical Items – typically, blank and assembled boards.
The key benefits
Here are just some of the benefits of adopting and using the new system:
- Integration with version control
When implemented, it ensures that no "private copy" of an essential design document is ever allowed to sit on an engineer's hard drive – with the potential of becoming lost or missed. This can save hours of searching for the right set of design documents that were used to generate a released product. - Solid audit trail
During the release process Altium Designer records the version control repository address and revision of the project, and commits this information to the release. This creates a perfectly transparent audit trail from the latest released revision all the way back to the first check-in of the source design documents. - 'One-shot’ releasing
The system only allows you to release a configuration of a design project once to any given revision of a targeted Item. No further data can be generated and released into that unique revision. - Automated and repeatable design release process
From taking the snapshot of the design files, through validation, output generation and final committal of the release data, it’s instigated by a one-touch operation. If any step fails, the release stops. - Validate the design as an integral part of the design release
process
For additional peace of mind and to ensure the integrity of the design data, you can add validation checks into the release process 'flow'. Along with standard ERC and - Data identification
All generated data files from the design release process are prefixed with the Item ID and the Item Revision ID, ensuring there can be no ambiguity as to which revision of which Item will be built from those data files. - Optional degrees of lifecycle management
This can be no management at all, through simple management including states and state transitions, to fully structured management. - Permission-controlled lifecycle management
The system allows you to implement folder-level security where you nominate those who can change the revision to a certain state – for example, from Prototype to Production. - Cloud-based publishing
Publish release data directly from a Release Vault to a shared storage medium in the cloud, such as Box.net.
Terminology
As covered in the previous Webinar, this new concept of a defined design release management system involves a few unfamiliar terms that need to be defined for the sake of clarity:
- Item
An Item is something you make or acquire, and it must be uniquely identifiable. In our case an item would typically be a bare board or an assembly (based on that board). The item’s identifier or item ID is also used to identify exactly what Item will be made from an output such as a set of Gerber files. - Revision
The design and to some degree, the function, of an electronic product can change somewhat over time or for different end-user markets, so our manufacturing outputs for the electronic product must be marked with the item and revision. By reserving the revision before creating the outputs that go in – or are linked – to it, you can be sure that there will no outputs in existence that don't have an assigned revision. - Revision lifecycle state
When we run a release we’re generating the outputs and putting them, or you could say storing them, in that revision. The revision is now used, and we cannot re-release to the same revision, otherwise we would not have consistency and integrity. But we can label that release according to what it can be used for. Initially, for example, we might promote it from being a new design to being in a prototype state – that is, we can use the manufacturing data from that release to make prototypes. If the prototype performs adequately, we may then promote that release to being in a production state, meaning that we can use that data to go to full production. On the other hand, if our prototype didn’t work, we might abandon this particular revision. There are a few different states like this that releases can go through, as discussed later. - Design Vault
Keeping the design in a source control repository or what we call a design vault allows designers to keep a record of a given design’s progress, and even allows other important features like design collaboration between team members – see the new PCB Design Collaboration feature for more information. Using a design vault also gives us the ability to exactly reproduce our design at any point in time. Although the vault can be based on a simple folder system, normally a version control system like subversion is the back end of the design vault. - The Release Vault
Since all the releases contain critical product information, and their integrity must be maintained, they need to be stored in a single place which is secure – this is the Release Vault. It’s a place where other key staff members – such as manufacturing engineers – are able to enter this storage and select the correct manufacturing files with confidence. The files are clearly identified in their release by item ID, revision and production status. - Data quality
An important point about generating releases is that you don’t want to release from incomplete or low-yield designs. You also want to be sure that there is a traceable record confirming that design data, integrity and checking have been completed successfully. To satisfy that criteria, the release process also has a validation phase where electrical rules, design rules and design Vault consistency are checked before the release can proceed.
Think of the data required to build a revision
of an Item being stored in an ‘item revision box’. In turn, this is stored
(along with any other released revision boxes) in the Release Vault.
Configurations are the key
An important prerequisite to releasing a design is specifying which product (and revision) is to be made from the design data, since the parametric nature of PCB design projects enables a single project to be the source of multiple real-world production Items. For example, a single PCB design project can be the source of not only a fabricated 'bare' board, but quite possibly one or more assembled boards – each a unique production Item in its own right.
Manufacture of these production Items is driven by variants defined for the project, along with Output Job files that generate the project’s fabrication/assembly outputs. Altium Designer employs a formal configuration structure to map from source PCB project in the Design Vault, to a specific revision of an Item in the Release Vault – this is the concept of PCB Project Configurations.
Fundamentally, you need to configure the project for generating the actual release – that is, the instructions needed to make the product from the current design files. This encompasses any of the outputs you may need – gerbers, ODB++, pick-n-place, bill of materials and so on. In fact you can make as many different configurations of the design as you want. This is particularly useful because there may be one PCB, with several assembly variants, or even different variants of the board where component silkscreens may be different on the final PCB.
Configurations are part of the actual design project, and provide the link from the design domain to the manufacturing domain. Each configuration represents an Item that we want to build in the real world, and defines the data that will be required by a manufacturing organization to actually build that Item. So when we release a design project, we are in fact releasing a configuration of that project. The generated 'release data' is stored in the revision of the target Item specified in that configuration.
Validation and release
Before actually going through the release process, there’s a good chance you’ll want to be able to validate the design – that is, run the design rule checker, electrical rules, and more importantly, make sure the schematics and the PCB have no differences between them. You may also want to generate output files, just to look at the gerbers or perhaps do a preliminary purchase of components for a prototype, or simply perform this as a trial run before committing to a real release. This where the output generators are run in Design Mode (rather than Release Mode).
When moving on to Release Mode, it’s important to realise that running a release commits that release to the current item revision. To prevent loss of release data integrity, this revision can only be used with one release flow execution. The only way to run a release again after this is to create a new item revision.
The release process flow involves these main automated steps:
- Checking out a snapshot
This creates a tag of the design documents from the current revision in the design vault – which might typically a subversion repository. This snapshot in time is a consistent copy which is traceable, because the tag is named after the item ID and the current item revision which we’ve associated with this particular release. - Validate the design
This runs the validation checks mentioned above. The release can’t continue if one of these fails – for example, the design or electrical rules check. This brings an important assurance to the release process that critical design parameters have been met or exceeded. And in Release 10 of Altium Designer, specific validations can be added to support a rigorous release process. Along with electrical rules check for the schematics and design rules check for the PCB, a Differences Report can be included, for example. This ensures that the schematics and PCB design are fully synchronized with each other. - Generate outputs
Assuming the validation stage has completed without errors, fabrication and assembly outputs are generated. Ultimately, these are the instructions from which the physical Item will be produced so it exists as a tangible product that can be bought and sold. Exactly what files will be generated are defined by the Output Job file called by the current configuration. - Commit Release
In this stage, both the generated outputs and the snapshot of the design documents are stored as an atomic bundle within the Release Vault. The current design revision, lets say revision number 1.A.1, has been released and the system does not allow it to be released again – it’s not possible to accidentally overwrite revision 1.A.1 of an item with any other release.
Working with revisions and releases
Of course, it’s rare that you are finished with a design after a first or even second revision.
Once you return to design mode (from release mode) the revision state changes from ‘planned’ to ‘new from design’ – we have a new release with the current revision number. This is just one of the various states releases can go through. Releases can be viewed and managed via the Release Vault, where a release can be promoted from ‘new from design’ to a ‘prototype’ state – the next logical step in the product development process. Alternatively, it can be changed to an ‘abandoned’ state if things have gone pear shaped for one reason or another.
On the other hand if we discovered a bug in the design before we actually made the prototype, we’d plan a new revision instead of promoting the current one to prototype. Using ‘Establish Planned Revision’, a new design revision (in this case, 1.A.2) is created and can be developed accordingly. Assuming this has then successfully moved through the prototype stage, works correctly and has passed all the required tests, the next available release state is production – that is, it will be used for manufacturing.
The concept of an Item revision
where the state has been promoted from being ‘New’ (from design) to ‘In
Prototype’, and finally, ‘In Production’.
Let’s now say that the current model of the product we made from this revision is in some way no longer valid – it’s run its course, or it’s just time for an updated model of the product. So we need to plan a new release, for a new prototype, that we can build after we update the design.
To do that, we would establish a new planned prototype. Then assuming that the prototype works we move to production, and we then want to plan a new model of the item, we use ‘establish planned model’. This is similar to say, a car manufacturer having a new, updated model of a particular type of car. Note that we can also create a whole new planned item, say a variant of the product, which is given a new unique item ID and an edited version of the description and comment from the current item.
Just to recap, we have we have a three-tiered revision scheme here: Models, Prototypes and Revisions.
Data integrity that’s visible and accountable
To keep track of all the revisions and states, you can use the vaults panel and item release history.
Here, the entire history of revisions for the selected item is shown as a linear release timeline, allowing you to monitor how the revisions have progressed. The release documents and design snapshot can be browsed, providing a quick easy way to see which documents were used to generate that specific revision, the relevant bill of materials (BOM) information for a release is also available, and the outputs that have been generated from the release can be opened.
It’s all about having a
controlled and managed flow of design release data. Configurations are the
configurable link between the design and production domains, where automated
validations control the flow.
Using these concepts, storage locations and management tools, Altium Designer’s new design release process allows designs to be released to the outside world with high confidence in the integrity of the data. The process is easily repeatable, fully audited and traceable, yet sufficiently flexible for designs to be released in exactly the way you need.
The result is the implementation of a design data management model that allows a formal definition of the links between the design world and the supply chain that is ultimately responsible for building the actual products. It’s a model that maps the design data to specific revisions of production Items that the supply chain is actually going to build. It frees electronics designers to return to the core task of developing new and innovative ways to solve a problem or enrich the lives of the product’s users.
