IBH Link UA:MQTT Beschreibung

IBH Link UA: MQTT-Funktion

Diese Seite beschreibt die MQTT-Funktion des IBH OPC UA Server/Client auf Basis des aktuellen Quellcodes und der vorhandenen Wiki-Inhalte.

Kurzueberblick

• Der Server unterstuetzt MQTT Publish und Subscribe.
• Mehrere MQTT-Verbindungen zu unterschiedlichen Brokern koennen parallel betrieben werden.
• Die Konfiguration erfolgt ueber eine XML-Datei ibhlinkua-mqtt.xml.
• Die Weboberflaeche besitzt eine eigene MQTT-Seite zum Hochladen, Herunterladen, Neustarten und Loeschen der MQTT-Konfiguration.
• Neben klassischem JSON-Mapping ist auch Sparkplug B unterstuetzt.
• TLS, Client-Zertifikate, eigene CA-Zertifikate, Last-Will-Nachrichten, Pufferung und persistente Ablage von Nachrichten werden unterstuetzt.
• Laut Produkthistorie wurde mit Version 5.37 der SparkplugB-Support verbessert.

Bedienung in der Weboberflaeche

Im aktuellen Stand besitzt die Weboberflaeche einen eigenen Bereich MQTT.

Verfuegbare Aktionen:

• MQTT XML Konfiguration hochladen
• MQTT XML Konfiguration herunterladen
• MQTT Verbindungen neustarten
• MQTT XML Konfiguration loeschen
• Diagnoseansicht aktualisieren

Die Diagnoseansicht zeigt pro Verbindung mindestens:

• Brokeradresse
• Client ID
• Verbindungsstatus

Die Konfigurationsdatei wird intern als ibhlinkua-mqtt.xml behandelt.

Grundprinzip

Die MQTT-Funktion bildet MQTT-Broker und Topics im OPC-UA-Adressraum ab.

Dabei gilt:

• unter Publish definierte Topics senden Daten aus dem OPC-UA-Server an MQTT
• unter Subscribe definierte Topics empfangen MQTT-Nachrichten und schreiben sie in den OPC-UA-Adressraum bzw. in zugeordnete OPC-Variablen
• die Topic- und Variablenstruktur wird aus der XML-Konfiguration aufgebaut

Betriebsarten

Klassisches MQTT mit JSON

Der Standardfall ist JSON-basierte Kommunikation.

• Publish: OPC-UA-Werte werden als JSON an ein MQTT-Topic gesendet
• Subscribe: eingehendes JSON wird geparst und in die definierten Variablen geschrieben
• Strukturen und Arrays werden unterstuetzt

Sparkplug B

Im aktuellen Code ist Sparkplug-Binary explizit implementiert.

Unterstuetzte Topictypen:

• DBIRTH
• DDATA
• DDEATH
• DCMD
• NBIRTH
• NDATA
• NDEATH
• NCMD

Aktuelles Verhalten laut Code:

• Sparkplug-Nachrichten werden ueber protobuf dekodiert.
• Bei Verbindungsaufbau werden fuer Sparkplug-Publisher automatisch Birth-Nachrichten erzeugt.
• Bei Verbindungsverlust wird der Birth-Status zurueckgesetzt.
• Bei Node Control/Rebirth kann erneut ein Birth-Versand ausgeloest werden.

Konfiguration der MQTT-Serververbindung

MQTT-Server werden ueber die XML-Datei beschrieben.

Unterstuetzte Funktionsbereiche:

• Brokeradresse
• Client ID
• Benutzername und Passwort
• TLS mit CA-Zertifikat, Client-Zertifikat und Private Key
• Private-Key-Passwort
• Last-Will-Nachricht
• automatische Wiederverbindung
• HTTP- oder HTTPS-Proxy
• Puffern von Nachrichten bei Verbindungsunterbrechung
• persistente Ablage gepufferter Nachrichten

Sicherheit und TLS

Der Code unterstuetzt abgesicherte MQTT-Verbindungen mit:

• CA-Zertifikat
• Client-Zertifikat
• Private Key
• optionalem Passwort fuer den Private Key

Wenn kein CA-Zertifikat angegeben ist, kann die Server-Zertifikatspruefung deaktiviert werden. Im Code ist ausserdem PSK-Unterstuetzung vorgesehen, wenn Identity und Passwort gesetzt sind.

