Sensor Applications, Experimentation, and Logistics (LNICST 29)

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

29

Nikos Komninos (Ed.)

Sensor Applications, Experimentation, and Logistics First International Conference, SENSAPPEAL 2009 Athens, Greece, September 25, 2009 Revised Selected Papers

13

Volume Editor Nikos Komninos Athens Information Technology Markopoulos Ave., P.O. Box 68 19002 Peania, Athens, Greece E-mail: [email protected]

Library of Congress Control Number: 2009943737 CR Subject Classification (1998): I.2.9, C.2, K.4.4, C.2.1, J.3, K.4.2, K.8 ISSN ISBN-10 ISBN-13

1867-8211 3-642-11869-0 Springer Berlin Heidelberg New York 978-3-642-11869-2 Springer Berlin Heidelberg New York

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. springer.com © ICST Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering 2010 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper SPIN: 12990566 06/3180 543210

Preface

Wireless sensor networks (WSNs) are envisioned to enable a variety of applications including environmental monitoring, building and plant automation, homeland security and healthcare. It has been argued that one of the key characteristics of sensor networks is that they are tightly coupled with the applications running on top of them. Although WSNs have been an active area of research for over a decade, real world sensor network deployments have not yet found their way to widespread adoption. The experience gained and lessons learned during the initial attempts to deploy WSNs and implement various sensor network applications are very valuable for the advancement of this technology. Recognizing the need of a conference dedicated to practical aspects of WSN pertaining to their employment in a plethora of applications, ICST launched SENSAPPEAL as a yearly event whose first edition took place in September 2009 at the Athens Information Technology campus in the outskirts of Athens, Greece. The First International Conference on Sensor Networks Applications, Experimentation and Logistics (SENSAPPEAL 2009) brought together researchers and developers from academia and industry that presented their work and shared their experiences with developing, deploying and testing WSN applications. More specifically, the technical program of SENSAPPEAL 2009 included presentations on a wide variety of WSN applications in wild fire detection and tracking, agriculture, water quality monitoring, people tracking for psychological experiments and smart management of the human environment. Other presentations addressed a number of issues in application development and WSN deployment such as application portability, in-field sensor reprogramming and software updates, overcoming network protocol stack compatibility issues, the impact of weather conditions on sensor communications in outdoors environments and the development of an IP capable sensor node with off-the-self hardware and software components. Moreover, the development of an open large-scale WSN testbed which can be used for testing networks protocols and applications was introduced to the conference attendees. The international nature of the conference was reflected in the geographical diversity of the authors: Belgium, Cyprus, France, Germany, Greece, Ireland, The Netherlands, Spain, Sweden, Switzerland, the UK, and the USA. The keynote address at SENSAPPEAL 2009 entitled “Wireless Innovations as Enablers for Complex and Dynamic Large Artificial Systems” was delivered by AIT Professor Gregory S. Yovanof. In his presentation Prof. Yovanof provided a comprehensive overview of current technological developments and research projects in the field of wireless communications which will lead to the not-so-distant reality of the “Internet of things.” SENSAPPEAL 2009 was a one-day conference which included one keynote speech and four technical sessions. There were 12 papers presented at the conference, one of which was an invited paper. The conference received 24 paper submissions. After a thorough review process, 12 papers were accepted bringing the acceptance rate to

VI

Preface

50%. One accepted paper was withdrawn by the authors and was replaced by an invited paper. In conclusion, we are very encouraged by the acceptance of this conference by the academic community and strongly believe that SENSAPPEAL will grow to become a well-recognized event in the field of WSNs and their applications.

Spyros Vassilaras

Organization

General Chair Spyros Vassilaras

Athens Information Technology, Greece

Steering Committee Imrich Chlamtac (Chair) Yannis Paschalidis

University of Trento, ICST, CreateNet, Belgium Boston University, USA

TPC Chair Athanassios Boulis

National ICT Australia (NICTA), Australia

Conference Coordinator Barbara Török

ICST

Local Organizations Chair Sofoklis Efremidis

Athens Information Technology, Greece

Publicity Chair Neeli Prasad

Aalborg University, Denmark

Publications Chair Nikos Komninos

Athens Information Technology, Greece

Demo and Exhibits Chair Vassilis Veskoukis

National Technical University of Athens, Greece

Sponsors Chair Vana Kalogeraki

Athens University of Economics and Business, Greece

VIII

Organization

Web Chair Savvas Gitzenis

CERTH-ITI, Greece

Technical Program Committee Hamid Asgari Subhash Challa Hui Chen Chun Tung Chou Nikolaos Doulamis Gianluigi Ferrari Savvas Gitzenis Wen Hu Salil Kanhere Kyriakos Karenos Yannis Kotidis Keyong Li Dimitrios Lymberopoulos Elias S. Manolakos Luca Mottola Sarfraz Nawaz Saikat Ray Andreas Savvides Curt Schurgers Yannis Stamatiou David Starobinski Vlasios Tsiatsis Michalis Vazirgiannis Christos Verikoukis Vassilios Vescoukis Thiemo Voigt Matthias Woehrle

Thales Research and Technology, UK NICTA, Australia Virginia State University, USA University of NSW, Australia National Technical University of Athens, Greece University of Parma, Italy CERTH-ITI, Greece CSIRO, Australia University of NSW, Australia IBM Research, USA Athens Universiy of Economics and Business, Greece Boston University, USA Microsoft, USA University of Athens, Greece Swedish Institute of Computer Science, Sweden University of Oxford, UK Ericsson, USA Yale University, USA University of California San Diego, USA University of Ioannina and Research Academic Computer Tech. Inst., Greece Boston University, USA Ericsson, Sweden Athens University of Economics and Business, Greece CTTC, Spain National Technical University of Athens, Greece Swedish Institute of Computer Science, Sweden ETH Zurich, Switzerland

Table of Contents

Wireless Sensor Network Application for Fire Hazard Detection and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Elias S. Manolakos, Evangelos Logaras, and Fotis Paschos Fire Detection and Localization Using Wireless Sensor Networks . . . . . . . Alireza Khadivi and Martin Hasler Design and Implementation of a Wireless Sensor Network for Precision Horticulture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Juan A. L´ opez, Fulgencio Soto, Andr´es Iborra, Pedro S´ anchez, and Juan Suard´ıaz A Nephelometric Turbidity System for Monitoring Residential Drinking Water Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Theofanis P. Lambrou, Christos C. Anastasiou, and Christos G. Panayiotou Deployment of a Wireless Ultrasonic Sensor Array for Psychological Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Roland Cheng, Wendi Heinzelman, Melissa Sturge-Apple, and Zeljko Ignjatovic WISEBED: An Open Large-Scale Wireless Sensor Network Testbed . . . . Ioannis Chatzigiannakis, Stefan Fischer, Christos Koninis, Georgios Mylonas, and Dennis Pfisterer SmartEN: A Marie Curie Research Framework for Wireless Sensor Networks in Smart Management of the Human Environment . . . . . . . . . . Toula Onoufriou, Anthony Constantinides, Anastasis Kounoudes, and Antonis Kalis

1

16

27

43

56

68

88

Software Update Recovery for Wireless Sensor Networks . . . . . . . . . . . . . . Stephen Brown and Cormac J. Sreenan

107

A Framework for Time-Controlled and Portable WSN Applications . . . . . Anthony Schoofs, Marc Aoun, Peter van der Stok, Julien Catalano, Ramon Serna Oliver, and Gerhard Fohler

126

Embedded Web Server for the AVR Butterfly Enabling Immediate Access to Wireless Sensor Node Readings . . . . . . . . . . . . . . . . . . . . . . . . . . . Konstantinos Samalekas, Evangelos Logaras, and Elias S. Manolakos

145

X

Table of Contents

Low-Power Radio Communication in Industrial Outdoor Deployments: The Impact of Weather Conditions and ATEX-Compliance . . . . . . . . . . . . Carlo Alberto Boano, James Brown, Zhitao He, Utz Roedig, and Thiemo Voigt TinySPOTComm: Facilitating Communication over IEEE 802.15.4 between Sun SPOTs and TinyOS-Based Motes . . . . . . . . . . . . . . . . . . . . . . Daniel van den Akker, Kurt Smolderen, Peter De Cleyn, Bart Braem, and Chris Blondia Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

159

177

195

Wireless Sensor Network Application for Fire Hazard Detection and Monitoring Elias S. Manolakos, Evangelos Logaras, and Fotis Paschos National and Kapodistrian University of Athens Department of Informatics and Telecommunications Panepistimioupolis, Ilissia, 15784 Athens, Greece {evlog,eliasm}@di.uoa.gr

Abstract. Hazard detection systems are sophisticated tools that can help us detect and prevent environmental disasters. The role of a well designed environmental hazard detection system based on a Wireless Sensor Network (WSN) is to continuously monitor and report the environment’s status by sampling relevant physical parameters (e.g. temperature), but at a rate that can be adapted dynamically to the criticality of the current situation, so that precious energy is conserved as much as possible and communication bandwidth is not wasted, both preconditions that need to be met for a scalable WSN application. We have designed and built a small-scale prototype of such a WSN system for fire detection and monitoring based on inexpensive in-house developed wireless sensor nodes. These nodes combine an AVR Butterfly microcontroller demonstration kit with an Xbee wireless Zigbee transceiver. The emphasis of the work reported here is on the software designed for the fire hazard detection application. We discuss the embedded computing strategy developed for the in-field sensor nodes that allows them to adjust their mode of operation (i.e. their sampling and reporting rates) dynamically and in an autonomous manner depending on the area prevailing conditions. We also discuss the functionality of the software running on the central node (PC) that is used to initialize the WSN system, synchronize nodes, monitor their status by maintaining an active registry, adjust parameters at any time, inspect real-time plots of the incoming temperature reports of selected nodes to monitor emerging trends and patterns etc. Several examples of the end-to-end system’s use are also presented and discussed. Keywords: Fire hazard detection, wireless sensor network, embedded systems AVR Butterfly, Zigbee.

1 Introduction Significant advances in embedded hardware and software technologies are driving down rapidly the cost of Wireless Sensor Networks (WSN) and allow large-scale WSN deployments for environmental monitoring applications to become a reality. There exist already several ongoing WSN projects in Europe and worldwide for assessing habitat changes, monitoring the evolution or predicting the risk of catastrophic phenomena such as floods [1], fires [2], earthquakes [3], volcano eruptions [4], etc. N. Komninos (Ed.): SENSAPPEAL 2009, LNICST 29, pp. 1–15, 2010. © Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering 2010

2

E.S. Manolakos, E. Logaras, and F. Paschos

Modeling wildfire behavior is a very challenging problem due to, among other reasons, the large number of time-varying parameters governing this complex phenomenon. However, since it is a very useful tool for fire management, significant efforts have been devoted over the last decade towards the development of effective fire evolution prediction models [5], [6]. In most cases, these models are designed to simulate fire spread and estimate linear intensity and flame length, but not temperature. In few cases, especially for modeling crown fire initiation, certain models have proposed sound algorithms to predict, for example, the time-totemperature profiles above a spreading flame front [7]. However, since low cost digital temperature sensors (that can measure usually up to ~120 oC) have become commodity items, it becomes feasible to deploy WSN based systems for distributed fire detection and monitoring. Such a system can contribute to the on-time fire detection via distributed signal processing and data fusion algorithms and also help us calibrate periodically computer models used to predict the evolution of a fire front under different prevailing wind conditions in the affected area. These capabilities can be particularly important in the so called Wildland Urban Interface (WUI) regions surrounding our modern cities, where the catastrophic impact of a rapidly spreading fire can be tremendous to human lives and property, as it has been recently experienced in Australia, Los Angeles CA, USA and Athens, Greece. Fire spread modeling depends on many factors, such as ground morphology, combustion fuel, moisture and most importantly on the wind speed and direction which may be changing rapidly. Nevertheless, there exist several software tools (such as FARSITE [8], FSE [9] etc.) that consider a geographical region of interest as a grid of “cells” and use algorithms to predict for every cell the time of arrival of the front of an erupted fire.. They are almost all based on the seminal work of Rothermel [10] which, given the type of fuel and the wind conditions, can estimate several local fire related properties, such as the flame length, fire intensity, etc for each cell when visited by the evolving fire front. We have developed and present here a WSN-based end-to-end system prototype for reliable fire hazard detection and notification. Our system is based on really inexpensive sensor nodes developed in-house by students, combining an AVR Butterfly (BF) demonstration kit [11] with an XBee (XB) [12] ZigBee [13] wireless transceiver [12] on the same PCB (Printed Circuit Board). The BF is equipped with an Atmel Mega169 [16] 8-bit microcontroller with 16KB flash memory. The embedded software design allows for each sensor node to utilize different sampling and reporting rates depending on its current mode of operation (related to the assessed criticality of the detected event). This choice maximizes system alertness while also minimizing power consumption, which is an important parameter for outdoor WSN environmental monitoring type applications. Sensor nodes can change modes of operation, either autonomously, depending on the sensed temperature, or under operator control. An end-to-end fire monitoring application has been developed and tested in which a software component running at the host-PC can be used to monitor the status of the WSN, initiate and terminate sensor nodes operation, log received temperature reports, plot the reported values from selected nodes in real-time, issue commands to change the mode of operation or the parameters of selected nodes, identify nodes that got silenced or return back to operation after a silence period etc.

Wireless Sensor Network Application for Fire Hazard Detection and Monitoring

3

The prototype we have developed and tested was certainly small-scale, but the embedded software running on each node has been designed and implemented in embedded C and with a larger scale application in mind. If a wide-area WSN of temperature sensors is deployed in a field, it becomes feasible to use it as a mechanism to calibrate periodically fire spread prediction computer models (such as those implemented in FSE, FARSITE etc) and improve substantially their prediction performance. To achieve this goal we need to be able to correlate periodically temperatures reported by in field sensors with temperature predictions generated by computer simulation models for the same location and time step. However, the fire spread simulators give us only the spatiotemporal field of fire related parameters (e.g. flame length or fire intensity). To bridge the gap we have also developed a statistical signal processing method that allows us to transform the flame length field into a corresponding expected temperatures field for the same area [14]. This estimated temperatures field can now be compared to the WSN node temperatures field and the data assimilation system loop be closed by adjusting the predictive model parameters accordingly in order to reduce the prediction error. This work has been performed during our participation to the SCIER project [15], co-funded by the European Commission under the 6th framework of R+TD. The rest of the paper is organized as follows: In Section 2 we present the sensor nodes architecture and functionality. We also present briefly the in-house hardware design of the sensor node and then in more detail the node’s operation modes, the possible transitions and the embedded software design. In Section 3 we shift our attention to the design of the central node that controls the network and discuss the capabilities of a user friendly GUI tool developed for this purpose. In Section 4 we present representative cases of the use of the system in the field with data collected during our application field testing. Finally our findings are summarized and work in progress is outlined in Section 5.

2 Sensor Node Design 2.1 Sensor Node Hardware We describe next the 2-layer PCB that we have developed in house to host the AVR BF and the XB modules and construct a low cost WSN node. The communication between the XB and the BF is achieved through an RS-232 serial connection. There is also an RS-232 serial port on the board through which a PC connection can be established. The serial connection can be active between the XB and BF or the BF and the PC. On board jumpers determine each time the connection mode. The BF can be programmed and exchange data with a PC through this port. A 9V battery is packed with the board to supply power. External power is an option too, but does not favor portability. The sensor node is extensible since the user has access to two 8-bit I/O ports of the AVR microcontroller through appropriate connectors on the board. The microcontroller [16] is equipped with an 8-channel 10-bit ADC unit which is used for temperature sampling and a UART unit which implements the RS-232 serial communication with the XB module and the PC. A 512 bytes EEPROM and an 1KB

4

E.S. Manolakos, E. Logaras, and F. Paschos

SRAM memory are available on-chip, while the clock rate can reach up to 16MHz providing an 1MIPS/MHZ processing power. For the needs of our project the AVR chip was clocked at 8MHz. 2.2 Sensor Node Modes of Operation The main tasks of the sensor node are: a) to collect temperature samples according to a predefined sampling period (SP) and b) to send the collected data back to the central node of the network according to a reporting period (RP). These two time periods are defined independently by the user, but the RP must be greater than the SP. Several samples may be collected and processed by the node, before a report (usually a summarizing statistic) is sent to the main node.

Fig. 1. The PCB of the wireless sensor node that includes an AVR Butterfly kit and an XBee ZigBee transceiver

The proper selection of the aforementioned period times is critical to the power dissipation of the node. For our application it is more power efficient to process a small number of samples and send a summarizing statistic to the central node since sending all measurements would drain the battery of the nodes and lead to network congestion. The AVR microcontroller on the sensor node is able to handle major processing tasks while in the same time sustaining a low power profile with its sleep mode features. The software of the sensor node is handled by the BF and the communication with the XB module is achieved through serial RS-232 connection between the two devices. The SP of the node must be adapted to the conditions in which is exposed, e.g. small SP on days with high temperatures.

Wireless Sensor Network Application for Fire Hazard Detection and Monitoring

5

The sensor node has 4 operation modes (states) which are: − Initialization Mode (I): In

this state the central node performs initialization tasks on the network (e.g. sensor node discovery and registration etc.). − Low Risk Mode (LR): the node transits to this state after the initialization mode, when there is no obvious fire hazard and the sampling and reporting periods have their maximum values. − High Risk Mode (HR): When several temperature samples are higher than a predefined threshold (called Low Risk Maximum Temperature Threshold, LR_MAXT), the node transits to this mode and the time periods (report and sampling) become smaller. If the temperature falls quickly below the threshold, then we had a false alarm and the node transits back to Low Risk Mode. Emergency Mode (EM): if the temperature continue to rise above the next predefined threshold (called High Risk Maximum Temperature Threshold, HR_MAXT), then the node transits to this mode, where a fire in the region is considered a certainty. The sampling and reporting periods get their minimum value. The central node must be aware of the state of each sensor node, so every time a sensor node changes its state, it informs the central node with a report message.

Fig. 2. The Statechart of the operation of the sensor node

6

E.S. Manolakos, E. Logaras, and F. Paschos

Fig. 3. The temperature range and associated thresholds of each mode of operation

The system operator may manually change the state of a sensor node or the value of the temperature thresholds and periods by issuing instruction messages to the network or to any individual node through the central node. The sensor node is able to receive these messages and reply back to the central node with reporting messages about its current state and the measured temperature. In Figure 2 can see that the first operation in the main loop that is being executed by the BF is to check for any incoming command messages. After that the node executes its normal operations, which are temperature sampling and reporting of a statistic of collected measurements. There is also a time service routine, that interrupts the main loop once every second and is used for time counting. In Figure 4 we can see the possible transitions between the operation modes of the sensor node. The conditions triggering a mode transition are shown on the edges.. The transitions depicted with dashed lines are initiated by an instruction message from the central node. After the initialization mode the node transits to the Low Risk Mode and starts taking temperature samples. The node can return to initialization mode only if the central node has sent the proper initialization mode instruction message. Every other transition occurs according to how the maximum value of the collected temperature samples compares to and the temperature thresholds shown in Fig. 3 at the end of a reporting period (RP). It is possible to use a different statistic (e.g. the median or the mean value) but the MaxValue has been found more effective in conducted experiments. The node can also be set up so that an immediate transition to the appropriate mode is performed as soon as an out of range sample is collected. This more reactive type of operation minimizes the system response delay at the expense of increasing its energy consumption (due to more mode transitions per unit time on average). There is also the case where the user forces a node to transit to a desired mode through a proper instruction message issued by the central node. These transitions are indicated with dashed arrowed lines in Figure 4.

Wireless Sensor Network Application for Fire Hazard Detection and Monitoring

7

Fig. 4. The FSM describing sensor node modes and possible transitions

3 Central Node Design and Operations The central node needs extra processing and storing capabilities than the AVR microcontroller on the sensor node can support. The solution that we adopted was to bundle together a sensor node and a PC into a central node. The central node, from a hardware aspect, is similar to the sensor node and uses its serial port to connect to the PC. The XB module is connected directly to the serial port while the AVR microcontroller is not used. The operator of the network, communicates with the sensor nodes through a GUI software tool running on the PC. The hardware of the central node’s board acts like a gateway between the RS-232 protocol used for communication with the PC and the ZigBee protocol used for wireless communication with the sensor nodes of the network. As mentioned earlier, the operator has the ability to issue instruction messages through the central node to the sensor nodes. The reception and execution of an instruction message is the first action in the main loop of the sensor node as indicated

8

E.S. Manolakos, E. Logaras, and F. Paschos

by the StateChart of Figure 2.The purpose of these messages is to change on demand the operation mode (state) or the value of one of the parameters that affect the functionality of the sensor nodes (e.g. the temperature thresholds). We have defined a messaging scheme that is implemented on top of the ZigBee protocol, which uses its own predefined messaging system. All the details about routing and addressing messages to the network are handled by the ZigBee protocol, which is realized on each node by the XB device. Our messaging scheme is realized by the software running on the AVR microcontroller on each node. As every message transmitted over the network, the instruction messages have a unique message identification code (which is 0x04) followed by the code of the parameter to be updated and its new value that the user wants to assign. The instruction messages may be broadcasted to all sensor nodes or addressed to specific nodes only. As mentioned, the addressing mechanism is handled by the ZigBee protocol. Table 1. The message format of an instruction sent by the central node to sensor nodes

Instruction code

Parameter code

Parameter value

0x04

Code of the parameter we want to change 1 byte

New value of the parameter 1 byte

1 byte

The most important tunable parameters a sensor node uses are the temperature thresholds and its current mode of operation. They are initialized by the central node who can also update them during the system’s operation, Other parameters are the address of the node and the current time (relatively to a global time reference). The PC connected to the central node keeps track of all the sensor nodes connected to the network. The topology of the nodes is a logical star network, since all the instructions and reports are transmitted from or received at the central node. When the central node must communicate with a sensor node that is out of its immediate range, the message may reach this remote node through multi-hopping , assuming that each sensor node in the network (including the gateway) is within range of at least one other node,. This routing scheme is supported by the ZigBee protocol and is suitable for outdoor WSN applications with a large number of sensors. The main functions of the central node are listed below: − Network initialization: after its activation, the central node starts tracking all the available sensor nodes. For each node discovered, the central node registers its address. The ZigBee protocol defines the global (64-bit) and the network (16bit) address for each network node. The global address is unique and assigned by the manufacturer of each ZigBee transceiver. The network address may be changed dynamically during the operation of the network. In our application we chose to assign our own addresses to the sensor nodes and avoid retransmission of large bit sequences of the global or the network address. Each node discovered is assigned a decimal number as its node address, starting from 0. Every address is associated to the global address of the node’s XBee module. After the registration of the all available sensor nodes, the central node

Wireless Sensor Network Application for Fire Hazard Detection and Monitoring

−

− − −

9

broadcasts the current time, so every sensor node is properly synchronized. Upon reception of the time reference, all the sensor nodes transit to the Low Risk mode and start sampling their environment. Data acquisition: At the end of an RP, the central node accepts report messages from all the active sensor nodes and stores them to the PC memory. The frequency of reception of these messages depends on the mode of operation of each sensor node and is an adjustable parameter. Temperatures plotting: The GUI software running on the PC can plot in real time the temperatures reported by selected active nodes. Data storing: All temperature reports received by the central node as well as the current mode information of each node are stored in files on the PC for further processing. Network surveillance: The central node periodically tracks all the active sensor nodes and updates a registry every time a new node becomes active or an active node becomes inactive or gets out of range. If new nodes are added to the network the central node must initialize them without affecting the operation of the other nodes.

3.1 Central Node GUI Design All the software of the central node is running in the PC connected to the XB module, in contrast with the sensor node where the software is running on the AVR microcontroller. For the development of the central node software we chose Matlab [17]. One of the main advantages of this choice, was the ease of development of the GUI. Through Matlab we gain access to the serial ports of the PC and so we could easily produce and send any kind of data to the attached devices, the XB module in our case. The XB has its own microcontroller which accepts instructions through its serial port in the form of AT commands. The Matlab code constructs these commands and sends them through the serial port to the XB. The main task of the central node, except the initialization of the network, is the reception of the reporting messages from the sensor nodes and their display in real time using the GUI, so that the user can easily understand the state of the network (measured temperatures and active nodes). The central node must be constantly aware of all the available active nodes on the network, so the creation of a sensor node registry was essential. Upon activation of the network, the central node records the address (global address) and the parameters of all the active nodes. Also there is a record for each node with all the reporting messages it has sent. This information is available to the user anytime s/he wishes to inspect it. Integration of new nodes is possible after the activation of the network, since the central node searches periodically for changes in the structure of the network. Also, all the nodes send a confirmation message back to the central node upon reception of an instruction message. So the central node becomes aware of non-responding nodes and can refresh accordingly its registry. During a fire it is known that a sensor node may exhibit periods of silence without necessarily been burned, so it is important to be able to dynamically reintegrate such nodes into the network as soon as they become available.

10

E.S. Manolakos, E. Logaras, and F. Paschos

Fig. 5. The Graphical User Interface (GUI) used to control and monitor the system’s operation

In Figure 5 we can see the GUI of the central node that we have developed. In the upper left corner there is the button that connects the central node to the network. Also we can choose the serial port of the PC where the XB module is connected. In the “Report History” window there is an active listing of all the reporting messages received from the sensor nodes, while in the “Operation Status History” window messages can be found about the network operations. The user can inspect and change the parameters of any sensor node through the “Node Information” and “Parameters” windows. The node selected through the “Node” tab in the “Set Active Node” window is the receiver of all the instruction messages transmitted by the central node. We can see that there is also an option for broadcast-type transmission to all nodes. The current values of all the parameters of the selected node are presented in the “Node Information” window. All the tunable parameter names and codes are presented in the “Parameters” window. The user can update the default values for each parameter of the selected node. An important parameter for each node is also its current mode, which the user-operator can also change if so desired, by altering the value of the “CM” parameter. In the “Node Information” window the

Wireless Sensor Network Application for Fire Hazard Detection and Monitoring

11

current temperature threshold parameter values for the selected sensor node are given in degrees Celcius and the periods (sampling and reporting) in seconds. As we see the periods get smaller as the node transitions from the Low Risk towards the Emergency Mode. Other important buttons in Figure 5 are the “Synchronize Nodes” button with which the user can assign the current time to all sensor nodes of the network. Also, the user can force the sensor node registry to be updated through the use of the “Check Online Nodes” button. Updating the sensor node mode and discovering changes in the active nodes set are two operations performed periodically by the system which could, however, been forced by the user-operator at any time through the central node, if so desired. The two graphic windows at the bottom display the current and past temperatures of any two nodes on the network. The left window displays the temperature of the selected node through the “Set Active Node” window, while the right window displays information about the node selected through the tab just above it. This is useful when the user-operator wants to visually inspect or report differences in realtime between a reference node and some other node. The user can also be informed about the time that every temperature report was generated and about the time a mode transition occurred in the selected node. Mode transitions are marked with colored vertical lines (entering LR, HR, ER modes with green, yellow, red color respectively).

4 Application Field Testing Now that the functionality of the central and the sensor nodes has been described we can provide some examples of the system’s testing in the field. The area where the system will be deployed is a very critical factor because it affects the communication range of the nodes. According to the datasheet of the XB module, in open areas this range can be up to 100m, while in urban areas the range is limited to approximately 30m. Keeping in mind the way the ZigBee protocol defines communication paths and routes messages through multi-hopping, in order to reach far nodes of the network every node must have in its range at least one other node and so their distance must be less than 30m. Upon its placement every sensor node must be activated through the buttons provided on the BF module. After the activation of the sensor nodes, the network is controlled by the GUI of the central node. If there are no isolated or malfunctioning nodes then the central node must discover all the sensor nodes and report them to its GUI and the registry. The user must initialize the network through the “Initialize Nodes” button. In this way every sensor node is assigned an address (which is associated to the global address of its XB module). Then the “Synchronize Nodes” button must be activated in order to provide the correct time information to all nodes. If the user wants to add new nodes to the network after its activation, then s/he has to press the “Check Online Nodes” button in order to update the registry of the central node. If the user wants to remove a node from the network, again the “Check Online Nodes” button has to be pressed and the central node will mark this node as offline in the registry. The central node checks periodically for new online or offline nodes, but as described above the user can also force this procedure at anytime.

12

E.S. Manolakos, E. Logaras, and F. Paschos

Fig. 6. Temperature reports received from a remote sensor node after a steep rise of its temperature. We observe the fast transition from Low risk to Emergency mode where the reporting period is much smaller. As the node cools down it enters the High Risk and finally the Low Risk mode and the reporting period is adjusted automatically back to normal.

If the user wishes to shutdown the network, then s/he must force all the sensor nodes to transit to initialization mode. In this way the nodes stop transmitting temperature reports, thus saving energy resources and are also in the proper state for a possible future reactivation of the network. We can now present some usage scenarios of the system in real conditions. All reported tests took place at the University of Athens campus in the area surrounding our Department. In Figure 6 we raised the temperature of a sensor so that it transits directly from Low Risk to Emergency mode. The default RP in Low Risk Mode is 60 seconds, but if a sample exceeds the HR_MXAT threshold value, then the node immediately transits to Emergency mode. Same rule applies if a node has to transit from Low Risk to High Risk Mode. We can see that the RP is reduced to 15 seconds after the transition to Emergency mode (red vertical line) and then gradually transits to High Risk (30 seconds RP) and finally to Low Risk mode.

Fig. 7. Temperature reports received from a remote sensor node while increasing its temperature gradually and then cooling it down. Mode transitions are marked with vertical lines.

Wireless Sensor Network Application for Fire Hazard Detection and Monitoring

13

In Figure 7 we can clearly see that the remote sensor node passes from all the modes, of operation as the temperature gradually increases (yellow line for entering High Risk mode and red line for entering Emergency mode). Then again as we decrease the temperature the node returns back to Low Risk mode (green line) and the SP increases back to normal.

Fig. 8. Sensor node forced to enter the High risk mode returns back to Low Risk mode after confirming that the forced action is not supported by local temperature sampling

In Figure 8 we can see a situation in which while a node operates at the Low Risk mode and without any appreciable change in the sensed temperature from its environment it is forced to change its mode to High Risk, because the user-operator has sent it the corresponding instruction message using the GUI of the central node. This may have happened because the operator has already some reports from neighboring sensors entering the HR mode. We also see, however, that the node transits back to Low Risk mode at the end of the RP, since its local temperature measurements did not justify remaining for longer at the forced High Risk mode. We have also mentioned that through the GUI the user can observe graphically and in real-time simultaneously the reports received by two nodes, through the two graphical windows shown at the bottom of the GUI (see Figure 5). In Figure 9 we can observe the temperature reports of two different nodes. We can see that every node is reporting back to the central node with each own reporting period (depending on its

Fig. 9. Temperature report of two nodes presented in the GUI in real-time. The nodes are synchronized with the central node and use a common timeline.

14

E.S. Manolakos, E. Logaras, and F. Paschos

mode), while the GUI can track and present in parallel all the mode transitions. We can also see that the time line is common for the two nodes, since they are synchronized with respect to the reference time provided by the central node. The next function to demonstrate is the ability of the central node to track new active nodes or mark as offline nodes that have stopped transmitting or got for some reason out of the range of the network. It is well known that when a fire is passing the communication range of a sensor is affected and thus it may appear as offline temporarily. In Figure 10 we observe some messages in the “Operation Status History” window. In the 4th line we are informed about one node being not active anymore, while in the last line we are informed that this node has become active again. The central node through the use of its node registry can track previously active nodes that become active again, or register new nodes that join the network for the first time.

Fig. 10. Network status messages in the central node, tracking nodes that become inactive temporarily

5 Conclusions An end-to-end system prototype for fire hazard detection and monitoring based on a WSN has been presented. The system was built using inexpensive sensor nodes that were designed in our laboratory (cost less than 50 euros/node). The embedded software for the sensor nodes allows them to adjust dynamically their mode of operation based on the local temperature trends sensed in their environment. Four modes of operation (Initialization, Low Risk, High Risk, Emergency) have been specified. As an approaching hazard makes the sensor nodes transition towards the Emergency mode, the sampling and reporting periods are decreasing so that the available energy is spent wisely when it is really needed and conserved during the rest of the time. A user friendly GUI has been designed for the central node (PC) that allows the user-operator to start, stop, synchronize, check the status of the network and change parameters (periods, thresholds) globally or for each individual node. The system has been tested in the field and examples of its usage are reported. Despite the fact that only a small-scale prototype has been built, the embedded software design was performed with network scalability in mind. By adjusting properly the reporting period a single central node can handle even large size networks without becoming a

Wireless Sensor Network Application for Fire Hazard Detection and Monitoring

15

communication bottleneck. Furthermore, the application design is modular so that multiple central nodes could be introduced if partitioning of the network control responsibilities is deemed necessary as the network grows bigger.

References [1] Chang, N., Guo, D.: Urban Flash Flood Monitoring, Mapping and Forecasting via a Tailored Sensor Network System. In: Proc. of the 2006 IEEE Int. conference ICNSC 2006, April 2006, pp. 757–761 (2006) [2] Doolin, D.M., Sitar, N.: Wireless Sensor for Wildfire Monitoring. In: Proc. of the SPIE, vol. 5765, pp. 477–484 (2005) [3] Suzuki, M., Saruwatari, S., Kurata, N., Morikawa, H.: A high-density earthquake monitoring system using wireless sensor networks. In: Proceedings of the 5th international conference on Embedded networked sensor systems, Sydney, Australlia (2007) [4] Welsh, M., Werner-Allen, G., Lorincz, K., Marcillo, O., Johnson, J., Ruiz, M., Lees, J.: Sensor networks for high-resolution monitoring of volcanic activity. In: Proceedings of the 20th ACM symposium on Operating systems principles, Brighton, United Kingdom (2005) [5] Glasa, J., Halada, L.: Envelope theory and its application for a forest fire front evolution. Journal of Applied Mathematics, Statistics and Informatics (1), 27–37 (2007) [6] Asensio, M.I., Ferragut, L.: On a wildland fire model with radiation. Int. Journal for Numerical Methods in Engineering 54, 137–157 (2002) [7] Cruz, M., Butler, B., Alexander, M., Forthofer, J., Wakimoto, R.: Predicting the ignition of crown fuels above a spreading surface fire. Int. Journal of Wildland Fire 15, 47–60 (2006) [8] Finney, M.A.: FARSITE: Fire Area Simulator – Model Development and Evaluation. Forest Service, Research Paper, RMRS-RP-4 Revised (March 1998) [9] EUFIRELAB, a wall-less Laboratory for Wildland Fire Sciences and Technologies in the Euro-Mediterranean Region, Deliverable D-03-06, http://www.eufirelab.org (07/02/2008) [10] Rothermel, R.C.: How to Predict the Spread and Intensity of Forest and Range Fires. USDA Forest Service Tech. Report, INT-143, Ogden, UT (1983) [11] ATMEL Corporation, AVR Butterfly Evaluation Kit User Guide, ATMEL (2005), http://www.atmel.com/dyn/resources/prod_documents/doc4271.pdf [12] MaxStream Inc., XBee OEM RF Modules Datasheet, Maxstream (2006), http://www.maxstream.net/hottag/index.phpht=/products/xbee/ datasheet_XBee_OEM_RF-Modules.pdf [13] IEEE std. 802.15.4, Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs), IEEE (June 2006) [14] Manolakos, E.S., Manatakis, D.: Temperature field modeling and simulation of wireless sensor network behavior during a spreading wildfire. In: Proceedings of the 2008 European Signal Processing Conference (EUSIPCO 2008), Lausanne, Switzerland (August 2008) [15] SCIER: Sensor and Computing Infrastructure for Environmental Risks, http://www.scier.eu [16] ATMEL Corporation, 8-bit AVR Microcontroller with 16K Bytes In-System Programmable Flash, ATMEL (2006), http://www.atmel.com/dyn/resources/prod_documents/doc2514.pdf [17] MATLAB and Simulink for Technical Computing, http://www.mathworks.com

Fire Detection and Localization Using Wireless Sensor Networks Alireza Khadivi and Martin Hasler Ecolé Polytechnique Fédérale de Lausanne School of Computer and Communication Sciences Laboratory of Nonlinear Systems CH 1015, Lausanne, Switzerland {alireza.khadivi,martin.hasler}@epfl.ch

Abstract. A Wireless Sensor Network (WSN) is a network of usually a large number of small sensor nodes that are wirelessly connected to each other in order to remotely monitor an environment or phenomena. Sensor nodes use the data aggregation method as an effective tool for estimating the desired parameters accurately and trustfully. In this paper, we have applied a cellularautomata-like algorithm and an averaging consensus algorithm for fire detection and localization with sensor networks. Indeed, when fire is detected somewhere in the network, our algorithm makes aware all the nodes in the network with a very short delay. Afterwards, the algorithm estimates the parameters of the circle surrounding the fire. To simulate the fire outbreak and the reaction of the sensor network equipped with our algorithm, we enabled the data exchange between the fire simulation software FARSITE and the communication software Castalia. The results show that our method detects the fire rapidly and monitors the extension of the fire in real time. The information about the outbreak and the extension of the fire is available from every live sensor in the network, even when part of the sensors are destroyed by the fire. Keywords: Wireless Sensor Network, Consensus Algorithm, Fire Monitoring.

1 Introduction Technological advances in microelectronics lead to very low power consumption electronic systems as well as RF modules with reasonable prices [1-3]. This creates new opportunities for environmental monitoring by wireless sensor networks. In a wireless sensor network, the sensors can exchange information repeatedly in order to come to some conclusion concerning the global environmental situation in the area the sensor network covers. In this paper the sensors measure temperature and determine collectively whether there is a fire in the area, and if so, where the fire is localized. This way of coming to a conclusion by a distributed algorithm before sending the information to a base station, instead of sending the information directly from each sensor separately is advantageous from the point of view of energy consumption and robustness, if the network is carefully designed. N. Komninos (Ed.): SENSAPPEAL 2009, LNICST 29, pp. 16–26, 2010. © Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering 2010

Fire Detection and Localization Using Wireless Sensor Networks

17

There are different strategies to transfer the aggregated data to the base station. In some networks, the sensor nodes first setup a multi-hop path and then send the data directly to the base station. In other networks, the sensor nodes first relay the data to a pre-specified Cluster-Head and then the cluster head sends the data to the base station. In this paper we do not elaborate on this question any further, but we just remark here that the aggregated data are available at each sensor in the network as long as it is alive and therefore many different read-out strategies can be realized, such as e.g. driving a vehicle to the edge of the area and reading from the nearest sensor. In this paper, two distributed algorithms are discussed, one for fire detection and one for fire localization. Using the first algorithm, the entire sensor node population in the network finds out rapidly that there is a fire somewhere in the network, and by using the second one, one can gain information about the exact place and boundary of the fire from every sensor node in the network. In these algorithms, we assumed that each sensor node is location aware, i.e. it knows its coordinates (but not those of the other sensors) and it has a temperature sensor which measures the temperature of the in its position periodically. In addition to studying the efficiency of the algorithm in ideal conditions, we also have taken into account non-idealities due to the implementation of the wireless network, such as collisions due to simultaneous media access. For this purpose, we have used the simulation software Castalia[4] which is specifically developed for wireless sensor network simulations. Realistic modeling of the channel is one of the major advantages of this software. The temperature of the environment, i.e. the input data for the sensor nodes, is generated by the FARSITE[5] fire simulator software. This software is well-known for modeling of the spreading of the fire depending on the parameters of the environment. At the end, the output data of Castalia is visualized by MATLAB. The result of simulation shows a rapid alarm spreading in the case of fire outbreak and a good estimation of the circle surrounding the fire. Compared with the behavior of the ideal network simulated by MATLAB, when there is no interference and loss in communication between nodes, a good agreement was found. The rest of the paper is organized as follows. Section 2 and 3 describes the Fire Detection and Fire Localization algorithms, respectively. Section 4 presents the simulation results and Finally, Section 5 concludes the paper.

2 Fire Detection Algorithm Since the sensor nodes have limited energy, most of the time, they are in a sleep mode. In this mode, there is a low number of packets traversing the network in order to ensure the connectivity of the network. But, when a node sensed a temperature greater than a pre-specified threshold, it wakes up first and second nearest neighbors and sends them a Fire-Detection message. It is worth to mention that they do not go anymore into sleep mode until the alarm is called off (not modeled here), or until they are burnt. In order to save energy, the packet lengths of messages that are sent by sensor nodes are short. In each packet, 4 bytes are used for the address of the alarm initiator and 1 bit for the type of the packet. When the sensor network has concluded that there is a fire in the area, and this information has reached every sensor extra information

18

A. Khadivi and M. Hasler

for finding the location and boundary of the fire is transmitted. The fire detection algorithm is as follows. Each sensor node in the network can be in 3 different states which are: No-Fire: the temperature measured by the sensor is below a pre-defined Temperature-Threshold (T-T) and no or not sufficiently many Alarms have been received from neighbor nodes. • Fire-Detected: the temperature that is measured by the sensor is more than the T-T for two consecutive measurements and no or not sufficiently many Alarms are received from neighbor nodes. • Fire-Alarm: there is a fire somewhere in the network that is observed by the sensor itself or by other sensor nodes. There are two types of packets that are sent in Fire-Detection phase • Fire-Detection massage: this massage is sent by sensor nodes that have detected the fire. • Fire-Alarm message: this message is used for disseminating Alarm in the network. All sensor nodes are initially in the No-Fire state. When a sensor has sensed a temperature above threshold in two consecutive measurements, it goes to the FireDetected state. Furthermore, it sends a Fire-Detection message to its first and second nearest neighbors. If a sensor node receives two Fire-Detection messages from two different nodes and also detects the fire itself, it changes its state to Fire-Alarm and sends a Fire-Alarm message to its neighbors. Furthermore, if a sensor node is in the Fire-Detected state and then receives a Fire-Alarm message from another node, it will go directly to the Fire-Alarm state. Also, if a sensor node is in the No-Fire state and its measured temperatures are more than T-T for two consecutive times while it has already received an Alarm message, then it will go instantly to Fire-Alarm state. The sensor nodes that are in No-Fire state cannot go to Fire-Alarm state unless they receive two Fire-Alarm messages from two different neighboring sensor nodes. This method leads to dissemination of the Alarm to all the nodes in the network. This result is also verified by Castalia simulation software for a realistic communication channel. The state diagram of the algorithm is depicted in figure 1. First way is adding the node ID of the original sender to its Fire-Detection message. The second option is to send the location of the sender instead of its node ID. We considered the second way in order that the sensors have a good estimate of the Fire-Start point. Having this location is helpful for improving the accuracy of the fire localization which follows fire detection. The way that the sensors estimate this location is as follows. The sensors that are in No-Fire state and receive two Fire-Alarm messages, they assume the average of the received locations as the Fire-Start point. In general, the Fire-Start point is assumed to be the average of the locations in Fire-Detection and Fire-Alarm received messages before going to Fire-Alarm state. Also, if a sensor node detects the fire itself, it adds its location in the averaging process. At the end, the estimated Fire-Start point on different nodes is slightly different but, it is negligible and does not affect the performance of fire localization algorithm.

Fire Detection and Localization Using Wireless Sensor Networks

1st sensedtemperature>TͲT Or 1st FireͲAlarmmessagereceived

19

1st FireͲDetectionmessagereceived 2nd Succeedingsensedtemperature>TͲT

NoͲFire State

FireͲDetection State

SendoneFireͲDetectionmessage

2nd FireͲAlarmmessagereceived Or 2nd Succeedingsensedtemperature>TͲT While,1st FireͲAlarmmessageisalready received

FireͲAlarm State

2nd FireͲDetectionmessagereceived Or 1st FireͲAlarmmessagereceived

SendoneFireͲAlarm message

Fig. 1. State Diagram of the Fire Detection Algorithm

3 Fire Localization Algorithm The Fire localization algorithm starts when the fire is detected in the network. In fact, it starts right after the end of Fire Detection phase. The purpose of this algorithm is to find a circle that surrounds approximately the fire. In order to estimate this circle, three parameters should be derived which are X and Y-coordinates of the center (Z) as well as the radius (r). Also, these parameters should be accessible from the all nodes in the network. A simple consensus algorithm [6] is used to estimate the circle parameters in a distributed manner. A similar approach to find parameters of functions by consensus has been described in [7]. The algorithm is as follows. The sensor nodes that have measured a temperature higher than a pre-defined LowTemperature-Threshold (LTT) and lower than a High-Temperature-Threshold (HTT) are assumed to be in the boundary of the fire. At each step, the consensus algorithm runs over these sensor nodes and the result is disseminated across the network. In our case, we consider the LTT = 30°C and HTT = 150°C. Also, we assume that if the temperature of a sensor node reaches 200°C, it will be destroyed. The algorithm finds the circle that minimizes the sum of the squares of the distances di2 = ( Z − X i − r )2 where X i is the position of ith node out of the m nodes that participate in the consensus finding. In order to solve this nonlinear least square problem, the Gauss-Newton method is used. Indeed, the objective is to minimize

u = ( z1 , z2 , r ) is the vector of unknowns and ( z1 , z2 ) are the x and y-coordinates of the centre, respectively [8]. This nonlinear optimization problem is solved iteratively by a sequence of linear least square problems. We set uˆ = u% + h as the next approximate solution if the current approximate solution is u% . By expanding d (u) = ( d 1 (u) , d 2 (u) , ... , d m (u) ) around u% using Taylor series, one obtains:

∑ i di (u) 2 , where

20

A. Khadivi and M. Hasler

J ( u% ).h = −d ( u% )

(1)

Solving (1), we find h in each iteration and update the approximation by uˆ = u% + h .

( ) T

Since J is not a square matrix, the vector h is determined by h = − J J

−1

T

J d.

For our problem we have: z1 − x1 ⎛ ⎜ 2 2 ⎜ ( z1 − x1 ) + ( z2 − y1 ) J ( u) = ⎜ M ⎜ ⎜ z1 − xm ⎜ ⎜ ( z − x )2 + ( z − y ) 2 m m 1 2 ⎝ which can be rewritten as

z2 − y1

⎞

2

( z1 − x1 ) + ( z2 − y1 )

2

M z2 − y m ( z1 − xm ) 2 + ( z2 − ym ) 2

−1 ⎟

⎟ M ⎟ ⎟ ⎟ −1 ⎟ ⎟ ⎠

⎛ cos(α1 ) sin(α1 ) −1 ⎞ ⎜ M ⎟ J (u) = M M ⎜ ⎟ ⎜ cos(α ) sin(α ) −1 ⎟ ⎝ ⎠ m m

(2)

(3)

where α i is the angle between the horizontal axis and the line through X i and Z. Then 2 ⎛ cos (α i ) ⎜ ∑ i ⎜ T J J = ⎜ ∑ cos(α i ).sin(α i ) ⎜ i ⎜ ⎜ −∑ cos(α i ) ⎝ i

∑ cos(α i ).sin(α i ) i

−∑ cos(α i ) ⎞

⎟ ⎟ − ∑ sin(α i ) ⎟ ⎟ i ⎟ m ⎟ ⎠ i

∑ sin 2 (α i ) i

− ∑ sin(α i ) i

(4)

Then we assume that the α of sensor nodes that are in the boundary of the fire are almost uniformly distributed in [0, 2π ] Hence, we have

∑ cos(α ) ≈ 0 i

i

∑ sin(α ) ≈ 0 i

i

1

1

∑ cos (α ) = ∑ 2 (1 + cos(2α ) ) ≈ 2 m 2

i

i

i

(5)

i

1

1

∑ sin (α ) = ∑ 2 (1 − cos(2α ) ) ≈ 2 m ∑ cos(α ) ≈ 0 2

i

i

i

i

i

i

1

∑ cos(α ).sin(α ) = ∑ 2 sin(2α ) ≈ 0 i

i

i

i

i

Fire Detection and Localization Using Wireless Sensor Networks

21

T

Therefore, J J can be simplified to

⎛1m ⎜2 ⎜ T J J =⎜ 0 ⎜ ⎜ 0 ⎜ ⎝

⎞ ⎟ ⎟ 1 m 0⎟ ⎟ 2 ⎟ 0 m ⎟ ⎠ 0

0

(6)

and as a result,

(J J ) T

−1

=

⎛2 1⎜ 0 m ⎜⎜ ⎝0

0

0⎞

2

0

⎟ ⎟ ⎟ 0 1⎠

(7)

At last, we find

( (

⎛1 m 2 2 ⎜ ∑ 2 cos (α i ) ⋅ r − ( z1 − xi ) + ( z2 − yi ) ⎜ m i =1 ⎜1 m 2 2 h = ⎜ ∑ 2 sin (α i ) ⋅ r − ( z1 − xi ) + ( z 2 − yi ) ⎜ m i =1 ⎜ 1 m ⎜ ( z1 − xi )2 + ( z2 − yi )2 − r ∑ ⎜ m i =1 ⎝

(

)

) ⎞⎟⎟ ⎟ ) ⎟⎟

(8)

⎟ ⎟ ⎟ ⎠

As can be seen, the components of the vector h are determined by averaging of three quantities across the sensors that are in the boundary of the fire. In fact, sensor i computes locally the i-th term of each sum and then finds the average value by running a simple averaging consensus algorithm as follows. At step t each sensor node sends the calculated data h ( t ) to its neighboring nodes. Then it uses the following formula to update h ( t )

h ( t + 1)

=

( I − ε L) h (t )

(9)

In this formula, I and L are the identity and Laplacian matrices, respectively. Also, ε > 0 is the connection weight. It is shown in [6] that if 0 < ε < 1 / Δ then h ( t ) converges to the vector h of (8). Δ is the maximum degree of the sensor nodes. Alternatively, different weights for each link could be chosen [9].

22

A. Khadivi and M. Hasler

It should be mentioned that the initial values of ( z1 , z2 ) constitute the Fire-Start position that as found in the Fire-Detection phase and the initial value of r is set to a default value. We have chosen it 5m in our simulations. The corresponding initial values of the entries of the vector h are determined by using these values. After reaching consensus, each sensor node in the boundary has vector h and is able to update vector u and as a result, it finds new parameters of the circle surrounding the fire. Also, these nodes send a Fire-Localization message carrying the new parameters of the circle to the sensor nodes that are not in the boundary of the fire. In the fire localization phase, the sensor nodes that are not in the boundary accept the average of the parameters (center and radius of the circle) in the received FireLocalization messages as the new parameters of the circle surrounding the fire. Also, they send the results in a new Fire-Localization message to their neighboring sensor nodes. After a while, all sensor nodes have the desired parameters. Every time that the sensor node samples the temperature of the environment, it decides whether to be involved in a new consensus process and the whole process is repeated. If a sensor node receives some Fire-Localization messages and then enters the consensus process, the initial values of the entries of vector u are the parameters that are updated by Fire-Localization messages, instead of those that were found in the Fire-Detection phase. The whole process is repeated periodically with a pre-specified period.

4 Simulation Results The algorithms are simulated by Castalia which is specially designed for wireless sensor networks. For our simulation, we have considered 1600 sensor nodes that are deployed in a 200m*200m area. The area is divided into 5m*5m sub-areas and in each sub-area a sensor node is deployed in a random position. The transmission power level is such that the transmitted message can be reached only by neighboring nodes. The duty cycle of the listening interval for each node is 0.1 and the temperature sampling interval is 8 seconds. Each sensor node checks the channel before transmission and waits until the channel is free. The wireless channel model is realistic and the effect of interference is considered to be additive. The Path-Loss-Exponent is 2.4 and the channel quality and the effect of fading between a pair of nodes in one direction are not correlated with the opposite direction. The data of the sensor nodes that were used by Castalia as the data input was generated by the FARSITE fire simulation software which is knows to produce realistic forest fire scenarios. It is worth to mention that the current version of Castalia does not accept any trace file as the input data for sensor nodes. Hence, in order to feed the data of FARSITE to Castalia, we added the possibility of using external trace files to Castalia successfully and thus enabled data exchange from FARSITE to Castalia Simulation results show that the entire sensor nodes go to the Fire-Alarm state after the fire started with a very short delay below 4 seconds. Figure 2 shows the number of nodes that are in Fire-Alarm mode versus the time difference from the first time of detection of fire in the network. In addition, the states of the nodes in four time instances (a-d) which are marked in figure 2 are depicted in figure 3.

Fire Detection and Localization Using Wireless Sensor Networks

23

1600

(d) 1400

Number of nodes in Fire-Alarm State

1200

1000

800 (c) 600

400

200 (b) (a) 0 0

0.5

1 1.5 2 2.5 3 Time difference from the time of the first fire detection in the network (Sec)

3.5

4

Fig. 2. Number of nodes in Fire-Alarm mode versus the time difference from the first time of fire detection in the network 0

0

50

50

100

100

150

150

200 0

200 0

50 100 150 200 (a) Time = Fire-Start-Time + 0.0001 Sec 3 nodes in Fire-Detection state and 3 nodes in Fire-Alarm state

0

0

50

50

100

100

150

150

200 0

50 100 150 200 (c) Time = Fire-Start-Time + 1.5 Sec 38.38 percent of nodes are in Fire-Alarm mode

200 0

50 100 150 (b) Time = Fire-Start-Time + 0.5 Sec 4.56 percent of nodes are in Fire-Alarm mode

200

50 100 150 200 (d) Time = Fire-Start-Time + 2.5 Sec 87.00 percent of nodes are in Fire-Alarm mode

Fig. 3. The states of the nodes in for 4 time instances. BLUE=No-Fire, ORANGE=Fire-Alarm, GREEN=Fire-Detection. In black and white format, BLACK=No-Fire, GRAY=Fire-Alarm, WHITE=Fire-Detection. The contour plot of the fire is shown in the middle of the figures.

As figure 3 shows the spreading of the alarm is quite fast and the Alarm is disseminated in at last 4 seconds which is an acceptable delay. Figure 4 shows the histogram of the difference between the derived geometrical locations of the Fire-Start with real location.

24

A. Khadivi and M. Hasler 900

800

700

Number of nodes

600

500

400

300

200

100

0 2.5

3

3.5 4 4.5 5 5.5 6 6.5 The difference between the real position of the fire and the derived position (Meters)

7

7.5

Fig. 4. Histogram of the difference between the real position and estimated positions of the Fire-Start point

As can be seen there is a bias in this difference that is due to the difference between the real position of the Fire-Start point and the position of the first nodes that have detected the fire. Although this bias is inevitable, it does not cause a considerable error in results. 0

0

50

50

100

100

150

150

200 0

50 100 150 (a): 24 seconds after the start of the fire

200

200 0

0

0

50

50

100

100

150

150

200 0

50 100 150 (c): 336 seconds after the start of the fire

200

200 0

50 100 150 (b): 144 seconds after the start of the fire

200

50 100 150 (d): 384 seconds after the start of the fire

200

Fig. 5. Four snapshots of the network during Fire-Localization phase. The red (gray in black and white mode) region shows the location of the sensor nodes that are in the boundary of the fire.

Fire Detection and Localization Using Wireless Sensor Networks

25

The Fire Localization algorithm starts running right after Fire Detection phase. Simulation results show that each node in the network obtains the parameters of the circle after each consensus process. We have taken 80 iterations for each consensus process. With a better choice of the connection weights, the number of iterations could still be reduced. In order that all the sensor nodes have enough time to process the received data, the time considered for each iteration of the consensus process is 0.3 seconds. Thus, the parameters of the circle are updated every 24 seconds. Also, we have chosen ε = 0.02 . Choosing a large value for ε leads to the instability of the consensus process. In figure 5, there are four snapshots of the network. The red units show the places that are in the boundary of the fire. The green circle is the circle that is found by the Fire-Localization algorithm. This algorithm is also tested in ideal conditions where there is no interference in the communication channel and the buffer size of the radio receiver of the sensor nodes is infinite. The results show that the performance of our algorithm in real conditions is close to ideal conditions. Figure 6 shows the difference in the radius of the circle obtained in real and in ideal conditions in 15 intervals.

Difference between raduis obtained in ideal and realastic conditions (Meters)

2.5

2

1.5

1

0.5

0 0

5

10

15

Interval

Fig. 6. Difference in the radius of the circle obtained in the real and ideal conditions

This error is negligible with respect to the size of the network. In summary, our algorithms work with a good accuracy and acceptable delay.

5 Conclusion We introduced two algorithms for WSNs for the application of forest fire detection and localization with good performance in terms of rapid spreading of alarm in the case fire outbreak as well as a reasonably accurate circle surrounding the fire. Simulation results show that our algorithms react rapidly to the changes in the network with

26

A. Khadivi and M. Hasler

high reliability. They also show that realistic wireless channel conditions do not deteriorate much the speed and accuracy of the algorithms. Acknowledgments. This work has been funded by the WINSOC Project; a Specific Targeted Research Project (contract number 0033914) funded by the INFSO DG of the European Commission within the RTD activities of the Thematic Priority Information Society Technologies. The authors would also like to express their thanks to INTRACOM Co. for providing us the FARSITE output data.

References 1. Chandrakasan, A., Amirtharajah, R., Seonghwan, C., Goodman, J., Konduri, G., Kulik, J., Rabiner, W., Wang, A.: Design considerations for distributed microsensor systems. Custom Integrated Circuits. Proceedings of the IEEE, 279–286 (1999) 2. Clare, L.P., Pottie, G.J., Agre, J.R.: Self-organizing distributed sensor networks. In: Unattended Ground Sensor Technologies and Applications, vol. 3713, pp. 229–237. SPIE, Orlando (1999) 3. Dong, M.J., Yung, K.G., Kaiser, W.J.: Low power signal processing architectures for network microsensors. In: International Symposium on Low Power Electronics and Design, Proceedings, pp. 173–177 (1997) 4. Castalia, http://castalia.npc.nicta.com.au 5. FARSITE, http://www.firemodels.org 6. Olfati-Saber, R., Olfati-Saber, R., Fax, J.A., Murray, R.M.: Consensus and Cooperation in Networked Multi-Agent Systems. Proceedings of the IEEE 95, 215–233 (2007) 7. Pescosolido, L., Barbarossa, S., Scutari, G.: Decentralized Detection and Localization Through Sensor Networks Designed As a Population of Self-Synchronizing Oscillators. In: IEEE International Conference on Acoustics, Speech and Signal Processing, ICASSP 2006, Proceedings, vol. 4, pp. IV981–IV984 (2006) 8. Gander, W., Golub, G.H., Strebel, R.: Least-squares fitting of circles and ellipses. BIT Numerical Mathematics 34, 558–578 (1994) 9. Xiao, L., Boyd, S., Kim, S.-J.: Distributed average consensus with least-mean-square deviation. Journal of Parallel and Distributed Computing 67, 33–46 (2007)

Design and Implementation of a Wireless Sensor Network for Precision Horticulture Juan A. López, Fulgencio Soto, Andrés Iborra, Pedro Sánchez, and Juan Suardíaz Universidad Politécnica de Cartagena, DSIE, Campus Muralla del Mar, s/n E-30202 Cartagena, Spain {jantonio.lopez,pencho.soto,andres.iborra, pedro.sanchez,juan.suardiaz}@upct.es

Abstract. A prototype wireless sensor network for measuring soil and environmental characteristics was developed and evaluated for purposes of scheduling irrigation on field vegetable farms. The system consists of a central base station connected to multiple sensor nodes installed in the field and distributed over several crops. The sensor nodes consist of specially designed hardware which transmits data to a base station inside the farm offices. The relatively low cost of the system (USD 6000 for a 20-sensor node system) allows for installation of a dense sensor population that can adequately represent inherent soil characteristics such us temperature, volumetric moisture content, salinity and so on. Additional sensors can be used to measure environmental variables and the quality of the water used to irrigate the crops. This paper describes our experience during the design and implementation of the wireless sensor network and its components in a field crop of Broccoli (Brassica oleracea L. var Marathon) in the semiarid region of Campo de Cartagena in Southern Spain. It presents the topology of the network, which was deployed using three types of sensor nodes (Soil-Mote, Environmental-Mote and Water-Mote). Keywords: Wireless Sensor Networks, Motes, TinyOS, Precision Horticulture, Precision Agriculture.

1 Introduction Precision agriculture (PA) and precision horticulture (PH) [1] are production systems which make it possible to more accurately predict crop development on the basis of site conditions. To that end it is important to gather as much information as possible on the soil, plants and environment. This is achieved with new technologies such as global positioning systems (GPS), geographic information systems (GIS), wireless communications and instrument systems. In this context, Wireless Sensor Networks (WSN) [2] is a technology with a promising future. In fact a number of studies have been published in the last few years on applications of this kind using WSN in Precision Agriculture. For example, Camilli et al. [3] used a simulation to demonstrate the utility of a WSN in Precision Agriculture; Pierce et al. [4] described a platform that they had developed for local and regional networks and implementations of them in two Precision Agriculture applications in N. Komninos (Ed.): SENSAPPEAL 2009, LNICST 29, pp. 27–42, 2010. © Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering 2010

28

J.A. López et al.

Washington State; and Morais et al. [5] described a prototype that they had developed for deployment on vineyards to monitor crops of this type. This article describes how a WSN was set up on a horticultural holding. The farm is located in the Campo de Cartagena in the Region of Murcia, South-East Spain, in one of Europe’s most important horticultural areas. In climatic terms, this is a semiarid zone with annual rainfall of approximately 400 mm. But despite that, 190,000 ha, 31% of the cultivated area, is under irrigation. The farm on which the experiment was conducted (Langmead España S.L.) practises ecological agriculture, also known as biological or organic farming. This is a way of growing crops and caring for the land that is respectful of nature and normally excludes the use of chemicals and genetically modified seeds. The principal aim of this kind of farming is to preserve the environment, maintain or enhance the fertility of the soil and produce foods with their own natural properties. The holding on which the experiment was conducted is of average size for the region. It covers 1000 ha, with 250 crop fields scattered over the Campo de Cartagena and several kilometres apart (between 5 and 10 km approximately). The ultimate aim of this work was to provide the farm with an infrastructure consisting of a large number of sensors with which to ascertain crop water conditions in real time and make the appropriate decisions. For these reasons, and in view of the scattered nature of the crop-fields, wireless sensor networks are the ideal solution. This article describes our experience in laying out a sensor network on a real farm holding; section 2 describes the experimental scenario where the sensor networks were deployed. Section 3 presents one of the system’s main devices, the GAIA SoilMote, from the standpoint of hardware and software. In combination with the Hydra Probe II sensor, this mote is capable of recording the salient characteristics of the soil (temperature, humidity and salinity). This same section describes the power management and the autonomy of the sensor node, and also the characteristics of the associated Hydra Probe II sensor. This section closes with a brief presentation of the other sensor nodes that have been developed to implement the network (GAIA Environmental-Mote and GAIA-Water Mote), and the Data-Sink/Gateway. Section 4 then gives a brief description of the possibilities offered by the monitoring software as developed, which is run on a computer at the farm’s central office. Section 5 reports the results achieved in a real installation, and finally section 6 summarizes the main conclusions and proposed future research.

2 General Characteristics of the Network Deployed Figure 1 shows the characteristics of the experimental crop on which the system as developed was tested. This consisted of two fields lying about 8.7 and 5.2 km respectively from the farm offices. In each plot, ten GAIA Soil-Motes were deployed to monitor the condition of the soil, and an Environmental-Mote was installed to monitor the ambient temperature and humidity in the plots. A Water-Mote was also installed in one of the supply ponds to check the quality of the irrigation water by monitoring its electrical conductivity.

Design and Implementation of a Wireless Sensor Network for Precision Horticulture

29

Fig. 1. Deployment of the wireless sensor network in two fields on a horticultural holding. The network also includes a sensor node to record the quality of the water supplied from a pond.

The device infrastructure required to interconnect the two sensor networks and the wireless sensor with the offices is as follows: (1) one Gateway for each of the sensor networks; (2) a Repeater located on the office building roof; and (3) a Base Station Mote inside the offices, physically connected to the monitoring computer. To assure wireless coverage of the system, Gateways were developed incorporating long-range radio modules in the design of the GAIA Soil-Mote. More information about hardware architecture of the overall system can be found in [6]. The nodes in each of these sensor networks were interconnected via IEEE 802.15.4 [7]. The reasons for the decision to use this standard will be explained in the part of the following section specifying the software architecture. When a message reaches the central computer through the Gateway, it is processed and its source and the information it contains are checked. On the basis of this information the message is stored in a relational data base, where a historical record is kept of the data gathered by the sensors and the times of the readings.

3 The GAIA Soil-Mote One important aspect of the motes is their capacity for connection with external instruments. There is a large group of sensors used in the field of Precision Agriculture which provide output by means of the SDI-12 protocol [8]. Commercial solutions based on this protocol include sensors marketed by Stevens, such as Hydra Probe II and EC 1200. Another major distributor, Campbell Scientific, markets sensors like CS245-L, CS408-L and WINDSONIC4-L. For that reason one of our objectives was to develop a mote capable of connecting to SDI-12-type external sensors. The chief requirements of this mote are as follows:

30

J.A. López et al.

1. The mote must be a robust product in order to monitor soil parameters (temperature, humidity, salinity and conductivity). 2. The mote must have a SDI-12 interface so that any sensor with this protocol can be connected. However, it must be designed in such a way as to allow other SDI12 sensors to be connected with minor variations in the software. In the present case, the mote must permit the running of two HP2 sensors to monitor the volumetric percentage. temperature, salinity and electrical conductivity of the soil at different depths. 3. The mechanical design of the device must be optimized for use on horticultural crops. This means that it must be suitable for installation at ground level and be small enough not to have to be removed when the crop is fumigated using farm machinery. The mote’s casing must therefore provide IP67 standard protection and must be no more than 20 cm high (including the antenna). Also, to help avoid the motes being stolen, they should be painted a discreet colour. Note that although the design has to be optimized for horticultural crops, the motes must also be able to be used in other kinds of crops such as fruit crops, vineyards, etc. 4. To assure the greatest possible autonomy, the device must be able to communicate with a Sink-Mote or a Gateway via a highly reliable radio module compatible with standard IEEE 802.15.4. The motes are programmed with TinyOS [9], which uses the BMAC medium access algorithm, in order to optimize consumption. The working frequency is the 2.4GHz free band (ISM). 5. There is a limitation in that the gateway antenna must be at a height of not less than 5 m above the deployed nodes, and the maximum coverage between the sensor node and the gateway must be at least 100 m. 6. The Soil-Mote must be battery-operated with an autonomy of at least 10 weeks, which is the normal duration of a horticultural crop cycle. 7. On the software side, sensor readings are sent periodically to the sink node by way of the gateway. The reading frequency must be configurable from the sink-mote, over a range from 30 minutes to 10 days. The sink node must also receive hourly information on the battery status. In addition, for the deployment phase it was decided that the GAIA Soil-Mote should receive test messages from the sink node, which the latter would send back to the soil mote to assure proper communication between the two. These were the basic requirements for the design of the GAIA Soil-Mote, which is described in the following sections. 3.1 Hardware Overview Figure 2 shows two photographs of the GAIA Soil-Mote. The first one gives an idea of the size of the PCB, which was developed using SMD technology. As we can see, the mote card has been developed with a minimal number of components. This is due in part to the low power-consumption requirement and in part to the need to keep the mote size and manufacturing costs to a minimum. The following figures show the block diagram, the external appearance of the mote and its location in a horticultural crop. The sensor node is connected to two Stevens Hydra Probe II (HP2) sensors, which are described further below. The HP2 sensors are buried at different depths to

Design and Implementation of a Wireless Sensor Network for Precision Horticulture

31

monitor the main soil parameters. The core of the platform is a Msp430f1611 ultralow power microcontroller from Texas Instruments. Wireless communication is provided by the Chipcon CC2420 radio module. The mote is powered with the help of a 3.7 V, 2000 mAh LiPo lithium polymer battery. Both the watertight casing and the sensor connectors have IP67 protection. Further information about the elements included in this device is presented in [9].

(a)

(c)

(b)

(d)

Fig. 2. Different views of the GAIA Soil-Mote. (a) PCB. (b) Block diagram. (c) External view of casing. (d) Image of device in field with detail of the sensor used.

When the battery is fully charged it delivers more than 4V. For that reason, as the block diagram shows, a low-consumption, low-dropout DC/DC converter (#1) is included to keep the battery voltage at 2.5 V. This voltage powers the microcontroller and the radio module. Then there is a second converter (#2) which transforms the 2.5 V to provide the 12 V output required by the HP2 external sensors. For efficient energy management, this converter is enabled only during the sensor reading process.

32

J.A. López et al.

An “SDI-12 Interface” module has been included to enable the external sensors to be connected to the microcontroller’s UART. This interface is necessary for two reasons: the microcontroller and the external sensors work with different voltages, and moreover the two pins of the UART (Rx and Tx) have to be interconnected with the single twoway data line from the external sensors. All this is achieved by means of a tri-state buffer, a transistor and some discrete components so as to incorporate the SDI-12 interface in the mote. A single connector serves to connect up to 10 external sensors. Note that using only one external connector simplifies the PCB design of the board. Finally, the block diagram shows the battery connected to the microcontroller by a voltage divider to allow periodic sampling of the battery level. 3.2 Software Organization The device software was developed with TinyOS [10] version 2.0 as an operating system environment with the nesC [9] component-oriented programming language associated. TinyOS is an event-driven open-code operating system that provides the functionality needed for the proposed application, and it benefits from a large and active user community. We ported TinyOS to our platform and used a set of drivers that make the various I/O components available to the application programmer. Interested readers can find more information on this kind of programming in [11]. Figure 3 shows the nesC component diagram for the mote as developed. HP2C is a new component that is grafted on to TinyOS and is optimized for the use of two HP2 sensors. All the other components are operating system primitives which have been instantiated. Further details about the software architecture of the devices involved in the network can be found in [6]. The program entry point is supplied by the MainC component using the Boot interface. For the program to function, it is necessary to instantiate four TimerMilliC components, which are required to manage the program timer so as to know when to take a reading (Timer0), send the command to start up the reading process (Timer2) and start the data reading process (Timer3), and to be able to handle a time lag from when the process starts until the data are available (Timer1). For communications, three AMSenderC components are required, one of the type CC2420ActiveMessageC and another of the type AMReceiver. The SendData instance of the AMSenderC component is used to send the data gathered from the sensors to the sink node or base station. The SendBattery instance sends the battery level data every hour. And finally, to facilitate the process of node deployment with the SendTest instance, a test message received from the Base Station is echoed. With the AMReceiver component it is possible to receive two types of messages: test messages and messages to alter the sensor reading timing. The last component, CC2420ActiveMessageC, is used to initiate the radio module and manage its operating time. In this way energy expenditure by the radio transceiver can be optimized. The nodes are specifically configured with a low-power-listening (LPL) period of 10 s. On this point it is important to remember that the frames sent and received with the selected TinyOS components are compatible with standard IEEE 802.15.4. We say that “the frames are compatible with the standard” because in order to optimize consumption TinyOS uses the BMAC medium access protocol instead of the MAC protocol, which is the one actually defined in the standard.

Design and Implementation of a Wireless Sensor Network for Precision Horticulture

33

Fig. 3. GAIA Soil-Mote: nesC component diagram.

The Msp430Uart1C component is the one used to manage all communications with the HP2 sensor. With the LedsC component it is possible to access the 3 LEDs included in the mote, which are used to indicate states such as sending data from the mote, receiving a message and others. Msp430ADC0C allows sampling of the microcontroller ADC0 that is connected to the battery by way of a resistive voltage divider. And finally, a HPL (Hardware Presentation Layer)-level TinyOS component is needed to manage a series of microcontroller pins required for management of the SDI-12 interface (communications and DC/DC converter on/off). 3.3 Hydra Probe II Sensor The Hydra Probe II sensor (HP2) (see figure 2.d) is a commercial product from Stevens Water Monitoring Systems, Inc. which is available with two different output interfaces: SDI-12 and RS485. Of these two versions, the most suitable for applications with low-consumption requirements is the SDI-12, since consumption in standby mode is 10 times less than with the RS485. Moreover, it only requires 3 wires (power, earth and data) as opposed to 4 required by the RS485 (power, earth, com+ and com-). This sensor can provide various parameters for the ground, the most important being the temperature, volumetric percentage, conductivity and salinity of the soil. Calibration is carried out in the sensor itself, so that the data are received in digital-format physical units and ASCII code. Nevertheless, users may wish to perform their own calibration, and there is therefore the possibility of receiving uncalibrated data on the variables directly from the ADCs, in raw format. As in any SDI-12 device, communication is achieved by sending ASCII commands and interpreting the response from previous ones. These commands can be used to

34

J.A. López et al.

take readings of the above-mentioned values and to configure parameters such as soil type, water constant, setting-up time and definition of the variables to be measured. 3.4 Power Management and Autonomy In this section the objective is to estimate the autonomy of the device. As battery specifications are provided using AH terms, this can be determined with the battery parameters and the intensity required by the device. The GAIA Soil-Mote has four functional states: standby for messages, communication module wake-up, sensor data acquisition and data transmission. Figure 4.a shows the mote’s power consumption in each of these states. The worst-case scenario was taken for average consumption that is acquisition and transmission of data from the two sensors every thirty minutes. The ultimate aim of this study was to determine how much power the mote consumed on average, so as to relate the resulting figure directly to the capacity of the batteries and hence determine the device’s autonomy. The mote’s average power consumption may be determined thus:

I soil− mote = I s tan dby + I receiv + I acq + I trans

(1)

I s tan dby = 0.25mA

(2)

20mA ⋅ 15 ⋅ 10 −3 = 0.03mA 10

(3)

where

I receiv ≈

⎛ 110mA ⋅ 1800 ⋅ 10 −3 ⎞ ⎟⎟ = 0.22mA I acq ≈ 2 ⋅ ⎜⎜ 1800 ⎝ ⎠

(4)

⎛ 25mA ⋅ 125 ⋅ 10 −3 ⎞ ⎟ = 0.00434 mA I trans ≈ 2.5 ⋅ ⎜⎜ ⎟ 1800 ⎝ ⎠

(5)

Equation (2) represents the stand-by consumption and (3) expresses the average consumption in receiving mode for a 15 ms pulse every 10 s, with the radio switched on in the Low-Power-Listening period. Equation (4) presents a similar calculation, in this case multiplied by two, which is the number of sensors that are connected, and divided by 1800 s (30 minutes), which is the worst-case scenario for estimating autonomy. Equation (5) expresses the average consumption for the transmission of the sensor data and battery voltage. The equation is multiplied by 2.5 because the battery voltage messages are sent every hour. Equation (1) gives us an average current of 0.5034 mA, which, considering that the batteries are 2000 mAH, gives an estimated autonomy of 165 days. Note that the intensities of each state have been measured at the device input for a voltage of 3 V.

Design and Implementation of a Wireless Sensor Network for Precision Horticulture

35

GAIA Soil-M ote Battery 4,40

Battery voltage

4,20 4,00 3,80 3,60 3,40 3,20

12/22/08

12/15/08

12/08/08

12/01/08

11/24/08

11/17/08

11/10/08

11/03/08

10/27/08

10/20/08

10/13/08

10/06/08

09/29/08

09/22/08

09/15/08

3,00

Date

(a)

(b)

Fig. 4. (a) Consumption states of the GAIA Soil-Mote: “standby”= 0.25 mA, “transceiver wake-up”= 20 mA, “acquisition”≈ 110 mA, “communication module transmitting (Sensor Data and Battery Voltage)”= 25 mA. (b) Evolution of battery rundown during laboratory tests.

To check the above result, a real study was conducted in the laboratory (see figure 4.b) between September and December 2008, with the device taking sensor readings every 30 minutes. At the end of the study, the final value for the battery was approximately 3.8 V, well above the value of 2.7 V required at the main DC/DC converter input for the system to work properly. 3.5 Environmental-Mote, Water-Mote and Data-Sink/Gateway The Environmental-Mote is a version of the GAIA Soil-Mote which has been equipped with suitable interface to enable it to connect the appropriate sensor. The Environmental Motes (see Figures 5.a and 5.b) record the ambient temperature and humidity parameters for a crop. The mote’s architecture is similar to what we saw for the GAIA Soil-Mote except for the interface with the external sensors. Each mote is connected via the I2C interface to a Sensirion SHT71 sensor, which is placed inside a solar protection shield a metre and a half off the ground. These kinds of motes take readings of the cited parameters with a maximum parameterizable frequency of 2 readings/hour. The Environmental Motes must be located within a radius of roughly one hundred metres around the Data Sink/Gateway. In the experimental deployment, only one mote per field was used since the ambient conditions do not vary significantly from one field to the next. The Water Mote (see Figures 5.c and 5.d) measures the temperature and salinity of the water supplied to the crop from an irrigation pond. In this case the mote is connected directly with the offices by way of a long-range radio module (XStream X24019PKI-RA radio modem) with an 8dBi omni-directional antenna for outdoor use. The rest of the architecture is very similar to that of the motes described above. In this case a Stevens EC 250 sensor is submerged in the pond. The two sensor outputs (temperature and salinity) are supplied in the form of a 4-20 mA signal; they are read by the microcontroller’s ADC0 and ADC1 converters after the current loop is passed through a resistor. These parameters are read with a maximum parameterizable frequency of 2 readings/hour. The mote is powered by a solar panel and is enclosed in a watertight box placed on the edge of the pond. Its antenna is located on a mast at a height of approximately four metres.

36

J.A. López et al.

(a)

(b)

(c)

(d)

(e)

(f)

Fig. 5. Views of the different prototypes developed with similar architecture to the GAIA SoilMote. (a) Environmental-Mote. (b) Environmental-Mote installed in the field. (c) Water-Mote. (d) Water-Mote installed in the field. (e) Data-Sink/Gateway. (f) Data-Sink/Gateway installed in the field.

As we saw in Figure 1, the device infrastructure required to interconnect the two sensor networks plus the wireless sensor to the offices consists of: (1) one DataSink/Gateway for each sensor network; (2) one Repeater located on the office building roof; and (3) one Base-Station inside the offices, physically connected to the monitoring computer.

Design and Implementation of a Wireless Sensor Network for Precision Horticulture

37

Figures 5.e and 5.f show a detailed image of the Data-Sink/Gateway along with its placement in the field. The microcontroller communicates with the crop motes via a short-range radio module and with the Repeater in the offices via a long-range radio module. The lifetime of the power supply is unlimited thanks to the use of rechargeable solar batteries. In order to have a connection with the Base-Station in the offices, the main antenna has been placed on the office roof, at a height of nine metres. The main antenna and the Base-Station are also connected wirelessly. The Base Station gathers all the information generated by the sensor networks and transmits it to the monitoring application which was developed to handle that network. Similarly, it broadcasts any order from the software application over the sensor network. This device is composed of a long-range radio module (2.4 GHz) connected to a 3dBi omni-directional antenna, and a RS-232 interface for connection to the central computer. The Repeater is a commercial radio modem configured in repeater mode, which is connected to an 8dBi omni-directional antenna. This provides up to 16 km line-of-sight coverage in the open. No additional repeaters are required since the relief of the Campo de Cartagena is flat. Table 1 summarizes the characteristics of the different devices that have been developed and deployed on the farm. Table 1. Type of devices developed for the farm

Device

Function

µC/O.S.

Energy Source

Common Module (Range)

Sensors

Water Mote (Prototype)

Instantly measures water salinity and temperature

MSP430F1611 TinyOS 2

Rechargeable Battery

XStream (16 km)

EC 250 (Stevens)

GAIA Soil Mote (final product)

Instantly measures soil moisture, conductivity, salinity and temperature

MSP430F1611 TinyOS 2

Rechargeable Battery

CC2420 (230 m)

Hydra Probe II (Stevens)

Environ. Mote (Prototype)

Instantly measures relative humidity and temperature

MSP430F1611 TinyOS 2

Rechargeable Battery

CC2420 (230 m)

SHT71 (Sensirion)

DataSink/Gateway. (Prototype)

Links soil and environmental motes with repeater

MSP430F1611 TinyOS 2

Solar Cell + Rechargeable Battery

Base Station (Prototype)

Links WSNs with software application

N/A

Grid

CC2420 (230 m) XStream (16 km) XStream (16 km)

N/A

N/A

4 Monitoring Application The monitoring application consists of: (1) a graphical user interface (GUI) where the data read by the sensors are shown, and (2) a program that receives and stores data from the nodes. Both programs were developed using the Java programming language, with

38

J.A. López et al.

the Eclipse environment and the MySQL relational data base management system. The essential features of these applications as developed may be summarized as follows: 1.

2.

3.

The GUI includes the placement of devices using the utility supplied by Google Maps. In this way we can identify the exact geographic position of each node and the crop in which it is located (see Figure 6). 2. The data read by the sensors are sent periodically to the base station and stored in the data base (the program waits for an event indicating data available at the serial port). The GUI will read these data and visualize them graphically in real time. In addition, the sampling period can be modified from the user application. The data base includes details of the nodes deployed, their regional aggregations, the sensors integrated in every node, the historical record of readings, the types of sensors, and the history of alarms received from the sensors and regions (for example battery failure, values below a threshold, etc.).

Fig. 6. Main view of monitoring application A menu bar at the top provides the options noted above (see Figure 6). On the right of the screen a Google Map has been used to depict the geographic position of the deployed nodes. On the left there are three tables displaying the latest data readings from the sensors for the three networks shown on the right. Below the tables is a graphic display of the data for a user-selected time interval, or the latest data gathered. The soil and environmental motes provide the following services: change the sensor sampling period and configure the device to send data from the battery every hour. They also trigger an alert signal if the battery charge is critically low. Moreover, the

Design and Implementation of a Wireless Sensor Network for Precision Horticulture

39

soil mote also provides other services, such as: set soil type, configure data measurement sets, set water constant and establish warm-up time. Note that all these services use a special combination of the data sent to set the sampling period.

5 Experimental Results Two sensor networks were deployed in two plots of approximately 4 ha each. The plots are about 5.2 and 8.7 km respectively from the farm offices. Ten GAIA SoilMotes, one Environmental-Mote and one Data-Sink/Gateway were deployed on each of the plots. The Data-Sink/Gateway was connected to an exterior 3 dBi omnidirectional antenna placed on a post 5 m tall. This was to assure direct line-of-sight between the antennas of the ground-level Motes and the Data-Sink/Gateway. And again to assure line-of-sight between the Data-Sink/Gateway and the offices, one 15 dBi omni-directional antenna was placed on the office roof (9 m high), and another identical antenna on the Data-Sink/Gateway. Wireless communication between the rooftop antenna and the Base Station was achieved with a repeater. At the same time, a technology similar to that of the Data-Sink/Gateway was used to develop a wireless node (Water-Mote) to monitor the quality of the water supplied to the crop using the EC250 sensor. A monitoring application, running on the Base Station, was developed to control all the devices and keep a record of the information received. It consists of: (1) a graphical user interface (GUI) where the data read by the sensors are shown using the utility supplied by Google Maps, and (2) a program that receives and stores data from the nodes. Both programs were developed using the Java programming language, with the Eclipse environment and the MySQL relational data base management system. The trials were conducted on crops of Broccoli (Brassica oleracea L. var Marathon) covering an area of 4 ha each, located in Campo de Cartagena (37º44’26’’N, 1º13’38’’W) in south-east Spain. The seedlings were transplanted (with a population density of 5 plants/m2) on 10 November 2008 and the crop was harvested 12 weeks later, in the first week of February 2009. The soil characteristics of the crop at a depth of 40 cm were: clay loam texture, total carbonates 35.4 p.100, P(Olsen) 78.6 ppm, K(Ac-NH4) 487.0 ppm. A drip irrigation system was laid between the two rows of crops and 1 l/h emitters were installed every 0.20 m. Fertilizer was applied to the crop using fertirrigation. The nodes were deployed in the second week of November, at which time the owners of the farm began to gather data from the WSNs. The SoilMote sensors were placed at depths of 20 cm and 40 cm. During this time there was 198 mm cumulative rainfall, moderately strong winds of up to 69 km/h and mild temperatures (average 11.5 ºC). Figure 7 shows the data (soil moisture) collected over a twelve-week period. The Hydra Probe sensors provide accurate soil moisture measurements in units of water fraction by volume (wfv or m3m-3 )—that is, a percentage of water in the soil displayed in decimal form. For example, a water content of 0.20 wfv means that a one-litre soil sample contains 200 ml of water. Full saturation (all the soil pore spaces filled with water) typically occurs between 0.5-0.6 wfv and is quite soil dependent. The nodes were found to function properly. This provides some assurance of the robustness of the arrangement for similar weather conditions.

J.A. López et al.

0,7 0,6 0,5 0,4

Sensor 1 Sensor 2

0,3 0,2 0,1 01/17/2009

12/31/2008

12/14/2008

11/27/2008

0 11/10/2008

Water Fraction Volume (WFV)

40

Date

Fig. 7. Humidity data from one of the motes Before this technology was introduced, the company monitored its crops in the traditional way—that is, a person visited the crop and the pond to measure the relevant agronomic parameters with appropriate portable equipment. Now, with the technology that has been developed, crop variables can be ascertained in real-time, and as a result the water requirements of the crops can be estimated without anyone having to visit them. The farm team were able to check, in real-time, that the optimum conditions for Broccoli growing were being maintained (salinity in the range 2-4 mmhos/cm, temperature between 10 ºC and 24 ºC, and relative humidity in the range 60%-90%).

6 Final Remarks and Conclusions A sensor network was installed on a real farm in the Campo de Cartagena. To that end a set of specialized motes (GAIA Soil-Mote, Environmental-Mote and WaterMote) were developed for different types of sensors. In turn, a set of auxiliary devices needed to implement the network (Data-Sink/Gateway, Repeater and Base-Station) were also developed. All the devices are available in prototype form, except for the GAIA Soil-Mote, which has been designed and manufactured as a commercial product that is robust enough for use in agricultural applications. The mote comes with a SDI-12 interface and its software is designed to handle two HP2 sensors connected to this interface. The software is readily adaptable to any other type of SDI-12 sensor. To check that they function properly, they were used for 10 weeks on a farm owned by the firm Langmead España S.L. in Campo de Cartagena in south-east Spain. The results were entirely satisfactory.

Design and Implementation of a Wireless Sensor Network for Precision Horticulture

41

A new hardware device has been developed with the following advantages: 1. 2. 3.

4. 5. 6.

7.

Low cost if compared with similar solution products. It offers an SDI-12 communication interface, which is not provided in other commercial solutions. New sensors can be easily connected by adding other general interfaces (SDI-12, 4-20 mA, 0-2.5 V), as in the case of the Environmental-Mote and the WaterMote. Wireless devices avoid the problems related to wired sensor networks deployed in crops. The size of the network can be increased easily in comparison to wired solutions. By using a Base-Station to gather sensor data it is possible to access, via the Internet, all stored data. This improves maintenance tasks because an in-situ data collecton is avoided. The battery replacement is managed remotely. The system sends a signal to the user when the battery is low.

We are now working on an improved version of the GAIA Soil-Mote. In this version the idea is that the mote should be easy to configure in the factory for use as a mote or as a gateway. Similarly, the number and type of output interfaces has been increased (SDI-12, 4-20 mA, 0-2.5 V) so that they can also be factory-configured depending on the sensors that are to be connected to the mote. The purpose of factory-configuration is to keep manufacturing costs down by minimizing the number of components required for each configuration. And finally, we would note that a single-output connector has been designed for connection with external instruments, updating of firmware and battery recharging so that the mote does not have to be opened.

Acknowledgements The authors wish to thank the Ministry of Industry, projects RIMSI (FIT-3301002006-173) and ESNA (ITEA 2006), Fundación Séneca of the Murcia Region (ref ID02998/PI/05) and the CICYT MEDWSA (ref TIN1006-15175-C05-02), Ministry of Education and Science, Spain, for supporting this work. They also gratefully acknowledge the supply of components by Texas Instruments and Maxim for our planned network deployment.

References 1. Zhang, N., Wang, M., Wang, N.: Precision agriculture a worldwide overview. Comput. Electron. Agric. 36, 113–132 (2002) 2. Akyildiz, I.F., Su, W., Sankarasubramaniam, Y., Cayirci, E.: Wireless sensor networks: a survey. Comput. Netw. 38, 393–422 (2002) 3. Camilli, A., Cugnasca, C.E., Saraiva, A.M., Hirakawa, A.R., Corrêa, L.P.: From wireless sensor to field mapping: Anatomy of an application for precision agricultura. Comput. Electron. Agric. 58, 25–36 (2007)

42

J.A. López et al.

4. Pierce, F.J., Elliot, T.V.: Regional and on-farm wireless sensor networks for agricultural systems in Eastern Washington. Comput. Electron. Agric. 61, 32–43 (2008) 5. Morais, R., Fernandes, M.A., Matos, S.G., Serodio, C., Ferreira, P.J.S.G., Reis, M.J.C.S.: A ZigBee multi-powered wireless acquisition device for remote sensing applications in precision viticulture. Comput. Electron. Agric. 62, 94–106 (2008) 6. López Riquelme, J.A., Soto, F., Suardíaz, J., Sánchez, P., Iborra, A., Vera, J.A.: Wireless Sensor Network for precision horticulture in Southern Spain. Comput. Electron. Agric. (2009), doi:10.1016/j.compag.2009.04.006 7. IEEE Standard for Information Technology-Telecommunications and information exchange between systems-Local and metropolitan area networks- Specific requirements Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs). 1st Ed.; IEEE Standard Association, Piscataway, NJ, USA (2006) 8. A Serial-Digital Interface Standard for Microprocessor-Based Sensors. Version 1.3 (July 18, 2005). Prepared By SDI-12 Support Group (Technical Committee). USA (2005), http://www.sdi-12.org/ (accessed 10 March 2009) 9. López, J.A., Soto, F., Sánchez, P., Iborra, A., Suardiaz, J., Vera, J.: A. Development of a Sensor Node for Precision Horticulture. Sensors 9(5), 3240–3255 (2009) 10. Hill, J., Szewczyk, R., Woo, A., Hollar, S., Culler, D., Pister, K.: System architecture directions for networked sensors. Architectural Support for Programming Languages and Operating System. ACM SIGPLAN Notices 35, 93–104 (2000) 11. Gay, D., Levis, P., von Behren, R., Welsh, M., Brewer, E., Culler, D.: The nesC Language: A Holistic Approach to Network Embedded Systems. In: Proc. of the ACM SIGPLAN Conference on Programming Language Design and Implementation, San Diego, California, USA, pp. 1–11 (2003)

A Nephelometric Turbidity System for Monitoring Residential Drinking Water Quality Theofanis P. Lambrou1 , Christos C. Anastasiou2 , and Christos G. Panayiotou1 1

2

Dept. of Electrical and Computer Engineering, University of Cyprus, Nicosia, Cyprus {faniseng,christosp}@ucy.ac.cy http://www2.ucy.ac.cy/~faniseng/ Dept. of Civil and Environmental Engineering, Frederick University Cyprus, Nicosia, Cyprus [email protected]

Abstract. In this paper the design and development of a turbidity system for monitoring drinking water quality in households is presented. Its operation is based on the principle that the intensity of the light scattered by the suspended matter is proportional to its concentration. Unlike the commercially available turbidity meters, which are relatively expensive and bulky, the proposed device is small-sized, low power, lightweight, easy to use and inexpensive. Laboratory tests of the device have yielded satisfactory repeatability and precision. This sensor can be used as a part of a low cost sensor network consisting of different types of sensors (pH, temperature, chloride, etc) to provide water quality information to consumers. Fusing on-line multi sensor measurements, the system can provide useful information regarding hazardous agents and waterborne pathogens contaminants of household drinking water raising awareness and encourage better water-handling. Keywords: Turbidity measurement, turbidity sensor, nephelometry, water quality monitoring, light scattering sensor.

1

Introduction and Definition

Turbidity is the measurement of scattered light that results from the interaction of incident light with suspended and undissolved material in a water sample and it is an important water quality indicator. Turbidity is defined by the International Standards Organization (ISO) as the reduction of transparency of a liquid caused by the presence of undissolved matter. Turbidity can be interpreted as a measure of the relative clarity of water and often indicates the presence of dispersed, suspended solids; particles not in true solution such as silt, clay, algae and other microorganisms; organic matter and other minute particles. Solids in drinking water can support growth of harmful microorganisms and reduce the effectiveness of disinfection processes (i.e. chlorination, UV irradiation) resulting in increased health risks. In almost all water supplies, high levels of suspended N. Komninos (Ed.): SENSAPPEAL 2009, LNICST 29, pp. 43–55, 2010. c Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering 2010 

44

T.P. Lambrou, C.C. Anastasiou, and C.G. Panayiotou

matter are unacceptable for aesthetic reasons and can interfere with chemical and biological tests. Further, there is a need to find a surrogate for continuous monitoring of waterquality conditions, for both potable water systems, as well as for wastewater facilities and natural water systems, because traditional sampling techniques often are labor intensive and costly; data collection can be potentially unsafe; and, most importantly, there typically can be long time delays between sample collection, chemical analysis, and the posting of results. Excessive turbidity, or cloudiness, in potable water is aesthetically unappealing, and may also represent a health concern. Turbidity can provide food and shelter for pathogens. If not removed, turbidity can promote regrowth of pathogens in water distribution systems, leading to waterborne disease outbreaks, which have caused significant cases of gastroenteritis throughout the world. Suspended solids (the particles of turbidity) provide “shelter” for microbes by reducing their exposure to disinfectants. Further, waters with high turbidity from organic sources may give rise to a substantial chlorine demand. This could result in reductions in the free chlorine residual in distribution systems as protection against possible recontamination. Drinking water can serve as a transmission vehicle for a variety of hazardous agents (E. coli,, Legionella, arsenic, etc). Contaminants in drinking water can produce adverse effects in humans due to multiple routes (ingestion, inhalation and dermal) of exposure. In the EU, the quality of water intended for human consumption is governed by the Drinking Water Directive (DWD), Council Directive 98/83/EC. According to DWD [5] a set of microbiological and chemical parameters must be monitored and tested regularly and their values cannot exceed a predetermined threshold. Such parameters include Turbidity, Conductivity, E. Coli, pH, odour, taste etc. Moreover WHO [6] recommends the surveillance of household water storage systems as this water is more vulnerable to contamination. Regarding WHO [6] and EU DWD [5] drinking water turbidity value must not exceeding 1,0 NTU (nephelometric turbidity units) in the water ex treatment works. The appearance of water with a turbidity of less than 5 NTU is usually acceptable to consumers. In many countries (e.g Mediterranean region), given the fact that most water quality regulations pertaining to drinking water are applied before or at the point where water enters the distribution system, often makes it impossible for authorities and consumers to know the quality of potable water reaching their homes. Further, water cuts (due to decreasing water sources) put extra strain on the integrity of the distribution network, thus making water more susceptible to contamination before it reaches consumers. Moreover, many residences in water stress countries are making use of individual water reservoir tanks that are meant to store water for during the times that direct water supply is not feasible; standing conditions and remaining substances makes tank water vulnerable to contamination. Some epidemiological and outbreak investigations conducted, suggest that a substantial proportion of waterborne disease outbreaks is attributable to problems within distribution systems [4]. Studies of water distribution systems have shown related findings with respect to turbidity and

A Nephelometric Turbidity System

45

microorganisms [2]. Haas et al [1] noted that increased values of pH, temperature and turbidity were associated with increased concentrations of microorganisms. Under the circumstances mentioned above, it would be extremely useful, if a real-time turbidity monitoring system could be installed to act as a type of “early warning system” for possible potable water quality deterioration at homes. For such a system to be implementable though, turbidity systems that are cheap, easy to install and use, and could have capabilities of sending information, wirelessly, to a central data logging and processing facility would be essential. The main contribution of this paper is the development of such a system. Further to the aforementioned possible home use, currently, two separate research projects are under way, both of which are based on the above rationale. The first of these projects will seek to identify the level to which water rationing measures enforced in Cyprus influence the quality of potable water reaching consumers, while the second of the two projects seeks to identify the effect that storing water in roof-mounted reservoir tanks influences water quality in homes. The remaining of the paper is organized as follows: Section 2 presents the basic turbidity measuring techniques. Section 3 describes the design and development of the the proposed turbidity system. Section 4 describes the sensor calibration method and testing results. In Section 5 describes some interferences in turbidity measurement in drinking water applications. The paper concludes with Section 6.

2

Turbidity Measuring Techniques

Turbidity is measured using the techniques of turbidimetry or nephelometry and is expressed in arbitrary units (Nephelometric Turbidity Unit, NTU). The direct relationship between turbidity data and suspended solids concentration depends on many factors, including particle size distribution, particle shape and surface condition, refractive index of the scattering particles and wavelength of the light. There are three basic designs of turbidity meters [7],[8]: – the nephelometer, which measures directly the intensity of light scattered by the sample. The light intensity is directly proportional to the amount of matter suspended in the light path. The sensor is mounted at an angle (usually 90o ) to the traversing beam to record scattered light. Nephelometers usually provide greater precision and sensitivity than turbidimeters and are normally used for samples of low turbidity containing small particles. – the turbidimeter, sometimes called absorption meter, which measures the intensity of the beam after it has passed through the sample. Suspended matter in the light path causes scattering and absorption of some light energy. The transmitted light is measured, in relation to initial beam intensity. Turbidimeters are more appropriate for relatively turbit samples in which the scattering particles are large in relation to the light wavelength used. – the ratio turbidimeter, which measures both transmitted and scattered light intensities. For this purpose, transmitted light and 90o -scattered light are measured simultaneously with two different light sensors, which produce two voltages, V0 and V90 , respectively. Changes in the light absorption of the

46

T.P. Lambrou, C.C. Anastasiou, and C.G. Panayiotou

process medium, e.g. because of coloring, have the same influence on both 90 light sensors. Thus, the signal ratio, Vout = c1 ·V0V+c remains unchanged 2 ·V90 (c1 , c2 are calibration coefficients). This feature has a number of advantages, including the elimination of the effect of coloring on readings and the increase of the long-term stability of the instrument (due to reducing drift of light source intensity). This design appears to be more appropriate for liquids either strongly colored or of variable color concentration, and for samples of high turbidity. Continuous turbidity monitoring has become increasingly popular, mainly because the alternative practice of sampling and sedimentation analysis or filtration-and-weighing procedures are time-consuming and error-prone. Turbidity sensors probes may also be the only viable means of assessing suspended sediment changes in circumstances where conditions are harsh and access is limited. Generally, turbidity values can serve as a simple and convenient measure of the concentration of suspended solids in water-supply installations. The relatively high price of commercially available turbidity meters spurred intensive research on designing an inexpensive turbidity sensor, which would be reliable, with high frequency response and good spatial resolution, but at the same time easy to fabricate, portable and robust, thus suitable for field measurements. The purpose of this project is to design and construct a portable, inexpensive and sensitive nephelometer for potable water quality monitoring in households.

3

Design and Development

In commercially available instruments, both the light source and the photodetector are usually located inside the sensor housing. In order to reduce the probe size and at the same time to minimize interference with the water, a first attempt was made to place the electronic parts away from the probe using optical fibers. However, because the intensity of the light reaching the photosensor is generally low, as the nephelometer is intended for potable water measurements, even a small attenuation of the transmitted light would greatly affect the sensitivity of the measurements. Therefore, in order to improve the performance of the system, the light sensor was embodied in the probe. The measuring system under discussion is comprised of the following subsystems as shown in figure 1: An optical sensor (photodiode) and the signal conditioning circuit. A light source (red laser diode) and the laser driver circuit located in the device housing. The laser diode emits light, that is transmitted through an optical gap to the water sample. A PIC (Peripheral Interface Controller) microcontroller with a built in 10-bit Analog-to-Digital converter, a wireless zigbee transceiver for transferring turbidity measurements to measurement server (or a remote LCD display) and a local LCD module to display the turbidity measurement after digital processing. The photodiode is mounted at a 90o angle with respect to the light path. Turbidity is measured using an 670 nm 1mW visible red laser diode and detector in a scattered mode. A cross-section view of the sensor is shown in figure 2(a).

A Nephelometric Turbidity System

Photodiode

Amplifier

Laser Module

47

Wireless Transceiver PIC Microcontroller LCD Display Power Unit

Fig. 1. Turbidity System Architecture Laser Module

C CAP

R Water Level RESISTANCE

U1

Light Beam

Vout

Light Sensor Particles in water

90O scattered Light

(a) A cross-section view of the sensor

D1

OPAMP

PHOTODIODE

(b) Analog signal conditioning circuitry (transimpedance amplifier)

Fig. 2. Water Turbidity Sensor

The diode laser source, which has of high directionality, low power consumption and relatively high light intensity, is used to improve signal to noise ratio (SNR). The photodiode converts the scattered light directly into electrical current. The spectral sensitivity ranging from 500 nm to 800 nm. A high-gain (R = 320M Ω) low-noise CMOS (Complementary metaloxidesemiconductor) transimpedance amplifier converts photocurrent to voltage output (see Figure 2(b)). The conversion is directly proportional to light intensity (irradiance) on the photodiode. Figure 3 shows the PIC microcontroller circuitry schematic and prototype board layout design. The probe is a plastic cylinder whose length is 2.5 cm and its diameter 1.5 cm (figure 4(a)). A plastic case houses all other remaining subsystems (microcontroller circuitry, laser source, transimpedance amplifier, LCD display, battery, wireless transceiver, etc) as shown in figure 4(b). After sampling the sensor signal, the digital sensor value needs further conversion to be transformed to nephelometric turbidity units (NTUs) (see figure 4(c)). Because of the laser light source, the measurements received are very sensitive

T.P. Lambrou, C.C. Anastasiou, and C.G. Panayiotou

VDD

LCD1 LM032L

7805 VO

R4

GND

4.7k

R1

0.1uF

0.1uF

47u

R5

D2 LED-GREEN

2

C3

470

SW1

C4 0.1uF

VDD

J1 RV2

1 2 3 4 5 6 7 8 9 10

RES-VAR 1

2

GND

1

C2

1 2 3

C1

D0 D1 D2 D3 D4 D5 D6 D7

2

330

RS RW E

1N5817 CONN-SIL2

7 8 9 10 11 12 13 14

VI

3

VSS VDD VEE

1

1 2

PIC_MCLR

VDD

U1

J_POWER D1

4 5 6

48

3

GND

X1

PIC_VDD PIC_GND

1

RESONATOR

VDD GND

LCD

GND

3

2

VDD

GND PIC_MCLR

J_SENSOR Photodiode Circuit Laser Module

9 10 1 2 3 4 5 6 7

1 2 3 4 5 Sensor Con

U2

GND

BC337

Q1

R2 1k

D3 LED-RED

R3

OSC1/CLKIN OSC2/CLKOUT MCLR/Vpp/THV

RB0/INT RB1 RB2 RB3/PGM RB4 RB5 RB6/PGC RB7/PGD

RA0/AN0 RA1/AN1 RA2/AN2/VREFRA3/AN3/VREF+ RA4/T0CKI RA5/AN4/SS RC0/T1OSO/T1CKI RC1/T1OSI/CCP2 RC2/CCP1 RC3/SCK/SCL RC4/SDI/SDA RC5/SDO RC6/TX/CK RC7/RX/DT

21 22 23 24 25 26 27 28

J_ICSP 5 4 3 2 1 PIC_ICSP_CLK PIC_ICSP_DATA

11 12 13 14 15 16 17 18

PIC16F876 PACKAGE=DIL28NAR VDD=PIC_VDD VSS=PIC_GND

PIC_ICSP_CLK PIC_ICSP_DATA PIC_GND PIC_VDD PIC_MCLR

ICSP

J_ZIGBEE 1 2 3 4 5 zigbee

330

GND

(a) PIC microcontroller circuitry

(b) System board layout Fig. 3. Turbidity System Schematic

to small changes in turbidity and thus the output of the sensor is needed to be averaged to develop a smooth turbidity signal. Instantaneous readings may vary considerably as particle density changes or large particles move. We implement a moving average of the past five readings in order to stabilize the output signal. (See figure 5). Finally, the microcontroller performs all the necessary calculations-initializations and displays the resulting signal to the LCD display and also transmits the sense data to a measurement server using the wireless zigbee transceiver. The components for the complete prototype turbidity system cost approximately 30 euros, which is at least an order of magnitude less expensive than commercially available turbidity meters (which their market prices are around

A Nephelometric Turbidity System

(a) Sensor probe

(b) Prototype microcontroller board

49

(c) Turbidity system prototype

Fig. 4. Turbidity System Photos

Fig. 5. Moving average of turbidity data

600-1200 euros [11]). The overall power consumption of the packaged sensor when on board LEDs and LCD are removed is about 15mW. A better and more sophisticated low power design (enable microcontroller running in sleeping mode during idle periods, remove-replace some power hungry components, power diodes, better power regulator-battery matching, scale down the voltage to 3V) will enable the system to operate in near 3-5 mW (using PIC microcontroller, laser diode, sensor signal conditioning circuits and the wireless zigbee transceiver (Xbee)). Thus using 2AA alkaline batteries of 2.5AHr capacity each, the sensor system will run unattended for about 4000 hours (≈ 1/2 year).

4

Calibration and Testing

An indirect method for the sensor calibration was employed, in order to avoid the use of the carcinogen and expensive chemical formazin, a method which is considered as the common practice [7].

50

T.P. Lambrou, C.C. Anastasiou, and C.G. Panayiotou

Sensor volatge output Vo (mV)

The first attempt in developing stable turbidity samples was made by using skim milk (0.1% fat), which forms a homogeneous solution in water. We use a volumetric pipette to mixed skimmed milk with distilled water and create samples of various turbidities, all of which were stable. However, milk is an organic substance which means that it spoils over time. The final attempt was clearly better; we diluted hydrophilic cutting oil into distilled water using a volumetric pipette. The samples created were stable, homogeneous and nonorganic thus they do not change over time. The calibration procedure is as follows: A number of samples was created by diluted small volumetric values (mL) of hydrophilic cutting oil into 1L of

1000 900 800 700 600 500 400 300 200 100 0

Vo = 179,73x + 34,944

0,0 0,5 1,0 1,5 2,0 2,5 3,0 3,5 4,0 4,5 5,0 5,5 Hydrophilic cutting oil into 1L of distilled water (mL)

Turbidity T (NTU)

(a) Turbidity sensor voltage output vs hydrophilic cutting oil particles

130 120 110 100 90 80 70 60 50 40 30 20 10 0

T = 23,849x + 3,2187

0,0 0,5 1,0 1,5 2,0 2,5 3,0 3,5 4,0 4,5 5,0 5,5 Hydrophilic cutting oil into 1L of distilled water (mL) (b) Commercial turbidimeter measurements vs hydrophilic cutting oil particles Fig. 6. Turbidity System Calibration

A Nephelometric Turbidity System

51

distilled water using a volumetric pipette. Then, the turbidity of each sample is measured both by the new turbidity sensor (see figure 6(a)) and by a commercial turbidimeter (Hach 2100P) used as reference (see figure 6(b)). Using linear regression the relationship between the Vo (in mV ) of the new turbidity sensor and the mL of the hydrophilic cutting oil into 1L of distilled water (represented by x) is given by equation 1 (see figure 6(a)). Vo = 179.73x + 34.944, R2 = 0, 9942

(1)

Consequently, the relationship between turbidity T (N T U ) measurements of the commercial turbidimeter and the mL of the hydrophilic cutting oil into 1L of distilled water is given by equation 2 (see figure 6(b)). T = 23.849x + 3.218, R2 = 0, 9958

(2)

The combination of equations 1 and 2 gives the relationship between turbidity T (in N T U ) and the Vo (in V ) of the proposed turbidity sensor as shown by equation 3. T = 132.69Vo − 1.418 (3) Surprisingly, the sensor tends to have almost linear response in the range of 0 − 100N T U . Although negative turbidity values are very unusual to occur the system is programmed to zero such values. The repeatability of the measurements was checked by conducting a series of two sets of experiments and the results were satisfactory. A demonstration of the turbidity system developed is shown in figure 7.

Fig. 7. Demonstration of the turbidity system developed

52

5

T.P. Lambrou, C.C. Anastasiou, and C.G. Panayiotou

Interferences in Turbidity Measurement

The measurement of turbidity in drinking water applications is subjected to interferences mainly due to stray light and bubbles in the sample water. Other turbidity interferences are listed in [10]. A positive bias is usually reported from the previous interferences (slightly higher measurements than the actual turbidity. A usual solution of the stray light interference is the rationing (ratio turbidimeter). This method also improves problems related to color interferences and optical intensity drifts of the light sources. As the bubble interference is concerned the best way to decrease the interferences is to let the sample stand for several minutes to allow bubbles to vacate or perform large integration periods.

6 6.1

Conclusions and Future Work Conclusions

The proposed turbidity sensor appears to be suitable for continuous monitoring of potable water quality. The prototype developed is quite appropriate for turbidity measurements in the range of 0-100 NTU with precision of 0.2 NTU. The sensor is battery powered as both the LASER source and the signal conditioning circuitry have very low power requirements moreover the laser diode is switching only during measurements to further reduce power consumption. The overall power consumption of the packaged sensor when on board LEDs and LCD are removed is about 15mW. The current development can be used as a portable instrument. Modifications in sensor housing can enable in situ measurements of residential premises (i.e housing in a water supply pipe). Unlike some commercial turbidimeters, the proposed instrument is not equipped with a self-cleaning mechanism. In the current development a water shower is adequate to clean the sensor from the impurities deposited during the measurements. The device is of low cost and easy to develop, the construction materials are easily obtainable and the final cost of the whole device does not exceed 30 euros. This sensor can be used as a part of a low cost sensor network to provide water quality information to consumers. 6.2

Future Work

Providing clean drinking water to the population has become an increasing challenge with depletion of water sources and pollution of water bodies. The pollutants in the water can be broadly classified as metals, organic and pathogens. Contaminants in drinking water can produce serious health consequences. There is a need for monitoring the quality of the water at all stages, from the source till the end user. Our goal is to develop low-cost sensors for detecting pollutants in drinking water at residential premises. Rapid advances in IC technologies and micro-electrical-mechanical systems (MEMS) have enabled the generation of low power and inexpensive sensor networks. Microsystems technology offers new ways of combining sensing, signal

A Nephelometric Turbidity System

53

processing and actuation on a microscopic scale and allows a wide range of operational environments. The proliferation of wireless sensor networks and the recent efforts for the standardization of sensor communication under the IEEE 802.15.4 and Zigbee standards are beginning to facilitate a rapidly expansion applications. An inexpensive sensor network could be deployed to monitor the easily-measurable properties of water such as turbidity, temperature, pH, electrical conductance, total dissolved solids, chloride and others which are correlated with water quality. These properties could be measured with low-cost sensors and provide water quality information. Moreover sensors for arsenic and microbial contamination are currently under research development. It is worth to note that a technique of multi-angle light scattering has been developed for microbial classification. This low-cost sensor network could fuse on-line multi sensor measurements to make a complex decision about the quality of drinking water or even the identification of hazardous agents and waterborne pathogens. Finally the proposed sensor network could raising awareness and encourage better water-handling.

Acknowledgements This work is partly supported by the Cyprus Research Promotion Foundation under contracts ENIΣX/0505/30 and ΠΛHPO/1104/10.

References 1. Haas, C.N., Meyer, M.A., Paller, M.S.: Microbial alterations in water distribution systems and their relationship to physical-chemical characteristics. of American Water Works Association (1983) 2. Le Chevallier, M.W., Norton, W.D.: Examining Relationships Between Particle Counts and Giardia, Cryptosporidium, and Turbidity. Journal of American Water Works Association (1992) 3. Brumberger, et al.: Light Scattering. Science and Technology, 38 (1968) 4. Lee, S.H., Levy, D.A., Craun, G.F., Beach, M.J., Calderon, R.L.: Surveillance for waterborne disease outbreaks-United States, 1999–2000. In: CDC Surveillance Summaries, November 22 (2002) 5. European Communities (Drinking Water) (No.2) Regulations (2007) 6. World Health Organization Guidelines for drinking-water quality, third edn. (2004) 7. Lawler, D.M.: Turbidimetry and Nephelometry. In: Encyclopedia of Analytical Science. Academic Press Ltd., UK (1995) 8. Basic turbidimeter design and concepts. EPA. Turbidity Guidance Manual (1999), http://www.epa.gov/safewater/mdbp/pdf/turbidity/chap11.pdf 9. HACH Company. Portable Turbidimeter Model 2100P, Instrument and Procedure Manual 10. Sadar, M.: Making Sense of Turbidity Measurements - Advantages in Establishing Traceability Between Measurements and Technology. In: 2004 National Monitoring Conference, Chattanooga, TN, USA (2004) 11. http://www.google.com/products?q=portable+turbidity+meters

54

T.P. Lambrou, C.C. Anastasiou, and C.G. Panayiotou

Appendix: Theory of Light Scattering Very simply, the optical property expressed as turbidity is the interaction between light and suspended particles in water. A directed beam of light remains relatively undisturbed when transmitted through absolutely pure water, but even the molecules in a pure fluid will scatter light to a certain degree. Therefore, no solution will have a zero turbidity. In samples containing suspended solids, the manner in which the sample interferes with light transmittance is related to the size, shape and composition of the particles in the solution and to the wavelength (color) of the incident light. A minute particle interacts with incident light by absorbing the light energy and then, as a point light source itself, reradiating the light energy in all directions. This omnidirectional reradiation constitutes the ”scattering” of the incident light. The spatial distribution of scattered light depends on the ratio of particle size to wavelength of incident light [3]. Particles much smaller than the wavelength of incident light exhibit a fairly symmetrical scattering distribution with approximately equal amounts of light scattered both forward and backward (see Figure 8(a)). As particle sizes increase in relation to wavelength, light scattered from different points of the sample particle create interference patterns that are additive in the forward direction. This constructive interference results in forward-scattered light of a higher intensity than light scattered in other directions (see Figure 8(b) and Figure 8(c)). In addition, smaller particles scatter shorter (blue) wavelengths more intensely while having little effect on longer (red) wavelengths. For example blue light tends to be scattered by the oxygen and nitrogen molecules in the atmosphere giving the blue sky we

(a) In small particles (smaller (b) In large particles (approximately 1/4 than 1/10 the wavelength of the wavelength of light) scattering concenlight) scattering is symmetric trated in forward direction

(c) In larger particles (larger than the wavelength of light) scattering in extremely concentrated in forward direction. Also maxima and minima of scattering intensity are developed at wider angles Fig. 8. Angular patterns of scattered intensity from particles of three sizes. (a) small particles, (b) large particles, (c) larger particles.(Source:[3]).

A Nephelometric Turbidity System

55

see!. Conversely, larger particles scatter long wavelengths more readily than they scatter short wavelengths of light. Particle shape and refractive index also affect scatter distribution and intensity. Spherical particles exhibit a larger forwardto-back scatter ratio than coiled or rod-shaped particles. The refractive index of a particle is a measure of how it redirects light passing through it from another medium such as the suspending fluid. The particle’s refractive index must be different than the refractive index of the sample fluid in order for scattering to occur. As the difference between the refractive indices of suspended particle and suspending fluid increases, scattering become more intense. The color of suspended solids and sample fluid are significant in scatteredlight detection. A colored substance absorbs light energy in certain bands of the visible spectrum, changing the character of both transmitted light and scattered light and preventing a certain portion of the scattered light from reaching the detection system. Light scattering intensifies as particle concentration increases. But as scattered light strikes more and more particles, multiple scattering occurs and absorption of light increases. When particulate concentration exceeds a certain point, detectable levels of both scattered and transmitted light drop rapidly, marking the upper limit of measurable turbidity. Decreasing the path length of light through the sample reduces the number of particles between the light source and the light detector and extends the upper limit of turbidity measurement.

Deployment of a Wireless Ultrasonic Sensor Array for Psychological Monitoring Roland Cheng, Wendi Heinzelman, Melissa Sturge-Apple, and Zeljko Ignjatovic University of Rochester, Rochester, NY 14627, USA {rocheng,wheinzel}@ece.rochester.edu, melissa [email protected], [email protected]

Abstract. The deployment of a wireless sensor network to monitor subjects’ locations and relative distances during psychological experiments is discussed. As its primary function, an overhead array of ultrasound sensors automatically tracks a parent, child and stranger over a 4.45 m×4.23 m observation area. The array of ultrasonic-equipped motes can resolve two point targets separated by at least 73 cm. Each sensor can detect the range to the nearest object with 20 cm resolution. Challenges with setting up the 6 × 6 ultrasonic imaging array and with establishing a Kalman tracking filter are also detailed. This WiPsy (Wireless sensors for Psychology research) system provides accurate, real-time quantitative metrics for psychological evaluation in lieu of traditional qualitative manual coding. Moreover, tracking subjects using ultrasound sensors is less error-prone than existing methods that track based on human coding of video. Overall, WiPsy strives to streamline data acquisition, processing, and analysis by providing previously unavailable assessment parameters. Keywords: Ultrasound, sensor network, imaging array, WiPsy.

1

Introduction

The theory of attachment, the enduring emotional bond between infant and caregiver, was first developed by psychiatrist John Bowlby in the late 1960s. Based upon conceptualizations derived from the disciplines of ethology and psychology, attachment theory posits that the quality of the parent-child relationship, particularly during infancy and early childhood, has significant implications for children’s socio-emotional development. Children who form strong, healthy attachments to their caregivers are also more likely to form high quality relationships later in life. In Bowlby’s theory, the attachment relationship serves the adaptive function of providing protection and support to the child, particularly in the face of distress and threat. Using the concept of behavioral systems, Bowlby theorized that in the attachment relationship, the mother is regarded as a “secure-base” from which the infant explores and habituates to the outside environment. In times of safety and security, the infant feels free to investigate his surroundings in attempts to understand and master his environment. Think of a child putting N. Komninos (Ed.): SENSAPPEAL 2009, LNICST 29, pp. 56–67, 2010. c Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering 2010 

Deployment of a Wireless Ultrasonic Sensor Array

57

a toy into his mouth or banging it on the floor. Bowlby would have viewed this as exploratory behavior. Under threatening or distressful conditions, the infant returns to the mother for soothing comfort and protection. Thus, the mother is the base from which the infant derives comfort and explores. Attachment researchers regard the child’s use of distance negotiation with the mother under conditions of safety and threat as an important indicator of the quality of the mother-infant attachment bond. In order to study attachment behavior, psychologists use the well-established Strange Situation Paradigm developed by Ainsworth. The paradigm calls for a child to play with toys in the presence of a parent, a stranger, both, or alone. By monitoring the child’s distance negotiation under these different stress conditions, psychologists can infer the quality of the child’s attachment to the mother [1]. For over 30 years, the distance between the child-parent and childstranger have been assessed by trained human coders. The coding process is unsatisfactorily qualitative and tediously slow. The system described in this paper replaces human coding with more accurate, quantitative measurements. During the strange situation experiments, an ultrasonic video of the observation room is recorded using a wireless array of ultrasound sensors. The ultrasound data is processed in real time through a tracking filter, which extracts the positions of the child, parent, and stranger and displays the child-parent and child-stranger distances. This gives psychologists the ability to assess behavioral distance negotiation instantaneously. Furthermore, given that the attachment relationship exists across multiple behavioral levels including physiological and psychological levels, this system allows researchers to simultaneously compare assessments across multiple levels of analysis.

2

System Architecture

The complete system architecture consists of two major components: the imaging subsystem and the tracking subsystem. The former is composed of an overhead array of 6 × 6 Tmote Sky motes, each equipped with a set of Devantech SRF05 ultrasonic transmitter/receiver transducers. The array transmits all echo measurements via wireless communication to a base station, which assembles and displays a real-time image of the room using Matlab. This data is also fed into a tracking filter, which estimates the positions of three possible targets within the room. Once positions are determined, the child-parent and child-stranger distances are computed and displayed. Instead of using conventional wired communication, the imaging system relays information over a wireless channel as an investigative procedure to determine whether fading channels have sufficient bandwidth for conveying real-time ultrasound images. Future work may include a means of easily deploying a movable, battery-operated version of the array into homes for in situ psychological monitoring. Conventional wireless sensor networks often require a device be placed onto each tracked target [2, 3]. Such systems include Olivetti Research’s Active

58

R. Cheng et al.

Badge [4], AT&T’s Active Bat [5], Microsoft’s RADAR [6], MIT’s Cricket [7], and Ascension’s MotionStar [8]. However, this imaging system must avoid using tracking tags on targets because child targets are often unwilling to wear them. Attempts to attach such tags result in the child’s uncooperation or a forced tag removal midway through the experiment. To circumvent this limitation, the imaging system is set up as a large-scale ultrasonic array akin to conventional ultrasonic arrays used in fetal imaging. In essence, the ultrasonic array takes snapshots of the room without requiring targets to wear specialized tracking devices. Other tracking systems that also do not require the wearing of tracking tags are computer vision systems [9, 10]. However, those systems suffer from larger processing requirements and possible occlusion problems [2]. This system requires comparatively less computation and avoids most occlusion situations. 2.1

Mote Development Environment

The Tmote Sky motes are programmed using the TinyOS development environment. TinyOS version 2 is chosen for access to the high resolution timers. These 32 kHz clocks enable the ultrasound sensors to provide a vertical height resolution of approximately 1 cm. However, in practice, these clocks are empirically slowed down by a factor of 20, which corresponds to a vertical resolution of about 20 cm. The justification for this reduced clock speed is simply to give the microprocessor sufficient CPU time to perform required computations (such as checking the radio for received packets) instead of being inundated with processing timer triggers. Since the smallest subjects, 18-month old children, typically have heights around 80 cm [11], this decreased resolution does not affect the system’s detection ability. 2.2

Sensor Array

Attached to each ceiling-mounted mote is a downward-facing ultrasound sensor, shown in Figure 1. When signaled by the mote, the sensor emits an 8-cycle, 40 kHz ultrasound pulse. This directed pulse returns to the detector after being reflected off either the floor or an interposed object. The flight time of the pulse gives the range to the closest object below the sensor. Usually, this object is a subject’s head, a chair, a toy on the floor, or the floor itself. By arranging a 6 × 6 grid of these ultrasound sensors (shown in Figure 2), an image of the 4.45 m × 4.23 m observation room can be taken. Locations of targets of interest are extracted from this image using peak detection. The sensor array is capable of discerning two adults separated by at least 73 cm. Objects separated by less than this minimum distance will appear to the imaging system as a single entity. 2.3

Tracking Filter

Because of the poor spatial resolution of these ultrasound images, multiple, closely clustered targets appear as a single peak instead of as separate individuals. To

Deployment of a Wireless Ultrasonic Sensor Array

59

Fig. 1. Ceiling-mounted mote with attached ultrasound sensor

circumvent this problem, a tracking filter is implemented to estimate the subjects’ positions when the imaging system is unable to resolve all targets. One of the simplest linear tracking filters to use is the Kalman filter. This adaptive filter minimizes the mean square error between a set of noisy measurements and some (noiseless) state space variables, assuming the state variables form a Markov chain. Some advantages with using a Kalman filter over a Wiener filter are the former’s causal nature and its ability to handle non-stationary processes [12]. Therefore, the Kalman filter can be used for real-time tracking and imposes few assumptions about the data’s behavior. The vector Kalman filter implemented in this system assumes that the state space variable s[n|n] at current time n evolves according to a Gauss-Markov model. Specifically, the state variable of three tracked targets is represented as an 18-element tuple:   s[n|n] = s1 [n] s2 [n] s3 [n] (1)   si [n] = xi [n − 1] xi [n] vi,x [n] yi [n − 1] yi [n] vi,y [n] (2) where (xi [n], yi [n]) is target i’s location at time n and vi [n] is the target’s velocity also at time n. The estimate ˆs[n|n] of the state variable at time n is incrementally computed using the prediction vector ˆs[n|n − 1], the Kalman gain vector K[n], the noisy observation vector w[n], the minimum predicted mean square estimate matrix M[n|n − 1], and the minimum mean square error matrix M[n|n]. All of the previous quantities are either given or can be computed from (4), (5), (6), and (7): ˆs[n|n] = ˆs[n|n − 1] + K[n] (w[n] − Hˆs[n|n − 1])

(3)

ˆs[n|n − 1] = Aˆs[n − 1|n − 1]

(4)

60

R. Cheng et al.

(a) Worm’s eye view

(b) Profile view Fig. 2. 6 × 6 array of motes

Deployment of a Wireless Ultrasonic Sensor Array

61

 −1 K[n] = M[n|n − 1]HT C + HM[n|n − 1]HT

(5)

M[n|n − 1] = AM[n − 1|n − 1]AT + BQBT

(6)

M[n|n] = (I − K[n]H) M[n|n − 1]

(7)

where A is the state transition matrix; H is the matrix transforming s[n|n] into w[n]; C is the covariance matrix of the white, Gaussian measurement noise added to s[n|n]; B is the matrix transforming the driving noise term u[n] into additive noise for s[n − 1|n − 1]; Q is the covariance matrix for u[n]; and I is the identity matrix. The recursion is initiated using ˆs[0|0] = [110110110110110110] and M[0|0] = C [12]. That is, the initial state assumes that all targets are stationary and start at the door, which is located at (1,1). In the tracking filter, H and B are further simplified and assumed to be identity matrices. Thus, the state variable s[n|n] and the noisy observation vector w[n] are identical in size. It is further assumed that each target’s x- and y-locations operate independently and that all three targets move mutually independently. Given these independence assumptions, the covariance matrices C and Q, and the state transition matrix A are almost diagonal matrices: ⎤ ⎡ c00000 ⎢0 c 0 0 0 0⎥ ⎥ ⎢ ⎢0 0 c 0 0 0⎥ ⎥ (8) C=⎢ ⎢0 0 0 c 0 0⎥ ⎥ ⎢ ⎣0 0 0 0 c 0⎦ 00000c ⎡ 2 ⎤ σ 0 0 c = ⎣ 0 σ2 0 ⎦ (9) 0 0 2σ 2 Q = 0.001I ⎤ a00000 ⎢0 a 0 0 0 0⎥ ⎥ ⎢ ⎢0 0 a 0 0 0⎥ ⎥ A=⎢ ⎢0 0 0 a 0 0⎥ ⎥ ⎢ ⎣0 0 0 0 a 0⎦ 00000a ⎡ ⎤ 0 1 0 a = ⎣ 0 1 Δt⎦ 1 1 − Δt Δt 0

(10)

⎡

(11)

(12)

1 = 1 s, and the 0 entries in C and A are 3×3 mawhere σ 2 = 1, Δt = frame rate trices of zero. The choice of the variance value for Q was empirically determined

62

R. Cheng et al.

to balance between the smoothness of tracking target movements against the slow response time of tracking fast-moving targets. With larger variance values for (10), the position estimates abruptly jump between the locations determined by the peak detectors. On the other hand, smaller variance values yield smoother position tracking at the expense of having a slow response to targets with rapidly altering velocities. Internally, the Kalman filter assumes that targets move in simple rectilinear motion. Therefore, the state transition matrix A predicts a target’s current location based on its previous position and velocity, and determines the target’s new velocity from the current and previous positions. Older position measurements were not used to calculate velocity to allow for fast-changing velocities. Notably, this occurs when the target alters direction or speed, which breaks the rectilinear motion assumption.

3

Surmounted Challenges

In order to create the current system, several obstacles have to be surmounted. First, the power constraint is avoided by deploying a network of USB cables and hubs. Second, two conflicting goals have to be reconciled: imaging noise quality versus imaging speed. Image noise is mitigated by sensing in a staggered access pattern and by using differential image calibration. Image noise can also be minimized by waiting for secondary reflections to attenuate, at the expense of decreased frame rates. On the other hand, imaging speed can be increased by transmitting multiple sensor readings simultaneously. 3.1

Power Network

Typically, sensor networks have severe power restrictions because of the limited charge carrying capacity of modern batteries. Because this imaging system monitors subjects during psychological experiments, a system whose power source must be frequently replaced is unacceptable. More so, the nature of the psychological experiments implies that each experimental trial can only be performed once. Thus, having a mote battery deplete in the middle of a running experiment must be avoided. To circumvent this power constraint, a power network has to be deployed to give each sensor an unlimited power source. The most convenient course of action is to network together several commercial USB hubs, USB cables, and power strips. Such a power network can supply 5 V to each mote through existing USB ports, which are present on each Tmote Sky mote. Although 5 V are being supplied by the power network, the output voltage supplied by the mote to the ultrasound sensor is only 3 V. Since each mote can be powered by two 1.5 V AA batteries, a mote can only send a maximum of 3 V through its output pins. As shown in Table 1, the sensors require a nominal power supply of 5 V. This 2 V shortfall actually does not drastically reduce the sensor performance. The ultrasound sensors still operate correctly at 3 V, but have a smaller object-detection range.

Deployment of a Wireless Ultrasonic Sensor Array

3.2

63

Sensor Access Pattern: Noise vs. Speed Tradeoff

The ultrasound sensor determines range based on the first reflection received after transmission. However, this primary reflection continues to bounce around the room long after its initial detection. These secondary reflections pose a problem if they are detected by other sensors. In particular, if an adjacent sensor hears the secondary reflection emitted from another sensor before it hears its own primary reflection, then the adjacent sensor would infer the incorrect range to the object underneath it. The detection of secondary reflections yields noisy ultrasound images. One way to ameliorate this problem is by having only one single sensor emit a pulse at a time. If multiple sensors were to simultaneously emit ultrasound pulses, the probability of detecting a secondary reflection would be increased. Instead, by partitioning time access over the room, each sensor can send and receive an echo during its own time slot without interference from other sensors. Secondary reflections can also be mitigated by increasing the effective spatial separation between consecutive transmitters or by increasing the time duration between transmitter emissions. The first method can be done with no penalty to the video frame rate. By increasing the distance between transmitters, a secondary echo must propagate farther and undergo more reflections before hitting another listening sensor. This additional traveling attenuates the secondary echoes until they are beneath the detection threshold. In practice, the physical distance between sensors need not be changed in order to increase the spatial separation. Instead, re-ordering the sensor access pattern from the raster order shown in Figure 3a to the staggered order shown in Figure 3b is equivalent to increasing the distance between ultrasound firings. Contrary to increasing the spatial separation, increasing the temporal separation between consecutive transmitters decreases the video frame rate. By making each sensor time slot longer, secondary reflections are allowed more time to reverberate and attenuate before the next sensor fires. However, by doing so, the total time needed to acquire a complete frame is also increased, which leads to decreased video frame rates. To avoid crippling the frame rate, the time slot

4

5

6

2

6 10 4

8 12

1

2

3

7

8

9 10 11 12

24 20 16 22 18 14

5 15 11 6 16 12

13 14 15 16 17 18

26 30 34 28 32 36

17 9

19 20 21 22 23 24

1

2 14 7

25 26 27 28 29 30

23 19 15 21 17 13

6 16 12 5 15 11

31 32 33 34 35 36

25 29 33 27 31 35

18 10 3 17 9

(a) Raster ordered access

(b) Single-transmit, staggered access

5

9

3

7 11

Fig. 3. Sensor access patterns

1 13 8

2 14 7

4 18 10 3 1 13 8 4

(c) Multiple-transmit, staggered access

64

R. Cheng et al.

length T0 is set to twice the minimum time needed to detect the primary reflec2hceiling = 25 ms, where the ceiling height tion. That is, T0 = 2tround-trip = 2 c hceiling is 2.13 m and the speed of sound in air c is 343 m/s. This yields a video frame rate of about 1 frame per second. Setting T0 to twice the minimum time is an empirical compromise that decreases image noise without sacrificing too much frame rate. The imaging frame rate can be increased by simultaneously sending ultrasound pulses from different sensors. To avoid detecting secondary reflections, the spatial separation technique can be applied without a speed penalty. Thus, a hybrid approach between sending simultaneous pulses and using spatial separation can be used to increase the frame rate without introducing too much noise. The array access order for this technique is shown in Figure 3c. 3.3

Differential Calibration

Another way to decrease image noise is by performing differential calibration. By taking a picture of the empty observation room and subtracting that image from every video frame, fixed pattern noise can be eliminated. Fixed pattern noise can arise from minor sensor-to-sensor or mote-to-mote variations, or simply from static background noise. In this case, background noise is the dominant source of fixed pattern noise, as shown in Figure 4. The figure shows a large peak due to echoes reflecting off the one-way observation mirror.

0.4 0.3 0.2 0.1 20 0 15 10

5 10

5

15 20

Fig. 4. Image of fixed pattern noise of the empty observation room

4

Results

A sample frame of the ultrasound images captured during the Strange Situation Paradigm is shown in Figure 5.

Deployment of a Wireless Ultrasonic Sensor Array

65

child

2 4 6 8 10

parent

y

stranger

12 14 16 18 20 5

10

15

20

x

Fig. 5. Ultrasonic image of stranger, child and parent in observation room (bird’s eye view)

4.1

Performance of Distance Tracking

3.5

3.5

3

3

2.5

2.5 y−position (m)

x−position (m)

Figure 6 compares an adult’s tracked position with the sensor acquired measurements and the human-coded position readings. The mean square errors between the Kalman-filtered position estimates and the human-coded positions are MSEx = 0.23 m2 in the x-direction and MSEy = 0.59 m2 in the y-direction.

2

1.5

2

1.5

1

1

0.5

0.5

0

0

10

20

30 time (s)

40

(a) x-position

50

60

0

0

10

20

30 time (s)

40

50

60

(b) y-position

Fig. 6. XY position of tracked subject. Black solid lines are human-coded positions; dotted red points are sensor acquired positions; dashed green lines are Kalman-filtered output of the sensor measurements.

66

4.2

R. Cheng et al.

System Specifications

Relevant specifications for the sensor and the array are summarized in Table 1. Table 1. Sensor and array specifications

array

sensor

Specification Nominal Actual ⎧ ◦ half-power beamwidth 40 ⎪ ⎪ ⎨ 5V 3V power supply max detectable distance 4m 2.1 m ⎪ ⎪ ⎩ 20 cm ⎧ resolution in propagation direction 73 cm × 73 cm ⎨ resolution in azimuth plane sensor separation 61 cm × 61 cm ⎩ 4.45 m × 4.23 m observation area

5

Conclusion

The WiPsy ultrasonic imaging array serves to replace human-coded distance tracking with automatic, accurate distance measurements taken during psychological experiments. A successful deployment of the sensor array requires overcoming several challenges, including creating a power network, scheduling a sensor access pattern, and using differential calibration.

6

Future Work

It is possible to extend the current work in at least two ways: utilize phase information to generate higher quality ultrasound images and track subjects using the forward-backward propagation algorithm. The current imaging system sends a series of directed ultrasound pulses to sample the scene. Instead, by using omnidirectional ultrasound pulses and processing the scattered signal at every sensor node, the signal can be amplified by an array gain. With proper signal processing, and perhaps spread-spectrum apodization, a higher-quality ultrasound image may be generated, much as is done in medical ultrasound imaging [13]. The current tracking filter is a causal Kalman filter. By removing the causality constraint, a more generalized algorithm can be used for tracking. The backwardforward propagation algorithm can use past and future information to more accurately determine the current location of a target. Such algorithms have proven quite successful in decoding digital capacity-approaching codes [14]. Acknowledgements. The lead author must acknowledge the effort of two undergraduates, Kyle Aures and Jian Chen, whose work during the summer of 2007 bootstrapped the deployment of the WiPsy ultrasonic sensor array. Furthermore, funding for this research has been provided by the National Institute of Nursing Research (R21 NR010857).

Deployment of a Wireless Ultrasonic Sensor Array

67

References 1. Ainsworth, M.D.S., Blehar, M.C., Waters, E., Wall, S.: Patterns of Attachment: A Psychological Study of the Strange Situation. Lawrence Erlbaum Associates, Hillsdale (1978) 2. Hightower, J., Borriello, G.: Location Systems for Ubiquitous Computing. Computer 34 (August 2001) 3. Niculescu, D., Nath, B.: Ad Hoc Positioning System (APS). In: IEEE Globe-Com, San Antonio, TX (November 2001) 4. Want, R., Hopper, A., Falc˜ ao, V., Gibbons, J.: The Active Badge Location System. ACM Transactions on Information Systems 10 (January 1992) 5. Harter, A., Hopper, A., Steggles, P., Ward, A., Webster, P.: The Anatomy of a Context-Aware Application. In: 5th ACM International Conference on Mobile Computing and Networking (MOBICOM), Seattle, WA (August 1999) 6. Bahl, P., Padmanabhan, V.N.: RADAR: An In-Building RF-Based User Location and Tracking System. In: Proceedings of IEEE Infocom, Tel-Aviv, Israel (March 2000) 7. Priyantha, N.B., Chakraborty, A., Balakrishnan, H.: The Cricket Location- Support System. In: 6th ACM International Conference on Mobile Computing and Networking (MOBICOM), Boston, MA (August 2000) 8. Ascension Technology Corp., Burlington, VT, Technical Description of DC Magnetic Trackers (2001) 9. Atiya, S., Hager, G.: Real-Time Vision-Based Robot Localization. In: Proceedings of 1991 IEEE International Conference on Robotics and Automation, Sacramento, CA (April 1991) 10. Krumm, J., Harris, S., Meyers, B., Brumitt, B., Hale, M., Shafer, S.: Multi-Camera Multi-Person Tracking for Easy Living. In: Proceedings of 3rd IEEE International Workshop on Visual Surveillance, Dublin, Ireland (July 2000) 11. Kuczmarski, R.J., Ogden, C.L., Grummer-Strawn, L.M., Flegal, K.M., Guo, S.S., Wei, R., Mei, Z., Curtin, L.R., Roche, A.F., Johnson, C.L.: CDC Growth Charts: United States. Advance Data (December 2000) 12. Kay, S.M.: Fundamentals of Statistical Processing, 1st edn., vol. 1. Prentice-Hall, Englewood Cliffs (1993) 13. Szabo, T.L.: Diagnostic Ultrasound Imaging. Elsevier Academic Press, Burlington (2004) 14. Gallager, R.G.: Low Density Parity-Check Codes. MIT Press, Cambridge (1963)

WISEBED: An Open Large-Scale Wireless Sensor Network Testbed Ioannis Chatzigiannakis1 , Stefan Fischer2 , Christos Koninis1 , Georgios Mylonas1 , and Dennis Pfisterer2 1

Computer Technology Institute and University of Patras, N. Kazantzaki, Rio, Patras, Greece {ichatz,koninis,mylonasg}@cti.gr 2 University of L¨ ubeck and Institute of Telematics, Ratzeburger Allee 160, L¨ ubeck, Germany {fischer,pfisterer}@itm.uni-luebeck.de

Abstract. In this paper we present an overview of WISEBED, a largescale wireless sensor network testbed, which is currently being built for research purposes. This project is led by a number of European Universities and Research Institutes, hoping to provide scientists, researchers and companies with an environment to conduct experiments with, in order to evaluate and validate their sensor network-related work. The initial planning of the project includes a large, heterogeneous testbed, consisting of at least 9 geographically disparate networks that include both sensor and actuator nodes, and scaling in the order of thousands (currently being in total 550 nodes). We present here the overall architecture of WISEBED, focusing on certain aspects of the software ecosystem surrounding the project, such as the Open Federation Alliance, which will enable a view of the whole testbed, or parts of it, as single entities, and the testbed’s tight integration with the Shawn network simulator. We also present examples of the actual hardware used currently in the testbed and outline the architecture of two of the testbed’s sites. Keywords: WISEBED, testbed, sensor network, large-scale, experiment, open, federated, portal, web services, heterogeneous, actuators, software library, simulation.

1

Introduction – Motivation

In the last few years, we have begun to witness the effects of turning a vast number of heterogeneous objects into one large and decentralized network, as a result of a growing trend to interconnect the natural and the digital worlds. A variety of methods and technologies is being used to realize the Internet-of-things vision, where myriads of networked devices will allow the provision of ubiquitous computing services and closer inspection of the physical domain. Still, the largescale effects of the interaction between hardware, software, algorithms and data are just starting to show, and many of the resulting emerging phenomena often come as a surprise, rather than by design. N. Komninos (Ed.): SENSAPPEAL 2009, LNICST 29, pp. 68–87, 2010. c Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering 2010 

WISEBED: An Open Large-Scale Wireless Sensor Network Testbed

69

Until very recently, scientific efforts for studying computing methodologies for decentralized complex systems have been very limited. A particularly promising and active research area, in this context, is wireless sensor networking (WSN), which is attracting researchers from very different backgrounds, such as hardware, software, algorithms, etc., as well as researchers from various application areas. So far, the number and size of actual testbeds for sensor networks has been rather limited. All of these efforts have been struggling with a number of different issues: – Hardware. Developing/acquiring small-scale devices for sensor networks is a tedious/expensive task. – Software. Dealing with the limitations of small-scale special-purpose computing devices makes it very challenging to develop appropriate software. – Algorithms. Dealing with the challenges of designing algorithms for wellorganized, large-scale distributed systems requires new algorithmic methods. – Data. The large volume of collected sensing information, as well as the communication overhead gives rise to huge amounts of data. WISEBED [1] is a European research project that will try to overcome some of these impediments by building a network of networks. More specifically, it will expose a network of heterogeneous sensor network testbeds, together with a unified and universal approach to software, algorithms, and data. Connecting sensor networks to the Internet creates endless opportunities for applications and services, new emerging models of operation. Users will be able to get real-time data from the physical world for everything, everywhere and anytime. To make such a vision a reality, be effective and produce applicable results, it is important to encourage interaction and bridge the gap between fundamental (theoretical) approaches and technological/practical solutions. WISEBED, in general, involves the following long-term actions: – Deploy large numbers of wireless sensor devices of different hardware technologies in different types of terrains to use for evaluating and testing solutions at a large scale. – Interconnect these wireless networks with the Internet and provide a virtual unifying laboratory to enable testing and benchmarking, in a controlled way, in different “real-life” situations. Researchers will be able to use the facilities remotely, thus reducing the need for a local, private testbed and, more importantly, reducing the cost for conducting all-rounded research. – Operate the testbeds to collect traces of data from the physical environment and derive models of real-life situations and scenarios. These scenarios will be used to evaluate the performance of algorithms and systems and draw conclusions on their operation and how it can be improved. – Provide a repository of algorithms, mechanisms and protocols and develop a library, called WISELIB, that can be directly used in experiments with WISEBED.

70

2

I. Chatzigiannakis et al.

Previous Related Work

In this section we give a brief description of a number of existing wireless sensor network testbeds and related software environments. We chose to include only testbeds of significant scale or based on their unique characteristics (e.g., mobile nodes, open to the public, etc.). The characteristics we chose to highlight include total number of nodes, indoor or outdoor deployment, heterogeneity support, overall architecture and topology, openness to the public, total operational time. Existing testbeds. The Trio testbed [2] was one of the largest wireless sensor testbeds, indoor and outdoor, built yet. The main target was to build and demonstrate a large-scale outdoor sensor testbed to be used in a multi-target tracking application. It consisted of 557 solar-powered motes, seven gateway nodes, and one overall testbed server. It was not open to the public research community, since it was targeted to a specific application. MoteLab [3] is an indoor sensor network testbed on the campus of Harvard University and is open to the public. It currently features 190 Tmote Sky sensor nodes. All sensor nodes are wired to programming boards allowing for direct reprogramming and communication. It was designed having in mind that the testbed should be both open and easy to use for other researchers, i.e., users from other research teams should have access for experimentation to real large-scale sensor networks. It provides a webbased interface for programming, debugging, and accessing data from the sensor network. The TWIST testbed [4] resides indoor in a building in the campus of the Technical University of Berlin, spanning across several floors. The total number of sensor nodes belonging to the testbed is 200, with heterogeneity supported to some extent. The TutorNet testbed [5] uses a 3-tier network topology (similar to TWIST but without any abilities to work in other topology modes) with testbed servers, gateway stations, and sensor nodes, which feature USB connections to the gateway stations. Services provided include remote programming of the nodes. Authorized-only users connect to the testbed servers and use command-line tools to control the testbed nodes. The total number of sensor nodes is approximately 100. Intel SensorNet [6] (now discontinued) is an indoor sensor network testbed that featured 100 MicaZ sensor nodes in the Berkeley Intel Research facilities. It allows resource allocation between multiple users submitting their jobs to be scheduled and executed in the sensor testbed. Kansei [7] is another sensor testbed targeted towards large indoor sensor networks. It currently features 210 sensor nodes, with 210 gateway stations attached to each one of the sensor nodes. It features a web-based interface for researchers, which allows for submitting jobs to the testbed, visualization of sensor readings, debugging and health monitoring, along with other sophisticated features. Only registered users can use this testbed. TrueMobile (Mobile Emulab wireless sensor network testbed, [8]) is an extension to the popular EmuLab wireless ad hoc networks testbed. The mobile testbed currently covers a total area of 60 m2 , and is situated indoor, and includes six mobile robots and 25 fixed Mica2 motes. EmuLab is an open testbed to the public (registered users). CitySense [9] is an urban (both indoor and outdoor) sensor network testbed, consisting of 100

WISEBED: An Open Large-Scale Wireless Sensor Network Testbed

71

wireless sensors deployed across a city, such as on light poles and buildings. Each node consists of an embedded PC with wifi and various sensors for monitoring weather conditions and air pollutants. CitySense is intended to be an open testbed. SENSEI [10] is another EU Research Project, aiming among other to provide a Pan-European test platform, enabling large scale experimental evaluation and execution of field trials - providing a tool for long term evaluation of the integration of sensor and actuator networks into the Future Internet. We should point out that, apart from TWIST and SENSEI, all the other testbeds are situated in the United States. Related Software. One of the most important problems in designing applications for WSNs is the heterogeneity in hardware and operating systems, especially when talking about a distributed testbed operated in different domains. It makes sense to add an integration layer somewhere between hardware and application, called middleware. Creating middleware for WSNs is a challenge, mainly due to resource restrictions. We point the reader to a number of survey papers on WSN middleware [11,12,13,14,15]. Simulation is also an invaluable tool for evaluating protocol designs for complex systems such as WSNs, that are either comprised of a large number of interacting entities, systems that exhibit highly dynamic behavior or systems where directly performing an experiment is difficult due to cost or time constraints. A number of simulators have been developed and/or extended to allow the modeling and simulation of WSNs. Most notable examples of such simulators are ns-2, OMNeT++, OPNET Modeler, GTNetS and YANS. Some attempts to bridge the gap between simulation and real-world performance and to make the transition smoother have been proposed in international literature, such as TOSSIM [16], which takes advantage of TinyOS’s structure to generate discrete-event simulations directly from TinyOS component graphs. The level of detail provided by these simulation tools is resource-demanding and limits simulations to small scenarios with only a few thousand of nodes while future scenarios anticipate networks with millions of nodes. A very important aspect of developing an application for wireless sensor networks and deploying an operational sensor network is testbed debugging. Simulations and lab deployments in controlled environments cannot always reveal weaknesses and errors in the design and implementation of such applications, especially since the physical world can heavily influence the overall operation of these systems. Debugging refers both to software parameters and network parameters (mostly connectivity issues). There must also be an easy way to detect and track down problems during the normal operation of the network, i.e., after the end of the development cycle. The problems in the operation of a wireless sensor network can be classified into four categories: node problems, link problems, path problems, and global problems affecting large portions of the network. Some examples of debugging software for WSN are: the Sensor Network Management System (SNMS, [17]), designed for debugging TinyOS applications; Sympathy [18], designed for sensor networks that follow a central gateway model;

72

I. Chatzigiannakis et al.

Memento [19], an environment that provides, apart from failure detection, symptom alerts, i.e., reports on degrading performance and failures that may happen in the future according to certain symptoms; Marionette [20], a software environment that allows easy interaction with applications written in nesC, running in TinyOS-based sensor networks; and Sensor Network Inspection Framework (SNIF, [21]), which follows a more passive approach by using a separate backbone network that intercepts all data transmitted over the air inside the wireless sensor network. A software environment for managing sensor testbeds associated with the SENSEI project is SIGNETLAB [22]. Other interesting examples of software environments that focus on “replaying” activity inside the sensor network are LiveNet [23] and [24]. Our contribution: Existing wireless sensor testbeds are mainly deployed in indoor environments, only few have above 100 nodes, most are not publicly open to other researchers to test their own ideas, and there is little support for heterogeneity and mobility. In general, a tightly coupled network and software architecture is followed, thus limiting the extendibility, customize-ability and relocation ability of such testbeds. Our approach aims at overcoming several of these limitations: – We plan to develop and deploy several connected testbeds, each with several hundred nodes. – We plan to connect these testbeds into a much larger heterogeneous network (with a few thousand nodes), creating the potentially largest sensor network testbed in the world. – This federation of testbeds is based on the concept of testbed virtualization and virtual links between them. – The system will provide a variety of interfaces for end-users and applications. – We aim at providing a unified algorithmic and software environment, thus overcoming the impediments of customization and allowing for convenient usage of the testbed.

3

Overall Architecture and Considerations

This section introduces WISEBED’s general architecture (cf. Figure 1). We consider the WISEBED distributed testbed as a global network where human users, intelligent agents, and powerful computers interact with the wireless sensor network testbeds. In particular, we distinguish the global network into three sub-domains: – The overlay network where peers are applications executing on powerful computer devices that have the ability to communicate with other peers via Internet or other global networks. – The sensor devices that form wireless sensor network testbeds and communicate via the wireless medium.

WISEBED: An Open Large-Scale Wireless Sensor Network Testbed

73

– The portal servers that consist of nodes that control the wireless sensor network testbeds and allow for interaction between the overlay peers and the sensor devices. Essentially, the architecture of the WISEBED system is based on a hierarchy of layers where each layer is comprised of one or more peers (see Figure 1). Each layer is assigned a particular role in the system. Each peer may be a traditional networked processor or a wireless sensor device. – The bottom layer contains the wireless sensor nodes that are running iSense, Contiki, TinyOS, or legacy systems. These devices form wireless networks that constitute the WSN testbeds. – The testbeds of each partner are controlled by Portal Servers that provide access and expose interfaces to manage and operate them. Users can connect to a single testbed directly via the Internet accessing the interface provided by the particular portal server. In order to do so, users must be aware of the public IP address of the individual portal servers. – The portal servers of each testbed partner site are interconnected via an overlay network. Peers connecting to the overlay network may access one or more portal servers in order to use multiple testbeds in a distributed manner. In order to do so, users are not required to know the public IP address of the portal servers. Overlay Software running on the Portal Server

TUD

TUBS

Testbed Portal Servers at each WISEBED Partner Site

Each WISEBED Partner maintains its own testbed with different hardware equipment and setup

UBERN

UPC

UZL

Overlay Network

ULANC

FUB

UNIGE

CTI

Users connect to a single testbed directly using Web Services defined by the OFA standard

CTI

Users connect to the federated testbed using the Web Services defined by the OFA standard via the Overlay Network

Fig. 1. Overall architecture of the WISEBED testbed federation

74

I. Chatzigiannakis et al.

The advantageous distributed characteristics of the system are achieved via a series of functions and mechanisms (services) which are activated by the system as a response to various kinds of events, processes, actions, applications that take place on it. Rather than following a multi-tiered architecture, in which a number of tiers are operating in a specific hierarchical way and specific interfaces are used for communication across each layer, we choose to follow a less tightly coupled architecture in order to offer more flexibility to the system. Interaction among services is performed over all the levels of the system, in order to exchange necessary information for the successful accomplishment of each of them. Software agents (services) running on a peer are considered as independent modules that may interact with other services on the same peer and/or software agents executed by nearby peers. This flexibility allows the overlay network to spontaneously federate multiple portal servers into a Virtual Distributed Testbed and expose their services as a single unifying virtual testbed. Thus, users connected to the overlay network can access the unifying distributed testbed in the same way they access individual testbeds via the portal servers. Due to the architecture of the overlay nodes and portal servers, the interfaces exposed look identical and therefore there is no need to re-write their code. In addition, the overlay network can partition specific nodes (not necessarily from the same testbed) and expose their services as a single unifying virtual testbed. Furthermore, due to the heterogeneity of the devices but also to the very nature of such a global system for testbed interconnection, each peer may operate with a different set of software agents, i.e. provide a subset of the available services, and may provide different versions of a particular service, i.e. provide different quality and functionality. In this sense, we point out that: – Each wireless device may operate a different set of software agents, i.e., provide a subset of services. – Each wireless device may operate different versions of a particular service. – Each portal server may operate under different implementation of a particular service that provides a subset of services. The structure of the peers of our system follows a modular architecture of essentially two layers: the inner layer that is comprised of minimum set core functionalities and an outer layer that hosts a variety of services. Portal Server. These peers are responsible for the control and management of the WSN testbed of a single partner. The inner layer includes services responsible for accessing the sensor devices via gateways to the wireless networks. User commands are translated to a binary packet format that is generic enough so that it can be implemented by the different hardware/software technologies available in WISEBED. Each portal server is connected to one or more local data stores (e.g., XML files, RDBMS systems, embedded databases etc.) for storing data retrieved from the database, debug traces, access lists etc. The outer layer implements a series of services that are used by the users of the testbed. Users can access the services of the outer layer via the public IP interfaces of the Portal Servers.

WISEBED: An Open Large-Scale Wireless Sensor Network Testbed

75

Overlay Node. These peers are responsible for the interconnection of the WSN testbeds of each partner. The inner layer contains client software of the services of the Portal Servers. User commands are directed to the corresponding service interface of the relevant Portal Server. Each overlay node is connected to one or more local data store for storing data retrieved from the Portal Servers (debug traces, access lists etc.) for future reference. The outer layer provides interfaces that are similar to those offered by the Portal Servers. Essentially they are proxy (or skeleton) interfaces that translate the incoming requests to one or more Portal Server. High-level description of Web Services. It is our intension to provide Open Standards for both high-level services and low-level network interfaces. We organize these services in three groups: – Authentication, Authorization, Accounting (AAA). Each portal server is part of an AAA system spanning across all federated testbeds. We will deploy the well-established, decentralized PKI-based authentication and authorization infrastructure Shibboleth to protect and simplify the inter-organizational access to the sensor network testbeds. Shibboleth is an open-source attributebased access control system basing on state of the art cryptography and security protocols. By making the portal servers available and joining the federation, each testbed operator offers its testbed resources to all affiliated WISEBED partners. – Network Control, Debugging and Configuration (MGT). Fully integrated portal server offer services for programming the nodes of the testbed (new binary image) and for debugging the state of the nodes (energy, communication, memory, debug interfaces using out of band methods). They also provide services for configuring the operation of the nodes (channel, transmission power). – Data Acquisition, Query Processing, Network Operation (OPT). Portal servers (both fully integrated and semi integrated) provide a description of the testbed offered to the community. This is a list of the devices of the testbed and their capabilities. We will use and extend the SensorML standard for describing the available hardware. This group of services also allows the selection of low-level protocols or combination of protocols (from WISELIB) and the programming of the nodes from existing, tested, known binary images. It provides services for accessing the data retrieved from the sensors and issuing queries for data.

4

Software Aspects of WISEBED

In the following we give some further details concerning a number two of the important software aspects of WISEBED, specifically its integration with the Shawn network simulator and the federation of discrete sensor testbeds.

76

4.1

I. Chatzigiannakis et al.

Integration with the Shawn Network Simulator

Shawn [25,26,27] is a simulation framework for WSNs with unique features for the development of algorithms, protocols and applications, that will play a major part in WISEBED. It does not compete with traditional simulators in the area of network stack simulation; instead, it focuses on an abstract, repeatable and expressive approach to WSN simulation. By replacing low-level effects with abstract and exchangeable models, the simulation can be used for huge networks in reasonable time while keeping the focus on the actual research problem. In the case of a MAC layer, for example, Shawn models the effects of a MAC layer for the application (e.g., packet loss, corruption and delay) instead of performing simulations including radio propagation properties such as attenuation, collision, fading and multi-path propagation. As a result, simulations are more predictable and there is a performance gain since such a model can be implemented very efficiently. Shawn requires orders of magnitudes less resources in terms of memory and CPU-time compared to traditional approaches and scales literally to millions of nodes Shawn allows to reduce the process of porting simulated code to actual sensor nodes by using just a mere recompile. There is already implemented support for the Pacemate [28] and the iSense [29] sensor nodes. This allows using the same code for the sensor nodes and the simulation tool thus relieving developers from reimplementing the software for different types of hardware. A direct consequence of this architecture is that Shawn can be used as a virtual testbed, thus simplifying the development of our WISEBED testbed software infrastructure. For developers of testbed applications this simplifies the development before software is actually deployed on real hardware since standard debugging tools can be used. 4.2

Federation of Testbeds and Related APIs

In this section we will discuss further the testbeds’ federation concept, presented in Section 3. As mentioned previously, WISEBED will provide abstractions so as to be able to use resources from different testbeds in a transparent manner. WISEBED aims to hide the inherent heterogeneity of the participating sensor networks to the end-user, so that even nodes with different types of hardware situated in discrete geographic areas will be able to communicate with each other. One way of dealing with the variety of possible scenarios in this case is the use of virtual links between the discrete testbeds. Such links will essentially create “tunnels” between testbeds and sensor nodes. An ambitious goal of the project is to provide to end-users the ability not only to use nodes from different sensor networks, but also to be able to define, to a certain extent, links between nodes belonging to these discrete networks and essentially be able to define network topologies. The introduction of virtual links naturally inserts additional complexity in the operation of the system, as well generates additional issues regarding the realism achieved by the experiments conducted within the scope of the project, and will be further researched through the course of WISEBED.

WISEBED: An Open Large-Scale Wireless Sensor Network Testbed

77

WISEBED will investigate, among other, the efficiency of using such virtual links in order to implement a distributed testbed over a variety of different kinds of infrastructure, since there is a varying degree in the use of direct wired connections to the testbed nodes in the currently deployed sensor networks. This is due to the fact that these networks on the one hand have to a certain degree different target applications, and on the other hand may be deployed indoors or outdoors. Thus, the testbeds’ backbone may range from completely wired, i.e., all nodes are directly connected to testbed gateways, to completely wireless, i.e., all nodes are wirelessly linked between each other and to hybrid approaches. Figure 2 depicts ways of using virtual links to interconnect sensor testbeds in different infrastructure architecture scenarios. We will now briefly discuss the entities related with the Data Acquisition and Network Operation(OPT) API of WISEBED as a whole and each portal server in particular (see section 3). In short, this API allows programmers and applications to interface with the testbed in order to have access to data describing the setup of the testbed, with regard to the resources used and the underlying networks’ operation, acting as a testbed directory. The design goal for these services are: – To take advantage of the already defined and used open standards such as SensorML, in order to extend the application scope of the project overall. – To supply a flexible interface that will accommodate the varying needs of several different types of users(protocol designers, application programmers) who choose to use the WISEBED infrastructure. – Enable the interaction with groups and research projects such as OGC, SANY FP6 project, CONET. First of all, we need to define a method to describe and uniquely identify all the different entities of the testbed - we use the following entities as a basis: – Sensor nodes - We define sensor nodes as the unique nodes comprising each of the partner testbeds in WISEBED. Each sensor node belongs to only one sensor network. So, each sensor node belonging to WISEBED is described using the unique ID of the partner site, a sensor network ID which is unique in the partner site namespace, and the sensor node ID which is unique in the specific sensor network scope it belongs to. – Node capabilities - With the term node capability we refer to the sensing and acting possibilities offered by each specific node. Node capabilities include sensor types, supported interfaces and other hardware information. – Edge attributes - Edge attributes describe characteristics such as the quality of the link between two sensor nodes of the testbed. – Node attributes - Sensor nodes of each WISEBED sensor network are represented as nodes of the aforementioned graph. We describe such nodes with attributes as whether is a gateway/base station. – Testbed portal servers - Each partner in WISEBED maintains a portal server, offering a defined set of services. For the description of such services refer to the respective deliverables.

78

I. Chatzigiannakis et al.

Fig. 2. Different types of testbed infrastructure (wired, wireless, hybrid) and virtual links between them

– Points of interest - Points of interest in WISEBED refer to specific areas, covered by the sensor networks belonging to WISEBED. To give some examples of the API that will be used in WISEBED, Portal Servers, among others, will provide the following interfaces: string getRecords(): Returns a GraphML document containing the complete list of nodes and the network topology1 . GraphML is an XML dialect used to “draw” a graph, by defining a set of nodes and the edges connecting these nodes, together with sets of attributes describing the nodes and the edges of the graph. Each such graph represents a discrete sensor network, that is controlled through the use of one (or maybe more) gateway nodes. string getCapabilities(string urn): Returns all the urn key values, for the specified sensor node, or sensor network. string describeCapability(string urn): For the specified capability, it returns a full description in SensorML. SensorML is an XML dialect used to describe “Sensor Webs”, i.e., entities (sensor nodes or networks of sensor nodes) connected to the Internet. It provides a very descriptive schema of sensors, nodes, and a large number of related attributes. string getKml(): Returns a KML document containing a description of the networks contained in a Portal Server or the whole WISEBED infrastructure. KML is the language used by Google Earth in order to describe all data related 1

When referring to “complete list” we imply the “authenticated list of nodes”.

WISEBED: An Open Large-Scale Wireless Sensor Network Testbed

79

to that specific application, including geographic information, visual representation, time-related state, etc. It can be seen as an alternative description of GraphML and SensorML data provided by previously mentioned functions. It is a widely used data format, which is also beginning to be used in other GISrelated applications. string getRecordsInArea(double x1, double y1, double z1, double x2, double y2, double z2): Returns a GraphML document containing the list of nodes and the respective network topology, that are within a specified area. This area is essentially defined as a cube, by providing longitude, latitude and altitude of two discrete points on Earth’s surface.

5

Hardware Aspects of WISEBED – Current Deployment

Existing sensor network testbeds, in terms of hardware, are mainly characterized by small scale, homogeneity and tight integration between hardware and software, i.e., the selection of a certain hardware platform implies the adoption of a specific complementary software platform and vice versa. The so far lacking adoption of software and hardware standards by the sensor network research community, poses further restraints in the interoperability of the existing testbeds. Such limitations have of course a big impact on the applications that can be eventually implemented and tested by researchers and developers. WISEBED aims to lift such restrictions by: – federating testbeds of considerable size (in the order of hundreds of nodes) into “virtual” unified testbeds of large scale (in the order of thousands). The initial planning is for approximately 2000 nodes at the end of the project, with the number currently (March 2009) being approximately 550. – offering heterogeneity, by adopting a number of hardware platforms. Heterogeneity is expressed in the form of using hardware with different computational resources, sensing resources, or the associated software resources. – using various network topologies, mirroring the various application needs. Such topologies can be flat, hierarchical, having wired or wireless backbone, etc. – placing the testbed nodes in various “realistic” settings, in order to simulate the conditions for certain applications such as building monitoring or natural disasters (e.g., river floods), indoor/outdoor, etc. – using mobility to a certain degree, in order to encompass the development of mobility-related applications. A number of mobile robots, such as Roomba, will be used to enable such applications. – using standardized radio interfaces. The multiplicity of different hardware platforms prevents a collaboration of devices from different vendors. The IEEE 802.15.4 standard is a step towards homogeneous and interoperable WSN hardware platforms. A number of the project partners use compatible 802.15.4 radio interfaces.

80

I. Chatzigiannakis et al.

The processors used in the testbed’s nodes are ranging from quite powerful, such as Intel PXA2xx series processors used in iMotes and GumStix, to much less powerful, e.g. MSP430F1612 used in MSB430. The minimum flash memory is 48KB (Tmote Sky nodes) and the minimum RAM is 2KB (EBS nodes), while the maximum flash and RAM resources is 32MB each (iMote). The wireless interfaces include IEEE 802.11b/g, IEEE 802.15.4 operating at 2.4GHz and other 900MHz radios. There is a variety of other interfaces present, such as Bluetooth, USB, JTAG, etc. A complete range of sensors is available ranging from the most commonly used ones, such as temperature, light, humidity, to other less common sensors like magnetometers and accelerometers. A variety of operating systems enable the users to experiment on the platforms they prefer. An analytic description of the current state of the overall testbed is included in [30]. We will now describe in more detail two specific WISEBED sites. 5.1

L¨ ubeck Testbed Description

Univerzit¨at z¨ u L¨ ubeck (UZL) currently operates two testbeds. Because of their different radio interfaces, the two different testbed nodes can only communicate via the gateway nodes. A gateway node is a normal node with an additional interface to communicate with a PC. The testbed PCs are connected among each other via a TCP/IP network to interact with the other testbed and over the Internet with the users participating in WISEBED. The first testbed uses the Pacemate nodes (developed as part of the MarathonNet project, see [31]). These nodes are wearable and are developed to realize services for athletes during a marathon. The testbed consist of approx. 50 sensor nodes (extensible to 500) and mobile gateways. These nodes are equipped with Philips LPC2136 processors and a Xemnics RF module running at 868 MHz. The Pacemates offer an ergonomic waterproof housing, are very light-weight and are easily attached to the back of the hand. They have a display and offer three buttons. Additionally, they are equipped with the following interfaces: – A serial extension interface for additional sensors. – A short range wireless heart rate receiver. – A long range wireless interface. The second testbed consists of up to 50 iSense nodes by coalesenses GmbH [29]. The gateway nodes as well as all other nodes have a Gateway Module with a permanent USB connection to a PC. This enables to power all nodes through the USB and guarantee a twenty-four-seven operating mode. The iSense Software is used to implement applications for the Pacemate as well as the iSense nodes. At the moment there is an iSense implementation for the iSense and Pacemate hardware and the Shawn simulation framework. Out of this reason it is possible to write an application with iSense, test it with the Shawn simulation framework and compile the same source code just using a different cross-compiler for the iSense or Pacemate architecture. In addition to the iSense platform, Coalesenses GmbH provides a software tool called iShell to communicate with the network and receive debug information

WISEBED: An Open Large-Scale Wireless Sensor Network Testbed

81

Table 1. Overview of the pacemate and iSense Hardware pacemate iSense RAM 64kB 96kB Serial Flash 256kB 128kB Current draw operation 47mA 39mA Current draw sleep mode 60µ A 10µ A Frequency 868 MHz 2,4GHz Bandwith 115kbit/s 250 kbit/s Transmission power 15dB 3dB Transmission range 100m 600m

from the nodes. iShell is running on a PC, which is connected to one or more gateway nodes via a USB connection. Through the PC and iShell, users can get data output (e.g., sensor readings), network status information and debug messages. Furthermore, the user can directly program the connected gateway nodes and indirectly program the other nodes in the network via over-the-air programming. The testbed PCs are connected amongst each other using cables or WiFi connections via the internet. UZL is currently planning to enhance its testbed with mobility support. An autonomous mobile sensor network, i.e., a network where the mobility of nodes does not rely on humans, will be introduced. UZL will purchase a small number of mobile robots, which will be able to carry iSense sensor nodes and are controlled by these sensor nodes. Apart from forming their own testbed, these robots can also be used as mobile gateways between fixed sensor nodes, in order to extend their reach and the size of the overall network. 5.2

RACTI Testbed Description

The testbed in Research Academic Computer Technology Institute (RACTI) in Patras currently spans over two locations at the University of Patras’ campus. These two locations include the main premises of RACTI and another building used to house several offices of RACTI’s Research Unit 1. Currently, these sensor networks are mainly used to monitor condition inside these two buildings, including parameters such as temperature, light, humidity, acceleration, levels of magnetic fields, barometric pressure. In the near future we will also add sensing features such as movement/presence and vehicle detection. The hardware architecture used for the purposes of our testbed has three hierarchical levels: – the first level includes the nodes at the sensor network level, – the second level includes the (stationary or mobile) gateways used to interface the sensor network to the rest of the world, – the third level includes the servers used to store information and administer the testbed. The deployment of the devices follows the structure of RACTI’s building; each floor of the building is divided in two or three sectors, with each sector separated

82

I. Chatzigiannakis et al.

with the others communication-wise, due to thick walls and metallic doors. A gateway device is used to interface the devices located in each part of the building, with the selection of the gateway based on the type of sensor nodes used. We chose to use wall plug mounts to power almost all of the sensor nodes inside the testbed, due to the difficulties arising from changing batteries in a large testbed and also to its demand for continuous availability. Currently, the testbed spans across 4 floors, covering almost one third of RACTI’s main building. In general, currently, we use devices provided by Crossbow and Sun on the sensor network level. At a glance, RACTI’s testbed consists of the following devices: – 20 Crossbow Mica2 devices, along with a number of additional sensor boards. – 20 Crossbow TelosB devices, with embedded temperature, light, and humidity sensors. – 45 Sun SPOT devices, with embedded light, temperature and acceleration sensors. – 60 iSense sensor nodes, with a variety of sensor boards (50 environmental sensor boards with temperature and light sensors, 9 security sensor boards carrying a PIR camera and a 3-axial accelerometer and 1 vehicle detection sensor board carrying a magnetometer) – 2 Crossbow Stargate Netbridge devices, used as stationary gateways. – 2 Crossbow MIB600 network programmers. – 5 Alix devices, used as stationary gateways. – 3 netbook-class laptop computers used as mobile gateways. The operating system used in the testbed, for the Mica2 and TelosB devices is TinyOS. We have recently started using Octopus (and customized it as well) for the tasking of these two types of devices inside our testbed, so the relevant code is written in NesC using TinyOS 2.x libraries. A few nodes have the Crossbow XMesh firmware installed on them. Sun SPOTs run a customized Java virtual machine, called SquawkVM, that is fully J2ME-capable and also serves as the operating system as well, so all code regarding the Sun SPOT devices is written in Java. As for the software running on the testbed gateways, we are using Xubuntu on the Alix and the Netbook gateways; a customized Debian distribution is used on the Stargate Netbridge gateways, provided by Crossbow. This customized distribution also has the MoteWorks software (by Crossbow) installed, that is used to collect readings from the nodes using the XMesh firmware. For the management of RACTI’s testbed we mainly use WebDust. WebDust is a software platform for monitoring and controlling a multitude of disparate wireless sensor networks, using a peer-to-peer infrastructure for the communication between the different networks comprising the system, in order to achieve great scalability. The system’s overall goals, apart from scalability, are to greatly simplify sensor network deployment, maintenance, and application development by offering a set of implemented services to the user and an extensible architecture to the developer, and also to offer heterogeneity by supporting a number of

WISEBED: An Open Large-Scale Wireless Sensor Network Testbed

83

Fig. 3. Testbed at RACTI through Google Earth using Webdust

hardware platforms. We currently support Mica2, MicaZ, TelosB, Sun SPOT, and iSense in the near future. It offers a user interface related to the concepts described above, by using software like Google Earth and Google Maps. Furthermore, we are working on integrating control functionality extensions to our system, thus making actor networks a part of the system as well. In Figure 3 the layout of the deployment of RACTI’s testbed through Google Earth can be seen.

6 6.1

Use-Case Scenarios – Research Challenges Scenarios

We now give two use-case scenarios for WISEBED users, in order to give insight regarding the potential uses of this testbed. Scenario 1. Suppose that Mr. Doe wants to test whether his new promising routing protocol for sensor networks in mesh topologies has actually a good performance. First, he develops the code for the Shawn network simulator with the aid of WISELIB library for other functionality the algorithm needs, and tests it using simulation experiments. After the initial implementation, Mr. Doe turns to WISEBED and using the user interface reserves a total of 150 nodes for his experiments. Simulated nodes in Shawn can interact with real nodes since they run the same code. Using Shawn the experiments were run with a total number of 20000 nodes; now the total number of nodes has reached 20150. The difference is that these additional 150 nodes add a new realistic dimension to the whole

84

I. Chatzigiannakis et al.

experiment, by offering the ability to check whether the algorithm works right in real nodes and also scales well to thousands of nodes. Scenario 2. Suppose that Mrs. Smith, working on an office and building automation application, wishes to test whether her software is functioning properly in practice. She would like input on events like turning on/off lights, motion sensors detecting movement in specific offices, etc. She first connects to the WISEBED infrastructure using the authorization/authentication services of the project, and reserves some testbed resources (e.g., 5 office rooms and the sensors associated with these offices). She then uses the provided services in order to retrieve (live) data about the occurrence of events in the network and its operation. We make the assumption that the testbed nodes are running some “default” software that enables such actions. 6.2

Research Challenges

We outline here some characteristic examples of the research challenges related with the project. Federation of testbeds - transparency. As described previously, the project revolves around a federation of testbeds that will provide a unified environment. This approach poses many challenges due to the heterogeneity of software and hardware in all of the different parts of the testbed. The notion of reserving resources from parts of disparate project sites (e.g., 50 nodes from site A and another 40 from site B), even in the case of using the exactly same type of nodes and software, injects additional complexity to the project. Interconnection with the testbed. Existing testbeds do not provide much in the ways of interfacing to the rest of the world, i.e., they usually provide a GUI to reserve some resources, upload your binary code and view results after the execution of the experiment; some environments offer the capability of monitoring the actual situation inside the network (network topology, radio activity, etc.), but all of these is often not provided in a systematic way. WISEBED aims to provide all of these capabilities in such a way, by using web services definitions and standards like SensorML, thus simplifying the whole process of interfacing with the system from an application’s or developer’s view. Software and hardware platform independence - Transparency. From a practical point of view, conducting research that combines both theory and practice must deal with considerable difficulties. To name a few, wireless sensor network application developers should acquire skills regarding embedded software engineering, dealing with low-level hardware devices and understanding the peculiarities of the wireless channel (hidden terminal problem, power versus distance model) etc. Still, even if all these skills are acquired, the cost of setting up and maintaining an experimental facility of significant size can be very high. Furthermore, deploying the experimental network into a realistic environment requires iteratively reprogramming dozens of nodes, positioning them

WISEBED: An Open Large-Scale Wireless Sensor Network Testbed

85

throughout an area large enough to produce an interesting radio topology, and instrumenting them to extract debugging and performance data. WISEBED aims to provide a library of sensor network-related functionality in order to simplify the whole process of developing code for these networks and abstracting many of the details from the users and the applications. Efficiency. The sheer volume of the nodes expected to be included in the testbed, along with many of the factors mentioned previously, naturally poses efficiency challenges. From the one side, we have the software running on the sensor network level, both as the main application and as a “backbone” service. On the first case efficiency is a necessity, on the second case the software must interfere with the rest of the system as little as possible or find ways to “hide” such activity from the user. In the other side we have the software interfacing the system with the outside world, that has to provide efficient ways to represent the information related to the operation of the testbed (e.g., a system-wide directory) or graphical end-user interfaces (current related implementations leave a lot to be desired).

7

Conclusions – Future Work

As of today, mainly isolated sensor network testbeds exist across Europe and the rest of the world. Their homogeneity, small scale and narrow application scope limit their use, up to a large degree, as a means to answer most of the research challenges related to wireless sensor networks. We have presented in this paper an overview of the WISEBED project, that tries to answer these challenges by the establishment of a large-scale sensor network by a number of federated testbed sites and the provision of a software platform to the public, in order to easily utilize all these resources. WISEBED is currently being developed, already having a number of testbed sites established. Future work on the project involves the expansion of the existing testbed sites, both in scale and heterogeneity, and the implementation of the software ecosystem surrounding the project. There is a large body of work related to the interconnection of the testbed sites, the development of an algorithmic library providing implemented solutions compatible with the existing testbed to application developers, and also the tighter integration between the testbed and virtual (simulated) sensor networks.

Acknowledgments This work has been supported by the ICT Programme of the European Union under contract number ICT-2008-224460 (WISEBED). We would also like to thank S. Fekete and A. Kr¨oller for providing one of the insightful use-case scenarios mentioned in section 6.

86

I. Chatzigiannakis et al.

References 1. WISEBED project website, http://www.wisebed.eu/ 2. Dutta, P., et al.: Trio: enabling sustainable and scalable outdoor wireless sensor network deployments. In: 5th International conference on Information processing in sensor networks (IPSN), pp. 407–415. ACM Press, New York (2006) 3. Werner-Allen, G., Swieskowski, P., Welsh, M.: Motelab: A wireless sensor network testbed. In: Fourth International Conference on Information Processing in Sensor Networks (IPSN). IEEE, Piscataway (2005); special Track on Platform Tools and Design Methods for Network Embedded Sensors (SPOTS) 4. Handziski, V., Kopke, A., Willig, A., Wolisz, A.: Twist: A scalable and reconfigurable wireless sensor network testbed for indoor deployments. Tech. Rep. TKN05-008 (November 2005) 5. Tutornet: A tiered wireless sensor network testbed, http://enl.usc.edu/projects/tutornet/ 6. Chun, B.N., et al.: Mirage: A microeconomic resource allocation system for sensornet testbeds. In: 2nd IEEE Workshop on Embedded Networked Sensors (2005) 7. Ertin, E., et al.: Kansei: A testbed for sensing at scale. In: 5th International conference on Information processing in sensor networks, IPSN (2006) 8. Johnson, D., et al.: Mobile emulab: A robotic wireless and sensor network. In: 25th IEEE Conference on Computer Communications, INFOCOM (2006) 9. Murty, R., Mainland, G., Rose, I., Chowdhury, A., Gosain, A., Bers, J., Welsh, M.: Citysense: An urban-scale wireless sensor network and testbed. In: 2008 IEEE Conference on Technologies for Homeland Security, May 2008, pp. 583–588 (2008) 10. SENSEI project website, http://ict-sensei.org/ 11. Henricksen, K., Robinson, R.: A survey of middleware for sensor networks: Stateof-the-art and future directions. In: Proc. of MidSens 2006 (2006) 12. Hadim, S., Mohamed, N.: Middleware challenges and approaches for wireless sensor networks. IEEE Distributed Systems Online 7(3) (2006) 13. Romer, K., Kasten, O., Mattern, F.: Middleware challenges for wireless sensor networks. ACM Mobile Computing and Communications Review 6, 59–61 (2002) 14. Kuorilehto, M., Hannikainen, M., Hamalainen, T.: A survey of Application Distribution in Wireless Sensor Networks. EURASIP Journal on Wireless Communication and Networking 5, 774–788 (2005) 15. R. Project, Survey of middleware for networked embedded systems, deliverable 5.1 (2005) 16. Levis, P., Lee, N., Welsh, M., Culler, D.: Tossim: accurate and scalable simulation of entire tinyos applications. In: SenSys 2003: Proceedings of the 1st international conference on Embedded networked sensor systems, pp. 126–137. ACM Press, New York (2003) 17. Tolle, G., Culler, D.: Design of an application-cooperative management system for wireless sensor networks. In: European Cinference on Wireless Sensor Networks, EWSN 2005 (2005) 18. Ramanathan, R., et al.: Sympathy for the sensor network debugger. In: 3rd International Conference on Embedded Networked Sensor Systems (SenSys), pp. 255–267 (2005) 19. Rost, S., Balakrishnan, H.: Memento: A health monitoring system for wireless sensor networks. In: SECON 2006 (2006)

WISEBED: An Open Large-Scale Wireless Sensor Network Testbed

87

20. Whitehouse, K., et al.: Marionette: using rpc for interactive development and debugging of wireless embedded networks. In: 5th International conference on Information processing in sensor networks (IPSN), pp. 416–423. ACM Press, New York (2006) 21. Ringwald, M., R¨ omer, K., Vitaletti, A.: Passive inspection of sensor networks. In: Aspnes, J., Scheideler, C., Arora, A., Madden, S. (eds.) DCOSS 2007. LNCS, vol. 4549, pp. 205–222. Springer, Heidelberg (2007) 22. Crepaldi, R., Friso, S., Harris, A., Mastrogiovanni, M., Petrioli, C., Rossi, M., Zanella, A., Zorzi, M.: The design, deployment, and analysis of signetlab: A sensor network testbed and interactive management tool, May 2007, pp. 1–10 (2007) 23. Chen, B.-R., Peterson, G., Mainland, G., Welsh, M.: Livenet: Using passive monitoring to reconstruct sensor network dynamics. In: Nikoletseas, S.E., Chlebus, B.S., Johnson, D.B., Krishnamachari, B. (eds.) DCOSS 2008. LNCS, vol. 5067, pp. 79–98. Springer, Heidelberg (2008) ¨ 24. Osterlind, F., Dunkels, A., Voigt, T., Tsiftes, N., Eriksson, J., Finne, N.: Sensornet checkpointing: Enabling repeatability in testbeds and realism in simulations. In: Roedig, U., Sreenan, C.J. (eds.) EWSN 2009. LNCS, vol. 5432, pp. 343–357. Springer, Heidelberg (2009), http://dblp.uni-trier.de/db/conf/ewsn/ewsn2009.html#OsterlindDVTEF09 25. Shawn, http://shawn.sf.net 26. Kr¨ oller, A., Pfisterer, D., Buschmann, C., Fekete, S.P., Fischer, S.: Shawn: A new approach to simulating wireless sensor networks. In: Design, Analysis, and Simulation of Distributed Systems (DASD 2005), pp. 117–124 (2005) 27. Fekete, S.P., Kr¨ oller, A., Fischer, S., Pfisterer, D.: Shawn: The fast, highly customizable sensor network simulator. In: Proceedings of the Fourth International Conference on Networked Sensing Systems (INSS 2007) (June 2007) 28. Lipphardt, M., Hellbr¨ uck, H., Pfisterer, D., Ransom, S., Fischer, S.: Practical experiences on mobile inter-body-area-networking. In: Proceedings of the Second International Conference on Body Area Networks, BodyNets 2007 (2007), http://www.bodynets.org/ 29. Coalesenses iSense - A modular hardware and software platform for wireless sensor networks, http://www.coalesenses.com/isense 30. Design of the Hardware Infrastructure, Architecture of the Software Infrastructure, and Design of Library of Algorithms, http://www.wisebed.eu/index.php/deliverables 31. Pfisterer, D., Lipphardt, M., Buschmann, C., Hellbrueck, H., Fischer, S., Sauselin, J.H.: MarathonNet: Adding value to large scale sport events - a connectivity analysis. In: Press, A. (ed.) Proceedings of the International Conference on Integrated Internet Ad hoc and Sensor Networks (InterSense 2006), May 2006, p. 12 (2006), http://doi.acm.org/10.1145/1142680.1142696

SmartEN: A Marie Curie Research Framework for Wireless Sensor Networks in Smart Management of the Human Environment Toula Onoufriou1, Anthony Constantinides2, Anastasis Kounoudes3, and Antonis Kalis4 1

Cyprus University of Technology 2 Imperial College 3 Signalgenerix 4 Centro Tecnológico Telecomunicaciones Cataluña, Athens Information Technology [email protected]

Abstract. Even though there is significant research work performed in the fields of wireless sensor networks, civil infrastructure reliability and management, most of the work is fragmented and there is no significant activity in performing multidisciplinary structured research for developing integrated smart and dynamic systems for effective management of the built and natural environment. The aim of SmartEN is to push innovation through the development of a research training network that will focus on the development and effective integration of emerging technologies targeting key application areas of current interest to Europe and the world. Keywords: Wireless sensor networks, signal processing, proactive management, infrastructure reliability.

1 Introduction There are increasing concerns regarding the environmental impact of human actions, the use of the environment and climate changes. These are coupled with ageing infrastructure systems, increasing urban population, continuously growing and changing demands on the built and natural environments as well as limited financial and depleting natural resources. The renewed EU Sustainable Development Strategy [Renewed EU Sustainable Development Strategy, Council of the European Union, 10917/06, Brussels, 26 June 2006] sets out a single, coherent strategy on how the EU will more effectively live up to its long-standing commitment to meet the challenges of sustainable development. It recognizes the need to gradually change our current unsustainable consumption and production patterns and move towards a better integrated approach to policy-making. Some of the key priority challenges are: climate change and clean energy, sustainable consumption and production, and conservation and management of natural resources. These issues pose significant challenges for designing and managing the human environment in a sustainable manner. Until now, research has been focused on the development of proactive risk-based approaches for civil infrastructure reliability and management with benefits in improved performance, safety and cost. N. Komninos (Ed.): SENSAPPEAL 2009, LNICST 29, pp. 88–106, 2010. © Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering 2010

SmartEN: A Marie Curie Research Framework for Wireless Sensor Networks

89

However, there are significant uncertainties associated with the various predictive models directly affecting the quality of the decision making mainly due to the limited amount of information available on the changing condition, demands and actual performance of various systems. Recently, a new generation of miniature wireless sensor platforms which utilize novel Digital Signal Processing, microprocessor and communication technologies has emerged. These can be adopted to obtain large quantities of highly diverse sensor data that are continuously collected over a long period of time from multiple targeted locations within a system, therefore providing significant insight on the condition, demands and performance of the system. These developments open up a completely novel area of multidisciplinary research and new research directions towards the ‘smart’ management of the sustainable environment. Wireless Sensor Networks (WSN) is a fast growing technology which can be widely used in a number of sectors associated with key aspects of the management of the human environment. There are significant opportunities presented in this area by the emerging technologies on wireless sensors and communications which can be exploited to develop dynamic and smart systems for strategic management. Even though there are top research institutions around the world, which are focusing their activities in the development of WSN technologies and others that are focusing on civil infrastructure reliability and management research, most of the research activity is fragmented and there is not any significant activity in performing multidisciplinary, intersectoral structured research for developing integrated smart and dynamic systems for effective management of the built and natural environment. The aim of SmartEN is to fill this technology gap and push innovation through the development of an initial research and training network that will focus its activities on the development, effective integration and increased utilisation of emerging technologies in wireless sensors, communications and proactive management targeting key issues of current interest to the European Commission and internationally. These will include application areas in monitoring and smart proactive management of Structural Systems, Heritage and Infrastructure, Transportation Infrastructure Systems and Urban Microclimate. SmartEN will advance the state-of-the-art in the development, integration and application of sensor technology in the specific sectors of Wireless Sensor Networks (WSN), Sensor Signal Processing (SSP), Non Destructive Evaluation (NDE) and Smart Proactive Management (SPM), for the benefit of the human environment (Figure 1). The SmartEN Initial Training Network (ITN) project, which is funded under the Marie Curie FP7 program, aims to train the next generation of researchers, engineers and research managers in the field of monitoring and smart proactive management of the built and natural environment by effectively developing and integrating novel WSN and digital signal processing (DSP) technologies in proactive management for the benefit of the human environment. The consortium, shown in Table 1, consists of fifteen partners with world-class competence and is inherently interdisciplinary as it combines expertise from areas like infrastructure reliability and management, digital signal processing, communications, computer engineering, materials, non destructive evaluation, information technology and wireless communications. The network consists of partners with established experience in civil and electrical engineering related disciplines from academia, research centres, and the industry. In addition to the European partners the consortium also includes nine Visiting Scientists who are

90

T. Onoufriou et al.

Fig. 1. Research Training and Application Areas of SmartEN Table 1. SmartEN Participants

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Cyprus University of Technology (CUT), Cyprus Research Academic Computer Technology Institute (RACTI), Greece Imperial College London (IC), UK Research and Education Laboratory in Information Technologies (AIT), Greece University of Surrey (UNIS), UK University of Pavia (UPV), Italy Federal Institute for Materials Research and Testing (BAM), Germany Swiss Federal Laboratories for Materials Testing and Research for Industry (EMPA), Switzerland Ecole Nationale Supérieure des Télécommunications (ENST), FR Comsis, (Comsis), France Design for Life Systems, UK COWI (COWI), Denmark Network Rail (NR), UK Parsons Brinckerhoff (PB)UK Intracom (ICOM), Greece

leading experts in the key disciplines represented in the project from top universities and other institutions worldwide.

2 Overview of Previous Work The design and management of the built and natural environment has moved towards a more proactive risk based approach considering the whole life cycle of a system [1].

SmartEN: A Marie Curie Research Framework for Wireless Sensor Networks

91

This encompasses the use of life cycle design and assessment and multi-objective optimisation [2,3] and the adoption and optimisation of proactive measures such as preventative maintenance [4,5]. Other important elements within this framework are component and system probabilistic assessment methods [6] and probabilistic long term performance and deterioration modelling [7]. These have been augmented with information from global dynamic monitoring through the use of system and damage identification methods [8,9] and the use of inspection and monitoring information integrated through Bayesian updating methods [10,11]. Recent trends in structural health monitoring are towards the application of statistical signal processing techniques to diagnose damage which offer improved accuracy in damage localisation and detection [12]. The combined developments in this whole area provide a tremendous potential for more rational and effective proactive management. However, there are still many research challenges that need to be addressed to integrate effectively all these elements within a proactive framework and achieve their full potential. Such developments are interlinked with the effective integration with emerging technologies in wireless sensor networks (WSN) and communications which open up tremendous opportunities for information gathering on a continuous basis that can reduce uncertainty in the modeling and decision making and result in effective life cycle strategies. Recent developments in this area include many solutions for software and hardware design, communications, distributed signal processing, data mining and fusion, node and source localization methods, and middleware design. The former include application-tailored hardware and software solutions that have been evaluated with short term deployments [13-16], off-the-shelf hardware components [17], and modular software and hardware designs [18-19]. Communication problems are tackled using distributed solutions like cooperative relaying networks [20], virtual MIMO systems [21], cooperative beamforming systems [22], and smart antenna systems [23]. Data mining and distributed data fusion methods are inevitable for reducing the massive amounts of raw data produced by WSN monitoring the physical world [24], and the emphasis has moved towards the use of WSN with distributed learning and processing capabilities [25]. Localization and synchronization of sensor nodes is critical for most of the previous distributed algorithms to work. Algorithms utilize either Time Difference Of Arrival (TDOA) [26], Round-trip Time Of Flight (RTOF) [27], Direction Of Arrival (DOA) [28], or Received Signal Strength (RSS) methods [29], with the former being the most accurate, and the latter mostly suited for the limited hardware of sensor nodes. All the aforementioned approaches have to be effectively handled by an intelligent Middleware that will be easy-to-use by inexperienced users, and provide transparent internet connectivity. The existing approaches for WSN middleware design include virtual machine-oriented [30-32], database-inspired [33-35], mobile-agents based [36-37], or application driven [38] designs. There is a large community of researchers working in all the above areas and a number of centres around the world focusing in a specific area (such as the ‘Cambridge MIT Centre on Smart Infrastructure’, The ‘Centre for Advanced Monitoring and Damage Detection’ at University of California Irvine, the ‘John A. Blume Earthquake Engineering Centre’ at Stanford, the ‘Advancement of smart infrastructure sensor technology’ at the University of Illinois, ‘Intelligent Infrastructure Institute’, Drexel University and the ‘Information Technology Research ITR Collaborative Project on Health Monitoring of Highway Bridges and Infrastructure’ in California).

92

T. Onoufriou et al.

In some areas like structural health monitoring guidelines covering the basic aspects of such applications have been developed (SAMCO, ISIS, FIB, ISO, FHWA). There are also a number of national, European and international networks like SIMONET (UK), SAMCO (EU) and ISHMII (International) who have contributed significantly in bringing together various stakeholders in an attempt to promote dialogue and understanding of needs and emerging capabilities. However, these networking platforms are heavily weighted towards the infrastructure community with limited participation from the WSN and communications community. Furthermore, these networks offer limited opportunities for advanced training of the next generation of research leaders and decision makers in this area. There are significant technological developments in the various components that can contribute to the smart management for sustainable human environment. The new technical challenges lie in the improved exploitation of these technologies through integrated multi-disciplinary life cycle management approaches with the development of effective interfaces between the various key disciplines. The importance of integrated management environment and life cycle approach are recognised by the European Commission COM(2005) 718 [39] and the Sixth Environmental Action Programme [40] which is calling for the preparation of a ‘thematic strategy for sustainable use of management of resources’. Furthermore, G8 ministers responsible for science and technology argue that in the long term making existing technologies more efficient will not be enough to solve a problem, instead ‘fundamental breakthroughs in science and technology will be essential’ (summit June 15 2008). The most significant barrier in achieving significant breakthroughs in these areas are the lack of: 1) a community of high calibre researchers who have a broader understanding of the whole spectrum of technologies required to achieve truly integrated multi-disciplinary solutions and who are trained to work in multi-disciplinary research environments and 2) a world class research environment encompassing the whole range of specialisations providing a powerful scientific base for training and technological developments in this area. The SmartEN ITN aims to fill this gap and place Europe in a unique position worldwide by providing a unique world class training and multi-disciplinary scientific research base moving Europe to the forefront of research in this field. Furthermore, the SmartEN ITN holds the potential for achieving significant breakthroughs with tremendous benefits for a sustainable human environment.

3 SmartEN Objectives and Challenges The main objective of the SmartEN project is to implement a joint multidisciplinary research training programme which will be focused on the growth of scientific, technological knowledge and professional skills through research on individual, personalised projects in the field of smart management for sustainable human environment. The network aims to achieve the following objectives: • Research: To conduct top level research and training and devise innovative solutions in the areas of monitoring and smart proactive management of Structural Systems, Heritage and Infrastructure, Transportation Infrastructure Systems and Urban Microclimate arising from changing and growing demands in the built and natural environment and deteriorating climate changes.

SmartEN: A Marie Curie Research Framework for Wireless Sensor Networks

93

• Education: To educate the next generation of intersectional and transnational researchers in the area of smart management of the sustainable environment and provide them with a unique range of skills and a network that will open up challenging and attractive career perspectives. • Convergence: To take forward the state-of-the-art in wireless sensor communications, digital signal processing and non destructive evaluation for the successful application of wireless sensors in the smart proactive management of the built and natural environment, by providing an impetus for infrastructure management and wireless sensor research groups to integrate and intensify their research effort in important innovative areas SmartEN will target applications of Structural Systems, Heritage and Infrastructure, Transportation Infrastructure Systems and Urban Microclimate. Namely, it aims to direct its research activities towards the following fields: 1. To develop new wireless communication protocols and localisation algorithms that will lead to a new generation of wireless sensors tailored to the needs of a sustainable human environment management which will enable engineers to assess constructions’ condition and detect defects in a more accurate, much faster and less costly way. 2. To extend the energy harvesting technologies and investigate renewable energy sources to power wireless sensor networks for applications in remote, completely isolated utilities and transportation infrastructures. 3. To enable automated, cost-effective application of NDE in remote and hazardous environments and reduce the error levels introduced by manual operation, infrequent data collection and interpretation of data. 4. To develop innovative proactive management methodologies for aging depleting infrastructures through better monitoring of the health of their assets thus enabling stakeholders to provide better services to the citizens including reduced disruption, improved safety, lower costs and reduced environmental impact. 5. To enable continuous monitoring of heritage and infrastructure systems of great cultural importance through the development of models for the evaluation of the performance and health of a structural systems and the detection of damage. 6. To facilitate the collection, transmission, processing, modelling and interpretation of huge quantities of highly diverse environmental sensor data for urban microclimate monitoring. 7. To develop technologies that will enable the development of optimum new designs for effective smart life cycle management of civil infrastructure through the implementation and integration of wireless sensor networks and NDE. 8. To contribute to the process of developing and improving standards in various aspects related to smart management for sustainable human environment. Such standards are the ones being produced by CEN/TC 350 on environmental performance and life cycle cost performance and service life planning. 9. To realise the research results to innovative prototype commercial systems and products and prove their performance in real world conditions. The network greatly supports the training of the researchers in the whole cycle of product research and development (R&D), from research to prototype implementation, integration testing and commercialisation. SmartEN results are expected to produce products that

94

T. Onoufriou et al.

will solve important infrastructure monitoring and management problems and enhance the life of the European citizen. Furthermore, the project aims to change the face of this research field and raise it to another level where inter-disciplinary research has a significant role to play. The proposed work and interactions between partners will provide the challenges and opportunities for developing technologies and methodologies that will enable moving away from reactive and fragmented to proactive and integrated approaches which hold the potential for achieving performance, safety, cost and environmental benefits on a much greater scale. SmartEN aims to span its research in all the technological challenges affiliated with deploying WSN for NDE and smart proactive management, starting from the device level to the application. Namely, SmartEN will focus its research on the main challenges concerning: 1.the density of nodes necessary to capture relevant information with minimal energy expenditure 2.the design of interaction mechanisms among the nodes that limit the possibility of congestion when relevant events occur 3.the optimal hardware design to maximize the network lifetime 4.the tolerance to node failures and the vulnerability to natural or intentional attacks 5.the distributed transmission and coding schemes that provide the optimum tradeoff between hardware complexity and energy efficiency 6.the localization and synchronization algorithms that provide adequate accuracy without depleting network resources 7.the middleware design which will enable robust over-the-internet access, transparency and reconfigurability 8.optimum sensors arrangement to achieve targeted system monitoring 9.design of dynamic and flexible monitoring and inspection regimes 10.improved assessment and long term performance modelling targeting system performance, spatial variability and effective treatment of uncertainties 11.continuous information systems in order to improve decision making and management strategies 12.new methods for incorporating information from diverse sources of different type, spatial and temporal coverage, quality and reliability 13.combined use of quantitative and qualitative information in model updating and decision making 14.combined use of damage identification with monitoring and NDT inspection for improved damage detection and sizing capability 15.integrated modelling of various proactive interventions 16.life cycle assessment and design incorporating multi-dimensional and multi-source information systems 17.dynamic multi-objective strategy optimisation for smart life cycle strategy optimisation.

SmartEN: A Marie Curie Research Framework for Wireless Sensor Networks

95

4 Work Programme and Methodology SmartEN has managed to bring together a collaborative research network that will focus its activities on research and training in the disciplines of WSN, SSP, NDE and SPM. Each of the above areas defines an individual work programme which requires a high level of interdisciplinary collaboration. It is considered that the specific workprogrammes and work-programme research themes illustrated in Figure 2, and the interaction between them provide a very significant impetus for transfer of knowledge (ToK) within the proposed research network. End-users will identify the requirements for new technology and will carry out practical evaluation of the developed methods and devices. Under the umbrella of the four application areas, shown in Figure 2, multidisciplinary projects will be developed which will involve research themes from more than one work-program. Six to seven SmartEN partners will collaborate in each individual project with a view of reinforcing links between them and achieving better integration between the various disciplines. Partners were selected to carry out work on each individual project according to their expertise in the related research area, their research infrastructure and their training facilities in associated topics, with the choices being “quality controlled” by internal and external experts. Academic and industrial research groups will work together to meet the interdisciplinary needs associated with the design, development and testing of the new techniques and devices.

Research Themes

SmartEN Work-Programmes

Application Areas

Multi-Disciplinary Research Projects • Structural Systems • Heritage and Infrastructure • Transportation Infrastructure Systems

Fig. 2. SmartEN Work Programmes, Research Themes and Application

96

T. Onoufriou et al.

The following paragraphs identify the key scientific challenges in this area which are associated with the various component technological fields as well as the challenges and opportunities presented in attempting to integrate these fields to develop complete systems for smart management for sustainable human environment. These are outlined below within the context of the scientific programme of the project. Current research ideas and techniques are highlighted together with the future research that needs to be undertaken in order to move away from the current fragmented approaches developing in each discipline and specialisation in order to move towards integrated total solutions and systems. 4.1 Work Programme 1 – Wireless Sensor Networks This work program (WP) will focus on training researchers in the critical area of wireless sensor node and network design, implementation and deployment. Intersectoral research will be deployed in the beginning of the project in order to gain a better understanding of the challenges involved with the NDE and smart proactive management applications, and lead to an effective design and evaluation of wireless sensor nodes, the basic building blocks of the system. Inter-disciplinary research and transfer of knowledge is also expected between work programs 1 and 2, so that signal processing and node design are coordinated. Research Theme 1: Communication protocols The goal of this research theme (RT) is to provide new knowledge in the field of communication protocols for wireless sensor networks, in areas such as multi-hop communications, cooperative relaying networks, energy efficient MAC and routing layer design, secure and trusted communications, virtual MIMO systems, interference mitigation, cooperative transmission and beamforming systems, smart antenna systems for sensor networks, cross-layer optimization algorithms. The scientific approach to this RT is to investigate and focus on the tradeoffs between algorithmic complexity and overall system performance and sustainability. We therefore envision that a successful completion of this RT will not only produce new protocols and standards for WSN, but also provide new approaches to the design of WSN. Research Theme 2: Distributed OS for Reconfigurable Sensor Networks Due to the restricted resources of WSN, each node can be programmed to perform a limited number of tasks. This could lead to wireless sensor networks where individual nodes perform a subset of the overall required sensing and processing tasks. In this RT focus is on the development of a distributed operating system (OS) that will be able to support network reconfigurability, following the changing requirements of the application. The goal is that the OS will not rely on individual node addresses to perform the changes but will rather monitor the changing needs and spatial distribution of events within the network structure. Research Theme 3: Energy Harvesting and Conservation One of the most critical points in meeting the goals of the project is to ensure that nodes will be able to operate unattended for large periods of time, without being connected to a power-line network, in order to take advantage of the low-cost deployment

SmartEN: A Marie Curie Research Framework for Wireless Sensor Networks

97

and sustainability of such a choice. The objective of this RT is to build sensor node hardware that will meet a set of specialized requirements related to both digital hardware characteristics and node lifetime. Several technologies will be examined for increasing the autonomous nature of sensor nodes, through energy harvesting solutions. At the same time, all the different building blocks of the node hardware (sensing, processing, communication, localization, synchronization, battery and energy harvesting circuitry), will be investigated and specialized to the needs of the NDE and smart proactive management applications, while being optimized for low energy consumption. Research Theme 4: Localization This RT deals with one of the most difficult problems in wireless sensor network technology. Localization is a network function that requires the synergy of both hardware and software mechanisms, and is applied both for finding the relative and absolute locations of sensor nodes, as well as for localizing and tracking events in the network environment (i.e, crack detection in large structures, land movements in landslide prediction etc.). The requirements of different localization algorithms focusing on different application scenarios could be quite diverse, ranging from fractions of a millimetre to a couple of meters. A successful outcome of this RT would be to produce new algorithms and localization systems. 4.2 Work Programme 2 – Sensor Signal Processing The focus of this WP is on the critical area of signal processing and energy efficient wake-up strategies for event based monitoring with wireless sensor networks. Signal processing in such resource constrained nodes is not trivial, therefore interdisciplinary research is expected to be triggered with the beginning of the project between WPs 1 and 2 to investigate the limitations and capabilities of signal processing algorithms within the desired system architecture. Naturally, this WP will collaborate with WP 3 and 4 in inter-sectoral research activities that will set the system requirements for the algorithms’ specifications. Research Theme 1: Distributed processing and Aggregation Due to the redundancy of information, the limited resources of sensor nodes and the requirements of the application, distributed algorithms are often needed in WSN to achieve the goals of the application. Distributed signal processing algorithms like distributed compression, aggregation and distributed coding schemes could provide a means of reducing communication overhead, and energy dissipation. A successful outcome of this RT would be to develop a framework and specific algorithms for cluster or network wide data analysis and inter-nodal negotiation which allows for a reliable autonomous evaluation of potential alarm situations. The wireless sensor network should be able to autonomously and adaptively switch between different alarm states based on the intensity of the critical parameters across the network, and to adapt the data acquisition, analysis, communication, and evaluation policy according to the specific alarm state. The event based wireless sensor network will be evaluated with a long term field test focusing on vibration monitoring of a construction site.

98

T. Onoufriou et al.

Research Theme 2: Signal Processing for Event Classification In this RT as the goal is to use signal processing on sensor individual nodes to take advantage of the proximity of sensors to the monitored events, taking into account the limited resources of sensor node hardware. Algorithms that will be investigated will be defined through an inter-sectoral research phase, where the type of algorithms, their accuracy, latency, complexity, power needs will be discussed. The work will include design of signal processing algorithms for ultra low power acceleration sensors for individual event detection, and for energy efficient signal conditioning boards with resistance strain gauges. The event based wireless sensor network will be evaluated with a long term field test focusing on fatigue monitoring of a railway bridge. The research would lead to new knowledge in the fields of signal processing for resource limited devices, or even to new approaches for the hardware design of sensor nodes. Research Theme 3: Middleware This RT will focus on the field of energy and communication efficient data mining to detect and classify events, and on fusion techniques, which will combine data from multiple sensor sources and gather information in order to achieve inferences. Fusion in low, intermediate and high level, depending on the processing stage at which fusion takes place will be examined. Findings in data mining and fusion will lead to an intelligent middleware design that will sit on top of the distributed OS of the WSN, enable reconfigurability options, be transparent to the inexperienced users of NDE and smart infrastructure management applications, and enable distant site monitoring through easy-to-use internet interfaces. 4.3 Work Programme 3 – Non Destructive Evaluation This WP will focus on the area of non destructive evaluation. Strong interaction between the five sub programmes in this package is required as well as the other WPs to achieve integration between these specialisations within a smart proactive management framework. Interaction with industry is also pivotal to the success of this programme in order to focus training and research towards the needs of end users. Research Theme 1: Optimum Sensor Locations and Requirements for NDE The objective of this RT is to identify where and what needs to be monitored in a system and determine the requirements of the sensors in terms of type of measurement, spatial and temporal coverage and reliability. The goal is to move towards optimum sensor arrangements and specifications to achieve targeted and efficient monitoring, avoiding mass collection of unused information. There are key competing objectives here which are maximising the amount and quality of information and minimising the processing effort and cost of the overall system. This multi-objective optimisation problem will require expertise from researchers from across the different specialisations and a high degree of intersectoral research is envisaged within this RT enabling multi-disciplinary research collaborations. The success of this RT would be a crucial part of the whole programme linking the main disciplines of electrical engineering and civil engineering.

SmartEN: A Marie Curie Research Framework for Wireless Sensor Networks

99

Research Theme 2: Combined Monitoring and Inspection Systems This RT will focus on the areas of inspection and Non Destructive Testing methods (NDT) and enable them to tackle the design of systems which can augment the information normally obtained from inspections only with continuous monitoring systems. The goal is to develop methods for designing combined flexible and dynamic monitoring and inspection regimes that optimise the efficiency of the information. The continuous monitoring sensor networks can provide a wider spatial and temporal coverage of the system with a relatively lower level of accuracy and cost while acting as a warning system flagging the areas/locations where more expensive and accurate NDT inspections are required. This RT will need to be combined with the decision making process to determine when NDT is required. It will bring closer the research communities across all disciplines of SmartEN providing a powerful platform for effective integration of different technologies. Research Theme 3: Assessment and Long Term Performance Modelling The objective of this RT is to provide assessment and long term performance modelling of systems subjected to ageing, deterioration and changing demands. Risk and reliability methods will be examined, which provide a rational framework for taking into account uncertainties in modelling and predictions affecting the quality of decision making. Challenges to be addressed in assessment and long term modelling targeting system performance include spatial variability, and effective treatment of uncertainties. A key target is reducing the uncertainty in the predictions using new knowledge from monitoring and inspections. Research Theme 4: Performance Model Updating Based on Sensor Information A central goal of SmartEN is the reduction of uncertainties in modelling and predictions through continuous information systems in order to improve decision making and management strategies. This will require new updating methods to be developed for incorporating information from diverse sources of different type, spatial and temporal coverage, quality and reliability which may also require the combination of both quantitative and qualitative information. This will raise the research challenge to a level of continuous multi-dimensional system updating. The aim is to enhance current practice with an improved information system and updating. Research Theme 5: Damage identification The objective is to conduct research in the area of damage identification methods that enable changes in the system to be detected, located and to some extent quantified with varying degrees of accuracy. While there have been significant developments in this area, these methods are only effective in identifying large changes from extreme events such as earthquakes rather than small changes due to deterioration. The goal of this RT is to explore how combined use of damage identification with sensor networks, NDT inspections and signal processing can improve the capability of detecting and quantifying damage and deterioration.

100

T. Onoufriou et al.

4.4 Work Programme 4 – Smart Proactive Management This WP will focus on smart proactive management providing the overall framework for linking all WPs. It comprises a key element of Smarten which holds the potential to make a significant contribution in the area of smart proactive management of the human environment. Research Theme 1: Proactive Management Strategies In this RT focus will be on the philosophy, opportunities, value and techniques of proactive management within the context of life cycle management of complex systems. There is a whole range of proactive interventions that can beneficially be employed to improve management strategies including preventative, corrective, modifications, change of use, restrictions, replacements etc. The goal is to be able to model their effects within combined proactive strategies, and not in isolation, and being able to improve their modelling and reduce uncertainties through monitoring and inspection systems. Integration of these models and reduction in uncertainty provides a more rational basis for deciding what actions are needed and when to maintain the system at the required level of performance, risk, cost, environmental impact etc within the whole life cycle of the system. Probabilistic modelling and updating and multiobjective optimisation methods are important elements here. Research Theme 2: Life Cycle Design and Assessment In this RT the life cycle perspective will be studied. The goal is to develop life cycle strategy development methods with all the challenges and opportunities presented by the adoption of extensive sensor monitoring systems providing multi-dimensional and multi-source information that needs to be assimilated and effectively used within the life cycle management process. Such systems need to be flexible and adaptive to meet future changing needs and their design optimised to maximise the benefit from the information obtained. This opens up a bigger area for research which is the design of smart proactive management systems for sustainable management of the human environment. Research Theme 3: Multi-objective Optimisation An important element of the life cycle design and assessment is how to manage with competing objectives. These include performance, risk, cost, safety, environmental impact, creation of jobs etc. and require the use of multi-objective optimisation techniques. The goal is to use multi-objective optimisation within the context of proactive life cycle strategy optimisation. Recent developments in this area incorporated the effects of various proactive actions like inspection, preventative maintenance and more recently limited monitoring. The goal in this RT is to develop methods that enable planners to consider the possible effects of various proactive actions together, and not in isolation, as well as capitalise on the continuous information system provided by the sensor networks. These issues need to be addressed in a dynamic system where models will be updated continuously therefore affecting the future predictions and decision making. This presents new dimensions to the research challenges and holds the potential for maximising the benefits in terms of performance, cost, risk, environmental impact etc.

SmartEN: A Marie Curie Research Framework for Wireless Sensor Networks

101

4.5 Horizontal Integration through Multi-disciplinary Research Projects The main work programme and research themes have been outlined above. Within this scope a number of individual research projects will be defined for the nineteen Marie Curie Fellows employed on the programme. The projects will be defined to combine partners from the main disciplines of civil engineering and electrical engineering as well as academic/research organisations with industrial partners giving the opportunity to the fellows to gain experience from the various bodies involved in the development and application of such methods. These projects aim to: • Give the opportunity to the MC fellows to develop expertise beyond their core area through short duration placements with other partners and develop a good level of understating of related fields which are important components of the development of integrated solutions. This will be achieved through short placements at both academic/research and industrial partners as well as through the series of network wide and local training events that will be organised. • Enable researchers to focus more on the integrating technologies moving away from isolated insular research efforts and topics. Understand how their work links into the other components that are necessary for integrated solutions which will enable them to focus their work and achieve more effective component methodologies by being aware of the needs and constraints posed by the other discipline components required in an integrated solution. • Exploit fully the complementarity between the expertise of the various partners as well as their research and training infrastructure. • Provide the opportunity to researchers to be exposed to experts and research in complementary fields, promote long term networking and establish effective lines of communications between the various experts, researchers and end users.

5 SmartEN Applications In the past 100 years, the world’s population living in cities has grown from 14% of a population of 1.6bn to over 50% of the 6.6bn today; and by 2030 it is forecast that 5bn people will live in urban conurbations. This statement alone emphasizes the increased demands on buildings, infrastructure, transport and the interaction and the effective monitoring and control of the urban microclimate. It clearly highlights the dependence of the planet’s population on sustainable well-engineered systems, and the importance of developing technologies that will facilitate and optimize the design and management of structural systems for buildings and civil infrastructure and the effective interaction with and control of the urban microclimate. The key areas of application to be addressed within SmartEN target the four key areas highlighted above namely; Structural Systems, Heritage and Infrastructure, Transportation Infrastructure and Urban Microclimate. A brief description of the areas of application is given below. Structural Systems Research within SmartEN will focus on the development of new and integrated technologies which will enable the design and maintenance of smart structures with the

102

T. Onoufriou et al.

aim of achieving more sustainable systems. It is envisaged that the application to new structures will provide the in built capability of sensor networks, signal processing and smart decision making for effective life cycle management. On existing structures various technologies can be developed which can be mounted with minimal intervention on the structure to provide a similar capability. Such systems should be able to monitor the structural and environmental loadings, the actual performance of the structure, changes in the structure due to long term deterioration processes, environmental effects and accidental and extreme environmental events such as earthquakes, typhoons and floods. Another dimension of the smart monitoring and proactive management capability to be explored for structures relates to thermal losses or gains and the energy efficiency for heating, cooling and electricity consumption and various environmental comfort parameters. The sensor network monitoring systems will be linked with assessment and whole life based management systems for early detection/recognition and proactive response to observed and expected changes in the structure’s demands and performance. The overall aim of the application of these technologies is to move towards sustainable systems using rational approaches for optimal solutions which balance various competing objectives such as whole life cost, safety, reliability, energy efficiency and comfort. Heritage and Infrastructure The application issues highlighted above for structural systems are also relevant to the need for smart effective management systems for maintaining priceless heritage and ageing infrastructure systems while there are specific concerns and characteristics in these groups of structures which require a specific focus in the research programme. There are specific constraints which apply to heritage structures such as the need to maintain the original form and materials with little or no interventions, dealing with very old already weakened structures, a long and unknown history of loading and performance and possible interventions, different materials and methods of construction etc, issues that need to be addressed specifically in developing technologies for this area of application. The application to infrastructure systems, while similar in many respects to structural systems, introduces a number of additional aspects which differentiates the way such methodologies need to be developed and applied at a network level. In the case of network application the main purpose would be to develop strategies to support financial planning, budget requests, bid prioritisation, monitoring of the performance of the network and asset valuation. Hence the various predictive and decision making models are likely to be more global in the case of network management planning with models representing the characteristics and behaviour of groups of structures. Consequently the type of data needed from associated sensor networks, communication and signal processing technologies to populate and continuously update these models would be different posing different challenges to their development and application. Transportation Infrastructure Systems There is a whole range of applications of the SmartEN integrated interdisciplinary technological developments in the area of smart transport infrastructure systems which encompass a more dynamic multidimensional environment with fixed and moving components requiring effective communication and interaction between them.

SmartEN: A Marie Curie Research Framework for Wireless Sensor Networks

103

Furthermore, transportation infrastructure systems need to satisfy various objectives effectively including the need to move people, facilitate trade and shift commodities within nations and across borders. These need to be viewed against cost issues, rising security risks and users demanding easy and fast access. Clearly this is an area where integrated developments combining wireless sensor networks, communications and digital signal processing with predictive performance models, multi-objective optimisation and infrastructure reliability and management methods have a lot to offer. The types of developments proposed within SmartEN have the potential to move the area of smart transport infrastructure management forward with significant benefits for the future. Urban Microclimate SmartEN developments and applications in the area of urban microclimate will be of major significance and aim to contribute towards securing a diverse, healthy and resilient natural environment, which provides the basis for everyone’s well-being, health and prosperity now and in the future; and where the value of the services provided by the natural environment are reflected in decision-making. Innovative wireless sensor systems and processes can be applied to ensure that: 1) the air that people breathe in cities are free from harmful levels of pollutants; 2) there is sustainable water use which balances water quality, environment, supply and demand; 3) the land and soils are managed sustainably 4) biodiversity is valued, safeguarded and enhanced sustainable, living landscapes with best features are conserved; 5) people are enjoying, understanding and caring for the natural and built environment.

6 Discussion and Conclusions There are increasing concerns regarding the environmental impact of human actions, the use of the environment and deteriorating climate changes. These are coupled with ageing infrastructure systems, continuously growing and changing demands on the built and natural environments as well as limited financial and depleting natural resources. According to the EU COM(2004)60 “Towards a thematic strategy on the urban environment” buildings and the built environment uses 50% (measured by weight) of the materials taken from the Earth’s crust. In addition waste produced from building materials, during the construction and demolition stages are the source of 25% of all waste generated in Europe. These issues pose significant challenges for designing and managing the human environment in a sustainable manner. Until now, research has been focused on the development of proactive risk-based approaches for civil infrastructure reliability and management with benefits in improved performance, safety and cost. However, there are significant uncertainties associated with the various predictive models directly affecting the quality of the decision making mainly due to the limited amount of information available on the condition, demands and actual performance of various systems. Recently, a new generation of miniature wireless sensor platforms which utilize novel Digital Signal Processing, microprocessor and communication technologies has emerged. These can be adopted to obtain large quantities of highly diverse sensor data that are continuously collected over a long period of time from multiple targeted locations within a system therefore providing significant insight on the condition, demands

104

T. Onoufriou et al.

and performance of the system. These developments open up a completely novel area of multidisciplinary research and new research directions towards the ‘smart’ management of sustainable environment. Wireless Sensor Networks is a fast growing technology which can be widely used in a number of sectors associated with key aspects of the management of the human environment. There are significant opportunities presented in this area by the emerging technologies on wireless sensors and communications which can be exploited to develop dynamic and smart systems for strategic management. Even though there are top research institutions around the world, which are focusing their activities in the development of WSN technologies and others that are focusing on civil infrastructure reliability and management research, most of the research activity is fragmented and there is not any significant activity in performing multidisciplinary, intersectoral structured research for developing integrated smart and dynamic systems for effective management of the built and natural environment. The aim of the ‘SmartEN’ ITN is to fill this technology gap and push innovation through the development of an initial research and training network that will focus its activities on the development and effective integration of emerging technologies in wireless sensors, communications and proactive management targeting key issues of current interest to the European Commission and internationally. These will include application areas in monitoring and smart proactive management of Structural Systems, Heritage and Infrastructure, Transportation Infrastructure Systems and Urban Microclimate. Acknowledgments. The authors would like to acknowledge the European Commission for funding SmartEN under the Marie Curie ITN FP7 program. The authors are also acknowledging the significant input of all colleagues, partners and other collaborators who have contributed to the successful setting up of this major research and training programme.

References [1] Onoufriou, T.: Proactive Risk Based Framework for Integrity Management of Civil Infrastructure Systems. In: Keynote Paper, Japan Conference on Structural Safety and Reliability, Tokyo. (2007) [2] Frangopol, D.M., Liu, M.: Multiobjective optimization of risk-based maintenance and life-cycle cost of civil infrastructure. In: Ceragioli, E., Dontchev, A., Furuta, H., Marti, K., Pandolfi, L. (eds.) System Modeling and Optimization (Plenary Lecture), pp. 123–136. Springer, Boston (2006) [3] Mariano-Romero, C.E., Alcocer-Yamanaka, V.H., Morales, E.F.: Multi-objective optimization of water-using systems. European Journal of Operational Research 181(3), 1691–1707 (2007) [4] Furuta, H., Dogaki, M., Nakatsuka, N.: Optimal Repair Planning of Existing Bridges Using Genetic Algorithm. In: Frangopol, D.M. (ed.) Proceedings of the International Workshops on Optimal Performance of Civil Infrastructure Systems, ASCE, Portland, Oregon, pp. 116–126 (1997) [5] Tantele, E., Onoufriou, T., Mulheron, M.: Optimum Preventative Maintenance Planning for Reinforced Concrete Bridges. In: Proceedings of IABSE Conference on Operation Maintenance and Rehabilitation of Large Infrastructure Projects, Bridges and Tunnels, Copenhagen (2006)

SmartEN: A Marie Curie Research Framework for Wireless Sensor Networks

105

[6] Jo, S.I., Onoufriou, T., Crocombe, A.D.: System Reliability-Based Bridge Assessment using Response Surface Method. In: Proc. 5th Int. Conf. Bridge Management, Guildford (2005) [7] Stewart, M.G., Faber, M.H.: Probabilistic Modelling of Deterioration Mechanisms for Concrete Structures. In: Proceedings ICASP9, 9th International Conference on Applications of Statistics and Probability in Civil Engineering, San Francisco, USA, vol. 1, pp. 645–651 (2003) [8] Teughels, A., De Roeck, G.: Damage identification of a highway bridge by FE model updating. In: Book of abstracts of EUROMECH symposium: Vibration, Identification, and Control of Dynamical Systems, Thessaloniki, Greece (August 2003) [9] Aktan, A.E., Catbas, F.N., Ciloglu, S.K., Grimmelsman, K.A., Pan, Q.: Opportunities and challenges in health monitoring of constructed systems by modal analysis. In: International Conference on Experimental Vibration Analysis for Civil Engineering Structures, Bordeaux, France (2005) [10] Onoufriou, T., Frangopol, D.M.: Reliability - Based Inspection Optimisation of Complex Structures: A Brief Retrospective. J. Computers and Structures 80(12), 1133–1144 (2002) [11] Rafiq, I., Chryssanthopoulos, M.K., Onoufriou, T.: Predictive SHM-supported Modelling of Reinforced Concrete Bridges. Submitted for publication, IABMAS 2006, 3rd Int. Conf. on Bridge Maintenance, Safety and Management, Porto (2006) [12] Nair, K.K., Kiremidjian, A.S., Law, K.H.: Time Series-based Damage Detection and Localization Algorithm with Application to the ASCE Benchmark Structure. Journal of Sound and Vibration 291, 349–368 (2006) [13] Glaser, S.D.: Some Real-World Applications of Wireless Sensor Nodes. In: Proceedings, SPIE Symposium on Smart Structures & Materials/ NDE 2004, San Diego, CA (2004) [14] Lynch, J.P., et al.: Performance monitoring of the Geumdang bridge using a dense network of high-resolution wireless sensors. Smart Materials and Structures 15(6), 1561–1575 (2006) [15] Kim, S., et al.: Health Monitoring of Civil Infrastructures Using Wireless Sensor Networks. Technical Report No. UCB/EECS-2006-121, University of California, Berkeley (2006) [16] Mechitov, K., et al.: High-Frequency Distributed Sensing for Structure Monitoring. Transaction of the Society of Instrument and Control Engineers (SICE) E-S-1(1), 109– 114 (2006) [17] Olofsson, I., et al.: Assessment of European railway bridges for future traffic demands and longer lives – EC project “Sustainable Bridges”. Structure and Infrastructure Engineering 1(2), 93–100 (2005) [18] Feltrin, G., Meyer, J., Bischoff, R.: Wireless Sensor Networks for Long Term Monitoring of Civil Structures. In: EVACES 2007, 2nd International Conference on Experimental Vibration Analysis for Civil Engineering Structures, Porto, Portugal, pp. 95–111 (2007) [19] Enz, C., El. Hoiydi, A., Decotignie, J.-D., Peiris, V.: WiseNET: An Ultralow-Power Wireless Sensor Network Solution. IEEE Computer 37(8), 62–70 (2008) [20] Himsoon, T., Siriwongpairat, W.P., Han, Z., Liu, K.J.R.: Lifetime maximization via cooperative nodes and relay deployment in wireless networks. IEEE Journal on Selected Areas in Communications 25(2), 306–317 (2007) [21] Nguyen, T.-D., Berder, O., Sentieys, O.: Impact of Transmission Synchronization Error and Cooperative Reception Techniques on the Performance of Cooperative MIMO Systems. In: IEEE International Conference on Communications, ICC 2008, pp. 4601–4605 (2008)

106

T. Onoufriou et al.

[22] Dong, L., Petropulu, A.P., Poor, H.V.: Cooperative Beamforming for Wireless Ad Hoc Networks. In: IEEE GLOBECOM 2007, November 26-30, pp. 2957–2961 (2007) [23] Kalis, A., Dimitriou, T.: Fast Routing in Wireless Sensor Networks Using Directional Transmissions. Int. J. Mobile Network Design and Innovation 1(1), 63–69 (2005) [24] Estrin, D., et al.: Connecting the Physical World with Pervasive Networks. IEEE Pervasive Computing 1(1), 59–69 (2002) [25] Predd, J., Kulkarni, S.R., Poor, H.V.: Distributed Learning in Wireless Sensor Networks. IEEE Signal Processing Mag., 56–69 (July 2006) [26] Ho, K.C., Xiaoning, L., Kovavisaruch, L.: Sourse Localization Using TDOA and FDOA Measurements in the Presence of Receiver Location Errors: Analysis and Solution. IEEE Transactions on Signal Processing 55(2), 684–696 (2007) [27] Tragas, P., Papadias, C., Kalis, A.: Super-Resolution Signal Processing Techniques for Accurate Indoor Positioning Finding. In: IET Seminar on Smart Antennas and Cooperative Communication, London, October 22 (2007) [28] Niculescu, D., Badri, N.: Ad Hoc positioning system (APS) using AOA. In: INFOCOM 2003, 30 March-3 April, vol. 3, pp. 1734–1743 (2003) [29] Benkic, K., Malajner, M., Planinsic, P., Cucej, Z.: Using RSSI value for distance estimation in wireless sensor networks based on ZigBee. In: 15th International Conference on Systems, Signal and Image Processing, IWSSIP 2008, June 25-28, pp. 303–306 (2008) [30] Levis, P., Culler, D.: Mate: A Tiny Virtual Machine for Sensor Networks. In: Proc. 10th Int’l Conf. Architectural Support for Programming Languages and Operating Systems (ASPLOSX), pp. 85–95. ACM Press, New York (2002) [31] Barr, R., et al.: On the Need for System-Level Support for Ad hoc and Sensor Networks. Operating Systems Rev. 36(2), 1–5 (2002) [32] Boulis, C.-C.H., Srivastava, M.: Design and implementation of a framework for efficient and programmable sensor networks. In: Proc. of MobiSys (2003) [33] Bonnet, P., Gehrke, J., Seshadri, P.: Towards Sensor Database Systems. In: Tan, K.-L., Franklin, M.J., Lui, J.C.-S. (eds.) MDM 2001. LNCS, vol. 1987, pp. 3–14. Springer, Heidelberg (2000) [34] Madden, S.R., Franklin, M.J., Hellerstein, J.M.: TinyDB: An Acquisitional Query Processing System for Sensor Networks. ACM Trans. Database Systems 30(1), 122–173 (2005) [35] Srisathapornphat, C., Jaikaeo, C., Shen, C.: Sensor Information Networking Architecture. In: Proc. Int’l Workshop Parallel Processing, pp. 23–30. IEEE CS Press, Los Alamitos (2000), http://doi.ieeecomputersociety.org/10.1109/ICPPW.2000.869083 [36] Fok, C., Roman, G., Lu, C.: Mobile Agent Middleware for Sensor Networks: An Application Case Study. In: Proc. 4th Int’l Conf. Information Processing in Sensor Networks (IPSN 2005), pp. 382–387. IEEE Press, Los Alamitos (2005) [37] Liu, T., Martonosi, M.: Impala: A Middleware System for Managing Autonomic, Parallel Sensor Systems. In: Proc. ACM SIGPLAN Symp. Principles and Practice of Parallel Programming (PPoPP 2003), pp. 107–118 (2003) [38] Heinzelman, W.B., et al.: Middleware to Support Sensor Network Applications. IEEE Network 18(1), 6–14 (2004) [39] Commission of the European Communities, Towards a Thematic Strategy on the Urban Environment, Communication from the Commission to the Council and the European Parliament, COM(2005) 718 final, Brussels, Brussels (11.1.2006) [40] Decision No 1600/2002/EC of the European Parliament and of the Council of 22 July 2002 laying down the Sixth Community Environment Action Programme (OJ L 242, 10.9.2002, p. 1)

Software Update Recovery for Wireless Sensor Networks Stephen Brown1 and Cormac J. Sreenan2 1

2

Department of Computer Science, NUI Maynooth, Ireland [email protected] Mobile and Internet Systems Laboratory, University College Cork, Ireland

Abstract. Updating software over the network is important for Wireless Sensor Networks in support of scale, remote deployment, feature upgrades, and fixes. The risk of a fault in the updated code causing system failure is a serious problem. In this paper, we identify a single, critical, symptom loss-of-control, that complements exception-based schemes, and supports failsafe recovery from faults in software updates. We present a new software update recovery mechanism that uses loss-ofcontrol to provide high-reliability, low energy, software updates, including a comparison of optimised-flooding against spanning-tree for determining loss-of-control in a multi-path environment. The solution presented supports a trial phase (with lower latency), and an operational phase (with lower energy). The energy/latency tradeoff of this is shown, and the high-reliability of this update recovery is demonstrated by analysis and simulation. The results presented control the risk in existing WSN software update mechanisms.

1

Introduction

Continuing advances in miniaturization and integration are making wireless sensor network (WSN) technology more realistic for deployment. Over-the-air software updating is an important feature for a number of reasons: high maintenance levels, development, and new software features[1][2][3]. A number of WSN software update mechanisms exist. But, in the field, there can be significant hesitancy to use these to perform software updates. This is due to the risk of system-wide failure, requiring expensive and time consuming manual recovery, or possible leading to complete loss of a sensor network. For example, the software update functionality was not used in [4] due to the risks, as the nodes were inserted deep into a glacier. During the development process, failsafe software updates can remove the need to manually reset the nodes, and replace parallel communication channels for development. Traditional fault detection mechanisms, such as watchdog timers and exception handlers catch certain classes of software faults, but there are others classes which can prevent the nodes from participating in the WSN’s future operation. In this paper we propose and evaluate a novel failsafe recovery mechanism based on detecting this single symptom: loss-of-control. N. Komninos (Ed.): SENSAPPEAL 2009, LNICST 29, pp. 107–125, 2010. c Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering 2010 

108

S. Brown and C.J. Sreenan

The paper is organized as follows. Section 2 discusses related work. Section 3 describes our automated recovery model. This model uses high reliability broadcasting; Section 4 provides an analysis and simulation results for this. Section 5 describes a protocol to realise the model, and simulation results are provided in Section 6. Conclusions and future work are addressed in Section 7.

2

Related Work

Software update research is a key topic for wireless sensor networks[5]. The need to update the update mechanism itself, to reconfigure parameters, and to provide users with standardized utilities to manage online changes have also been identified, along with the need for overall update management[1]. There are a number of systems for updating wireless sensor network software ’over-the-air’, with the focus to date on efficiently propagating the update to the nodes (e.g. ZebraNet[6], DelugeM[7], SensorScheme[8]). If the software update fails, then recovery mechanisms based on exceptions and watchdog timer are used to try and recover. This is the key risk: node loss will occur if management connectivity is lost without triggering one of these mechanisms. Given the selfevident high risk of failure immediately after activating a software update, this prompts the need for a fail-safe software update mechanism which includes automated recovery if management connectivity is lost. This work does not address the downloading of software updates, but rather the recovery from downloads which contain faults which would prevent further downloads. There are two activities required to update software in a WSN: propagating the new software to all the nodes, and activating this software on each node. The benefits of separating these activities are explored in [2] and [3]. This separation is supported, for example, in Deluge with the ’injection’ and ’reprogramming’ activities. If the update fails, causing loss of network connectivity, then a third activity is required: automated local recovery.

3

Automated Local Recovery

To provide a low-risk environment for updating the software on the nodes in a WSN, every node must locally recover from faults in the updated software. (These faults are those that cause loss of management connectivity. Fault-tolerant data collection is not addressed here: it is an entirely separate matter from ensuring system recovery.) The keystone of failsafe recovery from faulty software updates is to be able to revert to a working software image, on each affected node, following loss-of-control. If a hardware errors occurs, but it allows connectivity to be maintained, then the node can be controlled (perhaps disabled) through network management. If not, the node will fallback to a known good software image, which may under some conditions help to re-establish connectivity. The price to be paid for a fail-safe fallback mechanism is false positives: where temporary loss of connectivity causes a node to fallback. In this case, when connectivity is restored, the node can revert to the operational software image.

Software Update Recovery for Wireless Sensor Networks

109

Having a maintenance image to reboot to when all else fails is an important element of node recovery (e.g. in [9]). But, to be effective, this depends on a mechanism to detect when it is needed, and to initiate its execution. In this paper, we introduce the term loss-of-control to describe the case where a software fault causes a loss of (management) connectivity from the management station to a node. Such loss of connectivity could be caused by various classes of faults in the updated code, but if the fault causes loss of management connectivity without triggering watchdog timeouts or exceptions, then each effected node is lost, and will require physical recovery. There are significant benefits in providing more complex recovery then just invoking the maintenance image[3] - for example, supporting fallback to the previously working version. 3.1

Identifying Loss of Control

We consider the case where a WSN is controlled by a management station via a gateway node. We assert that the only way a node can identify loss of control is whether it receives management traffic from the management station(s). Accurately identifying loss-of-control requires a high-reliability, end-to-end communication path from the management station to every node in the WSN, over unreliable and asymmetric links. Data paths are not suitable: they are mainly in the opposite direction, they may not be periodic to every node, and generally do not have a very high level of guaranteed delivery: this precludes piggybacking on data traffic or acknowledgements. Also, when nodes are running the maintenance image, dedicated connectivity traffic would still be required. The automated recovery mechanism described here uses periodic traffic from the management station, referred to as beacons. This is similar to a keep-alive heartbeat used in many embedded systems, but unreliable wireless links, and the constraints of wireless sensor nodes (e.g. energy, memory) make achieving highreliability operation more difficult. Unlike the Trickle/Drip distribution method used in SNMS [9], designed to eventually update all nodes, it is important that nodes do not re-broadcast messages periodically: this would propagate out-ofdate connectivity information. Also, protocols like Trickle do not provide the very high per-node reliability needed to ensure high system-wide reliability. Well established mechanisms for distributing network state, such as OSPF, are too heavyweight for infrequent communications in a WSN environment, both in terms of traffic and data storage. For example, every node maintains a full copy of the network-wide database. They also rely on low loss rates to establish stable, bi-directional connections with neighbours. For these reasons, many authors have argued that reactive protocols, such as described in this paper, are more suitable in a low traffic WSN environment than proactive protocols such as OSPF. We assert that there is no way, in an ad-hoc and multi-path environment, for any node (or local group of nodes) to determine whether loss of connectivity is due to a single node or a system-wide failure. Thus every node that loses connectivity must take action, whether it can communicate with other local nodes or not.

110

3.2

S. Brown and C.J. Sreenan

Recovery Action

There are two principle actions that can be taken to recover a node (and eventually an entire WSN). The first is to fall back to an ’known good software’ image. If this fails (or is not available) then the second action is to fall back to a maintenance image (e.g. Golden Image [10]). This needs a high level of reliability, and must provide at a minimum support for downloading and activating software updates. If the connectivity failure is due to faults in the software update, then recovering to ’known-good’ software restores network management connectivity (allowing further software updates to be downloaded/activated). If the connectivity failure is due to other causes (e.g. temporary loss of radio connectivity) then recovery returns the network to a state where, once the external factor is removed, it will be manageable. Data collection may be interrupted during recovery: so long connectivity timeouts are required, and the recovery mechanism should be used a last resort - other mechanisms (such as rerouting around effected areas) should activate on a shorter timescale. The minimum hardware/memory requirement is for a full-size image and a smaller maintenance image (with software updates performed from the maintenance image). If a node can store two full-sized images, then the software updates can be performed during operation, reducing disturbance to the application. This is reasonable: a MICAz mote has 128KB internal/512KB external flash; the TmoteSky has 48KB/1MB. A maintenance image might take up an estimated 32KB (e.g. Golden Image at c. 24KB). Where the image is stored will depend on the software download protocol and bootstrap loader. 3.3

Two-Phase Approach

It is likely that a WSN will exhibit early software update failures (for reasons explored in [3]). This motivates a two-phase approach to save energy. Software updates are initially run on a trial basis with a high frequency of monitoring providing for quick recovery, but using more energy. Following a successful trial, the same software version continues to execute, but on an operational basis, with a lower frequency of monitoring, providing slower recovery, but lower energy use. 3.4

State Machine

A node can be running in one of four modes from a software update and recovery viewpoint - see Figure 1. The TRY, RUN, and RTM commands are issued over the recovery protocol: TRY(x) starts a trial with software version x; RUN(x) starts operational use; and RTM initiates a Return to the Maintenance Image. As shown with the bold arrows in Figure 1, in normal use a node will startup in MAINTENANCE mode; and, for the first software update, will be transitioned to TRIAL mode, and then to OPERATIONAL mode. Subsequent software updates will be run initially in TRIAL mode and then in OPERATIONAL mode. In each state, a node will be running the software image as shown:

Software Update Recovery for Wireless Sensor Networks

111

Fig. 1. Recovery State Machine

– MAINTENANCE: running the maintenance image; – TRIAL and OPERATIONAL: running the specified software (version ”x”); – FALLBACK: the previous software image, or the maintenance image. The inclusion of a version id causes all (connected) nodes to try and activate the same version. It is regarded as a feature of the software download propagation functionality to ensure that this version is available. Protocols such as DHV[17] address the problem of ensuring that all the nodes are running the same software version following network partitioning, etc. The ”Timeout” events are raised by loss-of-control (i.e. beacon timeouts). The next section presents an investigation into reliably determining this.

4

High-Reliability Polycasting

The term polycasting is used in this paper to mean the propagation of traffic from a single node to all other nodes in the WSN (i.e. network-layer broadcasting); this allows clear differentiation from the term broadcasting which is used at the MAC layer. For each node to determine connectivity, a beacon must be polycast periodically from the management station (via a gateway). To provide a low level of unnecessary recovery, this propagation must have a high level of reliability. For example, if the maximum allowed probability of an unnecessary recovery in a 100-node WSN within 1 year is 5%, and connectivity traffic is polycast once a day, then the maximum connectivity error rate for each node is 0.0000014.

112

S. Brown and C.J. Sreenan

In this paper we focus on multi-path physical network topologies; these are common for wireless sensor networks due to the robustness properties that they present. The overlay network may form, for example, a spanning-tree, or linear, or grid, or clustered topology - but in general nodes will be placed so as to allow for alternate paths to cope with link or node failure. Two algorithms for high-reliability polycasting are Flooding and Spanning Trees. In [11] it is shown that Spanning Trees perform better for some metrics (i.e. count of relay nodes); here we show that, with energy consumption as a metric, optimised flooding can provide higher reliability for lower cost. Flooding has the additional energy benefit of not requiring any setup or maintenance. For generality, link-quality data and node position data is not knowna priori. In both cases a random transmit delay timer (”jitter”) is used to reduce medium contention. Optimizations with high overheads for low traffic levels (e.g. Clustering[12]) are not considered as candidate solutions: see [18] for a comparison of Clustering and Spanning-Tree approaches in WSNs. Also optimisations that would impact application traffic (e.g. power modifications[13]) are not considered. 4.1

Minimum Spanning Tree Algorithm

The Minimum Spanning Tree (MST) algorithm used for comparison was based on Bellman-Ford. MAC broadcast messages are used to minimize transmissions for data to multiple children, and overheard data packets provide free acknowledgements using the ”wireless broadcast advantage” ([14]) to parent nodes, with onyl leaf nodes sending an explicit acknowledgement. Link weight is expected transmissions to the root node, calculated from collected link-quality data. 4.2

Flooding Algorithm (FDMT)

Flooding with Duplicate-suppression, Missing packet regeneration, and Timeout (FDMT) removes the broadcast storm problem. A beacon is sent as a series of packets in a burst, with a burst ID (Burst Index) and a packet-in-burst counter (Burst Size). This allows each packet to be uniquely identified - only the first copy received of any packet is re-broadcast (Duplicate Suppression), using the burst ID and packet-in-burst counter. When missing packets are identified, from gaps in the received packet-in-burst counter, the node regenerates them (Missing Packet Regeneration). A lifetime field allows the burst IDs to be reused. The fundamental novelty of this algorithm is in using controlled duplicate (multipath) reception in order to provide very high reliability for one-to-many trafic in an ad-hoc wireless network. See Table 3 for the protocol fields. 4.3

Analytical Comparison

To demonstrate the benefits of FDMT (higher reliability for lower energy cost) we compare the results for a 4x4 grid of 16 nodes (see Figure 2) with the FDMT and MST algorithms described above. The root in both cases is at the top left hand corner, and the link quality/packet-receive-rate (PRR) pij is shown

Software Update Recovery for Wireless Sensor Networks

113

Fig. 2. 4x4 Grid Data Flows

(reflecting noise, distance, and interference-related packet loss). The probability of system failure is determined by the equation shown, where P ri (success) is the probability that node i receives at least one packet from P packets injected in a network of N nodes: P r(systemf ailure) = 1 −

N 

P ri (success)

(1)

n=1

For the spanning tree, the probability of success is determined as follows: P ri (success) = P rparent (success) ∗ (1 − (1 − pparent )P ) i

(2)

And for FDMT: P ri (success) = 1 −

n=N 

(1 − (P rn (success) ∗ (1 − (1 − pni )P )))

(3)

n=1

The results of applying these equations to the 4x4 grid are shown in Table 1 for increasing P, showing the probability of system failure and energy cost (Tx count) in each case. FDMT provides higher reliability for lower cost. For P=1, using FDMT each node only transmits once (reliability is attained through multiple receptions); but using MST, each node must reliabily transmit both an ack packet to its parent, and a data packet to each of its children in the tree. So, for example, to achieve a failure rate < 1-in-1000, costs 110 transmissions for MST, and 48 for FDMT. Or, for an energy cost of 48-55 transmissions, MST provides a failure rate of 32, 000 ppm, and FDMT a significantly lower failure rate of 3 ppm. 4.4

Experimental Comparison

To validate these results with a more realistic radio model, and a larger network, the two algorithms were simulated using TOSSIM [15], with the default TinyOS

114

S. Brown and C.J. Sreenan Table 1. MST vs FDMT Packets P 1 2 3 4 5 6

MST FDMT Pr(Fail) Tx Count Pr(Fail) Tx Count 0.316934 18.4 0.293000 16 0.100447 36.8 0.085849 32 0.031835 55.1 0.000003 48 0.010090 73.5 6.73E-12 64 0.003198 91.9 1.08E-14 80 0.001013 110.3 1.75E-17 96

MAC (details in Section 6). This radio model introduces significant traffic losses due to both noise and interference. Similar results (not included for space reasons) are seen for random topologies with the same average node densities as for the three topologies shown. A random transmit delay after reception of a new packet is used to reduce medium contention - the maximum value is specified in the ”Jitter” field. A minimum inter-packet transmission interval of 4*Jitter is used. A Jitter value of 675mS was used: 225 slots of 3mS each (large anough for an average transmit). Experiments have shown that this value achieves a reception rate over 99.9% for all densities with 225 nodes. The results of the simulation (measured over 100 runs for FDMT, 20 runs for MST) are shown in Table 2, showing the system reliability (Reliability) and MTTF (Mean Time To Failure). The cost is the average per-node transmit count, and the latency is the time from the first beacon injection, to full coverage (reception by every node). Note that, as for the analytical case, FDMT provides a higher reliability/cost ratio than MST. Table 2. MST vs FDMT Algorithm Density Tight System Reliability 100.0% System MTTF 9.75×1012 Avg. Node Tx 1 Latency [S] 0.051 Spanning Tree Tx 0

FDMT MST Medium Sparse Tight Medium Sparse 99.999% 99.55% 99.97% 99.92% 99.84% 1.93×105 2.42×102 3.93×103 1.33×103 6.28×102 2 4 5.17 4.06 4.54 0.444 1.633 9.1 19.05 36.8 0 0 29 29 29

Notes: – if latency is used as an indication of cost, representing required receiver on time, FDMT shows an even greater advantage; – the Spanning Tree Tx figures show the transmit count required to build the spanning tree; – achieving this reliability for the spanning tree required, on average, up to 23 re-transmissions - this is a significant contributor to the large latencies.

Software Update Recovery for Wireless Sensor Networks

115

For FDMT the key parameter is the burst size (number of packets sent in a burst). This is set by monitoring the minimum-duplicates feedback field (see Section 5). In our experiments, modifying the burst size to produce a minimum value of 5 to 6 duplicates provides the high reliability shown. For the Spanning-Tree, the key parameter is the per-link reliability: only one packet is injected as retransmissions are used to guarantee reliability. The perlink reliability is used to calculate the maximum retransmit count per link, based on the measured round-trip link quality (used as the weight for building the minimum cost spanning tree). A per-link reliability figure of 0.999999 (i.e. 1 failure per million) was used to achieve the above results - this produces an average system reliability of 0.999999225 = 99.978% (MTTF=225 bursts). As in the analytical case, the results demonstrate that FDMT provides higher reliability with lower cost. FDMT introduces no setup overhead, and has reduced RAM requirements: 64 bytes vs approx 1KB in our implementations.

5

Protocol Overview

The protocol packet definition used to evaluate recovery is shown in Table 3. This implementation contains 23 bytes, fitting into a standard TinyOS packet. The management station periodically polycasts ”Activation and Recovery” PDU’s into the network. The (wrapping) sequence number uniquely identifies the packet, and is timed out by the lifetime (to allow for safe wrapping) which is decremented Table 3. Protocol Field Summary Field Sequence Number Lifetime Jitter Burst Size Burst Index Mode-ID Mode Software-ID LoffOfControl Timeout Recovery Timeout Flags

Description unique ID for each burst (wrapping) timeout the wrapping Sequence No. random delay to reduce media contention packets in the burst packet burst position - for regeneration unique ID for the mode field (wrapping) the mode to run the software in the software version to run timeout for ”loss of control” from MAINT to FALLBACK Flag0=Failure Seen Bit, set after recovery

Max Hops

maximum hops seen

Min life Min Dups

minimum lifetime seen, used to set Lifetime minimum duplicates seen

116

S. Brown and C.J. Sreenan

on every hop. Burst Size and Burst Index are used to regenerate missing packets. Mode-ID is the mode sequence number; it is changed for each new Mode command. Mode specifies what state the node should take (reference Figure 1). A burst is used, instead of single packets, to provide better reliability within a power-cycled environment (higher reliability can be achieved with one cycle); it also allows separation of the required recovery time and the beacon injection period (by allowing multiple packets to be injected per period). A burst also provides quicker feedback to the management station (later packets in the burst will piggyback feedback to the management station from more remote nodes in the network).

6

Simulation

The protocol is simulated, both to demonstrate its correct operation, and also to measure the reliability and cost in an environment that allows direct access to each node to collect data. The protocol and state machine were simulated using the TOSSIM 2 simulator. Results for 225 node, 15x15 grid configurations (”tight”, ”medium”, and ”sparse”) are shown here representing networks with the characteristics shown in Table 4 using the simulator’s default parameters1 . The radio model uses the log-normal shadowing path loss model, and provides a realistic model of real-world conditions[16] with significant variability in packet reception rates as shown in Figure 3. The topologies span a wide range of network densities (from very tightly connected to very weakly connected), and provide for validation of the protocol across this wide range, and also show the impact that the network density has on the protocol performance characteristics. Table 4. Network Parameters Sparse Medium Tight Spacing 20m 10m 2.2m Nbrs. 9.17 30.01 191.37 Gain -108±9dB -110±9dB -90±9dB Noise -105±1.8dB Power 0dBm

6.1

Behavioral Results

The correct operation of the protocol is demonstrated here, showing 100% completion, and the latency times. Figure 4 shows the behavior of a successful software trial followed by operational use of the new software version for a medium density network. Initially the network is running the maintenance image. At time=20 a ”Try” command is inserted into the WSN via the gateway, and at time=30 a ”Run” command is inserted. In practice, it is likely that a trial would 1

See www.tinyos.net for details.

Software Update Recovery for Wireless Sensor Networks

117

Fig. 3. PRR vs Distance

Fig. 4. Successful Trial

last for multiple cycles of the WSN operation, possibly in the order of days rather than seconds. Figure 5 shows the behavior of a recovery during a trial following a software failure (with quick fallback, using the failure-seen flag) for a medium density

118

S. Brown and C.J. Sreenan

Fig. 5. Automatic Fallback Table 5. System Reliability Tight Medium Sparse Reliability 1.0 1.0 0.999994 99.9% CI <1.0E-9 1.81E-9 5.44E-6 MTTF >1000000 >1000000 166666.7

network. The center node (112) detects loss of connectivity at time 180, and propagates the failure-seen flag quick, network-wide, automatic recovery. 6.2

Estimating Long-Term Reliability

Long-term reliability is measured as the probability that all the nodes receive a beacon before timing out. The probability that no packets would have been received by the node is calculated as follows, where c is the number of packets received by node n from node i: Reliability = P r(success) = 1 −

n=N  i=N 

n

(1 − pni )ci

(4)

n=1 i=1

The PRR pni is measured during each simulation. This method allows the reliability of the system to be estimated from a relatively small number of runs. The results in Table 5, averaged over 450 runs, show the high reliability achieved. The 99.9% Confidence Interval (CI) was calculated using the Student-t distribution. The number of runs is based on producing a largest CI in the order of 10−6 .

Software Update Recovery for Wireless Sensor Networks

6.3

119

Propagation Delay

The propagation delay results (measured as the time from initial injection to 100% reception) are shown in Table 6 averaged over 93 runs, showing the min, max, and average in seconds (with 99.9% Confidence Intervals calculated using the Studentt distribution). The results show that higher network densities have both lower and less variable propagation times, and that reasonable propagation times can be achieved. Figure 6 shows a sample propagation delay pattern - the X and Y axes are spatial dimensions (150m from side to side), and the gateway node is in the bottom left corner. Note that the unreliable wireless links lead to both peaks (nodes that receive the beacon much later than their neighbours) and troughs (beacons that receive an early beacon over long-distance, low-reliability links). Table 6. Average Propagation Delays [Seconds] Density Delay Tight Medium Sparse Min. 0.035 0.369 1.5 Avg. 0.285 0.743 2.5 99.9% CI 0.015 0.023 0.16 Max. 0.6 1.2 9.3

6.4

Recovery Latency

The ”failure-seen” flag provides feedback to the management station that a connectivity failure has been seen and recovered from by some nodes. For a ”Quick-Trial”, no reaction is required: the network will automatically fallback. In ”Operational” use, the management station may query the nodes (using a management protocol such as SNMS [9]), or issue further Software Activation commands to recover the network. Table 7 shows the recovery latency for a failed ”Quick” software trial, measured between a (simulated) software failure occurring and: that node identifying loss of connectivity (T1 ), all the nodes automatically recovering (T2 ), and the fail flag seen at the management station (T3 ). The failure was simulated on the center node (112); the burst frequency was 20 seconds. The results are averaged over 20 runs, and are shown in seconds (with ± 99.9% Confidence Intervals shown in brackets). Table 8 shows the performance for an Operational software failure in terms of the times between the simulated software failure occurring and (a) the failed node identifying loss of connectivity (T4 ), and (b) the fail flag seen at the management station (T5 ). The failure was simulated on the center node (112), with a burst frequency of 20 seconds, with results averaged over 20 runs, and shown ± the 99.9% Confidence Interval in seconds. Note the close correlation of results with the separate set of experiments shown in Table 7.

120

S. Brown and C.J. Sreenan

Fig. 6. Propagation Pattern Table 7. Recovery Latency [Seconds] Tight Medium T1 19.0 (±0.0) 19.3 (±0.13) 19.4 T2 23.6 (±0.43) 25.4 (±0.34) 31.2 T3 24.0 (±0.0) 25.0 (±0.33) 33

Sparse (±0.67) (±0.92) (±1.01)

Table 8. Reporting Latency [Seconds] Tight Medium Sparse T4 19.0 (±0.00) 19.3 (±0.13) 19.4 (±0.67) T5 24.0 (±0.00) 25.0 (±0.33) 33.0 (±1.01)

6.5

Energy Use

This activation and recovery protocol runs during powered-up cycles of a powercycled WSN, and thus works with the synchronisation mechanism in use (for downloading software updates, and network management, as well as for the sensornet application). This implies that no additional energy is required to

Software Update Recovery for Wireless Sensor Networks

121

Fig. 7. Energy Use, Normal Operation

Fig. 8. Energy Use, Quick-Trial Recovery

receive packets (typically transceiver power use is the same whether receiving or not), so the incremental power used by the protocol is measured in transmits. The low latency requires little extension to the power-up phase of the duty cycle.

122

S. Brown and C.J. Sreenan

If an alternative power saving approach, such as wake-on-wireless or preamble sampling, is being used, the energy cost would be directly proportional to the number of transmits. Figure 7 shows the energy use under normal operation (in terms of packets transmitted): the average is one packet transmitted per node per packet injected. This graph is extracted from a long run (10,000 beacons), and shows 22 beacon cycles, with a burst-size of 2. This could represent, for example, 22 days with one sequence per day (providing for a connectivity timeout value of 2 days), or 22 hours with one sequence an hour (providing for a 2-hour connectivity timeout). Energy use is linear with time, and with network size. If transceiver on time is used as the energy metric, then the power requirement would be in the order of 1 second per day for a medium network (based on a measured maximum of 0.8S). Figure 8 shows the energy use of recovery following a failed software trial. There is higher energy use during the software trial operation, due to the higher frequency of beacon sequences, and a lower latency for identifying failure (and recovering). The energy use per beacon sequence is the same as for normal operation, but additional energy is expended during the automated recovery (steeper slope of the energy line) reflecting the propagation of the fail flag. 6.6

Energy vs. Latency Tradeoff

The energy/latency tradeoff is shown in Figure 9 for a burst size of 2 beacons, and using the Mica2 transmit power level of 0dBm=1mW with an average broadcast

Fig. 9. Energy/Latency Tradeoff

Software Update Recovery for Wireless Sensor Networks

Fig. 10. Maximum Hops vs Burst Size

Fig. 11. Minimum Duplicates vs Burst Size

123

124

S. Brown and C.J. Sreenan

transmitter on time of 2.1mS per packet (as measured in the simulator). The latency is for a node to identify loss-of-connectivity. This shows the benefit of two-phase operation: low latency/high power usage software trials (left), and high latency/low power operational use (right). 6.7

Feedback

Feedback is propagated for free by piggy-backing data (Table 3) on the beacons. An example, using a sparse network, is shown in Figures 10 and 11 over two runs. The figures show that the actual number of hops (hmax-actual) is reported more accurately to the management station (hmax) as the burst size increases, and that the actual number of duplicates (dmin-actual) is also reported more accurately (dmin) with the burst size. The burst size is modified until maximum hops (hmax) value stabilizes, and then the minimum duplicates value (dmin) used to refine the burst size. Actual values as well as reported values are shown for comparison. Minimum duplicates between 5 and 10 works well for the wide range of network densities simulated.

7

Conclusions and Future Work

In this paper we present a software update safety net that reduces the risk of WSN loss during software updates, and we demonstrate its effectiveness through simulation. We show a new result: that an optimised flooding approach provides better efficiency and responsiveness than a spanning-tree for very high reliability polycasting. Our results show the energy costs of using the software update and recovery mechanism, and evaluate the energy/latency tradeoff. Using the same mechanism for both propagating update commands, and also measuring management connectivity, is shown to be effective. The protocol provides the update recovery mechanism that we have argued is an essential part of realworld wireless sensor networks. The two phases of operation of a software update, Trial and Operational, allow the conflicting requirements for a quick, network-wide recovery in the one case, and a low-energy, node-specific recovery in the other case, to be resolved. This allows for quick recovery of the network when a software update fails soon after its deployment, at the cost of higher energy use. And for better continuation of operation of the set of working nodes, while still guaranteeing eventual recovery, with lower energy use in normal operational use of the sensor network. Future work includes simulation and real-world assessment on a range of network densities and topologies, and integration with existing software update mechanisms. This recovery might also be used for communication nodes in a hierarchical networks, with a simplified version for the sensing nodes (e.g. IEEE802.15.4 full and reduced function devices). In summary, by providing for fail-safe software update recovery, which significantly reduces the risk of losing nodes due to faulty updates, this work provides the basis for high confidence in using over-the-air software updates. This is an

Software Update Recovery for Wireless Sensor Networks

125

important element of real-world deployment, and will make WSNs more flexible and supportable in practice.

References 1. Han, C.-C., Kumar, R., Shea, R., Srivastavam, M.: Sensor network software update management: a survey. Intl. Journal of Network Management 15, 283–294 (2005) 2. Wang, Q., Zhu, Y., Cheng, L.: Reprogramming wireless sensor networks: challenges and approaches. IEEE Network 20(3), 48–55 (2006) 3. Brown, S., Sreenan, C.: A new model for updating software in wireless sensor networks. IEEE Network 20(6), 42–47 (2006) 4. Padhy, P., Martinez, K., Riddoch, A., Ong, H.L.R., Hart, J.K.: Glacial environment monitoring using sensor networks. In: Proc. RealWSN 2005, pp. 10–14 (2005) 5. Kothari, N., Nagaraja, K., Raghunathan, V., Sultan, F., Chakradhar, S.: Hermes: A software architecture for visibility and control in wireless sensor network deployments. In: Proc. IPSN 2008, pp. 395–406 (2008) 6. Liu, T., Sadler, C., Zhang, M., Martonosi, P.: Implementing software on resourceconstrained mobile sensors: Experiences with impala and zebranet. In: Proc. MobiSys 2004, pp. 256–269. ACM, New York (2004) 7. Xiao, Z., Sarikaya, B.: Code dissemination in sensor networks with mdeluge. In: Proc. SECON 2006 (2), pp. 661–666. IEEE, Los Alamitos (2006) 8. Evers, L., Havinga, P., Kuper, J.: Flexible sensor network reprogramming for logistics. In: Proc. MASS 2007, pp. 1–4. IEEE, Los Alamitos (2007) 9. Tolle, G., Culler, D.: Design of an application-cooperative management system for wireless sensor networks. In: Proc. EWSN 2005, pp. 121–132. IEEE, Los Alamitos (2005) 10. Dutta, P., Hui, J., Jeong, J., Kim, S., Sharp, C., Taneja, J., Tolle, G., Whitehouse, K., Culler, D.: Trio: enabling sustainable and scalable outdoor wireless sensor network deployments. In: Proc. IPSN 2006, pp. 407–415. IEEE, Los Alamitos (2006) 11. Williams, B., Camp, T.: Comparison of broadcasting techniques for mobile ad hoc networks. In: MobiHoc 2002, pp. 194–205. ACM, New York (2002) 12. Liang, C.-K., Huang, Y.-J., Lin, J.-D.: An energy efficient routing scheme in wireless sensor networks. In: Proc. AINAW 2008, pp. 916–921 (2008) 13. Rahnavard, N., Vellambi, B., Fekri, F.: Distributed protocols for finding low-cost broadcast and multicast trees in wireless networks. In: Proc. SECON 2008, pp. 551–559. IEEE, Los Alamitos (2008) 14. Wieselthier, J., Nguyen, G., Ephremides, A.: On the construction of energy-efficient broadcast and multicast trees in wireless networks. In: Proc. INFOCOM 2000 (2), pp. 585–594. IEEE, Los Alamitos (2000) 15. Levis, P., Lee, N., Welsh, M., Culler, D.: Tossim: accurate and scalable simulation of entire tinyos applications. In: Proc. SenSys 2003, pp. 126–137. ACM, New York (2003) 16. Zuniga, M., Krishnamachari, B.: Analyzing the transitional region in low power wireless links. In: Proc. SECON 2004, pp. 517–526. IEEE, Los Alamitos (2004) 17. Dang, T., Bulusu, N., Feng, W., Park, S.: DHV: A Code Consistency Maintenance Protocol for Multi-hop Wireless Sensor Networks. In: Proc. EWSN 2009, pp. 327–342. Springer, Heidelberg (2009) 18. Tan, H.O., Korpeoglu, I.: Power Efficient Data Gathering and Aggregation in Wireless Sensor Networks. SIGMOD Record 32(4), 66–71 (2003)

A Framework for Time-Controlled and Portable WSN Applications Anthony Schoofs1 , Marc Aoun2 , Peter van der Stok2 , Julien Catalano3 , Ramon Serna Oliver4 , and Gerhard Fohler4 1

CLARITY: Centre for Sensor Web Technologies, Dublin, Ireland [email protected] 2 Philips Research, Eindhoven, The Netherlands {marc.aoun,peter.van.der.stok}@philips.com 3 Enensys Technologies, Rennes, France [email protected] 4 University of Kaiserslautern, Kaiserslautern, Germany {serna oliver,fohler}@eit.uni-kl.de

Abstract. Body sensor network applications require a large amount of data to be communicated over radio frequency. The radio transceiver is typically the largest source of power dissipation; improvements on energy consumption can thus be achieved by enabling on-node processing to reduce the number of packets to be transmitted. On-node processing is facilitated by a timely control over process execution to sequence operations on data; yet, the latter must be enabled while keeping highlevel software abstracted from both underlying software and hardware intricacies to accommodate portability to the wide range of hardware and software platforms. We investigated the challenges of implementing software services for on-node processing and devised constructs and system abstractions that integrate applications, drivers, time synchronization and MAC functionality into a system software which presents limited dependency between components and enables timely control of processes. We support our claims with a performance evaluation of the software tools implemented within the FreeRTOS micro-kernel. Keywords: Wireless sensor networks, portability, temporal control.

1

Introduction

The use of low-cost and intelligent physiological sensor nodes, capable of sensing, processing, and communicating one or more vital signs to a monitoring station is the next step for health monitoring. Wearable health monitoring systems can closely monitor changes and provide feedback to either the remote clinician or the patient himself about life-threatening alerts, as well as to maintain an optimal health status. Because of the scarce resources available on the nodes, achieving both accurate health monitoring and long-life node activity is rendered difficult. Indeed, accurate health monitoring requires continuous acquisition and reasoning on sensor data. A stroke rehabilitation system is an example of sensor-based N. Komninos (Ed.): SENSAPPEAL 2009, LNICST 29, pp. 126–144, 2010. c Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering 2010 

A Framework for Time-Controlled and Portable WSN Applications

127

system where the amount of data and frequency at which they are transmitted is high [5]. The direct consequence is the intensive use of the Radio Frequency (RF) transceiver, which dominates the power consumption of a node. Power consumption can be reduced by enabling reasoning and processing of data on the node; this offers the opportunity to avoid the transmission of raw data and to exchange only valuable information processed from sensor data. For this type of applications, enabling software services for on-node processing is required. Also, in this application where multiple nodes work together for monitoring health, a common notion of time shared by the nodes is required to treat, correlate and combine the different types of data. It allows collective signal processing, accurate duty-cycling, data aggregation, and distributed sampling. SAND nodes [1] are an example of flexible body sensor nodes with a fixed core around which application specific sensors and actuators can be placed. Another motivation of this work is to support this view of flexible nodes by providing a software system with a fix core around which software components can be seamlessly integrated, and ported to new hardware configurations. Portability facilitates reuse of existing applications and software for on-node processing in new execution environments. With these goals, we investigated the necessary software services and system abstractions, and the challenges to integrate them without depreciating the system’s performance. Section 2 presents information essential to understand the motivation of this work and related work. In Section 3 we present the software constructs that we devised and the problems solved. We validate our work with a performance evaluation of the software tools implemented within the FreeRTOS micro-kernel in Section 4. Finally Section 5 concludes.

2 2.1

Background Constraints with Development in Lightweight Software Environments

The following summarizes the usual constraints associated with lightweight or monolithic software environments. Hardware dependent application code. This depicts a situation where direct accesses to hardware low-level details are included into application software (e.g. writing hardware registers for peripheral control). When hardware interfaces are changed or not fully compatible, additional effort to adapt code deviates application developers from their main application development task, forcing them to dive deep into the hardware details. No separation of independent processes. One single thread for the program execution forces the application developper to combine independent application processes. For the envisioned application scenario, data acquisition, data processing, and time synchronization would end up correlated, making the code unclear and difficult to debug.

128

A. Schoofs et al.

No control on timing. By combining different application processes in one single thread, it becomes difficult to keep accurate control on timing. Changes in one part of the code involve new time delays for other processes that require new timing calculations at each occurrence. No prioritization of processes. One single thread executes sequentially the different application processes and no priority can be given to a process. Limited portability. With application specific code, written for a specific hardware configuration and intricated within different processes, very little can be reused directly. 2.2

Challenges to Enabling Temporal Control over Processes and System Abstraction

Timely control over processes on the node requires a clear separation of independent software processes and means of scheduling these processes according to their priority and timing deadlines. Global or distributed timely control over processes additionally requires that a common notion of time is shared by the nodes. That way, they are able to locally schedule and execute processes in global synchrony. A first challenge is then to enable accurate execution of processes on the node, contingently based on a global time knowledge. Sequencing operations on data requires a close interaction with the underlying system services. This aspect contrasts with the portability needs of algorithms and applications, that should be favored to accommodate the wide range of hardware and software platforms. A second challenge is then to ensure that providing timely control over processes to high-level software does not prevent portability. Drivers and applications are often provided by different developers, and either need to be developed or ported to the hardware platform. As the software development grows, it is important to bring all the software parts together. Merging implementations exposes the software system to code redundancy and bugs. Therefore, a consistent and reliable system abstraction on which to write high-level software is advocated. A third challenge is to devise an abstraction that enables an optimal usage of the platform (possibly specific) hardware and software mechanisms, while presenting a uniform top application programmer interface (API) hiding those various intricacies. 2.3

Related Work

On the software side little consensus exists about the basic functionalities that should be at the disposal of the application developer. In a sense the situation for software is worse than the situation for the hardware. Where the hardware goals are more or less clear: smaller and lighter with less energy consumption, the software goals are undefined. Many people experiment in isolation with their favoured software paradigm to create answers to isolated problems. Identified problems centre around software constructs, which give access to the hardware

A Framework for Time-Controlled and Portable WSN Applications

129

with a low consumption in memory. We aim at providing a software platform on which a given class of applications can be developed, removing the problems of synchronization and many hardware intricacies from the application, as well as enabling on-node processing to lower the overall energy consumption. Event-based and preemptive multithreading are two approaches to programming resource constrained systems. Event-based operating systems are efficient as they require little memory and processing resources. TinyOS is a very famous open source component-based operating system and platform targeted to wireless sensor networks [10]. It is designed to incorporate rapid innovation as well as operate within the severe memory constraints inherent in sensor networks. It is largely written in C and NesC, a component-based programming language and an extension to the C programming language. Multithreading is not provided in the original version to prevent excessive stack usage and the system bases its operation on run-to-completion semantics. The efficiency comes at the cost of additional programming overhead; connecting results of software modules, keeping track of execution flow, and determining when a specific function ends is the programmer’s responsibility. Later work introduced TinyThread, a library for TinyOS that enables true multi-threading on a mote [11]. Task preemption required to meet temporal requirements is not provided, but has been enabled with low memory overhead by Duffy et al. [12]. A second event-driven embedded operating system is Contiki [13]. Contiki uses protothreads, a lightweight form of cooperative threading, implemented as pre-processor macros. Protothreads provide the programmers with a more natural way of formulating their code. Contiki implements implicit network time synchronization. No explicit time synchronization messages are sent: the module relies on the underlying network device driver to timestamp all radio messages, both outgoing and incoming. An average synchronization error of 1.4 ticks was achieved in single-hop network, with one tick equal to 2ms [14]. A high time synchronization accuracy is needed to be able to synchronize the execution of events on separate nodes, and to be able to time-stamp precisely events and sampled data. While TinyOS and Contiki lack native real-time support, FreeRTOS provides pre-emptive scheduling based on task priorities. FreeRTOS is a portable, open source, micro Real Time Kernel [2]. It is responsible for managing system resources, processor, memory and I/O peripherals. FreeRTOS code base is small, and is mostly written in standard C. Each task is assigned a priority and tasks with the same priority share the CPU time in a round-robin fashion. FreeRTOS scheduler is configured as preemptive to answer the real-time behaviour required by the system. FreeRTOS queue mechanism is priority aware for real-time treatment. Tasks and Interrupt Service Routines (ISR) can also communicate using queues, and binary semaphores are implemented as a special case of queues. Similar to Contiki, FreeRTOS does not provide a native 802.15.4 MAC implementation. In this work we have strong requirements on temporal execution of processes for on-node and distributed processing. We also favor the integration of a generic and standard compliant MAC protocol, as the presented framework should fit the needs of multiple applications scenarios and different hardware configurations.

130

A. Schoofs et al.

The aforementioned OS and micro-kernels do not natively provide the software for supporting those requirements. A choice of micro-kernel as the core of our software environment was made. Our choice of adopting FreeRTOS, instead of an event-based OS such as Contiki, has a number of reasons. Application programmers are usually more familiar with traditional multi-threaded programming, in comparison with an event-based environment where an explicit differentiation might exist between requesting operations in one phase, and processing notifications in a second phase. This is in contrast with traditional multi-threaded environments, where the execution flow of individual tasks is easier to follow. Additionally, in an event-based programming model, when combined with runto-completion semantics, it becomes the responsibility of the application programmer to carefully divide long-running tasks into multiple smaller entities to ensure a timely flow of execution of the system as a whole. Software portability is achieved with a consistent and extensive abstraction of the underlying system: abstraction of the microcontroller hardware details and system resources. Much work has been done in researching portability for application development in wireless sensor networks. The authors of [15] have successfully achieved with the MAC Layer Architecture (MLA) a componentbased approach for developing MAC protocols. Code is reused and intricacies of hardware platforms are hidden to the developer. Our objective is different; we aim at facilitating the development of applications, device drivers and middleware. MAC protocols are generally modeled as a communicating state machine, where each state represents a different phase in the communication protocol. The execution of the state machine is supported by the underlying software system. Our work on the MAC does not aim at producing hardware dependent code reused by different MAC protocols; we aim at breaking the influence of software constructs, supporting the MAC state machine execution, on higher layer processes’ timing control and portability. In [16], a three-layer hardware abstraction architecture has been introduced with the objective of increasing portability and simplifying application development. Although such design facilitates the building of platform independent applications, abstraction of hardware intricacies needs to be conjugated with an abstraction of the underlying software system. 2.4

Software Architecture Overview

In the presented framework, timely control over processes is enabled via the use of micro-kernel services, time synchronization, and a task-based IEEE-802.15.4 MAC implementation. Software portability is achieved with a hardware peripheral abstraction and an operating system (OS) API, built around the micro-kernel. Figure 1 depicts the devised software framework architecture. The 6LoWPAN adaptation layer and UDP/IP protocol stack are described in [8]. The task synchronization component enables synchronized execution of processes on multiple nodes. We show in Section 4 how this service for distributed node processing has been integrated within the framework.

A Framework for Time-Controlled and Portable WSN Applications

131

Applications / Middleware / Device Drivers

Socket API Task Synchro

UDP/IP 6LoWPAN

Time Synchro

MAC

Micro-Kernel

Micro-Kernel

OS API

Peripheral Drivers Interrupt Service Routines

Hardware Presentation Layer

Basic functions

Hardware

Fig. 1. Software framework architecture

3 3.1

Architecture A Micro-kernel as the Core of the Software System

The choice of a micro-kernel is motivated by the memory and resource constraints of low-power microprocessors and by the flexibility in term of functionalities that are supported. Every system designer can use the same base, the micro-kernel, and add or remove components as required by the application. For wireless sensor networks applications, multi-threaded kernels offer the possibility to run fixedpriority tasks which guarantee the execution of processes that need real-time behaviour. The type of applications devised for wireless sensor networks requires a small number of tasks, which limits the memory and latency overhead. A multithread environment helps the programmer separate unrelated code, and breaks the timing and event dependency. By having independent applications in different tasks, it becomes also easier to read the code and debug it. We used FreeRTOS micro-kernel to implement and validate our software constructs. It is responsible for managing system resources, processor, memory and I/O peripherals. 3.2

Achieving Timely Control over Processes

Reducing the MAC Influence on Application Process Execution Motivation. The Medium Access Control (MAC) is an important piece of software which impacts on the architecture of the total node software. The IEEE 802.15.4 standard [18] has defined a physical and MAC layer for low bit-rate and low-power consumption, to enable communication within nodes. Transmission of

132

A. Schoofs et al.

data or command frames relies on a Carrier Sense Multiple Access with Collision Avoidance (CSMA-CA) protocol to schedule the communication. CSMA-CA is implemented using units of time called backoff periods, which are generated via a periodic event (e.g. timer periodic tick) on the microcontroller. Most 802.15.4compliant transceivers have only a small subset of 802.15.4 features built in hardware and MAC protocol mechanisms including CSMA-CA are implemented in software on the node’s microcontroller. Therefore, both MAC and applications share the same processing power. Generally, 802.15.4 MAC software is implemented as interrupt-driven, where the MAC state machine is executed within interrupt service routines, executed every 320µs on MAC tick interrupts (e.g. [19]). The regular backoff-slot tick and the lengthy software execution within the ISR impose unnecessarily constraints to the whole software system. Ticks are happening even when RF communication is not required, and thus increases overhead. Besides, once an interrupt-based MAC implementation is adopted, the application is often developed as one background task removing all possibilities of independently executing tasks. A later switch to a task oriented micro-kernel becomes very difficult. Also, when interrupt nesting is not supported by the microcontroller of a new hardware platform, an interrupt-driven implementation becomes unusable. We propose a new architecture based on a preemptive task execution environment. With the proposed architecture, MAC software is activated by the micro-kernel scheduler, providing a solution where MAC software is not executed by an ISR, but by a micro-kernel task. A task-based implementation. Micro-kernel tasks are scheduled on the basis of the periodic tick interrupts of the micro-kernel timer. Our design takes a dual scheduling approach, where a second timer dedicated to the MAC is started for handling RF communication: one timer generates OS ticks for the micro-kernel scheduling whereas a second one generates ticks for the MAC scheduling, only when needed. With more powerful timer engines, one single timer can generate the two ticks. The interest is to be able to adapt dynamically the tick frequency to the application, to avoid useless overhead and reduce power consumption, and to clear the influence of the MAC on the software system by removing the execution of MAC software from ISRs. With this approach two timer bases are maintained and MAC software is executed within a micro-kernel task, removing the architecture constraints of interrupt-based implementations. General aspects on implementation. We have implemented an 802.15.4 MAC onto the FreeRTOS micro-kernel following the task-based architecture. In the micro-kernel -based implementation of the MAC, the MAC is considered as an application whose duty is to drive the transceiver chip to be compliant with the 802.15.4 standard. Accordingly, the MAC will be run by one FreeRTOS task, which we call the FreeRTOS MAC task. Currently, the FreeRTOS MAC task has the highest priority of all FreeRTOS tasks, in order to respect timing constraints related to network wireless communication. Two FreeRTOS binary semaphores have been created to control the operations for packet transmission (TX) and packet reception (RX). Initially and repeatedly, the FreeRTOS MAC task checks the FRTOS MAC semaphore used for controlling TX operations, as shown below:

A Framework for Time-Controlled and Portable WSN Applications

MAC tick started

Application task Init

FRTOS_MAC_ semaphore released

Application code ...

Call to MAC primitive for TX transmission MAC tick started Application code ...

133

MAC functions added to priority queue

MAC functions executed on each MAC tick interrupt in the FreeRTOS MAC task

MAC tick stopped

MAC process completed

Fig. 2. Task-based MAC process execution for a packet transmission

portTASK_FUNCTION(FreeRTOS_MAC_Task,pvParameters){ for(;;) { //Wait for the semaphore to become available if(xSemaphoreTake(FRTOS_MAC_semaphore,portNO_BLOCK)){

When packet transmission is not required, the FreeRTOS MAC task cannot take the FRTOS MAC semaphore semaphore. Next, the FreeRTOS MAC task checks the FRTOS MAC FIFOP handle semaphore in case a RX packet is to be retrieved, as shown below: if (xSemaphoreTake(FRTOS_MAC_FIFOP_handle_semaphore, portBLOCK)){

In case no packets are received, and after a time defined by the portBLOCK parameter, control returns and the FreeRTOS MAC task loops back to the first if condition. Higher-level protocols that need to access the MAC use the 802.15.4 primitives. Transmission of data happens during units of time called backoff slots. For that purpose MAC primitives called by higher layers will add MAC requests to one of four priority queues. The FreeRTOS MAC task executes the corresponding functions by taking the oldest request from the highest priority nonempty queue, and executes the corresponding function, starting on a backoff slot boundary. The execution of MAC functions is state machine based on a task information structure. This structure contains information on the currently active functions and the associated packets. As long as the priority queues are filled, the MAC timer is active and generates interrupts every 320µs. On interrupts from the IEEE 802.15.4 chip, the MAC timer ISR releases the FRTOS MAC semaphore thus liberating the blocked FreeRTOS MAC task which executes the MAC functions according to the contents of the task information structure, as shown in Figure 2.

134

A. Schoofs et al.

On packet reception, the transceiver generates interrupts at the microprocessor to indicate the reception of an 802.15.4 packet. The FIFOP interrupt signals that a complete frame has been received. When the FIFOP interrupt occurs, the corresponding ISR releases the FRTOS MAC FIFOP handle semaphore that blocks the FreeRTOS MAC task. The ISR terminates and the micro-kernel scheduler checks whether new micro-kernel tasks were enabled by the interrupt. The semaphore released by the ISR unblocks the FreeRTOS MAC task. The latter retrieves the payload from the transceiver. Providing a Common Notion of Time throughout the Network Motivation. Peer sensor nodes lack a common notion of time. Since timing is of importance for coherently time-stamping packets in the network, performing data fusion and correlating sensory data, a time synchronization procedure is needed to provide distributed sensor nodes with the same notion of time. In order to synchronize the clocks in our testbeds, we integrated a time synchronization component based on the FTSP protocol [4]. In FTSP, nodes in a network synchronize their clocks to that of a single time master. Multihop time synchronization is supported by requiring any node synchronized to the master to assume a time master role for its unsynchronized neighboring nodes. FTSP combines accurate MAC-layer time-stamping of time synchronization packets [21] and clock drift rate estimation using linear regression [22]. With the motivation to provide the high timing accuracy required for on-node data processing and distributed sampling, while reducing the associated overhead, we introduced the use of Kalman filtering for estimating the clock drift, which gave interesting insight in the reduction of clock synchronization messages exchange [23]. General aspects on implementation. To achieve time-stamping of time synchronization messages at the MAC layer, we used the Start of Frame Delimiter (SFD) interrupt, specified in the IEEE 802.15.4 standard, as a triggering event for time-stamping. The SFD interrupt occurs at the sender of a time synchronization message and at the receiver of that same message. Neglecting propagation time, these ”twin” interrupts can be considered to be simultaneous. A timestamp made at the sender side is included in its corresponding time synchronization message. This is achieved by writing the first part of the message’s payload to the CC2420 transmission buffer (TxFIFO), initiating transmission, waiting for the SFD interrupt to occur and the time-stamp to be made, and then writing the time-stamp to the TxFIFO in time before the buffer runs out of bytes to send and the CC2420 signals a buffer underflow. At the receiver side, a second time-stamp, made upon the occurrence of the ”twin” SFD interrupt, is associated with the received message. As such, a pair of time-stamps related to the same time synchronization message becomes available at the receiver side. The latter applies linear regression on a set of n consecutive pairs of time-stamps, or alternatively Kalman filtering, to determine the clock drift rate between sender and receiver. Time synchronization is implemented in a FreeRTOS task, and is an optional service available to the application developer. The interrupt subscription mechanism depicted in Section 3.3 keeps time synchronization related

A Framework for Time-Controlled and Portable WSN Applications

135

code out of other components e.g. the MAC. The time synchronization task subscribes to the SFD interrupt and defines code to execute whenever the interrupt fires (at the sender and at the receiver). The code related to time-stamping and addition of the time-stamp to the packet is then confined to the time synchronization task, and makes the module non-intruding. 3.3

Achieving Portable Software

We designed a set of abstraction layers that break the application dependency on hardware intricacies and software system. Abstracting the Hardware Intricacies Motivation. The motivation behind abstracting the hardware intricacies of a microcontroller is to ease application development, enable code re-use between different applications, optimize hardware interaction, facilitate the portability of device drivers and applications, protect access to hardware peripherals and ease debugging. Challenges. Abstracting hardware should not compromise efficiency by hiding platform features that may optimize a set of processes. For instance, the 24-bit architecture of the NXP CoolFlux DSP equips it with a SPI interface that allows transfers of up to three bytes per transaction, as opposed to traditional 1-byte transactions. Making use of such feature improves process latency and accompanying energy by reducing the occurrence of micro-kernel context switches on each peripheral interrupt and lowering the overhead of fetching bytes in the memory. Another challenge is the handling of peripheral transactions in hardware without introducing high latency overhead. Hardware handling of peripheral transactions in parallel to software execution prevents the use of blocking calls. Description. We developed an hardware abstraction with a layered architecture to present a common interface to applications for controlling the underlying hardware. This architecture provides all the necessary functions to communicate with the different hardware blocks. The architecture is given in Figure 3. The Basic functions layer is a very thin layer enabling a way to read and write to the input and output registers of the micro-controller and to redirect hardware interrupts to the Interrupt Service Routines (ISR) layer. The ISR layer handles the interrupts, and can be used to free a semaphore or post data to a queue using the micro-kernel system interface, operate on the hardware such as acknowledging the interrupt or sending an extra byte, or simply run application code. In order to keep the application code separate from the hardware specific sections of the code, the ISR layer provides a subscription mechanism which allows for applications or device drivers to perform custom actions within the interrupt. Applications tasks, device drivers and peripheral drivers can subscribe to a specific ISR and write some code, placed outside the hardware specific code, to be executed when the interrupt fires. The Hardware Presentation Layer (HPL) provides a complete and dense interface of all the hardware peripherals to the

136

A. Schoofs et al.

App. 1 Device Drivers

App. 2

App. 3

OS API

Microkernel

Peripheral Drivers Interrupt Service Routines

Hardware Presentation Layer

Basic functions

Hardware

Fig. 3. Hardware Abstraction Architecture

upper layer. This layer is stateless, meaning that it will not keep information about the status of a peripheral. It executes the order from upper layers. This layer, despite the fact that it provides standard functions, is not generic to all the platforms as it contains platform specific options. It is meant to expose all the functions available on the underlying hardware. Finally, the Peripheral Drivers layer, using the HPL, provides the application or the upper device drivers with a set of functions to use the hardware safely and in interaction with the microkernel. In this layer, the state of the interface is kept in a dedicated structure and data and/or events related to a bus or a timer are also recorded in micro-kernel queues or semaphores. The common top interface is the peripheral driver layer interface. The layers underneath are platform specific and should not be exposed to the application layer for portability reasons as well as for the risk of misuse. In order to make use of any platform specific features, the peripheral layer is implemented such that it optimally makes use of the underlying hardware via the HPL. Figure 4 depicts an example where the MAC initiates a packet transmission. In the process, the packet is transmitted to the radio transceiver via the SPI interface before the actual physical transmission. For that purpose, the CC2420 radio driver uses the API of the SPI peripheral driver. The latter passes the first byte of data to the HPL layer, and the remaining bytes are stored in the SPI TX FreeRTOS queue, for later transmission. The byte is eventually transmitted via SPI once written in the SPI data register. On SPI transfer completion, the SPI ISR checks in the TX queue the whether other bytes need to be transmitted. If yes, the next byte is passed to the HPL layer for immediate transmission and so on until the last byte is transmitted. Abstracting the Software Environment Motivation. A subset of existing OS are widely used by the WSN community. Porting applications among different operating systems is a time consuming exercise which requires a deep knowledge of both application domain and OS

A Framework for Time-Controlled and Portable WSN Applications

RfPayload: [0xad,0xd8,…]

MAC

xRadioSend(address,&RfPayload,length);

CC2420 driver Microkernel

137

xSpiDeviceTransfer(SPI0,&RfPayload[0],…);

SPI Driver ISR

pxPort->pxTxQueue: [0xd8,…] xSpiPut(SPI0, 0xad);

HPL

xQueueReceiveFromISR(xSPI_ISR[ePort]->pxTxQueue,…); xSpiPut(SPI0,TxWordToSend); cf_write_reg(cf_inthandler.status, cf_write_reg(spi[0].data, 0xad); (1 << int_spi0)); goto void_SERIAL_ISR;

Basic functions

p_cf_iomem[0x12] = 0xad;

Hardware

Fig. 4. Example describing the Hardware Abstraction Architecture for a packet transmission

architecture. In the case of WSN, even though most operating systems count with a subset of similar services from an application point of view, they are presented with a different API, thereby making portability harder. OS Abstraction layer. The definition of proper control mechanisms for the hardware platform into the software framework arise a number of portability issues. The OS abstraction layer [25] (OSAL) exposing an abstraction of the OS API is designed to address these issues and diminish the conflicts between different software and hardware platforms. In particular, it addresses the discrepancies among different OSs with respect to their functional API, hardware configuration mechanisms, resource management and handling of peripherals. Application builders are offered a common API which abstracts the underlying OS and hardware platform. Hence, portability among different platforms is mostly reduced to the re-implementation of the OSAL without introducing changes to the interface between software and hardware platforms (i.e. OSAL API). The OSAL API defines a subset of OS primitives which satisfies the basic application builder’s requirements but at the same time, remain simple to match most of the target OSs. Use of other native functionalities not covered by the OSAL is discouraged as it violates the principles of portability. The OSAL embraces the management of hardware configurations and access to specific set-points which represent a major hook to performance trade-offs. The procedure to design the OSAL covers the following steps: – Selection of primitives done with a concrete analysis of the typical application requirements on the WSN domain as well as further portability considerations.

138

A. Schoofs et al. Table 1. OSAL Profiles

Profile OSAL.0: Core

Description Basic system handling and initialization

OSAL.0.1: System System primitives OSAL.0.2: Task and scheduler Task initialization and scheduling primitives OSAL.0.3: Basic I/O I/O primitives

OSAL.1: Memory OSAL.2: Synchronization

Dynamic Memory management Task synchronization

OSAL.2.1: Mutexes OSAL.2.2: Message Queues OSAL.2.3: Signals

Mutexes Message Queues Inter-task signaling

OSAL.3: Time

Time handling primitives primitives

OSAL.3.1: Clock OSAL.3.2: Self-suspension OSAL.3.3: Timers

Internal clock handling Sleep and delay primitives Handling of timers

OSAL.4: Extended I/O OSAL.5: ELF-loader

Non-basic I/O primitives Dynamic code loader

– Definition of an API to expose the set of primitives. Our design is based on a POSIX-like1 API [26] [27] motivated by the aim of reducing the learningcurve as well as the preference of a neutral reference which does not reflex specific features from any platform. Hence, generality prevails over particular features, which is a reasonable price to pay for portability. – Implementation of the OSAL with a minimal footprint and execution overhead, which is achieved by means of advance compilation tools and techniques. General aspects on implementation. This approach focuses on WSN multi-task operating systems implemented in C/C++, which covers the majority of available OS in the field. The implementation of low-overhead wrappers for the native OS’ primitives is achieved with the support of different programming utilities: – Macros are very useful for renaming of functions, data types and parameter re-ordering. – Inline functions are similar to macros in what they can be used for, but require support from the compiler. They introduce less risk of inconsistencies but not always reduce the run-time overhead. – Function level linking, when supported by the compiler, reduces the size of executables by preventing the linkage of unused functions. Table 1 shows a list of profiles which subdivides the set of primitives present in the OSAL API. The categorization is done following a functional behavior 1

POSIX is a well structured standard which covers most of the features supported by any multi-task oriented OS. It is extensively documented and used for many different purposes. Note that one of the several POSIX profiles is defined to target embedded systems. However, it is too complex for the average operating system running on WSN and therefore its adoption to cover the OSAL API is not pursued.

A Framework for Time-Controlled and Portable WSN Applications

139

and based on a non-arbitrary analysis of applications in the WSN domain. This design allows the implementation of the OSAL in a progressive manner without loosing the integrity. Profiles are simple and contain dependent functionalities which need to be implemented together but can be discarded as a whole if such functionalities are not required.

4

Experimental Validation

Our software framework has been tested in multiple application scenarios with different requirements in parallel to its development e.g. to develop an home stroke rehabilitation application [6], an emotion sensing application [7], and a herd monitoring application [8]. This has allowed for a validation of the different modules and an extensive testing under various contexts, which generated some refinements of both the architecture and the implementation, leading to a stable and well-tested services. The following gives some details on the services operation and performance. 4.1

Temporal Control

Process execution example. An example of an application task calling the mcpsDataRequest MAC primitive to transmit a data packet is illustrated in the following to depict the execution of processes within the micro-kernel environment. Figure 5 shows the challenges and benefits of multi-tasking application tasks with the kernel task implementation of the 802.15.4 MAC. The Idle task is scheduled whenever no other tasks are ready to run. The respective mechanisms indicated by numbers are explained for the indicated three moments. 1. The FreeRTOS application task runs from the OS tick interrupt and initiates a packet transmission by calling the mcpsDataRequest MAC primitive. A packet transmission requires MAC functions (e.g. CSMA/CA) to be executed on 802.15.4 backoff slots. For that purpose, mcpsDataRequest initializes the MAC timer to generate ticks every 320µs and sets the FreeRTOS MAC task as ready-to-run at the highest priority to execute MAC functions on MAC tick interrupts. The MAC primitive, executed by the application task, also adds the mtxScheduleTransmission function into the low priority MAC function queue to be run by the FreeRTOS MAC task to initiate the transmission, and blocks until the end of the transmission. 2. When the MAC tick interrupt happens, the FRTOS MAC semaphore is released. On return from the interrupt, the FreeRTOS scheduler checks whether new tasks have been enabled. Because the FRTOS MAC semaphore has been released, the FreeRTOS MAC task is enabled and has the highest priority. It executes the mtxScheduleTransmission function, as shown on Figure 5. The mtxScheduleTransmission function is a state machine function, where each successive state is executed on MAC tick interrupts. The first state of mtxScheduleTransmission is executed, and the FreeRTOS MAC task is suspended until the next MAC tick. Because the application task is blocked, the

140

A. Schoofs et al.

Fig. 5. Process scheduling for a packet transmission within the OS-based implementation

FreeRTOS Idle task runs. At the next MAC tick, the next state of mtxScheduleTransmission is executed and so on. 3. Later, when the transmission process is done, the FreeRTOS MAC task is suspended, the MAC tick is stopped and the application task unblocked. It will remain in this state until the application calls a new MAC primitive to initiate a service. Synchronized distributed processing. Multiple tasks, some of which of periodic nature, are performed by sensor nodes in a network. It can be of interest to synchronize the execution of specific periodic tasks; synchronizing sensing tasks can improve data correlation, and can even be an unavoidable requirement when different signals have to be concurrently measured to deduce a global state. A synchronized periodic on/off switching of radio transceivers would also be beneficial for duty-cycling, by reducing the uncertainty period between the wake-up time of a transmitting node and a receiving node. The method we devised to implement distributed task synchronization is based on synchronizing timer interrupt occurrences at different nodes to that of a single master [24]. The synchronized interrupts are then used to launch the execution of periodic tasks in a synchronized manner across the network. The method builds on the time synchronization and micro-kernel framework services and achieves task synchronization with high accuracy by specifically targeting the timer (micro-kernel timer) used by the micro-kernel for starting task execution and switching between tasks. Our time synchronization implementation yielded an average absolute time synchronization error of 1 µs for nodes at one hop from the time master. This average error increases by less than 0.5 µs for every additional hop further from

A Framework for Time-Controlled and Portable WSN Applications

141

the time master in a multihop scenario. The tests we conducted in a single-hop network of 5 nodes showed that we achieved accurate task synchronization over nodes, with an average absolute offset of 5 µs between the start of execution of the same task at the master and a second node. 90% of the registered 1000 offset instances were found to be smaller than 10 µs [24]. 4.2

Memory Footprint

We measured the code size of the software framework on our CoolFlux DSP port, as shown in Table 2. The current version of the MAC software includes support for both beacon and non-beacon networks. Two buffers of length 128B for ongoing and incoming packets are used. Improvements can be realized to reduce the memory footprint. The first objective of the software implementation was to validate the concept, and less effort has been put into optimizing the coding. Table 2. Measurements of FreeRTOS port to CoolFlux DSP FreeRTOS code size (Words of 32 bits) FreeRTOS RAM usage (Words of 24 bits)

1757 words

160 words 23 words per task + stack 26 words per queue + data Hardware abstraction 9KB MAC software code size 11KB MAC software RAM usage 2.3KB

4.3

Micro-kernel Latency Overhead

The values presented in Table 3 compare the FreeRTOS context switch times on different microcontrollers, namely NXP CoolFlux DSP, TI MSP430 and CC2430’s 8051. A context switch is the process of storing and restoring the state (context) of the processor such that multiple processes can share a single processor. These timing measurements are very dependent on the clock frequency and the architecture of the module tested. They show that FreeRTOS (and more generally any micro-kernels) performance and overhead are very dependent on the platform. In order to quantify the overhead of the micro-kernel and other software services with respect to the useful processing, we measured on the NXP CoolFlux DSP the duration of a RF packet transmission, initiated by an application process, as shown in Table 4. The implementation and execution of the MAC state machine makes use of the FreeRTOS micro-kernel services and the hardware abstraction. During transmission, FreeRTOS context switches happen at each MAC tick interrupt, every 320µs, and at each FreeRTOS tick interrupt, every 1ms. We conclude that with approximately four ticks per ms, a FreeRTOS context switch of 17µs represents an overhead of about 7% on the available processing power.

142

A. Schoofs et al.

Table 3. FreeRTOS context switch duration for several architectures. (1) corresponds to a tick interrupt which does not wake-up any task, (2) is for a tick interrupt that wakes up one task and (3) refers to a task yield. Processor Tick (1) Tick (2) Yield (3) CoolFlux (20MHz) 12.9µs 16.6µs 9.6µs MSP430F449 (8MHz) 37µs 54.4µs 30.8µs 8051 (CC2430) (32MHz) 121µs 249µs 128µs

Table 4. Timing measurements on the CoolFlux DSP executing an 802.15.4 MAC within a FreeRTOS task (RF channel free) Sending 1 bytes Sending 100 bytes Receiving 1 bytes Receiving 100 bytes

4.4

2.6 9.4 1.9 8.4

(ms) (ms) (ms) (ms)

Portability

The implementation of the software framework has been ported in three months to a TelosB-like node (TI MSP430 + CC2420) by a master student. The MSP430 port in itself only involved compiler adaptations, timer settings and adaptation of the lower layers of the hardware abstraction. The FreeRTOS port for the MSP430 was already available [2]. We also ported part of the software framework on the CC2430’s 8051 microcontroller, but the latency related to FreeRTOS context switch (as shown in Table 3) introduced too much overhead to the system.

5

Conclusions

We proposed and evaluated a software framework dedicated to wireless sensor nodes. Both the architecture and services ease the development of applications, where power conservation with on-node processing is facilitated. We have provided software services, APIs, and contructs for temporal control over process execution and portability. The software framework has been ported to different microcontrollers, and the different modules have been validated by several applications. According to the requirements of application scenarios, a subset of requisite modules can be chosen, with the whole system providing a complete and efficient programming interface to the application developer.

Acknowledgments The authors wish to thanks Albert Rietema for his work on the software implementation of the hardware abstraction and the MAC, and Nils Preusker and Tao Xu for their efforts on porting software components to the 8051 and the MSP430.

A Framework for Time-Controlled and Portable WSN Applications

143

We would also like to thank Niek Lambert and Victor van Acht for their valuable feedback. This work is partially financed by the European Commission under the Framework 6 IST Project Wirelessly Accessible Sensor Populations (WASP) and is supported by Science Foundation Ireland under grant 07/CE/I1147.

References 1. Ouwerkerk, M., Pasveer, W.F., Engin, N.: SAND: a modular application development platform for miniature wireless sensors. In: Proc. of BSN 2006 International Workshop on Wearable and Implantable Body Sensor Networks, pp. 166–170 (2006) 2. FreeRTOSTM Homepage, Richard Barry, http://www.freertos.org/ 3. Texas Instruments CC2420 2.4 GHz IEEE 802.15.4 RF Transceiver Data Sheet, http://focus.ti.com/docs/prod/folders/print/cc2420.html 4. Maroti, M., Kusy, B., Simon, G., Ledeczi, A.: The Flooding Time Synchronization Protocol. In: Proceedings of the 2nd Int. Conf. On Embedded networked Sensor systems (SenSys) Baltimore (2004) 5. Willmann, R.D., Lanfermann, G., Saini, P., Timmermans, A., te Vrugt, J., Winter, S.: Home Stroke Rehabilitation for the Upper Limbs. In: Proc. of the 29th Annual International Conference of the IEEE EMBS Cite Internationale, Lyon, France (2007) 6. van Acht, V., Bongers, E., Lambert, N., Verberne, R.: Miniature Wireless Inertial Sensor for Measuring Human Motions. In: Proc. of the 29th Annual International Conference of the IEEE EMBS Cite Internationale, Lyon, France (2007) 7. Westerink, J.H.D.M., Ouwerkerk, M., Overbeek, T.J.M., Pasveer, W.F., de Ruyter, B. (eds.): Probing Experience - From Assessment of User Emotions and Behaviour to Development of Products. Philips Research Book Series, vol. 8 (2008) 8. Schoofs, A., Daymand, C., Sugar, R., Mueller, U., Lachenmann, A., Kamran, S.M., Gefflaut, A., Thiem, L., Schuster, M.: Testbed for IP-Based Herd Monitoring. In: The 9th ACM/IEEE International Conference on Information Processing in Sensor Networks, The 8th ACM/IEEE International Conference on Information Processing in Sensor Networks, IPSN (2009) 9. Adi Mallikarjuna, V.R., Phani Kumar, A.V.U., Janakiram, D., Ashok Kumar, G.: Operating Systems for Wireless Sensor Networks: A Survey, Technical Report (2007) 10. Levis, P., Madden, S., Polastre, J., Szewczyk, R., Whitehouse, K., Woo, A., Gay, D., Hill, J., Welsh, M., Brewer, E., Culler, D., Werner Weber, J.M.R., Aarts, E. (eds.): TinyOS: An Operating System for Sensor Networks, pp. 115–148. Springer, Heidelberg (2005) 11. McCartney, W.P., Sridhar, N.: Abstractions for Safe Concurrent Programming in Networked Embedded Systems. In: Proceedings of SenSys 2006, pp. 167–180 (2006) 12. Duffy, C., Roedig, U., Herbert, J., Sreenan, C.J.: Adding Preemption to TinyOS. In: Proceedings of the The Fourth Workshop on Embedded Networked Sensors (EmNets 2007), Cork, Ireland (2007) 13. Dunkels, A., Gronvall, B., Voigt, T.: Contiki - a Lightweight and Flexible Operating System for Tiny Networked Sensors. In: First IEEE Workshop on Embedded Networked Sensors (2004) 14. Chen, S.: Secure Real-time Services for Wireless Sensor Networks in Contiki (2007) 15. Klues, K., Hackmann, G., Chipara, O., Lu, C.: A Component-Based Architecture for Power-Efficient Media Access Control in Wireless Sensor Networks. In: ACM SenSys 2007, Sydney, Australia (2007)

144

A. Schoofs et al.

16. Handziski, V., Polastre, J., Hauer, J.-H., Sharp, C., Wolisz, A., Culler, D.: Flexible hardware abstraction for wireless sensor networks. In: Proceedings of the Second European Workshop on Wireless Sensor Networks, EWSN (2005) 17. Fernando Friedrich, L., Stankovic, J., Humphrey, M., Marley, M., Haskins, J.: A survey of configurable component-based operating systems for embedded applications. IEEE Micro 21(31), 54–68 (2001) 18. IEEE 802.15.4 Standard-2003, Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs), IEEE-SA Standards Board (2003) 19. Freescale Semiconductors, 802.15.4 MAC PHY Software Reference Manual Rev. 1.6, IEEE Micro 22(6) (2008), http://www.freescale.com/files/rf_if/doc/ref_manual/802154MPSRM.pdf 20. Roeven, H., Coninx, J., Ade, M.: CoolFlux DSP - The embedded ultra low power C-programmable DSP core. In: Proceedings of the Int. Signal Processing Conf. (GSPx), Santa Clara (2004) 21. Ganeriwal, S., Kumar, R., Srivastava, M.B.: Timing-sync Protocol for Sensor Networks. In: Proceedings of the 1st ACM Conference on Embedded Networked Sensor Systems (SenSys), Los Angeles, California (2003) 22. Elson, J., Girod, L., Estrin, D.: Fine-Grained Network Time Synchronization using Reference Broadcasts. In: Proceedings of the 5th Symposium on Operating Systems Design and Implementation, Boston, Massachusetts (2002) 23. Aoun, M., Schoofs, A., van der Stok, P.: Efficient Time Synchronization for Wireless Sensor Networks in an Industrial Setting. In: Proceedings of the 6th ACM Conference on Embedded Networked Sensor Systems, SenSys (2008) 24. Aoun, M., Catalano, J., van der Stok, P.: Distributed Task Synchronization in Wireless Sensor Networks. In: Proceedings of the 6th European Conference on Wireless Sensor Networks (2009) 25. Andree, M., et al.: Core Hardware Abstraction and Programming Model, Deliverable D3.2, IST-034963, WASP (2008) 26. The Open Group Base Specifications Issue 6 (cited: 2008-04-01). IEEE Std 1003.12001, The IEEE and The Open Group, http://www.unix.org/online.html 27. Aldea Rivas, M., Gonzalez Harbour, M.: Evaluation of New POSIX Real-Time Operating Systems Services for Small Embedded Platforms. In: Proceedings of the 15th Euromicro Conference on Real-Time Systems, ECRTS, Porto, Portugal (2003)

Embedded Web Server for the AVR Butterfly Enabling Immediate Access to Wireless Sensor Node Readings Konstantinos Samalekas, Evangelos Logaras, and Elias S. Manolakos National and Kapodistrian University of Athens, Department of Informatics and Telecommunications, Panepistimioupolis, Ilissia, 15784 Athens, Greece {k.samalekas,evlog,eliasm}@di.uoa.gr Abstract. The “AVR Butterfly” (BF) is not just a microcontroller, but rather an autonomous embedded system kit including several sensors. Our main objective was first to provide Internet connectivity to the BF and then to evaluate its further capabilities as a sensor network node. To this end, we equipped the BF with a TCP/IP stack and a Zigbee transceiver. As a case study, we constructed a node and a gateway based on the BF and formed a simple wireless sensor network (WSN). In order to enable remote users to access, on demand, sensor node readings through their web browsers, an HTML Server application was developed for the BF-gateway. We demonstrate that despite the scarcity of the available resources, if we enhance the BF with a popular Ethernet chip and the optimal TCP/IP stack for 8-bit microcontrollers, we can obtain a powerful, yet simple and inexpensive, monitoring device with Internet connectivity capabilities. Keywords: AVR Butterfly, TCP/IP, Web Server, Wireless Sensor Network, Microcontrollers, Zigbee.

1 Introduction In our days, we are experiencing the dawn of a new information revolution. We are heading towards major changes that will affect the coexistence of humans and machines. Internet users will become billions, but still a minority in comparison to networked devices [1]. With the fast progress of computer technology and the advancements in communication protocols, such as the IPv6, the assignment of a unique address to every “small device” is now becoming possible. As a consequence, cameras, traffic lights, parking meters and household appliances of the near future may perform measurements and transmit information about themselves and peers in their neighbourhood. The huge development of networked devices, sensors and actuators is forming a “Sensor Nation” [2] which expands rapidly, transforming the way that people gather information and interact with their environment. There are numerous applications of sensor networks, in a wide spectrum of fields such as in medicine for collecting patients’ data [3], in industry for controlling manufacturing [4] and in transportation for effectively managing traffic [5]. One of the most interesting and challenging applications of sensor networks is wide-area environmental monitoring. It is now common to use multiple sensors in order to monitor the environmental conditions in large geographical areas, e.g. the activity of volcanoes, the eruption N. Komninos (Ed.): SENSAPPEAL 2009, LNICST 29, pp. 145–158, 2010. © Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering 2010

146

K. Samalekas, E. Logaras, and E.S. Manolakos

of wildfires etc. With the use of wireless protocols and inexpensive or even disposable sensors, real-time environmental monitoring becomes feasible even for low budget research projects. In many situations, such as in wildlife habitat monitoring [6], it is undesirable that the researcher approaches the sensors physically. In these cases the installation and maintenance of information sinks that collect, compute and store data locally, might affect the flexibility and the energy requirements of the system. Thus, the network design must be accomplished in such a way that distributed data can be reached and evaluated from a remote location. The most interesting case, is to become able to utilize the largest and most widely available network, the Internet, to reach specific sensor measurements or reports from anywhere in the planet. The interest in distance monitoring and control is growing rapidly [7], bringing enhanced capabilities and efficiency. The development of microelectronics and embedded systems allows the creation of affordable, web-enabled boards and devices. The Internet as the means to access remote sensor nodes, not only provides flexibility to the monitoring system, but also facilitates the end-users needs, by replacing the physical or software control panels with their familiar web browser interface. It is always vital for sensor networks to have the ability to communicate with other infrastructure networks in order to propagate their data. Apart from the structural and functional similarities that we notice between sensor networks and traditional networks, we also encounter some important differences. First of all, the nodes in a sensor network are usually co-operating, hence appropriate synchronization and data management is required. The protocols are mainly low-power wireless and the usage of the communication channel is limited. Additionally, as low power consumption is crucial, there are restrictions for the nodes, often limiting their performance and forcing them to sleep for most of the time. On the other hand, in traditional networks we have end-to-end connections among independent hosts. Moreover, the links are usually wired and power restrictions are unnecessary. The demand for throughput here is high, while both bandwidth and retransmissions are relatively inexpensive. Modern tendencies and needs dictate that sensor networks should be integrated with the Internet. However, the best architectural solution for this integration is still debated. At the moment there is no perfect proposal, the scheme to be adopted though, must be efficient, reliable, extensible, and scalable. In general, we could classify the architectures that have been proposed in two categories: the Gateway approach and the Overlay approach [8]. The Gateway approach [9] is the “traditional” and simplest scheme to implement. The general idea is that a special device comes in between the sensor network and the Internet and performs the translation between the protocols of the two ends. Therefore, no additional workload is necessary for the nodes, since the (application-level) gateway is the only unit responsible for managing the communication overhead. However, due to the rapidly increasing number of sensors, this model may be heading towards a dead end [36]. As data loads rise inside the sensor networks, synchronization and real-time reporting becomes problematic. Apart from the drawback of high congestion, we should also consider that failure of the gateway entails isolation of the entire network. In addition, the final scheme is usually application dependent and not easily extensible1. 1

For the sake of completeness, we mention the Delay Tolerant Network (DTN) Gateway [5], which is a new, more extensible and performant type of Gateway-style architecture.

Embedded Web Server for the AVR Butterfly

147

The Overlay approach attempts to overcome the issues discussed above. To this end, two different schemes have been proposed: a sensor network overlay on top of the Internet [8] and an IP overlay network over a sensor network [10]. The first case is data-centric and refers to the creation of virtual nodes outside the WSN, forming virtual sensor networks. According to this idea, Internet hosts are equipped with a “Sensor Network Layer” on top of their TCP/IP stack, which enables them to act as virtual nodes of the WSN. In that way, the virtual nodes can understand the sensor messages even if they do not belong “physically” to the WSN. Other special hosts handle the encapsulation of WSN messages into IP packets in order to reach other IP targets. As a disadvantage of this method, we could mention the protocol overhead of the nodes implementing the additional WSN layer. The need of protocol translation is also a drawback, however it is not as expensive as it is inside a single gateway. The second case is address-centric. Each sensor-node is assigned a unique IP address, becoming equal with all other hosts and acting as a “First-class Citizen” of the Internet [10]. Thus, a remote host can send messages directly to a specific node equipped with a TCP/IP stack, without requiring any intermediate “translator”. This particular architecture is of great interest, since it gives independence to each node, provides multiple-path access to the sensor network and relieves the network of congestion problems and expensive synchronization. Furthermore, it gives the opportunity to combine already successful Internet protocols and web services for the node communication. However, serious challenges appear, mainly due to memory and power restrictions of the tiny sensor-nodes. In addition, web protocols and services are often very demanding and the routing of TCP/IP messages may cause high overheads because of the large message headers.. Since recently, 8-bit microcontrollers have been regarded as outdated. However, thanks to features such as their simple architecture and low cost, they were brought back to the fore. Today, devices based on such microcontrollers seem to be the perfect choice for low-power and low-cost applications in sensor networking. The main objective of the work reported here was to expand the applicability of one such device, the well known “AVR Butterfly” [11]. The “AVR Butterfly” (to be called BF for short) is a simple and affordable (approx. 15€€ ) embedded system demonstration kit provided by ATMEL, which is equipped with an 8-bit microcontroller and several sensors. In this paper we show how we have managed to make the BF embedded system kit Internet-aware. We extended considerably its capabilities by transforming it into a very simple monitoring device and an inexpensive wireless sensor network node. In particular, we installed a TCP/IP stack, added a wireless transceiver and then designed a BF-based inexpensive system prototype which allows Internet users to have immediate access to remote sensor readings via their web browser. While creating a “mote” around the BF, some difficulties arose mainly due to the microcontroller’s limited memory and other hardware limitations. After providing Internet connectivity to the BF, in order to evaluate its performance, we constructed a gateway and a Zigbee WSN node. The entities of this architecture, i.e. the Gateway device and the nodes in the Zigbee WSN, are both simple embedded systems built around a BF device. In our implementation we used one of the most efficient TCP/IP stacks for 8-bit and 16-bit microcontrollers: the uIP [12], the popular Ethernet chip: RTL-8019AS [13] and the Zigbee enabled radio transceiver: XBee [14]. The application we have

148

K. Samalekas, E. Logaras, and E.S. Manolakos

developed on top of the Gateway’s TCP/IP stack, is a basic web server, able to serve static and dynamic pages and to communicate with the WSN nodes. We should clarify that we do not claim that the AVR Butterfly can form the basis for a more suitable WSN node or gateway than other solutions. However, the metamorphosis of the popular BF kit to an inexpensive WSN mote (with total cost below 40 euros) is by itself a novel contribution and has not been demonstrated before. Furthermore, the applications presented here provide a list of ideas built around the webenabled AVR Butterfly. The model system designed and developed in this work is inexpensive, highly configurable (it is easy to add more sensors if needed), easy to construct and combines some very popular off-the-shelf components. After this introductory section, the rest of the paper is organized as follows. Next we describe in brief the main components of the basic scheme and then we refer to some implementation details and results. In the third section, we present the web server application and the user interface. Afterwards, we describe how the baseline system can be extended to implement a Zigbee WSN and present distance control applications. Finally, we conclude by summarizing the paper and point to interesting future work.

2 Basic Scheme As mentioned previously, the BF is an inexpensive evaluation kit which demonstrates the major features and capabilities of ATMEL’s AVR microcontrollers. The main onboard module is the ATmega169 which is an AVR 8-bit microcontroller, running at 8 MHz, with 1 KByte SRAM, 16 KBytes Flash, 512 Bytes EEPROM memory. It also includes a liquid crystal display screen (LCD), a serial port (RS-232), a real-time clock (RTC), temperature, light and voltage sensors, a miniature joystick and a piezoelectric speaker. Additionally, there is support for the Joint Test Action Group (JTAG) debugging interface, the Universal Serial Interface (USI) protocol and insystem Programming (ISP). The advantages of using this platform in applications are its low cost (approx. 15€€ ) and low power consumption, the wide collection of peripherals and the ease of reprogramming due to the embedded Bootloader and the RS-232 converter. Because of the previous properties, the BF has been used as the core unit in several interesting projects such as an MP3 player device [15] and an educational robot called FlutterBot [16]. The RTL-8019AS is a very popular 10Base-T Ethernet controller chip provided by Realtek [13]. It supports Plug and Play (PnP) and full-duplex operation (i.e., sends and receives packets simultaneously), it is NE2000 compatible and has 16 KBytes embedded SRAM for packet buffering. There are many boards equipped with this specific Ethernet controller, which range from advanced commercial solutions, to very simple breakout boards. The Packet Whacker is a simple and inexpensive (approx. 20€€ ) RTL-8019AS breakout board provided by EDTP [17], which contains a 20 MHz crystal, an RJ-45 port and indicating LEDs. This solution gives a convenient way to provide Ethernet connectivity to any microcontroller. Possible alternatives could be other similar boards such as the ETM121 from EMBIN [18] or any old RTL8019-based network card [19], with the appropriate interface to convert its ISA port to a standard input/output (I/O) port.

Embedded Web Server for the AVR Butterfly

149

The uIP is an open-source TCP/IP stack, created by Adam Dunkels at the Swedish Institute of Computer Science (SICS) [20] and further developed by a world-wide community. Its implementation is general, aiming at 8-bit and 16-bit microcontrollers and its code is organized as a software library, providing functions for the communication between the TCP/IP stack and the lower layers. The strong points of the uIP are its small code size and low RAM memory requirements. Moreover, it is fully RFC standards compliant, supporting protocols such as ARP, SLIP, IP, UDP, ICMP, and TCP. It also provides basic mechanisms, such as flow control, packet reconstruction, retransmission time calculation and the ability to communicate with equivalent peers. Apart from its great performance, the uIP has very well structured code, extensive documentation, a wide spectrum of applications and ports for many different devices. The current project uses the uIP-AVR-0.60 port of uIP, which was developed by Lois Beaudoin [21]. In addition, a web server application was placed on top of the TCP/IP stack, tailored to suit the BF. All software was compiled with the 7.16A version of the Imagecraft ICC-AVR compiler [22]. 2.1 Related Work and uIP-AVR The idea of combining the parts described above, to construct an Ethernet-enabled AVR microcontroller running a web server application is not new. Similar work has been done in: the AVRnet [23], the Embedded AVR WebServer [24], the AVR WebServer Project [19] and the Embedded ATMEL HTTP Server [25]. However, these projects utilize microcontrollers with higher memory capacities (ATmega32, ATmega128), their software is custom-made and the construction of the device is rather advanced. Some other complete solutions like the Ethernut [26] and the WS128 Amber Micro Web Server [27], are commercial products with a much higher price (approx. 100€€ ), which do not allow access to their source code. Apart from the work of Louis Beaudoin, one project of special interest is the Tuxgraphics AVR Web Server [28], which embeds a web server application in the ATmega88, a microcontroller with very scarce resources (8 KBytes FLASH, 1 KByte RAM). As for the uIP-AVR port of uIP, it contains a device driver implementation for the communication of the TCP/IP stack with the Ethernet controller, a checksum algorithm and a 32-bit addition function. The parts of the code which need modification to match the specific AVR device, include the hardware timer (used to generate periodic uIP calls) and the Ethernet device interface. Other projects which have used the uIPAVR, are based on the following microcontrollers: ATmega161 [21], ATmega163 [29], ATmega128 [21] and AT90S8535 [21]. 2.2 Structure and Difficulties The Internet-user client makes a data request from a remote host using a web browser. The request message travels through the appropriate router to our Ethernet controller in the form of an IP packet. Then, the Ethernet controller collaborates with the TCP/IP stack and the microcontroller in order to extract the data from the IP packet. In the final step, the application (i.e., web server) processes the request, generates the proper data and forms an IP packet that goes back to the end-user following the opposite direction (Figure 1).

150

K. Samalekas, E. Logaras, and E.S. Manolakos

Fig. 1. The general structure of the baseline system

During the implementation of this simple model system, the main difficulties arose due to the low resources of the BF. Additionally, some device dependent modifications were necessary in the uIP-AVR code and special treatment was needed for the compilation of the application code with the ICC-AVR. There were also some hardware issues concerning the availability of free I/O pins and the power supply of the system. Finally, special care was given to the design of the user web-interface. For the connection between the Ethernet controller and the AVR-BF we used the I/O ports interface approach. In particular, the necessary connections were two buses: one for data and one for addressing and three control signals: Read, Write and Reset. In total, we needed two 8-bit I/O ports for the buses and three I/O pins for the control signals. Unfortunately, most of the I/O ports of AVR-BF were already allocated to the LCD screen and the other peripherals, so not enough pins were actually free for our purposes. However, we could use the I/O pins anyway, changing their previous usage. Hence, we decided to use PortB and PortD, disabling the function of ISP, the rightmost part of the LCD and part of the joystick. In the same way, we managed to obtain three more pins by abandoning the USI feature. As for the device dependent parts of the code, we had to define the appropriate registers for the embedded timer (i.e. Timer0) which makes periodic checks to the uIP and the Ethernet device interface. Among the device dependent parts we must also mention the embedded clock speed and the overflow interrupts which control the hardware timer. Finally, we included the fix of Mattias Rosén for the ARP implementation, that allows packets from different subnets to be received [21].

3 Web Server Application For the development of the web server application we utilized the sample HTTP server of the uIP-0.60 as the baseline, and then made modifications and simplifications. Some sort of file-system is necessary for a web server in order to be functional. In our case, the HTML pages served by the application are stored in the FLASH memory of the microcontroller converted in lists of hexadecimal numbers. In that

Embedded Web Server for the AVR Butterfly

151

way, the static parts of the pages are stored in a file along with an index that maintains the structure of the files. The role of the compiler is important for the organization of the contents into the RAM and FLASH memory. In compilers such as the AVR-GCC, the “const” keyword can be used in two ways: to declare a constant or to give the instruction to store something in the FLASH memory. However, this could lead to less comprehensible code or misuse of memory instructions. In order to overcome these problems, the 7th version of ICC-AVR compiler introduces the “__flash” keyword, which indicates that a variable, a list or a structure will be stored in the FLASH memory. Therefore, the code of our application was modified according to the philosophy of the ICC-AVR compiler. In order to get access to sensor data of the BF platform, we must define the source of the appropriate peripheral and then read the value from the equivalent analog-todigital converter (ADC) channel. The light sensor measurement is in fact the voltage of the light sensor, which decreases as the light intensity increases. As for the temperature sensor, we use a table of constants to convert the voltage of the sensor to temperature in degrees Celsius. The web pages that contain sensor data should be updated dynamically before being served to the remote user. In the sample code of the uIP-0.60, there is an implementation of a simplified scripting language with a CGIstyle operation. Another interesting feature would be to support server side includes (SSI), according to which we could use the syntax of HTML comments to import dynamic data [30]. However, neither of these approaches was appropriate for our platform because of memory limitations. According to our custom solution, a dynamic page is marked with a special character in the URL of the page. Then, the code of the web page is split into two pieces: the one preceding and the other following the dynamic entry part. The web page is constructed dynamically and then is divided in packets which are being sent to the recipient the one after the other. According to the general structure of the code shown in Figure 2, the application first listens to a port. If there is a connection, and an active user makes a new request, then the requested web page is accessed from the file-system. In the case that the page

Fig. 2. The top level structure of the web server application code

152

K. Samalekas, E. Logaras, and E.S. Manolakos

has dynamic content, sensor data is generated and embedded into the page. Subsequently, successive packets and acknowledgements are being sent and received until all data is delivered to the remote client. Finally the connection is closed.

4 Zigbee Gateway Application Zigbee is a wireless networking protocol built on top of the IEEE 802.15.4 standard for wireless personal area networks (WPANs). It was developed to meet the needs of low-cost, low-power WSNs and defines the Network, Application and Security layers, while the lower MAC and physical layers are defined by the IEEE 802.15.4. Some key features of this standard are: reliability, security, low power consumption, high number of supported nodes and inexpensive devices. It operates in the unlicensed 2.4 GHz, 915 MHz and 868 MHz ISM bands and enables interoperability between different products. The Zigbee enabled devices have long battery life and low complexity. Furthermore, the WSN becomes self-maintained, reliable and easily expandable thanks to the mesh networking support. 4.1 Baseline System Extension Additional Hardware. At this point we will present an extension to the basic scheme, in which the Ethernet enabled device described in section 3, takes the role of a Gateway in a Zigbee WSN. The BF is again used to build the nodes of this WSN, equipped with an XBee RF module. The XBee is an RF-device provided by Digi, that implements the Zigbee protocol [14]. Its power consumption is very low and the outdoor line-of-sight of its embedded antenna can reach a range of 90 meters. The XBee is a great solution for the networking of small devices, especially because of its small size and low cost (approx. 15€€ ). As part of another project, a number of special Zigbee WSN nodes were built around BF (XBee-BF) by the Embedded Systems Group at the University of Athens (Fig. 3a). These nodes are autonomous boards which provide interconnection between the BF and the XBee. In addition, the connection with a PC becomes easy, thanks to the serial RS-232 port and the onboard jumpers which set the mode of operation. An important requirement for a monitoring device is to be power-line independent. Therefore we equipped the BF with a solar cell provided by Olimex, as shown in Figure 3b. This device is intended to be connected with the MSP430 family of Texas Instruments microcontrollers, however it can be arranged to supply power to the BF as well. Ten hours of exposure to sunlight are enough to fully recharge the onboard AA-type battery. Whenever there is no access to sunlight, the BF can use the stored energy for its operation. Software. In order to combine all the components described above in our final application, we needed to manage the communication of the Gateway with a wireless node. At first, the Gateway was connected with an XBee via UART. Then, we configured the XBee firmware, so that it broadcasts all messages being received. Afterwards, we set up the XBee of the XBee-BF node to communicate with the Gateway, provided the appropriate code for the remote BF and modified the web server application. Finally, we added the code for the distant switch control application.

Embedded Web Server for the AVR Butterfly

153

Fig. 3. The developed a) XBee-BF node and b) BF-Gateway node with solar panel

The Gateway was equipped with UART communication functions. When there is a request for remote measurements, the microcontroller sends a “GET” message serially to the XBee, which is then broadcasted. The message reaches the remote XBee-BF board over the Zigbee wireless network and then is forwarded from the XBee to the BF. The BF’s microcontroller recognizes the message, collects the proper sensor measurements and creates a string of the form: “R{Temperature}{Light}”, which is sent back to the Gateway as a reply. The measurements are then extracted from the message and imported to a dynamic web page.

Fig. 4. The Zigbee WSN application structure: Gateway device (BF, uIP-AVR, Packet Whacker, solar cell), XBee-BF board, dual-relay board

154

K. Samalekas, E. Logaras, and E.S. Manolakos

We have also developed a relay-based control application. A relay is a switch that can start or stop the flow of electric current in a circuit, depending on the logic level of a signal that controls its input. It can be considered as a simple actuator which can control a high power output with a relatively small power input. Therefore, by connecting a BF to a relay, we can control a switch just by setting an output pin to logic “1”. The idea is to allow users to control devices connected to the relay via their web browser. In our implementation, we used a board equipped with two 12V relays provided by Anykits [31]. Every input signal above 2V can trigger the relay and control an external circuit up to 230V. For instance, we could control an air conditioning system or a fire alarm when the temperature rises above a threshold, or manage the lights and shutters of a house according to the indoor light intensity. Two free I/O pins were necessary to connect the dual-relay board to the BF in order to control two devices independently. However, we already used all the free pins except for the JTAG port. In order to use the JTAG pins (i.e., PF4 – PF7) for I/O, we had to disable the JTAG feature which is supported by default. This can be done by writing a function [32] which instructs the appropriate registers to bypass the JTAG in every clock circle. 4.2 Final System Architecture In the final configuration, we combine all the software and hardware components described above, forming a wireless network of BF nodes (Figure 4). The web interface presented in Figure 5, was designed to be user friendly and functional, with low requirements in memory. During the system testing, the mean Gateway-to-node range was measured up to 9m. The number of users that can be

Fig. 5. The sitemap of the web interface

Embedded Web Server for the AVR Butterfly

155

connected to the server simultaneously is restricted due to the limited RAM of the BF. This number depends on the configuration of uIP and the size of the static pages. The key advantage of a web-enabled monitoring and control system is that it can be accessed by any platform equipped with a simple browser. Therefore, the interface was also tested in a mobile phone browser simulator [33]. Another example that could be applied in our monitoring device is a simple wind meter. First we attach a wind propeller in the centre of a simple speedometer [34], then we connect the output of this device to an input pin of the BF. The speedometer is composed of an opto-interrupter and a plastic wheel with a small cut on its edge. The wheel is placed horizontally on a pin, in a way that is able to turn on its centre axe. The opto-interrupter is a component with two poles: an infrared emitter and a shielded infrared detector. By emitting a beam of infrared light from one pole to the other, the sensor can detect when an object passes between the poles, breaking the beam. The system is arranged as shown in the Figure 6, so that the opto-interrupter can detect the cut in every turn of the spinning wheel. In the BF side we can estimate the wind-speed in Hertz, by counting the interrupts driven from the signals of the optointerrupter every one second.

Fig. 6. Wind Meter application

Even though we already used a number of I/O pins related to the LCD screen, it could be possible to utilize its remaining part by writing a new display driver. We could then use text, such as the name of the file being served to the user, the temperature/light readings, or just “ON/OFF” when device’s power is switched on or off respectively. Moreover, we could reallocate the I/O ports, in order to free and utilize the embedded Universal Serial Interface (USI), to connect additional components. USI is a serial interface protocol, which can provide external connections, operating as Serial Peripheral Interface (SPI) or as Inter-Integrated Circuit (I2C) controller. For instance, we could develop an e-Health application, by attaching devices able to monitor blood pressure or levels of glucose.

156

K. Samalekas, E. Logaras, and E.S. Manolakos

5 Conclusions and Future Work The first contribution in the current study was to provide Internet connectivity to the AVR Butterfly, by installing the uIP-AVR TCP/IP stack. In order to evaluate its further capabilities, as a case study, we have presented an affordable and simple solution for monitoring physical conditions and controlling actuators via the Internet. All units were inexpensive and easy to design, built around the BF. Our final scheme supports wireless node reports, extending the functionality of our example application. We have shown, how BF-based sensor systems could be used for house automation or outdoor area-monitoring, despite their memory and power limitations. Combined with the appropriate components, the web-enabled BF played both the roles of a Zigbee WSN node and a WSN Gateway, providing immediate communication with external users. This simple system also provides an excellent educational platform, where students can learn in practice to develop Embedded-C applications and use different network protocols, getting valuable hands-on experience. As mentioned before, in order to welcome the “Internet of things” era, we ought to overcome major hurdles and specify which is the most suitable architecture for integrating the WSNs with the Internet. Until recently, researchers have been expressing serious doubts about IP’s aptness for low power sensor networks. The main concern was that IP seemed very “heavy” for such applications. Nevertheless, the emergence of light TCP/IP stacks such as the uIP, increased the supporters of this perspective. October 2008 may be the date that all the doubts started dissolving, as Cisco, Atmel, and SICS announced the uIPv6, an extension to uIP which combines IPv6 with the 6LowPan protocol [35]. With all these elements in place, TCP/IP may become a viable solution, even for sensor nodes with very low resources. Nowadays, sensors turn into independent producers of data, receive control, become web-enabled and serve data on demand. This is certainly more than a trend, it is the way of the future.

References 1. International Telecommunication Union: ITU Internet Reports 2005: The Internet of Things. The World Summit on the Information Society (WSIS), ITU, Tunis (2005) 2. Kumagai, J., Cherry, S.: Sensors & Sensibility. IEEE Spectrum 41(7), 22–26 (2004) 3. Park, S., Jayaraman, S.: On Innovation, Quality of Life and Technology of BodyNets. In: Proceedings of the ICST 3rd International Conference on Body Area Networks, ICST, Tempe, Arizona (2008) 4. Shen, X., Wang, Z., Sun, Y.: Wireless Sensor Networks for Industrial Applications. In: Fifth World Congress on Intelligent Control and Automation (WCICA), vol. 4, pp. 3636–3640. IEEE, Hangzhou (2004) 5. Coleri, S., Cheung, S.Y., Varaiya, P.: Sensor Networks for Monitoring Traffic. In: FortySecond Annual Allerton Conference on Communication, Control, and Computing, UrbanaChampaign (2004) (invited paper) 6. Hac, A.: Wireless Sensor Network Design, pp. 349–367. John Wiley & Sons, Manoa (2003) 7. Römer, K., Mattern, F.: The Design Space of Wireless Sensor Networks. IEEE Wireless Communications 11(6), 54–61 (2004)

Embedded Web Server for the AVR Butterfly

157

8. Zhang, M., Pack, S., Cho, K., Chang, D., Choi, Y., Kwon, T.: An Extensible Internetworking Architecture (EIA) for Wireless Sensor Networks and Internet. In: Asia-Pacific Network Operations and Management Symposium (APNOMS), Poster Sessions, Busan, S. Korea (2006) 9. Karl, H., Willig, A.: Protocols and Architectures for Wireless Sensor Networks, pp. 78–81. John Wiley & Sons, Chichester (2005) 10. Dunkels, A., Alonso, J., Voigt, T., Ritter, H., Schiller, J.: Connecting Wireless Sensornets with TCP/IP Networks. In: Langendoerfer, P., Liu, M., Matta, I., Tsaoussidis, V. (eds.) WWIC 2004. LNCS, vol. 2957, pp. 143–152. Springer, Heidelberg (2004) 11. ATMEL, AVR Butterfly, http://www.atmel.com/dyn/Products/tools_card.asp?tool_id=3146 12. Swedish Institute of Computer Science, Dunkels, A.: uIP, http://www.sics.se/~adam/uip/index.php 13. Realtek, RTL8019AS SA Full-Duplex Ethernet Controller with Plug and Play Function, http://www.realtek.com.tw/products/productsView.aspx?Langid= 1&PFid=15&Level=4&Conn=3&ProdID=22 14. Digi, XBee 802.15.4 OEM RF Module, http://www.digi.com/products/wireless/point-multipoint/ xbee-series1-module.jsp 15. Brokentoaster, AVR Butterfly MP3, http://www.brokentoaster.com/butterflymp3/index.html 16. Flutterbot, The FlutterBot an Educational Robot Kit, http://www.flutterbot.com 17. EDTP, Packet Whacker, http://www.edtp.com/whacker_page.htm 18. EMBIN, ETM121 Ethernet Connectivity, http://www.embin.com/products_etm121.html 19. Radig, U.: AVR web server project, http://www.ulrichradig.de/home/index.php/avr/webserver 20. Swedish Institute of Computer Science, Networked Embedded Systems Group, http://www.sics.se/nes 21. Louis Beaudoin, uIP-AVR, http://www.laskater.com/projects/uipAVR.htm 22. Imagecraft, ICCVAVR, http://www.imagecraft.com/devtools_AVR.html 23. AVR portal, AVRnet, http://www.avrportal.com/?lang=en&page=avrnet 24. Pfeifer, T.: Embedded AVR Webserver, http://thomaspfeifer.net 25. Tzeming Tan, J., Land, B.: Embedded ATMEL HTTP Server. Master’s Thesis, School of Electrical and Computer Engineering, Cornell University (2004) 26. MicroController Pros Corporation, Ethernut, http://microcontrollershop.com/product_info.php?products_ id=358 27. SOC Robotics, WS128 Amber Micro Web Server, http://www.soc-machines.com/product/Amber_Specs/ Amber_Processor.html 28. Socher, G.: Tuxgraphics AVR web server, http://www.tuxgraphics.org/electronics/200611/ embedded-webserver.shtml 29. Ben Zijlstra, Atmel163 With Ethernet, http://members.home.nl/bzijlstra/software/communication/ Communication.htm 30. Apache, Server Side Includes, http://httpd.apache.org/docs/1.3/howto/ssi.html

158

K. Samalekas, E. Logaras, and E.S. Manolakos

31. AnyKits, Dual Channel Relay Board, http://www.anykits.com/catalog/product_info.php? products_id=310 32. Thomas, M.: AVR Butterfly JTAG Pins For General I/O, http://www.siwawi.arubi.uni-kl.de/avr_projects/ BF_JTAG_disable.html 33. Opera Software, Opera Mini Simulator, http://www.operamini.com/demo/ 34. Pardue, J.: C Programming for Microcontrollers Featuring AVR Butterfly. Smileymicros, 144–151 (2005) 35. Durvy, M., Abeillé, J., Wetterwald, P., O’Flynn, C., Leverett, B., Gnoske, E., Vidales, M., Mulligan, G., Tsiftes, N., Finne, N., Dunkels, A.: Making Sensor Networks IPV6 ready. In: Proceedings of the Sixth ACM Conference on Networked Embedded Sensor Systems (ACM SenSys). Poster Sessions. ACM, Raleigh (2008) 36. Ali, M., Langendoen, K.: A Case for Peer-to-Peer Network Overlays in Sensor Networks. In: The Sixth International Conference on Information Processing in Sensor Networks (IPSN 2007), Cambridge, MA, USA (2007)

Low-Power Radio Communication in Industrial Outdoor Deployments: The Impact of Weather Conditions and ATEX-Compliance Carlo Alberto Boano1, James Brown2 , Zhitao He1 , Utz Roedig2 , and Thiemo Voigt1 1

2

Swedish Institute of Computer Science, Kista, Sweden {cboano,zhitao,thiemo}@sics.se Lancaster University Computing Deparment, Lancaster, UK {j.brown,u.roedig}@lancaster.ac.uk

Abstract. Industry recognizes wireless sensor networks as one of the next major technical and economical shifts in automation and control systems. Industrial applications need performance assurances of wireless communication, which is hard to attain given the variability of the environment where such applications are deployed. In this paper, we quantify the impact of environmental conditions, namely temperature, fog, and rain on wireless communication links. We further investigate the influence of industrial casing on communication, evaluating an ATEX enclosure intended for use in potentially explosive atmospheres. Knowledge of the potential impact of environmental conditions and special casings provides an important input to robust communication design during deployment planning. Keywords: Industrial outdoor deployment, wireless sensor networks, temperature impact, weather conditions, RSSI, LQI, ATEX compliance.

1

Introduction

Several industry sectors are seeing wireless sensor networks as a promising technology to bring operational renovations. A wide range of potential applications, such as plant automation, process monitoring and control, preventive maintenance, safety in hazardous environments, and radiation detection, can benefit from the technology. Wireless sensor networks increase efficiency in automation and process control by enabling quicker decisions, improving safety and reliability, enhancing flexibility and visibility, while decreasing maintenance and installation costs. Industrial applications, on the other hand, have strict requirements for delay and reliability. The required performance assurance is hard to attain without knowledge about the complicated variability of the environment where the sensors are deployed. Unlike military applications where nodes are placed in a dense and random manner, industrial plants allow carefully planned sensor deployments to facilitate the provision of performance assurances. For example, N. Komninos (Ed.): SENSAPPEAL 2009, LNICST 29, pp. 159–176, 2010. c Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering 2010 

160

C.A. Boano et al.

modern industrial plants such as refineries may host more than ten thousands sensors. In these plants, extensive redundancy is impossible due to the sheer numbers of sensors and the associated costs. When deploying outdoor industrial sensor networks, persistent connectivity between sensors must be maintained over a range of environmental conditions. This is a major challenge, in light of the known impacts of temperature and weather conditions on sensor nodes and their low-power radios. Bannister et al. have observed a strong reduction in signal strength during the hottest time of the day [1], while others have attributed transmission range and connectivity changes to fog and rain [2,3,4]. Another outstanding issue that potentially impacts radio communication are the specific implementation requirements. For example, equipment for products intended for use in potentially explosive atmospheres must be ATEX certified [5]. While it would be possible to obtain ATEX certifications for sensor nodes, a simpler way is to put regular non-certified sensor nodes into ATEX-compliant enclosures. However, the potential impact of such enclosures on wireless communication has never been quantified to date. In this paper, we analyze the impact of environmental conditions and certification requirements on wireless connectivity in industrial outdoor deployments. We also quantify these effects, in order to enable solutions that can give performance assurances to radio communication. The contributions of our work are three-folded. Firstly, we experimentally confirm the findings by Bannister et al. [1] showing that increasing temperature negatively affects the communication between nodes. Further, we analyze the behavior of nodes below 0◦ C. Secondly, we assess the impact of weather effects such as fog, rain, and snow on low-power radio communication. Thirdly, we measure if ATEX compliant enclosures affect the communication between sensor nodes. The paper proceeds as follows. Section 2 provides a general description of the related work. We investigate and quantify the impact of temperature on radio communication in Section 3. Thereafter we discuss the influence of weather phenomena in Section 4, providing a comparison between the impacts of temperature, weather and radio interference. We quantify the impact of ATEX compliant enclosures on the communication between sensor nodes in Section 5. We conclude the paper in Section 6, along with a summary of the results and suggestions for future work.

2

Related Work

Several researchers have shown that outdoor sensor networks are affected by weather conditions and temperature. The results of Anastasi et al. suggest that weather effects, specifically fog and rain, may have a severe impact on the transmission range of sensor nodes [2]. They report a high difference in the maximum range between two MICA2 nodes: 70 meters with clear and dry weather conditions versus 25 meters with foggy and rainy conditions. The authors do not

Low-Power Radio Communication in Industrial Outdoor Deployments

161

present any details about the amount of rain, humidity, and temperature. In their experiments, they provide a relationship between the Packet Reception Rate (PRR) and the distance between nodes, without any allusion on the signal strength or link quality. Sun et al. [3] report a loss of connectivity in their outdoor experiments with rainfalls from 0.4 to 1.4 mm. They conclude that rain and fog cause the difference in link quality. On the other hand, they report a systematic change in signal strength every 24 hours which might indicate that the temperature plays a nonnegligible role. Capsuto et al. [4] analyze the effects of snow and ice on sensor networks using an outdoor deployment on a flat roof. They report 30 dB fades in their static deployment due to freezing rain and freezing fog. In contrast to the findings above, Thelen et al. [6] have noticed that in a potato field deployment, radio waves propagate better during the night and during rain, i.e. in weather conditions with high humidity. They believe that humidity impacts the reflection coefficient of the top of the potato canopy. Also many radio vendors state that impact of rain on communication in the 2.4 GHz band should be insignificant [7,8,9]. Bannister et al. have shown that high temperatures negatively affect communication between sensor nodes [1]. In their deployment in the Sonoran Desert of the southwestern United States, the reduction of the signal strength was largest during the hottest time of the day. Given these discrepancies, we set up multiple experiments in order to quantify and compare the impacts of atmospheric events such as rain, snow, fog, and temperature. Our experimental results indicate that the changes in temperature can indeed affect radio communication much more than light rainfall or humidity. In addition to the experiments by Bannister et al., we measure the impact of low temperatures on radio communication, providing experimental results for two platforms at different radio frequencies. Similar to their experiments, we focus on the Received radio Signal Strength Indicator (RSSI), but we also measure and analyze the Link Quality Indicator (LQI) and noise floor. Most sensor networks for industrial control and automation applications must comply with the ATEX 95 equipment directive 94/9/EC for equipment and protective systems intended for use in potentially explosive atmospheres. For example, the RUNES1 technology roadmap for industrial control and automation highlights that all new networked embedded components should comply with the ATEX directive [5]. To the best of our knowledge, however, there are no studies that assess if compliance with this particular standard has an impact on wireless sensor networks performance. Our measurements aim to close this knowledge gap.

3

Impact of Temperature in Outdoor Deployments

Sensor nodes communicate using low power, short range radio transceivers, such as the 2.4 GHz Chipcon CC2420 [10] on the Tmote Sky platform [11] and 1

RUNES was an European Commission funded project (contract IST-004536).

162

C.A. Boano et al.

the Chipcon 868 MHz CC1020 [12] on the Scatterweb Modular Sensor Board (MSB430) [13,14]. As other modern single-chip transceivers, both radio chips offer indicators to measure the link or signal quality, such as the Received Signal Strength Indicator (RSSI) and the Link Quality Indicator (LQI). Researchers have investigated the relationship between these indicators and the Packet Reception Rate (PRR) [15,16,17], showing that the indicators represent a good estimation of packet delivery. Hardware components for outdoor deployments are usually designed for an industrial grade operating temperature range of -40◦ C to +85◦ C, to ensure uninterrupted operation under various environmental conditions. Temperature changes, however, may cause crystal frequency to shift, thermal noise level of the transceiver to increase, and amplifiers to saturate [18], resulting in potential performance degradation of the radio device. In order to quantify the impact of temperature on sensor nodes communication, we carry out different experiments with two different platforms. We want to assess the effects of both high and low temperatures on wireless communication since long-running outdoor deployments may be exposed to large temperature variations. We further investigate the behavior of several hardware indicators, such as Received Signal Strength Indicator (RSSI), Link Quality Indicator (LQI), i.e. the correlation value of the first eight symbols of the received PHY header (CCI), and noise floor. We also verify that platforms using different radio frequencies show the same behavior. 3.1

Experimental Setup

We deploy three Tmote Sky [11] nodes in a wheat field in Govone, Italy during the end of December. We place the nodes 1,5 meters above ground, at a distance close to the border of their communication range. Nodes are supported by wood pieces fastened to the ground, to withstand wind blasts. The surface of the wheat field is flat, with no discrepancies. In our experiments, we set the transmission power to approximately -5 dBm. Our nodes run the Contiki operating system [19]. Our deployment lasts seven consecutive days. The sink node triggers a sender node to send 256 consecutive packets with a size of eight bytes on a specific channel. The sink node stores RSSI, LQI and noise floor readings for each received packet. It also stores environmental information such as temperature, humidity, sunlight and battery voltage of both nodes. In order to record the data without intrusion, the information is forwarded to a third node that acts as a data logger. We measure temperature and humidity using the on-board Sensirion SHT11 sensor [20]. To protect them from rain we keep the sensor nodes in plastic boxes We also carry out indoor experiments, in which we create a difference in temperature of more than 70o C on both Tmote Sky platforms and MSB430 nodes, by moving the nodes from a cold environment (refrigerator) to a warm environment and vice versa, while logging the data about the received packets. The position of the motes remain fixed, and there is no human interaction because

Temp [C]

50 30 10 -10

Temperature [C]

LQI [CCI]

110 105 100 95

LQI [CCI]

RSSI [dB]

Low-Power Radio Communication in Industrial Outdoor Deployments

-35 -40 -45 -50

RSSI [dB]

22/12/0008 12:00

23/12/0008 00:00

23/12/0008 24/12/0008 12:00 00:00 Time of the day [hh:mm]

163

24/12/0008 12:00

Fig. 1. Changes of RSSI and LQI of received packets follow the pattern of temperature changes: the higher the temperature, the worse the radio signal strength and the link quality. Data is retrieved in a 48-hour outdoor deployment in a wheat field in Govone, Italy.

the data is collected at a third node far away from the communicating ones. Temperature reading increases slowly, and should be accurate since the SHT11 sensor lies only few millimeters away from the radio chip. We also vary the temperature using a cooling spray that drops the temperature quickly to around -35oC. We obtain the same results which confirms the validity of our method. We set the transmission power to approximately -25 dBm in the Tmote Sky and to -20 dBm in the MSB430. We use the same software setup as in the previous experiment. 3.2

Experimental Results

Our outdoor and indoor experiments show the high impact of temperature on wireless connectivity between sensors, and confirm the experiments by Bannister et al. [1]. Our data show that temperature strongly affects the wireless communication on sensor networks platforms; in particular, the large difference in temperature between daytime and nighttime may affect the signal strength by several dBs. Figure 1 shows the data retrieved by the sink in the wheat field during 48 hours of sunny weather. Sensors experience large temperature shifts between day and night, amplified by the greenhouse effect caused by the plastic boxes covering the motes when the sun is shining. Figure 1 shows that the RSSI changes follow the same pattern as temperature: when the temperature increases, the signal strength decreases.

C.A. Boano et al.

-78 Signal Strength (RSSI) [dB]

Signal Strength (RSSI) [dB]

-62

-64

-66

107

RSSI LQI

RSSI -60 -80

106.5

-82 106 -84 105.5 -86 105

-88

Link Quality (LQI) [CCI]

164

-68 -90 -10

0

10

20

30

40

104.5 0

50

10

20

30

40

50

Temperature [Celsius]

Temperature [Celsius]

a) MSB430 platform

b) Tmote Sky platform

Fig. 2. Our indoor experiments confirm the results of our outdoor experiments. Both LQI and RSSI decrease as temperature increases. This applies not only to the Tmote Sky, but also to the MSB430 platform that uses a radio chip operating in a different frequency band.

Our experimental results also show that LQI is affected by the temperature to a similar degree. Figure 1 shows that the higher the temperature, the worse the link quality. In the experiments, the motes are placed at close to the border of their transmission range. We carried out additional experiments to show that the significance of the impact on LQI decreases with distance. The temperature impact is considerable on weak links, whereas at short distances where LQI indicates a near-perfect link, the temperature effect is negligible. The results of our indoor experiments depicted in Figure 2 confirm the results of the outdoor experiments. They reveal a similar behavior of the MSB430 platform that uses a radio chip operating in a different frequency band. The figure shows that the radio signal strength of received packets (RSSI) decreases monotonically as temperature increases. In summary, temperature variations affect communication between both MSB430 nodes and Tmote Sky nodes. -96

RSSI floor readings

-98

RSSI floor readings [dB]

RSSI floor readings [dB]

-96

-100

-102

-104

-106 -10

0

10

20

30

Temperature [Celsius]

a) MSB430 platform

40

50

RSSI floor readings

-97

-98

-99

-100 -10

0

10

20

30

40

50

Temperature [Celsius]

b) Tmote Sky platform

Fig. 3. Noise floor readings detected in our experiments carried out in different platforms at different temperatures

Low-Power Radio Communication in Industrial Outdoor Deployments

165

Figure 2b further shows that also the Link Quality Indicator (LQI) is affected by the temperature. Since the LQI is not available in the CC1020 radio chip, it is not possible to measure it on the MSB430 platform. The indoor experiments with the Tmote Sky nodes, however, show how LQI and RSSI follow the same pattern of temperature, confirming the results of our outdoor experiments. Figure 3 shows that, in addition to LQI and RSSI, noise floor readings are affected by temperature. As a direct consequence of the RSSI alteration, also the noise floor decreases as long as temperature increases. This is important since the noise floor reading is often used to evaluate the interference and noise level in the communication [21,22]. Figure 3 shows the impact of temperature on the noise floor readings on both the Tmote Sky and the MSB430 platforms.

4

Impact of Humidity, Fog, Snow and Rainfall

Not only temperature, but also other weather effects may impact the performance of outdoor deployments. As shown in Section 2 some researchers claim a strong impact of rain and other atmospherical events on radio signal strength. Others including radio manufacturers, however, indicate that the effects of rain on radio waves propagation are negligible at 2,4 GHz frequencies [6,7,8,9]. The presence of rain, fog, and snow may be strictly connected to a temperature change. Since the temperature variation may cause a loss in radio signal as we illustrated previously, it is important to discern the pure effect of temperature and atmospheric precipitations at the Line of Sight (LoS). Looking at the available data in published experiments, we can see that temperature changes may have influenced several deployments [3,4], since there is a regular RSSI variation every 24 hours, even when there is no rain or fog. During our outdoor deployment in the wheat field in Govone illustrated in Section 3.2, we report some light rainfall (around 1 mm/hour), snow and fog. Figure 4 shows the RSSI including the instants with fog, rain and snow. The radio communication is almost not affected by these atmospheric events, and no significant thermal variations are revealed in that period of time. In contrast, the impact of the temperature on LQI and RSSI is very high. Therefore, we design new experiments to distinguish the impact of temperature and weather on radio communication, trying to discern the temperature effect from the pure rainfall . 4.1

Experimental Setup

In order to to distinguish between weather and temperature impact on wireless communication, we design new experiments. To avoid larger variations in temperature we place the nodes in two opposite office buildings in Kista, Sweden. The distance between the buildings is few dozens meters, and there are no obstacles. We deploy the motes at the fourth floor of the buildings. In this way, only rain and other environmental issues but not temperature affect the wireless communication. To easily detect weather impacts, we choose the transmission power so that the nodes can just communicate.

Temp [C]

50 30 10 -10

LQI [CCI]

C.A. Boano et al.

110 105 100 95

FOG

RAIN SNOW

RSSI [dB]

166

-35 -40 -45 FOG -50 22/12/0008 12:00

RSSI [dB]

Temp [C] FOG

RAIN SNOW

LQI [CCI]

RAIN SNOW 23/12/0008 24/12/0008 25/12/0008 26/12/0008 12:00 12:00 12:00 06:00 Time of the day [hh:mm]

Fig. 4. Experimental data of the effects of temperature, fog, rain and snow on the radio signal strength. Data is retrieved in a wheat field during December in Govone (CN), Italy.

We take data about the amount of rain from a weather station situated 400 m away from the deployment area [23]. Data about rainfall, wind speed, temperature, humidity, solar light, snow and atmospheric pressure are available. In order to check the presence of fog, we use the images available from one of the webcams situated close to the deployment area. Figure 5 shows webcam images pointed towards the deployment area. Our deployment also provides the possibility to compare the effects of microwaves and electromagnetic disturbances with temperature and weather effects. The buildings are offices, and thus during daytime, radio interference is higher than during the night. This implies that during working days, in office hours the signal strength may be varying more than usual. 4.2

Experimental Results

Between January and March 2009, we experienced several foggy days and many light and heavy rainfalls in Kista. We run the experimental setup explained in the previous section for 60 consecutive days. We combine the data from the sensor nodes and the information about the weather, isolating the instants of time with rain and fog. Figure 6 illustrates the RSSI variation when there is fog in the deployment area. Although it is difficult to quantify the amount of fog, we consider respectively thin and thick fog the situations shown in the two latter pictures in Figure 5. Neither thin nor thick fog have a significant impact on the radio signal strength.

Low-Power Radio Communication in Industrial Outdoor Deployments

167

RSSI [dB]

Fig. 5. Images captured from the webcam in order to check the presence of fog. From the bottom images it is possible to see both when rain and fog appeared in the deployed area. The figure appears under explicit permission of the owner [23].

-41 -43

RSSI [dB]

22/01 19:00

22/01 23:00

23/01 03:00

-31

23/01 07:00

Thin fog Thick fog

-38 -45 25/01 00:00

RSSI [dB]

Thin fog

-39

25/01 16:00

26/01 08:00

-75

Thin fog Thick fog

-80 -85 06/02 18:00

27/01 00:00

07/02 09:00

08/02 00:00

08/02 15:00

Time of the day [hh:mm] Fig. 6. Radio signal strength variation during foggy days in January and February in Kista, Sweden. The radio signal is neither affected by thin nor by thick fog.

Figures 7 and 8 illustrate the RSSI variation in rainy days during January, February and March 2009 respectively. Rainfall is computed as the amount of rain fallen in the last 30 minutes. Although the rain intensity never reaches the

168

C.A. Boano et al.

Rainfall [mm]

3

Rainfall [mm]

2 1

0 24/01 00:00

26/01 12:00 Time of the day [hh:mm]

RSSI

-84

RSSI [dB]

29/01 00:00

-88 -92 24/01 00:00

26/01 12:00 Time of the day [hh:mm]

29/01 00:00

Fig. 7. Radio signal strength during rainy days in January in Kista, Sweden. The grey area highlights the instants in which we report a significant impact of rainfall on packet delivery. The RSSI variation is otherwised caused mainly by the electronic disturbances introduced by the office environment.

Rainfall [mm]

1 0.5 0 05/02 00:00

06/02 12:00 Time of the day [hh:mm]

-76

Rainfall [mm]

1.5

0 05/03 00:00

08/02 00:00

08/03 00:00

11/03 00:00

Time of the day [hh:mm] -70

RSSI RSSI [dB]

RSSI [dB]

3 Rainfall [mm]

Rainfall [mm]

1.5

-80

RSSI

-85

-84 05/02 00:00

06/02 12:00 Time of the day [hh:mm]

08/02 00:00

a) Rainy days in February

-95 05/03 00:00

08/03 00:00

11/03 00:00

Time of the day [hh:mm]

b) Rainy days in March

Fig. 8. Radio signal strength during rainy days in February and March in Kista, Sweden. The RSSI variation is caused mainly by the electronic disturbances introduced by the office environment rather than by the rainfall.

possible values obtainable in tropical areas, the results indicate clearly that the impact of rain is less than the one caused by changes in temperature. In particular, when the rainfall amount is less than 1 mm/h, the effect of rain is almost negligible, while it increases with higher rain intensities. The only significant

Low-Power Radio Communication in Industrial Outdoor Deployments

169

impact of rain we report is a significant packet loss rate and interruption of connectivity highlighted by a grey area in Figure 7. In this period, the rainfall reaches values much higher than the average intensity of 2 mm/h. In all other cases shown in Figures 7 and 8, the RSSI variation is caused mainly by the noise generated by the office environment in which nodes are deployed rather than by weather effects. Together with the results from our deployment in the wheat field, we can understand how the impact of temperature and electromagnetic disturbances is much higher than the one caused by light rainfall or fog. However, really heavy rainfalls may affect the communication between nodes, especially if deployed at the border of their communication range.

5

ATEX Compliance

Many Industries have very specific requirements regarding the deployment of equipment within production environments. For example, in coal mines, chemical plants and oil refineries there are significant risks of fire or explosion due to flammable gas by-products released during production. Thus, wireless sensor nodes deployed in such an industrial context must adhere to specific standards. Within the European Union, regulations regarding the use of equipment in explosive atmospheres are known as the so called ATEX directives. For an explosion to occur there is a requirement for a combustible material, oxygen and an ignition source. As it is very difficult to prevent the presence of combustible material and oxygen in large processing plants, explosion prevention concentrates on the ignition source. For example, it is almost impossible to guarantee that no oil spills occur in an oil refinery, where on the contrary it is much easier to secure electric systems to prevent sparks. It is possible to obtain ATEX certification for a wireless sensor node. However, this is a costly and time consuming process which needs to be repeated whenever the sensor node is modified, for example, by adding new sensor arrays. An alternative to obtaining ATEX certification for the sensor node is to obtain it for the enclosure that will house the node. Although certification of an enclosure is easier than that of a sensor node, this can also be avoided through the use of one of the many off the shelf ATEX-compliant enclosures that exist. Using an ATEX certified enclosure in this case means a standard sensor node can be used and alterations can be applied without re-running through the certification cycle. Every element of a sensor node that is to be placed outside the ATEX certified box needs to be itself ATEX certified. For example, if the antenna of the node is placed outside the box it needs a certification on its own and has to be fitted with ATEX certified connectors to the main box. Hence it is highly desirable to keep all components such as antenna inside the box. As other work has shown, placing nodes with antennas inside an enclosure can substantially affect the communication patterns. The effects that such encloses have can be reduce through design and the selection of material used in

170

C.A. Boano et al.

their construction. For example in a car-park application [24] a box was specially designed that minimizes the impact on communication. For the described industrial scenarios it is not possible to change the material of the ATEX box without potentially losing its protective properties. Before such enclosures can be used for the above industrial applications, an investigation of how these might impact the communication capabilities of a node must take place. 5.1

Experimental Setup

We investigated the effects that ATEX casing have on node communications by conducting three experiments. The first experiment quantifies the effects that ATEX casing has on two communicating nodes at various distances and orientations. The second experiment was determines the potential communication distance of nodes with ATEX casings. The third experiment is conducted to discover the effects that the internal enclosure temperature has on communications. All experiments were carried out on Tmote Sky [11] nodes, which were placed into two separate ATEX compliant enclosures as shown in Figure 9. One node is used as a sender and the other as a receiver. Experiment 1. The first experiment is carried out in-doors within a large empty meeting room with no obstacles or visible interference. Both nodes are placed one meter above the ground with a distance of D. The distance D between sender and receiver is one of the variables in the experiments and is set at 5m, 10m and 20m. For each communication test at distance D the sender is used to transmit blocks of i = 256 packets over a four second window. The sender’s

Fig. 9. Zone 2 ATEX compliant case

Low-Power Radio Communication in Industrial Outdoor Deployments

171

transmission power is set to −5dBm. For each communication test at distance D, four receiver orientations α were used (α = 0◦ , α = 90◦ , α = 180◦ , α = 270◦). The orientation of the transmitter is not changed. At the starting point α = 0◦ the sender and receiver antenna point towards each other. For each setting 10 transmission blocks are sent to the receiver which forwarded statistics to a third node connected to a laptop. For each setting two experiments are conducted: one whilst the two nodes are cased in the ATEX compliant enclosures and one where the nodes are not encased. The average RSSI R in dependence of the communication distance D and orientation α is determined. The results for this experiment are show in Figure 10. -40

-40

Case Open

-50

-60

-60

-70

-70

-80

-80

-90

-90

-90

-100

-100

-100

0

90 180 Orientation

a) D = 5m

270

0

90 180 Orientation

b) D = 10m

Case Open

-50 RSSI [dB]

RSSI [dB]

-40

Case Open

-50

270

-60 -70 -80

0

90 180 Orientation

270

c) D = 20m

Fig. 10. Effects of ATEX compliant casing on RSSI in with different configurations

Experiment 2. The second experiment is carried out in a open field. The days prior to the experiment, it was raining, thus the chosen field is extremely wet. The field is not completely plane, a ditch of about 1m is present (The impact of such small topology imperfections is discussed later with the results). The distance D is increased between each test run in 10m steps from D = 10m to D = 170m inclusive. At each distance, D, i = 100 packets with inter-arrival time of 100ms are transmitted from the sender to receiver. The average RSSI R in dependence of the communication distance D is determined. For this test, sender and receiver are placed in ATEX casings with orientation α = 0◦ . The results of this experiment are shown in Figure 11. Experiment 3. The third experiment is carried out indoors within an office building environment. The distance is fixed at D = 5m. Three nodes are used similarly to experiment one, one transmitter, one receiver and one node to collect statistics. To fully ascertain the effects of temperature three different test settings are investigated in which the transmitter temperature Ts and/or the receiver temperature Tr is altered. In the first test the temperature of the sender is fixed at room temperature of Ts = 25◦ C and temperature of the receiver is slowly lowered from T r = 45◦ C to T r = −15◦ C. In the second test the temperature of

172

C.A. Boano et al.

the receiver is fixed at Tr = 25◦ C and the temperature of the sender is slowly lowered from Ts = 45◦ C to Ts = 0◦ C. Finally during the last test the temperature of both the receiver and sender is raised and then slowly cooled to a temperature of Tr = Ts = 0◦ C. The average RSSI R in dependence of the transmitter temperature Ts and the receiver temperature Tr is determined. The results of this experiment are shown in Figure 12 to Figure 14. 5.2

Results

Experiment 1. The measured RSSI at the receiver is found to be affected by both node orientation and ATEX Casing. Figure 10 shows at the 5m distance point, the measurements taken whilst the devices are within the case is significantly better than those taken from the devices outside of the case. This changes as the devices moved further apart, where at the 10m point there is a negligible difference between devices within the case to those outside of the case. At 20m the devices outside the case out performed those within the case. Looking at the effects of orientation, no trends could be established to how orientation affects the measured RSSI at the receiver. Experiment 2. Figure 11 shows that with increasing distance the RSSI value drops. However, from a distance of approximately 70m to 80m meters, the RSSI is stable at a low value. This can be attributed to the fact that the RSSI is only recorded when a packet is received at the receiver, therefore when packet is lost, which occurs as the distance is increased and signal degrades, less RSSI sample points are measured. At the 90m point packet loss does increase, as obstacles in the field are encounter particularly the dip in RSSI at around 100m can be attributed to the fact that a small water filled ditch was present at this distance. Obviously such small obstacles have a significant impact on the communication patterns. The maximum communication range during the experiment with ATEX casings is found to be approximately 140m. From this distance on significant losses are recorded. However, an abnormality occurred at 160m where an isolated patch with good communication conditions is found.

With Case

RSSI [dB]

-60 -70 -80 -90 -100 20

40

60

80

100

120

140

160

Distance [m]

Fig. 11. Effects of ATEX compliant casing on RSSI over distance

Temperature [C]

Low-Power Radio Communication in Industrial Outdoor Deployments

45 30

Temperature sender [ C] Temperature receiver [ C]

15 0 -15 19/03 22:22

19/03 22:43 Time of the day [hh:mm]

-55 RSSI [dB]

173

19/03 23:05

RSSI [dB]

-60

-65 19/03 22:22

19/03 22:43

19/03 23:05

Time of the day [hh:mm]

Temperature [C]

Fig. 12. Effects of the temperature on communication when the ATEX cases of only the sender is cooled 45

Temperature sender [ C] Temperature receiver [ C]

30 15 0 19/03 23:35

19/03 23:49

20/03 00:04

Time of the day [hh:mm] RSSI [dB]

-65

RSSI [dB]

-70

-75 19/03 23:35

19/03 23:49 Time of the day [hh:mm]

20/03 00:04

Fig. 13. Effects of the temperature on communication when the ATEX cases of only the receiver is cooled

Experiment 3. A high temperature of either the receiver or transmitter has a worsening effect on the recorded RSSI. When the receiver is cooled from 45◦ C to approximately −10◦ C, RSSI rises by approximately 5dB. Likewise when the temperature of the transmitting device is cooled from 45◦ C to 0◦ C, RSSI rises again by 5dB. It is also found that when the temperature of both the sender and receiver is cooled, there effects are summed to 10dB. 5.3

Findings

During our experimentation with ATEX compliant casing we found that the effects on communication were negligible at distances of approximately 10m.

C.A. Boano et al.

Temperature [C]

174

60

Temperature sender [ C] Temperature receiver [ C]

40 20 0 20/03 00:33

20/03 00:47

20/03 01:02

Time of the day [hh:mm] RSSI [dB]

-70

RSSI [dB]

-75 -80 -85 20/03 00:33

20/03 00:47 Time of the day [hh:mm]

20/03 01:02

Fig. 14. Effects of the temperature on communication when the ATEX cases of both receiver and sender are cooled

As this point is passed, RSSI falls as distance between receiver and transmitter increases. Conversely the opposite occurs as the communicating nodes are brought closer together. Furthermore it was found that node configuration has a major role in communication, simply turning the node in a single plane in some cases can reduce RSSI by 10dB much more than the measured effects of ATEX enclosures. A typical maximum range of nodes communication from inside separate ATEX enclosures is measured to be approximately 140m before substantial signal degradation. As we show in this paper this value is very easily influenced by temperature or orientation so is here purely to depict a possible communication range in one environment. Similarly to the findings in the early sections of this paper, it is discovered that raising the temperature of the node within an ATEX enclosure has a negative effect on communication. Not only is the temperature of the receiver important but also that of the sender.

6

Summary and Conclusions

Several industrial deployments require performance assurances. Outdoor deployments are exposed to varying environmental conditions, in particular rain, fog, and temperature, which might have an impact on the wireless communication between the deployed sensor nodes. Furthermore, in potentially explosive environments, it is necessary to enclose the sensor nodes in ATEX compliant enclosures. In order to evaluate the impact of the environmental conditions and ATEX-compliant cases, we perform multiple experiments with real hardware. We show that the temperature has the largest impact on communication. The impact of fog and rain is not severe until the rain is heavy, i.e. more than 2-

Low-Power Radio Communication in Industrial Outdoor Deployments

175

3 mm/hour. The impact of ATEX-compliant enclosures on communication is small. Our results suggest that when deploying an outdoor industrial sensor network, the current temperature needs to be taken into account. The distance between the nodes should not be close to the maximum transmission range, in particular when the deployment is done during the colder time of the year. Our results also suggest that through a careful planning and deployment, that takes into account the environmental conditions and the potential impact on temperature and rain, it is possible to provide reliable wireless sensor communication.

Acknowledgments The research leading to these results has received part-funding from the European Community’s Seventh Framework Programme (FP7/2007-2013) under grant agreement number 224282. Part of this work has been performed within the SICS Center for Networked Systems funded by VINNOVA, SSF, KKS, ABB, Ericsson, Saab Systems, TeliaSonera and T2Data and the SSF-funded Promos project. This work has been partially supported by CONET, the Cooperating Objects Network of Excellence, funded by the European Commission under FP7 with contract number FP7-2007-2-224053.

References 1. Bannister, K., Giorgetti, G., Gupta, S.K.S.: Wireless sensor networking for hot applications: Effects of temperature on signal strength, data collection and localization. In: Proceedings of the fifth Workshop on Embedded Networked Sensors (HotEmNets 2008), Charlottesville, Virginia, USA (June 2008) 2. Anastasi, G., Falchi, A., Passarella, A., Conti, M., Gregori, E.: Performance measurements of motes sensor networks. In: Proceedings of the 7th ACM international symposium on Modeling, analysis and simulation of wireless and mobile systems (MSWiM 2004), Venice, Italy (October 2004) 3. Sun, J., Oliver, R.C.: An experimental evaluation of temporal characteristics of communication links in outdoor sensor networks. In: Proceedings of the second Workshop on Real-World Wireless Sensor Networks (REALWSN 2006), Uppsala, Sweden (June 2006) 4. Capsuto, B., Frolik, J.: Demo abstract: A system to monitor signal fade due to weather phenomena for outdoor sensor systems. In: Proceedings of the Fifth International Conference on Information Processing in Sensor Networks (IPSN 2006), Nashville, TN, USA (April 2006) 5. ATEX Guidelines. Web page, http://ec.europa.eu/enterprise/atex/guide/ (Visited 2009-02-14) 6. Thelen, J., Goense, D., Langendoen, K.: Radio wave propagation in potato fields. In: Proceedings of the 1st workshop on wireless network measurement, Riva del Garda, Italy (April 2005) 7. CWNP certifications. Rain fade margin, http://www.cwnp.com (Visited 2009-0214)

176

C.A. Boano et al.

8. Covad Communications Group. Wireless networking backgrounder (March 2007), http://www.covadwireless.com/documents/wirelessWhitepaper.pdf 9. AFAR Communications Inc. 900 mhz versus 2.4 ghz in long distance links, http://www.afar.net/tutorials/900-mhz-versus-2.4-ghz/ (Visited 2009-0214) 10. Chipcon, A.S.: CC2420 datasheet - 2.4 GHz IEEE 802.15.4 / ZigBee-Ready RF Transceiver (Rev. B) (March 2007) 11. Moteiv Corporation. Tmote Sky - Datasheet, edition 1.04 edn. (November 2006) 12. Chipcon, A.S.: CC1020 datasheet - Low-Power RF Transceiver for Narrowband Systems (Rev. B) (July 2008) 13. ScatterWeb GmbH. MSB: modular sensor board, version 1.0 edn. (Visited 200902-14) 14. Baar, M., K¨ oppe, E., Liers, A., Schiller, J.: Poster abstract: The scatterweb msb430 platform for wireless sensor networks. In: Contiki Workshop 2007, Kista, Stockholm, Sweden (March 2007) 15. Srinivasan, K., Levis, P.: Rssi is under appreciated. In: Proceedings of the Third Workshop on Embedded Networked Sensors (EmNets 2006), Cambridge, MA, USA (May 2006) 16. Srinivasan, K., Dutta, P., Tavakoli, A., Levis, P.: Understanding the causes of packet delivery success and failure in dense wireless sensor networks. In: Proceedings of the 4th ACM Conference on Embedded Networked Sensor Systems (SenSys 2006), Boulder, Colorado, USA, November 2006, pp. 419–420 (2006) 17. Holland, M.M., Aures, R.G., Heinzelman, W.B.: Experimental investigation of radio performance in wireless sensor networks. In: Proceedings of the 2nd IEEE Workshop on Wireless Mesh Networks (WiMesh 2006), Reston, Virginia, USA (September 2006) 18. Chipcon A.S.: CC2400 datasheet - 2.4 GHz Low-Power RF Transceiver (Rev. 1.5) (March 2006), http://focus.ti.com/lit/ds/symlink/cc2400.pdf (Last visited January 2009) 19. Dunkels, A., Gr¨ onvall, B., Voigt, T.: Contiki - a lightweight and flexible operating system for tiny networked sensors. In: Workshop on Embedded Networked Sensors, Tampa, Florida, USA (November 2004) 20. Sensirion, A.: SHT1x Humidity and Temperature Sensor datasheet, version 2.04 edn. (May 2005) 21. Lal, D., Manjeshwar, A., Herrmann, F., Uysal-Biyikoglu, E., Keshavarzian, A.: Measurement and characterization of link quality metrics in energy constrained wireless sensor networks. In: IEEE Global Telecommunications Conference (GLOBECOM 2003), December 2003, pp. 446–452 (2003) 22. Senel, M., Chintalapudi, K., Lal, D., Keshavarzian, A., Coyle, E.J.: A kalman filter based link quality estimation scheme for wireless sensor networks. In: IEEE Global Telecommunications Conference (GLOBECOM 2007), November 2007, pp. 875– 880 (2007) 23. Fogelberg, B.: Kistav¨ adret, http://soloregn.se/ (Visited 2009-02-14) 24. Benson, J.P., O’Donovan, T., O’Sullivan, P., Roedig, U., Sreenan, C.J., Barton, J., Murphy, A., O’Flynn, B.: Car-park management using wireless sensor networks. In: LCN, pp. 588–595 (2006)

TinySPOTComm: Facilitating Communication over IEEE 802.15.4 between Sun SPOTs and TinyOS-Based Motes Daniel van den Akker1 , Kurt Smolderen1,2 , Peter De Cleyn1 , Bart Braem1 , and Chris Blondia1 1

PATS, Dept. of Mathematics and Computer Science, University of Antwerp – IBBT, Middelheimlaan 1, B-2020, Antwerp, Belgium {Daniel.VanDenAkker,Kurt.Smolderen,Peter.DeCleyn, Bart.Braem,Chris.Blondia}@ua.ac.be http://www.pats.ua.ac.be/ 2 Dept. of Industrial Sciences and Technology, Karel de Grote-Hogeschool, Salesianenlaan 30, B-2660, Hoboken, Belgium

Abstract. The increasing popularity of sensor network has spawned a wide range of platforms and frameworks for sensor network development. While in theory nodes based on different frameworks should provide radio stack compatibility, in practice this is rarely the case. We explore this problem by providing a case study and introduce TinySPOTComm, a customized radio stack for the Sun SPOT platform which allows for radio communication between IEEE 802.15.4 based TinyOS motes and Sun SPOTs. The TinySPOTComm radio stack remains fully compatible with the Sun SPOT radio stack and its network performance is only marginally affected in comparison to the default Sun SPOT radio stack. Performance tests have shown good results when communicating between TinyOS motes and Sun SPOTs. The round trip time, when measured between a Sun SPOT and a TinyOS mote, is affected by no more than 15%, in comparison to the RTT between two TinyOS motes. In the same scenario an increase in throughput of more than 50% has been measured. Keywords: Sun SPOT, TinyOS, 802.15.4, network.

1

compatibility, sensor

Introduction

Over the years sensor networks have become increasingly popular, not only as a research topic, but also for real-life applications. Because of this, many frameworks for sensor network development now exist, each with its own programming language preference and supported hardware platforms. Unfortunately, communication between nodes using different sensor network frameworks is, despite compatibility at the hardware level, generally not possible. N. Komninos (Ed.): SENSAPPEAL 2009, LNICST 29, pp. 177–194, 2010. c Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering 2010 

178

D. van den Akker et al.

This paper attempts to provide further insight into this problem by means of a case study. More specifically, we focus on the radio stack compatibility between two distinct types of sensor nodes: TinyOS-motes [1] and Sun SPOTs [2]. These two platforms are, amongst others, further discussed in section 2. An introduction to the IEEE 802.15.4 [12] and LowPAN [10] protocols, which are both commonly used in sensor networks, is provided in section 3. The radio stacks of these two platforms are further discussed in section 4. In section 5 we discuss the effect of the changes proposed in section 4 on the wireless networking performance, and we conclude our paper in section 6.

2

Current Frameworks for Sensor Network Development

In this section several sensor network development frameworks are discussed. 2.1

TinyOS

TinyOS has been widely accepted as a well supported, highly usable and efficient framework for sensor network development. It is, as the name suggests, a ‘Tiny’ Operating System designed for energy-constrained devices and for sensor nodes in particular. Sensor nodes running TinyOS are usually referred to as TinyOS-motes. TinyOS is written in nesC, a component-based version of the C programming language. A nesC application consists of multiple components. Each component is expected to both provide and use interfaces. The provided interfaces allow other components to interact with the component, while used interfaces define the functionality required by it. Unlike interfaces in other languages, nesC-interfaces are bidirectional since they specify both commands and events. Commands are functions implemented by the component providing the interface and may be invoked by other components requiring the interface. Events work in the opposite direction. They are implemented by requiring components and may be invoked from the component providing the interface. Commands may therefore be regarded as the equivalent of methods while events resemble call-back functions. Based on this principle, TinyOS uses an event-driven asynchronous approach to concurrency. Unlike regular programming-languages, most operations are executed asynchronously. When performing operations, such as sending packets, a command is issued to initiate the operation. This command immediately returns and does not block until the operation is complete. Instead an event is used to signal completion. Furthermore, TinyOS does not support multithreading, since it would require a separate stack for each thread and introduce a significant thread-swapping overhead. Instead, so called Tasks may be submitted which are then sequentially executed by the only available thread. As a result, TinyOS applications have a very small memory-footprint and require very little computational power.

Facilitating Communication between Sun SPOTs and TinyOS-Based Motes

179

Although TinyOS allows for the development of efficient, modular applications and is supported on numerous hardware platforms, it has a few major drawbacks. One of the largest issues is that due to the structure of nesC and the used concurrency model, writing TinyOS applications is a complex task. Furthermore, debugging these applications is equally challenging. It either requires applications to be simulated, which prevents low-level device interactions to be tested, or requires specialized tools and hardware, such as a JTAG controller, to directly interface with the mote’s microcontroller. Moreover, it is only possible to debug the C code generated by the nesC compiler. As a result of these restrictions, TinyOS may only reach a specific target audience. A second problem of TinyOS is that, since nesC compiles both application-specific and general-purpose TinyOS-originated code into a single binary, it is not possible to update the application code without replacing the entire binary. As a result it is generally not possible to reprogram TinyOS-motes once they have been deployed. Levis et al. [3] addresses this problem by providing Mat´e, a byte code interpreter implemented on top of TinyOS. Mat´e is based on the observation that many sensor network applications rely on a common set of components and services. Mat´e therefore specifies a specialized instruction set containing not only regular instructions such as arithmetic operations but also more elaborate instructions such as the ‘send’ instruction which is used to transmit data. Furthermore the Mat´e-instruction set provides eight ‘user’ instructions which allow Mat´e to be extended with domain-specific functionality. Application code is broken into capsules, each containing up to 24 instructions, which are then transmitted to the individual motes and scheduled for execution. As a result, sensor network applications may be altered in an efficient way, even after the sensor network has been deployed. While both Mat´e and TinyOS allow the development of efficient sensor network applications, they both require a profound knowledge about low-level (nes)C or even assembler programming. As a result both exhibit a very steep learning curve and therefore only appeal to a specific audience. 2.2

Java Based Frameworks

To enable the use of sensor networks by a broader community, various Java virtual machines for sensor nodes have been proposed. NanoVM [4], for instance, is an open-source Java VM designed to run on the AVR ATmega8 CPU. While it can run using only 8KB of program flash and 1KB of RAM, it only supports a very limited subset of the Java language specification and the JDK. AmbiCompVM [5] an extension to NanoVM does support most of the Java specification. In order to limit the memory footprint and CPU usage, compiled class-files are transcoded for the target platform and then statically linked into a single binary. VM* [6] takes this principle even further, and synthesizes a specialized VM for each application. Since these platforms are not open-source, their benefit for researching sensor networks is limited.

180

2.3

D. van den Akker et al.

Squawk and Sun SPOTs

In April 2007, Sun introduced their own platform for sensor network development. Specialized sensor nodes, called Sun SPOTs [2] (Small Programmable Object Technology), are equipped with the Squawk VM, a Java virtual machine that was originally developed for the next generation smart cards [7] and has been refined for sensor network usage. While Squawk shares many characteristics with other embedded device JVMs, such as a specialized compressed byte code format, the open source Sun SPOT platform provides many features that greatly facilitate the development of Sun SPOT applications. Not only is the Squawk VM fully compliant with Java ME [2]. It also provides an extensive debugging framework and allows applications to be migrated between devices. Furthermore, the Sun SPOT platform allows for over-the-air deployment of Sun SPOT applications. Despite these features, Squawk is still required to run on sensor nodes, which usually have a limited memory capacity. Squawk therefore runs directly above the hardware and does not require an operating system. However, unlike most other VMs Squawk is almost entirely implemented in Java itself [2]. This is a result of the observation that the Java language is well suited to express most VM functionality. Therefore only the actual byte code interpreter was written in C. All other features such as the thread scheduler and the garbage collector have been written in Java. Consequently all device drivers have also been written in Java and may easily be modified for domain specific purposes. Like with other VMs the standard Java byte codes are translated into a more compact byte code format. Furthermore Squawk uses a ”Split VM” architecture. Instead of directly performing the loading process off the Sun SPOT device, class files are first loaded on the host where the application is deployed from. The internal object memory representation of these classes is serialized into suite files which are then deserialized on the Sun SPOT, where they are placed in predetermined memory areas. As a result both the memory footprint and the time required to launch an application are reduced. Despite these optimizations, the Squawk VM requires hardware that is more powerful than what is usually found in TinyOS based sensor networks. A Sun SPOT consists of an ARM920T processor, running at 180 MHz, 512KB RAM- and 4MB flash memory [2], while the Crossbow TelosB mote running TinyOS, for instance, uses a TI MSP430 micro controller with only 10KB RAM running at 4MHz [9]. As a result, the average battery lifetime of a Sun SPOT is a few orders of magnitudes less than is actually required for a sensor network. Sun SPOTs are therefore most suited for rapid prototyping of sensor network applications.

3

IEEE 802.15.4 and LowPAN

Sun SPOTs and many types of TinyOS-programmable sensor nodes [8] are equipped with an IEEE 802.15.4 compliant radio to perform wireless communication. Furthermore, the network layer of the Sun SPOT stack is heavily based on

Facilitating Communication between Sun SPOTs and TinyOS-Based Motes

181

the IETF’s LowPAN [10] specification. Therefore, in the following, we introduce these protocols. 3.1

IEEE 802.15.4

As Akyildiz et. al [11] point out, the use of power-limited devices in wireless sensor networks requires power-optimized radio protocols. Since existing protocols, such as IEEE 802.11, consider power-consumption as a secondary concern, the IEEE 802.15.4 standard was introduced. This standard provides both PHY and MAC layer protocols for low-power low-bandwidth wireless networks and is used for instance in the proprietary ZigBee radio stack. At the physical layer, IEEE 802.15.4 can operate on a variety of frequency bands, including the 2.4GHz ISMband in which 802.15.4 defines 16 separate channels. DSSS and OQPSK are used to send symbols, each containing 4 bits of data, at a rate of up to 62.5 ksymbols or 250kbits per second. Above the physical layer, the MAC layer provides two modes of operation: beacon-enabled mode and non-beacon-enabled mode. The beacon-enabled mode provides many interesting features such as contention-free channel access and polling-based frame reception. In non-beacon-enabled mode, all frames are sent using the contention based CSMA-CA algorithm. Since neither TinyOS nor the Sun SPOT library supports beacon-enabled mode, this paper focuses on the non-beacon-enabled mode. For simplicity’s sake, in what follows we refer to the non-beacon-enabled mode of the IEEE 802.15.4 MAC layer protocol as ‘the MAC layer’. The IEEE 802.15.4 standard specifies four different MAC frame-types: beacon, management, data and acknowledgement frames. For this discussion only data and acknowledgement frames are relevant, since management frames are used in neither TinyOS nor the Sun SPOT radio stack and beacon frames are only relevant when using beacon-enabled mode. Data frames are used to transfer higher-level data between nodes. The sender of a data frame may request that frame to be acknowledged. The receiver is then required to send an acknowledgement frame exactly 12 symbol periods (192 µs) after receiving the data frame. This interval is the maximum time allowed for changing the radio between RXand TX-modes. The MAC Layer divides all nodes operating on the same channel into multiple Personal Area Networks (PANs). Each of these PANs is identified by a unique identifier. Although this separation does not prevent communication between nodes of different PANs, this mechanism does allow multiple networks to operate independently on the same channel. More importantly, the communication between nodes of the same PAN may be optimized if a so called PAN-Coordinator is present. In that case a node may request its coordinator for a temporary, PAN-specific, 16-bit short address. When granted, this address is then used for PAN-local communication instead of the node’s unique 64-bit extended address. By using this mechanism, the overhead on local communication can thus be largely reduced.

182

D. van den Akker et al.

  












  

 

     

   

   

 

 




 !" 


#

%# !" 

%
'

 $
  %&'

Fig. 1. The IEEE 802.15.4 MAC Frame format. Reproduced from [13].

      



$$$

% !"#   $ 









$$$












 






Fig. 2. The IEEE 802.15.4 Ack-frame format

We now explain the IEEE 802.15.4 frame format shown in figure 1. This frame format is used by both TinyOS and the Sun SPOT library. Each MAC frame can contain up to 127 bytes and consists of a MAC Header (MHR), the MAC Payload and a MAC Footer (MFR) containing a 16-bit frame check sequence. The MHR contains a 16-bit frame control field, followed by a 1-byte sequence number and the addressing fields. The frame control field contains the following information relevant to this paper: – Frame type: the type of the frame being sent. – Ack. Request: used to signal to the receiver that the frame should be acknowledged. – PAN ID Compression: if set, the packet is being sent between nodes with the same PAN id and the source PAN id is not present. – Dest. addressing mode: specifies whether the destination address is 16 bit long, 64 bit long, or not present in the frame. – Src. addressing mode: specifies whether the source address is 16 bit long, 64 bit long, or not present in the frame. The address fields of the MHR consist of the PAN-id and address of the source and destination node. Each of these fields may, depending on the frame type, be absent from the MHR. Data frames being sent between nodes of the same PAN-id, for instance, do not specify the destination PAN-id field. Likewise,

Facilitating Communication between Sun SPOTs and TinyOS-Based Motes

183

acknowledgement frames, as illustrated by figure 2 contain no addressing information at all. They only contain the sequence number of the data frame being acknowledged. As a result the length of the MHR is dependant on which fields are present and the length of the source and destination address. For more information about the IEEE 802.15.4 protocol, we refer to [12]. 3.2

LowPAN

In order to integrate sensor networks with other networking technologies, a general network layer such as IPv6 is required. Unfortunately this protocol cannot be used directly on top of IEEE 802.15.4 since, amongst others, IPv6 packets are too large to fit in a single IEEE 802.15.4 MAC frame (at most 114 bytes). To resolve this problem, the IETF specifies an intermediate layer that provides the needed services to support IPv6 on IEEE 802.15.4-based sensor networks [10]. This layer is commonly referred to as the LowPAN layer (or 6LowPAN when talking about IPv6). The first service provided by this LowPAN layer is fragmentation. As IPv6 packets may contain up to 1280 bytes and IEEE 802.15.4 frames only contain 127 bytes, fragmentation and reassembly is required to transfer IPv6 packets between sensor nodes. Furthermore, the LowPAN specification also requires that all nodes in a single PAN should be seen by IPv6 as being on the same network-link. As a result the LowPAN layer also provides meshing and multihop broadcasting in order to manage the routing of packets between nodes of the same PAN. Furthermore, the LowPAN layer can also perform IPv6 header compression. Due to its limited relevance to this paper, we refer to [10] for more information about IPv6 header compression. In order to ensure extensibility, the LowPAN specification does not define a single ‘LowPAN-header’ but instead defines a separate header for each provided service. In order to distinguish between headers of different services, a 1-byte dispatch- or type-value is defined for each header. When a LowPAN frame is sent, the relevant headers are created, prepended with their dispatch-byte and then stored in a fixed order at the start of the payload of an IEEE 802.15.4 MAC frame. An example of such a frame is provided in figure 3. Not all headers need to be present. If, for instance, an IPv6 packet is small enough to fit into a single LowPAN frame no fragmentation header is used.


 



 

   

 

   

      #$
 !"   

Fig. 3. Example LowPAN frame

 %

184

D. van den Akker et al.

Fig. 4. The LowPAN layer architecture

Upon packet reception, the LowPAN headers are processed by the appropriate services in the same order they were stored. Since each service may decide that no further headers are to be processed, these services may be regarded as separate ’sublayers’ inside the LowPAN layer. Figure 4 shows the resulting architecture and the flow of incoming and outgoing packets. While separate headers exist for the meshing and for the multihop broadcasting service, the broadcasting header may only appear if a meshing header is present. We therefore regard these services as being a single layer. As explained above, each service is assigned a separate dispatch value. While some of these values are already in use to support the current LowPAN services, many values remain unused to allow future extensions to the LowPAN layer. In order to allow non LowPAN-enabled nodes to coexist with LowPAN implementing nodes, a range of dispatch-values has been reserved. These special ’Not a LowPAN’ or NALP dispatch-values indicate that the frame should be discarded by the LowPAN layer upon packet reception.

4

Radio Stack Compatibility

We now discuss the radio stacks of both the TinyOS and the Sun SPOT platform. These platforms both based their radio stacks on the IEEE 802.15.4 standard and the LowPAN specification. Unfortunately both do not provide fully compliant implementations. Consequently, their radio stacks are not compatible with each other. The resulting issues manifest both at the MAC and the LowPAN layer.

Facilitating Communication between Sun SPOTs and TinyOS-Based Motes

185

While these issues could be resolved by providing compliant implementations of the IEEE 802.15.4 MAC protocol and the LowPAN specification for both platforms, this solution would require the radio stack of both the Sun SPOT and the TinyOS platform to be altered. Sun SPOTs are however best suited for rapid prototyping of sensor network applications. The main application of this paper therefore lies in integrating SunSPOTs with existing TinyOS-based networks. Altering the TinyOS radio stack would thus require the sensor network to be completely redeployed. A more viable solution is therefore to modify the Sun SPOT radio stack in order to provide compatibility with the TinyOS radio stack. We introduce the TinySPOTComm project. This project consists of a number of modifications to the Sun SPOT stack, that allow for radio communication with an unaltered TinyOS stack. Furthermore the TinySPOTComm stack remains fully compatible with the default Sun SPOT stack. The changes made by the TinySPOTComm project, as discussed below, are based on version 4.0 (blue) of the Sun SPOT library and TinyOS version 2.1.0. Since hardware-compatibility between the two investigated platforms is one of the key assumptions in our research, the TelosB TinyOS-mote was used as it is based on the same RF-chip as the Sun SPOT platform, namely the TI CC2420 RF Transceiver. 4.1

MAC Layer

As mentioned above, the radio stacks of Sun SPOTs and TinyOS-motes are both based on the IEEE 802.15.4 specification for wireless sensor networks. Unfortunately, this standard is generally not fully implemented. This is also the case for TinyOS and the Sun SPOT library. Both provide only partial implementations, which are not compatible with each other. The following issues were identified: 16- vs. 64-bit addressing. As mentioned in section 3, the IEEE 802.15.4 standard provides two different addressing modes. The Sun SPOT radio stack uses the 64-bit extended addresses, while in TinyOS only 16-bit addresses are used, without the required PAN Coordinator. Since no 64-bit to 16-bit translation is being performed, this issue prevents communication between Sun SPOTs and TinyOS-motes. This issue may not be resolved by the use of a PAN Coordinator since TinyOS is to remain unaltered and lacks the functionality required to communicate with one. Consequently the most viable solution is to build support for 16-bit addressing into the Sun SPOT stack. In order to maintain compatibility with unmodified Sun SPOTs, the required changes have to be as least intrusive as possible. The usage of short addresses is therefore as much as possible hidden from both the MAC layer and the rest of the radio stack. For this purpose a two-way conversion between short and extended addresses is used. Since the Sun SPOT radio stack implementation makes use of a separate ‘RadioPacket’-class to perform all packet-related operations, this conversion has been inserted into this class. As a result the rest of the Sun SPOT stack is largely unaware of the existence of 16-bit addressed hosts. By default, the conversion is implemented by assuming a unique 48 bit prefix is shared between the extended address of

186

D. van den Akker et al.

all Sun SPOTs. In reality each extended address is comprised of a 32 bit vendor specific prefix followed by a 32 bit device identifier. As all Sun SPOTs are manufactured by Sun, the 32 bit vendor specific prefix is shared between all Sun SPOT devices. The device identifier is uniquely coupled to each individual Sun SPOT. As a result, this assumption fails to hold when the extended addresses of two Sun SPOTs differ within the 16 most significant bits of the device identifier. In order to circumvent this issue, the TinySPOTComm stack allows the address conversion to be redefined by extending the ‘IEEEAddressHash’ class. Secondly, the configuration of the address-recognition had to be altered. In the unmodified Sun SPOT stack, the CC2420 chip is configured to only accept broadcast and matching 64-bit addressed unicast frames. Since TinyOS only uses 16-bit addresses, the radio was configured to also accept frames addressed to the 16-bit representation of the Sun SPOTs extended address. Software versus Hardware Acknowledgements. According to the IEEE 802.15.4 standard, frames with the ‘ACK’ bit set, should be acknowledged after exactly 12 symbol periods (192 µs) The Sun SPOT stack implements this behavior by using the automatic acknowledgement feature provided by the radio chip. Unlike the Sun SPOT library, TinyOS handles ACKs, by default, in software rather than in hardware. This is due to the fact that in TinyOS a received packet is not guaranteed to be transferred from the CC2420 chip to the micro controller [15]. Consequently, the use of hardware-ACKs may result in false acknowledgements. The TinyOS developers therefore chose to handle ACKs in software. Because of this, ACKs sent from a TinyOS-powered mote, are sent with a delay that is too large to be accepted by Sun SPOTs. By increasing the Sun SPOTs ACK timeout from 864µs to 992µs, TinyOS-originated ACKs are accepted by Sun SPOTs. It should be noted that increasing the ACK timeout is not entirely without risk. Since in the IEEE 802.15.4 standard, acknowledgements do not contain the address of the host which sent the original packet, a packet and its acknowledgement are only related by their respective sequence number. Consequently, a false acknowledgement will occur if an unrelated packet with the same sequence number is acknowledged while the sender of the original packet waits for an acknowledgement. The chance of a false acknowledgement is proportional to the ACK timeout, which should therefore be kept as small as possible. In a TinyOS network however, the proposed increase should not pose a problem as TinyOS requires an ACK timeout of 8000µs. This relatively large timeout value is the result of restrictions on the hardware level. On certain hardware platforms, such as the Crossbow TelosB mote, the radio chip shares its bus to the microcontroller with other peripherals. By increasing the ACK timeout value, it is no longer necessary for the radio chip to keep the bus occupied while waiting for an acknowledgement. As a result the other peripherals on the bus (persistent storage in the case of the TelosB mote) may be accessed by the microcontroller while the radio is busy.

Facilitating Communication between Sun SPOTs and TinyOS-Based Motes

4.2

187

Network Layer

As mentioned above, the Sun SPOT stack heavily relies on the LowPAN specification to provide routing, meshing and fragmentation. Although most LowPAN functionality is implemented, the Sun SPOT library does not support IPv6 and instead uses the IEEE 802.15.4 extended addresses to identify nodes in the network. Based on the ‘multiple header’ principle of the LowPAN specification, the Sun SPOT library provides an extensible LowPAN implementation. It allows so called ‘ProtocolHandlers’ to be coupled to specific dispatch-bytes. Upon packet reception, a packet is relayed to the ProtocolHandler associated with the dispatch-byte of the packet. This mechanism is, for instance, used by the radiogram (the equivalent of UDP) and radiostream (the equivalent of TCP) protocols to allow Sun SPOT applications to access the network. These ProtocolHandlers are only used for protocols which are not defined in the LowPAN specification. If meshing, multihop broadcasting or fragmentation headers are present, these are directly handled by the LowPAN layer itself. In contrast, TinyOS does not seem to provide any network layer functionality. Instead the payload of each TinyOS-originated data packet commences, by default, with a byte containing ‘0x3f’. LowPAN implementing nodes interpret this byte as a ‘NALP’ value and consequently discard TinyOS-originated packets. The second byte is used for multiplexing, as to allow multiple data-flows. Since

Fig. 5. The LowPAN Layer in the Sun SPOT architecture

188

D. van den Akker et al.

try { Da ta gr am Co nn ec ti on conn = ( Da ta gr am Co nn ec tio n ) Connector . open ( " radiogram ://0014.4 F01 .0000.116 B :65 " ); Datagram dg = conn . newDatagram (22); dg . writeChars ( " Hello World " ); conn . send ( dg ); } catch ( IOException e ) { ... }

Fig. 6. This code sends the string ”Hello World” to SunSPOT ‘0014.4F01.0000.116B’ on port 65, using radiograms

try { DatagramConnection conn = ( DatagramConnection ) Connector . open ( " tinyos ://0014.4 F01 .0000.0001:65 " ); Datagram dg = conn . newDatagram (22); dg . writeChars ( " Hello World " ); conn . send ( dg ); } catch ( IOException e ) { ... }

Fig. 7. This code sends the string ”Hello World” to the TinyOS-mote with short address ‘0001’, using 65 as multiplexing value

no alterations are to be made to the TinyOS radio stack, the best solution to this problem would be to bypass the LowPAN layer for all TinyOS-originated packets. Fortunately, the Sun SPOT LowPAN implementation allows for this behavior to be implemented with only minor changes. Figure 5 shows the resulting architecture. Since packets starting with a ‘NALP’ byte do not contain any meshing or fragmentation headers, the LowPAN implementation attempts to dispatch the packet to the corresponding ProtocolHandler. Since, by default, no ProtocolHandlers are registered to handle NALP values, the packet is discarded (as required by [10]). TinyOS originated packets may therefore be intercepted by registering a specialized ’TinyOSProtocolHandler’ to the dispatch value 0x3f. This ProtocolHandler is also responsible for sending packets to TinyOS nodes. Since the LowPAN layer normally uses 64-bit addressing, this ProtocolHandler is responsible for creating RadioPackets using 16-bit addressing. The created packet is then passed directly to the MAC Layer. By extending this TinyOSProtocolHandler, new protocols being developed on top of the TinyOS-stack may be ported to the Sun SPOT platform. The current implementation of the TinyOSProtocolHandler is used to provide application

Facilitating Communication between Sun SPOTs and TinyOS-Based Motes

189

level compatibility with the default TinyOS stack. This is done by translating TinyOS’ multiplexing byte into a port number and by adding a new ‘tinyos://’ handler to the Sun SPOTs Generic Connection Framework (GCF) [14]. Using this GCF handler, communicating with TinyOS-motes is done similar to regular communication between Sun SPOTs. An example of this is provided in figures 6 and 7.

5 5.1

Performance Setup

In order to establish the performance of the TinySPOTComm stack (the Sun SPOT stack patched with the changes proposed in the previous section), the single-hop delay and throughput between Sun SPOTs and TinyOS motes were measured. The delay was measured by performing a ping-test from a client to a server node and recording the round-trip time. The average round trip time was then calculated over 200 test runs. To measure the throughput, unicast packets with the ACK-request flag set, were continuously sent from the client node to the server node. After the test-run had completed, throughput was derived from the number of packets received by the server. An average value was calculated over seven test-runs of 60 seconds. These round trip time and throughput tests were run using only TinyOS motes, only Sun SPOTs or between a Sun SPOT and a TinyOS mote, with the TinyOS mote acting as server and the Sun SPOT acting as client and vice versa. Furthermore, the network performance of the TinySPOTComm stack was compared to that of the regular Sun SPOT stack. For this purpose the delay and throughput tests were also performed using the TinyOS-incompatible radiogram protocol provided by the Sun SPOT library. These tests were then run between two Sun SPOTs equipped with the default Sun SPOT radio stack and between two Sun SPOTs using TinySPOTComm stack. Unfortunately, the use of radiograms limits the number of bytes that may be sent in an IEEE 802.15.4 frame to 123 instead of 127 bytes. This is due to the fact that the Sun SPOT library is overly cautious when calculating the number of available payload bytes. Firstly the Sun SPOT library reserves two bytes in the MAC header to store the source PAN id, regardless of whether that field is present or not. Secondly, two extra bytes are reserved by the LowPAN implementation to allow for the use of extended dispatch-fields in a LowPAN packet. Given the limited number of ProtocolHandlers registered with the LowPAN layer, these large dispatchfields remain currently unused. In order to compensate for this inequality, all throughput tests were performed using 123-byte frames. Due to it’s limited relevance to this paper, the energy consumption of the Sun SPOT and TinyOS radio stacks was not measured. The TinySPOTComm project does not alter the TinyOS radio stack and therefore does not affect it’s energy consumption. Furthermore, Sun SPOTs only have a battery lifetime of a few hours to a few days at most and are best suited for rapid prototyping. As a result ‘prototyped’ sensor network applications usually only need to run

190

D. van den Akker et al.

for a few hours or are deployed on a Sun SPOT connected to an external power source. All measurements were obtained using Crossbow TelosB motes equipped with TinyOS 2.1.0 and Sun SPOTs running either version 4.0 (blue) of the Sun SPOT library or our custom TinySPOTComm stack. 5.2

Round Trip Time

Figure 8 displays the average and the standard deviation of the round trip times measured between TinyOS motes and Sun SPOTs. The smallest average is measured when two TinyOS motes are used. When one TinyOS mote is replaced with a Sun SPOT, the round trip time increases, and it is the largest when only Sun SPOTs are used. This increase in round trip time is to be expected since the Sun SPOT library provides a more advanced network layer than TinyOS. Furthermore, different threading models are used by TinyOS and the Sun SPOT JVM. As a result, in TinyOS a received packet is handed almost directly to the application while the Sun SPOT radio stack requires a received packet to be handled by several different threads before it is delivered to the application. This may also account for the increase in delay. The tests show however that the round trip time is increased by no more than 10% to 15%. It is therefore unlikely to cause any major issues. 5.3

Throughput

The average and standard deviation of the throughputs that are reached when sending data between TinyOS motes and Sun SPOTs is displayed in figure 9. In 30 Average RTT

Round trip time (ms)

25

20

15

10

5

0 TinyOS to TinyOS TinyOS to SunSPOT SunSPOT to TinyOS SunSPOT to SunSPOT

Fig. 8. Average Round Trip Times

Facilitating Communication between Sun SPOTs and TinyOS-Based Motes

191

12000 Average Throughput

Throughput (bytes/sec)

10000

8000

6000

4000

2000

0 TinyOS to TinyOS TinyOS to SunSPOT SunSPOT to TinyOS SunSPOT to SunSPOT

Fig. 9. Average Throughputs

contrast with the round trip time, the throughput is maximal when measured between two Sun SPOTs and it is minimal when only TinyOS motes are used. This is probably due to the fact that the used TelosB motes have significantly lower hardware specifications than Sun SPOTs. Interestingly, this bottle-neck is most prominent when the TelosB mote is used as a client node. When a Sun SPOT is used to unicast packets to a TelosB mote, the throughput is only slightly smaller than if two Sun SPOTs are used. Secondly, a sudden increase in the standard deviation can be observed when only Sun SPOTs are used. This is caused by the garbage collector of the Squawk VM interrupting the server node test application during the performance test. This phenomenon is not visible in the other test setups, since it only affects the Sun SPOT server node and only when the throughput is large enough. When the garbage collector is explicitly invoked at the end of each test-run, the standard deviation is equally large as in the other test setups, while the average throughput remains unaltered. Do note that the throughputs displayed in figure 9 do not approach the theoretically possible maximum throughput of the IEEE 802.15.4 standard (250kbit/s). This is due to the fact that power consumption is more important than throughput in the application domain targeted by the IEEE 802.15.4 standard and the Sun SPOT and TinyOS platforms. 5.4

Impact on Sun SPOT Performance

Figures 10 and 11 show the results of the radiogram based delay and throughput tests. From these results, it is clear that the network performance of the

192

D. van den Akker et al. 30 Average RTT

Round trip time (ms)

25

20

15

10

5

0 TinySPOTComm stack

Default SunSPOT stack

Fig. 10. Average Round Trip Times when using radiograms

12000 Average Throughput

Throughput (bytes/sec)

10000

8000

6000

4000

2000

0 TinySPOTComm stack

Default SunSPOT stack

Fig. 11. Average throughput when using radiograms

TinySPOTComm stack is only marginally smaller than that of the default Sun SPOT stack. The use of the TinySPOTComm stack only increased the round trip time by 1.03%. The original Sun SPOT stack only achieves a throughput that is 1.02% larger than the TinySPOTComm stack. As with the Sun SPOT to

Facilitating Communication between Sun SPOTs and TinyOS-Based Motes

193

Sun SPOT throughput test in section 5.3, the relatively large standard deviation of the measured throughputs is caused by the garbage collector.

6

Conclusion and Future Work

Wireless sensor networks are becoming increasingly popular. Despite hardware compatibility, sensor nodes which are programmed using different frameworks are often incapable to communicate with each other. We have investigated this problem by focussing on the radio stacks of the Sun SPOT and TinyOS platform. The TinySPOTComm project introduced in this paper, provides a set of modifications to the Sun SPOT stack, that allow for communication with TinyOSmotes. The TinySPOTComm stack remains fully compatible with the default Sun SPOT radio stack and we have shown that its network performance is only marginally smaller than that of the default radio stack. While the TinySPOTComm stack does allow for communication between Sun SPOTs and TinyOS motes, the use of this modified radio stack would become unnecessary if both the Sun SPOT and the TinyOS radio stack were to be made fully IEEE 802.15.4compliant. The Sun SPOT platform already provides a respectable but not yet fully compliant implementation and a working group [16] has been founded to provide an IEEE 802.15.4 compliant radio stack for TinyOS. The TinySPOTComm stack may be improved by providing compatibility with blip [17], a LowPAN implementation for the TinyOS platform. Unfortunately, it is impossible to extend the functionality of the TinyOSProtocolHandler in order to gain this compatibility as the blip stack both lacks both the ‘NALP’ byte and the multiplexing byte used by the standard TinyOS stack. A possible solution would be to inject IPv6 functionality into the existing LowPAN implementation. The TinySPOTComm stack may be further improved by analyzing and reducing the effect on the round trip time of using multiple threads to handle incoming packets.

References 1. The TinyOS community website, http://www.tinyos.net 2. Simon, D., Fuentes, C., Cleal, D., Daniels, J., White, D.: Java(TM) on the bare metal of wireless sensor devices: the squawk Java virtual machine. In: Proceedings of the 2nd international conference on Virtual execution environments, pp. 78–88 (2006) 3. Levis, P., Culler, D.: Mat´e: a tiny virtual machine for sensor networks. ACM SIGOPS Operating Systems Review (2002) 4. Harbaum, T.: The NanoVM - Java for the AVR (2005), http://www.harbaum.org/till/nanovm/ 5. Saballus, B., Eickhold, J., Fuhrmann, T.: Towards a Distributed Java VM in Sensor Networks using Scalable Source Routing, http://i30www.ira.uka.de/research/documents/p2p/2007/ saballus07distributed.pdf

194

D. van den Akker et al.

6. Koshy, J., Pandey, R.: VMSTAR: synthesizing scalable runtime environments for sensor networks. In: SenSys 2005: Proceedings of the 3rd international conference on Embedded networked sensor systems, pp. 243–254 (2005) 7. Shaylor, N., Simon, D.N., Bush, W.R.: A java virtual machine architecture for very small devices. SIGPLAN Not. 38(7), 34–41 (2003) 8. Beudel, J.: Metrics for Sensor Network Platforms. In: Proceedings of REALWSN 2006 (2006) 9. Datasheet for the Crossbow TelosB mote, http://www.xbow.com/Products/Product pdf files/Wireless pdf/ TelosB Datasheet.pdf 10. Montenegro, G., Kushalnagar, N., Hui, J., Culler, D.: Transmission of IPv6 Packets over IEEE 802.15.4 Networks (2007) 11. Akyildiz, I.F., Su, W., Sankarasubramaniam, Y., Cayirci, E.: A Survey On Sensor Networks. Communications Magazine, 102–114 (August 2002) 12. IEEE Computer Society: IEEE Std 802.15.4-2006 (September 2006) 13. IEEE Computer Society: IEEE Std 802.15.4-2003 (October 2003) 14. Enrique Ortiz, C.: The Generic Connection Framework (2003), http://developers.sun.com/mobility/midp/articles/genericframework/ 15. Moss, D., Hui, J., Levis, P., Choi Il, J.: CC2420 Radio Stack (2007), http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/ doc/html/tep126.html 16. The TinyOS IEEE 802.15.4 Working Group, http://www.tinyos.net/scoop/special/working_group_tinyos_154 17. The Berkeley IP Information project, http://smote.cs.berkeley.edu:8000/tracenv/wiki/blip

Author Index

Akker, Daniel van den 177 Anastasiou, Christos C. 43 Aoun, Marc 126 Blondia, Chris 177 Boano, Carlo Alberto Braem, Bart 177 Brown, James 159 Brown, Stephen 107

159

Lambrou, Theofanis P. 43 Logaras, Evangelos 1, 145 L´ opez, Juan A. 27

68

88

Oliver, Ramon Serna 126 Onoufriou, Toula 88 Panayiotou, Christos G. Paschos, Fotis 1 Pfisterer, Dennis 68 Roedig, Utz

Fischer, Stefan 68 Fohler, Gerhard 126

56

Iborra, Andr´es 27 Ignjatovic, Zeljko 56 Kalis, Antonis 88 Khadivi, Alireza 16

88

Manolakos, Elias S. 1, 145 Mylonas, Georgios 68

Catalano, Julien 126 Chatzigiannakis, Ioannis Cheng, Roland 56 Cleyn, Peter De 177 Constantinides, Anthony

Hasler, Martin 16 He, Zhitao 159 Heinzelman, Wendi

Koninis, Christos 68 Kounoudes, Anastasis

43

159

Samalekas, Konstantinos 145 S´ anchez, Pedro 27 Schoofs, Anthony 126 Smolderen, Kurt 177 Soto, Fulgencio 27 Sreenan, Cormac J. 107 Stok, Peter van der 126 Sturge-Apple, Melissa 56 Suard´ıaz, Juan 27 Voigt, Thiemo

159