Working with the Detailed Item View_AD
Parent page: Vault Items
An Altium Vault can store a broad variety of data, including: components (and their models); managed content (such as templates and managed sheets); and the output fileset from you released board designs. Each component, template or released output fileset is stored in the vault as an Item.
As well as storing different types of data, the vault also stores the complete history of that data. It does that using the concept of Revisions - each time the original design data requires a releasable design update, it is re-released (uploaded/comitted) into the vault as a new revision of that Item. Revisioning ensures that you have complete traceability of all of your data throughout its life, as well as access to any revision - essential when an existing product must continue to use an older revision of an Item. To ensure the correct revision is being used, each Item is always identified as an Item-Revision.
As well as being revisioned, each Item-Revision also has a Lifecycle State. The Lifecycle State reflects the 'readiness' of the Item-Revision for use, for example it could be In Design, For Prototype, or For Production.
Management of the revisions of an Item, and the lifecycle states of those revisions, can be performed from the following two places within Altium Designer:
- A dedicated Item view.
- The Lifecycle aspect view for the selected Item in the Vaults panel.
This document takes a closer look at using the Item view.
Accessing the Item View
The Item view provides a highly detailed view of the revision and lifecycle history of a specific Item, as well as showing all of the elements that make up that Item. The Item view is also where you can manage and increment the revisions and their lifecycle states.
To access the Item view, locate the required Item in the Vaults panel, right-click on it, and select Full Item History from the context menu.
Graphical Elements of the View
While the graphical elements in the Item view might initially seem confusing, it's functionality is straightforward. It is important to point out that the set of graphical elements used for a specific Item actually depends on the Revision Naming Scheme and Lifecycle Definition employed for that Item. That said, the overall behavior of the Item view is consistent regardless of the Scheme and Definition chosen, a more detailed Revision Naming Scheme or Lifecycle Definition simply adds more detail into the view.
Since the detail and arrangement of the graphical display presented in the Item view is directly related to the chosen Revision Naming Scheme and Lifecycle Definition, the following discussion and images center around a 3-Level Revision Scheme and a Structured Lifecycle with Approvals.
Connection with the Revision Naming Scheme
Related page: Item Revision Naming Schemes
The Item shown in the previous image uses a 3-level Revision Naming Scheme. Each revision of that Item has a dark grey caption, for example Rev. 02.A.1. The cluster of cells below the revision caption shows the different lifecycle states that that revision has been through.
The image below shows the relationship between the chosen Revision Naming Scheme and how those revisions are presented in the Item view.
Consider the revision 02.A.1 in the image. Breaking down this 3-Level Naming Scheme, you can see:
- Model 02 - the top-most entity, corresponding to Level 2 of the Revision Naming Scheme. The 02 signifies that this is the second model of this Item.
- Prototype 02.A - corresponding to Level 1 of the Revision Naming Scheme. The A signifies this as being the first prototype of this second model of the Item.
- Rev. 02.A.1 - corresponding to the Base level of the Revision Naming Scheme. The 1 signifies this as being the first revision of this first prototype, of the second model of the Item.
The ability to define the number of levels and the detail of the naming scheme ensures you can select a scheme that best reflects the needs of your organization. In this example the Model is used to identify the model of the project that is ultimately sold. To use Samsung® as an example, think of the Galaxy® S6, followed by the Galaxy® S7. A new Model would only be released when there were significant feature changes made to the product.
At the next level down, a new Prototype would indicate that design changes were needed, perhaps to resolve a technical issue in a released Model.
A change at the lowest level, the Revision level, indicates that a minor design change was needed. Changes at this level would typically happen when that Model of the product is still in development, before it makes it into Prototype.
The 2-Dimensional Nature of the Item View
The Item view presents revisions of an Item graphically, but can only do so in a 2-dimensional way. The way it handles this depends on the Revision Naming Scheme employed for the parent Item:
- 1-Level Revision Scheme employed - in this case there are only Revisions (no Prototypes or Models), so all releases will appear in a single column.
- 2-Level Revision Naming Scheme employed - all revisions of a specific major release will appear in a single column. Each new major release is presented in the horizontal direction, starting a new column in the view.
- 3-Level Revision Naming Scheme employed - all revisions of a specific Prototype are in a single column. Each new Prototype then starts a new column, but still under the same highest level Model heading. Each new Model starts a completely separate column in the view.
If multiple entities are available below a particular level, you can essentially 'roll-up' the view to show only the latest entity at that level, by clicking the control in the applicable cell.
Changing the Revision or Lifecycle State
Both the revisions of an Item, and lifecycle state of an Item Revision, can be incremented in the Item view, using the right-click menu. The menu entries for lifecycle-type changes are toward the middle of the menu, as shown in the image below. The options available (including the displayed menu text), are determined by the valid transitions defined for the current lifecycle state of the revision. The menu entries for revision-type changes always appear at the bottom of the right-click menu.
While establishing a new revision, or promoting the lifecycle state of an existing revision, are completely separate tasks that are done for different reasons (a new revision when there is a design change, a new lifecycle state to reflect the enhanced usability of that Item Revision), they are inter-related, so it is worth discussing them together.
Just how are they interrelated, you ask? When a revision of an Item is to move from one lifecycle state to another state, this process is called a Transition. Allowed transitions are defined as part of each state definition, defining the target state that a given transition can move to. When you right-click on a cell in the Item view to perform a lifecycle state change, it is the allowed transitions that appear as available menu entries.
The lifecycle states can also be clustered into Stages. If they are, then the stages can be linked to the revision levels of the revision naming scheme using the option at the bottom of the Edit Lifecycle Definitions dialog. This creates a relationship between the lifecycle state and the revision level. What that means is when an Item Revision's lifecycle is incremented so that it moves from a lifecycle state in one stage to a lifecycle state in the next stage, then the available revision modification type commands will change too.
For example, when the Item Revision was New From Design, then the revision-type options include: establish a new Revision; a new Prototype; or a new Model. If the lifecycle is then incremented to the point where it is now In Prototype, it will have moved to the second stage. Right-clicking on it now, the available revision-type options now include: establish a new Prototype; or a new Model, that is, there is no option to start a new revision. This behavior is what you would intuitively expect - if the design has progressed to Prototype, then if a design change was needed you would expect to have to release a new Prototype, or even a new Model, depending on the scope of that change.
The Item View Timeline
The Item view includes a Timeline. Use the Timeline to examine the exact time and date of any change made to the revision level of the Item, as well as any changes to the lifecycle state of its revisions. The Timeline also lists the user who made each change, as well as any pertinent notes (made upon releasing into a new revision, or changing the lifecycle state of an existing revision).
To simplify the task of interpreting the Timeline, when you click on an entry in the Timeline, that cell is highlighted in the main graphical region of the Item view, and all following Revision/Lifecycle changes are temporarily grayed out.
The Timeline also includes a menu button . Use this to limit the amount of data shown in the Item view, as shown in the animation below. This could be useful if there are a large number of releases, and revision state changes for a particular Item.
Accessing Item Revision Data
Depending on the type of Item, you may be able to see a graphical depiction of the data stored in the currently selected revision of that Item (e.g. for a Symbol Item, or Footprint Item), or be able to open, or download, a document that is stored in that revision (e.g. a Binary File Item, or the documents in a released PCB Fabrication Data Item, or PCB Assembly Data Item).
Where such functionality is supported, look to the right-click context menu for the applicable region in the Item view. If an entry appears as a hyperlink, you will typically be able to follow that link (perhaps to an external web page - for example a component datasheet).
The following image illustrates the data stored in the revisions of three different Item types, and presented through the Item view.
Bill Of Materials
When releasing a board design, and generating a PCB Fabrication Data Item, PCB Assembly Data Item, or PCB Project Design Item, the Item view also presents the System BOM. This is a separate BOM, generated at release time and stored in the vault as an XML document - not to be confused with the user-defined BOM which is driven from the Output Job Files in the project.
Publishing Released Data
Related page: Sharing Released Data through Publishing Destinations
From within the Item view, you have the ability to publish released documents for any Item Revision (PCB Fabrication Data Item, PCB Assembly Data Item, PCB Project Design Item), to any hosted storage space defined within your Publishing Destinations preferences. Currently supported hosting destinations include Box.com, Amazon S3, an FTP server, or a simple folder location on a shared network. 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.
To publish, simply select the specific revision of the Item you wish to publish documents for. Publishing commands are available from the right-click menu for the Released Documents region.
The publishing sub-menus list all available Publishing Destinations, by name, as defined on the Data Management - Publishing Destinations page of the Preferences dialog. Choose a destination and use the subsequent Publish to dialog to define the required destination sub-folder in which to store the data.