Eine IIoT-Anwendung läuft über Wochen störungsfrei. Sensoren und Steuerungen liefern ihre Messwerte an ein Edge-Gateway, von dort werden die Daten an einen Historian, ein SCADA-System oder eine Cloud-Plattform übertragen. Dann fällt die WAN-Verbindung aus. Die Maschine läuft weiter, die Messwerte entstehen weiterhin – aber das übergeordnete System ist für mehrere Stunden oder sogar Tage nicht erreichbar.
Ob nach Wiederherstellung der Verbindung eine vollständige Datenhistorie zur Verfügung steht, hängt jetzt wesentlich von der lokalen Pufferung ab. Ein Edge-System benötigt genügend persistenten Speicher, um alle relevanten Daten während der angenommenen Offline-Zeit aufnehmen zu können. Gleichzeitig muss festgelegt sein, welche Daten überhaupt gespeichert werden, wie groß ein Datensatz tatsächlich ist, welche Metadaten dazugehören und wie die aufgelaufenen Daten anschließend wieder übertragen werden.
Die Dimensionierung lässt sich deshalb nicht sinnvoll mit einer pauschalen Aussage wie „einige Gigabyte reichen“ beantworten. Die benötigte Speichergröße ergibt sich aus der tatsächlich gespeicherten Datenrate, der maximal geplanten Offline-Dauer, dem Speicher- und Datenbank-Overhead sowie einer angemessenen Reserve. Zusätzlich muss geprüft werden, ob die Kommunikationsverbindung nach dem Ausfall schnell genug ist, um den Datenrückstand wieder abzubauen.
Die zentrale Auslegungsregel lautet: Ein Edge-Pufferspeicher muss nicht nur groß genug sein, um einen Ausfall zu überstehen. Die gesamte Store-and-Forward-Kette muss so ausgelegt sein, dass Zeitstempel, Datenqualität und Reihenfolge erhalten bleiben und der entstandene Rückstand nach Wiederverbindung kontrolliert übertragen werden kann.
Warum Edge-Pufferung überhaupt erforderlich ist
Eine Cloud- oder Serververbindung ist in einer industriellen Anlage niemals vollkommen garantiert. Router können neu starten, VPN-Verbindungen abbrechen, Mobilfunkverbindungen ausfallen, Firewalls oder Zertifikate können Probleme verursachen und auch geplante Wartungsarbeiten können die Kommunikation vorübergehend unterbrechen.
Für die eigentliche Messwerterfassung muss dies nicht zwangsläufig ein Problem sein. Sensoren, Feldgeräte und Steuerungen können lokal weiterarbeiten. Kritisch wird der Ausfall erst dann, wenn die Architektur davon ausgeht, dass jeder Messwert unmittelbar nach seiner Entstehung an das übergeordnete System übertragen werden muss.
Ein Edge-Gateway mit lokalem Pufferspeicher entkoppelt deshalb die Messwerterfassung von der WAN- beziehungsweise Cloud-Verbindung. Die lokale Seite kann weiter Daten erfassen und speichern, während die Übertragung vorübergehend stillsteht. Nach Wiederherstellung der Verbindung werden die noch nicht übertragenen Datensätze nachgeliefert.
Eine typische Architektur kann vereinfacht so aussehen:
Sensor / SPS → Edge-Gateway → lokaler Puffer → MQTT / HTTPS → Historian / Cloud
Der lokale Puffer ist dabei nicht mit dem Langzeit-Historian zu verwechseln. Seine primäre Aufgabe besteht darin, Kommunikationsunterbrechungen kontrolliert zu überbrücken und Daten solange vorzuhalten, bis das Zielsystem die Übertragung bestätigt hat.
Von der Messstelle zur tatsächlichen Speicherdatenrate
Der erste Schritt bei der Dimensionierung ist die Bestimmung der tatsächlichen Datenrate. Ein häufiger Fehler besteht darin, nur die Anzahl der Messwerte und die Größe des eigentlichen Zahlenwertes zu betrachten. Ein Float-Wert benötigt beispielsweise nur wenige Byte. Ein industriell nutzbarer Datensatz besteht jedoch meistens aus deutlich mehr Informationen.
Neben dem eigentlichen Messwert können unter anderem Messstellen-ID, Zeitstempel, Einheit, Qualitätsstatus, Diagnoseinformationen, Sequenznummern und weitere Metadaten gespeichert werden. Hinzu kommen je nach Architektur die Struktur des Datenformats und der Speicher- beziehungsweise Datenbank-Overhead.
| Größe | Bedeutung | Einfluss auf die Dimensionierung |
|---|---|---|
| N | Anzahl der gespeicherten Datenpunkte | Mehr Messstellen erhöhen die Datenrate annähernd proportional |
| f | Speicherfrequenz je Datenpunkt | 1 Hz bedeutet beispielsweise einen gespeicherten Wert pro Sekunde |
| B | Effektive Bytezahl je gespeichertem Datenpunkt | Enthält Wert, Kennung, Zeitstempel, Status und Datenformat |
| t | Geplante Offline-Dauer | Bestimmt, wie lange Daten ohne Verbindung lokal vorgehalten werden müssen |
| kO | Speicher-/Datenbank-Overhead | Berücksichtigt beispielsweise Index, Journal, Dateistruktur und interne Metadaten |
| kR | Reservefaktor | Schafft Spielraum für Wachstum und Abweichungen von der Planannahme |
Für eine erste Abschätzung kann die Speicherdatenrate mit folgender Beziehung berechnet werden:
Rstore = N × f × B
Dabei ist Rstore die lokale Speicherdatenrate beispielsweise in Byte pro Sekunde.
Die entscheidende Größe ist dabei B. Sie sollte möglichst nicht aus der reinen Nutzdatenbreite des Sensors abgeleitet werden, sondern aus dem tatsächlich gespeicherten Datenformat. Ein Datensatz, der als binärer Block gespeichert wird, kann wesentlich kleiner sein als derselbe Messwert in einer ausführlichen JSON-Struktur mit Tag-Namen, Zeitstempel und Statusinformationen.
Warum das Datenmodell den Speicherbedarf stark beeinflusst
Die Größe eines einzelnen Prozesswertes sagt nur wenig über die Größe des gespeicherten Datensatzes aus. Ein Temperaturwert kann technisch beispielsweise als 32-Bit-Gleitkommazahl vorliegen und damit vier Byte benötigen. Sobald jedoch zusätzlich ein Zeitstempel, eine Messstellenkennung und ein Qualitätsstatus gespeichert werden, vervielfacht sich der Platzbedarf.
Noch deutlicher wird der Unterschied bei textorientierten Formaten. Eine Struktur wie:
{"tag":"pressure_01","timestamp":"2026-09-18T08:30:00.000Z","value":6.42,"quality":"Good"}
benötigt wesentlich mehr Speicherplatz als der reine Zahlenwert. Wird jeder einzelne Datenpunkt auf diese Weise abgelegt, wächst der benötigte Puffer entsprechend.
Das bedeutet allerdings nicht, dass möglichst kompakte Daten immer die beste Lösung sind. Für die spätere Nutzbarkeit können Messstellenkennung, Original-Zeitstempel und Qualitätsstatus wesentlich wichtiger sein als einige eingesparte Byte. Ziel sollte daher kein minimaler Datensatz sein, sondern ein klar definiertes und für die Anwendung ausreichendes Datenmodell.
| Rechenannahme | Speicherdatenrate | Datenmenge pro 24 h |
|---|---|---|
| 20 Datenpunkte, alle 10 s, 64 Byte je Punkt | 128 Byte/s | ca. 11,1 MB |
| 100 Datenpunkte, 1 Hz, 64 Byte je Punkt | 6,4 kB/s | ca. 553 MB |
| 500 Datenpunkte, 2 Hz, 64 Byte je Punkt | 64 kB/s | ca. 5,53 GB |
| 100 Datenpunkte, 1 Hz, 150 Byte je Punkt | 15 kB/s | ca. 1,30 GB |
Die Tabelle zeigt, wie stark sich Anzahl der Messstellen, Speicherfrequenz und Datensatzgröße auswirken. Insbesondere bei großen IIoT-Installationen können aus scheinbar kleinen Änderungen der Aufzeichnungsstrategie mehrere Gigabyte zusätzlicher Daten pro Tag entstehen.
Grundformel zur Dimensionierung
Ist die effektive Speicherdatenrate bekannt, kann der reine Datenbedarf während einer Kommunikationsunterbrechung zunächst einfach berechnet werden:
Mraw = Rstore × toffline
Dieser Wert entspricht jedoch nur der theoretischen Nutzdatenmenge. Für die technische Auslegung sollte zusätzlich berücksichtigt werden, dass Datenbanken, Journaling, Indizes, Dateisysteme und Queue-Strukturen zusätzlichen Platz beanspruchen können.
Eine praxisnahe Planungsformel lautet deshalb:
Mplan = Mraw × kO × kR
Dabei beschreibt kO den tatsächlich zu erwartenden Speicher-Overhead und kR die gewünschte Planungsreserve.
Die Faktoren sollten möglichst aus einem Testsystem beziehungsweise einer realen Datenaufzeichnung ermittelt werden. Pauschale Prozentwerte sind nur für eine erste Abschätzung geeignet. Gerade bei Datenbanken können Datenstruktur, Indexierung, Kompression, Journaling und Anzahl kleiner Dateien erheblichen Einfluss auf den tatsächlichen Speicherbedarf haben.
Praxisbeispiel: 72 Stunden Offline-Betrieb
Ein Maschinenbauer möchte 120 Prozesswerte über ein Edge-System erfassen. Jeder Datenpunkt wird einmal pro Sekunde gespeichert. Aus einem Testbetrieb wurde ermittelt, dass ein persistierter Datensatz einschließlich Zeitstempel, Messstellenkennung und Qualitätsinformation durchschnittlich etwa 80 Byte beansprucht.
Die Speicherdatenrate beträgt damit:
Rstore = 120 × 1 × 80 Byte/s
Rstore = 9.600 Byte/s
Pro Tag entstehen damit ungefähr:
9.600 × 86.400 = 829.440.000 Byte
Das entspricht für die überschlägige Planung rund 829 MB pro Tag.
Die Anlage soll einen Ausfall von maximal 72 Stunden beziehungsweise drei Tagen ohne Datenverlust überbrücken können:
Mraw = 829 MB × 3 ≈ 2,49 GB
In einem Test zeigt sich, dass Datenbank und Queue etwa 20 % zusätzlichen Platz benötigen. Für die Planung wird außerdem beispielhaft eine Reserve von 30 % angesetzt:
Mplan = 2,49 GB × 1,20 × 1,30
Mplan ≈ 3,88 GB
Für diese eine Anwendung wären daher rund 3,9 GB nutzbarer Pufferspeicher ein rechnerischer Planwert. Das bedeutet jedoch nicht, dass eine 4-GB-Systempartition ausreichend wäre. Betriebssystem, Anwendungen, Logs, Updates und weitere lokale Daten benötigen eigenen Speicherplatz. Der für Store-and-Forward vorgesehene Speicher sollte deshalb technisch klar vom übrigen freien Speicher des Systems unterschieden werden.
Speicherreserve richtig einplanen
Eine Speicherreserve ist wichtig, weil die Datenrate in realen Anlagen selten vollkommen konstant ist. Zusätzliche Diagnosewerte können hinzukommen, Softwareversionen können das Datenformat verändern und bei Störungen entstehen unter Umständen mehr Ereignisse und Alarme als im normalen Betrieb.
Die Reserve sollte jedoch nicht willkürlich gewählt werden. Sinnvoller ist es, zunächst möglichst realistische Messdaten über einen repräsentativen Zeitraum zu erfassen und daraus den tatsächlichen Speicherzuwachs zu bestimmen. Anschließend wird eine Reserve entsprechend dem Anlagenrisiko, der geplanten Betriebsdauer und der erwarteten Erweiterung vorgesehen.
Außerdem sollte das System nicht erst dann reagieren, wenn der Datenträger vollständig belegt ist. Eine volle Systempartition kann neben dem eigentlichen Datenverlust weitere Probleme verursachen: Datenbanken können keine Journale mehr schreiben, Anwendungen können abstürzen und selbst Systemdienste können beeinträchtigt werden.
| Offline-Dauer | Rohdaten bei 100 Punkten, 1 Hz, 64 Byte | Planwert mit Faktor 1,25 Overhead und 30 % Reserve |
|---|---|---|
| 8 Stunden | ca. 184 MB | ca. 300 MB |
| 24 Stunden | ca. 553 MB | ca. 899 MB |
| 72 Stunden | ca. 1,66 GB | ca. 2,70 GB |
| 7 Tage | ca. 3,87 GB | ca. 6,29 GB |
Auch diese Werte sind bewusst Rechenbeispiele und keine allgemeingültigen Speicherempfehlungen. Entscheidend ist immer das tatsächlich verwendete Datenmodell.
Welche Offline-Dauer sollte angesetzt werden?
Die geplante Offline-Dauer darf nicht ausschließlich aus der technischen Erwartung an die Internetverbindung abgeleitet werden. Relevant ist vielmehr die längste realistische Zeitspanne, in der das Zielsystem nicht erreichbar sein könnte.
Bei einer Produktionsanlage mit eigenem IT-Bereitschaftsdienst kann ein Kommunikationsproblem möglicherweise innerhalb weniger Stunden behoben werden. Bei einer abgelegenen Messstation, einem Mobilfunkstandort oder einer Anlage, die über ein Wochenende unbeaufsichtigt läuft, können mehrere Tage realistischer sein.
Auch geplante Arbeiten sollten berücksichtigt werden. Werden beispielsweise Firewall-Regeln, VPN-Systeme oder Cloud-Dienste gewartet, kann eine Unterbrechung entstehen, obwohl die lokale Anlage technisch fehlerfrei arbeitet.
Für die Planung sollte daher nicht gefragt werden: „Wie lange fällt unsere Verbindung normalerweise aus?“, sondern: „Welche Offline-Dauer müssen wir ohne Datenverlust sicher beherrschen?“
Abtastrate, Deadband und Change-of-Value unterscheiden
Bei der Speicherberechnung ist zwischen Mess-, Speicher- und Übertragungsfrequenz zu unterscheiden. Ein Sensor kann intern beispielsweise mit hoher Frequenz messen, während das Edge-System nur einmal pro Sekunde einen Wert speichert. Ebenso kann ein Edge-System Daten lokal mit 1 Hz aufzeichnen, aber mehrere Messwerte gebündelt nur alle 30 Sekunden an die Cloud übertragen.
Auch Change-of-Value beziehungsweise Deadband kann die Datenmenge deutlich reduzieren. Bei langsam veränderlichen Prozessgrößen muss nicht zwingend jeder zyklisch gelesene Messwert erneut gespeichert oder übertragen werden, wenn sich der Wert nicht relevant verändert hat.
Für die Pufferspeicher-Dimensionierung ist jedoch Vorsicht geboten: Eine durchschnittlich niedrige Change-of-Value-Datenrate garantiert nicht, dass die Datenrate während eines Störfalls ebenfalls niedrig bleibt. Gerade bei dynamischen Anlagen können während eines Prozessereignisses sehr viele Änderungen auftreten.
Der Pufferspeicher sollte deshalb nicht ausschließlich auf einem besonders ruhigen Normalbetrieb dimensioniert werden. Für kritische Anwendungen ist eine realistische obere Datenrate beziehungsweise ein technisch plausibler Worst Case wesentlich aussagekräftiger.
Zeitstempel und Datenqualität erhalten
Store-and-Forward funktioniert nur dann sauber, wenn ein nachträglich übertragener Messwert weiterhin seinem ursprünglichen Erfassungszeitpunkt zugeordnet werden kann.
Würde ein während eines dreistündigen Netzwerkausfalls gespeicherter Druckwert beim späteren Upload einen neuen Zeitstempel erhalten, sähe das übergeordnete System so aus, als wäre dieser Wert erst zum Zeitpunkt der Wiederübertragung entstanden. Die historische Prozessdarstellung wäre dadurch verfälscht.
Ein sinnvoller Puffereintrag sollte daher mindestens die für die Anwendung relevanten Informationen erhalten, beispielsweise:
- eindeutige Messstellenkennung,
- Messwert,
- Original-Zeitstempel beziehungsweise Source Timestamp,
- Qualitäts- oder Statusinformation,
- bei Bedarf Einheit beziehungsweise Skalierungsinformation,
- gegebenenfalls Sequenznummer oder eindeutige Datensatz-ID.
Gerade bei einer späteren Wiederübertragung ist der Qualitätsstatus wichtig. Ein numerischer Wert allein sagt nicht, ob er tatsächlich frisch gemessen wurde, ob die Sensorverbindung bereits gestört war oder ob lediglich der zuletzt bekannte Wert weitergeführt wurde.
Store-and-Forward richtig aufbauen
Ein robuster Edge-Puffer arbeitet nicht nach dem Prinzip „Datei schreiben und irgendwann senden“. Es sollte eindeutig nachvollziehbar sein, welche Daten bereits erfolgreich übertragen wurden und welche noch ausstehen.
Ein typischer Ablauf besteht darin, einen Datensatz zunächst persistent lokal zu speichern. Anschließend versucht das Edge-System die Übertragung an das Ziel. Erst wenn die gewählte Kommunikations- beziehungsweise Anwendungsschicht den Datensatz als erfolgreich verarbeitet betrachtet, kann er aus der offenen Queue entfernt oder als übertragen markiert werden.
Je nach System können dabei unterschiedliche Mechanismen eingesetzt werden: lokale Datenbanken, persistente Message Queues, Journale oder speziell implementierte Store-and-Forward-Puffer. Entscheidend ist weniger die Bezeichnung als das Verhalten bei Fehlern.
Das System sollte insbesondere klar definieren, was nach einem Neustart geschieht, wie doppelte Datensätze verhindert beziehungsweise erkannt werden und in welcher Reihenfolge alte und neue Daten übertragen werden.
Bei langen Ausfällen kann es außerdem sinnvoll sein, Daten verschiedener Priorität unterschiedlich zu behandeln. Prozessalarme und Zustandsänderungen können beispielsweise wichtiger sein als hochfrequente Trendwerte. Eine solche Strategie muss allerdings bereits im Datenmodell und in der Queue-Logik vorgesehen werden.
Kann der Rückstand nach dem Ausfall schnell genug übertragen werden?
Ein ausreichend großer Speicher löst nur die erste Hälfte des Problems. Nach Wiederherstellung der Verbindung muss der aufgelaufene Datenbestand zusätzlich übertragen werden, während gleichzeitig bereits neue Live-Daten entstehen.
Entscheidend ist deshalb die freie Übertragungskapazität oberhalb des laufenden Datenstroms.
Vereinfacht gilt:
Rfrei = RUpload - RLive
Nur dieser verbleibende Anteil kann zum Abbau des Puffers verwendet werden.
Die ungefähre Wiederaufholzeit ergibt sich dann aus:
tReplay = MBacklog / Rfrei
Ein Beispiel: Nach einem längeren Ausfall liegen 2 GB nachzuliefernde Daten vor. Die Verbindung kann unter den tatsächlichen Bedingungen 150 kB/s für diese Anwendung übertragen. Gleichzeitig benötigen die laufenden neuen Daten einschließlich Protokoll-Overhead bereits 25 kB/s.
Für den Abbau des Rückstands bleiben somit:
150 kB/s - 25 kB/s = 125 kB/s
Unter idealisierten Bedingungen benötigt die Übertragung des 2-GB-Rückstands damit rund 4,4 Stunden.
Wäre die nutzbare Uploadrate dagegen kleiner oder gleich der laufenden Live-Datenrate, würde der Puffer trotz wiederhergestellter Verbindung nicht kleiner. Der Rückstand könnte dann dauerhaft bestehen bleiben oder sogar weiter wachsen.
Bei dieser Rechnung müssen gespeicherte Datenmenge und tatsächlich übertragene Datenmenge auf derselben Basis betrachtet werden. MQTT-, HTTPS- oder andere Protokollrahmen, Verschlüsselung, Batch-Größe und mögliche Kompression können dazu führen, dass die Netzwerkdatenrate nicht exakt der lokalen Speicherdatenrate entspricht.
Persistenter Speicher statt flüchtigem RAM-Puffer
Für einen kurzen Kommunikations-Jitter von wenigen Sekunden kann ein RAM-Puffer ausreichend sein. Für geplante Store-and-Forward-Funktionen über Stunden oder Tage ist ausschließlich flüchtiger Arbeitsspeicher dagegen problematisch. Fällt gleichzeitig die Versorgung des Edge-Gerätes aus oder startet das Betriebssystem neu, sind nicht persistierte Daten verloren.
Für eine belastbare Offline-Pufferung müssen relevante Datensätze deshalb auf einem persistenten Medium gespeichert werden. Je nach Plattform kann dies beispielsweise eMMC, SSD, Industrie-SD-Speicher oder ein anderes nichtflüchtiges Speichersystem sein.
Neben der nominellen Kapazität ist bei häufigem Schreiben auch die Schreibbelastung zu berücksichtigen. Eine Anwendung, die dauerhaft viele kleine Datensätze schreibt, kann einen Flash-Speicher anders belasten als eine Anwendung, die größere Blöcke sammelt und gebündelt schreibt.
Ebenso wichtig sind Dateisystem- und Datenbankverhalten bei abruptem Spannungsverlust. Eine USV beziehungsweise gepufferte Versorgung kann Bestandteil des Gesamtkonzeptes sein, ersetzt aber keine konsistente Speicher- und Datenbankstrategie.
IT/OT-Betrieb und Überwachung des Puffers
Ein Pufferspeicher sollte im laufenden Betrieb nicht unsichtbar bleiben. Wenn der Speicher lediglich still im Hintergrund wächst, wird eine fehlerhafte Cloud-Verbindung unter Umständen erst bemerkt, wenn der lokale Datenträger nahezu voll ist.
Sinnvolle Betriebsgrößen sind beispielsweise:
- aktuelle Queue-Größe,
- belegter und freier Pufferspeicher,
- Alter des ältesten noch nicht übertragenen Datensatzes,
- Anzahl ausstehender Datensätze,
- aktuelle Schreib- und Uploadrate,
- Zustand der Verbindung zum Zielsystem,
- Zeitpunkt der letzten erfolgreich bestätigten Übertragung.
Auf dieser Basis können Warnschwellen definiert werden. Eine Meldung bei beispielsweise 70 oder 80 % Pufferbelegung kann deutlich sinnvoller sein, als erst auf einen vollständig gefüllten Datenträger zu reagieren. Der konkrete Schwellenwert muss jedoch zur jeweiligen Architektur und Reaktionszeit des Betreibers passen.
Systematischer Planungs- und Prüfablauf
Für neue IIoT-Projekte lässt sich die Pufferspeicher-Dimensionierung in einem klaren Ablauf durchführen.
- Alle relevanten Datenpunkte erfassen: Welche Prozesswerte, Zustände, Alarme und Diagnoseinformationen müssen offline erhalten bleiben?
- Speicherfrequenz definieren: Nicht nur die Sensor-Abtastrate, sondern die tatsächlich persistierte Rate festlegen.
- Datenmodell definieren: Messwert, Zeitstempel, Tag-ID, Status und weitere Metadaten festlegen.
- Reale Datensatzgröße messen: Wenn möglich nicht schätzen, sondern einen repräsentativen Datenbestand erzeugen.
- Speicherdatenrate bestimmen: Datenmenge pro Minute, Stunde oder Tag berechnen beziehungsweise messen.
- Maximale Offline-Dauer festlegen: Technische Störung, Wartung und unbeaufsichtigte Zeiträume berücksichtigen.
- Overhead einbeziehen: Datenbank, Queue, Journal und Dateisystem berücksichtigen.
- Reserve definieren: Wachstum, zusätzliche Tags und Lastspitzen einplanen.
- Replay prüfen: Sicherstellen, dass der Rückstand nach Wiederverbindung schneller abgebaut werden kann, als neue Daten entstehen.
- Grenzfall testen: Netzwerk tatsächlich trennen und den vorgesehenen Offline-Zeitraum beziehungsweise einen realistischen Testfall simulieren.
- Neustart testen: Prüfen, ob ungeuploadete Daten auch nach einem kontrollierten Neustart weiterhin vorhanden sind.
- Monitoring einrichten: Pufferfüllstand und Alter der ältesten Daten überwachen.
Ein solcher Test ist wesentlich aussagekräftiger als eine rein theoretische Betrachtung. Gleichzeitig lässt sich dabei feststellen, ob die Daten nach Wiederverbindung in der richtigen Reihenfolge und mit dem ursprünglichen Zeitbezug im Zielsystem erscheinen.
Häufige Planungsfehler
Nur den eigentlichen Messwert in Byte berechnen
Ein Float-Wert allein bildet nicht den tatsächlichen Speicherbedarf ab. Zeitstempel, IDs, Qualität, Datenformat und Datenbankstrukturen können einen wesentlich größeren Anteil ausmachen.
Sampling-Rate mit Speicherrate verwechseln
Ein Sensor kann deutlich schneller messen, als Werte tatsächlich gespeichert werden. Für die Puffergröße ist die persistierte Datenrate entscheidend.
Nur den durchschnittlichen Normalbetrieb betrachten
Bei ereignisbasierter Speicherung kann gerade ein Anlagenfehler besonders viele Daten erzeugen. Ein Puffer, der nur auf einem ruhigen Produktionszustand basiert, kann genau im kritischen Ereignis zu klein sein.
Keine Reserve für Datenbank und Dateisystem vorsehen
Die Summe der Nutzdaten entspricht nicht zwingend dem real belegten Speicherplatz.
Den kompletten freien Systemdatenträger als Puffer einplanen
Betriebssystem, Logs, Updates und Anwendungen benötigen weiterhin freien Speicher. Ein volles Dateisystem kann das gesamte Edge-System beeinträchtigen.
Nur die Offline-Zeit berechnen
Nach der Wiederverbindung muss der Rückstand zusätzlich übertragen werden. Reicht die verfügbare Bandbreite dafür nicht aus, bleibt der Buffer dauerhaft gefüllt.
Zeitstempel erst beim späteren Upload vergeben
Dadurch geht der ursprüngliche Messzeitpunkt verloren. Die Historie im Zielsystem kann zeitlich falsch dargestellt werden.
Nur RAM als langfristigen Buffer einsetzen
Nach einem Stromausfall oder Neustart können die gepufferten Daten verloren sein. Für längere Offline-Zeiten ist persistente Speicherung erforderlich.
Das Verhalten bei vollem Speicher nicht definieren
Jede Architektur benötigt eine klare Strategie für den Grenzfall. Soll der älteste Datensatz verworfen werden? Darf überhaupt verworfen werden? Muss die Anlage alarmieren oder eine andere Betriebsstrategie einleiten? Diese Entscheidung sollte nicht dem zufälligen Verhalten eines vollen Dateisystems überlassen werden.
IIoT-Lösungen bei ICS Schneider
ICS Schneider Messtechnik unterstützt IIoT-Architekturen von der industriellen Messstelle über Edge- und Gateway-Ebenen bis zur Anbindung an übergeordnete IT-, SCADA-, Historian- oder Cloud-Systeme.
Typische Datenketten können Feldgeräte und Sensoren über Schnittstellen wie Modbus RTU, IO-Link, HART, OPC UA oder Ethernet in eine Edge-Ebene integrieren. Von dort können Messdaten beispielsweise über MQTT beziehungsweise HTTPS an weitere Systeme weitergegeben werden.
Für die hier beschriebene Pufferung ist wichtig, die tatsächlich verfügbare Gateway- und Softwarefunktion projektspezifisch zu prüfen. Nicht jedes Gerät, das als Gateway eingesetzt wird, besitzt automatisch dieselben Funktionen für lokale Datenbanken, persistente Queues, Store-and-Forward oder Speicherverwaltung.
Ein Beispiel einer bei ICS geführten IIoT-Architektur ist der Siemens SITRANS MS200 zur Vibrations- und Temperaturüberwachung in Kombination mit dem SITRANS CC220 Gateway. Ein weiteres Beispiel ist die Siemens IIoT-Wägeelektronik 7MH4647-0KK00-0AA2 für Anwendungen mit dem SIMATIC IOT2050.
IIoT-Lösungen bei ICS Schneider
Weiterführend: Cloud-Verbindung fällt aus – Edge-Alarme und lokale Datenpufferung planen
Weiterführend: Change-of-Value und Deadband richtig wählen
Fazit
Ein zuverlässiger Edge-Pufferspeicher wird nicht nach der nominellen Speicherkapazität eines Gateways ausgewählt, sondern aus der tatsächlichen Datenkette heraus dimensioniert.
Datenpunkte × Speicherfrequenz × reale Datensatzgröße × Offline-Dauer ergeben den Ausgangspunkt der Berechnung. Hinzu kommen Speicher- und Datenbank-Overhead sowie eine sinnvoll festgelegte Reserve.
Ebenso wichtig ist die Zeit nach dem Ausfall. Die Verbindung zum übergeordneten System muss genügend zusätzliche Übertragungskapazität besitzen, damit der gespeicherte Rückstand neben dem laufenden Live-Datenstrom wieder abgebaut werden kann.
Für eine technisch belastbare Store-and-Forward-Lösung gehören deshalb Speichergröße, persistente Speicherung, Original-Zeitstempel, Qualitätsstatus, Queue-Management, Wiederübertragung und Betriebsüberwachung zusammen. Wird nur die Anzahl der verfügbaren Gigabyte betrachtet, bleibt ein wesentlicher Teil der Systemauslegung unberücksichtigt.
Am zuverlässigsten ist eine Dimensionierung auf Basis echter Testdaten. Wer eine repräsentative Datenmenge lokal aufzeichnet, den tatsächlichen Speicherzuwachs misst und anschließend einen vollständigen Offline-/Online-Zyklus testet, erhält eine deutlich belastbarere Grundlage als mit einer rein theoretischen Schätzung.
FAQ zum Edge-Pufferspeicher
Wie berechnet man die Größe eines Edge-Pufferspeichers?
Als Grundlage kann die Anzahl der Datenpunkte mit der Speicherfrequenz und der effektiven Datensatzgröße multipliziert werden. Daraus ergibt sich die Speicherdatenrate. Diese wird mit der gewünschten Offline-Dauer multipliziert und anschließend um Datenbank-/Dateisystem-Overhead und eine Planungsreserve ergänzt.
Wie groß ist ein einzelner IIoT-Messwert?
Das lässt sich nicht pauschal beantworten. Der reine numerische Wert kann nur wenige Byte benötigen, der gespeicherte Datensatz enthält jedoch häufig zusätzlich Messstellenkennung, Zeitstempel, Qualitätsstatus und weitere Metadaten. JSON, Datenbanken und andere Speicherformate erzeugen zusätzlichen Overhead.
Reicht die Größe eines Float-Wertes für die Speicherberechnung?
Nein. Für eine realistische Dimensionierung sollte die tatsächlich persistierte Datensatzgröße verwendet werden.
Sollte ich die durchschnittliche oder maximale Datenrate verwenden?
Für unkritische Abschätzungen kann ein realistischer Durchschnitt hilfreich sein. Muss Datenverlust zuverlässig vermieden werden, sollte zusätzlich geprüft werden, welche Datenrate in dynamischen Betriebszuständen oder bei Ereignissen auftreten kann.
Welche Offline-Dauer sollte ein Edge-Gateway überbrücken können?
Das hängt von Betriebsmodell, Netzwerk, Standort und Reaktionszeit ab. Entscheidend ist die längste Kommunikationsunterbrechung, die das System laut Anlagenkonzept ohne Datenverlust beherrschen soll.
Warum benötige ich zusätzlich Speicherreserve?
Datenrate und Datenmodell können sich verändern. Außerdem benötigen Datenbanken, Journale und Dateisysteme zusätzlichen Speicher. Eine Reserve verhindert, dass kleine Abweichungen sofort zum Erreichen der Kapazitätsgrenze führen.
Ist ein RAM-Puffer für Store-and-Forward ausreichend?
Für sehr kurze Kommunikationsunterbrechungen kann RAM sinnvoll sein. Für eine ausfallsichere Pufferung über längere Zeit sollten die noch nicht übertragenen Daten jedoch persistent gespeichert werden, damit sie einen Neustart oder Versorgungsausfall überstehen können.
Was ist Store-and-Forward?
Store-and-Forward bedeutet, dass Daten zunächst lokal gespeichert werden, wenn das Zielsystem nicht erreichbar ist. Nach Wiederherstellung der Verbindung werden die gespeicherten Datensätze nachträglich übertragen.
Warum muss der Original-Zeitstempel gespeichert werden?
Damit ein später übertragener Datensatz weiterhin dem tatsächlichen Messzeitpunkt zugeordnet werden kann. Der Zeitpunkt der späteren Cloud-Übertragung darf den ursprünglichen Ereigniszeitpunkt nicht ersetzen.
Was passiert, wenn die Verbindung nach einem Ausfall zu langsam ist?
Wenn die verfügbare Übertragungsrate kaum größer als die laufende Live-Datenrate ist, wird der Rückstand nur sehr langsam abgebaut. Ist sie gleich groß oder kleiner, kann der Puffer trotz funktionierender Verbindung weiter gefüllt bleiben.
Kann Change-of-Value den benötigten Speicher reduzieren?
Ja. Bei langsam veränderlichen Messgrößen können Deadband- oder Change-of-Value-Strategien die Anzahl gespeicherter Datenpunkte deutlich reduzieren. Für die Dimensionierung sollte aber berücksichtigt werden, dass bei dynamischen Prozesszuständen wesentlich mehr Änderungen auftreten können.
Sollte der Edge-Puffer den gesamten freien Datenträger verwenden dürfen?
In der Regel nicht. Das Betriebssystem, Anwendungen, Logs, Datenbanken und Updates benötigen eigenen freien Speicher. Für den Datenpuffer sollten klare Grenzen und Warnschwellen definiert werden.
Was sollte bei vollem Puffer passieren?
Das Verhalten muss projektspezifisch festgelegt werden. Je nach Bedeutung der Daten kann beispielsweise alarmiert, die älteste Information verworfen oder eine andere definierte Betriebsstrategie ausgelöst werden. Ein unkontrolliert volllaufendes Dateisystem sollte vermieden werden.
Wie prüft man eine Store-and-Forward-Lösung praktisch?
Die Verbindung zum Zielsystem sollte kontrolliert unterbrochen werden. Anschließend wird geprüft, ob Daten lokal weiter erfasst werden, wie der Speicher wächst, ob ein Neustart überstanden wird und ob nach Wiederherstellung der Verbindung alle Datensätze mit den ursprünglichen Zeitstempeln korrekt nachgeliefert werden.