Journal 6 avril 2019 : C'est le 2e GPS Week Number Rollover

Posté par . Licence CC by-sa.
Tags :
42
26
fév.
2019

Bonjour,

Renault me demande de faire une mise à jour du système multimédia de ma voiture rapidement, avant le 6 avril (RLink 1 des fois que certains n'aient pas reçu le message et soient concernés). Et pour une fois, alors que le message est destiné au grand public, il donne la raison technique, et en V.O. en plus : "Week Number Rollover".

Donc je me suis renseigné sur ce que c'était.

Le codage de la date dans le système GPS

Les communications GPS comprennent une date à la seconde. On parle bien d'une simple date informative, pas de l'ultra-précision nécessaire au calcul des positions.

Cette date est basée sur un epoch un peu à la Unix, mais pas pareil : on compte les secondes depuis le début de la semaine (qui commence le dimanche) et on compte les semaines depuis le début du GPS. Ce compteur de semaines (WN = Week Number) étant codé sur 10 bits, il se remet à zéro au bout de 1024 semaines, soit grosso-modo 20 ans, c'est le Week Number Rollover. Or le GPS a plutôt 40 ans.

Les dates clé

  • La création du GPS qui sert de référence à l'epoch c'est le 6 janvier 1980
  • 20 ans plus tard environ, le 21 août 1999, premier Week Number Rollover
  • 20 ans plus tard environ, le 6 avril 2019, prochain Week Number Rollover

Conséquences

En 1999 je ne me souviens pas que ça ait défrayé la chronique. En même temps, les équipements GPS étaient peu courants dans le grand public. Mais les utilisations industrielles étaient déjà là et il n'y a pas eu d'impact notable.

En 2019, je m'attends tout de même à plus d'impact. Par exemple j'ai une autre voiture (Renault aussi) plus vieille, qui synchronise son heure sur le GPS, et j'ai bien peur qu'il me faille passer en manuel. Autre exemple spéculatif, si votre smartphone considère que seule l'heure GPS est de confiance et que le bug est avéré, peut-être que certains certificats DRM se trouveront inutilisables.

Mais en cherchant des informations, je me suis rendu compte que le calcul de la date selon les fabricants pouvait également contenir un "offset" basé sur la date de fabrication par exemple, qui fait que ce Rollover arrivera potentiellement dans quelques années, pas forcément à date anniversaire du GPS.

Bref il y a un petit côté "bombe à retardement" dans cette histoire, variable selon la naïveté de l'implémentation.

Conclusion

Je n'ai pas réussi à trouver l'origine de ce choix de codage de date ni pourquoi il apparait un certain manque d'ambition (ou d'excès de confiance dans les systèmes utilisateurs ?) de la part de la norme en ne visant que 20 ans avant d'avoir un problème potentiel. Si quelqu'un a plus d'explication, ce sera toujours intéressant.

En tous cas, si le dimanche 7 avril au matin un appareil GPS vous dit qu'on est en août 1999, vous saurez pourquoi.

