a middleware to integrate robots, simple devices and everyday objects into an ambient ecology

Pervasive and Mobile Computing 8 (2012) 522–541

Contents lists available at SciVerse ScienceDirect

Pervasive and Mobile Computing

journal homepage: www.elsevier.com/locate/pmc

A middleware to integrate robots, simple devices and everyday objectsinto an ambient ecologyJayedur Rashid, Mathias Broxvall, Alessandro Saffiotti ∗AASS Cognitive Robotic Systems Laboratory, School of Science and Technology, Örebro University, Sweden

a r t i c l e i n f o

Article history:Available online 15 June 2012

Keywords:RoboticsSmart objectsWireless sensor networksAmbient ecologyRobot ecologySmart environments

a b s t r a c t

The fields of ambient intelligence, distributed robotics and wireless sensor networksare converging toward a common vision, in which ubiquitous sensing and actingdevices cooperate to provide useful services in the home. These devices can range fromsophisticated mobile robots to simple sensor nodes and even simpler tagged everydayobjects. In this vision, a milkbox left on the table after the user has left the home couldask the service of a mobile robot to be placed back in the refrigerator. A missing ingredientto realize this vision is a mechanism that enables the communication and interoperationamong such highly heterogeneous entities. In this paper, we propose such a mechanism inthe form of a middleware able to integrate robots, tiny devices and augmented everydayobjects into one and the same system. The key moves to cope with heterogeneity are:the definition of a tiny, compatible version of the middleware, that can run on smalldevices; and the concept of object proxy, used to make everyday object accessible withinthe middleware. We describe the concepts and implementation of our middleware, andshow a number of experiments that illustrate its performance.

© 2012 Elsevier B.V. All rights reserved.

1. Introduction

It is a fact that the average home or workplace today includes a large number of heterogeneous, ubiquitous, oftennetworked computing devices. These include TVs, media centers and mobile phones, often endowed with powerfulcomputational capabilities and running a large variety of applications that extend their functionality well beyond the mainone. Slightly less common devices include burglar alarms connected tomotion detectors, digital weather stations connectedto indoor and outdoor sensors, robotic vacuum cleaners and lawn movers, baby monitors, wireless web cameras, healthmonitoring systems, gaming consoles, and of course personal computers. Devices for home automation based on standardssuch as X10 or KNX are also becoming increasingly common, allowing the remote or automatic control of lights, heaters,air-conditioners, intruder alarms, audio–visual systems and household appliances.

In this context, it is interesting to think of creating new or enhanced services in the home not by adding new devices, butby connecting the existing ones in new,meaningfulways. Two ormore home devices engaged in a collaboration patternmaybe able to perform tasks and services that cannot be performed by either one alone. As a simple example, if the automaticvacuum cleaner is able to receive and use information from the home intruder detection system, then it can provide thenew service ‘‘clean whenever nobody is at home’’. In this paper, we generically refer to a set of computing devices in theenvironment that are able to engage in collaboration patterns as an ambient ecology.

The creation of ambient ecologies requires the existence of a common communication and collaboration mechanismthrough which the different devices can be integrated into one consistent system. This mechanism should be able to cope

∗ Corresponding author.E-mail addresses: [email protected] (J. Rashid), [email protected] (M. Broxvall), [email protected] (A. Saffiotti).

1574-1192/$ – see front matter© 2012 Elsevier B.V. All rights reserved.doi:10.1016/j.pmcj.2012.06.003

http://dx.doi.org/10.1016/j.pmcj.2012.06.003

http://www.elsevier.com/locate/pmc

http://www.elsevier.com/locate/pmc

mailto:[email protected]



http://dx.doi.org/10.1016/j.pmcj.2012.06.003

J. Rashid et al. / Pervasive and Mobile Computing 8 (2012) 522–541 523

with the intrinsically dynamic nature of ambient ecologies, in which devices may be added or removed at any time—e.g., anew device comes into communication range, or an existing device is turned off. The addition or removal of devices, as wellas the dynamic establishment of cooperation patterns among them, should happenwith no orminimalmanual intervention.In other domains, like ambient intelligence (AmI) or network robot systems (NRS), mechanisms of this type are providedby a suitable shared middleware (see Section 7). Ambient ecologies, however, have requirements that go beyond what istypically covered by the existing mechanisms. One such requirement is the need to accommodate highly heterogeneousdevices, which may differ greatly in shape and function, but also in their computation, memory, and bandwidth capability.An ambient ecology may contain a mixture of powerful devices based on a PC or large embedded system, simpler devicesbased on small microcontrollers or wireless sensor nodes (motes), and even everyday objects augmented with minimalisticdevices like RFID tags.

The goal of this paper is to propose a communication and collaboration mechanism for ambient ecologies that satisfiesthe above requirements, with a specific focus on dynamicity and heterogeneity. We start from an existing middleware thatwas developed in the area of network robot systems, called the Peis-Middleware. This middleware provides the requireddynamicity, but it relies on the relatively powerful computation capabilities usually present on mobile robots. We thenextend this mechanism in two steps in order to allow highly heterogeneous devices. First, we define a ‘‘tiny’’ version ofthe Peis-Middleware, which implements the same communication and cooperation model but can be run on small deviceswith only minimal computational and communication resources. Second, we define the notion of ‘‘object proxy’’ as a wayto include in the ambient ecology everyday objects like books, dishes, glasses or pieces of furniture. This paper builds uponour previous work [1–3], but it provides two important novel contributions: it integrates the previous, separate work onthe Peis-Middleware, its tiny extension, and the proxy-based approach into one coherent framework; and it presents anextensive experimental evaluation of the integrated framework.

The rest of this paper is organized as follows. In the next section, we provide the needed background by introducing thegeneral framework used in this paper, called Peis-Ecology. The next three sections give the details of our three step approach:Section 3 deals with the full middleware; Section 4 with its extension to tiny devices; and Section 5 with its extension toeveryday objects. We then report several quantitative and qualitative experiments in Section 6. Finally, we discuss somerelated work in Section 7, and conclude.

2. A reference framework: Peis-Ecology

The techniques that we introduce in this paper are to a large extent independent on the details of the underlying ambientecology framework, and could in principle be described in general terms. For the sake of clarity, however, we shall describethem in the context of the specific framework which we have used in our concrete realization, called Peis-Ecology. We nowreview the main ingredients of this framework: more details can be found at the Peis-Ecology web site [4].

The concept of Peis-Ecology was initially proposed by Saffiotti and Broxvall [5] as a new approach to introducerobotic technologies in domestic environments. This approach is based on an ecological view of the robot–environmentrelationship [6]: the robots and the environment are seen as parts of the same system, engaged in a symbiotic relationship.

In the Peis-Ecology approach, the notion of robotic device is abstracted through the notion of a Physically EmbeddedIntelligent System, or Peis.1 A Peis is any device in the environment that incorporates some computation and communicationresources, and possibly some sensing and actuation capabilities. These devices may range from complex humanoid robotsdown to simple household items with embedded controllers. From a logical viewpoint, a Peis is a set of inter-connectedsoftware components, called Peis-components, residing in one physical entity. Each componentmay include links to sensorsand actuators, as well as input and output ports to connect it to other components in the same Peis or in another Peis.

An ecology of Peis, or Peis-Ecology, consists of two main elements. First, a set of Peis that are pervasively distributedin the environment in the form of sensors, actuators, smart appliances, active tagged objects, or more traditional mobilerobots. These Peis may be highly heterogeneous, and they may dynamically join or leave the ecology at any time. Second,a communication and cooperation model that allows these Peis to exchange information, while coping with the aboveheterogeneity and dynamicity aspects.

A concrete realization of the concept of Peis-Ecology must address both the communication and integration of theconstituent components, and the individual functionalities of each component. Important functionalities to be providedinclude introspection and configuration of multiple components as well as the establishment of a suitable collaborationmechanism. Commonly these functionalities are provided by a middleware, which acts as a collaboration layer betweenall devices, lifting the complexity of low-level communication and hiding the heterogeneity of the underlying systems. Ina Peis-Ecology, such middleware must satisfy a number of requirements that stem from the above concepts: to providea shared memory model; to provide simple mechanisms for introspection and for dynamic configuration; to have a smallfootprint suitable for both small embedded devices and larger computers; to support different hardware, operating systems,and communication protocols; to scale up smoothly as the number of devices increases; and to cope with the appearanceand disappearance of devices (or group of devices) from the network. Finally, the open and dynamic nature of a Peis-Ecology suggests that a middleware for it should be fully decentralized.

1 Peis is pronounced /peIs/ like in ‘pace’.

524 J. Rashid et al. / Pervasive and Mobile Computing 8 (2012) 522–541

TC, PTL, Player, Cam, CS Vision,Fridgedoor, Nose, HUI-server, ...

Semantic discovery,Configurator

PEIS, Init,Tupleview

Tuplespace

PE

IS-kernel

PE

IS-m

iddleware ...

Hardware & Operating system

Network communicationDiscovery, P2P, ...

Topology,Debugging

Fig. 1. The application stack used for individual Peis-components.

Although a large number of middlewares have been proposed in the fields of robotics and of ambient intelligence (seeSection 7), none of them fully satisfies the above requirements. We have therefore developed a specific middleware tailoredon the Peis-Ecology concept, called Peis-Middleware.2 This implements a fully decentralized communication model basedon a distributed tuple-space, and runs on a wide range of platforms ranging from powerful mobile robots to very basicsensor nodes. These platforms may differ in computational power and bandwidth by several orders of magnitude. Oneway to manage this large difference is to restrict the capabilities of the middleware to the lowest common denominatoramong all the target devices. In the Peis-Middleware, we have opted for a different approach: we have developed twocompatible versions of the middleware, one for devices with full-scale processors, and one for simpler devices based onmicro-controllers. Both versions hide all network and communication details, and allow for transparent and seamlesscollaboration among and across the two families of devices. These two versions of the Peis-Middleware are called Peis-kernel and Tiny Peis-kernel, respectively, and they are described in the next two sections.

