T. Using interaction protocols in distributed construction processes

CONSTRUCTIONPROCESSES

SanttuToivonen,TapioPitk¨aranta

VTTInformationTechnology

P.O.Box1203,FIN-02044VTT,FINLANDEmail:{santtu.toivonen,tapio.pitkaranta}@vtt.fi

HeikkiHelin

TeliaSoneraFinland

P.O.Box970,FIN-00051Sonera,FINLANDEmail:heikki.j.helin@teliasonera.com

JungUngMin

StanfordUniversity,CIFE,TermanEngineeringCenter

Stanford,CA94305-4020,USAEmail:jumin@stanford.edu

Keywords:Abstract:

Interactionprotocols,softwareagents,adaptability,constructionprocess.

Wepresentaninteractionprotocolbasedapproachforfacilitatingdistributedconstructionprocesses.Inourapproach,softwareagentsrepresentvariousparticipantsofaconstructionproject.Examplesofsucharecontractor,subcontractor,andsupplier.Theseagentsaresupposedtocommunicateaccordingtopredefinedinteractionprotocols.Shouldanagentbeunawareofsomeprotocolneededintheprocess,itbenefitsfromadoptingit.Weapproachthisproblemwithinteractionprotocoldescriptionsserializedinacommonlyagreeduponformatanddesignouragentssothattheycanadapttothedescriptions.Wepresentascenariointhefieldofconstructionindustry,wheretheprojectparticipantsdonotknowinadvancehowtocommunicatewitheachother.However,byadaptingtotheinteractionprotocoldescriptionsprovidedbytherespectivepartiestheyareeventuallyabletointeract.

1INTRODUCTION

Internet’semergingeraisthatofWebServices.LikeHTMLpagesofthecurrentweb,alsoWebSer-vicesaredistributedacrosstheInternetandaddress-ablewithURIs.Themostevidentdifferenceistheinclusionofintelligentcomputerprogramsinaddi-tiontohumanbeingsastheconsumersofwebcon-tent.Thiscallsforprovidingmaterialinthewebwithformalandmachine-understandabledescriptions,i.e.,creatingtheSemanticWeb.

Thispaperdiscussesacaseofbusiness-to-businesscollaborationinthedomainofconstructionindustry.Morespecifically,weoutlineaframeworkforintelli-gentsoftwareagentsrepresentingvariousparticipantsofaconstructionprojecttocollaborate.Collabora-tionisbasedoninteractionprotocoldescriptionspro-videdbytheparticipants.Inordertoenabledynamiccollaboration,thedescriptionsconformtomutuallyagreeduponinteractionprotocolontologyweintro-ducedin(ToivonenandHelin,2004).

Motivationforthechosencasestemsfromthecon-

tractor’sneedtokeeptrackoftheprogressofaprojectithasinitiated.Thispresupposesdirectinteractionbetweenthecontractor’sexpeditorandotherpartic-ipants.Theexpeditoragent,ifunawarebeforehandhowtocommunicatewithaparticipant,candown-loadinteractionprotocoldescriptionsprovidedbytheparticipantandadaptitsbehavioraccordingly.Inadditiontotheabovemotivationtofacilitatein-formationflowsbetweenconstructionprocesspartic-ipants,wealsohaveatechnologicalobjective.Ourintentionistoinvestigatesoftwareagentsadaptingaccordingtointeractionprotocoldescriptions.Eventhoughthesamplescenarioisfocusedtoaparticularphaseofaconstructionprocess,ourapproachissuit-abletovirtuallyanydistributedapplicationwithinde-pendentpartiesinteractingviasoftwareagents.How-ever,expeditingprocessasarealworldproblempro-videsuswithinterestingproof-of-conceptmaterial.Therestofthepaperisorganizedasfollows:Inthenextsectionwedescribeascenarioforapplyingourapproachincertainpartsofaconstructionpro-cess.Section3summarizestheinteractionprotocol

1

ontology,howtodescribeinteractionprotocolsbasedonitusingRDF,andhowtoadapttothedescriptions.Finally,Section4presentssomeconcludingremarks.

2DISTRIBUTED

CONSTRUCTIONPROCESS2.1

SampleScenario

