IIoT Connector

Übersicht

Der IIoT Connector ist ein MQTT-Client, der eine Verbindung zu einem MQTT-Broker aufbauen kann. Sobald die Verbindung hergestellt ist, kann der IIoT-Connector Nachrichten veröffentlichen oder abonnieren.

Es können unterschiedliche Systeme angebunden werden:

• MQTT Broker (z. B. Mosquitto oder HiveMQ)

• easyConnect (Weidmüller IIoT Cloud-Plattform)

• ResMa® (Weidmüller Energie- und Prozessdatensoftware onPremise)

Der IIoT Connector unterstützt die MQTT Versionen v5 und v3.1.1.

Navigation

Über die Startseite kann der Bereich IIoT Connector (1) aufgerufen werden.

Connector-Übersicht

Übersicht zur Verwaltung bestehender Connectoren sowie Einstiegspunkts für das Hinzufügen neuer Connectoren.

1. Connector hinzufügen: Einstiegspunkt für das Hinzufügen eines Connectors. Nach Klick öffnet eine Auswahl, bei der das Ziel gewählt wird, mit dem verbunden werden soll. Zur Auswahl stehen ResMa®, easyConnect oder ein MQTT-Broker.

2. Name: Name des Connectors. Der Name wird vom Benutzer während des Hinzufügens gewählt. Eine nachträgliche Bearbeitung ist nicht möglich.

3. Ziel: Zieltyp, mit dem der Connector verbunden ist.

4. Verbindungsstatus: Aktueller Status der Verbindung. Hier kann abgelesen werden, ob der Connector mit dem Ziel verbunden oder inaktiv ist. Auch Lizenzinformationen werden hier angezeigt.

5. Nachrichtenübersicht: Anzahl der gesendeten und empfangenen Nachrichten.

6. Optionen-Menü: Einstiegspunkt für Optionen des jeweiligen Connectors wie bspw. Verbinden, Bearbeiten oder Löschen.

7. Globale Verbindungsanzeige: Die globale Verbindungsanzeige erscheint, wenn mindestens ein bestehender Connector keine Verbindung zu seinem Ziel aufbauen konnte.

Hinzufügen easyConnect oder ResMa Connector

Der easyConnect und ResMa Connectors werden identisch angelegt.

1. Connectorname: Kann frei vergeben werden, muss jedoch eindeutig sein.

2. Aktivierungscode: Der Code dient dazu, die Identität des Clients zu besätigen und den Zugriff auf den MQTT-Broker zu sichern. Der Code muss in easyConnect bzw. ResMa® erzeugt und hier eingetragen werden. Die Erzeugung des Codes in ResMa® ist nachfolgend im Detail beschrieben.

3. Server-URL: Für ResMa-Verbindungen ersetzen Sie hier den Passus [RESMA_HOST]:[PORT] mit der IP oder dem DNS-Eintrag Ihres ResMa-Servers sowie dem zugehörigen Port (default ist 8080).

4. Cloudkommunikation: Bei Deaktivierung können keine Werte außerhalb des eigenen Netzwerkes empfangen oder gesendet werden.

5. Zeitintervall Keep-Alive: Das Intervall legt fest, wie oft ein Ping-Signal gesendet wird, um die Verbindung zum Broker aufrechtzuerhalten (Standard: 180 Sekunden). Ein kürzeres Intervall erhöht die Verbindungsstabilität, während ein längeres die Netzwerklast verringert.

Aktivierungscode in ResMa® erzeugen

Um die Verbindung zwischen PROCON-Connect und ResMa® herzustellen, muss ein Aktivierungscode in ResMa® erstellt und dann in PROCON-Connect hinterlegt werden.

Führen Sie dazu die folgenden Schritte in ResMa® aus:

1. Loggen Sie sich in Ihr ResMa®-System ein.

2. Schalten Sie die den Objektbaum von der Ansicht Standard in die Ansicht Connector.

3. Schalten Sie den Objektbaum in den Editiermodus um.

4. Machen Sie einen Rechtsklick auf den Standort, dem Sie den IIoT Connector hinzufügen möchten. Es öffnet ein Kontextmenü.

5. Wählen Sie im Kontextmenü die Option ‚Neues Gerät‘. Es öffnet die Konfigurationsseite für den IIoT Connector.

6. Geben Sie dem Connector einen Namen. Dieser wird in den Objektbaum übernommen.

7. Markieren Sie den Aktivierungscode aus dieser Übersicht und kopieren Sie diesen mit der Tastenkombination Strg + c.

8. Klicken Sie auf Speichern, um die Konfiguration des Connectors abzuschließen.

Anschließend können Sie den kopierten Aktivierungscode in die Konfiguration des IIoT Connectors in PROCON-Connect einfügen mit der Tastenkombination Strg + v.

Hinzufügen MQTT Connector

Die Konfiguration des MQTT Connectors ist in drei Tabs unterteilt. Im Bereich Kommunikation (1) müssen fast dieselben Werte wie bei den anderen Connectoren erfasst werden.

