Hispanopedia Wiki
Articulo de referencia

Análisis de modos y efectos de falla

Gráfico con un ejemplo de los pasos en un análisis de modos y efectos de falla. El análisis de modos y efectos de falla ( FMEA ; a menudo escrito con "modos de falla" en plural)...

Hispanopedia WikiContenido en espanolLectura gratuita
Gráfico con un ejemplo de los pasos en un análisis de modos y efectos de falla.

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, 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 dichas hojas de trabajo. Un FMEA puede ser un análisis cualitativo, [ 1 ] pero puede basarse en un enfoque semicuantitativo con un modelo RPN (Número de Prioridad de Riesgo). Los métodos relacionados combinan modelos matemáticos de tasa de falla con bases de datos estadísticas de relación de modos de falla. Fue una de las primeras técnicas altamente estructuradas y sistemáticas para el análisis de fallas . [ 2 ] Fue desarrollada por ingenieros de confiabilidad [ 3 ] a finales de la década de 1950 para estudiar los problemas que podrían surgir de las fallas de los sistemas militares. Un FMEA suele ser el primer paso de un estudio de confiabilidad del sistema.

Existen diferentes tipos de análisis FMEA, como por ejemplo:

  • Funcional
  • Diseño
  • Proceso
  • Software

A veces, el FMEA se extiende al FMECA [ 4 ] (análisis de modos de falla, efectos y criticidad) con números de prioridad de riesgo (RPN) para indicar la criticidad.

El FMEA es un análisis de punto único de fallo basado en el razonamiento inductivo (lógica directa) y es una tarea fundamental en la ingeniería de fiabilidad , la ingeniería de seguridad y la ingeniería de calidad .

Un análisis FMEA exitoso ayuda a identificar posibles modos de falla basándose en la experiencia con productos y procesos similares, o en la lógica física común de las fallas. 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 el AMFE funcional como para el AMFE de componentes (hardware). El AMFE se utiliza para estructurar medidas de mitigación que permitan reducir el riesgo, ya sea disminuyendo la gravedad del modo o efecto de falla, o reduciendo la probabilidad de falla, o ambas cosas.

El FMEA 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 FMEA puede incluir información sobre las causas de la falla (análisis deductivo) para reducir la posibilidad de ocurrencia eliminando las causas identificadas (causas raíz) .

Introducción

El FME(C)A es una herramienta de diseño que se utiliza para analizar sistemáticamente las fallas hipotéticas de los componentes e identificar los efectos resultantes en el funcionamiento del sistema. El análisis se caracteriza a veces por constar de dos subanálisis: el primero, el análisis de modos y efectos de falla (FMEA), y el segundo, el análisis de criticidad (CA). [ 5 ] El desarrollo exitoso de un FMEA requiere que el analista incluya todos los modos de falla significativos para cada elemento o parte del sistema. Los FMEA se pueden realizar a nivel de sistema, subsistema, ensamblaje, subensamblaje o parte.

El FMECA debe ser un documento vivo durante el desarrollo de un diseño de hardware. Debe programarse y completarse simultáneamente con el diseño. Si se completa a tiempo, 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 eficacia y la puntualidad con que se identifiquen los problemas de diseño. La puntualidad es probablemente la consideración más importante. En el caso extremo, el FMECA tendría poco valor para el proceso de decisión de diseño si el análisis se realiza después de que el hardware esté construido. Si bien el FMECA identifica todos los modos de falla de las piezas, su principal beneficio es la identificación temprana de todos los modos de falla críticos y catastróficos del subsistema o del sistema para que puedan eliminarse o minimizarse mediante la modificación del diseño en la etapa más temprana del esfuerzo de desarrollo; por lo tanto, el FMECA debe realizarse a nivel de sistema tan pronto como se disponga de información de diseño preliminar y extenderse a los niveles inferiores a medida que avanza el diseño detallado.

Nota: Para un modelado de escenarios más completo, se puede considerar otro tipo de análisis de confiabilidad, por ejemplo, el análisis de árbol de fallas (FTA); un análisis de fallas deductivo (lógica inversa) que puede manejar múltiples fallas dentro del elemento y/o externas al mismo, incluyendo mantenimiento y logística. Comienza en un nivel funcional/de sistema superior. Un FTA puede usar los registros AMFE de 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 riesgos de interfaz, análisis de errores humanos y otros para completar el modelado de escenarios.

Análisis de modos y efectos de fallas funcionales

El análisis siempre debe comenzar con alguien que enumere las funciones que el diseño debe cumplir. Las funciones son el punto de partida de un FMEA bien realizado, y utilizarlas como base proporciona el mejor resultado. Al fin y al cabo, un diseño es solo una posible solución para realizar las funciones que deben cumplirse. De esta manera, un FMEA puede aplicarse tanto a diseños conceptuales como a diseños detallados, tanto a hardware como a software, y sin importar la complejidad del diseño.

Al realizar un análisis FMECA, primero se considera que el hardware (o software) de interfaz funciona dentro de las especificaciones. Posteriormente, se puede ampliar el análisis utilizando uno de los cinco posibles modos de fallo de una función del hardware de interfaz como causa de fallo para el elemento de diseño bajo revisión. Esto permite que el diseño sea robusto frente a fallos funcionales en otras partes del sistema.

Además, cada fallo de componente postulado se considera el único fallo del sistema (es decir, se trata de un análisis de fallo único). Además de los FMEA realizados en sistemas para evaluar el impacto de los fallos de nivel inferior en el funcionamiento del sistema, se realizan otros FMEA. Se presta especial atención a las interfaces entre sistemas y, de hecho, a todas las interfaces funcionales. El objetivo de estos FMEA es asegurar que no se propague daño físico o funcional irreversible a través de la interfaz como resultado de fallos en una de las unidades de interfaz. Estos análisis se realizan a nivel de componente para los circuitos que interactúan directamente con las demás unidades. El FMEA puede realizarse sin un CA, pero un CA requiere que el FMEA haya identificado previamente fallos críticos a nivel de sistema. Cuando se realizan ambos pasos, el proceso total se denomina FMECA.

