Hallo,
ich möchte Euch ein Projekt vorstellen, an dem ich, mein Kollege Christof und Roan Brandt aus Südafrika seit einigen Monaten arbeiten.
Wir haben in den letzten Monaten das Protokoll Message Queue Telemetry Transport (MQTT) für Siemens S7 als Step7 Projekt programmiert.
Über MQTT
MQTT ist ein Publish-Subscriber Protokoll, das bei "Internet of Things" (IoT) Projekten als Standardprotokoll verwendet wird. Es wird von allen großen Cloud Anbietern mit IoT Diensten wie Amazon AWS oder auch Microsoft Azure direkt unterstützt.
MQTT hat einige interessante Eigenschaften. Wie bereits erwähnt basiert es auf dem Publish-Subscriber Muster. Sendende Systeme, die Publisher genannt werden, übermitteln Nachrichten an Nachrichtenverteiler, die Broker genannt werden.
Systeme, die sich für bestimmte Typen von Nachrichten interessieren, können diese beim Broker abonnieren. Diese Systeme nennt man deswegen Subscriber.
Publisher, Subscriber und Topics
Nachrichten enthalten Topics, diese sind eine Mischung aus Nachrichtenüberschrift und hierarchischen Nachrichtentypen. Anhand der Topics können MQTT Nachrichten gefiltert werden.
Ein Topic könnte z.B. "test" lauten. Subscriber, die das Topic "test" abonniert haben, erhalten sämtliche Nachrichten mit dem topic "test", die von Publisher versendet werden, aber keine Nachrichten mit anders lautendem Topic.
Ein Subscriber kann übrigens mehrere Topics gleichzeitig abonnieren. Natürlich können Abos für Topics mittels Unsubscribe auch wieder gelöst werden.
Topic-Hierarchien und Filter
Topics können mittels "/"-Zeichen aber auch Hierarchien abbilden. Z.B. könnte es ein Topic Haus/Küche/Temperatur und ein weiteres Topic Haus/Küche/Luftfeuchtigkeit geben.
Ein Subscriber, der das Topic Haus/Küche/Temperatur abonniert hat, würde ab dann alle Nachrichten mit diesem Topic erhalten. Nachrichten dieses Topics können von einem Publisher System aber auch von mehreren versendet werden, solange diese das gleiche Topic verwenden bekommt der Subscriber alle Nachrichten.
Es gibt aber auch den Filter # für Topics, abonniert man diesen erhält man alle Nachrichten, egal welches Topic diese haben. Das + Zeichen ist ein Platzhalter für eine Hierarchieebene. Abonniert man z.B. /Haus/+/Temperatur, würde man alle Temperaturnachrichten aus allen Zimmern erhalten.
Quality of Service Level - Handshakes für Publisher
MQTT bietet aber noch einiges mehr. Das Protokoll definiert drei Quality of Service Modi.
Quality of Service 0 ist der "Fire and Forget" Modus. MQTT Nachrichten, die mit diesem QoS-Modi gesendet werden haben keinerlei Handshake, dass den Empfang beim Broker quittieren würde.
Sendet man eine Nachricht mit dem Quality of Service Level 1, dann wird ein einfacher Handshake aktiviert. Jeder Nachricht wird mit einer Quittierung seitens des Brokers bestätigt, die Quittierung erfolgt anhand einer Nachrichten-ID, die bei Emfpang durch den Broker zurückgemeldet wird.
Der Quality of Service Level 2 enthält einen doppelten Handshake, d.h. die Quittierung einer empfangenen Nachricht wird vom Publisher wiederum zum Broker Quittiert, der wiederum die Quittierung quittiert (ächz). Dies soll den doppelten Versand einer Nachricht erschweren (Duplicates).
Quality of Service Level - Nachrichtenpufferung für Subscriber
Beim Abonnieren können ebenfalls Quality of Service Level angefordert werden, diese haben dann aber eine etwas andere Funktion. Ein Subscriber, der Quality of Service beim Broker anfordert, bekommt nicht nur eine gesicherten Nachrichtenversand mit Handshake, der Broker fängt auch an Nachrichten von Topics, die der Suscriber abonniert hat, zu puffern, falls der Subscriber offline ist. Geht der Subscriber wieder online, bekommt er alle zwischenzeitlich eingegangen Nachrichten des Topics vom Broker zugeschickt.
Retained Messages - der letzte bleibt hängen
Aber auch der Publisher kann eine bestimmte Art der Nachrichtenpufferung beim Broker anfordern Sendet ein Publisher eine Nachricht mit gesetztem Retain Flag, dann puffert der Broker immer die letzte eingegangene Nachricht für deren Topic. Abonniert ein neuer Subscriber dieses Topic, erhält er sofort die letzte eingegangene Nachricht, auch wenn diese bereits vor dessen Abonement eingegangen war.
Connect - Funktion mit Mehrwert für Tote
Bevor Publisher oder Suscriber die Funktionen eines Broker nutzen können, müssen sie sich erst einmal mittels Connect beim Broker anmelden. Daraufhin wird im Broker eine Session für den Client erzeugt. Die Anmeldung kann dabei auch mit Benutzername und Kennwort abgesichert werden.
Interessant ist dabei die Möglichkeit des Clients eine Testamentsnachricht an den Broker zu übergeben. Dies ist eine normale MQTT Nachricht mit Topic, Daten und auch Retained Flag. Der Broker macht beim Connect mit dem Client eine Keepalive Zeit aus, in diesem Zeitraum muss der Client eine Nachricht verschicken oder ein MQTT-Ping zum Broker schicken, ansonsten nimmt der Broker an, das der Client tot (offline) ist. Genau in diesem Fall wird die Testamentsnachricht vom Broker verschickt, er handelt sozusagen als Notar im Auftrag des Clients. So eine Nachricht kann z.B. an das Topic "Offline-Client" mit dem Inhalt "Client 10 ist offline" lauten. Alle Systeme, die das Topic "Offline-Client" abonniert haben, erhalten darauf hin diese Nachricht. Somit werden interessierte Systeme vom "ableben" eines Clients benachrichtigt, ohne dass sie diesen überwachen müssten.
Leichtgewichtiges Protokoll für schwere Daten
MQTT ist ein sehr einfach gehaltenes Protokoll, dass trotz Einfachheit aber tolle Funktionen bietet. Ich meine : hey, wir haben es selber für S7 implementiert! Wer mich kennt weiss also: kann so kompliziert nicht sein ;-) Weiterhin kann MQTT bis zu 256MB an Daten befördern.
MQTT im Netzwerk - auch im Web zuhause
MQTT funktioniert standardmäßig über TCP/IP oder Websockets. Dank der Websockets-Untersützung können auch Browser-Clients mit Javascript direkt beim Broker Topics abonnieren und somit Daten in Echtzeit erhalten. Websockets sind Teil des HTML 5 Standards und auch Proxy-fähig, d.h. MQTT-Kommunikation kann über einen HTTP-Proxy weitergeleitet werden. Websockets-URL fangen mit ws:// oder wss:// an.
Broker
Broker sind die Nachrichtenvermittler in der MQTT-Infrastruktur. Broker erhalten Daten von Publishern, puffern diese auf Anforderung und liefern diese in Echtzeit an Subscriber aus.
Allerdings heisst das nicht, das alle Clients auf einen Broker angewiesen sind. Broker unterstützen so genanntes Bridging, d.h. mann kann auch Broker mit Broker verbinden und die Nachrichten von einem Broker zum nächsten übermitteln lassen. Somit können z.B. Broker für Standorte zuständig sein, aber die Standorte auch untereinander verbinden.
Weiterhin sorgen Broker auch für Sicherheit und Nachrichtenpufferung.
Broker gibt es viele, sie müssen nur das MQTT Protokoll (aktuell ist die MQTT-Protokollversion 3.1.1) unterstützen. Es gibt Open Source Produkte wie den Mosquitto Broker aber auch sehr gute kommerzielle Produkte wie z.B. HiveMQ mit Clustering-Fähigkeiten.
MQTT - der Ring der sie alle bindet
Aufgrund der Einfachheit des Protokolls gibt es MQTT-Bibliotheken für so ziemlich alles, was 0 und 1 unterscheiden kann. Unser Team hat es für S7 implementiert, es gibt MQTT aber auch für praktisch alle Programmiersprachen und auch für Systeme wie z.B. LabView.
Somit lassen sich innerhalb einer Industrieumgebung die unterschiedlichsten Systeme zusammenschalten, aber ebend auch aus der Industrieumgebung hinaus in die klassische IT-Welt bis "rauf" in die Cloud!
Nun ist MQTT aber auch kein IT-Exot der OASIS Standardisiert ist, sondern auch ein Protokoll mit ISO/IEC-Heiligsprechung (ISO/IEC 20922:2016).
Schaut selbst mal nach unter http://www.mqtt.org und http://www.iso.org/iso/catalogue_det...csnumber=69466
MQTT - wozu?
Ich habe Euch ja nun den Feature-Blumenstrauss von MQTT vorgestellt. Aber warum soll das jetzt besser sein oder als Alternative zu etablierten Standards wie z.B. OPC oder OPC-UA in Erwägung gezogen werden?
Zunächst einmal Entkoppelt MQTT Sender und Empfänger wunderbar voneinander. Sender könen Daten zum Broker senden und sind danach "fertig", einer oder viele Empfänger können diese Daten abonnieren, ohne dass der Sender überhaupt weiss, wer der oder die Clients sind. Bei OPC ist das ähnlich, aber MQTT funktioniert eben nicht nur im Industrial Engineering und der Hausautomation. Ausserdem is MQTT viel billiger, praktisch alles an MQTT ist Open Source bzw. frei erhältlich. Weiterhin wird MQTT von modernen IT-Diensten wie IoT verwendet.
MQTT kann jeder "sprechen", der LabView End-of-Line Tester, die Siemens-Steuerung, der Arduino Microcontroller oder der Raspberry Pi. Und natürlich alle PC-Anwendungen die MQTT unterstützen bzw. sämtliche Individualprojekte - einfach MQTT Bibliothek einbinden und die Kommunikation ist in 10 Zeilen fertig programmiert.
MQTT ersetzt natürlich die etablierten Standards nicht, es kann es aber in bestimmten Szenarien und es ist eine tolle Ergänzung. Wer einmal Publisher-Subscriber-Systeme aufgebaut hat wird sie schon als eleganten Fortschritt ansehen.
Weiterhin ist MQTT besser als selbgestrickte S7 TCP-Kommunikation mit unglaublich "genialen" Selbstbau-Binärprotokollen. Warum, lies das nächste Kapitel.
MQTT - Fehlersuche mal einfach
Das bekannte Netzwerkanalyseprogramm Wireshark kennt das MQTT Protokoll. Somit kann man mit Wireshark die komplette MQTT-Kommunikation einsehen, protokollieren und analysieren. Bis ins Detail!
MQTT S7 - Worum es hier eigentlich geht :-)
Ok, jetzt aber zu Theme SPS. Unter
https://github.com/CarstenMaul/MQTT-Siemens-S7-300
könnt Ihr euch das aktuelle S7 Projekt inkl. Anleitung runterladen.
Ein Beispielprojekt in der Datei MQTT_Example.scl liegt bei. Alle Funktionen werden in diesem Beispielprojekt exemplarisch angesteuert: Connect, Publish, Susbsribe, Unsubscribe, Disconnect.
Das Projekt unterstützt sowohl CPUs mit integriertem Profinet als auch mit CP-Ethernet-Baugruppe.
Schaut Euch unser Werk mal an. Über Feedback würden wir uns sehr freuen, über erkannte Fehler natürlich um so mehr ;-)
Einen Broker könnt Ihr euch unter
http://www.mosquitto.org
laden. Den MQTT-Client MQTT.fx, der auch als Desktopanwendung die Möglichkeit gibt alle MQTT-Funktionen zu testen und mit einem Broker zu kommunizieren, gibt es hier:
http://mqttfx.jfx4ee.org/
So, jetzt hoffentlich viel Spass mit dieser Technologie.
Und bitte vergesst nicht: alle Software und Quellcodes ohne Gewähr! Ihr bekommt den S7 Quellcode zur freien Nutzung, der Einsatz in Euren Projekten erfolgt natürlich auf eigene Gefahr.
Gruß
Carsten
ich möchte Euch ein Projekt vorstellen, an dem ich, mein Kollege Christof und Roan Brandt aus Südafrika seit einigen Monaten arbeiten.
Wir haben in den letzten Monaten das Protokoll Message Queue Telemetry Transport (MQTT) für Siemens S7 als Step7 Projekt programmiert.
Über MQTT
MQTT ist ein Publish-Subscriber Protokoll, das bei "Internet of Things" (IoT) Projekten als Standardprotokoll verwendet wird. Es wird von allen großen Cloud Anbietern mit IoT Diensten wie Amazon AWS oder auch Microsoft Azure direkt unterstützt.
MQTT hat einige interessante Eigenschaften. Wie bereits erwähnt basiert es auf dem Publish-Subscriber Muster. Sendende Systeme, die Publisher genannt werden, übermitteln Nachrichten an Nachrichtenverteiler, die Broker genannt werden.
Systeme, die sich für bestimmte Typen von Nachrichten interessieren, können diese beim Broker abonnieren. Diese Systeme nennt man deswegen Subscriber.
Publisher, Subscriber und Topics
Nachrichten enthalten Topics, diese sind eine Mischung aus Nachrichtenüberschrift und hierarchischen Nachrichtentypen. Anhand der Topics können MQTT Nachrichten gefiltert werden.
Ein Topic könnte z.B. "test" lauten. Subscriber, die das Topic "test" abonniert haben, erhalten sämtliche Nachrichten mit dem topic "test", die von Publisher versendet werden, aber keine Nachrichten mit anders lautendem Topic.
Ein Subscriber kann übrigens mehrere Topics gleichzeitig abonnieren. Natürlich können Abos für Topics mittels Unsubscribe auch wieder gelöst werden.
Topic-Hierarchien und Filter
Topics können mittels "/"-Zeichen aber auch Hierarchien abbilden. Z.B. könnte es ein Topic Haus/Küche/Temperatur und ein weiteres Topic Haus/Küche/Luftfeuchtigkeit geben.
Ein Subscriber, der das Topic Haus/Küche/Temperatur abonniert hat, würde ab dann alle Nachrichten mit diesem Topic erhalten. Nachrichten dieses Topics können von einem Publisher System aber auch von mehreren versendet werden, solange diese das gleiche Topic verwenden bekommt der Subscriber alle Nachrichten.
Es gibt aber auch den Filter # für Topics, abonniert man diesen erhält man alle Nachrichten, egal welches Topic diese haben. Das + Zeichen ist ein Platzhalter für eine Hierarchieebene. Abonniert man z.B. /Haus/+/Temperatur, würde man alle Temperaturnachrichten aus allen Zimmern erhalten.
Quality of Service Level - Handshakes für Publisher
MQTT bietet aber noch einiges mehr. Das Protokoll definiert drei Quality of Service Modi.
Quality of Service 0 ist der "Fire and Forget" Modus. MQTT Nachrichten, die mit diesem QoS-Modi gesendet werden haben keinerlei Handshake, dass den Empfang beim Broker quittieren würde.
Sendet man eine Nachricht mit dem Quality of Service Level 1, dann wird ein einfacher Handshake aktiviert. Jeder Nachricht wird mit einer Quittierung seitens des Brokers bestätigt, die Quittierung erfolgt anhand einer Nachrichten-ID, die bei Emfpang durch den Broker zurückgemeldet wird.
Der Quality of Service Level 2 enthält einen doppelten Handshake, d.h. die Quittierung einer empfangenen Nachricht wird vom Publisher wiederum zum Broker Quittiert, der wiederum die Quittierung quittiert (ächz). Dies soll den doppelten Versand einer Nachricht erschweren (Duplicates).
Quality of Service Level - Nachrichtenpufferung für Subscriber
Beim Abonnieren können ebenfalls Quality of Service Level angefordert werden, diese haben dann aber eine etwas andere Funktion. Ein Subscriber, der Quality of Service beim Broker anfordert, bekommt nicht nur eine gesicherten Nachrichtenversand mit Handshake, der Broker fängt auch an Nachrichten von Topics, die der Suscriber abonniert hat, zu puffern, falls der Subscriber offline ist. Geht der Subscriber wieder online, bekommt er alle zwischenzeitlich eingegangen Nachrichten des Topics vom Broker zugeschickt.
Retained Messages - der letzte bleibt hängen
Aber auch der Publisher kann eine bestimmte Art der Nachrichtenpufferung beim Broker anfordern Sendet ein Publisher eine Nachricht mit gesetztem Retain Flag, dann puffert der Broker immer die letzte eingegangene Nachricht für deren Topic. Abonniert ein neuer Subscriber dieses Topic, erhält er sofort die letzte eingegangene Nachricht, auch wenn diese bereits vor dessen Abonement eingegangen war.
Connect - Funktion mit Mehrwert für Tote
Bevor Publisher oder Suscriber die Funktionen eines Broker nutzen können, müssen sie sich erst einmal mittels Connect beim Broker anmelden. Daraufhin wird im Broker eine Session für den Client erzeugt. Die Anmeldung kann dabei auch mit Benutzername und Kennwort abgesichert werden.
Interessant ist dabei die Möglichkeit des Clients eine Testamentsnachricht an den Broker zu übergeben. Dies ist eine normale MQTT Nachricht mit Topic, Daten und auch Retained Flag. Der Broker macht beim Connect mit dem Client eine Keepalive Zeit aus, in diesem Zeitraum muss der Client eine Nachricht verschicken oder ein MQTT-Ping zum Broker schicken, ansonsten nimmt der Broker an, das der Client tot (offline) ist. Genau in diesem Fall wird die Testamentsnachricht vom Broker verschickt, er handelt sozusagen als Notar im Auftrag des Clients. So eine Nachricht kann z.B. an das Topic "Offline-Client" mit dem Inhalt "Client 10 ist offline" lauten. Alle Systeme, die das Topic "Offline-Client" abonniert haben, erhalten darauf hin diese Nachricht. Somit werden interessierte Systeme vom "ableben" eines Clients benachrichtigt, ohne dass sie diesen überwachen müssten.
Leichtgewichtiges Protokoll für schwere Daten
MQTT ist ein sehr einfach gehaltenes Protokoll, dass trotz Einfachheit aber tolle Funktionen bietet. Ich meine : hey, wir haben es selber für S7 implementiert! Wer mich kennt weiss also: kann so kompliziert nicht sein ;-) Weiterhin kann MQTT bis zu 256MB an Daten befördern.
MQTT im Netzwerk - auch im Web zuhause
MQTT funktioniert standardmäßig über TCP/IP oder Websockets. Dank der Websockets-Untersützung können auch Browser-Clients mit Javascript direkt beim Broker Topics abonnieren und somit Daten in Echtzeit erhalten. Websockets sind Teil des HTML 5 Standards und auch Proxy-fähig, d.h. MQTT-Kommunikation kann über einen HTTP-Proxy weitergeleitet werden. Websockets-URL fangen mit ws:// oder wss:// an.
Broker
Broker sind die Nachrichtenvermittler in der MQTT-Infrastruktur. Broker erhalten Daten von Publishern, puffern diese auf Anforderung und liefern diese in Echtzeit an Subscriber aus.
Allerdings heisst das nicht, das alle Clients auf einen Broker angewiesen sind. Broker unterstützen so genanntes Bridging, d.h. mann kann auch Broker mit Broker verbinden und die Nachrichten von einem Broker zum nächsten übermitteln lassen. Somit können z.B. Broker für Standorte zuständig sein, aber die Standorte auch untereinander verbinden.
Weiterhin sorgen Broker auch für Sicherheit und Nachrichtenpufferung.
Broker gibt es viele, sie müssen nur das MQTT Protokoll (aktuell ist die MQTT-Protokollversion 3.1.1) unterstützen. Es gibt Open Source Produkte wie den Mosquitto Broker aber auch sehr gute kommerzielle Produkte wie z.B. HiveMQ mit Clustering-Fähigkeiten.
MQTT - der Ring der sie alle bindet
Aufgrund der Einfachheit des Protokolls gibt es MQTT-Bibliotheken für so ziemlich alles, was 0 und 1 unterscheiden kann. Unser Team hat es für S7 implementiert, es gibt MQTT aber auch für praktisch alle Programmiersprachen und auch für Systeme wie z.B. LabView.
Somit lassen sich innerhalb einer Industrieumgebung die unterschiedlichsten Systeme zusammenschalten, aber ebend auch aus der Industrieumgebung hinaus in die klassische IT-Welt bis "rauf" in die Cloud!
Nun ist MQTT aber auch kein IT-Exot der OASIS Standardisiert ist, sondern auch ein Protokoll mit ISO/IEC-Heiligsprechung (ISO/IEC 20922:2016).
Schaut selbst mal nach unter http://www.mqtt.org und http://www.iso.org/iso/catalogue_det...csnumber=69466
MQTT - wozu?
Ich habe Euch ja nun den Feature-Blumenstrauss von MQTT vorgestellt. Aber warum soll das jetzt besser sein oder als Alternative zu etablierten Standards wie z.B. OPC oder OPC-UA in Erwägung gezogen werden?
Zunächst einmal Entkoppelt MQTT Sender und Empfänger wunderbar voneinander. Sender könen Daten zum Broker senden und sind danach "fertig", einer oder viele Empfänger können diese Daten abonnieren, ohne dass der Sender überhaupt weiss, wer der oder die Clients sind. Bei OPC ist das ähnlich, aber MQTT funktioniert eben nicht nur im Industrial Engineering und der Hausautomation. Ausserdem is MQTT viel billiger, praktisch alles an MQTT ist Open Source bzw. frei erhältlich. Weiterhin wird MQTT von modernen IT-Diensten wie IoT verwendet.
MQTT kann jeder "sprechen", der LabView End-of-Line Tester, die Siemens-Steuerung, der Arduino Microcontroller oder der Raspberry Pi. Und natürlich alle PC-Anwendungen die MQTT unterstützen bzw. sämtliche Individualprojekte - einfach MQTT Bibliothek einbinden und die Kommunikation ist in 10 Zeilen fertig programmiert.
MQTT ersetzt natürlich die etablierten Standards nicht, es kann es aber in bestimmten Szenarien und es ist eine tolle Ergänzung. Wer einmal Publisher-Subscriber-Systeme aufgebaut hat wird sie schon als eleganten Fortschritt ansehen.
Weiterhin ist MQTT besser als selbgestrickte S7 TCP-Kommunikation mit unglaublich "genialen" Selbstbau-Binärprotokollen. Warum, lies das nächste Kapitel.
MQTT - Fehlersuche mal einfach
Das bekannte Netzwerkanalyseprogramm Wireshark kennt das MQTT Protokoll. Somit kann man mit Wireshark die komplette MQTT-Kommunikation einsehen, protokollieren und analysieren. Bis ins Detail!
MQTT S7 - Worum es hier eigentlich geht :-)
Ok, jetzt aber zu Theme SPS. Unter
https://github.com/CarstenMaul/MQTT-Siemens-S7-300
könnt Ihr euch das aktuelle S7 Projekt inkl. Anleitung runterladen.
Ein Beispielprojekt in der Datei MQTT_Example.scl liegt bei. Alle Funktionen werden in diesem Beispielprojekt exemplarisch angesteuert: Connect, Publish, Susbsribe, Unsubscribe, Disconnect.
Das Projekt unterstützt sowohl CPUs mit integriertem Profinet als auch mit CP-Ethernet-Baugruppe.
Schaut Euch unser Werk mal an. Über Feedback würden wir uns sehr freuen, über erkannte Fehler natürlich um so mehr ;-)
Einen Broker könnt Ihr euch unter
http://www.mosquitto.org
laden. Den MQTT-Client MQTT.fx, der auch als Desktopanwendung die Möglichkeit gibt alle MQTT-Funktionen zu testen und mit einem Broker zu kommunizieren, gibt es hier:
http://mqttfx.jfx4ee.org/
So, jetzt hoffentlich viel Spass mit dieser Technologie.
Und bitte vergesst nicht: alle Software und Quellcodes ohne Gewähr! Ihr bekommt den S7 Quellcode zur freien Nutzung, der Einsatz in Euren Projekten erfolgt natürlich auf eigene Gefahr.
Gruß
Carsten