OPC XML Data Access (OPC XML-DA)

As denoted above, this standard describes accessing plant floor data through an OPC Server utilizing Soap Web Services technology and is therefore of a special interest for this thesis. OPC XML-DA compliant servers may be bundled with an OPC DA 3.00 server and act as a front end but may be also stand alone.

The specification is accompanied by a WSDL document that must be used when building web applications complying to this standard. The specification on the one hand consists of WSDL fragments that basically are XML Schema definitions which specify various SOAP messages. One the other hand it includes specific architecture definitions that describe special issues like subscription, buffering and error handling:

Supported data types:

The OPC XML-DA specification is based on the OPC DA Server which relies on COM/DCOM technology. For compatibility reasons, OPC XML-DA inherits the data types from the COM/DCOM environment.³⁰ These are represented by SOAP/XML Schema data types and cover simple types like strings, integers and date/time types and also enumerations and arrays.

Available services:

The following services are supported and their structure, parameters and behavior are precisely defined in the standard:

Status:

Provide status information about the server.

Read/Write:

Synchronously read and write data from and to OPC Items. These basic operations are illustrated in listing 9 and 10 as given in [OPCXMLDA].

Subscription:

OPC Clients can subscribe to specific items and will be notified whenever values change.

Browse:

Used for searching and listing available OPC Items on a specific OPC Server.

Properties:

Get OPC Item properties.

language=XML

language=XML

Subscription architecture

: Basically there are two ways of obtaining data from OPC Servers: Polling and Subscribing. Polling means checking for new data with simple read operations, which is perfect for acquiring data once in a while. In automation systems it is often necessary to handle events. Such events are often simply value changes of plant floor devices, such as sensors or switches. Although polling of these devices is a viable solution, there are many disadvantages of this technique such as high server load, high communication overhead and possible outdated values. A better approach in such situations are notifications, where devices send messages to the client which indicate that data has changed. This solution requires that clients inform the server that they want to be notified if values change. This is called subscription.

Subscription naturally raises problems with SOAP Web Services as SOAP messages utilize the HTTP protocol for data transport. HTTP is a stateless request/response protocol and is designed for communication situations where a client fetches data from a server.³¹ Asynchronous data transfer with HTTP is therefore impossible by design.³²

OPC XML-DA suggests a workaround to the limitations of HTTP by introducing a technique called ``polled subscription''. This way the client initiates the subscription and issues periodic refresh requests. The associated response messages will then contain all data that was updated since the last poll. As subscripted polling poses the same problems as generic polling, such as high server load and outdated values, OPC introduces a more sophisticated approach by delaying the server replies of refresh requests. This technique is described in figure 20. The left diagram depicts the simple case where the server does not delay replies. The middle and right diagram introduce server delay times.<sup>33</sup> During the ``wait time'' the server waits for occurring data changes. If data changes occur, the server immediately sends a reply message with the updated data. This technique provides huge advantages concerning communication latency and network traffic. Further information about polled subscription can be found in [OPCXMLDA].

Figure 20: Simple and Advanced Refreshed Polling

Buffering:

In case of subscriptions, there can be situations where more than one data change occurs within one polled refresh cycle. In order to prevent data loss, OPC Servers provide buffering, which means that a certain amount of data changes can be stored in a buffer. At a polled refresh, the server sends a reply message with all changed values stored in the server's buffer.