•  
• EDN Europe MAGAZINE
•  
• Free SUBSCRIPTION
• Subscription Renewal
• View Media Kit

• EDN
• EDN Australia
• EDN Asia
• EDN China
• EDN Japan

Agile software empowers wireless-sensor networks

APPLICATIONS FOR WIRELESS NETWORKS CAN RANGE FROM HOME AUTOMATION TO LARGE-SCALE ENVIRONMENTAL MONITORING. WITH THE FREEDOM THESE WIRELESS APPROACHES OFFER, YOU CAN NETWORK THE TUNDRA AS EASILY AS THE OFFICE.

An effective wireless-sensor network requires the integration of two key components: lowcost, low-power, scalable hardware and manageable software. The industry has shown signs of satisfying the first need with more cost-effective microprocessors and chip sets that allow for lower power communications. A good example is the ZigBee protocol, in which devices can have a duty cycle of less than 1% and an extended battery life of as long as two years using common AA batteries. However, the industry has yet to deliver software that addresses such communications challenges as message routing, node management, and application development.

Before any application development begins, you must configure a sensor network such that nodes can communicate with each other. This step allows for coordination among the sensors as well as some supervisory host communication to the entire network. Unique challenges present themselves when such broad communication is necessary in a powersensitive environment in which battery life dictates the life of the network. This network communication can be powerintensive, and you must keep it to a minimum; the device needs to spend most of its life in a low-power sleep mode.

When most people imagine a “typical” wireless-sensor network, they think of many identical intelligent sensors communicating with each other in an ad hoc network (Figure 1). In this configuration, each node broadcasts messages to its neighbors on a defined schedule, and messages “hop” from sensor to sensor until they reach their final destination. Because these short-range broadcasts are typically easy on the power budget, this configuration is ideal for optimization of power consumption. Additionally, it requires no central control and therefore is suitable for truly self-sufficient systems. However, this configuration introduces inherent risks concerning the robustness of a network. Because each node will likely be low-cost and, in effect, disposable, you must plan for a reasonable rate of node failure within the system. In such a configuration, certain nodes can possibly emerge as gateways to large subsections of the network, and if these key nodes should fail, these same large subsections of the network will become unreachable. Although you can reasonably detect and repair these failures, many systems use wireless-sensor networks in remote locations in which simply getting to the sensor is expensive.

An alternative to the ad hoc network involves overlaying a series of higher power base stations within the network to act as master routing nodes. This configuration, a heterogeneous network, requires more power to run but offers a more maintainable architecture. Each base station represents a single point of failure, and individual sensors can go offline without affecting the rest of the network (Figure 2). This model is similar to the one that modern cellular-telephone networks use. Anyone who has experienced a dropped call in the middle of the city knows that the success of any heterogeneous network relies on the strength and placement of the base stations.

When selecting a network configuration, you must take into account the node topology. A static topology is a sensor network in which the nodes are not mobile. An example of this topology is instrumenting a redwood forest for monitoring environmental conditions. The topology naturally lends itself to an ad hoc configuration, because you can strategically place nodes to offer redundant paths to all areas of the network. In addition, although ad hoc networks would likely require a more sophisticated routing strategy, you would need to develop it only once, and it should be applicable throughout the lifetime of the project.

The alternative to a static topology is a dynamic one. In this case, node locations are not fixed, and “nearest neighbors” can change at any point. An example of this approach is a livestock-monitoring system that remotely monitors the health of a herd of cattle. At any point, any one cow could wander past the other, and the network-routing strategy would need to change accordingly. This management requires messaging, increasing network traffic and thus decreasing effective battery life.

