PLM once started as an Engineering Data Management: a tool for engineers. What is the added value of product life cycle management for the engineer? After all the constructor’s task is to design a workable product that complies with the sales requirements. That task ends when releasing the design.

A decade ago I started this column with explaining what PLM is meant for. Looking back to the more recent episodes, I especially focused on the details of PLM. This first column after the summer holiday is a great opportunity to go wider again.

Modular design has tremendous potential. Would it be possible to unlock that potential? In practice, there has not been much new In the last 30 years. I think this is because there is no sharp definition of modular and because the methods are more intuitive than logically substantiated. Can a sharper definition bring more clarity?

In a previous column about the design of modular configurable products it emerged that it is possible to check if a change in a module is safe, provided you know exactly what constraints are in the system. 

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. 

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. 

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 ‘. 

Some time ago I devoted a trio of columns (year 15 Nrs 6-10) to modularity, a subject that, I fear, is still too little understood. Since those columns treated the subject at a rather abstract level, it seems useful to illustrate the idea by means of a simple but concrete example.

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. 

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.