PLM, how do you design modular?

In my previous column I showed a simple example of what a module actually is in a mechanical design. A module is determined by its interfaces. These interfaces are not the usual mechanical interfaces, but they are the specifications that modules of each other ‘ know ‘. 

This is because the purpose of interchangeability is not primarily to be able to swap a module in a finished product, but to be able to design and authenticate modules as independent units in the design.

To be developed separately, a module must be ‘ independent ‘ in the total composition. This independence depends on the correct definition of the interfaces. The interface of a module consists of a foreign and a public domain. The foreign domain of a module contains the specifications of other modules that need to be taken into account in the design. The public domain is that part of the module’s own specifications that can be ‘ known ‘ by the other modules in the composition. This means that the designer of the other module with these specifications may take into account the design of his own module. Modular design mainly means defining interfaces carefully, thus hiding the complexity of modules as well as possible. The condition for independence of a module (see previous column) is that:

For each  constraint that refers to its own specification of  that module, all  specifications of other modules to which that constraint refers are included in the foreign domain of block.

A constraint is a rule that restricts the allowed values for a variable, or for multiple variables in conjunction with each other. In the example of block and cylinder, there is a constraint that requires the diameter of cylinder to fit within a certain tolerance in the hole of block. If the diameter of the cylinder Is too large, it does not fit; If it is too small, the cylinder can vibrate when used. The designer of the ‘Block’ must therefore know that a cylinder with a certain diameter will be mounted in his hole. This must therefore be specified in the foreign domain of block (Figure 1). Vice versa, the foreign domain of the cylinder must contain the variables of the hole (Figure 2).

Now suppose the block designer starts while there is no cylinder model yet. How does he get to the specifications of his foreign domain? Very simple: he can specify his own foreign domain and in it define which characteristics of his environment he assumes to be able to design his block properly. He must ask himself what constraints determine the proper functioning of his block. Thus he enters the foreign domain as in Figure 1. From the point of view of the design of cylinder a similar story applies. The designer must specify all constraints whose proper operation depends on his cylinder as axle in some hole. In order to be able to specify those constraints, he must include all variables to which those constraints refer in his foreign domain.

If now, as the third design action, the composition of block and cylinder is specified, then it must be checked whether both modules are independent in that composition. To check the independence of block and cylinder in composition, we now compile a list of all constraints in the composition, block and cylinder, with per constraint the list of variables to be referenced. From that list, we select the constraints per module that contains their own variable of that module and verify that all referenced variables are listed in that module’s own or foreign domain. If the control succeeds, then the module is independent in the composition. For this check, we do not need to know the exact wording of the constraints.

The power of independent modules is that you can design and verify them without further knowledge of the intended environment. Remember, however, that independence in itself does not guarantee that a module cannot cause errors in the composition. Independence only guarantees that a module as a separate unit will be verified. Only when that verification is successful is it sure that the module in the composition will not cause any errors.

I expect that designing through independent modules will make the design of complex systems a lot easier and more predictable: after all modules have been verified and tested separately, there is nothing more to go wrong with the integration. I say ‘ actually ‘ because in a mechanical system constraints arise from the physical properties and effects of products. They are not always known beforehand. Think e.g. to temperature effects or vibrations. Nevertheless, most errors originate from constraints that are known, but not explicitly formulated. Such errors are detected by the independence check.

Next time I want to look at modular design of configurable products.