collaborative design of structures using intelligent agents

Ž .Automation in Construction 11 2002 89–103www.elsevier.comrlocaterautcon

Collaborative design of structures using intelligent agents

C.J. Anumba a,), O.O. Ugwu a, L. Newnham b, A. Thorpe a

a Centre for InnoÕatiÕe Construction Engineering, Loughborough UniÕersity, Loughborough LE11 3TU, UKb Touch Clarity Ltd, London W1X 7DB, UK

Accepted 6 April 2001

Abstract

The construction industry has a long tradition of collaborative working between the members of a construction projectteam. At the design stage, this has traditionally been based on physical meetings between representatives of the principaldesign disciplines. To aid these meetings, the information and communications technologies that are currently available havebeen utilised. These have yielded some success but are hampered by the problems posed by the use of heterogeneoussoftware tools and the lack of effective collaboration tools that are necessary to collapse the time and distance constraints,within which increasingly global design teams work. In particular, there are very few tools available to support distributedasynchronous collaboration. Distributed artificial intelligence, which is commonly implemented in the form of intelligentagents, offers considerable potential for the development of such tools. This paper examines some of the issues associatedwith the use of distributed artificial intelligence systems within the construction industry. It describes the potential for theuse of agent technology in collaborative design and then goes on to present the key features of an agent-based system for thecollaborative design of portal frame structures. An example is presented to demonstrate the working and benefits of theprototype system, which makes a significant contribution by allowing for peer to peer negotiation between the design agents.q 2002 Elsevier Science B.V. All rights reserved.

Keywords: Intelligent agents; Distributed AI; Collaborative design; Portal frame structures

1. Introduction

Building design often requires collaborative work-ing between members of a construction project team.A typical project involves a wide range of disparateprofessionals—clients, architects, structural engi-neers, building services engineers, quantity survey-ors, contractors, materials suppliers, etc.—workingtogether for a relatively short period on the design

) Corresponding author. Tel.: q44-1509-222-615; fax: q44-1509-223-981.

Ž .E-mail address: [email protected] C.J. Anumba .

and construction of a facility. In many cases, theparticipants are geographically distributed, makingthe need for effective information and communica-tion technologies acute. This is compounded by theproblems posed by the use of heterogeneous soft-ware tools within the industry. Furthermore, theparties involved in a building project often adopt asequential approach to the design of the project, suchthat downstream participants have little or no influ-

Ž .ence at the earlier and more crucial design stages.For example, the architectural design is usually sub-stantially complete before the start of structural de-sign, which is normally at an advanced stage before

Ž .the mechanical and electrical M&E services engi-

0926-5805r02r$ - see front matter q 2002 Elsevier Science B.V. All rights reserved.Ž .PII: S0926-5805 01 00055-3

( )C.J. Anumba et al.rAutomation in Construction 11 2002 89–10390

neers begin their design. In many cases, the design isfinished before a contractor is appointed, thus effec-tively separating the integration of design and con-struction considerations. The problems associatedwith this ‘over the wall’ approach to project delivery

w xare well documented 1 and will not be restatedhere.

Increasingly, the benefits of concurrent and col-laborative working within the building design en-

w xvironment are now being recognised 2–6 , withproject teams being actively encouraged to worktogether more closely and to exchange project infor-mation in a more structured way. Concurrent engi-neering in construction involves ‘an attempt to opti-mise the design of a project and its constructionprocess to achieve reduced lead times, and improvedquality and cost by the integration of design, fabrica-tion, construction and erection activities, and bymaximising concurrency and collaboration in work-

w xing practices’ 6 . This need for improved collabora-tive working in the construction industry has beenhighlighted in a number of recent government-ini-tiated reports and publications such as: The Latham

w xReport 7 , The Technology Foresight Report onw x ŽConstruction 8 and the DoErBT Report Construct

. w xIT—Bridging the Gap 9 .For effective collaborative working between the

parties in a construction project team, it is essentialthat enabling information and communications tech-nologies are available. The additional problems posed

Ž .by the use of heterogeneous legacy software toolsare well known and need to be overcome by theadoption of new approaches. One such approach,which has significant potential for use in the con-struction industry, involves the use of distributedartificial intelligence, which is commonly imple-mented in the form of intelligent agents. Intelligentagents consist of self-contained knowledge-basedsystems that are able to tackle specialist problems,

Žand which can interact with one another andror.with humans within a collaborative framework.

This paper discusses the use of intelligent agentsin the collaborative design of structures. The earlypart of the paper reviews the basic concept of intelli-gent agents, highlighting related work in the con-struction domain. The ADLIB project, which is in-vestigating the use of agents in the collaborativedesign of light industrial buildings, is then discussed

in detail. The main contribution of the work is in thepeer-to-peer negotiation between the agents encapsu-lated within the ADLIB prototype. An example ispresented to illustrate the key features and benefitsof the prototype application.

2. Intelligent agents

2.1. Definitions

There is much discussion about whether someparticular system is an agent, an intelligent agent ormerely a program. This is the manifestation of ageneral problem in AI of defining ‘intelligence’ thathad led to much fruitless discussion. The result isthat there are as many definitions as there are re-searchers, leading to the term being substantiallyoverused. However, there are several broad qualities

w xthat have some measure of general agreement 10 .The key feature would appear to be ‘autonomy,’ theability of the agent to formulate its own goals and toact in order to satisfy them.

w xNwana 11 defines an agent in terms of threebehavioural attributes, any two of which must bepossessed by a software agent. Quoting from Nwana,these are:

ØAutonomy: This refers to the principle thatagents can operate on their own without the needfor human guidance, even though this wouldsometimes be invaluable. Hence agents have indi-

Ž .vidual internal states and goals, and an agentacts in such a manner as to meet its goals onbehalf of its user. An important element of theirautonomy is their pro-activeness, i.e. their abilityto ‘take the initiative’ rather than acting simply inresponse to their environment.

