1 — La scène concrète
Un capteur annonce une valeur physiquement impossible. Le logiciel doit décider s’il s’agit d’un vrai danger, d’un capteur défaillant ou d’un transitoire, puis choisir une réaction sûre.
Le point essentiel est de ne jamais isoler ce sujet du reste du vaisseau. Une modification locale déplace souvent masse, puissance, chaleur, données, logiciel, essais ou risque ailleurs dans le système.
2 — Les mots indispensables, expliqués avant de les utiliser
Avant de calculer, on définit chaque mot qui servira ensuite. Le but est que le symbole arrive après l’idée, jamais avant.
- État
- Configuration logique autorisant certaines actions.
- Watchdog
- Surveillance attendant un signe de vie.
- FDIR
- Détection, isolation et récupération après défaut.
- Redondance
- Moyen supplémentaire pouvant reprendre une fonction.
- Cause commune
- Dépendance pouvant faire tomber plusieurs voies.
- Mode sûr
- État simplifié privilégiant la survie et le diagnostic.
3 — Voir l’architecture avant de calculer
Détection
Seuils, cohérence, votes et temporisations.
Isolation
Identifier la zone probable, pas seulement signaler une alarme.
Récupération
Réessayer, redémarrer, basculer ou désactiver.
Mode sûr
Réduire la complexité pour conserver énergie, thermique et communication.
4 — Les formules, seulement lorsqu’elles répondent à une question
Une formule n’est utile que si l’on sait quelle question elle résout, ce que signifie chaque symbole et dans quelles unités on doit travailler.
Ici, la compréhension du système compte plus qu’une équation unique. On raisonne avec des états, des interfaces, des marges et des critères de réussite.
5 — Ce que les unités et les marges veulent dire
Seuils gardent l’unité de la grandeur ; temporisations en s ou ms. La logique doit écrire à la fois valeur, durée et état applicable.
6 — Trois démonstrations concrètes, calculées pas à pas
Temporisation
Dépassement 0,2 s, seuil logique 2 s.
0,2 s observé
2 s requis
0,2<2 : pas de déclenchement
Vote capteurs
21,0 °C ; 21,3 °C ; 85 °C.
Deux proches
Un très éloigné
La voie à 85 °C est suspecte, cause non prouvée.
Mode dégradé
Deux calculateurs, un perdu.
Avant=2 voies
Après=1 voie
Fonction maintenue, tolérance supplémentaire perdue.
7 — Approfondissement : ce que le schéma simplifié cache
Machines à états
Les transitions explicites réduisent les comportements implicites.
Fausses alarmes
Trop sensible ou trop permissif sont deux risques.
Diversité
Deux copies identiques peuvent partager la même erreur de conception.
Redémarrage
Il faut restaurer un état cohérent après reboot.
Validation
Simulations et hardware-in-the-loop testent les cas rares.
8 — Application à un vaisseau Terre–Mars
Sur un transit Terre-Mars, la longue durée transforme une petite faiblesse en risque cumulé : vieillissement, dérive, consommation, cycles et maintenance deviennent aussi importants que la performance nominale.
Le délai de communication oblige le véhicule et éventuellement l’équipage à diagnostiquer et reconfigurer localement. La conception doit donc rester observable, compréhensible et testable en modes dégradés.
9 — Dossier de référence : ce qu’un vrai projet doit encore prendre en compte
Cette partie va volontairement plus loin que le calcul d’introduction. Elle relie le concept aux interfaces, aux pannes, aux essais, à la durée et à la maintenance afin que le cours puisse servir de chapitre de référence et pas seulement de fiche de révision.
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.
10 — Pièges fréquents et mauvaises intuitions
- Croire que deux copies identiques éliminent les causes communes.
- Utiliser le redémarrage comme réponse universelle.
- Créer un mode sûr jamais testé en chaîne complète.
11 — Exercices guidés
Question : Quelle question faut-il poser avant de choisir un équipement ?
Question : Pourquoi un résultat nominal ne suffit-il pas ?
12 — À retenir
- Expliquer le sujet avec des mots simples avant les symboles.
- Relier au moins quatre interfaces avec les autres sous-systèmes.
- Refaire les trois exemples numériques sans saut de raisonnement.
- Identifier au moins trois limites ou modes de panne absents du calcul idéal.
13 — Sources NASA pour approfondir
Sources institutionnelles primaires utilisées pour contrôler la structure du cours. Les exemples numériques pédagogiques sont identifiés comme tels.