Subscription Architecture

As denoted above, ESD does not provide equivalent functionality to OPC subscriptions. Therefore the OPC server has to implement this subscription architecture by itself. One way to do this is to periodically poll the ESD for a value of a fieldbus datapoint via an ESD READ command. However, OPC subscriptions are quite complicated issues and provide the following features:

Deadband:

The OPC client may notify that it is only interested in value changes exceeding a predefined limit. This is called ``deadband'' and is specified in the percentage of the current value.

Caching/Buffering:

If a value change occurs that should be recorded by the OPC server, it has to cache this value. Moreover, the client may request buffering, so that multiple value changes are stored until they are read by the client.

Multiple Subscriptions of the Same Item:

Multiple clients may subscribe to one item. This may lead to situations, where multiple polls on one fieldbus value are periodically issued while one read would suffice, which would greatly reduce the fieldbus load. On the other hand, it is not possible to easily replace one fieldbus read by another as the client may specify differing sampling rates¹³⁷ for each subscribed item.

Maximum Sampling Rate:

Sometimes it is not easy to predict how fast a datapoint value can be sampled. Some ESD READ commands may reply after a fraction of a second, others take 10 seconds or more. Moreover, the response time of these fieldbus requests may change, for instance, if there is a high network load, or a sensor needs more time for sampling data. Therefore situations may occur where the sampling rate is faster than the response time of an ESD READ. In this case, multiple READs would build up to an extent that exceeds capabilities of the fieldbus.

Manual/Automatic Termination of a Subscription:

Subscriptions can either be manually canceled or expire if the client does not poll the OPC server within a specified time (the ``ping rate''). When the subscription is canceled, every related periodic sampling must be stopped.

WaitTime/HoldTime:

The OPC client has to periodically retrieve changed values via a special operation, called ``Subscription Polled Request'' (SPR). The client may specify a ``hold time'' and a ``wait time'' which specify when the server responds. These parameters complicate the server implementation to some degree¹³⁸.

Due to these difficulties a suitable architecture had to be designed and implemented.

When a client subscribes to one or more OPC items, a subscription object is created, as depicted in figure 64.

Figure 64: Creating a Subscription Object

The function ``Subscribe'' first reads all requested items in a deferred style and adds a callback called ``addSubscription'' to prevent blocking of the server due to the read command. The callback function creates a subscription object, which is able to store all attributes and methods associated with this subscription. Then for every item the previously read value is cached and the two functions ``SampleItem'' and ``HandleSampledItem'' are created¹³⁹, where the second function will handle the output of the first. Next a so-called ``LoopingCall'' is started and stored in the subscription object, which periodically calls the sampling functions. The last step is to set up a delayed call that cancels this subscription and all related sampling functions. This way, subscriptions will automatically be canceled in case the OPC client does not query the server within the ``ping rate''.

Figure 65 depicts how caching and buffering of OPC Items are implemented in the current design.

Figure 65: Item Caching/Buffering Scheme

The function ``SampleItem'' first reads the fieldbus value in a deferred style. The result is handled by the callback function ``HandleSampledItem'', which stores the new value in the ``subscription cache'' in case it has changed<sup>140</sup>. If buffering is enabled for this subscribed item, the old value will be stored in the ``item buffer''. This FIFO-style buffer is not subscription specific and can store a predefined amount of items. If the buffer is full, the oldest entry will be deleted. In case a buffered item is lost, this event will be recorded by the subscription object so that it may notify OPC clients which retrieve buffered data from the server.

Figure 66 depicts an OPC ``Subscription Polled Request'' (SPR) which queries the OPC server for new values. An OPC SPR may query multiple subscriptions in one request.

Figure 66: Polling a Subscribed Item

After checking whether the specified subscriptions are valid, the polling of the subscription is blocked to guarantee that no other client may poll data from this subscription¹⁴¹. The next step is to cancel all automatic unsubscriptions, so that the subscription object is not deleted while a poll is taking place. Then the function creates a deferred and adds the callback ``PollWait'' in case the client specified a wait time and the callback function ``PollItems''. Then the server waits for the specified hold time and calls the next function in the callback chain.

If a client specifies a wait time, the server waits for the given time and returns immediately in case a value has changed or after the wait time has exceeded. Therefore the PollWait function first creates a deferred that is stored in the subscription object and sets up a WaitCancel function. This deferred will either be fired by the function ``HandleSampledItem'', which periodically checks for value changes and fires all deferreds in a subscription object, or by the WaitCancel function that is executed when the wait time has elapsed.

The function ``PollItems'' reads all changed values from the subscription cache and from the item buffer, denotes whether a buffer overflow has occurred and returns this data. Moreover, it establishes the automatic unsubscription function, so that the subscription is canceled in case the ping rate is exceeded.