Wireless Sensor Networks: Programming Reactions

Nicholas J. LarsonSoftware Engineering

University of Wisconsin-Plattevillelarsonn@uwplatt.edu

Abstract

The use of wireless sensor network is endless when it comes to monitoring environmental phenomena. With the use of many wireless nodes and communication from nodes to receivers, vast amounts of data can be stored and analyzed. Wireless sensor networks have many applications that are still in use today like wildlife monitoring systems, forest fire detection systems, home security systems and many more. This document will cover the basics of what is a wireless sensor network, step into a brief military based history of wireless sensor networks, a possible application pattern, common hardware these networks are used with, possible operating systems used in the design of wireless sensor networks, and details on one macro programmer that helps set up and design wireless sensor networks.

Introduction

Many designers have tried to create devices that will react to the world as it changes. A fast growing area of research involves Wireless Sensor Networks (WSN). WSNs are typically composed of embedded devices with sensors and/or actuators, a processing unit, and a wireless communication interface. These actuators allow for a physical action to be taken at the location of use. One example of an actuator would be a sprinkler for a fire extinguishing system which would only be turned on only after a fire is detected. Many of the newer designs use tiny battery operated components to achieve more mobile devices. These components provide cheap and intricate interactions with the environment.

Although the idea of WSNs has been around for quite some time, very few deployed applications utilize high-level programming. High-level programming would be programing in a language that is similar to human language but is interpreted and converted into a machine language that is known by your specific hardware. Not many interpreters have been designed specifically for wireless sensor networks that would take the burden of knowing the hardware and specific

2

machine languages for the devices off the programmer. Much of the importance lies in the hardware and proper software platforms are necessary for application developers. Most of the time, programmers were forced into dealing with low-level system issues and with the design of distributed protocols due to programming being carried out very close to the operating system [6].

History

During the Cold War, Untied States Navy had trouble locating soviet submarines due to the lack of visibility underwater. They found that using an underwater acoustic sound microphone, hydrophone, they were able to hear when a submarine was near. They created a mesh of connected hydrophones called the Sound Surveillance System (SOSUS) to locate these submarines which is considered one of the first large scale sensor networks. This system is still in use today [7].

In the 1980s, the Defense Advanced Research Projects Agency (DARPA) researched into using Arpanet, the predecessor to the current internet, to communicate between nodes. The idea was to use this form of communication to allow many low cost sensing nodes to be distributed over a much larger area with each node operating autonomously using this form of communication as a central processor deciding where the information collected is best used [2].

Near the end of 1980, more universities started getting involved into the research. Massachusetts Institute of Technology (MIT) used the same idea of using acoustic sensors, but applied the idea to tracking a helicopter. Before this point, sensor networks meant for tracking were only used to locate and collect data for a single target. The algorithms MIT was using were meant for the single target and would fail to detect or give false detections if multiple targets entered the sensing region. During this time, Advanced Decision Systems, a company based in California, created a multiple-hypothesis algorithm to locate multiple targets more effectively [2]. MIT was able to use this multiple-hypothesis algorithm to correct the vast amount of incorrect readings.

Previously the United States Navy used radar and on ship sensors to track air born targets, but in the late 1980s and early 1990s under the Cooperative Engagement Capability, the Navy deployed a new system that used the sensed data from other nearby vessels in order to produce a clearer image of the target [2, 8]. This communication between the vessels extended the range that the naval vessels could detect and engage from.

In the early 2000s, DARPA started a new program, SensIT, which developed software for networks using micro-sensors. This software was designed to create ad-hoc connections with the sensors no matter how many sensors are active. These sensors were made to be small, cheap, and

3

disposable leaving many sensors to be dead on arrival or even flicker on and off during use. This was considered one of the first distributed wireless self-contained sensor networks [5]. These new developments lead to many of today’s systems like in tornado wind data collection systems and wildlife monitoring systems.

Application Pattern

