OPC UA

Was ist das

Ein OPC-UA-Ziel ist ein benannter Messpunkt oder Stellwert an einer Maschinensteuerung: Endpunkt, Knoten, Datentyp und Richtung. Sie legen das Ziel einmal an. Kommando-Schritte und separate Telemetriebindungen referenzieren es danach über seinen Namen.

Aktionen greifen über zwei Kommandos darauf zu. opcua.read liest einen Wert, ohne etwas zu verändern. opcua.write schreibt einen Wert auf die Steuerung; dieser Schritt ist unumkehrbar, denn ein einmal geschriebener Sollwert lässt sich nicht softwareseitig zurückholen. Zusätzlich kann eine separate Telemetriebindung Werte eines OPC-UA-Ziels für das telemetry-Widget bereitstellen, ohne dass eine Aktion dazwischenläuft. Das Widget selbst bindet nur eine Maschine, nicht den Zielnamen.

Ein OPC-UA-Ziel legen Sie in der Verwaltung unter „OPC-UA-Ziele“ an, entweder manuell oder über den Assistenten. Beide Wege prüfen die Definition vor dem Speichern nach denselben Regeln.

Daneben existieren zwei getrennte OPC-UA-Telemetriepfade. Eine OPC-UA-Konfiguration in der Maschinenbindung enthält selbst Endpunkt, Intervall und numerische Knoten. Sie leitet Messpunkte wie MQTT in den Zeitreihen- und Zustandsregelpfad. Sie verwendet kein benanntes OPC-UA-Ziel und befüllt nicht die aktuellen Zeilen des Live-Widgets.

Für das Live-Widget braucht die beim Start aus der gebündelten Konfiguration geladene telemetry.Binding dagegen eine Maschine und den Namen eines OPC-UA-Ziels. Der Telemetrie-Runner löst dieses Ziel auf, abonniert seinen Knoten und aktualisiert die aktuellen Anzeigezeilen der Maschine. Nur wenn telemetry.Binding.Kind den Wert counter trägt und der gelesene Wert numerisch ist, schreibt dieser Pfad den Wert zusätzlich in die historische Zeitreihentabelle für den Zählerabgleich. Die vollständige Abgrenzung zeigt MQTT & Telemetrie.

Die vier Pfade bleiben technisch getrennt: Aktionen lesen oder schreiben über ein benanntes Ziel, eine Maschinenbindung speist den Telemetry Ingest, und eine Telemetriebindung speist die Live-Anzeige.

flowchart LR
    Action["Aktion"] --> Read["opcua.read"]
    Action --> Write["opcua.write"]
    Read --> Target["Benanntes OPC-UA-Ziel"]
    Write --> Target
    Target --> Controller["Maschinensteuerung"]
    Controller -->|"Wert"| Read
    Read --> Result["Ergebnis für weiteren Schritt"]
    Write -->|"Sollwert"| Controller

    MachineBinding["OPC-UA-Maschinenbindung"] --> Polling["Polling"]
    Polling --> Ingest["Telemetry Ingest<br/>Zeitreihe und Zustandsregeln"]

    TelemetryBinding["Telemetriebindung"] --> Target
    TelemetryBinding --> Subscription["Live-Abonnement"]
    Controller --> Subscription
    Subscription --> Current["Aktuelle Anzeigezeilen"]
    Current --> SSE["SSE"]
    SSE --> Widget["Maschinendaten-Widget"]
    Subscription -->|"nur numerischer Zähler"| Counter["Historische Zeitreihe"]

Wann einsetzen

