Wessen Uhr geht richtig? Zeitstempel, Zeitsynchronisation und die Maschinendaten, die niemand abgleicht

Die Kurzfassung: Jeder Datensatz, den eine Maschine erzeugt, beginnt mit einer Uhrzeit. In einem Werk mit Maschinen verschiedener Hersteller und Baujahre stammen diese Zeiten von mehreren Uhren: in den Steuerungen, in Gateways, in Servern und in dem Rechner, der den Wert gerade abgefragt hat. Selten vergleicht jemand diese Uhren. OEE, Ursachenanalyse, Rückverfolgbarkeit, Energie pro Teil und jedes Modell, das auf den Daten trainiert wird, setzen voraus, dass sie übereinstimmen.

Oft tun sie das nicht. Ein Wert kann exakt stimmen und trotzdem am falschen Zeitpunkt stehen. Um diese zweite Art von Fehler geht es in diesem Beitrag: woher sie kommt, was sie zerstört und welche Prüfungen ein Werk machen kann, bevor es einer Zeitleiste vertraut, die es nie getestet hat.

Der Realitätscheck aus der Fertigung

Eine Linie steht an einem Dienstag um 02:14. Morgens wird das Ereignisprotokoll geöffnet. Zuerst stoppte das Förderband, um 02:14:03. Die Presse meldete um 02:14:31 einen Stau. Die Schlussfolgerung liegt auf der Hand: Das Band blieb stehen, die Presse lief weiter und verklemmte sich. Die Instandhaltung wird zum Förderband geschickt.

Am Band ist nichts. Drei Wochen später tritt derselbe Stillstand wieder auf, und diesmal steht ein Bediener direkt an der Presse. Die Presse verklemmte sich zuerst. Das Band stoppte, weil die Presse es angewiesen hatte.

Die Steuerung der Presse hat ihre eigene Uhr. Seit der Inbetriebnahme hat sie niemand gestellt, und nichts synchronisiert sie. Inzwischen geht sie dem Server, der die Ereignisse des Förderbands stempelt, etwa eine halbe Minute vor. Jedes Ereignis der Presse wird rund eine halbe Minute zu spät gestempelt, sichtbar nur dort, wo zwei Maschinen zusammenwirken: als Ursache, die nach ihrer Wirkung auftaucht.

Niemand hat einen Fehler gemacht. Jede Uhr tat, wofür sie gebaut wurde. Das Werk hat nie gefragt, welche Uhr welche Zeile geschrieben hat.

Warum das Problem strukturell besteht

Im Büronetz ist Zeit gelöst. Server und Laptops fragen mehrmals täglich einen Zeitserver. Daraus folgt die naheliegende Annahme: Das Werk hat einen Zeitserver, also stimmt die Zeit.

Die Fertigung ist anders aufgebaut. Ein gewachsenes Werk enthält Steuerungen aus mehreren Jahrzehnten und von mehreren Herstellern, jede mit eigener Echtzeituhr, bei der Inbetriebnahme von Hand gestellt oder nie. Viele hingen nie an einem Netz, das Zeit verteilt. Manche haben keine Einstellung für einen Zeitserver, bei anderen wurde sie nie konfiguriert, weil die Maschine auch so lief.

Zudem durchlaufen Maschinendaten mehrere Schichten, bevor sie jemand sieht: eine Steuerung, vielleicht ein Gateway, ein Collector, ein Historian, eine Datenbank, ein Bericht. Jede Schicht kann eine eigene Zeit hinzufügen. Manche behalten die Zeit, die sie bekommen haben. Manche ersetzen sie durch den Moment, in dem die Daten ankamen. Manche behalten beide und reichen nur eine weiter.

Die Frage „Wann ist das passiert?“ hat also mehrere mögliche Antworten, und welche im Bericht landet, hängt davon ab, wie jemand eine Schicht eingerichtet hat, oft Jahre zuvor und nie dokumentiert.

Warum gerade jetzt

Zeit ist seit Jahrzehnten ein leises Problem. Vier Dinge machen es jetzt lauter.

