Comment Apollo 11 a inventé le logiciel et le hardware modernes

Langage bas niveau, débogage et économie de code

A l'époque, ces programmes ont en plus dû être écrits en langage bas niveau. Et pour cause, la programmation haut niveau - comme le C - n'avait pas encore été inventée.

« Pour Apollo, tout le code a été fait en pur assembleur », confirme Ella Atkins. « Ce n'est qu'au moment la Navette Spatiale [en 1981], que l'on s'est dit que ce niveau de spécialisation et de surcharge de travail n'avaient plus vraiment de sens. Écrire un logiciel pour un système embarqué est plus facile aujourd'hui que dans les années 60 ».

La directrice du laboratoire de systèmes aérospatiaux autonomes souligne d'autres apports majeurs de cette première mission pour l'IT. « Apollo nous a appris que nous pouvions faire des calculs mathématiques suffisamment rapidement pour qu'une orbite soit calculée correctement. Nous avons aussi appris que l'on pouvait déboguer un code suffisamment bien pour qu'il fonctionne sans problème ».

Ce concept de débogage, dans le cadre d'une recherche de fiabilité absolue, a été crucial pour tous les logiciels développés depuis, tant pour les missions spatiales que pour les systèmes critiques sur Terre. « Un voyage pour la Lune ne peut pas être un aller simple. Jamais. La NASA devait s'assurer que l'équipage d'Apollo 11 rentrerait sur Terre sain et sauf », rappelle Paul Kostek.

Contrairement à des technologies grand public et aux applications Windows, « les ordinateurs de la mission avaient besoin d'un très haut niveau de fiabilité digne de cette mission spatiale », resitue le membre senior de l'IEEE. Pour y arriver, « la mission Apollo a utilisé le strict minimum de code nécessaire », explique-t-il. « Dans les années 1960, le logiciel était un monde relativement nouveau. Le module que Neil Armstrong a posé manuellement sur la lune n'embarquait que quelques milliers de lignes de code ».

Un bogue quand même

Et pourtant. Même avec cette économie, des débogages, et les tests, la mission n'échappa pas à l'incident logiciel.

Un documentaire de la BBC « 8 jours : aller et retour sur la Lune » (« 8 Days: To the Moon and back ») montre comment le module lunaire a rencontré une « erreur 1202 » juste avant le moment ô combien critique où Neil Armstrong et Buzz Aldrin entament leur descente finale vers la lune

L'erreur venait en fait de ce que le petit ordinateur du module lunaire avait très peu de mémoire, et que celle-ci avait été saturée par des données que Paul Adler - un de ses concepteurs - décrit aujourd'hui comme « une mauvaise configuration des commutateurs radar ».

A l'approche de la lune, Neil Armstrong demande des éclaircissements sur cette erreur 1202. Jack Garman, ingénieur informatique de la NASA qui travaillait à la Apollo Guidance Program Section, confirme alors au Centre de Contrôle (Mission Control) que l'erreur peut être ignorée. En fait, l'ordinateur de bord signalait juste qu'il était surchargé. La mission pouvait continuer.

Neil Amstrong obtempère et - malgré le « 1202 » - Apollo 11 touche le sol lunaire comme prévu, quelques secondes plus tard.

Au-delà d'Apollo

Pour Paul Kostek, « le plus gros problème des programmes aujourd'hui, ce sont leur taille et leur portée. Dans des systèmes aérospatiaux, vous devez avoir une confiance totale dans le code. Or il y a des millions de lignes dans les applications modernes. Combien de scénarios peut-on vraiment tester ? ».

Pour Ella Atkins, le travail de l'équipe de programmation de la Navette Spatiale (qui a commencé dix ans après Appolo) n'était peut-être pas un travail aussi « glamour » que celle d'Appolo, mais c'était la meilleure équipe du monde. « Tous les développeurs étaient tellement concentrés à chercher et à résoudre tous les problèmes possibles », avance-t-elle. Il n'en reste pas moins que c'est bien la mission de 1969 qui a posé les bases de l'IT moderne de la NASA.

