OPC UA mit Mosquitto / MQTT-Broker verbinden

Bevor Sie starten

• Etwas, das tatsächlich OPC UA spricht: ein Publisher, ein Collector oder ein Gateway. Der Broker ist ein Ziel, kein Client, und keine Broker-Konfiguration bringt eine SPS zum Publizieren.
• Eine Entscheidung über das Payload-Format, bevor das erste Topic existiert. OPC UA PubSub über MQTT mit JSON ist der normbasierte Weg; das eigene JSON-Schema eines Collectors und Sparkplug B sind die verbreiteten Alternativen, und sie sind nicht austauschbar.
• Eine Namenskonvention für Topics, abgestimmt mit denjenigen, die sie konsumieren werden, denn der Topic-Baum ist der Vertrag, und ihn später umzubenennen bricht alle Subscriber auf einmal.
• TLS mit echten Zertifikaten und konfigurierter Authentifizierung, bevor irgendetwas Produktives veröffentlicht. Ein offener Broker in einem Anlagennetz ist eine offene Anlage.

Die Einrichtung

1. Den Broker zuerst für TLS und Authentifizierung konfigurierenSetzen Sie einen expliziten Listener, deaktivieren Sie anonymen Zugriff, konfigurieren Sie Anmeldedaten oder Client-Zertifikate und ergänzen Sie eine Topic-Zugriffssteuerung je Client. Das zu tun, bevor es überhaupt einen Publisher gibt, ist wesentlich einfacher, als es später über eine Flotte von Publishern nachzurüsten.
2. Entwerfen Sie die Topic-Hierarchie aus der Anlage heraus, nicht aus dem AdressraumEin Topic-Baum, der mechanisch aus OPC-UA-Browse-Pfaden abgeleitet ist, ist bequem und erzeugt Topics, die niemand sinnvoll abonnieren kann. Leiten Sie ihn aus Standort, Bereich, Linie und Maschine ab und setzen Sie den Signalnamen ans Blatt. Wo ein Publisher automatisches Routing aus BrowseNames anbietet, beachten Sie, dass für MQTT reservierte Zeichen escaped werden müssen, und prüfen Sie, was der Publisher damit macht.
3. Payload-Codierung wählen und festschreibenWenn Sie OPC UA PubSub über MQTT nutzen, entscheiden Sie zwischen UADP und JSON und, bei JSON, zwischen reversibler und nicht reversibler Form. Nicht reversibles JSON verliert die Typinformation und lässt sich nicht zurückwandeln, eine Überraschung, die Monate später bei einem nachgelagerten Verbraucher eintrifft.
4. Entscheiden Sie über Retained Messages und Last Will je Topic-KlasseRetained Messages geben einem neuen Subscriber sofort den aktuellen Wert, was für Zustand und Identität richtig ist und für Events falsch, wo eine Retained Message etwas wiedergibt, das bereits geschehen ist. Konfigurieren Sie ein Last-Will-Topic je Publisher, damit ein ausgefallener Collector sichtbar wird.
5. Quality of Service an die Bedeutung der Daten anpassenQuality of Service 0 ist in Ordnung für einen hochfrequenten Analogwert, den Sie ohnehin neu abtasten, und inakzeptabel für ein Stillstandsereignis oder eine Zählerinkrementierung, denn ein Netzwerkaussetzer verliert sie schlicht. Verwenden Sie At-least-once für alles, worauf eine Berechnung aufbaut, und machen Sie die Verbraucher idempotent.
6. Prüfen Sie den Payload mit einem Client, bevor Sie Consumer bauenAbonnieren Sie mit MQTT Explorer oder einem Kommandozeilen-Client und lesen Sie die tatsächlichen Bytes auf der Leitung. Beachten Sie insbesondere, dass in der OPC-UA-JSON-Codierung ein Good-Status der Nullwert ist und weggelassen wird: ein fehlendes Statusfeld bedeutet also gut und nicht fehlende Daten.
7. Broker und Publisher getrennt überwachenBeobachten Sie die Verbindungszahlen und verworfenen Nachrichten des Brokers und alarmieren Sie auf die Erreichbarkeit der Publisher über Last-Will-Topics oder ein Heartbeat-Topic je Maschine. Stille auf einem Topic ist mehrdeutig und braucht ein unabhängiges Signal zur Deutung.

