aiMOOC

Digitale Vernetzung und Industrial IoT – Datenverlust und Verbindungsabbruch simulieren

QR-Code

Einleitung

Digitale Vernetzung und Industrial IoT – Datenverlust und Verbindungsabbruch simulieren

Zielgruppe: Ausbildung in IT, Mechatronik, Elektronik, Automatisierungstechnik und Industrie 4.0

Dauer: ca. 90–120 Minuten

Schwerpunkt: Pufferung, Datenverlust, Wiederverbindung und kontrollierte Wiederaufnahme.

In diesem aiMOOC lernst Du, wie industrielle Systeme bei einem Verbindungsabbruch mit Messdaten umgehen. Du simulierst Fehler, untersuchst Datenverluste und entwickelst Lösungen für eine zuverlässigere Datenübertragung.

Dein Ziel: Messdaten trotz kurzzeitiger Störungen sicher zwischenspeichern, geordnet nachsenden und Duplikate erkennen.

Beispiel einer industriellen Maschinensteuerung. Bild: EngelGMA, Wikimedia Commons, CC BY-SA 4.0. Die dargestellte Steuerung ist nicht Teil des Simulationsfalls.

Video: What is MQTT? – HiveMQ, MQTT Essentials, Teil 1 (Englisch).

Lernziele

Nach dem Kurs kannst Du:

Industrial Internet of Things: Den Weg industrieller Sensordaten erklären.
Datenverlust: Fehlerquellen und fehlende Messwerte erkennen.
Pufferung: Einen begrenzten Zwischenspeicher einsetzen.
Wiederverbindung: Eine kontrollierte Datenübertragung nach Störungen durchführen.
Datenintegrität: Fehlende und doppelte Nachrichten unterscheiden.
Simulation: Fehlerfälle lokal testen und Ergebnisse auswerten.

Lernpfad

Lerneinheit	Thema	Zeit
1	Vernetzte Produktionsanlage	10 Minuten
2	Datenverlust und Verbindungsfehler	15 Minuten
3	Pufferung und Wiederaufnahme	15 Minuten
4	Lokales Simulationslabor	25 Minuten
5	Messdaten visualisieren	15 Minuten
6	Ergebnisse bewerten und übertragen	15 Minuten

Ausbildungsfall: Verpackungslinie Alpha

Du arbeitest als Auszubildende oder Auszubildender in einem fiktiven Industriebetrieb.

Eine Verpackungslinie überträgt Temperaturmesswerte von einem Sensor über ein IoT-Gateway an ein übergeordnetes Überwachungssystem.

Der Datenaustausch funktioniert normalerweise. Bei einer kurzen Verbindungsunterbrechung kommen jedoch Messwerte verspätet oder gar nicht an.

Dein Auftrag: Untersuche den Fehler, simuliere verschiedene Störungen und plane eine zuverlässige Wiederaufnahme.

Beispiel eines Sensorknotens, hier für akustische Messungen. Bild: Wsnlab, Wikimedia Commons, CC BY-SA 3.0.

Die fiktive Anlage

VERPACKUNGSLINIE ALPHA

[Temperatursensor]
         |
         v
   [IoT-Gateway]
         |
         v
 [Datenverbindung]
         |
         v
  [Überwachung]

FEHLERFALL:

Sensor --> Gateway --X--> Überwachung
              |
              v
          [Puffer]
              |
     Wiederverbindung
              |
              v
       Geordnet senden

Ausgangsdaten:

Eigenschaft	Festlegung im Ausbildungsfall
Messwerte	8 fiktive Temperaturmessungen
Messintervall	1 Messung je Simulationstakt
Zwischenspeicher	Maximal 3 Messungen
Nachsendeleistung	Maximal 1 Versuch je Takt
Testdaten	21 bis 28 Grad Celsius
Testumgebung	Ausschließlich lokales Python-Programm

Die Zahlen sind didaktisch gewählt. Sie beschreiben keine reale Produktionsanlage.

Lerneinheit 1: Digitale Vernetzung verstehen

Im Industrial Internet of Things (IIoT) übertragen Maschinen, Sensoren und Anwendungen Daten, beispielsweise für die Zustandsüberwachung oder Wartungsplanung.

Bei MQTT übermittelt ein Publisher Nachrichten an einen Broker. Dieser verteilt sie an passende Subscriber.

MQTT-Systemdarstellung. Bild: Chine3me, Wikimedia Commons, CC0 1.0.

MQTT-Architektur mit Publisher, Broker und Subscriber. Bild: Ana beloti, Wikimedia Commons, CC BY-SA 4.0. Die Bildbeschriftungen sind auf Portugiesisch.

Video: MQTT Publish / Subscribe / Unsubscribe – HiveMQ (Englisch).

Drei zentrale Begriffe

Begriff	Bedeutung
Publisher	Erzeugt und veröffentlicht Nachrichten
Broker	Nimmt Nachrichten entgegen und verteilt sie
Subscriber	Abonniert Nachrichten bestimmter Themen

Basisaufgabe: Zeichne den Datenweg der Verpackungslinie und beschrifte Publisher, Broker und Subscriber.

Feedback: Der Sensor beziehungsweise sein Gateway kann Publisher sein. Das Überwachungssystem kann Subscriber sein. Der Broker vermittelt die Nachrichten.

Lerneinheit 2: Datenverlust und Verbindungsfehler

Ein Datenverlust bedeutet, dass eine erwartete Messung am vorgesehenen Ziel fehlt. Ein Verbindungsabbruch bedeutet dagegen zunächst nur, dass die Kommunikation zeitweise unterbrochen ist.

Wichtig: Nicht jeder Verbindungsabbruch führt zwangsläufig zu dauerhaftem Datenverlust.

Beispiel eines MQTT-Paketaustauschs mit QoS 0. Bild: Simon A. Eugster, Wikimedia Commons, CC BY-SA 4.0.

Typische Fehlerursachen

Verbindungsabbruch: Eine Nachricht kann nicht übertragen werden.
Paketverlust: Eine Übertragung scheitert und muss gegebenenfalls wiederholt werden.
Pufferüberlauf: Neue Messwerte passen nicht mehr in die Warteschlange.
Zeitüberschreitung: Eine erwartete Antwort bleibt aus.
Duplikat: Eine Nachricht wird erneut empfangen.

MQTT Quality of Service

MQTT unterscheidet drei Zustellungsstufen.

Stufe	Zustellungsprinzip	Mögliche Folge
QoS 0	Höchstens einmal	Nachrichten können verloren gehen
QoS 1	Mindestens einmal	Mehrfachzustellung ist möglich
QoS 2	Genau einmal auf der jeweiligen MQTT-Übertragungsstrecke	Höherer Protokollaufwand

Achtung: Auch QoS 2 garantiert nicht automatisch, dass ein Messwert dauerhaft in einer Anwendungsdatenbank gespeichert oder eine industrielle Aktion genau einmal ausgeführt wurde.

Aufbau eines MQTT-PUBLISH-Pakets. Bild: Blacktron, Wikimedia Commons, CC BY-SA 4.0.

Video: MQTT QoS – Quality of Service – HiveMQ (Englisch).

Basisaufgabe: Vergleiche QoS 0 und QoS 1. Erkläre, warum die Bestätigung einer Nachricht für das Wiederholen einer Übertragung wichtig sein kann.

Feedback: Ohne Bestätigung weiß der Sender nicht zuverlässig, ob die Nachricht angenommen wurde. Bei QoS 1 sind wiederholte Zustellungen möglich.

Lerneinheit 3: Pufferung und kontrollierte Wiederaufnahme

Bei einer Verbindungspause kann ein Puffer Messwerte vorübergehend aufbewahren.

Eine kontrollierte Wiederaufnahme besteht aus vier Schritten:

Zwischenspeicherung: Neue Messungen werden in die Warteschlange aufgenommen.
Verbindungsprüfung: Die Kommunikation ist wieder möglich.
Wiederholung: Unbestätigte Nachrichten werden erneut gesendet.
Datenintegrität: Fehlende oder doppelte Nachrichten werden erkannt.

Visualisierung: Store and Forward

TAKT       1   2   3   4   5   6
           |   |   |   |   |   |

VERBINDUNG OK  OK  XX  XX  OK  OK

SENSOR     A   B   C   D   E   F

PUFFER     -   -   C   CD  DE  EF
                           ^
                           |
                    C bestätigt,
                    aus Puffer entfernt

Vereinfachtes Modell: Es wird höchstens eine gepufferte Nachricht je Takt bestätigt. Der Pufferzustand wird nach dem Sendeversuch angezeigt.

Empfangsbestätigung und Idempotenz

Ein Messwert erhält eine eindeutige Ereignis-ID.

Wenn eine Quittung verloren geht, kann der Sender denselben Messwert erneut übertragen. Das empfangende System erkennt anhand der ID, dass die Messung bereits verarbeitet wurde.

Diese Eigenschaft unterstützt eine idempotente Verarbeitung: Wiederholung derselben Operation führt nicht zu einer zweiten fachlichen Wirkung.

Wichtig: Eine MQTT-PUBACK-Quittung bestätigt die Annahme durch den direkten MQTT-Gegenpart, nicht zwingend die vollständige Verarbeitung im Endsystem.

Video: Persistent Session and Message Queue – HiveMQ (Englisch). Das Video behandelt hauptsächlich MQTT 3.x; bei MQTT 5 gelten ergänzende Einstellungen zur Sitzungsablaufzeit.

Anwendungsaufgabe: Begründe, weshalb das Gateway unbestätigte Messungen nicht sofort löschen darf.

Feedback: Bei fehlender Quittung ist der Erfolg der Zustellung unklar. Ein erneuter Versuch verhindert möglicherweise Verlust, kann aber ein Duplikat erzeugen.

Lerneinheit 4: Isoliertes Simulationslabor

Sicherheitsregeln

Alle Experimente finden ausschließlich lokal mit fiktiven Daten statt.

