Parent article: Vault-Driven Electronics Design

Getting deep and dirty 'under the bonnet' of a design truly is an Engineer's playground. The fun of creating that next intelligent (and lucrative!) electronic product, the mastery of laying out the design on a PCB or testing, in real-time, the operation of an embedded design running in a physical FPGA device – but that's just the half of it. Once a design is considered ready for flight into the wider world, it needs to be released – a process that can often be underestimated.

Without a regimented and fundamentally-sound release process, tracking an ever-maturing product over time can be fraught with any number of pitfalls. Just imagine needing to go back and release a previous revision of your product, only to find that all required source design files were never included, as a snapshot, with that particular release! That's OK, just get the generated output files from the relevant folder(s) for that release – trusty Gerbers and any additional fabrication and assembly information, that's all that's really needed anyway. But imagine those 'trusty' outputs have been overwritten or become corrupt somehow. If only the release process were more robust.

Altium Designer answers this call by providing powerful, high-integrity board design release management, as part of Altium’s wider Design Data Management System. The board design release process is automated, enabling you to release your board design projects without the risks associated with manual release procedures. When a particular project is released, a snapshot of the design source is taken and archived along with any generated output. Release data are stored as revisions of a specific Item – the entity within a target Altium Vault, and which represents a tangible product that is made from that design project and sold by the company. This can be either a Blank Board (manufactured by the fabrication house), or an Assembled Board (the bare board populated with specified components, in accordance with a Bill of Materials).

The overall result is the highest-integrity board design release management possible. Not only is your actual design project tightly monitored, backed-up and managed in a version-controlled Design Repository, but also too, the releases of its configurations in a similar manner within the target Altium Vault – robust, safe, secure.

Key Benefits

• Integration with version control. If your project is under version control, then the system requires all files to be checked in and up to date before releasing. This 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. This simple rule can save hours down the track in costly searching for the right set of design documents that were used to generate a released product.

• Solid audit trail. Whenever a new revision of an Item is generated, during the release process Altium Designer records the version control repository address and revision of the project and commits this information to the vault. This method means that at any point in the future it is possible to retrieve an identical snapshot of all files in the design project from version control – a perfectly transparent audit trail from the latest released revision all the way back to the first checkin of the source design documents. Visibility. Accountability. Integrity.

• '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. In fact, a successful release results in committing (storing) the release data in the referenced Item Revision, then closes that revision. No further data can be generated and released into that same revision.

• Automated and repeatable design release process. One-touch releasing – no manual stages or risks. From taking the snapshot of the design files, through validation, output generation and final committal of the release data into the Item Revision in the target vault, there is no interaction. If a part of the process fails, the release fails. Simple as that.

• Ability to validate the design as an integral part of the design release process. The release process works from a 'locked down' snapshot of the design source (including dependencies) and pre-release validation is almost sure to have been performed prior to initiating release. But for additional peace of mind and to ensure the integrity of the design data, you can optionally add validation checks into the release process 'flow'. Standard ERC checking for the source schematics and DRC checking of the PCB, but also the ability to check that the source project and PCB are in-sync, and comparison of footprints on the board against their source library to ensure they are up-to-date, and matched. The release will fail if any validation checks are not passed successfully.

• 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 the data is to be used to build.

• Publishing, offering the ability to publish release data directly from a vault to a shared storage medium, such as Amazon S3, FTP servers, Box.net, or a simple network-based folder. This facilitates easy sharing of vault data in a secured way, without providing outside parties access to the vault.

PCB Project Configurations

Related article: PCB Project Configurations

So then, on the one side we have the design team, doing what they do best – creating innovative designs. On the other, we have the supply chain, taking data to build the end product – the physical embodiment of the captured design. But just how do we specify which Item is to be made from the design data? Providing a formal configuration structure, to map from source PCB project in a Design Repository to a specific Item in an Altium Vault, Altium Designer employs the concept of PCB Project Configurations.

Configurations are part of the actual design project and provide the link from the design world to the manufacturing world. Each configuration represents an Item that we want to build in the real world, defining the data that will be required by a manufacturing organization to actually build that Item. When we release a board design project, we are in fact releasing a configuration of that project. The generated 'release data' are stored in a revision of the target Item specified as part of that configuration.

Each unique configuration of a board design project maps to a unique Item in the vault referenced by that project. Each time we release a configuration, the data generated are stored as (and in) a new revision of the target Item – an Item Revision. Before we can release a configuration therefore, we must ensure that a new Item Revision is created ready to accept the release data, and that this revision is in the Planned state.

Board design projects are parametric in nature. But what does this actually mean, and how does it relate to configurations and the Items manufactured from those configurations? In other words, what makes a design parametric? The answer becomes evident if you think of a board design project as data that can be generated from it, and how those data are 'driven'. Data are generated using one or more Output Job files. The output generators in these files can, in turn, be driven through the use of Variants. By changing the variant used to drive (possibly different) Output Job files, we can create differing and unique configurations of a design. The variants and Output Job files are then, in essence, the variable 'parameters' of a design – the very entities that make a design parametric.

