Language
Contents
The tangible object that is made from a design project and sold by a company is manufactured from a specific set of data, generated from source design files. The data used for manufacturing can be thought of as the set of instructions used to build that object. This data includes the fabrication files (Gerbers, NC Drill files, etc) and assembly files (BOM, Pick and Place, etc) needed to make the blank board and then the assembled board. But how to uniquely identify this set of instructions, firstly so that the production team can be assured that they are making the right blank board, and then the separate set of instructions needed to make the right assembled board? The answer is the Item.
What Exactly are Items and Revisions?
An Item simply represents a specific object that gets built, and is uniquely identified by its Item identifier (ID). A design project can be the source of multiple bare or assembled boards. Each of the distinct physical objects that is built is represented in the system as a different Item, each with its own unique Item ID.
Now over time the design may need to change – a mistake is found, a part becomes obsolete. On the design side, incremental changes to the source design are stored as separate versions of that design, typically using a version control system. Once the changes are complete, a new set of those manufacturing instructions needs to be generated, or released. So how do we identify between different releases of the same design, and more importantly the different data sets generated? The answer is a revision identifier (ID), which in combination with the Item ID creates a unique identifier for each release of an Item. This gives us the Item-Revision.
An Item-Revision simply identifies which revision of an Item is to be built. There will always be at least one revision of an Item (the first release), but there could be many, depending on how many times that design is released. An important point to make here is that you can only release to a particular Item-Revision once, if there is a change then a new Item-Revision must be created. This ensures the highest integrity, as the data set to manufacture a given revision can never be overwritten by re-releasing to the same revision. To release again, a new Item-Revision must be used.
The simplest way to grasp the concept of an Item and its revisions is to think of a 'box', into which all the data (instructions) required to build that particular revision of that particular Item, are stored. When the Item is released the data is put into the box, and the box is closed. The Item ID and the Item-Revision ID become labels on the side of that box – they allow instant recognition of what the contents of the box is used for. If the design needs to be updated and re-released then the Revision ID is incremented, creating a new box.
The act of releasing closes the box and sets its Lifecycle state to New From Design.
 | To ensure that there is no ambiguity about the generated release data, each output file is prefixed with the Item ID and Revision ID, in the format |
