Image Processing Reference
In-Depth Information
20.5 Fieldbus Characteristics
The application areas of fieldbus systems are manifold, hence many different solutions have been
developed in the past. Nevertheless, there is one characteristic and common starting point for all
those efforts. Just like today's embedded system networks, fieldbus systems were always designed for
efficiency, with two main aspects:
•
Efficiency concerning data transfer, meaning that messages are rather short according to
the limited size of process data that must be transmitted at a time.
•
Efficiency concerning protocol design and implementation, in the sense that typical field
devices do not provide ample computing resources.
These two aspects, together with characteristic application requirements in the individual areas
with respect to real-time, topology, and economical constraints, have led to the development of con-
cepts that still are very peculiar of fieldbus systems and present fundamental differences to LANs. In
the previous section, the general differences in the context of the OSI model were already sketched.
This section will discuss some more peculiarities in detail.
20.5.1 Traffic Characteristics and Requirements
The primary function of a fieldbus is to link sensors, actuators, and control units that are used to
control a technical process. herefore, the consideration of the typical traffic patterns to be expected
in a given application domain was in most cases the starting point for the development of a new
fieldbus. Indeed, the characteristic properties of the various data types inside a fieldbus system differ
strongly according to the processes that must be automated. Application areas like manufacturing,
process, and building automation pose different “timing and consistency” requirements that are not
even invariant and consistent within the application areas [].
As regards timing, there are two essential philosophies to look at the technical process in a black-
box form and describe (and thus convey within the network) its behavior. One is a state-based
approach focusing on the status of the process defined by its internal state variables together with
its I/Os. hese variables are continuously sampled and transmitted in discrete-time fashion and form
the basis for continuous process control and monitoring (like temperature, pressure, etc.).
The other philosophy is an event-based one, i.e., data are transmitted only in case of state changes.
This approach is well suited for processes or subprocesses that have a somewhat discrete nature and
can be modeled as a state machine. Switches obviously lend themselves to such an interpretation.
Butalsoincontinuousprocesses,itmaybereasonabletotransmitprocessdataonlyiftheyexceed
certain predefined limits. his naturally requires the implementation of control functions locally in
the network nodes rather than in a remote control unit.
As far as consistency is concerned, there are on the one hand process data which are continuously
updated and on the other hand parameterization data that are transferred only upon demand. In case
of error, the former can easily be reconstructed from historical data via interpolation (or simply be
updated by new measurements). The system-wide consistency of configuration data, on the other
hand, is an important requirement that cannot be met by mechanisms suitable for process data.
Trying to find an abstract and comprehensive classification scheme for all possible fieldbus traffic
patterns,wearriveatthetraictypesshowninFigure.anddescribedbelow.Intheory,datatraic
generation is exclusively a question of the application process and should be seen independently of
the underlying communication system. In practice, however, the communication protocol and the
services provided therein heavily influence the possible traffic types—it is one of the peculiarities of
fieldbus systems that the two cannot be properly disentangled.
