Negotiation in DAI as an Infrastructure Component for Collaborative Enterprises*

Keith J. Werkmant IBM Federal Systems Company, Advanced Technology Department

Abstract

This paper examines how negotiation in dis- tributed artificial intelligence (DAI) acts as in integral component f o r the development of tools nec- essary to support collaborative enterprises. As an ex- ample of how negotiation plays a key part, we esam- ine its use for conflict resolution among participants involved in the concurrent design of connections in buildings. Described is the Designer Fabricator In- terpreter (DFI) System, U knowledge-based tool which fosters interaction among structural engineers (de- signers), fabricators and erectors. The system’s archi- tecture models the participants as semi-autonomous computer “agents” which reason f i o m their design evaluation perspectives. Alternative are proposed through a novel incremental negotiation method called knowledge-based negotiation. The resulting ne- gotiation methodology provides for potentially “better” designs as a result of &Bering agent viewpoints.

1 Introduction

As a result for the need for collaboration within en- terprises, a new form of collaborative information pro- cessing system will evolve in the near future. These systems will contain a variety of diverse databases and knowledge-based “agent” subsystems which will act as assistants to humans such as engineers. Each agent will have its own perspective on its particular domain of expertise and communicate it among other agents during the design critiquing phase of a n artifact long before the artifact is ever realized in a physical state. The result of such an automated collaborative design

‘The following work was performed while the author was employed by the National Science Foundation sponsored En- gineering Research Center, Advanced Technology for Large Structural Systems (ATLSS), at Lehigh University.

t Author’s current address is IBM Federal Systems Company, Route 17c, Mail Drop 0210, Owego, New York 13827, Email: kcithw Bonet.ibm.com

system will be better engineered artifacts, delivered in a timely fashion without incurring development cost overruns.

Such collaborative systems will require a variety of enabling technologies such as constraint directed search [l] and shared dictionary knowledge includ- ing domain models among design participants[2]. In addition, Distributed Artificial Intelligence (DAI) re- search will provide additional enabling technologies necessary for collaborative systems such as the design of autonomous domain agents, the creation of effi- cient interagent communication languages, the devel- opment of methods of agent coordination, and pro- visions for conflict resolution through agent negoti- ation. This paper specifically underscores the need for negotiation among agents (automated or human) during collaborative/cooperative problem solving in order to promote coordination during product de- sign. A novel form of zncremental negotzatzon called knowledge-based negotzatzon is presented. Through this negotiation process, conflicts are resolved by use of shared agent knowledge representations called shareable agent perspectzves. Agent’s perspective are made “shareable” by providing each agent with an is- sue indexing scheme. This aprzorz indexing scheme allows conflicting agents to relate to the other agents’ perspectives. This allows each agent to reasonably negotiate by generating counterproposals without de- tailed knowledge of the others agents’ issues.

In the knowledge-based negotiation scheme pre- sented in this paper, all agents maintain unique perspectives about objects in the shared domain of problem-solving. Each agent’s perspectives is grouped and accessible by other agents through an indexing concept called the domazn aspect. In addition, two agent perspectives can be combined to form another knowledge construct called an znteragenl m u e rela- taon. Pairings of interagent issue relations are then grouped into a redatzonal network which is maintained by a third-party arbztrator agent. The arbitrator uses this relational network to develop alternative sugges-

0-8186-4082-0/93 $3.00 0 1993 IEEE 104

tions for the conflicting agents during its mediation phase of assistance. The arbitrator develops its sug- gestion by first searching the negotiation dialog for rel- evant issues between conflicting agents that occurred as a result of previous agent negotiations. The arbi- trator then reviews the shared network for relations that are known to exist between the agents. Upon finding a “reasonable” interagent issue relation, the arbitrator presents the relation to the agents who use them to identify other possible viable alternatives which they might not have considered during their negotiation. If agents still do not agree (mediation fails), the arbitrator enters into binding arbitration which forces a “fair” solution on the agents based on their past negotiation dialog. The resulting re- search is implemented as the Designer Fabricator In- terpreter (DFI) System which integrates diverse agent knowledge of the construction domain into a “what- if” tool used for critiquing connection designs in build- ings. The DFI system allows a structural engineer a t preliminary design time the ability to review alterna- tive steel connections which have been cooperatively evaluated from multiple agent viewpoints. The engi- neer can then select the connection design which is the most feasible and economic t o produce and hence more beneficial for the construction project.

This paper is structured in the following fashion. Section 2 discusses some common product develop- ment problems found within industry today. Specif- ically, communications problems within the frag- mented U.S. construction industry are used to high- light some of these basic product development prob- lems. An illustrative example of a critique of a construction design is presented in Section 3. This gives the reader a basic overview of the distributed problem-solving nature of the DFI system and the agent negotiation process. An overview of the DFI system components are outlined in Section 4 includ- ing the system’s information flow, agent communi- cations language, the DFI Relational Network, the agent’s evaluation process and agent negotiation and conflict resolution by a third-party arbitrator agent. Section 4.4 details the various agent proposal strate- gies used in DFI including key issue and agent issue proposal and counterproposal negotiation strategies. A discussion of the arbitrator’s role within DFI pre- sented in Section 4.5. The actual Knowledge-Based Negotiation Model is presented in Section 5. Section 5.1 includes a discussion of the various types of local and global knowledge required by this negotiation ap- proach. The concept of the shareable agent perspec- tive is presented in Section 5.2 including a description

of an agent perspectives, domain aspects and intera- gent issue relations. Section 6 gives a summary and a discussion of future work.

2 Present Industry Practice

