Networking & Communications

Building Large-Scale ZigBee Systems with Web Services

May 1, 2005 By: Tim Enwall, Venkat Bahl Sensors

Web services promise to help developers create applications for large sensor networks.

Creating applications for large, diverse sensor networks is difficult due to the volume and varying longevity and dynamics of the sensor nodes. When node volume and sensor/actuator diversity increases, the complexity of the entire system increases exponentially. While standards such as ZigBee address the need for an industry-driven open standard, they don't define the tools required to build these systems.

As a result, developers of large sensor networks face investing dozens of man-years into developing common "foundational" software services that are unrelated to the application they seek to build. They are forced to code services to access groups of sensor nodes, manage and aggregate data, build abstractions to represent those node groups, build event-driven rules, and simulate the network's behavior.

Web services are a way to solve this problem. Developers can tap Web service "brokers" to provide the network discovery, extraction, commissioning, configuration, management, security, event/rule logic, and data management functions for large, diverse ZigBee systems. Rather than having to learn embedded/network programming skills or master the intricacies of the ZigBee networking stack, the developers can quickly build applications in familiar, higher-level languages such as Java or C++, using Web services or native interfaces to automatically extract and manage data transactions across the ZigBee network.

Making the Case

As ZigBee adoption accelerates (see "ZigBee's Next Steps, and Figure 1), users will face systems of a hundred to a thousand nodes. How do you interface with such a system, where each of the thousand nodes lacks any form of user interface? How do you control them?

 Figure 1. ZigBee is the only standards-based wireless technology that addresses the unique needs of low-power, low-data-rate networks for remote monitoring and control.
Figure 1. ZigBee is the only standards-based wireless technology that addresses the unique needs of low-power, low-data-rate networks for remote monitoring and control.

Consider the example of a large shipping company using a large ZigBee-based sensor network to detect all sorts of environmental data on a cargo ship and to control various equipment. The system would require hundreds of highly constrained sensor and control nodes creating self-forming, self-healing, and self-coordinating networks. You'd need vibration and stress-sensing sensors attached to the hull to monitor structural integrity, cracking, and stress; vibration and temperature sensors on the equipment in the engine room; temperature and humidity sensors connected throughout the ship to check overall conditions for both personnel and equipment; and accelerometers attached to the hull to detect normal and extreme movements. You'd need fan controls to monitor the ship's ventilation system; motor and valve controls attached to almost all engine room equipment and in other critical machine rooms; fuel and energy supply valve controls to restrict fuel flow in case of dangerous conditions; and RFID and other tracking sensors on each cargo container to monitor movement, internal/external temperature, and tampering.

The developer just wants to write an interface program for the ship's maintenance people, engineers, captain, and other company personnel. Let's say that the acceleration sensors on the left-hand side of the ship have exceeded a threshold, indicating stormy seas or dangerous situations. The application the developer wants to write would send broadcast control messages to the engine room equipment to put it into "safe" mode and close down the fuel supply valves until given an "all clear" message. The latter message is most likely an application-generated event from data gathered by the hull acceleration sensors.

It would be unwieldy for a developer to write a program that places C code on each sensor. Let's continue with our hull sensor example. Addressing (not to mention authenticating and registering) the 50 or so hull acceleration sensors, managing messages to the group, aggregating data, and performing calculations to detect abnormal behavior, in addition to triggering control events to a larger group of sensor nodes promises enormous complexity and development overhead for the developer. After all, he or she just wants to perform a series of safety maneuvers in the event of rough seas.

1 2 3 4 

Add Comment


Sensors 2017 Call for Speakers



Twitter Feed

Find It Fix It Forum

Sensors invites you to join the Findit-Fixit Forum, where you can get answers to your sensing questions—concerning technologies, products, methods, applications, and services--and also offer help to your fellow engineers. The Forum covers all kinds of topics, from the basics to the extraordinary.

Join the discussion!

© Copyright 2016 Questex, LLC. All Rights Reserved. Sensorsmag. Privacy Policy | Terms of Use

If you are having technical difficulties or considerations, please contact the webmaster.