Hinweise und Einschränkungen

Allgemein

Anzahl der verbundenen Clients

Die Anzahl der Clients, die zum WinCC OA OPC UA Server verbunden sind, wird nicht immer richtig ausgegeben. Der Grund dafür ist, dass man am Server nur das Ende einer Session ermitteln kann und nicht das Ende der Verbindung. Das Ende einer Session kann bis zu 20 Minuten nach einer Verbindungsunterbrechung erst gesendet werden.

Die maximale Anzahl an verbundenen OPC UA Clients ist beschränkt auf 50. Diese Einschränkung besteht durch einen fixen Wert innerhalb des OPC UA SDKs und kann dementsprechend nicht innerhalb von WinCC OA angepasst werden.

Secure Conversation

Für den WinCC OA OPC UA Client und WinCC OA OPC UA Server wurde ausschließlich UA Secure Conversation implementiert. Die Umsetzung von WS Secure Conversation wird derzeitig nicht unterstützt.

Zeichenkodierung

Wenn Zeichenketten in Datenpunktelementen am Server oder Client angegeben werden und diese Umlaute oder Sonderzeichen enthalten, dann werden diese von der Kodierung WinCC OA ISO 88591 zu OPC UA UTF-8 konvertiert, sodass diese auch richtig dargestellt werden. Wenn in WinCC OA ein UTF-8 Zeichen nicht dargestellt werden kann, wird dieses durch '?' ersetzt.

Eingehende Wertänderungen am OPC UA Server

Der WinCC OA OPC UA Server gruppiert Wertänderungen bzw. Befehle die von Clients an den Server übermittelt werden. Die maximale Anzahl an Wertänderungen in einer Message, die der Server an den Event-Manager sendet, wird mit dem Config-Eintrag [opcuasrv] maxVcMessageSize definiert.

Adressraum

  • Zugriff auf Adressraum des Servers
  • Der Client kann den Adressraum des Servers nicht ändern.
  • Spiegelung des Adressraumes
  • Eine Spiegelung der Adressraumes zwischen Client und Server wird nicht unterstützt.

Verwendung veralteter OPC UA Sicherheitsrichtlinien

Für die Verwendung von veralteten OPC UA-Sicherheitsrichtlinien (Base128Rsa15, Base256) müssen diese unter Red Hat Enterprise Linux manuell aktiviert werden. Dies erfolgt mit dem Aufruf des nachfolgenden Befehls unter Verwendung von root-Berechtigungen.

update-crypto-policies --set DEFAULT:SHA1
Anmerkung: Bitte beachten Sie, dass diese Änderung einen Neustart erfordert!

Redundanz

Generelle Handhabung der Serverredundanz

Der OPC UA Server setzt die UA Server Objekt ServerRedundancy Variable für einen redundanten Serverbetrieb.

Läuft der UA Server in einem redundanten WinCC OA-System, wird der RedundancySupport auf Hot gesetzt und der redundante UA-Server-URI wird zum ServerUriArray hinzugefügt. .

Der redundante UA-Server-URI kann über den Config-Eintrag [opcuasrv] reduServerInstanceUri gesetzt werden. Wenn der Config-Eintrag nicht gesetzt ist, wird ein Default festgelegt.

Für spezielle Konfigurationen (z.B. connectToRedundantHosts oder eine abgesetzte UA Server Konfiguration) muss die redundante UA Server URI mit dem Config-Eintrag gesetzt werden, da für solche erweiterten Konfigurationen kein Default festgelegt werden kann.

Der Name der redundanten Serverinstanz kann mit dem Config-Eintrag [opcuasrv] reduServerInstanceName gesetzt werden .

Um den redundanten Server in die URL-Ermittlungsliste für die Clients aufzunehmen, kann der Config-Eintrag [opcuasrv] reduServerDiscoveryUrl gesetzt werden.

Doppelte Werte bei einer Redundanzumschaltung

Es kann vorkommen, dass Werte, die vom OPC UA Server empfangen werden, bei einer Redundanzumschaltung doppelt in die Datenbank geschrieben werden. Um dies zu vermeiden, müssen folgende Voraussetzungen erfüllt sein:

  1. Das Lesen von Eingangswerten von einem OPC UA Server erfolgt mithilfe einer Subscription.
  2. In der Subscription muss Zeitstempel von Server oder Quelle gesetzt sein.
  3. Der Config-Eintrag [opcua] autoGQ muss auf 0 oder 1 gesetzt sein.

Möglicher Verlust von Wertänderungen bei redundanten WinCC OA OPC UA Servern

Bei Ausfall des aktiven WinCC OA OPC UA Servers kann es vorkommen, dass Wertänderungen verloren gehen, da der passive Event-Manager zeitverzögert (ca. 10 Sekunden) den Ausfall erkennt, und bis dahin die Wertänderungen vom passiven Event-Manager bereits verworfen wurden.

Um dies zu vermeiden, muss der Config-Eintrag [all sections except general] requestDejaVu = 1 gesetzt werden.

Redundanz: Alarme können nicht quittiert werden

Wenn der OPC UA Client zu einem redundanten WinCC OA System verbunden ist, dann kann er Alarme nicht quittieren, wenn er nur eine Verbindung zum OPC UA Server am passiven System hat. Folgende Lösungsvorschläge werden hierzu geboten:

  • Man starte die beiden Server mit unterschiedlichen Managernummern und connectToRedundantHosts = 1. Damit können beide Server den Alarm quittieren. Der erste wird in dem Fall gewinnen, wenn beide quittieren.
  • Der Client wertet den Serverstatus vom Serverobjekt aus. Dort sieht er, ob der OPC UA Server zum aktiven oder zum passiven Event verbunden ist.

Alarme und Zustände (Alarms&Conditions)

Keine Übertragung von Werten

Bei der Übertragung von Alarmen werden in OPC UA keine Werte mitübertragen. D.h. der Wert wird am Client nicht abgebildet. Der Wert kann zwar mittels einer Daten-Subscription übertragen werden, jedoch muss dies auf ein anderes Datenpunktelement erfolgen als die Abbildung des Alarms.

Quittierungsmodell

In der Alarm&Condition-Spezifikation wird das normale Quittieren um die Bestätigung (Confirm) erweitert. Die Bestätigung passt jedoch nicht in das Alarmmodell von WinCC OA und wird deshalb nicht unterstützt.

Wenn der WinCC OA Client einen Alarm quittiert und der Alarm als "unconfirmed" ("unbestätigt") angezeigt wird, dann führt der Client eine automatische Bestätigung durch.

Gleiche Meldebehandlung am Client und Server

Die parametrierte Meldebehandlung am Client muss jener am Server entsprechen. Ist das nicht der Fall, so kann die Abbildung des Alarmstatusmodells vom Server am Client nicht richtig durchgeführt werden. Im Fall einer Kommunikation von WinCC OA UA Server und WinCC OA UA Client erreicht man dies, indem man die Meldebehandlungen symmetrisch parametriert.

Historical Access

Einschränkung: Nur die unterhalb angeführten Funktionen des OPC UA Standards werden durch den WinCC OA OPC UA Server unterstützt.

Unterstützte OPC UA Facets

Folgende Facets werden unterstützt:

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

Unterstützte OPC UA Nodes

Folgende Nodes werden unterstützt:

  • 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.

Unterstützte Funktionen

Der WinCC OA OPC UA Server unterstützt folgende Funktionen, welche verwendet werden können um historische Werte und historische Ereignisse vom Server abzufragen.

  • 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 u

  • 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.