Unified Namespace anbinden: Daten einspeisen und zurückschreiben

Aus Steuerungen und Altanlagen auf der Seite der Betriebstechnologie (OT) und aus Datenbanken und SAP auf der IT-Seite, also aus Systemen, die MQTT nicht unbedingt selbst sprechen. Der erste Schritt ist deshalb eine Bestandsaufnahme: Welche Quelle erreicht man auf welchem Weg?

Welches Werkzeug diese Wege herstellt, hängt davon ab, worauf der Namensraum läuft. Steht er für sich, etwa auf einem eigenen Broker, ist das der OPC Router als eigenständige Middleware vor Ort; die Tabelle nennt seine Wege. Läuft der Unified Namespace auf der pronubes-Plattform, übernimmt pronubes Edge diese Aufgabe. Es ist dort die Verbindungsschicht zwischen den lokalen Systemen und der Plattform, mit Instanzen an den Standorten. Welches von beiden, entscheidet die Rolle. Die Tabelle und die folgenden Abschnitte beschreiben den OPC Router nach seinem Handbuch.

Vom Broker lesen die Abnehmer: ein MES, ein SCADA, Dashboards, und aus derselben Produktfamilie manubes für Transparenz und Produktionsmanagement aus der Cloud sowie pronubes zum Auswerten der Daten und Automatisieren von Prozessen. Beide abonnieren Topics am Broker.

Für Maschinen, die gar keine Schnittstelle haben, hilft keine Middleware. Dort geht es um Nachrüstsensorik, und die beschreibt Legacy-Maschinen per OPC UA anbinden.

Aus der Praxis: Laut der Anwenderübersicht auf opc-router.de (Stand der Seite: Juli 2026) sammelt ein Hersteller von Schmiedeteilen seine Werte von einem OPC-Server und veröffentlicht sie über MQTT. Als Nutzen nennt der Eintrag, dass die Prozessdaten damit „leicht für andere Systeme zugänglich“ sind. Ein Hersteller von Haftnotizen leitet auf demselben Weg Produktionsdaten an sein MES und sein SCADA weiter und wertet sie zusätzlich mit KI aus. Beide Einträge sprechen nicht von einem Unified Namespace. Sie zeigen aber das Muster, auf dem er beruht: einmal veröffentlichen, mehrfach lesen.

Über einen Flow im OPC Router: Ein Trigger löst ihn aus, das MQTT-Transferobjekt veröffentlicht den Wert am Broker. Bei Steuerungswerten ist der Trigger meist der Data-Change-Trigger des OPC Client. Er löst bei Wertänderung aus, gesendet wird also, was sich ändert. „Metadaten ausgeben" gibt Zeitstempel und Qualität mit.

Das MQTT-Transferobjekt gehört zum MQTT-Plug-in des OPC Routers. Dort wird das Topic festgelegt, also der Name im Namensraum, dazu die Servicequalität und die Frage, ob der Broker den Wert halten soll. Drei Einstellungen tragen dabei den größten Teil der UNS-Logik:

• Retain veranlasst den Broker, die Nachricht als letzte bekannte für dieses Topic zu speichern. Ein neuer Abonnent erhält sie sofort. Das ist der Mechanismus hinter dem Satz, der Namensraum halte den aktuellen Wert. Eine Langzeithistorie ersetzt das nicht; sie liegt typischerweise in einem Historian, einer Zeitreihendatenbank oder einem Data Lake.
• Dynamisches Topic setzt den Namen zur Laufzeit aus einem Eingabewert. Ein Flow kann damit viele Maschinen bedienen.
• Servicequalität kostet Durchsatz. In einer Messreihe des Herstellers lag QoS 1 rund 11 % unter QoS 0, QoS 2 rund 37 %. Die Bedingungen gehören dazu: eine frühere Version des OPC Routers, 100 parallele Transfer-Flows ohne Verbindungspool, lokaler Broker, Windows Sandbox mit 4 GB, 100 Byte Nutzlast. Das Handbuch nennt die Zahlen ausdrücklich ein Verhältnis der Varianten und keine Leistungsgrenze. Die Empfehlung daraus: QoS 0 für zyklische Telemetrie, QoS 1 als Standard, QoS 2 nur, wo eine Dopplung fachlich ausgeschlossen sein muss. QoS 2 steht dabei für genau einmalige Zustellung zwischen Broker und Router; gegen Dopplung durch überlappende Subscriptions wirkt es nicht.

