Mixed continuous and discrete catalog-based design ...

Mixed continuous and discrete catalog-based design modeling and optimization Nicola Senin, David R. Wallace, and Nicholas Borland Computer-aided Design Laboratory, Room 3-435, 77 Massachusetts Avenue, Massachusetts Institute of Technology, Cambridge, MA, USA 02139. Email: [email protected]

Abstract: Product design typically involves a mix of custom, semi-custom, and standard components. A mathematical model of a design problem may also mix custom models and cataloged models that represent standard elements or families of elements. Further, design problem models are often decomposed into subsystems and delegated to appropriate experts, each of whom may use their own preferred modeling and analysis tools. A degree of coupling usually exists between these subsystems so they cannot be optimized independently, yet it can be difficult to understand their integrated system performance. Ideally, it would be possible to link this set of heterogeneous and distributed models to represent the complete product in a way that facilitates rapid exploration of design tradeoffs and global optimization. This paper describes a general object-based system modeling formalism for product design. It allows the convenient integration of custom models, models from catalogs, and a wide variety of software modeling and analysis tools distributed over the Internet. Subsystems operating in different locations using different modeling tools are integrated, and mixed variable optimization using custom, semi-custom and standard elements is made possible. A bottle design problem is implemented using a software prototype called DOME (Distributed Object-based Modeling and Evaluation), linking models in ProEngineer, Excel, TEAM (life-cycle analysis software), and DOME custom models. Keywords: object-based modeling, distributed design, system modeling, integrated modeling, catalog optimization.

1. INTRODUCTION Figure 1 illustrates a scenario for a company that designs beverage containers for many customers. Design capabilities are distributed geographically. In-house, the design configuration engineers select the main design parameters (materials, container type, dimensions) and perform the final evaluation of each design alternative (trading off cost, safety, capacity and environmental impact). The container geometric modeling and related computations are outsourced to an industrial design firm, while environmental impact assessment and life cycle modeling is provided by a consultant. Each design

participant uses different software tools, models, and data, ranging from solid modelers to spreadsheets. ProEngineer Industrial Design CAD and assembly Environmental Consultant Qualifies for Eco-label Ecobilan TEAM

Design configuration Current Design Option DOME

Strength Analysis Pressure OK EXCEL

Figure 1; Design scenario – Participants in the bottle design team are distributed geographically. Each presents their own viewpoint and software tools, but an integrated understanding of the complete product is needed. The distributed enterprise needs to design a new beverage container for a customer that requires a different fluid volume and internal pressure. They would like to explore design options, trading off cost, styling, safety, material, and environmental considerations—all of which are highly interrelated but addressed by different participants. In current practice obtaining such an integrated view for just a single alternative is at best very time consuming, typically requiring months to coordinate and resolve. At worst, obtaining an integrated system view for making global tradeoffs is deemed intractable and decisions are left to intuition. The goal of this work is to facilitate the construction of integrated design models that rapidly predict overall product performance, making it plausible to trade-off between many options and perform global optimization. An integrated model can be created by allowing each design participant to embed their own software tools and models into modules. Modules behave like distributed objects, providing functionality in the form of services, which are made publicly available over the Internet while hiding their own local implementation. Each design participant defines an interface declaring what services they can provide and what services must be provided to them. This interface is published on the Internet so that their services can be used by other designers as building blocks. Ultimately, a distributed model that predicts integrated behavior emerges. Local state changes propagate through the Internet via service calls, sequenced and coordinated by locally defined service exchange relationships. Once such integrated modeling capabilities are available, decision support and optimization can be introduced to facilitate the exploration of alternatives from an overall system viewpoint. The distributed enterprise scenario for the bottle design will be used as an example to illustrate the general object-based modeling formalism, which has been developed.

Then, the bottle design problem will be implemented using a software prototype of the formalism called DOME (Distributed Object-based Modeling and Evaluation).

