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

Digitale Vernetzung und Industrial IoT – MQTT-Themen sinnvoll strukturieren

QR-Code

Einleitung

Digitale Vernetzung und Industrial IoT – MQTT-Themen sinnvoll strukturieren

Für die Ausbildung | 6 kurze Lerneinheiten | ca. 90 Minuten | Voraussetzungen: grundlegende Netzwerk- und Python-Kenntnisse.

In diesem Kurs strukturierst Du MQTT-Topics für eine fiktive Produktionslinie. Du ordnest Geräte, testest Wildcards und planst Zugriffsrechte nach dem Prinzip der geringsten Berechtigung.

Sicherheitsrahmen: Alle Geräte, Rollen und Messwerte sind erfunden. Das Python-Labor arbeitet vollständig offline. Der optionale MQTT-Broker darf ausschließlich auf Deinem eigenen oder ausdrücklich freigegebenen Ausbildungsrechner über 127.0.0.1 laufen. Keine fremden Netze, Produktionsanlagen, Zugangsdaten oder Kundendaten verwenden. Externe Videos und iFrames sind nur Lernmedien, keine Testbroker; ihr Aufruf kann Verbindungsdaten an die jeweiligen Anbieter senden.

Symbol: Tichovský Petr / chris, gemeinfrei.

Ausbildungsfall: Zwei Geräte in Werk 1

Dein Lernbetrieb betreibt nur als Modell die Linie A mit presse01 und ofen02. Die Geräte liefern Temperaturen. Eine Bedienoberfläche (HMI) liest Daten; ein Leitdienst darf ausschließlich einen virtuellen Anzeigebefehl an presse01 senden.

training
└── werk1
    └── linieA
        ├── presse01
        │   ├── telemetry/temperatur
        │   ├── state/betrieb
        │   └── command/led_sim
        └── ofen02
            └── telemetry/temperatur

Lernziel: Du begründest, warum der Aufbau training/werk1/linieA/gerät/datenart/merkmal Geräte, Daten und Zugriffsrechte unterscheidbar macht. training ist dabei nur ein Namenspräfix, keine Sicherheitsschranke.

Lerneinheit 1: MQTT in 10 Minuten

Merke: Ein Publisher sendet Nachrichten mit Topic und Payload an den Broker. Ein Subscriber abonniert einen Topic-Filter. Der Broker verteilt passende Nachrichten. MQTT ist Publish/Subscribe, kein direkter Sensordatenabruf durch jede Anzeige.

Schaubild: Ademant, CC BY-SA 4.0.

Video: HiveMQ, „What is MQTT | MQTT Essentials Part 1“ (englisch; YouTube-Einbettung, keine freie Weiterverwendung behauptet).

Basis-Check: Wer verteilt eine Temperatur-Nachricht? Feedback: Der Broker, nicht der Sensor; der Sensor veröffentlicht nur an sein Topic.

Lerneinheit 2: Die Topic-Hierarchie

Ein Topic besteht aus Ebenen, getrennt durch /. MQTT unterscheidet Groß- und Kleinschreibung. In unserem Modell nutzen wir kurze ASCII-Namen ohne Leerzeichen.

Topic	Inhalt	Beispiel-Payload (fiktiv)
`training/werk1/linieA/presse01/telemetry/temperatur`	Temperatur	`21.5`
`training/werk1/linieA/presse01/state/betrieb`	Zustand	`bereit`
`training/werk1/linieA/presse01/command/led_sim`	Virtuelle Anzeige	`an`
`training/werk1/linieA/ofen02/telemetry/temperatur`	Temperatur	`22.0`

Darstellung eines PUBLISH-Pakets: Blacktron, CC BY-SA 4.0. Das Bild zeigt das Paketformat; unsere Topics sind Anwendungsbeispiele.

Anwendungsfrage: Wie lautet das Topic für die Temperatur von ofen02? Feedback: training/werk1/linieA/ofen02/telemetry/temperatur ist konsistent, weil nur das Gerätesegment wechselt.

