What is OPC Server?


What is  OPC Server?

OPC
Server is a windows application that provides a means of bringing data and
information from a wide range of industrial devices and systems into client
applications on your windows PC. OPC Server falls under the category of a
“Server” application. It is very common to hear the term
“client/server application” in use across many software disciplines
and business segments. In the industrial market, it has usually come to mean
the sharing of manufacturing or production data between a variety of
applications ranging from human machine interface software and data historians,
to large MES and ERP applications.
Regardless
of the business segment served, client/server applications have one thing in
common, a standardized method of sharing data. In the industrial segment many
client/server technologies have been developed over the last ten years.
Initially some of these technologies were proprietary. In many cases these
proprietary client/server architectures were in wide use but remained
unavailable to third party applications. Early in the development of windows
Microsoft provided a generic client server technology called DDE or Dynamic
Data Exchange. DDE did provide a basic architecture that would allow many
windows applications from a wide range of vendors to share data, but there was
one problem. DDE was not designed for the industrial market; it lacked much of
the speed and robustness desired in an industrial setting. However, this did
not stop DDE from becoming dominant client/server architecture, largely due to
its availability in most windows applications. In time, variations on
Microsoft’s DDE were developed by some of the leading vendors in the market.
These variations addressed some of the speed and reliability issues of DDE but
many people in the industrial segment agreed that a better system needed to be
developed.

OPC
(OLE for Process and Control)
In
1994 a group of vendors representing a broad spectrum of disciplines in
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 that 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 vendor’s 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
applications to which any OPC compatible application can address. 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. Our 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. This server 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 that 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:
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.


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.

 
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
either by 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.
DDE
Fundamentals
While
the Server is first and foremost an OPC server, it was recognized that a number
of legacy applications still depend upon DDE for their underlying client server
technology. To addresses these applications the server has been designed to
provide the same access to device data via DDE as can be achieved using OPC.
 The
server supports these formats of DDE:
1)  CF_Text
2)  XL_Table
3)  AdvancedDDE
4)
 NetDDE
5)  FastDDE/SuiteLink
Source: Kepserver
application Guide

Leave a Reply