Firmware-Updates für IIoT-Gateways planen: Wartungsfenster, Rollback und Messdatenausfall berücksichtigen

→ Produktkategorie: IIoT-Lösungen

Ein IIoT-Gateway überträgt seit Monaten zuverlässig Druck-, Temperatur- und Füllstanddaten an eine zentrale Plattform. Dann wird eine neue Firmware installiert, um Sicherheitslücken zu schließen und die Kommunikation zu verbessern. Nach dem Neustart ist das Gerät wieder erreichbar, die Verbindung zur Cloud steht und das Dashboard zeigt aktuelle Messwerte. Auf den ersten Blick ist das Update erfolgreich verlaufen.

Bei der späteren Auswertung zeigt sich jedoch eine Lücke in der Messdatenhistorie. Während des Neustarts wurden mehrere Minuten lang keine Werte erfasst. Andere Messdaten sind zwar angekommen, tragen aber den Zeitpunkt der nachträglichen Übertragung statt des ursprünglichen Erfassungszeitpunkts. Zusätzlich wurde bei einem Datenpunkt die bisherige Skalierung verändert. Die Verbindung funktioniert wieder, doch die historische Datenqualität ist beeinträchtigt.

Firmware-Updates für IIoT-Gateways sind deshalb nicht nur eine Aufgabe der IT-Sicherheit. Sie betreffen die gesamte industrielle Messdatenkette. Neben der Aktualisierung selbst müssen Wartungsfenster, lokale Datenpufferung, Zeitstempel, Konfiguration, Wiederherstellung und die erforderliche Alarmverfügbarkeit berücksichtigt werden.

Dieser Fachbeitrag zeigt, wie sich Firmware-Updates für industrielle Edge-Gateways kontrolliert vorbereiten, durchführen und nachweisen lassen. Im Mittelpunkt stehen die Vermeidung unerkannter Messdatenausfälle, ein belastbarer Rollback-Plan, die sichere Wiederaufnahme der Datenübertragung und eine klare Trennung zwischen Geräteverfügbarkeit und tatsächlicher Datenqualität.

Inhaltsverzeichnis

1. Update-Ziel und Anforderungen an den Messdatenbetrieb festlegen
2. Die vollständige IIoT-Datenkette berücksichtigen
3. Welche Funktionen ein Firmware-Update unterbrechen kann
4. Gateway-Inventar, Abhängigkeiten und Update-Risiken erfassen
5. Wartungsfenster und Wiederherstellungszeit realistisch planen
6. Firmware vor dem Rollout in einer Testumgebung prüfen
7. Konfiguration, Messdaten und Zugangsinformationen sichern
8. Firmware-Authentizität und Update-Übertragung absichern
9. Rollback und Wiederherstellung zuverlässig vorbereiten
10. Messdatenausfall, Übertragungsausfall und Datenlücke unterscheiden
11. Lokale Datenpufferung und Store-and-Forward auslegen
12. Rechenbeispiel: Speicherbedarf und Wiederanlauf berechnen
13. Zeitstempel und Uhrensynchronisation erhalten
14. Datenmodell, Einheiten und Skalierungen unverändert halten
15. MQTT, Übertragungsbestätigungen und Duplikate behandeln
16. Lokale Alarmierung und sicheren Anlagenbetrieb gewährleisten
17. Feldbus, Sensorverbindungen und Kommunikation nach dem Neustart prüfen
18. Firmware-Updates auf mehrere Gateways gestaffelt ausrollen
19. Einen kontrollierten Firmware-Update-Ablauf durchführen
20. Messdatenqualität und Betriebsbereitschaft nach dem Update nachweisen
21. Typische Update-Fehler systematisch diagnostizieren
22. Passende IIoT-Lösungen von ICS Schneider
23. Fazit: Firmware-Updates als kontrollierte Änderung der Messdatenkette behandeln
24. Häufige Fragen zu Firmware-Updates für IIoT-Gateways

1. Update-Ziel und Anforderungen an den Messdatenbetrieb festlegen

Ein Firmware-Update kann unterschiedliche Ziele verfolgen. Häufig sollen bekannte Sicherheitslücken geschlossen, Fehler behoben, Kommunikationsprotokolle verbessert oder zusätzliche Funktionen bereitgestellt werden. Bei einem IIoT-Gateway können solche Änderungen sowohl die IT-Verbindung als auch die Verarbeitung der industriellen Messdaten betreffen.

Vor dem Update muss deshalb zunächst feststehen, welche Funktion des Gateways betroffen ist. Ein Sicherheitsupdate für eine Kommunikationsbibliothek unterscheidet sich von einer Firmware-Version, die gleichzeitig den Modbus-Treiber, die Datenbankstruktur oder die MQTT-Nachrichten verändert.

Ebenso wichtig ist die betriebliche Bedeutung der Messdaten. Bei einer langsamen Füllstandüberwachung kann eine dokumentierte kurze Datenlücke möglicherweise toleriert werden. Bei einer zeitkritischen Prozessüberwachung, einer kontinuierlichen Qualitätsaufzeichnung oder einem System mit relevanten Alarmfunktionen können deutlich strengere Anforderungen gelten.

Für die Planung sollten die maximal zulässige Unterbrechung der Online-Verbindung, der erlaubte Verlust von Messwerten und die geforderte Wiederanlaufzeit getrennt festgelegt werden. Eine unterbrochene Cloud-Verbindung ist beispielsweise nicht automatisch mit einem Verlust der lokalen Messwerte gleichzusetzen.

Zwei betriebliche Kenngrößen sind dabei besonders hilfreich: Das Recovery Time Objective (RTO) beschreibt die angestrebte maximale Wiederherstellungszeit. Das Recovery Point Objective (RPO) beschreibt den höchstens tolerierbaren Datenverlust bezogen auf einen Wiederherstellungspunkt. Beide Werte sind anwendungsspezifisch zu definieren.

Ein gefordertes RPO von null bedeutet, dass durch das betrachtete Ereignis keine relevanten Messdaten verloren gehen dürfen. Dieses Ziel kann nur erreicht werden, wenn die Architektur auch während der Update-Unterbrechung eine lückenlose Erfassung oder eine spätere Wiederherstellung der Messwerte ermöglicht. Eine vorhandene Cloud-Verbindung allein genügt dafür nicht.

2. Die vollständige IIoT-Datenkette berücksichtigen

In einer industriellen IIoT-Anwendung befindet sich das Gateway zwischen der Feldebene und den übergeordneten IT- beziehungsweise OT-Systemen. Es liest Messwerte von Sensoren, Messumformern oder Steuerungen, verarbeitet diese und stellt sie für weitere Anwendungen bereit.

Ein typischer Aufbau kann folgendermaßen aussehen:

Sensor / Messumformer → Feldbus oder Analogeingang → Edge-Gateway → lokale Verarbeitung und Datenpuffer → MQTT / HTTPS / OPC UA → SCADA, Historian oder Cloud

Die tatsächliche Architektur kann davon abweichen. Einige Systeme erfassen die Messwerte bereits in einer SPS. Andere übernehmen die zeitliche Erfassung erst im Gateway. Wieder andere verwenden separate lokale Datenlogger oder eine industrielle Datenbank.

Für die Firmware-Planung ist entscheidend, welche Aufgaben tatsächlich auf dem zu aktualisierenden Gerät ausgeführt werden. Wenn das Gateway ausschließlich Daten weiterleitet, kann eine Unterbrechung andere Auswirkungen haben als bei einem Gerät, das die Sensoren selbst abfragt und gleichzeitig die lokale Alarmberechnung übernimmt.

Die auf der ICS-Website beschriebenen IIoT-Lösungen verbinden beispielsweise Messgeräte über RS-485/Modbus RTU, HART, IO-Link, OPC UA oder Ethernet mit übergeordneten Systemen. Am Edge können Skalierung, Zeitstempel, lokale Alarmierung und Datenpufferung erfolgen.

Damit ist das Gateway ein funktionaler Bestandteil der Messkette. Ein Firmware-Wechsel kann beeinflussen, wie Daten gelesen, verarbeitet, zwischengespeichert und übertragen werden. Die erfolgreiche Installation einer neuen Version beweist deshalb noch nicht, dass die komplette Messaufgabe unverändert erfüllt wird.

3. Welche Funktionen ein Firmware-Update unterbrechen kann

Je nach Gerätearchitektur kann ein Firmware-Update einzelne Anwendungen neu starten oder einen vollständigen Neustart des Gateways erfordern. Dabei können unterschiedliche Funktionen zeitweise nicht verfügbar sein.

Wichtig ist die Unterscheidung zwischen dem Gerät, das Messwerte ursprünglich erfasst, und dem Gerät, das sie überträgt. Bleibt die Sensorerfassung während eines Gateway-Neustarts aktiv, können Daten möglicherweise später übernommen werden. Wird die Erfassung selbst unterbrochen, entstehen ohne unabhängige Aufzeichnung möglicherweise tatsächlich fehlende Messwerte.

Mögliche Update-Auswirkungen auf die industrielle Messdatenkette

Betroffene Funktion	Mögliche Auswirkung	Notwendige Gegenmaßnahme
Feldbusabfrage	Sensorwerte werden während des Neustarts nicht abgefragt	Erfassungspause bewerten; gegebenenfalls unabhängige Historie oder vorgelagerte Pufferung vorsehen
Lokale Datenbank	Zwischengespeicherte Daten sind vorübergehend nicht verfügbar oder werden bei ungeeigneter Speicherung beschädigt	Persistente, wiederanlauffähige Pufferung und geeignete Datensicherung sicherstellen
MQTT- oder HTTPS-Verbindung	Messwerte erreichen den Broker oder Server zeitweise nicht	Store-and-Forward und kontrollierte Wiederübertragung vorsehen
Zeitdienst	Nach dem Neustart stimmt die Systemzeit vorübergehend nicht	Uhrensynchronisation prüfen und unsichere Zeitstempel kennzeichnen
Treiber oder Datenmodell	Adressen, Datentypen, Einheiten oder Skalierungen ändern sich	Konfiguration vergleichen und Referenzmesspunkte prüfen
Lokale Alarmfunktion	Grenzwertüberwachung kann während des Neustarts ausfallen	Unabhängige Schutzfunktion oder freigegebenen Ersatzbetrieb vorsehen
Kommunikationszertifikate	Verbindung nach dem Update wird nicht wieder aufgebaut	Zertifikate, Schlüssel, Gültigkeit und Verbindungsparameter vorab prüfen
Remote-Management	Gateway kann nach einem Fehler nicht mehr aus der Ferne erreicht werden	Lokalen Wiederherstellungszugang und definierten Rollback-Prozess bereitstellen

Die Tabelle zeigt, dass nicht jede Update-Unterbrechung zwangsläufig einen dauerhaften Datenverlust erzeugt. Entscheidend ist, welche Funktion ausfällt und ob eine andere Komponente die benötigte Aufgabe währenddessen weiterführt.

Besonders kritisch sind Systeme, bei denen dasselbe Gateway die Messwerte erfasst, puffert, verarbeitet und Alarme erzeugt. Fällt dieses Gerät vollständig aus, können mehrere Funktionen gleichzeitig betroffen sein.

4. Gateway-Inventar, Abhängigkeiten und Update-Risiken erfassen

Vor einem Firmware-Rollout muss bekannt sein, welche Geräte überhaupt betroffen sind. Dazu gehört eine eindeutige Inventarisierung mit Gerätekennung, Hersteller, Typ, Hardware-Revision, installierter Firmware und zugeordneten Anlagenbereichen.

Ebenso wichtig sind die verwendeten Schnittstellen. Ein Gateway kann beispielsweise mehrere Modbus-RTU-Messumformer abfragen, Daten aus einer SPS über OPC UA übernehmen und parallel über MQTT an eine Cloud-Plattform senden.

Eine Firmware-Änderung kann deshalb unterschiedliche Kommunikationspartner betreffen. Werden Protokollbibliotheken oder Treiber aktualisiert, müssen ihre Kompatibilität mit den angeschlossenen Geräten und Systemen geprüft werden.

Auch Abhängigkeiten zu Zertifikaten, VPN-Verbindungen, Zeitsynchronisation und zentralen Verwaltungsdiensten gehören zum Inventar. Ein Gateway kann technisch fehlerfrei gestartet sein und dennoch keine Messdaten übertragen, wenn eine benötigte Authentifizierung nach dem Update nicht mehr funktioniert.

Für jedes Gateway sollte außerdem dokumentiert werden, welche Messstellen es bedient und welche Prozesse von diesen Daten abhängen. Dadurch lassen sich Geräte mit geringer betrieblicher Bedeutung von Gateways mit hohen Anforderungen an Verfügbarkeit und Datenintegrität unterscheiden.

Die Priorisierung von Updates sollte sowohl das Sicherheitsrisiko als auch das Betriebsrisiko berücksichtigen. Ein Update zur Behebung einer schwerwiegenden Sicherheitslücke kann dringend sein. Dennoch muss ein geeignetes Verfahren gewählt werden, damit die Aktualisierung nicht unkontrolliert Prozessfunktionen beeinträchtigt.

Für industrielle OT-Systeme beschreibt NIST SP 800-82 Rev. 3 einen risikobasierten und dokumentierten Umgang mit Updates. Auch IEC TR 62443-2-3 behandelt das Patch-Management in industriellen Automatisierungs- und Steuerungssystemen. Die konkrete Umsetzung muss zur jeweiligen Anlage passen.

5. Wartungsfenster und Wiederherstellungszeit realistisch planen

Ein Wartungsfenster bezeichnet den Zeitraum, in dem eine geplante Änderung unter abgestimmten betrieblichen Bedingungen durchgeführt werden darf. Für ein IIoT-Gateway muss dieses Zeitfenster mehr umfassen als den eigentlichen Firmware-Installationsvorgang.

Zur Planung gehören die letzte Kontrolle der Ausgangskonfiguration, das gegebenenfalls erforderliche Sichern oder Leeren von Datenpuffern, die Installation, der Neustart, die Wiederherstellung von Kommunikationsverbindungen und die Prüfung der Messdatenübertragung.

Auch die Zeit für eine mögliche Rückkehr zur vorherigen Version muss berücksichtigt werden. Wird das gesamte Wartungsfenster bereits für die Installation verbraucht, bleibt im Fehlerfall keine ausreichende Zeit für Wiederherstellung und anschließende Prüfung.

Ein beispielhaftes Zeitbudget könnte 10 Minuten für Sicherung und Vorbereitung, 15 Minuten für das Update, 5 Minuten für den Neustart, 20 Minuten für die Funktionsprüfung und 30 Minuten als Wiederherstellungsreserve vorsehen. Daraus ergibt sich ein geplantes Wartungsfenster von 80 Minuten. Diese Zeiten sind reine Planungsannahmen und keine allgemeingültigen Herstellerwerte.

Die tatsächliche Dauer hängt unter anderem von Dateigröße, Übertragungsweg, Speichermedium, Geräteperformance, Anzahl der Schnittstellen und Art des Updates ab. Bei Geräten mit Mobilfunkanbindung muss zudem die Verbindungsqualität berücksichtigt werden.

Ein belastbares Wartungsfenster enthält einen klaren Abbruchzeitpunkt. Ist bis zu diesem Zeitpunkt keine erfolgreiche Inbetriebnahme nachgewiesen, wird nach dem festgelegten Verfahren die Wiederherstellung eingeleitet.

Besonders bei weltweit verteilten Messstellen sind zusätzlich unterschiedliche Zeitzonen, Produktionszeiten und die Verfügbarkeit von Servicetechnikern zu beachten. Ein für die zentrale IT günstiger Zeitpunkt kann an einer entfernten Anlage mitten in eine kritische Betriebsphase fallen.

Das Wartungsfenster muss daher mit den verantwortlichen OT-Betreibern abgestimmt werden. Bei sicherheitsbezogenen Funktionen dürfen notwendige Schutzmaßnahmen nicht ohne freigegebenes Ersatzkonzept unterbrochen werden.

6. Firmware vor dem Rollout in einer Testumgebung prüfen

Ein Firmware-Update sollte nach Möglichkeit zunächst auf einem repräsentativen Testgerät installiert werden. Die Testumgebung muss die wesentlichen Eigenschaften des späteren Einsatzes abbilden. Dazu zählen Hardware-Revision, bisherige Firmware, Kommunikationsprotokolle und wichtige Konfigurationseinstellungen.

Ein Gateway, das im Prüflabor nur über Ethernet mit einem einzelnen Sensor verbunden ist, bildet eine produktive Anlage mit mehreren RS-485-Teilnehmern, Mobilfunkübertragung und lokaler Datenbank nur eingeschränkt ab.

In der Testumgebung sollte geprüft werden, ob alle benötigten Dienste nach dem Update korrekt starten. Dazu gehören beispielsweise die Feldbusabfrage, MQTT-Verbindung, Zeitdienst, lokale Messdatenpufferung und eventuelle Alarmfunktionen.

Auch ein unterbrochener Update-Vorgang kann Bestandteil eines freigegebenen Robustheitstests sein. Entscheidend ist, wie das Gateway bei einer fehlerhaften Installation reagiert und ob ein vorgesehener Wiederherstellungsmechanismus funktioniert. Solche Tests dürfen nur entsprechend den Herstelleranweisungen und unter geeigneten Bedingungen durchgeführt werden.

Besonders wichtig ist die Prüfung der Datenverarbeitung. Werden nach der neuen Firmware weiterhin dieselben Messgrößen mit den vorgesehenen Einheiten, Datenpunkten und Zeitstempeln übertragen? Bleiben vorhandene Konfigurationsdateien gültig? Werden bereits gespeicherte Messdaten korrekt übernommen?

Die Testumgebung sollte außerdem zeigen, ob die vorherige Firmware tatsächlich wieder installiert werden kann. Ein theoretisch vorhandenes Firmware-Archiv ersetzt keinen belastbaren Nachweis des Wiederherstellungsverfahrens.

Bei einem nicht erfolgreich bestandenen Test wird der produktive Rollout zurückgestellt, bis die Ursache verstanden und das Vorgehen angepasst ist.

7. Konfiguration, Messdaten und Zugangsinformationen sichern

Vor einem Firmware-Update müssen die Informationen gesichert werden, die für die Wiederherstellung der bisherigen Funktion benötigt werden. Dazu gehört deutlich mehr als die eigentliche Firmware-Datei.

