PLM: The relevance of design constraints.

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. 

With a safe change, we mean a change in the design of a module that cannot cause errors in other modules during production or use. But what exactly do we mean by a constraint?

A constraint is a rule that binds the value of a design variable, or the values of some design variables in conjunction, to certain boundaries. In a CAD system a shape is made up of features such as beam, cylinder etc. Each feature is characterized by a number of variables and an important task for the designer is to choose the optimal value for all those variables. That optimum is determined by a variety of connections between these variables. In parametric designs, these links can be partially represented as rules, but usually the variables in the final design are given a fixed value and the rules disappear from the model. In addition, there are always many constraints that cannot be expressed in rules, but which the engineer will take into account during the design. Many of these constraints are not documented with the result that they are overlooked in a later change so that during production or use a situation can occur where a constraint is violated, so that an error occurs that causes the product to not function correctly. This can be avoided by properly keeping track of the constraints that have been taken into account in the design.

Constraints come in many types. To begin with in the form of requirements. These requirements can be understood as constraints, because they all ultimately relate to design variables. The requirements document is usually saved, so these requirements can be retrived. However, requirements are often changed or added during the design process. All too often, such changes are made directly in the design, without the requirements document being altered. And these changes are later overlooked.

Another common kind of constraint relates to the fitting of two components against each other, for example in the form of a tangent plane with a number of holes for bolts. Such constraints seem so trivial that a constructor will never move such a hole without adjusting it in the adjoining part as well. In Modular designs, however, there are often extra holes for variants and there it can go wrong. If this variant is later applied, it suddenly appears to no longer fit.

A slightly more mixed kind are constraints that limit the maximum load on components. Often a force is passed through a chain of components. Then it can happen that a change in the beginning of the chain causes an overload at the end. A fine example of this occurred in the design of a Formula Student race car. In order to save weight, they had chosen to implement the cross axes between differential and rear wheel in carbon. The new axles were dimensioned on the maximum torque that the engine could deliver. However, they did not take into account that, when shifting the clutch, strong peaks in the torque occurred when the engine was slowed down or accelerated. The old steel shafts were elastic and thus limited the peak. The carbon shafts were much stiffer so the load peaks were much larger so that the powertrain broke down during the race. So here a constraint was overlooked.

Even meaner are the constraints that apply to modern electronic systems. An example happened to me when I wanted to mount a rear view camera on my car. Despite the fact that the connection between camera and monitor was a copper pipe and not a radio connection, the image was fuzzy. When I complained to the supplier I got the answer that it was probably caused by the canbus system in my car. Now my car has no canbus, but this response from the supplier indicates that connecting new devices regularly gives problems with the bus system. The high frequencies of the digital signals in the bus, especially when piping is close to each other, can easily interfere with the camera’s video signals.

The examples mentioned make it clear that it can be sensible to document all constraints in a design. By doing this in a database that relates each constraint to the components/modules to which it refers, it becomes very easy to check for any changes in the system that may be compromised by the change. While keeping track of that registration requires some extra time, but the consequences of the errors that can be avoided may be many times more expensive. Unfortunately, in no PLM system, I have encountered a constraint management feature and also support CAD systems, beyond the rules of parametric design, not relenting constraints to variables of features. Here too, there remains room for improvements in the future.