Contents

Chapter 1
Introduction

1.1 OPC UA

OPC UA is an open communication protocol for industrial automation. Unlike legacy OPC, OPC UA is a multi-platform protocol, it may work as a web service and it offers many advanced functions like diagnostics, method calls and various levels of security and authentication in addition to standard events and data access. OPC UA is becoming a preferred communication interface of many devices from various companies.

However, OPC UA is not a suitable protocol for hard real-time communication between control devices, but is sufficient for soft real-time applications in many cases. A main utilization areas of OPC UA are human-machine interfaces and interconnection of various devices in a heterogeneous environment.

1.2 OPC UA server for REXYGEN

OPC UA server for REXYGEN is as standalone application that is connected to a REXYGEN runtime utilizing a low-level diagnostic protocol. It is not required to run the OPC UA server on the same station where the REXYGEN runtime is running. However, it is advised to run the OPC UA server as close to the REXYGEN runtime as possible to minimize latencies. The OPC UA server for REXYGEN implements the opc.tcp communication protocol, that is the most common protocol for OPC UA servers that acquire data from real-time control devices. The connection of OPC UA with client applications is shown on figure 1.1.

The OPC UA server for REXYGEN obtains the licensing information directly from the connected REXYGEN runtime. The OPC UA server itself operates unlimited. However, if an executive is too large (i.e. contains too many variables), then the OPC UA server refuses to display it. In such a case, a higher OPC UA licence has to be installed on the target REXYGEN runtime.

1.3 Provided functionality

The OPC UA server is connected directly to a REXYGEN runtime core. It shows complete structure of a target algorithm (ie. blocks, variables..) in the address space. The server acquires complete structure of the algorithm during startup and make all runtime variables accessible to clients upon request.

A connection to the target device is maintained and checked periodically. The server tries to reinitialize the connection or reconnect to the target device when the connection is lost or an error occurs. Last acquired values are held and available to clients. Value quality is set appropriately. If the target algorithm is changed, the address space is rebuild appropriately and connected clients are notified.

Chapter 2
Address space

An address space contains all the data that is available to clients. Address space is comprised of nodes. Some nodes are common to all OPC UA servers, other nodes are application-specific. There are also nodes that control the server itself. The "Exec" node is a root node to all runtime-specific variables and the whole structure of a target algorithm (ie. tasks, subsystems, blocks and variables) is available underneath this node. A content of the "Exec" node is rebuilt when a connection with a target is established or a control algorithm is changed on the target. A sample address space is shown on figure 2.1. The picture has been taken from UaExpert OPC UA client (see chapter 7.1).

The server utilizes several name spaces. The first name space corresponds to the application URI and is dedicated for a server diagnostics.

The name space urn:Rex:TypeDeclaration is dedicated for definitions of types that are used among the address space.

The name space urn:Rex:Server is dedicated for commanding the server itself.

A name space that corresponds to the target algorithm is always target-specific and is described in chapter 4.4.2. This name space contains are all nodes that corresponds to the target algorithm.

2.1 Blocks

The structure of address space within the Exec node reflects the structure in a target device that the server is connected to. All nodes are part of the executive name space (see chapter 4.4.2). Node names published in BrowseName and DisplayName correspond to block names in the target device.

There are two distinct objects within the Exec node. The first object is a so-called block. A block represents a task (TaskType), a subsystem (SubsystemType) or a function block (BlockType) on the target device. The second object is a so-called variable. A variable represents a single input, output, state or parameter of a block.

2.2 Variables

Variables are represented by a data type, range and actual value. A range of a data type is stored in the Min and Max nodes. A value is the only node that is constantly synchronized with the target device.

A value of a variable is propagated immediately to the target device upon a write request from a client. However, a cached value may be returned to a client upon a read request if a value age does not exceed specified limit. A maximal age of a value is configured by a SYNC_INTERVAL (see chapter 4.4.1). A variable is also refreshed periodically within this period if a monitoring is established by a client. The process of synchronization is shown on figure 2.2.

A data type of a variable object reflects the data type of a corresponding variable on the target. The names published in BrowseName and DisplayName correspond to the names of corresponding variables in the target device.

Arrays (vector or matrix) are internally divided into small and large arrays. Small arrays are synchronized atomically. Large arrays are synchronized sequentially.

2.3 Events