WSNs today are being implemented in a variety of different ways, using many different techniques. Many of them can be simplified and condensed into a single model that covers the majority of their designs’ common traits. In my research, I found that Mottola and Picco provide one graphical depiction of WSN applications, shown in Figure 1, which seems to cover the vast spectrum of applications pretty well.

Figure 1: Mottola’s and Picco’s taxonomy of WSN applications.

Using this model, WSN applications can be broken into five separate sections. Each section has its own decisions to be made in order to produce the application that best fits the desired scenario.

Goal

The goal of an application can be broken down into either a sense-only design or a sense-and-react design. The goal most commonly involves data being retrieved from nodes, which are typically set up with a sensor and/or an actuator, and stored for later data analysis. Sense-only designs are used mostly in situations where readings are taken at each node and stored in a database or in memory normally at a single central base station. Sense-and-react designs are

4

much more complex once actuators are involved. They can still use a single central data sink like that of a sense-only design to handle the data processing and interpretation but also issue commands to the actuators. However, energy consumption and latency increase as the number of processing nodes increases. To reduce the energy consumption and latency or time need to carry out the process, it is recommended that the processing be done at nodes as close to the central node as the design can allow, thus putting heavier loads on just a few nodes instead of many. Sense-and-react patterns also result in very different architectures due to the sensing nodes now having to communicate with possibly more than one receiver. These receivers ordinarily are another sensing node or a data collection sink.

Interaction Pattern

Interaction patterns describe how the nodes communicate with others in the network. The goal of the application plays a vital role in how the nodes will communicate. Many of sense-only patterns use a many-to-one pattern where many nodes relay their collected data to just a single location. Sense-and-react patterns usually use a one-to-many or even a many-to-many pattern to allow their reactions to change where they send the collected data based on the changing configuration commands. One-to-many and many-to-many patterns are usually used in situations where there are multiple data collection sinks.

Mobility

Applications can use varying degrees of dynamism to achieve their desired pattern and extend their lifetime. Static applications refer to applications where once deployed, neither the nodes nor the sinks move or change. Applications that have mobile entities use mobile nodes to achieve data collection from the moving entities. This is most commonly used in tracking and monitoring wildlife. Mobile sinks on the other hand utilize the aspect of data collection based on proximity or opportunity. This is mostly used in situations where one collection point would be expensive in either distance or work load; another sink can take the load with less expense.

Space and Time

Depending on the monitored entity, the time at which collection is needed and the physical space covered changes. The processing required determines the applications time and space.

5

The space in which processing is distributed can be broken down into global or regional. In global applications, the processing is done over the network as a whole whereas in regional applications, the majority of the processing is done in some limited area of the network.

Time can be distilled into two categories as well: periodic and event-triggered. Periodic applications are designed to pull sensor data at regular intervals and process data continuously. Event-triggered applications can be done in two phases. First, during event detection, the nodes sample the environment with little or no communication due to the levels being below threshold. Second, when values sampled rise above thresholds, processing begins.

Plotting space and time on a single graph, real-life examples of each can be placed at each cross section. Figure 2 represents possible examples [6].

Figure 2: A graph of space and time with examples of WSN applications.

Hardware

Many different platforms exist and many different companies supply a plethora of products to choose from. Many of the platforms use MSP430, which is a 16-bit Texas Instruments micro-controller, or Atmel’s ATMega family 8/16-bit chip. Other micro-controllers like Intel PXA or ARM920T become more popular when looking at more powerful chips for more intense systems. Volatile memory usually stays below 512 KB and dedicated binary program memory stays below 128 KB but nodes frequently are equipped with larger external storage devices

6

which can store many gigabytes of data [6]. Communication is typically done in the 2.4 GHz ISM band and use IEEE 802.15.4 compliance [1]. Other possible solutions use the alternative 868/916 MHz band or rely on Bluetooth for small radius communications. Figure 3 shows one possible layout.

Figure 3: High-level example of node hardware in a WSN.

Operating System

