Die Druckversion wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

aiMOOC

Industrielle Kommunikation und Vernetzung – MQTT für Zustandsdaten einordnen

QR-Code

Einleitung

Industrielle Kommunikation und Vernetzung – MQTT für Zustandsdaten einordnen zeigt Dir, wie Zustandsdaten in einer virtuellen Anlage über MQTT strukturiert und verteilt werden. Im Mittelpunkt stehen Broker, Topics und Zustellverhalten. Du arbeitest mit kurzen Lerneinheiten, Signalverläufen und einer fiktiven Ausbildungsanlage.

Zielgruppe: Ausbildung in Automatisierungs-, Elektro-, IT- und Mechatronikberufen.

Kurzbeschreibung: Broker, Themen und Zustellverhalten. Du ordnest Zustandsdaten ein, testest Publish/Subscribe lokal und begründest QoS- sowie Retain-Entscheidungen.

Sicherheitsrahmen: Alle praktischen Beispiele verwenden ausschließlich `localhost`, virtuelle Komponenten und fiktive Daten. Verwende keine fremden Netze, Produktivanlagen, Zugangsdaten, Kundendaten oder nicht ausdrücklich freigegebene Broker.

Lernziele

Nach dem Kurs kannst Du:

Broker: die Rolle des Brokers im Publish/Subscribe-Modell erklären.
Topics: Zustandsdaten in einer sinnvollen Topic-Hierarchie einordnen.
QoS: QoS 0, 1 und 2 unterscheiden und passend auswählen.
Retain: den Nutzen einer letzten bekannten Zustandsmeldung erklären.
Diagnose: lokale Signalverläufe beobachten und Fehler in Topic, QoS oder Retain begründet eingrenzen.

Ausbildungsfall: Virtuelle Anlage Zelle A1

Du arbeitest an einer rein virtuellen Förderbandzelle. Ein simulierter Motor liefert Temperatur und Vibration. Ein virtueller Steuerungsclient meldet den Anlagenzustand. Ein Diagnoseclient beobachtet die Daten.

Virtuelles Signal	Topic	Beispiel-Payload
Förderbandzustand	`ausbildung/zelleA1/foerderband/zustand`	`RUN`
Freigabe	`ausbildung/zelleA1/foerderband/freigabe`	`EIN`
Motortemperatur	`ausbildung/zelleA1/motor1/temperatur`	`54.2`
Motorvibration	`ausbildung/zelleA1/motor1/vibration`	`2.8`
Störung	`ausbildung/zelleA1/stoerung/code`	`VIB_HIGH`

Merke: Topic und Payload haben unterschiedliche Aufgaben. Das Topic ordnet eine Nachricht ein; die Payload enthält den Wert.

Kurze Lerneinheit 1: Broker

Ein MQTT-Broker ist die zentrale Vermittlungsstelle. Publisher senden Nachrichten an den Broker. Subscriber abonnieren passende Topics. Publisher und Subscriber müssen einander nicht direkt kennen.

Rolle	In Zelle A1
Publisher	virtueller Temperatursensor
Broker	lokaler MQTT-Broker
Subscriber	Diagnoseanzeige

Einordnen: MQTT nutzt ein Publish/Subscribe-Modell. Der Broker verteilt passende Nachrichten an Abonnenten.

Basisaufgabe 1: Wer macht was?

Ordne gedanklich zu: Temperatursensor – Broker – Diagnoseanzeige.

Hilfe 1: Wer erzeugt den Messwert?

Hilfe 2: Wer verteilt ihn?

Hilfe 3: Wer möchte ihn sehen?

Begründetes Feedback: Der Sensor ist Publisher, weil er Daten veröffentlicht. Der Broker vermittelt, weil Nachrichten über ihn laufen. Die Diagnoseanzeige ist Subscriber, weil sie Daten abonniert.

Kurze Lerneinheit 2: Topics

Topics strukturieren Nachrichten hierarchisch. Der Schrägstrich `/` trennt Ebenen.

Beispiel: `ausbildung/zelleA1/motor1/temperatur`

Bei Subscriptions darfst Du Wildcards verwenden:

`+`: genau eine Topic-Ebene.
`#`: mehrere nachfolgende Ebenen.

Beispiel: `ausbildung/zelleA1/motor1/#` empfängt alle Nachrichten unterhalb von `motor1`.

Wichtig: `+` und `#` gehören in Topic-Filter von Subscriptions, nicht in veröffentlichte Topic-Namen.

Anwendungsaufgabe 1: Passender Topic-Filter