3. The Peis-Ecology middleware

We now describe the Peis-Middleware, the full fledged implementation of the infrastructure needed to realize the Peis-Ecology concept described above. The basic concepts of this implementation, however, are shared by the ‘‘tiny’’ version,which will be described in the next section.

3.1. Software stack

The Peis-Middleware is a set of software libraries and tools that allow a developer to implement a Peis-Ecology, tovisualize its state, and to debug it. The tools and libraries are available for many platforms and programming languages(C/C++, Java, LISP). They are organized in the Peis-kernel software stack, which is visualized in Fig. 1.

At the bottom, we rely on a standard posix compliant operating system and hardware, like Linux or MacOS running onPC or PC/104 computers. Above this lays the Peis-kernel library. This library utilizes the available communication devices,such as network cards or bluetooth interfaces, to establish a peer-to-peer (P2P) network between all Peis-componentsrunning on the different machines in the neighborhood. This allows even Peis without a direct means of communicationto communicate.

2 The PEIS-Middleware and related software components are published under an OpenSource license, and are available in the project website:http://aass.oru.se/~peis.

http://aass.oru.se/~peis


176 bytes

Owner Creator Timestamps Meta Keys/subkeys Data

4 4 24 16 128 1..231

Fig. 2. Contents and size of a Peis-tuple.

The decentralized nature of this P2P network allows for dynamically changing topology and devices appear-ing/disappearing from the network. The primary interface to this network is the capability of detecting devices, routingunicast and broadcast messages reliably at different virtual ports. In this multi-hops routing we use the standard weightedrandom early detection (WRED) [7] congestion control algorithm to ensure a higher QoS for control messages and metadata. Interestingly, this routing allows devices which have mutually exclusive communication methods such as wirelessLAN (802.11) and ZigBee (802.15.4) to still communicate using any set of intermediate Peis as a bridge. Additionally, thislayer provides a mechanism for registering callable functions as hooks to be invoked periodically, or upon different eventssuch as receiving specific messages.

At the next layer, we utilize this P2P network to implement a number of different services. The most important of theseis a distributed tuplespace, which is described in detail in the next subsection. Other services include synchronization of adecentralized network clock, and various debugging functionalities. The P2P layer together with this service layer constitutethe Peis-kernel library. Any Peis-component that should participate in a Peis-Ecology is run as a normal user-space processlinked to this library.

In addition to the basic functionalities implemented in the Peis-kernel, the Peis-Middleware includes a number ofstandardized Peis-components such as a visualization and debugging components (tupleview), automatic configurators,and the PeisInit component. The latter is most relevant to the goals of this article. The PeisInit component is startedon boot-time on every PC based platform; it provides semantic information about all the other components whichmay runon that platform; and it dynamically starts, stops andmonitors the execution of those components. Formore details on thesecomponents we refer the readers to Broxvall et al. [8].

3.2. Tuplespace

As a shared memory model for communication and coordination, the Peis-kernel implements a Linda-type distributedtuplespace [9], augmented with an event mechanism.

In a Linda-space, tuples containing keys and other data can be stored and retrieved by any participating process. In ourversion of this space, a Peis-tuple consists of a name-space, key, data as well as several meta-attributes such as timestampsand expiration date—see Fig. 2. A component corresponding to the name-space is called the owner of the tuple. The key isa string consisting of dot-separated fields (currently up to seven), e.g., camera.position. Wild-cards are allowed in fields,e.g., *.position to allow associative searches.

We also allow the use of abstract tuples, that is, tuples in which one or more fields contain a wild-card value. An abstracttuple is said tomatch a concrete (fully instantiated) tuple if all the non wild-card fields are equal to the corresponding fieldsof the concrete tuple. Abstract tuples allow us to make associative searches in the distributed tuplespace. These searchesresult in the subset of all tuples that is generalized by the given abstract tuple [8].

In addition to reading, the Peis-kernel allows remote components to update tuples in the tuplespace. This capability ispivotal to enable actuation over the network. When a component writes a tuple with a specific name-space and key, thekernel sends amessagewith awrite request to the owner of that tuple. The owner is responsible for synchronization, servingrequests in FIFO order: this circumvents many problems with decentralized databases and provides some load balancing.The tuple owner commits the write in its local memory and sends a notification to all components which have registered aninterest in this tuple. Components can register an interest in specific tuples by means of a subscription mechanism, makingsure that they will continuously receive updates whenever that tuple is written. Subscriptions are typically made usingabstract tuples containingwild-cards thatmatch zero ormore specific tuples. Subscriptions andnotifications are transmittedover the P2P network and are guaranteed to be delivered in order.

Whenever a component receives a tuple change notification, it invokes any user specified hook associated with atuple generalizing the updated tuple, and stores the tuple in a local cache. Retrievals from the local cache of tuples areinstantaneous, and do not incur any network overhead. This allows the use of both asynchronous and instant read by value(polling) access to the tuples, as well as callback access, again using abstract tuples matching zero or more specific tuples.

To establish a given pattern of communication and collaboration between a given set of components, a Peis-Ecology designer typically creates the right set of tuple subscriptions and callbacks among those components. This set iscalled a configuration of the Peis-Ecology. The Peis-Middleware allows a dynamic configuration mechanism, in which adesigner as well as any Peis-component can create and remove subscriptions at run-time. This mechanism is based on the


notion of meta tuples, which contain a reference by name to other tuples. The configuration problem is out of the scope ofthis paper, and we refer the curious reader to Rashid and Broxvall [10] for a detailed discussion of meta-tuples and their usefor run-time configuration.

4. Including tiny devices

To allow tiny devices to take part in a Peis-Ecology on-pair withmore powerful devices,we have developed a light-weightversion of the Peis-Middleware which implements the same model using minimal computational and communicationresources. We call Tiny Peis-kernel this version. In what follows, we describe the requirements and the design of the TinyPeis-kernel.3 These requirements make precise what we mean by ‘‘tiny’’ devices. An empirical evaluation of the Tiny Peis-kernel will be shown in Section 6.

4.1. Requirements

The main requirement for the Tiny Peis-kernel is of course full compatibility with the full version described in theprevious section. More specifically, a Peis-component A should interact with another Peis-component B in the same way,irrespective of whether B is running on a normal device (Peis, via the Peis-kernel) or on a tiny device (tiny Peis, via the TinyPeis-kernel).

The second requirement is that the Tiny Peis-kernel should run on a wide variety of ‘‘commercial off the shelf’’ (COTS)devices aswell as custom-built ones. In otherwords, a tiny Peis should not be restricted to exist only on some specific, ad hocplatform. Examples of COTS devices of interest include wireless sensor network (WSN) motes [11–13] and low-cost micro-controller boards [14]. There are two facets to this requirement: the amount of computation and communication resourcesneeded to run the Tiny Peis-kernel should be commensurate to commonly available small devices; and the underlyingoperating system (OS) should be highly portable.

Regarding computation, most of today’s COTS embedded devices have no more than 10 KB of RAM and a few hundredsKB of programming memory. Accordingly, we require that our Tiny Peis-kernel uses at most 4 KB of RAM and 40 KB ofprogrammingmemory. Tomaintain generality, we do not assume that an external programming flash is available. Regardingcommunication, most of these devices support the IEEE-802.15.4 or ZigBee network standard. This has relatively smallpacket size (127 bytes), low bandwidth (250 Kb/s) and short communication range (30–60 m indoor). Accordingly, werequire that our Tiny Peis-kernel supports the same standard. As we discuss below, this entails the need to resize the tuplestructure to fit the small packet size.

As for portability of the underlying OS, we have decided to rely on TinyOS [15,16], a small, event driven, open-sourceoperating system developed within the WSN community. TinyOS is available on a wide selection of commercial platformsand it is portable to nearly every architecture for which a C compiler is available [17]. In addition, TinyOS provides thePHY/MAC layers implementation of the IEEE-802.15.4 and ZigBee network standard.

4.2. Tiny Kernel

The Tiny Peis-kernel implements a software stack similar to the one of the regular Peis-kernel. Any tiny device whichruns the Tiny Kernel is called tiny Peis, and can participate in a Peis-Ecology involving both regular and tiny Peis.

The underlying P2P network in the Tiny Kernel relies on the Active Message (AM) communication stack, which isavailable with TinyOS-2.0 distribution and is asynchronous by nature [18]. To ensure the reliability at the tuplespacelevel, the Tiny Peis-kernel includes additional features such as acknowledgment of non-broadcast packets. Notice thatthe acknowledgment mechanism provided by AM is not sufficient in our case, since packets transmitted between regularPeis and tiny Peis use two different communication protocols. The Tiny Kernel handles the dynamic nature of the Peis-Ecology by broadcasting periodic beacon messages. Any Peis (tiny or regular) in the network is aware of the presence of atiny device by receiving these messages. If beacon messages are no longer received from a device, the other Peis assumethat it has left the ecology.

Like the regular Peis-kernel, the Tiny Peis-kernel implements a Linda-like distributed tuplespace through the event-based publish/subscribe paradigm. The Tiny Kernel, however, replaces the stateful subscriptionmechanism by a stateless, orperiodic one. The stateful approach requires routing information of existing network, which costsmorememory, processing,energy and network bandwidth than the stateless one. This difference is hidden to the application developer by the kernel.

Like the regular Peis-kernel, the Tiny Kernel allows not only reading but also writing, creating, and updating of tuples inthe distributed tuplespace, thus enabling actuation functionalities along with sensing. Synchronization is solved like in thePeis-kernel: all the write/update requests are sent to the tuple owner, and are executed in FIFO order. It should be notedthat a bottleneck may arise if a tiny device owns a tuple which is highly demanded. This is usually not the case, since tinydevices typically provide few services at a low frequency, and hence access to their tuples is moderate. For example, a motecontrolling a lamp typically receives few write requests from just a few components.

