Análisis del árbol de fallas

El análisis del árbol de fallas (en inglés: Fault tree analysis, FTA) es un análisis de falla deductivo de arriba hacia abajo (descendente) en el que se analiza un estado no deseado de un sistema utilizando la lógica booleana para conjugar una serie de eventos de bajo nivel. Este método de análisis se utiliza sobre todo en los campos de ingeniería de seguridad e ingeniería de fiabilidad para comprender cómo los sistemas pueden fallar, para identificar las mejores formas de reducir un riesgo o para determinar (o comenzar a comprender) tasas de eventos de un accidente de seguridad o una falla (funcional) de un nivel en particular de un sistema. El FTA se aplica en la industria aeroespacial,[1]​ en la ingeniería nuclear, en la industria de química y procesos,[2]​[3]​[4]​ en la industria farmacéutica,[5]​ en la industria petroquímica y en otras industrias de alto riesgo; pero también se aplica en campos tan diversos como la identificación de factores de riesgo relacionados con el sistema de fallo del servicio social,[6]​ lo mismo que en la ingeniería de software, para propósitos de depuración. Está estrechamente relacionado con la técnica de eliminación de causas utilizada para detectar errores de código.[7]​

En la industria aeroespacial, el término general condición de falla del sistema se usa para el estado no deseado o estado superior del árbol de falla. Estas condiciones se clasifican en función de la severidad de sus efectos. Las condiciones más graves requieren el análisis más extenso del árbol de fallas.^[cita requerida]

Uso

El análisis de un árbol de fallas puede usarse para:

• Entender la lógica que conduce al evento superior / estado no deseado;