Construction projects, as with any product design effort, frequently include several participants, some- times a t geographically distributed locations. Prob- lems usually arise when vital information is not read- ily available t o participants in the process at the time it is needed to support decisions. This “lack of com- munication” problem is seen in the construction do- main where constructions drawings are updated a t the construction site via notes on drawings. As engi- neering changes are made by the designer’s office, new drawings are sent to the field. No convenient meth- ods currently exists for the integration of information between the contractors drawings with notes and new engineering drawings sent to the field. At times, the contractor’s field drawings are as many as three revi- sions behind the engineer’s most current drawings[3]. Therefore, a distributed view of the product design exists in a non-computer processable form.

Similar problems occur between work groups dur- ing new product development. Necessary information is captured locally and not disseminated to the par- ties that need it in order to make informed design decisions. In addition, the communication problem is compounded as additional participants become in- volved in the product development. For example in the construction industry, this might involve the ad- dition of the owner and architect a t the front of the development process and the facilities manager a t the back end of the process. The question becomes one of how to include new participants in the design of a product a fashion where they can contribute t o the overall knowledge base needed to develop the prod- uct. This required the need for all participants to have a basic understanding of the product domain and a common vocabulary in which t o communicate their concerns of design, manufacture, in-service support, etc. In addition, this has to be done in an easy fash- ion so as not to alienate the new participant from the process. One proposed solution is the development of a set of knowledge-based computer tools which act as “agents” for the product development participant. These “agents” not only provide a specific participant interface to the computational product design system, but they also can act on behalf of the participant when they are absent during times when design decisions

105

are made. Once again, the construction domain is used as an example to highlight the communication and coordination problems found in any product de- velopment effort.

2.1 The Construction Design Process

This section briefly outlines the four stages in the design and construction process from the origination of a design to the implementation of the constructed physical artifact. The basic stages in the construction domain include conceptual design, preliminary design, detailed design, and construction. Figure 1 shows the stages and participants involved a t each stage along with the information gaps (shown as small black dia- monds).

The stages related to Figure 1 are described below:

Conceptual Design: This stage involves two principal participants: owner and architect. The participants determine the building topology (i.e. number of stories, typical floor plan) and site lay- out.

Preliminary Design: This stage involves two principal participants: designer and fabricator. The building components are sized from the structural analysis and preliminary connection configurations are chosen.

Detailed Design: This stage involves two prin- cipal participants: fabricator and erector. The connections are designed and detailed a t this stage. Construction plans are developed for both the fabrication and erection sequences.

Construction: This stage involves many differ- ent participants performing different tasks simul- taneously. Example tasks include: steel erection, fire proofing, and pouring concrete.

In the DFI system, only the information interface gap between design engineers and fabricators of struc- tural steel systems was examined. This interface was chosen because of its importance and lack of under- standing and cooperation that exists between design- ers and fabricators on their respective tasks *. The participants involved in the design of beam-to-column connections are described below:

0 Designer: This is the structural engineer. It is his responsibility t o design a structure (con- nection) that meets the necessary load require- ments given the constraints of the architects floor

‘A more detailed description of the stages and information gaps can be found in [4].

CONCEPTUAL DESIGN

ARCHITECT

Figure 1: Design and Construction Stages and Infor- mation Gaps

plan layout of the owner’s functional needs of the building.

Fabricator: This is the steel fabrication com- pany. It is the fabricator’s responsibility to obtain the necessary materials (steel members, bolts, welding rods, etc.) and w t and assemble as much of the connection pieces as possible in the shop. The fabricator is constrained by the en- gineer’s design in the necessary number of holes to punch, the number of bolts to insert, and the type and lay of the welds.

Erector: This is the field erection company (so called iron workers) that “hang” steel. Erector’s responsibilities include preparing the site and as- sembling the building. The erector is constrained by the delivery of pieces from the fabricator and by the engineer’s design and fabricator’s inter- pretation of that design.

In the ideal world, the concerns of each downstream participant would be made known a t preliminary de- sign time. Therefore, issues of safety in assembling steel members in the field from the erector viewpoint would be made known to the design engineer. This could in turn influence the design and eventually the Drocess of fabrication for the fabricator. who might .,

106

in turn complain about one of his issues, possibly re- lated to material cost or difficulty in performing the necessary operations.

2.2 The DFI Approach

The DFI system is an initial attempt to capture human civil engineering knowledge from the various participants involved and then model that knowledge as semi-autonomous computerized “agents.’’ These

Figure 2: Designer’s Initial Configuration

agents use their perspectives to negotiate the out- comes of their critique of connection designs in buildings. Through the development of integrated knowledge-based design and construction systems, agents can interactively utilize data and knowledge from other agents’ perspectives throughout the design critiquing process. By integrating multiple agents’ perspectives with a method of distributed problem- solving using negotiation, a cooperative environment of compromise can be provided. Such an environment would be useful for an engineer during preliminary de- sign when general constraints from downstream con- struction agents could highlight potentially problem- atic design decisions. The engineer could use this feed- back to reconsider a design in order to make that de- sign easier and less costly to fabricate and erect. The DFI system attempts to provide the necessary envi- ronment to allow the sharing and integration of multi- ple perspectives among participants during the design review process. Similar design review processes are likely to occur during concurrent engineering of prod- ucts or large systems. Examination of parts of the DFI system should provide some insight what might be necessary to develop intelligent automated design aids for the concurrent engineered projects in c.ollab- orative enterprises.

3 An Illustrative Example