Unter MQTT 5 lassen sich Benutzereigenschaften mitgeben, etwa eine Schemaversion. Das Handbuch hält dazu fest, dass Fachdaten in den Payload oder in die Topic-Struktur gehören, nicht in diese Zusatzfelder. Für den Payload selbst prüft das JSON-Schema-Plug-in eingehende Daten und erzeugt ausgehende nach Schema, wahlweise gegen eine feste Schemaversion.

Wie ein veröffentlichter Wert aussehen kann, zeigt ein Beispiel einer Projektierung. Der Flow legt den Wert und die Angaben aus „Metadaten ausgeben" in ein JSON-Dokument und veröffentlicht es auf dem Topic des Messwerts, hier werk-nord/halle-2/linie-3/fueller/temperatur:

Feldnamen und Aufbau legt die Projektierung fest. Das MQTT-Transferobjekt sendet den Inhalt als String oder Byte-Array und schreibt kein Format vor.

Und Sparkplug? Sparkplug B gibt MQTT-Nachrichten eine feste Struktur für Zustände, Messwerte und Lebenszeichen. Dafür schreibt es den Pfad vor: spBv1.0////. Ein frei gewählter Pfad nach der Anlagenhierarchie aus ISA-95, etwa Enterprise / Site / Area / Line / Cell, und Sparkplug B schließen sich deshalb aus. Beides zusammen erfordert eine Abbildungsregel, welche Ebene auf die Group ID, welche auf den Node und welche in den Metriknamen geht. Das Sparkplug-Plug-in des OPC Routers veröffentlicht im Profil „Node" und setzt dort Group ID und Node ID als Vorgabe, die sich je Transferobjekt überschreiben lassen. Sein zweites Profil, „Application", gehört zum Rückweg.

Über einen Flow, der am Broker beginnt. Der MQTT-Trigger des OPC Routers, „MQTT-Subscribe", abonniert ein Topic oder, je nach Broker, ein Muster mit Wildcards. Jede eingehende Nachricht löst den Flow aus, und ihr Inhalt steht darin als String oder als Byte-Array zur Weiterverarbeitung bereit. Ist der Inhalt ein JSON-Dokument, wertet das Transferobjekt „JSON lesen" die Felder per JMESPath aus. Dasselbe JSON-Schema-Plug-in, das beim Einspeisen ausgehende Dokumente erzeugt, prüft eingehende, ausdrücklich auch solche über MQTT. Am Ende des Flows schreibt ein Transferobjekt ins Ziel. Die Brokeranbindung kann dieselbe sein wie beim Einspeisen. Systeme ohne MQTT sind so Abnehmer des Namensraums, ohne selbst am Broker zu hängen.

Dieser Weg ist das letzte Stück eines größeren Kreislaufs. Wie Produktionsdaten zu Entscheidungen werden, die in die Produktion zurückgehen, beschreibt pronubes als geschlossenen Regelkreis: Was ist data-driven production? Hier geht es um die Technik darunter, also darum, wie ein Wert aus dem Namensraum an seinem Ziel ankommt und wie der Absender erfährt, ob er angekommen ist.

Welche Ziele ein solcher Flow beliefert, hängt von seinen Transferobjekten ab. Die Seite des MQTT-Plug-ins nennt als Beispiele MQTT an OPC UA, an SAP, zu SQL und an REST:

Dieselbe Anwenderübersicht beschreibt Wege in solche Ziele, allerdings ohne Broker. Ein Pumpenhersteller in Finnland bringt mit dem OPC Router Produktionsplanungsdaten aus dem ERP in die SPS, und der OPC Router meldet die Aktivität an das ERP zurück. Ein österreichisches Chemieunternehmen setzt ihn in mehreren Werken als Datendrehscheibe ein: Die Daten kommen über OPC UA aus der Produktion, und je nach Standort sind REST, InfluxDB, SAP oder Drucker angebunden. Einen Fall, in dem der OPC Router Daten aus einem Broker abonniert und weiterschreibt, enthält die Übersicht nicht.

