El análisis de modos y efectos de falla ( FMEA ; a menudo escrito con "modos de falla" en plural) es el proceso de revisar tantos componentes, conjuntos y subsistemas como sea posible para identificar posibles modos de falla en un sistema y sus causas y efectos. Para cada componente, los modos de falla y sus efectos resultantes en el resto del sistema se registran en una hoja de trabajo FMEA específica. Existen numerosas variaciones de este tipo de hojas de trabajo. Un AMEF puede ser un análisis cualitativo, [1] pero se puede poner sobre una base cuantitativa cuando los modelos matemáticos de tasa de fallas [2] se combinan con una base de datos estadística de tasas de modos de falla. Fue una de las primeras técnicas sistemáticas y altamente estructuradas para el análisis de fallas . Fue desarrollado por ingenieros de confiabilidad a finales de la década de 1950 para estudiar los problemas que podrían surgir por el mal funcionamiento de los sistemas militares. Un AMEF suele ser el primer paso de un estudio de confiabilidad del sistema.
Existen algunos tipos diferentes de análisis AMEF, como por ejemplo:
A veces, FMEA se extiende a FMECA (modo de falla, efectos y análisis de criticidad) para indicar que también se realiza un análisis de criticidad.
FMEA es un razonamiento inductivo (lógica directa) de análisis de punto único de falla y es una tarea central en ingeniería de confiabilidad , ingeniería de seguridad e ingeniería de calidad .
Una actividad FMEA exitosa ayuda a identificar posibles modos de falla basándose en la experiencia con productos y procesos similares, o en base a la física común de la lógica de falla. Se utiliza ampliamente en las industrias de desarrollo y fabricación en diversas fases del ciclo de vida del producto. El análisis de efectos se refiere al estudio de las consecuencias de esas fallas en diferentes niveles del sistema.
Los análisis funcionales son necesarios como insumo para determinar los modos de falla correctos, en todos los niveles del sistema, tanto para AMEF funcional como AMEF pieza-parte (hardware). Un AMEF se utiliza para estructurar la mitigación de la reducción del riesgo en función del modo de falla o de la reducción de la gravedad del efecto, o en función de la reducción de la probabilidad de falla o ambos. El AMEF es, en principio, un análisis inductivo completo (lógica directa); sin embargo, la probabilidad de falla solo puede estimarse o reducirse comprendiendo el mecanismo de falla . Por lo tanto, el AMEF puede incluir información sobre las causas de la falla (análisis deductivo) para reducir la posibilidad de que ocurra eliminando las causas (raíces) identificadas .
El FME(C)A es una herramienta de diseño utilizada para analizar sistemáticamente fallas de componentes postuladas e identificar los efectos resultantes en las operaciones del sistema. El análisis a veces se caracteriza por consistir en dos subanálisis, siendo el primero el análisis de modos y efectos de falla (FMEA) y el segundo, el análisis de criticidad (CA). [3] El desarrollo exitoso de un AMEF requiere que el analista incluya todos los modos de falla significativos para cada elemento o parte contribuyente en el sistema. Los AMEF se pueden realizar a nivel de sistema, subsistema, conjunto, subconjunto o pieza. El FMECA debe ser un documento vivo durante el desarrollo de un diseño de hardware. Debe programarse y completarse al mismo tiempo que el diseño. Si se completa de manera oportuna, el FMECA puede ayudar a guiar las decisiones de diseño. La utilidad del FMECA como herramienta de diseño y en el proceso de toma de decisiones depende de la efectividad y oportunidad con la que se identifican los problemas de diseño. La puntualidad es probablemente la consideración más importante. En el caso extremo, el FMECA sería de poco valor para el proceso de decisión de diseño si el análisis se realiza después de construir el hardware. Si bien el FMECA identifica todos los modos de falla de las piezas, su beneficio principal es la identificación temprana de todos los modos de falla del sistema o subsistema críticos y catastróficos para que puedan eliminarse o minimizarse mediante la modificación del diseño en el punto más temprano del esfuerzo de desarrollo; por lo tanto, el FMECA debe realizarse a nivel del sistema tan pronto como la información de diseño preliminar esté disponible y extenderse a los niveles inferiores a medida que avanza el diseño detallado.
Observación: Para un modelado de escenarios más completo se puede considerar otro tipo de análisis de confiabilidad, por ejemplo, análisis de árbol de fallas (FTA); un análisis de fallas deductivo (lógica hacia atrás) que puede manejar fallas múltiples dentro del artículo y/o externas al artículo, incluido el mantenimiento y la logística. Comienza en un nivel funcional/de sistema superior. Un FTA puede utilizar los registros AMEF del modo de falla básico o un resumen de efectos como una de sus entradas (los eventos básicos). Se pueden agregar análisis de peligros de interfaz, análisis de errores humanos y otros para completarlos en el modelado de escenarios.
El análisis siempre debe iniciarlo alguien que enumere las funciones que debe cumplir el diseño. Las funciones son el punto de partida de un AMEF bien hecho, y utilizarlas como punto de referencia proporciona el mejor rendimiento de un AMEF. Al fin y al cabo, un diseño es sólo una posible solución para realizar funciones que deben cumplirse. De esta manera, se puede realizar un AMEF tanto en diseños conceptuales como en diseños de detalle, tanto en hardware como en software, y sin importar cuán complejo sea el diseño.
Al realizar un FMECA, primero se considera que el hardware (o software) de interfaz está funcionando dentro de las especificaciones. Después de eso, se puede ampliar utilizando en consecuencia uno de los cinco modos de falla posibles de una función del hardware de interfaz como causa de falla para el elemento de diseño bajo revisión. Esto brinda la oportunidad de hacer que el diseño sea robusto contra fallas funcionales en otras partes del sistema.
Además, cada falla de una pieza postulada se considera la única falla en el sistema (es decir, es un análisis de falla única). Además de los AMEF realizados en sistemas para evaluar el impacto que tienen las fallas de nivel inferior en la operación del sistema, se realizan varios otros AMEF. Se presta especial atención a las interfaces entre sistemas y, de hecho, a todas las interfaces funcionales. El propósito de estos FMEA es garantizar que no se propaguen daños físicos y/o funcionales irreversibles a través de la interfaz como resultado de fallas en una de las unidades de interfaz. Estos análisis se realizan a nivel de pieza para los circuitos que interactúan directamente con las otras unidades. El AMEF se puede lograr sin una CA, pero una CA requiere que el AMEF haya identificado previamente fallas críticas a nivel del sistema. Cuando se realizan ambos pasos, el proceso total se llama FMECA.
Las reglas básicas de cada AMEF incluyen un conjunto de procedimientos seleccionados para el proyecto; los supuestos en los que se basa el análisis; el hardware que ha sido incluido y excluido del análisis y la justificación de las exclusiones. Las reglas básicas también describen el nivel de contrato del análisis (es decir, el nivel en la jerarquía de la parte al subsistema, del subsistema al sistema, etc.), el estado básico del hardware y los criterios para el sistema y la misión. éxito. Se debe hacer todo lo posible para definir todas las reglas básicas antes de que comience el AMEF; sin embargo, las reglas básicas pueden ampliarse y aclararse a medida que avanza el análisis. A continuación se presenta un conjunto típico de reglas básicas (supuestos): [4]
Los principales beneficios derivados de un esfuerzo FMECA implementado adecuadamente son los siguientes:
De la lista anterior, las identificaciones tempranas de SFPS, la entrada al procedimiento de solución de problemas y la localización de dispositivos de monitoreo de desempeño/detección de fallas son probablemente los beneficios más importantes de FMECA. Además, los procedimientos del FMECA son sencillos y permiten una evaluación ordenada del diseño.
Los procedimientos para realizar FMECA se describieron en 1949 en el documento de Procedimientos Militares de las Fuerzas Armadas de EE. UU. MIL-P-1629, [5] revisado en 1980 como MIL-STD-1629A. [6] A principios de la década de 1960, los contratistas de la Administración Nacional de Aeronáutica y del Espacio (NASA) de EE. UU. utilizaban variaciones de FMECA o FMEA bajo una variedad de nombres. [7] [8] Los programas de la NASA que utilizaban variantes de FMEA incluían Apollo , Viking , Voyager , Magellan , Galileo y Skylab . [9] [10] [11] La industria de la aviación civil fue una de las primeras en adoptar FMEA, y la Sociedad de Ingenieros Automotrices (SAE, una organización que cubre la aviación y otros medios de transporte más allá del automóvil, a pesar de su nombre) publicó ARP926 en 1967. [ 12] Después de dos revisiones, la práctica recomendada aeroespacial ARP926 ha sido reemplazada por ARP4761 , que ahora se usa ampliamente en la aviación civil.
Durante la década de 1970, el uso de AMEF y técnicas relacionadas se extendió a otras industrias. En 1971, la NASA preparó un informe para el Servicio Geológico de Estados Unidos recomendando el uso de FMEA en la evaluación de la exploración petrolera en alta mar. [13] Un informe de la Agencia de Protección Ambiental de EE. UU. de 1973 describió la aplicación del FMEA a las plantas de tratamiento de aguas residuales. [14] El FMEA como aplicación del HACCP en el programa espacial Apolo se trasladó a la industria alimentaria en general. [15]
La industria automotriz comenzó a utilizar AMEF a mediados de los años 1970. [16] La Ford Motor Company introdujo el FMEA en la industria automotriz para consideraciones regulatorias y de seguridad después del asunto Pinto . Ford aplicó el mismo enfoque a los procesos (PFMEA) para considerar posibles fallas inducidas por el proceso antes de iniciar la producción. En 1993, el Grupo de Acción de la Industria Automotriz (AIAG) publicó por primera vez un estándar FMEA para la industria automotriz. [17] Se encuentra ahora en su cuarta edición. [18] La SAE publicó por primera vez el estándar relacionado J1739 en 1994. [19] Este estándar también se encuentra ahora en su cuarta edición. [20] En 2019, ambas descripciones de métodos fueron reemplazadas por el nuevo manual AIAG / VDA FMEA. Es una armonización de los antiguos estándares FMEA de AIAG, VDA , SAE y otras descripciones de métodos. [21] [22] [23] A partir de 2024, GM , Ford, Stellantis , Honda NA , BMW , Volkswagen Group , Mercedes-Benz Group AG (anteriormente Daimler AG) y Daimler Truck aceptan el manual AIAG/VDA FMEA. . [24]
Aunque inicialmente fue desarrollada por el ejército, la metodología FMEA ahora se utiliza ampliamente en una variedad de industrias que incluyen procesamiento de semiconductores, servicios de alimentos, plásticos, software y atención médica. [25] Toyota ha llevado esto un paso más allá con su enfoque de revisión de diseño basado en el modo de falla (DRBFM). El método ahora cuenta con el respaldo de la Sociedad Estadounidense para la Calidad , que proporciona guías detalladas sobre cómo aplicar el método. [26] Los procedimientos estándar de análisis de modos y efectos de falla (FMEA) y análisis de modos de falla, efectos y criticidad (FMECA) identifican los mecanismos de falla del producto, pero no pueden modelarlos sin un software especializado. Esto limita su aplicabilidad para proporcionar una aportación significativa a procedimientos críticos como la calificación virtual, el análisis de la causa raíz, los programas de prueba acelerados y la evaluación de la vida restante. Para superar las deficiencias de FMEA y FMECA, a menudo se ha utilizado un análisis de modos, mecanismos y efectos de falla (FMMEA).
Tras el lanzamiento de IATF 16949:2016 , un estándar de calidad internacional que requiere que las empresas tengan un proceso FMEA documentado específico de la organización, muchos fabricantes de equipos originales (OEM) como Ford están actualizando sus Requisitos específicos del cliente (CSR) para incluir el uso de requisitos específicos. Software AMEF. [27] Para Ford específicamente, estos requisitos tenían fechas límite de cumplimiento de múltiples etapas de julio y diciembre de 2022. [28]
A continuación se cubre alguna terminología básica de AMEF. [29]
Es necesario analizar la causa de un modo de falla y la probabilidad de que ocurra. Esto se puede hacer mediante análisis, cálculos/FEM, observando elementos o procesos similares y los modos de falla que se han documentado para ellos en el pasado. La causa de una falla se considera una debilidad del diseño. Se deben identificar y documentar todas las causas potenciales de un modo de falla. Esto debería ser en términos técnicos. Ejemplos de causas son: errores humanos en el manejo, fallas inducidas por la fabricación, fatiga, fluencia, desgaste abrasivo, algoritmos erróneos, voltaje excesivo o condiciones de operación o uso inadecuadas (dependiendo de las reglas básicas utilizadas). A un modo de falla se le puede asignar una clasificación de probabilidad con un número definido de niveles.
Para un AMEF de pieza parcial, la probabilidad cuantitativa se puede calcular a partir de los resultados de un análisis de predicción de confiabilidad y las relaciones de modos de falla de un catálogo de distribución de modos de falla, como RAC FMD-97. [30] Este método permite que un FTA cuantitativo utilice los resultados del FMEA para verificar que los eventos no deseados cumplan con niveles aceptables de riesgo.
Determine la gravedad para el efecto final adverso (estado) del peor de los casos. Es conveniente anotar estos efectos en términos de lo que el usuario podría ver o experimentar en términos de fallas funcionales. Ejemplos de estos efectos finales son: pérdida total de la función x, rendimiento degradado, funciones en modo inverso, funcionamiento demasiado tarde, funcionamiento errático, etc. A cada efecto final se le asigna un número de gravedad (S) de, digamos, I (sin efecto). a V (catastrófico), basado en el costo y/o pérdida de vida o calidad de vida. Estos números priorizan los modos de falla (junto con la probabilidad y la detectabilidad). A continuación se proporciona una clasificación típica. Otras clasificaciones son posibles. Véase también análisis de peligros .
Los medios o métodos mediante los cuales el operador y/o mantenedor detectan una falla, la aíslan y el tiempo que puede tomar. Esto es importante para el control de la mantenibilidad (disponibilidad del sistema) y es especialmente importante para múltiples escenarios de falla. Esto puede implicar modos de falla inactivos (por ejemplo, sin efecto directo en el sistema, mientras que un sistema/elemento redundante toma el control automáticamente o cuando la falla solo es problemática durante una misión específica o estados del sistema) o fallas latentes (por ejemplo, mecanismos de falla por deterioro , como el crecimiento de una grieta en el metal). , pero no de longitud crítica). Debe quedar claro cómo un operador puede descubrir el modo o la causa de la falla bajo la operación normal del sistema o si puede ser descubierto por el equipo de mantenimiento mediante alguna acción de diagnóstico o prueba automática incorporada en el sistema. Se puede introducir un período de inactividad y/o latencia.
Si se conoce, se puede ingresar el tiempo promedio que un modo de falla puede pasar desapercibido. Por ejemplo:
Si la falla no detectada permite que el sistema permanezca en un estado seguro /de funcionamiento, se debe explorar una segunda situación de falla para determinar si una indicación será evidente para todos los operadores y qué acción correctiva pueden o deben tomar.
Las indicaciones para el operador deben describirse de la siguiente manera:
REALIZAR ANÁLISIS DE COBERTURA DE DETECCIÓN PARA PROCESOS DE PRUEBA Y MONITOREO (De Norma ARP4761):
Este tipo de análisis es útil para determinar qué tan efectivos son varios procesos de prueba en la detección de fallas latentes e inactivas. El método utilizado para lograr esto implica un examen de los modos de falla aplicables para determinar si se detectan o no sus efectos, y para determinar el porcentaje de tasa de falla aplicable a los modos de falla que se detectan. La posibilidad de que los medios de detección puedan fallar de manera latente debe tenerse en cuenta en el análisis de cobertura como un factor limitante (es decir, la cobertura no puede ser más confiable que la disponibilidad de los medios de detección). La inclusión de la cobertura de detección en el AMEF puede llevar a que cada falla individual que habría sido una categoría de efecto ahora sea una categoría de efecto separada debido a las posibilidades de cobertura de detección. Otra forma de incluir la cobertura de detección es que la FTA suponga de manera conservadora que ningún agujero en la cobertura debido a una falla latente en el método de detección afecta la detección de todas las fallas asignadas a la categoría de efecto de falla de interés. El AMEF puede revisarse si es necesario para aquellos casos en los que este supuesto conservador no permita que se cumplan los requisitos de probabilidad máxima del evento.
Después de estos tres pasos básicos se podrá proporcionar el nivel de Riesgo.
El riesgo es la combinación de la probabilidad y la gravedad del efecto final, donde la probabilidad y la gravedad incluyen el efecto sobre la no detectabilidad ( tiempo de inactividad ). Esto puede influir en la probabilidad de fallo del efecto final o en el peor de los casos, la gravedad. El cálculo exacto puede no ser fácil en todos los casos, como aquellos en los que son posibles múltiples escenarios (con múltiples eventos) y la detectabilidad/inactividad juega un papel crucial (como en el caso de los sistemas redundantes). En ese caso, es posible que se necesite un análisis de árbol de fallas y/o árboles de eventos para determinar los niveles exactos de probabilidad y riesgo.
Los niveles de riesgo preliminares se pueden seleccionar basándose en una matriz de riesgo como la que se muestra a continuación, basada en Mil. Estándar 882. [31] Cuanto mayor es el nivel de riesgo, más justificación y mitigación se necesitan para proporcionar evidencia y reducir el riesgo a un nivel aceptable. El riesgo alto debe indicarse a la dirección de nivel superior, que es responsable de la toma de decisiones finales.
El AMEF debe actualizarse siempre que:
Si bien el AMEF identifica peligros importantes en un sistema, sus resultados pueden no ser completos y el enfoque tiene limitaciones. [32] [33] [34] En el contexto de la atención sanitaria, se ha descubierto que el FMEA y otros métodos de evaluación de riesgos, incluido SWIFT ( técnica estructurada What If ) y los enfoques retrospectivos, tienen una validez limitada cuando se utilizan de forma aislada. Los desafíos en torno al alcance y los límites organizacionales parecen ser un factor importante en esta falta de validez. [32]
Si se utiliza como herramienta de arriba hacia abajo , el AMEF sólo puede identificar modos de falla importantes en un sistema. El análisis de árbol de fallas (FTA) es más adecuado para el análisis "de arriba hacia abajo". Cuando se utiliza como herramienta ascendente, el AMEF puede aumentar o complementar el FTA e identificar muchas más causas y modos de falla que resulten en síntomas de alto nivel. No es capaz de descubrir modos de falla complejos que impliquen múltiples fallas dentro de un subsistema, ni de informar los intervalos de falla esperados de modos de falla particulares hasta el subsistema o sistema de nivel superior. [ cita necesaria ]
Además, la multiplicación de las clasificaciones de gravedad, ocurrencia y detección puede dar como resultado inversiones de clasificación, donde un modo de falla menos grave recibe un RPN más alto que un modo de falla más grave. [35] La razón de esto es que las clasificaciones son números de escala ordinales y la multiplicación no está definida para números ordinales. Las clasificaciones ordinales sólo dicen que una clasificación es mejor o peor que otra, pero no en cuánto. Por ejemplo, una clasificación de "2" puede no ser dos veces más grave que una clasificación de "1", o un "8" puede no ser dos veces más grave que un "4", pero la multiplicación los trata como si lo fueran. Consulte Nivel de medición para obtener más información. Se han propuesto varias soluciones a este problema, por ejemplo, el uso de lógica difusa como alternativa al modelo RPN clásico. [36] [37] [38] En el nuevo manual AIAG/VDA FMEA (2019) el enfoque RPN fue reemplazado por el AP (prioridad de acción). [39] [40] [23]
La hoja de trabajo AMEF es difícil de producir, de entender y leer, así como de mantener. El uso de técnicas de redes neuronales para agrupar y visualizar modos de falla se sugirió a partir de 2010. [41] [42] [43] Un enfoque alternativo es combinar la tabla FMEA tradicional con un conjunto de diagramas de pajarita. Los diagramas proporcionan una visualización de las cadenas de causa y efecto, mientras que la tabla FMEA proporciona información detallada sobre eventos específicos. [44]