Supplychainmanagementintheconstructionindus-trycanatagenerallevelbedividedintotwoseparateprocesses:procurementandexpediting(Williams,1995).Thispaperdealswiththeexpeditingpro-cess.Traditionally,performinganexpeditingprocessmeanspayingvisitstothepremisesofprojectpartic-ipants,makingphonecalls,orexchangingemailsforcheckingthestatus.Therearepreviousattempts,suchastheonedescribedin(Kimetal.,2000),forapply-ingsoftwareagentsinconstructionprocesses.Adis-tinctivepropertyinourapproachisthatweautomatepartsoftheexpeditingprocessbyapplyinginteractionprotocolstotheworkperformedbythecontractor’ssoftwareagentthatactsasanexpeditor.

Typicallythecontractorwantstokeeptrackoftheprojectithasinitiated,andthereforeexpectstore-ceivestatusreportsoftheprojectfromthesubcontrac-tor(s)regularly.Thathelpsthecontractortoidentifyandavoidpossiblerisksinvolvedintheprojectsuchasscheduledelaysandcostoverruns(BarrieandPaul-son,1992).However,oftenthecontractorcannotrelysolelyontheinformationthesubcontractor(s)provideinthestatusreports.Asubcontractorcaneitherinten-tionallyconcealthattheprojectisbehindschedule,orsomeimportantpieceofinformationmightunin-tentionallybeoutofdateinastatusreport.

Forverifyingtheinformationinastatusreport,thecontractor’sexpeditorcontactstheotherparticipantsdirectly.Thereby,inadditiontointeractingwiththesubcontractor,weaddfunctionalitiesfortheexpedi-toragenttointeractwiththerest.Figure1depictsthestatesoftheexpeditingprocessfromtheexpedi-tor’spointofview.Theexpeditoractssomewhatasadetectivetryingtodigupinformationfromvarioussourcesandincorporateitintoacompletepicture.Withmanyprojectparticipantsinvolved,directin-teractionbetweenthecontractorandtherestcanalsohelptoavoidproblemamplification.Consideracasewhereasupplierdeliversrawmaterialtoamanufac-turer,whoissupposedtofabricatebulkproductsfromthatmaterialanddeliverthemtoanothermanufac-turer.Thatmanufacturer,inturn,issupposedtobuildamorerefinedproductfromthemandagaindeliverittoyetanotherparticipant.Supposefurther,thataproblemofsomekindhappensatanearlystageofthe

2

[failure]󰀀Request Status Report󰀀[success]󰀀Extract Order ID󰀀Extract Supplier URI󰀀[failure]󰀀Query For Delivery ID󰀀Extract Carrier URI󰀀[success]󰀀[failure]󰀀Request Delivery Report󰀀[success]󰀀Compare Information󰀀[not ok]󰀀[ok]󰀀Take Actions󰀀Figure1:Progressionoftheexpeditingprocessfromthecontractor’spointofview

process—saythedeliveryofrawmaterialgoestoawrongaddress.Unlessthereisfrequentdirectinterac-tionbetweenthecontractorandalltheseparticipants,reactingtothismisfortunemostlikelytakeslongertime.Directinteraction,instead,canfastentheinfor-mationexchange.That,inturn,canhelpinavoidingthe“bullwhipeffect”(Leeetal.,1997)andtheprojectwilllikelynotfallasmuchbehindtheschedule.Inourscenario,theexpeditorknowsinitiallyonlyhowtointeractwiththesubcontractor,andthereforeithastolearnhowtodosowithotherparticipants.Weapproachthisproblembydefininginteractionpro-tocoldescriptions,anddesigntheexpeditoragentsothatitcanprocessthedescriptions,andadaptitsbe-havioraccordingly.

2.2

InteractionProtocolBasedCollaboration

WemodeltheinteractionbetweenthecontractorandthesubcontractorusingFIPARequest(FoundationforIntelligentPhysicalAgents,2000c)interactionproto-col.Thecontractorrequeststhesubcontractortosendthestatusreport.Thesubcontractorthentriestoper-formtherequestedaction.Inthesuccessfulcasethesubcontractorinformsthecontractorthattheactionisperformed.Shouldsomethinggowrong,thesubcon-tractorsendsafailuremessageinstead.

