Pour mieux comprendre la sûreté de fonctionnement et logique des arbres de défaillance je me suis à la recherche de livres et d'exercises. Et je suis tombé sur ce livre de la NASA qui donne un exemple sur un système de propulsion (chapitre 11 page 127). J'ai bien lu et compris l'arbre qu'ils ont développé pour le cas n°3 (mise à feu du système lorsque ce n'est pas nécessaire) et je me suis alors penché sur les deux autres cas, à savoir :
1) Incapacité du système à fournir de la propulsion quand commandée
2) Mise à feu du système par inadvertance lorsque ce n'est pas requis
Pour le cas numéro 1), je trouve l'arbre suivant :
Pour y arriver, j'ai utilisé la même hypothèse que le livre (IV1 peut s'ouvrir et se fermer sans soucis & TK1 n'a pas d'échec), sans considérer les valves RV (RV1, RV2, ...).
Mais j'ai vraiment un doute sur mon résultat. Quelqu'un a-t-il une correction à me proposer svp ?
Ou au moins, quelqu'un pourrait me dire ce qui est faux ?
De plus, je n'ai que des portes logiques "OU". Je me demande donc, quelles sont les coupes minimales dans ce cas ? Au vu de mon arbre, ma conclusion est que chaque élément est une coupe minimale en lui-même. Est-ce correct ?
Pour le cas numéro 2), je trouve :
De même que pour 1), j'ai vraiment un doute pour l'arbre. Je ne suis pas du tout sûr de moi...
Je n'ai pas étudié les arbres de défaillance, mais je connais bien les structures d'arbre en général.
Je connais bien les fonctions logiques du style OU, ET, etc.
Quand tu descends dans ton arbre, chaque chemin implique un ET, car tu ne peut aller dans un sous-embranchement sans avoir passé dans TOUS les embranchements qui précèdent.
On a les cas suivants:
1) Incapacité du système à fournir de la propulsion quand commandée)
2( Mise à feu du système par inadvertance lorsque ce n'est pas requis)
3(mise à feu du système lorsque ce n'est pas nécessaire)
Qu'est-ce qui caractérise ces cas? On a appuyé sur le bouton de mise à feuet il y a eu feedback du système.
De quoi as-tu reçu le feedback? «(IV1 peut s'ouvrir et se fermer sans soucis & TK1 n'a pas d'échec)»
Le '&' veut justement dire ET. Tu dois passer par tous les feedback pour arriver à une de tes conclusions.
Il te faudra un feedback supplémentaire pour faire la différence entre ces trois cas.
Un des problèmes en pratique est que l'action peut avoir eu lieu mais le système n'a pas reçu de feedback ou il en reçoit un sans que l'action ait eu lieu.
La plus grande défaillance est sans doute celle du système de feedback lui-même avec sa multitude de composantes.
Le Tout est souvent plus grand que la somme de ses parties.
Si je comprends bien ce que tu dis et que je suis tes messages, tu induis qu'il manque un niveau avant le niveau "IV3 est fermé" et "IV2 est fermé" pour le cas 1 ? Et de même pour le cas 2 (du type "IV3 reçoit du fuel OU Le circuit est fermé" juste en dessous du Top Event.. même si je trouve cela pas logique et pas correct) ?
Si ce n'est pas ce que tu veux dire, est-ce que tu peux être plus clair si possible ?
Quant à "Un des problèmes en pratique est que l'action peut avoir eu lieu mais le système n'a pas reçu de feedback ou il en reçoit un sans que l'action ait eu lieu", j'ai pensé exactement la même chose. Et c'est d'ailleurs pour cela que je l'ai intégré aux 2 arbres ("erreur de commande ou n'arrive pas à s'ouvrir/se fermer" (selon le cas 1 ou 2)). Enfin, sans doute que j'ai loupé un détail...
D'abord, je ne sais pas si on a la même définition du OU, sont-ils inclusifs ou mutuellement exclusifs?
Dans un arbre de défaillance, je crois qu'il est préférable que ce soit exclusif.
Dans l'exemple donné, les cas 2 et 3 sont dus à des erreurs humaines alorrs que le cas 1 est dû à une erreur technique.
Donc, à ce niveau, il faut un test supplémentaire pour vérifier s'il y a eu défaillance technique.
Sinon, cela relève de procédures humaines qui devront être vérifiées autrement.
Puisque tu parles de la NASA, tu pourrait regarder les compte-rendus des vieilles missions Gemini et Apollo où on voit toutes les erreurs qui se sont passées.
J'ai travaillé à une époque où les ordinateurs étaient faits de transistors "discrets" et non des micro-processeurs.
La technique de recherche des problème s'appelait en anglais "trouble shouting".
Il y a des procédures écrites et d'autres qui sont déduites sur place.
Même si on n'utilisait pas le terme "arbre de défaillance", c'est ce qui se faisait d'une façon ou d'une autre.
Même dans les années 1970, les techniciens faisaient rouler des logiciels spéciaux pour déterniner les défaillances des ordinateurs.
Une légende veut que la NASA avait des ordinateurs de deux ou trois compagnies différentes codés par des programmeurs différents pour éviter les erreurs.
Le Tout est souvent plus grand que la somme de ses parties.
J'ai suivi ton conseil et j'ai pu trouver 2-3 choses concernant des missions passées (surtout Gemini et Challenger).
J'ai compris qu'il me manquait quelques petits détails à prendre en compte dans mes arbres, notamment le cas du switch enclenché par l'homme (comme référencé dans ton message).
Puisque j'ai un peu mieux compris, je clos ce sujet. Merci !
Arbre de défaillance
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.