Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

2016 – 2017 GRIF : Grafique intéractif et calculs de fiabilité) - Module : Tree

2016 – 2017 GRIF : Grafique intéractif et calculs de fiabilité) - Module : Tree Les Arbres des Défaillances traités à l’aide du logiciel Grif Sommaire 1. Introduction 2. Construction d’un AdD 3. Codage d’un AdD par un DDB (Diagramme de Décision Binaire) 4. Exploitation qualitative d’un AdD 5. Exploitation quantitative d’un AdD 6. Présentation du logiciel GRIF (module Tree)  Arbre des Défaillances (AdD)  Arbre des pannes  Arbre des fautes  Arbre des causes  Fault Tree (FT) Analysis (FTA) Introduction Dénominations CEI 61025 Introduction Bref historique (1)  L’AdD a été à l'origine développée en 1962 aux BELL Laboratories par H.A. Watson, sur une demande de l’U.S. Air Force pour évaluer le Système de commande de Lancement du missile balistique intercontinental Minuteman.  Boeing et AVCO ont utilisé les AdD pour l’ensemble du système de Minuteman II en 1963 et 1964.  Grande promotion de l’AdD lors du Symposium System Safety de 1965 à Seattle patronné par Boeing et l’Université de Washington.  Boeing a commencé à utiliser les AdD pour la conception d'avions civils vers 1966.  A partir de 1970, utilisation courante des AdD dans le domaine de l'aviation civile aux États-Unis suite aux recommandations de l'aviation civile américaine visant l’adoption de critères probabilistes d'échec pour les équipements.  Publication du rapport Rasmussen (appelé aussi WASH-1400) en 1975: utilisation de l'évaluation probabiliste des risques (PRA ou probabilistic risk assessment) par l’U.S. Nuclear Regulatory Commission (NRC).  1981 (suite a l’accident de Three Mile Island): publication du manuel sur les AdD intitulé NRC Fault Tree Handbook (NUREG-0492).  Création (Watson ; 1962) : projet Minuteman ICBM.  Règles de construction (Haasl ; 1965) : University of Washington et Boeing.  Bases de l’évaluation quantitative (Vesely, 1970) : Kinetic Tree Theory (KITT).  Approche originale pour l’évaluation qualitative (Fussell et Vesely ; 1972) : MOCUS.  Développements multiples (algorithmes, AdD non-cohérents, multi- phases…; 1980-90).  Diagrammes de décision binaires ou DDB (Coudert, Madre, Rauzy ; 1992). Introduction Bref historique (2) Aralia  Méthode de représentation graphique de la logique de dysfonctionnement d’un système. Elle utilise une symbolique graphique particulière qui permet de présenter les résultats dans une structure arborescente.  Méthode déductive (Top-Down) : considère un événement redouté (indésirable, sommet) (ER) ou (conséquences, effets) (ex.: arrêt de production, explosion…) dont elle cherche à expliquer les causes possibles: ei (événements élémentaires). Introduction Caractéristiques majeures-Principe Effets Causes ei ER Evénement intermédiaire Introduction Caractéristiques majeures-Principe  Méthode de détermination des scénarios (combinaisons d’événements «élémentaires») conduisant à la réalisation d’un ER engendré par le système étudié. Les liens entre les différents évènements identifiés sont réalisés grâce à des portes logiques (de type « ET » et « OU » par exemple).  Méthode de quantification de l’occurrence de l’ER considéré. Evénement / report Dénomination Portes Dénomination Evénement de base Porte « ET » Pseudo-événement de base Porte « OU » Evénement maison Porte « OU exclusif » Evénement-sommet ou événement intermédiaire Porte « combinaison » Report (sortie) Porte « NON-OU » Le sous-arbre situé sous ce « drapeau » est à dupliquer … Report (entrée) Porte « NON-ET » …à l’endroit indiqué par ce second drapeau 1 1 K/n Introduction Conventions graphiques Introduction Conventions graphiques Événement du plus bas niveau pour lequel la probabilité d'apparition ou d'information de fiabilité est disponible Événement qui doit se produire avec certitude lors de la production ou de la maintenance. On peut aussi le définir comme un événement non- probabilisé, que l'on doit choisir de mettre à 1 ou à 0 avant tout traitement de l'arbre. Ce type d'événement permet d'avoir plusieurs variantes d'un arbre sur un seul dessin, en modifiant la logique de l'arbre selon la valeur choisie par l'utilisateur. Le développement de cet événement n'est pas terminé, soit parce que ses conséquences sont négligeables, soit par manque d'information Introduction Conventions graphiques L'événement de sortie apparaît si au moins un des événements d'entrées apparaît L'événement de sortie apparaît si tous les événements d'entrées apparaissent L'événement de sortie apparaît si l'événement d'entrée n'apparaît pas. L'état logique de la sortie est l'inverse de celui d'entrée Introduction Conventions graphiques L'événement de sortie apparaît si au moins k événements d'entrées apparaissent L'événement de sortie apparaît si un seul événement d'entrée apparaît  Pas de véritables contraintes limitant :  son pouvoir de modélisation (logique de dysfonctionnement),  son aptitude à être exploité qualitativement :  portes séquentielles, libellé étendu des événements, …  allocation d’objectifs qualitatifs.  Mais, une limitation drastique de sa capacité d’évaluation quantitative due au respect de la condition d’indépendance des événements de base. Cette indépendance doit se vérifier au niveau :  des défaillances (redondance passive),  des réparations (nombre de réparateurs disponibles),  de la mission (fiabilité). Introduction Champ d’application Sommaire 1. Introduction 2. Construction d’un AdD 3. Codage d’un AdD par un DDB (Diagramme de Décision Binaire) 4. Exploitation qualitative d’un AdD 5. Exploitation quantitative d’un AdD 6. Présentation du logiciel GRIF (module Tree)  Procédure manuelle directe  Procédure manuelle indirecte  Procédure automatique Construction d’un AdD Types de construction  R1 : Libellé explicite (quoi et quand ?) : écrire explicitement le libellé de tous les événements (notamment celui de l’événement sommet). Construction d’un AdD Règles de base Exemples:  Remarque : l’utilisation préalable de méthodes inductives (APR, AMDEC, HAZOP) permet d’identifier les évènements qui méritent d’être retenus pour une analyse par arbre des défaillances. • Rejet à l’atmosphère de produits toxiques ou inflammables • Incendie • Explosion • échec d’une mission (défaillance d’un système de sécurité ou d’un système de production, …) • … Construction d’un AdD Règles de base  R2 : Cause (s) immédiate(s) : rechercher systématiquement les causes immédiates, nécessaires et suffisantes de chaque événement à développer.  R3 : Evénement du type-composant Associer automatiquement à chaque événement intermédiaire de type-composant une porte OU doté au plus de trois entrées:  Système Evénement du type-système Type de porte  Composant 1. défaillance primaire du composant : vanne bloquée ouverte, … 2. défaillance secondaire : agression extérieure, erreur humaine, … 3. défaut de commande : la vanne n’a pas reçu de signal de fermeture, pas d’alimentation électrique, … 1. Evénement intermédiaire type-composant : la vanne reste ouverte, … 2. Evénement intermédiaire type-système : le système d alimentation ne s’arrête pas (alimentation continue), … Construction d’un AdD Règles de base  R4 : Pas de porte à porte : ne pas oublier d’associer à chaque porte un événement de sortie.  R5 : Pas de miracle à espérer : ne pas espérer qu’une défaillance ou qu’un événement imprévu vienne neutraliser un scénario critique. Les défaillances prises en compte sont fonction des limites et objectifs de l’étude.  Le plus souvent, la décomposition est menée jusqu’à ce qu’on ait la certitude que : Construction d’un AdD Arrêt de la décomposition On dispose d’un retour d’expérience suffisant (études SdF déjà menées sur des systèmes similaires ou de technologie voisine). Lorsque l’on est en mesure de pouvoir quantifier les événements de base.  Un événement trouvé dans le déploiement d’une branche étudiée s’avère être identique à un autre événement détecté dans une autre branche de l’arbre. On veillera alors a les repérer et les libeller de façon identique. Les événements de base doivent être indépendants : qu’ils ne possèdent pas de mode commun (cause commune). Rechercher ses causes immédiates, nécessaires et suffisantes et déterminer la nature de la porte-connectrice Définir les événements intermédiaires représentant chacune de ces causes Cet événement est l’événement de sortie d’une porte OU dotée au plus des 3 entrées suivantes Cet événement est l’événement du type-système Cet événement est-il du type- composant ? Oui Non Définir la défaillance primaire du composant Définir la défaillance secondaire du composant Existe-t-il un défaut de commande associé à ce composant ? Non Oui Existe-t-il ? Oui Non FIN Passer à l’événement-cause suivant Définir le défaut de commande Définir l’événement-sommet représentant l’ER Construction d’un AdD Procédure de construction manuelle Unité de production d’énergie + - Lampe Interrupteur Fusible Batterie Lampe défectueuse La lampe ne s’allume pas Pas d’énergie fournie à la lampe Pas d’alimentation en énergie Circuit ouvert Pas d’énergie venant de la batterie Interrupteur défectueux Pas d’énergie venant de l’unité de production Fusible défectueux L B UP I F Construction d’un AdD Procédure de construction manuelle : Exemple 1 (circuit électrique) Evacuation Services consommateurs LSH LS HH V2 V1 Source V3 Réservoir d’eau L’alimentation du réservoir en eau est assurée par une source supposée inépuisable et une canalisation dont le débit est commandé par l’ouverture ou la fermeture des vannes automatiques V1 et V2. Durant le remplissage, la vanne automatique V3 demeure fermée. Le débit qu’elle autorise est supérieur à celui des vannes V1 et V2. Lorsque le niveau haut est atteint, il est détecté par le capteur LSH (Level Switch High) qui commande alors la fermeture de V1. Si cete séquence venait à échouer, le niveau d’eau continuerait de monter dans le réservoir jusqu’à atteindre sa valeur limite qui serait détecée par le second capteur LSHH (Level Switch High uploads/Ingenierie_Lourd/ add-grif-skikda-2.pdf