OPC Data Access

OPC Data Access is used to access real-time values in process devices. An OPC DA Client reads only the current values provided by a device and can also write data. A typical example of an OPC Client would be a Spreadsheet application reading the active power output from a wind turbine. When the OPC Client connects to wind turbine’s OPC Server, the OPC Server will initiate communication with the device (for example start to poll Modbus registers).

Data Access Example
Figure 1. Data Access Example

OPC Data Access is the most used OPC specification: About 80% of all OPC servers are OPC DA servers. The term “device” in OPC DA is a very broad spectrum, and stands as synonym for all kinds of data sources. OPC Servers exist to provide data generated by:

  • Distributed Control Systems in a plant or refinery

  • Programmable Logic Controllers

  • SCADA Systems

  • Individual Sensors

  • Analyzers

  • Databases

With its integrated OPC DA Client, inmation’s Connector Service can make use of the data in all the above devices - and all other devices that provide their own OPC Data Access Server.

By using asynchronous principles to transfer the data, the design of the OPC DA specification allows for architectures with a very high read performance. Synchronous data transfer is possible as well, but not many OPC Clients use it.

OPC DA is very easy to use, the basic mechanism behind a DA connection is:

  1. Server Browsing / Connect OPC Server

  2. Browse address space for data items (optional)

  3. Create group of items to read/write data values

After group creation, the client will in most cases receive a continuous stream of real-time data. A client can periodically call a life ping function (GetStatus) from an OPC Server to detect if the OPC Server is still available.

Data can be read in 2 different ways, from Cache or straight from Device. Each OPC data item contains:

  • Data Value in variant data type

  • Timestamp

  • Quality (status code)

Over time, the OPC Foundation created revisions of the Data Access specification. Today 3 versions of OPC Data Access exist:

  • DA 1.00a

  • DA 2.05a

  • DA 3.0

In many parts the different revisions overlap, but there are differences. For example, a DA 1.00a OPC Client can’t use the callback interface of a DA 2.05a OPC Server. If in doubt, it is better to check if the same version is supported by both Client and Server.

Server Browsing (OPCEnum)

Classic OPC is based on COM/DCOM communication. When a COM Client connects to the COM Server, it needs the CLSID to execute the CoCreateInstanceEx call. Therefore, an OPC Client needs to obtain the remote OPC Server’s CLSID before attempting to connect. To help in finding the CLSID, the OPC Foundation provides a COM Component called OPCEnum.

OPCEnum assists the OPC client in 3 different ways:

  1. Browsing a remote computer for available OPC Servers and returning a list of CLSIDs (IOPCServerList::EnumClassesOfCategory)

  2. Providing the CLSID for a given PROGID (IOPCServerList::CLSIDFromProgID)

  3. Providing the PROGID and server details for a given CLSID (IOPCServerList::GetClassDetails)

The first task only needs to be done if browsing the remote machine is necessary. Most vendors' free-test OPC clients implement this, in order to show the user the available OPC Server on a computer.

The second task is often used for first-time connecting: OPC Client applications ask the user to provide hostname and ProgID for the connection. When the OPC Client connects the first time, OPCEnum is used to get the CLSID from the ProgID.

OPCEnum Interface
Figure 2. OPCEnum Interface

All professional OPC Clients use OPCEnum, as it is the most secure approach and at the same time is more convenient for the user. When configuring DCOM security, you open ACLs for the component OPCEnum.

The alternative is either less secure as:

  • The OPC Client needs administrative permissions on the OPC Server machine to do a remote registry browse. This implementation is not part of the OPC standard though.

Or it is less convenient as:

  • User needs to provide the CLSID in client application GUI

  • User needs to import the CLSID and ProgID locally so that the OPC Client can read it in local registry

Older versions of OPCEnum (<101.2) are not compatible with 64bit Windows installations. On 64bit operating systems, OPCEnum is usually installed in C:\Windows\SysWOW64\.

Address Space Browsing

In OPC DA and OPC HDA communication, the OPC Client does not need upfront knowledge about how the data is structured in a device. It contacts the OPC Server to find out what data items are available and the server provides its address space. Usually, this is a hierarchical tree that the client can navigate though but some OPC Servers can also have a flat address space. The elements on an address space are branches and leaves.

  • A branch can contain more branches, usually corresponding to a container level in the physical data model

  • A leaf is always part of a branch and is a data item that can be requested

During browsing the OPC Client picks one or multiple items, and the OPC Server provides the Fully Qualified ItemIDs for these items (String). The ItemIDs are used when adding items to a group. When adding an item, the OPC Client creates a client handle and the OPC Server creates a server handle. Handles are 32bit identifiers for the ItemID string, and are used by all later client-to-server communication.

OPC DA Address Space Browsing
Figure 3. OPC DA Address Space Browsing

Some specific devices use data structures where browsing does not make sense. In other cases browsing is restricted due to the nature of the device (e.g. Modbus register). In these cases the OPC Server can provide place holders that need to be changed by the end user.

It is possible to filter the OPC Clients browsing requests, which makes sense when dealing with large address spaces.

Item browsing is an optional interface in the OPC DA 2.05 specification, so some OPC DA 2.05 servers exist that do not support browsing. In OPC DA 3.0, browsing is mandatory.

Synchronous / Asynchronous Communication

Data transfer between OPC DA Clients and DA Servers can be synchronous or asynchronous. Different scenarios exist for how data can be provided by a device. When the OPC Client requests data the first time, the OPC Server needs to contact the data source and read the values. This happens below the OPC layer of the server and is sometimes called “scanning the device”.