Tracking the location of the sensors as well as the local environmental data further complicates the problem. Keeping with the earlier example in which the network is now tracking the health and position of a herd of cattle, you can use a simple survey of node-signal strength to track the location of each cow. This algorithm is relatively simple: you make assumptions about signal degradation over distance and use triangulation to derive approximate position. Because a cow pasture is a relatively open environment in which you can ignore signal reflections, this option is viable. However, examine a scenario that uses wireless sensors to track the health and position of firefighters in a burning building. The data requirements are virtually identical, but environmental factors affect the implementation approach. Because signals will likely need to travel through a variety of materials—such as glass, concrete, partition wall, and steel—when transmitted inside a building, you can no longer ignore reflections. Therefore, you can no longer consider the simple signalstrength technique to be reliable. Using this algorithm, any one node could logically be in several different locations, and resolving these conflicts can quickly become too much to manage. In these cases, a GPS (global-positioning system) is a natural fit, because it can provide precise global position. However, a GPS chip set requires a considerable increase in the power budget.

Interference is an additional concern that a wireless-software configuration must address. If wireless sensors truly become ubiquitous, it is reasonable that one network might interfere with another. For example, one could reasonably expect a home-automation system to interfere with the firefightermonitoring system. With this idea in mind, a system must exchange and maintain a unique identifier for each network. Whatever approach you develop for a network-configuration and -routing strategy, you need to scale their deployments to hundreds, thousands, and, in the future, perhaps even millions of nodes. Moore’s Law tells us that commercially available processor speeds double every 18 months. The natural corollary to Moore’s Law is that the price of processors of the same frequency decreases over time. Therefore, it becomes more and more economically viable to have an increasing number of intelligent programmable nodes in a wireless-sensor network. Programmers’ salaries are not decreasing at a parallel rate, and, therefore, addressing each of these nodes as a separate programmable entity will continue to grow more costly.

Once you’ve addressed all of the complexities of the sensor network and determined the routing, communication, and power-management strategies, you still need to complete the application programming of the network. The application software must exist on three levels: the node, the hub, and the user interface. Software on the node must manage the power consumption and provide enough data processing to minimize data transmissions. In short, the software should ensure that the network sends only the important information and discards the rest. Software on the hub must manage the communication level of the network to maximize battery life. Finally, the user interface must collect all of this information and somehow display it to a user in a way that is intuitive and meaningful (Figure 3).

treats the wireless sensor as an instrument much like an oscilloscope or a digital multimeter. This method allows engineers to abstract the complexity of application development by interacting with the network in a way that is familiar and comfortable. Major players in the wireless-sensor-network industry are addressing this need today by providing driver interfaces to software-development environments such as National Instruments’ LabView (see sidebar “A GUI makes the move from T&M to wireless-sensor networks”).

Node software involves treating the sensor network as a distributed computing cluster. When programming such systems, you develop a single application and execute it on all nodes simultaneously. You give each node some unique identifier, and the software relies on this identifier for its processing algorithm. The advantage of this approach is that, through thoughtful programming, you can write a single application that executes differently on each node, effectively giving the same flexibility of programming each node individually. This approach does, however, require a programmer to understand and apply new programming techniques and refactor or rewrite any existing applications.

AUTHOR’S BIOGRAPHY
PJ Tanzillo has worked at National Instruments for three years, where he is LabView embedded-product manager. He graduated from Ohio State University (Columbus) with a bachelor’s degree in electrical and computer engineering.

A GUI MAKES THE MOVE FROM T&M TO WIRELESS-SENSOR NETWORKS

National Instruments’ LabView is a graphical development environment that the measurement industry has used for more than 20 years. It allows engineers and scientists to rapidly and cost-effectively interface with measurement-and-control hardware, analyze data, share results, and distribute systems (Figure A). Several wireless-sensor vendors, including Crossbow Technology, Accutech, and Accsense (www.xbow.com, www. accu-tech.com, www.accsense.com), are partnering with National Instruments to create LabView drivers to connect to and program their respective wireless-sensor networks. These drivers will allow current LabView users to quickly program and integrate wireless-sensor networks in wired applications with limited or no software learning curve. Figure B shows a sample block diagram with two programs. The bottom program is written with National Instruments’ DAQmx software driver to acquire data from a wired dataacquisition device. On the other hand, the top program is reading temperature from a Crossbow wireless-sensor node. Although both are connecting to very distinct hardware technologies, the designers have created the software interface to yield a similar look and feel for the user.