Fault Tree Analysis (FTA): método, puertas lógicas, cálculo y aplicación

Fault Tree Analysis aplicada a ingeniería: evento superior, puertas AND/OR, minimal cut sets, fallos de causa común, probabilidades y decisiones de confiabilidad.

¡Descúbrelo!

FTA — Fault Tree Analysis, o Análisis de Árbol de Fallos — es una técnica deductiva utilizada para estudiar cómo fallos, condiciones y combinaciones de eventos pueden producir un evento indeseado previamente definido. El análisis comienza por el efecto que se desea comprender, denominado evento superior, y avanza de arriba hacia abajo descomponiendo sus causas mediante relaciones lógicas hasta llegar a eventos suficientemente elementales para su análisis y tratamiento.

La técnica es especialmente útil cuando la pérdida de una función no depende de un único fallo, sino de la interacción entre redundancias, protecciones, utilities, interfaces, software, error humano y condiciones comunes. En lugar de limitarse a enumerar posibles causas, el árbol muestra qué eventos aislados son suficientes, cuáles deben ocurrir conjuntamente y qué dependencias pueden invalidar una redundancia aparentemente robusta.

Una FTA puede ser cualitativa o cuantitativa. En el análisis cualitativo, el objetivo es identificar caminos de fallo, puntos únicos, dependencias y conjuntos mínimos capaces de conducir al evento superior. En el enfoque cuantitativo, probabilidades, indisponibilidades o frecuencias pueden propagarse por la lógica del árbol, siempre que los datos, las unidades y las premisas de independencia sean técnicamente adecuadas.

FTA no es sinónimo de FMEA ni de análisis de causa raíz. FMEA parte de los modos de fallo de componentes y analiza sus efectos; FTA parte de un evento indeseado y busca las combinaciones capaces de producirlo. RCA normalmente investiga una ocurrencia real para evitar su repetición. La elección de la técnica depende de la pregunta de ingeniería que necesita respuesta.

Evento superior y frontera: dónde comienza realmente la FTA

La calidad del árbol depende de la definición del problema. Un evento superior como «fallo del sistema» es demasiado amplio para orientar una descomposición consistente. Una formulación como «pérdida total de alimentación de la carga crítica durante un periodo superior al tiempo de transferencia admisible en operación normal» delimita función, condición y criterio de fallo.

Antes de construir la lógica, también es necesario establecer la frontera del sistema. Fuentes externas, utilities, personas, software, entorno, protección, telecomunicaciones y sistemas auxiliares pueden estar dentro o fuera del alcance. Un elemento situado fuera de la frontera puede aparecer como evento básico; el mismo elemento, cuando forma parte del sistema estudiado, debe desarrollarse.

Una definición adecuada registra al menos:

• función o condición perdida;
• sistema e interfaces considerados;
• estado operativo analizado;
• duración o límite relevante, cuando corresponda;
• premisas de redundancia y reparación;
• elementos explícitamente excluidos.

Esta formalización evita árboles que crecen sin criterio y permite que otro equipo comprenda exactamente qué condición fue modelada.

Eventos y puertas lógicas del Árbol de Fallos

El árbol utiliza eventos y puertas para representar relaciones causales. El evento básico es aquel que no se descompondrá adicionalmente dentro del objetivo del análisis; esto no significa que sea físicamente indivisible, sino únicamente que ha alcanzado el nivel de detalle considerado suficiente.

Elemento	Interpretación práctica
Evento superior	condición indeseada que inicia el análisis
Evento intermedio	condición resultante de la combinación de eventos inferiores
Evento básico	evento tratado como elemental en el alcance del árbol
Evento no desarrollado	evento cuya descomposición no se realizó, con justificación
Puerta OR	cualquiera de las entradas puede producir la salida
Puerta AND	todas las entradas deben ocurrir para producir la salida

Considere un sistema de ventilación cuya pérdida pueda producirse por fallo del ventilador, pérdida de su alimentación o mando bloqueado. Si cualquiera de estas condiciones es suficiente, la relación se representa mediante una puerta OR. En otra situación, una carga alimentada por dos vías independientes puede perderse únicamente si la vía A y la vía B están indisponibles; la relación se representa mediante AND.

