What is OPC?

OPC = OLE for Process Control

OPC [1] is a software interface standard [2] that allows Windows programs to communicate with
industrial hardware devices.

OPC is implemented in server/client pairs. The OPC server is a software program that converts the
hardware communication protocol used by a PLC [3] into the OPC protocol. The OPC client
software is any program that needs to connect to the hardware, such as an HMI [4] . The OPC
client uses the OPC server to get data from or send commands to the hardware.

The value of OPC is that it is an open standard, which means lower costs for manufacturers and
more options for users. Hardware manufacturers need only provide a single OPC server for their
devices to communicate with any OPC client. Software vendors simply include OPC client
capabilities in their products and they become instantly compatible with thousands of hardware
devices. Users can choose any OPC client software they need, resting assured that it will
communicate seamlessly with their OPC-enabled hardware, and vice-versa.

The typical OPC connection scenario is a single server-client connection on a single computer as
illustrated above, but there are more possibilities. For example, you might need to:

 Connect an OPC client to several OPC servers. This is called OPC aggregation.

 Connect an OPC client to an OPC server over a network. This can be done with OPC
tunnelling.

 Connect an OPC server to another OPC server to share data. This is known as OPC
bridging.

The OPC DataHub is uniquely designed to do all of these tasks. It is a combination OPC server and
OPC client that supports multiple connections. Thus it can connect to several OPC servers
simultaneously, for OPC aggregation and OPC bridging. Two OPC DataHubs can mirror data across
a TCP network to provide OPC tunnelling.

In addition to enhancing OPC server and client connections, the OPC DataHub can connect any
OPC server or client to other applications as well, such as Excel, a web browser, or any ODBC
database. And it can also be used to get OPC data into Linux or QNX.

[1] The acronym "OPC" comes from "OLE (Object Linking and Embedding) for Process Control".
 Since OLE is based on the Windows COM (Component Object Model) standard, under the hood
OPC is essentially COM. Over a network, OPC relies on DCOM (Distributed COM), which was not
designed for real-time industrial applications and is often set aside in favour of OPC tunnelling.

[2] OPC actually comprises several standards, the first and most important of which is OPC Data
Access (OPC DA). There are also standards for alarms & events, historical data, batch data, and
XML.

[3] Programmable Logic Controller: a small industrial computer that controls one or more
hardware devices.

[4] Human-Machine Interface: a graphical interface that allows a person to interact with a control
system. It may contain trends, alarm summaries, pictures, or animation.

OPC - What is it ? What Does is Mean to Me ?

What is OPC ? OPC stands for Openness, Productivity, and Connectivity. OPC is a
specification that has been developed over the last 8 years by a team of 150
companies and represents a shining example of how industry specification
organizations can be effective. The OPC Foundation is an independent organization
that is supported by the fees payed on a equitable basis by the members of the
foundation. Software Toolbox was a Charter Member of the OPC Foundation.

The goal of the OPC specification is to provide an open, flexible, plug-and-play

software standard for modular software interoperability in the automation
industry. The specification is based upon the Microsoft Component Object Model
(COM) and addresses the specific needs of the automation industry such as data
access (i.e. drivers), alarming, historical data access and trending, batch, and more.
You may ask "what about ActiveX - I thought it was the standard?" Well, OPC takes
the concepts of properties, methods, and events that you learned about for ActiveX
controls (see related articles in Object Technology Center) but goes a step further to
address automation specific issues and actually provide specific names for many of
the interfaces based on the application type. For some products, ActiveX will be all
you need, for others you may choose to use an OPC compliant product.

The long-term benefits for the user of OPC come from the ability to pick best-of-
breed application modules such as trending, alarming, graphics, etc. from various
sources and bring them together with common interfaces. For example, your
graphics environment could function as an OPC client, getting it's data from an OPC
data server connected to your PLCs. The trending package you choose could
function as an OPC client to the graphics package to get it's data, which also
happens to be an OPC server! Or it could go direct to the OPC data server.
Although this concept may sound like the old DDE server model that has been
around since the late eighties, but it is not. When DDE was invented, COM and the
whole 32 bit world did not exist. The OPC specification is built upon COM and uses
Windows technologies to provide superior performance and robustness that will
never be found when using DDE. Simply put, 15 years of technological
advancements since DDE was first used (circa 1988 in Windows 2.0) make a huge
difference!

So as you begin looking at manufacturing software packages, whether they are HMI
or others, find out if they are OPC compliant. If they are, you'll be able to shop
Software Toolbox and find all the OPC products that you need in one place. To learn
more, visit our website as we'll be adding more technical articles there as OPC
becomes more and more popular.

Straight Talk about What is OPC ?

This document is a work in progress that Software Toolbox is providing to our clients and the industry
because we find that we are still answering many questions for our clients about OPC that remain
unanswered despite the massive number of articles and papers on OPC created by the drafters of the
specification and the industry.

