Fiabilité et résilience : prévoir la panne et organiser le retour
Une mission martienne ne peut pas promettre qu’aucun équipement ne tombera en panne. Elle doit plutôt montrer qu’une panne crédible sera détectée, comprise suffisamment vite, isolée, supportée par un mode dégradé et réparée avec les ressources disponibles. Ce module distingue fiabilité, disponibilité, redondance, maintenabilité et résilience, puis les relie à des méthodes de preuve.
1. Fiabilité, disponibilité et résilience répondent à des questions différentes
La fiabilité décrit la probabilité qu’un élément accomplisse sa fonction pendant une durée donnée sous des conditions définies. La disponibilité inclut aussi la capacité à revenir au service après panne. La résilience ajoute l’idée de conserver une mission acceptable malgré perturbation, dégradation et récupération. Un système peut être peu fiable mais rapidement réparable, ou très fiable mais catastrophique lorsqu’il échoue.
La fiabilité décrit la probabilité qu’un élément accomplisse sa fonction pendant une durée et dans des conditions données. La disponibilité demande s’il est prêt quand on en a besoin, donc elle dépend aussi de la réparation. La résilience va plus loin : peut-on préserver une fonction essentielle, se reconfigurer puis revenir vers un état durable après l’événement ? Un système peut être très fiable mais peu résilient si une panne rare est irréparable. À l’inverse, un équipement qui tombe plus souvent en panne peut offrir un excellent service si la détection est rapide, les pièces accessibles et le mode dégradé acceptable. Ces trois mots doivent donc rester séparés dans les exigences et les calculs.
2. Lire un MTBF sans lui faire dire l’avenir
MTBF signifie Mean Time Between Failures. Il décrit une statistique de population sous un modèle et un domaine d’utilisation. Ce n’est pas la date de mort d’une pièce. Dans un modèle exponentiel, un taux constant λ donne R(t)=e−λt. Cette hypothèse ignore le rodage et l’usure ; elle doit donc être utilisée avec prudence.
Le MTBF, mean time between failures, est une statistique de population ou de modèle, pas une date de décès d’un composant particulier. Sous une hypothèse exponentielle simplifiée à taux de panne constant λ, la fiabilité vaut R(t)=e^(−λt) et MTBF=1/λ. Un MTBF de 10 000 h ne signifie pas que l’équipement fonctionnera 10 000 h puis cassera. Il signifie que le modèle attribue un certain taux d’événements sur une population. Pour Mars, l’hypothèse de taux constant peut être mauvaise en présence d’usure, radiation, poussière ou cycles thermiques. Le chiffre doit toujours être accompagné du domaine d’essai et de l’incertitude.
3. La disponibilité montre le rôle de la réparation
Un modèle simple utilise A = MTBF/(MTBF+MTTR). MTTR est le temps moyen de réparation. Avec 1 000 h de MTBF et 10 h de MTTR, A ≈ 1 000/1 010 ≈ 0,990. Si le MTTR tombe à 2 h, la disponibilité augmente sans modifier le taux de panne.
Exercice A — disponibilité
Calculez A pour MTBF = 500 h et MTTR = 5 h.
A = 500/(500+5) = 500/505 ≈ 0,9901, soit environ 99,01 %. Le chiffre n’inclut les délais logistiques que si la définition de MTTR les inclut.
Une approximation courante de disponibilité intrinsèque est A = MTBF/(MTBF + MTTR). Si MTBF = 1 000 h et MTTR = 10 h, A ≈ 1 000/1 010 = 0,990, soit 99,0 %. Réduire le MTTR à 2 h donne environ 99,8 % sans changer la fréquence de panne. Le calcul montre pourquoi accès, diagnostic, outillage et test après réparation peuvent être aussi importants qu’une amélioration de fiabilité composant. Mais cette formule suppose notamment des réparations possibles et ne représente pas automatiquement logistique de rechanges, attente d’EVA, causes communes ou files de maintenance. Il faut savoir ce que l’indicateur exclut.
4. FMEA et FMECA parcourent les modes de défaillance
Une FMEA demande : comment ce composant ou cette fonction peut-il échouer, quel est l’effet local, quel est l’effet système et comment détecter la panne ? La FMECA ajoute une appréciation de criticité. L’intérêt est de rendre visibles les pannes simples, les points critiques et les besoins de détection ou de maintenance.
Une FMEA parcourt les fonctions ou composants et demande : comment cela peut-il échouer, quel effet local puis système, comment le détecter et quelle action limite la conséquence ? La FMECA ajoute une notion de criticité. La valeur n’est pas dans le tableau lui-même mais dans la découverte d’interfaces cachées et de modes non couverts. Une ligne ‘capteur faux’ doit par exemple préciser si la panne est détectée, si le logiciel peut croire la mesure et quel actionneur sera commandé. Pour un habitat martien, la FMEA doit aussi inclure maintenance, logiciel, erreur humaine et défaillances après réparation, sinon elle décrit seulement le matériel neuf.
5. L’arbre de défaillance raisonne depuis l’événement redouté
Un Fault Tree Analysis part d’un événement comme « perte de pressurisation » et remonte vers les combinaisons possibles. Des portes logiques ET/OU aident à représenter les chemins. L’arbre ne remplace pas l’ingénierie physique : deux événements peuvent être corrélés même si le schéma les dessine séparément.
L’arbre de défaillance part d’un événement redouté et remonte vers les combinaisons de causes. Une porte OR signifie qu’une cause parmi plusieurs suffit ; une porte AND exige une combinaison. Ce raisonnement est particulièrement utile pour les causes communes. Deux pompes peuvent sembler redondantes, mais si la perte de leur alimentation unique suffit à perdre le débit, l’arbre révèle que la branche commune domine. Les probabilités peuvent être ajoutées lorsque les hypothèses d’indépendance sont crédibles, mais l’intérêt premier reste logique : montrer quelles combinaisons rendent la fonction indisponible et où une séparation physique, électrique ou logicielle change réellement le résultat.
6. La redondance n’est utile que si les causes sont séparées
Deux pompes sur le même bus, deux ordinateurs avec le même bug ou deux capteurs affectés par la même contamination peuvent échouer ensemble. La revue doit chercher alimentation, refroidissement, logiciel, connecteurs, calibration, environnement et procédure communs.
Exercice B — vraie ou fausse indépendance
Deux calculateurs identiques utilisent deux alimentations séparées mais le même logiciel. Citez une cause commune encore présente.
Un défaut logiciel ou une erreur commune de configuration peut affecter simultanément les deux calculateurs malgré les alimentations séparées.
La redondance ne vaut que si les voies possèdent assez d’indépendance. Deux calculateurs dans le même boîtier peuvent partager alimentation, température, connecteur, logiciel et erreur de configuration. Une panne commune peut donc supprimer les deux. La diversité peut porter sur le matériel, le logiciel, le principe de mesure ou la localisation. Elle a cependant un coût de validation et de maintenance. La question de revue n’est pas ‘combien d’unités ?’ mais ‘quelles causes peuvent encore les perdre ensemble ?’. Pour une colonie, il faut aussi considérer la capacité de réparation : deux unités non réparables peuvent être moins résilientes qu’une unité robuste soutenue par des modules remplaçables et un bypass.
7. FDIR : détecter, isoler, récupérer
Détection : reconnaître une incohérence. Isolation : estimer la cause ou au moins la zone fautive. Récupération : choisir un état sûr ou une reconfiguration. Le temps disponible change selon la panne. Une fuite lente peut permettre un diagnostic long ; un défaut de contrôle d’attitude peut exiger une réaction automatique rapide.
FDIR signifie Fault Detection, Isolation and Recovery : détecter qu’un comportement sort du domaine attendu, isoler la cause ou au moins la zone fautive, puis récupérer une fonction sûre. Chaque étape peut échouer. Une alarme trop sensible crée des faux positifs ; une isolation trop agressive peut couper le seul équipement sain ; une récupération automatique peut réintroduire la panne. Les preuves doivent donc être graduées. Un premier seuil peut demander confirmation par une mesure indépendante, un second basculer en mode dégradé, puis une vérification autoriser le retour. L’objectif n’est pas d’automatiser toute décision mais de garantir que l’état reste compréhensible et contrôlable pendant l’anomalie.
8. Safe mode ne signifie pas tout éteindre
Un mode de sauvegarde conserve les fonctions qui empêchent l’état de se dégrader : énergie, thermique, attitude, communications et parfois support-vie. Il doit être stable assez longtemps pour analyser. S’il consomme une ressource plus vite qu’on ne peut intervenir, il n’est pas réellement sûr.
Un safe mode est une configuration stable conçue pour préserver des ressources et éviter l’escalade. Il ne signifie pas ‘tout éteindre’. Un vaisseau doit continuer à produire de l’énergie, contrôler certaines températures, maintenir une attitude compatible avec panneaux et communications et protéger l’équipage. Le safe mode doit donc avoir ses propres exigences de puissance, capteurs, actionneurs et durée. S’il dépend d’un composant qui vient justement de tomber en panne, il n’est pas un vrai refuge. La validation injecte des fautes et vérifie que le système atteint ce mode avec les ressources réellement restantes, puis qu’il existe une voie de diagnostic et de récupération.
9. La maintenabilité se conçoit dans la géométrie
Une pièce accessible, testable, isolable et munie de connecteurs remplaçables peut réduire énormément le temps de restauration. À l’inverse, un composant « redondant » derrière des éléments qu’il faut démonter pendant deux jours peut transformer une petite panne en indisponibilité majeure.
La maintenabilité se dessine avant la panne. Temps d’accès, masse d’un panneau, connecteurs, volumes de travail, outils, points de test, isolation électrique et nécessité d’une EVA peuvent dominer le MTTR. Une pièce facilement remplaçable sur banc peut devenir impraticable lorsqu’elle est installée derrière deux conduites. Le design doit donc simuler l’intervention avec l’outillage et les gants prévus, puis inclure le temps de remise en configuration et de vérification. Sur Mars, une réparation locale peut aussi créer une nouvelle configuration qui doit être tracée. La résilience dépend autant de la capacité à prouver le retour en service que du geste mécanique lui-même.
10. Scénario : deux pannes indépendantes deviennent une panne commune par procédure
Une première panne conduit l’équipage à reconfigurer deux services sur un même bus de secours. Une seconde panne du bus supprime alors les deux services. Le couplage n’existait pas au départ ; il a été créé par la récupération. Les analyses de résilience doivent donc examiner les configurations dégradées, pas seulement l’architecture nominale.
Deux pannes indépendantes peuvent devenir une panne commune par la procédure. Si l’équipe utilise le même mauvais fichier de configuration pour remplacer deux contrôleurs, la duplication matérielle n’aide plus. De même, une checklist ambiguë peut conduire deux opérateurs à isoler la même mauvaise vanne. La fiabilité humaine et organisationnelle doit donc être intégrée aux analyses. Les procédures critiques exigent des critères observables, des confirmations indépendantes lorsque l’action est irréversible et une gestion de version. Le retour d’expérience doit modifier le document contrôlé sans effacer l’historique, afin qu’une erreur corrigée ne réapparaisse quelques mois plus tard sur un autre système.
Étude guidée — deux architectures de pompe
Architecture A possède deux pompes identiques en parallèle ; architecture B une pompe active, un bypass à 60 % de débit et trois modules facilement remplaçables. À première vue, A semble plus redondante. Mais si les deux pompes A partagent un seul contrôleur et une seule alimentation, une cause commune peut supprimer les deux. B peut au contraire conserver 60 % du service pendant huit heures, assez pour remplacer un module en deux heures et le tester avant remise en ligne.
Le calcul de disponibilité ne suffit pas à lui seul. Il faut dérouler la séquence : temps de détection, stabilisation, accès, réparation, essai et reprise. Un MTTR annoncé de 30 minutes sur banc peut devenir quatre heures dans l’habitat si l’accès exige dépressurisation d’une zone ou déplacement d’équipements.
L’exercice final demande quel changement apporte le plus de résilience : troisième pompe identique, seconde alimentation, bypass manuel, diagnostic indépendant ou meilleure accessibilité. La réponse dépend de la cause dominante révélée par l’arbre de défaillance, pas du nombre brut de composants.
11. Mini-projet : construire un dossier de résilience
- Choisissez une fonction vitale.
- Définissez son événement redouté.
- Listez cinq modes de panne.
- Identifiez les causes communes.
- Décrivez détection, mode dégradé et réparation.
- Calculez un indicateur simple de disponibilité.
- Ajoutez une seconde panne pendant le mode dégradé.
Le dossier est bon si l’on comprend ce qui reste possible après la première panne et comment le service revient.
12. Atelier mission — comparer redondance et réparabilité
Considérons deux architectures pédagogiques. L’architecture A possède deux pompes identiques non réparables, chacune capable de fournir tout le débit. L’architecture B possède une seule pompe en service mais trois modules facilement remplaçables et un bypass manuel. Laquelle est « plus fiable » ? La question est incomplète. Il faut connaître taux de panne, causes communes, temps de remplacement, stock, durée acceptable sans circulation et capacité du bypass.
Si le remplacement d’un module prend 2 h et que le mode bypass maintient 60 % du débit pendant 8 h, B peut avoir une excellente résilience même avec moins de redondance instantanée. À l’inverse, si les deux pompes A partagent le même contrôleur, leur duplication ne protège pas d’une panne commune. La résilience se juge sur la séquence complète de l’événement.
Un bon dossier décrit aussi le temps de détection, le temps de stabilisation, le temps de réparation et le temps de vérification. Additionner seulement le temps passé à tourner une clé sous-estime le MTTR opérationnel.
13. Limites des probabilités et importance de la preuve physique
Des probabilités très précises peuvent donner une impression scientifique même lorsque leurs entrées sont fragiles. Les données terrestres ne représentent pas toujours poussière, radiation, faible gravité, longues périodes sans maintenance spécialisée ou configurations martiennes. Les modèles probabilistes doivent donc être accompagnés d’essais, inspection, compréhension physique des mécanismes de panne et retour d’expérience.
Un chiffre de fiabilité est utile s’il change une décision : ajouter une indépendance, rendre une pièce accessible, augmenter un stock, modifier un intervalle d’inspection ou créer un mode dégradé. S’il n’a aucune conséquence de conception ou d’exploitation, il risque de devenir un indicateur décoratif.
Sources et références
Complément primaire vérifié : NASA Systems Engineering Handbook
Studio d’ingénierie — comparer deux architectures de disponibilité
Pour une loi exponentielle simple, la fiabilité sans réparation pendant une durée t s’écrit R(t)=exp(−t/MTBF). Avec MTBF = 1 500 h et t = 500 h, R ≈ exp(−1/3) ≈ 0,716. Deux chaînes réellement indépendantes en parallèle donneraient alors une probabilité théorique d’en conserver au moins une de 1−(1−R)² ≈ 0,919. Ce calcul pédagogique montre à la fois le gain de redondance et l’importance de l’hypothèse d’indépendance.
Le piège final est une cause commune : les deux chaînes redondantes partagent la même alimentation. L’élève doit expliquer pourquoi deux équipements identiques ne forment plus une vraie redondance si une seule panne peut les supprimer ensemble. Il doit proposer un changement architectural — séparation électrique, diversité ou refuge fonctionnel — et définir l’essai qui démontrera que la cause commune a réellement été rompue.