Control over WirelessHART Network

Control over WirelessHART Network Song Han1, Xiuming Zhu1, Aloysius K. Mok1, Mark Nixon2, Terry Blevins2, Deji Chen2 The Department of Computer Science, the University of Texas at Austin, Austin, TX 78712, USA 2 Emerson Process Management, 12301 Research Blvd, Bldg III, Austin, TX 78759, USA {shan, xmzhu, mok}@cs.utexas.edu {mark.nixon, terry.blevins, deji.chen}@emerson.com

1

Abstract-It has been observed that the history of industrial process control development is also a history of reducing the number of wires necessary for effecting the control. Control over wireless is the end of this evolution. Wireless control faces a lot of challenges such as security, reliability, feedback latency, battery longevity, etc. In this paper we report some experience with implementing control over wireless. The platform we use is the WirelessHART mesh network, the first international industrial wireless control standard. We describe a full implementation of the standard and study the issues and solutions in its application. Our data suggest that WirelessHART technology is up to the challenge of wireless control.

I.

state of the WirelessHART technology and how we perform the experiments. The results are then presented and some preliminary observations are made. Section V concludes the paper. To put things in perspective, this paper talks about wireless among the devices within a process field, i.e., the low power, low data rate, and short distance wireless communications. We do not address the wireless communication between the field and the host, which is sometimes referred to as backbone communication. II.

INTRODUCTION

The history of controlling a process plant is also a history of reducing the number of wires in the industrial plant. In the pre-fieldbus era, each IO device requires a pair of twisted wires to relay the data and optionally provide the power. With fieldbuses, a set of devices are connected to a single bus, which also optionally supplies power. One of the key contributors towards fieldbuses’ success is the cost reduction in wire deployment. The natural next question to ask is if we could remove the wire for the fieldbuses as well to further reduce costs. The answer is wireless mesh network. Applying wireless in the process control industry is no longer an avant-garde adventure. WirelessHART, the first in this field, has become the standard of International Electrotechnical Commission (IEC). As of April 2010, there are already more than a thousand WirelessHART mesh networks deployed all over the world. If we include other systems that are not WirelessHART, the number could be even higher. The entry barrier for deploying wireless has been overcome; the debate has now shifted to how deep the wireless deployment penetration is. The questions we ask now are if we could completely replace all the wires in the plant, and if we could apply wireless beyond sensing to control. Industry experts are divided in their opinions on the first question. Some believe it will happen, some argue that certain core areas should never go wireless. This paper will focus on the second question. The next section looks at control with wireless in general. The common wisdom is to go from the simple to the critical. The first round of wireless applications will be for monitoring, and eventually supervisory control. Section III studies control with WirelessHART. We shall discuss some topics specific to WirelessHART; we shall argue that control in the gateway is the best way to go. In Section IV we discuss our experiment with control in the gateway. We describe the

CONTROL OVER WIRELESS

When the process control industry started looking at wireless a few years ago, wireless monitoring was the focus. Now that wireless is fully established in the monitoring applications, wireless control is coming to the forefront and several research projects have been devoted on it [7][8][9][10]. The fact is that the need to reduce the wiring costs makes control wireless inevitable. The question is when. Besides, the fast progress in the wireless technology is removing the adoption barrier. There are three groups of applications running in a process plant, ranging from auxiliary to critical. They are Class C applications for monitoring, Class B applications for control, and Class A applications for safety. The current wireless adoption is at the Class C level. While there has been serious work on wireless for Class B, wireless for Class A will also come eventually. Class B could be further divided into supervisory control, open loop control, close loop control and critical control. Today’s discussion about wireless control, including what is in this paper, is still at the lower end of the control spectrum. We do not find it prudent to advocate wireless critical control at this point. The following issues must be answered before the process engineer can welcome wireless into the process plant: 





Security. The first concern is the security of open air communication. To answer the security question is beyond this paper. It suffices to say that the security concern is serious but there are some proposed solutions. Reliability. In a process plant, timely delivery of correct data is essential, especially for control. Wireless is, however, inherently unreliable. We shall talk about this issue more in the following. Safety. Safety is the topmost concern in a process plant. We could not talk about safety unless we have extremely

