C++ Based OPC UA Client/Server/PubSub SDK
Tutorial Server COM OPC DA Migration

OPC Unified Architecture provides a similar Data Access functionality like the widely adopted COM based OPC Data Access 2.05A and 3.0 interface.

This tutorial gives a short explanation of the mapping between the COM based OPC DA interface and the OPC UA Data Access features, provides a framework for the mapping of existing OPC DA servers to OPC UA and describes the sample code that is used to simulate such an OPC DA server.

This tutorial implements the interfaces of the SDK directly and is not using the toolkit level. See Starting Points for Users of the SDK for the two different implementation options available.

Introduction to migration from COM DA to OPC UA

There are two main areas that need to be compared for understanding the differences between OPC UA and COM based OPC DA and to understand the necessary mapping.

One is the content and the structure of the OPC server address space and the other is the API to access the information in the server address space.

The address space in COM DA is composed of branches used to create a hierarchical structure and OPC Items providing the data that can be accessed in the server. OPC UA allows to provide a fully object oriented address space. Objects can contain variables and methods and can fire events. In addition the objects have a type that is also provided with a complete description in the address space. But for the mapping of COM based OPC DA we just need Folder objects representing branches and variables representing OPC Items.

In COM DA the OPC Items have mandatory properties like value or data type and optional properties like the value range (High EU and Low EU). In OPC UA all nodes (objects, variables, methods, types) have attributes describing the nodes like display name. The number of attributes depends on the node class. Variables have the longest list of attributes like value, data type and access level. In addition nodes can have properties in OPC UA but properties are just specialized variables. In general the mandatory properties in COM DA can be mapped to attributes in OPC UA and the optional properties in COM DA to properties in OPC UA.


The API for accessing information from the OPC server can be separated into two areas, the context that is needed for communication like creating a connection and the methods to access information like browse and read.

The context like server and group object in COM DA can be mapped to session and subscription in OPC UA and the methods for creating the context are also similar.

The bigger difference is in the methods to access the real information like navigating through the address space and reading data. In COM DA there are much more methods that are needed for one action or several variations of the same method. In OPC UA there is a much smaller but more generic set of methods called services.

One good example is Read. For COM DA there are several different variations of read calls plus special calls to get property values. In OPC UA there is only one read method that is used to read values of variables but also all other attributes of nodes.

Mapping provided by the example

Like described in Starting Points for Users of the SDK, the SDK provides two levels. The first level is the SDK. It is implementing all common functionality and the management of the context like Sessions and Subscription. The second level provides a toolkit for rapid OPC server development.

Most of the server tutorials are using the toolkit level.

This tutorial implements the interfaces of the SDK level directly since all the necessary functionality like managing the address space and sampling data is already implemented in existing COM based OPC Data Servers. To reduce resource consumption the mapping of COM based OPC Data Access servers to OPC UA is just a thin wrapper on top of this existing functionality. In a second step this can be further optimized to not loose performance on the data access part.

The following figure shows the small list of methods that need to be implemented for the mapping of the existing OPC DA server to OPC UA.


To simplify the mapping of the NodeManager and IOManager to the existing OPC information, the migration example provides a generic layer that can be reused for different existing OPC Data Access servers. This layer is indicated in green in the next figure.

It expects that the address space configuration information part of the OPC server is available as configuration data base that contains all information other than the current OPC item value. The information is provided through the interface ComDaAddressSpace that is defined by the example. It is used by the class NodeManagerComDaMigration that implements the NodeManager interface and by the IOManagerComDaConfig that implements the IOManager interface for all attributes other than the value attribute.

The other interface ComDaGroup defined by the example is a subset of the OPCGroup functionality necessary to monitor, read and write values. It is used by the IOManagerComDa class that implements the IOManager for the value attribute.

The blue layer represents the mapping code that is necessary to access the configuration information for the interface ComDaAddressSpace and to access the OPC Item values. The access to the values can be directly mapped to an existing OPC Group object.


In a second step the IOManager implementation used to access the value attribute can be replaced with an optimized implementation of the IOManager interface.


The next figure shows the interfaces and sample classes more detailed.

The class ComDaAddressSpaceSample provides a simple implementation of the interface ComDaAddressSpace. The address space contains a list of branches containing a list of OPC Items.

The class ComDaGroupSample provides a simple data simulation implementing the interface ComDaGroup. This interface would normally be mapped to the OPC Group object.