Process Control Adopts Wireless - Emerson Process Experts

By Mark Nixon, Rusty Shepard, Aloysius K. Mok, Bill Bennett, and Deji ChenMiddleware approach precludes idiosyncrasies of wireless.Wireless is all the rage.We do not need to repeat its benefit here. Itsuffices for us to say that those who ignore itrisk missing the biggest opportunity.In essence, wireless technology is about data transmission,and data transmission is a key part in processcontrol. The benefit offered by wireless network isappealing for process control. An example is offshoreoil drilling where systems on land communicate to systemson drilling platforms. In places where wire is difficultor expensive to deploy, satellite communicationmay be the best choice. Using commercial wireless networkmakes possible process control that was previouslyunachievable.Communication bandwidth, disturbances, and costhave been very real impediments to moving monitorand control techniques into a much wider set of problems.Oil exploration, production, and distribution areareas where improved control would provide considerablebenefits.Challenges of deliveryThere are three layers of networks in a distributedprocess control system. Level one is between the smartdevices and the controllers; level two is among the controllersand the workstations; and level three is fromthe workstations to the outside world.Level one runs the process. It has tight real-timerequirement of high predictability and reliability. Thenetwork protocols are usually industry standards likeHART, Foundation Fieldbus, DeviceNet, and the like.Level two supports user interaction, including configuration,control, and monitoring. It has less timingrequirement than level one, but still requires good reliability.The network protocol could be proprietary orindustry standards such as Ethernet. Level three is the

WIRELESS AUTOMATIONA distributed process control systemgateway of the control system to other corporate systems,like accounting, inventory, and managementdecision systems. It would be nice to have good supportat this level, but conventional networks like officenetwork, intranet, and others are in use.Wireless acts as a kind of network, and it can targetany of the three network levels of a process control system.Level one requires reliable short-range data transmission.Data package sizes are small, usually less than100 bytes. There is much debate on whether wirelesscan work at this level. Of different wireless technologies,ZigBee, Wi-Fi, Bluetooth, and Ultra Widebandwork well at short range. One could implement fieldbuson top of them, or define new process control fieldbusstandards for wireless communication. Self-healingmesh technologies such as those developed byEchelon are finding a place in this space.Level two networks have longer transmissionranges and bigger data package sizes. They havestricter requirements than COTS networks. People inthe process control industry are already using wirelesstechnology at this level. Satellite, Wi-Max, andthe like, support long-range wireless transmission;microwave and radio work for shorter distances. Incomparison, bringing wireless to the third leveldraws far less concern from people of process control.Any conventional methods to replace wire linewith wireless in non-process control world apply tothis level.Wireless as a new type of technology could introducenew support for a process control system.Wireless has applications in display and handheldfunctions as well. For example, people talk about ahandheld device that could retrieve data wirelesslyfrom field devices.Wireless has its own challenges compared with wireline,such as bandwidth, delay, noise, security, etc. Datacommunication in process control introduces furtherchallenges like delivery guarantee, delay guarantee,continuous data request, and asymmetric data traffic.When a wireless network is to do the process controlwork, even more challenges add up, such as reliabilityand cost structure.The difference between wireline and wireless is bigat the lower layer, but at a higher layer, the differencescould be merely different parameter values, especiallywhen both implement the same network protocols.Network provides supportThe approach we look at is replacing the wireline networkin a process control system with a wireless one,with minimum possible change to the existing controlsystem. We will look at replacing the level two networks.We will assume the existence of the control systemwith wireline networks. This means building a newcontrol system from the ground up. Assume the leveltwo uses standard network protocol. If the wirelinenetwork uses proprietary protocol, the wireless versionwould have to implement the same protocol in ordernot to re-implement the control system. Assume astandard protocol enables us to apply COTS wirelessnetworks. Since almost all COTS wireless networkssupport TCP/IP, we further assume, without loss ofgenerality, the control system uses TCP/IP to communicatebetween the distributed workstations and controllers.In this way, the control system runs, but withflaws, if we substitute the wireline network with thewireless counterpart.If the wireless network provides the same support asthe wireline network, our job is over. Unfortunately, wehave to continue to address the difference and its effecton the performance of the original system of wirelinenetwork. In the following, we shall define the frameworkto mitigate the flaws.First, we’ll define the middleware that captures thespecifics of the wireless network. Then we’ll look athow the specifics propagate during runtime. Then wetalk about the necessary changes required for the controlsystem. We think it is not possible without changesto the control system. Finally, we’ll look at the angles toobserve when configuring a control system with awireless network.We assume a basic commercial wireless networkoffering, on top of which we build a middleware forprocess control data communication. The middlewareprovides an application programming interface (API)to the process control system.The control system sendsdata to the middleware with transmission constraintrequirements and little knowledge of the underlyingwireless network.The API provided by the middleware for the controlsystem supports regular data communication, such asinitialize, open, close, send, receive, acknowledge, andcancel. The middleware executes these commands bycalling the corresponding functions at the lower layer.In addition, the middleware will monitor the performanceof these calls. This registers as a set of parametersin the middleware. The difference of parameter valuestells the difference of the underlying wireline and wirelessnetworks. The parameters will keep track of thefollowing, some of which are configurable:• Flag indicating if the node is on the network• Type of network connection• Message timeout value• Message round-trip delay• Number of message retries• Flag indicating encrypted data and type ofencryption• Flag indicating if the node has a redundant

