A common misconception about TOP Server as an OPC server is that TOP Server will poll your device/devices automatically with no OPC client connected. So, when you are getting started with TOP Server, it is good to have an accurate understanding of how interactions occur between each node of a basic OPC architecture— client-server and server-device— to ensure that the configuration meets your needs and can be scalable to more demanding projects.
Continuing our Tech Support Corner blog series, in this blog post, we will discuss some basics of the interactions between an OPC client and server, including different types of reads and the expected behavior that you'll see as a result of those interactions.
So, going back to the introduction, it's a common question our support team answers regarding whether or not devices in TOP Server get polled even if a client isn't connected. Or, rather than a question, many times that behavior of polling automatically without a client connected is assumed by some users. So let's discuss the basics of what you can expect when using TOP Server related to the client/server architecture.
What is TOP Server's Role as an OPC Server?
We'll assume that you're familiar with basic configuration in TOP Server for the purposes of this post - if you're new to TOP Server, you may want to watch our TOP Server quick start video. When a channel and device are defined in TOP Server, it does not immediately attempt to initiate a connection and request data. Instead, it will wait until a connected client specifically requests information from this device before reaching out.
And TOP server will only request the pieces of data the client/clients requested - if you have 1000 static tags defined in TOP Server, for instance, but your OPC client is only requesting 100 of those tags, then TOP Server will only request those 100 tags. And for dynamic tags being requested by a client, only the tags actually being asked for will be requested. For a discussion of static (tags defined in TOP Server) and dynamic tags (addresses requested by the client directly), click here.
TOP Server's role as a server dictates that data be served, and therefore requested, at the direction of a client application. This behavior eliminates unnecessary traffic on the network to your devices since there would be no requesting clients for any other tags that weren't requested and, thus, no reason to request them.
The only caveat to this behavior is when you're using the TOP Server Scheduler Plug-in. The Scheduler Plug-in acts as a client itself, requesting specified tags for a device or devices based on a set and configurable schedule.
That scheduled polling behavior overrides the traditional OPC client/server behavior and dictates when and which tags for a device will be requested from the device and all connected client applications will then be updated (not based on their requested update rate but from the server's cache of the last values received from the last scheduled poll). We'll talk more about the Scheduler Plug-in and about cache vs device reads shortly.
Defining an Interval for Device Requests
OPC clients can request data in one-shot reads (often referred to as demand polls), but often they instead will subscribe to data changes of the tags they need. Subscriptions are a more efficient method as they don't require the client to repeatedly send a request to the server every time the client wants an update. Instead, once subscribed, the server will simply perform a poll at the requested poll rate or frequency and, when the value has changed from the last update that was sent to the client application, the server sends the updated value.
That rate at which TOP Server requests subscription data from the device is again called the scan rate or poll rate or update rate or frequency (there are many synonyms but all refer to how frequently TOP Server will send a request to the actual device).
Now TOP Server supports a number of "scan modes" that affect the poll rate related to what the OPC client actually requests (these scan modes have multiple purposes such as insulating your devices on the control network from unruly clients requesting an update rate that is too fast for your network to handle). For more details on the Scan Modes in TOP Server, you can take a look at our other blog post: Tech Support Corner: Understanding TOP Server Device Scan Modes.
For any new subscriptions to the same tags with a different scan rate, TOP Server will reassess its scan rate to the device to satisfy all client subscriptions in the most efficient manner possible with the fewest number of optimized requests necessary.
With OPC UA subscriptions, clients also provide a separate rate for the server to use to provide data updates to itself. This property is called the update rate or Publishing Interval. TOP Server delivers any updated tag values from the last interval to the client independently of device communication. The decoupling of the client-server and server-device communications allows us to accommodate different needs of different clients with minimal impact to the device.
Understanding TOP Server's Internal Cache
When a client initiates a subscription with TOP Server, TOP Server will start to cache the subscribed tag values and keep the latest updated values retrieved from the device. When clients perform one-shot reads on a tag maintained in a subscription, unless a device read is specified, TOP Server will first look to provide the value within its cache.
OPC client read requests contain a value age or maxAge property that specifies how old the cached value can be and still be acceptable, and the server determines whether the cached value can be returned or if a device read is necessary because the cached value is "stale" or outside the acceptable age that the client application consider valid or current. The following diagram depicts the logic involved with a subscription read versus a single/one-shot read operation.
Cache reads are effective in minimizing the number of requests sent to a device and can improve communication in high-load systems with a large tag quantity or where rapid client updates are necessary but actual values aren't changing that frequently.
Taking Advantage of TOP Server's Cache
It is not uncommon for project architectures to require infrequent polls. In these scenarios, all tag values need to be retrieved periodically throughout the day— every 30 minutes, every few hours, etc. Large delays on the client side can occur when a high quantity of tags are requested at once, as TOP Server will need time to get the updated data from the device at the time it receives the request (which can take more or less time due to a variety of factors including the blocking capabilities of the communications protocol/protocols, the speed of the communications network, and more).
Additionally, the large payloads between server and device will significantly increase this response time, thus increasing the time it takes for a client application such as an HMI or SCADA to start seeing good quality and values. So our goal is to optimize communications such that the user experiences minimal latency.
We can avoid these client-side delays by leveraging TOP Server’s cache and the nature of the OPC standard’s decoupled communications (at least for subsequent reads - on first connection and reads, there will be no cached value to update clients from). If the client can retrieve its data from the cache for those subsequent reads, we will be avoiding the latency involved with the server-device exchange. One could even implement an intermediary client application that will always be connected to TOP Server for the required tags to ensure that the cache contains the necessary updated values that the client needs, thus avoiding the latency on startup. Since we do not care about delays in responses to the intermediary client (since it wouldn't be the primary client used for visualization and other upstream needs), we only need to ensure that the data is returned in time for the primary client’s next poll cycle.
As mentioned earlier, TOP Server includes a Scheduler Plug-in feature (licensed as an add-on feature) which can actually be used as this intermediary client to request data and populate TOP Server's cache independent of other upstream clients. The Scheduler Plug-in provides the ability to control communications to connected devices. You are able to define the specific devices and tags included in the scheduled polls as well as polling windows, so the configuration can be fine-tuned to best accommodate all clients.
With the Scheduler Plug-in, it's important to understand, though, that if the Scheduler is used for any of the tags for a specific device, it must be used for all tags for that device. All tag updates with the Scheduler plug-in will be from cache, which is updated based on the configured schedule frequency. It is, however, possible to perform a demand poll of all items on a device or schedule via special system tag write from any client.
To learn more about the Scheduler Plug-in, please see the plug-in details page here: TOP Server Real-Time Polling Engine Scheduler Plug-In.
I hope this information will be useful to you as you design and configure your own communications using TOP Server. Please feel free to contact our support team with any further questions you may have about polling behavior with TOP Server, the Scheduler Plug-in or other questions and don’t forget to subscribe to our blog to find out about the latest updates, tips and suggestions for TOP Server.
