A framework for mixed parametric and catalog-based ... - CiteSeerX

Senin, Wallace, Borland and Jakiela

1

A framework for mixed parametric and catalog-based design problem modeling and optimization Nicola Senin, David R. Wallace, and Nicholas Borland

Mark J. Jakiela

Computer-Aided Design Laboratory, Room 3-435 Department of Mechanical Engineering Massachusetts Institute of Technology 77 Massachusetts Avenue, Cambridge, MA 02139 Tel: 617-253-2655, Fax: 617-253-9637, Email: [email protected]

Department of Mechanical Engineering Washington University Campus Box 1185 One Brookings Drive St. Louis, MO 63130-4899 Tel: (314) 935-4966, Fax: (314) 935-4014 Email: [email protected]

Abstract In this paper an integrated modeling and search framework is proposed to optimize product design problems which involve simultaneously making choices from discrete sets of alternatives (catalog-based design) and the setting of design parameters defined over continuous intervals (parametric design). The modeling framework is based on the decomposition of problems into modules that interact by exchanging information services through interfaces. Modules contain embedded models composed of continuous variables, mathematical models or software programs and represent an aspect of a design problem, such as a component or an analysis viewpoint. Modules can be stored in catalogs so that they may be reused and substituted in a problem model to explore alternatives. The framework is used to optimize both module selections from catalogs and continuous parameters within modules. The optimization engine uses a genetic algorithm, and a genome representation and genetic operators are developed for the purpose. A high-level model definition software language is implemented for the framework so that the modeling and search approach may be readily applied to a wide variety of design problems. The efficacy of the modeling and search approach is tested for several genetic search algorithms, including simple, steady state and crowding techniques. The crowding algorithms most reliably located the global solution. A particular variation, referred to as Struggle2, offered the best overall performance, reliably locating global solutions in a relatively low number of evaluations while simultaneously locating many local solutions. Keywords: design problem modeling, catalog-based design, mixed variable optimization, genetic algorithms

Senin, Wallace, Borland and Jakiela

2

1. Introduction Many design problems involve choosing elements from catalogs and combining them with unique custom components. Therefore, methods to model such problems and search for optimal solutions are of practical importance. From an automated search perspective, however, these combinatorial problems tend to present difficulties. In this paper we will develop a general modeling and search methodology for this class of design problems. In the remainder of the introduction we define our design problem modeling and optimization scope, and outline the issues that we will address. Then, after reviewing prior art, the principles of the modeling and search methodologies are described and a framework is implemented to quantify their performance on a variety of problems. 1.1 Design Problem Modeling We define a design problem as a problem involving decisions about design variables. These decisions may range from choosing among a discrete and finite set of alternatives (e.g. selection of materials, manufacturing process, etc.) to the tuning of continuous parameters (e.g. dimensions). The decisions are made to best satisfy a number of design criteria or objectives. Thus, a design scoring method is needed to rank competing solutions. A computer-based design model predicts a system's behavior in terms of performance metrics or performance variables for given values of the design variables. A unique set of states for the design variables constitutes a design alternative, or design solution. The design model must provide a choice mechanism that allows designers to select or manipulate design variables. The design model provides information about the performance characteristics of design alternatives corresponding to different design variable states. When many performance characteristics are of interest, an evaluation or decision model is needed to compare design alternatives. An evaluation model (or decision model) relates performance variable predictions to a value structure, typically expressed by designers in terms of criteria or specifications. The evaluation model assesses design alternatives relative to the value structure. In this paper a goal based approach is adopted (Kim and Wallace 1997, Wallace, et al. 1996). An evaluation model encompasses both the definition of the designer’s preference structure and the comparison of design performance variables to this preference structure. Uncertainty may also be present in both the preference structure and the design performance variables. Further, a preference structure may evolve and grow as the understanding of a design problem changes over time. Finally, the preference structure or

Senin, Wallace, Borland and Jakiela

3

even the evaluation model for a design problem may change with different design viewpoints. Together, the design model and the evaluation model form what we call a design problem model. Once a computer-based design problem model is created, search algorithms may be applied to facilitate the exploration and location of suitable design alternatives. In this work we focus upon genetic algorithms because of their general reliability and lack of assumptions about search space characteristics (Goldberg 1989). 1.2 Problem optimization A computer-based design problem model, consisting of the design model and the evaluation model, can be combined with an optimization algorithm to search for suitable design solutions. The choice mechanism of the design model can be used by the optimization algorithm to make changes and the evaluation model can be used in the optimization objective function. Therefore, it should be possible to automate the optimization problem formulation process. Since design choices can involve a mix of continuous and discrete selections, finding a reliable technique for global optimization is a concern. Further, designers are often not only interested in finding a single best answer. Rather, they would like to obtain a number of reasonable alternatives or even determine if there are classes/families of solutions which will satisfy their requirements. 1.4 Other design problem modeling and optimization issues There are a number of issues related to the characteristics of design models, evaluation models and optimization which we wish to address in addition to mixed parametric and catalog-based design considerations. These general design problem modeling issues are briefly highlighted in this section. Uncertainty Uncertainty is often inherent in design modeling. This uncertainty can arise through lack of information or through natural variability. We wish to provide a generalization of variables so that the relations between variables can be defined independently from their types (e.g., deterministic or probabilistic). Ideally, the computation of a relation should adjust according to the types of data it is processing. Additionally, we often wish to change portions of a design model from very approximate to more detailed without redefining the entire design model.

Senin, Wallace, Borland and Jakiela

4

Decomposition The application of decomposition techniques is common practice in computer-based modeling. Decomposition of a problem into sub-problems can be used to manage complexity by distributing modeling tasks. We wish to facilitate a flexible problem decomposition that facilitates the reintegration of sub-problems so that integrated global modeling and optimization is possible. Additionally, the modeling decomposition approach should facilitate the reuse of sub-problem models in other design problems. Multiple Viewpoints Providing multiple viewpoints of a design model is closely related to model decomposition. Design problems usually involve several different issues and domains. The way a designer views a problem depends upon the aspects of interest at a given moment. In our minds we can rapidly change our representation of a problem or decompose it and reassemble it differently to better suit our current focus or design viewpoint. Each viewpoint involves a different grouping of variables, even though many viewpoints will share common information. If a computer-based model could provide multiple viewpoint capabilities, designers could use a common underlying design model decomposition to create models which highlight different design issues.

2. Prior art 2.1. Design problem modeling Many issues are involved in the modeling of multidisciplinary design problems (Sobieszczanski-Sobieski 1995). A relevant subset of such problems is configuration design, where the design problem consists in selecting components from catalogs (also called catalog selection problems) (Bradley and Agogino 1994, Brown and Hwang 1993, Carlson and Pegg 1995, Vogwell 1990, Ward and Seering 1993). Often, configuration design problems are characterized by a defined and fixed schema, or topology: a skeleton that defines the entities involved in the problem model and the relations that link them together (i.e. their functional role). In this case a catalog selection usually replaces an entity with one that is different, yet functionally equivalent (Brown and Hwang 1993, Senin, et al. 1996, Ward and Seering 1993). Catalog selections can also be performed when uncertainty is associated with the information. Uncertainty may arise from incomplete knowledge or the stochastic nature of the information and should be modeled accordingly (Bradley and Agogino 1994, Kim and Wallace 1997, Vadde, et al. 1992, Wallace, et al. 1996). In a mixed design problem catalog selections are performed along with variations of independent design parameters defined over continuous intervals (Chi and Bloebaum 1995, Senin, et al. 1996).

