This latency may be not important for most clients that retrieve fieldbus data from Internet/fieldbus gateways. Clients will often collect statistical/historic information, or will retrieve data that is not timing critical. These applications only need to know the exact time when the data was valid, which is accomplished by delivering a timestamp79 associated to a fieldbus value.
However, there may be applications where the timing is critical, such as for alarms or system notifications. In this case, the latency of the whole system has to be analyzed and mechanisms have to be implemented that guarantee a minimum delay.
Figure 33 shows that the overall latency consists of two basic delays, which could be called ``fieldbus latency'' and ``SOAP latency''. Most industrial automation fieldbus systems, such as Profibus, have real time capabilities. The fieldbus latency is predictable in this case and simply adds a fixed delay to the overall latency.
The SOAP latency, as depicted in figure 34, is not easy to predict as the underlying protocols on a LAN/WAN, such as TCP/IP and HTTP, are not real-time capable. Moreover, the encoding and decoding time of the SOAP messages may vary80.
As figure 34 shows, the delay is caused by three factors:
A possible solution to circumvent timing problems is to minimize the overall load on the network and the gateway. Moreover, it may be possible to implement an operating system on the gateway that has real time capabilities.
Minimizing the network load may not be easy: Figure 35 depicts a case where two workstations - unrelated to the fieldbus - produce a lot of network traffic causing a congestion on the LAN.
One possible solution to this problem is to set up a network path that is free from congestion. As this is not always possible, specific features of TCP/IP, such as ``Quality of Service'' (QoS) may be used to give the fieldbus communication precedence over other network traffic82.