2. PREVIOUS WORK Engineering design is a multidisciplinary activity involving the cooperation and teamwork of many designers and tools in a distributed environment. There are many examples of research efforts to develop distributed systems for collaborative engineering [Wong et al.1993], [Petrie et a.l.1994]; [Toye et al.1994]; [Molina et al.1995]; [Pena-mora et al.1995], [Sobieszczanski-Sobieski 1995], [Bliznakov et al., 1996], [Case et al. 1996], [Cutkosky et al.1996], [Dabke et al.1998], [Kim, et al. 1998], [Rajagopalan et al.1998], [Wang et al.1998]. This paper is also founded on a vision for distributed collaborative modeling [Pahng et al. 1997], [Pahng et al. 1998]. A central issue for collaborative design is the model representation. An overview of current approaches can be found in Hsu and Woon [Hsu et al. 1998] One powerful representation for integrated modeling is the blackboard architecture [Reddy et al. 1998]. However, in distributed modeling one of the key challenges is that different participants use different tools and representations. Further, the scope of most product design problems makes it very difficult to establish an explicit global system model. Large models benefit from modular decomposition, and modularity can be achieved through object oriented representations. Works by Gorti [Gorti et al. 1998] and Yoshikawa [Yoshikawa et al. 1994] are examples. When using a modular decomposition based on function, catalog selections substituting modules can be used to replace functionally equivalent components [Brown et al. 1993], [Ward et al. 1993], Senin et al. 1996], [Harmer et al. 1998]. It is also possible to coordinate object services using locally negotiated distributed service relations, so that overall system behavior is emergent (in contrast to a central explicit system model). Thus, this work adopts an object-based approach.

3. MODELING FORMALISM The formalism structures models by decomposing them into objects called modules. We often refer to these as “DOME modules” and call a set of interacting modules “DOME models” in reference to the prototype software implementation called DOME (Distributed Object-based Modeling and Evaluation). The main characteristics of the formalism are outlined in this section. 3.1. Modules and Services Modules are used to encapsulate portions of a design problem, hiding implementation details within their embedded models. Modules can represent various mechanical components, materials, domain expertise, or analysis software. They may be accessed by invoking their services (Figure 2). Services are the interface of a module and provide

information or perform computations upon request. In providing a service, a module can invoke other services including those belonging to other modules. Modules, either local or distributed over the network, interact through service exchange relations to form integrated systems—creating a distributed-object computational model.

(a)

Module (containing embedded model)

Services provided

Services required

Strength Analysis (Excel)

(b)

Hoop stress

Thickness, diameter, height

Figure 2; (a) DOME modules and services. (b) The bottle strength analysis module computes hoop stress, but it needs to call services from other modules to obtain appropriate bottle parameters. In the bottle design problem, a DOME module is associated with each of the four major design participants (solid modeling; strength analysis; life-cycle assessment, and engineering design configuration). The four modules each encapsulate specific aspects of the design problem within their embedded models and exchange services over the Internet. Service exchanges between these modules are exchanged using a CORBA compliant communication protocol [Siegel 1996]. 3.2. Embedded models An embedded model is the software that implements a module’s services. Proprietary code, a system of DOME modules, and third party engineering design software tools (e.g. CAD systems, databases, etc.) can be used as an embedded model and mapped to module services. In the bottle example, applications are wrapped with DOME modules so they can provide services to other modules: TEAM for life-cycle assessment; ProEngineer for CAD modeling; and the spreadsheet EXCEL for stress analysis (Figure 3). DOME Wrapper

PC running Excel spreadsheet

Hoop Stress Strength Analysi

Bottle Configuration

Thickness, etc. DOME domain Interactions External application domain through Excel API

Figure 3; Excel wrapper module from the bottle design problem. 3.2.1. DOME Engineering Modules Many distributed object implementations provide tools to integrate different platforms and software applications [Chappel 1996], [Orfali et al. 1996], [Siegel 1996]. Additionally, the DOME formalism provides template modules for engineering system modeling, optimization, and decision making.

Engineering Variable Modules are used to represent deterministic or probabilistic quantities, matrices, vectors, sets, and functions. Each module type provides the proper set of services (Figure 4). For example, in the bottle problem model, the shipping distance to the customer is represented as a probabilistic variable D using a DOME Beta Distribution Module. D D.getExpectedValue() Beta

D.getStandardDeviation()

