Share this page
Cross-product baselines
This topic provides an overview of baselines that can include design parts and items from different products.
About cross-product baselines
A cross-product baseline contains design parts and/or items that belong to two or more products.
Within the baselined design-structure USAGE relationships have been created (using the Relate Design Part Usage and/or Relate Item to Part function), and they have specified design parts and/or items in other products.
The product whose design structure or its part is being baselined, is called the baselining product, and all relevant items that don't belong to this product are called foreign items from foreign products.
To create a cross-product baseline, you need to define the item types of all relevant items, including foreign items, in the process model for the baselining product.
The remaining requirements and limitations concern the lifecycles associated with these item types, in the various process models for all products in the baseline.
A common case is where, for each item type taken in turn, that item type uses the same lifecycle in every process model. In this scenario, there are no further complications, and revisions of all relevant items, including foreign items, can be selected using the described procedures.
Lifecycles in cross-product baselines
It may be impracticable for different products to share identical lifecycles for the same item type.
When the lifecycle for an item type in a foreign product differs from the lifecycle for the same item type in the baselining product, examine the extent to which these two lifecycles need to be similar.
Identical normal lifecycles
The normal lifecycles in the two lifecycles can be identical. The same state names appear in the same order, and the lifecycles differ only in the number and/or arrangement of the lifecycle transitions that do not lie on the normal path.
In this case, there are no further issues for relevant items of that type in either product. For a baseline template, the two lifecycles function in an identical manner, because their normal lifecycles are the same.
Different normal lifecycles
The normal lifecycles for an item type can be different the baselining product and a foreign product.
Consider individually the alternatives for the template rule for that item type, starting with the simplest:
| Rule | Description |
|---|---|
| *ALL | This rule raises no problems, as it selects all revisions of a relevant item, regardless of their lifecycle states. This applies equally to foreign items. |
| *BUILT and *MADE OF | These rules raise no problems, as they are processed in an entirely different way, and are not directly concerned with normal lifecycles. The *BUILT and *MADE OF procedures are applied equally to relevant items of both the baselining and foreign products. |
| *LATEST |
This rule is handled in a special way, the effect of which is that the normal lifecycles for the baselining and foreign products do not need to correspond with each other. For a relevant item of the baselining product, the latest revision is selected from all at any of the states in the baselining product's normal lifecycle. For a foreign item, the latest revision is selected from all at any of the states in that foreign product's own normal lifecycle. |
| LFS rule with a specific state |
This is a more general version of *LATEST. The given specific state is looked up in the normal lifecycle for the baselining product. Suppose the normal lifecycle has six states and that the specified state is number 3 (the first state is number 1, and the final normal state is number 6). For a relevant item of the baselining product, the latest revision is selected from all those at any of the states whose numbers are 3, 4, 5 and 6. For a foreign item, you look up the foreign product's normal lifecycle for the names of the states which are number 3 (the same number as that of the specified state) or greater, and select the latest revision from those at any of these states. If this normal lifecycle has nine states instead of six, there are seven states from which a selection could be made (numbers 3 to 9 inclusive) instead of four in the baselining product. In an extreme case, if the normal lifecycle for a foreign product has only two states, there are no states from which to select, and so no revision can be selected for a foreign item of this item type in that product. Example: Specify LFS along with the state which is number 2 in the baselining product's normal lifecycle. Then the effect of this rule is that, for every relevant item of that item type in any product, the revision selected is the latest at any normal state, excluding those which had initial status. It guarantees that the selected revision had been actioned at least once after modification. |
| All other codes and implicit states *FINAL and *HIGHEST |
These rules require consistency between the normal lifecycles in the baselining product and a foreign product to select a revision of a foreign item. Only the baselining product's normal lifecycle is consulted, and the search (in order of preference) is performed on all relevant items of that type (for example, associated with that normal lifecycle), including foreign items, using the state names in the baselining product's normal lifecycle. Example: If the rule specified *FINAL, and the final normal state in the baselining product's lifecycle was DONE, then DONE would at least have to appear somewhere in the corresponding lifecycle for the foreign product, and the foreign item's revision selected would be the latest (if any) which had DONE status, regardless of what DONE actually meant in the foreign product's lifecycle. If any of these codes are to be used, you need to ensure sufficient agreement among the normal lifecycles for all the involved products, as to the meaning of most state names, if not all. This ensures that the selected revision of a foreign item is the one actually desired. |
See also:
