Technische Kernaussagen
- Die Maschine braucht einen dauerhaften lokalen Besitzpunkt für noch nicht gesendete Daten.
- Jeder Datensatz braucht Ereigniszeit, Sequenz, Schemaversion und eine stabile ID.
- Eine volle Queue ist ein sichtbarer Betriebszustand und darf nicht still Daten vernichten.
Das Netzwerk ist Transport, kein Archiv
Routerwechsel, Zertifikate, DNS, Mobilfunk und Wartung unterbrechen industrielle Verbindungen regelmäßig. Die Steuerung muss lokal weiterlaufen; die Telemetrie muss wissen, welche Daten noch nicht dauerhaft angekommen sind.[1][4]
Datensätze brauchen eine replay-feste Identität
Maschinen-ID, Signal-ID, Wert, Qualität, Ereigniszeit, Sequenz, Schemaversion, Softwareversion und stabile Record-ID gehören zusammen. Ereignis- und Ingest-Zeit dürfen nicht verwechselt werden.[6][5]
- Sequenz oder eindeutige ID zur Deduplizierung
- Zeitqualität und Uhrwechsel markieren
- Payload-Schema versionieren
- Stale- und Offline-Zustände explizit übertragen
Ein begrenztes lokales Journal verwenden
Eine eingebettete Datenbank oder ein Append-only-Log ist oft robuster als ein eigenes Dateiformat. Eine Komponente muss Reihenfolge, Bestätigung, Komprimierung und Crash-Recovery besitzen.[2][3]
| Status | Lokal | Cloud | Aktion |
|---|---|---|---|
| Queued | Dauerhaft | Unbekannt | Mit gleicher ID erneut senden |
| In flight | Dauerhaft | Wartet | Nach Timeout erneut |
| Bestätigt | Dauerhaft | Gespeichert | Komprimierbar |
| Abgelaufen | Nach Regel | Nicht gesendet | Verlust zählen |
Historie nachholen, ohne den Live-Blick zu blockieren
Reservieren Sie Bandbreite für aktuelle Gesundheit und Alarme und leeren Sie historische Batches kontrolliert. So bleibt die Live-Sicht frisch, während die Lücke geschlossen wird.[1][5]
MQTT QoS 1 bedeutet mindestens einmal und erlaubt Duplikate. Genau-einmal-Verarbeitung braucht weiterhin stabile IDs und idempotente Speicherung.[1]
Vorher entscheiden, was bei vollem Speicher geschieht
Kapazität folgt aus Ausfalldauer, Datenrate, Overhead und Reserve. Regeln müssen je Signalklasse festlegen, was verdichtet, geschützt oder verworfen wird.[4]
- Queue-Alter, Bytes und Verluste anzeigen
- Runtime vor Speicherblockaden isolieren
- Retention spezifizieren
- Stromausfall in jeder Phase testen
Ein sinnvoller Ausfalltest
- Uplink bei laufender Maschine trennen
- Service neu starten und Controller stromlos machen
- Nach maximaler Ausfallzeit verbinden
- Zeit, Reihenfolge und Deduplizierung prüfen
- Live-Daten während Replay prüfen
- Speichergrenzen gezielt erreichen
Häufig gestellte Fragen
Reicht MQTT QoS 1?
Nein. Es definiert weder lokales Journal noch Retention, Schema oder Ende-zu-Ende-Deduplizierung.
Muss Replay global sortiert sein?
Meist reicht Reihenfolge pro Maschine und Signalstrom; globale Ordnung erzeugt unnötige Blockaden.
Wie viel Speicher reicht?
Aus maximaler Ausfallzeit, Datenvolumen, Retention und getesteter Reserve berechnen und als Grenze veröffentlichen.
Quellen und Standards
- MQTT Version 5.0OASIS Open
- Write-Ahead LoggingSQLite
- Transaction control languageSQLite
- NIST SP 800-82 Rev. 3: Guide to Operational Technology SecurityNational Institute of Standards and Technology, September 2023
- Prometheus Remote-Write 2.0 specificationPrometheus
- RFC 3339: Date and Time on the InternetIETF
BootCtrl Engineering hat die technischen Aussagen und Quellenlinks zuletzt am 26. Juli 2026 geprüft. Produktaussagen werden mit den aktuellen Implementierungs-Repositories abgeglichen; Roadmap-Arbeit wird nicht als verfügbare Funktion dargestellt.
