1
COM/OLE
applications are
widely used in
Industrial
Automation and
Process Control
domains. Since not
many programmers are
aware of these
technologies, I
thought to share my
experience in
OPC and most
developers would
love to expand their
knowledge about
COM/OLE application
areas.
The goal of
article: Give
simple &
understandable
overview of
OPC. More
detailed information
and specifications
can be downloaded
from
OPC
Foundation and
websites mentioned
in Resources
section.
So first, about
the above diagram...
Theory about
Figure 1:
On left-bottom
is a hardware
device. It could
be a
PLC
(programmable
logic
controller), a
temperature
sensor, roller
belt controller,
or just about
any industrial
device. Central
part is the
OPC
server. Right
side is the
client that
wants to
operate the
device. The
OPC
Server gives out
standard COM
interfaces so
that any client
aware of these
OPC
Interfaces
can interface
with server and
operate the
device -
without
programming
device driver
for that
hardware.
Hardware can be
as varied as
OPC
server
can
handle and
clients can
still read and
write from this
hardware.
Now back to
our
OPC course.
This article gives
an overview of
OPC and
covers following
topics. Source code
is not available,
since most of server
code is specific to
hardware. And client
would still need a
server to connect
to. But yes, if you
want to experiment
with
OPC, check
out the Resources
section below.
History of
OPC
In 1996, a group
of companies
Rockwell Software,
Intellution, et. al.
came together to
form a consortium
that defined a
standard for process
control.
SCADA and
similar
standardization
efforts were being
made at that time in
process control and
automation industry.
This group created
an initial draft
that was based on
Microsoft's Object
Linking and
Embedding (OLE). It
was called OLE
for Process
Control
(OPC).
OPC
Foundation
publishes
specifications and
manages everything
that goes into
OPC
technology.
Today more than
300 companies are
part of
OPC
Foundation.
Microsoft, GE,
Siemens, Rockwell,
ABB, Ford, Honeywell
and more are members
that actively
contribute and
consume
OPC
technology.
In 2005,
OPC
Foundation released
OPC Unified
Architecture draft.
There are
predecessor drafts
released before -
OPC HDA,
OPC DX,
OPC AE,
OPC Commands,
OPC Security.
We will briefly
study them in this
article.
By now, you must
have a question in
your mind. Let me
answer it below...
Why do we need
OPC? its
Benefits
I was also a
first timer to
OPC (coming
from varied
experience in
DevTools, eLearning,
CAD/PLM,
Multimedia), and had
no clue as to why do
we need it. I found
that learning it
through a case study
was very helpful, so
I am going to do the
same for you. To
understand the need
for standardization
in process control
industry, let me
give you an actual
case study performed
by a giant
organization in
Petrochemicals
business.
Refer to figure
2. It shows the
devices and software
application that
were in action on
this particular
petrochemical plant.
PLC, Vibration
sensor, and
Calculation engine
work on different
communication
protocols - TSAA,
Modbus, and DDE. So
the software
applications that
need data from these
devices also need to
be aware of TSAA,
Modbus, and DDE
protocol.
Additionally each
device needs to
serve all the three
applications. The
process historian,
GUI application
providing human
machine interface
and the machine
condition monitor
all communicating
with all devices
results in a
complexity. This
deployment took the
company around 10
days. And its cost
was approximately US
$ 50,000.
Now, someone like
me :) came to them
and said, "hey guys,
why don't we think
smart and implement
as in Figure 3?".
Observe the reduced
complexity. Now all
software
applications talk
only to the
OPC Servers.
And all devices also
respond only to the
OPC server.
OPC Server
provides the
Black Box for
software
applications around
hardware.
The new
implementation took
just 2 days to
deploy and cost
incurred was
approximately US
$10,000. They could
have eliminated 2
OPC servers
as well and
implemented device
drivers right inside
a single
OPC server.
This is a tradeoff
and off the shelf
OPC servers
may have standard
protocols support
like DDE, Modbus and
TSAA.
As you observed
correctly, the
benefits are:
-
Reduced load
on device.
-
Scalability
of system has
increased.
-
OPC
server provides
caching of data.
-
Client
applications
need not know
hardware
protocol
details.
-
Increased
life for device
(it need not
serve multiple
clients
anymore).
-
Interoperability
(Unix/Linux and
Windows - both
platforms are
supported by
OPC)
-
Standardization
Now that you have
some insight into
OPC benefits
and history, let's
take one step ahead
to understand
OPC
terminology and
concepts.
OPC Concepts
& Terminology
OPC
specification
defines a consistent
terminology to
identify various
entities involved.
The best analogy to
OPC way of
data representation
is that of a file
system hierarchy.
OPC calls it
as
OPC Address
Space. Within this
address space every
entity can be
uniquely identified
by its "full-path".
For example, refer
to figure 4.
OPC Address
Space is
hierarchical. It
starts with a root.
Then there are
logical
folders
and
sub-folders.
Leaf nodes are
OPC Items or
Tags.
Generally your
sensors and
actuators form the
leaf nodes. This is
an important point
to understand and we
will spend some time
on it. For example,
you have a device
that can sense
temperature,
Pressure, and
Humidity. Then these
attributes are
generally mapped as
leaf nodes under
some
folder-subfolder
hierarchy. We will
see what that
hierarchy can be in
a moment. If you
have an actuator
(say,
Turn_ON_Boiler),
then that also
becomes a leaf node.
You can write to
Turn_ON_Boiler
values of 1 or 0 for
example, and
necessary action
will be taken - of
course we just
assumed that your
hardware control
mechanism behaves
this way. You can
read from
Temperature
to know sensed
value.
Hope we are all
clear till this
point. Now let's
understand this
"logical" folder
stuff. The logical
folders and
sub-folders are used
to represent state
of your Industrial
Automation system.
This configuration
can actually map to
some physical
configuration or
even geographical
setup. Let's spend
some time to
understand this one
as well. For
example, in this
diagram we have an
ethernet
communication
channel to which a
wireless meter is
connected. And
within wireless
meter, there are two
classes "Average"
and "Channel1".
These folders and
sub-folders are very
effective means of
grouping your
process control
parameters and
values.
This address
space is "published"
to all clients of
OPC server.
The
OPC clients
can be simple
spreadsheets like
Excel, process
historians that keep
record of data
coming from various
industrial plant
entities. Every
client can create a
logical entity
called as
group
inside
OPC server.
Each
OPC Group
can contain a set of
OPC Items.
Synchronous &
Asynchronous
OPC Item
reading
OPC
specification
supports synchronous
as well as
asynchronous reading
and writing on
hardware devices.
Since not all
hardware device
operations are
fast-enough, the
asynchronous
mechanism of reading
and writing to a
device comes very
handy.
COM Interfaces &
Component Categories
Well, so now
suppose you wish to
write your first
OPC client.
If you were
developing a client
that runs on local
machine as that of
server, and if you
were aware of all
OPC Server
ProgIDs, then we
would not have any
worries. But since
that is not
possible, we need an
enumeration
mechanism. Following
is an enumeration
mechanism.
Collapse
|
Copy Code
<font size=2>OPC Component Categories
Enumeration issue is addressed by requiring OPC servers to implement
component categories. For example, all servers that are OPC DA 1.0
(more about this in later sections) compliant implement COM category
with CatID {63D5F430-CFE4-11d1-B2C8-0060083BA1FB}. Similarly the
servers compliant with OPC Data Access 2.0 implement category with
CatID {63D5F432-CFE4-11d1-B2C8-0060083BA1FB}.</font>
So
OPC
Foundation
distributes a
Windows Service
called as
OPCEnum.
Collapse
|
Copy Code
<font size=2>Enumerating OPC Servers
OPCEnum.exe runs as a Windows Service and provides enumeration
functionality. Using OPCEnum, the client applications can query
available OPC Servers on local as well as remote networked machines.
Now let's look at
server component
interfaces.
There are various
COM interfaces that
OPC Server
must support
according the
OPC
Specification
compliance required.
These basic
interfaces have
specific
functionality.
IOPCBrowse
This interface has
methods that allow
browsing
OPC Address
Space. Client can
query level by level
folders and
subfolders till the
leaf nodes. The
hierarchy looks like
shown in
figure 4.
IOPCItemIO
Interface is used
for performing
OPC Item read
and write
operations.
Now let's
understand how
OPC Client
interacts with the
OPC Server.
Important steps
involved are
summarized in figure
6, below.
I know you must
still be wondering
about this
OPC Group
term. Let's spend
some time
understanding it.
Every client when
opens a session with
OPC Server,
needs to create a
logical group of
items that it wants
to read or write.
Client can maintain
multiple groups.
Each group is given
a unique name and
has following
attributes:
-
Update rate
[milliseconds]
at which the
values of items
are read.
-
Active or
In-active Flag
[Boolean] only
if group is
active that the
items are
processed.
-
Deadband [%]
variations
inside this band
are considered
NULL.
-
IO Mode
[Synchronous/ASynchronous]
all operations
performed are
either sync or
async.
-
Time Bias
[time] local
time band with
respect to GMT.
The
OPC Group
component supports
following
interfaces.
Figure 7.
As you may have
identified these IOPCSyncIO
etc interfaces that
are relevant for
synchronous and
asynchronous
OPC Item read
and write
operations.
OPC Group
Components also
support connection
point container for
events that are used
for client
notifications. At
least you have some
idea by now that
OPC is just
another COM
application in
action - just that
it is a standard
meaning all
OPC Clients
and
OPC Servers
are bound by design
contract.
OPC
Foundation provides
compliance test
applications. Using
these suites one can
execute certain
number of test cases
on
OPC Server
and determine their
compliance to
particular
OPC
Specifications.
There are several
OPC
specifications
available (explained
in next section). A
typical compliance
report looks like as
shown in figures 8 &
9.
Figure 8.
Figure 9.
OPC
Compliance Test
Suite also supports
testing for
performance whereby
the
OPC Server in
question is loaded
with multiple items
read and write
requests. These
determine time
required per item
operation and also
passed and failed
test cases. Once
compliance is
achieved, the report
can then be uploaded
to
OPC
Foundation web site
for public
reference. So that
customers buying
OPC Server
from a particular
vendor can make sure
that the server is
compliant to a
particular
specification and
may meet their
integration need
with other software
packages used on the
plant.
OPC
Foundation is
responsible for
maintaining and
releasing new
specifications. It
is a body made up of
industry experts,
companies that
produce
OPC products
and organizations
that consume
OPC products.
So far
OPC
Foundation has
released following
specifications.
-
OPC-DA
(Data Access)
Provides access
to real-time
data. We can
query most
recent values of
temperature,
pressure,
density,
acceleration,
and other types
of process
control data
from
OPC-DA
server.
-
OPC-HDA
(Historical Data
Access) Used
to retrieve
historical
process data for
analysis. This
data is
typically stored
in archives,
databases or
remote telemetry
systems.
-
OPC-AE
(Alarms &
Events)
OPC AE
servers are used
to exchange and
acknowledge
process alarms
and events.
-
OPC-DX
(Data eXchange)
Defines how one
OPC
server exchanges
data with other
OPC
servers.
-
OPC-XML
(XML Data
Access)
Defines schema
and data
representation
format based
upon XML
standard. Makes
it possible to
share &
manipulate
process control
data across all
operating
systems –
Windows, Unix,
Solaris, etc.
-
There were
several efforts
put onto -
OPC
Security,
OPC
Batch,
OPC
Commands,
OPC for
ERP.
Most recently
OPC
Foundation has
released a draft for
OPC Unified
Architecture
that attempts to
provide even more
integration of
process control data
and software with
other industrial
software systems
like ERP.
There are plenty of
resources available
on the web about
OPC.