Zeitstempel für IIoT-Messdaten: Sensor, SPS oder Gateway?

→ Produktkategorie: IIoT-Lösungen

 

Ein Messwert ohne verlässlichen Zeitbezug ist in einer IIoT-Anwendung häufig nur eingeschränkt nutzbar. Besonders deutlich wird das bei Störungen, kurzen Prozessereignissen oder der nachträglichen Ursachenanalyse: Zwei Systeme melden nahezu gleichzeitig eine Druckänderung, einen Motorschwingungsalarm und das Abschalten einer Maschine – aber welches Ereignis trat tatsächlich zuerst auf?

Entscheidend ist dabei nicht nur die Genauigkeit der Uhr. Ebenso wichtig ist, an welcher Stelle der Datenkette der Zeitstempel erzeugt wird.

Wird ein Messwert bereits im Sensor oder unmittelbar bei der Erfassung mit einem Zeitstempel versehen, bleibt sein ursprünglicher Messzeitpunkt auch dann erhalten, wenn die Daten erst später übertragen werden. Entsteht der Zeitstempel dagegen erst am Gateway oder sogar in der Cloud, enthält er zunächst nur die Information, wann der Wert dort angekommen ist.

Je größer und variabler die Kommunikationslatenz zwischen Messung und Zeitstempelerzeugung ist, desto schwieriger wird es, den tatsächlichen Ereigniszeitpunkt später zuverlässig zu rekonstruieren.

Für typische IIoT-Architekturen bietet ICS Schneider Lösungen vom Feldgerät über Edge-Gateways bis zur IT- beziehungsweise Cloud-Anbindung. Weitere Informationen finden Sie unter IIoT-Lösungen bei ICS Schneider.

Ein praktisches Beispiel für eine Sensor-Gateway-Architektur ist der Siemens SITRANS MS200 IIoT-Multisensor, der bei ICS für Vibrations- und Temperaturüberwachung in Kombination mit dem SITRANS CC220 Gateway geführt wird. Für die Digitalisierung von Wägesignalen steht außerdem die Siemens IIoT-Wägeelektronik 7MH4647-0KK00-0AA2 für Anwendungen mit dem SIMATIC IOT2050 zur Verfügung.

Warum ist der Zeitstempel bei IIoT-Messdaten so wichtig?

In vielen einfachen Anwendungen genügt es zunächst, einen aktuellen Messwert im Dashboard anzuzeigen.

Sobald die Daten jedoch für:

• Störungsanalyse,
• Condition Monitoring,
• Qualitätssicherung,
• Chargenrückverfolgung,
• Energieanalyse,
• Predictive Maintenance,
• Alarmkorrelation

verwendet werden sollen, wird der tatsächliche Messzeitpunkt entscheidend.

Beispiel

Eine Maschine meldet innerhalb weniger Sekunden:

• steigende Motorschwingung,
• Druckabfall,
• Drehzahlabfall,
• Not-Aus beziehungsweise Anlagenstopp.

Für die Ursachenanalyse muss bekannt sein:

Welches Ereignis trat zuerst auf?

Wenn alle Daten lediglich den Zeitpunkt erhalten, zu dem sie in der Cloud gespeichert wurden, kann die ursprüngliche Reihenfolge durch unterschiedliche Übertragungszeiten bereits verfälscht sein.

Welche Zeitpunkte existieren in einer Messdatenkette?

Ein einzelner Messwert kann während seiner Übertragung mehrere unterschiedliche Zeitpunkte durchlaufen.

Zeitpunkt	Bedeutung
Messzeitpunkt	Zeitpunkt, an dem der physikalische Wert tatsächlich erfasst wurde
Sensor-Zeitstempel	Zeitpunkt, den das Feldgerät dem Messwert zuordnet
SPS-Erfassungszeit	Zeitpunkt, zu dem die Steuerung den Wert übernimmt
Gateway-Zeit	Zeitpunkt, zu dem das Edge-Gateway den Wert empfängt oder ausliest
Publish-Zeit	Zeitpunkt, zu dem eine Nachricht beispielsweise per MQTT versendet wird
Broker-/Server-Zeit	Zeitpunkt der Annahme durch ein übergeordnetes System
Speicherzeit	Zeitpunkt, zu dem der Datensatz in Historian, Datenbank oder Cloud gespeichert wird

Diese Zeitpunkte können bei einer schnellen lokalen Ethernet-Verbindung nur wenige Millisekunden auseinanderliegen.

Bei:

• Funkverbindungen,
• Mobilfunk,
• LoRaWAN,
• zyklischem Modbus-Polling,
• Gateway-Buffering,
• Netzwerkstörungen

kann die Differenz jedoch erheblich größer und vor allem variabel werden.

Zeitstempel direkt im Sensor erzeugen

Die zeitlich sauberste Lösung besteht grundsätzlich darin, den Zeitstempel möglichst nah an der tatsächlichen Messwerterfassung zu erzeugen.

Vorteil

Der Zeitstempel beschreibt dann tatsächlich den Zeitpunkt der Messung beziehungsweise des Ereignisses.

Nachfolgende:

• Kommunikationslatenz,
• Warteschlangen,
• Gateway-Verarbeitung,
• Cloud-Übertragung

verändern diesen ursprünglichen Zeitbezug nicht mehr.

Voraussetzung

Der Sensor benötigt:

• eine eigene Uhr beziehungsweise geeignete Zeitbasis,
• eine Synchronisationsmöglichkeit oder ausreichend stabile Uhr,
• ein Protokoll, das den Zeitstempel zusammen mit dem Messwert übertragen kann.

