Regelungstechnik und das Problem im Jahr 2036 / 2038

[h5py]

Hallo,

hatten im Projekt heute Diskussion wegen der zu erwartenden Probleme im Jahr 2036 und 2038 bzgl. des "Überlaufes" der Zeitberechnung in eingebetteten Steuerungen/Regelungen. Problem wird auf wikipedia recht verständlich erläutert: Jahr2038-Problem

Wenn Ihr in der nächsten Zeit eine neue Heizung anschafft und Ihr plant den Einsatz über das Jahr 2036 bzw. 2038:

Lasst Euch vom Heizungsbauer bzw. vom Hersteller besser bestätigen, dass es keine Probleme geben wird.

 

[cephalopod]

Lasst Euch vom Heizungsbauer bzw. vom Hersteller besser bestätigen, dass es keine Probleme geben wird.

Wikipedia:

Dieses Problem ist auf EDV-Systeme beschränkt, die die Unixzeit benutzen ...

Weil Heizungssteuerungen natürlich unbedingt auf einem Unix System Laufen ....

Hauptsache mal was gepostet

 

[tricotrac]

Lasst Euch vom Heizungsbauer bzw. vom Hersteller besser bestätigen, dass es keine Probleme geben wird.

Die Nummer haben wir doch mit dem Jahrtausendwechsel schon mal gehabt. Ich hatte den Bereitschaftsdienst für 1999 / 2000 übernommen für einen jüngeren Kollegen. Und was ist da passiert ? nichts, einfach gar nichts. Kein Regelungsausfall ; keine digitale Uhr ist ausgefallen und kein hinterlegter Kalender hat versagt. Am Vormittag des ersten Januar 2000 habe ich mich bei meinem Technikchef dann für mehrere Stunden abgemeldet und bin in den Nordsternpark nach Gelsenkirchen gefahren und habe den "Deutschlandexpress", eine fest installierte Modelleisenbahn, besucht. Ich war ganz allein mit einer Aufsichtsperson in diesem Raum unterwegs. Und deshalb kann ich mich so gut daran erinnern. Wochenlang sind da vorher alle möglichen Szenarien durchgespielt worden.

 

[h5py]

Die Nummer haben wir doch mit dem Jahrtausendwechsel schon mal gehabt.

Genau - und wir mussten jede Menge Programme anpassen - welche ohne Anpassung definitv nicht mehr funktioniert hätten. Und pensionierte Cobol-Programmierer haben sich ein nettes Zubrot verdient. Nur ist das mit den eingebetteten System halt nicht so einfach, da niemand weiss was da eigentlich passiert. Und es ist in der Tat so, dass in Regelungen immer häufiger auf Linux basierte Systeme verwendet werden.

 

[JSchnell]

Ich versuchs jetzt mal als Laie, und bevor @cephalopod sich ne Beule holt,
Sollte das Problem in Programmierkreisen bekannt sein, dann ist es halt nur noch ein Problemchen, weil es ja anscheinend heute schon Lösungen gibt.
Andersherum wäre es grob fahrlässig, jetzt noch Heizungssteuerungen zu verkaufen, die hiervon betroffen sind. und dann, ist das ja kein heizungsspezifisches Prob.

Also ich kann es nicht, aber es gibt bestimmt User like @h5py, die möglicherweise sicher wissen, welche Systeme (Hersteller, Anlagen etc.) unter Umständen betroffen sein könnten. Muss ja nicht gleich der Super-GAU sein.
so ’ne kleine Leiste mit Heizungsbezug (sind ja ein Heizungsforum) wäre doch a nice idea.

Erinnert mich etwas an das Jahrtausend prob, ist Schnee von gestern, bis 2036 ist ja noch Zeit die schmelze von morgen zu verhindern, oder?

MfG

 

[kolobezka]

User
Regelungstechnik und das Problem im Jahr 2036 / 2038

ChatGPT
Im Jahr 2036 und 2038 gibt es in der Regelungstechnik kein spezifisches Problem, das auf diese Jahreszahlen beschränkt ist. Es gibt jedoch zwei bekannte Problemstellungen in der Informatik, die mit diesen Jahreszahlen in Verbindung stehen: das Jahr-2038-Problem und das Jahr-2036-Problem.

