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
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:
- Das Lesen von Eingangswerten von einem OPC UA Server erfolgt mithilfe einer Subscription.
- In der Subscription muss Zeitstempel von Server oder Quelle gesetzt sein.
- 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
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
.