Ein Sensor-Zeitstempel ist nicht automatisch besser

Besitzt ein Feldgerät zwar eine Echtzeituhr, wird diese jedoch nicht korrekt synchronisiert, kann der Zeitstempel systematisch falsch sein.

Ein Gateway mit sauber synchronisierter Uhr kann dann in der Praxis zuverlässiger sein als ein vermeintlich präziser, aber driftender Sensor-Zeitstempel.

Die beste Position für den Zeitstempel ist möglichst nah an der Datenquelle – aber nur dann, wenn die dort verwendete Zeitbasis zuverlässig ist.

Zeitstempel in der SPS erzeugen

In vielen Maschinen wird der eigentliche Prozess bereits durch eine SPS erfasst.

Dann kann die Steuerung eine sinnvolle Stelle für die Zeitstempelerzeugung sein.

Das ist besonders geeignet, wenn

• mehrere Signale in derselben SPS zusammenlaufen,
• digitale Ereignisse miteinander korreliert werden sollen,
• die SPS-Uhr zentral synchronisiert wird,
• der Sensor selbst keinen Zeitstempel liefert.

Zu beachten ist jedoch

Auch der SPS-Zeitstempel beschreibt nicht zwingend den physikalischen Messzeitpunkt.

Zwischen:

Sensorerfassung

und:

SPS-Verarbeitung

können bereits entstehen:

• Sensorfilterzeit,
• Buszyklus,
• I/O-Update-Zeit,
• SPS-Zykluszeit.

Für normale Maschinenüberwachung kann dieser Unterschied unkritisch sein.

Für sehr schnelle Ereignisse muss dagegen die gesamte zeitliche Signalkette betrachtet werden.

Zeitstempel am Gateway erzeugen

Besonders bei Brownfield-Anlagen besitzen viele vorhandene Feldgeräte überhaupt keine eigene Zeitstempelfunktion.

Ein Edge-Gateway kann dann den Messwert beim Einlesen mit einer Zeitinformation versehen.

Eine typische Architektur lautet:

Sensor → Feldbus → Edge-Gateway → MQTT/HTTPS/OPC UA → IT/Cloud

Vorteile

• zentrale Zeitbasis für viele Feldgeräte,
• NTP-Synchronisation vergleichsweise einfach umsetzbar,
• einheitliches Datenmodell,
• Brownfield-Sensoren ohne Echtzeituhr nutzbar,
• lokales Puffern mit Zeitstempel möglich.

Der entscheidende Nachteil

Der Gateway-Zeitstempel kennzeichnet zunächst:

Zeitpunkt des Einlesens beziehungsweise Empfangens

und nicht zwingend:

Zeitpunkt der eigentlichen Messung

Bei zyklischem Polling

fragt ein Gateway beispielsweise nacheinander:

• Sensor A,
• Sensor B,
• Sensor C,
• Sensor D

ab.

Die vier Werte können physikalisch nahezu gleichzeitig entstanden sein, erhalten jedoch aufgrund der Abfragereihenfolge unterschiedliche Gateway-Zeitstempel.

Oder umgekehrt: Ein Sensor kann einen intern älteren Wert liefern, der erst später abgefragt wird.

Bei Gateway-Zeitstempeln muss deshalb dokumentiert werden, ob der Zeitwert eine Messzeit, Abfragezeit oder Empfangszeit beschreibt.

Warum der Cloud-Empfangszeitpunkt meist nicht ausreicht

Der späteste mögliche Ort für eine Zeitstempelerzeugung ist das übergeordnete IT- beziehungsweise Cloud-System.

Für reine Statusanzeigen kann dies ausreichen.

Für technische Ereignisanalysen ist es jedoch häufig problematisch.

Zwischen Messung und Cloud können liegen

• Sensorzyklus,
• Feldbusübertragung,
• Gateway-Verarbeitung,
• lokaler Datenpuffer,
• Broker,
• WAN oder Mobilfunk,
• Cloud-Ingestion,
• Datenbankwarteschlange.

Eine Verzögerung an nur einer dieser Stellen verändert den Cloud-Empfangszeitpunkt.

Der physikalische Messzeitpunkt bleibt dagegen unverändert.

Sensor, SPS oder Gateway: Welche Variante ist besser?

Zeitstempel entsteht bei	Vorteil	Beachten
Sensor	sehr nah am tatsächlichen Messzeitpunkt	Sensoruhr muss synchronisiert und zuverlässig sein
SPS	gute Korrelation vieler Maschinensignale	I/O-, Bus- und SPS-Zyklus liegen bereits vor dem Zeitstempel
Gateway	ideal für Brownfield und einheitliche Zeitbasis	Zeitpunkt entspricht häufig Empfang oder Polling
Cloud/Server	technisch einfach	Netzwerk- und Buffer-Latenzen verfälschen den Ereigniszeitpunkt

Faustregel

Den Zeitstempel so nah wie sinnvoll an der Entstehung des Messwertes erzeugen und ihn anschließend unverändert durch die gesamte Datenkette weiterreichen.

Übertragungslatenz und Jitter verstehen

Latenz beschreibt die Verzögerung zwischen zwei Punkten der Datenkette.

Wird ein Wert am Sensor zum Zeitpunkt:

tsource

erfasst und am Gateway zum Zeitpunkt:

tgateway

empfangen, kann vereinfacht betrachtet werden:

Δt = tgateway − tsource

Diese beobachtete Differenz enthält jedoch nicht ausschließlich Kommunikationslatenz.

Sie kann sich zusammensetzen aus