Verwende weder ein fremdes Netzwerk noch einen öffentlichen MQTT-Broker, eine reale SPS, eine Produktivanlage oder echte Betriebsdaten.

Der folgende Simulator benötigt nur Python 3 und die Standardbibliothek. Er erzeugt keine Netzwerkverbindungen, versendet keine Daten und verwendet keine Zugangsdaten.

Die simulierte Verbindung ist lediglich ein Programmzustand. Es werden keine tatsächlichen Netzpakete verändert.

Vorbereitung:

Python: Speichere den ersten Code in einer Datei namens iot_sim.py.
Terminal: Öffne den Ordner mit der gespeicherten Datei.
Simulation: Starte lokal mit python -I iot_sim.py, gegebenenfalls mit python3 -I iot_sim.py.
Fehlersimulation: Wähle ein Szenario zwischen 1 und 5 aus.

Python-Simulator: Fehler gezielt erzeugen

from collections import deque
import csv

KAPAZITAET = 3
SZENARIEN = {"1": "normal", "2": "abbruch",
             "3": "paketverlust", "4": "quittungsverlust",
             "5": "pufferueberlauf"}
wahl = input("1 normal, 2 Abbruch, 3 Paketverlust, "
             "4 Quittungsverlust, 5 Pufferueberlauf: ").strip()
modus = SZENARIEN.get(wahl, "normal")
puffer = deque()
empfangen = {}
verworfen = []
versuche = {}
protokoll = []
duplikate = 0

for takt in range(1, 11):
    online = not (
        (modus == "abbruch" and takt in (3, 4))
        or (modus == "pufferueberlauf" and takt in (3, 4, 5, 6))
    )
    status = "Warten"
    if takt <= 8:
        ereignis = (takt, 20 + takt)  # ID, fiktive Temperatur
        if len(puffer) < KAPAZITAET:
            puffer.append(ereignis)
        else:
            verworfen.append(takt)
            status = "Puffer voll: ID " + str(takt)

    if online and puffer:
        id_, temperatur = puffer[0]  # nur 1 Versuch je Takt
        versuche[id_] = versuche.get(id_, 0) + 1
        if modus == "paketverlust" and id_ == 2 and versuche[id_] == 1:
            status = "Paket verloren: ID 2"
        else:
            if id_ in empfangen:
                duplikate += 1
                status = "Duplikat ignoriert: ID " + str(id_)
            else:
                empfangen[id_] = temperatur
                status = "Empfangen: ID " + str(id_)
            if (modus == "quittungsverlust" and id_ == 4
                    and versuche[id_] == 1):
                status += ", Quittung verloren"
            else:
                puffer.popleft()  # erst nach Quittung entfernen
    elif not online:
        status += " / offline"

    protokoll.append((takt, "online" if online else "offline",
                      len(puffer), status))

with open("iot_protokoll.csv", "w", newline="", encoding="utf-8") as f:
    writer = csv.writer(f, delimiter=";")
    writer.writerow(("Takt", "Link", "Puffer", "Ereignis"))
    writer.writerows(protokoll)

print("\nSZENARIO:", modus)
for takt, link, fuellstand, status in protokoll:
    print(f"{takt:2} | {link:7} | {'#' * fuellstand:3} | {status}")
fehlende = sorted(set(range(1, 9)) - set(empfangen))
print("Einmalig empfangen:", sorted(empfangen))
print("Fehlende IDs:", fehlende)
print("Puffer-Überläufe:", verworfen)
print("Erkannte Duplikate:", duplikate)
print("Noch im RAM-Puffer:", [e[0] for e in puffer])

Hinweis: Die Simulation speichert den Puffer nur im Arbeitsspeicher. Bei einem Programmabbruch wäre dieser Inhalt verloren. Das CSV-Protokoll wird lokal im aktuellen Arbeitsordner erstellt und bei jedem neuen Lauf überschrieben.

Testumgebung A: Verbindungsausfall

Wähle 2.

Das Programm simuliert eine unterbrochene Verbindung in Takt 3 und 4.

Erwartung: Der Puffer wächst. Nach Wiederverbindung werden die Messwerte schrittweise übertragen.

Geprüftes Ergebnis: Alle acht Messungen treffen ein. Es fehlen keine Ereignis-IDs.

Testumgebung B: Paketverlust

Wähle 3.

Der erste Sendeversuch für Ereignis-ID 2 scheitert.

Erwartung: Die Nachricht bleibt im Puffer und wird später erneut übertragen.

Geprüftes Ergebnis: ID 2 wird beim nächsten Versuch angenommen. Keine Messung geht dauerhaft verloren.

Testumgebung C: Quittungsverlust

Wähle 4.

Ereignis-ID 4 erreicht die Empfangsseite. Die erste Bestätigung geht jedoch im Simulationsmodell verloren.

Erwartung: ID 4 wird erneut gesendet. Die Empfängerseite erkennt das Duplikat.

Geprüftes Ergebnis: Ein Duplikat wird erkannt. Alle acht Ereignisse sind einmalig im Empfängerspeicher vorhanden.