Die Uhren wurden umgestellt, und das geht weiter. Am letzten Sonntag im Oktober wurden die Uhren zurückgestellt. Die Europäische Union hat 2018 vorgeschlagen, die Zeitumstellung abzuschaffen. Der Vorschlag liegt seit 2019 ohne Zeitplan im Rat, also hat jedes Werk mit Sommerzeit und Winterzeit im nächsten Frühjahr wieder einen 23-Stunden-Tag und im nächsten Herbst einen 25-Stunden-Tag.

Schaltsekunden laufen aus. Im Oktober 2026 hat die Generalkonferenz für Maß und Gewicht, das Vertragsorgan für das SI, eine Resolution verabschiedet, nach der UTC ab dem 20. Mai 2027 ohne Sprünge fortläuft und die Differenz zwischen Atomzeit und Erdrotation auf bis zu eine Stunde anwachsen darf. Seit Ende 2016 wurde keine Schaltsekunde mehr eingefügt, und nun wird auch keine mehr kommen. Für die meisten Werke entfällt ein seltener Sonderfall. Wer UTC mit GPS-Zeit mischt, die UTC 18 Sekunden voraus ist und keine Schaltsekunden kennt, sieht daran, dass „die Uhrzeit“ eine Konvention ist, keine Tatsache.

Satellitenzeit wird gestört. Eine Notiz des Rates der Europäischen Union vom Mai 2025 hält fest, dass im Oktober 2024 im estnischen Luftraum 1.150 Flugzeuge von Störung oder Täuschung der Satellitennavigation betroffen waren und im Januar 2025 1.085, bei den Nachbarländern mehr, und weist darauf hin, dass dieselben Satellitensignale zur Synchronisation von Telekommunikationsnetzen dienen. Auch in Industrienetzen sind Satellitenempfänger eine verbreitete Zeitquelle.

Die Regulierung verlangt übereinstimmende Uhren. Die Durchführungsverordnung (EU) 2024/2690 der Kommission zu NIS2 verpflichtet die dort erfassten Anbieter digitaler Dienste, soweit möglich für synchronisierte Zeitquellen in allen Systemen zu sorgen, damit sich Protokolle verschiedener Systeme korrelieren lassen. Hersteller fallen stattdessen unter das nationale NIS2-Recht, doch die unverbindliche Umsetzungshilfe der EU-Agentur für Cybersicherheit dazu (Juni 2025), die NTP oder PTP nennt, gilt weithin als Maßstab dafür, was „synchronisiert“ bedeutet. IEC 62443-3-3, die Industrienorm für Security, nach der viele Werke bereits arbeiten, hat eine eigene Anforderung an Zeitstempel. Regulierte Branchen verlangen seit Langem Audit-Trails mit Zeitstempel. Keine dieser Regeln nennt eine Toleranz in Millisekunden. Alle setzen voraus, dass sich zwei Protokolle nebeneinanderlegen lassen.

Und ein Datum weiter in der Zukunft steht schon in Herstellerhinweisen. Geräte, die die Zeit als vorzeichenbehaftete 32-Bit-Zahl der Sekunden seit 1970 zählen, laufen am 19. Januar 2038 um 03:14:07 UTC über. Der Sicherheitshinweis eines Steuerungsherstellers von 2025, aktualisiert im August 2026, beschreibt Steuerungen, bei denen einige Funktionen ausfallen, wenn ihr Datum auf diesen Tag gesetzt wird. 2038 liegt vor dem Ende der Nutzungsdauer vieler Anlagen, die dieses Jahr in Betrieb gehen.

Was ein Zeitstempel festhält

Ein Zeitstempel ist die Antwort auf eine Frage, und verschiedene Systeme beantworten verschiedene Fragen.

Wann wurde gemessen? Der Zeitpunkt, an dem Sensor oder Steuerung den Wert erfasst haben. Diesen braucht die Analyse.

Wann wurde gesendet? Der Zeitpunkt, an dem der Wert das Gerät oder Gateway verlassen hat.

Wann kam er an? Der Zeitpunkt, an dem ein Server, Collector oder eine Datenbank ihn empfangen hat.

Wann wurde geschrieben? Der Zeitpunkt der Speicherung. Nach einem Ausfall kann er Stunden nach der Messung liegen.