Assumethesubcontractorhasorderedasteeldeliv-eryfromthesupplierwiththehelpofanexternalcar-rier,butthedeliveryhasnotyetarrived.Itneverthe-lessincludestheorderinthestatusreportbeforesend-ingittothecontractor.Inourscenariothecontractorwantstokeeptrackofthewholeprocess.Therebyitcontactsthesupplierandthecarriertocheckthestatusoftheorderandthedelivery.Thecontractorfirstre-queststhesubcontractortosendthestatusreport.ByexaminingitasdepictedinFigure1,itfindsouttheaddresses(URIs)oftheagentsrepresentingsupplierandcarrier,aswellastheIDofthesteelorder.Notethatthisexamination,i.e.,howthecontractorextractsthedesiredinformationfromthestatusreport,isnotinthefocusofourcurrentresearch,anditcouldbeperformedbythesoftwareagentitself,orbyahu-manbeing.Inanycase,afterretrievingthisinforma-tionthecontractorqueriesthesupplierfortheIDofthesteeldeliverywiththeorderIDastheparameter.Thesupplierprovidesthecontractorwithit,andthecontractorusesitnextasaparameterforrequestingadeliveryreportfromthecarrier.

Sincethecontractorhasnotcollaboratedwiththesupplierandthecarrierbefore,beingabletodosoatthistimepresupposesadaptability.Inthenextsectionwepresentinteractionprotocoldescriptionsinmoredetail.Westartwiththeinteractionprotocolontol-ogy,thenmoveontotheactualdescriptions,andafterthatdiscusshowthecontractor’sexpeditoragentcanprocesstheinformationfoundinthedescriptionsandadaptitsbehavioraccordingly.

3

DESCRIBINGINTERACTIONPROTOCOLSWITHSEMANTICWEBTECHNOLOGIES3.1

InteractionProtocolOntology

Interactionprotocolsspecifyorderedsetsofmessagestobeexchangedbetweenconversatingagents.WedescribetheinteractionprotocolsusingRDF(LassilaandSwick,1999),alanguagedesignedfordescribing

11cardinalityminCardinalityObjectPropertyonPropertyRestrictionsubClassOfhasInitiatorsubClassOfRestrictiononPropertydomainClassObjectPropertyrangeClassInteractionProtocoldomainhasParticipantInitiatorsubClassOfcardinalityRestrictiondomainsubClassOf1onPropertyObjectPropertyhasProgressClassClassrangeAgentsubClassOfParticipantrangeObjectPropertyClassrangerangeMessage1minCardinalityhasMessageClassrangeRestrictionsubClassOfProgressdomaindomaindomainClassonPropertyOptionrangeObjectPropertyObjectPropertyObjectPropertydomainsendByrecvByhasStatesubClassOfObjectPropertyrangeObjectPropertychoicesdomainClasshasTimeoutdomainClassStatePredThingdomainrangeObjectPropertyrangefollowsClassClassTimeOutsubClassOfExceptionsubClassOfFigure2:Coreconceptsoftheinteractionprotocolontology

anyresourcesintheSemanticWeb.Asmentioned,interactionprotocoldescriptionsconformtoaninter-actionprotocolontology(ToivonenandHelin,2004).CoreconceptsofthatontologyaredepictedinFig-ure2.

Basicallyallinteractionprotocolshaveoneinitiatorandoneormoreparticipants.Progressoftheproto-colisdefinedwithstatesfollowingeachother.Morespecifically,stateshaveoptionstochoosefrom,andthechosenoptiondetermineswhichstatetoshiftto.Optionscanhavemessagesassociatedwiththemthataresentbetweentheparticipatingagents.

3.2DescribingInteractionProtocols

Amongotherinteractions,thesupplierknowshowtorespondtoqueriesforselectedthings.Inoursce-nario,thecontractorasksthesupplierfortheIDofthesteeldeliveryusingtheorderIDfoundinthesta-tusreportasaparameter.Inordertodoso,itadaptstoFIPAQuery(FoundationforIntelligentPhysicalAgents,2000b)interactionprotocol.Thisserializa-tionisprovidedbythesupplier.Thefollowingex-cerptsoftheserializationdonotcapturetheentireprotocol,butsomepivotalpoints.Usingourontol-ogy,descriptionoftheinteractionprotocolclassisasfollows:

3

