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:
Mariani, S., Omicini, A.: "Coordination in Situated Systems: Engineering MAS Environment in TuCSoN". In Internet and Distributed Computing Systems, Lecture Notes in Computer Science 8729, 22-24 September 2014. Available here.
Mariani, S., Omicini, A.: "TuCSoN Coordination for MAS Situatedness: Towards a Methodology". In WOA 2014 – XV Workshop Nazionale "Dagli Oggetti agli Agenti", CEUR Workshop Proceedings 1260, September 2014. Available here.
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. Implement Probes. While implementing their probes, developers should adhere to the ISimpleProbe
interface, depicted below:
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:
getTransducer
) and to check such field for existence prior to reading or writingnull
), 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:
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:
getEnv
is meant for sensor transducers. It "stimulates" the sensor probe to perceive the property of the portion of the MAS environment it can observe (key
parameter), outputting the perceived value in the tuple centre the transducer is bound to.setEnv
is meant for actuator transducers. It commands the actuator probe to modify the property of the portion of the MAS environment it can act upon.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’
:
createTransducerSensor(@Tcid,@Tclass,@Tid,@Pclass,@Pid)
, where:
Tcid
is the TucsonTupleCentreId
of the tuple centre mediating transducer's interactions--must be '$ENV'
Tclass
is the full name of the Java class implementing the transducerTid
is the id [2] of the transducer we are requesting to be created, to be used, e.g., within ReSpecT reactionsPclass
is the full name of the Java class implementing the probe this transducer will managePid
is the id [2] of the probe this transducer will manage, to be used, e.g., for the other management operations listed herecreateTransducerActuator(@Tcid,@Tclass,@Tid,@Pclass,@Pid)
, whose parameters are the same as aboveaddSensor(Class,@Pid,@Tid)
, where:
Class
is the full name of the Java class implementing the probe to be added to the list of those probes managed by the transducer Tid
, which must be already existingPid
is the id of the probe we are adding to the situated MASTid
is the id of the transducer which this probe should be added toaddActuator(Class,@Pid,@Tid)
, whose parameters are the same as aboveremoveResource(@Pid)
, where:
Pid
is the id of the probe to be deregistered and terminatedchangeTransducer(@Pid,@Tid)
, where:
Pid
is the id of the probe whose management should be given to another transducer, which must be already existingTid
is the id of the transducer which should manage the probe from now onThe TuCSoN architectural component in charge of executing such management operations is the TransducersManager
, whose API is depicted below:
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]:
first of all, it is necessary to react to an interaction request issued by an agent toward a probe. The agent request is reified in a tuple, which ReSpecT interprets to call the right operation on the transducer associated to the probe target of the operation (getEnv
or setEnv
)
e.g., in the case of a sensor
reaction(
in(sense(temp(T))),
(operation, invocation),
sensor@localhost:20504 ? getEnv(temp, T)
).
where sensor
is the Pid
of the probe (the Tid
of the associated transducer is automagically retrieved by ReSpecT).
then, it is possible to react to the event of operation completion by the resource, that is, to the environmental event generated (either reactively or proactively) by the probe (getEnv
or setEnv
)
e.g., following previous ReSpecT specification
reaction(
getEnv(temp, T),
(from_env, completion),
out(sense(temp(T)))
).
where from_env
is the guard predicate filtering events coming from the environment (thus, from a transducer).
TBD.
In the meanwhile, you can read through the comments in TuCSoN "Thermostat MAS" example source files, here.
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
).