PRODUCT PLATFORM DESIGN: A GRAPH GRAMMAR APPROACH

Proceedings of DETC 99: 1999 ASME Design Engineering Technical Conferences September 12-16, 1999, Las Vegas, Nevada DETC99/DTM-8762 PRODUCT PLATFORM DESIGN: A GRAPH GRAMMAR APPROACH Zahed Siddique Graduate Research Assistant David W. Rosen Associate Professor George W. Woodruff School of Mechanical Engineering Georgia Institute of Technology Atlanta, GA 30332-0405 Email: david.rosen@me.gatech.edu Tel:(404)-894-9668 ABSTRACT The current marketplace can be characterized by the need for variety, faster time to market, and decrease in cost. To survive companies are shifting from a mass production mode to mass customization to provide the necessary variety. One of the key elements of mass customization is the product platform. In this paper we will investigate the use of graph grammars to develop common platforms for a set of similar products and to specify the product portfolio supported by the platform. To facilitate development of common platforms a formal product family architecture representation is presented which separates the core and the options to facilitate the identification of the common platform. Graphs are used to represent the core for function and structure viewpoints, and grammars to specify the relationships among the core and the options. Arguments on suitability of graph grammars in common platform development, are also presented in the paper. 1 INTRODUCTION The need for variety has many companies extending their product portfolios to target different market segments. New models are introduced in the market more frequently and the number of mass-produced models is decreasing (Schile and Goldhar 1989). If the extension of the product portfolio is not well thought, then it leads to component proliferation and introduction of new assembly and manufacturing lines. This need for a strategy has given rise to the new concept of mass customization. One of the basic elements in applying mass customization to a product line is the concept of common product platform. A product platform is defined as: A product platform is a collection of the common elements, especially the underlying core technology, implemented across a range of products, (McGrath 1995). A well defined product platform is required to provide mass customization. Focusing product strategy at the platform level simplifies the product development process because there are fewer platforms than products and major platform decisions are only made every few years. Researchers have indicated the use of different methods to develop product families, but do not give any formal structure to represent product family. This paper is an attempt to introduce formalism to product family representation. Currently, there is no well defined design process for developing family of products, but there are several widely used design processes for designing single products (Ulrich and Eppinger 1995; Pahl and Beitz 1996). Most of these processes suggest investigation of customer need and then transforming the customer needs to product requirements, which are then used to specify function structure for the product. The function structure can then be transformed to structure viewpoint using formal languages. Some of the formal languages that have been used are shape grammars, string grammars, graph grammars etc. Agarwal and Cagan (1997, 1998) demonstrated the use of shape grammars to generate a wide range of coffeemakers. Graph grammar and a formal product family architecture representation are used here to develop common platform for a product family and to specify the varieties supported by the platform. The function structures and product architectures are defined by using graphs that explicitly represent product elements in different viewpoints and relationships among these elements. The idea is to use alternate syntax rules to generate the necessary product varieties from the core at any given viewpoint. Conversions from functional viewpoint to other viewpoints are also achieved according to syntax rules. These rules constitute the grammar, which along with the core defines a discrete product design space where the members of the space represent architectures of the different variety. To add formal structure to product family design we highlight some of the characteristics of the platform commonization problem and 1 Copyright 1999 by ASME

