Download Postscript file for printing (12.8 MB)

Collaborative Mechatronic System Design

R. Fruchter
Department of Civil Engineering
Stanford University
Stanford, CA 94305
fruchter@cive.stanford.edu

K. A. Reiner
Mechanical Engineering Department
Stanford University
Stanford, CA 94305
kreiner@cdr.stanford.edu

G. Toye
Mechanical Engineering Department
Stanford University
Stanford, CA 94305
toye@cdr.stanford.edu

L. J. Leifer
Mechanical Engineering Department
Stanford University
Stanford, CA 94305
leifer@cdr.stanford.edu

Abstract

Integrated product and process development is accomplished by multi-disciplinary teams. To support the team approach we have developed ICM, the Inter-disciplinary Communication Medium. It accommodates and integrates many perspectives within a design and manufacturing enterprise. The ICM prototype integrates a shared graphic modeling environment with network based services. Graphics include 3D models of evolving designs, and network based services may include knowledge-based reasoning tools that critique the performance of the proposed device. ICM implements an iterative communication cycle in which team members: (1) propose form models in a shared graphic modeling environment, (2) interpret the shared form models into semantic discipline models, (3) gather information by using the discipline models to customize their search for additional discipline information, (4) critique the discipline models to derive behavior and compare it to function, (5) explain the results to other members of the team, (6) route change notifications for proposed changes.

1. Introduction

The "over the wall" product design model. A mechatronic system design project is undertaken by a multi-disciplinary team of professionals. Traditionally, team members have difficulty in communicating design intents, decisions and problems across disciplines. As the design of the device evolves, each of the design team members investigates and communicates alternative solutions using:

separate models of the design for each discipline,
individual, private engineering notebooks to record the background information,
representational idioms that are private to a single member's profession, and
diverse media for transferring design information.

Other team members in turn, must interpret, extract, and re-enter the relevant information in the form of conventional idioms of their discipline and in the format required by their tools. These tasks are error-prone and time consuming. In addition, conflicts among different discipline design proposals go unnoticed or remain unresolved late into the design process. The communication difficulties that result often have an impact upon the quality of the final device and the time required to achieve design consensus. Furthermore, the information created in the conceptual design stage must be carried forward into later stages of design, which often entails translating the initial data for use by other software tools.

Numerous software tools are available for evaluating mechatronic system designs. However, such tools are of little value in the exploration of alternatives and the communication of design concepts in the early stages of design. Furthermore, CAD and analysis tools represent "islands of automation" which focus upon a single discipline or a single task in the design process. In recent years, research work addressing issues in concurrent engineering has been of growing interest as exemplified by the works of [3], [5], [8]. This project addresses similar issues of integrating multi-criteria and multi-disciplinary representation and reasoning.

The collaborative product design model. We propose a framework for interdisciplinary communication of design information in the conceptual design stage and present a prototype called Interdisciplinary Communication Medium (ICM) for mechatronic system design. In order to facilitate effective communication across disciplines, this research argues that an integrated software framework should enable sharing and capture of multi-criteria design proposals, design semantics, critique, explanation, and change notifications. The vision behind ICM is that professionals perform their tasks in a world of networked resources and services. ICM integrates a shared graphical modeling environment and network based services. ICM graphics includes 3D models of evolving designs, and network based services may include knowledge-based reasoning tools that critique the performance of the design. The key technical concept of ICM is that a graphical design environment (such as AutoCAD[*]) can also serve as the central interface among designers (human-to-human) and as the gateway to tools/services (human-to-machine) in support of interdisciplinary design. This computer based graphical environment enables designers to share and explore designs in the following ways:

define and view definitions of objects and functions at different levels of abstraction,
customize a model-centered gathering and organization of information resources relevant to specific project perspectives and issues,
directly engage distributed network services (e.g., critique) with geometric, spatial, and graphics based information models as defined by the designer in diagrammatic form,
link different discipline interests via shared graphics.

Our hypothesis is that use of our ICM prototype will:

improve concurrent engineering,
increase the number of explored alternatives,
support multi-criteria evaluation,
reduce product design cycle,
capture design intent.

The paper discusses the capabilities of ICM, which enable a drive train engineer, a motor designer, and an electrical engineer to each (1) propose their design solutions in a shared graphic modeling environment, (2) capture multi-criteria semantics, information, critique, explanations, and (3) exchange design change notifications. A detailed discussion of the specific knowledge-based systems used for critiquing mechatronic systems is beyond the scope of this paper. In the following we present a scenario used as a test case for ICM, we discuss the open system integration architecture of ICM, and we summarize the implications of this work.

