CONCENSUS: multi-party negotiation support for conflict resolution in concurrent engineering design

5
CONCENSUS: multi-party negotiation support for conflict resolution in concurrent engineering design SIMON COOPER and A. TALEB-BENDIAB Department of Mechanical Engineering, Design and Manufacture, The Manchester Metropolitan University, Manchester, UK Received February and accepted October 1997 Advances in telematics have led many manufacturing companies in particular to explore the adoption of groupware technology to improve communication between team members. However, complex activities such as conflict resolution are still predominantly facilitated through face-to-face negotiation meetings. Intelligent software agents technology is being applied to support computer-mediated conflict resolution activities, such as information search and retrieval, recording negotiation process history and task allocation – whilst the creative negotiation activities such as generating new solutions, preventing and detecting conflicts are still left to the human experts. This paper describes the development of a framework for the support of multi-party negotiation for multi-agent systems, which will be introduced through a general overview of the requirements of multi-agent negotiation. Finally, the current architecture of the developed prototype for a CONCurrent Engineering Negoti- ation SUpport System (CONCENSUS) is presented. Ó 1998 Chapman & Hall Keywords: Negotiation, concurrent engineering, conflict resolution 1. Introduction The last decade has seen the emergence of a new work practice, where manufacturing companies in particular are developing their new products/services in partnership with their customers, suppliers and competitors. This is to fur- ther reduce lead-time, cost and project failure risk. The timely advances in telematics have led many manufacturing companies in particular to explore the adoption of group- ware technology such as; electronic mail, file sharing and conferencing tools to improve communication between team members. However, complex activities such as con- flict resolution are still predominantly facilitated through face-to-face negotiation meetings, to enable new product development engineers to participate in an iterative process of exchanging proposals, rejections, supporting arguments and compromise until a consensus is reached. Following a notable success in the provision of infra- structures for conflict resolution and understanding social aspects of conflict resolution, the Computer Supported Collaborative Work (CSCW) community is now investi- gating the application of intelligent software agents tech- nology to support negotiation (Jones and Edmonds, 1994). However, many of these projects focus primarily on the automation of routine activities such as information search and retrieval to support conflict resolution, recording ne- gotiation process history and task allocation – whilst the creative negotiation activities such as generating new so- lutions, preventing and detecting conflicts are still left to the human experts. This paper will describe the development of a framework for the support of multi-party negotiation for multi-agent systems. A brief review of research work in multi-agent negotiation will be followed by the requirements for the framework, and a description of the developed system prototype for a CONCurrent Engineering Negotiation SUpport System (CONCENSUS). 2. Background In both the fields of Group Decision and Negotiation Support Systems (GDNSS) and Distributed Artificial Intelligence (DAI) many works have focused on the support of negotiation activities to resolve conflicts between human and/or software agents. Two general Journal of Intelligent Manufacturing (1998) 9, 155–159 0956-5515 Ó 1998 Chapman & Hall

Transcript of CONCENSUS: multi-party negotiation support for conflict resolution in concurrent engineering design

Page 1: CONCENSUS: multi-party negotiation support for conflict resolution in concurrent engineering design

CONCENSUS: multi-party negotiation

support for con¯ict resolution in concurrent

engineering design

SIMON COOPER and A. TALEB-BENDIAB

Department of Mechanical Engineering, Design and Manufacture, The ManchesterMetropolitan University, Manchester, UK

Received February and accepted October 1997

Advances in telematics have led many manufacturing companies in particular to explore theadoption of groupware technology to improve communication between team members.However, complex activities such as con¯ict resolution are still predominantly facilitatedthrough face-to-face negotiation meetings. Intelligent software agents technology is being

applied to support computer-mediated con¯ict resolution activities, such as informationsearch and retrieval, recording negotiation process history and task allocation ± whilst thecreative negotiation activities such as generating new solutions, preventing and detecting

con¯icts are still left to the human experts. This paper describes the development of aframework for the support of multi-party negotiation for multi-agent systems, which will beintroduced through a general overview of the requirements of multi-agent negotiation. Finally,

the current architecture of the developed prototype for a CONCurrent Engineering Negoti-ation SUpport System (CONCENSUS) is presented. Ó 1998 Chapman & Hall

Keywords: Negotiation, concurrent engineering, con¯ict resolution

1. Introduction

