BIBLE MARS — DOSSIER DE RÉFÉRENCE
Avionique, logiciel de vol et FDIR : comment un vaisseau martien observe, décide et se sauve lui-même
Ordinateurs de bord, mémoire, bus de données, horloges, logiciel temps réel, watchdog, mode sûr, redondance, radiation, diagnostic et mises à jour lointaines.
Pourquoi ce dossier est indispensable
Ordinateurs de bord, mémoire, bus de données, horloges, logiciel temps réel, watchdog, mode sûr, redondance, radiation, diagnostic et mises à jour lointaines.
L’objectif est volontairement encyclopédique : partir du principe simple, montrer les interfaces et les calculs utiles, puis aller jusqu’aux pannes, aux essais, à la maintenance et à l’autonomie martienne.
1. L’avionique est le système nerveux numérique du véhicule
Capteurs, ordinateurs, mémoires, bus de données, entrées-sorties, horloges et logiciels relient presque tous les sous-systèmes. L’avionique ne « pilote » pas seule le vaisseau : elle transporte et traite l’information nécessaire à la navigation, au thermique, à l’énergie, aux communications, au support-vie et à la propulsion. Une architecture numérique défaillante peut donc rendre inutilisables des équipements mécaniquement sains. Pour Mars, l’enjeu supplémentaire est l’autonomie : la Terre ne peut pas intervenir à la milliseconde lorsqu’une anomalie apparaît.
2. Ordinateur de bord : plusieurs temporalités dans la même machine
Une boucle d’attitude doit traiter des mesures et commander des actionneurs dans un délai maîtrisé. Une compression d’image ou une analyse scientifique peut attendre davantage. Le logiciel répartit donc tâches et priorités. Un système temps réel garantit surtout que certaines réponses respectent des bornes temporelles ; il ne signifie pas simplement « très rapide ». Les ressources processeur et mémoire doivent être budgétées comme les watts et kilogrammes, avec une marge pour les évolutions logicielles.
3. Mémoire : conserver ce qui permet de redémarrer
La mémoire volatile sert au calcul courant ; la mémoire non volatile conserve logiciel, paramètres et données après une coupure. Une mission longue doit protéger au moins une image de logiciel connue et fiable, des paramètres de configuration et des journaux suffisants pour comprendre une panne. Des codes correcteurs et des opérations de scrubbing peuvent limiter certaines erreurs de bits. La stratégie doit aussi traiter l’usure, la corruption logique et la possibilité qu’une mise à jour soit mauvaise.
4. Bus de données : quand les équipements doivent parler la même langue
Un bus définit supports physiques, protocoles, messages, adresses, vitesse, temporisation et gestion des erreurs. Le choix dépend du besoin : déterminisme, débit, distance, redondance, simplicité et compatibilité. Un bus très rapide peut être inutile pour un thermostat, tandis qu’une caméra exige un débit élevé. La panne d’un bus peut isoler plusieurs équipements à la fois ; les topologies et chemins redondants doivent donc être analysés comme une architecture de réseau critique.
5. Horodatage : sans temps cohérent, les données perdent leur sens
Une mesure d’accélération, une image et une commande ne peuvent être comparées correctement si leurs horloges ne sont pas cohérentes. L’avionique distribue donc le temps et horodate les événements. Cette discipline aide aussi le diagnostic : après une panne, on cherche quelle alarme est apparue avant quelle coupure. Sur une mission interplanétaire, on distingue l’instant à bord, l’instant d’émission radio et l’instant de réception au sol, séparés par un délai de propagation important.
6. Rayonnement : prévoir que des bits changeront
Le rayonnement peut provoquer des erreurs transitoires dans l’électronique, voire des dommages plus graves selon l’événement et la technologie. La réponse combine choix de composants, blindage, correction d’erreurs, watchdogs, redondance et reconfiguration. La philosophie importante est de ne pas fonder la sûreté sur l’hypothèse « aucune erreur ne surviendra ». Le système doit reconnaître des comportements incohérents et retrouver un état contrôlé. La tolérance au rayonnement est donc une propriété de l’architecture complète, pas seulement d’une puce.
7. Logiciel de vol : rendre les modes explicites
Une machine à états définit les modes et les transitions permises. Initialisation, croisière, manœuvre, communication, sommeil et mode sûr n’autorisent pas les mêmes commandes. Les transitions doivent avoir des conditions et des temporisations claires. Un comportement implicite difficile à décrire est également difficile à tester. Pour une mission critique, on préfère des règles compréhensibles, journalisées et vérifiables à une accumulation de réactions cachées.
8. Watchdog et santé : vérifier plus que le simple fait que le processeur tourne
Un watchdog peut redémarrer un processeur qui ne donne plus signe de vie. Mais un logiciel peut continuer à s’exécuter tout en produisant une décision fausse. Les contrôles de santé surveillent donc aussi délais, valeurs plausibles, communications et cohérence entre capteurs. Trop sensibles, ils provoquent de fausses alarmes ; trop permissifs, ils laissent une panne s’étendre. Le réglage des seuils et temporisations fait partie de la sûreté.
9. FDIR : trois verbes différents
Détecter signifie reconnaître qu’une situation sort du comportement attendu. Isoler signifie identifier la fonction ou le composant probablement en cause. Récupérer signifie choisir une action : reconfigurer, redémarrer, basculer sur une voie de secours, couper une branche ou entrer en mode sûr. Ces étapes doivent être séparées intellectuellement. Une mauvaise isolation peut conduire à couper le mauvais équipement. Une récupération trop agressive peut transformer une anomalie bénigne en perte de fonction.
10. Mode sûr : minimum vital numérique
Le mode sûr cherche à stabiliser le véhicule avec un ensemble réduit de fonctions : attitude favorable, énergie positive, températures compatibles et communication minimale. Il doit être plus simple que le nominal mais n’est jamais indépendant de tout. Si son capteur de référence, son alimentation ou son logiciel est perdu, il peut lui-même être indisponible. Les analyses doivent donc identifier les dépendances du mode sûr et les cas où une intervention locale serait nécessaire.
11. Mises à jour à distance : changer le cerveau sans perdre le véhicule
Une correction logicielle peut être nécessaire après le lancement. Une mise à jour sûre utilise authentification, contrôle d’intégrité, image de secours et mécanisme de retour arrière. Le fichier doit être transmis malgré erreurs et interruptions, puis installé sans supprimer la capacité de redémarrer sur une version connue. Sur Mars, le délai radio rend précieuse une supervision locale. Une colonie devra conserver outils, compilateurs, clés, documentation et compétences pour ne pas dépendre éternellement d’un serveur terrestre.
12. Tester les combinaisons rares : là où se cachent les vraies surprises
Les scénarios dangereux combinent souvent plusieurs événements : capteur douteux pendant une manœuvre, reset lors d’une perte de communication, batterie froide pendant une reconfiguration. Les simulations, bancs software-in-the-loop et hardware-in-the-loop permettent d’injecter ces pannes. On mesure non seulement le résultat final, mais les temporisations, transitions et journaux. Une campagne qui ne teste que le nominal valide surtout que le cas facile fonctionne.
13. Télécommande et autonomie : qui a le droit de décider ?
Une architecture logicielle définit quelles décisions exigent une commande du sol, lesquelles peuvent être prises automatiquement et lesquelles nécessitent une confirmation humaine locale. Le délai Terre-Mars pousse davantage de décisions vers le bord, mais l’autonomie doit être encadrée. Des règles d’autorité évitent qu’un algorithme de récupération contredise une procédure équipage ou qu’une commande tardive du sol arrive dans un contexte qui a déjà changé.
14. Cybersécurité : authenticité et intégrité des commandes
Un vaisseau qui accepte des commandes doit vérifier qu’elles viennent d’une source autorisée et qu’elles n’ont pas été altérées. Les mises à jour logicielles exigent les mêmes protections. La cybersécurité ne se réduit pas au chiffrement : gestion des clés, séparation des domaines, journalisation et capacité de récupération sont également nécessaires. Sur Mars, une base doit pouvoir continuer localement même si un lien avec la Terre ou un service distant est indisponible.
15. Intelligence artificielle : utile, mais sous contraintes
Des méthodes d’IA peuvent aider à analyser images, détecter anomalies ou optimiser opérations. Mais une fonction critique doit rester testable, surveillable et entourée de limites. Un modèle performant sur ses données d’essai peut rencontrer un cas hors distribution. L’architecture doit donc définir où l’IA conseille, où elle commande, quelles vérifications indépendantes existent et comment revenir à un comportement simple. L’autonomie ne doit pas rendre le système incompréhensible au moment où il faut le dépanner.
16. Gestion des données scientifiques et opérationnelles
Le vaisseau produit davantage de données qu’il ne peut parfois transmettre immédiatement. L’avionique doit décider quoi stocker, compresser, dupliquer ou supprimer. Les données de santé et d’anomalie peuvent être plus urgentes que certaines images ; un fichier scientifique rare peut mériter une copie redondante. Les politiques de stockage doivent aussi gérer la saturation : un journal qui grossit sans limite ne doit pas remplir toute la mémoire. Pour Mars, ces principes deviennent ceux d’un centre de données autonome, avec archivage local, réplication, priorités et capacité à fonctionner pendant des jours ou semaines avec un lien Terre dégradé.
Approfondissements transversaux : ce que le cours simplifié ne doit pas faire oublier
Les points suivants complètent la lecture système et permettent de relier ce dossier aux cours de la Space Academy.
AM-09.05 — Ordinateur de bord et données : calculer, mémoriser, commander et télémesurer
L’ordinateur de bord est un orchestrateur, pas seulement un calculateur
Il reçoit des télémesures, exécute des commandes, horodate des événements, supervise des bus de données, lance des algorithmes GNC, stocke des données et contribue à la détection des pannes. Certaines fonctions sont temps réel : une boucle d’attitude ne peut pas attendre plusieurs secondes qu’un autre logiciel termine. D’autres sont moins urgentes, comme compresser une image scientifique. L’architecture informatique répartit donc priorités, processeurs, mémoires et réseaux selon les délais et les conséquences d’une perte.
Mémoire volatile, non volatile et données de survie
La RAM est rapide mais perd généralement son contenu sans alimentation. Une mémoire non volatile conserve code, paramètres et données après redémarrage. Pour une mission longue, il faut protéger les images logicielles de référence, journaux d’anomalies et configurations capables de restaurer un état sûr. La mémoire elle-même peut subir erreurs de bits dues au rayonnement. Des codes de correction d’erreur, scrubbing, copies redondantes et redémarrages contrôlés contribuent à la résilience.
Les bus de données sont des routes partagées
Capteurs, actionneurs et ordinateurs échangent leurs données via des liaisons et protocoles. Débit, latence, déterminisme, topologie et tolérance aux pannes déterminent le choix. Un bus très rapide n’est pas nécessairement meilleur s’il augmente complexité, consommation ou sensibilité. Il faut aussi gérer les adresses, priorités, synchronisation et erreurs. Une panne de réseau peut rendre des équipements sains inaccessibles ; l’architecture de communication interne fait donc partie de la sûreté du véhicule.
Le temps est une donnée de navigation et de diagnostic
Deux mesures prises à des instants différents ne peuvent pas être fusionnées correctement si leur horodatage est faux. Une dérive d’horloge peut donc affecter navigation, communication, séquences et reconstruction d’une panne. Le véhicule maintient des références temporelles, distribue le temps aux équipements et enregistre les événements. Pour les opérations à longue distance, il faut aussi distinguer le temps embarqué, le temps de réception au sol et les délais de propagation.
Rayonnements et informatique : penser à l’erreur transitoire
Une particule énergétique peut modifier temporairement un bit ou perturber un circuit sans détruire définitivement le matériel. On parle notamment de single-event upset pour certains événements. Le système doit donc distinguer erreur récupérable et dommage permanent. La tolérance peut combiner composants adaptés, blindage, redondance, vote, mémoire corrigée, watchdog et reconfiguration. L’objectif n’est pas de prétendre qu’aucune erreur n’arrivera, mais de continuer à fonctionner ou de revenir dans un état sûr lorsque l’erreur survient.
Observabilité : une panne impossible à expliquer est une panne difficile à réparer
Si le logiciel se contente d’afficher « erreur », l’équipage ou le sol manque d’informations. Des journaux structurés enregistrent événements, valeurs importantes, changements de mode, resets et messages de bus. Il faut cependant gérer le volume : conserver tout en permanence peut saturer la mémoire ou le lien radio. On choisit donc niveaux de journalisation, fenêtres temporelles et priorités. Une bonne observabilité permet de reconstituer la séquence causale après une anomalie.
Architecture distribuée et autonomie martienne
Un véhicule habité ou une base peut répartir le calcul entre plusieurs contrôleurs locaux plutôt que dépendre d’un unique ordinateur central. Cette distribution peut isoler des pannes et réduire le câblage, mais elle complique synchronisation, mise à jour logicielle et diagnostic. Sur Mars, la maintenance doit considérer aussi les fichiers de configuration, outils de programmation, versions de firmware et capacité à remplacer un calculateur par un matériel compatible. L’avionique devient donc une chaîne logistique numérique autant qu’un ensemble de cartes électroniques.
Ouvrir le cours Space Academy correspondant
AM-09.06 — Logiciel de vol, watchdog, FDIR, redondance et mode sûr
Le logiciel de vol est une machine à états
Un logiciel spatial robuste décrit explicitement des modes et transitions : initialisation, nominal, manœuvre, communication, mode sûr, récupération, etc. Chaque transition possède des conditions d’entrée et des actions. Cette approche réduit les comportements implicites qui deviennent difficiles à tester. Une commande qui est valide en croisière peut être interdite pendant une manœuvre. Les machines à états rendent ces règles visibles et facilitent la vérification des chemins rares.
Watchdog : surveiller le surveillant
Un watchdog est un mécanisme qui attend un signe périodique prouvant que le logiciel ou un processeur fonctionne. Si ce signe disparaît, il peut déclencher un reset ou une reconfiguration. Mais un watchdog mal conçu peut provoquer des redémarrages inutiles ou ne rien détecter lorsqu’un logiciel tourne mais produit de mauvaises décisions. Il faut donc définir ce qui est réellement surveillé : simple activité du processeur, respect d’un délai, cohérence de données ou combinaison de plusieurs critères.
FDIR : détecter, isoler et récupérer
FDIR signifie Fault Detection, Isolation and Recovery. Détecter répond à « quelque chose est-il anormal ? ». Isoler répond à « où est la cause probable ? ». Récupérer répond à « quelle action permet de continuer ou de se mettre en sécurité ? ». Ces trois étapes sont différentes. Couper immédiatement un équipement à la première mesure suspecte peut transformer une fausse alarme en vraie perte de mission. À l’inverse, tolérer trop longtemps une anomalie peut propager le défaut.
Mode sûr : survivre n’est pas accomplir la mission
Le mode sûr réduit souvent les objectifs pour préserver énergie, température, attitude et communication minimale. Il doit être suffisamment simple pour rester disponible lorsque le reste du système est douteux. Mais il n’est pas magique : un mode sûr exige toujours des capteurs, de l’énergie, du logiciel et des actionneurs. Il faut donc analyser quelles pannes peuvent empêcher même son activation et prévoir des chemins de récupération appropriés.
Redondance logicielle et cause commune
Deux ordinateurs exécutant exactement le même code peuvent prendre exactement la même mauvaise décision si l’erreur est dans l’algorithme ou les données. On distingue redondance matérielle et diversité de conception. Dans certains cas, une fonction de sauvegarde volontairement plus simple peut être plus robuste qu’une copie complète. Mais la diversité coûte en développement, vérification et maintenance. Le bon choix dépend de la criticité et des scénarios crédibles.
Tester les cas rares avant qu’ils ne deviennent réels
Les pannes critiques apparaissent justement dans des combinaisons peu fréquentes : capteur en défaut pendant une manœuvre, communication perdue durant un redémarrage, batterie froide lors d’une transition, etc. La simulation, le software-in-the-loop puis le hardware-in-the-loop permettent d’injecter des anomalies et de tester les réactions. On vérifie aussi les temporisations, les courses entre tâches et les transitions après reset. Une campagne de test qui ne couvre que le nominal donne une confiance trompeuse.
Mise à jour logicielle loin de la Terre
Un logiciel peut nécessiter une correction après le lancement. Mettre à jour un véhicule lointain exige une image validée, un protocole de transfert robuste, une copie de secours et un moyen de revenir à l’ancienne version si la nouvelle ne démarre pas. Le délai radio impose parfois d’exécuter l’opération avec une grande autonomie locale. Pour une base martienne, conserver outils de compilation, signatures, procédures et compatibilités devient une question de souveraineté technique autant que de maintenance.
Sources NASA primaires
Ces références servent de garde-fou documentaire ; elles ne transforment pas les choix prospectifs de cette page en architecture officielle NASA.