ØCo-operation: Co-operation with other agents isparamouth; it is the raison d’etre for havingˆmultiple agents in the first place in contrast tohaving just one. In order to co-operate, agentsneed to possess a social ability, i.e. the ability tointeract with other agents and possibly humansvia some communication language. Having saidthis, it is possible for agents to co-ordinate theiractions without co-operation.

( )C.J. Anumba et al.rAutomation in Construction 11 2002 89–103 91

Fig. 1. Taxonomy for agents.

ØLearning: For agent systems to be truly ‘smart,’they would have to learn as they react androrinteract with their external environment. In our

Ž .view, agents are or should be disembodied bitsof ‘intelligence.’ Though we will not attempt todefine what intelligence is, we maintain that animportant attribute of any intelligent being is itsability to learn. The learning may also take theform of increased performance over time.

Nwana’s requirements for agenthood may beŽ .neatly shown as a Venn diagram Fig. 1 .

The inclusion of learning, at least, as an aspirationrecognises a core quality of intelligent human be-haviour. In addition, it provides a framework bywhich software agents, as well as biologically basedagents from worker ants up to higher mammals, canbe visualised.

2.2. Agent applications

Intelligent agent research grew out of DistributedŽ .Artificial Intelligence DAI . The aim of this area

was to gain the benefits of modularity when tacklinglarge, real-world problems. These benefits are essen-tially speed and realibility. One of the problemsresearchers faced was the sheer scale of the task; inorder to get anything working the complete systemand its environment needed to be modelled. With theadvent of the wide usage of the Internet, new andsomewhat more manageable research areas started toopen up, as the Internet is essentially an ideal elec-tronic environment for agents.

In the last few years, there has been an explosionin the amount of information available on a daily

basis and, as it has increased, so has dependence onit. This information may be stored as passive storeddatabases and files or it may be information we needto actively request in order to make a decision; forexample, in the case of scheduling a meeting. Muchof this information is stored remotely in a variety offormats and sources; much of it badly labelled, if atall, and much of it time-consuming to locate. Thishas led to a state of affairs where traditional ITsystems are increasingly hard-pressed to meet manyinformation gathering challenges. Whereas, previ-ously, humans would take on the role of sifting andco-ordinating gathered information in order to takedecisions, agent-based software technology is rapidlyevolving to perform all of these functions.

Agents are considered particularly useful for tack-ling large-scale, real-world problems involvingmulti-disciplinary perspectives. They are currentlyapplied to a variety of application domains includingworkflow management, telecommunications networkmanagement, air traffic control, business process re-engineering, information retrieval and management,electronic commerce, personal digital assistants, e-mail filtering, command and control, smart databases,

w xand schedulingrdiary management 12 .

2.3. Collaboration models and the role of agents

There are essentially four modes of collaborationdepending on the nature of separation and pattern ofcommunication, between the participants in a pro-ject. The classification in the space–time communi-cation matrix shown in Fig. 2 is useful, but further

Žcharacteristics of such group collaboration such as.group sizes can be identified and used to generate a

more elaborate matrix. The types of collaboration in

Fig. 2. Collaboration models.


the generated matrix are briefly summarised beloww x13 .

ØFace-to-face Collaboration—this would nor-mally involve meeting in a common venue such as ameeting room, and participants engaging in face-to-face discussions. An example could be an initialface-to-face meeting between an architect and a clientfor a project brief session. Another example is ameeting between an architect and the structural engi-

Ž .neer s in order to discuss the implications of aproposed architectural plan on the structural configu-rations.

ØAsynchronous Collaboration—this mode ofcommunication can be conducted using such mediumas noticerbulletin boards within an organisation.

ØSynchronous Distributed Collaboration—thiswould involve real-time communication using any ofthe current technologies and techniques such as tele-phony, computer-mediated conferencing, video con-ferencing, electronic group discussionrediting facili-ties.

ØAsynchronous Distributed Collaboration—thismode of communication would involve communica-

Žtions via the post e.g. periodic lettersrnews bul-.letins , fax machines, telephone messagesrvoice

mail, pagers, electronic mail transmissions, etc.Agents are particularly appropriate for distributed

collaboration. While there are tools such as video-w xconferencing 14 that support distributed syn-

chronous collaboration by enabling ‘virtual co-loca-tion’ of project team members, there are very fewdesign tools that adequately support distributed asyn-chronous collaboration. This is the main focus of theADLIB project within a collaborative design envi-ronment. Before describing the ADLIB prototype, itis pertinent first to review related work on the use ofagents in collaborative design.

3. Related work

There is only limited research activity into theapplication of intelligent agents to problems in theconstruction industry. Some work has been done at

Ž .the Centre for Integrated Facility Engineering CIFE ,Stanford University, on the use of agents in a feder-

w xated collaborative framework 15,16 . Pena-Mora atMIT has also investigated the use of intelligent

w xagents in change negotiation 17 . However, specificdesign applications are very few, with no commer-cial systems available for use by practising engi-neers.

Much of the work in the area of automated designhas been done on building design support. Systemssuch as the Lawrence Berkeley Laboratories’ Build-

w xing Design Advisor 18 and the Building Designw xSupport Environment 19 rely on expert knowledge

residing on one machine, being used solely to advisethe user of the consequences of some design choices.Another project addresses the problem of decisionsupport for design and costing of bridge foundationsw x20 . It involves knowledge acquisition in severalrelevant domains and is intended to provide supportfor engineers in areas they find complex and prob-lematic. It also demonstrates the feasibility of acquir-ing, storing and accessing knowledge of sufficientcomplexity to be useful to an engineer in the designprocess. However, it falls short of fully automatedcollaborative design as it relies on human input tosuggest design changes and makes no use of intelli-

w xgent agents. Fenves et al. 21 developed an Inte-Ž .grated Building Design Environment IBDE which

consists of a multi-agent system, with each agenthaving responsibility for a given area—for example,spatial configuration design, structural design, andconstruction planning. Provision is made for commu-nication and co-ordination between the agents but nopeer-to-peer negotiation takes place between theagents. The US Army Corps of Engineers’ Construc-

