System Notifications

Fieldbus clients are often interested in value changes. An example would be an alarm system that logs the value of a sensor that reports whether a door is open or closed. Many fieldbus systems support this technique by so-called ``System Notifications''.

This mechanism cannot be mapped directly to the communication between Internet/fieldbus gateways and their clients, as the underlying protocols differ. HTTP is a request/response protocol and does not provide means for system notifications. The only way for HTTP-based communication is polling, which means periodically reading data from the gateway. Implementing system notifications by periodic polling contains the following problems:

High Network/System Load:

Periodic polling causes a high network and system load, as periodic SOAP messages have to be sent over the network processed by the gateway.

Data Loss:

If data changes are faster than the polling period, data loss occurs. If for example the door sensor in an alarm system is set to ``open'' for only 5 seconds and the polling period is set to 10 seconds, the client may never know that the door was opened, as depicted in figure 36.

Figure 36: Polling and Possible Data Loss

This problem may be solved by implementing buffers in the gateway, which store all datapoint changes until they are fetched by a client. The appropriate size of these buffers is related to the time between the polls. More information about buffering can be found in [OPCXMLDA].

Notifying the client by other means than polling is only possible in the following two ways:

1. Client implements a server:

If the client implements a server that listens for notifications, the gateway directly informs the client in case of value changes. Theoretically, it would be possible to establish a Web Service on the client, which can be used for system notifications. The problem with this approach is on the one hand additional complexity and on the other possible security restrictions. Very often, clients are situated behind network firewalls, which disallow incoming connections to clients.

2. Client holds the connection open:

Another solution would be to open a connection to the server which is never closed, so that possible system notifications may be sent directly.

[OPCXMLDA] introduces an interesting technique, called ``Advanced Subscription'', as described in chapter 3, where HTTP requests are not answered immediately. Instead, the connection is held open until a value changes, or a timeout occurs. This method greatly reduces the network and gateway load. However, HTTP was never designed for such a case and it is possible that other timeouts⁸³ could lead to unexpected problems.

Theoretically, it would be possible to use other protocols for transporting SOAP messages that keep an open connection between the client and the server. However, such protocols are not supported by current SOAP frameworks, moreover, security regulations will eventually block these protocols.

SOAP messages may also be transported by other means than HTTP. Therefore it is possible to choose another protocol that is more suitable for system notifications. One possible protocol is SMTP, which is well known for transporting E-Mails over the Internet. SMTP is simple and a lightweight protocol and it is widely adopted. Moreover, some SOAP frameworks already support SMTP.

Clients would request to be informed, whenever certain datapoint values change. In such a case, the gateway would encapsulate the SOAP message with the fieldbus data in the SMTP protocol and send it to the client, just like an ordinary E-Mail. This way, the gateway load will be greatly reduced, as there is no polling.

The problem with SMTP is that the delay cannot be predicted in any way. SMTP messages may be routed over various relay stations, which may delay them for an unknown time. In case of errors, the sender is notified - but this may also take considerable time. Moreover, the client also has to poll some server for the SMTP message⁸⁴, which adds an additional delay.