TuCSoN Coordination for MAS Situatedness: Towards a Methodology

TuCSoN Coordination for MAS SituatednessTowards a Methodology

Stefano Mariani, Andrea Omicini{s.mariani, andrea.omicini}@unibo.it

Dipartimento di Informatica – Scienza e Ingegneria (DISI)Alma Mater Studiorum—Universita di Bologna, Italy

Talk @ WOA 2014Workshop nazionale “Dagli Oggetti agli Agenti”

Universita di Catania, Italy26 Settembre 2014

Mariani, Omicini (DISI, UniBO) Situatedness in TuCSoN WOA 2014, 26/9/2014 1 / 45

Outline

1 Context, Motivation & Goals

2 Requirement Analysis: The TuCSoN Meta-model

3 Model & Design: The TuCSoN ArchitectureAgent SideEnvironment SideBetween agents and environment: Situated coordination

4 Implementation: ReSpecT API

5 Deployment: Smart Home Appliances Coordination

6 Conclusion


Context, Motivation & Goals

Outline



3 Model & Design: The TuCSoN Architecture



6 Conclusion



Context & Motivation

Situatedness in multi agent systems (MAS) amounts to beingsensitive to environment change, as well as affecting it in turn[Ferber and Muller, 1996]

This is the core of the notion of situated action, as those actionsarising from strict interaction with the environment [Suchman, 1987]

Thus, dependencies among agents and the environment are one of thesources of complexity within MAS—the other being socialdependencies, between agents’ activities [Malone and Crowston, 1994]

Situatedness & CoordinationCoordination, as the discipline of managing dependencies[Malone and Crowston, 1994], could then be used to deal with both social andsituated interaction.



Goals

We introduce the situated coordination approach promoted by theTuCSoN model and technology for coordination in MAS[Omicini and Zambonelli, 1999]

We describe how TuCSoN supports MAS programmers in eachmacro-stage of a typical MAS software engineering process

We sketch how to deploy a TuCSoN-coordinated situatedinfrastructure for smart home MAS coordination


Requirement Analysis: The TuCSoN Meta-model

Outline






6 Conclusion



The TuCSoN Meta-model I

Activities The goal-directed/oriented proceedings resulting into actions ofany sort, which “make things happen” in a MAS. Through actions,activities in a MAS are social [Castelfranchi, 1998] and situated[Suchman, 1987]. From the standpoint endorsed here, agents donot exist because they resemble some “real-world” entity; theyexist as the means through which activities can be modelled in aMAS—as a way to model actions along with their driving goals.

Environment change The (possibly unpredictable) variations in the properties orstructure of the world surrounding a MAS that affect it in anyway—thus, which the MAS needs to account for. Such variationsdo not express any specific goal, either because this does not exist,or because it is not to be / cannot be modelled in the MAS.Environment (change) can be modelled through the resourceabstraction, as a non-intelligent entity either continuouslyproducing events or reactively waiting for requests to perform itsfunction.



The TuCSoN Meta-model II

Dependencies Activities depend on other activities (social dependencies), as wellas on environment change (situated dependencies). Thus,dependencies motivate and cause interaction, both social andsituated, based on the sort of dependency taking place.

Events To provide a uniform representation of MAS dynamics, as well asto promote a coordination-oriented approach in modelling bothsocial and situated dependencies, both activities and environmentchanges are represented via events. Therefore, in TuCSoN, eventsreify any social and any situated interaction taking place withinthe MAS, driving the coordination process.



The TuCSoN Meta-model III

Summing up

MAS designers should think about the problem at hand in terms of

(i) a bunch of goal-directed/oriented activities (agents)

(ii) interacting with each other, influenced by / influencing some sort of

(iii) changes in their environment (resources), therefore

(iv) generating events which

(v) have to be properly coordinated


Model & Design: The TuCSoN Architecture

Outline






6 Conclusion



TuCSoN Architecture I



TuCSoN Architecture II

agents — Any computational entity willing to exploit TuCSoNcoordination services [Viroli and Omicini, 2006] is a TuCSoNagent. In order for agents to be recognised as coordinables[Ciancarini, 1996] by TuCSoN, they need to obtain an ACC,released by TuCSoN itself. Agents (interaction-oriented) activitiesresult into coordination operations, targeting the coordinationmedia (a tuple centre) actually handled by the ACC.

