Process control is about "real time." However, as we know, the definition of real time is a function of the process itself. Profinet is a technology that reflects the realization that the requirements of real time differ by application. The standard has several different versions, including isochronous real time (IRT) for factory automation installations that need microsecond or better resolution.
Fortunately, most process industry applications are much slower than that, thus making it possible to use wireless for closed-loop control. But, just as we need to consider the response time of a thermowell in a temperature measurement, in wireless networks, the lag time for the signal must also be considered prior to implementing wireless control loops.
Looking at the sources of delay in a wireless control loop means we need to consider that every hop in the network not only adds delay (wake-up, receive, transmit) and affects battery life for sensor mesh networks such as WirelessHART, ZigBee and ISA100.11a.. However, being mesh-based means that, though the routing will normally remain unchanged, the path may not always be the same.
The fastest response time that can be expected is if the analog input (AI, transmitter) and analog output (AO, valve) are on the same network and connected to the same gateway. Work by Konovalov has demonstrated that, realistically, WirelessHART round-trip message time is approximately 1 second if there are less than 20 nodes in the network. It also shows that a significant portion of the delay is not with the wireless network itself, but with the routing of the messages and with the bridge or gateway.
Of course, our control loop also needs the regulatory control algorithm (PID or similar) to relate the setpoint to the AI and determine the appropriate AO value, so additional time is necessary for communications between the gateway and the control system, where this algorithm runs. The synchronization of the wireless network with the controller scan rate can cause additional delays. Without proper synchronization between the controller and gateway, it's likely that the output is being manipulated by an input from at least one scan earlier.
Fortunately, in most processes, the AI does not change significantly between scans or updates, so the above effect should be minimal.
One solution to this concern is to take out the requirement to talk to the controller by making smarter gateways with basic regulatory control functions built in—much like what is done with SCADA systems. This will reduce and effectively eliminate the risk of synchronization timing mismatch or breakdown of wireless backhaul to the timing of any parameter other than sending a setpoint to the gateway/controller device.
Compromise of backhaul network integrity is the expected case with SCADA systems. It's the reason they contain both buffer and the ability, either themselves or in the controller(s) to which they're connected, to maintain control at the last setpoint (as a minimum).
For larger networks, such as SCADA and long-distance SCADA for pipelines or where multiple-tower microwave and/or satellite communications are involved, the delay can become more significant and certainly on the order of several seconds.
The Foundation for ROM project is, to some extent, already building "smart gateways" with FF control-in-the-field and remote I/O capabilities in the remote signal assemblies and the FF PID function block itself. With the recent proposed merging of HART and FF, it's likely that HART or at least WirelessHART will get access to control-in-the-field technology soon.
Can wireless be used for real-time control? The answer is a qualified "yes." Just be sure you understand your real-time requirements, as well as all the potential lags/response times of all the elements in your control loop. Also remember that, for a mesh network, the response time may be also be a function of the communications path.