Contents

History of OPC

Why do we need OPC? its Benefits

OPC Concepts & Terminology

COM Interfaces & Component Categories

OPC Compliance

OPC Specifications

Resources

Schematic of OPC Server.

Figure 1.
<!------------------------------- STEP 3 ---------------------------> <!-- Add the article text. Please use
simple formatting (

,
etc) -->
Introduction
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.
This is my first ever article on Code Project, so if you feel anything needs to be improved, drop
me a line. Your suggestions and comments are most welcome.
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.

Figure 2.
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.

Figure 3.
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 "fullpath". For example, refer to figure 4.

Figure 4.
OPC Address Space is hierarchical. It starts with a root. Then there are logical folders and subfolders. 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.
Hide 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.

Hide 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.

Figure 5.
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.

Figure 6.

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 Compliance
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 Specifications
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.

Resources
There are plenty of resources available on the web about OPC.

OPC Foundation's Website : http://www.OPCFoundation.Org

OPC Unified Architecture : http://www.opcconnect.com/ua.php

OPC Connect Website : http://www.opcconnect.com

Control.com website also has some useful discussions on OPC: http://www.control.com

Hope you enjoyed knowing a bit of OPC in this article. If you have any questions or suggestions,
please post them here or drop me a line. srt@Suchit-Tiwari.Org or Suchit.Tiwari@Ge.com Your
suggestions and comments are most welcome. <!------------------------------- That's it!
--------------------------->