introduce the concept of a Product Family Reasoning System (PFRS) being developed to design product families using platform strategy. In this paper we will demonstrate the use of graph grammars in designing family of products. Use of graph grammars to capture the different characteristics of product family design will also be discussed followed by a discussion on the use of graph grammar to specify the product family architecture and to identify common platform for several existing products. The use of graph grammars to provide the necessary product varieties is part of a PFRS to address: (1) How to design common platforms for a family of products? and (2) How to synthesize and reason about the variety that can be supported from the common platform? In the next section we will give a brief overview of some of the product family design concepts and the use of grammars in design. An introduction to the platform commonization problem followed by an brief introduction to our PFRS will be provided in Section 3. In Section 4 we will outline how different product family concepts can be represented using graph grammars. An coffeemaker product family example will be used to demonstrate the use of grammars for product family design and platform commonization in Section 5. We will present our concluding remarks and future directions for this research in the final section. 2 BACKGROUND The main focus of this paper is on product family design using graph grammar approaches. In this section we will give a brief overview on some of the research performed on product family design. Use of grammars in the product design process will also be presented along with some of the basic concepts on graphs and grammars. 2.1 Product Family Design Design for product variety is a relatively new research field, but it has received considerable attention in the management (Baker et al. 1986; Sanderson and Uzumeri 1992) and engineering (Rothwell and Gardiner 1990; Ishii et al. 1995; Ulrich and Eppinger 1995; Simpson et al. 1997) literatures. The basic concept of a family of products or multi-products approach is to obtain the biggest set of products through the most standardized set of base components and production processes (Stadzisz and Henrioud 1995). Characteristics of product family range from flexible modular designs (Chen et al. 1994) to robust and scaleable designs (Rothwell and Gardiner 1990) to standardized, flexible products (Uzumeri and Sanderson 1995). Martin and Ishii (1996) identified commonality, modularity and standardization; Rothwell and Gardiner (1990) emphasized robust design; Simpson et al. (1997) related change in form and function to highlight mutability, modularity and robustness, which they suggest are the core characteristics of product families. Some of the other characteristics that have been stressed in other literatures for designing product families are: commonality (McDermott and Stock 1994; Ishii et al. 1995), modularity (Ulrich and Tung 1991; Pimmler and Eppinger 1994; Newcomb et al. 1996), and standardization (Ulrich and Eppinger 1995). In a earlier study we investigated application of different mass customization concepts to automotive platform commonality (Siddique et al. 1998). Different approaches to providing families of products through the use of common platforms have been proposed. Wheelwright and Clark (1992) suggest designing platform projects that are capable of meeting the needs of a core group of customers but are easily modified into derivatives through addition, substitution and removal of features. McGrath (1995) also stresses the need for a well designed product platform for a family of products. Parts commonality has been viewed as a means of cost reduction (Baker et al. 1986). McDermott and Stock (1994) in their paper describe how the use of common parts can shorten the product development cycle for savings in both time and money in the manufacturing process. Having a common assembly and manufacturing process is another important aspect of developing common product platforms. MacDuffie et al. (1996) looked at how variety affected manufacturing within the automotive industry by studying empirical data. 2.2 Grammatical Approaches and Design A grammar defines the elements and syntax of language, whether the language is English, a computer programming language, a shape language or a mechanical design language. The grammar provides a framework upon which to interpret the language. The interpretations of a language are based upon syntactical information gained from grammatical analysis and lexical information inherent in the individual components (Mullins and Rinderle 1991). Grammars can be used to generate sentence forms (sentence forms could be strings, graphs or various types of shapes) or to parse sentences to check for syntax and inclusion in the language. Based on the form of rewriting rules, called productions, Chomsky (1957) categorized grammars into four types regular, context free, context sensitive and recursively enumerable. In this paper we will focus on context sensitive grammars that have productions in the form uαv uβv, where α is rewritten by β in the context provided by u and v, which can be any sentence fragments (Lewis and Papadimitriou 1981). α and β can be strings of symbols or graph fragments with the limitation α β. We will now present the formal development of graph grammar by defining terms and stating restrictions based on the development in Ehrig (1978). A graph grammar is a grammar rewriting system expressed as a quadruple: GG = ( n, a, R, S) Where: n = alphabet of node labels a = alphabet of arc labels R = set of graph productions S = start graph 2 Copyright 1999 by ASME

Seat Leg 1 Leg 2 Leg 2 (a) combining two legs with a seat to make chair Leg 1 Seat Leg 2 Support Leg 1 (c) graph generation Seat Support Leg 2 Leg 1 Leg # A graph is defined as: G = (N, A, M, J) Where N = a set of nodes A = a set of arcs M = (M n, M a ) = a pair of labeling mappings, M n :N n and M a :N a J = (s, t) = a pair of adjacency mappings s:a N gives source nodes for an arc and t:a N gives target nodes for an arc In Figure 1 we have shown an example application of some of the graph grammar concepts. A subgraph H = (N h, A h, M h, J h ) of a given graph G is a subset of the nodes and arcs of G, N h N g and A h A g, along with corresponding restrictions on the mappings s, t, M n and M a. This definition becomes more specific by defining an injective graph morphism. Injective means there are 1-1 maps from nodes, arcs and labeling functions of H to nodes of G. A graph grammar production is defined as p=(b 1, B 2, K, b 1, b 2 ) where B 1 and B 2 are the left and the right hand side graphs, respectively, K is the interface graph, and b 1 and b 2 are injective graph morphisms which map K into B 1 and B 2, respectively. A direct derivation of a child graph H from a parent graph G via a production p is denoted by p:g H. A derivation sequence is a sequence of direct derivations that start from the graph G and end with H denoted as G *H', where * denotes the reflexive, transitive closure of. With some of the basics of graph grammar defined we will now highlight some of the researches involving applications of formal language theory to design. Shape grammars (Stiny 1975) have been used successfully in generating architectural designs (Stiny and Mitchell 1980). More recently Agarwal and Cagan (1997; 1998) have used shape grammars to generate coffeemaker designs. Fitzhorn (1990) developed graph grammars for describing the topology of 3-D models. Variations of graph pattern matching and graph grammars have been extensively used in feature extraction from solid models - Fu and de Pennington (1991) used symmetric string grammars to recognize holes, Rosen et al. (1994) used graph grammars parsing to convert feature based design representations. Schmidt and Cagan (1995; 1996) used hierarchical ordering of Seat Seat Support Leg # (b) grammar production Σ n = {Seat, Leg 1, Leg2} Σ a = {Support} (d) node and arc alphabets Figure 1- Example Application of Graph Grammar Concepts grammar based-design generation processes for optimization and design space characterization. 3 COMMON PLATFORM DEVELOPMENT From a general perspective (in most cases) all products have platforms and a set of similar products have the potential to be produced from a common platform. Development of common product platforms, in general, has a component perspective and an assembly process perspective associated with it. The component perspective specifies the common components present and different relationships among them. The assembly process perspective specifies assembly information, which will be used to specify if all the members of the family can be produced from the same assembly line. One of the objectives of developing common platform is to use the same assembly line to provide the necessary varieties. In this paper we will only concentrate on the component perspective of the platform commonization process. In the rest of this section we will give an overview of our product family reasoning system that is under development. The work presented in this paper reflects some of our developments pertaining to common platform design and providing the necessary variety from the platform. 3.1 PFRS A Design for Product Variety Approach The primary technology development goal for this research is to develop a product family reasoning system founded on discrete mathematics which enables the production of several related products from a common base for different market segments. The focus is on the design of product platforms, within the configuration design stage - configure product and platform structures to meet design requirements, to satisfy constraints on manufacturing capabilities, and to achieve targets on manufacturing cost and lead-time. We call our design method, for enabling product variety, the Product Family Reasoning System (PFRS). Activities that will be involved in PFRS are shown in Figure 2. Two problem types are being investigated: 1. Platform Commonization (PC) Design Problem (i) determination of which components and modules are common and their common spatial and interface relationships; (ii) determination of the common assembly process for the product family; 2. Platform Supported Product Variety (PSPV) Design Problem determination of which product varieties can be supported by the common product platform. At a very high level in PC problem of PFRS a common design space for platform architectures is generated to identify the common platform architecture and assembly process associated with it. During the PSPV phase a feasible product variety space for the common platform, requirements, constraints and assembly process is generated and then product architectures that are in the feasible space can be enumerated. Product structures are primarily discrete, rather than continuous, constructs. That is, a product structure is represented by 3 Copyright 1999 by ASME

