Secure Modular Design of Configurable Products

. Design of complex configurable products is a hard task. Testing of all variants is often impossible because the number of variants is orders of magnitude larger than the total life cycle production volume. Modular design is advocated as solution but cannot guarantee that if one variant works OK another will not cause errors. This paper proposes, based on a similar method for modular database sys-tem design, a theory for modular design of mechanical systems that poses the concept of module independence, to enable design and test of module families as a separate unit while offering formal conditions to assure that no variant of the module family will cause failures when integrated in the end-product. This allows system verification and testing to be done per module family with no need to test individual end product variants. The method is illustrated with a simple example of a mechanical design, but not yet applied in practice.


Introduction
A configurable product is defined by a number of parameters. By assigning proper values to the parameters a specific product can be configured to fit the requirements of a customer. When one or more parameters control the selection out of a set of interchangeable components, the design is called modular and the interchangeable components are called modules. Product configuration is applied massively in modern industry in order to increase product variety. Especially automotive industry depends heavily on product configuration, such that numbers of product variants within one model range up to 10**20 and larger.
The design of a configurable product is a complex task. Where designing a single product first time right is still a challenge, the design of a consistent product family, with all necessary rules to make sure that every allowed variant will be manufacturable and will work properly, is a huge task, especially because 100% testing is impossible when the number of variants is orders of magnitude larger than the total life cycle production volume.
Controlling the change process in a configurable product environment is as complex as the original design. Every product family will have numerous changes during its life time. Every change in a module may cause conflicts with other modules. Maintaining the consistency of a configurable product is a huge task. This research proposes a secure method for design and maintenance of configurable products.

Modularity Overview
The generic meaning of module is "exchangeable component". The term modularity is used to describe the use of common units to create product variants. It aims at the identification of independent, standardized, or interchangeable units to satisfy a variety of functions (1,2). For decomposing a system into modules often Design Structure Matrix (3,4) is used where components with relatively more interactions are combined into one module. Components that are not assigned to any module are called independent. Three types of modularity are distinguished: component swapping, component sharing and bus. Four types of interaction are mentioned by (5): spatial, energy, information and material. Modularity is viewed by (6) as depending on two characteristics of a design: 1) similarity between the physical and functional architecture of the design, and 2) minimization of incidental interactions between physical components. (7) Discusses modularity in the context of integrated process and product design in order to obtain flexibility in terms of increased number of product variants. An approach from the operations management point of view is found in (8). Their qualitative research results in correlations between type of modularity and complexity of production and supply chain. The modular design of production management systems is discussed in (9,10,11,12).
All methods for design of modular products aim at reduction of design cost, but non offers a possibility to prove that two modules are exchangeable in the sense that if one functions without failure in a larger system, the other will as well. Changes in a modular system can be implemented by changing one or more modules and replacing the old versions by the new ones. A method to prove that that if the new module version is consistent in itself, it will also be consistent in the whole system, could reduce considerably the maintenance cost for complex configurable products. This paper discusses such a method for secure modular design.

Research question and Approach
When the number of variants is much larger than the total lifecycle production volume, it is unrealistic to test all possible combinations, so it is desirable to have a method to test individual modules independent from the total product, with certainty that all module variants will operate properly in the total system, regardless the choices made for other modules. Also it is desirable to be able to design and verify modules independently, in order to avoid endless design iterations. The problem is that there are many relationships between the components, which may cause failure under non frequently occurring conditions. When there are complex relationships between the components of a product, a change in one component may cause failure in other components. This means that the effort for a change increases with the complexity of the product. If we assume that the frequency of changes also increases with the complexity of the product, we may conclude that maintenance cost will increase with the square of the complexity. This paper describes a method to define module independence as a provable property that enables to design, verify and test a module as a separate entity and yet ensure that the module will not cause failures in other modules during manufacturing or operation. Note that the term module independence as defined in this paper is very different from the term as cited (3,4) in the previous section.
The research builds upon a modular design methodology developed for large databased information systems (13,14). The concept of module independence is translated from database systems to mechanical systems and illustrated with an example. This paper explains how the theory can be applied in mechanical design, but does not describe validation in practice.

4
Configurable products and product families.

Some terminology
The traditional approach in manufacturing is to design a product once and produce identical copies many times. The need for increased variety led to introduction of the concept of product families (15,16). Understanding product families requires quite some abstract thinking, so precise definition of terms is helpful:  A product instance is a specific, single, manufactured product, as can be touched, sold to and used by a customer,  A product type is defined by a product model, such that each two product instances, manufactured according to this model, are equivalent to the user.
 A product family is a class of product variants, defined by a number of parameters with specified value ranges. Each choice of parameter values defines a product variant. A product variant may be either a product family itself, or a product type.
Product is used as generic term: it can be an end-product, a sub-assembly or a mono part, and for each of them instance, type or family. A component is a product that is intended to be used as part of an assembly. The implementation of a change in the design of a modular product can be viewed as creating a changed version of a module and exchanging the old module version with the new one.