high reliability. Wireless for safety control has still some to go in this respect.  Speed. Although we use the term “low data rate” wireless network, the data rate and transmission delay of a wireless network is still comparable or superior to some of the fieldbuses. For example, the underlying data rate of WirelessHART is 250Kb/s whereas that of the Foundation Fieldbus is 32.25Kb/s. In WirelessHART a single hop transmission timeslot is 10ms, while the communication time on a Foundation Fieldbus is in the 10ms to 20ms range.  Battery Longevity. With wireless come battery powered devices. It would be costly if the field engineer has to constantly replace the batteries. Again, this issue is beyond this paper. We know that current commercial wireless devices can last for years before the battery runs out. We now address the reliability issue in wireless control. We discuss how to increase reliability in the following subsection; in the subsequent subsection we discuss how to adapt control for unreliable communication.

in output spike and/or large process oscillations once the communication is back to normal. Problems also occur if output communication is disrupted. The PID Plus algorithm freezes its execution when the communication is lost. When the communication is restored, it resumes execution by taking into account the duration of the interruption. The experiments in [6] show improved process performance with PID Plus. When the data loss ratio is 0, PID Plus reduces to PID. PID Plus can also be employed to proactively reduce the traffic and hence the possibility of data loss. The sensors could use exception-based reporting rather than periodically reporting on process data. In the classic control philosophy exception reporting is normally used for non-process data. We should point out that even if we have achieved 0 data loss ratio, classic control algorithms must still be adapted in the wireless environment. We pointed out in the last subsection that mesh and multipath routing can be employed to deal with communication failures. The consequence is that

A. Increase Wireless Reliability The premise is that if wireless communication can be improved to as good as that of the fieldbuses, then the reliability problem will no longer be an issue. Reliability includes many aspects, such as availability, survivability, dependability, integrity, safety, performability, etc. We shall use WirelessHART as the example. The WirelessHART standard achieves high reliability through diversity over several dimensions: 

Time. All non-broadcast messages require ACK within the timeslot. Retry is employed on failure.  Space. WirelessHART network uses a mesh topology; each end-to-end pair must have at least 2 live paths.  Frequency. The WirelessHART standard provides channel hopping over 16 channels.  Code and Polarity. The WirelessHART standard adopts the IEEE 802.15.4 standard, whose coding and modulation methods are proven to be reliable.  Command concatenation. WirelessHART combines commands into long messages, which can be shown by calculation to result in a smaller less data loss ratio. We have observed 0% data loss ratio for a WirelessHART network in a real process plant at Balcones Lab of the University of Texas at Austin. B. Control with less Reliability An effective approach for wireless control is to the adapt classic control strategy to survive the adverse conditions in wireless. In [6], we took this approach and proposed a new PID (Proportional, Integral, and Derivative) Plus algorithm. Classic PID algorithm assumes that the input and output paths are reliable and updates are run periodically. If for some reason the input is temporarily lost, then the PID will accumulate error based on the last good value. This will result

Fig. 1. A WirelessHART Mesh Network.

periodically published data from a device may arrive at the destination with different delays and even out of order. For example, in the WirelessHART mesh in Fig. 1, data from Device 3 may have two routing paths to the gateway, one through Device 2, Device 1 and Access Point 1, the other through the router and Access Point 2. The data travelling on two routes do not have the same delay. Even data travelling on the same route may have different delays. Furthermore, a new value going through one route might arrive at the gateway earlier than an old value going through another route. This is different from wired fieldbuses where data could be punctually delivered in the right order. A good wireless control method should be able to handle jitters and out-of-order data values.

III.

CONTROL OVER WIRELESSHART

