Il n'y a probablement pas besoin de changer le matériel. On peut très bien manipuler des entiers 64 bit sur un processeur 32 bit (en C il suffit de déclarer l'entier en "nong int" ou "uint64_t" par exemple).
Mais si ça n'a pas été fait depuis le début et que ça utilise un système qui a traîné des pieds pendant 20 ans pour faire la mise à jour (quelque chose comme la glibc, par exemple), ben il faut mettre à jour tout le système. Grosse montée en version si ça n'a pas été fait au fil de l'eau: probablement que mettre à jour la glibc va aller avec une mise à jour du noyau, du compilateur, bref de tout le système.
Ensuite il faut corriger les erreurs de compilation que le nouveau compilateur a généré.
Jusque là, c'est la partie facile: tu peux faire ça tranquille dans ton bureau. Mais une fois que ça compile, tu peux pas dire "allez zou, on installe ça vendredi après-midi au centre de contrôle (ou sur les rames de métro si c'est embarqué dedans) et c'est parti". Il va falloir tester, probablement d'abord en simulation, mais à un moment sur le vrai matériel. Hors de question de le faire avec des gens dans les rames de métro, et il y a assez peu d'endroits où on peut faire des essais sur des voies qui ne sont pas en service.
Donc ça veut probablement dire fermeture de la ligne de métro pendant quelques jours pour vérifier si tout se passe bien, ou éventuellement essais de nuit si les métros sont fermés la nuit (c'est pas le cas dans toutes les villes) et que le temps de fermeture n'est pas déjà mobilisé par d'autres travaux (entretien des voies, ...).
Pour le centre de contrôle tu pourrais peut-être t'en sortir en faisant tourner le nouveau logiciel en parallèle de l'ancien, et vérifier qu'ils font toujours "la même chose", si le truc a été architecturé pour avoir deux contrôleurs en parallèle.
Le problème des systèmes embarqués est assez réduit ici: c'est l'accès au calculateur pour le mettre à jour. Dans le cas d'un train ça peut se faire lors d'une visite régulière au centre de maintenance. Par contre il faut s'assurer de ne pas avoir oublié de le faire sur un train.
On a donc des problèmes de gestion de flotte, des problèmes de capacité à tester en situation réelle, et peut-être de la gestion d'obsolescence logicielle.
[^] # Re: Difficulté de la mise à jour
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Des lignes de métro, tramway et RER de la RATP concernées par le bogue de 2038. Évalué à 10.
Il n'y a probablement pas besoin de changer le matériel. On peut très bien manipuler des entiers 64 bit sur un processeur 32 bit (en C il suffit de déclarer l'entier en "nong int" ou "uint64_t" par exemple).
Mais si ça n'a pas été fait depuis le début et que ça utilise un système qui a traîné des pieds pendant 20 ans pour faire la mise à jour (quelque chose comme la glibc, par exemple), ben il faut mettre à jour tout le système. Grosse montée en version si ça n'a pas été fait au fil de l'eau: probablement que mettre à jour la glibc va aller avec une mise à jour du noyau, du compilateur, bref de tout le système.
Ensuite il faut corriger les erreurs de compilation que le nouveau compilateur a généré.
Jusque là, c'est la partie facile: tu peux faire ça tranquille dans ton bureau. Mais une fois que ça compile, tu peux pas dire "allez zou, on installe ça vendredi après-midi au centre de contrôle (ou sur les rames de métro si c'est embarqué dedans) et c'est parti". Il va falloir tester, probablement d'abord en simulation, mais à un moment sur le vrai matériel. Hors de question de le faire avec des gens dans les rames de métro, et il y a assez peu d'endroits où on peut faire des essais sur des voies qui ne sont pas en service.
Donc ça veut probablement dire fermeture de la ligne de métro pendant quelques jours pour vérifier si tout se passe bien, ou éventuellement essais de nuit si les métros sont fermés la nuit (c'est pas le cas dans toutes les villes) et que le temps de fermeture n'est pas déjà mobilisé par d'autres travaux (entretien des voies, ...).
Pour le centre de contrôle tu pourrais peut-être t'en sortir en faisant tourner le nouveau logiciel en parallèle de l'ancien, et vérifier qu'ils font toujours "la même chose", si le truc a été architecturé pour avoir deux contrôleurs en parallèle.
Le problème des systèmes embarqués est assez réduit ici: c'est l'accès au calculateur pour le mettre à jour. Dans le cas d'un train ça peut se faire lors d'une visite régulière au centre de maintenance. Par contre il faut s'assurer de ne pas avoir oublié de le faire sur un train.
On a donc des problèmes de gestion de flotte, des problèmes de capacité à tester en situation réelle, et peut-être de la gestion d'obsolescence logicielle.