Ž .tion Engineering Research Laboratory CERL hasalso done work on collaborative engineering designw x22,23 , taking the above decision support ideas astep further by implementing an agent-based system.Here, agents have areas of specialist knowledge andperform design and checking tasks. They interactdirectly with a user who is responsible for designchanges. However, as with the IBDE, there is noprovision for direct negotiation between agents dur-ing the design process, so the number of designsevaluated remains small. Hence, convergence to anear-optimal design is dependent on the user anddoes not make full use of the available computa-tional power, which can allow for the evaluation ofmany slightly differing designs automatically.


On the more theoretical side, there has been somework on negotiation in multi-agent systems. Forexample, Wooldridge has done work developing ne-gotiation algorithms for production sequencing in

w xmanufacturing 24 . Negotiation takes place betweendifferent production cells with their own particular

Žtasks such as ‘spray green paint,’ ‘spray red paint,’.etc. . This work demonstrates the feasibility of agent

negotiation to produce semi-optimal solutions toreal-world problems.

w xWellman 25 describes a computational marketmodel for distributed configuration design. Heshowed that if different self-interested agents wereresponsible for different functions within the design,then modelling the problem as a computational mar-ket and allowing agents’ self-interest to drive thesystem into competitive equilibrium produces Pareto-optimal designs quickly for simple examples.

The ADLIB Project builds on the work done atCERL by placing it in a more powerful agent envi-ronment. This is based on the production sequencingwork and market modelling work above, such thatsimple design changes can be suggested by the agentsthemselves. The agents then negotiate between them-selves to arrive at a consensual design that satisfieseach of them. This goes much further than previouswork on agent-based collaborative design, in whichthe role of agents is limited to change notification,and there is no provision for peer to peer negotiationbetween the agents.

4. Agent-based collaborative design of portalframes

4.1. Context

The agent-based collaborative design of portalframe structures presented here is being undertakenwithin the context of the EPSRC-funded ADLIBProject. The aim of the ADLIB Project is to investi-gate the issues involved in collaborative design usingintelligent agents, within the context of light indus-trial buildings. The choice of portal frame structuresas the testbed for the prototype system is based onthe fact that they are very widely used for factories,warehouses, leisure facilities, etc. and constitute ap-

proximately 50% of all structural steel used in thew xUK 26 . Also, this application area is one that is

familiar to many participants in the constructionindustry, and in which collaboration is necessarybetween members of the design team if an optimumdesign is to be achieved.

Within the context of this paper, an agent isproposed as being composed of two main parts.First, knowledge relating to a particular area ofexpertise, and second, a negotiation strategy thatargues for design changes, but at the same timeensuring overall agreement is reached with the otheragents. The development environment within whichthe prototype system is being developed is presentedbelow.

4.2. DeÕelopment enÕironment

The system development environment is based onZeus, a proprietary tool developed by BT that usesTCPrIP messaging built on Java to achieve interop-

w xerability 27,28 . Other message transport protocolsinclude: HTTP, KQML, and KIF. Fig. 3 belowshows a conceptual architecture of a ZEUS agent,followed by a brief definition of the layers that

w xprovide some of the in-built functionality 27 . Theselayers are:

Ø an interface layer, which enables the agent tobe linked to the external programs that provide

w xFig. 3. Conceptual model of a Zeus agent 27 .


it with resources andror implement its compe-tencies;

Ø a definition layer, where the agent is viewed asan autonomous reasoning entity;

Ø an organisation layer, where the agent isviewed in terms of its relationships with otheragents;

Ø a co-ordination layer, where the agent isviewed as a social entity that interacts accord-ing to its known protocols and strategies; and

Ø a communication layer, which implements theprotocols and mechanisms that support inter-agent communication.

4.3. Conceptual model of domain agents

The domain agents include both an InterfaceAgent, and Specialist Agents—Structural Design

Ž . Ž .Agent SDA , Building Services Agent BSA , Cost-Ž .ing and Constructability Agent CCA , and Safety

Ž .Advisory Agent SAA . These agents participate in acollaborative design and negotiate for an optimumdesign based on the constraints outlined in the pro-

w xject specifications 29 . The agents are shown in Fig.4 and their functionality described below.

( )InterfacerArchitectural Agent IAA : The inter-face agent interacts directly with the end-user andfacilitates designerragent interaction. It accepts asinput the basic building specification with constraintsand provides the final output of a building designconforming to this specification and satisfying theconstraints in a near optimal solution. As the func-tion of the other agents in the system is task-specific,they need as input a building design that they canassess. Therefore, the interface agent must transform

the specification and constraints into an initial de-sign. It is responsible for a rough initial design thatmeets the specifications. Behind this interface areseveral task-specific specialist agents.

Specialist Agents: The specialist agents compriseother agents dedicated to specialist functions. Theinternal composition of these representative agents isan assembly of other sub-agents with their ownfunctional and computational capabilities. Thesesub-agents collaborate to find an optimum solutionto a specific, devolved design task. Included in thespecialist agents are given below.

( )ØStructural Design Agent SDA : Contains struc-tural design knowledge of steel portal frames, purlinsand cladding rails. It evaluates the proposed structureand can suggest changes where the initial structure isinadequate and, in addition, changes where the struc-ture is over-designed.

( )ØBuilding SerÕices Agent BSA : This agent isresponsible for sub-agents dealing with heating,lighting and other building services. It, again, canreturn suggestions for alterations as above.

( )ØCosting and Constructability Agent CCA : Re-sponsible for costing all plans. It returns suggestionson the cost and constructability implications of sug-gested design changes.

( )ØSafety AdÕisory Agent SAA : This agent is re-sponsible for broad but not exhaustive safety princi-ples. The agent returns suggestions to meet minimumstandards.

The intention is for these agents to iterativelynegotiate changes to a proposed structure and toconverge on an optimal design that fulfills the initialspecification and constraints. Put simply, the agents

Žwill be able to trade what are from the individual.agent’s perspective areas of relative over-engineer-

Fig. 4. ADLIB domain agents.


Žing in exchange for changes that will improve again.from the agent’s perspective areas of inadequate

design.

4.4. Agent ontology