1. Connectorname: Kann frei vergeben werden, muss jedoch eindeutig sein.

2. MQTT URL: Gültige URL des MQTT-Brokers, mit dem verbunden werden soll.

3. Cloudkommunikation: Bei Deaktivierung können keine Werte außerhalb des eigenen Netzwerkes empfangen oder gesendet werden.

4. Zeitintervall Keep-Alive: Das Intervall legt fest, wie oft ein Ping-Signal gesendet wird, um die Verbindung zum Broker aufrechtzuerhalten (Standard: 180 Sekunden). Ein kürzeres Intervall erhöht die Verbindungsstabilität, während ein längeres die Netzwerklast verringert.

5. MQTT Protokoll: Version des Protokolls. Die Version muss auf den anzubindenden MQTT-Broker angepasst werden. Die Version beeinflusst bzw. die verwendeten Status-Codes in der Kommunikation zwischen MQTT-Client und MQTT-Broker.

Im Tab „Sicherheit“ (1) werden gültige Zugangsdaten für den Connector benötigt.

1. Authentifizierung: Gültiger Benutzer und Passwort für den Connector.

2. Zertifikate: Client-Zertifikate aktivieren und über den Button hochladen.

   Upload von Client-Schlüssel und CA-Zertifikat

Im letzten Reiter „Konfiguration“ (1) erfolgt die Eingabe der MQTT-Clientdaten. Der Quality of Service ist hierbei bei allen wählbar zwischen maximal einmal / mindestens einmal oder genau einmal

1. Client-ID: Eindeutige ID.

2. Publish Definition: Typinformationen zu den Werten.

3. Publish Instance: Bereitstellung der Werte.

4. Subscribe Instance: Lesen der Werte.

5. Last Will: Die Last Will Nachricht informiert den Broker darüber, welche Nachricht er an die Abonnenten senden soll, falls der Client unerwartet die Verbindung verliert. Damit können andere Teilnehmer über den Ausfall des Clients benachrichtigt werden.

Quality of Service (QoS)

Der Quality of Service (QoS) in einem MQTT-Client legt fest, wie Nachrichten zwischen Client und Broker übermittelt werden. Es gibt drei QoS-Stufen: 0, 1 und 2. Jede Stufe bietet eine unterschiedliche Balance zwischen Zuverlässigkeit und Performance. QoS-Stufen

1. QoS 0 – „At most once“ (Maximal einmal)

   • Funktionsweise: Die Nachricht wird einmal gesendet, ohne dass der Sender eine Bestätigung vom Empfänger erhält. Es gibt keine Garantie, dass die Nachricht ankommt.

   • Performance: Höchste Performance, da keine Bestätigungen notwendig sind und die Übertragung nur einmal erfolgt.

   • Anwendungsfall: Geeignet für unkritische Daten, bei denen es nicht auf die zuverlässige Zustellung ankommt, z.B. Sensordaten, die häufig aktualisiert werden.

2. QoS 1 – „At least once“ (Mindestens einmal)

   • Funktionsweise: Die Nachricht wird so lange erneut gesendet, bis eine Bestätigung vom Empfänger eintrifft. Es kann jedoch passieren, dass die Nachricht mehrfach zugestellt wird.

   • Performance: Mittlere Performance, da es zu Wiederholungen der Übertragung kommen kann.

   • Anwendungsfall: Passend für Anwendungen, bei denen die Nachricht auf jeden Fall ankommen soll, aber eine mehrfache Zustellung tolerierbar ist, z.B. Zahlungsaufträge oder Status-Updates.

3. QoS 2 – „Exactly once“ (Genau einmal)

   • Funktionsweise: Die Nachricht wird garantiert genau einmal zugestellt. Dies wird durch einen mehrstufigen Handshake-Prozess zwischen Sender und Empfänger erreicht.

   • Performance: Niedrigste Performance, da mehrere Kommunikationsschritte notwendig sind, um die doppelte Zustellung zu verhindern.

   • Anwendungsfall: Ideal für kritische Nachrichten, bei denen doppelte Zustellung nicht akzeptabel ist, z.B. bei der Übermittlung von Auftragsdaten in einem Bestellsystem.

Note

Die Wahl der QoS-Stufe sollte abhängig von den spezifischen Anforderungen der Anwendung getroffen werden, um ein optimales Verhältnis zwischen Zuverlässigkeit und Performance zu erreichen.

• QoS 0: Maximal einmal – Hohe Performance, keine Garantie für Zustellung.

• QoS 1: Mindestens einmal – Balance zwischen Zuverlässigkeit und Performance.

• QoS 2: Genau einmal – Höchste Zuverlässigkeit, geringere Performance.

Die Wahl der QoS-Stufe sollte abhängig von den spezifischen Anforderungen der Anwendung getroffen werden, um ein optimales Verhältnis zwischen Zuverlässigkeit und Performance zu erreichen.

Retain

Konfigurationsoption: Retain Option im MQTT-Client

