Go to the table of contents.

Previous ...

4.5 Product models and product configuration

Product configuration is an area where much research. It is an interesting area since there are many different starting points from which the product configuration problem can be addressed. This makes the area rather large and differentiated. An overview of configuration tasks and methods is provided by Sabin & Weigel (1998). However, since the field of product configuration is large, the overview did not manage to cover the whole subject. A selected set of references on product configuration are described below to provide a frame of reference for the research presented in this thesis.

4.5.1 The generic model of configuration tasks

Sabin & Weigel (1998) define configuration as a generative process. A solution is the result of a search process within the space of all possible combinations of objects. During this process, the system selects component instances and adds them to the current configuration. Many authors that write about product configuration refer to the generic model of configuration tasks defined by Mittal & Frayman (1989). Their definition of a configuration task includes two statements: (1) what is given and (2) expected result.

Given: (A) a fixed, pre-defined set of components, where a component is defined by a set of properties, ports for connecting it to other components, constraints at each port that describe the components that can be connected at that port, and other structural constraints, (B) some description of the desired configuration, and (C) possibly some criteria for making optimal selections.

Build: One or more configurations that satisfy all the requirements, where a configuration is a set of components and descriptions of the connections between the components in the set, or detect inconsistencies in the requirements.

Mittal & Frayman (1989) further describe two restrictions on the general configuration task defined above. The reason for introducing these restrictions is to reduce the complexity of the task through the introduction of additional kinds of knowledge. The two restrictions are a functional architecture and key components per function. The generic description of the configuration task as presented above remains, except for the statement A, which is refined to:

(A1) one or more functional architectures for desired configurations, each abstractly defined by functions {rf1, rf2, …, rfn, of1, of2, …, ofm}, where rfi are always needed and ofj are optional, (A2) a fixed pre-defined set of components, where a component is minimally described by a set of properties, ports for connecting it to other components, constraints at each port that describe the components that can be connected at that port, and other structural constraints, (A3) a mapping from each function fi to components ci that are key components in providing fi and a description of other functions that are required by ci in order to function as fi.

Mittal & Frayman (1989) also present a set of criteria that are relevant to problem-solving methods for configuration purposes. These criteria are: (1) soundness (i.e., a solution is indeed correct), (2) completeness (i.e. if a solution exist it will be found), (3) exhaustivity (i.e., all possible solutions can be found), and (4) optimization (i.e. finding the best solution under some set of criteria).

4.5.2 Configuration using a frame architecture

Zhang & Jarzabek (2003) present XVCL (XML-based Variant Configuration Language) as a method and tool for product lines, to facilitate handling variants in re-useable software assets. Zhang & Jarzabek use three domains to identify parameters that influence variation: functional variants, variant design decisions, and implementation-level variants. By functional variants Zhang & Jarzabek (2003) mean variation driven by variant functional requirements. Zhang & Jarzabek (2003) describe an x-framework as an XVCL implementation of the concept of product line architecture. An x-framework is a layered collection of meta-components that in XVCL are referred to as x-frames. The x-framework facilitates production of concrete software components that meet required variants. Zhang & Jarzabek state that x-frames are generic in the sense that they include provisions for accommodating variants. Jarzabek et al. (2003) conclude that, while designing a frame-based architecture is not trivial, subsequent productivity gains are substantial. By reusing skillfully structured frame architectures, there is a need to focus on only the 5%-15% of a program solution that is unique; the other 85%-95% is re-used. These gains are made through the flexibility of the resulting architectures and their evolvability over time.

4.5.3 Product configuration models

The area of product definition and its interaction with the sales delivery process is described in some detail by Mesihovic (2004). Mesihovic focuses on the processes involved in how configurable products are managed with a specific focus on the sales delivery process and related aspects. The most common concepts companies use to describe the variety of their products are the components that the product consists of and the functions that the product provides to the customer. This is complemented with a set of rules defining which components should be selected to meet given customer needs. The components relate to each other by aggregation relationships (Figure 32). The relationships between the component aggregates can be expressed through positive combinatory relationships between components and parameter values (variants in Figure 32) as well as incompatibility relations (restrictions).

Figure 32: Product configuration model (Mesihovic & Malmqvist, 2004).

