GUIDE

A Beginner’s Guide to OPC

Version 2

FREQUENTLY ASKED QUESTIONS ABOUT OPC

By John Weber and Win Worrall

Our mission is to provide you with the right software

package to solve your industrial operation challenges.
A Beginner’s Guide to OPC: Frequently Asked Questions
about OPC
Guide Version 2
We’ve been working with the OPC software interoperability standards since 1996, and it’s easy
to forget that others who are new to this space often find the whole discussion around the OPC
standard and all the different standards confusing.

John and I created this guide to help users that are new to the industrial automation space, also
known as operations technology or OT, or just new to the software side of operations
technology. We are approaching the subject based on some commonly asked questions that our
team hears and in this Version 2 of the guide we have added questions that we have heard from
you since our first guide was published.

Why OPC?
Before we get into what the OPC acronym stands for it’s important to understand at a
high level the business problem it set out to solve.

One of the common challenges in industrial operations is communications between

different brands or manufacturers’ control devices (PLC, DCS, Drives, RTUs, Smart
Sensors)) and between those devices and software. While most control devices have
methods of communication they don’t all communicate using the same methods or
protocols, and even if they both have the same serial or Ethernet wiring the difference in
communication protocols prevents them from passing information. It’s the same
problem you have if someone calls you on the phone, but doesn’t speak the same
language. As humans we may be able to overcome a difference in dialect, machine
communication has to be precise and exact. Small differences in addressing or data
formatting can be enough variation to prevent sharing of critical information.

A BEGINNER’S GUIDE TO OPC: FREQUENTLY ASKED QUESTIONS ABOUT OPC 1

 When a group of industrial automation vendors came together in 1995 and created the
independent OPC Foundation, the most common problem in automation was connecting
Windows based industrial software to PLCs and control systems. Each vendor of
software had to write their own drivers to talk to all the different PLCs. Our world in
automation was like printer drivers before Windows existed and came with standard
printer drivers.

Users had limited choices and vendors trying to

integrate with other vendor’s hardware and software
experienced frustration. Some vendors were using
an early Windows technology called DDE but that
had limitations.

The OPC standards changed all that as shown in this

diagram by providing a standardized way to
exchange real-time information between industrial
automation software applications. That early
standard was called OPC Data Access or OPC DA,
and now has been adopted in used worldwide.

In the years following 1995, OPC suppliers sprung up and user choice was finally
available. A user could choose HMI from Vendor A and have easy connectivity to control
hardware in their plant from Vendors B and C. They could share information between
software applications provided those software applications supported the OPC standard.

What does the OPC acronym stand for?

John: Ask a veteran of OPC this and they will laugh, because they
know there have been many meanings! In classic engineering techie fashion, the original
meaning was based on very software programmer speak: OLE for Process Control. OLE
or Object Linking and Embedding, was a fundamental early building block of Windows
that allowed applications to share complex information between them. I’ll show my age
here – I remember the first demos of Windows 3.0 where people were embedding Excel
spreadsheets into Microsoft Word documents and how much of a big deal it was to
update the spreadsheet, open Word, and the document updated. The original OPC
standards derived from that technology and COM or the Windows Component Object
Model.

Since then we’ve heard OPC stand for Open Productive Communications, but today the
official OPC Foundation meaning is Open Platform Communications. The goal remains
the same: Eliminate barriers and obstacles to interoperability between automation
software and hardware platforms to give users a choice.

A BEGINNER’S GUIDE TO OPC: FREQUENTLY ASKED QUESTIONS ABOUT OPC 2

What’s the difference between an OPC client and OPC server?
Win: OPC clients request data and sometimes also want to write data. Servers respond
to the requests of clients and provide data or accept their writes, if allowed. In the
simplest form, that’s it.

Think of an OPC Server like a protocol converter, OPC Servers talk to a device or devices
using the specialized protocols of the devices, and then provide access to that data using
the standardized formats defined by the OPC Classic and OPC UA specifications.
Typically an OPC Server doesn’t do anything until an OPC client request to read or write
data. Some OPC servers can be configured to poll data from devices even in the absence
of client requests. This is typically done to allow an OPC server to have current data in
its internal cache and ready to go when a client requests it, but comes at the price of
generating communications traffic that may not be required. Many OPC servers provide
flexibility for the user to configure the behavior to suit their application needs.