1.1 Scenario

The following scenario illustrates the concepts behind the ICM prototype with an example of the software's use in mechatronic system design. The mechatronic device chosen for our test case is a real project performed by one team of mechanical engineering graduate students in the Design and Manufacturing Program of the Mechanical Engineering Department at Stanford University. The project goal was to design and build an automobile door latch system that combines the function of latch, power lock and cinching into a single assembly. The project was proposed and sponsored by General Motors Corp. The new latch mechanism had to be integrated with other systems within the limited space inside the car door frame.

The scenario begins with the team proposing a schematic solution which includes the different subsystems (e.g., actuator, cinch, reduction, switch logic, forkbolt) of the door latch system and their interaction. The design progresses in an iterative mode through: more detailed design of 3D and electrical circuit models, information gathering, critique of the proposed designs from different perspectives, problem identification and explanation, change of design solution and design change notifications.

Design proposal in a shared graphic modeling environment

The team members discuss and share their potential design solutions using a geometric modeling environment, such as AutoCAD. The designers draw a top level schematic diagram representing the functional blocks of the future device (Figure 1.1). Each designer then starts to explore and propose design solutions in the shared graphic modeling environment. For instance:

the drive train designer proposes a 3D model for the reduction system (Figure 1.2),
the motor designer adds a DC motor to the 3D model (Figure 1.2), and
the electrical designer proposes the circuit design for the switch logic and motor control (Figure 1.3).

Figure 1: Shared Graphic, Semantic and Symbolic Representation in the Design Scenario

(1) Graphic top level model of functional objects; (2) 3D Graphic model of latch system; (3) Graphic model of electrical circuit design of switch logic subsystem; (4) Interpretation objects capturing the semantic design intent in the top level, drive train, motor, electrical circuit contexts; (5) Symbolic models of the top level, drive train, motor, electrical circuit

Capturing the semantic design intent of different perspectives

The designers use ICM's Semantic Modeling Extension from within AutoCAD to define specific discipline perspectives or contexts (e.g., drive train design, motor selection, electrical circuit) and annotate features in the shared graphic models with semantic meaning (Figure 1.4). These discipline semantics are captured in Interpretation Objects illustrated in Figures 1.4. For instance, the motor represents a source of torque in the drive train design, and an impedance in the electrical system design.

Gathering, organizing, and sharing information related to specific discipline issues.

The designers may seek previous designs which can serve as benchmarks, lessons learned, or reuse opportunities. They use the semantic interpretations as seeds for a search of the World Wide Web (WWW) resources with the WWW Design Coach. The search and retrieval of information is guided by model-centered interpretations and users' ratings of retrieved resources. For example, the drive train designer wishes to review the gear prices and identify new vendors. He/she selects the drive train interpretation, then starts the WWW Design Coach. The system returns a number of pages which match the users interest, such as PartNet (URL: http://part.net/) pages.

Multi-disciplinary concurrent critique

Once the design has evolved to a stage when the designers decide to evaluate the performance of their proposals, they use the Interpretation Objects to interactively map their graphic form models into symbolic models. The symbolic models are instantiated in the corresponding discipline critique tools (Figure 1.5). The Motor Selection knowledge-base (KB) is used to identify a specific DC motor that meets the requirements defined by the team. Given the motor characteristics, the Circuit Designer KB runs a simulation to evaluate functional behavior. Concurrently, the Drive Train Design KB analyzes the reduction and tries to select specific component part numbers from a catalog. The Toplevel module coordinates the input and output parameter requests and replies of the other modules, such as Motor Selection, Circuit Designer, and Drive Train Design KB.

Multi-criteria explanation of critique results

The analysis and evaluation results obtained from the different critique tools are projected back to the shared graphic modeling environment. Graphic features related to the identified performance problems are highlighted. For instance,

The Circuit Designer KB finds that the current flow in transistor Q0 excessive and recommends "Make base resistor R3 larger or increase collector resistance.",
The Drive Train Design KB finds that the power requirement is low and suggests the use of crossed - helical gears.

Design changes and routing of change notifications