ACC — Agent Coordination Contexts [Omicini, 2002] are TuCSoNarchitectural components devoted to represent and mediate agentsactivities within the MAS. In particular, an ACC maps coordinationoperations (thus both social and situation actions) into events anddispatches them to tuple centres. ACCs preserve agent autonomy[Omicini, 2002]: while the ACC takes care of asynchronouslydispatching events, the agent is free to undertake other activities.This enables uncoupling in control, reference, space and time.



TuCSoN Architecture III

probes — Environmental resources in TuCSoN are called probes. Theycan be sources of perceptions (sensors), targets of actions(actuators), or both: TuCSoN models them in the same way, usingtransducers. In fact, as for agents with ACC, probes do notdirectly interact with the MAS, but through transducer mediation.

transducers — The architectural run-time components in charge ofrepresenting and mediating environment changes regarding probes[Casadei and Omicini, 2009]. Each probe is assigned a transducer,which is specialised to handle events to/from that probe. So,transducers translate (i) probes properties changes into events, tobe dispatched to tuple centres, and (ii) MAS events into propertieschanges, to be sensed/effected on probes.



TuCSoN Architecture IV

events — TuCSoN adopts ReSpecT [Omicini, 2007] event model,representing any sort of event happening in the MAS in a uniformway. TuCSoN events record: the immediate and primary cause ofthe event [Ricci et al., 2008], its outcome, who is the source of theevent, who is its target, when and where the event was generated.In this way, any event is situated both in space and time, as well aswithin its execution context. Thus, tuple centres can effectivelycoordinate events while accounting for the situated nature ofinteractions to its full extent.

tuple centres — ReSpecT tuple centres [Omicini and Denti, 2001] are TuCSoNarchitectural component mediating all interactions happening inthe MAS, thus in charge of handling events in order to resolvedependencies. By adopting ReSpecT tuple centres, TuCSoN relieson (i) the ReSpecT language to program coordination laws, and(ii) the ReSpecT situated event model to implement events.



TuCSoN Architecture V

Summing up

MAS designers should

(i) rely on ACC and therein defined primitives to interact with otherTuCSoN-coordinated entities

(ii) define transducers to represent the relevant portions of MASenvironment

(iii) program TuCSoN tuple centres through ReSpecT specifications tohandle TuCSoN events—therefore, to coordinate the MAS


Model & Design: The TuCSoN Architecture Agent Side

Outline






6 Conclusion



Interaction Overview

1 acquire an ACC

2 choose each operation invocation semantics

3 expect operations result to be available accordingly

4 release ACC when TuCSoN services are no longer needed



Synchronous Operation Invocation



Asynchronous Operation Invocation


Model & Design: The TuCSoN Architecture Environment Side

Outline






6 Conclusion



Interactions Overview

1 register probes causing their transducer instantiation

2 be aware that environmental events are always generatedasynchronously

3 deregister probes when they are no longer needed



Sensor Probe



Actuator Probe



Interactions Explained

1 (message 2.2) The transducer builds the event corresponding to theperception operation and dispatches it to the tuple centre target ofthe interaction

2 (messages 2.2.1− 2.2.2) The tuple centre enacts the coordinationprocess triggered by such event (if any), properly dispatching itsoutcome

Situatedness & Autonomy

There is no distinction between synchronous or asynchronous invocationsemantics. Being representations of environmental resources, probes arenot supposed to expect any feedback from the MAS: they simply cause /undergo changes that are relevant to the MAS. Thus, interactionssemantics is always asynchronous, preserving agents’ autonomy despitesituatedness of their actions.


Model & Design: The TuCSoN Architecture Between agents and environment: Situated coordination

Outline






6 Conclusion



Sensor Probe



Actuator Probe



Interactions Explained I

1 After event dispatching, the tuple centre target of the operation reacts bytriggering the ReSpecT reaction in annotation 1.1.1 (2.1.1), which generatesa situated event (step 1.1.2 / 2.1.2, respectively) aimed at executing asituation operation (getEnv(temp, T) / getEnv(temp, T)) on the probe(sensor / actuator)

2 The transducer associated to the tuple centre and responsible for the targetprobe intercepts such an event and takes care of actually executing theoperation on the probe (message 1.1.2.1 / 2.1.2.1)

3 The sensor probe reply (message 1.1.2.2 / 2.1.2.2) generates a sequence ofevents propagation terminating in the response to the original coordinationoperation issued by the agent (message 1.1.2.3.2.1 / 2.1.2.3.2.1)



Interactions Explained II

Supporting Situatedness

TuCSoN ACC and transducers play a central role in supportingdistribution and uncoupling of agents and probes within the MAS,providing for a general event-based model

