Featured Topic
 

Which OPC UA Data Update Model Maximizes SCADA Efficiency?

Up until about ten years ago, I/O sensors were basic “dumb” devices that could only do two things: take a reading (temperature, pressure, event, etc.), and send the reading electronically over a wire. For this reason, the OPC (OLE for Process Control) standard was based on a client-server polling model. That is, a central OPC server would be configured to poll sensors for data. However, since the server would not necessarily know in advance when a sensor reading would change, the server might be programmed to poll various devices at frequent intervals, resulting in a big waste of network bandwidth.

Starting about ten years ago, companies at the vanguard of I/O technology introduced “smart” remote I/O servers that gave dumb I/O devices the intelligence they needed to initiate a connection with the OPC server. Moxa’s ioLogik series, for example, works with I/O devices’ at remote sites, and supports Moxa’s “Active OPC Server,” which uses “push technology” to allow dumb I/O devices to actively send readings to the OPC server.

In a more recent development, in 2008 the OPC Foundation standardized a “report by exception” concept in the OPC Unified Standard (OPC UA for short), which uses a “subscription and monitored item” model that gives engineers a bigger bag of tricks to draw from when designing their I/O systems. OPC UA is completely new, in that it allows users to work directly from their SCADA system to configure the way the OPC server interacts with the various I/O devices.

In this article, we explain the difference between “updating data by polling” and “updating data by exception,” give some general rules of thumb you can follow to decide which method is suitable for your various I/O devices, and introduce Moxa’s new MX-AOPC UA server solution.

Updating Data by Polling or Exception

As was alluded to in the introduction, for many years, “updating data by polling” was the industry standard for communication between OPC servers and clients. Now, however, engineers need to decide between updating data by polling and updating data by exception. Generally speaking, which option to choose depends on the frequency with which sensor readings change, and the required level of precision. Sensor readings that change frequently need to be sampled frequently to get a true picture of how the sensor readings change with time. On the other hand, for sensor readings that don’t change very often, you could end up wasting quite a bit of network bandwidth if you sample too frequently. Some background on how updating works with OPC UA should help clarify the difference.

OPC UA uses a “subscription and monitored item” function to manage data transfer between the OPC server and SCADA clients. With this methodology, a SCADA client subscribes to a set of monitored items, after which the server “publishes” the items’ readings based on a pre-configured frequency (Figure 1). In this case, “publish” simply means that the server sends the readings to the client.

Figure 1: Subscription and monitored item methodology

Two settings need to be configured on the I/O device to enable this function: the sampling interval and the publishing interval (Figure 2). The sampling interval defines the rate at which the server checks for changes in the monitored items, and the publishing interval defines the rate at which the server sends notifications to the client. The sampling interval can be shorter than the publishing interval, in which case notifications are queued in the server until the publishing interval has elapsed. At that point, the server sends all of the notifications in the queue to the client.

Figure 2: Subscription and monitored item settings for a sample client

With “update by exception,” since I/O readings are not transmitted when the monitored system’s status doesn’t change, operators can greatly reduce the amount of network bandwidth that’s required. This is especially true when the frequency of value changes is far less than the polling interval, such as is true when monitoring a door’s open/close status. Report by exception also saves computing resources on both server and client computers for handling timeouts and retries. Moreover, if the frequency of value changes is higher than the polling interval, and data precision is critical, updating data by exception is still the better way to go.

However, this method still may cause a lot of data to be transmitted in a very short time, which could cause network congestion. The congestion can be relieved somewhat by setting an appropriate “dead band” for analog data, or by trimming down the amount of data with numerical computing before data is sent out.

On the other hand, if the frequency of value changes is higher than the polling interval, and data precision is not critical (such as when monitoring the temperature of a liquid), update by polling might be more appropriate. Generally speaking, selecting whether to use polling or exception depends on the frequency of value changes and the critical level of value precision of the monitored items.

Most OPC UA servers use a poll-type protocol, such as Modbus, to get data from their devices. However, polling hundreds or thousands of tags is very inefficient. If both polling and exception options are available, you can determine the best approach by first categorizing device tags into one of four types (Figure 3), and then increase the efficiency of your operation by using poll-type methods on the high frequency but non-critical precision tags to update data to the SCADA system.

Figure 3: Selecting either polling or exception

Moxa’s MX-AOPC UA Server

MX-AOPC UA Server expands on Moxa’s patented “Active OPC” monitoring technology, incorporates support for Modbus protocol, and provides a secure and reliable gateway between local devices and a remote SCADA system. Moxa pioneered “push type” I/O processing (as opposed to “pull type” or simply “polling”) in the automation industry with the release of its “Active OPC Server.” The patented MX-AOPC UA server offers both a polling and non-polling architecture alongside the standard OPC UA protocol, giving users the choice of pull or push-based communication with Moxa devices (Figure 4).

Figure 4: Choice of push or pull type communication

MX-AOPC UA Server’s design logic is user-application oriented. As can be seen in Figure 5, users can create device groups, “SiteA” and “SiteB” for example, based on their application. In the example shown here, each site uses the same ioLogik E1210 unit to monitor pump status.

Figure 5: Application-based device groups

Tag names (Figure 6) are much clearer and more readable when it comes time to configure your SCADA system.

Figure 6: Clearer tag names

Moxa’s Broad Selection of Data Acquisition Products

Moxa provides a wide array of reliable industrial data acquisition solutions, including easy-to-use software, for general industry use. For details, visit http://www.moxa.com/product/MX-AOPC_UA_Suite.htm and see how Moxa’s data acquisition solutions can benefit your business.

Back to index