Du möchtest Temperatur und Vibration von `motor1` gemeinsam beobachten.

Welcher Filter ist passend?

`ausbildung/zelleA1/motor1/#`

Hilfe 1: Beide Werte liegen unter derselben Elternstruktur.

Hilfe 2: `#` umfasst beliebig viele nachfolgende Ebenen.

Begründetes Feedback: Der Filter endet nach `motor1` mit `#` und erfasst deshalb sowohl `temperatur` als auch `vibration` sowie weitere Untertopics. Ein `+` würde nur genau eine einzelne Ebene ersetzen.

Kurze Lerneinheit 3: QoS und Zustellverhalten

QoS beschreibt den Grad der Zustellsicherung einer MQTT-Nachricht.

QoS	Bedeutung	Typische Einordnung im Ausbildungsfall
0	höchstens einmal	schneller, zyklischer Messwert
1	mindestens einmal	wichtiger Zustandswechsel; Duplikate möglich
2	genau einmal	seltene Fälle mit besonders strenger Zustellanforderung

Merke: Höhere QoS-Stufen erzeugen zusätzlichen Protokollaufwand. QoS 1 kann eine Nachricht mehrfach zustellen; die Anwendung muss damit umgehen können.

Signalverlauf: Was ist wirklich wichtig?

Fiktiver Verlauf der Motorvibration:

Zeit	0 s	2 s	4 s	6 s	8 s	10 s
Vibration in mm/s	1,2	1,3	1,5	2,4	3,5	4,1
virtueller Zustand	normal	normal	normal	erhöht	Warnung	Störung

Diagnosefrage: Welche Information darf eher einmal fehlen: ein einzelner Zwischenwert oder die Störungsmeldung?

Begründetes Feedback: Bei einem schnellen Messwertstrom kann ein einzelner fehlender Zwischenwert je nach Prozess tolerierbar sein. Eine Störungsmeldung ist meist wichtiger und wird deshalb eher mit stärkerer Zustellsicherung behandelt.

Kurze Lerneinheit 4: Retain

Mit dem Retain-Flag kann der Broker die letzte retained veröffentlichte Nachricht eines Topics speichern. Ein neuer passender Subscriber erhält diesen letzten bekannten Wert beim Abonnieren.

Beispiel: `ausbildung/zelleA1/foerderband/zustand = STOP`

Das ist nützlich, wenn eine neu gestartete Diagnoseanzeige sofort den letzten Zustand sehen soll.

Nicht verwechseln: Retain ist kein Zeitreihenarchiv. Es ersetzt keine Historian- oder Datenbankfunktion.

Basisaufgabe 2: Retain einordnen

Eine Anzeige startet neu. Sie soll sofort wissen, ob das Förderband zuletzt `RUN` oder `STOP` gemeldet hat.

Entscheidung: Für den letzten Anlagenzustand kann Retain sinnvoll sein.

Hilfe 1: Muss die Anzeige auf die nächste Zustandsänderung warten?

Hilfe 2: Gesucht ist genau der letzte bekannte Zustand.

Begründetes Feedback: Retain löst das Startwertproblem, weil der Broker den letzten retained Wert eines passenden Topics an einen neuen Subscriber senden kann.

Kurze Lerneinheit 5: Lokaler Praxistest

Verwende nur einen lokalen, selbst kontrollierten MQTT-Broker. Die folgenden Befehle adressieren ausschließlich `localhost`.

Terminal A – Diagnose abonnieren:

mosquitto_sub -h localhost -t 'ausbildung/zelleA1/#' -v

Terminal B – fiktive Temperatur senden:

mosquitto_pub -h localhost -t 'ausbildung/zelleA1/motor1/temperatur' -m '54.2' -q 0

Virtuellen Anlagenzustand mit QoS 1 und Retain setzen:

mosquitto_pub -h localhost -t 'ausbildung/zelleA1/foerderband/zustand' -m 'BEREIT' -q 1 -r

Fiktive Freigabe senden:

mosquitto_pub -h localhost -t 'ausbildung/zelleA1/foerderband/freigabe' -m 'EIN' -q 1

Diese Nachrichten steuern keine reale Anlage. Sie dienen ausschließlich als lokale Simulation.

Interaktive Steuerungsaufgabe: Virtuelles Förderband

Starte die lokale Subscription auf `ausbildung/zelleA1/#`.
Sende die fiktive Freigabe `EIN`.
Sende anschließend den Zustand `RUN`.
Ändere den Zustand auf `STOP`.
Beobachte Topic und Payload im Diagnosefenster.