Ein typisches Gateway enthält Feldbuskonfigurationen, Adresszuordnungen, Messbereichsparameter, Einheiten, MQTT-Topics, Alarmgrenzen, Netzwerkeinstellungen und verschiedene Kommunikationszertifikate.

Bei Systemen mit lokaler Datenverarbeitung können außerdem Skripte, Filterregeln, Umrechnungen oder benutzerdefinierte Anwendungen vorhanden sein. Diese Einstellungen müssen nach dem Update verfügbar bleiben oder aus einer freigegebenen Sicherung wiederhergestellt werden können.

Auch lokale Messdatenpuffer sind zu berücksichtigen. Wenn die Firmware-Installation Speicherbereiche verändert oder ein Speichermedium neu initialisiert, können ungesicherte Messwerte verloren gehen. Der Sicherungsumfang muss daher ausdrücklich zwischen Konfigurationsdaten und Messdaten unterscheiden.

Die Sicherung sensibler Zugangsdaten benötigt ein geeignetes Sicherheitskonzept. Private Schlüssel, Kennwörter und Zertifikate dürfen nicht ungeschützt in beliebige Backup-Dateien übernommen werden. Wo das Gerät einen sicheren Export nicht unterstützt, muss die Wiederherstellung über dafür vorgesehene Verwaltungs- oder Provisionierungsverfahren erfolgen.

Entscheidend ist zudem die Wiederherstellbarkeit. Eine Sicherung ist erst dann belastbar, wenn ihre Lesbarkeit und die notwendige Zuordnung zur Geräte- und Firmware-Version nachgewiesen wurden.

Die Backup-Dokumentation sollte festhalten, welche Daten gesichert wurden, wann dies geschah, auf welche Hardware-Revision sie sich beziehen und welche Berechtigungen für eine Wiederherstellung erforderlich sind.

Eine reine Kopie der Gerätekonfiguration garantiert nicht automatisch die Wiederherstellung des vollständigen Betriebszustands. Laufende Messdaten, Queues, Zertifikate und externe Kommunikationsbeziehungen können zusätzliche Maßnahmen erfordern.

8. Firmware-Authentizität und Update-Übertragung absichern

Ein Firmware-Update verändert Software, die mit weitreichenden Berechtigungen auf einem industriellen Gerät ausgeführt wird. Deshalb muss sichergestellt werden, dass die verwendete Firmware aus einer vertrauenswürdigen Quelle stammt und während der Bereitstellung nicht unbemerkt verändert wurde.

Geeignete Update-Architekturen verwenden dafür beispielsweise digital signierte Firmware-Images und geschützte Metadaten. Der IETF-Standardisierungsansatz in RFC 9019 beschreibt unter anderem die Bedeutung von Authentifizierung, Integritätsschutz und sicheren Wiederherstellungsmechanismen.

Ein kryptografischer Hashwert kann helfen, eine Datei mit einem bekannten Referenzwert zu vergleichen. Ein Hash allein bestätigt jedoch nicht die Vertrauenswürdigkeit der Quelle. Dafür ist eine geeignete Authentifizierung beziehungsweise Signaturprüfung erforderlich.

Auch die Kompatibilität muss kontrolliert werden. Eine Firmware-Datei kann authentisch sein und dennoch für eine andere Hardware-Revision vorgesehen sein. Das Update-Verfahren muss deshalb die Geräte- und Versionszuordnung prüfen.

Bei einer Fernaktualisierung über das Netzwerk sind zusätzlich die Rechte zur Auslösung des Updates und die Kommunikationswege abzusichern. Nicht jeder Benutzer, der Messdaten lesen darf, sollte automatisch Firmware auf produktiven Gateways installieren können.

Eine sinnvolle Rechteverteilung unterscheidet beispielsweise die Freigabe eines Updates, dessen technische Bereitstellung und die eigentliche Installation im vorgesehenen Wartungsfenster.

Auch ein automatisiertes Update-System benötigt nachvollziehbare Protokolle. Daraus muss hervorgehen, welche Version auf welchem Gerät durch wen oder durch welchen autorisierten Prozess installiert wurde.

Sichere Firmware-Verteilung und betriebliche Update-Freigabe ergänzen sich. Selbst eine korrekt signierte Firmware sollte nicht unkontrolliert auf eine produktive OT-Anlage ausgerollt werden, wenn ihr Einfluss auf die Messdatenverarbeitung noch nicht geprüft wurde.

9. Rollback und Wiederherstellung zuverlässig vorbereiten

Rollback bezeichnet die kontrollierte Rückkehr zu einer vorherigen funktionsfähigen Softwareversion. Für IIoT-Gateways ist diese Möglichkeit besonders wichtig, wenn nach einem Update Messdaten nicht mehr korrekt übertragen werden oder eine benötigte Funktion ausfällt.

Ein automatischer Rollback ist jedoch keine allgemeine Standardeigenschaft aller Gateways. Ob er vorhanden ist, hängt von Hardware, Bootloader, Speicheraufteilung und Firmware-Architektur ab.

Bestimmte Geräte verwenden getrennte Firmware-Partitionen, beispielsweise ein A/B-System. Dabei kann die neue Version zunächst in einem anderen Speicherbereich vorbereitet werden. Nach einem erfolgreichen Start wird dieser aktiviert. Bei einem erkannten Fehler kann unter entsprechenden Voraussetzungen ein Rückwechsel möglich sein.

Andere Geräte benötigen eine separate Wiederherstellungsumgebung, einen lokalen Servicezugang oder eine vollständige Neuinstallation. Manche Systeme unterstützen überhaupt kein direktes Downgrade auf ältere Firmware-Versionen.

Zusätzlich können Sicherheitsmechanismen das Zurückspielen älterer, verwundbarer Versionen verhindern. Ein Rollback darf deshalb nicht vorausgesetzt werden, ohne die dokumentierten Möglichkeiten und Einschränkungen des Herstellers zu prüfen.

Besonders kritisch sind Änderungen an der Datenbank- oder Konfigurationsstruktur. Wenn eine neue Firmware gespeicherte Daten in ein anderes Format migriert, kann die alte Firmware diese möglicherweise nicht mehr lesen.

Ein vollständiger Wiederherstellungsplan muss daher Software, Konfiguration, Datenmodell und lokale Messdaten getrennt betrachten. Eine erfolgreiche Rückkehr zur alten Firmware garantiert nicht automatisch, dass der vorherige Datenbestand ebenfalls wiederhergestellt ist.

Vor dem Rollout sollten deshalb die zulässigen Rückkehrversionen, die benötigten Sicherungen, die Wiederherstellungsdauer und die verantwortliche Person eindeutig festgelegt werden.

Ein Rollback ist erst dann abgeschlossen, wenn das Gateway wieder die vorgesehenen Messwerte erfasst, überträgt und die erforderlichen Betriebsfunktionen erfüllt.

10. Messdatenausfall, Übertragungsausfall und Datenlücke unterscheiden

Im IIoT-Betrieb werden verschiedene Arten von Datenunterbrechungen häufig unter dem Begriff Messdatenausfall zusammengefasst. Für die Qualität der späteren Auswertung ist jedoch eine genauere Unterscheidung erforderlich.

Erfassungsausfall: Während eines bestimmten Zeitraums werden keine neuen Messwerte erzeugt oder aufgenommen. Ist keine unabhängige Aufzeichnung vorhanden, lassen sich diese Werte später nicht zuverlässig rekonstruieren.

Übertragungsausfall: Die Messwerte werden weiterhin erfasst, erreichen den übergeordneten Server aber zunächst nicht. Wenn sie lokal zuverlässig gespeichert werden, kann eine spätere Übertragung möglich sein.

Zeitbezogener Datenfehler: Die Messwerte sind vorhanden, tragen aber ungeeignete oder falsche Zeitstempel. Dadurch kann die Reihenfolge oder zeitliche Zuordnung später falsch erscheinen.

Semantischer Datenfehler: Ein Wert wird nach dem Update mit einer anderen Einheit, Skalierung oder Datenpunktzuordnung interpretiert. Die Übertragung funktioniert, aber die physikalische Bedeutung ist nicht mehr korrekt.

Diese Fehlerarten haben unterschiedliche Auswirkungen. Eine vorübergehend unterbrochene Cloud-Verbindung kann bei vorhandener Pufferung ohne dauerhaften Datenverlust bleiben. Ein vollständiger Ausfall der Gateway-Erfassung erzeugt dagegen möglicherweise eine echte Messlücke.

Auch nachträglich übertragene Messwerte müssen daher als solche erkennbar bleiben. Der Zeitpunkt der Übertragung darf nicht mit dem ursprünglichen Messzeitpunkt verwechselt werden.

Eine kontinuierliche Linie im Dashboard ist ebenfalls kein ausreichender Nachweis lückenloser Erfassung. Manche Anwendungen verbinden vorhandene Messpunkte grafisch oder ergänzen fehlende Werte durch Interpolation. Eine solche Darstellung kann den tatsächlichen Ausfall verdecken.

Für belastbare Messdaten sind deshalb Informationen über Erfassungsstatus, Zeitstempel und gegebenenfalls vorhandene Datenlücken erforderlich.

11. Lokale Datenpufferung und Store-and-Forward auslegen

Store-and-Forward bezeichnet ein Verfahren, bei dem Messdaten bei unterbrochener Übertragung zunächst lokal gespeichert und nach Wiederherstellung der Verbindung weitergeleitet werden.

