OPC UA mit Node-RED verbinden

Bevor Sie starten

• Eine Node-RED-Installation mit einer unterstützten Node.js-Runtime und die Berechtigung, darauf Palette-Nodes zu installieren. In einem OT-Netz ist diese Berechtigung oft der eigentliche Blocker.
• Ein aus der Palette installierter Satz von OPC-UA-Client-Nodes. Es gibt mehrere konkurrierende Community-Pakete mit unterschiedlichen Node-Namen, unterschiedlicher Konfiguration und unterschiedlichem Pflegezustand; wählen Sie eines und bleiben Sie über alle Flows hinweg dabei.
• Eine funktionierende Endpunkt-URL und eine klare Entscheidung zur Sicherheit. Wenn Sie signiert und verschlüsselt fahren wollen, prüfen Sie vor dem Bau des Flows, ob das gewählte Node-Paket die Policy unterstützt, die der Server anbietet.
• Ein Ziel für die Daten, das nicht Node-RED ist. Es hat keinen eigenen dauerhaften Puffer.

Die Einrichtung

1. Ein OPC-UA-Node-Paket installieren und dabei bleibenInstallieren Sie über den Palette Manager und notieren Sie dann Paketname und Version in Ihren Projektunterlagen. Zwei OPC-UA-Pakete in einer Node-RED-Instanz zu mischen erzeugt verwirrende doppelte Node-Typen und widersprüchliche Zertifikatsverzeichnisse.
2. Weisen Sie den Endpunkt zuerst mit Security None nachKonfigurieren Sie den Client-Node mit der Endpunkt-URL und ohne Sicherheit und lesen Sie einen einzigen bekannten Knoten. Das trennt Netzwerk- und Endpunktprobleme von Zertifikatsproblemen und dauert eine Minute.
3. Die Zertifikatsarbeit explizit erledigenFinden Sie heraus, wo Ihr Node-Paket sein Client-Zertifikat und seine Ordner für vertrauenswürdige und abgelehnte Zertifikate auf der Festplatte ablegt, und schließen Sie den Austausch dann in beide Richtungen ab: Der Server muss dem Node-RED-Client-Zertifikat vertrauen, und der Client muss dem Serverzertifikat vertrauen. Das ist der Schritt, der aus einer Demo etwas macht, das ein Security-Review übersteht.
4. Adressieren Sie Knoten über die Namespace-URI, wo das Paket es zulässtDie meisten Community-Nodes erwarten einen NodeId-String mit einem literalen Namespace-Index, oft im Message-Topic mitgeführt. Wenn das Paket die Auflösung über die Namespace-URI unterstützt, nutzen Sie sie. Wenn nicht, lesen Sie das NamespaceArray zu Beginn des Flows in einem Function-Node und bauen Sie die NodeId-Strings daraus, statt Indizes in jeden Node zu kopieren.
5. Abonnieren statt pollen, und drosseln, bevor es nachgelagert weitergehtVerwenden Sie den Subscription- oder Listener-Node des Pakets mit einem Publishing-Intervall, das zum Bedarf des Verbrauchers passt. Setzen Sie dann einen Rate-Limiter oder einen Aggregations-Node zwischen das Abonnement und jeden Node, der echte Arbeit leistet, denn jede Nachricht läuft in derselben Event-Loop wie der Rest Ihrer Flows.
6. Behandeln Sie den Wiederverbindungsfall als vollwertigen FallVerdrahten Sie den Status-Ausgang des Client-Nodes mit etwas, das protokolliert und alarmiert. Testen Sie, indem Sie den Endpunkt an der Firewall blockieren, und beobachten Sie, ob der Flow von selbst wieder hochkommt oder ein Redeploy braucht, denn die Antwort hängt von Paket und Version ab.
7. Die Daten sofort in dauerhaften Speicher bringenSchicken Sie Nachrichten direkt an einen MQTT-Broker, eine Zeitreihendatenbank oder eine Datei, und legen Sie Transformationen hinter diesen Schritt. Node-RED startet bei jedem Deploy neu, und alles, was in diesem Moment nur im Flow-Kontext liegt, ist weg.

Wie der Adressraum aussieht

