OPC UA-Datenaustausch & -Strukturen

Allgemein

Das Lesen von Eingangswerten von einem OPC UA-Server erfolgt entweder über Subscriptions (spontan) oder über Pollgruppen (periodisch). Die bevorzugte Variante ist die spontane Übertragung, da hier das Übertragen von Werten, die sich nicht geändert haben, wegfällt und somit unnötige Last vermieden wird.

Subscriptions

In der Peripherieadresse wird festgelegt, welcher Subscription eine Adresse zugeordnet ist. Die Parameter einer Subscription werden am zugeordneten Datenpunkt _OPCUASubscription definiert (siehe Kapitel Interne Datenpunkte des OPC UA Clients). Dieser Datenpunkt wird teilweise (einige Einstellungen sind nur über interne Datenpunktelemente konfigurierbar) mithilfe des Subscription-Panels parametriert.

Wenn alle Adressen einer Subscription gelöscht oder deaktiviert werden, dann löscht der Client automatisch die Subscription beim Server.

Monitored Items

Die Parameter der Monitored Items sind zum Teil fixcodiert oder in der Subscription festgelegt. D.h. es wird davon ausgegangen, dass viele Monitored Items in Gruppen mit gleichen Parametern zusammengefasst sind.

Zuordnung Attribute WinCC OA <-> OPC UA

Jeder Node (Knoten) im Adressraum besitzt Attribute. Diese sind ihren Entsprechungen im WinCC OA Adressraum zugeordnet.

OPC UA WinCC OA Konfig Beschreibung
Statuscode: Good oder Bad/Uncertain _original.._aut_inv Invalid von einem Schnittstellentreiber gesetzt.
Attributwert _original.._value Originalwert.
Setzt WinCC OA OPC UA Client _original _..GI Wird bei einer Generalabfrage gesetzt.
Setzt WinCC OA OPC UA Client _original _..SI Wird bei einer Einzelabfrage gesetzt.
Setzt WinCC OA OPC UA Client _online_..stime Quellzeit.
Projektspezifisches Mapping

_online.._userbit1

bis

_online.._userbit32

 Benutzerdefinierte Statusbits, die projektspezifisch im Client parametriert werden (siehe Kapitel Parametrierung des OPC UA Clients)

OPC UA Statuscodes (siehe OPC UA Statuscodes) sind projektspezifisch auf WinCC OA Userbits abzubilden.

Anmerkung:

Mittels des Config-Eintrages setInvalidForConnLoss können alle Eingangs- sowie Ein/Ausgangsadressen des OPC UA-Clients ungültig gesetzt werden, wenn es zu einem Verbindungsverlust zwischen Client und Server kommt. Das Invalid-Bit wird bei der nächsten erfolgreichen Übertragung zurückgesetzt.

Wenn der Client ordnungsgemäß beendet oder die Verbindung zum Server im Konfigurationpanel beendet wird, erfolgt kein Setzen des Invalid-Bits. Ebenfalls wird das Bit nicht für Alarme oder Ausgangsadressen gesetzt.

Generalabfrage (GQ)

GQ für Datenwerte

Die Generalabfrage für Datenwerte kann für alle verbundenen Server, für einen spezifischen Server oder nur für eine Subscription ausgelöst werden.

Für alle Server:

Internes Datenpunktelement: _Driver1.GQ.._original

Für einen Server:

Internes Datenpunktelement: _Server4.Command.GQ.._original

Für eine Subscription:

Internes Datenpunktelement: _Subs23.Command.GQ.._original

Automatische GQ

Bei einer automatischen Generalabfrage bei Verbindungsaufbau werden nur jene Daten abgefragt, die nicht in einer Subscription sind, da diese Daten ohnehin beim Anlegen der Subscription geschickt werden. Mit dem Config-Eintrag autoGQ können die verschiedenen Varianten der automatischen Generalabfrage eingestellt werden.

GQ für Alarme

Die Generalabfrage für Alarme kann wie eine GQ für Werte für alle verbundenen Server, für einen spezifischen Server oder nur für eine Subscription ausgelöst werden. Die Datenpunkte zum Auslösen der GQ sind dieselben wie jene für die Werte (siehe oben). Welchen GQ ausgelöst wird kann durch den auf das entsprechende Datenpunktelement geschriebenen Wert bestimmt werden.

0 -> Werte und Alarme

1 -> nur Werte

2 -> nur Alarme

Rückmeldung auf Schreibbefehle

