Step 7 MQTT - IoT und Machine2Machine Kommunikation für Siemens S7

Lace

Member
Beiträge
10
Punkte Reaktionen
11
Zuviel Werbung?
->Hier kostenlos registrieren
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_detail.htm?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
 
Zuletzt bearbeitet:

Ralle

Supermoderator
Teammitglied
Beiträge
14.246
Punkte Reaktionen
3.296
Gute Idee, auf jeden Fall mal Wert, getestet zu werden.
Muß mich allerdings erst einmal ein wenig damit befassen, also Broker- und Client-Software, was gibt es, wie nutzt man das, klar.
Dann könnte man mal ein paar Performance-Tests machen, im Vergleich zu OPC und zum S7-Protokoll vielleicht.
Man muß natürlich hier in der SPS definieren, welche Daten man zur Verfügung stellt, richtig?
 
OP
L

Lace

Member
Beiträge
10
Punkte Reaktionen
11
Zuviel Werbung?
->Hier kostenlos registrieren
Hallo Ralle,




MQTT sendet Daten als Binärdaten oder als UTF-8 String.


Wir nutzen Binärdaten als "Nutzlast" und serialisieren diese mit dem MessagePack Serialisierungsformat. MessagePack ist 100% kompatibel zum JSON Datenformat.


MessagePack ist sehr effizient und leicht zu nutzen. Im Endeffekt stellst Du die Daten in der S7 in einem Datanblock zusammen, aber vor jedes Datum kommt ein Steuerbyte, dass den Typ des Datums festlegt. Beispiel: in deinem DB hast Du einen 2 Byte Integer, vor die 2 Byte des Integer schreibst Du 0xce als Steuerbyte und MessagePack weiss, dass die nächsten 2 Byte ein 16 Bit unsigned Integer sind. Vor die ganzen Daten kommt noch ein Struktur-Steuerbyte dass die Daten z.B. alls Array kennzeichnet, z.B. bedeutet Das Struktur-Steuerbyte 0x93 : Array mit 3 Werten.


Beispiel:
In Deinem DB steht
0x93 - Array mit 3 Werten
0xce - 16 Bit unsigned Integer
2 byte S7-Integer
0xce
noch ein 2 byte S7 Integer
0xce
und der letzte 2 byte Integer im Array


Oder als Hex-Daten, wenn wir annehmen, dass alle Integer 0 sind:


0x93 0xce 0x00 0x00 0xce 0x00 0x00 0xce 0x00 0x00


Beim PC kommt dann raus:


[0,0,0] => Array mit 3 Integern, alle mit dem Wert 0

Und noch ein "Schmankerl": MessagePack kann auch Key-Value Arrays erzeugen,
also z.B.:

"Pruefdruck" : 12
"Drehzahl" : 345

Du nimmst dann deinen DB mit den Daten, sendest diesen via MQTT als Bytes an einen PC und dekodierst die Binärdaten mit einer MessgePack-Bibliothek mit dem Unpack-Befehl und schon bekommst Du ein schönes Object, hier z.B. als Array, mit allen Daten als Variablen enthalten - ohne OPC dazwischen. Einfach nur durch Steuerbyte-Kodierung.


Auf der PC-Seite sind MQTT als Subscriber + Messagepack nicht mehr als 10 Befehle. Und schon kriegst Du Daten in Echtzeit und Ereignisbasiert geliefert, die direkt als Nachrichtenobjekte "frei Haus" kommen.


http://msgpack.org/index.html


Die Tage schreibe ich zu MessagePack noch einen Artikel.




Zum Broker:
Du kannst die Brokersoftware auf einem PC installieren.
Du kannst aber auch einen Raspberry Pi in einem Hutschienengehäuse nehmen, das Betriebssystem Raspian auf eine SD-Karte kopieren, in Raspbian mit dem Befehl "apt-get install mosquitto" den Broker installieren und schon hast Du einen Broker im Schaltschrank.


Oder Du sendest gleich in die Cloud:
https://azure.microsoft.com/en-us/documentation/articles/iot-hub-mqtt-support/
http://docs.aws.amazon.com/iot/latest/developerguide/protocols.html
 
Zuletzt bearbeitet:
OP
L

Lace

Member
Beiträge
10
Punkte Reaktionen
11
Und noch eine Kleinigkeit zu MessagePack:

MessagePack ist per Definition Big Endian und somit kompatibel zum Byteformat der S7-300 und der S7-1x00 bei der Verwendung von "Standard"-DBs (nicht bei "optimierten" DBs).

Das bedeutet auch, dass die ganze "Byte Dreherei" bereits auf der PC-Seite von der MessagePack-Bibliothek übernommen wird, raus kommt auf der PC-Seite immer Little Endian Byteformat (also Intel kompatibel).
 

INSEVIS-Service

Well-known member
Beiträge
275
Punkte Reaktionen
25
Ergänzend: für INSEVIS CPU s gibt es auf unserer Homepage ein Beispiel mit angepassten Systemfunktionen für die 300er Umgebung in TIA V 14.

Es handelt sich um das Siemens Beispiel mit ausgetauschten T-Bausteinen.
 
Oben