ADN: An Agent-Based Decision Network for

Proceedings of the 1999 ASME Design Engineering Technical Conferences September 12-15, 1999, Las Vegas, Nevada

DETC99/DFM-8915 ADN: AN AGENT-BASED DECISION NETWORK FOR CONCURRENT DESIGN AND MANUFACTURING Mohammad Reza Danesh Impact Laboratory, DRB –101 Dept. of Aerospace and Mechanical Engineering University of Southern California Los Angeles, California 90089-1111, USA Tel: (213) 740-9621, Fax: (213) 740-6668 [email protected]

ABSTRACT Engineering design is a complex process. Even in designing a simple product, tens, if not hundreds, of decisions must be made by a single designer or manufacturer. The problem gets more complex when a group of designers work as a team to design an artifact. In this paper, we take a decisionbased approach to model design process and introduce an agent-based decision network (ADN) to support concurrent decision-making and collaboration in design and manufacturing. Our research on ADN focuses on making team members consider other members' decisions when making their owns and attempts to achieve coherent design decisions among designers by explicitly representing and capturing individual design decisions and negotiation processes. To achieve this goal we introduce a decision-based design process model (DDPM) and a condition-based negotiation model (CNM). The DDPM was developed to capture individual designers' design processes. The CNM was developed to facilitate condition-based negotiation process and to track both conditions generated and decisions made at each design stage for downstream negotiation support. In ADN, each designer is associated with an agent and both the DDPM and CNM are captured and facilitated by agents and are not explicitly visible to designers. Agents generate and utilize the DDPM and CNM information to support their designers. This paper describes the ADN framework in detail, points out its advantages, and presents an application example to demonstrate the effectiveness of the ADN framework. KEYWORDS Design process, decision making, negotiation, coordination, dependency, intelligent agents, collaboration, concurrent engineering.

Yan Jin Impact Laboratory, DRB –101 Dept. of Aerospace and Mechanical Engineering University of Southern California Los Angeles, California 90089-1111, USA Tel: (213) 740-9574, Fax: (213) 740-6668 [email protected]

INTRODUCTION Engineering design is a complex process. Even in designing a simple product such as a gear, tens, if not hundreds, of decisions must be made by a single designer1. The problem gets more complex when a group of designers work as a team to design an artifact. Collaboration is needed for designer working in teams to exchange information with each other, find and resolve design conflicts, generate new ideas and design options, and assess the manufacturability of a given design. As the complexity of designed artifact increases, collaboration is changing its role from an auxiliary activity of team interaction to one of the main challenges in team design process. Nowadays, major design and manufacturing companies are more concerned about consistency and efficiency of their design teams rather than how the detailed design is being done. Researchers in the area of design and manufacturing have done extensive study on design methodology. Some examples are Axiomatic Design Model (Suh, 1990), Systematic Design Model (Pahl and Beitz, 1996), Decision Based Design model (Hazelrigg, 1998), (Mistree, et al, 1990). In Axiomatic Design Model, Suh has identified two axioms to be fundamental (i.e. Independence axiom and information axiom). The former suggests maintaining independence between functional requirements and the latter suggests minimizing the information content. Systematic design model is based on the observation that engineering design must be carefully planned and systematically executed and that a design method must integrate many different aspects of engineering. Some of the decisionbased design models (Hazelrigg 1998) use a decision based axiomatic framework of engineering design with emphasis on 1

Throughout this paper we use terms “designer” and “manufacturer” interchangeably, since manufacturers are in fact designers with different set of tasks but they work based on the same design principles.

1

Copyright © 1999 by ASME

classical decision theories, and others (Mistree et al 1990) try to define design problems in algebraic forms and solve them with optimization algorithms. As much as local design is important and essential in team design process, the key action that differentiates collaborative design form isolated design is coordination. Coordination is needed to manage interdependencies between designers and to facilitate progress of each individual (Malone et al, 1991). Researchers have done substantial research in fields of computer support for collaboration work (CSCW) and Distributed artificial intelligence and have proposed various coordination models. Some examples are Action workflow model (Medina-Mora, et al, 1992), Contract-net model (Smith, 1980), Redux model (Petrie, 1993), Distributed problem solving through coordination (CP&CR) model (Liu, et al, 1994) and Generalized Partial Global Planning (GPGP) model (Decker, et al, 1995). The action workflow model is based on theories of communicative activity such as language/action and has been developed in a series of systems for coordination among users of networked computers. This model characterizes a workflow based on the identification and construction of atomic “loops” of action in which a performer completes an action to the satisfaction of a customer. Contract-net model emphasizes on the issues of problem solving, communication and control for nodes in a distributed problem-solving environment. A contract is established by a process of bidding and award through cycles of two-way communication. Available contractors evaluate task announcements made by several managers and submit bids on those for which they are suited, then the managers evaluate the bids and award contracts to the nodes they determine to be most appropriate. Redux model, a centralized decision maintenance server, keeps track of decisions made by the team members and maintains the dependencies between them. It provides coordination services by tracking the design decisions made by team members. CP&CR (Constraint Partition and Coordination Reaction) model is a problem solving framework in which a society of specialized and well-coordinated agents collectively solve a problem. Each agent reacts to others’ actions and communicates with others by leaving and perceiving particular message on the objects it acts on. A solution emerges from the evolutionary interaction process of the society of diverse agents. GPGP model consists of an extensible set of modular coordination mechanisms. Each mechanism is defined as a response to certain feature in the current subjective task environment. GPGP works in conjugation with an agent architecture and local scheduler. GPGP approach views coordination as modulating local control but doesn’t replace it. Form the collaborative engineering point of view, the research in two fields of design and coordination modeling thus far provides the needed instruments to define a collaborative decision based design framework. As long as local design process has no conflicts with other designers’ designs, local design models can capture most critical aspects of the design process and guide engineers throughout the local design

