A configuration design based method for platform commonization for product families

BRIAN CORBETT; DAVID W. ROSEN

doi:10.1017/S089006040404003X

A configuration design based method for platform commonization for product families

Published online by Cambridge University Press: 28 January 2005

BRIAN CORBETT and

DAVID W. ROSEN

Show author details

BRIAN CORBETT: Affiliation:
Bell Helicopter Textron Inc., Fort Worth, Texas 76101, USA
DAVID W. ROSEN: Affiliation:
The George W. Woodruff School of Mechanical Engineering, Georgia Institute of Technology, Atlanta, Georgia 30332-0405, USA

Article contents

Abstract
1. INTRODUCTION
2. OVERVIEW OF PFRS
3. MATHEMATICAL DEVELOPMENT OF VIEWPOINT SPECIFIC DESIGN SPACES
4. PARTITIONING METHOD
5. EXAMPLE PROBLEM
6. CONCLUSIONS
ACKNOWLEDGMENTS
NOMENCLATURE
References

Rights & Permissions

Abstract

Product families help companies reach customers in several different markets, lessen the time needed to develop new products, and reduce costs by sharing common components among many products. The product platform can be considered as a set of technologies, components, or functions, and their arrangements, that are utilized for more than one product. Configuration design focuses on the components in a product and their connections and relationships. Discrete, combinatorial design spaces are used to model design requirements regarding physical connections, module partitions, and assembly sequences for the product family. To ensure that products satisfy all design requirements, it is necessary to combine these design spaces into a common configuration space into which all requirements can be mapped. This paper presents computational methods for modeling and combining design spaces so those configurations can be identified that satisfy all constraints. A new representation of assembly sequences facilitates the development of an assembly design space, elements of which can be enumerated readily. Because the size of the combinatorial design spaces can become quite large, computational efficiency is an important consideration. A new designer guided method, called the partitioning method, is presented for decomposing configuration design problems in a hierarchical manner that enables significant reductions in design space sizes. An example of a family of automotive underbodies illustrates the application of the discrete design space approach to develop a common platform.

Keywords

Configuration Design Discrete Mathematics Platform Commonization Product Family Design

Type: Research Article
Information: AI EDAM , Volume 18 , Issue 1 , February 2004 , pp. 21 - 39

DOI: https://doi.org/10.1017/S089006040404003X [Opens in a new window]
Copyright: © 2004 Cambridge University Press

1. INTRODUCTION

For many companies, a major motivation for designing product families is to leverage product development investments across a wide range of products. Many of these investments result in a common platform from which products in the family can be developed. From the product perspective, the platform can be considered as a set of technologies, components, or functions, and their arrangements, which are utilized for more than one product. Often, assembly processes, equipment, and facilities are also considered part of a product platform because they represent major investments for a company. Hence, designing a good platform for a product family can serve to integrate product designs with production resources, leveraging the investments made in those resources.

1.1. Configuration design of product platforms

In this paper, we focus on the configuration design of product platforms that include assembly considerations. In configuration design, the challenge is to identify which components are in a product and/or product family, and their arrangements and relationships. For product families, these configuration challenges can concern either a platform commonization (PC) problem (identify common platform configurations for a set of products considering multiple viewpoints) or a platform supported product variety (PSPV) problem (identify the product family portfolio that can be supported by the platform). Our focus here is on developing mathematical models for configuration design and developing a PC method based on those models. In this work, we are concerned with identifying common platforms for an existing set of products that are to become a product family.

Configuration design problems are inherently combinatorial in nature. Design of a product platform involves the identification and evaluation of component and relationship combinations. Product and platform representations for configuration design are discrete structures, usually modeled using graphs, sets, partially ordered sets, lattices, or trees. From a mathematical perspective, it is necessary to develop platform representations for several types of design requirements, to find methods of describing design spaces composed of these representations, and to efficiently search within such discrete, combinatorial design spaces. Discrete design spaces for modeling functional intent, physical connections, and assembly considerations have been presented in previous work, as has the configuration design approach (Siddique & Rosen, 1999, 2001).

Because configuration design spaces are combinatorial, their sizes can increase exponentially as the number of components in the product increase. Two means for addressing this issue are provided in this work. First, the constrained Cartesian product (CCP) has been shown to reduce the combinatorial explosion that results when combining discrete design spaces. Second, a new method is presented in this paper, called the partitioning method, which enables a designer to effectively explore discrete design spaces. The partitioning method is a designer-guided method for selecting regions to search within these discrete design spaces. In this manner, designer judgment is used to isolate promising regions for in-depth investigation and explore the effects of constraints on levels of product family commonality and variety.

This work builds on the product family reasoning system (PFRS) approach (Siddique & Rosen, 2001) that is summarized in Section 2. In Section 3, the viewpoint specific design spaces are introduced and the CCP is presented for combining these spaces. In Section 4, the partitioning method for generating platform configurations is presented. Section 5 features an extensive example of an automotive unibody commonization problem to illustrate the application of configuration reasoning methods.

1.2. Related research

Research done in the areas of mass customization, design for product variety, designing family of products, and so forth 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. Kota and Sethuraman (1998) suggested standardization of all components that do not need to be varied to satisfy functional requirements of the product family. Stone et al. (1998) proposed a method to identify modules from a functional description of the product. Gonzalez–Zugasti et al. (1998, 1999) focus on modular product family development based on customer demands. Newcomb et al. (1998) 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.

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; that is, after conceptual design but before parametric design according to Dixon et al. (1988). A product's architecture can be partitioned into modules based on functional similarity, organization structure, manufacturing considerations, or the need for upgrade or add-on modules (Ulrich & Eppinger, 2000).

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 & 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 language-based approaches using shapes and graphs (Rosen & Dixon, 1992; Reddy & 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 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 & Ward, 1990).

