MonSense – Application for Deployment, Monitoring ...

MonSense – Application for Deployment, Monitoring and Control of Wireless Sensor Networks José Pinto, Alexandre Sousa, Gil Manuel Gonçalves, Paulo Lebres, João Sousa Faculdade de Engenharia da Universidade do Porto Rua Dr. Roberto Frias Porto, Portugal + 351 22 508 1539

{ zepinto, ajsousa, gil, paulo.lebres, jtasso}@fe.up.pt ABSTRACT

This paper presents the MonSense application that is currently being used at our laboratory to deploy, monitor and control Wireless Sensor Networks (WSN). MonSense can connect to various sensor networks (each one composed by multiple sensor nodes) by interfacing with one or more gateways that forward information received by attached networks. The system is being developed iteratively, according to need arising from projects in our laboratory. We are currently applying WSN technology and the MonSense application to a weather monitoring station as well as to wildfire prevention and distributed noise monitoring.

Categories and Subject Descriptors

D.2.13 [Reusable Software]: Domain engineering and Reusable libraries.

General Terms

Measurement, Standardization, Design

Keywords

Wireless Sensor Networks, Data visualization, Systems architecture, TinyOS, MOTE.

INTRODUCTION The   possibilities   given   by   recent   Wireless   Sensor   Networks technologies are very appealing to anyone doing research in our field  [1],  [2].   Most   of   the   applications   in   the   field   involve deployment of large sensor networks that spread over vast areas, turning   the  correct  visualization  of   the  network   and  individual sensor states into matters of crucial importance. We are currently using WSNs for wildfire prevention, distributed noise   measuring   and   distributed   weather   monitoring.   The MonSense system was developed according to the needs that we have encountered when deploying, monitoring and controlling the WSNs that served this purposes. We have found problems like the need for global localization of sensor nodes, fast network state visualization, time­shifting data visualization, alert configuration, sensor recalibration, data fusion between multiple networks, map creation, among others. Currently, the MonSense application solves all of the mentioned problems   and   aims   to   solve   any   other   recurrent   problems   and requisites that arise when dealing with WSNs.

The system is being developed in a very modular way, being easy to   extend   it   by   creating   software   plug­ins   that   reuses   existing components.   The   plug­ins   must   implement   defined   software interfaces in order to recalibrate or display sensor data, control sensor   networks,   and   take   actions   when   some   conditions   are triggered. We are currently using the TinyOS [3] operating system and the Telos hardware platform, but the system is developed in a way that allows hardware and operating system independence.

RELATED WORK

Currently there are various applications to monitor WSNs like the TOSGUI [4] project, which is composed of modular components that can be used to create a customized application. Unfortunately, the component architecture is tightly connected with the TinyOS operating system and the MOTE hardware platform. SpyGlass [5] is a modular application that already has time-shifting abilities. Currently there is no support for the TinyOS operating system or a way to position the network nodes according to their real world locations. The MSR Sense [6] project is also able to collect data from a WSN and visualize it, but the visualization can’t be done in real-time and the software is not platform independent. The Trawler application from MoteIV is well suited for monitoring small sized WSNs but, as the size increments the current network state becomes less obvious. There are also some visualization applications included in the

REQUIREMENTS The   MonSense   application   is   being   developed   iteratively.   Any iteration matches a WSN deployment corresponding to one of the applications we are researching. The multiple aims of the system have lead to an increasingly modular and complete infrastructure that   serves   the   purposes   of   a   multitude   of   WSN   usages   and deployment phases. MonSense   can   be   used   for   different   goals   like   Planning, Deployment, Monitoring and Control of WSNs. This application is intended to serve two different types of users: WSN Customers and  WSN Researchers. The WSN Customers may know nothing about   ad­hoc   wireless   networking,   TinyOS   or   hardware specificities.   On   other   hand,   WSN   Researchers   have   deep