• Sensorverarbeitungszeit,
• Buswartezeit,
• Übertragungszeit,
• Gateway-Verarbeitung,
• Unterschied zwischen den beiden Uhren.

Nur bei ausreichend synchronisierten Uhren kann aus der Differenz der Zeitstempel sinnvoll auf die tatsächliche Latenz geschlossen werden.

Jitter

bezeichnet die zeitliche Schwankung dieser Verzögerung.

Beispielsweise:

10 ms → 11 ms → 37 ms → 9 ms

Eine konstante Latenz lässt sich oft berücksichtigen.

Starker Jitter ist für die nachträgliche Ereignissortierung wesentlich problematischer.

Was passiert bei Buffering und Verbindungsunterbrechungen?

Ein gutes Edge-System sollte Messwerte bei einer unterbrochenen Verbindung lokal zwischenspeichern können.

Die Daten werden später übertragen, sobald:

• Netzwerk,
• Broker,
• Server

wieder verfügbar sind.

Genau hier zeigt sich der Vorteil eines Quell-Zeitstempels

Angenommen, ein Messwert entsteht um:

10:15:01

.

Das Gateway besitzt aber erst um:

10:15:31

wieder eine Verbindung zur Cloud.

Mit ursprünglichem Zeitstempel

wird der Datensatz weiterhin gespeichert als:

Messzeit = 10:15:01

Nur mit Cloud-Empfangszeit

würde er dagegen erscheinen als:

Zeit = 10:15:31

und damit zeitlich um 30 Sekunden verschoben.

Bei vielen gepufferten Werten

kann es noch problematischer werden.

30 Messwerte aus 30 Sekunden werden möglicherweise innerhalb weniger hundert Millisekunden an die Cloud übertragen.

Würde erst dort gestempelt, sähe es aus, als seien alle Werte nahezu gleichzeitig entstanden.

Store-and-forward-Systeme sollten deshalb den ursprünglichen Erfassungszeitpunkt zusammen mit dem Messwert puffern.

Warum Zeitstempel allein die Ereignisreihenfolge nicht immer sichern

Auch korrekt synchronisierte Zeitstempel lösen nicht jedes Problem.

Zwei Ereignisse können denselben Zeitstempel erhalten

Beispielsweise wenn:

• die Zeitauflösung nur 1 ms beträgt,
• mehrere Ereignisse innerhalb derselben Millisekunde auftreten.

Außerdem können

• Pakete verzögert werden,
• Nachrichten wiederholt werden,
• Daten aus mehreren Quellen zusammenlaufen,
• Uhren geringfügig voneinander abweichen.

Für eine belastbare Ereignisrekonstruktion sollte deshalb nicht ausschließlich nach einem Zeitstempel sortiert werden.

Sequenznummern und Event-IDs ergänzen

Eine robuste Telemetrie-Nachricht kann neben dem Messwert zusätzliche Metadaten enthalten.

Beispielsweise:

value = 7.42

sourceTimestamp = 2026-08-25T10:15:01.125Z

sequence = 583214

quality = good

deviceId = pressure_017

Eine Sequenznummer hilft bei

• Erkennung verlorener Datensätze,
• Erkennung von Duplikaten,
• Rekonstruktion der Reihenfolge innerhalb einer Quelle,
• Prüfung nach einer Offline-Phase.

Eine eindeutige Event-ID

kann zusätzlich verhindern, dass dieselbe Nachricht nach einer Wiederholung mehrfach gespeichert beziehungsweise ausgewertet wird.

Zeitstempel und Sequenznummer erfüllen unterschiedliche Aufgaben und ergänzen sich deshalb sinnvoll.

SourceTimestamp und ServerTimestamp bei OPC UA

OPC UA unterscheidet bei einem Datenwert ausdrücklich zwischen verschiedenen Zeitinformationen.

SourceTimestamp

Der SourceTimestamp beschreibt den Zeitstempel, der dem Wert von seiner Datenquelle zugeordnet wurde.

Er soll möglichst nah an der Quelle des Messwertes entstehen.

ServerTimestamp

Der ServerTimestamp beschreibt dagegen den Zeitpunkt, zu dem der OPC-UA-Server den Wert erhalten hat beziehungsweise wusste, dass dieser Wert gültig ist.

Das ist für IIoT-Architekturen besonders hilfreich

Ein Wert kann beispielsweise besitzen:

SourceTimestamp = 10:15:01.125

und:

ServerTimestamp = 10:15:01.142

.

Damit bleiben:

• ursprünglicher Datenzeitpunkt,
• Verarbeitungszeitpunkt des Servers

voneinander unterscheidbar.

Wird ein OPC-UA-Wert weitergereicht

sollte der ursprüngliche SourceTimestamp nicht durch einen späteren Gateway-Zeitstempel ersetzt werden.

Zusätzliche Zeitinformationen können separat ergänzt werden.

Zeitstempel und Reihenfolge bei MQTT

MQTT eignet sich sehr gut für die Übertragung von Telemetriedaten zwischen Edge- und IT-Systemen.

Der eigentliche fachliche Zeitstempel des Messwertes sollte dabei im Datenmodell beziehungsweise Payload enthalten sein, wenn er für die Anwendung benötigt wird.

Beispiel

{"value":7.42,"timestamp":"2026-08-25T10:15:01.125Z","seq":583214}

MQTT besitzt Regeln zur Nachrichtenreihenfolge

Bei geordneten Topics werden Nachrichten eines Publishers unter den entsprechenden Bedingungen in Veröffentlichungsreihenfolge weitergereicht.