Das Jahr-2038-Problem, auch als UNIX-Zeit-Problem bekannt, betrifft Computersysteme, die die Zeit in Form von Sekunden seit dem 1. Januar 1970 darstellen. Diese Systeme verwenden eine 32-Bit-Variante für die Zeitangabe, wodurch das Jahr 2038 zum Problem wird. Am 19. Januar 2038 um 03:14:07 UTC wird der 32-Bit-Zeitwert überlaufen und auf den 1. Januar 1970 zurückgesetzt. Dies kann zu Fehlfunktionen in Systemen führen, die auf dieses Zeitformat angewiesen sind.

Das Jahr-2036-Problem betrifft das Global Positioning System (GPS). Das GPS verwendet eine 10-Bit-Woche in seiner Zeitdarstellung, wodurch nur 1024 Wochen (rund 19,7 Jahre) abgedeckt werden können. Nach Ablauf von 1024 Wochen beginnt die Zählung wieder von vorne. Das letzte Mal trat dieses Problem im Jahr 1999 auf, und das nächste Mal wird es im Jahr 2036 auftreten. Wenn die Systeme nicht entsprechend aktualisiert werden, können Fehler in der Positionsbestimmung auftreten.

In der Regelungstechnik selbst sind diese Probleme jedoch nicht direkt relevant. Regelungstechnik beschäftigt sich mit der Steuerung und Regelung von Systemen, um bestimmte Ziele oder Verhaltensweisen zu erreichen. Sie umfasst Aspekte wie Modellierung, Regelungsentwurf, Regelkreisanalyse und Implementierung von Reglern. Diese Prinzipien und Methoden der Regelungstechnik sind zeitunabhängig und gelten unabhängig vom Jahr.

Falls du weitere Informationen zu spezifischen Themen der Regelungstechnik benötigst, stehe ich gerne zur Verfügung.

https://chat.openai.com/?model=text-davinci-002-render-sha

 

[h5py]

Das Jahr-2036-Problem betrifft das Global Positioning System (GPS). Das GPS verwendet eine 10-Bit-Woche in seiner Zeitdarstellung, wodurch nur 1024 Wochen (rund 19,7 Jahre) abgedeckt werden können. Nach Ablauf von 1024 Wochen beginnt die Zählung wieder von vorne. Das letzte Mal trat dieses Problem im Jahr 1999 auf, und das nächste Mal wird es im Jahr 2036 auftreten. Wenn die Systeme nicht entsprechend aktualisiert werden, können Fehler in der Positionsbestimmung auftreten.

yup - was mir die KI verschweigt: Es gibt 2036 zusätzlich mit dem NTP-Protokoll ein Problem.

In der Regelungstechnik selbst sind diese Probleme jedoch nicht direkt relevant.

Nö, nur indirekt. Der Kram läuft dann halt nicht mehr.

ChatGPT

Du bist ein Phrasendrescher!

 

[kolobezka]

Network Time Protocol (NTP): Definition und Funktionsweise

Das Synchronisierungsprotokoll NTP (Network Time Protocol) hilft vielen Computersystemen, die Systemzeit zu aktualisieren. Dazu findet ein Abgleich mit der Weltzeit statt.

www.ionos.de

User
Es gibt 2038 zusätzlich mit dem NTP-Protokoll ein Problem

ChatGPT
Ja, tatsächlich gibt es ein bekanntes Problem mit dem NTP-Protokoll im Jahr 2038, das als "Year 2038 Problem" oder "Y2K38 Problem" bezeichnet wird. Ähnlich dem Y2K-Problem im Jahr 2000, tritt das Year 2038 Problem aufgrund der Verwendung von 32-Bit-Variablen für die Darstellung von Zeitstempeln in vielen Computersystemen auf.

Das NTP-Protokoll verwendet einen 32-Bit-Zähler, um die Anzahl der Sekunden seit dem 1. Januar 1900 zu speichern. Wenn dieser Zähler den maximalen Wert von 2^31-1 erreicht und dann weiterzählt, wird er auf den Wert -2^31 zurückgesetzt. Dieses Zurücksetzen des Zählers kann zu Fehlern bei der Berechnung von Zeitstempeln führen und damit die korrekte Synchronisation von Uhren und Zeitservern beeinträchtigen.