In order for the domain agents to communicateeffectively, they need to have a common understand-ing and shared knowledge of the concepts associatedwith project design and management. In the contextof collaborative design environments, this means thatthe agents should have a domain specific ontology.

In the case of collaborative design of industrialŽ .buildings such as portal frame structures , the con-

struction industry already has a vocabulary for de-scribing the different elements. This is encapsulated

w xin design standards such as BS 5950 30,31 , andTechnical Reports from the International Standards

w xOrganisations—ISO TR14177 32,33 . These stan-dards facilitate communication between members ofa project team often culminating in the exchange andinterpretation of product specifications by the projectparticipants. Within the ADLIB Project, a case studyproject was used to develop a shared ontology forthe collaborative design of portal frame structures.The case study project also enabled the establish-ment of the information logistics and flows betweenproject participants in a collaborative design environ-

w xment 34,35 . Fig. 5 shows a basic ontology used forthe example presented in this paper. Details of theontology development for the ADLIB project is pre-

w xsented elsewhere 36 .For the demonstrator, the frame components only

have the parameters length, width and height. Theontology was developed using BT’s Zeus Agent

w xBuilding Toolkit 27 as shown in Fig. 6.

Fig. 5. Conceptual demonstrator model of portal frame shed.

Fig. 6. Ontology implemented for conceptual demonstrator.

4.5. Agent knowledge modelling and representation

Each agent must have specialised knowledge uponwhich to evaluate designs. This must enable it to:

1. Satisfy minimum criteria such as the swayŽ .stability test for the structural agent . Portal

frames are relatively simple buildings with rela-tively few variables and allow simple arith-metic evaluation of a design according to cer-tain criteria.

2. Evaluate a design to obtain an overall utilityvalue. This could be a weighted sum of theabove criteria.

Specialist agent knowledge was obtained by meansof a knowledge acquisition process for the system.This involved identifying appropriate sources of

Žknowledge for each agent e.g. standards, technical


.publications, domain experts, etc. and using a rangeof knowledge elicitation techniques, including bothstructured and unstructured interviews, rapid proto-typing, and brain storming sessions with the domain

Žexperts selected from the industrial partners in the.project . The knowledge acquisition process was used

to capture and understand the data and informationmodel that describes the domain, the various levelsof knowledge associated with problem solving, andthe patterns of communicationrinteraction, and in-formationrdata flows in the problem solving space.The informationrknowledge was then transformedinto the domain ontology for the agents’ use, whilethe result of the interaction analysis was used todevelop the ADLIB agents’ interaction models withinthe multi-agent organisation. Thus, an agent’s re-sources predominantly consist of data and informa-tion required for design. The agents could also inter-act with external resources, such as domain-specificdesign software currently in use within the construc-

Žtion organisation that the agent originates from seew x.Ref. 36 .

4.6. Agent interaction and negotiation

In order to achieve effective interaction, eachagent must have some mechanism to ensure that itreaches an agreement. Each agent has the top-levelgoal of reaching agreement on the design with theother agents in the same negotiation group. It alsohas a sub-goal of maximising some measure of‘utility of design’ as seen purely from its own spe-cialist area. It will then argue for design changes that

Ž .improve or minimise the reduction of its ownutility. There is a body of work that has been done

w xon developing agent negotiation strategies 24 . Thereare two main elements in agent interaction—a nego-tiation protocol and negotiation strategies.

4.6.1. Negotiation protocolThe negotiation protocol is the set of rules of

interaction that the agents will follow to converge ona solution in design space. A common method, whichhas been adopted in the prototype, is the Monotonic

Ž . w xConcession Protocol MCP 37,38 . For two agents,the standard version is as follows. Agents start by

Žsimultaneously proposing a deal in this case a de-.sign . Agreement is reached if one agent matches, or

Žexceeds what the other has asked for in terms of.utility . If agreement is not reached negotiation pro-

ceeds to another round. An agent can only proposedeals that have a greater or equal utility for the otheragent, that is, concede or do nothing. If neither agentconcedes then negotiation ends as conflict is reached,otherwise negotiation continues. It is a protocol par-

Ž .ticularly suited to task-oriented domains TODs as itŽensures convergence to a deal where a deal is

.possible . In ADLIB, the negotiation protocol isslightly more complicated for the three reasons statedbelow.

ØAn agent cannot calculate the utility anotheragent may ascribe to a design as each has its ownarea of specialist knowledge with which design util-ity is calculated. For an agent to suggest a conces-sion from its current position that gives the otherhigher utility it must make repeated offers until oneis accepted.

ØThere is a utility time function introduced tostop long, drawn out negotiations. This means thatno agent can stand still and offer a deal consisting ofa design with the same utility. Due to the time cost,overall utility will have decreased.

ØThere are more than two agents. The simplestanswer is for agents to negotiate in pairs that chainaround a random, round robin arrangement. A com-plete deal is obtained when there has been a com-plete round where each pair has agreed.

4.6.2. Negotiation strategiesThese are the strategies that an individual agent

follow to propose alternate deals within the negotia-tion protocol above. Given that the final system isdesigned so that any agent that adheres to the negoti-ation protocol above can work within the system,then this will be completely up to the designers ofthese agents. For the agents designed for this projecta simple gradient descent algorithm is used. In thiscase, an agent makes an offer that will decrease itsutility by the least amount with the minimum stepsize being governed by the time cost; the more dealsit has to offer before one is accepted the greater willbe the time cost, so the more it will have to concedeon the design. Fig. 7 shows the opening offer fornegotiation in design space.


Fig. 7. Utility gradient within design space for three agents, A , A and A .1 2 3

This assumes a well-behaved design space withfew local maxima. Generally, but not always, thiscould be considered to be the case, e.g. a concession

Žon beam depth i.e. lower utility for a structural. Žagent will usually result in lower cost i.e. greater

.utility for a costing agent . This is something thatneeds to be evaluated in practice.

The assumption of a smooth design space givesagents a metric for judging the distance between

Ž .proposed deals a point in design space , so allows asuitable step-size to be calculated, and more impor-tantly determines the direction an agent needs tomove in to converge on a solution.