Mesihovic & Malmqvist (2004) discuss some of the difficulties associated with product configuration. Current product configuration models and processes have in many cases failed to deliver expected benefits to the companies. A lack of uniform methods and complex maintenance sometimes resulting in incorrectness and inconsistencies are part of the explanation. Another is that the configuration system contains very central information about the product, but it is seldom the system where the information is primarily maintained. This situation tends to create different groups of people (e.g. those working with the products and those working with the product configuration models) that may have difficulties in communicating and fully understanding each other. In some cases companies also lack well-defined and functioning procedures and processes for updating product configuration models. This is in some contrast to related areas such as engineering change management, where formalized change management processes are used.

4.5.4 Generic structures for product configuration

Männistö et al. (1995) introduce the reasons for their approach with the statement that there is an increasing demand for individually tailored products with short delivery times. This demand can be satisfied with configurable products, which can be easily customized according to customer specifications. The designers of a configurable product must devise a plan that can be used repeatedly for realizing customer orders as working combinations of the available components. Männistö et al. refer to this information in terms of a configuration model and state that the concept is similar to some uses of the term product family. Based on a customer order the order and configuration model are used for creating a product configuration that describe a single instance of the product. In a well functioning configuration environment provisions should be available for modeling configurable products, supporting the configuration process, and being supportive of the evolution of the constructs captured in the model. According to Männistö et al. (1995) data modeling for a configuration environment requires: (1) classification with inheritance, (2) component relationships between classes with support for refinement in sub-classes and complex domains, and (3) versions of classes with a clear distinction between the evolution of general product descriptions and product instance descriptions and with richer versioning semantics than just evolution.

Männistö et al. (2001a) presents a mechanism based on generic models of product individuals organized into a specialization hierarchy to support multiple abstraction levels. The main purpose of the model presented is to support the needs for after-sales. Männistö et al. (2001a) state that data structures suitable for manufacturing are not the most appropriate for after-sales. After-sales requires its own concepts and its information must be presented in a view of its own. For instance, a component (part) needing regular service deserves a more prominent position in the after-sales view than in the manufacturing view.

In the model presented by Männistö et al. (2001a) a product is composed of components (which in turn can be composed of components) and this hierarchy is referred to as a product structure (or bill-of-materials, BOM). A distinction is made between a master BOM (which serves as a recipe for many products, e.g. in mass production) and an order BOM (which specifically describes the structure of an individual product for a single customer order, e.g. in make-to-order or assemble-to-order production). The term product type is used to refer to a type of a product when this distinction is of importance. The terms component, component type, and component individual are used similarly. The term part refers to the relation between components (a component can have other components as parts). The main focus of the model is products that have a large number of variants. A special class of such products is configurable products that are configured to the needs of each customer in a configuration process according to a pre-defined configuration model (or, with a more generic term, a generic product structure model). The term ‘structure’ indicates that the interest is mainly in variation of product structure, i.e. the components of the product. The term ‘generic’ means that a single data model is used to represent multiple product variants. Furthermore, different organizational stakeholders see the structure of a product very differently. These different aspects of a product are called views. A view may need different concepts and different semantics for the concepts in order to fulfill the needs of the organizational stakeholder (i.e. it is not only the breakdown structure of the product that may differ between views). As a consequence, it becomes an interesting issue how the views relate to each other. Männistö et al. (2001a) focus on data models for the after-sales view of different product individuals and on the relation between this view and the manufacturing view.

4.5.5 The generic bill-of-material concept

The generic bill-of-material (BOM) concept described by van Veen (1990) aims to provide many possibilities for modeling large varieties of product types and their product structures without requiring large amounts of data redundancy. The basic idea of the generic BOM concept is to define data at the level of sets of product types instead of individual product types. The set of product types is referred to as an item. An item can be generic or specific. An item is a specific item if it contains precisely one product type. An item is a generic item if it contains more than one product type. The objective of the concept item is to allow data to be recorded only once, for a set of product types, i.e. for an item, instead of recording them explicitly for each individual product type of that item. The independent definition of a set of product types by means of an item is not limited to final product types only. Sets of product types at lower levels in the product structure can also be defined as independent entities, i.e. as items.

A product type is a basic element and has the following definition: a physical, existing product is represented by at most one product type. Any product is in fact an instance of a product type. It is assumed that products that are instances of the same product type are mutually exchangeable. Furthermore, a product type can also be defined for non-physical concepts. A product type is defined by means of a specification. A specification is a set of (relevant) parameter values. A parameter value is the combination of a parameter and a value. For each parameter a set of values is defined. An important operation is to be able to determine whether two parameter values are equal or unequal. The set of values of any parameter may contain one special value called unknown. In the evaluation of equality of two parameter values it is assumed that the parameter values (pi, vij) and (pi, unknown) are unequal. A product type that has one or more parameters with the value unknown is not entirely defined and will require additional engineering to obtain a product type that is entirely known (i.e. a product type with one or more values unknown is not fully engineered).

