Comment la NASA a conçu l'ordinateur de bord à haute résilience d'Artemis II : une « architecture à défaillance silencieuse » maintient les systèmes opérationnels quelles que soient les pannes
La documentation de la NASA illustre le bond technologique entre les missions Apollo et le programme Artemis II. Elle met en lumière la complexité croissante des systèmes informatiques spatiaux. Contrairement aux équipements rudimentaires des années 1960, la capsule Orion repose sur une architecture « fail-silent » capable de détecter et d'isoler instantanément toute erreur de calcul causée par les radiations cosmiques. La documentation détaille une stratégie de redondance massive qui s'appuie sur huit processeurs synchronisés et un réseau Ethernet déterministe pour garantir une fiabilité absolue. D'autres couches de sécurité sont également présentes.
La mission Artemis II a été lancée avec succès le 1er avril 2026 par la NASA. Il s'agit d'un vol spatial habité visant à effectuer un survol de la Lune. Près de 54 ans après Apollo 17, une nouvelle mission spatiale habitée permet à l'homme de se rapprocher une nouvelle fois de son satellite naturel. Artemis II valide les systèmes de survie du vaisseau spatial Orion pour des missions de longue durée, notamment Artemis III et les futures missions vers Mars.
Le système informatique embarqué à bord de la mission Artemis II n'a plus rien à voir avec celui de l'époque Apollo. Il est décrit comme « le système informatique le plus tolérant aux pannes jamais développé pour les vols spatiaux ». Communications of the ACM en révèle quelques détails impressionnants.
Artemis III : une évolution majeure depuis l'époque Apollo
Pour mémoire, les astronautes des missions Apollo se sont rendus sur la surface lunaire à l'aide d'un ordinateur de bord doté d'un processeur de 1 MHz et d'environ 4 kilo-octets (Ko) de mémoire effaçable, soutenu par une mémoire « rope » fixe plus importante. Bien qu'il s'agisse d'une merveille de l'ingénierie des années 1960, le champ d'action de l'Apollo Guidance Computer était ciblé et ne couvrait pas la boucle de contrôle de tous les systèmes.
Les commandes environnementales et d'alimentation critique étaient gérées par des moyens manuels ou électromécaniques. La mission Artemis II s'appuie sur l'un des systèmes informatiques les plus résistants aux pannes jamais conçus pour les vols spatiaux. L'architecture informatique de la capsule Orion gère « la quasi-totalité des fonctions critiques pour la sécurité du vaisseau », du système de survie à l'acheminement des communications.
Cette telle architecture logicielle exige une fiabilité absolue : à environ 400 000 kilomètres de la Terre, une panne est irrémédiable. Aucune intervention physique n'est possible pour réparer un composant défaillant. Par conséquent, chaque sous-système doit être conçu pour résister aux inversions de bits dues aux rayons cosmiques, aux blocages induits par les radiations et aux défaillances matérielles sans la moindre seconde d’interruption.
« Nous concevons toujours nos systèmes de manière à pallier les défaillances matérielles. Outre des câbles physiquement redondants, nous avons des plans de réseau logiquement redondants. Nous avons des ordinateurs de vol redondants. Tout cela est mis en place pour pallier une défaillance matérielle », a déclaré Nate Uitenbroek, responsable de l’intégration et de la vérification logicielles au sein du programme Orion au Centre spatial Johnson.
Une architecture révolutionnaire à "défaillance silencieuse"
Pour garantir une sécurité absolue, la NASA a mis en œuvre une architecture dite « fail-silent » reposant sur une redondance massive. Le vaisseau spatial utilise deux ordinateurs de gestion de véhicule, contenant chacun deux modules de commande de vol (FCM), pour un total de quatre modules. Chaque module est lui-même composé d'une paire de processeurs qui s'autovérifient, ce qui signifie que huit processeurs fonctionnent en parallèle.
Selon la documentation, la philosophie technique repose sur une conception « sans signalisation des défaillances ». Si une erreur de calcul est détectée suite à un impact de rayonnement, le module fautif cesse immédiatement de transmettre des données plutôt que d'envoyer une commande erronée aux propulseurs. Un algorithme de sélection prioritaire prend alors le relais en choisissant le flux de données du module sain suivant dans la liste.
« Un ordinateur défectueux tombera en panne silencieuse, plutôt que de transmettre une mauvaise réponse », selon Nate Uitenbroek. Cette approche simplifie la tâche complexe du mécanisme de « vote » triplex qui compare les résultats. Elle est adaptée aux conditions extrêmes de l'espace lointain. La NASA prévoit des défaillances temporaires lors du passage de la mission Artemis II à travers les ceintures de Van Allen, où le rayonnement est intense.
« Nous pouvons perdre trois FCM en 22 secondes et continuer à voler en toute sécurité grâce au dernier FCM », note Nate Uitenbroek. Un FCM mis en veille ne devient pas un poids mort ; le système est conçu pour se réinitialiser, resynchroniser son état avec les modules en service et rejoindre le groupe en plein vol.
Déterminisme et synchronisation « rigoureuse » du réseau
Maintenir plusieurs ordinateurs indépendants en parfaite synchronisation constitue un défi technique majeur, car la moindre dérive temporelle peut entraîner une divergence entre des systèmes pourtant sains. La solution de la NASA réside dans une architecture strictement déterministe utilisant un réseau Ethernet. Le logiciel de vol opère selon un ordonnancement précis où les entrées et sorties sont parfaitement alignées sur le calendrier du réseau.
Chaque seconde, la dérive de chaque module est mesurée et son horloge locale est recalibrée sur le temps « vrai » du réseau. Si une application ne respecte pas son délai d'exécution strict, le module est automatiquement mis sous silence, réinitialisé, puis synchronisé à nouveau avec les autres modules en plein vol.
Cette discipline architecturale se fait de plus en plus rare dans le développement moderne. Michael Riley, chef d’équipe à l’Institut d’ingénierie logicielle de l’université Carnegie Mellon, si les générations précédentes travaillaient dans le cadre de contraintes matérielles strictes, le développement moderne des systèmes critiques est différent. Il a collaboré avec la NASA pour adapter des outils d’évaluation des risques à la mission Orion.
Il critique les approches Agile et DevOps. « Les approches Agile et DevOps modernes privilégient l'itération, ce qui peut remettre en cause la discipline architecturale. En conséquence, la dette technique s'accumule, et la maintenabilité ainsi que la résilience du système en pâtissent », explique Michael Riley.
Protection matérielle et redondance logicielle dissemblable
La protection du vaisseau ne se limite pas aux processeurs, mais s'étend à l'ensemble de l'infrastructure matérielle. La mémoire utilise une redondance modulaire triple qui corrige automatiquement les erreurs de bits à chaque lecture, tandis que le réseau lui-même est triplement redondant avec trois plans distincts. En complément de ce système primaire, Orion transporte un logiciel de vol de secours (BFS) totalement indépendant.
Le BFS utilise un matériel et un système d'exploitation différents du système principal afin d'éviter qu'une erreur de conception logicielle commune n'affecte les deux systèmes en même temps. Il fonctionne en permanence en arrière-plan et prend automatiquement le relais via la sélection de source en cas de défaillance des ordinateurs principaux. Si le système se retrouve sous le contrôle du BFS, il peut mener à bien toutes les phases dynamiques de la mission jusqu’à atteindre une phase de repos, moment auquel l’équipage peut tenter de rétablir les FCM principaux.
Orion utilise un réseau Ethernet synchronisé où le temps est réparti sur l’ensemble du système. Le logiciel de vol fonctionne selon des « trames principales » divisées en « trames secondaires », gérées par un planificateur conforme à la norme ARINC653. Le système utilise un partitionnement temporel et spatial pour planifier les partitions au sein de ces trames, garantissant que les entrées et les sorties sont parfaitement alignées sur le calendrier du réseau.
Protocoles de récupération et méthodes de vérification modernes
En cas de perte totale de puissance, Orion est programmé pour entrer dans un mode de sécurité une fois l'énergie rétablie. Il se stabilise de lui-même, oriente ses panneaux solaires vers le Soleil pour récupérer de l'énergie, puis tente de rétablir la communication avec la Terre. Pour garantir cette fiabilité, la NASA emploie des flux de vérification de pointe, incluant des simulations environnementales complètes et des tests de stress de type Monte-Carlo.
Selon la documentation, des superordinateurs sont utilisés pour injecter massivement des pannes matérielles catastrophiques dans les simulations afin de vérifier que le logiciel est capable de rester silencieux en cas d'erreur et de récupérer son état opérationnel sans mettre l'équipage en danger.
Conclusion
La mission Artemis II représente un bond technologique majeur par rapport aux missions Apollo. Contrairement aux systèmes anciens, les engins modernes comme Orion dépendent entièrement de l'informatique pour gérer des fonctions vitales face aux radiations cosmiques. Pour garantir une sécurité absolue, la NASA utilise désormais des simulations intensives et des tests de stress sur supercalculateurs afin de prévoir les pannes matérielles.
Cette architecture informatique à haute résilience ne se limite pas à l'exploration lunaire, car elle préfigure l'avenir de la fiabilité pour nos technologies terrestres. Ainsi, l'exigence de survie dans l'espace stimule une innovation majeure en matière de systèmes autonomes et d'infrastructures critiques.
Et vous ?
Quel est votre avis sur le sujet ?
Que pensez-vous de l'architecture informatique à haute résilience de la capsule Orion de la NASA ?
Les approches modernes Agile et DevOps remettraient en cause la discipline architecturale. Qu'en pensez-vous ?
Voir aussi
Les astronautes de la NASA sur Artemis pourraient parler à l'ordinateur d'un vaisseau spatial, « Amazon Alexa sur la lune ne peut pas devenir le HAL de 2001 », soutiennent certains ingénieurs
Elon Musk qualifiait la lune de « distraction » malgré les remarques des scientifiques : un an plus tard, SpaceX en fait sa priorité absolue et son PDG reporte Mars d'au moins sept ans
Agile est-il mort ? Pour un ingénieur « Le développement "agile" avec lequel nous sommes coincés aujourd'hui est une blague », il souligne ses dysfonctionnements dans les processus de développement en entreprise







Quel est votre avis sur le sujet ?
Répondre avec citation





Partager