3 The work on the Tiny Peis-kernel described here builds upon and extends the preliminary work reported in [2].


Owner Creator Timestamps Meta Keys/subkeys Data

4 4 12 2 2..14 56..68

22 bytes 70 bytes

Fig. 3. Contents and sizes of a tiny-tuple.

If a tuple managed by a tiny device is highly demanded, one can use the mechanism ofmeta-tuple described at the end ofthe previous section, to store that tuple elsewhere. For example, consider a mote controlling a PTZ (pan-tilt-zoom) camera,which may receive several conflicting positioning requests in an input tuple. A plausible design is to make this mote take itsinput from ameta-tuple, which points to a remote tuple, say ptz-request, stored in a full Peis. Devices send their requestby setting the ptz-request tuple, and the burden of arbitrating conflicting requests is taken by the full Peis. Notice thatredirection of the mote input via the meta-tuple can be done at run-time, taking factors like load balancing into account.

4.3. Tiny tuples

We have redesigned the Peis-tuple structure to a much more compact format, called tiny-tuple, as shown in Fig. 3. Themain rationale is to be able to send a tuple in a single network packet (less than 100 bytes payload for safe transmission)and to store several tuples in the limited RAM available. The tiny-tuple has a fixed 22 bytes header and a 70 bytes storagefield (tuple key plus data). The tuple key consists of maximum 7 sub-keys, each represented as a short integer of two bytes.The data field has variable length, depending on how many sub-keys are used.

The tiny tuple format has several practical limitations compared to the standard one. All time-stamps are 32 bits (ratherthan 64 bits) thus reducing the resolution; keys are limited to 14 bytes (rather than 256 bytes) thus reducing the maximumnumber of possible keys and sub-keys; and data size is limited to 68 bytes (rather than 231). The last limitation is usuallynot a problem for tiny devices, which typically only need to exchange a few bytes of sensor data or control values.

Since full Peis and tiny Peis rely on different network standards and different tuple formats, we need to include one ormore bridge devices to allow them to exchange tuples, and hence to be part of the same Peis-Ecology. We call any suchdevice a Tiny-gateway. This is composed of a tiny Peis connected to a full Peis through a dedicated channel, plus a translatorPeis-component. Typically, we use a WSN mote for the tiny Peis, and we connect it via a USB serial port to a regular PC onthe IEEE-802.11 network. The mote reads from the IEEE-802.15.4 network and writes to the serial port, and vice versa. ThePeis-component on the PC reads from the serial port and sends data to the IEEE-802.11 network, and vice versa.

The translator Peis-component in the Tiny-gateway performs several tasks. First, it translates between the regular andtiny tuple formats. This includes the translation between the sting key names used in the Peis-tuple and the numeric keyindexes used in the tiny-tuple, using a central naming registry. Second, it applies a mechanism for the conversion betweenstateless and stateful subscriptions. Optionally, there can be an acknowledgment mechanism for network efficiency,particularly for this subscription messages conversion. Third, it performs multi-hop routing on behalf of the tiny nodesunder the coverage of this Tiny-gateway. Finally, it broadcasts a periodic beaconmessage containing the ID of its tiny device,so that all tiny nodes under its coverage can discover it at run-time. Notice that the presence of the Tiny-gateway and itstranslations are fully transparent to the applications running in the nodes of both networks.

When several Tiny-gatewayes are available, the TinyKernel selects one by a simple local arbitrationmechanism, i.e., usingthe packet’s signal strength of the beaconmessages received from each Tiny-gateway in range. By grouping tiny devices intodifferent clusters based on the choice of a gateway, one can easily scale up the system into large networks. For routing, eachnode transmits itsmessages to the gateway of its cluster, and the gateway routesmessages through the generic P2P network.

4.4. Example implementation on TinyOS

The TinyOS component graph of the Tiny Peis-kernel is shown in Fig. 4. The PeisKernelC is the TinyOS componentfor the Tiny Peis-kernel and it provides one prime interface4, PeisTuple, and some commands: currentTime(),isKernelRunning() and tinyPeisId(). These commands provide current running time of the embedded device forinstance motes since the beginning, the running status of the Tiny Peis-kernel, and the Peis-id of the running componentconsecutively. Here we describe different composition components of the PeisKernelC.

PeiskCommC: This layer is the wrapper of the TinyOS Active Message communication stack. It provides PeiskSend andPeiskReceive interfaces for sending/receiving data to/from the network. All network packets formation and extractionbetween the kernel and the Active Message are done in this layer.

4 We do not mention common interfaces such as Init for initializing a component.


Fig. 4. Component diagram of Tiny Peis-kernel. All boxes and arrows represent components and interfaces respectively.

Tuple layer(TuplesM): TuplesM module implements the distributed tuplespace. It provides PeisTuple interface, whichcontains TinyOS commands and events for accessing tuples such as initializing, reading and writing to a tuple as well assub/unsubscription requests to tuples in either the local or a remote tuplespace.

When a sub/unsubscription request for a tuple is made by the application program using the PeisTuple interface,this layer checks whether the request is for the local or the remote tuple. If the request is for the latter, the request isplaced to kernel regardless of a tiny Peis or a full-Peis. However, to use the memory efficiently and to get rid of unnecessarysubscriptions e.g. a component leaves the ecology and does not unsubscribe the interested tuples, this layer periodicallydeletes all subscriptions received from networks.

Kernel layer (PeisKernelM): This module implements the basic functionalities of the kernel mentioned in Section 4.2. Itprovides several commands and two interfaces and uses PeisCommC component to send messages to the network.

For managing P2P network topology, we have used only single-hop routing among WSN nodes in this implementation.To send a packet to a remote nodewhich is beyond the single-hop neighbors, the kernel sends it to the nearest Tiny-gateway,which forwards the packet to the ultimate destination.

To manage different messages reliably this layer uses priority queue. Messages, which are necessary for keepingthe network up and running, have the highest priority. Therefore the beacon messages have highest priority. Theacknowledgment packages have second priority since packet re-transmission costsmemory, processing and communicationbandwidth. Rest of the messages for instance tuples and subscription requests are given lowest priority. A queue packet,which needs to be acknowledged, is resent up to three times in this implementation.

5. Including everyday objects

Our next step in extending the range of devices that can be included in an ambient ecology is to consider the integrationof everyday objects like books, dishes, glasses or pieces of furniture. We shall pose a requirement on these objects: that theyhave been augmented with some type of communication means, like a ZigBee or a BlueTooth transmitter, or simply an RFIDtag. We shall not assume that these objects are augmented with a computational device which able to run any middleware(e.g., the full or tiny Peis-kernel) on-board. Our minimalistic requirement covers a wide range of objects: e.g., all those towhich an RFID tag can be easily attached, and the growing number of those to which an RFID tag has already been attachedby the vendor for logistic reasons.

Our approach to integrating everyday objects is based on the notion of object proxy. An object proxy, or simply proxy,is a process hosted by a component of the ambient ecology, which acts as a unique representative, inside the ecology, of agiven everyday object. The proxy uses the common middleware to interact with the other components in the ecology, andit uses a dedicated interface to interact with the proxied object. Intuitively the proxy maintains a unique, shared image ofthe everyday object within the middleware, and it keeps the information in this image synchronized with the properties ofthe actual object using the dedicated interface. Through themediation of the proxy, then, any component in the ecology caninteract with an everyday object as it does with any other component, and vice versa. As we shall shortly see, this simpleidea is complicated by a few factors: (i) proxies are created and destroyed dynamically to reflect the physical presence of


the corresponding proxied objects; (ii) a proxy may use several interfaces to communicate with its proxied object; and(iii) a proxy may hold more information about the proxied object that what is communicated by that object.

In the rest of this section we make the idea of object proxy more precise. We do it in two steps: first we describe it ingeneral as a design pattern; next we describe a specific implementation in the Peis-Ecology framework.

5.1. The design pattern for object proxies

In software engineering, design patterns are used to describe general, reusable solutions to common problems. We nowdescribe a design pattern to include everyday objects in an ambient ecology. The design pattern consists of four ingredients:Proxied-objects: These are the target everyday objects, augmentedwith a communication device, and possibly withmemory,sensors or actuators. Examples include amilk boxwith anRFID tag that stores information like type of product and expirationdate; and a bedwith a ZigBeemodule connected to a pressure sensor, that provide information about the current occupancyof the bed.Interface: An interface is any component in the ambient ecology which can interface to a proxied object through the corre-sponding communication channel. Examples include an RFID tag reader inside a refrigerator, and a ZigBee radio base station.Notice that at our abstraction level an interface comprises both the communication device and the software component thatcontrols it and exposes it to the ambient ecology middleware. This component need not perform any substantial operationor interpretation on the communicated data, but only to relay the raw data to make them accessible to the rest of the ecol-ogy through the common middleware. Note that we do not require the same interface component to communicate with aproxied object at all time, but only that some interfaces can communicate with the object some of the time.Proxy: This is the software component that acts as representative of the proxied everyday object to all the components inthe ambient ecology via the middleware. The proxy receives data from the (attached device in the) proxied object throughone or several interfaces, parses these data according to the object-specific semantics, and publishes to the middleware.It also receives data and commands from any other components which are intended for the object, translates them, andpasses them to the proxied object through the interface(s). Notice that each proxy is specific for a given type of object, andit incorporates semantics for that object: for example, a ‘‘GreatProducer Milk’’ proxy would know the semantic of the datastored in the RFID tag of milk boxes from producer GreatProducer, and use this semantics in the above translations.We shallshortly discuss how to select the right proxy for a given object.