La lógica debe representar la condición física real, no la apariencia del diagrama. Si ambas vías comparten una misma barra, controlador o entorno, la premisa de independencia debe revisarse antes de tratarlas simplemente como eventos AND independientes.

Cómo construir una FTA paso a paso

Una secuencia técnicamente consistente es:

1. Definir el objetivo del análisis. Determinar si el árbol se utilizará para diseño, seguridad, disponibilidad, diagnóstico, comparación de alternativas o cuantificación del riesgo.
2. Definir el evento superior. Especificar función perdida, condición operativa, límite y duración cuando sean relevantes.
3. Establecer la frontera. Registrar sistemas, interfaces, fuentes externas y condiciones incluidas.
4. Identificar causas inmediatas. Preguntar qué condiciones son necesarias o suficientes para producir el evento superior.
5. Aplicar las puertas lógicas. Conectar eventos mediante relaciones coherentes con el comportamiento físico y funcional.
6. Descomponer eventos intermedios. Continuar hasta alcanzar eventos básicos adecuados al propósito del estudio.
7. Analizar dependencias y causas comunes. Verificar elementos compartidos entre caminos aparentemente redundantes.
8. Generar y revisar cut sets. Identificar combinaciones mínimas que producen el evento superior.
9. Cuantificar, cuando sea necesario. Aplicar datos de probabilidad, indisponibilidad o frecuencia con premisas explícitas.
10. Transformar resultados en decisiones. Evaluar rediseño, monitorización, mantenimiento, barreras, pruebas o procedimientos.

La descomposición debe detenerse cuando el nivel alcanzado permite tomar una decisión. Desarrollar componentes irrelevantes hasta niveles microscópicos no mejora necesariamente el análisis; detenerse demasiado pronto, por otro lado, puede ocultar causas comunes o posibles acciones de ingeniería.

Minimal cut sets y análisis cualitativo

Un cut set es un conjunto de eventos básicos cuya ocurrencia conjunta es suficiente para producir el evento superior. Un minimal cut set es mínimo en sentido lógico: si se elimina cualquier evento, esa combinación deja de ser suficiente.

Imagine un árbol en el que el evento superior ocurre si A y B fallan simultáneamente o si C falla por sí solo. Los conjuntos mínimos son:

• {A, B};
• {C}.

El segundo es un conjunto de primer orden: un único evento es suficiente para producir el evento superior. En sistemas diseñados para tolerar un fallo, este resultado merece análisis inmediato porque puede representar un Single Point of Failure — SPOF.

El orden del cut set no es, por sí solo, una medida de riesgo. Un conjunto de primer orden con probabilidad extremadamente baja puede contribuir menos al riesgo total que una combinación de segundo orden formada por eventos frecuentes. El análisis cualitativo identifica la estructura lógica; la priorización debe considerar también probabilidad, consecuencia, detectabilidad y contexto operativo.

Este tipo de razonamiento complementa el Análisis de Criticidad de Activos, que ayuda a decidir dónde un análisis detallado de fallos genera mayor valor.

Cómo calcular probabilidades en puertas AND y OR

La cuantificación exige atención a la variable utilizada. La probabilidad de fallo durante una misión, la indisponibilidad en un instante determinado y la frecuencia de ocurrencia son magnitudes relacionadas, pero no automáticamente intercambiables.

Para dos eventos independientes A y B conectados mediante una puerta AND:

P(A ∩ B) = P(A) × P(B)

Si cada camino tiene una probabilidad de indisponibilidad de 0,01 en la condición analizada y la independencia es técnicamente válida:

P(AND) = 0,01 × 0,01 = 0,0001, o 0,01%.

Para una puerta OR con dos eventos independientes:

P(A ∪ B) = P(A) + P(B) − P(A)P(B)

Con varios eventos independientes, la probabilidad de que ocurra al menos uno puede expresarse como:

P(OR) = 1 − ∏(1 − Pi)