Lerneinheit 3: Topic-Filter und Wildcards

+ steht für genau eine Ebene; # für null oder mehrere Ebenen und steht nur am Ende. Beides darf in Abonnement-Filtern, aber nicht in veröffentlichten Topic-Namen stehen.

Filter	Ergebnis im Ausbildungsfall
`training/werk1/linieA/+/telemetry/temperatur`	Temperatur beider Geräte
`training/werk1/linieA/presse01/telemetry/#`	Telemetrie von presse01, auch die Elternebene
`training/werk1/linieA/presse01/state/+`	Zustände unmittelbar unter state
`training/werk1/linieA/#`	Alle Topics der Modelllinie; für HMI zu weit gefasst

Sonderfall: sport/# passt auch zu sport. Ein Filter, der mit + oder # beginnt, erfasst keine mit $ beginnenden Broker-Topics wie $SYS/....

Video: HiveMQ, MQTT Topics & Wildcards, eingebettet aus der fachlichen MQTT-Essentials-Erklärung.

Denkprobe: Warum ist training/werk1/linieA/+/telemetry/# besser für die HMI als #? Feedback: Er trifft nur freigegebene Messdaten innerhalb einer Linie und vermeidet unnötige Nachrichten und Einsichten.

Lerneinheit 4: Berechtigungen unterscheiden

Authentifizierung klärt die Identität; Autorisierung klärt, ob ein Client auf einem Topic publizieren oder abonnieren darf. Eine ACL kann dafür brokerseitig Regeln abbilden. Ein guter Topic-Baum erleichtert die Regeln, erzwingt sie aber nicht automatisch.

Fiktive Rolle	Publizieren	Abonnieren
`presse01`	eigene `telemetry/#` und `state/#`	eigenes `command/#`
`ofen02`	eigene `telemetry/#`	nichts
`hmi`	nichts	`+/telemetry/#` und `+/state/#` in Linie A
`leitsystem`	`presse01/command/#`	`presse01/state/#`

Die Pfade in der Tabelle beziehen sich alle auf training/werk1/linieA/. Die Rechte sind eine Lernrichtlinie, nicht bereits eine reale Broker-Konfiguration. Abonnement-Rechte lassen sich je nach Broker unterschiedlich durchsetzen; die Offline-Simulation akzeptiert nur exakt aufgeführte Filter.

MQTT-Authentifizierung, Brivadeneira, CC BY-SA 4.0. Authentifizierung ist nicht gleich Berechtigung.

Transferfrage: Darf hmi einen virtuellen Steuerbefehl publizieren? Feedback: Nein. Lesen ist nicht Schreiben; das verhindert ungewollte Zustandsänderungen.

Lerneinheit 5: Lokales Offline-Labor mit Python

Umgebung A (vollständig isoliert): Speichere den folgenden Code als mqtt_labor.py und starte ihn mit python3 mqtt_labor.py auf Deinem lokalen Rechner. Python 3 genügt. Kein Netzwerkzugriff, keine Pakete, keine Konten. Der Code simuliert Topic-Matching und eine vereinfachte Berechtigungsliste, nicht die Sicherheitsprüfung eines echten Brokers.

BASE = "training/werk1/linieA"
RECHTE = {
    "presse01": {
        "pub": [f"{BASE}/presse01/telemetry/#", f"{BASE}/presse01/state/#"],
        "sub": [f"{BASE}/presse01/command/#"],
    },
    "ofen02": {
        "pub": [f"{BASE}/ofen02/telemetry/#"],
        "sub": [],
    },
    "hmi": {
        "pub": [],
        "sub": [f"{BASE}/+/telemetry/#", f"{BASE}/+/state/#"],
    },
    "leitsystem": {
        "pub": [f"{BASE}/presse01/command/#"],
        "sub": [f"{BASE}/presse01/state/#"],
    },
}