In general, a proxy may contain three types of information about the proxied object: information polled from the object,called direct information; prior information built into the proxy for the specific type of proxied object; and informationabout the proxied object which has been deduced by some other component, called indirect information. In the case of theabove proxy for ‘‘GreatProducer Milk’’, direct information would include the expiration date read from the RFID tag; priorinformation would include the producer’s customer service number; and indirect information would include the currentlocation of the milk box (e.g.: refrigerator) provided by the RFID interface which has detected it—or by the interface withhighest signal strength if several interfaces have detected the object.

Proxy manager: Coping with a dynamic environment requires the dynamic creation and removal of proxies as proxiedobjects appear in and are removed from the environment. A proxymanager is a general component which is responsible forthe instantiation of proxy components as interfaces detect new objects. To do this, the proxy manager relies on a signaturemechanism: each proxied object must provide a signature, which can be recognized by the interfaces that can communicatewith that object; and each proxy componentmust be associated to a set of signatures corresponding to the objects for whichit can act as proxy. Associations may be stored inside the proxy manager, or otherwise accessible to it—e.g., via Internet. Forinstance, the above milk box could provide a unique ID for GreatProducer in its RFID tag data; and the above milk box proxycould be associated to this ID and the contents code for ‘‘milk’’. The job of the proxy manager is to dynamically associateproxy components to proxied objects through interfaces using these signatures. If a suitable proxy component is availablebut not running, the proxy manager creates an instance of this proxy and starts it.

Fig. 5 shows an example of the above design pattern. Here, we proxy a milk-box in the context of a larger system thatalso includes a mobile robot named Astrid. When the RFID-tag attached to the milk box is detected by the RFID reader, thecorresponding interface forwards the signature of the milk box to the proxy-manager. The proxy manager compares thissignature with the latent proxies database and starts the proxy program corresponding to the GreatProducer milk, herecalled milk-proxy, giving it also the ID of the interface that has detected the milk box. The milk-proxy component thencommunicates with this interface, receives the data read from the RFID tag, translates them, and publishes the translatedinformation to the tuplespace. The proxy also gets from the interface information about its location, e.g., ‘‘refrigerator’’, andpublishes this information as the coarse location of the proxied object. Whenever the robot Astrid needs to get informationfrom the milk box, it sends queries to the milk-proxy component through the middleware, which answers on behalf of themilk box object.

Fig. 6 shows the internal structure of a proxy for a vacuum cleaner. In this example, a few objects have been attached asmall XBee IEEE-802.15.4 communicationmodule tomake them accessible to the ecology: a cupwith a temperature sensor,a sofa with a pressure sensor, and a Roomba robotic vacuum cleaner. Interesting, in the latter case the reason to use theproxy design pattern to include the vacuum into the ecology is not that the Roomba does not have enough computationalresources to run the ecology middleware, but that its closed system does not allow us to run the middleware on-board.


Fig. 5. Conceptual example of the design pattern.

Fig. 6. Inside a sample object proxy for a vacuum cleaner. In this example all objects use the same communication channel, i.e., ZigBee.

The XBee device is used to make the proxy communicate with the cleaner using its specific protocol. In this example, threeXBee modules are deployed as interfaces at different locations in the environment. The proxy component is responsible forselecting the most suitable interface, when multiple modules simultaneously perceive the vacuum (box A in the figure),e.g., by selecting the one with highest RSSI (received signal strength indicator). The proxy communicates with the actualhardware via the selected interface. Note that other proxies may use the same interface to communicate with other objects,e.g., a sofa proxy or a cup proxy: the vacuum proxy will only use data from the interface that is recognized as originatingfrom the vacuum.

The vacuum proxy makes the translation of data between the format used inside the ecology and the protocol used bythe hardware, as indicated in the gray boxes in the figure. In addition, the proxy also maintain indirect information aboutthe coarse location of the vacuum, labeled ‘‘MyPosition’’, derived from the position of the interfaces. (More sophisticatedtechniques could also be attemptedbased on the location and correspondingRSSI of all interfaces.) Finally, the proxy includessome prior information for this specific object, e.g., its color, shape, capabilities, and so on. This information can be used, forinstance, by a deliberation module in the ecology to decide how to use the object.

5.2. The Peis-Ecology implementation

Since in the Peis-Ecology the PeisInit component (described in Section 3) publishes the semantics of the componentsinstalled in the corresponding Peis, we use the PeisInit as a distributed signature database, associating object signaturesto the latent proxies which are installed in any given Peis. Below we describe how the other generic components areinstantiated in the case of the Peis-Middleware.


Interface Peis-components. The simplest example of an interface component is the RFID reader component. This is connectedvia a serial port to a Texas Instruments RFID reader and continuously publishes three types of tuples: position, the locationthe reader; tags, a list of all tags x currently detected by the reader; and tags.X.data, the data stored in tag X . Similarinterface components have been implemented for other channels, e.g., ZigBee radio link.Peis-proxy. In the Peis-Ecology, proxies have been implemented as Peis-components running on board one of the homemonitoring computers in the test-bed environment. Each proxy consists of a separate Unix process linked against the Peis-kernel. The proxies are started and monitored, like any other Peis-component, by the PeisInit component residing on thecorresponding Peis. The decision to start a new proxy is taken by the proxy manager, which sends the start up request aswell as initialization parameters through the tuplespace.

Consider for instance the proxy for our RFID tagged milk box. The initial parameters given by the proxy manager tothe proxy are, e.g., the serial number of the tag, say X . Using this serial number, the proxy performs an associative searchin the tuplespace to return the data for any interface I that publishes a tag I.tags.X.data matching this serial number. Ifmultiple interfaces provides the same tag’s data, the proxy selects one using its arbitration criterion, in this case, the link-strength of interfaces. By interpreting the data in the tuple, the proxy can retrieve and properties about the object. The proxyalso retrieve the position tuple from the interface I , and uses this to deduce the position of the proxied object.The Peis-proxy manager. This is a Peis-component that monitors all the existing interface components to listen for theappearance of new proxied objects by subscribing to the I.tags tuple from any interface I . When this tuple is changed,the proxy manager receives a new list of signatures corresponding to the tags within range of the interface. These are thencompared to all running proxies, and unless a proxy is already running for each signature a new proxy is started via PeisInit.To knowwhichproxy component to start, the proxymanager uses the semantic informationpublishedby the various PeisInitcomponents currently running in the ecology.

6. Experiments

Wenow report experimental results that demonstrate the practical viability of the proposedmiddleware.We first reportexperiments aimed at assessing, in a quantitative way, the performance of the heterogeneous P2P network maintained bythe Peis-middleware. We then report experiments that show, in a qualitative way, the applicability of our framework in afew concrete case studies.

6.1. Quantitative experiments

Some commonmetrics are used in the literature to analyze the performance of realisticwireless sensor networks [19–21].These include: received signal strength indication (RSSI), throughput, delay, and energy consumption. At the abstractionlevel of the Peis-middleware, however, two metrics are more relevant: reliability, that is, the ratio of abstract packets thatare correctly transmitted over a time span; and visibility of a component from the other ones as long as the former is part ofthe network. Reliability is a critical property in highly heterogeneous systems, in which very simple devices share the samenetwork with powerful ones. Visibility is an important property in distributed systems, in which each component in thesystem must be continuously aware of the presence of other components in order to share functionalities. Since ambientecologies in general, and Peis-Ecology in particular, are highly heterogeneous distributed systems, it is important to evaluateboth the reliability and visibility of the Peis-middleware.

6.1.1. Performance metricsInwhat follows,we study visibility and reliability for networks consisting of full-Peis and of tiny-Peis. Proxied-Peiswould

not add a meaningful contribution since they do not run any kernel on-board, therefore we do not include them in ouranalysis. We begin by defining how we measure visibility and reliability.Visibility. In the Peis-Ecology framework, any Peis-component broadcasts a periodic network beacon message. This is usedby other components in the network to realize the presence of that component. Conversely, the absence of beaconmessagesfrom a component indicates that the component is unavailable in the network at this time. Therefore, we relate the visibilityof a node in the network to the number of missed beacon messages.

More precisely, given a fixed interval of time T , we denote by NsentB the number of beacon messages sent during T . Since

beacons are sent periodically, the value of NsentB can be estimated a priori. We also denote by Nmiss

B the number of beaconmessages missed during T . We know what beacons have been missed since beacons are sent periodically. The receivedbeacon message ratio, then, is given by

x = 1 −missing beaconstotal beacons

= 1 −NmissB

NsentB

. (1)

The reason why we count missing beacon messages instead of received ones is that a node is marked as non-visible(e.g., it has been turned off or it has physically left the network) when it stops broadcasting, that is, after a certain numberof expected beacon messages are not received. Therefore, missed beacons are the critical measure for visibility.


If we deem a node non-visible after a single beacon message is missing, than the time during which the component maybecome invisible once is Tvisibility =

∆t1−x , where ∆t is the beacon sending period. In general, if we deem a node non-visible

after c consecutive missing beacons, we have

Tvisibility =∆t

(1 − x)c(2)

where we assume probabilistic independence of beacon messages. We call the c the sensitivity of visibility. For instance, if∆t = 4, x = 0.8 and c = 2, we expect the node to become non-visible once in 100 s.Reliability. In the Peis-Ecology framework, a consumer Peis-component can subscribe to tuples of a given type from a givenproducer Peis-component.When this is done, the consumer Peis-component should receive all tuples of that type generatedby the producer Peis-component. Moreover, these tuples should arrive in the order inwhich they are produced. Accordingly,we define reliability as the accuracy of sending and receiving data as tuples between components, and we measure it by theratio of correctly received tuples over the total number of tuples sent.