The last decade has seen the emergence of a new workpractice, where manufacturing companies in particular aredeveloping their new products/services in partnership withtheir customers, suppliers and competitors. This is to fur-ther reduce lead-time, cost and project failure risk. Thetimely advances in telematics have led many manufacturingcompanies in particular to explore the adoption of group-ware technology such as; electronic mail, ®le sharing andconferencing tools to improve communication betweenteam members. However, complex activities such as con-¯ict resolution are still predominantly facilitated throughface-to-face negotiation meetings, to enable new productdevelopment engineers to participate in an iterative processof exchanging proposals, rejections, supporting argumentsand compromise until a consensus is reached.Following a notable success in the provision of infra-

structures for con¯ict resolution and understanding socialaspects of con¯ict resolution, the Computer SupportedCollaborative Work (CSCW) community is now investi-gating the application of intelligent software agents tech-nology to support negotiation (Jones and Edmonds, 1994).

However, many of these projects focus primarily on theautomation of routine activities such as information searchand retrieval to support con¯ict resolution, recording ne-gotiation process history and task allocation ± whilst thecreative negotiation activities such as generating new so-lutions, preventing and detecting con¯icts are still left tothe human experts.This paper will describe the development of a framework

for the support of multi-party negotiation for multi-agentsystems. A brief review of research work in multi-agentnegotiation will be followed by the requirements for theframework, and a description of the developed systemprototype for a CONCurrent Engineering NegotiationSUpport System (CONCENSUS).

2. Background

In both the ®elds of Group Decision and NegotiationSupport Systems (GDNSS) and Distributed Arti®cialIntelligence (DAI) many works have focused on thesupport of negotiation activities to resolve con¯ictsbetween human and/or software agents. Two general

Journal of Intelligent Manufacturing (1998) 9, 155±159

0956-5515 Ó 1998 Chapman & Hall

Page 2: CONCENSUS: multi-party negotiation support for conflict resolution in concurrent engineering design

models have been employed to express and resolve con¯ictproblems:

(1) Mathematical model-based systems ± which are gen-erally based on game theory and economic behaviour (VonNeumann and Morgenstein, 1964), where a vast majorityof developed systems have utilized quantitative models,such as multi-criteria decision making (Bui and Jarke,1986; Hwang and Lin, 1987), con¯ict analysis (Fraser andHipel, 1981), group decision theory (Schocken and Hum-mel, 1994), multi-objective linear programming (Sycara,1985) and fuzzy arithmetic (Peri, 1994) to search for ane�cient solution based upon the negotiation criteria andpreferences provided from the users. Of the systems builtupon this approach, Co-Op (Bui and Jarke, 1986) is one ofthe few that supports cooperative negotiation;(2) Heuristics model-based systems ± which are developed