def trifft(filter_, topic):
    """Minimales Topic-Matching fuer die fiktive Unterrichtsumgebung."""
    if not filter_ or not topic:
        return False
    if topic.startswith("$") and filter_[0] in "+#":
        return False
    teile = filter_.split("/")
    ebenen = topic.split("/")
    for index, teil in enumerate(teile):
        if teil == "#":
            return index == len(teile) - 1
        if index >= len(ebenen):
            return False
        if teil != "+" and teil != ebenen[index]:
            return False
    return len(teile) == len(ebenen)

def erlaubt(rolle, aktion, ziel):
    regeln = RECHTE.get(rolle)
    if regeln is None or aktion not in ("pub", "sub"):
        return False
    if aktion == "sub":
        return ziel in regeln["sub"]  # Filter nur exakt aus der Liste
    if "+" in ziel or "#" in ziel:
        return False  # PUBLISH braucht ein konkretes Topic
    return any(trifft(f, ziel) for f in regeln["pub"])

tests = [
    ("presse01", "pub", f"{BASE}/presse01/telemetry/temperatur", True),
    ("presse01", "pub", f"{BASE}/ofen02/telemetry/temperatur", False),
    ("hmi", "sub", f"{BASE}/+/telemetry/#", True),
    ("hmi", "pub", f"{BASE}/presse01/telemetry/temperatur", False),
    ("leitsystem", "pub", f"{BASE}/presse01/command/led_sim", True),
]
for rolle, aktion, ziel, erwartet in tests:
    ergebnis = erlaubt(rolle, aktion, ziel)
    assert ergebnis == erwartet
    print(f"{rolle:11} {aktion:3} {'ERLAUBT' if ergebnis else 'GESPERRT'}  {ziel}")

werte = [21.1, 21.5, 22.0, 21.6, 21.3]
print("\nFiktive Temperaturkurve – Balken ueber 20 Grad:")
for minute, wert in enumerate(werte):
    print(f"{minute:02} min | {'#' * round((wert - 20) * 10):<20} {wert:.1f} Grad C")

if __name__ == "__main__":
    print("\nInteraktive Probe, nur offline; Ende mit leerer Rolle:")
    while True:
        rolle = input("Rolle [presse01/ofen02/hmi/leitsystem]: ").strip()
        if not rolle:
            break
        aktion = input("Aktion [pub/sub]: ").strip()
        ziel = input("Topic oder Topic-Filter: ").strip()
        print("ERLAUBT" if erlaubt(rolle, aktion, ziel) else "GESPERRT")

Sichtbares Testergebnis (Auszug):

presse01    pub ERLAUBT   .../presse01/telemetry/temperatur
presse01    pub GESPERRT  .../ofen02/telemetry/temperatur
hmi         sub ERLAUBT   .../+/telemetry/#
hmi         pub GESPERRT  .../presse01/telemetry/temperatur

Fiktive Temperaturkurve – Balken ueber 20 Grad:
00 min | ###########          21.1 Grad C
01 min | ###############      21.5 Grad C
02 min | #################### 22.0 Grad C
03 min | ################     21.6 Grad C
04 min | #############        21.3 Grad C

Interaktion: Gib beispielsweise hmi, dann pub, dann training/werk1/linieA/presse01/telemetry/temperatur ein. Ergebnis: GESPERRT. Mit presse01 und pub wird derselbe Pfad ERLAUBT. Das Feedback folgt aus den eingetragenen Rollenrechten.

Gestufte Hilfen:

Hinweis: Sieh in der Rechte-Tabelle auf die Spalte „Publizieren“.
Teilhilfe: Die HMI hat dort kein freigegebenes Topic.
Lösung mit Begründung: hmi darf nur lesen; eine veröffentlichte Nachricht müsste brokerseitig abgewiesen werden. Die Simulation meldet dies schon ohne Broker.

Lerneinheit 6: Optionaler lokaler MQTT-Transporttest

Umgebung B (nur mit vorhandener bzw. von der Ausbildungsstelle bereitgestellter Mosquitto-Installation): Erstelle lokal die Datei mqtt-lokal.conf:

listener 18883 127.0.0.1
allow_anonymous true
persistence false