For example, consider a temperature sensor Peis-component, Tpc, which takes temperature measurements at 1 Hzfrequency, and publishes each measurement as a tuple with key Tpc.temperature. Consider then a monitoring Peis-component, Mpc, which subscribes to these tuples. Full reliability means that Mpc receives in average one temperaturereading per second from Tpc, and that these readings arrive in the same order as they have been generated.

More generally, consider P producers and C consumers. Let Si denote the number of tuples generated by producer i over agiven time span, and sent to all its subscribed consumers. Let Rj denote the number of tuples correctly received by consumerj over the same time span. The reliability over the given time span is measured by:

RelP,C =total correctly received tuples

total sent tuples=

Pj=1

Sj

Ci=1

Ti

. (3)

Comments. There are of course several ways in which the system could been benchmarked. We have chosen to use visibilityas a benchmark for scalability, since this reflects a common service that eachmote performs at a regular interval: the beaconmessages can be thought of as a dedicated sensor reading, one that we know is present in any deployment of the system.

The results below suggest a smooth degradation of performance when more than ten tiny-Peis are in the same cluster.The full version of the Peis middleware has been tested with up to thousands of components without degradation ofperformance. In practice, more tiny Peis can be included by grouping them in different clusters, that reside on separateislands connected by different gateways.

6.1.2. Tested situationsIn our experiments, we have systematically analyzed two paradigmatic types of situations:

• N full Peis-components are subscribed to one tiny Peis, and• N full Peis-components are subscribed toM tiny Peis-components.

In each experiment of each kind, the number of tuples sent and the tuple payloads are fixed: in most cases, one tuplewith payload of three bytes. The first situation focuses on the performance of our middleware on one single tiny Peis; thesecond situation considers more complex cases in which several tiny Peis share functionalities with a several ordinary Peis-component.

We focus on the above types of situations because these are the most challenging ones. Situations in which a full Peis-component has multiple subscribers would not be very interesting, since full Peis-components typically run on relativelypowerful processors, with enoughmemory and processing power, and therefore visibility is usually guaranteed even with alarge number of subscribers. Tiny Peis-components, however, typically run onmemory constrained devices likeWSNmotes,which may affect reliability when the number of subscribers is high—which results in more tuples being sent out from thetiny Peis-component. Theoretically, visibility of a tiny Peis-component should be independent of the number of subscribers.Visibility, however, may suffer when several tiny Peis-components are connected to the wired network via a base-station,due to the limited capacity/performance of the base-station, as well as to the acknowledgment mechanism and memorylimitation (which forces us to use the limited size of the message queue) of the Tiny Kernel. The two types of situationsconsidered above, then, focus our analysis on the ‘‘weakest’’ part of a Peis-ecology: tiny Peis-components with multiplesubscribers.

6.1.3. NPeis-components subscribe to one tiny Peis

Experimental setup. In this experiment we use a single tiny Peis producer and 20 full-Peis-components consumers. Thetiny Peis is a MoteIV Tmote Sky running Tiny Kernel on board. This mote has 250 Kbps Chipcon wireless transceiver, andthe suggested maximum radio buffer is 100 bytes. The tiny Peis generates and publishes a tuple every second, whose


1

0.95

Received Beacon Messages Ration full-PEIS subscribe to m Tiny-PEIS

0.9

0.85

0.8

Rat

io

0.75

0.7

0.65

0.6

0.55

0.52 4 6 8 10 12

Subscribers:full-PEIS14 16 18 20

Fig. 7. Visibility analysis results. Left: rate of correctly received beacon messages from tiny Peis as the number of subscribed Peis-components increases.Right: number of times when the tiny Peis was regarded as non-visible for different numbers of subscribers and different values of the sensitivityparameter c.

key is counter-value and whose value is a counter that starts at 0 and is increased at each cycle until 255. The fullPeis-components all subscribe to the counter-value tuple, and therefore they receive the value whenever the tuple ispublished and/or updated.

The tiny Peis and the full-Peis are connected through a Tiny-gateway, for which we have used a second Tmote Sky. At theTiny-gateway, the packet sending rate over the radio is set to 100 packets/s, with maximum packet length 100 bytes. Thisfrequency is more than the requirement for this experiment. On the other hand, the packet sending frequency in the TinyKernel is 20 packets/s, and the message Queue length is 20 bytes. Both at the Tiny-gateway and the Tiny Kernel the packetre-sending interval is set to 2 s, and a packet is sentmaximum3 times, unless it is an acknowledgment or a broadcast packet.The payload of the tuples is kept at a constant value of 3 bytes in all experiments in order to avoid introducing difficultiesrelated to variable bandwidth.

Each experiment in this set was run for about 15 min, using a different number of subscribers and/or different values ofthe parameters. The number of sent tuples was recorded by the producer tiny Peis, and the numbers of successfully receivedtupleswere recorded by each of the subscriber Peis-components. Since all tiny Peis are 1-hop neighbors of the Tiny-gateway,the beacon messages are collected by the Tiny-gateway rather than by the actual subscribing Peis. The sampling interval ofthe Tiny-gateway was 6 s.Visibility analysis. Fig. 7 (left) summarizes the results of the experiments, and shows how the visibility of a tiny Peis is affectedby the number of subscribed Peis-components. Visibility (Y axis) is measured by the beacon message ratio x defined byEq. (1) above. The corresponding time lengths Tvisibility during which the tiny Peis is expected to become invisible to thenetwork (i.e., to the Tiny-gateway) can be computed through Eq. (2) above. The table on the right hand side of the figureshows the actual number of times, in the experimental runs, when the tiny Peiswas invisible to network for different valuesof the sensitivity parameter c. These results are in good agreement accordance with the above expectation. Given theseresults, we have decided to set c = 4 in most of our applications.

Since the network beacon messages are given the highest priority in our design, the tiny Peis should remain visibleindependently of the number of subscribers, until the node actually leaves the network—e.g., it turns off or it goes outsideradio coverage. From our experimental analysis, we conclude that the invisibility occurrences of the tiny Peis are negligiblewhen the sensitivity parameter c is set to 2 or higher. This is an important property, which ensures that our middleware issuitable to practical applications that need to integrate tiny devices in a large network.Reliability analysis. To see how reliability depends on the number of subscribers, we have run 25 experiments with anincreasing number of subscribers. Fig. 8 summarizes the results, where reliability (Y axis) is measured according toEq. (3) above. We see that the tuples sent by the tiny Peis are transmitted with more than 95% reliability as long as there are10 subscribers or less. Reliability decreases almost linearly with the number of subscribers after this point.

The reliability is affected by several parameters in the Tiny Kernel, such as the length of the message queue and thepackage transfer rate over the radio. Fig. 9 (left) plots the measured values of reliability and network performance withan increasing number of subscribers using different queue lengths, while radio speed is set to 20 packets/s. Fig. 9 (right)plots the same values using different radio speeds, while queue length is set to 20. Network performance is computed as


Reliability Analysis

Q of TinyKernel = 20Radio Frequency = 20 packs/sec

Increasing number of full-PEIS are subscribed to one Tiny-PEIS

Rel

iabi

lity

full-PEIS

1

0.95

0.9

0.85

0.8

0.75

0.7

0.65

0.6

0.55

0.45

0.5

0.41 3 5 7 9 11 13 15 17 19 21 23 25

Fig. 8. Reliability value as a function of the number of subscribers.

Rel

iabi

lity


Analysis:various radio speed for TinyKernelfor variant Tiny Queue Length

PEIS

1

0.95Q Len=20; Reliability Freq=20; Reliability

Freq=25; Reliability

Freq=50; Reliability

Freq=20; Net performance



Tiny Q Len = 20

Q Len=30; Reliability

Q Len=30; network performance

Q Len=20; network performance

0.9

0.85

0.8

0.75

0.7

0.65

0.6

0.558 9 10 11 12 13 14 15

Subscribers

8 9 10 11 12 13 14 15

1

0.95

0.9

0.85

0.8

0.75

0.7

0.65

Fig. 9. Impact of some Tiny Kernel parameters on reliability and network performance. Left: impact of the message queue size. Right: impact of the radiospeed.

the ratio of the successfully arrived tuples versus the total number of sent tuples: this value differs from the reliabilityvalue since it does not take into account the ordering of the tuples. From these data, it appears that longer queue valuesslightly increase reliability but seriously decrease performance, while values of radio speeds higher than 25 decrease bothreliability and performance. We have therefore decided to set the queue size to 20 and the radio speed to 20 packets/s in allour experiments.

6.1.4. N full-Peis subscribe to M Tiny-Peis: N × M subscriptions

Experimental setup. In this series of experiments, many full-Peis receive tuples frommore than one tiny Peis. The runs wereperformed in our Peis-Home experimental facility, described below. Six tiny Peis are spread in one room of the Peis-Home,and are all acting as tuple producer. As in the previous experiment 6.1.3, each tiny Peis generates and publishes tuples at1 Hz frequency, with key counter-value andwith a sequential number as value. All full Peis-component subscribe to thecounter-value tuples from all the existing components in the network. In the Peis-middleware, this is done by using anassociative (wild-card) subscription. As before, the setup includes a TMote Sky used as Tiny-gateway to bridge the full andthe Tiny-sides of the network. Each experimental run has been run for 15 min, using a different number of producer and/orconsumers.Visibility analysis. Fig. 10 summarizes the ratio of correctly received beacon messages obtained in 38 runs using increasingnumbers of producers and/or consumers. The ratiowas computed according to Eq. (1) above. The expected timeof invisibility


1

0.9

0.86

5

56

7

0.98

0.96

0.94

0.92

0.9

0.88

4

4

Producers

Subscribers

Visibility Analysis

Vis

ibili

ty

3

32

211

Fig. 10. Ratio of correctly received beacon messages when N full-Peis are subscribed to M tiny Peis. In Y is the number of tiny Peis producers; in X , thenumber of Peis subscribers.


Increasing number of full-PEIS are subscribed to increasing number of Tiny-PEIS

