About OPC - OPen Connectivity through Open Standards.

OPC is a Client / Server technology. One application acts as the

server providing data and another acts as a client using data.



Kepware 2006 Overview
by ARC

Product Quality Control



OPC is a widely accepted industrial communication standard that enables the exchange of data
between multi-vendor devices and control applications without any proprietary restrictions. An OPC
server can communicate data continuously among PLCs on the shop floor, RTUs in the field, HMI
stations, and software applications on desktop PCs. Even when the hardware and software are from
different vendors, OPC compliance makes continuous real-time communication possible.

An enabling technology that helps users move beyond "closed" or proprietary solutions. OPC has led
to improved cooperation between technology providers and users alike. OPC has helped automation
suppliers provide solutions that are truly open which in turn has given users more choices in their
automation applications. This is an exciting time in the industry; interoperability, open solutions, and
choices have helped automation professionals around the globe realize the advantages of
incorporating OPC into their industrial applications. Kepware engineers develop and maintain
products according to the OPC Foundation's OPC Data Access specifications.

OPC is open connectivity in industrial automation and the enterprise systems that support the
industry. Interoperability is assured through the creation and maintenance of non-proprietary open
standards specifications. The first OPC standard specification resulted from the collaboration of a
number of leading worldwide automation suppliers working in cooperation with Microsoft. Originally
based on Microsoft's OLE COM and DCOM technologies, the specification defined a standard set of
objects, interfaces and methods for use in process control and manufacturing automation
applications to facilitate interoperability. The COM/DCOM technologies provided the framework for
software products to be developed. There are now hundreds of OPC Data Access servers and clients.

OPC is open connectivity via open standards and these standards are based on technologies of the
general computing market. Products by OPC members offer a wide range of tools for people who
prefer "off-the-shelf" products, to mid-level engineers who like the efficiency of building with a
toolkit, to the developer who prefers to build the entire application.

The History of OPC


In 1994 a group of vendors representing a broad spectrum of disciplines in the industrial segment
formed what is now known as the OPC Foundation. The OPC Foundation put forth the goal of
developing a single client/server specification that would allow any vendor to develop software and
applications that could share data in a fast, robust fashion, and do it in a way that would eliminate
the proprietary schemes that forced these same vendors to duplicate development efforts. The OPC
Foundation developed the first specification, called Data Access Specification 1.0a which was released
in early 1996. Using this specification, vendors were able to quickly develop client/server software.
A major goal of the OPC Foundation and the Data Access specification was to eliminate the need of
client application vendors to develop their own proprietary set of communications drivers. For many
vendors, the effort required to develop numerous communications drivers outweighed the
development effort involved in the client application itself. With the adoption of OPC technology, a
vendor could now focus their efforts almost exclusively on the development of the client application.
The Data Access specification defines how both the client and the server application interface must
be constructed. If the specification is followed properly, a client vendor knows that any OPC server
that exists for an industrial device can provide the connectivity needed for data access. Issues like
time to market or reliability no longer restrict OPC applications. OPC has given the end user the
additional benefit of being able to select the best of breed software to solve application problems.
Historically, if the application software did not have the desired communication driver or if the
available driver didn't perform adequately, the only solution was to try to persuade the application
vendor to either develop the desired driver or repair an existing driver. The time required in either of
these cases was usually never short. With OPC, the end user is no longer tied to the resource
limitations of the client application vendor. The user can now choose from a variety of OPC server
vendors to address a new driver requirement or remedy a performance issue. Equally, the client
application vendor can now focus on the continued improvement of their core product without the
disruptive effort required to address communication issues and needs. Kepware's goal within the OPC
environment is to be a leading provider of the server component of the OPC equation and to do so by
providing a product that is reliable and easy to use. KEPServerEX is built upon years of development
efforts in communications driver development and OPC technology.

A lot has been said here about OPC but how does the OPC specification work? The OPC Foundation
has provided a good overview of OPC technology. With permission of the OPC Foundation, we have
provided the following section of the Data Access specification.

