OpenSCADAWiki: Home Page En/Doc/OPCUA
 

"OPC-UA" modules of "Data acquisition" and "Transport protocols" subsystems

Parameter Module 1 Module 2 Library
ID: OPC_UA OPC_UA libOPC_UA
Name: Client OPC-UA Server OPC-UA Library of implementing OPC-UA into OpenSCADA
Type: DAQ Protocol Library
Source: daq_OPC_UA.so daq_OPC_UA.so libOPC_UA.{h,cpp}
Version: 1.6 1.8 1.2
Author: Roman Savochenko, Maxim Lysenko (2010)
Description: Provides OPC-UA client service implementation. Provides OPC-UA server service implementation. Provides the protocol OPC-UA implementing into parts of client and server, as a separated library.
License: GPL2 GPL2 LGPL3

Contents

Introduction

OPC (OLE for Process Control) — it is the family of protocols and technologies that provide the single interface to control the objects of automation and technological processes. The creating and support of specifications of OPC coordinates an international nonprofit organization OPC Foundation, established in 1994 by the leading manufacturers of industrial automation.

In view of the fact that a significant influence in the OPC Foundation organization has the Microsoft corporation, OPC protocols, until recently, was single platform and closed, due to binding to the closed technologies of MS Windows. However, more recently, the OPC Foundation organization has created multi-platform solutions such as OPC XML-DA and OPC-UA. Most interesting of them is the OPC-UA, as a solution unifying all the earlier protocols in an open and multi-platform technologies.

This module implements the interface and protocol support for OPC-UA in the form of client service, and as the OPC-UA server. Client service of OPC-UA is implemented by the same name module of the subsystem "Data acquisition", and the server is implemented by the subsystem's "Protocols" module. The OPC-UA protocol's specific implementing code by the module was moved to a separated library under the LGPL3 license, by the users requests.

In the current version of these modules and the library it is implemented the binary part of the protocol and basic services in unsafe mode and safe mode of policies "Base128Rsa15" and "Base256". Later it is planned to extend the module to work via HTTP/SOAP and implementation of other OPC-UA services.

Although the OPC-UA protocol is multi-platform, its specification and SDK are not freely available, but are provided only to members of the OPC Foundation organization. For this reason, the implementation of these modules has faced significant obstacles and problems.

Firstly, the protocol OPC-UA is complex and its realization in general without specification an extremely laborious. For this reason, the work on these modules for a long time was not started, and only thanks to sponsorship by an organization-member of OPC Foundation the OpenSCADA project received documentation of the specification. The SDK and source code ANSIC-API of the OPC-UA protocol have not been received due to their incompatibility with the GPL license and as a consequence, the potential threat of violation of the license when working with the source code, which could lead to subsequent legal problems with the free distribution of these modules.

Secondly, even the presence of the specification does not allow to solve some technical question without an example of implementation and possibility of test the working prototype of the client and server of OPC-UA. For example, it is the technical features of the implementation of symmetric encryption algorithms and the keys for them do not allowed to make the implementation of support for security policy at once.

To debug the operation of the modules the demonstration software of company Unified Automation was used, in consist of the OPC-UA client — UAExpert and Server — "OPC-UA Demo Server", from the SDK package. In view of the constantly developing process of same "UAExpert" client, as the OPC-UA specification implementing, it's new versions often have problems in work with the OPC-UA server from OpenSCADA. Generically the results of compatibility in work with clients and servers of the different developers you can get in the appendix.

1. The OPC-UA protocol

OPC-UA — it is the platform-independent standard by means of which the systems and devices of various types can interact by sending messages between the client and the server through various types of networks. The protocol supports secure communication through the validation of clients and servers, as well as the counteraction to attacks. OPC-UA defines the concept Services that the servers can provide, as well as services that the server supports for the client. Information is transmitted as the data types defined by OPC-UA and it producer, in addition the servers define object model, for which the clients can implement the dynamic review.