Es ist möglich am dazugehörigen Datenpunkt eine Rückmeldung auf OPC UA-Schreiboperationen zu bekommen. Um eine Rückmeldung anzufordern, muss ein konfigurierbares Userbit gesetzt sein, wenn auf ein Datenpunktelement mit I/O-Adresse geschrieben wird. Durch Anfordern der Rückmeldung setzt der Treiber ein anderes konfigurierbares Userbit, wenn das Ergebnis des Schreibbefehls erhalten wird. Schlägt das Schreiben fehl, so wird vom Treiber zusätzlich das _aut_inv-Statusbit gesetzt.

Das Userbit zum Anfordern der Rückmeldung wird mit dem Config-Eintrag connUserbitWriteFeedback definiert. Der Config-Eintrag userbitWriteFeedback gibt das Userbit an, welches bei Erhalt der Rückmeldung gesetzt werden soll.

Soll das Userbit, welches die Rückmeldung kennzeichnet, auch beim Lowlevel-Vergleich oder bei der Glättung berücksichtigt werden, muss zusätzlich der treiberallgemeine Config-Eintrag smoothBit = userbitWriteFeedback gesetzt werden.

OPC UA Structured Data Variables

Konzept

Für die Verwendung von OPC UA Structured Data Variables (SDV) innerhalb von WinCC OA müssen diese auf einen JSON-String abgebildet werden.

Gründe warum WinCC OA keine direkte Abbildung für diese struktturierten Daten auf einen WinCC OA DP bietet sind folgende:

  1. Eine SDV muss als eine Einheit behandelt werden, was bei einer Abbildung auf mehrere Datenpunkt-Elemente sehr schwer ist.
  2. Die Addressierung wäre sehr komplex, da eine eigene Peripherie-Adresse für jedes Element erforderlich wäre.
  3. SDVs können Datentypen verwenden, welche nicht auf WinCC OA DPs abgebildert werden können, z.B. ein Array an Strukturen.

Grundsätzlich ist die Verwendung eines JSON-Strings nur ein Zwischenschritt und die endgültige Repräsentation eines SDVs in WinCC OA ist eine mapping-Variable.

Das bedeutet, dass das DPE, welches die Adresse eines SDVs beinhaltet, vom Typ string und der Inhalt ein JSON-String ist. Das erlaubt es der Anwendung die Daten einfach für die komfortable Vearbeitung in eine mapping-Variable zu konvertieren während das mapping flexible genug is um beliebige SDVs abzubilden.

OPC UA Structured Data Variable Mapping

Ein einfaches Beispiel für einen OPC UA Datentyp finden sie unterhalb. Dieser Vector besitzt folgende Elemente:

X: double
Y: double
Z: double

In WinCC OA entspricht dies folgendem mapping:

mapping m;
m["X"] = 10.0;
m["Y"] = 20.0;
m["Z"] = 30.0;

Um dies auf eine SDV zu schreiben, muss das mapping in einen JSON-String konvertiert (siehe jsonEncode()) und auf ein DPE des Typs string geschrieben werden, welches die Addresse der SDV konfiguriert hat.

Für die Eingabe-Richtung stellt der Treiber einen JSON-String auf dem DPE zur Verfügung, welches mittels der Funktion jsonDecode() in ein mapping konvertiert werden kann.

Dies kann ebenfalls für sehr komplexe verschachtelte Strukturen verwendet werden. Ein Array an Strukturen in OPC UA kann auf ein dyn_mapping in WinCC OA abgebildet werden. Wenn der OPC UA Datentyp eine verschachtelete Struktur aufweist, dann muss das WinCC OA mapping ebenfalls ein verschachteltes mappping darstellen.

Stellen Sie sich zum Beispiel einen OPC UA Datentyp vor, welcher aus einem eingebauten Typ string und dem oben beschriebenen Vector besteht:

Name: string
V: Vector

Sie müssen das entsprechende mapping folgendermaßen aufbauen:

mapping m1, m;
m1["X"] = 10.0;
m1["Y"] = 20.0;
m1["Z"] = 30.0;
m["Name"] = "Vector Name";
m["V"] = m1;
Anmerkung: Es ist wichtig, dass ein verschachteltes mapping verwendet wird und nicht ein mapping mit den Schlüsseln versehen wird, welche die Hierachie repräsentieren.

Einschränkungen

Folgende Einschränkungen müssen beachtet werden:

  • Der OPC UA Server muss ein DataType Dictionary für die strukturierten DataTypes bereitstellen. Es wird nicht unterstützt, wenn der UA-Server die Strukturdefinition nur durch das DataType-Attribut DataTypeDefinition bereitstellt.
  • Datentypen Union oder OptionSet werden nicht unterstützt.