An example of a connection evaluation with ne- gotiated alternative proposals between the agents is presented in this section. The agent models are im- plemented in a frame-based knowledge representation environment developed a t Lehigh University written in Quintus PrologTM. The environment also inc.or- porates an integrated graphical user interface writ- ten in Quintus ProWindowsTM running on SunTM workstationst. Each agent has unique knowledge

t Quintus Prolog and Quintus Prowindows are trademarks of Quintus Computer System, Inc. Sun is a trademark of Sun Microsystems, Inc.

about connections including a standardized quahta- tive rating scheme for the issues related to each con- nection. The higher the value, the more acceptable it is. After the user enters a connection and selects the evaluate option, the user is asked for a single, most important key zssue which is maintained by all agents during their proposal of alternate connection configu- rations. In this example, the user specifies an endplate connection with a key zssue of strength. The agents will attempt to suggest alternative connections that are of the same connection type and with the same value for strength as the user’s specified endplate con- nection. Initially, the arbitrator c o m m a n d s the de- sign agent to a c c e p t the user’s endplate connection proposal using strength as the positive supporting is- sue because the user is the designer in the first cycle of negotiation. The design agent then informs all agents of the key issue and r e q u e s t s that the proposed con- nection be evaluated. The designer’s request is shown graphically in the deszgner’s wzndow in Figure 2 .

Before each agent’s evaluation, the arbitrator re- views all proposed connections to determine which agent is most detrimentally affected and hence should go next. In this case, the erector is most severely af- fected by the designer’s endplate proposal. The erec- tor determines that the designer’s proposal is unac- ceptable because the endplate connection is too dif- ficult in terms of erectzon ease. Therefore, the erec- tor refuses (objects to) the designer’s connection and looks to the fabricator in hopes that it might have pro- posed an acceptable connection. At this stage, the fabricator has not yet proposed anything, so the erec- tor selects a connection from the set of possible con- nections about which it knows. The erector r e q u e s t s the plates-tee because it satisfies the erectzon ease is- sue as well as satisfying the user specified key zssue. This is depicted in the erector’s wtndow in Figure 3 .

It is important to note that the erector has directed the proposed connection back to the designer for re- view. The designer accepts the erector’s proposed connection because it exceeds the key zssue of strength as well as meets the designer’s criterion for the end-

107

Figure 3: Erector Replies With Plates-Tee

Figure 4: Designer Agrees With Erector

plate connection. Also, the value of the key zssue has been increased to the new value associated with the erector’s proposed plates-tee connection since it was higher than the original designer’s strength key assue for the endplate connection. By increasing the value of the key issue, the search space of possible connec- tion alternatives is reduced, thus causing the agents t o converge more quickly on a set of agreeable connec- tions. The designer’s acceptance is seen graphically in the designer’s window in Figure 4.

Next, the arbitrator reviews the connection situa- tion and notices that two agents have proposed the same connection. Usually, this would cause the ar- bitrator to inform all agents of a halting condition. This is not the case here because an “unfair” evalua- tion condition has occurred - unfair in the sense that the fabricator has not yet had a chance to evaluate any connections. Thus, the arbitrator gives control to the fabricator who looks at the designer’s connec- tion and immediately notices that materzal cost is the problem-issue. Since both the designer’s and erec- tor’s connection are the same, the fabricator needs only t o review the plates-tee connection and propose an alternative connection. In this case, the next best connection that maintains the key wsue of strength as well as improves the fabricator’s materzaE cost issue is the direct flange weld wzth shear plate as seen in the fabricator’s window in Figure 5 .

Again, the arbitrator reviews the evaluation pro- cess and notices that two agents have agreed on a connection and that each agent has had a chance a t suggesting an alternative. There is also the pos-

Figure 5: Fabricator Proposes Flange Weld

sibility that agents may not be able t o propose an alternative:. The arbitrator informs all agents of the halting condition and control is returned to the user. At this point the user can ask any agent t o explain its proposed connection or continue with the evalu- ation. If the user continues, the arbitrator reviews the situation and notices that no particular agent is in “peril”, and allows the agents to determine their own control sequence. Whichever agent received the last message is given a chance t o respond to that message. In this case, the fabricator proposed a connection t o the designer. The design agent, upon reviewing this connection, notices that the fabricator’s connection satisfies all issues of the designer. Thus, the design agent accepts the fabricator’s proposal of a direct flange weld with shear plate as seen in the designer’s window in Figure 6. This causes another halting con- dition upon where the arbitrator returns control to the user.

In Figure 6, the user has the option of selecting but- tons from the User/Arbitrator window. This allows the user to obtain a summary of the initial connec- tion, review the agent dialog of the entire negotiation process from start to finish listing each agent’s pro- posal and related issues. Also, the user can change the overall key issue which focuses the negotiation, continue the agent evaluation, ask for help, or stop the agent evaluation and exit. Moreover, the user can select buttons from the Agent windows and obtain a summary descxiption for each agent’s proposed con- nection or ask the agent to explain its last proposal action. The explanation appears in the system’s In- put/Output window beneath the Agent windows, as seen in Figure 6, and includes the key issue, the con- nections under review, the agent’s response to the re- viewed connections, i.e., the acceptance or rejection of other agent’s connection, the reasons for the action, and the agent’s proposed connection with its justifi- cations. Currently, the explanation of the agents’ ac-

:In such cases, the agents enter into negotiation using vari- ous techniques such as logrolling[5]. In cases where the agents cannot resolve their differences, the arbitrator is consulted.

108

Figure 6: Designer Agrees With Fabricator After Continuing

tions are in the form of keywords taken directly from the DFI relational network. Future explanations will relate to more robust user models of each agent in- volved in the negotiation process. At times, it is also useful for the user to be able to refuse (object to) and remove a connection from the evaluation process if the user knows that a particular connection is not acceptable.

