PLM: How to rate modularity?
Last time I discussed what modular design entails: specifying interfaces. The purpose of a module is to be interchangeable: to be able toreplace it with a variant, without first having to test whether it fits. This property is essential in order to work with a product configurator.
However, interchangeability is not self-evident: a module must be independent, in the sense that you have to be able to design it with only limited knowledge of the total product in which it fits. The more knowledge is needed, the more complex, and therefore more expensive, the design becomes. What’s even worse: the maintenance of the module in the future is also more expensive. Independence is therefore an important prerequisite for limiting design and maintenance cost in a modular design. The previous column ended with the bold assertion (I improved the wording slightly):
A module is independent if all rules that refer to an object in its own domain and to one or more other objects, all the other objects referenced are elements of its own or foreign domain.
In this case the own domain (see the picture below) is the actual specification of the module and the foreign domain the specification of the required knowledge of the environment. A rule is a statement that establishes a link between the properties of two or more geometrical objects. In each design there are such rules. The most villain are rules that establish connections between different modules. The risk is high that a change in one module, through such a rule, causes a conflict with the other module. If the two are then applied together in a configuration, an error can occur because the design is inconsistent with the rule. Such errors will come to light during production or during operation and are therefore relatively very expensive. If a module is independent, you can make any arbitrary change to its specification without risk of causing problems in other modules. Indeed you can design and modify the module without using knowledge of the rest of the system, except for the foreign domain of the module. Demanding and controlling module independence in the review process of a modular product, May yield massive costs reduction!
Independence can also be described as the requirement that all rules that may cause a conflict with another module are specified in the module interface. If verification shows that a module is not independent, then either the interface should be expanded, or the design should be adjusted so that the module no longer depends on the rule.. Independence therefore comes down to the careful management of interfaces. And there is a problem: in the current design practice interfaces are not managed at all. To begin with, only those rules that define parametric links between objects within the module are specified. The engineering model only specifies what is necessary to maufactue the module to be used and knowledge of interfaces is not necessary. So why specify an interface?
The first condition for good modular design is that with each module the foreign domain is explicitly documented. As such that is not so difficult, since all objects are already specified in the other modules. So you only have to specify the necessary references. Furthermore, all rules must be explicitly stated. That is more difficult, because often there are some of which you are not immediately aware off.
The second condition is that the review process will include the explicit checking of independence. Nevertheless, an error may occur. It may happen that someone forgot to specify a rule. Very often such an error arises because a designer (unconsciously?) uses knowledge of the total, which is not specified in its interface. This tendency must therefore be eradicated with great decisiveness.
A third condition is that we continually strive to improve modularity. This means that the interfaces are kept as small as possible, containing as few objects and rules as possible. This means that the designer needs less knowledge of the system which makes designing easier. This can be caused by making each module more robust by stretching the parametric boundaries within which it functions reliably. Conflicting interests apply: the designer will preferably incorporate as many rules as possible in his own module, because that makes it easier to create a reliable design. However, for the designers of adjoining modules, this is detrimental because the interface becomes larger, and thus makes the design of those other modules more difficult.
In practice, the design and maintenance costs often appear to be higher than foreseen. I hope to have made it clear that the richer definition of modular design offers the possibility of substantially reducing those costs.
This is an translation from the original Dutch text that appeared as a column in magazine Constructeur, published by MYbusinessMediaB.V. in the Netherlands.