By a process of rounds involving concession mak-Žing, each individual agent will move from its in its

. Žown terms most optimal design represented by the.black dots in Fig. 7 to a final compromise design.

This deal or final design will be somewhere withinthe interaction of all three circles in Fig. 7.

4.6.3. Modelling agent negotiation knowledgeIn the demonstrator, knowledge is modelled as

sets of declarative facts, which consists of abstract orconcrete concepts that define the domain ontology.For example, the concrete facts may define the struc-tural elements of a portal structure such as rafter,beam, column, and the associated design attributesŽ .see Fig. 6 . In the context of a MAS organisation,the abstract facts are used to model an agent’s designand negotiation knowledge including the social be-

Ž .haviour such as interaction with other agents dur-ing negotiation in the design space. These factscumulatively define the sequences of negotiation ac-tions, and the design processesrtasks are decom-posed to such a discrete level that they are amenableto process automation through a series of symboliclogic manipulation. It is necessary to point out thatone of the characteristics of the ADLIB agents is thatthey are non-transient. This means that there is nodynamic re-distribution of tasks at run-time. Theagents, tasks and actions to be performed, and whichagents will perform which tasks and when, areclearly defined a priori at design time as part of theagent creation and configuration process. However,definition of the agent tasks and responsibilities re-flect the functional and disciplinary roles and respon-sibilities of domain experts, in a collaborative designcontext. As an illustration, an abstract fact negotia-tionOrder that is encapsulated within the Negotia-tion protocol, is used to define an agent’s sequence

Ž .of negotiations rules of engagement with other taskagents in the design space. This is an initial resourcethat the agent is equipped with, and it defines animportant social behaviour of the agent in the designspace. However, the negotiation order was deter-mined by the logistics of communication and interac-tion between the domain experts, and this importantsocial behaviour was specifically captured in theknowledge acquisition. Consequently, the agent in-teraction model is a by-product of the interaction


analysis of the knowledge acquisition protocol dataw x36 . Utilising knowledge in this way could lead to

significant reduction in communication overheadsrequired by the agents at runtime. Such communica-

Ž . Ž . Ž . Ž .Fig. 8. a Agent registration; b initial design proposals by the three specialist agents; c frequency of inter-agent interaction; d agentsconverge on a design solution.


Ž .Fig. 8 continued .

tion overheads translate to monetary costs and can bequite significant in heavy practical or industrial ap-plications.

5. Pilot demonstrator

A pilot demonstrator has been implemented todemonstrate the collaborative design of portal framestructures using intelligent agents. This is based on asubset of ADLIB agents—the Structural Design

Ž .Agent SDA , the InterfacerArchitectural AgentŽ . Ž .IAA and the Safety Advisory Agent SAA , andfocuses on the negotiation mechanism through whichthe collaborating agents reach agreement. The nego-tiation mechanism is based on game theory, with theutility functions for these agents being calculated bythe analysis of a proposed design according to theirown specialist knowledge. These agents are acting

w xwithin a Worth Orientated Domain, 37 , that is, theirgoal is to maximise their utility function. The agentsalso have a second goal that must always be satis-fied; that is to meet a set of minimum design criteria.These are things such as maximum loads for acertain beam size, etc.; some of these are all con-tained within an agent’s internal knowledge base.Agents then negotiate from the starting point of arough initial design. Negotiation proceeds in rounds,where in each round agents make concessions, in

Ž .pairs, to arrive at a near optimal compromise de-sign. Concession making by individual agents isencouraged by the use of a time-dependent functionas part of the utility function; this attaches a cost tothe negotiation time. Concessions are made by sug-gesting alternative designs.

Fig. 8a–d illustrates some of the steps taken inarriving at a consensual design. The agents firstregister with the Agent Name Server, which provides

Žthe directory service within the agent platform Fig..8a .In Fig. 8a, the agents register themselves in the

Ž .Agent Name Server ANS , and are able to locateand communicate with each other during design. Forinstance, the illustration captures registration of thecosting agent with the ANS, as well as the interac-tion between the Structural and Interface agents.After the registration process, the interface agentdistributes the project design constraints as extractedfrom the project specification document and input bythe user. The interface agent then sends trigger to the

Ž .Structural Design Agent SDA to begin design. Thisscenario is shown in Fig. 8a above. This messageexchange from the Interface Agent to SDA acts as anexternal stimulus for the SDA to initiate the designprocess and subsequently begin negotiation with thenegotiation participants. On completion of its design,the structural agent identifies and enters into negotia-tion with the first negotiation participant in the chain


SAA, proposing the structural configuration thatŽ .maximises its own utility Fig. 8b .

In Fig. 8b, each agent proposes a design thatmaximises its utility; for example, the Structural

Ž .Design Agent SDA proposes the biggest structurepossible while the Costing and Constructability AgentŽ .CCA proposes the cheapest structure possible. Theabstract concepts negotiation participants and nego-tiation pair together define an agent’s social be-haviour with regards to its interactions with otheragents during design in the MAS environment. Theagents are also equipped with this piece of knowl-edge as initial resources during design and configura-tion. This interaction sequence can be viewed in realtime, but Zeus also provides the visual tools thatenable both the sequence of message transactions

and a statistical analysis of the interaction betweenthese agents during a given collaborative designsession to be viewed.

The thread of conversationrtransactions betweenthe SDA and other task agents during the negotiationis summarised below in Table 1. The complete sce-nario consists of the parametric design of the follow-ing structural elements in a portal frame: beam,column, rafter, and purlin. However, some of thestructural elements and attributes have been sup-pressed due to space constraints, but negotiations anddecisions on the parametric design are simply exten-sions of the inter-agent transactions demonstrated inthe table. Only a portal frame structural elementŽ .beam is shown, and the table only shows theattributes that were negotiated and altered in the

Table 1Summary of agent transaction report: trail of conversationrnegotiation between SDA and other task agents

SrN Time Fromrto ContentŽ .Zeus units