OPC Data Access Fundamentals
This section introduces OPC Data Access and covers topics which are specific to OPC Data Access.

OPC Overview

This specification describes the OPC COM Objects and their interfaces implemented by OPC Servers.
An OPC Client can connect to OPC Servers provided by one or more vendors.


OPC Client


Different vendors may provide OPC Servers. Vendor supplied code determines the devices and data
to which each server has access, the data names, and the details about how the server physically
accesses that data. Specifics on naming conventions are supplied in a subsequent section.


OPC Client/Server Relationship


At a high level, an OPC server is comprised of several objects: the server, the group, and the item.
The OPC server object maintains information about the server and serves as a container for OPC
group objects. The OPC group object maintains information about itself and provides the mechanism
for containing and logically organizing OPC items.

The OPC Groups provide a way for clients to organize data. For example, the group might represent
items in a particular operator display or report. Data can be read and written. Exception based
connections can also be created between the client and the items in the group and can be enabled
and disabled as needed. An OPC client can configure the rate that an OPC server should provide the
data changes to the OPC client.

There are two types of groups, public and local (or 'private'). Public is for sharing across multiple
clients, local is local to a client. Refer to the section on public groups for the intent, purpose, and
functionality and for further details. There are also specific optional interfaces for the public groups.
Within each Group the client can define one or more OPC Items.


Group/Item Relationship


The OPC Items represent connections to data sources within the server. An OPC Item, from the
custom interface perspective, is not accessible as an object by an OPC Client. Therefore, there is no
external interface defined for an OPC Item. All access to OPC Items is via an OPC Group object that
contains the OPC item, or simply where the OPC Item is defined.

Associated with each item is a Value, Quality and Time Stamp. The value is in the form of a
VARIANT, and the Quality is similar to that specified by Fieldbus.

Note that the items are not the data sources - they are just connections to them. For example, the
tags in a DCS system exist regardless of whether an OPC client is currently accessing them. The OPC
Item should be thought of as simply specifying the address of the data, not as the actual physical
source of the data that the address references.

Where OPC Fits

Although OPC is primarily designed for accessing data from a networked server, OPC interfaces can
be used in many places within an application. At the lowest level they can get raw data from the
physical devices into a SCADA or DCS, or from the SCADA or DCS system into the application.. The
architecture and design makes it possible to construct an OPC Server which allows a client application
to access data from many OPC Servers provided by many different OPC vendors running on different
nodes via a single object.


OPC Client/Server Relationship


General OPC Architecture and Components

OPC is a specification for two sets of interfaces; the OPC Custom Interfaces and the OPC Automation
interfaces. A revised automation interface will be provided with release 2.0 of the OPC specification.
This is shown below.


OPC Interfaces


The OPC Specification specifies COM interfaces (what the interfaces are), not the
implementation (not the how of the implementation) of those interfaces. It specifies the
behavior that the interfaces are expected to provide to the client applications that use them. Included
are descriptions of architectures and interfaces that seemed most appropriate for those architectures.
Like all COM implementations, the architecture of OPC is a client-server model where the OPC Server
component provides an interface to the OPC objects and manages them. There are several unique
considerations in implementing an OPC Server. The main issue is the frequency of data transfer over
non-sharable communications paths to physical devices. Thus, we expect that the OPC Server will
either be a local or remote EXE which includes code that is responsible for efficient data collection
from a physical device.

An OPC client application communicates to an OPC server through the specified OPC custom and
automation interfaces. OPC servers must implement the custom interface, and optionally may
implement the automation interface.

An inproc (OPC handler) may be used to marshal the interface and provide the additional Item level
functionality of the OPC Automation Interface. Refer to the figure below: Typical OPC Architecture.

Typical OPC Architecture


It is also expected that the server will consolidate and optimize data accesses requested by the
various clients to promote efficient communications with the physical device. For inputs (Reads), data
returned by the device is buffered for asynchronous distribution or synchronous collection by various
OPC clients. For outputs (writes), the OPC Server updates the physical device data on behalf of OPC
Clients.


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.