Definition of module
As stated above a module is an exchangeable component. That means that in a specific assembly it can be exchanged with another variant of the same product family. When it is not feasible to test the behavior in the end-product of each variant individually, we need formal rules to predict the consistent exchangeability of the whole family. Since a module, in order to be a functional part of a larger system, must have relationships (share space, energy, information or material) with other parts of the system, it is impossible to check consistency of a module without knowledge of some specifications of those other parts. Therefore a module must have interfaces, showing the necessary specifications of related parts in the system. Consequently, in this paper, we define a module as: A module is a product family or product type including the specification of its interfaces.
This means that a module specification consists of two parts: 1. The own domain which holds the specification of the component itself, 2. The foreign domain which holds specifications of related components.
The own domain can be split into two parts: 1. The public domain with the own specifications that may occur in the public domain of other modules, 2. The private domain with the specifications that are hidden for other modules.
Note that in this definition a module interface differs from the usual interpretation of interface as a physical port to exchange or share space, energy, information or material. A module interface is a set of specifications. The foreign domain is the module's model of its environment, the public domain is the model the module shows of itself to its environment. So in this paper a module interface is defined from the design point of view rather than form an operational point of view.
The essential property of a module is that it can be changed and verified without any other knowledge of the total system than its foreign domain, such that, after verification, it can be integrated in its intended position in the total system, without causing any failures during assembly or operation. This property is called module independence.
Supposing that a module type is always a variant of a family of mutually exchangeable components, we call a module independent when: It can be verified and tested to operate properly in the intended product, without knowledge of the intended product other than specified in the module's foreign domain.
It may be clear that the designer of a module may only change specifications in the own domain of the module. When changing a specification in the public domain, he must check which other modules are using this specification and negotiate with the designers of those modules whether the intended change is acceptable. A desirable, but not self evident property is that the designer can change any specification in the private domain without causing conflicts with other modules. The designer is not allowed to change any specification in the foreign domain of his module, since those are the responsibility of another designer.

module independence in databased systems
The concept of module independence has originally been developed for data based information systems, which consist of a set of applications that operate on a common database. Maintenance of complex databased information systems appears to be expensive because a change in one application or its database subschema, may cause failures in other applications. These errors cannot always be detected in tests, because it happens that state changes propagate slowly along different elements of the database until a fault occurs in an application that does not even have any data element in common with the changed application. Since any data element may be related, directly or via applications, to any other data element in the total database, every change must be verified against the whole database.
A database is defined by a database schema that specifies object classes, their attributes and constraints that limit the allowed combinations of attribute values. Constraints can refer to single attributes (like "the value must be a positive integer") or to multiple elements (like "this value must be unique within the object class population"). In this way the database schema defines the state space of the database. Applications perform operations on the database, which can be (1) reading data and performing computational operations on them or (2) writing data in order to add or change data. A fault occurs when an application tries to execute a not allowed state change (like writing a negative integer) or when a value read from the database causes failure of a computational operation (like division by zero). Since the database state space is defined by its schema, it is theoretically possible to check each operation against every possible set of values.
A database module is a subset of object classes and constraints together with a set of applications that operate on only those classes. The subset of element specifications and constraints forms the module-subschema. The module state space is obtained by projecting the database state space on the module schema. It is evident that constraints make only sense for a module when all elements referenced in the constraint are in the module subschema. Modules interact through interfaces in the form of shared object classes. Each class is owned by a single module and only applications of the owner module are allowed to write on this object class. This means that the applications of a module may read all elements in its subschema, including foreign elements, but update only own elements. On basis of the usage rights the subschema of a module can be divided in own, private, public and foreign domains, consistent with the definitions above.
Verification of the design of the subschema and applications of a module must make sure that each computational operation is defined for all possible values of the attributes that are referred to and that each change operation results in an element of the state space (meaning it does not conflict with any constraint). It is clear that a change in the design of the foreign domain may cause an own operation to fail on an unanticipated value, while a change in the public domain may cause failure of an operation of another module. The desirable property of module independence must guarantee that each module can be designed, operated and maintained with only knowledge of the module and its interfaces. This property is defined as: A module is independent in a total schema if and only if every state change that is allowed according to its subschema, is also allowed according to the total schema, and every element of the module state space is a valid state for all its operations.
Independence means that a module can be designed, used and changed without risk of failures in the total database, with only knowledge of its subschema. This means that new or changed applications as well as changes in the own domain of the subschema, need to be checked only against the subschema of the module without knowledge of the database structure nor applications outside that subschema.
It has been proven (13) that: a database module is independent in a database schema, if every constraint in the database schema that refers to an element of the own domain of the module, does not refer to any element outside the subschema of the module.
In practice this means that modules must be designed without using any knowledge that is not specified in the subschema of the module. Note that independence of a module is defined in the context of the total database schema of which it is a subschema. Independence is not a property of a module on its own, but of the module in a specific environment.