Ž ŽŽ . Ž . Ž .1 8.95 From: IAA data :type constraints :attributes maxHeight 16 maxCost 100000 maxWidth 15Ž . Ž . Ž . Ž . Ž ...minHeight 6 minWith 5 tgtCost 6000 maxDepth 16 minDepth 6

Ž ŽŽ ...2 8.959 From: IAA data :type startCreateInitialDesigh:attributes start trueŽ ŽŽ .3 8.970 From: IAA data :type negotiationParticipants :attributes initiator Structural

Ž ...respondent notYetKnownŽ .4 11.302 From: ANS :name HandS :host A158.125.72.17B :port 6703 : type Agent

Ž ŽŽ Ž Ž . Ž .5 14.261 To: SAA data :type myDesign :attributes beam :type Beam :attributes Depth 0.30 Length 12.0Ž . Ž . Ž ...owner HandS status proposal toBeEvaluatedBy Structural

Ž ŽŽ Ž ŽŽ .6 17.264 From: SAA data :type myDesign :attributes beam :type Beam :attributes Depth 0.4994Ž . Ž . Ž . Ž .Length 12.0 owner Structural status proposal toBeEvaluatedBy HandSŽ ...completed false

Ž ŽŽ Ž Ž .7 20.337 From: SAA data :type myDesign :attributes beam :type Beam :attributes Depth 0.3599Ž . Ž . Ž . Ž ...Length 9.6 owner HandS status proposal toBeEvaluatedBy Structural

Ž ŽŽ . Ž ...8 21.238 To: IAA data :type acceptProposal :attributes accept false name noneŽ ŽŽ Ž ŽŽ .9 22.283 To: IAA data :type myDesign:attributes beam :type Beam :attributes Depth 0.49552

Ž . Ž . Ž . Ž . Ž .Length 9.6 utility 1.0 owner HandS status mine toBeEvaluatedBy HandSŽ ...completed false

Ž ŽŽ Ž Ž . Ž .10 23.265 To: SAA data :type myDesign :attributes beam :type Beam Depth 0.4992 Length 9.6Ž . Ž . Ž . Ž ...owner HandS status proposal toBeEvaluatedBy HandS completed false

Ž ŽŽ . Ž ...11 24.259 From: SAA data :type acceptProposal :attributes accept true name HandSŽ ŽŽ . Ž .12 25.293 From: CCA data :type negotiationParticipants :attributes initiator Costing respondent Structural

Ž ...start trueŽ ŽŽ Ž ŽŽ .13 25.295 From: CCA data :type myDesign :attributes beam :type Beam :attributes Depth 0.4992

Ž . Ž . Ž . Ž .Length 9.6 owner Costing status proposal toBeEvaluatedBy StructuralŽ ...completed false

Ž ŽŽ . Ž ...14 26.285 To: CCA data :type acceptProposal :attributes accept true name StructuralŽ ŽŽ Ž ŽŽ .15 26.312 To: IAA data :type myDesign :attributes beam :type Beam :attributes Depth 0.4992

Ž . Ž . Ž . Ž . Ž ...Length 9.6 owner Costing status mine toBeEvaluatedBy Structural completed falseŽ ŽŽ .16 26.312 To: SAA data :type startChangeNegotiationParticipant :attributes initiator Structural

Ž . Ž ...respondent HandS start trueŽ ŽŽ . Ž . Ž ...17 26.344 From: IAA data :type firstOfferHistory :attributes HanS true Structural true Costing true


process before agreement was reached. This includeslength and depth of the beam. The depth is a func-tion of the cross-sectional dimensions. The agents

Žcommunicate by sending a design proposal myDe-.sign as the main content in a message body. The

abstract concept message is inherited from the agentŽ .development platform Zeus and the syntax and

Žprotocol are FIPA Federation of Intelligent Physical.Agents -compliant. All the messages shown in the

table are of type inform. The next session describesthe sequence of actions in the inter-agent interaction.

The negotiations trail follows these sequences.There is a progressive increase in the time, which isgenerated from the system:

1. IAA passes design constraints to all the taskagents;

2. IAA sends trigger for SDA to start design, aswell as other task agent

3. IAA sends information on negotiation partici-pants, default value is none.

4. ANS responds to SDA’s request for the ad-dressrlocation of SAA, responds with: Struc-tural1649 as the conversation ID in the AIn-Reply-ToB field of the message

Ž .5. SDA proposes a design myDesign and sendsit for SAA to evaluate

6. Counter-proposal sent to SDA: 1st alterationis on Beam Depth

7. Counter-proposal from SAA: 2nd alteration ison Beam depth, and length

8. SDA informs IAA that proposal from SAAhas been rejected, proposes an alternative de-sign and notifies IAA that respondents shoulduse NewDesignEÕaluateUtility as the conver-sation ID in the Reply-With field

9. Counter-proposal: 3rd alteration is on Beamdepth

10. Counter-proposal: 4th alteration is on Beamdepth

11. SAA accepts the proposal and enters negotia-Žtion with Costing trigger not shown in the

.table12. CCA initiates negotiation with SDA13. CCA sends a proposal. There is no change

from that agreed upon with SDA, as CCA isalso satisfied with the proposal

14. SDA confirms acceptance to CCA15. SDA Sends confirmation of accepted design

from CCA to the IAA and includes SendAc-ceptNotice as the conversation ID in the ARe-ply-With fieldB of the message

16. Informs SAA that proposal from costing hasbeen accepted

17. The Accepted Final Design Configuration is:Ž .Beam Depth 0.4992, Length 9.6 @ 26.3125

18. IAA certifies that all three agents have agreedand sends trigger to all the Agents to stop the

Ž .negotiation see Fig. 8d .

A detailed analysis of the frequency of inter-agentinteraction for the simulation can be obtained. Fig.8c below shows the matrix analysis of the interactionbetween the agents in the automated design space.Users are able to monitor, analyse, and evaluate theperformance and activities of their agents in thenetwork using the visualrreporting tools in Zeus.

The interaction matrix in Fig. 8c shows all theagents in the MAS environment including the utility,and task agents. The utility agents include: ANS thatprovides a directory service for agent registrationand peer identification, the Broker agent providesdirectory services for agent-discovery, while the Vi-sual agent provides services for visualisation of theagents behaviour in real time. The task agents weredescribed in Section 4.3.

