The ZigBee standard is a superset of the 802.15.4 standard. In other words, a ZigBee-certified application must conform to both the ZigBee standard and the 802.15.4 standard, while an 802.15.4 application may or may not adhere to the ZigBee standard. The distinction is important because an 802.15.4 network is simpler to implement than a ZigBee network, and because the 802.15.4 standard is complete, while the ZigBee standard continues to evolve. Some of ZigBee's higher-level application layers have not even been defined yet. Thus, any application that must be deployed now will probably have to be deployed as an 802.15.4 network, with ZigBee capability added later when the profile for the application has been ratified.

IEEE 802.15.4 covers the basic RF part of the network: the physical layer and the media access control layer. ZigBee covers the network layer, application framework and application profiles. The application framework and profiles provide specifications at the application level that guarantee interoperability between equipment from different vendors. In addition, the ZigBee network layer specification defines networking topologies, specifically "mesh" networks. Network Topologies There are several types of network configurations that can be implemented under the 802.15.4 and ZigBee umbrella: point-to-multipoint (star) networks, tree networks and mesh networks.

Mesh networks represent the highest level of 802.15.4/ZigBee configuration and require the most network level code. Mesh networks route data dynamically creating the most efficient path among a multiple of network nodes. The ability to route data among multiple paths provides mesh networks with a "self healing" capability. If a node in the path fails for any reason, the network identifies a new path using other nodes. This capability makes mesh networks ideal for large building control systems or wide area sensing. Mesh networks are by far the most difficult 802.15.4/ZigBee networks to design and implement. Building a mesh network from scratch is a complex process. Since mesh networking is defined as part of the ZigBee network layer specification, anyone wanting to deploy a mesh network should stick with the ZigBee standard. (Figure 2 " ZigBee Mesh Network) If the application does not require a "mesh" networking capability or does not need interoperability with equipment from other vendors, ZigBee may not be necessary. In the case of industrial control systems, interoperability may actually be a disadvantage that compromises network security. Since the vast majority of industrial control systems can be accommodated using a simpler tree network, developers may prefer to go with 802.15.4 and a proprietary network layer, rather than waiting for the ZigBee standard to be ratified.

Network Integration In most wireless networking applications, such a wireless LAN, WiFI, Bluetooth, etc, the network is the primary application. In industrial control, the primary application is some kind of process or flow control application. The network is the vehicle by which the processes and equipment communicate. When deploying ZigBee or 802.15.4 functionality in an industrial control system, two separate applications must be developed in parallel: the primary control application and the supporting networking application. Most industrial control engineers are not, and should not have to become RF experts in order to add 802.15.4 functionality to their systems. Fortunately, most 802.15.4 vendors, including Atmel, TI, Freescale, Jennic and Ember, offer fairly complete system-level solutions that already integrate the radio, controller, collateral software and development tools. The designer does not have to become an RF expert. Single-chip, Chipset, or Multi-vendor Solution
ZigBee/IEEE 802.15.4 applications have a variety of node types that range from full-functioned devices (FFDs) that serve as gateways and system controllers to reduced function devices (RFDs) that include a switch or a sensor. A full function device may execute application layer software, as well as network and security layer software. A reduced function device will execute limited functionality, such as sensing, polling the other radios in the network and/or turning a switch on or off. Different nodes will require varying amounts of processing and will have different code and data storage requirements.

Vendors of 802.15.4/ZigBee ICs offer a wide range of options, from radios and controllers, to media access control (MAC) stacks and network or application layer software. They may offer a completely integrated solution or they may offer individual ICs that the OEM can integrate on his/her own. There are lots of choices and it can be pretty confusing if you're not an expert in 802.15.4 networking.

For most designers it is advisable to choose a system-level solution from a single vendor that minimally includes the radio, controller and MAC, with all interfaces taken care of. This approach will vastly simplify product development and will give engineers much more freedom to focus on the industrial control application.

Among these system level solutions, both single-chip and chip set implementations are available. A single chip solution integrates both the radio and the controller in a single package, simplifying the design somewhat and allowing a smaller footprint. However, single-chip solutions available today offer limited flexibility, particularly in terms of on-chip memory densities. Designers should take a hard look at the memory densities of single-chip solutions to ensure there is enough on-chip memory to accommodate the applications code, software stacks needed on the full function devices. Some vendors of single-chip 802.15.4 solutions offer as much as 128 KBytes of flash memory. However, others only offer between 8- and 32-KBytes of on-chip flash. A fully featured 802.15.4 MAC can require 20- to 30-KBytes of memory. Single chip solutions with smaller memories may not have enough program storage to implement the 802.15.4 stack, plus the ZigBee stacks, plus that of the industrial control application. In this situation external memories may be needed, which will increase design complexity, cost and power consumption. It will also remove the original advantage of a single chip solution.

Even if the embedded controller has enough flash memory for the first generation design, it may not offer a migration path to devices with bigger memories to accommodate the addition of new, software-based features. It is equally as important to have the option to reducing costs by using a controller with less memory and fewer peripherals.

It is important to have the flexibility to handle a fairly wide range of processing and program storage requirements of the various node types at the lowest possible system cost. A gateway node that also executes the main industrial control application may need 128 KB or even 256 KB of flash memory. If program upgrades are done "over the air" using the wireless network, twice the memory density will be required to 1) execute the application from during the update and 2) store the new code. On the other hand, an end-node with just a sensor or switch on it will execute a minimal amount of code and will require very little memory. A low cost controller with a relatively small memory may be sufficient. Until single-chip ZigBee/802.15.4 solutions offer a wider range of memory densities and peripherals, it may be wise to use a chip set with stand alone MCU plus radio. Chipsets are available that offer the same "plug-and-play" 802.15.4 functionality as a single-chip solution, but also offer the flexibility to choose from a variety of MCUs with flash densities that range from 64- to 256 KB.

The 802.15.4/ZigBee market is in its infancy. Nobody knows yet, which applications will get volume traction in the market or how those applications will evolve. There are probably dozens of applications that no one has even imagined. Therefore, at present, it makes sense to design an application with a discrete radio coupled with a family of microcontrollers that provides the flexibility to let applications evolve as the market evolves.

Author Bio: Chris Baumann is Director of Atmel'sBiCMOS Products business unit. Before joining Atmel in 1989, he worked at Texas Instruments and Honeywell. Mr. Baumann received his B.S. degree in Electrical Engineering and his M.S.E.E. degree from the University of Notre Dame. cbaumann@cso.atmel.com