«
Considérons Mars Polar Lander (MPL), un triple échec en 1999. L'objectif de MPL était de fournir un atterrisseur sur Mars pour la moitié du coût de la mission Pathfinder succès spectaculaire lancé deux ans plus tôt. À 265 millions de dollars Pathfinder lui-même était beaucoup moins cher que le vaisseau planétaire précédent
Peu de temps avant qu'il ne commence sa descente, MPL largue 2 sondes Deep Space jumelles qui étaient censées impacter la surface de la planète à quelque 400 mph (640 km/h) et retourner des données "sous-strates".
MPL s'est écrasé lamentablement. Aucune des deux sondes DS2 n'a émis ne serait-ce un cri.
La commission d'enquête a fait l'observation, qui ne casse pas trois pattes à un canard, que le personnel fatigué commet des erreurs. Le contractant a utilisé de manière excessive les heures supplémentaires pour répondre à un calendrier ambitieux. Mars est exigeante sur la planification. Un décalage d'une seule journée sur la fin de la fenêtre de tir et la mission doit entrer en sommeil pour deux ans. Dans certaines affaires vous pouvez négocier avec le patron sur les dates d'échéance mais vous ne pouvez pas négocier avec la mécanique céleste.
Les développeurs MPL travaillait de 60 à 80 heures par semaines durant de longues périodes.
La commission releva également des tests insuffisants. Les analyses et modéles ayant remplacé tests et validations. Les analyses ne sont pas un mal en elles-mêmes, mais le test, c'est comme la comptabilité à double entrées, il trouve des erreurs de modélisation et des comportements étranges jamais envisagés lorsque les produit n'existent que sous forme de bits éthérés.
La doctrine de la NASA est de "tester comme vous volez et de faire voler ce que vous testez". Pourtant, aucun test d'impact d'une sonde opérationnelle DS2 n'a jamais eu lieu. Bien que prévu, ces tests ont été supprimés à mi-parcours du projet en raison de considérations de calendrier. Deux raisons possibles ont été avancées pour expliquer le flop des sondes jumelles DS2 : défaillance électronique en raison de l'impact à haute-vélocité, et une ionisation autour de l'antenne après l'impact. Étrangement, l'antenne n'a jamais été testée dans une simulation de l'atmosphére de Mars.
Pendant que les deux sondes s'écrasaient sur la Planète Rouge, la situation n'était pas meilleures sur MPL.
La commission d'enquête estime que les pieds d'atterrissage se sont déployés lorsque la sonde était à 1.500 mètres de hauteur, comme prévu. Trois capteurs, un par pied, signalent un touché avec succès, provoquant l'arrêt, par le logiciel, du moteur de descente.
Les ingénieurs savaient que lorsque les pieds seraient déployés, ces capteurs pourraient connaître une transition, provoquant la lecture d'une valeur "sol" fausse... mais on oublié d'en informer les équipes "firmware". L'erreur a donc été verrouillée ; à 40 mètres d'altitude le logiciel commence l'examen des données, lis les donnés fausses, et éteint scrupuleusement le moteur.
Un test en pré-lancement du système n'avait pas détecté le problème en raison d'un mauvais cablâge des capteurs. Après correction de l'erreur de câblage, le test n'a jamais été répété.
Il y a également les jumeaux de Mars Expedition Rovers, Spirit et Opportunity, qui à ce jour ont dépassé tous les objectifs de la mission et continuent de fonctionner. Nous avons tous entendu parler de l'arrêt désespérant de Spirit lorsqu'il a tenté de broyer une roche. La plupart d'entre nous savent que le répertoire du système de fichier flash était plein. VxWorks a remonté une exception, exactement comme prévu et a tenté de redémarrer. Ce qui exige plus d'espace de répertoire, causant une autre exception, un autre redémarrage, et ainsi de suite...
Comme dans le non-regretté DOS, les fichiers effacés consomment toujours l'espace du répertoire. Beaucoups de vieux dossiers accumulés lors de la naviguatin vers Mars dévoraient encore l'espace mémoire.
Initialement prévu comme une mission de 90 jours, le vaisseau spatial n'a jamais été testé pendant plus de 9 jours. Le fonctionnement en vol des moteurs et actionneurs a généré beaucoups plus de fichiers que cela n'avait été observé au cours des tests au sol. Les enquêteurs ont écrit: "Bien qu'il y ait des essais limités de longue durée dont le but était d'identifier la consommation de mémoire système de ce type là, aucun problème n'a été détecté parce que le système n'a pas été sollicité autant qu'il le serait plus tard en vol."
''Test like you fly, fly what you tested.''
Les gestionnaires d'exceptions étaient mal implémentés. Ils ont suspendu les tâches critiques après un échec d'allocation mémoire au lieu de placer le système dans un mode dégradé et sûr.
Une source de la NASA m'a indiqué que le même échec d'allocation mémoire VxWorks a provoqué des crash logiciels sur au moins 6 autres missions. L'OS n'est pas en faute, mais c'est gros morceau de code complexe. Dans tous les (chaque?) cas, les ingénieurs ont utilisé VxWorks de manière incorrecte.
Nous semblons incapables d'apprendre des catastrophes des autres. Nous avons le droit de faire une erreur. Répéter la même erreur toujours et encore est une forme de folie.
Il est facile de blâmer les ingénieurs, mais ils ont quand même diagnostiqué ce problème complexe en utilisant un débogueur à 100 (resp 160) millions de miles (resp km) du système cible, ont trouvé une solution, et transféré un correctif.
Ces gars là sont fortiches.
À suivre