Um das Year 2038 Problem zu beheben, müssen betroffene Systeme auf 64-Bit-Zeitstempel oder andere Lösungen umgestellt werden, die das Problem der Überlaufzeitstempel vermeiden. Es ist wichtig, dass Betriebssysteme, Anwendungen und Gerätehersteller diese Änderungen rechtzeitig vor dem Jahr 2038 implementieren, um Störungen zu vermeiden.

Es ist möglich, dass es in den letzten Jahren weitere Entwicklungen oder Lösungen gegeben hat. Um genaue und aktuelle Informationen zu erhalten, empfehle ich, die neuesten Quellen und Informationen von Experten auf diesem Gebiet zu konsultieren.

frag die KI

https://chat.openai.com/?model=text-davinci-002-render-sha

 

[helmut m.]

Halbwegs "normale" Regeanlagen holen sich die Zeit und das Datum entweder über das Internet (die allermeisten) oder über das DCF Zeitsignal. Alle Zeitserver und das DCF-Signal werden auch 2038 vermutlich das korrekte Datum samt korrekter Uhrzeit liefern.

 

[h5py]

Halbwegs "normale" Regeanlagen holen sich die Zeit und das Datum entweder über das Internet (die allermeisten)

Leider nicht ganz richtig: NTP kann im Jahr 2036 auch das Licht ausgehen. Steht auch so in dem von mir verlinkten Wikipedia-Artikel.

 

[Hinnerk]

Halbwegs "normale" Regeanlagen holen sich die Zeit und das Datum entweder über das Internet (die allermeisten) oder über das DCF Zeitsignal. Alle Zeitserver und das DCF-Signal werden auch 2038 vermutlich das korrekte Datum samt korrekter Uhrzeit liefern.

Meine Wolf bzw. das Bedienmodul BM-2 besitzt zwar keine Funkuhr aber einen "ewigen Kalender". Der berücksichtigt die Sommer und Winterzeit sowie die Schaltjahre. Da kann im Jahr 2036 oder 2038 kommen was da wolle. Zeittechnisch ist da die Wolf vollkommen autark.

 

[Austro-Diesel]

Weil Heizungssteuerungen natürlich unbedingt auf einem Unix System Laufen ....

Die ETA Heizungsregelung basiert zB auf Linux. Das ist gar nicht weit weg von Unix. Immerhin updatefähig.

 

[Georg Hendrich]

Das ist gar nicht weit weg von Unix. Immerhin updatefähig. ...

Seit 2020 und Kernel 5.6 gibt auch der 32bit der Linux-Kern auch als Posix-Time (time_t) einen vorzeichenbehafteten 64bit Integer zurück [1],
die API-Erweiterung war explizit für die Embedded -Verwendung [1].
64bit Linux haben immer-schon einen 64 bit integer.

NTP /SNTP ist seit je her 64 bit [2].

Wer sauber und "Recourcend-sparend" programmiert -- also auf kleinen embedded-Systemen vor allem C++ ..

.. der hat entweder schon etwas länger kein Jahr-2038-Problem mehr weil die Standard-Bibliothek bereits einen 64bit Wert verwendet und den "überlaufende" 32bit Werte des Kernel korrigiert.

Oder er wird das "Problem" durch einfaches neu-kompelieren los -- also ohne Änderungen im eigenen Code, sowie eine Jahr-2038 -"fähige" Standard-Bibliothek verfügbar wird.

Denn unter C++ sollte ein Entwickler für den "Zeitwert" den entsprechenden dezidierten Type verwenden [3] also:

std::time_t

Das ist ein typedef (1) auf einen "passenden" Integer.

Wird bei einen "Update" der Bibliothek std::time_t von 32bit integer auf 64 integer geändert läuft die Änderung über den gesamten Code mit -- ohne Änderungen im Anwendungscode (wenn sauber programmiert wurde).

Anmerkungen:

(1) "typedef" ist C++ Syntax und erlaubt dem Programmierer einen Datentype neu zu definieren, im einfachsten Fall wird so eine Art Synonym für einen bestehenden Datentype erzeugt.


Quellenangaben:

[1] Year 2038 problem - Wikipedia

[2] Network Time Protocol – Wikipedia

[3] std::time_t - cppreference.com