Für IIoT-Gateways kann diese Funktion einen wesentlichen Beitrag zur Datenverfügbarkeit leisten. Voraussetzung ist jedoch, dass die Messwerterfassung und der lokale Speicherprozess während der betreffenden Unterbrechung weiterhin funktionieren.

Ein flüchtiger Speicher allein ist für eine längere Update-Unterbrechung unter Umständen nicht ausreichend. Bei einem Neustart können Daten verloren gehen, wenn sie nur im Arbeitsspeicher liegen. Für die gewünschte Wiederanlauffähigkeit ist daher gegebenenfalls eine persistente Speicherung erforderlich.

Der lokale Puffer sollte die Reihenfolge der Messwerte, ihre Zeitstempel und ihren Qualitätsstatus erhalten. Er muss zudem mit unvollständig übertragenen Daten und wiederholten Sendeversuchen umgehen können.

Eine wichtige Frage betrifft das Verhalten bei vollem Speicher. Manche Systeme überschreiben ältere Daten, andere verwerfen neuere Werte oder stoppen die Aufnahme. Welche Strategie geeignet ist, hängt von der Messaufgabe ab.

Ein Überschreiben der ältesten Messwerte kann beispielsweise für eine reine Live-Trendanzeige akzeptabel sein. Für eine rückverfolgbare Qualitätsaufzeichnung ist dieses Verhalten möglicherweise unzulässig.

Auch die Belastung des Speichermediums muss berücksichtigt werden. Häufige Schreibvorgänge können bei ungeeigneten Flash-Speichern die Lebensdauer beeinflussen. Deshalb sind Speichertechnologie, Schreibstrategie und erforderliche Datenintegrität Bestandteil der Systemauslegung.

Entscheidend ist außerdem die Grenze des Verfahrens: Store-and-Forward schützt gegen eine unterbrochene Weiterleitung. Wenn das Gateway während eines Firmware-Neustarts keine neuen Messwerte erfasst, kann sein eigener Puffer diese nicht nachträglich erzeugen.

Für eine lückenlose Erfassung während eines vollständigen Gateway-Ausfalls kann beispielsweise eine unabhängige Aufzeichnung in einer SPS, einem separaten Datenlogger oder einer dafür ausgelegten vorgelagerten Komponente erforderlich sein. Ob die historische Abfrage unterstützt wird, hängt von den eingesetzten Geräten und Protokollen ab.

Weitere Grundlagen zur lokalen Pufferung und zum Ausfall der Cloud-Anbindung erläutert der ICS-Beitrag Cloud-Verbindung fällt aus: Edge-Alarme und lokale Datenpufferung ausfallsicher planen.

12. Rechenbeispiel: Speicherbedarf und Wiederanlauf berechnen

Der benötigte lokale Pufferspeicher hängt von der Anzahl der Messpunkte, dem Erfassungsintervall, der durchschnittlichen Datensatzgröße und der maximal zu überbrückenden Unterbrechung ab.

Für eine vereinfachte Abschätzung kann folgende Beziehung verwendet werden:

S = N · f · B · t

Dabei bezeichnet S den erforderlichen Speicherbedarf in Byte, N die Anzahl der erfassten Messpunkte, f die Erfassungsrate pro Messpunkt in 1/s, B die durchschnittliche Datensatzgröße in Byte und t die Unterbrechungsdauer in Sekunden.

Ein Beispiel betrachtet ein Gateway mit 120 Messpunkten. Jeder Messpunkt wird alle zwei Sekunden erfasst. Pro Datensatz werden einschließlich der für das Beispiel angesetzten Metadaten durchschnittlich 220 Byte gespeichert. Eine Übertragungsunterbrechung von drei Stunden soll vollständig gepuffert werden.

Die Erfassungsrate beträgt damit 60 Datensätze pro Sekunde. Über drei Stunden entstehen 648.000 Datensätze.

S = 120 · 0,5 s^-1 · 220 Byte · 10.800 s
S = 142.560.000 Byte ≈ 142,6 MB

Die folgende Tabelle fasst das Beispiel zusammen:

Beispiel zur Auslegung eines lokalen Messdatenpuffers

Parameter	Angenommener Wert	Bedeutung
Anzahl Messpunkte	120	Separat erfasste Datenpunkte
Erfassungsintervall	2 s	Ein Messwert pro Datenpunkt alle zwei Sekunden
Datensatzgröße	220 Byte	Angenommener mittlerer Speicherbedarf je Datensatz
Unterbrechungsdauer	3 h	Vorgesehene maximale Übertragungspause im Beispiel
Datensatzanzahl	648.000	Während der Unterbrechung erzeugte Datensätze
Rechnerischer Speicherbedarf	ca. 142,6 MB	Ohne zusätzliche Speicher- und Verwaltungsreserven
Mit beispielhaft 30 % Reserve	ca. 185,3 MB	Zusätzlicher Planungszuschlag, keine allgemeingültige Vorgabe

Für die tatsächliche Auslegung müssen darüber hinaus Dateisystem, Datenbankindizes, Verwaltungsinformationen, mögliche Wiederholungen und weitere lokale Speicheraufgaben berücksichtigt werden. Der genutzte Speicher muss während des Updates verfügbar bleiben beziehungsweise sicher erhalten werden.

Auch die Wiederübertragung benötigt Zeit. Angenommen, nach Wiederherstellung der Verbindung können insgesamt 100 Datensätze pro Sekunde verarbeitet werden. Gleichzeitig entstehen weiterhin 60 neue Datensätze pro Sekunde. Dann stehen für den Abbau des Rückstands netto nur 40 Datensätze pro Sekunde zur Verfügung.

Unter diesen idealisierten Bedingungen würde der Abbau von 648.000 zwischengespeicherten Datensätzen rund 4,5 Stunden dauern. In der Praxis können Protokolloverhead, Serverlast und Netzverbindung die Wiederherstellungszeit verändern.

Eine ausreichend große Speicherkapazität allein garantiert deshalb keine schnelle Rückkehr zu aktuellen Daten. Auch die Übertragungsleistung nach der Unterbrechung muss zur laufenden Erfassung und zum vorhandenen Rückstand passen.

Die Berechnung behandelt ausdrücklich nur Messdaten, die während der Unterbrechung tatsächlich erzeugt und gespeichert wurden. Ein vollständiger Ausfall der Erfassung während des Gateway-Neustarts bleibt davon unberührt.

13. Zeitstempel und Uhrensynchronisation erhalten

Für eine industrielle Messdatenhistorie ist der Zeitbezug ebenso wichtig wie der eigentliche Messwert. Ein Druckwert von 6,2 bar ist nur dann eindeutig einem Prozesszustand zuzuordnen, wenn bekannt ist, wann er erfasst wurde.

Bei IIoT-Systemen können mehrere Zeitpunkte auftreten: der Zeitpunkt der tatsächlichen Messwerterfassung, der Empfangszeitpunkt im Gateway und der spätere Eingangszeitpunkt in einer Datenbank oder Cloud-Plattform.

Diese Zeitpunkte sind insbesondere während und nach einem Firmware-Update nicht zwangsläufig identisch. Werden Messwerte mehrere Stunden lokal gepuffert, erreichen sie die zentrale Datenbank erst deutlich später.

Für historische Auswertungen sollte deshalb der ursprüngliche Erfassungszeitpunkt erhalten bleiben. Der Übertragungs- oder Speicherzeitpunkt kann ergänzend dokumentiert werden, darf aber nicht unbemerkt den ursprünglichen Messzeitpunkt ersetzen.

Ein geeignetes Datenmodell unterscheidet beispielsweise timestamp_source, timestamp_received und timestamp_ingested. Die genaue Benennung ist projektspezifisch, die Bedeutung der Felder muss jedoch eindeutig sein.

In OPC UA werden beispielsweise SourceTimestamp und ServerTimestamp unterschieden. Die OPC-UA-Spezifikation beschreibt den SourceTimestamp als Zeitbezug des Datenursprungs und sieht dessen unveränderte Weitergabe vor, soweit ein solcher Zeitstempel verfügbar ist.

Nach einem Neustart benötigt das Gateway eine zuverlässige Systemzeit. Wird die Uhr über NTP oder einen anderen geeigneten Zeitdienst synchronisiert, muss das Wiederanlaufverhalten berücksichtigt werden. Messwerte, die vor einer erfolgreichen Zeitsynchronisation erfasst werden, können einen unzuverlässigen Zeitbezug besitzen.

Besonders kritisch sind Systeme ohne ausreichend gepufferte Echtzeituhr, die nach einem Spannungsausfall zunächst mit einer falschen Uhrzeit starten. Derartige Werte dürfen nicht stillschweigend als zeitlich korrekt gekennzeichnet werden.

Für die Messdatenqualität ist daher festzulegen, wie mit ungültigen oder unsicheren Zeitstempeln umgegangen wird. Geeignete Qualitätskennzeichen können verhindern, dass solche Daten später ungeprüft in Berechnungen oder Berichte eingehen.

Auch Änderungen der Zeitzone oder Sommerzeit dürfen historische Messdaten nicht unbemerkt verschieben. Für übergreifende industrielle Datenmodelle ist eine konsistente Zeitbasis, beispielsweise UTC mit eindeutig dokumentierter Darstellung, besonders hilfreich.

14. Datenmodell, Einheiten und Skalierungen unverändert halten

