Modo de Fallos y Análisis de Efectos

Análisis de modos de falla y efectos (FMEA; a menudo escrito con "modos de falla" en plural) es el proceso de revisar tantos componentes, ensamblajes 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, pero se puede poner sobre una base cuantitativa cuando se combinan modelos matemáticos de tasa de fallas 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:

• Funcional
• Diseño
• Proceso

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 análisis de punto único de falla de razonamiento inductivo (lógica directa) y es una tarea central en ingeniería de confiabilidad, ingeniería de seguridad e ingeniería de calidad.

Una actividad AMEF 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 entrada para determinar los modos de falla correctos, en todos los niveles del sistema, tanto para FMEA funcional como para FMEA de pieza (hardware). Un AMEF se utiliza para estructurar la mitigación de la reducción del riesgo basándose en la reducción de la gravedad del efecto (modo) de la falla o en la reducción de la probabilidad de falla, o ambas. 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 identificadas (raíz).

Introducción

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). 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 múltiples fallas 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.

Análisis de modos y efectos de fallo funcional

El análisis siempre debe comenzar enumerando las funciones que el diseño debe cumplir. Las funciones son el punto de partida de un AMEF bien hecho, y utilizar funciones 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 para 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.

Reglas básicas

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):

1. Sólo existe un modo de falla en un momento.
2. Todas las entradas (incluyendo comandos de software) al elemento analizado están presentes y a valores nominales.
3. Todos los consumibles están presentes en cantidades suficientes.
4. El poder nominal está disponible

Beneficios

Los principales beneficios derivados de un esfuerzo FMECA implementado correctamente son los siguientes:

1. Proporciona un método documentado para seleccionar un diseño con una alta probabilidad de operación y seguridad exitosas.
2. Un método uniforme documentado para evaluar los posibles mecanismos de falla, los modos de fallo y su impacto en el funcionamiento del sistema, lo que da lugar a una lista de modos de fallos clasificados de acuerdo con la gravedad de su impacto del sistema y la probabilidad de ocurrencia.
3. Identificación temprana de puntos de fallo únicos (SFPS) y problemas de interfaz del sistema, que pueden ser críticos para el éxito de la misión y/o la seguridad. También proporcionan un método de verificación de que la conmutación entre elementos redundantes no se pone en peligro por fallos únicos postulados.
4. Un método eficaz para evaluar el efecto de los cambios propuestos en el diseño y/o los procedimientos operacionales sobre el éxito y la seguridad de las misiones.
5. Una base para los procedimientos de solución de problemas en vuelo y para localizar dispositivos de monitoreo y detección de fallos.
6. Criterios para la planificación temprana de las pruebas.

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 rendimiento/detección de fallas son probablemente los beneficios más importantes de FMECA. Además, los procedimientos FMECA son sencillos y permiten una evaluación ordenada del diseño.

Historia

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, revisado en 1980 como MIL-STD-1629A. 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 con diversos nombres. Los programas de la NASA que utilizaron variantes de FMEA incluyeron Apollo, Viking, Voyager, Magellan, Galileo y Skylab. 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 transportes más allá del automóvil, a pesar de su nombre) publicó ARP926 en 1967. Después de dos revisiones, la Práctica Recomendada Aeroespacial ARP926 ha sido reemplazado 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. Un informe de 1973 de la Agencia de Protección Ambiental de Estados Unidos describió la aplicación del FMEA a las plantas de tratamiento de aguas residuales. El FMEA como aplicación de HACCP en el programa espacial Apollo se trasladó a la industria alimentaria en general.

La industria automotriz comenzó a utilizar FMEA a mediados de la década de 1970. 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. Ya va por su cuarta edición. La SAE publicó por primera vez la norma relacionada J1739 en 1994. Esta norma también se encuentra ahora en su cuarta edición. 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.

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. Toyota ha llevado esto un paso más allá con su revisión de diseño basada en el enfoque del 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. 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).

Términos básicos

A continuación se cubre alguna terminología básica de AMEF.

Prioridad de acción (AP)

El AP reemplaza la matriz de riesgo anterior y RPN en el manual AIAG / VDA FMEA 2019. Hace una declaración sobre la necesidad de nuevas medidas de mejora.

Fallo

The loss of a function under stated conditions.

Modo de falla

