/
How-To - OPC-UA Anbindung

How-To - OPC-UA Anbindung

Owned by Marcel Ortler
Last updated: Nov 25, 2024 by Michael Schagerl
9 min read

Informationen zur Konfiguration und Anbindung OPC-UA mittels Client “UaExpert“

OPC-UA Server auf myDatanet

Der myDatanet Server bietet die Einbindung eines OPC-UA Servers. Damit können die Daten welche am myDatanet Server bereitgestellt werden, in ein externes System (z.B. SCADA) eingebunden werden.

image-20240308-093133.png
Übersicht

OPC-UA DA Implementierung

Das Kürzel “DA” steht für “Data Access” und ist eigentlich die Basis-Funktion, die sich jemand von OPC erwartet. Mit DA kann auf einzelne Datenfelder und deren Wert zugegriffen werden. Im Falle von myDatanet OPC-UA kann ein Lesezugriff auf die Hist-Daten (letztgültige Werte) sowie Lese-und Schreibzugriff auf die Config-Daten erfolgen.

Die verfügbaren Datenfelder werden automatisch aus dem Blueprint einer Site generiert. Dadurch ist keine Konfiguration der Datenpunkte notwendig.

OPC-UA HA Implementierung

Das Kürzel “HA” steht für “Historical Access” und ermöglicht es auch Zeitreihen von Datenfeldern auszulesen. Nachdem in myDatanet historische Daten vorhanden sind, unterstützt myDatanet OPC-UA diese Funktion. Neben dem Datenfeld kann der Client einen Zeitraum übergeben und erhält dafür passenden Daten.

Authentifizierung

Die Authentifizierung der OPC-UA Clients erfolgt über die myDatanet Benutzerverwaltung. Damit ist das Rechte-Management vollständig integriert und erleichtert das Sicherheits-Management. Der für die Authentifizierung verwendete Benutzer hat die gleichen Rechte wie bei Anmeldung an dem myDatanet UI (wie z.B. sichtbare Sites/Kunden).

Konfiguration am myDatanet - Server

Bevor Daten mittels OPC-UA abzurufen sind, sind auf myDatanet die entsprechenden Konfigurationen unter “OPC-UA Server” vorzunehmen.

Voraussetzungen:

  • Um den OPC-UA Server konfigurieren zu dürfen wird ein Admin (Benutzergruppe 7) benötigt.

  • Serverversion >= 50v017 mit entsprechender Lizenz um OPC-UA zu verwenden

  • Freigabe des verwendeten TCP-Ports (Standard: 4334)

  • Im “Kunden” wurde die REST-API mittels “API verfügbar“ aktiviert

Die Einstellungen erfolgen unter “Konfigurationen” am Servers.

image-20240308-101553.png
myDatanet Konfiguration

Im Reiter “OPC-UA Server” finden sich die Einstellungen.

image-20240308-102534.png
UPC UA Einstellungen

Für die Authentifizierung am myDatanet Server über OPC-UA wird empfohlen, separate Interface-Benutzer anzulegen.

Dazu wird ein neuer Benutzer mit Typ “Interface-Benutzer” angelegt. Die Benutzergruppe “Kunden-Operator (1)“ ist berechtigt die Messdaten abzufragen.

image-20240308-103345.png
Interface Benutzer

 

Konfiguration des OPC-UA Clients

Für diesen Artikel wurde “UAExpert“ Client verwendet. Es kann ein beliebiger OPC-UA Client gewählt werden.

Im Client ist ein neuer OPC-UA Server hinzuzufügen. Dazu wird auf das Plus Symbol geklickt.

 

c116aeae-39b1-449e-acb3-0a586fae9dda.png

Mit einem Doppelklick auf “Custom Discovery“ wird die Eingabemaske geöffnet zur Eingabe von URL laut Serverkonfiguration.

image-20240311-084616.png
Custom Discovery

Mit dem Klicken auf OK wird dieser in die Liste hinzugefügt.

image-20240311-124417.png
URL laut Konfiguration

Danach kann man den OPC-UA Server aufklappen bis man zu den verschiedenen Verschlüsselungstypen kommt und eines der grün hinterlegten wählt. Danach muss man nur mehr Username und Passwort von seinem Interface Benutzer eingeben.

image-20240311-125136.png
Verschlüsselungstypen

image-20240311-125240.png
Authentifizierung

