Cloud-Verbindung fällt aus: Edge-Alarme und lokale Datenpufferung ausfallsicher planen

→ Produktkategorie: IIoT Lösungen

 

Die Drucküberwachung einer Anlage funktioniert über Monate problemlos. Messwerte werden automatisch in die Cloud übertragen, Grenzwertverletzungen erscheinen im Dashboard und Wartungspersonal erhält Benachrichtigungen. Dann fällt die Internetverbindung aus.

Die Sensoren messen weiter – aber in der Cloud kommen keine neuen Daten mehr an.

Jetzt entscheidet die Systemarchitektur darüber, ob lediglich das Online-Dashboard vorübergehend nicht verfügbar ist oder ob gleichzeitig Alarme und Messdaten verloren gehen.

Eine robuste IIoT-Lösung sollte deshalb so aufgebaut sein, dass wesentliche Funktionen nicht erst in der Cloud entstehen. Messwerte sollten lokal erfasst und mit Zeitstempeln versehen werden, relevante Grenzwertlogik muss bei Bedarf am Edge beziehungsweise in der lokalen Steuerung weiterarbeiten und nicht übertragene Daten müssen zwischengespeichert werden.

Nach Wiederherstellung der Verbindung können die gepufferten Daten anschließend kontrolliert an das übergeordnete System übertragen werden.

Lösungen zur industriellen Digitalisierung finden Sie unter IIoT Lösungen. Anwendungen speziell für die digitale Drucküberwachung sind unter IIoT Drucküberwachung zusammengefasst.

Was passiert bei einem Cloud-Ausfall?

Ein IIoT-System besteht normalerweise aus mehreren voneinander abhängigen Kommunikationswegen.

Beispielsweise:

Sensor → Feldbus beziehungsweise Funk → Edge-Gateway → Netzwerk → Internet → Cloud → Dashboard beziehungsweise Benachrichtigung

Fällt nur die Verbindung zwischen Edge und Cloud aus, bedeutet dies nicht automatisch, dass auch die Sensoren oder der lokale Prozess ausgefallen sind.

Die Anlage kann weiterhin Messwerte erzeugen.

Problematisch wird es erst, wenn die Systemarchitektur davon ausgeht, dass jeder Messwert unmittelbar an die Cloud übertragen werden muss.

Ohne lokalen Speicher entstehen dann während einer längeren Unterbrechung echte Datenlücken.

Noch kritischer wird es, wenn auch die Grenzwertauswertung ausschließlich in der Cloud erfolgt. Eine lokale Drucküberschreitung kann dann zwar vom Sensor gemessen werden, aber die vorgesehene Alarmmeldung erreicht während der Kommunikationsstörung möglicherweise niemanden.

IIoT-System in Ebenen betrachten

Eine robuste Architektur sollte klar festlegen, welche Aufgabe auf welcher Ebene ausgeführt wird.

Ebene	Typische Aufgabe	Verhalten bei Cloud-Ausfall
Sensor / Feldgerät	Messwert erfassen	Messung sollte weiterlaufen
SPS / Edge-Gateway	Daten sammeln, skalieren, Zeitstempel, lokale Logik und Pufferung	Lokaler Betrieb sollte weiter möglich sein
Lokales HMI / SCADA	Anzeige und Bedienung vor Ort	Sollte bei geeigneter Architektur verfügbar bleiben
Cloud	Fernzugriff, Dashboards, Reporting, übergeordnete Analysen	Vorübergehend nicht verfügbar

Diese Trennung verhindert, dass eine reine Kommunikationsstörung unnötig zu einem Funktionsverlust der kompletten Mess- und Überwachungskette führt.

Warum wichtige Alarme lokal entstehen sollten

Ein typischer Fehler bei neuen IIoT-Projekten besteht darin, jeden Grenzwert ausschließlich in einem Cloud-Dashboard zu konfigurieren.

Im Normalbetrieb funktioniert das komfortabel:

