|
Home / Library
OPC - PLUG
AND PLAY INTEGRATION TO LEGACY SYSTEMS
Copyright © 2000 IEEE
Universal Dynamics
Technologies Inc.
100 - 13700 International Place
Richmond, British Columbia V6V 2X8 Canada
www.udgroup.com
Abstract-This paper
discusses the use of OLE for Process Control as a medium for connection
of third-party applications to legacy control systems. This topic is
becoming more important as legacy system users attempt to "open
up" their systems to third-party applications. Several approaches
to implementing the OLE for Process Control interface to existing systems
are discussed, including emulation of field hardware, use of available
communication ports, and legacy application nodes. The advantages and
disadvantages of implementing each approach will be discussed, including
feasibility, performance and cost. A brief overview of the Client-Server
paradigm will be provided, as this is the cornerstone of OLE for Process
Control communications. Finally, some examples of successful connections
to legacy systems will be presented.
Index Terms-OPC, Connectivity,
OLE for process control, Connection.
Introduction
Recently, the Windows NT operating
system (OS) has enjoyed an increase in popularity within process control
industries. Today, many Distributed Control Systems (DCS), Supervisory
Control and Data Acquisition (SCADA) systems and Programmable Logic
Controller (PLC) systems include operator stations or engineering stations
that run Windows NT. These stations are commonly included in DCS, SCADA
or PLC systems installed today, and are available for legacy systems.
Human Machine Interface (HMI) applications have evolved over the last
few years to match SCADA system functionality. Therefore, the term SCADA
will also apply to HMI software.
One benefit that the Windows
NT operating system provides is several standardized mechanisms providing
methods for application communication. These include Dynamic Data Exchange
(DDE) and Object Linking and Embedding (OLE). OLE is based on Microsoft's
Component Object Model (COM) technology. OLE for Process Control (OPC)
is relatively new technology developed by a consortium of companies
involved in the process control industries. Because OPC is considered
much more robust and efficient than DDE, only OPC will be discussed.
Before the adoption of Windows
NT and standard communication mechanisms such as OPC, only applications
developed by DCS, SCADA or PLC vendors could access process information
through their operator or engineering stations. The exception to this
rule was applications developed by third party vendors that utilized
a DCS, SCADA or PLC vendors' proprietary Application Programmer's Interface
(API) or custom serial or Ethernet protocol. These third party solutions
where usually developed for a single DCS, SCADA or PLC system as the
cost of interfacing to multiple systems via multiple APIs or protocols
was considered too costly. This significantly limited the choices available
to end-users searching for specialized applications, each of which may
support only one or two APIs or protocols.
Today, standard communications
mechanisms within Windows NT such as OPC provide third party vendors
with a single API that will furnish communications to many vendors'
systems. This system access may be purely through software data transfer
or may be through a driver providing access to system process data.
Each of these scenarios is depicted in Figs. 1 and 2.
Use of a common interface such
as OPC significantly increases the potential number of end users for
third party applications. This benefit has meant a dramatic increase
in the number of specialized applications available for process control
systems. This increase has provided end-users with a wider range of
choices for specialized applications including advanced control, trending,
data logging, data conditioning, etc. (See Fig. 3.)
Fig. 1. Software
Level OPC Communications
Fig. 2. Communications
through an OPC Server to a System
Fig. 3. OPC client
applications communicating to several OPC servers for access to process
data
Client-Server
Paradigm
To understand OPC communications,
an understanding of the client-server paradigm is important. Within
this paradigm, server applications acquire, contain and "serve
up" data to client applications. Client applications process data
that is made available by server applications. Server applications cannot
communicate with each other directly; a client application must be used
as a bridge between two or more server applications to facilitate data
transfer. (See Fig. 4.)
Similarly, client applications
may not communicate directly with each other. Two or more client applications
must communicate through a server application. (See Fig. 5.)
Each client application may
access data within multiple server applications at the same time. This
is an important feature of client-server structure as it means that
when a common interface is employed, each client application simply
handles data processing, and not interfacing to a variety of data sources.
Each server application functions as a connection to a different data
source. (See Fig. 6.)
Fig. 4. Server
Communication through a Client
Another significant benefit
of the client-server paradigm is provision for connection of multiple
clients to any server at a given time. This capability provides for
an efficient use of data within a system. (See Fig. 7.)
Fig. 5. Client
Communication through a Server
Fig. 6. Client
Connected to Multiple Servers
Fig. 7. Server
Connected to Multiple Clients
Crossing Machine
Boundaries
Because OPC is based on COM
and an extension of COM - the Distributed Component Object Model (DCOM)
may be used to extend OPC client-server communications across machine
boundaries. What this means is that OPC clients and servers may communicate
while each runs on a separate computer, providing each of those computers
is connected by a Local Area Network (LAN). This LAN connection may
include a network server or exist as a simple peer-to-peer connection.
This feature of OPC provides systems with the ability to more efficiently
process data as data processing elements (OPC clients) may each be run
on dedicated hardware and will not have to share resources with other
data processing elements. (See Fig. 8.)
Fig. 8. OPC Client
Server Connection across Machine Boundaries
Available Connections
to DCS Systems
OPC technology may be used to
provide a common interface to new and existing legacy DCS systems in
a variety of forms. These forms may be categorized three ways as indicated
below:
- Modbus
- Serial or Ethernet Port
- Application Node
Modbus Communications
Many DCS systems include Modbus
communications capability. Modbus communications have been included
in such systems to provide communications to smart Modbus field devices.
Such devices may include process analyzers, control valves, weigh scales,
etc. OPC server software capable of emulating a Modbus device is available.
This software responds to DCS read and write requests over the Modbus
link. To provide up to date process information, DCS systems must actively
write data to and read data from the OPC server over Modbus. Third party
applications running within Windows NT may access process data over
the OPC link. (See Fig. 9.)
Fig. 9. OPC Server
Connected as Modbus Slave to DCS System
Communications via a Serial
or Ethernet Port
For DCS systems, that do not
support Modbus communications, a proprietary protocol over a serial
or Ethernet communication link may be available. Many third party driver
developers have OPC server software available that use such links. Using
this type of connection, the OPC server does not function passively
as it would when emulating a Modbus device. In this type of connection,
the OPC server reads and writes process data to and from the DCS. This
may prove beneficial, as fewer DCS configuration changes are required.
Another benefit that this type of connection may provide, over standard
Modbus, is increased bandwidth (communication throughput). (See Fig.
10.)
Communications via an Application
Node
Many DCS systems have application
nodes available. These nodes are provided to customers as a platform
on which applications developed by third party vendors may be run with
access to process data. For such application nodes, OPC server functionality
may be included. Applications nodes typically are connected to DCS systems
as an IBM compatible PC running Windows NT. (See Fig. 11.)
Fig. 10. OPC Server
Connected via Serial or Ethernet Connections to DCS System
Fig. 11. OPC Server
Connected to DCS System Application Node Software
Economical and Technical
Considerations
Typically, utilization of an
existing Modbus interface is the cheapest method of connecting to DCS
hardware using an OPC interface. This is due to the low cost of a very
common Modbus Slave OPC server and due to the low cost of implementing
and extension to existing Modbus wiring. OPC server software that utilizes
an available serial or Ethernet communication link is typically four
or five times as expensive as is the Modbus Slave OPC server software.
This cost difference may be explained by the fact that OPC software
that uses a proprietary serial or Ethernet link is less common and more
proprietary. The most expensive mechanism for connection to DCS systems
is usually an application node. As DCS equipment, the application node
cost and any required licensing costs typically associated with this
node could be quite significant. This high cost may be offset by the
ease of installation typically associated with these nodes and the consideration
that no wiring costs are incurred when connecting to them while running
on the same PC.
Connection to
PLC Systems
Communication to PLC systems
(or, in fact, SCADA hardware) is similar to serial or Ethernet communications
to DCS hardware discussed above. OPC server software utilizing a serial
or network connection to PLC hardware may be employed to provide the
common OPC interface to application software. Many vendor and third-party
OPC servers are available for popular PLC hardware. (See Fig. 12.)
Fig. 12. OPC Server
Connected to PLC Hardware
Connection to SCADA Systems
Most popular SCADA software
available today includes OPC server functionality. For those few software
applications that do not include this functionality, third party solutions
may be available. OPC client applications may simply be "plugged
in" to process data within these software packages. (See Fig. 13.)
Fig. 13. OPC Server
Connected to SCADA
References
[1] "OPC Data Access Specification,
OPC Foundation 1.0A, 1997 at website: http://www.opcfoundation.org.
[2] Dale Rogerson, "Inside
COM-Microsoft's Component Object Model," Microsoft Press, 1997.
[3] Kraig Brockschmidt, "Inside
OLE", Microsoft Press, 2nd Ed., 1995.
 |