From the beginning WirelessHART was written to support measurement and control applications, although its early target is process monitoring. All the state of the art wireless technology it has adopted is geared towards meeting the control requirements. In this section we shall see how to design a closed control loop with WirelessHART. The HART standard was created in the late 80’s. In its initial release the HART Field Communications Protocol was superimposed on a 4-20mA signal providing two-way communications with smart field instruments without compromising the integrity of the measured data. The most recent version of the HART standard includes a major new WirelessHART communication protocol. The WirelessHART standard leverages existing standards such as the HART standard, the IEEE-802.15.4 standard, and DDL/EDDL (Electronic Device Description Language). Fig. 1 illustrates a WirelessHART network with all the basic device types. In WirelessHART, protocol communications are precisely scheduled using an approach referred to as Time Division Multiple Access (TDMA) to guarantee data delivery. Other features are also provisioned to support control over wireless: the mesh architecture provides multiple paths from a publisher to a subscriber; the schedules are sequenced so that measurement and control occur in the correct order; network manager allocates communication resources and it has no impact on control. WirelessHART application layer is command based. All commands require command responses. The sensors publish

an enlarged gateway illustrating the flow of the data. The published data from the sensors are cached in the gateway, which could further publish to the host if the data is subscribed. The host also asks the gateway for data, and the latter will return the cached data. A. Control in the Host WirelessHART fully supports this approach. There is no change to the gateway. Referring to Fig. 2, the control module runs in the host’s Function Block Application. The sensor data is routed to the gateway cache, and the gateway forwards it to the host. The control data is written to the gateway which wraps it in Command 79 and routes it to the actuator. The command 79 response from the actuator is then unwrapped and forwarded to the host. If the host supports HART, the data could be wrapped in the commands when transmitted between the host and the gateway. The drawback of control in the host is the further communication delay between the gateway and the host. The longer the loop delay is, the worse the control performance. B. Control in the Gateway WirelessHART fully supports this approach. The gateway needs to be enhanced to allow configuration and execution of the control modules. Referring to Fig. 2, a function block application layer (such as that developed by Foundation Fieldbus) may be easily added to the WirelessHART gateway. Control performance using function blocks executing in the gateway will match and in some cases improve upon that provided by Foundation Fieldbus devices. Some benefits of this approach include:   

Fig. 2. A WirelessHART Gateway.

data using the response format of Command 1, 3, 9, etc. So they are unsolicited. Command 79 is used to write data to the actuators. The response to Command 79 could be the actuator’s feedback. We shall borrow the concept of function blocks to describe control modules. Function block is use in Foundation Fieldbus. Each block encapsulates a control algorithm. And every control strategy could be defined as a combination of different function blocks. Depending on where the control module is placed, there are three types of control: control in the host, control in the gateway, and control in the field. We shall discuss each of them in the context of a WirelessHART mesh. Fig. 2 shows

A deterministic schedule is established for all communications by the network manager. Function block execution may be fully synchronized with IO communication. Gateways may be fully redundant.

C. Control in the Field WirelessHART only partially supports this approach. This approach is part of the Foundation Fieldbus standard in which a device supports a set of function blocks. A control loop could be realized exclusively among the devices by putting the function blocks in those devices together. WirelessHART has all the core features required to support control-in-thefield. It allows peer-to-peer session created between devices; It provides publish/subscribe capability; it has synchronized communications; and it has a fully defined user layer. However, it does not specify function blocks in devices. Putting function blocks in a WirelessHART device may not be desirable because:   

It forces device manufactures to understand control. There exist inconsistent implementations of function blocks. There exist inconsistent sets of function blocks in devices.



Running function blocks in devices increases battery usage by up to 3 times; stated another way, running function blocks in controller or gateway “plus” reduces battery usage in devices by up to 20 times by leveraging exception reporting techniques.

Fig. 5. Network Manager UI Display

Fig. 3. WirelessHART Gateway Design

which is not critical here since we are only interested in the communications. Fig. 5 is the screen capture of the network manager user interface after both devices have joined the network. In the network topology on the left hand side, the red node is the gateway, the yellow node is the access point, and the two blue nodes are the sensor and actuator. The numbers on the edges show the signal strength among the nodes. We can see that a mesh is formed among the three nodes. Table I is the address assignment. TABLE I DEVICE ADDRESS ASSIGNMENT