Figure 4; Engineering Variable modules provide different services depending on their type. A subset of the services provided by the shipping distance D, an instance of a Beta Distribution module, is shown. Container Modules encapsulate other modules, controlling their service interactions using mathematical Relations and mathematical Solvers to translate relations into the proper sequence of service calls. Container modules are specialized according to their solver type (e.g., directed graph or simultaneous equations). Container Modules maintain consistency between module services according to a set of locally defined equations. When the value service of a contained module is requested, the solver will first check/recalculate the service state against relations, and then provide the value service (Figure 5). Performance

Cost per unit volume

Relation R1 { TotManufCost = CostPerUnitVolume * BottleVolume; } Bottle volume Performance.getTotManufCost() Tot Manuf. Cost

Figure 5; In the bottle example, the “Performance” container module (within the engineering configuration) encapsulates: TotManufCost, CostPerUnitVolume, and BottleVolume, whose services are related by the relation R1. When the total manufacturing cost service is requested,a solver ensures that the total manufacturing cost is consistent with the relation R1. Catalog Modules also store other modules, but they provide a consistent interface and mechanisms for switching easily between the stored modules. A replacement mechanism is provided that allows users to explore alternatives by swapping the services of functionally equivalent modules in the problem model. In the bottle design, catalogs are used to represent bottle types (aluminum can, plastic bottle, glass bottle), bottle contents (carbonated drink, water, alcohol), and Life-cycle assessment (LCA)

indicators (Figure 6). Since modules can encapsulate whole applications, catalog replacement can also be used to seamlessly recombine different pieces of software. LCA-indicators

Current Selection

EPS

Ecopoints

CML

Assessment Scheme

CVCH

ETH

IPCC

Engineering design configuration module

Figure 6; LCA assessment scheme catalog. The module selected from the catalog is used to provide environmental impact assessment scheme in the bottle model Decision-making Modules provide quality or worth evaluations based upon state of chosen modules according to a decision theory methodology. For example, specialized decision modules can be created for Utility Theory [Keeney et al. 1993], the Analytical Hierarchy Process [Saaty 1980] and acceptability-based design [Kim et al. 1997]. Further, Optimization Modules can be developed to search through the possible states of the independent variables and catalog selections to locate the best design configurations according to objective scores obtained using decision making modules. Optimization modules could embed any type of search engine but the module currently implemented uses genetic algorithms [Senin et al. 1996]. 4. IMPLEMENTATION RESULTS The DOME software prototype was implemented in the Silicon Graphics IRIX operating system. Problem models are described using text files written in a high level scripting language developed for the formalism called MDL (Model Definition Language). MDL files are loaded into the DOME prototype to become active object models that can be browsed and operated by the designer through a MOTIF graphical user interface. Utilities have also been developed to build CORBA compliant DOME wrapper modules for third party applications or proprietary code [Borland et al. 1998]. Several problems have been modeled and optimized using the prototype implementation, including: design of electromagnetic sheilding for box enclosures [Jackson et al. 1997]; job shop scheduling and resource allocation [Wasserlein 1997]; and LCD projector design [Wang 1997]. Figure 7 shows the bottle design problem model from the viewpoint of the engineering configuration division. The main window shows modules contained in the main design configuration module. Lines between modules indicate the existence of service exchanges. Local references to remote wrappers are shown mapped to their associated application, dark modules are container modules (containing variable

modules, relations and solvers inside); the lighter catalog modules have an additional label indicating the current selection. Excel ProEngineer

Team

