PLM: What makes a good module?

AfAfter an invigorating holiday period, we pick up on modular design. “Decompose your product into modules” is easily said, but what makes a good module? This time I want to elaborate on that question.

According to Wikipedia a modular design divides the system into smaller modules that can be designed independently of the whole, and can be assembled in different combinations to create different systems. Most people only know the second part of the definition, but the first one is certainly as important: “Modules that can be designed independently of the whole”. Just ask yourself: how can you design a module without knowing in which environment it is going to be used. That is a strangerequirement. Yet an essential one.

Of course, the designer of a module needs to know something about the environment in which the module should fit. That piece of knowledge we call the interface of the module. The general understanding of ‘interface’ is ‘where the modules touch each other’. A better definition however is ‘what the modules see of each other’. It is essential for a modular design that the interfaces are carefully specified.

Take a starter motor, for example. The interface is, you would think, the flange with which the starter motor fits on the engine block. At second thought , you would add the positions of the holes. but is that all? No, because the pinion must of course reach the starter wreath on the flywheel and the teeth must fit. Anything more? How about the torque and rpm needed to get the engine going? Just think about it and you’ll find some specs that need to fit. Moral of this example: Specifying an interface is not a trivial problem.To be able to talk more accurately about the requirements of interfaces, we use the picture below.

The first picture, figure a, depicts a system, integrated from two modules: Yellow and Red. The rounded, spotted fields compose the interface. They show that the modules share part of their specifications.  I invented this schematic years ago for my dissertation. That was about databases, which can be specified perfectly in mathematical/logical terms, but for mechanical designs this is no different: a CAD model also is a mathematical model.

Figure b shows the system as the two separate components. The yellow rectangle contains all the specifications needed to build a physical copy of component Yellow. I call it the own domain of the module.

So far a simple story, but now the interfaces. Figure c shows the spotted, overlapping areas. Please note: the spotted yellow field contains specifications of Red. They are part of the interface because the designer of Yellow needs to know them in order to create a fitting and working design. Try to formulate yourself what the spotted red field represents, in order to better understand how it works. I call these parts of the specification  foreign domain: They belong to the specification of the module, but they are owned by another module.

Figure d continues the story. The redsSpotted field contains specifications owned by Yellow, but is at the same time foreign domain for Red. It is knowledge that the designer of Red needs to have. That’s why I call it the public domain. It contains specifications of the module that the designer of the interfacing module needs to know in order to be able to design an appropriate module.  

In figure e finally, we see what is called: the private domain. These are the specifications that only the designer of the module needs to know. 

Note that I use the terms module and component in a specific meaning. The component is the physical object that is to be designed and produced. The module includes the specification of the interfaces. In other words: a component becomes a module by specifying its interfaces. 

For a mechanical design we can distinguish two types of specifications: 1) Specifications of geometrical objects  and 2) specifications of  rules  that capture relationships between objects. Independence of a module now appears to be determined by those rules:

A module is independent if for all rules that refer to an object in its own domain and to one or more objects in its environment, holds that all referenced objects are element of its  own or  foreign domain.

So, to check whether a module is independent, you have to check all the rules in its specification and check whether all the objects mentioned in those rules are actually included in the foreign domain. If the module complies with this, the designer can freely change any specification in his private domain without causing a problem with another module!

Next time I will go into the consequences of this design rule for good modularity.

This is an translation from the original Dutch text that appeared as a column in magazine  Constructeur, published by MYbusinessMediaB.V. in the Netherlands.