Ein Firmware-Update kann nicht nur Kommunikationsfunktionen verändern, sondern auch die Interpretation von Messdaten. Besonders problematisch sind Änderungen an Skalierungsfaktoren, Registerzuordnungen, Einheiten oder Datentypen.

Ein Beispiel ist ein Drucksensor mit einem analogen Signal von 4 … 20 mA. Vor dem Update wird der Eingang mit einem Messbereich von 0 … 10 bar verarbeitet. Nach einer fehlerhaften Konfigurationsmigration verwendet das Gateway plötzlich 0 … 16 bar. Bei gleicher elektrischer Eingangsspannung beziehungsweise gleichem Eingangsstrom entstehen dadurch andere berechnete Druckwerte.

Auch die Verarbeitung digitaler Register kann betroffen sein. Ein geänderter Modbus-Treiber kann beispielsweise Datentypen, Byte-Reihenfolge oder Registeradressen anders interpretieren. Der Kommunikationsstatus kann dabei weiterhin fehlerfrei erscheinen.

Deshalb sollten wichtige Messpunkte vor und nach dem Update mit denselben bekannten Eingangsbedingungen verglichen werden. Dazu gehören zumindest exemplarische Werte im unteren, mittleren und oberen Bereich der jeweiligen Messspanne, soweit dies für die Messaufgabe sinnvoll und sicher möglich ist.

Eine besonders zuverlässige Lösung verwendet versionierte Datenmodelle. Werden Einheit, Skalierung oder physikalische Bedeutung eines Datenpunkts geändert, bleibt dokumentiert, ab wann welche Konfiguration gültig war.

Auch MQTT-Topics oder Datenpunktkennungen sollten bei einer Firmware-Änderung nicht unkontrolliert umbenannt werden. Andernfalls können Historian, Alarmregeln oder Dashboards Daten unter einem unerwarteten Namen erhalten oder überhaupt nicht mehr zuordnen.

Die Firmware-Version selbst kann als zusätzliche Metainformation dokumentiert werden. Sie ersetzt jedoch keine eigenständige Versionierung des Messdatenmodells, wenn dessen Bedeutung unabhängig von der Firmware geändert werden kann.

Der ergänzende ICS-Fachbeitrag Einheiten und Skalierung in Messdaten versionieren erläutert die langfristige Sicherung der physikalischen Bedeutung industrieller Messwerte.

15. MQTT, Übertragungsbestätigungen und Duplikate behandeln

MQTT wird häufig für die Übertragung industrieller Messdaten zwischen Edge-Gateways, Brokern und übergeordneten Anwendungen verwendet. Die Nachrichtenübertragung kann mit verschiedenen Quality-of-Service-Stufen erfolgen.

Bei QoS 0 wird eine Nachricht ohne das für höhere QoS-Stufen vorgesehene Bestätigungs- und Wiederholungsverfahren übertragen. Ein Verlust ist möglich. QoS 1 sieht mindestens eine Zustellung auf der jeweiligen Protokollstrecke vor, wobei Duplikate auftreten können. QoS 2 verwendet einen umfangreicheren Ablauf zur genau einmaligen Zustellung innerhalb der jeweiligen MQTT-Protokollbeziehung.

Diese Eigenschaften bedeuten jedoch nicht automatisch, dass jeder Messwert genau einmal und dauerhaft in einer nachgeschalteten Historian-Datenbank gespeichert wurde. Eine erfolgreiche MQTT-Bestätigung kann sich auf die Annahme der Nachricht durch den jeweiligen Kommunikationspartner beziehen, während die weitere Verarbeitung in einer anderen Anwendung stattfindet.

Für Store-and-Forward muss deshalb festgelegt werden, wann eine Nachricht als erfolgreich übertragen gilt und unter welchen Bedingungen sie aus dem lokalen Puffer gelöscht werden darf.

Bei QoS 1 können nach Verbindungsunterbrechungen wiederholte Nachrichten auftreten. Ein robustes Datenmodell sollte deshalb eine eindeutige Zuordnung der Messwerte ermöglichen. Dazu können beispielsweise stabile Gerätekennungen, Messpunktkennungen, Zeitstempel und Sequenznummern verwendet werden.

Die nachgeschaltete Verarbeitung kann auf dieser Grundlage bereits gespeicherte Datensätze erkennen und doppelte Einträge vermeiden. Welche Kombination eindeutig ist, hängt vom Erfassungsverfahren und der Anwendung ab.

Ein weiterer wichtiger Punkt betrifft die Reihenfolge. Nach einer Wiederverbindung können ältere gepufferte Nachrichten und neue Live-Daten zeitlich ineinanderlaufen. Eine Datenbank darf den Empfangszeitpunkt deshalb nicht automatisch als physikalische Reihenfolge der Messereignisse interpretieren.

Auch die MQTT-Retain-Funktion ist von einer Messdatenhistorie zu unterscheiden. Retained Messages stellen für ein Topic den jeweils gespeicherten letzten Nachrichteninhalt bereit, sind aber kein Ersatz für eine vollständige historische Aufzeichnung.

Die passende MQTT-Konfiguration hängt daher von Datenrate, Verfügbarkeit, zulässigen Duplikaten und den Anforderungen an die vollständige Messdatenkette ab.

16. Lokale Alarmierung und sicheren Anlagenbetrieb gewährleisten

Bei IIoT-Anwendungen muss besonders sorgfältig zwischen einer informativen Meldung und einer sicherheitsrelevanten Schutzfunktion unterschieden werden.

Ein Cloud-Dashboard kann beispielsweise Grenzwertüberschreitungen darstellen und Benachrichtigungen an Wartungspersonal senden. Eine solche Meldung ist jedoch nicht automatisch für eine sicherheitsgerichtete Abschaltung geeignet.

Werden notwendige Alarmfunktionen direkt im IIoT-Gateway ausgeführt, können sie während eines vollständigen Firmware-Neustarts zeitweise nicht verfügbar sein. Eine lokale Datenpufferung verhindert diesen Funktionsausfall nicht.

Für wichtige Prozessschutzfunktionen muss deshalb geprüft werden, ob eine unabhängige Auswertung in einer geeigneten SPS, einem separaten Grenzwertgerät oder einem entsprechend ausgelegten Schutzsystem erforderlich ist.

Die notwendige Unabhängigkeit ergibt sich aus der Gefährdungs- und Funktionsbewertung der Anlage. Ein gewöhnliches IIoT-Gateway mit Alarmfunktion ist nicht automatisch ein für funktionale Sicherheit zugelassenes Schutzsystem.

Vor dem Update ist festzulegen, welche Alarmierungen während des Wartungsfensters verfügbar bleiben müssen. Falls bestimmte Funktionen vorübergehend ausgesetzt werden, benötigt dies ein freigegebenes betriebliches Verfahren und gegebenenfalls geeignete Ersatzmaßnahmen.

Nach dem Firmware-Wechsel muss zusätzlich geprüft werden, ob alle Alarmgrenzen, Hysteresen, Verzögerungen und Zustandsmeldungen korrekt übernommen wurden.

Auch die Kennzeichnung historischer Alarme ist wichtig. Ein nachträglich übertragener Grenzwertverstoß darf nicht automatisch als neuer aktueller Alarm interpretiert werden, wenn er während einer zurückliegenden Pufferphase auftrat.

Für eine belastbare Architektur müssen daher der ursprüngliche Ereigniszeitpunkt, der Status der Messstelle und die vorgesehene Alarmverarbeitung eindeutig bleiben.

17. Feldbus, Sensorverbindungen und Kommunikation nach dem Neustart prüfen

Nach einem Firmware-Update sollte nicht nur die Verbindung des Gateways zur Cloud überprüft werden. Ebenso wichtig ist die Kommunikation zur Feldebene.

Bei Modbus-RTU-Verbindungen sind beispielsweise serielle Schnittstellenparameter, Teilnehmeradressen, Registerzuordnungen und die tatsächliche Abfrage der angeschlossenen Geräte relevant.

Ein Gateway kann nach einem Update über seine Weboberfläche erreichbar sein, während einzelne Modbus-Teilnehmer wegen einer geänderten Schnittstellenkonfiguration keine gültigen Messwerte mehr liefern.

Bei OPC UA müssen unter anderem Endpoint-Einstellungen, Sicherheitsrichtlinien, Zertifikate und die verwendeten Datenpunktkennungen zur bestehenden Anlage passen.

Bei HART- oder IO-Link-Anbindungen sind gegebenenfalls die entsprechenden Schnittstellenkomponenten und ihre Treiberversionen zu berücksichtigen.

Ebenso wichtig ist die Unterscheidung zwischen einem erfolgreich aufgebauten Kommunikationskanal und dem Empfang gültiger Messwerte. Ein TCP-Verbindungsaufbau beweist noch nicht, dass die erforderlichen Prozessdaten in der richtigen physikalischen Bedeutung gelesen werden.

Ein sinnvoller Funktionstest umfasst deshalb ausgewählte Messpunkte aus allen relevanten angeschlossenen Gerätegruppen. Die Prüfwerte werden mit den vorgesehenen Referenzen und Konfigurationseinstellungen verglichen.

Auch die Wiederverbindung nach einem Netzausfall sollte geprüft werden. Das Gateway muss nach dem Firmware-Update mit den vorgesehenen Kommunikationspartnern erneut arbeiten können, ohne dass hierfür unkontrollierte manuelle Änderungen notwendig werden.