Figure 7; The beverage model seen from the GUI for the engineering configuration module. Excel, TEAM and ProEngineer are accessed through references to remote wrappers. The dialog box at the center-bottom of the figure is the bottle-type catalog module browserÑan aluminum can module has been selected. The decision module GUIs provide thumbnails on the right of the main panel. There are three decision modules: safety, performance, and environment. Each shows evaluation results for selected design attributes relative to tolerance-like design requirements. The evaluation scores are calculated according to an acceptablity-based decision model [Kim et al. 1997]. The current configuration (aluminum can) fails to meet the cost criterion and two environmental indicator criteria. Using the tool, the designer could use the bottle-type catalog to substitute a plastic bottle and, in just a few seconds, realize that both environental and cost performance will improve. For large problems optimization tools can help designers explore a solution space and locate promising alternatives. The genetic Optimization module GUI is shown in Figure 8 after an optimization. Design variables and catalogs selected for optimization are reported in the top right column, choosing from the list of possibilities on the left. The bottom-right graph shows the generational history of the optimization process (best, average, and worst of generation according to the services of the cost, performance and environmental assessment decision modules). At the bottom left search results are listed, rank ordered by objective measure. Three major families of solutions were found each corresponding to a different bottle type.

Figure 8; Optimization results. Three locally optimal families of solutions correspond to the bottle types. The plastic bottle performed best in the example model. 5. CONCLUSIONS In this paper a distributed object-oriented modeling formalism for design problems has been described. The formalism has been implemented in a prototype called DOME and applied to a variety of test problems. The formalism allows integration of distributed software tools and models into a global system design model, which then can be explored to identify configurations corresponding to best overall performance. The building block of the formalism, the Module, embeds indifferently proprietary software, third party commercial applications, or custom models, and provides a standard Internet-based communication interface for accessing the services of distributed modules. Container modules with mathematical solvers are provided for state-change propagation and to ensure that model services are consistent with locally defined relations. Continuous engineering variables and catalog selections can be modeled. Using catalog selection, the framework provides a mechanism to seamlessly replace pieces of software within a problem model. A DOME model forms a distributed service exchange network that exhibits integrated system behavior. Thus, global trade offs can be explored using optimization modules like the genetic algorithm-based implementation applied in this work. The objective scores can be formulated using the services of modules specialized in decision support calculations. 6. ACKNOWLEDGMENTS We are grateful for the financial support provided by the National Science Foundation Center for Innovation in Product Development and the Alliance for Global Sustainability.

REFERENCES [Bliznakov et al., 1996] Bliznakov, P.I.; Shah J.J.; "Integration Infrastructure to Support Concurrence and Collaboration in Engineering Design"; In Proceedings of the ASME DETC'96, Irvine, Ca. [Borland et al., 1998] Borland, N.; Kaufmann, H.P.; et al; "Integrating Environmental Impact Assessment into Product Design: A collaborative modeling approach". In Proceedings of ASME DETC'98, Atlanta, Georgia. [Brown et al., 1993] Brown, D.R; Hwang, K.Y.; “Solving Fixed Configuration Problems with Genetic Search.”; Research In Engineering Design 5(2): 80-87. [Case et al., 1996] Case, M.P.; Lu S.C.-Y; “Discourse model for collaborative design.” Computer-Aided Design 28(5): 333-345. [Chappel, 1996] Chappel, D; Understanding ActiveX and OLE, Microsoft Press. [Cutkosky et al., 1996] Cutkosky, M.R.; Engelmore, R.; et al.; “PACT: An Experiment in Integrating Concurrent Engineering Systems.”, IEEE Computer (January, special issue on Computer Support for Concurrent Engineering): 28-37. [Dabke et al., 1998] Dabke, P.A.; Cox; et al.; “NetBuilder: an environment for integrating tools and people.”; Computer-Aided Design 30(6): 465-472. [Gorti et al., 1998] Gorti, S.R.; Gupta, A.; et al.; “An object-oriented representation for product and process.”; Computer-Aided Design 30(7): 489-501. [Harmer et al., 1998] Harmer, Q.J.; Weaver, P.M.; et al.; “Design-led component selection.”; Computer-Aided Design 30(5): 391-405. [Hsu et al., 1998] Hsu, W.; Woon, I.M.Y.; “Current research in the conceptual design of mechanical products.”; Computer-Aided Design 30(5): 377-389. [Jackson et al., 1997] Jackson, P.; Wallace, D.R.; “An analytical method for integrating environmental and traditional design considerations.”; Annals of the CIRP 46(1): 355-360. [Keeney et al., 1993] Keeney, R.L.; Raiffa, H.; Decisions with Multiple Objectives: Preferences and Value Tradeoffs, Cambridge University Press. [Kim et al., 1998] Kim, C.; Kim Y.; et al.; "Internet-based Concurrent Engineering: An Interactive 3D System with Markup". In Proceedings of the ASME 18th Computers in Engineering Conference, Atlanta, Georgia. [Kim et al., 1997] Kim, J.B.; Wallace, D.R.; "A Goal-oriented Design Evaluation Model"; In Proceedings of the ASME DETC'97, ASME. [Molina et al., 1995] Molina, A.; Al-Ashaab, A.H.; et al.; “A review of computer aided simultaneous engineering systems.”; Reseach in Engineering Design 7(1): 38-63. [Orfali et al., 1996] Orfali, R.; Harkey, D.; et al.; The Essential Distributed Objects Survival Guide, John Wiley & Sons, Inc. [Pahng et al., 1997] Pahng, K.F.; Senin, N.; et al.; "Modeling and evaluation of product design problems in a distributed design environment". In Proceedings of the ASME DETC'97, Sacramento, California. [Pahng et al., 1998] Pahng, K.F., Senin, N.; et al.; “Distributed modeling and evaluation of product design problems.”; Computer-Aided Design 30(6): 411-423.