process. On the other hand, coordination models can give members of a team (whether they are designers or manufacturers) enough support to overcome the inconsistencies of their team effort by using negotiation models. In the engineering practice however, design processes often become inconsistent with each other. A small change in one local design decision can create several inconsistencies in the overall design and may require several rounds of conflict resolution among members of the design group. In such cases, the challenge is to detect and resolve the conflicts at the stage that they are created to reduce further coordination and increase efficiency of design process. Our research on Decision-based Design Networks attempts to develop a framework that supports local design decisionmaking and group coordination process by introducing models of design decision making and negotiation. Our objectives are 1) to develop a decision-based model for local decision making, 2) to develop a negotiation model to support coordination and resolve conflicts among team members based on the local design process, and 3) to develop an agent-based system to support local and group design decision making and coordination. The basic idea behind our research is that group design process has two aspects. First is local design process where a single designer solves his/her own design problem. Second is coordination between members to coordinate their design plans and solutions in order to reach coherent local decisions by taking each other’s decisions into consideration. In order to increase the effectiveness and efficiency of the design process, these two steps should be executed concurrently. The focus of our research, hence, is on how to develop a framework and mechanisms, which can support local decision-makings as well as team coordination process. In the following sections, we first introduce our Agentbased Decision Network for concurrent design and manufacturing and discuss some issues related to ADN. After that we present the ADN model. In section 4, we describe the current implementation of our model and present an example application. Section 5 summarizes this paper and points out future research directions. ADN: AN AGENT-BASED DECISION NETWORK Large scale and complex design problems require engineers to be able to apply principals and methodologies of design and collaboration, to efficiently use emergent computer technologies, and to work effectively in teams. Researchers have identified two major theoretical views that underlie the current computer technologies for collaborative design support. The most prevalent has been based on the idea of “data sharing”. Its distinction is that of data, formatting or representation, and algorithms for data storage, communication, and manipulation. A computer system contains and manipulates data and is related to the “real world” through operations of “data entry” and “reporting” or “data access”. This view is embodied in the development of shared database systems of product or process models and communication facilities. The

2

Copyright © 1999 by ASME

problem with this view is that it does not address the issue of how the shared information is related to design decisions. The notion of process is missing. As a result, available data or information may overwhelm the designers. The second view can be characterized as “group decision support (GDS)”. Here the focus moves away from data itself to the process of group decision making, which often take the form of group meetings. GDS removes the communication barriers by providing necessary techniques for structuring decision analysis, and facilitating the formulation of a solution by directing the pattern, timing, or content of discussion. Group decision support systems (GDSS) developed under this framework take a human-centered approach. While group decision-making is one aspect of collaborative design, the existing GDS framework does not explicitly address individual decision making processes and their various linkages. As a result, most GDSS tools fail to provide engineering design specific solutions and support other than facilitating mail exchange and telephone – or video – conferencing. To overcome the shortcomings of the existing frameworks for design process, we propose an “Agent-based decision network (ADN)” framework. Our principal claim is that collaborative design is not merely about data, but it is about the processes of decision making that are carried out by multiple designers in specific organizational (functional and social) contexts and involves applications of specific design knowledge. The ADN view is different from GDS in that instead of focusing only on group meetings, the ADN thinking emphasizes the roles of individuals’ decision processes and the links between those processes. This distinction is crucial for concurrent engineering because the key contents of concurrent engineering are individual designers’ design processes and their coherent links. Group meeting is only a “snapshot” of the whole process and may not provide a complete understanding of the whole collaborative design process. The ADN view of concurrent design and manufacturing recognizes three key distinct actions each performed or exercised at different levels. These actions are 1) decisionmaking by individual designers using decision-based design process model, 2) coordinating between two designers, and 3) organizing among multiple designers using condition based negotiation model. Design decision-making: Design starts from the need to find a solution for a design task (e.g. to design mechanical components for a car headlight). The process of moving from the initial task to the final solution involves hundreds, or thousands or more decisions. We are concerned with decisionmaking aspect of design because decisions of a designer have to be coordinated with others. Inspired by (Petrie 1993), we view design decision making process composed of a set of tasks, decisions, and solutions, as shown in Figure 1. A task can be decomposed into sub tasks or a single solution by a decision. Design decisions are arrived at, by applying knowledge to generate options, collecting needed information to evaluate the alternatives, and selecting the best option. To develop a