Das bedeutet jedoch nicht, dass der MQTT-Broker den tatsächlichen physikalischen Messzeitpunkt kennt.

Außerdem können bei Wiederholungen

beispielsweise bei QoS 1 nach einer Verbindungsunterbrechung Duplikate auftreten.

Deshalb sollten Anwendungen, bei denen eine eindeutige historische Reihenfolge wichtig ist, zusätzlich mit:

• Source Timestamp,
• Sequenznummer,
• gegebenenfalls Event-ID

arbeiten.

NTP zur Zeitsynchronisation

NTP – Network Time Protocol – ist ein weit verbreitetes Verfahren zur Synchronisation von Systemuhren über IP-Netzwerke.

Für viele typische IIoT-Anwendungen ist NTP eine sinnvolle Lösung.

Typische Anwendungen sind

• Trendaufzeichnung,
• Energieüberwachung,
• Condition Monitoring,
• Produktionsdaten,
• normale Alarmkorrelation.

Wichtig ist eine gemeinsame Zeitquelle

Idealerweise synchronisieren sich:

• SPS,
• Gateways,
• Server,
• relevante Sensoren

auf eine kontrollierte Zeitreferenz.

Nicht nur die Uhrzeit konfigurieren

Zusätzlich sollte überwacht werden, ob die Synchronisation tatsächlich funktioniert.

Ein Gateway kann beispielsweise technisch erreichbar sein und weiterhin Daten übertragen, obwohl sein NTP-Dienst ausgefallen ist.

Die Messwerte wären dann vollständig vorhanden, ihre zeitliche Zuordnung könnte aber zunehmend driften.

Wann PTP sinnvoll wird

PTP – Precision Time Protocol – wird eingesetzt, wenn eine deutlich engere zeitliche Synchronisation zwischen Geräten erforderlich ist.

Das kann relevant sein bei

• sehr schnellen Maschinenereignissen,
• hochaufgelöster Zustandsüberwachung,
• elektrischen Ereignissen,
• verteilten Messsystemen,
• Anwendungen, bei denen die Reihenfolge innerhalb sehr kleiner Zeitfenster entscheidend ist.

PTP ist jedoch keine reine Softwareeinstellung

Die erreichbare Synchronisationsqualität hängt unter anderem ab von:

• Geräteunterstützung,
• Netzwerkhardware,
• Timestamping-Verfahren,
• Netzwerktopologie,
• PTP-Profil beziehungsweise Konfiguration.

Ein System sollte daher nicht allein deshalb als hochpräzise zeitsynchron bezeichnet werden, weil irgendwo im Netzwerk PTP aktiviert wurde.

Anforderung	Typischer Ansatz
normales IIoT-Monitoring	NTP häufig ausreichend
historische Trends über Sekunden/Minuten	NTP
enge Ereigniskorrelation vieler Geräte	NTP-Qualität prüfen, gegebenenfalls PTP
sehr schnelle verteilte Messungen	PTP beziehungsweise systemspezifische Synchronisation prüfen

UTC, Zeitzone und Sommerzeit richtig behandeln

Für die interne Speicherung von Messdaten ist UTC in der Regel die robusteste Zeitbasis.

Problem lokaler Zeit

Bei der Umstellung von Sommer- auf Winterzeit kann beispielsweise eine lokale Uhrzeit zweimal vorkommen.

Ein Ereignis um:

02:30 Uhr

ist dann ohne zusätzliche Information möglicherweise nicht eindeutig.

Empfehlung

Intern speichern:

UTC

und die lokale Zeitzone erst bei:

• Dashboard,
• Report,
• Benutzeroberfläche

anwenden.

Geeignet ist beispielsweise

2026-08-25T10:15:01.125Z

Die Endung:

Z

kennzeichnet UTC.

Clock Drift und Zeitsprünge erkennen

Keine reale Uhr läuft dauerhaft vollkommen fehlerfrei.

Ohne Synchronisation entsteht Clock Drift.

Beispiel

Gateway A läuft täglich:

+1,5 s

vor.

Gateway B läuft täglich:

−0,8 s

nach.

Bereits nach wenigen Tagen können Ereignisse zeitlich falsch sortiert werden.

Auch Korrekturen selbst können problematisch sein

Wenn eine Systemuhr plötzlich vor- oder zurückgesetzt wird, kann ein reines Sortieren nach der lokalen Uhrzeit zu:

• Zeitsprüngen,
• doppelten Zeitwerten,
• scheinbar rückwärts laufenden Ereignissen

führen.

Für lokale Zeitdauern

ist deshalb häufig zusätzlich ein monotoner Systemzähler sinnvoll.

Für die Korrelation zwischen verschiedenen Geräten bleibt dagegen eine gemeinsame UTC-basierte Zeitreferenz erforderlich.

Abtastrate und Zeitstempelauflösung unterscheiden

Eine hohe Anzahl Nachkommastellen im Zeitstempel bedeutet nicht automatisch, dass der Messwert tatsächlich mit dieser zeitlichen Genauigkeit erfasst wurde.

Beispiel

Ein Sensor aktualisiert seinen Messwert nur alle:

1 s

.

Das Gateway versieht den abgefragten Wert jedoch mit einem Zeitstempel mit:

1 µs Auflösung

.

Damit ist lediglich der Empfangszeitpunkt hochauflösend dargestellt.

Der tatsächliche Messzeitpunkt ist dadurch nicht plötzlich auf eine Mikrosekunde bekannt.

Zu unterscheiden sind daher

• Sensor-Abtastrate,
• Signalfilterung,
• Kommunikationszyklus,
• Zeitstempelauflösung,
• Synchronisationsgenauigkeit.