understanding   about   ad­hoc   routing   protocols,   sensor   hardware platforms   and   the   NesC   code   that   runs   on   the   devices.   WSN Researchers  will use  the application to  plan and  deploy sensor networks,   while   the   WSN   Customers   will   use   the   same application for the purpose of monitoring and controlling phases. The   application   must   be   able   to   connect   to   various   sensor networks   simultaneously,   also   allowing   the   existence   of   more than one base station for the same WSN. The gathered data must be easily understood by the final users and,  optionally,  this  data can be  published to the internet in a format that doesn’t require any previous software installation like html, plain text or images. The   maps   and   sensor   locations   should   be   (optionally)   geo­ referenced, facilitating the planning and deploy phase.

SOFTWARE ARCHITECTURE The   MonSense   application   is   very   modular   and   has   various extension points. It also reuses various software libraries in order to   reach   the   intended  behavior.   Here   is   an   incomplete   list   of libraries used in the application, together with a short description of why they were used: DOM4J [7] – Read/Write XML data as a tree structure. GPSylon [8] – Read positions from a GPS device. OpenMap [9] – Read positions from a GPS device. TinyOS Java Tools – Some classes are used to interface with the TinyOS SerialForwarder application. VisAD  [10]  –   Used   to   create   a  3  dimensional  visualization   of data. Neptus Framework [NEPTUS ref] ­ Various components were reused like the Neptus Map Editor and the Neptus 2D Renderer. Figure   1   shows   some   components   that   coexist   in   the   current architecture.   The   system   can   be   extended   by   creating   new implementations   of   interfaces   like  WSNStateRenderer  or WSNUpdater.  For instance,  one  can envisage the  addition  of a new component that would allow to publish the information via Web   Services   simply   by   registering   itself   as   a   new WSNStateRenderer. Thus, a new WSNUpdater could import real­ time data from the latter. To improve the independence of the system, we opted to use code introspection   to   parse   incoming   messages   from   the   network, which can be easily done by using the Java Reflection API. As an example, whenever the embedded sensor code changes, the only required efforts are the insertion of the generated java class files in the MonSense code and, optionally, the creation of a field calibration method.

Figure 1 – Partial view over MonSense architecture

1.1

Planning WSNs

When dealing with sensor networks, the planning phase usually involves   the   reconnaissance   of   the   deployment   area   and   the selection of the correct locations to position the sensors in a way that accomplishes the intended goal. In the EWFDS (o que é que é esta cena de EWFDS?!??!?!?! Esta sigla caiu do céu aqui) project, we need to cover vast areas of dense forest in order to monitor the possibility of fire ignition. Since forests are usually unordered landscapes, we need to use GPS coordinates in order to plan sensor locations. In MonSense, this   was   done   by   creating  an  environmental  map  of   the   Gerês National   Park  [11]  (where   experimentation   was   done)   and positioning the sensor devices following a virtual grid of 80 x 80 meters. The selected locations where then sent to a GPS device that   guided   the   deployment   personnel   to   the   intended   sensor positions.

WSN LIFECYCLE Typically,   there   are   four   phases   in   the   lifecycle   of   a   wireless sensor network (the implementation phase is omitted because the sensor code is usually reused). Researchers are usually involved in the planning and deployment phase, while the final customers are more interested in the monitoring and controlling of the WSN. Next, we show some problems relative to these phases and how the  MonSense  application   can  be  used  to  help   in  each   one  of them. Figure 2 – Planning WSNs using MonSense.

1.2

Deploying WSNs

In   the   deployment   phase,   sensor   nodes   continually   send   their wireless connection quality and route to the base. The MonSense application   displays   the   existing   connections   (routes)   as   an undirected graph, whose nodes are the sensor devices and edges are   the   current   connections.   The   colour   of   the   nodes   changes according to their connection quality: Red Color – The node has no connection with the network Yellow Color – The node has sent a message to the network that was just received Green Color – The node is connected to the base station Blue Color – The node is connected to the network and has sent a message recently The use of different colours to display the status of the network greatly facilitates the apprehension of the information and allows the rapid perception of the entire network state. Additionally to the colour information, the user can view further details about a specific node like the time since the last message reception, sensor readings, GPS location, etc. The nodes can be placed in the map by a drag and drop operation or by entering its intended GPS coordinates, allowing a precise definition of their real locations.