Task Decision Sub-Task

Solution

Figure 1: Design decision making process framework to support decision making, we must explicate knowledge for option generation, formalize procedures for choice analysis and selection, and develop a framework for decision-making dependency management. The focus of our current research is to develop representation constructs of the various elements of the decision-making process. Coordination: In ADN, design coordination is defined as interactive actions between designers. Although designers try to make sub-tasks as independent as possible, it is almost impossible to avoid interactions among sub-tasks. Coordination is needed at different design stages for different purposes between designers. The need for coordination and the ways of coordination are key distinctions of collaborative design. Coordination is the link that bridges individual design decision processes to each other and creates a design network process as illustrated in figure 2. Coordination action can be as simple as passing information between designers (e.g. design change notification), or requesting certain action from others (e.g., relaxing a specific constraint), or negotiating Figure 2: Design over certain agreement (e.g., coordination among resolving a conflict). To designers provide support for effective coordination, we must develop protocols for coordination and identify knowledge that can be applied to coordinate decisions. As discussed in the next section, we have developed a condition-based negotiation protocol, CNP, to support coordination of design activities. Organizing: The action of organizing defines organizational policy and norms for designers to follow. Given only the individual design decision-making processes and their coordination links, there may be still cases that the designer makes the design decisions ineffectively. For example, although

3

Copyright © 1999 by ASME

preventive coordination - or preplanning - may take a lot of design time, it can reduce the likelihood of occurrence of conflicts and consequently saves time that might be needed for conflict resolution. However, excessive use of preventive coordination may consume excessive time itself as well as reduce the space of design options. Organizing is a distinct action to solve this problem of concurrent design. We will address this issue in the next step of our research. The important feature of our ADN framework is that it explicitly captures the decisions, coordination links, and organizational policies in the sense that it provides a structured representation of the concepts and actions as well as the mechanisms to support the actions. The main challenge we face to realize the framework is: how can we develop effective models to capture decision-making and coordination? The following section presents the initial results of our modeling endeavor. MODELING AGENT-BASED DECISION NETWORK The objective of developing a formal design process model is to provide unambiguous representation of the required information and operations so that the mechanisms for supporting those can be defined. We introduce decision-based design process model to serve the following needs: 1) to formalize design process information so that it can be recorded for later usage. 2) To define a design process information structure that can be used to identify and deal with dependencies between designers, and 3) To provide a base ground for composing a negotiation protocol. In the remaining sections, we begin by presenting main concepts of decisionbased design process model (DDPM), and condition-based negotiation model (CNM). In the next section, we show how these two models are combined together in the ADN framework. Elements of DDPM In a very general term design is a process of generating information and manufacturing is a process of converting design information to physical products. Now to capture the design process, we should record the related and useful information. We recognize that tasks, options, decisions, and solutions represent design process. We define design process as followings: Definition 1: Design process A design process denoted by D(t) is defined as: D(t)={T, O, D, S} Where: 0

1

1

2

2

m

T = { t1 , t 2 , t3 , t 4 , t5 … t n }: Tasks*,

O = { O1 , O 2 ,..., O k }: Option sets with Oi ={ o1i , o2i , o3i …} 1

1

2

2

D = { d 1 , d 2 , d 3 , d 4 …}: Decisions, S = { s1 , s2 , s3 …}: Solutions.


0

* t1 represents the initial task (This task is not decomposed from any other task). Definition 2: Tasks A Task, denoted by t, is associated with a set of goals G and attributes A and is defined as

t nm = {G, A} = {g1 ,…, gp , a1 , … , aq } where gi  G, and ai  A, and m is the task number from which the task is expanded, and n is a unique identification number for task.
Task goal (or goals) is the objective function of a task. Task attributes are measures to verify which option meets the requirements of task goals. In order for an attribute to be useful in decision making process it should be comprehensive and measurable. Comprehensive attribute is an attribute which by knowing the level of it in a particular situation, there is a clear understanding of the extent that the associated goal can be achieved. Measurable attribute is an attribute, which a) is reasonable to obtain a probability distribution for each option over the possible levels of the attribute and b) is reasonable to assess the designer’s preferences for different possible levels of the attribute. We say that a task is completed or satisfied when there is an option available that satisfies the task goals, i.e., o n
O : on Solves