Starte den Testbroker im ersten Terminal:

mosquitto -c mqtt-lokal.conf -v

Abonniere im zweiten Terminal:

mosquitto_sub -h 127.0.0.1 -p 18883 -t 'training/werk1/linieA/+/telemetry/#' -v

Veröffentliche im dritten Terminal nur den fiktiven Wert:

mosquitto_pub -h 127.0.0.1 -p 18883 -t 'training/werk1/linieA/presse01/telemetry/temperatur' -m '21.5'

Erwartet: Das zweite Terminal zeigt das Topic und 21.5. Beende die Prozesse nach dem Versuch mit Strg+C. Die Portbindung an 127.0.0.1 schließt Zugriffe über andere Netzwerkschnittstellen aus, sofern keine zusätzliche Weiterleitung eingerichtet ist.

Wichtig: Dieser anonyme Testbroker erzwingt keine Rollentrennung. Er dient nur dazu, PUBLISH und SUBSCRIBE lokal sichtbar zu machen. Nutze ihn niemals als Produktionskonfiguration oder in fremden Netzen. Für reale Systeme sind authentifizierte Identitäten, TLS, geprüfte ACLs und eine abgestimmte Betriebsfreigabe erforderlich.

Nachrichtenfluss bei QoS 0: Simon A. Eugster, CC BY-SA 4.0.

Video: HiveMQ, PUBLISH/SUBSCRIBE, eingebettet aus MQTT Essentials Part 4.

Zusatzwissen: QoS 0 bedeutet höchstens einmal, QoS 1 mindestens einmal mit möglichen Duplikaten, QoS 2 genau einmal auf der jeweiligen MQTT-Übertragungsstrecke. Ein QoS-Wert ersetzt weder Anlagensicherheit noch Anwendungsprüfung. Retain speichert die letzte Retained-Nachricht pro Topic im Broker.

Beispiel für TLS-Client-Authentifizierung: Ademant, CC BY-SA 4.0. Keine Aufforderung, reale Zertifikate zu verwenden.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Welche Aufgabe übernimmt ein MQTT-Broker? (Er verteilt Nachrichten an passende Abonnenten) (!Er erfasst immer selbst die Temperatur) (!Er ersetzt die Sensorik) (!Er vergibt automatisch sichere Rollen)

Wofür steht das Pluszeichen in einem Topic-Filter? (Genau eine Topic-Ebene) (!Beliebig viele Topic-Ebenen) (!Nur die Gerätekennung) (!Ein geheimes Passwort)

Wofür steht die Raute am Ende eines Topic-Filters? (Null oder mehrere Topic-Ebenen) (!Genau eine Topic-Ebene) (!Eine verschlüsselte Nachricht) (!Ein verpflichtendes Topic-Suffix)

Welche Aussage über Wildcards ist richtig? (Sie dürfen beim Abonnieren verwendet werden) (!Sie müssen in jedem Publish-Topic stehen) (!Sie sind Gerätenamen) (!Sie schalten ACLs aus)

Wie behandelt MQTT Groß- und Kleinschreibung in Topics? (Als unterschiedliche Zeichen) (!Es ignoriert sie immer) (!Es wandelt alles in Großbuchstaben um) (!Es erkennt nur Ziffern)

Welcher Abschnitt identifiziert im Kurs das einzelne Gerät? (presse01) (!training) (!telemetry) (!temperatur)

Was regelt eine ACL hauptsächlich? (Erlaubte Zugriffe auf Ressourcen und Aktionen) (!Die gemessene Temperatur) (!Den Stromverbrauch eines Sensors) (!Die Netzwerkkabellänge)

Welche Aktion ist der HMI im Ausbildungsfall erlaubt? (Abonnieren freigegebener Telemetrie) (!Publizieren virtueller Befehle) (!Publizieren auf allen Topics) (!Ändern fremder Brokerkonten)

Welche Adresse begrenzt den optionalen Broker auf den eigenen Rechner? (127.0.0.1) (!0.0.0.0) (!Eine fremde öffentliche IP-Adresse) (!Ein unbekannter Servername)

