Traitement des défaillances d'origine courante dans les arbres de failles

L'analyse des causes courantes des défaillances est importante dans les études de fiabilité et de sécurité, car les défaillances d'origine courante l'emportent souvent sur les défaillances matérielles aléatoires. Les systèmes affectés par des défaillances d'origine courante sont des systèmes dans lesquels deux événements ou plus sont susceptibles de se produire pour la même cause. Parmi les causes courantes typiques, citons les chocs, les vibrations, la pression, le sable, le stress et la température. HBK Prenscia propose une approche innovante pour gérer les défaillances d'origine courante. Les défaillances à l'origine de différents événements peuvent être modélisées à l'aide de blocs en miroir dans ReliaSoft BlockSim.

Blocs en miroir

Les blocs en miroir vous permettent de placer exactement le même bloc à plusieurs endroits dans un schéma de blocs de fiabilité (RBD) ou un arbre de défaillances. Cela peut être utile à de nombreuses fins, telles que la modélisation de chemins bidirectionnels dans un diagramme et la modélisation de défaillances d'origine courante. La mise en miroir est réalisée en ajoutant des blocs à un groupe de miroirs. Les groupes miroirs sont des ressources qui peuvent être partagées entre les analyses et qui peuvent être gérées via le gestionnaire de ressources. Les blocs appartenant à un groupe de miroirs ont un carré dans le coin inférieur gauche du bloc ; l'apparence de l'indicateur et sa légende sont configurables.

Les blocs en miroir sont traités comme des instances multiples totalement équivalentes d'un seul bloc, plutôt que considérés comme des originaux et des copies. Les temps de défaillance et tous les événements de maintenance sont identiques pour chaque bloc du groupe miroir. Toute modification apportée aux propriétés d'un bloc d'un groupe de miroirs s'appliquera à tous les autres blocs du groupe de miroirs.

L'utilisation de blocs en miroir garantit que plusieurs blocs présenteront le même comportement (par exemple, des pannes...) et subiront la même action (par exemple, une maintenance corrective, des inspections, etc.) simultanément. La saisie des mêmes propriétés pour différents blocs d'un diagramme ne garantit pas que ces blocs agiront comme des blocs en miroir. Par exemple, en raison du caractère aléatoire, des blocs présentant la même distribution de défaillances et les mêmes paramètres peuvent toujours échouer à des moments différents lors de l'exécution d'une simulation.

Utilisation de blocs en miroir pour l'analyse des causes courantes de défaillance

Les défaillances d'origine courante étaient traditionnellement traitées à l'aide des modèles Beta, MGL, Alpha et BFR. BlockSim propose une approche plus simple et plus efficace pour gérer les défaillances d'origine courante qui repose sur l'utilisation de blocs en miroir. Par conséquent, les méthodes traditionnelles d'analyse des causes courantes de défaillance ne seront pas abordées dans cet article. L'exemple suivant illustre l'approche BlockSIM.

Prenons l'exemple suivant dans lequel l'événement A peut provoquer à la fois un échec X (s'il se produit en même temps qu'un événement B) et un échec Y (s'il se produit en même temps qu'un événement C).

blocksim simple common cause failure problem

L'exemple ci-dessus décrit un problème de défaillance d'origine courante simple. Dans cet exemple, l'événement A est la cause commune. Une distribution des défaillances doit être spécifiée pour les événements A, B et C. Les distributions d'échec des événements sont répertoriées ci-dessous.

Vous pouvez utiliser des blocs en miroir pour indiquer que les deux événements A sont en fait le même événement et pour spécifier que si l'événement A se produit, des défaillances X et Y peuvent survenir.

La probabilité d'une défaillance au niveau du système peut être déterminée à l'aide du Quick Calculation Pad comme suit.

Si les deux événements A de cet exemple d'arbre de failles n'avaient pas été reflétés, les résultats auraient été différents, comme le montre la figure suivante.