In die Steuerung: Aufträge und Sollwerte mit Quittung

Auch eine Steuerung kann das Ziel sein. Der OPC Router schreibt dann über einen OPC-Server wie Kepware oder über den OPC-UA-Server der Steuerung, also auf demselben Weg, auf dem er beim Einspeisen liest. Dafür stehen diese Transferobjekte bereit:

• OPC Data Access schreibt aktuelle Werte auf Datenpunkte, bei OPC Classic und OPC UA. Stehen die Datenpunkte erst zur Laufzeit fest, schreibt OPC Dynamic Write auf die übergebenen Pfade.
• OPC-Strukturen schreibt eine OPC-UA-Struktur, etwa einen Auftrag, den die SPS als Struktur definiert.
• OPC-Methoden ruft eine Methode in der Steuerung auf und erhält ihre Rückgabewerte. Das setzt OPC UA voraus und eine Steuerung, die die Methode anbietet.
• OPC Message bündelt die zu schreibenden Daten in einem Request mit einer MessageID, die der OPC Router bei jedem Transfer hochzählen kann. Mit „Auf Antwort warten" wartet er, bis die Steuerung die Verarbeitung über einen Response-Datenpunkt bestätigt. Bleibt die Bestätigung innerhalb des Antwort-Timeouts aus, gilt der Transfer als fehlgeschlagen und bricht ab.

Für Aufträge und Sollwerte ist OPC Message der Weg mit Quittung. Es ist der Handshake, den der SPS-Artikel für die Gegenrichtung beschreibt, mit vertauschten Rollen: Der OPC Router schreibt den Datensatz und meldet ihn über den Sendedatenpunkt, die Steuerung verarbeitet ihn in ihrem Programm und bestätigt über den Response-Datenpunkt. Die Verarbeitung liegt damit in der Steuerung. Steuerbefehle an laufende Prozesse gehören nicht auf diesen Weg. Auch manubes.de rät, Prozesse mit sehr hohen Anforderungen an Reaktionszeiten, Zuverlässigkeit und Ausfallsicherheit, etwa in der Produktionssteuerung oder bei sicherheitsrelevanten Anwendungen, vor einer Integration in den Namensraum sorgfältig zu prüfen; dort werden oft weiterhin direkt angebundene Systeme bevorzugt.

Welche Systeme schreiben dürfen, legt der Betreiber fest. Die Mittel dafür liegen am Broker, für den die MQTT-Spezifikation Zugriffsrechte je Topic empfiehlt, und in der Steuerung oder im OPC-Server, wo OPC UA Schreibrechte je Benutzer vorsieht. Die Sparkplug-Spezifikation nennt für Befehle drei Stellen: Zugriffsregeln am Broker, Rechte in der sendenden Anwendung und den Edge Node, der entscheidet, ob er einen Befehl ausführt.

Sparkplug als Abnehmer

Auch Sparkplug B geht in beide Richtungen. Eine Sparkplug-Anbindung des OPC Routers meldet sich in einem von zwei Profilen am Broker an. Im Profil „Node" betreibt der OPC Router einen Edge Node: Er veröffentlicht Werte und nimmt mit dem Sparkplug Command Trigger Befehle an, die eine Anwendung an ihn schickt, in Sparkplug B die Nachrichtentypen NCMD für den Node und DCMD für ein Gerät. Im Profil „Application" steht er auf der Gegenseite: Der Trigger für Knoten- und Gerätedaten löst aus, wenn ein angebundenes Gerät seine Daten ändert, und das Transferobjekt Application Command schickt Befehle an Sparkplug-Nodes, adressiert über Group ID, Node ID und wahlweise Device ID.

Eine eigene Quittung für Befehle definiert Sparkplug B nicht. Nach der Spezifikation schreibt ein Edge Node einen empfangenen Befehl über das native Protokoll in die Steuerung, und bestätigt wird mittelbar: Ändert sich der Ausgang, veröffentlicht der Node den neuen Wert als DATA-Nachricht. Was bei einem gescheiterten Schreibvorgang geschieht, regelt die Spezifikation nicht.

