Building Self-adaptive Software Systems with Component, Services & Agents Technologies: Self-OSGi - Agents and Artificial Intelligence - page 307

respective component plans have been instantiated for a specific robot agent, i.e. Robot1 ,
the services they provide will have an Agent attribute with value Robot1 .However,in
order for the same services to work, they must receive updates, respectively, of location
and video data related to the same robot agent. Both XML descriptions specify this de-
pendency by repeating the attribute ?Agent in the reference elements describing their
required service goals. Self -OSGi will take care to propagate the value of these vari-
able properties from the post-condition/service side to the requirement/reference side,
for instance, to wire a MoveTo component activated for a Robot1 robot agent, with a
LaserLocalization activated for the same robot agent, rather than using the pure syntac-
tic match (which could be satisfied by any localization data, e.g. related to other robots
or used to represent the location of a human user).
Finally, the following code is used to send a robot to a given location by initializing
a standard OSGi ServiceTracker object to request the GoalNavigation service goal, be-
fore invoking it by passing the location coordinates. The special attribute selfosgi=true
is used to demand the Self -OSGi management of the call. Noticeably, no other modifi-
cations are required to standard OSGi programming.

ServiceTracker tracker = new ServiceTracker(...,
context.createFilter("(\&(objectClass
="+GoalNavigation.class.getName()+") (selfosgi=true)").open();
(GoalNavigation)(tracker.waitForService(0)).beAt (100, 200);

In the localization example, these features have been used to make the robot reach its
destination while opportunistically exploiting any suitable localization mechanism, for
instance, starting with the CameraLocalization and then switching to the LaserLocal-
ization if the first fails, e.g. when the ambient light drops below the given threshold.
In order to measure the time needed by Self -OSGi to perform the reconfiguration,
tests were performed using a non-physically realistic simulated robot system, whose
hardware components had no initialization latency, and no inertia. Over 10 runs using a
Pentium dual core at 2.40 GHz with 8GB of SDRAM, with the Sun J2SE 6.0 platform
compliant JVM and running the Linux 2.6.24 kernel, the system was able to recover
from failure with an average of 72ms with standard deviation of 3.78. For compari-
son, a similar dynamic service replacement performed over the Java Beans component
framework and co-ordinated by a standard BDI agent toolkit took an average of 312ms
[11].
The Self -OSGi's management of real and more complex robotic systems has been
recently enabled by integrating Self -OSGi with the PEIS (Ecologies of Physically Em-
bedded Intelligent Systems) middleware [16], and by making it operate across dis-
tributed platforms, thanks to the R-OSGi distributed extension of OSGi [15].

6.2 Service-Selection

Self -OSGi includes a Benchmark bundle to enable developers to assess Self -OSGi per-
formance and estimate the overhead it imposes to specific applications. To this end, the
Benchmark bundle implements a simple simulated test domain, which models a typical
Self -OSGi application where both the set of available component plans, and the set of
service goals are organized in L levels of abstraction.