It's common with OPC for users to not realize that it is the OPC client that typically defines how quickly the OPC server should poll or send requests to the underlying control devices and equipment the server is communicating with.
This blog post will discuss how important it is for an OPC tunneling solution to have some level of control over this frequency of polling in order to maximize efficient usage of your precious bandwidth.
It is an important aspect of using OPC to understand that the OPC client typically determines how quickly an OPC server polls a control device. In order to understand the importance of this factor, you first need to understand how the rate at which an OPC server will poll field devices or control devices is determined. OPC Servers typically will not poll field or control devices if no clients are connected. When an OPC client connects to an OPC Server, one of the parameters it passes is a “Group Update Rate”. The OPC client can setup multiple groups with different update rates when it connects to the OPC server, and put different tags in each group based on the desired polling rate.
Currently in the process of choosing an OPC tunneling solution? Learn more about compatibility considerations and other variables in our free whitepaper "25 Considerations when choosing a tunneling solution".
The OPC server then looks at all connected clients and their requested group update rates and optimizes so that it polls field or control devices fast enough to satisfy the fastest Group Update Rate for each tag or item, but no faster. This capability is part of how the OPC technology, when implemented properly, provides better performance than letting clients like HMI systems talk directly to your field or control devices.
The problem occurs when a client is mis-configured. For example, picture a system where your clients were all setup for 1000 ms or 1 second Group Update Rates, and you know that is a proper update rate for your systems. Someone configures a new client connection and they mistype and enter 100 instead of 1000. Now they have increased the polling rate for all tags in the group they added to 100 ms - 10 times what you know your systems can handle.
Imagine that group had 10,000 items in it, or even 1,000 items. That one client has now caused the update rates of every other client to slow, while the OPC server struggles to get the data at 100ms rates. This is not a limitation of the OPC server, it’s a limitation of the control network that can’t handle that update rate.
How do you prevent that OPC client from getting that 100 ms rate? The OPC specification covers this in that it allows an OPC server to reject a requested update rate and throttle it. Not all OPC servers have implemented this capability, and for those that have not, an intermediary like an OPC tunnel solution can act as a sort of "buffer" and allow you to control the actual rate requested from the OPC server.
Some tunneler solutions do have the ability to allow the user to configure update rates in ways that effectively serve to throttle and protect the OPC server from clients with unrealistic expectations. The device polling rates passed to the downstream OPC servers are handled in such a way that ensures the OPC Client connected to the tunneler does not control how fast the devices are polled from the OPC Server. This is accomplished by you specifying the polling rate in the tunneler on the OPC Server side of the tunnel.
When the OPC client makes a connection to its local tunneler component, the update rate set by your OPC Client is only how fast the OPC client expects updates from the local tunneler. This allows the user of the tunneler on the OPC Server side to configure an update rate that will not overload the devices or the process control network.
Choosing a tunneler that supports configurable OPC server request/update rates instead of simply passing through the client-requested rate will ensure your control network is safe from unruly clients, minimizing any overconsumption of bandwidth on your network.
The ability to control bandwidth and polling frequency is just one of the many considerations when choosing a tunneler - learn about the other variables you should be considering in the free whitepaper “25 Considerations when choosing a tunneling solution”.
