The integration of drives into existing engineering systems normally
involves substantial parameterisation work in respect of different
fieldbus systems. Not so with ‘Drive Server’, whose OPC interface enables
software to be connected in a true plug-and-play manner. Volker Arlt
reports.
The range of functions of field devices in drive technology is expanding
all the time, and expectations regarding their capability for integration
into modern drive systems are correspondingly high. With the introduction
of freely programmable inverters conforming to IEC 1131, for example,
drives not only perform drive functions independently and autonomously
but also take on control tasks. However, direct access to field devices
via the PC has so far been problematic and it is characterised by the
diversity of fieldbuses and their interfaces.
Manufacturer-specific device properties and special protocols for
accessing subsystem components also serve to complicate integration
capability in an engineering environment. Subsystem components - in the
case of multi-axis applications, for example - can only be accessed via
the manufacturer’s own programming tools and not with commercially
available programs. As a consequence, device functions are frequently
developed by the user.
This is where the ‘Drive Server’ concept, developed by the Drivecom User
Group, comes into its own. This device server provides easy access to
field devices with no need for complex driver integration and device
configuration. For a manufacturer of automation components it therefore
represents a pragmatic approach to the integration of field devices into
existing engineering environments. It is fieldbus independent; offers
automatic configuration using the device description; has
function-oriented display on the drives; supports encapsulation of
manufacturer-specific device properties, and provides transparent access
to subsystems.
Drive Server has the open standard OPC (OLE for Process Control) at its
heart. It operates as OPC client and server and, in addition to providing
access to field device parameters and process data, it also allows a
client/server architecture based on COM/DCOM to be set up. In this way, a
three-layer system architecture (presentation, processing and device
access) can be developed that satisfies industry’s demand for modularised
automation systems. Fieldbus independence is achieved by means of an OPC
server, which is responsible for bus access and communication. This bus
server is supplied by the manufacturers of the fieldbus cards thus
maintaining the device server concept at bus level. The field device
manufacturer supplies the user with the Drive Server, which provides
optimum support for the drive. It can also be used as a basis for ActiveX
controls, which make it easy to manage device functions.
The idea of encapsulating the device properties in a server supplied by
the device manufacturer can be generalised and applied to other field
devices too. As with a printer driver, the user can utilise the specific
functions of a field device without being responsible for
manufacturer-specific protocols and fieldbus connections. In this way the
drive server forms a layer between the application program with OPC
client interface and the communications media. In practice this means
that if the Drive Server is installed on the PC, users simply need to
enter the fieldbus they wish to use. The Drive Server automatically
detects the field devices present, configures itself and constructs its
own ‘name space‘. The OPC browse function enables all of the application
programs to find and access the specific drive parameters. User-specific
parameters can simply be added during routine operation.
Drive Server and Open Control
The CALL specification developed by the Open Control Foundation divides
field device interfaces into th