OPC DA / OPC HDA / OPC UA - Server Dist

Dieses Kapitel beschreibt wie der WinCC OA OPC DA Server,WinCC OA OPC HDA Server bzw. der WinCC OA OPC UA Server mit Hilfe von CNS-Views Daten sowohl vom lokalen System auf dem der Server läuft, als auch von verteilten WinCC OA Systemen bereitstellen kann. Dadurch haben mit dem entsprechenden OPC Server verbundene OPC Clients Zugriff auf Daten von allen verteilten Systemen.

Nachfolgend wird der Begriff WinCC OA OPC Server allgemein sowohl für den OPC DA, OPC HDA als auch den OPC UA Server verwendet, da alle Angaben grundsätzlich für alle Server gültig sind.

Konfiguration

Um Daten in einem verteilten System bereitzustellen müssen die entsprechenden CNS-Views angelegt werden (siehe OPC DA Server CNS, OPC HDA Server CNS bzw. OPC UA Server CNS).

Dem jeweiligen OPC Server kann eine Liste mit CNS-Views (vom lokalen bzw. den abgesetzten Systemen) übergeben werden, womit der Server dann den entsprechenden Adressraum aufbaut. Die Zuweisung der Views zum Server kann per Anlagenmodell-Editor - OPC oder direkt über das entsprechende Datenpunktelement durchgeführt werden.

Weisen Sie die CNS-Views aus der Liste rechts per Drag & Drop dem entsprechenden OPC Server zu. Hier werden nur Views von Systemen angezeigt, die aktuell verbunden sind. Die dem Server zugewiesenen CNS-Views werden am internen Datenpunktelement _OPCPvssServer.Config.CNSViews (OPC / OPC HDA) / _OPCUAPvssServer.Config.CNSView (OPC UA) gespeichert. Der aktuelle Status der CNS-Views wird auf das interne Datenpunktelement _OPCPvssServer.State.CNSViews (OPC / OPC HDA) / _OPCPUAvssServer.State.CNSViews (OPC UA) abgebildet und im Panel über die folgenden Symbole dargestellt:

Icon Status Beschreibung
0 Der Status der CNS-View ist nicht definiert, da der OPC Server nicht läuft. Wenn der Server nicht ordnungsgemäß gestoppt wurde (z.B. wenn der Server durch den KILL Befehl gestoppt wurde), bleibt der zuletzt gesetzte Status bis der OPC Server neu gestartet wird.
1 Das verteilte System ist verbunden und die CNS-View bzw. alle OPC-Elemente der View sind korrekt im Adressraum des Servers. Die Werte aller Elemente im Adressraum stimmen mit den Werten der Datenpunktelemente überein.
2 Das verteilte System ist verbunden und die Delta-Synchronisation läuft. Verbundene OPC-Clients können Daten vom Server abfragen.
3 Das verteilte System ist verbunden und die Voll-Synchronisation läuft. Das bedeutet dass die komplette CNS-View im Server-Adressraum aktualisiert wird. In diesem Fall erhalten die verbundenen OPC-Clients die zuletzt verwendbaren Werte des Servers, die mit OPC-Quality "uncertain, Last Useable Value" gekennzeichnet sind. Sobald eine CNS-View eines systems in diesem Status ist, gilt das auch für alle anderen Views dieses Systems.
4 Das verteilte System ist verbunden, die konfigurierte CNS-View existiert nicht bzw. kann im angegebenen System nicht gefunden werden.
5 Das verteilte System ist nicht verbunden und der Server hat keine Informationen zu den konfigurierten CNS-Views im Adressraum. Sobald die Verbindung zum verteilten System hergestellt wird, führt der OPC-Server eine Voll-Synchronisation für alle Views durch.
6

Das verteilte System ist nicht verbunden, dem Server sind DP Identification und CNS-Views im Adressraum bekannt. Alle Werte des Systems dieser View werden vom OPC DA Server mit OPC-Quality "Uncertain - Last Usable Value" gekennzeichnet. Der OPC HDA Server liefert bei historischen Abfragen eine Fehlermeldung.

Wird die Verbindung zum verteilten System hergestellt, führt der OPC-Server eine Voll- oder Deltasynchronisation durch, abhängig von Config-Eintrag maxUpdateMsgCouint und der Menge an geänderten Daten.

Wird der OPC Server mit useLocalIdentification gestartet, wird der Adressraum mit den geladenen Informationen der proj_path/data/DpMsgTypeContainer.bin und proj_path/data/DpMsgIdentification.bin Dateien erstellt, damit TypContainer und DpIdentification nicht übers Netzwerk gesendet werden müssen.

Sobald der OPC-Server gestartet wird, erstellt er mit Hilfe der ihm zugewiesenen Views automatisch den entsprechenden Adressraum. Werden dem Server CNS-Views zur Laufzeit zugewiesen, so erweitert dieser den Adressraum, ohne dass ein Serverneustart erforderlich ist. Mit dem Server verbundene OPC-Clients können die über die Views bereitgestellten Daten abfragen.