elements (component, modules) that have relationships with one another (fastening, spatial, exchange of physical quantities, etc.), rather than a set of variables that take real numbers as values. This reasoning system is based on set theory and combinatorics. During PC problem formulation, constraints of the product family are modeled using discrete mathematics to identify the common platform spaces for different viewpoints (components, connections among components, etc.). Different assembly attributes will also be considered to formulate other viewpoints. The reasoning system will consider multiple important viewpoints simultaneously to identify the architecture of the common platform. During later stages of the PC problem the reasoning system will also be able to specify the assembly process associated with the common platform. During the PSPV problem the PFRS will be involved in identifying the product varieties that can be supported by the common platform. Solving this problem involves modeling the flexibility of the platform components and the platform as a whole. The PSPV problem will be helpful in specifying what varieties can be supported from the common platform. As an example imagine a new car is being designed given that its requirements have been identified already, the solution to this PSPV problem can help determine which common platform (if any) will be the most suitable. In this section we presented our vision for PFRS, as stated earlier we have only investigated some parts of PFRS. In Section 5 we will demonstrate the use of graph grammars in different stages of PFRS (PC and PSPV problem) using a coffeemaker product family. 3.2 Product Family Architecture Representation To design a family of products provisions must be made for different configurations of the product to support different functions. The objective of PFRS is to determine the common platform of the product family (PC) and the product family architecture (PSPV) to provide the necessary configurations. Formal product family architectures is defined starting with a definition of a product architecture: PA (Product Architecture) = <C, M, Rc, Rm> where: C = set of components in the product, M = set of modules Rc = set of relationships among components, Rm = set of relationships among modules. The relationships represented by Rc and Rm are relationships in different viewpoints (function, structure, water flow, etc.) as well as others that are found to be relevant to product family architecture design. Each relationship will have a corresponding mathematical relation. PFA (Product Family Architecture) = <Core, Options> where: Core = <C, M, Rc, Rm>, this is the same as a product architecture and represents the common platform; Options = <C o, P, Rc o, Rm o > Platform Commonization Existing Product Architectures Requirements Constraints Relationships Platform Supported Product Variety Limitations of Assembly Tools and other factors Modeling Scheme Modeling Scheme Common Platform Design Spaces Component Viewpoint Assembly Viewpoint Modeling Scheme Feasible Product Variety Space Mathematical Tools Mathematical Tools Family of Products Common Platform Architecture Common Platform Assembly Process Figure 2 - Activities in Product Family Reasoning System where: C o = set of all optional components, P = set of optional components arranged into options = {Pi Pi = {a,b,c,...}, a,b,c C o, i is counter for number of options} Rc o, Rm o are relationships among optional components and modules. That is, P consists of sets of optional components, where one component from each set must be selected for one particular product architecture. The empty component Ø models the case where no physical component is to be included in the architecture. Thus, Rc o, Rm o represent necessary, but not sufficient, relationships; additional relationships will probably be necessary in order describe a feasible architecture. When the entire range of possible combinations of components, modules, and relationships is considered, the size of the architecture design space increases tremendously. One goal of PFRS (not presented in this paper) is to use requirements as constraints that reduce the size of the feasible design space. The challenge is to formulate mathematical expressions of the feasible space that results from applying a specific requirement. In Section 5 we will describe the Product Family Architecture representation procedure for a family of coffeemakers. 4 REPRESENTING PRODUCT FAMILY CONCEPTS USING GRAPH GRAMMARS In this section we will outline how different graph grammar concepts relate to designing product families. We first give arguments on how graph grammars can be used to represent different aspects of product architecture, followed by an outline on how some of the product family characteristics are related to graph grammar concepts. 4.1 Product Architectures and Graph Grammar Designing products involves several steps. One of the preliminary steps is the development of the function structure 4 Copyright 1999 by ASME

