OPC Data Access Fundamentals

This section introduces OPC Data Access and covers topics which are specific to OPC Data Access. Additional common topics including Windows NT, UNICODE, Threading Models, etc are discussed in the OPC Overview Document (OPCOVW.DOC). 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 2-1 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 2-2 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 cleint.

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 2-3 - 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 2-4 - 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 2-5 - 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 2-6 - 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.


Overview of the Objects and Interfaces

The OPC Server object provides a way to access (read/write) or communicate to a set of data sources.. The types of sources available are a function of the server implementation.

An OPC client connects to an OPC server and communicates to the OPC server through the interfaces. The OPC server object provides functionality to an OPC client to create and manipulate OPC group objects. These groups allow clients to organize the data they want to access. A group can be activated and deactivated as a unit. A group also provides a way for the client to ‘subscribe’ to the list of items so that it can be notified when they change.

Note: All COM objects are accessed through Interfaces. The client sees only the interfaces. Thus, the objects described here are ‘logical’ representations which may not have anything to do with the actual internal implementation of the server. The following figure is a summary of the OPC Objects and their interfaces. Note that some of the interfaces are Optional (as indicated by [ ]).

Figure 2-7 - Standard OPC Server Object
 

Figure 2-8 - Standard OPC Group Object







The Address Space and Configuration of the Server

This release of the OPC specification assumes that a server configuration address space may be managed and persistently stored using the IPersistFile interface. Only the server specific information is persistently stored. All client configuration information (Group and Item Definitions) must be persistently stored by the respective client application. All Handles that are defined in the system are not guaranteed to have the same value between sessions of the client and server conversation.

It is important to distinguish the address space of the server (also known as the server configuration) from the small subsets of this space that a particular client may be interested in at a particular time (also known as the ‘groups’ and ‘items’). The details of how these client specific groups are maintained are discussed in detail in this specification. The persistent storage of groups is the responsibility of the respective clients. The details of how the server address space is defined and configured are intentionally left unspecified. For example the server address space might be:

 It is expected that this server address space is stable and is managed within the server. The clients will define and manage the relatively small lists of items called ‘groups’ as needed from time to time. The interfaces described here provide the client the ability to easily define, manage, and recreate these lists as needed through the use of ‘OPCGroups’. The clients direct the server to create, manage and delete these groups on their behalf (persistence of the groups is the responsibility of the client application). Although it is possible, with the usage of public groups, that the server could provide persistent storage of these type of groups, or treat them as server defined groups. Application Level Server and Network Node Selection OPC Data Access supports the concept of organizing client requests into groups within a server. Such groups can contain requests for data from only one particular OPC Server object. In order to access data, a client application will need to specify the following: It is beyond the scope of this specification to discuss the implications of this on the architecture and user interface of the client program. Synchronization and Serialization Issues By ‘synchronization’ we mean the ability of a client to read or write values and attributes in a single transaction. For example, most applications want to insure that the value, quality and time stamp attributes of a particular item are in ‘sync’. Also, a reporting package might want to insure that a group of several values read together as part of a ‘Batch Report’ are in fact part of the same batch. Finally, a recipe download package would want to insure that all of the values in the group were sent together and that the recipe was not started until all of the values had been received. These are just a few examples where synchronization is important.

The short answer is that OPC itself cannot insure that all of these synchronization tasks can be accomplished. Additional handshaking and flag passing between the client application and the device server to signal such states as ‘ready’ and ‘complete’ will be required. There are also things that need to be specified about the behavior of OPC servers to assure that OPC does not prevent this sort of synchronization from being done.

It will be seen later that OPC allows explicit reads and writes of groups of items or of individual items as well as exception based data connections (OnDataChange). Without jumping ahead too far it is possible to make some general observations about these issues and about server behavior.
  1. In general, OPC Servers should try to preserve synchronization of data items and attributes that are read or written in a single operation. Synchronization of items read or written individually in separate operations is not required. Clearly, data read from different physical devices is difficult to synchronize.
  2. Reads and writes of data items which can be accessed by more than one thread must be implemented to be thread safe, to the extent that data synchronization is preserved as specified in this specification. Examples of where this is important might include: logic within a server where one thread services method executions while a separate thread performs the physical communications and writes the received data into a buffer area which is shared with the first thread. Another example might be the logic in a handler or proxy where a ‘hidden’ RPC thread servicing an OnDataChange subscription is writing data into a shared buffer which a thread in the client might be reading.
  3. Threading issues are always important but this is especially true on SMP systems.
By ‘Serialization’ we mean the ability of the client to control the order in which writes are performed.
  1. It is STRONGLY RECOMMENDED that write requests to the same device be handled ‘in-order’ by any server implementation. For example, an application might use a ‘recipe download complete’ flag which is set by the application after the individual recipe items are sent. In this case, the data must be transmitted to the physical device in the same order it was output to insure that the ‘complete’ flag is not set before all the data has actually arrived. Where the server buffers the outgoing data and implements a separate communications manager thread to send these outputs to the physical device (as is often the case), the server implementation must take extra care to insure that the order of the outputs is preserved.
  2. Where a client can both read values explicitly or receive updates via a callback attention must be given to defining exactly when a callback will or will not occur. This is discussed in more detail later.
Many of these issues will be clarified in the detailed descriptions of the methods below. Public (aka shared) Groups The purpose of the public group concept is to provide a way to share data configuration information across multiple client applications. Typically, in process control systems, multiple client applications are configured to monitor or control the same process control data using the same applications or tools. A public group can be created, such that only one application / end-user defines the items, and other client applications access the information in the public group by connecting to it. This facilitates keeping the definitions of the same data in sync, since only one client has to create and configure the attributes of the data items.

Because the information is shared across multiple clients, some restrictions may be required to make sure that the configuration information across multiple clients remains consistent.

 Persistent Storage Story OPC Servers may implement an optional interface to facilitate OPC clients telling an OPC server to persistent (store) the OPC server configuration information. OPC Server configuration information may include information about the devices and data source necessary to facilitate communication between the data source and the OPC server. Client configuration information, including the groups and items, are not persistently stored by an opc server.

Clients are responsible for the configuration and persistent storage of the groups and items that are required by their application..