Image Processing Reference
In-Depth Information
application processes (such as control functions localized in the network nodes), communication
and network parameters, and more general all network management data belong to this class.
Management data typically are aperiodic as they occur infrequently depending on the state of the
complete system. Traditionally, they are therefore often transmitted in some dedicated parameter
channels that use a small amount of communication bandwidth left over by the (mostly periodic)
process data.
In some cases, management data may also be needed periodically or quasi-periodically, e.g., to
update session information after a certain time, to exchange authentication information after a given
number of messages, or to change communication parameters on a routine basis. Nevertheless, the
communication mechanisms for such periodic management messages likely do not differ from the
aperiodic ones; they are simply invoked on a periodic basis.
Contrary to process data, management data are mostly not real-time data, which means that timely
delivery is not that important. What is more important, however, is guaranteed and correct delivery,
which influences the communication services that are used for this type of data. Confirmed services
are mandatory.
20.5.1.3 Parallel Traffic
This traffic type does not belong to the applications processes concerned with the actual control of the
technical process. Rather, it is generated by independent parallel processes and shares the communi-
cation medium. In traditional fieldbus systems, which were closed environments, this type of traffic
did not exist. With growing interconnection of automation networks, however, it becomes relevant,
either because external traffic (such as IP traffic) may be routed or tunneled through the fieldbus
or because fieldbus traffic may be routed through a shared backbone network. In particular, this is
an issue for Industrial Ethernet solutions, which in general foresee some sort of general-purpose IP
channel for devices not belonging to the automation system.
From the viewpoint of the automation process, care must be taken that the fieldbus traffic is not
negatively influenced. This needs to be done by appropriate QoS arrangements that guarantee rea-
sonable bandwidth and latency to the fieldbus application traffic in case a shared backbone is used. In
the other case, the fieldbus network management must ensure that the parallel traffic cannot consume
an arbitrary amount of communication resources or block other processes.
20.5.1.4 Implications for the Fieldbus
The various traffic types have also implications for the way communication in fieldbus systems is
handled, both from a protocol and from an implementation point of view. Data which are exchanged
on a cyclic basis are usually sent via connectionless services. he reason behind this is that for peri-
odicallyupdatedprocessdata,itmakesnosensetorequireaconirmation.Ifamessagecontaining
process data gets lost, resending it is not sensible because by the time the data might arrive at the
receiver, they are outdated, anyway, and new data might already be available. With respect to practi-
cal implementation, the handling of such data, especially at the receiver side, is mostly implemented
by means of buffers. In these buffers, the latest data always overwrite older values, even when they
are basically implemented in a first in, first out (FIFO) structure. In this case, the “FIFO full” signal
is suppressed, so that always the most recent values are in the buffer.
On the contrary, acyclic data need special precautions, irrespective of whether they are related to
process variables or management data. Loss of such data is not desirable and might be detrimental to
the overall application (e.g., if alarm events are not received). Hence, mechanisms involving some sort
of acknowledgment must be used to allow for retransmissions in case of data loss. hese mechanisms
can be implemented on the lower communication layers or the application level, depending on the
basic communication services a fieldbus offers. In terms of actual implementation, such messages are
typically handled in queues. As opposed to buffers, messages are not overwritten. If the queue is full,