Hilfe 1: Publisher und Subscriber verbinden sich beide mit `localhost`.

Hilfe 2: Die Freigabe und der Zustand sind unterschiedliche Topics.

Hilfe 3: Nutze `-v`, damit Topic und Payload gemeinsam angezeigt werden.

Begründetes Feedback: Eine saubere Trennung von `freigabe` und `zustand` macht die Bedeutung der Nachrichten eindeutig. Die Diagnose kann dadurch erkennen, was angefordert wurde und welcher Zustand tatsächlich gemeldet wurde.

Interaktive Diagnoseaufgabe: Der Wert fehlt

Der Subscriber lauscht auf:

`ausbildung/zelleA1/motor2/#`

Der Publisher sendet auf:

`ausbildung/zelleA1/motor1/temperatur`

Aufgabe: Finde den Fehler, ohne Netzwerke oder fremde Systeme zu untersuchen.

Hilfe 1: Vergleiche jede Topic-Ebene.

Hilfe 2: Achte auf `motor1` und `motor2`.

Begründetes Feedback: Die Topic-Strukturen passen nicht zusammen. Der Subscriber erwartet Daten unter `motor2`, während der Publisher unter `motor1` sendet. Für diesen Fehler ist keine Netzwerkanalyse außerhalb der lokalen Lernumgebung nötig.

Kurze Lerneinheit 6: Verbindung und Abgrenzung

MQTT kann in verschiedenen Netzarchitekturen eingesetzt werden. Für diesen Kurs reicht ein lokaler Broker.

Praxisregel: Erst lokal simulieren, dann nur in ausdrücklich freigegebenen Ausbildungs- oder Testumgebungen arbeiten.

Nicht Gegenstand praktischer Übungen: fremde Broker suchen, Zugangsdaten testen, Produktivnetze scannen, reale Anlagen beeinflussen oder sensible Daten veröffentlichen.

Lernpfad mit Basis, Anwendung und Transfer

Basis

Aufgabe: Ordne Broker, Publisher, Subscriber, Topic und Payload im Ausbildungsfall korrekt zu.

Gestufte Hilfe:

Hilfe 1: Der Sensor erzeugt den Wert.
Hilfe 2: Der Broker verteilt Nachrichten.
Hilfe 3: Das Topic beschreibt den Informationskanal; die Payload enthält den Wert.

Begründetes Feedback: Die Rollen müssen getrennt werden, weil MQTT nicht auf einer direkten Punkt-zu-Punkt-Beziehung zwischen Sensor und Anzeige beruht.

Anwendung

Aufgabe: Entscheide für drei Datenarten:

Datenart	Mögliche Einordnung	Begründung
zyklische Temperatur	QoS 0	einzelne Zwischenwerte können je nach Anwendung entbehrlich sein
Zustandswechsel RUN zu STOP	QoS 1	Zustandswechsel soll zuverlässig ankommen; Duplikate müssen beherrscht werden
letzter bekannter Zustand	Retain	neue Subscriber erhalten sofort einen Startwert

Hilfe 1: Trenne Zustellsicherung und Speicherung.

Hilfe 2: QoS und Retain lösen unterschiedliche Probleme.

Begründetes Feedback: QoS beschreibt die Zustellsicherung einer Nachricht. Retain beschreibt, ob der Broker den letzten retained Wert für spätere neue Subscriber bereithält.

Transfer

Aufgabe: Entwirf eine Topic-Struktur für zwei Motoren, einen Energiezähler und eine Störmeldung. Begründe für jedes Topic QoS und Retain.

Hilfe 1: Beginne mit `ausbildung/zelleA1/`.

Hilfe 2: Trenne Gerät, Signal und Bedeutung.

Hilfe 3: Frage bei jedem Wert: Ist ein einzelner Verlust tolerierbar? Braucht ein neuer Subscriber sofort einen letzten Zustand?

Begründetes Feedback: Eine gute Lösung ist nicht nur syntaktisch korrekt, sondern macht die Anlagenstruktur lesbar und ordnet Zustellverhalten anhand der fachlichen Bedeutung des Signals ein.

Mediengestützte Vertiefung

Das Bild zeigt den Aufbau eines MQTT-CONNECT-Pakets. Für die Ausbildung ist vor allem wichtig: Ein Client muss zunächst eine Verbindung zum Broker aufbauen, bevor Publish oder Subscribe möglich sind.