Node-RED baut kein Modell auf. Jede Nachricht trägt einen Wert oder ein kleines Bündel, mit dem, was das Node-Paket vom DataValue offenlegt: meist den Wert selbst, manchmal den StatusCode und die Zeitstempel, oft nicht die Typinformation. Die Struktur des Adressraums entdecken Sie je Flow mit einem Browse-Node neu, gespeichert wird sie nicht. Für Prototypen und Verbindungsarbeit ist das akzeptabel, bedeutet aber, dass die Semantik Ihrer Daten im Aufbau des Flows und in Node-Namen steckt, und die ist nicht abfragbar, standardmäßig nicht versioniert und nicht auf die nächste Maschine übertragbar. Wenn dieselbe Zuordnung zweimal verwendet werden soll, erzeugen Sie die NodeId-Liste aus einem Browse und halten Sie sie als Datei, die der Flow liest.

Die Fallen

• Die Community-Nodes sind in Qualität und Pflege nicht einheitlich. Node-Namen, Nachrichtenformate und der Aufbau der Zertifikatsverzeichnisse unterscheiden sich zwischen Paketen und zwischen Versionen desselben Pakets, halten Sie also fest, gegen welches Paket und welche Version ein Flow gebaut wurde.
• Ein in jeden Node kopierter literaler Namespace-Index ist der Standard-Ausfallmodus von Node-RED. Nach einem SPS-Programmdownload liefert der gesamte Flow auf einen Schlag BadNodeIdUnknown, und es gibt keine einzelne Stelle, an der man das repariert.
• Die Zertifikatsbehandlung ist der schwächste Teil der meisten Pakete, und deshalb laufen so viele produktive Node-RED-Collector still mit Security None. Das sollte jemand bewusst entscheiden und nicht als Voreinstellung übernehmen.
• Node-RED ist Single-Threaded. Ein Abonnement mit 50 ms Publishing-Intervall auf einigen hundert Items lässt die Event-Loop verhungern und macht den Editor selbst unbedienbar, und das Symptom sieht wie ein Netzwerkproblem aus.
• Ein Deploy startet die Flows neu und wirft dabei Sessions und Subscriptions ab. Schon eine kleine Dashboard-Änderung unterbricht damit die Erfassung; eine Node-RED-Instanz, die erfasst, sollte deshalb nicht dieselbe sein, an der während der Schicht jemand arbeitet.
• Es gibt kein Store-and-Forward. Wenn die nachgelagerte Senke nicht verfügbar ist, gehen die Nachrichten schlicht verloren, sofern Sie nicht selbst einen Puffer gebaut haben.
• Die serverseitigen Session-Grenzen werden je Client-Node verbraucht, und ein Flow mit mehreren Client-Nodes gegen einen eingebetteten SPS-Server kann sie erschöpfen.

OEE-Daten daraus gewinnen

Node-RED ist ein guter Ort, um zu erkunden, was eine Maschine bereitstellt, und ein schlechter Ort, um OEE zu berechnen. Es kann eine Zustandsvariable, einen Zähler und einen Störgrundcode lesen und weiterleiten, was für einen Proof of Concept oder für eine Maschine, die sonst nichts erreicht, tatsächlich nützlich ist. Was es nicht liefert, ist die Zuverlässigkeit, die die Berechnung braucht: kein dauerhafter Puffer, bei jedem Deploy unterbrochene Erfassung und ein Timing, das von einer Event-Loop abhängt, die sich alles andere in der Instanz teilt. Wenn ein Node-RED-Collector in Produktion geht, beschränken Sie ihn auf eine einzige Aufgabe, bringen Sie die Werte mit unverändertem Server-Zeitstempel sofort zu einem Broker oder in eine Datenbank und berechnen Sie Verfügbarkeit, Leistung und Qualität nachgelagert, wo eine Lücke sichtbar und neu verarbeitbar ist. Geplante Produktionszeit, Schichtkalender und Standard-Taktzeiten stehen nicht in der Maschine und sollten nicht in einen Flow hartcodiert werden.

Zuletzt geprüft am 7. September 2026 gegen OPC UA 1.05.07. OPC UA Connect ist ein unabhängiges Bildungsangebot und steht in keiner Verbindung zur OPC Foundation.