aiMOOC

Digitale Vernetzung und Industrial IoT – Sensorwerte robust übertragen

QR-Code

Digitale Vernetzung und Industrial IoT – Sensorwerte robust übertragen

Ausbildung | Lernzeit: etwa 60–90 Minuten | Praxis: lokaler Python-3-Simulator | Voraussetzung: einfache Python-Grundlagen.

Dein Auftrag: Sichere die fiktiven Temperaturmesswerte eines Förderbandmotors gegen verspätete Zustellung, Verbindungsabbrüche und doppelte Übertragung ab. Du arbeitest ausschließlich offline – ohne echte Maschine, Broker, Zugangsdaten oder fremde Netzwerke.

Einleitung

In einem Industrial-IoT-System entstehen Messwerte an Sensoren, werden über eine Verbindung transportiert und später ausgewertet. Robust bedeutet nicht „es fällt nie etwas aus“, sondern: Zeit, Verlust, Wiederholung und Datenlücken werden erkennbar behandelt.

Bildimpuls: Finde Sensor-/Edge-Ebene und Auswertung. Das Bild zeigt eine allgemeine IIoT-Architektur, nicht unsere Testanlage.

Am Ende kannst Du …	Nachweis
Messzeit und Empfangszeit auseinanderhalten	Zeitstempel erklären
Ausfälle, Wiederholungen und Lücken untersuchen	Simulationsprotokoll deuten
doppelte Sensordaten vermeiden	lokale Tests bestehen

Dein Ausbildungsfall: Förderbandmotor TRAINING-01

Ein fiktiver Temperatursensor sendet alle fünf Sekunden eine Messung. Für die spätere Diagnose sollen Messzeit, Sensor-ID, Sequenznummer und Temperatur erhalten bleiben. Ein Verbindungsfehler darf nicht stillschweigend als normaler Wert erscheinen.

FIKTIVER SENSOR  →  Warteschlange  →  gestörte Übertragung  →  Auswertung
Messzeit + seq          lokal           Ausfall / ACK?        Duplikatprüfung

Sicherheitsrahmen: Kein echter Sensor, kein MQTT-Broker und keine Netzwerkverbindung werden gestartet. Die Simulation nutzt nur erfundene Messwerte im Arbeitsspeicher. Ausprobieren ausschließlich auf Deinem eigenen oder ausdrücklich freigegebenen Ausbildungsrechner. Niemals produktive OT oder fremde Netze testen.

Fünf kurze Lerneinheiten

Einheit 1 – Wer überträgt was? (ca. 8 Minuten)

Sensor → Publisher → Broker → Subscriber: Bei MQTT veröffentlicht ein Client eine Nachricht auf einem Topic. Ein Broker verteilt sie an passende Abonnenten. Ein Topic könnte in unserem reinen Gedankenmodell training/motor01/temperatur heißen.

Bildauftrag: Zeige im Publish/Subscribe-Schema auf Sender, Broker und Empfänger.

Optionales externes Erklärvideo: HiveMQ, „What is MQTT“ (Englisch); zum Lernen ansehen, nicht für die Simulation benötigt.

Mini-Check: Muss der Sensor die Adresse jedes Auswerterechners kennen? Begründetes Feedback: Nein. Beim Publish/Subscribe-Prinzip übernimmt der Broker die Verteilung anhand von Topics.

Einheit 2 – Zwei Zeiten, zwei Bedeutungen (ca. 10 Minuten)

Messzeit = Zeitpunkt der Sensorerfassung. Empfangszeit = Zeitpunkt der Ankunft. Für die Weiterverarbeitung ist eine eindeutige Zeitangabe mit Zeitzone wichtig, etwa 2026-01-01T12:00:05Z nach ISO 8601 bzw. RFC 3339. Z kennzeichnet UTC. Die Uhr muss ausreichend zuverlässig synchronisiert sein, etwa durch NTP in einer dafür freigegebenen Umgebung.

Bildauftrag: Erkläre, warum ungleich gehende Geräteuhren die Reihenfolge von Messwerten verfälschen können.

