next up previous contents
Next: Operation Specific Functionality and Up: Item Caching and Subscriptions Previous: Item Caching   Contents

Subscriptions

In order to observe OPC items, one could theoretically periodically poll OPC items with read operations and check for changes. However, such polling leads to an unnecessary network and server load. Therefore [OPCXMLDA] introduces so-called ``subscriptions'' and specifies three related OPC operations.

OPC clients may subscribe to items, which basically commands the server to observe these items for changes. Such changes will be stored by the server and can later be retrieved by the client.

Implementing such a subscription mechanism in the server is quite complicated. The OPC XML-DA specification describes several complex issues, such as deadband (recording items only if they exceeded a predefined value) and the so-called extended subscription architecture. A detailed description of these topics is given in [OPCXMLDA].

To ease the development of OPC XML-DA servers, the PyOPC framework implements a default mechanism for subscriptions which is automatically available and functional for all OPC XML-DA servers based on the XDAServer class. The basic idea is that most underlying systems such as fieldbuses have a read operation that is roughly similar between different systems, while system notifications - a common way to observe datapoints for changes - can be very different on fieldbus systems. Therefore the most compatible way is to utilize the read operation for subscriptions.

Therefore developers only have to implement the read operation and will thus automatically enable subscriptions. The basic mechanism is illustrated in figure 9.

Figure 9: Subscriptions in PyOPC
\begin{figure}\centering
\includegraphics[scale=0.7]{graphics/pyopc_subs.eps}\end{figure}

It can be seen that a client can utilize the following three operations to handle subscriptions:

PyOPC also covers all complex subscription-related issues, such as the PingRate, HoldTime/WaitTime, deadband and more, therefore developers do not have to deal with these issues.

The following functionality can be configured in the server object:

BufferSize:
All OPC subscriptions share one buffer, which is used to store changed items until they are fetched by the client via the SPR operation. With the BufferSize attribute, the number of items can be specified that the buffer can hold. If more items than this number are stored in the buffer, the oldest entries are lost.
SubscriptionPingRate:
If the client did not specify a ping rate, this predefined value will be used. The ping rate defines, how much time may elapse between two client polls. If the ping rate is exceeded, the subscription is automatically canceled.
MaxPingRate:
This is the maximum ping rate, a client may specify.
MaxSamplingRate:
As denoted above, the subscription object periodically fetches (samples) item values from underlying devices. This sampling can be very demanding for the underlying system, therefore a maximum sampling rate can be specified in the server. If a client requests a higher sampling rate than this value, it is revised to this value by the server.

OPC server developers should set this to a suitable value: the maximum sampling rate should never be higher than the time that is needed for a read request.

It should be denoted that PyOPC allows only one SPR for one subscription object at a time. If a second concurrent SPR is issued, the server will return an error16.

An OPC server developer may also implement his own subscription mechanisms. This can be done by overriding the three XDAServer methods Subscribe, SubscriptionPolledRequest and SubscriptionCancel, however, this will most often not be necessary.


next up previous contents
Next: Operation Specific Functionality and Up: Item Caching and Subscriptions Previous: Item Caching   Contents
Hermann Himmelbauer 2006-11-07