Références

  • # En 1999...

    Posté par . Évalué à 10 (+14/-1).

    …ça paniquait pour un autre changement de date. Mais je ne sais plus laquelle…
    C'était une belle psychose et cela a permis des heures de consulting : air nostalgique

    • [^] # Re: En 1999...

      Posté par . Évalué à 6 (+5/-0).

      Ben je viens d'être confronté à une variante du bug de l'an 2000 : 20*19 et 19*xx et des mélanges de formats de date.

  • # et au final ça fait quoi ?

    Posté par . Évalué à 3 (+1/-0).

    J'ai pas très bien compris ce que ce «Week Number Rollover» implique comme manipulation a faire sur les GPS …
    Tu nous explique l'origine, les conséquence mais la solution c'est quoi ? Et puis surtout es-ce qu'une solution a plus long terme est envisagé, car tous les 20 ans ça fait court finalement.

    • [^] # Re: et au final ça fait quoi ?

      Posté par . Évalué à 2 (+0/-0).

      En fait il change d'Epoch tous les 20 ans, donc j'imagine que, tous les 20 ans, il faut redéfinir l'Epoch de chaque GPS.

      Et puis surtout es-ce qu'une solution a plus long terme est envisagé, car tous les 20 ans ça fait court finalement.

      Je ne sais pas, mais déjà les alternatives au GPS n'ont apparemment pas ce problème : https://www.guralp.com/howtos/gps-wnro.shtml

    • [^] # Re: et au final ça fait quoi ?

      Posté par . Évalué à 5 (+3/-0).

      C'est là où on fait le lien direct avec le libre : si ton GPS non libre a un soucis, tu ne peux que te retourner vers le fabriquant pour espérer une mise à jour. Par contre si tu as le code de source, tu auras la possibilité de proposer un fix (toi ou qqu'un d'autre qui en fera profiter la communauté).

      Par exemple au boulot on travaille sur l'intégration d'un équipement qui se synchronise (date et heure) sur le GPS. Vu qu'on n'a pas le code source, on a envoyé un mail au fournisseur pour lui demander si il a bien pris ça en compte (et nous éviter de galérer pendant 3 ou 4 jours le temps qu'on comprenne et qu'il nous envoie un fix).

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: et au final ça fait quoi ?

      Posté par . Évalué à 5 (+4/-0).

      Il existe au moins une solution théorique au problème du compteur: ajouter un autre compteur. Si on imagine un récepteur GPS qui n'aurait comme source d'information que le signal GPS et rien d'autre, donc très rustique, alors il pourrait détecter que le compteur a recommencé un cycle en comparant avec la dernière valeur connue. Il incrémenterait alors un autre compteur dans sa mémoire non volatile. Le problème serait résolu s'il est allumé au moins une fois tous les 20 ans et si le deuxième compteur est suffisamment grand.

      Mais au final, le comportement dépend complètement du GPS et de la qualité de son logiciel. Ça c'est bien passé pour mon GPS simple en 1999. D'une part, comme expliqué dans le journal il peut utiliser une semaine pivot, inconnue donc imprévisible, pour régler le problème. Il faut aussi voir que les "GPS" modernes utilisent maintenant aussi les autres constellations, les services d'assistance (satellite et serveur), les réseaux mobiles (NTP ou autre), en plus d'une horloge interne (RTC). Si j'ai bien suivi, Galileo a ajouté 2bits supplémentaires au compteur de semaines. Donc, il est difficile de prédire comment ce mélange de dates est traité par le récepteur mais il a potentiellement la possibilité de s'en sortir.

      Je ne connais pas l'origine de la limitation du compteur à 10bits, mais la taille des messages et le débit de transmission est très réduit donc c'est probablement pour économiser des bits que ce choix a été fait.

      Les spécifications des signaux sont en partie publiques. Pour le logiciel libre, il existe une implémentation Android (il faut quand même un récepteur compatible) réalisée à l'ESA pour Galileo: GNSS Compare (lien Google Play, documentation, dépôt Github).

      • [^] # Re: et au final ça fait quoi ?

        Posté par . Évalué à 8 (+6/-0). Dernière modification le 28/02/19 à 07:52.

        Il existe au moins une solution théorique au problème du compteur: ajouter un autre compteur.

        Oui, j'ai vu passer un autre fabricant qui annonçait avoir un compteur sur 16 bits, donc des WNR il peut en vivre un paquet (6 bits de WNR, soit 64*20 ans de durée de vie). Mais ce qui est rigolo c'est que un tel équipement, si tu le laisses plus de 20 ans dans une armoire et que tu le rallumes, il n'a strictement aucun moyen de savoir qu'il a passé 20 ans.

        En gros : le GPS te donne une date module 20 ans. A toi de ne pas passer 20 ans sous un tunnel, sous peine de rater un modulo.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: et au final ça fait quoi ?

        Posté par (page perso) . Évalué à 2 (+0/-0).

        Tout à fait, si j'ai bonne mémoire le signal GPS grand public contient des informations qui sont transmises une fois toutes les 12.5 minutes. Par exemple, les secondes intercalaires, probablement la date, et tout un tas d'autre choses.

        Chaque bit coûte donc assez cher, car si cette période devient plus longue, d'une part ça va mettre plus de temps pour récupérer les informations, et d'autre part, la probabilité de perdre un bit parmi tout le message est augmentée (et dans ce cas, on a plus qu'à attendre la prochaine émission…).

        Donc un compteur sur 20 ans, c'est déjà pas mal. Il y a peu de récepteurs GPS fabriqués avant 1999 qui sont encore utilisés aujourd'hui, non?

        Et je suppose que les signaux utilisée par les militaires américains (qui eux, ne sont pas documentés) n'ont pas ce problème, les specs militaires demandant probablement que ça dure plus de 20 ans.

        • [^] # Re: et au final ça fait quoi ?

          Posté par . Évalué à 1 (+0/-0).

          Donc un compteur sur 20 ans, c'est déjà pas mal. Il y a peu de récepteurs GPS fabriqués avant 1999 qui sont encore utilisés aujourd'hui, non?

          J'utilise un tomtom rider 2, acheté vers 2010. Il n'est plus en bon état physique, jamais mis à jour au niveau données ou logiciel mais il répond encore à mon besoin.

          Pour les récepteur avant 1999, je ne sais pas s'il en reste. Pour les récepteurs avant 04/2019 et qui ne supporteront pas le passage, il peut y en avoir un certains nombre.

        • [^] # Re: et au final ça fait quoi ?

          Posté par . Évalué à 2 (+0/-0).

          Tout à fait, si j'ai bonne mémoire le signal GPS grand public contient des informations qui sont transmises une fois toutes les 12.5 minutes. Par exemple, les secondes intercalaires, probablement la date, et tout un tas d'autre choses.

          Les specifs d'interface du signal in space, que ce soit pour Galileo ou pour le GPS sont publiques et disponibles sur internet. Tout est dedans. Effectivement la bande passante pour transférer les almanachs (les paramètres macros) et les éphémérides (paramètres micros et corrections d'horloges) est extrêmement faible.

  • # matériel ou logiciel ?

    Posté par (page perso) . Évalué à 2 (+1/-0). Dernière modification le 27/02/19 à 13:31.

    La correction est-elle du niveau du firmware ou du software ?
    En gros, je me pose la question, pour OSMAnd, de savoir si on doit attendre une mise à jour Android, ou OSMAnd…

    • [^] # Re: matériel ou logiciel ?

      Posté par . Évalué à 2 (+0/-0).

      Il se pourrait aussi parfaitement qu'il n'y ait aucun bug.

      Mais tu utilises la date dans OSMand ?

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: matériel ou logiciel ?

        Posté par (page perso) . Évalué à 7 (+6/-0). Dernière modification le 27/02/19 à 15:27.

        Ah, peut-être pas, c’est vrai. Tout va bien, alors :-)

        Et à part ça, s’être marié le jour de la bascule de 1999, c’est quand même une coïncidence amusante !

  • # Je me demande

    Posté par . Évalué à 8 (+6/-0).

    Dans une autre vie (wow quand j'y pense, je deviens vieux :-D ) j'ai bossé sur des satellites qui utilisaient un récepteur GPS pour déterminer leur orbite. Et aussi pour recaler l'heure de bord. Je me rappelais que l'epoch démarrait au 6 janvier 80, pour avoir du calculer des temps basés là dessus, mais pas qu'il y avait eu un rollover (pourtant c'était bien après 1999 quand même) (je dialoguais avec un récepteur GPS intelligent, c'est peut-être lui qui corrigeait déjà ça)

    Du coup je me demande à quel point ça va lancer des alarmes en avril dans les centres de contrôle. (pour avoir bossé un peu dans le domaine, j'imagine que ça va faire plein de problèmes, mais surtout des faux positifs sur des équipement sols). C'était amusant de voir le passage au 31 décembre des années bissextiles (compteur de jour dans l'année qui arrive à 366) ou lors des secondes intercalaires (la seconde 60, en dehors de l'interval [0,59])

    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: Je me demande

      Posté par . Évalué à 8 (+6/-0).

      Je pensais que l'aérospatial était plus fiable que ça sur la gestion du temps. S'ils ont les même problème que nous, c'est « rassurant » :D

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.