Pour Mix Pour Mix Product Family Common Structure Carry Store Carry Store Specific Structure 1. Specific Structure n Heat Heat Figure 3 - (a) Basic Structure (b) Flow of for the product. Several researchers have investigated the transformation of functions into structures using grammar productions at different levels of specificity. To represent architecture of a product, components and relationships among these components need to be specified. These components are discrete structures, making graphs well suited to represent product architectures the nodes of the graph can represent components/modules whereas the edges represent relationships among the components. Graphs can be used to represent function structures also, from Figure 3a we see that the functions are the nodes and the function flows are the edges of the graph. Different types of relationships can be represented in the graphs by using colored edges among the same nodes, in Figure 3b we show flow of water among the functions of the coffeemaker. Different relationships can be represented on the same graph using colored or labeled edges to make a more complete representation of the product. In many cases these relationships will be non-directional, but in other cases the relationships may be directional (flow relationship). In the case of directional relationships, directional edges or arrows can be used to specify the flow direction (Figure 3). In the rest of this section we will illustrate how different graph grammar concepts relate to product family development. 4.2 Graph Grammar Concepts Related to Family of Product Development Family of products is defined as a set of products that share common technology and address a related set of market applications. From this definition it is clear that products in a family will perform similar tasks, hence they will have a set of common functions that need to be performed. This set of common functions and relationships among them make the functional core of the product, whereas the optional functions will provide the variety. The common function structure can be represented using a graph, and a graph grammar can be used to specify interactions among the optional functions and the core. As different functions are added to the common function structure, a variety of function structures will emerge, which is shown at the first level of Figure 4. The function structures can be transformed using production rules to generate the architecture of the product. In Figure 5 we show a production rule that converts the carry Product variety 1 for Structure 1 Product variety n for Structure 1 Product variety 1 for Structure n Product variety n for Structure n Figure 4 -Variety Generated from one common function structure water function to tube structure. As alternate production rules are used to transform functions to structures, varieties will emerge. All these varieties constitute the product family at the physical structure level (Figure 4). Architectures of different products in the family can be traced to the common function structure by parsing the product architecture graphs (Figure 4). Parsing of a structure using a grammar can determine if the functions corresponding to the architecture can be traced back to the common function, which will determine the structure s inclusion in the language specifying a product family. The inherent characteristic of context sensitive graph grammars, to allow transformation from one viewpoint to another viewpoint and parsing to determine inclusion in the language, can be very useful in defining product family and identification of common platforms. Commonization Process: The products generated using graph grammars from a common function structure are in a product family, which is a part of the PSPV problem (Section 5.3.1). To solve the PC Design Problem commonality of the products needs to be identified at different levels of detail and different viewpoints to determine the overall common platform for the family. Imagine a scenario where a company is already producing a set of similar products. To economize, the company wants to reduce the number of platforms it uses (PC Design Problem, Section 5.3.2). The architecture of the products are known for different viewpoints and they can be represented using graphs. Using sub-graph isomorphism, sub-graphs that are common in all the platforms can be identified. s that are performed by the structures in the common sub-graph can be considered as common functions, whereas structures not in the Carry 6 Figure 5 - Conversion of to Structure 5 Copyright 1999 by ASME