Zeitstempelauflösung und tatsächliche Zeitgenauigkeit sind nicht dasselbe.

Welche Zeitinformationen sollten gespeichert werden?

Für anspruchsvollere IIoT-Projekte ist es sinnvoll, mehr als nur einen einzelnen Zeitwert zu speichern.

Datenfeld	Zweck
value	eigentliche Messgröße
sourceTimestampUtc	ursprünglicher Mess- oder Ereigniszeitpunkt
gatewayTimestampUtc	Empfang beziehungsweise Verarbeitung am Edge
sequenceNumber	Reihenfolge innerhalb der Quelle
quality	Gültigkeit beziehungsweise Messwertstatus
deviceId	eindeutige Datenquelle
bootId oder sessionId	Erkennung eines Geräte-Neustarts beziehungsweise neuen Datenzyklus

Optional kann zusätzlich gespeichert werden

• Cloud-Empfangszeit,
• Broker-Zeit,
• Synchronisationsstatus der Quelle,
• geschätzte Zeitunsicherheit.

Damit lässt sich später wesentlich besser beurteilen, ob eine zeitliche Abweichung durch den Prozess oder durch die Datenübertragung entstanden ist.

Praxisbeispiel: Störungsanalyse an einer Maschine

Eine Produktionsmaschine besitzt drei getrennte Messsysteme:

• Vibrationssensor,
• Drucksensor,
• SPS mit Motordrehzahl.

Um:

14:22:17

stoppt die Maschine unerwartet.

Cloud-Empfangszeiten

Im Historian erscheint:

14:22:17.430 – Druckabfall

14:22:17.440 – starke Vibration

14:22:17.455 – Drehzahlabfall

Danach würde zunächst der Druckabfall als Ursache vermutet.

Source Timestamps

Die ursprünglichen Zeitstempel zeigen jedoch:

14:22:17.310 – starke Vibration

14:22:17.365 – Drehzahlabfall

14:22:17.390 – Druckabfall

Ursache der falschen Reihenfolge

Die Vibrationsdaten wurden über einen Kommunikationsweg mit höherer Latenz übertragen.

Der Druckwert erreichte das übergeordnete System deshalb zuerst, obwohl das physikalische Ereignis später stattfand.

Für die Ursachenanalyse ist der Source Timestamp entscheidend und nicht die Reihenfolge, in der Nachrichten im zentralen System eintreffen.

Praxisbeispiel: Gateway 30 Sekunden offline

Ein Edge-Gateway erfasst alle:

1 s

einen Messwert.

Die Verbindung zum MQTT-Broker fällt für:

30 s

aus.

Richtige Umsetzung

Das Gateway speichert für jeden Wert:

• Messwert,
• ursprünglichen Zeitstempel,
• Sequenznummer.

Nach Wiederherstellung der Verbindung werden alle 30 Datensätze übertragen.

Die Zeitreihe bleibt korrekt.

Problematische Umsetzung

Das Gateway speichert nur die Messwerte.

Beim späteren Versand erzeugt es jeweils einen neuen Zeitstempel.

Die gesamte Offline-Phase erscheint anschließend als kurzer Messwertblock zum Zeitpunkt des Wiederverbindens.

Eine korrekte Trendanalyse wäre dann nicht mehr möglich.

Brownfield-Anlagen ohne Zeitstempel integrieren

Viele vorhandene Maschinen besitzen:

• 4–20-mA-Sensoren,
• Modbus-RTU-Geräte,
• ältere SPS,
• einfache Zähler

ohne eigene Zeitstempelfunktion.

Ein Edge-Gateway ist hier häufig die praktikabelste Lösung

Es kann:

• Geräte zyklisch auslesen,
• Werte skalieren,
• mit einem Gateway-Zeitstempel versehen,
• lokal puffern,
• in ein einheitliches Datenmodell überführen,
• per MQTT beziehungsweise HTTPS weiterleiten.

Wichtig ist die korrekte Semantik

Ein Gateway-Zeitstempel sollte dann nicht als:

exakter Sensor-Messzeitpunkt

bezeichnet werden.

Korrekt wäre beispielsweise:

Erfassungszeit am Gateway

oder:

Polling Timestamp

.

Diese klare Unterscheidung verhindert später falsche Interpretationen der Datenqualität.

Typische Fehlerbilder

Beobachtung	Mögliche Ursache	Sinnvolle Prüfung
Ereignisse erscheinen in falscher Reihenfolge	unterschiedliche Kommunikationslatenzen	Source Timestamp statt Empfangszeit vergleichen
Messwerte erscheinen nach Netzwerkausfall gleichzeitig	Zeitstempel erst beim Wiederübertragen erzeugt	Store-and-forward-Konfiguration prüfen
Zwei Gateways driften zeitlich auseinander	NTP fehlt oder funktioniert nicht	Zeitsynchronisationsstatus prüfen
Messdaten springen zeitlich zurück	Systemuhr wurde korrigiert	NTP-Log und Clock-Verhalten prüfen
Sommerzeit erzeugt doppelte Uhrzeiten	lokale Zeit gespeichert	intern UTC verwenden
Gateway-Zeitstempel unterscheiden sich systematisch zwischen Sensoren	serielles Polling	Abfragezyklus und Registerstruktur prüfen
Sehr präziser Zeitstempel, aber schlechte Ereigniskorrelation	Zeitauflösung mit tatsächlicher Genauigkeit verwechselt	Sensor-Abtastrate und Synchronisation prüfen
Einige Datenpunkte fehlen nach Offline-Phase	Pufferüberlauf oder Paketverlust	Sequenznummern auswerten
Doppelte Datensätze nach MQTT-Reconnect	Nachricht erneut übertragen	Sequenznummer oder Event-ID auswerten
Source Timestamp älter als Gateway-Zeit um stark wechselnde Werte	Jitter beziehungsweise variable Pufferung	Latenzstatistik bilden
Sensor und SPS widersprechen sich bei Ereignisfolge	unterschiedliche Zeitquellen	Synchronisationsarchitektur prüfen
Gateway zeigt richtige Uhrzeit, Historian trotzdem falsche Zeit	Zeitzonen- beziehungsweise UTC-Konvertierung	gesamte Datenkette prüfen
Zeitstempel fehlen nur bei einzelnen Feldgeräten	Quellprotokoll liefert keine Zeitinformation	Gateway-Erfassungszeit separat kennzeichnen