Senin, Wallace, Borland and Jakiela

5

The framework described in this paper can model configuration, parametric, or mixed design problems. 2.2. Design problem solving Several methods have been used to automatically obtain good solutions using a design problem model. Extensions of the traditional interval calculus can be used to reduce the solution space by progressively eliminating infeasible solutions (Chang, et al. 1994, Chen and Ward 1992, Lin and Ward 1992), or expert systems can be used to perform catalog selections driven by heuristics (Waldron and Chan 1988). Genetic Algorithms (GAs) have also been used in catalog selection problems (Brown and Hwang 1993, Carlson 1996). Holland and Goldberg each provide good introductions to Genetic Algorithms (Goldberg 1989, Holland 1975). Our approach makes use of special types of GAs (Senin and Wallace 1997, Senin, et al. 1996). Other approaches to design problem solving have also been proposed (Chang, et al. 1994, Chi and Bloebaum 1995, Ramakrishnan and Rao 1994, Wu and Azarm 1992). 2.3. Distributed design problem modeling Part of design problem modeling research is devoted to helping product designers collaborate by sharing product information and manufacturing services through formal or informal interactions. Other research projects are intended to provide designers with a formalized framework that manages conflicts between design constraints, thereby assisting designers in making decisions. The SHARE project (Toye, et al. 1993) is aimed to support design engineers or teams by allowing them to gather, organize, re-access and communicate design information over computer networks to establish a "shared understanding" of the design and development process. Software support for collaborative engineering design is provided by Case and Lu (Case and Lu 1996) by treating interactions between designers as a process of discourse. The model treats design commitments made by designers as opinions, subject to review and revision by other designers. It also utilizes agents to identify conflicts between designers and to negotiate the resolution of conflicts. A computer-based design system developed by Sriram, et. al. (Sriram and Logcher 1993) provides a shared workspace where multiple designers work in separate engineering disciplines. In their DICE (Distributed and Integrated Environment for Computer-aided Engineering) program, an object-oriented database management system with a global control mechanism is utilized to resolve coordination and communication problems. Design rationale provided during the product design process is also used for resolving design conflicts (Pena-mora, et al. 1995).

Senin, Wallace, Borland and Jakiela

6

3. Design Problem Modeling and Optimization Framework In this section, a formalism to build computer-based design problem models will be introduced. A modeling framework based on this formalism has been implemented and will be described. In Section 4 it will be linked it to an optimization engine which uses a genetic search algorithm. 3.1 Variables and relations A design model is created using variables and relations between them. A model definition language (MoDeL) has been developed to define these variables and relations. Deterministic and probabilistic variables can be defined using the predefined types available in the framework. Relationships between variables are defined by creating dependencies and by defining the functions that relate them. When the model created with MoDeL is loaded by the framework, a corresponding executable process is created and it can be used to explore design alternatives. The framework visualizes the model in the form of an entity-relationship graph where nodes represent variables and arcs represents relations. The designer can interact with the visual model to establish connections among variables or manipulate the values of variables to observe the effects of the changes. Figure 1 shows a simple model definition for two variables and a relation, along with a corresponding graph visualization as created by the framework when the definition file is loaded. In the example, the variable named A is independent and the variable B depends on A and its dependency is modeled by the relation B = A + 5. A is given an initial value of 2.

Figure 1. The MoDeL definition file for two variables (left) and its graph visualization (right). 3.2 Variable generalization An important feature is the capability to define relations among variables without the need to specify the variable types. A relation (e.g., C = A + B) should be understood

Senin, Wallace, Borland and Jakiela

7

whether A and B are deterministic or probabilistic. This capability allows the designer to change from deterministic data to probabilistic scenarios without redefining relations. The framework supports this capability: when the MoDeL file is loaded, probabilistic variables are identified and the associated relations receive appropriate treatment when compiled into the executable process. Currently, relations involving probabilistic variables are solved using algorithms based on Monte-Carlo simulation and Bootstrap techniques (Efron and R.J.Tibshirani 1993). This process is transparent to the user. When variables are changed from probabilistic to deterministic the underlying executable process is modified automatically by the framework to support the different types of computation. In Figure 2 three variables (A, B and C) are modeled. A and B are independent, but A is deterministic while B is probabilistic. The third variable C depends on the previous two, and its type is not specified a priori in the definition file. In this case, C will be created by the framework as a probabilistic variable. However, if the user changes B to a deterministic variable the framework will change C to a deterministic variable. Thus, although C is always related to A and B by the relation “C = A + B”, this relation may be interpreted differently, depending on the variable types of A and B.

Figure 2. The MoDeL definition file and corresponding graph for a model with a generalized variable (C). 3.3 Solvers A solver is an algorithm which maintains the consistency of a set of related variables so that changes in independent variables are reflected in the model scope according to the defined relations. If a design variable changes (e.g. due to a designer choice) the solver is in charge of propagating the change through all the variables related directly or indirectly to the design variable. In the framework, a solver has been implemented to efficiently resolve large sets of related variables. The propagation of a design variable change occurs only when information is requested by other variables that are directly or indirectly affected by the change. Only the variables needed to provide the information are updated

Senin, Wallace, Borland and Jakiela

8

to be consistent with the design changes. This update mechanism, as illustrated in Figure 3, is invoked by the solver, which ensures that requested information is current. The solver is a major part of the design modeling framework and guarantees an efficient spreadsheet-like behavior.

Figure 3. The update mechanism is shown for a simple 7 variables example. The variables related to the information request (variable G) are parsed. Only the variables which are affected by the modified variables and needed for the requested information are recalculated.

3.4 Modular modeling Variables can be grouped together into modules. Modules are variable containers. Variables can be grouped into modules according to logical, functional or physical component-based decompositions. This process (grouping variables into modules) is a bottom-up decomposition as elementary entities are aggregated to build more complex entities. However, a designer might prefer to use a top-down approach, beginning with the definition of high-level modules and subsequently detailing the low level of variables and relations. Using both the bottom-up and top-down techniques, integrated design models are built by interconnecting modules corresponding to different subproblems. Modules interact by service calls. A module might request information from other modules to perform internal computations and then provide the results as services to other modules. 3.5 Module definition and interaction between modules A module can be defined and populated with variables using the MoDeL language. Figure 4 shows how a simple module built on the example in Figure 2.

Senin, Wallace, Borland and Jakiela

9

Figure 4. Variables can be defined within module boundaries. The visual representation uses a circle to enclose variables and relations belonging to the module.

A module provides its information to other modules through services. The set of services that a module can provide is its output interface. In the current implementation, when the user adds a variable to a module, a service is automatically created to make its information available to other modules. Dependencies which are not fulfilled within a module are also visible from outside of the module and constitute its input interface. Information provided as services by other modules can be used to satisfy such unfulfilled dependencies. The two modules shown in Figure 5 interact through their interfaces. The variable “A”, owned by the module “One”, is made available through the output interface to the module “Two”, fulfilling its input interface for the dependency "X" (used by "C"). The input interface entry “X” of the module “Two” is mapped to the output interface “A” of module "One" to form an integrated model.