Beim ersten Verbinden könnte nach einem Zertifikat gefragt werden. Dieses Server Zertifikat akzeptieren und loslegen.

Anschließend muss man sich zum Server verbinden. Dazu Rechtsklick auf den Server und Connect.

 

image-20240311-125553.png
Zum Server verbinden

Anzeigen von Daten im OPC-UA Client

Der myDatanet OPC-UA Server stellt automatisch die

  • Der myDatanet OPC-UA Server stellt automatisch die Kunden → SITE → Datenfelder Struktur zur Verfügung.

    Über die DropDown-Felder kann man zum gewünschten Datenfeld navigieren.
    UaExport stellt unterschiedliche “Documents” zur Anzeige der Datenpunkte zur Verfügung.

    • DataAccessView → letzter Messwert

    • History Trend View → Darstellung einer Zeitreihe in einer Kennlinie

    • Event View → Darstellung und Verwaltung von Alarmen & Events. Als so genannte “Event Sources” können in OPC UA nur Objekte verwendet werden. D.h. die Alarm-Ansicht muss zumindest auf Ebene eines historischen Datenstroms (z.B. histdata0) erfolgen. Auf der Ebene einzelner Felder ist dies nicht möglich.

    Die entsprechenden Datenfelder können per Drag&Drop aus der Auswahlliste in den jeweiligen View gezogen werden.

Verwendung von StatusCodes bei einzelnen Datenpunkten

Ein Datenpunkt setzt sich immer aus 3 Komponenten zusammen:

  • Zeitstempel

  • Wert

  • Qualität des Werts (abgebildet durch den StatusCode)

In myDatanet kommen bei Einzeldatenpunkten folgende StatusCodes zum Einsatz:

  • Good … Der Datenpunkt enthält einen letztgültigen Wert.

  • GoodNoData … Es liegen (noch) keine Daten vor. (Zum Beispiel, wenn eine neue Site noch keine Daten hat)

  • BadWaitingForInitialData … Wird bei der Initialisierung einer Registrierung verwendet, um dem Client zu signalisieren, dass der Server noch auf die interne Abfrage des letztgültigen Werts wartet. Im Normalfall besteht dieser StatusCode nur für den Bruchteil einer Sekunde, bis die aktuellen Werte ausgeliefert sind.

  • BadDataUnavailable … Wird ausgegeben, wenn der aktuelle Wert des Datenpunkts ‘NAN’ ist.

  • BadOutOfRange … Wird ausgegeben, wenn der aktuelle Wert des Datenpunkts ein NAMUR-Wert (OPEN LOOP, SHORTCUT, OVERFLOW, UNDERFLOW) ist.

  • BadResourceUnavailble … ist für einen eigentlich nicht erreichbaren Zustand reserviert, in dem der Client Daten eines nicht verfügbaren Datenpunkts abfragen will.

Behandlung des Publish Interval und anderen Settings

Alle einstellbaren Werte (z.B. “Publishing Interval”, “Sampling Interval”, “Queue size”, etc.) werden zwischen Client und Server ausgehandelt. Dabei sendet der Client eine Änderungsanfrage an den Server, der diese dann bewerten kann und den letztlich gültigen Wert (“revised”) als Info an den Client zurück sendet. In UaExpert merkt man davon nicht sofort etwas, im Log-Fenster der Software kann man diese Abfolgen aber beobachten.