La forma o forma específica por la que se produce un fracaso en términos de falla de la parte, componente, función, equipo, subsistema o sistema bajo investigación. Dependiendo del tipo de FMEA realizado, el modo de fallo puede describirse en varios niveles de detalle. Una parte de la pieza FMEA se centrará en modos detallados de parte o componente de falla (como eje totalmente fracturado o eje deformado, o contacto eléctrico atascado abierto, atascado corto o intermitente). Un FMEA funcional se centrará en los modos de fallo funcional. Estos pueden ser generales (como ninguna función, sobre función, bajo función, función intermitente o función no deseada) o más detallada y específica para el equipo que se analiza. Un PFMEA se centrará en los modos de fallo del proceso (como insertar el bit de perforación incorrecto).

Causa y/o mecanismo de falla

Defectos en requisitos, diseño, proceso, control de calidad, manejo o aplicación de parte, que son la causa o secuencia subyacente de causas que inician un proceso (mecanismo) que conduce a un modo de falla en un determinado tiempo. Un modo de fallo puede tener más causas. Por ejemplo: "fatiga o corrosión de un rayo estructural" o "corrosión de frenado en un contacto eléctrico" es un mecanismo de falla y en sí mismo (sólo) no un modo de falla. El modo de falla relacionado (estado final) es una "fracción total del haz estructural" o "un contacto eléctrico abierto". La causa inicial podría haber sido "Improper application of corrosion protection layer (paint)" y /or "(abnormal) entrada de vibración de otro sistema (posiblemente fallido).

Efecto de fracaso

Consecuencias inmediatas de un fallo en operación, o más generalmente sobre las necesidades para el cliente / usuario que debe cumplirse por la función, pero ahora no se cumple o no totalmente.

Niveles de densidad (grandes de degradación material o funcional)

Un identificador para el nivel del sistema y por lo tanto la complejidad de los elementos. La complejidad aumenta a medida que los niveles están más cerca de uno.

Efecto local

El efecto de fallo en la medida en que se aplica al objeto analizado.

Siguiente efecto de nivel superior

El efecto de falla como se aplica en el siguiente nivel de indentadura superior.

Efecto final

El efecto de fallo en el nivel de indentadura más alto o sistema total.

Detección

Los medios de detección del modo de fallo por el encargado, el operador o el sistema integrado de detección, incluido el período estimado de permanencia (si es aplicable).

Probabilidad

La probabilidad de que ocurra el fracaso.

Número de prioridades de riesgo (RPN)

Severidad (del evento) × probabilidad (del evento que ocurre) × detección (probabilidad de que el evento no se detecte antes de que el usuario esté consciente de ello).

Severidad

Las consecuencias de un modo de fracaso. La severidad considera la peor consecuencia potencial de un fracaso, determinado por el grado de lesión, daño de propiedad, daño del sistema y/o tiempo perdido para reparar el fracaso.

Observaciones / mitigación / acciones

Información adicional, incluyendo la mitigación propuesta o las acciones utilizadas para reducir un riesgo o justificar un nivel o escenario de riesgo.

Ejemplo de hoja de trabajo AMEF

Probabilidad (P)

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 un Clasificación de probabilidad con un número definido de niveles.

Para un FMEA de pieza, 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. Este método permite que un FTA cuantitativo utilice los resultados del AMEF para verificar que los eventos no deseados cumplan con niveles aceptables de riesgo.

Severidad (S)

Determine la gravedad del 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.

Detección (D)

El medio o método por el cual se detecta una falla, aislado por el operador y/o mantenedor 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 latente (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, falla por deterioro). mecanismos, como el metal al crecer una grieta, pero no de una longitud crítica). Debe quedar claro cómo un operador puede descubrir el modo o la causa de la falla durante el funcionamiento normal del sistema o si el equipo de mantenimiento puede descubrirlo 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.

Periodo de latencia o latencia

Si se conoce, se puede ingresar el tiempo promedio que un modo de falla puede pasar desapercibido. Por ejemplo:

• Segundos, auto detectado por ordenador de mantenimiento
• 8 horas, detectadas por inspección de vuelta
• 2 meses detectados por bloque de mantenimiento programado X
• 2 años, detectado por tarea de revisión x

Indicación

Si la falla no detectada permite que el sistema permanezca en un estado seguro/en funcionamiento, se debe explorar una segunda situación de falla para determinar si una indicación será evidente para todos los operadores y qué acciones correctivas pueden o deben tomar.

Las indicaciones para el operador deben describirse de la siguiente manera:

• Normal. Una indicación que es evidente para un operador cuando el sistema o el equipo está operando normalmente.
• Anormal. Una indicación que es evidente para un operador cuando el sistema ha funcionado mal o fallado.
• Incorrecto. Una indicación errónea a un operador debido al mal funcionamiento o fracaso de un indicador (es decir, instrumentos, dispositivos de detección, dispositivos de advertencia visuales o audibles, etc.).

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 FMEA puede revisarse si necesario para aquellos casos en los que este supuesto conservador no permite que se cumplan los requisitos de probabilidad de evento máximo.

