This Control Talk column appeared in the July 2020 print edition of Control. To read more Control Talk columns click here or read the Control Talk blog here.
Greg: PID control is only as good as its signals. To help guide us on how to most effectively use wireless technology, we have Hunter Vegas, engineering manager at Wunderlich-Malec, and Mark Nixon, director of DeltaV Research and Technology at Emerson. Both Hunter and Mark were the principle writers on PID signals in Chapter 5 on Control Communications in the Process/Industrial Instruments and Controls Handbook Sixth Edition. Hunter is also cofounder of the ISA Mentor Program and coauthor of 101 Tips for a Successful Automation Career and is writing the section on the types of PID signals for the ISA 5.9 Standards and Practices (S&P) technical report on PID Algorithms and Performance. The following conversation is mostly between Hunter and Mark with me just chiming in.
Hunter: My understanding is that wireless instrument resolution will vary by device and depends on configuration.
Mark: Device parameters can be configured to be sent as raw data or in engineering units. In WirelessHART, values are generally sent in engineering units.
Greg: Larger calibration spans generally reduce resolution and accuracy but not as much with modern day transmitters unless the lower end of the span exceeds the rangeability capability of the sensor.
Hunter: The literature I’ve found seems to conflict significantly on time between updates. Some say input signal update rates are completely deterministic, others say there is variability due to network traffic, rerouting algorithms, etc. Also, it seems that output signal updates are not deterministic and will vary.
Mark: My discussion here is limited WirelessHART. PID input signal updates from transmitters are typically deterministic, but PID output signal updates to valves are not and can vary. Input update times can be reduced to 1 sec but this consumes network bandwidth and battery life. Most wireless devices are updated every 4, 8, 16 or more seconds.
PID inputs have a variable latency. The published periodic messages from the device travel through the mesh from source to destination. The various routes that a packet may take through the mesh are not all the same in hops. There are also retries. I did an extensive study on this. I combined retries and hops together and just called the traffic “tries.” What I found was that 64% of the traffic gets to its destination in the first try, 23% requires two tries, and the remainder of the traffic takes three to five tries. If the traffic goes in one try, then the latency will be very short (10ms). For two or more tries, the latency varies by how long it takes for the packet to be retransmitted. I found the average latency for the entire mesh network to be about 0.4 seconds. So, on average a four-second periodic messages would take 0.4 seconds to get sent. Many packets came in at 10ms (one time slot) with a few taking up to 4 seconds to arrive. I guess that’s why the average was about 0.4 seconds.
PID outputs are not periodic and can vary. I won’t dwell too much on this. Writes from the control system to the actuator (valve) were designed in the standard to also be periodic (windowed or change of state). However, the most common method in use doesn’t support this. So, outputs are sent request/response. In our studies we were seeing these downstream messages taking on average 1-4 seconds. There were a few changes that took up to 15 seconds.
Greg: The deadtime introduced in a loop is half the time interval between updates plus the latency. The same issue but with a much larger potential deadtime occurs for at-line and offline analyzers. An enhanced PID can prevent oscillations from the additional deadtime, stuck valves, and update failures is covered in Appendix E of ISA 5.9 and described in my InTech article “Wireless - Overcoming challenges in PID control & analyzer applications” and my white paper “PID Enhancements for Wireless."
However, the minimum peak and integrated error for an unmeasured load disturbance is proportional to the deadtime and deadtime squared, respectively. Where minimizing these errors are important (e.g., reactor pressure and temperature control), the update time should be appreciably less than one-fourth the existing loop deadtime. Considering that many loops are not tuned aggressively, an alternative rule is that the update time should be roughly less than one-fourth the reset time assuming the reset time is not too small, which is a common mistake for level and temperature loops. For self-regulating processes and lambda tuning, this corresponds to an update time less than about one-fourth the 63% response time. For near-integrating, true integrating and runaway processes, the response time is irrelevant (too large or nonexistent) necessitating reverting back to one-fourth the PID reset time and less than one-fourth the deadtime where integral action is minimized or omitted (e.g., gas pressure, exothermic reactor temperature and unidirectional batch temperature or pH response).
An opportunity often overlooked is the possible use of portable wireless transmitters to find best sensor location and to diagnose/improve process operation. The best distillation tray for temperature control is the one with the largest most symmetrical change in temperature for a change in the manipulated flow (e.g., reflux flow). The best location for a pH electrode is the one with the best mixing, least bubbles and shortest transportation delay. Heat transfer can be monitored in a jacket, coil or heat exchanger by inlet and outlet temperature measurements, where the inlet is synchronized with the outlet temperature by passing the inlet through a deadtime block with the deadtime set equal to the transportation delay through the equipment for a known flow. This can be used to infer reaction rates and batch completion and to compute a heat transfer coefficient to monitor fouling and frosting of heat transfer surfaces. Wireless steam trap monitoring devices are a great opportunity. Steam trap problems can be an extensive largely unrecognized problem.
Hunter: What are specific issues with gateway selection/configuration and fast update times?
Mark: The gateway needs to be positioned so that it has good access to the wireless mesh network. Extended antennas may be required. Devices with fast update times should be close to the gateway if possible. This reduces the hops but devices still need to wake up to perform the communications.
Hunter: What can you do to avoid problems with mesh networks and self-healing settings?
Mark: It is important that each device have two neighbors. From experience, network interference can change with time of day, shift, maintenance activities as well as other factors. Having good neighbors greatly improves the likelihood that communications will get through.
Hunter: The information I have found on diagnostics is somewhat conflicting. I expect the amount diagnostic data is very dependent on the gateways and control system interface devices. If the equipment is tightly integrated, I expect diagnostics will come through “out of the box.” However, if the components are not integrated, diagnostics will require special configuration to obtain and may not be available at all. I’m most interested to know if the PID block has some easy means to determine if an input/output value is not working (PVBAD) or does the value just freeze and the PID block continues assuming everything is working. Is there any feedback that an output is really getting to the valve or must one program do some readback check?
Mark: All HART communications include the health of the device and the status of each measurement. With WirelessHART devices (all HART devices), each value communicated includes the value, a device status code and a unit code. Here’s what a DCS would typically get (if the DCS only looked at the variable status, i.e. PV and other measured variables):
- Process Data Status. Overall status of the Device Variable: Good, Manual/Fixed, Poor Accuracy or Bad.
- Limit Status. Indicates whether the Device Variable is responding to process changes: Constant, High Limited, Low Limited or Not Limited.
In a control strategy the status would typically be included along with the parameter and the control strategy would be designed to deal with Good/Bad/Limited status conditions. Control systems should also use status values from the Device Status field and the Extended Device Status codes:
Device Status:
Code |
Map |
Description |
0x01 |
S |
Primary Variable Out of Limits. The PV is beyond its operating limit. |
0x02 |
S |
Non-Primary Variable Out of Limits. A Device Variable not mapped to the PV is beyond its operating limits. |
0x04 |
S |
Loop Current Saturated. The Loop Current has reached its upper (or lower) endpoint limit and cannot increase (or decrease) any further. |
0x08 |
N |
Loop Current Fixed. The Loop Current is being held at a fixed value and is not responding to process variations. |
0x10 |
N8 |
More Status Available. More status information is available via Command 48, Read Additional Status Information. |
0x20 |
N |
Cold Start. A power failure or Device Reset has occurred. |
0x40 |
N8 |
Configuration Changed. An operation was performed that changed the device's configuration. |
0x80 |
N |
Device Malfunction. The device detected a serious error or failure that compromises device operation. |
Extended Device Status:
0x01 |
N |
Maintenance Required. [Condensed Status] This bit is set to indicate that, while the device has not malfunctioned, the Field Device requires maintenance. Devices supporting this bit should support the Condensed Status Commands (see Common Practice Command Specification). |
0x02 |
S |
Device Variable Alert. This bit is set if any Device Variable is in an Alarm or Warning State. The host should identify the Device Variable(s) causing this to be set using the Device Variable Status indicators. |
0x04 |
F |
Critical Power Failure. For devices that can operate from stored power. This bit is set when that power is becoming critically low. For example, a device scavenging power loosing that power source would set this bit. Devices must be able to sustain their network connection for at least 15 minutes from the when this bit is set. A device may begin gracefully disconnecting from the network if its power level drops too low. |
0x08 |
N |
Failure. [Condensed Status] When this bit is set one or more Device Variables (i.e., measurement or control values) are invalid due to a malfunction in the field device or its peripherals. Devices supporting this bit must support the Condensed Status Commands (see Common Practice Command Specification). |
0x10 |
N |
Out of Specification. [Condensed Status] When set, this bit indicates deviations from the permissible ambient or process conditions have been detected that may compromise measurement or control accuracy (i.e., device performance may be degraded given current operating conditions). Devices supporting this bit must support the Condensed Status Commands (see Common Practice Command Specification). |
0x20 |
N |
Function Check. [Condensed Status] This bit is set if one or more Device Variables are temporarily invalid (e.g. frozen) due to ongoing work on the device. Devices supporting this bit must support the Condensed Status Commands (see Common Practice Command Specification). |
APPENDIX I: Communication Modes and Wireless Best Practices
Excerpts from Process/Industrial Instruments and Controls Handbook Sixth Edition, McGraw- Hill, 2019.
1.1 Communication Modes
The standard communication techniques that are supported by HART devices are defined below.
1.1.1 Request Response
This is directed communication between a host and a single, specific device. The address of source and destination device is specific and unambiguous. All HART commands specify the request and response data to be communicated. All devices are required to support request/response. Likewise, all gateway devices are also required to support request/response.
1.1.2 Publish/Subscribe/Burst-Mode
HART devices may be configured to publish new measurement values using continuous, windowed, level, and on-change triggered modes. WirelessHART devices MUST support cyclic burst messages. The communication modes are:
- Continuous: The device wakes up at a configured update time, senses the measurement and then communicates the value. This is used for analog and discrete devices.
- Window: The device wakes up at a configured update time, senses the measurement and then communicates its value if the specified trigger value is exceeded. This is primarily used for analog devices. The value is sent if the maximum time between updates has been exceeded. The rules are (restated): the magnitude of the difference between the new measurement value and the last communicated measurement value is greater than a specified trigger value, or, the time since the last communication exceeds a maximum update period.
- On-Change: The burst message is triggered when any value in the message changes. This mode is often used for discrete devices (refer to Discrete Applications Specification) and for command 48. This is used by most WirelessHART devices.
- Level-Triggered: The burst message is triggered when the value rises above or falls below the specified trigger value. The level can be set up as a rising or falling condition.
5.5.4 Wireless technology best practices
There are many common features that can use best practices for network design. While a network could be small, too few devices might not maximize the capabilities of the mesh network. On the other hand, too big a network can drag down the performance of the network. For a large facility such as refinery or chemical plant, each wireless network should be scoped to a single process unit. For vertically arranged facilities such as power plants or factories, the self-organizing network should be scoped to a single floor. Engineering practices generally assign a network to each plant area and/or unit operation, similar to the way automation system controllers and I/O systems are done today.
In the case of WirelessHART, a wireless network can be thought of as a WirelessHART gateway and its devices. For ISA100-11a a wireless network can be either a ISA100-11a gateway and backbone routers with devices or a collection of devices and the backbone routers that they connect to.
The following best practices should be considered in the installation of the wireless networks:
-
The lithium-thionyl chloride battery cells used by many wireless devices provide high energy density, long shelf life and a wide working temperature range. However, the communication update rate that is configured for a device has a direct impact on the expected battery life, as does the service temperature. In most cases, the communication update rate may be selected by the end user. Reducing the communication rate from 1s to 16s often extends the battery life from three-six months to over five years.
-
In most cases, the networks should be deployed to similar wired systems. The steps are:
-
Determine where the devices should be mounted in the plant and install them.
-
After the devices have joined the network they typically begin to immediately start publishing data.
-
Next, install the backbone routers or access points, remote antenna (if used), and gateway.
-
In small networks, the gateway or backbone routers should be in the center of the network. For large networks or applications that require the gateway to be mounted inside a control room or rack room with remote access points, backbone routers or antenna, it is best practice to build the initial network around the location of the access points or antenna. Then the network can be expanded to reach remote area of the process unit. These practices provide a solid foundation on which to expand the network.
-
An RF assessment should also be considered. A good indication that some kind of interference is at play is the existence of excessive retries. If RF interference is suspected then most suppliers offer comprehensive site assessment services to access site RF spectrum utilization and interference. Consider the following while conducting a site assessment:
-
Conduct the site assessment when the plant is operating so that the maximum possible interference is measured and addressed.
-
Conduct an RF spectrum analysis on the 2.40-2.483GHz band and 5 GHz band (if available) to detect any potential RF interference. Strong interference sources must be addressed (removed, avoided or minimized). Some frequencies may not be available for use in some locations and countries.
-
Received Signal Strength Indicator (RSSI) can serve as an indicator of the RF environment. For Wi-Fi and IEEE 802.11 mesh networks, TCP/IP throughput testing and UDP/IP throughput and packet drop rate testing must be conducted in all the selected locations to measure the quality of the signal strength in the site.
5.6.3 Wireless best practices
The following best practices should be considered in the installation of the WirelessHART network.
-
Minimize the number of hops to the gateway in order to reduce latency. A minimum of five wireless instruments should be within effective range of the WirelessHART gateway.
-
A mesh network gets its reliability from multiple communication pathways. Ensuring each device has multiple neighbors within range will result in the most reliable network. Every WirelessHART device should have a minimum of three neighbors within effective range. This ensures there will be at least two connections and the potential for connections to change with time.
-
Include 25% of each network’s wireless instruments within effective range of the gateway. This clusters more devices around the gateway and ensures fewer hops and more bandwidth available to WirelessHART devices with fast scan rates.
-
Gateways can be added to ensure spare capacity. Gateways may be logically distributed throughout the process unit like junction boxes. Wireless field devices should be assigned to the closest gateway, or to the gateway that is assigned to the process unit adjacent to the unit where the field devices reside.
-
Identify the necessary update rate of each WirelessHART device to meet the specifications of the application as well as battery life.
-
Typical WirelessHART devices can update from once per second to once per hour.
-
The update rate should be faster than one-fourth the minimum desirable PV change divided by the maximum PV rate of change for monitoring and open loop control applications.
-
The update rate should be faster than one-fourth the PID reset time for closed loop control. For self-regulating processes, this corresponds to less than one-fourth the 63% response time.
-
Update rates faster than four seconds can impact the total number of wireless devices that can be put on a gateway. Consult the specification of the gateway vendor for additional constraints.
-
Determine the capacity of the gateway. For example, 100 WirelessHART devices may be connected per gateway if all devices are updating every eight seconds (check the manufacturer specifications).
-
Determine and apply any guidelines on spare capacity. If the design rules for the project state that I/O components should have 40 percent spare capacity, then include this value in the capacity calculations.
-
Do not place all gateways in the same location just because connecting into the host system is convenient.
-
The effective range of a device is the typical linear distance between WirelessHART field devices when in the presence of process infrastructure. Typically, if WirelessHART devices have no obstructions between them, have clear line of sight (LOS), and are mounted at least 6 feet (2 meters) above the ground, then the effective range with 10 mW/10 dBi of power is approximately 750 feet (228 m). Obstructions decrease the effective range. Most process environments have high concentrations of metal that reflect RF signals in a non-predictable manner bouncing the signal off of the metal of the surrounding environment. The path of an RF signal could easily be 750 feet (230m) even though the neighboring device separation is only 100 feet (31m) away.
-
Never use default keys. Default keys are generally not as safe as a strong, randomly generated key, so it is recommended that randomly generated keys be used. Use robust key management measures. Treat encryption keys as private and confidential information and protect them against unauthorized access.
APPENDIX II: System Engineering Guidelines from IEC62591
These best practices are from the System Engineering Guidelines for IEC 62591 WirelessHART
Effective Device Range
I have generally used 100ft as the distance between WirelessHART devices (neighbors in a mesh) when installing on equipment in plants. The rules from the System Engineering Guidelines are:
The effective range of a device is the typical linear distance between WirelessHART field devices when in the presence of process infrastructure. Typically, if WirelessHART devices have no obstructions between them, have clear line of sight (LOS), and are mounted at least 6 feet (2 meters) above the ground, then the effective range with 10 mW/10 dBi of power is approximately 750 feet (228 m). Obstructions decrease the effective range. Most process environments have high concentrations of metal that reflect RF signals in a non-predictable manner bouncing the signal off of the metal of the surrounding environment. The path of an RF signal could easily be 750 feet (230m) even though the neighboring device separation is only 100 feet (31m) away. Below are basic classifications for effective range in the process environment.
-
Heavy obstruction: 100 ft. (30 m). This is the typical heavy density plant environment, where a truck or equipment cannot be driven through.
-
Medium obstruction: 250 ft (76 m). This is the less light process areas where lots of space exists between equipment and infrastructure
-
Light obstruction: 500 ft (152 m). Typical of tank farms. Despite tanks being big obstructions themselves, lots of space between and above makes for good RF propagation.
-
Clear line of sight: 750 ft (228 m). The antenna for the device is mounted above obstructions and the angle of the terrain change is less than five degrees.
Some WirelessHART vendors provide options and techniques for obtaining even further distances for long distance applications.
The following four design rules should be followed when setting up the device network.
- Design Rules – Rule of Five: Every WirelessHART network should have a minimum of five WirelessHART devices within effective range of the gateway. Networks will work properly with less than five WirelessHART devices but will not benefit from the intrinsic redundancy of a self-organizing mesh network and may require repeaters. In a well formed, well designed network, new WirelessHART devices can be added to the interior or perimeter of the network without affecting operation or extensive consideration for design.
- Design Rules – Rule of Three: Every WirelessHART device should have a minimum of three neighbors within effective range. This ensures there will be at least two connections and the potential for connections to change with time.
I had mentioned two neighbors in my previous response. This is consistent with the two connections noted here. Three neighbors generally ensures that two will always be available for communications. - Design Rules – Rule of Percentages: Every WirelessHART network with greater than five devices should have a minimum of 25% of devices within effective range of the gateway to ensure proper bandwidth and eliminate pinch points. WirelessHART networks can work with as little as 10%, and actual implementation may yield less than 25%, but experience shows this is a practical number.
Example, a 100-device network implies 25 within effective range of the gateway.
Networks with greater than 20% of wireless devices with update rates faster than 2 seconds should increase the percentage of devices within effective range of the gateway from 25 to 50%. - Design Rules – Rule of Maximum Distance: Wireless devices with update rates faster than 2 seconds should be within two times the effective range of wireless devices from the gateway. This rule maximizes speed of response for monitor and control applications requiring high-speed updates.
- Control and Higher Speed Networks: It is recommended that wireless field devices used for control and high-speed monitoring have a higher path stability than general monitoring devices with updates slower than two seconds. Path stability is the measure of successfully transmitted messages on any given path relative to the attempted transmissions. General requirements are 60% path stability, but 70% is recommended for control and high-speed monitoring. The additional consideration provided in this text ensures higher path stability that can be confirmed once the network is deployed.
In my control study, I found that 64% of the traffic got to its destination in the first try, 23% required two tries, with the remainder of the traffic taking three to five tries. This is consistent with the 60% path stability noted above.
Minimizing downstream messages for wireless output control devices
Digital control signals sent from a controller (a controller is a host) to a wireless output control device via the gateway require a downstream message. Maximum downstream message time from gateway to wireless control device is independent of the update rate (this is the device update rate referred to earlier) and should be no more than 30 seconds when network design best practices are followed.
Techniques for limiting miscellaneous downstream messages are as follows:
-
limit remote configuration of wireless devices when control is in service,
-
limit device scans by asset management software, and
-
limit other actions that require a remote poll and response from the wireless field device.
The update rate of the wireless control device (e.g. valve) determines how fast the controller receives notification that the control command was received and executed. The valve actual position should be included as one of the parameters published from the valve. As many as eight parameters can be communicated in each published update.
In order to minimize the time for the downstream message to arrive at the wireless control device, downstream messages initiated by non-control applications should be minimized (e.g. from asset management applications).
(10) You like the process engineer’s creativity in exploring process abnormalities
(9) You enjoy war stories
(8) You want operators to depend upon what you say is the problem
(7) You like the doughnuts in the control room
(6) You don’t want to be trapped into understanding steam trap problems
(5) Batches are done when they are done
(4) Fouling will help operators appreciate your oversized coolant valves
(3) The best measurement location is the one closest to the instrument shop
(2) Where upsets originate is anybody’s guess
(1) You don’t want to be beaten by being off the beaten path