Die gängigen Industrieprotokolle beantworten diese Fragen unterschiedlich, manche gar nicht.

OPC UA kann an jedem Wert zwei Zeitstempel tragen. Die Spezifikation definiert einen Quellzeitstempel, den die Datenquelle setzt, und einen Serverzeitstempel, den Zeitpunkt, zu dem der Server den Wert empfangen hat oder wusste, dass er gültig ist. Jeder Server in einer Kette setzt seinen eigenen Serverzeitstempel. Fehlt der Quellzeitstempel, fallen viele Clients auf den Serverzeitstempel zurück, und der Datensatz wirkt ebenso präzise.

Sparkplug B, die industrielle Konvention für MQTT, trennt ebenfalls. Jede Nachricht trägt den Sendezeitpunkt, und jede Metrik kann den Erfassungszeitpunkt tragen. Außerdem definiert sie ein Kennzeichen für historische Daten, die die Referenz-Payload-Definition als Daten beschreibt, die „should not update real time tag“.

Reines MQTT hat keinen eigenen Zeitstempel. Die Zeit reist in der Nutzlast mit, in einer User Property oder gar nicht.

Modbus hat im Protokoll kein Zeitfeld. Die abfragende Seite stempelt jeden Messwert, wenn die Antwort zurückkommt, die Zeit enthält also das Abfrageintervall und die Netzlaufzeit. Eine geräteseitige Zeit gibt es nur, wenn der Hersteller sie in Register gelegt hat.

MTConnect-Agenten versehen jede Beobachtung, die sie vorhalten, mit einer UTC-Zeit. Meist stammt sie vom Adapter, der den Agenten speist, und das kann die Uhr der Steuerung sein oder auch nicht.

Zwei Werte, „in derselben Sekunde“ erfasst, können also zu verschiedenen Zeitpunkten gemessen, gesendet und empfangen worden sein, von Uhren, die nie verglichen wurden. Eine Datenbankspalte namens `timestamp` sagt nicht, welche der vier Fragen sie beantwortet. Die Protokolle selbst haben wir in MQTT, OPC UA oder Modbus? Der Architekten-Leitfaden für Industrieprotokolle 2026 verglichen. Die Zeit ist eine der Stellen, an denen die Unterschiede am meisten zählen.

Eine Beispielrechnung

Die Zahlen sind rund und zeigen den Mechanismus, keine typischen Werte eines Werks.

Drift. Die Echtzeituhr einer Steuerung läuft mit einem Schwingquarz. Ein Quarz mit einer Toleranz von 20 ppm kann bei Raumtemperatur etwa 1,7 Sekunden am Tag vor- oder nachgehen. Temperatur und Alterung kommen hinzu. Über 30 Tage ohne Korrektur sind das rund 52 Sekunden.

Nun zwei Maschinen an derselben Linie. Die eine wird von einem synchronisierten Server gestempelt. Die andere stempelt ihre Ereignisse selbst, mit einer unkorrigierten Uhr, die 52 Sekunden vorgeht. Zwei Ereignisse an diesen Maschinen, die weniger als 52 Sekunden auseinanderlagen, können jetzt in falscher Reihenfolge erscheinen. An einer Linie, an der ein Stillstand der einen Maschine binnen Sekunden einen Stillstand der nächsten auslöst, betrifft das fast jeden Fall, in dem die driftende Maschine zuerst stoppt, also genau den Fall, in dem sie die Ursache ist.

Abfrage. Ein Energiezähler an Modbus wird alle 10 Sekunden abgefragt. Ein Schwingungssensor an derselben Maschine meldet mit Quellzeitstempel. Eine Stromspitze und eine Schwingungsspitze, die im selben Augenblick auftraten, können bis zu 10 Sekunden auseinander erscheinen. Ein Modell, das mit genug solchen Fällen trainiert wird, lernt, dass die Schwingungsspitze zuerst kommt und der Strom bis zu 10 Sekunden später folgt, ein Vorlauf, den es nur im Abfragetakt gibt. Eine Spitze unterhalb des Abfrageintervalls wird womöglich nie erfasst.