A version number of a target executive is held internally by the sever. A GeneralModelChangeEvent event is invoked and list of added or removed object is passed on each time a change in the target executive is detected.

Chapter 3
Quick start guide

A configuration file, server’s certificate and a private key (if encryption and authentication are required) are needed to successfully run a server. Following steps have to be done in order to start the server:

1. Install REXYGEN system with the OPC UA server option enabled.
2. Create a configuration file by following these steps:
   1. Copy an example configuration from REXYGEN installation (see chapter 4.5).
   2. Change configuration file appropriately (see chapters 4.3 and 6).
3. Create a certificate if you don’t have one either obtain it by following certificate policy of your company or generate it yourself
   1. Using RexOpcUaConfig (viz kapitolu 6.1)
   2. Using OpenSSL
   3. Using script /etc/rexcore/rexopcua.d/10-cert.sh
      • -i <IP_ADDRESS> – External IP address of the OPC UA server
      • -d <DNS> – External DNS of the OPC UA server
      • -f – Force regenerate certificate
      • -k – Force regenerate private key
4. Set-up user accounts either directly or by using RexOpcUaConfig (see chapter 6).
5. Set client certificate options if any of configured endpoint uses client certificates:
   1. Create certificate directories (by RexOpcUaConfig, see 6.1).
   2. Copy trusted client certificates into the folder specified by the CERTIFICATE_TRUST_LIST_PATH configuration option.
6. Set discovery options appropriately if a discovery service is requested (see 4.4.6):
   1. Find out information about your discovery server.
   2. Copy discovery server’s certificate into corresponding folder.
   3. Set up configuration option in the DISCOVERY section.
      1. SERVER_URL - Endpoint URL of a discovery server.
      2. SECURITY_POLICY - Security policy used to communicate with discovery server.
      3. SERVER_CERTIFICATE_PATH - A patch to a certificate of a discovery server.
      4. ENDPOINT_URL - Endpoint list that is to be published on a discovery server. A single endpoint should be sufficient to register OPC UA server properly.
7. Run the OPC UA service, see chapter 4.2.

Chapter 4
Startup and configuration

4.1 Startup

The server is configured by a simple configuration file. Its location is specified by the "-c" parameter.

RexOpcUa [-c <configFile>]

Path to the configuration file is set by default in GNU/Linux:

/rex/OpcUa/RexOpcUa.ini

Configuration options are described in chapter 4. The server may also run as a system service – see chapter 4.2). A quick start guide is available in chapter 3.

4.2 System service

The OPC UA server may run as a system service. The system service mode is a default and a recommended mode.

The OPC UA server running as a service may be monitored by a RexTrayMon application that runs in a system tray on Windows platform. (see pictures 4.1, 4.2 a 4.3). It is also possible to start, stop and run configuration utility from RexTrayMon

The OPC UA server runs as a system.d service on a Linux platform. The service may be started from command line using following command:

systemctl start rexopcua

Configuration file path for the server is defined by the CFGFILE option in a service configuration file:

/etc/rexcore/rexopcua.conf

4.3 Configuration

A configuration is stored in a standard INI file format. An UTF-8 encoding is preferred. The content is case-sensitive. There must be no additional space at the start and at the end of a line and around the "=" (equals) symbol. A comment is prefixed by a ";" (semicolon) symbol. A section name is specified within "[]" (square brackets) symbols. Every parameter must have a value. Parameters without values are ignored.

All sections must be identified by a name. A name must be recognized by the server. All recognizable section names are described in following paragraphs. Sections User Token Policy (UTP) Endpoint and Target may have subsections. A single corresponding endpoint or connection is created for every single subsection.

Configuration parameters are described in following paragraphs. Parameters that have a default value are optional. Parameter values may have string, number, arrays or boolean types. A number is always an integer. A boolean value is either Y, YES, ON for logical true or N, NO, OFF for logical false. An array is a set of several values within "[]" (square brackets) symbols divided by a "," (comma) symbol. An empty array is considered as a no value. A file path is a system path to the file. It is either absolute system path or relative to the configuration file.

4.4 Configuration sections

All supported section names of a configuration file are described in following paragraphs.

4.4.1 Target

This section contains options that affect a communication link established with a target device. Details are described in the table 4.1. There is a corresponding Exec node build for every single TARGET identified by a name defined by TARGET:Exec1.

Usage of Parameters ADD_WHITE_LIST and ADD_BLACK_LIST