OPC-UA provides the combination of integrated address space with service model. This allows the server to integrate data alarms and events, the history in this address space, as well as provide access to them through the integrated services. Services also provide an integrated security model.

OPC-UA allows servers to provide for clients the definitions of types for access to the objects of the address space. OPC-UA supports the provision of data in various formats, including binary structures and XML-documents. Through the address space clients can request the server metadata that describe the data format.

OPC-UA appending the support for multiple connections between nodes instead of a simple hierarchy. Such flexibility in combination with types' definition allows to use OPC-UA for solving problems in the wide problem area.

OPC-UA is designed to provide the reliable output of data. Main feature of all OPC servers — the ability to issue the data and events.

OPC-UA is designed to support the wide range of servers, from simple PLC to industrial servers. These servers are characterized by the wide range of sizes, performance, platforms and functional capacity. Consequently, the OPC-UA defines the comprehensive set of possibilities, and the server can implement the subset of these possibilities. To compatibility ensure the OPC-UA defines subsets, named the Profiles that the server can indicate for agreement. Clients may subsequently make the review of server's profiles and make the interaction with the server, based on the profiles.

OPC-UA specification is designed as the core in the layer, isolated from the underlying computer technologies and network transports. This allows for OPC-UA if necessary to expand on the future technologies without excluding the framework of design. Currently, the specification defines two ways to data encode: XML/text and UA Binary. In addition, the two types of transport layer are defined: TCP and HTTP/SOAP.

OPC-UA is designed as the solution for migration from OPC clients and servers, which are based on Microsoft COM technologies. OPC COM servers (DA, HDA and A&E) can be easily reflected in the OPC-UA. Producers can independently make such migration or recommend users to use wrappers and converters between these protocols. OPC-UA unifies the previous models in the single address space with the single set of services.

2. Module of the server implementation

The server module contains an implementation code for the server part of the OPC-UA — server services, in part of the OpenSCADA specific, and using the library in part of the OPC-UA specific. To construct the OPC-UA server it is enough to create an incoming transport, for ordinarily it is TCP-transport of module Sockets, and select in it the module of the protocol, and also configure although one endpoint node of the protocol module, about it bellow.

2.1. Service of requests on the OPC-UA protocol

Incoming requests to the module-protocol are processed by the module in accordance with configured endpoint nodes of OPC-UA (EndPoints) (Fig. 1).

Endpoint nodes of the protocol. (62 Kb)
Fig.1. Endpoint nodes of the protocol.


The endpoint node of the OPC-UA protocol is actually the server object of OPC-UA. Endpoint nodes in OPC-UA can be either local or remote. The local one is designed to provide resources of OpenSCADA station to protocol OPC-UA, while the remote endpoint nodes are both for the service and review of available OPC-UA units, and to forwarding of the requests to remote stations. In this version of the module is only supported the configuration of the local endpoint nodes.

General configuration of the endpoint node is made on the main tab of the endpoint node's page (Fig. 2) with parameters:

Main tab of the endpoint node's page. (129 Kb)
Fig.2. Main tab of the endpoint node's page.

3. Module of the data acquisition

The data acquisition module provides ability of acquisition and writing the value's attributes (13) of points with the "Variable" type.

3.1. Data controller's object

To append the OPC-UA data source the controller's object into the OpenSCADA system is created and configured. An example of the configuration tab of the controller's object is shown in Figure 3.

Controller's object configuration tab. (129 Kb)
Fig.3. Controller's object configuration tab.


From this tab you can set:
 (2 Kb) Often there meets a situation when the refined address is symbolic which does not resolve into the network by the server incorrect configuration. In this cases you need to keep the original IP-address or the name which resolved to the correct IP.

To facilitate the identification of nodes on the remote station, as well as their choice to be inserted in the parameter of the controller in the controller's object it is provided the navigation on the remote station's nodes tab, where you can walk through the tree of objects and familiar with their attributes (Figure 4).

The "Server nodes browser" tab of the controller's object page. (117 Kb)
Fig.4. The "Server nodes browser" tab of the controller's object page.