Testumgebung D: Pufferüberlauf

Wähle 5.

Die Verbindung ist länger unterbrochen, während weiterhin neue Messungen entstehen.

Erwartung: Der Puffer mit drei Plätzen reicht nicht aus.

Geprüftes Ergebnis: Die Ereignis-IDs 6 und 7 werden wegen Pufferüberlaufs verworfen.

Szenario	Empfangene IDs	Dauerhaft fehlende IDs	Duplikate erkannt
Normal	1–8	Keine	0
Abbruch	1–8	Keine	0
Paketverlust	1–8	Keine	0
Quittungsverlust	1–8	Keine	1
Pufferüberlauf	1–5 und 8	6 und 7	0

Beachte: Diese Ergebnisse gelten für die festgelegten Simulationsbedingungen, nicht als allgemeine Zusicherung für reale Netze.

Gestufte Hilfen

Hilfe 1 – Beobachten: Achte zuerst auf die Spalten Verbindung, Pufferfüllung und Ereignis.

Hilfe 2 – Verstehen: Bei einer Unterbrechung bleiben Messungen in der Warteschlange. Bei fehlender Quittung bleibt die betroffene Nachricht ebenfalls dort.

Hilfe 3 – Prüfen: Vergleiche die erwarteten IDs 1 bis 8 mit den tatsächlich empfangenen IDs. Eine Lücke zeigt einen fehlenden Messwert an.

Lerneinheit 5: Messdaten visualisieren

Das Simulationsprogramm erzeugt die Datei iot_protokoll.csv.

Du kannst sie in einer Tabellenkalkulation öffnen oder direkt mit Python auswerten.

Lokale Datenvisualisierung

Speichere den folgenden Code als iot_plot.py im selben Ordner wie die CSV-Datei.

import csv

with open("iot_protokoll.csv", newline="", encoding="utf-8") as f:
    daten = list(csv.DictReader(f, delimiter=";"))

print("Pufferfüllung je Takt (# = 1 Messung, . = leer)")
for zeile in daten:
    anzahl = int(zeile["Puffer"])
    balken = "#" * anzahl if anzahl else "."
    print(f'{zeile["Takt"]:>2} | {balken:<3} | '
          f'{zeile["Link"]:<7} | {zeile["Ereignis"]}')
print("Höchster Pufferstand:",
      max(int(x["Puffer"]) for x in daten))

Starte anschließend:

python -I iot_plot.py

Die Darstellung bleibt vollständig lokal.

Beispielvisualisierung: Puffer bei Verbindungsabbruch

Takt   Verbindung   Pufferfüllung

 1     Online       .
 2     Online       .
 3     Offline      #
 4     Offline      ##
 5     Online       ##
 6     Online       ##
 7     Online       ##
 8     Online       ##
 9     Online       #
10     Online       .

# = eine gespeicherte Messung
. = leerer Puffer

Beobachtung: Während der Störung steigt die Pufferfüllung. Nach der Wiederverbindung bleibt sie zunächst erhöht, weil weiterhin neue Messungen eintreffen und jeweils nur eine Nachricht pro Takt gesendet wird.

Anwendungsaufgabe: Warum leert sich der Puffer nicht sofort nach der Wiederverbindung?

Feedback: Die kontrollierte Sendegeschwindigkeit ist begrenzt. Solange neue Daten hinzukommen, kann der Rückstand bestehen bleiben.

Was Du aus dem Diagramm ableiten kannst

Warteschlange: Der Pufferstand zeigt den Rückstau.
Durchsatz: Die Sendekapazität beeinflusst die Aufholgeschwindigkeit.
Überwachung: Ein dauerhaft hoher Pufferstand kann auf einen Engpass hinweisen.
Kapazitätsplanung: Eine längere Unterbrechung erfordert mehr Pufferplatz oder eine geeignete Überlaufstrategie.

Lerneinheit 6: Kontrollierte Wiederaufnahme in der Praxis

Für eine robuste industrielle Datenübertragung reicht ein Wiederverbindungsversuch allein nicht aus.

Zusätzlich müssen Pufferkapazität, Ereigniskennungen, Wiederholungsstrategie und die sichere Verarbeitung der Daten festgelegt werden.

Beispiel eines MQTT-Brokers mit TLS-geschütztem Listener. Bild: Ademant, Wikimedia Commons, CC BY-SA 4.0.

Maßnahmen im Vergleich

Maßnahme	Nutzen	Grenze
RAM-Puffer	Überbrückt kurze Ausfälle	Inhalt geht bei Stromausfall verloren
Persistenter Speicher	Kann Neustarts überstehen	Benötigt Speicherverwaltung und Integritätsschutz
Eindeutige Ereignis-ID	Unterstützt Duplikaterkennung	Muss zuverlässig vergeben werden
Empfangsquittung	Bestätigt eine definierte Annahmestufe	Bedeutet nicht automatisch Endverarbeitung
Begrenztes Nachsenden	Verhindert unkontrollierte Lastspitzen	Rückstände dauern länger
Monitoring	Erkennt Rückstau und Fehler	Behebt die Ursache nicht selbst