1. Sensor misst.
2. Messwert wird übertragen.
3. Cloud vergleicht den Wert mit dem Grenzwert.
4. Cloud erzeugt eine Meldung.

Bei unterbrochener Internetverbindung funktioniert Schritt 2 jedoch nicht mehr.

Für betriebsrelevante Grenzwerte kann deshalb eine zusätzliche lokale Auswertung sinnvoll sein.

Beispielsweise:

• Druck größer 9 bar → lokaler Alarm,
• Tankfüllstand kleiner 10 % → lokale Warnung,
• Temperatur über 80 °C → lokales Relais beziehungsweise SPS-Alarm,
• Messwertänderung ungewöhnlich schnell → lokale Rate-of-Change-Überwachung.

Die Cloud kann dieselben Ereignisse zusätzlich anzeigen und weiterleiten.

Sie sollte jedoch nicht zwingend der einzige Ort sein, an dem ein für den laufenden Betrieb wichtiger Zustand erkannt wird.

Cloud-Alarm und Sicherheitsfunktion unterscheiden

Besonders wichtig ist die Unterscheidung zwischen einer betrieblichen Alarmierung und einer sicherheitsgerichteten Schutzfunktion.

Ein IIoT-Dashboard kann hervorragend für Fernüberwachung, Wartungsinformation und Zustandsmeldungen geeignet sein.

Eine sicherheitskritische Abschaltung sollte jedoch nicht allein davon abhängen, dass eine Internetverbindung und ein externer Cloud-Dienst erreichbar sind.

Wenn eine Maschine oder Anlage bei einem gefährlichen Zustand automatisch in einen sicheren Zustand überführt werden muss, muss die dafür vorgesehene Schutzfunktion entsprechend der Risikobeurteilung lokal und mit den dafür erforderlichen Komponenten umgesetzt werden.

Das Edge-System kann solche Zustände zusätzlich erfassen und dokumentieren, ist aber nicht automatisch Bestandteil einer sicherheitsgerichteten Steuerung.

Store-and-Forward: Messwerte lokal puffern

Für die Vermeidung von Datenlücken ist ein lokaler Datenpuffer eine der wichtigsten Funktionen.

Das Prinzip wird häufig als Store-and-Forward bezeichnet:

1. Messwert wird am Edge empfangen.
2. Zeitstempel wird vergeben.
3. Datensatz wird lokal gespeichert.
4. Übertragung zur Cloud wird versucht.
5. Ist die Verbindung nicht verfügbar, bleibt der Datensatz im lokalen Speicher.
6. Nach Wiederverbindung wird er nachträglich übertragen.

Dadurch muss der Sensor nicht wissen, ob die Cloud gerade erreichbar ist.

Die lokale Edge-Ebene übernimmt die Entkopplung zwischen kontinuierlicher Datenerfassung und möglicherweise unterbrochener Fernkommunikation.

Entscheidend ist allerdings, dass der Puffer ausreichend groß dimensioniert wird.

Ringspeicher richtig dimensionieren

Lokaler Speicher ist nicht unbegrenzt verfügbar.

Deshalb muss vorab festgelegt werden, wie lange das System einen Kommunikationsausfall überbrücken können soll.

Die benötigte Speicherkapazität hängt insbesondere ab von:

• Anzahl der Messstellen,
• Abtastrate,
• gespeicherten Variablen,
• Größe eines Datensatzes und
• maximal angenommener Ausfallzeit.

Vereinfacht gilt:

Speicherbedarf = Datensätze pro Sekunde × Datensatzgröße × gewünschte Pufferzeit

Zusätzlich sollte eine Reserve vorgesehen werden.

Ein Ringspeicher kann so ausgelegt werden, dass bei vollständiger Belegung die ältesten Daten überschrieben werden.

Das verhindert zwar einen vollständigen Speicherüberlauf, bedeutet aber gleichzeitig, dass bei einem zu langen Ausfall historische Werte verloren gehen.

