Eine OPC UA Integration kann heute den richtigen Wert lesen und nach einer Serveraktualisierung einen falschen Wert liefern, wenn sie eine veränderliche Kennung gespeichert hat. Ein OPC UA Server verwaltet einen Adressraum aus Knoten, die Anlagen, Werte und deren Beziehungen beschreiben. Eine zuverlässige Integration identifiziert jeden Wert über NodeId und Namespace und bewahrt Status und Zeitstempel mit dem Wert auf. Dieser Leitfaden erklärt die Kennungen und die Abnahme eines Datenpunkts, bevor hundert weitere hinzukommen.
Dieser Leitfaden gehört zur Reihe über OPC UA und MQTT. Er behandelt die übliche sitzungsbasierte Kommunikation zwischen Client und Server, nicht OPC UA PubSub.
Clients und Server
Teil 1 der Einführung der OPC Foundation unterscheidet die Rollen: Der Server besitzt den Adressraum und bietet Dienste dafür an. Der Client verbindet sich und nutzt diese Dienste. Eine Anwendung kann beide Rollen einnehmen: Ein Gateway kann als Client den Server einer SPS lesen und zugleich einem SCADA-System einen eigenen Server anbieten. Diese beiden Schnittstellen brauchen jeweils eine eigene Spezifikation und einen eigenen Test. Ein häufiger Fall ist ein Wrapper, der einen UA Server vor einen älteren OPC DA Server setzt; der Leitfaden zur Migration von OPC DA behandelt ihn.
Prüfen Sie jeden benötigten Dienst einzeln: Browse, Read, Write, Subscriptions mit Monitored Items, Methodenaufrufe und historischen Zugriff. Eine erfolgreiche Abfrage eines einzelnen Skalarwerts belegt nur, dass dieser Knoten mit diesem Benutzer gelesen werden kann.
Endpunkte und Sicherheit
Eine Endpunkt-URL wie opc.tcp://plc-line-a.example:4840/UA/Process kennzeichnet die Verbindung, nicht einen Wert. Jeder Endpunkt gibt in seiner EndpointDescription an:
- die Security Policy, also die verwendeten Algorithmen;
- den Message Security Mode: None, Sign oder SignAndEncrypt;
- die akzeptierten Benutzeranmeldungen: anonym, Benutzername und Passwort oder Zertifikat.
Darauf folgen zwei getrennte Vertrauensentscheidungen. Client und Server müssen einander bei ihren Anwendungszertifikaten vertrauen. Danach muss der Server den Benutzer autorisieren. Ein vertrauenswürdiges Zertifikat erteilt einem Benutzer noch keine Berechtigung; eine offene TCP-Verbindung beweist keines von beidem. Dokumentieren Sie Endpunkt, Security Policy und Mode, Benutzeridentität und den Ort, an dem jedes Zertifikat als vertrauenswürdig hinterlegt ist.
NodeIds und Namespaces
Eine NodeId identifiziert genau einen Knoten. Sie besteht aus Namespace-Index und Kennung:
| NodeId | Namespace-Index | Kennungstyp | Kennung |
|---|---|---|---|
ns=2;s=LineA.Temperature | 2 | Zeichenfolge | LineA.Temperature |
ns=3;i=1001 | 3 | Zahl | 1001 |
i=2258 | 0 (OPC UA Namespace) | Zahl | 2258, die aktuelle Serverzeit |
Der Namespace-Index ist die Position im NamespaceArray des Servers; an jeder Position steht eine Namespace-URI. Teil 3 der Spezifikation legt diese Beziehung fest. Die URI ist der stabile Name. Der Index kann sich ändern, wenn Konfiguration oder Firmware des Servers geändert werden:
Dokumentieren Sie zu jeder NodeId in der Datenpunktliste auch die Namespace-URI. Prüfen Sie nach jeder Serveränderung das NamespaceArray, bevor Sie den bisherigen Indizes vertrauen.
Anzeigename und Browse Path sind ebenfalls keine NodeIds. Nutzen Sie sie zur Suche nach einem Knoten und dokumentieren Sie anschließend dessen NodeId.
Wert, Status und Zeitstempel
Eine Leseanfrage liefert ein DataValue gemäß Teil 4 der Spezifikation. Bewahren Sie alle Bestandteile auf:
| Feld | Bedeutung |
|---|---|
| Value | Wert im Datentyp des Knotens: Skalar, Array oder Struktur |
| StatusCode | Good, Uncertain oder Bad mit einer Begründung |
| SourceTimestamp | Zeitpunkt der Messung oder Änderung an der Quelle, sofern dem Server bekannt |
| ServerTimestamp | Zeitpunkt, zu dem der Server den Wert zuletzt als aktuell kannte |
Regeln für die Verwendung:
- Zuerst den Status prüfen. Ein Bad-Wert ist kein Messwert. Vereinbaren Sie eine Regel für Uncertain.
- Zeitstempel auseinanderhalten. Ein gleichbleibender Wert kann einen alten SourceTimestamp behalten, während der Server ihn wiederholt mit einem neuen ServerTimestamp bestätigt. „Seit einer Stunde unverändert“ bedeutet nicht „seit einer Stunde keine Kommunikation“.
- Datentyp prüfen. Halten Sie den deklarierten Typ und die Frage fest, ob ein Array vorliegt. Ein UInt64-Zähler ist in OPC UA gültig, kann aber in Software mit 64-Bit-Gleitkommazahlen an Genauigkeit verlieren.
- Zeitstempel des Erfassers kennen. Manche Erfassungssysteme verwenden Server- oder Quellzeit, andere den eigenen Lesezeitpunkt. Der Leitfaden zu Zeitstempeln erklärt den Unterschied.
Einen Datenpunkt abnehmen, dann erweitern
Dokumentieren Sie für den ersten Datenpunkt Endpunkt, Sicherheitseinstellungen, Benutzer, Namespace-URI, NodeId, Datentyp, Einheit, Skalierung und Abfrageintervall. Danach:
- Vergleichen Sie den Wert während einer Änderung mit einer unabhängigen Referenz.
- Erfassen Sie Statuscode und Zeitstempel am Server, am Datenerfasser und am Zielsystem.
- Stoppen Sie die Quelle oder die Verbindung mit Genehmigung. Die Daten müssen eine Lücke oder den Status Bad oder Uncertain zeigen, nicht einen alten Wert mit neuem Zeitstempel.
- Starten Sie den Datenerfasser neu und prüfen Sie, ob er wieder denselben Knoten liest.
- Lesen Sie einen nicht vorhandenen Knoten und einen Knoten, für den der Benutzer keine Leseberechtigung hat. Beide Zugriffe müssen klar fehlschlagen, statt den Wert eines anderen Knotens zurückzugeben.
Prüfen Sie Schreibzugriffe separat, nur mit Genehmigung der für die Anlage verantwortlichen Person und mit unabhängiger Kontrolle der tatsächlichen physischen Reaktion.
OPC UA mit Edge
Edge auf dem ZGW-20 Gateway arbeitet als OPC UA Client. Es verbindet sich mit einem Endpunkt über die vom Server angebotene Security Policy und den Mode (None, Sign oder SignAndEncrypt), anonym, mit Benutzername oder mit Zertifikat. Es liest jeden Variablenknoten nach einem Zeitplan von einmal pro Sekunde bis einmal pro Tag und wendet gegebenenfalls Multiplikator und Offset an. Edge adressiert jeden Knoten mit der vollständigen NodeId einschließlich Namespace-Index. Prüfen Sie den Index deshalb nach jeder Serveränderung. Jeder Wert erhält beim Lesen durch Edge einen Zeitstempel.
Häufige Fragen
Was ist eine NodeId in OPC UA?
Die Kennung eines Knotens im Adressraum eines Servers. Sie besteht aus einem Namespace-Index und einer Kennung, die eine Zahl, Zeichenfolge, GUID oder Bytefolge sein kann. ns=2;s=LineA.Temperature bezeichnet beispielsweise die Zeichenfolge LineA.Temperature im Namespace 2.
Was ist ein OPC UA Namespace?
Eine Gruppe von Knotenkennungen, die durch eine URI benannt wird. Der Server listet seine Namespaces im NamespaceArray. Eine NodeId verweist über die Position in diesem Array auf einen Namespace. Die URI ist der stabile Name; die Position, also der Index, kann sich bei einer Änderung der Serverkonfiguration verschieben.
Worin unterscheiden sich OPC UA Client und Server?
Der Server besitzt den Adressraum und bietet Dienste dafür an. Der Client verbindet sich und nutzt diese Dienste zum Browsen, Lesen, Schreiben oder Abonnieren. Eine Anwendung kann beides sein: Ein Gateway kann als Client den Server einer SPS lesen und einem SCADA-System einen eigenen Server bereitstellen.
Was bedeutet ein OPC UA Statuscode?
Jeder vom Server zurückgegebene Wert hat einen Statuscode: Good, Uncertain oder Bad, jeweils mit einer Begründung. Ein Bad-Wert darf nicht als Messwert verwendet werden. Für Uncertain-Werte braucht das Projekt eine vereinbarte Regel.