When using ADD_WHITE_LIST and ADD_BLACK_LIST, the rules also apply to child nodes (blocks, variables) of the target node unless otherwise specified. Rules can be defined either as arrays or as individual text strings. Previously added rules are not discarded but are extended.

Example of Rule Definition:

ADD_WHITE_LIST=[$.task1,$.task2] 
ADD_WHITE_LIST=[$.task3] 
ADD_WHITE_LIST=$.task4

This setup introduces four rules, which are evaluated simultaneously.

Rules with Quantifiers

• If a rule name does not contain a colon, it applies to the node and all its child nodes (inputs, outputs, subsystems, blocks, etc.).
• Rules with a colon after the node name apply only to the inputs, outputs, parameters, states, and arrays of the node (not to its child nodes).
• Additional quantifiers can be added after the colon for filtering:
  • I – Node inputs
  • O – Node outputs
  • P – Node parameters
  • S – Node states
  • A – Node arrays

Example of Equivalent Rules: The following two definitions have the same meaning:

ADD_WHITE_LIST=$.task4: 
ADD_WHITE_LIST=$.task4:IOPSA

Behaviour of the Blacklist

If a node is included in the blacklist, neither it nor its child nodes will be displayed in OPC UA. An exception occurs when one of its child nodes (or their inputs, outputs, parameters, states, arrays) is in the whitelist. In this case, the parent nodes will appear as "bare" to ensure the OPC UA structure remains consistent.

Note: If a node in the whitelist does not exist on the target device, its parent nodes will still appear because the rules are based on the configuration rather than the actual executive structure.

Tree Structure of Rules

The ADD_WHITE_LIST and ADD_BLACK_LIST rules form a tree structure. Each rule name is split by dots (quantifiers prefixed with a colon are not considered at this stage). If the names differ at certain levels, a new branch is created. It is also possible to use an asterisk (*) instead of a specific level, which acts as a fallback at that level.
Rule Visualisation:
For the following rule names:

$.task3 
$.task3.sub2 
$.task4.sub2 
$.task4.sub3: 
$.task4.∗ 
$.∗.∗.block1

The following rule tree is created, where the underlined nodes represent tree nodes with specific rules:

$ 
+$-$$-$ task3 
|   +$-$$-$ sub2 
+$-$$-$ task4 
|   +$-$$-$ sub2 
|   +$-$$-$ sub3 
|   +$-$$-$ * 
+$-$$-$ ∗ 
    +$-$$-$ ∗ 
        +$-$$-$ block1

When utilising WHITE_LIST a BLACK_LIST, the selected rule is also applied for child nodes (blocks, variables). A rule which is closest to a particular node is applied. If a node is explicitly mirrored then its ancestors (block, subsystem, task) are also created for organizational purposes. Examples of rules by priority (starting with the lowest priority):

• $ – the entire executive
• $.task1 – applies to task1, its variables, and its nested subsystems/blocks
• $.task1: – applies only to the variables of task1
• $.task1.subsystem2 – applies to subsystem2, its variables, and its nested subsystems/blocks
• $.task1.subsystem2: – applies only to the variables of subsystem2
• $.task1.subsystem2.block3 – applies to block3 and its variables
• $.task1.subsystem2.block3: – applies only to the variables of block3
• $.task1.subsystem2.block3.param4 – applies to the variable param4

Searching in Rules

The following rules apply when searching the rule tree:

1. At each level, specific rules are searched for.
2. If no specific rules are found, fallback rules marked with an asterisk (*) are used.
3. If no rule is found, the algorithm moves up one level (to the left).

Example:

• For $.task3, the rules $.task3 are used - they exist and are the most specific.
• For $.task3.sub1, the rules $.task3 are used - they exist and are the most specific.
• For $.task3.sub2, the rules $.task3.sub2 are used - they exist and are the most specific.
• For $.task4, no rules exist - $.task4 has no rules, $.* has no rules, and $ has no rules.
• For $.task4.sub1, the rules $.task4.* are used - $.task4.sub1 has no rules, but $.task4.* exists and is the most specific.
• For $.task4.sub2, the rules $.task4.sub2 are used - they exist and are the most specific.
• For $.task4.sub2.block1, the rules $.task4.sub2 are used - they exist and are the most specific.
• For $.task4.sub3, the rules $.task4.sub3 are used - they exist and are the most specific.
• For $.task5, no rules exist - $.task5, $.*, and $ have no rules.
• For $.task5.sub1, no rules exist - $.task5.sub1, $.task5, $.*.sub1, $.*.*, and $ have no rules.
• For $.task5.sub1.block1, the rules $.*.*.block1 are used - $.task5, $.*.sub1, and $.*.* have no rules, but $.*.*.block1 exists and is the most specific.

