Topologies for Wireless Instrumentation
Anyone who has been reading Control Engineering and similar publications for the last couple of years has seen a lot of discussion regarding wireless instrumentation and larger wireless plant integration. Like the “fieldbus wars,” wireless discussions can create more heat than light, but the potential for wireless capabilities is undeniable.
Anyone who has been reading Control Engineering and similar publications for the last couple of years has seen a lot of discussion regarding wireless instrumentation and larger wireless plant integration. Like the “fieldbus wars,” wireless discussions can create more heat than light, but the potential for wireless capabilities is undeniable. If you’re beginning to consider how you might put the technology to work in your plant, you have plenty of choices. For purposes of this article, we will confine the discussion to permanently mounted process instrumentation and associated discrete devices. Larger scale plant integration, employee location, wireless workers, and the like will be treated elsewhere.
Like the wired world, there are many options for moving a signal from a given device to the larger control system. You need to choose a way to “wire” your wireless devices. The biggest difference with wireless is that it is a shared medium. While it is always possible to add more wires for more instruments, there is a point when wireless bandwidth will run out for a given frequency. As a practical matter, adding wire costs money and there are physical limitations to conduit and cable trays. On the other hand, there are few clear rules as to when wireless bandwidth runs out. There are not enough situations where wireless interference has become a problem to provide clear indications beyond the belief that it will vary greatly from plant to plant.
Much of the discussion lately has related to the growing selection of instrumentation with built-in wireless communication. Transmitters have sprouted antennas and radio modules are an integral part of the electronics. While integral wireless is the easiest, the choices are still limited. Most producers have started with simpler devices for wireless integration, so there are many temperature and pressure sensors available, but few complex items like Coriolis flow meters. Frequently this is driven by the ability to power a device with batteries, so high power consumption items such as a magnetic flowmeters are overlooked.
There are manufacturers who offer wireless communication modules that can be added to existing instrumentation. These typically accept standard analog and digital communication protocols, such as 4-20 mA, and some also handle bit-level devices. The transmitter is usually powered separately, either externally or by battery. This expands the potential selection to include essentially all instrumentation from any manufacturer, but requires adding a separate device. Depending on the needs of a given application, this may be a small price to pay.
The decision to use a wireless solution is typically driven by the desire or requirement to eliminate a wired connection. But does that mean every wire? When mounting a temperature sensor on the side of a rotary kiln, all wired connections have to go. On the other hand, sometimes getting rid of the data wire is enough. If an instrument is a long distance from its I/O point but close to a mains power source, it makes sense to use that capability. Batteries have a finite life, even if it is years, and limit the amount of power available to the transmitter. A higher power signal is usually more robust and reliable, so there are many reasons to use external power if it is available.
There are other alternatives, including solar collectors, which can help where mains power is not available and power consumption is too high to make conventional battery power practical. For purposes of this article, battery power discussions assume a self-contained battery pack.
Given the complexity of creating a communication protocol, instrumentation producers frequently use the same protocols as IT and consumer products. Your wireless pressure sensor may be sending its readings back using ZigBee or Bluetooth. The wireless backhaul for a fieldbus segment is probably using Wi-Fi or possibly Bluetooth.
In many respects, the communication protocol should not necessarily be a primary selection criterion. A wireless pressure sensor from company “A” probably isn’t designed to interact with a sensor from company “B,” even if they both use ZigBee. Technical capabilities and limitations of each protocol will tend to dictate its applications.
Given that most wireless equipment was developed relatively recently, concerns for cyber security are part and parcel of virtually all current platforms. Wireless instrumentation protects itself with two main techniques:
First, signals can be kept within physical confines through the use of careful transmitter powering and antenna directionality. This minimizes the potential for data to spill over plant perimeters where hackers can eavesdrop, insert bogus data or use unprotected points to slip into larger networks. Unfortunately, in many cases this is not entirely possible, particularly where plants exist in crowded areas.
Second, most systems include a combination of data encryption and authentication. Not only is the data sent in a format that is undecipherable from the outside, but instruments have to identify themselves to the network to participate in data transfers. Platforms can have elaborate ID codes for each device to preclude the possibility of listening to rogue devices. Appropriate firewalls can keep hackers from moving out of instrumentation networks into higher level IT systems.
Update rates, data types
Most wireless instrumentation is designed to report its process variable at a specific time interval. While standard wired 4-20 mA devices send information continuously, this is rarely necessary for a process except in the most critical applications. Wireless devices typically digitize the signal and send back whatever the value is at a given interval. This may be once per second or even faster for a critical data point, or once per hour for a value that cannot change quickly. Fast update rates consume larger amounts of power since the radio spends more time transmitting, so the interval is directly related to battery life. Moreover, the reporting rate influences the number of devices that can communicate with a given gateway. Frequent rates mean few devices and short battery life, so don’t make the interval any shorter than truly is necessary for the process.
Some platforms support alerting functions, where a device that is set for a long reporting period will break out of its set interval to send back an emergency message if its variable has crossed over an alarm level. For this to happen, the sensor has to be functioning during the times the radio is in sleep mode. This may seem like a minor function, but it has the practical value of allowing you to set a long reporting interval for a device and still know that a problem will be communicated immediately.
Most instrumentation can transmit a process variable as a single value, which is easy for the radio to handle as a very short data burst. However devices such as vibration monitors that are trying to transmit something as complex as a wave form usually need more time. For some systems this is not a problem, but if your process depends on complex data transmission, this can become a critical element and merits in-depth discussion.
Simple point to point systems are effective, but for multiple installations, there are more efficient approaches.
Point to point
The oldest and simplest approach is point to point, where there is a single instrument with its own radio transmitter sending a signal to a gateway (receiver), which is wired to the control system. The gateway only receives signals from that transmitter. This approach works, but is losing its practicality for all but the smallest installations. For applications where there only will be a handful of devices or where they will be spread over a large installation and communicate with multiple I/O points, this might still make sense. However it gets expensive due to the large amount of hardware and has potential to cause interference between parallel systems.
Larger scale systems can use a group of individual instruments that communicate with a single gateway. Each device sends its data in turn and the gateway sorts it out so the control system can follow instrument variables individually. The devices do not talk to each other, so no single instrument is aware of what is going on with other devices around it.
Point to point systems are typically proprietary, although they may use a standard or commercial transmitting protocol. Getting the data out of the device and into the control system usually uses proprietary software that is not interoperable across platforms.
Applications with only one or two instruments to monitor are rare. Usually pieces of instrumentation exist in clusters around process units and subunits. While a group of instruments communicating individually to a single gateway might be a solution, often it is simpler to use a data concentrator that collects the signals and sends them back from one transmitter. This eliminates extra radio transmissions which can be critical in crowded radio frequency (RF) environments. A data concentrator can also use standard devices without their own wireless capability. Most of these are externally powered, so they usually have a high wattage radio with a strong and reliable signal with long distance capabilities.
Data concentrators are typically modular with configurations similar to PLC I/O points. The radio can have different input blocks attached depending on number and types of instrumentation. For example, if a tank has a flowmeter, pressure sensor, and level sensor, combined with a level switch and a pressure switch for alarming, you can configure the inputs to accept both scalar and bit-level devices. The gateway separates the variables for the control system. Some use a protocol such as Modbus to gather and distribute process variables, and can also handle HART data from enabled instruments.
The effectiveness of wired fieldbus systems can be extended by using strategic wireless communication.
Using wireless communication with a fieldbus usually follows one of two approaches:
The first takes the data from an entire wired fieldbus segment and sends it from the scanner back to a gateway. In this respect it performs like a sophisticated data concentrator. Usually this involves a Wi-Fi backhaul, but other options are also possible.
The second incorporates a wireless gateway in the fieldbus scanner to communicate with specific instruments on a segment that are not directly wired. Consider a situation where a fieldbus segment involves all the devices associated with a reactor. If the reactor has a removable lid with a level sensor mounted on it, this would be an ideal situation to have one item wireless when the others are wired. The wireless device communicates with the gateway, and its data is included with the wired devices on the segment.
Much of the current discussion relates to the growing availability of instrumentation with integral radios that form mesh networks. The concept is that individual devices can communicate with each other and their gateway in a way that supports robust and reliable data transfer. Within that approach, there are two main methodologies.
The first approach is fully dependent on battery powered individual instruments. (The new WirelessHART protocol is the leading example of this approach currently.) Each device is a transmitter and receiver, and devices that are within range of each other communicate with each other and the gateway. Every radio module is on a common clock, and they turn themselves on at a specific interval to exchange data. Devices that are far from the gateway send data from device to device, repeating it as needed and advancing with each hop. Every instrument participates with each data cycle, even if some do not have a variable of their own to transmit due to a longer reporting interval. Instruments that are not available with an integral radio can have one added as an external device, although the instrument will likely need its own power source.
Battery-powered meshed networks require the least infrastructure, but accept some strategic limitations to achieve that.
While this approach adds some latency to moving data, the amount of time required to get it to the gateway is usually very short compared to the reporting interval. The devices form their own network and are self healing in the sense that they are capable of reconfiguring the way they interact if there are disturbances within the network from RF interference or damage to a device. If a device drops out of the network, the others will report its absence.
This topology has many advantages. It requires very little, if any, external management and uses its own software to configure communication and power consumption. When a network is optimized, batteries can last five, ten, or more years due to efficient power use.
On the other hand, battery powered radios sacrifice transmitting power and bandwidth to minimize power consumption. Reliable communication depends on all the small radios supporting each other rather than more powerful externally powered transmitters.
The other mesh networking protocol also uses battery powered instrumentation but externally powered nodes as intermediate devices. Individual instruments communicate with the nodes and do not mesh with each other. Nodes function as repeaters, meshing with each other when necessary, and bring data to the gateway. Individual instruments are capable of communicating with more than one node to provide a redundant path.
While this approach requires more infrastructure, there are advantages over the all-battery topology. First, nodes use higher power radios with greater bandwidth compared to individual devices. This sends data back to the gateway faster from distant instruments with fewer hops. Moreover, with higher power, node to gateway signals are more robust.
Individual instruments can sleep longer and conserve battery power since they only have to wake up at their reporting interval rather than with each data cycle. And since nodes receive signals continuously, a device in an alerting mode can transmit at any time.
Still, adding nodes complicates the initial installation. Even if they do not need a data cable, they do need power, so this adds to wiring requirements. If a data cable is available, a node usually also can function as a secondary gateway, adding flexibility for routing data through complex systems.
Mesh networking is conceived to serve larger applications than the other smaller-scale approaches. While data concentrators and point to point solutions are good for five or ten devices per segment, mesh networks are better suited to applications with (potentially, anyway) up to hundreds of devices. All-battery mesh networks become more reliable as they add devices, since they all support each other. Powered node mesh networks depend on high device counts to spread out the infrastructure cost. While virtually all suppliers will offer plans for incremental adoption of a given platform, when making a selection, it is best to keep the larger picture in mind of where you might go with eventual implementation.
Know your process
Choosing the best wireless platform, like any equipment selection, depends on understanding the needs of your process. The placement of instrumentation, level of precision, frequency of update, and the like, all enter into the discussion. If you have clear concepts of how all these factors interact, and how instrumentation and data support control strategy, you can outline clear and appropriate objectives for wireless networking.
Peter Welander is process industries editor. Reach him at PWelander@cfemedia.com .
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.