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.
OPC (OLE for Process and Control)
|
| 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.
Figure 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.
Figure 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.
Figure 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.
Figure 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.
Figure The 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.
Figure 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.
OPC Data Access 3.0 Enhancements
|