TuCSoN tuple centres and the ReSpecT language are fundamental tosupport both situatedness via objective coordination[Schumacher, 2001, Omicini and Ossowski, 2003], encapsulating thelogics of event coordination


Implementation: ReSpecT API

Outline






6 Conclusion



ReSpecT Situated Event Model I

〈Event〉 ::= 〈StartCause〉 , 〈Cause〉 , 〈Evaluation〉〈StartCause〉 , 〈Cause〉 ::= 〈Activity〉 | 〈Change〉 , 〈Source〉 , 〈Target〉 ,

〈Time〉 , 〈Space:Place〉〈Source〉 , 〈Target〉 ::= 〈AgentId〉 | 〈TCId〉 | 〈ProbeId〉 | ⊥

〈Evaluation〉 ::= ⊥ | {〈Result〉}

event predicate 1(Term p) — makes it possible to inspect the〈Activity〉 | 〈Change〉 field of the event which directly caused(〈Cause〉) the triggering of the ReSpecT reaction. In the case ofour sensor probe, it unifies p with in(sense(temp(T))).



ReSpecT Situated Event Model II

event source 1(Term s) — makes the 〈Source〉 of the event observable—thatis, who caused event generation. In our case, it unifies s with the〈AgentId〉 of the agent issuing the coordination operation(message 1).

event target 1(Term t) — allows inspection of the 〈Target〉 field of theevent. In our case, it unifies t with the 〈TCId〉 of the tuple centretarget of the event (message 1.1).

event time 1(Term t) — makes the 〈Time〉 when the event was generatedobservable. In our case, it unifies t with the time at which theACC receives the coordination operation request (message 1).

event place 1(Term s, Term p) — allows the 〈Space:Place〉 field of theevent to be inspected, once the sort of space is chosen from apre-defined set of admissible spaces—either absolute physicalposition (s=ph), IP address (s=ip), domain name (s=dns),geographical location (s=map), organisational position (s=org). Inour case, it unifies p with, e.g., the network address of the agentwhich caused reaction triggering.


Deployment: Smart Home Appliances Coordination

Outline






6 Conclusion



Scenario

“Smart appliances” (e.g. smart fridge, smart thermostat, smartlights, smart A/C, etc.) are scattered in an indoor environment (e.g.a flat) [Denti, 2014]

Either inhabitants have an Android smartphone, or a desktop PC isavailable in the environment (or, both)

Some kind of connection is available at least between each applianceand the smartphone/desktop

The “smart home system” should self-manage toward a given goal(e.g. always optimise power consumption) according to userspreferences (e.g. prefer turning on fans rather than switching A/C on)



Requirements

Users continuously and unpredictably perform their daily activities. . .

. . . which may depend on the environment being in a certain “enablerstate” (e.g. food must be available to enable cooking dinner), as wellas may both impact and be affected by (other form of dependencies)the environment. . .

. . . causing some change to happen (e.g. since I’ll be late delay lightsturn on time, there is no food thus I must go to the grocery shop)

Meta-model mapping

Once activities and environment change are recognised as the (only)sources of events, managing their dependencies ultimately amounts tomanaging events, thus leading to a perfect match with TuCSoN referencemeta-model.



Design I

Users activities are generated by agents, making it possible to alsoascribe goals to actions, and mediated by ACCs, enabling andconstraining interactions according to the system goals

Changes in the environment are generated by probes and mediated bytransducers, enabling a uniform representation of environmentalproperties despite appliances heterogeneity

Both activities and changes (thus ACCs and transducers) generateevents as their own representation within the smart home MAS,which are then managed by tuple centres suitably programmed withadaptable coordination laws



Design II

Architecture mapping

So, in our smart home we have

agents deployed to users’ personal devices (smartphone/desktop pc)

probes deployed to home appliances

ACCs and transducers deployed either on-board along with agents andprobes, respectively (e.g. on the smartphone), or remotely (e.g. on thedesktop)

tuple centres deployed again either on board or remotely

all performing activities and enacting/undergoing changes generating events,automatically handled by TuCSoN according to designed coordination laws


Conclusion

Outline






6 Conclusion


Conclusion

Conclusion

Agent-oriented frameworks can be effective in the engineering ofcomplex distributed systems by providing a coherent framework forevent-driven programming—in particular when dealing withenvironment engineering in situated systems

Agent coordination models, typically exploited for governing socialinteraction, could extend their reach to deal with situated interaction,by providing suitable abstractions to handle all sources of change in aMAS – agents and environment – through a uniform event model