Figure 5. Service interactions between two modules. The input interface for dependency "X" in module "Two" is fulfilled by the output interface service "A" provided by the module "One".

Senin, Wallace, Borland and Jakiela

10

Since a module interacts with the other modules only through its interface, its embedded model is not limited to the variable types defined in the framework. The embedded model could contain any custom written programs or pre-existing external applications. A wrapper is a module that has an external application as its embedded model (see Figure 6). The wrapper mediates interactions between the module interface and the external application. By means of the wrapper, external applications can be linked seamlessly to problem models built in the framework.

External Application

Wrapper

Figure 6. The wrapper module provides a bond between the model defined within the framework and an external application. Inputs to the module are rerouted as inputs to the external application and the outputs of the application are sent back to become outputs of the module. 3.6 Parametric and catalog-based design modeling Design variables can be directly manipulated to generate alternative solutions during parametric design. Design variables may be drawn from the set of independent variables defined within modules. If a parameter change, or choice, is mapped to a single independent variable, then choices correspond to a change in the state of the variable. However, a design choice might involve a set of variables, possibly requiring the replacement of a subset of the design problem model, including variables and relations. Such choices are modeled by grouping the variables and relations into the same module; then the choice constitutes a module replacement. Since modules interact only through mapped interfaces, alternative modules providing equivalent interfaces are indistinguishable from the viewpoint of modules interacting with them. Thus, modules embedding very different models can be interchanged, provided they have compatible interfaces.

Senin, Wallace, Borland and Jakiela

11

The framework provides the capability for defining replaceable modules, which are modules that can be replaced with equivalent ones through a single design choice. Replaceable modules defined within the design model are grouped in catalogs. A catalog manages a collection of modules to make available modules whose interfaces are compatible with the given design problem model and correctly maps their interfaces to service requests by other modules in the design problem model. Each time a design choice is made, the selected module within the catalog is placed in the design model as the current instance of the replaceable module. The process of module replacement, as shown in Figure 7, is a catalog selection, thus catalog-based design is achieved through replaceable modules. Replaceable Module out 1 in out 2 Catalog general interface

x y

w

w = in x = out 1 z = out 2

z

w =a x =b y =c z=d Module A

w =g x= e y = none z=f Module B

b

Module C (wrapper) e

c

a

w =l x =h y =i z = none

d

h

g

l

i

f

Catalog

External Application

Figure 7. A replaceable module in a design model is associated with a catalog. In this example, only modules A and B are suitable for selection . Module C does not satisfy the interface requirements for the given problem. Corresponding to a designer's selection, the catalog replaces modules in the design problem, automatically establishing necessary interface connections. The general interface of a catalog, an abstract module, mediates services between modules within the catalog and the rest of the design model. There are a number of catalog selection scenarios that this approach will accommodate. Perhaps the most obvious case involves choosing elements defined as static collections of data. For example, an element in a catalog of standard pipes would include an inside and outside diameter, a cross sectional area, a second moment of inertia, etc. However, one can imagine more complex cases where catalogs should not be limited to static data. Consider a catalog of motors. An element in the catalog (i.e., a specific motor) will certainly have static data, such as its geometry. Other characteristics, such as the operating torque or speed, must be calculated using motor specific models and operating conditions governed

Senin, Wallace, Borland and Jakiela

12

by other aspects of the design. Ideally, each motor in the catalog should be able to calculate its performance according to the operating conditions defined in the design problem. Thus, some catalogs elements should contain embedded models in addition to static data. Modules with no apparent similarity can be arbitrarily placed in the same catalog. However, the interface requirements of the replaceable module in the design model will allow the catalog to determine which of its modules are compatible with the design model. A designer can replace a module corresponding to sets of variables with different embedded models by changing a single parameter in the problem model definition. To relate families of modules corresponding to different levels of abstraction the framework allows for Catalog Hierarchies. In a catalog hierarchy, a module within a catalog can be the parent of another catalog. This module would contain information representing the entire range encompassed by the catalog to which it is associated. For example, a catalog of materials might contain a module “Steel”. In turn, the steel module might be a parent to a catalog of modules for different types of steels. This special “Steel” module would contain information that encapsulates the set of steels contained in the child catalog. Selecting this special module would allow the designer to see the range of performance the family "steel" will provide. An example catalog hierarchy involving engineering materials is illustrated in Figure 8. Engineering Materials Catalog Composites

Steels

Alloys

Steel Catalog Structural Steel

Wrought Steel

Stainless Steel

Wrought Steel Catalog AISI 1020

AISI 1045

AISI 1090

Figure 8. A material catalog hierarchy. At the top level the models represent more generic information while more detailed information can be obtained browsing the levels below. 3.7 Evaluation modeling The design modeling formalism described thus far can also be used to define evaluation or decision procedures. In essence, special modules and variables can be created to provide design evaluation services. There are many possible decision models one could use

Senin, Wallace, Borland and Jakiela

13

(Keeney and Raiffa 1976, Saaty 1980, Thurston 1991). In this work a goal-based approach (Kim and Wallace 1997, Wallace, et al. 1996) is adopted. A brief explanation is provided here as these evaluation models are later used by the search engine to formulate an objective function. According to the goal-based approach, design solutions are evaluated against a set of goals stated as requirements or specifications. Specifications map the designer’s probability of accepting different values of states for performance variables. A specification-like acceptability function (Figure 9) is used to indicate desired performance levels and is compared to the expected design performance. A specification is represented as a piecewise linear function of its associated attribute, ranging from 0 (reject the performance variable value with certainty) to 1 (accept the performance variable value with certainty). A single quantitative output representing the probability that the design’s performance will be acceptable is then computed.

Figure 9. Goal-based acceptability design evaluation. To build acceptability-based evaluation models, the framework provides two special variables: the specification and the criterion. The specification defines acceptability preference functions and the criterion's embedded relation evaluates a performance variable against a specification to determine its acceptability, assuming the evaluation result as its value. Figure 10 shows both MoDeL and the graphical representation for these variables.

Figure 10. The performance variable we are interested in evaluating and the specification variable are connected to the criterion variable (dc), whose internal relation automatically performs the computations necessary to assess the performance state according to the acceptability evaluation model.

Senin, Wallace, Borland and Jakiela

14

In order to group design criteria according to particular design viewpoints, a special type of module called lens has been developed. A lens provides the service of evaluating multiple criteria corresponding to a particular aspect of a design problem. For example, safety, performance and environmental impact viewpoints all may involve a number of design criteria which could be assessed using a lens.

4. Optimization Framework The modeling formalism described to this point provides the ability to create and explore changes in design models involving both continuous parameters and catalog selections. The formalism also provides an evaluation model for articulating design preferences and evaluating designs against these preferences. These elements constitute what we have defined as the design problem model. The design problem modeling framework is linked to an automated search engine which interacts with the problem model, generating candidate solutions and evaluating them using lenses as illustrated in Figure 11.