t nm  on satisfies {g1 ,…, gn }
t nm .

Definition 3: Options An Option is a set of possible sub-tasks and/or solutions, which can satisfy the goal(s) of a certain task. Each option set, Ok, represents one possible course of action to satisfy a design task. The complete set of option sets creates an option space. O = {O

1

, O 2 ,..., O k }  {[ o11 , o12 , o31 …], [ o12 , o22 , o32 …]…

[ o1 , o2 , o3 …]}
k

k

k

Option generation is a creative process of human designers. Our on-going research attempts to develop better understanding of this process. Generally, options in ADN can be generated using one of the following three methods: They can be generated based on the designer experience (creative options). In other words, the designer uses his knowledge and generates required steps to satisfy the design goal(s). Options can be selected from a Pre-recorded set of options. In this case designer uses a library of previously recorded options and searches between them to find the proper option, which suits the assigned task. A suitable method for such cases is to use group technology in order to find similar design cases. Designer can generate options by using option generation tools. Software tools can assist the designer in generating solutions. We are currently developing models and tools to assist option generation.

4

Copyright © 1999 by ASME

Definition 4: Decision A decision d, links a task

t nm to a set of subtasks { t1n ,

t2n …} or a single solution sn found in the option space O.
The process of decision making has two steps, 1) evaluation of options, and 2) selection of one option. In our DDPM model we represent decisions as follows: 1

1

2

d ij .

2

D = { d 1 , d 2 , d 3 , d 4 …} “i” represents the task which decision is made for it and “j” represents the task that decision is leading to. Generally a decision leads to several sub-tasks. The only case, which a decision leads to one sub-task, is when the sub-task is a solution. Definition 5: Solution A solution, denoted by s is an end result of a task t after a decision d is made.




Some examples of solutions are catalogue references, physical dimensions, product models, and shifting design responsibility to another designer. Several implications can be drawn from the above definitions for the DDPM model. First, in every design process, generation of option is one of the key points to consistent and efficient design. More design options create more flexibility for the designer and if one option doesn’t work designer can easily evaluate another option. On the other hand, a designer might introduce dependencies and conflicts because s/he doesn’t have enough information about other designer’s activities and each option may conflict with other designers’ design. This creates an uncertainty in selection of design options. In order to reduce this uncertainty, designer should coordinate his design selections with other designers and considers their priorities. Second, as the design process progresses, the number of dependencies between tasks increases exponentially and evaluating a design options gets more difficult (each design option should be checked with all tasks of the dependent designer(s) for conflicts). This phenomenon is called complexity in collaborative engineering context. In order to cope with the complexity, we first need to understand the origin of such complexity. The main reason for complexity in collaborative teamwork is dependency and we need to understand and then present methods to deal with it. Dependency Dependency is a case when the choice of selecting an option depends on the confirmation or the outcome of another option. If a task is completely independent from any other task, the implication is that evaluation of its options is only based on the design requirements of the task. On the other hand if a task is dependent on one (or more) task(s), the designer cannot make

decision with out validating the outcome of the dependant tasks. In our model we consider the following three types of dependencies: 1. Task dependencies: this is a situation when a task should be finished before another task can begin (precedence relationship). An example for such dependency is in designing a car headlight, mechanical designer should define the geometry of the headlight so that the manufacturing engineer can decide on a suitable manufacturing process. 2. Information dependencies: when one task’s decision is based on the information provided by another task, there is information dependency between these two tasks. For example, in the car headlight design, mechanical designer should be informed about the driving conditions in order to make decision on headlight structure. 3. Resource dependencies: these types of dependencies are most common to ensure the manufacturability. The problem is that one resource (machine or material) is either not available or not capable of fulfilling the requirements of the task. An example in the car headlight case is that the punching machine in the manufacturing is not capable to punch sheet metals that are selected by the mechanical designer for the headlight. All three types of dependencies require coordination between designer and manufacturers, which is time consuming and might get forgotten. In order to enhance the dependency resolution process, we introduce the condition based negotiation model, and combine it with DDPM to reduce real communications between designers and manufacturers. Condition-based negotiation model (CNM) Negotiation is the process of interaction between two (or more) parties to reach a mutual agreement to resolve conflicts and/or dependencies. Specifically, in team design context, negotiation is needed when during a design process, one designer finds out that s/he is using some shared resource which s/he might pose conflict with others. Consider the headlight design example (presented as a case study in section 4.2), where the electrical designer needs 5 cm3 of space between body and frame to pass the headlight cables. If s/he was the only designer in charge of the whole system, s/he could change other requirements (based on the priority of this requirement) of other parts. But in a group design where several designer are responsible for different parts of design, one person can’t change parameters of other designers’ parts with out prior consultation. Following (Medina-Mora 1992), we define the primitive negotiation cycle for CNM in concurrent engineering composed of four actions, namely, propose->agree->act->satisfy, and a statement of conditions that need to be satisfied for the negotiation cycle to complete. At any of the four action points, another primitive cycle may be invoked in order to make a decision to decide whether to execute the action or not. Figure 3

