J. ENG. DESIGN, VOL.
14,
NO.
2,
JUNE
2003, 145–167
Modelling platform-based product configuration using programmed attributed graph grammars XUEHONG DU {, JI A N X I N J I AO { * and MITCHELL M. TSENG § The rationale of platform-based product configuration has been well recognized for the implementation of mass customization. A product platform refers to the conceptual structure and logical organization of product families from both customer and technical viewpoints. This provides a generic umbrella under which product configuration manifests itself through variant derivation within common product line structures. Earlier research often highlights successful yet isolated empirical studies without attempt to discuss the more general modelling issue surrounding this economically important class of engineering design problems. This paper introduces graph grammar formalisms to the representation of a product platform and the modelling of variant derivation. The concepts of multi-pointed hyper-graph, node nesting and graph class are developed for modelling platform modules, multilevel variety origins and generic product instantiation, respectively. A programmed attributed graph grammar is used to transform customer requirements in the customer view to product family design in the technical view. Mapping relationships from the customer view to the technical view are represented in the form of production rules for graph transformation. The application conditions of productions in cooperation with control diagrams determine how a suitable variant can be derived from the base product of the platform. A case study of power supply platform modelling is also reported.
1. Introduction Facing the buyers’ market, many industries are now shifting from mass production to mass customization, which demands quick response to the needs of individual customers with high quality and acceptable costs (Pine 1993). Platform-based product configuration has received an increasing interest in recent years because, by sharing components across products, a product platform lends itself to the ability to derive a family of products that are tailored to individual customer needs along with reduced lead time and costs (Meyer and Lehnerd 1997). The platform performs as a generic umbrella under which product configuration manifests itself through variant derivation within common product line structures. Earlier research often highlights successful yet isolated empirical studies without attempt to discuss the more general modelling issue surrounding this economically important class of engineering design problem Revision received January 2003. { Artesyn Technologies Asia–Pacific Ltd, 13–15 Shing Wan Road, Tai Wai, Shatin, N.T., Hong Kong. { School of Mechanical and Production Engineering, Nanyang Technological University, Nanyang Avenue 50, Singapore 639798, Singapore. § Department of Industrial Engineering & Engineering Management, The Hong Kong University of Science & Technology, Clear Water Bay, Kowloon, Hong Kong. * To whom correspondence should be addressed. e-mail:
[email protected] Journal of Engineering Design ISSN 0954-4828 print/ISSN 1466-1387 online # 2003 Taylor & Francis Ltd http://www.tandf.co.uk/journals DOI: 10.1080/0954482031000091482
146
X. Du et al.
(Rothwell and Gardiner 1990, McGrath 1995, Sanderson and Uzumeri 1995, McKay et al. 1996). To realize mass customization, the computerization and, eventually, automation of platform-based product configuration necessitates the formal representation of a platform and the modelling of product variant derivation. Towards this end, the present paper attempts to introduce graph grammar formalisms to product platform representation and variant derivation modelling. Owing to its formality, executability, extensibility and generality in modelling and manipulation of structural and non-structural information, the graph grammar approach has been applied as a formal method to facilitate the characterization of design problems more precisely (Mullins and Rinderle 1991). The generic term ‘graph grammars’ refers to a variety of mathematical formalisms for specifying sets of graphs through manipulating symbols representing graph vertices and edges. A graph re-writing system consists of graphs (or starting graphs) and a set of operations (or productions) that can be applied to manipulate the graphs. Graphs provide an expressive and versatile data representation. Typically, nodes represent objects or concepts, and edges represent relations among them. If a system is modelled as graphs and the production rules for graph operation are designed properly, as long as users apply the pre-defined productions to manipulate a graph, then the graph produced will satisfy the characteristics of the desired system model. All of the graphs that can be derived by applying productions to the starting graph in certain order from the language of this graph grammar. In the next section, key issues of platform-based product configuration and technical challenges of its modelling are discussed. Graph grammar concepts are then related to platform representation and variant derivation modelling in section 3. Modelling formalisms are developed in section 4, while in section 5 a case study of a power supply platform and related product customization is presented to illustrate the feasibility and potential of graph grammars for platform modelling.
2. Platform-based product configuration A number of perspectives on product platforms exist in the literature. A review suggests that the product platform has been defined diversely, ranging from being general and abstract (Wheelwright and Sasser 1989, Corso et al. 1996, Robertson and Ulrich 1998) to being industry and product specific (Sanderson and Uzumeri 1995, Ericsson et al. 1996, Jandourek 1996). In addition, meaning of the platform differs in the scope. Some definitions and descriptions focus mainly on the product/artifact itself (Meyer and Utterback 1993, McGrath 1995), whereas others try to explore the platform concept in terms of a firm’s value chain (Sawhney 1998). There are two streams of research prevailing in the field of developing product platforms to support product family development. One perspective refers to a platform as a physical one, namely a collection of elements shared by several related products. Accordingly, the major concern is how to identify common denominators for a range of products (Ulrich and Seering 1990, Ericsson et al. 1996, Jandourek 1996, Wilhelm 1997, Kota and Sethuraman 1998, McAdams et al. 1999). The effort is often geared towards the extraction of those common product elements, features, and/or subsystems that are stable and well understood, so as to provide a basis for introducing valueadded differentiating features (Robertson and Ulrich 1998, Moore et al. 1999). Meyer and Lehnerd’s (1997) work may be the representative of another dominating perspective to product platforms. They defined a product platform as ‘a set of
Platform-based product configuration
147
subsystems and interfaces developed to form a common structure from which a stream of derivative products can be efficiently developed and produced’ (Meyer and Lehnerd 1997, p. 39). The major issue is to exploit the shared logic and cohesive architecture underlying a product platform. One endeavour towards product platform development is to design product families in the way of ‘stretching’ and/or ‘scaling’ (Rothwell and Gardiner 1990). The development of Boeing 7XX aircrafts epitomizes such a design practice (Sabbagh 1996). The robust design of product families is discussed in Chen et al. (1996) and Simpson et al. (1996a, 1996b). Simpson et al. (1999) proposed a product platform concept exploration method to facilitate the synthesis and exploration of certain common product platform concepts that can be scaled to generate an appropriate family of products. Siddique et al. (1998) employed graph grammars to identify the common platform for a set of similar products and to specify possible product portfolio supported by the platform. To facilitate platform-based product family development, interface management is reported as a distinct process of defining the physical interfaces between subsystems (Sundgren 1999). Set-based model is an attempt to the formal representation of product platform design and manufacturing processes (Finch 1999). While prevalent understanding of product platform refers to those shared physical components (Ulrich 1995), this research emphasizes its architectural implication—the conceptual structure and overall logical organization of generating a family of products. In other words, a product platform is a structured system creating a variety of products with shared core product technologies. The common elements may be shared physical components, customization modules, standard designs, and/or rules for generating custom designs. Such an architectural perspective in fact manifests the platform-based product configuration. 2.1. Key issues 2.1.1. Multiple views. Platform-based product configuration involves both the customer and technical views (Du et al. 2001). From the customer or sales viewpoint, the platform should reflect information on its capability in the form of the range of available features and the associated feature levels and/or options for certain product families derived from the platform. From the technical viewpoint, the product platform embodies mechanisms of variety fulfillment. 2.1.2. Generic product structure and taxonomy of modules. As the backdrop of a platform, the Generic Product Structure (GPS) refers to the generic organization of all modules that may occur in the product families of a platform. Similar to the generic bill-of-material concept (Hegge and Wortmann 1991), a generic module is an abstract module representing a family of concrete modules that are similar (i.e. variants). In general, three types of modules with regard to the origin of variety can be identified. They are fixed modules, primitive generic modules and compound generic modules. Figure 1 shows the structure of a generic product, M, representing all product variants in a family. M0 is a fixed module that is commonly shared by all products derived from the same platform, and thus is not relevant to any variety. M2 is a kind of module that has more than one variant but cannot be decomposed into any generic modules, and thus is called a primitive generic module (Erens and Verhulst 1997). These primitive variants become the origin of variety as each of them possesses more than one variant (e.g. {M(2j)}). On the contrary, M1 is a
148
X. Du et al.
compound generic module that is composed of fixed modules, primitive generic modules, and/or other compound generic products. Its variety results from different variants of its lower level component modules. As a result, a compound generic module needs to be decomposed further to facilitate the production of desired variants (Erens and Verhulst 1997). 2.1.3. Variety generation. To produce custom-built products under certain customization circumstances, some universal methods for generating variety need to be identified. Built upon the rationale of uncoupled modular product architecture (Ulrich 1995), four platform-based variety generation methods can be identified. More complicated customization can be implemented by nesting these basic methods recursively (Du et al. 2001). Attaching. A particular module carrying out certain additional functions can be attached to a base product to create a new product variant. The attachable modules should possess appropriate interfaces to the base product. Attaching appears in many situations (Ulrich and Tung 1991), such as electronic devices with optional accessories, and computer systems with peripherals, where optional accessories and peripherals exemplify attachable modules. A variety of end-products can thus be generated by attaching different attachable modules to the base product. Removing. Opposite to attaching, variant products can be derived through removal of certain modules. In most cases, a module carrying out certain functions that are redundant for a particular customer’s application can be removed to have a simplified model with cost savings. Swapping. Swapping frequently appears in practice (Ulrich and Tung 1991). In fact, it can be regarded as the combination of attaching and removing. Swapping is mostly related to variety due to different performance levels for the same function. Usually, substitutable modules should possess common interfaces to the other parts of the product. In most cases they are the variants of the same module. Scaling. This refers to the fact that the value of a certain operational parameter of the product or a module can be changed following some system models or functions. For example, the size of an office chair can be changed and is thus scaleable. In this context, scaling is related to either the whole product or only a part of the product. Nevertheless, the fundamental technology and the system structure remain unchanged. Scaling is consistent with approaches suggested by Rothwell and Gardiner (1990) and Simpson et al. (1999), in which products are regarded as scaled objects. 2.1.4. Variant derivation. A platform characterizes the architecture of product families, thus revealing the organization of product families and the derivation of product variants (Du et al. 2001). In the sales view, a product family is specified in terms of functionality, including common features, optional features, and selection constraints. In the technical view, all product variants share one GPS and are derived from the base product by manipulating distinctive modules using scaling, attaching, removing, and/or swapping. Figure 1 illustrates how product variants can be derived from the base product through the instantiation of GPS according to given family specifications.
Platform-based product configuration
149
Figure 1. Product variant derivation through GPS instantiation.
To co-ordinate variety fulfillment across different views, the conditions and sequences of module manipulation are introduced. The external, internal, and system conditions should be considered. External conditions come from customer selections and embody the mapping mechanism from customer requirements to technical solutions. Internal conditions involve constraints such as compatibility, simultaneity, and capacity constraints (Fujita et al. 1999), as well as coupling/decoupling relationships between modules. System conditions result from considerations of both design and manufacturing. 2.2. Technical challenges In light of the architectural perspective, the modelling of product configuration includes two aspects: representation of the platform and modelling of the variant derivation process. As a result, the technical challenges can be observed as follows. (1) It involves the representation of various product-specific data, such as functional features and technical parameters, and hierarchical decomposition structures, together with relationships of part-to-part and part-to-product. (2) It also involves the representation of family-related data, such as common elements and options, variety parameter instantiation, and relationships of product to product (i.e. variant to family) and family to family. (3) It should represent the mechanisms of variety generation and variant derivation, as well as those constraints relevant to the mapping relationship from the customer to technical views and relevant to configuration compatibility and precedence. (4) It should be able to synchronize variety and family representations for both the customer and technical views.
3. Graph grammars As a complex system modelling tool, graph grammars excel in describing structural information and dealing with the transformation and generation of elements in graph morphisms. With respect to architectural modelling, graph grammar concepts are summarized as follows.
150
X. Du et al.
3.1. Graph schemes Definition 1: An unattributed graph (u-graph) is a three-tuple, g ¼ (N , E, l), where (1) N is a finite set of nodes; (2) E ¼ (Ew )w2W is a tuple of relationships, Ew N N , for each w 2 W ; and (3) l: N ! V is the node labelling function (Bunke 1982, Kreowski and Rozonberg 1990).
An edge can be directed, in which the graph is a digraph, or be undirected. A pair (n, n0) is interpreted as a directed edge with label w from node n to n0. A self-loop in a graph is an edge that starts and ends at the same node. Two sets of attributes are involved, namely the set A for node attributes and the set B for edge attributes, where an attribute is a function associating attribute values with nodes or edges. Definition 2: An attributed graph (a-graph) is a five-tuple g ¼ (N, E, l, a, b), where (1) N, E, and l are the same as in definition 1; (2) a is a function that associates a set of node attributes with each node; and (3) b is a function that associates a set of set attributes with each edge (Bunke 1982, Kreowski and Rozonberg 1990). Definition 3: A multi-pointed hyper-graph (mh-graph) is a seven-tuple: g ¼ (N , E, l, a, b, begin, end ), where (1) The first five components are the same as in definition 2; (2) begin, end 2 N (i.e., a subset of N); and (3) g is a (k, l)-hypergraph, begin ¼ {b1 , . . . , bi , . . . , bk } and end ¼ {e1 , . . . , ej , . . . , el } with I 2 [1, k], j 2 [1, l]. Then EXTg ¼ {b1 , . . . , bk } [ {e1 , . . . , el } denotes the set of external nodes for g. All other nodes are internal ones (Habel and Kreowski 1987).
The mh-graph is originally introduced to explore the generative power of edge replacement. For example, a state graph of finite automation together with its initial and final states exhibits an example of mh-graph, where the external nodes of a flow diagram become its entries and exits. In the context of architectural modelling, mh-graphs enable the modelling of the hierarchical structure of systems. In addition, it allows modules of the system to be handled individually. 3.2. Graph manipulation Definition 4: The direct derivation of a graph G0 from a graph G is an eight-tuple,