Deshalb sollte ein definierter Füllstand des Puffers selbst überwacht werden.

Beispielsweise:

• 50 % Speicherbelegung → Information,
• 80 % → Warnung,
• 95 % → kritischer lokaler Alarm.

Die konkreten Werte müssen an die jeweilige Anwendung angepasst werden.

Zeitstempel bereits am Edge vergeben

Ein Messwert sollte möglichst mit dem Zeitpunkt gespeichert werden, zu dem er tatsächlich erfasst wurde.

Das wird besonders wichtig, wenn Daten erst mehrere Stunden später in der Cloud eintreffen.

Würde erst der Cloud-Server den Zeitstempel vergeben, könnten nach einer Wiederverbindung Tausende ältere Werte scheinbar zum gleichen aktuellen Zeitpunkt erscheinen.

Eine robuste Datensatzstruktur enthält deshalb beispielsweise:

• Geräte-ID,
• Messwert,
• Einheit,
• Erfassungszeitpunkt,
• Qualitäts- beziehungsweise Statusinformation und
• gegebenenfalls eine fortlaufende Sequenznummer.

Auch die Uhrzeit des Edge-Gateways muss überwacht werden.

Nach einem Neustart ohne gültige Zeitsynchronisation dürfen historische Messwerte nicht unbemerkt mit falschen Zeitstempeln gespeichert werden.

Was MQTT QoS bei Verbindungsabbrüchen leistet

MQTT bietet verschiedene Quality-of-Service-Stufen für die Nachrichtenübertragung.

Vereinfacht:

QoS	Grundprinzip	Zu beachten
QoS 0	At most once	Nachricht kann verloren gehen
QoS 1	At least once	Zustellung wird bestätigt, Duplikate sind möglich
QoS 2	Exactly once auf Protokollebene	Höherer Kommunikationsaufwand

Für viele industrielle Telemetrie- und Alarmanwendungen ist QoS 1 eine sinnvolle Option.

Wichtig ist jedoch:

MQTT QoS ersetzt keinen ausreichend dimensionierten lokalen Messwertspeicher.

Wenn ein Edge-Gerät während eines mehrstündigen kompletten Netzausfalls neue Prozesswerte erzeugt, müssen diese Werte irgendwo lokal gespeichert werden, wenn sie später vollständig nachgeliefert werden sollen.

MQTT-Sitzungsmechanismen und Store-and-Forward erfüllen deshalb unterschiedliche Aufgaben und sollten nicht miteinander verwechselt werden.

Duplikate und Reihenfolge nach Wiederverbindung

Nach einer unterbrochenen Verbindung kann die Wiederübertragung zusätzliche Herausforderungen erzeugen.

Bei einer Übertragung mit „at least once“ können beispielsweise Nachrichten mehrfach eintreffen.

Das Zielsystem sollte solche Datensätze erkennen können.

Hilfreich sind beispielsweise:

• eindeutige Datensatz-ID,
• Geräte-ID,
• Zeitstempel und
• fortlaufende Sequenznummer.

Damit kann das Zielsystem prüfen, ob ein Wert bereits verarbeitet wurde.

Auch die Reihenfolge ist wichtig.

Nach einer achtstündigen Unterbrechung sollte nicht einfach zuerst der aktuellste Wert und anschließend der komplette alte Datenpuffer ohne Kennzeichnung übertragen werden.

Die Auswertung muss eindeutig unterscheiden können zwischen:

• aktuellen Live-Daten und
• nachgelieferten historischen Daten.

Echte Datenlücken eindeutig erkennen

Auch ein gut ausgelegter Puffer kann irgendwann vollständig gefüllt sein.

Wenn anschließend alte Messwerte überschrieben werden, entsteht eine echte Datenlücke.

Diese sollte nicht verborgen werden.

Das System sollte beispielsweise dokumentieren:

• Zeitpunkt des Kommunikationsausfalls,
• Beginn der Datenpufferung,
• Pufferüberlauf,
• Anzahl verlorener Datensätze und
• Zeitpunkt der Wiederverbindung.

Ein fehlender Datenabschnitt darf später nicht wie ein normaler Zeitraum ohne Prozessänderung aussehen.

Für Qualitäts- oder Nachweisdaten ist eine eindeutige Kennzeichnung solcher Lücken besonders wichtig.

Verbindungsstatus mit Watchdog überwachen

Eine Anlage sollte erkennen können, dass ihre übergeordnete Verbindung ausgefallen ist.

Dafür kann ein Kommunikations-Watchdog beziehungsweise Heartbeat verwendet werden.

Das Prinzip ist einfach:

Innerhalb eines definierten Zeitraumes wird eine erfolgreiche Kommunikation erwartet.

Bleibt sie aus, setzt das Edge-System einen Status wie:

Cloud offline / Verbindung gestört.

Dieser Zustand kann lokal angezeigt und protokolliert werden.

Wichtig ist die Wahl einer geeigneten Zeitüberwachung.

Ein einzelnes verlorenes Datenpaket sollte bei einer grundsätzlich unkritischen Anwendung nicht sofort einen Kommunikationsalarm auslösen. Umgekehrt darf eine tatsächlich unterbrochene Verbindung nicht stundenlang unbemerkt bleiben.

Lokales HMI und SCADA weiter betreiben

Eine cloudbasierte Visualisierung bietet Vorteile beim standortübergreifenden Zugriff.

Für Anlagenpersonal ist jedoch häufig zusätzlich eine lokale Anzeige sinnvoll.

Während eines Internetausfalls können beispielsweise weiterhin verfügbar bleiben:

• lokales HMI,
• SCADA-System im Werksnetz,
• SPS-Anzeige,
• Edge-Weboberfläche oder
• physische Signalleuchte beziehungsweise Relaismeldung.

Dadurch kann das Bedienpersonal weiterhin beurteilen, ob der Prozess normal arbeitet.

Ein schwarzes Cloud-Dashboard sollte nicht dazu führen, dass lokal überhaupt keine Information über Druck, Temperatur oder Füllstand mehr vorhanden ist.

Internet-, Cloud- und Stromausfall unterscheiden

Bei einer Ausfallbetrachtung sollten mindestens drei unterschiedliche Situationen getestet werden:

Ausfall	Sensor / Edge	Cloud
Internetverbindung unterbrochen	lokal verfügbar	nicht erreichbar
Cloud-Dienst nicht verfügbar	lokal verfügbar	Dienst gestört
Edge-Stromversorgung fällt aus	abhängig von Versorgung / USV	keine neuen Edge-Daten

Ein Datenpuffer hilft bei einem Internet- oder Cloud-Ausfall nur dann, wenn das Edge-Gerät selbst weiterhin mit Energie versorgt wird.

Für besonders wichtige Daten kann deshalb auch die Stromversorgung des Gateways, Netzwerk-Switches und gegebenenfalls der lokalen Steuerung in das Verfügbarkeitskonzept einbezogen werden.

Wiederverbindung kontrolliert behandeln

Nach Rückkehr der Netzwerkverbindung entstehen gleichzeitig zwei Aufgaben:

• aktuelle Messwerte weiter übertragen und
• historisch gepufferte Daten nachliefern.

Werden mehrere Stunden Daten ungefiltert mit maximaler Geschwindigkeit übertragen, kann dies Netzwerk, Broker oder Cloud-Schnittstelle unnötig belasten.

Eine kontrollierte Wiederübertragung kann deshalb sinnvoll sein.

Dabei sollten unter anderem festgelegt werden:

• Priorität aktueller Alarme,
• Reihenfolge der historischen Daten,
• maximale Nachlieferungsrate,
• Bestätigung erfolgreich übertragener Datensätze und
• Löschung aus dem lokalen Speicher erst nach erfolgreicher Verarbeitung.

