I recently gave a presentation titled “Essentials of Rational Engineering Lifecycle Manager”. During the talk, my co-presenter (the wizard) Andy Lapping mentioned that a better title for Rational Engineering Lifecycle Manager would be Rational Information Lifecycle Manager since the tool is not only for engineers but anyone who wants an easily consumable view of their linked information. The key benefit of the tool is that it indexes disparate data that is spread around the company so that you can easily visualize, organize, and analyze the data.

 

One of the most important new features of this tool is called a product configuration. A product configuration allows you to insulate changes you make in a product hierarchy in a couple of different ways, and then check-in the changes for reuse in other product configurations. You can link the products you structure in the hierarchy to artifacts in other tools, so you can group and reuse the same set of artifacts in other products.

 

One way to use a product configuration for insulation of changes is to structure a product hierarchy with a child product configuration. The child product configuration can play the dual role of product and product configuration. As a product configuration, it determines and tracks the versions of the products below it in the hierarchy and insulates the version information from the higher-level product configuration. As a product, it fills a slot for a subsystem or component while determining and managing the products below it. It can be reused in other products and if you need to find out what products are using it, you can do a “find use” command. In the illustration below, the Cabin product configuration is a product and a product configuration so only it knows the versions of the rear seats and front seats. It insulates that version information of the rear seats and front seats from the higher-level Car product configuration so when the versions change, that version information is insulated.

 

 

Another way to use the product configuration feature is to manage a separate development effort for a particular type of subsystem or component. You can create a product configuration for Transmissions where various different types of transmissions used in different models of cars are developed. If you create a variant of a transmission, the new product variant will be available for reuse in other configurations when it is checked in. In the example below, the new variant of the 2WTran-4 with a dimension value of Model=Eco will be available for reuse upon check in. It will be selected for use in a Car product configuration with the dimension and value of Model=Eco. The new variant is insulated when it is checked out as shown in yellow, and available for reuse in other product configurations when it is checked in. The variant will automatically be selected for reuse in product configurations where the dimension value pairs match.

 

So how does a product configuration determine the child products to include in the hierarchy?  Dimension value pairs are used for this purpose. When a product variant is created, the dimension values assigned to the variant make it distinguishable. A product configuration has a dimension value pair and it looks for child products that most closely match its own dimension value pairs. Another alternative you have in defining product hierarchy is to pin a particular variant in the hierarchy - this will prevent the parent product configuration from overriding it with another product.

 

These are just some of the potential ways to define products for reuse in Rational Engineering (or information) Lifecycle Manager. Most likely, there will be other ideas that emerge from our customers for using product configurations creatively. Do you have any ideas for reusing a product configuration?  

 

Joanne Scouler,
Curriculum Architect, Continuous Engineering Education