Le jour où un bug logiciel a presque mis fin à la mission du Rover Spirit sur Mars
Des délais serrés, une décision de ne pas tester un logiciel au-delà d'une certaine limite, et c'est la mission d'exploration de Mars qui a bien failli s'arrêter avant d'avoir commencé. Des problèmes que tous les informaticiens rencontrent tous les jours.
Le vendredi 25 Janvier 2013, a marqué le neuvième anniversaire de l'arrivée réussie sur Mars du Rover Opportunity, le robot d'exploration martien qui fonctionne toujours jusqu'à aujourd'hui. Cependant, son frère jumeau le Rover Spirit aura fêté le moins joyeux anniversaire de son arrivée quasi simultanée il y a 9 ans et la presque fin prématurée de sa mission due à un bug logiciel, dû principalement à une anomalie de gestion de la mémoire flash.
Les deux Rovers étaient arrivés de manière réussie sur Mars en Janvier 2004. Et les deux premières semaines, ils s'étaient promenés joyeusement pour explorer la planète. Cependant, le 21 Janvier, l'équipe de la Nasa n'obtenait plus aucun signal depuis Spirit. Après un test, l'équipe était capable d'obtenir une réponse mais pas plus qu'un simple bip, signifiant que le Rover Spirit était encore vivant.
Après de multiples tests, la conclusion était que le problème était situé soit dans la carte d'interface avec la radio, soit qu'il y avait un problème avec le logiciel de vol. La panique commençait à monter dans l'équipe. Au bout de deux jours supplémentaires, l'équipe avait récupéré des données de diagnostic, dessinant ce qui se passait, sans savoir pour autant pourquoi cela arrivait. Le logiciel de vol était pris dans un cycle de reboot permanent.
A chaque fois qu'il essayait de redémarrer, il rencontrait une erreur, ce qui déclenchait un nouveau redémarrage. Le problème se trouvait dans la mémoire Flash du Rover, où le système de fichiers était stocké.
Au bout du 20ème jour solaire, l'équipe de la Nasa ne connaissait pas la cause racine du problème, elle savait que comme le Rover ne pouvait pas s'arrêter proprement, comme il était censé le faire chaque nuit, sa batterie se déchargeait et qu'il était sur le point de surchauffer, et que sa mission allait s'arrêter avant même d'avoir débuté.
Redémarrer sans accéder à la mémoire Flash ...
Redémarrer sans accéder à la mémoire Flash
Finalement, le jour suivant, l'équipe arriva à faire sortir le Rover de son cycle de reboot en le plaçant en mode « crippled » (invalide). Cela permettait au logiciel de vol de démarrer sans accéder à la mémoire Flash, et d'utiliser à la place la mémoire RAM pour y simuler un système de fichiers. En faisant cela, l'équipe arriva à arrêter le Rover afin qu'il puisse recharger ses batteries. Cela offrait aussi un répit pour diagnostiquer l'origine de la panne et trouver une solution.
L'équipe de la Nasa trouva que le problème était une combinaison d'une faille dans la conception de la bibliothèque DOS (Disk Operating System) , d'un bug dans un logiciel fourni par une tierce partie, et de plusieurs erreurs de configuration. Le logiciel tiers effectuait le miroir de la mémoire flash dans la RAM, qui était en quantité insuffisante de moitié. A cause de la manière dont le DOS gérait le système de fichiers, celui-ci ne cessait de grossir en taille même quand les fichiers étaient supprimés.
Au bout du compte, quand le logiciel de vol essayait de redémarrer, de la nouvelle mémoire ne pouvait pas être allouée, ce qui déclenchait une erreur, ce qui déclenchait un nouveau redémarrage, etc ... Au bout de 32 jours solaires, l'équipe réussissait à corriger le bug, reformatait la mémoire Flash et faisait revenir Spirit à la vie.
Le Rover Spirit a continué à opérer jusqu'au 22 mars 2010, bien au-delà de ses 90 jours solaires prévus initialement. Au final, il fut conclu que le problème aurait pu être évité.
Le calendrier réduit, il n'y avait que trois ans entre la conception et le lancement, a été considéré comme un facteur ayant contribué au problème, car il avait mené à un développement et à des tests incomplets. Alors que les problèmes avec le système de fichiers DOS étaient connus au moment du développement, les connaître complètement et déterminer le paramétrage correct pour les paramètres de configuration avaient été considérés comme de faible priorité et n'avait pas été fait.
Cela sonne comme une vieille histoire pour les projets informatiques : courir pour réaliser le projet et tester plus tard. Trop tard.