Mix 7 Mixer Figure 6 - Hypergraphs to represent modules common set are options. Using sub-graph isomorphism the common product platform can be identified to solve the component section of the PC Design Problem. With the core and optional functions identified we can now formalize the product family architecture for the product by developing graph grammars that can be used to generate the existing product variety architectures. This formal product family architecture, using graph grammars, will help identify all the products (some of them not on production) that have the potential to be produced from the common platform, which is part of the PSPV problem. Modularity: Modularity is one of the main concepts in developing product families. Many researchers have specified the need to develop products in modules to support product varieties. A module is a set of components that work together to accomplish a higher level function. From a functional viewpoint, two or more functions are combined together into a module. Hypergraphs can be used to combine more than one function into a working module for the system. The combined function can be viewed as a single integrated function that interacts with other nodes of the graph. A hypergraph is defined to be an ordered pair H = (X, E) where X={x 1, x 2,,x n } is a set of vertices and E={e 1, e 2,..,e m } a set of hyperedges such that e i (i=1,2,,m) and m e i Support Mixer i = X; In Figure 6, the shaded line indicates a hypernode, which represents the higher level function Mix. Relationships (edges) are specified at the boundary of the hypernode representing interactions of the module with its neighbors. The relationships among the functions of the module are specified inside the hypernode, which captures the functional coupling in the module. Grammar production rules can be used on the hypergraphs to transform a graph to appropriate structures and relationships with external structures. Using hypergraphs to represent modules is useful in capturing the functional coupling in the module. The hypernodes facilitate the identification of the interactions that are required with other external functions of the product. Standardization: Standardization is the use of standard components/processes in multiple products or across a product line. Graph grammars can be used to map functions into generic structures. When refinements of a structure are made using further production rules, the generic components can be replaced by standard products or unique products according to need. In most cases productions are used to map from one stage of a product representation to a different stage of the product. These transformations usually have one or more alternate productions. The alternate production rules provide the variety, whereas the production rules (for a required function/component/module) without alternatives becomes standard. So standardization is supported at multiple levels of the grammar. A complete standardization will be accomplished when standardization is achieved at all levels. In the next section a coffeemaker product family representation will be developed by incorporating the concepts described in this section. 5 REPRESENTING A PRODUCT FAMILY The primary target in using product platforms to provide the necessary varieties is the identification of the largest set of common components/modules that do not change as different product varieties are introduced. From the product family definition it is clear that products in a family will perform similar tasks, hence they will have a set of common functions that need to be performed. This set of common functions and relationships among them make the functional core of the product, whereas the optional functions will provide the variety. From an engineering perspective tasks that are common in a product family can be realized in the same fashion, where the components and the relationships among the components are similar. If we use the modular product architecture concept, then the set of components and relationships can be combined into a module that performs a specific functions. The main focus of this paper is the development of a product family architecture that can concisely represent all the members of the product family. 5.1 Development of Product Family Representation In this section we briefly describe several steps that can facilitate the development of a product family architecture (Figure 7). Step 1: Determine the common and optional functions for the product family. Aim: The common tasks have the potential to be performed by common modules/components. Common functions that are used across the product family can be used to determine the product platform. The optional tasks provide the variety for the product family. Step 2: Specify the interactions among the core and the optional functions. Aim: To ensure that the core and the optional functions perform the desired tasks, the optional functions need to be inserted at the appropriate place in the function structure. PC Step 1 Step 2 Step 3 Step 4 Step 5 PSPV Figure 7 -Solving PC and PSPV problem 6 Copyright 1999 by ASME

Step 3: Transform the function structure to the structure viewpoints maintaining a correspondence between functions and modules. Aim: To determine the components and modules that will perform the functions. al modules are maintained to separate components of the core and optional modules. Step 4: Define the product family architecture. Aim: Determine the product family architecture. Step 5: Combine the core and the optional modules to specify the members of the product family. Aim: Use the product family architecture to generate the individual product architectures of the product family members that can be supported by the product platform. In the next section a coffeemaker product family example will be used to illustrate the application of different graph grammar concepts to formally represent a product family. 5.2 Using Graph Grammars to represent Product Family maker Example To illustrate some of the concepts related to using graph grammars to design family of products, a coffeemaker product family has been chosen. Agarwal and Cagan (1997; 1998) generated a set of coffeemakers using shape grammars. Most of the coffeemakers varieties were generated by changing shape grammar rules. In the coffeemaker example we will use the same function description and available options to describe a coffeemaker product family architecture. As mentioned earlier formal representation of product families do not exist, a formal representation of product family architecture was presented in Section 3.2. This formal representation combined with graph grammars will be used to formally represent product families, which is used to address different issues of the PC and PSPV design problem. Agarwal and Cagan (1997; 1998) introduced shape grammars that describe a language of coffeemakers, which can be used to generate a large class of coffee makers by changing the shapes and features. The functional breakdown of all coffeemakers is essentially the Figure 3.a): 1. water is first poured into and stored within a container 2. the water flows through a heating element, turns to steam 3. the steam rises through a tube, at the top it expands and condenses and flows into the filter 4. the hot water mixes with the coffee grounds within the filter 5. the coffee is then released into a coffee pot below 6. the coffee is kept warm on the pot which is kept warm by a heater Other information can also be represented with the function structure to develop a more complete model. As an example, flow of water (Figure 3.b) for the coffeemaker might be such information. The flow of water might indicate the need to have a tube to carry the steam to be mixed with the coffee, which is above the water heater. Some other constraints also exist that drive the configuration of the product. These constraints are also dependent on the basic functionality of the product, such as the water heater must be below the water storage unit, the filter unit must be above the heater, etc. The three main parts of the coffeemaker are: the filter unit, the water storage and the base unit. Some of the available options for these basic parts highlighted by Agarwal and Cagan (1997, 1998) are: q Number of heaters: In some coffeemakers, the same heater is used to heat the water and to keep the coffee hot. In the case of two heaters, two separate heaters are used to heat the water and to keep the coffee hot. q Flow control in filter: Fixed flow outlet or a variable flow outlet resulting in varying concentrations of coffee. q Flow control for water outlet: With or without mechanism to stop the flow of the coffee when the pot is not in place. 5.3 maker Family Representation The PFRS has two components: PC problem and PSPV problem. In the PC problem the objective is to determine the common platform for several related products. The PC problem has to be solved to develop product families for both new and existing products. The objective of the PSPV problem is to specify the architecture of the individual products that are in the product family supported by the product platform identified in the PC problem. Two possible scenarios can be imagined for developing a product family architecture. In the first scenario a new coffeemaker product family is to be developed and in the second scenario existing coffeemakers are to be commonized. In Section 5.3.1 we will describe the steps for developing a new coffeemaker product family. The steps for developing coffeemaker product family for the second scenario will be presented in Section 5.3.2. 5.3.1 New coffeemaker product family A company wants to develop a new coffeemaker product family to target different sections of the consumer market. The viable coffeemaker options that will be offered to differentiate the products are known, the company wants to know what is the product family and what is the product platform for the family. One obvious option is to keep all the options same and just provide variety by modifying the coffeemaker shape, which will only target a small segment of the market because the functional options are unchanged. In this case the product platform is easy to identify because it is all the components except for the outer shell of the coffeemaker. On the other hand, functional options can be varied to cover a greater portion of the market. When the functional options of the coffeemaker are changed then the shape grammar presented in Agarwal and Cagan (1997, 1998) is not well suited to identify the product family and the common platform (PSPV and PC Design Problem). A set of coffeemakers generated from a similar set of rules and parameters will have very closely related grammar and shape, in other words they will belong to the same coffeemaker family, which will be demonstrated in this example. Step 1: Identify core and optional functions The coffeemaker product family was described in Section 5.2. From the description we can identify the common and the optional 7 Copyright 1999 by ASME