Reglas básicas

Las reglas básicas de cada FMEA incluyen un conjunto de procedimientos seleccionados del proyecto; los supuestos en los que se basa el análisis; el hardware que se ha incluido y excluido del análisis; y la justificación de las exclusiones. Las reglas básicas también describen el nivel de dependencia del análisis (es decir, el nivel en la jerarquía de la pieza al subsistema, del subsistema al sistema, etc.), el estado básico del hardware y los criterios de éxito del sistema y de la misión. Se debe hacer todo lo posible por definir todas las reglas básicas antes de que comience el FMEA; sin embargo, las reglas básicas pueden ampliarse y aclararse a medida que avanza el análisis. A continuación se muestra un conjunto típico de reglas básicas (supuestos): [ 6 ]

  1. Solo existe un modo de fallo a la vez.
  2. Todos los datos de entrada (incluidos los comandos de software) del elemento que se está analizando están presentes y en valores nominales.
  3. Todos los consumibles están presentes en cantidades suficientes.
  4. Se dispone de potencia nominal.

Beneficios

Los principales beneficios derivados de un análisis FMECA implementado correctamente son los siguientes:

  1. Un método documentado para seleccionar un diseño con alta probabilidad de éxito en su funcionamiento y con total seguridad.
  2. Un método uniforme y documentado para evaluar los posibles mecanismos de fallo, los modos de fallo y su impacto en el funcionamiento del sistema, que da como resultado una lista de modos de fallo clasificados según la gravedad de su impacto en el sistema y la probabilidad de que ocurran.
  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 o la seguridad. También proporcionan un método para verificar que la conmutación entre elementos redundantes no se vea comprometida por posibles fallos únicos.
  4. Un método eficaz para evaluar el efecto de los cambios propuestos en el diseño y/o los procedimientos operativos sobre el éxito y la seguridad de la misión.
  5. Una base para los procedimientos de resolución de problemas en vuelo y para la localización de dispositivos de monitorización del rendimiento y detección de fallos.
  6. Criterios para la planificación temprana de las pruebas.

De la lista anterior, la identificación temprana de SFPS, la información para el procedimiento de resolución de problemas y la localización de dispositivos de monitoreo de rendimiento/detección de fallas son probablemente los beneficios más importantes del FMECA. Además, los procedimientos del 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, [ 7 ] revisado en 1980 como MIL-STD-1629A. [ 8 ] A principios de la década de 1960, los contratistas de la Administración Nacional de Aeronáutica y del Espacio de EE. UU. (NASA) estaban utilizando variaciones de FMECA o FMEA bajo una variedad de nombres. [ 9 ] [ 10 ] Los programas de la NASA que utilizaron variantes de FMEA incluyeron Apollo , Viking , Voyager , Magellan , Galileo y Skylab . [ 11 ] [ 12 ] [ 13 ] La industria de la aviación civil fue una de las primeras en adoptar el FMEA, y la Sociedad de Ingenieros Automotrices (SAE, una organización que abarca la aviación y otros medios de transporte más allá del sector automotriz, a pesar de su nombre) publicó la ARP926 en 1967. [ 14 ] Después de dos revisiones, la Práctica Recomendada Aeroespacial ARP926 ha sido reemplazada por la ARP4761 , que ahora se utiliza ampliamente en la aviación civil.

Durante la década de 1970, el uso del FMEA y técnicas relacionadas se extendió a otras industrias. En 1971, la NASA preparó un informe para el Servicio Geológico de los Estados Unidos recomendando el uso del FMEA en la evaluación de la exploración petrolera en alta mar. [ 15 ] Un informe de la Agencia de Protección Ambiental de los Estados Unidos de 1973 describió la aplicación del FMEA a las plantas de tratamiento de aguas residuales. [ 16 ] El FMEA, como aplicación del HACCP en el Programa Espacial Apolo, se extendió a la industria alimentaria en general. [ 17 ]

La industria automotriz comenzó a utilizar FMEA a mediados de la década de 1970. [ 18 ] Ford Motor Company introdujo FMEA en la industria automotriz para consideraciones de seguridad y regulación después del caso Pinto . Ford aplicó el mismo enfoque a los procesos (PFMEA) para considerar posibles fallas inducidas por el proceso antes de lanzar la producción. En 1993, el Automotive Industry Action Group (AIAG) publicó por primera vez un estándar FMEA para la industria automotriz. [ 19 ] Ahora está en su cuarta edición. [ 20 ] La SAE publicó por primera vez el estándar relacionado J1739 en 1994. [ 21 ] Este estándar también está ahora en su cuarta edición. [ 22 ] En 2019, ambas descripciones de métodos fueron reemplazadas por el nuevo manual FMEA de AIAG/VDA. Es una armonización de los estándares FMEA anteriores de AIAG, VDA , SAE y otras descripciones de métodos. [ 23 ] [ 24 ] [ 25 ] A partir de 2024, el Manual AIAG/VDA FMEA es aceptado por GM , Ford, Stellantis , Honda NA , BMW , Volkswagen Group , Mercedes-Benz Group AG (anteriormente Daimler AG) y Daimler Truck . [ 26 ]

Aunque inicialmente desarrollada por el ejército, la metodología FMEA ahora se utiliza ampliamente en una variedad de industrias, incluyendo el procesamiento de semiconductores, el servicio de alimentos, los plásticos, el software y la atención médica. [ 27 ] Toyota ha ido un paso más allá con su enfoque de revisión de diseño basado en modos de falla (DRBFM). El método ahora está respaldado por la Sociedad Estadounidense para la Calidad, que proporciona guías detalladas sobre cómo aplicar el método. [ 28 ] Los procedimientos estándar de análisis de modos y efectos de falla (FMEA) y análisis de modos, efectos y criticidad de falla (FMECA) identifican los mecanismos de falla del producto, pero pueden no modelarlos sin software especializado. Esto limita su aplicabilidad para proporcionar una entrada significativa a procedimientos críticos como la calificación virtual, el análisis de causa raíz, los programas de prueba acelerada y la evaluación de la vida útil restante. Para superar las deficiencias de FMEA y FMECA, se ha utilizado con frecuencia un análisis de modos, mecanismos y efectos de falla (FMMEA).

