PLM, how modular can it be?

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.

Imagine a block with a cylindrical hole, a cylinder and a wheel, as loosely outlined in the accompanying figure. The block (called Blok since this is Dutch Design) is specified by variables length l, width b, height h, Axis as and diameter d. The origin of the block is the center of gravity of the left plane. Length, width and height are parallel to resp. X, Y and Z axis. The axis of the hole goes through the origin and coincides with the X axis. The cylinder Cilinder is specified by variables as, d and l. The origin is the center point of the left plane and the shaft coincides with the x-axis. Wiel is specified by axle, h, b and d. The origin is again the center of the left plane and the shaft coincides with the X-axis.

The intention is to make an assembly in which the Wiel mounted on Cilinder  can rotate in Blok. The design starts with the modules Blok and Cilinder. We want Blok as a module to be independent in the assembly. To that end, as explained in the preceding columns, we must provide the modules with interfaces in the form of a foreign domain that shows all the specifications relevant to this module from other modules. The condition for independence means for Blok that:

For each  constraint that refers to an own specification of  Blok, all  specifications of other modules to which that constraint refers are included in the foreign domain of Block.

The designer considers that the following constraints (synonym for the word ‘rule’ that in the previous columns) must hold:

C1: Blok and Cilinder axle coincide,
C2:  The difference between the diameters of hole and Cilinder must lie between 1% and 2% of the bore diameter,
c3:  None of the ends of the shaft is located inside the block.

To be able to check that the axles of Blok and Cilinder coincide, the designer must know the positions of both modules from the BOM. That can be specified as

Part1:  block (0, 0, 0, 0, 0, 0);

Part2:  cylinder (0, 0, 0, 0, 0, 0).

To be able to check all these constraints, the foreign domain of Blok is:

Cilinder.as, Cicylinder.d, Cilinder.l, Part1, Part2.

Remember that the foreign domain , in addition to the module’s own specifications, adds parts of other modules. Although it is listed here as variables, you may imagine it as lines and solids in a 3D model. In that model, you see the component in its relevcant environment and that is exactly the essence of modular design: The designer must know something about the environment of his component, but not more than strictly necessary.

If Cilinder is to be independent in this composition, a foreign domain must also be specified for this purpose:

Blok.axle, Blok.d, Blok.b, Part1, Part2.

Exercise: check whether block and cylinder are indeed independent (I might have made a mistake). How easy omissions can happen we see if we assign the design of Wiel to another designer. Wiel is added to the assembly with the following BOM-line:

PART3: Wiel ((cylinder. L-Wiel. B), 0, 0, 0, 0, 0).

In order for Wiel to be stable, the following constraint shall be added:

C4: Wiel.d = Cilinder.d, C5: Cilinder.l – Blok.l – Wiel.b > Wiel.d/10.

On this basis the foreign domain of Wiel is specified as:

Cilinder.d, Cilinder.l, Blok.l, Part2, Part3.

With this Wiel is independent in the asse,bly, but note: the independence of Blok is now disturbed, because C5 is a constraint that touches Blok, but which the designer of Blok cannot see. So we have to add Wiel.b to the foreign domain of Blok to restore the independence of Blok.

This example shows how adding a part to a system can lead to conflicts with parts whith which it has no direct contact. The unobserved dependency of Blok could cause an error if the designer of Block would decide to enlarge the length of the Blok with a clash between Blok and Wiel as a result.  In the specification of Blok nothing is known about Wiel. Simple geometric clashes are flagged by the CAD system, but not a constraint like C5 about the clearance between Block and Wiel. For instance, a simple change can cause an error without a CAD system or even a reviewer noticing it. In this super simple example, it may seem trivial, but in a complex product such an error can easily occur.

I hope that it has become clear that the extra work of specifying constraints and foreign domains for complex systems can be very rewarding. One only needs to check the ‘scope’ of the constraints to know if a module is independent and respects the independence of other modules. the question of what that means for the methodology of modular design, I would like to raise in a next column.

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