Fig. 4. Test Setup of Control in the WirelessHART Gateway

IV.

CONTROL IN THE WIRELESSHART GATEWAY

We contend that placing control in the WirelessHART gateway is the best approach. In this section we shall discuss experimenting with control in the gateway. Fig. 3 is our gateway design with the Function Block Application included. The Function Block Application could be run periodically or triggered by sensor input. Fig. 4 is our test set up. The gateway and network manager run on the laptop. The access point is connected to the laptop. We have a sensor, the Rosemount 648 WirelessHART H7 Temperature Transmitter, and a prototype radio board for the actuator. The test setup is not connected to a real process,

Access Point

0x0001

Sensor

0x0002

Actuator

0x0003

Gateway

0xF981

Network Manager

0xF980

In our test the sensor is configured to publish the primary value with Command 1 every 4 seconds. Upon the arrival of the sensor data at the gateway, the Function Block Application issues command 79 to the actuator, which responds back. Graph routing is used for packets sent to the gateway; source routing is used for the output to the actuator. In the source routing to the actuator we use the sensor as the routing device. We mentioned earlier in this paper that one way to reduce traffic is to publish values by exception. We do not employ this approach here. Rather the data is periodically transmitted. This is because we are interested in the data traffic reliability. We use Wi-Analys to capture the WirelessHART messages. Wi-Analys is a network sniffer tool from the HART Foundation. It captures packages on all 16 channels simultaneously. Fig. 6 is one screen capture showing the messages of our network while the control loop is being executed. Table II describes each of the columns in Fig. 6. In the capture, message #25618 is the sensor data sent from 0x0002 to the access point 0x0001. The gateway receives this

data, runs the control module, and sends actuator data to 0x0003, which is first routed in message #25624 from 0x0001 to 0x0002 which forwards it to 0x0003 in message #25632. Note that for demonstration purposes, we copy the sensor value to the actuator; the Command 1 payload in message #25618 is part of the payload of Command 79 in message #25624. The actuator receives the data, processes it, and sends the response back to 0x0002 in message #25639, which forwards it to 0x0001 in message #25642 which eventually forwards it to the gateway. This sequence is repeated in the lower half of Fig. 6.

There are other WirelessHART networks active during our test. Table III shows the networks and devices in those networks that we detected with the Wi-Analys. The first one with network ID 0x1240 is our test network. In 6 hours of the Wi-Analys run, about 240,000 WirelessHART packets were captured. About 106,000 of the packets were from our network. The packets were distributed over 15 channels from Channel 11 to Channel 26.

TABLE III ACTIVE WIRELESSHART NETWORKS

TABLE II WI-ANALYS DISPLAY COLUMN DEFINITION Network ID

Active Device Addresses

0x1240

0x442A

0x0001, 0x0002, 0x0003 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 0x0006, 0x0007, 0x0008, 0x0009 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 0x0006, 0x0007, 0x0008 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 0x0006

0x1E61

0x0001, 0x0002, 0x0004

0x73E3

0x0001, 0x0002

0x58AF

0x0001, 0x0003

0x0524

0x0001, 0x0004

0x0001

0x0001, 0x0005

Packet Number

Packet sequence number

PDU

WirelessHART message type

Net ID

Network ID

To

Data link layer destination address

0x05D4

From

Data link layer source address

Graph ID

Graph ID for routing the current packet

0x6FFB

Dest

Network layer destination address

Src

Network layer source address

Src Route 1

Source routing table 1

Payload

Decrypted network payload

Fig. 6. Wi-Analys Screen Capture of Loop Data Traffic