Die Retain Option in einem MQTT-Client bestimmt, ob eine Nachricht auf dem Broker gespeichert („retain“) wird, damit sie an zukünftige Abonnenten gesendet werden kann. Dies beeinflusst, wie der Broker mit neuen Abonnenten umgeht, die sich nach der Veröffentlichung der Nachricht anmelden.

1. Retain Option aktiviert

   • Verhalten: Wenn die Retain Option aktiviert ist, speichert der Broker die letzte gesendete Nachricht für jedes Topic, das sie betreffen. Diese gespeicherte Nachricht wird dann automatisch an alle neuen Abonnenten gesendet, sobald sie sich für dieses Topic anmelden.

   • Anwendungsfall: Nützlich, wenn Abonnenten immer die aktuellste Information erhalten sollen, auch wenn sie sich nach der ursprünglichen Veröffentlichung anmelden. Zum Beispiel, wenn der aktuelle Status eines Systems (wie Temperatur oder Online-Status) immer verfügbar sein muss.

2. Retain Option deaktiviert

   • Verhalten: Ohne die Retain Option wird die Nachricht nicht auf dem Broker gespeichert. Neue Abonnenten erhalten nur Nachrichten, die nach ihrer Anmeldung veröffentlicht werden. Frühere Nachrichten werden nicht zugestellt.

   • Anwendungsfall: Geeignet für Daten, die nur in Echtzeit relevant sind, wie beispielsweise kontinuierlich aktualisierte Sensordaten, bei denen es nicht wichtig ist, die letzte Nachricht zu kennen.

Note

Die Wahl, ob die Retain Option aktiviert oder deaktiviert wird, sollte auf den Bedürfnissen der Anwendung basieren, insbesondere darauf, ob neue Abonnenten auf den letzten bekannten Zustand zugreifen müssen oder nicht.

• Retain Option aktiviert: Speichert die letzte Nachricht auf dem Broker und stellt sicher, dass neue Abonnenten diese erhalten. Ideal für Statusinformationen, die immer aktuell sein müssen.

• Retain Option deaktiviert: Nachrichten werden nicht gespeichert; neue Abonnenten erhalten nur zukünftige Nachrichten. Optimal für Echtzeit-Daten, bei denen vergangene Informationen nicht relevant sind.

Die Wahl, ob die Retain Option aktiviert oder deaktiviert wird, sollte auf den Bedürfnissen der Anwendung basieren, insbesondere darauf, ob neue Abonnenten auf den letzten bekannten Zustand zugreifen müssen oder nicht.

Datendefinitionen

Für jeden der hinzugefügten Connectoren können Datendefinitionen hinzugefügt werden. Mithilfe dieser Datendefinitionen können einzelne oder mehrere definierte Werte zusammengefasst, übermittelt oder gelesen werden.

Unabhänig vom gewählten Connector funktioniert die Erstellung einer Datendefinition immer gleich. Durch Aufklappen des Connectors in der Übersicht kommt entweder eine Übersicht über die bereits erstellten Datendefinitionen und im Anschluss der Button „Datendefinition Hinzufügen“ oder der Hinweis, dass noch keine vorhanden ist und der entsprechende Button zum Hinzufügen.

Im anschließenden Dialog werden zuerst die allgemeinen Einstellungen getätigt.

1. Clouddatendefinitionsname: Zwingend erforderlich, muss eindeutig sein.

2. Verbindungstyp: Zur Auswahl stehen:

   • Sende Tags bei Werteänderung (publish)

   • Sende Tags periodisch (publish) > Hier muss anschließend noch der Zyklus und die Zeiteinheit festgelegt werden

   • Lese Tags (subscribe)

Bei erstellte Datendefinitionen kann über die drei Punkte das Kontextmenü aufgerufen und die Datendefinitionen bearbeitet oder gelöscht werden.

Im Tab „Tags“ können dann die Variablen ausgewählt werden, die überwacht werden sollen. Auch können bereits hinzugefügte Tags wieder entfernt werden.

Ausfallsicherheit

Bei einer Unterbrechung der Netzwerkverbindung zwischen IIoT Connector (MQTT Client) und einem konfigurierten Ziel (MQTT Broker) kann es potenziell zu Datenverlusten kommen.

Um Datenverluste zu vermeiden, puffert der IIoT Connector je konfiguriertem Ziel (MQTT Broker) bis zu 1000 Nachrichten lokal. Konnte bis zum Erreichen dieser Grenze noch immer keine Verbindung aufgebaut werden, wird die älteste Nachricht jeweils mit der neuesten Nachricht überschrieben. Sobald eine Netzwerkverbindung besteht, wird der IIoT Connector die Nachrichten an das Ziel senden.

Ein auf Zeitbasis konfigurierbarer Puffer ist in Planung. Solange dieser nicht umgesetzt ist, kann das Limit von 1000 Nachrichten über eine Konfigurationsdatei angepasst werden. Nehmen Sie bei Bedarf Kontakt mit uns auf.