Die 25-Stunden-Nacht. In der Nacht, in der die Uhren zurückgestellt werden, dauert eine von 22:00 bis 06:00 geplante Nachtschicht 9 Stunden statt 8. Eine Maschine mit 60 Teilen pro Stunde macht 540 Teile. Gemessen an geplanten 8 Stunden ergibt sich ein Leistungsgrad von 112,5 Prozent, was unmöglich ist. Im Frühjahr dauert dieselbe Schicht 7 Stunden, bringt 420 Teile und zeigt einen Verlust von 12,5 Prozent, den es nie gab. Wird Ortszeit ohne Offset gespeichert, landet die doppelte Stunde im Herbst zudem im selben Intervall, und ihre Energie wird falschen Teilen zugerechnet.

Im Monatsbericht fällt nichts davon auf. Jeder Effekt reicht aber, um die Instandhaltung an die falsche Maschine zu schicken, einem Modell ein falsches Muster beizubringen oder ein Werk in einer beliebigen Nacht besser aussehen zu lassen als ein anderes.

Die benannten Fehlermuster

Nach diesen Mustern lohnt es sich zu suchen. Benannt erkennt man sie leichter.

Der 1970-Alarm. Eine Steuerung ist während eines langen Stillstands ausgeschaltet. Die Gangreserve ihrer Uhr, oft ein kleiner Kondensator oder eine Batterie, ist erschöpft, und die Uhr erwacht mit einem Standarddatum. Ihre Alarme sortieren sich im Historian vor alle anderen Einträge, und der Stillstandsbericht beginnt mit einem Ereignis, das Jahrzehnte alt ist.

Der driftende Zeuge. Eine Geräteuhr, die niemand synchronisiert, driftet um Sekunden pro Tag. Nach einigen Wochen wird die Wirkung vor ihrer Ursache protokolliert, und die Ursachenanalyse beschuldigt die Maschine, die in Wahrheit das Opfer war.

Die Wiederholung um Mitternacht. Das Netz fällt sechs Stunden aus, und ein Gateway hält die Daten zurück, bis es wieder senden kann. Nach dem Wiederverbinden kommt der Rückstand an. Erkennt das empfangende System ihn nicht als Historie, überschreiben die Werte der letzten Nacht die aktuellen, und das Dashboard zeigt eine Flut von Kurzstopps, die nie stattgefunden haben.

Die 25-Stunden-Nacht. Zeiten werden als Ortszeit ohne Offset gespeichert. In der Herbstnacht, in der die Uhren zurückgestellt werden, kommt eine Stunde zweimal vor, im Frühjahr gibt es eine Stunde gar nicht. OEE und Energie pro Teil sind in diesen Nächten in beide Richtungen falsch.

Der Ankunftsstempel. Ein Wert wird bei Ankunft am Server gestempelt, nicht bei der Messung. Jeder Messwert trägt die Verzögerung seines Weges, und Messwerte von verschiedenen Wegen lassen sich nicht mehr aufeinander legen.

Die Verknüpfung über zwei Uhren. Ein Prüfergebnis aus dem Laborsystem und ein Prozesswert von der Linie werden über die Zeit verknüpft. Das Laborsystem nutzt eine Uhr, die Linie eine andere. Die Verknüpfung ordnet die Messung dem falschen Teil zu oder gar keinem, und die Rückverfolgbarkeit reißt genau an der Stelle ab, nach der ein Auditor fragen wird.

Ein Architekturproblem, bevor es ein Datenproblem ist

Die übliche Antwort auf schlechte Daten ist Bereinigung. Bei der Zeit funktioniert das nicht. Ist ein Wert einmal mit falscher Zeit gespeichert, sieht der Fehler aus wie jeder andere Wert. Nichts im Datensatz sagt, dass die Uhr 52 Sekunden daneben lag.

Die Zeit muss dort stimmen, wo die Daten entstehen, und sie muss an ihnen haften bleiben, während sie sich bewegen. Das ist eine Entwurfsentscheidung in jeder Schicht:

• Woher die Zeit kommt. Welche Geräte Zeit aus einer Netzquelle beziehen können, welche nicht, und wie die anderen stattdessen gestempelt werden.
• Welche Zeit erhalten bleibt. Ob an jeder Station die ursprüngliche Zeit der Quelle weiterreist oder durch die Ankunftszeit ersetzt wird.
• Wie die Zeit gespeichert wird. UTC im Speicher, Ortszeit nur auf dem Bildschirm, und die Zeitzone beim Standort hinterlegt, damit Tage mit 23 und 25 Stunden durch Rechnung behandelt werden und nicht durch Glück. Die einschlägigen Internetstandards, RFC 3339 und die Erweiterung RFC 9557 von 2024, liefern ein Format, das Offset und Zeitzonennamen zusammenhält.
• Wie späte Daten gekennzeichnet werden. Sendet ein Gateway Daten, die es während eines Ausfalls zurückgehalten hat, sagen die Daten das selbst, und der Empfänger schreibt sie in die Historie statt über die Gegenwart.
• Wie gut jede Uhr ist. Für jede Quelle eine bekannte und dokumentierte Genauigkeit und eine Prüfung, ob sie noch gilt.

Fast alles davon wird einmal und früh entschieden; wer später korrigiert, muss jede gespeicherte Zeit neu herleiten. Einen Historian mit fünf Jahren gemischter Orts- und UTC-Zeiten ohne Vermerk repariert kein Skript. Das ist derselbe Punkt wie in Warum KI ohne Kontext in der Fertigung scheitert: Ein Wert ohne seinen Kontext, hier die Zeit und die Uhr dahinter, ist nicht reif für die Analyse, ganz gleich, wie viele Werte es gibt.

Welcher Uhr Sie vertrauen

Es gibt keine einzige richtige Antwort darauf, wie genau die Zeit in einem Werk sein muss. Die richtige Antwort hängt von der Frage ab, die gestellt wird.

Sekunden genügen für Schichtberichte, die tägliche OEE und die meisten Energiekennzahlen. Hier zählt vor allem, dass alle Systeme dieselben Sekunden verwenden und die Ortszeit korrekt behandelt wird.

Hundertstelsekunden zählen, wenn Ereignisse an verschiedenen Maschinen in eine Reihenfolge gebracht werden müssen: ein Stillstand, der sich entlang einer Linie fortpflanzt, eine Alarmfolge, ein Sicherheitsvorfall, der über mehrere Systeme verfolgt wird. NTP in einem gut betriebenen lokalen Netz schafft das in der Regel, oft auch besser. Die Schwachstelle ist meist das Gerät, nicht das Protokoll: Viele Steuerungen fragen selten nach der Zeit und driften dazwischen. Der Zeitdienst eines verbreiteten Server-Betriebssystems etwa ist vom Hersteller nur in Versionen ab 2016 für 1 Sekunde, 50 Millisekunden oder 1 Millisekunde freigegeben, wenn jeder Knoten der Zeitkette wie dokumentiert konfiguriert ist und die Netzlaufzeiten in Grenzen bleiben (unter 5 ms zur Quelle für 50 ms, unter 0,1 ms für 1 ms). Ältere Versionen werden für hohe Genauigkeit gar nicht unterstützt.

Mikrosekunden zählen für Bewegungssteuerung, schnelle Netzqualitätsanalyse und manche Prüfstände. Das ist das Gebiet des Precision Time Protocol, IEEE 1588, und von Time-Sensitive Networking. PTP erreicht mit Hardware-Zeitstempeln und Switches, die am Protokoll teilnehmen, eine Genauigkeit unter einer Mikrosekunde. Ein einziger gewöhnlicher Switch im Pfad fügt eigene Warteschlangenverzögerung hinzu, Dutzende bis Hunderte Mikrosekunden, unter Last mehr.

Die meisten Werke brauchen die erste Stufe verlässlich in allen Systemen und die zweite an Linien, an denen die Reihenfolge zählt. Der häufige Fehler ist nicht zu wenig Genauigkeit, sondern nie zu entscheiden, sodass jedes System die Genauigkeit hat, die es zufällig bekommen hat.