Empfohlener Planungs- und Inbetriebnahmeablauf

1. Messaufgabe definieren: Klären, ob Trends, Alarmierung oder exakte Ereignisreihenfolgen benötigt werden.
2. Erforderliche Zeitgenauigkeit bestimmen: Sekunden, Millisekunden oder kleiner festlegen.
3. Abtastraten erfassen: Sensor- und SPS-Aktualisierungszeiten kennen.
4. Datenquellen inventarisieren: Sensoren, SPS, Gateways und Server aufnehmen.
5. Timestamp-Fähigkeit prüfen: Feststellen, welche Geräte einen Source Timestamp bereitstellen.
6. Zeitstempelquelle definieren: Sensor, SPS oder Gateway gezielt auswählen.
7. Semantik festlegen: Messzeit, Empfangszeit und Speicherzeit eindeutig unterscheiden.
8. Zeitquelle definieren: Zentralen NTP- beziehungsweise bei Bedarf PTP-Ansatz planen.
9. Zeitzonenstrategie festlegen: Intern vorzugsweise UTC verwenden.
10. Synchronisationsstatus überwachen: Ausfall der Zeitquelle erkennbar machen.
11. Gateway-Polling analysieren: Abfragezyklen und dadurch entstehende Zeitunsicherheit berücksichtigen.
12. Buffering definieren: Verhalten bei Netzwerkausfall festlegen.
13. Original-Zeitstempel erhalten: Beim Weiterleiten nicht überschreiben.
14. Sequenznummer vorsehen: Fehlende und doppelte Messwerte erkennbar machen.
15. Qualitätsstatus übertragen: Ungültige oder unsichere Werte kennzeichnen.
16. OPC-UA-Zeitfelder prüfen: SourceTimestamp und ServerTimestamp korrekt verwenden.
17. MQTT-Datenmodell definieren: Timestamp und Sequenznummer in Payload beziehungsweise Datenmodell einplanen.
18. Offline-Test durchführen: Netzwerk absichtlich unterbrechen und Wiederübertragung prüfen.
19. Clock-Drift-Test durchführen: Zeitabweichungen mehrerer Geräte vergleichen.
20. Ereignisreihenfolge testen: Definierte Ereignisse an mehreren Quellen auslösen.
21. Historian prüfen: Sicherstellen, dass Source Time und Ingestion Time nicht verwechselt werden.
22. Dokumentation erstellen: Zeitstempelquelle und Zeitgenauigkeit jeder Messgröße festhalten.

Passende IIoT-Lösungen bei ICS Schneider

IIoT-Lösungen – vom Feldgerät bis zur Cloud

Unter IIoT-Lösungen bei ICS Schneider werden herstellerübergreifende Architekturen für die Anbindung von Sensorik, Steuerungen und Feldgeräten an Edge-, SCADA- und Cloud-Systeme zusammengefasst.

Typische Schnittstellen und Protokolle sind:

• RS-485 / Modbus RTU,
• HART,
• IO-Link,
• OPC UA,
• Ethernet,
• MQTT,
• HTTPS.

Eine typische IIoT-Kette lautet:

Feldgerät → Edge-Gateway → MQTT/HTTPS → SCADA/Cloud/BI

Siemens SIMATIC IOT2050 – Edge-Gateway-Plattform

Das SIMATIC IOT2050 ist eine industrielle Gateway-Plattform zur Erfassung, Verarbeitung, Harmonisierung, lokalen Speicherung und Weiterleitung von Maschinen- und Produktionsdaten.

Damit eignet sich die Plattform insbesondere für Brownfield-Architekturen, in denen bestehende:

• Feldgeräte,
• Steuerungen,
• serielle Schnittstellen,
• Ethernet-Datenquellen

in eine übergeordnete IIoT-Datenstruktur integriert werden sollen.

Welche konkreten Funktionen für:

• Timestamping,
• NTP beziehungsweise PTP,
• OPC UA,
• MQTT,
• lokales Buffering

zur Verfügung stehen, hängt von der verwendeten Hardware-, Betriebssystem- und Softwarekonfiguration ab und sollte projektspezifisch geprüft werden.

Siemens SITRANS MS200 – IIoT-Multisensor

Der Siemens SITRANS MS200 ist ein drahtloser IIoT-Sensor für:

• Vibration,
• Temperatur.

ICS beschreibt das Gerät für den Betrieb in Kombination mit dem SITRANS CC220 Gateway.

Die Architektur:

SITRANS MS200 → SITRANS CC220 → übergeordnetes Monitoring

ist ein gutes Beispiel dafür, warum in einer IIoT-Lösung klar definiert werden muss, an welcher Stelle Messwerte ihren maßgeblichen Zeitstempel erhalten.

