AM-09.06 · SPACE ACADEMY

Logiciel de vol, watchdog, FDIR, redondance et mode sûr

Comment le vaisseau se protège-t-il quand un capteur devient incohérent ou un calculateur se bloque ?

📄 Télécharger le PDF A4

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.

Question directrice : Comment le vaisseau se protège-t-il quand un capteur devient incohérent ou un calculateur se bloque ?

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

Logiciel de vol, watchdog, FDIR, redondance et mode sûr
Schéma fonctionnel simplifié : il montre les relations à comprendre avant de mémoriser les détails.

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.

Toujours écrire les unités et la frontière du calcul. Une valeur sans unité, durée, mode ou hypothèse peut devenir trompeuse.

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

Conclusion : Filtre une pointe mais retarde aussi un vrai défaut.

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.

Conclusion : Le vote exige indépendance et modèle cohérent.

Mode dégradé

Deux calculateurs, un perdu.

Avant=2 voies

Après=1 voie

Fonction maintenue, tolérance supplémentaire perdue.

Conclusion : Opérationnel ne signifie plus pleinement tolérant aux pannes.

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 ?

Réponse guidée : Quel besoin vérifiable doit-il satisfaire, dans quel mode, avec quelles interfaces, quelles marges et quelles conséquences en cas de panne ?

Question : Pourquoi un résultat nominal ne suffit-il pas ?

Réponse guidée : Parce qu’il faut aussi vérifier dispersion, environnement, vieillissement, pannes, configuration et conditions de pointe.

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.