Dynamic electronic institutions in agent oriented cloud robotic systems

17 Pages·2017·3.33 MB·English

Dynamic electronic institutions in agent oriented cloud
robotic systems
Vineet Nagrath, Olivier Morel, Aamir Malik, Naufal Saad, Fabrice Meriaudeau
To cite this version:
Vineet Nagrath, Olivier Morel, Aamir Malik, Naufal Saad, Fabrice Meriaudeau. Dynamic electronic
institutions in agent oriented cloud robotic systems. SpringerPlus, 2015, 8, pp.3 - 3. ￿10.1186/s40064-
015-0810-4￿. ￿hal-01457943￿
HAL Id: hal-01457943
https://hal.archives-ouvertes.fr/hal-01457943
Submitted on 9 Feb 2017
HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est
archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.
Nagrathetal.SpringerPlus (2015) 4:103
DOI10.1186/s40064-015-0810-4
a SpringerOpen Journal
METHODOLOGY OpenAccess
Dynamic electronic institutions in agent
oriented cloud robotic systems
VineetNagrath1*,OlivierMorel1,AamirMalik2,NaufalSaad2andFabriceMeriaudeau1
Abstract
Thedot-combubbleburstedintheyear2000followedbyaswiftmovementtowardsresourcevirtualizationand
cloudcomputingbusinessmodel.Cloudcomputingemergednotasnewformofcomputingornetworktechnology
butamereremouldingofexistingtechnologiestosuitanewbusinessmodel.Cloudroboticsisunderstoodas
adaptationofcloudcomputingideasforroboticapplications.Currenteffortsincloudroboticsstressupondeveloping
robotsthatutilizecomputingandserviceinfrastructureofthecloud,withoutdebatingontheunderlyingbusiness
model.HTM5isanOMG’sMDAbasedMeta-modelforagentorienteddevelopmentofcloudroboticsystems.The
trade-viewofHTM5promotespeer-to-peertradeamongstsoftwareagents.HTM5agentsrepresentvariouscloud
entitiesandimplementtheirbusinesslogiconcloudinteractions.Tradeinapeer-to-peercloudroboticsystemis
basedonrelationshipsandcontractsamongstseveralagentsubsets.ElectronicInstitutionsareassociationsof
heterogeneousintelligentagentswhichinteractwitheachotherfollowingpredefinednorms.InDynamicElectronic
Institutions,theprocessofformation,reformationanddissolutionofinstitutionsisautomatedleadingtoruntime
adaptationsingroupsofagents.DEIsinagentorientedcloudroboticecosystemsbringorderandgroupintellect.This
articlepresentsDEIimplementationsthroughHTM5methodology.
Keywords: Dynamicelectronicinstitutions;Cloudrobotics;Modeldrivenengineering;Cloudcomputing;
Peer-to-peersystem;Businessmodel
Introduction believe that this second kind of adaptation will require
Anotetopractitioners special tools and development methodologies. Cloud
Cloud computing is a business model for the internet. robotic entities include all robotic and non-robotic
A typical scenario of cloud computing has a serving entities that collectively build a cloud robotic service
party that offers its infrastructure, platform or software ecosystem. Using software agents to represent cloud
resources to one or many clients across the network robotic entities will require minimal changes in the way
cloud.Cloudservicebusinesseschargetheirclientsbased those entities are independently developed by various
on the quality and volume parameters chosen as and vendors. Agents are also ideal for implementing social
when required by the client. Service contracts, banking and business concerns of a cloud robotic entity. HTM5
and administrative mechanism created the trust envelop (5ViewHyperactiveTransactionMetaModel)isa5-view
that made cloud computing business model a success. meta-model for model driven development of agent ori-
Whenwemovetheideasofcloudcomputingtorobotics, ented cloud robotic systems. The trade view of HTM5
there are two kinds of adaptations that will take place. promotes peer-to-peer exchange of services based on
The firstkind of adaptation willinvolve directmodifica- relationshipsandcontractsbetweenparticipatingagents.
tion of cloud services to suit robotic applications while Agents are autonomous entities with personal goals that
thesecondkindofadaptationwillbeonthelinesofsocial may make them greedy in their interactions with other
and business ideas represented by cloud computing. We agents. Dynamic Electronic Institutions are modelled on
theideasofInstitutionsinHumansocieties.Normsbased
on trade contracts, social relationships and institutions
*Correspondence:[email protected]
1LaboratoireLe2i,UMRCNRS6306,LeCreusot71200,France bringasenseoforderinmultiagentsystems.Theaimof
Fulllistofauthorinformationisavailableattheendofthearticle
©2015Nagrathetal.;licenseeSpringer.ThisisanOpenAccessarticledistributedunderthetermsoftheCreativeCommons
AttributionLicense(http://creativecommons.org/licenses/by/4.0),whichpermitsunrestricteduse,distribution,andreproduction
inanymedium,providedtheoriginalworkisproperlycredited.
Nagrathetal.SpringerPlus (2015) 4:103 Page2of16
thisarticleis totestfeasibilityofHTM5methodologyin Developmentofcloudroboticsasabusinessmodelwill
implementingDynamicElectronicInstitutions. require new tools and methodologies. It is essential to
developmethodologiesthatareindustryandbusinessori-
Background ented. The cloud robotic methodologies should go one
Cloud computing is a relatively new business model for stepfurthertoincludemodels thatincorporateconcepts
the Internet. NIST (National Institute of Standards and like Distributed Artificial Intelligence (DAI) (Stone and
Technology- United States) defines cloud computing as Veloso 2000), registry based service discovery and auto-
"a pay-per-use model for enabling available, convenient, mated matchmaking mechanism. Many of the services
on-demand network access to a shared pool of config- offered by a robot to other robots will have a physical
urable computing resources that can be rapidly provi- worldcomponent.Arobot’sphysicalreachwilldetermine
sioned and released with minimal management effort or the scope of the physical services offered by it and any
service provider interaction." Cloud computing does not business model for a robotic ecosystem should include
introducesanewcomputingornetworktechnologybutas provisions to model factors that codify physical world
a business model it remoulds the way existing technolo- interactions.A cloud roboticecosystemwillalso include
giesareused.Decreasingcostofinternetconnectivityand many non-robotic entities. These entities could range
cheaper internet enabled devices has further improved fromambient intelligence to serverbanks. In theoryany
the feasibility of cloud computing as a business model. device that can communicate through a network could
Roboticresearchersandengineerssoonrealizedtheben- be included as a working component of a cloud robotic
efitsofcloudcomputinginrobotics.Cloudbasedstorage system. The communication networks that collectively
andprocessingexpandedfunctionalitieswhilecarryinga build the cloud could be of different kinds and visible
minimal set of hardware on-board. Emergence of cloud in selective physical regions. A methodology that allows
roboticsfromcloud computing canbe seen as atwofold modelling of these non-robotic devices, networks and
development. The more visible development is direct interfaceswillgiveacompletedesigntoolsettodesigners
modification of current cloud based services for robotic of cloud robotic systems. Figure 1 shows a typical cloud
applications.Cloudroboticsisacomprehensivetermused robotic ecosystem with robotic and non-robotic enti-
to describe infrastructure, platform or software as a ser- ties. A design methodology for cloud robotic ecosystem
vice for robots, internet enabled robotics, utilisation of should provide tools to model all physical and theoreti-
searchenginesbyrobotsanduseofinternetforcommu- calaspects of thesesystems. Key theoreticalelements of
nicationbetweenrobots.Thesedevelopmentsaremaking acloudroboticecosystemwouldbeitsnetworkstructure,
animpact inthe wayroboticsystemsaredesignedusing event driven behaviour, social interactions, norm driven
cloudbasedtoolsbutnotmuchisdonetowardsdevelop- peer-to-peertrade,microlevelcompetitionsanddynami-
ingcloudroboticsasabusinessmodel. callyregulatingcollaboration(Weiss1999).Ausableagent
Figure1Robotic,non-roboticandnetworkelementsofatypicalcloudroboticecosystem.
Nagrathetal.SpringerPlus (2015) 4:103 Page3of16
oriented cloud robotic methodology could concentrate more important at initial stages of development. More
only onthe implementational designaspectsand system than one models for the same system may be made
requirement capture. The reasonwhya metamodel with to separate system concerns. These multiple models are
tools to include DAI is useful is because as the systems called views of the system and the practice is known as
becomemorerobustandextensive,itwillrequiremech- multi-view methodology (Finkelstein et al. 1992). Soft-
anismtoimplement some levelofintelligence. Theoreti- ware Product Line Engineering (SPLE) (Clements and
callysuchintelligencecanbeimplementedattherunning Northrop 2001; Pohl et al. 2005; Weiss and Lai 1999) is
code level irrespectiveof the methodology used to envi- an encouraged practice in software industry to produce
sion the system. The decision to include DAI friendly reusable system components and models. Methodolo-
elements in all three layers of the design (computation gieswhichcomplywithOMG-MDAandSPLEstandards
independent,platformindependentandplatformspecific have higher industrial acceptance. OMG-MDA has a
layers)makesthesystemmoresuitableforresearchersas three layer architecture where layers vary in their level
well as engineers who will develop the DAI concepts on of abstraction and target audience. Figure 2 shows the
agentorientedcloudroboticsystem. three layers of a typical OMG-MDA meta-model with
Anagentorientedapproachtowardscloudroboticshas ComputationIndependent (CIM),Platform Independent
some distinct advantages. A typical cloud robotic entity (PIM) and Platform Specific (PSM) models at different
willhaveamanufacturerwithapersonalizeddevelopment layers.ComputationIndependent, PlatformIndependent
methodology for its product. The manufacturer would and Platform Specific layers of OMG-MDA cater to dif-
typically like to hide the internal designs of its prod- ferentstakeholdersinthedevelopmentlifecycle.Compu-
uct and thus the business that deploys that entity may tationIndependentorPlatformIndependentmodelsmay
havelimitedornoaccesstotheinternalsoftwareframe- besupportedbyaDomainSpecificlanguageofsamelayer
work of the entity. The business will also want to keep abstraction. The Domain Specific Language can be exe-
itsbusinesslogichiddenfromtheoutsideworldandeven cutedtogenerateautomatedModeltoModelandModel
from sections of their own workforce. “Software Agents ToText(Code)transformations.ADomainSpecificLan-
arecomputationalentitieswithspecificrolesandpersonal guage(DSL)isoftenbuilttosupportaMeta-model.Code
objectives working in a visible environment with other writteninaDSLis used to codifydesignsin aprogram-
entities which may have dissimilar roles and objectives” ming language that has a domain specific syntax based
(Jennings and Bussmann 2003). Using a software agent onaparticularMeta-model.DSLcodecanbemadeexe-
to represent cloud entities does not interfere with man- cutable bywritingcompiler functions togenerate Model
ufacturer’s development methodology.Agents are closed toModelandModeltoTexttransformations.Thesetrans-
autonomous systems that have an internal logic frame- formationsareessentialastheyallowanewMeta-model
workthatcommunicateswiththeoutsideworldviames- tobetranslatedintoexistingModels/Languages.
sages.Unlikeobjects inan objectoriented methodology, The 5-view Hyperactive Transaction Meta-Model
Agents do not release details of their functionalities and (HTM5) is a domain specific Meta-model for agent ori-
do notallow directexecutionoftheirfunctions byother ented development of cloud robotic systems. HTM5 is
agents. Agents thus are by design ideal for implement- based onOMG-MDAand hastheprescribedthreelayer
ing a secure business logic. Multi-agent systems (Luck architecture as shown in Figure 2. The 5 views and
et al. 2003, 2005; Wooldridge 2002) are also ideal for 4 hyperactivity sub-views in HTM5 (Figure 3) separate
implementingintelligentconceptslikeDistributedArtifi- view-specific concerns in all three layers. The Platform
cialIntelligence(DAI)(StoneandVeloso2000)anddigital independent and platform specific layers of HTM5 are
businessecosystem(DiscussedinSection 2, 2).Anagent componentlevellayersandaredevelopedintwophases.
based approach is idea for systems with dynamic partic- The first phase creates class component templates for
ipation of entities in an open (Hungate and Gray 1995) individual agent components which are then developed
peer-to-peerserviceexchange. byvariousentitymanufacturersinsecondphaseofdevel-
Object Management Group’s Model Driven Architec- opment. HTM5 also has a Machine Descriptor Model
ture (OMG-MDA)(OMG 2003) is a prevalent industrial (HTM5-MDM) that models machine (host hardware or
standard for development of software Meta-models for softwareentity)representedbyanagentcomponent.Top-
complicatedsystems.Amodelisasetofvalidcomments most layer in HTM5 has a set of Computation Inde-
about a system and a Meta-model is a set of valid com- pendent graphical models named Agent Relation Charts
ments about a model (Seidewitz 2003). Model Driven (ARCs).ThetermHyperactivityinHTM5correspondsto
Engineering (MDE) develops system models with high provisionsthatallowdeviationsfromidealAgencyasand
level of abstraction, without much emphasis on imple- whenrequired.Hyperactivitymaybeusedtogivecertain
mentational details. MDE is ideal for Systems where the Agents, an object like characteristics by releasing their
overall idea of a system (and not its implementation) is autonomy for specific associated Agents. HTM5 follows
Nagrathetal.SpringerPlus (2015) 4:103 Page4of16
Figure2Objectmanagementgroup’smodeldrivenarchitecture(OMG-MDA)(OMG2003).
multi-viewmeta-modellingmethodologyandhas5separate multi view model it is essential that the designer should
viewstocapturestructural,relational,trade,hyperactivity have a clear idea about the scope of a particular view.
and behavioural elements of the design. Some compo- TradeviewofHTM5is formodelingthetrade logic ina
nents of HTM5 Meta-model were introduced in earlier cloudroboticecosystem.HTM5proposesaPeer-to-peer
publications(Nagrathetal.2013a,2013b).Thetrade-view service oriented trade mechanism managed by Relation
ofHTM5promotespeer-to-peertradeamongstsoftware agents.Forasystemdesigner,itisimportanttospecifythe
agents. HTM5 agents represent various cloud entities norms and default trade relationships in a cloud robotic
andimplementtheirbusinesslogiconcloudinteractions. system. Agent transactions in cloud robotic systems fol-
Tradeinapeer-to-peercloudroboticsystemisbasedon lowthecloudcomputingbusinesslogic,butunlikecurrent
relationshipsandcontractsamongstseveralagentsubsets. cloud robotic systems, these transactions are driven by
DynamicElectronicInstitutions(Section 2)aremodelled decentralized Relationagents. The Trade viewof HTM5
on the ideas of Institutions in Human societies. Norms targets to capture the following design elements of an
basedontradecontracts,socialrelationshipsandinstitu- agentorientedcloudroboticecosystem:
tions bring a sense of order in multi agent systems. The
1. NamesandRelativeLocationsofthefollowing
aimofthis articleis to testfeasibilityof HTM5method-
Tradeelementsinacloudroboticecosystem.
ology in implementing Dynamic Electronic Institutions.
Forthebenefitofthereader,wewillelaborate aspectsof (a) Components(Agent,RelationorMerge)that
HTM5relevanttothesubjectmatterofthecurrentarticle. areinvolvedinTrade.
A view by definition is a representation of the system (b) ItemsinTrade.
with concerns specific to a particular stakeholder. In a (c) DataentitiesassociatedwithTradeitems.
Nagrathetal.SpringerPlus (2015) 4:103 Page5of16
Figure3Anoverviewof5viewshyperactivetransactionmetamodel(HTM5)foragentorienteddevelopmentofcloudroboticsystems.
2. ThefollowingInformationabouttheaboveentities: (i) IsitaLookuptable?
(ii) Isitacostmetric?
(a) AssociationsbetweenTradeitemsand
(iii) Isitamanagementvariable?
Components.
3. FollowingFunctionalitiesshouldexclusivelygoin
(b) NatureofassociationbetweenaTradeitem
theRelationalviewclassesofvariouscomponents:
andaComponent:
(a) Localization:Locatingone’spositionin
(i) ItemisaDemandbyaComponent.
differenttransactions.
(ii) ItemisaServiceprovidedbya
(b) Identifyingrelationshipsassociatedwitha
Component.
particulartradeitem.
(c) Implementingrelationshipnormsassociated
(c) EntitiesassociatedwithaTradeitem:
withatradeitem.
(d) ImplementationofBusinesslogicofa
(i) Componentsthatprovidetheitemas
Component(Functionalityrelatedtobusiness
aservice.
concernsofaparticularHTM5Component).
(ii) Componentswhichdemandtheitem.
(e) ImplementationofBusinesslogicofthe
(iii) Dataentitieswhichareassociated
system(Functionalityrelatedtobusiness
withTradeoftheitem.
concernsofthecloudroboticsystem).
(iv) TheComponents(Generally
(f) Calculatingreadjustmentsinrelationship
Relations)thatarehostingand
normsbasedonbusinesslogic.
managingthosedataentities.
(g) Communicatingdesiredreadjustmentsto
(d) NatureofvariousDataentities: relationalviewclasses.
Nagrathetal.SpringerPlus (2015) 4:103 Page6of16
(h) Maintainingdataentitiesassociatedwitha governedbyasetofnorms,buttrustbetweenagents
tradeitem. mayplayapartinthecoalitionformationphase.Any
(i) Readingandupdatingofremotelyhosteddata logicthatgovernscoalitionformationbetweenaset
entitiesassociatedwithatradeitem. ofagentsistheirFormationlogic.
(cid:129)
(j) GeneratingtriggersforTradeHyperactivity Re-Formation:Re-formationistheprocessof
sub-viewclass.(Initiation,managementor reconfiguringacoalition.Areformationmaybe
finalizationofaHyperactivelink). triggeredbychangeincoalitionmembershipora
changeinparametersresponsibleforcoalition
Dynamicelectronicinstitutions formation.
(cid:129)
Humansocietiesareamalgamationofseveralnormbased Foundation:Thememberagentsinacoalitionchoose
institutionsthatgiveordertootherwiserandominterac- acandidateInstitutiontoform.Thenormsofthe
tions.Institutions are structures based on mutual incen- candidateinstitutionarebasedoncollectiveviewsof
tives based on predefined contracts. Social, Politicaland individualmembersofthecoalition.Oncethetarget
economic institutions represents the norms of a soci- institutionisselected,thecoalitiongoesthrough
ety and interactions of its members. Institutes establish institutionalizationtoformaninstituteofthe
standardizationinresponsefromamemberentitywhich selectedtype.Thissteppresentsalotofchallengesas
in absence of an institution is free to act solely for its selectionofthekindofinstitutionandmaintenance
own benefit. Institution helps in controlling the greed- ofinstitution-baserequiresawell-definedstrategy.In
iness of individual entities and brings order to a sys- theory,anystrategythatassignsaninstitutetoa
tem (North 1996). Electronic Institutions are a relatively groupofagents(basedontheircollectivedecision
new field where the concept of human institutions is parameters)qualifiesasaFoundationLogic.
(cid:129)
extendedtoMultiAgentSystems(MAS)(Lucketal.2003, Re-Foundation:Re-foundationistheprocessof
2005;Wooldridge2002)andDistributedArtificialIntelli- reconfiguringaninstitution.Areconfigurationmay
gence(DAI)(StoneandVeloso2000).Someearlyattempts betriggeredbyachangeinenvironmentvariablesor
towards the use of organizational metaphors for system afoundation-timeoutvaluesetbyFoundationlogic
modellingsystemswerepresentedin(Pattisonetal.1987; (atthetimeofinstitutionfoundation).
(cid:129)
Werner1989).Thefirstapproachtowardselectronicinsti- Fulfilment:Thememberagentsinaninstitute
tutions was given in (Noriega 1999) where an abstract dissolveintoindividualfreeagentswhentheinstitute
notion agent-mediated electronic institution was intro- completesallitsobjectives.Aninstitutemayalso
duced forthefirsttime. Theseinstitutions aredescribed fulfilwhentriggeredbyafulfilment-timeoutvalueset
as environments where agents are interacting withother byFoundationlogic(atthetimeofinstitution
agents under predefined restrictions. An institution is foundation).Likefoundation,fulfilmentisalsoa
specified by a set of pre-defined norms that restrict challenginglogictodevice.Thedecisionmaybe
actions of its member agents. The idea of an electronic basedonweightedpercentageofcollectivegoalsof
institution is very open and various groups (Aldewereld memberagents,ortimeelapsedsinceinstitution
et al. 2005; Dignum 2004; López ) are working on this foundation/re-foundation.Fulfilmentlogicis
problem with different perspectives. Electronic institu- usuallydevisedatfoundationstatewhentheinstitute
tions require limited human intervention for institution candidateisselectedbyFoundationlogic.
design phase. In open agent systems, it is necessary to
automatethedesignphaseofinstitutions.
ThetermDynamicElectronicInstitutionsfirstappeared Dynamicelectronicinstitutionsincloudrobotics
in the roadmap for agent technology (Luck et al. 2003). There are many application domains where Dynamic
Dynamic Electronic Institutions are Electronic Institu- Electronic Institutions (DEIs) are applicable. In agent
tions where formation, reformation and dissolution of oriented cloud robotics, DEIs are applicable in tasks
institutions are automated processes. The norms and involving a contract based cooperation amongst ad-
objectives of institutionalization are dynamically adapt- hoc teams. Collaboration between agents which were
ing to the needs of its member agents. Figure 4 shows not originally programmed to work together is exam-
the 3-F life cycle of an institution proposed in recent ples of Ad-Hoc teams. Common scenarios where DEIs
works(Muntaner-PerichandRosaEsteva2007; 2008).Re- are used are Ad-Hoc mobile networks, B2B (Business
FormationandRe-Foundationprocessesarealsoincorpo- to Business) electronic commerce and OOTW (opera-
ratedinthe3-Flifecycle. tions other than war) scenario. For the current article
we will concentrate on B2B electronic commerce as a
(cid:129)
Formation:Agentswithsimilarobjectivescome scenario for agent oriented cloud robotic system. Fol-
togethertoformacoalition.Acoalitionisusuallynot lowing the 3F life cycle in B2B electronic commerce,
Nagrathetal.SpringerPlus (2015) 4:103 Page7of16
Figure43Flifecycleofadynamicelectronicinstitution.Thethreephasesareinorder:Formation,FoundationandFulfilment.Re-Formation
andRe-Foundationprocessesarealsowithinthe3Flifecycle.
followinganalogywasproposedby(Muntaner-Perichand anumberofcontributorswhichbuilduparesource(like
RosaEsteva2007,2008). algorithms and other internet resources) which is then
offered as a service to other entities through cloud. An
(cid:129)
ADigitalB2Belectroniccommerceecosystem:Agent open registry and matchmaking service allows peer-to-
Community peer trade of these services in cloud robotic ecosystem.
(cid:129)
ABusinessOpportunity:Coalition The network cloud itself may have many private and
(cid:129)
DigitalBusinessEcosystem(DBE):Dynamic public networks, some of which may be owned by busi-
Institution nesses that allows their use as a service. Banking super
agents (Agents with special access norms) allow actual
TheaimoftheDEIscenariomentionedaboveistofind transfer of money between agents. Other super agents
newopportunitiestoexchangeservicesamongstmember may be present to enforce law, quality, communication
agents.Formationofacoalitionrepresentsaviableservice and trade standard over the agent community. Develop-
exchange (a business opportunity). When the member mentlifecycleofcloudroboticproductsmaydifferfrom
agents agree upon a set of norms to execute the service vendor to vendor. Business model of organisations that
exchange,itisrepresentedasfoundationofaninstitution. deploy theseproductsmay also differ. Individual entities
Figure 5 shows an example where DBE is applied to an may enter or exit the ecosystem dynamically and their
agentorientedcloudroboticecosystem.Agentsareinde- behaviourmay changewithtime. Anapproachbased on
pendent software entities that represent a robotic/non- representative agents ensures that heterogeneity in busi-
roboticentityincloudroboticecosystem.Individualcloud ness logic, design methodology and implementation of
entitiesmay havedifferenthardwareand software setup. these products is respected. An approach based on rep-
Eachoftheseentitiesmayhaveabusinessownerandset resentative agents ensuresthatheterogeneity inbusiness
of offered services. Some online server banks may have logic, design methodology and implementation of these
Nagrathetal.SpringerPlus (2015) 4:103 Page8of16
Figure5Exampleofdigitalbusinessecosystem(DBE)inanagentorientedcloudroboticsenvironment.
products is respected. In a real life scenario, it may be domain. HTM5 (Nagrath et al. 2013a, 2013b) is OMG-
requiredtohaveaminimalhumaninvolvementinthe3F MDA (OMG 2003) based meta-model for development
lifecycle(seeFigure4).Aproposalby(Muntaner-Perich ofagentorientedpeer-to-peercloudroboticsystems(See
andRosaEsteva2007; 2008)advocatesa7steplifecycle Section 2).Themeta-modelisdesignedtoprovidetools
wherehumandecisionmakersareinvolvedattwostages to implement advance distributed Artificial Intelligence
to validate business opportunities detected by the DBE (DAI)designsinacloudroboticecosystem.Inthissection
system. we discuss the tools and anatomical elements of HTM5
Steps of the DBE lifecycle (Muntaner-Perich and Rosa thatare utilized toimplement aDigitalBusinessEcosys-
Esteva2007; 2008): tembasedonDynamicElectronicInstitution.
Figure 6 shows an example of a Dynamic Electronic
Institution with two institutions. The HTM5 methodol-
1. Searchofopportunities(FormationLogic)
ogyallowsforspecialagentscalledRelationsthatmaintain
2. Analysisofopportunitybybusinessowner
the relationshipsbetween groupsof agents in a relation-
(ValidationI,Optional)
ship. The sample project Sandbox is a Digital Business
3. Coalitionestablishment(Formationand
Ecosystemexample withtwo institutionseeds.Institutes
Re-FormationPhase,Re-formationwillrequire
(Relation Agents) manage trade within an institute and
re-validation)
hostserviceandcostlookuptablesalongwithothertrade
4. DBEselection(FoundationLogic)
data items. Social and business logic of an Institute is
5. Acceptationbybusinessowner(ValidationII,
implemented at relation agents. Detailed description of
Optional)
ARCs and HTM5 anatomy can be found at (Nagrath
6. DBEestablishment(FoundationandRe-Foundation
etal.2012,2013a,2013b).Theaboveexamplelocatesele-
Phase,Re-foundationwillrequirere-validation)
ments of Digital Business Ecosystem in a HTM5 based
7. DBEFinalization(FulfilmentPhase)
implementation. Section 2 of this article presents a
complete case study of DBE implemented using HTM5
DynamicelectronicinstitutionsinHTM5 methodology.
In the previous section we saw the steps in a DBE For the example shown in Figure 6, the relations are
lifecycle and its applicability in the cloud robotic designedtoactasInstitutionseeds.Noanatomicalchange
Nagrathetal.SpringerPlus (2015) 4:103 Page9of16
Figure6AnexampleofdynamicelectronicinstitutionsimplementedusingHTM5methodology.Aboveareagentrelationcharts
(ComputationindependentlayerofHTM5)forstructural,relationalandtradeviewsofHTM5.
is required in HTM5 to use HTM5 relation construct asInstitutions).TheTrade-AgentRelationChart(Trade-
as Institution seeds. An institution between groups of ARC) that defines the following trade relationships and
agents can be seen as a special kind of relationship. In dependenciesbetweenmembersofSandboxcloudrobotic
HTM5, the norms and relationship variables of a rela- ecosystem.
tionship are hosted and managed by the Relation agent.
When HTM5 is used to implement Dynamic Electronic 1. TradeSearchSpaceisaserviceprovidedbyTrader
Institutions,thevariables,formationandfoundationlogic toManagerandassignsasearchspaceinthemine
may be hosted in institution seeds (which are relation fortheManager.
agents). For ease of implementation, an institution may 2. TradeSubSearchSpaceisaserviceprovidedby
be implemented as two separate agents. In Figure 6, the ManagertoMinersandassignsasectionofthe
Manager agent along with InsA relation and M4 merge searchspace(allocatedtotheManager)totheMiner.
areallhostedatonemachine.Itispossibletoimplement 3. TradeSubSpaceHitisthenotificationservicefrom
thelogicofallthreecomponents(Manager,InsAandM4) theMineragentwhenitdetectsthetargetmineral.
ontooneagentbutseparationandplacementofmachine ThisserviceisademandatManageragent.
functionalities into agent, merge and relation specific 4. TradeInitialcoordinateslocatesthefoundmineral
parts is encouraged in HTM5. In Figure 6 Part I of the intheminefield.ThisserviceisademandatTrader
figureisafullARCdiagramoftheSandboxsystemwhile agent.
part II is its normalized version. There is multiple num- 5. TradeMinerSalaryisthepaymentthataMiner
bers of Miner and Trader agents in the system. Part III agentreceivesinexchangeoftheminerallocationsit
models trade dependenciesinSandbox cloudecosystem. deliverstotheTraderagent.Theserviceisademand
Peer-to-Peer trade relationships exists between mem- attheBankagentwhichtransferstheamountfrom
bers of a relationship (Here relationships are modelled Trader’stoMiner’saccount.