Note: The rules $.*.*.block1 do not apply to $.task3.sub1.block1, as the rules $.task3 are found first. Caution: Exceptions to rules require explicit definition. For example, a rule $.*.sub1.* can have an exception defined as $.*.sub1.*.variable1. Similarly, a rule $.task4.sub1.* can have an exception defined as $.task4.sub1.*.variable1.

4.4.2 Application

The Application section contains main configuration options, see the table 4.3. Both the executive and server name space is configured in the Application section. The server name space is configured by a APPLICATION_URI parameter. The executive name space configuration has the following form:
urn:Rex:Exec:<COMPANY_URI_NAME>:<PROJECT_URI_NAME>[:<INSTANCE_URI_NAME>]: <TARGET_NAME>

Parameters COMPANY_URI_NAME, PROJECT_URI_NAME and INSTANCE_URI_NAME should be unique for each target device. Multiple OPC UA servers that are connected to the same target device should have these parameters set to the same value. The TARGET_NAME parameter matches the subsection TARGET (see the table 4.4.1).

4.4.3 Security

The Security section contains configuration of clients certificates ie. validation options and locations. The section is relevant only when any of the configured endpoints has security options set.

Certificates and their storage should comply with the OPC UA standard (see https://reference.opcfoundation.org/GDS/v105/docs/F.1). The RexOpcUaConfig configuration tool from the REXYGEN installation may be used to create a server certificate and directories for client certificates.

4.4.4 User Token Policy (UTP)

User Token Policy (UTP) sections define allowed authentication and authorization methods. The options are described in the table 4.5. Modification of user accounts and roles is described in chapters 5 and 6.2.

An authentication policy is specified by a client during connection handshake. No credentials are required within an anonymous connection. Otherwise a valid user name and password and/or valid and trustworthy certificate has to be supplied by a client. A certificate validation can be configured in the same way as a certificate validation for secured connection (see table 4.4).

A list of supported authentication policies has to be defined for every endpoint by the option USER_TOKEN_POLICY. An endpoint may support multiple anonymous policies. A client selects a required policy.

A configuration file with user roles, accounts and encrypted passwords has to be provided for username UTP. An optional parameter OPTIONAL_ENCODING_SALT defines an encoding salt of user passwords in the configuration file.

4.4.5 Endpoint

The Endpoint section contains configuration of OPC UA endpoints that are available for clients. Each subsection in the Endpoint defines a single endpoint and must therefore contain all required configuration options. All configuration options are described in table 4.6.

If it is necessary to use an endpoint for Discovery services, we recommend not using localhost in its URL, but instead a public IP address or DNS name. Otherwise, depending on the implementation of the client and the Discovery server, the client may attempt to access localhost on its own machine rather than on the intended server.

The URL should follow this format:

• for opc.tcp:
  opc.tcp://<IP address | DNS>:<port>[/<endpoint>]
• for opc.https:
  opc.https://<IP address | DNS>:<port>[/<endpoint>]

When using the opc.https protocol, it is necessary to properly configure the certificate folders — in the same way as for signing and encryption with opc.tcp. Since the OPC UA server uses standard HTTPS encryption mechanisms, the SignEncrypt options listed in Table 4.7 are not supported. The default port for opc.https is 443.

If the security mode None is selected, client certificates are not validated — not even against the trusted certificates folder. To re-enable this validation, any Sign security mode must be selected.

4.4.6 Discovery

This section describes the configuration for registering with a Discovery server. The entire section is optional. The ENDPOINT_URL parameter may contain multiple endpoints intended to be registered, but it is recommended to specify only a single address. Other endpoints should be discoverable by a client through the specified one. The ENDPOINT_URL should correspond to an actual server endpoint, but this is not verified.

To register successfully, a valid discovery server URL must be provided and the path to the discovery server’s certificate via SERVER_CERTIFICATE_PATH. The discovery server must trust the OPC UA server’s application certificate. Configuration parameters are listed in Table 4.8.

4.4.7 Options

The Options section contains all other parameters that affect server’s behavior. These parameters should be modified only with detailed knowledge of OPC UA specification. All parameters in this section are optional and are described in table 4.9 and 4.10. All interval values are in milliseconds.

4.5 Configuration templates

Several configuration templates are provided to make it easier to configure a new instance of the OPC UA server. These configurations may be used as a quick start templates for arbitrary configurations. Following configuration templates are provided:

• Minimal - a minimal configuration with and unsecured endpoint and a running REXYGEN target on localhost,
• Secured_communication - a configuration for secured endpoints without authentication,
• Username_Authentication - a configuration for secured endpoints and authentication with user name and password,
• Certificate_Authentication - a configuration for secured endpoints and authentication with client certificates,
• Multi_Authentication - a configuration for multiple authentication policies,
• Endpoints - a configuration with two endpoints,
• Discovery - a configuration with registration to a discovery server,
• Full - a complete configuration.

It is recommended to always modify parameters ADDRESS, COMPANY_URI_NAME, PROJECT_URI_NAME and INSTANCE_URI_NAME.

Chapter 5
Authentication and authorization

5.1 Roles and users

Five roles are defined in the OPC UA server: Anonymous, AuthorizedUser Observer, Operator and Supervisor. An AuthorizedUser is allowed to browse address space. An Observer is also allowed to read values of variables and blocks. An Operator has all the permissions as Observer and is also allowed to write values of variables and blocks and thus affect behaviour of a target algorithm. A Supervisor has unlimited permissions including utilisation of communication diagnostics and invocation of server methods. Access permissions are listed in table 5.1.

A role that is applied for a session is determined by a security policy that is applied on an endpoint and during authentication process. A client may only apply policies that are enabled and allowed on an endpoint. Security, authentication and authorization is ensured by a configuration of policies for endpoints, see chapter 4.4.5.

A valid path to a configuration file with roles, users and passwords has to be provided when authentication using user name and password is enabled. The configuration file is loaded during the server startup. Use RexOpcUaConfig tools to modify user accounts. This tool is integral part of REXYGEN installation.

5.2 Credentials INI file

The credentials INI file contains information about uses, their passwords and roles. This file contains five sections corresponding to OPC UA server roles: SUPERVISOR, OPERATOR, OBSERVER, AUTHORIZED_USER, ANONYMOUS. These sections contains pairs of users with encoded passwords. Passwords are encoded by SHA1 encoding of string: <password><username><OPTIONAL_ENCODING_SALT>. An example credential INI file is depicted bellow.

Chapter 6
Configuration Tool

RexOpcUaConfig is a graphical configuration tool of the OPC UA server for REXYGEN. It simplifies a process of a server configuration. It provides a certificate generation, ini file modification and administration of user accounts. Several example configurations are provided for beginners.

A whole content of the configuration ini file is shown on the Configuration tab, see picture 6.1). A content may be modified by a user and saved. Configuration is checked for common errors before it is saved. All errors found are listed in the Errors tab.