Sometimes scanning can be a trivial task (i.e. when the value is already present in memory of OPC Server or available on an OPC Server computer) or a longer operation (i.e. the value needs to be requested from SCADA device via radio communication). For longer operations, synchronous communication between OPC Client and Server would be bad if:

  1. The OPC Client requests data via a sync read

  2. The OPC Server starts scanning and reads value from device

  3. When complete it replies to OPC Client

When waiting for server’s response the OPC Client cannot do anything. It is waiting for the server to finish, which is why it is sometimes referred to as a blocking call. Synchronous communication involves a polling mechanism: If data is required in 1000ms resolution, a request needs to be created by the OPC Client every 1000ms.

Data Access Synchronous Read
Figure 4. Data Access Synchronous Read

It is more efficient to use asynchronous communication. Here, the client posts a request to the server, and the server’s response is done via a callback. Different ways exist in the OPCGroup object of the data access specification that asynchronous and synchronous reads can be realized. Highest read performance is achieved with the OnDataChange subscription that only transmits data to the OPC Client when a value changes - this is the method that inmation uses to read data:

  1. OPC Client creates a subscription at the server, providing information on what items it needs and in which update rate

  2. OPC Server starts scanning the device to read the values

  3. When values do not change, the server will not respond to client

  4. When value changes, OPC Server sends data value to client via callback

Data Access Subscription
Figure 5. Data Access Subscription

Also, when multiple OPC Clients access a single OPC Server asynchronous operations are very useful. Synchronous polling from multiple clients would involve a high amount of processing on the server side.

Most data throughput can be achieved using Data Access 3.0, which implements the IOPCItemSamplingMgt interface that allows the transmission of multiple values with one callback.

Cache or Device Reads

Two different types of DA reads exist: reading from Cache or reading from Device.

If the client requests a device read from the OPC Server, it forces the OPC Server to scan the device immediately. This can cause a problem, because device reads used in a polling mechanism can overload the device easily. This is especially true if multiple OPC Clients request data. A better option is to leave control over device communication with the OPC Server, and that is done by implementing a cache read. A cache read provides values from an internal data cache in the OPC Server if:

  • OPC Client requests data in a specific update rate

  • OPC Server starts scanning the device in a scanning rate, usually slightly faster than the update rate

  • These scans are used to fill data to the cache

  • OPC Client response is created with data from cache

If multiple clients request the same data item in the same update rate with a cache read, it does not require multiple reads to the device. For the scanning rate, most vendors implement minimum values to prevent device overloading.

Cache or Device Reads
Figure 6. Cache or Device Reads

A central idea of OPC communication is that the OPC Client application does not need any knowledge about device communication, this goes hand in hand with using cache reads. The OPC Server vendor usually knows how to efficiently handle device scanning. With inmation, cache reads are used by default - it is ideally suited for the 24/7 operation of the OPC Client.


OPC DA communication transfers real-time data. In the case of OPC this means knowing the point in time when a value was created in the process. If possible the OPC Server reads a timestamp from the process (e.g. a DCS has timestamps that can be read by OPC Server). If this is not possible, the OPC Server creates a timestamp on its own.

Real-time in the world of OPC does not make a statement about how long the transfer time is between sensor and OPC Client, but makes sure that the timestamp is as close to the process as possible. It is most important that you CAN get a value with a timestamp from the device to the end processing application.

OPC Timestamps
Figure 7. OPC Timestamps

OPC uses standard UTC timestamps with a length of 8 Bytes.

Most interactive client applications will add the local time offset (including day light saving times offset) to the OPC Server, so the end user can see local instead of UTC time. The local time zone offset of the OPC Server can be read by the client, in case the OPC Server / Client operate in different time zones (Property of Group Object). This has to be treated carefully if daylight saving time (DST) offsets changes: DST offset is never part of the TimeBias property of group object, the OPC Client is assumed to be in an area with the same DST offset as the server.

In inmation, UTC timestamps are stored in the database. This is most convenient, since the data processing application can decide to add any offset, or continue working with UTC timestamps.


The quality field in a data item shows information about the state of the transferred data. It consists of 3 different parts (Quality 2Bit, Status 4Bit and Limit 2Bit). Quality has the following possibilities:

  • Quality code will be "good" if data was read normally and connection was uninterrupted

  • Quality code will be "bad" if the connection between OPC Server and device failed

  • Quality code can be "uncertain" if the OPC Server can’t know if current value is good or bad (for example if it knows only the last valid value, but not the current)

Status, or sub quality, can have multiple values and is usually tied to the main quality. If it is not possible to determine sub quality, OPC Server returns 0: “non-specific”:

  • (Good/Bad) Non-specific – The special sub quality detected

  • (Bad) Not-connected – device not connected

  • (Bad) Comm Failure – communication to device failed

  • (Uncertain) Last usable Value – value is stale

The limit field has four possible values. If no limit can be determined, the OPC Server returns 0.

  • Not Limited

  • Low Limited

  • High Limited

  • Constant

OPC DA Quality
Figure 8. OPC DA Quality

The OPC specification defines a set of possible qualities and sub qualities but the vendor implementing the OPC Server decides which qualities to implement. A poorly designed OPC Server might only show a small subset of qualities, whereas a better implementation might be more granular about quality codes. Sometimes the quality information can be read from the device, but often quality information is determined during the OPC Server’s communication with the device.