After the initial design, the drive train designer discovers that the torque required to actuate the forkbolt is greater than previously specified. This requires a change in the reduction system which places new demands on the motor. The drive train designer documents the new requirements for the motor in a change notification. The change notification is then routed to the electrical and motor designers who share an interest in the motor feature.

The described scenario represents a communication cycle continues which continues until a design consensus is reached.

We present the theory and computational environment which have evolved from our research in two different domains, facility engineering and mechatronic system design. These domains share similar interest and requirements for computer support for collaborative multi-disciplinary teamwork.[2], [4], [9] Our research is founded on empirical data from observations of multi-disciplinary design teams at work, theoretical evidence discussed in design theory, and the implementation of the proposed communication cycle into a software prototype.

2. Theoretical Foundation

We view the mechatronic systems design as an iterative process of synthesis, analysis and evaluation. Proposing a design consists of synthesizing a design concept from requirements and specifications. Critiquing entails analysis and evaluation of the design. In the analysis step, the performance of the design is predicted. In the evaluation step, the derived performance is compared against the requirements. The design or its requirements may be modified in light of the new information obtained by the evaluation. The process is repeated until a satisfactory result is achieved. This perspective is discussed in a similar fashion in the design literature by [1], [6], [7].

A complementary characterization of design and modeling employs form, function, and behavior models. The form of the design is the arrangement and pattern of elements. The functions represent the intended purposes to be satisfied by the design. The behavior represents the way the design responds in a particular environment. Each of the design process steps described above relates two of the three aspects of the triad. Synthesis relates function to the form. Analysis relates form to behavior. Evaluation relates behavior back to the function. By this description, it is obvious that form, function and behavior must also be understood in the context of multiple disciplines.

Throughout the design process designers create and use form, function, and behavior models in both the graphic and the symbolic representational worlds.

Form models. The graphic form model describes the physical characteristics of an entity in a discipline model (e.g., a gear in the drive train system, an inverter in the electrical circuit). The graphic form description includes: spatial information (e.g., location, orientation in the 3D form model), geometric information (e.g., dimension, shape), and topological information (e.g., connectivity among components). The symbolic form model represents the hierarchy of object classes that describes the specific application discipline (e.g., spur gear in the drive train application, inverters and solenoids in the electrical circuit application).
Behavior models. The behavior represents the way an entity responds in a particular environment in carrying out a specific function. An entity may have several behaviors in different discipline models. The graphic behavior model may consist of annotations of the graphic form model, corresponding to the derived behavior results. The symbolic behavior model contains the reasoning mechanisms, the domain principles (i.e., physical principles and experiential knowledge), and the parameters that describe the plausible responses in the application domain.
Function models. The function of an entity reflects the intended role of the entity in a discipline model. An entity may serve several functions in different discipline models (e.g., a motor is a source of torque in the drive train model and an impedance in the electrical circuit model). The function is determined from the relationships among entities in a discipline model. The graphic function model consists of diagrams and annotations representing derived functional role of graphic entities and problematic evaluation results. The symbolic function model includes the reasoning mechanisms, the domain principles and the parameters that describe the plausible purposes of components in the application domain.

The graphic world plays a crucial role in exploring, editing, recording, explaining and understanding the evolving design. The symbolic world plays a central role in reasoning and evaluating the design.

Much of the negotiation in a collaborative mechatronic system design project focuses on the graphic entities that are shared among discipline models. Because of this emphasis, a graphic modeling environment should be the central interface to support collaborative design. The form of the device is most easily represented by graphic models, while reasoning about function and behavior is more easily achieved symbolically. Graphic methods for representing form, symbolic methods for reasoning about function and behavior, and graphic methods for visualizing function and behavior must be integrated to achieve a better environment for collaborative teamwork.

3. Model-Centered Collaborative Mechatronic System Design

We propose a formalization for model-centered collaborative mechatronic system design which is based on an iterative communication cycle of

