Communication Considerations for Distributed Control Applications

Editor’s Note: This is the third in a series of articles (see below for links to previous articles) that uses the example of a smart irrigation project to explore the types of questions and design issues most real-world control systems need to address.

• Part 1 - Six Questions to Answer When Scoping an Arduino-Based Irrigation Project
• Part 2 - Careful Sensor Selection Ensures Desirable – and Avoids Undesirable – Outcomes
• Part 3 - Communication Considerations for Distributed Control Applications

Building and operating a distributed smart system, such as an irrigation project and smart IoT building, must strike a balance between delivering superior capabilities and operating costs - especially with regards to effort required to maintain the system. The larger the distributed network, the higher the complexity, cost, and potential interventions required by the operator to keep the system performing correctly.

In Part 3 of this series, we will see how the careful choice of communication architecture can avoid maintenance overhead costs, while delivering superior capability.

As smart applications increase, the number of sensors and actuators they use also increases, along with the complexity of connecting and communicating between those devices. This communication complexity is further amplified when the sensors and actuators are geographically distributed relative to each other.

In a typical, small-scale irrigation system, all of the necessary processing is centralized in a single control unit that relies on a local timer function, an irrigation scheduler, and switches to deliver power to valve solenoids that control the flow of water through the subsections of the system. The user is responsible for making sure the system is operating correctly and to make adjustments as needed to ensure its continued efficient operation.

Smart irrigation systems add sensors to offload some or most the responsibility from the user to make the dynamic adjustments necessary to maintain the efficiency of the system, as well as to detect and autonomously respond when faults occur. When the physical area serviced by the irrigation project is more widely distributed, it becomes appropriate to consider more complex communication options that also enable the processing to be distributed throughout the system for the benefit of efficiency, reliability, and cost savings.

The communication benefits and trade-offs apply to all distributed control projects even though the specific details and technical constraints will differ between each project. For example, a smart building fire detection and sprinkler system has very similar considerations to our smart irrigation example. While a smart-building installation of Internet of things (IoT) devices might not deal with water, it deals with the same issues of communicating, processing, and coordinating information from the various sensors and actuators in the building.

Many smart and distributed control systems are installed into an environment rather than being contained within a single package or device. Irrigation systems are installed into plots, hot houses, and fields that will be repeatedly manipulated to support different plantings. Smart building IoT systems are likewise installed into buildings that may see their use change over time.

Figure 1 shows the signal and processing flow between sets of sensors that monitor the environment and the relevant output of a paired set of actuators. The sets of sensors and actuators might consist of repeated types of sensors and actuators, but they are grouped together by proximity in the operating environment. Each paired set may also share the same communication and power-management implementation.

This intimate relationship with the environment creates different considerations between installing the smart system at the same time that the environment is being built or retrofitting it into an existing environment.

Figure 1: Distributed smart control systems use sets of sensors that monitor the environment and results of paired actuator sets to enable closed-loop control. (Image created using Scheme-it®)

If the control system is being installed along with the rest of the environmental infrastructure, there may be an opportunity to effectively use hard-wired communication, with appropriate environmental protection, alongside the other infrastructure components. For our irrigation example, this could mean installing power and communication lines adjacent to the water lines that are placed into the ground.

However, if you are adding or upgrading a control system to an existing facility, repairing a damaged node, or even just expanding the number of distributed sensor and actuator nodes to an existing system, it may make more sense to use wireless communication and battery as a local power source for the new nodes. Wireless communication offers the most flexibility for managing and operating a retrofitted distributed control system in environmentally challenging locations.

The RF module chosen should be able to support bi-directional communication to support collecting data from the sensors and commanding the actuators in each node. The communication protocol should include cross-platform support so that when you replace or add new nodes, you have the flexibility to use the best-in-class or price devices without having to reinstall the whole system. The communication protocol should allow the user to easily deploy new or replacement devices in bulk in a plug-and-play fashion so as to enable automatic detection, tracking, and reporting of the state of each device.

The RF modules should include support for bi-directional message buffering to enable aggressive power management strategies. This is especially important for nodes that are difficult to access or remotely located and operating on battery power. Choosing software APIs that avoid being too chatty will help with reducing battery drain.

Security

Security is an important issue when using wireless communication in a distributed control project because you cannot rely on physical access control to protect your system. It is critical to employ multiple levels of security including having no open ports on devices and providing device level access control.

Not only can a malicious attacker use the captured sensor information to infer what and how you are operating, but a motivated and persistent attacker can find unexpected and creative ways to command your actuators to incapacitate, damage, or even accelerate the wear-and-tear on the actuators.

Digi International’s XB24CAUIT-001 XBee® S2C 802.15.4 RF modules target low-cost, low-power wireless sensor networks (Figure 2). The modules are based on the Silicon Labs EM357 SoC and support a data rate of 250 Kbps with an indoor range of 200 feet and an outdoor, line-of-sight range up to 4000 feet. The module employs DSSS (direct sequence spread spectrum) for interference immunity, and has an operating temperature range of -40°C to +85°C.

Figure 2: The Digi XBee S2C 802.15.4 RF modules suit low-cost, low-power wireless networks with a range of 4000 feet and an operating temperature range of -40˚C to +85˚C. (Image courtesy of Digi International)

This is sufficient for providing a communication infrastructure for home gardens, hot houses, and fields. The ranges specified are typical when using the integrated whip (1.5 dBi) and dipole (2.1 dBi) antennas. The transmit power output is software selectable to: 6.3 mW (8 dBm) and Boost mode at 3.1 mW (5 dBm). The Xbee-PRO® variant extends the outdoor range to 2 miles to support larger commercial field irrigation.

The RF modules employ 128-bit AES encryption and support UART, SPI, and over-the-air firmware updates. The ZigBee® PRO 2007 protocol is HA-ready with support for binding/multicasting operating at the ISM 2.4 GHz frequency band. The Xbee modules support point-to-point, peer-to-peer, as well as multipoint and star topologies, and they are updateable to and from the ZigBee PRO and DigiMESH® protocols.

The modules deliver simple, out-of-the box RF communications with no configuration required. Digi XCTU is a free multi-platform, configuration and test utility that provides a graphical interface to set-up, configure, and test Xbee RF modules. It includes tools such as a graphical network viewer that includes signal strength at each connection, and the XBee API frame builder to build and interpret API frames while the module is operating in API mode.

Figure 3: Application example using the XBee RF module through a gateway, cellular/VPN, device cloud service, and Ethernet, into a remote monitoring control office. (Image courtesy of Digi International)

The application example in Figure 3 shows that the wireless infrastructure can be combined via a variety of network technologies and services outside of the immediate control system. This is relevant to not only IoT and smart building applications, but also to our example irrigation project because there are weather services that our irrigation control system can access to further improve operating accuracy and efficiency.

Conclusion

Smart and distributed control systems find their genesis in smaller scoped projects. These projects grow into distributed control systems by adding sensors and actuators that enable automatic and dynamic adjustments to the operation of the system to improve reliability and efficiency, as well as offload fault detect and response from the end user. In many cases, these systems are installed into existing environments that include distance, access, and safety concerns for the end user. The ability to wirelessly connect new sets of paired sensors, actuators, processors, and local power into the whole distributed system enables the user to grow their system to best meet their needs, while controlling the reliability and scalability of the project.

However, as we have described, it is critical that deliberate design effort is put to the issue of security, as a malicious attacker may be creative enough to wreak unexpected havoc and damage. Gaining control of the environmental controls of a building offers a myriad of choices for mischief. It is better to prevent this mischief by performing intelligent partitioning of your system’s networking, processing, and device control access.