5

Copyright © 1999 by ASME

shows three such primitive negotiation cycles and their linkages. One important distinction between our CNM and the Actionflow model is that CNM’s primitive negotiation cycles are explicitly embedded in design decision processes, which are captured explicitly by DDPM. In the following, we briefly describe the four actions and the condition. The application of the CNM negotiation protocol will be described in the example in Section 4. When a designer discovers a conflict between a task in his task list and other designers’ tasks, he will propose a solution by sending a request for the related party. This request contains the information about the task goal, task constraints and an id to

are confirmed and are not modifiable, designer has two options. Either reject the proposition or evaluate another option. In this case the proposition is rejected and the original designer should send the proposed task for another designer with the same expertise (if available). It is important to point out that our decision support model will not change the accepted tasks by itself. The reason is that in most cases, each designer has gone through several rounds of negotiations with other designer to decompose the higher level tasks, hence changing any of them requires new negotiation rounds and there is no guarantee that the design state would be the same. One of the advantages of ADN model is that it maintains the negotiation needs, so if designer decides to

P rop os al

A g re em e nt

C o n d itio n o f s a tis fa c tio n E n g3

Eng4

S a tis fa c tio n

P e rform anc e

D e sign E n gin e e rs

M a n u fa ctu rin g E n gin e e rs

P rop os al

A g re em e nt

C on dition of s atis fac tio n E n g1

C o n d itio n o f s a tis fa c tio n Eng5

E n g2

S a tis fac tio n

A g re e m e n t

P rop os al

S a tis fa c tio n

P e rform anc e

Eng6

P e rform a n c e

Figure 3: An Image of Negotiation in CNM identify the task for further communications. This process is called proposition. Proposition is a suggested course of action that designer wants the other person to do. The mathematical representation of proposal is given below: m

m

If [has_Conflict ( tlocal ,n , tteam ,n )]

 Propose [ onm
1]

Once a designer receives the proposal, he/she should evaluate it with his/her current plan (design process) and find out if it matches with the local design process so that s/he can agree or disagree. Matching implies that there are no conflicts with already accepted tasks. If there are no conflicts, the proposed task-state is changed to an option for designer and s/he can either accept or reject it. If s/he accepts it, then an agreement has been reached. It is also possible that the proposed task has an overlap with one of the local tasks. Given the fact that the current tasks

change any design activity, ADN will remind him/her that there is a dependency with other design task and coordination is needed with other members before selecting such option. After an agreement has been reached, the receiving designer should Perform or act on the assigned task. Acting on an assigned task means that the receiving party has made a commitment to satisfy the requirements of the assigned task and will report the results back to original designer. During the action process the original designer should not be concerned about the design task and it’s the receiving designer’s responsibility to allocate enough time and resources to satisfy the design requirements. An assigned task can spawn a new design process for the receiving designer and might not be related to his current design process. Even during decomposition of the assigned task, in order to find the

6

Copyright © 1999 by ASME

complete solutions, the receiving designer might need to negotiate with other designers. Satisfaction is when the designer from whom the request originated declares that his requirements were met. Once the receiver has completed the task, s/he will send back the results to the original designer. At this time the designer who proposed the task will check the results with his expectations of the proposed task. If they match, then s/he will declare satisfaction and the negotiation process terminates. In some situations, the results reported by the receiving designer are not what original designer expected. It is important to make the expectations clear from both sides to avoid any misunderstanding between two parties. To address this problem we introduce another concept called condition of satisfaction.

ME

M E : M echanical E ngin eer M F E : M a nufacturing E ngineer

Loop 1 Start ME

End

D esign H eadlight S tructure

D esign casing m ateria l

MFE

Loop 2 MFE

Loop 3

ME

V erify P roce ss plan

ME MFE

C reate P roce ss plan

MFE

Loop 4

Figure 4: Negotiation cycles between mechanical designer and manufacturing engineer Condition of satisfaction is a set of evaluation criteria (requirements) by a design task. These are set by the proposing and receiving designers. Although at a first glance conditions of satisfaction can be assumed as design goals, but they are more than that. If a task is assigned to a designer who does not have any background about the design context, s/he may choose a design alternative that isn't acceptable in the current design context. At this point let us go back to our headlight design case and choose “design headlight structure” task for mechanical designer. The design process consists of four central loops as shown in Figure 4. Lines connecting loops indicate triggering and dependency relationship between tasks. The “design headlight process” starts when mechanical designer proposes one alternative of structure to manufacturing engineer (loop 1). As a subtask of this proposal he proposes a material to build the structure with (loop 2). The manufacturing engineer reviews this proposal and either accepts or rejects the material. If he rejects the selected material, the mechanical designer should select a new material and start the process again. If he accepts the selected material, an agreement has been reached and the second phase of negotiation cycle is finished. In the next stage,