Welche Aussage zu MQTT QoS 1 stimmt? (Eine Nachricht kann mehrfach ankommen) (!Eine Nachricht wird niemals dupliziert) (!Eine Nachricht enthält immer einen Befehl) (!QoS 1 ersetzt die Zugriffskontrolle)

Begründetes Feedback zum Quiz: Der Broker verteilt Nachrichten; Filter begrenzen die Auswahl, nicht die Identität. ACLs unterscheiden Lesen und Schreiben. Lokales Testen reduziert Risiken, ersetzt aber keine Produktionssicherheit.

Memory

Broker	Verteilstelle für Nachrichten
Publisher	Sendender MQTT-Client
Subscriber	Abonnierender MQTT-Client
Topic	Pfad zur Kennzeichnung einer Nachricht
Payload	Inhalt einer MQTT-Nachricht
ACL	Regel für erlaubte Zugriffe
Pluszeichen	Platzhalter für genau eine Ebene

Drag and Drop

Ordne die richtigen Begriffe zu.	Thema
telemetry	Simulierte Messwerte
state	Gemeldeter Gerätezustand
command	Virtuelle Steueranweisung
Broker	Verteilung an passende Abonnenten
ACL	Einschränkung erlaubter Aktionen
HMI	Anzeige freigegebener Daten

Kreuzworträtsel

Broker	Welche Instanz verteilt MQTT-Nachrichten an Abonnenten?
Sensor	Welches Bauteil erfasst beispielsweise eine Temperatur?
Client	Wie heißt ein Gerät oder Programm, das sich mit dem Broker verbindet?
Topic	Wie heißt der Pfad, der eine MQTT-Nachricht kennzeichnet?
Payload	Wie heißt der Inhalt einer MQTT-Nachricht?
Subscriber	Wie nennt man einen Client, der Topics abonniert?

LearningApps

Optionale externe Suchseite; gib dort keine realen Geräte- oder Kundendaten ein.

Lückentext

Ein

verteilt MQTT-Nachrichten an passende Empfänger.

Ein

sendet eine Nachricht an den Broker.

Ein

meldet sein Interesse an passenden Topics an.

Eine

ordnet Geräte und Datenarten in Ebenen.

Das Zeichen

steht im MQTT-Filter für genau eine Ebene.

Eine

kann im Filter null oder mehrere Ebenen abdecken.

Die

enthält den Inhalt der veröffentlichten Nachricht.

Eine

begrenzt erlaubte Aktionen auf Topics.

Die

prüft die Identität eines Clients.

Die

entscheidet nach der Identitätsprüfung über Rechte.

Offene Aufgaben

Leicht

MQTT: Zeichne Publisher, Broker und Subscriber für presse01. Feedback: Richtig, wenn die Nachricht über den Broker läuft und die HMI nur empfängt.
Gerätehierarchie: Erweitere den Topic-Baum um sensor03 und dessen Temperatur. Feedback: Richtig, wenn Werk, Linie, Gerät, Datenart und Messgröße unverändert geordnet bleiben.
Publish-Subscribe-Muster: Markiere drei konkrete Topic-Namen und einen Filter. Feedback: Ein Filter darf Platzhalter enthalten; ein Publish-Topic nicht.
Datenvisualisierung: Zeichne aus der fiktiven Temperaturkurve ein Mini-Diagramm. Feedback: Der höchste Wert muss bei Minute zwei stehen.

Standard

Wildcard: Entwirf einen Filter für Temperaturen beider Geräte und prüfe ihn im Offline-Labor. Feedback: Ein + für die Geräteebene reicht.
ACL: Erstelle eine Rechte-Matrix für HMI, Presse und Ofen. Feedback: Jede erlaubte Schreibaktion braucht einen fachlichen Zweck.
Python: Ändere den Laborcode so, dass eine dritte Rolle wartung_lesend nur Zustände abonnieren darf. Feedback: Ein eigener exakter Filter muss in der Rolle stehen; Schreibrechte bleiben leer.
Softwaretest: Dokumentiere zwei erlaubte und zwei gesperrte Offline-Testfälle. Feedback: Ein überzeugender Test enthält Eingabe, erwartetes und beobachtetes Ergebnis.