Configuration design has received attention from the artificial intelligence (AI) community for the past 2 decades (Soininen et al., 1998). The focus has been on constraint satisfaction (Mittal & Falkenheiner, 1990), and resource-based configuration (Heinrich & Jungst, 1991). In addition, the AI community has investigated the use of generative systems, which includes evolutionary methods (Gero et al., 1997; Rosenman & Gero, 1999), rewrite rule methods (Agarwal & Cagan, 1998; Agarwal et al., 1999) and heuristic rule methods (Kolodner, 1993), to discover new designs. However, the difficulty lies in selecting those that are worth considering or the feasible designs. This problem becomes more complex as the design space becomes discrete and combinatorial in nature.

In contrast, the work presented in this paper seeks to exploit the mathematical structure underlying the evolutionary and rule-based methods. The structure inherent in configuration design spaces enables the explicit computation of feasible regions within these spaces, enabling the generation of all feasible designs without the need for random or heuristic search. Given that millions of designs (or more) may be feasible, designer-guided methods of navigating these designs are developed here.

2. OVERVIEW OF PFRS

The PFRS developed by Siddique and Rosen (2001) provides a formal foundation for the configuration design of platforms and product families. PFRS contains mathematical models and tools that can be used with common platform design methods to facilitate PC and product family member generation. With PFRS, product configurations are developed to satisfy constraints from multiple viewpoints. A viewpoint is a design space that models a specific type of relationship among the components of a product. They present viewpoints for modeling module intent, component connectivity, and assembly. An overview of PFRS is presented in this section, while a detailed development of the mathematics behind the viewpoint specific design spaces is documented in the next section.

An overview of PFRS and its four main steps (A–D) is presented in Figure 1. Inputs to PFRS include a set of existing products and viewpoint specific constraints on the product family. The outputs of PFRS are a candidate set of product platforms and a candidate set of products that can be supported by the platforms. From the outputs, the designer can select the most favorable platforms and products for further design and engineering. Commonality measures help to rank order the alternatives, because generally, more commonality is better. An overview of each of the main steps in PFRS follows:

A. Identify a common platform from the portfolio of existing products. This platform is the baseline from which better platforms will emerge.

B. Identify constraints inherent in the product family. Relationships among optional and platform modules and components provide insight into the core structure of the overall product family as well as configuration constraints on members of the family. Perform a “reality check” to identify if the designer can tolerate any flexibility regarding a constraint.

C. Formulate design spaces based on the common components identified for the baseline platform and product family constraints. Viewpoint-specific design spaces are generated and then combined to obtain overall platform configurations during this step. Feasibility constraints ensure that viewpoint specific configurations are compatible with one another. Identify an improved common platform.

D. Extend the design spaces from Step C to model the product family by including options. Identify feasible product family members (products) from which the new product family portfolio can emerge.

An overview of the product family reasoning system.

The example in this paper primarily focuses on the PC design problem addressed in Step C of PFRS: Given a set of similar existing products, identify common modular platform architectures that satisfy multiple viewpoints. This problem is formulated in greater detail in Figure 2.

Word formulation of the platform commonization (PC) problem.

3. MATHEMATICAL DEVELOPMENT OF VIEWPOINT SPECIFIC DESIGN SPACES

The approach taken here is to develop combinatorial design spaces to model feasible product configurations. Lattices and partially ordered sets are used to represent the combinatorial spaces. Mathematical models for three design spaces are presented that model the functional intent, connectivity, and assembly relationships of components in product platforms, products, and product families. The complexity of these design spaces follows directly from their combinatorial nature, which is exponential in nature. The advantage of our approach is that it reduces the size of each design space to be searched by applying constraints and considering only the feasible solutions. Much of this section is taken from Siddique and Rosen (2001).

3.1. Intent design space

For the intent space, we are interested in grouping components into modules based on the functions they perform. If one, two, or more components contribute to meeting a function, then the components comprise a module with a common intent. The intent design space (ISpc) is characterized by partitioning all the components in the product into possible subsets. Each element of ISpc is a potential platform configuration, with a particular assignment of functions to components. An element may or may not correspond to a feasible platform or product.

The intent space contains all partitions of n components into possible modules. The grouping of components into partitions is accomplished using an equivalence relation that determines if two components contribute to the same function. More generally, given a set V, all partitions of V are formed to generate a family of partitions,

. Each partition P_i is a collection of modules

where each module (M_i,j) is a set of components. ISpc is formed by applying a partial order on

. The specific partial order is subset, ⊆, where P_i ≤ P_j, if for every M_i,k in P_i there is a M_i,l in P_j such that M_i,k ⊆ M_j,l. Hence, ISpc is structured as a subset–superset lattice to specify the interactions among the different possible product architectures. This is formally expressed in Eq. (2).

As an example, assume that there are four components V = {a, b, c, d} in a product, then ISpc(V) may be represented as a Hasse diagram, with [a][b][c][d] as the unique bottom element and [a b c d] as the unique top element. Consider the element [ab] [cd] : this platform consists of two intent modules [ab] and [cd] , meaning that components a and b contribute to one function, wheras c and d contribute to meeting a different function. Note that we can view ISpc in a different manner; it is the set of component partitions with a discrete topology (Munkres, 1975).

The size of the unconstrained space can be counted using Bell numbers (Kreher & Stinson, 1999). Usually there are product constraints that reduce the size of ISpc significantly. Two types of constraints are of interest: strict constraints and nonstrict constraints.

Strict constraints (C^S) specify the elements that are included in a module, and only these elements can be in the module; that is, a set of components, C^S = {a, b, …}, must be a module in every partition. Let C₁^S, C₂^S, …, C_j^S be sets of constraints that strictly specify components in j modules. The resulting space can be determined using the following equation:

and the number of options can be counted as

where B(n) indicates the Bell number for n elements.

Nonstrict constraints (C^NS) allow modules to contain additional components, not just those specified in the constraint, to accomplish the intent of the module. The space satisfying the constraint can be determined by collapsing the subset C^NS into an element y, then considering the new space as V − C^NS ∪ {y} and determining the intent space for the set of new elements. The result of applying nonstrict constraints is given by

The strict and nonstrict constraints are advantageous because they can be applied prior to the generation of solutions. This prevents invalid configurations from ever being considered. Other informal or conditional constraints may be developed, but they may need to be implemented via a generate-and-test strategy.

3.2. Connects design space

The connects design space (ConSpc) was developed to model the physical connections present among the components of a product. As considered here, connections between components can be fastening, constraining, supporting, etc. Mathematically, connected graphs are used to model these connections. Components in a product are represented by a set of vertices, V = {v₁, v₂, …, v_n}, and edges of a graph are contained in set E = {e₁, e₂, …, e_m}. An arbitrary edge representing a physical connection between two components, v_i and v_j, is defined as e_k = {v_i, v_j} where v_i, v_j ∈ V. A configuration in ConSpc is formally defined as a graph G.

ConSpc is actually a subset of the lattice of all graphs based on set V because we require all elements of ConSpc to form connected graphs: the product must not be disjoint. As a result, ConSpc is a partially ordered set, not a lattice. The collection of all connected graphs, G_i, is included in the set

. Applying a subset (⊆) the relationship to

defines the connects space.

Constraints for the connects space are inclusive or exclusive in nature. Inclusive constraints (C⁺) require specific connections to be present in every configuration; exclusive constraints (C⁻) specify connections that should not be part of any configuration. Formal constraints for ConSpc are presented below.

In the worst case, the number of possible connection configurations is bounded by 2^|X| [where X is the set of all

possible connections that can be formed among the n components in the product]. Configurations for ConSpc are obtained by choosing all possible combinations of connections from set X. The impact of the constraints is to reduce the size of X by removing all constrained connections from X.

3.3. Assembly design space

During the assembly of a product, components are combined in a hierarchical manner. The assembly design space (AsySpc) contains all possible assembly sequences for a set of components that needs to be assembled into a platform or a product. Each element of AsySpc represents a possible assembly sequence, where an assembly sequence is given by a sequence of workstations at which multiple components are inserted and fastened. Assembly sequences are developed by hierarchically partitioning components into subassemblies; an equivalence relationship is established among all components combined at the same workstation (Siddique & Rosen, 2001).

In this paper, a new assembly representation using rooted trees is used to express the partition hierarchies of AsySpc. Figure 3 illustrates a rooted tree structure. In the figure black dots represent components (leaves) and white dots represent assembly operations (nodes). Four components (a, b, c, d) are assembled in two operations; c and d are assembled first, and then a and b are added to that subassembly at the second workstation. Two partially ordered sets, Leaf and Node, may be used to describe an assembly sequence, T = (Leaf, Node) (MacMahon, 1891). The poset Leaf describes how components are assigned to an assembly tree. Node describes the hierarchical information necessary for describing when components are assembled. The poset Node specifies the hierarchy of assembly operations by noting the altitude of each node in the assembly tree. Enumerating all assembly trees with n leaves is possible with the use of multinomial combinations (Lomnicki, 1972).

The rooted tree structure.

The assembly design space is developed by applying partial order relations to all labeled, rooted trees of a certain size included in the set

. The Assembly space can be formally defined as

A Hasse diagram for an assembly space with four elements is presented in Figure 4. In the figure, trees are arranged hierarchically according to the number of equivalence relations (assembly operations) that are needed to assemble the product. The highest element requires only one assembly operation.

The assembly space for four elements.

Constraints for AsySpc enable the designer to completely or partially specify subassemblies and their assembly sequences (Nugen, 1999). Two types of assembly constraints are presented here:

Type^I (C^I): Specify the components of an assembly module as well as their assembly sequence. This amounts to specifying a subset of components: C^I = {Leaf, Node}.

Type^II (C^II): Specify the components in an assembly module, but not the assembly sequence among the components. This amounts to specifying the components within a subset, but not the containment relationships among those components: C^II = {Leaf}.

The AsySpc allows constraints to be nested. Nesting allows the designer to specify that one subassembly be an input into another assembly process.

3.4. Common platform configuration space

After viewpoint-specific design spaces are developed, combinations of configurations from each viewpoint are generated to help form a combined design space (CombSpc). When two or more viewpoints are used in conjunction to describe the configuration of a product, it is necessary to ensure that the structures described by each viewpoint are compatible. As each viewpoint has unique mathematical characteristics, not all combinations of elements from different viewpoints will be feasible. In effect, the required mathematical relationships between two viewpoints will constrain the number of element pairs that result when the spaces are combined. CombSpc contains feasible platform architectures that satisfy constraints from all viewpoints.

To combine configurations from multiple viewpoints, an operator called the CCP is introduced (Siddique & Rosen, 2001). The CCP is based on the Cartesian product, an operation that enables all points in an n-dimensional space to be defined [e.g., (a, b, c, d) ∈ A × B × C × D, where a ∈ A, b ∈ B, c ∈ C, and d ∈ D] . For the CCP we are interested in obtaining all combinations of configurations from each viewpoint specific design space. If ISpc, ConSpc, and AsySpc are combined with the CCP the resulting configurations would be n-tuples of the form (P, G, T) ∈ CombSpc.

The CCP uses feasibility constraints to ensure that the structures described by the viewpoint specific configurations of each n-tuple are compatible with one another. The CCP is defined in Eq. (12) for the combination of n design spaces. Here, s_k,i represents an arbitrary configuration k from a design space S_i. The CCP operation is indicated by the symbol “[otimes ].”