Una variante del FMEA desarrollada para aplicaciones de seguridad funcional se denomina Análisis de Desviación y Mitigación del Diseño (DDMA).[5] La variante DDMA añade información que normalmente no se incluye en un FMEA, como las mitigaciones de diagnóstico automático, las pruebas de fallos latentes y la vida útil. El DDMA elimina los números RPN, ya que se reemplazan por los resultados del FMEA . [ 29 ]

Tras la publicación de IATF 16949 :2016, una norma internacional de calidad que exige a las empresas contar con un proceso FMEA documentado y específico para cada 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 software FMEA específico. [ 30 ] En el caso específico de Ford, estos requisitos tenían plazos de cumplimiento en varias etapas, concretamente en julio y diciembre de 2022. [ 31 ]

Términos básicos

A continuación se presentan algunos términos básicos de FMEA. [ 32 ]

Prioridad de acción (PA)
El AP sustituye a la matriz de riesgos y al RPN anteriores en el manual AMFE AIAG/VDA 2019. En él se destaca la necesidad de medidas de mejora adicionales.
Falla
La pérdida de una función bajo las condiciones establecidas.
Modo de fallo
La forma específica en que se produce una falla en términos de falla de la pieza, componente, función, equipo, subsistema o sistema bajo investigación. Dependiendo del tipo de FMEA realizado, el modo de falla puede describirse con varios niveles de detalle. Un FMEA de pieza se centrará en modos de falla detallados de la pieza o componente (como eje completamente fracturado o deformado, o contacto eléctrico atascado abierto, atascado en cortocircuito o intermitente). Un FMEA funcional se centrará en modos de falla funcionales. Estos pueden ser generales (como ausencia de función, sobrefuncionamiento, subfuncionamiento, funcionamiento intermitente o funcionamiento no deseado) o más detallados y específicos del equipo que se está analizando. Un PFMEA se centrará en modos de falla de proceso (como insertar la broca incorrecta).
Causa y/o mecanismo de la falla
Defectos en los requisitos, el diseño, el proceso, el control de calidad, la manipulación o la aplicación de las piezas, que constituyen la causa subyacente o la secuencia de causas que inician un proceso (mecanismo) que conduce a un modo de fallo en un tiempo determinado. Un modo de fallo puede tener varias causas. Por ejemplo, la fatiga o corrosión de una viga estructural o la corrosión por frotamiento en un contacto eléctrico constituyen un mecanismo de fallo y, en sí mismas, probablemente no un modo de fallo. El modo de fallo correspondiente (estado final) es la fractura total de la viga estructural o un contacto eléctrico abierto. La causa inicial podría haber sido la aplicación incorrecta de la capa de protección anticorrosión (pintura) o la entrada de vibraciones (anormales) procedentes de otro sistema (posiblemente averiado).
Efecto de falla
Consecuencias inmediatas de un fallo en el funcionamiento o, más generalmente, en las necesidades del cliente/usuario que deberían ser satisfechas por la función, pero que ahora no lo son, o no lo son completamente.
Niveles de contrato (lista de materiales o desglose funcional)
Un identificador para el nivel del sistema y, por lo tanto, para la complejidad del elemento. La complejidad aumenta a medida que los niveles se acercan a uno.
Efecto local
El efecto de la falla en lo que respecta al elemento analizado.
Efecto de nivel superior siguiente
El efecto de la falla tal como se aplica en el siguiente nivel superior de la escisión.
Efecto final
El efecto de falla en el nivel más alto de la escisión o en el sistema total.
Detección
Los medios de detección del modo de fallo por parte del mantenedor, el operador o el sistema de detección incorporado, incluido el período de inactividad estimado (si procede).
Probabilidad
La probabilidad de que ocurra el fallo.
Número de prioridad de riesgo (NPR)
Gravedad (del evento) × probabilidad (de que ocurra el evento) × detección (probabilidad de que el evento no se detecte antes de que el usuario se dé cuenta de él).
Gravedad
Las consecuencias de un modo de falla. La gravedad considera la peor consecuencia potencial de una falla, determinada por el grado de daño, daño a la propiedad, daño al sistema y/o tiempo perdido para reparar la falla.
Observaciones / mitigación / acciones
Información adicional, incluyendo las medidas de mitigación propuestas o las acciones utilizadas para reducir un riesgo o justificar un nivel o escenario de riesgo.

Ejemplo de hoja de trabajo FMEA

Probabilidad (P)

Fuente: [ 34 ]

Es necesario analizar la causa de un modo de fallo y la probabilidad de que ocurra. Esto se puede hacer mediante análisis, cálculos/FEM, y examinando elementos o procesos similares y los modos de fallo que se han documentado para ellos en el pasado. Una causa de fallo se considera una debilidad de diseño. Todas las causas potenciales de un modo de fallo deben identificarse y documentarse en términos técnicos. Ejemplos de causas son: errores humanos en la manipulación, fallos inducidos por la fabricación, fatiga, fluencia, desgaste abrasivo, algoritmos erróneos, voltaje excesivo o condiciones de funcionamiento o uso inadecuados (según las reglas básicas utilizadas). A un modo de fallo se le puede asignar una clasificación de probabilidad con un número definido de niveles. Este campo también se conoce a menudo como índice de ocurrencia . [ 28 ]

Para un FMEA de una pieza, la probabilidad cuantitativa se puede calcular a partir de los resultados de un análisis de predicción de confiabilidad y las razones de modos de falla de un catálogo de distribución de modos de falla, como RAC FMD-97. [ 35 ] Este método permite que un FTA cuantitativo utilice los resultados del FMEA para verificar que los eventos no deseados cumplan con niveles de riesgo aceptables.

Gravedad (G)

Fuente: [ 36 ]