the action starts where the manufacturing engineer prepares the process plan for the designed structure (loop 3). Again at this stage, an internal loop of negotiation between mechanical designer and manufacturing engineer on the process plan is needed. Once the process plan is generated, and the results are satisfactory for the manufacturing engineer, he will send the results back to the mechanical designer to review the results. The final stage is verification of the process plan by the mechanical designer (loop 4). At this stage the mechanical designer verifies that all the selections made by the manufacturing engineer are within his criteria of satisfaction and finally accepts the plan. At this point the design process is finished. As a side note, its important to notice that the mechanical designer has a set of criteria for his design imposed by design situation (condition of satisfaction). These conditions are verified during the last stage of negotiation cycle, where designer examines the outcomes of negotiation with his/her own conditions. Where this condition will be used to evaluate the material selected by the style designer. Note that this condition can also be treated as a part of task requirement, but since it isn't in the style designer’s expertise, the mechanical designer only use it to validate the design outcome and there is not need for style designer to obtain this knowledge. CNM is used in conjunction with DDPM. At each stage, during the evaluation of an option in DDPM, if the designer finds a conflict or need of negotiation with another members, s/he uses CNM as a framework for communication. Depending on the nature of the design problem, s/he can control, exchange information or negotiate with other designers. ADN IMPLEMENTATION In this section we will present our implementation of ADN framework. We have implemented an agent-based system for 2 the purposed framework using JAVA language. The advantages of using Java are that it is object-oriented, network savvy, and portable across computer systems. In the next section we will first describe our agent architecture, then we will present a case study that was created for the purpose of testing the framework and some of our preliminary results. ADN architecture As shown in figure 5, our agent architecture has six major components namely: user-interface agent, design processcapturing agent, rule based engine and conflict detection agent, negotiation agent, option space generation and storage agent, and finally communication agent. User-interface agent is in charge of all the interfaces with the user (designer). User will interact with the user interface in each step of design process, receive results of negotiations with other designers, and input the design decisions to the agent. Design process-capturing agent is in charge of capturing the DDPM model. As shown in figure 6, through out the design 2

7

http://www.javasoft.com

Copyright © 1999 by ASME

Design processcapturing agent

Rule based engine and Conflict detection

Option space generation and storage

Negotiation agent

Network (other agents)

User-interface agent

Communication agent

Figure 5: ADN agent architecture process at each decision point, designer has to choose between available options of the option space. The option space generating, editing and storage agent generates these options. Once an option is selected, the process of evaluation and negotiation will be started and the decision making process isn't finished until the evaluation process is done and one of the qualified options is selected. Design process-capturing agent has a viewer tool to view the recent decisions. It also maintains the information about dependencies between local tasks and global design process. Option space generation, editing and storage agent is in charge of generating, editing and storage of the options for each local design decision. In our current implementation, the designer himself is in charge of generating the option space and inputting them in the system, but our architecture allows the use of an option generation tool or an agent which stores pre-recorded options. Rule based engine and conflict detection agent is in charge of finding the possible conflicts amongst the selected options. This agent will act whenever designer evaluates a new option or when another designer in the team proposes a new 3 task. In our implementation we used JESS© inference engine 4 for this purpose. JESS is an implementation of CLIPS© expert system for Java language. The rule-based files for each designer have two parts (i.e. general rules and discipline-based rules). The reason for doing so is that although some of the rules used by the inference engine are general to every design process (e.g. a designer can’t work on two design tasks at the same time), most of the rules are dependant to designer’s discipline. For example, electrical designer can use a plastic material for the cover of a headlight, but mechanical designer should avoid using plastics because of the applied loads on the headlight in high speeds. To overcome such problems, we have considered two separate rule sets for each designer. 1) General design rules, which are consistent with the policies of the design team, and 2) context-based design rules which vary from one designer to 3 4

