Situatedness in TuCSoN (with ReSpecT)

In this brief "how-to", you will learn TuCSoN and ReSpecT main API available to developers of situated MAS, willing to exploit TuCSoN-provided situated coordination facilities.

Assumptions are you are familiar with TuCSoN core API and ReSpecT programming.

Prior to reading this how-to is highly recommended to read the reference paper on supporting situatedness in MAS:

available from here.

Suggested readings complementing the content of this "how-to" are:


  1. Situatedness in TuCSoN

    1.1 API Overview

    1.2 "Hands-on" step-by-step tour

  2. Contact Information


1. Situatedness in TuCSoN


1.1 API Overview

Situated coordination services in TuCSoN are mediated by transducers, representing sensors, actuators, "environmental resources" in general within the TuCSoN-coordinated MAS--called probes. Thus, designing a situated MAS with TuCSoN amounts at dealing with the following tasks:

  1. implementing probes
  2. implementing their transducers
  3. dynamically instantiating and associating them upon need
  4. implement the situated coordination policies needed by the application at hand

1. Implement Probes. While implementing their probes, developers should adhere to the ISimpleProbe interface, depicted below:

Probes API

Methods readValue/writeValue have to be implemented for sensors and actuators, respectively. These methods should embed the "logic" of interaction with the specific probe, either software (e.g. in a simulation) or hardware (e.g. in a real-world deployment).

Please notice: being creation and association of classes implementing probes and transducers dynamic, within such methods it is good practice to:

  1. check if the association with the transducer has been done. It is good practice to give the probe a private member field storing the id of the associated transducer (as requested by method getTransducer) and to check such field for existence prior to reading or writing
  2. if the association has been done (such field is not null), a reference to the transducer should be retrieved, using method getTransducer of singleton class TransducersManager--whose reference, unique per TuCSoN node, can be obtained by calling TransducerManager.INSTANCE

Once the probe and its transducer have been implemented, run-time creation and association can be achieved by exploiting the Transducers Manager (see point 3 below).

2. Implement Transducers. TuCSoN supports developers in implementing transducers by providing the AbstractTransducer Java class depicted below:

Transducers API

Such class should be subclassed implementing at least one [1] of its protected methods, depending on whether the transducer is responsible for a sensor or an actuator:

For both methods, the most simple and straightforward implementation is to iterate through the protected member field this.probes (storing the list of the probes associated to the transducer) to read/write the value of the environmental property of interest, by using method readValue/writeValue. The method should return a boolean value representing success or failure of the operation.

3. Exploit the Tranducers Manager. TuCSoN provides services for creation, (de)registration, etc. of transducers and probes, which have to be requested through well-formed tuples to be put into the special tuple centre '$ENV’:

The TuCSoN architectural component in charge of executing such management operations is the TransducersManager, whose API is depicted below:

TuCSoN Transducers Manager

4. Exploit ReSpecT programming.

Likewise transducers mediate between environmental resources (the probes) and the MAS, tuple centres mediate between transducers and agents. Tuple centres mediation is necessary because getEnv and setEnv are ReSpecT-only primitives, not accessible to TuCSoN agents. This enforces decoupling and leverages encapsulation as well as separation of concerns.

ReSpecT programming is necessarily application-specific, but a core of general purpose operations to carry out can be devised [3]:


1.1 "Hands-on" step-by-step tour

TBD.

In the meanwhile, you can read through the comments in TuCSoN "Thermostat MAS" example source files, here.


Contact Information

Author of this "how-to":

Authors of TuCSoN in TuCSoN "People" section of its main site, here > http://apice.unibo.it/xwiki/bin/view/TuCSoN/People.


[1] Also both methods can be implemented, e.g. if the transducer is responsible for a probe able to behave both as a sensor and as an actuator.

[2] For both transducers’ and probes' ids the same syntactic rules as those for agent ids and tuple centres ids hold, that is, any valid tuProlog ground term. See tuProlog documentation, here.

[3] What follows is based on the example in package alice.tucson.examples.situatedness, which can be run either by using the bash script TuCSoN_boot.sh or by typing $> java -cp tucson.jar alice.tucson.examples.situatedness.Thermostat in a command prompt (a TuCSoN node should be active on localhost:20504).