Ella Atkins estime qu'une avancée majeure depuis Apollo 11 a été l'émergence de la « science autonome » - avec Earth Observing-1, un satellite de télédétection expérimental du programme New Millennium de la NASA. Lancée en novembre 2000, la mission initiale de l'engin spatial devait durer un an... mais il est resté en orbite 16 ans de plus, jusqu'en 2017.

« Pendant des décennies, [Earth Observing-1] a envoyé des données vers la Terre. Earth Observing-1 est un changement de paradigme. Avec lui, le logiciel a changé de statut. Le satellite a été capable d'envoyer des données scientifiques de façon sélective. Il a convaincu les scientifiques que le traitement embarqué pouvait avoir une vraie valeur ».

Le voyage interplanétaire de l'embarqué

« Depuis Apollo, toutes les sondes spatiales ont été sur-équipées technologiquement. Il faut entre 10 et 15 ans pour atteindre une planète. Et les sondes sont aujourd'hui conçues pour durer 30 ans, avec une durée de vie supplémentaire qui a été une chance incroyable pour les scientifiques », confirme Paul Kostek. « Ces systèmes sont simples et fiables ». Mais leur durée de vie impose qu'ils soient reprogrammables.

Ella Atkins acquiesce et explique que, étant donné les énormes distances qu'un engin spatial parcourt au cours d'une mission interplanétaire - les sondes qui s'aventurent dans les régions éloignées du système solaire doivent être conçues dès le départ pour s'adapter à l'inattendu, afin de pouvoir effectuer des expériences qui dépassent les objectifs de la mission initiale.

« Les rovers Spirit et Opportunity destinés à explorer le sol de Mars ont fonctionné beaucoup plus longtemps que ce qui était prévu au départ », illustre l'experte, « les scientifiques ont modifié et mis à jour leurs codes sources originaux ». La mission d'Opportunity est d'ailleurs iconique. Elle devait durer 90 jours. Elle s'acheva presque 15 ans plus tard, avec un message devenu légendaire : « My battery is low and it's getting dark » (« Mes réserves sont faibles et il commence à faire noir »).

Avec ces missions, le conservatisme historiquement lié aux voyages spatiaux a laissé place à l'adaptabilité, voire à l'expérimentation avec l'essai de nouveaux algorithmes, analyse Ella Atkins.

Toujours selon elle, deux autres missions - Galileo et Cassini - ont démontré les opportunités qu'il y avait à communiquer, à très longue distance, avec des objets programmables.

La sonde Galileo a été lancée en 1989 pour étudier Jupiter. Cassini a été lancée en 1997 pour étudier Saturne. La première devait finir sa mission en 1999, la deuxième en 2008. Elles ont finalement terminé leurs services en 2003 et en 2017 - les deux en s'écrasant volontairement pour ne pas contaminer les lunes de ces deux planètes, et les deux après avoir été prolongées à deux reprises.

« Dans les deux cas, il y a eu un moment où les ingénieurs se sont demandé ce qu'il fallait faire », raconte Ella Atkins. « Et à chaque fois, cela s'est traduit par des changements logiciels - soit pour améliorer l'exploration scientifique, soit pour corriger les problèmes matériels, [soit les deux] ». Par exemple, la NASA a installé plusieurs patches logiciels à Galileo, pour contrecarrer les conséquences sur plusieurs de ses éléments de l'intense rayonnement à proximité de Jupiter (enregistreur sur bandes, mémoire, instruments de mesures scientifiques, etc.).

C'est cette capacité d'adapter les systèmes informatiques au-delà des objectifs fixés lors de leur conception qui sous-tend aujourd'hui l'exploration spatiale. Une exploration spatiale lancée il y a tout juste 50 ans, et qui n'a - depuis - jamais cessé de changer la face de l'IT.