Wie der Adressraum aussieht

MQTT hat kein Modell, nur einen Topic-String und einen Payload, also muss alles, was der OPC-UA-Adressraum wusste, von der publizierenden Instanz neu ausgedrückt werden. Das ist die zentrale Entwurfsentscheidung eines Unified Namespace: Die Topic-Hierarchie plus das Payload-Schema sind für jeden Consumer das gesamte Informationsmodell. OPC UA PubSub überträgt Dataset-Metadaten zusammen mit den Daten, was Typen und Feldnamen erhält und der Grund ist, warum der standardbasierte Weg den zusätzlichen Konfigurationsaufwand wert ist; das JSON eines Ad-hoc-Collectors tut das meist nicht, und dann liegt die Bedeutung eines Feldes in irgendeinem Dokument. Was Sie auch wählen: Veröffentlichen Sie die OPC-UA-Namespace-URI und den Node-Identifier im Payload oder in den Topic-Metadaten, damit ein Wert auf den Knoten zurückverfolgt werden kann, aus dem er stammt.

Die Fallen

• Den Broker für die Integration zu halten ist der klassische Fehler. Der Broker bewegt Bytes; die Semantik kommt aus dem Topic- und Payload-Entwurf des Publishers, und in diesem Entwurf steckt die eigentliche Projektarbeit.
• Quality of Service 0 auf ereignisartigen Daten verliert Ereignisse stillschweigend genau unter den Netzbedingungen, die die interessantesten Ereignisse erzeugen. Stillstandsdatensätze und Zählerinkremente brauchen At-least-once-Zustellung.
• Retained Messages auf Event-Topics spielen jedem neuen Subscriber veraltete Events vor, was Konsumenten beschädigt, die annehmen, eine Nachricht bedeute jetzt.
• Die nicht umkehrbare JSON-Codierung verliert Typinformationen und lässt sich nicht zurückwandeln. Entscheiden Sie bewusst und halten Sie die Entscheidung fest; sie erst nachgelagert zu bemerken ist teuer.
• In der JSON-Codierung von OPC UA ist ein Good-Status null und wird weggelassen, ein Konsument, der ein fehlendes Statusfeld als fehlende Daten behandelt, verwirft also gute Werte.
• Topic-Bäume, die automatisch aus Browse-Pfaden abgeleitet werden, codieren die interne Struktur der SPS in Ihren werksweiten Namespace, und sie ändern sich, wenn sich das SPS-Programm ändert.
• Der Broker wird zum werksweiten Single Point of Failure und zur werksweiten Sicherheitsgrenze. Clustern Sie ihn oder akzeptieren Sie das Risiko ausdrücklich, und lassen Sie anonymen Zugriff nie aktiviert, nur weil er bei der Inbetriebnahme bequem war.
• MQTT garantiert keine Reihenfolge über verschiedene Topics hinweg. Ein Zustandswechsel und die dazugehörige Stückzahl können in falscher Reihenfolge ankommen, wenn sie auf getrennten Topics veröffentlicht werden; legen Sie deshalb Fakten, die zusammenpassen müssen, in eine Nachricht.

OEE-Daten daraus gewinnen

Der Broker trägt von sich aus nichts zur OEE bei und kann sie unbemerkt beschädigen. Gut kann er die Entkopplung von Erfassung und Berechnung: Eine Analyseplattform kann Maschinenzustand, Stückzahlen und Störgründe konsumieren, ohne zu jeder SPS eine Session zu halten. Die Anforderungen, die er stellt, sind konkret: Zustandsübergänge als Events mit dem maschineneigenen Zeitstempel im Payload veröffentlichen statt sich auf die Ankunftszeit zu verlassen, Zählerinkremente oder absolute Zähler mit genug Kontext veröffentlichen, um Resets zu erkennen, für beides At-least-once-Zustellung verwenden und jeder Maschine ein Heartbeat- oder Last-Will-Topic geben, damit sich Stille von einer stehenden Maschine unterscheiden lässt. Geplante Produktionszeit, Schichtkalender, Auftragskontext und Standard-Taktzeiten sind keine Maschinendaten und sollten aus MES oder ERP in die Berechnung gelangen, nicht dadurch, dass sie einmal von Hand auf ein Topic veröffentlicht und dann vergessen 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.