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. |
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.
So what can the application developer do? Typically, he or she would build and repeat the same set of foundational, common software services necessary to interact with a large ZigBee system, wasting time on nonapplication focused code.
Standards-based Web services (and Web service subvariant standards such as Web service distributed management) could provide a common set of foundational software design and run-time services and tools for the developer to draw on. These services and tools must conform to the common set of application developer paradigms (i.e., be useful to a Java, .NET, or C++ developer) and be easily integrated into popular development environments such as Eclipse, IntelliJ, or Microsoft Visual .NET. They could be deployed on a customer's Windows or Linux server as a set of libraries and tools with a run-time engine that operates on the developed software, somewhat akin to a more traditional PC application server such as BEA's WebLogic.
Web services called "service brokers" can serve as structured mechanisms to coordinate communications, such as forwarding requests from nodes to applications, nodes to nodes, and applications to nodes, as well as transmitting results and exceptions (see Figure 2). For example, Tendril Networks has developed service brokers that work with Ember's ZigBee-based wireless nodes. These service brokers provide most if not all of the system-level services developers would otherwise have to implement themselves, such as recognizing and authenticating new sensors or controls on the network, cataloging sensor capabilities, aggregating data, applying rules to the data collected, and issuing commands to controls based on those rules. This frees the application developer to focus on his or her application.
 Figure 2. The ZigBee stack architecture includes a number of layered components including the IEEE 802.15.4 medium access control (MAC) layer and physical (PHY) layer as well as the ZigBee network (NWK) layer. Each of these provides applications with its own set of services and capabilities. |
Any Web services broker should provide the following.
Abstraction. A logical abstraction layer lets developers handle the network at any level of abstraction. The model provides a virtual map of the ZigBee network and its capabilities to the developer. For example, the cargo ship has 50 acceleration nodes on its hull—25 on the port and 25 on the starboard side. The model doesn't necessarily say where the nodes are physically, just logically. Developers need to be able to work logically from a multinetwork (or subnet) level down to the node level. Abstraction essentially enables the application to operate on any Ember or other standards-based ZigBee network via a set of system adaptors.
Nodes/Network Provisioning and Extraction. To create an appropriate level of abstraction, it's necessary to extract existing capabilities from the nodes, such as health, status, bindings, routes, power levels, functional capabilities, and location, to name a few. Ideally, the cargo ship developer automatically extracts all of the functional capabilities from the different groups of nodes and focuses on connecting various nodes to application-defined parameters.
A service broker must offer a set of core services that enable discovery of the existing infrastructure and new network entries as well as protecting the network from unauthorized introduction of network components. Security will be implemented at many layers of the system, starting at the ZigBee stack (see Figure 3). A service broker will focus on application-level security using roles and permissions structures; the cargo ship system doesn't want a rogue fuel valve placed in operation without it being sanctioned. Additional core services would involve monitoring, provisioning of the nodes on the network, configuration, reprogramming the code on the node "on the fly," deployment, and authentication.
 Figure 3. The service broker provides a fundamental abstraction between the single-node or small-node device network model and a programmer-oriented data access model for larger, more diverse networks. The service broker first sets up the network model and appropriate device properties and capabilities and then exposes an event, rule, and data access layer for the data-oriented programmer. |
