O R I G I N A L A R T I C L E
FamiWare: a family of event-based middleware for ambient
intelligence
Nadia Ga´mez•Lidia Fuentes
Received: 29 September 2010 / Accepted: 4 December 2010 Springer-Verlag London Limited 2011
Abstract Most of the middlewares currently available focus on one type of device (e.g., TinyOS sensors) and/or are designed with one requirement in mind (e.g., data management). This is an important limitation since most of the AmI applications work with several devices (such as sensors, smartphones or PDAs) and use a high diversity of low-level services. Ideally, the middleware should provide a single interface for accessing all those services able to work in heterogeneous devices. To address this issue, we propose a family of configurable middleware (FamiWare) with a really flexible architecture, instead of building a single version of a middleware with a rigid structure. In this work, we present the architecture of our middleware that can be configured, following a Software Product Line approach, in order to be instantiated in a particular device fulfilling specific application requirements. Furthermore, we evaluate that the decisions taken at architecture and implementation are the adequate ones for this kind of constrained devices.
Keywords Middleware AmI SPLs Events Publish/Subscribe
1 Introduction
The use of middleware platforms enhances the develop-ment of Ambient Intelligence (AmI) applications by
providing a set of high-level and platform-independent services. Most of the middleware platforms currently available for AmI devices are focused mainly on WSNs (Wireless Sensor Networks) [1] or on a specific kind of smart or mobile phone. But normally, AmI environments consist of a heterogeneous set of devices communicating with each other [2]. There are lightweight devices with limited resources, such as different kinds of sensors (MICAz, MICA2, Telosb or Sun SPOT) and smartphones, from several vendors with their respective Operative Sys-tems (HTC with Android, iPhone with iPhone OS, Nokia with Symbian, or Samsung with several OS, for example Windows Phone 7). This means that in each device, the application may be developed in its own programming language using different APIs (nesC for the TinyOS motes, Java for Sun SPOT or Java for Android smartphones) and considering different computational or memory limitations. On the other hand, these devices are structured in networks, such Wireless Sensor Networks (WSNs) or ad-hoc net-works. The nodes of these networks have to be able to communicate with each other and with the outside world, through different network protocols. Therefore, one of the new research challenges in this field is to develop mid-dlewares for dealing with complex heterogeneity problems and integrating WSN-Middlewares with higher level per-vasive computing middlewares [1].
The main shortcoming of current middleware for AmI devices is that the internal middleware architecture is rigid and homogenous. This means that it provides a fixed set of services, although target devices and the requirements of each AmI application are heterogeneous. One important disadvantage of this approach is that the middleware deployed in different devices will contain more services than required, unnecessarily incrementing its size. This is especially important in AmI environments where the
N. Ga´mez (&) L. Fuentes
Department of LCC, ETSII, University of Malaga, Campus de Teatinos, Ma´laga, Spain
e-mail: nadia@lcc.uma.es L. Fuentes
e-mail: lff@lcc.uma.es
resource limitation is a key problem. Furthermore, current middleware proposals follow a fixed layered architecture, with services composed using rigid mechanisms and they are developed for a certain programming language or operating system. So these architectures are not flexible, but the requirements of AmI environments demand cus-tomisable platforms, in order to work with several kinds of devices or service versions.
We present FamiWare, a middleware family for AmI that allows the customization and instantiation of a specific middleware platform taking into consideration the pecu-liarities of every device and application domain, with the goal of reducing the middleware size. Our middleware family is built using the Software Product Line (SPL) engineering approach [3]. In previous works [4], we pre-sented an innovative model-driven configuration process that allows the automatic customization of our middleware, where a minimal set of parameters has to be specified. In order to support such a process, the FamiWare architecture must be very flexible. This means that the internal archi-tecture of the middleware must be composed by loosely coupled services, which allow the generation of customized configurations of the middleware for a specific device platform and certain application requirements.
In this work, we describe the FamiWare architecture and implementation. The composition among services them-selves and between the services and the final application is performed with a Publish/Subscribe event-based mecha-nism, specifically a reduced implementation of the standard Data Distribution Service (DDS) [5]. This composition mechanism decouples the middleware services, so it is easier to generate a configuration with variable services [1,6].
The remainder of this paper is organized as follows. In Sect.2, we present our motivation, giving an overview of our MDD configuration process of the family. Section3
describes the middleware architecture, and Sect.4 details the implementation. In Sect.5, we present our experiments to evaluate our approach and we make a comparison with related works. Finally, in Sect.6, we conclude the paper.
2 Motivation
FamiWare provides a communication and composition model to help the application developers dealing with interoperability between networks and programming languages. So our middleware family is implemented in several programming languages for different devices, so far nesC for TinyOS sensors and Java for Android. The mid-dleware family must be configured in order to get a par-ticular middleware product customized for specific application requirements and device and network particu-larities. So, we proposed to apply model-driven SPL techniques to automate this configuration process [4].
Figure1 gives a general overview of our process (for more on this process the interested reader can refer to [4]). The very first step when creating a SPL is to analyze the variability inherent in the AmI middleware domain. For this task, a feature model (FM) [7] is constructed. The next step is to create a flexible design, or product line archi-tecture (PLA), which supports the variations specified by the FM. A Feature Mapping between the FM and the PLA is also defined. Given a minimal set of high-level param-eters (e.g., the kind of devices, or services required by the application), our process calculates an optimal complete configuration of the FM for customizing the middleware architecture, by means of model transformations. So a larger set of low-level parameters (e.g., all the specific service implementation versions) is automatically obtained. Finally, this customized architectural model is the input of a model-to-text transformation, which produces 100% of the code for deploying this middleware into a device. So, the software engineers can automatically obtain a cus-tomized middleware by simply specifying high-level information.
This automatic process must be supported by a mid-dleware, the internal architecture of which allows: • Adding or removing services required or not required
by the application.
• Selecting the correct implementation of the middleware services considering the operating system or program-ming language of a specific target device.
• Choosing the correct version of the selected services, considering the special needs of the applications (e.g., location service, concretely the version that uses GPS). Nevertheless, in order to obtain a minimal implemen-tation, the middleware services must not be aware that there exist different service versions and that a middleware instantiation may include a variable list of services.
3 FamiWare architecture
In order to get a highly modularizable and reusable archi-tecture, we have followed a microkernel plus services approach. The microkernel is responsible for providing the composition and communication model, and the services implement the useful facilities for AmI environments.
One of the most suitable paradigms for dealing with the configurability of the middleware family is the event-based composition [1,6]. The primary goal of event-based archi-tectures is to enable more flexible patterns of communication between components: multiple senders and receivers, event filtering by various conditions, asynchronous communica-tion, etc. Thus, event-based architectures provide more expressivity for defining connections between components than in a service-based or component-based composition [6]. We define a composition model driven by events. There are several event-based configurable middlewares but they provide this composition model only to the application, though not also in the implementation of the middleware itself. On the contrary, our middleware is event-driven, per se. This means that not only the communication between the application and the services is driven by events, but so too is the communication between the services. The main benefit of this is that an architecture configuration can be obtained
from a variable list of components, since the compositions of middleware services are not hard coded as part of the services implementation.
Furthermore, similar to other previous event-based plat-forms, we have chosen the publish/subscribe communication scheme. Using this scheme the applications will subscribe to events that will be published by the services. In our case, we have followed the Data Distribution Service (DDS) specifi-cation [5], which is an OMG standard for publish/subscribe middlewares. DDS defines a set of interfaces for event sub-scription and publication. These interfaces are implemented as part of the FamiWare microkernel. And, both the services and the applications use these interfaces to publish and subscribe events, which in the case of DDS are identified as topics.
The architecture of FamiWare is depicted in Fig. 2. The functionality of the microkernel is: (1) provides the DDS interface with the main methods to create the publisher, subscriber or topics; (2) provides methods for data write and read; (3) encapsulates the Data Delivery service, a mandatory service for all FamiWare implementations, which sends data to both local (either application or mid-dleware services) and remote components. Due to the resource limitations of the AmI devices, we took special care to implement the minimum set of methods of the DDS interface that are required to implement FamiWare func-tionality. The microkernel interface is required by both the application, which subscribes to some topics according to its functionality, and the services that publish the topics for either the application or other services with which they are composed (see the next subsection).
The middleware includes code to create a specific set of middleware services on demand, all this customized by the device, network and application requirements. This code is automatically generated by the model-to-code generator of our configuration process. Also the implementation of the DDS interface is pre-implemented, so 100% of the code is automatically generated. Since the services are built as
independent modules that are plugged in and executed on demand, we obtain a more modular and configurable sys-tem. Along with the microkernel configuration, we include how to initially instantiate a minimum set of services required for the correct functioning of the middleware. This is very dependent on the operating system, but it is very naturally addressed in our approach by generating auto-matically an initialization code according to the different service creation patterns used by each target device (e.g., a configuration file of extension ‘‘.nc’’ for TinyOS). From the point of view of the application developers, they only have to know how to use the DDS publish and subscribe mechanism and provide a list of high-level requirements that will be translated by the configuration process to the list of middleware services that will be created by the microkernel.
3.1 FamiWare services
We identified the services necessary for our middleware, as part of the feature model specification. So, there is a direct correspondence between these services and the features of the middleware. This means that each service defines a standard interface to implement the functionality defined by the corresponding middleware feature of the FM (see more about the functionality of each middleware feature in [4, 8]). What is additionally defined in the FamiWare PLA is the list of topics that a service may publish or may subscribe to. Figure3 shows the services provided by the current version of the FamiWare PLA middleware, and for each service describes which topics it publishes and which services subscribe to them using the DDS interface.
Note that more than one service may subscribe to one topic. This is the case of the Position topic, which is sub-scribed to by the Discovery and the TopoloyControl ser-vices. Also, note that a topic published by a service may be required by another service installed in a different device. For example, the Discovery service subscribes to the capabilities (NodeCapabilities published by the Capability service) and the Position published by the local Location service of nearby devices, in order to publish the capability of the whole AmI environment. This means that there is a dependency between Discovery, Location and Capability services, installed in different nodes. Likewise, the Topol-ogy Control manages the topolTopol-ogy of the networks formed by a set of devices. This service publishes the Topology topic, which consists of a list of pairs with the id of the node and its absolute or relative position. In order to ascertain the position of every node, it subscribes to the Position topic, published by the local Location service of every network node. In this case, there exists a dependency relationship between the Topology Control service installed in a sink
node and the Location service installed on all the nodes of the network.
Another similar example is the dependency between the Data Fusion service, responsible for aggregating moni-tored or sensed data to achieve more accurate information while reducing data redundancy and transmission over-head, which subscribes to the monitored data (MonData) topic to publish Fusioned data. Note that these kinds of dependencies are defined in our FM, and our configuration process takes them into account when generating the cor-rect configuration to install in every node [4]. So, not only the device, network and application requirements defined locally for each network node are considered in order to generate a valid configuration, but also the dependencies between the services installed in every network node.
Finally, the applications normally play the role of subscriber since they are interested in the data provided by the middleware. For example, the Coordination service
Middleware << domainParticipant >> Location << publisher >> positionWriter << topic>> Position << domainParticipant >> TopologyControl << subscriber>> positionReader tags domain = Middleware domain = Middleware tags << domainParticipant >> Coordination << subscriber>> topologyReader << topic>> Topology domain = Middleware tags << topic>> NodeCapabilities << topic>> NodesCoordinated << topic>> MonData << topic>> SavedDatas << topic>> Fusioned << topic>> Encrypted << domainParticipant >> Discovery << publisher >> tags domain = Middleware << subscriber>> << domainParticipant >> Capability << publisher >> tags domain = Middleware << publisher >> topologyWriter << publisher >> << domainParticipant >> Monitoring domain = Middleware tags << publisher >> << domainParticipant >> FaultTolerance << subscriber>> domain = Middleware tags << publisher >> << domainParticipant >> DataFusion << subscriber>> domain = Middleware tags << publisher >> << domainParticipant >> Encryption domain = Middleware tags << subscriber>> << publisher >> sub pub nodecapWriter nodecapReader positionReader coordWriter savedWriter dataReader dataWriter fusionedWriter encryptedWriter dataReader dataReader sub sub sub sub sub pub pub pub pub pub pub pub << topic>> NetworkCapabilities netcapWriter pub
publishes the list of nodes that collaborate under the supervision of a master node (e.g., a cluster head or a sink in a WSN). This information is relevant to some appli-cations, which can subscribe to the NodesCoordinated topic to obtain this information. An example of how the interaction between the application and the middleware (specifically with the battery monitoring service) using the DDS interface is performed is shown in Fig.4. In the diagram, we show the asynchronous version, but the DDS also provides an synchronous version of such interaction.
3.2 Case study instantiation
In order to illustrate the variability present in an AmI environment and how FamiWare manages it, we have selected an AAL Application, an Accidental Fall Report [9] system. This application is responsible for reporting acci-dental falls of elderly and/or disabled people. We have chosen this simple application to demonstrate that in a relatively small AmI system, we have to manage a great deal of variability and we show how our middleware does this easily. This system is comprised of a set of image sensor nodes equipped with cameras, three wall-mounted static sensors with known coordinates, one user badge node equipped with two 3-axis accelerometers (all MICAz Motes) and one smartphone to communicate with a central call centre (HTC Desire smartphone with Android), as we can see in Fig.5. So, for only eight devices, we have to use two programming languages: nesC for TinyOS motes and Java for Android in the smartphone. Moreover, every special device may have different ways to perform some task, for example locating services for a smartphone with a GPS is not the same as locating them in a sensor node with known coordinates. Apart from that, the applications deployed in each device must be able to communicate and
collaborate, first between the sensor nodes of a WSN and second between a camera node and the smartphone.
On the other hand, every application installed in each device requires some facilities provided by the middleware. For instance, according to the personal data protection laws, images sent from the camera node to the phone must be encrypted, so the middleware in this case may provide encryption security facilities. So, for every middleware installation, we will have different services selected, as is shown in the figure.
Figure6shows how the user badge application interacts with the TinyOS version of middleware installed in this device. Location service creates a publisher for the Location topic, which publishes this topic periodically. When the application detects a fall, it creates a subscriber to the Posi-tion topic. Then, when the microkernel receives the PosiPosi-tion (i.e., when Location service writes it), using the Data Delivery service, it writes the Position and the application reads it. Using this information related to the fall, the application writes data to be sent to other nodes of the net-work. After, these data are read by the Data Delivery service that sends it through the network using a specific routing protocol, for example Drip [10] or TinyHop [11].
4 Implementation
In this section, we show some implementation details of FamiWare middleware for two different devices: an Android smartphone and a TinyOS sensor mote. These two implementations are very dissimilar, as they use two dif-ferent programming languages, Java for Android [12] and nesC for TinyOS [13], and what is more, each of these languages follows a very distinct programming paradigm. Java is object oriented (OO) and nesC is an extension of C, designed to embody the structuring concepts and execution
Fig. 4 End-to-end event
delivery between an application and a service
model of TinyOS, which compose components using an event-driven pattern. So, our configuration process must generate these two really different architecture versions of FamiWare middleware, but transparently for the applica-tion developers and interoperable between themselves. This is achieved since, although each service implemen-tation is very different, they publish and/or subscribe to the same topics, so the application only needs to know the list of topics relevant to its execution, and subscribe to or publish such topics when required. Likewise, the micro-kernel internal architecture is very different for each ver-sion, but all implement the same DDS-reduced interface.
4.1 FamiWare for Android
We use the Java APIs specific for Android to implement the DDS interfaces as part of the FamiWare microkernel for Android (see Fig.7). The microkernel is included in an Android Library project, so that the application and the middleware services must only import this project to publish and subscribe topics. The main classes of the middleware model Topics, DataWriters, DataReaders, Publisher, Subscriber or DomainParticipant. FamiWare middleware services are modelled by classes that inherit from the Service Android class.
The DataDelivery class implements the data propaga-tion mechanism, and it is implemented as a class that inherits from ContentProvider Android class that allows data sharing between different applications [12]. This allows for every service or application to be developed in independent projects, but they are able to share data and to be notified when new data arrive. Also, this data-sharing mechanism is provided by Android OS directly, so they are implemented in a more efficient way than if we use other inter-process communication mechanisms.
4.2 FamiWare for TinyOS
NesC programs are built out of components, which are assembled (wired) to form whole programs [13]. Compo-nents define two scopes, one for their specification (con-taining the names of their interface instances) and one for their implementation. There are two types of components in nesC: modules (provide the implementations of one or more interfaces) and configurations (used to assemble other components). Observe that architectural style is very dif-ferent from an object-oriented one, in which DDS interface is specified. So, each DDS entity is modelled by means of both module and configuration components. A nesC mod-ule implements the corresponding interfaces, and the nesC
Fig. 5 Accidental fall report
scenario
Fig. 6 Interaction between the
AAL application and the middleware
configuration defines the provided and required interface of this module. The main components of the microkernel are responsible for creating Topics, DataWriters, DataReaders, Publish/Subscribe and Write/Read. Also it encapsulates the DataDelivery component, but in this case, we implemented the methods send and receive for sending data either locally or thought the network, using a routing protocol specified during the configuration process.
In order to allow the application subscribe topics published by a service, it has to have wirings to the SubscriberC and DataReadersC components. Similarly, the services compo-nents need wirings to the PublisherC and DataWriterC components of the microkernel. In TinyOS, all the compo-nents are wired in the same image of code ready to install in a sensor mote. Figure8 shows the component graph for an instantiation of our middleware for a generic subscriber application and with one service to monitor the battery.
5 Evaluation
To evaluate our middleware, we have developed two different versions, for smartphones with Android OS and for sensor
networks with TinyOS. Concretely for Android, we use the version 2.2 with the API level 8. The measurements shown in this section were made using the emulator provided in the r07-x86 SDK of Android version for Linux and also using the HTC Desire smartphone device. The implementation for WSN has been realized in TinyOS 2.1.1., and the experiments have been performed using two simulators, TOSSIM and AVRORA beta-1.7.106 and also in real MICAz motes (equipped with CC2420 radio and ATmega128L microcontroller).
5.1 Experimental results
The goal of the experiments presented in this section is threefold: (1) they quantify the memory footprint used by the FamiWare microkernel; (2) they calculate the overhead produced for our middleware, measuring the latency for an end-to-end event delivery and the delay in the interaction between the application and a service; (3) and they eval-uate the scalability of FamiWare, regarding the delay produced in the reception of the events as the number of services and topics increase.
Resource Consumption: FamiWare consists of a micro-kernel and a variable set of services, so the memory usage
on a device depends on the actual configuration, i.e., how many services are in the configuration and the size of each one. Obviously, the size for the two versions (TinyOS and Android) is very different, but also their memory con-straint, which is stricter in sensor nodes.
For TinyOS, the minimal core platform consists of the microkernel and the data delivery service, which includes a routing protocol. Also, since any TinyOS application is compiled together with the OS in one image, we also have to include the OS as part of our measures. So, for the simplest case, where any service is selected, and using a lightweight routing protocol (Drip [10]), the memory footprint is extremely reduced. Considering that typically, MICAz nodes have 128 Kb of ROM and 4 Kb of RAM, the FamiWare minimal version only consumes the 11.8% (484 bytes) of RAM and 10.9% of ROM (14,342 bytes). How-ever, if we change the routing protocol to TinyHop [11], the usage reaches to 48.2% of RAM (1,977 bytes). So, we observe that the memory usage of the FamiWare core platform is minimal, but strongly depends on the routing protocol selected (as in other WSN platforms). This means that depending on the application’s size, one routing pro-tocol will be more suitable than another. Our configuration process is responsible for choosing the best suitable routing protocol for every network and application. In addition, the average size of each service is about 73 bytes. Then, a typical configuration with 7 services, the microkernel, Drip protocol and a simple application (123 bytes) uses 27.3% (1,118 bytes) of the memory, so there is still 72.7% free for other sensing tasks not provided by FamiWare.
For the Android version, the minimal configuration consists of the microkernel library project that contains the data delivery service, but without a routing protocol (we use Internet access). This Android project uses 3.15% (2,972 Kb) of the emulator memory (94,096 Kb). As we already commented in the implementation section, the Android processes share a memory region, so the memory footprint of FamiWare remains constant although the number of services increases. Our Android services use
3,124 Kb as size average, so for a typical configuration with seven services, the microkernel and a simple appli-cation (2,824 Kb), FamiWare uses the 9.47% (8,920 Kb) of the emulator memory. But, in the HTC Desire mobile, the memory is 576 Mb, so this percentage goes down to 1.51%.
Summarizing, the resource consumption of FamiWare is minimal and therefore very well suited to the resource requirements of both node sensor and smartphones, since in both versions for a configuration with several services, there is from 70 to 90% of free memory for other appli-cations and tasks. Also, note that the size is very different in both implementations, showing the advantages of using tailored configurations with the operating system of each device.
Overhead and Latency: We measure the time a sub-scriber application installed in a smartphone, or in a sensor node of a WSN, needs to receive an event from a publisher service installed in another smartphone or node. We have assessed the time taken by a service to create an entity able to publish as well the time taken by an application to subscribe to a topic (following DDS methods). Further-more, we measure the time needed to write and send topics and to receive and read them. Table 1reports the results.
In the TinyOS version, these times are really small (of the order of microseconds) and it is not worth calculating the time that every operation consumes. The time to create a publisher (0.033 ms) and to write a topic (0.019) is minimal compared with the time taken to send a data packet from a node to other node. For instance, using Drip protocol in one hop (without intermediate nodes), it takes 8 ms, but if we consider 3 intermediate nodes, this time increase to 6.43 s. So, the necessary time to send a packet is very dependent on the number of intermediate nodes and also on the routing protocol used, but the overhead on the publisher side produced by the implementation of the DDS methods is really insignificant for this time. The same thing happens on the subscriber side. The total time to receive an event is 0.164 ms, again a very small value. This time was
calculated considering a few topics, but for a configuration with a high number of topics, an overhead is produced in the subscriber side, as we show in the scalability evaluation.
For the Android version, these times are significantly higher, since Java introduces a high overhead. Concretely, the total time to send an event is around 310 ms. The longer time taken corresponds with the writing of a topic and sending the data through the network, but this time it is independent of the overhead produced by the DDS methods (e.g., to create a publisher), in which each of them takes less than 20 ms. On the other hand, the time taken to receive an even is around 338 ms. The longer time taken corresponds to the method that creates a subscriber (179 ms). The reason is that this method subscribes the data delivery service, so the first time the Android OS has to allocate the shared memory of the ContentProvider class, which takes lot of time. Another increase in time
taken in the subscriber side is the one taken to notify the subscriber when data are available (94 ms). This is because the microkernel has to check which topic has arrived and call the corresponding listener.
In both versions, the increased times strongly depend on the OS operations or in the way the data are sent through the network. Therefore, the time is not primarily influenced by the implementation of the DDS interfaces. From the user point of view, total times to write and read events are more than acceptable if we compare them with the delays produced to send and receive data through the network without our middleware.
Scalability: Since our configuration process selects an undetermined number of services for a configuration (with their respective topics to publish), we assess the scalability performance in terms of the number of topics. We have performed some experiments with the hypothesis that there is an overload in the subscriber side when the number of topics increases. For the TinyOS version, the subscriber has to search the topic when an event arrives. Since the topics are stored in a table, the time to search a topic lineally increases with an increasing number of topics as shows Fig.9a. For 195 topics, it takes 1.013 ms so the overload produced is not very significant compared to the time taken to send a packet through the network (for example, 6.43 s for 3 intermediate nodes, as we have explained above). However, the tests are not successful with a number of topics larger than 195. This is because the system is out of memory and stack overflows. Therefore, we can conclude that the boundary in the TinyOS version is 195 topics. As the topic average is 3.2 per service, for the TinyOS version FamiWare could provide around 60 services, more than enough for a WSNs middleware.
The time consumption is hard to measure in Android, since as with any Java based system, this strongly depends on the state and the timing of the garbage collector. As is shown in Fig.9b, increasing the number of topics does not produce overload in the subscriber side for the Android version. This is because topics are note stored in a table, as in TinyOS, and to the contrary, a Topic object is con-structed from the topic name, using the reflective
Table 1 Latency for an end-to-end event delivery
Operation Android
(ms)
TinyOS (ms)
Create domain participant 19.985 0.033
Create publisher 13.813 Create topic 10.421 Create datawriter 11.650 Write 254.837 0.019 Send 8 (1 hop), 6,430 (3 hops)
Total send time 310.706 8.052 (1 hop),
6,430.052 (3 hops)
Create domain participant 19.985 0.021
Create subscriber 179.391 Create datareader 14.676 Set listener 2.541 Get listener 0.032 0.143 Read 26.690 Data available 94.869
Total receive time 338.184 0.164
mechanism of Java, and is notified to the corresponding DataReaders. So this time, it depends more on the notifi-cation time to the DataReaders than on the number of topics, resulting in very variable times. Comparing both implementations, the Android version is more scalable than the TinyOS one. Furthermore, the memory footprint also does not increase too much when increasing the number of topics. For 200 topics, the microkernel use 3,401 Kb of memory is only 429 Kb more than with one topic (2,972 Kb). So, it is not possible to calculate the FamiWare boundary in the Android version, since it strongly depends on how Android allocates the memory using a shared memory mechanism.
5.2 Comparison with related work
We present the advantages of our architecture compared with other WSN middleware platforms that do not use a SPL approach. Regarding the survey presented in [1], one of the main benefits of our approach is that we contemplate the use of several kinds of devices and not only one spe-cific sensor as all the approaches surveyed in [1] does. Table2lists a summary of the advantages of our approach as respect to the most cited WSN middleware.
The main advantages of FamiWare are that (1) it offers a large variety of services; (2) it may be instantiated in dif-ferent kinds of devices; (3) the communication between the nodes uses different network technologies and switching between some routing protocols, and (4) it provides an automatic configuration process for customizing the mid-dleware, which also facilitates the evolution or addition of new services. So, our approach allows the integration of the WSNs with a complete AmI environment.
Regarding middleware for other kinds of AmI devices, especially mobiles phones, recently a systematic review has been published [19] of SPL applied to mobile mid-dleware. This paper discusses the proposal of applying SPL at middleware level for AmI devices as a novel and interesting idea. But up to that moment, only a few approaches had been surveyed in this systematic review and many of those surveyed are in the very early (devel-opmental) stages.
6 Conclusions and future work
We have presented the FamiWare architecture and the implementation, a middleware family for AmI systems. We have developed a microkernel plus services architec-ture where the services are composed using a publish/ subscribe mechanism based on events that complies with the DDS standard. This event-based architecture is loosely coupled allowing the generation of different middleware Table
2 Summary of WSNs middleware features Services Implementation Heterogeneity Data collection Type communication Programming paradigm Device/platforms Network technology Network protocols Application configurability New services Mate [ 14 ] Code Management, Resource Management Security All Synchronous Asynchronous Component-based TinyOS Zigbee Content-based No No MiLaN [ 15 ] Resource Management Resource Discovery Event- Driven Synchronous Asynchronous None (Imperative) No No Switch No No Impala [ 16 ] Code Management Resource Management Storage Supporting, Security Event- Driven Asynchronous Mobile Agent iPAQ/PC Linux No Switch Yes, dynamic at runtime Yes DSWare [ 17 ] Data Management Resource Management Storage Supporting Security, Real-time Reliability Event- Driven Asynchronous Pub/Sub Glomosim Simulation Zigbee Cluster-Based No No Mire [ 18 ] Data Management Event Asynchronous Pub/Sub TinyOS Zigbee Cluster-Based No Yes FamiWare All services described previously Event- Driven Synchronous Asynchronous Pub/Sub Now: TinyOS, Android All Switch Yes, MDD process Yes
configurations. We have obtained a highly flexible archi-tecture that may be customized for several kinds of devices and specific application purposes, as is shown in the instantiations of the case study. We have shown the main details of our implementation for TinyOS and Android devices. Experimental results have shown that our imple-mentation is highly efficient and consumes a low percent-age of memory. In addition, we compare FamiWare with other WSN platforms concluding that one important benefit of our approach is the support of the heterogeneity of AmI environment.
As to future work, we are implementing other versions of the middleware in Java for SunSPOT sensors and in J2ME for mobile phones. Furthermore, we are working in providing an autonomic behavior to our middleware for self-healing in WSNs. The goal is that the middleware could capture context changes and adapt itself to main-tain a correct and efficient functioning of the network system.
Acknowledgments This work has been supported by the Spanish
Ministry Project RAP TIN2008-01942 and the Junta de Andalucı´a regional project FamWare P09-TIC-5231.
References
1. Wang MM et al (2008) Middleware for wireless sensor networks: a survey. J Comput Sci Technol 23(3):305–326
2. Bravo J et al (2006) Visualization services in a conference con-text: an approach by RFID technology. J Univers Comput 12(3): 270–283
3. Pohl K, Bo¨ckle G, Linden F (2005) Software product line engi-neering: foundations, principles, and technique. Springer, Berlin 4. Fuentes L, Ga´mez N (2010) Configuration process of a software product line for AmI middleware. J Univers Comput 16(12): 1592–1611
5. OMG Data Distribution Service (DDS) for real-time systems, v1.2. Retrieved August 25, 2008
6. Pohl C et al (2007) Survey of existing implementation techniques with respect to their support for the practices currently in use at industrial partners, AMPLE Project deliverable D3.1, 2007 7. Lee K, Kang K, Lee J (2002) Concepts and guidelines of feature
modeling for product line software engineering. LNCS Softw Reuse Methods Tech Tools 2319:62–77
8. Delicato F, Fuentes L, Ga´mez N, Pires P (2009) Variabilities of wireless and actuators sensor network middleware for ambient assisted living. LNCS Distributed Comput Artif Intell Bioinform Soft Comput Ambient Assisted Living 5518:851–858
9. Keshavarz A, Tabar A, Aghajan A (2006) Distributed vision-based reasoning for smart home care. In: Proceedings of SenSys workshop on distributed smart cameras
10. Levis P, Patel N, Culler D, Shenker S (2004) Trickle: a self-regu-lating algorithm for code propagation and maintenance in wireless sensor networks. In: Proceedings of the first USENIX/ACM sym-posium on networked systems design and implementation 11. Carbajo R, Huggard M, McGoldrick C (2008) An end-to-end
routing protocol for peer-to-peer communication in wireless sensor networks. In: Proceedings of the 6th workshop on mid-dleware for network eccentric and mobile applications
12. Android.com, November 2010.http://www.android.com/
13. TinyOS Home Page, November 2010.http://www.tinyos.net/
14. Levis P, Culler D (2002) Mate: a tiny virtual machine for sensor networks. In: Proceedings of the 10th international conference on architectural support for programming languages and operating systems. ACM Press
15. Heinzelman WB et al (2004) Middleware to support sensor net-work applications. IEEE Netw 18(1):6–14
16. Liu T, Martonosi M (2003) Impala: a middleware system for managing autonomic, parallel sensor systems. In: Proceedings of PPoPP’03, June 2003, pp 107–118
17. Li S, Son S, Stankovic J (2003) Event detection services using data service middleware in distributed sensor networks. In: Pro-ceedings of the 2nd international workshop information pro-cessing in sensor networks (IPSN 03), April 2003
18. Souto E et al (2006) Mires: a publish/subscribe middleware for sensor networks. Pers Ubiquit Comput 10(1):37–44
19. Morais Y, Burity T, Elias G (2009) A systematic review of software product lines applied to mobile middleware. In: Pro-ceedings of 6th international conference on information tech-nology: new generations, USA, April, 2009