Jede Zeitkette endet in einer Quelle. Ist es ein Satellitenempfänger auf dem Dach, sollten Sie wissen, was das Netz tut, wenn er sein Signal verliert oder ein gefälschtes bekommt. Eine Grandmaster-Uhr mit ofengeregeltem Quarz- oder Atomoszillator hält die Zeit nach Signalverlust stundenlang, eine mit einfachem Quarz beginnt binnen Minuten zu driften.

Wem die Zeit gehört

Die Zeit liegt zwischen IT und OT, deshalb gehört sie oft niemandem.

Die IT verantwortet meist die Zeitserver und synchronisiert die Server und Laptops, die sie betreut. Die OT verantwortet die Steuerungen, und in der Fertigung gilt: Eine laufende Maschine fasst man nicht an. Eine Steuerungsuhr zu stellen, kann ein Wartungsfenster, ein verlorenes Passwort oder einen Anruf beim Maschinenbauer bedeuten. Also driften die Steuerungen, und jede Seite nimmt an, die andere habe es im Griff.

Der übliche Einwand lautet: „Die Uhren stimmen doch, die IT hat NTP.“ Das stimmt für die Server. Die IT hat ihre Server synchronisiert, aber niemand hat die Steuerungen gefragt.

Drei praktische Regeln helfen.

Schreiben Sie den Zeitentwurf auf eine Seite: woher die Zeit kommt, welche Genauigkeit jeder Bereich braucht, welche Systeme die Quellzeit erhalten und dass im Speicher UTC gilt. Mit Verantwortlichem und Datum.

Prüfen Sie ihn, statt ihn anzunehmen. Vergleichen Sie einmal im Quartal die Uhr jeder Steuerung mit der Referenz und notieren Sie die Abweichung. Eine Tabelle genügt. Beim ersten Mal kann die Streuung die nützlichste Zahl der gesamten Datenqualitätsarbeit sein.

Nehmen Sie die Uhren in die Anlaufcheckliste auf, nach jedem langen Stillstand, jedem Batteriewechsel und jedem Steuerungstausch. So gefundene zurückgesetzte Uhren fallen Monate früher auf, als sie sonst in einem Bericht als seltsame Zeile auftauchen würden.

Entscheidungsrahmen: drei Fragen, bevor Sie einer Zeitleiste trauen

1. Wessen Uhr hat das geschrieben? Klären Sie für die Zeitleiste vor Ihnen bei jeder Quelle, ob die Zeit vom Gerät, einem Gateway, einem Abfrageprozess oder dem Server stammt. Weiß es niemand, ist die Reihenfolge der Ereignisse eine Hypothese, kein Befund.

2. Wie weit liegen die Uhren heute auseinander? Vergleichen Sie die beteiligten Uhren mit einer Referenz und notieren Sie die Abweichungen. Liegen zwei Uhren weiter auseinander als die Ereignisse, die Sie analysieren, ist der Reihenfolge nicht zu trauen.

3. Was geschah an den Rändern? Prüfen Sie, ob der Zeitraum eine Zeitumstellung enthält, einen Ausfall, nach dem Daten nachgeliefert wurden, oder einen Wiederanlauf nach langem Stillstand. Dort entstehen die meisten Zeitfehler, und sie sind leicht zu finden, wenn man weiß, wonach man sucht.

Zusammenfassung für die Geschäftsführung

• Jeder Maschinendatensatz hängt an einem Zeitstempel, und in einem gemischten Maschinenpark stammen diese Zeitstempel von mehreren Uhren, die selten verglichen werden.
• Die gängigen Industrieprotokolle behandeln Zeit unterschiedlich: Manche tragen die Messzeit, manche nur die Ankunftszeit, manche gar keine.
• Unkorrigierte Geräteuhren driften um Sekunden pro Tag. Die Zeitumstellung erzeugt Tage mit 23 und 25 Stunden. Ausfälle erzeugen nachgelieferte Daten, die wie Live-Daten aussehen können.
• Im Monatsbericht fallen diese Fehler nicht auf, aber sie vertauschen in der Ursachenanalyse Ursache und Wirkung, verzerren OEE und Energie pro Teil, brechen die Rückverfolgbarkeit und lehren Modelle falsche Muster.
• Nachträglich bereinigen lassen sie sich nicht. Die Zeit muss dort stimmen, wo Daten entstehen, und mit ihnen weiterreisen.
• Die Regulierung setzt für Sicherheitsprotokolle bereits synchronisierte Uhren voraus, und Schaltsekunden, Störungen der Satellitensignale und die Grenze von 2038 halten das Thema auf der Tagesordnung.
• Die Lösung beginnt mit einem einseitigen Zeitentwurf, einer vierteljährlichen Uhrenprüfung und einem klaren Verantwortlichen zwischen IT und OT.