Figure 11. Integrated design problem modeling and optimization architecture. The results generated by the lenses in the problem model are used by the optimization engine to evaluate an objective score. The engine generates new design choices which are sent as inputs to the problem model to generate a new alternative. The search engine generates new solutions by sending a set of values to the design variables/replaceable modules in the problem model. The search algorithm then evaluates the quality of the design by invoking the design lenses representing different viewpoints

Senin, Wallace, Borland and Jakiela

15

and their corresponding evaluation services. The evaluation results are then used as inputs to an objective function. 4.1. Genetic Algorithms In this work we focus on genetic algorithms (GAs). There were three reasons for this decision. First, the algorithms do not require the specification of a feasible starting point, which is often a difficult task. Second, the mixed search spaces are discontinuous and frequently ill-behaved. However, genetic algorithms do not require any assumptions about the characteristics of the search space (Goldberg 1989, Holland 1975). Finally, we wish to explore algorithms which have the potential to locate several locally optimal design alternatives (in addition to the global solution) in a single optimization. This will provide designers with insight into the design space and freedom to select from a number of possibilities. In the remainder of this chapter a brief overview of GAs and a new algorithm developed through this research is introduced. Then, genetic operators for the design problem modeling formalism are defined. 4.2. Global and Speciating Genetic Algorithms Genetic algorithms are based upon the principles of natural selection. For readers unfamiliar with genetic algorithms, a good introduction to the subject can be found in (Beasley, et al. 1993, Goldberg 1989). Figure 12 illustrates the mechanism of a simple genetic algorithm. eliminate chromosomes not selected for breeding

evaluate fitness

mate mutation

population of chromosomes

select and pair parents

next generation population

Figure 12. Schematic representation of a genetic algorithm. Solutions of a given problem can be represented by a genome. A fitness or objective function evaluates the quality of design solutions. Better individuals are selected to be parents for the next generation of solutions while genomes corresponding to poorer solutions are eliminated from the population. Individuals are paired and mated using genetic operators, such as crossover and mutation, to create a new set of genomes corresponding to new candidate solutions. Some genetic algorithms allow all of the individuals in the old generation to disappear in the new generation, while other GAs

Senin, Wallace, Borland and Jakiela

16