4 Distributed Problem-Solving in DFI

The computerized agents in the DFI system act in both a cooperative and competitive fashion when cri- tiquing a proposed connection design. The result of the overall cooperative behavior of the agents allows them to work together toward a common goal, sug- gesting alternative connection configurations “simi- lar” t o that which was originally specified by the user. In addition, agents also behave competitively during the proposal process in order to maximally improve their own positions during each proposal cycle. To provide some means of balance, an independent arbi- trator agent is used to monitor agent proposals and mediate the process, interceeding only when ncces-

sary.

4.1 Informat ion Flow

An information flow diagram of the DFI system is shown in Figure 7. The solid boxes indicate sequen- tial processes, the dashed box represents the iterative agent interaction process, and the large ovals repre- sent input from and output to the user. The arbi- trator agent resides a t the logical center of the agent interaction process, monitoring all agent communica- tion, allowing the arbitrator to assist in the problem- solving process when necessary.

Initially, the engineer reads in a description of a building and selects a floor. Then a particular col- umn and beam are selected and a connection is de- veloped between the two members. Calculations are performed to determine the moment capacity of the beam and establish the required connection type. A list of connection component alternatives is shown t o the user. At this point, the user can evaluate a de- sign to see what effect it has on the fabrication and field erection processes. After the multiagent evalu- ation has been completed, the user is presented with the original connection configuration and three po-

109

Table 1: Speech Related Social Actions Initial Input - i-

Initial Calculations 1 Connection Type

Connection Input -?=F--l ............... 1... ............ v : Connection Evaluation .............................

t l

.............................

t l

Output of Alternative Connections

Figure 7: DFI Information Flow Diagram

tentially different connection configurations proposed by the design, fabrication and erection agents. The user can review the results and decide what design t o accept.

4.2 Agent Communications