6. Discussion and conclusions

Distributed artificial intelligence offers majorscope for facilitating collaborative working and con-current engineering in construction. It directly ad-dresses the integration of multi-disciplinary perspec-tives and provides a framework for resolving designconflicts between members of a construction projectteam. The use of intelligent agents can also help to

w xreduce information overload 39 , and to facilitateinteroperability between the many, diverse and het-

Ž .erogeneous legacy IT systems in the constructionw xindustry 40,41 .

The distributed approach proposed will allow in-dividual areas of expertise to be encoded into partic-ular agents, thus modelling the real-world problem of


collaborative and concurrent design development inan intuitive, modular and hence expandable manner.In such an agent-based system, as compared with acentralised knowledge-based system, decisions canbe taken locally according to local knowledge, allow-ing greater flexibility as this changes. Having agentscommunicate with each other across the Internetbrings great increases in speed of convergence to asatisfactory design, compared with the traditionalinter-disciplinary interactions. Some of the otherbenefits of this approach include: decentralisation oftraditional and inadequate project command and con-trol structures; effective decomposition of large-scaleproblems; improved collaborative and concurrent

Ž .working; and easier and cheaper access to routineŽspecialist information especially as agent-based sys-

.tems are made available on the World Wide Web .This paper has introduced the concept of dis-

tributed artificial intelligence and demonstrated thepotential for its use in the collaborative design ofportal frame structures by means of an example. Theprototype system represents a significant advanceover existing systems by providing for peer to peernegotiation between the design agents. The nextstage of the research project involves enhancing theknowledge base of the various agents so that theycan tackle more complicated designs, and providinga mechanism for the integration of the agents withthe legacy software systems used by the variousproject participants.

Clearly, the trend towards the adoption of collab-orative and concurrent engineering practices withinthe construction industry is long overdue and needsto be supported by emerging information and com-munications technologies. Intelligent agent systems,such as that described in this paper, have a role inthis regard and can facilitate distributed asyn-chronous collaboration as well as the integration ofmulti-disciplinary perspectives, tools and techniques.However, there is still much that needs to be donebefore agent-based systems can be usefully deployedin the collaborative design of buildings. Issues thatneed to be addressed include the development of acommon ontology for shared domain concepts, agentcommunication and negotiation protocols, and mech-anisms for the integration of agent-based systemswith existing CAD and IT systems. Most of these arebeing addressed within the ADLIB project.

Acknowledgements

The ADLIB project is funded by the EngineeringŽ .and Physical Science Research Council EPSRC ,

UK, under its Innovative Manufacturing InitiativeŽ .IMI . The industrial collaborators are: Building Re-

Ž .search Establishment BRE , Steel Construction In-Ž . Ž .stitute SCI , British Telecommunications BT ,

Curtins, WS Atkins, Health and Safety ExecutiveŽ .HSE , Wescol Glosford, Ferguson McIlveen Archi-tects, and CSC.

References

w x Ž .1 C.J. Anumba, N.F.O. Evbuomwan Eds. , Concurrent Engi-neering in Construction. Institution of Structural Engineers,

Ž .London, 1997, July ISBN 1 874266 35 2 .w x2 C.J. Anumba, N.F.O. Evbuomwan, Concurrent engineering

in design-build. Projects, Construction Management and Eco-Ž . Ž .nomics 15 3 1997 271–281, May.

w x3 P. Deasley, F. Lettice, A concurrent engineering approach toconstruction: learning from cases in manufacturing industry.

Ž .in: C.J. Anumba, N.F.O. Evbuomwan Eds. , ConcurrentEngineering in Construction. Institution of Structural Engi-neers, London, 1997, pp. 296–305, July.

w x4 C.J. Anumba, N.F.O. Evbuomwan, T. Sarkodie-Gyan, Anapproach to modelling construction as a competitive manu-facturing process. Competitive Manufacturing, ProceedingsIMC-12, University College, Cork. 1995, pp. 1069–1076.

w x5 Y. Rezgui, G. Cooper, J. Yip, Construction collaborativeengineering in a concurrent multi-actor environment, in: C.J.

Ž .Anumba, N.F.O. Evbuomwan Eds. , Concurrent Engineer-ing in Construction. Institution of Structural Engineers, Lon-don, 1997, pp. 183–194, July.

w x6 N.F.O. Evbuomwan, C.J. Anumba, Concurrent life cycleŽ .design and construction, in: B.H.V. Topping Ed. , Develop-

ments in Computer-Aided Design and Modelling for CivilEngineers. Civil-Comp Press, Edinburgh, 1995, pp. 93–102.

w x7 M. Latham, Constructing the team: final report on jointreview of procurement and contractual arrangements in theUK construction industry, HMSO, 1994.

w x8 Office of Science and Technology, Technology Foresight—Progress Through Partnership. HMSO, London, 1995.

w x9 DoErBT, Construct-IT: Bridging the Gap, An InformationTechnology Strategy for the United Kingdom ConstructionIndustry, Construction Sponsorship Directorate, Departmentof the Environment, HMSO, 1995.

w x10 M. Wooldridge, N.R. Jennings, Intelligent agents: theory andŽ . Ž .practice. The Knowledge Engineering Review 10 2 1995 .

w x11 H.S. Nwana, Software agents: an overview. Knowledge En-Ž . Ž .gineering Review 11 3 1996 205–244.

w x12 D.T. Ndumu, H.S. Nwana, Research and development chal-lenges for agent-based systems. IEErBCS Software Engi-

Ž .neering Journal, Special Issue on Agents Technology 144 1Ž .1997 2–10, February.


w x13 O.O. Ugwu, C.J. Anumba, L. Newnham, A. Thorpe, Agent-based collaborative design of constructed facilities’ in artifi-cial intelligence in structural engineering—information tech-nology for design, manufacturing, maintenance, and monitor-

Ž .ing, in: A. Borkowski Ed. , Proceedings of the 6th EG-SEA-AI Workshop, Wierzba. 1999, pp. 199–208.

