-Agent-based technologies embed solutions for critical issues in agent-oriented software engineering. In this paper we describe the coordination-based approach to MAS situatedness as promoted by the TuCSoN middleware, by sketching the steps of an agent-oriented methodology from the TuCSoN meta-model down to the TuCSoN programming environment.
The need for situatedness in multi-agent systems (MAS)
is often translated into the requirement of being sensitive to
environment change [
Accordingly, in this paper we introduce the situated
coordination approach promoted by the TuCSoN model and
technology for agent coordination [
II.
META-MODEL
The availability of well-known and established
development frameworks and middleware often lead to (implicit)
methodologies which are essentially driven by the abstractions
promoted and supported by the technology [
What influences the process of MAS engineering based
on an agent-oriented framework is first of all the conceptual
framework provided by the technology, and in particular the
meta-model behind it, which fundamentally shapes the space
of the solutions: the availability of different abstractions to
elaborate over the application problem usually leads to
different designs and implementations—and ultimately, to different
solutions, too. This is why in the remainder of this section we
describe the meta-model of the TuCSoN model and
technology for agent coordination [
Activities are the goal-directed/oriented proceedings
resulting into actions of any sort, which “make things happen” in
a MAS. Through actions, activities in a MAS are social [
Environment change represents the (possibly unpredictable) variations in the properties or structure of the world surrounding a MAS that affect it in any way—thus, which the MAS needs to account for. Such variations do not express any specific goal, either because this does not exist, or because it is not to be / cannot be modelled in the MAS. Also, variations may not correspond to actual changes in the 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 the environment actually changes too. Environment (change) is usually modelled through the resource abstraction, as a non-intelligent entity either continuously producing events or reactively waiting for requests to perform its function.
Finally, in any non-trivial MAS, activities depend on other activities (social dependencies), as well as on environment change (situated dependencies). Thus, dependencies motivate and cause interaction, both social and situated, based on the sort of dependency taking place.
Furthermore, the core notion linking the TuCSoN architecture to its meta-model is that of event. Despite their intrinsic diversity, activities and environment change constitute altogether the only sources of dynamics – thus complexity – in a MAS. In order to provide a uniform representation of MAS dynamics and to promote a coordination-oriented approach in modelling social as well as situated dependencies, both activities and environment changes trigger events. Therefore, in TuCSoN, events reify any social and any situated interaction taking place within the MAS, driving the coordination process.
Given the above abstractions, MAS designers should think about the problem at hand in terms of (i) a bunch of goaldirected/oriented activities (agents) (ii) interacting with each other and influenced by / influencing some sort of (iii) changes in their environment (resources), therefore (iv) generating events, which (v) have to be properly coordinated.
III.
In this section we first overview the TuCSoN architecture by describing its main components, directly stemming from the TuCSoN meta-model introduced in Section II. Then we sketch how such components collaborate to properly support the modelling of activities and environment changes in TuCSoN (Subsection III-A and Subsection III-B), in particular focussing on agent-environment interactions—that is, situated dependencies (Subsection III-C).
TuCSoN1 [
Agents (interaction-oriented) activities result into coordination operations, targeting the coordination media (a tuple centre, see below) actually handled by the ACC.
ACC — Agent Coordination Contexts [
Each probe is assigned a transducer, which is specialised to handle events to/from that probe.
So, in particular, transducers translate (i) probes
properties changes into events, to be dispatched
to tuple centres and properly coordinated, and
(ii) MAS events into properties changes, to be
sensed/effected on probes.
events — TuCSoN adopts the ReSpecT [
and decouple (in control, reference, space, and
time) dependencies between agent activities as
well as environment change—in other words, both
social and situated interactions [
Summing up, MAS designers aiming at exploiting TuCSoN coordination services should: (i) rely on ACC and therein defined primitives to interact with other TuCSoN-coordinated entities, (ii) define suitable transducers to represent the relevant portions of MAS environment, (iii) program TuCSoN tuple centres through ReSpecT specifications to handle TuCSoN events—therefore, to effectively coordinate the MAS.
As a last note, we would like to highlight that ReSpecT event model (TABLE I) is general enough to model any kind of social/situated coordination event, not any kind of (whatever) event which can happen in a MAS. In particular, we do not aim at foreseeing at design time all possible events which can happen in a MAS; rather, we simply aim at foreseeing the general structure of any coordination-related event, to be later instantiated through a TuCSoN event at run-time. Then, considering only such a restricted subset of events, we can achieve adaptation as well as tolerance to unpredictability thanks to ReSpecT programmability and TuCSoN transducers, respectively. In fact, programmability of ReSpecT reactions makes it possible to change event handling (thus, coordination policies) at run-time, whereas run-time addition/removal of transducers along with situatedness of ReSpecT events instantiation helps in dealing with unpredictability of environment.
The agent side of a TuCSoN-coordinated MAS is basically represented by the run-time relationships between agents, ACC, and tuple centres.
First of all, as depicted in Fig. 2, TuCSoN agents have to
acquire an ACC before issuing any sort of coordination
operation towards the TuCSoN infrastructure. They do so by asking
the TuCSoN middleware to release an ACC. Whether an ACC
is actually released, and which one among those available2 is
2See the TuCSoN official guide at http://www.slideshare.net/andreaomicini/
the-tucson-coordination-model-technology-a-guide.
dynamically determined by the TuCSoN middleware itself,
based upon the agent request and its expected role inside the
MAS [
Once a TuCSoN agent obtains an ACC, all of its interactions are mediated by the ACC itself, with no role for the TuCSoN node. In particular, as depicted in Fig. 3, in the case a coordination operation is requested through a synchronous invocation: (i) first of all (messages 2 2:1:2), the target tuple centre associated to the ACC is dynamically instantiated by the TuCSoN run-time infrastructure, and its network address given to the ACC for further reference (ii) then (message 2:2), the ACC takes charge of building the corresponding event and of dispatching it to the tuple centre target of the interaction (iii) finally (messages 2:2:1 2:2:2:1), the ACC is notified when the outcome of the coordination operation requested is available – after a proper coordination stage, possibly involving other events from other entities – so that it can send the operation result back to the agent Only the coordination operation request from the agent to its ACC is a synchronous method call: any other interaction is asynchronous as well as event-driven. This is necessary in every open and distributed scenario, and enables the already mentioned decoupling in control, reference, space, and time. Nevertheless, in such a scenario – synchronous operation invocation – the control flow of the caller agent is retained by the ACC as long as the operation result is not available (message 2:2:2:1).
Conversely, Fig. 4 depicts the asynchronous invocation scenario: the only difference w.r.t. the synchronous one lays in the fact that the control flow is given back to the caller agent as soon as the corresponding event is dispatched to the target tuple centre (messages 3:3 3:4). The actual result of the requested coordination operation is dispatched to the agent as soon as it becomes available, asynchronously (message 3:3:2:1). TuCSoN lets client agents choose which semantics to use for their coordination operations invocation, either synchronous or asynchronous. As a side note, the scenario depicted in Fig. 4 assumes that the target tuple centre is already up and running – e.g., as a consequence of a previous operation invocation – thus, the TuCSoN node simply retrieves its reference, and passes it to the ACC.
Whenever an agent no longer needs TuCSoN coordination services, it should release its ACC back to TuCSoN middleware, which promptly destroys it in order to prevent resources leakage—as depicted in Fig. 5. It should be noticed that there is no way to re-acquire an already-released ACC – e.g., to restore interactions history –, since whenever an ACC is requested a new one is created and assigned. Since ACC are used to represent and identify agents within a TuCSoN-coordinated MAS, an agent obtaining an ACC multiple times is recognised every time as a new agent by the TuCSoN middleware.
Summing up, designers of agents exploiting TuCSoN should make their agents: (i) acquire an ACC; (ii) choose each operation invocation semantics, and (iii) expect operations result to be available accordingly; (iv) release their ACC when TuCSoN services are no longer needed—notice at agents shutdown TuCSoN automatically releases “orphan” ACCs.
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 perceived nor actions undertaken on a probe prior to transducer association. respectively—as depicted by Fig. 6. Thus, first of all, probes should register to the TuCSoN middleware in order to get their transducer and interact. After probe registration, any interaction resulting from environmental property change affecting the MAS is mediated by the transducer. Fig. 7 depicts the interaction among TuCSoN run-time entities in the case of a sensor probe, thus a sensor transducer, whereas Fig. 8 shows the case of an actuator probe. By comparing the two pictures, the flow of interactions is almost the same, except for the first invocation, which depends on the nature of the probe—either sensor (Fig. 7) or actuator (Fig. 8).
In particular, a perception by a sensor probe works as follows—Fig. 7: (i) first of all (messages 2 2:1:2), the target tuple centre associated to the transducer is dynamically instantiated by the TuCSoN run-time infrastructure, and its network address passed to the transducer for further reference (i) then (message 2:2), the transducer builds the event corresponding to the perception operation, and dispatches it to the tuple centre target of the interaction (i) finally (messages 2:2:1 2:2:2), the tuple centre enacts the coordination process triggered by such event (if any), properly dispatching its outcome As far as probe interaction is concerned, there is no distinction between synchronous or asynchronous semantics. In fact, being representations of environmental resources, probes are not supposed to expect any feedback from the MAS: they simply cause / undergo changes that are relevant to the MAS. For this reason, the semantics of situation operations invocation on probes is always asynchronous—as depicted in Fig. 7 and Fig. 8: the control flow is always returned to the probe as soon as the corresponding event is generated.
When a probe is no longer needed, it should be deregistered from TuCSoN, which subsequently destroys the associated transducer—as depicted in Fig. 9.
Wrapping up, TuCSoN situatedness services require MAS designers to: (i) always register probes causing their transducer instantiation; (ii) be aware that environmental events are always generated asynchronously; (iv) de-register probes when they are no longer needed—no automatic de-registration is performed by the TuCSoN middleware.
C. Between agents and environment: Situated coordination
Putting together the agent and the environment side of
the TuCSoN event-driven architecture, Fig. 10 and Fig. 11
depict a synchronous interaction of an agent with a sensor,
and an asynchronous interaction of an agent with an actuator,
respectively. By inspecting the whole interaction sequence, one
could see how (i) TuCSoN ACC and transducers play a central
role in supporting distribution and decoupling of agents and
probes within the MAS, and (ii) how TuCSoN tuple centres
and the ReSpecT language are fundamental to support both
situatedness and objective coordination [
In particular, in Fig. 10 the agent is issuing a synchronous coordination operation request involving a given tuple sense(temp(T))—message 1. After event dispatching (all the dynamic instantiation interactions were left out for the sake of clarity), the tuple centre target of the operation reacts to such invocation by triggering the ReSpecT reaction in annotation 1:1:1, which generates a situated event (step 1:1:2) aimed at executing a situation operation (getEnv(temp, T)) on the probe (sensor). The transducer associated to the tuple centre and responsible for the target probe intercepts such an event and takes care of actually executing the operation on the probe (message 1:1:2:1). The sensor probe reply (message 1:1:2:2) generates a sequence of events propagation terminating in the response to the original coordination operation issued by the agent (message 1:1:2:3:2:1).
The role of the tuple centre in supporting situatedness should pointed out here: in fact, step 1:1:2:3:1 properly reacts to the completion of situation operation getEnv(temp, T) by the sensor probe, emitting exactly the tuple originally requested by the agent (sense(temp(T))).
In Fig. 11 the sequence of interactions as well as the annotations are very similar to those in Fig. 10. In particular, annotation 2:1:1 shows how the ReSpecT reaction triggering event matches the event raised as a consequence of agent coordination operation request (act(temp(T))), while annotation 2:1:2:3:1 highlights how the tuple centre maps the situation operation outcome (setEnv(temp, T)) in the original tuple (act(temp(T))) through a proper ReSpecT reaction. The only differences w.r.t. Fig. 10 are the asynchronous invocation semantics used by the agent and the actuator nature of the interacting probe—thus, the names of messages 2:1:2:1 and 2:1:2:2.
In summary, as shown by Fig. 10 and Fig. 11, ReSpecT is fundamental to program TuCSoN tuple centres so as to correctly bind coordination operations with situation operations – while preserving the autonomy of interacting entities –, ultimately supporting agent-environment interactions – thus, situatedness – in distributed, open environments
IV.
This section focusses on ReSpecT programming for situatedness and events handling, by discussing the ReSpecT language API. In particular, it is meant to explain what programmers can do in the implementation stage of TuCSoNcoordinated MAS by exploiting ReSpecT situated event model to its full extent. Notice, what follows is not merely done to describe implementation details; instead, it is meant to show which situatedness-related properties are available for inspection/handling and how these properties are dynamically instantiated: this contributes to clarify what situatedness means and how it can be supported.
Starting from the reaction annotating message 1:1:1 in
Fig. 10, and according to ReSpecT formal syntax and
semantics [
As soon as the operation invocation event generated by the ACC arrives to the target tuple centre (message 1:1), the ReSpecT VM scans its ReSpecT program searching for any reactions whose triggering event matches the one received—where matching means unification in the first-order logic ReSpecT language. Any reaction found is collected and candidate for execution. In this case, the triggering event corresponds to an Activity , using the terminology
Asynchronous situation operation commanding an actuator. As in Fig. 10, ReSpecT role in enabling situatedness is visible in annotations 2:1:1 and hStartCausei , hCausei , hEvaluationi hActivityi j hChangei , hSourcei , hTargeti , hTimei , hSpace:Placei hAgentIdi j hTCIdi j hProbeIdi j ? ? j fhResultig of ReSpecT event model in TABLE I—that is, something coming from an agent. (operation, invocation) — the guard predicates.
Triggered reactions are further filtered based upon evaluation of their guards, that is, logic predicates allowing fine-grained control over reaction triggering, which can evaluate to either true or false. In this case, the operation guard filters coordination operation events whereas the invocation guard filters events from the ACC to the tuple centre. If all the guards of the reaction are evaluated to true, such reaction is scheduled for execution. [...] ? getEnv(temp, T) — the actual reaction.
After guard-based filtering phase, the tuple centre non deterministically selects one reaction from the pool of those scheduled and starts executing it. In this case, the only computation to carry out is a Change, again, using the terminology of TABLE I. In particular, the situation operation (getEnv(...)) on probe sensor – whose full name is the hProbeIdi in TABLE I –, which causes a situation operation event to be generated and dispatched first to the associated transducer, then to the actual probe.
After the request is served, field hEvaluationi from TABLE I is still empty—waiting for completion to be carried out. In fact, due to the asynchronous nature of events dispatching in TuCSoN, the tuple centre itself does not suspend execution waiting for a response from the probe. This is necessary, e.g., to face the issues of network communications in a distributed scenario.
For these reasons, the ReSpecT reaction annotating message 1:1:2:3:1 in Fig. 10 is complementary and necessary to complete the situated interaction in a meaningful way. In such reaction, the triggering event, the guards, and the reaction are, respectively: getEnv(temp, T) — the situation operation event corresponding to the Change execution by the tuple centre (through the probe transducer) in the first reaction (messages 1:1:2 - 1:1:2:3). The first reaction, in fact, requests the operation execution to the probe transducer, whereas this reaction manages such request reply. (from_env, completion) — filtering situation operation events (from_env) representing the outcome of an execution (completion). Using these guards, MAS programmers are guaranteed to make the tuple centre react only when the requested situation operation has been actually executed on the target probe.
out(sense(temp(T))) — the computation emitting in the tuple centre the tuple reifying the information perceived by the sensor probe. Such a tuple perfectly matches the one used as argument of the coordination operation issued by the interacting agent: thus, coupled with the synchronous invocation semantics chosen, this ensures MAS programmers that their agent will resume its execution only when the perception operation has been successfully carried out.
The above description of ReSpecT reactions machinery should make the role played by the tuple centre coordination abstraction in supporting situatedness evident—thus, the concept of situated coordination. The reactions annotating Fig. 11 can be explained in a similar way, thus they are left out from discussion.
Finally, a list of some of the methods available in the Respect2PLibrary Java class within TuCSoN distribution follows in the remainder of this section, which exposes the API for ReSpecT programmers. Such API allows inspection of any event property on any TuCSoN event from within any ReSpecT reaction, according to the event model in TABLE I.
In the particular scenario depicted by ReSpecT reaction 1:1:1 of Fig. 10, for instance: event_predicate_1(Term p) — makes it possible to inspect the hActivityi j hChangei field of the event which directly caused (hCausei) the triggering of the ReSpecT reaction. In this case, it unifies p with in(sense(temp(T))). event_source_1(Term s) — makes the hSourcei of the event observable—that is, who caused event generation. In this case, it unifies s with the hAgentIdi of the agent issuing the coordination operation (message 1). event_target_1(Term t) — allows inspection of the hTargeti field of the event. In this case, it unifies t with the hTCIdi of the tuple centre target of the event (message 1:1). event_time_1(Term t) — makes the hTimei when the event was generated observable. In this case, it unifies t with the time at which the ACC receives the coordination operation request (message 1). event_place_1(Term s, Term p) — allows the hSpace:Placei field of the event to be inspected, once the sort of space is chosen from a pre-defined set of admissible spaces—either absolute physical position (s=ph), IP address (s=ip), domain name (s=dns), geographical location (s=map), organisational position (s=org). In this case, it unifies p with, e.g., the network address of the agent which caused reaction triggering.
If the same methods were used in ReSpecT reaction annotating message 1:1:2:3:1, the results would be different—due to situatedness of events: event_predicate_1(Term p) — would unify p
with getEnv(temp, T). event_source_1(Term s) — would unify s with the hProbeIdi of the probe source of the event (message 1:1:2:2). event_target_1(Term t) — would unify t with the hTCIdi of the tuple centre target of the event (message 1:1:2:3). event_time_1(Term t) — would unify t with the time at which the transducer receives the situation operation completion (message 1:1:2:2). event_place_1(Term s, Term p) — would unify p with, e.g., the network address of the sensor probe that caused reaction triggering.
COORDINATION
In this section, we look at a smart home scenario with the aim of deploying TuCSoN as its underlying situated coordination infrastructure. This allows us to sketch how requirement analysis and modelling & design can be dealt with while evaluating (in principle) both the TuCSoN approach and its architecture—the implementation is left out being it too application-specific.
Scenario: In order to lose as less generality as possible, we could depict a smart home scenario. There, many different “smart appliances” (e.g., smart fridge, smart thermostat, smart lights, smart A/C, etc.) are scattered in an indoor environment (e.g., a flat). Either inhabitants have an Android smartphone or a desktop PC is available in the environment (or even both)—this ensures the TuCSoN middleware can be running, being the JVM its only requirement. Some kind of connection is available at least between each appliance and the smartphone/desktop—appliances may also be connected together to improve distribution thus resilience, although not strictly necessary. Inhabitants want the “smart home system” to self-manage toward a given goal (e.g., always optimise power consumption) according to their preferences (e.g., prefer turning on fans rather than switching A/C on), while keeping the capability to control it despite such self-management, when desired (e.g., “I want frozen beers now, forget about power consumption!”).
Requirement Analysis: Essentially, the core requirement of our proposed scenario is that environmental resources (e.g., the A/C, the fridge, etc.) should be able to adapt to environment change (e.g., temperature drops, food depletion, etc.) as well as user actions (e.g., I’m coming home late, order pizza), striving to achieve a system goal (e.g., optimise inhabitants comfort) while accounting for each user desires.
According to the TuCSoN meta-model as described in Section II, this can be interpreted as follows: users continuously and unpredictably perform their daily activities. . . . . . which may depend on the environment being in a certain “enabler state” (e.g., food must be available to enable cooking dinner), as well as 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 lights turn on time, there is no food thus I must go to the grocery shop) Once we recognise that activities and environment changes both make events happen, thus managing dependencies between activities and change ultimately amount to managing events, we have a perfect and complete match with TuCSoN reference meta-model.
Modelling & Design: Once the problem at hand (smart home appliances coordination) has being re-interpreted according to the TuCSoN meta-model, TuCSoN architecture provides all the necessary components to build a solution. Thus: activities of users are generated by agents, making it possible to also ascribe goals to actions, and mediated by ACCs, enabling and constraining interactions according to the system goals; changes in the environment are generated by probes and mediated by transducers, enabling a uniform representation of environmental properties despite appliances heterogeneity; both activities and changes (thus ACCs and transducers) generate events as their own representation within the situated MAS coordinated by TuCSoN, which are then managed by tuple centres suitably programmed with adaptable coordination laws.
Consequently, 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 and probes, respectively (e.g., on the smartphone), or remotely (e.g., on the desktop), 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.
Considerations: Notice a similar scenario is depicted in
[
VI.
Comparing the methodological approach discussed here
with the whole lot of AOSE methodologies available
nowadays would be unfeasible for reasons of space. However, it
may easily be noted that the only AOSE methodology that
clearly resembles our coordination-based approach is SODA
[
So, in this paper we introduce the TuCSoN approach to situated coordination in MAS, by describing the support to situated MAS engineering provided by the TuCSoN model and architecture in each typical stage of software development: the abstractions to be used for the requirement analysis step, the architectural components available to model the MAS at hand, the software API to program situatedness-related aspects from a coordination standpoint.
The solutions promoted by the TuCSoN technology to deal with the issues of open and distributed MAS are also highlighted: in particular, the need to rely on mediating abstractions such as ACC, transducers, and tuple centres as the means to decouple individual components (agents and probes) interactions, along with the need for an asynchronous eventdriven communication model to correctly deal with the most common issues of system distribution.