Communications within the DFI system occurs through a centralized communications medium called a blackboard [6, 71 by means of a commonly under- stood interagent communications language. Because of disparate knowledge between each expert agents, a commonly agreed upon set of communications primi- tives was developed. This shared vocabulary provides a basis for commonality among the agents during eval- uation. As stated in [8], logically valid statements made by one agent in this language should be accepted as valid by other agents. Because of the shared lan- guage, an effective form of negotiation between agents can exist. By selecting the right message primitives combined with the right historical dialog (prior pro- posals and context), agents can communicate abstract levels of intentions and therefore reason about the be- liefs of other agents [9]. The DFI interagent language is based on work done in the area of speech act the- ory [lo] where speakers perform speech actions like

Accept Ask Command Convince

Explain Inform Refuse Reply Request

Agent accepts Recipient’s cause X. Agent doesn’t know Recipients cause X. Agent wants Recipient to cause X. Agent convinces Recipient to want X. (Makes Recipient believe he wants X) Agent explains lack of outcome X to Recipt. Agent informs Recipient of X (simple tell). Agent refuses Recipient’s request. Agent replies to Recipient’s ask. Agent asks Recipient to want X.

Table 2: Agent Labels and Related Issue

DESIGN AGENT

Strength Stiffness

Reliability Versatility

FAB. AGENT

Fabrication Cost Fabrication Ease

Material Cost

ERECT. AGENT

Erection Cost Erection Ease

Safety

requests, assertions, and suggestions. Cohen and Per- rault [ll] have suggested that speakers actually use a plan-based approach when making utterances. Thus, the listeners try to infer the intentions of the speaker’s speech plan and offer assistance if they can by noting obstacles in the speaker’s plan. A similar plan-based approach to generating responses to agent queries is used in the DFI system. The communications primi- tives used in DFI are based on work by Bruce[l2] who models sociaE actions that occur between people. The social actions used in DFI are listed in Table 1.

4.3 DFI Relational Network

Agents in the DFI system evaluate and suggests al- ternative connection designs based on their own view- points as well as in consideration of other agents’ per- spectives. Each agent viewpoint is decomposed into several unique agent issues. The issues are based on different aspects of connections such as economics, feasibility, and type of material, to name a few. The agents in DFI system and their respective issue labels are seen in Table 2.

A network of semantic relationships between these

110

’, . . . . . . . .. . . . . . . . . . . . . . . . . . . . _... . . . . . . . . . . . . ., . . p2&-H!iJ p 1-g..~j@Gq 1 ....

.Reviewina A#nl Detsrmlnes Woml ISSUO

Generatos Alternatives Based on Issue.

I. Ask to Select

AitematlveS Whleh Meet the Key W e .

i Ask -1 to Ordor this Llsl

Based on Proposing Agenl’s PerJpoctlve.

J Beled Best Alternative from Returned Lis Based on Reviowinq Aaenl‘s Preference.

roposal? Evaluate Proposal

I 1

FABRICATOR I I ..... ~ ~ ; ~ ~ ~ q

.... . i A.. . ..:. >...

Figure 8: DFI Relational Network

agent issues has been developed. This DFI Relational Network, depicted in Figure 8, illustrates how a con- nection is related to designer, fabricator and erector agents issues in terms of functional, component, and fastener aspects of a connection. The network pro- vides an abstract level description of agent issue in- teractions that allows the arbitrator to detect imme- diate conflicts between agents and suggest possible so- lutions. The proposed network scheme allows for the addition of new agents to the distributed problem- solving model. Initially, each new agent must share its knowledge of relevant issues with the arbitrator so that they can be added t o the network and used during negotiation.

4.4 Agent Proposal Strategies

There are many negotiation proposal strategies used between agents depending on the type of role the agent plays in the system. In the contract-net protocol the role of the agents is to recognize and al- locate resources to agents to allow them to perform their tasks. The nodes in the contract-net protocol generate proposals and negotiate without any histor- ical use of previous agent interactions. This is not the case in knowledge-based negotiation systems like DFI which attempt to produce detailed explanations of agent interactions during the negotiation process.

4.4.1 Key Issue Directed Proposals

In DFI, the focus of the agent proposal and negoti- ation process is controlled by a key issue. The key issue consists of a single (local) agent issue which ev- ery agent must consider before proposing an alterna- tive. Since the key issue is non-negotiable and must be

Revlewfna Aaent Saves as Potentlal AN.

c Selects Best Alternative

from List of Potentlal Alternatives.

i Proposes Best Alternative

Figure 9: Agent Evaluation and Proposal Process

maintained throughout the negotiation process, the key wsue agent’s viewpoint tends to become domi- nant. Because the key issue agent is given the power to maintain a non-negotiable issue position, it attains a higher bargaining power over the other agents. This elevated bargaining power helps constrain and focus the proposals made by the other agents. In the DFI system, the key issue is selected by the user and re- flects the user’s interest in a particular agent issue for a given connection evaluation.

4.4.2 Agent Issue Directed Proposals

The general agent zssue directed proposal scheme seen in Figure 9 has been implemented for distributed problem-solving among semi-autonomous agents in the DFI system. In DFI, each agent (called the re- vaewzng agent when reviewing a connection) reviews all of the other agents’ proposals and then proposes the best alternative possible (by either accepting an existing proposal or generating an alternative coun- terproposal). Each agent reviews another agent’s pro- posal based on the first (reviewing) agent’s unique set of issues and how they are affected by the character- istics of the proposal.

111

The process outlined in Figure 9 starts with the reviewing agent evaluating the proposing agent’s con- nection to determine which issue is most problematic based on the connection’s characteristics. If the re- viewing agent finds that the current connection pro- posal is acceptable, then the reviewing agent accepts the proposing agent’s connection and proposes this as its own solution. If on the other hand the review- ing agent notices that one of its particular issues is effected, the reviewing agent will search for a counter- proposal which improves its effected issue while main- taining or improving the value of the user’s initial key issue. The reviewing agent then generates alternatives that enhance the worst issue and submits this list for review to the key issue agent. The key issue agent selects only the connections that meet or exceed the user specified key issue and returns this new list back to the reviewing agent.

In a n attempt t o provide a coordinated behavior among the agents (cooperative solution), the review- ing agent sends the list of alternatives which meets the key issue to the proposing agent for its review. This gives the proposing agent a chance to rank the list of alternatives based on its preferences8 . The review- ing agent then takes this ordered list and selects its best possible connection counterproposal in response to the proposing agent’s initial proposal. The review- ing agent saves this specific counterproposal and per- forms a similar evaluation for all other agent pro- posals. Upon evaluating all other agent proposals, the reviewing agent selects its best alternative from its best alternatives list and proposes that alterna- tive t o the initial proposing agent whose proposal is to be replaced by the reviewing agent’s proposal. This last action can be varied by the evaluation mode of the reviewing agent. If the reviewing agent takes the competitive help single agent approach, the reviewing agent will simply select and counterpropose its best alternative from its best alternatives list as described above. If on the other hand the agent takes the more cooperative help other agents approach, an additional review it performed by the reviewing agent on the alternatives in its best alternatives list to find an al- ternative which might be beneficial to other agents.

4.5 Arbitration in DFI

At some point during the agent evaluation and ne- gotiation process, a proposing agent might exceed the acceptable limits of the issues of the group. This may

fIn cooperative mode only. In competitive mode, the original propoaing agent can also delete connections it finds unsuitable.

require a n agent to concede an issue and propose an alternative in order for the negotiation t o proceed. It is also possible that a n agent may not be able to concede an issue because it would be too costly for that agent. In such cases, the arbitrator agent must be brought in to attempt to mediate a solution be- tween two conflicting agents. Initially, the arbitrator monitors the current status of all agent proposals and reviews each proposal for any immediate problems that they might cause for an agent. If the arbitra- tor detects a problem that affects a particular agent, it warns the agent and gives control t o that agent so that it has a chance to respond t o the problem caused by the proposed connection.

In addition to detecting agent problems during pro- posals, the arbitrator also reviews the history of pro- posed connections to determine if a halting condition or a “deadlock” situation has occurred. The arbi- trator informs all agents of a halt of the evaluation process when two agents propose the same connection (one agent agrees with another). The resulting con- nections are presented to the user for review. If the arbitrator notices a “deadlock” situation (where the same proposals are being made by the same agents in response to a previous agent’s proposal, also known as a flip-flop condition), the arbitrator intervenes by an- alyzing the situation and attempts to convince one agent that the other would agree if only the first agent would relax the importance of a n issue or drop it al- together. The arbitrator generates the argument of which issues are relevant from abstract interagent is- sue relations it obtains from the DFI relatzonal net- work as well as the history of past proposals and is- sues. The arbitrator does not contain any knowledge about each agent’s unique operations knowledge. In order for the arbitrator t o augment a proposed solu- tion with additional arguments, each agent has to be queried as to the reason and explanations behind the issue relationship under consideration similar t o other negotiation systems[l3]. A full description of the ar- bitrator’s mediation and arbitration strategies can be found in [14, 151.

In situations where agents still fail to agree after initial negotiation methods, the arbitrator determines the final solution given the input from both agents as to the importance of each agent’s issue. This is a form of meta-level control[l6] in that the final decision is based on an a priori policy of acceptance specific to the given domain of construction. If the agents’ pro- posals do not converge after six iterations (considered adequate given the evaluation process), the arbitrator stops the evaluation and returns control to the user.

112

4 Agent Proposss

I Arbltrstor Reviews All Prowsalr: 1 ) Atbllrator Updates Key losue 2) Chck for Halting Condition 3) Check for Agent Mesaages 4) Check for Ink”1on EL Assist