WIRELESS AUTOMATIONnetwork connection• Auto message timing indicating whether the lowlevel automatically calculates the message timeout and re-tries based on round trip timing or theof configured values• Flag indicating if there is failed communicationsor bad integrity• License information• Security informationExecution of the middlewareDuring execution, the middleware carries out thecommands from the control system and maintains theparameters current. Ideally, the middleware would beable to adjust itself automatically by taking intoaccount the response time, bandwidth, number ofpackets, number of unacknowledged packets, delaytimes, and cost—perhaps even choosing betweentransmission media based on time-of-day.One major work the middleware should perform isto maintain network connections. Wireless networkcould be intermittent. The middleware should handlethis gracefully. Depending on the configuration, theconnection could be permanent between two nodesor could be ad-hoc whenever connection is available.In the case of redundant connection, the middlewareshould switch between primary and standby connectionswithout the notice of the control applications.The middleware could add variable retry and timeouttimes for each connection to account for propagationdelays. Alternatively, it could allow multiple outstandingmessages for more efficient use of bandwidth.During active data transmission period, the middlewareshould perform a suite of housekeeping tasks.These include:Round-trip delay timing: The initial round-tripdelay is the time between the synchronous requestand the synchronous response during connectionestablishment. The round-trip delay should updateover time by timing the delay between sending a messageand the receipt of an acknowledgment. Roundtripdelay value adds to the message header to communicatethe initial value to the passive end of theconnection and to keep both ends of the connection inagreement of the current value.Send message processing: Remote connections needto have the ability to support multiple outstandingsent messages. We could add a window parameterthat defines the limit on how many messages are to beoutstanding at a time, change the message sendingfunction to send all messages on the pending messagequeue up to the window limit, request an acknowledgmentonly on the last message sent, and add atimer to trigger sending messages that have queuedwhile waiting for an acknowledgment on a previousmessage.Receive message processing: When acknowledging amessage, copy the time sent value from the receivedmessage into the acknowledgment message. This willwork to calculate round trip times and will provide amechanism for validating that the acknowledgment isassociated with the acknowledged message. When anout of order message arrives, return an acknowledgmentfor accepted messages to that point. This willprevent messages that have already successfullylogged in but not acknowledged from undergoingneedless retransmission. When an acknowledgmentcomes back, the time sent value checks against thetime sent value in the message undergoing acknowledgement.If these times match, the round-trip timeaverages into the round-trip time value.Retry and timeouts: To support multiple outstandingmessages, each message must have a timeout value,not one time for the connection. As messages receiveacknowledgement, they drop from the acknowledgmenttimeout queue leaving the remaining messagesto time out at their proper times. An acknowledgmentmay acknowledge multiple messages. All messageswithin the window that precede the sequence numberundergoing acknowledgement get their acknowledgementand drop off the retransmit queue. The systemignores acknowledgments for messages withsequence numbers that are not in the window.Management of the retransmit queue must handletiming out multiple sets of messages sent at differenttimes with each message given the same fixed amountof time to remain on the retransmit queue before timingout. The retry value should depend on the configuredtimeout or the round trip delay. If the round-tripdelay is used, the retry value is a minimum, and theround trip delay multiplied by two. The timeout valuefor a link bases on the number of retries for a link.Slower, perhaps less reliable, links may use a largercount.Message packing and unpacking: To better utilizethe given bandwidth on a remote connection, it maybe desirable to pack as much information as possibleinto each packet. This mechanism is only valuable if itis common for several small messages to be queuedwaiting for a message to be acknowledged or for thewindow to open up. To accomplish this, one may needthe following enhancements: As messages drop fromthe pending message queue, if two or more messageswill fit in a single message buffer, the system will allocatea large message and all available messages thatwill fit copy into the large buffer. As messages arereceived that contain more than one message as aresult of being packed by the remote peer, new receivemessages are allocated and data is copied from thepacked message into individual message buffers to beprocessed. All messages contained in a single messagewill list under a single acknowledgment of the lastsequence number on the packed messages.Other optimizations: The extra middleware layerenables many kinds of optimizations. If severalapplications request the same data, we would getmultiple requests for the same data sent over thewireless link. For remote network connections usingsatellites, modems, or other slow or delayed transmissionmedia, we could collect up the runtime dataon the remote side of the network over the satellite(or other slow connection) and distribute it out tothe other side. This reduces the amount of messagetraffic sent over the slow network. The remote appli-

