C++ Based OPC UA Client/Server/PubSub SDK
Introduction to Classic OPC

This section provides a short overview for the Classic OPC interfaces.


In recent years, the OPC Foundation has defined a number of software interfaces to standardize the information flow from the process level to the management level. The main use cases are interfaces for industrial automation applications like HMIs and SCADA systems to consume current data from devices and to provide current and historical data and events for management applications.

According to the different requirements within industrial applications, three major OPC specifications have been developed: Data Access (DA), Alarm & Events (A&E), and Historical Data Access (HDA). Access to current process data is described in the DA specification, A&E describes an interface for event-based information, including acknowledgement of process alarms, and HDA describes functions to access archived data. All interfaces offer a way to navigate through the address space and to provide information about the available data.

OPC uses a client–server approach for the information exchange. An OPC server encapsulates the source of process information like a device and makes the information available via its interface. An OPC client connects to the OPC server and can access and consume the offered data. Applications consuming and providing data can be both client and server. The following figure shows a typical use case of OPC clients and servers.

Typical use case of OPC clients and servers

Classic OPC interfaces are based on the COM and DCOM technology from Microsoft.

The advantage of this approach was the reduction of the specification work to the definition of different APIs for different specialized needs without the requirement to define a network protocol or a mechanism for interprocess communication. COM and DCOM provide a transparent mechanism for a client to call methods on a COM-object in a server running in the same process, in another process, or on another network node. Using this technology available on all PCbased Windows operating systems reduced the development time of the specifications and products and the time-to-market for OPC. This advantage was important for the success of OPC.

The two main disadvantages are the Windows-platform-dependency of OPC and the DCOM issues when using remote communication with OPC. DCOM is difficult to configure, has very long and non-configurable timeouts, and cannot be used for internet communication.

OPC Data Access

The OPC Data Access interface enables reading, writing, and monitoring of variables containing current process data. The main use case is to move real-time data from PLCs, DCSs, and other control devices to HMIs and other display clients. OPC DA is the most important OPC interface. It is implemented in 99% of the products using OPC technology today. Other OPC interfaces are mostly implemented in addition to DA.

OPC DA clients explicitly select the variables (OPC items) they want to read, write, or monitor in the server. The OPC client establishes a connection to the server by creating an OPCServer object. The server object offers methods to navigate through the address space hierarchy to find items and their properties like data type and access rights.

For accessing the data, the client groups the OPC items with identical settings such as update time in an OPCGroup object. The following figure shows the different objects the OPC client creates in the server.

Objects created by an OPC client to access data

When added to a group, items can be read or written by the client. However, the preferred way for the cyclic reading of data by the client is monitoring the value changes in the server. The client defines an update rate on the group containing the items of interest. The update rate is used in the server to cyclic check the values for changes. After each cycle, the server sends only the changed values to the client.

OPC provides real-time data that may not permanently be accessible, for example, when the communication to a device gets temporarily interrupted. The Classic OPC technology handles this issue by providing timestamp and quality for the delivered data. The quality specifies if the data is accurate (good), not available (bad), or unknown (uncertain).

OPC Alarm & Events

The OPC A&E interface enables the reception of event notifications and alarm notifications. Events are single notifications informing the client about the occurrence of an event. Alarms are notifications that inform the client about the change of a condition in the process. Such a condition can be the level of a tank. In this example, a condition change can occur when a maximum level is exceeded or is fallen below a minimum level. Many alarms include the requirement that the alarm has to be acknowledged. This acknowledgement is also possible via the OPC A&E interface.

OPC A&E thus provides a flexible interface for transmitting process alarms and events from different event sources.

To receive notifications, the OPC A&E client connects to the server, subscribes for notifications, and than receives all notifications triggered in the server. To limit the number of notifications, the OPC client can specify certain filter criteria.

The OPC client connects by creating an OPCEventServer object in the A&E server in the first step and by generating an OPCEventSubscription used to receive the event messages in the second step. Filters for these event messages can be configured separately for each subscription. The following figure shows the different objects the OPC client creates in the server.

Objects created by an OPC client to recieve events

In contrast to OPC DA, there is no explicit request for specific information like reading values; however, all process events are supplied and the client can limit the quantity of the events by setting certain filter criteria, for example, filter by event types, by priority, or by event source.

OPC Data Historical Access

Where OPC Data Access gives access to real-time, continually changing data, OPC Historical Data Access provides access to data already stored. From a simple serial data logging system to a complex SCADA system, historical archives can be retrieved in a uniform manner.

The OPC client connects by creating an OPCHDAServer object in the HDA server. This object offers all interfaces and methods to read and update historical data. A second object OPCHDABrowser is defined for browsing the address space of the HDA server.

The main functionality is the reading of historical data in three different ways. The first mechanism reads raw data from the archive, where the client defines one or more variables and the time domain he wants to read. The server returns all values archived for the specified time range up to the maximum number of values defined by the client. The second mechanism reads values of one or more variables for specified timestamps. The third read mechanism computes aggregate values from data in the history database for the specified time domain for one or more variables. Values include always the associated quality and timestamp.

In addition to the read methods, OPC HAD also defines methods for inserting, replacing, and deleting data in the history database.

Other OPC Interface Standards

OPC specified several additional standards as base specifications or for specialized needs. Base specifications are OPC Overview and OPC Common defining interfaces and behavior that is common to all COM-based OPC specifications. The following figure gives an overview for all Classic OPC specifications.

OPC Security specifies how to control client access to servers to protect sensitive information and to guard against unauthorized modification of process parameters.

OPC Complex Data, OPC Batch, and OPC Data eXchange (DX) are extensions to OPC DA. Complex Data defines how to describe and transport values with complex structured data types. OPC DX specifies the data exchange between Data Access servers by defining the client behavior and the configuration interfaces for the client inside a server. OPC Batch extends DA for the specialized needs of batch processes. It provides interfaces for the exchange of equipment capabilities corresponding to the S88.01 Physical Model and current operating conditions.

Classic OPC interface standards

OPC Commands defines mechanisms to call methods or to execute programs via OPC. This specification was never released since it was finished after OPC UA was started. But its content and functionality is completely incorporated into UA.


OPC XML-DA was the first platform-independent OPC specification replacing COM/DCOM with HTTP/SOAP and Web Service technologies. Thus a vendorand platform-neutral communication infrastructure was introduced and widely accepted functionality of OPC Data Access was retained.

Since typical Web Services are stateless, the functionality was reduced to the minimum set of methods to exchange OPC Data Access information, without the need for methods to create and modify a context for communication. Only eight methods were needed to cover the key features of OPC Data Access.

The eight services are the following:

  • GetStatus to verify the server status
  • Read to read one or more item values
  • Write to write one or more item values
  • Browse and GetProperties to get information about the available items
  • Subscribe to create a subscription for a list of items
  • SubscriptionPolledRefresh for the exchange of changed values of a subscription
  • SubscriptionCancel to delete the subscription.

OPC XML-DA was designed for internet access and enterprise integration. But based on its platform-independence, it was mainly implemented in embedded systems and on non-Microsoft platforms. But due to its high resource consumption and limited performance, it was not as successful as expected for this type of applications.

To continue the OPC introduction you can read Motivation for OPC UA or Introduction to OPC UA.