apply “elitism”. That is, the best or a number of the best individuals in a generation always survive to the next generation. The different types of genetic algorithms provide different search characteristics, depending upon their variation of the basic search scheme. There are global genetic algorithms, such as the generational/Simple GA (Simple) or the Steady-State GA (SS). In these algorithms the population tends to converge to a single best solution. Multimodal genetic algorithms (also called speciating GAs or niching GAs) are intended to locate multiple local optima in a single search. There are two basic types: crowding and fitness sharing. Crowding techniques, such as Restricted Tournament Selection (RTS) or Deterministic Crowding (DC), use an additional similarity measure so that only similar organisms compete with each other when eliminating organisms from the population. Fitness sharing techniques use an additional similarity measure plus a niching radius. The fitness of an individual is downrated based upon the number of individuals within its niche. In our experience the performance of fitness sharing techniques is very dependent upon the problem specific definition of the niche radius and the periodicity of the solution space. These different genetic algorithms are described in the literature (Grueninger and Wallace 1997, Mahfoud 1995). In this work both global (simple with elitism, steady state) and multimodal (Restricted Tournament Selection and Deterministic Crowding) will be tested in combination with the design problem modeling formalism. Additionally, a variation of Restricted Tournament Selection GA which we refer to as the Struggle GA [Gruninger, 1997 #48] will be tested. A brief overview of the Struggle GA is provided in the following section. 4.3. Restricted Tournament Selection and the Struggle GA Crowding techniques force competition amongst similar individuals in a population. Restricted Tournament Selection is a particular type of crowding technique where a new individual is compared to a randomly chosen subset of the total population (referred to as a window). The new individual is compared to the most similar individual in the window and replaces it only if it has a better objective score (referred to as elitism). This algorithm is quite effective, but because new individuals are compared to only a subset of the population there is no guarantee that offspring are really compared to and replace the most similar individual in the population. This replacement error can lead to inappropriate diversity loss and reduce search reliability. In the Struggle GA the concept of a population window is eliminated and new solutions are compared to the most similar individual in the complete population. The algorithm is outlined below.

Senin, Wallace, Borland and Jakiela

17

Randomly seed population of genomes Repeat Select parents P1 and P2 (uniform/random selection) Cross P1 and P2 yielding an offspring C Apply mutation with a probability pmut on C, yielding C’ Find the individual R that is most similar to C' in the entire population If fitnessScore(C’)>fitnessScore(R) replace R with C’ Until Stop Criterion

Additionally, a variation of the Struggle GA (Chan 1997) which stochastically alternates between uniform selection of parents and mating similar organisms, will also be tested. The selection strategy is outlined below. The parameter mate closest is true with a probability of Pmateclosest. We will refer to this algorithm as Struggle2 (Str2). Select parent P1 If (Mate Closest == TRUE) Assign the individual most similar to but different from P1 to be parent P2 Else Select P2 uniformly

4.4. Genome representation, genetic operators and similarity measure Before a genetic algorithm can be applied to a problem, a genome representation and appropriate genetic operators must be defined. Typically, the genome representation is defined in a very problem specific manner. In this case, we wish to develop a general representation for design problem models created using the modeling framework. This will allow the process of encoding design problems onto genomes to be automated. There are several genome representations and genetic operators that one might choose from. Binary and real number encodings were evaluated against customized genome representations. Several types of genetic operators were also tested for each genome representation. Additionally, most of the multimodal crowding techniques require a similarity measure to determine which individual in the population is closest to a new candidate solution and several measurement techniques were evaluated. The genome representation, genetic operators and similarity measure presented in the following sections performed best on a broad suite of design problems modeled using the framework.

Senin, Wallace, Borland and Jakiela

18

4.4.1. Genome representation In general, design problems modeled using the framework will include both continuous parameters and discrete module selections from catalogs. In the early stages of this research project, genomes were binary strings where segments of the string encoded the value of different design variables. Genetic operators were defined to modify these strings. However, as a generalization, we have found that genomes which are similar or identical to the actual variables gave better search performance. For example, if one uses a binary representation for a real number a resolution for the variable must be chosen, limiting its definition over the search space. Using binary representations to encode module selections from catalogs also presents similar issues. However, there is no restriction on the type of information that can be used in a genome or in a genome shape, provided appropriate 'abstract' genetic operators can be derived. In our approach, the continuous parameters, both deterministic or probabilistic are defined by either a single real parameter or set of parameters. These parameters are represented in genome using their actual real number values. Similarly, the modules selected from catalogs are also directly encoded in the genome. This genome representation is shown in Figure 13.

Figure 13. The genome developed for the framework is made of two parts. The first is a list of values corresponding to continuous design parameters, while the second part is a list of catalog selections for replaceable modules. 4.4.2. Similarity measure and genetic operators Measuring the similarity of individuals is not a trivial problem in a mixed variable multidimensional search space. The notion of similarity is quite abstract as we wish to measure the difference between very different design alternatives. In this work the similarity measure is very important as it is used by speciating GAs to determine which individual a new organism will replace. The most effective similarity measure that was developed for the genome representation separately measures continuous variable similarity (i.e. similarity of two values for the

Senin, Wallace, Borland and Jakiela

19

same design parameter) and catalog selection similarity, subsequently combining the two measures into an overall metric. Similarity of two real number parameters

Euclidean distance is an obvious similarity measure for real numbers. This measure is defined in equation (1) and illustrated in Figure 14. Dist(A, B) = A− B Where the real values of A and B are mapped to a 0-1 scale.

(1)

Dist(A,B)

A

B

Figure 14. Euclidean distance between two variables defined in a one-dimensional space. Similarity of two catalog selections

The problem of determining a meaningful distance metric between two catalog selections is more complex. It is difficult to define a general measure for the difference between two modules, which may contain both embedded models and sets of static data. In order to resolve this dilemma the structure of a catalog is exploited. We infer meaning upon the relative location of modules within a catalog. This notion is illustrated in Figure 15 (a). In this catalog, modules representing pipe sections are ordered such that relative location is tied to conceptual similarity. We define this type of catalog as an ordered catalog. In Figure 15 (b) the same modules are organized differently within the catalog and their relative locations do not have meaning. We define this structure as an unordered catalog and presume that all modules in the catalog are equidistant.

Figure 15. Examples of ordered catalog (a) and unordered catalog (b).

Senin, Wallace, Borland and Jakiela

20

Consequently, the distance between two modules within a single catalog is given by equation (2) and illustrated in Figure 16. The designer or catalog creator is responsible for judging the catalog type. β

Dist(A, B) = index(A) − index(B) ⋅Span

(2)

Where Span is a constant belonging to each catalog and to all of its modules, representing the distance between two adjacent modules in the catalog (i.e. unit distance). For a single catalog the span is equal to 1. Modules are stored in catalogs with an index which is used to determine the position of the module in the catalog. Beta is one for an ordered catalog, and zero for unordered catalogs. Catalogs may also be organized into hierarchies. If the hierarchy is used to model abstraction it is assumed that the breadth of the subordinate catalog is captured by its parent module. Thus we presume that the relative distance between modules in a catalog decreases with hierarchy depth (i.e. the span decreases). These ideas are illustrated in Figure 17. The span of the top level catalog is defined as the number of levels in the hierarchy, while the span of the second level catalog is generated using the span of the parent module and the number of modules contained in the child catalog. However, if the child catalog is unordered (β=0), its span is half the span of the parent module.

Figure 16. Distance evaluation for two modules belonging to the same ordered catalog.

Senin, Wallace, Borland and Jakiela

21

Figure 17. The span of modules in a catalog is defined so that the breadth of the catalog is equal to the span of the parent module. Furthermore, the modules belonging to the child "Catalog 2" are equidistant from the parent module A'. Thus, the distance between any module X and A' is the difference of the spans of the two catalogs, as illustrated in Figure 18.

Figure 18. The module X belonging to Catalog 2 is equally distant from A’ as any other module in the child catalog. These measures can be used to define the distance between any two modules in a hierarchy of catalogs as a combination of the previous definitions, as shown in Figure 19.

Senin, Wallace, Borland and Jakiela

22

Figure 19. Modules A' and B' are the two modules from which the branches leading to the two selected modules A and B originate. The distance between A and B is obtained by adding the distance between A’ and B’ and the distances from A’ to A and from B’ to B.

The distance measurement illustrated is based upon assumptions interpreting catalog hierarchies as "family trees". If a catalog hierarchy is based on principles other than family abstraction other similarity measures may be needed. 4.4.3. Combining distances to measure overall similarity After defining the distance measures for comparing two real numbers and two catalog selections, these individual distances must be aggregated to form an overall similarity measure. A weighted sum of the individual distances was adopted, as defined in equation (3). No.var s.

DistAllContVars(G1, G2 ) =

∑ a − b ⋅w i

i

i

i =1 No.Sels

DistAllCatSels(G1,G 2) =

 catDist(uj,vj )  ηj MaxDistj 

∑  j=1

TotalDist(G1,G2) = DistAllContVars(G1,G2) + DistAllCatSels(G 1,G2 ) Where: G1, G 2 are the two genomes ai, bi are the values of G1 and G 2 for the ith design variable w i is a normalized weight for the ith design variable ηi is a normalized weight for the jth catalog selection catDist is the catalog distance function for two modules uj , v j are the modules contained in G1 and G 2, for the jth catalog selection MaxDistj is the maximum possible distance between two modules in the catalog hierarchy for the jth catalog selection

(3)

Senin, Wallace, Borland and Jakiela

23

The weights are used to assign importance to each distance evaluation and thus can be used to force the speciation process to consider some design parameters as more important than others in the distance evaluation. For example, if one assigns a weight of 0.7 to a material selection in a multiple variable optimization, 70% of the overall distance will be allocated to represent similarity in material choice. Thus, the alternatives generalized by multimodal algorithms will emphasize material alternative. However, in general we have not found a need to differentially weight distances. The weights are constrained according to equation (4). No.var s .

∑w =1 i

i =1 No.Sels .

∑ η =1

(4)

j

j =1

Genetic operators

The genetic operators mate parents to create new offspring. Typically crossover operators are defined to combine the attributes of two parents into a child while mutation operators randomly alter offspring after crossover. In previous experiments (Grueninger and Wallace 1997) a type of crossover known as BLX0.5 (Eshelman and Schaffer 1992) has performed well for real number genomes. The BLX algorithm is illustrated in Figure 20.

d

d d

A

M

B

Figure 20. BLX crossover between A and B. The offspring is randomly selected from the interval of width 2d, centered in M, that is the average of A and B. A crossover operator analogous to BLX was defined for catalog selections. The algorithm is illustrated in Figure 21.

Senin, Wallace, Borland and Jakiela

24

A gaussian mutation operator was also defined. This mutator randomly selects new values for design parameters and catalog selections in the genome, following a gaussian distribution. For each entry in the genome, a new random value is selected: the random value is determined using a gaussian distribution instead of an uniform distribution. The mutation operator applies to both continuous variables and catalog selections in the genome.

Figure 21. The distance midpoint M corresponds to a module in the catalog hierarchy that is equidistant from the two modules A and B. The crossover operation randomly selects in the hierarchy, from the modules in the 2d interval centered on the module M (gray modules).

4.5. Objective formulation The framework provides criteria which evaluate the quality of performance variables. Criteria can be bundled into lenses to reflect different design evaluation viewpoints. The lenses are used by the optimization engine to automatically build an objective function. For the acceptability model currently implemented using the framework, the objective is to maximize the likelihood of obtaining acceptable performance in all criteria. Thus the optimization engine formulates an objective function using equation (5). Maximum Fitness = nlog 2 pmin n

Design Fitness = Maximum Fitness +

∑ log p

(5)

2 i

i=1

where: n is the number of design criteria; pmin is a small non-zero probability (0.00001) which is substituted for any pi less than this amount; and pi is the probability of acceptance arising from the evaluation of the ith design criterion. This formulation is justified in (Wallace, et al. 1996). If other evaluation models are used to define design specifications (e.g., utility theory) other formulations would be substituted for equation (5).

Senin, Wallace, Borland and Jakiela

25

5. Example Problems In this section example design problem models defined using the framework are described. These models are used in the final section as an optimization test suite. 5.1. Shekel’s foxholes This two dimensional function, illustrated in Figure 22 has 25 equally spaced peaks of varying height.

Figure 22. The leftmost peak is the global optimum. There are a total of 25 peaks in the defined interval. This continuous real variable function is included as it is a well know test function from DeJong’s dissertation (DeJong 1995) and can be used to test both global optimization and niching performance. The function is given in equation (6). z( x ,y ) =

1 1 + 50

∑

1 i =1 1 + i + (x − ai ) 6 + (y − bi ) 6 25

,

(6)

where a i = 16[(i mod5 ) − 2] and bi = 16[ (i ÷ 5) − 2] . The MDL for defining the problem using the framework is included in Appendix A. The problem, implemented using a single module, is visualized through the framework GUI as shown in Figure 23.

Senin, Wallace, Borland and Jakiela

26

Figure 23. The framework GUI for the Shekel's foxholes problem. The X and Y coordinates can be changed interactively to observe the change of Z. The open criterion browser compares the current value of the Z variable (a delta distribution) with its specification. The integrated optimization GUI is illustrated in Figure 24. The process of encoding the problem model for the search is completely automatic .

Figure 24. The browser shows the history of the optimization process plotting the best, average and worst fitness score vs. generation number. 5.2 Winch/truss lift-system design This example, illustrated in Figure 25, is a mechanical design problem. A winch, powered by a battery, is used to lift a load up to a platform. The load W and the lift height LH are the only given attributes for the design. All other characteristics of the apparatus (the

Senin, Wallace, Borland and Jakiela

27

truss geometry, the structural sections, the truss material, the winch, the battery and the cable) are to be determined through the design search. The design problem is mixed, involving both continuous variables (overall truss geometry) and numerous discrete module selections from catalogs (e.g., the winch and truss materials). The catalog selection problem is designed to present a deceptive search problem with many local solutions (9 within 99.5% and 31 within 98.3% of the global optimum).

Horiz.Member

g Dia

.Me

mb

er

Figure 25. Schematic representation of the lift system design problem components. The modules for the lift-system problem as implemented in the framework are shown in Figure 26. Replaceable modules have a slightly lighter color and have a second label indicating the specific module being chosen from its corresponding catalog hierarchy.

Figure 26. The lift-system problem as it looks once it is loaded into the framework.

Senin, Wallace, Borland and Jakiela

28

The catalog hierarchies used in the design problem are shown in Figure 27.

Figure 27. Catalog hierarchies used in the lift-system problem. Each catalog contains numerous modules corresponding to different alternatives. Each catalog contains several modules. Modules in the material catalogs contain static data corresponding to material properties while modules in the sections and winch catalogs contain mathematical models. Modules for different beam sections are shown in Figure 28.

Figure 28. Modules representing different cross sections for the truss members using different embedded models. All of the continuous variables in the problem are related to the truss geometry, as seen in Figure 29. The light colored variables are independent while the dark variables depend on other variables.

Senin, Wallace, Borland and Jakiela

29

Figure 29. The variables in the module (enclosed by the "topology" gray disc) are connected to external variables belonging to other modules. These latter variables are visually represented outside of the module area. All design variables and the input and outputs of modules selected from catalogs are summarized in Table 1. Table 1. Design variables for the lift system problem Design variables - continuous Name Description L length of horiz. element q truss angle

Type delta delta

Design variables - catalog selections Name starting inputs catalog horizontal Sections section diagonal section Sections horizontal Materials material diagonal Materials material winch Winches lift height, load weight cable

Cables

-

Search Limits 1000mm - 3000mm 10 - 50 degrees

outputs A, I A, I yield strength, E, cost yield strength, E, cost lift time, cost, ampere consumption max. allowable weight, cost

Senin, Wallace, Borland and Jakiela

battery

30

Batteries

ampere consumption

discharge time, cost

There are three lenses with different evaluation viewpoints: safety, performance, and cost. Each of these viewpoints contains a number of specifications which must be satisfied. These are summarized in table 2. Thumbnail visualization of the lenses as provided by the framework GUI is shown in Figure 30. The optimization setup for the problem is shown in Figure 31.

Figure 30. The lenses for the lift-system problem list the criteria used to evaluate design solutions. The thumbnails show how the current design solution is performing: cost and safety (cable tension) are receiving a low evaluation score. Table 2. Design criteria for the lift system problem Lens cost

Criterion Descriptio Performance Specification n variable cost total cost of Total cost the design 130 200

safety

Ymax

vertical deflection of the truss free extremity

Ymax 2

5

Senin, Wallace, Borland and Jakiela

safety

normal stress a

safety factor stress on horizontal member safety normal safety stress b factor stress on diagonal member safety buckling b safety factor buckling on diagonal member safety cable safety stress factor max. load on winch cable performance operation total time of time activity to lift N loads performance battery safety time factor battery duration with respect to the total time of activity

31

normal stress safety factor 1.5

3

1.5

3

2

4

2

3

normal stress safety factor

buckling safety factor

max. load safety factor cable

total operation time battery duration safety factor

6000 8000

15 25

Senin, Wallace, Borland and Jakiela

32

Figure 31. In the upper right corner of the GUI window the variables being optimized are listed. The uppermost part lists design parameters, while the lower section shows catalog selections.

6. Optimization Results and Discussion In this section the global and niching search performance of the framework is characterized for the example problems implemented using the framework. Two global genetic algorithms (elitist Simple and Steady-State) plus four niching algorithms (Deterministic Crowding, Restricted Tournament Selection, Struggle and Struggle2) are compared. Although results are provided for only the two example problems described in the previous section, the trends are consistent with tests performed on a broader suite of test problems. For all algorithms a crossover probability of 1.0 and a mutation rate of 0.03 were used for both continuous variables and catalog selections. Unless otherwise noted the population size was 20 as we believe that small populations will be preferred for computationally intensive design applications. The window size for Restricted Tournament Selection was half of the population (10). The Pmateclosest (probability of performing special mating) parameter for the Struggle2 GA was 0.2. Runs were terminated after 300 generations (6000 evaluations) and all results are averaged over ten runs. 6.1. Global Optimization Performance In global search performance we were interested in two traits: the ability to locate the true global optimum and the number of evaluations required to locate it.

Senin, Wallace, Borland and Jakiela

33

Probability of correct solution (within 99.99%)

While all algorithms were able to locate the global optimum for the Shekel’s foxholes problem, not all of them succeeded in the lift-system problem. Figure 32 illustrates the reliability of the different algorithms for the lift-system problem.

1 0.8 0.6 0.4 0.2 0 DC

RTS

STR

STR2

Simple

SS

GA type

Figure 32. Probability of converging within 99.99% of the known global optimum in 300 generations. A correct solution for the lift-system problem is defined as the optimal selection of modules from catalogs and fitness convergence to within 99.99% of the optimal score (which is tied to the continuous variables). The results indicate that while all of the multimodal algorithms consistently find the correct solution, the global algorithms (Simple and Steady-State) are less reliable. Observation of these test problems and in other work (Grueninger and Wallace 1997) suggests that the poor performance of the Simple GA is due to a relatively slow hill-climbing characteristic, while the Steady -State algorithm tends to rapidly lose population diversity and thus may converge to a local optima. With a zero mutation rate the performance of the Steady-State algorithm is much worse whereas the other algorithms (in combination with the representation used by the framework) are not adversely affected. This is because the other algorithms maintain sufficient diversity for crossover to effectively search the problem space. Figure 33 shows the number of generations needed to converge to a solution within 99.99% of the optimal score for both the Shekel’s foxholes and the lift-system problems. The Simple GA consistently required the most evaluations and never reached the 99.99% criterion for the lift-system. The performance of Deterministic Crowding and the SteadyState GAs differs greatly for the two problems. In addition to being reliable, Struggle, Restricted Tournament Selection, and Struggle2 are consistent in their relatively low number of evaluations. The Struggle2 algorithm requires fewer evaluations than the Struggle GA because of the stochastic mate-closest selection strategy.

Convergence to 99.99% of global optimum (# generations)

Senin, Wallace, Borland and Jakiela

34

120 100 80 60 40 20 0 dc

rts

str

str2

simple

ss

GA type

Convergence to 99.99% of global optimum (# generations)

(a) foxholes 300 250 200 150 100 50 0 dc

rts

str

str2

simple

ss

GA type

(b) - lift-system Figure 33. Number of generations required to obtain a solution within 99.99% of the known global optimum. Note that the Simple GA never converged within 300 generations on the lift-system problem. 6.2. Multimodal optimization performance In this section only the multi-modal algorithms (DC, RTS, Struggle, Struggle2) are considered. In the previous section these algorithms were shown to provide robust global optimization characteristics. Both example problems have several local optima. In fact, there are more local optima than individuals in the search population (20 individuals). Therefore, it is not possible to find all solutions in one optimization, but we are interested in finding as many solutions as possible within a single search and to consistently find the better ones. Figure 34 (a) through (d) compares the ability to identify local optima (species) for the Shekel’s foxholes problem (25 known species). The optima are in order of decreasing quality.

Species identified (% of runs)

Senin, Wallace, Borland and Jakiela

35

100 80 60 40 20 0 1 2 3 4 5 6 7 8 9 10111213141516171819 202122232425 Species ID

25

23

21

19

17

15

13

11

9

7

5

3

100 80 60 40 20 0 1

Species identified (% of runs)

(a) Deterministic Crowding (DC)

Species ID

Species identified (% of runs)

(b) Restricted Tournament Selection (RTS)

100 80 60 40 20 0 1 2 3 4 5 6 7 8 9 10111213141516171819202122232425 Species ID

Species identified (% of runs)

(c) Struggle (Str)

100 80 60 40 20 0 1 2 3 4 5 6 7 8 9 101112 13141516171819202122232425 Species ID

(d) Struggle (Str2) Figure 34 (a)-(d). Ability to identify species in the foxholes problem for different types of speciating GAs.

Senin, Wallace, Borland and Jakiela

36

100 80 60

31

29

27

25

23

21

19

17

15

13

11

9

7

5

3

40 20 0 1

Species identified (% of runs)

Similar plots for the lift-system problem are in Figure 35 (a) through (d).

species ID

100 80 60 40

31

29

27

25

23

21

19

17

15

13

11

9

7

5

3

20 0 1

Species identified (% of runs)

(a) Deterministic Crowding (DC)

Species ID

29 31

species ID

100 80 60

species ID

(d) Struggle (Str2)

27

25

23

21

19

17

15

13

11

9

7

5

3

40 20 0 1

Species identified (% of runs)

(c) Struggle (Str)

31

27 29

25

23

21

19

17

15

13

11

9

7

5

3

100 80 60 40 20 0 1

Species identified (% of runs)

(b) Restricted Tournament Selection (RTS)

Senin, Wallace, Borland and Jakiela

37

Figure 35 (a)-(d). Ability to identify species in the lift problem for different types of speciating GAs. Figure 36 (a)-(b) indicates the average number of species (local solutions) found by the algorithms for the foxholes and lift-system problems in a single search.

# species found

20 15 10 5 0 dc

rts

str

str2

GA type

# species found

(a) foxholes problem 8 6 4 2 0 dc

rts

str

str2

GA type

(b) lift-system problem Figure 36 (a)-(b). Number of species identified by the genetic algorithms, averaged over 10 runs. The species are retrieved from the final population of each run. The data indicate that although Deterministic Crowding reliably locates the global optima, it is relatively poor at locating other solutions (average of 3.9 for the foxholes problem, average of 1.44 for the lift problem). Previous studies reveal that this is caused by replacement errors which slowly eliminate local solutions over the course of a search. Restricted Tournament Selection reliably finds the top few solutions but generates a small spectrum of solutions (average of 5.3 for the foxholes, average of 3.3 for the lift-system). Although less prone to replacement errors than Deterministic Crowding, the limited number of local optima are also attributable to the same phenomena. Both the Struggle and Struggle2 algorithms consistently locate the better local solutions and many alternatives in a single search (average of 18 - Struggle and Struggle2 - for the foxholes; average of 6.6 -Struggle- and 5.9 -Struggle2 - for the lift-system).The superior ability to locate many alternatives is a result of minimizing replacement errors. In Figure 37 speciation results for the Struggle2 GA using a population size of 50 (more than the number of known local solutions) and 500 generations is shown for the foxholes

Senin, Wallace, Borland and Jakiela

38

Number of individuals in final population

problem. These plots show the ability to consistently locate all the 25 local optima in a single search.

5 4 3 2 1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Species ID

Figure 37. Species identified after 500 generations by the Struggle2 genetic algorithm for the foxholes problem. All species are present and converged in the final population.

7. Conclusions An integrated modeling and search framework was proposed for product design problems which involve simultaneous choices from discrete sets of alternatives (catalog-based design) and the setting of design parameters defined over continuous intervals (parametric design). The modeling formalism provides for the creation of design models to predict a design performance and evaluation models for relating performance to a value structure. Mechanisms for defining variables and relations which permit variable generalization have been developed. Modules are defined to encapsulate variables and relations according to logical, functional or physical component-based problem decompositions. Modules interact with other modules through services mediated by their interfaces and a collection of interconnected modules, each of which represents subproblem models, form an integrated design model. Modules are collected in catalogs, thereby allowing entire modules in a problem model to be changed as a single variable. Because modules encapsulate their variables and relations, both parameters and mathematical models can be modified through catalog selections. The design problem is linked to a genetic search engine. The search engine uses the design and evaluation models to automate the formulation of the optimization problem. A genome representation , crossover operator and similarity measure are defined for the framework. The framework implementation and model definition language was demonstrated to model a continuous variable problem (Shekel's foxholes) and a mixed variable problem i.e. continuous variables and catalog selections (lift-system). The efficacy of the

Senin, Wallace, Borland and Jakiela

39

representation/search approach was tested for these problems using several genetic search algorithms, including Simple, Steady State and crowding algorithms. The results observed for the two example problems are representative of the performance that has been observed on a variety of problems modeled and optimized using the framework. Neither of the global search algorithms (Simple or Steady State) were as reliable as the crowding techniques in finding the global solution for the mixed problem. Restricted Tournament Selection and the Struggle2 algorithms consistently required relatively low numbers of evaluations to locate the global optima. The Struggle and Struggle2 outperformed other multimodal algorithms (Restricted Tournament Selection and Deterministic Crowding) in their ability to locate the better local solutions and a wide variety of alternatives during a single search. Therefore, in combination with the proposed design problem modeling framework, the Struggle2 algorithm provides the best combination of characteristics: robust global solution location; a relatively low number of evaluations; and the ability to locate a large number of locally optimal alternatives.

8. References D. Beasley, D. Bull, and R. R. Martin, “An Overview of Genetic Algorithms: Part 1, Fundamentals,” University Computing, vol. 15, no. 2, pp. 58-69, 1993. S. R. Bradley and A. M. Agogino, “An Intelligent Real Time Design Methodology for Component Selection: An Approach to Managing Uncertainty,” Journal of Mechanical Design, vol. 166, no. 4, pp. 980-988, 1994. D. R. Brown and K.-Y. Hwang, “Solving Fixed Configuration Problems with Genetic Search,” Research In Engineering Design, vol. 5, no. 2, pp. 80-87, 1993. S. E. Carlson, “Genetic Algorithm Attributes for Component Selection,” Research in Engineering Design, vol. 8, no. 1, pp. 33-51, 1996. S. E. Carlson and T. A. Pegg, “Genetic Operators for Catalog Design,” proceedings of Design Automation Conference, DE-Vol. 82, pp. 65-71, 1995. M. P. Case and S. C.-Y. Lu, “Discourse model for collaborative design,” Computer-Aided Design, vol. 28, no. 5, pp. 333-345, 1996. K. K. Y. Chan, “An investigation on speciating genetic algorithms in multimodal optimization,” Massachusetts Institute of Technology, 1997. T.-S. Chang, A. C. Ward, J. Lee, and E. H. Jacox, “Distributed design with conceptual robustness: a procedure based on Taguchi's parameter design,” proceedings of Concurrent Product Design, DE-Vol 74, pp. 19-29, 1994. R. Chen and A. C. Ward, “Introduction to Interval Matrices in Design,” proceedings of Design Theory and Methodology, DE-Vol. 42, pp. 221-227, 1992. H.-W. Chi and C. L. Bloebaum, “Mixed variable optimization using Taguchi's orthogonal arrays,” proceedings of ASME Design Engineering Technical Conference, DE-Vol. 82, 1995.

Senin, Wallace, Borland and Jakiela

40

K. A. DeJong, “An analysis of the behavior of a class of genetic adaptive systems,” University of Michigan, 1995. B. Efron and R.J.Tibshirani, An introduction to the Bootstrap: Chapman & Hall, 1993. L. J. Eshelman and J. D. Schaffer, “Real-Coded Genetic Algorithms and IntervalSchemata,” in Foundations of Genetic Algorithms 2, L. D. Whitly, Ed. San Mateo: Kaufmann Publishers, 1992, pp. 187-202. D. E. Goldberg, Genetic Algorithms in Search, Optimization, and Machine Learning. New York, NY: Addison-Wesley Publishing Company, Inc., 1989. T. Grueninger and D. R. Wallace, “Multimodal optimization using genetic algorithms,” MIT CADLab internal report, 1997. J. Holland, Adaptation in Natural Selection and Artificial Systems. Ann Arbor, Michigan: The University of Michigan Press, 1975. R. L. Keeney and H. Raiffa, Decisions with Multiple Objectives: Preferences and Value Tradeoffs. New York, NY: John Wiley and Sons Inc., 1976. J. B. Kim and D. R. Wallace, “A Goal-oriented Design Evaluation Model,” proceedings of ASME Design Engineering Technical Conference, DETC97/DTM-3878, 1997. B.-T. Lin and A. C. Ward, “Introduction to design inferences over sets of intervals,” ASME Design Theory and Methodology, vol. 42, pp. 187-192, 1992. S. Mahfoud, “Niching Methods for Genetic Algorithms,” University of Illinois at UrbanaChampaign, IlliGAL Report 95001 1995. F. Pena-mora, R. Sriram, and R. Logcher, “Conflict mitigation system for collaborative engineering,” AI EDAM special issue of Concurrent Engineering, vol. 9, no. 2, pp. 417429, 1995. B. Ramakrishnan and S. S. Rao, “An efficient strategy for the robust optimization of large scale nonlinear design problems,” Advaances in Design Automation, DE-Vol 69, no. 2, , 1994. T. L. Saaty, The Analytic Hierarchy Process. New York, NY: McGraw-Hill Book Company, 1980. N. Senin and D. R. Wallace, “A framework for mixed parametric and catalog based product design,” MIT CADLab Internal report 97.02, 1997. N. Senin, D. R. Wallace, and M. J. Jakiela, “Mixed continuous variable and catalog search using genetic algorithms,” proceedings of ASME Design Engineering Technical Conferences, Irvine, CA, 1996. J. Sobieszczanski-Sobieski, “Multidisciplinary design optimization: an emerging new engineering discipline,” in Advances in Structural Optimization. Netherlands: Kluwer Academic Publishers, 1995, pp. 483-496. D. Sriram and R. Logcher, “The MIT DICE project,” IEEE Computer, pp. 64-65, 1993.

Senin, Wallace, Borland and Jakiela

D. L. Thurston, “A Formal Method for Subjective Design /Evaluation with Multiple Attributes,” Research in Engineering Design, vol. 3, no. 2, pp. 105-122, 1991. G. Toye, M. R. Cutkosky, J. M. Tenenbaum, and J. Glicksman, “SHARE: a methodology and environment for collaborative product development,” proceedings of Proceedings of the IEEE Infrastructure for collaborative enterprise, Morgantown, West Virginia, pp. 33-41, 1993. S. Vadde, J. K. Allen, and F. Mistree, “Catalog design: design using avalilable assets,” Advances in Design Automation, DE-Vol.44, no. 1, pp. 345-354, 1992. J. Vogwell, “Computer-aided component selection: a new and expanding research activity,” Computer-aided Design, vol. 22, no. 5, pp. 308-310, 1990. M. B. Waldron and C. W. Chan, “Object oriented system for component selection,” proceedings of International Computers In Engineering Conference, San Francisco CA, pp. 57-62, 1988. D. R. Wallace, M. Jakiela, and W. Flowers, “Design search under Probabilistic Specifications using Genetic Algorithms,” Computer-aided Design, vol. 28, no. 5, pp. 405-421, 1996. A. C. Ward and W. P. Seering, “The Performance of a Mechanical Design 'Compiler',” Journal of Mechanical Design, vol. 115, no. 3, pp. 341-345, 1993. B.-C. Wu and S. Azarm, “A reduction method for non-hierarchical optimization-based design,” Advances in Design Automation, DE-Vol.44, no. 1, 1992.

41

Senin, Wallace, Borland and Jakiela

Appendix A Shekel’s foxholes MoDeL definition file Module "foxholes" ( UpdateFile "update" Variable "X" (Delta {0}) Variable "Y" (Delta {0}) Variable "Z" ( Delta {0} Dependency "X" (ConnectedTo "X") Dependency "Y" (ConnectedTo "Y") DefineUpdateFunction "UpdateZ" ( int i; float ai[25],bi[25]; for (i=0; i