Fiktive Messzeit in UTC	seq	°C	Zustellung
12:00:00	1	20,4	angenommen
12:00:05	2	20,8	wiederholt, einmal gespeichert
12:00:10	3	21,2	nach seq 4 angekommen
12:00:15	4	21,6	vor seq 2 angekommen
12:00:20	5	22,0	vorerst nicht zugestellt

Mini-Check: Darf die Empfangsreihenfolge als Messreihenfolge gelten? Feedback: Nein, denn Verzögerungen können Nachrichten vertauschen; verwende Messzeit und stabile Sequenznummern und prüfe auf fehlerhafte Geräteuhren.

Einheit 3 – Ausfall und Puffer (ca. 8 Minuten)

Bei einer Störung kann ein Sensorwert zeitweise nicht zugestellt werden. Eine lokale Warteschlange hält ihn für spätere Versuche bereit. Jede Warteschlange braucht Grenzen: Speicherplatz, maximale Wartezeit und eine Regel für Überlast. Ein nach drei Versuchen noch offener Wert ist nicht automatisch verloren; in unserem Lernskript bleibt er lediglich als nicht zugestellt markiert.

Bildauftrag: Verfolge den MQTT-Nachrichtenfluss ohne zusätzliche QoS-Bestätigung.

Bildauftrag: Diskutiere, weshalb eine Datenbrücke zwischen Produktions- und IT-Ebene kontrolliert werden muss.

Mini-Check: Kann ein MQTT-Broker nachträglich jede historische Messung rekonstruieren? Feedback: Nein. Das Retain-Flag speichert den letzten entsprechenden Topic-Zustand, nicht automatisch eine vollständige Messhistorie. Persistente Sitzungen und Queuing helfen nur unter passenden Einstellungen und Grenzen.

Einheit 4 – Wiederholen, quittieren, deduplizieren (ca. 10 Minuten)

Eine fehlende Quittung (ACK) kann bedeuten, dass die Nachricht selbst oder nur ihre Bestätigung fehlte. Deshalb darf ein Wiederholungsversuch nicht unbemerkt denselben Messwert doppelt zählen. In der Anwendung hilft ein stabiler Schlüssel aus Sensor-ID + Sequenznummer (bei Neustarts zusätzlich eine eindeutige Gerätesitzung bzw. persistente Kennung).

MQTT-QoS	Zustellprinzip je MQTT-Protokollstrecke	Konsequenz
0	höchstens einmal	Verlust möglich
1	mindestens einmal	Duplikate möglich
2	genau einmal auf Protokollebene	mehr Protokollaufwand; keine automatische Garantie für Datenbank-Nebeneffekte

Bildauftrag: Suche DUP, QoS und Packet Identifier. Ein MQTT-Packet-Identifier ist kein dauerhaft eindeutiger Messdatenschlüssel.

Optional: HiveMQ „MQTT QoS“, demonstriert die drei Zustellstufen.

Mini-Check: Reicht die Anzeige des MQTT-DUP-Flags, um alle wiederholten Sensormessungen zu erkennen? Feedback: Nein. DUP bezieht sich auf einen Übertragungsversuch eines MQTT-Pakets; Anwendungsnachrichten können auch mit neuem Paket-Identifier erneut erscheinen.

Einheit 5 – Was geschieht bei der Wiederverbindung? (ca. 8 Minuten)

Verbindung zurück → wartende Nachrichten prüfen → erneut senden → nur einmal auswerten. Das ist ein Entwurfsmuster, keine automatische Eigenschaft jeder Installation. In MQTT 5 regeln u. a. Session Expiry und Message Expiry das Verhalten von Sitzungen und Nachrichten; Konfiguration und Zustellstufe sind entscheidend.

Bildauftrag: Erkenne die Rolle von TLS im Architekturbeispiel. Verschlüsselung ersetzt weder Berechtigungen noch Netztrennung.