Strongness Control Carry Mix + Flow Control Mix + Flow Stopper Separate heating Store Carry Store Heat Control Strongness of 11 10 Carry Mix Flow Stopper Store Separate + Heating 12 Carry Control Strongness of Store Heat Mix Heat transformations the functions as well as relationships among them are transferred to components and relationships among the components. In the case of coffeemaker structure the rules will specify what the components (terminal symbols) for the optional functions are and then how these components interact with other components of the coffeemaker. Addition of a second heater to the core structure is accomplished using grammar rule 13 and 14 (Figure 10). Rule 13 specifies how to add Heater 2 whereas Rule 14 specifies the structure modification on required to add the optional heater. Similar rules can be specified to add the optional functions Strongness Control and Flow Control. Step 4: Specify the product family architecture to describe the product portfolio. As described in Section 3.3, a product family architecture is composed of the core and the options. For the coffeemaker product family, both the functional core (left-most graph) and structural core (right-most graph) are shown in Figure 11. The structure of the coffeemaker is generated from the function by using grammar rules. In Figure 11 the numbers on arrows Figure 8 - Addition of Optional s functions. The common functions are: store water, heat water and coffee, carry water, mix water and coffee, and store coffee. The function structure of the core functions is shown in Figure 3.a. The optional functions for the coffeemaker family in this example are: separate heating for water and coffee, coffee flow stopper and control strongness of coffee. Step 2: Specify the interactions among the core and the optional functions. With the core functions (Figure 3.a) defined, production rules can be used to add optional functions to generate the variety. The rules (Figure 8) specify how optional functions interact with the core function structure and then generate a new function structure with specific functions for a member of the family. Step 3: Transform the function structure to the structure viewpoint maintaining a correspondence between functions and modules. The basic function structure shown in Figure 3.a can be transformed into the structure viewpoint using grammar rules. Some of these grammar rules are shown in Figure 9. Grammar rule 1 specifies transformation of store water function into intermediate symbols and relationships between them. The shaded box is a hyperedge, which treats the entrance and storage structures as a module, the external interactions with the module are specified at the boundary. In rule 2, the external interaction is specified with specific structures. Similarly, transformations of the other functions to structures are specified using grammar rules. The hyperedge is used to explicitly specify the module corresponding to the function. Applying the production rules the function structure is transformed to physical structure of the coffeemaker. In these Store Carry Mix Mixer 6 7 2 1 Mixer Support Mixer 8 Support Mixer Holder Mechanism - Carry Heat Provide support for coffee 3 Provide Heat to Heater Base - Store Store 4 5 Provide support for coffee Provide Heat to Pot Base Plate Figure 9 - Grammar rules to transform coffeemaker functions to structure Heat Heat 13 9 Heater 2 Figure 10 - Rules to add optional second heater to structure 14 Base Plate 8 Copyright 1999 by ASME

