Qué es un árbol de fallos
El árbol de fallos, conocido como FTA, es una representación deductiva. Comienza por un suceso que se desea evitar y examina qué situaciones pueden producirlo. Cada rama se desarrolla mediante relaciones lógicas hasta llegar a sucesos básicos o a elementos que no se desarrollan más por los límites del estudio.
Puede emplearse de forma cualitativa para entender vulnerabilidades o complementarse con una estimación cuantitativa. Su utilidad depende de que el modelo represente el sistema real. Un diagrama extenso no es necesariamente mejor si contiene relaciones imprecisas, oculta supuestos o mezcla consecuencias diferentes bajo una misma descripción.
Definir el suceso superior y los límites
El suceso superior debe indicar claramente qué ocurre y en qué condiciones. Expresiones como fallo general son demasiado ambiguas para construir una lógica verificable. Conviene definir la función perdida o la situación peligrosa, junto con el modo operativo y el periodo o demanda que interesa analizar.
El alcance incluye equipos, suministros, interfaces y actuaciones humanas relevantes. También establece qué queda fuera y por qué. La información de diseño, operación y mantenimiento debe permitir contrastar las relaciones propuestas. Cuando falta información, el árbol puede marcar una rama pendiente de desarrollo, manteniendo visible esa limitación.
Puertas lógicas y construcción del modelo
Una puerta O representa situaciones en las que basta cualquiera de los sucesos conectados para producir el siguiente. Una puerta Y representa una combinación en la que deben concurrir todos los sucesos definidos. La condición temporal y el significado de concurrencia necesitan coherencia con el escenario estudiado.
El árbol se construye por niveles, comprobando cada relación antes de continuar. Las causas deben estar al mismo nivel de descripción cuando se comparan. Si una rama utiliza fallos físicos y otra expresiones generales como mala gestión, será necesario precisar los mecanismos que conectan esos factores con el suceso superior.
Dependencias y causas comunes
Dos equipos físicamente separados pueden compartir alimentación, ambiente, mantenimiento o información. Por ello no se debe asumir independencia solo porque existan dos dispositivos. Un mismo suceso puede inutilizar varias funciones y debe representarse de modo que el análisis no atribuya una redundancia inexistente.
Los sucesos repetidos necesitan una identificación consistente. Si aparecen como eventos distintos en ramas separadas, la estimación puede resultar engañosa. El análisis cualitativo ayuda a localizar combinaciones mínimas capaces de producir el suceso superior y a reconocer fallos individuales que comprometen varias protecciones simultáneamente. Un conjunto mínimo de fallo describe una combinación suficiente para producir el suceso superior que deja de ser suficiente si se retira cualquiera de sus elementos. Su interpretación ayuda a priorizar el estudio de vulnerabilidades. No debe confundirse con una lista de componentes a sustituir: la decisión preventiva requiere revisar mecanismos, consecuencias y opciones de diseño.
Cuándo y cómo cuantificar
La cuantificación requiere datos adecuados sobre fallos, demandas, tiempos y disponibilidad, con una interpretación compatible con el modelo. Una tasa de fallo, una probabilidad de fallo en demanda y una probabilidad durante un periodo no son magnitudes intercambiables. Los supuestos deben documentarse para que otra persona pueda revisar el cálculo.
En condiciones apropiadas de independencia pueden aplicarse relaciones probabilísticas, pero no deben usarse mecánicamente para cualquier puerta. Las dependencias, reparaciones y secuencias pueden requerir modelos más elaborados. Presentar muchos decimales no compensa la falta de datos. Es preferible expresar incertidumbre y analizar sensibilidad que ofrecer una cifra aparentemente exacta.
Diferencias con otros análisis
El árbol de causas suele emplearse para reconstruir hechos de un accidente ocurrido. El árbol de fallos modela combinaciones posibles que conducen a un suceso definido. Ambos usan relaciones entre eventos, pero su finalidad y forma de justificar las ramas son diferentes.
El AMFE parte de funciones o elementos y recorre sus fallos potenciales. El análisis Bow-tie conecta amenazas, suceso central, consecuencias y barreras. Estos métodos pueden alimentar el árbol de fallos, siempre que se comprueben las relaciones y no se trasladen automáticamente las conclusiones de un formato a otro.
Ejemplo práctico
Se estudia la pérdida de una función de protección durante una operación. El equipo identifica dos canales que, en apariencia, proporcionan redundancia. Al revisar documentación y mantenimiento descubre que ambos dependen de un mismo suministro auxiliar, cuya pérdida puede afectar a los dos al mismo tiempo.
El árbol incorpora esa causa común y muestra que no basta con multiplicar probabilidades de fallo individuales como si los canales fueran independientes. El equipo revisa el diseño y las comprobaciones necesarias. El ejemplo ilustra la utilidad del razonamiento lógico; la solución técnica requiere datos y validación específicos de la instalación.
Uso preventivo y revisión
Los resultados deben convertirse en decisiones sobre diseño, mantenimiento, pruebas, procedimientos o análisis adicionales. Cada recomendación necesita responsable y evidencia de cierre. Cuando cambia una condición del sistema, la gestión del cambio debe revisar si el árbol continúa siendo representativo.
Entre los errores más frecuentes están definir mal el suceso superior, omitir suministros compartidos, duplicar eventos y confundir probabilidades con frecuencias. El árbol debe ayudar a comprender y mejorar la seguridad, no funcionar como una justificación gráfica elaborada después de haber decidido que el riesgo es aceptable.