Besonders Alarmereignisse sollten nicht minutenlang hinter großen Mengen historischer Trenddaten warten müssen.

Kommunikationsausfall gezielt testen

Ob eine IIoT-Lösung offline funktioniert, sollte nicht erst beim ersten realen Netzausfall festgestellt werden.

Ein definierter Ausfalltest kann beispielsweise folgendermaßen durchgeführt werden:

1. Normalbetrieb herstellen.
2. Messwerte und Cloud-Verbindung kontrollieren.
3. Internet- beziehungsweise Cloud-Verbindung gezielt unterbrechen.
4. Prozessmesswerte verändern.
5. Lokale Grenzwerte auslösen.
6. Lokale Alarmierung kontrollieren.
7. Pufferfüllung beobachten.
8. Mehrere Messwerte mit bekanntem Zeitverlauf erzeugen.
9. Verbindung wiederherstellen.
10. Nachlieferung der historischen Werte überprüfen.
11. Zeitstempel und Reihenfolge kontrollieren.
12. Auf doppelte Datensätze prüfen.
13. Cloud- und lokales Ereignisprotokoll vergleichen.

Ein solcher Test zeigt wesentlich mehr über die tatsächliche Systemrobustheit als die reine Kontrolle, ob das Dashboard im Normalbetrieb Werte anzeigt.

Typische Planungsfehler

Beobachtung	Mögliche Ursache	Sinnvolle Maßnahme
Während Internetausfall entstehen Datenlücken	Keine lokale Pufferung	Store-and-Forward am Edge vorsehen
Lokaler Grenzwert wird nicht gemeldet	Alarm ausschließlich in der Cloud konfiguriert	Betriebsrelevante Alarmfunktion lokal ergänzen
Historische Werte erscheinen mit falscher Uhrzeit	Zeitstempel erst beim Cloud-Empfang	Zeitstempel bei Erfassung vergeben
Nach Wiederverbindung erscheinen Werte doppelt	Wiederholung ohne Duplikaterkennung	Eindeutige IDs beziehungsweise Sequenznummern verwenden
Gateway überschreibt Daten nach längerem Ausfall	Puffer zu klein dimensioniert	Pufferzeit berechnen und Speicherstatus überwachen
Cloud ist offline, vor Ort merkt es niemand	Kein Kommunikations-Watchdog	Lokalen Verbindungsstatus überwachen
Nach Verbindungsrückkehr wird Netzwerk stark belastet	Unbegrenzte Nachlieferung des Puffers	Store-and-Forward kontrolliert priorisieren
Bei Stromausfall sind trotz Puffer Daten verloren	Edge-Gateway selbst stromlos	Versorgung und gegebenenfalls USV-Konzept prüfen

Empfohlenes Vorgehen bei der Auslegung

1. Messstellen definieren: Festlegen, welche Sensorwerte erfasst werden.
2. Abtastrate bestimmen: Prozessdynamik und benötigte Auflösung berücksichtigen.
3. Alarmklassen festlegen: Unterscheiden zwischen Information, betrieblichem Alarm und sicherheitsrelevanter Funktion.
4. Lokale Logik definieren: Festlegen, welche Grenzwerte auch ohne Cloud ausgewertet werden müssen.
5. Ausfallzeit festlegen: Bestimmen, wie lange ohne Netzwerk keine Messdaten verloren gehen dürfen.
6. Puffer dimensionieren: Anzahl der Messstellen, Datenrate und Reserve berücksichtigen.
7. Zeitkonzept festlegen: Zeitstempel bereits bei der Messwerterfassung vergeben.
8. Daten-ID definieren: Geräte-ID, Zeitstempel und Sequenznummer für eindeutige Zuordnung verwenden.
9. Kommunikationsstatus überwachen: Watchdog beziehungsweise Heartbeat einrichten.
10. Lokale Visualisierung festlegen: HMI, SCADA oder Edge-Oberfläche bei Bedarf unabhängig von der Cloud betreiben.
11. Store-and-Forward definieren: Verhalten bei Unterbrechung und Wiederverbindung festlegen.
12. Überlauf behandeln: Verhalten bei vollständig belegtem Speicher eindeutig definieren.
13. Wiederverbindung testen: Reihenfolge, Duplikate und Nachlieferung prüfen.
14. Ausfallszenario dokumentieren: Internet-, Cloud-, Gateway- und Stromausfall getrennt betrachten.