From an assembly perspective, the one board design project could have multiple variants defined that use the same fabricated bare board, but differ in the components used to populate that board, the result being distinctly different products when assembled. For example, consider the design for a communications board that provides mobile Internet functionality. From a 'superset' of components, two assembled variants of that design could be manufactured – one populated with components to offer 2G-based communication, the other to offer 3G. These are variants of the design, specified as such within the PCB project, and defined in terms of which components are fitted, or not. In fact any number of these 'assembled board variants' could be defined. From a fabrication perspective, we can also use variants to control changes in the silk screen for a bare board, giving rise to 'Fabrication variants' (of a sort).

The point to make here is that each variant, be it used to drive creation of a bare board or an assembled board, gives rise to the manufacture of a different, unique Item in its own right – and a unique Item requires that we create a unique configuration of that PCB design. It is the choice of variant that drives the generation of the outputs defined in underlying Output Job files. So, when we define a configuration, we not only map that configuration to a dedicated Item, but also:

• Assign the Output Job file(s) that will be used to generate the data when releasing that configuration.

• Specify which variant (if required) is to be used when driving those outputs.

Considering the mobile Internet communications design, we would define three configurations – one to target the fabricated bare board Item that is common to both assembled boards, and the other two to target the 2G and 3G assembled board Items. The BOM for each assembled board would include the fabricated board Item.

 
A configuration also provides the means to constrain the release process, through the ability to define validation-based output reports as part of an Output Job file assigned to it. These validations – ERC, DRC, checking that source schematic and PCB design documents are synchronized, and comparison of footprints on the board against their source library – ensure the validity of the data that are being sent to the manufacturing team.

The Board Design Release Process

Related article: PCB Release View

The release process itself is performed using Altium Designer's PCB Process Manager, the user-interface to which is provided courtesy of a dedicated view – the PCB Release view. This view presents a high-level 'Dashboard' that operates in two modes:

• Design Mode – for controlling and managing the Board-Level design process. Here you can run validations and generate outputs as needed, and in any order, 'testing the waters' as it were to ensure all is as it should be prior to initiating the actual release of the intended configuration.

• Release Mode – for initiating releases of PCB Project configurations. This is where the high-integrity release process is performed, taking the specified configuration of the design project and processing it to obtain the data required to physically produce the revision of the Item referenced by it.

With the PCB Release view in Release Mode, initiating the release is an automated affair, kicked off by pressing a single button. The process consists of several stages run in sequence – a process flow if you like. The following image illustrates the stages involved in the overall flow, which are discussed in more detail thereafter.

• Checkout Snapshot – a snapshot of the data, including dependencies, is checked out from the Design Repository.

• Validate Design – all defined validation output generators, defined in an Output Job file assigned to the configuration being released, are run. This includes running any of: Differences Report (using the comparator to determine if the source and PCB design documents are correctly in-sync); Electrical Rules Check (checking the electrical/drafting validity of the captured source design); Design Rules Check (checking the validity of the PCB document in relation to specified board-level design constraints); Footprint Comparison Report (comparing footprints on the board against their source library to ensure they are up-to-date, and matched).

• Generate Outputs – all other defined outputs in the assigned Output Job file(s) are run. These are the outputs that drive the release of the target Item, the instructions from which the physical Item will be produced to exist as a tangible product which can be bought and sold.

• Commit Release – pushing the generated outputs and validated design document snapshot into the defined new revision (planned revision) of the target Item, stored in the nominated vault.

All stages in the process flow must run successfully, otherwise the release will fail and no data will be committed to the new Item Revision in the vault. As the process is fully automated, the risk of errors associated with a manual release process are no longer a consideration. Full validation, full checking. The data set for use by the supply chain is exactly what it needs to be, to produce the product exactly as you designed it.

The whole concept of configuration release management provides the ability to identify the point in time at which any given configuration of the PCB design was released, go back to this point and retrieve, modify and re-release that configuration with the correct dependencies.

For a design project stored in a VCS-based Design Repository, during the release process Altium Designer records the version control repository address and revision of the project and commits this information to the target Altium Vault. This method means that at any point in the future it is possible to retrieve an identical snapshot of all files in the design project from version control.

Publication of Released Data

Related article: Publishing Destinations

For released data generated from a board design project, an Altium Vault supports the ability to publish those released documents – generated output from Output Job files assigned to the released project configuration – for any Item Revision, to a storage space, such as Amazon S3, FTP and Box.net. In terms of distribution and collaboration, this provides an unparalleled advantage in a world where the collective members of the overall 'product team' – the design team, the manufacturing team and all others involved in the process of getting a product from thought to reality – are often dispersed around the globe.

Publishing is simply a matter of defining a Publishing Destination and then uploading the released data for the required Item Revision to that destination. As part of the system you nominate, by specifying email addresses, whom to share access to the data with. From the manufacturing plant in China, to the design teams in Stuttgart, Adelaide and San Diego, and to the Project Director in-flight somewhere across the Pacific, everyone that needs to know about the new release will receive mail in their inbox with a link to the published folder – shared (and controlled) access to view, discuss and utilize the data with which to build the Item.