The general notation used to express the feasibility constraint operations of the CCP is shown in Eq. (13), where elements s_k,1 and s_k,2 from design spaces S₁ and S₂, respectively, are combined. The result of the operation is a Boolean variable where a value of 1 indicates that the pair is feasible or 0 if the pair is not feasible.

Unique feasibility constraints are required for each pair of viewpoints that are being combined. Feasibility constraints among ISpc (I), AsySpc (A), and ConSpc (C) are presented in Eq. (14). FeasibleIC requires all components of a module to be physically connected. FeasibleIA states that all components of a module must form an independent subassembly in the overall assembly tree. FeasibleAC requires the components assembled in an assembly operation to be physically connected in the final product.

4. PARTITIONING METHOD

A new partitioning method has been developed to solve problems that involve products with large numbers of components. As indicated in Figure 5, the number of elements in discrete configuration design spaces increases at exponential rates; the number of solutions to a problem can quickly become overwhelming. The partitioning method hierarchically structures the configuration design task such that a designer considers only a simplified interpretation or subset of the configuration problem at any given time.

The size of unconstrained, discrete configuration design spaces with n elements.

The partitioning method is based on the notion that larger configurations can be developed by combining a number of smaller configurations. Figure 6 illustrates this concept; an assembly configuration for a product with 10 components (a–j) is constructed by combining three smaller configurations of size 2, 3, and 5, respectively. Figure 6 also indicates that a distinction can be made between the substructures being combined to form the larger configuration and the main structure for the larger configuration itself. With the partitioning method each substructure is analogous to a module in the product.

The construction of a larger assembly configuration from three smaller configurations.