Praxisbeispiel einer IIoT-Drucküberwachung

In einem Industriebetrieb werden mehrere Druckluftleitungen mit digitalen Drucksensoren überwacht.

Die Werte werden von einem Edge-Gateway eingelesen und anschließend per MQTT an eine zentrale Cloud-Plattform übertragen.

Das Dashboard dient zur Energieüberwachung und meldet ungewöhnliche Druckabfälle.

Die normale Abtastrate beträgt zehn Sekunden.

An einem Freitagabend fällt die Internetverbindung des Werkes aus.

Die Sensoren und das Edge-System laufen weiter.

Das Gateway erkennt die fehlende Cloud-Verbindung über den Kommunikations-Watchdog und setzt lokal die Meldung „Cloud offline“.

Gleichzeitig werden alle neuen Druckwerte mit ihrem ursprünglichen Zeitstempel in einem lokalen Puffer gespeichert.

Während der Nacht entsteht an einer Druckluftleitung ein ungewöhnlich starker Druckabfall.

Da der entsprechende Grenzwert zusätzlich lokal im Edge beziehungsweise in der Steuerung ausgewertet wird, erscheint die Warnung weiterhin auf dem lokalen HMI.

Die Cloud kann zu diesem Zeitpunkt jedoch keine externe Benachrichtigung versenden.

Am Samstagmorgen wird die Internetverbindung wiederhergestellt.

Aktuelle Prozesswerte werden sofort wieder übertragen. Gleichzeitig beginnt das Gateway kontrolliert mit der Nachlieferung der historischen Daten.

Die Cloud erhält jeden Messwert mit seinem ursprünglichen Erfassungszeitpunkt.

Im späteren Trend ist deshalb auch der komplette Verlauf während des Netzausfalls sichtbar.

Das Ereignis „Cloud offline“ ist ebenfalls dokumentiert.

Damit kann eindeutig unterschieden werden zwischen:

• einer realen Prozessabweichung,
• einem Kommunikationsausfall und
• einer tatsächlichen Datenlücke.

Das Beispiel zeigt: Die Cloud darf ein wichtiger Bestandteil des Überwachungssystems sein, sollte aber nicht automatisch dessen einziger funktionsfähiger Teil sein.

Welche Produkte und Lösungen eignen sich?

ICS IIoT-Lösungen – Edge, MQTT und lokale Datenverarbeitung

Unter IIoT Lösungen kombiniert ICS Schneider Messtechnik Feldgeräte, Sensorik und Steuerungen mit Edge-Gateways sowie übergeordneten IT- und Cloud-Systemen.

Je nach Anwendung können Messwerte beispielsweise über Modbus RTU, HART, IO-Link, OPC UA oder Ethernet erfasst und anschließend über MQTT beziehungsweise HTTPS weitergegeben werden.

Für eine ausfallsichere Architektur kann die Edge-Ebene unter anderem folgende Aufgaben übernehmen:

• Messwerterfassung,
• Skalierung,
• Zeitstempel,
• lokale Grenzwertauswertung,
• Datenpufferung und
• Store-and-Forward nach Wiederverbindung.

Entscheidend ist dabei, die benötigten Offline-Funktionen bereits bei der Projektierung festzulegen.

WIKA PEW-1000 – drahtlose IIoT-Drucküberwachung

Der WIKA PEW-1000 ist ein funkbasierter Drucksensor für industrielle Gas- und Flüssigkeitsanwendungen.