Module independence in mechanical systems
The property of independence as defined above for a database module is exactly the property we wish to have for modules in mechanical systems. If we can extend the concept of module independence from databased information systems to complex mechatronic products, we would have a tool to design modular systems that can be proven correct by proving that each single module is correct. In this paper we extend this concept to the design of mechanical products. However, we expect that the conclusions will stay valid when electronic and other technologies are added.
A mechanical product is an assembly of ultimately mono parts. Some parts can have variable positions because of elastic properties or degrees of freedom in assemblies. A mono part is specified in terms of features like cube or cylinder. Each feature compares to an object class in a database. Each variable of the feature compares to an attribute of the object class and each actual value for a variable to an attribute value. Some variables specify possible movements of the construction during operation (e.g. axle rotation). We call them dynamic variables. When in the part model all static (non-dynamic) variables have singular values, the model specifies a product type. When one or more static variables have a value range assigned, the model specifies a product family. An assembly is defined by a Bill of Materials, where each BoM-line specifies a part with its relative position in the assembly. If the what-used variable of a BoM-line specifies a set of possible parts, it defines a product family based on exchangeable parts.
Constraints in a database schema correspond to constraints in a mechanical design, that limit the range of allowed values of variables. Examples are mutual fit for connected components, design volumes and limits on force, mass, speed, temperature etc. The own domain of the module is the product model itself. The public domain of a module is the list of own elements and constraints that may be referred to (known by) other modules. The foreign domain is the list of elements and constraints of other modules that may be referred to (relied upon) in this module. Private, public and foreign domains together form the module model.
Based on this analogy between database systems and mechanical systems, we can define the condition for module independence as: a module of a mechanical system is independent in the system model, if every constraint in the system model that refers to an element of the own domain of the module, does not refer to any element that is not specified in the module model.
In the following section we will apply this interpretation of a modular mechanical product model on a simple example.

Example
Let's take the simple example of a metal block (further referenced as Block) with a cylindrical hole and a metal cylinder (Cylinder) that can rotate in the hole (see figure  1). Block has attributes l, w, and h for its outer dimensions. Further is has axis and d for axis and diameter of the hole. The origin of Block is where the axis meets its left side in its point of gravity; the x-axis equal to axis and parallel to the length of Block.
Width is parallel to y-axis and height parallel to z-axis. Cylinder has attributes l and d.
The origin is the center of the left end. The x-axis is the axis of Cylinder.

Fig. 1. Mechanical design with three modules
Suppose Cylinder is intended to rotate in the hole of Block. Then the following constraints could apply: C1. The axes of the hole and the cylinder coincide, C2. The difference between hole-and cylinder diameter must be between 1% and 2% of hole diameter, C3. No end of the cylinder is inside the hole.
Because independence is not a property of a module on its own, but of a module in an assembly, the structure of the assembly must be known in order to be able to check independence. Therefore we define assembly Assy with bill of material: {Part1: Block(0, 0, 0, 0, 0, 0), Part2: Cylinder(0, 0, 0, rotation, 0, 0)}.
This BOM specifies that the x y and z-axes of Block and Cylinder coincide and that Cylinder can rotate around the x-axis.
In order to be an independent module, the designer of Block needs to know all Cylinder specifications that are referenced in the constraints: Cylinder.axis, Cylinder.d, Cylinder.l, Part2. This makes all relevant constraints 'visible' for module Wheel, so Wheel is independent in Assy. However, the Wheel design introduced a constraint that refers to a specification of Block, and thus destroys the independence of Block. This may cause trouble, when configuring a product. Suppose that parameter values for Wheel and Cylinder have been set and a value for Block.l has to be chosen. Since the Block module does not know Wheel, it cannot check constraint C5 and may cause a clash between Block and Wheel. To restore independence of Block, Wheel.l must be added to the foreign domain of Block.
The example shows how the features and bills of material in the model of a mechanical product correspond to object classes in databases. Feature and BoM variables correspond to attributes of objects. Constraints in a mechanical model limit value ranges of variables like constraints in a database schema limit attribute values. The distinction between static and dynamic variables adds a nuance to mechanical models: static attributes define variants of product families while dynamic variables define the behavior of the product during operation.

Discussion
Although the example is extremely simple, it shows how module independence depends on constraints and how ignored constraints cause failures (like when adding Wheel in the example). Constraints are essential for system consistency and thus for managing changes. Therefore it is paramount that all constraints are explicitly specified in the module models and that for every constraint it is clear to which elements it refers. In our experience this is not common in current design practice. Also CAD and PLM systems do not support the maintenance of lists of design constraints, other than, to some extent in the requirements management function. An important task of reviewers is to check for implicit constraints, that are not specified in the design but nevertheless relied upon for any design decisions.