Figure 33: Parameter, value, parameter value, and specification (based on van Veen, 1990).

In order to determine whether the data of an item apply to a product type it is important to be able to determine whether a given product type is a member of a given item. This membership is determined by means of a set description of X. When a specification is evaluated against the set of specifications defined by the set description of an item A, three outcomes are distinguished. A specification may be valid, invalid, or semi-valid against the set description of an item.

A specification is valid against an item if it does not contain any parameter with the value unknown and if there is precisely one product type described by the specification. The item is in this case fully specified. A specification is invalid against an item if no product type is described by the specification. A specification is definite semi-valid against an item if precisely on product type is described and both the specification and the product type description share the same parameters with the value unknown. Finally, a specification is indefinite semi-valid against an item is more than one product type is described by the specification. The item is in this case partly specified. In this case, addition of parameter values to the specification may produce a valid or definite semi-valid specification.

In the generic BOM concept the relationships that build the product structure will have a generic nature similar to the items (van Veen, 1990). The relationships are defined between properties (i.e. parameter values) of different product types, without referring to the individual product types. Two different types of relationships may exist between items. The first type is a set relationship and the second type is the gozinto relationship. The first type deals with how product types are organized into sets (i.e. items) and the second type is used to define a product structure hierarchy.

The set relationship exists due to the fact that items are sets of product types and that they can be defined such that they have none, one, or more than one product type in common. There are three different kinds of set-relationships: disjunct, overlap relationship, and generalization specialization relationship. In the generic BOM concept presented by van Veen it is assumed that there are no overlap relationships A generalization-specialization relationship occurs if one item Y is a real sub-set of the other item X. Item X of the entire set is called the generalized item. Item Y, the sub-set, is called the specialized item.

   [Eq. 4.2]

Figure 34: General form of a conversion rule (van Veen, 1990).

Product types that are each other’s parent and component are members of different items and related by a gozinto relationship. The generic BOM concept allows for the definition of relationships of the type gozinto relationship between items. Determining the specific product types involved in a gozinto relationship between two generic items (i.e. sets of product types) is the role of the conversion function. The conversion function is constituted by conversion rules. Conversion rules define deterministic relationships between parameter values of product specifications of parent product types and component product types. In order to guarantee a function (in the mathematical sense), conversion rules must be formulated in such way that, for each full specification of the parent item, precisely one full specification for the component item is produced. In addition, if the specification of the parent item is valid, then the specification produced for the component item must also be valid. It is assumed that the conversion rule has the general form illustrated in Figure 34. If there are more sets of parameter values of the parent item that require the same parameter value for the component item, more than one conversion rule can be defined for that component parameter value. Special attention is required for the role of the value unknown in the conversion function. According to van Veen (1990) it is not permitted to define a conversion rule for a component parameter value (piunknown) unless at least one parameter value (pjunknown) of the parent item is present in the conversion rule. In other words, it will not be allowed that a set of parent item parameter values all unequal to unknown causes a parameter of a component item to be assigned the value unknown. In this way it is avoided that a valid specification against a parent item could produce a semi-valid specification for one or more of its component items (a product type which is already entirely engineered cannot have a component product type which is not entirely engineered). Correspondingly, it should not be allowed to define a conversion rule for a component parameter value (pc, vci) (vci not being unknown) that has a parent parameter value (ppunknown). In other words, it is not permitted for a component parameter value unequal to unknown to be generated automatically from a parent parameter pp which apparently has some influence on pc, but which may still be assigned any imaginable value.

According to van Veen (1990) items may need to be distinguished such that for a parent item P and a component item C, gozinto-relationships between product types of P and product types of C require different values for attributes such as quantity/per, scrap factor, and lead time adjustment. An issue here is which attributes of gozinto relationships vary substantially and therefore may impose high demands on the way in which items must be distinguished. These attributes should not remain attributes of a gozinto relationship but should become parameters that may be assigned a value dependent on the parent product type specified. In order to stress the difference between sets of gozinto-relationships and members of these sets, a set of gozinto-relationships will be called a Cover Aggregation Set relationship, derived from the concept of Cover Aggregation of Codd (1979). This relationship will be shortened to CAS relationship. A CAS relationship is a non-empty set of gozinto-relationships. A parent item and a component item are connected by a CAS relationship. In a similar way as for product types, a finite set of parameters is defined for a gozinto relationship. Also, for each parameter, a set of values can be defined (including the value unknown). The set of parameter values of a gozinto relationship is called a gozinto relationship specification.

