sor network applications. To show flexibility and adaptability of NanoMon, we im- plemented two WSN applications- home monitoring and parking lot monitoring ...
NanoMon: An Adaptable Sensor Network Monitoring Software Misun Yu, Haeyong Kim, and Pyeongsoo Mah Embedded S/W Research Division Electronics and Telecommunications Research Institute (ETRI) Gajeong-dong 161, Yuseong-gu, Daejeon 305-700, South Korea {msyu, haekim, pmah}@etri.re.kr Abstract In this paper, we present a sensor network monitoring software, named NanoMon, which has a flexible architecture and supports for various user requirements of sensor network applications in an adaptive manner. With NanoMon, users can specify custom GUI plug-ins and internal module parameters by using a simply describable configuration file; and it can be automatically integrated to NanoMon framework to support user-specific sensor network applications. NanoMon employs a widely used database, MySQL, to concurrently and correctly manage sensing data and node information of several types of sensor network applications. To show flexibility and adaptability of NanoMon, we implemented two WSN applications- home monitoring and parking lot monitoring systems. By selecting a WSN application name specified in the configuration file, users can easily and dynamically change GUI and internal module parameters such as sensor types and database locations of NanoMon used to display the status of WSN.
1. Introduction Wireless sensor network (WSN) is a computer network consisting of spatially distributed sensor devices, which collect quite detailed information about the physical environment. WSNs have made many novel applications possible to emerge in the fields of environmental monitoring, home automation, object tracking, security and prevention of disasters. In these application systems, several tens or hundreds of sensing devices generate a volume of data. To deal with sensor network data generated various operating environment, users inevitably require monitoring software with decent abilities: abilities to flexibly change and scale its functions and appearances suitable to the purpose of various sensor networks as well as to monitor and analyze the collected information from sensor networks.
In this paper, we present architecture of sensor network monitoring software named NanoMon. NanoMon enables users to interpret sensor network status visually by providing decent visualization components for sensor network monitoring: topology, sensor data, sensor list, node status, received packet log and so on. In addition to its visualization components provisioning capability, NanoMon can manage multiple sets of sensor network information and store sensor data related with them. NanoMon also provides plug-in capability for adding and removing custom GUI components at need.
2. Capability Comparison of NanoMon and Other Monitoring Tools Currently, only few kinds of sensor network monitoring tools are available, which provide sensor network data display capability, topology visualization and sensor network information manageability to users. Mote-View [1] monitoring tool is capable of logging wireless sensor data to a database, analyzing sensor readings and plotting them. It is composed of several modules which scale flexibly enough to support disparate needs from various users by using the plug-in capability. Surge-View [2] provides similar functions with Mote-View except the plug-in capability. In SpyGlass framework [3], visualization plug-ins can register different data types and display information using a flexible multi-layer mechanism that renders information on a canvas. This software targets on debugging of applications and making the setup process easier. TinyViz is a Java-based GUI and a part of the TOSSIM package of TinyOS [4] [5]. It visualizes sensor readings, LED states and the status of radio links. Additionally, it allows a direct interaction with running TOSSIM simulations. The adaptive architecture of TinyViz allows users to add application specific visualization functions. These functions include specialized drawing operations, subscription/reaction to events and operations for providing feedback to the TOSSIM simulator. Table 1 shows the comparison among NanoMon
XXX XXX T ools F eatures XXXX Multiple WSN monitoring Plug-in capability for custom GUI Sensor node control based on GUI Database Application platform WSN platform
NanoMon
MOTE-VIEW
SpyGlass
O
X
X
O
O
O
X
O
X
MySQL Platform independent (implemented in Java) .Nano-24(NanoQplus) .ETRI-SSN(NanoQplus) .MicaZ(NanoQplus)
TinyDB Windows XP & 2000 Mica-series [6] (TinyOS)
None Platform independent (implemented in Java) Mica-series (TinyOS)
Notes
Future work
We will test NanoMon with various WSN platforms in near future.
O: supportable, X: unsupportable Table 1. Capability comparison among monitoring tools and some of above tools which is similar to NanoMon. NanoMon can manage and visualize multiple sensor network information such as history of received sensing data and network topology using MySQL databases. All tools listed in the Table 1 provide plug-in capability for GUI extension, but only our tool provides easy GUI extension method such as a configuration file. NanoMon and SpyGlass are implemented in Java language to offer platform independence. Additionally, NanoMon provides well-defined packet format to connect with sink nodes or other monitoring devices.
Figure 1. Sensor network monitoring framework of NanoMon
3. Sensor Network Monitoring Framework Sensor network monitoring framework of NanoMon is composed of following four functional parts. Figure 1 shows how these parts are interconnected with each other. • Wireless sensor networks • Monitoring server • Databases • Monitoring clients A wireless sensor network includes micro-sensor nodes loading sensor OS (e.g. NanoQplus [7] [8]), sensor applications and routing facilities, and a sink node. Environment information generated by sensor nodes is forwarded to a designated sink node. Each sink node sends collected data and topology information to a monitoring server (e.g. NanoMon). After the monitoring server receives the sensor network data from sink nodes, it filters, arranges and displays them
in turn. And then it transmits data to a database server via TCP /IP network to store them. The monitoring server can also forward sensor data to monitoring clients connected via TCP/IP. In our implementation, we defined XML packet formats for sending sensor data to monitoring clients. The database is a data storage saving sensor data, network topology, etc. We use MySQL [9] as a database manager. Monitoring clients are computer programs(e.g. NanoMon) utilizing sensor data and topology information of a sensor network received from monitoring servers (NanoMon). Monitoring clients and monitoring servers communicate each other through TCP/IP network. When past data related with a sensor network is requested by users, a monitoring client connects to its database server via TCP/IP network and retrieves those data from it.
4. NanoMon Architecture Minimum components of NanoMon are one configuration file, essential five software modules and a database. Users can set GUI components, sensor related information, the database information and connection information to sensor networks just by writing a configuration file. Each software module reads specific parts of the configuration file dedicated to it and adjusts its appearances or creates internal parameters according to them.
4.1. Configuration file A NanoMon configuration file can contain module settings of several sensor network applications to make all of their connections and environment settings to NanoMon at once. Module settings of a specific sensor network application split into four parts: GUI setting part, sensor setting part, database setting part and connection setting part. GUI setting part includes names of plug-in components which will be integrated into the GUI framework when a user selects a specific sensor network application. Sensor setting part includes sensor related information such as names and identifiers of sensor types, measurement units and calibration classes of sensor data used in the sensor network application. Sensor identifiers are numbers to identify sensor types used in the packets received from a sensor network. A calibration class is used to convert sensor readings of a specific sensor to universal engineering units. Database setting part includes database location and user information (user id and password). Connection setting part includes connection type between NanoMon and a sensor network such as RS-232 serial data communication protocol or TCP/IP with their specific parameters. Figure 2 shows the structure of NanoMon configuration file and its example.
Figure 2. Structure of NanoMon configuration file and its example
Figure 3. Software architecture
4.2. Software Architecture NanoMon is composed of five software modules GUI integration module, sensor network abstraction module, packet processing module, data management module and connection module. Users can flexibly scale and change the operation of NanoMon according to its specialized sensor network application requirements by using the configuration file. Figure 3 shows the software architecture of NanoMon and its constituting modules. • Connection Module connects NanoMon with sensor network via serial data transmission protocols or TCP/IP as specified in the connection setting part of the configuration file. After connection is successfully established, this module forwards received packets from wireless sensor networks to
the packet processing module. This module processes connections requests from external monitoring devices which want to receive the information generated from sensor networks connected to NanoMon. • Packet Processing Module parses packets received from the connection module according to well-defined packet formats and transmission procedures. This module also sends parsed data to data management module to store them into the database and to sensor network abstraction module to send to GUI module consequently. When external monitoring devices are connected to NanoMon via TCP/IP, this module sends parsed data to these devices in accordance with the well-defined procedure and an XML packet format through the connec-
tion module. • Data Management Module defines and implements data access interfaces so as to write/read sensor node data to/from the storage specified in the database setting part of the configuration file. All the other modules can access the storage using these data access interfaces. NanoMon provides sensor data history and conditional sensor data searching functions by using this module. • Sensor Network Abstraction Module contains information of sensors, nodes, connections between nodes and its data used in the GUI integration module. If user sets receiving mode to ”live mode” in GUI framework, this module provides current sensor network status and the most recent data from sensor nodes, otherwise it contains the past status and data generated for specified period. This module reads the sensor setting parts of the configuration file and then creates sensor objects dynamically and integrates calibration classes. • GUI Integration Module creates GUI framework and integrates GUI plug-ins specified in the configuration file into the framework. Users can add and remove plug-ins freely at their needs. Plug-ins can use interfaces provided by a sensor network abstraction module to access information of a sensor network connected with NanoMon. NanoMon basically provides below plug-ins.
5.1. Transmission procedure Figure 4 shows the packets used to send information and the transmission procedure between a sink and NanoMon. When NanoMon wants to receive information such as sensing data, its network topology and remaining battery volume of constituting sensor nodes from a sensor network, it starts the procedure by sending a MON REQ packet. After receiving the request from NanoMon, the sink node starts to send packets containing WSN information (WSN INFO, WSN DATA, WSN BATTERY) to NanoMon. WSN INFO packet contains sensor network’s topology information such as existing sensor nodes, attached sensor types and parent nodes of them. When the topology of a sensor network has changed, its sink node sends a WSN INFOMS packet including the revised topology information. WSN DATAMS packets include sensing data collected from sensor nodes in a WSN. Sink nodes send this type of packets to NanoMon periodically or immediately. A WSN DATAMS packet contains node IDs, sensor types and sensing data. Sensor nodes periodically send battery volume to sink node. And sink nodes send collected battery values to NanoMon using WSN BATTERY packets. If NanoMon doesn’t want to receive sensor network information or ends execution, it sends a MON CLOSE packet to connected sink nodes.
– Topology plug-in visualizes sensor nodes and connections between them. – Sensor data plug-in displays accurate sensing value from sensor nodes and data reception time. This plug-in also provides interfaces for searching particular sensor data according to input conditions. – Chart plug-in visualizes sensor data using the various types of charts such as line chart, bar chart, and so on. User can dynamically add and remove user-defined charts. – Sensor list plug-in displays live sensor nodes and their detailed information such as battery volume, install location, ID, nick name, last sensing value and etc.
5. Communication Protocol with Sink Nodes NanoMon provides well-defined packet format and packet transmission procedure to sink nodes so as to offer sensor network platform independency to users. NanoMon uses binary packets to communicate with sink nodes.
Figure 4. Transmission procedure
5.2. Packet format Figure 5 shows packets and their format used to transfer the information of sensor networks or inform the status (start and close) of a monitoring application. Figure 5-(a) shows the common format of packets used in the NanoMon monitoring framework. All packets must include node ID of a sender and packet type identifier. Figure 5-(b) shows the packets from sink nodes to NanoMon. WSN INFOMS packets include information of sensor nodes composing a specific sensor network
such as total number of nodes, each node’s ID, node’s parent node ID and sensor types of nodes. Sink nodes transmit WSN DATAMS packets to send collected sensing data from sensor nodes. These packets include sensor node’s IDs, sensor types and sensing data. WSN BATTERY packets are used to inform battery volume and live state of sensor nodes periodically. WSN BATTERY includes nodes IDs and battery volume. Figure 5-(c) shows the packets from NanoMon to sink nodes. MON REQ and MON CLOSE packets just inform the starting and closing of NanoMon application to sink nodes. These packets include no data field.
6.1. Home monitoring system First, we built a home monitoring system which can collect environmental information of home like temperature, humidity, states of lighting, gas leakage and movement of objects. WSN is comprised of a sink node and seven sensor nodes. Five of sensor nodes are attaching integrated sensor board and the others are attaching infrared ray sensors. Figure 6 shows the configuration file of home monitoring system which specifies sensor information (e.g. types, identifiers, measurement units and calibration classes), plug-in GUI modules, communication protocol between sink node and NanoMon and database information.
Figure 6. Home monitoring system
Figure 5. Packet formats
Figure 7 shows home monitoring system maed of a WSN for environment sensing of home, a sink node collecting sensed information from sensor nodes and NanoMon configured using the above configuration file.
6. Sensor Network Monitoring System Examples We applied NanoMon to two sensor network applications - home monitoring system and parking lot monitoring system. Each system has several sensor nodes, a sink node and NanoMon. Sensor nodes send sensing data and battery volume to a sink node through RF communication. A sink node sends received data and connection information between sensor nodes to NanoMon using serial communication. We used ETRI-SSN and Nano-24[8] board as sensor nodes and NanoQplus as sensor node’s OS. ETRI-SSN and Nano-24 board can attach several sensors (or sensor boards) such as temperature, light, humidity, gas, infrared rays and ultrasonic sensors. Temperature, light, humidity and gas sensors are integrated into one sensor board which is called integrated sensor board.
Figure 7. Home monitoring system
6.2. Parking lot monitoring system Second, we built a parking lot monitoring system which shows the empty spaces of parking lot. WSN is comprised of ten sensor nodes attaching infrared ray sensor and a sink node. When a car enters a parking space, installed sensor node in this space sends information to the sink node. The sink node forwards this information to NanoMon immediately, and NanoMon displays the total number and position of empty spaces.
We added settings of NanoMon for parking lot monitoring system to the configuration file of home monitoring system to concurrently monitor(manage) two systems using one NanoMon application. Figure 8 shows the configuration file including settings of home monitoring system and parking lot monitoring system.
Figure 8. Configuration file of parking lot monitoring system
7. Conclusion and perspectives NanoMon provides configuration files for users to set GUI, database, sensor types and desired connection protocol to connect sensor network applications to NanoMon. Users can easily change external appearances as well as internal modules of NanoMon into more adequate forms to interpret the status and data of sensor networks according to their own sensor network applications. The multiple connections support capability of NanoMon to sensor networks and their designated database enables users to switch among several sensor networks and observe current and past status of them. We designed well-defined packet format and transmission procedure so that NanoMon can connect with various sensor network platforms. Currently, we completed the implementation and testing. Testing was performed with real sensor nodes embedding Nano-Qplus platform and its applications. We have a plan to publish NanoMon with Nano-Qplus package. In the near future, we are going to test NanoMon with real sensor network applications composed of a lot of sensor nodes and reinforce its ability by adding sensor network management functions such as remote management of sensor nodes, network performance monitoring functions and so forth.
References Figure 9 shows parking lot monitoring system having sensor nodes for recognizing empty or full spaces of parking lot, a sink node collecting parking lot information from sensor nodes and NanoMon configured using the above configuration file. NanoMon can connect with any of sensor network specified in the configuration file, and monitor current status of selected WSN. We selected parking lot monitoring system in Figure 9 using the upper right combo box of NanoMon. When we select another WSN, NanoMon changes its appearances (plug-in GUI components) and internal parameters (sensor types of WSN, serial parameters for connection with a sink node and etc.) dynamically.
Figure 9. Home monitoring system
[1] T. M., “Mote-view: A sensor network monitoring and management tool,” in proceedings of the 2nd IEEE workshop on embedded Networked Sensors (EmNetS-II), May 2005. [2] Crossbow Technology Inc., “Surge network viewer.” http://www.xbow.com/Products/Products/productsdetails.aspx?sid=86. [3] C. Buschmann, D. Pfisterer, and S. Fischer, “Spyglass: A wireless sensor network visualizer,” in ACM SIGBED review, vol. 2, Jan. 2005. [4] UC Berkeley, “Tinyos.” http://www.tinyos.net. [5] P. Levis, N. Lee, M. Welsh, and D. Culler, “Tossim: accurate and scalable simulation of entire tinyos applications,” in proceedings of the 1st international conference on embedded networked sensor systems, pp. 126–137, 2003. [6] C. T. Inc., “Mica2mote.” http://www.xbow.com. [7] E. S. research Division of ETRI, “Nanoqplus.” http://qplus.or.kr. [8] K. Lee, Y. Shin, H. Choi, and S. Park, “A design of sensor network system based on scalable and reconfigurable nano-os platform,” in IT-Soc International Conference, 2004. [9] M. AB., “Mysql.” http://www.mysql.com/.