Optional: HiveMQ „Persistent Session and Message Queue“. Das Video erläutert vor allem MQTT 3.1.1; MQTT 5 verwendet andere Sitzungsparameter.

Mini-Check: Warum sind Wiederholungen ohne zeitliche Grenze problematisch? Feedback: Veraltete Nachrichten könnten später unpassende Entscheidungen auslösen; Zeitgrenzen und Zustandsprüfung sind nötig.

Lokales Praxislabor – ohne Netzwerk

Vorbereitung und Start

Verwende Python 3.9 oder neuer in einem lokalen Ordner. Speichere den ersten Block als sicherer_sensor_sim.py. Es werden nur Python-Standardbibliothek und Arbeitsspeicher genutzt: keine Sockets, kein Webzugriff, kein MQTT-Verkehr und keine Installation zusätzlicher Pakete.

python sicherer_sensor_sim.py --szenario basis
python sicherer_sensor_sim.py --szenario ausfall
python sicherer_sensor_sim.py --szenario wiederholung
python sicherer_sensor_sim.py --szenario kombiniert

Testauftrag: Vergleiche die Empfangsreihenfolge, die Anzahl verworfener Duplikate und die noch nicht zugestellten Nummern. Sämtliche Messungen sind fiktiv und haben einen festen Zeitpunkt für reproduzierbare Ergebnisse.

Vollständig lauffähiger Simulator

"""Offline-Lernsimulation: keine Sockets, keine echten Sensoren."""
import argparse
from datetime import datetime, timedelta, timezone

START = datetime(2026, 1, 1, 12, 0, tzinfo=timezone.utc)
FAULTS = {
    "basis": {},
    "ausfall": {(2, 1): "offline", (5, 1): "offline",
                (5, 2): "offline", (5, 3): "offline"},
    "wiederholung": {(2, 1): "ack_verloren"},
    "kombiniert": {(2, 1): "offline", (2, 2): "ack_verloren",
                   (5, 1): "offline", (5, 2): "offline",
                   (5, 3): "offline"},
}

def iso(moment):
    return moment.isoformat().replace("+00:00", "Z")

def simulate(scenario="kombiniert"):
    if scenario not in FAULTS:
        raise ValueError("Unbekanntes Szenario")
    samples = {
        n: {"sensor": "TRAINING-01", "seq": n,
            "messzeit": iso(START + timedelta(seconds=5 * (n - 1))),
            "celsius": round(20 + n * 0.4, 1)}
        for n in range(1, 6)
    }
    order = [1, 2, 3, 4, 5] if scenario == "basis" else [1, 4, 2, 3, 5]
    received, arrival_order, log = {}, [], []
    duplicates = 0
    tick = 0
    for seq in order:
        packet = samples[seq]
        for attempt in range(1, 4):
            tick += 1
            fault = FAULTS[scenario].get((seq, attempt), "ok")
            if fault == "offline":
                log.append(f"seq={seq} Versuch {attempt}: Verbindung unterbrochen")
                continue
            key = (packet["sensor"], packet["seq"])
            if key in received:
                duplicates += 1
                log.append(f"seq={seq} Versuch {attempt}: Duplikat verworfen")
            else:
                received[key] = dict(packet, empfangszeit=iso(
                    START + timedelta(seconds=30 + tick)))
                arrival_order.append(seq)
                log.append(f"seq={seq} Versuch {attempt}: einmalig gespeichert")
            if fault == "ack_verloren":
                log.append(f"seq={seq}: Quittung verloren, Wiederholung folgt")
                continue
            break
        else:
            log.append(f"seq={seq}: nach 3 Versuchen noch nicht zugestellt")
    missing = sorted(set(samples) - {key[1] for key in received})
    return {"received": received, "arrival_order": arrival_order,
            "duplicates": duplicates, "missing": missing, "log": log}