Die Darstellung zeigt eine Variante mit mehreren Listenern und TLS. Im Kurs wird diese Architektur nur konzeptionell betrachtet; praktische Übungen bleiben lokal und ohne echte Zugangsdaten.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Welche Aufgabe hat ein MQTT-Broker? (Er empfängt Nachrichten und verteilt sie an passende Subscriber) (!Er misst direkt die Motortemperatur) (!Er ersetzt jeden Publisher) (!Er ist ausschließlich ein Datenspeicher)

Was beschreibt ein MQTT-Topic? (Den Informationskanal einer Nachricht) (!Die elektrische Versorgungsspannung) (!Die IP-Adresse jedes Subscribers) (!Die Dateigröße einer Datenbank)

Was bedeutet QoS 0? (Höchstens einmal zustellen) (!Mindestens einmal zustellen) (!Genau zweimal zustellen) (!Jede Nachricht dauerhaft speichern)

Was bedeutet QoS 1? (Mindestens einmal zustellen) (!Höchstens einmal zustellen) (!Nur retained Nachrichten zustellen) (!Genau einmal ohne Bestätigung zustellen)

Welche Besonderheit kann bei QoS 1 auftreten? (Eine Nachricht kann mehrfach ankommen) (!Topics dürfen keine Schrägstriche enthalten) (!Der Broker wird umgangen) (!Subscriber müssen Publisher direkt kennen)

Was ist die Hauptidee von Retain? (Der Broker hält den letzten retained Wert eines Topics für neue Subscriber bereit) (!Der Broker speichert automatisch den gesamten Signalverlauf) (!Jeder Subscriber sendet die Nachricht zurück) (!Das Topic wird verschlüsselt)

