OPC UA an Azure IoT Edge / OPC Publisher anbinden
| Produkt | Azure IoT Edge / OPC Publisher |
|---|---|
| Kategorie | Cloud |
| OPC-UA-Rolle | Client |
OPC Publisher ist ein OPC-UA-Client, der als IoT-Edge-Modul läuft, die in einer Konfigurationsdatei aufgelisteten Knoten abonniert und sie als JSON an Azure IoT Hub weiterleitet. Es ist der am besten dokumentierte Weg von OPC UA in die Cloud, und sein schwerstes Problem sind Zertifikate, nicht Code.
Bevor Sie starten
- Eine IoT-Edge-Runtime auf einem Gateway, das sowohl die OPC-UA-Server als auch die Cloud erreicht.
- Eine published-nodes-Konfigurationsdatei, die die Endpunkte und NodeIds auflistet, die abonniert werden sollen.
- Ein Plan dafür, wie dem Zertifikat des Publishers auf jedem Server, mit dem er spricht, vertraut wird. Das ist der Teil, der Rollouts verzögert, nicht der Container.
- Ausgehende Netzverbindung vom Gateway. Die OPC-UA-Seite ist aus Sicht des Publishers nur eingehend, deshalb passt sie in ein geschichtetes Netz.
Die Einrichtung
- Die published-nodes-Datei schreibenEin Eintrag je Endpunkt, jeweils mit einer Liste von NodeIds, deren Publishing- und Abtastintervallen und optionalem Deadband. Hinterlegen Sie die Namespace-URI in der NodeId, wo die Syntax es erlaubt, statt eines rohen Index, damit ein SPS-Download die Erfassung nicht stillschweigend zerstört.
- Modul ausrollenRollen Sie es als IoT-Edge-Modul aus, mit der Konfigurationsdatei und einem persistenten Volume für das PKI-Verzeichnis. Das Volume ist nicht optional - siehe die Stolperfallen.
- Dem Publisher auf jedem Server vertrauenBei der ersten Verbindung landet das Zertifikat des Publishers im Rejected-Store jedes Servers. Ein Administrator verschiebt es nach Trusted, auf jedem Server. Planen Sie dafür über einen Maschinenpark hinweg echte Zeit ein, oder führen Sie vorher ein Zertifikatsmanagement ein.
- Die Codierung bewusst wählenDer Publisher kann reversibles oder nicht reversibles JSON ausgeben. Nicht reversibel ist kleiner und leichter zu lesen, verwirft aber Typinformationen und lässt sich nicht zurückwandeln. Entscheiden Sie das, bevor nachgelagerte Konsumenten dagegen geschrieben werden.
- Prüfen Sie, was ankommtSehen Sie sich die Nachrichten im IoT Hub an und bestätigen Sie, dass StatusCode und SourceTimestamp erhalten geblieben sind. In der JSON-Codierung ist ein Good-Status 0 und wird vollständig weggelassen, ein fehlendes Statusfeld bedeutet also Good und nicht fehlende Daten - der nachgelagerte Code muss in diesem Wissen geschrieben sein.
- Optimieren Sie, bevor Sie skalierenSetzen Sie Publishing-Intervalle auf das, was der Cloud-Consumer braucht, und nicht auf das Schnellste, was die SPS hergibt, legen Sie Totbänder auf Analogwerte und halten Sie die Zahl unterschiedlicher Intervalle klein. Jedes unterschiedliche Intervall wird zu einer weiteren Subscription auf dem Server.
Wie der Adressraum aussieht
Der Publisher modelliert nichts - er leitet die Knoten weiter, die Sie auflisten. Die Semantik bleibt dort, wo Sie sie hinlegen, was in der Praxis heißt: Entweder tragen die Node-IDs per Konvention Bedeutung, oder etwas Nachgelagertes hängt sie wieder an. Implementiert die Maschine eine Companion Specification, geht diese Struktur verloren, sofern Sie sie nicht in Ihrer Topic- oder Tag-Benennung codieren.
Die Fallen
- Ein nicht persistentes PKI-Volume erzeugt das Anwendungszertifikat bei jedem Container-Neustart neu, sodass die Vertrauensliste jedes Servers bei jedem Deploy veraltet. Das ist der mit Abstand häufigste Deployment-Fehler beim OPC Publisher.
- Die Dokumentation sagt unmissverständlich, dass es für die meisten OT-Administratoren die größte Hürde ist, Geräte dazu zu bringen, das Zertifikat des Publishers zu akzeptieren. Behandeln Sie das als Projektaufgabe mit einem Verantwortlichen, nicht als Konfigurationsdetail.
- Nicht umkehrbares JSON verliert stillschweigend Typinformationen. Ein nachgelagerter Consumer kann einen Int32 nicht von einem Double unterscheiden, was in dem Moment zählt, in dem jemand rechnet.
- Reverse Connect wird nur für opc.tcp unterstützt, und der Publisher lauscht dafür auf einem konfigurierbaren Port. Nützlich durch ein nach Purdue geschichtetes Netz, in dem nur ausgehende Verbindungen erlaubt sind.
- Fest codierte Namespace-Indizes in einer published-nodes-Datei brechen nach einem SPS-Programm-Download. Verwenden Sie Namespace-URIs, wo die Node-ID-Syntax es zulässt.
OEE-Daten daraus gewinnen
Verfügbarkeit, Stückzahlen und Störgründe gelangen alle in die Cloud, wenn die Maschine sie bereitstellt, aber der Publisher leitet Werte weiter, statt sie zu interpretieren. Übergänge der Zustandsmaschine kommen als Wertänderungen an, die Dauerberechnung passiert also nachgelagert und hängt von Ihrem Publishing-Intervall ab - ein Intervall von 10 Sekunden kann einen Kurzstillstand von 3 Sekunden nicht auflösen. Abonnieren Sie für Stillstandsgründe die Condition Events aus Part 9, statt ein Störgrundregister zu pollen. Geplante Produktionszeit und Auftragskontext stehen nicht in der Maschine und werden hier nicht erscheinen.
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.