def main():
    parser = argparse.ArgumentParser(description="Reine Offline-IIoT-Simulation")
    parser.add_argument("--szenario", choices=FAULTS, default="kombiniert")
    args = parser.parse_args()
    result = simulate(args.szenario)
    print("\n".join(result["log"]))
    print("Empfangsreihenfolge:", result["arrival_order"])
    print("Messwerte nach Messzeit (ein # = 0,2 Grad ueber 20 Grad):")
    for _, packet in sorted(result["received"].items()):
        bars = "#" * round((packet["celsius"] - 20) * 5)
        print(f'{packet["messzeit"]} | seq={packet["seq"]} | '
              f'{packet["celsius"]:.1f} C | {bars}')
    print("Duplikate verworfen:", result["duplicates"])
    print("Nicht zugestellt:", result["missing"])

if __name__ == "__main__":
    main()

Lokale Testumgebung mit automatischem Feedback

Speichere den zweiten Block als test_sensor_sim.py im selben Ordner. Er prüft vier erwartete Eigenschaften; Du kannst ihn ohne Netzwerk starten.

python -m unittest -v test_sensor_sim.py

"""Lokale Tests: python -m unittest -v test_sensor_sim.py"""
import unittest
from sicherer_sensor_sim import simulate

class SensorSimulationTests(unittest.TestCase):
    def test_basis_alle_da(self):
        self.assertEqual(simulate("basis")["missing"], [])

    def test_ausfall_luecke(self):
        self.assertEqual(simulate("ausfall")["missing"], [5])

    def test_wiederholung_duplikat(self):
        self.assertEqual(simulate("wiederholung")["duplicates"], 1)

    def test_kombiniert_reihenfolge(self):
        result = simulate("kombiniert")
        self.assertEqual(result["arrival_order"], [1, 4, 2, 3])
        self.assertEqual(result["missing"], [5])
        self.assertEqual(len(result["received"]), 4)

if __name__ == "__main__":
    unittest.main()

Erwartetes Testergebnis: Vier Tests mit ok. Warum? Ohne Störung fehlen keine Werte; bei dauerhaftem Ausfall bleibt seq 5 offen; bei verlorener Quittung wird ein Duplikat erkannt; im kombinierten Fall ist die Empfangsreihenfolge 1, 4, 2, 3.

Wichtig: Das Skript modelliert Anwendungslogik, nicht den MQTT-Protokollablauf, TCP, echte Sensoruhren oder reale Netzzuverlässigkeit. Sein Puffer liegt nur im RAM; beim Programmende ist er weg. Eine echte Lösung benötigt unter anderem dauerhafte Speicherung, Neustartverhalten, Zeitvalidierung, Authentifizierung, Begrenzung der Warteschlange und eine autorisierte Sicherheitsarchitektur.

Visualisierte Daten: Lesen statt raten

Fiktive Empfangsfolge:      [1] → [4] → [2] → [2*] → [3]       [5: offen]
* zweites Eintreffen von 2 → verworfen