Propose. The form models of a mechatronic system design are proposed by designers using a shared graphic modeling environment. Consequently, a graphic discipline model is a subset of the shared graphic form models.
Interpret. The interpret activity results in the identification of the features of the shared graphic form models relevant to a particular discipline context. Such an interpretation is represented by semantic annotation of the CAD graphic entities. An interpretation is explicit and dynamic in the sense that the annotations may be inspected, displayed, manipulated and changed. A discipline model is a graphic form representation of the design and its instantiation into a symbolic form model. The interpretation mechanism provides a one-to-many relationship between a graphic entity and its instances in multiple symbolic discipline models. The designers explicitly register their interest in and responsibilities for specific interpretations.
Information gathering and organizing. The gathering activity uses a symbolic form model as an initial guideline to search for information relevant to a specific project. User ratings of the retrieved resources are used to improve and customize the search parameters. The organization activity links information sources to graphic forms.
Critique. The critique activity uses knowledge-based analysis and evaluation of a symbolic discipline form model to derive behavior from the form, and compare the behavior to function. The behavior of a symbolic discipline form model is derived by performing qualitative and quantitative analysis. The function is determined by the designer and by discipline design requirements.
Explain. The explanation activity provides a symbolic trace of the causes that lead to performance problems identified in the critique stage and their visualization in the context of the shared 3D graphic models.
Change notifications. In the change notification activity: (1) the user selects the changed features and appends a notification which captures the design intent behind the changes, (2) the system uses the interpretation mechanism to identify team members who are interested in the changes, and (3) the system routes the change notification.

The communication cycle of propose - interpret - gather - information - critique - explain - change and route notifications is the means by which designers explore the design proposals, capture the semantic meaning of the design proposals, and express the impact of their design decisions and the consequences to other disciplines. The goal of the cross-disciplinary communication is to reach consensus. Consensus is represented by agreement reached by designers, based on compatible discipline models. Discipline models are considered to be compatible if they comply with the discipline requirements and if there are no conflicting components.

In the following section we elaborate on the implementation of the proposed communication cycle paradigm.

Figure 2: Overview of the ICM Architecture

4. ICM Prototype Implementation

In order to test this communication cycle we have implemented a working software prototype, which we call ICM, (Interdisciplinary Communication Medium.) It enables a multi-disciplinary team to share and capture: form models, multi-criteria semantics, project specific information, critique results, explanations, and change notifications. ICM provides an open system integration architecture based upon a central, shared graphic modeling environment which can be connected, on the fly, to network based services. Services include knowledge-based systems that provide automated representation of the design's symbolic models and reasoning about the performance of the design from multiple discipline perspectives. In addition, a World Wide Web (WWW) Design Coach module can be linked to the shared graphic models to collect and organize information relevant to a specific project. Notes regarding changes of features (graphic entities) can be linked to the models and routed to interested team members who share an interest in the changed feature. Figure 2 illustrates an overview of the ICM prototype.

We have implemented ICM using: AutoCAD as the geometric modeling environment, Prokappa as the platform for developing prototype critique tools, C and Mosaic for the implementation of the WWW Design Coach, and Internet e-mail for routing change notifications. In order to facilitate the creation of Interpretation Objects we have developed a Semantic Modeling Extension (SME) as part of ICM. SME is integrated with AutoCAD and the AME[*] solid modeler. The Semantic Modeling Extension is accessed from AutoCAD using an additional menu. The SME prototype provides a user interface using AutoCAD's Dialog Control Language. The SME part of ICM runs on Unix, PC, or Macintosh computers.[**] We have implemented prototype critique tools which can be linked to the central graphic environment using SME. These critique tools run on SUN workstations and were written using Prokappa[***] Each critique tool derives the behavior of the design in a particular context and compares the behavior against functional requirements. Discussion of the methods used in the critique tools is beyond the scope of this paper.

4.1 Interpret: Semantic Modeling Extension

One of the key ideas in this research is to provide a semantic modeling method by which a shared graphic representation of a mechatronic device can be mapped to multiple symbolic representations (e.g., Figure 3a). Our concept of Interpretation Objects supports interactive graphic to symbolic mapping. We have used object-oriented programming techniques to develop a Semantic Modeling Extension (SME), which enables a designer to capture and express intents and meanings behind the graphics that describe the design.

Figure 3: Concepts of the Semantic Modeling Extension

(a) Multiple interpretations of a shared graphic entity, and (b) Manager Object, Interpretation Object, Feature Classes, Feature Objects, and Services.

The fundamental concepts of the semantic modeler include:

Interpretation Manager Object supports the multiple interpretations required for the consideration of multiple contexts by the design team. It consists of a list of Interpretation Objects associated with shared graphic models to support multiple points of view (Figure 3b).
Interpretation Objects collect features for a particular perspective. An Interpretation Object has three basic attributes: a list of Feature Classes, a list of Feature Objects, and a list of Services. The interpretation is defined by the user. Feature Classes describe the semantic meaning of graphics in the desired perspective. The list of Feature Objects is edited by the user at run-time to contain the instances from a particular graphic model which are relevant to this interpretation. The list of Services indicates the critique tools which may be linked to the Interpretation Object (Figure 3b).
Feature Classes provide the ontology that is used to describe the domain of an interpretation (Figure 3b). This vocabulary can be defined or augmented by the user at run-time based on the specific characteristics of the project.
Feature Objects capture the link between a graphic entity and a symbolic entity. We define a feature as a graphic entity with semantic content necessary for a particular context of reasoning. A Feature Object consist of a pointer to a graphic entity, an individual identifier or name, and an associated Feature Class (Figure 3b). A graphic entity may have different meanings within different interpretations (Figure 3a).

Each designer can define his/her Interpretation Objects and specify his/her interest and responsibility in Feature Objects.

The dialog boxes in Figure 1.4 show the results of having interpreted the design from four points of view. After having represented a design proposal using the AutoCAD graphic editor, the designers identify the semantics of the design proposal by creating an Interpretation Object for each interpretation context. The drawings (Figure 1.1, 1.2, 1.3) portray the corresponding graphic visualizations in AutoCAD of the shared device model. The Interpretation Features dialog boxes (Figure 1.4) contain the interpretations in the contexts of top level, drive train, motor, electrical circuit. In order to verify whether a graphic entity is part of the interpretation, the designers can use the Identify< command and then point at a graphic entity. If the graphic entity has been linked to a feature in this interpretation, the feature is highlighted in the Features list.

Interpretation Objects provide the means for early designers to identify shared features among contexts, and the vocabulary related to each of interpretation contexts which share those features. SME enables designers to:

Identify graphic entities of the device model which are shared among multiple Interpretation Objects. The Identify< button of the Interpretation Manager supports this operation. A designer can use this facility to identify in the graphic model if a selected Feature Object within his/her context of interest is shared with other Interpretation Objects. As a result of this action, an alert box will indicate the Interpretations, and the corresponding vocabulary in terms of the Feature Classes and Names associated with the selected graphic entity. If the designer wants to modify this Feature Object he/she could negotiate the modification with the appropriate team members who are concerned with the Interpretation Objects which share this graphic entity.
Visualize sets of graphic entities of multiple Interpretation Objects, by providing Boolean operations which act upon Interpretation Object feature lists, including intersect, union, and subtract, included in the Interpretation Manager. These functions allow designers to study interdisciplinary interactions of various interpretations.

4.2 Gather and Organize Information: WWW Design Coach

The collection and organization of information related to form, function and behavior of a device is recognized as a necessary activity in the capture of design rationale [9]. For a given domain, this information will range from broad descriptions of technological alternatives to specifics about component details. In either case, these references can serve as a means of further communicating discipline-specific concerns within an interdisciplinary design environment.

In the ICM prototype, we utilize the World Wide Web (WWW) as a source of information. The system supports design tasks and communication by providing mechanisms for WWW document gathering, organizing, and reuse. We have created a design aid, the WWW Design Coach agent which utilizes Interpretation Objects captured by SME to create a project keyword list which serves as a seed for the search. The agent searches Web sites for a specified period of time and returns a set of pages that match the interpretation semantics. The user is prompted to rate the retrieved Web pages based on their relevance. This rating is used to adjust the importance of the Web page characteristics (e.g., number of keyword hits, number of pictures, number of links, host machine name, length). The agent customizes the keyword list by adding words which are present in highly rated pages, but are not common to all pages. The designer can store useful pages for future reuse by linking them to Feature Objects .

The flow of information between the model, the designer, and the WWW Design Coach is illustrated in Figure 4. The drive train designer uses the Feature Classes (e.g., spur, gear, bevel, worm, shaft) from his/her interpretations to set up the keyword list (Figure 4.1). The WWW Design Coach searches the Web and returns a page from the PartNet catalog (Figure 4.2). The user rates this on a scale of 0 to 10, and decides to link the page to the spur gears in the graphic model.

Figure 4: Use of WWW Design Coach in the GM Automobile Door Latch System Design.
(1) 3D device model, and (2) PartNet WWW page.

4.3 Critique Tools