Wie erfährt der Absender, ob ein Befehl angekommen ist?

Aus der MQTT-Quittung nicht. Der MQTT-Trigger quittiert eine Nachricht gegenüber dem Broker, sobald er den Transfer eingereiht hat, mit „Warte auf Transfer" erst nach dessen Ende. In beiden Fällen meldet die Quittung laut Handbuch nur, dass der Router die Nachricht abgeschlossen hat. Das Ergebnis des Transfers enthält sie nicht, und auch ein fehlgeschlagener Transfer wird dem Broker nicht als Fehler gemeldet. Der Sparkplug Command Trigger quittiert ein Kommando nie.

Die fachliche Rückmeldung ist deshalb eine eigene Nachricht, die im Flow projektiert wird:

• Unter MQTT 5 legt der Absender ein Antwort-Topic und Korrelationsdaten in seine Anfrage. Der MQTT-Trigger kann beide an den Flow ausgeben, und das MQTT-Transferobjekt hat eine Option, die Nachricht an ein Antwort-Topic zu senden statt an das eingestellte Topic. Das setzt voraus, dass die Brokeranbindung auf MQTT 5 steht und der Broker diese Version unterstützt.
• Unter MQTT 3.1.1 gibt es diese Eigenschaften nicht. Kennung und Antwort-Topic gehören dann in den Payload, so wie es AWS für Befehle auf seiner IoT-Plattform beschreibt.
• Bei Sparkplug veröffentlicht ein zusätzliches Transferobjekt „Sparkplug Node Publish" im selben Flow eine Rückmeldung. Laut Handbuch geschieht das mitten im Flow, unabhängig vom Transferergebnis und ohne Bezug zum auslösenden Kommando.

Soll die Rückmeldung auch einen Fehlschlag melden, gehört der Schreibschritt in ein Try/Catch-Transferobjekt, und der CATCH-Zweig veröffentlicht die Fehlermeldung. Ohne diese Klammer endet der Transfer beim fehlgeschlagenen Schritt, und das Transferobjekt, das die Quittung senden sollte, läuft nicht mehr. Für jeden Aufruf des TRY-Zweigs gilt ein festes Zeitlimit von 30 Sekunden. Das Antwort-Timeout von OPC Message muss deshalb darunter liegen. Braucht die Steuerung für die Bestätigung länger, gilt der Versuch als fehlgeschlagen, und der CATCH-Zweig meldet einen Fehler, während die Steuerung den Auftrag womöglich noch verarbeitet.

Ein Beispiel einer Projektierung für diese Richtung: Ein Auftrag für den Füller auf Linie 3 kommt als JSON-Dokument auf einem eigenen Befehls-Topic an, mit einer Kennung, die in der Quittung zurückkommt:

Der Flow schreibt Auftrag und Sollmenge per OPC Message in die Steuerung und veröffentlicht nach deren Bestätigung auf dem Antwort-Topic:

Im CATCH-Zweig steht an derselben Stelle "ergebnis": "fehler" samt Fehlermeldung. Auch hier legt die Projektierung Felder und Topics fest.

Schneiden muss ihn die Organisation. Welche Ebene die zentrale IT festlegt und welche das Werk, zeigt die Tabelle auf pronubes.com; die Namensregeln stehen dort ebenfalls.

Keine Software nimmt diese Entscheidung ab.

Die Middleware übernimmt den zweiten Teil: sie legt den Namen nicht fest, sie hält ihn durch. Im OPC Router steht die Konvention als Vorlagenvariable im Topic. Die konkreten Werte je Maschine stehen als Zeile in einer CSV- oder Excel-Datei, aus der die Instanzen erzeugt werden. Ändert sich der feste Teil der Konvention, genügt eine Änderung an der Vorlage; die Instanzen werden danach neu produktiv geschaltet. Ändert sich der Name einer einzelnen Maschine, betrifft das ihre Zeile in der Datei, nicht die Vorlage. Was eine Umbenennung auf der Abnehmerseite kostet, steht in den Fragen auf pronubes.com.