Vom Modell zur industriellen Anwendung

Die lokale Simulation bildet kein vollständiges MQTT-Protokoll ab. Sie demonstriert ausgewählte Mechanismen auf Anwendungsebene.

Eine reale Umsetzung müsste unter anderem Verbindungszustände, persistente Nachrichten, Zeitstempel, Speichergrenzen, geeignete Wiederholungsintervalle und End-to-End-Bestätigungen berücksichtigen.

Besonders wichtig: Wiederholtes Übertragen von Messdaten ist nicht gleichbedeutend mit dem wiederholten Ausführen von Maschinenbefehlen. Steuerbefehle benötigen eigene Sicherheits- und Freigabekonzepte.

Transferfall: Verbindungsabbruch während der Nachtschicht

Eine Produktionslinie erzeugt jede Sekunde eine Messung. Die Verbindung fällt für zehn Minuten aus.

Während der Störung entstehen 600 neue Messwerte.

Deine Aufgabe: Entwickle ein Konzept, das diese Daten ohne unkontrollierte Wiederholung oder stille Verluste behandelt.

Erwartete Überlegungen: Mindestens 600 Speicherplätze bei zuvor leerem Puffer und gleichbleibender Messrate, zusätzlicher Reserveplatz, dauerhafte Speicherung bei Neustartrisiko, Zustellungsprüfung und ausreichend Nachsendekapazität.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Was bezeichnet Industrial IoT? (Die digitale Vernetzung industrieller Geräte und Systeme) (!Das ausschließliche Speichern von Dateien auf einem USB-Stick) (!Eine mechanische Verbindung zwischen zwei Zahnrädern) (!Ein Verfahren zur manuellen Maschinenreinigung)

Welche Aufgabe übernimmt ein MQTT-Broker? (Er nimmt Nachrichten an und verteilt sie an passende Abonnenten) (!Er misst selbstständig jede Temperatur in der Fabrik) (!Er ersetzt grundsätzlich sämtliche Maschinensteuerungen) (!Er verhindert jeden Stromausfall)

Was beschreibt einen Verbindungsabbruch? (Die Kommunikation zwischen zwei beteiligten Komponenten ist unterbrochen) (!Alle bereits gespeicherten Daten werden automatisch gelöscht) (!Jeder Messwert wird zwingend doppelt erfasst) (!Die Sensorhardware ist immer zerstört)

Wozu dient ein Datenpuffer? (Zur vorübergehenden Speicherung noch nicht abgeschlossener Übertragungen) (!Zur automatischen Erhöhung der Sensorgenauigkeit) (!Zum mechanischen Schutz eines Netzwerkkabels) (!Zur dauerhaften Abschaltung des Gateways)

Welche Eigenschaft besitzt MQTT QoS 1? (Eine Nachricht kann mindestens einmal zugestellt werden und mehrfach eintreffen) (!Jede Nachricht wird ohne Bestätigung sofort gelöscht) (!Eine Anwendung führt jeden Maschinenbefehl garantiert exakt einmal aus) (!Die Übertragung funktioniert ohne Kommunikationsweg)

Warum erhalten Messwerte eindeutige Ereigniskennungen? (Damit fehlende und wiederholte Ereignisse erkannt werden können) (!Damit die Verbindung physikalisch schneller wird) (!Damit der Sensor keinen Strom benötigt) (!Damit die Raumtemperatur konstant bleibt)

Wann tritt ein Pufferüberlauf auf? (Wenn neue Daten nicht mehr in den verfügbaren Speicher passen) (!Wenn der Broker erfolgreich eine Nachricht bestätigt) (!Wenn die Warteschlange vollständig leer ist) (!Wenn der Sensor eine korrekte Zeitangabe liefert)

Warum kann bei einer verlorenen Quittung ein Duplikat entstehen? (Weil der Sender ohne empfangene Bestätigung erneut sendet) (!Weil sich jeder Messwert automatisch verdoppelt) (!Weil die CPU grundsätzlich zwei Sensoren benötigt) (!Weil eine Netzwerkverbindung nur einmal benutzt werden darf)

Was bedeutet kontrollierte Wiederaufnahme? (Dass die Übertragung nach einer Störung geordnet und begrenzt fortgesetzt wird) (!Dass alle gepufferten Nachrichten unkontrolliert gleichzeitig verschickt werden) (!Dass sämtliche alten Messwerte grundsätzlich gelöscht werden) (!Dass die Verbindung dauerhaft abgeschaltet bleibt)

Welche Grenze besitzt ein ausschließlich im RAM gespeicherter Puffer? (Sein Inhalt kann bei einem Neustart verloren gehen) (!Er garantiert dauerhaft gespeicherte Daten) (!Er benötigt niemals Speicherkapazität) (!Er erkennt automatisch sämtliche Messfehler)

Memory

Ordne die Begriffe ihren Bedeutungen zu.