w x14 A.N. Baldwin, A. Thorpe, C. Carter, G. Taylor, Conferenc-ing systems within construction organizations, civil engineer-ing. Proceedings of the Institution of Civil Engineers, vol.132, 1995, pp. 174–180, No. 4.

w x15 T. Khedro, AgentCAD: a distributed cooperative CAD envi-Ž .ronment. in: B. Kumar, A. Retik Eds. , Information Repre-

sentation and Delivery in Civil and Structural EngineeringDesign. Civil-Comp Press, Edinburgh, 1996, pp. 15–19.

w x16 T. Khedro, P. Teicholz, M.R. Genesereth, A framework forcollaborative distributed facility engineering. Proceedings 1stASCE Congress on Computing in Civil Engineering, Wash-ington D.C., 20–22 June. ASCE, New York, 1994, pp.1489–1496.

w x17 F. Pena-Mora, K. Hussein, Change negotiation meetings in adistributed collaborative engineering environment, in: B. Ku-

Ž .mar, A. Retik Eds. , Information Representation and Deliv-ery in Civil and Structural Engineering Design. Civil-CompPress, Edinburgh, 1996, pp. 29–37.

w x18 K. Papamichael, J. LaPorta, The building design advisor.ACADIA96, Tucson, Arizona, 1996.

w x19 K. Papamichael, S. Selkowitz, Building Design Support En-vironment. Internal Report, Lawrence Berkeley Laboratory,1996.

w x20 J.V. Cadogan, C.J. Moore, J.C. Miles, Computational supportfor the design and costing of bridge foundations, information,

Ž .in: B. Kumar Ed. , Processing in Civil and Structural Engi-neering Design. Civil-Comp Press, Edinburgh, 1996, pp.113–119.

w x21 S. Fenves, U. Flemming, C. Hendrickson, M.L. Maher, R.Quandrel, M. Terk, R. Woodbury, Concurrent Computer-In-tegrated Building Design. Prentice Hall, New Jersey, 1994.

w x22 J.D. Chiou, R.D. Logcher, Testing a Federation Architecturein Collaborative Design Process—Final Report, Report No.R96-01, US Army Construction Engineering Research Labo-ratory, Urbana-Champaign, USA, 1996.

w x23 K.D. McGraw, P.W. Lawrence, J.D. Morton, J. Heckel, Theagent collaboration environment an assistant for architects

Žand engineers for details, see URL: http:rrwww.cecer..army.milrplrace. htm , 1999.

w x24 M. Wooldridge, S. Bussmann, M. Klosterberg, Productionsequencing as negotiation. Proceedings of the First Interna-tional Conference on the Practical Application of Intelligent

Ž .Agents and Multi-Agent Technology PAAM 96 , London,1996.

w x25 M.P. Wellman, A computational market model for dis-Ž .tributed configuration design. AI EDAM 9 1995 125–133.

w x26 C.M. King, Personal communication, Steel Construction In-stitute, November 1997.

w x27 BT, Zeus Development Toolkit. Zeus Documentation, BritishTelecommunications plc, UK, 1999.

w x28 URL1, UMBC KQML Web at University of Marylandhttp:rrwww.cs.umbc.edurkqmlr.

w x29 C.J. Anumba, L.N. Newnham, Towards the use of distributedartificial intelligence in collaborative building design, in:

Ž .E.T. Miresco Ed. , Proceedings, 1st International Confer-ence on New Information Technologies for Decision Makingin Civil Engineering, Sheraton Hotel, Montreal, Canada,11–13 October. 1998, pp. 413–424.

w x30 BSI, BS 5950: Structural Use of Steelwork in Building: Part1. 1990: Code of Practice for Design of Simple and Continu-ous Construction. British Standards Institution BSI, UK,1990.

w x31 SCI, Design of single-span steel portal frames. Draft Specifi-cation SCI Publication, vol. 252, The Steel ConstructionInstitute, UK, 1999.

w x32 ISO, Classification of information in the construction indus-try, International Standards Organisation, ISO TR 14177,1994.

w x33 ISO, Industrial automation systems and integration—productdata representation and exchange—Part 1: Overview andfundamental principles, International Standards Organisation,ISO 10303-10301, 1994.

w x34 T.R. Gruber, A translation approach to portable ontologyŽ . Ž .specifications. Knowledge Acquisition 5 2 1993 199–220.

w x35 T.R. Gruber, Towards Principles for the Design of Ontolo-gies used for Knowledge Sharing, Technical Report KSL93-04, Knowledge Systems Laboratory, Stanford University.http:rrksl-web.stanford.edurknowledge-sharingrpapersrshade-overview.html, 1993.

w x36 O.O. Ugwu, C.J. Anumba, A. Thorpe, Ontology develop-ment for agent-based collaborative design. Engineering, Con-struction, and Architectural Management. Blackwell Science,

Ž .UK, 2001 in press .w x37 J.S. Rosenschein, G. Zlotkin, Rules of Encounter. MIT Press,

Cambridge, Massachusetts, 1994.w x38 N.R. Jennings, P. Faratin, M.J. Johnson, Using intelligent

agents to manage business processes. Proceedings of the FirstInternational Conference on the Practical Application of In-

Ž .telligent Agents and Multi-Agent Technology PAAM 96 ,London, 1996.

w x39 P. Maes, Agents that reduce work and information overload.Ž . Ž .Communications of the ACM 37 7 1994 31–40.

w x40 M.R. Genesereth, S.P. Ketchpel, Software agents. Communi-Ž . Ž .cations of the ACM 37 7 1994 48–53.

w x41 D.T. Ndumu, J.M.H. Tah, Agents in computer-assisted col-Ž .laborative design, in: I. Smith Ed. , Artificial Intelligence in

Structural Engineering. Proceedings 5th EG-SEA-AI Work-shop, Ascona, Switzerland, 26–31 July, Lecture Notes inArtificial Intelligence, Springer-Verlag, Berlin, 1998, pp.249–270.

collaborative design of structures using intelligent agents

Documents