3.2. Parameters

The data acquisition module provides only one type of parameters — "Standard". Additional configuration field of the parameter of the module (Fig. 5) is the list of OPC-UA nodes and the field of navigation by OPC-UA nodes in single line, for the selected nodes of type "Variable" insertion to the defined list. Attribute in this list is written as follows: {ns}:{id}.
Where:
ns — name space, number; zero value can be omitted;
id — node identifier by number, string, bytes string and GUID.
Examples:
84 — root directory;
3:"BasicDevices2" — basic devices node in the name space 3 and the string view;
4:"61626364" — node in the names space 4 and the byte string view;
4:{40d95ab0-50d6-46d3-bffd-f55639b853d4} — node in the names space 4 and the GUID view.

Configuration tab of the parameter's object. (97 Kb)
Fig.5. Configuration tab of the parameter's object.


 (2 Kb) Nodes in type "Variable" with the value view as a structure are impossible typically to read entirely then you need it's elements insert separately to the reading nodes list.

In accordance with the specified list of nodes performs acquisition and creation of the parameter's attributes (Fig. 6).

The parameter's attributes tab. (72 Kb)
Fig.6. The parameter's attributes tab.

4. libOPC_UA library

Grounding on workouts of the module the protocol OPC-UA code was moved to different library and published on the LGPLv3 license. That was done to provide possibility of easy appending of support the OPC-UA protocol by external projects. The library represents by two files libOPC_UA.h, libOPC_UA.cpp; supported and hosted into the module content, then it's last version you can get here: http://oscada.org/svn/trunk/OpenSCADA/src/moduls/daq/OPC_UA/libOPC_UA.

The library, like this module code, wrote on C++ programming language. Statical classes diagram which represents the library architecture shown on Figure 7. According to the classes diagram the library implemented into the name space "OPC" and architecturally it can be divided to client "Client" and server "Server" parts which inherited from common class "UA". Besides the direct classes of the protocol "OPC-UA" the library includes to self a set of functions and classes for processing or storing the protocol data, specialty from which it should be noted class of a node of language XML "XML_N" used for requests to the library API unification.

Ńņąņč÷åńźą’ äčąćšąģģą źėąńńīā įčįėčīņåźč libOPC_UA. (42 Kb)
Fig.7. Statical class diagram of the library libOPC_UA.


The library using at all lies in inheriting of the class "Client" and/or "Server", according to the end-program functions, and next implementing of the virtual function for the client/server properties, into the OPC-UA protocol context and the transport communication part, that is connect/open a TCP-socket and write/read of unstructured data stream. Next requests and the requested data processing (for server) performed through the function call reqService(), request to a service, and/or processing of the virtual function reqData() of a data requesting then in fact there is integration to the data model of the application.

4.1. Service objects, functions and the class UA

Data

Implementations types (enum — SerializerType):

Open secure channel request's type (enum — SC_ReqTP):

Security mode of message (enum — MessageSecurityMode):

Type of authentication (enum — AuthTp):

Node classes (enum — NodeClasses):

Browse direction (enum — BrowseDirection):

Time stamp to return (enum — TimestampsToReturn):

Access (enum — Access):

References description result mask (enum — RefDscrResMask):

Identificators of attribute of node (enum — AttrIds):

Subscription stats (enum — SubScrSt):

Monitoring modes (enum — MonitoringMode):

External functions

To the library included range of external functions of the object TSYS of OpenSCADA core to make simply and unified of the internal operations range:

Automatic POSIX mutex unlock object for OPC (OPCAlloc)

The mutex management object is a copy of the "MtxAlloc" object of core OpenSCADA.

Public methods:

Error of OPC (OPCError)

The error object "OPCError" is a trimmed copy of the "TError" object of core OpenSCADA.

Public methods:

Public attributes:

XML-tag (XML_N)

The object "XML_N" is trimmed copy of the object API#h921-2 of OpenSCADA core.

Public methods:

Node's object of OPC-UA (NodeId)

Data:
Data types (enum — NodeId::Type):

Public methods:

Root object of the OPC-UA protocol (UA)

Public methods:
Security parameters included object (SecuritySetting)
Public data:

Public methods:

4.2. Client's main object (Client->UA)

Application: Direct inheritance by a user object — OPC-UA client.

Public methods:

Protected attributes:

Client's session included object (SClntSess)

Public data:

Public methods:

4.3. Server's main object (Server->UA)

Application: Direct inheritance by a user object — OPC-UA server.

Public methods:

Protected methods:

Security channel included object (SecCnl)

Public methods:

Public attributes:

Session included object (Sess)

Public methods:

Public attributes:
Browse's continuation point included object (ContPoint)
Public methods:

Public attributes:

Subscription included object (Subscr)

Public methods:

Public attributes:
Monitored item included object (MonitItem)
Public methods:
Value element included object (Val)
Public methods:

Ļóįėč÷ķūå ąņščįóņū:

Endpoint included object (EP)

Public methods:

Protected methods:

Protected attributes:

5. Private keys and certificates

For the client and server parts of OPC-UA working you need to create and to place the private key and the certificate into configuration of client or server object. In general be enough to create an ordinal selfsigned certificate and a private key without password, but for exclude warning messages you need to add range of service fields to to the certificate. That you can do taking the file of configuration of the certificate creation and executing next procedure:

6. Notes

During implementation of the modules of supporting OPC-UA was detected several inconsistencies with the official SDK specification OPC-UA:

7. Appending: Table of compatibility of implementations of OPC-UA from other developers


Software Core Browse Read Write Publish Notes
OpenSCADA parts
OpenSCADA OPC-UA Client (libOPC_UA client part) + + + + - IO requests by XML implemented: HEL (HELLO), OPN (OpenSecureChannel), CLO (CloseSecureChannel), FindServers, GetEndpoints, CreateSession, ActivateSession, CloseSession, Read, Write, Browse
OpenSCADA OPC-UA Server (libOPC_UA server part) + + + + + The requests implemented: HELF, OPNF, CLOF, MSGF: FindServers, GetEndpoints, CreateSession, ActivateSession, CloseSession, CreateSubscription, ModifySubscription, DeleteSubscriptions, MonitoredItems, ModifyMonitoredItems, SetMonitoringMode, DeleteMonitoredItems, SetPublishingMode, TranslateBrowsePathsToNodeIds, RegisterNodes, UnregisterNodes, Browse, BrowseNext, Read, Write, Publish, Republish. Chunks implemented.
Clients
UAExpert 1.2, 1.3 Pass Pass Pass Pass Pass
Indusoft web studio 7.1 Pass Pass Pass Pass Pass
Iconics genesis64 10.8 Pass Pass Pass Pass Pass
Insat masterscada 3.7 Pass Pass Pass Pass Pass
Sample Applications of Unified Architecture Pass Pass Pass Not tested Pass
Wonderware System Platform Pass Pass Pass Not tested Pass Result mask processing fix into the service "Browse" for nodes of OpenSCADA data model. ...
Kepware Pass Pass Pass Pass Pass Specific value types OpcUa_IntAuto and OpcUa_UIntAuto was added for adaptive integer type selection, mostly for provide integer not fixed as int64. Time stamp was removed from "Write" package but the client tell 0x80730000(OpcUa_BadWriteNotSupported)
UAExpert 1.4 Pass Pass Pass Pass Pass Packages sequence number split from it's request and set self managing.
Servers
IgnitionOPC_UA Pass Pass Pass Not tested NA
B&R Embedded OPC-UA Server Pass Pass Pass Not tested NA The authenticate process fixed by the server provides self specific identifiers to its. The string of bytes wrong interpretation fixed.

Links

Referring pages: HomePageEn/Doc
HomePageEn/Function
HomePageEn/Using/APIFunctionLibs/LibUserPrtDevs
HomePageEn/Works/RoadMap