We did not measure if there is other wireless traffic in our environment. Since we run our test in our technology department office building, there is usually a lot of nonWirelessHART traffic around such as Wi-Fi, Bluetooth, etc. With the test environment described above, we recorded not a single packet loss in a run of almost 2 hours. During this run the gateway received 1651 burst messages from the sensor. Some observations and analysis are presented here based on our experiment. A. WirelessHART Supports Control Our control in the WirelessHART gateway experiment is built with actual WirelessHART device, gateway, and network manager. The noise environment and communication reliability prove that good control performance is achievable. B. Fastest Loop Let us assume that the communication delay between the gateway and the access point is negligible and the control module could be run quickly. We construct a star topology in which all devices are one hop from the access point. We can achieve a 20ms loop period: the sensors publish data in one timeslot of 10ms and in the very next 10ms timeslot the actuator data is transmitted from the access point. If we time the sensor to sample right before the transmission, the process sees a 20ms turnaround time from the controller. V.

CONCLUSION AND FUTURE WORK

In this paper we look at the issue of control over wireless in industrial process control. We focused on WirelessHART, the first international standard in this field. To achieve good control, we recommend running the control module in the gateway which is fully accommodated by the WirelessHART standard. Control in the WirelessHART gateway is reliable, and has less delay and hence good performance. Our experiment also supports the reliability claim of the WirelessHART standard. We plan to perform more experiments with our mesh environment in the future. We shall measure the delay and jitter in different setups; we shall test the fastest loop a WirelessHART mesh can support. Although our experiment generates all wireless traffic for closed loop control, it is not attached to a real process. We are building a real demo kit as is show in Fig. 7. In the design the liquid level in the small tank is to be maintained by adjusting the input valve. The level gauge sensor serves as the input device. Since currently there are no WirelessHART actuators on the market that can wirelessly receive Command 79, we put a WirelessHART adaptor between the traditional valve and the wireless network. We shall report our work with this real setup in the future.

Fig. 7. Design of a Control over WirelessHART Gateway Test Setup

REFERENCES M. De Biasi, C. Snickars, K. Landernas, and A. Isaksson, “Simulation of Process Control with WirelessHART Networks Subject to Clock Drift”. 32nd Annual IEEE International Computer Software and Applications Conference. [2] T. Blevins, G. McMillan, W. Wojsznis, and M. Brown. “Advanced Control Unleashed: Plant Performance Management for Optimum Benefit”. ISA Press, 2002. [3] D. Chen, M. Nixon, and A. Mok, “WirelessHART - Real-Time Mesh Network for Industrial Automation,” Springer, 2010. [4] S. Han, J. Song, X. Zhu, A. K. Mok, D. Chen, M. Nixon, W. Pratt, and V. Gondhalekar, “Wi-HTest: Compliance Test Suite for Diagnosing Devices in Real-Time WirelessHART Network.” Real-Time Technology and Applications Symposium, 2009. [5] J. Song, S. Han, A. K. Mok, D. Chen, M. Lucas, M. Nixon, and W. Pratt, “WirelessHART: Applying Wireless Technology in Real-Time Industrial Process Control.” Real-Time Technology and Applications Symposium, 2008. [6] J. Song, A. K. Mok, D. Chen, M. Nixon, T. Blevins, and W. Wojsznis, “Improving PID Control with Unreliable Communications,” ISA EXPO Technical Conference, 2006. [7] A. Willig, K. Matheus, and A. Wolisz, “Wireless Technology in Industrial Networks,” Proceedings of the IEEE, vol. 93, no. 6, pp.1130– 1151, 2005. [8] J. R. Moyne and D. M. Tilbury, “The Emergence of Industrial Control Networks for Manufacturing Control, Diagnostics, and Safety Data,” Proceedings of the IEEE, vol. 95, no. 1, pp. 29–47, Jan. 2007. [9] F. D. Pellegrini, D. Miorandi, S. Vitturi, and A. Zanella, “On the Use of Wireless Networks at Low Level of Factory Automation Systems,” IEEE Trans. on Industrial Informatics, vol. 2, no. 2, pp. 129–143, May 2006. [10] E.Tovar and M. Alves, “Real-time communications over wired/wireless PROFIBUS networks supporting inter-cell mobility,” Computer Networks,vol. 51, no. 11, pp. 2994–3012, Aug. 2007. [1]