Why do I need OPC servers if my control hardware vendor says they support
OPC?
Win: Welcome to the evolving world of OPC. When hardware suppliers say they support
OPC, they often aren’t meaning they have embedded an OPC server into their hardware
directly. What they mean is that they have OPC server software that runs on a Windows
based computer somewhere that talks to their hardware and exposes data using one or
more of the OPC standards. Also for some hardware suppliers, there may be additional
licensing fees to enable this OPC server functionality. It sounds better in marketing for
them to just say “we support OPC”, but we do hear often from users that they find this
confusing. Always clarify what your vendor says.

Now some vendors are beginning to leverage the multi-platform capabilities and embed
OPC UA servers directly into their PLCs. This can be quite handy if your HMI or SCADA
software supports OPC UA. If your client applications don’t support OPC UA, there are
OPC Gateway applications that can help you bridge from OPC UA to DA.

Do OPC servers have to run on Server class computers and operating systems?
John: OPC servers do not need server class hardware or operating systems. Some
vendors may require this for their specific implementations, but the OPC standards do
not dictate this. OPC server software is often fairly lightweight and can easily co-exist
with other software applications on a desktop PC. Check with your OPC server supplier
for your specific application’s requirements to be sure. Software Toolbox’s products have
a specification page on each product website area though we typically do not require
server class hardware or operating systems for our OPC servers.

A BEGINNER’S GUIDE TO OPC: FREQUENTLY ASKED QUESTIONS ABOUT OPC 3

I have multiple brands of devices, do I need multiple OPC Servers?
John: Maybe. It really depends on the
device types and whether they are using the
same device level protocol or, if different
protocols, using protocols that are available
in a single OPC server product. For
example, if you have multiple flow meters
that all use Modbus or can support Enron
Modbus, then you could use a single OPC
server. If you are using PLCs from different
vendors, and maybe a flow metering
package from another vendor, you likely
will be dealing with different device level
protocols. However, you may be able to
obtain an OPC server that has plug-in
drivers that may be licensed separately, but
actually run in the same OPC server
application. Implementations of this
nature are common.

How can 2 OPC servers talk to each other? How can two OPC clients talk to each
other?
Win: In the OPC world, clients talk to servers. Servers talk to clients. The good news is
there are ways for OPC servers to talk to other OPC servers and the same for OPC clients.

Why might two OPC servers need to communicate? Imagine you have PLC vendor A and
PLC Vendor B and there is an OPC server communicating to each one using the two
different PLC vendor’s specific device protocols. You want to move data from PLC A to
PLC B, which means the 2 different OPC Servers need to talk with each other. You can
do this using OPC Bridging software applications. OPC Bridging software applications
are OPC client applications that can connect to many different OPC servers and then
allow you to map data movement between the two OPC servers, specifying direction,
data transformations, etc. You can learn more about OPC bridging in our OPC bridging
blog post.

In the case of OPC clients talking to each other, the most common application would be
two different SCADA or HMI software applications needing to exchange data. The first
solution would be to see if the HMI or SCADA software supports an OPC Server interface
in addition to being an OPC client. Many do, and if so then problem solved. The two

A BEGINNER’S GUIDE TO OPC: FREQUENTLY ASKED QUESTIONS ABOUT OPC 4

 client applications talk to each other’s OPC server interfaces using their OPC client
interface. If not, and the clients are purely OPC DA, UA or DA and UA clients, then using
an application such as the Cogent DataHub would be the solution. The Cogent DataHub
can act as an OPC server with a tag list that you define and both OPC clients read/write
to those common tags.

Why so many standards? DA, A&E, HDA, UA – seems like alphabet soup?
John: There are multiple standards because
there are multiple software to software and
software to hardware problems that the
independent OPC Foundation set out to solve
starting in 1995. Each standard addresses a
different problem type.

Remember the original problem OPC set out

to solve with OPC Data Access or OPC DA,
which was control hardware to software
communications as shown here.

The OPC DA standard defines

function calls to read, write, and
subscribe to data points like analog
and digital values, integers, floats,
strings, etc. There are no complex
data structures, it’s all about
moving real time data effectively
and openly.

We discuss the other 2 major

original OPC standards next in this
paper: OPC A&E and OPC HDA.

A BEGINNER’S GUIDE TO OPC: FREQUENTLY ASKED QUESTIONS ABOUT OPC 5

 You may have also heard about OPC XML-DA, OPC Security, OPC commands, & OPC
batch.

All of these were standards to address specific types of problems, but none were as
widely adopted as OPC DA, A&E, and HDA.

As a collection, these original OPC standards are now known as OPC Classic. It may be
“Classic” but to be clear, these standards are still widely used and implemented and there
are millions of installed OPC Classic servers and clients in the world. Examples of OPC
DA servers in the Software Toolbox offering include TOP Server for Wonderware,
OmniServer, and Cogent Datahub.