rdf:resource=\"&this;contractor\"/>rdf:resource=\"&this;supplier\"/>rdf:resource=\"&this;queryProgress\"/>

Theabbreviation&ip;referstotheip-namespacecontainingtheinteractionprotocolontology.TheinteractionprotocolclassIPcontainspropertiescalledhasInitiator,hasParticipant,andhasProgress,whichareinthisserializationgivenvaluesdenotingtoRDF-descriptionsappearinginthesamefile.Theagentstakingpartintheprotocolaredefinedinthefollowingway:

Theagentshavetocomprehendtheinteractionpro-tocolontologyinorderfortheadaptationoftheindi-vidualprotocoldescriptionstotakeplace.Forexam-ple,theagentshavetounderstandthebasicdifferencebetweentheInitiatorandtheParticipant,i.e.,thatitistheInitiatorthatstartstheproto-colbysendingthefirstmessage.DefinitionofthequeryProgressclassisserializedasfollows:

rdf:about=\"&this;queryProgress\">

rdf:resource=\"&this;replySupplier\"/>

Ofthethreestatesofthisprotocol,startandendarefoundineveryprotocolinstanceandknowl-edgeoftheirsemanticsispresupposedoftheagentsadaptingtotheprotocoldescriptions.Theagenthastoknow,forexample,thatthefirststateoftheproto-colisstart.Belowareserializedtwoofthesethreestates,namelystartandreplySupplier.

rdf:about=\"&this;replySupplier\">

rdf:resource=\"&this;sendSupplInform\"/>rdf:resource=\"&this;sendSupplFailure\"/>

4

Everystatehasoneormoreoptions.Thesearedenotedbyip:choicestags.TheonlyoptionofstartissendDelivQuery,whilereplySupplierhastwooptions.Theactualchoicebetweenthesedependsonthesuccessofthesupplier’sabilitytoanswertothequery.Movingon,theoptionshavetheirownserializations,whichcontainthepossiblemessagestobesent,aswellasthetargetstatesfortheprotocoltoshiftto.Be-lowaretwooptions,namelysendDelivQueryre-sultingfromtheactivationofthestartstateandsendSupplInformresultingfromthepositivere-sponsebythesuppliertotheinitialquery.

rdf:about=\"&this;sendDelivQuery\">

rdf:resource=\"&this;delivqueryRef\"/>rdf:resource=\"&this;replySupplier\"/>

rdf:about=\"&this;sendSupplInform\">

rdf:resource=\"&this;supplInform\"/>

Thetargetstateisdenotedbytheip:followstag.Forexample,sendDelivQueryhastheabove-serializedreplySupplierasitstargetstate.Italsoentertainsonemessage,namelydelivQueryRef,whichispresentedbelow.sendSupplInform,instead,hasendasitstargetstate,andsupplInformasthemessageassociatedwithit.Themessageserializationscontaintheinfor-mationonwhosendsandwhoreceivesthemessages,aswellasreferencestothepossiblemessagecontents.

rdf:about=\"&this;delivqueryRef\">

rdf:resource=\"&this;queryContent\"/>

Theabovemessagedefinitionscontainthesendersandthereceiversofthemessages,denotedbythere-spectivesendByandrecvBytags.Additionally,anewnamespacecalledfipaisintroduced.Itde-notesalocationcontainingtheFIPAextensiontothe

If the original directive implicated an󰀀action performed by the agent itself,󰀀such as \"May I open the door?\agent does not continue to wait after󰀀a non-directive message such as \"Yes\but instead moves on to the next state.󰀀[State == END]󰀀[State != END]󰀀Get options󰀀Decide from options󰀀Get next state󰀀Execute an option󰀀[directive]󰀀[non-communicative]󰀀[non-directive]󰀀[to self]󰀀[communicative]󰀀[non-directive]󰀀[message received]󰀀[to others]󰀀Wait for an answer󰀀[directive]󰀀Send message󰀀Figure3:Flowofaprotocolfromtheinitiator’spointofview

interactionprotocolontology,whichisdescribedindetailin(ToivonenandHelin,2004).AmongotherthingsspecifictoFIPAACL(FoundationforIntel-ligentPhysicalAgents,2000a),theextensionallowsexpressingmessagecontents.BelowisserializedthequeryContentclass,whichexpressesthethingtobequeried,inthiscasetheIDofthedeliveryreport.