Checkliste für die Umsetzung

1. Die Uhren auflisten. Jedes Gerät und jedes System, das eine Zeit in Maschinendaten schreibt.
2. Die Zeitquelle jeder Uhr festhalten. Netzquelle, Satellitenempfänger, von Hand gestellt oder nie gestellt.
3. Die Abweichungen messen. Jede Uhr mit einer Referenz vergleichen, Abweichung und Datum notieren.
4. Einen Wert verfolgen. Ein Signal von der Maschine bis zum Bericht verfolgen und an jeder Station notieren, welche Zeit es trägt.
5. UTC speichern. Bestätigen, dass im Speicher UTC steht oder Ortszeit mit Offset, und dass die Zeitzone des Standorts hinterlegt ist.
6. Den letzten Oktober prüfen. OEE und Energie pro Teil für die Nacht der Zeitumstellung ansehen. Nach einer 9-Stunden-Schicht suchen, einem Leistungsgrad über 100 Prozent oder einer doppelten Stunde.
7. Einen Ausfall testen. Geplant ein Gateway eine Stunde vom Netz nehmen und prüfen, wie die zurückgehaltenen Daten ankommen und wohin sie geschrieben werden.
8. Die Standarddaten finden. Im Historian nach Ereignissen suchen, die Jahrzehnte in der Vergangenheit oder Jahre in der Zukunft datiert sind.
9. Den Zeitentwurf schreiben. Eine Seite, mit Genauigkeit pro Bereich, Zeitquelle, Verantwortlichem und Datum.
10. Uhren in den Wiederanlauf aufnehmen. Nach jedem langen Stillstand, Batteriewechsel oder Tausch gehört die Uhr der Steuerung zur Anlaufprüfung.

Wo wir stehen

Wir entwickeln Software in diesem Umfeld, wir sind also keine neutrale Partei. Für den Großteil der Checkliste brauchen Sie eine Referenzuhr, eine Tabelle, jemanden aus der IT, jemanden aus der OT und ein paar geduldige Stunden, kein Produkt.

Wir haben diesen Beitrag geschrieben, weil hinter Maschinendaten, die nicht aufgehen, oft eine ungestellte Frage steht: Welche Uhr hat das geschrieben?

Wenn Sie den Zeitentwurf Ihres Werks oder das Ergebnis einer ersten Uhrenprüfung besprechen möchten, tun wir das gern.

Fragen für Ihr nächstes Review

1. Stammt bei jedem Maschinensignal, das wir nutzen, die Zeit vom Gerät, einem Gateway, einem Abfrageprozess oder dem Server?
2. Wann hat zuletzt jemand die Uhr einer Steuerung mit der Zeit unserer Server verglichen, und wie weit lagen sie auseinander?
3. Speichern wir UTC, und wie sah die Nachtschicht vom letzten Oktober in unseren OEE- und Energiezahlen aus?
4. Wenn die Verbindung zu einem Gateway abreißt, kommen die zurückgehaltenen Daten als Historie gekennzeichnet an?
5. Welche unserer Geräte würden nach einem langen Stillstand mit einem Standarddatum aufwachen, und würde es jemand bemerken?
6. Könnten wir einen Maschinenalarm, ein Prüfergebnis und einen Eintrag im Sicherheitsprotokoll aus derselben Minute nebeneinanderlegen und der Reihenfolge trauen?
7. Welche Geräte in unserem Werk speichern die Zeit so, dass sie 2038 überläuft, und weiß das jemand?

Worauf es ankommt

Betriebe stecken Kalibrierbudgets, Sensorauswahl und Stunden der Datenbereinigung in die Frage, ob ein Wert stimmt. Weit weniger in die Frage, ob er am richtigen Zeitpunkt steht, denn eine falsche Zeit sieht aus wie eine richtige.

