BIBLE MARS — RISQUE & RÉSILIENCE
Capteurs contradictoires et logiciel de commande : que croire quand les instruments ne sont pas d’accord ?
Quand deux capteurs indiquent des valeurs incompatibles, la vraie question n’est plus « quelle valeur lire ? », mais « quelle chaîne de mesure mérite encore notre confiance ? ».
Une base autonome doit savoir distinguer panne de capteur, défaut de câblage, dérive d’étalonnage, anomalie logicielle et phénomène physique réel. Ce dossier suit la décision depuis la détection d’une incohérence jusqu’au vote de capteurs, à l’isolement, au mode dégradé et à la confirmation par une mesure indépendante.
1 — Une mesure n’est jamais la réalité elle-même
Un capteur transforme une grandeur physique en signal. Il possède précision, bruit, biais, dérive et plage de fonctionnement. Trois valeurs différentes ne signifient donc pas automatiquement trois pannes.
La première tâche est de connaître l’incertitude normale de chaque instrument avant de déclarer un conflit.
2 — Voter à trois ne suffit pas toujours
Une logique 2-sur-3 peut rejeter un capteur isolé, mais elle échoue si deux capteurs partagent le même défaut ou la même calibration erronée.
La diversité de principe de mesure peut être plus utile que trois copies identiques.
3 — Le logiciel doit savoir dire “je ne sais pas”
Un estimateur robuste produit non seulement une valeur mais un niveau de confiance. Lorsque la confiance s’effondre, le système peut passer en mode sûr au lieu de poursuivre une optimisation agressive.
La sûreté exige des états dégradés conçus à l’avance.
4 — Exemple : trois capteurs de pression
Si A = 101,2 kPa, B = 101,3 kPa et C = 98,0 kPa, C semble aberrant. Mais si A et B partagent le même manifold gelé, leur accord peut être trompeur.
On vérifie alors un capteur indépendant, le comportement attendu du système et d’autres grandeurs corrélées comme débit ou température.
5 — Commander lentement lorsqu’on doute
Une mauvaise mesure transformée en action rapide peut amplifier le problème. Selon le risque, limiter la vitesse de commande, figer une configuration stable ou demander une confirmation indépendante peut être préférable.
Le choix dépend de la dynamique : une fuite explosive n’autorise pas la même prudence qu’une dérive thermique lente.
6 — Conserver la traçabilité de la décision
Les valeurs brutes, drapeaux qualité, versions logicielles et commandes doivent être journalisés. Après incident, l’équipe doit pouvoir reconstruire ce que le système croyait et pourquoi il a agi.
Sans traçabilité, une panne intermittente devient presque impossible à diagnostiquer.
Comparer un écart à une tolérance connue
CALCUL PÉDAGOGIQUE — LES HYPOTHÈSES SONT EXPLICITES
HYPOTHÈSE PÉDAGOGIQUE : deux capteurs lisent 101,2 et 101,3 kPa, un troisième 98,0 kPa.
Écart C–moyenne(A,B) ≈ 98,0 − 101,25 = −3,25 kPa. Si la dispersion normale annoncée n’est que ±0,2 kPa, cet écart est très supérieur au bruit attendu.
Cela justifie une investigation, pas la conclusion automatique “C est faux”. Une cause commune peut fausser A et B.
Questions de décision propres à ce risque
- Quelle incertitude est normale pour chaque capteur ?
- Les instruments en accord partagent-ils la même alimentation, le même manifold ou la même calibration ?
- Quel mode sûr existe si l’état ne peut plus être estimé avec confiance ?
- Quelle grandeur indépendante peut confirmer le diagnostic ?
- Le journal permet-il de reconstruire chaque commande après incident ?
Le système doit savoir qu’il ne sait plus
Lorsque deux capteurs critiques donnent des valeurs incompatibles, le pire comportement consiste à choisir automatiquement celui qui « ressemble le plus » à la valeur attendue. Une valeur plausible peut être fausse. Le système doit donc disposer d’un état explicite d’incertitude : les mesures ne sont plus cohérentes, la confiance diminue et certaines commandes automatiques deviennent interdites tant qu’une source indépendante n’a pas arbitré.
Cette logique impose de surveiller non seulement la valeur mesurée, mais aussi la santé de la chaîne qui la produit : alimentation, communication, dérive, fréquence de mise à jour et cohérence avec d’autres grandeurs physiques. Un capteur de pression, par exemple, peut être confronté à la variation de masse, au débit et à la température. L’objectif n’est pas de fabriquer une vérité par vote, mais de rendre visibles les contradictions avant qu’elles deviennent une commande dangereuse.
Tester les logiciels avec des mensonges réalistes
Une validation sérieuse ne consiste pas seulement à présenter au logiciel des données propres. Il faut lui injecter des incohérences représentatives : donnée figée, valeur retardée, bruit anormal, perte intermittente, capteur qui dérive lentement ou deux instruments qui divergent au moment d’une manœuvre. On observe alors si le système détecte l’anomalie, bascule dans un mode sûr et explique suffisamment son raisonnement à l’équipage.
Sur Mars, cette capacité doit rester testable localement. Une colonie ne peut pas dépendre d’une équipe terrestre pour reproduire chaque anomalie. Des bancs de test, des simulateurs et des journaux d’événements permettent de rejouer les scénarios et de vérifier qu’une mise à jour logicielle n’a pas supprimé une protection ancienne.
Sources primaires principales
À relier aux autres dossiers
Quand deux instruments ne racontent plus la même histoire
Un capteur isolé n’est jamais une vérité absolue. Il possède une plage de mesure, un bruit, une dérive possible, un historique d’étalonnage et des modes de panne. Lorsque deux mesures essentielles divergent, le problème n’est pas seulement de choisir « la moyenne » : il faut comprendre lequel des deux instruments est encore crédible, si un phénomène réel peut expliquer l’écart et quelles décisions restent sûres en attendant.
La cité doit donc conserver des références indépendantes, des tests de cohérence et des modes dégradés. Une mesure impossible physiquement, une variation trop rapide ou une contradiction avec un troisième phénomène peut déclencher une suspicion. Mais un algorithme trop agressif peut lui aussi rejeter une vraie anomalie. La sûreté exige donc une logique explicitement testée contre faux positifs et faux négatifs.
Le logiciel peut être la panne commune
Même trois capteurs différents ne suffisent pas si un seul logiciel interprète mal leurs données. Une erreur d’unité, une saturation numérique, une mauvaise table d’étalonnage ou une mise à jour défectueuse peut transformer plusieurs mesures correctes en une décision erronée commune. La diversité doit donc concerner les chemins de calcul autant que les instruments.
Dans un habitat martien, la bonne architecture cherche à conserver une capacité de repli : affichage brut disponible pour l’équipage, logique de secours plus simple, seuils physiques indépendants et procédure permettant de figer une commande automatique devenue suspecte. L’objectif n’est pas de revenir au pilotage manuel intégral, mais de conserver des moyens de vérifier ce que l’automatisme croit savoir.
Tester les désaccords avant Mars
Les essais doivent injecter volontairement des capteurs dérivants, bloqués, incohérents ou intermittents. On observe alors ce que fait le système : quelle alarme apparaît, quelle valeur est retenue, quelle fonction est inhibée et combien de temps l’équipage dispose pour comprendre la situation. Une architecture que l’on n’a testée qu’avec des capteurs parfaits n’a jamais réellement testé son autonomie.
Le même principe s’applique au jumeau numérique et aux simulateurs d’entraînement. Les scénarios doivent inclure des informations contradictoires et incomplètes, parce que la vraie difficulté d’une crise n’est souvent pas l’absence totale d’information mais l’incertitude sur celle qui mérite confiance.