String

ORDER_ID=\"http://www.sscompany.com/\"

+\"orderReports#steelOrd123\";

Stringquery=\"SELECT?x\"+\"WHERE(?y,,\"+\"),\"

+\"(?y,,?x)\"+\"AND(?yeq<\"+ORDER_ID+\">)\"+\"USING\"+nameSpaces;

scribedinthesimilarmannerasthequeryandnotincludedhere.Eventually,oncethecontractorhasre-ceivedthedeliveryreport,itcancomparetheinforma-tioninitwiththeinformationintheoriginalstatusre-portreceivedfromthesubcontractor.Shouldthetworeportscontainconflictinginformation,itcantakeappropriateactions(seeFigure1).Softwareagentscouldtakepartinperformingthecomparison,forex-amplebynotifyingtheirowneraboutmismatchesbe-tweenthereports.However,consideringthesedetailsisoutsidethescopeofthispaper.

3.3

AdaptingtoInteractionProtocolDescriptions

Themessagecontentisexpressedinsidethefipa:expressiontag.ThisphraseexpressestheRDQL(Seaborne,2002)queryforadeliveryID(?x)withtheorderID(?y)astheparameter.OrderID,asdepictedinFigure1,isfoundintheinitialstatusre-portreceivedfromthesubcontractor.Hereweassumethattheagentsshareasupplychainreportsontology,denotedbythereportnamespace,whichcapturesthegeneralstructuresoforderanddeliveryreports.Forexample,thecontractorknowsthattheorderre-portcancontaininformationaboutthedeliveryandtherebyhasreasontoperformtheabovequery.

WiththedeliveryIDthatthecontractorreceivesasareplytotheabovequeryitproceedstorequestthedeliveryreportfromthecarrier.Theprotocolisde-

Theonlyagentadaptingtotheinteractionprotocoldescriptionsintheabovescenarioisthecontractor’sexpeditor.Otheragentsofthescenariohaveknowl-edgeoftheinteractionprotocolsbeforehand.Fig-ure3depictshowaprotocolprogresses.Knowledgeofstartandendstatesisassumedtobeknownbyev-eryagent—alsobytheadaptableexpeditor—asmen-tionedabove.Beingtheinitiatoroftheprotocol,theexpeditorfirstsearchesforthestartstate.Fromthatstateitextractsdifferentoptions.Basedonitscur-rentgoals,itchoosesoneoptionandexecutesit.Notethatagents’goalshavingeffectonthedecisionareexcludedfrominteractionprotocoldescriptions.

Executinganoptionthatdoesnotentailmessagesendingiscalledanon-communicativeoption.Acommunicativeoption,instead,entailssendingames-sage.Ifsuchmessageisdirective,thesenderofthatmessageexpectsareplytothatmessage.Addition-ally,withdirectivemessagesthesenderaimstogetthereceivertodosomething,suchasperformanac-

5

tionoransweraquestion(withtheexceptionofdirec-tives“directed”tooneself).AsanexampleconsiderFIPARequest;aftersendingtherequestmessagetheinitiatorwaitsforananswertoitfromthepartici-pantbeforetheprotocolshiftstothenextstate.Foranon-directivemessage,instead,therearenoanswersandtheprotocolmovesimmediatelytothenextstate.ExamplesarealltheothermessagesinFIPARequest,namelyrefuse,agree,failure,andinform.Unlikeagree,allothernon-directivemessagesinFIPARequestprotocolarefollowedbytheendstate.Instead,agreeisfollowedbytheonewhere(aftertryingtoperformtherequestedactionandbasedonitsresults)theparticipantsendstheappropriatemessagetotheinitiator.NotethatexcludedfromFigure3arecancelingandexceptionhandlingmechanisms.Anagentparticipatinginaprotocolhasthepossibilityofcancelingtheprotocolatanypoint.Also,exceptionscanariseatanypointoftheprotocol.

Contractor’sexpeditoragentisabletoadaptitsbehaviortoconformtotheinteractionprotocolsde-scribedandprovidedbyotherprocessparticipantsbycombiningthefollowinginformation:Knowledgeoftheinteractionprotocolontology;knowledgeoftheflowofaprotocolasdepictedinFigure3;knowl-edgeofutilizeddomainontologiessuchastheabove-mentionedsupplychainreportsontology.

