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
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é.
Interfaces critiques et conséquences système souvent oubliées
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.
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.
Approfondissement d’ingénierie — construire un cerveau de bord vérifiable, reconfigurable et capable de douter
La redondance informatique n’a de valeur que si les voies peuvent réellement se départager
Deux ordinateurs identiques qui produisent des réponses différentes posent une question : lequel croire ? Trois voies peuvent voter, mais trois copies identiques exposées au même logiciel et aux mêmes données peuvent partager la même erreur. La redondance matérielle protège bien contre certaines pannes de composant ; elle protège moins contre un défaut de spécification ou un bug commun. La conception doit donc distinguer panne aléatoire et cause commune.
Les architectures peuvent séparer les domaines : calcul nominal, surveillance indépendante, protections simples et commande de secours. Une fonction de sauvegarde moins sophistiquée peut être plus crédible précisément parce qu’elle partage moins de code. Le but n’est pas de multiplier les processeurs mais d’éviter qu’une erreur unique puisse neutraliser toutes les barrières.
Le vote doit aussi traiter l’incertitude. Trois capteurs ne donnent jamais exactement la même valeur. Il faut définir des tolérances, détecter une dérive et décider quand une voie est exclue. Un vote majoritaire naïf peut conserver deux capteurs vieillissant ensemble et écarter le seul correct. La cohérence physique avec d’autres mesures devient alors une source d’information supplémentaire.
Les modes doivent représenter des états de mission, pas seulement des états logiciels. « Nominal », « safe mode » ou « maintenance » ne devraient pas être de simples étiquettes dans le code. Chaque mode doit préciser quelles fonctions sont actives, quelles commandes sont autorisées, quelles ressources sont prioritaires et comment la transition s’effectue. Une transition mal conçue peut être plus dangereuse que le mode lui-même : deux sous-systèmes peuvent croire être dans des états différents.
Le véhicule doit donc posséder une machine d’état globale ou au minimum des contrats d’interface cohérents. Lors d’un passage en mode sûr, l’orientation, l’énergie, le thermique, les communications et la propulsion doivent converger vers une configuration compatible. Un sous-système qui attend une commande d’un ordinateur déjà isolé peut bloquer la récupération.
Les transitions doivent être testées dans les deux sens. Il est fréquent de vérifier l’entrée en mode sûr et moins de vérifier le retour. Or une mission Mars peut rester des heures ou des jours en configuration dégradée. Le redémarrage doit tenir compte des températures, de la charge batterie, des données accumulées et de l’état réel des mécanismes.
Mettre à jour à distance suppose de pouvoir revenir en arrière. Une mission de plusieurs années rencontrera probablement des défauts logiciels ou de nouveaux besoins. Interdire toute mise à jour est irréaliste ; autoriser des changements non maîtrisés est dangereux. La stratégie doit prévoir des images logicielles signées, une banque de secours, une installation par étapes et un retour automatique si les tests de santé échouent.
La mise à jour ne concerne pas seulement le code. Les paramètres, tables de calibration, modèles de capteurs et règles FDIR peuvent changer le comportement sans modifier l’exécutable. Ils doivent donc suivre la même discipline de version et d’approbation. Un véhicule où l’on connaît la version du programme mais pas celle des tables de seuils n’est pas maîtrisé.
Le délai de communication renforce la nécessité de tests locaux. Avant d’activer un nouveau logiciel sur la chaîne principale, le véhicule peut l’exécuter sur un banc redondant, rejouer des données enregistrées et comparer les sorties. Cette pratique rapproche le vaisseau d’un centre de calcul autonome qui possède sa propre capacité d’intégration.
La cybersécurité devient une fonction de sûreté de fonctionnement. Sur un véhicule lointain, une commande malveillante et une commande corrompue par erreur peuvent produire le même effet physique. L’authentification, l’intégrité et la gestion des clés doivent donc être conçues avec les fonctions de commande. La sécurité informatique ne peut pas être ajoutée après coup sans toucher l’architecture.
Les mécanismes de protection doivent néanmoins éviter le verrouillage fatal. Une clé expirée ou une horloge désynchronisée ne doit pas rendre impossible une commande de secours. Il faut prévoir des procédures d’urgence, des rôles séparés et des moyens de récupération qui ne créent pas une porte ouverte permanente. Le compromis entre sécurité et disponibilité est particulièrement aigu lorsqu’aucun technicien ne peut physiquement accéder au système.
À l’échelle d’une colonie, les domaines doivent être segmentés : réseaux de contrôle vital, administration, recherche, usages personnels et industrie. La connexion généralisée simplifie les échanges mais élargit les chemins d’attaque et les causes communes. Une ville martienne aura besoin d’une architecture cyber comparable à celle d’infrastructures critiques terrestres.
Une IA utile doit être confinée par des invariants vérifiables. L’intelligence artificielle peut aider à diagnostiquer, planifier ou classer des anomalies, mais elle ne devrait pas obtenir une autorité illimitée simplement parce qu’elle est performante. Les fonctions vitales peuvent être protégées par des invariants : limites de pression, température, énergie, orientation ou séparation que l’IA ne peut pas violer. Une couche déterministe valide alors la proposition avant action.
La provenance est essentielle. Si l’IA recommande de couper une pompe, l’opérateur doit savoir quelles mesures et quelles hypothèses conduisent à cette recommandation. Une explication rhétorique ne suffit pas ; il faut des liens vers l’état du système, les événements et la règle de sécurité concernée. Cela permet à l’humain de détecter une conclusion basée sur une donnée obsolète.
Enfin, l’IA doit pouvoir être désactivée. Le véhicule doit conserver un noyau de fonctions pilotables avec des logiques plus simples, même si les performances diminuent. La robustesse ne consiste pas à rendre l’IA parfaite ; elle consiste à garantir que l’échec de l’IA ne devienne pas l’échec du véhicule.
Rendre le logiciel modifiable sans rendre le véhicule imprévisible
Séparer les fonctions vitales des fonctions évolutives
Un vaisseau martien a besoin de logiciel capable d’évoluer pendant des années, mais toute mise à jour accroît le risque de régression. Une architecture robuste sépare les noyaux de sûreté — gestion des modes, protections essentielles, interfaces critiques — des fonctions pouvant être enrichies plus fréquemment. Cette séparation ne signifie pas que le noyau est immuable ; elle signifie que son cycle de modification est plus strict, avec davantage de preuves et de tests.
Le versionnage doit conserver logiciel, paramètres, modèles et données de calibration. Dire qu’un véhicule utilise « la version 7 » n’est pas suffisant si une table de capteurs ou un seuil FDIR a changé séparément. La configuration réellement exécutée doit pouvoir être reconstruite et comparée à la configuration validée.
Préparer le retour arrière comme une fonction normale. Une mise à jour réussie au banc peut échouer dans une configuration réelle inattendue. Le système doit donc posséder une stratégie de rollback, c’est-à-dire de retour à une version précédente, ainsi qu’un mode sûr capable de démarrer avec un ensemble minimal de fonctions. Les données créées après l’update doivent être compatibles ou convertibles ; sinon le retour arrière peut restaurer le programme mais perdre la capacité à lire son propre état.
Les mises à jour lointaines doivent être transactionnelles autant que possible : transfert vérifié, installation dans une partition inactive, test, bascule contrôlée puis surveillance. Une coupure de communication au milieu du processus ne doit pas laisser l’ordinateur dans un état intermédiaire ambigu.
Encadrer l’IA par des invariants et une autorité explicite. Une IA peut aider à classer des anomalies, rechercher des procédures ou proposer un diagnostic. Elle ne doit pas devenir une source d’autorité implicite simplement parce que son texte paraît convaincant. Pour les fonctions critiques, les limites doivent être définies en termes d’invariants vérifiables : pression à ne pas dépasser, zones interdites, états de vannes, enveloppes thermiques, réserves minimales et actions nécessitant une approbation humaine.
Cette doctrine permet d’utiliser des modèles plus puissants sans confondre recommandation et commande. Le journal doit conserver la donnée observée, la proposition, l’autorité qui a décidé et l’action réellement exécutée. Ainsi, une future analyse peut distinguer une erreur de capteur, une mauvaise recommandation, une validation humaine insuffisante ou une exécution défectueuse.
Cas de vérification et marges opérationnelles
Qualifier les changements par campagnes de régression représentatives
Une mise à jour critique doit être testée contre une bibliothèque de scénarios représentant l’histoire du système : démarrage nominal, capteur biaisé, donnée absente, redémarrage en cours de manœuvre, saturation du réseau, perte d’un actionneur et combinaison de pannes. Le résultat attendu n’est pas seulement « le test passe », mais un comportement traçable : mode choisi, alarmes émises, commandes interdites et état final. Cette bibliothèque s’enrichit après chaque incident important.
Lorsque le matériel vieillit, certains tests doivent également utiliser des valeurs proches des limites et non uniquement des données idéales. Un logiciel parfaitement robuste avec des capteurs neufs peut devenir instable face à des dérives lentes. La validation doit donc intégrer les marges réellement observées dans la flotte. Sur Mars, qualification logicielle et maintenance matérielle finissent par partager les mêmes données de santé.
Le même principe vaut pour les données de configuration envoyées depuis la Terre. Un nouveau seuil, une table de calibration ou une règle de reconfiguration doit suivre le même circuit de vérification qu’un logiciel, car une simple valeur peut modifier le comportement d’un système critique. Le paquet de changement devrait donc porter un identifiant, une justification, les versions compatibles, les tests exécutés, une procédure de retour arrière et la personne ou l’autorité ayant approuvé le déploiement. Cette discipline évite qu’une colonie accumule des « petits réglages » impossibles à reconstruire quelques mois plus tard.
L'avionique est le système qui transforme des mesures imparfaites en décisions exécutables
Dans un vaisseau interplanétaire, l'avionique ne se réduit pas à « l'ordinateur de bord ». Elle englobe calcul, mémoire, réseaux de données, acquisition de capteurs, interfaces avec actionneurs, horloges, logiciels de vol et moyens de diagnostic. La NASA décrit l'avionique comme l'infrastructure de commande et de gestion de données sur laquelle reposent les fonctions du véhicule. Pour Mars, la caractéristique essentielle est l'autonomie : une alarme ne peut pas attendre vingt minutes qu'un spécialiste au sol décide si un capteur est en panne ou si une action immédiate est nécessaire.
L'ordinateur reçoit des mesures qui ont du bruit, des biais et parfois des valeurs manquantes. Le logiciel doit distinguer une transition physique réelle d'une erreur de mesure. Cela demande des contrôles de plausibilité, des comparaisons entre capteurs, des modèles d'état et des délais de confirmation. Un capteur de température qui saute brutalement de 20 à 120 °C alors que les capteurs voisins restent stables n'implique pas automatiquement un incendie ; mais ignorer le signal peut être catastrophique. La décision dépend donc du contexte, des tendances et de la criticité.
FDIR : détecter, isoler, récupérer sans créer une deuxième panne
FDIR signifie Fault Detection, Isolation and Recovery : détection, isolement et récupération après panne. Un système bien conçu possède des seuils et logiques qui évitent deux extrêmes : ne rien faire face à une panne réelle, ou basculer trop agressivement sur un équipement sain et provoquer une instabilité. Une récupération peut consister à redémarrer un logiciel, isoler une branche électrique, sélectionner un capteur de secours, geler une commande ou passer en mode sûr.
Le mode sûr n'est pas « l'arrêt ». Il doit maintenir une attitude, une puissance et une thermique compatibles avec la survie du véhicule, préserver les données nécessaires au diagnostic et rouvrir progressivement les fonctions. La conception doit identifier les conditions dans lesquelles le mode sûr lui-même devient dangereux : manque de puissance, orientation thermique défavorable, perte de communication ou besoin médical urgent.
La tolérance aux radiations se construit de la pièce au logiciel
Les composants électroniques peuvent subir dose ionisante cumulée et événements ponctuels. Une stratégie peut combiner composants qualifiés, redondance, codes correcteurs d'erreurs en mémoire, scrubbing périodique, watchdogs et capacité de redémarrage. Aucun mécanisme n'est parfait. Une mémoire protégée contre certains bit flips peut toujours être vulnérable à une panne d'alimentation ou à une erreur logicielle commune. La diversité des défenses est donc plus importante qu'un slogan « radiation hardened ».
Un exemple simple : si un système produit en moyenne un événement mémoire corrigible toutes les 200 heures sur un ensemble donné, un transit de 6 000 heures conduirait à un ordre de grandeur de 6 000 ÷ 200 = 30 événements attendus, si le taux restait constant. Ce n'est pas une prédiction de mission ; cela montre que « faible taux » ne signifie pas « zéro événement » sur une longue durée. Le logiciel doit traiter l'événement corrigé comme une donnée de santé, suivre sa fréquence et détecter une dérive.
Le logiciel de vol doit pouvoir évoluer sans effacer la configuration validée
La NASA utilise des cadres comme core Flight System et des pratiques de développement qui relient exigences, modèles, tests automatisés et intégration. Sur une mission martienne, une mise à jour peut être nécessaire pour corriger un défaut ou améliorer l'autonomie. Elle doit pourtant rester réversible. Le véhicule doit connaître la version active, disposer d'une image de secours, vérifier l'intégrité du paquet reçu et conserver une voie de démarrage minimale si l'installation échoue.
La capacité à modifier un logiciel ne doit jamais devenir une excuse pour livrer une architecture matériellement fragile. Les fonctions de sûreté essentielles doivent conserver des protections indépendantes lorsque cela est possible. Le logiciel est très puissant pour reconfigurer, filtrer et décider ; il partage aussi des causes communes qui peuvent affecter simultanément plusieurs fonctions.
Le journal d'événements devient un instrument scientifique de la fiabilité
Un vaisseau autonome doit enregistrer non seulement les alarmes mais leur contexte : mesures avant et après, commandes exécutées, changements de mode, version logicielle et résultat de la récupération. Après plusieurs mois, ce journal permet d'identifier des pannes intermittentes et de mettre à jour les modèles de risque. C'est une différence fondamentale entre un appareil qui « fonctionne » et un système capable d'apprendre de sa propre histoire technique.
Repères primaires
NASA Small Spacecraft Avionics, mai 2026 : calcul embarqué, mémoires, bus et logiciel. Core Avionics & Software Technologies : pratiques de développement et cFS. JSC Software & Autonomous Subsystems : logiciels de vol, contrôle autonome et exploration humaine.
Le logiciel de vol doit pouvoir expliquer ce qu'il croit vrai. Un système autonome n'est pas fiable parce qu'il possède davantage d'algorithmes. Il devient fiable lorsque ses estimations, hypothèses et modes sont observables. Si l'avionique décide qu'un capteur est défaillant, l'équipage doit pouvoir savoir quels symptômes ont conduit à cette conclusion, quelle source le remplace et quelle incertitude supplémentaire en résulte. Sans cette transparence, une bonne décision automatique peut être interprétée comme une panne et annulée par l'opérateur.
Le FDIR — détection, isolation et récupération des fautes — doit distinguer anomalie physique et anomalie de données. Un capteur bloqué, un message retardé, un paquet corrompu et un véritable changement de température peuvent produire des symptômes proches. Les filtres de plausibilité utilisent redondance, modèle et cohérence temporelle. Mais un modèle trop rigide peut rejeter un phénomène réel inattendu : l'autonomie doit donc savoir déclarer « inconnu » plutôt que forcer un diagnostic.
La configuration logicielle devient particulièrement critique pendant une mission de plusieurs années. Une mise à jour corrige un défaut mais peut modifier timing, mémoire, communications et interactions. Le véhicule doit conserver version précédente, preuve d'intégrité, procédure de retour arrière et description des changements. L'existence d'un lien interplanétaire ne signifie pas qu'une mise à jour terrestre puisse être appliquée comme sur un ordinateur domestique.
Les événements radiatifs introduisent des fautes transitoires. La mémoire peut être protégée par correction d'erreur, scrubbing et redondance ; les calculateurs peuvent surveiller divergences et redémarrer des partitions. Mais une réinitialisation automatique répétée peut masquer un défaut matériel durable. Les journaux doivent permettre de reconstruire fréquence, localisation et contexte des événements afin d'adapter le mode de fonctionnement.
Le test logiciel doit couvrir le système physique qu'il commande. Une simulation peut vérifier des milliers de cas sans révéler qu'une vanne réelle met deux secondes de plus à se déplacer à froid. Le matériel dans la boucle, les injections de fautes et les scénarios temporels sont essentiels. L'assurance logicielle concerne donc autant les hypothèses sur le monde que les lignes de code.
Pour Mars, le défi ultime est l'autorité pendant la perte de liaison. Le logiciel doit être capable de protéger le véhicule, mais l'équipage conserve une responsabilité de mission. Les règles d'escalade doivent préciser quelles actions sont automatiques, lesquelles demandent confirmation et lesquelles sont interdites sans plusieurs preuves indépendantes. C'est une constitution technique de l'autonomie.
Étude de cas : trois capteurs ne sont pas forcément trois vérités. Trois capteurs de pression surveillent une même boucle. Deux indiquent une baisse lente, le troisième reste stable. Une logique de vote majoritaire conclurait immédiatement que le troisième est défaillant. Mais si les deux capteurs « d'accord » partagent alimentation et conditionnement analogique, une dérive commune peut tromper le vote. Le FDIR doit connaître l'indépendance réelle des chaînes, pas seulement compter les valeurs.
Le logiciel compare alors d'autres preuves : débit, position de vanne, température, consommation de la pompe et modèle dynamique de la boucle. Si ces informations corroborent la baisse, le diagnostic gagne en confiance. Si elles contredisent les deux capteurs, l'état doit rester ambigu. Cette capacité à conserver plusieurs hypothèses évite de transformer une incertitude en mauvaise action certaine.
Le temps est crucial. Une fuite lente autorise plusieurs secondes ou minutes de vérification ; une dépressurisation rapide exige une action conservatrice immédiate. Les seuils FDIR doivent donc intégrer vitesse de variation et conséquence. Un algorithme identique ne convient pas à tous les phénomènes.
Supposons ensuite qu'une mise à jour logicielle récente ait modifié la calibration des deux capteurs. L'historique de configuration devient une donnée de diagnostic. Le système peut comparer comportement avant/après mise à jour, revenir au paramètre précédent ou isoler la nouvelle fonction. Sans journal de version, l'équipage chercherait uniquement une panne matérielle.
Après récupération, les données sont conservées pour analyse. Le but n'est pas seulement d'éviter la panne suivante, mais d'améliorer la capacité à distinguer les causes. Une mission martienne autonome accumule ainsi une connaissance locale des comportements réels de son véhicule. Le logiciel de bord devient progressivement meilleur parce que les preuves de terrain reviennent dans ses modèles et procédures.
Faire de l’avionique un système de décision explicable et récupérable
Une mesure n’est pas encore une vérité
Un capteur fournit une tension, un compteur, une fréquence ou un paquet de données. L’avionique doit transformer cette observation en grandeur physique, lui associer une date, une qualité et une incertitude, puis décider si elle est compatible avec les autres observations. Cette chaîne est essentielle sur Mars car un équipage ne peut pas demander immédiatement à une équipe au sol de trancher chaque ambiguïté. Le logiciel doit savoir distinguer absence de mesure, mesure douteuse, mesure hors plage et désaccord entre capteurs.
La fusion de données ne doit pas effacer le désaccord. Une température moyenne calculée à partir de trois sondes peut sembler rassurante alors que l’une d’elles dérive lentement. Il faut conserver les résidus, les tendances et les indicateurs de santé. Une alarme utile n’est pas seulement « température haute » : elle peut préciser quel capteur s’écarte, depuis combien de temps, avec quelle cohérence par rapport au débit et à la puissance thermique. L’explication accélère le diagnostic humain.
Le temps est lui-même une mesure critique. Si deux calculateurs horodatent différemment la même séquence, une analyse de cause peut inverser l’ordre apparent des événements. Les réseaux doivent donc surveiller synchronisation, dérive d’horloge et qualité du temps distribué. Une mission martienne peut tolérer plusieurs minutes de délai avec la Terre ; elle ne peut pas tolérer que ses propres systèmes ignorent quel événement local a précédé l’autre de quelques millisecondes.
FDIR : détecter, isoler, récupérer sans masquer l’incertitude
La détection répond « quelque chose n’est plus cohérent ». L’isolation cherche la frontière du défaut. La récupération choisit une configuration qui restaure une fonction ou au moins empêche la situation de s’aggraver. Ces trois étapes doivent rester séparées parce qu’une détection rapide ne garantit pas une isolation correcte, et une récupération lancée sur un diagnostic faux peut aggraver la panne.
Un exemple simple est la perte apparente d’une pompe. Le courant moteur tombe à zéro et le débit diminue. Le défaut peut venir de la pompe, du contacteur, de l’alimentation, du capteur de courant, du capteur de débit ou de la commande logicielle. Le FDIR doit chercher des preuves indépendantes avant de déclarer la pompe morte. Une bascule automatique vers la redondance est pertinente si le coût d’une erreur est faible ; elle peut être dangereuse si les deux voies partagent le même défaut amont.
La récupération doit être réversible lorsque l’incertitude reste forte. Safe mode, limitation de puissance, gel d’une action ou bascule sur un estimateur plus simple sont des moyens de gagner du temps. L’objectif n’est pas toujours de retrouver immédiatement la performance nominale. Il est souvent de conserver un état où l’équipage dispose de suffisamment d’énergie, de données et de contrôle pour comprendre ce qui s’est passé.
L’autorité logicielle doit avoir des limites visibles
Plus un véhicule s’éloigne de la Terre, plus l’autonomie logicielle devient utile. Mais l’autonomie ne signifie pas que le logiciel doit pouvoir tout faire. Chaque fonction automatique doit avoir un domaine d’autorité : conditions d’entrée, actions autorisées, limites, durée maximale et critères de restitution du contrôle. Ces limites protègent à la fois contre une mauvaise estimation d’état et contre une erreur logicielle.
Les mécanismes de vote doivent eux aussi être interprétés avec prudence. Trois calculateurs exécutant exactement le même logiciel peuvent voter à deux contre un contre un défaut matériel isolé, mais ils restent vulnérables à une erreur commune de spécification ou de code. La diversité peut être introduite par des capteurs physiques différents, des algorithmes de surveillance indépendants ou une chaîne de secours plus simple. Elle coûte en validation mais réduit le risque qu’une même hypothèse erronée domine toutes les voies.
Dans un système habité, l’équipage doit comprendre quand l’automatisme agit et pourquoi. Un message « reconfiguration terminée » est insuffisant si personne ne sait quel capteur a déclenché l’action, quelles fonctions ont été perdues et comment revenir en arrière. Les journaux d’événements, les états de configuration et les explications de décision deviennent donc des interfaces de sûreté.
Mettre à jour le logiciel sans fabriquer une panne commune
Une mission de longue durée aura besoin de corriger des défauts, modifier des paramètres ou améliorer des algorithmes. La mise à jour doit cependant être conçue comme une opération à risque : vérifier l’image reçue, l’authentifier, conserver une version de retour, contrôler la compatibilité de la configuration et limiter la portée du changement. Le véhicule ne doit jamais dépendre d’une unique image logicielle fraîchement installée pour conserver ses fonctions vitales.
Un schéma robuste sépare la partition active, une image connue comme saine et les données de configuration. Une mise à jour peut être installée hors ligne, testée, puis activée dans une fenêtre où un retour arrière reste possible. Si le calculateur ne redémarre pas correctement, un mécanisme indépendant doit pouvoir sélectionner l’image précédente. Cette capacité est particulièrement importante lorsque le délai de communication empêche le sol de guider seconde par seconde la récupération.
Les standards NASA de génie logiciel et d’assurance logicielle sont utiles parce qu’ils imposent traçabilité, classification de criticité, vérification et indépendance proportionnées au risque. Ils ne dispensent pas d’adapter le raisonnement au contexte martien : long isolement, changements de configuration, équipe limitée et impossibilité de remplacer facilement le matériel.
Tester l’avionique avec des fautes injectées, pas seulement avec des cas parfaits
Un système FDIR doit être éprouvé contre des capteurs bloqués, des valeurs plausibles mais fausses, des paquets retardés, des redémarrages partiels, des pertes de bus et des défauts simultanés. L’injection de fautes permet de vérifier le temps de détection, la qualité de l’isolation et la stabilité de la récupération. Un système peut détecter correctement chaque panne séparée et devenir instable lorsque deux alarmes se déclenchent pendant une reconfiguration.
Le test doit également couvrir les faux positifs. Une alarme trop sensible peut déclencher des bascules inutiles, user des équipements redondants ou saturer l’attention de l’équipage. Supposons qu’un détecteur produise en moyenne un faux déclenchement tous les 30 jours. Sur un transit de 240 jours, l’espérance est de 240 ÷ 30 = 8 faux événements. Même si chacun est « sans danger », huit interruptions peuvent devenir un problème opérationnel. La performance d’un FDIR se mesure donc aussi par son taux de fausses alarmes et le coût de récupération associé.
Enfin, le test doit conserver les preuves nécessaires à l’enquête. Un journal circulaire trop petit peut écraser les secondes précédant une panne. Une horloge non synchronisée rend les traces ambiguës. Une télémesure qui ne conserve que l’état final empêche de comprendre la transition. La capacité à apprendre d’une anomalie commence par la capacité à enregistrer ce qui s’est réellement produit.
Étude de cas avionique : trois capteurs ne garantissent pas trois vérités
Quelques minutes avant une correction de trajectoire, trois capteurs d’attitude fournissent des informations légèrement différentes. Deux sont cohérents entre eux ; le troisième dérive lentement. Un vote majoritaire pourrait l’écarter immédiatement. Pourtant, la bonne question est d’abord de savoir si les deux capteurs « d’accord » partagent une même référence, un même algorithme ou une même perturbation. La majorité n’est une preuve que si l’indépendance a été étudiée.
Le logiciel peut comparer les mesures à une prédiction dynamique et à une source différente, par exemple une mesure stellaire contre une estimation inertielle. Il calcule des résidus, examine leur évolution et attribue une qualité à chaque observation. Si les deux capteurs majoritaires dérivent ensemble à cause d’une erreur commune de temps, le troisième peut être le seul à signaler la réalité. La chaîne de preuve doit donc conserver la provenance des données au lieu de réduire trop tôt trois mesures à une valeur unique.
Supposons que l’erreur admissible d’attitude soit de 0,20° pendant la manœuvre. Deux estimateurs diffèrent de 0,08° tandis qu’un troisième s’écarte de 0,23°. Ce dernier dépasse la limite, mais l’avionique doit encore déterminer s’il s’agit d’une erreur réelle ou d’un désaccord de référentiel. Une règle prudente peut inhiber la manœuvre si aucune source indépendante ne confirme l’estimation dominante. Le coût est un retard ; le bénéfice est d’éviter une impulsion exécutée avec une orientation mal connue.
Le mode dégradé doit rester exploitable. L’équipage peut réduire la complexité de l’estimateur, figer certaines mises à jour automatiques et demander une acquisition stellaire supplémentaire. Le logiciel expose alors quelles sources sont utilisées, lesquelles sont rejetées et pour quelle raison. Si la mission doit finalement manœuvrer avec une précision réduite, l’incertitude restante est transmise au calcul de trajectoire afin que la correction suivante absorbe la dispersion.
Après l’événement, l’analyse ne doit pas se limiter au capteur déclaré défaillant. Elle examine horloges, bus, alimentation, température, versions logicielles et historique de calibration. Une cause commune découverte après coup peut conduire à modifier la logique de vote de tout le véhicule. L’anomalie devient alors une source d’amélioration d’architecture plutôt qu’un simple remplacement de pièce.
Ce scénario illustre la différence entre autonomie et automatisme. L’automatisme applique une règle. L’autonomie robuste conserve assez de contexte pour savoir quand la règle n’est plus fiable, ralentir la décision et demander une preuve différente. Sur un vaisseau martien, cette capacité à douter proprement peut être aussi importante que la vitesse de calcul.
De la mesure à la décision : une chaîne de preuve numérique
Une avionique de mission martienne doit faire beaucoup plus que « faire tourner le logiciel ». Elle doit construire une image de l’état du véhicule à partir de mesures imparfaites, décider quelles informations sont crédibles, détecter les incohérences, choisir une action et conserver assez de traces pour qu’un équipage ou une équipe au sol puisse comprendre ce qui s’est passé. Cette chaîne de preuve est particulièrement importante lorsque le délai radio interdit de demander une confirmation à la Terre avant chaque décision urgente.
La première difficulté est l’observabilité. Un capteur ne mesure pas toujours directement la grandeur qui intéresse l’opérateur. Une pression, une température, un courant électrique ou une accélération peuvent être utilisés pour inférer l’état d’un équipement. Deux capteurs peuvent être cohérents entre eux et pourtant partager le même biais. L’avionique doit donc croiser des sources réellement indépendantes lorsque la fonction est critique : par exemple une position estimée par inertie peut être confrontée à une mesure optique, et l’état d’une vanne à la fois à son capteur de position et aux conséquences hydrauliques attendues.
Le FDIR — Fault Detection, Isolation and Recovery — est souvent résumé par trois verbes, mais chacun pose un problème différent. Détecter signifie décider qu’une observation n’est plus compatible avec le comportement attendu. Isoler signifie identifier la cause ou au moins la zone probable sans remplacer prématurément un composant sain. Récupérer signifie remettre la mission dans un état sûr, parfois avec une fonction dégradée. Confondre ces étapes peut créer une « panne de diagnostic » où le logiciel aggrave la situation en commandant la mauvaise reconfiguration.
Le vote majoritaire ne suffit pas lorsque les erreurs ont une cause commune
Trois capteurs identiques sont souvent présentés comme une solution évidente : deux valeurs proches l’emportent sur la troisième. Le raisonnement ne fonctionne que si les erreurs sont suffisamment indépendantes. Trois capteurs du même lot peuvent dériver sous le même environnement radiatif ou thermique ; trois chaînes peuvent utiliser le même convertisseur analogique-numérique ; trois calculateurs peuvent exécuter le même défaut logiciel. La diversité doit donc être étudiée au niveau des causes, pas seulement du nombre d’éléments.
Un exemple numérique aide à comprendre la différence entre redondance et couverture de panne. Supposons qu’un capteur individuel ait une probabilité de 0,001 d’être indisponible pendant une période donnée. Si trois capteurs étaient indépendants et qu’au moins deux soient nécessaires, la probabilité de perdre la fonction par panne simultanée serait très faible. Mais si une cause commune possède à elle seule une probabilité de 0,0005 de neutraliser les trois, cette valeur devient rapidement dominante. Ajouter un quatrième capteur identique ne réduit presque pas cette part du risque. Il faut traiter la cause commune : alimentation, logiciel, connectique, environnement, procédure ou principe de mesure.
Le diagnostic doit aussi gérer l’incertitude. Un algorithme qui transforme chaque mesure en vrai/faux trop tôt perd de l’information. Il est souvent préférable de conserver une qualité de donnée : valide, suspecte, non disponible, hors domaine, non synchronisée, ou incohérente avec une autre source. Cette graduation permet au système de choisir un mode plus prudent sans déclarer arbitrairement qu’il connaît la cause.
Le temps est une donnée : horloges, latence et ordre des événements
Une panne complexe se reconstruit comme une enquête. Pour savoir si une baisse de tension a provoqué le redémarrage d’un calculateur ou si le redémarrage a provoqué la chute du bus, les événements doivent être horodatés avec une précision cohérente. Si chaque équipement possède une horloge qui dérive et qu’aucune synchronisation n’est maintenue, les journaux deviennent ambigus au moment même où ils sont le plus nécessaires.
La précision requise dépend de la dynamique. Une séquence pyrotechnique, un événement de propulsion ou un bus numérique rapide peut demander une résolution très fine ; une dérive thermique sur plusieurs heures accepte un autre ordre de grandeur. L’architecture de temps doit donc distinguer l’heure de mission, la synchronisation interne, les horodatages scientifiques et l’heure civile affichée à l’équipage. Les convertir sans perdre le contexte fait partie de l’avionique.
Le délai Terre–Mars ajoute une autre temporalité. Une commande envoyée depuis le sol représente la connaissance que la Terre avait du véhicule plusieurs minutes auparavant. L’ordinateur de bord doit savoir si cette commande reste compatible avec l’état actuel. Dans certains cas, une commande devra être associée à une condition ou à une fenêtre d’exécution, plutôt qu’appliquée aveuglément lorsqu’elle arrive.
Mettre à jour le logiciel sans transformer chaque correction en pari
Un véhicule de plusieurs années aura besoin d’évolutions logicielles : corrections, nouveaux modes, changement de capteur, amélioration des diagnostics, adaptation à du matériel remplacé. La sécurité ne consiste donc pas à interdire les mises à jour mais à les rendre réversibles et traçables. Une architecture saine sépare le logiciel actif, l’image précédente connue comme bonne, les paramètres de configuration et les données opérationnelles qui ne doivent pas être écrasées.
Le retour arrière doit être testé comme une fonction normale. Si une nouvelle version démarre mais produit des anomalies, l’équipage doit pouvoir restaurer une version précédente sans dépendre d’un outil externe devenu indisponible. La procédure doit également préciser ce qu’il advient des formats de données et des paramètres créés par la version récente. Un rollback qui restaure le programme mais laisse une configuration incompatible n’est pas un vrai retour arrière.
Les exigences logicielles NASA actuelles insistent sur le cycle de vie, la gestion des exigences, la vérification, la validation et l’assurance. NASA-STD-8739.8B ajoute une approche systématique de l’assurance logicielle, de la sûreté et de l’IV&V. Pour un vaisseau martien, la conséquence opérationnelle est claire : la capacité à modifier le logiciel doit être accompagnée de la capacité à démontrer ce qui a changé, ce qui a été testé et ce qui reste incertain.
Le mode sûr doit préserver la capacité de comprendre, pas seulement empêcher la destruction
Un mode sûr trop minimal peut survivre tout en rendant le diagnostic impossible. Le véhicule doit préserver assez de télémétrie, de journaux, de capteurs et d’autorité pour savoir pourquoi il a basculé. À l’inverse, maintenir trop de fonctions augmente la consommation et laisse davantage de logiciels actifs pendant une situation mal comprise. La définition du safe mode est donc un compromis entre simplicité, survie et observabilité.
Les règles de basculement doivent être explicables. Une alarme isolée ne devrait pas toujours déclencher la même réponse qu’une combinaison cohérente d’indicateurs. Le système peut utiliser des temporisations, des confirmations indépendantes et des seuils différents selon le mode de mission. Une pression suspecte pendant une croisière stable et la même pression pendant une mise à feu ne conduisent pas nécessairement à la même action.
Un exercice utile consiste à imaginer une perte intermittente du bus principal pendant trente secondes. Quelles fonctions doivent continuer sur un bus de secours ? Quels équipements conservent leur dernier état ? Quels actionneurs reviennent par défaut à une position sûre ? Comment éviter que le retour du bus principal ne provoque une avalanche de commandes retardées ? La réponse est une propriété d’architecture, de logiciel et de procédures simultanément.
Repères principaux : NASA-HDBK-2203 — Software Engineering Handbook, NPR 7150.2D — Software Engineering Requirements, NASA-STD-8739.8B — Software Assurance and Software Safety et les exigences NASA relatives au FDIR des fonctions critiques. Les probabilités et valeurs de disponibilité utilisées ici sont des exemples pédagogiques explicitement hypothétiques.
Étude de cas — faire du FDIR une chaîne de preuves
Une boucle à 50 Hz possède une période τ = 1/f = 0,02 s, soit 20 ms. Un watchdog déclenché après deux échéances manquées détecte donc une tâche bloquée en environ 40 ms. Le symbole f est la fréquence et τ la période. Cette rapidité n’est utile que si le redémarrage ne recharge pas un état déjà corrompu.
Un capteur aberrant peut justifier une comparaison avec d’autres observables plutôt qu’une bascule immédiate de calculateur. Deux calculateurs redondants partageant la même table corrompue peuvent commettre la même erreur.
La campagne injecte perte de trame, bit mémoire retourné, capteur figé, dérive temporelle et redémarrage incomplet, puis exige une chronologie déterministe détection–isolement–reconfiguration–vérification.
Cybersécurité et sûreté se rejoignent lorsque le logiciel commande le monde physique
Dans un vaisseau martien, une erreur de configuration et une attaque peuvent produire des symptômes semblables : commandes inattendues, données incohérentes, refus de service ou modification d’un paramètre. La cybersécurité ne doit donc pas être isolée dans une couche administrative. Elle rejoint la sûreté dès qu’un logiciel peut actionner une vanne, couper une charge ou modifier l’estimation d’état.
Le principe de moindre privilège limite ce qu’un service peut faire. Un logiciel chargé de compresser des images n’a aucune raison de posséder l’autorité pour reconfigurer un bus vital. Une interface de maintenance peut être très puissante mais n’être accessible que dans un mode précis, avec authentification et journalisation. Cette séparation réduit la surface d’erreur comme la surface d’attaque.
Les clés et certificats constituent eux-mêmes un stock critique. Ils expirent, peuvent être compromis et doivent parfois être remplacés pendant une longue mission. La procédure de renouvellement ne doit pas dépendre d’une liaison terrestre instantanée. Le véhicule a besoin d’une racine de confiance, de moyens de récupération et d’une politique claire pour isoler un équipement suspect sans perdre toute la fonction.
Une mise à jour logicielle doit aussi préserver la preuve. Qui a autorisé l’image ? Quelle version était installée avant ? Quel hash a été vérifié ? Quels paramètres ont changé ? Quel test minimal a été exécuté après redémarrage ? Une intervention impossible à reconstruire après coup est une faiblesse opérationnelle, même si elle a réussi.
Le mode dégradé de cybersécurité mérite enfin d’être pensé. Si une partie du réseau interne est isolée, les fonctions vitales doivent continuer avec des interfaces minimales. Un véhicule dont chaque fonction dépend d’un annuaire, d’un serveur central ou d’une clé unique peut transformer un incident numérique en panne générale. La segmentation et les chemins locaux de commande sont donc des choix de sûreté.
La règle pratique est simple : toute autorité numérique importante doit avoir une origine vérifiable, une portée limitée, une trace et une procédure de retrait. Cette discipline rend les automatismes plus explicables et empêche qu’une architecture très connectée ne devienne une architecture où une seule erreur logicielle possède trop de pouvoir.
Quand l’avionique doit savoir dire « je ne sais pas »
Un système autonome mûr ne transforme pas toute incertitude en décision catégorique. Il doit parfois signaler qu’un état n’est pas suffisamment observable, qu’un capteur n’est plus digne de confiance ou qu’une hypothèse utilisée par l’estimateur vient d’être violée. Cette capacité à exprimer l’incertitude empêche le logiciel de fabriquer une précision inexistante et donne à l’équipage la possibilité de ralentir l’opération.
La représentation peut être simple : valeur estimée, intervalle d’incertitude, sources contributrices et qualité. Lorsqu’une action critique dépend d’une variable, le seuil ne doit pas ignorer l’incertitude. Si une limite opérationnelle vaut 100 unités et que l’estimation est 96 ± 8, déclarer la situation « sous la limite » serait trompeur ; l’intervalle recouvre la zone interdite. Le système peut demander une mesure supplémentaire ou adopter une action plus conservatrice.
Cette prudence doit être équilibrée avec le risque de paralysie. Un véhicule qui refuse toute action dès qu’une donnée est imparfaite serait inutilisable. Les modes dégradés définissent donc quelles décisions peuvent être prises avec une preuve réduite, quelles marges sont ajoutées et quelles actions restent interdites. L’autorité logicielle se contracte à mesure que la confiance diminue.
Le résultat recherché est une autonomie qui ne cache ni ses sources ni ses doutes. Cela améliore le diagnostic, facilite le retour d’expérience et permet à l’équipage de distinguer une machine qui sait réellement quelque chose d’une machine qui ne fait que produire un nombre.
Sources et références
Sources NASA primaires
- NASA - 2026 State-of-the-Art: Small Spacecraft Avionics
- NASA Systems Engineering Handbook
- NASA - 2026 State-of-the-Art of Small Spacecraft Technology
- NASA - 2026 State-of-the-Art: Ground Data Systems and Mission Operations
- NASA NTRS — Fault Detection and Diagnosis in Spacecraft Electrical Power Systems — diagnostic autonome et tolérance aux fautes
- NASA Moon to Mars — Autonomous Systems and Data Systems — autonomie, données et commande