Nach MESSZEIT sortierte Werte:
seq 1 | ##       20,4 °C
seq 2 | ####     20,8 °C
seq 3 | ######   21,2 °C
seq 4 | ######## 21,6 °C
seq 5 | ?        keine Zustellung
                  (# entspricht 0,2 °C über 20 °C)

Die Balken stammen aus fiktiven, im Skript berechneten Daten. Messwert 5 ist unbekannt für die Auswertung, nicht null Grad und nicht ein gemessener Nullwert. In einem Diagramm bleibt die Lücke sichtbar.

Gestufte Hilfen für Dein Labor

Stufe	Hilfe
1 – Hinweis	Prüfe zuerst die Felder `messzeit`, `seq` und `empfangszeit`.
2 – Vorgehen	Vergleiche `arrival_order` mit der Sortierung der gespeicherten Daten.
3 – Lösungsidee	Beim Wiederholen von seq 2 findet `received` bereits den Schlüssel und zählt genau ein verworfenes Duplikat.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Was bezeichnet die Messzeit? (Den Zeitpunkt der Sensorerfassung) (!Den Zeitpunkt des Öffnens einer Webseite) (!Den Zeitpunkt des Programmstarts) (!Den Zeitpunkt des letzten Backups)

Welche Zeitangabe ist eindeutig auf UTC bezogen? (2026-01-01T12:00:05Z) (!12 Uhr irgendwann) (!Gestern am Nachmittag) (!Morgens um sieben)

Was kann MQTT QoS 1 verursachen? (Mehrfachzustellung derselben Nachricht) (!Eine garantierte Netztrennung) (!Automatisch korrigierte Sensoruhren) (!Eine unbegrenzte Datenbankhistorie)

Wozu dient eine Sequenznummer im Ausbildungsfall? (Zum Erkennen von Lücken und Wiederholungen) (!Zum Verschlüsseln eines Passworts) (!Zum Kühlen des Motors) (!Zum Festlegen der Netzwerkadresse)

Was bedeutet eine verlorene Quittung? (Der Sender weiß nicht sicher ob der Empfänger gespeichert hat) (!Die Messung wurde zwingend gelöscht) (!Der Sensor hat seine Temperatur geändert) (!Die Verbindung wurde verschlüsselt)

Wie wird ein doppelter Messwert hier erkannt? (Durch Sensor-ID und Sequenznummer) (!Allein durch die Temperaturhöhe) (!Durch die Farbe des Diagramms) (!Durch die Dateiendung)

Was zeigt ein fehlender Wert im Diagramm korrekt an? (Eine sichtbare Datenlücke) (!Automatisch null Grad Celsius) (!Den Mittelwert der Nachbarn) (!Einen garantierten Motorschaden)

Welche Aussage über MQTT QoS 2 stimmt? (Es betrifft die Zustellung auf MQTT-Protokollebene) (!Es ersetzt alle Datenbanktransaktionen) (!Es synchronisiert die Sensoruhr) (!Es verhindert jedes Problem bei Neustarts)

Was geschieht bei Szenario kombiniert mit seq 5? (Sie bleibt nach drei Versuchen nicht zugestellt) (!Sie wird als null Grad gespeichert) (!Sie wird automatisch durch seq 4 ersetzt) (!Sie wird dreifach als Messung gezählt)

Welche Testumgebung ist hier erlaubt? (Eine lokale Simulation mit fiktiven Daten) (!Ein fremdes Firmennetz ohne Erlaubnis) (!Eine aktive Produktivanlage) (!Ein öffentlicher Broker mit realen Kundendaten)

Memory

Messzeit	Zeitpunkt der Erfassung
Empfangszeit	Zeitpunkt der Ankunft
Quittung	Bestätigung des Empfangs
Sequenznummer	Fortlaufende Kennung
Puffer	Vorübergehende Speicherung
Duplikat	Wiederholt eingetroffene Nachricht

Drag and Drop

Ordne die richtigen Begriffe zu.	Bedeutung
Sensor	Erfasst die Temperatur
Zeitstempel	Dokumentiert die Messzeit
Warteschlange	Hält offene Nachrichten bereit
Quittung	Bestätigt einen Empfang
Deduplizierung	Verhindert doppelte Auswertung

Kreuzworträtsel

Zeitstempel	Welche Angabe kennzeichnet den Messzeitpunkt?
Broker	Wer vermittelt MQTT-Nachrichten zwischen Clients?
Quittung	Wie heißt die Bestätigung einer erfolgreichen Zustellung?
Duplikat	Wie heißt eine erneut eingetroffene identische Nachricht?
Puffer	Welche Zwischenspeicherung hilft bei einer Unterbrechung?
Sequenz	Wie heißt die geordnete Folge von Messkennungen?

LearningApps

Optionaler externer Suchzugang, kein Bestandteil des lokalen Testlabors. Nur freiwillig mit Zustimmung der Ausbildungsstelle öffnen; keine realen Geräte- oder Kundendaten eingeben. Es wird keine konkrete LearningApp als geprüft behauptet.

Lückentext

Im Industrial IoT erfasst ein

die Temperatur.

Der Zeitpunkt der Erfassung heißt

.

Die Ankunft beim Empfänger kennzeichnet die

.

Das Kürzel Z in unserem Zeitformat bezeichnet

.

Eine fortlaufende Kennung heißt

.

Vorübergehend nicht zustellbare Daten benötigen einen

.

Eine Empfangsbestätigung heißt

.

Ein erneut eintreffender identischer Wert ist ein

.

Bei MQTT QoS 1 ist eine

möglich.

Eine fehlende Messung sollte als

sichtbar bleiben.

Offene Aufgaben

Arbeite nur mit den fiktiven Daten. Die Aufgaben sind nach Schwierigkeit und Kompetenzniveau geordnet. Jede Rückmeldung nennt ein begründetes Erfolgskriterium.

Leicht – Basisaufgaben

Sensor: Skizziere den Weg von TRAINING-01 zur Auswertung. Feedback: Sensor, Warteschlange und Auswertung müssen unterscheidbar sein, weil jede Stelle andere Fehler behandeln kann.
Zeitstempel: Markiere Messzeit und Empfangszeit in einer eigenen Beispielnachricht. Feedback: Zwei Felder sind richtig, weil Übertragungsverzögerung den Erfassungszeitpunkt nicht ändern darf.
Sequenznummer: Kennzeichne in der Tabelle oben die fehlende Nummer. Feedback: seq 5 ist nicht zugestellt; der Wert darf deshalb nicht als Temperatur 0 erscheinen.
MQTT: Zeichne Publisher, Broker und Subscriber. Feedback: Die Verbindung über ein Topic ist entscheidend, weil Publisher und Subscriber entkoppelt sind.

Standard – Anwendungsaufgaben

Python: Starte lokal alle vier Szenarien und notiere je die offenen Werte. Feedback: Basis ohne Lücke, Ausfall und kombiniert mit seq 5; das folgt aus den festgelegten Störungen.
Fehlersuche: Erkläre anhand des Protokolls die zwei Versuche nach dem Netzausfall von seq 2. Feedback: Nach dem erneuten Empfang fehlt die Quittung; erst der nächste Versuch wird als Duplikat verworfen.
Datenvisualisierung: Erstelle aus den angenommenen Messwerten ein eigenes Balkendiagramm mit sichtbarer Lücke. Feedback: Die Lücke muss sichtbar bleiben, da ein fehlender Wert keine gemessene Temperatur ist.
Softwaretest: Ergänze einen Test, der im Basisszenario die Empfangsfolge prüft. Feedback: Erwartet wird 1, 2, 3, 4, 5, weil dort keine Störung simuliert wird.

Schwer – Transferaufgaben

Persistenz: Entwirf einen lokalen, nach Neustart wiederherstellbaren Puffer auf Papier. Feedback: Auch die zuletzt bestätigte Kennung muss erhalten bleiben, sonst drohen Verlust und Doppelzählung.
Datenqualität: Beschreibe den Umgang mit einer falschen Sensoruhr. Feedback: Plausibilitätsprüfungen und ein Kennzeichen für unsichere Zeit verhindern falsche zeitliche Schlussfolgerungen.
Netzwerksicherheit: Entwirf eine getrennte Laborarchitektur für einen späteren autorisierten MQTT-Versuch. Feedback: Rollen, Rechte, Isolation und fiktive Daten sind erforderlich; bloßes TLS ist keine Freigabe.
Systementwurf: Vergleiche QoS 0, 1 und 2 für eine nicht sicherheitskritische Trendanzeige und ein Auditprotokoll. Feedback: Begründe die Abwägung von Verlust, Mehrfachzustellung, Aufwand und dauerhafter Speicherung; QoS allein schützt keine komplette Verarbeitungskette.

Lernkontrolle

Anforderungsanalyse: Ein Messwert trifft 30 Sekunden verspätet ein. Begründe, welcher Zeitstempel für einen zeitlichen Trend verwendet wird und wann die Empfangszeit zusätzlich nützlich ist.
Fehleranalyse: Nach einem Neustart werden drei alte Meldungen erneut verarbeitet. Entwirf eine Maßnahme, die Wiederholung erlaubt, ohne die Statistik zu verdreifachen.
Datenvisualisierung: Ein Bericht verbindet seq 4 direkt mit seq 6. Erkläre, wie Du seq 5 als offene Messlücke kennzeichnest und warum eine stillschweigende Interpolation riskant ist.
Protokollanalyse: Ein Team behauptet, QoS 2 garantiere exakt eine Datenbankbuchung. Beurteile die Aussage und ergänze eine Anwendungsstrategie für idempotentes Speichern.
Risikobewertung: Entwirf für einen längeren Netzausfall Regeln für Puffergröße, maximale Aufbewahrungszeit, Alarmierung und spätere Prüfung; begründe die Zielkonflikte.
Transfer: Beschreibe den Übergang vom Offline-Modell zu einem ausschließlich freigegebenen Labor. Nenne technische Freigaben, Testdaten und einen sicheren Abbruchplan.

Lernnachweis

Für Deinen Lernnachweis gibst Du keine echten Geräte- oder Kundendaten ab.

Ein beschriftetes Datenflussdiagramm mit Sensor, Zeitstempel, Puffer und Auswertung.
Die Ausgaben der vier lokalen Szenarien einschließlich Datenlücke und Duplikatnachweis.
Die Ergebnisse der vier automatischen Tests oder ein entsprechendes lokales Prüfprotokoll.
Ein Diagramm, das Messzeit, Empfangsreihenfolge und fehlende Werte korrekt unterscheidet.
Eine begründete Entscheidung für Wiederholungs- und Deduplizierungsregeln einschließlich ihrer Grenzen.
Eine kurze Reflexion zu lokaler Testisolation, Datenschutz und OT-Sicherheit.

Bewertungsmaßstab: Fachlich richtige Zuordnung (30 %), funktionierender Offline-Test (30 %), begründeter Transfer (25 %) und sorgfältige Sicherheitsgrenzen (15 %).

OERs zum Thema

Vertiefung zu MQTT (externer Wikipedia-Inhalt; nur freiwillig öffnen):

Geprüfte Fachquellen

OASIS: MQTT Version 5.0, Standard – normativ für QoS, DUP, Sitzungs- und Nachrichtenablauf.
IETF: RFC 3339 – Datums- und Zeitangaben mit UTC-Bezug.
IETF: RFC 5905 – Grundlagen zur Synchronisierung von Uhren mit NTPv4.
Wikipedia: MQTT – Überblick und Begriffe; zum Vertiefen, nicht als Ersatz für den Standard.

Medienrechte und Nachnutzung

Die folgenden tatsächlich vorhandenen Wikimedia-Commons-Dateien sind mit Urhebern und Lizenz auf ihrer Dateiseite dokumentiert. Beachte insbesondere die Namensnennung und Weitergabe unter gleichen Bedingungen bei CC BY-SA.

IIoT System Building Blocks – Sujata Tilak, CC BY-SA 4.0.
Estrutura padrão publish-subscriber – Siol bruno, CC BY-SA (siehe Dateiseite).
Network Time Protocol servers and clients – Benjamin D. Esham, gemeinfrei.
MQTT protocol example without QoS – Simon A. Eugster, CC BY-SA 4.0 (alternativ weitere Lizenzen auf Dateiseite).
Purdue model with IIoT – Paul McLaughlin / Rohan McAdam, CC BY-SA 4.0.
MQTT Publish packet – Blacktron, CC BY-SA 4.0.
MQTT single broker multiple listener tls single – Ademant, CC BY-SA 4.0.

YouTube-Einbettungen stammen vom Fachkanal HiveMQ und sind als optionale externe Videos gekennzeichnet. Öffentliche Abrufbarkeit oder Einbettung bedeutet nicht automatisch eine freie Bearbeitungs- oder Weiterverbreitungslizenz. Die Einbettung kann technische Daten an die Videoplattform übertragen. Für Offline-Unterricht werden nur die hiesigen Text-/Python-Aufgaben benötigt.