Image Processing Reference
In-Depth Information
expected to facilitate the employment of fieldbus systems by the end-user who normally is only
concerned about the overall functionality of a particular plant—and not about the question which
fieldbus to use. he methods used to define data types, indices, default values, coding and meanings,
identification data, and device behavior are based on functional abstractions (most promising are
currently function blocks [,]) and general modeling techniques [].
20.5.7 Fieldbus Management
Owing to the different capabilities and application areas of fieldbus systems, the management of a
fieldbus shows varying complexity and its solutions are more or less convenient for the user. It has
already been stated that the various fieldbusses offer a wide range of network management services
with grossly varying levels of sophistication. Apart from the functional boundary conditions given
by the protocols, fieldbus management always strongly relies on the tool support provided by the
manufacturers. his significantly adds to inhomogeneity of the fieldbus world in that entirely differ-
ent control concepts, user interfaces, and implementation platforms are being used. Furthermore, a
strict division between communication and application aspects of fieldbus management is usually
not drawn.
Typical “communication-related” management functions are network parameter settings like
address information, data rate, or timing parameters. hese functions are rather low level and implic-
itly part of all fieldbus protocols. he user can access them via software tools mostly supplied by the
device vendor. “Application-related” management functions concern the definition of communica-
tion relations, system-wide timing parameters (such as cycle times), priorities, or synchronization.
The mechanisms and services offered by the fieldbus systems to support these functions are very
diverse and should be integrated in the management framework for the application itself (e.g., the
control system using the fieldbus).
As a matter of fact, a common management approach is still not available despite all interoperabil-
ity achievements, and vendor-specific solutions are preferred. From the user's point of view (which
includes not only the end-users, but also system integrators), this entails significantly increased costs
for the build-up and maintenance of know-how because they must become acquainted with an
unmanageable variety of solutions and tools. his situation actually revives one of the big acceptance
problems that fieldbus systems originally had among the community of users: the missing interoper-
ability. Communication interoperability (as ensured by the fieldbus standards) is a necessary but not
sufficient precondition. For the user, “handling interoperability” of devices from different vendors
is equally important. What is needed are harmonized concepts for configuration and management
tools. More than that, tools should also be consistent for different aspects of the life cycle of an instal-
lation, like planning, configuration, commissioning, test, and diagnosis or maintenance. Such tools
require functionality-oriented, abstract views. A major disadvantage of today's tool variety is that they
operate in many cases on incompatible data bases, which hampers system integration and is likely
to produce consistency problems. More advanced concepts build on unified data sets that present
consistent views to the individual tools with well-defined interfaces [,]. [,].The data structures are
nevertheless still specific for each fieldbus.
For a fieldbus-independent access to the field devices and their data (not necessarily covering the
entire life cycle), several solutions have been proposed. They mostly rely on a sort of middleware
abstraction layer using object-oriented models. Examples are OLE for process control (OPC) [],
also Java or other concepts []. Such platforms can ultimately be extended through definition of
suitable application frameworks which permit the embedding of generic or proprietary software
components in a unified environment spanning all phases of the life cycle. Relevant approaches are,
e.g., Open Control [], Field Device Tool [], or a universal framework of the ISO [].
In the context of management and operation frameworks, the unified description of device and
system properties becomes of eminent importance. To this end, device description languages were