Welche Wildcard steht in MQTT für mehrere Topic-Ebenen? (#) (!+) (!/) (!?)

Welche Wildcard ersetzt genau eine Topic-Ebene? (+) (!#) (!/) (!*)

Welcher Broker ist für die Übungen vorgesehen? (Ein lokaler selbst kontrollierter Broker auf localhost) (!Ein zufällig gefundener Broker im Internet) (!Der Broker einer Produktivanlage) (!Ein fremder Kundenbroker)

Warum werden Freigabe und Zustand in getrennten Topics geführt? (Damit Anforderung und tatsächlicher Zustand eindeutig unterscheidbar sind) (!Damit MQTT ohne Broker funktioniert) (!Damit jede Nachricht QoS 2 benötigt) (!Damit keine Payload mehr nötig ist)

Memory

Broker	verteilt Nachrichten
Publisher	veröffentlicht Daten
Subscriber	abonniert Informationen
Topic	ordnet Nachrichten hierarchisch ein
Payload	enthält den Nachrichtenwert
QoS 1	mindestens einmal
Retain	letzter bekannter retained Wert

Drag and Drop

Ordne die richtigen Begriffe zu.	Thema
Broker	zentrale Vermittlungsstelle
Topic	hierarchischer Informationskanal
QoS	Zustellsicherung
Retain	letzter gespeicherter retained Wert
Subscriber	Empfänger über Subscription

Kreuzworträtsel

Broker	Welche MQTT-Komponente verteilt Nachrichten zwischen Clients?
Topic	Wie heißt der hierarchische Informationskanal einer MQTT-Nachricht?
Payload	Wie heißt der eigentliche Nachrichteninhalt?
Publish	Welcher englische Begriff bezeichnet das Veröffentlichen einer Nachricht?
Retain	Welches Flag hält den letzten retained Wert eines Topics bereit?
Subscriber	Wie heißt ein Client, der Topics abonniert?

LearningApps

Lückentext

Offene Aufgaben

Leicht

Broker-Skizze: Zeichne Publisher, Broker und Subscriber der virtuellen Zelle A1 und beschrifte die Nachrichtenwege.
Topic-Baum: Stelle die vorgegebenen Topics als Baumstruktur dar.
Signal markieren: Markiere im Vibrationstrend den Übergang von normal zu Warnung und begründe Deine Wahl.
Rollenwechsel: Erkläre an einem Beispiel, warum ein MQTT-Client sowohl Publisher als auch Subscriber sein kann.

Standard

Filter entwickeln: Entwickle je einen Filter für alle Motordaten und nur für Zustandsmeldungen der Zelle A1.
QoS entscheiden: Ordne Temperatur, Störung und Zustandswechsel einer sinnvollen QoS-Stufe zu und begründe jede Entscheidung.
Retain prüfen: Entscheide für fünf fiktive Signale, ob Retain sinnvoll ist.
Fehlersuche: Erstelle drei lokale Fehlerfälle mit falschem Topic, falschem Filter oder fehlendem Retain und dokumentiere die Diagnose.

Schwer

Topic-Konzept: Entwirf eine skalierbare Topic-Struktur für drei virtuelle Zellen mit je zwei Motoren.
Payload-Konzept: Vergleiche einfache Zahlenwerte mit strukturierten fiktiven JSON-Payloads und diskutiere Vor- und Nachteile.
Zustellkonzept: Entwickle für eine virtuelle Warnkette ein QoS- und Retain-Konzept und begründe mögliche Duplikatbehandlung.
Lernvideo: Produziere ein kurzes eigenes Erklärvideo, das Broker, Topic, QoS und Retain anhand einer ausschließlich lokalen Simulation zeigt.

Lernkontrolle

Architektur begründen: Erkläre, warum die Diagnoseanzeige den Temperatursensor nicht direkt kennen muss, und leite daraus einen Vorteil des Publish/Subscribe-Modells ab.
Topic-Fehler: Ein Subscriber empfängt keine Daten. Entwickle eine lokale Prüfreihenfolge, die zuerst Topic und Filter betrachtet, bevor andere Ursachen untersucht werden.
QoS-Abwägung: Begründe, warum QoS 2 nicht automatisch für jedes Sensorsignal die beste Wahl ist.
Startwertproblem: Eine Visualisierung startet nach dem Publisher. Beschreibe, wie Retain helfen kann und welche Grenze Retain gegenüber einer Historie hat.
Signalverlauf: Bewerte den gezeigten Vibrationsverlauf und entscheide, welche Nachricht eher als Zustandsmeldung statt als reiner Messwert modelliert werden sollte.
Neues Anlagenmodell: Übertrage das Topic-Prinzip auf eine virtuelle Pumpstation mit Druck, Drehzahl, Freigabe und Störung und begründe Deine Struktur.

Lernnachweis

Für einen Lernnachweis solltest Du zeigen, dass Du:

Broker, Publisher und Subscriber sicher unterscheiden kannst.
eine verständliche Topic-Hierarchie für fiktive Zustandsdaten entwickeln kannst.
`+` und `#` in Subscriptions korrekt einordnest.
QoS 0, 1 und 2 fachlich unterscheiden und begründet auswählen kannst.
Retain als letzten bekannten retained Zustand, aber nicht als Historie, erklären kannst.
einen lokalen MQTT-Test mit fiktiven Daten dokumentieren kannst.
Diagnoseentscheidungen anhand von Topic, Payload, QoS und Retain begründen kannst.
Sicherheitsgrenzen einhältst und keine fremden oder produktiven Systeme verwendest.

Fachquellen und Medienrechte

Fachlich geprüft:

OASIS MQTT Version 5.0: normative Grundlage zu Topics, Topic-Filtern, QoS und Retain.
Eclipse Mosquitto Documentation: Broker sowie `mosquitto_pub` und `mosquitto_sub`.
Node-RED Cookbook – Connect to an MQTT Broker: lokaler MQTT-Broker auf `localhost`.
Wikipedia – MQTT: deutschsprachiger Überblick.

Verwendete Wikimedia-Commons-Medien:

Arquitetura MQTT exemplo.png – CC BY-SA 4.0.
MQTT multiple broker 02.svg – CC BY-SA 4.0.
MQTT protocol example without QoS.svg – unter anderem CC BY-SA 4.0.
MQTT Publish packet.svg – CC BY-SA 4.0.
MQTT connect package.svg – CC BY-SA 4.0.
MQTT single broker multiple listener.svg – CC BY-SA 4.0.
MQTT single broker multiple listener tls client.svg – CC BY-SA 4.0.
MQTT autenticacion.png – CC BY-SA 4.0.

YouTube-Videos:

MQTT schnell erklärt – Topics, Retain, QoS von Torben Ledermann.
MQTT Retained messages – MQTT Essentials Part 9 von HiveMQ.
Learn MQTT with Node-RED and Mosquitto under 5 mins von IoT Frontier.

Die YouTube-Inhalte werden über die von YouTube vorgesehene Einbettungsfunktion angezeigt und nicht als eigene OER-Dateien übernommen. Rechte an den Videos verbleiben bei den jeweiligen Rechteinhabern. Die Commons-Dateien sind entsprechend ihrer jeweiligen Dateibeschreibungsseite frei lizenziert. Quellen und Medienlinks wurden für diesen Kurs geprüft; Stand: 7. Oktober 2026.