Introduction to OPC

Introduction to OPC (OLE for Process Control)

1
Contents
OPC description 3
Introduction 3
Origin and uses 3
Development 3
OPC Foundation 4
OPC Standards and Specification Groups 4
Technical overview of the OPC Data Access interfaces 5
Introduction 5
The technology 6
The logical object model 7
Typical server design 8
The group and the item 8
The server interfaces in detail 9
The client side interfaces 11
OPC Unified Architecture 12
Innovations 12
Protocols 13
Specifications 14
OPC UA communication stack 16
OPC UA security 17
OPC UA API 18
Internet sources 19
2
OPC description
(From Wikipedia)

Introduction
OLE for Process Control (OPC), is the original name for an open standards specification developed in
1996 by an industrial automation industry task force. The standard specifies the communication of
real-time plant data between control devices from different manufacturers.
After the initial release, the OPC Foundation was created to maintain the standard. Since then,
standards have been added and names have been changed. Currently (June, 2006), "OPC is a series of
standards specifications". (Seven current standards and two emerging standards.) "The first standard
(originally called simply the OPC Specification"), is "now called the Data Access Specification", or
(later on the same page) "OPC Data Access", or OPC Data Access Specification.
OPC is generally understood to stand for "OLE for Process Control", even though no page on the OPC
Foundation website suggests that the letters "OPC" ever stood for anything, except for some content
written by member companies about themselves.
Origin and uses
The OPC Specification was based on the OLE, COM, and DCOM technologies developed by
Microsoft for the Microsoft Windows operating system family.
OPC was designed to bridge Windows based applications and process control hardware and software
applications. It is an open standard that permits a consistent method of accessing field data from plant
floor devices. This method remains the same regardless of the type and source of data.
OPC servers provide a method for many different software packages to access data from a process
control device, such as a PLC or DCS. Traditionally, any time a package needed access to data from a
device, a custom interface, or driver, had to be written. The purpose of OPC is to define a common
interface that is written once and then reused by any business, SCADA, HMI, or custom software
packages.
Once an OPC server is written for a particular device, it can be reused by any application that is able
to act as an OPC client. OPC servers use Microsoft’s OLE technology (also known as the Component
Object Model, or COM) to communicate with clients. COM technology permits a standard for real-
time information exchange between software applications and process hardware to be defined.
Development
The OPC Unified Architecture (UA) has been specified and is being tested and implemented through
its Early Adopters program. It can be implemented with Java, Microsoft .NET, or C, eliminating the

need to use a Microsoft Windows based platform of earlier OPC versions. UA combines the
functionality of the existing OPC interfaces with new technologies such as XML and Web Services to
deliver higher level MES and ERP support. It looks to become the standard for exchanging industrial
data, replacing FactoryTalk, Archestra, some Modbus applications, and OPCDA.

3
OPC Foundation
The OPC Foundation (www.opcfoundation.org) is an industry consortium that creates and maintains
standards for open connectivity of industrial automation devices and systems. The OPC standards
specify the communication of industrial process data, alarms and events, historical data and batch
process data between sensors, instruments, controllers, software systems and notification devices.
The OPC Foundation started in 1994, as a task force comprised of five industrial automation vendors,
with the purpose of creating a basic OLE for Process Control specification. OLE is a technology
developed by Microsoft Corporation for the MS Windows operating system. The task force released
the OPC standard in August 1996. The OPC Foundation was chartered to continue development of
interoperability specifications and includes manufacturers and users of devices, instruments,
controllers, software and enterprise systems.
OPC Standards and Specification Groups
OPC Data Access
This group of standards provides specifications for communicating real-time data from data
acquisition devices such as PLC's to display and interface devices like Human-Machine Interfaces
(HMI). The specifications focus on the continuous communication of data
OPC Alarm and Events
Standards for communicating alarm and event data on demand, as opposed to the continuous
communications in the OPC Data Access group
OPC Batch
Standards to address the needs of batch processes
OPC Data eXchange
This group of standards addresses server to server communications across industrial networks. The
standards also address remote configuration, diagnostics, monitoring and management

communications
OPC Historical Data Access
Standards for communicating stored data
OPC Security
Standards for controlling client access to OPC compliant devices and systems
OPC XML-DA
Builds on the OPC Data Access specifications to communicate data in XML. Incorporates SOAP and
Web services
OPC Complex Data
Standards for specifying the communication of complex data types such as binary data and XML
documents
OPC Commands
Standards for communicating control commands to devices and systems
OPC Unified Architecture
An entirely new set of standards that incorporates all of the functionality of the above standards (and
more), but does so using cross platform web services and other modern technology.
4
Technical overview of the OPC Data Access interfaces
Al Chisholm,
Chief Technical Officer,
Intellution Inc.
1 Edgewater Drive,
Norwood, MA 02062
781 769 8878
( />This paper presents a fairly detailed technical overview of the Data Access interfaces. It begins by
describing the problem these interfaces are designed to solve, the functionality they provide and the
object model they employ. Following this is a review of the specific interfaces provided, including a
brief discussion of the specific methods exposed by those interfaces.
Introduction
This paper contains a fairly detailed technical overview of the OPC (OLE for Process Control) Data

Access Interface. It assumes that the reader has some technical background in COM (Component
Object Model) and object oriented programming. This paper will also talk about where OPC Data
Access fits in the architecture of a control system and about the objects and methods that the OPC
Interface presents to the programmer.
In addition to talking about WHAT the objects look like, this paper will also talk a bit about WHY
they look the way they do. Which is to say it will try to answer the question, “What were those guys
thinking when they designed this stuff…”. This paper talks primarily about the Custom (C++)
interface as that is what server vendors and most serious client vendors need to understand and
implement.
The left figure above illustrates ‘The I/O Driver Problem’. Clearly each software driver for a new
device requires a unique, device-specific chunk of code to talk to the device or network. The need for
this device specific code is not a problem OPC is trying to address. Rather, this is something Fieldbus
is trying to address, and Devicenet, and Profibus, and Lonworks, and a host of others.
The problem that OPC deals with is that each of these software drivers also presents a different
software interface to the calling application. As a result, each application also requires a unique chunk
5
Software
Driver
Display
Application
Trend
Application
Report
Application
Software
Driver
Software
Driver
Software
Driver

Software
Driver
Display
Application
Trend
Application
Report
Application
Software
Driver
Software
Driver
Software
Driver
of code for each driver, device or network it wants to connect to. This obviously makes it difficult to
reuse applications with different sets of process interface equipment.
OPC Solves this problem be creating a ‘software bus’ as shown in the right hand figure. Applications
only need to know how to get data from OPC data sources. As a result, they are simpler, smaller and
easier to use. Device Drivers (servers) only need to know how to provide data in a single format (OPC
Server). As a result they are easier to write (and there is more of a market for such servers).
Although the MAIN problem OPC solves is the ‘I/O Driver’, you can see in the figure above that OPC
is flexible enough to be used not only between Devices and SCADA, SoftPLC or DCS systems, but
also between the SCADA SoftPLC or DCS engines and the high level applications such as HMI,
Trends, Reports, etc. which use their data. In this architecture, the SCADA system, the DCS system or
the SOFTLOGIC system really just represents a ‘smarter’ device.
The technology
Now for some technology basics… Why, for example, does OPC use COM? COM is Microsoft's
Component Object Model which is the ‘90’s’ way to do APIs (subroutines). In addition to being
widely used, another advantage of COM is that Microsoft provides a lot of the useful common
‘plumbing’ required to connect the clients and servers. This includes DCOM (Distributed COM)

which allows creation of network-based applications with a minimum of development effort.
As noted earlier OPC is flexible enough to be used at different layers within the system architecture
and is specifically designed to work well over a network. Efficiency is insured by the fact that (a) OPC
can be exception based and (b) unlike DDE, OPC can pack 100s or 1000s of data items into each
transaction. Performance is also guaranteed both by the support for multiple data items per transaction
and by the fact that COM and thus OPC servers can be created in several models; inprocess, local and
remote. For the highest possible performance, Inprocess servers incur 0 overhead. Millions of
transactions per second are possible using this approach. Local servers allow 1000s of transactions per
second. Even remote servers can manage 100s of transactions per second. And again, unlike DDE,
each transaction can include many data items.
6
Client Applications
SCADA System
Software Driver
DCS System
OPC
OPC
OPC
OPC
OPC
The logical object model
The OPC interfaces look the way they do largely because of the assumptions the OPC working group
made about the applications. The main assumptions are listed below.
• subset of the Tags available within the underlying Control system is needed for applications.
• many different subsets of Tags at different times and at different resolutions are needed for
applications.
• appilications should be independent of the process objects
It is important to stress that first point. A fundamental assumption is that there is some sort of control
or monitoring engine running independently of anything OPC is doing and that OPC is just a window
into this engine’s data. That last assumption is the only controversial one. This issue will be discussed

again below. In any case, these assumptions lead logically to the model in the following figure.
At the top of this figure is an OPC Server object . This is the COM object to which the application
first connects. Below this is a collection of OPC Group Objects. These are created dynamically by the
applications to hold lists of Tags and attributes (which OPC refers to as Items). An HMI might create a
Group for each open picture. A report package might create a group to access data for each report. The
contents of the Group and item collections may vary over time based on the needs of the applications.
(Again this has no effect on the underlying control system). This is actually somewhat analogous to
RowSets as used on OLEDB. There is a lot of data in the database, you want to look at a subset of it in
your application., and that subset may vary based on your needs at the time.
Which brings us back to the assumption about process object independence. There were two
fundamental approaches which could have been taken to this; the first is the ‘rowset’ approach seen
here. The second is a more purely object oriented approach in which the server would ‘proxy’ the
process objects and expose their properties and methods to the applications. The OPC working group
felt the pure object approach was basically much to complex. Two issues in particular were those of
efficiency and getting the vendors to agree on the nature and properties of the specific objects. Do note
that the OPC approach does allow a vendor to expose data from an OODB through a very flexible
names space.
7
The Logical Object Model
OPCServer
OPCGroup(s)
Custom and
Automation
Interfaces
OPCGroup(s)
OPCGroup(s)
OPCItem(s)
OPCItem(s)
OPCItem(s)
OPCItem(s)

OPCItem(s)
OPCItem(s)
OPCItem(s)
OPCItem(s)
OPCItem(s)
Typical server design
The figure above shows a typical server design. The SERVER provides management of the OPC
Groups and also controls, mediates and optimizes access to the physical devices by multiple clients.
The Server is essentially an I/O Driver which ‘understands’ how to talk to some vendor specific data
provider (hardware or software) and which Exposes the data from this data provider via the standard
OPC Interfaces. The OPC sample server available at the OPC web site provides a very good
implementation of the upper two layers of the diagram. Various commercial toolkits provide
frameworks or implementations of one or more additional layers.
The group and the item
The GROUP provides a convenient way for an application to organize the data it needs. Different
Groups can be used by different parts of the application; can have different refresh rates; can be polled
or exception based. Operator Displays, Recipes, Reports might each use one or more groups.
The ITEM provides a connection point to a value in the physical device. Typically this is a single
variable such as a process value or setpoint. The ITEM provides information to the client; Value,
8
The Logical Object Model
The Item
OPC Server The ‘Real’ SCADA
or DCS System
FIC101 TIC101
FIC102 TIC102
FIC103 TIC103
FIC104
FIC105
OPC Groups

OPC Item
OPC Item
OPC Item
OPC Item
OPC Item
Typical Server Design
OPC/COM Interfaces
OPC Group & Item Management
Item Data Optimization and Monitoring
Device Specific Protocol Logic
Hardware Connection Management
Quality, TimeStamp, and Data Type. As mentioned before, the OPC item is a transient object which
exists within the OPC server. It is used to create a connection between the server and the real data.
The OPC interfaces always return the process data in a VARIANT. It is assumed that the server has a
‘native’ or ‘prefered’ datatype which is also known as the canonical datatype. OPC allows clients to
read this canonical type (e.g. 4 byte float). It also allows them to specify that they want the data
returned in some other format (e.g. ASCII).
The server interfaces in detail
• IOPCServer
• IOPCBrowseServerAddressSpace (optional)
We will now review the interfaces on these objects in more detail discussing first what functionality
they provide and then listing the methods of each interface to show how that functionality is provided.
The Server interfaces are listed above. They allow the application
• To create and delete groups
• To browse the available tags
• To translate error codes into meaningful text
• To obtain status information about the server
IOPCServer
• AddGroup
• RemoveGroup

• GetGroupByName
• CreateGroupEnumerator
• GetErrorString
• GetStatus
The IOPCServer Interface allows the client to manage Groups. This is done using the Add, Remove,
Get and Enumerator functions. GetErrorString allows the client to translate errors (HRESULTS) into
strings. GetStatus allows the client to monitor the overall status of the server.
IOPCBrowseServerAddressSpace
• QueryOrganization
• ChangeBrowsePosition
• BrowseOPCItemIDs
• GetItemID
The browser interface (which is optional but which any worthwhile server should provide) allows the
application to browse the tag names and attributes available within the server. It is carefully designed
to work with essentially any organization; from a flat list of PLC registers to a hierarchical area/group/
loop organization to a fully object oriented database. It does this by mapping all of the above into a
hierarchical name space. This is intended to allow the application to present the results in an Explorer
like browse tree. QureryOrganization tells the client if the space is flat or hierarchical. If the space is
hierarchical, ChangeBrowsePosition moves up and down the hierarchy. BrowseOPCIDs returns an
enumeration of the leafs or branches at a particular node. GetItemID returns the fully qualified name
of an item. (This allows complete independence from the syntax and delimiters used by the vendor).
9
The group managment interfaces in detail
The Group Interfaces allow the application
• To add and remove items from groups
• To Manage the accuracy (update rate) of the data in the group
• To read or write values for one or more items in a group
• To Subscribe to data in the group on an exception basis.
Note that the ITEM is not defined as a COM object and does not expose any interfaces in the Custom
model. There are a variety of reasons for this, most related to the efficiency and complexity of the

server.
IOPCGroupStateMgt
• GetState
• SetState
• SetName
• CloneGroup
After a client creates a group, IOPCGroupStateMgt allows control of the behavior of that group. It can
change the name or update rate and a few other parameters of the group. It can also activate or
deactivate the group. For example, an HMI might want to deactivate a group (but not delete it) if the
display page using that group was minimized or hidden. CloneGroup can also create a copy of the
group.
IOPCitemMgt
• AddItems
• ValidateItems
• RemoveItems
• SetActiveState
• SetClientHandles
• SetDatatypes
• CreateEnumerator
IOPCitemMgt allows the client to add items to the group. For example, an HMI might create a group
for each display page and then add to those groups all of the items referenced by that page. The most
important functions here are AddItems and RemoveItems. The other functions are basically bells and
whistles.
10
The group read/write interfaces in detail
There are 3 ways for a client to read data from an OPC Server Group; sync read (polled), async read
and exception (subscription). The sync and async read work with specific lists (subsets) of items from
the group which are provided by the caller. The subscription sends back any item in the group that
changes. The interfaces which allow these operations are described below.
IOPCAsyncIO

• Read
• Write
• Refresh
• Cancel
The Asynch functions work in combination with the callbacks (IAdviseSink). The Read and Write
functions ‘launch’ an asynchronous request for one or more items. The server works in background to
get the data and then returns the data for those items to the caller via a callback. (a completion event).
The Refresh method works in combination with the subscription mode. It tells the server to pretend
that all of the data items have changed. As a result, fresh copies of all of the items get sent back.
IOPCSyncIO
• Read
• Write
This interface supports very straight forward polled reads and writes. The client provides a list of
items to read and gets back a list of values and/or errors or provide a list of items and values to write
and gets back a list of errors. These functions always run to completion.
IDataObject
• DAdvise
• Dunadvise
The IDataObject is a standard Microsoft interface. OPC requires that vendors provide the DAdvise
and DUnadvise methods. These are used to hook up callbacks which are used by the async and
subscription modes of data access. Clients which do synchronous reads do not need to use this
interface. Specifically, this interface works in combination with IAdviseSink on the client side. Note
that the groups operate independently. The client can poll, subscribe or do asynch I/O to different
groups.
The client side interfaces
On the client side, there is one ‘callback’ interface required in order to do synchronous or exception
based I/O. This is a standard Microsoft interface called IAdviseSink. The only important method the
client needs to implement is OnDataChange. The client will get a callback into this method if any of
the following occurs:
• An asynch read or write completes

• One or more values change in a subscription
The data comes back packed into a shared global region. The specification shows how to unpack the
data (as does the sample code).
11
OPC Unified Architecture
(From Wikipedia)
OPC Unified Architecture is the most recent OPC specification from the OPC Foundation and differs
significantly from its predecessors. After 3 years of specification work and another year of prototyping
the first version of Unified Architecture is now being released.
Innovations
Although the original binding to COM/DCOM helped OPC to distribute well but nevertheless had also
its drawbacks.
• no configurable timeouts
• only available for the Windows Operating System
• security not really applicable
• frequent configuration issues with DCOM, and no control over DCOM (COM/DCOM is kind
of a blackbox, developers have no access to sources and therefore have to live with bugs or
insufficient implementations)
That and various other conclusions generated the decision to develop a new and independent
communication stack for OPC UA which replaces COM/DCOM. The outstanding characteristics of
this communication stack are
• portable ANSI C implementation
• scalability from embedded controllers up to Mainframes
• the stack can be compiled for multi-threaded as well as single-threaded/single-task operation,
which is necessary for porting the stack onto embedded devices.
• an own security implementation, based on new standards, realizes "real" security.
• configurable timeouts for each service
• handling of big datagrams
This communication stack describes only the beginning of various innovations. The OPC UA
architecture is a Service Orientated Architecture (SOA) and is based on different logical levels.

12
All of the Base Services defined by OPC are abstract method decriptions which are protocol
independent and found the basis for the whole OPC UA functionality. The transport layer these
methods into a protocol, which means it encode/decode ("serializes"/"de-serializes") the data and
transmits it over the network. Currently there are two protocols specified for this purpose. One is a
binary, towards high performance optimized TCP protocol and as second, a Webservice-based one.
The OPC information model isn't just a hierarchy based on groups ("folders"), items and properties
anymore, but also is a so-called "Full Mesh Network" based on nodes. These nodes can additionally
transmit all varieties of meta information.The easiest comparison of a node would be an object, known
thru object orientated programming (OOP). It can own attributes for read access (DA, HAD), methods
which can be called (Commands) and triggered events which can be transmitted (AE, DA
DataChange). The nodes get used for process data as well all other types of meta data. The used OPC
namespace contains now also the type model used for description of all possible data types. Based on
the above, other organizations e.g. like EDDL are specifying their own information source. Client
software has the ability to verify which of the so-called Profiles a server supports. This is necessary to
obtain information if a server only supports the DA functionality or additionally the AE, HAD, etc
functions. Additionally, information can be obtained whether a server supports i.e. the EDDL profile
and therefore the client knows that there are also EDDL-specific device descriptions available.
Additional new and important features of OPC UA are:
• Redundancy support
• Heartbeat for connections in both directions. That means the server as well as the client
recognized interruptions.
• Buffering of data and acknowlegements of transmitted data. Lost connections don't lead to
lost data anymore. Lost datagrams can get fetched repeatedly.
Protocols
As described before there are two protocols. An application programmer will recognize this only via
the different URL he has to pass for binary protocol opc.tcp://Server and http://Server for
WebService. Otherwise OPC UA works completely transparent to the API.
1. Binary protocol
• best performance, the least overhead

• takes minimum resources (no XML Parser, SOAP and HTTP required -> important for
embedded devices)
13
• best possible interoperability (binary is explicitly specified and allows less degrees of freedom
during implementation as XML does)
• only one single TCP port (4840) gets used for communication and can get tunneled or enabled
through a Firewall easily
2. WebService (SOAP)
• best supported from available tools. It can be easily used i.e. from JAVA or .Net environments
• Firewall-friendly. Port 80 (http) und 443 (https) will usually work without additional
configuration.
Since the available ANSI C stack supports both protocols, the expectation is given that most of the
final products may communicate via the more effective binary protocol.
Specifications
The OPC UA spesification is a multi-part specification and consists of the following parts
1. Concepts
2. Security Model
3. Address Space Model
4. Services
5. Information Model
6. Service Mappings
7. Profiles
8. Data Access
9. Alarms and Conditions
10. Programs
11. Historical Access
14
In contrast to the COM based specifications are the UA spesifications no pure application specs. They
describe typically UA internal mechanisms which get handled through the communication stack and
are normally only out of interest for those which port a stack to a specific target or those which want to

implement their own UA stack. The OPC UA application developers code against the OPC UA API
and therefore will mainly use the API documentation instead. Nevertheless, part 3, 4, and 5 may be out
of interest for the application developers as well.
15
OPC UA communication stack
The architecture of an UA application, independent whether it is for the server or client part, is
structured into the following levels.
The green parts equalize to the former COM Proxy/Stubs and get provided by the OPC Foundation.
New is the portability level which allows it in an easy way to port the UA ANSI C stack also to other
target platforms. A port layer for Windows and Linux gets also provided by the OPC Foundation. As
described before, based on the API the applications can be developed, similar to how it was when
coding based on COM in the past. At the OPC UA DevCon in October 2006 in Munich the first
prototypes have been presented live. The company ascolab GmbH, which also developed the ANSI C
stack for OPC Foundation, presented various prototypes and demonstrated impressively the
interoperability between a Windows/.NET UA Client and a Linux UA Server. Additionally, various
UA Server have been shown on a Beckhoff PLC and an embedded test board from Euros. Whereby
the Beckhoff PLC is based on Windows XP Embedded and the embedded controller is based on the
real-time operating system Euros.
16
OPC UA security
UA Security consists of authentication and authorization, encryption and data integrity via signatures.
For that, the OPC Foundation hasn't reinvented the wheel but oriented itself at the Web Service
Security specifications. For Web Services the WS Secure Conversation gets used and is therefore
compatible to .Net and other SOAP implementations. For the binary variant, the algorithms of WS
Secure Conversation have been followed and also converted to a binary equivalent. This gets now
named as UA Secure Conversation.
As visible on the figure above, there is also a mixed version where the code is binary but the transport
layer is SOAP. This compromises efficient binary coding and Firewall-friendly transmission. Binary
coding always requires UA Secure Conversation. The authentication uses x509 certificates
exclusively. It relies on the application developer to what certificate store the UA application gets

bound to. For instance, it is possible to use the Poublic Key Infrastructure (PKI) of an Active
Directory.
17
OPC UA API
For UA developers, the possibility gets provided to code based on C API, C++ API or a .NET API,
directly. All API support the same functionality. The communication stack and API get provided by
the OPC Foundation.
.Net Implementation
The .Net implementation uses only the lower part of the ANSI C stack and implements the rest of the
stack natively in .Net. That means only the handling of the socket and the Message-handling gets
integrated from the ANSI C stack. The de-serialization takes place directly in .Net and therefore gets
converted directly into .Net structures and objects. This processes a better performance than de-
serialzing into a C structure first and then copying the data to a .Net structure afterwards.
JAVA Implementation
Various stacks for JAVA are already in development. But similar to .Net there are principially 3
variants. Currently it's hard to determine which one is the fastest.
1. Mostlikely, the fastest variant (in terms of engineering time) currently is to make use of the
complete ANSI C stack and encapsulate it via JNI.
• - A drawback is that you lose the simple JAVA portability. Although the stack can be ported
to different operating systems, it needs to get compiled for those individually
• - The data needs to get copied to the JNI boundary.
• + This method uses the performance of C during de-serialization.
2. The code gets based on the network layer directly (similar to the current .Net implementation) and
de-serialzed in JAVA.
• + Saves one data copy execution
• - still depending on the C stack.
3. Complete implementation in JAVA.
• + Best portability option
• - Takes the most engineering effort to implement
Alternatively, there is the simple variant to only support the WebService protocol. For that a SOAP

Toolkit, which supports WS Security, is needed.
18
Internet sources
1. OPC Foundation (www.opcfoundation.org) - The Object Linking and Embedding for
Process Control (OPC) Foundation is an industry consortium that creates and maintains
standards for open connectivity of industrial automation devices and systems. The OPC
standards specify the communication of industrial process data, alarms and events, historical
data and batch process data between sensors, instruments, controllers, software systems, and
notification devices.
2. OPC Programmers Connection () - OPCconnect.com is an
independent site dedicated to the needs of the software/solutions developer working with OPC
(formerly OLE for Process Control).
19