PLM, how to configure modularly?

The beauty of complex products is that they can fulfill the most sophisticated combinations of functions, but the annoying thing is that everything is related to everything, so that a change in one function can cause an undesirable effect, say an error, in another , even if both functions are functionally unrelated to each other. 

A comprehensive system test is the means to detect such errors in a timely manner. However, if it is a configure-to-order product, where the number of variants is many times greater than the total lifecycle production volume, testing of all possible variants is not an option. How do you avoid mistakes in previously produced variants?

The answer is modular design. Because now you have some of the feature of modules that you can test them separately from the integral product.  If the tested module is independent in the total product, variants can be verified per module. Independence is easy to demonstrate using module interfaces in relation to the constraints that apply in the design. 

I fall back on the now familiar example of BLok and cylinder. For the readers who do not have the previous song directly at hand, I copy figure 1 and 2 again. I want to start looking at the composition of both as a configurable product. In block are length, height, width and hole-diameter as variables specified. Of cylinder are that length and diameter. Thus, block and cylinder are product families: each combination of choices for each of the variables provides a Variant.  The composition Sam of block and cylinder is specified by the parts and their relative position. Those are chosen so that the origins of Sam, block and cylinder coincide (center of gravity left), so that the axes of the hole and cylinder coincide with the x-axis. This defines Sam as a configurable product. 

I’m going to show you how the modular design helps to derive the necessary rules for the Configurator. In the preceding episodes it has already been demonstrated that block and cylinder are independent. This allows us to check per module for each parameter choice if all constraints are met.  There are two constraints in which variables play a role:

C2: The difference between the diameters of  Gat and  Cilinder  lies  between 1% and 2% of the holediameter,
C3: None of the tips of cylinder  is located in  BLok.

One wants to offer the customer a limited choice of the possible values for the different variables and thus set up a product configurator. Now suppose that one decides to start producing block in 24 variants with the choices:

b: ‘3, 5, 7’, h: ‘4, 6’, ‘l: ‘5, 10’ in d: ‘1, ‘2’.

For cylinder one chooses for 8 variants with the choices:

d: ‘0.995, ‘1,990’ in l: ‘6, 8, 12, 15’.

What choices now cause conflicts with constraints?  We do the check per module and start with cylinder, because it is the simplest. C2 and C3 are both visible in the own and/or foreign domain of cylinder. C2 imposes restrictions on the combination of hole and shaft diameters. This closes block. D: {1} and cylinder. D: {1.990} each other out, as well as block. D: {2} and cylinder. D: {0.990}. C3 says something about the lengths of block and cylinder and makes that block. L: {10} and cylinder. L: {6, 8} are incompatible. All other cylinder variants respect the constraints and are therefore good. Analysis from module block does not provide new rules, because C2 and C3 are the only constraints for block. Further testing is no longer necessary, assuming the constraints are fully specified.

Now what if something needs to be changed? Block height and width are not visible to cylinder and can therefore be freely chosen. Adding a variant with e.g. block. B = 4 can not give any problems. When changing the length, we will touch an interface, so possible constraints. If we add e.g. for block length 11, then in C3 we hit the strange domain of cylinder and a control is needed. Combination with cylinder. L: {6, 8} indicates a conflict so a new configuration rule must be added.

To a super simple example, I have now shown how independent modules simplify the design of configurable products. Because of its simplicity, the role of constraints, interfaces and independence may seem obvious, but in a realistic complex design they are certainly not. By carefully specifying constraints and choosing interfaces so that the modules are independent, the configuration rules can be easily inferred and variants can be verified per module. Tests at the system level are no longer necessary and that is good as well, because with an increasing number of variants this is quickly becoming impossible.