Notes and Restrictions

Number of connected clients

The number of clients connected to the OPC UA server is not always displayed correctly. The reason for this is that it is only possible to determine the end of a session, but not the end of a connection. In same cases the end of a session can be sent up to 20 minutes later after the connection was interrupted.

The total number of connected OPC UA Clients is restricted to 50. This is caused by a fixed value used inside the OPC UA SDK and can therefore not be changed through WinCC OA.

Secure conversation

Only UA Secure Conversation has been implemented for the WinCC OA OPC UA client and server. The conversion of WS Secure Conversation is currently not supported.

Character encoding

If strings in data point elements on the server or client contain umlauts or special characters, they will be converted from the WinCC OA ISO 88591 to OPC UA UTF-8 character encoding so that they are displayed correctly. If a UTF-8 character can not be displayed in WinCC OA it will be replaced with '?'.

OPC UA server - incoming value changes

Value changes or commands received from clients are grouped by the WinCC OA OPC UA server. The maximum number of value changes in a message, which is sent to the Event manager by the server, can be defined with the config entry maxVcMessageSize.

Address space

• Access to the address space of the server
• The client is not able to change the address space of the server.
• Mirroring of the address structure
• A mirroring of the address structure is not supported.

Use of outdated OPC UA security policies

For the use of outdated OPC UA security policies (Base128Rsa15, Base256), these must be activated manually under Red Hat Enterprise Linux. This is done by calling the following command using root-permissions.

update-crypto-policies --set DEFAULT:SHA1

General Redundancy Server Handling

The OPC UA server sets the UA Server object ServerRedundancy variables for a redundant server operation.

If the UA server is running in a redundant WinCC OA system the RedundancySupport is set to Hot and the redundant UA server URI is added to the ServerUriArray.

The redundant UA server URI can be configured using the config entry [opcuasrv] reduServerInstanceUri. If the config entry is not set a default is determined.

For some specific configurations (e.g. connectToRedundant hosts or a remote UA server configuration) the redundant UA server URI must be set with the config entry as no default can be determined for such extended configurations.

The name of the redundant server instance can be set using the config entry [opcuasrv] reduServerInstanceName.

To add the redunant server to the URL discovery list for the clients, the config entry [opcuasrv] reduServerDiscoveryUrl can be set.

Duplicate values during a redundancy switch

It is possible that values that are received from the OPC UA server, are written double into the database during a redundancy switch. To avoid this, the following requirements must be met:

1. The reading of input values from an OPC UA server takes place via a subscription.
2. In the subscription, the timestamp from server or source must be set.
3. The config entry autoGQ must be set to 0 or 1.

Possible loss of value changes in the event of redundant WinCC OA OPC UA servers

In case of a breakdown of the active WinCC OA OPC UA server it may happen that value changes get lost, as the passive Event manager recognizes the breakdown delayed (ca. 10 seconds), and until then the value changes had already been rejected by the passive Event manager.

To avoid this the config entry requestDejaVu = 1 in the [opcuasrv] section has to be set.

Redundancy: Alarms can not be acknowledged

If the OPC UA client is connected to a redundant WinCC OA system, it is not able to acknowledge alarms if it is only connected to the OPC UA server on the passive system. The following solution suggestions are offered:

• Start the both servers with different manager numbers and connectToRedundantHosts = 1. With this, both servers can acknowledge the alarm. In this case, the first one will win if both acknowledge.
• The client evaluates the server status of the server object. There it can detect whether the OPC UA server is connected to the active or to the passive system.

No transfer of values

When transferring alarms, no values are transferred in OPC UA. I.e. the value is not sent on the client. Although the value can be transferred using a data subscription, but this must be done to a different data point element as the mapping of the alarm.

Acknowledge concept

The normal acknowledgement is extended by the confirmation in the Alarms & Conditions specification. The confirmation does not match the WinCC OA alarm concept and thus it is not supported.

If the WinCC OA client acknowledges an alarm and the alarm is shown as "unconfirmed", the client carries out an automatic confirmation.

Same alert handling on client and server

The configured alert handling on the client must match that on the server. If this is not the case, the mapping of the alarm state model to the client can not be carried out properly by the server. In case of a communication of server and client this can be achieved by symmetrical configuration of the alert handlings.

Supported OPC UA facets

The following facest are supported:

• Historical Raw Data Server Facet
• Base Historical Event Server Facet

Supported OPC UA nodes

The following nodes are supported:

• HistoricalDataNode

  This node is used to define whether or not a client can read historical data from the respective element.

• HistoricalEventNode

  Object or View in the AddressSpace where a client can access historical Events.

Supported functions

The following functions are supported, which can be used by OPC UA clients to retrieve raw historical values and historical events from the server.

• readRaw
• readAtTime
• readEvents

Supported History Capabilities

The following capabilities are supported:

• AccessHistoryDataCapability

  Defines if the server supports access to historical data values

• MaxReturnDataValues

  Defines maximum number of values that can be returned by the server for each HistoricalNode accessed during a request

• AccessHistoryEventsCapability

  Defines if the server supports access to historical Events.

• MaxReturnEventValues

  Specifies the maximum number of Events that a server can return for a HistoricalEventNode.