Siemens IIoT-Wägeelektronik für SIMATIC IOT2050

Die IIoT-Wägeelektronik 7MH4647-0KK00-0AA2 dient zum Anschluss einer Wägezelle beziehungsweise DMS-Vollbrücke mit:

1 … 4 mV/V

und ist für die Nutzung mit dem SIMATIC IOT2050 vorgesehen.

Eine entsprechende Architektur kann beispielsweise lauten:

Wägezelle → Wägeelektronik → SIMATIC IOT2050 → übergeordnetes System

Bei einer solchen Datenkette sollte ebenfalls festgelegt werden, ob der Zeitstempel:

• bei der eigentlichen Messwerterfassung,
• bei der digitalen Verarbeitung,
• am Gateway

entsteht.

Fazit

Für zuverlässige IIoT-Zeitreihen reicht es nicht aus, jedem Messwert irgendeine Uhrzeit zuzuordnen.

Der Source Timestamp ist der wichtigste Zeitbezug

Für Ereignisanalysen sollte der Zeitpunkt der tatsächlichen Messung beziehungsweise der frühestmöglichen Erfassung erhalten bleiben.

Der Zeitstempel sollte möglichst nahe an der Quelle entstehen

Sensor oder SPS sind besonders geeignet, wenn dort eine zuverlässige und synchronisierte Zeitbasis verfügbar ist.

Gateway-Timestamping ist für Brownfield sehr nützlich

Es ermöglicht auch bei älteren Sensoren eine konsistente zeitliche Einordnung. Der Wert beschreibt dann jedoch häufig den Empfangs- beziehungsweise Abfragezeitpunkt.

Cloud-Zeit ist keine Messzeit

Netzwerklatenz, Buffering und Wiederholungen können die Empfangszeit erheblich vom tatsächlichen Ereigniszeitpunkt entfernen.

Original-Zeitstempel müssen beim Buffering erhalten bleiben

Andernfalls gehen während einer Offline-Phase die tatsächlichen Zeitabstände der Messwerte verloren.

Zeitstempel allein reichen nicht immer aus

Sequenznummern, Event-IDs und Qualitätsinformationen helfen, Duplikate, Paketverlust und Reihenfolgeprobleme zu erkennen.

NTP oder PTP müssen zur Anwendung passen

NTP ist für viele klassische IIoT-Anwendungen ausreichend. Für sehr enge Ereigniskorrelationen muss eine präzisere Synchronisationsarchitektur wie PTP gegebenenfalls projektspezifisch geprüft werden.

UTC vereinfacht die Datenhaltung

Zeitzonen und Sommerzeit sollten vorzugsweise erst bei der Darstellung berücksichtigt werden.

Für die Praxis gilt

Messanforderung definieren → tatsächlichen Messzeitpunkt bestimmen → Timestamp-Fähigkeit der Datenquelle prüfen → Zeitstempel möglichst nahe an der Quelle erzeugen → gemeinsame Zeitreferenz einrichten → UTC verwenden → Original-Zeitstempel beim Weiterleiten erhalten → Gateway- und Empfangszeit separat speichern → Sequenznummer und Qualitätsstatus ergänzen → Offline-Buffering testen → Clock Drift überwachen → Ereignisreihenfolge praktisch verifizieren → Zeitarchitektur dokumentieren.

FAQ: Zeitstempel für IIoT-Messdaten

Warum brauchen IIoT-Messdaten einen Zeitstempel?

Damit Messwerte eindeutig einem Zeitpunkt zugeordnet und Trends, Störungen und Ereignisfolgen später korrekt analysiert werden können.

Wo sollte der Zeitstempel erzeugt werden?

Möglichst nahe an der tatsächlichen Messwerterfassung, sofern dort eine zuverlässige und synchronisierte Zeitbasis vorhanden ist.

Ist ein Sensor-Zeitstempel immer die beste Lösung?

Nicht automatisch. Eine schlecht synchronisierte Sensoruhr kann größere Fehler verursachen als ein sauber synchronisiertes Gateway.

Wann eignet sich die SPS für den Zeitstempel?

Wenn viele Maschinensignale dort zusammenlaufen und die SPS-Uhr zuverlässig synchronisiert wird.

Wann eignet sich ein Gateway-Zeitstempel?

Besonders bei Brownfield-Geräten ohne eigene Zeitstempelfunktion oder wenn viele unterschiedliche Feldprotokolle vereinheitlicht werden sollen.

Was ist der Nachteil eines Gateway-Zeitstempels?

Er beschreibt häufig den Zeitpunkt des Empfangs oder Pollings und nicht den exakten physikalischen Messzeitpunkt.

Kann ich einfach die Empfangszeit in der Cloud verwenden?

Für einfache Statusanzeigen möglicherweise. Für genaue Ereignisanalysen ist sie wegen Netzwerk- und Pufferlatenzen meist ungeeignet.

Was bedeutet Source Timestamp?

Er bezeichnet den Zeitstempel, der dem Messwert an beziehungsweise möglichst nahe seiner Datenquelle zugeordnet wurde.

Was bedeutet Server Timestamp bei OPC UA?

Er beschreibt den Zeitpunkt, zu dem der OPC-UA-Server den Wert erhalten hat beziehungsweise wusste, dass dieser Wert gültig ist.

Sollte ein Gateway einen vorhandenen Source Timestamp überschreiben?

Nein. Der ursprüngliche Source Timestamp sollte erhalten bleiben. Eine zusätzliche Gateway-Zeit kann separat gespeichert werden.

Was ist Übertragungslatenz?