Er eignet sich insbesondere für abgelegene Messstellen und Retrofit-Anwendungen, bei denen Messwerte drahtlos in eine IIoT-Infrastruktur eingebunden werden sollen.

Der Sensor stellt dabei die Feld- und Funkebene der Messkette dar. Lokale Alarmierung, übergeordnete Datenpufferung und Store-and-Forward müssen entsprechend der gewählten Gesamtarchitektur auf Gateway-, Steuerungs- beziehungsweise Edge-Ebene umgesetzt werden.

WIKA NETRIS®1 – bestehende Standardsensoren drahtlos anbinden

Die WIKA NETRIS®1 ermöglicht die drahtlose Einbindung von Sensoren mit Standardsignalen in eine IIoT-Anwendung.

Dadurch können beispielsweise vorhandene 4–20-mA- oder 0–10-V-Sensoren sowie geeignete Widerstandsthermometer in eine Funkarchitektur integriert werden.

Die Funkeinheit ist damit besonders interessant für die Nachrüstung bestehender Messstellen.

Auch hier sollte die Offline-Strategie des Gesamtsystems unabhängig davon geplant werden, wie der einzelne Messwert von der Feldstelle zum übergeordneten System übertragen wird.

WIKA NETRIS®3 – IIoT-Funkübertragung für Ex-Anwendungen

Für geeignete WIKA-Messgeräte in explosionsgefährdeten Bereichen steht die WIKA NETRIS®3 zur Verfügung.

Die Funkeinheit überträgt Messwerte über LoRaWAN® und ermöglicht damit auch an räumlich entfernten Messstellen eine Einbindung in IIoT-Strukturen.

Für das Ausfallkonzept muss jedoch auch hier betrachtet werden, welche Daten bei Unterbrechung des Funk-, Gateway- oder Cloud-Pfades lokal verfügbar bleiben sollen.

IDCT531i – Drucksensor mit RS485 / Modbus RTU

Der IDCT531i stellt Druckwerte digital über RS485 mit Modbus RTU bereit.

Damit kann der Sensor beispielsweise direkt an eine SPS oder ein Edge-Gateway angebunden werden.

Eine kabelgebundene Feldkommunikation kann besonders interessant sein, wenn die lokale Prozessüberwachung unabhängig von Internet oder Cloud verfügbar bleiben soll.

Weitere Geräte und Lösungen für diesen Bereich finden Sie unter IIoT Drucküberwachung.

ICS Schneider Messtechnik unterstützt bei der Auswahl von Sensorik, Kommunikationsschnittstellen und Edge-Gateways sowie bei Register-Mapping, MQTT-Topic-Struktur, lokaler Alarmierung, Datenpufferung und Anbindung an SCADA- beziehungsweise Cloud-Systeme.

Fazit

Eine IIoT-Lösung ist erst dann wirklich robust, wenn sie auch bei unterbrochener Cloud-Verbindung ein definiertes Verhalten besitzt.

Die wichtigste Grundregel lautet:

Messung, betriebsrelevante lokale Alarmierung und notwendige Datenhaltung dürfen nicht unnötig von einer permanent verfügbaren Internetverbindung abhängig sein.

Ein Edge-Gateway kann dabei die Verbindung zwischen Feld- und Cloud-Ebene entkoppeln.

Es erfasst Messwerte lokal, vergibt Zeitstempel, führt bei Bedarf Grenzwertlogik aus und speichert noch nicht übertragene Daten zwischen.

Nach Wiederverbindung werden die Datensätze per Store-and-Forward nachgeliefert.

Dabei müssen Duplikate, Reihenfolge und ursprünglicher Erfassungszeitpunkt berücksichtigt werden.

MQTT QoS verbessert die Zuverlässigkeit der Nachrichtenübertragung, ersetzt aber keinen lokal dimensionierten Messwertpuffer für längere Offline-Zeiträume.