Dabei ist fast jede Frage an Maschinendaten eine Frage nach der Zeit: Was geschah zuerst, wie lange dauerte es, was lief, als das Teil gefertigt wurde, was änderte sich vor dem Ausfall. Wenn die Uhren nicht übereinstimmen, sind die Antworten selbstsicher und falsch.

Die Zeit ist das erste Feld jedes Datensatzes. Sie verdient einen Verantwortlichen, einen Entwurf und eine Prüfung, bevor jemand darauf aufbaut.

Quellen

• Die OPC-UA-Spezifikation, Teil 4: Services, Version 1.05, Abschnitt 7.11 (Quellzeitstempel und Serverzeitstempel).
• Die Sparkplug-B-Payload-Definition der quelloffenen Referenzimplementierung: Sendezeitpunkt, Erfassungszeitpunkt je Metrik, Kennzeichen für historische Daten.
• Der Standard MQTT Version 5.0 (2019): Das Protokoll definiert keine Zeitstempel-Eigenschaft.
• Resolution 5 der 28. Generalkonferenz für Maß und Gewicht (Oktober 2026): fortlaufende UTC ab dem 20. Mai 2027.
• Rat der Europäischen Union, Notiz ST 9188/25 (Mai 2025), zu Störungen der Satellitennavigation im Ostseeraum.
• Durchführungsverordnung (EU) 2024/2690 der Kommission, Anhang, Nummer 3.2.6, und die technische Umsetzungshilfe der EU-Agentur für Cybersicherheit (Juni 2025).
• Die Application Note eines Halbleiterherstellers zur Quarzgenauigkeit: 20 ppm sind etwa eine Minute pro Monat.
• Die veröffentlichte Supportgrenze eines Herstellers von Server-Betriebssystemen für hochgenaue Zeit.
• Ein Sicherheitshinweis eines deutschen Industrie-CERT von 2025, aktualisiert im August 2026, zu Steuerungen, bei denen einige Funktionen ausfallen, wenn ihr Datum auf den 19. Januar 2038 gesetzt wird.
• Rat der Europäischen Union, Themenseite zur Zeitumstellung.
• IETF RFC 3339 und RFC 9557 (2024), Datums- und Zeitformate mit Offset und Zeitzone.
• IEC 62443-3-3, Systemanforderung 2.11 (Zeitstempel).
• Der MTConnect-Standard zu Beobachtungszeitstempeln, die der Adapter liefert oder der Agent setzt.
• Internationaler Dienst für Erdrotation und Referenzsysteme (IERS), Bulletin C: die Differenz zwischen Atomzeit und UTC seit dem 1. Januar 2017.

Nehmen Sie eine Linie und zwei Maschinen daran. Vergleichen Sie heute deren Uhren mit einer Referenz und notieren Sie die Abweichung. Ist diese Abweichung größer als der Abstand zwischen den Ereignissen, die Sie in Ihrer letzten Stillstandsanalyse ausgewertet haben, oder kann niemand sagen, welche Uhr welches Signal stempelt, schreiben Sie es in die Kommentare unten. Wir antworten auf jeden Kommentar und nennen dort auf Nachfrage auch die vollständigen Quellen. Wenn Sie vorher sehen möchten, ob Ihre Maschinendaten für diese Art von Analyse bereit sind, nutzen Sie die kostenlose Selbsteinschätzung unter criussoftware.com/res/kits/readiness/. Sie fragt eine geschäftliche E-Mail-Adresse, den Firmennamen und Ihre Einwilligung zur Kontaktaufnahme ab und liefert ein bewertetes Ergebnis.

Nehmen Sie eine Linie, einen Alarm aus dem letzten Monat und das Qualitätsergebnis, das darauf folgte. Legen Sie für beide die Zeit der Steuerung, die des Gateways und die des Servers nebeneinander. Stimmen sie auf die Sekunde überein, haben Sie den Beleg. Stimmen sie nicht, haben Sie die Stelle gefunden, an der jeder Bericht über diese Linie zu driften beginnt.