Zur Konvention gehört auch, wo Befehle liegen. Sparkplug B führt Daten und Befehle als eigene Nachrichtentypen im Pfad, NDATA und DDATA für Werte, NCMD und DCMD für Befehle. Die Spezifikation begründet mit dieser Entkopplung, dass sich das Senden von Befehlen per Zugriffsregel am Broker auf bestimmte Anwendungen beschränken lässt. AWS empfiehlt für seine IoT-Plattform, Daten- und Befehls-Topics schon an der ersten Ebene zu unterscheiden. Auf einen Namensraum nach der Anlagenhierarchie lässt sich beides als Analogie übertragen; wo die Befehle darin liegen, entscheidet die Konvention. Getrennte Topics sind die Voraussetzung dafür, Schreibrechte je Topic zu vergeben.

Dass ein Livewert erst mit Stammdaten lesbar wird, beschreibt pronubes.com als eigenen Schritt. Hier geht es darum, woher sie kommen: nicht aus der Steuerung, sondern aus MES, ERP oder einer Datenbank.

Im OPC Router lässt sich das in einem Flow zusammenführen: Der Livewert löst aus, ein Datenbankzugriff oder ein SAP-Aufruf holt den Auftragsbezug, und beides wird als ein JSON-Dokument veröffentlicht. Die einzelnen Bausteine sind dokumentiert, die Kombination ist eine Frage der Projektierung. Die MQTT-Datenspeicherung hält zudem je Topic die zuletzt empfangene Nachricht auf der Festplatte. Ein anderer Flow kann sie lesen und mit einem eigenen Trigger kombinieren.

Doppelte Zeilen in der Datenbank, ein Dashboard mit eingefrorenem Druckwert, eine Maschine, die unter falschem Namen sendet, ein Auftrag, der ein zweites Mal in der Steuerung ankommt, und einer, der nie ankommt: Diese Fehlerbilder folgen aus der Bauart von MQTT und des Namensraums und treten zum größten Teil unabhängig vom eingesetzten Produkt auf.

Eine Nachricht löst zweimal aus, oder gar nicht

Das Fehlerbild: Ein Flow schreibt dieselbe Meldung zweimal in die Datenbank. Oder ein Flow, der gestern lief, löst heute gar nicht mehr aus.

Die Ursache: In einem Namensraum liegen Wildcards nahe. Ein Flow abonniert werk-nord/halle-2/#, ein zweiter ein einzelnes Topic darunter. Beim Broker sind das zwei getrennte Subscriptions. Ob der Broker eine passende Nachricht dann einmal oder je Subscription einmal zustellt, lässt die MQTT-Spezifikation offen, in Version 3.1.1 wie in 5.

Woran es sich zeigt: an doppelten Zeilen mit gleichem Inhalt und fast gleicher Ankunftszeit, oder an Triggern im Zustand Konfigurationsfehler, die das betroffene Topic nennen. Der zweite Fall geht auf eine Eigenheit des OPC Routers zurück, siehe unten.

Was beim Betrieb liegt. Vor der Inbetriebnahme prüfen, wie der eingesetzte Broker bei überlappenden Mustern zustellt. Flows an QoS-1-Triggern so bauen, dass sie eine mehrfache Ausführung vertragen, denn bei QoS 1 darf der Broker ohnehin wiederholen.

Im OPC Router. Läuft die Brokeranbindung mit MQTT 5 und liefert der Broker die Subscription-Kennung mit, ordnet der Router laut Handbuch jede Zustellung ihrer Subscription zu und löst einen Flow auch bei überlappenden Mustern nur einmal aus, außer die MQTT-Datenspeicherung ist aktiv: dann wird die Kennung nicht ausgewertet. Eingestellt wird das im Feld „MQTT-Version“ der Brokeranbindung. Die MQTT-Datenspeicherung abonniert werkseitig das Muster # und überlappt damit mit jedem Trigger; ihre Muster gehören im Abschnitt „Storage“ auf die benötigten Topics beschränkt. Als letztes Mittel gibt es im Abschnitt „Erweitert“ die Nachrichtendeduplizierung mit einem Zeitfenster von standardmäßig 3 Sekunden. Sie ist werkseitig aus, weil sie auch echte Wiederholungen mit gleichem Inhalt verwirft. Außerdem wirkt sie nur je Brokeranbindung.