Zusätzliche Aufmerksamkeit benötigen Anlagen mit wechselnden Netzwerkadressen, Mobilfunkroutern oder VPN-Verbindungen. Dort kann ein scheinbarer Firmwarefehler auch durch fehlerhafte Namensauflösung, Zertifikate oder Netzwerkparameter entstehen.

18. Firmware-Updates auf mehrere Gateways gestaffelt ausrollen

In größeren IIoT-Anlagen sind häufig mehrere Gateways an verschiedenen Maschinen, Linien oder Standorten installiert. Ein gleichzeitiges Update aller Geräte kann das Risiko einer größeren Betriebsunterbrechung erhöhen.

Ein gestaffelter Rollout reduziert dieses Risiko, indem zunächst eine kleine, repräsentative Gerätegruppe aktualisiert wird. Erst nach erfolgreicher Prüfung folgen weitere Gruppen.

Eine geeignete Reihenfolge kann beispielsweise mit einer Testanlage beginnen, danach einzelne produktive Gateways mit geringer betrieblicher Kritikalität umfassen und schließlich auf weitere Anlagenbereiche erweitert werden.

Die Gruppierung sollte nicht ausschließlich nach Standort erfolgen. Auch Hardware-Revision, Firmware-Ausgangsstand, verwendete Schnittstellen und betriebliche Bedeutung sind relevant.

Wird ein Fehler festgestellt, kann der Rollout angehalten werden, bevor die gleiche Änderung weitere Gateways erreicht.

Für das Geräte- und Fleet-Management sind stabile Gerätekennungen und nachvollziehbare Versionsstände wichtig. Nach dem Rollout muss eindeutig festgestellt werden können, welche Geräte erfolgreich aktualisiert wurden, welche weiterhin die alte Firmware besitzen und bei welchen Geräten ein Fehler aufgetreten ist.

Auch zeitversetzte Rückmeldungen müssen berücksichtigt werden. Ein Gateway kann während einer Mobilfunkunterbrechung nicht erreichbar sein und später wieder online gehen. Sein tatsächlicher Firmware- und Betriebsstatus darf nicht allein aus dem zuletzt versendeten Update-Befehl abgeleitet werden.

Ein als erfolgreich gemeldeter Installationsvorgang sollte deshalb zusätzlich durch einen geeigneten Gesundheits- und Funktionstest bestätigt werden.

Für kritische Systeme ist eine zentrale Möglichkeit zum Stoppen oder Aussetzen weiterer Updates sinnvoll. Automatische Rollouts benötigen klare Freigabe- und Abbruchbedingungen.

19. Einen kontrollierten Firmware-Update-Ablauf durchführen

Ein reproduzierbarer Firmware-Update-Prozess verbindet technische Prüfung, betriebliche Freigabe und nachvollziehbare Dokumentation. Die Durchführung erfolgt nach den Angaben des jeweiligen Gateway-Herstellers und dem freigegebenen OT-Änderungsverfahren.

Ein geeigneter Ablauf kann folgende Schritte umfassen:

1. Update-Anlass bewerten: Sicherheitslücke, Fehlerbehebung oder neue Funktion eindeutig dokumentieren.
2. Geräte und Abhängigkeiten identifizieren: Hardware-Revision, Ausgangsfirmware, Messpunkte, Schnittstellen und betroffene Anlagenfunktionen erfassen.
3. Firmware-Freigabe prüfen: Herkunft, Signatur, Kompatibilität, Versionshinweise und erforderliche Zwischenschritte kontrollieren.
4. Betriebliches Wartungsfenster freigeben: Verfügbarkeit, notwendige Schutzfunktionen, Wiederherstellungsreserve und verantwortliche Personen abstimmen.
5. Konfiguration und Daten sichern: Vorhandene Einstellungen und relevante lokale Messdaten entsprechend dem Wiederherstellungsplan sichern.
6. Ausgangszustand messen: Verbindung, Datenqualität, Zeitstempel, Pufferstatus und wichtige Referenzmesswerte dokumentieren.
7. Update vorbereitet bereitstellen: Geeigneten und sicheren Übertragungsweg verwenden; gegebenenfalls Firmware vor dem eigentlichen Wartungsfenster übertragen.
8. Firmware installieren: Herstellerverfahren ausführen und Statusmeldungen dokumentieren.
9. Neustart kontrollieren: Firmware-Version, Systemzeit, verfügbare Dienste und Gerätezustand überprüfen.
10. Feldkommunikation testen: Repräsentative Messwerte aus den relevanten Sensor- und Steuerungsschnittstellen lesen.
11. Messdatenpfad verifizieren: Datenmodell, Einheiten, Skalierungen, Zeitstempel, Übertragungsstatus und lokale Pufferung überprüfen.
12. Alarm- und Störungsfunktionen prüfen: Die vorgesehenen betrieblichen Meldungen und erforderlichen Schutzfunktionen nach dem freigegebenen Verfahren nachweisen.
13. Rollback-Entscheidung treffen: Bei nicht erfüllten Freigabekriterien innerhalb der vorgesehenen Frist die Wiederherstellung einleiten.
14. Abschluss dokumentieren: Endgültige Firmware-Version, Prüfergebnisse, bekannte Einschränkungen und Freigabe des Anlagenbetriebs festhalten.

Besonders wichtig ist die Reihenfolge der Prüfungen. Zunächst muss das Gateway technisch wieder betriebsbereit sein. Anschließend wird die Kommunikation zur Feldebene überprüft. Erst danach kann die vollständige Messdatenübertragung einschließlich ihrer semantischen und zeitlichen Eigenschaften bewertet werden.

Wird die Cloud-Verbindung erfolgreich aufgebaut, dürfen die weiteren Prüfschritte nicht automatisch entfallen. Ein vollständiger Funktionsnachweis benötigt auch gültige Messwerte und die korrekte Auswertung der angeschlossenen Datenpunkte.

Für die produktive Freigabe sollten alle vorher festgelegten Akzeptanzkriterien erfüllt sein. Nicht bestandene oder nicht durchgeführte Prüfungen sind ausdrücklich zu dokumentieren.

20. Messdatenqualität und Betriebsbereitschaft nach dem Update nachweisen

Die erfolgreiche Installation einer Firmware-Version ist zunächst ein technischer Status. Für die Freigabe einer industriellen IIoT-Messstelle muss zusätzlich nachgewiesen werden, dass die vorgesehene Messaufgabe wieder korrekt erfüllt wird.

Ein wichtiger Prüfpunkt ist die Aktualität der Messwerte. Die Daten dürfen nicht lediglich aus einer alten Anzeige oder einem vorhandenen Cache stammen. Das Gateway und die übergeordnete Plattform müssen neue Messdaten entsprechend dem vorgesehenen Erfassungsintervall verarbeiten.

Zusätzlich ist zu kontrollieren, ob die Messdaten aus der Zeit vor dem Update weiterhin verfügbar sind. Bei vorhandener Pufferung muss festgestellt werden, ob ungesendete Datensätze vollständig und korrekt nachträglich übertragen wurden.

Für die historische Auswertung sind die ursprünglichen Zeitstempel relevant. Eine Datenbank, in der mehrere Stunden alte Werte plötzlich den aktuellen Zeitpunkt tragen, besitzt zwar möglicherweise alle Zahlenwerte, aber keinen korrekten zeitlichen Verlauf.

Auch die Datenqualität muss bewertet werden. Ungültige, veraltete oder nicht verfügbare Messwerte sollten entsprechend dem verwendeten Datenmodell gekennzeichnet sein. Eine fehlende Messung darf nicht stillschweigend als gültiger letzter Messwert erscheinen.

Ein weiterer Prüfpunkt ist die Reihenfolge der Messdaten. Nach einem Neustart können gepufferte und neue Nachrichten zeitlich versetzt eintreffen. Die nachgelagerte Anwendung muss sie korrekt zuordnen können.

Schließlich müssen die Messstellenkennungen, Einheiten, Skalierungen, Alarmparameter und gegebenenfalls hinterlegten Konfigurationsversionen mit dem freigegebenen Ausgangszustand verglichen werden.

Ein vollständiger Nachweis umfasst deshalb sowohl die Geräteverfügbarkeit als auch die Vollständigkeit, Aktualität und physikalische Richtigkeit der Messdaten.

Für die betriebliche Qualitätssicherung können daraus geeignete Kennzahlen abgeleitet werden. Beispiele sind die Zeit bis zur Wiederverfügbarkeit, die Anzahl verlorener Messwerte, der höchste Pufferfüllstand, die Dauer der nachträglichen Übertragung und die Anzahl festgestellter Datenpunktabweichungen.

Die Grenzwerte dieser Kennzahlen sind anwendungsabhängig. Sie müssen aus den Anforderungen der Anlage abgeleitet und vor dem Update festgelegt werden.

21. Typische Update-Fehler systematisch diagnostizieren

Nach einem Firmware-Update können Fehler auftreten, die zunächst wie gewöhnliche Netzwerkprobleme aussehen. Eine systematische Diagnose trennt deshalb Firmwarezustand, Feldkommunikation, Datenverarbeitung und Übertragung.

Typische Fehler nach Firmware-Updates an IIoT-Gateways