Synchronisation

Änderungen an CNS-Views von verteilten Systemen wie zum Beispiel beim Hinzufügen neuer Knoten oder zugeordneter Datenpunkte werden automatisch synchronisiert und auf den Server-Adressraum abgebildet. Hierbei wird zwischen zwei Synchronisierungstypen unterschieden.

Deltasynchronisation

Während dem Normalbetrieb, d.h. alle verteilten System sind verbunden und die WinCC OA OPC Server laufen, werden Änderungen an den CNS-Views sofort synchronisiert. Wird die Verbindung zum verteilten System unterbrochen, werden Änderungen die während dieser Zeit auftreten bis hin zum definierten maxUpdateMsgCount gepuffert und nach Verbindungswiederherstellung mit dem Adressraum abgeglichen.

Vollsynchronisation

Eine Vollsynchronisation ist erforderlich, wenn im Server-Adressraum mindestens eine komplette CNS-View aktualisiert werden muss. Die komplette View wird mit dem aktuell abgebildeten Modell im Adressraum verglichen und wenn vorhanden werden die Änderungen in den Adressraum übernommen. Das führt zu einer Belastung des OPC-Servers und kann bis zu einigen Minuten dauern. Während dieser Zeit erhalten OPC-Clients keine Werte vom Server.

Diese Synchronisation ist nur erforderlich wenn es zu Änderungen an der DpIdentification eines verteilten Systems gekommen ist. Das betrifft folgende Fällen:

  • Die Verbindung zu einem verteilten System ist unterbrochen und die Änderungen der DpIdentification des verteilten Systems übersteigen den festgelegten Wert von maxUpdateMsgCount.
  • Nach Projektstart bzw. Neustart eines verteilten Systems.
  • Nach Neustart des Dist-Managers eines verteilten Systems. In diesem Fall muss die DpIdentification zwischen den Systemen abgeglichen werden. Sollten keine Abweichungen vorhanden sein, ist die Synchronisation nicht erforderlich.

Redundanz

Der WinCC OA OPC Server stellt auch Werte von redundanten Systemen bereit. Im Falle von Distaster Recovery Systemen werden von beiden redundanten Systemen die gleichen Daten bereitgestellt. Hier muss auf Seiten der OPC-Clients entschieden werden, zu welchem Server welchen Systems die Verbindung hergestellt werden soll.

Verbindungsausfall

OPC Server Allgemein

  • Wird der OPC Server gestartet bevor die Verbindung zu den verteilten Systemen hergestellt ist, werden die Elemente dieser Systeme nicht auf den Adressraum abgebildet. In diesem Fall ist die Vollsynchronisation erforderlich, nachdem die Verbindung der Systeme aufgebaut wird.
  • Durch den Config-Eintrag useLocalIdentification kann der Server-Adressraum auch vom lokalen Bufferfile erstellt werden, auch wenn das verteilte System beim Hochlauf noch nicht verbunden ist. Nach Verbindungsaufbau wird vom OPC-Server eine Deltasynchronisation durchgeführt und das Bufferfile wird nicht mehr benötigt.

OPC DA Server spezifisch

  • Wird die Verbindung zu einem verteilten System verloren, ändert sich die OPC-Quality aller OPC-Elemente dieses Systems auf "Uncertain - Last Usable Value". Dadurch wird angezeigt, dass der aktuell angezeigte Wert unbestimmt ist. Nach Wiederherstellung der Verbindung werden die Quality-Bits automatisch aktualisiert.
  • Wird versucht auf ein Item auf einem nicht erreichbaren verteilten System zu schreiben, wird ein Fehlercode ausgegeben, da das Ziel nicht erreicht werden kann. Der Client muss den Wert also erneut schreiben, nachdem das System wieder erreicht werden kann.

OPC HDA Server spezifisch

  • Wird die Verbindung zu einem verteilten System verloren, liefert eine historische Abfrage auf dieses System eine Fehlermeldung zurück.

OPC UA Server spezifisch

  • Wird die Verbindung zu einem verteilten System verloren, ändert sich die OPC-Quality aller OPC-Elemente dieses Systems auf "Uncertain - Last Usable Value". Dadurch wird angezeigt, dass der aktuell angezeigte Wert unbestimmt ist. Nach Wiederherstellung der Verbindung werden die Quality-Bits automatisch aktualisiert.
  • Wird versucht auf ein Item auf einem nicht erreichbaren verteilten System zu schreiben, wird ein Fehlercode ausgegeben, da das Ziel nicht erreicht werden kann. Der Client muss den Wert also erneut schreiben, nachdem das System wieder erreicht werden kann.
  • Nur die Alarme des eigenen Systems werden bei der Verwendung von verteilten Systemen unterstützt.
  • Wird die Verbindung zu einem verteilten System verloren, liefert eine historische Abfrage auf dieses System eine Fehlermeldung zurück.