Eine Eigenheit des OPC Routers. Überwachen mehrere Flows über dieselbe Brokeranbindung dasselbe Topic, wartet einer davon auf den Transfer und kommt die Nachricht mit QoS über 0, löst laut Handbuch keiner mehr aus. Alle beteiligten Trigger gehen in den Konfigurationsfehler, und ein einzelner wartender Trigger genügt dafür. Abhilfe schafft, eine der drei Bedingungen aufzulösen: „Warte auf Transfer“ bei allen Triggern dieses Topics ausschalten, das Topic nur in einem Flow überwachen oder dafür sorgen, dass die Nachricht mit QoS 0 ankommt.

Ein stiller Ausfall sieht aus wie ein ruhiger Wert

Das Fehlerbild: Das Dashboard zeigt seit Stunden denselben Druck. Die Anlage scheint ruhig zu laufen. Tatsächlich ist die Quelle seit Stunden weg.

Die Ursache: Retain ist gewollt. Jeder neue Abonnent soll den letzten Wert sofort bekommen. Fällt die Quelle aus, bleibt genau dieser Wert beim Broker stehen, und ein unveränderter Wert ist von einem veralteten nicht zu unterscheiden. Das ist ein anderes Problem als die Lücke in der Historie, die der SCADA-Artikel beschreibt. Das Symptom selbst, die Kennzahl, die stehen bleibt, obwohl die Anlage läuft, beschreibt Was ist ISA-95? samt den Feldern am Trigger, und pronubes.com führt es unter den typischen Fallstricken. Hier geht es um das, was der Namensraum dazulegt: den Wert, den der Broker hält.

Woran es sich zeigt: am Wert selbst nicht. Erst der Vergleich seines Zeitstempels mit der aktuellen Zeit zeigt, wie alt er ist.

Was beim Betrieb liegt. Ein Status-Topic je Quelle in die Namenskonvention aufnehmen, und die Abnehmer so bauen, dass sie das Alter eines Werts auswerten statt nur den Wert. Das ist eine Entscheidung über den Namensraum und keine Einstellung.

Im OPC Router. In der Plug-in-Konfiguration lassen sich ein First Will und ein Last Will hinterlegen, jeweils mit Retain. Naheliegend ist, beide auf dasselbe Status-Topic zu legen: online beim Verbinden, offline beim Abriss. Der Last Will meldet allerdings nur den Abriss zwischen Router und Broker, nicht den Ausfall einer Steuerung hinter dem OPC-Server. Den zeigt die Qualität, die „Metadaten ausgeben“ am Data-Change-Trigger zusammen mit dem Zeitstempel mitsendet; „Triggern bei Quality-Änderung“ löst auch dann aus, wenn sich nur die Qualität ändert. Der Data-Change-Missing-Trigger löst aus, wenn sich ein Datenpunkt innerhalb eines Prüfzeitraums nicht ändert. Die Felder dazu beschreibt Was ist ISA-95? Vorsicht bei zwei Einstellungen, die einen veralteten Wert frisch aussehen lassen können: „Mindestens alle“ überträgt den aktuellen Wert periodisch, bei einer eingefrorenen Quelle also den eingefrorenen. Es taugt nur zusammen mit „Metadaten ausgeben“ und einem Abnehmer, der den mitgesendeten Zeitstempel auswertet. „Publish known Devicemetrics on reconnect“ im Sparkplug-Plug-in veröffentlicht bekannte Metriken nach dem Wiederverbinden erneut, mit demselben Risiko. Im selben Plug-in fügt „Add Session Number to Device Birth and Death“ die aktuelle Sitzungsnummer zu den Meldungen bei Device Birth und Death hinzu.

Der Broker nimmt jeden Tippfehler an

Das Fehlerbild: Eine Maschine fehlt in der Auswertung, obwohl sie sendet. Sie sendet nur unter einem anderen Namen.