Store Carry Mix Store Heat 1 Carry Mix Store Heat 2 9 represent the rule being applied to the graph. The relationships among the different symbols of the core also specified by the grammar are transferred when the production rules are applied. The two cores are equivalent in their viewpoints given the graph grammar that was developed in the previous steps. As we transfer the core function structure and the optional functions to coffeemaker structure the graphs that are generated are members of the language. Because the graph grammar was developed to specify product family architecture the graphs represent coffeemakers that belong to the same product family. PFA (Product Family Architecture) = <Core, Options> where: Core = <C, M, Rc, Rm>, In the function structure viewpoint, the core is the common function structure. Dividing the core function structure into its elements of <C, M, Rc, Rm>, we get C = {Store, Heat water and coffee, carry water, mix water and coffee, store coffee} M = { Ø} Rc= { Flow (Store to Heat water and ), Flow (Heat water and coffee to carry water), Flow (carry water to mix coffee and water), Flow (mix coffee and water to store coffee) Flow (heat water and coffee to store coffee)} Rm={ Ø} Where the basic functions for the coffeemaker family are specified in C and the relationships among these functions are specified in R c. Dividing the optional functions into its elements <C o, P, Rc o, Rm o > we get P={{Ø, Separate Heating},{Ø, Flow Stopper},{Ø, Control Strongness of coffee}} C o is the list of all components mentioned in P. Rm o is empty and Rc o is specified by the grammar rules {{(Ø), (12)}, {(Ø), (11)}, {(Ø), (10)}}. A similar product family architecture can be developed for the structure viewpoint. Step 5: Combine the core and the optional modules to specify the members of the product family. The focus of this step is to use the product family representation scheme and graph grammars to develop Figure 11 - Transformation of to Structure Store Holder Mechanism Pot Carry product architectures of the different members of the product family in different viewpoints. This section is related to the PSPV. The coffeemaker family representation and graph grammars will be used to develop product architectures for the coffeemaker model with all options and the basic model. The two sub-steps are: Step 5.a: Combine the optional functions with the functional core using specified grammar production rules Generation of the product family member with all options can be accomplished by applying grammar rules to add optional functions (from Step 2) to the core function structure. For this example apply rules 10, 11, and 12 to the core function, which gives: 10 11 Core function Structure Structure with Strongness Control Structure with Strongness Control and Flow Control 12 Structure with Strongness Control, Flow Control and Separate Heating The right hand side of the conversion above is a function structure (Figure 12) for a coffeemaker that allows control of strongness of coffee, stops flow when the coffee pot is not in place and uses separate heaters for heating water and keeping the coffee pot warm. Step 5.b: Use grammar production rules to transform the functions into structure viewpoint for specific coffeemakers. In this step the function structure, obtained from the previous step, is transformed into structure viewpoint by applying grammar production rules. For the coffeemaker example this can be achieved by applying product rules 1 through 9 and then 13 through 16 (from Step 3), where rule 13 and 14 add the second heater, rule 15 specifies the module for controlling strongness of coffee and rule 16 adds the structure module for controlling coffee flow. The final graph representing the architecture of this specific coffeemaker is shown in Figure 12 (right hand side). In the case of the base coffeemaker model the first step can be skipped because no optional function needs to be added to the core function structure. The left hand side graph of is the core function structure. The basic coffeemaker structure can be Control Strongness of Heat Mix Flow Stopper Store Heat 13.. 16 Strongness Controller Heater 2 Holder Mechanism Pot Base Plate Stopper Figure 12 - maker will two heaters, coffee flow stopper and coffee strongness control options 9 Copyright 1999 by ASME

generated after applying rule 1 through rule 9 to the core function structure. Using the graph grammar we can generate product structures for 8 different coffeemakers. The differences in the architecture comes form addition and deletion of options. Generation of the different product architectures belonging to the same product family is part of the PSPV problem. 5.3.2 Commonization of existing coffeemakers In this scenario several existing coffeemaker architectures, not previously designed as a product family, will be commonized. The company wants to identify the common platform that can be used to support all the existing product varieties and would like to know the potential product portfolio for the identified product platform. Commonization of existing products require reasoning of the product architectures. Although the general steps required for developing a product family for this scenario are the same for new platform development scenario, the graph grammar implementation changed for several steps. Three different coffeemaker architectures will be used as an illustrating example to relate different graph grammar concepts to the steps for commonization of existing products. Step 1: Determine the common and optional functions for the product family. Step 1.a:Partition the products that are being commonized into common and unique components/modules. In Figure 13, we have three different coffeemaker architectures. We are interested in identifying the common architecture for these varieties. Using subgraph isomorphism we get three subgraphs that are common to all three varieties. The set of common components are: <,,,, Holder Mechanism, Pot,, >. Components that are optional can be determined by subtracting the common from the individual architectures. Performing this task we get the optional components Heater 2, Stopper, and Strongness Controller. The relationships that are common to all varieties are also shown in the subgraphs obtained. Step 1.b:Determine the intent or function of the different components and modules. From designer's previous knowledge, the functions of the different components/modules can be identified to establish a correspondence between function and components. Step 2: Specify the interactions among the core and the optional functions. We can apply node contraction to determine the one to one correspondence between the modules/components and their functional intent. Collapse components that are used to perform same functions into a single node and label the node to reflect the functional intent. The resulting graph will specify function structure for individual products. Using these function structures and the set of optional functions identified in step 1, we can identify the relationships between the optional and the core functions. These relationships can be represented using graph grammars similar to the ones shown in Figure 8. Step 3: Transform the function structure to the structure viewpoint maintaining a correspondence between functions and modules. From the identified functional intents we can specify grammar rules, similar to the ones shown in Figure 5, with the components/modules as the right hand side and the contracted nodes, with functional intent label, as the left hand side of the productions. Step 4: Specify the product family architecture to describe the product portfolio. Product family architectures for both structure and functional viewpoints can be identified from the resulting common and optional sets of components and functions from the previous two steps. The common elements for the viewpoints specify the core, whereas the optional elements specify the available options in their respective viewpoints. Dividing the family of products into core and options specifies how modules of the product should be developed. Using combinatorics members that belong to the coffeemaker product family can be specified (PSPV Design Problem). All the graphs accepted by the grammar makes up the potential set of coffeemakers for the product family. Agarwal and Cagan (1997, 1998) varied shapes to generate different varieties. The 8 product architectures generated by the graph grammar can be used to generate many actual coffeemakers that differ both in functions and shapes. This product family was developed to specify functions and structures related to functions as such the Holder Mechanism Pot Heater 2 Variety #1 Variety #2 Common Holder Mechanism Pot Holder Mechanism Pot Optional Strongness Controller Heater 2 Stopper Strongness Controller Heater 2 Variety #3 Figure 13 - Using Subgraph Isomorphism to determine the core Holder Mechanism Stopper Pot 10 Copyright 1999 by ASME