What’s OPC A&E?

Win: The OPC Alarms & Events (OPC A&E) standard was created to provide a
standardized method of exchanging information from systems that generate alarms or
events with other applications. For example, a Distributed Control System (DCS) may
generate alarms that are shown on operator consoles used by the DCS. The user may
also have a callout or alarm notification system that needs to unify alarm data from
multiple vendors systems. Prior to the OPC standard, the alarm callout or notification
software would have to write and support drivers or interfaces to every different system
and their custom interfaces.

The OPC A&E standard defined a common format to exchange that information. Alarms
have the alarm type, limit, timestamp, value, possibly a string message, acknowledgment
status and more, and all that information needs to remain together as a single “bundle”
of information. OPC DA wasn’t designed to that. Below is an example of the types of
information the OPC A&E standard allows to be shared in a single call between a client
and server.

OPC A&E provides the specialized function calls and data format for this data type. So
when an OPC client says it supports A&E that means it supports these specialized
function calls and data formats. In the Software Toolbox offering, the Cogent DataHub

A BEGINNER’S GUIDE TO OPC: FREQUENTLY ASKED QUESTIONS ABOUT OPC 6

 can be an OPC A&E server and client, securely tunneling data between OPC A&E clients
and servers across networks, routers, firewalls and between remote sites. The Cogent
DataHub can also convert OPC A&E to OPC DA or OPC UA.

What’s OPC HDA?

John: The OPC Historical Data Access (OPC HDA) standard solves the problem of
providing a standardized way to read data from Process Historians. We often hear
people say that they think OPC HDA defines how the data is stored in the historian
database. Actually it does not. OPC HDA is about allowing interoperability between
client applications that do trending, analysis, and reporting on data from wide range of
Process Historian applications on the market. Each Process Historian has their own
client tools that often connect using a private interface into their Process Historian. OPC
HDA opens the door for users to use a mix of vendors for these types of applications.

A historical data recordset will consist of a variety of data samples with the timestamps
for those samples, retrieved at the request of a client application to “Give me all the
values for Tag1, Tag2, Tag3, etc for the time range of the last 2 hours”. Like OPC A&E,
the OPC HDA standards provide specialized function calls and data formats to pass these
blocks of information between software applications.

In the Software Toolbox offerings, Flow can connect to multiple Process Historians using
OPC HDA as well as databases, Information Platform for industrial reporting and
operational analysis. Dream Report can also connect to OPC HDA and many other data
sources to produce a wide range of reports.

Why OPC UA?

John: The OPC Unified Architecture (OPC UA) seeks to take what was learned over the
first 10-15 years of OPC and remove duplication in code and interfaces that were

A BEGINNER’S GUIDE TO OPC: FREQUENTLY ASKED QUESTIONS ABOUT OPC 7

 obstacles to adopting multiple parts of the standard, and expand the uses of OPC into
other applications.

With the OPC Classic interfaces, developers had to include foundational OPC code over
and over again for the different interfaces standards. Now they can use a unified code-
base and implement whatever profiles they need. So the classic OPC standards became
OPC UA Profiles and an OPC UA server or client describes itself based on what profiles it
supports such as OPC UA DA profile, A&E profile, HDA profile, etc.

The most popular benefit of OPC UA is that it can be used across operating system
platforms, communicates using a single TCP/IP port, offers SSL encryption, and allows
for security rights control to the tag level based on user credentials, provided the OPC
client and server have implemented all the required facets.

Looking to the future, because OPC UA had to support the more complex data structures
of Alarms & Events and Historical Data, it was a logical extension to allow for support of
just about any complex data model and provide mechanisms for the implementation of
other complex data models for other standards to use OPC UA as the transport.

Software Toolbox offerings using OPC UA include TOP Server for Wonderware,
Omniserver, Cogent DataHub, OPC Data Client, OPC Data Logger and SLIK-DA for UA.

Can OPC UA talk to OPC DA and vice versa?

Win: OPC UA and OPC DA can’t talk directly, but there are OPC Gateway applications
that can share data in a single or bi-directional configuration between the 2 standards.

This is useful when you have existing systems that you need to integrate with OPC UA
but you aren’t able to or ready to upgrade all the software in your systems. Simple
gateway applications make the transition possible.

A BEGINNER’S GUIDE TO OPC: FREQUENTLY ASKED QUESTIONS ABOUT OPC 8

