TuCSoN Coordination for MAS Situatedness: Towards a Methodology Stefano Mariani Andrea Omicini DISI, A LMA M ATER S TUDIORUM–Università di Bologna DISI, A LMA M ATER S TUDIORUM–Università di Bologna via Sacchi 3, 47521 Cesena, Italy via Sacchi 3, 47521 Cesena, Italy Email: s.mariani@unibo.it Email: andrea.omicini@unibo.it Abstract—Agent-based technologies embed solutions for criti- What influences the process of MAS engineering based cal issues in agent-oriented software engineering. In this paper we on an agent-oriented framework is first of all the conceptual describe the coordination-based approach to MAS situatedness framework provided by the technology, and in particular the as promoted by the TuCSoN middleware, by sketching the steps meta-model behind it, which fundamentally shapes the space of an agent-oriented methodology from the TuCSoN meta-model of the solutions: the availability of different abstractions to down to the TuCSoN programming environment. elaborate over the application problem usually leads to differ- ent designs and implementations—and ultimately, to different I. C OORDINATION AND S ITUATEDNESS IN MAS solutions, too. This is why in the remainder of this section we describe the meta-model of the TuCSoN model and technol- The need for situatedness in multi-agent systems (MAS) ogy for agent coordination [7]; that is, the set of abstractions is often translated into the requirement of being sensitive to provided by TuCSoN in order to model application problems environment change [1], possibly influencing the environment since the very beginning of the engineering stage. Three are the in turn. Such a requirement lays at the core of the notion TuCSoN core concepts for MAS engineering, which motivate of situated action – complementing that of social action [2] the architecture described in Section III: activities, environment –, as those actions arising from strict interaction with the change, dependencies. environment [3]. This leads to recognise dependencies among agents and the environment as one of the fundamental sources Activities are the goal-directed/oriented proceedings result- of complexity within a MAS—the other being dependencies ing into actions of any sort, which “make things happen” in between agents’ activities [4]. Therefore, coordination – as a MAS. Through actions, activities in a MAS are social [2] the discipline of managing dependencies [4] – could be used and situated [3]. Activities are usually modelled through the to deal with both social and situated interaction, by exploiting agent abstraction: the reason for this choice is that, often, MAS coordination artefacts [5] for handling both social and situated designers are not merely interested in modelling an action “as dependencies [6]. is”, but they also want / need to model the motivations behind that action—namely, their goal. Thus, from the standpoint Accordingly, in this paper we introduce the situated co- endorsed here, agents do not exist because they resemble some ordination approach promoted by the TuCSoN model and “real-world” entity; they exist as the means through which technology for agent coordination [7] to handle situatedness activities can be modelled in a MAS—as a way to model in MAS as a coordination issue. In particular, we describe the actions along with their driving goals. support that TuCSoN provides to MAS programmers in each macro-stage of a typical software engineering process applied Environment change represents the (possibly unpredictable) to a MAS: the abstractions available for the requirement variations in the properties or structure of the world sur- analysis (Section II), the reference run-time architecture for the rounding a MAS that affect it in any way—thus, which the design phase (Section III), the API supporting the concept of MAS needs to account for. Such variations do not express situated coordination (Section IV). Finally, to help the reader any specific goal, either because this does not exist, or be- understanding our methodological approach, we sketch how cause it is not to be / cannot be modelled in the MAS. to deploy a TuCSoN-coordinated situated infrastructure for Also, variations may not correspond to actual changes in the smart home appliances coordination (Section V). real-world properties or structure, but simply variations in the perception of the world the MAS has—in other words, what the MAS observes may vary independently of whether II. R EQUIREMENT A NALYSIS : T HE TuCSoN the environment actually changes too. Environment (change) M ETA - MODEL is usually modelled through the resource abstraction, as a non-intelligent entity either continuously producing events or The availability of well-known and established develop- reactively waiting for requests to perform its function. ment frameworks and middleware often lead to (implicit) methodologies which are essentially driven by the abstractions Finally, in any non-trivial MAS, activities depend on other promoted and supported by the technology [8]. This typically activities (social dependencies), as well as on environment happens when the maturity of technologies precedes that change (situated dependencies). Thus, dependencies motivate of methodologies—and actually happened for agent-oriented and cause interaction, both social and situated, based on the technologies in the last decade [9]. sort of dependency taking place. Furthermore, the core notion linking the TuCSoN ar- an ACC (see below), released by TuCSoN itself. chitecture to its meta-model is that of event. Despite their Agents (interaction-oriented) activities result into intrinsic diversity, activities and environment change constitute coordination operations, targeting the coordina- altogether the only sources of dynamics – thus complexity – in tion media (a tuple centre, see below) actually a MAS. In order to provide a uniform representation of MAS handled by the ACC. dynamics and to promote a coordination-oriented approach ACC — Agent Coordination Contexts [12] are TuC- in modelling social as well as situated dependencies, both SoN architectural components devoted to rep- activities and environment changes trigger events. Therefore, in resent and mediate agents activities within the TuCSoN, events reify any social and any situated interaction MAS. In particular, an ACC maps coordination taking place within the MAS, driving the coordination process. operations (thus both social and situation actions) into events, dispatches them to tuple centres, waits Given the above abstractions, MAS designers should think for the outcome of dependency resolution (that about the problem at hand in terms of (i) a bunch of goal- is, coordination), then sends the operation result directed/oriented activities (agents) (ii) interacting with each back to the agent. ACC are also the fundamental other and influenced by / influencing some sort of (iii) changes run-time entities that preserve agent autonomy in their environment (resources), therefore (iv) generating [12]: in fact, while the ACC takes care of asyn- events, which (v) have to be properly coordinated. chronously dispatching events – consequence of agent’s activity – to tuple centres, the agent is III. M ODEL & D ESIGN : T HE TuCSoN A RCHITECTURE free to undertake other activities. This enables decoupling in control, reference, space and time. In this section we first overview the TuCSoN architecture probes — Environmental resources in TuCSoN are called by describing its main components, directly stemming from probes. They can be either sources of percep- the TuCSoN meta-model introduced in Section II. Then we tions (like sensors), targets of actions (like ac- sketch how such components collaborate to properly support tuators), or even both: TuCSoN models them in the modelling of activities and environment changes in TuC- the same way, using transducers. In fact, actions SoN (Subsection III-A and Subsection III-B), in particular over probes are carried out by transducers: as for focussing on agent-environment interactions—that is, situated agents with ACC, probes do not directly interact dependencies (Subsection III-C). with the MAS, but through transducer mediation. TuCSoN1 [7] is a Java-based, tuple-based coordination transducers — Analogously to ACC for agents, TuC- infrastructure for open distributed MAS. Its main architectural SoN transducers [13] are the architectural run- run-time components are—as depicted in Fig. 1: time components in charge of representing and mediating environment changes regarding probes. agents — Any computational entity willing to exploit Each probe is assigned a transducer, which is TuCSoN coordination services [10] is a TuCSoN specialised to handle events to/from that probe. agent. In order for agents to be recognised as co- So, in particular, transducers translate (i) probes ordinables [11] by TuCSoN, they need to obtain properties changes into events, to be dispatched to tuple centres and properly coordinated, and 1 http://tucson.unibo.it (ii) MAS events into properties changes, to be sensed/effected on probes. events — TuCSoN adopts the ReSpecT [14] event model – adapted from [15] in TABLE I on page 8 –, representing any sort of event happening in the MAS in a uniform way—both the events gener- ated from agents activities and those from changes in the environment. Events are the data structure reifying all the relevant information about the activity or change that generated them. In partic- ular, TuCSoN events record: the immediate and primary cause of the event [16], its outcome, who is the source of the event, who is its target, when and where the event was generated. Thus, any event captured by TuCSoN – through ACC and transducers – is situated both in space and time, as well as within its execution context. This lays at the core of the notion of situated coordination, meaning that tuple centres can effectively coor- Fig. 1. TuCSoN architecture. ACC and transducers mediate the interactions dinate events (thus resolve dependencies) while between agents and the environment by translating activities and changes accounting for the situated nature of interactions. into events, which are then handled by tuple centres so as to support both coordination and situatedness. The “inner cloud” can be seen as a TuCSoN tuple centres — ReSpecT tuple centres [17] are the TuC- node, that is, a single “place” in which the coordination between MAS entities SoN architectural component mediating all inter- happens. Actually, such node can be distributed across networked devices, actions happening in the MAS, thus in charge of blurring the distinction between a TuCSoN node and a TuCSoN system. handling events in order to resolve dependencies. They are run by the TuCSoN middleware to rule dynamically determined by the TuCSoN middleware itself, and decouple (in control, reference, space, and based upon the agent request and its expected role inside the time) dependencies between agent activities as MAS [18]. well as environment change—in other words, both social and situated interactions [6]. By adopting Once a TuCSoN agent obtains an ACC, all of its inter- ReSpecT tuple centres, TuCSoN relies on (i) actions are mediated by the ACC itself, with no role for the the ReSpecT language to program coordination TuCSoN node. In particular, as depicted in Fig. 3, in the case laws, and (ii) the ReSpecT situated event model a coordination operation is requested through a synchronous to implement events. invocation: Summing up, MAS designers aiming at exploiting TuCSoN (i) first of all (messages 2 − 2.1.2), the target tuple centre coordination services should: (i) rely on ACC and therein associated to the ACC is dynamically instantiated by the defined primitives to interact with other TuCSoN-coordinated TuCSoN run-time infrastructure, and its network address entities, (ii) define suitable transducers to represent the relevant given to the ACC for further reference portions of MAS environment, (iii) program TuCSoN tuple (ii) then (message 2.2), the ACC takes charge of building centres through ReSpecT specifications to handle TuCSoN the corresponding event and of dispatching it to the tuple events—therefore, to effectively coordinate the MAS. centre target of the interaction As a last note, we would like to highlight that ReSpecT (iii) finally (messages 2.2.1 − 2.2.2.1), the ACC is notified event model (TABLE I) is general enough to model any kind of when the outcome of the coordination operation re- social/situated coordination event, not any kind of (whatever) quested is available – after a proper coordination stage, event which can happen in a MAS. In particular, we do not possibly involving other events from other entities – so aim at foreseeing at design time all possible events which can that it can send the operation result back to the agent happen in a MAS; rather, we simply aim at foreseeing the general structure of any coordination-related event, to be later Only the coordination operation request from the agent to its instantiated through a TuCSoN event at run-time. Then, con- ACC is a synchronous method call: any other interaction is sidering only such a restricted subset of events, we can achieve asynchronous as well as event-driven. This is necessary in adaptation as well as tolerance to unpredictability thanks to every open and distributed scenario, and enables the already ReSpecT programmability and TuCSoN transducers, respec- mentioned decoupling in control, reference, space, and time. tively. In fact, programmability of ReSpecT reactions makes it Nevertheless, in such a scenario – synchronous operation possible to change event handling (thus, coordination policies) invocation – the control flow of the caller agent is retained at run-time, whereas run-time addition/removal of transducers by the ACC as long as the operation result is not available along with situatedness of ReSpecT events instantiation helps (message 2.2.2.1). in dealing with unpredictability of environment. Conversely, Fig. 4 depicts the asynchronous invocation scenario: the only difference w.r.t. the synchronous one lays in A. Agent side the fact that the control flow is given back to the caller agent as The agent side of a TuCSoN-coordinated MAS is basically soon as the corresponding event is dispatched to the target tuple represented by the run-time relationships between agents, centre (messages 3.3 − 3.4). The actual result of the requested ACC, and tuple centres. coordination operation is dispatched to the agent as soon as it becomes available, asynchronously (message 3.3.2.1). First of all, as depicted in Fig. 2, TuCSoN agents have to TuCSoN lets client agents choose which semantics to use for acquire an ACC before issuing any sort of coordination opera- their coordination operations invocation, either synchronous or tion towards the TuCSoN infrastructure. They do so by asking asynchronous. As a side note, the scenario depicted in Fig. 4 the TuCSoN middleware to release an ACC. Whether an ACC assumes that the target tuple centre is already up and running is actually released, and which one among those available2 is – e.g., as a consequence of a previous operation invocation 2 See the TuCSoN official guide at http://www.slideshare.net/andreaomicini/ – thus, the TuCSoN node simply retrieves its reference, and the-tucson-coordination-model-technology-a-guide. passes it to the ACC. Fig. 2. ACC acquisition by TuCSoN agents. Nothing can be done by an Fig. 5. ACC release by TuCSoN agents. Nothing can be done by an agent agent with the TuCSoN middleware prior to ACC acquisition. with the TuCSoN middleware after ACC release. Fig. 3. Synchronous operation invocation. The control flow is released back to the agent only when the operation result is available—thus, only when the coordination process ends. Fig. 4. Asynchronous operation invocation. The control flow is released back to the agent as soon as the event related to the request is generated and dispatched by the ACC. Whenever an agent no longer needs TuCSoN coordination Summing up, designers of agents exploiting TuCSoN services, it should release its ACC back to TuCSoN middle- should make their agents: (i) acquire an ACC; (ii) choose ware, which promptly destroys it in order to prevent resources each operation invocation semantics, and (iii) expect operations leakage—as depicted in Fig. 5. It should be noticed that there is result to be available accordingly; (iv) release their ACC when no way to re-acquire an already-released ACC – e.g., to restore TuCSoN services are no longer needed—notice at agents interactions history –, since whenever an ACC is requested shutdown TuCSoN automatically releases “orphan” ACCs. a new one is created and assigned. Since ACC are used to represent and identify agents within a TuCSoN-coordinated B. Environment side MAS, an agent obtaining an ACC multiple times is recognised every time as a new agent by the TuCSoN middleware. On the environment side of the TuCSoN architecture, agents and ACC are replaced by probes and transducers, Fig. 6. Probes registration and transducers association. No events can be Fig. 9. Probe de-registration. Nothing can be either sensed or effected by perceived nor actions undertaken on a probe prior to transducer association. the MAS upon the de-registered probe, since the mediating transducer is no longer running. respectively—as depicted by Fig. 6. Thus, first of all, probes C. Between agents and environment: Situated coordination should register to the TuCSoN middleware in order to get their transducer and interact. After probe registration, any interac- Putting together the agent and the environment side of tion resulting from environmental property change affecting the TuCSoN event-driven architecture, Fig. 10 and Fig. 11 the MAS is mediated by the transducer. Fig. 7 depicts the depict a synchronous interaction of an agent with a sensor, interaction among TuCSoN run-time entities in the case of a and an asynchronous interaction of an agent with an actuator, sensor probe, thus a sensor transducer, whereas Fig. 8 shows respectively. By inspecting the whole interaction sequence, one the case of an actuator probe. By comparing the two pictures, could see how (i) TuCSoN ACC and transducers play a central the flow of interactions is almost the same, except for the first role in supporting distribution and decoupling of agents and invocation, which depends on the nature of the probe—either probes within the MAS, and (ii) how TuCSoN tuple centres sensor (Fig. 7) or actuator (Fig. 8). and the ReSpecT language are fundamental to support both situatedness and objective coordination [19], [20]. In particular, a perception by a sensor probe works as In particular, in Fig. 10 the agent is issuing a syn- follows—Fig. 7: chronous coordination operation request involving a given tu- ple sense(temp(T))—message 1. After event dispatching (i) first of all (messages 2 − 2.1.2), the target tuple centre (all the dynamic instantiation interactions were left out for the associated to the transducer is dynamically instantiated sake of clarity), the tuple centre target of the operation reacts by the TuCSoN run-time infrastructure, and its network to such invocation by triggering the ReSpecT reaction in address passed to the transducer for further reference annotation 1.1.1, which generates a situated event (step 1.1.2) (i) then (message 2.2), the transducer builds the event corre- aimed at executing a situation operation (getEnv(temp, sponding to the perception operation, and dispatches it to T)) on the probe (sensor). The transducer associated to the the tuple centre target of the interaction tuple centre and responsible for the target probe intercepts such (i) finally (messages 2.2.1 − 2.2.2), the tuple centre enacts an event and takes care of actually executing the operation on the coordination process triggered by such event (if any), the probe (message 1.1.2.1). The sensor probe reply (message properly dispatching its outcome 1.1.2.2) generates a sequence of events propagation terminat- ing in the response to the original coordination operation issued by the agent (message 1.1.2.3.2.1). As far as probe interaction is concerned, there is no distinction between synchronous or asynchronous semantics. In fact, The role of the tuple centre in supporting situatedness being representations of environmental resources, probes are should pointed out here: in fact, step 1.1.2.3.1 properly reacts not supposed to expect any feedback from the MAS: they to the completion of situation operation getEnv(temp, T) simply cause / undergo changes that are relevant to the MAS. by the sensor probe, emitting exactly the tuple originally For this reason, the semantics of situation operations invocation requested by the agent (sense(temp(T))). on probes is always asynchronous—as depicted in Fig. 7 and In Fig. 11 the sequence of interactions as well as the Fig. 8: the control flow is always returned to the probe as soon annotations are very similar to those in Fig. 10. In par- as the corresponding event is generated. ticular, annotation 2.1.1 shows how the ReSpecT reaction triggering event matches the event raised as a consequence When a probe is no longer needed, it should be de- of agent coordination operation request (act(temp(T))), registered from TuCSoN, which subsequently destroys the while annotation 2.1.2.3.1 highlights how the tuple centre associated transducer—as depicted in Fig. 9. maps the situation operation outcome (setEnv(temp, T)) in the original tuple (act(temp(T))) through a proper Wrapping up, TuCSoN situatedness services require MAS ReSpecT reaction. The only differences w.r.t. Fig. 10 are the designers to: (i) always register probes causing their trans- asynchronous invocation semantics used by the agent and the ducer instantiation; (ii) be aware that environmental events actuator nature of the interacting probe—thus, the names of are always generated asynchronously; (iv) de-register probes messages 2.1.2.1 and 2.1.2.2. when they are no longer needed—no automatic de-registration is performed by the TuCSoN middleware. In summary, as shown by Fig. 10 and Fig. 11, ReSpecT Fig. 7. Sensor probe interaction. The control flow returns to the probe as soon as the environmental event is generated and dispatched by the transducer, thus, everything happens asynchronously. Fig. 8. Actuator probe interaction. Again, everything happens asynchronously. is fundamental to program TuCSoN tuple centres so as to instantiated: this contributes to clarify what situatedness means correctly bind coordination operations with situation opera- and how it can be supported. tions – while preserving the autonomy of interacting entities –, ultimately supporting agent-environment interactions – thus, Starting from the reaction annotating message 1.1.1 in situatedness – in distributed, open environments Fig. 10, and according to ReSpecT formal syntax and se- mantics [14], we can distinguish: IV. I MPLEMENTATION : ReSpecT API in(sense(temp(T))) — (part of) the triggering event. As soon as the operation invocation event gen- This section focusses on ReSpecT programming for sit- erated by the ACC arrives to the target tuple uatedness and events handling, by discussing the ReSpecT centre (message 1.1), the ReSpecT VM scans language API. In particular, it is meant to explain what its ReSpecT program searching for any reac- programmers can do in the implementation stage of TuCSoN- tions whose triggering event matches the one coordinated MAS by exploiting ReSpecT situated event received—where matching means unification in model to its full extent. Notice, what follows is not merely the first-order logic ReSpecT language. Any re- done to describe implementation details; instead, it is meant action found is collected and candidate for ex- to show which situatedness-related properties are available for ecution. In this case, the triggering event cor- inspection/handling and how these properties are dynamically responds to an Activity, using the terminology Fig. 10. Synchronous situation operation querying a sensor. ReSpecT plays a fundamental role in binding both the agent coordination operation to its corresponding situation operation (annotation in step 1.1.1) and the probe response back to the agent original request (annotation in step 1.1.2.3.1). Fig. 11. Asynchronous situation operation commanding an actuator. As in Fig. 10, ReSpecT role in enabling situatedness is visible in annotations 2.1.1 and 2.1.2.3.1. hEventi ::= hStartCausei , hCausei , hEvaluationi hStartCausei , hCausei ::= hActivityi | hChangei , hSourcei , hTargeti , hTimei , hSpace:Placei hSourcei , hTargeti ::= hAgentIdi | hTCIdi | hProbeIdi | ⊥ hEvaluationi ::= ⊥ | {hResulti} TABLE I. ReSpecT SITUATED event model. of ReSpecT event model in TABLE I—that is, out(sense(temp(T))) — the computation emitting something coming from an agent. in the tuple centre the tuple reifying the infor- (operation, invocation) — the guard predicates. mation perceived by the sensor probe. Such a Triggered reactions are further filtered based upon tuple perfectly matches the one used as argument evaluation of their guards, that is, logic predi- of the coordination operation issued by the inter- cates allowing fine-grained control over reaction acting agent: thus, coupled with the synchronous triggering, which can evaluate to either true invocation semantics chosen, this ensures MAS or false. In this case, the operation guard programmers that their agent will resume its ex- filters coordination operation events whereas the ecution only when the perception operation has invocation guard filters events from the ACC been successfully carried out. to the tuple centre. If all the guards of the reaction are evaluated to true, such reaction is scheduled The above description of ReSpecT reactions machinery for execution. should make the role played by the tuple centre coordination [...] ? getEnv(temp, T) — the actual reaction. abstraction in supporting situatedness evident—thus, the con- After guard-based filtering phase, the tuple centre cept of situated coordination. The reactions annotating Fig. 11 non deterministically selects one reaction from can be explained in a similar way, thus they are left out from the pool of those scheduled and starts executing discussion. it. In this case, the only computation to carry Finally, a list of some of the methods available in the out is a Change, again, using the terminology Respect2PLibrary Java class within TuCSoN distribution of TABLE I. In particular, the situation operation follows in the remainder of this section, which exposes the (getEnv(...)) on probe sensor – whose full API for ReSpecT programmers. Such API allows inspection name is the hProbeIdi in TABLE I –, which of any event property on any TuCSoN event from within any causes a situation operation event to be generated ReSpecT reaction, according to the event model in TABLE I. and dispatched first to the associated transducer, In the particular scenario depicted by ReSpecT reaction 1.1.1 then to the actual probe. of Fig. 10, for instance: After the request is served, field hEvaluationi from TABLE I event_predicate_1(Term p) — makes it possible is still empty—waiting for completion to be carried out. In to inspect the hActivityi | hChangei field of the fact, due to the asynchronous nature of events dispatching in event which directly caused (hCausei) the trig- TuCSoN, the tuple centre itself does not suspend execution gering of the ReSpecT reaction. In this case, it waiting for a response from the probe. This is necessary, e.g., unifies p with in(sense(temp(T))). to face the issues of network communications in a distributed event_source_1(Term s) — makes the hSourcei of scenario. the event observable—that is, who caused event For these reasons, the ReSpecT reaction annotating mes- generation. In this case, it unifies s with the sage 1.1.2.3.1 in Fig. 10 is complementary and necessary to hAgentIdi of the agent issuing the coordination complete the situated interaction in a meaningful way. In such operation (message 1). reaction, the triggering event, the guards, and the reaction are, event_target_1(Term t) — allows inspection of respectively: the hTargeti field of the event. In this case, it unifies t with the hTCIdi of the tuple centre target getEnv(temp, T) — the situation operation event of the event (message 1.1). corresponding to the Change execution by the event_time_1(Term t) — makes the hTimei when tuple centre (through the probe transducer) in the the event was generated observable. In this case, it first reaction (messages 1.1.2 - 1.1.2.3). The first unifies t with the time at which the ACC receives reaction, in fact, requests the operation execution the coordination operation request (message 1). to the probe transducer, whereas this reaction event_place_1(Term s, Term p) — allows the manages such request reply. hSpace:Placei field of the event to be inspected, (from_env, completion) — filtering situation op- once the sort of space is chosen from a pre-defined eration events (from_env) representing the out- set of admissible spaces—either absolute physi- come of an execution (completion). Using cal position (s=ph), IP address (s=ip), domain these guards, MAS programmers are guaranteed name (s=dns), geographical location (s=map), to make the tuple centre react only when the organisational position (s=org). In this case, it requested situation operation has been actually unifies p with, e.g., the network address of the executed on the target probe. agent which caused reaction triggering. If the same methods were used in ReSpecT reaction annotat- enable cooking dinner), as well as may both impact ing message 1.1.2.3.1, the results would be different—due to and be affected by (other form of dependencies) the situatedness of events: environment. . . event_predicate_1(Term p) — would unify p • . . . causing some change to happen (e.g., since I’ll be with getEnv(temp, T). late delay lights turn on time, there is no food thus I event_source_1(Term s) — would unify s with must go to the grocery shop) the hProbeIdi of the probe source of the event (message 1.1.2.2). Once we recognise that activities and environment changes event_target_1(Term t) — would unify t with both make events happen, thus managing dependencies be- the hTCIdi of the tuple centre target of the event tween activities and change ultimately amount to managing (message 1.1.2.3). events, we have a perfect and complete match with TuCSoN event_time_1(Term t) — would unify t with the reference meta-model. time at which the transducer receives the situation Modelling & Design: Once the problem at hand (smart operation completion (message 1.1.2.2). home appliances coordination) has being re-interpreted ac- event_place_1(Term s, Term p) — would unify cording to the TuCSoN meta-model, TuCSoN architecture p with, e.g., the network address of the sensor provides all the necessary components to build a solution. probe that caused reaction triggering. Thus: activities of users are generated by agents, making it possible to also ascribe goals to actions, and mediated by V. D EPLOYMENT: S MART H OME A PPLIANCES ACCs, enabling and constraining interactions according to C OORDINATION the system goals; changes in the environment are generated In this section, we look at a smart home scenario with by probes and mediated by transducers, enabling a uniform the aim of deploying TuCSoN as its underlying situated representation of environmental properties despite appliances coordination infrastructure. This allows us to sketch how heterogeneity; both activities and changes (thus ACCs and requirement analysis and modelling & design can be dealt with transducers) generate events as their own representation within while evaluating (in principle) both the TuCSoN approach and the situated MAS coordinated by TuCSoN, which are then its architecture—the implementation is left out being it too managed by tuple centres suitably programmed with adaptable application-specific. coordination laws. Scenario: In order to lose as less generality as possible, Consequently, in our smart home we have: agents deployed we could depict a smart home scenario. There, many different to users’ personal devices (smartphone/desktop pc), probes “smart appliances” (e.g., smart fridge, smart thermostat, smart deployed to home appliances, ACCs and transducers deployed lights, smart A/C, etc.) are scattered in an indoor environment either on-board along with agents and probes, respectively (e.g., a flat). Either inhabitants have an Android smartphone (e.g., on the smartphone), or remotely (e.g., on the desktop), or a desktop PC is available in the environment (or even tuple centres deployed again either on board or remotely, all both)—this ensures the TuCSoN middleware can be run- performing activities and enacting/undergoing changes gener- ning, being the JVM its only requirement. Some kind of ating events, automatically handled by TuCSoN according to connection is available at least between each appliance and designed coordination laws. the smartphone/desktop—appliances may also be connected Considerations: Notice a similar scenario is depicted in together to improve distribution thus resilience, although not [21], although much more thoroughly. There, TuCSoN is taken strictly necessary. Inhabitants want the “smart home system” as the underlying infrastructure on top of which the “Butlers to self-manage toward a given goal (e.g., always optimise Architecture” for smart home management is deployed— power consumption) according to their preferences (e.g., prefer further evaluating its architecture (in principle, at least). In turning on fans rather than switching A/C on), while keeping particular, it should be noticed that agents are used therein to the capability to control it despite such self-management, when model environmental resources as well (e.g., home appliances), desired (e.g., “I want frozen beers now, forget about power whereas our proposed approach would model them as probes, consumption!”). thus handled (coordinated) within the MAS by transducers. Requirement Analysis: Essentially, the core requirement of Benefits of doing so are not limited to a cleaner architecture our proposed scenario is that environmental resources (e.g., the and separation of concerns, but also include smaller computa- A/C, the fridge, etc.) should be able to adapt to environment tional load (transducers are “simpler” than full-fledged agents), change (e.g., temperature drops, food depletion, etc.) as well as better run-time adaptiveness (replacing a transducer is much user actions (e.g., I’m coming home late, order pizza), striving simpler than replacing an agent), improved management of to achieve a system goal (e.g., optimise inhabitants comfort) heterogeneity (despite probes API differences, transducers map while accounting for each user desires. any event to a common event structure). According to the TuCSoN meta-model as described in Section II, this can be interpreted as follows: VI. C ONCLUSION Comparing the methodological approach discussed here • users continuously and unpredictably perform their with the whole lot of AOSE methodologies available nowa- daily activities. . . days would be unfeasible for reasons of space. However, it • . . . which may depend on the environment being in a may easily be noted that the only AOSE methodology that certain “enabler state” (e.g., food must be available to clearly resembles our coordination-based approach is SODA [22], in particular regarding its concern with interaction and [9] A. Molesini, A. Omicini, and M. Viroli, “Environment in Agent- environment in MAS. Also, most of the possible remarks can Oriented Software Engineering methodologies,” Multiagent and be easily found in [8], where the issues of situatedness and Grid Systems, vol. 5, no. 1, pp. 37–57, 2009, special Issue “Engineering Environments in Multi-Agent Systems”. [Online]. environment engineering in MAS, along with the relationship Available: http://iospress.metapress.com/content/q38j30vw612rg5g8/ between agent infrastructure and methodologies, is throughly [10] M. Viroli and A. Omicini, “Coordination as a service,” Fundamenta reviewed. Informaticae, vol. 73, no. 4, pp. 507–534, 2006, special Issue: Best papers of FOCLASA 2002. [Online]. Available: http://iospress. So, in this paper we introduce the TuCSoN approach to metapress.com/link.asp?id=5uefwmu39gt3gmvp situated coordination in MAS, by describing the support to [11] P. Ciancarini, “Coordination models and languages as software situated MAS engineering provided by the TuCSoN model integrators,” ACM Computing Surveys, vol. 28, no. 2, pp. 300–302, Jun. 1996. [Online]. Available: http://portal.acm.org/citation.cfm?id=234732 and architecture in each typical stage of software development: the abstractions to be used for the requirement analysis step, [12] A. Omicini, “Towards a notion of agent coordination context,” in Process Coordination and Ubiquitous Computing, D. C. Marinescu and the architectural components available to model the MAS at C. Lee, Eds. Boca Raton, FL, USA: CRC Press, Oct. 2002, ch. 12, hand, the software API to program situatedness-related aspects pp. 187–200. from a coordination standpoint. [13] M. Casadei and A. Omicini, “Situated tuple centres in ReSpecT,” in 24th Annual ACM Symposium on Applied Computing (SAC 2009), S. Y. The solutions promoted by the TuCSoN technology to Shin, S. Ossowski, R. Menezes, and M. Viroli, Eds., vol. III. Honolulu, deal with the issues of open and distributed MAS are also Hawai’i, USA: ACM, 8–12 Mar. 2009, pp. 1361–1368. [Online]. Available: http://portal.acm.org/citation.cfm?id=1529282.1529586 highlighted: in particular, the need to rely on mediating ab- [14] A. Omicini, “Formal ReSpecT in the A&A perspective,” Electronic stractions such as ACC, transducers, and tuple centres as the Notes in Theoretical Computer Science, vol. 175, no. 2, pp. 97–117, means to decouple individual components (agents and probes) Jun. 2007. [Online]. Available: http://www.sciencedirect.com/science/ interactions, along with the need for an asynchronous event- article/pii/S1571066107003519 driven communication model to correctly deal with the most [15] S. Mariani and A. Omicini, “Space-aware coordination in ReSpecT,” common issues of system distribution. in From Objects to Agents, ser. CEUR Workshop Proceedings, M. Baldoni, C. Baroglio, F. Bergenti, and A. Garro, Eds., vol. 1099. Turin, Italy: Sun SITE Central Europe, RWTH Aachen University, 2–3 Dec. 2013, pp. 1–7, xIV Workshop (WOA 2013). Workshop R EFERENCES Notes. [Online]. Available: http://ceur-ws.org/Vol-1099/paper3.pdf [16] A. Ricci, M. Viroli, and A. Omicini, “The A&A programming [1] J. Ferber and J.-P. Müller, “Influences and reaction: A model model and technology for developing agent environments in MAS,” of situated multiagent systems,” in 2nd International Conference in Programming Multi-Agent Systems, ser. LNCS, M. Dastani, on Multi-Agent Systems (ICMAS-96), M. Tokoro, Ed. Tokio, A. El Fallah Seghrouchni, A. Ricci, and M. Winikoff, Eds. Japan: AAAI Press, Dec. 1996, pp. 72–79. [Online]. Available: Springer, Apr. 2008, vol. 4908, pp. 89–106. [Online]. Available: http://aaaipress.org/Papers/ICMAS/1996/ICMAS96-009.pdf http://www.springerlink.com/content/92370q174328841j/ [2] C. Castelfranchi, “Modelling social action for AI agents,” Artificial [17] A. Omicini and E. Denti, “From tuple spaces to tuple centres,” Science Intelligence, vol. 103, no. 1-2, pp. 157–182, Aug. 1998. of Computer Programming, vol. 41, no. 3, pp. 277–294, Nov. 2001. [Online]. Available: http://www.sciencedirect.com/science/article/pii/ [18] M. Viroli, A. Omicini, and A. Ricci, “Infrastructure for RBAC- S0004370298000563 MAS: An approach based on Agent Coordination Contexts,” Applied [3] L. A. Suchman, “Situated actions,” in Plans and Situated Actions: The Artificial Intelligence: An International Journal, vol. 21, no. 4– Problem of Human-Machine Communication. New York, NYU, USA: 5, pp. 443–467, Apr. 2007, special Issue: State of Applications Cambridge University Press, 1987, ch. 4, pp. 49–67. in AI Research from AI*IA 2005. [Online]. Available: http: //www.tandfonline.com/doi/abs/10.1080/08839510701253674 [4] T. W. Malone and K. Crowston, “The interdisciplinary study of coordination,” ACM Computing Surveys, vol. 26, no. 1, pp. 87–119, [19] M. Schumacher, Objective Coordination in Multi-Agent System 1994. [Online]. Available: http://dl.acm.org/citation.cfm?doid=174668 Engineering. Design and Implementation, ser. LNCS. Springer, Apr. 2001, vol. 2039. [Online]. Available: http://www.springerlink.com/ [5] A. Omicini, A. Ricci, and M. Viroli, “Coordination artifacts as content/t65dbp4hmj7r/ first-class abstractions for MAS engineering: State of the research,” in Software Engineering for Multi-Agent Systems IV: Research Issues [20] A. Omicini and S. Ossowski, “Objective versus subjective coordination and Practical Applications, ser. Lecture Notes in Computer Science, in the engineering of agent systems,” in Intelligent Information A. F. Garcia, R. Choren, C. Lucena, P. Giorgini, T. Holvoet, Agents: An AgentLink Perspective, ser. LNAI: State-of-the-Art and A. Romanovsky, Eds. Springer Berlin Heidelberg, Apr. Survey, M. Klusch, S. Bergamaschi, P. Edwards, and P. Petta, 2006, vol. 3914, pp. 71–90, invited Paper. [Online]. Available: Eds. Springer, 2003, vol. 2586, pp. 179–202. [Online]. Available: http://link.springer.com/10.1007/11738817 5 http://www.springerlink.com/content/cvx82e7ej1j9c65n/ [21] E. Denti, “Novel pervasive scenarios for home management: the [6] A. Omicini and S. Mariani, “Coordination for situated MAS: Towards butlers architecture,” SpringerPlus, vol. 3, no. 52, pp. 1–30, January an event-driven architecture,” in International Workshop on Petri 2014. [Online]. Available: http://www.springerplus.com/content/3/1/52/ Nets and Software Engineering (PNSE’13), ser. CEUR Workshop abstract Proceedings, D. Moldt and H. Rölke, Eds., vol. 989. Sun SITE Central Europe, RWTH Aachen University, 6 Aug. 2013, pp. 17–22. [22] A. Omicini, “SODA: Societies and infrastructures in the analysis [Online]. Available: http://ceur-ws.org/Vol-989/paper00.pdf and design of agent-based systems,” in Agent-Oriented Software Engineering, ser. Lecture Notes in Computer Science, P. Ciancarini [7] A. Omicini and F. Zambonelli, “Coordination for Internet application and M. J. Wooldridge, Eds. Springer-Verlag, 2001, vol. 1957, development,” Autonomous Agents and Multi-Agent Systems, vol. 2, pp. 185–193, 1st International Workshop (AOSE 2000), Limerick, no. 3, pp. 251–269, Sep. 1999. [Online]. Available: http://springerlink. Ireland, 10 Jun. 2000. Revised Papers. [Online]. Available: http: metapress.com/content/uk519681t1r38301/ //link.springer.com/chapter/10.1007/3-540-44564-1 12 [8] A. Molesini, E. Nardini, E. Denti, and A. Omicini, “Situated process engineering for integrating processes from methodologies to infrastructures,” in 24th Annual ACM Symposium on Applied Computing (SAC 2009), S. Y. Shin, S. Ossowski, R. Menezes, and M. Viroli, Eds., vol. II. Honolulu, Hawai’i, USA: ACM, 8–12 Mar. 2009, pp. 699–706. [Online]. Available: http://dl.acm.org/citation.cfm?id=1529429