Beobachtung	Mögliche Ursache	Sinnvolle Prüfung
Gateway ist erreichbar, aber einzelne Messwerte fehlen	Treiberproblem, geänderte Registerzuordnung oder ausgefallene Feldverbindung	Feldschnittstelle, Datenpunktkonfiguration und Rohwerte prüfen
Neue Daten erscheinen, historische Daten fehlen	Puffer wurde gelöscht, nicht persistent gespeichert oder noch nicht vollständig übertragen	Lokale Queue, Datenbankstatus und Wiederübertragung kontrollieren
Messwerte erscheinen mit falschem Zeitpunkt	Systemzeit nicht synchronisiert oder Empfangszeit als Messzeit gespeichert	Quellzeitstempel, Gateway-Uhr und Datenbank-Zeitzuordnung prüfen
Einzelne Messwerte besitzen plötzlich andere Größenordnungen	Skalierung, Einheit, Datentyp oder Byte-Reihenfolge geändert	Referenzwerte und versionierte Datenpunktkonfiguration vergleichen
Nach dem Update werden Messwerte doppelt gespeichert	Wiederholte Übertragung oder fehlende Duplikaterkennung	MQTT-QoS, Sequenznummern und Historian-Verarbeitung prüfen
MQTT-Verbindung wird nicht mehr aufgebaut	Zertifikat, Authentifizierung, TLS-Einstellung oder Broker-Konfiguration nicht kompatibel	Verbindungsprotokoll, Zertifikate, Uhrzeit und Zugangskonfiguration prüfen
Gateway startet nach dem Update wiederholt neu	Fehlerhafte Firmware, Konfigurationsproblem oder Speicher-/Versorgungsstörung	Boot-Protokolle und Gerätestatus kontrollieren; gegebenenfalls Wiederherstellung einleiten
Dashboard zeigt normale Werte, obwohl eine Feldverbindung unterbrochen ist	Alte Werte werden ohne passende Qualitätskennzeichnung weiter angezeigt	Messwertalter, Qualitätsstatus und Störungsverarbeitung prüfen
Neue Firmware läuft, aber Rollback ist nicht möglich	Downgrade-Sperre, fehlendes Wiederherstellungsimage oder inkompatible Datenstruktur	Herstellerfreigabe und vorher dokumentierten Wiederherstellungsweg prüfen
Alarme werden nach Wiederübertragung historischer Werte erneut ausgelöst	Vergangene Ereignisse werden wie aktuelle Live-Meldungen verarbeitet	Ereigniszeitstempel, Alarmstatus und Replay-Verarbeitung untersuchen

Die Tabelle enthält typische Ursachen und sinnvolle Prüfansätze. Ein beobachtetes Fehlerbild kann mehrere technische Ursachen besitzen. Deshalb sollte nicht unmittelbar eine erneute Firmware-Installation oder ein Werksreset ausgelöst werden.

Ein Werksreset kann vorhandene Konfigurationen oder lokale Daten verändern beziehungsweise löschen. Er ist deshalb nur dann geeignet, wenn der Wiederherstellungsumfang geklärt und das Vorgehen freigegeben wurde.

Eine nachvollziehbare Diagnose beginnt mit dem tatsächlichen Gerätezustand. Danach werden Feldkommunikation, lokale Datenverarbeitung, Zeitbasis und externe Übertragung nacheinander geprüft.

22. Passende IIoT-Lösungen von ICS Schneider

22.1 ICS IIoT-Lösungen: Edge-Gateways, Datenmodelle und industrielle Integration

Die IIoT-Lösungen von ICS Schneider verbinden industrielle Sensoren, Messumformer und Steuerungen mit übergeordneten IT- und OT-Systemen. Die beschriebenen Architekturen nutzen beispielsweise Modbus RTU, HART, IO-Link, OPC UA, Ethernet und MQTT/HTTPS.

ICS unterstützt die Auswahl und Integration geeigneter Edge-Gateways, die Definition von Datenmodellen, das Register-Mapping und die sichere Übertragung der Messwerte. Auch lokale Datenverarbeitung, Alarmierung und Pufferung können Bestandteil eines entsprechenden Lösungskonzepts sein.

Für die Wartungs- und Firmwarestrategie ist entscheidend, dass die konkret ausgewählte Gateway-Hardware die erforderlichen Funktionen tatsächlich unterstützt. Dazu gehören gegebenenfalls signierte Updates, persistente Datenpufferung, gesicherte Konfiguration, eine definierte Wiederherstellung und geeignete Verwaltungsfunktionen.

Diese Eigenschaften müssen für das konkrete Gerät geprüft werden. Sie dürfen nicht allein aus der allgemeinen Bezeichnung IIoT- oder Edge-Gateway abgeleitet werden.

22.2 IIoT-Drucküberwachung: Messdaten von Drucksensoren sicher weiterverarbeiten

Die IIoT-Drucküberwachung von ICS umfasst die Integration von Drucksensoren und Differenzdrucktransmittern in industrielle Datenarchitekturen.

Ein Beispiel für geeignete Feldsensorik ist der IDCT 531i Drucksensor mit RS-485/Modbus RTU. Der Sensor stellt digitale Druckwerte für die Verarbeitung durch entsprechend geeignete Master-Geräte bereit.

Bei einem Firmware-Update des übergeordneten Gateways sind insbesondere Modbus-Adressierung, Registerinterpretation, Abfrageintervalle und die dokumentierte Messwertskalierung zu prüfen.

Der Drucksensor selbst ersetzt keine Gateway-Datenpufferung. Soll während eines vollständigen Ausfalls der zentralen Datenerfassung weiter aufgezeichnet werden, benötigt die Architektur eine entsprechend geeignete zusätzliche Erfassungs- oder Speicherfunktion.

22.3 WIKA NETRIS1: Drahtlose Übertragung von Messwerten

Die WIKA NETRIS1 Funkeinheit ermöglicht die drahtlose Einbindung geeigneter Messgeräte in IIoT-Anwendungen. Je nach Ausführung werden unter anderem LoRaWAN, mioty und Bluetooth unterstützt.

Sie kann beispielsweise Messwerte von geeigneten Sensoren mit Normsignalen übertragen und ist damit für die Fernüberwachung industrieller Anlagen interessant.

Die NETRIS1 ist jedoch eine Funkeinheit auf der Feld- beziehungsweise Übertragungsebene und darf nicht mit einem frei programmierbaren industriellen Edge-Gateway gleichgesetzt werden. Update-, Puffer- und Wiederherstellungsfunktionen müssen für die jeweilige Systemkomponente separat nachgewiesen werden.

In einer vollständigen IIoT-Architektur muss außerdem geklärt sein, welche Komponente den maßgeblichen Messzeitstempel erzeugt und wie Daten bei einer Unterbrechung der nachgelagerten Kommunikation behandelt werden.

22.4 WIKA NETRIS3: IIoT-Funktechnik für geeignete Anwendungen im Ex-Bereich

Die WIKA NETRIS3 Funkeinheit ermöglicht die Übertragung von Messdaten geeigneter WIKA-Messgeräte über LoRaWAN. Die Serie ist für entsprechende Anwendungen in explosionsgefährdeten Bereichen ausgelegt.

Sie wird beispielsweise zur drahtlosen Fernüberwachung industrieller Druck-, Temperatur- oder Füllstandmessstellen eingesetzt.

Auch hier sind die verschiedenen Ebenen der IIoT-Architektur zu unterscheiden. Eine Aktualisierung eines zentralen Gateways oder Netzwerkservers ist nicht automatisch identisch mit einer Firmware-Aktualisierung der eingesetzten Funkeinheiten.

Für die Planung sind daher die jeweiligen Herstellerfreigaben, Betriebsbedingungen und Kommunikationsabhängigkeiten separat zu betrachten. Bei Geräten in explosionsgefährdeten Bereichen gelten zusätzlich die entsprechenden Zulassungs- und Wartungsanforderungen.

Weitere Integrationsmöglichkeiten bietet ICS Schneider in den Bereichen IIoT-Temperaturüberwachung und IIoT-Füllstandüberwachung.

Für eine komplette IIoT-Lösung sollten neben Sensorik und Kommunikation auch das Gateway-Management, die Update-Strategie, die lokale Datenhaltung und die Anforderungen an eine spätere Wiederherstellung bereits bei der Projektierung berücksichtigt werden.

23. Fazit: Firmware-Updates als kontrollierte Änderung der Messdatenkette behandeln

Firmware-Updates gehören zum sicheren und langfristig zuverlässigen Betrieb industrieller IIoT-Gateways. Sie können Sicherheitslücken schließen, Fehler beheben und neue Funktionen ermöglichen. Gleichzeitig können sie aber die Messwerterfassung, Datenverarbeitung, Kommunikation und Alarmierung vorübergehend oder dauerhaft verändern.

Eine erfolgreiche Aktualisierung darf deshalb nicht allein am Firmware-Versionsstand oder an der wiederhergestellten Netzwerkverbindung gemessen werden. Entscheidend ist, ob die vollständige Messdatenkette nach dem Update weiterhin die vorgesehenen Funktionen erfüllt.

Die wichtigsten Voraussetzungen sind ein ausreichend bemessenes Wartungsfenster, eine geprüfte Datensicherung, ein tatsächlich unterstützter Wiederherstellungsweg und die klare Trennung zwischen Messdatenerfassung und Messdatenübertragung.

