OpenSCADA

Modules/OPC UA

English • ‎mRussian • ‎Українська
Module Name Version License Source Languages Platforms Type Author
OPC_UA Client OPC-UA 2.8 GPL2 daq_OPC_UA.so en,uk,ru,de x86,x86_64,ARM DAQ Roman Savochenko
  Maxim Lysenko (2010) — the page initial translation
Description
Provides OPC-UA client service implementation.
OPC_UA Server OPC-UA 2.2 GPL2 daq_OPC_UA.so en,uk,ru,de x86,x86_64,ARM Protocol Roman Savochenko
  Maxim Lysenko (2010) — the page initial translation
Description
Provides OPC-UA server service implementation.
OPC_UA Library of implementing OPC-UA into OpenSCADA 2.2 LGPL3 libOPC_UA.{h,cpp} en x86,x86_64,ARM Library Roman Savochenko
Description
Provides the protocol OPC-UA implementing into parts of client and server, as a separated library.
- resolve the controversy in Client::messIO() about mixing the pure requesting mode with the free read/write mode and the time of waiting responses here without passing the connection timeout directly;
- append the authentication support for the input-server protocol part;
- append the automatic creation for input transports and their pre-configuration from the EndPoint object properties;
+ implement the request-service "Publish" and chunks in the client part;
- observe deeply the Publish service for the packages loss and the Republish request sending;
- append for support of the history services of the server part, seeing and testing against UAExpert negotiation;
- append for support of the history services of the client part.

OPC (OLE for Process Control) — it is the family of protocols and technologies what 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 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 of 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 implementation of other OPC-UA services by the need.

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 any 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 the symmetric encryption algorithms and keys for them do not allowed to make the implementation of support for the security policies 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 the same "UAExpert" client, as the OPC-UA specification implementing, its 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 different developers you can get in the table of compatibility.

Contents

1 The OPC-UA protocol

OPC-UA — it is a 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 an 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 appends the support for multiple connections between nodes instead of simple hierarchy. Such flexibility, in combination with type definition, allows to use OPC-UA for solving problems in the wide problem area.

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

OPC-UA is designed to support wide range of servers, from simple PLC to industrial servers. These servers are characterized by 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: UA Binary and XML/text. Additionally, the two types of transport layer are defined: TCP and HTTP/SOAP.

OPC-UA is designed as a 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 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 the services.

2 Module of the protocol implementation

The server module contains an implementation code for the server part of OPC-UA — server services (Fig.1), 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 input transport, for ordinarily it is TCP-transport of the module Sockets, and select in it the module of the protocol, and also configure although one endpoint node of the protocol module, about it see bellow.

Fig.1. The "Server" common state.

The common state of the Server contains only the list of the active secure channels.

2.1 Service of requests on the OPC-UA protocol

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

Fig.2. Endpoint nodes of the protocol.

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. Local ones are designed to provide resources of OpenSCADA station by the protocol OPC-UA, while 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.3) with parameters:

At.png Hidden in the enabled state.
Fig.3. 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 in the direct acquisition mode by the request "Read" and the asynchronous service request "Publish".

3.1 Controller object

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

Fig.4. Configuration tab of the OPC-UA controller object.

From this tab you can set:

At.png Manual restart of the enabled controller object causes the force reformation of the monitored items list.
At.png 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.
At.png Hidden in the running state.
At.png This mode also prevents for loss the writing data at the connection loss and the wrote data will be transmitted just the connection will be restored.

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 tab "Server nodes browser" of navigation on the remote station's nodes, where you can walk through the tree of objects and familiar with their attributes (Fig.5).

Fig.5. The "Server nodes browser" tab of the OPC-UA controller object page.

3.2 Parameters

The data acquisition module provides two types of parameter: "Standard (_Prm)" and "Logical (_PrmL)". Additional configuration fields of the parameters of this module are:

3.2.1 Standard (_Prm)

Additional configuration field of the type parameter (Fig.6) is the list of OPC-UA nodes and the field of navigation by OPC-UA nodes in single line, for the selected nodes of the type "Variable" insertion to the defined list. Attribute in this list is written as "{ns}:{id}[|[{flg}][|{id}[|{name}]]]".
Where:

Examples:

84 — root directory;
3:"BasicDevices2"||var — basic devices node in the name space 3 and the string view with the force attribute ID;
4:"61626364"||var|Variable — node in the names space 4 and the byte string view with the force attribute ID and name;
4:{40d95ab0-50d6-46d3-bffd-f55639b853d4}|irw|var|Variable — node in the names space 4 and the GUID view with no requesting the server metadata for RW Integer and the force attribute ID and name.
Fig.6. Configuration tab of the OPC-UA parameter object.

At.png 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 there performs acquisition and creation of the parameter's attributes (Fig.7).

Fig.7. Tab of attributes of the parameter.

3.2.2 Logical (_PrmL)

Main page of configuration parameters of the logical type is shown in Figure 8.

Рис.8. Configuration tab of the logical parameter type.

Link value, when configuring the template (Fig.9), is written in the form "{ns}:{id}".
Where:

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.
Рис.9. Tab "Template configuration" of the logical parameter type.

The module provides a special processing of a number of attributes of the template:

In accordance with the template, underlying the parameter, we obtain a set of attributes of the parameter (Fig. 10).

Fig.10. Tab of attributes of the logical parameter type.

3.3 User programming API

Due to the support of the logical type parameters, it makes sense to provide a number of functions of the user API for calling them from the template of the logical parameter.

The object "Parameter" [this]


4 libOPC_UA library