Schwer

Least Privilege: Beurteile, warum training/# für eine HMI riskant sein kann. Feedback: Beziehe Datenmenge, Sichtbarkeit und minimale Rechte ein.
Industrie 4.0: Übertrage die Hierarchie auf ein zweites fiktives Werk, ohne bestehende Filter unabsichtlich zu erweitern. Feedback: Trenne Werkkennung und Berechtigungen nachvollziehbar.
IT-Sicherheit: Entwirf die Anforderungen für einen späteren produktiven Betrieb, ohne ihn aufzubauen. Feedback: Nenne mindestens Identität, TLS, ACL, Protokollierung und Freigabeprozess.
Fehlertoleranz: Erkläre, weshalb QoS 1 und Retain keine Freigabe zum sicheren Fernsteuern einer Maschine darstellen. Feedback: Übertragungsgarantie, Aktualität und Maschinensicherheit sind unterschiedliche Fragen.

Lernkontrolle

Systemarchitektur: Eine zweite Produktionslinie kommt hinzu. Wie muss der Topic-Baum wachsen, damit alte Abonnements nicht versehentlich deren Daten empfangen? Begründe Deine Struktur.
Zugriffskontrolle: Ein Anzeigeclient möchte einen Befehl senden. Leite aus dem Rollenmodell ab, ob dies zulässig ist, und beschreibe die nötige Prüfung am Broker.
Testfall: Ein Filter liefert keine Temperatur. Prüfe zunächst Topic-Ebenen, Großschreibung und Platzhalter und begründe Deine Diagnose.
Datensparsamkeit: Vergleiche eine globale Subscription mit zwei gezielten Filtern hinsichtlich Netzlast und Offenlegung von Informationen.
IT-Sicherheit: Diskutiere, warum der lokale anonyme Broker in der Übung vertretbar, im Produktionsnetz aber ungeeignet ist.
Qualitätssicherung: Übertrage das Modell auf eine dritte fiktive Maschine und formuliere prüfbare Akzeptanzkriterien für Publish, Subscribe und Rollenrechte.

Lernnachweis

Ein selbst gezeichneter Topic-Baum für die fiktive Linie mit konsistenter Schreibweise.
Eine Rollen- und Berechtigungsmatrix mit klar getrennten Lese- und Schreibrechten.
Mindestens vier dokumentierte Offline-Testfälle mit Eingabe, Erwartung, Ergebnis und Begründung.
Eine visualisierte kleine Messwertreihe ausschließlich mit fiktiven Zahlen.
Eine kurze Sicherheitsreflexion zu Localhost, ACL, Authentifizierung, TLS und Grenzen von QoS.
Eine Transferlösung für eine zusätzliche fiktive Linie mit begründeter Rechtevergabe.

Bewertungsraster: fachliche Richtigkeit, Nachvollziehbarkeit, Minimalberechtigungen, reproduzierbare Tests und verantwortlicher Umgang mit Testdaten. Keine echten Zugangsdaten, Maschinen oder Kundendaten als Nachweis abgeben.

OERs zum Thema

Quellenprüfung: Primärquelle ist die OASIS-Spezifikation MQTT 5.0, besonders Abschnitt 4.7 für Wildcards und Topics. Für das lokale Konfigurationsbeispiel gilt die Eclipse-Mosquitto-Dokumentation. Didaktische Ergänzungen: HiveMQ MQTT Topics und HiveMQ Autorisierung. Die verlinkten Fachtexte sind nicht automatisch offen lizenziert; die eingebundenen Commons-Grafiken nennen ihre jeweiligen Lizenzen und Urheber. YouTube-Videos dürfen angesehen oder eingebettet werden, aber nicht pauschal weiterverwendet.