Sensor Systems and Software: Second International Icst Conference, S-Cube 2010, Miami, FL, December 13-15, 2010, Revised Selected Papers

Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering Editorial Board Ozgur Akan Middle East Technical University, Ankara, Turkey Paolo Bellavista University of Bologna, Italy Jiannong Cao Hong Kong Polytechnic University, Hong Kong Falko Dressler University of Erlangen, Germany Domenico Ferrari Università Cattolica Piacenza, Italy Mario Gerla UCLA, USA Hisashi Kobayashi Princeton University, USA Sergio Palazzo University of Catania, Italy Sartaj Sahni University of Florida, USA Xuemin (Sherman) Shen University of Waterloo, Canada Mircea Stan University of Virginia, USA Jia Xiaohua City University of Hong Kong, Hong Kong Albert Zomaya University of Sydney, Australia Geoffrey Coulson Lancaster University, UK

57

Gerard Parr Philip Morrow (Eds.)

Sensor Systems and Software Second International ICST Conference, S-Cube 2010 Miami, FL, USA, December 13-15, 2010 Revised Selected Papers

13

Volume Editors Gerard Parr Philip Morrow University of Ulster, School of Computing and Information Engineering Cromore Road, Coleraine, Co. Londonderry Northern Ireland, BT52 1SA, UK E-mail: {gp.parr; pj.morrow}@ulster.ac.uk

ISSN 1867-8211 ISBN 978-3-642-23582-5 DOI 10.1007/978-3-642-23583-2

e-ISSN 1867-822X e-ISBN 978-3-642-23583-2

Springer Heidelberg Dordrecht London New York Library of Congress Control Number: 2011935462 CR Subject Classification (1998): C.2, K.6, K.4.2, D.2, D.4, J.3

© ICST Institute for Computer Science, Social Informatics and Telecommunications Engineering 2011 This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com)

Preface

The Second International ICST Conference on Sensor Systems and Software (S-Cube) was held at the National Hotel, Miami Beach, during December 13–14, 2010. The conference was a two-day event covering many aspects of wireless sensor network systems and their management and control software. Wireless sensor systems are increasing in importance both in the academic and commercial worlds: the availability of innovative sensing technologies and low-cost, low-power wireless communications have made it possible to create and tailor hardware designs to specific applications such as smart homes, assisted living, railway track and signal management, environmental monitoring and measurement and nextgeneration healthcare monitoring. However, the control and management software for such systems has, to a large extent, been bespoke, and the development of novel programming paradigms that support the modularity, scalability and reusability of generic software components is a challenge the research community is addressing to come up with scalable solutions. The conference offered a forum for industrial and commercial sensor design and applications developers to interact with those from other research groups. There is a need to foster a greater understanding of the technical and operational constraints of real sensor deployments and the difficulties present in the ever-increasing complexity of real systems that may have to deal with sensing in real time, acquiring large amounts of raw data and operating in sometimes harsh communications environments. The conference included a keynote talk by Sumi Helal, Professor in the CISE Department at the University of Florida, and Director of its Pervasive and Mobile Computing Laboratory. He presented ongoing research efforts in defining and supporting programmable pervasive spaces, from “assistive environments” for the elderly to ATLAS, a middleware architecture and sensor platform that was used as the foundation for the Gator Tech Smart House. Seventeen papers were accepted for presentation at the conference across six main categories: Sensor Application Programming Paradigms; Novel Sensor Applications; Sensor Network Middleware; Trust, Security and Privacy; Wireless Sensor Network Management and Monitoring; and Sensor Application Development Support Systems. This conference could not have happened without the support of many people. I am grateful for the support of our sponsors: the ICST, who made this conference possible, and Create-Net. I am particularly indebted to my colleague Philip Morrow in his role as TPC Chair for his undaunting eye for detail and planning and for his assistance in organizing the technical programme. I am also very grateful to the Florida International University for assistance with local arrangements and advising such a stunning venue for the event. In particular I wish to thank Ming Zhao from Florida International University for assistance with the local arrangements in Miami.

VI

Preface

I also wish to express my appreciation to Tarja Ryynanen of ICST for her organizational guidance and support in managing the interactions with the various stakeholders and conference supporters and to JeongGil Ko of Johns Hopkins University who did a sterling job with the conference website. On behalf of all attendees, I would like to thank the S-Cube 2010 Steering Committee and the members of the Technical Programme Committee and Track Chairs for their support and efforts. In particular I wish to acknowledge Steve Hailes, who invited me to take on the role of Conference Chair. Finally, thanks is also due to Brian J. Bigalke and Tamas Deli of ICST for their assistance with the production of the conference proceedings and CD. Gerard Parr

Organization

Steering Committee Imrich Chlamtac Sabrina Sicari Stephen Hailes