6.1 Certificates

Administration of server and client certificates is provided on the Certificates tab, see picture 6.2. All file paths are obtained from the configuration file. The configuration file must be present and all file paths must be valid, otherwise the tab is filled with a red color.

Client certificates are stored among various directories. RexOpcUaConfig makes it possible to create, open and delete these directories. Trusted client certificates are stored in the Trusted folder. All certificates of clients that tried to connect to the server and were rejected are stored in the Rejected directory.

A special dialog is provided for certificate creation. The Passsword and Application URI fields are filled by values defined by APPLICATION_PRIVATE_KEY_PASSWORD a APPLICATION_URI configuration options.

The Subject field contains an arbitrary text. The Restriction field contains an IP address or domain that the certificate is bound to. The Application URI must match APPLICATION_URI configuration option. Certificate Settings affect certificate’s validity and used cipher.

The location of the generated certificate and key is specified in the configuration INI file and can be seen under the Certificates tab (Figure 6.2). The key file (.key, .pem) is stored in PEM format. The certificate is generated in DER format.

6.2 Authentication

The Authorization tab (see picture 6.4) contains settings for authentication and authorization. The tab is visible only when the CREDENTIALS_INI_PATH is set and valid. All user accounts are stored in this configuration file.

There is a simple graphical interface for creation of a user account (picture 6.5), modification (picture 6.6) and deletion.

6.3 Configuration examples

