1. Overview

	The OPC Data Access Client module for the Edge One™ platform provides a reliable, easy to configure interface to connect third party OPC Data Access Servers.

This guide includes the following sections:

1. OPC Client Features.
2. OPC Data Access Overview.
3. Where OPC Fits in an Automation architecture.
4. General OPC Architecture and Components.
5. OPC Server Object, which describes the OPC Server object.
6. OPC Group Object, which describes the OPC Group object.
7. OPC DA Version Interoperability, which displays the differences between the various version of the OPC DA specification.

OPC DA Client Features

The OPC DA Client module of the Edge One™ implements the OPC DA version 2.05a Specification as well as the OPC AE Alarms and Events specification. In addition, it supports the Percent Deadband option, which can be used with OPC servers with deadband support.

OPC Data Access Overview

The OPC Data Access Specification is the first of a group of specifications known as the OPC Classic Specifications. OPC Data Access is a group of client-server standards that provides specifications for communicating real-time data from data acquisition devices such as PLCs to display and interface devices like Human-Machine Interfaces (HMI), SCADA systems and also ERP/MES systems. The specifications focus on the continuous communication of data.

The OPC Data Access specification is also known as OPC DA. OPC DA deals only with real-time data and not historical data or events. For historical data you need to use OPC Historical Data Access, or OPC HDA. For Alarms and Events you need to use OPC Alarms and Events, or OPC AE.

An OPC Client can connect to OPC servers provided by one or more vendors. 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.

Figure 1. 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. Within each Group the client can define one or more OPC Items.

Figure 2. 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.

There are three attributes associated with OPC DA item. These are

• a value,
• the quality of the value, and
• a timestamp.

The OPC DA specification states that these three attributes have to be returned to an OPC client making a request. Therefore, if the data source is not capable of providing a timestamp, for example, the OPC DA server must create a timestamp.

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.