Cuando todos los eventos son raros, la suma de las probabilidades puede utilizarse como aproximación en determinados análisis, pero esta simplificación debe reconocerse explícitamente como una aproximación.

Sin embargo, el problema más relevante normalmente no es el álgebra: es la validez de las premisas. Multiplicar probabilidades de dos vías que comparten la misma alimentación auxiliar o el mismo software puede producir un resultado aparentemente excelente y técnicamente engañoso.

Fallos de causa común y dependencias entre redundancias

La redundancia de equipos no significa independencia funcional. Dos vías pueden compartir elementos capaces de derribarlas simultáneamente:

• barra o alimentación auxiliar;
• sala o condición ambiental;
• ruta física de cables;
• lógica de control o firmware;
• sistema de refrigeración;
• puesta a tierra;
• equipo y procedimiento de mantenimiento;
• configuración común;
• utility externa.

Considere dos fuentes A y B que alimentan una carga crítica, pero convergen en un único cuadro de salida. Un árbol simplificado puede representar la pérdida de la carga como:

fallo del cuadro común OR (fallo de la vía A AND fallo de la vía B).

La arquitectura posee redundancia en las fuentes, pero el cuadro común crea un camino de primer orden hacia el evento superior. FTA hace explícito aquello que un diagrama con «dos fuentes» puede ocultar.

El mismo razonamiento se aplica a redes con dos switches conectados por una única ruta de fibra, bombas redundantes con aspiración común o controladores duplicados ejecutando la misma configuración incorrecta. La ingeniería debe evaluar la independencia de función, no únicamente la cantidad de equipos.

Este principio es central en Reliability by Design, especialmente en arquitecturas que dependen de tolerancia a fallos.

Condición normal, mantenimiento y estados degradados

Un árbol representa un estado definido. Un sistema puede cumplir el criterio de redundancia en operación normal y perder esa característica durante mantenimiento, pruebas o contingencia.

Por ello, los sistemas críticos pueden requerir árboles o escenarios específicos para condiciones como:

Estado	Pregunta de ingeniería
Operación normal	¿qué combinaciones conducen a la pérdida de la función con todos los caminos disponibles?
Una vía en mantenimiento	¿qué eventos adicionales pasan a ser suficientes para el evento superior?
Operación degradada	¿qué barreras permanecen efectivas?
Arranque o transferencia	¿existen fallos específicos de secuencia, mando o sincronismo?
Modo manual	¿la intervención humana introduce nuevos caminos de fallo?

Este enfoque evita evaluar la disponibilidad únicamente en la configuración nominal. En instalaciones de misión crítica, el mantenimiento concurrente y las transiciones de estado pueden ser tan importantes como la arquitectura estática.

FTA, FMEA, RCA y RAM: qué técnica responde a qué pregunta

Las técnicas son complementarias y deben elegirse según la pregunta que se pretende responder.

Técnica	Dirección / enfoque	Pregunta típica
FTA	deductiva, top-down	¿qué combinaciones pueden producir este evento superior?
FMEA	inductiva, bottom-up	¿qué ocurre cuando aparece este modo de fallo?
RCA	investigativa	¿por qué ocurrió este evento y cómo evitar su recurrencia?
RAM	desempeño del sistema	¿qué confiabilidad, disponibilidad y mantenibilidad entrega la arquitectura?

Una FMEA puede aportar modos de fallo relevantes para el árbol. Un Análisis de Causa Raíz puede utilizar una lógica semejante para probar hipótesis después de una ocurrencia, pero no se convierte automáticamente en una FTA formal. Un Análisis RAM puede utilizar modelos de fallo y reparación para evaluar el desempeño global de la arquitectura.

Separar estas responsabilidades evita producir análisis diferentes con el mismo contenido y nombres distintos.

FTA en proyecto, Design Review y mantenimiento

FTA puede aplicarse antes de que ocurra un fallo. En proyecto y Design Review, la técnica ayuda a verificar puntos únicos, dependencias comunes, cobertura de protección y comportamiento en estados degradados. Un cambio de arquitectura puede compararse entonces por la reducción o eliminación de caminos críticos.