• Mostrar conformidad con la (entrada) seguridad del sistema / los requisitos de fiabilidad;
• Priorizar los colaboradores que conducen hacia el evento superior, creando las listas de equipamiento crítico/partes/eventos para diferentes medidas de importancia;
• Monitorear y controlar el rendimiento de seguridad de un sistema complejo (por ejemplo, ¿es seguro para una aeronave en particular volar cuando la válvula de combustible x falla? ¿por cuánto tiempo se le permite volar con el fallo de la válvula?;
• minimizar y optimizar recursos;
• Asistir en el diseño de un sistema: puede utilizarse como herramienta de diseño que ayuda a crear requerimientos de salida/nivel más bajo;
• Funcionar como herramienta de diagnóstico para identificar y corregir las causas del evento superior; puede ayudar con la creación de manuales / procesos de diagnóstico.

Historia

El Análisis del Árbol de Fallas (FTA) fue originalmente desarrollado entre los años 1970 a 1971 en los Laboratorios Bell por H. A. Watson, bajo un contrato con la División de Sistemas de Balística de la Fuerza Aérea de Estados Unidos para evaluar el Sistema de Control de Lanzamiento del Misil Balístico Intercontinental Minuteman I (ICBM).[8]​[9]​[10]​[11]​ El uso de árboles de fallas desde entonces ha ganado un apoyo extendido y es a menudo utilizado como herramienta de análisis de fallas por expertos en fiabilidad.[12]​ Siguiendo el primer uso publicado del FTA en el Estudio del Sistema de Control de Lanzamiento del Minuteman I en 1962, Boeing y AVCO expandieron el uso del FTA al sistema completo del Minuteman II en los años 1963-1964. El FTA recibió extensa cobertura en un Simposio de Seguridad de Sistemas en Seattle en 1965, patrocinado por Boeing y la Universidad de Washington.[13]​ Boeing empezó a utilizar el FTA para el diseño de aeronaves civiles alrededor de 1966.[14]​[15]​

Posteriormente, dentro del ejército de EE. UU., la aplicación del FTA para su uso con fuzes fue explorado por el "Picatinny Arsenal" en las décadas de los 60 y 70.[16]​ En 1976 el Comando de Material Bélico del Ejército de Estados Unidos, incorporó el FTA en un Manual de Diseño de Ingeniería sobre Diseño para Confiabilidad.[17]​ El Centro de Análisis de la Fiabilidad en el Laboratorio de Roma y sus organizaciones sucesoras, ahora con el Centro de Información Técnica de Defensa (Centro de Análisis de Información de Confiabilidad y ahora Centro de Análisis de Información de Sistemas de Defensa, https://www.dsiac.org/) ha publicado documentación sobre el FTA y los bloques de diagramas de fiabilidad desde la década de los 60.[18]​[19]​[20]​ MIL-HDBK-338B proporciona una referencia más reciente.[21]​

En 1970, la Administración de Aviación Federal (FAA por sus siglas en inglés) de los EE.UU publicó un cambio respecto a las regulaciones de navegabilidad 14 CFR 25.1309 para aeronaves de categoría de transporte en el Registro Federal en el 35 FR 5665 (1970-04-08). Este cambio adoptó criterios probabilísticos de falla para sistemas de aeronaves y equipamientos, y condujo al amplio uso del FTA en la aviación civil. En 1998, la Administración de Aviación Federal publicó la Orden 8040.4,[22]​ estableciendo la política de administración de riesgo, que incluye al análisis de riesgo en una gama de actividades críticas más allá de la certificación de aeronaves, incluyendo el control de tráfico aéreo y la modernización del Sistema Nacional de Espacio Aéreo de los EE.UU. Esto condujo a la publicación del Manual de Seguridad del Sistema de la Administración de Aviación Federal, el cual describe el uso del FTA en varios tipos de análisis formales de riesgo.[23]​

Anteriormente en el proyecto Apolo la cuestión se enmarcaba en la probabilidad de enviar con éxito los astronautas a la Luna y regresarlos a salvo a la Tierra. Se hizo un cálculo de riesgo o fiabilidad de algún tipo, y el resultado fue una probabilidad de éxito de la misión que era inaceptablemente bajo. Este resultado desanimó a la NASA de realizar análisis cuantitativos de riesgo y fiabilidad hasta después del accidente del Challenger en 1986. En cambio, la NASA decidió confiar en el uso del análisis modal de fallos y efectos (AMFE) y otros métodos cualitativos para valoraciones de la seguridad de los sistemas. Después del accidente del Challenger, la importancia de la Evaluación probabilística del riesgo (en inglés: Probabilistic Risk Assessment, PRA) y el FTA en el análisis de riesgo y fiabilidad de sistemas, fueron tomadas en cuenta y empezó a crecer su uso en la NASA, y ahora el FTA es considerado como una de las más importantes técnicas de fiabilidad y análisis de seguridad de sistemas.[24]​

Dentro de la industria nuclear, La Comisión Reguladora Nuclear de EE. UU. (en inglés: Nuclear Regulatory Commission, NRC) empezó utilizar los métodos de evaluación probabilística del riesgo (en inglés: probabilistic risk assessment, PRA) incluyendo el FTA en 1975, y expandieron significativamente la investigación PRA luego del Accidente de Three Mile Island en 1979.[25]​ Esto finalmente condujo a la publicación del Manual del Árbol de Fallas NRC NUREG–0492,[26]​ y al uso obligatorio del PRA bajo autoridad reguladora de la NRC.

Luego de desastres de procesos industriales como el Desastre de Bhopal en 1984 y la explosión del Piper Alfa en 1988, en 1992 el Departamento de Seguridad Laboral y Administración de Salud de los EE.UU (en inglés: Occupational Safety and Health Administration, OSHA) publicó en el Registro Federal en el 57 FR 6356 (1992-02-24) su estándar de Administración de Seguridad de Procesos (en inglés: Process Safety Management, PSM) en el 19 CFR 1910.119.[27]​ OSHA PSM reconoce al FTA como un método aceptable para el análisis de riesgo de procesos.

Hoy el FTA es ampliamente utilizado en seguridad de sistemas e ingeniería de fiabilidad, y en todos los campos importantes de la ingeniería.

Metodología

La metodología del FTA está descrita en varios estándares industriales y del gobierno, incluyendo la NRC NUREG–0492 para la industria nuclear, una revisión del NUREG–0492 orientada a la industria aeroespacial usada por la NASA,[28]​ la SAE ARP4761 para aeronaves civiles, la MIL–HDBK–338 para sistemas militares, y el estándar IEC IEC 61025[29]​ que se pretende para el uso de la industria cruzada y ha sido adoptada como Norma europea EN 61025.

Cualquier sistema suficientemente complejo está sujeto a fallas, a causa del fallo de uno o más sus subsistemas. La probabilidad de falla, sin embargo, a menudo puede ser reducida a través del diseño mejorado del sistema. El análisis de árboles de fallas mapea la relación entre las fallas, los subsistemas, y los elementos redundantes del diseño de seguridad, creando un esquema lógico del sistema global.

El resultado no deseado se toma como la raíz ('acontecimiento / evento superior') de un árbol lógico. Por ejemplo, el resultado no deseado de una operación de prensado y estampado de metal, es que algún apéndice humano sea estampado. Trabajando hacia atrás desde este evento superior, podríamos determinar que hay dos maneras en que esto podría ocurrir: durante una operación normal o durante una operación de mantenimiento. Esta condición es un O lógico. Considerando la rama en la que ocurre durante una operación normal quizás determinamos que hay dos formas en que esto podría pasar: los ciclos de prensa hacen daño el operador o los ciclos de prensa hacen daño a otra persona. Esto es otro O lógico. Podemos hacer una mejora del diseño al requerir que el operador pulse dos botones para echar andar a la máquina - esta es una característica de seguridad en la forma de un Y lógico -. El botón puede tener una taza de fallo intrínseca - esto deviene en un incentivo de falla que podemos analizar-. Cuándo los árboles de fallas son ponderados con números reales para las probabilidades de fallas, los programas computacionales pueden calcular las probabilidades de fracaso en los árboles de fallas. Cuándo se tiene que un acontecimiento en concreto afecta a más de un evento, i.e. tiene impacto en varios subsistemas, se le llama una causa común o modo común. Hablando gráficamente, esto significa que este acontecimiento aparecerá en varias posiciones del árbol. Las causas comunes introducen relaciones de dependencia entre acontecimientos. Los cálculos de probabilidades de un árbol que contiene algunas "causas comunes" son mucho más complicados que en árboles normales donde todos los acontecimientos son considerados como independientes. No todas las herramientas de software disponibles en el mercado proporcionan tal capacidad.

El Árbol es normalmente escrito utilizando símbolos convencionales de puertas lógicas. La ruta a través de un árbol entre un acontecimiento y un iniciador en el árbol se llama un Cut Set. La manera creíble más corta a través del árbol desde un fallo hasta un evento inicializador se llama Cut Set Mínimo.

Algunas industrias utilizan ambos: los árboles de falla y los árboles de eventos (ver Valoración de Riesgo Probabilística). Un Árbol de Eventos empieza desde un inicializador no deseado (pérdida de suministro crítico, fracaso de componente, etc.) y sigue posibles eventos más lejanos del sistema a través de una serie de consecuencias finales. A medida que cada acontecimiento nuevo es considerado, se añade un nuevo nodo al árbol con una probabilidad dividida de tomar cualquier rama. Las probabilidades de una gama de 'acontecimientos superiores' surgiendo del acontecimiento inicial entonces pueden verse.

Los programas clásicos incluyen el software (EPRI) CAFTA del Instituto de Investigación de Energía Eléctrica, el cual es utilizado por muchas de los plantas nucleares de EE. UU. y por la mayoría de los fabricantes aeroespaciales internacionales y de EE. UU., y el SAPHIRE del Laboratorio Nacional de Idaho, el cual es utilizado por el Gobierno de EE. UU. para evaluar la seguridad y fiabilidad de reactores nucleares, el Transbordador espacial, y la Estación Espacial Internacional. Fuera de los EE. UU., el software RiskSpectrum es una herramienta popular para los análisis de Árbol de Fallas y de Árbol de Eventos y está autorizado para su uso en casi la mitad de las plantas nucleares del mundo por Evaluación Probabilística de Seguridad.

Símbolos gráficos

Los símbolos básicos utilizados en el FTA están agrupados como eventos, puertas, y símbolos de transferencia. Variaciones menores pueden ser utilizadas en softwares de FTA.

Símbolos de los eventos

Los símbolos de eventos son utilizados para acontecimientos primarios y acontecimientos intermedios. Los eventos primarios no se desarrollan más en el árbol de fallas. Los acontecimientos intermedios se encuentran en la salida de una puerta. Los símbolos de eventos se muestran debajo:

• 
  Acontecimiento / Evento básico
• 
  Acontecimiento / Evento externo
• 
  Acontecimiento / Evento no desarrollado
• 
  Acontecimiento / Evento Condicionante
• 
  Acontecimiento / Evento intermedio

Los símbolos de eventos primarios son típicamente utilizados como sigue:

• Evento básico - falla o error en un componente o elemento del sistema (ejemplo: Interruptor atascado en la posición de abierto)
• Evento externo - normalmente se espera que ocurra (No por sí mismo una falla)
• Evento no desarrollado - Un evento sobre el que no se dispone de información suficiente o que no tiene ninguna consecuencia
• Evento condicionante - Condiciones que restringen o afectan puertas lógicas (ejemplo: modo de operación en vigor)

Una puerta de evento intermedio se puede utilizar inmediatamente por encima de un evento primario, para proporcionar más espacio para escribir la descripción del evento. El FTA es un enfoque de arriba hacia abajo (descendente).

Símbolos de puerta lógica

Los símbolos de puerta describen la relación entre los eventos de entrada y de salida. Los símbolos se derivan de símbolos lógicos booleanos:

• 
  Puerta de O lógico
• 
  Puerta de Y lógico
• 
  Puerta de O-Exclusivo lógico
• 
  Puerta de Y lógico Priorizado
• 
  Puerta Inhibidora

Las puertas funcionan como sigue:

• Puerta de O lógico - La salida se produce si se produce alguna de las entradas
• Puerta de Y lógico - La salida se produce sólo si se producen todas las entradas (las entradas son independientes)
• Puerta de O-exclusivo lógico - La salida se produce si se produce exactamente una entrada
• Puerta de Y lógico priorizado - La salida se produce si las entradas se producen en una secuencia específica, especificada por un evento condicionante.
• Puerta inhibidora - Se produce la salida si la entrada se produce bajo una condición permisiva, especificada por un evento condicionante.

Símbolos de transferencia

Los símbolos de transferencia son usados para conectar las entradas y las salidas de árboles de fallas relacionados, tal como el árbol de fallas de un subsistema al de su sistema. La NASA preparó una documentación completa sobre el FTA a través de incidentes prácticos.

• 
  Transferencia entrante
• 
  Transferencia saliente

Fundamentación matemática básica

Los eventos en un árbol de fallas están asociados con probabilidades estadísticas. Por ejemplo, las componentes fallidas pueden presentarse generalmente con algún índice de falla constante λ (una función de riesgo constante). En este caso más sencillo, la probabilidad de falla depende del índice λ y del tiempo de exposición t:

P = 1 - exp(-λt)

P ≈ λt, λt < 0.1

Un árbol de fallas suele normalizarse a un intervalo de tiempo dado, como una hora de vuelo o un tiempo de misión mediano. Las probabilidades de los eventos dependen de la relación entre la función de riesgo del evento y su intervalo.^[cita requerida] A diferencia de los esquemas de puertas lógicas convencionales en los cuales las entradas y las salidas contienen los valores binarios de CIERTOS (1) o FALSOS (0), las puertas en el árbol de fallas producen probabilidades relacionadas con las operaciones de conjunto de la lógica Booleana. La probabilidad del evento de salida de una puerta depende de las probabilidades de los eventos de la entrada.

Una puerta de Y lógico representa una combinación de acontecimientos independientes. Esto es, la probabilidad de cualquier acontecimiento de entrada a una puerta de Y lógico no se ve afectada por ningún otro acontecimiento de entrada a la misma puerta. En términos de teoría de conjuntos, esto es equivalente a la intersección de los conjuntos de eventos de la entrada, y la probabilidad de la salida de la puerta de Y lógico está dada por:

P (A y B) = P (A ∩ B) = P(A) P(B)

Una puerta de O lógico, por otro lado, corresponde a una unión de conjuntos:

P (A o B) = P (A ∪ B) = P(A) + P(B) - P (A ∩ B)

Como las probabilidades de fallas en árboles de fallas tienden a ser pequeñas (menos de .01), P (A ∩ B) normalmente deviene en un término de error muy pequeño, y la salida de una puerta de O lógico puede ser aproximada conservadoramente usando la suposición de que las entradas son eventos mutuamente excluyentes:

P (A o B) ≈ P(A) + P(B), P (A ∩ B) ≈ 0

La puerta de O-Exclusivo con dos entradas representa la probabilidad que una o la otra entrada, pero no ambas, ocurra:

P (A xor B) = P(A) + P(B) - 2P (A ∩ B)

Nuevamente, como P (A ∩ B) normalmente deviene en un término de error muy pequeño, la puerta de O-Exclusivo tiene valor limitado en un árbol de fallas.

Análisis

Muchas aproximaciones diferentes se pueden usar para modelar un FTA, pero la más común y popular puede ser resumida en unos cuantos pasos. Un único árbol de fallas se usa para analizar uno y sólo un evento no deseado o evento superior, el cual puede alimentar posteriormente a otro árbol de falla como un evento básico. Aunque la naturaleza del evento no deseado puede variar dramáticamente, un FTA sigue el mismo procedimiento para cualquier evento no deseado; sea un retraso de 0.25 ms en la generación de energía eléctrica, un incendio no detectado en una bodega, o el lanzamiento fortuito e involuntario de un ICBM. Debido al costo de mano de obra, el FTA sólo se utiliza normalmente para eventos no deseados más graves.

El FTA implica cinco pasos:

1. Definir el evento no deseado a estudiar
   • El evento no deseado puede ser muy difícil de definir, a pesar de que algunos de los eventos son muy obvios y fáciles de observar. Un ingeniero con un amplio conocimiento del diseño del sistema, o un analista de sistemas con experiencia en ingeniería es la mejor persona para ayudar a definir y enumerar los eventos no deseados. Los eventos no deseados son utilizados entonces para hacer de un FTA, un evento para otro FTA. No se utilizarán dos eventos para realizar un FTA.
2. Lograr un entendiendo del sistema
   • Una vez el que el evento no deseado está seleccionado, todas las causas con probabilidades de 0 o más de afectar a este evento son estudiadas y analizadas. Obtener valores exactos para las probabilidades que conllevan al evento es normalmente imposible, debido a que puede ser muy costoso y el tiempo que consume es demasiado. Los softwares de computadoras se usan para estudiar las probabilidades; esto puede conducir a un análisis del sistema menos costoso.
     Los analistas de sistemas pueden ayudar al entendimiento del sistema global. Los diseñadores de sistemas tienen pleno conocimiento del sistema y este conocimiento es muy importante para no perder ninguna causa que afecte al evento no deseado. Para el evento seleccionado, todas las causas se enumeran y secuencian en el orden de ocurrencia, y luego se usan para el siguiente paso que es dibujar o construir el árbol de fallas.
3. Construir el árbol de fallas
   • Después de seleccionar el evento no deseado y de haber analizado el sistema para que sepamos todos los efectos causantes (y si es posible sus probabilidades) podemos ahora construir el árbol de fallas. El árbol de fallas se basa en las puertas AND y OR que definen las principales características del árbol de fallas.
4. Evaluar el árbol de fallas
   • Después de que el árbol de fallas ha sido ensamblado para un evento no deseado específico, se evalúa y analiza para cualquier posible mejora o en otras palabras, se estudia la gestión de riesgos y se encuentra maneras de mejorar el sistema. Este paso es como una introducción para el paso final que será controlar los peligros identificados. En resumen, en este paso identificamos todos los posibles peligros que afectan de forma directa o indirecta al sistema.
5. Controlar los riesgos identificados
   • Este paso es muy específico y difiere en gran medida de un sistema a otro, pero el punto principal siempre será que después de identificar los peligros se persigan todos los métodos posibles para disminuir la probabilidad de ocurrencia de estos.

Comparación con otros métodos analíticos

El FTA es un método deductivo, descendente, dirigido a analizar los efectos de iniciar fallas y eventos en un sistema complejo. Esto contrasta con el análisis modal de fallos y efectos (FMEA), que es un método inductivo de análisis bottom-up que tiene como objetivo analizar los efectos de fallas de un solo componente o función en equipos o subsistemas. El FTA es muy bueno para mostrar cuán resistente es un sistema a fallas simples o múltiples. No es bueno para encontrar todas las posibles fallas iniciales. El FMEA es bueno en catalogar de forma exhaustiva las fallas iniciales, y en la identificación de sus efectos locales. No es bueno para examinar los fallos múltiples o sus efectos a nivel del sistema. El FTA considera los eventos externos, el FMEA no. En la aeronáutica civil la práctica habitual es realizar tanto FTA y FMEA, con un resumen de efectos de modo de fallo (FMES) como la interfaz entre el FMEA y el FTA.

Las alternativas al FTA incluyen los diagramas de dependencias (DD), también conocidos como diagramas de bloques de fiabilidad (RBD) y el análisis de Markov. Un diagrama de dependencias es equivalente a un análisis de árbol de éxito (en inglés: Success Tree Analysis, STA), el inverso lógico de un FTA, y representa el sistema utilizando rutas en lugar de puertas. DD y STA producen probabilidades de éxito (es decir, evitar un evento superior) en lugar de la probabilidad de un evento superior.

Véase también

• Análisis de causa raíz
• Diagrama de Ishikawa
• Análisis Causa-Efecto
• Análisis modal de fallos y efectos
• Ingeniería de fiabilidad
• Ingeniería de seguridad
• Seguridad de sistemas

Referencias

1. Goldberg, B. E.; Everhart, K.; Stevens, R.; Babbitt, N.; Clemens, P.; Stout, L. (1994). «3». System engineering toolbox for design-oriented engineers (en inglés). Marshall Space Flight Center. pp. 3-35 to 3-48. 
2. Center for Chemical Process Safety (abril de 2008). Guidelines for Hazard Evaluation Procedures (3.ª edición). Wiley. ISBN 978-0-471-97815-2. 
3. Center for Chemical Process Safety (octubre de 1999). Guidelines for Chemical Process Quantitative Risk Analysis (2.ª edición). American Institute of Chemical Engineers. ISBN 978-0-8169-0720-5. 
4. U.S. Department of Labor Occupational Safety and Health Administration (1994). Process Safety Management Guidelines for Compliance. U.S. Government Printing Office. OSHA 3133. 
5. ICH Harmonised Tripartite Guidelines.
6. Lacey, Peter (2011). «An Application of Fault Tree Analysis to the Identification and Management of Risks in Government Funded Human Service Delivery» (PDF). Proceedings of the 2nd International Conference on Public Policy and Social Sciences. Consultado el 9 de septiembre de 2013. 
7. Robles, José. «Encontrar las ubicaciones más cercanas con GKRTree en Swift». Consultado el 20 de diciembre de 2020. 
8. Ericson, Clifton (1999). «Fault Tree Analysis - A History» (PDF). Proceedings of the 17th International Systems Safety Conference. Archivado desde el original el 23 de julio de 2011. Consultado el 17 de enero de 2010. 
9. Rechard, Robert P. (1999). «Historical Relationship Between Performance Assessment for Radioactive Waste Disposal and Other Types of Risk Assessment in the United States» (PDF). Risk Analysis (Springer Netherlands) 19 (5): 763-807. doi:10.1023/A:1007058325258. SAND99-1147J. Consultado el 22 de enero de 2010. 
10. Winter, Mathias (1995). «Software Fault Tree Analysis of an Automated Control System Device Written in ADA» (PDF). Master's Thesis (Monterey, CA: Naval Postgraduate School). ADA303377. Archivado desde el original el 15 de mayo de 2012. Consultado el 17 de enero de 2010. 
11. Benner, Ludwig (1975). «Accident Theory and Accident Investigation». Proceedings of the Society of Air Safety Investigators Annual Seminar. Consultado el 17 de enero de 2010. 
12. Martensen, Anna L.; Butler, Ricky W. «The Fault-Tree Compiler». Langely Research Center. NTRS. Consultado el 17 de junio de 2011. 
13. DeLong, Thomas (1970). «A Fault Tree Manual» (PDF). Master's Thesis (Texas A&M University). AD739001. Archivado desde el original el 4 de marzo de 2016. Consultado el 18 de mayo de 2014. 
14. Eckberg, C. R. (1964). WS-133B Fault Tree Analysis Program Plan (Rev B). Seattle, WA: The Boeing Company. D2-30207-1. Archivado desde el original el 3 de marzo de 2016. Consultado el 18 de mayo de 2014. 
15. Hixenbaugh, A. F. (1968). Fault Tree for Safety. Seattle, WA: The Boeing Company. D6-53604. Archivado desde el original el 3 de marzo de 2016. Consultado el 18 de mayo de 2014. 
16. Larsen, Waldemar (January 1974). Fault Tree Analysis. Picatinny Arsenal. Technical Report 4556. Archivado desde el original el 18 de mayo de 2014. Consultado el 17 de mayo de 2014. 
17. Evans, Ralph A. (5 de enero de 1976). Engineering Design Handbook Design for Reliability. US Army Materiel Command. AMCP-706-196. Archivado desde el original el 18 de mayo de 2014. Consultado el 17 de mayo de 2014. 
18. Begley, T. F.; Cummings (1968). Fault Tree for Safety. RAC. ADD874448. 
19. Anderson, R. T. (March 1976). Reliability Design Handbook. Reliability Analysis Center. RDH 376. Archivado desde el original el 18 de mayo de 2014. Consultado el 17 de mayo de 2014. 
20. Mahar, David J.; James W. Wilbur (1990). Fault Tree Analysis Application Guide. Reliability Analysis Center. 
21. «7.9 Fault Tree Analysis» (PDF). Electronic Reliability Design Handbook. B. U.S. Department of Defense. 1998. MIL–HDBK–338B. Consultado el 17 de enero de 2010. 
22. ASY-300 (26 de junio de 1998). Safety Risk Management. Federal Aviation Administration. 8040.4. 
23. FAA (30 de diciembre de 2000). System Safety Handbook. Federal Aviation Administration. 
24. «Fault Tree Handbook with Aerospace Applications». NASA. August 2002. Archivado desde el original el 15 de agosto de 2015. Consultado el 8 de enero de 2016. 
25. Acharya, Sarbes (1990). Severe Accident Risks: An Assessment for Five U.S. Nuclear Power Plants (PDF). Wasthington, DC: U.S. Nuclear Regulatory Commission. NUREG–1150. Consultado el 17 de enero de 2010. 
26. Vesely, W. E. (1981). Fault Tree Handbook (PDF). Nuclear Regulatory Commission. NUREG–0492. Consultado el 17 de enero de 2010. 
27. Elke, Holly C., Global Application of the Process Safety Management Standard .
28. Vesely, William (2002). Fault Tree Handbook with Aerospace Applications (PDF). National Aeronautics and Space Administration. Archivado desde el original el 15 de agosto de 2015. Consultado el 17 de enero de 2010. 
29. Fault Tree Analysis. Edition 2.0. International Electrotechnical Commission. 2006. ISBN 2-8318-8918-9. IEC 61025.  |fechaacceso= requiere |url= (ayuda)

• Datos: Q428453
• Multimedia: Fault tree diagrams / Q428453