Rules Engine. The ZigBee standard enables multiple applications to run on large numbers of nodes/networks. It also allows you to push complex logical evaluations and executions closer to the nodes. To tap this capability, the rules engine must enable an application's complex algorithms and hierarchical processing across multiple networks. Any robust service broker must include a comprehensive, dynamic set of rules, the goal being to generate robust rules libraries to accelerate the development process. Combining network and data monitoring with the network extraction lets developers analyze potential data caching, filtering, aggregating, and routing schemes during the design process.
Data Processing. Most users won't want to permanently store all the sensor data coming from thousands of ZigBee nodes. The application must understand, manage, and optimize the data flow in the network and make that highly preprocessed data available anywhere within the enterprise. Rules-based processing can then manage, query, merge, cache, route, set triggers, match patterns, and handle bulk operations based on complex algorithms.
Simulation. Using these core services, a service broker can provide simulation capability to help developers evaluate potential application tradeoffs, coverage, and performance against either an extracted view of their actual network or a virtual network model. This differs from existing data stream simulators in that the evaluation is done from a services rather than a data stream perspective. Simulation is mandatory to guarantee functional, appropriately scaled deployments and eliminate guesswork and trial and error.
Back to Our Developer. The developer installs the service broker software on his or her favorite server platform, grabs the design libraries and network extraction modules (if a physical network is in place) or simulation modules (if no network is in place) and begins to build the application. The developer can browse the properties of various ZigBee nodes and group them by sensor or control property, all with the aid of a property inspector and property mapper.
Once the virtual model of the network has been created, the developer can build rules and business processes and aggregate data to set event triggers, trigger messages and alarms, and make the system work. By connecting the libraries and the run-time engine with a graphical user interface, the developer can deliver actual application functionality to his or her user base for testing.
Conclusion
By providing common foundational software services, Web service brokers can help developers design a system-wide application. Their services allow developers to immediately focus on application-specific material, the rules that govern the physical environment, the data aggregation and synthesis required for effective decision making, and the specific human and computer messages to be sent to achieve the desired user outcomes.
Further, if the broker's software services operate in ways familiar to the developer, e.g., using familiar interfaces, then the developer need learn only the capabilities of a ZigBee system rather than having to learn the intricacies of MEMS sensors, ZigBee mesh networking routing algorithms, wireless network reliability, node operating systems, internode networking stacks, and protocols, and fitting this all together to create the desired application.
As ZigBee networks scale into large, diverse ZigBee systems, developers naturally will turn to service brokers to help them manage the complexity of these systems and speed their application development projects to completion.
Tendril Networks is currently building its own version of a service broker, which works with Ember and other ZigBee networks. The product is currently being used by a few early adopters and will be in beta during May 2005. The initial release of the Tendril service broker includes most but not all of the services required for a large, diverse network.
ZigBee's Next Steps
Venkat Bahl, Ember Corp.
When the ZigBee specification was ratified in December 2004, it was the culmination of two years of development by more than 100 member companies. How did ratification affect the market? First, it legitimized the market opportunity; when OEMs saw that ZigBee was no longer a specification in development, they moved quickly to adopt it. In the first three months after ratification, we've seen a steady parade of OEMs announcing new ZigBee products, such as Eaton Corp. and its home awareness systems, Raymarine's wireless autopilot system, and NURI Telecom's automated meter readers.
Ratification also boosted the credibility of the ZigBee Alliance. When ratification was announced, we saw ZigBee.org Web site hits spike dramatically. The most recent ZigBee Open House conference in San Francisco drew more than 600 attendees and had 27 participating companies. The event ran parallel session tracks, one for a technical audience on network layer and architectural issues, the other focusing on helping OEMs learn what business opportunities the new specification presented.
ZigBee ratification triggered an increase in membership as well. The Alliance added a new class level of membership for companies looking to bring ZigBee-based products to market quickly. The Adopter class is designed for OEMs and system integrators who want to develop and submit their products for conformance testing, but don't want to get involved in technical contributions to the ZigBee Alliance.
The next steps for ZigBee include compliance and interoperability testing of end products. Expect to see a wave of new vendor announcements in the coming months touting official ZigBee compliance. With ratification, the specification has been pronounced stable. This means developers can now confidently work on their products without worrying that changes to the standard could impact the way their applications work. As a result, a number of OEMs have given the green light to developing applications on top of the ratified ZigBee spec.
Tim Enwall is CEO, Tendril Networks, Inc., Lafayette, CO; 303-951-4365, [email protected], www.tendrilnetworks.com.
Venkat Bahl is Vice President of Marketing, Ember Corp., Boston, MA; 617-951-1222, [email protected], www.ember. com.