[Pena-mora et. al., 1995] Pena-mora, F.; Sriram, R.; et al.; “Conflict mitigation system for collaborative engineering.”; AI EDAM special issue of Concurrent Engineering 9(2): 417-429. [Petrie et al., 1994] Petrie, C.; Cutkosky, M.; et al.; "Design Space Navigation as a Collaborative Aid". In Proceedings of the Third International Conference on Artificial Intelligence in Design, Lausanne. [Rajagopalan et al., 1998] Rajagopalan, S.; Losleben, P.; et al.; "Integrated Design and Rapid Manufacturing over the Internet"; In Proceedings of the ASME DETC'98, Atlanta, Georgia. [Reddy et al., 1996] Reddy, S.Y.; Fertig, K.W.; "Design Sheet: A System for Exploring Design Space, Application to Automotive Drive Train Life Analysis"; In Proceedings of the Fourth International Conference on Artificial Intellingence in Design (AID'96), Stanford, CA. [Saaty, 1980] Saaty, T.L.; The Analytic Hierarchy Process. New York, NY, McGrawHill. [Senin et al. 1996] Senin, N.; Wallace, D.R.; et al.; "Mixed continuous variable and catalog search using genetic algorithms"; In Proceedings of the ASME DETC'96, Irvine, CA. [Siegel, 1996] Siegel, J.; CORBA: Fundamentals and Programming, OMG. [Sobieszczanski-Sobieski, 1995] Sobieszczanski-Sobieski, J.; "Multidisciplinary design optimization: an emerging new engineering discipline"; Advances in Structural Optimization., Netherlands, Kluwer Academic Publishers: 483-496. [Toye et al., 1994] Toye, G.; Cutkosky, M.R.; et al.; “SHARE: a methodology and environment for collaborative product development.”; International Journal of Intelligent & Cooperative Information Systems 3(2): 129-153. [Wang et al., 1998] Wang, F.-C.; Wright, P.; "Web-based CAD Tools for a Networked Manufacturing Service". In Proceedings of the ASME DETC'98, Atlanta, Georgia. [Wang, 1997] Wang, P.H; Benchmarking a Collaborative, Concurrent Computer Design Tool, MIT Department of Mechanical Engineering. Cambridge. [Ward et al., 1993] Ward, A.C.; Seering, W.P.; “The Performance of a Mechanical Design 'Compiler'.”, Journal of Mechanical Design 115(3): 341-345. [Wasserlein, 1997] Wasserlein, H.D.; A representation for optimizing scheduling problems; MIT Department of Mechanical Engineering. Cambridge. [Wong et al. 1993] Wong, A.; Sriram, D.; “SHARED: an information model for cooperative product development.”; Research in Engineering Design 5(1): 21-39. [Yoshikawa et al. 1994] Yoshikawa, H.; Tomiyama, T.; et al.; “An Integrated Modelling Environment Using the Metamodel.” Annals of the CIRP 43(1): 1-4.