Proceedings of DETC'00 2000 ASME Design Engineering Technical Conferences and Computers and Information in Engineering Conference Baltimore, Maryland, September 10-13, 2000
DETC2000/DTM-14666 PRODUCT FAMILY CONFIGURATION REASONING USING DISCRETE DESIGN SPACES Zahed Siddique Assistant Professor School of Aerospace and Mechanical Engineering University of Oklahoma Norman, OK 73019 (405)325-2692, Fax: (405)325-1088
[email protected]
ABSTRACT In the current market place companies need to deliver more variety with reduced time to market, lower prices and higher quality. These challenges have introduced the concept of developing a set of similar products using a common platform. Development of common platforms to support a family of products requires configuration reasoning. Configuration design spaces can be defined to facilitate platform and product family reasoning. For configuration design problems, the design space is much more difficult to define precisely (than the typical design space which is a subset of Rn, where n is the number of continuous variables), particularly when constraints are present. The purpose of this paper is to present a configuration design method that can be applied to two related problems: develop a common platform that satisfies requirements from multiple viewpoints, and generate members of a product family that also satisfy these requirements. To accomplish this objective, first design spaces are developed to model connectivity, functionality and assemblability considerations, then a common design space is developed to consider constraints from multiple viewpoints simultaneously. These design spaces are developed for both platforms and for product families. The application of this configuration design reasoning methodology is illustrated using a coffee maker product family. 1
INTRODUCTION Designing a product family often starts with a good platform and a strategy for generating the desired variety utilizing the platform as a common basis. In this paper, we explore the problems of Platform Commonization (PC), the
1
David W. Rosen Associate Professor The G. W. W. School of Mechanical Engineering Georgia Institute of Technology Atlanta, GA 30332-0405 (404) 894-9668, Fax: 404-894-9342
[email protected]
development of a suitable common platform for a product family, and Platform Supported Product Variety (PSPV), the generation of a product family from a common platform. The problem of designing product families is a large one; our focus in this paper is on the development of configuration design methods that address issues of which components are in a product and/or product family, and their arrangements and relationships. We specifically do not address scaling issues in product family design, although scaling is often utilized. Rather, we are investigating issues that involve commonality, modularity, and standardization through configuration reasoning methods. Although configuration reasoning is essential in product family development, the current state of research does not address the issue adequately. In configuration design (Dixon, et al. 1988), we are interested in identifying the components in an artifact and the relationships among the components. To address these questions, it is necessary to identify common platform configurations, for a set of products, considering multiple viewpoints and to identify the product family portfolio that can be supported by the platform. A configuration design approach leads naturally to combinatorial design spaces. A family of products can be developed using a platform approach by combining different options with the platform to provide the required product varieties. Determining feasible combinations of these options with the platform is a combinatorial problem. In addition, determining feasible product and platform configurations as options are added or product constraints are imposed is also combinatorial in nature. To address these combinatorial
Copyright © 2000 by ASME
problems, the approach presented in this paper is centered on constructing combinatorial design spaces through the application of discrete mathematics. In these design spaces, product, platform, and product family constraints are applied to identify and generate only feasible configurations that meet the requirements. The purpose of this paper is to present the Product Family Reasoning System (PFRS), a formal method for generating platform and product family alternatives. The solution process begins with an existing product family that is to be replaced with an improved product family with an improved platform. Output from PFRS is two-fold: candidate platform configurations, and candidate products within the product family that are based on the platforms. Only product configurations are generated; i.e., no dimensional synthesis is performed. The types of product family design problems to which PFRS applies include product families with a variety of optional components, modules, and functions and where a common platform is likely to emerge. If a product can be scaled up and down to provide variety, then PFRS is not applicable. Likewise, if the product family consists of virtually arbitrary combinations of functional modules (e.g., electronics assemblies), then again PFRS would not be applicable. As a design method, the benefit of PFRS is that is makes explicit the configuration issues involved in platform design and product family design. PFRS is called a formal method since it is based on the application of discrete mathematics: PFRS is a set of mathematical constructs for supporting the formulation and solution of PC and PSPV design problems. Product configurations consist of discrete components with relationships among them. As such, graph and other discrete representations are used to represent the product configuration and assembly information. Mathematical tools and concepts are then applied on these representations to formulate a series of common platform design spaces for a set of similar products. Constraints are applied to these design spaces to reduce feasible region sizes, which can then be more efficiently searched for promising platform configurations. After identifying promising platforms, the configuration design spaces are expanded to include all optional components and modules; this enables product family design. The mathematical foundation for PFRS is beneficial in that feasible design spaces can be explicitly computed without enumeration or search, enabling much more efficient platform and product family design. In the next section related research in product family design and configuration design is presented, followed by an overview of the PFRS and the focus of this paper in the configuration design context. Mathematical models used for platform and product family configuration reasoning are presented in Section 4 and 5 respectively. The coffeemaker platform and product family development is presented in Section 6. Concluding remarks are presented in Section 7.
2
2
RESEARCH IN RELATED TOPICS
2.1. Research in Product Family Design Research done in the areas of Mass Customization, Design for Product Variety, Designing Family of Products, etc. has stressed the need for developing a common platform. Martin and Ishii (1997) identified commonality, modularity and standardization as the core characteristics of product families. Chen et al. (1994) suggests designing flexible product architectures to enable small product changes to increase product variety. Pine (1993) suggests modularity to achieve maximum individual customization while minimizing cost. Stone et al. (1998) proposed a method to identify modules from a functional description of the product. Kota and Sethuraman (1998) suggested standardization of all components that does not need to be varied to satisfy the varying function requirements of the product family. Simpson et al. (1999) presented a Product Platform Concept Exploration Method (PPCEM) to facilitate the design of a common scalable product platform for a product family. Gonzalez-Zugasti, et. al, (1998; 1999) focus on modular product family development based on customer demands. Newcomb et. al., (1996) use Steward’s (1981) Design Structure Matrix to define modular product architecture(s) from different life cycle viewpoints. This research in product family design and modular architecture development does not systematically investigate all feasible platform and product family member architectures. The first step towards achieving this goal is to generate all feasible platform and product family configurations given a set of product and process constraints. 2.2. Research in Configuration Reasoning The platform commonization problem is concerned with determining which components should form the product family core and what the relationships among the components are, both internal and external to the platform. Configuration design is concerned with determining what components are in a design and how they are arranged spatially and logically. Typically, product architecture design occurs during the configuration design stage; i.e., after conceptual design but before parametric design Dixon et al. (1988). A product's architecture can be partitioned into modules based on function similarity, organization structure, manufacturing considerations, or the need for upgrade or add-on modules (Rosen, 1996). Much of the research in more general configuration design has focused on the development and application of heuristic methods for searching combinatorial design spaces (Finger and Dixon, 1989). Proper modeling of design spaces can greatly aid the search for solutions. Some work has been performed on developing mathematical operations including formal languagebased approaches using shapes and graphs (Rosen and Dixon 1992; Reddy and Cagan 1995). Although many results are mathematically elegant, the computational complexity of underlying algorithms makes direct implementation infeasible. Researchers have suggested that one way of reducing the size
Copyright © 2000 by ASME
of the combinatorial problem is to solve the problem at a higher level of abstraction, in which less important details are temporarily ignored (Sacerdoti 1974; Kota and Ward 1990). Rosen (1996) presents a formal foundation for configuration design for the life cycle that emphasizes product modularity and how it influences life cycle issues. The foundation derives from discrete mathematics (set theory and combinatorics) to represent and reason with combinatorial design spaces that capture all combinations of components, modules, and their relationships. The work presented in this paper builds upon this earlier research. 3
OVERVIEW OF PRODUCT FAMILY REASONING SYSTEM A Product Family Reasoning System (PFRS) is being developed to focus on the commonization of product platforms and the generation of required product family variety from those common platforms (Figure 1). PFRS contains mathematical models and tools to generate feasible common platform configurations and to generate configurations of product family members supported by the common platform, for a set of similar existing products. Inputs and outputs to PFRS include: Inputs Set of existing products Assembly facility(ies) for these products Constraints imposed by the existing products on the product family Constraints imposed by the existing assembly facility(ies)
Outputs Candidate set of platforms Candidate set of products within the product family Measures of commonality for platforms and products
From the outputs, the designer can select the most favorable platforms and products for further design and engineering. The commonality measures help to rank order the alternatives since generally, more commonality is better. A simple coffeemaker product family example will be used in this section to illustrate issues and tasks associated with PFRS. Imagine there are two coffeemakers that are of the same size. The first coffeemaker has no options. The second coffeemaker has a water level indicator and a coffee flow stopper. Currently the manufacturer does not use a platform approach to provide the varieties. As such it has been decided that a platform approach will be employed to provide the coffeemaker varieties. The coffeemaker designers consider three types of configuration requirements, called viewpoints: functional intent, connections, and assembly. Within each viewpoint, all combinations of components are considered when identifying the platform and product family members. As an example of a requirement for the functional intent viewpoint, the designers may specify that the heating subsystem contain only one Heater and the Base-Plate. This specifies a constraint on allowable component configurations. Designing within only one viewpoint is insufficient, so a method for combining feasible regions from viewpoint specific design spaces into a
3
common design space is required. This is where the key contribution of this research lies and is explained in Section 4. From an engineering perspective the steps that need to be performed are shown in Figure 1: A. Identify a common platform from the existing product portfolio: Components and modules common to both the coffeemakers need to be determined along with the connections among these components and modules. The manufacturer also wants to determine a common assembly process for the coffeemaker platform. To address this issue viewpoint specific platforms need to be identified. This platform is the baseline from which better platforms will emerge. B. Identify constraints inherent in the product family: With the common modules for the coffeemakers identified, relations among these modules need to be explicitly captured. These relations provide insight into connections among the components and assembly process associated with the coffeemakers. Relations among optional modules/components with platform modules/components provide insight into the overall product family and configuration constraints on members of the family. As an example, the designer may specify a constraint that dictates the Heater must be connected to the Base-Plate in all coffeemakers. Additional constraints would specify required functional, connection, and assembly relationships. C. Platform Commonization (PC) Design Problem: Formulate design spaces for a common platform: apply the constraints from Step B to these design spaces, and identify feasible platform configurations. More formally: Given a set of similar products, a candidate common platform, and constraints from multiple viewpoints, identify improved common modular platform architectures that satisfy those constraints. The two steps for this configuration reasoning are: C1. Feasible platform configurations for the different viewpoints are first determined by developing viewpoint specific platform design spaces with constraints. Set theory and combinatorics are used to provide the foundation for this step and to mathematically model product constraints in these spaces. In this work, we utilize three viewpoint specific design spaces: intent, connections, and assembly. Each design space represents all platform configurations that can be generated using the relationship that underlies the viewpoint (Intent, Connection, Assembly sequence). An element of one space contains one particular combination of relationships among the components in the platform. Other elements of the same space contain other combinations of relationships. Hence, all combinations of relationships among components are contained in the spaces, enabling all possible platform configurations to be modeled and investigated. C2. The common platform configuration space allows consideration of multiple viewpoint constraints simultaneously. This is accomplished by mapping feasible regions of all viewpoint specific design spaces into a common space.
Copyright © 2000 by ASME
is developed. The product family constraints at the module level are mathematically modeled to provide the feasible alternatives. D2. Viewpoint specific product family spaces are formulated by expanding the corresponding platform communization spaces. Constraints and requirements for the different members of family need to be mathematically modeled in the spaces so that all feasible product family member configurations for different viewpoints are captured. D3. The Product Variety Space is formulated to model product configurations for members of the family supported by the platform. To formulate this space, product platform and family constraints for multiple viewpoints need to be considered simultaneously. Mappings of individual product family spaces into the common configuration design space need to be developed. Hence the Product Variety Space needs to be characterized along with development of mathematical modeling foundations for mapping feasible product member architectures for different viewpoints. A. Identify Common Platform for a Both Steps C and D require a systematic Collection of Products B. Product platform and way of identifying the design space bounded family Constraints by the product constraints. Mathematical Identify and specify: models of relationships among the different • Module • Component components and modules of the platform must • Connections • Assembly be developed. Computational foundations are Identify viewpoint constraints for platform and specific product required to manipulate platform configurations product family platform for a set of similar products in specific viewpoint spaces (connection, assembly, etc.). Both platform and product C. Overall Common Platform family reasoning also require development of a Viewpoint Specific Platform common design space, where configuration Configurations reasoning for multiple product viewpoints can Common Platform be performed simultaneously. Configurations Assembly Steps C and D will be presented in this Mappings Platform paper, shown in the shaded region of Figure 1. Constraints Intent Detailed discussion of Steps A and B is presented in (Siddique, 2000).
Platform Commonization
Product information
Feasible Platform Configurations
Connects
Determine viewpoint specific platform configurations Determine platform configurations that satisfy all relevant view points
Platform Supported Product Variety
D. Product family member configurations Viewpoint Specific product family configurations
Constraints Constraints Module perspective of product family Product Family Constraints Constraints and Common Platform Configuration
Product Family Member Configurations
Assembly Mappings
Product Family Portfolio
Mappings
Intent
Constraints
Platform and Family constraints
Elements of the common platform configuration space will contain only feasible platform configurations. D. Platform Supported Product Variety (PSPV) Design Problem: Generate configurations of product family members: From the viewpoint specific platform and product family constraints, configurations of coffeemaker product varieties need to be determined. More formally: Given the configuration of a common platform and product family information and constraints, identify the configurations of the different products that can be supported by the common platform. The design spaces from Platform Commonization will be expanded to include optional components and modules. First, the organization of all modules needs to be specified. The PSPV problem involves three steps: D1. The feasible and desirable combinations of the platform and optional modules need to be determined first. Towards this end, a configuration space named Product Family Module Space
4 IDENTIFYING COMMON FEASIBLE PLATFORM CONFIGURATIONS – STEP C The approach taken here is to develop discrete design spaces to model feasible platform configurations. A systematic way of identifying the design space bounded by the product constraints is required for configuration reasoning. First, viewpoint specific feasible platform configurations are determined (§4.1), which are then combined to determine platform configurations that satisfy constraints of all relevant viewpoints (§4.2).
Connects
Determine viewpoint specific family member configurations Determine overall product family member configurations
Figure 1 – Steps involved in PFRS 4
Copyright © 2000 by ASME
[abcd ]
[12,13, 14,23,24,34]
[12,13,14,23,24]
[abc][d] [abd][c] [ab][cd]
[12,13,14,23,34]
[12,13,14,24,34]
[12, 13,23,24,34]
[12, 14,23,24,34]
[13, 14,23,24,34]
[acd][b] [ac][bd] [ad][bc] [bcd][a] [12,13,14,23] [12,13,14,24] [12,13,14,34] [12,13,23,24] [12,13,23,34] [12,13,24,34] [12,14,23,24] [12,14,23,34] [12,14,24,34] [12,23,24,34] [13,14,23,24] [13,14,23,34] [13,14,24,34] [13,23,24,34] [14,23,24,34]
[ab][c][d] [ac][b][d] [ad][b][c] [bc][a][d] [bd][a][c] [cd][a][b] [12,13,14] [12,13,24] [12,13,34] [12,14,23] [12,14,34] [12,23,24] [12,23,34] [12,24,34] [13,14,23] [13,14,24] [13,23,24] [13,23,34] [13,24,34] [14,23,24] [14,23,34] [14,24,34]
[12,34]
[a][b][c][d]
Figure 2 - Intent Space for Four Components. 4.1. Viewpoint Specific Platform Configuration Spaces – Step C1 4.1.1. Approach to Developing Mathematical Models The design spaces are constructed such that for a set of constraints viewpoint specific or general platform and product family member configurations are generated. In addition, the configuration spaces also capture relations among the feasible configurations. All of our design spaces are structured into what we call partition hierarchies. First, we will explain what we mean by “partition.” Each element in a design space is a partition of components or subsets of components, where each partition comprises a module. For the platform design spaces, the components or component subsets are limited to those components in the platform, while for product family spaces, all components from all potential products across the family are included. The simplest design space is called the intent space, which models the functional intent of components. It is structured as a simple partition hierarchy among the components in a platform. That is, each element of the intent space is a partition of the platform components into functional modules. In the remaining spaces, partitions of component sets make up the elements of those spaces. Second, we will explain the term “hierarchy.” Within a design space, an element of the space is a partition of the components in the platform or product family. For a single space, these partitions can be organized into a hierarchy in a mathematically meaningful manner. This is accomplished by defining a partition using an equivalence relation, then defining a partial order relation(s) to generate the hierarchy from the set of partitions. The mathematical structure of partition hierarchies enables the explicit representation of feasible regions of design spaces. It also enables the systematic enumeration of platforms or products in those feasible regions, without relying on search to generate alternatives. 4.1.2. Design space related to product intent information The Intent Design Space (ISpc) is constructed to determine all feasible platform configurations, where components are organized into various functional groupings. For ISpc, we are interested in grouping components into modules based on the functions they perform. If two components contribute to
5
[13,24]
[14,23]
Figure 3 - Connect Space for Four Components. meeting a function, then the components comprise a module with a common intent. ISpc is characterized by partitioning all the components in the product into possible subsets. Mathematically, the intent relationship between two components is an equivalence relation, where two components are equivalent if they contribute to the same function. Then, the set of resulting modules (subsets) is organized into a lattice (technically a Hasse diagram (Siddique 2000)). Assume that the four components in the coffeemaker platform (Filter, Bottom Housing, Base Plate and Heater) are designated X={a,b,c,d}, then the unconstrained module space denoted by ISpc(X) and is shown in Figure 2. The elements in the space represent feasible sets of modules in the coffeemaker platform. At the lowest level of the space, all components are separate modules ([a][b][c][d]) and at the highest level of the ordering all the components are in one module ([a b c d]). As another example, the element [cd][a][b] represents a coffeemaker configuration with Base-Plate and Heater as a module and the other two components as separate modules. Usually there are product constraints that reduce the size of the intent space significantly. The types of constraints are: • Strict constraints specify the elements that are included in the module, and these elements only can be in the module. • Non-strict constraints are similar to the strict constraint except that the intent can have other components from the complete set of components to accomplish the intent of the module. Mathematical model of these constraints in the Intent space is presented in Siddique (2000). 4.1.3. Design space related to platform component connections The Connects design space (ConSpc) represents all combinations of connected pairs of components that can serve as feasible platforms (Rosen, 1996). Assume that the coffeemaker platform has the same four components as above. ConSpc is constructed to specify the feasible set of coffeemaker platform configurations based on allowable connections among these four components. ConSpc is characterized by all subsets of the set containing all pairs of components in a given product. As considered here, connections between components can be fastening, constraining, or supporting. All that is implied is a physical contact between components. To develop the connects space, we consider that each pair of components represents a potential connection, then model connections
Copyright © 2000 by ASME
between pairs of components using an equivalence relation. Applying this relation to a set of component pairs partitions the pairs into disjoint subsets. Similarly to ISpc, these disjoint subsets can be organized as a Hasse diagram. Technically, ConSpc is a partially ordered set, not a lattice, since additional interpretation on the partitions must be imposed to make them meaningful. To interpret an element of ConSpc, we only consider the largest subset of pairs in the element as representing a platform and require all elements of ConSpc to contain all components in the platform. The unconstrained connect space for four components (1, 2, 3, 4) is shown in Figure 3. Each element in ConSpc represents a platform configuration with only the connections information. In most cases, connections among the different components in a product or platform are known, which provide constraints on ConSpc. These constraints significantly reduce the size of the feasible region of ConSpc. For example, if components Base-Plate and Heater are designated 1 and 2, respectively, and are required to be connected in the platform, then this constraint reduces the size of the feasible design region to the upper left of the heavy line in Figure 3. Consider 3 and 4 to be Filter and Bottom Housing respectively, then each element of the feasible region represents a coffeemaker platform configuration with Heater and Base-Plate connected with each other. 4.1.4. Design space related to platform assembly information The assembly design space contains all possible assembly sequences for the components that make up the product. The Assembly Design Space (AsySpc) is characterized by partitioning all the components in the platform into all families of subsets, where “family of subsets” denotes subsets nested within other subsets. Each element of the assembly design space represents a possible assembly sequence, where b
b
a b
a c
a
a b c
a c
a c
b
a b
b
a c
b c
a c
b
c
b
c
b
c
b
a
b
c
a b c
a
b c
b
b
a
a c
c
b
b
a c
a c
b
c
b
b c
c
a b
a
a c
b c
a
a c
b
a
a
a
c
a c
a b
c
Figure 4 - Assembly Space for Three Elements.
6
an assembly sequence is given by a sequence of workstations at which one or more components is inserted and possibly fastened. Consider the coffeemaker platform example with three components, a, b, and c. AsySpc for these three components is given in Figure 4. If a and b were assembled at workstation 1, and c was assembled at workstation 2, then the partition of components at workstation 2 is {{a, b}, c} (rightmost element of second row from bottom of Figure 4). These sequences can be organized into a partially ordered set. Typically, constraints on the assembly sequence of the product are known and can be modeled mathematically. Three types of constraints are of interest (Siddique 2000): q Strict constraints represent a situation where the basic components of an assembly module are completely specified along with their assembly sequence. q Strict-Components constraints represent a situation where the components in an assembly module are specified, but not the assembly sequence among the components. q Non-Strict constraints specify assembly sequence relationships among several components and subassemblies. Extending the coffeemaker example, if the designer specifies that Heater and Base-Plate are assembled before Bottom Housing is assembled, then this is a Strict-Components constraint and the possible 8 assembly options for the coffeemaker platform are shaded in Figure 4. 4.2. Common Platform Configuration Space – Step C2 With the viewpoint specific platform configurations identified, the next step is to consider all of the viewpoints simultaneously. This is accomplished by developing a common design space, called CombSpc, where the feasible viewpoint specific configurations are mapped and combined. CombSpc contains feasible modular platform architectures that satisfy constraints of multiple viewpoints. In this work, the common design space will contain platform configurations that meet connects, intent and assembly constraints simultaneously. The process of determining the common design space with only feasible module configurations consists of three steps: a a c b c b 1. Determine the implied modules for viewpoint specific set of constraints. Implied modules for ISpc: Modules are directly represented as each element of ISpc; a a a b c c b c i.e., element [a b c d] of ISpc represents the b module [a b c d]. Implied modules for ConSpc: For a set of components to be in a module, they must be a c connected. Since all components in a product b are connected to at least one other component in that product, every element of ConSpc implies the SAME module that contains all components in the product.
Copyright © 2000 by ASME
Implied Modules for AsySpc: For an assembly module represented by a subset, the vertices contained by the subset implies a module, which corresponds to actual assembly modules. Each vertex subset in the family implies a module. 2. Combine feasible regions of ISpc, ConSpc, and AsySpc into a common design space, CombSpc From an engineering point of view this step corresponds to determining feasible product modules that satisfy constraints of all viewpoints simultaneously. The structure of CombSpc depends on the viewpoint specific spaces being combined. A platform configuration in the common space is represented as an n-tuple, where the ith element of the tuple represents a feasible element of the ith design space. Let S1,S2,…,Sn be a set of n discrete spaces. If a1∈S1, a2∈S2,…an∈Sn then a product configuration in the common space is: {a1,a2,….,an} if they are feasible together. Feasible common platform configurations are determined using a new mathematical construct called the constrained cartesian product, ⊗, which operates on a set of viewpoint specific design spaces. CombSpc can be formulated as the constrained cartesian product of the individual spaces. CombSpc = ISpc ⊗ ConSpc ⊗ AsySpc (1) The key contribution, from the mathematical perspective, is this constrained cartesian product operator. The mathematical structure of CombSpc is determined from the structures of the viewpoint specific space. Furthermore, the constrained Cartesian product only produces feasible elements of the combined space. This can save tremendous time and effort in exploring large combinatorial design spaces. The mathematical development is presented in (Siddique 2000). The results of applying the constrained cartesian product will be presented intuitively. For the combination of an element of ISpc and an element of ConSpc, the constrained cartesian product judges the combination to be feasible if the set of components in all modules of the ISpc element are connected. As an example, consider the ISpc element to be {[Heater BasePlate] [Filter] [Bottom-Housing]} and the ConSpc element to be {[Heater Base-Plate Bottom-Housing] [Filter]}. The combination is {[Heater Base-Plate] [Filter] [Bottom-Housing]} (same as ISpc module) and is feasible because each ISpc module is a connected sub-module of a ConSpc module. Similarly, elements from ISpc and AsySpc can be combined according to the rule that all components in an ISpc module are assembled at the same, or consecutive, workstations. This means that if a group of components contributes to one function, they are {v1,1,u1,1,u2,1 } {v1,2,u1,1,u2,1 } assembled to one another at one workstation, or at {v1,1,u1,1} {v1,2 ,u1,1} {v1,1 ,u2,1} {v1,2 ,u2,1} consecutive {v1,1} {v1,2} workstations. Note that this is a heuristic {Ø} that can be changed. Figure 5 - Product Family Module The constrained Space.
7
cartesian product will still apply, however, the mathematical definition of module feasibility must be changed to model the desired heuristic. To compute Equation 1, elements of ISpc, ConSpc, and AsySpc must be feasible together. Based on the rules for combining ISpc and ConSpc, and ISpc and AsySpc, the rule for generating elements of CombSpc can be given as: modules implied by ISpc must be connected and must be assembled at one or consecutive workstations. This rule admits a concise mathematical definition that can be applied readily in practice. The output from Step C of PFRS will be a common platform design space containing a set of feasible platform configurations. As an example in the case of the coffeemaker, the common platform design space will contain a set of feasible coffeemaker platforms that will meet connection, intent and assembly constraints simultaneously. With all the feasible platform configurations generated, the designer can select the most suitable platform or platforms for further investigation. 5
CONFIGURATION DESIGN OF PRODUCT FAMILY The focus of the PSPV problem is to identify the product family portfolio that can be generated from the common platform output from the Platform Commonization step. Step D of PFRS uses a three-step procedure to accomplish this. Configuration reasoning is performed at two levels - module level and component level. Details of the sub-steps for PSPV are discussed next. 5.1. Specify Product Family Module Space – Step D1 The Product Family Module Space (ModSpc) represents all combinations of modules across the entire product family. These combinations are generated from all platform and optional modules. ModSpc contains all product family member configurations from a module perspective. A product family can be represented as a 2-tuple: (Siddique and Rosen, 1999). The platform is present in every member of the family. For the coffeemaker example, the available options are water level indicator and coffeeflow stopper. If these were the only variations from the platform, ModSpc will contain only four product configurations: platform only, platform plus water level indicator, platform plus coffeeflow stopper, and platform plus both the water level indicator and coffeeflow stopper. Variety module sets can be divided into two subclasses: 1. Required modules from groups that have to be in the product. Let V={V1,V2,…,Vk} be the collection of module sets, with V1,V2,…,Vk as the individual module sets such that one module from each has to be in the product. 2. Optional modules that are not required to be in the product. Let U={U1,U2,….,Uj ) be the collection of such module sets. One element in each U1,U2,..,Uj is the null module. The null module is selected if the product member does not contain that option. An example of product family module space is shown Figure 5. Assume there is one required module set in V={V1} and two optional module sets in U={U1,U2} with V1={v 1,1,v 1,2},
Copyright © 2000 by ASME
Coffeemaker Platform
Price Range: High §Large lid to pour water §Revolving filter and can be detached when needed §Indicator to show amount of water in water storage §Decanter activated pause and serve (Coffee flow stopper to stop coffee when pot is taken out)
family by identifying the set of components for each node in ModSpc. (2) Using this set of components, an assembly space for that product family member can be constructed. (3) These individual assembly spaces can then be organized according to the structure of ModSpc to generate the product family AsySpc.
Coffeemaker Variety#n
Coffeemaker Variety#2
Coffeemaker Variety#1
Base Coffeemaker
Price Range: Low §Small lid to pour water §Sliding filter §Only basic functionality
Figure 6 - Coffeemaker Product Family Development U1={u 1,1, Null) and U2={u 2,1, Null}. In ModSpc, the ∅ represents the platform. ModSpc is organized as a partially ordered set to specify relationships among the different members of the space. Constraints for ModSpc are primarily in the form of specifying modules that need to be together to provide desired products. Mathematical models of these product constraints are developed to constraints in ConSpc (Siddique, 2000). 5.2. Specify Viewpoint Specific Product Family Design Spaces - Step D2 Similarly to the platform commonization problem, a set of viewpoint specific design spaces are formulated for designing the product family. These product family design spaces contain configuration information for the entire family, with each element of a space satisfying all viewpoint specific platform constraints. Product Family Intent Space: The functional intent space for platform design (Section 4.1.2) can be extended to model the product family intent space, denoted ISpcF, which contains intent relations for members of the product family. This extension can be constructed using the entire set of components in all members of the product family and the product module space. Intent constraints are applied to ISpcF similarly to constraints applied to ISpc. Product Family Connects Space: Product family extensions for the connections space are similar to ISpc. The resulting product family space is denoted ConSpcF, and contains all combinations of connected components from the variety modules. Platform constraints and product family constraints can be specified in ConSpcF, which will reduce the size of the space. Product Family Assembly Space: The extension of the platform assembly space to product family assembly space is more complicated. To construct the product family assembly space, AsySpcF, the product family module space, ModSpc, is used. AsySpcF is constructed in the following manner: (1) Determine the components for each member of the product
8
5.3. Specify Product Variety Space - Step D3 The Product Variety Space, denoted ProdSpc, is developed by applying the constrained cartesian product to the viewpoint specific product family design spaces, as in Equation 2. ProdSpc = ISpcF ⊗ ConSpcF ⊗ AsySpcF (2) Each element in ProdSpc represents a feasible configuration of a member of the product family supported by the platform. Constraints on ProdSpc derive from both ModSpc and the viewpoint specific product family design spaces. As a result of applying these constraints, only feasible product configurations are generated, similarly to CombSpc. 6
COFFEEMAKER PRODUCT FAMILY DEVELOPMENT A coffeemaker is a consumer product with several primary functions: (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 and (6) the coffee is kept warm on the pot which is kept warm by a heater. Many coffeemaker varieties are available, some of which are based on the shape and the size (capacity) of the coffeemakers, whereas others are based on functions. The functions are used to satisfy needs of different market segments. Imagine that a coffeemaker manufacturer has two coffeemakers in the market, one basic (Base Coffeemaker) and the other one for the high priced market (coffeemaker #n) as shown in Figure 6. The manufacturer has decided to apply product family concepts to their product line and wants to develop: q a common platform for the coffeemaker varieties q a common assembly process and q coffeemaker varieties that can be supported by the platform given the set of available options in the two coffeemakers. The designer has specified the platform and product family constraints. With the constraints specified, coffeemaker product platform(s) and the family supported by the platform need to be determined. 6.1. Identifying Common Feasible Coffeemaker Platform Configuration – Step C A set of coffeemaker platform configurations will be identified by applying Step C of PFRS. 6.1.1. Viewpoint specific platform spaces – Step C1 Intent Space for platform: The coffeemaker platform intent space is generated from a set of constraints specified by the designer. The constraints are: Y1=CoverBottom={Bottom Lid}
Y5=Carry Steam 1={Steam
Copyright © 2000 by ASME
[Y1][Y2][Y 3][Y 4][Y5 ][Y6 Y7 ][Y8 ]
M2 M1 [Y 1][Y2 ][Y3 ][Y4 ][Y5][Y6][Y 7][Y 8]
Figure 7 - Intent space for coffeemaker platform Y2=CoverLower={BottomHousing} Y3=HeatWater and Coffee={Metal Pipe,Heater,Base Plate,Plastic Ring,Metal Bar} Y4=Carry Water={Water Carrying Pipe}
Table 1 - Feasible combined platform configurations C,M 1,A 1 C,M 2,A 1 C,M 1,A 2 C,M 2,A 2 C,M 1,A 4 C,M 2,A 4
C-04 C-06
C-04 Bottom Lid
C-06 C-11
Constraints Y1-Y5 and Y8 are specified as strict constraints, while Y6 and Y7 are non-strict constraints. The resulting intent design space for the coffeemaker platform is shown in Figure 7, which has two elements. Connects Space for Platform: The connection relationships among the different components of the platform are specified in ConSpc. The set of connects constraints are: Z={Bottom Lid, Bottom Housing}{Bottom Housing, Plastic Ring}{Metal Pipe, Metal Bar}{Metal Pipe, Heater}{Heater, Base Plate}{Base Plate, Plastic Ring}{Plastic Ring, Metal Bar}{Metal Pipe, Water Carrying Pipe}{Metal Pipe, Steam Carrying Pipe 1}{Water Carrying Pipe, Water Storage}{Steam Carrying Pipe 1, Water Storage}{Water Storage, Steam Carrying Pipe 2}{Water Storage, Condenser}{Steam Carrying Pipe 2, Condenser}
For the platform to be feasible, all of the connections specified in Z must be present. Then the constrained connects space has just one element, named C, meeting all constraints specified in the constraint set Z. This trivial connects space is not shown. Assembly space: The constraints for the assembly process are: e1=C-01={Heater, Metal Pipe} e2=C-02={Metal Bar, Base Plate, C-01} e3=C-03={Steam Carrying Pipe 1, Water Carrying Pipe, C-02} Bottom Lid∈C-11 e4=C-04={Bottom Housing, Plastic Ring, C-03} e5=C-05={Water Storage, Steam Carrying Pipe 2} e6=C-06={Condenser, C-05} e7=C-11={C-05, C-04,Bottom Lid}
As can be seen from the list of constraints some of the constraints are nested: e1,e2, and e3 are nested inside e4. e5 and e6 are also nested with e6 being the outermost constraint. Applying the constraints with e1 through e6 as strict constraint, e7 as a non-strict constraint and restricting the assembly process such that components and subassemblies are loaded and assembled in the same workstation, then the number of elements in the assembly space is 4, each of which is shown in Figure 8. The output of Step C1 is a set of feasible viewpoint specific coffeemaker platform configurations.
9
C-11
A3
A2
C-04
Carrying Pipe 1} Y6=Carry Steam 2={Steam Carrying Pipe 2} Y7=WaterReservoir={Water Storage} Y8=CondenseWater={Condenser}
Bottom Lid
A1
C-04 Bottom Lid
C-06
C-11
A4 Bottom Lid
C-06 C-11
Figure 8 - Coffeemaker Platform Assembly Space 6.1.2. Identifying combined common platform configurations – Step C2 With the individual platform spaces constructed, constrained cartesian product (Eq. 1) is applied to combine the viewpoint specific spaces. The common platform space for the coffeemaker contains six platform configurations. If C,M, and A represents the elements of the individual spaces then Table 1 lists all the feasible platform configurations. In each case the implied modules for all viewpoints are satisfied. The output of Step C is a set of six coffeemaker platform configurations that meet all connects, intent and assembly constraints imposed on the platform. From these six feasible configurations, the designer can determine which platform configuration will provide a better outcome. In this case, assume that the designer has chosen the C,M1,A1 configuration (Figure 9). 6.2. Coffeemaker Product Variety Space Development In this step family member configurations for the selected coffeemaker platform (Figure 9) are generated. 6.2.1. Coffeemaker product family module space– D1 To generate the product variety space, first the product family module space for the coffeemaker product family is developed. This space will provide a module level perspective for the entire family. The functional modules can be organized into following three groups: V1={Cover Water Entrance1, Cover Water Entrance2} V2={Mix Water and Coffee1, Mix Water and Coffee2} V3={Cover Top1, Cover Top2, (Cover Top2, Water Level Indicator),(Cover Top2, Stop Coffee Flow), (Cover Top2, Stop Coffee Flow, Water Level Indicator)}
One option from each Vi is selected to determine ModSpc. There will be 2*2*5=20 elements in the product family module space, which is shown in Figure 10. Note the hierarchical structure of optional modules and the similarity to Figure 5. 6.2.2. Specify individual product family design spaces for coffeemaker product family – D2 The development of the product family variety space requires construction of viewpoint specific product family spaces.
Copyright © 2000 by ASME
Water Storage
CWE = Cover Water Entrance TC = Top Cover MWC = Mix Water and Coffee WI = Water level Indicator SCF = Stop Coffee Flow
C-06 Condenser C-05
Water Carrying Pipe
Bottom Housing
Metal Bar
Steam Carrying Pipe 2
Steam Carrying Pipe 1
C-02 Metal Pipe
C-03
CWE2 TC1 MWC1 WI
Plastic Ring
CWE2 TC1 MWC2 WI
CWE2 TC2 MWC1 WI
CWE2 TC1 MWC2 WI SCF
CWE2 TC2 MWC2 WI
CWE2 TC2 MWC1 WI SCF
CWE2 TC2 MWC2 WI SCF
CWE2 TC1 MWC1 SCF
CWE2 TC1 MWC2 SCF
CWE1 TC1 MWC1
C-01
CWE1 TC1 MWC2
CWE1 TC2 MWC1
CWE1 TC2 MWC2
CWE2 TC1 MWC1
CWE2 TC1 MWC2
CWE2 TC2 MWC1
CWE2 TC2 MWC2 SCF
CWE2 TC2 MWC2
C-04
Bottom Lid
CWE2 TC2 MWC1 SCF
C-11
Heater Base Plate
CWE2 TC1 MWC1 WI SCF
Platform Cover Lower, Cover Bottom, Heat Water and Coffee, Carry Water, Carry Steam 1, Carry Steam 2, Water Reservoir, and Condense Water
Module Hyperedges
Components
Assembly Hyperedges
Connects Relationships
Figure 9 - Selected Combined Common Platform Configuration Intent product family design space: The constraints for the intent design space include all platform and optional constraints. The set of platform constraints will apply to all members of the product family and are not presented here. Applying the constraints reduces the size of the intent product family space, which contains 1 element (bracketed components represent modules): [Bottom Lid][Bottom Housing][Metal Pipe,Heater,Base Plate,Plastic Ring,Metal Bar][Water Carrying Pipe][Steam Carrying Pipe1][Steam Carrying Pipe2][Water Storage][Condenser][Lid1][Lid2][Top Housing1][Top Housing 2][Filter 1][Filter 2][Water Level Indicator][Stop Coffee Flow]
The embedded modularization of the members of the family depends on the components that are in the family. Connects product family design space: The members of the product family will be developed using the coffeemaker product platform presented in Figure 9, as such the platform connection constraints will apply to all members of the coffeemaker family. Other constraints that apply are: Z 1 = [{Top Housing1, Water Storage}, {Lid1, Top Housing1}, {Lid1, Top Housing2}, {Filter1, Condenser}, {Filter2, Condenser}, {Filter1, FlowStopper}, {Filter2, Flow Stopper}, {Top Housing2, Water Storage}, {Water Indicator, Top Housing 2}, {Lid 2, Top Housing 2}, {Lid2, Top Housing1}{Top Housing2, Filter2}, {Flow Stopper, Top Housing2}, {Top Housing1, Bottom Housing}, {Top Housing2, Bottom Housing}]
Each of these constraints represents required connections when additional components are added to the platform to provide variety. As an example {Water Indicator, Top Housing2} represents a connection, which is required when the water indicator is added on a coffeemaker that uses Top Housing2. Assembly product family design space: The family space for the assembly viewpoint is composed of sub-spaces that contain feasible assembly sequences for the different members, which
10
Figure 10 - Coffeemaker Product Family Module Space are determined from the product module space. There are 20 assembly subspaces that are organized according to the elements of the module space. The set of constraints for each of these subspaces will satisfy the constraints of the platform in addition to satisfying other constraints evolving from addition of optional modules. As an example, constraints for the first subspace are shown below: Strict Constraints: e9=C-08={Filter 1, C-07} e10=C-09={C-04, C-08} e11=C-10={C-09, Lid 1} Non-Strict Constraint: e8=C-07={C-06, Top Housing 1}
Enumeration of the subspaces is performed by applying the platform constraints and optional modules constraints. The ordering of these assembly sub-spaces is similar to the product family module space. 6.2.3. Determine coffeemaker product family variety space - Step D3 The constrained cartesian product (Eq. 2) is applied to construct the product variety space. From ModSpc, there are 20 subspaces in the ProdSpc, where each subspace contains a set of feasible configurations of the family members. As an example, consider the components in the first subspace: φ17
φ18
φ 19
φ20
φ9
φ10
φ11
φ12
φ 13
φ14
φ15
φ16
φ1
φ2
φ3
φ4
φ5
φ6
φ7
φ8
φ0 Platform
Figure 11 – Product Variety Space for the Coffeemaker Family.
Copyright © 2000 by ASME
∂1={Bottom Lid, Bottom Housing, Water Carrying Pipe, Steam Carrying Pipe1, Steam Carrying Pipe2, Metal Pipe, Heater, Base Plate, Plastic Ring, Metal Bar, Water Storage, Condenser, Lid1, Top Housing1, Filter1} To ensure that the constrained cartesian product of the spaces is consistent, the components specified by ∂1 are the only components when the common subspace for this product family member, φ1, is generated. The constrained cartesian product of this member results in a subspace with two elements. Configurations of several member products are shown in Table 2. There are 32 coffeemaker configurations in the product variety space, which can be grouped into 20 subsets such that each subset contains coffeemaker configurations that have the same components. The configuration variation of the coffeemaker sets for the same components/modules is due to the alternatives in the assembly process. Hence there are 20 varieties that can be supported by the product platform. The varieties are provided by changing the type of outer casing, lid and filter along with adding the optional functions of Water Level Indicator and Coffee Flow Stopper. The partial order of the subspaces is shown in Figure 11, which has the same structure as ModSpc in Figure 10, as expected. The output of Step D is the product variety space for the coffeemaker platform selected by the designer. The product variety space contains coffeemaker configurations that can be supported by the platform. The designer now has all feasible coffeemaker configurations that can be supported by the platform and can decide the final coffeemaker portfolio. 7
CONCLUDING REMARKS The Product Family Reasoning System (PFRS) was developed to support a configuration design method with two objectives: to identify common platforms from a collection of similar, existing products, and to generate product families from these common platforms. PFRS and the design method were presented in this paper. The significance of this work is the development of configuration reasoning methods based on discrete mathematics, rather than an ad hoc treatment of the combinatorial nature of configuration design. PFRS was applied to a coffeemaker design problem to determine common coffeemaker platform configurations and the product variety configurations that can be supported by the platform. In related research, we have also applied PFRS to several automotive platform and product family design problems. Results match the decisions of the automotive manufacturer, but many alternatives were also generated, not all of which were explored by the manufacturer. These examples demonstrate that PFRS can be applied effectively to platform and product family design problems. Furthermore, the mathematical foundation of PFRS enables efficient representation and systematic enumeration of feasible combinatorial design spaces. The mathematical efficiency arguments were not presented here to enable the presentation of the PFRS method.
11
To date, PFRS has been applied manually. We are currently working on a computer implementation of PFRS that will enable us to more completely test our effectiveness and efficiency assertions. Because PFRS only addresses configuration issues, it is an incomplete design method. However, the major advantages of PFRS is that it makes configuration issues explicit and it enables systematic enumeration of alternatives. ACKNOWLEDGMENTS We gratefully 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-9900259. REFERENCES Chen, W., Rosen, D.W., Allen, J. K., and Mistree, F., 1994, “Modularity and the Independence of Functional Requirements in Designing Complex Systems.” ASME Winter Annual Meeting, Concurrent Product Design vol. 74: pp. 31-38. Dixon, J. R., M. R. Duffey, R. K. Irani, K. L. Meunier and M. F. Orelup, 1988, "A Proposed Taxonomy of Mechanical Design Problems." ASME Computers in Engineering Conference, San Francisco, pp. 41-46. Finger, S. and J. R. Dixon, 1989, “A Review of Research in Mechanical Engineering Design. Part I: Descriptive, Prescriptive, and Computer Based Models of Design Processes.” Research in Engineering Design vol. 1 pp. 51-67. Finger, S. and J. R. Dixon, 1989, “A Review of Research in Mechanical Engineering Design. Part 2: Representations, Analysis, and Design for the Life Cycle.” Research in Engineering Design vol. 1 pp 121-137. Gonzalez-Zugasti, J. P., K. N. Otto and J. D. Baker, 1998, "A Method for Architecting Product Platforms with an Application to Interplanetary Mission Design". ASME Design Automation Conference, Atlanta, GA, Sept 13-16 Paper No. DETC98/DAC5608. Gonzalez-Zugasti, J. P., K. N. Otto and J. D. Baker, 1999, "Assessing Value for Product Family and Selection". ASME Design Automation Conference, Las Vegas, NV, ASME, Sept 1215 Paper No. DETC99/DAC-8613. Kota, S. and A. C. Ward, 1990, “Functions, Structures, and Constraints in Conceptual Design.” Proceedings of the 2nd International Conference on Design Theory and Methodology, Chicago, IL. DE-27 pp. 239-250. Kota, S. and K. Sethuraman, 1998, “Managing variety in product families through design for commonality.” 1998 ASME Design Engineering Technical Conferences, Atlanta, GA, ASME. Paper no. DETC/DTM5651 Martin, M. V. and K. Ishii, 1997, “Design for Variety: Development of Complexity Indices and Design Charts.” 1997 ASME Design for Manufacturing Conference, Sacramento, CA. paper no. DETC97/DFM-4359. Newcomb, P. J., B. Bras and D. W. Rosen, 1996, "Implications of Modularity on product design for the life cycle". ASME 1996
Copyright © 2000 by ASME
Conference on Design Theory and Methodology, Irvine, CA 96DETC/DTM-1516. Reddy, G. and J. Cagan, 1995, “An Improved Shape Annealing Algorithm for Truss Topology Generation.” ASME Journal of Mechanical Design Vol. 117 pp. 315-21. Rosen, D. W. and J. R. Dixon, 1992, “Languages for FeatureBased Design and Manufacturability Evaluation.” International Journal of Systems Automation: Research and Applications vol.2(4) pp. 353-373. Rosen, D. W., 1996, "Design of Modular Product Architectures in Discrete Design Spaces Subject to Life Cycle Issues." 1996 ASME Design Automation Conference, Irvine, CA 96DETC/DAC-1485. Sacerdoti, E. D., 1974, “Planning in a Hierarchy of Abstraction Spaces.” Artificial Intelligence vol. 5 pp. 115-135. Siddique, Z. (2000). Product Platform Development: Designing for Product Variety. Mechanical Engineering. Atlanta, Georgia Institute of Technology.
Siddique, Z. and D. W. Rosen, 1999, “Product Family Design: A Graph Grammar Approach.” ASME Design Theory and Methodology Conference, Las Vegas, Nevada. Paper no. DETC99/DTM8762. Simpson, T. W., J. R. A. Maier, and F. Mistree, 1999, “ A Product Platform Concept Exploration Method for Product Family Design.” ASME Design Theory and Methodology Conference, Las Vegas, NV, paper no. DETC99/DTM8761. Steward, D. V., 1981. Systems Analysis and Management: Structure, Strategy, and Design. New York, NY, Petrocelli Books. Stone, R. B., K. L. Wood, and R. H. Crawford, 1998, “A Heuristic Method to Identify Modules from a Functional Description of a Product.” ASME Design Theory and Methodology Conference, Atlanta, paper no. DETC98/DTM-5642.
Table 2 - Number of configurations in each product variety subspace Family Member Configurations SPACE: φ1 C-10
Family Member Configurations
Water C-06 Condenser Storage
Lid 1
C -05 Filter1 Steam Steam CarryingC -08 Water Top C-07 Carrying Carrying Pipe 2 Housing1 Pipe 1 Pipe C-11 Metal C-02 Metal Pipe Bar C-13
Bottom Housing Bottom Lid
Base Plate Plastic Ring
SPACE: φ20
C-03
Water Storage
Lid 2
Heater C-09 C-01
C-10
Water C-06Condenser Storage C-05
Water Top C-07 Carrying Pipe Housing1 Metal Bar Bottom Housing
Top Housing1
Bottom Lid
Bottom Housing
Filter 1
Plastic Ring
C-02 C-03 Metal Pipe
Base Plate
C-0 8 Coffee Flow Stopper C-14 C-1 1
Heater C- 09
C-0 1
Bottom Lid
C-04
1 Configuration
C-11
C-02 Metal Pipe
Water Steam Carrying Steam Carrying Pipe Carrying Pipe 2 Pipe 1
Metal Bar
……
Steam Steam CarryingC-08 Carrying Pipe 2 Pipe 1
Base Plastic Plate Ring
Filter 2
C-04 C-1 3
Lid 1
Condenser
C- 05
Water C-0 7 Level Indicator
C-10
C-06
Heater C-09 C-01 C-03
C-04
2 Configurations ……………………………………. Intent Modules
Assembly Modules
Components
12
Connects Relationships
Copyright © 2000 by ASME