My OPC Server doesn’t support UA yet but my OPC client does, what do I do?
John: We hear this a lot, and in the end it’s really the same as the previous question. We
also hear the question reversed as “My OPC client supports OPC DA only but it needs to
talk to an OPC UA server”. The solution to both scenarios is the same. You need an OPC
gateway application that can convert from OPC DA to UA at both the client and the
server level.

Some people also call this an OPC wrapper or OPC UA wrapper, or OPC DA wrapper.
They key is that you need a solution that is fast, easily configured, and supports the
necessary OPC UA security features that you plan to use.

Can OPC DA 2 and DA 3 clients and servers talk to each other?

John: If you’ve been around OPC long enough you may have heard
that there were 3 versions of OPC DA – Version 1, 2, and 3. The
most widely implemented standard is OPC DA 2.x. We don’t see
many OPC DA 1.x servers or clients any more but they do exist.
OPC DA 3.x was the first step towards OPC UA in that it added
some additional functionality to the DA function set to handle
sampling of data and controlling of what constitutes changed data,
but it was not widely adopted in client or server applications.

Many OPC clients, if they support OPC DA 3.x, they will support 2.x,
and they might support OPC 1.x. Bottom line the client application
has to support one of the versions of the OPC DA standard that the
server offers. But what if the client doesn’t?

If you find you need integrate between OPC DA 2 and DA 3 clients and servers and either
your OPC client or server is missing the support you need, the Cogent DataHub supports
OPC DA 2, OPC DA3, and OPC UA and can be an OPC Client and Server and would be a
good solution.

If you happen to have an OPC DA 1.x client or server and need to integrate it with OPC
DA 2, 3 or even OPC UA, the TOP Server OPC Client Driver would be a good solution.

A BEGINNER’S GUIDE TO OPC: FREQUENTLY ASKED QUESTIONS ABOUT OPC 9

What are OPC Data Quality and Timestamps all about?
Win: Before OPC,
when your HMI or
SCADA software
went to read data
with its built in
drivers, it either got
data or it didn’t. If
you didn’t get data
you had no good
way to know the
last time you did
get data. There was
no in between.

With OPC servers,

they cache, or hold onto the last value that they read from the devices. They also
timestamp the data in their cache, typically using the time the value was read from the
device by the OPC server.

OPC Quality is a way for OPC Servers to tell OPC clients more about the value they are
providing. The way this is done is by passing a number along with the value and
timestamp. In OPC speak we call this VQT or “Value, Quality, Timestamp”. The OPC
quality number is really determined by setting bits within a word, and that results in
different values. A value of 192 means “Good” quality, which means the last time the
OPC server polled the device it was able to successfully get data, so the OPC client can
trust that value. A value of 0 will mean Bad Quality and typically means that there was a
communications failure between the OPC server and the device it is polling. There are a
whole range of other values that the OPC server can use to indicate why the quality is
bad, but they are not widely implemented. We have a detailed application note that
shows more of the common OPC quality values.

What matters the most is that OPC client applications typically can be configured to
cause a change in how they show values to the user on an operator screen, or in a
historical database, so that people know not to trust that value and they know why.

What about Devices that store events and send data in batches with timestamps?
Some devices store a timestamp for when the data last changed, and can pass that to the
OPC server using the device specific communications protocol. If the device supports
that and the OPC server supports it, device timestamps can be used. Examples of
Software Toolbox products that support device timestamps for protocols that support the
functionality include TOP Server DNP, IEC 61850, and IEC 60870 drivers.

A BEGINNER’S GUIDE TO OPC: FREQUENTLY ASKED QUESTIONS ABOUT OPC 10

 Sometimes we hear from users that have applications where they need to source
timestamps from one place and data from another and combine them. They aren’t often,
but when we run into those we help with the Cogent DataHub as we can use its scripting
engine to control the source of data and timestamp separately.

I need to share data between a control system and a metering package or between
2 different control systems that have OPC servers
John: What you need in this case is an OPC Bridge application. An OPC Bridge
application is a product that is an OPC client, and thus can talk to OPC DA and OPC UA
servers, and has functionality to allow you to:

 Create mappings between tags in each control system through a visual user interface
 Define whether data flows one direction or both directions between the systems
 Define changes such as scaling to be applied to the data values if required
 Bridge to non-OPC data sources or destinations, if required, for your application
 Bridge between different OPC data sources, including OPC UA to OPC DA and vice
versa

Where should my OPC servers be placed in my network security model?

John: This could probably be a whole paper, as there are so many considerations, but we have
heard this one a lot since the first edition, so let’s look at it here.

First, remember when we say OPC servers, we’re talking