Die Ursache: Die eigene Seite Was ist MQTT? hält es fest: Der Broker akzeptiert jedes gültige Topic ohne vorherige Initialisierung und unterscheidet Groß- und Kleinschreibung; werk1/halle1 und Werk1/Halle1 sind zwei verschiedene Topics. Beim Anbinden eines Maschinenparks von Hand entstehen so Parallelzweige ohne jede Fehlermeldung. Ein Abnehmer mit Wildcard auf den richtigen Zweig erhält von der abweichenden Maschine keine Daten.

Woran es sich zeigt: Beim Browsen des Brokers taucht ein Zweig doppelt auf, einmal groß und einmal klein geschrieben.

Was beim Betrieb liegt. Die Konvention schriftlich festlegen und die Liste der Maschinen mit ihren Namen als eine gepflegte Datei führen, nicht als Wissen im Kopf. Denn eine Vorlage macht die Schreibweise einheitlich, sie prüft sie nicht: Ein Tippfehler in der Liste erzeugt wieder einen eigenen Zweig.

Im OPC Router. Das Topic lässt sich als Vorlagenvariable vom Typ String anlegen, nur dieser Typ erlaubt die Kombination aus Variable und festem Text. Die Instanzen entstehen aus einer CSV- oder Excel-Datei über „Vorlage herunterladen“ und „Import“, als Serie oder, mit dem Add-on Enterprise+, dynamisch aus einer Datenbanktabelle. Im MQTT-Transferobjekt bietet „Start Browsing“ eine Topic-Auswahl aus der aktuellen Brokerverbindung an.

Ein Befehl kommt ein zweites Mal an

Das Fehlerbild: Ein Auftrag, der längst abgearbeitet ist, steht wieder in der Steuerung. Neu gesendet hat ihn niemand.

Die Ursache: Der Auftrag wurde mit Retain veröffentlicht. Der Broker hält ihn dann als letzte bekannte Nachricht des Topics und stellt ihn nach der MQTT-Spezifikation jedem neuen Abonnement zu. Nach MQTT 3.1.1 sendet er gehaltene Nachrichten auch dann noch einmal, wenn ein Client ein Topic abonniert, das er bereits abonniert hat, unter MQTT 5 ebenso bei Retain Handling 0. Die Spezifikation erläutert Retain als Mittel für Zustandsmeldungen: Ein neuer Abonnent soll den jüngsten Zustand bekommen. Ein Befehl mit Retain erreicht dagegen jedes neue Abonnement noch einmal, auch das eines Abnehmers, der ihn schon ausgeführt hat. Sparkplug B schreibt für Befehle ausdrücklich vor, NCMD und DCMD ohne Retain und mit QoS 0 zu veröffentlichen.

Woran es sich zeigt: Ein MQTT-Client, der das Befehls-Topic neu abonniert, erhält sofort eine Nachricht, obwohl gerade niemand sendet. Sie trägt das Retain-Flag, denn gehaltene Nachrichten stellt der Broker beim Abonnieren mit gesetztem Flag zu.

Was beim Betrieb liegt. Befehle ohne Retain veröffentlichen. Manche Broker setzen das per Zugriffsregel durch: HiveMQ über seine Enterprise Security Extension, EMQX ab Version 5.1.1 in der ACL-Datei. Die ACL-Datei von Mosquitto unterscheidet nur Lese- und Schreibrechte. Eine schon gehaltene Nachricht verschwindet, wenn eine leere Nachricht mit Retain auf dasselbe Topic geht; die aktuellen Abonnenten bekommen diese leere Nachricht ebenfalls und müssen sie als Nicht-Befehl erkennen. Unter MQTT 5 kann ein Abonnent mit Retain Handling 2 gehaltene Nachrichten beim Abonnieren abbestellen, und ein Absender kann mit Message Expiry eine Lebensdauer mitgeben: Ist sie abgelaufen, bevor die Zustellung an einen Abonnenten begonnen hat, verwirft der Broker diese Kopie. Und weil der Broker bei QoS 1 ohnehin wiederholen darf, bekommt jeder Befehl eine Kennung oder Folgenummer mit, an der der Empfänger eine Wiederholung erkennt.