So far this discussion about Items has only talked about how they are used to manage the production and release of blank and assembled boards, but Items are also used to identify all of the design elements that need to be created and used during the overall electronic product development design process. This includes the components that get loaded onto the board, as well as your company's re-usable design content, such as templates and managed sheets. Each of these types of Items also uses the Item-Revision concept to manage the creation, release and usage of that content.
used in the design and manufacture of an electronic product.
The Lifecycle of an Item-Revision
Main article: Item Lifecycle Management
Another important aspect of an Item-Revision is its Lifecycle state. This is another identifier that the production team can use to quickly assess what stage that revision has currently reached in its manufacturing life, and what they are therefore authorized to do with it. Where the Revision reflects design changes made to the Item, the Lifecycle state reflects the state of the item from a business perspective, such as Planned, New From Design, For Production, Obsolete and so on.
Initially, the Item-Revision will be in the Planned state – ready to receive (and store) the data generated by the design release process. Once the release process is complete, that revision is closed (the design cannot be released to that same revision again), and the Lifecycle State is set to New From Design. While the data for this Item-Revision can not be modified, the Lifecycle state can be changed to reflect just where the Item-Revision is in terms of its design-produce-ship-sell-obsolescence life.
Altium Designer provides different types of Lifecycle management – from basic management, through simple management including states and state transitions, to fully structured management, where the states and state transitions are organized into distinct stages, with a link between those stages and the Revision ID. Based on these different Lifecycle management strategies, a number of standard Lifecycle definitions are defined, from which you can choose to model the state transitions that an Item-Revision may undergo over time. There are also definitions that include 'Approval' type states and transitions – where user-defined specific authorities are required to increment to a given Lifecycle state.
For all default definitions (other than Basic), after release the Item-Revision automatically changes from the Planned state to the New From Design state, as shown in the previous image.
An Item-Revision's life-cycle is managed manually, and in accordance with company policies and practices. Once a design is complete and the development team are happy with the design, the Lifecycle state would be elevated to the In Prototype state and, all being well with the subsequently-manufactured prototype, would then proceed to the In Production state. At a later date another revision of the same Item might be needed (another box!) to introduce better functionality. Once released this second Item-Revision would progress through prototyping to production, while the Lifecycle of the previous Item-Revision passes through deprecation and finally to obsolescence. The point is that the life-cycle information shows how the contents of the 'Item-Revision box' can, or rather are, being used.
authorized to go for prototype and onto production, but subsequently
became deprecated and is now obsolete.
Creating an Item
Related article: Altium Vaults
Items are created in an Altium Vault – and all of the generated data needed to manufacture that Item is then stored in that vault, against that Item number.
An Altium Vault is designed to store 3 distinct types of data:
- Components – both the domain models (schematic symbols, footprints, etc) and the vault components that use those models.
- Managed Design Content – includes managed schematics (previously referred to as Device Sheets) and templates.
- Released Designs – completed designs that are ready to move from design to manufacture. This includes both bare boards and assembled boards.
The Items themselves are created directly within the vault. Items can be created manually (they must be for board and managed content types of Items), or they can be created automatically as part of the release process for components and their domain models. Vault management and Item creation is done via the Vault Explorer panel. Items are organized in the vault in a tree-like structure of folders, much like the tree of folders used on a PC to organize files. To add a folder into a vault, right-click in the Vault Folders region of the Vaults panel.
Once you have defined the required folders, you can proceed to create Items in the vault. To create an Item, select the appropriate folder and then right-click in the Item region of the panel and select Create Item from the floating menu. The sub-menu that appears will have different options, depending on the type of Item you are adding – choose the appropriate menu entry.
Choosing an Item Naming Scheme
There is an infinite number of possible name/numbering schemes that can be used for Items, the ones shown in these images are just examples. There are numerous discussions you can read about what is the best numbering scheme to use. Generally, the experts agree that a short, non-significant, numeric-only numbering scheme is best. Non-significant means that there is no information encoded into the numbering scheme, such as the product category, sub-category, location, etc, each new Item is simply issued the next number in the sequence.
The length is important because the longer the identifier, the greater the chance of a human making an error when they record or recall the Item ID. Experience and academic study have shown that that data entry errors increase as the number of characters increase. Seven digits is believed to be the magic number in terms of being easily and reliably recalled by a human. Beyond a certain length errors increase at an increasing rate – at 15 characters, the error probability is close to 100%.
If it is important in your organization to create identity in the Item ID, then a composite identifier could be the answer. In this case a simple alpha/numeric commodity prefix code is recommended, such as the one shown in the images on this page. Here the D in the code could denote Design, meaning this is an Item used for designs. In the next 3 digits, the first digit could denote the product category, such as Peripheral Boards, the second and third digits in the block of three could be used to denote bare boards (1X) or assemblies (2X and up). The final four digits in the Item ID are a simple, non-significant, next-in-the-queue type number.
The Create Item dialog will appear, providing all controls necessary to fully define the Item.
The following fields collectively define an Item:
- Item ID – the unique ID for this Item. The ID itself is typically a code, in accordance with established naming conventions. For example
D-810-XXXXis used at Altium to reflect a fabricated Blank Board Item, whileD-820-XXXXreflects an Assembled Board Item. The Item ID can not be changed after the Item is released.
- Content Type – This is the type of this Item (see next section).
- Revision Naming Scheme – this field determines the scheme employed when assigning Revision IDs. Use the drop-down to choose from the schemes currently defined for the vault. Schemes themselves are defined in the Edit Revision Naming Schemes dialog, which can be accessed by clicking the
button at the right of the field. As schemes are chosen at the Item-level, you are free to have different schemes applied to different Items. The chosen Revision Naming Scheme can not be changed after the Item is released.
- Revision ID – the revision of the Item, in accordance with the chosen revision naming scheme. This field is read-only.
- Lifecycle Definition – this field determines which Lifecycle definition is used to model the state transitions that an Item-Revision may undergo over time. Use the drop-down to choose from the definitions currently defined for the vault. The definitions themselves are defined in the Edit Lifecycle Definitions dialog, which can be accessed by clicking the button at the right of the field. As Lifecycle definitions are chosen at the Item-level, you are free to have different definitions applied to different Items. The chosen Lifecycle definition can not be changed after the Item is released.
- Revision State – the state of the revision of this Item specified in the Revision ID field. This field is read-only and for a newly created Item will always be set to
Planned.
- Comment – use this field to enter any further comments regarding this Item.
- Description – use this field to enter a meaningful description of what is represented by this Item.
- Folder – the vault folder in which this item is stored.
- Ancestor Revision – the preceding revision from which this Item is created/branched.
The Item Type
Different Items are used to store and represent different types of data. One Item could represent a schematic symbol, another a PCB component model, while another could contain the generated data from a released board design configuration, along with source design snapshot. To declare the type of content an Item (or rather its revisions) will be used to contain, its Content Type property needs to be specified when creating or editing that Item. To put this another way, you are in essence specifying the Item Type.
The following table summarizes the different Item types that are supported.
Content Type | Code | Description | Content Generated By... |
|---|---|---|---|
|
| Component | releasing a component definition (in a |
|
| Embedded Software Design Project | releasing a source Embedded Software design project ( |
|
| FPGA Design Project | releasing a source FPGA design project ( |
|
| OpenBus Document | releasing an OpenBus System document ( |
|
| Part Choice List | adding Part Choices to a Component Item. |
|
| PCB 3D Model | releasing a PCB 3D Model, defined in a PCB 3D Model Library ( |
|
| Structured BOM and PCB Assembly Data Set | releasing an |
|
| Blank PCB Fabrication Data Set | releasing a |
|
| PCB Component Model | releasing a PCB 2D/3D component model, defined in a PCB Library file ( |
|
| PCB Design Project | releasing a source PCB design project ( |
|
| PCB Design File | releasing a PCB design document ( |
|
| Schematic Sheet | releasing a schematic sheet, or 'tree' of sheets ( |
|
| Signal Integrity Model | releasing a signal integrity model, defined in a Signal Integrity Model file ( |
|
| Simulation Model | releasing a simulation model, defined in a Simulation Model file ( |
|
| Schematic Symbol | releasing a schematic symbol, defined in a Schematic Library file ( |
|
| XApp Design Package |
|
|
| Web Content Item |
|
|
| Web Resource File |
|
|
| XApp Design Project |
|
|
| XApp Deployment Data Set |
|
Item-Revision Naming Schemes
Main article: Item Revision Naming Schemes
To provide the greatest level of flexibility, Altium Designer comes with a number of pre-defined Revision Naming Schemes, and also supports user-defined Naming Schemes. The Revision Naming Scheme is specified at the vault level and then automatically applied when an Item is created, but can be locally overridden for an Item if required. To specify the Naming Scheme for the vault open the Data Management – Vaults page of the Preferences dialog, select the vault and click the Properties button, then select Edit Revision Naming Schemes from the drop-down menu. The Edit Revision Naming Schemes dialog will appear.
Four default naming schemes are available:
- 1-Level Revision Scheme – with this scheme, a Revision ID will consist of one level only (e.g.
1).
- 2-Level Revision Scheme – with this scheme, a Revision ID will consist of two distinct levels (e.g.
A.1).
- 3-Level Revision Scheme – with this scheme, a Revision ID will consist of three distinct levels (e.g.
01.A.1).
- Component Revision Scheme – with this scheme, a Revision ID will consist of two distinct levels (e.g.
A.1).
| The revision naming scheme applied is chosen at the individual Item level, when creating an Item. Different Items can therefore have different revision naming schemes assigned to them. |
 | Once a defined Revision Naming Scheme is in use by an Item in the vault, that scheme can no longer be edited, nor can it be deleted. Conversely, once an Item is created and an initial release into a planned revision of that Item is made, that Item can not have its Revision Naming Scheme changed. |
Item-Revision Lifecycle Definitions
Main article: Item Lifecycle Management
Like the Revision Naming Scheme, a default Lifecycle definition is applied at the vault level. This can then be overridden when an Item is created, if required. To examine of edit the Lifecycle definition being used for a vault, open the Data Management - Vaults page of the Preferences dialog, select the vault and click the Properties button, then select Edit Lifecycle Definitions from the drop-down menu. The Edit Lifecycle Definitions dialog will appear.
There are six default Lifecycle definitions available:
Basic LifecycleComponent LifecycleSimple LifecycleSimple Lifecycle With ApprovalsStructured LifecycleStructured Lifecycle With Approvals.
| Once a defined Lifecycle Definition is in use by an Item in the vault, that definition can no longer be edited, nor can it be deleted. Conversely, once an Item is created and an initial release into a planned revision of that Item is made, that Item can not have its Lifecycle Definition changed. |
Reviewing and Managing the Revision and Lifecycle State
Main article: Managing the Item's Revision and Lifecycle State - the Item View
For a detailed view of the Revision and Lifecycle history of an Item, right click on the Item in the Vaults panel and select Full Item Details from the menu. The Item view will open, as shown below.
The detail that is presented in the Item view will depend on the type of Item being examined. For example, for an assembled board Item the view presents a list of released documents, the snapshot of the design project used to generate the release and the generated Bill of Materials (BOM) that will be used to physically manufacture that board.
The Item view displays a column for each major Revision. Each column then displays the Lifecycle state changes for that Revision. Right-click on a Lifecycle state cell to:
- Establish a new Planned Revision of the Item, in accordance with the Revision Naming Scheme selected for that Item.
- Manage the Lifecycle state for a particular revision of the Item, in accordance with the Lifecycle definition selected for that Item.
- View Revision properties.
- Retrieve documents associated with each revision of the Item.
- Publish release data directly to a nominated publishing destination (for Blank Board and Assembled Board Items only).
The BOM detail comes from a System BOM that is generated automatically as part of the released process.
Labels