Image Processing Reference
In-Depth Information
Tools that operate on the IFS have been implemented using CORBA as middleware. CORBA is
an object model managed by the OMG that provides transparent communication among remote
objects. Objects can be implemented in different programming languages and can run on different
platforms. he standardized CORBA protocol IIOP (Internet Inter-ORB protocol) can be routed over
TCP/IP, thus supporting worldwide access to and communication between CORBA objects across the
Internet.
Alternatively, it is possible to use Web Services as management interface for embedded devices.
A case study that implements Web Services on top of the IFS is described in [].
22.5 Profiles, Datasheets, and Descriptions
In order to support computer-aided configuration, dedicated computer-readable representations of
network and node properties are required. This information plays a similar role as manuals and
datasheets for a computer-based support framework during configuration and management of a sys-
tem. These computer-readable representations allow establishing common rule sets for developing
and configuring applications and for accessing devices and system properties (for configuration as
well as management functions). In the following we discuss the profile approach as well as several
mechanisms following an electronic datasheet approach, the Electronic Device Description Lan-
guage (EDDL), the Field Device Tool/Device Type Manager (FDT/DTM), the transducer electronic
datasheets (TEDS), and the smart transducer descriptions (STD) of the IFS.
22.5.1 Profiles
Profile is a widely used mechanism to create interoperability in fieldbus systems. We distinguish
several types of profiles, i.e., application, functional, or device profiles. Heery and Patel propose a
very general and short profile definition that we adopt for our discussion. In short, “. . . profiles are
schemas, which consist of data elements drawn from one or more namespaces,
∗
combined together
by implementors, and optimized for a particular local application” [].
In many cases, a profile is the result of the joint effort of a group of device vendors in a particular
area of application. Usually, a task group is founded that tries to identify reoccurring functions, usage
patterns, and properties in their domain and then creates strictly formalized specifications according
to these identified parts, resulting in the so-called profiles.
More specific, for each device type a profile exactly defines what kind of communication objects,
variables, and parameters have to be implemented so that a device conforms to the profile. Profiles
usually distinguish several types of variables and parameters (e.g., process parameters, maintenance
parameters, user-defined parameters) and provide a hierarchical conformance model that allows for
the definition of user-defined extensions of a profile. A device profile need not necessarily correspond
to a particular physical device, for example, a physical node could consist of multiple “virtual” devices
(e.g., multipurpose I/O controller), or a virtual device could be distributed over several physical
devices.
Protocols supporting device, functional, and application profiles are CANopen [], PROFIBUS,
and LON [] (LonMark functional profiles). Figure . depicts, as an example, the visual specifica-
tion of a LonMark
†
functional profile for an analog input object. he profile defines a set of network
variables (in this example only the mandatory ones are shown) and local configuration parameters
∗
i.e., sources.
†
http://www.lonmark.org.
