Notes and Restrictions

General

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.

Redundancy

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:

The reading of input values from an OPC UA server takes place via a subscription.
In the subscription the timestamp from server or source must be set.
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.

Alarms and Conditions (AC)

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.

Historical Access

Restriction: Only the below-mentioned functionality of the OPC UA standard is supported by the WinCC OA OPC UA server.

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.