Rel

iabi

lity

0.95

1

0.9

0.85

0.8

0.75

0.7

0.65

0.6

nMote=1

nMote=2

nMote=3

nMote=4

nMote=5

nMote=6

PEIS3 42 5 6 7 8 9 10 11 12 13 141 15

Fig. 11. Reliability values with up to 15 full-Peis subscribed to up to 6 tiny Peis. Each line refers to a given number nMote of tiny Peis.

of components can be derived from this data through Eq. (2). As expected, the beacon message ratio decreases when thetotal number of subscribers and producers increases. However, the ratio of correctly received beaconmessages is still higherthan 85%, even with seven subscriber all subscribing to six producers. According to Eq. (2), this gives us a Tvisibility of about8000 s for c = 4 and∆t = 4, that is, the componentmay disappear once every 8000 s. Inmore typicalmonitoring situations,where 1–2 subscribers receive data from all producers, the beaconmessage ratio exceeds 95%, resulting in a Tvisibility of morethan 170 h. These values are more than acceptable for most applications.

Reliability analysis. Fig. 11 summarizes the results of a suite of experiments run with configurations where a number Mof producer tiny Peis provides tuples to a number N of subscribing Peis, where M ranges from 1 to 6 and N from 1 to 15.Reliability is computed according to Eq. (3) above. For each value of M , there is a critical value for N after which reliabilitybegins to decrease. From the visibility analysis, we know that one tiny Peis can provide tuples to up to 10 subscribers withmore than 95% reliability. Accordingly, we conjecture that loss of reliability in this experiment suite ismainly due to droppedpackets at the base-station, and hence that reliability could be improved by using amore powerful processor as base-stationthan the standard mote used in this experiment.

Fig. 12 shows in detail how reliability changes as a function of the numberM of producer tiny Peiswhen there is a singleconsumer Peis subscribed to all tiny Peis. In this case, which is typical of manymonitoring application, tuples are transferredwith reliability in excess of 97.5%.


Rel

iabi

lity


0 1 2 3

Motes

4 5 6 7

0.99

0.99

0.98

0.98

0.97

0.97

Fig. 12. Reliability values with a single full-Peis subscribed to up to 6 tiny Peis.

Blinds motor

Blinds controller

Astrid

Lamp

Plant

Fig. 13. Some views of the Peis-Home experimental test-bed. Left: the robot Astrid (full Peis) and a few tiny Peis. Right: a garbage bin proxied through aXBee communication module (top), and some objects proxied though RFID tags (bottom).

By comparing Fig. 11 with Fig. 10, we notice that reliability usually reaches higher values than the ratio of correctlyreceived beacon messages. The reason for this is that beacon messages and tuple messages are treated differently in ourdesign. Beacons are sent by broadcast with high priority, while tuples are sent by unicast with low priority. Lower prioritymessages may be discarded when the message queue is full; on the other hand, unicast messages are acknowledged.This means that beacon messages are less likely to be lost, and tuple messages are less likely to be incorrectly received.These design choices are intended to maximize visibility of beacon messages while ensuring high reliability of tuple datatransmission.

6.2. Qualitative experiments

The second series of experiment that we report aims at demonstrating the practical applicability of the Peis-Middlewarein realistic domains, where Peis of highly heterogeneous nature must coexist and inter-operate. These experiments areproof-of-concept: as such, the results are reported in the form of sample executions on illustrative scenarios rather than inthe form of quantitative assessments.Experimental setup. The experiments have been performed in a physical test-bed developed at Örebro University, calledthe Peis-Home (Fig. 13). This resembles a typical Swedish bachelor apartment, and it is equipped with a communicationinfrastructure and with a number of Peis, including static cameras, mobile robots, sensor nodes, and so on. This test-bedhas been extensively used to validate both the Peis-Ecology concept at large and several related techniques [22]. For thepurpose of the experiments reported in this section, we have used a small subset of the devices available in the Peis-Home,including two full Peis, six tiny Peis, and seven proxied-Peis. The full Peis run the regular Peis-kernel; the tiny devices runthe Tiny Kernel; and the proxied objects are incorporated in the network through the design pattern discussed in Section 5above.

More specifically, the two full Peis are: an instrumented refrigerator, which has been equipped with an openingmechanism, a robotic arm, an RFID reader and a PC-104 computer; and a regular home PC in the living room. Both areconnected through wired Ethernet. The home PC runs a datalogger Peis-component, which logs data obtained from allthe deployed nodes (including proxied objects) for analytic purposes. The home PC also carries a Tiny-gateway to bridge


the tiny and the regular parts of the network, using a TMote Sky device connected to a USB port. Our framework supportsmultiple gateways, but one was sufficient in our experiments given the small size of the environment.

The six tiny Peis are all TMote Sky motes. Three motes, with ID 3, 7 and 8, are respectively placed in the kitchen, thebedroom and the living-room. They measure ambient light and publish tuples with key light-value once a second. Theyalso publish tuples with key light-status, with values ON or OFF. This value is decided by comparing the average of lastfive readings against a threshold, which can be set at run time through the tuple threshold. Motes 3 and 7 also measurehumidity, at sampling rate of 1 Hz, and publish every five seconds a tuple containing the series of the last fivemeasurements.One additional mote (9) is installed in the department’s relax area, adjacent to the Peis-Home, and is set tomeasure ambientlight in that area. The last two motes (5 and 6) are attached to a floor lamp: the first turns the lamp on and off, the secondsenses the actual light value.5

The seven proxied objects are four everyday objects, one garbage bin and two sofas. The objects are a box of milk, twoboxes of cookies, and a glass, and each has an RFID tag attached. The proxy communication interfaces (see Section 5) forthese objects consist in three RFID readers: one in the fridge, one under the kitchen table, and one under the low table inthe living room. The first two readers are connected to the fridge PC-104 computer, and the third one to the home PC. Theinterface programs provide the position tuple for proxied objects detected by the corresponding RFID readers, with valuekitchen-fridge, kitchen-table and livingroom-table, respectively. The garbage bin has been equipped with aFigaro gas sensor and a XBee communication module, which transmits the sensor value at 1 Hz. The two proxied sofasare one in the department’s relax (coffee) area and one in the Peis-Home living room. Each sofa has been equipped withpressure sensors under the legs, connected to a XBee module that transmits the sensors’ values at 1 Hz. The communicationinterfaces for all the XBee-enabled proxied objects consist in two XBee modules, respectively placed in the coffee room andin the living room and wired to the fridge computer and to the home PC. The corresponding interface programs provide thevalues coffee-room and living-room for the position tuple.

The proxy programs for the proxied objects are very simple: they set the position tuple of the object to the valuecurrently received by the interface which has detected it, or to unknown if the object is not detected. This is especiallyuseful for RFID-tagged objects, where location at a given time is an important property. In addition to position, the proxyprogram for the bin computes and publishes the gas-value coming from the gas sensor, and the proxy programs for thesofas compute and publish the sofa-status (empty or occupied) computed by comparing the pressure reading with agiven threshold. Finally, two proxy managers run on the fridge computer and on the home PC, respectively. Both can startthe relevant proxy for XBee and RFID channels, according to an object signature. Recall that in the Peis-middleware, thespecial component called PeisInit act as the signature database for proxied objects.

6.2.1. An extended runThe above setup has been used to run a number of experiments for extended periods of time. The goal was to test the

stability and reliability of our system in a real-life situation. Here we describe one of these experiments, which was run fora total of 350 h, i.e., more than two weeks. To make the experiment less controlled, we have used the relax/coffee area inour department under normal activity: most of the users of this area were not aware of the ongoing experiment.

For this experiment we used the following subset of the devices described above: the proxied sofa placed in the coffeearea; the proxied lamp, whichwas placed beside the sofa; the ambient light sensormote-9; the fridge and home computers;the XBee interfaces; and the Tiny-gateway. A dedicated Peis-component running on the home PC implemented a simpledecision making program. This program subscribes to the sofa-status tuple from the sofa proxy, the light-valuetuple from the mote-9 tiny Peis, and the lamp-status tuple from mote-6 in the lamp. The program uses two rules todecide when to switch the lamp on and off:

Rule-1: "Turn Lamp On"IF (sofa-status=SITTING and light-value<ENOUGH and lamp-status!=ON)THEN (switch(lamp,ON))

Rule-2: "Turn Lamp Off"IF (sofa-status=EMPTY and lamp-status!=OFF)THEN (switch(lamp,OFF))

Intuitively, the lamp should be on whenever someone is sitting on the sofa and the ambient light is lower than a giventhreshold. Switching the lamp on and off is made by setting the lamp-request tuple of mote-5 in the lamp.

Fig. 14 summarizes the data collected during two weeks of execution. The ‘‘expected sofa state changes’’ is the numberof changes in the sofa state, from SITTING to EMPTY or vice versa. Transient changes of less than 4 s are not considered, sinceboth the sofa and lampmonitor average readings over five seconds. The ‘‘detected sofa state changes’’ is the number of timeswhen a rule is activated and hence the light is switched on or off. Ideally, this number should be the same as in the previouscolumn. The difference between those numbers is reported in the ‘‘error’’ column: positive values indicate false negatives,

5 In a concrete application, a single mote could be used for both purposes. The additional complexity was introduced here to make our experimentsricher.


Fig. 14. Summary results from two weeks of execution of the ‘‘sofa-lamp’’ scenario.

i.e., the sofa status has changed but the lamp has not been switched; negative values indicate false positives, i.e., the lighthas been switched although the sofa status had not changed.

Note that the data from days 8, 10 and 13 were corrupted due to external reasons—students rebooted the home PC, anda pressure sensor broke. Excluding these data, the overall experiment contains 145 sofa status changes, 141 of which havebeen correctly detected, corresponding to a success rate of 97.24%. Of the 144 light switches, 3 were due to false positives,corresponding to a false positive rate of 2.08%. Although the results are episodic, since this experiment was simply meantas a proof of concept, these data indicate that our framework can be reliably used in real-world applications that integratefull Peis, tiny Peis, and proxied objects.