about the software, not necessarily the hardware they are
running on. Often those “hardware” servers are virtual these
days, and the choice of location of those servers needs to
involve a discussion with your IT department, OT team, and
cybersecurity team.

The answer to the question is really “it depends”, and there

are too many possible combinations of factors and scenarios
to discuss here in a responsible fashion so, instead, we’ll
point out some of what you should consider, and provide a couple of examples.

A BEGINNER’S GUIDE TO OPC: FREQUENTLY ASKED QUESTIONS ABOUT OPC 11

Factors to consider include but are not limited to:

 Who needs the data from the OPC servers and

where are those applications running? Are
they on the public internet? Are they in a
business layer? A DMZ layer in the network?
Or are they in a totally isolated Automation
layer?
 Do different data sets have different user
needs and, thus, access is needed at multiple
layers?
 How often do they need the data?
 Is some of the data read only and some
read/write?
 How critical is the security of the data?
 What are your corporate IT standards?
Have some considerations to add, we’d love to hear from you.

To be sure, there are more factors, but most conversations we have start there. More and more
we are seeing the need to be able to share data securely, rapidly, with more and more parties,
which presents a cybersecurity challenge. There are unique tools available to share data without
having to open inbound firewall ports, and without significantly sacrificing performance.

Probably the most common scenario we see is to place the OPC servers in the Automation Layer
of a network, as close to the data source as possible, to insure performance and to make data
available rapidly to other applications that reside in the Automation layer. Then, using tools for
tunneling, including OPC UA, data is taken to a DMZ layer and then up to the business layer,
with the DMZ providing the necessary filtering and isolation.

A BEGINNER’S GUIDE TO OPC: FREQUENTLY ASKED QUESTIONS ABOUT OPC 12

We also are asked this question in the context of the Perdue enterprise reference architecture
and the layers 0 to 4. We sometimes also are asked the question in the context of the Perdue
ICS model. The answer unfortunately is still “it depends”. Typically, we see the OPC servers
residing at Level 2 or Level 3 in the Perdue Enterprise model and, in the Security Cell/Area
Zone, level 1 or level 2, in the Perdue security model. What matters most is that you involve all
the relevant stakeholders and their needs in your decision.

I need redundancy in my OPC system, how do I do that?

This is another deep topic, with lots of questions before there
are answers. First, you must define what you mean by
redundancy as, taken to deep extremes, it can apply to every
component of the system that touches the OPC server or that
the OPC server depends upon. We’ve written about this topic
at length, so we suggest you read about the OPC redundancy
considerations you need to keep in mind when defining what
redundancy means to you.

The most common scenario we hear about is people wanting to

have redundant OPC servers, specifically OPC UA servers with
the growing adoption of OPC UA. Some HMI/SCADA client
applications will have redundancy switching and monitoring of OPC data source health built
into the product, so first check there. If they don’t then you’ll need an OPC redundancy
switching tool. This is another area we’ve written about in more detail that you can read about
here.

Do you have more questions? Ask us!

John and I view this document as a living document so we hope to hear from you with your
questions so that we can continue to enhance and improve this resource for people that are new
to the operations technology space.

Click here to send us your questions. We look forward to helping you.

About the Authors

Win Worrall

Win studied software engineering and has been working at Software Toolbox
since 2007. Win started out in product support and has worked with
hundreds of users around the world with about every product in Software
Toolbox's mix. Win’s unique mix of development experience combined with
hands-on client experience enables him to deliver value to his clients. Win
currently is responsible for product management of the Cogent DataHub
offering within Software Toolbox's range of products and is part of the
company leadership team with various other responsibilities.

A BEGINNER’S GUIDE TO OPC: FREQUENTLY ASKED QUESTIONS ABOUT OPC 13

John Weber

John founded Software Toolbox in 1996 after 6 years with GE Fanuc

automation and CIMTEC, a large high tech automation products distributor.
He started out in technical support at GE Fanuc and has worked with users in
about every industry through a variety of roles. That experience developed a
passion for customer experience that is a key part of Software Toolbox’s vision to provide a total
product experience that will empower users to maximize their results. John is very active in
many parts of Software Toolbox’s business and enjoys the opportunity to help others learn about
this space.

A BEGINNER’S GUIDE TO OPC: FREQUENTLY ASKED QUESTIONS ABOUT OPC 14

 888 665 3678 TOLL FREE
+1 704 849 2773 GLOBAL
Charlotte, NC USA GLOBAL HQ
www.softwaretoolbox.com WEB

Our mission is to provide you with the right software package to solve your industrial operation challenges.