variety provided is distinguished by the functions that are provided. 6 CONCLUSION In this paper we presented an approach that uses graph grammar to develop a formal representation of product family with product platform as focus. The results indicate that some of the inherent characteristics of graph grammars have close mappings to product platform and product family characteristics. Graph grammars in this paper were used to transform function structures to product structures. A product family architecture was also presented, which has two components, core and options. In the case of functional viewpoint the core is the basic functions and options represent the optional functions used to provide the variety. Grammar production rules are used to convert the function structure to structures. Graph grammars also provide a means to determine if a specific product belongs to the product family by parsing and determining the inclusion of the product in the language, which is part of the PSPV Design Problem of PFRS. Subgraph isomorphism was used to determine the product platform for several existing products through commonization (PC problem). A coffeemaker product family was used to illustrate some of the product family concepts. The product family architecture consisted of a core, which was represented by a graph with basic functions. The options represented adding another heater, stopping coffee flow to pot, and variable water flow to filter to the core to generate function structure for variety of coffeemakers. Product family architectures were first defined at the functional level and then productions were used to convert it to structure. The product family architecture defined in the example can be used to generate all 8 members of the product family. Some of the conclusions that can be drawn from the example are: q Graph grammar concepts can be applied to both PC and PSPV problem. q Graph grammars make explicit the structure of a product family, including the structure of functions and physical architectures. q Product family architecture consisting of core and options is a useful formal representation to specify the common product platform and the variety that can be provided. q Graph grammars provide a means to add optional functions and structures to the core by specifying how they interact with other components in the product. In this paper, the coffeemaker structure and function structure was at a very high level. More detailed function structure can be generated using the same approach, then a graph grammar can be developed to convert the function structure into detailed structure. One future activity is the development of graph grammars that can be used to convert the function structure to other important viewpoints and then determine the common platform for all viewpoints. In this paper we did not include the assembly viewpoint, which is one of main constituent of the development of product platforms. Inclusion of different assembly considerations in the product platform development needs to be accomplished to determine the common assembly process that is essential to determine if all the product varieties can be supported on the same assembly line. ACKNOWLEDGMENT We gratefully acknowledge the support of Ford Motor Company for partial funding of this project and the cooperation of several Ford employees. We acknowledge the support of George W. Woodruff School of Mechanical Engineering of Georgia Institute of Technology. Also, we acknowledge the National Science Foundation through grant DMI-9414715. REFERENCE Agarwal, M. and J. Cagan (1997). "Shape Grammars and their Languages -- A Methodology for Product Design and Product Representation." Proceedings of the DETC 97, 1997 ASME Design Engineering Technical Conferences, Sacramento, CA DETC97/DTM-3867. Agarwal, M. and J. Cagan (1998). A blend of different tastes: the language of coffeemakers. Environment and Planning B: Planning and Design Vol 25(No. 2) pp. 205-226. Baker, K. R., M. J. Magazine and H. L. W. Nuttle (1986). The Effect of Commonality on Safety Stock in a Simple Inventory Model. Management Science vol. 3(8) pp. 982-988 Chen, W., D. Rosen, J. Allen and F. Mistree (1994). Modularity and the Independence of al Requirements in Designing Complex Systems. Concurrent Product Design vol. 74 pp. 31-38. Chomsky, N. (1957). Syntactic Structures. Atlantic Highlands, NJ, Humanities Press. Ehrig, H. (1978). "Introduction to the Algebraic Theory of Graph Grammars". Graph Grammars and Their Application to Computer Science, Springer-Vaerlag. Lecture Note Series in Computer Science. Fitzhorn, P. A. (1990). Formal Graph Languages of Shape. AI EDM vol. 4 No. 3. Fu, Z. and A. Pennington (1991). "Geometric Reasoning Based on Graph Grammar Parsing." ASME Design Automation Conference, Miami, Fl., September 1991. Ishii, K., C. Juengel and F. Eubanks (1995). "Design for product variety: key to product line structuring." ASME Design theory and methodology Conference, Boston, MA DE-Vol. 83 pp. 499-506. Lewis, H. R. and C. H. Papadimitriou (1981). Elements of the Theory f Computation. Englewood Cliffs, NJ, Prentice-Hall. MacDuffie, J. P., K. Sethuraman and M. L. Fisher (1996). Product Variety and Manufacturing Performance: Evidence from the International Automotive Assembly Plant Study. Management Science vol. 42 pp. 350-369. Martin, M. V. and K. Ishii (1996). "Design For Variety: A Methodology for understanding the Costs of product proliferation." 1996 ASME Design Engineering Technical Conferences, Irvine, CA 96-DETC/DTM-1610. 11 Copyright 1999 by ASME