Image Processing Reference
In-Depth Information
data link layer [,] or the application layer (in the way safety profiles introduce additional protocol
features like transaction numbering to safeguard the communication).
Another fundamental problem with tunneling concerns the response time of the IP channel estab-
lished over the fieldbus. IP is basically a peer-to-peer protocol, which means that any node must in
principle be able to initiate a communication at any time. In particular in master-slave fieldbus sys-
tems, this cannot be guaranteed easily because slave nodes cannot become active without being told
so by the master. If in addition the fieldbus is slow, the latency introduced by the polling cycle might
lead to troubles with (often hard-coded) timeouts in the protocol stacks used on the nodes in the
IP-based network. he fact that data transfer between a fieldbus and an IP-based network is normally
limited to client-server communication does not help either. Typically, the field device provides the
server and the client is, e.g., a configuration tool in the outside world. One could expect that in this
case, excessive polling latencies do not occur—provided, of course, that the access point is also the
fieldbus master. Unfortunately, if TCP is used as transport protocol (like in the popular applications
of embedded Web servers), the delivery of requests and responses is inherently asynchronous. hings
getworseiftherequestandresponsepacketsexceedthemaximumsizeoftheieldbuspayloadand
must be fragmented. he additional traffic needed to transfer all fragments will expand over subse-
quent polling cycles, further deteriorating the end-to-end delay in the IP channel. For a reasonably
efficient tunneling of IP over a slow master-slave fieldbus, it would be necessary to influence the
polling cycle directly from the TCP stack, which is not a viable solution. Consequently, tunneling is
possible only in multi-master fieldbusses or in sufficiently “fast” master/slave systems.
Despite the conceptual problems, tunneling approaches are available even for master-slave field-
busses. Within the scope of the R-Fieldbus project, the feasibility of IP over PROFIBUS to include
multimedia data streams was demonstrated []. Apart from this research project, IP tunneling solu-
tions have been developed for Interbus and WorldFIP. Interbus is an extreme example, because the
IP traffic is transported in a communication channel similar to the parameter channel [,]. [,].This
channel has only a small capacity of, say, eight bytes per cycle in order not to interfere with the real-
time process data, and one byte is needed for control purposes. Depending on the size of the network
and the selected baud rate, one cycle may take a few milliseconds. As an IP packet usually is of the
size of several hundred bytes, it is evident that the performance of the IP channel is rather limited.
In WorldFIP, the situation is better. IP packets are transmitted in message frames outside the time-
critical section of the bus cycle. he messages can be up to bytes long and are thus large enough
to avoid excessive fragmentation []. Together with a high raw data rate on the fieldbus itself, this
offers a reasonable IP channel that is being used in practical applications, e.g., for embedded Web
servers inside field devices [].
20.6.1.2 Fieldbus Data Tunneling over Backbone Networks
The tunneling variant where fieldbus messages are encapsulated into IP-based protocols and pro-
cessed at a distant node is less relevant in practice as far as actual implementations are concerned.
Nevertheless, there are applications. One is to connect remote fieldbus segments over a backbone
network. A wide field of application for this concept are network-based control systems, for instance
in building automation [,]. Like in the reverse case, the latency introduced by the tunnel itself
and the protocol handling at the endpoints matters. It is therefore not astonishing that research work
was devoted to solutions involving ATM as backbone. ATM offers sophisticated QoS mechanisms
which ensure bounded transmission delays and therefore are basically able to retain real-time char-
acteristics of the fieldbus. Implementations were developed, e.g., for PROFIBUS [,], but without
achieving any practical relevance.
No matter if ATM or general IP-based networks (possibly also using QoS features if available) are
used as backbone network, a really transparent interconnection where the tunnel does not noticeably
impair the timing of the fieldbus network is hardly possible. It would theoretically be possible only if