In this paper we describe the coordination-based approach to MASsituatedness as promoted by the TuCSoN middleware, by sketchingthe steps of an agent-oriented methodology from the TuCSoNmeta-model down to the TuCSoN programming environment, anddiscussing a smart home scenario


References

References I

Casadei, M. and Omicini, A. (2009).Situated tuple centres in ReSpecT.In Shin, S. Y., Ossowski, S., Menezes, R., and Viroli, M., editors, 24th Annual ACMSymposium on Applied Computing (SAC 2009), volume III, pages 1361–1368, Honolulu,Hawai’i, USA. ACM.

Castelfranchi, C. (1998).Modelling social action for AI agents.Artificial Intelligence, 103(1-2):157–182.

Ciancarini, P. (1996).Coordination models and languages as software integrators.ACM Computing Surveys, 28(2):300–302.

Denti, E. (2014).Novel pervasive scenarios for home management: the butlers architecture.SpringerPlus, 3(52):1–30.

Ferber, J. and Muller, J.-P. (1996).Influences and reaction: A model of situated multiagent systems.In Tokoro, M., editor, 2nd International Conference on Multi-Agent Systems (ICMAS-96),pages 72–79, Tokio, Japan. AAAI Press.


References

References II

Malone, T. W. and Crowston, K. (1994).The interdisciplinary study of coordination.ACM Computing Surveys, 26(1):87–119.

Omicini, A. (2002).Towards a notion of agent coordination context.In Marinescu, D. C. and Lee, C., editors, Process Coordination and Ubiquitous Computing,chapter 12, pages 187–200. CRC Press, Boca Raton, FL, USA.

Omicini, A. (2007).Formal ReSpecT in the A&A perspective.Electronic Notes in Theoretical Computer Science, 175(2):97–117.

Omicini, A. and Denti, E. (2001).From tuple spaces to tuple centres.Science of Computer Programming, 41(3):277–294.

Omicini, A. and Ossowski, S. (2003).Objective versus subjective coordination in the engineering of agent systems.In Klusch, M., Bergamaschi, S., Edwards, P., and Petta, P., editors, Intelligent InformationAgents: An AgentLink Perspective, volume 2586 of LNAI: State-of-the-Art Survey, pages179–202. Springer.


References

References III

Omicini, A. and Zambonelli, F. (1999).Coordination for Internet application development.Autonomous Agents and Multi-Agent Systems, 2(3):251–269.

Ricci, A., Viroli, M., and Omicini, A. (2008).The A&A programming model and technology for developing agent environments in MAS.In Dastani, M., El Fallah Seghrouchni, A., Ricci, A., and Winikoff, M., editors,Programming Multi-Agent Systems, volume 4908 of LNCS, pages 89–106. Springer.

Schumacher, M. (2001).Objective Coordination in Multi-Agent System Engineering. Design and Implementation,volume 2039 of LNCS.Springer.

Suchman, L. A. (1987).Situated actions.In Plans and Situated Actions: The Problem of Human-Machine Communication,chapter 4, pages 49–67. Cambridge University Press, New York, NYU, USA.


References

References IV

Viroli, M. and Omicini, A. (2006).Coordination as a service.Fundamenta Informaticae, 73(4):507–534.Special Issue: Best papers of FOCLASA 2002.


Extras

URLs

Slides

On APICe

http://apice.unibo.it/xwiki/bin/view/Talks/TucsonWoa2014

On SlideSharehttp://www.slideshare.net/andreaomicini/

tucson-coordination-for-mas-situatedness-towards-a-methodology

Article

On APICe

http://apice.unibo.it/xwiki/bin/view/Publications/TucsonWoa2014

On CEUR

Coming soon


http://apice.unibo.it/xwiki/bin/view/Talks/TucsonWoa2014

http://www.slideshare.net/andreaomicini/tucson-coordination-for-mas-situatedness-towards-a-methodology

http://www.slideshare.net/andreaomicini/tucson-coordination-for-mas-situatedness-towards-a-methodology

http://apice.unibo.it/xwiki/bin/view/Publications/TucsonWoa2014

TuCSoN Coordination for MAS SituatednessTowards a Methodology

Stefano Mariani, Andrea Omicini{s.mariani, andrea.omicini}@unibo.it

Dipartimento di Informatica – Scienza e Ingegneria (DISI)Alma Mater Studiorum—Universita di Bologna, Italy

Talk @ WOA 2014Workshop nazionale “Dagli Oggetti agli Agenti”

Universita di Catania, Italy26 Settembre 2014