Durante la operación, el árbol también puede apoyar la definición de pruebas y estrategias de mantenimiento. Si una función de protección permanece oculta hasta que es requerida, FTA puede evidenciar la importancia de la prueba funcional. Si determinados eventos básicos dominan los cut sets, la monitorización de condición, los repuestos o la revisión de frecuencia pueden ser más eficaces que aumentar indiscriminadamente el mantenimiento preventivo.

Cuando el análisis indica la necesidad de una revisión estructurada de la estrategia, la interfaz natural es con la Ingeniería de Confiabilidad y Disponibilidad, la Gestión de Riesgos de Ingeniería y el Design Review, según la fase del ciclo de vida.

FTA como instrumento de gobernanza, assurance y decisión de ingeniería

FTA adquiere mayor valor cuando deja de tratarse como un diagrama aislado y pasa a integrar el sistema de decisión de ingeniería. La propia terminología brasileña de confiabilidad y mantenibilidad asocia la gestión de la confiabilidad con actividades planificadas, control, auditoría, supervisión y revisión de diseño. En este contexto, el árbol de fallos puede funcionar como evidencia técnica para justificar requisitos, verificar arquitecturas, priorizar riesgos y sustentar decisiones en diferentes fases del ciclo de vida.

En organizaciones con gobernanza técnica estructurada, el modelo puede incorporarse a procesos de Ingeniería de Confiabilidad y Disponibilidad, Gestión de Riesgos de Ingeniería, Design Review y Owner’s Engineering. Cada una de estas disciplinas utiliza el análisis con una finalidad diferente, pero todas dependen de requisitos, criterios de decisión y trazabilidad.

Fase	Uso de FTA	Decisión soportada
Concepción / FEED	comparar arquitecturas, redundancias y puntos únicos	selección de alternativa y requisitos de confiabilidad
Proyecto	verificar interfaces, protecciones y causas comunes	rediseño, segregación, instrumentación y criterios de prueba
Contratación	traducir riesgos en requisitos verificables	especificaciones, garantías, FAT/SAT y responsabilidades
Implantación	validar si barreras y redundancias fueron materializadas	aceptación, punch list, pruebas integradas y correcciones
Operación	reevaluar escenarios con datos de campo y estados degradados	mantenimiento, monitorización, repuestos y contingencia
Cambio / retrofit	comparar el riesgo antes y después de la modificación	aprobación del cambio y riesgo residual

Esta integración convierte FTA en parte de Project Assurance: el análisis no sirve únicamente para «mostrar riesgo», sino para verificar si la solución propuesta cumple los requisitos y si las decisiones poseen base técnica suficiente. En proyectos críticos, la Auditoría Técnica de Ingeniería puede utilizar árboles existentes, premisas, registros de pruebas y evidencias de campo para evaluar la coherencia entre proyecto, condición instalada y desempeño.

Gobernanza del modelo: responsables, premisas, versiones y cambios

Una FTA utilizada para decisión debe gobernarse como información de ingeniería. Debe existir un responsable del modelo, una definición clara del evento superior, control de las premisas, identificación de las fuentes de datos, versionado y criterios de revisión. Sin ello, dos equipos pueden analizar el mismo sistema con fronteras e hipótesis diferentes y producir resultados que parecen comparables, pero no lo son.

Esta necesidad conecta el análisis con la Gobernanza Documental, la Gestión de Requisitos, Evidencias y Criterios de Aceptación y la Gestión de Procesos, Workflows y Aprobaciones Técnicas. El modelo puede tener estados de elaboración, revisión independiente, aprobación y obsolescencia, igual que otros documentos de ingeniería que sustentan decisiones críticas.

Los cambios también deben disparar reevaluación. Modificar firmware, lógica de control, alimentación auxiliar, topología de red, ruta física, configuración de protección, estrategia de mantenimiento o proveedor puede alterar dependencias existentes en el árbol. La Gestión de Pendientes, RFIs y No Conformidades ayuda a mantener visibles las desviaciones identificadas, mientras que procesos formales de aprobación evitan que una modificación invalide premisas de confiabilidad sin que nadie lo perciba.