using AI techniques to model the strategic behaviour of thenegotiating parties. For instance RUNE (Jellasi and For-oughi, 1989) and Negoplan systems (Matwin et al., 1989)use knowledge-based systems to model the impact of de-cisions within competitive negotiations, and model andsimulate possible negotiating positions. Sycara (1991) hasused a case-based reasoning technique in conjunction withmulti-attribute utility theory to assess the negotiationproblem and compares it to stored similar past cases, fromwhich a solution to the considered con¯ict can be adapted.Klein (1991) in his attempt to abstract out negotiationstrategic knowledge from domain knowledge, has identi®edgeneric classes of negotiation strategies, which are consid-ered as an important concept for the development of amulti-agent negotiation framework. Lander and Lesser(1992) have been among the few who recognize and addressthe need for a computational distributed control model,which is the essence of multi-agent negotiation. Their de-veloped `negotiated search' algorithm provides a genericsearch method that explicitly recognizes and exploits searchactivity between agents, where con¯icts are used as a sourceof control information for the search, but ultimately thecontrol is provided through democratic decisions made bythe agents themselves.

The authors believe that a high-level control mechanismfor multi-party negotiation has not yet been fully ad-dressed. In many situations, the best (and in some cases,perhaps the only) solution to a con¯ict may itself createadditional con¯icts, which also have to be resolved before a®nal and complete solution can be agreed upon. Such asituation poses the important and di�cult decision as towhether it is best to adopt such a solution (and createfurther con¯icts) or accept what may have initially seemedan inferior solution but creates no further con¯icts. Per-haps more importantly, these additional con¯icts may in-volve the interests of other agents not already in thenegotiation team. It can be seen that without control, asimple scenario of one con¯ict between two agents can

quickly develop into a situation requiring the involvementof many agents to resolve complex multiple con¯icts.Furthermore, within a negotiation session, one con¯ict

resolution strategy may be abandoned in favour of an-other, which may also require the reformation of the ne-gotiation team. In domains such as new productdevelopment, where the agents' activities are likely to begeographically and temporally dispersed, it may be bothimpractical and too costly to wait for some time when it isconvenient for another interested party to join the negoti-ation, just so that a potentially (fruitless) direction can beinvestigated. Thus more often than not, it is likely that if itis at all possible, a solution will be adopted which does notcreate any further con¯icts with other parties; this ap-proach may possibly produce a result quickly and with theleast e�ort, but it is also likely to miss more optimal so-lutions.In developing multi-agent negotiation frameworks a

high-level control mechanism is required that can bothprevent the search process from becoming too chaotic, yetallows the ¯exibility to exploit di�erent strategies when theopportunities or needs arise.

3. Requirements of negotiation supportfor multi-agent systems

In developing systems to support negotiation within con-current design there are seven fundamental areas whichrequire consideration, including:

(1) Con¯ict detection ± to consider means of limiting anddetecting their occurrence depending on the method usedto represent design constraints, goals, design intents anddesign dependencies;(2) Con¯ict identi®cation/strategy selection ± to identify a

given con¯ict's type, in order to enable the selection ofappropriate strategies to be used for its resolution. Also,this process includes making decisions concerning whichattributes could be changed to a�ect particular strategiesand which agents should be responsible for making thesechanges;(3) Negotiation team formation/reformation ± to identify

and form the team of agents required to participate in theselected resolution strategy of the identi®ed con¯icts.Similarly, as the negotiation progresses and existing con-¯icts are resolved or further con¯icts are created the ne-gotiation team may need to be dynamically reformed;(4) Negotiation management ± to conduct and control a

collaborative/competitive negotiation session, which oftenrequires the presence of a mediating impartial senior au-thority or `chair'. The chair is presented with many roles inthe negotiation process, but is ultimately responsible forthe choice of when and what all the actions are to be taken.These choices include the selection of con¯ict resolutionstrategies, the decision to stop and/or refocus a search, the

156 Cooper and Taleb-Bendiab

Page 3: CONCENSUS: multi-party negotiation support for conflict resolution in concurrent engineering design

change of problem solving paradigms, and reformation ofthe negotiation team;(5) Negotiation monitor ± to collect and store informa-

tion that is needed to support and guide the decisions madewithin the negotiation management;(6) Solution generation ± to use selected strategies for a