another because of the difference in the nature of their design process. Negotiation agent is in charge of initiating negotiation with other designers. Once a conflict is detected by the rule based engine and is reported to the negotiation agent, this agent will find the corresponding designer and create an appropriate message. Depending on the type of the conflict that is reported by the inference engine, different types of messages are generated. If there is a change in the local design process, the agent will create a proposal message for the corresponding designer(s). If a proposed message received by another agent is received, the negotiation agent will deliver it to the inference engine to evaluate and wait for the results. If an incoming message as a result of a previous negotiation is received, the result is checked and if it is satisfactory, the result is reported to the inference engine and the decision-capturing agent to record the information in their database. Option space generation and storage agent is in charge of generating, editing and storage of the options. As mentioned in previous sections, for generating options, designer may use his previous knowledge, or pre-stored options stored in a database, or an auxiliary option generation tool. At this stage our implementation only accommodates the first two choices. As shown in figure 7, the information for each option can be entered to the system by a graphic user interface and user has the ability to browse, edit or remove option information. The dependant designer field is entered from a list of available designers and is totally based on designer judgement. Communication agent is in charge of connecting to the network, sending, and receiving messages. We used 5 ”knowledge query and manipulation language (KQML)” as the standard language for our agent communications. KQML is

Figure 6: Option selection window a language and protocol for exchanging information and knowledge. The communication agent converts every message, which is sent out by the negotiation agent to a KQML message and sends it out to the proper agent. At the same time, if the

http://herzberg.ca.sandia.gov/jess/ http://www.ghg.net/clips/CLIPS.html

5

8

http://www.cs.umbc.edu/kqml/

Copyright © 1999 by ASME

Figure 7: Option space generation and storage window communication agent receives a message from another agent, it will extract the information and report it to the negotiation agent for interpretation. The above-described architecture is a general architecture for the ADN model agent that was implemented for this research. In the following section, we will present a case study that was developed in order to verify the proposed conceptual framework and also to test its performance in a design team. Case study In order to check the validity of ADN model, we developed a case study to understand the feasibility and implications of our model in solving real world problems. In this case study our objective is to design and manufacture a car headlight for a new model of a car. The project manager in charge of the front section design lays out the basic requirements and constraints to the design team consisting of four members (i.e., mechanical designer, electrical designer, style designer, and manufacturing engineer). The top-level task for each designer is to design the corresponding components of the headlight and for the manufacturing engineer is to take the product models (CAD drawings) and design the appropriate process plan for the designed components. To illustrate the applications of the ADN framework, let us concentrate on the manufacturing engineer for the time being. The reason for doing so is that in a typical design and manufacturing environment, usually designers work in design department and manufacturing engineers work at the shop floor. One of the main problems in traditional design processes is that manufacturers are not involved in the design until final stages of design and hence the manufacturability issues are not considered. The decision-made tree for mechanical designer is given in figure 8. In the following, we will illustrate the coordination

between mechanical designer and manufacturing using the ADN framework Task 1: Decide on structure: As illustrated in figure 4, mechanical designer should make a decision on the structure of the headlight. Two options that are available to the designer are 1) parabolic and 2) spherical geometry. In this case the design decision has close dependency to the manufacturing engineer. Since the spherical geometry is the most common geometry in designing a car headlight, let us assume that the mechanical designer starts his evaluation with this option. His corresponding agent finds the dependant designer (manufacturing in this case) and sends a message to the manufacturing engineer about selection. The manufacturing engineer’s agent receives the information and pops up a window stating the request. Manufacturing engineer may agree to the proposal since the manufacturing facilities are capable to manufacture such geometry. In this case, the agent will send back his agreement and the conflict is resolved in the first round and no further negotiation is required. Task 2: Decide on material: in order to make decision on the material type for the casing, mechanical designer should generate options. In this case designer generates two options: 1) plastic, 2) glass. Obviously, the material selection has a significant impact on the manufacturing process. So there is a dependency between this task’s outcome and manufacturing engineer’s preferences. Now suppose the mechanical designer starts his design task by evaluating the “glass” option for the headlight. S/he uses his/her agent to propose this option to the manufacturing engineer. The manufacturing receives his/her proposal and evaluates it and rejects this selection because the manufacturing department isn't equipped with machinery to

Figure 8: Decision made tree for Mechanical designer

9

Copyright © 1999 by ASME