Store-and-Forward kann einen Ausfall der übergeordneten Verbindung überbrücken. Es verhindert jedoch keine Datenlücke, wenn während eines vollständigen Gateway-Neustarts überhaupt keine neuen Messwerte erfasst werden und keine unabhängige Historie existiert.

Ebenso müssen Zeitstempel, Einheiten, Skalierungen und Datenpunktkennungen über den Firmware-Wechsel hinweg nachvollziehbar bleiben. Ein vollständig übertragener Datensatz ist für die Qualitätssicherung nur dann wertvoll, wenn seine physikalische Bedeutung und zeitliche Zuordnung korrekt sind.

Update-Bedarf bewerten → Geräte und Abhängigkeiten erfassen → Wartungsfenster festlegen → Firmware und Wiederherstellung testen → Konfiguration und Messdaten sichern → Datenpufferung und Alarmverfügbarkeit prüfen → Update kontrolliert installieren → Feld- und IT-Kommunikation testen → Messdatenqualität nachweisen → Rollout dokumentieren

Der wichtigste praktische Grundsatz lautet damit: Ein Firmware-Update ist erst dann vollständig abgeschlossen, wenn das IIoT-Gateway nicht nur wieder erreichbar ist, sondern die industriellen Messdaten weiterhin korrekt erfasst, zeitlich zuordnet, verarbeitet und überträgt.

24. Häufige Fragen zu Firmware-Updates für IIoT-Gateways

24.1 Warum müssen Firmware-Updates für IIoT-Gateways geplant werden?

Ein Firmware-Update kann Messwerterfassung, lokale Verarbeitung, Datenübertragung und Alarmfunktionen beeinflussen. Ein geplanter Ablauf stellt sicher, dass Wartungszeit, Datensicherung, Wiederherstellung und Funktionsprüfung auf die betrieblichen Anforderungen abgestimmt sind.

24.2 Kann ein Firmware-Update zu Messdatenverlust führen?

Ja. Wenn das Gateway während der Installation keine Messwerte erfasst oder lokale Daten nicht persistent gespeichert werden, können Daten verloren gehen. Eine unterbrochene Übertragung muss dagegen nicht zwangsläufig einen dauerhaften Datenverlust verursachen, sofern die Werte zuverlässig gepuffert werden.

24.3 Reicht eine lokale Store-and-Forward-Funktion aus, um Datenverlust zu verhindern?

Nicht in jedem Fall. Store-and-Forward schützt vor allem gegen Unterbrechungen der Weiterleitung, wenn die Messwerterfassung und lokale Speicherung weiterarbeiten. Bei einem vollständigen Gateway-Ausfall können ohne eine unabhängige vorgelagerte Aufzeichnung weiterhin Messlücken entstehen.

24.4 Wie groß muss der lokale Messdatenpuffer sein?

Der Speicherbedarf hängt von der Anzahl der Datenpunkte, der Erfassungsrate, der mittleren Datensatzgröße und der vorgesehenen Unterbrechungsdauer ab. Zusätzlich müssen Speicherverwaltung, Sicherheitsreserven, Schreibverhalten und die Wiederübertragungsleistung berücksichtigt werden.

24.5 Was bedeutet Rollback bei einem IIoT-Gateway?

Rollback bezeichnet die kontrollierte Rückkehr zu einer vorherigen funktionsfähigen Firmware-Version. Ob dies automatisch oder manuell möglich ist, hängt vom konkreten Gerät ab. Auch Konfiguration und lokale Datenformate müssen zur wiederhergestellten Software passen.

24.6 Unterstützt jedes industrielle Gateway einen automatischen Rollback?

Nein. Manche Systeme verwenden A/B-Firmware-Partitionen oder Wiederherstellungsimages. Andere benötigen einen lokalen Servicezugang oder unterstützen keine direkte Rückkehr zu einer früheren Version. Die tatsächlichen Möglichkeiten müssen vor dem Update anhand der Herstellerdokumentation geprüft werden.

24.7 Was gehört in das Wartungsfenster eines Firmware-Updates?

Zum Wartungsfenster gehören Vorbereitung, Sicherung, Installation, Neustart, Kommunikations- und Messwertprüfung sowie eine angemessene Reserve für Wiederherstellung. Zusätzlich sind die betriebliche Freigabe und ein festgelegter Abbruchzeitpunkt erforderlich.

24.8 Kann ich die Firmware während der laufenden Produktion aktualisieren?

Das hängt von der konkreten Architektur und den betroffenen Funktionen ab. Wenn die Aktualisierung Messwerterfassung oder Alarmierung unterbricht, muss dies betrieblich bewertet und freigegeben werden. Für notwendige Schutzfunktionen sind geeignete unabhängige Maßnahmen oder ein entsprechend abgesicherter Anlagenzustand erforderlich.

24.9 Warum stimmen die Zeitstempel nach einem Update manchmal nicht mehr?

Mögliche Ursachen sind eine nicht synchronisierte Systemuhr, geänderte Zeiteinstellungen oder eine fehlerhafte Zuordnung von Messzeit und Übertragungszeit. Die Zeitsynchronisation und die Behandlung historischer Messwerte müssen deshalb nach jedem relevanten Update geprüft werden.

24.10 Kann ich Messwerte nachträglich übertragen, ohne ihre Zeitstempel zu verändern?

Ja, wenn die ursprünglichen Messzeitpunkte korrekt erfasst und zusammen mit den Werten gespeichert wurden und das nachgelagerte System sie entsprechend verarbeitet. Der Zeitpunkt des späteren Datenempfangs sollte dabei von der ursprünglichen Messzeit unterscheidbar bleiben.

24.11 Warum entstehen nach einem Firmware-Update doppelte MQTT-Messwerte?

Bei bestimmten Übertragungsverfahren, beispielsweise MQTT mit QoS 1, können Nachrichten erneut zugestellt werden. Ohne geeignete Identifikation und Duplikaterkennung können dadurch doppelte Historieneinträge entstehen. Stabile Datenpunktkennungen, Zeitstempel oder Sequenznummern können bei der eindeutigen Zuordnung helfen.

24.12 Kann ein Firmware-Update die Skalierung von Messwerten verändern?

Ja, wenn Konfigurationen migriert, Registerzuordnungen geändert oder Datentypen anders interpretiert werden. Deshalb sollten die relevanten Messpunkte vor und nach dem Update mit bekannten Referenzwerten und der freigegebenen Datenpunktkonfiguration verglichen werden.

24.13 Warum reicht es nicht aus, nach dem Update nur die Netzwerkverbindung zu prüfen?

Eine erfolgreiche Netzwerkverbindung bestätigt nicht automatisch die richtige Sensorabfrage, Skalierung, Zeitstempelung oder Datenübertragung bis zum Historian. Für eine vollständige Freigabe müssen repräsentative Messwerte und die relevante Datenverarbeitung geprüft werden.

24.14 Welche Rolle spielt die lokale Alarmierung während eines Firmware-Updates?

Wenn Alarme direkt im Gateway berechnet werden, können sie während eines Neustarts ausfallen. Notwendige Schutzfunktionen müssen daher auf Grundlage der Gefährdungsbewertung unabhängig verfügbar bleiben oder durch ein freigegebenes Ersatzverfahren abgesichert werden.

24.15 Sollte ich alle IIoT-Gateways gleichzeitig aktualisieren?

Bei größeren Anlagen ist ein gestaffelter Rollout häufig sinnvoller. Zunächst wird eine repräsentative Gerätegruppe aktualisiert und geprüft. Erst nach erfolgreicher Bewertung folgen weitere Gateways. Dadurch lassen sich mögliche Fehler früh erkennen und ihre Auswirkungen begrenzen.

24.16 Welche Sicherheitsanforderungen gelten für Firmware-Updates?

Wichtige Anforderungen sind die Verwendung vertrauenswürdiger Firmware, Integritäts- und Authentizitätsprüfung, kontrollierte Berechtigungen, geeignete Übertragungswege und nachvollziehbare Update-Protokolle. Für industrielle OT-Systeme sind außerdem die betrieblichen Risiken und die erforderlichen Freigabeprozesse zu berücksichtigen.

24.17 Wann ist ein Firmware-Update wirklich abgeschlossen?

Wenn das Gateway nach der Aktualisierung die vorgesehene Firmware verwendet und alle erforderlichen Funktionen erfolgreich geprüft wurden. Dazu gehören Feldkommunikation, Messdatenverarbeitung, Zeitstempel, Übertragung, Pufferung und gegebenenfalls Alarm- und Störungsfunktionen. Ein erfolgreich abgeschlossener Installationsdialog allein reicht nicht aus.

24.18 Welche Angaben benötigt ICS Schneider für die Planung?

Benötigt werden Gateway-Hersteller und Typ, Hardware- und Firmware-Version, verwendete Feldschnittstellen, Anzahl der Messpunkte, Erfassungsintervalle sowie die angeschlossenen IT- und OT-Systeme. Zusätzlich sind Anforderungen an Datenverfügbarkeit, zulässige Unterbrechung, lokale Pufferung, Alarmfunktionen, Fernzugriff und Cybersicherheit wichtig. Für die Update-Strategie werden außerdem Angaben zu Backup, Rollback, Wartungsfenstern, Wiederherstellungszeiten und erforderlichen Prüf- und Dokumentationsnachweisen benötigt.