Several simple configuration templates are provided for beginners. (see chapter 4.5). An example configuration may be used as a quick start template for arbitrary configurations (see pictures 6.7, 6.8 and 6.9).

No template of configuration file for user accounts exists and the file must always be created from scratch. Please check, that OPTIONAL_ENCODING_SALT is set appropriately when copying or re-using the configuration file.

Chapter 7
Connection testing with OPC UA clients

Several OPC UA clients that are freely available may be used for testing of the OPC UA server. Their behavior and functionality may differ. UaEpert by Unified Automation GmbH and myScada are shortly introduced in this guide. Both anonymous and authenticated connections are demonstrated (see pictures 7.1, 7.2 and 7.3).

7.1 UaExpert

UaExpert is a universal and a fully functional OPC UA client that may be used for testing and verification of OPC UA connection and for a simple diagnostics. It supports wide range of OPC UA functionality.

UaExpert support three ways of authentication, encrypted connection, discovery service, reading data, writing data, monitoring of nodes, browsing address space, monitoring events, method invocation and more.

UaExpert invokes a certificate creation on a first startup. A generated certificate has to be copied to the server’s trusted certificates directory if an authentication using certificate is requested using option Settings > Manage Certificates > Copy Application Certificate To... (see picture 7.4).

A connection with OPC UA server is established by clicking on "+" button. A dialog for connection configuration is opened. Advanced connection options are set in tab Advanced (see picture 7.5).

An established and working connection is indicated by a connected plug (see picture 7.7). A connection may be closed (unconnected plug) and re-established again. Connection options may be changed only in disconnected state (icon with a key). Authentication policy may be changed at any time (icon with a user). UaExper may have several connections established at the same time. Client configuration (including connections, monitored items etc.) may be saved and later loaded again.

A Data Access View document has to be created by clicking on a document icon, selecting option Data Access View and then clicking on Add (see picture 7.8). To monitor an item simply drag and drop corresponding node from address space to the document (see picture 7.9). A monitoring of the item starts immediately. The item may be deleted at any time. A value may be written to a monitored item by double-clicking on the item in the document and entering new value(see picture 7.10).

A Event View document has to be created by clicking on a document icon, selecting option Event View and then clicking on Add (see picture 7.11). To monitor an item simply drag and drop corresponding node from address space to the Configuration area (see picture 7.12). All monitored events are listed in Events area. Event details are shown in the Details area. It is recommended to always monitor the Exec and the Server nodes of the OPC UA server for REXYGEN.

A simple read operation in UaExpert is performed by clicking on a node in the address space tree view. A value is shown in the right part of the node, see picture 7.13. A write operation is invoked by double-clicking on a node, see picture 7.14.

UaExpert supports a discovery service and shows all available OPC UA endpoints of registered servers (see picture 7.15). A user may expand a requested server in the tree view, select requested operation and set up an authentication policy to establish a connection. UaExper always checks a Local Discovery Server (LDS), a freely available discovery server (see chapter 4.4.6). Another option is to register a custom discovery server or OPC UA server directly.

Inspect application logs that are available in the bottom panel (see picture 7.16) if a problem occurs with a connection.

7.2 myScada

mySCADA is an Human-Machine Interface tool that supports OPC UA. Not all OPC UA options are supported by mySCADA.

First, a new project has to be created in myPROJECT designer. Then open a connection tab, insert a new connection a select OPC UA. A configuration dialog is opened in which a connection with OPC UA is set, see picture 7.17.

A data tag has to be defined in the next step. The tag contains a reference to a single node on OPC UA server that contains the requested value, see picture 7.18. The tag may be then used to show a value in HMI application, see picture 7.19. Download a final project to the device and use myView to show it.

Use myView to show HMI on a device. A proper value is shown and updated from OPC UA server, see picture 7.20. An error is indicated when a connection error occurs, authentication fails or a tag is not valid, see picture 7.25.

An endpoint has to have a /None/None suffix to mySCADA work properly with unencrypted connection. A policy ID for anonymous login must be set to zero, see picture 7.1.

To configure user name and password authentication policy a UserNameIdentityToken policy has to be set (see pictures 7.22 and 7.23) and user name and password must be supplied (see picture 7.24).

An error is indicated when authentication fails, see picture 7.25.

Bibliography

Documentation reference number: 17331

2025 © REX Controls s.r.o., www.rexygen.com