Live-Anzeige an der Maschinenwand. Stückzähler, Drehzahl oder Werkzeugtemperatur laufen als aktuelle Werte in einer Ansicht mit, damit der Bediener den Zustand der Maschine auf einen Blick sieht, ohne eigens an der Steuerung nachzusehen.
Sollwerte aus einer Aktion setzen. Eine Aktion schreibt einen Sollwert oder eine Freigabe auf die Steuerung, etwa als letzten Schritt eines Rüstvorgangs, der die Presse danach für den nächsten Auftrag freigibt.
Zählerabgleich im Cockpit. Der Zählerabgleich vergleicht gebuchte Stückzahlen mit einer Telemetriebindung, deren telemetry.Binding.Kind auf counter steht. Er zeigt Abweichungen zwischen Buchung und Maschinenzähler, Tag für Tag und Maschine für Maschine. Details dazu stehen im Kapitel Kennzahlen & Cockpit.

Anatomie der Definition

Eine OPC-UA-Ziel-Definition ist ein flaches JSON-Objekt:

name: der Bezeichner des Ziels, ^[a-z][a-z0-9-]{0,63}$. Kommando-Schritte und eine separate Telemetriebindung referenzieren das Ziel über diesen Namen. Das telemetry-Widget kennt diesen Namen nicht.
endpoint: die Adresse der Maschinensteuerung, zum Beispiel opc.tcp://plc.example.invalid:4840.
node: die Knoten-ID auf dem Server, ns=2;s=Spindel.Drehzahl oder eine der anderen OPC-UA-Adressformen mit i=, g= oder b= statt s=.
type: der Datentyp des Werts, bool, int, double oder string.
mode: die erlaubte Richtung, read, write oder read-write. opcua.read braucht read oder read-write, opcua.write braucht write oder read-write.
security: optional, der Kanal- und Anmeldemodus. Fehlt das Feld ganz, gilt None und anonym. Der Modus (mode) steht auf None, Sign oder SignAndEncrypt; Sign und SignAndEncrypt verlangen zusätzlich eine policy. Die Anmeldung (auth) läuft anonym, per Benutzername mit password_secret, oder per Zertifikat mit user_cert_secret und user_key_secret. In allen drei Fällen sind die *_secret-Felder reine Namens-Verweise auf ein bestehendes Secret, nie ein Klartextwert.

Die Knoten-ID folgt dem Muster ns=<Namespace-Index>;<Adressform>=<Bezeichner>. Die Adressform bestimmt, wie der letzte Teil zu lesen ist: s= steht für einen symbolischen Namen wie Spindel.Drehzahl, i= für eine numerische ID, g= für eine GUID und b= für einen rohen Byte-String. Welche Form eine Steuerung anbietet, hängt vom jeweiligen OPC-UA-Server ab. Die Dokumentation und die freigegebenen Diagnosewerkzeuge Ihrer Steuerung zeigen die verfügbaren Knoten samt korrekter Adressform an.

Eine telemetry.Binding ordnet einem benannten OPC-UA-Ziel eine Maschine, einen Metriknamen, eine Beschriftung und eine Einheit zu. Optional hat telemetry.Binding.Kind den Wert counter. Dieser Wert ist keine Eigenschaft des OPC-UA-Ziels. Nur ein numerischer Wert einer solchen Zählerbindung wird zusätzlich in die Zeitreihentabelle für den Zählerabgleich geschrieben. Andere gebundene Werte bleiben aktuelle Anzeigezeilen.

Für diese Live-Telemetriebindungen gibt es derzeit weder UI- noch HTTP-CRUD. „OPC-UA-Ziele“ verwaltet das referenzierte Ziel, nicht die Zuordnung zur Maschine. Eine Ansicht konfiguriert ebenfalls nur die Maschine des Widgets.

Telemetrie ist reine Anzeige. Ein Live-Wert ist keine Buchung, taucht in keiner Rückverfolgung auf und ersetzt keinen Schritt-Abschluss. Verbindlich wird eine Zahl erst durch eine Buchung, also durch einen abgeschlossenen Schritt oder eine Aktion. Der Maschinenzähler mag einen bestimmten Stand anzeigen; für das System und für die Rückverfolgung zählt trotzdem nur, was ein Bediener am Terminal tatsächlich abgeschlossen hat.