Our attempt here is to explain OPC in Plain English with a series of Questions and Answers. We also
have available a paper authored by Colin Winchester, our Director of Support Services, on the subject
of "What is OPC" - Colin's style of writing is often appealing to users and he enjoys writing to aid our
users in learning more about technologies - click to read his paper

We welcome your input and feedback. Email us your questions and we'll build them into this straight
talk tutorial about OLE for Process Control. Here are some common questions we are asked and the
answers.

 What is OPC ?
OPC is a specification or set of written rules and procedures for the way multiple software
programs ("applications") can talk to each other. The OPC specification was created by users
and software developers in the manufacturing/process control industry to serve the needs of
the manufacturing automation/process control industry specifically. The specification is
managed by volunteer effort and administered by the independent OPC Foundation.

OPC came about because application software developers and users saw the need to begin
to standardize how their applications worked together to reduce integration and total life cycle
costs for software used in the manufacturing automation/process control industry.

 Before OPC, each software application vendor provided their own custom ways to
connect 3rd party applications into theirs. So to connect vendor application "A" to
vendor application "B", you had usually have an expert C++ programmer who could
quickly come up to speed and become an expert on the custom programming
interfaces for both application "A" and application "B". Furthermore, users usually
had to purchase a toolkit from each of the two application vendors at a cost of several
thousand dollars each, long before they even cut the first check to the programmer
who was to integrate the two.

 With the OPC initiative, developers in the manufacturing automation/process control

industry began to adopt the specification and build "doors" into their applications that
met the OPC specfications, so that if Application A and Application B were both
written to the same OPC specification, they could connect with a mere fraction of the
integration time and cost and without custom code.

 Is OPC a standardized language for communicating to my plant hardware ?

No, though in at least one perspective OPC can be perceived as such and it would be an
accurate perception. When you have a software program that you want to get data from the
 plant floor in to you have a piece of software that sits between your application and the
hardware that is often called a "driver".

Think of a driver as a translator - it reads data from the hardware using the functions and
commands and wiring necessary to talk to the process control hardware and then hands it to
your software application using methods, formats, and a language your software program can
understand. So the "driver" software has to speak two languages or "protocols", one to your
software, one to the hardware.

The OPC specification takes care of standardizing the means of speaking between your
software application and the driver software. "Driver" software that follows the OPC
specifications for providing data to other software applications are usually known as "OPC
Servers". This term is used because they "serve up data" to the software applications that
need it. The reason there are so many different OPC Server "drivers" on the market is
because the multitudes of hardware suppliers each speak a different "language" on their
communications interfaces

To the degree that we accept that once a piece of hardware has an OPC Server driver
connected to it the interface to software applications that need the data is standardized, then
yes, OPC does provide a standard means for connecting your applications to your plant
hardware.

 Are OPC servers communications drivers ?

Yes they are - they are translators between your process control hardware's language and
your application that needs the data. There are other types of drivers such as DDE servers
and ActiveX controls, but they do not provide the combination of performance plus
standardization of interface in the same package that drivers written as OPC Servers provide.

 What's the difference between an OPC client and an OPC server - what are they ?

An OPC Client is a software application that needs the data from the process control systems
and is able to speak the "language" defined by the OPC specifications in order to be able to
get the data from an OPC Server. The OPC server is the "driver" software that talks to
your specific hardware and reads/writes data and "serves it up" to the OPC client application

 How do I know if my software application is an OPC client ?

First of all ASK the people who developed your application. Perhaps you need a specific
version in order to make your application into an OPC client. If your application developer or
vendor doesn't know what OPC is, send them to this page to learn more and then to the OPC
Foundation website at http://www.opcfoundation.org

 My software application is not an OPC client ? How do I make it one ?

First of all if you licensed the application from someone else, check with the application
vendor - they may have an upgrade or accessory software application that adds OPC Client
capabilities to the package. If you developed the application yourself, you have some work to
do.

If you're a highly proficient C++ programmer then you can go get the OPC Specification from
the OPC Foundation and read it over, look at their sample code, and dive into
programming. We would caution you though that you need to have a solid understanding of
COM, DCOM, and ATL programming if you take that route.

The other route you could take is to license a toolkit that will help to speed your application
development. Toolkits are available for Visual C++ and Visual Basic so you can choose the
language that works best for your application.

The OPC Data ActiveX control is essentially a toolkit for adding OPC client functionality to
 your Visual Basic Applications. Visual C++ toolkits are available from SoftwareToolbox.com

 Why should I make my custom application into an OPC client ?

Because if you do, the next time you ask someone "can I connect my software to that
hardware ?" the only question you really need an answer to is "Is there an OPC Server
software driver available for your hardware?" If the answer is yes, and the OPC Server author
has followed the OPC Specifications, then you are done. You don't have to write any custom
drivers, or change anything. By making your software application an OPC Client you are
giving your application universal connectivity. If you used to have to be in the driver writing
business, you can get out of that business and partner with companies who focus on writing
OPC Servers and live or die by the quality of their drivers. You can focus on your application
development and business needs instead of worrying about custom drivers.

 What if my hardware vendor says they don't have an OPC server driver ?