important happenings. These alerts will be implemented by using a scripting language over the incoming network data. MonSense also has the ability to export data being received to the internet in a pluggable way. So, it is possible to create plug­ins for exporting data as text, HTML, SVG, or any other relevant format. Currently  there   are   plug­ins  for   HTML,   XML,   PNG   and  CSV formats but others will be built according to need.

Figure 4 – Sensor Data Visualizations

1.4

Controlling WSNs

The application  can also  be used to  control  WSNs by  sending commands to the network. These commands can tell the network devices   to   stop   sending   messages,   increase   the   time   between messages   or   even   reset   the   network   (restart   the   Multi­Hop algorithm). In the future, the network could be controlled via a web interface or a handheld device, being easier to stop and restart the network as needed. Figure 3 – Nodes coloured according to their current state.

1.3

Monitoring WSNs

When monitoring WSNs, the user interest mainly focuses on the values read by network sensors. In MonSense, the sensor readings can also be viewed as a colored map due to the precise definition of the real sensor locations. In addition to latitude and longitude, there is also the possibility to define the altitude of every device. When the altitudes are entered correctly, the WSN can also be viewed as colored 3D surface as shown on Figure 2.  Sensor   readings   can   be   viewed   in   real­time   or   the   user   may choose to replay previously gathered data by opening a MonSense log file. After opening a log file, all the messages recorded are then   replayed   chronologically,   allowing   the   revision   of unexpected behavior and the archiving of timed data. The MonSense application will also allow the definition of alerts relative to a specific type of sensor in order to warn the user about

PROJECTS USING MonSense Currently, there are various projects using MonSense to interface with   WSNs.   Due   to   the   great   disparities   between   the   various goals, this lead to an increasingly modular framework that can be used for virtually any other type of WSN application. In the following subsections we present projects running in our laboratory   that   are   using   the   MonSense   application   and   also explain how the application is being accordingly adapted. Other possibilities are rising, like the integration of WSNs in a water  museum  for  monitoring   variables   like  water   temperature and   the   water   velocity,   various   precision   farming   applications, among   others.   We   look   forward   to   see   how   this   will   further improve the modularity of MonSense.

1.5

EWFDS Project

This was the first project in our laboratory dealing with wireless sensor networks. This system tries to quantify the probability of wildfire   occurrence,   based   on   wireless   sensor   nodes

measurements   from   specific   environmental   parameters (temperature, humidity and light). Initially,   we   tried   to   use   existing   software   from   the   TinyOS distribution, like the Surge application and TinyVIZ, to deal with sensor   readings,   but   the   features   of   these   applications   were insufficient to fulfil the requirements of our project. Alternatively, we   used   the   already   existing   Framework   (Neptus),   to   meet EWFDS project specific requirements. The   requisites   for   this   project   were   an   application   that   could monitor an entire WSN and help define the real location of every sensor   in   the   network.   Since   this   was   our   first   project,   the application also served for debugging the ad­hoc communication protocol we used.

We believe the MonSense application is still at its infancy. There is a great quantity of future extensions that can be implemented over time.

1.6

Another interesting way of publishing WSN data will be made by creating a KML server that will integrate with Google Earth (nao tens uma ref p aqui?) software. This server will be able to publish geo-referenced information incoming from WSNs across the world.

Distributed Weather Station

This project was created to involve our institution in our current research   effort.   The   project   aims   to   create   a   sensor   network distributed   over   campus   university   buildings   to   continually monitor temperature, relative humidity, wind speed and direction. This brought several problems such as the great distances between buildings, the need for simpler visualizations and the inclusion of 3 dimensional building maps. The MonSense application evolved toward making it possible to connect to multiple sensor networks and view the received data as if it was a single WSN. This allowed the existence of different base   stations   across   the   university   that   continually   collect   and serve data from the attached sensor network. To respond to the explosion in the amount of people wanting to visualize the network data, we developed a publishing framework for   MonSense.   This   framework   allows   the   export   of   data   in multiple formats to a local or remote computer. It is now possible to export data forwarded by multiple base stations to various file formats like HTML, PNG or text. We currently use images and HTML files to present the WSN information to the community.