The partitioning method hierarchically structures configuration design tasks such that they are performed at two levels: a product level, and a module level. At the product level configurations are developed to describe the relationships among modules in the product (i.e., establish the configuration's main structure). If the number and/or type of modules in the product are known, an overall product structure can be developed quickly by creating configurations at the product level. Module information is suppressed, and the product is viewed as a collection of modules rather than components. At the module level, configurations are developed among the components of each module in the product. Configuration design tasks are performed with greater detail at the module level.

To develop product configurations with the partitioning method, four basic steps must be followed. These steps are presented below and in Figure 7.

The steps in the partitioning method.

Step 1. Identify functional product modules into which components will be partitioned.

Step 2. Determine configurations among product modules (product level).

Step 3. Determine configurations for individual modules (module level).

Step 4. Integrate individual module configurations from Step 3 into product configurations from Step 2 to achieve a complete configuration discription.

A brief description of the partitioning method is presented here. Starting with Step 1 in Figure 7, all product module partitions are found first. Each square in the grid represents a different module partition. This process is similar to computing the intent space as discussed in Section 3.1. Before moving on to Step 2 it is assumed that the designer selects the shaded square as the module partition chosen for the product. In Step 2 the designer determines how the modules in the selected configuration in Step 1 are assembled and connected. The cube in Step 2 represents the combined Assembly and Connects spaces for the product's modules. (Note: the top of the cube has no grid pattern, as the intent space was computed in the previous step.) In Step 3 all design viewpoints for each module are created and combined individually. Each cube in the box for Step 3 represents all configuration combinations for each module in the configuration specified in Step 1 (it is assumed that the product has three modules). Finally, in Step 4 the configurations for individual modules from Step 3 are integrated into the product configurations identified in Step 2. The cube in Step 4 represents the results of the method: all complete product configurations for the module partition selected in Step 1. If the designer wishes to investigate different module partitions from Step 1, then Steps 2 through 4 may be repeated for the new module partitions. Each step is discussed in detail in the following sections.

4.1. Step 1: Identify functional product modules

The first step in the partitioning method is to identify sets of modules that are desired in the final product. For this step it is necessary to determine how many modules the product will have, the size of each module, and the specific components in each module. Step 1 is essentially the same process as that used to create the intent design space in normal PFRS configuration design problems: the designer specifies constraints before partitioning the components of the product into modules. The same constraints from Section 3.1 are used. The primary difference between the partitioning method presented here and the standard PFRS configuration design process is the fact that the modules from this first step will be further decomposed into submodules later in the configuration design process (Step 3). The designer should be aware of this fact when selecting a module configuration as excessive partitioning may complicate the integration process in Step 4. A word and math formulation for the tasks performed in Step 1 are presented in Figure 8. The intent space created in Step 1 of the partitioning method will be denoted ISpc_p where the subscript p indicates the product level.

The word and math formulation of Step 1.

As an example, the 10 components of the assembly configuration depicted in Figure 6 are described by the module partition: {{a, b} {c, d, e} {f, g, h, i, j}} ∈ ISpc_p, where M₁ = {a, b}, M₂ = {c, d, e}, and M₃ = {f, g, h, i, j} in the notation from Figure 8.

The identification of the main product modules is intended to be a straightforward process. Because the general architecture of many products is well established, determining the main modules should be rather direct. Ideally, only a few module configurations will be carried on to the next step as all of the remaining steps must be completed for each module configuration that is considered. If the number of module configurations is large, the designer should consider performing a selection procedure to reduce the amount of computation needed.

4.2. Step 2: Determine product configurations at the module level

The second step continues the configuration design process at the product level. Given an ISpc_p configuration from Step 1, it is necessary to determine how the modules of that configuration are connected and assembled. An overview of this step is presented in Figure 9. As with Step 1, the process for determining the connections and assembly sequences for the product's modules is similar to creating the connects and assembly design spaces as described in Sections 3.2 and 3.3. Constraints may be used to eliminate undesirable configurations when generating the remaining design spaces, and the CCP ([otimes ]) must be computed to determine which configuration combinations (P_p,i, G_p,j, T_p,k) are valid. The resulting product level configurations from this step essentially describe module interfaces and final assembly processes for the product. Information from ConSpc_p only states which pairs of modules are connected; details describing connections among individual components across specific module interfaces are obtained in Step 4.

The word and math problem formulation for Step 2.

It is important to emphasize that the number of elements in the configurations developed during Step 2 is equivalent to the number of modules in the ISpc_p element P_p,i that is selected in Step 1. Referring to Figure 6 again, all configurations in Step 2 would be based on the set V_p = {1, 2, 3} where elements 1, 2, and 3 of V_p represent the module subsets {a, b, c}, {d, e}, and {f, g, h, i, j}, respectively. Sample ConSpc_p and AsySpc_p elements for the module partition {{a, b, c} {d, e} {f, g, h, i, j}} are presented in Figure 10.

Sample product module elements for the module partition {{a, b, c} {d, e} {f, g, h, i, j}}.

4.3. Step 3: Determine configurations for individual modules

Using product module information from the ISpc_p configuration selected in Step 1, configurations describing how components within each module are grouped into submodules, connected, and assembled must be constructed. For the components in a particular module constraints are generated, individual design spaces are created, and feasible combinations of different design space elements are found as outlined in Figure 11. This process is completed for all modules in the product. Satisfactory configuration results for each module will be permuted in the next step and combined with each product level configuration from Step 2. Knowing this, the designer may perform some sort of selection procedure to reduce the number of individual module configurations so the total number of final combinations is manageable. It should also be noted that Steps 2 and 3 are decoupled and that both may be computed concurrently once a module configuration is selected in Step 1.

The word and math problem formulation for Step 3.

4.4. Step 4: Integrate module configurations from Step 3 into product configurations from Step 2

The objective of the integration step is to generate CombSpc for the complete product given the product level CombSpc_p and module level CombSpc_{M_i} configurations. An important part of the integration process is the generation of interface connection configurations, because, in Step 2, module–module interfaces were specified, but the exact component specific connections that fulfill those interfaces were not. The integration process is performed in three steps:

I. generate all module interface connection configurations (ConSpc_{M_i
M_j})

II. compute all combinations of CombSpc_p, CombSpc_{M_i}, and ConSpc_{M_i
M_j} configurations,

III. for each combination from II integrate all viewpoint specific configurations.

Of the three steps, designer input is only required for the first. Each of these three steps is outlined in this section. An overview of Step 4 is presented in Figure 12. Step I of the integration is accomplished in the formulate and generate portion of Figure 12; Steps II and III are accomplished in the compute phase.

The word and math problem formulation for Step 4.

4.4.1. Generating interface connection configurations: ConSpc_{M_i
M_j}

Module interfaces are represented as connections in the product level (Step 2); in this step all connection configurations for interfaces are computed. The space ConSpc_{M_i
M_j} contains all connection configurations that satisfy all constraints governing the interface between modules M_i and M_j. One or more connections must exist between a component in M_i and one in M_j to make the interface valid. The set of all possible connections is given by the crossproduct of M_i and M_j, resulting in all pairs of components from these modules. After computing M_i × M_j, constraints must be applied.

Constraints are used to determine the connection options that exist for each module interface. The same constraint types used for developing the connects space are used to constrain the connections. Positive (Cⁱ⁺) constraints specify connections that are required and negative (Cⁱ⁻) constraints specify connections that are not allowed (superscript i indicates interface). The total number of possible connections for the interface is equal to the product of the size of the two modules being connected, |M_i| · |M_j|. For a required interface, the minimum number of interface connections is either 1 or |Cⁱ⁺|, whichever is greater, and the maximum number of interface connections is |M_i| · |M_j| − |Cⁱ⁻|. To determine all interface options, all combinations of unconstrained connections are formed. Figure 13 demonstrates how the connection combinations are determined for the interface between two modules M_A = {a, b} and M_B = {c, d, e}.

A sample computation of all interfaces among two modules {a, b} and {c, d, e}.

4.4.2. Compute all combinations of product level, module level, and interface connection configurations

CombSpc contains all unique combined configurations that describe the complete product through each viewpoint that is modeled. To obtain all unique combined configurations, all combinations of elements from CombSpc_p, each CombSpc_{M_i}, and all appropriate ConSpc_{M_i
M_j} spaces must be computed. CombSpc combinations need to be computed in an iterative manner because the number and type of ConSpc_{M_i
M_j} spaces that are required to complete a configuration are dependent on the starting ConSpc_p configuration.

As indicated in the Generate step of Figure 12, all CombSpc configurations associated with a specific CombSpc_p configuration can be determined by computing the crossproduct among all CombSpc_{M_i} (where 1 < i ≤ n, and n is the number of modules in the product) and ConSpc_{M_i
M_j} (where 1 ≤ i ≤ n, 1 ≤ j ≤ n, i ≠ j, (M_i, M_j) ∈ ConSpc_p) spaces associated with that product level combined configuration. Results of the combination process are a mixed (product and module levels) set of configurations that describe specific product architectures. The integration of these mixed configurations is described in the next section.

With the partitioning method the CCP is not directly utilized when computing CombSpc as the operation was previously performed in Step 2 and Step 3 to generate the intermediate combined spaces. As a consequence, no feasibility constraints impact the combinatorial generation of CombSpc elements.

4.4.3. Integration of viewpoint specific configuration information to obtain CombSpc elements

Given a combination of product level, module level, and interface connection configurations, it is necessary to compute elements (P, G, T) of CombSpc. This final integration process is performed independently for each design space that is modeled. The integration of all configuration information for the intent, connects, and assembly spaces is described here. Combinatorial substitutions are the basis for the viewpoint specific integration process; module level configurations are inserted in place of the corresponding elements used to hold their place in a product level configuration.

ISpc. The integrated intent space is formed by substituting the various P_{M_i,i} at the module level for each M_i in P_p,i at the product level. The ISpc that is formed has an additional level of modules, compared with ISpc from Section 3.1, because of the usage of the submodules from Step 3.

AsySpc. For integrating the assembly viewpoint, the overall assembly procedure for the product's modules from Step 2 (T_p) must be updated to include the assembly configurations for each module developed in Step 3 (T_{M_i}). The result is a single assembly tree (T) that represents the entire assembly process for the complete product. During the integration process, each leaf in the assembly trees from Step 2 (T_p) must be replaced with a subassembly for the appropriate module as indicated in Figure 14. A procedure for creating the Leaf and Node sets for the complete assembly tree [T = (Leaf, Node)] has been developed by Corbett (2003).

A sample integration for the assembly design space.

ConSpc. To integrate all the connection information, all permutations of connection configurations for the product's modules (Step 2), individual modules (Step 3), and all relevant interfaces must be formed. The product connection configuration selected for the product's modules will determine which interface configurations must be permuted. The ConSpc integration process is formally stated here:

where there are n modules in the product. In the final connection configuration, G = (V, E), the set of vertices (V) includes all elements of the product and the set of edges (E) is formed by combining the set of edges from each module (G_{M_i}) and interface (G_{M_i
M_j}) graph.

5. EXAMPLE PROBLEM

The example problem presented in this section seeks to identify common product platform configurations for an automotive body structure using the partitioning method. The body structure of an automobile defines the vehicle's overall shape and serves as the main structural element in the vehicle. Automotive body structures are typically comprised of several sheet metal components that are welded together. From the common automotive body configurations identified in this case study, a designer can select one configuration to serve as a platform from which multiple vehicle variants are derived. For this case study emphasis is placed on illustrating the application of viewpoint specific constraints and implementation of feasibility constraints with the partitioning method. The purpose of this case study is to demonstrate how the partitioning method helps the designer manage the complexity of large problems and illustrate the relevance of the configuration design methods to an industry problem.

The body structure being studied is illustrated in Figure 15. Overall, the structure contains 138 components, but we will focus on the 39 components that make up the rear third of the vehicle's underbody and the body sides. It must be noted that for this example highly restrictive constraints are used to limit the number of solutions for presentation purposes. This is also representative of many automakers' approaches because modifications to assembly facilities are very expensive, and PC efforts should not result in onerous cost penalties.

An automotive body structure.

5.1. Step 1: Identify product module partitions

The first task is to determine how components of the body structure should be divided into modules. This requires the creation of the product level intent space (ISpc_p). Knowing that a total of 39 components are part of this configuration problem, constraints must be applied to compute ISpc_p and yield a manageable number of alternative module partitions.

The identification of constraints for the intent space is typically based on the grouping of components according to their function. An automotive body is an integral structure that makes it difficult to assign any specific function to an individual component. However, by investigating physical regions of the rear structure, it is straightforward to identify the purposes of groups of components; these groups become the functional modules. Five key modules were found: body-side, rear floor panel, rear H-frame, back panel, and rear wheel house assemblies. Assembly flow charts and component connectivity were used to identify opportunities for commonization. The key modules and all 39 components of the rear body structure are presented in Figure 16.

The main body modules and components.

For this example problem, module variety accounts for differences in the way that smaller components can be grouped with different modules. Fuel tank brackets (18 and 29) and a spare tire support (34) could be grouped with the rear floor assembly (M₂) or the rear H-frame (M₃) as indicated in Figure 17. Different module configurations may support alternative means of packaging components under the vehicle. Likewise, the rear tail lamp fixture (8) may be part of the back panel (M₄) or body-side assembly (M₁).

Opportunities for modular variety.

The solution process for Step 1 is summarized in Figure 18. Both formal (C_p^S and C_p^NS) and informal constraints are used. Formal constraints group most components into one of the five key modules. The informal constraints ensure that unconstrained components are assigned to the appropriate module by using exclusive or statements (

). Step 1 results in a total of 16 different module partitions because each of the four unconstrained components can attach to one of two different modules: 2 · 2 · 2 · 2 = 16.

The math formulation of Step 1.

One module partition is selected to be carried on for use with the three remaining steps of the partitioning method. The selected partition is presented here:

This partition corresponds to the following assignments for the unconstrained modules: 8 ∈ M₁, 18 ∈ M₂, 29 ∈ M₃, and 34 ∈ M₃.

5.2. Step 2: Generate product level configurations among modules

The second task is to generate product level configurations among the modules in the rear body structure. For this step the viewpoint specific design spaces ConSpc_p and AsySpc_p are generated after formulating and applying relevant constraints. These two spaces and are then combined with the module partition selected in Step 1 (P_p,i) using the CCP. This step is formulated below in Figure 19.

The math formulation of Step 2.

The viewpoint specific constraints specified for Step 2 restrict the number of product level configurations that are generated. Constraints for the assembly design space are based on assembly flowcharts again. The Type^I assembly constraint C_p^I is nested with the second constraint (C_p^II), a Type^II constraint. These constraints require the rear floor panel (M₂) and H-frame (M₃) to be assembled first, followed by the addition of wheel house inner (M₅) and body-side (M₁) assemblies in no specified order. The back panel (M₄) is unconstrained and added last. For this example ConSpc_p is fully constrained. Only one interface among modules is disallowed, {M₁, M₃}, whereas all others are required by C_p⁺. The large number of required connections is a consequence of the common practices adopted by the auto industry. The high connectivity among modules helps provide greater structural rigidity and more load paths for dispersing crash forces. The elements of AsySpc_p and ConSpc_p that are generated from using these constraints are illustrated in Figure 20. Four assembly and one connection configuration alternatives are found.

The elements of AsySpcp and ConSpcp.

Step 2 results in four product level configurations of the form (P_p,i, G_p,j, T_p,k). Combining AsySpc_p, ConSpc_p, and P_p,i with the CCP reveals that all permutations of assembly sequences, module connections, and module partitions are valid. This is a consequence of the high connectivity in the single ConSpc_p configuration: any subassembly in a product level assembly configuration (T_p,k ∈ AsySpc_p) will be connected in ConSpc_p.

5.3. Step 3: Generate module level configurations among components

For the third step, configurations for individual modules must be created. This process will be illustrated by presenting the development of configurations for a body-side module in detail. The body-side module is essentially a three-layer structure that provides side crash protection and supports the doors and roof of the vehicle. Figure 21 shows this module and its layered structure. In Step 3, individual design spaces are first constrained and then generated. Following that, the module design spaces are combined to obtain module configurations.

The layered structure of a body-side module.

The mathematical formulation used for developing module configurations for the body-side module (M₁) is presented in Figure 22. ISpc_M₁ constraints for the body-side module generally group components into submodules according their arrangement in the module's three-layer structure. Components such as the side cowl reinforcement (1) and door brackets (9 and 10) could belong to various layers. Connection constraints are mostly derived from the physical proximity of components in the module. Most of the optional connections correlate with the module options presented for ISpc_M₁. Assembly of the body-side module essentially begins by building up each layer individually and then joining all layers. This is reflected in the constraints.

The math formulation for Step 3.

Generating viewpoint-specific design spaces for the body-side module yields 52 alternative submodule structures, 24 connection configurations, and 236 assembly sequences. Rather than using informal (conditional) constraints to help further constrain the number of intent or assembly configuration alternatives, the CCP is relied upon to constrain the possible combinations of viewpoint-specific configurations for the body-side module. Of the 52 × 24 × 236 = 11,328 combined configuration combinations for the body-side module, all but 248 of the combinations yield incompatible configurations. An arbitrary combined module configuration

is listed at the end of Step 3.

5.4. Step 4: Integrate product and module configurations

The fourth task is to integrate configurations for individual modules from Step 3 into the product level configurations from Step 2. To accomplish the integration of ConSpc, it is necessary to identify connection configurations for module interfaces. To illustrate the interface configuration task, the interface required between the back panel assembly (M₄) and body-side (M₁) is determined. Figure 23 presents the constraints used for restricting the type of interface connections that are possible between the back panel and body-side modules; rather than listing all disallowed connections (C_M₁,M₄⁻) we only list optional connections: {M₁ × M₄} − C_M₁,M₄⁺ − C_M₁,M₄⁻.

The math formulation for Step 4.

Considering the interface between the body-side and the rear panel assembly it is apparent that only connections among components that will be in close physical proximity will need to be considered. Only components towards the back of the body-side would connect with components in the rear panel assembly. This interface is shown in Figure 24.

The interface between the back panel and body-side modules.

Figure 25 presents a connection matrix for this interface. Gray elements in the matrix indicate that the specified interface connection should not exist in the product configuration. As shown, of the 42 possible interface connections only 6 are plausible (4 are required, 1 and 2 are optional). The specified interface constraints result in four different interface connections as listed in Figure 23. Integration of the intent and assembly design spaces is not presented here because those steps do not generate any new configuration information. The integration processes for those design spaces were presented in Sections 4.4.1 and 4.4.2.

The connection matrix for the interface between the back panel and body-side modules.

6. CONCLUSIONS

From a configuration design perspective, the PC problem involves identifying a set of common components, modules, relationships among components and modules, and assembly sequences that can serve as a common platform for a product family. Configuration design spaces are discrete, combinatorial spaces that can grow very large. By modeling their underlying structure, however, some reduction in design space size can be achieved. By applying constraints derived from a particular PC problem, feasible design space regions can be identified; these are often very small. The mathematical methods for modeling these spaces, combining them, and applying constraints were presented in this paper. The partitioning method was presented as a designer guided approach to navigating in these discrete spaces to identify promising platform designs. An extensive example of automotive PC demonstrated the application of the mathematical and partitioning methods on a large, industrial problem.

Based on this work, the following conclusions can be drawn:

Mathematical models of configuration design spaces can be developed to identify feasible platform configurations.
Engineering constraints can be formulated mathematically and applied to these design spaces to significantly reduce their sizes.
It is advantageous to hierarchically partition design spaces, based on the modular structure of the platform, to reduce the difficulties in navigating large discrete design spaces.
Configuration considerations are just one aspect of PC and product family design. Packaging and other dimensional considerations are needed in order to fully analyze a platform's potential.
Although limited, this work provides a potential foundation for modeling and solving many types of discrete, combinatorial problems encountered in engineering design.

ACKNOWLEDGMENTS

We gratefully acknowledge the support from NSF Grant DMI-9900259 and matching funds from the Ford Motor Company. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation.

NOMENCLATURE

David Rosen is an Associate Professor in the School of Mechanical Engineering at the Georgia Institute of Technology. He is Director of the Rapid Prototyping and Manufacturing Institute. David received his PhD at the University of Massachusetts in 1992 and his MS and BS degrees, all in mechanical engineering, from the University of Minnesota in 1987 and 1985, respectively. He is a Fellow of ASME. Dr. Rosen's research interests include computer-aided design, rapid and virtual prototyping, and design theory and methodology.

Brian Corbett is an Engineer at Bell Helicopter Textron Inc. in Fort Worth, TX. He received his MS degree at Georgia Tech in 2003 and his BS degree from Texas A&M University in 2000 in mechanical engineering. Brian held engineering positions at Ford Motor Company during his education. Mr. Corbett's research interests are in product family design, computer-aided design, and design theory and methodology.

References

REFERENCES

Agarwal, M. & Cagan, J. (1998). A blend of different tastes: The language of coffeemakers. Environment and Planning B: Planning and Design 25(2), 205–226.Google Scholar

Agarwal, M., Cagan, J., & Constantine, K.G. (1999). Influencing generative design through continuous evaluation: Associating cost with the coffeemaker shape grammar. Artificial Intelligence for Engineering Design, Analysis and Manufacturing 13(4), 253–275.Google Scholar

Corbett, B. (2003). Configuration design methods and mathematics for product families. MS thesis. Georgia Institute of Technology.

Dixon, J.R., Duffey, M.R., Irani, R.K., Meunier, K.L., & Orelup, M.F. (1988). A proposed taxonomy of mechanical design problems. Proc. ASME Computers in Engineering Conf., San Francisco, pp. 41–46.

Finger, S. & Dixon, J.R. (1989). A review of research in mechanical engineering design. Part I: Descriptive, prescriptive, and computer based models of design processes. Research in Engineering Design 1, 51–67.Google Scholar

Gero, J.S., Kazakov, V., & Schnier, T. (1997). Genetic engineering and design problems. In Evolutionary Algorithms in Engineering Applications (Dasgupta, D. & Michalewicz, Z., Eds.), pp. 47–68. Berlin: Springer–Verlag.

Gonzalez–Zugasti, J. P., Otto, K.N., & Baker, J. D. (1998). A method for architecting product platforms with an application to interplanetary mission design. Proc. ASME Design Automation Conf., Atlanta, GA, Paper No. DETC98/DAC-5608.

Gonzalez–Zugasti, J.P., Otto, K.N., & Baker, J.D. (1999). Assessing value for product family and selection. Proc. ASME Design Automation Conf., Las Vegas, NV, Paper No. DETC99/DAC-8613.

Heinrich, M. & Jungst, E. (1991). A resource-based paradigm for the configuring of technical systems from modular components. Proc. Seventh IEEE Conf. on AI Applications, pp. 257–264.

Kolodner, J. (1993). Case-Based Reasoning. San Mateo, CA: Morgan Kaufmann.

Kota, S. & Sethuraman, K. (1998). Managing variety in product families through design for commonality. Proc. ASME Design Theory and Methodology Conf., Atlanta, GA. Paper No. DETC98/DTM-5651.

Kota, S. & Ward, A.C. (1990). Functions, structures, and constraints in conceptual design. Proc. ASME Design Theory and Methodology Conf., Chicago, DE-Vol. 27, pp. 239–250.

Kreher, D.L. & Stinson, D.R. (1999). Combinatorial Algorithms-Generation, Enumeration, and Search. Boca Raton, FL: CRC Press.

Lomnicki, Z.A. (1972). Two-terminal series-parallel networks. Advances in Applied Probability 4, 109–150.Google Scholar

MacMahon, P.A. (1891). Yoke-chains and multipartite compositions in connexion with the analytical forms called “trees.” Proceedings of the London Mathematical Society 22, 330–346.Google Scholar

Martin, M.V. & Ishii, K. (1997). Design for variety: development of complexity indices and design charts. Proc. ASME Design for Manufacturing Conf., Paper No. DETC97/DFM-4359. Sacramento, CA.

Mittal, S. & Falkenheiner, B. (1990). Dynamic constraint satisfaction problems. Proc. AAAI-90 Eighth National Conf. on AI, pp. 25–32.

Munkres, J.R. (1975). Topology, a First Course. Englewood Cliffs, NJ: Prentice Hall.

Newcomb, P.J., Bras, B.A., & Rosen, D.W. (1998). Implications of modularity on product design for the life cycle. ASME Journal of Mechanical Design 120(3), 483–490.Google Scholar

Nugen, F. (1999). Enumerating with constraints on the hierarchy space. Unpublished manuscript, Georgia Institute of Technology.

Reddy, G. & Cagan, J. (1995). An improved shape annealing algorithm for truss topology generation. ASME Journal of Mechanical Design 117, 315–321.Google Scholar

Rosen, D.W. & Dixon, J.R. (1992). Languages for feature-based design and manufacturability evaluation. International Journal of Systems Automation: Research and Applications 2(4), 353–373.Google Scholar

Rosenman, M.A. & Gero, J.S. (1999). Evolving designs by generating useful complex gene structures. In Evolutionary Design by Computers (Bently, P.J., Ed.). San Francisco, CA: Morgan Kaufmann.

Sacerdoti, E.D. (1974). Planning in a hierarchy of abstraction spaces. Artificial Intelligence 5, 115–135.Google Scholar

Siddique, Z. & Rosen, D.W. (1999). Product platform design: A graph grammar approach. Proc. ASME Design Theory and Methodology Conf., Las Vegas, NV, Paper No. DETC99/DTM-8762.

Siddique, Z. & Rosen, D.W. (2001). On combinatorial design spaces for the configuration design of product families. Artificial Intelligence for Engineering Design, Analysis and Manufacturing 15(2), 91–108.Google Scholar

Soininen, T., Tiihonen, J., Mannisto, T., & Sulonen, R. (1998). Towards a general ontology of configuration. Artificial Intelligence for Engineering Design, Analysis and Manufacturing 12(4), 357–372.Google Scholar

Steward, D.V. (1981). Systems Analysis and Management: Structure, Strategy, and Design. New York: Petrocelli Books.

Stone, R.B., Wood, K.L., & Crawford, R.H. (1998). A heuristic method to identify modules from a functional description of a product. Proc. ASME Design Theory and Methodology Conf., Atlanta, GA, Paper No. DETC98/DTM-5642.