Después de estos tres pasos básicos se podrá proporcionar el nivel de Riesgo.

Nivel de riesgo (P×S) y (D)

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 latencia). 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 árboles 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. Cuanto mayor sea el nivel de riesgo, más justificación y mitigación se necesitarán 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.

• Después de este paso, el FMEA se ha convertido en una FMECA.

Tiempo

El AMEF debe actualizarse siempre que:

• Empieza un nuevo ciclo (nuevo producto/proceso)
• Cambios en las condiciones de funcionamiento
• Un cambio se hace en el diseño
• Se instituyen nuevas normas
• Los comentarios del cliente indican un problema

Usos

• Desarrollo de los requisitos del sistema que minimizan la probabilidad de fracasos.
• Desarrollo de diseños y sistemas de prueba para asegurar que se hayan eliminado los fallos o que el riesgo se reduzca a un nivel aceptable.
• Desarrollo y evaluación de sistemas de diagnóstico.
• Para ayudar con las opciones de diseño (análisis comercial).

Ventajas

• Catalyst for teamwork and idea exchange between functions
• Recopilar información para reducir fallos futuros, capturar conocimientos de ingeniería
• Identificación temprana y eliminación de posibles modos de fracaso
• Poner énfasis en la prevención del problema
• Fulfill legal requirements (product liability)
• Mejorar la imagen de la empresa y la competitividad
• Mejorar la producción
• Mejorar la calidad, fiabilidad y seguridad de un producto/proceso
• Aumentar la satisfacción del usuario
• Maximizar el beneficio
• Minimizar los cambios tardíos y los costos asociados
• Reducir el impacto en el margen de ganancia de la empresa
• Reducir el tiempo y el costo del desarrollo del sistema
• Reducir la posibilidad de un mismo tipo de fracaso en el futuro
• Reducir el potencial de las preocupaciones de garantía

Limitaciones

Si bien el AMEF identifica peligros importantes en un sistema, sus resultados pueden no ser completos y el enfoque tiene limitaciones. En el contexto de la atención sanitaria, se ha descubierto que el FMEA y otros métodos de evaluación de riesgos, incluido el 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.

Si se utiliza como herramienta de arriba hacia abajo, el FMEA solo puede identificar modos de falla importantes en un sistema. El análisis de árbol de fallas (FTA) es más adecuado para la evaluación "de arriba hacia abajo" análisis. Cuando se utiliza como estrategia "ascendente" La herramienta FMEA 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.

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. La razón de esto es que las clasificaciones son números de escala ordinal 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 una calificación de "8" Puede que no sean dos veces más graves 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. En el nuevo manual AIAG/VDA FMEA (2019) el enfoque RPN fue reemplazado por el AP (prioridad de acción).

La hoja de trabajo AMEF es difícil de producir, de entender y leer, así como de mantener. A partir de 2010 se sugirió el uso de técnicas de redes neuronales para agrupar y visualizar modos de falla. 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.

Tipos

• Funcional: antes de que se proporcionen soluciones de diseño (o sólo en alto nivel) funciones pueden evaluarse sobre posibles efectos de fallo funcional. Se pueden proponer Mitigaciones generales ("diseñadas a" requisitos) para limitar la consecuencia de fallos funcionales o limitar la probabilidad de ocurrencia en este desarrollo temprano. Se basa en un colapso funcional de un sistema. Este tipo también se puede utilizar para la evaluación del software.
• Diseño de conceptos / hardware: análisis de sistemas o subsistemas en las etapas de concepto de diseño temprano para analizar los mecanismos de falla y fallas funcionales de menor nivel, especialmente para diferentes soluciones de concepto con más detalle. Puede utilizarse en estudios de compensación comercial.
• Diseño detallado / hardware: análisis de productos antes de la producción. Estos son los FMEAs más detallados (en MIL 1629 llamados Piece-Part o Hardware FMEA) y utilizados para identificar cualquier posible modo de falla hardware (o de otro) hasta el nivel de parte más bajo. Debe basarse en el desglose de hardware (por ejemplo, BoM = factura de materiales). Cualquier efecto de fallo severidad, prevención de fallos (mitigación), detección de fallos y diagnóstico puede ser analizado por completo en este FMEA.
• Proceso: análisis de procesos de fabricación y montaje. Tanto la calidad como la fiabilidad pueden verse afectadas por fallos de proceso. La entrada para este FMEA es entre otros un proceso de trabajo / desglose de tareas.