Auch der Puffer selbst muss überwacht werden. Ist er voll, muss eindeutig definiert sein, ob alte Daten überschrieben, neue Daten verworfen oder ein lokaler Alarm ausgelöst wird.

Besonders wichtig ist schließlich der praktische Ausfalltest.

Erst eine gezielte Unterbrechung der Kommunikation zeigt, ob lokale Alarme tatsächlich funktionieren, Messwerte erhalten bleiben und die Cloud nach Wiederverbindung einen vollständigen und zeitlich korrekten Verlauf erhält.

Häufige Fragen zu IIoT bei Cloud-Ausfall

Was passiert mit IIoT-Messwerten, wenn das Internet ausfällt?

Das hängt von der Systemarchitektur ab. Ohne lokalen Speicher können Werte verloren gehen. Mit einem ausreichend dimensionierten Edge-Puffer können sie lokal gespeichert und nach Wiederherstellung der Verbindung nachträglich übertragen werden.

Was bedeutet Store-and-Forward?

Store-and-Forward bedeutet, dass Messwerte zunächst lokal gespeichert werden, wenn das Zielsystem nicht erreichbar ist. Nach Wiederherstellung der Verbindung werden die zwischengespeicherten Datensätze automatisch nachgeliefert.

Sollten Alarme in der Cloud oder am Edge erzeugt werden?

Für reine Ferninformationen kann eine Cloud-Auswertung ausreichen. Betriebsrelevante Alarme, die auch bei einer Kommunikationsstörung verfügbar sein müssen, sollten zusätzlich lokal am Edge beziehungsweise in der Steuerung ausgewertet werden.

Ist MQTT QoS 1 ausreichend gegen Datenverlust?

QoS 1 verbessert die Zustellsicherheit einzelner MQTT-Nachrichten und arbeitet nach dem Prinzip „at least once“. Für während einer längeren Offline-Phase neu entstehende Prozessdaten wird jedoch weiterhin ein geeigneter lokaler Speicher benötigt.

Warum können bei MQTT QoS 1 doppelte Werte auftreten?

Bei „at least once“ kann eine Nachricht erneut übertragen werden, wenn die erfolgreiche Zustellung nicht eindeutig bestätigt wurde. Anwendungen sollten deshalb in der Lage sein, bereits verarbeitete Datensätze zuverlässig zu erkennen.

Wie groß sollte ein Edge-Datenpuffer sein?

Das hängt von Anzahl der Messstellen, Abtastrate, Datensatzgröße und maximal gewünschter Offline-Zeit ab. Zusätzlich sollte eine ausreichende Speicherreserve vorgesehen und die Belegung des Puffers überwacht werden.

Warum sollten Zeitstempel lokal vergeben werden?

Damit nachträglich übertragene Werte weiterhin ihrem tatsächlichen Erfassungszeitpunkt zugeordnet werden können. Ein Zeitstempel erst beim Cloud-Empfang würde den historischen Verlauf verfälschen.

Was passiert, wenn der lokale Ringspeicher voll ist?

Das Verhalten muss während der Projektierung festgelegt werden. Je nach Konzept können beispielsweise die ältesten Daten überschrieben werden. Ein drohender beziehungsweise eingetretener Pufferüberlauf sollte eindeutig protokolliert und gemeldet werden.

Wie erkennt das System einen Cloud-Ausfall?

Typischerweise kann ein Kommunikations-Watchdog oder Heartbeat verwendet werden. Bleibt die erwartete Kommunikation über einen definierten Zeitraum aus, wird der Verbindungsstatus lokal als gestört erkannt.

Wie teste ich die Offline-Funktion eines IIoT-Systems?

Die Verbindung sollte kontrolliert unterbrochen werden, während definierte Messwerte und Alarme erzeugt werden. Anschließend werden lokale Alarmierung, Datenpuffer, Zeitstempel, Wiederverbindung, Nachlieferung, Reihenfolge und mögliche Duplikate überprüft.