Sensor Applications, Experimentation, and Logistics (LNICST 29) [1st Edition.] 3642118690, 9783642118692

Citation preview

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

∑ i di (u) 2 , where

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:

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 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

−1

T

J d.

⎞

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

∑ sin 2 (α i ) − ∑ sin(α i ) i

i

−∑ cos(α i ) ⎞

⎟ ⎟ − ∑ sin(α i ) ⎟ ⎟ i ⎟ m ⎟ ⎠ 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 ∑ sin(α ) ≈ 0 i

i

i

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

1

2

1

i

i

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

i

1

2

1

i

i

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

i

1

i

i

i

i

i

i

i

(5)

Fire Detection and Localization Using Wireless Sensor Networks

21

T

Therefore, J J can be simplified to

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

and as a result,

(J J ) T

−1

=

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

⎛2 1⎜ 0 m ⎜⎜ ⎝0

0

(6)

0⎞

⎟ ⎟ ⎟ 0 1⎠ 0

2

0

(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 ⎝ ⎠ ⎛ 25mA ⋅ 125 ⋅ 10 −3 ⎞ ⎟ = 0.00434 mA I trans ≈ 2.5 ⋅ ⎜⎜ ⎟ 1800 ⎝ ⎠

(4)

(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

D2 LED-GREEN

R5 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

D0 D1 D2 D3 D4 D5 D6 D7

C1

RS RW E

2

330

7 8 9 10 11 12 13 14

1N5817 CONN-SIL2

VSS VDD VEE

VI

3

1 2 3

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

Conclusions and Future Work

6.1 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 nand vi[n] is the target’s velocity also at time n. The estimate ˆs[n|n] of the state variable at time nis 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 w ireless 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 T r io 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 m 2 , 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.

M em ento [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; M a rionette [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. I nteraction 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

O verlay 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

S hawn [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) p ij 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 r i (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 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

137

RfPayload: [0xad,0xd8,…]

MAC

xRadioSend(address,&RfPayload,length);

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

Microkernel

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