Last Will

Last-Will-Nachrichten sind implementiert.

Verwendete Eigenschaften:

• Will Topic
• Will Message
• Will QoS
• Will Retain

Puffern und persistente Ablage

Die MQTT-Bibliothek wird im Code mit maxBufferedMessages betrieben.

Aktueller Stand:

• bei maxBufferedMessages > 0 wird clean session deaktiviert
• damit koennen Nachrichten waehrend Unterbrechungen zwischengespeichert werden
• mit PersistDir ist eine persistente Ablage moeglich
• unter Linux wird das Persistenzverzeichnis zusaetzlich ueber Dateisystem-Events ueberwacht

Cloud-spezifische Varianten

Microsoft Azure IoT Hub

Die bisherige Doku beschreibt eine spezielle Anbindung ueber AzureIoTConnectionString.

Wichtiger Hinweis:

• pro Azure IoT Hub ist nur ein Topic moeglich

Der aktuelle Code enthaelt weiterhin spezielle Pfade fuer Azure-Publish- und Subscribe-Topicnamen.

Amazon AWS IoT

Die AWS-IoT-Anbindung erfolgt ueber Zertifikate.

Praktisch relevant sind:

• CA-Zertifikat
• Client-Zertifikat
• Private Key

Topic-Konfiguration

Topics werden unter Publish oder Subscribe definiert.

Aktuell relevante Topic-Parameter:

• name
• qos
• retain
• trigger_var
• trigger_mode
• trigger_sampling_interval
• status_var
• deadband

QoS

Unterstuetzt werden:

• 0
• 1
• 2

retain

Fuer Publish-Topics kann retain="true" gesetzt werden.

Trigger

Der Code unterstuetzt triggergesteuertes Senden.

Verwendete Parameter:

• trigger_var
• trigger_mode
• trigger_sampling_interval

Dokumentierte Werte fuer trigger_mode:

• rising_edge
• falling_edge
• value_change

status_var

status_var ist eine OPC-Variable fuer den Sendestatus.

Dokumentiertes Verhalten:

• Wert 1: Senden oder Puffern erfolgreich
• Wert 2: Fehler oder Puffer voll
• die SPS sollte bei 1 einen neuen Wert uebergeben und danach wieder auf 0 setzen

deadband

Der aktuelle Code unterstuetzt deadband sowohl auf Topic- als auch auf Variablenebene.

Variablen und Datentypen

Im aktuellen Code werden unter anderem diese Datentypen unterstuetzt:

• Boolean
• SByte
• Byte
• Int16
• UInt16
• Int32
• UInt32
• Int64
• UInt64
• Float
• Double
• DateTime
• String
• die entsprechenden Array-Typen

Zusaetzlich werden in der bestehenden Doku beschrieben:

• Konstanten ueber const
• freie Namensvergabe fuer Variablen
• Strukturen mit geschachtelten Elementen
• Anbindung an externe OPC-UA-Servervariablen

Verhalten bei Subscribe

Im aktuellen Code gilt:

• JSON-Payloads werden geparst und typgerecht in MQTT-Variablen geschrieben.
• Vorhandene OPC-Zuordnungen werden anschliessend direkt beschrieben.
• Fehler beim Parsen oder Schreiben werden im Verbindungsstatus hinterlegt.
• Bei Sparkplug werden eingehende protobuf-Metriken in den OPC-UA-Adressraum uebernommen.

Verhalten bei Publish

Im aktuellen Code gilt:

• Publish-Topics uebertragen Werte aenderungsgetrieben oder triggergesteuert.
• retain und QoS werden an die MQTT-Bibliothek uebergeben.
• Bei Sparkplug werden je nach Topic-Typ Birth- oder Data-Nachrichten erzeugt.

Diagnose und Betrieb

Die MQTT-Seite der Weboberflaeche ist fuer den laufenden Betrieb relevant.

Typische Betriebsaktionen:

1. neue ibhlinkua-mqtt.xml hochladen
2. MQTT-Verbindungen neu starten
3. Verbindungsliste und Status pruefen
4. bei Bedarf Konfiguration herunterladen oder loeschen

Fuer Support und Fehlersuche sind besonders wichtig:

• Brokeradresse
• Client ID
• Verbindungsstatus
• XML-Konfigurationsdatei
• eingesetzte Zertifikate
• Topicnamen und Triggerparameter