- L’ordinateur de vol d’Orion, le vaisseau habité lunaire, repose sur une architecture bien plus résiliente et capable de contrôle automatique que les systèmes de l’ère Apollo, et gère l’ensemble des fonctions critiques, dont le maintien en vie, l’alimentation électrique et les communications
- Pour fonctionner sans interruption jusqu’à 250 000 miles de la Terre en orbite lunaire, il a été conçu pour résister aux pannes matérielles et aux effets des radiations grâce à une redondance physique et logique ainsi qu’à plusieurs ordinateurs de vol
- Chaque Flight Control Module (FCM) est composé d’une paire de processeurs à auto-vérification, pour un total de 8 CPU exécutés en parallèle, avec une conception fail-silent et un algorithme de sélection de sortie fondé sur les priorités afin d’isoler les erreurs
- Le système reste entièrement synchronisé grâce à une architecture déterministe et à l’Ethernet déclenché par le temps, avec un réseau et une mémoire triplement redondants capables de corriger automatiquement jusqu’aux erreurs d’un seul bit
- Si tous les systèmes principaux tombent en panne, un Backup Flight Software reposant sur un matériel et un système d’exploitation indépendants reprend le contrôle ; cette architecture est considérée comme un futur modèle de résilience always-on pour les systèmes autonomes
Conception par la NASA de l’ordinateur tolérant aux pannes d’Artemis II
- L’ordinateur de vol d’Artemis II repose sur une architecture offrant une résilience et des capacités de contrôle automatique bien supérieures à celles de l’ordinateur de navigation de l’ère Apollo
- L’ordinateur d’Apollo utilisait un processeur à 1 MHz et environ 4 KB de mémoire, et les principaux contrôles reposaient sur des commutateurs manuels ou des relais
- Dans la capsule Orion d’Artemis II, l’ordinateur gère directement toutes les fonctions critiques, dont le maintien en vie, l’alimentation électrique et les communications
- Comme un échec de mission à 250 000 miles de la Terre en orbite lunaire serait irrécupérable, le système doit continuer à fonctionner sans interruption malgré les radiations spatiales, les inversions de bits et les défaillances matérielles
- La NASA se prémunit contre les erreurs matérielles grâce à un câblage physiquement redondant, des plans réseau logiquement redondants et plusieurs ordinateurs de vol
-
The Power of Eight
- Orion adopte une architecture qui va au-delà de la triple redondance (triple redundancy) traditionnelle
- Deux Vehicle Management Computer (VMC) embarquent chacun deux Flight Control Module (FCM), pour un total de 4 FCM
- Chaque FCM est constitué d’une paire de processeurs à auto-vérification (self-checking), ce qui porte à 8 le nombre total de CPU exécutant le logiciel de vol en parallèle
- Le système repose sur une conception fail-silent : lorsqu’une erreur survient, le CPU fautif cesse immédiatement d’émettre au lieu de produire une sortie incorrecte
- Au lieu d’un vote majoritaire, il utilise un algorithme de sélection de source fondé sur les priorités pour choisir la sortie d’un canal sain
- La NASA anticipe des erreurs temporaires lors de la traversée de la ceinture de radiation de Van Allen ; même avec la perte de 3 FCM pendant jusqu’à 22 secondes, la mission peut continuer avec le dernier FCM restant
- Un FCM passé en mode silencieux peut, après réinitialisation, se resynchroniser avec les autres modules et réintégrer le vol en cours
- Orion adopte une architecture qui va au-delà de la triple redondance (triple redundancy) traditionnelle
-
Maintenir un fonctionnement déterministe
- Pour maintenir plusieurs ordinateurs indépendants en synchronisation complète (lockstep), une architecture déterministe (deterministic architecture) est utilisée
- Orion utilise un réseau Ethernet déclenché par le temps (time-triggered Ethernet) pour distribuer le temps à l’ensemble du système
- Le logiciel de vol s’exécute dans des trames majeures (major frame) et trames mineures (minor frame) gérées par l’ordonnanceur ARINC653
- Le partitionnement temporel et spatial garantit que les entrées et sorties sont parfaitement alignées sur le calendrier du réseau
- Chaque FCM reçoit les mêmes entrées, exécute le même code et produit les mêmes sorties
- Chaque seconde, la dérive d’horloge des FCM est mesurée puis recalibrée sur la référence temporelle du réseau
- Toute application qui ne respecte pas sa date limite (deadline) passe automatiquement en mode silencieux avant d’être resynchronisée
- Le matériel utilise une mémoire à triple redondance modulaire (TMR) pour corriger automatiquement les erreurs d’un seul bit, et les cartes d’interface réseau comparent aussi deux chemins de trafic afin de basculer en fail-silent en cas d’erreur
- Le réseau est triplement redondé sur trois plans indépendants, et tous les commutateurs disposent de fonctions d’auto-vérification
-
Système de secours final
- La NASA se prépare également à une défaillance de mode commun (common mode failure) pouvant affecter simultanément tous les canaux principaux
- Pour cela, elle embarque un système Backup Flight Software (BFS) distinct
- Le BFS repose sur un matériel différent, un système d’exploitation différent et un logiciel de vol simplifié développé indépendamment
- Si le système principal échoue, le BFS reprend automatiquement le contrôle afin de terminer les phases dynamiques de la mission
- L’équipage peut ensuite tenter de restaurer les FCM principaux
- La logique fail-silent est indispensable, mais elle doit s’accompagner de watchdogs et d’une supervision multicouche afin qu’aucune erreur ne reste non détectée
- Le système est aussi conçu pour survivre à une perte totale d’alimentation (dead bus)
- Au retour de l’alimentation, il passe automatiquement en mode sûr (safe mode)
- Il oriente ensuite les panneaux solaires vers le Soleil pour rétablir l’énergie, puis place le vaisseau queue vers le Soleil pour stabiliser sa température
- Il tente ensuite de rétablir les communications avec la Terre et, si nécessaire, l’équipage peut ajuster manuellement les équipements de maintien en vie
-
L’avenir de la fiabilité
- Le passage d’Apollo à Artemis traduit une augmentation spectaculaire de la complexité logicielle
- Apollo disposait de sauvegardes mécaniques, tandis que dans Artemis, le logiciel assure l’ensemble du contrôle
- La NASA utilise un workflow de vérification moderne comprenant la simulation environnementale complète, des stress tests Monte Carlo et de l’injection de pannes (fault injection) à grande échelle
- À l’aide de supercalculateurs, elle simule l’intégralité de la chronologie de vol et vérifie que le logiciel peut se rétablir en mode fail-silent même en cas de panne matérielle
- L’architecture à tolérance zéro d’Orion est considérée comme un modèle de résilience always-on pouvant aussi s’appliquer à l’avenir aux véhicules autonomes et aux réseaux de contrôle industriels
- Le passage d’Apollo à Artemis traduit une augmentation spectaculaire de la complexité logicielle
1 commentaires
Avis sur Hacker News
J’ai travaillé chez Stratus de 1989 à 1995 sur VOS et les performances des bases de données
Stratus était une entreprise de systèmes à tolérance aux pannes (fault-tolerant) fondés sur le matériel, tandis que son concurrent Tandem suivait une approche logicielle
L’architecture de Stratus reposait sur le modèle « pair and spare » : toutes les cartes étaient doublées et les sorties de chaque broche étaient comparées à chaque tick
Lors du passage de Motorola 68K à Intel, l’équipe hardware a rencontré de grosses difficultés à cause de broches inutilisées sur certaines instructions qui se retrouvaient flottantes
La formule du chercheur de la CMU disant que « Agile et DevOps ont affaibli la discipline architecturale » m’a marqué
On dirait qu’aujourd’hui on a oublié comment construire des systèmes déterministes
La planification stricte des trames de Time-triggered Ethernet donne l’impression d’un monde totalement différent des méthodes actuelles de développement logiciel
Certaines pratiques de développement modernes (tests unitaires, CI, etc.) ont aussi un effet positif dans ce type d’environnement
Aujourd’hui, avec le basculement vers un marché dominé par le commercial, les investissements ont baissé, mais il reste encore beaucoup d’algorithmes intéressants
Les travaux de Frank Mueller ou Johann Blieberger valent le détour
Dans des environnements aux entrées/sorties limitées comme les avions, une conception déterministe est parfaitement adaptée
En pratique, cela ressemble davantage à un bus matériel dédié qu’à de l’Ethernet
En voyant le défi « radiation hardening » de Code Golf, je me suis demandé si ce genre d’approche pouvait vraiment être utile
En pratique, c’est sans doute difficile car trop de problèmes à différents niveaux s’entremêlent, mais l’idée reste intéressante
La conception « fail-silent » décrite dans l’article était intéressante
Mais je me suis demandé comment on détecterait le cas où les deux CPU feraient simultanément un calcul erroné avec le même résultat
La probabilité que les deux CPU produisent simultanément la même erreur est bien plus faible que le FIT d’un CPU unique
Cela dit, dans l’espace, la loi de Murphy s’applique aussi, donc on ne peut pas l’exclure totalement
un « vote majoritaire à 25 % » pourrait malgré tout sélectionner le mauvais résultat
Je serais curieux d’avoir des détails concrets sur les CPU, la RAM, l’OS, le langage de ce système
J’aimerais aussi savoir à quelle fréquence le FCM passait en mode « fail-silent »
Il tourne généralement sur FreeRTOS ou RTEMS
Personnellement, j’ai trouvé la structure du projet trop complexe et difficile à manier
La plupart du code cœur de la NASA n’est pas public, mais cFS reste une bonne ressource pour apprendre une conception classique de logiciel de vol
L’article omet des détails sur le RTOS et l’architecture réellement utilisés
Le contrôle de vol principal d’Orion repose sur une architecture quadruplement redondante à base de Green Hills INTEGRITY RTOS et de processeurs BAE RAD750
Le BFS tourne sur un matériel complètement différent, LEON3 + VxWorks, et utilise le framework cFS de la NASA
C’est une architecture modulaire réutilisable également utilisée sur le télescope James Webb et les rovers martiens
Ce n’est pas simplement un schéma « système principal + secours », mais un concept de redondance hétérogène (dissimilar redundancy)
Plus de détails ici : document technique NASA 1, document 2
La réalisation concrète a été assurée par Lockheed Martin et ses sous-traitants
Quand les médias présentent cela comme si la NASA l’avait construit directement, c’est trompeur
Quand je travaillais comme développeur web il y a 25 ans, j’ai demandé à un ami passé par la NASA comment ils géraient les bugs
Il a ri avant de répondre : « Il n’y en avait pas »
Les développeurs d’aujourd’hui ont l’habitude d’environnements où l’échec ne met pas des vies en danger
Pour un service web, il s’agit surtout de pertes de revenus, alors que pour un vaisseau spatial, ce sont des vies humaines qui sont en jeu
J’ai autrefois développé un ordinateur résistant aux radiations,
et au-delà de la simple redondance, nous utilisions aussi des techniques de détection d’erreurs non redondantes
Je trouve dommage qu’on ne voie pas ce type d’approche dans ce système
afin de répartir la section efficace d’impact radiatif, ce qui constituait aussi une forme de durcissement physique
Toutes ces architectures redondantes sont impressionnantes, mais je me demande si une fonction de pilotage manuel (Manual Override) reste possible
J’aimerais savoir s’il est toujours possible de reprendre la main comme lors d’Apollo 11 et 13 quand c’est nécessaire
Comme les astronautes restent issus du monde des pilotes d’essai, j’imagine que oui