En la transición entre implantación y operación, el árbol debe reconciliarse con la condición realmente construida. El Comisionamiento de Ingeniería, el As-Built, la Recepción Técnica y el Recomisionamiento son puntos naturales para confirmar si las redundancias, protecciones e interfaces representadas en el modelo existen y funcionan como se previó.

FTA integrada con la gestión de activos y la ingeniería de mantenimiento

En gestión de activos, el objetivo no es eliminar cualquier posibilidad de fallo, sino decidir dónde aplicar recursos para generar valor considerando desempeño, riesgo, coste y horizonte de vida. FTA contribuye a esta decisión al mostrar qué eventos y combinaciones dominan un determinado escenario. Este resultado puede alimentar la Ingeniería de Mantenimiento, la Gestión de Activos de Ingeniería y los planes de confiabilidad.

Si un evento básico de primer orden está asociado a un componente sin redundancia, la respuesta puede ser rediseño. Si el riesgo deriva de un fallo latente en una protección, la respuesta puede ser una prueba periódica. Si la contribución principal procede de una causa ambiental común, la solución puede ser segregación o monitorización. Si la indisponibilidad depende de largos retrasos logísticos, la decisión puede involucrar repuestos, contrato de soporte o estrategia de reparación. El mismo árbol, por tanto, puede orientar diseño, mantenimiento, suministros y operación.

Esta lectura es especialmente importante para activos y sistemas críticos, donde un análisis puramente por equipo puede perder dependencias funcionales. Los contenidos sobre Plan de Gestión de Activos, Ingeniería de Mantenimiento y Análisis RAM complementan FTA al conectar el escenario de fallo con objetivos, desempeño y ciclo de vida.

Aplicaciones transversales en infraestructura crítica

La técnica es transversal porque el razonamiento funcional es independiente de la disciplina. En una subestación, el evento superior puede ser pérdida de teleasistencia, indisponibilidad de protección o pérdida de alimentación auxiliar. En un Data Center, puede ser pérdida de energía para una carga crítica o indisponibilidad térmica. En seguridad electrónica, puede ser pérdida de cobertura de un área o incapacidad de grabación. En telecomunicaciones, puede ser pérdida de conectividad entre puntos críticos.

Esta transversalidad aparece en soluciones como Teleasistencia y Monitorización Operativa en Subestaciones, Ingeniería Integrada para Data Centers, Instalaciones Eléctricas de Media Tensión y sistemas integrados de seguridad, donde la disponibilidad depende de múltiples interfaces técnicas.

En los proyectos publicados por A3A, este tipo de complejidad puede observarse en diferentes contextos. El monitoreo operativo para soporte a teleasistencia en una subestación de transmisión combina operación remota, redes y sistemas de monitorización; los proyectos turnkey de monitoreo en Londrina, Umuarama y Guaíra muestran arquitecturas distribuidas en entornos de transmisión.

En otra tipología, el FEED de un sistema de vigilancia electrónica en una central hidroeléctrica y el FEED de telecomunicaciones en el mismo proyecto evidencian la necesidad de analizar interfaces desde las etapas de definición. La implantación turnkey de un sistema integrado en un complejo gubernamental demuestra la aplicación en un entorno con múltiples subsistemas, infraestructura, redes y operación.

Cómo puede contratarse un análisis de confiabilidad

Una contratación de FTA no necesita limitarse a la entrega de un árbol. En un enfoque de ingeniería consultiva, el trabajo puede incluir levantamiento de requisitos, definición de frontera, workshops técnicos, modelado, análisis de cut sets, cuantificación cuando corresponda, revisión independiente, recomendaciones, matriz de acciones e integración con registros de riesgos y cambios.

Según la etapa del activo, este alcance puede desarrollarse como Consultoría Técnica de Ingeniería, dentro de un Design Review, como apoyo a Owner’s Engineering o bajo un régimen de Servicios Continuados de Ingeniería Consultiva. El diferencial está en transformar el análisis en una decisión trazable y acompañar si las acciones recomendadas realmente modificaron el riesgo.

Datos, premisas y validación del árbol