group of agents to apply their own domain knowledge toprovide an `optimal' solution to the considered con¯ict;(7) Solution evaluation ± to facilitate the rating of po-

tential solutions based on a given evaluation mechanism,using a set of group agreed evaluation criteria.

4. CONCENSUS architecture

In recognition of the requirements for systems to supportnegotiation (Section 3), a system prototype has been de-veloped (Fig. 1). This section will present a very brief de-scription of the implemented system prototype. Full detailsof the prototype, and the proposed high-level controlmechanism for multi-party negotiation is out of the scopeof this paper and can be found elsewhere (Cooper, 1997).The CONCENSUS system prototype is structured into a

number of modules (agents):

4.1. Design model

This is structured into a constraint network and a cluster-dependency network. The constraint network is used tomodel the relationships between the physical attributes,such as length, weight and material type. The cluster-de-pendency model is used to automatically create andmaintain the interfaces between design clusters. A designcluster can be any separable group of design attributeswhich relate to a single component. Both constraints anddependency networks are used as a basis for design productconsistency maintenance.

4.2. Design agents

These are multi-agent design systems involved in a con¯ictnegotiation. The negotiation team formation (structure) ishere de®ned through use of design clusters.

4.3. Design change evaluation

This combines the functionality of the cluster-dependencynetwork with constraint propagation to assess the e�ects ofdesign changes. Proposed changes are assessed and anyresulting con¯icts are returned at the required level of ab-straction that is how design agents, design clusters or de-sign attributes are e�ected.

4.4. Decision tree

This keeps a record of decisions made, where each decisionnode in the tree represents a list of the current con¯icts andcorresponding proposals for that point. Each arc in the treerepresents a proposal which connects two decision pointsand can contain a reference to a number of design changes.The decision tree has been extended to provide the nego-tiation process transparency, and human user control ofCONCENSUS system, such as:

(1) Backtracking and undoing the changes that theyinitiated;

(2) Simultaneous exploration of multiple solution searchpaths.

4.5. Proposal evaluation

This evaluates proposals made to give the negotiators aquantitative measure of its quality. Proposal evaluationoccurs at two levels:

(1) The design changes that make up the proposals arechecked to see if they create any further con¯icts, and if so,they are added to the con¯ict list in the decision pointwhich the proposal leads to;

(2) The proposal is evaluated using global and localutility functions provided by the design agents. This allowsproposals to be compared and contrasted rationally. Inaddition to the global and local utility measures a global/local o�set rating is also produced. The purpose of theo�set rating is to aid the negotiators in identifying pro-posals and solutions that are best from both global andlocal perspectives; a proposal which is considered goodfrom a global perspective can be considered to be better if itis also considered to be good from all or more of theagents' local perspectives.

4.6. Proposal generation

This makes a procedural call to either the genetic algo-rithm-based solution generator or the solution builderFig. 1. CONCENSUS architecture.

CONCENSUS: multi-party negotiation support for con¯ict resolution 157

Page 4: CONCENSUS: multi-party negotiation support for conflict resolution in concurrent engineering design

interface. The genetic algorithm (GA) search mechanismprovides an automated search method using ®tness func-tion combining a design constraint violation measure withglobal and agents' local utility functions to guide it towardsoptimal con¯ict solutions.

4.7. Solution builder interface

This aids human designers in making use of the negotiationframework. Initially, CONCENSUS was developed so thatthe control of the negotiation process was provided solelyby a human user ± much in the same way as it is in atraditional chaired negotiation held directly between hu-mans. In a con¯ict situation, all design agents in the ne-gotiation team use their own computer terminals tocommunicate their proposals and evaluations with eachother using the solution builder interface (Fig. 2) to thenegotiation framework. A graphical view of the decisiontree provides the design agents with a group shared view ofthe con¯ict situation. Each agent independently presentstheir proposals to the framework and they are added to thedecision tree. Feedback is then provided as each agent'sview of the decision tree is updated to display the con¯ictinformation and global/local utility evaluations for the newdecision points the new proposals lead to.This iterative process of exchanging proposals and feed-

back leads to a greater shared understanding of the problemand leads to the development of proposals that result inmutually agreeable/bene®cial con¯ict solutions. The solu-tion builder also provides an interface to the GA searchmechanism which the design agents can use to automati-cally generate proposals to be added to the decision tree.

4.8. High-level control mechanism

This selects a design agent as the negotiation manager andas such is the only member of the negotiation team who has

the authority to actually execute control actions (i.e. movethe current negotiation position on the decision tree toanother). The information provided by the system (pro-posal evaluations, state of con¯icts, etc.) provides the ne-gotiation manager with the support needed to make thecontrol decisions, such as:

(1) Accepting a proposal;(2) Running a GA search;(3) Backtracking to another solution search path.

Currently, CONCENSUS is being modi®ed to incorporatea high-level control mechanism which allows the respon-sibility for making control decisions to be shared betweenthe human negotiation manager and a computer-basedplanning system. This high-level control mechanism allowsthe negotiation manager to specify when and how thecomputer-based planner should operate to assist in man-aging the negotiation.The control pro®le window of the CONCENSUS system

(Fig. 3) allows the negotiation manager to input this de-sired behaviour, which is speci®ed using a script-basedlanguage to state a set of control gates and preferences. Acontrol gate consists of a matched pair of expected stateand desired action, for example, when two complete con-¯ict solutions have been found return the control to thehuman negotiation manager.Preferences allow the behaviour of the system to be more

speci®cally controlled, for example, an exclusion preferencemay be to not create any further con¯icts which wouldrequire the reformation of the negotiation team to includea particular (or any new) agent. A set of control gates andpreferences creates a control pro®le, which speci®es thedesired behaviour and level of automation to be providedby the negotiation framework for a speci®c negotiationscenario. Control pro®les can be saved and subsequently bere-used for other con¯ict problems. By using di�erent levelsof abstraction to specify the control gates and preferences,it is believed that it is possible to build a library of generic

Fig. 2. Solution builder interface. Fig. 3. CONCENSUS control pro®le window.

158 Cooper and Taleb-Bendiab

Page 5: CONCENSUS: multi-party negotiation support for conflict resolution in concurrent engineering design

control pro®les, which can be easily modi®ed and extendedto support many speci®c con¯ict situations.

5. Conclusions

A brief discussion of the general requirements of a nego-tiation framework has been presented that models thecomplex, dynamic nature of negotiation between multi-agent systems. This framework has been used to implementa prototype system ± CONCENSUS. The later supportsdesign agents in negotiating solutions to engineering con-¯icts. The prototype has been tested using an o�ce furni-ture design case study (Cooper, 1997).A proposed high-level control mechanism is being de-

veloped to enable CONCENSUS to share (switch) controlresponsibility between human facilitated and computercontrolled modes. Negotiation strategies are used to gen-erate a skeleton of a control pro®le, which can be improvedby the system user. Control pro®les allow the behaviour ofthe computer-controlled mode to be speci®ed, modi®edand re-used for di�erent con¯ict situations.The current CONCENSUS system prototype has been

developed using Microsoft Visual C++ development andadheres to our proposed Virtual Team system architecture(Williams and Bendiab, 1997). The current CONCENSUSprototype works with logically distributed negotiatingagents. Work is underway to develop an infrastructure fordynamic con®guration for intelligent software agents,which will be used to extend and test the CONCENSUSprototype in a distributed cross-platform environment(Williams and Bendiab, 1997).

6. References

Bui, T. X. and Jarke, M. (1986) Communications design for co-op: a group decision support system. ACM Transactions on

O�ce Information Systems, 4(2), 81±83.

Cooper, S. J. (1997) Http://www.csce.mmu.ac.uk/�dt9daa4/con-cencus.html.

Fraser, N. M. and Hipel, K. W. (1981) Computer assistance inlabor-management negotiations. Interfaces, 11(2), 22±29.

Hwang and Lin (1987) Group Decision Making Under MultipleCriteria, Springer-Verlag, Berlin.

Jellasi, M. T. and Foroughi, A. (1989) Negotiation support sys-tems: an overview of design issues and existing software.Decision Support Systems (Special Issue on Decision Support

Systems) 5, 167±181.Jones, R. and Edmonds, E. (1994) CSCW and Arti®cial Intelli-

gence, Springer-Verlag, London.

Klein, M. (1991) Supporting con¯ict resolution in cooperativedesign systems. IEEE Transactions on Systems Man, andCybernetics, 21(6), 1379±1389.

Lander, S. and Lesser, V. R. (1992) Customizing distributed searchamong agents with heterogeneous knowledge, in Proceedingsof the First International Conference on Information andKnowledge Management, Baltimore, MD, pp. 335±344.

Matwin, S., Szpakowicx, S., Koperczak, Z., Kersten, G. E. andMichalowski, G. E. (1989) Negoplan: an expert system shellfor negotiation support. IEEE Expert, Winter, 50±61.

Peri, L. H. (1994) Application of fuzzy arithmetic in group deci-sion and negotiations involving multicriteria and con¯ictingpriorities, in Proceedings of the Twenty-Seventh Annual Ha-

waii International Conference on System Sciences, pp. 291±300.

Schocken, S. and Hummel, R. A. (1994) Compromise reachingmechanisms in multi-group/multi-player negotiation pro-

cesses, in Proceedings of the Twenty-Seventh Annual HawaiiInternational Conference on System Sciences, pp. 281±290.

Sycara, K. (1985) AI Planning, Kerste.

Sycara, K. P. (1991) Cooperative negotiation in concurrent en-gineering design, in Computer-Aided Cooperative ProductDevelopment, Springer-Verlag, Berlin, pp. 269±297.

Von Neumann, J. and Morgenstein, O. (1964) Theory of Gamesand Economic Behavior, Princeton University Press.

Williams, M. J. and Bendiab, A. T. (1997) A toolset for archi-

tecture independent, re-con®gurable multi-agent systems, inProceedings of the First International Workshop on MobileAgents (MA97), Rothermel, K. and Popescu-Zeletin (eds),Springer-Verlag. Berlin, pp. 210±222.

CONCENSUS: multi-party negotiation support for con¯ict resolution 159