-1 Awnt Evaluates Proposals I=/

tion, if agents are to provide some form of explanation of their reasoning of the proposal process, they must be able to communicate issues that the other agents can understand. This is done through the sharing of agent perspectives with other agents. Though shar- ing common knowledge and agent perspectives, agents can review the dialog of the negotiation and use this knowledge to make better informed proposals a t fu- ture steps in the negotiation process. The history of the agent dialog also provides a basis for explana- tions for the user. The negotiation dialog describes the agents’ behaviors a t each point in time during the negotiation process. The user can use the resulting dialog-based explanations to make a better decision about which final solution to select.

no

Figure 10: The Basic Arbitrator Control Loop

The main arbitrator control loop of the negotiation process within the DFI system is outlined in Figure 10.

The actual order of agent proposals is determined by the arbitrator, when appropriate, by utilizing shared knowledge of agents’ issues and connection rating values. If the arbitrator “sees” no problem, the agents follow a predetermined default order. This scheme allows DFI to take an approach to negotiation that uses aspects of both centralized control as well as agent based control over negotiation. This differs from systems which contain fully autonomous agent control schemes where agents are totally on there own to determine what to do next[l7, 181 and centrally controlled systems where one superagent maintains total control over all other agents[l9].

5 The Knowledge-Based Negotiation Model

The knowledge-based negotiation approach used in the DFI system requires that agents must be able to communicate the problem, reason from their own and other agent’s perspectives, and finally generate a so- lution. For agents to be able to contemplate the ef- fects of their proposals on others, they need to share a common background of the problem domain. In addi-

5.1 K B - N ego t iat ion Know ledge Require- ment s

This section details the types of knowledge required by a knowledge-based negotiation system (KBNS). In a KBNS, three types of knowledge are maintained. The first type of knowledge is shared knowledge which is accessible to all agents including the independent arbitrator agent. The shared knowledge includes do- main object knowledge as well as knowledge about the history of the negotiation dialog. Object knowledge includes such things as the names of objects known to all agents in the domain and is predefined and static in the system. In DFI, this includes a list of con- nections labels (connection proposals), a list of con- nection component pieces (proposal attributes) and a list of agent issue labels (aspects of proposal at- tributes). The negotiation history includes all agent proposals, rejections, and counterproposals made by the agents and is dynamically generated. The second type of knowledge maintained by the DFI system is unique agent knowledge. In DFI, this includes special- ized knowledge of construction processes maintained by each agent which is also statistically defined in the system.

The third form of knowledge in the DFI sys- tem includes knowledge maintained by the arbitra- tor. The arbitrator agent maintains both local unique agent knowledge related to mediation and arbitration strategies as well as shared agent knowledge including object knowledge, agent issue labels and the negoti- ation dialog. In addition to this shared knowledge, the arbitrator also maintains each agent’s shared per- spective of domain objects. The arbitrator maintains this knowledge in a relational network of shareable agent perspectives. An example of a network of interlinked agent perspectives is seen in Figure 11.

113

Figure 11: Example

The figure contains three

Relational Network

agent nodes each with its own local issue nodes (grey block of issues), linked by agent issue links. The two remaining types of nodes in the figure are the domain aspects and the domain ob- ject nodes (boxes with rounded corners). Each agent node is linked to a domain object by means of a com- monly accepted domain issue link iSUCh as expensei which also passes through a domain aspect node. This linking of nodes comprises a shareable agent per- spective in the relational network. When two unique agent perspectives are linked to the same domain ob- ject, the results is an interagent issue relation. This is seen in the figure as a heavy black line. The arbitrator uses the interagent issue relations to aid in selecting probable alternatives for agent’s to consider when they find themselves in a “deadlock” situation and can not develop their own proposals. In the DFI system, this network is called the DFI Relational Net- work.

5.2 Shareable Agent Perspectives

An agent perspective includes a combination of agent issues and other domain factors that are re- lated to an object being evaluated given the context of the evaluation. An example of an agent perspective for a design agent in the DFI system would include one of the designer’s agent issues of strength, stiffness, versatility or reliability related to one of the connec- tions known by the design agent. An agent perspec- tive is different from the concept of object perspective as described by Bobrow in the KRL language [20].

Object perspectives usually include the selection of specific object attributes that are inherited from an object taxonomy depending on the focus of the per- spective. Instead, agent perspectives are a separate knowledge structure orthogonal to the object taxon- omy, much like the concept of domain perspective pre- sented in work by McCoy [21]. Domain perspectives include salience values to indicate which perspectives are highlighted and which are suppressed.

Two agent perspectives can be combined with shared knowledge of domain aspects and domain is- sues to produce relational “links’’ between issues of the two agents. These interagent issue relations make up a network of relationships which are main- tained by the arbitrator agent. Because all agent is- sues are made available t o a third party arbitrator in the form of agent perspectives and interagent issue re- lations, agent perspectives can be considered “share- able.” Agents can query the arbitrator to check for the existence of a particular interagent issue relation. Once an agent obtains a interagent issue relation be- tween itself and another agent, it can use this newly acquired knowledge and combine it with any past pro- posals found in negotiation dialog to develop a coun- terproposal which might be more acceptable than if the agent had not had this knowledge available.

5.2.1 An Agent Perspective

Each agent’s perspective of a given domain object is composed of the agent’s local assue, a domaan zssue lank, and a domazn aspect, as seen previously in Fig- ure 11. These three elements make up a context in which the agent views a domain object ( that agent’s perspective). The first element, the agent’s local zs- sue, consists of ordinal values which allow the agent to rank the issue’s level of desirability. The second element, the domazn zssue Eznk, links the agent’s lo- cal zssue to a shared domazn aspect and thus pro- vides a way of relating (grouping) common domain concepts (domain issues) among the agents. Domain issues could be used to effect the outcome of the ne- gotiation by causing each agent to focus on a shared issue during its proposal cycle(. Domain issues can also be used to develop general explanations that are understood by all agents. The third component of a “shareable” agent perspective is the domazn aspect and is described below.

9To some extent, a more limited approach is used initially in the DFI system where one agent’s local issue (referred to as the h e y issue) is used to focus all other agents’ proposals. This is described in Section 4.4.

114

5.2.2 Domain A s p e c t s

Domain a s p e c t s are similar in concept to domain perspectives as described in work by McCoy on cor- recting dialog misconceptions by use of agent perspec- tives [21]. Both DFI’s domain aspects and McCoy’s domain perspectives are similar in their four major characteristics. Both concepts include salience values to indicate which perspectives are to be highlighted and which are suppressed over the entire domain of objects. Second, both are separate da ta structures that are orthogonal to the system’s object generaliza- tion hierarchy. This differs from the concept of object perspective described in the KRL language which in- volves highlighting certain attributes of a single ob- ject. Third, any number of domain objects can be viewed from the same domain aspect or perspective. Some domain aspects might not be applicable (make sense) to every domain object, but this is acceptable considering that in real life the same thing happens when one tries to apply a particular viewpoint to all possible objects in the world. The fourth major char- acteristic of McCoy’s domain perspectives states that only one domain perspective is active at any one time during an evaluation. In the DFI system, one do- main aspect is active for any given agent a t one time. During an evaluation, two agents might be viewing the same domain object (connection) from their own agent perspective and hence unique domain aspect. Therefore, an object can be considered from several viewpoints at one time in DFI.

5.2.3 Interagent I s s u e Relations

An example of an interagent i ssue relation which links two agent’s unique perspectives to a common do- main object is shown in Figure 12. The domain issue which links the two agents’ perspectives during a ne- gotiation cycle can be different and an interagent issue link will still exist between the agents. In the example, a design agent with an issue of strength and an erector agent with an issue of erection cost are linked to the endplate connection via their own unique agent per- spectives. The designer’s perspective on the endplate connection is seen through the functional domain. as- pect based on the domain issue of performance. The erector agent views the endplate connection through

-.... J

Agcnt Issue: Slrength (+)

Desiener’s Persuective (DBSlGNfiP1 Erector’s Perspective D o w n Ins=: Expense D m n Aspccr: Fartenerr Rt.asoo: Field Operations

D o m n Issue: Performance

Reason: User Selslcd

[“““;“I

Agent Issue. Erection Cost (.)

Figure 12: Example Interagent Issue Relation

Table 3: A Designer/Erector Interagent Issue Rela- tion

Agent : Designer Agent : Rrcotor I s r u e : Erection Cost Issue : Strength

Reason : Detail Material Re-son : Field Operations

on the detracting issue of erection cost (noted as a “- ” in the figure) given the domain issue of expense. Attached to each agent’s issue is a reason describing why that agent considers the issue as supporting or detracting from the agent’s goal. The supportive rea- son for the strength issue of the endplate connection from the designer’s perspective is because of the detail material used in the connection (the endplate detail material is strong). From the erector’s viewpoint, the endplate connection is costly (erection cost) because of the field operations required to assemble the con- nection in the field (alignment problems for bolting the endplate).

the fastener domain aspect with a domain issue of ex- pense. From the designer’s viewpoint, the endplate connection is favorable based on the supporting issue of strength (noted as a “+” in the figure) given the domain issue of performance. From the erector’s per- spective, the endplate connection is undesirable based

6 Summary and Future Work

In summary, this paper tried to present the need for Knowledge-Based Negotiation Systems (KBNS) as

115

part of a collaborative design system. As users wish t o utilize knowledge from many knowledge sources t o develop “better” or more complete answers to their queries, they will require systems that can zn- tegrate diverse viewpoints. The incremental negotia- tion scheme called knowledge-based negotiation presented here is one potential approach to solving this problem. This scheme allows agents which share a common background to behave both cooperatively and competitively during negotiation, thus providing a form of critical evaluation of the user’s query, This is accomplished by use of a shared knowledge repre- sentation called shareable agent perspectives11 A grouping of two of more shareable agent perspectives results in an interagent issue relation that relates agents to domain objects by means of domain as- pects. A network of these relations is maintained by a third party arbatrator agent who uses them during its mediation phase of conflict resolution. The arbitrator selects a n interagent issue relation based on a review of the negotiation dialog for issues that exist between the conflicting agents. The arbitrator suggests the interagent issue relation to the agents in hope that they will consider it as a viable alternative. If this fails, the arbitrator enters its arbitration phase of con- flict resolution which includes such techniques as set- ting time limits and searching the negotiation dialog for other proposal alternatives that have similar ad- vantages and disadvantages for each of the conflicting agents. The resulting research is demonstrated as an implementation within a knowledge-based tool called the Designer Fabricator Interpreter (DFI) Sys- tem which structural design engineers may use to evaluate preliminary designs from the additional per- spectives of fabrication and field erection in order to avoid potential “downstream” problems, thus reduc- ing costs and saving time.

Current and future work includes the reimplemen- tation of the knowledge-based negotiation scheme in the DFI system into a more generic tool for use in other application domains. Currently, work is being done to modify the DFI system to be used in a con- current engineering setting where the system will act as a coordinator of cooperative problem solving be- tween human and computer agents. Even though it is believed that a sequential pair-wise interaction be- tween agents in greatest disagreement is best, addi- tional agent interaction scenarios are being investi- gated. As the system is extended to more than 3 agents, as in the case of the concurrent engineering

1 1 A comprehensive overview of shareable agent perspectives can be found in [22].

task (involves many functions such as marketing, sys- tenis engineering, software engineering, manufactur- ing, etc.), the problems of pair-wise agent issue inter- action (and their potential reviews by the arbitrator) will be examined. Also t o be examined is the issue of agent behavior (competitive vs. cooperative mode) during negotiation. As KBNS architectures are ap- plied to multiagent application domains such as in col- laborative enterprises, more will be learned about the types of knowledge which compose agent perspectives and how to best share that knowledge among others in the distributed cooperative problem solving (DCPS) system. The result should be more “thoughtful” an- swers t o user queries through the coordinated inter- action of many diverse knowledge sources of which KBNS architectures will be an integral part.

Acknowledgments

Special thanks to Mr. Marcello Barone who devel- oped the construction domain relations used in the DFI Relational Network.

References

[l] J . Bowen and D. Bahler. Supportzng Multiple Perspectzves: A Constraznt-Based Approach to Concuwent Engzneerzng, pages 85-96. Kluwer Academic Publishers, 101 Philip Drive, Nrowell, MA 02061, U.S.A, 1992.

S. Konda R. Coyne A. Westerberg Y. Reich S. Levy, E. Subrahmanian. An overview of the n-dim environment. Edrc 05-65-93, Engineering Design Research Center, 1993.

G.W. Simpson and J.K. Cochran. An analytic approach to prioritizing construction projects. Gzvzl Engzneerzng Systems, 4(4):185-190, 1987.

Marcello Barone. Designer fabricator interpreter: A step towards computer integrated construc- tion. Master’s thesis, Lehigh University, 1990.

Dean G . Pruitt. Negotzatzon Behavzor. Academic Press, Inc., New York, NY, 1981.

H . Penny Nii. Blackboard systems, part 2. A I Magarzne, 7(3):82-106, 1986.

L.S. Baum. Recent Developments zn Blackboard Frameworks, pages 303-308. Academic Press,

116

Inc., 1250 Sixth Street, San Diego, CA 92101, 1989.

[8] Alan H. Bond. The Cooperation of Ezperts in Engineering Design, pages 462-486. Pit- man/Morgan Kaufmann, London, 1989.

[9] Robert R. Tenney and Jr . Sandell, Nils R. Strate- gies for distributed decisionmaking. IEEE Trans- actions on Systems, Man and Cybernetics, SMC- 11(8):527-538, August 1981.

[lo] James F. Allen and C. Raymond Perrault. An- alyzing intention in utterances. Artificial Intelli- gence, 15(3):441-458, 1980.

[ll] P. Cohen and R. Perrault. Elements of a plan- based theory of speech acts. Cognitive Science, 3:177-212, 1987.

[12] Bertram C. Bruce. Belief systems and language understanding. Bbn report no. 2973, ai report no. 21, Bolt Beranek and Newman, Inc., 1975.

[13] Katia P. Sycara. Argumentation: Planning other agent’s plans. In Proceedings of the Eleventh In- ternationaz Joint Conference on Artificial Intelli- gence, pages 517-523, Detroit, MI, August 1989. IJCAI, Morgan Kaufmann Publishers, Inc.

[14] K.J. Werkman. Multiple Agent Cooperatave De- sign Evaluation Using Negotiation, pages 85-96. Kluwer Academic Publishers, 101 Philip Drive, Nrowell, MA 02061, U.S.A, 1992b.

[15] K.J. Werkman. Using Negotiation and Coordi- nation i n Multiagent Intelligent Cooperative In- formation Systems. Springer-Verlag, NY, NY, 1992c.

[16] Daniel D. Corkill and Victor R. Lesser. The use of meta-level control for coordination in a dis- tributed problem solving network. In Proceed- ings of the 8th International Joint Conference on Artificial Intelligence, pages 748-756. IJCAI, IJ- CAI, 1983.

[17] Meyer R. Conry, S. and V. Lesser. Multi- stage negotiation in distributed planning. Tech- nical Report COINS TR86-87, University of Mas- sachuset t s , 1986.

[19] McArthur D. Cammarata S. Narian S. Steeb, R. and W. Giarla. Distributed problem solving for air fleet control: Framework and implemen- tation. Technical Report N-2139-ARPA, Rand Note, 1984.

[20] D.G. Bobrow and T. Winograd. An overview of krl: A knowledge representation language. Cog- nitive Science, 1:3-46, 1977.

[all Kathleen F. McCoy. Generating context- sensative responses to object-related misconcep- t,ions. Artzficial Intelligence, 41:157-195, 1990.

[22] Keith James Werkman. Multiagent Cooperative Problem Solving Through Negotatzon and Per- spective Sharing. PhD thesis, Lehigh University, 1990.

[18] Randall Davis and Reid G . Smith. Negotiation as a metaphor for distributed problem solving. Artificial Intelligence, 20:63-109, 1983.

117