Beispiele

{
  "name": "presse-1-drehzahl",
  "endpoint": "opc.tcp://plc.example.invalid:4840",
  "node": "ns=2;s=Spindel.Drehzahl",
  "type": "int",
  "mode": "read",
  "security": {}
}

Mit dem Assistenten

Lese-Ziel für die Spindeldrehzahl anlegen.

Die Minimalform eines Ziels: name, endpoint, node, type und mode: read, ganz ohne security-Block. Fehlt der Block, gilt der Kanal als unverschlüsselt und die Anmeldung als anonym. opcua.read kann dieses Ziel lesen, opcua.write dagegen nicht. Für Live-Telemetrie muss die separate, beim Start geladene Telemetriebindung den Zielnamen und eine Maschine zuordnen; das telemetry-Widget selbst referenziert nur die Maschine.

{
  "name": "presse-1-freigabe",
  "endpoint": "opc.tcp://plc.example.invalid:4840",
  "node": "ns=2;s=Steuerung.Freigabe",
  "type": "bool",
  "mode": "write",
  "security": {
    "policy": "Basic256Sha256",
    "mode": "SignAndEncrypt",
    "auth": "username",
    "username": "werkspur",
    "password_secret": "presse-1-opcua-passwort"
  }
}

Mit dem Assistenten

Schreib-Ziel mit signierter, verschlüsselter Verbindung und Benutzer-Anmeldung anlegen.

mode: write erlaubt opcua.write auf dieses Ziel. Der Kanal läuft signiert und verschlüsselt (SignAndEncrypt), was eine Policy voraussetzt, hier Basic256Sha256. Die Anmeldung läuft per Benutzername; password_secret ist ein Namens-Verweis auf das hinterlegte Secret, nicht das Passwort selbst.

Fallstricke

opcua.write braucht ein schreibbares Ziel. Der Kommando-Schritt scheitert, wenn das Ziel mode: read trägt. Der übergebene Wert wird zusätzlich auf den type des Ziels gebracht; ein Text, der sich nicht als int lesen lässt, führt bei einem int-Ziel zu einem Fehler statt zu einer Schreibung.
Ein Schreiben lässt sich nicht zurückholen. Das Terminal behandelt opcua.write wie jede andere unumkehrbare Buchung. Die min_role der Aktion entscheidet, wer den Schritt auslösen darf; das Kapitel Aktionen beschreibt dieses Rollenmodell im Detail.
Sign und SignAndEncrypt ohne Policy lehnt die Validierung ab. Ein sicherer Kanalmodus benötigt eine passende policy; ohne sie akzeptiert WERKSPUR die Definition nicht.
Kein security-Block heißt unverschlüsselt und anonym. Das eignet sich nur für abgeschottete Maschinennetze ohne Zugriff von außen. Sobald die Steuerung in einem größeren Netz hängt, gehört ein security-Block mit einem echten Modus dazu. Ein Modbus-Ziel kennt diese Abstufung gar nicht erst und läuft grundsätzlich unverschlüsselt; dieselbe Einordnung gilt dort ausnahmslos.
Eine Änderung an einem Ziel braucht für die Live-Anzeige einen Neustart. Änderungen an Zielen wirken für Aktionen sofort, die laufende Telemetrie liest ihre Zuordnung beim Start; nach dem Ändern eines Ziels braucht die Live-Anzeige einen Neustart des Servers.

Wie ein telemetry-Widget eine Maschine in einer Ansicht auswählt, zeigt das Kapitel Ansichten. Wie der Zählerabgleich eine counter-Bindung gegen gebuchte Stückzahlen prüft, beschreibt das Kapitel Kennzahlen & Cockpit. Den vollständigen Weg von Telemetry Ingest über Speicherung und Regeln bis zur Live-Anzeige beschreibt MQTT & Telemetrie. Eine sichere Diagnosefolge finden Sie unter Integration: Fehlersuche.