This article looks at the challenges of implementing control loops with a wireless sensor network. It looks at the latency requirements of different closed and open control loop architectures and the wireless network protocols that can support them.
While Wi-Fi can be used with embedded modules such as Microchip’s MRF24WB0MB, recent protocols such as ISA100a and WirelessHART™ aim to provide more focused support for control loops within wireless networks. Devices such as Atmel’s AT86RF231, NXP’s JN5148 and Silicon Labs’ EM357 that already support the IEEE802.15.4 ZigBee standard can be used to support these later protocols and customized versions for tight control loops.
Unlike traditional control systems that have dedicated coaxial wires between sensors, actuators and the centralized controller, a control system adopting wireless communications requires sensors, and controllers to share a common wireless medium for communication. When a closed-loop control system is implemented using a common communication system, the quality of the network is a vital part of the performance of the overall system. Time delays that in many systems are not important can become critical in real time closed loop systems.
The problem is that traditional short-range wireless network standards such as IEEE 802.11 Wi-Fi and IEEE 802.15.4 ZigBee do not consider packets according to their delay deadlines and treat the packets all the same regardless of these requirements. This presents a major issue for a closed loop control system where the data from the sensors is used to control the actuators that influence the process. Delays in the data can lead to negative reinforcement so that a process can run away rather than be kept within close limits.
This is different from an open loop system where the data is fed back to a central controller, analyzed with changes made in the order of seconds or even minutes. This is used for slowly changing processes or situations where the process falls outside its limits and can easily be brought back or the process terminated.
One way around this is to have an application using the wireless medium that associates each packet with a delay requirement. Mechanisms such as ER (Early Retirement) and PHY+ use the deadline associated with each packet for further transmission and redundancy optimization. Simulation of Wireless Sensor Networks using the IEEE 802.15.4 standard showed that these mechanisms outperform the original standard considerably, especially in situations where high numbers of users exist in the system.
Other standards have emerged to try to tackle this problem, with researchers looking at how the IP technology of the wider Internet can be used to provide deterministic control loops in wireless networks.
This is becoming more important with the increasing use of machine-to-machine (M2M) applications. M2M covers a wide range of applications but in a typical scenario, a sensor detects an anomaly, sends an alert to monitoring middleware which in turn generates a command to an actuator, informs a business operation software application, and eventually sends an alarm to an operator off the loop.
Scalability is critical for M2M. Soon, billions of sensor devices might be deployed to provide remote monitoring of houses, buildings, patient vital signs, physical security, and any number of new applications enabled by the falling price of the technology. All of this has an impact on the delays in the wireless network and the effectiveness of the control loop.
The new IPv6 Internet Protocol is providing a way forward. While the older IPv4 technology was limited by its 32-bit addresses, IPv6 was designed for scalability with an address range of 128 bits and improved mechanisms for peering and address allocation with Neighbor Discovery. It also introduces Unique Local Addresses, which can be used to isolate completely the process-control network from enterprise networks and provide a more deterministic environment to support control loops.
One way to make use of this is the additional performance of 802.11. This can give higher performance links that give more time for the control loop elements while making use of existing cost effective hardware, such as Microchip’s MRF24WB0MA Wi-Fi module. Additional customized layers can be added to the protocol stack to customize the system for particular control requirements.
Figure 1: Microchip’s MRF24WB Wi-Fi module.
This surface-mount module includes all the associated RF components from the crystal oscillator, bypass, and bias passives, with integrated MAC, baseband, RF and power amplifier, and built-in hardware support for AES, and TKIP (WEP, WPA, WPA2 security). The integrated module design frees the designer from RF and antenna design tasks and regulatory compliance testing. It is designed for use with Microchip’s TCP/IP software stack, which has an integrated driver that implements the API that is used in the modules for command and control, and for management and data packet traffic.
The Internet Engineering Task Force (IETF) has standardized IPv6 over 802.15.4 at the 6LoWPAN Working Group and the initial standard, RFC 4944, was adopted by the Instrumentation, System, and Automation Society (ISA) for its network-layer formats (see below).
The IEEE 802.15.4 standard was designed with concepts similar to 802.11, but optimized for battery savings with a typical 1 mW transmit power. This is one-hundred times less than 802.11, and enables ranges in tens of meters with low data rates of 250 kbps, 40 kbps, and 20 kbps at 2.4 GHz, 915 MHz, and 868 MHz, respectively. A key point is that the frames carrying the data are thirteen times smaller than typical Ethernet frames with a physical packet size of 127 bytes. This constrains the network, but also gives more opportunity for more deterministic control loops and mapping to other process control protocols such as WirelessHART.
Because IPv6 has a minimum frame size of 1280 bytes, 6LoWPAN has defined an adaptation layer for header compression, fragmentation and reassembly. An addressing scheme specifies an IPv6 address from a device’s IEEE 64-bit extended addresses or its 16-bit unique address in the network. However, this adds time in the protocol engine, which can be an issue in the control loop.
There is also the issue of multiple hops and mesh networking for control loops. IEEE 802.15.4 allows data to be carried from node to node to reach a gateway, allowing the network to be easily expanded. However, as the network expands this adds delays that can impact significantly on the control loop. There may also be nodes in the network that are powered by batteries or energy harvesting and may not be available at a particular time. This has to be taken into account for a control loop. The delays may be acceptable in an open loop, but a closed loop control will require a closely defined architecture with predictable timing and this often means a limited number of wireless sensor nodes.
At the moment, the multi-hop protocols in the mesh and sensor network research community are proprietary and operate at Layer 2, forming homogeneous but non-interoperable islands on the overall network to tackle this problem. This then leads to multiple overlaid sensor networks, which has to be taken into account in the overall control architecture.
The WirelessHART industrial wireless sensor networking standard was developed to address industrial applications where control loops are vital, such as critical data monitoring, calibration, device status, and diagnostics, field device troubleshooting, commissioning, and supervisory process control. WirelessHART provides robust and reliable communication using DSSS channel hopping based on IEEE std. 802.15.4, TDM, redundant data paths with mesh networking and retry mechanisms for reliability. Balancing the requirements of retry for reliability with determinism is a key challenge for developing high performance control loop systems.
The Instrumentation, System, and Automation Society (ISA) has also developed an industrial wireless standard that addresses other applications with ISA 100.11a. Like WirelessHART, this reuses and extends IEEE std. 802.15.4 2006 and uses its security part to address major industrial security threats. ISA 100.11a also extends 6LowPAN for QoS-aware relaying over multipath time-slotted meshes.
Figure 2: The ISA100a wireless industrial networking modes.
There are moves to converge both the ISA100 work and WirelessHART but this has not yet emerged. However, many 802.15.4 wireless transceivers can support ‘custom’ protocols alongside ZigBee and so can be used for either WirelessHART or ISA100a.
Atmel’s existing ATmega128RFA1 2.4 GHz transceiver for example has been extended with new memory derivatives and lower power, including the ATmega256RFR2 256K device. This integrates a number of industry-leading features including the lowest power using advanced hardware assist, best-in-class RF performance, and additional memory options to meet today’s demanding wireless requirements. Delivering less than 6 mA in listen mode, 14.5 mA in transmit mode and 1.5 μA in deep sleep mode, the transceiver offers a true 1.8 V operation at 16 MHz and a wider temperature range, up to 125°C for deployments in more demanding environments such as wireless lighting control.
Atmel’s ATmegaRFR2 family can be used with proprietary communication stacks and solutions compliant to the IEEE 802.15.4 standard such as WirelessHART and ISA100a. Atmel has already obtained 'golden units status' with the ZigBee Alliance for its new ZigBee Light Link reference implementation and can be used with ZigBee Building Automation (ZBA), or ZigBee Smart Energy (ZSE).
Similarly, the EM357 from Silicon Labs is a fully integrated System-on-Chip that integrates a 2.4 GHz, IEEE 802.15.4 compliant transceiver with a 32-bit ARM® Cortex™-M3 microprocessor, flash and RAM memory, and peripherals for designers of ZigBee-based systems.
The transceiver uses an efficient architecture that exceeds the dynamic range requirements imposed by the IEEE 802.15.4-2003 standard by over 15 dB, giving designers the option of increasing data rates to provide more headroom for the control loop. The integrated receive channel filtering allows for robust coexistence with other communication standards in the 2.4 GHz spectrum, such as IEEE 802.11-2007 and Bluetooth, minimizing the packet rejection and so improving the control loop performance. The integrated regulator, VCO, loop filter, and power amplifier keep the external component count low. An optional high performance radio mode, called boost mode, can be selected by the software to boost dynamic range.
The integrated 32-bit ARM processor supports two different modes of operation – privileged mode and user mode. This architecture could allow for separation of the networking stack from the application code, and prevents unwanted modification of restricted areas of memory and registers resulting in increased stability and reliability in the field.
Figure 3: Silicon Labs’ EM357.
To maintain the strict timing requirements imposed by the ZigBee and IEEE 802.15.4-2003 standards, the EM357 integrates a number of MAC functions, AES128 encryption accelerator, and automatic CRC handling into the hardware. The MAC hardware handles automatic ACK transmission and reception, automatic backoff delay, and clear channel assessment for transmission, as well as automatic filtering of received packets. The Ember Packet Trace Interface is also integrated with the MAC, allowing complete, non-intrusive capture of all packets to and from the device. Having these in hardware provides more headroom for the protocol handling to optimize the control loop.
JenNet is another protocol based on the IEEE 802.15.4 specification that is optimized for low power, low data-rate, cost-sensitive applications, JenNet offers a small footprint alternative to the standard based ZigBee protocol stack without fees or certification. This has been extended with the IETF 6LoWPAN network layer for JenNet-IP. This provides a self-healing, highly robust and scalable network backbone, serving wireless networks up to 500 nodes.
Figure 4: The different JenNet protocols.
The JN5148-001 from NXP is an ultra-low power, high-performance wireless microcontroller targeted at JenNet, JenNet-IP and ZigBee PRO networking applications. The device features an enhanced 32-bit RISC processor offering high coding efficiency through variable width instructions, a multistage instruction pipeline and low power operation with programmable clock speeds. It also includes a 2.4 GHz IEEE802.15.4 compliant transceiver, 128 kB of ROM, 128 kB of RAM, and a rich mix of analog and digital peripherals. The large memory footprint allows the device to run both a network stack such as ZigBee PRO and an embedded application or in a coprocessor mode, and so provides the extra space and hardware peripherals that other protocols may require. The operating current is below 18 mA, allowing operation direct from a coin cell.
Figure 5: The NXP Jn5148.
Enhanced peripherals include low-power pulse counters running in sleep mode designed for pulse counting in AMR applications and a unique Time of Flight ranging engine, allowing accurate location services to be implemented on wireless sensor networks. It also includes a 4-wire I²S audio interface, to interface directly to mainstream audio CODECs, as well as conventional MCU peripherals.
Implementing a closed control loop in a wireless sensor network is increasingly important and still challenging. The popular wireless protocols can present problems if the architecture is not carefully optimized for the particular control loop if real time performance is a key consideration. While open control loops can be handled with Wi-Fi or ZigBee protocols, there is an increasing focus on closed control loops. WirelessHART and the ISA 100a protocols are aiming to tackle these issues, but still have to converge to provide designers with a clear route forwards. Using IPv6 provides some advantages but the performance of the protocol processors has to be improved to provide the capabilities demanded for deterministic networks. At the same time researchers are exploring new ways of implementing protocols for control loops in wireless sensor networks. Fortunately, many of the devices supporting the ZigBee protocol can also support other protocols, including custom versions, allowing new approaches to control loop networks to be developed.