Il problema dell’anno 2038 (Y2K38) è un bug di overflow che riguarda alcuni sistemi informatici che utilizzano il tempo Unix rappresentato come un numero intero a 32 bit con segno. In questi sistemi, il tempo è contato come il numero di secondi trascorsi dal 1° gennaio 1970 (Epoch Unix). Un intero a 32 bit con segno può rappresentare valori fino a 2.147.483.647.
Quindi il problema si verificherà il 19 gennaio 2038 alle 03:14:07 UTC, quando si raggiunge il valore massimo rappresentabile. Un secondo dopo, il contatore va in overflow e “gira” a un valore negativo, causando un’interpretazione errata della data (potenzialmente tornando al 1970).
Questo può causare:
- Malfunzionamenti di sistemi embedded e industriali
- Errori nei registri di log e nei database
- Problemi nelle funzioni di pianificazione e automazione
- Possibili impatti su sicurezza e comunicazioni
- Errori nei meccanismi di sicurezza e certificati
- Incompatibilità con servizi di sincronizzazione dell’ora (ad es. NTP/GPS/PTP)
Come viene gestita la data/ora nei ns sistemi
Nei nostri sistemi programabili che utilizzano l’ambiente di programmazione LogicLab esistono diversi tipi di rappresentazione data/ora come definito dalla normativa IEC-61131, come si evince dalla tabella gli unici 2 tipi che soffrono del Y2K38 sono il DATE e DATE_AND_TIME:
| Tipo IEC | Bits | Range valore |
|---|---|---|
| TIME | 32 | Time expressed in milliseconds, range da -24d_20h_31m_23s_648ms a 24d_20h_31m_23s_647ms |
| LTIME | 64 | Time expressed in nanoseconds,, range da -106751d_23h_47m_16s_854ms_775us_808ns a 106751d_23h_47m_16s_854ms_775us_807ns |
| TIME_OF_DAY | 32 | Time of the day expressed in milliseconds, range da 00:00:00.000 a 23:59:59.999 |
| LTIME_OF_DAY | 64 | Time of the day expressed in nanoseconds, range da 00:00:00.000000000 a 23:59:59.999999999 |
| DATE | 32 | Date expressed in seconds, range da 1970-01-01 a 2038-01-19 |
| LDATE | 64 | Date expressed in nanoseconds, range da 1970-01-01 a 2262-04-11 |
| DATE_AND_TIME | 32 | Date expressed in seconds, range da 1970-01-01-00:00:00 a 2038-01-19-03:14:07 |
| LDATE_AND_TIME | 64 | Date expressed in nanoseconds, range da 1970-01-01-00:00:00 a 2262-04-11-23:47:16.854 |
Vulnerabilità al Y2K38 dei ns sistemi
Nei nostri sistemi operativi sono disponibili due funzioni per la gestione del tempo di sistema:
- SysDateGetS (time in secondi): Questa funzione restituisce la data e ora di sistema in UTC espressa in secondi, utilizzando una variabile di tipo UDINT a 32 bit. Il range temporale supportato va da 00:00:00 del 1° gennaio 1970 fino a 06:28:15 del 7 febbraio 2106.
- SysDateGetNs (time in nanosecondi): Questa funzione restituisce la data e ora di sistema in UTC espressa in nanosecondi, utilizzando una variabile di tipo ULINT a 64 bit.Il range temporale supportato va da 00:00:00 del 1° gennaio 1970 fino a 23:34:33.709 del 21 luglio 2554.
Entrambe le funzioni sono quindi immuni al problema del Y2K38. Il primo limite di overflow si presenta con SysDateGetS nel 2106, mentre utilizzando SysDateGetNs il limite viene esteso fino al 2554.
Il problema può porsi nel modo in cui viene scritto il programma PLC, se come visto si utilizzano i tipi DATE e DATE_AND_TIME si può incorrere nel problema Y2K38, per questo consigliamo di utilizzare nei programmi i tipi a 64 bits.
Utilizzo Real Time Clock hardware
Nei nostri sistemi è previsto l’utilizzo del Real Time Clock (RTC) hardware; in alcuni casi tale funzionalità è opzionale, mentre in altri costituisce una dotazione standard. L’impiego dell’RTC richiede una sorgente di alimentazione di backup, tipicamente una batteria o un power capacitor, al fine di garantire il mantenimento delle informazioni di data e ora anche a sistema spento.
Nell’utilizzo dell’RTC è necessario considerare il range di data/ora supportato dal dispositivo. Attualmente vengono utilizzati dispositivi con intervallo compreso tra il 01/01/2000 00:00:00 e il 31/12/2099 23:59:59.