Grounding on workouts of the module, the protocol OPC-UA code was moved to a different library and published on the LGPLv3 license. That was done to provide the 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 its actual version you can get here: http://oscada.org/svn/trunk/OpenSCADA/src/moduls/daq/OPC_UA/libOPC_UA.

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

Fig.11. Static class diagram of the library libOPC_UA.

The library using at all lies in inheriting of the class "Client" and/or "Server" accordingly to the end-program functions and next implementing of the virtual functions for the client/server properties into the OPC-UA protocol context, and the transport communication part also, 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 call the function of requesting to the service reqService() and/or processing of the virtual function of the data requesting reqData() than, in fact, there is integration to the data model of the application.

After appending to the client for support of the asynchronous data polling by the service "Publish", the integration process was supplemented by periodic call for the Client::poll() function in order to process the asynchronous service. The "Client::poll()" function is also provided with support for synchronous operation, by a separate argument, through the unified subscription-registering infrastructure of monitoring elements, but the "Read" function. That is, now it is enough to register all the elements of monitoring with the function Client::Subscr::monitoredItemAdd() and then call the function Client::poll() to get their data in the desired mode.

After the last refactoring of the code in version 2, the integration of the server part additionally requires a mandatory start of a separate thread of all subscriptions processing, with call from it for the function Server::EP::subScrCycle() and the argument of the subscription processing cycle counter — the periodicity of the call Server::EP::subscrProcPer().

4.1 Service objects, functions and the class UA

4.1.1 Data

Implementation types (enum — SerializerType):

Open secure channel request types (enum — SC_ReqTP):

Security mode of the messages (enum — MessageSecurityMode):

Types of the authentication (enum — AuthTp):

Node classes (enum — NodeClasses):

Browse directions (enum — BrowseDirection):

Time stamp to return (enum — TimestampsToReturn):

Access (enum — Access):

Items of the description mask of the browsing request (enum — RefDscrResMask):

Attribute identifiers of the node (enum — AttrIds):

Subscription statuses (enum — SubScrSt):

Monitoring modes (enum — MonitoringMode):

4.1.2 External functions

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

4.1.3 Automatic POSIX mutex unlock object for OPC (OPCAlloc)

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

Public methods:

4.1.4 Error of OPC (OPCError)

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

Public methods:

Public attributes:

4.1.5 XML-tag (XML_N)

The object "XML_N" is a trimmed copy of the XMLNode object of the OpenSCADA core.

Public methods:

4.1.6 Node's object of OPC-UA (NodeId)

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

Public methods:

4.1.7 Root object of the OPC-UA protocol (UA)

Public methods:

4.1.7.1 Included object of the security parameters (SecuritySetting)

Public data:

Public methods:

4.2 Main object of the Client (Client->UA)

Application: Directly inheritance by a user object — OPC-UA Client.

Public methods:

At.png The mixed mode of requesting and free reading/writing is resolving still.

Protected attributes:

4.2.1 Complex Client session (Client::SClntSess)

Public data:

Public methods:

4.2.1.1 Client Subscription (Client::Subscr)

Public data:

Public methods:

4.2.1.1.1 Monitored Item of the Client Subscription (Client::Subscr::MonitItem)

Public data:

Public methods:

4.3 Main object of the Server (Server->UA)

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

Public methods:

Protected methods:

Protected attributes:

4.3.1 Server Security Channel (Server::SecCnl)

Public methods:

Public attributes:

4.3.2 Server Session (Server::Sess)

Public methods:

Public attributes:

4.3.2.1 Browse continuation point of the Server Session (Server::Sess::ContPoint)

Public methods:

Public attributes:

4.3.3 Server Subscription (Server::Subscr)

Public methods:

Public attributes:

4.3.3.1 Monitored Item of the Server Subscription (Server::Subscr::MonitItem)

Public methods:

4.3.3.1.1 Value element of the Monitored Item of the Server Subscription (Server::Subscr::MonitItem::Val)

Public methods:

Public attributes:

4.3.4 Server End Point (Server::EP)

Public methods:

Protected methods:

Protected attributes:

5 Private keys and certificates

For the client and server-protocol 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, there will 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 the certificate. That you can do taking the file of configuration of the certificate creation and executing next procedure:

# Private key creation:
openssl genrsa -out key_c.pem -des3 -rand /var/log/messages 2048
# Private key without the password creation:
openssl rsa -in key_c.pem -out key_c1.pem
# Selfsigned certificate creation:
openssl req -x509 -new -key key_c.pem -out cert_c.pem -config ./OPC-UA_openssl.cnf -days 3650
# Files content placing, for the file key_c1.pem to the field of private key and the file cert_c.pem to the certificate field!

6 Notes

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

7 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, CreateSubscription, DeleteSubscriptions, CreateMonitoredItems, DeleteMonitoredItems, Publish, Poll (the special empty request of checking the input channel). Chunks implemented.
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 request and set self managing.
UAExpert 1.5 Pass Pass Pass Pass Pass The Server code cleaned from inconsistency of the data types and the types appended for declaration own OpenSCADA types OpcUa_IntAuto and OpcUa_UIntAuto.
Servers
IgnitionOPC_UA Pass Pass Pass Not tested Not tested
B&R Embedded OPC-UA Server Pass Pass Pass Pass Pass
  • the authenticate process fixed by the server provides self specific identifiers to its. The string of bytes wrong interpretation fixed;
  • 2021.05: has limits on direct reading by the service request "Read", so that was an initiator of implementing the service request "Publish" and Chunks for the Client part, UAExpert 1.5 adaption, significant refactoring and the document complete revision.


8 Links

Modules/OPC_UA/en - GFDLMarch 2024OpenSCADA 0.9.7