Sobald Geräte am Server Daten abliefern, kümmert sich der Server zur Datenübermittlung über OPC-UA. Der Ablauf und der Zusammenhang der Datenübermittlung über OPC-UA ist im folgenden beschrieben:

  1. In der Welt von OPC UA öffnet ein Client zunächst eine Session.

  2. In einer Session können nun Subscriptions erstellt werden. Die wesentlichen Eigenschaften davon sind:

    1. “Publishing Interval”: Im “Publishing Interval” sendet der Server neue Daten an den Client, sofern seit dem letzten “Publish” neue Daten in der Queue sind. Ein Client erhält Daten niemals schneller als im Publishing Interval. So wird vermieden dass Clients überlastet werden.

    2. “Life Time Count”: Ein Faktor, mit dem der “Publishing Interval” multipliziert wird, um den Timeout der Subscription zu berechnen, falls der Client die Verbindung verliert. Beispiel: “Publish Interval” ist 500ms, “LifeTimeCount” ist 2400, damit ergibt sich ein Timeout von 1200 Sekunden, also 20 Minuten.

  3. Eine Subscription kann dann beliebige “monitored Items” enthalten. Ein monitored Item steht immer in einer 1:1-Beziehung mit einem Datenpunkt im Address Space. Man kann in einer Subscription auch mehrere monitored Items anlegen, die den gleichen Datenpunkt registrieren. Die wesentlichen Eigenschaften eines monitored Item sind:

    1. “Sampling Interval”: In diesem Zeitintervall wird der Wert des Datenpunkts gegenüber dessen Datenquelle abgefragt. Falls ein neuer Wert zur Verfügung steht wird dieser in die Queue geschrieben.

    2. “Queue Size” (Standard-Wert ist 1): Die Länge der Queue (Warteschlange) auf dem monitoredItem. Das ist die maximale Anzahl an Werten, die bei einem Publish (im “Publishing Interval”) an den Client gesendet werden können. Die Queue wird im Sampling Interval befüllt (sofern sich der unterliegende Wert auch ändert). Ist die Queue voll, dann:

    3. “Discard Oldest”: Legt fest was passieren soll, wenn die Queue voll ist. Ist “Discard Oldest” nicht aktiv, so wird der aktuellste Wert der Queue immer überschrieben, bis die Queue geleert (also an den Client gesendet) wird.

    4. “Data Change Filter”: Einstellung zur serverseitigen Vorfilterung der Daten. Standard ist hier “Status/Value”, wodurch nur dann neue Werte beim Client ankommen, wenn es auch eine tatsächliche Änderung gibt. Will man wirklich jeden Datenpunkt am Client erhalten, ist hier “Status/Value/Timestamp” zu verwenden.

Szenarien und Bedeutung der Parameter in myDatanet

Fortführung einer unterbrochenen Verbindung (Session)

Verliert ein Client seine Verbindung zum Server (z.B. durch Abbruch der TCP-Verbindung), so kommt pro Subscription die Timeout-Berechnung auf “Publishing Interval” multipliziert mit “Life Time Count” zum Einsatz. So lange behält der Server die Subscription vor und der Client hat die Chance, diese dann auch wieder aufzunehmen. Wenn in dieser Zeit Daten in der Queue eines monitored Item gesammelt werden, so werden auch diese Daten nach Wiederherstellung der Verbindung übermittelt.

Das absichtliche Trennen einer Verbindung beendet auch alle darin enthaltenen Subscriptions. Die Fortführung einer Verbindung ist nur für unvorhergesehene Unterbrechungen gedacht.

Wann wird die Queue befüllt?

Das Konzept der Queue ist dafür gedacht, nicht jeden einzelnen Messwert eines monitoredItems über die Netzwerkverbindung zum Client senden zu müssen, sondern eben gesammelt. Ist der “Sampling Interval” eines monitored Item kleiner als der “Publishing Interval” der zugehörigen Subscription, so wird eine Queue Size von 1 (Standard-Wert) nicht ausreichen. Die Queue sollte immer zumindest so viele Werte halten können, wie im Sampling Interval auftreten können, bevor wieder ein Publish an den Client durchgeführt wird. Wird das nicht gemacht ist damit zu rechnen, dass nicht alle Datensätze beim Client ankommen.

Sampling Interval und die Queue bei Datenloggern im Intervallbetrieb

Diesem Szenario wird in der Implementierung von OPC UA in myDatanet entsprechend Sorge getragen. Ein Datenlogger im Intervallbetrieb übermittelt seine aufgezeichneten Daten auf einmal zum Server, die Weitergabe über OPC UA kann jedoch dann nicht 1:1 passieren, weil nur eine begrenzte Anzahl an Datensätzen (= Queue Size) in einem Publishing Interval übermittelt werden können.
In diesem Szenario werden die neuen, vom Gerät empfangenen Datensätze, nur im zeitlichen Abstand des maximal verwendeten “Sampling Interval” auf dem betroffenen Datenpunkt eben dort hin geschrieben. Damit wird gewährleistet, dass alle Datenpunkte ihren Weg zum Client finden können, vorausgesetzt die Queue ist lang genug, um die Daten auch halten zu können.