4CONCLUSION

Inthispaperweconsideredapplyingadaptableagentsinanexpeditingprocessofadistributedcon-structionproject.Inourscenarioasoftwareagentrep-resentingacontractoractedasanexpeditor.Ithadtheintentionofcontactingotherprojectparticipantsdirectlyforverifyinginformationinastatusreportre-ceivedearlierfromthesubcontractor.

Sincetheexpeditoragentdidnotknowinadvancehowtointeractwithotherprojectparticipants,itadaptedtointeractionprotocoldescriptionsprovidedbythem.TheseinteractionprotocoldescriptionswereserializedinRDF,andfollowedaninteractionpro-tocolontology.Suchsharedontologyspecifyingthegeneralstructureofconversationsbetweentheagentsbringsflexibilityinmulti-agentsystems.Solongastheagentsareawareoftheontology,modifyingex-istingprotocolsorlaunchingnewonesisstraightfor-ward.Notethatourintentionwasnottocontentu-allysolveproblemsrelatedtoexpeditingprocesses,butinsteadtopresentanapplicationareaforagentsadaptingtointeractionprotocoldescriptions.

Ourfutureworkaroundtheareaincludesfurtherdevelopingfunctionalitiesoftheagents.Progressofaninteractionprotocolcouldbemoredependentonthecontentsofthemessagesthanitisatthemo-

6

ment.Theagentscouldalsohavethefunctionalityofcomposingprotocoldescriptionsthemselvesandstor-ingtheminRDF.Atthemomentthedescriptionsarehand-writtenbyhumans.Inaddition,weareplanningonapplyingsoftwareagentsadaptingtointeractionprotocoldescriptionsinwirelessnetworks.Insuchnetworks,shouldalltheclientdevicesentertainanagentcapableofadaptingtointeractionprotocolde-scriptions,theclientdevicescouldinformtheserverabouttheircapabilities(screensizes,memorycapac-ities,etc.),connectiontypes(WLAN,GPRS,Blue-tooth,etc.),aswellasuserprofilesandcontextualde-tails.Theserversideagentcouldprovidethemwithappropriateinteractionprotocoldescriptionsforcon-nectingwiththeservices.

REFERENCES

Barrie,D.andPaulson,B.C.(1992).Professional

ConstructionManagement:includingC.M.,design-construct,andgeneralcontracting.McGraw-Hill,Inc,NewYork.

FoundationforIntelligentPhysicalAgents(2000a).FIPA

ACLMessageStructureSpecification.Geneva,Switzerland.SpecificationnumberXC00061.

FoundationforIntelligentPhysicalAgents(2000b).FIPA

QueryInteractionProtocolSpecification.Geneva,Switzerland.SpecificationnumberXC00027.

FoundationforIntelligentPhysicalAgents(2000c).FIPA

RequestInteractionProtocolSpecification.Geneva,Switzerland.SpecificationnumberXC00026.

Kim,K.etal.(2000).Compensatorynegotiationforagent-basedprojectschedulecoordination.InProceedingsofTheFourthInternationalConferenceonMultiagentSystems(ICMAS-2000),pages405–406.IEEECom-puterSocietyPress.

Lassila,O.andSwick,R.(1999).ResourceDe-scriptionFramework(RDF)ModelandSyn-taxSpecification.W3C.Availableat:

http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/.

Lee,H.etal.(1997).Thebullwhipeffectinsupplychains.

SloanManagementReview,38(3):93–102.Seaborne,A.(2002).JenaTutorial:AProgram-mer’sIntroductiontoRDQL.Availableat:

http://www.hpl.hp.com/semweb/doc/tutorial/RDQL/.Toivonen,S.andHelin,H.(2004).Representinginterac-tionprotocolsinDAML.InvanElst,L.,Dignum,V.,andAbecker,A.,editors,Agent-MediatedKnowl-edgeManagement:SelectedPapersfromAAAI2003SpringSymposium,volume2926ofLectureNotesinArtificialIntelligence,pages310–321,Berlin,Ger-many.Springer.

Williams,G.(1995).Fasttrackprosandcons:Considera-tionsforindustrialprojects.JournalofManagementInEngineering,11(5):24–32.