In a way similar to the items described above, a set of gozinto relationships (i.e. the CAS-relationship) is defined by a related set description in terms of these parameters and values. An example of a set description of CAS-relationship (parent, X), (sequence, 10), component, Y), which is denoted as parent item-sequence number-component item, is:

Using the same approach as described above for the concept of item, it can be determined for a specification whether or not a gozinto relationship meeting that specification is a member of a CAS relationship. The specification of a CAS relationship should be made available unambiguously if the parent item is fully specified. The basic conversion function can be applied for that purpose. It is assumed that a set description is available and that we can distinguish between valid, invalid, and definite or indefinite semi-valid specifications against the CAS relationship. Furthermore, in line with the concept of item, a CAS relationship can be fully or partly specified and a CAS relationship can be specific or generic. A resulting CAS relationship can only be generated if a parent result item and a component result item have been generated. The resulting CAS relationship will be identified by the combination of the key attribute of the parent result item, the sequence number, and the key attribute of the component result item.

Generic CAS relationships can represent situations in which a parent item P and a component item Q can be related in such a way that some, but not all, product types of P have a component product type that is a member of Q. For instance, a generic CAS relationship can be defined using the parameter qty/per. A gozinto relationship with a qty/per equal to 0 then defines that no gozinto relationships must be represented (i.e. no product type of the component item is related to the parent). It should, however, be noted that van Veen (1990) advices against using this capability since this, in his opinion, leads to negative effects regarding interpretation of the structure. Instead it is required that a generic CAS relationship between parent item P and component item Q represents the fact that, at fewest, one product type p from P has a component product type q that is a member of Q.

The bill-of-material (BOM) of an item X is defined as the set of CAS relationships in which X is the parent item. Since it can be defined when a single CAS relationship is specific or not, it can also be determined whether the BOM is specific or not. The BOM of X is fully specified if all CAS relationships constituting the BOM of X are fully specified and each of these CAS relationships specifies a component item that is fully specified. The BOM of X is specific if all CAS relationships constituting the BOM of X are specific and each of these CAS relationships specifies a component item that is specific. The BOM of X is generic if one or more of the CAS relationships from the set of CAS relationships constituting the BOM is generic and/or if one or more of these CAS relationships specifies a component item that is generic.

The application of the above described generic BOM concept to the development of product families and the synthesis of variety has been explored and described by for instance Erens (2004).

4.5.6 Architecture of bill-of-material systems

Two processes can be identified in the architecture for a bill-of-material (BOM) processing system (van Veen, 1990). The two processes are: (1) the product specification process, in which a product type is merely identified by means of parameter values, and (2) the bill-of-material generation process in which a BOM is generated for a product type that is identified by means of< parameter values. The distinction between these processes is used by van Veen (1990) to define the architecture for BOM processing systems (see Figure 35).

Figure 35: An architecture for a new kind of BOM processing and order entry system
(van Veen, 1990).

The architecture distinguishes three sub-systems. The primary function of the product specification system (PSS) is to evaluate whether a given specification S is valid, semi-valid, or invalid against a particular item A. The primary function of the bill-of-material generating system (BGS) is to generate a BOM given an item A and a valid specification against A. The BGS supports both single- and multi-level BOM. The primary function of the customer specification support system (CSSS) is to advise the user (a salesman or customer) in selecting parameter values that produce the specification of the product type most suitable. The PSS relies on the definition of items and their set-descriptions. The data that represent items and their set descriptions are called product specification data.

The BGS relies on a so-called source BOM structure. The source BOM of an item A is the set of gozinto-relationships in which A is the parent item. In the source BOM, A and its component items may contain one or more product types. The BOM structure that is obtained for a fully specified item A, by selecting and/or specifying gozinto-relationships and items from the source BOM structure of A, is called the result BOM. The result BOM structure of the fully specified item A unambiguously represents the product structure of the product type that is identified by the fully specified item A.

Continue ...

Go to table of contents.