6.2.2. Additional experimentsIn addition to the above experiment, the set-up in the Peis-Home has been used for a number of other experiments aimed

at testing other parts of the full Peis-Ecology project. Two experiments are worth mentioning here.In one experiment, fully reported in [23], a plan-based technique is used to self-configure a system that includes a

combination of full Peis (a mobile robot), tiny Peis (a mote actuated lamp) and proxied Peis (a RFID-tagged book). Thesystem is automatically configured to perform a given task (fetch a book and bring it to a person), and is re-configured aftera failure. The framework described in this paper allows the mobile robot to get information about the book’s position viathe book proxy, and to turn on the light via the tiny Peis to navigate more safely.

The second experiment, fully reported in [24], is about activity recognition. A number of full Peis, tiny Peis and proxied-Peis are deployed in the Peis-Home to collect data about the usage of objects and appliances by the inhabitant. FullPeis include a camera-based system that tracks the position of the human. Tiny Peis include motes sensing the status of thestove. Proxied Peis include a sofa and a bed equipped with pressure sensors which communicate through XBee interfaces,and a number of tagged objects which communicate via RFID interfaces. The framework described in this paper allows thedata from all these objects and devices to be seamlessly transmitted to the monitoring program, which runs as a regularPeis-component on the home PC. The monitoring program has been used to infer the activities and plans of the user overextended periods of time.

6.2.3. UsabilityThe Peis-Ecology middleware, including its Tiny and Proxy sides, has been used for four years in our Masters level

education, and students have found it very helpful in developing large integrated projects involving many interactingsensors, actuators, and robot. The ease by which components can be added and removed and input–output connectionsredirected, at run time andwithout restarting the system, has often beenmentioned as one of themost convenient features.The tuple abstraction has also been found helpful in terms of abstraction and modularity. The Peis-Ecology middleware isalso being used as the main integration platform in two EU projects, and again the feedback is positive in terms of ease ofuse, flexibility in integrating modules developed in a distributed way, and debugging.

Unfortunately, the positive feedback about themiddleware is qualitative and informal, andwe did not run any systematicevaluation so far. Onedifficulty in performing a systematic evaluation is the complexity of programmingdistributed systems.If a programmer had to solve the same tasks that are solved through the Peis-kernel with only standard operating systemabstractions, he or she would have to implement a decentralized and reconfigurable network of devices—typically by aP2P network. This task alone would require several months to be implemented over common network abstractions suchas TCP/IP. A quantitative evaluation would require dozens of implementations taking several person–months each, whichclearly is not feasible.

Quantitative comparisons with other existing middlewares that can solve the same tasks would constitute a moremeaningful set of experiments. At the time of our experiments, middlewares with support for full decentralization and


reconfigurability were not readily available. Middleware of this type are more mature and available today, so performingsuch an evaluation would be an interesting challenge, and we plan to do so in the future.

7. Related work

There is great potential in being able to make computers, robots, small sensing or acting devices, and even augmentedeveryday objects communicate and cooperate in a common framework. Correspondingly, many works have been reportedin different areas that aim at the integration of some of the above entities, typically by defining a middleware. We reviewsome of the most prominent proposals below. To the best of our knowledge, however, the work presented in this paper isthe only generic approach able to smoothly integrate all of the above types of entity into one and the same system.

The Ubiquitous Robot Technology Space, or ‘‘u-RT Space’’ project [25] is a system for a life-supporting heterogeneousrobot systems and, and it relies on the RT-Middleware for robotic control to achieve this goal. The middleware is basedon the well-known ACE (Adaptive Communication Environment) and CORBA standard [26]. It allows WSN technology byimplementing a tailored version of the RT-Middleware called LwRTc [27] and RFID technology to represent everyday objectsby adaptingweb-service technology [28]. Differently fromour approach, LwRTc runs on custom-built hardware,which limitsits applicability. Also, theweb-based approach is less general than our proxy approach, in that it only represents the physicalproperties of an object but not its context dependent properties, e.g., its current position.

Several research groups in Korea have investigated the concept of Ubiquitous Robotic Companion (URC), which providesservices to users whenever and wherever they need them [29,30]. Their view is to establish a unified framework forboth robot–environment and ubiquitous computing environment. UPnP technology [31] is a good candidate for sucha unified framework instead of mostly used CORBA specification. These projects, so far, consider mostly devices withpowerful computation resources, like robots, digital TVs, mobile phones, PDAs and PCs. In fact, the implementation of UPnPspecification requires 500 KBRAMand 3000KB programmingmemory, and thus it is not suitable to small devices like typicalmotes or WSN nodes.

GAS [32], or Gadgetaware Architectural Style, is a generic architectural style that can be used to describe everydayenvironments populated with computational artifacts. Everyday objects, sensors and/or actuators having processing andcommunication abilities are called eGadgets. A set of eGadgets that communicate and share functionalities are known aseGadgetworld. In this architecture a Plug is the software component that publishes the properties of an eGadget to thenetwork and synapses are the associations between two compatible plugs. A component based software kernel, GAS-OSimplements theGAS concept. This architecture provides both sensing and actuation functionalities. However, GAS-OS shouldbe running on the hardware and it requires few MBs RAM. Therefore, GAS cannot currently accommodate the type of tinydevices addressed in this work, which typically have 10–100 KBs programming memory. Also, GAS has no provision tointegrate everyday objects.

The concept of a Peis proxy has many similarities to concept of a surrogate in Jini [33,34]. There are however importantconceptual differences. First, while the main motivation behind surrogates is interoperability with foreign devices, theconcept of Peis proxy draws its main motivation from the wish to access everyday objects. The main intended use ofPeis proxies is to make physical objects members of a Peis-Ecology by just having some interface to them—which can beas simple as an RFID tag attached on the object, or even just a camera looking at the object. The second difference is thatthe Peis proxy framework includes a comprehensive mechanism for the creation and destruction of proxies, and for theirdynamic connection to different interfaces, not necessarily known beforehand. The third difference is that Peis proxies canincorporate mechanisms for fusion of information about the proxied object coming frommultiple sources, including a prioriinformation and information provided by multiple interfaces.

Several families of middleware share a few characteristics with the Peis-Ecology middleware. Some of the mostpopular middleware proposed in the pervasive computing community, like Gaia [35], PCom [36] and MundoCore [37], arecharacterized by dynamic reconfiguration and high interoperability. The LIME family is perhaps the approach closer to theone presented here. LIME [38], together with its tailored versions TinyLIME and TeenyLIME [39], is a java-based system forheterogeneous networked devices such as robots and WSN. It is based on a Linda model, where processes communicatethrough a shared tuple space that acts as the data repository. The LIME systems are interoperable between WSN and largerplatforms, including mobile robots. However, none of the above middleware try to accommodate simpler everyday objects,or non-open devices, that are unable to run even the light-weight version of the LIME middleware.

The RUNES Middleware [40] also addresses the co-existence of various heterogeneous devices, from resource richPCs to resource constrained WSN motes. RUNES adopts a component based programming model and encapsulates thefunctionality provided by its various components behind a well defined middleware kernel API. It is a two layeredarchitecture in which the middleware kernel, and the middleware components and application-level software componentsreside in different layers. Only the middleware kernel is implemented on different hardware platforms for interoperability,while other middleware components are dynamically loaded and unloaded at run-time depending on the applicationscenarios and contexts. These features make RUNES highly reconfigurable as well as highly heterogeneous: for example,an implementation on Contiki is available in [41]. Similarly to LIME, however, RUNES does not offer any mechanism to dealwith everyday objects or non-open devices.

The EU funded project PERSONA [42] is another approach toward the integration of different networked devices in orderto build ambient intelligent environment. The components of a PERSONA system are interfaced through the PERSONA


middleware, which provides four different communication buses: context-bus, service bus, and multi-modal input andoutput buses. The PERSONAmiddleware is implemented on the OSGi [43] platform. In order to integrate low computationalresource devices, the PERSONAmiddleware adopts a solution based on gateway, which allows the PERSONA applications toshare information by communicatingwith other application layers reside on different networks such as ZigBee or BlueTooth.In this approach, every network is represented by a software driver. To integrate a network writing a bridging component,which interacts between the software driver and PERSONA, is sufficient. However, instead of dealingwith individual devices,PERSONA integrates the whole networks which are different in communication protocols.

The project AwareKitchen [44] aims at developing service robots for households by networking heterogeneous devices.The well known player framework [45] is the used middleware. The ‘‘devices-as-file’’ model borrowed from Multics andUNIX is the basic of the representation of devices of different from PC toWSNmotes, RFID readers, etc. Though this projectsconsider motes like WSN nodes, it heavily relies on more powerful base station (Gumstix or ordinary PCs) interface and themote network is dedicated for sensing only.

8. Conclusions

We have presented a method that allows to smoothly integrate highly heterogeneous devices into an ambient ecology.Devicesmay range fromPCs andmobile robots towireless sensor nodes and even simple tagged everyday object. Themethodrelies on an existing middleware for network robot systems, and extends it in two ways: by developing a light-weight, fullycompatible version of it that can be run on tiny devices; and by introducing the notion of ‘‘object proxy’’ to incorporatetagged everyday objects.

Although we have developed and presented our method on the top of a specific framework, the Peis-Ecology, and itsspecific middleware, a similar development could be done starting from another middleware. In particular, the conceptof object proxy is a general design pattern that can be applied to any middleware that allows the dynamic creation andconnection of components.