If an Interpretation Object supports a critique service, the designer can request a critique to analyze and evaluate the design (e.g., reduction system analysis and selection, motor selection, electrical circuit simulation and evaluation) (Figure 1.5). Such an interpretation object provides methods for extracting specific information from the graphic model and sending this information to the critique tool. The critique tool responds to the messages by instantiating a symbolic model of the design for use in automated reasoning. The symbolic model is used for automated reasoning about the performance of the design in the specific context. The prototype knowledge-based systems developed for ICM provide the following services:

The Toplevel KB handles the input and output parameter requests and replies between the knowledge bases, based on the functional schematic.
The Drive Train Design KB analyzes gear trains to determine the overall reduction. It uses domain knowledge to recommend changes based on desired input and output speeds and torques. It also identifies specific part numbers from a simulated on-line component catalog which are compatible with the geometry of the proposed design.
The Motor Selection KB identifies a suitable motor from a simulated on-line catalog given a number of search constrains (e.g., cost, speed/torque requirements, size).
The Circuit Designer KB performs a simulation of the proposed circuit design to determine its behavior. It then compares this behavior with the intended function, and uses domain knowledge to suggest design modifications.

4.4 Explanation

Another key concept in this research is the method by which multiple symbolic critique results can be mapped onto a shared graphic representation. Our concept of Explanation Objects supports this interactive method of symbolic to graphic mapping. We have used object-oriented programming techniques to develop a discipline specific explanation capability in ICM. The critique tools provide methods for extracting specific critique result information from the symbolic model and sending this information to the graphic environment. The fundamental concepts of the explanation facility include:

Context of explanation representing the specific critique domain reasoning about the design performance.
Explanation items capture the link between a symbolic entity and a graphic entity. A particular graphic entity may have different explanation items within different contexts. An Explanation item consist of a pointer to a graphic entity, an individual identifier or name, and an associated symbolic object, representing the behavior or suggestion derived by a critique tool within a particular Context.
Explanation Objects collect critique results related to features for a particular context. An Explanation Object has three basic attributes: (1) a context of explanation defined by the user when receiving the critique results from the critique tool; (2) a list of explanation items; and (3) a list of textual statements about suggestions, behaviors, and functional requirements, corresponding to the respective explanation items.
Explanation Manager Object supports the multiple explanations obtained from the multiple critique contexts. It consists of a list of Explanation Objects associated with shared models.

Critique results are sent back to the graphic modeling environment (Figure 5.1). This facility for explaining the critique results is part of the computer-supported communication cycle. This provides discipline specific explanations of critique results related to graphic form features (Figure 5):

affected form -- (1) highlighted graphic entities of the CAD model corresponding to specific Explanation items, e.g., Figure 5.1 indicating the worm1 Explanation item, and (2) list of the Explanation items of the form model identified by the critiquing tool (Figure 5.2);
predicted behavior and required function -- textual description of the function and behavior linked to a graphic form feature (Figure 5.3).

Figure 5: Examples of Explanations in the Electrical Circuit and Drive Train Design
(1) Graphic Models, (2) List of Explanation Items, (3) Textual Explanation linked to Graphic Feature

4.5 Change Notification

The final step in the collaborative design cycle enables the creation, organization, and linking of design change notifications to features and interpretation objects. A notification is comprised of :

Changed features identified by the designer proposing the change
Affected Interpretation Objects that share the changed features.
Notification Text written by the designer which captures the intent and motivation for the change.
An email Distribution List compiled based on the sharing mechanism supported by SME.

For example, in our scenario, the drive train designer wants to modify the reduction system shown in the 3D graphic model of Figure 6.1. In the Interpretation Features dialog, he/she selects the relevant Feature Objects (Figure 6.2) which are being considered for change. In the Change Notification dialog, a text note is added (i.e., Notification Text, Figure 6.3). Using the intersection of features in Interpretation Objects, the system identifies designers who share an interest in the proposed changes. An email message is sent to these people containing the text note and the Feature Names and Classes within the affected interpretations (Figure 6.4). This notification is also stored within the originating Interpretation Object.

Figure 6: Change Notification in a redesign of the gear train.
(1) The graphic model of the gear train, (2) Changed Features are selected from the affected Interpretation Object, (3) The Notification Text and the compiled Distribution List, and (4) Email distribution of change notification.

5. Conclusions

This paper presents the results of on-going research in the development and testing of the ICM prototype for collaborative mechatronic system design. ICM supports concurrent engineering by improving communication among members of interdisciplinary teams. The fundamental concepts that we have discussed include:

A communication cycle for collaborative teamwork which consists of propose - interpret - gather - information - critique - explain - change and route notifications.
Open system integration architecture.
A central graphic modeling environment as a design exploration and communication vehicle.
A Semantic Modeling Extension which introduces a structured way to capture design intent. It provides an interactive graphic to symbolic mapping mechanism. It implements the concepts of Interpretation Context, Feature Object, Interpretation Object, and Interpretation Manager Object.
A WWW Design Coach for searching and organizing relevant project information.
Prototype critique tools.
A Change Notification mechanism which documents notes on design changes linked to the graphic models and routs change notifications.

Research Validation. We have had considerable success testing the ICM prototype using other design projects. The research team has constructed four knowledge-based critique tools. In addition, other researchers have employed ICM's SME to assist in their own efforts to integrate graphic and symbolic models for reasoning about engineering construction processes. The prototype has proven to be useful beyond the confines of the original research team for supporting multi-disciplinary collaborative teamwork. At this time, approximately 50 representatives from industry companies have participated in a hand-on workshops using the ICM prototype. A more extensive testing effort has been conducted in the design and manufacturing course offered by the Mechanical Engineering Department, and in the "Computer Integrated Architecture-Engineering-Construction" course offered by the Department of Civil Engineering, at Stanford.

Continuing research. Our evidence suggests that ICM provides an effective way to model the semantic content of a design for the purpose of capturing and sharing information, multiple critiques, explanations, and change notifications. Our tests have included examples in facility engineering and mechanical engineering. However, there are a number of additional research issues which we hope to address in the future.

The critique tools that we have used thus far are proof-of-concept software. We foresee additional research focusing upon development of more sophisticated Interpretation Objects and critiquing tools.

Integration across project stages calls for identification of a graphic entity's level of abstraction. We have considered specializing Interpretation Objects to capture an "is-abstraction-of" relation between two graphic entities. The semantic dimension of versions or alternatives of a design might also be represented by Interpretation Objects.

While the degree of integration achieved by ICM is preliminary, the current work already allows various models of the design to share a description of the form. This is a powerful point of integration. Certainly other information content could be shared among design participants. We envision specializations of our Interpretation Manager class to coordinate sharing of other information, such as component identifiers or item costs and availability for procurement. A developer could produce libraries of Interpretation Objects which work closely together under a specialized Interpretation Manager, yet preserve the basic integration of the graphic form model when used with a basic Interpretation Manager.

Acknowledgments

This research is partially supported by the Stanford Integrated Manufacturing Association (SIMA) at Stanford University.

References

Asimow, W., Introduction to Design, Prentice-Hall, Englewood Cliffs, NJ, 1962.
Clayton, J.M., Fruchter, R., Krawinkler, H., and Teicholz, P., "Interpretation Objects for Multi-Disciplinary Design," Proc. of AI in Design 94, ed. J. Gero, Lausanne, Switzerland, August 1994, Kluwer Publishing Inc.
Cutkosky, M., Engelmore, R., Fikes, R., Gruber, T.R., Genesereth, M., Mark, W., Tenenbaum, J.M., Weber, J.C, PACT: An Experiment in Integrating Concurrent Engineering Systems, IEEE Computer, special issue on Computer Support for Concurrent Engineering, January 1993.
Fruchter, R, Clayton, M.J., Krawinkler, H., Kunz, J., Teicholz, P., Interdisciplinary Communication Medium for Collaborative Design, Proc. of AI CIVIL-COMP93, ed. B.H.V. Topping, Edinbourgh, UK, August 1993.
Khedro, T., Genesereth, M., Teicholz, P., Agent Based Framework for Integrated Facility Engineering, Engineering with Computers, 1993.
H.A. Simon, "The Science of the Artificial," Cambridge, MA: MIT Press, 1969
D. Schoen, "The Reflective Practitioner," Basic Books, Inc., 1983
K.P. Sycara, "A Computational Model of Negotiation Agents in Concurrent Engineering," CERA Conference, 1994.
G. Toye, M.R. Cutkosky, L. Leifer, M. Tennenbaum, M.J. Glicksman, "SHARE: A Methodology and Environment for Collaborative Product Develoment," 2nd IEEE Workshop on Enabaling Technologies Infrastructure for Collaborative Enterprisess 1993.