Determinar la gravedad del efecto final adverso (estado) en el peor de los casos. Es conveniente escribir 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 invertido, funcionamiento demasiado tardío, funcionamiento errático, etc. A cada efecto final se le asigna un número de gravedad (S) desde, por ejemplo, I (sin efecto) hasta V (catastrófico), en función del costo y/o la pérdida de vidas o calidad de vida. Estos números priorizan los modos de falla (junto con la probabilidad y la detectabilidad). A continuación se presenta una clasificación típica. Son posibles otras clasificaciones. Véase también análisis de riesgos .

Detección (D)

Fuente: [ 37 ]

El método o la forma en que se detecta y aísla una falla por parte del operador y/o el personal de mantenimiento, y el tiempo que puede tomar. Esto es importante para el control de la mantenibilidad (disponibilidad del sistema) y es especialmente importante para escenarios de fallas múltiples. Esto puede incluir modos de falla latentes (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 estados específicos de la misión o del sistema) o fallas latentes (por ejemplo, mecanismos de falla por deterioro , como el crecimiento de una grieta en el metal, pero sin 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 descubrirla mediante alguna acción de diagnóstico o prueba automática integrada del sistema. Puede entrar en un período de latencia.

Período de inactividad o latencia

Se puede introducir el tiempo promedio durante el cual un modo de fallo puede permanecer sin ser detectado, si se conoce. Por ejemplo:

  • Segundos, detectado automáticamente por el ordenador de mantenimiento
  • 8 horas, detectado mediante inspección de retorno
  • 2 meses, detectado por el bloque de mantenimiento programado X
  • 2 años, detectado por la tarea de revisión x

Indicación

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

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

  • Normal. Indicación evidente para el operador de que el sistema o equipo funciona con normalidad.
  • Anormal. Indicación evidente para el operador cuando el sistema ha fallado o ha sufrido un mal funcionamiento.
  • Incorrecto. Una indicación errónea a un operador debido al mal funcionamiento o falla 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 (Según la norma ARP4761):

Este tipo de análisis es útil para determinar la eficacia de diversos procesos de prueba en la detección de fallos latentes e inactivos. El método empleado implica examinar los modos de fallo aplicables para determinar si se detectan sus efectos y el porcentaje de la tasa de fallos correspondiente a los modos detectados. La posibilidad de que el propio medio de detección falle de forma latente debe considerarse en el análisis de cobertura como un factor limitante (es decir, la cobertura no puede ser más fiable que la disponibilidad del medio de detección). La inclusión de la cobertura de detección en el FMEA puede dar lugar a que cada fallo individual, que habría pertenecido a una categoría de efecto, se convierta ahora en una categoría de efecto independiente debido a las posibilidades de cobertura de detección. Otra forma de incluir la cobertura de detección es que el FTA asuma, de forma conservadora, que ninguna brecha en la cobertura debida a fallos latentes en el método de detección afecta a la detección de todos los fallos asignados a la categoría de efecto de fallo de interés. El FMEA puede revisarse, si es necesario, en los casos en que esta suposición conservadora no permita cumplir con los requisitos de probabilidad del evento principal.

Tras estos tres pasos básicos, se podrá determinar el nivel de riesgo.

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

Fuente: [ 38 ]

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 indetectabilidad ( tiempo de latencia ). Esto puede influir en la probabilidad de fallo del efecto final o en la gravedad del efecto en el peor de los casos. El cálculo exacto puede no ser sencillo en todos los casos, como en aquellos donde son posibles múltiples escenarios (con múltiples eventos) y la detectabilidad/latencia desempeña un papel crucial (como en los sistemas redundantes). En ese caso, puede ser necesario el análisis de árboles de fallos y/o árboles de eventos para determinar los niveles exactos de probabilidad y riesgo.

Los niveles de riesgo preliminares pueden seleccionarse con base en una matriz de riesgo como la que se muestra a continuación, según la norma militar 882. [ 39 ] Cuanto mayor sea el nivel de riesgo, mayor será la justificación y mitigación necesarias para aportar evidencia y reducir el riesgo a un nivel aceptable. El alto riesgo debe comunicarse a la alta dirección, responsable de la toma de decisiones final.

  • Después de este paso, el FMEA se ha convertido en algo parecido a un FMECA .

Técnica de FMEA de diseño mejorada (DDMA)

Se ha introducido una nueva variante del FMEA: el Análisis de Desviación y Mitigación del Diseño (DDMA) . Este método adapta los requisitos de seguridad funcional al proceso FMEA de diseño. Esta técnica permite la recopilación simultánea de información FMEA, aprovechando los conocimientos de ingeniería de seguridad funcional para optimizar el FMEA.

El proceso de seguridad funcional reemplaza en gran medida la necesidad de los Números de Prioridad de Riesgo (NPR) tradicionales. La gravedad se sustituye por una clasificación más precisa de los modos de fallo de nivel final (seguro, peligroso, anunciación o sin efecto), mientras que la probabilidad y la detección se reemplazan por métricas cuantitativas del FMEDA, que proporciona un análisis mucho más preciso de los fallos de los componentes de hardware y su impacto. Para facilitar la configuración del FMEDA, el proceso DDMA también incorpora descripciones de diagnósticos automáticos (acción realizada, cobertura) y evalúa la eficacia de las pruebas de fallos latentes. [ 40 ]

Momento

Se debe utilizar el FMEA:

  • Cuando se está diseñando (o rediseñando) un producto o proceso
  • Cuando un producto o proceso existente se aplica de una manera novedosa.
  • Antes de desarrollar planes o procedimientos de control para un proceso nuevo o rediseñado
  • Al intentar mejorar un producto, proceso o servicio existente
  • Al analizar fallos en un producto, proceso o servicio existente
  • Periódicamente y de forma regular durante toda la vida útil del producto, proceso o servicio [ 28 ].

El FMEA debe actualizarse siempre que:

  • Comienza un nuevo ciclo (nuevo producto/proceso).
  • Se realizan cambios en las condiciones de funcionamiento.
  • Se realiza un cambio en el diseño.
  • Se implementan nuevas regulaciones
  • Los comentarios de los clientes indican un problema.

Usos

  • Desarrollo de requisitos del sistema que minimicen la probabilidad de fallos.
  • Desarrollo de diseños y sistemas de prueba para garantizar que se hayan eliminado las fallas o que el riesgo se haya reducido a un nivel aceptable.
  • Desarrollo y evaluación de sistemas de diagnóstico
  • Para ayudar en la toma de decisiones de diseño (análisis de compensaciones)

Ventajas

  • Catalizador para el trabajo en equipo y el intercambio de ideas entre funciones.
  • Recopilar información para reducir fallos futuros y capturar conocimientos de ingeniería.
  • Identificación temprana y eliminación de posibles modos de falla
  • Hacer hincapié en la prevención de problemas
  • Cumplir con los requisitos legales (responsabilidad del producto)
  • Mejorar la imagen y la competitividad de la empresa.
  • Mejorar el rendimiento de la producción
  • Mejorar la calidad, la fiabilidad y la seguridad de un producto/proceso.
  • Aumentar la satisfacción del usuario
  • Maximizar las ganancias
  • Minimizar los cambios de última hora y los costes asociados.
  • Reducir el impacto en el margen de beneficio de la empresa.
  • Reduzca el tiempo y el costo de desarrollo del sistema.
  • Reducir la posibilidad de que se produzca el mismo tipo de fallo en el futuro.
  • Reduzca la posibilidad de problemas con la garantía.

Limitaciones

Si bien el FMEA identifica peligros importantes en un sistema, sus resultados pueden no ser exhaustivos y el enfoque tiene limitaciones. [ 41 ] [ 42 ] [ 43 ] En el contexto de la atención médica, se ha encontrado que el FMEA y otros métodos de evaluación de riesgos, incluidos SWIFT ( Técnica Estructurada de Análisis de Situaciones ) y los enfoques retrospectivos, tienen una validez limitada cuando se usan de forma aislada. Los desafíos relacionados con el alcance y los límites organizativos parecen ser un factor importante en esta falta de validez. [ 41 ]

Si se utiliza como herramienta descendente , el FMEA solo puede identificar los principales modos de fallo en un sistema. El análisis de árbol de fallos (FTA) es más adecuado para el análisis descendente. Cuando se utiliza como herramienta ascendente , el FMEA puede complementar el FTA e identificar muchas más causas y modos de fallo que dan lugar a síntomas de nivel superior. No es capaz de descubrir modos de fallo complejos que involucren múltiples fallos dentro de un subsistema, ni de informar sobre los intervalos de fallo previstos para modos de fallo específicos hasta el subsistema o sistema de nivel superior.

Además, la multiplicación de las clasificaciones de gravedad, ocurrencia y detección puede resultar en inversiones de rango, donde un modo de falla menos grave recibe un RPN más alto que un modo de falla más grave. [ 44 ] 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 solo dicen que una clasificación es mejor o peor que otra, pero no por cuánto. Por ejemplo, una clasificación de "2" puede no ser el doble de grave que una clasificación de "1", o un "8" puede no ser el doble de grave que un "4", pero la multiplicación los trata como si lo fueran. Consulte Nivel de medición para una discusión más detallada. Se han propuesto varias soluciones a este problema, por ejemplo, el uso de lógica difusa como alternativa al modelo RPN clásico. [ 45 ] [ 46 ] [ 47 ] [ 48 ] En el nuevo manual AMFE AIAG/VDA (2019), el enfoque RPN fue reemplazado por AP (prioridad de acción) en el método AMFE suplementario para monitoreo y respuesta del sistema (AMFE-MSR). [ 49 ] [ 50 ] [ 25 ]

La hoja de trabajo FMEA es difícil de producir, difícil de entender y leer, así como difícil de mantener. El uso de técnicas de redes neuronales para agrupar y visualizar los modos de falla se sugirió a partir de 2010. [ 51 ] [ 52 ] [ 53 ] Un enfoque alternativo es combinar la tabla FMEA tradicional con un conjunto de diagramas de corbata de lazo . Los diagramas proporcionan una visualización de las cadenas de causa y efecto, mientras que la tabla FMEA proporciona la información detallada sobre eventos específicos. [ 54 ]

Tipos

  • Funcional : antes de que se proporcionen soluciones de diseño (o solo a un nivel general), se pueden evaluar las funciones en función de los posibles efectos de fallos funcionales. Se pueden proponer medidas de mitigación generales (diseño conforme a los requisitos) para limitar las consecuencias de los fallos funcionales o reducir la probabilidad de que ocurran en esta fase inicial del desarrollo. Se basa en un análisis de la funcionalidad del sistema. Este tipo de análisis también puede utilizarse para la evaluación de software.
  • Diseño conceptual / hardware : análisis de sistemas o subsistemas en las primeras etapas del diseño conceptual para analizar los mecanismos de falla y las fallas funcionales de bajo nivel, especialmente comparando diferentes soluciones conceptuales con mayor detalle. Puede utilizarse en estudios de compensación.
  • Diseño detallado / Hardware : análisis de productos previo a la producción. Estos son los FMEA más detallados (en MIL 1629 denominados FMEA de piezas o de hardware) y se utilizan para identificar cualquier posible modo de fallo del hardware (u otro) hasta el nivel de componente más bajo. Debe basarse en el desglose del hardware (por ejemplo, la lista de materiales). En este FMEA se puede analizar exhaustivamente la gravedad de cualquier efecto de fallo, su prevención (mitigación), su detección y su diagnóstico.
  • Proceso : análisis de los procesos de fabricación y ensamblaje. Tanto la calidad como la fiabilidad pueden verse afectadas por fallos en el proceso. La información de entrada para este AMFE incluye, entre otros datos, un desglose de procesos/tareas.

Análisis de modos y efectos de fallos (FMEA) del software

Fuente: [ 55 ]

El FMEA de software se centra en los modos de fallo que se originan en los requisitos, el diseño, el código o las interfaces del software. En este análisis, el software no debe tratarse como una "caja negra". En su lugar, se debe considerar una lista de las causas raíz que históricamente han provocado fallos de software. La Enumeración de Defectos Comunes (CDE) [ 56 ] es el método preferido para el FMEA de software, ya que incluye una lista de causas raíz de fallos de software, como funcionalidad defectuosa, manejo de errores defectuoso, gestión de estado defectuosa, sincronización defectuosa, secuenciación defectuosa, procesamiento defectuoso, usabilidad defectuosa, aprendizaje automático defectuoso, etc. El FMEA de software es un FMEA de diseño, ya que su objetivo es identificar especificaciones de diseño faltantes, insuficientes o incorrectas antes de escribir el código.

La probabilidad de un fallo de software se evalúa de la siguiente manera:

  • Existencia: ¿Son las especificaciones/el diseño/el código claramente insuficientes o incorrectos?
  • Manifestación: ¿El evento es un fallo de punto único o de múltiples puntos? ¿Cuántos sitios instalados tendrán la función con el modo de fallo?
  • Controles: ¿Cuántos controles independientes para este modo de fallo existen actualmente en el diseño?
  • Detectabilidad: ¿Existe un procedimiento de prueba explícito para este modo de fallo?

La probabilidad NO se calcula a partir de las tasas de fallos de software, simplemente porque estas miden el tiempo transcurrido entre fallos de software de CADA causa raíz, en lugar del tiempo transcurrido entre un fallo debido a una única causa raíz. Además, en el caso de los fallos de software, las causas raíz se corregirán o evitarán cuando se produzca el fallo. Por lo tanto, el tiempo transcurrido entre una causa raíz específica tiene un valor mínimo.

La gravedad debe tener en cuenta que el software puede fallar de forma diferente al hardware:

  1. Los fallos de software con la misma causa raíz pueden repetirse en un corto período de tiempo. Esto no ocurre con el hardware.
  2. Las fallas de gravedad media que se repiten pueden provocar una falla muy grave del sistema. Por lo tanto, el analista debe tener esto en cuenta al evaluar la gravedad.
  3. Los fallos de software no se limitan a la pérdida total de funcionalidad. Según la norma IEEE 1633, si el software realiza una función que no cumple con los requisitos, se considera un fallo.
  4. Las medidas compensatorias no necesariamente mitigan la gravedad de un fallo de software. Esto se debe a que muchos fallos de software ocurren sin previo aviso y muchos causan daños antes de que un operador pueda intervenir.

Véase también

Referencias

  1. ↑ Rausand, Marvin; Høyland, Arnljot (2004). Teoría de la fiabilidad de sistemas: modelos, métodos estadísticos y aplicaciones (2.ª  ed.). Wiley . pág.  88.
  2. ↑ "IARIGAI - Revista de Investigación en Tecnología de Impresión y Medios, 3-2019" .
  3. ↑ Kar, Avijit; Pal, Arun Kiran (2019). "Un enfoque para la estrategia de mantenimiento basada en riesgos de una imprenta" . Journal of Print and Media Technology Research ( 3–2019 ). doi : 10.14622/JPMTR-1907 .
  4. ↑ Pal, Arun Kiran; Kar, Avijit (2025). "Evaluación cuantitativa de la matriz de riesgo impulsada por RAM de la máquina de impresión offset" . Maintenance, Reliability and Condition Monitoring . 5 : 53–83 . doi : 10.21595/marc.2025.25026 .
  5. ↑ Project Reliability Group (julio de 1990). Koch, John E. (ed.). Jet Propulsion Laboratory Reliability Analysis Handbook (pdf) . Pasadena, California: Jet Propulsion Laboratory . JPL-D-5703 . Consultado el 25 de agosto de 2013 .
  6. ↑ Centro de Vuelo Espacial Goddard (GSFC) (10 de agosto de 1996). Realización de un análisis de modos y efectos de fallas (pdf) . Centro de Vuelo Espacial Goddard. 431-REF-000370 . Recuperado el 25 de agosto de 2013 .
  7. ↑ Departamento de Defensa de los Estados Unidos (9 de noviembre de 1949). MIL-P-1629 – Procedimientos para realizar un análisis crítico y de modos de falla . Departamento de Defensa (EE. UU.). MIL-P-1629. Archivado del original el 19 de julio de 2011. Recuperado el 7 de abril de 2011 .
  8. ↑ Departamento de Defensa de los Estados Unidos (24 de noviembre de 1980). MIL-STD-1629A – Procedimientos para realizar un análisis de modos de falla, efectos y criticidad . Departamento de Defensa (EE. UU.). MIL-STD-1629A. Archivado del original el 22 de julio de 2011.
  9. ↑ Neal, RA (1962). Resumen del análisis de modos de falla para el reactor Nerva B-2 . Laboratorio Astronuclear de Westinghouse Electric Corporation. hdl : 2060/19760069385 . WANL–TNR–042.
  10. ↑ Dill, Robert ; et al. (1963). Estimación de confiabilidad del estado del arte de los sistemas de propulsión del Saturno V. General Electric Company. hdl : 2060/19930075105 . RM 63TMP–22.  
  11. ↑ Procedimiento para el análisis de modos, efectos y criticidad de fallas (FMECA) . Administración Nacional de Aeronáutica y del Espacio. 1966. hdl : 2060/19700076494 . RA–006–013–1A.
  12. ↑ Análisis de modos de falla, efectos y criticidad (FMECA) (PDF) . Administración Nacional de Aeronáutica y del Espacio JPL. PD–AD–1307 . Consultado el 13 de marzo de 2010 .
  13. ↑ Referencia para experimentadores basada en la gestión de experimentos de Skylab (PDF) . Administración Nacional de Aeronáutica y del Espacio, Centro de Vuelos Espaciales George C. Marshall. 1974. M–GA–75–1 . Consultado el 16 de agosto de 2011 .
  14. ↑ Procedimiento de análisis de diseño para el análisis de modos de falla, efectos y criticidad (FMECA) . Sociedad de Ingenieros Automotrices. 1967. ARP926.
  15. ↑ Dyer, Morris K.; Dewey G. Little; Earl G. Hoard; Alfred C. Taylor; Rayford Campbell (1972). Aplicabilidad de los procedimientos de gestión de calidad de contratos y análisis de modos y efectos de fallas de la NASA al programa de gestión de arrendamientos de petróleo y gas de la plataforma continental exterior del USFS (PDF) . Administración Nacional de Aeronáutica y del Espacio, Centro de Vuelos Espaciales George C. Marshall. TM X–2567 . Recuperado el 16 de agosto de 2011 . 
  16. ↑ Mallory, Charles W.; Robert Waller (1973). Aplicación de técnicas seleccionadas de ingeniería industrial a plantas de tratamiento de aguas residuales (PDF) . Agencia de Protección Ambiental de los Estados Unidos . págs. 107–110 . EPA R2–73–176 . Consultado el 10 de noviembre de 2012 .  
  17. ↑ Sperber, William H.; Stier, Richard F. (diciembre de 2009 – enero de 2010). "Feliz 50.º cumpleaños al HACCP: retrospectiva y prospectiva" . FoodSafety Magazine : 42, 44–46 .
  18. ↑ Matsumoto, K.; T. Matsumoto; Y. Goto (1975). "Análisis de confiabilidad del convertidor catalítico como sistema de control de emisiones automotrices". Documento técnico SAE 750178. Serie de documentos técnicos SAE. 1 750178. doi : 10.4271/750178 .
  19. ↑ AIAG (1993). Análisis de modos y efectos de fallas potenciales . Automotive Industry Action Group.
  20. ↑ AIAG (2008). Análisis de modos y efectos de fallas potenciales (FMEA), 4.ª edición . Automotive Industry Action Group. ISBN 978-1-60534-136-1.
  21. ↑ SAE (1994). Análisis de modos y efectos de fallas potenciales en el diseño (FMEA de diseño), análisis de modos y efectos de fallas potenciales en los procesos de fabricación y ensamblaje (FMEA de proceso) y análisis de modos y efectos de fallas potenciales para maquinaria (FMEA de maquinaria) . SAE International.
  22. ↑ SAE (2008). Análisis de modos y efectos de fallas potenciales en el diseño (FMEA de diseño) y análisis de modos y efectos de fallas potenciales en los procesos de fabricación y ensamblaje (FMEA de proceso) y análisis de efectos para maquinaria (FMEA de maquinaria) . SAE International.
  23. ↑ Manual AIAG / VDA FMEA 2019. Consultado el 14 de septiembre de 2020.
  24. ↑ VDA: La industria automotriz alemana exige la máxima calidad de sus productos. Archivado el 2 de marzo de 2021 en Wayback Machine . Consultado el 14 de septiembre de 2020.
  25. 1 2 Kymal, Chad; Gruska, Gregory F. (19 de junio de 2019). "Presentación del AIAG-VDA DFMEA" . qualitydigest . Recuperado el 2 de diciembre de 2020 .
  26. ↑ Webmaster, AIAG. "(FMEA/DFMEA/PFMEA) Análisis de modos y efectos de falla" . www.aiag.org . Consultado el 30 de julio de 2024 .
  27. ↑ Fadlovich, Erik (31 de diciembre de 2007). "Realización de análisis de modos y efectos de fallas" . Embedded Technology . Archivado del original el 17 de noviembre de 2011.
  28. 1 2 3 "Análisis de efectos y modos de falla (FMEA)" . ASQ . Consultado el 15 de febrero de 2012 .
  29. ↑ "El proceso esencial de DFMEA: valor máximo / coste óptimo | exida" . www.exida.com . Consultado el 25 de junio de 2025 .
  30. ↑ "17 de diciembre de 2021 – Ford CSR para uso con IATF 16949 – Grupo de Trabajo Automotriz Internacional" . Consultado el 30 de julio de 2024 .
  31. ↑ Ford Motor Company (3 de enero de 2022). "Requisitos específicos del cliente de Ford Motor Company para IATF-16949:2016" (PDF) . Ford IATF CSR : 23 – vía International Automotive Task Force.
  32. ↑ Langford, JW (1995). Logística: Principios y aplicaciones . McGraw Hill. pág. 488. 
  33. ↑ Pal, Arun Kiran; Kar, Avijit (2025). "Evaluación cuantitativa de la matriz de riesgo impulsada por RAM de la máquina de impresión offset" . Maintenance, Reliability and Condition Monitoring . 5 : 53–83 . doi : 10.21595/marc.2025.25026 .
  34. ↑ Pal, Arun Kiran; Kar, Avijit (2025). "Evaluación cuantitativa de la matriz de riesgo impulsada por RAM de la máquina de impresión offset" . Maintenance, Reliability and Condition Monitoring . 5 : 53–83 . doi : 10.21595/marc.2025.25026 .
  35. ↑ Distribuciones de modos/mecanismos de falla . Centro de análisis de confiabilidad. 1997. FMD–97.
  36. ↑ Pal, Arun Kiran; Kar, Avijit (2025). "Evaluación cuantitativa de la matriz de riesgo impulsada por RAM de la máquina de impresión offset" . Maintenance, Reliability and Condition Monitoring . 5 : 53–83 . doi : 10.21595/marc.2025.25026 .
  37. ↑ Pal, Arun Kiran; Kar, Avijit (2025). "Evaluación cuantitativa de la matriz de riesgo impulsada por RAM de la máquina de impresión offset" . Maintenance, Reliability and Condition Monitoring . 5 : 53–83 . doi : 10.21595/marc.2025.25026 .
  38. ↑ Pal, Arun Kiran; Kar, Avijit (2025). "Evaluación cuantitativa de la matriz de riesgo impulsada por RAM de la máquina de impresión offset" . Maintenance, Reliability and Condition Monitoring . 5 : 53–83 . doi : 10.21595/marc.2025.25026 .
  39. ↑ "MIL-STD-882 E SEGURIDAD DEL SISTEMA" . www.everyspec.com . Consultado el 4 de enero de 2017 .
  40. ↑ "El proceso esencial de DFMEA: valor máximo / coste óptimo | exida" . www.exida.com . Consultado el 25 de junio de 2025 .
  41. 1 2 Potts HWW; Anderson JE; Colligan L.; Leach P.; Davis S.; Berman J. (2014). "Evaluación de la validez de los métodos de análisis de riesgos prospectivos: una comparación de dos técnicas" . BMC Health Services Research . 14 41. doi : 10.1186/1472-6963-14-41 . PMC 3906758. PMID 24467813 .  
  42. ↑ Franklin, Bryony Dean; Shebl, Nada Atef; Barber, Nick (2012). "Análisis de modos y efectos de falla: ¿ demasiado poco para demasiado?". BMJ Quality & Safety . 21 (7): 607– 611. doi : 10.1136/bmjqs-2011-000723 . PMID 22447819. S2CID 46106670 .  
  43. ↑ Shebl, NA; Franklin, BD; Barber, N. (2009). "¿Es fiable el análisis de modos y efectos de fallos?". Journal of Patient Safety . 5 (2): 86– 94. doi : 10.1097/PTS.0b013e3181a6f040 . PMID 19920447. S2CID 45635417 .  
  44. ↑ Kmenta, Steven; Ishii, Koshuke (2004). "Análisis de modos y efectos de fallas basado en escenarios utilizando el costo esperado". Journal of Mechanical Design . 126 (6): 1027. doi : 10.1115/1.1799614 .
  45. ↑ Jee TL; Tay KM; Lim CP (2015). "Un nuevo enfoque basado en un sistema de inferencia difusa de dos etapas para priorizar fallas en el análisis de modos y efectos de fallas" (PDF) . IEEE Transactions on Reliability . 64 (3): 869– 877. Bibcode : 2015ITR....64..869J . doi : 10.1109/TR.2015.2420300 . S2CID 20987880 . 
  46. ↑ Kerk YW; Tay KM; Lim CP (2017). "n Sistema de inferencia difusa de intervalo analítico para la evaluación y priorización de riesgos en el análisis de modos y efectos de fallas". IEEE Systems Journal . 11 (3): 1– 12. Bibcode : 2017ISysJ..11.1589K . doi : 10.1109/JSYST.2015.2478150 . S2CID 5878974 . 
  47. ↑ Chai KC; Tay KM; Lim CP (2016). "Un método basado en computación perceptiva para priorizar los modos de falla en el análisis de modos y efectos de falla y su aplicación al cultivo de nidos de aves comestibles" (PDF) . Applied Soft Computing . 49 : 734–747 . doi : 10.1016/j.asoc.2016.08.043 .
  48. ↑ Tay KM; Lim CP (2008). "Sobre el uso de técnicas de inferencia difusa en modelos de evaluación: parte II: aplicaciones industriales" (PDF) . Optimización difusa y toma de decisiones . 7 (3): 283– 302. doi : 10.1007/s10700-008-9037-y . S2CID 12269658 . 
  49. ↑ Manual AIAG / VDA FMEA 2019. Consultado el 23 de noviembre de 2020.
  50. ↑ VDA: La industria automotriz alemana exige la máxima calidad de sus productos. Archivado el 2 de marzo de 2021 en Wayback Machine . Consultado el 23 de noviembre de 2020.
  51. ↑ Tay KM; Jong CH; Lim CP (2015). "Un modelo de análisis de modos y efectos de fallas basado en agrupamiento y su aplicación a la industria de nidos de aves comestibles" (PDF) . Neural Computing and Applications . 26 (3): 551– 560. doi : 10.1007/s00521-014-1647-4 . S2CID 7821836. Archivado del original (PDF) el 22 de septiembre de 2017. Recuperado el 14 de julio de 2019 . 
  52. ↑ Chang, Wui Lee; Tay, Kai Meng; Lim, Chee Peng (noviembre de 2015). "Agrupación y visualización de modos de falla mediante un árbol evolutivo" (PDF) . Expert Systems with Applications . 42 (20): 7235–7244 . doi : 10.1016/j.eswa.2015.04.036 .
  53. ↑ Chang, Wui Lee; Pang, Lie Meng; Tay, Kai Meng (marzo de 2017). "Aplicación del mapa autoorganizado a la metodología de análisis de modos y efectos de fallas" (PDF) . Neurocomputing . PP : 314–320 . doi : 10.1016/j.neucom.2016.04.073 .
  54. ↑ "Creación de un FMEA" . Diametric Software Ltd. Archivado del original el 22 de agosto de 2020. Consultado el 13 de marzo de 2020 .
  55. ↑ Neufelder, AM (2016). Aplicación efectiva del análisis de modos y efectos de fallas de software. Quanterion Solutions Incorporated.
  56. ↑ "Apéndice B Enumeración de Defectos Comunes (CDE) | www.dau.edu" .
Lecturas relacionadas
6 articulos
{\displaystyle \lambda(t)}Porcentaje de averíasLa tasa de fallas es la frecuencia con la que falla un sistema o componente diseñado, expresada en fallas por unidad de tiempo. Generalmente se den...Análisis de fallosAnálisis de fallosEl análisis de fallas es el proceso de recopilar y analizar datos para determinar la causa de una falla , a menudo con el objetivo de determinar ac...Ingeniería de confiabilidadIngeniería de confiabilidadLa ingeniería de confiabilidad es una subdisciplina de la ingeniería de sistemas que enfatiza la capacidad de un equipo para funcionar sin fallas. ...Razonamiento inductivoEl razonamiento inductivo es cualquiera de los diversos métodos de razonamiento en los que se derivan generalizaciones o principios amplios a parti...Ingeniería de seguridadIngeniería de seguridadIlustración de la NASA que muestra las áreas de alto riesgo de impacto para la Estación Espacial Internacional La ingeniería de seguridad es una di...Ingeniería de calidadIngeniería de calidadLa ingeniería de calidad es la disciplina de la ingeniería que se ocupa de los principios y la práctica del aseguramiento y control de la calidad d...