Until now, we have only considered systems consisting of a single Peis-Ecology. An exciting direction of developmentis to study systems in which multiple, inter-connected ecologies exist, and both Peis and users may move across them. Asystem of this type is being developed in the context of the Robot-Era EU project (www.robot-era.eu), in which ecologiesset in the house, the building, the shop or the street may negotiate information and services to assist roaming elderly users.

The experiments reported in this paper indicate that the implemented middleware has a sufficient degree of maturityto allow long-term deployment of hybrid ambient ecologies including several devices in laboratory environments. We arenow in the progress of deploying this middleware in real environments, namely in several ambient-assisted facilities in thecontext of elderly care. We expect that this deployment will further stress the robustness of this middleware and promptfor additional improvements.

Acknowledgments

This work has been partly supported by Vetenskapsrådet (the Swedish Research Council) and partly by the EuropeanCommunity’s FP7 under contract #269914 RUBICON (www.fp7rubicon.eu).

References

[1] M. Broxvall, Amiddleware for ecologies of robotic devices, in: Proceedings of the International Conference on Robot Communication and Coordination,RoboComm, pp. 16–22, 2007.

[2] M. Bordignon, J. Rashid, M. Broxvall, A. Saffiotti, Seamless integration of robots and tiny embedded devices in a PEIS-Ecology, in: Proceedings of theIEEE/RSJ International Conference on Intelligent Robots and Systems, IROS, 2007.

[3] J. Rashid, M. Broxvall, A. Saffiotti, Digital representation of everyday objects in a robot ecology via proxies, in: Proceedings of the IEEE/RSJ InternationaConference on Intelligent Robots and Systems, IROS, pp. 1908–1914, 2008.

[4] PEIS Ecology homepage. www.aass.oru.se/~peis.[5] A. Saffiotti, M. Broxvall, PEIS Ecologies: ambient intelligence meets autonomous robotics, in: Proceedings of the International Conference on Smart

Objects and Ambient Intelligence, sOc-EUSAI, pp. 275–280, 2005.[6] J.J. Gibson, The Ecological Approach to Visual Perception, Houghton Mifin, Boston, MA, 1979.[7] Random early detection queue management. www.icir.org/floyd/red.html.[8] M. Broxvall, B.S. Seo, W.Y. Kwon, The PEIS Kernel: a middleware for ubiquitous robotics, in: Proceedings of the IROSWorkshop on Ubiquitous Robotic

Space Design and Applications, pp. 212–218, 2007.[9] David Gelernter, Generative communication in Linda, ACM Transactions on Programming Languages and Systems 7 (1) (1985) 80–112.

[10] J. Rashid, M. Broxvall, Indirect reference: reconfiguring distributed sensors and actuators. in: Proceedings of the IEEE International Conference onSensor Networks, Ubiquitous, and Trustworthy Computing, SUTC, 2010.

[11] Crossbow home page. http://www.xbow.com/.[12] J. Polastre, R. Szewczyk, D. Culler, Telos: enabling ultra-low power wireless research, in: Proceedings of the International Symposium on Information

Processing in Sensor Networks, 2005.[13] J. Schiller, A. Liers, H. Ritter, R. Winter, T. Voigt, ScatterWeb—low power sensor nodes and energy aware routing, in: Proceedings of the Annual Hawaii

International Conference on System Sciences, p. 286c, 2005.[14] Gumstix home page. http://www.gumstix.com/.[15] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo, D. Gay, J. Hill, M. Welsh, E. Brewer, D. Culler, TinyOS: an operating system for

sensor networks, Ambient Intelligence (2005).[16] TinyOS, website. www.tinyos.net.

http://www.robot-era.eu

http://www.fp7rubicon.eu

http://www.aass.oru.se/~peis

http://www.icir.org/floyd/red.html

http://www.xbow.com/

http://www.gumstix.com/

http://www.tinyos.net


[17] Ciaran Lynch, Fergus O’Reilly, PIC-based TinyOS implementation, in: Proceedings of the 2nd European Workshop on Sensor Networks, 2005.[18] P. Buonadonna, J. Hill, D. Culler, Active message communication for Tiny networked sensors, in: Proceedings of the 20th Joint Conference of the IEEE

Computer and Communications Society, 2001.[19] G. Ferrari, P. Medagliani, S. Di Piazza, M. Martalo, Wireless sensor networks: performance analysis in indoor scenarios, EURASIP Journal on Wireless

Communications and Networking 14 (2007) (Article ID 81864).[20] A. Ozgovde, C. Ersoy, WCOT: a realistic lifetime metric for the performance evaluation of wireless sensor networks, in: Proceedings of the IEEE

International Symposium on Personal, Indoor and Mobile Radio Communications, 2007.[21] G. Anastasia, E. Borgiaa, M. Contia, E. Gregoria, A. Passarella, Understanding the real behavior of Mote and 802.11 ad hoc networks: an experimental

approach, Pervasive and Mobile Computing 1 (2005) 237–256.[22] A. Saffiotti, M. Broxvall, M. Gritti, K. LeBlanc, R. Lundh, J. Rashid, B.S. Seo, Y.J. Cho, The PEIS-Ecology project: vision and results, in: Proceedings of the

IEEE/RSJ International Conference on Intelligent Robots and Systems, IROS, 2008.[23] R. Lundh, L. Karlsson, A. Saffiotti, Autonomous functional configuration of a network robot system, Robotics and Autonomous Systems 56 (10) (2008)

819–830.[24] M. Cirillo, F. Lanzellotto, F. Pecora, A. Saffiotti, Monitoring domestic activities with temporal constraints and components, in: Proceedings of the

International Conference on Intelligent Environments, 2009.[25] B.K. Kim, K. Ohara, K. Kitagaki, K. Ohba, T. Sugawara, Design of ubiquitous space for the robotic library system and its application, in: Proceedings of

the World Congress of the International Federal of Automatic Control, 2008.[26] CORBA/IIOP Specification, Object Management Group, Inc., 2000.[27] Y. Tsuchiya, M. Mizukawa, T. Suehiro, N. Ando, H. Nakamoto, A. Ikezoe, Development of light-weight RT-component (LwRTC) on embedded processor,

in: Proceedings of the SICE-ICASE Conference, 2006.[28] B.K. Kim, K. Ohba, S. Hirai, K. Tanie, Web services and ubiquitous control platform for the knowledge distributed robot system, in: Proceedings of the

IROS Workshop on Network Robot Systems, 2004.[29] D.S. Kim, J.M. Lee, W.H. Kwon, I.K. Yuh, Design and implementation of home network systems using UPnPmiddleware for networked appliances, IEEE

Transactions on Consumer Electronics 48 (4) (2002) 963–972.[30] S.C. Ahn, K.W. Lim, J.W. Lee, H. Ko, Y.M. Kwon, H.G. Kim, UPnP robot middleware for ubiquitous robot control, in: Proceedings of the International

Conference on Ubiquitous Robots and Ambient Intelligence, URAI, 2006.[31] Universal plug and play (UPnP) device architecture version 1.0. http://www.upnp.org/.[32] eGadget consortiom, project web site. www.extrovert-gadgets.net.[33] R. Gupta, S. Talwar, D.P Agrawal, Jini home networking: a step toward pervasive computing, Computer 35 (8) (2002) 34–40.[34] K. Harihar, S. Kurkovsky, Using jini to enable pervasive computing environments, in: Proceedings of the Southeast Regional Conference, pp. 188–193,

2005.[35] M. Roman, C. Hess, R. Cerqueira, A. Ranganathan, H.H. Campbell, K. Nahrstedt, Amiddleware infrastructure for active spaces, IEEE Pervasive Computing

1 (4) (2002) 74–83.[36] C. Becker, M. Handte, G. Schiele, K. Rothermel, PCOM—a component system for pervasive computing, in: Proceedings of the IEEE International

Conference on Pervasive Computing and Communications, PerCom, pp. 67–76, 2004.[37] E. Aitenbichler, J. Kangasharju, M. Mühlhäuser, Mundocore: a light-weight infrastructure for pervasive computing, Pervasive and Mobile Computing

3 (4) (2007) 332–361.[38] A.L. Murphy, G.P. Picco, G.C. Roman, Lime: a coordination middleware supporting mobility of hosts and agents, ACM Transactions on Software

Engineering and Methodology 13 (3) (2006) 279–328.[39] C. Curino, M. Giani, M. Giorgetta, A. Giusti, A.L. Murphy, G.P. Picco, Mobile data colleciton in sensor networks: the TinyLime middleware, Journal of

Pervasive and Mobile Computing 4 (1) (2005) 446–469.[40] P. Costa, G. Coulson, C. Mascolo, L. Mottola, G.P. Picco, S. Zachariadis, A reconfigurable component-based middleware for networked embedded

systems, International Journal of Wireless Information Networks 14 (2) (2007).[41] P. Costa, G. Coulson, R. Gold, M. Lad, C. Mascolo, L. Mottola, G.P. Picco, T. Sivaharan, N. Weerasinghe, S. Zachariadis, The RUNES middleware for

networked embedded systems and its application in a disaster management scenario, in: Proceedings of the IEEE International Conference onPervasive Computing and Communications, PERCOM, 2007.

[42] PERSONA project web site. http://www.aal-persona.org/.[43] OSGi web site. http://www.osgi.org/.[44] R.B. Rusu, B. Gerkey, M. Beetz, Robots in the kitchen: exploiting ubiquitous sensing and actuation, Robotics and Autonomous Systems 56 (10) (2008)

844–856.[45] TobyH.J. Collett, BruceA.MacDonald, Brian P. Gerkey, Player 2.0: toward a practical robot programming framework, in: Proceedings of theAustralasian

Conference on Robotics and Automation, ACRA, Sydney, Australia, 2005.

http://www.upnp.org/

http://www.extrovert-gadgets.net

http://www.aal-persona.org/

http://www.osgi.org/

a middleware to integrate robots, simple devices and everyday objects into an ambient ecology

Documents