WSN applications typically use very small primitive operating systems that commonly use a C based language. Two common operating systems used by wireless sensor networks today are nesC and TinyOS. These systems would be similar in size to that of a library used in mainstream computing program [6]. When working with small embedded devices with very limited memory, you need to keep your operating system and code non-cumbersome. If the operating system takes up too much of the memory, it can force developers into not using the full potential of the sensing nodes due to lack of memory space to hold code needed to fully utilize the node. Not many operating systems allow for dynamic linking which is very useful in supporting wireless reprogramming of the WSN. In some deployed WSNs, a change in the operating code might be needed and allowing for dynamic linking will allow this change to be pushed to all the nodes creating a simple way to update a system on the go. Many applications will use middleware software to help implement the application. Middleware software is software designed to provide services for a specific need. The operating systems only offer some services and middleware software will provide these services other than what the operating system can offer alone.

7

Kairos

Kairos is known as a common macro programmer used in applications based in wireless sensor networks. It only limitedly supports scalability, openness, and power awareness due to not having full control of underlying resources, but it does fully address the idea of mobility by providing code used for node localization and routing [4].

Kairos uses a Python based language with much of the base services already constructed. A lot of the functions and services are pre-defined and many of the functions that are common across WSNs are provided. Figure 4 is a snippet of code used to build a shortest-path tree of the current active nodes [3]. In line 6 you will see that the system only pulls all the active nodes and for each node in that set it will calculate its distance from root on lines 7 through 12. Lines 14 through 20 there is a loop that will wait for an event and update based on the event.

Figure 4: Code to build the shortest-path tree.

Another selection of code Kairos offers is for the localization of nodes. Figure 5 shows how Kairos uses a bottom up approach to start with a node and extend its node graph if it is within the sub-graph (line 12). If it cannot place the node into that localized group, it will check to see if it is a neighbor and extend the localization if it is within one hop of the previous collection.

8

Figure 5: Code for localization of nodes using bottom-up.

Kairos uses node synchronization to improve its reliability for shared data between connected nodes. The use of the synchronized nodes enables assurance that the data will not be corrupted by multiple nodes changing data at the same time and space [3].

Using provided code like the examples above helps take the burden of designing and rewriting common functions of wireless sensor networks off of the programmers shoulders. For those just getting started in wireless sensor networks will find software like Kairos very useful. The services the middleware programs provide dramatically lessen the learning curve.

References

[1] Baronti, P., Pillai, P., Chook, V. W., Chessa, S., Gotta, A., & Hu, Y. F. (2007). Wireless sensor networks: A survey on the state of the art and the 802.15. 4 and ZigBee standards. Computer communications, 30(7), 1655-1695.

[2] Chong, C. Y., & Kumar, S. P. (2003). Sensor networks: evolution, opportunities, and challenges. Proceedings of the IEEE, 91(8), 1247-1256.

9

[3] Gummadi, R., Gnawali, O., & Govindan, R. (2005). Macro-programming wireless sensor networks using kairos. Distributed Computing in Sensor Systems, 466-466.

[4] Hadim, S., & Mohamed, N. (2006). Middleware: Middleware challenges and approaches for wireless sensor networks. Distributed Systems Online, IEEE, 7(3), 1-1.

[5] Kumar, S., & Shepherd, D. (2001, August). SensIT: Sensor information technology for the warfighter. In Proc. 4th Int. Conf. on Information Fusion.

[6] Mottola, L., & Picco, G. P. (2011). Programming wireless sensor networks: Fundamental concepts and state of the art. ACM Computing Surveys (CSUR), 43(3), 19.

[7] Nishimura, C. E., & Conlon, D. M. (1994). IUSS dual use: Monitoring whales and earthquakes using SOSUS. Marine Technology Society Journal, 27, 13-13.

[8] O'Neil, W. D. (2007). The Cooperative Engagement Capability" CEC" Transforming Naval Anti-air Warfare (No. NDU/CTNSP-CS-11). NATIONAL DEFENSE UNIV WASHINGTON DC CENTER FOR TECHNOLOGY AND NATIONAL SECURITY POLICY.