Sequenzkennung	Identifikation einer bestimmten Messung
Zwischenspeicher	Vorübergehende Ablage ausstehender Nachrichten
Empfangsquittung	Rückmeldung über die Annahme
Idempotenz	Wiederholung ohne zusätzliche fachliche Wirkung
Wiederverbindung	Erneuter Kommunikationsaufbau nach Unterbrechung
Pufferüberlauf	Überschreitung der verfügbaren Speicherplätze
Drosselung	Begrenzung der Übertragungsgeschwindigkeit
Persistenz	Erhaltung gespeicherter Daten über einen Neustart hinweg

Drag and Drop

Ordne jeder Maßnahme ihre passende Wirkung zu.

Ordne die richtigen Begriffe zu.	Wirkung
Pufferung	Speichert noch nicht übertragene Messungen zwischen
Quittierung	Meldet die Annahme einer Nachricht zurück
Duplikaterkennung	Verhindert eine erneute fachliche Verarbeitung derselben Messung
Nachsenden	Wiederholt einen nicht bestätigten Übertragungsversuch
Überwachung	Macht einen ungewöhnlichen Rückstau sichtbar
Speicherkapazität	Bestimmt die maximale Größe der Warteschlange
Verbindungsprüfung	Stellt fest, ob eine Übertragung wieder möglich ist

Kreuzworträtsel

Broker	Wie heißt bei MQTT die Komponente zur Verteilung veröffentlichter Nachrichten?
Puffer	Wie heißt ein Speicher für zeitweise zurückgehaltene Messungen?
Sequenz	Wie nennt man eine geordnete Folge von Ereignissen?
Quittung	Wie nennt man eine Rückmeldung über den Empfang einer Nachricht?
Idempotenz	Wie heißt die Eigenschaft einer Operation ohne zusätzliche Wirkung bei Wiederholung?
Drosselung	Wie heißt die gezielte Begrenzung der Verarbeitungsgeschwindigkeit?

LearningApps

Optional kannst Du weitere Zuordnungsübungen suchen.

Hinweis: LearningApps ist ein externer Dienst. Verwende dort keine Messprotokolle, Anlagendaten oder personenbezogenen Informationen. Die lokale Simulation benötigt diesen Dienst nicht.

Lückentext

Im Industrial Internet of Things tauschen industrielle Geräte über eine digitale

Informationen aus.

Ein MQTT-System verwendet häufig einen zentralen

zur Verteilung der Nachrichten.

Ein Sensor kann seine Messwerte über einen

veröffentlichen.

Eine Unterbrechung der Datenverbindung bezeichnet man als

.

Nicht übertragene Messungen lassen sich in einem

zwischenspeichern.

Nach einer Unterbrechung kann das System eine

durchführen.

Die geordnete Wiederholung eines Übertragungsversuchs bezeichnet man als

.

Eine Rückmeldung über die Annahme einer Nachricht nennt man

.

Wird eine Nachricht mehrfach empfangen, handelt es sich um ein

.

Wenn die Warteschlange vollständig belegt ist, entsteht ein

.

Eindeutige Kennungen helfen bei der Prüfung der

.

Die dauerhafte Erhaltung von Daten über einen Neustart hinweg wird als

bezeichnet.

Die Begrenzung der Sendegeschwindigkeit wird auch

genannt.

Die im Programm erzeugte Protokolldatei besitzt das Format

.

Offene Aufgaben

Die Aufgaben sind in Basis-, Anwendungs- und Transferniveau gegliedert. Verwende ausschließlich selbst erzeugte Daten und isolierte lokale Testumgebungen.

Leicht – Basisaufgaben

Datenfluss: Zeichne eine einfache Verpackungslinie mit Sensor, Gateway und Überwachung. Kennzeichne den Datenweg.
Fehlererkennung: Beschreibe anhand der Simulation, was bei einem zweitäktigen Verbindungsabbruch passiert.
Puffer: Erstelle eine kleine Zeichnung mit drei Speicherplätzen und stelle dar, wie die Messwerte aufgenommen werden.
Messprotokoll: Starte den Simulator im Normalbetrieb und dokumentiere die empfangenen Ereignis-IDs.

Feedback zur Basisstufe: Deine Lösung ist richtig, wenn Datenquelle, Übertragungsweg und Speicherfunktion korrekt voneinander unterschieden werden. Im Normalfall müssen alle acht Ereignis-IDs eintreffen.

Standard – Anwendungsaufgaben

Fehlersimulation: Vergleiche den Verbindungsausfall mit dem Paketverlust. Dokumentiere Gemeinsamkeiten und Unterschiede.
Duplikaterkennung: Simuliere eine verlorene Quittung und erkläre die wiederholte Zustellung von Ereignis-ID 4.
Datenvisualisierung: Erzeuge das lokale Balkendiagramm aus der CSV-Datei und beschreibe den höchsten Pufferstand.
Kapazitätsplanung: Verändere die Pufferkapazität im Code von drei auf fünf Plätze und untersuche den Überlauffall erneut.