Im OPC Router. Veröffentlicht der OPC Router selbst Befehle, etwa einen Auftrag aus SAP, bleibt „Retain“ im MQTT-Transferobjekt für diese Topics aus. Für die Empfängerseite nennt das Handbuch nur, dass der MQTT-Trigger beim Empfang den Retain-Merker einer Nachricht prüft; eine Einstellung, die gehaltene Nachrichten verwirft, beschreibt es nicht. Die Prüfung auf Wiederholung gehört deshalb in den Flow: Er vergleicht die Kennung eines Befehls mit der zuletzt verarbeiteten, etwa über eine Datenbanktabelle, bevor er in die Steuerung schreibt. In der Brokeranbindung startet „CleanSession“ eine neue Sitzung ohne gespeicherte Nachrichten. Ausgeschaltet bleibt die Sitzung bestehen, und der Broker stellt Nachrichten mit QoS 1 und 2, die während einer Unterbrechung eingingen, nach dem Wiederverbinden zu. Ob ein Befehl nach einer Störung noch ausgeführt werden soll, wird deshalb vor der Inbetriebnahme entschieden.

Ein Schreibvorgang scheitert ohne Meldung

Das Fehlerbild: Im Namensraum steht ein Auftrag, das sendende System führt ihn als übermittelt, in der Steuerung ist er nie angekommen. Eine Fehlermeldung hat der Absender nicht bekommen.

Die Ursache: Scheitert in einem Flow der Schreibschritt, etwa weil die Steuerung nicht erreichbar ist, bricht der OPC Router den Transfer ab. Die restlichen Schritte laufen nicht mehr, und der abgebrochene Transfer wird nicht wiederholt. Dem Broker wird der Fehlschlag nicht gemeldet, auch nicht mit „Warte auf Transfer“; die Nachricht gilt als zugestellt. Beim Absender kommt nur an, was eigens als Rückmeldung projektiert ist.

Woran es sich zeigt: am Transferstatus im OPC Router, nicht am Broker. Ganz unauffällig bleibt der Fehler in einem Try/Catch-Transferobjekt ohne CATCH-Zweig: Es verschluckt einen endgültigen Fehlschlag, der Transfer bleibt grün, und nur der Status-Ausgang Succeeded steht auf false.

Was beim Betrieb liegt. Jeder Befehl bekommt eine Rückmeldung mit Ergebnis, und der Absender wertet eine ausbleibende Rückmeldung nach einer festgelegten Zeit als Fehler. Wiederholt wird nur, was mehrfach ausgeführt werden darf.

Im OPC Router. Mit OPC Message und „Auf Antwort warten“ wird eine ausbleibende Bestätigung der Steuerung nach dem Antwort-Timeout zum fehlgeschlagenen Transfer. Das Try/Catch-Transferobjekt wiederholt den Schreibschritt auf Wunsch, mit höchstens 5 Versuchen, jeder mit einem festen Zeitlimit von 30 Sekunden. Eine Wiederholung führt allerdings den kompletten TRY-Zweig erneut aus, auch die Schritte, die schon erfolgreich waren, und passt deshalb nur zu Abläufen, die mehrfach ausgeführt werden dürfen. Den endgültigen Fehlschlag übernimmt der CATCH-Zweig, der die Fehlerquittung veröffentlicht. Das Add-on Store & Forward hilft an dieser Stelle nicht. Laut seiner Produktseite ist es für nicht zeitkritische Kanäle gedacht, die keine zu verarbeitende Rückantwort erwarten; ein Schreibvorgang mit „Auf Antwort warten“ wertet die Bestätigung der Steuerung dagegen aus. Ein nachgereichter Auftrag käme zudem erst an, wenn der Absender ihn nach Ablauf der festgelegten Zeit schon als gescheitert wertet: zu spät, oder doppelt, falls der Auftrag inzwischen neu geschickt wurde. Auch für Ziele, bei denen nur der aktuelle Wert zählt, etwa ein OPC-Tag, rät das Handbuch davon ab, weil sonst veraltete Werte verspätet geschrieben würden.