Create-Net, Italy (Chair) Universit` a degli studi dell’Insubria, Italy University College of London, UK

Conference General Chair Gerard Parr

University of Ulster, UK

Web Chair JeongGil Ko

Johns Hopkins University, USA

Conference Coordinator Tarja Ryynanen

ICST

Technical Programme Committee Chair Philip Morrow

University of Ulster, UK

Local Chair Ming Zhao

Florida International University, USA

Track Chairs Sensors for Assisted Living Chris Nugent

University of Ulster, UK

Scalable Deployment Strategies for Sensor Clouds Stephen Hailes

University College London, UK

Sensor Data Fusion Tools and Techniques Sally McClean

University of Ulster, UK

VIII

Organization

TPC Members Alberto Coen Porisini Alicia As´ın P´erez Animesh Pathak Bryan Scotney Chris Nugent Eiko Yoneki Eli Katsiri Gerd Kortuem Houda Labiod Krishna M. Sivalingam Lu´ıs Lopez Masum Hasan Mattia Monga Mirco Musolesi Philip Morrow Sally McClean Sam Michiels Subrat Kar Tatsuo Nakajima Uday Desai Jane Tateson Ming Zhao

Universit` a degli Studi dell’Insubria, Italy Libelium, Spain INRIA, France University of Ulster, UK University of Ulster, UK University of Cambridge, UK Birkbeck College University of London, UK Lancaster University, UK Telecom ParisTech, France Indian Institute of Technology, India Universidade do Porto, Portugal Cisco Systems, USA Universit` a degli Studi di Milano, Italy University of St. Andrews, UK University of Ulster, UK University of Ulster, UK Katholieke Universiteit Leuven, Belgium Indian Insitute of Technology Delhi, India Waseda University, Japan Indian Insitute of Technology Hyderabad, India BT Innovate & Design, UK Florida International University

Table of Contents

Sensor Application Programming Paradigms Wireless Sensors Solution for Energy Monitoring, Analyzing, Controlling and Predicting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Marius Marcu, Cristina Stangaciu, Alexandru Topirceanu, Daniel Volcinschi, and Valentin Stangaciu Policy-Driven Tailoring of Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . Nelson Matthys, Christophe Huygens, Danny Hughes, J´ o Ueyama, Sam Michiels, and Wouter Joosen

1

20

Novel Sensor Applications Integration of Terrain Image Sensing with UAV Safety Management Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timothy Patterson, Sally McClean, Gerard Parr, Philip Morrow, Luke Teacy, and Jing Nie A Study on the Wireless Onboard Monitoring System for Railroad Vehicle Axle Bearings Using the SAW Sensor . . . . . . . . . . . . . . . . . . . . . . . . Jaehoon Kim, K.-S. Lee, and J.-G. Oh

36

52

Sensor Network Middleware Middleware for Adaptive Group Communication in Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Klaas Thoelen, Sam Michiels, and Wouter Joosen

59

A Middleware Framework for the Web Integration of Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Herv´e Paulino and Jo˜ ao Ruivo Santos

75

Expressing and Configuring Quality of Data in Multi-purpose Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pedro Javier del Cid, Daniel Hughes, Sam Michiels, and Wouter Joosen A Lightweight Component-Based Reconfigurable Middleware Architecture and State Ontology for Fault Tolerant Embedded Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jagun Kwon and Stephen Hailes

91

107

X

Table of Contents

Distributed Context Models in Support of Ubiquitous Mobile Awareness Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jamie Walters, Theo Kanter, and Roger Norling

121

Trust, Security and Privacy SeDAP: Secure Data Aggregation Protocol in Privacy Aware Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alberto Coen Porisini and Sabrina Sicari

135

A Centralized Approach for Secure Location Verification in Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abbas Ghebleh, Maghsoud Abbaspour, and Saman Homayounnejad

151

How Secure Are Secure Localization Protocols in WSNs? . . . . . . . . . . . . . . Ch´erifa Boucetta, Mohamed Ali Kaafar, and Marine Minier

164

Wireless Sensor Network Management and Monitoring DANTE: A Video Based Annotation Tool for Smart Environments . . . . . Federico Cruciani, Mark P. Donnelly, Chris D. Nugent, Guido Parente, Cristiano Paggetti, and William Burns Pro-active Strategies for the Frugal Feeding Problem in Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Elio Velazquez, Nicola Santoro, and Mark Lanthier Integrating WSN Simulation into Workflow Testing and Execution . . . . . Duarte Vieira and Francisco Martins

179

189 205

Sensor Application Development Support Systems Revisiting Human Activity Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eunju Kim and Sumi Helal Deriving Relationships between Physiological Change and Activities of Daily Living Using Wearable Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Shuai Zhang, Leo Galway, Sally McClean, Bryan Scotney, Dewar Finlay, and Chris D. Nugent Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

219

235

251

Wireless Sensors Solution for Energy Monitoring, Analyzing, Controlling and Predicting Marius Marcu, Cristina Stangaciu, Alexandru Topirceanu, Daniel Volcinschi, and Valentin Stangaciu “Politehnica” University of Timisoara, Faculty of Automation and Computer Science 2 V. Parvan Blv., 300223 Timisoara, Romania [email protected], [email protected], [email protected], [email protected], [email protected]

Abstract. The work presented in this paper addresses the problem of energy wastes through irresponsible usage of computers or electrical devices, as well as wastes encouraged by companies or firms that do not implement any kind of power awareness plan. It is meant to help increase the power usage efficiency in the locations it is installed, by completing an extensive survey of power usage patterns over a short period, and then presenting clear expressive power consumption results of the monitored location, together with recommendations of action plans that would save energy if applied. Based on the consumption analysis, studying energetically profiles for different electrical devices, prediction of power consume and savings can be made. We propose a new wireless sensor network solution that can be used to profile power consumption of both electric power connected devices and battery-powered devices running different applications. The proposed solution offers a better and easier way to monitor the energy each of the target devices, and get real time feedback on the effect of different usage patterns applied to target devices. Keywords: power consumption, power characterization, power profiles, power signatures, wireless sensors network.

1 Introduction The information and communication technology industry is responsible for 2% of the global carbon dioxide emission. The figure is equivalent to aviation industry [1]. In Europe, the energy consumption in data centers was 46 Terawatt hours, in 2006, and 70 Terawatt hours in USA in 2007. This is the equivalent of one hundred million 100 watts light bulbs running 24 h/day 365 days [2]. Moreover, a reduction of the energy consumed by the IT equipment has the greatest impact on overall consumption, because they cascade across all supporting systems [3]. Another aspect of the problem is the high energy consumed in data centers. Gartner’s research showed that data centre and IT managers are interested in internal projects like rationalization and virtualization. In order to achieve improvements in G. Parr and P. Morrow (Eds.): S-Cube 2010, LNICST 57, pp. 1–19, 2011. © Institute for Computer Sciences, Social Informatics and Telecommunications Engineering 2011

2

M. Marcu et al.

the energy efficiency for data centers, it is necessary to gain a better understanding of server power consumption and how does this influence the server performance [4]. As far as household domain is concerned, in 2006, BBC predicted that irresponsible behavior of home users in UK would cause an emission of carbon dioxide of 43 millions of tones by 2010 and a cost of £11 billion, coming only from electrical energy wasted during this time [5]. Therefore, important institutions like The European Parliament discussed about reducing energy waste and new standards for standby power consumption of electronic devices [6]. The European Union action plan to increase energy efficiency is oriented also on changing energy behavior of the consumer, public awareness being one of the priorities [7]. Besides the European Parliament, other important institutions (as the European Commission, the Economic Committee etc.) have participated in an awareness-raising campaign on energy saving 'M'illumino di meno' (meaning ‘I'm using less light’) on 12th of February [8]. This action shows their interest in reducing energy usage, by eliminating energy waste. Only advanced monitoring, modeling and measuring techniques would lead to an effective energy management [9]. A system to monitor the electrical consumption of individual devices in a home or office buildings could help people make decisions that are more informed on how to alter their usage patterns and choice of electrical devices in order to conserve electricity. This detailed picture would help users better identify those devices or usage patterns that are leading to needless electricity consumption. Therefore, we propose a system to monitor, analyze and control the energy consumption of individual devices in a home, office building or data centre could provide the necessary tools that lead to a superior energy management. The proposed solution is a better way for individuals or companies to see how much electricity each of the devices in their homes and offices consume, to make a prediction based on consumption habits and try to control the amount of electrical energy that is used. One practical aspect of our solution is that the user can receive a more detailed feedback on the energy used by receiving an electric bill with a line for every individual device that details how much electricity that device used over the monitored period and shows a graph of the power consumption through time. We aimed our system to be a configurable one, which takes into consideration the three types of users (office buildings, data centers, home user), and their particularities: − In office buildings, the energy waste can be reduced by offering a system that monitors and controls the energy consumption. A simple action, as shutting down PCs at night saves $15 to $20 per computer annually [10]. Office buildings are characterized by a large number of systems of the same class, usually desktop computers that have the same kind of usage profile. Therefore, electrical and computing devices existing in office buildings need various profiles according to the companies working program in order to optimize energy consumption according with their weekly program. Every such profile offers the needed level of usability for the devices at the minimum energy, hence energy efficiency could be obtained; − For data centers we want to offer a less expensive solution that monitors and analyses consumption at different levels (server level, cooling system etc). We are

Wireless Sensors Solution for Energy Monitoring, Analyzing, Controlling

3

motivate by the fact that in the present, there is a lack of detailed information about power consumption at the rack or row level [11]. Therefore, without an accurate measuring, there is no basis for trying to optimize data centers [10]. Data centers equipments are characterized by high availability under different load levels, therefore the existing power management solutions must not influence the quality level of the services they are implemented for. One possible solution in such environments is to use the proposed system in order to implement a dynamic balancer between virtual machines and physical machine in order to obtain optimum energy efficiency for the current performance and quality requested level; − As for home users, we propose a solution that will make people aware of their consumption habits, helping them reduce costs and try to make them more responsible. Home buildings are characterized by a much larger variety of electrical, electronic and computing devices: TV sets, DVD Players, desktop and laptop computers, washing machines, air conditioning, refrigerator, microwave, radio sets, etc. This variety of devices implies a variety of power signatures and usage patterns which makes the energy consumption uncontrollable [12]. The most important aspect for home usage energy efficiency is to identify users’ bad habits and to make them aware of their effects. These goals can be achieved by means of four actions implemented as core features in the proposed solution: monitor, analyze, control and predict. − monitor feature permits online measurement of all or targeted devices in order to save power consumption, voltage and current consumption values into the database for further analysis and to provide a real time image of instant overall or particular device power consumption; − analyze feature provides a way to extract relevant data from the measurements existing already in the database. This module offers a number of various reports and charts that show different perspectives on overall or specific energy consumption for certain period of time; − control feature is an important mechanism to programmatically switch on or off specific devices according with its class or usage profile. However, some problems may appear when controlling certain devices, like computer systems, because of their specific shut down process in order to avoid data loss; − prediction is needed mainly for dynamic power management implementation in order to select the correct management decisions in order to optimize the overall power consumption under certain requirements. Prediction can be implemented as long term and short term trends generation starting from measurements stored in the database. In this paper we describe in Section 2 the other actual work related to the domain addressed in our project. The overall architecture of the power consumption monitoring solution is presented in Section 3. The solution architecture contains both hardware and software solution design. In Section 4 the power signatures of electrical devices are introduced together with their characteristics and the example and discussion of the extracted power signatures for one type of electrical device. The conclusions are presented in the last section.

4

M. Marcu et al.

2 Related Work Reducing energy consumption of electrical devices has both economical and ecological benefits, but it also opens new research directions related to the interpretation of power consumption data. The research directions we are interested to explore starting from the power consumption monitoring of various devices are: energy and power signatures definition and their characteristics; the relation between usage patterns, power profiles and energy signature; and new application-aware power management techniques for energy efficiency. In this section we first discuss current tools for monitoring electrical consumption then we present some research papers which address power and energy monitoring and analysis. Although there are a number of options for measuring power consumption at the level of a total building (the electric meter being the most obvious), a cheap scalable option for measuring power consumption of each device individually does not exist [13]. The current way one can measure power consumption of an electric system is to use an on-the-self device like Kill A Watt [14] or Watts Up Pro [15]. Both of these features make it difficult to develop a practical real time system specific picture of energy usage that contains many individual devices because the user must go to each monitor in order to record the data [13]. Most of the available solutions [16] are oriented on consumer market therefore they do not offer complex features and power management support or integration. On the other hand, professional solutions oriented to servers and network equipments in data centers are expensive and they are oriented mainly on alarms and failure avoidance, but they are not used for dynamic power management. In [16] there are presented ten energy monitoring tools: EnergyHub, Tendril, Onzo, Agilewaves, Google PowerMeter, GreenBox, The Energy Detective, PowerMand, Green Energy Options, and Energy Aware. It is out of the scope of this paper to present and compare all these devices, but [16] is a good starting point to explore these solutions. The author of [13] proposed an electrical power monitoring system containing distributed units that transmit power consumption data wirelessly via RF radios to a central base station. The designed monitoring units plug into an outlet and then the device being monitored is plugged into them. The base station parses the incoming data from multiple monitors to determine the power consumption of each device in order to have an overview on overall power consumption. Our solution is similar with the solution described in [13] in terms of hardware overall architectures but it much more oriented on the four core features implemented in the software (monitor, analyze, control and predict). In [17] the authors proposed to implement a virtual instrument for the electric power quality monitoring aiming to act in real-time for detecting, monitoring and recording all typical disturbances superimposed on the ideal signal. Their goal is to extract the voltage and power quality parameters for the power distribution network. The authors present a completely digital method for the fast and accurate monitoring of the electrical power quality useful to produce real time quality/ disturbance reports. In the paper, the mathematical basis of the proposed estimation algorithm is discussed in terms of reliability and uncertainty. This work is different from ours because we do not address the quality or disturbances of power lines but we consider the power signatures and their relation with the usage pattern of the device.

Wireless Sensors Solution for Energy Monitoring, Analyzing, Controlling

5

An interesting idea is presented in [18], where the authors try to find a way to obtain detailed information about electricity consumption in a building, at a low cost, without the usage of distinct power meter for every target device. They intend to achieve this goal using a non-intrusive method, maximizing the use of the existing infrastructure rather than imposing the need to install various new devices in the building, thus reducing the associated hardware and labor costs. In order to split overall power consumption data they built a data acquisition system that samples voltage and current at 100 kHz and calculates real and reactive power, harmonics, and other features at 20Hz. The authors showed that under certain conditions disaggregating the total power consumption between different plugged devices is an achievable task, and can be done with a relatively high degree of accuracy. However, the problem is much more challenging in the real world, where not only does the number and type of appliances increases, but also the measurements are susceptible to more noise and obtaining ground truth data becomes more difficult [18]. Furthermore, they did not take in account complex devices, like computers, which do not have constant levels of power consumption, but it varies significantly with the running applications. The original aspects of our work are: identification of specific aspects of different types of users power consumption patters and their energy management requirements; definition and implementation of the core features required by a complete energy management solution; definition of power signatures and their relation with the usage patterns; design and implement the extensible and cost effective wireless sensors network and software application for power consumption monitoring, analysis, control and prediction.

3 Solution Architecture The proposed solution aims to address a wide range of needs in this domain, and that was the starting principle in the design process. We have to take into account different usage scenarios in order to satisfy as many requests as possible. Also, given the use of the wireless sensors, the topology of the location has to be accounted for. That is why an incremental design process was selected, which allows for developing a base solution which serves only a small segment of clients, and then extend it with more functionality at each step. We started with addressing office buildings, which present a high density of computers and workstations. There are two advantages in this approach. Firstly, the types of devices to be monitored do not vary considerably, because all computers can be abstracted to a one-phased AC powered device. This means that the hardware needed in the implementation of this solution is the same for all devices, which lowers the development costs. A second advantage is represented by the fact that there are many devices to be monitored in such locations, in comparison with home or industrial locations. This stresses the software, because more data is processed and transported through the system at each architectural level. The added strain on the software part allows for a more reliable development process, because more code is covered and exercised at a high load, so the faults are caught earlier and the final result is more reliable.

6

M. Marcu et al.

The development process for this project carried us through many knowledge domains, from electrical engineering and computer network principles to database management, web design and event-based programming. We faced challenges in developing different parts of the system and were able to learn as we advanced through the design. The software development has different characteristics, depending on the level of the system it was done for. The low-level code for the microcontroller from the sensor nodes was written in AVR Studio development environment. This environment was chosen because it allows writing the code to the micro-controller’s flash in the same interface. Plus, it offers a real-time debugging option. Both this characteristics provide a faster development process and testing of the written code. The code for both the eBox and the server was written in C# using the .NET platform and Visual Studio 2010 Professional. The difference resides in the type of the projects. The user interface web application on the server is an ASP.NET MVC 2 project because it uses the model-view-control design pattern. The Windows Communication Foundation was used to assure the communication with the server, thus WCF projects were created separately for the eBox and for the server and the IIS service was activated. The rest of the functionality of the code on the eBox is integrated in the mentioned project and addresses Xbee communication, the configuration module, data base administration and the data processing modules. 3.1 Hardware Architecture In Figure 1, we designed the overall architecture for the hardware of the project. This design is built around the eBox which is considered the central embedded element of the system. This is a ready built device and no hardware alterations were done to it. Together with the sensor network coordinator, the eBox forms the central unit. The interface between the two is implemented through a USB port. Also, the components of a sensor node are specified in the figure. These are the Xbee module, an ATmega16 microcontroller and the measuring device adapted to the type of element which needs measuring. As far as the server is concerned, the hardware represents a normal Windows Server 2008 machine. The custom hardware components used in this project are further detailed in this section. The hardware layer of this project is mainly represented by monitoring devices with wireless communication capabilities (Figure 2), whit each device being connected between the AC line and an electrical consumer. These devices together form a sensor network designed to measure the power consumption and AC line parameters within an office building, a datacenter or a personal home. The wireless sensor network is responsible for acquiring power measurements from the devices attached to the AC line and transmitting them to a central unit. Each node is composed out of a controller specialized in measuring AC line parameters such as voltage, current, active power and frequency, a wireless communication device and a microcontroller which controls the whole activity of the device. Besides measurement capabilities, each node has a secondary task such as routing the information to the central unit. Each measuring node is identified through a unique serial number provided by the wireless device.

Wireless Sensors Solution for Energy Monitoring, Analyzing, Controlling

Fig. 1. Overall solution architecture

Fig. 2. Measuring device architecture

3.2 Software Architecture The product is structured in three separate stand alone applications: − the EBox component which can collect data from the sensors and also control them;

7

8

M. Marcu et al.

− the Web portal which can be used to represent data in a logical and friendly fashion; − the Web Service which holds the logic to access and modify the data for outside consumers (clients) for example the EBox. All was centered around the data logic and modeled as a separate project with logic shared between the other components (service, reports, web portal, admin applications). As a development platform we used .NET 4 with its enhancements for Entity Framework and ASP MVC. For modeling the data layer it has been used Entity Framework 4 and Unity 2.0 in order to assure a persistence and context ignorant scenario for each application this was deployed to. Persistence ignorance was assured by POCO objects (a feature introduced in Entity Framework 4) while the context “ignorance” was handled by making use of Dependency Injection found in Unity 2.0 Framework. On top of this came the service with its logic to access and modify database sensible content. The Service was done with WCF and if the client supports WS Binding, than it can make use of sessions (different instance/session) enabling caching and logic enhancements. The Website was meant to provide frontend business capabilities and was developed with ASP MVC 2.0 making also use of the same logic as the service. Rich client graphics and effects were accomplished by using jQuery with some of its famous controls/plugins (apple like menus, tabs, grids) which we enhanced to support different business scenarios for example paging in grids, autocomplete in comboxes.

Fig. 3. Overall software architecture

Wireless Sensors Solution for Energy Monitoring, Analyzing, Controlling

9

The software part of the system is described in Figure 3 [12]. As mentioned before, the various components follow the general system architecture, with the code on the eBox being the one offering the main functionality. The applications written in different levels of the system have distinct characteristics and are described below. First, we first have the low-level code that is written for the microcontroller in the sensor nodes. There is a separate part that regards the coordinator. This consists of the serial communication protocol for the connection with the eBox. The code on the endpoints differs from the one written to the coordinator, because the controller on the endpoint has to communicate with the measurement device and read data from it. So, the serial interface is replaced by the interface with the devices. Both types of sensor nodes implement a communication protocol between them, which builds on top of the already existing layers. Second, we have the software on the eBox, build on top of a Windows Embedded 6.0 Image. The eBox gathers all data from the monitored devices and stores it using the compact version of SQL Server 2008 for embedded devices. A monitoring module congregates data into clusters of measurements coming from the same source and adds a timestamp to make chronological ordering possible. Then a mild analysis is done to remove inconsistent data from the clusters, such as misreads or values that could not practically exist, but are reported due to specific events in the power line, especially in alternative current. After the analysis, the data can be stored into the database. After the analysis, the data can be stored into the database. In this state, the data is structured into chronological data samples from the same source, and each source has its own data. Reporting and analysis features were provided by Microsoft’s Reporting Services 2008. Data was stored in Microsoft Sql Server 2008 R2. Though not implemented yet in the web portal, support for localization (example Bing Maps) it’s present. The database structure we designed is presented in Figure 4. There are a number of 15 tables that resulted from the normalization process. We have a table-cluster that represents the hierarchical representation of an organization (company-departmentlocations (rooms)) and a set of corresponding maps for each location. On the other side, an abstract representation of physical elements can be seen (monitored device, eBox, consumption). The central tables are the user table, which can access identity, rights, location, consumption and devices information. For security reasons, the password field contains the md5 code of the user-selected password. We used this encryption for its proven correctness and safety in many domains and applications. In this way, the only place the password itself is available, is the login form textbox where the user enters it. Each device has an ID, from the XBee unique serial number, the name given by the user, the name of the location it measurement entry has a timestamp, the values of the current and voltage from which the power will be calculated, and a reference to the device that provided this measurement. The same structure is available on the data base present on the server. For the communication to the server, Windows Communication Foundation is used. The server makes available through WCF several services regarding the data transfer. One service assures that the two SQL Servers present in the system stay synchronized. Another is used to communicate to the eBox which devices from the user’s list are enabled and which are disabled. The third service permits the eBox to upload the clusters of data to the server.

10

M. Marcu et al.

Fig. 4. Database architecture

The security measures taken at this point are described next. First, the communication through the WCF is done using https with a self signed certificate, for the moment. More important, at each access from the eBox to the server, the registration protocol is used, meaning that the username and password stored in the data base of the eBox are transmitted to the server. Only after the data is checked, the server allows the communication to start. If the provided username and password are found in the database on the server, but the eBox serial number is not present, the system assumes that a new eBox was added for the specified user, and registers it. Finally, there is the software running on the server. This is split into two parts. One consists of the discussed WCF Services: synchronization and data storing operate with the local SQL Server, while the user-parameter setting transmits to the eBox the user preferences. The second part is a web application that addresses the users of the system. This application is designed using the model-view-control pattern available in ASP.NET. The data regarding the current user is loaded from the global data-base containing measurements from all users and is stored in the model. Then, when the user requests certain information to be displayed, the controller enables the view containing the respective data. There is a view for the list of devices, and one for each of the devices, with the graphical representation of the consumed power over a period of time.

Wireless Sensors Solution for Energy Monitoring, Analyzing, Controlling

11

3.3 Analysis and Prediction Analysis and prediction are two of the four main functionalities of our solution. Moreover, they are the ones that mostly influence the user into changing his behavior. Analysis offers the user 4 various graphical representations of the consumption of one or more devices. − A first option would be to generate an intuitive graphical representation of the consumption of all devices in a selected location, over a defined time span. The total consumption is depicted with the help of bar charts. − Another chart will show the consumption distribution for a selected location, highlighting the contribution of each device to the locations total power draw. If, for any reason, a device is responsible for a major proportion of the consumption, the user might understand that he is misusing that certain device. − Third, the user can generate an individual consumption distribution pie-chart showing how much time the selected device spends in each of the four consumption categories: low-power, normal mode, high and very high. The piegeneration algorithm is straightforward: having the minimum and the maximum consumptions over the selected time interval, all consumption readings (in Watts) are attributed to one of the four categories by the following criteria: interval = maximum – minimum if (Watts <= interval * 0.20 + min) -> low-power (0-20%) else if (Watts <= interval * 0.60 + min) -> normal mode (20-60%) else if (Watts <= interval * 0.80 + min) -> high mode (60-80%) else -> very high consumption (80-100%)

− Finally, a classic XY chart, showing the consumption evolution over a selected time span, can be generated. Note that, if, for instance, the user selects a very broad time span, it will be automatically narrowed to the space in which readings have occurred, so that the representation area will be filled by graphics. All four analysis graphics can have their representation step set to a day, week, month or a year. Prediction is again, a simple yet powerful tool, which will offer the user an insight on the possible consumption evolution over a selected period of one day, one week, one month or a whole year. Of course, the accuracy will depend on the amount of data has already been collected. The generated report or graphical representations are based on the same algorithm: − All (W) readings are clustered into groups corresponding to the prediction range (e.g. if “weekly prediction” is selected, all readings for the selected device will be grouped into clusters for each week up until the last finished week) − For every cluster an average consumption is computed for each temporal subunit (e.g. for “weekly prediction”, the subunit is day. An average consumption will be computed for each Monday, Tuesday … Sunday. The subunit for day is hour, for week day, for month week and for year it’s a month). − In order to predict to consumption for each temporal subunit the following computations are done:

12

M. Marcu et al.

N = number of available subunits with recordings Next subunit possible average consumption = {subunit (N) - [subunit (N) - subunit (N-1)] / 2 + average (subunits)} / 2 (E.g. we have the following consumptions: Monday (N) = 100W, Monday (N-1) = 60W and overall Monday consumption M = 70W. We need Monday (N+1), which equals [100 – (100 - 60) / 2 (100 – 20 + 70)/2 = 150/2 = 75 W)

+ 70] / 2 =

As can be seen, the prediction algorithm focuses on the idea that our consumption habit for the next tine interval depends on the habit over the last two intervals, and is further approximated with the help of the overall average consumption habit. 3.4 User Features The targeted clients of our service have very different profiles, from company managers or representatives, who want to reduce power consumption in a certain branch, to individuals who want to analyze the energy consumption in their homes. That is why we designed the solution to require less training on the user part and not to rely on any previous knowledge other than internet browsing. After this step, the system is powered on and the client only needs an internet connection to access the server and use the application. The user interface presents a list of all the registered devices for the logged in user. The device name and id are displayed, together with the power consumed by the device since the start-up of the system, both in absolute values and in percentages of the total power consumed. View current/ previous power data

Set consumption threshold alert

Single node information

View node signal strength

Consumption statistics

Highest/lowest consumption per node

Overloaded nodes

Cluster information Reports

Graphics

View topology

MONITORING

ANALYSIS

BROWSER CONTROL

PREDICTION Predict energy consumption

Daily / weekly / monthly consumption

Energy‐saver profiles

Specific devices/nodes consumption

Power option commands to PCs

Fig. 5. Features overview

Plugged device control

Switch on/off node

Limit node parameters (voltage,current)

Wireless Sensors Solution for Energy Monitoring, Analyzing, Controlling

13

Any user may opt for one of the four main functionalities (depicted in Fig.5) supported by the user interface (Fig. 6). The monitoring option offers a 2D spatial view of the installed network of plugs. Interaction is possible with all nodes, and data may be obtained from them in the form of reports or suggestive graphics. The prediction option is a special asset which may give an idea regarding, for example, the value of the next electric bill. The control option enables remote on/off switching of specific consumers and offers the possibility to apply a certain energy-saver profile. These profiles take decisions like turning off lights at night or putting a PC into hibernation.

Fig. 6. Graphical user interface

14

M. Marcu et al.

4 Power Signatures and Test Results 4.1 Power Signature Definition Power signature of an electrical, electronic or computer device is defined as the power consumption response to certain workload executed by the target device. Power signature is the variation in time of power consumption measurements when certain usage pattern is applied to the device. Some devices can show distinct power signatures function of the type of workload the device executes or function of the applications executed on the device. Therefore, power consumption of a device is not constant but it depends on various hardware parameters and user applications. Test methodology we used to extract power consumption signatures addresses two directions: the power states of target devices and the usage patterns of top level applications. Every device has at least two power states (on and off) while most devices implement more power states: off - the device is turned off, but it remains plugged in; sleep or stand-by - the device is in one of its power saving states, where it waits for certain commands to switch in active state again. In sleep states a device is not completely switched off in order to retain at certain level the last active device state or context, so that the active state can be easily activated; active - the device is turned on and executes its activities. The application level influence on power consumption is much more difficult to model but it has an important impact on the power signature. Considering the relation between type of workload executed by certain device and its power consumption variation when executing the workload, we grouped the consumer electrical devices in three classes: − Low-intelligence devices are considered the systems whose power signatures depend only or mostly on the hardware power states the device passes through when used. In this class we include consumer electrical devices like: refrigerators, washing machines, heating devices, air conditioning devices, etc. For these devices their power signatures are less influenced by their usage parameters or workload type they execute. − Medium-intelligence devices are considered the systems whose power signatures depend on both hardware power states and the workload the device executes. In this class we include the electronic devices containing some level of electronic control features: TV sets, radio devices, CD players, DVD players, set-top-boxes, fixed phones, etc. The power signatures of these devices are moderately influenced by the workload they execute. − High-intelligence devices are considered the systems whose power signatures depend mainly on the workload type and parameters they execute. We include in this class the computing systems containing at least one certain type of central processing unit like microprocessors or microcontrollers. In this class of devices we consider: desktop PC, notebooks, PDAs, SmartPhones, printers, network devices, etc. The power signatures of these devices are strongly influenced by the workload they execute.

Wireless Sensors Solution for Energy Monitoring, Analyzing, Controlling

15

For every type of device which can be seen as power consumption source we can establish different power signatures (or power fingerprints) which denotes the power consumption of the device for a given utilization profile (e.g. usage pattern, applied stimuli or workload). In our tests we observed that every electronic device has a specific power consumption profile for different workload type or usage patterns [12]. We started from the results obtained in [12] and we tried to identify the power signature characteristics and their benefits, and we take in study one simple device. 4.2 Test Workbench The performance criteria by which we benchmarked our system refer to specific metrics depending on the component being analyzed. The system as a whole has to be accurate, fast and scalable. During the tests, we observed the behavior of our system, paying special attention to faults occurred in the components of the system. The communication distances between two XBees were measured. In open space these were of about 30 meters. When the modules are separated by a 25 centimeters thick concrete wall, the communication between them is interrupted. On the other hand, a thinner wall, of 15-20 centimeters, only shortens the distance to about 10 meters. Glass doors do not affect the communication in any way, which is a good thing especially when using the system in office buildings. Regarding the transmission times, these are satisfactory, especially because we need to transmit a sample from a device every five minutes. This allows for enough time to gather measurements from all devices present and due to the processing power of the eBox, the samples are analyzed and stored in time, such that the workload on the eBox is not at constant high levels. Considering all these parameters, we tried to execute the tests in the same environment. For every type of device we considered specific set of tests in order to extract power signature characteristics. We tried to see two aspects of power signatures: whether they are the same or similar when executing similar workloads and second, whether they are distinct when executing different workloads. In our tests we considered one programmable device in the first class - a washing machine. 4.3 Test Results The first test was executed to identify the elements of the washing program and their effect on power consumption. There are seven phases of a complete washing program (Figure 7): − − − − − − −

(I) - the prewashing phase; (II) - water heating phase (40oC); (III) - first washing phase; (IV) - an optional heating phase between the two washing phases; (V) - second washing phase; (VI) - rinsing phase; (VII) - drain and drying phase (1000 rotations/minute).

16

M. Marcu et al.

Fig. 7. Washing program phases and their power signatures Power signature (test 1) P [W]

2500

2000

1500 Power signature 1 1000

500

0 1

501

1001

1501

2001

2501

3001

3501

4001

t [s]

(a) Power signature (test 4)

2500

2000

1500 Power signature 4

P [W]

1000

500

0 1

501

1001

1501

2001

2501

3001

(b) Fig. 8. Power signature repeatability

3501

4001

t [s]

Wireless Sensors Solution for Energy Monitoring, Analyzing, Controlling

17

The second test emphasis the stability and repeatability of power signatures when running the same washing program and the same clothes workload. We run the washing program four times and we monitored the power consumption (Figure 8a). The obtained power consumption signatures were the same, but some differences can be observed due to different amount of items washed. During test 4 there washing machine was loaded half of its full capacity therefore the heating phase is shorter because the washing machine automatically adapts to the workload (Figure 8b). During the test 2 we observed that the washing machine didn’t drain the clothes correctly. This malfunction can be observed in the power signature in Figure 9 (a). In Figure 9 (b) two differences are observed compared with standard power signatures: an extra spike to heat the water between washing phases and a larger drain phase. In our tests we obtained both similar signatures for similar programs and workloads and distinct signatures for different programs or workloads.

(a)

(b) Fig. 9. Power signature differences

18

M. Marcu et al.

Power signature (test 5) P [W]

2500

2000

1500 Power signature 5 1000

500

0 1

501

1001

1501

2001

2501

3001

3501

4001

4501

5001

t [s]

(a) Power signature (test 6) P [W]

2500

2000

1500 Power signature 6 1000

500

0 1

501

1001

1501

2001

2501

3001

3501

4001

4501

5001

t [s]

(b) Fig. 10. Washing programs power signatures

In Figure 10 two washing programs power signatures are presented. In Figure 10(a) there is a long program with full capacity loaded and the second chart depicts the power signature of a short washing program with only half of the capacity loaded. It can be observed in Figure 10 (b) the shorter heating phase duration due to the smaller quantity of water needed in test 6. It can be also observed the missing of the washing phase I in test 6, and this is specified in the selected washing program.

6 Conclusions In this paper we presented our proposed architecture for online monitoring of different consumer electronic devices. We defined the concept of power signatures of different types of devices and we run a number of tests for a device in every proposed class. Based on these preliminary results for every power signature class further

Wireless Sensors Solution for Energy Monitoring, Analyzing, Controlling

19

specific analysis can be done in order to observe usage flaws and malfunctions of the devices. For certain types of devices, power signatures can be used to monitor the usage pattern of that device and furter power management assumptions can be made. Acknowledgments. This work was supported by Romanian Ministry of Education CNCSIS grant 680/19.01.2009.

References 1. Gartner, Inc. Gartner Estimates ICT Industry Accounts for 2 Percent of Global CO2 Emissions. Gartner. Gartner, Inc. (April 27, 2007) 2. Falcon Electronics LTD, Measurement of Data Center Power Consumption, http://www.fe.co.za 3. Emerson: Energy Logic: Reducing Data Center Energy Consumption by Creating Savings that Cascade Across Systems, http://www.emerson.com/edc 4. Giri, R., Vanchi, A.: Increasing Data Center Efficiency with Server Power Measurements. Document. Intel Information Technology. IT@Intel White Paper (2010) 5. BBC, UK ’tops energy wasters league’ (October 23, 2006), http://news.bbc.co.uk/2/hi/uk_news 6. European Parliament. Action Plan for Energy Efficiency: Realizing the Potential (2008) 7. European Commission, Directorate-General for Energy and Transport. 2020 vision: Saving our energy. European Commission (2007), http://ec.europa.eu 8. Energy Saving Campaign: ’M’illumino di meno’. Press release (February 2010), http://www.europarl.europa.eu/sides/ getDoc.do?pubRef=-//EP//NONSGML+IMPRESS+20100212IPR68943+0+DOC+PDF+V0//EN&language=EN 9. Gartner, Inc. Gartner Says Measurement and Monitoring of Data Centre Energy Use Will Remain Immature Through 2011. Gartner (September 24, 2009) 10. Wong, W.: Green Tech. Tips, Biztech (March 2009), http://www.biztechmagazine.com 11. Giri, R., Vanchi, A.: Increasing Data Center Efficiency with Server Power Measurements. Document. Intel Information Technology. IT@Intel White Paper (2010) 12. Marcu, M., Popescu, B., Stancovici, A., Stangaciu, V., Certejan, C.: Power Characterization Of Electric, Electronic And Computing Devices. Scientific Bulletin of the Electrical Engineering Faculty (1) (2009) 13. LeBlanc, J.: Device-Level Power Consumption Monitoring. In: Proceedings of the 9th International Conference on Ubiquitous Computing, Austria (September 2007), http://www.awarepower.com/ubicomp07.pdf 14. Kill-A-Watt, http://www.p3international.com 15. Watts-Up-Pro, http://www.doubleed.com/products.html 16. Fehrenbacher, K.: 10 Monitoring Tools Bringing Smart Energy Home, Business Week (April 2009), http://www.businessweek.com/technology/content /apr2009/tc20090414_446611.htm 17. Adamo, F., Attivissiomo, F., Cavone, G., Lanzolla, A.M.: A Virtual Instrument for the Electric Power Monitoring in the Distributing Network. In: 15th Symposium on Novelties in Electrical Measurements and Instrumentation, Romania (2007) 18. Berges, M., Goldman, E., Matthews, H.S., Soibelman, L.: Learning Systems for Electric Consumption of Buildings. In: Proceedings of the ASCE International Workshop on Computing in Civil Engineering, Austin, Texas (2009)

Policy-Driven Tailoring of Sensor Networks Nelson Matthys1 , Christophe Huygens1 , Danny Hughes2 , J´ o Ueyama3 , Sam Michiels1 , and Wouter Joosen1 1

IBBT-DistriNet, Katholieke Universiteit Leuven, 3001 Heverlee, Belgium [email protected] 2 Department of Computer Science and Software Engineering, Xi’an Jiaotong-Liverpool University, 215123 Suzhou, China [email protected] 3 University of S˜ ao Paulo (USP), S˜ ao Carlos, 13566-585, Brazil [email protected]

Abstract. The emerging reality of wireless sensor networks deployed as long-lived infrastructure mandates an approach to tailor developed artefacts at run-time to avoid costly reprogramming. Support for dynamic concerns, such as adaptation, calibration or tuning of the functional and non-functional behaviour by application users and infrastructure managers raises the need for fine-grained run-time customization. This paper presents a policy-based paradigm to realize the diverse concerns of the involved actors by enabling fine-tuning and optimization of the runtime environment. Integration of the policy paradigm into various main programming models is analyzed. A prototype implementation of the paradigm in the context of an event-component based wireless sensor network platform is evaluated on the SunSPOT sensor platform. Keywords: Policy, Component models, Reconfiguration, Multi-paradigm Programming.

1

Introduction

Over the last few years, Wireless Sensor Networks (WSN) have evolved into long-lived infrastructure on which various applications from multiple actors may be executing concurrently [25,24,21]. This trend of moving away from the traditional monolithic application paradigm towards a general purpose execution platform capable of hosting a multitude of applications has already been exemplified by several scenarios that explore the advantages of using WSNs, such as environmental monitoring [16], road monitoring [4], or logistics [21]. In these application scenarios, WSN devices play a role which is merely not data-centric but expands to the execution of a localized part of the holistic application, in which the sensor acts as a general purpose execution platform, albeit with limited execution capabilities. As such, WSN infrastructure is becoming another tier of enterprise infrastructure on which various software components can be deployed over time, and which are potentially used and administrated by different actors. G. Parr and P. Morrow (Eds.): S-Cube 2010, LNICST 57, pp. 20–35, 2011. c Institute for Computer Sciences, Social Informatics and Telecommunications Engineering 2011 

Policy-Driven Tailoring of Sensor Networks

21

Both these multi-actor and long-lived usage modes drive the need for run-time customization or adaptation. More specifically, the need for run-time adaptation can be due to (i) changing requirements of a single application end-user in a long-lived setting, since it is impossible to capture all (future) requirements at development time, (ii) driven by the benefits of reuse by running customized versions of a single application for various application users, and (iii) plain change in the system environment over time. In the first case (i), the demands of the user with respect to the system change: a sampling frequency sufficient today may no longer be appropriate tomorrow. This ultimately comes down to the same requirement raised by the multi-actor perspective (ii) where services may differ only through customization of service behaviour, for instance in sampling frequency, persistence or security of collected data. These objectives are typically very specific to each user, and therefore cannot always be fixed during platform development time. To illustrate (iii), it is straightforward to envision different behaviour depending on location or energy status. As a result, appropriate programming abstractions must be foreseen that allow for each individual actor to tailor its portion of business functionality over time at run-time. In this paper, we propose a policy-based abstraction and associated programming model to accommodate the adaptation requirement, hereby enabling variations in functional and non-functional concerns of application end-users and system administrators. We demonstrate how our policy-driven system integrates in a non-intrusive way with (the interaction models) of the application logic programmed in the WSN and how it operationally aligns with the activities of the WSN administrative stakeholder. A prototype implementation on the SunSPOT [23] sensor platform is presented enabling flexible and fine-grained customizability of the WSN, while respecting its resource-constrained nature in terms of memory footprint and performance overhead. We validate through a case study in a WSN-based flood monitoring application where the policy-driven system is used to tailor the individual concerns of the various actors. The remainder of this paper is structured as follows. Section 2 motivates the case for and highlights the requirements of fine-grained customization in long-lived WSN scenarios involving multiple actors. Section 3 discusses how the policies are used as a paradigm to express and support the various concerns of different stakeholders and how to integrate them in existing systems. Section 4 validates a prototype implementation through a flood monitoring case, while its performance and overhead is evaluated in Section 5. Section 6 discusses related work. Finally, Section 7 concludes and sketches future work.

2

Fine-Grained Customization in Multi-actor WSNs: Motivation and Requirements

WSNs are moving away from the monolithic application model towards a sharedinfrastructure, multi-application usage mode where every device has an administrative owner controlling the device [10]. In this setting, multiple applications reflecting the functional (business) goals of their respective owners may execute concurrently on a node [25,21].

22

N. Matthys et al.

Consider for instance an environmental river-monitoring scenario where multiple entities may leverage a WSN to gather temperature, pollution, and water level data. Both governmental agencies as well as ecological scientists from universities are interested in pollution and temperature data, whereas local government is interested in flooding data to protect the livestock of the community along the river. During commissioning, certain activities are executed: first and foremost the application is composed out of subprograms. These programs are then deployed. Finally an initial configuration defining fixed sensor sampling and reporting rates is established. From this scenario, we can identify three drivers for run-time customization: 1. Since at commissioning time, ecologists do not know what base pollution values to expect, the alerting threshold will need updating. In fact, this value will change frequently with evolution of water quality. Within a long-lived application, customization happens frequently reflecting tuning or changing requirements. 2. The data gathering activities of the government and the scientist are fundamentally similar yet subtle differences in level of detail need to be accommodated. Large efficiency gains (footprint, programming effort) can be made in the WSN by using customized variants of the same application, for example with different operational parameters. Within a multi-actor setting, the possibility to customize greatly facilitates reuse and resource efficiency. 3. Alerting thresholds need to be adjusted depending on the location of the sensor and time of season, for example in extreme rainfall events pollution will typically be very high because of sewerage overrun. Customization rules describe change in system behaviour in response to system dynamics. Due to dynamism in many of these scenarios, WSN customization is not solely a one-time process as previous real world WSN deployments [16] have revealed, but rather a continuous process. Many operational parameters of the WSN (or its constructing system or application parts) will change continuously in response to changes in objectives of applications users, system administrators or in response to internal change such as mobility or available energy. In addition, the change cycle of above customizations is closely related to the type of abstraction which is used to realize that particular part of the application that is impacted by this change. For instance, pure business functionality, such as a generic sensing component, is changed less often compared to the rules governing the sampling behaviour of that component during extreme rainfall. Finally, since the above customizations are performed by both application endusers or system administrators during the run-time phase of the application, it should be recognized these users prefer to express their goals differently than developers [2]. Abstractions offered for run-time customization must therefore be intuitive and sufficiently high-level. In this context, rule-based declarative or imperative approaches are typically considered to be appropriate abstractions [10,3]. From this, the requirements of the mechanism to support these run-time customizations can now be identified:

Policy-Driven Tailoring of Sensor Networks

23

1. Fine-grained: supporting small and specific changes in behaviour and as such complementary to the development and composition activities of the applications where behaviour is described at large. 2. Light-weight: since the changes are frequent, it is beneficial to the WSN that their representation is compact and their execution imposes little overhead. 3. End-user abstraction: adequate abstraction so that less technical end-users rather than expert WSN programmers can express their goals. These requirements are in contrast with typical WSN reprogramming approaches such as TinyOS [15] that work monolithically, or even component-based engineering [8] where only coarse-grained change is supported. Component models do provide an attractive programming model for building multi-actor WSNs since new applications can be constructed in a cost-effective and resource-efficient manner by reusing existing components. Some level of support is offered in component models for the problems of dynamism and long-livedness of the WSN through the ability to add or delete functionality or modification of the existing composition at run-time. Yet, components are typically implemented as coarse-grained generic artefacts applicable for a wide variety of applications with little support for domain-specific customization. Thus, while component-based reconfiguration provides a generic mechanism for enacting changes, it is inefficient when only a few lines of code may represent that change. This is particularly critical for WSNs, where memory is limited and software updates are costly. So, while the component approach has clear merits, the combined requirements regarding change granularity, frequency, and end-user abstraction demand a specific solution with low development overhead, memory footprint, and performance overhead. Furthermore, the solution should integrate in a non-intrusive manner with the existing main development paradigm. Therefore, we introduce a lightweight framework for adapting application behaviour based on policies. Policies for this framework are high-level, declarative and platform independent, allowing end-users to easily tailor behaviour.

3

Policy as Paradigm for Fine-Grained Customization

Like regular programs, policies are abstractions that govern the behaviour of applications. By using policies functionally, the application actor can fine-tune the behaviour of a business function so that it better serves its purpose. Nonfunctionally, an infrastructure manager can realize its security or energy concerns through policy specification. For instance, sharing policies may indicate what actor may use which piece of functionality. In this section, we first discuss the life cycle of using policies as a programming paradigm for fine-tuning WSN behaviour. Secondly, we focus on possible strategies for integration in existing systems. 3.1

Policy Life Cycle

Several activities take place between policy specification by the application user and their actual enforcement or execution on the target device. Policies start

24

N. Matthys et al.

1 5 Policy enforcement

2

Policy analysis

3

Policy transformation

Policy specification

Application user A 1

Policy specification

Gateway 4

Sensor node

Secure policy distribution

Infrastructure Manager Application user B

Fig. 1. Policy life cycle: specification, analysis, distribution, and enforcement

their life cycle as high-level user-specified policies and subsequently undergo several levels of transformation and refinement to end up as code or configuration specifications that can be directly deployed and executed on the elements of an IT infrastructure [1]. To be applicable in the context of resource-constrained systems such as WSNs, it is crucial to make optimal use of the capabilities offered by the resource-rich back-end to perform most of these activities which are inherently heavyweight. Figure 1 illustrates the chain of activities that constitute the policy life cycle in the context of WSNs: 1. Policy specification happens by (non-technical) application users using tools helping them to create syntactically and semantically correct policies written in a policy language. These policies are then submitted to the administrative actor together with a list of applications and target nodes where they should be applied. 2. Policy analysis is a heavyweight activity which should exclusively happen in the resource-rich back-end of the administrative actor. It involves checking for conflicts between already applied policies and verification whether the policy is transparent for other users. If a policy is found to be correct, it is marked for transformation and distribution to the nodes. 3. Next, the policy is transformed into a more compact and optimized representation better suited for energy-efficient dissemination inside the WSN. 4. Since policies may potentially govern control over all types of functionality deployed inside the network, secure policy distribution is an essential part of the life cycle. Therefore, it is particularly critical that only authorized actors can deploy these policies and that they are disseminated in a secure and reliable fashion. 5. Installation and policy enforcement on a node happens upon reception and verification of the policy. After reception of the compact policy representation, an implementation-specific data structure more suitable for efficient evaluation is constructed which is then stored locally.

Policy-Driven Tailoring of Sensor Networks

3.2

25

Integration Strategies

Integration of the proposed policy-based programming paradigm with the main application development paradigm of the WSN should be transparent for the application developer whilst guaranteeing execution of the policies. At some point execution must be transferred from application code to policy code. The exact point in an application where redirection to the set of applicable policies or corresponding refined code is performed depends on the interaction model used for application composition. Classical interaction paradigms [5] in traditional distributed applications include amongst others (remote) procedure calls, method invocations, or event-based messaging, and the base entities (components in these systems) are considered reusable, solely identified by their type along with their interfaces and dependencies [8]. At development time, all applications are composed by combining individual components through a set of connections which model interface dependencies. At run-time, these connections are represented by a series of inter-component procedure calls or communication messages, depending on the interaction model used. Since both syntax and semantics of these component interactions are well standardized, it is advantageous to limit policy enforcement to these componentto-component interaction points. For tailoring and customization purposes of the application this set of points is sufficient. Hence, the integration of the policybased paradigm must a priori be supported by the interaction model or must be inserted in the interaction model before deployment through selective instrumentation. Regarding the interaction model, since (remote) procedure calls and method invocation are resource-heavy, they are not suited for the WSN target environment as scalability is compromised [14]. Therefore, we limit the scope of our research to event-based messaging, which is commonly used as interaction model in WSNs [15,18], and integrate our policy-based paradigm directly inside this interaction model. 3.3

Paradigm Benefits

Policies offer an attractive development paradigm complementary to the main application development paradigm used inside the WSN system. First, they provide a powerful abstraction for additional customization as they allow to specify and enforce various functional and non-functional concerns at run-time. Secondly, since policies are focused on a single concern, they can be lightweight (see Section 4). Thus customization is achieved at a reasonable energy cost. Finally, the fine-grained, independent distribution model complements the update model used by the main development paradigm, since it supports small changes to application compositions, hence accommodating evolving application demands and dynamic environmental conditions.

4

Research Prototype

A prototype of a framework supporting the proposed policy paradigm was implemented for an event-based run-time reconfigurable component model. For testing

26

N. Matthys et al.

and evaluation purposes, we applied the resulting framework in the context of a small-scale real world river monitoring case. 4.1

Implementation

Base Paradigm: Component Model. The Loosely-coupled Component Infrastructure (LooCI) [9] is a lightweight event-based run-time reconfigurable component model for WSNs. In the LooCI model, components are indirectly bound over an event bus abstraction, implementing a decentralized publish/subscribe interaction model. All LooCI components define their provided interfaces as the set of events that they publish, whereas the required interfaces of a LooCI component are similarly defined as the events to which it subscribes to. Reconfiguration in LooCI is enacted by mechanisms to dynamically deploy, start, stop, or remove components together with dynamic re-wiring of component bindings. Defining a LooCI component implicitly provides access to the event bus for inter-component communications and the underlying connectionless network framework. As a result, all communication between LooCI components is carried by events that allow for asynchronous and indirect communication between a pair of components. For our research, the key benefits of LooCI are, along with a small footprint and good performance, that it promotes this event-based interaction paradigm and a loose coupling between cooperating components. The set of introspective facilities includes support to discover components and their bindings on a node or between two nodes. Policy Framework and Language: The supporting framework for our policy based programming paradigm is illustrated in Figure 2. This framework is deployed on every node inside the WSN and is integrated with the LooCI event bus. Since all interactions between LooCI components occur as events over the event bus, it is possible to tailor multiple aspects of the system by modifying their content or configuring the manner in which these events are propagated. To facilitate this type of management, the LooCI run-time is extended with a compact policy engine, which executes a lightweight Event-Condition-Action (ECA) policy specification language. Every ECA policy consists of a description of the triggering events, a condition which is a logical expression typically referring to event criteria or external system aspects, and a list of actions to be enforced in response. Every time an event is sent between a pair of components via the event bus, the policy engine intercepts this event and evaluates how it should be modified based upon the set of per-node installed policy rules, stored inside a repository component. If the incoming event matches a policy rule, its associated action(s) will applied. At run-time, the set of policies can be dynamically updated accommodating evolving application requirements. Our prototype policy language allows various functions to be invoked inside the condition and action parts of a policy. Amongst these include actions to allow/deny the event to pass, change its contents, replicate and reroute the event towards an intermediate component for additional processing, or to publish a custom user-defined event, for example containing a configuration value destined

Policy-Driven Tailoring of Sensor Networks

Application Component A

EVENT_A

27

Application Component B

EVENT_A

Event Bus

INTERCEPT EVENT

(UN)DEPLOY POLICY

From Networking Framework

(DIS)ALLOW EVENT

PUBLISH EVENT

INVOKE ACTION

Secure Policy Distribution

Policy Engine

Policy Repository (UN)INSTALL POLICY

CHECK POLICY

Policy Framework Run-time

KEY Component

To LooCI Run-time

Provided interface Required interface

Fig. 2. Policy framework prototype

for a particular component. In this sense, policies offer a simple, yet powerful abstraction for end-users to fine-tune generic component behaviour, or for system administrators to inject various flavours of non-functional concerns. Policy Distribution Model: As shown in Figure 1, the policy distribution model forces all policy administration to go through the gateway, which is under control of the infrastructure manager and has a direct trust relation with each sensor. In our research prototype, this trust between the gateway and the individual sensors is established by using a pre-deployed public/private key scheme. Application users submit their (high-level) policies to the infrastructure manager in a secure manner using standard enterprise-grade security technologies such as TLS/SSL. Upon reception, these policies are analysed for consistency and transformed into a compact binary representation, more suitable for energyefficient dissemination inside the WSN. In order to deploy a policy on a sensor node, the infrastructure manager then transfers this compact policy representation together with its associated deployment instructions to the gateway using a secure connection, ensuring authenticity and confidentiality of the said policies when distributed to the gateway. Next, to securely deploy the policy inside the WSN, the gateway constructs a message M that securely encapsulates the following content D: D = [deploy_instr, dest_addr, id, timestamp, policy_data] M = D, M AC(KGW , D) In this message, deploy instr contains the deployment instructions such as install or remove a policy, dest addr is the node where the policy needs to be deployed, id indicates a sequence number used between the gateway and destination, timestamp is the current timestamp used as nonce, and policy data is the binary representation of the policy sent to the WSN. For integrity purposes, a Message Authentication Code (MAC), denoted as M AC(KGW , D), of the

28

N. Matthys et al.

policy data D is attached to the message M . This MAC is signed by the private key KGW of the gateway. Once received, the destination node can check whether the message has been sent from the gateway by using the pre-deployed public/private key pair to verify M AC(KGW , D). In this sense, non-repudiation of origin, integrity, and protection against replay attacks can be guaranteed. When this verification is successful, the policy data can be extracted from the message, transformed by the policy engine into a data structure which is more suitable for efficient evaluation, and added to the list of policies installed on the node. Note that this scheme only ensures integrity of the policy data and does not provide confidentiality. Policy authenticity can be assured between each node and the gateway, and between the gateway and network administrator. Optionally, confidentiality can be ensured inside the WSN via symmetric encryption using a session key generated by the pre-deployed public/private key scheme. 4.2

Real World Case Study

The combination of a lightweight component framework LooCI and policy framework was evaluated in the context of a small-scale real world river monitoring case in the city of S˜ ao Carlos, in S˜ ao Paulo state, Brazil. In this scenario, the WSN consisted of four SunSPOT [23] sensor nodes that were deployed to monitor river water quality. Different local environmental science partners monitored three environmental factors over a two-week period: (i) water depth was monitored using a hydrostatic level sensor in order to provide early warning of flood events, (ii) water conductivity levels were monitored using a standard conductivity sensor in order to infer pollution levels, and (iii) methane levels were monitored using a simple CH4 sensor in order to detect decaying organic matter. Finally, tamper and theft detection was implemented using the built-in three dimensional accelerometer of the SunSPOT. Application Composition: The river monitoring composition consisted of seven LooCI components that implemented generic functionality, including logging, encapsulation of hardware resources like sensors, or alert reporting. At platform commissioning time, these components were wired to each other as depicted in Figure 3(a). – A pressure sensor component periodically polls the hydrostatic level sensor and exposes these readings through events of type ‘PRESSURE’. – A conductivity sensor component periodically measures water conductivity and exposes these readings through events of type ‘CONDUCTIVITY’. – A methane sensor component exposes readings from the CH4 sensor via an interface of type ‘METHANE’. – An environmental alert component processes these readings, adds additional context information such as node ID and timestamp, and forwards these readings to the environmental scientists. – A generic logging component encapsulating access to the flash memory and processing ‘LOG’ events.

Policy-Driven Tailoring of Sensor Networks

TAMPERING ALERT

Administrator

TAMPERING ALERT (remote)

ENVIRONMENTAL ALERT

Scientist

ENVIRONMENTAL ALERT

PRESSURE

Administrator

TAMPERING ALERT

TAMPERING ALERT (remote)

ACCEL

ACCELEROMETER CONDUCTIVITY

Flood Detection Policy

LOGGING COMPONENT

LOG

METHANE

Conductivity Detection Policy

ACCEL

CONDUCTIVITY SENSOR

ACCELEROMETER

METHANE SENSOR

LOGGING COMPONENT

Scientist

ENVIRONMENTAL ALERT

Theft Detection Policy

PRESSURE SENSOR

Energyaware Reporting Policy ENVIRONMENTAL ALERT

29

Methane Detection Policy

CONDUCTIVITY

LOG

METHANE

PRESSURE

PRESSURE SENSOR

CONDUCTIVITY SENSOR

METHANE SENSOR

(a) Default component-based application(b) Policy-augmented application composicomposition tion Fig. 3. River monitoring composition

– Finally, to detect sensor tampering and theft, a tampering alert component in the back-end is remotely wired to an accelerometer component that provides readings from the built-in accelerometer via an interface of type ‘ACCEL’. Policy-augmented Composition: In contrast to the generic functionality offered by components, policies are used to tailor this functionality. For example, allowing scientists to set a specific level at which sensor readings should generate an alert. As a result of this, the basic application composition can be augmented with various types of policies as illustrated in Figure 3(b). An example policy for flood detection is provided in Listing 1.1, filtering readings at the source node and only allowing remote publication where the value exceeds a pre-defined threshold. As a result, the policy allows very specific customization of the flood alerting composition by the scientist, possibly depending on the time of season or the location of the sensor. It will not only prevent the publication of spurious alerts, but also conserve battery power. Similarly, an administrator can deploy a policy specifying an energy-aware alert reporting strategy for all environmental alerts inside the network. For instance, when the nodes are low on battery power everything must be stored locally, which is achieved through the publishing of a custom LOG event (Listing 1.2). policy " Flood detection " { on PRESSURE as p ; // PRESSURE contains parameter value if ( p . value > 500 ) then ( allow p ; // by default other PRESSURE events are blocked ) } Listing 1.1. Example of flood detection policy

30

N. Matthys et al.

policy " Energy - aware reporting policy " { on ENVIRONMEN TA L _A L ER T as e ; if ( POWER_STATE == LOW ) then ( deny e ; // do not propagate event publish ( LOG , e . data []) ; // but store it locally ) } Listing 1.2. Example of energy management policy set by the administrator

Similarly, other possible unanticipated concerns might be addressed by the injection of policies at run-time. As a result, Figure 3(b) illustrates policies for conductivity detection, tampering detection, and methane detection which are possibly written by different users.

5

Evaluation and Discussion

We have implemented and evaluated the performance of our policy-based programming paradigm on Java ME CLDC 1.1 compliant SunSPOT nodes [23] (180 MHz ARM9 CPU, 512 kB RAM, 4 MB flash, SQUAWK VM version ‘RED100104’). We investigate the overhead in terms of memory footprint, development overhead, and performance of policy evaluation and secure policy distribution. 5.1

Memory Footprint and Cost of Change

As presented in Table 1, the footprint of the policy framework is small. The run-time consumes 28 kB of ROM, which represents 0,6 % of the total flash memory available on the SunSPOT. Dynamic memory requirements (RAM) for the policy framework are small, requiring only 0,2 % of the total available RAM. The footprint for the component model run-time and the example components is higher, but still small w.r.t. resource capabilities. The disparity between ROM and RAM requirements of a component can be explained by SunSPOT-specific overhead due to the inter-isolate RPC server and the establishment of proxies. Representing a policy is efficient, as the compact representation of the policies used in the case study only occupies 72 bytes of static memory on average. When combined with the distribution protocol header size of 15 bytes, it represents the amount of data transmitted per policy from the gateway to an individual node. As a result, policy updates are lightweight compared to traditional componentbased reconfiguration. Upon reception, the policy data is transformed into a Java object more suitable for efficient evaluation, requiring 320 bytes of RAM on average for the policies applied in the case study. 5.2

Development Overhead

Table 1 also provides a quantitative assessment of development overhead in terms of Source Lines of Code (SLoC) of all components and policies. As can be seen,

Policy-Driven Tailoring of Sensor Networks

31

Table 1. Comparison of memory requirements and development overhead Static footprint (ROM) Dynamic footprint (RAM) SLoC Components: LooCI run-time Conductivity Sensor Methane Sensor Pressure Sensor Accelerometer Environmental Alert Logging Component Policies: Framework run-time Flood detection Energy-aware reporting Theft detection Conductivity detection Methane detection

52 kB 1.8 kB 1.7 kB 1.7 kB 1.9 kB 2.1 kB 1.9 kB

37 26 26 26 26 26 27

28 kB 64 bytes 102 bytes 65 bytes 63 bytes 62 bytes

1 284 440 292 296 286

kB kB kB kB kB kB kB

N/A 59 59 59 53 64 68

kB bytes bytes bytes bytes bytes

N/A 7 8 7 7 7

both paradigms are relatively compact and impose limited overhead on developers. The identical size of some artefacts listed in the table may be attributed to their simplicity and similarity (in all cases, components read a simple value from the SunSPOT Analog-to-Digital Converter (ADC) and transmit it over the event bus, whereas the policies do some simple filtering of spurious events). 5.3

Policy Engine Performance

Figure 4(a) illustrates the overhead of evaluating a number of policies against an event flowing between two components. The performance of policy evaluation includes the time to intercept and redirect the event to the policy engine (0.5 ms), followed by evaluation of matching policies, which was on average 0.5 ms per

10

900

’performance’

9 8

700

7

600

6 Time (ms)

Evaluation time (ms)

’signingtime’ ’verificationtime’

800

5

500 400

4 300

3

200

2

100

1 0

0

1

2

3

4 5 6 Number of policies

7

(a) Policy evaluation

8

9

10

0

0

250

500

750

1000 1250 Policy size (byte)

1500

1750

(b) Secure policy deployment

Fig. 4. Performance evaluation

2000

32

N. Matthys et al.

policy used in our case study. As can be seen from the figure, this scales linearly with the number of policies. Finally, it takes 6 ms on average to construct a policy from its compact representation into a suitable data structure, whereas 7420 ms are needed on average to initialize and start a regular component after deployment (due to registration with the LooCI run-time and establishment of inter-isolate proxies on the SunSPOT). 5.4

Secure Policy Distribution Performance

Subsequently, we investigate the overhead of secure policy distribution in terms of a varying length of policy data as input. Since policy signing happens at the gateway, which in the case study is a standard Internet-connected PC located near the river, it can be done efficiently. We mainly concentrate on the time it takes to verify M AC(KGW , D) at the receiving node. For signing and verification, we use the SHA-1 hashing algorithm, which makes use of the pre-deployed public/private key scheme [22] of the SunSPOT. As can be seen from Figure 4(b), verifying the authenticity of the message can be done in a constant time order (i.e on average 720 ms). Only the time to calculate the signature slightly increases with the input size (which could hypothetically be large), albeit this signing happens at the resource-rich gateway tier. As policy updates in the field test involved less then 80 bytes of policy data on average and 15 bytes of header data, we believe this overhead is still acceptable. 5.5

Lessons Learned from the Field Test

Through the case, several points were uncovered. Firstly, the ability to deploy policies with different coverage was found advantageous. The distribution model allows a single policy, implementing a specific concern, to be deployed to different entities inside the network, ranging from an individual component interface on a single device to the entire network. Secondly, because of diversity in functional objectives, nature of the concerns, resource-constraints, and change cycle, WSN applications benefit from “mixing- and-matching” multiple programming paradigms. In particular, artefacts of varying granularity are incorporated to reduce the impact of change on the system. Both relatively coarse-grained components and lightweight, fine-grained policies are key elements of effective solutions. Base artefacts can reflect dynamism of the application functionality and the control rules govern the behaviour of that functionality. This paradigm mix also supports the conceptual decoupling of stakeholder abstractions. Ordinary application users who often have little experience in programming, such as the ecologists in our case, had the ability to express how components developed by embedded systems experts should behave. However, applying multiple programming paradigms next to each other must be done with care. One paradigm can introduce additional behaviour opaque to the other paradigm or create tight coupling between the various artefact developers, both leading to unwanted side effects. An operational model where for example the network administrator analyzes the interplay between both paradigms can mitigate this problem.

Policy-Driven Tailoring of Sensor Networks

33

Regardless of the potential issues raised, it is our belief that the programming of WSN applications based on multiple paradigms holds great potential for large scale multi-actor scenarios such as the river monitoring application described in this paper. The approach respects both the skill-set of each actor and the resource constraints of the WSN.

6

Related Work

In recent years, a number of programming abstractions [18] have been proposed to simplify WSN application development, including programming models adopting the principles of component-based engineering. Their associated update models can be classified as either static or dynamic. NesC [7], perhaps the best known component model in the WSN field, adopts an event-driven programming approach as the interaction model in combination with a static update model. Reconfiguration translates to deploying a monolithic image, allowing for whole-program analysis and optimization. Run-time reconfigurable component models such as RUNES [4], or OpenCOM [6] follow a dynamic update model, allowing the composition to be changed at run-time through the deployment of new components and modification of component bindings. Despite their benefits regarding reusability, components are still artefacts solely supporting coarse-grained modifications. In order to use the component paradigm, additional support from the sensor operating system is equally needed. Modular updates at run-time can be provided, for example, by modular Virtual Machine (VM) solutions [13,25] or component-oriented operating systems [20]. A major drawback of VMs applied in energy-constrained systems is that they interpret byte code as opposed to components executing native instructions, which results in overhead. Similar to this research on combining a lightweight policy-based paradigm with a more generic main development paradigm, Koshi et al. [13] describe a hybrid approach that efficiently combines VM byte code interpretation with native code execution. Platon and Sei [19] emphasize the need for policy-based management of WSNs to provide for scalability of security. Marsh et al. [17] provide for a flexible and memory efficient policy specification language validating policy-based approaches for WSN management. Finger [26] provides support for the policy-based management of TinyOS [15] nodes in a relatively small footprint, though it offers no support of run-time reconfiguration of applications.

7

Conclusions and Future Work

This paper has made the case for a fine-grained, policy-driven approach to manage the diverse concerns of multiple actors involved in realistic WSN applications. The feasibility of this approach has been demonstrated through a prototype implementation on the SunSPOT platform, using an event-based component model as the base programming paradigm. We validated in a real world river monitoring scenario. As a result, the evaluation has shown that our approach is sufficiently lightweight and has clear benefits to be applied effectively in WSN environments.

34

N. Matthys et al.

In the short term, our future work will focus upon further investigation on the interplay of multiple co-existing programming paradigms. Furthermore, investigation of when to apply which paradigm is required as this might not always be always obvious for many goals. In this light, further collaboration with different WSN actors should give us the necessary insights. Acknowledgement. This research is partially funded by the Interuniversity Attraction Poles Programme Belgian State, Belgian Science Policy, the Research Fund K.U.Leuven, and is conducted in the context of the IWT-SBO-STADiUM project No. 80037 [11] and IWT-SBO-SymbioNets project No. 090062 [12].

References 1. Agrawal, D., Calo, S., Lee, K.-w., Lobo, J., Verma, D.: Policy Technologies for Self-Managing Systems. IBM Press (2008) 2. Bai, L.S., Dick, R.P., Dinda, P.A.: Archetype-based design: Sensor network programming for application experts, not just programming experts. In: IPSN, pp. 85–96 (2009) 3. Chu, D., Popa, L., Tavakoli, A., Hellerstein, J.M., Levis, P., Shenker, S., Stoica, I.: The design and implementation of a declarative sensor network system. In: SenSys 2007: Proceedings of the 5th International Conference on Embedded Networked Sensor Systems, pp. 175–188. ACM, New York (2007) 4. Costa, P., Coulson, G., Mascolo, C., Mottola, L., Picco, G.P., Zachariadis, S.: Reconfigurable component-based middleware for networked embedded systems. International Journal of Wireless Information Networks 14(2), 149–162 (2007) 5. Coulouris, G., Dollimore, J., Kindberg, T.: Distributed systems: concepts and design, 4th edn. Addison-Wesley Publishing Co., Inc., Boston (2001) 6. Coulson, G., Blair, G., Grace, P., Taiani, F., Joolia, A., Lee, K., Ueyama, J., Sivaharan, T.: A generic component model for building systems software. ACM Trans. Comput. Syst. 26(1), 1–42 (2008) 7. Gay, D., Levis, P., von Behren, R.V., Welsh, M., Brewer, E., Culler, D.: The nesc language: A holistic approach to networked embedded systems. In: Proceedings of the 2003 PLDI, pp. 1–11. ACM Press, New York (2003) 8. Heineman, G.T., Councill, W.T. (eds.): Component-based software engineering: putting the pieces together. Addison-Wesley Co., Boston (2001) 9. Hughes, D., Thoelen, K., Horr´e, W., Matthys, N., del Cid Garcia, P.J., Michiels, S., Huygens, C., Joosen, W.: LooCI: A loosely-coupled component infrastructure for networked embedded systems. In: Proceedings of the 7th International Conference on Advances in Mobile Computing & Multimedia, pp. 195–203. ACM, New York (2009) 10. Huygens, C., Hughes, D., Lagaisse, B., Joosen, W.: Streamlining development for networked embedded systems using multiple paradigms. IEEE Software (September 2010) 11. IWT-SBO-STADiUM project No. 80037. Software technology for adaptable distributed middleware, http://distrinet.cs.kuleuven.be/projects/stadium/ 12. IWT-SBO-SymbioNets project No. 090062. Symbiotic networks, http://symbionets.intec.ugent.be/

Policy-Driven Tailoring of Sensor Networks

35

13. Koshy, J., Wirjawan, I., Pandey, R., Ramin, Y.: Balancing computation and communication costs. The Case for Hybrid Execution in Sensor Networks 6(8), 1185– 1200 (2008) 14. Kuorilehto, M., H¨ annik¨ ainen, M., H¨ am¨ al¨ ainen, T.D.: A survey of application distribution in wireless sensor networks. EURASIP J. Wirel. Commun. Netw. 2005(5), 774–788 (2005) 15. Levis, P., Madden, S., Gay, D., Polastre, J., Szewczyk, R., Woo, A., Brewer, E.A., Culler, D.E.: The emergence of networking abstractions and techniques in tinyos. In: Proc. 1st Symposium on NSDI, pp. 1–14 (2004) 16. Mainwaring, A., Culler, D., Polastre, J., Szewczyk, R., Anderson, J.: Wireless sensor networks for habitat monitoring. In: Proceedings of the 1st ACM International Workshop on Wireless Sensor Networks and Applications, New York, USA, pp. 88–97 (2002) 17. Marsh, D., Baldwin, R., Mullins, B., Mills, R., Grimaila, M.: A security policy language for wireless sensor networks. Journal of Systems and Software 82(1), 101–111 (2009) 18. Mottola, L., Picco, G.: Programming wireless sensor networks: Fundamental concepts and state of the art. ACM Computing Surveys (2010) 19. Platon, E., Sei, Y.: Security software engineering in wireless sensor networks. Progress in Informatics 5(1), 1–19 (2008) 20. Porter, B., Coulson, G.: Lorien: a pure dynamic component-based operating system for wireless sensor networks. In: Proceedings of the 4th International Workshop on Middleware Tools, Services and Run-Time Support for Sensor Networks, pp. 7–12. ACM, New York (2009) 21. Steffan, J., Fiege, L., Cilia, M., Buchmann, A.: Towards multi-purpose wireless sensor networks. In: Proceedings of the International Conference on Systems Communications, Washington, DC, USA, pp. 336–341 (2005) 22. Sun Microsystems. Sun SPOT security library, https://spots-security.dev.java.net/ 23. Sun Microsystems. Sun SPOT world, http://www.sunspotworld.com/ 24. Wang, M., Cao, J., Li, J., Dasi, S.K.: Middleware for wireless sensor networks: A survey 23(3), 305–326 (2008) 25. Yu, Y., Rittle, L., Bhandari, V., LeBrun, J.: Supporting concurrent applications in wireless sensor networks. In: Proc. of the 4th International Conference on Embedded Networked Sensor Systems, pp. 139–152. ACM, New York (2006) 26. Zhu, Y., Keoh, S., Sloman, M., Lupu, E., Dulay, N., Pryce, N.: Finger: An Efficient Policy System for Body Sensor Networks. In: 5th IEEE International Conference on Mobile Ad-hoc and Sensor Systems (September 2008)

Integration of Terrain Image Sensing with UAV Safety Management Protocols Timothy Patterson, Sally McClean, Gerard Parr, Philip Morrow, Luke Teacy, and Jing Nie School of Computing and Information Engineering University of Ulster Cromore Road, Coleraine, BT52 1SA, Northern Ireland {patterson-t,si.mcclean,gp.parr,pj.morrow,l.teacy,j.nie}@ulster.ac.uk

Abstract. In recent years there has been increased interest in the development of lightweight rotor-based UAV platforms which may be deployed as single or multiple autonomous UAV systems in support of applications such as ground surveillance, search and rescue, environmental monitoring in remote areas, bridge inspection and aerial imaging of crops. With the increased complexity of the UAV platforms comes a legal requirement that any UAV operates in a safe manner and is able to land safely in the presence of control and power when flight task exception conditions are alarmed. No standards currently exist for the in-line discovery and designation of UAV Safe Landing Zones (SLZs) for rotor-based platforms and this paper describes a novel approach which has been developed as part of a wider UAV Safety Management Protocol. Aspects relating to the SLZ sensing, classification and designation are described together with the methodology for deciding on the SLZ attainability. Keywords: Quadrotor UAV, UAV safety management protocol, UAV safe landing zone detection.

1

Introduction

For many sensing applications such as monitoring atmospheric pollution or surveillance, Unmanned Aerial Vehicles (UAVs) provide a versatile and often inexpensive method of gathering data. UAVs offer many advantages over manned aircraft the most notable of which is the removal of humans from situations which may be deemed dull, dangerous or dirty. There are a wide range of commercially available UAVs which can be equipped with many types of sensors, for example infra red cameras for oil slick detection [1] or video cameras for traffic monitoring [2]. The Sensing Unmanned Autonomous Aerial Vehicles (SUAAVE) project [3] is concerned with the development of swarms of coordinating ’autonomous’ UAVs. The UAVs are autonomous in that low level flight controller commands are generated in response to high level goals, for example GPS waypoints. Currently Ascending Technologies Quadrotor Hummingbird UAVs [4] are used within the G. Parr and P. Morrow (Eds.): S-Cube 2010, LNICST 57, pp. 36–51, 2011. c Institute for Computer Sciences, Social Informatics and Telecommunications Engineering 2011 

Integration of Terrain Image Sensing

37

SUAAVE project. These UAVs have a flight time of approximately 23 minutes or 12 minutes with a 200g payload. They have four flexible rotors and can be equipped with a variety of sensors. The Hummingbird UAVs used within the project are currently equipped with a Point Gray Chameleon colour camera, GPS, Inertial Measurement Unit (IMU) and wireless communication capabilities. An initial application scenario for the SUAAVE project is that of mountain search and rescue. In this scenario swarms of collaborating UAVs offer many advantages over a single UAV working in isolation. These include: 1. Heterogeneous sensors - UAVs may be fitted with different types of sensors and their respective actions coordinated based on the data detected by other members of the swarm. For example, a UAV equipped with an IR camera flying at a relatively high altitude may be able to identify heat signatures on the ground. A UAV equipped with a colour camera could subsequently be dispatched to areas which have a high probability of containing the casualty given the observations by the IR camera [5]. 2. Efficient searching - One of the most important constraints in a search and rescue scenario is time. By utilizing swarms of coordinating UAVs an area can be searched relatively quickly and efficiently. 3. Robustness against mission failure - In the event of a UAV malfunction a mission can continue to be executed by other members of the swarm. There are many possible situations which may trigger a UAV malfunction. For the most serious of UAV malfunctions it is desirable to land the UAV as safely and quickly as possible. Such scenarios include prolonged loss of GPS signal, a sudden change in operating conditions resulting in insufficient battery life to navigate to the base station and a loss of communication capabilities. Presented in this position paper is the current state of work within the SUAAVE project related to the safe operation of the UAVs. A Safety Management Protocol (SMP) is outlined which incorporates a method of autonomously detecting safe landing areas from image sensor data. The remainder of the paper is structured as follows. In section 2 an overview of related work is presented. Section 3 describes the components of the SMP. An algorithm for the autonomous detection of safe landing sites is outlined in section 4. In section 5 the process of choosing a safe landing site from the available alternatives is discussed. Finally, conclusions and proposed future work are outlined in section 6.

2

Related Work

For the most serious scenarios it may be the safest course of action to instruct the UAV to land. These scenarios may be caused by a variety of reasons, for example prolonged loss of GPS signal due to the profile of the terrain [6] or a hardware error. The definition of a safe landing site varies depending on the UAV’s size and type, for example the Ascending Technologies Hummingbird UAV will require

38

T. Patterson et al.

a much smaller landing site than a MQ-9 Reaper UAV. However, it is proposed by [7] that a safe landing system should, minimize the expectation of human casualty, minimize external property damage, maximize the chance of aircraft survival and maximize the chance of payload survival. Under certain circumstances it may not be possible to satisfy all of these requirements, for example it may be safer to land the UAV in a lake as opposed to a school yard. One method of detecting safe landing areas is to create a 3D map of the surrounding terrain. In these approaches a user is required to provide the GPS coordinates of the suitable area. The UAV then navigates to this area and creates a 3D map of the terrain which enables suitable areas, for example flat, smooth surfaces to be identified. This 3D map can be created by a variety of approaches including stereo ranging [8], structure from motion [9] and laser scanning [10]. The work in [10] addresses the issue of the effect of obscurants on safe landing zone identification by utilizing a laser range finder to create a 3D reconstruction of the terrain. Accurate 3D terrain reconstruction is influenced by the position and pose estimation of the UAV at any given time. In this approach the pose measurements are fused with the laser scan using a probabilistic model of pose error and the likelihood of an accurate point in 3D space given 2 successive scans. However [10] found that in some cases the laser beam reflected off smoke resulting in an inaccurate reading of the terrain profile. Perhaps the main disadvantage of methods which attempt to reconstruct terrain is the required equipment. In [8] a stereo pair of cameras is required. Whilst this may be achieved using two low cost cameras whose pose and relative position is known it increases equipment payload and power consumption. Similarly, the use of a laser range finder as proposed by [10] would be impractical for a small quadrotor UAV. In the work by [11] the terrain is reconstructed using a single camera. However, in order to achieve this multiple passes of the same area is required. In the scenario of an emergency forced landing this may not be achievable due to limited battery life. A further disadvantage is the requirement of an accurate estimation of camera movement. For a UAV with constantly changing velocity this may be difficult. An improvement on these approaches in terms of required equipment is presented by [12]. In this work a user chooses a safe landing area via a series of navigation waypoints either from an aerial image or from the live UAV camera feed. The optical flow between two successive images is estimated using Scale Invariant Feature Transform (SIFT) features and used to estimate depth structure information. An assumption is made that areas with low variance between optical flow vectors indicate flat areas and are therefore deemed to be a safe landing site. A threshold for determining the boundaries between safe and unsafe is calculated during a supervised training phase. Each of the approaches discussed provide a degree of autonomy in that the UAV is able to detect landing sites and land without receiving low level commands from the operator. However many of the systems described require significant human input such as manually identifying suitable landing sites via a

Integration of Terrain Image Sensing

39

GUI. In the SUAAVE project were an operator is responsible for multiple UAVs it may not be feasible to choose a landing site whilst possibly ignoring the status of other UAVs in the swarm.

3

A Safety Management Protocol

Understandably safety is given utmost priority within the SUAAVE project. An implemented safety management protocol (SMP) defines a set of operational constraints on the UAV platform to help ensure that a mission is executed as safely as possible. In the event of the SMP issuing an abort command the UAV identifies the safest possible area to land in either from its current location, from a database of previously identified safe landing sites, or by contacting neighbouring UAVs. The safety management protocol is responsible for monitoring UAV location, health, connectivity and risks, for example from surrounding UAVs. 3.1

UAV Location

Flying a small autonomous quad-rotor UAV over heavily populated areas currently presents an unacceptable risk of causing damage to property or, in extreme cases human fatalities. Whilst the envisaged initial application for the SUAAVE project is mountain search and rescue it is desirable to include a mechanism whereby areas which are known to be unsuitable for flying over can be avoided. One such example is a school which may be in close proximity to the operational area. The location of unsuitable areas for flying through are indicated within the SMP by specifying the corner points of a bounding box via a series of GPS coordinates. When the application layer sends a GPS waypoint it is verified against the unsuitable areas specified in the SMP and unsafe requests subsequently denied. This provision reduces the probability of causing damage to property and people however increases the complexity of the path planning algorithms used. 3.2

UAV Health

The system health of the UAV can be influenced by many factors including operating and environmental conditions, for example decreased battery life due to wind or loss of GPS signal due to the profile of the terrain. In a related SUAAVE publication [3] it is proposed that the UAV periodically checks for and diagnoses errors. The UAV passes through several states including: 1. Pre-Flight Bootstrap - This phase of operation ensures that the necessary communication links, GPS, and on-board sensors are functional. The successful execution of this phase is a prerequisite to flight. 2. In-Flight Self Diagnostics - During a flight the UAV periodically executes this phase to detect and diagnose errors. 3. Operation - The operation phase is the most common state of the UAV during which the UAV executes its assigned mission.

40

T. Patterson et al.

4. Recover - In the event that an error is encountered the UAV will attempt to recover from that error, for example loss of a communication link may be resolved by relocating within range of another UAV or the base station. 5. Abort - Should the UAV encounter an irrecoverable error then the safest course of action may be to land as soon as possible. In the event of an abort command being issued by the SMP or the human operator the UAV will attempt to land as safely as possible. The relationship between each of these states is outlined in Figure 1.

Fig. 1. State transition diagram for the phases of operation

3.3

Maintaining Connectivity

An important constraint imposed by the SMP is that the potential for connectivity between a UAV and the base station is maintained at all times. This may be either via direct communication or a multi-hop link between neighbouring UAVs. From a safety prospective this constraint is significant as it helps ensure that there is a human-in-the-loop at all times who can abort a mission or command a single UAV to land. Balancing the limited flight time of the UAVs, the requirement of constant connectivity and the need to maximize information gain results in a project requirement of resource aware path planning algorithms. To achieve maximum information gain given the platform constraints the algorithm presented in [13] has been implemented and extended by incorporating two new features. Firstly, the algorithm is modified to account for the changing communication range of

Integration of Terrain Image Sensing

41

the UAVs in response to environmental and topographic conditions. Secondly, a multi-hop routing protocol has been incorporated. In the event of a loss of communication link the UAV will attempt to recover by relocating within range of other UAVs or the base station. Should this loss of communication link continue the SMP will switch to an abort state during which it will attempt to land the UAV as safely as possible. 3.4

Collision Avoidance

One potential hazard which is especially pertinent to UAVs operating as members of a swarm is that of mid-air collisions. Within the SUAAVE project an approach to multi-UAV collision detection using the IEEE 802.11 wireless networking protocol has been designed and implemented. In this work the received signal strength between UAVs is used to estimate their distance. The sampling rate is dynamically based on the speed of the UAV broadcasting the signal. The distance between two UAVs is estimated assuming ideal propagation conditions and that there is a clear line-of-sight path between the transmitter and the receiver. As the UAVs are operating as members of a swarm it is desirable that they are aware of the position of other UAVs which may only be accessible via a multi-hop connection. This knowledge enables UAVs to pre-emptively adjust their path to avoid breaching the safe operating distance threshold. One of the constraints placed upon the collision avoidance strategy is that it should not depend on GPS. In the absence of GPS the location of a UAV can be estimated from three nodes whose positions are known. Once this location is known the distance, D(i, j) between UAVi with coordinates (Xi , Yi , Zi ) and UAVj with coordinates (Xj , Yj , Zj ) is estimated using the Euclidean distance measure,  D(i, j) = (Xi − Xj )2 + (Yi − Yj )2 + (Zi − Zj )2 (1) This distance is stored in a dynamically updated table (Table 1) along with a unique UAV identifier, timestamp and coordinates. The table is updated with new information upon receiving a ”Coords” message from a neighbouring UAV. Table 1. Stored attributes of neighbouring UAVs UAV name Timestamp Coordinates Distance UAV1 T1 (X1 , Y1 , Z1 ) D1 ... ... ... ... UAVn Tn (Xn , Yn , Zn ) Dn

The safe operating distance threshold refers to the minimum allowable distance between UAVs and is dynamically changed based on the speed of the UAV and number of neighbours. A breach of this safe operating distance threshold between two UAVs may be the result of operating conditions, for example wind, or

42

T. Patterson et al.

a hardware error, for example GPS inaccuracies. Therefore, in this initial work and until robust see-and-avoid and sense-and-avoid technologies are available the UAV is issued with an abort command.

4

Detection of Landing Sites

In the event of receiving an abort command it is not sufficient to assume that the area directly beneath the UAV is suitable for landing. Furthermore it cannot be assumed that the UAV has the required resources to safely navigate to the base station. It is therefore desirable to provide a means of detecting a safe landing area which considers the surrounding terrain and the available resources of the UAV. This section and subsequent subsections discuss the detection of a landing site from a colour aerial image captured from the UAV. An overview of the processes used for the detection and storage of landing sites can be found in Fig. 2.

Sample image

No

Image useable

Yes

Identify potential landing sites

Determine attribute values for each potential landing site

Assign a safety classification to each potential landing site

Store landing site locations and relevant information

Fig. 2. Safe landing site detection overview

Sample Image and Test for Quality. The first stage in the safe landing site detection algorithm is to sample a frame from the live video stream. To avoid needlessly expending processing time by executing the algorithm on previously seen images this sampling rate is related to the altitude and velocity of the UAV. In this initial work an assumption is made that the UAV is travelling in a forward motion and is located at the centre of the image. Furthermore, the attitude of the UAV is not taken into account. The image sampling rate, S from the video stream is therefore, (2) S = (Iy /2 ∗ R)/V where Iy is the resolution of image I along the y axis, R is the ground pixel resolution and V is the velocity of the UAV estimated from GPS and IMU

Integration of Terrain Image Sensing

43

data. The ground pixel resolution, R, refers to the size of each pixel and can be calculated using [14], R = (AW ∗ H)/(F L ∗ Ix ) (3) where AW is the sensor array width in mm, H is the height above ground level, F L is the lens focal length in mm and Ix is the width of the image. Identify Potential Landing Sites. The sampled image is then analysed to identify regions which are of a suitable size and shape for landing. An edge detection operator is executed on the sampled image to identify object boundaries. In comparison to many image segmentation techniques edge detection in an unconstrained environment is relatively computationally inexpensive and provides reasonable results. However an assumption is made that object boundaries exhibit a steep change in intensity gradient. Currently a Canny edge detector [15] is used to identify object boundaries. This operator requires three parameters, σ which denotes the standard deviation of the Gaussian filter, a low threshold for high edge sensitivity and a high threshold for low edge sensitivity. These thresholds are currently determined empirically and are statically defined however, in future work it is planned that the parameters will be dynamically adjusted according to altitude. The resulting image is then dilated to increase the size of object boundaries and to close small gaps. The motivation behind this step is to provide a margin of error when performing the actual landing. Following edge detection and dilation areas which are of a suitable size for landing in are identified. The Ascending Technologies Hummingbird UAV is approximately 0.5m2 in size which, depending on the altitude of the UAV corresponds to varying numbers of pixels in the input image. The process of identifying potential landing sites can be represented by the following pseudo code: begin execute Canny edge detector on input image, i dilate detected edges by 1.5m for each group of pixels, p in input image, i analyse a rectangular area corresponding to 20m2 surrounding p if the area does not contain edges set p as a potential landing site end end for all potential landing sites, pi for all potential landing sites, pj if pi is adjacent to pj merge end end end assign a unique ID to each potential landing site end

44

T. Patterson et al.

Determine Attribute Values. The previous stages of edge detection, dilation and identification of areas of suitable size results in a set of potential landing sites. The suitability of these potential landing sites is determined by a number of factors including terrain classification and roughness. Currently a Maximum Likelihood Classifier (MLC) is used for the classification of terrain. This classifier requires training data from which class spectral signatures are estimated. The MLC estimates the probability of a pixel represented by a vector of spectral values, x belonging to class ωi and is given as [16], 1 (4) p(x|ωi ) = (2π)−1/2 |Σi |−1/2 exp{− (x − mi )t Σ−1 i (x − mi )}, 2 where mi is the mean spectral values and Σi is the covariance matrix for each class i. Intuitively different terrain types have varying degrees of suitability for landing in. Current classes used in mountainous terrain are grass, gorse, rock, trees and water. These classes are assigned a numeric suitability measure in the range [0..1] by a human expert familiar with the operational area. This suitability measure is used to determine a fuzzy classification of unsuitable, risky or suitable (Figure 3a). In aerial images of many rural scenarios man-made structures typically exhibit a high greyscale contrast deviation in comparison to the surrounding terrain. Landing a UAV near these structures presents a higher risk of damaging property and possibly harming people. Therefore the greyscale intensity deviation of each area surrounding a potential landing site is analysed and assigned a fuzzy classification of low, medium or high (Figure 3b). In the event of a fuzzy classification of high the potential landing site is discounted as unsafe. In future work it is planned that man-made structures will be more robustly detected by fusing map information with the aerial image sensor data. Potential landing sites which are exceptionally rough, for example areas which are very stony represent a risk to the safety of the UAV and its payload. As with man-made structures these areas typically exhibit relatively high greyscale intensity deviation and so this measure is used as an estimate of roughness. A fuzzy classification of smooth, rough and very rough is used to describe the roughness property (Figure 3c). The greyscale intensity deviation of a landing sites neighbourhood and the landing sites roughness is calculated using [17]:   2 I i,j i,j∈r i,j∈r (Im − Ii,j ) ,V = (5) Im = N ∗M N ∗M where Im is the average pixel intensity within the region, r is the region under consideration, i, j is the location of the pixel in the image, I is pixel intensity, N ∗ M is the size of region r and V is the standard deviation. Landing Site Safety Classification. The fuzzy input parameters of terrain suitability, neighbourhood deviation and roughness are aggregated using a series

Integration of Terrain Image Sensing

Unsuitable

1

Risky

Suitable

Smooth

1

Degree of membership

Rough

45

Very Rough

Degree of membership

0

0.1

0.5

0

1

Roughness b) The membership functions of input parameter landing site roughness

a) The membership functions of input parameter terrain suitability Low

1

Medium

30

15

Terrain suitability

High

1

Unsafe

Risky

Safe

Degree of membership

Degree of membership

0

15

30

Neighbourhood deviation c) The membership functions of input parameter neighbourhood deviation

0

0.1

0.5

1

Safety weighting d) The membership functions of output parameter safety weighting

Fig. 3. The membership functions of fuzzy logic parameters

of rules to produce a fuzzy output (Figure 3d), for example if terrain is suitable and neighbourhood deviation is low and roughness is smooth then landing site = safe. These rules are generated based on expert knowledge which is captured during a training phase prior to deployment. The centroid defuzzification method is used to provide a crisp numeric value for safety weighting. Storage of Previously Classified Landing Sites. It is desirable to store all previously seen landing sites for future use. Attributes of landing sites which are stored are outlined in Table 2. Table 2. Stored attributes of classified landing sites Attribute Description ID Primary key - Used to uniquely identify each landing site Time Each landing site is time-stamped Latitude/Longitude Used to estimate attainability Grid reference The corner coordinates in the image of the landing site Safety weighting The numeric safety weighting of each landing site

These attributes enable the UAV to locate a previously identified landing site in the event of receiving an abort command from the SMP in an area which is unsuitable for landing in. A time-stamp on each landing site may be used as an

46

T. Patterson et al.

indication of the safety classification accuracy which in a dynamic environment, for example farmland may change over time. The database is updated when a new landing site is identified. Many other processes such as path planning are executed in parallel with the safety module which results in processing and storage constraints. Under certain conditions it may therefore be feasible to only store landing sites with a safety weighting above a given threshold. During the course of a mission a large number of classified landing sites may be accumulated. The potential usefulness of these landing sites may decrease over time and with distance from the UAV’s location. To avoid sorting through a large number of unattainable landing sites in the event of an emergency the database is periodically pruned of such sites.

5

Choosing a Landing Site

In the event of the SMP issuing an abort command the UAV will consider the state of its resources and the suitability of surrounding and previously sensed terrain to choose a suitable landing site. An overview of the decisions taken by the UAV are outlined in Figure 4 and are discussed in the subsequent subsections.

Base station safely attainable

Abort command

Yes

Land at base station

Yes

Land at site with highest weighting

No Landing site available from current position No

Check database of previously classified landing sites

Previously classified landing sites

Choose landing site

Request aid from surrounding UAVs

Dynamically evaluate landing site

Fig. 4. Safe landing system overview

Land

Integration of Terrain Image Sensing

47

Attainability. A key attribute when choosing a landing site is its attainability which is determined by remaining battery life and distance from the UAV’s current position. The Ascending Technologies Hummingbird UAV used in the SUAAVE project has a battery life of approximately 23 minutes or 12 minutes with a 200g payload. However, this can be significantly influenced by environmental conditions such as wind. In the absence of models which characterize the effects of specific flight manoeuvres and environmental conditions upon the platforms battery, the travelled distance and current battery voltage may be used as an estimate of the required power per m of the UAV. Given an estimate of the required power per m of the UAV the potential attainability of a landing site can be determined by: R =C −D∗P

(6)

where R is the remaining battery life in volts (v) after navigating to the landing site, C is the current battery life in v, D is the distance of the landing site from the UAV’s position in m and P is the required battery power in v per m. The required power to navigate to a landing site is estimated as a percentage of remaining battery life. A landing site is considered unattainable if it requires more than 75% of the remaining battery life to navigate to that area. Therefore, in emergency situations the UAV reserves 25% of battery life to ensure that it has sufficient power to perform a controlled descent and, if possible transmit its location following an emergency landing. Part of the future work within the SUAAVE project will involve characterisation of the UAV platform. This will enable the impact of environmental conditions and specific flight manoeuvres upon battery life to be modelled. Furthermore, the power required by the UAV to perform a controlled descent and transmit its location can be estimated from these models enabling the attainability thresholds of a landing site to be more accurately defined. Neighbouring Landing Sites. It is possible that a landing site which appears suitable for landing in from a high altitude may, upon closer inspection contain hazards. Preference is therefore given to landing sites which have surrounding areas which are suitable for landing in. Therefore in the event of a chosen landing site containing hazards, alternative, attainable landing sites are available. 5.1

Base Station

In the first instance the UAV will assess if it has sufficient battery life to safely navigate to the base station. Landing at the base station enables easy recovery of the UAV which is an important advantage given that a single operator may be responsible for an entire swarm. 5.2

Current Location

In the event of the base station being unattainable the UAV will attempt to locate a landing site from its current location using aerial image data captured

48

T. Patterson et al.

from the onboard camera. The sequence of events executed in this scenario are similar to those outlined in Figure 2 however, as opposed to storing landing site locations a decision is made as to the most suitable landing site from the input image. The distance of landing sites detected from the UAV’s current location is estimated by calculating the Euclidean distance from the UAV’s current position to the centre of each landing site. This distance is used in conjunction with remaining battery life to estimate attainability. 5.3

Check Database

In the event of no suitable landing site being available from the current location the UAV will query the database of previously classified landing sites. This database contains the unique id, longitude/latitude position, safety classification and time stamp for each landing site. The distance, d from the UAV’s current position to the location of the landing site is calculated using the haversine formula [18], d = Rc (7) where R is the Earth’s radius in m and c is calculated as, Δlat = lat2 − lat1 , Δlong = long2 − long1 ,     Δlat Δlong a = sin2 + cos(lat1 )cos(lat2 ) sin2 , 2 2 √  c = 2atan2( a, (1 − a))

(8) (9) (10)

The fields in the database are subsequently sorted into ascending order by distance from the UAV’s current position and are compared against any landing sites which are detected by neighbouring UAVs. 5.4

Neighbouring UAVs

One of the requirements placed upon the UAVs by the SMP is that the potential for connectivity is maintained at all times. Therefore in the event of a member of the swarm performing a forced landing for reasons other than connectivity problems it is possible that a neighbouring UAV may be able to detect a landing site which has not been previously identified and stored by the UAV. If a neighbouring UAV can identify a safe landing site it will transmit the location of that site along with its associated safety weighting and number of neighbouring landing sites via 802.11. 5.5

Landing

The result of searching through the safe landing site database and requesting aid from surrounding UAVs is a list of attainable safe landing sites and their

Integration of Terrain Image Sensing

49

associated attributes. In this initial work the safe landing site with the greatest number of attainable, neighbouring safe landing sites is chosen. As the UAV descends it is possible that at lower altitudes a hazard may be identified in the landing site. Therefore, the chosen landing site is dynamically evaluated. In the event of the landing site containing hazards a neighbouring landing site is chosen. A constraint placed upon the UAVs by the SMP is that connectivity with the base station must be maintained. This connectivity can be either directly between the UAV and the base station or via neighbouring UAVs using a multihop routing protocol. In the event of a UAV performing an emergency landing the configuration of other swarm members will adapt to ensure that connectivity is maintained. A further constraint imposed by the SMP is with respect to the maximum allowable distance between swarm members. A possible scenario is where multiple UAVs attempt to land at the same landing site. It is therefore desirable that a UAV retains a portion of battery life to periodically transmit a ”Coords” message to other swarm members. This will be used in conjunction with the collision avoidance module of the SMP to help decrease the risk of multiple UAVs landing in close proximity to each other. In the example shown in Figure 5, 3 UAVs are dispatched to sense the environment in search for a missing person. Due to a GPS failure UAV1 navigates out of multi-hop communication range with the base station. As it cannot safely navigate to the base station without GPS UAV1 executes the safe landing

UAV 3 UAV 1 UAV UA AV 2

UAV

Communication Direction of travel range

Base station Link to base station

Grass

Water

Trees

Fig. 5. Example scenario where an emergency safe landing is required

50

T. Patterson et al.

site detection algorithm and determines that the ground directly beneath it is suitable for landing in. UAV1 subsequently lands and periodically transmits a ”Coords” message notifying other UAVs of its presence should they fly within communication range.

6

Conclusions/Future Work

In this position paper a safety management protocol which incorporates connectivity constraints, collision avoidance and safe landing site detection from aerial image data is presented. A novel algorithm is described for the detection, storage and subsequent choosing of safe landing sites. Preliminary results indicate potential in the approach used for the detection of landing sites. In future work it is planned to validate and improve all components of the SMP based on experiments conducted on a Hummingbird quadrotor UAV. A further piece of future work will be characterization of the platform in varying environmental conditions which will enable the attainability components of the algorithm to be defined more accurately. Acknowledgements. This research was supported by a Department for Employment and Learning studentship and through the Sensing Unmanned Autonomous Aerial Vehicles (SUAAVE) project under grants EP/F064217/1, EP/F064179/1 and EP/F06358X/1.

References 1. Binenko, V.I., Andreev, V.L., Ivanov, R.V.: Remote sensing of environment on the base of the micro-aviation. In: Remote Sensing of the Enviornment, St. Petersburg, Russia, pp. 10–15 (2005) 2. Srinivasan, S., Latchman, H., Shea, J., Wong, T., McNair, J.: Airborne traffic surveillance systems: video surveillance of highway traffic. In: Proceedings of the ACM 2nd International Workshop on Video Surveillance & Sensor Networks, pp. 131–135. ACM, New York (2004) 3. Cameron, S., Parr, G., Nardi, R., Hailes, S., Symington, A., Julier, S., Teacy, L., Mclean, S., Mcphillips, G., Waharte, S., Trigoni, N., Ahmed, M.: SUAAVE: Combining Aerial Robots and Wireless Networking. In: Unmanned Air Vehicle Systems, Bristol, vol. (01865), pp. 7–20 (2010) 4. Ascending Technologies. AscTec Hummingbird AutoPilot(accessed July 30, 2010) 5. Quaritsch, M., Kruggl, K., Wischounig, D., Bhattacharya, S., Shah, M., Rinner, B.: Networked UAVs as aerial sensor network for disaster management applications. E & I Elektrotechnik und Informationstechnik 127(3), 56–63 (2010) 6. Ochieng, W.Y., Sauer, K., Walsh, D., Brodin, G., Griffin, S., Denney, M.: GPS Integrity and Potential Impact on Aviation Safety. Journal of Navigation 56(1), 51–65 (2003) 7. Cox, T.H., Nagy, C.J., Skoog, M.A.: Civil UAV Capability Assessment (2004) 8. Theodore, C., Rowley, D., Ansar, A., Matthies, L., Goldberg, S., Hubbard, D., Whalley, M.: Flight trials of a rotorcraft unmanned aerial vehicle landing autonomously at unprepared sites. In: Annual Forum Proceedings-American Helicopter Society, Phoenix, AZ, vol. 62, pp. 67–73 (2006)

Integration of Terrain Image Sensing

51

9. Johnson, A., Montgomery, J., Matthies, L.: Vision guided landing of an autonomous helicopter in hazardous terrain. In: Proceedings of IEEE International Conference on Robotics and Automation, pp. 3966–3971 (2005) 10. Sevcik, K., Kuntz, N., Oh, P.: Exploring the Effect of Obscurants on Safe Landing Zone Identification. Journal of Intelligent and Robotic Systems 57(1-4), 281–295 (2009) 11. Templeton, T., Shim, D.H., Geyer, C., Sastry, S.: Autonomous vision-based landing and terrain mapping using an MPC-controlled unmanned rotorcraft. In: 2007 IEEE International Conference on Robotics and Automation, pp. 1349–1356 (2007) 12. Cesetti, A., Frontoni, E., Mancini, A., Zingaretti, P., Longhi, S.: A Vision-Based Guidance System for UAV Navigation and Safe Landing using Natural Landmarks. Journal of Intelligent and Robotic Systems 57(1-4), 233–257 (2009) 13. Stranders, R., Farinelli, A., Rogers, A., Jennings, N.J.: Decentralised control of continously valued control parameters using the max-sum algorithm. In: Proceedings of AAMAS 2009, pp. 601–608 (2009) 14. Booth, D., Cox, S., Berryman, R.: Precision measurements from very-large scale aerial digital imagery. In: Environmental Monitoring and Assessment, pp. 293–307 (2006) 15. Canny, J.: A Computational Approach To Edge Detection. IEEE Transactions Pattern Analysis and Machine Intelligence, 679–698 (1986) 16. Richards, J.A., Xiuping, J.: Remote Sensing Digital Image Analysis, 3rd edn. Springer, New York (1999) 17. Howard, A., Seraji, H.: Multi-Sensor Terrain Classification for Safe Spacecraft Landing. IEEE Transactions on Aerospace and Electronic Systems 40, 1122–1131 (2004) 18. Sinnott, R.W.: Virtues of the haversine. Sky Telescope 68 (1984)

A Study on the Wireless Onboard Monitoring System for Railroad Vehicle Axle Bearings Using the SAW Sensor Jaehoon Kim1, K.-S. Lee1, and J.-G. Oh2 1

Korea Railroad Research Institute, 360-1, Woram-dong , Uiwang- city, Gyeonggi-do, 437-757, Korea {lapin95,kslee}@krri.re.kr 2 Corechips, Shin-dong, Youngtong-gu, Suwon-city, Gyeonggi-do, 443-734, Korea [email protected]

Abstract. This study aimed to replace the current discontinuous rail monitoring system by applying “Plug and Play” technology to rail system monitoring to enable real-time monitoring, and by confirming on-condition maintenance efficiency and reliability. It examined a wireless sensor monitoring system which uses SAW (Surface Acoustic Wave) technology to monitor temperature changes in the axle box bearing of railroad vehicles during operation. The results of the experiment were compared with HDB measurements to confirm the reliability of the real-time monitoring results measured on vehicles during operation. Keywords: Monitoring, Wireless, Surface Acoustic Wave, Railroad.

1 Introduction In the railroad system measurement field, real-time measurements are an essential feature for the various sensors used for vehicle maintenance. These sensors are currently powered by batteries or through electric wires. However, such power supply methods can only be installed in certain locations and many improvements can be made in terms of long-term maintenance cost efficiency. This means that vehicle maintenance system developments require smaller sensors and technical improvements which enable “Plug and Play” so that sensors can be installed in any location. Axle box bearing heating and adhesion during vehicle operation damage the axle, causing derailments and other accidents. However, the current limitations in monitoring system installation locations and technology do not allow direct axle bearing temperature monitoring during vehicle operation. Instead, the temperature is monitored using wayside Hot Box Detectors (HBD) installed at fixed distances along the track. This is discontinuous monitoring, and there have been reported incidents in which vehicles that passed the HBD with no problems suddenly derailed due to axle box bearing damages [1, 2]. This study aimed to replace the current discontinuous rail monitoring system by applying “Plug and Play” technology to rail system monitoring to enable real-time G. Parr and P. Morrow (Eds.): S-Cube 2010, LNICST 57, pp. 52–58, 2011. © Institute for Computer Sciences, Social Informatics and Telecommunications Engineering 2011

A Study on the Wireless Onboard Monitoring System

53

monitoring, and by confirming on-condition maintenance efficiency and reliability. It examined a wireless sensor monitoring system which uses SAW (Surface Acoustic Wave) technology to monitor temperature changes in the axle box bearing of railroad vehicles during operation. The results of the experiment were compared with the existing HDB measurements to confirm the reliability of the real-time monitoring results measured on actual vehicles during operation [3-5].

2 SAW Sensor for Real-time Wireless Axle Box Bearing Temperature Monitoring For axle bearing boxes of vehicles that travel at high speeds, it is difficult to employ temperature sensors that use standard power supplies due to the influence of the surrounding environment, interference from high voltages and electronic parts and the unique location of the axle box bearing. Moreover, if the temperature sensor is employed in vehicles currently in commercial operation, the sensor and bearing structure need to be changed and this would incur significant replacement costs. Sensors such as the real-time wireless SAW temperature sensor, which do not require a power supply and can wirelessly monitor temperature immediately after semipermanent installation, fully overcome the limitations described above and do not require changes in the parts structure of commercial vehicles. They can be employed in both existing and newly-produced vehicles, giving them high research value. 2.1 SAW Sensor Design In general, SAW (Surface Acoustic Wave) sensors do not require any power supplies and can take measurements wirelessly. They are being studied intensively as a powerfree wireless sensor, and are expected to be of great use in areas such as axle box bearings where it is not easy to install and operate sensors that require a standard power supply. Researchers in Europe published a research paper on measuring braking disc temperature in high-speed railroad vehicles using SAW sensors [6].

Fig. 1. SAW Sensor Concept (ZL : Variable impedance temperature sensor)

This study looked at the SAW temperature sensor which allows temperature monitoring on the axle box bearing. As shown in Figure 1, the SAW temperature sensor in this study has a substrate surface that can transfer acoustic waves, which is where the input and output Interdigital Transducers are located. At the input IDT, electric signals applied to the comb finger electrodes are transformed into acoustic

54

J. Kim, K.-S. Lee, and J.-G. Oh

waves by the inverse piezoelectric effect. The waves are transferred along the substrate to arrive at the output IDT, and a voltage is created at the electrode by the piezoelectric effect. The signal produced at the output IDT reacts with the IDT finger and substrate material. Substrate characteristics are applied to the acoustic wave transfer process, and the waves are converted to electric signals after reacting with the substrate material at the output IDT. The characteristics that can be expected from the SAW temperature sensor in this study are firstly, a filter characteristic and secondly, a delay characteristic. In actual application, there are many products such as the VCO and Band Pass Filter in which communication systems composed of devices with filter characteristics play a key role. However, though devices with delay characteristics are being used as communication devices such as Delay Lines, the delay characteristic of SAW devices is a key feature of the power-free/wireless sensor to be developed through this study. In an actual device, the medium used on the substrate which transfers acoustic waves has a certain amount of thickness. Acoustic waves that are generated on the IDT on the substrate surface are not all transferred along the surface, but partially transferred as bulk waves. The amount of bulk waves depends on the substrate material and electrode design. If bulk waves transferred into the substrate reflects off the bottom surface of the substrate, they disrupt the surface acoustic waves and decrease the filter and delay characteristics of the SAW device. This means that it is extremely important in the development of powerfree/wireless SAW sensors and transponders to select appropriate IDT finger shape and substrate material. In this study, YZ-LiNb03, a popular SAW filter substrate material, was used to produce power-free/wireless SAW transponders and the IDT finger was designed to operate at a center frequency of 433MHz. A numerical analysis was carried out in order to confirm the transponder design for the SAW transponder design in Figure 2. The results showed a matching performance of near 50 ohms at a center frequency of 433MHz with Reflector Finger IDT (Inter Digital Transducers) of 24 pairs and a Finger IDT Overlap Length of 500 . A SAW Mask Pattern as shown in Figure 2 was designed and produced based on these results. The estimated performance based on the results was a one-way traveling wave insertion loss of around -9dB. When used as a SAW power-free/wireless transponder, the two-way loss, 2-step piezoelectric conversion and inverse piezoelectric conversion result in a -6dB loss. Therefore, the basic design policy was set to have a structure with a loss of around -24dB (-9dB-9dB-6dB).

㎛

λ

d

4

h

λ

4

Sensor IDT

(nλ)

Open Grating

Transceiver IDT

(mλ)

Fig. 2. SAW Model and Actual Production Sample Mask Pattern

A Study on the Wireless Onboard Monitoring System

55

The loss varies according to the SAW IDT number and the distance between the Sensor IDT and Transceiver IDT, and this was also analyzed. The analysis conditions and results are shown in Table 1. Note that the conditions and results apply when aluminum was (Al) is used as the metal layer, with the external impedance of the Sensor and Transceiver IDT matching at 50oe, a finger overlap (h) of 3mm), and an open grating distance (d) of 7mm. As Table 1 shows, insertion loss is low when the IDT number is 25 or fewer. Table 1. Insertion Loss by Sensor IDT and Transceiver IDT Number NSensor IDT

NTransceiver IDT

1 5 10 15 20 25 30 35 40 50

5 5 5 25 25 25 40 40 40 50

Insertion loss (dB) -25 -13 -11 -11 -11 -11 -15 -15 -18 -22

3dB BW (MHz) 60 40 30 20 14 14 14 12 12 10

Fig. 3. Power-free SAW Temperature Sensor Prototype Combined with a Thermistor (Resistive Temp. Sensor)

A validation test and vehicle application test were carried out in order to monitor axle box bearing temperature in real-time by producing an SAW Transponder with an excellent measuring distance and noise coherence at 1°C precision, and an SAW temperature sensor with a variable impedance structure, as shown in Figure 3. The variable impedance temperature sensor was developed into a form which combines the Thermistor (Resistive Temp. Sensor) , which is commonly used in measurements that require precision, with the SAW transponder as shown in Figure 3, and the characteristics of the Thermistor is as shown in the graph in Figure 4. For the validation test, the current

56

J. Kim, K.-S. Lee, and J.-G. Oh

study also measured changes in sensor value with temperature changes in the precision hot-plate. Changes in sensor temperature were measured on the hot-plate instead of the standard incubation chamber because for axle box bearings, the monitoring target of this study, the existing HBD monitoring device measures the axle box bearing surface temperature during operation. Surface temperature was measured using hot-plates instead of incubation chambers in order to create similar conditions. Tem perature vs. R esistance R esistance (Ω) 600 517

500 ) 400 (Ω e c n 300 at iss e R 200

344 234 162 115

100 0

40

60

80 Tem perature (℃)

83

61 100

45

34 120

Fig. 4. Changes in Thermistor Resistance by Temperature

2.2 System Application Test Using High-speed Railroad Vehicles An application test was carried out for axle box bearing temperature monitoring during vehicle operation using the SAW temperature sensor from the validation test described above. The aim of the application test was to replace the existing HBD (Hot Box Detector), which detects axle box bearing damages through a discontinuous temperature monitoring method, with a SAW temperature sensor to enable continuous temperature monitoring. It also compared SAW temperature sensor measurements with HBD temperature measurements to confirm the data, reliability, and validity of real-time monitoring.

Fig. 5. SAW Temperature Sensor and Antenna Installation for Axle Box Bearing Temperature Measurement

A Study on the Wireless Onboard Monitoring System

57

As shown in Figure 5, a SAW temperature sensor was installed on the axle box bearing of a vehicle that travels at 300km/h to wirelessly monitor temperature changes in real-time. To minimize errors due to installation location, the sensor was placed at a location closest to where the wayside HBD makes contactless temperature measurements on the axle box bearing surface.

50

40

o

Temperature [C ]

SAW Sensor HBD

30

20

10

07:00:00

08:00:00

09:00:00

10:00:00

11:00:00

Time

Fig. 6. SAW Sensor Temperature Results vs HBD Temperature Results (HBD installed in 7 locations along the route)

Figure 6 shows that during the two-way operation of the vehicle at the maximum speed of 300km/h, the SAW temperature sensor measurements were similar to the HBD measurements. For the entire period, both the SAW temperature sensor measurements and HBD measurements show fluctuations in axle box bearing temperature according to operation conditions such as stopping at stations or passing through tunnels, and both show an overall increase in temperature with operation time. Furthermore, the SAW temperature sensor and HBD temperature measurements differed only by 0.02 ~4.02 for each section. This confirmed the reliability of the SAW temperature sensor developed for r real-time wireless monitoring of axle box bearings on railroad vehicles. The real-time monitoring validity was compared with the HBD. The HBD is only installed in 7 locations on each of the upward and downward routes. This does not allow continuous monitoring as the axle box bearing temperature is measured only when the vehicle passes these locations, and errors may occur in data analysis. In particular, it is difficult to determine whether sudden temperature changes in vehicles operating at 300km/h indicate problems in the axle box bearing with only HBD measurements. For example, in Figure 6, there is a sudden change in HBD data between 10:15 and 10:30. In order to determine whether this indicates a problem in the axle box bearing, another HBD measurement must be taken after 15 minutes. 15 minutes is a long period of time for a high-speed vehicle and if the axle box bearing has in fact been damaged, there may be an accident before the problem can even be checked. However, for real-time SAW sensor measurements, increases and decreases in axle box bearing temperature can be analyzed continuously, allowing quick and

℃

℃

58

J. Kim, K.-S. Lee, and J.-G. Oh

accurate damage detection. The SAW temperature sensor measurements in Figure 6, unlike the HBD measurements, show continuous changes in axle box bearing temperature between 10:15t and 10:30 to allow accurate monitoring of the axle box bearing. This study confirmed the reliability of the real-time wireless SAW temperature sensor, and demonstrated that the temperature sensor can be made useful in vehicle integrity assessment and maintenance by using it to monitor axle box bearings and take continuous temperature measurements.

References 1. Rail Safety Investigation Report- Derailment of Pacific National Freight Services CB76 and 1WB3. Office of Transport Safety Investigations, Sydney, Australia (2007) 2. Rail Safety Investigation into the Derailment of Train 6WP2. Australian Transport Safety Bureau (2003) 3. Sodano, H.A., Inman, D.J., Park, G.: Comparison of piezoelectric energy harvesting devices for recharging batteries. Journal of Intelligent Material Systems and Structures 16, 799–807 (2005) 4. Horowitz, S., Kasyap, K.A., Liu, F., Johnson, D., Nishida, T., Ngo, K., Sheplak, M., Cattafesta, L.: Technology Development for Self-Powered Sensors. In: Proc. of 1st Flow Control Conference, AIAA-2022-2702 (2002) 5. Roundy, S.: On the Effectiveness of Vibration-based Energy Harvesting. Journal of Intelligent Material Systems and Structures 16, 809–824 (2005) 6. Pohl, A., Seifert, F.: Wirelessly interrogable surface acoustic wave sensors for vehicular applications. IEEE Transactions on Instrumentation and Measurement 46, 1031–1038 (1997)

Middleware for Adaptive Group Communication in Wireless Sensor Networks Klaas Thoelen, Sam Michiels, and Wouter Joosen IBBT - DistriNet, Katholieke Universiteit Leuven 3001 Leuven, Belgium [email protected]

Abstract. While the size and heterogeneity of wireless sensor networks confirm the need and benefit of group communication, an intelligent approach that exploits the interaction pattern and network context is still missing. This paper introduces sensor middleware to dynamically select the most efficient alternative from a set of group communication mechanisms. The proposed solution leverages on an empirical analysis of the ODMRP multicast protocol and was evaluated by a proof-of-concept prototype running on the SunSPOT platform. Results show that network overhead is considerably reduced when using the sensor middleware for software deployment, reconfiguration and periodic data monitoring. Keywords: Group Communication, Context-Awareness, Middleware, Wireless Sensor Networks, Multicast.

1

Introduction

As wireless sensor network (WSN) platforms mature and standardization in their networking stack advances, WSN deployments become larger and more heterogeneous. This heterogeneity is exposed by differences in hardware, software and even ownership of the individual sensor nodes. As a result, sensor nodes emerge with different responsibilities (provided services, quality levels), capabilities (processing power, sensor accuracy) and general properties (ownership, types of sensors, energy source). Paradoxically, this heterogeneity also leads to the opportunity of defining groups of sensor nodes with common characteristics. Group communication support is needed so that a subset of nodes adhering to a certain commonality can easily be contacted. In the scope of large scale, long lived and dynamic WSN environments, we identify three interaction patterns that benefit from group communication [9,13]: (1) software deployment, (2) dynamic configuration and (3) periodic actuation and monitoring. Evolving requirements on deployed services and the network as a whole trigger both software deployment and configuration. The difference lies however in the frequencies of these interactions and the amount of data to be exchanged. (1) Software deployment involves the dissemination of relatively large chunks of data and should be kept to a minimum to extend the battery lifetime of the sensor nodes. (2) Reconfigurations can be performed more frequently than deployment, given that the G. Parr and P. Morrow (Eds.): S-Cube 2010, LNICST 57, pp. 59–74, 2011. c Institute for Computer Sciences, Social Informatics and Telecommunications Engineering 2011 

60

K. Thoelen, S. Michiels, and W. Joosen

network overhead is considerably smaller. (3) The exchange of monitoring and actuation data is highly frequent and often periodic in nature; in addition, the frequency of this periodic interaction is not static but susceptible to (changing) application preferences. The size of the data that is exchanged for monitoring however, is typically small in comparison with software deployment. These differences in interaction pattern characteristics influence the applicability of the various group communication mechanisms at hand. In traditional networking, group communication is provided by multicast protocols that represent a group of nodes by a single address. The member nodes are not always bound by geographical properties and can be scattered throughout the network. The primary goal of multicast protocols is to deliver the intended packets to all members of the group with the least possible amount of transmissions per packet. This is typically achieved by the usage of an overlay tree or mesh in which all sources, members and needed intermediary nodes are connected. Creating these overlays, typically involves broadcasting the network in search of members and subsequent replies to the initiator of this so-called discovery phase. This exchange of control packets is commonly called protocol overhead, as it does not take part in delivering the actual data to the group members. In the face of mobility, changing connectivity and changing group memberships, these discovery phases need to be repeated at an appropriate frequency to keep the overlay up-to-date. The problem that we address in this paper is that the protocol overhead introduced by multicast protocols is not always justifiable. Alternatives like broadcast and gossip mechanisms, introduce no or less protocol overhead [2,4] and although not group-aware, can be more efficient than multicast protocols. We argue that both the characteristics of the current interaction pattern and the network context need to be taken into account when performing group communication. Only in this way can we ensure that the most efficient communication mechanism is used. The contributions of this paper are (1) the design of a context aware middleware layer that allows the selection of the most efficient mechanism at hand to perform group communication; to enable this, we performed (2) an efficiency analysis of a representative multicast protocol with regards to protocol overhead; (3) the evaluation of our prototype on the SunSPOT platform confirms the efficiency benefits of the proposed solution. The remainder of this paper is structured as follows. In Section 2 we report on our efficiency analysis of the ODMRP multicast protocol and discuss the main results. We introduce our Communication Management Middleware in Section 3. We evaluate our prototype in Section 4 and elaborate on related work in Section 5. We conclude in Section 6.

2

Multicast Efficiency Analysis

With respect to the interaction patterns identified in the introduction, we compare a multicast and broadcast approach in terms of the amount of transmissions

Middleware for Adaptive Group Communication in WSNs

61

needed to deliver data to all group members. This, of course, is dependent on the selected multicast protocol and how its overlay is created. In the following subsection we first discuss why we selected the ODMRP protocol and how it operates. We continue with a report on an efficiency analysis of ODMRP and conclude with defining a set of rules to follow in order to achieve efficient group communication. 2.1

Multicast Protocol Selection

We selected the On-Demand Multicast Routing Protocol (ODMRP) [14] because it is on-demand and source-initiated. Only when a source has a need to send data to a group, a multicast overlay is created, hereby reducing the protocol overhead to truly useful situations. This suits the identified interaction patterns as both deployment and reconfiguration require only short-lived overlays to fulfill their duties. Furthermore, periodic data publication only requires a constantly active overlay when the periodicity is high enough. ODMRP is a mesh-based multicast protocol that uses the concept of a forwarding group in which only a subset of nodes forward data packets to the group members. The mesh overlay is created during a so-called discovery phase which involves broadcasting a Join Query packet to find all possible members of the group. At the reception of a Join Query, members of the group create a Join Reply and unicast it back to the source. Intermediate nodes receiving the Join Reply realize that they are on a path between the source and at least one member of the group and set a forwarding group flag before forwarding the Join Reply. In this way, a mesh of forwarding nodes is created that establishes routes between the source and the group members. Multicast data, transmitted by the source, is only retransmitted by nodes which have the forwarding flag set. Periodically, but only while the overlay is in effective use, discovery phases are repeated to refresh the mesh overlay. This period is defined as the discovery phase interval. The mesh overlay is maintained only in soft-state and fades away when no longer in use. No explicit control packets are thus required to leave the group. Implementations. We implemented ODMRP on the SunSPOT [11] platform, the stable RED version of 090706. The SunSPOT version consumes 920 bytes or 0,17% of the total available RAM on a SunSPOT, compared to the 1040 bytes consumed by the built-in LQRP (Link Quality Routing Protocol) unicast routing protocol which is a derivative of AODV (Ad hoc On-demand Distance Vector) [7]. To be able to test the performance of our implementation in larger networks, we ported this implementation to a Cooja [6] compatible version. Cooja is a simulator primarily created to simulate sensor nodes running the Contiki operating system [1]. However, since it is developed using Java, it allows to simulate networks of Java-based application level sensor nodes. 2.2

Tests and Simulations

Driven by the interaction patterns introduced in Section 1, the variables in scope are the amount of data to exchange and the frequency of interactions with a

62

K. Thoelen, S. Michiels, and W. Joosen

1

2

4

5

7

8



  













3

6









(a)



















 


9

 


 


(b)

Fig. 1. The 3x3 grid topology with an indication of the radio range around node 5 (a), and the accompanying graph of the number of transmissions needed to deliver a certain amount of data packets to the specified group (b)

multicast group. We define efficiency as the cumulative number of transmissions of all nodes in the network to deliver a certain amount of data packets to a group of nodes. This includes the transmissions of control as well as data packets. We compare the efficiency of the following cases: the SunSPOT implementation of ODMRP, the Cooja port of ODMRP, the theoretical optimum of ODMRP and a simple broadcast mechanism. In our experiments, the discovery phase interval of ODMRP was kept constant at 30 seconds and the forwarding group refresh interval at 60 seconds. We consider node mobility as future work. The theoretical optimum of ODMRP is the case in which ODMRP uses the minimum amount of protocol overhead to select the minimum number of forwarders. This case was used as a point of reference for the SunSPOT and Cooja implementations. In case of the simple broadcasting mechanism, we calculated the number of transmissions executed when every node retransmits every packet it receives once. The number of transmissions per packet is thus equal to the number of nodes in the network. The SunSPOT network under test was a 3x3-grid (see Figure 1(a)). Node 1 was used as the source of multicast data, with nodes 3, 7 and 9 being members. In Cooja, we repeated the tests on a 3x3 grid with the same topology and radio range. As can be seen in Figure 1(b), the difference in efficiency was small and can be attributed to the difference in MAC and PHY layers used in both cases. This causes both setups to slightly favor different overlay meshes as members reply to the first JoinQuery they receive. The difference in comparison to the theoretical case can be attributed to the fact that in this case the most ideal mesh overlay is created with the least amount of forwarders. This is not always the case in the SunSPOT and Cooja versions.

Middleware for Adaptive Group Communication in WSNs

63

1

11

21

31

41

51

61

71

81

91

1

11

21

31

41

51

61

71

81

91

1

11

21

31

41

51

61

71

81

91

2

12

22

32

42

52

62

72

82

92

2

12

22

32

42

52

62

72

82

92

2

12

22

32

42

52

62

72

82

92

3

13

23

33

43

53

63

73

83

93

3

13

23

33

43

53

63

73

83

93

3

13

23

33

43

53

63

73

83

93

4

14

24

34

44

54

64

74

84

94

4

14

24

34

44

54

64

74

84

94

4

14

24

34

44

54

64

74

84

94

5

15

25

35

45

55

65

75

85

95

5

15

25

35

45

55

65

75

85

95

5

15

25

35

45

55

65

75

85

95

6

16

26

36

46

56

66

76

86

96

6

16

26

36

46

56

66

76

86

96

6

16

26

36

46

56

66

76

86

96

7

17

27

37

47

57

67

77

87

97

7

17

27

37

47

57

67

77

87

97

7

17

27

37

47

57

67

77

87

97

8

18

28

38

48

58

68

78

88

98

8

18

28

38

48

58

68

78

88

98

8

18

28

38

48

58

68

78

88

98

9

19

29

39

49

59

69

79

89

99

9

19

29

39

49

59

69

79

89

99

9

19

29

39

49

59

69

79

89

99

10

20

30

40

50

60

70

80

90

100

10

20

30

40

50

60

70

80

90

100

10

20

30

40

50

60

70

80

90

100

(a)

(b)

(c)

Fig. 2. Topologies of the 10x10 grid networks. The different sets of members (shaded circles) were chosen to represent a very dispersed group (a), a very condensed group (b) and an evenly spread out group (c). In (a), also the radio ranges are shown which were used during subsequent simulations.

Additional simulations were performed on a 5x5 grid and a 10x10 grid. In the first case we used the same radio range and the same network configuration as previous (one corner node as a source and all other corner nodes as members of the group). The 10x10 grid was however used to perform more extensive simulations with various network configurations. Figure 2 shows the radio ranges and sets of group members used. Node 1 was again used as the source of multicast data and the different sets of members were chosen to represent (a) a very dispersed group, (b) a very condensed group and (c) a evenly spread out group. To indicate that our ODMRP implementation is satisfactory and that the measured transmissions effectively deliver the data packets to the group members, we include Table 1. This table shows the delivery ratio, or the average ratio of the number of data packets effectively received by the group members to the number of data packets sent by the source. The theoretical multicast and broadcast cases obviously hold a perfect delivery ratio of 1, but the experimental SunSPOT and Cooja cases come very close. 2.3

Multicast vs. Broadcast: Protocol Overhead

In this subsection we evaluate how the two alternatives of multicasting and broadcasting relate to each other in terms of protocol overhead. Table 1. Delivery ratios of the tests and simulations Network

Implementation

Delivery Ratio

3x3 3x3 5x5 10x10

SunSPOT Cooja Cooja Cooja

0,976 0,994 0,999 0,980

64

K. Thoelen, S. Michiels, and W. Joosen

Figure 3(a) and Figure 3(b) show the measured (or required) number of transmissions per number of data packets sent out by the source, respectively with and without the broadcast results. These specific figures are the average results from measurements in the 10x10 grid network, with medium radio range and evenly spread group members. All other cases resulted in similar graphs however. The simple, yet wasteful, broadcast mechanism has no protocol overhead. Every data packet transmitted by the source is retransmitted exactly once by every node when it is received. This is represented by the linear function nx in which n is equal to the number of nodes in the network and x to the amount of data packets transmitted by the source. In the multicast case, the protocol overhead introduces a variable factor. A discovery phase is executed before the first data packet is transmitted and periodically repeated. Such a discovery phase requires an amount of transmissions equal to O. O = JQN + JRN + AckN

(1)

JQN , JRN , AckN are respectively defined as the total amount of Join Queries, Join Replies and Acknowledgements transmitted by all nodes in the network. JQN is equal to n or the number of nodes in the network. JRN and AckN are however dependent on the actual overlay mesh that is created at execution time. They are both functions of the size of the network, the position and the amount of members, the selected forwarders and the radio range of the nodes. The total amount of transmissions in the multicast case, during a single discovery interval, can be represented by the function O + kx, in which k is equal to the number of nodes which are selected as a forwarder. We can compare both functions with the graphs in Figure 3(a). As the number of forwarders in the multicast case is typically much smaller than the total amount of nodes and thus k < n, we see that the slope of the multicast graph is









  




  











































 


  


(a)

























 





 
 


  




     


(b)

Fig. 3. The amount of transmissions needed per number of data packets sent out by the source, with (a) and without (b) the broadcast results for the 10x10 grid network, with medium radio range and evenly spread group members

Middleware for Adaptive Group Communication in WSNs

65

a lot less steep than the broadcast graph. A second discovery phase, performed between 250 and 500 data packets causes the multicast graphs to bend a little. In the theoretical case, the optimal set of forwarders is reselected and thus the graph only bends lightly because of the additional protocol overhead. In the practical case however, the selection of a different set of forwarders causes a greater bend in the graph. Subsequent discovery phases influence the slope to a lesser extent since after two discovery phase intervals forwarders are deactivated. From Figure 3(a), we can conclude that in general multicast requires far less transmissions than broadcast, especially when the amount of data to disseminate is large. For a small amount of data packets however, the benefit of multicast is not that clear. Two of the three interaction patterns we identified involve the dissemination of small amounts of data. In the following subsection we therefore investigate the influence of protocol overhead on the amount of transmissions needed to disseminate an increasing number of data packets. 2.4

The Efficiency Threshold

   


 



In this section, we empirically determine the amount of data packets that need to be disseminated by the source in order to compensate multicast protocol overhead. This is defined as the efficiency threshold and visualized in Figure 4. The horizontal axis shows the amount of data packets disseminated by the source. On the vertical axis, we depict the total amount of transmissions (control and data packets) in percentages of the broadcast constant. To compensate for the various network sizes, we normalize the broadcast constant to 100 %. Only a single discovery phase is executed in the experiments. This happens before the first data packet is transmitted, but the respective protocol overhead is divided over the amount of data packets disseminated by the source. For a single data packet, the total amount of transmissions is thus the sum of all protocol overhead transmissions and the data packet transmissions. For a larger number







  





 
 





 
 
 
 




























 


Fig. 4. The normalized amount of transmissions needed per data packet, for an increasing number of data packets sent by the source

66

K. Thoelen, S. Michiels, and W. Joosen Table 2. The average efficiency threshold for the various grids under test. Network

Threshold (in number of data packets)

3x3 5x5 10x10

7 5 2

of data packets, the protocol overhead transmissions are divided over all the data packets, hereby reducing their impact. In Figure 4, the curves represent the average of all our tests and simulations on the various grids (see section 2.2). We see that for a few packets, the multicast protocol overhead is not justifiable and broadcast is the better option. The multicast curves however quickly drop below the broadcast constant and level of to the average amount of forwarders selected by the protocol in each of the three grids. The amount of data packets on the horizontal axis that corresponds with the intersection of the multicast curve with the broadcast constant, is the efficiency threshold (see Table 2). The variation is explained in the following subsection. 2.5

Network Influences on the Efficiency Threshold

In this subsection we look at how various network parameters influence the efficiency threshold and explain its variation between the various grids. The discovery phase interval and periodic data interval have no influence on the efficiency threshold. Any change in one of them, doesn’t affect the amount of data packets required to justify the multicast protocol overhead. For a fixed group of members, the radio range also has no practical influence. It affects the number of forwarders selected and thus the overall total of transmissions, but in most practical cases, this results in only a few more transmissions per data packet. Due to the steep decline of the curves in Figure 4, this practically has no influence on the efficiency threshold. The member distribution and member ratio (the percentage of members in the network) in general also do not influence the efficiency threshold. The contribution of the broadcasting of Join Queries is too large for the variation in members and forwarders to have a clear impact on the total amount of transmissions. The amount of transmissions per data packet does change lightly in most cases, but not enough to influence the efficiency threshold. The 3x3 and 5x5 grids however, expose extreme cases which do clearly affect the efficiency threshold. The small size of the grid, inherently causes the member ratio to be higher. In combination with the small radio range used, this causes nearly all nodes to be either a member or a forwarder. This drastically augments the amount of transmissions during both the discovery phase and the data dissemination afterwards. As a result, the efficiency threshold increases. In larger grids, this effect is also present, but only appears in extreme situations with a

Middleware for Adaptive Group Communication in WSNs

67

very low radio range, combined with a very high member ratio. The efficiency thresholds in Table 2, were empirically determined and do not take into account such extreme situations. 2.6

Lessons Learned

With respect to the results described in the previous subsection, we deduce a number of rules which guide us towards efficient use of multicast. For this purpose, we define the following variables: d = discovery phase interval e = the efficiency threshold p = periodic data interval Using these variables, we can describe the following rules: 1. For a number of data packets below the threshold e, the protocol overhead is inefficient. In this case simply broadcasting is more efficient. 2. For a number of data packets above the threshold e, during a single discovery interval, the multicast protocol overhead is justifiable and multicast becomes the most efficient alternative. 3. For periodic transmissions to a multicast group, we can select a threshold for p below which multicast is the most efficient communication mechanism. In the other case, broadcast is the more efficient alternative. p has to obey to the following equation: d p< (2) e

3

Communication Management Middleware

In this section we introduce our Communication Management Middleware (CMM) which leverages on the conclusions presented in the previous section. It efficiently delivers application data to a specified destination taking into account the interaction pattern and network context. The CMM is situated above a traditional networking layer and below any application functionality (see Figure 5). The networking layer provides an extensible set of communication mechanisms like unicast, broadcast and multicast. The need for a middleware layer arises from the fact that neither the applications, nor the multicast protocols should be held responsible for the selection of the most efficient communication mechanism. Applications might target their data to a group of interested nodes, but should not be concerned about how the data is delivered to this group. Additionally, multicast protocols allow for dissemination of data to a group of nodes but are not, and shouldn’t be, concerned about whether they are to be used or not. We continue this section with an overview of the key CMM building blocks and a discussion on the adaptations required at the networking layer.

68

K. Thoelen, S. Michiels, and W. Joosen

Network Manager Application

Application

Management Interface

Data Interface

Communication Management Middleware Network Monitor

Context

Decision Tree

Packetizer Network Layer Multicast

...

Broadcast

...

Unicast

Dispatcher

... Radio

Fig. 5. Architectural representation of the Communication Management middleware in the network stack. The white blocks depict the contributions of this paper.

3.1

Component View

The Communication Management Middleware consists of a Data and Management Interface, a Network Monitor, a Context representation and a Decision Tree. The Data Interface (see Table 3) is used by applications to pass data and the recipient’s address to the middleware. The address can either be a unicast, broadcast or multicast address; further delivery of data is taken care of by the CMM. Through the same interface, applications can also notify the middleware of periodic transmissions by registering themselves together with the multicast address concerned and the sending interval time value. The Management Interface and Network Monitor are both used to update the context representation. The latter contains a small database with tuples for various network parameters like the network size, the group size and the radio range. These parameters are used to determine the efficiency threshold and can be manually updated by a network manager through the Management Interface (see Table 4). The context representation is also interfaced with the various communication mechanisms in the network layer to query on their state or update various settings. With regard to the multicast mechanism, for instance, it can check for active multicast overlays or update the discovery phase interval. Table 3. The Data Interface void send(NetworkAddress address, byte[] data) void registerPeriodicSender(NetworkAddress address, int interval, int ApplicationID) void unregisterPeriodicSender(NetworkAddress address, int ApplicationID)

Middleware for Adaptive Group Communication in WSNs

69

Table 4. The Management Interface void setNetworkSize(int size) int getNetworkSize() void setGroupSize(NetworkAddress address, int size) int getGroupSize(NetworkAddress address) void setRadioRange(int range) int getRadioRange() void setEfficiencyThreshold(int value) int getEfficiencyThreshold()

We conceptually include the Network Monitor, which provides a future automated alternative to the Management Interface. This alleviates the burden of manually updating the context representation from the network manager. Further research is however required on how the network parameters can be extracted from the network in an automated manner. We do foresee however that the Network Monitor will not be installed in the same form on all nodes of the network. A full-fledged Network Monitor will operate at the more powerful nodes like for instance gateways, while light-weight monitors or proxies will be deployed on the more resource constrained nodes. The logic of the CMM is defined in the Decision Tree. The current interaction pattern at use is reflected by the data received via the Data Interface. In combination with the information retrievable in the context database, the Decision Tree evaluates which communication component at the network layer will deliver the data in the most efficient manner. A detailed representation of the Decision Tree is presented in Figure 6. Depending on the destination address specified, the broadcast or unicast mechanisms of the network layer are activated, in which case the middleware layer simply passes the data and destination address to the network layer. The real logic comes into play when the destination address is a multicast address. In this case, first the size of the message is compared against the product of the efficiency threshold e and the available payload size of the network packets. The

yes

Broadcast

Broadcast address?

yes no

Multicast address? no

yes

Fragment and Multicast

no

Overlay active?

message > payload size * eff. thresh.

Unicast

yes

no

Multicast yes

Multicast

no

Broadcast

High periodicity?

Fig. 6. The Communication Management Middleware decision tree

70

K. Thoelen, S. Michiels, and W. Joosen

latter product indicates the amount of data required to result in enough data packets to be transmitted to justify the protocol overhead of a discovery phase. If the message is large enough, a discovery phase is executed if no multicast overlay is active and the message gets fragmented and transmitted via the multicast mechanism. In case the message is smaller than the mentioned product, we check whether an overlay is active, in which case we multicast anyway. Be it that no multicast overlay is active, we further check if the multicast group is registered as a group towards which periodic communication is targeted with a high enough periodicity. If this is the case, we multicast as well, if not we broadcast the message over the network and let the recipients detect whether they should process the message or not. 3.2

Network Layer Adaptations

The network layer provides an extensible set of communication mechanisms. Besides the unicast, broadcast and multicast mechanisms depicted in Figure 5, other mechanisms can be provided such as gossip protocols and anycast mechanisms. To allow multicast data to be broadcasted, the broadcast mechanism has to be adapted to reflect the multicast membership of nodes. The Packetizer component adds a small header to all broadcast traffic. This header consists of a multicast-flag and an optional multicast address. If the broadcast data to be sent, is targeted to a multicast group, the multicast-flag is set to 1 and the multicast address is added to the header. In case of a normal broadcast, the multicast-flag is set to 0 and no multicast address is added. At the receiving end, the Dispatcher component checks the destination address of all incoming packets. Packets destined to the node’s unicast address or one of its multicast addresses are dispatched to the upper layer applications for further processing. In case a broadcast packet is received, its multicast-flag is inspected. If this is not set, the packet is dispatched to the upper layers as a normal broadcast packet. If the multicast-flag is set however, the packet is only dispatched to the upper layers if the node itself is a member of the specified multicast group. The multicast-flag thus allows receiving nodes to refrain from processing a broadcast packet when it is intended for a multicast group they are not a member of. The Dispatcher furthermore appropriately makes use of Unicast, Broadcast and Multicast mechanism for packet forwarding to the (other) destination(s).

4

Prototype Evaluation

We implemented a prototype version of the Communication Management Middleware on the SunSPOT platform (version Red-090706) and ported it to the Cooja simulator. The SunSPOT prototype consumes 124 bytes of RAM and 2997 bytes of flash memory on a SunSPOT. This is respectively 0,02% of the 512 kbytes available RAM and 0,07% of the 4 MB available flash memory on a SunSPOT. We consider

Middleware for Adaptive Group Communication in WSNs

71

!




  


 

 



   



   



 

   







Fig. 7. The number of transmissions needed to perform the actions of the described use case

this very low with regards to the efficiency advantage that is added. Furthermore it indicates the applicability of our approach on more constrained sensor devices. The following use case is used as a practical evaluation. In the 10x10 grid as depicted in Figure 2(a) node 1 is used as a management gateway to the WSN, through which deployments and reconfigurations are performed. The small radio range as depicted in the same figure is used and the discovery phase interval is set to 30 seconds. We performed the following set of actions using the Cooja prototype. 1. Deploy a temperature monitoring service to the group of opposite corner nodes 10, 91 and 100. The size of the component is 4KB which is fragmented over 50 packets. 2. During a 200 second period, the temperature monitoring services publish temperature readings to a group consisting of nodes 5 and 51. The temperature readings are published with a periodic time interval of 10 seconds and small enough to fit in a single packet. 3. A reconfiguration is executed which changes the periodic interval of the publication of temperature readings from 10 seconds to 30 seconds. This reconfiguration is performed on nodes 10, 91 and 100 and can be performed by the dissemination of a single data packet. 4. For another 200 seconds, the temperature components publish their temperature readings. This time using the new periodic interval of 30 seconds. We compare the results of our middleware layer to the alternatives of always multicasting and always broadcasting. Figure 7 shows the total amount of transmissions in the network needed to execute this set of actions. During the first action, the evaluation of the decision tree results in the selection of the Fragment and Multicast leaf. The temperature monitoring component is thus multicasted to the group members, which requires an average of 736 transmissions or about 15% of the broadcast alternative.

72

K. Thoelen, S. Michiels, and W. Joosen

During the second action, the periodicity of the temperature readings is small enough to justify the protocol overhead of multicasting. When using the Communication Management Middleware, the components register their periodic publication to the defined group and the evaluation of the decision tree results in the selection of multicast as the most efficient alternative. This results in an average of 3124 transmissions or about 52% of the broadcast alternative. Concerning the third action, the single packet needed for reconfiguration causes the Communication Management Middleware to refrain from using the multicast mechanism. The efficiency threshold e for a 10x10 grid is 2 as shown in Table 2 and thus the evaluation of the decision tree results in the selection of a Broadcast leaf. This results in a 100 transmissions as compared to an average of 161 transmissions in case multicast is used. This equals to 62% of the multicast alternative and is a reduction of 38%. During the fourth action the temperature components are registered with the relatively high periodic interval of 30 seconds. This means that in case multicast is used, a discovery phase has to be executed for each transmission of a temperature reading. The evaluation of the decision tree, however results in the selection of a Broadcast leaf. This results in 1800 transmissions which is about 77% of the transmissions needed when multicast would have been used. We can conclude that the Communication Management Middleware always selects the most efficient mechanism to perform group communication, and this at a very low cost with regards to memory consumption. The last two actions indicate the real additional value of our middleware. While a multicast mechanism can be provided, and will in some situations be the most efficient alternative, it is rather wasteful to use it as a default to perform group communication. Certainly when the overall task of WSNs is considered, which generally is periodic gathering of sensor data. The introduction of a middleware layer which takes the current context and interaction patterns into account, shows that considerable reductions of transmissions are possible.

5

Related Work

The work described in this paper is a first step towards more elaborated group communication support in the field of WSNs. While considerable work has been done on multicast routing in WSNs [10], few attention has been given to runtime selection of the efficient application of these protocols. In this section we discuss related work that adds to the functionality of the Communication Management Middleware. First of all, the functionality of the Communication Management Middleware can be expanded to include group definition and creation. This would allow the middleware to create groups outside of the awareness of the applications. In [12], a reconfigurable group management middleware is presented. Group management is defined as the combination of identifying the need for new groups and discovering their members. The authors argue that different strategies need to be employed, dependent on the user services requiring group communication

Middleware for Adaptive Group Communication in WSNs

73

and the system conditions (power level, connectivity, bandwidth etc.). A similar mechanism can be included in our context aware middleware. Secondly, as possible outcomes of the decision tree in Figure 6, broadcasting is a frequent alternative to multicasting. The efficiency of group communication, and broadcasting in general, can be further improved by supporting more intelligent broadcast mechanisms like gossiping [2] or clustering [4]. A further efficiency gain can be realized by adopting a framework like ManetKit [8]. While we consider the multicast routing protocols to be black boxes, ManetKit provides reusable components and supports composition, decomposition and hybridisation of possibly multiple MANET routing protocols. It allows for runtime transition between unicast routing protocols while retaining reusable protocol state. The combination of a multicast version of ManetKit and our Communication Management Middleware would enable finer grained mechanism selection by replacing the fixed set of communication mechanisms with runtime composable alternatives which are better adapted to the current usage and network conditions. In the third place, improving the context awareness of the Communication Management Middleware requires more elaborate studies on how multicast protocols are affected by the network context. Additionally, further work on network monitoring that extracts this information from the network is needed [5]. Node mobility is just one of the context parameters that need to be studied.

6

Conclusion

This paper presented the Communication Management Middleware which enables the selection of the most appropriate group communication mechanism based on the current interaction pattern and network context. The Communication Management Middleware incorporates rules that are the conclusions of an efficiency analysis of the ODMRP multicast protocol. We evaluated the middleware by performing a set of deployment, reconfiguration and periodic data monitoring actions. In all cases, the middleware selected the most efficient alternative, hereby considerably reducing the network overhead. Acknowledgement. This research is partially funded by the Interuniversity Attraction Poles Programme Belgian State, Belgian Science Policy, and by the Research Fund K.U.Leuven. It is conducted in the context of the IWT-SBOSTADiUM project No. 80037 [3].

References 1. Dunkels, A., Gr¨ onvall, B., Voigt, T.: Contiki - a lightweight and flexible operating system for tiny networked sensors. In: Proceedings of the First IEEE Workshop on Embedded Networked Sensors, Tampa, Florida, USA (November 2004) 2. Haas, Z.J., Halpern, J.Y., Li, L.: Gossip-based ad hoc routing. In: Proceedings of IEEE INFOCOM 2002, The 21st Annual Joint Conference of the IEEE Computer and Communications Societies, June 23-27. IEEE, New York (2002), ISBN 0-78037477-0

74

K. Thoelen, S. Michiels, and W. Joosen

3. IWT STADiUM project 80037, Software Technology for Adaptable Distributed Middleware (2010), http://distrinet.cs.kuleuven.be/projects/stadium/ (visited June 2010) 4. Kwon, T.J., Gerla, M.: Efficient Flooding with Passive Clustering (PC) in Ad Hoc Networks. ACM SIGCOMM Computer Comm. Rev. 32(1), 44–56 (2002) 5. Lee, W.L., Datta, A., Cardell-Oliver, R.: Network Management in Wireless Sensor Networks. In: Handbook of Mobile Ad Hoc and Pervasive Communication (2007) ¨ 6. Osterlind, F., Dunkels, A., Eriksson, J., Finne, N., Voigt, T.: Cross-level sensor network simulation with COOJA. In: SenseApp 2006, Tampa, Florida, USA (2006) 7. Perkins, C., Belding-Royer, E., Das, S.: Ad hoc On-Demand Distance Vector (AODV) Routing. RFC 3561 (2003) 8. Ramdhany, R., Grace, P., Coulson, G., Hutchison, D.: MANETKit: Supporting the Dynamic Deployment and Reconfiguration of Ad-Hoc Routing Protocols. In: Proceedings of IFIP/ACM/USENIX Middleware, vol. 09 (2009) 9. S´ a Silva, J., Camilo, T., Pinto, P., Ruivo, R., Rodrigues, A., Gaud˚ encio, F., Boavida, F.: Multicast and IP Multicast support in Wireless Sensor Networks. Journal of Networks 3(3), 19–26 (2008) 10. Simek, M., Komosn´ y, D., Burget, R., S´ a Silva, J.: Multicast Routing in Wireless Sensor Networks. In: Telecommunication and Signal Processing (2008) 11. SunSPOT, http://www.sunspotworld.com/ (visited June 2010) 12. Vieira, M.S., Rosa, N.S.: A reconfigurable group management middleware service for wireless sensor networks. In: Proceedings of the 3rd International Workshop on Middleware for Pervasive and Ad-Hoc Computing, Grenoble, France (2005) 13. Wagenknecht, G., Anwander, M., Brogle, M., Braun, T.: Reliable Multicast in Wireless Sensor Networks, 7. GI/ITG KuVS Fachgespr¨ ach Drahtlose Sensornetze, Berlin, Germany, September 25-26, pp. 69–72, Freie Universitt Berlin, Fachbereich Mathematik und Informatik, Tech. Report B 08-12 (2008) 14. Yi, Y., Lee, S., Su, W., Gerla, M.: On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc Networks. IETF Draft, draft-ietf-manet-odmrp-04.txt (February 2003)

A Middleware Framework for the Web Integration of Sensor Networks Herv´e Paulino and Jo˜ ao Ruivo Santos CITI / Departamento de Inform´ atica Faculdade de Ciˆencias e Tecnologia, FCT Universidade Nova de Lisboa 2829-518 Caparica, Portugal [email protected]

Abstract. This paper introduces SenSer, a generic middleware framework that allows for the Web access and management of sensor networks by virtualizing their functionalities as services, in a way that is programming language and sensor network development platform independent. We present the SenSer architectural model and provide a concrete Javabased implementation that exposes the framework as two Web services, cleanly separating regular user operations from administration operations. This prototype implementation has been validated with the development of two applications, and evaluated against the initial functional and non-functional requirements, namely modularity, performance and scalability. We have also performed two integration exercises targeting Callas [17] and SWE [3] networks. Keywords: Wireless sensor networks, Web services, Middleware.

1

Introduction

Sensor networks are, currently, one of the hottest topics in computer science research, spreading areas as diverse as programming language design and implementation, computer networks, information processing, security, and physical sensor manufacturing, to name a few. The focus of our work is on Web integration, namely on the remote Web access and management, of such networks. By being commonly deployed at distant and/or unreachable locations (e.g. environmental monitoring), the widespread use of wireless sensor networks is bound to the ability of presenting them, to the application developer, as just another easily composable software component. The main challenges in this endeavor are to provide a generic Web accessible interface for common sensor network functionalities, and to cope with heterogeneity on both endpoints of the interaction. The integration of heterogeneous sensor networks is a crucial concern that is still underachieved. There are many operating systems (e.g. TinyOS [14], SOS [13], Contiki [5], and Nano-RK [6]) and programming languages (e.g. Nesc [7], Pushpin [16], TinyScript [15], and Callas [17]) available to develop and support G. Parr and P. Morrow (Eds.): S-Cube 2010, LNICST 57, pp. 75–90, 2011. c Institute for Computer Sciences, Social Informatics and Telecommunications Engineering 2011 

76

H. Paulino and J.R. Santos

sensor networks, which makes integration in mainstream programming languages a cumbersome task. Moreover, heterogeneity must also be dealt with on the client side. The lack of standardized interfaces further contributes to the difficulty of systematically incorporating sensor networks in everyday applications. The state of the art in the porting of wireless sensor networks to the Web is almost entirely restricted to the Sensor Web Enablement (SWE) specifications [3] of the Open Geospatial Consortium. As will be further detailed in Section 7, the scope of the SWE specifications is more on the integration of existing sensor networks in a Web of sensors and not on the actual client/network interaction. There are other platforms that enable remote access to a sensor network [10,11], but these are custom-made solutions that address a particular setting, and thus do not contribute to solve the problem at hand. Other proposals, such as [1] and [9], focus on sensor network integration. In this paper we propose SenSer, a generic middleware framework that allows for the remote (Web) access and management of Sensor networks by virtualizing their functionalities as services, in a way that is programming language and sensor network development platform independent. The featured operations are divided in two categories: regular user and administrator. Regular users may interact with a network by posting queries, requiring data-streams, subscribing notifications, and performing operations (if the network contains actuator nodes). Administrators are allowed to configure networks by registering and unregistering sinks, and by reprogramming the network’s behavior. The concrete implementation of the SenSer framework relies on the Web Service technology, solving client heterogeneity by providing a Web based interoperable platform. With SenSer, a sensor network can be integrated into an application as just another Web service, hence enabling their inclusion in business processes, by resorting to BPEL [18], a feature most welcomed in businesses whose work-flow comprises the monitoring of merchandise. The heterogeneity of the sensor network endpoint is handled by network specific drivers, which must be compliant with the SenSer sensor network interface. The remainder of this paper is structured as follows: Sections 2 and 3, present, respectively, the SenSer architectural model and its concrete implementation; Section 4 focuses on an applicational example; Section 5 evaluates the framework against the functional and non-functional requirements; Section 6 presents two integration exercises with Callas networks and with SWE compliant sensor webs and, finally; Section 8 presents our conclusions and guidelines for future work.

2

The SenSer Middleware Framework

The main functional requirements of the SenSer middleware framework are: 1. to virtualize one or more sensor networks as a set of World Wide Web accessible services; 2. to seamlessly integrate multiple heterogeneous sensor networks; 3. to collect data from the registered sensor networks, either in real-time or by retrieving archived data, and; 4. to manage the middleware layer and the registered networks. The main non-functional architectural requirements are: 1. modularity

A Middleware Framework for the Web Integration of Sensor Networks

77

PRESENTATION LAYER WSN Admin Service

WSN Service

LOGIC LAYER Middleware Manager

Async Message Producer

Filter Manager

Notification Listener

Stream Listener

Query Manager

Network Registry Manager

DATA LAYER Repository Manager

Network Manager

Repository Sensor Networks

Fig. 1. The SenSer architectural model

in the design and configuration of the framework; 2. scalability in handling of large number of client requests and registered networks, and; 3. performance in the processing of client requests. The proposed architecture comprises several components organized in a threetier model that, as illustrated in Figure 1, cleanly separates client interaction, logic, and data management. The lower layer manages the two possible data sources: the registered networks or a repository of previously archived data. In this section we briefly describe each component, listing the interface of only the ones that are visible from the outside world. The complete specification can be found in [20]. 2.1

Presentation Layer

This layer exposes a set of sensor networks as two service interfaces that cleanly separate the operations available for regular users and administrators. SenSer manipulates two concepts: network type that stands for a sensor network type, e.g. a temperature or air humidity monitoring network, and; sink that abstracts a sink of a particular network type. Sink identifiers are qualified with their network type (sinkId@networkType) being that, by itself, networkType denotes all the sinks of that given type. snId denotes the whole identifier (sink and network type included) and, for the sake of simplicity, is throughout this text abusively referred to as sink. Regular User Service: Service WSNService (Listing 1)1 features the operations available to regular users: getNetworkTypes returns the identifiers of the network 1

For the sake of readability, the throwable exceptions were removed from all listings.

78

H. Paulino and J.R. Santos

types currently registered; getSinks returns the identifiers of the sinks of either one or all network types; query posts a query on a given sink; requestStream and requestNotification request a topic upon which the stream or the notification service can be subscribed; subscribe and unsubscribe manage the actual topic subscription; getSensorNetworkInterface retrieves the interface supported by the sinks of a network type and the respective parameters, and; finally executeOperation executes an operation on network, via its sink. i n t e r f a c e WSNService { N etwo r kTyp eId [ ] g etN etwo r kT yp e s ( ) ; SinkId [ ] getSinks () ; S i n k I d [ ] g e t S i n k s ( N etwo rkTypeId netwo r kType ) ; O b s e r v a t i o n q u e r y ( S i n k I d s i n k , Query q u er y , Date d a t e ) ; T o p i c r e q u e s t S t r e a m ( S i n k I d s i n k , C o n d i t i o n c o n d i t i o n , Date s t a r t D a t e , Date endDate , i n t r a t e ) ; Topic r e q u e s t N o t i f i c a t i o n ( Co n d i t i o n c o n d i t i o n , Date v a l i d i t y D a t e ) ; boolean s u b s c r i b e ( Topic t o p i c ) ; boolean u n s u b s c r i b e ( Topic t o p i c ) ; N e t w o r k I n t e r f a c e g e t S e n s o r N e t w o r k I n t e r f a c e ( N etw o r k T yp eI d n etw o r k T yp e ) ; v o i d e x e c u t e O p e r a t i o n ( S i n k I d s i n k , O p e r a t i o n op , P a r a m e t e r [ ] params ) ; }

Listing 1. Interface WSNService

Conditions are used to parameterize both data-streams and notification requests. In the context of data-streams, the condition, along with the specification of a maximum data rate, operates as a filter on the data to be received. When it comes to notification requests, the condition specifies the scenarios on which a notification event is to be triggered. Notifications may encompass more than a single sink or network type, thus no explicit target sink argument is included. Condition specification borrows the conditional and logic expressions syntax used in Java and C. An example that operates on all sinks of type Temperature and Light follows: ((Temperature > 30 && Light >= 70) || (Temperature < 5 && Light < 20)) Administration Service: Service WSNAdminService (Listing 2) specifies the administration operations. This includes the getNetworks and getSinks operations described above plus: registerNetwork and unregisterNetwork to manage network type registry, the registration requires a set of properties and the network’s interface; registerSink and unregisterSink to manage sink registry, the registration requires the sink’s network type, an adapter to bridge the communication between the framework and the sink (more on this in Subsection 2.2), and the set of properties to provide, for instance, the location of the sink; install to reprogram a network by deploying a new program in the target sink; setFilter to set the filter for a given sink (more on this in Subsection 2.2) and, finally; operations to manage the configuration (properties map) of the middleware, of a registered networkType, or of a registered sink. We only list the operations available for managing the configuration of the middleware: getPropertyList, getPropertyValue, and setPropertyValue. The remainder are analogous.

A Middleware Framework for the Web Integration of Sensor Networks

79

Note that the management of the inclusion in the framework of the adapters to bridge sink communication is not included in the interface. This happens because these operations require the uploading of code to the middleware (more on this in Subsection 2.2). This is naturally implementation dependent, for instance a Java-based implementation will not accept C# code. i n t e r f a c e WSNAdminService { N etwo r kTyp eId [ ] g etN etwo r k T y p e s ( ) ; SinkId [ ] getSinks () ; S i n k I d [ ] g e t S i n k s ( N etwo rkTypeId netwo r kType ) ; v o i d r e g i s t e r N e t w o r k T y p e ( N etw o r k T yp eI d netType , N e t w o r k I n t e r f a c e i n t e r f , Map<S t r i n g , S t r i n g > p r o p s ) ; v o i d r e g i s t e r N e t w o r k T y p e ( N etw o r k T yp eI d n etw o r k T yp e ) ; v o i d r e g i s t e r S i n k ( S i n k I d s i n k , N etw o r k T yp eI d netType , A d a p t e r I d a d a p t e r , Map<S t r i n g , S t r i n g > p r o p s ) ; void unr eg iste r Sin k ( SinkId sink ) ; v o i d i n s t a l l ( S i n k I d s i n k , byte [ ] program ) ; void s e t F i l t e r ( SinkId sink , P ipe l ine p i p e l i n e ) ; Map<S t r i n g , S t r i n g > g e t P r o p e r t y L i s t ( ) ; String getPropertyValue( String property ) ; void setPropertyValue ( Str i n g property , Str i n g value ) ; ... }

Listing 2. Interface WSNAdminService

2.2

Logic Layer

The components of the logic layer provide the core functionalities of the framework. A brief description of each follows. NetworkRegistryManager: all requests are processed by the logic layer that interacts with the data layer to relay the queries or to perform actions upon a target sink. Each kind of network (e.g. temperature monitoring network) constitutes a network type that may comprise many physical networks composed of one or more sinks, of distinct technologies, each of them explicitly addressable. i n t e r f a c e SensorNetworkAdapter { S t r i n g query ( S t r i n g query ) ; Map<S t r i n g , S t r i n g > g e t P r o p e r t y L i s t ( ) ; String getPropertyValue( String property ) ; void setPropertyValue ( Str i n g property , Str i n g value ) ; v o i d i n s t a l l ( byte [ ] program ) ; }

Listing 3. Interface SensorNetworkAdapter

Sensor technology specifics are decoupled from the middleware and encapsulated in sensor network specific adapter that has the task of translating the communication on both directions (requests and data). The registry of a sink requires the existence of such an adapter that must be compliant with the framework (respect the SensorNetworkAdapter interface depicted in Listing 3) and with the respective network type. For instance, the adapter for a temperature control network that offers operation int maxTemperature() must implement a method with such signature.

80

H. Paulino and J.R. Santos

The NetworkRegistryManager component manages the registry of sensor network adapters. How it is made available to administrators is considered an implementation detail and will be dealt with in Section 3. FilterManager: supports the ability of SenSer to periodically collect data from a given sink and archive it in an history repository. This data is processed as a data-stream subjected to a pipeline of filters, whose purpose is to refine the information to be stored (Figure 2). In the end, the processed information may be either actual sensed data or simply computed statistics. Currently pipelines can be only associated to sinks, through the setFilter method of the administration interface. Ongoing work is extending their application to client requested streams (Section 8). 1st Filter

2nd Filter

Repository

Sensor Network

Fig. 2. Filter pipeline

The pipeline specification syntax is presented in Table 1, where pipeline identifiers, filter identifiers, and primitive values are denoted, respectively by p, f , and v. A pipeline (P ) is a sequence of filters (F ) that are applied sequentially, whereas records can be used to create complex values. Types (T ) ensure compliance between two consecutive pipeline stages. Table 1. Pipeline definition syntax

P := p = F

Pipeline definition

F := f ( v¯ ) : T

Filter application

|F >F | [ F¯ ]

Filter composition

T := String | Boolean | Integer | Float | Double

Record definition Data-types

The following example denotes a pipeline, named MyPipeline, that aggregates all the data read from the network in clusters of 30 minutes (filter Aggregate with instantiated with value 30) and creates a record holding the minimum and average values (computed, respectively by filters Min and Avg) of each of these clusters: MyPipeline = Aggregate(30) : Integer > [Min : Integer, Avg : Integer] StreamListener: opens a data-stream between the framework and the client application. According to the dates supplied in the stream’s request (present or past) the data is retrieved from the target sink or from the repository. This

A Middleware Framework for the Web Integration of Sensor Networks

81

decision is taken by the component, in a way that is transparent to the client. The date range may even require a rerouting of the data path, when crossing the boundary between the past and the present. The actual emission of the data is performed by the AsyncMessageProducer component. NotificationListener: supports the subscription and handling of notifications. These events are triggered whenever the condition specified in the request is evaluated to true. Similarly to StreamListener, this component resorts to AsyncMessageProducer to create the notification topics and to publish the events. AsyncMessageProducer: factorizes the support for producer/consumer relationships. It stores all the currently active data-stream and notification topics, allowing for the client applications to subscribe them, and for the StreamListener and NotificationListener services to publishing their items. The interface includes operations to create, remove, subscribe to, and publish on data-stream and notification topics. QueryManager: processes queries to the registered networks. Once again the supplied date determines whether the query is forwarded to the repository or to the network. In either case, the operation is synchronous, in the sense that it only concludes when the result is sent back to the client. MiddlewareManager: the behavior of the SenSer framework can be regulated through a set of parameters. This component is responsible for loading these configuration parameters and for allowing their on-the-fly modification, without disrupting the framework’s availability. 2.3

Data Layer

This layer comprises three components: one responsible for the storage of the framework’s configuration settings, and two more responsible for the integration of the system’s data sources: sensor networks and the repository. Only the latter two justify a more detailed description. NetworkManager: relays the upper level requests to the target sink. The network type identifier is used to retrieve the network type’s interface and ensure protocol compliance between the request and the target sink. The sink identifier selects the required adapter (SensorNetworkAdapter implementation) from the network registry. RepositoryManager: supports the persistent storage of the data collected from the sensor network sinks. It manages the integration of a specific repository (e.g. a database system or a file-system) in the framework, virtualizing it in a service interface accessible to the upper level components. Furthermore, it manages the connections for data storing and retrieval.

3

Implementation

This section presents the most relevant implementation specific details of a Javabased prototype instantiation of the SenSer architectural specification. We

82

H. Paulino and J.R. Santos

center our discussion on the following major topics: overall instantiation of the model; integration with the World Wide Web; sensor network registry; support for data-streams and notifications, and; implementation of filter pipelines. Model Instantiation: to promote loose coupling between components, allowing these to be autonomous and to run on different machines, we instantiated the three-tier conceptual model in a Enterprise Service Bus. All inter-component communication is built on top of Java-RMI, hence the bus takes the form of a Java-RMI registry. Web Integration: all client-platform interaction is based on the Web service technology, providing an Internet-scale interoperable platform. The WSNService and WSNAdminService components are, thus, exposed as two Web services. To provide a framework upon which it would be easy to access the SenSer middleware layer from Java applications, we have transposed these interfaces to the Java world by implementing a client side API that hides the Web service communication details. The interface of this API is almost identical to the one presented in Subsection 2.1 as can be checked in the example of Section 4. Network Registry: the registry of sensor network adapters is performed by having a client that directly accesses the NetworkRegistryManager by plugging in the service bus. The registry requires the upload of all the user-implemented classes required by the adapter are uploaded to the framework and locally stored. Ongoing work focuses the integration of these operations in the Java client API by featuring a Web service dedicated to these operations. Several of the functionalities that must be offered by these adapters crosscut the sensor technology, operating system and programming language, e.g. the properties map. We offer factorize these functionalities in an adapter development kit. Data-streams and Notifications: both these features are supported by WSNotification [19], a topic-based publish/subscribe Web service standard. Each distinct data-stream and notification request has a associated dedicated topic in the AsyncMessageProducer component. This topic is used both for subscription (client side) and for publication purposes (components StreamListener and NotificationListener). The implemented Java client API features a component, AsyncMessageConsumer, that hides the details of the publish/subscribe protocol. As is illustrated in Figure 3, the client no longer has to be aware of the topic subscription protocol, simply posting the request and obtaining the stream or the notification event handler. The latter can be used to associate an action to the reception of the notification, such as display or persistently store them. An example will be given in Section 4. Figure 3 illustrates the whole stream request process. The client invokes the requestStream method on the API. The request is relayed to the WSNService Web service that, in turn, relays it to the StreamListener logic layer component. A new topic is then created by the AsyncMessageProducer (if one does not yet exist) and sent back to the API, that automatically subscribes it. From this point

A Middleware Framework for the Web Integration of Sensor Networks

83

Fig. 3. Data-stream request diagram

on, the AsyncMessageConsumer component receives all the messages published on the subscribed topic. Filter Pipelines: filters are instantiated as Java classes that implement the Filter interface depicted in Listing 4. Filter provides methods to define the filter’s input arguments (setArgs), to program the filter’s data manipulation process (process), and to obtain a stream to the filter’s output (getStream). The last method is used to connect two pipeline stages, each filter processes the data it reads from the stream generated by the previous stage in the pipeline.

}

interface F ilt er { void setArgs ( String [ ] args ) ; void p r o c e s s ( j a v a . i o . InputStream i n ) ; j a v a . i o . InputStream getStream ( ) ;

Listing 4. Interface Filter

The name of a filter in the pipeline definition string must match the name of the associated Java class. The latter will be dynamically loaded as soon as the string is successfully parsed. Thus, to add a new filter to SenSer is simply to place a Java filter class with the same name in a folder pre-determined by the framework’s configuration parameters. The output of the pipeline must be persistently stored in the repository (a MySQL database in our prototype). For this purpose, a Java class that encapsulates the record to be stored is dynamically generated. This class resorts to the Java Data Objects technology to abstract database records as Java objects.

4

Automated Home Management Application

This section illustrates how SenSer can be used to develop an automated home management application that incorporates lighting control and security systems. We have also used SenSer to interact with a network of medical body-sensors,

84

H. Paulino and J.R. Santos

such as the one described in [2], but the home management application better illustrates the framework’s capabilities. The sensor networks used in these examples were simulated. The lighting control system automatically regulates the lights of the rooms, according to human presence and daylight intensity, while the security system closes all outside doors and windows when no human presence is detected inside the house. Due to space restrictions, the application cannot be fully presented. We will restrict the code to two snippets that cover the registry of network types and sinks, and the management of notifications. As is illustrated in Figure 4, this implementation assumes the existence of sensor networks for human presence detection and for the measurement of light intensity, both comprising a sink node for each house division. It also assumes the existence of networks to control the intensity of each illumination point (e.g. a X10 module network), and to control the lock of every outside door and window.

RepositoryManager

Lock Activation Network

Presence Detection Network

Room1

NetworkManager

Room2

Window1

Window2

Light Intensity Network

Door

Room1

Room2

Light Switching Network

Room1

Room2

Fig. 4. The networks registeres in the automated management application

Once the frameowrk is equipped with all the adapters needed by the set up sensor networks, the remote interfaces can be used to manage the network types and sink nodes, and to program the intended behaviors. Listing 5 illustrates the registry of the LightSwitchingNetwork network type and its living-room sink. The network interface includes, among others, the switchOn operation that has no parameters. The properties map in the sink registry was used to indicate the latter’s contact port2 . Sen s er WSN A d m i n Ser vi ce w s n A d m i n S e r v i c e = new Sen s er WSN A d m i n Ser vi ce ( s en s er UR L ); wsnAdminService . registerNetwor kT ype ( ” LightSwitchingNetwork ” , new N e t w o r k I n t e r f a c e ( ) {{ . . . ; p u t ( ” s w i tch O n ” , n u l l ) ; . . . ; }}) ; wsnAdminService . r e g i s t e r S i n k ( ” LivingRoom@LightSwitchingNetwork ” , ” LSNAdapter ” , new P r o p e r t i e s M a p ( ) { p u t ( ” P o r t ” , ”A1” ) ; }}) ;) ;

Listing 5. Sink registry example 2

The port value range is network type specific.

A Middleware Framework for the Web Integration of Sensor Networks

85

A notification request returns an handler to which an action can be bound. This binding will cause the AsyncMessageConsumer client API module to associate the behavior to the correspondent notification topic, and trigger its execution whenever a message is received. Listing 6 exemplifies how to perform a notification request and to bind an action to its reception. These actions are programmed by providing a concrete implementation of the NotificationResponse abstract class, namely of its response method. In this particular example, the response is to switch on the lights on a given house division. N o ti f i ca ti o n H a n d le r livingRoomHandler = wsnService . r e q u e s t N o t i f i c a t i o n ( ” L i vi n g R o o m @H u m a n Pr es en ceD etec to r==f a l s e && L i v i n g R o o m @ L i g h t I n t e n s i t y <0.4 ” ); livingRoomHandler . setResponse ( new N o t i f i c a t i o n R e s p o n s e ( w s n S e r v i c e , ” L i v i n g R o o m @ L i g h t S w i t c h i n g N e t w o r k ” ) { void response () { w s n S e r v i c e . e x e c u t e O p e r a t i o n ( t h i s . s i n k , ” s w i tch O n ” , n u l l ) ; } };) ;

Listing 6. Notification setup and management example

5

Evaluation

In this section we evaluate SenSer against the requirements enumerated in Section 2. The functional requirements have all been met and individually and collectively tested [20]. We just highlight the sensor network adapter approach, which enables the interaction of sensor networks independently of their technology, and introduction of the date field in the user requests, a tool that allows the framework to route the requests to the target sensor networks or to the repository, providing for the transparent access of real-time and archived data. Regarding the non-functional requirements, special focus was given on modularity, namely on the clean separation between client interaction, logic, and data retrieval and storage. The use of the ESB model was also an important contribution to meet this modularity requirement. Moreover, it enables the physical separation of the components. SenSer does not have to run in a single processor (core) or machine, thus enabling scalability. Another key aspect of modularity was parameterization. The framework is highly configurable and this can be done remotely, through the administration API. To certify that SenSer does not pose as a bottleneck on user-sensor network interaction, we performed some performance tests. The first test measured the overhead imposed on client requests. Figure 5 presents the mean and the standard deviation for three scenarios: 30, 150 and 300 simultaneous queries. We can observe that for each of these the mean of the overheads is under 25 milliseconds, and the maximum value under 35 milliseconds. We can also observe that there are no scalability problems. the overhead remains steady with the increase of requests.

86

H. Paulino and J.R. Santos

Fig. 5. Overhead imposed on query processing

Fig. 6. Mean of the overhead imposed on Fig. 7. Standard deviation of the overhead stream processing imposed on stream processing

The next two graphics, depicted in figures 6 and 7, present the mean and the standard deviation of the overhead that SenSer imposes on stream processing. We measured the time elapsed between the instant a new data item arrives from a sensor network and the instant it is sent to the client, i.e., the time the platform takes to process it. We analyzed streams requested with rates of 5 and 10 milliseconds. The graphics present the actual rate of the stream after being processed by SenSer and the overhead regarding the original requested rate. We can observe that the overhead never reaches the 2% barrier. In fact, for streams with rates of 5 milliseconds it is lower than 1%. The impact of these is negligible when taking into account the latency of an Internet connection.

6

Integration

We realized two integration exercises. The first, directed to the Callas WSN programming language [17], consists on the implementation of a Java class that communicates with Callas network sinks. This class can now be extended to be compliant with the SensorNetwork interface and, thus, be used to register Callas networks with specific capabilities. Callas sink nodes were equipped with a set of system calls that enables them to accept TCP connections at a configurable port. Requests are in the form of

A Middleware Framework for the Web Integration of Sensor Networks

Data Layer

87

Socket communication 1. Callas request

Network Manager

CallasSensor Network

2. OK or ERROR

Sink

if OK

3. DATA

Repository Manager

Callas sensor network

Fig. 8. Callas communication protocol

a Callas program that is submitted to the sink (Figure 8). The parsing of the program will generate an Ok or ERROR response, being that the former spawns the request to the network and replies the consequent result. The second exercise targeted the SWE specification. It is a simple theoretical exercise that illustrates how SenSer and SWE can be integrated. The integration of a SenSer instance in a SWE network (Figure 9) only requires the addition of an extra component in the SenSer presentation layer, with the task of translating SWE to SenSer requests and SenSer to SWE data. The opposite, i.e. to register a SWE network in SenSer (Figure 10) is also feasible. The motivation is to compare local measurements with data retrieved from other locations. For instance, a concrete example is the comparison of air pollution indicators: how do the local measurements compare with the mean of the remainder of the city or country. In this scenario, the translator would have to be SensorNetwork compliant and convert SenSer requests to SWE and SWE data to SenSer. Figures 9 and 10 illustrate both processes.

WSN Admin Service

WSN Service

SWE SOS WNS SPS SAS

Middleware Manager

Async Message Producer

Filter Manager

Notification Listener

Stream Listener

Repository Manager

WSN Service

WSN Admin Service

Network Manager

SWE Translation Service Light Switching Network

SWESensor Network

Middleware Manager

Async Message Producer

Filter Manager

Repository Manager

Notification Listener

Network Registry Manager

Query Manager

Stream Listener

Query Manager

Network Registry Manager

Network Manager

Fig. 9. Integrate SenSer in SWE

SAS SPS WNS SOS SWE

Room 1

Room 2

Room 3

Fig. 10. Integrate SWE in SenSer

Room 4

88

7

H. Paulino and J.R. Santos

Related Work

IrisNet [8] stands out as one of the first projects to address sensor webs at an Internet-scale. It is a software infrastructure that supports distributed queries on a Internet-wide service-oriented platform that abstracts common sensing hardware, such as web-cams. Services are described through XML documents that are published on dedicated distributed databases. These operations, as well as the querying, are performed through a high-level API. Sensor Web Enablement (SWE) [3] is a set of models and Web service interfaces proposed by the Open Geospatial Consortium for the Internet integration of sensor systems. The goal is to provide a specification for the integration of sensor networks in a Web of sensors accessible via Internet technologies. The focus is on the integration of several sensor networks in a web of sensors, rather than the actual remote access and management of such networks. The featured services have several limitations of which we emphasize: 1. the lack of management operations, such as network registry and network reprogramming; 2. the lack user levels or roles, such administration privileges, or different access permissions for different users; 3. the overall complexity when the purpose may be simply to setup a single network, and; 4. the disregard for community adopted Web service standards, such as service orchestration to perform planning, defining its own protocol. In our opinion, a sensor network should be virtualized as just another service on Web, and therefore easily integrable with standard Web service technologies. Some SWE implementations are available3 Among the most known are Nosa [4] and 52o North [21]. Nosa is a research-oriented implementation of a first iteration of the specification, that had many limitations, some of which overcome with non-SWE extensions [12]. 52o North is a more recent implementation with a more industrial focus. The documentation is mostly in German, thus not easily digestible for the majority of the scientific community. GSN [1] also targets sensor network integration. The objecive is to build a sensor Internet by connecting virtual sensors, that abstract data-streams originating from either a sensor network or from another virtual sensor. SQL queries can than be performed on top of these virtual sensors. There is no focus on Web interoperability. Aginome [9] integrates IP and sensor networks by resorting to mobile agents that communicate through tuple-spaces. The focus is on sensor network integration, agents may migrate between wireless sensor networks, rather than on Web exposure and interoperability.

8

Conclusions

We have presented SenSer, a framework that provides a generic middleware for the remote access and management of sensor networks. Two distinct interfaces 3

http://www.sensorsmag.com/networking-communications/ government-military/new-impl ementations-ogcsensor-web-enablement-standards-1437

A Middleware Framework for the Web Integration of Sensor Networks

89

are defined to cleanly separate the operations available for regular users and administrators. A major effort was placed on the support for modularity and heterogeneity. The framework’s architecture follows a three-tier model, decoupling the presentation, logic and data layer, the latter comprising the two possible data sources: registered sensor networks and a history repository. A Java-based prototype implementation exposes the framework’s presentation layer as two Web services, providing a Internet-scale interoperable platform, thus solving client heterogeneity. Due to the lack of standards, sensor network heterogeneity is handled by a dedicated framework compliance interface, that specifies the SenSer/sensor network interaction protocol. The prototype has been validated with the development of applications [20], of which one was briefly described in Section 4, and with an evaluation of the functional and non-functional requirements. Regarding the latter, a performance study revealed that SenSer is a lightweight framework that scales well with the increase of requests. Our final efforts were in the realization of two integration exercises, with Callas sensor networks and SWE sensor webs. Regarding future work our goals include: 1. the addition of the registry of network types to the Java client API. This requires the migration of Java code on top of Web service technology, an ongoing work; 2. apply the filter pipeline functionality to modify client requested streams; 3. the definition of different access permissions, for instance to distinguish users that may only retrieve data, from the ones that can perform actions; 4. the integration with real-life applications, and; 5. the actual incorporation of an authentication module in the current implementation. Acknowledgments. This work was partially funded by FCT MCTES under project CALLAS (contract PTDC/EIA/71462/2006) and the CITI research center.

References 1. Aberer, K., Hauswirth, M., Salehi, A.: A middleware for fast and flexible sensor network deployment. In: Dayal, U., Whang, K.-Y., Lomet, D.B., Alonso, G., Lohman, G.M., Kersten, M.L., Cha, S.K., Kim, Y.-K. (eds.) Proceedings of the 32nd International Conference on Very Large Data Bases, Seoul, Korea, September 12-15, pp. 1199–1202. ACM, New York (2006) 2. Baldus, H., Klabunde, K., M¨ usch, G.: Reliable set-up of medical body-sensor networks. In: Karl, H., Wolisz, A., Willig, A. (eds.) EWSN 2004. LNCS, vol. 2920, pp. 353–363. Springer, Heidelberg (2004) 3. Botts, M., Percivall, G., Reed, C., Davidson, J.: OGC Sensor Web Enablement: Overview and high level architecture. Technical report, OGC (2007) 4. Chu, X., Kobialka, T., Durnota, B., Buyya, R.: Open sensor web architecture: Core services. In: Proceedings of the 4th International Conference on Intelligent Sensing and Information Processing, pp. 98–103 (2006) 5. Dunkels, A., Gronvall, B., Voigt, T.: Contiki - a lightweight and flexible operating system for tiny networked sensors. In: LCN 2004: Proceedings of the 29th Annual IEEE International Conference on Local Computer Networks, pp. 455–462. IEEE Computer Society, Los Alamitos (2004)

90

H. Paulino and J.R. Santos

6. Eswaran, A., Rowe, A., Rajkumar, R.: Nano-RK: An energy-aware resource-centric RTOS for sensor networks. In: RTSS 2005: Proceedings of the 26th IEEE International Real-Time Systems Symposium, pp. 256–265. IEEE Computer Society Press, Los Alamitos (2005) 7. Gay, D., Levis, P., von Robert Behren, Welsh, M., Brewer, E., Culler, D.: The nesC language: A holistic approach to networked embedded systems. In: PLDI 2003: Proceedings of the ACM SIGPLAN 2003 Conference on Programming Language Design and Implementation, pp. 1–11. ACM, New York (2003) 8. Gibbons, P., Karp, B., Ke, Y., Nath, S., Seshan, S.: Irisnet: An architecture for a worldwide sensor web. IEEE Pervasive Computing 2(4), 22–33 (2003) 9. Hackmann, G., Fok, C.-L., Roman, G.-C., Lu, C.: Agimone: Middleware support for seamless integration of sensor and IP networks. In: Gibbons, P.B., Abdelzaher, T.F., Aspnes, J., Rao, R. (eds.) DCOSS 2006. LNCS, vol. 4026, pp. 101–118. Springer, Heidelberg (2006) 10. Hillenbrand, M., Verney, A., Muller, P., Koenig, T.: Web services for sensor node access. In: 5th CaberNet Plenary Workshop (2003) 11. Jiang, G., Chung, W., Cybenko, G.: Semantic agent technologies for tactical sensor networks. In: Carapezza, E.M. (ed.) Proceedings of the SPIE Conference on Unattended Ground Sensor Technologies and Applications V, vol. 5090, pp. 311–320. SPIE, San Jose (2003) 12. Kobialka, T., Buyya, R., Leckie, C., Kotagiri, R.: A sensor web middleware with stateful services for heterogeneous sensor networks. In: 3rd International Conference on Intelligent Sensors, Sensor Networks and Information, ISSNIP 2007, pp. 491–496 (2007) 13. Kumar, C.-C.H.R., Shea, R., Kohler, E., Srivastava, M.: A dynamic operating system for sensor nodes. In: MobiSys 2005: Proceedings of the 3rd International Conference on Mobile Systems, Applications, and Services, pp. 163–176. ACM, New York (2005) 14. Levis, P., Madden, S., Polastre, J., Szewczyk, R., Whitehouse, K., Woo, A., Gay, D., Hill, J., Welsh, M., Brewer, E., Culler, D.: TinyOS: An operating system for sensor networks. Ambient Intelligence, 115–148 (2005) 15. Lewis, P.: The TinyScript Language. UC Berkeley (2004) 16. Lifton, J., Seetharam, D., Broxton, M., Paradiso, J.A.: Pushpin computing system overview: A platform for distributed, embedded, ubiquitous sensor networks. In: Mattern, F., Naghshineh, M. (eds.) PERVASIVE 2002. LNCS, vol. 2414, pp. 139– 151. Springer, Heidelberg (2002) 17. Martins, F., Lopes, L., Barros, J.: Towards Safe Programming of Wireless Sensor Networks. Electronic Proceedings in Theoretical Computer Science 17, 49–62 (2010) 18. OASIS. Web Services Business Process Execution Language (WSBPEL) TC, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel 19. OASIS. Web Services Notification (WSN) TC, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn 20. Santos, J.R.: Um middleware para acesso e gest˜ ao de redes de sensores em ambientes web. Master’s thesis, Faculdade de Ciˆencias - Universidade Nova de Lisboa, Supervised by Herv´e Paulino (2009) 21. Stasch, C., Walkowski, A., Jirka, S.: A geosensor network architecture for disaster management based on open standards. In: Digital Earth Summit on Geoinformatics 2008: Tools for Climate Change Research, pp. 54–59 (2008)

Expressing and Configuring Quality of Data in Multi-purpose Wireless Sensor Networks Pedro Javier del Cid, Daniel Hughes, Sam Michiels, and Wouter Joosen IBBT - DistriNet, Katholieke Universiteit Leuven, 3001 Leuven, Belgium {name.lastname}@cs.kuleuven.be Department of Computer Science and Software Engineering, Xi'an Jiaotong-Liverpool University, 215123 Suzhou, China [email protected]

Abstract. Wireless Sensor Networks (WSNs) are evolving towards interconnected, sensing, processing and actuating infrastructures that are expected to provide services for multiple concurrent applications. In a multi-purpose WSN, concurrently running applications share network resources and each may have varying Quality of Data (QoD) requirements. Our middleware targets these multipurpose WSN deployments. Specifically this paper discusses how one should express and configure QoD properties for multi-purpose WSNs. We contribute by presenting our approach; which leverages per-instance QoD configuration and a separation of operational concerns to achieve simpler configuration and improve adaptability and customize-ability of the WSN. A prototype implementation and comparison to the related state of the art in WSNs are provided. Keywords: Wireless Sensor Networks, Resource Management, Middleware, Adaptive, Context Aware, Quality of Data.

1 Introduction Wireless sensor networks (WSNs) support the integration of environmental data into applications, from mobile devices to backend enterprise infrastructure. WSNs are evolving towards interconnected, sensing, processing and actuating infrastructures that are expected to provide services for multiple concurrent clients [1]. In a multipurpose WSN, applications share network resources and each may have varying Quality of Data (QoD) requirements. Notably, QoD requirements, i.e. the required data reliability, resolution and the importance of a single reading, vary from application to application [2]. Previous approaches address the challenge of multiple applications on shared infrastructure by decoupling of the applications and the network, e.g. Milan [3], Servilla [4], TinySOA [1] and TinyCOPS [5]. In early approaches, such as Milan, QoD is expressed at the application level i.e. once for every application, it is assumed that: (i) there is no run-time variability in required QoD, (ii) considerable collaboration between applications is possible and (iii) a-priori knowledge of all G. Parr and P. Morrow (Eds.): S-Cube 2010, LNICST 57, pp. 91–106, 2011. © Institute for Computer Sciences, Social Informatics and Telecommunications Engineering 2011

92

P.J. del Cid et al.

applications that will use the network is available. In multi-purpose WSNs these assumptions are not reasonable thus application level configuration of QoD is not an adequate approach. Approaches such as TinySOA [1], Servilla [4] and TinyCOPS [5] configure QoD in a per-instance manner. An instance refers to each service request or query an application may have, where an application may have multiple concurrent requests or queries. Per-instance configuration allows for higher flexibility and optimization. These multi-purpose WSNs may serve different types of applications with arbitrary requests or query patterns with no a-priori knowledge needed. They provide application developers the flexibility to meet variable QoD requirements of new applications and yet expect the same levels of performance that would result from an applicationspecific deployment [1]. Fine-grained optimization is possible because every instance may be customized with specific QoD requirements allowing for higher component re-usability, more efficient parameterization and improved reliability through lightweight run-time capacity planning [6]. We present our approach that leverages per-instance QoD configuration and a separation of operational concerns to achieve simpler configuration and improve adaptability and customize-ability of the WSN. Adaptability refers to the system’s capacity to enact context-aware run-time reconfiguration. Customize-ability refers to the capacity the system has to fine-tune or extend its functionality at run-time without service interruption. This paper is structured as follows: Section 2 elaborates on the operational setting of our research. Section 3 presents an overview of our middleware. Section 4 presents our prototype implementation. Section 5 further describes WSN configuration and highlights our achieved benefits. Section 6 discusses these benefits in the context of the current state of the art. Section 7 concludes the paper and maps the road ahead.

2 Operational Setting One of the main objectives of shared enterprise deployments is to maximize the return on investment in the WSN infrastructure [1,7,8]. We leverage on per-instance QoD configuration and focus on maximizing the amount of concurrent and varying QoDaware requests the network can successfully support while providing simple configuration abstractions. Quality of Data (QoD) can be broken down into reliability and resolution [2]. The former specifies the accuracy of the data i.e. reported data corresponds to reported phenomena and the latter refers to the granularity of data and its temporal and spatial qualities. These are properties that are specified by the application and may vary for each request instance. In multi-purpose WSNs the main operational concerns involved in application development and use should be undertaken by the following operational roles as defined by Huygens et al. in [9]: application developers, service developers and network administrators. Application developers (application owners in [9]) will be concerned with achieving high-level business goals and will undertake the implementation of domain specific business logic. Service developers (component developers in [9]) will be concerned with developing prepackaged functionality to support the goals of the network administrators and application developers. They will

Expressing and Configuring Quality of Data in Multi-purpose WSN

93

undertake the implementation of application-independent and platform-specific common use services e.g. temperature sensing on a SunSpot [10] sensor node. Network administrators (infrastructure owner in [9]) will be concerned with monitoring network QoS, configuring and maintaining common use software services e.g. temperature, aggregation. They also have high-level goals, usually system-wide requirements driven by concerns such as system lifetime optimization or service level agreements with application stakeholders. Consider a WSN deployed in a corporate warehouse (see Fig. 1). The deployment is shared by multiple applications each with different QoD requirements. An HVAC application monitors environmental conditions to determine cooling and heating requirements and periodically gathers sensing information. A tracking application is used to provide information on package movement and environmental conditions during storage.

Fig. 1. Deployment scenario

The HVAC application periodically requests temperature and light readings throughout the warehouse and deploys specialized components to specific nodes that locally determine if an actuating action needs to be taken e.g. if temperature exceeds 30 degrees increase power to the AC unit in this area. The tracking application continuously monitors temperature and position of packages. Additionally a specialized component is deployed to high value packages which use light and accelerometer readings to locally determine package handling and tampering. An application developer would be concerned with implementing the required functionality of each deployed application; that is HVAC and tracking, as well as the respective application-specific components. The implementation of the temperature, light, accelerometer services would be undertaken by the service developer but monitoring their run-time performance would be undertaken by the network administrator. The network administrator is in charge of monitoring the infrastructure and taking corrective action when needed to ensure expected quality levels are achieved. Current approaches do not properly separate these operational concerns and do not provide appropriate abstractions to achieve the required adaptability and customize-ability.

94

P.J. del Cid et al.

3 Middleware Overview We propose a middleware approach based on configurable components that may be used in multiple concurrently running compositions and allow different QoD parameterizations for each composition. Figure 2 illustrates an overview of the different elements that compose our middleware. Through decoupling of applications and the components implementing the underlying application functionality, and the provision of structure and behavior patterns we achieve simple compositions and perservice instance parameterization. We consider a service instance to be: each service request from the moment it is submitted to the middleware until it has been processed. The service request specification is used to express the desired functionality and QoD for every service instance.

Fig. 2. Middleware overview

3.1 The Mediation Layer The mediation layer runs in the backend and in cluster heads in the WSN. The mediation layer is implemented by the Service Management Component (SMC). It automatically interprets requests, selects the optimal service providers and instantiates an individual service composition involving specified services from a shared pool of components interacting in a loosely coupled manner. Every application may submit multiple service requests, each representing a service instance. As such, every composition allows for per-service instance parameterization of how this pool of components is used.

Expressing and Configuring Quality of Data in Multi-purpose WSN

95

3.2 The Service Request Specification Application developers use the service request specification to express their QoD requirements for each service instance. In the specification one includes the request Id, which is a unique sequential number generated by the WSN backend middleware. The service Id represents a globally unique service identifier defined at service implementation time. Each sensing service e.g. temperature, humidity, has a unique service Id. The temporal resolution required from the specified service is expressed through the sampling frequency. Duration of service is the amount of time one requires the selected sensing service to collect data samples. Spatial resolution is specified by selecting a target location e.g. <warehouse A> or < node21>. A Postcollection data processing service Id, which is globally unique identifier for services like averaging or specialized data filters. Finally a parameter to be passed to the postcollection data processing service may be required e.g. in case of the averaging component, one may use the parameter 30 to indicate the average must be done in 30 minute intervals. Each service request may be configured with different QoD requirements and it may or may not include one or more post-collection processing instructions. serviceRequest#(requestId,serviceId,samplingfrequency,duration, targetLocation,DataProcessServiceId[],parameter[]);

3.3 WSN Services As one may see in Fig. 3A, we typify services based on two primary types: sensing services and post-collection data processing services. These are the meta-types used to implement all services that comprise the pool of services available to create service compositions. They are implemented in Sensing Service Components (SSC) and Data Processing Component (DPC) respectively. Sensing services are components offering typical functionality such as the retrieval of temperature or light readings. They provide access to the various sensors. Data processing services are components implementing typical post-collection data processing functionality such as averaging, data filtering or persistence. A sample composition may be: (i) an SSC reads, timestamps and stores temperature readings which, (ii) an averaging component processes and finally (iii) a persistence component stores to static memory. SSC and DPC meta-types impose structure and behavior of implemented services. This predictable structure and behavior allows for higher re-usability of services in compositions because all DPCs can transparently be used with any SSC. SSCs are unaware of the existence of any other SSC or DPC. All SSCs provide and require the same interfaces. All DPCs provide and require the same interfaces. Elaboration on how the imposed structure and behavior of components helps achieve more efficient reconfiguration and service composition can be found in our previous work [6]. Data reliability requirements may be achieved with the use of specialized data filters implemented with DPCs. For example, erratic sensor readings may be excluded from a sample on the basis that may indicate a defective sensor.

96

P.J. del Cid et al.

Fig. 3. WSN Services and valid service compositions

3.4 Service Compositions The submission of a service request starts a service instance which is fulfilled with an independent service composition. Service compositions can have only 1 SSC and zero-to-many DPCs (see Fig. 3B). Dash-dotted lines depict a composition that only involves an SSC, the dashed lines depict a composition that uses one SSC and one DPC and the continuous lines depict a composition that involves an SSC and 2 DPCs. All components may be used in multiple compositions concurrently and have different QoD parameters for each composition. Due to the imposed structure and behavior, DPCs may be transparently combined with any SSC. Additionally new services can be introduced or additional requests supported and none of the existing compositions need to be modified or any service interrupted, resulting in efficient reconfiguration. Elaboration on how our simple composition rules help achieve more efficient service reconfiguration and lower complexity overheads can be found in our work [6]. 3.5 Share-Able and Adaptive Components We consider that introducing a new component for every service requiring different parameterization is not efficient, as exemplified in [6]. We separate the functional code from the meta-data and share the same component instance across multiple service compositions (see Fig.4A). This meta-data contains the configuration semantics to be used to serve each service request. Each component is associated with a particular service composition through a request Id; this association contains perinstance configuration semantics. Configuration semantics for each service composition are extracted from the specified service request. The configuration semantics include specified QoD, services involved in each composition and related parameterization. The SMC parses the service request and extracts configuration parameters which it autonomously submits to the corresponding SSC or DPCs. Clients may also submit these configuration parameters directly to the SSC or DPC using ProcessRequest@SSC or ProcessData@DPC as one may see in Fig. 5A. This allows a single instance of our components to be used across multiple service compositions with varying parameters in each composition and avoids substantial increases in required static and dynamic memory per additional service request. For further details on how each SSC and DPC are configured we refer the reader to [6].

Expressing and Configuring Quality of Data in Multi-purpose WSN

97

Fig. 4. Configuration semantics, annotated attributes and adaptation in components

Furthermore these configuration parameters are available for introspection in SSCs and DPCs. Introspection provides insight as to currently allocated requests and their parameters. Additionally these inform of current component dependencies. Annotated Component Attributes: SSCs and DPCs are annotated with attributes that are mandated as part of their structure. They may be static or dynamically modified at run-time depending on the attribute and intended use. For example: an energy category attribute is used to represent energy consumption incurred in the invocation of a particular sensor, given that energy use may vary considerably by platform / sensor hardware as exemplified in [11]. At implementation time the service developer would include the value for the energy category of the SSCs he implements and these are specific to the platform/sensor of deployment. These attributes provide semantic information which is used during the evaluation of system strategies, such as: adaptation and resource reservation. E.g. The result of the evaluation of an adaptation strategy may modify the maxSamplingFrequency attribute in an SSC modifying the execution of the component’s functional code, in turn influencing the selection of service provider during the evaluation of the selection strategy in the service matching process of the SMC (see Fig.4C). Sykes et al. in [12] discuss how the use of quality attribute annotations in components improves decisions about adaptive reconfigurations. Using these attributes is how the service developers may express their concerns, regarding relevant usage parameters, provided accuracy or energy consumption of implemented services. Component Level Adaptation: Component behavior may be modified at run-time i.e. the parameters used in the execution of its functional code may be dynamically modified as previously discussed. These adaptations give the network admin effective mechanisms that account for current working conditions and help prolong system lifetime. As exemplified in Levels [13] modifying available functionality has proven very efficient in prolonging system lifetime in sensor networks. The adaptation strategy specifies that data resolution is lowered more aggressively on services with higher energy categories when battery levels decrease, thus avoiding excessive use of high consumption services. This is done independently from any request being processed and transparently for application developers and service developers.

98

P.J. del Cid et al.

3.6 Capacity Planning Each node has a light-weight Resource Manager (RM) that does run-time capacity planning and reservation of any resource required to effectively support allocated service requests. For further details on the benefits of run-time capacity planning we direct the reader to [6]. Currently we focus on required dynamic and static memory to support allocated requests. The RM uses a memory reservation strategy specified by the network administrator. This strategy specifies how much memory to reserve based on estimated requirements and when and how to release these reservations. This guarantees that every service request will have the needed resources e.g. memory, to be processed successfully through the service duration. Calculating Required Memory: In order to effectively calculate the amount of static and dynamic memory that will be used by the middleware, the service developer must realize an off-line process to establish a memory baseline and an autonomic run-time process to establish run-time memory requirements. During the off-line process a baseline of memory use is recorded for every implemented service and the corresponding annotated attributes of each service are updated e.g. requiredStaticMemory, requiredDynamicMemory, memoryManagementOverheads. The on-line process parses each submitted service request and extracts: (i) services involved in the composition (ii) QoD parameters. These are used to calculate the amount of memory needed to successfully process each request. For example: in the SSC the amount of required memory depends on the output dataset size which is directly proportional to the amount of records. These will vary depending on sampling frequency and service duration. Further details can be found in our previous work [6]. Memory Management: The memory management strategy dictates how and when data should be transferred to static memory. The strategy accounts for frequency of read and write operations. Additionally this strategy may specify memory related actions to increase reliability, e.g. make all sensed and processed data persistent when battery levels drop under 15%. Both these strategies are evaluated in the RM. Making data persistent in static memory is done by a persistence service DPC. 3.7 The Client API Clients interact with the middleware through a distributed API (see Fig. 5A). We consider middleware clients to be applications, which are developed by application developers. The mediation layer is accessible to the clients at the back-end or in every cluster head and exposes interfaces A and B. The former interface is used to submit service requests and the latter to retrieve processed data. Clients may also access the middleware directly at the sensor nodes commonly through the use of applicationspecific components. This interaction happens through interfaces 1 and 2 available on SSCs and DPCs. The former is used to submit configuration parameters which are used by the component to parameterize each service instance and the latter is used to retrieve data. ProcessRequest@SSCorDPC(requestId,samplingfrequency,duration); ProcessData@SSCorDPC(requestId,serviceIdToCollectData,parameter, timeToExecute);

Expressing and Configuring Quality of Data in Multi-purpose WSN

99

Fig. 5. Middleware component and interface views

This distributed API gives the application developer access to WSN services directly on each sensor node in a consistent manner. She is able to leverage innetwork processing to achieve improved application performance while still undertaking only her concerns for the implementation of business functionality. She can develop application-specific components that take business reasoning into the network and react locally to improve reaction times while still being abstracted away from platform specific programming. For example: the HVAC components that locally determine if an actuating action needs to be taken, as described in section 2 (see Fig.1). 3.8 Network Administrator API The network administrator interacts with the middleware through the API depicted in Fig. 5B. The SMC exposes interfaces C, D and E. Interface C is used to configure allocation strategies which are used by the SMC in the first step of the selection process, to narrow down possible providers to a potential sub-network or cluster. Additionally once the potential cluster is selected workload distribution or node tasking preferences are accounted for e.g. nodes at the edges of the network should sense, intermediate nodes should only transmit and process. Interface D is used to configure selection and composition strategies. Once the potential cluster of providers is selected, the selection strategy selects a node from within said cluster. This is done by comparing the current battery level and sampling frequency provided by each node. Once the provider is selected composition strategies are used to determine the proper order of composition according to the composition pattern expressed in the strategy. E.g. For a request that involves a temp, average and data filter services, based on a Sequence pattern [14]: the resulting composition would first have the temp service then the data filter and finally the averaging service. The sequence pattern (aÆb) states that b is carried out after the completion of a. In [14] the authors further elaborate on the benefits of leveraging composition patterns to achieve significant benefits in the composition process. Interface E is used to introspect the SMC e.g. service requests being processed and their respective parameters. The SMC may in turn use the introspection interfaces of relevant SSCs and DPCs to obtain all requests being process by each one and their

100

P.J. del Cid et al.

respective annotated attributes. It is important to notice that this introspection provides the details on all current component dependencies and can be used to create a component graph. On each node the RM exposes interfaces 1,2,3 and every SSC/DPC expose interface 3 and 4. In the RM interface 1 provides access to resource reservation and memory management strategies (see section 3.6). In the RM interface 2 provides access to adaptation strategies (see section 3.5). In the RM interface 3 provides introspection of current resource allocations e.g. current static and dynamic memory allocations with all relevant request related information. In the SSC/DPC interface 3 provides access to requests being processed with all their respective configuration parameters and the annotated component attributes; which in essence describes all current component dependencies and when each dependency will expire. Expiration of a dependency depends on the duration of the service that required that dependency i.e. when the service terminates the dependency expires. This gives the admin valuable insight into current system configuration. Interface 4 provide access to the modification of annotated attributes hence potentially altering how the component’s functional code is executed and the outcome of strategy evaluation as described in section 3.5.

4 Middleware Implementation We implemented a prototype to validate our approach; it was implemented in Java ME CLDC1.1 configuration on the SunSPOT platform [10]. The implementation supports the operational scenario as described in section 2. To provide the reader with explicit background on our implementation we provide details of the evaluation conducted in the context of our previous work. This is described in more detail in [6] and is summarized below. We recorded relevant footprint information and run-time memory consumption in our middleware while executing the following use case: The HVAC back-end application requires that for service request 1, temperature is to be sensed every 30 minutes during the next 1 day, averages of samples for every 60 min. should be processed and the results should be made persistent. The tracking application requires that for service request 2 light readings be taken every 10 min. for the next 15 days, 120 min averages are processed and the results be made persistent. These service requests are submitted to the SMC and are depicted in Fig. 6A (as is not directly relevant to our scenario, we omit the specification of target location). The HVAC specialized component that determines AC related actions requires temperature readings every 10 min. for the next year. Since this specialized component is deployed on the node, it submits these parameters directly to the temperature SSC with the ProcessRequest@Temp1. The deployed tracking specialized component that determines product handling and tampering requires light and accelerometer readings every 5 min. for the next 5 days. This component submits these parameters directly to the corresponding SSC. In Fig.6B one can see the component configuration implemented and the service composition that resulted from the submitted service requests and process requests. Five service components are used to serve 5 concurrent requests which are fulfilled

Expressing and Configuring Quality of Data in Multi-purpose WSN

101

with 5 independent service compositions. As the number of served requests increases the amount of instantiated components remains constant. Each SSC consumes 750 bytes of dynamic memory and 7.8 Kb of static memory. Each DPC consumes about 750 bytes of dynamic memory and 11.9 Kb of static memory. Each additional service request processed in a SSC consumes about 5Kb of dynamic memory. Each additional request that runs in a DPC consumes about 800 bytes of additional dynamic memory. We then recorded footprint and run-time memory consumption for a comparable approach. We implemented the same use case with LooCI [15] component model. We selected this approach because of its very loosely coupled component interaction and published subscribe functionality provides effective mechanisms to implement multipurpose WSNs. It was necessary to instantiate 9 LooCI micro-components. Each LooCI component requires 3 Kb of dynamic memory and 1.7Kb of static memory.

Fig. 6. Implemented scenario

In Fig.6C we plotted the amount of dynamic memory (RAM) and static memory (ROM) required to instantiate the components needed to process concurrent requests with both approaches. We varied the amount of concurrent requests processed from n=1 to n=10. Each of these requests is equivalent in functionality as serviceRequest1. In terms of transmission overhead: One service request (order of 64 bytes) is needed to support an additional request, where in LooCI two new components are needed (each component is in the order of 1.7Kb). In terms of request load: The additional functionality offered in our components comes with some overhead in static memory which as one can see from Fig.6C is an acceptable trade-off given the improved efficiency under higher request loads.

5 Discussion In this section we further discuss how a separation of operational concerns allows for simpler WSN configuration while improving adaptability and customize-ability of the middleware. 5.1 Simpler WSN Configuration To elaborate on how the proposed middleware simplifies configuration we look at the manner in which the WSN is to be configured i.e. complexity of abstractions used and how operational concerns are accounted for. We consider that a clear separation of

102

P.J. del Cid et al.

operational concerns allows for simpler system configuration. We elaborate on the benefits for network administrators, application and service developers below. Application developers: In our system they only have to concern themselves with the implementation of business functionality. Our client API uses the service request specification to allow them to express their functional requirements only. They are not burdened with platform specific commands to implement sensing or processing services. They are not burdened with issues like selecting low consumption services to maximize network lifetime. The service request is easy to use and yet expressive enough to adequately address complex use cases as the one described in section 4. The service request specification does not require any coding or instantiation of runtime constructs. Furthermore, they can use application-specific components that implement extended business functionality and deploy them anywhere in the network and still access a simple and consistent API at node level. Service developers: Service implementation may be done by following the specified structure and behavior imposed by the SSC and DPC meta-types. Annotated attributes allow them to enhance the implementation with semantic information regarding relevant usage parameters, provided accuracy or energy consumption. These attributes can be easily extended to account for new requirements. In this way the service developer is not burdened with operational considerations e.g. what should be the offered data resolution given a particular battery level. Service developers do not require any domain specific or business knowledge. Network administrators: The network admin API gives them access to configure allocation, selection, composition strategies in the SMC, adaptation, resource reservation and memory management strategies in the RM. These strategies give the administrator the abstractions needed to define specific actions to be taken under changing system conditions that will result in compliance with expected quality levels and system lifetime as describe in section 3.5. In [9] Huygens et al. elaborate on the importance of providing the network administrator access to mechanisms that can influence the ensemble of running applications and thus fine-tune system functionality. The admin is able to execute his responsibilities without the burden of the implementation of business functionality or low level sensor programming. In our implementation, strategies are described with event condition action semantics in human readable form, facilitating comprehension and extension (see the code snippet below). In our model the network administrator is not restricted to use a specific notation. Using the provided interfaces she is able to evaluate and enact required adaptations. Event: If battery level > 80 Condition: for energy category = 2; Action: do maxSamplingFreq = 100;

The evaluation of these strategies is orthogonal to the running applications. This implies that network administrators need no a-priori knowledge of what applications will be using the WSN. Finding the extent of efficacy and the optimal strategies to provide the highest benefits in multi-purpose WSNs is the main focus of our future work.

Expressing and Configuring Quality of Data in Multi-purpose WSN

103

5.2 Adaptability and Customize-Ability of the Middleware Adaptability: Is the system’s capacity to enact context aware run-time reconfiguration. Strategies are the way one may express reconfiguration actions which account for contextual conditions. We provide the SMC and RM abstractions which enforce these strategies to achieve autonomic and lightweight run-time reconfiguration. The reconfiguration can be system-wide e.g. using allocation, memory management strategies (see sections 3.5 and 3.8) or fine-grained e.g. adaptation strategies (see section 3.5). The strategies are currently implemented using event condition action notation which can be easily understood and extended. E.g. currently component level adaptation is limited to restrict the sampling frequency to save energy but they may be easily extended to account for monetary costs or other factors. Introspection capabilities offered in the network admin API allow our system to provided run-time details on component dependencies and execution of all services; which is essential information in reconfiguration efforts. Customize-ability: Is the system’s capacity to fine-tune or extend its functionality during run-time without service interruption. As we discussed in section 3 our loosely coupled system allows for new services or additional clients to share a common pool of components without modification to any current service composition. The pool of components can be easily extended with the implementation of additional SSCs or DPCs with no modifications on existing services (see section 3.3). Applicationspecific functionality may be implemented and leverage the node level client API to achieve significant benefits from in-network processing. Furthermore a running application may have varying QoD requirements which can be easily expressed in the per-instance service request and transparently configured by the SMC (see sections 3.4 and 3.5).

6 Related Work In this section we discuss the previously highlighted benefits in the context of state of the art [1,4,5,11]. We considered approaches that contribute programming abstractions designed to provide application support in the context of multi-purpose WSNs. We narrowed the landscape further by selecting one approach from some of the more prominent models used in WSNs. These include: service oriented [1], modularized agent like abstractions [4], content-based publish-subscribe [5] and database oriented [11]. These approaches provide a high level abstraction that allows each application to express its QoD and non-functional concerns, a mediation layer to manage service selection and low level abstractions to expose network resource and allow these to be shared. All these approaches are designed to be application independent and all offer the possibility of specifying some QoD requirements per every query, request or subscription instance. In this context service requests, queries and subscriptions all serve the same functional purpose, expressing application interests and commonly specify: required service, the duration of the service, temporal resolution or sampling frequency and spatial resolution or target location. Access to WSN resources is offered as software services using code modularization, mainly implemented with component-like abstractions.

104

P.J. del Cid et al.

6.1 Configuration in State of the Art The main issue impacting configuration in these approaches is that they do not clearly separate operational concerns and they all rely on an all-knowing programmer. This programmer is expected to know low level platform specific programming and high level implementation of business functionality; this of course implies domain specific knowledge. Additionally they need to have in-depth knowledge about network monitoring and management. This of course is only feasible in research oriented WSN deployments but not for commercially viable WSN deployments. We will briefly elaborate on relevant differences of the evaluated approaches: Servilla [4] uses ServillaScript to express queries to be executed by the WSN, which requires the application developer to learn a scripting language similar to JavaScript. Additionally complexity arises because there is no notion of time in queries and application developers are expected to know how many transmission hops the query can execute, which is not easily estimated under changing conditions. Service specification requires the use of yet another programming language ServillaSpec which further burdens service developers. TinySOA [1] uses an extended event condition action syntax and a service oriented query model to specify service requests which is comparable to our service request specification but limited, service composition is not possible and deploying application-specific components is not discussed. TinyCOPS [5] uses subscriptions to specify service requests and leverages the concept of subscription meta-data to express quality requirements for each subscription. Expressing application requirement in terms of subscriptions is rather straight forward but limited, service composition is not possible and deploying application-specific components is not possible. TinyDB [11] uses SQL syntax to specify queries and related quality requirements. It offers a rather static view of the WSN since it abstracts away all functionality and presents it strictly as a database. Retrieving sensed information and executing aggregation or filtering processes is possible but the information is only accessible through a centralized user interface. 6.2 Adaptability and Customize-Ability in State of the Art The evaluated approaches are all designed strongly toward either a macroprogramming e.g. TinySOA, TinyCOPS, TinyDB or node-centric approach e.g. Servilla. The former are usually characterized by higher-level abstractions that focus mainly on the behavior of the entire network. Node-centric programming generally refers to programming abstractions used to express the application processing from the point of view of the individual nodes. Macro-programming approaches are usually characterized by abstracting away node level interactions which limits the customize-ability by restricting the possibility to deploy application-specific components in the network to leverage in-network processing and extend functionality. On the other hand node-centric approaches allow for the possibility of deploying application-specific components but lack some higher level abstractions to unburden application developers of implementing common use functionality e.g. having to realize service composition. Our approach provides both,

Expressing and Configuring Quality of Data in Multi-purpose WSN

105

high level abstractions e.g. the SMC and node-centric abstractions e.g. the RM and annotated components. This allows our middleware to provide both: high-level functionality e.g. service composition and fine-grained control e.g. component level adaptation. None of the evaluated approaches [1,4,5,11] provide abstractions to enable modification or extension of reconfiguration actions or introspection into run-time behavior. Our approach provides system strategies that inform reconfiguration actions both at system level and at node level and introspection of component dependencies, allocated requests with their respective parameters. We briefly comment on the more relevant differences in each of these approaches: TinyCOPS [5] only offers a notion of control information with soft semantics to inform subscriptions but it is not really clear to what extent this could influence runtime reconfiguration and it is left up to the application developer to determine the control information to be used. It offers Service Extension Components (SEC) which can be used to extend functionality to meet application-specific functionality. However these components cannot locally interact with other services, they need to subscribe to receive events of interest with a centralized broker, limiting the possibility of composition. Servilla [4] offers direct access to services on nodes through the implementation of tasks, these tasks implement application-specific functionality. They offer support for discovery, matching and binding but the application developer is left to realize any needed service compositions. Using ServillaSpec the service developer can enhance service descriptions with semantic information but this is only used during the service matching process not to inform system reconfiguration. In TinySOA [1] the extension of functionality is possible by implementing new services. However no support for run-time reconfiguration or service composition e.g. sense, aggregate and persist is offered. TinyDB [11] exposes the WSN as strictly a database. They offer support for service composition which offers the possibility to request sensor data, aggregate or filter it. However the approach does not provide the possibility to add services at runtime or to deploy application-specific components and leverage in-network processing.

7 Conclusion This paper presented a lightweight, component-based service platform for WSN. We argue in favor of per-instance run-time configuration of QoD attributes and we demonstrate how our approach leverages per-instance QoD configuration and a separation of operational concerns to achieve simpler configuration and improve adaptability and customize-ability of the WSN. In the short term we plan to record a baseline of resource usage under concurrent use and varying system loads. We will identify key QoS attributes that may be representative of global system state. In the long term we plan to further investigate and thoroughly evaluate system strategies for multi-purpose WSN.

106

P.J. del Cid et al.

Acknowledgments. The Research for this paper was partially funded by IMEC, the Interuniversity Attraction Poles Programme Belgian State, Belgian Science Policy, and by the Research Fund K.U. Leuven for IWT-SBO-STADIUM [16].

References 1. Rezgui, A., Eltoweissy, M.: Service-oriented sensor–actuator networks: Promises, challenges, and the road ahead. Computer Communications 30, 2627–2648 (2007) 2. Basaran, C., Kang, K.: Quality of Service in Wireless Sensor Networks. In: Guide to Wireless Sensor Networks, Computer Communications and Networks. Springer, Heidelberg (2009) 3. Murphy, A., Heinzelman, W.: MiLAN: Middleware Linking Applications and Networks, TR-795, University of Rochester, Computer Science (November 2002) 4. Fok, C., Roman, G., Lu, C.: Enhanced Coordination in Sensor Networks through Flexible Service Provisioning. In: Field, J., Vasconcelos, V.T. (eds.) COORDINATION 2009. LNCS, vol. 5521, pp. 66–85. Springer, Heidelberg (2009) 5. Hauer, J., Handziski, V., Kopke, W., Wolisz, A.: A component framework for contentbased publish/Subscribe in sensor networks. In: Verdone, R. (ed.) EWSN 2008. LNCS, vol. 4913, pp. 369–385. Springer, Heidelberg (2008) 6. del Cid, P.J., et al.: Middleware for Resource Sharing in Multi-purpose Wireless Sensor Networks. In: IEEE Proc. NESEA 2010, China (November 2010) (in press) 7. Yu, Y., Rittle, L.J., Bhandari, V., LeBrun, J.: Supporting concurrent applications in wireless sensor networks. In: ACM Proc. of Sensys 2006, New York, NY, USA, pp. 139– 152 (2006) 8. Steffan, J., Fiege, L., Cilia, M., Buchmann, A.: Towards multi-purpose wireless sensor networks. In: International Conference on Sensor Networks (August 2005) 9. Huygens, C., et al.: Streamlining development for Networked Embedded Systems using multiple paradigms. IEEE Software 27(5), 45–52 (2010) 10. SunSPOT, http://www.sunspotworld.com/ (visited July 2010) 11. Madden, S., Hong, W.: TinyDB: An Acquisitional Query Processing System for Sensor Networks. ACM Transactions on Database Systems 30(1), 122–173 (2005) 12. Sykes, D., Heaven, W., Magee, J., Kramer, J.: Exploiting Non-Functional Preferences in Architectural Adaptation for Self-Managed Systems. In: SAC 2010, March 22-26, ACM, New York (2010) 13. Lachenmann, A., Marron, P.J., Minder, D., Rothennel, K.: Meeting Lifetime Goals with Energy Levels. In: ACM Proc. of SenSys (2007) 14. Hu, H., Han, Y., Huang, K., Li, G., Zhao, Z.: A Pattern-Based Approach to Facilitating Service Composition. In: Jin, H., Pan, Y., Xiao, N., Sun, J. (eds.) GCC 2004. LNCS, vol. 3252, pp. 90–98. Springer, Heidelberg (2004) 15. Hughes, D., et al.: LooCI: A Loosely Coupled Component Infrastructure for Embedded Network Eccentric Systems. In: ACM Proc. of MoMM 2009, Kuala Lumpur (2009) 16. IWT Stadium project 80037, http://distrinet.cs.kuleuven.be/projects/stadium

A Lightweight Component-Based Reconfigurable Middleware Architecture and State Ontology for Fault Tolerant Embedded Systems Jagun Kwon and Stephen Hailes Department of Computer Science University College London, Gower Street, London, WC1E 6BT, UK {j.kwon,s.hailes}@cs.ucl.ac.uk

Abstract. In this