1.7

Distributed Noise Monitoring

This project was started due to a real world need for it. We were asked to monitor noise over a large area and create a simple model for the propagation of noise. The goal is to prevent some surrounding areas from the noise created by the upload and download of merchandise. We are still studying the possibility of using MOTES to sense noise and send the collected data to a base station, where it could be correlated to the other data collected by other noise sensors.

CONCLUSIONS AND FUTURE WORK

MonSense has proved very useful in all the projects we are involved in. Its use in real world applications accelerated its development, increased its usefulness and made the system more modular. The ability to easily extend the application was also very important to effectively respond to the new requisites. The existence of multiple interaction modes greatly increases software usability and allows its use by people who know nothing about WSN specificities. The publishing plug-in had crucial importance to the success of the application because it facilitates the distribution of data over the web.

Currently, the insertion of alerts involves codification, which is against the project aim. A more elegant way of including this feature will be to provide a way for visually defining a limit for any of the sensor values, by dragging a line over a chart or a moving a slider. We will continue to reuse components from the Neptus Framework, like a 3 dimensional map visualization which will aid the planning in other types of environments like building interiors, mines, etc. New data import and export plug-ins will be created to respond to requisites of new users. Some of the formats that probably will be implemented include Matlab , OpenGIS SensorML and SQL.

We will integrate new hardware platforms like the Sun SPOT devices by creating new WSNUpdater plug-ins. Yet another aspect we want to improve is the deployment phase. One way this can be facilitated is by creating a stripped-down version of the application that can run in a handheld device. If the device has GPS abilities this will greatly improve the efficiency of the deployment and retrieval phases. In the future we also want to create a central server that gets notified of every instance of MonSense running. It will be used to list data sources (MonSense applications) and serve as a proxy to the data.

2.

REFERENCES

[1] David Culler, Deborah Estrin and Mani Srivastava, Overview of Sensor Networks, Computer, August 2004, pp. 41-49. [2] Vijay Kumar, Daniela Rus and Sanjiv Singh, Robot and Sensor Networks for First Reponders, Pervasive Computer, October – December 2004, pp 24-33 [3] TinyOS Community Forum http://www.tinyos.net/, March 2006 [4] Mark Miyashita, Mikhail Nesterenko, Romil D. Shah and Adnan Vora, Visualizing Wireless Sensor Networks: Experience Report, International Conference on Wireless Networks 2005 [5] Carsten Buschmann, Dennis Pfisterer and Stefan Fischer, SpyGlass: A Wireless Sensor Network Visualizer, ACM SIGBED Review 2005 [6] MSR Sense - MSR Networked Embedded Sensing Toolkit http://research.microsoft.com/nec/msrsense/, March 2006 [7] DOM4J Home page - http://www.dom4j.org/, March 2006 [8] GPSylon Home page - http://www.tegmento.org/gpsylon/, March 2006 [9] OpenMap – Open Systems Mapping Technology http://openmap.bbn.com/, March 2006 [10] VisAD – Home page http://www.ssec.wisc.edu/~billh/visad.html, March 2006 [11] Parque Nacional da Peneda-Gerês – Official home page http://www.geira.pt/pnpg/index.html, March 2006

[12] Alessandro G. Colombo and Ana V. Arellano (editors), NEDIES Project - Lessons Learnt from Forest Fires Disasters, Report EUR 20662, Joint Research Center, 2003 [13] Alexandre Sousa, José Pinto, Gil Gonçalves and João Sousa, Poster Abstract: Pilot Experiment of an Early Warning Fire Detection System, EWSN 2006, ETH Zurich, Switzerland, February 13-15, 2006

[14] Paulo Sousa Dias, R. Gomes, J. Pinto, , S. L. Fraga, G. M. Gonçalves, J. B. Sousa and F. Lobo Pereira, “Neptus – A framework to support multiple vehicle operation”, Today's technology for a sustainable future, OCEANS Europe 2005, Brest, France, June 20-23, 2005.