CONCURRENT ENGINEERING: Research and Applications Graph Grammar Based Product Family Modeling Xuehong Du1, Jianxin Jiao2,* and Mitchell M. Tseng3 1
Artesyn Technologies Asia-Pacific Ltd, 13-15 Shing Wan Road, Tai Wai, Shatin, N.T., Hong Kong 2
3
School of Mechanical and Production Engineering, Nanyang Technological University, Nanyang Avenue 50, Singapore, 639798
Department of Industrial Engineering and Engineering Management, The Hong Kong University of Science and Technology, Clear Water Bay, Kowloon, Hong Kong
Abstract: Many industries are shifting from mass production to mass customization, which demands quick response to the needs of individual customers with high quality and low costs. The development of product families has received an increasing interest in recent years because, by sharing components across products, a family of products can be derived to cater variety while maintaining the economy of scale. Aiming at the computerization, and eventual automation, of product family design, this paper tackles the formal representation issue surrounding this economically important class of engineering design problem. Breaking free from conventional understanding of product families, which is limited as shared components, the paper defines a product family as a structured system to create variety of products with shared core product technologies. It not only involves the shared base product, but also encompasses customization modules, standard designs, and primary patterns of variety to generate custom designs. The paper introduces graph grammar formalisms to the modeling of such a product family. Based on Programmed Attributed Graph Grammars (PAGG), the graph language is developed to specify the design space of the product family. The process of customizing the base product through manipulating particular modules is modeled by rewriting the starting graph using a series of productions according to the control diagram. Configuration constraints are dealt with by defining application conditions for production rules. Control diagrams are constructed to capture complex relationships among modules and used to control the application sequence of production rules. A case study of power supplies is presented to demonstrate the potential of the graph grammar based modeling approach. Key Words: product family, variety, modeling, graph grammar.
1. Introduction The emerging buyer’s market has resulted in products characterized by a large variety. Facing this challenge, many companies try to satisfy demands from their customers through engineering-to-order, produce-toorder, or assembly-to-order production systems (Wortmann et al., 1997). At the back end of product realization, especially on the component aspect, today we have both flexibility and agility provided by advanced manufacturing technologies such as CNCmachines. These facilities accommodate variety originating from diverse needs of customers. However, at the front end, from customer needs through product assembly, managing variety is still very ad hoc. For example, production control information systems, such as MRPII or ERP, are falling behind even
*Author to whom correspondence should be addressed. E-mail:
[email protected]
though they are important ingredients in production management (Erens et al., 1994). The difficulties lie in the necessity to specify all possible variants of a product, and in that current production management systems are often designed to support a production that is based on a limited number of product variants (van Veen, 1992). The traditional approach to variant handling is to treat every variant as a separate product by specifying a unique Bill-of-Materials (BOM) for each variant. This works with a low number of variants, but not when customers are granted a high degree of freedom in specifying products. The dilemma is that a large number of BOM structures will occur in high variety production, in which a wide range of combinations of product features may result in millions of variants for a single product. Design and maintenance of such a large number of complex data structures are difficult, if not impossible. The consequence of product variety and the associated proliferation of BOM may manifest itself through several ramifications, including increasing costs due to the exponential growth of complexity, inhibiting
Volume 10 Number 2 June 2002 1063-293X/02/02 0113–16 $10.00/0 DOI: 10.1106/106329302027635 ß 2002 Sage Publications
113
114
XUEHONG DU, JIANXIN JIAO
benefits from economy of scale, and exacerbating difficulties in coordinating product family life-cycles. Developing product families has been recognized as a means to support product variety with minimal data redundancy (Sanderson and Uzumeri, 1995; Ulrich and Eppinger, 1995; Paula, 1997; Kota and Sethuraman, 1998; Schonfeld, 1998). A number of models containing partial and complete descriptions of the structure of a product are created and utilized throughout the product development and innovation process. Research in the area of product structure is mainly presented in terms of product modeling which typically tackles detailed data related to an individual product (Krause et al., 1993). In the industry, product structures and associated coding systems usually are specific to particular product families. A company-wide product data model across various product families rarely exists (Bei and MacCallum, 1995). In the context of variety management, the modeling of product family is different from traditional product modeling in that product data have to be related to both families of products and specific product variants in a single context in order to minimize data redundancy. There exist several data relationships in product families, including part-to-part, part-to-product, product-to-product, product-to-family and family-to-family relationships. While the part-to-part relationship represents the interconnections between components, the part-to-product relationship exhibits the composition of a product in the form of hierarchical structures. The product-to-product relationship reveals the commonality among family members, i.e., product variants. The product-to-family and family-to-family relationships specify how product variants are derived from the common platform of product families in response to diverse customer requirements. To manage and utilize product families effectively, product family modeling has become crucial, especially for manufacturers who, on a routine basis, adapt their core products to accommodate the needs of individual customers, for example, in the case of mass customization (Pine, 1993). Consequently, challenges for product family modeling can be observed as follows: 1. The common structure underlying product family: Instead of a collection of individual product variants, the organization of product data needs to explicate the relationships among variants (McKay et al., 1996). 2. Derivation of product variant: An individual product (a variant) should be defined in terms of parameters of the product family and as a function of both customer specifications and product family descriptions (Erens et al., 1994). 3. Synchronization of multiple perspectives: The modeling of product family should be able to represent
AND
MITCHELL M. TSENG
product specifications in terms of functional parameters and constraints, and in the meantime, to describe end-products, subassemblies, and components, along with their relationships for engineering purposes (Erens and Hegge, 1994). Towards the end, this paper introduces a modeling framework for product families based on graph grammars. In the next section, related work is reviewed. The logical organization of product family data is discussed from an architectural perspective in Section 3. In Section 4, graph grammars are related to product family modeling. Accordingly, the graph formalism is developed in Section 5 and the graph grammar model for product family modeling is presented in Section 6. In Section 7, the development and application of the graph grammar model are illustrated through a case study of power supplies. Finally, discussions and conclusions are drawn in Section 8.
2. Literature Review Efforts in the area of product modeling are mostly devoted to detailed descriptions of individual products or parts, such as surface and solid models, and featurebased modeling (Krause et al., 1993). These modeling techniques depend on domain-specific information (e.g., geometry) and focus on physical structures (e.g., assembly). To accommodate different business functions, the standardization of various product models and thus communication protocols are advocated, for example, by efforts of STEP, IGES, DXF, and EXPRESS, as well as in Engineering Database Management Systems (DBMS) and Product Data Management (PDM). In production planning, the BOM is a widely accepted simple product model. It encodes the relationships of finished products and their constituent parts or assemblies (Smolik, 1983). Some research has recently generalized BOMs to include product families, such as the Generic BOM (GBOM) concept (Hegge and Wortmann, 1991). By introducing parameters and differentiating products with alternative parameter values, a GBOM is able to represent multiple products in a single structure. van Veen (1992) investigated GBOM-based product family modeling from the production perspective. While the GBOM aims at exploring a generic product structure and excels in describing manufacturing or production-related product information, its standpoint mainly rests on the assembly structure of a product family, which seems to ignore the design process prior to production. For variant derivation, formal representations of optional features, restrictions, selection conditions and constraints are discussed by Baldwin and Chung (1995).
Graph Grammar Based Product Family Modeling
The data structure of parametric design and the corresponding design process are studied by Malmqvist (1993a, 1993b). The initiative of Product Family Classification Tree (PFCT) emphasizes the classification of end-products and/or modules merely from a functional viewpoint (Bei and MacCallum, 1995). The implicit, if not ignored, capturing of relationships between modules and end-products hinders the PFCT to recognize the origins of variety that may result from diverse variations of functional requirements, design solutions, as well as the mapping relationships in between. To characterize variety and its derivation, Jiao et al. (2000) proposed a Generic Variety Structure (GVS), which consists of the common product structure, variety parameters, and configuration constraints. To facilitate representations from multiple perspectives, Generic Product Modeling (GPM) is advocated to represent product families from both commercial and assembly views (Wortmann and Erens, 1995). McKay and Bloor (1991) and McKay et al. (1996) tried to describe product families from both sales/customer and assembly views by merging descriptions of detailed product data with product variety. Erens and Verhulst (1997) described the architecture for product families in three domains: the required function, technological realization and the physical realization. Jiao and Tseng (1999) identified two types of constraints in dealing with variety mapping from sales to engineering domains and variety configuration within each domain. To handle variety effectively, it is necessary to synchronize product family representations for different business functions. In addition, a general modeling approach is imperative to integrate all relationships characterizing product families in a single context and in the meantime to support variant derivation in response to specific customer requirements.
3. Product Family: An Architectural Perspective A product family refers to a group of individual products that share common subsystems or components and yet possess specific functional features to satisfy a variety of market niches (Meyer and Lehnerd, 1997). Earlier studies have demonstrated the rationale of the modular product architecture with respect to catering flexibility to tailor products to custom ones (Ulrich, 1995). Instead of treating the product family simply as a bunch of individual products, the architectural perspective emphasizes the logical organization of the modules of a product family and the interpretation of such logical organization from both sales and engineering perspectives. In other words, the underlying architecture of a product family defines both what is common and what is distinctive among family members,
115
as well as mechanisms with which some product variants can be derived. Major issues regrading the understanding of a product family are discussed as follows. 1. Product family specification From the viewpoint of sales, a product family is specified by a set of common features along with a set of optional features. Specific product variants are defined by the combination of common features and certain selected optional features. While common features capture the similarity of customer requirements from the target market, optional features address the differentiation of requirements for different customers. Since some combinations are not technologically feasible or economically reasonable, there exist constraints on the selection of optional features, thus referred to as selection constraints. 2. Generic product structure The Generic Product Structure (GPS) of a product family refers to the generic organization of all modules that may occur in the family (Du et al., 2001). Similar to the GBOM concept, a generic module is an abstract module that represents a family of concrete modules that are similar. Two categories of concrete modules can be observed, namely, common modules and distinctive modules. While common modules are employed by every variant of the product family, distinctive modules are those modules making product variants different from one another. Two types of distinctive modules can be identified with respect to the hierarchical product decomposition structure: primitive modules and compound modules. The first type refers to those modules that cannot be further decomposed. Each of them possesses several variants. The second type is composed of common modules and/or primitive modules. A compound module may be used as a child module to compose another compound module (i.e., parent module), that is, to be employed recursively. In this sense, the endproduct itself is in fact a compound module. The variants of a compound module result from variations of its child modules. They are derived by manipulating the distinctive modules of these child modules. The hierarchical structure of products can be regarded as the decomposition of compound modules at various levels of abstraction. The generation of a variant for the end-product can be viewed as a recursive process of generating the variants for a series of compound modules contained by the end-product. 3. Base product Common subsystems or components, from which a variety of product variants can be derived, are usually embodied as a base product. In practice, the base product may manifest itself through many forms. It may be a product with basic functionality, a semi-finished product, or a standard product that fulfils the requirements of the majority of customers. From the engineering viewpoint, the base product embodies the commonality within a product family.
116
XUEHONG DU, JIANXIN JIAO
The advantages of adopting base products include avoiding the technological risk, reducing costs, and achieving quick response to the market. 4. Variety generation To produce custom-built products under certain customization circumstances, some universal methods for generating variety need to be identified. It has been assumed that the modular product architecture (Ulrich, 1995) can contribute to product family design. Modules in this context may be a set of physical parts or a group of logical units that cater for certain functions. Product variety can thus be achieved through combinations of modules. In addition, any change of modules in order to produce a custom product will not induce a high cost or substantial changes of the other parts of the product. Because the GPS of a product family is built upon the hierarchical decomposition of every compound module, variety generation methods are defined for each compound module and are specified how variety of a compound module is created by manipulating its child modules. Based on these assumptions, four basic variety generation mechanisms can be distinguished, including attaching, removing, swapping (for details see Du et al., 2001). 5. Product variant derivation The architecture of a product family reveals the organization of the family, as well as how product variants are derived. In the sales view, a product family is specified in terms of functionality, including common features, optional features, and selection constraints. In the engineering 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. Du et al. (2001) formulated procedures for deriving product variants from the base product through the instantiation of GPS according to given family specifications.
4. Graph Grammars for Product Family The term ‘graph grammars’ generally refers to a variety of methods for specifying (possibly infinite) sets of graphs (IWGG, 1987). Graphs and graph-like structures are used for representing the structure of complex systems to provide an expressive and versatile data representation. Typically, nodes represent objects or concepts, edges represent relationships among them, and node or edge attributes represent nonstructural information associated with the objects or relations. Possible manipulations are replaced by production rules. All graphs that can be derived by applying productions to a starting graph form the language of this graph grammar. If a system is modeled as graphs, assuming that the productions are designed properly, as long as the user employs the defined productions
AND
MITCHELL M. TSENG
to manipulate a graph, then the graph produced will satisfy the characteristics of the desired model. Graph grammars model realistic systems at an abstract level and combine the advantages of intuitive understanding with mathematical rigorousness (Blostein, et al., 1994). Prior work demonstrates that, as a modeling tool for complex systems, graph grammars excel in describing both structural and nonstructural information and in dealing with the transformation and generation of elements of the modeled system. Owing to its advantages proven in many applications, this research adopts graph grammars as a tool to model the elements of a product family. The strategy of graph grammar based product family modeling is to design graph grammars to represent the organization of product family elements and accordingly to transform the variant derivation process into a process of graph derivation. To map the entities of product family to the elements of graph grammars, products, base products, distinctive modules are represented as graphs. Modules are modeled as nodes, the interconnections between these modules as edges, and the parameters of modules as node attributes. Module manipulations and the associated conditions regarding when manipulations should be performed are modeled as operations and application conditions of production rules, respectively. Adopting the concept of Programmed Attributed Graph Grammar (PAGG) (Bunke, 1982; Blostein et al., 1994), the sequence of executing a set of productions can be explicated in a control diagram. The static description of product family comprises these graph grammar notations. Based on this static description, product variants of the family can be derived by applying production rules according to the control diagram to modify the starting graph which is the graph representing the base product. The resultant graphs are the graph models of desired variants. All these graphs make up the graph language of this graph grammar, which comprises the design space of the product family to be modeled.
5. Graph Formalism Products inherently possess structures that are suitable to be represented as graphs (Mullins and Rinderle, 1991). A product is composed of a set of interrelated modules. Each module is characterized by a set of parameters. These modules interact with one another to carry out certain tasks in order to fulfill the functionality of the product. Let V and W be the two alphabets for labeling nodes and edges, respectively, and set, A, denote the attributes of nodes. An attributed graph consisting of a finite set of nodes and edges can be defined. If V is composed of
Graph Grammar Based Product Family Modeling
the names of modules, W of the types of relationships between modules, and A of the parameters of modules, an attributed graph can be used to represent a product consisting of modules. Definition 1 An attributed graph (a-graph), ga, representing a product can be specified by a 4-tuple, denoted as: ga ðN, E, , Þ, where 1. N is a finite set consisting of nodes representing the modules of the product; 2. E ¼ ðEw Þw2W is a tuple of relationships, Ew N N for each w 2 W, representing relationships between modules. A pair ðni , nj Þ 2 Ew , is interpreted as a directed edge with label, w, from node, ni (related to Mi), to node, nj (related to Mj). 3. : N ! V is a node labeling function; and 4. (ni) is a function that associates a set of node attributes with node, ni. 5.1
Encapsulated Graph
To characterize external interfaces and internal structures of modules, the encapsulated graph is adopted. The concept of encapsulated graph was first introduced by Engels and Schu¨rr (1995). It is used to describe different abstraction levels of hierarchical systems. We define the encapsulated graph in terms of modeling modules at different levels of abstraction of the hierarchical structure of products. Definition 2 An encapsulated graph (e-graph), g, representing a module, M, is specified by a 7-tuple, denoted as: g ðKN, N, KE, E, CPN, PRN, CMNÞ, where 1. KN(g) ¼ KN is a set, consisting of known nodes in g, which correspond to all the modules contained by or connected to M, thus referred to as child modules or context modules, respectively. KN 6¼ 6 0; 2. N(g) ¼ N is a set, encompassing all nodes belonging to g and corresponding to all the child modules of M. NKN, N 6¼ 6 0; 3. KE(g) ¼ KE KN KN is a set, consisting of known edges in g; 4. E(g) ¼ E N N is a set, encompassing all edges that belong to g. E KE; 5. CPN(g) ¼ CPNN is a set, encompassing all compound nodes that correspond to the compound child modules of M;
117
6. PRN(g) ¼ PRN N is a set, encompassing all primitive nodes that correspond to the primitive child modules of M; 7. CMN(g) ¼ CMN N is the set of all common nodes corresponding to the common child modules of M; and 8. N(g) ¼ CPN(g) [ PRN(g) [ CMN(g). The following abbreviations are needed in the sequel: 1. CN(g) ¼ KN(g)\N(g) is a set, comprising all context nodes in g; 2. CE(g) ¼ KE(g)\E(g) is a set, comprising all context edges in g; and 3. G(M) denotes the e-graph of module, M. Definition 2 can be used to represent any category of modules in a product family: 1. If CPN(G(M)) [ PRN(G(M)) ¼ 6 0, M is a common module; 2. If |N(G(M))| ¼ 1, M is a primitive module; 3. If |N(G(M))| > 1, M is a compound module; and 4. If |N(G(M))| > 1 and CN(G(M)) ¼ 6 0, M is an endproduct. Therefore, each module can be represented by an e-graph. A child module represented as a node in the e-graph of its parent module can be elaborated using its own e-graphs. Such a recursive representation is referred to as node nesting (Harel, 1988; Sindre et al., 1993). 5.2
Production
Based on the modular product architecture, product variety can be fulfilled through various combinations of modules (Ulrich, 1995). In addition, variety may result from topological modification or variation of node attributes. Since products and modules are represented by e-graphs, variety generation is modeled by specifying state transformations of the associated graphs. This is achieved by applying productions to original graphs. A production consists of two elements: the operation and its application conditions. The operation, O (gl, gr, T, F, ), indicates how the left-hand side (LHS) graph, gl, is replaced by the right-hand side (RHS) graph, gr, with respect to embedding transformation, denoted by T, or attribute transformation, denoted by F. Application conditions specify when an operation should be performed. They can be expressed as functions of customer selected features or feature values, or parameters of the parent module. When the application conditions of a production are satisfied, the applicability predicate, , is true. In fact the first four elements together define the operation on the host graph by replacing gl with gr, whereas the last element specifies the condition under which the operation can be performed. While graph operation is related to module manipulation, application conditions are
118
XUEHONG DU, JIANXIN JIAO
related to synchronizing multiple views of variety. For clarity, we first define operations for product family as follows. Definition 3 Attaching (denoted as atta) a module, M, to a base product, PD0, is equivalent to attaching the e-graph, G(M), to the host graph, g ¼ G(PD0), as long as there are the equivalent of the context nodes of G(M) in G(PD0). It is specified by a 3-tuple: (gl, gr, T ), denoted as: attaðG 1 ðGðMÞÞ ¼ attaðMÞ, where 1. G 1(gr) indicates the module represented by the e-graph of gr. This notation will be used in the same way in sequel; 2. gl ¼ CN(G(M)). It is a subgraph of g and is composed of the context nodes of G(M), which implies that the base product provides interface to module M to be attached; 3. gr ¼ G(M); and 4. T ¼ (gl, CN(gr)). This embedding transformation function specifies that all the edges connected to the nodes in gl will be connected to the corresponding nodes in gr. For example, an operation for attaching module, M5, to the base product, which is composed of modules, M1, M2, M31 , and M4, can be described as: attaðM5 Þ ¼ ðgl , gr , TÞ: gl ¼ CNðGðM5 ÞÞ: gr ¼ GðM5 Þ:
T ¼ ðgl , CNðgr ÞÞ:
M5 is connected to the base product via M2 and M31 , which become the interface of M5 to the base product. Definition 4 Removing (denoted as remo) a module, M, from a base product, PD0, is equivalent to removing the e-graph, G(M), from the host graph, g ¼ G(PD0), but keeping the context nodes of G(M) in the resultant graph. It is specified by a 2-tuple: (gl, gr), denoted as: remoðG 1 ðGðMÞÞÞ ¼ remoðMÞ, where 1. gl ¼ G(M); and 2. gr ¼ CN(G(M)). It is composed of the context nodes of G(M) and is a subgraph of the resultant graph. Definition 5 Swapping (denoted as swap) is to replace a module, M 0, in a base product, PD0, with a module, M, that shares with M 0 the same interface to the other parts of the product. It is equivalent to substituting the e-graph G(M) for G(M 0) in the host graph, g ¼ G(PD0), as long as G(M) and G(M 0) possess the same context nodes. It is a 3-tuple: (gl, gr, T), denoted as: swapðG 1 ðGðMÞÞÞ ¼ swapðMÞ,
AND
MITCHELL M. TSENG
where 1. gl ¼ G(M 0); 2. gr ¼ G(M); 3. CN(gr) ¼ CN(gl). It implies that M and M 0 have the same interface to the other parts of the product; and 4. T ¼ (CN(gl), CN(gr)). This embedding transformation function specifies that all the edges connected to the context nodes of gl will be connected to the corresponding nodes in gr. For example, an operation for swapping module, M31 , with M32 in the base product, which is composed of modules, M1, M2, M31 , and M4, can be described as: swapðM32 Þ ¼ ðgl , gr , TÞ: gl ¼ GðM31 Þ: T ¼ ðCNðgl Þ, CNðgr ÞÞ:
gr ¼ GðM32 Þ:
Through this operation, M31 is replaced by M32 . Definition 6 Scaling (denoted as scal) is to change the parameters of module, M. It is equivalent to changing the attributes of the node, N(M), in the host graph, G(M). N(M) is the node associated with M, whereas the topology of the graph remains unchanged. A swapping operation is specified by a 3-tuple: (gl, gr, f ), denoted as: scalðG 1 ðGðMÞÞÞ ¼ scalðMÞ, where 1. gl ¼ gr ¼ G(M); 2. nl ¼ nr ¼ N(M)2N(G(M)), (nl ) 6¼ (nr ); and 3. f is the attribute transfer function of node, N(M). For example, an operation for scaling module, M2, in the base product, can be described as: scalðM2 Þ ¼ ðgl , gr , f Þ: gl ¼ gr ¼ GðM2 Þ: ðNðM2 ÞÞ ¼ f ððNðParentÞÞÞ: Through this operation, the attribute of M2 is changed from A2 ¼ (N(M2)) to A02 ¼ ðNðParentÞÞ: After defining the operations used to modify graphs for variety generation, conditions under which the operations can be performed have to be specified, that is, when modules should be attached, removed, swapped, or scaled. Application conditions are introduced for this purpose. When application conditions are satisfied, the applicability predicate, , is true. Application conditions can be expressed as functions of customer selected features or feature values, and/or parameters of the parent module. Definition 7
A production is defined as a 2-tuple: p ðO, Þ,
Graph Grammar Based Product Family Modeling
where 1. 8O 2 fatta, remo, swap, scalg is the operation. If operations other than atta, remo, swap, and scal are needed, they can be added to the set; and 2. 8 2{TRUE, FALSE} is the applicability predicate, which is a logic function of application conditions. A few examples of production are given below, where Fj indicates feature, j, of the product and (Fj) indicates the value of Fj: P1 ¼ ðscalðM2 Þ, TRUEÞ, iff jðF2 Þj 6¼ 12; P2 ¼ ðswapðM62 Þ, TRUEÞ, iff ðF4 Þ ¼ HIGH; P3 ¼ ðattaðM7 Þ, TRUEÞ; P4 ¼ ðattaðM7:1 Þ, TRUEÞ, iff ðF5 Þ 2 ffSCg, fSC, OVgg: In the above productions, p1 defines a production to modify the parameter of module, M2, if the absolute value of feature, F2, is not equal to 12. Production p2 is used to replace module, M62 , with a module, which possesses the same interface to the base product.p3 and p4 are two productions for attaching modules. By applying p4 , M7.1 will be attached to the base product as long as F5 takes a value of either {SC} or {SC, OV}. The application condition of p3 is always true, which means that M7 is a mandatory module for the product and thus should be attached under any condition. 5.3
Graph Derivation
Deriving a product variant may involve more than one step of modification of the base product. The sequence of performing modifications is determined by the coupling/decoupling relationships among the associated modules. The process of modifying a base product to a custom one can be modeled as a series of graph derivation by executing certain production rules. Definition 8 The direct derivation of a graph, g0, from a graph, g, by means of a production, p, is defined by the following procedure: 1. Test – Check whether gl is a subgraph in g, i.e., g: gl ! g, and check if the application condition is true. If both conditions are fulfilled go to step 2. 2. Replacement – Replace gl , including all incoming and outgoing edges, with the nodes and edges of gr. 3. Embedding – Transform the embedding of gl in g into gr in g0. 4. Attribute evaluation – Attaching attributes to the inserted RHS graph, gr, according to the function, f.
119
Definition 9 Graph derivation manifests itself through the sequence of n 0 direct derivations. 5.4
Control Diagram
Usually, a number of productions will be involved in the process of graph derivation. The order for a collection of productions to be invoked is specified by the control mechanism, which can be expressed in a variety of forms. Diagrammatic control specification excels in being easy to read and flexible to extend, thus adopted as follows. Definition 10 The control diagram in the graph grammar of a compound module expresses the order of productions defined for this compound module to be executed. If P is a finite set of productions, I is the initial node and F is the final node, a control diagram over P, denoted as C, is an attributed graph (a-graph) specified as a 3-tuple: C ðV 0 , W 0 , A0 Þ, where 1. V 0 ¼ P [ {I, F}. It is a set of node labels; 2. W 0 ¼ {Y, N}. It is a set of edge labels, denoting the edges connecting a node to its successor; and 3. A0 ¼ {Reached}. Reached is the attribute of nodes labeled as pi 2P. Furthermore, the following conditions hold true: 1. 2. 3. 4.
There There There There
exists exists exists exists
only one initial node, nI , labeled as I; only one final node, nF , labeled as F; no edge terminated with nI , and no edge originating from nF .
The attribute Reached is an integer variable. Its initial value indicates the total number of times that a production might be invoked during a single derivation process. Every time when the production is invoked, the number will reduce by 1. If the number equals to 0, the node should not be included in any successor of the node to which the edge is pointing. This property in particular is useful to avoid any unpredicted loop in the control diagram. To map customer selections to a variant design, the checking of application conditions should start from the production that is the label of a direct successor of the initial node. If the application condition is true, this production will be applied. Otherwise, the production that is the label of another direct successor of the initial node should be checked. Once the final node is reached, a graph representing a variant that meets the requirements can be derived. If lack of outgoing edges, the continuation of the current derivation sequence
120
XUEHONG DU, JIANXIN JIAO
cannot be defined, the graph derivation process thus aborts, and no graph is generated.
6. Product Family Modeling
AND
MITCHELL M. TSENG
4. S is the starting graph representing the base product of M; 5. P ¼ {p} is a set, encompassing all production rules defined for manipulations of distinctive modules to generate the variants of M; and 6. C is the control diagram over P, specifying the order by which productions are applied so that the variants of M can be derived.
In the graph grammar model of a product family, the base product is related to the starting graph. The process of customizing the base product through attaching, removing, swapping, and/or scaling of particular modules can be modeled by rewriting the starting graph using a series of productions according to the control diagram. Configuration constraints can be dealt with using the application conditions of production rules. Control diagrams are constructed to capture complex relationships among modules and used to control the application sequence of production rules. The derived graphs represent the desired variants. While all variants comprise the family, the design space of product family is described by the graph language of this graph grammar.
Figure 1 gives an example of the PAGG model of compound module, M. Figure 1(a) shows the generic structure of M, including all possible variants of M. While M1 and M4 are common modules, M2, M3 and M5 are primitive modules. Figure 1(b) describes the base product, from which the variants of M can be derived through attaching M5, scaling the parameter of M2, or swapping M31 with M32 . M31 and M32 are two variants of M3. Therefore, the PAGG of M can be formulated as:
6.1
where
Graph Grammar Model
The underlying architecture of a product family is manifested by the GPS. There may be one or more compound modules associated with the GPS. Each compound module possesses its base product, distinctive modules and certain methods regarding how to modify the base product to generate the variants of this compound module. The resultant variants form the family of the compound module. A compound module can be defined at either the end-product or subassembly level, thus becoming the basic construct of GPS for characterizing product family (Du et al., 2001). The graph grammar for compound modules is defined below. A Programmed Attributed Graph Grammar (PAGG) is defined by six elements. They are node labels, edge labels, node attributes, a starting graph, productions, and the control diagram. Therefore, the graph grammar for a compound module, M, is a 6-tuple, denoted as: GðMÞ ðV, W, A, S, P, CÞ, where 1. V ¼ {Mi} is a set, consisting of node labels (i.e., names) of all child modules and context modules associated with M, i ¼ 1, 2,. . .,N(G(M)); 2. W ¼ {Mi Mj} is a set, consisting of edge labels that indicate the relationships between the child modules of M, i, j ¼ 1, 2,. . .,N(G(M)); 3. A is a set, consisting of node attributes representing parameters of child modules;
GðMÞ ðV, W, A, S, P, CÞ
1. 2. 3. 4.
V ¼ {M1, M2, M3, M4, M5}; W ¼ {s}; A is a set of node attributes; The starting graph, S, in Figure 1(c) is the graph representation of the base product; 5. P ¼ {p1 , p2 , p3 }, as shown in Figure 1(d); and 6. The control diagram, C, is shown in Figure 1(e). There are three possible through paths in the control diagram, as shown in Figure 1(f). Starting from the starting graph and applying the productions sequentially yield the graphs of product variants, as shown in Figures 1(g)–(i). In addition to the base product, there are three members in the family of M, i.e., V 1, V 2, and V 3. Based on the above PAGG defined for compound modules, the graph grammar model of product family can be defined as: GGðPFÞ fGðMÞg, where {G(M)} is a set, consisting of graph grammars defined for all compound modules in the GPS of the product family. If the end-product employs common modules only, or primitive modules only, as its child modules, then GG(PF) is equivalent to G(M) since there is only one compound module, that is, M becomes the end-product itself. For complex products, more than one compound module will be involved for child modules. In such a case, each compound module itself can be modeled as a product family. As a result, GG(PF) consists of those graph grammars defined for all compound modules, including the end-product.
121
Graph Grammar Based Product Family Modeling M4
α(N(M2)) =A2
M M
GPS
M31
M1
4 M1
M2
M4
M3
M5
1
1
3
M5
M2
(a) Generic structure
(g) Variant #1: V1 P1
S → g (V 1 )
2 M4
(c) S: starting graph p1 = (atta(M5 ), π5)
Y
p1 1
M32
M2 (h) Variant #2: V2 M4
P1
S → g (V 1 ) Y
F
M4
M1
g (V 2 )
→ g (V 3 ) S →
(b) Base product
Y
3
P2 , P3
P2 , P3 , P1
2 p2
I
S
α(N(M2 )) =A2 M2
(d) Productions
p3
M31
M1
p2= (scal(M2), π2) p3= (swap(M32), π3)
α(N(M2)) =A2’
P2 , P3
→ g (V 2 ) S
α(N(M2)) =A2’ M32
M1
P2 , P3 , P1
Y
S → g (V 3 )
(e) C: control diagram
(f) Graph rewriting
M2
M5
(l) Variant #3: V3
Figure 1. Graph grammar model for a compound module.
6.2
Product Variant Derivation
The hierarchical structure of products can be regarded as a collection of compound modules organized at various levels of abstraction. The derivation of product variants becomes a recursive process of generating the variants of all compound modules. Suppose the hierarchy of a GPS has L levels (L 1). The variants of a compound module at level j (1 j