WIRELESS AUTOMATIONcations would then get their runtime data from thelocal middleware instead of requesting it over thesatellite link.Finally, the middleware should handle link integrityand security. Since we are allowing remote connectionsthat may connect via satellite or microwave type connections,we will need to provide security measures toprevent someone from being able to sniff the networktraffic and break into the system. Providing the optionof encrypting messages on the remote network connectionsshould is necessary.The middleware is a new component in the system.It has to be developed. This may be extra work for thecontrol system.It is impossible to run the wireline version of thecontrol system without any change on this frameworkof wireless. Even if the middleware supports the sameset of APIs that the control system invokes, the controlsystem still needs additional function to accessthe set of parameters in the middleware. Of course, ifthe control system and the middleware grow uptogether for the wireline version, switching to wirelesscould be much easier. The goal of the approach is tomitigate the difficulties introducing wireless toprocess control. For wireless network, the control systemshould configure and monitor the middlewareparameters. The control system could rely on the middlewarefor wireless communication, but the moremonitoring by the control system itself, the bettercontrol will be.Between two dedicated nodesGiven a wireless control system, how one configures itmakes a lot of difference. We have talked about how todevelop a wireless control system. Here we discussissues involved in deploying a wireless control system.Consider a setup with only one wireless connectionbetween a workstation and a controller. The workstations,however, connect using hardwire as are the controllers.This reduces the wireless exposure and shouldresult in better data quality. Many real applications canonly afford wireless communication between two dedicatedremote nodes, which act as the gateway for alltheir local nodes.Another important issue is the types of data transmittedacross the wireless networks. As wireless is less reliablethan wireline, a system needs to configure suchthat only necessary data passes through the wirelesslinks. For example, configuration database can go wheremost of the download happens; historian data archiveswhere the data source is; diagnostic data retrieved ondemand; large quantity of non-time critical data transmittedbetween production phases, and other scenarios.Now we’ll apply this idea to analyze an oil extractorcontrol system.The mechanism works this way. A canister lowersinto a well, and after some time it fills with oil. Theentire assembly then returns to the surface.The collectedoil then meters and pumps to a storage tank. It’s anDedicated wireless nodesentirely automated procedure. Radio wireless links to amaster communicator, which then employs cellulartechnology to communicate with operators.Some of the system requirements are:• Allow users to remotely command the oilextractor unit.• Allow users to locally operate the oil extractor witha hand held unit.• Detect abnormal situations like leaks, pluggedlines, and salt-water.• Provide auto calibration and metering.• Upload measurements and events to host throughcellular links.• Provide security to prevent an unauthorized userfrom tampering with metering information.The wireless network used by the oil extractor providesperformance statistics and cost structure. For example,we found the communication over Global System forMobil Communication (GSM) using Short MessageService (SMS) messages encounter transmission problemsbetween 7 p.m. and 9 p.m. Monday thru Friday.The pricing structure of satellite tends to be forbandwidth. For cellular, it is a combination of packetsand bandwidth. One advantage of using cellular is theability to send abnormal situation events to individualsor response centers.The middleware dynamically adjusts to the networkperformance to send data with the best result. Some ofmiddleware’s considerations are:• The effective bandwidth of a GSM or satellite network may be less than advertised due to overloading,noise, and other problems.• In the case of satellite communications noise is asignificant issue, while in the case of a cellular network traffic is very real issue.• Since the delay times with satellite communicationsis significant, we could send many packetsout and acknowledge in bulk. .• With cellular at 2-5 cents per packet, it makessense to keep the packets as large as possible bycombining several data packages.✍ Behind the bylineMark Nixon is lead system architect and Deji Chen is a softwareengineer working at Emerson Process Management with RustyShepard and Bill Bennett. Aloysius K. Mok is associated with theDepartment of Computer Sciences at the University of Texas. This articlecomes from their ISA 2004 technical paper presented in Houston. Readthe entire paper at http://www.isa.org/intech/feb2005/wirelessfeature.Reprinted with permission from InTech, February 2005.© 2005 ISA Services, Inc. All Rights Reserved. FosteReprints 866-879-9144Form D351312x012/PDF 02/05