Die Übertragung von Daten kann aber hier natürlich länger dauern, wenn ein Datenlogger viele Daten übermittelt, der Sampling Interval in OPC UA aber auch lang eingestellt ist. Ein “Sampling Interval” von 1000ms würde z.B. bedeuten, dass die Daten einer Messstelle mit minütlicher Aufzeichnung, die nur 1x täglich Daten übermittelt, insgesamt 1440 Sekunden dauern würde, also ca. 24 Minuten!

Good to Know - DataAccessView

Zur Anzeige des letzten Messwerts bringt UAExpert eine Eigenheit mit. Der Wert inkl. Timestamp wird nur dann aktualisiert, sobald sich der Wert ändert. Gleichbleibende Werte über neuere Timestamps können mit folgender Einstellung aktuell angezeigt werden.

20240208-0713-31.3327774.mp4

Schreiben von Config-Werten

Es ist möglich, Konfigurationswerte über OPC UA zu schreiben. Diese Funktion ist auf die Veränderung von Konfigurationsfeldern beschränkt. Ein Schreiben von historischen Datensätzen ist nicht möglich.

Die jeweilige Voraussetzung ist, dass auch die dafür nötigen Benutzerrechte vorhanden sind. Es ist nicht möglich, die Beschreibbarkeit eines Feldes von vorne herein über OPC UA zu sperren. Erst wenn ein verbundener Client einen Schreibversuch unternimmt, wird die Antwort des Servers über Erfolg oder Misserfolg Auskunft geben.

Der Client UaExpert unterstützt das auch. Zunächst muss der zu schreibende Wert in einem “Data Access View” angezeigt werden, dann kann mit einem Doppelklick auf den letzten Wert dieser auch verändert werden.

Alarme & Events

Die Unterstützung von Alarms & Events über OPC UA ist ab Server Version 52v010 verfügbar.

Treten am myDatanet-Server Alarme auf, wie z.b. Messwert Über-/Unterschreitungen, so werden diese als OPC UA Alarm Events weitergeleitet.

Alarmquelle

Die Alarmquelle im OPA UC “Address Space” ist dabei der Datenstrom der den entsprechenden Messkanal beinhaltet. Tritt z.b. ein Alarm am Kanal “val1” auf so ist die Alarmquelle “STATUS”. Die Alarm-Condition selbst scheint im “Address-Space” nicht auf.

image-20240731-074431.png

Der Client kann auch als Alarmquelle das Messstellenobjekt auswählen um alle Alarme einer Messstelle zu bekommen, oder das Kundenobjekt um alle Alarme eines Kunden zu bekommen. Um alle Alarme aller Kunden und Messstellen zu bekommen kann der Client auch als Alarmquelle das “customers” Object registrieren.

Alarmdetails

image-20240731-075250.png

ConditionId

Eindeutige NodeId der Condition.

z.B.: “s.4DF24E23816DED27.histdata0.ch1.overflow”
“s.4DF24E23816DED27” … NodeId der Messstelle
”histdata0” … Datenstrom
”ch1” … Kanal
”overflow” … Typ der Condition. Siehe Tabelle “Condition Typen”

AckedState

True wenn der Alarm quittiert wurde. Dies kann über das myDatanet-Portal erfolgen oder über die OPC-UA Schnittstelle.

ActiveState

True so lange der Alarm aktiv ist (die Alarmschwelle über-/unterschritten ist)

ConditionName

Kann “alarm” oder “warning” sein.

EventId

Eindeutige Nummer des Alarm Events, wird vom Framework automatisch vergeben.

EventType

ist immer “ExclusiveLimitAlarmType”

Message

Klartext des Alarm-Events

Severity

250….warning
500…alarm

SourceName

Name des Messkanals bei dem der Alarm aufgetreten ist.

SourceNode

NodeId der Alarmquelle

z.B.: “s.4DF24E23816DED27.histdata0.ch1”
“s.4DF24E23816DED27” … NodeId der Messstelle
”histdata0” … Datenstrom
”ch1” … Kanal

Condition Typen

“underflow”

Unterschreitung der Warn-/Alarmschwelle

“overflow”

Überschreitung der Warn-/Alarmschwelle

“fault”

Messwert ungültig

“offline”

Messstelle ist offline

“transfer_volume”

Überschreiten der Datentarif Warnschwelle

“position”

Alarm auf Grund von Ortungsdaten

“test”

Test-Alarm

“user1”..”user3”

Applikationsspeziefische Alarme