Back to Top

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 Distributed Control System (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 3. OPC DA and SCADA Systems.

Back to Top

General OPC Architecture and Components

OPC is a specification for two sets of interfaces; the OPC Custom Interfaces and the OPC Automation interfaces. This is shown below.

Figure 4. OPC DA 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 interfaces. OPC servers must implement the custom interface, and optionally may implement the automation interface if defined. 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 5. OPC DA 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.

The OPC Custom Interface Objects include the following custom objects:

• OPCServer
• OPCGroup

The interfaces and behaviors of these objects are described in detail in Chapter 4 of the OPC DA 3.00 Specification. Please refer to the OPC Foundation documentation for the specification for full details. The following sections provide a high level overview of these two custom interface objects.

Back to Top

OPC Server Object

The OPCServer object is the primary object that an OPC server exposes. The interfaces that this object provides include:

Interface	Description
IUnknown	The server must provide a standard IUnknown Interface. Since this is a well defined interface it is not discussed in detail. See the OLE Programmer’s reference for additional information. This interface must be provided, and all functions implemented as required by Microsoft DCOM.
IOPCServer	This is the main interface to an OPC server. This interface must be provided, and all functions implemented as specified.
IOPCommon	Other OPC Servers such as alarms and events share this interface design. It provides the ability to set and query a LocaleID which would be in effect for the particular client/server session. That is, as with a Group definition, the actions of one client do not affect any other clients.
IOPCServerPublicGroups (optional)	This optional interface allows management of public groups. An application may be designed so that the same groups of data items are used by many clients. In those cases, the optional Public Group capability of the server provides a convenient mechanism for both clients and servers to share these groups.
IOPCBrowseServerAdressSpace (optional)	This optional interface provides a way for clients to browse the available data items in the server, giving the user a list of the valid definitions for an ITEM ID. It allows for either flat or hierarchical address spaces and is designed to work well over a network. It also insulates the client from the syntax of a server vendor specific ITEM ID.
IOPCItemProperties	This interface is used by clients to browse the available properties (also refered to as attributes or parameters) associated with an ITEMID and to read the current values of these properties. In some respects the functionality is similar to that provided by BrowseServerAddressSpace, by EnumItemAttributes and by the SyncIO Read function. It differs from these interfaces in two important respects; (a) it is intended be much easier to use and (b) it is not optimized for efficient access to large amounts of data. Rather it is intended to allow an application to easily browse and read small amounts of additional information specific to a particular ITEMID.
IConnectionPointContainer	This interface provides access to the connection point for IOPCShutdown. The general principles of ConnectionPoints are covered in the Microsoft DCOM Documentation. The reader is assumed to be familiar with this technology. OPC 2.0 Compliant Servers are REQUIRED to support this interface.

NOTE: Version 1.0 of this specification listed IEnumUnkown as an interface on the OPC Server. This was an error and has been removed. The semantics of QueryInterface do not allow such an implementation. The proper way to obtain a group enumerator is through IOPCServer::CreateGroupEnumerator.

For detailed information on each interface, refer to the OPC DA versions 2.0-2.05a specification.

Back to Top

OPC Group Object

The OPCGroup object is the object that an OPC server delivers to manage a collection of items. The interfaces that this object provides include:

Interface	Description
IUnknown	The server must provide a standard IUnknown Interface. Since this is a well defined interface it is not discussed in detail. See the OLE Programmer’s reference for additional information. This interface must be provided, and all functions implemented as required by Microsoft DCOM.
IOPCGroupStateMgt	Allows the client to manage the overall state of the group. Primarily this allows changes to the update rate and active state of the group.
IOPCPublicGroupStateMgt (optional)	This optional interface is used to convert a private group to a public group. Servers optionally provide this interface on group objects. A group created by a client is always created initially as a private group. This interface can be obtained from that private group in order to convert the group to a public group.
IOPCAsyncIO2	This interface is similar to IOPCAsync and it is intended to replace it. It allows a client to perform asynchronous read and write operations to a server. The operations will be ‘queued’ and the function will return immediately so that the client can continue to run. Each operation is treated as a ‘transaction’ and is associated with a transaction ID. As the operations are completed, a callback will be made to the IOPCDataCallback in the client. The information in the callback will indicate the transaction ID and the results of the operation.
IOPCAsyncIO (obsolete - V1)	This interface was replaced by IOPCAsyncIO2. IOPCAsyncIO allows a client to perform asynchronous read and write operations to a server. The operations will be ‘queued’ and the function will return immediately so that the client can continue to run. Each operation is treated as a ‘transaction’ and is associated with a transaction ID. As the operations are completed, a callback will be made to the IAdvise Sink in the client (if one has been established). The information in the callback will indicate the transaction ID and the error results. By convention, 0 is an invalid transaction id. Also the expected behavior is that for any one transaction to Async Read, Write and Refresh, ALL of the results of that transaction will be returned in a single call to OnDataChange.
IOPCItemMgt	This interface allows a client to add, remove and control the behavior of items is a group.
IConnectionPointContainer	This interface provides functionality similar to the IDataObject but is easier to implement and to understand and also provides some functionality which was missing from the IDataObject Interface. The client must use the new IOPCAsyncIO2 interface to communicate via connections established with this interface. IOPCAsyncIO2 is described above. The ‘old’ IOPCAsnyc will continue to communicate via IDataObject connections as in the past. Note that IConnectionPointContainer is implemented on the OPCGROUP rather than on the individual items. The general principles of Connection Points are explained in the Microsoft DCOM Documentation.
IOPCSyncIO	Allows a client to perform synchronous read and write operations to a server. This function reads the value, quality and timestamp information for one or more items in a group. The operations will run to completion.
IDataObject (obsolete V1)	IDataObject is implemented on the OPCGroup rather than on the individual items. This allows the creation of an Advise connection between the client and the group using the OPC Data Stream Formats for the efficient data transfer. It is required that the following methods be supported: DAdvise, DUnadvise. Because the IDataObject deals with a STREAM rather than individual items, the following methods do not need to be supported (they can be implemented as stubs which return E_NOTIMPL. GetData, GetDataHere, GetCanonicalFormatEtc. The server vendor may chose to implement additional methods on the IDataObject. It is the intent of this design that data items be transferred to applications primarily via the Advise connection or via the Synchronous or Asynchronous Read methods.

The sections below describe the general properties of an OPC Group.

Back to Top

General Properties of a Group

The OPCGroup has certain general properties and behaviors which affect the operation of the Interfaces and Methods. These are discussed below.

Name

Each group has a name. For private groups the name must be unique among the other private groups that belong to that client. For public groups the name must be unique among all of the public groups. While a client can change the name of a private group, the name of a public group cannot be changed. A private Group and a public group may have the same name as long as the client is not connected to the public group with the same name.

Group names are Case Sensitive. Group1 would be different from group1.

Cached data

The methods that use the interfaces described above, allow the client to specify that some operations can be performed on CACHE or DEVICE.

It is expected that most servers will implement some sort of CACHE.

The way the group functions described above behave differs slightly based on which source is specified. The actual details of the implementation of this functionality are up to the server vendor.

In most cases, access to CACHE data is expected to be fast while access to the DEVICE is expected to be slow but more accurate. CACHE data is affected by the Active state of the group and the items in the group while DEVICE data is not. Note again that although we sometimes make suggestions, this specification does not dictate any particular implementation or performance.

Back to Top

Active

Groups and Items within Groups have an Active Flag. The active state of the group is maintained separately from the active state of the items. Changing the state of the group does not change the state of the items. For the most part, the Active flag is treated as ‘abstract’ within this specification. The state of these flags affects the described behavior of various interfaces in a well defined way. The implementation details of these capabilities is not dictated by this specification.

In practice, it is expected that most servers will make use of this flag to optimize their use of communications and CPU resources. Items and Groups which are not active do not need to be maintained in the CACHE.

It is also expected that clients will simply set and clear active flags of groups and items as a more efficient alternative to adding and removing entire groups and items. For example, if an operator display is minimized, its items might be set to inactive.

Refer to the Data Acquisition and Active State Behavior summary earlier in this document for a quick overview of the behavior of a client and server with respect to the active state of a group and items.

OnDataChange within the client’s address space can be called whenever any active item data in a active group changes, where “change” is defined as a change in value (from the last value sent to this client), or a change in the Quality of the value. The server can return values and quality flags for those items within the group that changed.(this will be discussed more in later sections)

Back to Top

Update Rate

The client can specify an update rate for each group. This determines the time between when the exception limit is checked. If the exception limit is exceeded, the CACHE is updated. The server should make a ‘best effort’ to keep the data fresh. This also affects the maximum rate at which notifications will be sent to the IAdvise sink. The server should never send data to a client at a rate faster than the client requests.

IMPORTANT:

Note that this is NOT necessarily related to the server’s underlying processing rate. For example if a device is performing PID control at 0.05 second rate the an MMI requests updates at a 5 second rate via OPC, the device would of course continue to control at a 0.05 second rate.

In addition, the server implementation would also be allowed to update the cached data available to sync or async read at a higher rate than 5 seconds if it wished to do so. All the update rate indicates is that (a) callbacks should happen no faster than this and (b) the cache should be updated at at least this rate.

The update rate is a request from the client. The server should respond with an update rate that is as close as possible to that requested.

Back to Top

Time Zone (Time Bias)

In some cases the data may have been collected by a device operating in a time zone other than that of the client. Then it will be useful to know what the time of the device was at the time the data was collected (e.g. to determine what ‘shift’ was on duty at the time). The Time zone Bias provides the information needed to convert the time stamp on the data back to the local time of the device.

This time zone information may rarely be used and the device providing the data may not know its local time zone. Therefore, it was not prudent to add this overhead to all data transactions. Instead, the OPCGroup provides a place to store a time zone which can be set and read by the client. The default value for this is the time zone of the host computer. The OPCServer will not make use of this value. It is there only for the convenience of the client.

Back to Top

Percent Deadband

Deadband will only apply to items in the group that have a dwEUType of Analog available. If the dwEUType is Analog, then the EU Low and EU High values for the item can be used to calculate the range for the item. This range will be multiplied with the Deadband to generate an exception limit. An exception is determined as follows: Exception if (absolute value of (last cached value - current value) > pPercentDeadband * (EU High - EU Low) )

If the exception limit is exceeded, then the last cached value is updated with the new value and a notification will be sent to the IAdviseSink (if any). The PercentDeadband is an optional behavior for the server. If the client does not specify this value on a server that does support the behavior, the default value of 0 (zero) will be assumed, and all value changes will update the CACHE. Note that the timestamp will be updated regardless of wether the cached value is updated.

The UpdateRate for a group determines time between when a value is checked to see if the exception limit has been exceeded. The PercentDeadband is used to keep noisy signals from updating the client unnecessarily.

Back to Top

ClientHandle

This handle will be returned in the data stream to IAdviseSink. This allows the client to identify the group to which the data packet belongs. It is expected that a client will assign unique value to the client handle if it intends to use any of the asynchronous functions of the OPC interfaces, including IOPCAsyncIO, IOPCAsyncIOs, and IDataObject/IAdviseSink or IConnectionPoint/IOPCDataCallback interfaces.

Reading and Writing Data

There are basically three ways to get data into a client (ignoring the ‘old’ IDataObject/IAdviseSink).

• IOPCSyncIO::Read (from cache or device)
• IOPCAsyncIO2::Read (from device)
• IOPCCallback::OnDataChange() (exception based) which can also be triggered by IOPCAsyncIO2::Refresh.

In general the three methods operate independently without ‘side effects’ on each other.

There are two ways to write data out:

• IOPCSyncIO::Write
• IOPCAsyncIO2::AsyncWrite

Back to Top

Public Groups

It is required that the server track each client’s group properties (update rate, deadband, active status, timezone, lcid) for a public group. For example, if two clients with different LCIDs want data from a public group, they can change the state of the group to reflect their LCID and the server must keep track of both.

Back to Top

OPC DA Version Interoperability

Data Access Servers may be compatible with the requirements of Versions 1.0a, 2.x or 3.0 of the specification or with any combinations of the Data Access Specification Versions. Data Access Clients may also be compatible with the requirements of Versions 1.0a, 2.x or 3.0 of the specification or with any combinations of the Data Access Specification Versions.

The following table lists the features supported by each one of the OPC DA versions.

Back to Top