PLM: Different models of the same product.

There is still discussion going on as to whether there should be a distinction between an engineering model and a manufacturing model. With configurable products it becomes even worse, because we design product families. 

In a parametric design, variables occur whose value must be within a certain range. Of course we want to save such a parametric model. So it will have to be given a unique number and a recognizable name.  Each time a specific choice is made for the parameter values, with the intent to produce that variant, that model will also have to be given a number and a name. In order for each variant, especially if there are billions of possibilities, to invent a separate name, even for the most creative constructor is too much to ask, so we choose to use the same name for all those variants. If at any given moment 1000 variants are made, then we do not have two or three different models of the same product, but about thousands. If you happen to be using the same variant twice, should we use the same number for both? In that case, we will have to check for each variant requested if it’s already been made. And what if there is a new version in the meantime? This requires some systematisation.

To begin with, it is useful to define some terminology. So far we call everything product (many PLM systems use the term ‘ part ‘). From specific to generic we name:

• Product  specimen: A specific, single, produced or to be produced product or component, that can be touched, sold and used (also known as a serial number),
• Product Type: specified by a product model, in such a way that two product specimens, produced in accordance with this model, are equivalent to the user,
• Product Family: A class of  product variants, the model of which contains one or more parameters, each with a specific range of values. Each choice for parameter values defines a product variant, where a product variant can be both a type and a family.

The funny thing about this terminology is that only a product copy can distinguish the product from its model. In product type or product family, there is only the model, so that product and model are synonymous. 

Now suppose we get the assignment to design a block with a hole (you can find a sketch in my-previous column) that has to position a rotatable axle in a certain environment. Especially if the design involves challenges, one will start with a parametric model. In every case, a block has a height, length and width. The hole for the axle will have a position and a diameter. In addition, there will have to be holes, each with a position and diameter, to fix the block in the intended environment. In order to save weight, some material can still be removed here and there. This provides some additional parameterized features. The requirements for the block can be used to determine the possible value ranges for the different parameters.

The designer will spend some time on it and also write down a lot of dependencies between parameters in constraints. He will also want to discuss his model with others. It will therefore have to be stored in the PLM system. There it gets a number and the name ‘Block’. During the development of the model, versions of course are tracked. Since the model still contains a number of variables, there is a product family.

Now it appears that there are two environments that vary greatly in load on the shaft. Therefore, it is decided to design two variants of the model and each to work out separately. These variants are given the name of ‘Heavy block’ and ‘Light block’. Both variants are in themselves product families again, because they still have open variables.

Now there is an order for a product in which the ‘Heavy block’ is to be applied. A variant of a ‘Heavy blok’ must therefore be designed and the intended model will be a product type. The model of the ‘Heavy-block’ family is copied under a new number, as the initial model of the intended ‘Heavy block’ type. A number of parameter choices clearly follow the requirements of the order. The remainder must be optimised in consultation with the designer(s) of the order. If this optimization is a simple linear process, the definitive choice arises from a number of successive versions, the final of which is the product type.  In this case, however, they see three solution directions, which they all want to develop and compare in order to choose the best solution. Therefore they create three variants, which have the same model initially, but which, in order to avoid misunderstandings in the design discussions, get a different name: ‘Heavy block-A’, ‘Heavy block-B’ and ‘Heavy block-C’. The finally chosen variant is elaborated in detail, with a definitive value given to the remaining parameters, and it is released as a product type.

This scenario illustrates how the complexity of the many models can be structured around one product. If you have objections or questions about my approach, then I am open to discussion. If your company has a similar problem, but a much more convenient solution then I would also like to hear that.