First, you as their customer may need to explain to them why it is important to you. Second,
check places like SoftwareToolbox.com for and OPC server driver for your hardware - often
times the hardware vendors are not totally aware that a company who lives and dies by
writing OPC Server software has already written one for their hardware.

If still no luck and the hardware vendor and you don't have software development resources,
you can hire someone to create an OPC Server for your application hardware. New drivers
can be expensive compared to buying an off-the-shelf driver that already has thousands of
copies in circulation, but with the right number of licenses of software involved and
arrangements, you might be surprised at what can be done when compared to investing your
precious engineering time.

The other alternative if you do have the development resources is to write your own OPC
server. Like toolkits for OPC clients, there are toolkits to help your developers write OPC
servers available.

 What's the difference between and OPC server and an ActiveX control ?

OPC Servers and ActiveX controls are both based on the Microsoft Component Object
Model. ActiveX controls are typically user interface components and are also typically
intended to be embedded inside of another application. You can't take and ActiveX control
and just runt it like some EXE application. OPC Servers are specialized applications, usually
EXE standalone applications, designed to get data from the plant floor and serve it to other
applications. A Visual Basic (VB) application using our OPC Data ActiveX control is an
example of a case where you're using the best of both worlds - the ActiveX because it snaps
in nicely with VB, and the OPC server application because it is highly optimized for doing
communications to the plant floor hardware and serving data to multiple applications that
need it.

 When should I use and ActiveX and when should I use an OPC server for
communications hardware - what are the pro's and cons of each ?

Keeping in mind the solution above, sometimes you should use both. There are ActiveX
controls available that drop into VB (we offer several) that do communications also. However
there are some key tradeoffs that you make.

If you use an OPC Server, the OPC Server will handle optimizing the communications
protocol packets and tags for you. Furthermore with an OPC server you get the option of
having a tag database in the OPC server itself thus eliminating the need for you to build a tag
database into your application. You map to the tags and if that tag ever needs to be tied to a
different physical hardware address, you can change that without touching your VB
application. Also, since OPC servers are separate applications, they can share the same data
read once from the PLC or other hardware with mulitple applications at the same time. Lastly,
another advantage of OPC is investment protection - since OPC is an accepted standard for
 connecting drivers to software, you can change your VB app out for another application
anytime and keep the same driver - before OPC you couldn't do that. On the downside, you
pay a per machine license for OPC servers (keep in mind the OPC Data ActiveX offers a
runtime free license for connecting VB to the OPC server). If one considers total life cycle cost
of a project you likely will find you will still come out ahead using a VB to OPC solution.

To be sure though, using an ActiveX to talk to your PLC as it's advantages. The first is
cost. Most PLC communications ActiveX controls are sold on a runtime free basis. The
downside is the PLC communications ActiveX control goes inside of VB, other applications
can't use it at the same time, you are responsible for building your own tag database, and you
are responsible for optimizing your own read/writes. The upside to that is that you have
ultimate flexibility and choice to tweak the application the way you want. However, if what you
are after is a quick application time to market, then you are in for more work with an pure PLC
communications ActiveX solution than if you used the OPC Data ActiveX connecting to an
OPC server.

 What is the difference between an OPC server and a DDE server ?

Most simply, it's a technology issue for one thing. DDE was the first desktop PC technology
that let multiple applications talk. It is vintage 1986 technology from Windows 2.0 (yes there
was such a thing as Windows 2.0 running on a 286 PC - our founders were using it back
then). Having said that, DDE was limited to one tag at a time and 50 concurrent connections,
period. Along came FastDDE, which let you pass blocks of data and made FastDDE a viable
contender for many years, championed by it's visionary creator, Wonderware. Rockwell
Software, not to be out done, came up with AdvanceDDE to address the same issues with a
different approach. Neither FastDDE or AdvanceDDE have been in the public domain - you
can gain access to them through purchasing toolkits but the specifications arent' something
you can publically download like the OPC specifications.

OPC is based on current Microsoft COM/DCOM technologies and does not suffer from the
performance and scalability issues that DDE suffers from still today. OPC software interfaces
are clearly defined by a public standards body, the OPC Foundation, with over 270
companies using the methodology. OPC was developed by automation developers for
automation developers and users and thus is highly tailored to the needs of this industry,
whereas DDE is a general purpose technology that at the time could be used for this industry
but left unaddressed many of the automation industry's needs unless you used semi-
proprietary variants.

 I have an application that isn't a communication's driver but it claims to be an OPC

server - what's the deal with that ?

Any software application that wants to provide data to other applications can be an OPC
server and use the standard OPC interfaces to present the data to other software programs,
regardless of the root source of the data. For example, many HMI applications expose their
tag databases via OPC now -- you could use the OPC Data ActiveX to connect to the HMI
application ( we tested this at OPC Interop 2001) and read data from the HMI into your Visual
Basic program and combine it with data from other sources.