Una FTA cuantitativa debe registrar el origen y la aplicabilidad de los datos. Historial propio, datos de fabricante, bancos de confiabilidad, ensayos y análisis estadísticos pueden utilizarse, pero ninguna fuente elimina la necesidad de verificar régimen operativo, población y unidad temporal.

Premisas como independencia, tiempo de misión, estado inicial, política de reparación, cobertura de protección y disponibilidad de recursos deben permanecer visibles. Sin ellas, el número calculado no es reproducible.

La revisión técnica debe verificar si el evento superior sigue correctamente definido, si la frontera es coherente, si los eventos repetidos fueron tratados como el mismo evento, si las causas comunes están representadas y si los cut sets tienen sentido físico. Cambios de diseño, configuración u operación pueden invalidar un árbol antiguo aunque su lógica matemática siga siendo correcta.

Entre los errores más recurrentes están asumir independencia sin justificación, mezclar tasa de fallo con probabilidad, ignorar condiciones de mantenimiento, descomponer eventos sin relevancia y aceptar la salida numérica del software sin revisión de ingeniería.

FTA está concluida cuando su lógica y sus premisas permiten responder a la pregunta original y orientar una decisión. El objetivo no es producir el árbol más grande posible, sino revelar de forma trazable cómo puede ocurrir el evento superior, qué caminos dominan el riesgo y qué cambios realmente modifican ese resultado.

Referencias técnicas

[1] IEC. IEC 61025:2006 — Fault tree analysis (FTA).

[2] IEC. IEC 31010:2019 — Risk management — Risk assessment techniques.

[3] ABNT. ABNT NBR 5462:1994 — Confiabilidad y mantenibilidad — Terminología.

[4] ISO. ISO 55000:2024 — Asset management — Vocabulary, overview and principles.

[5] ISO. ISO 55001:2024 — Asset management — Asset management system — Requirements.

[6] ISO. ISO 21505:2017 — Project, programme and portfolio management — Guidance on governance.

Preguntas frecuentes

¿Qué es FTA?

FTA, o Fault Tree Analysis, es una técnica deductiva que parte de un evento superior indeseado y descompone lógicamente las combinaciones de eventos capaces de producirlo.

¿Cuál es la diferencia entre FTA y FMEA?

FTA es top-down: parte de un evento indeseado y busca sus combinaciones causales. FMEA es bottom-up: parte de los modos de fallo y analiza sus efectos.

¿Qué significa una puerta AND en FTA?

La puerta AND indica que todas las entradas deben ocurrir para producir la salida. Para eventos independientes, la probabilidad conjunta puede calcularse como el producto de las probabilidades.

¿Qué significa una puerta OR en FTA?

La puerta OR indica que cualquiera de las entradas es suficiente para producir la salida. La probabilidad de la unión debe considerar la superposición entre eventos.

¿Qué es un minimal cut set?

Es un conjunto mínimo de eventos básicos cuya ocurrencia conjunta es suficiente para producir el evento superior. Si se elimina cualquier evento, esa combinación deja de ser suficiente.

¿FTA debe ser cuantitativa?

No. El análisis cualitativo ya puede revelar puntos únicos de fallo, dependencias, causas comunes y caminos críticos. La cuantificación debe utilizarse cuando los datos y las premisas sean adecuados.

Materiales técnicos relacionados

Servicios de ingeniería relacionados

• Ingeniería de Confiabilidad y Disponibilidad
• Gestión de Riesgos de Ingeniería
• Design Review en Proyectos de Ingeniería

Contenidos técnicos relacionados

• FMEA en Ingeniería: cómo analizar modos, efectos y causas de fallo
• Análisis de Causa Raíz — RCA
• Análisis RAM: Reliability, Availability y Maintainability
• Reliability by Design: cómo diseñar sistemas para confiabilidad y mantenibilidad
• Análisis de Criticidad de Activos
• Ingeniería de Confiabilidad: métodos, indicadores y aplicaciones

Guías y referencias

• Gestión de Ingeniería: procesos, gobernanza, proyectos y desempeño
• Data Center Resiliente: evaluación, proyecto, modernización y aceptación