Feedback zur Anwendungsstufe: Erkläre nicht nur das beobachtete Ergebnis, sondern auch seine Ursache. Ein größerer Puffer kann Verluste durch Überlauf reduzieren; er beseitigt jedoch nicht die Ursache einer Verbindungsstörung.

Schwer – Transferaufgaben

Fehlertoleranz: Entwickle ein Konzept, mit dem Messdaten zusätzlich in einer lokalen SQLite-Datenbank gesichert werden könnten. Berücksichtige den Neustart des Programms.
Lastmanagement: Erweitere die Simulation um eine einstellbare maximale Nachsendeleistung und vergleiche die Rückstaudauer.
Monitoring: Entwickle eine lokale Anzeige, die bei drohendem Pufferüberlauf eine Warnung ausgibt. Verwende nur fiktive Testdaten.
Industrie 4.0: Erstelle ein Sicherheits- und Wiederanlaufkonzept für eine simulierte vernetzte Produktionsanlage. Unterscheide Messdaten von sicherheitsrelevanten Steuerbefehlen.

Feedback zur Transferstufe: Gute Lösungen berücksichtigen Datenintegrität, Speichergrenzen, Wiederholungen und das Verhalten bei erneuten Unterbrechungen. Die bloße Erhöhung der Sendegeschwindigkeit genügt nicht in jedem Fehlerfall.

Gestufte Lernhilfen

Hilfe für Basisaufgaben

Stufe 1: Nutze die Abbildungen zum MQTT-Datenweg.

Stufe 2: Unterscheide den erzeugenden Sensor, die übertragende Komponente und die empfangende Anwendung.

Stufe 3: Überprüfe, ob alle acht erwarteten Ereignis-IDs vorkommen.

Hilfe für Anwendungsaufgaben

Stufe 1: Vergleiche mehrere Simulationsläufe.

Stufe 2: Untersuche die Variablen für Verbindungszustand, Pufferkapazität und Anzahl der Versuche.

Stufe 3: Verwende die CSV-Ausgabe zur Begründung. Ein hoher Pufferstand zeigt Rückstau, beweist aber nicht allein einen dauerhaften Datenverlust.

Hilfe für Transferaufgaben

Stufe 1: Überlege, welche Fehler noch nicht simuliert werden.

Stufe 2: Prüfe insbesondere Stromausfall, erneute Unterbrechung und unvollständige Empfangsbestätigungen.

Stufe 3: Entwirf ein Konzept mit persistenter Warteschlange, stabiler Ereignis-ID, definiertem Bestätigungszeitpunkt, begrenztem Nachsenden und Überwachung.

Lernkontrolle

Bearbeite die folgenden Aufgaben möglichst mit einer eigenen Skizze, einem kurzen Testprotokoll oder einer begründeten Entscheidung.

Systemanalyse: Eine Anlage verliert während einer dreiminütigen Unterbrechung keine Daten, erreicht aber nach der Wiederverbindung einen dauerhaft hohen Pufferstand. Erkläre zwei mögliche Ursachen und geeignete Gegenmaßnahmen.
Fehlerdiagnose: Zwei identische Messungen erscheinen im Überwachungssystem. Entwickle ein Verfahren, um eine echte zweite Messung von einem Übertragungsduplikat zu unterscheiden.
Kapazitätsberechnung: Eine Anlage erzeugt fünf Messwerte je Sekunde und kann 900 Werte puffern. Bestimme die maximale überbrückbare Unterbrechungsdauer bei leerem Startpuffer und ohne Übertragung während des Ausfalls. Begründe die Grenzen dieser Rechnung.
Datensicherheit: Erkläre, warum ein erfolgreiches MQTT-PUBACK nicht unbedingt den erfolgreichen Eintrag in einer Datenbank bestätigt.
Wiederanlauf: Entwickle eine begründete Strategie, mit der ein Gateway einen größeren Messdatenrückstand abbaut, ohne das Zielsystem zu überlasten.
Systemzuverlässigkeit: Vergleiche einen flüchtigen RAM-Puffer und eine persistente Speicherung im Hinblick auf Unterbrechung, Neustart, Speicheraufwand und Datenintegrität.
Sicherheitsbewertung: Begründe, warum ein Nachsendemechanismus für Temperaturmesswerte nicht unverändert für Bewegungs- oder Schaltbefehle einer Maschine eingesetzt werden darf.

Bewertungsmaßstab

Kriterium	Erkennbar an
Fachverständnis	Fachbegriffe werden korrekt verwendet
Fehleranalyse	Ursachen und Auswirkungen werden unterschieden
Datenprüfung	Fehlende und doppelte Messungen werden erkannt
Lösungskompetenz	Maßnahmen werden passend zum Fehler gewählt
Transfer	Die Lösung berücksichtigt neue Randbedingungen
Sicherheit	Die Erprobung bleibt auf autorisierte Testumgebungen beschränkt

Lernnachweis

Für einen vollständigen Lernnachweis dokumentierst Du Deine selbstständige Arbeit an der Simulation.