Die zeitliche Verzögerung zwischen Datenentstehung und Ankunft an einem späteren Punkt der Kommunikationskette.

Was ist Jitter?

Jitter bezeichnet die zeitliche Schwankung der Übertragungslatenz.

Warum ist Jitter problematisch?

Weil die Reihenfolge eingehender Daten dann nicht zuverlässig der tatsächlichen Ereignisreihenfolge entsprechen muss.

Was passiert bei einer Offline-Verbindung?

Ein geeignetes Gateway kann Messwerte lokal puffern und nach Wiederherstellung der Verbindung nachträglich übertragen.

Was muss beim Buffering erhalten bleiben?

Insbesondere der ursprüngliche Zeitstempel sowie sinnvollerweise Sequenznummer und Qualitätsstatus.

Warum sollte ich eine Sequenznummer verwenden?

Damit fehlende, doppelte oder in anderer Reihenfolge eintreffende Datensätze erkannt werden können.

Kann MQTT Nachrichten doppelt übertragen?

Je nach QoS und Wiederholungsverhalten können Duplikate auftreten. Eine anwendungsseitige Sequenznummer beziehungsweise Event-ID erleichtert deren Erkennung.

Garantiert MQTT die physikalische Ereignisreihenfolge?

Nein. MQTT kann Nachrichten unter definierten Bedingungen in Veröffentlichungsreihenfolge transportieren, kennt aber nicht automatisch den ursprünglichen physikalischen Messzeitpunkt.

Was ist NTP?

NTP ist ein Netzwerkprotokoll zur Synchronisation von Systemuhren über IP-Netzwerke.

Ist NTP für IIoT ausreichend?

Für viele typische Monitoring-, Trend- und Energieanwendungen ja. Die tatsächlich erforderliche und erreichbare Zeitgenauigkeit muss jedoch zur Anwendung passen.

Was ist PTP?

PTP ist ein Verfahren für präzisere Zeitsynchronisation in verteilten Systemen und wird eingesetzt, wenn engere zeitliche Korrelationen erforderlich sind.

Ist PTP automatisch genauer, sobald es aktiviert wurde?

Nein. Die tatsächlich erreichbare Synchronisation hängt von Geräten, Netzwerkhardware, Timestamping, Topologie und Konfiguration ab.

Sollten Messdaten in lokaler Zeit gespeichert werden?

Für zentrale Datenhaltung ist UTC meist geeigneter. Die lokale Zeitzone kann anschließend bei der Darstellung angewendet werden.

Warum ist Sommerzeit problematisch?

Bei der Rückstellung der Uhr können lokale Uhrzeiten doppelt vorkommen und ohne Zeitzoneninformation mehrdeutig werden.

Was bedeutet Clock Drift?

Clock Drift ist die zunehmende Abweichung einer Geräteuhr von der tatsächlichen Referenzzeit.

Wie erkenne ich ausgefallene Zeitsynchronisation?

Der Synchronisationsstatus sollte überwacht und idealerweise alarmiert beziehungsweise protokolliert werden.

Ist eine Mikrosekundenanzeige automatisch mikrosekundengenau?

Nein. Auflösung des Zeitstempels, Abtastrate, Kommunikationslatenz und tatsächliche Synchronisationsgenauigkeit sind unterschiedliche Eigenschaften.

Welcher Zeitstempel ist für Trendaufzeichnungen relevant?

Vorzugsweise der tatsächliche Erfassungs- beziehungsweise Source Timestamp.

Welche Zeit sollte zusätzlich gespeichert werden?

Je nach Anwendung können Gateway-Empfangszeit und Cloud-Ingestion-Zeit hilfreich sein, um Kommunikationslatenzen zu analysieren.

Was ist bei Modbus-RTU-Sensoren ohne eigene Uhr zu tun?

Das Gateway oder die SPS kann beim Auslesen einen Zeitstempel vergeben. Dieser sollte dann eindeutig als Erfassungs- beziehungsweise Polling-Zeit gekennzeichnet werden.

Kann zyklisches Polling die Zeitstempel verfälschen?

Ja. Werden viele Sensoren nacheinander abgefragt, entstehen systematische zeitliche Unterschiede zwischen den Gateway-Zeitstempeln.

Welche Rolle spielt OPC UA bei Zeitstempeln?

OPC UA kann SourceTimestamp und ServerTimestamp getrennt transportieren und damit Datenquelle und Serververarbeitung zeitlich unterscheiden.

Welches Gateway eignet sich für Brownfield-IIoT?

Das SIMATIC IOT2050 ist eine industrielle Plattform für die Erfassung, Verarbeitung, lokale Speicherung und Weiterleitung von Maschinen- und Produktionsdaten. Die konkret verfügbaren Protokoll- und Zeitfunktionen hängen von der eingesetzten Softwarekonfiguration ab.

Welcher Siemens-Sensor eignet sich für IIoT Condition Monitoring?

Der SITRANS MS200 ist bei ICS als Bluetooth-IIoT-Multisensor für Vibrations- und Temperaturüberwachung in Kombination mit dem SITRANS CC220 Gateway gelistet.

Welche Lösung gibt es für IIoT-Wägedaten?

Die Siemens IIoT-Wägeelektronik 7MH4647-0KK00-0AA2 ist für den Anschluss einer Wägezelle beziehungsweise DMS-Vollbrücke und die Nutzung mit SIMATIC IOT2050 vorgesehen.

Wo finde ich weitere IIoT-Lösungen?

Weitere Informationen finden Sie unter IIoT-Lösungen bei ICS Schneider.