build the headlights form glass with the required constraints. At this point the mechanical designer should evaluate another option and this time s/he proposes the plastic, which the manufacturing engineer agrees to use as the material for the headlight casing. At this stage the mechanical designer is finished with this branch of the design process but s/he still needs a report from the manufacturing engineer on the status of the manufacturing process. Task 3: Build the casing: this task is an example of partial solution. A partial solution is a solution, which cannot be further elaborated by a designer. In this case, creating the manufacturing plan for the headlight is a task that the mechanical designer can not elaborate further. Hence s/he will propose this task to the manufacturing engineer with the required specifications (material, geometry, tolerances…). Manufacturing designer’s agent receives the request and once an agreement is reached, this task will be added to manufacturing engineer’s task list. From this point, this task is manufacturing engineer’s responsibility and s/he should satisfy its requirements and report back the results to the mechanical designer. Discussion: Several observations can be made from the above example. First, engineering level collaboration requires dependency checking with other departments (manufacturing in this case). By considering the manufacturing aspects of design process at the design stage, designers can make most effective and efficient use of their time and resources. Second, agents play a critical role in facilitating coordination among team members. As shown in the above example, mechanical designer initiates coordination with the manufacturing engineer by proposing one option for designing the casing. Once the proposal was received by the manufacturing designer, two agents worked together to overcome the dependencies and propagate status of changes or updates among team members. No human interaction is needed during this process. Third, the proposed negotiation protocol governs the conflict resolution among team members until a settlement is reached. The ADN framework as illustrated in the above example, has significant advantages over traditional design and manufacturing methods. Concurrency: The ADN approach attempts to achieve concurrency in design and manufacturing process by integrating design and manufacturing processes together from early stages of the design process. The term concurrency is used here because while the design is not completed yet, the manufacturing is involved and can plan for allocating required resources. Communication loads: The overhead for achieving concurrency is communication and coordination among members, since identifying and maintaining task dependencies requires significant amount of coordination and communication. ADN reduces the real time needed for communications and dependency maintenance by using agents.

Design and manufacturing integration: Our main goal for developing ADN is to reduce the overall time of design and manufacturing by involving manufacturer in the design process at early stages to reduce downstream conflicts. To make this integration possible, one must be able to link design and manufacturing tasks together. Moreover, identifying design dependencies to manufacturing procedures requires information form the manufacturing side. CONCLUSIONS AND FUTURE WORK In this paper an agent-based decision network framework (ADN) for collaborative design was introduced. Two major aspects of collaborative decision-making process (i.e. local decision-making (DDPM) and condition-based negotiation (CNM)) were discussed. The ADN framework was modeled and simulated in an agent-based design environment and a case study was created to examine the validity of the proposed framework. The initial results indicated that ADN framework increases the efficiency and effectiveness of the design process comparing with traditional collaborative design process. Further investigation is required to study the impact of using different option generation methods and applications of utility theory in selecting the best options from the candidate option set. The tradeoffs between selecting another option if a conflict arises and negotiation until the conflict is resolve also needs to be investigated. ACKNOWLEDGMENTS This research project was primarily supported by NSF career award under grant DMI-9734006. The authors are grateful to NSF for its support. The authors would also like to thank three anonymous reviewers of the paper for their helpful comments and suggestions. REFERENCES Barbuceanu, M. and Fox, M. S. (1994), “Conflict management with an authority/deniability Model”, Proceedings of AAAI-94 Workshop on Models of Conflict Management, AAAI Technical Report WS-94-04, Seattle, WA. Decker, K. S., and Lesser, V. R., (1995), “Designing a Family of Coordination Algorithms”, UMass Computer Science Technical Report 94-14, University of Massachusetts, Amherst, MA. Hazelrigg, G. A. (1998), “A framework for decision-based engineering design”, Journal of Mechanical Design, Vol. 120, PP 653 – 658. Jin, Y., and Levitt, R. E., (1993), “I-Agents: Modeling organizations problem solving in Multi-agent teams”, Intelligent Systems in Accounting, Finance and Management, Vol. 2, PP 247-270. Liu, J., and Sycara, K., (1994), “Distributed problem solving through coordination in a society of agents”, Proceedings of the 13th International Workshop on Distributed Artificial Intelligence, Seattle, WA.

10

Copyright © 1999 by ASME

Malone, T. W., and Crowston, K., (1991), “Towards an Interdisciplinary Theory of Coordination”, MIT Sloan school working paper #3294-91-MSA. Medina-Mora, R., et al, (1992), “The action workflow approach to workflow management technology”, The Information Society, Volume 9, Number 4, PP 391-398. Mistree, F. and Allen, J. K., (1997), “Optimization in decisionbased design”, Position paper: Open Workshop on Decision-based Design, Orlando, Florida. Mistree, F., Smith, and W. F., Bras, B. (1993) “A decisionbased approach to concurrent engineering”, Chapman & Hall, New York, PP 127-158 Pahl, G. and Beitz, W., (1996), Engineering design – A systematic approach, second edition, Springer, London. Petrie, C., (1993), “The Redux’ server”, proceedings of the international conference on intelligent and cooperative information systems (ICICIS), Rotterdam Simon, H. A. (1969), The science of artificial, MIT press, Cambridge, Massachusetts Smith, R. G., (1980), “The Contract Net Protocol: High-Level communication and Control in a Distributed problem Solver”, Readings in Distributed Artificial Intelligence, PP 357-366 Suh, N. P. (1990), The principles of design, Oxford University Press, Oxford. Von Neumann, and J., Morgenstern, O., (1953), Theory of games and economic behavior, 3rd edition, Princeton University press, Princeton, New Jersey.

11

Copyright © 1999 by ASME