Systemskizze: Datenweg der fiktiven Verpackungslinie.
Testprotokoll: Ergebnisse aus mindestens drei unterschiedlichen lokalen Simulationsszenarien.
Datenvisualisierung: Darstellung des Pufferstands mit kurzer Interpretation.
Fehlerbegründung: Unterschied zwischen Verbindungsunterbrechung, Paketverlust, Quittungsverlust und Pufferüberlauf.
Codeverständnis: Erklärung der Zwischenspeicherung, erneuten Übertragung und Duplikaterkennung.
Transferlösung: Begründetes Konzept für einen verbesserten Wiederanlauf.
Sicherheitsreflexion: Beschreibung der Grenzen des Simulationsmodells und der Trennung von realen Anlagen.

Mögliche Bewertung: 30 Prozent Simulation und Auswertung, 25 Prozent Fehleranalyse, 25 Prozent Transferkonzept und 20 Prozent fachlich nachvollziehbare Dokumentation.

Alle Nachweise enthalten ausschließlich eigene fiktive Messwerte und keine betrieblichen Zugangsdaten, Kundendaten oder Informationen aus fremden Systemen.

OERs zum Thema

Wikipedia: MQTT

Ergänzende Wikipedia-Lernbereiche

Internet der Dinge: Grundlagen vernetzter Geräte.
Industrie 4.0: Vernetzung industrieller Produktionssysteme.
MQTT: Nachrichtenbasierte Kommunikation.
Message Queuing: Warteschlangen für Nachrichten.
Paketverlust: Fehlende Nachrichten in der Übertragung.
Fehlertoleranz: Umgang mit Störungen.
Datenintegrität: Vollständigkeit und Korrektheit von Daten.
Idempotenz: Sichere Wiederholbarkeit von Operationen.

Fachquellen und Medienrechte

Geprüfte Fachquellen

MQTT-Protokoll:

OASIS: MQTT Version 5.0, offizieller Standard, 2019

Die Spezifikation beschreibt das Publish-Subscribe-Prinzip, die MQTT-Qualitätsstufen, Zustellbestätigungen und Sitzungszustände.

Sicherheit industrieller Systeme:

NIST SP 800-82 Revision 3: Guide to Operational Technology Security, 2023

Diese Quelle behandelt Sicherheitsanforderungen industrieller Betriebstechnologie unter besonderer Berücksichtigung von Verfügbarkeit, Zuverlässigkeit und Sicherheit.

Zusätzliche Einführung:

HiveMQ: MQTT Quality of Service Levels

Der Artikel erläutert QoS 0, QoS 1 und QoS 2 sowie deren Einsatzgrenzen.

Bildlizenzen

Die im Kurs verwendeten Wikimedia-Commons-Dateien wurden hinsichtlich Dateiexistenz, Urheberangaben und Lizenzhinweisen geprüft.

Digitale lösungen smart factory.jpg: EngelGMA, CC BY-SA 4.0.
Sensor node.jpg: Wsnlab, CC BY-SA 3.0.
MQTT SYSTEM DESIGN.png: Chine3me, CC0 1.0.
Arquitetura MQTT exemplo.png: Ana beloti, CC BY-SA 4.0.
MQTT protocol example without QoS.svg: Simon A. Eugster, CC BY-SA 4.0.
MQTT Publish packet.svg: Blacktron, CC BY-SA 4.0.
MQTT single broker multiple listener tls single.svg: Ademant, CC BY-SA 4.0.

Die ursprünglichen Bilder werden unverändert eingebunden. Bei Weiterverwendung sind die jeweiligen Lizenzbedingungen und Namensnennungen zu beachten.

Videos und externe Dienste

Die eingebetteten YouTube-Videos stammen aus der MQTT-Essentials-Reihe von HiveMQ. Sie dienen der fachlichen Vertiefung und werden nur über den Videoplayer referenziert.

Eine freie OER-Lizenz dieser Videos wurde nicht nachgewiesen. Daher dürfen sie nicht ohne entsprechende Erlaubnis als frei weiterverwendbare Videodateien verbreitet werden.

YouTube, Wikipedia und LearningApps sind externe Angebote. Beim Laden solcher Inhalte können Verbindungsdaten an die jeweiligen Anbieter übermittelt werden. Keine dieser Verbindungen ist für die lokale Python-Simulation notwendig.

Verknüpfte Lernbereiche

Digitale Vernetzung und Industrial IoT

Fazit

Das hast Du gelernt:

Eine unterbrochene Verbindung muss nicht zwangsläufig zu Datenverlust führen. Entscheidend sind die vorhandenen Puffer, die Behandlung unbestätigter Nachrichten und die kontrollierte Wiederaufnahme.

Die lokale Simulation zeigt zugleich ihre Grenzen: Ein zu kleiner Puffer kann überlaufen, verlorene Quittungen können Duplikate verursachen und flüchtig gespeicherte Daten können bei einem Neustart verschwinden.

Eine zuverlässige industrielle Lösung verbindet deshalb Pufferung, Datensicherung, Ereigniskennungen, Übertragungsbestätigung, Lastbegrenzung und Monitoring.