Amef Onudi 2019

VDA – AMEF
INTRODUCCION
Esta publicación conjunta es la culminación de más de tres años de
colaboración entre OEM y proveedores de nivel 1 del Automotive Industry
Action Group (AIAG), y Verband der Automobilindustrie (VDA). El texto se ha
reescrito por completo y el método AMEF se ha revisado en algunas áreas
clave. La intención es proporcionar una base común para AMEF en todos los
sectores de la industria automotriz que están representados por estas
organizaciones. Si bien se hicieron todos los esfuerzos para lograr el consenso,
puede ser necesario hacer referencia a publicaciones corporativas individuales
o Requisitos específicos del cliente (CSR). Se ha agregado un nuevo método,
AMEF suplementario para monitoreo y respuesta del sistema (FMEA-MSR).
Proporciona un medio para el análisis de detección de diagnóstico y mitigación
de fallas durante la operación del cliente con el fin de mantener un estado
seguro o un estado de cumplimiento normativo. Este manual reemplaza a AIAG
4th Edition FMEA y VDA, "Producto y Proceso FMEA" Volumen 4
INTRODUCCION
El Manual de AIAG y VDA FMEA es un manual de referencia para

ser utilizado por los proveedores de la industria automotriz
como una guía para ayudarlos en el desarrollo del AMEF de
Diseño, AMEF de Proceso y AMEF suplementario para monitoreo
y respuesta del sistema. El manual no define requisitos; Su
objetivo es aclarar los pasos, actividades y herramientas
relacionadas con el desarrollo técnico de los AMEF.
QUÉ ES UN AMEF ?
Un FMEA puede ser descrito como un grupo sistematizado de actividades que
pretenden: a) Reconocer y evaluar la falla potencial de un producto/proceso y los
efectos de esa falla; b) Identificar acciones que pueden reducir o eliminar el riesgo de
que una falla potencial ocurra y c) documentar el proceso completo. Es complementario
al proceso de definir que debe hacer un diseño o proceso debe satisfacer al cliente.
• Herramienta de Mejora
• Prevención de Fallas (Controles Preventivos)
• Corrección de Fallas (Detección)

Amef dentro de
IATF 16949
7.2.3. 8.5.6.1.1.
9.3.2
7.5.3.2.2
8.7.1.4.
8.3.2.1.
8.7.1.5.
8.3.3.3. 9.1.1.2.
8.3.5.1. 9.2.2.3
8.5.1.1.
9.3.2
10.2.4.
10.3.1.
PROPOSITO Y DESCRIPCION DEL AMEF
La industria demanda:
➢Alta calidad del cliente
➢ Optimización de costos de los productos y procesos
➢ Mayor complejidad DE LOS COMPENTES SUMINISTRADOS
➢Alta responsabilidad del producto por parte del diseñador y fabricante
➢por la legislación.
El AMEF se utiliza para abordar los aspectos técnicos de la reducción de riesgos. El

Análisis de Modo y Efectos de Falla (FMEA) es un método analítico sistemático,
cualitativo y orientado al equipo destinado a:
❖Evaluar los riesgos técnicos potenciales de falla de un producto o proceso

❖ Analizar las causas y los efectos de esas fallas
❖ Documentar acciones preventivas y de detección
❖Recomendar acciones para reducir el riesgo
PROPOSITO Y DESCRIPCION DEL AMEF
Los fabricantes consideran diferentes tipos de riesgo, incluidos riesgos técnicos,
riesgos financieros, riesgos de tiempo y riesgos de estrategia.
El FMEA se utiliza para analizar los riesgos técnicos para reducir fallas y mejorar la
seguridad en los productos y procesos
OBJETIVOS DEL AMEF
El objetivo de FMEA es identificar las funciones de un producto o los pasos de
un proceso y los modos, efectos y causas potenciales de falla asociados.
Además, se utiliza para evaluar si los controles de prevención y detección ya
planificados son suficientes y para recomendar acciones adicionales. El FMEA
documenta y rastrea las acciones que se toman para reducir el riesgo. La
metodología FMEA ayuda a los ingenieros a priorizar y enfocarse en evitar
que ocurran problemas de productos y / o procesos.
✓ FUNCION DE PRODUCTO
✓ PASO DE PROCESO
✓ PROBLEMA DE PRODUCTO/ PROCESO
OBJETIVOS DEL AMEF
Existen objetivos importantes de la organización respaldados por FMEA y
otras actividades, tales como:
• Aumentar la calidad, confiabilidad, capacidad de fabricación, facilidad de
servicio y seguridad de los productos automotrices.
• Asegurar la jerarquía, la vinculación, la interfaz y la conexión en cascada y
la alineación de los requisitos entre componentes, sistemas y vehículos.
• Reducción de los costos de garantía y buena voluntad.
• Incremento de la satisfacción del cliente en un mercado altamente
competitivo.
• Probar el análisis del riesgo del producto y del proceso VS la
responsabilidad del producto.
• Reducción de cambios tardíos en el desarrollo.
• Cumplimiento de requisitos legales y reglamentarios.
• Lanzamientos y mantenimiento de productos libre de defectos
• Asertividad en la comunicación con clientes y proveedores
• Crear una base de conocimiento en la empresa, documentar las lecciones
aprendidas
LIMITACIONES AMEF
Las limitaciones de la FMEA incluyen lo siguiente:
• Es cualitativo (subjetivo), no cuantitativo (medible)

• Es un análisis de falla de un solo punto, no un análisis de falla de múltiples
puntos
• Se basa en el nivel de conocimiento del equipo que puede o no predecir el
desempeño futuro
• Es un resumen de las discusiones y decisiones del equipo, por lo tanto, la
calidad del informe FMEA está sujeta a las habilidades de registro del equipo
que pueden reflejar los puntos de discusión en su totalidad o en parte (no es
una transcripción de una reunión )
IDENTIFIQUE EL CLIENTE
• Hay cuatro clientes mayores a ser considerados en el proceso FMEA todos necesitan ser
tenidos en cuenta en el análisis FMEA:
• USUARIO FINAL: La persona u organización que utilizará el producto. El análisis FMEA que afecta el
Usuario Final podría incluir, por ejemplo, durabilidad.
• ENSABLE OEM y CENTROS DE MANUFACTURA (PLANTAS): Las locaciones OEM donde tienen lugar
operaciones de manufactura (Ej. Estampado, Tren de tracción) y ensamble del vehículo. Direccionar los
interfaces entre el producto y su proceso de ensamble es crítico para un efectivo análisis FMEA.
• CADENA DE SUMINISTRO MANUFACTURA. La localidad del proveedor donde tiene lugar la
manufactura, se fabrican o ensamblan materiales de producción, o de partes. Estas incluye fabricación
de producción y partes para servicio y ensambles y procesos tales como tratamiento, soldadura,
pintura, u otros servicios de acabado. Estas pueden ser subsiguientes u operaciones río abajo o un
proceso de manufactura siguiente.
• REGULADORES, agencias de gobierno que definen los requerimientos y monitorean el cumplimiento
para seguridad y especificaciones ambientales las cuales pueden impactar el producto o el proceso
INTEGRACION DEL AMEF
El FMEA en la empresa es una actividad multidisciplinaria que afecta todo el
proceso de realización del producto. La implementación de FMEA necesita
estar bien planificada para ser completamente efectiva. El método FMEA es
un elemento integral de las actividades de desarrollo de productos y
desarrollo de procesos. El FMEA puede reducir el tiempo y el costo de
desarrollo del producto, el entendimiento de especificaciones, planes de
prueba y planes de control.
Las consideraciones para el análisis del AMEF y la implementación de sus

resultados están entre las responsabilidades de las empresas que diseñan,
fabrican y / o ensamblan productos para la industria automotriz. Es crítico que
el análisis tome en consideración las condiciones de operación del producto
durante su vida útil, particularmente con respecto a los riesgos de seguridad y
el mal uso previsible (pero no intencional).
Secuencia de desarrollo de un producto
Define el producto y las especificaciones a

PRODUCTO cumplir
Diseña el proceso de forma de asegurar la

PROCESO calidad final
Utiliza los procesos realizando las tareas

MANUFACTURA
MANUFACTURA definidas
CLIENTE
VIDA UTIL FUNCIONAMIENTO
PROCESO CLIENTE
Ocurrencia Detección Severidad
•Falla
•Control
•Modo de Falla Impacto del
•Confirmación Problema
TIEMPO
IDENTIFIQUE LAS FUNCIONES ,REQUERIMIENTOS, LAS ESPECIFICACIONES
• Identifique y entienda las funciones, requerimientos y especificaciones relevantes para definir

el alcance. El propósito de esta actividad es clarificar la intención del ítem de diseño o el
propósito del proceso. Esto asiste en la determinación del modo potencial de falla para cada
atributo o aspecto de la función.
IDENTIFIQUE LOS MODOS POTENCIALES DE FALLA
• El Modo de Falla está definido como la forma o manera en la cual un producto o proceso podría
fallar para cumplir el intento del diseño o los requerimientos del proceso. Esta presunción se
hace en que la falla podría ocurrir pero no necesariamente ocurre. Una definición concisa y
entendible de falla es importante por cuanto enfoca adecuadamente el análisis. El modo
Potencial de falla podría ser descrito en términos técnicos y no como un síntoma
necesariamente notable por el cliente. Un gran número de modos de falla identificados por un
solo requerimiento puede indicar que la definición de requerimientos no es concisa.
IDENTIFIQUE LOS EFECTOS POTENCIALES
• Los Efectos Potenciales de falla son definidos como los efectos del modo de falla como
los percibe el cliente. Los efectos o el impacto de la falla son descritos en términos de
que el cliente puede notar o experimentar. El cliente puede ser un cliente interno
también como el Usuario Final.
• La determinación de los efectos potenciales incluye el análisis de las consecuencias

de las fallas y de la severidad o seriedad de aquellas consecuencias.
IDENTIFIQUE LAS CAUSAS POTENCIALES
• La Causa Potencial de falla es definida como una indicación de cómo la falla podría ocurrir, descrita en
términos de algo que pude ser corregido o puede ser controlado. La causa potencial de falla puede ser una
indicación de una debilidad en el diseño, la consecuencia de la cual es el modo de falla.
• Hay una relación directa entre una causa y su modo de falla resultante (Ej., si la falla ocurre, entonces el
modo de falla ocurre). Identificar la causa(s) raíz del modo de falla, con suficiente detalle, permite la
identificación de controles apropiados y planes de acción. Un análisis separado de la causa potencial se
realiza para cada causa si hay causas múltiples.
IDENTIFIQUE LOS CONTROLES
• Los Controles son aquellas actividades que previenen o detectan la causa de falla o el modo de falla. En el
desarrollo de los controles es importante identificar que esta yendo mal, porqué, y como prevenirlo o
detectarlo. Los controles son aplicables para el diseño producto o los procesos de manufactura. Los controles
enfocados sobre la prevención producirán los más grandes retornos.
¿ En qué está basada esta Técnica Analitica?
En la valoración de los distintos modos

de falla por medio de ranking’s
Gravedad de la falla,
SEVERIDAD medida de la consecuencia
para el cliente
Frecuencia a que la causa
OCURRENCIA potencial o el mecanismo de
falla está proyectado que ocurra
Probabilidad de que el sistema
DETECCIÓN de control detecte el modo
de falla o la causa potencial
IDENTIFIQUE Y EVALUE EL RIESGO
Uno de los pasos importantes en el proceso FMEA es la evaluación del riesgo.
Este se evalúa en tres formas, severidad, ocurrencia y detección.
• Severidad es una evaluación del nivel de impacto de una falla sobre el cliente.
• Ocurrencia es cuán a menudo puede ocurrir la causa de falla.
• Detección es una evaluación de que tan bien los controles del producto o proceso
detectan la causa de la falla o el modo de falla..
Consideraciones DEL AMEF
Cuando se realiza el FMEA, se deben seguir las siguientes normas:
❑ Claro: los modos de falla potenciales se describen en términos técnicos
precisos y específicos, lo que permite a un especialista evaluar las causas de
falla y los posibles efectos.
❑ Verdadero: las consecuencias de posibles fallas se describen con precisión
(por ejemplo, potencial de olor, humo, fuego, etc.).
❑ Completo: las posibles fallas previsibles no se ocultan. La preocupación por

revelar demasiados conocimientos mediante la creación de un FMEA correcto y
competente no es una razón válida para un FMEA incompleto. La integridad se
refiere a la totalidad del producto / proceso bajo análisis
Los riesgos técnicos de falla identificados en el FMEA se evalúan como aceptables

o se asignan acciones para reducir aún más el riesgo. Se documenta el estado de
cierre de las acciones para reducir el riesgo.
Compromiso de la dirección
El proceso de FMEA puede tardar un tiempo considerable en completarse. Un
compromiso de los recursos requeridos es vital. La participación activa de los
propietarios de productos y procesos y el compromiso de la alta gerencia son
importantes para el desarrollo exitoso de FMEA. La alta gerencia tiene la
responsabilidad de la aplicación de FMEA. En última instancia, la alta gerencia
es responsable de la aceptación de los riesgos y las acciones de minimización
de riesgos identificadas en el AMEF.
El intercambio de propiedad intelectual que se encuentra en el Diseño FMEA y /
o Proceso FMEA entre proveedores y clientes se rige por acuerdos
contractuales entre proveedores y clientes y está más allá del alcance de este
manual.
Los requisitos específicos del cliente con respecto a FMEA deben coordinarse con
las partes involucradas y / o los proveedores. Un acuerdo sobre la ejecución de los
AMEF puede incluir, entre otros, elementos como los límites del sistema, los
documentos de trabajo necesarios, los métodos de análisis y las tablas de
evaluación.
ESTRATEGIA DE TRANSICION
Los FMEAs existentes desarrollados utilizando el “AMEF de Producto y proceso
” de la 4ta edición de AIAG anterior de VDA Edition, pueden permanecer en su
forma original para revisiones posteriores. La organización debe planificar
cuidadosamente la transición de sus procesos y métodos actuales de FMEA a
los nuevos procesos y herramientas de AIAG y VDA FMEA. Cuando sea
práctico, los FMEA existentes utilizados como punto de partida para nuevos
programas deben convertirse para reflejar las nuevas escalas de calificación,
métodos analíticos y formato. Sin embargo, si el equipo determina que el
nuevo programa se considera un cambio menor en el producto existente,
puede decidir dejar el FMEA en el formato existente. Los nuevos proyectos
deben seguir el método VDA FMEA presentado en este Manual a menos que
el liderazgo de la empresa y los Requisitos específicos del cliente (CSR) exijan
un enfoque diferente. La fecha de transición y el hito del proyecto después de
los cuales los nuevos proyectos siguen este método deben ser definidos por la
compañía teniendo en cuenta los Requisitos específicos del cliente.
AMEF BASE O DE FAMILIA
Se recomienda crear y utilizar un AMEF Base o/y de familia como base para
nuevos análisis. Estas prácticas opcionales proporcionan la mayor oportunidad
para aprovechar la experiencia y el conocimiento pasados y garantizar que el
conocimiento se acumule a lo largo de los ciclos de vida de los productos y
que no se repitan problemas de rendimiento anteriores (lecciones
aprendidas). Además, esta reutilización también reduce el esfuerzo y los
gastos.
Los FMEA BASE o de Familia contienen conocimientos de la organización de
desarrollos anteriores que los hacen útiles como punto de partida para los
nuevos FMEA.
Los FMEA de familia, es común desarrollar productos que generalmente
contienen límites de productos comunes o consistentes y funciones
relacionadas (una familia de productos) o procesos que contienen una serie
de operaciones que producen varios productos o números de pieza. En estos
casos, es apropiado desarrollar FMEA de Familia que cubran los puntos en
común para estas Familias
AMEF BASE O DE FAMILIA
Al utilizar el enfoque FMEA de la familia o Tipo para el nuevo producto o

proceso en desarrollo, el equipo debe identificar y centrar el análisis en las
diferencias entre el producto, proceso o aplicación existente y el nuevo. La
información y las calificaciones llevadas a cabo desde los AMEF de familia o
Tipo.
EN QUÉ CASOS SE REALIZA UN AMEF?
AMEF DE PRODUCTO Y PROCESO
Caso 1: Diseño nuevo, nueva tecnología, o procesos nuevos.
El alcance del FMEA es el diseño completo, la tecnología o el proceso.
Caso 2: Nueva aplicación (Modificación) a diseños o procesos existentes (se asume que hay
un FMEA para los diseños o procesos existentes). El alcance de la FMEA es un diseño o
proceso existente en un nuevo entorno, ubicación, aplicación o perfil de uso (incluyendo
ciclo de trabajo, requisitos reglamentarios, etc.). El alcance de la FMEA debe centrarse en el
impacto del nuevo entorno, ubicación o uso de la aplicación en el diseño o proceso
existente.
Caso 3: Cambio de Ingeniería de un proceso o diseño existente
Los nuevos desarrollos técnicos, los nuevos requisitos, los retiros del mercado de productos y
los informes de fallas en el campo pueden generar la necesidad de cambios en el diseño y /
o proceso. En estos casos, puede ser necesaria una revisión o revisión del FMEA.
.
EN QUÉ CASOS SE REALIZA UN AMEF?
El FMEA contiene una gran colección de conocimientos sobre un diseño o proceso y
puede revisarse después del inicio de la producción si se aplica al menos uno de los
siguientes puntos:
• Cambios en los diseños o procesos.

• Cambios en las condiciones de operación.
• Requisitos modificados (por ejemplo, leyes, normas, clientes, estado del arte)
• Problemas de calidad (por ejemplo, experiencia en la planta, cero kilometraje o
problemas de campo, quejas internas / externas).
• Cambios en el Análisis de Peligros y Evaluación de Riesgos
• Cambios en el análisis de amenazas y la evaluación de riesgos
• Hallazgos debido al monitoreo del producto.
• Lecciones aprendidas Existen dos enfoques principales para FMEA: el análisis según
las funciones del producto (Diseño FMEA) o según los pasos del proceso (Proceso
FMEA).
.
Un FMEA diseño (DFMEA) es una técnica analítica utilizada
principalmente por un ingeniero / equipo responsable del diseño
como un medio para asegurar que, en la medida de lo posible, los
posibles modos de falla y sus causas o mecanismos asociados de falla
hayan sido considerados y abordados antes de su lanzamiento de la
parte a producción.
El FMEA Diseño analiza las funciones de un sistema, subsistema o
componente de interés según lo definido por el límite que se muestra
en el Diagrama de Bloque / Límite, la relación entre sus elementos
subyacentes y los elementos externos fuera del límite del sistema. Esto
permite la identificación de posibles debilidades de diseño para
minimizar los riesgos potenciales de falla.
Un componente DFMEA es un subconjunto de un sistema o subsistema DFMEA.
Por ejemplo, un motor eléctrico es un componente del elevador de ventanas,
que es un subsistema del sistema de elevadores de ventanas. Una carcasa para
el motor eléctrico también puede ser un componente o una parte. Por esta
razón, los términos "elemento del sistema" o "elemento" se utilizan
específicamente del nivel de análisis. El diseño FMEA también se puede utilizar
para evaluar los riesgos de falla de productos no automotrices como máquinas y
herramientas. Las acciones resultantes del análisis pueden detectar cambios de
diseño, pruebas adicionales y otras acciones que reducen el riesgo de falla o
aumentan la capacidad de una prueba para detectar fallas antes de la entrega
del diseño para la producción.
En contraste con el Diseño FMEA (DFMEA), que analiza las posibilidades de
falla que se pueden crear durante la fase de diseño del producto, el Proceso
FMEA (PFMEA) analiza las fallas potenciales de los procesos de fabricación,
ensamblaje y logística para producir productos que se ajusten a la
intención del diseño. Las fallas relacionadas con el proceso son diferentes a
las fallas analizadas en el Diseño FMEA. El FMEA de Proceso analiza los
procesos al considerar los posibles modos de falla que pueden resultar de
la variación del proceso, para establecer la prioridad de las acciones de
prevención y, según sea necesario, mejorar los controles. El propósito
general es analizar los procesos y tomar medidas antes del inicio de la
producción, para evitar defectos no deseados relacionados con la
fabricación y el ensamblaje y las consecuencias de esos defectos.
Existen oportunidades de
colaboración entre los FMEA de
diseño y proceso en la misma
empresa y fuera de la empresa.
Para ayudar a comunicar los efectos
y la gravedad, puede realizar
evaluaciones conjuntas y entre
organizaciones (diferentes
proveedores en la cadena de
suministro que comienzan con el
Nivel 1, Nivel 2, Nivel 3, etc.) como
se muestra en la figura
Un buen punto de partida para un fabricante es asegurarse de
que la severidad en DFMEA y PFMEA sea la misma cuando los
efectos de falla sean los mismos. Si los efectos de falla del
"producto" para el usuario final (nivel del vehículo) no están
incluidos en el PFMEA, entonces la correlación entre el DFMEA y
el PFMEA no es posible. Se debe hacer una correlación para que
una falla de una característica en el diseño que conduce a un
cierto efecto de falla también se capture en el PFMEA para la
misma característica (característica del producto).
´ PLANIFICACION DEL PROYECTO
Las Cinco T son cinco temas que deben definirse al comienzo de un DFMEA o PFMEA
para lograr los mejores resultados a tiempo y evitar la retrabajos del FMEA.
Al inicio del proyecto se deben definir los siguientes temas:
Intención del AMEF – ¿Para que estamos haciendo FMEA? (Intent)

Se recomienda que los miembros del equipo de FMEA sean competentes en el
método, en función de su papel en el equipo. Cuando los miembros del equipo
entiendan el propósito y la intención de FMEA, estarán más preparados para contribuir
a las metas y objetivos del proyecto.
Tiempo del FMEA - ¿cuando se debe hacer? (timing)

FMEA debe ser una acción "antes del evento", no un ejercicio "después del hecho".
Para lograr un mayor valor, el FMEA debe realizarse antes de la implementación de un
producto o proceso en el que existe el modo potencial de falla. Un FMEA ayuda ha
implementar los cambios de producto / proceso de manera más fácil y económica,
minimizará las crisis de cambio tardío.
El FMEA debe llevarse a cabo de acuerdo con el plan del proyecto y evaluarse en
los hitos del proyecto de acuerdo con el estado del análisis. Se recomienda que
una empresa defina los niveles de madurez deseados para sus FMEA de acuerdo
con los hitos generales del proyecto de desarrollo específico de la empresa
FMEA Timing Aligned with APQP Phases
FMEA Timing Aligned to MLA Phases
Equipo del FMEA - ¿Quiénes deben formar el equipo? (Team )
El equipo de FMEA está formado por miembros multidisciplinario,
(multifuncionales) que abarcan el conocimiento necesario de la materia. Esto
debe incluir la experiencia en facilitación y el conocimiento del proceso FMEA. El
éxito del FMEA depende de la participación activa del equipo multifuncional.
El equipo de FMEA de Diseño
El equipo central puede estar formado por las siguientes personas:
• facilitador
• ingeniero de diseño
• ingeniero de sistemas
• ingenieros de componentes
• ingeniero de pruebas
• ingeniero de calidad / confiabilidad
• otros responsables del desarrollo del producto.
Los miembros del Equipo Central preparan el Análisis del Sistema FMEA (Pasos 1 -
3) y participan en las reuniones de FMEA.
El equipo de FMEA de Diseño
Los miembros del Equipo Central preparan el Análisis del Sistema FMEA (Pasos 1 - 3) y
participan en las reuniones de FMEA.
El Equipo Extendido puede participar bajo demanda (coordinado por el facilitador de
FMEA o el organizador de la reunión). El Equipo Extendido puede consistir en las
siguientes personas:
• expertos técnicos
• ingeniero de procesos / fabricación
• Ingeniero de servicio
• gerente de proyecto
• ingeniero de seguridad funcional
• compra
• proveedor
• representante del cliente
• otros que pueden tener conocimientos especializados que ayudarán al equipo
central a analizar aspectos específicos del producto
El equipo de FMEA de Proceso
El equipo central puede estar formado por las siguientes personas:
• facilitador
• ingeniero de Manufactura/ Proceso
• ingeniero de Ergonomía
• ingeniero de Validación de proceso.
• ingeniero de calidad / confiabilidad
• otros responsables del desarrollo del proceso.
Los miembros del Equipo Central preparan el Análisis del Sistema FMEA (Pasos 1 -
3) y participan en las reuniones de FMEA. El Equipo Extendido puede participar bajo
demanda (coordinado por el facilitador de FMEA o el organizador de la reunión).
El Equipo Extendido puede participar bajo demanda (coordinado por el facilitador de
FMEA o el organizador de la reunión). El Equipo Extendido puede consistir en las
siguientes personas:
• Ingeniero de Diseño
•Expertos técnicos
• Ingeniero de servicio
• gerente de proyecto
• ingeniero de Mantenimiento
• Trabajadores de línea
• Compras
• proveedor
• otros (que se requieran)
Roles y responsabilidades del equipo FMEA
Dentro del proceso de desarrollo de productos de la organización, se deben asignar los
siguientes roles y responsabilidades para la participación de FMEA. Las
responsabilidades de un rol determinado pueden compartirse entre diferentes
personas y / o pueden asignarse múltiples roles a la misma persona.
Gerente del proyecto
• Autoridad para tomar decisiones sobre la aceptabilidad de los riesgos identificados y
la ejecución de acciones
• Define a las personas responsables de las actividades previas al trabajo, la
facilitación de FMEA y el ingeniero de diseño / proceso responsable de la
implementación de las acciones resultantes del análisis.
• Responsable de seleccionar y aplicar recursos y garantizar que se implemente un
proceso de gestión de riesgos efectivo dentro del tiempo programado del proyecto
• Responsabilidad y propiedad del desarrollo y mantenimiento de los AMEF.
• La responsabilidad administrativa también incluye brindar apoyo directo a los
equipos mediante revisiones continuas y eliminar obstáculos.
• Responsable del presupuesto.
Líder de Diseño/ Proceso (Líder Técnico)
• Responsabilidad técnica por los contenidos de FMEA .
• Define a las personas responsables de las actividades previas al trabajo, la
facilitación de FMEA y el ingeniero de diseño / proceso responsable de la
implementación de las acciones resultantes del análisis.
• Responsable de seleccionar y aplicar recursos y garantizar que se implemente
un proceso de gestión de riesgos efectivo dentro del tiempo programado del
proyecto
• Responsabilidad y propiedad del desarrollo y mantenimiento de los AMEF.
• La responsabilidad administrativa también incluye brindar apoyo directo a los
equipos mediante revisiones continuas y eliminar obstáculos.
• Responsable del presupuesto.
Facilitador del AMEF
• Coordinación y organización de los flujos de trabajo en la FMEA
• Mitigación de conflictos
• Participación en la formación de equipos
• Participación en la preparación del calendario
• Participación en la invitación a la 1a reunión del equipo para la fase de análisis
• Participación en la preparación de las pautas/criterios de decisión
• Desarrollo de ejemplos corporativos o de línea de productos para tablas de
clasificación (opcional) con el apoyo de ingeniería de procesos
• Competencia método (FMEA) y familiarización de los participantes en el método
FMEA
• Competencia de documentación de software FMEA (según sea necesario)
• Habilidades sociales, capaces de trabajar en equipo
• Moderador competente, capacidad para convencer, organización y habilidades de
presentación
• Gestión de la ejecución de los 7 pasos del método FMEA
• Si es necesario, Preparación o finalización de las reuniones de la FMEA
Miembros Principales del AMEF
• Aportar conocimientos de productos y experiencia de proceso relevantes
• Aportar la información necesaria sobre el producto o proceso que es el foco de la
FMEA
• Contribución de las experiencias existentes de FMEA anteriores ya conocidas
• Participación en la ejecución de los 7 pasos de FMEA
• Participación en la preparación del caso de negocio
• Incorporación de las lecciones aprendidas
Miembros Extendido y/o Expertos del AMEF

• Contribución de información adicional sobre temas especiales
• Contribución de la información necesaria sobre el producto o proceso que es el foco de la
FMEA
• Participación en la preparación del caso de negocio
Tareas de FMEA
La descripción general de 7 pasos proporciona el marco para las tareas y entregas
del AMEF. Además, el equipo del AMEF debe estar preparado para revisar los
resultados de su análisis con la dirección y el cliente, previa solicitud.
El Amef también puede ser auditada por un auditor interno, auditor de clientes o
Auditor externo para asegurarse de que cada tarea se ha cumplido
Herramientas FMEA
Hay numerosas herramientas FMEA, es decir, paquetes de software que se
pueden utilizar para desarrollar un DFMEA y PFMEA, así como el seguimiento de
las acciones. Este software abarca desde software FMEA dedicado hasta hojas de
.
cálculo estándar personalizadas para desarrollar el FMEA. Las empresas pueden
desarrollar su propia solución de base de datos interna o comprar software
comercial. En cualquier caso, el equipo de FMEA necesita tener conocimiento de
cómo utilizar la herramienta FMEA seleccionada para su proyecto según lo
requiera la empresa.
METODOLOGIA DEL AMEF
Los análisis para el AMEF de Diseño FMEA, el AMEF de Proceso FMEA y el AMEF
Suplementario para Monitoreo y respuesta del Sistema (FMEA-MSR) se describen
completamente de manera independiente. Por consiguiente la redundancia de
conceptos es inevitable. Tiene la ventaja que el Usuario puede referirse
directamente al capítulo de AMEF de Diseño y/o Amef de Proceso y/o FMEA-MSR
sin hacer referencia al contenido de los otros capítulos.
El Desarrollo del AMEF se lleva a cabo en siete pasos.

Estos siete pasos proporcionan un enfoque sistemático para realizar un
.
análisis de Modos de Falla y sus efectos y sirven como un registro del
análisis de riesgo técnico en un proyecto.
El enfoque de los siete pasos otorga un marco de trabajo para la documentación de
los riesgos técnicos de una forma precisa, relevante y completa. Los siete pasos de
la nueva versión de FMEA se pueden dividir en tres etapas y son los siguientes:
METODOLOGIA DEL AMEF
.
AMEF DE DISEÑO ETAPA 1 : PREPARACION Y PLANIFICACION
PROPOSITO:
El propósito del Paso de Planificación y Preparación del AMEF de diseño es
definir qué FMEA se realizarán para un proyecto, y definir lo que se incluye y
excluye en cada FMEA en función del tipo de análisis que se está desarrollando,
es decir, sistema, subsistema o componente.
Los principales objetivos de esta etapa son:
• Identificación del proyecto
• Plan de proyecto: InTent, Timing, Team, Tasks, Tools (5T)
• Límites de análisis: Lo que se incluye y excluye del análisis
• Identificación de FMEA de referencia con las lecciones aprendidas
• Bases para la Etapa de Análisis Estructural.
ETAPA 1: PLANEACION Y PREPARACION
Identificación y Límites del Proyecto DFMEA
La identificación del proyecto DFMEA incluye una comprensión clara de lo que debe
evaluarse. Esto implica un proceso de toma de decisiones para definir los DFMEA que
se necesitan para un proyecto de cliente. Lo que debe se debe excluir puede ser tan
importante como qué incluir en el análisis.
A continuación se presentan algunas preguntas básicas que ayudan a dimensionar el
proyectos DFMEA.
• ¿Qué nos está comprando el cliente?
• ¿Existen nuevos requisitos?
• ¿El cliente o la empresa requiere un DFMEA?
• ¿Hacemos el producto y tenemos control de diseño?
• ¿Compramos el producto y todavía tenemos control de diseño?
• ¿Compramos el producto y no tenemos control de diseño?
• ¿Quién es responsable del diseño de la interfaz?
• ¿Necesitamos un sistema, subsistema, componente u otro nivel de análisis?
Las respuestas a estas preguntas y otras definidas por la empresa ayudan a
dimensionar el proyecto DFMEA y Asegura compromiso de la dirección y un enfoque
coherente.
ETAPA 1: PLANEACION Y PREPARACION
Identificación y Límites del Proyecto DFMEA
Lo siguiente puede ayudar al equipo a definir los límites de DFMEA, según corresponda:
❖ Requisitos técnicos
❖ Requisitos Legales
❖ Deseos/necesidades/expectativas del cliente (clientes externos e internos)
❖ Especificación de requisitos
❖ Diagramas (Bloque/Límite) de un proyecto similar
❖ Esquemas, dibujos y/o modelos 3D
❖ Lista de materiales (BOM), evaluación de riesgos
❖ FMEA anterior para productos similares
❖ •Requisitos de Prevención de errores, Diseño para la fabricación y montaje (DFM/A)
❖ • Implementación de funciones de calidad QFD
CONSIDERE
❖ Novedad de la tecnología/grado de innovación
❖ Historial de calidad / confiabilidad (interno, cero kilometraje, fallos de campo, garantía y
reclamaciones de políticas para productos similares)
❖ Complejidad del diseño
❖ La Seguridad de las personas y los sistemas
❖ Sistema ciberfísico (incluida la ciberseguridad)
❖ Cumplimiento legal
❖ Catálogo de partes
ETAPA 1: PLANEACION Y
PREPARACION
Plan de Proyecto DFMEA
Una vez que se conozca el proyecto DFMEA, se debe elaborar un plan para la
ejecución del DFMEA.
Se recomienda utilizar el método 5T (InTent, Timing, Team, Tasks, Tool) El plan para el
DFMEA ayuda a la empresa a ser proactiva en el inicio de DFMEA temprano. Las
actividades de DFMEA (proceso de 7 pasos) deben incorporarse al plan general del
proyecto
Identificación de la línea de base DFMEA
Parte de la preparación para la realización del DFMEA es saber qué
información ya está disponible que puede ayudar al equipo multifuncional.
Esto incluye el uso de un DFMEA BASE, producto similar DFMEA, o DFMEA
de Familia. Para un nuevo producto de la familia, los nuevos componentes y
funciones específicos del proyecto para completar el DFMEA del nuevo
producto se añadirían a la familia FMEA. Las adiciones para el nuevo producto
pueden estar en la propia familia DFMEA, o en un nuevo documento con
referencia a la familia original o DFMEA. Si no hay línea de base disponible, el
equipo desarrollará un nuevo DFMEA.
Encabezado del DFMEA
PREPARACION
Durante el paso de planificación y preparación, se debe rellenar la cabecera
del documento DFMEA. El encabezado se puede modificar para satisfacer las
necesidades de la organización. El encabezado incluye parte de la
información básica del ámbito DFMEA de la siguiente manera:
Nombre de la empresa: Nombre de la empresa responsable de DFMEA
Ubicación de ingeniería: Ubicación geográfica
Nombre del cliente: Nombre del cliente o producto
Año Modelo / Programa(s): Aplicación de Cliente o Modelo de Empresa /Estilo
Asunto: Nombre del Proyecto DFMEA (Sistema, Subsistema y/o Componente)
DfMEA Fecha de inicio: Fecha de inicio
DFMEA Fecha de revisión: última fecha de revisión
Equipo multifuncional: Miembros del Equipo
DFMEA ID Número: Determinado por la compañía
Responsabilidad de diseño de la empresa: Nombre del propietario de DFMEA
Nivel de Confidencialidad: Uso Comercial, Propietario, Confidencial
PREPARACION
AMEF ANALISIS DE MODO Y EFECTO DE FALLA (AMEF DE PROCESO )

PLANEACION Y PREPARACION (PASO 1)
NOMBRE DE LA COMPAÑÍA: ASUNTO/ PROYECTO DFMEA Numero:
UBICACIÓN INGENIERIA: PFMEAFECHA DE INICIO: RESPONSABLE DEL DISEÑO
NOMBRE DEL CLIENTE : PFMEA FECHA DE REVISION: NIVEL DE CONFIDENCIALIDAD:
AÑO MODELO/ PLATAFORMA: EQUIPO MULTIFUNCIONAL
Base para el análisis estructural

La información recopilada durante la Planificación y Preparación del Paso 1
se utilizará para desarrollar el Análisis de Estructura del Paso 2.
ETAPA 2: ANALISIS ESTRUCTURAL
Propósito
El propósito del Análisis de Estructura de Diseño es identificar y desglosar el alcance
de FMEA en el sistema, subsistema y componentes para el análisis de riesgos técnico.
Los principales objetivos de un análisis de estructura de diseño son:
• Visualización del alcance del análisis
• Árbol de estructura o equivalente: diagrama de bloques, diagrama de límites,
modelo digital, partes físicas
• Identificación de interfaces de diseño, interacciones, holguras cercanas
• Colaboración entre equipos de ingeniería de clientes y proveedores
(responsabilidades de interfaz)
• Base para el paso Análisis de funciones
Estructura del sistema
Una estructura del sistema se compone de elementos del sistema. Según el ámbito
del análisis, los elementos del sistema de una estructura de diseño pueden constar de
un sistema, subsistemas, ensamblajes y componentes Un sistema tiene un límite que
lo separa de otros sistemas y del entorno. Su relación con el entorno se define por
entradas y salidas. Un elemento del sistema es un componente distinto de una
posición funcional, no una función, un requisito o una operación
Definir al cliente
Hay dos clientes principales a tener en cuenta en el análisis FMEA:
• USUARIO FINAL: La persona que utiliza un producto después de que ha sido

completamente desarrollado y comercializado.
• MONTAJE y FABRICACIóN: los lugares donde se llevan a cabo las operaciones de

fabricación (por ejemplo, tren motriz, estampado y fabricación) y el procesamiento de
materiales de montaje y producción de vehículos/productos. Abordar las interfaces
entre el producto y su proceso de montaje es fundamental para un análisis FMEA
eficaz. Esto puede ser cualquier operación posterior o posterior o un siguiente
proceso de fabricación de nivel.
El conocimiento de estos clientes puede ayudar a definir las funciones, requisitos y

especificaciones de forma más robusta, así como ayudar a determinar los efectos de
los modos de falla relacionados.
Visualizar la estructura del sistema
Una visualización de la estructura del sistema ayuda al equipo de DFMEA a desarrollar
el análisis estructural. Hay varias herramientas que pueden ser utilizadas por el
equipo para lograr esto. Dos métodos comúnmente utilizados se describen en las
secciones siguientes:
• Diagramas de bloques
• Estructura de Árbol
Diagrama de bloques
Los diagramas de bloques son herramientas útiles que representan el sistema
considerado y sus interfaces con los sistemas adyacentes, el entorno y el cliente. El
diagrama es una representación gráfica que proporciona pautas para la lluvia de ideas
estructurada y facilita el análisis de las interfaces del sistema como base para un
AMEF de DISEÑO. El diagrama siguiente muestra las relaciones físicas y lógicas entre
los componentes del producto. Indica la interacción de componentes y subsistemas
dentro del ámbito del diseño, así como de aquellas interfaces con el producto Cliente,
Fabricación, Servicio, Envío, etc. El diagrama identifica a las personas y las cosas con
las que el diseño interactúa durante su vida útil.
El diagrama puede estar en forma de cajas conectadas por líneas, y cada caja
corresponde a un componente principal del producto. Las líneas se
corresponden con la forma en que los componentes del producto están
relacionados o interactúan entre sí, con flechas en los puntos finales para
indicar la dirección del flujo.
• Define el alcance del análisis (ayuda a identificar posibles

miembros del equipo)
• Identifica interfaces internas y externas.
• Permite la aplicación de sistema, subsistema y jerarquía de
componentes
ANALISIS DE INTERFACE
Un análisis de interfaz describe las interacciones entre elementos de un sistema.
Hay cinco tipos principales de interfaces:
• Conexión física (por ejemplo, soportes, pernos, abrazaderas y varios tipos de
conectores)
• Intercambio de material (por ejemplo, aire comprimido, fluidos hidráulicos o
cualquier otro intercambio de fluido o material)
• Transferencia de energía (por ejemplo, transferencia de calor, fricción o
transferencia de movimiento, como eslabones de cadena o engranajes)
• Intercambio de datos (por ejemplo, entradas o salidas de computadora, mazos
de cables, señales eléctricas o cualquier otro tipo de intercambio de información,
elementos de seguridad cibernética)
• Hombre-máquina (p. Ej., Controles, interruptores, espejos, pantallas,
advertencias, asientos, entrada / salida)
Otro tipo de interfaz puede describirse como una separación física entre las partes,
donde no hay conexión física. Los espacios libres pueden ser estáticos y / o
dinámicos. Considere las interfaces entre subsistemas y componentes además del
contenido de los subsistemas y componentes en sí.
Estructura de árboles
Estructura de Árbol organiza los elementos del sistema jerárquicamente e ilustra la
dependencia a través de las conexiones estructurales. De este modo, la estructurada
del sistema completo está garantizada por el hecho de que cada elemento del sistema
sólo existe una vez para evitar la redundancia. Las estructuras dispuestas bajo cada
elemento del sistema son subestructuras independientes
Brush Card Base Body
Window Lifter Commutation System Carbon Brush

Motor
Electronic Control Unit
Magnets (Neodym)
Armature Shaft
Electromagnetic
Converter
Pole Housing
Window Lifter System Lifting
Mechanism Magneto-mechanical Gear box
Converter
Guiding Frame
System Elements in Scope …

…
Ejemplo de análisis de estructura
1. Siguiente nivel superior: El nivel más alto de integración dentro del ámbito del
análisis.
2. Elemento de enfoque: El elemento en foco. Este es el elemento que es tema de
consideración de la cadena de fallas.
3. Siguiente nivel inferior o tipo de característica:
El elemento que es el siguiente nivel hacia abajo de la estructura desde el
elemento de foco.
Colaboración entre el Cliente y el Proveedor

La salida del Análisis de Estructura (visualización del diseño y sus interfaces)
proporciona una herramienta de colaboración entre clientes y proveedores durante
las revisiones técnicas del proyecto de diseño y/o DFMEA.
Base para el análisis de funciones

La información definida durante el Paso 2 Análisis de Estructura se utilizará para
desarrollar el Análisis de Funciones del Paso 3. Si faltan elementos de diseño
(elementos) en el Análisis de estructura, también faltarán en el Análisis de funciones.
ETAPA 3: ANALISIS de la función
PROPOSITO
El objetivo del análisis de funciones de diseño es garantizar que las funciones
especificadas por los requisitos/especificaciones se asignen adecuadamente a los
elementos del sistema. Independientemente de la herramienta utilizada para generar
el DFMEA, es fundamental que el análisis esté escrito en términos funcionales.
Los principales objetivos de un análisis de funciones de diseño son:
• Visualización de las funciones del producto o del proceso
• Hoja de formulario y diagrama de parámetros de análisis de árbol/red o árbol de
funciones (diagrama P)
• Cascada de funciones de cliente (externas e internas) con requisitos asociados
• Asociación de requisitos o características a las funciones
• Colaboración entre equipos de ingeniería (sistemas, seguridad y componentes)
• Base para el paso Análisis de fallos
Función
Una función describe lo que el elemento/elemento del sistema está destinado a hacer.
Se debe asignar una función a un elemento del sistema. Además, un elemento del sistema puede contener
varias funciones.
La descripción de una función debe ser clara.
El formato de frase recomendado es usar un "verbo de acción" seguido de un "sustantivo" para describir una
función medible.
Una función debe estar en el TIEMPO PRESENTE ; utiliza la forma base del verbo (por ejemplo, entregar,
contener, controlar, ensamblar, transferir).
Ejemplos: entregar energía, contener fluido, velocidad de control, transferencia de calor, color negro
REQUISITOS
ISO 9000 define un requisito como una necesidad o expectativa que un diseño,
producto o proceso en particular tiene como objetivo satisfacer.
Los requisitos se dividen en dos grupos: requisitos funcionales y requisitos no
funcionales.
Un requisito funcional es un criterio por el cual se juzga o mide el rendimiento

previsto de la función (por ejemplo, rigidez material).
Un requisito no funcional es una limitación de la libertad de decisión de diseño (por
ejemplo, rango de temperatura).
Los requisitos pueden derivarse de diversas fuentes, externas e internas, que podrían
ser:
Requisitos legales:
• Diseño de producto respetuoso con el medio ambiente, adecuado para el reciclaje,
seguro en caso de posible mal uso por parte del operador, no inflamable, etc.
Normas y normas de la industria:

• ISO 9001, VDA Volumen 6 Parte 3, Auditoría de procesos, SAE J1739, ISO 26262
Seguridad Funcional.
Requisitos del cliente:
• Explícito (es decir, en las especificaciones del cliente) e implícito (es decir, libertad
de materiales prohibidos) – en todas las condiciones especificadas
Requisitos internos:
• Producto específico (es decir, especificaciones de requisitos, manufacturabilidad,
idoneidad para pruebas, compatibilidad con otros productos existentes, reutilización,
limpieza, generación, entrada y propagación de partículas)
Características del producto:
• Una característica distintiva (o atributo cuantificable) de un producto, como un
diámetro de Trabajo o un acabado superficial.
DIAGRAMA DE PARAMETROS
Los parámetros se consideran atributos del comportamiento de una función. Un
diagrama de parámetros (P) es una representación gráfica del entorno en el que
existe un elemento. Un diagrama P incluye factores que influyen en la función de
transferencia entre entradas y salidas, centrándose en las decisiones de diseño
necesarias para optimizar la salida.
Un diagrama P se utiliza para caracterizar el comportamiento de un sistema o
componente en el contexto de una sola función. Los diagramas P no son necesarios
para todas las funciones. Los equipos deben centrarse en algunas funciones clave
afectadas por las nuevas condiciones y aquellas con historial de problemas de
robustez en aplicaciones anteriores. Se puede necesitar más de un diagrama P para
ilustrar las funciones del sistema o componente que son de interés para el equipo de
El diagrama P, completado para funciones ideales específicas, ayuda a la identificación
FMEA.
de:
• Factores, niveles, respuestas y señales necesarias para la optimización del sistema
• Funciones que son entradas para el DFMEA
• Factores de control y ruido que podrían afectar el rendimiento funcional
• Salidas involuntarias del sistema (salidas desviadas)
Ejemplo de comportamiento del sistema

A continuación se muestra un ejemplo de un diagrama de parámetros que se utiliza
para evaluar las influencias en una función de un producto, que incluye:
Entrada (lo que desea poner para obtener el resultado deseado) es una descripción
de las fuentes necesarias para cumplir con la funcionalidad del sistema.
Función (Lo que desea que suceda) se describe en un diagrama de parámetros con un
verbo activo seguido de un sustantivo medible en el tiempo presente y asociado con
los requisitos.
Factores de control (Lo que se puede hacer para que suceda) que se pueden ajustar
para hacer el diseño más insensible al ruido (más robusto) se identifican. Un tipo de
Factor de Control es un Factor de Señal. Los factores de señal son factores de ajuste,
establecidos directa o indirectamente por un usuario de un sistema, que cambian
proporcionalmente la respuesta del sistema (por ejemplo, el movimiento del pedal de
freno cambia la distancia de frenado). Sólo los sistemas dinámicos utilizan factores de
señal. Los sistemas sin factores de señal se denominan sistemas estáticos.
Requisitos no funcionales (lo que necesita además de los requisitos funcionales) que
limitan la opción de diseño.
Salida prevista (lo que desea del sistema) son salidas funcionales ideales, previstas
cuya magnitud puede (sistema dinámico) o no (sistema estático) ser linealmente
proporcional a un factor de señal (por ejemplo, activación de haz bajo para un faro,
detención de distancia como un función del movimiento del pedal de freno).
Salida no deseada (lo que no desea del sistema) son comportamientos incorrectos o
salidas del sistema no deseadas que desvían el rendimiento del sistema de la función
prevista ideal. Por ejemplo, la energía asociada a un sistema de frenos se transforma
idealmente en fricción. El calor, el ruido y las vibraciones son ejemplos de salidas
desviadas por energía de freno. Las salidas desviadas pueden ser pérdidas de
radiación térmica, vibración, resistencia eléctrica, restricción de flujo, etc.
Factores de ruido (lo que interfiere con el logro de la salida deseada) son parámetros
que representan fuentes de variación potencialmente significativas para la respuesta
del sistema y no se pueden controlar o no son prácticos de controlar desde la
perspectiva del ingeniero.
salidas del sistema no deseadas Los ruidos se describen en unidades físicas.

• Variación pieza a pieza
(en un componente e interferencia entre componentes)
• Cambiar con el tiempo
(envejecimiento a lo largo de la vida, por ejemplo, kilometraje, envejecimiento,
desgaste)
• Uso del cliente
(uso fuera de las especificaciones deseadas)
• Entorno externo
(condiciones durante el uso del cliente, por ejemplo, tipo de carretera, clima)
• Interacciones del sistema
(interferencia de otros sistemas)
ANALISIS DE LA FUNCION
Las interacciones de las funciones de varios elementos del sistema deben
demostrarse, por ejemplo, como un árbol de funciones/red, o utilizando la hoja de
formulario DFMEA. El enfoque de las cascadas de análisis de OEM a proveedor de
nivel 1 a proveedor de nivel N.
El objetivo de crear un análisis de árbol de funciones/red o función en la hoja de
formulario DFMEA es incorporar la dependencia técnica entre las funciones. Por lo
tanto, posteriormente admite la visualización de las dependencias de error. Cuando
hay una relación funcional entre funciones vinculadas jerárquicamente
Las interacciones de las funciones de varios elementos del sistema deben
demostrarse, por ejemplo, como un árbol de funciones/red, o utilizando la hoja de
formulario DFMEA. El enfoque de las cascadas de análisis de OEM a proveedor de
nivel 1 a proveedor de nivel N.
El objetivo de crear un análisis de árbol de funciones/red o función en la hoja de
formulario DFMEA es incorporar la dependencia técnica entre las funciones. Por lo
tanto, posteriormente admite la visualización de las dependencias de error. Cuando
hay una relación funcional entre funciones vinculadas jerárquicamente,
ETAPA 4: ANALISIS de FALLA
FUNCTION ANALYSIS (STEP 3)
1. Next Higher Level 2. Focus Element

Function and Function and 3. Next Lower Level Function and
Requirement Requirement Requirement or Characteristic
Commutation system
Convert electrical transports the electrical Brush card body transports forces
energy into current between coil between spring and motor body to hold
mechanical energy pairs of the the brush spring system in x, y, z position
according to electromagnetic (support commutating contact point)
parameterization converter
La numeración de encabezado de columna (1, 2, 3) y la codificación de color se incluyen para

ayudar a mostrar la alineación entre el análisis de estructura y el contenido asociado del análisis
de funciones . En esta sección se trabaja de izquierda a derecha respondiendo a la pregunta:
"¿Cómo se habilita la función de nivel superior mediante funciones de nivel inferior?"
1. Siguiente función y requisito de nivel superior: La función en el ámbito del análisis.
2. Función y requisito del elemento de enfoque:
Función del elemento de sistema asociado (elemento en foco) identificado en el análisis de
estructura.
3. Siguiente función de nivel inferior y requisito o característica: La función del elemento de
componente asociado identificado en el análisis de estructura.
Colaboración entre equipos de ingeniería (sistemas, seguridad y componentes)

Los equipos de ingeniería dentro de la empresa necesitan colaborar para asegurarse
de que la información sea consistente para un proyecto o programa de cliente,
especialmente cuando varios equipos de DFMEA están realizando simultáneamente el
análisis técnico de riesgos. Por ejemplo, un grupo de sistemas podría estar
desarrollando la arquitectura de diseño (estructura) y esta información sería útil para
DFMEA para evitar la duplicación de trabajo. Un equipo de seguridad puede estar
trabajando con el cliente para entender los objetivos y peligros de seguridad. Esta
información sería útil para el DFMEA para garantizar calificaciones de severidad
consistentes para los efectos de falla.
Base para el análisis de fallos

La definición completa de funciones (en palabras positivas) dará lugar a un análisis
completo de fallas del paso 4 porque los posibles fallas son formas en que las
funciones podrían fallar (en palabras negativas)
PROPOSITO
El propósito del análisis de Modo de Fallas de diseño es identificar las causas, modos
y efectos de falla y mostrar sus relaciones para permitir la evaluación de riesgos.
Los principales objetivos de un análisis de fallas de diseño son:
• Establecimiento de la Cadena de Fallas
• Posibles efectos de fallo, modos de falla, causas de falla para cada función del
producto.
• Colaboración entre cliente y proveedor (Efectos de fallo)
• Base para la documentación de fallas en la hoja de formulario FMEA y en el paso
Análisis de Riesgos
• Base para el paso Análisis de Modo de fallas
MODO DE FALLAS
Los modos de fallas de una función se derivan de las descripciones de la función. Hay
varios tipos de modos de falla potenciales, incluyendo, pero no limitado a:
• Pérdida de la función (por ejemplo, inoperable, falla repentinamente)
• Degradación de la función (por ejemplo, pérdida de rendimiento en el tiempo)
• Función intermitente (por ejemplo, la operación se inicia/detiene/inicia al azar)
• Función parcial (por ejemplo, pérdida de rendimiento)
• Función no deseada (por ejemplo, operación en el momento equivocado, dirección
no deseada, rendimiento desigual)
• Exceder la función (por ejemplo, operación por encima del umbral aceptable)
• Función retrasada (por ejemplo, operación después de un intervalo de tiempo no
intencional)
Function derive failures Malfunctions
+
F F F F F F F
0
t t t t t t -
… is on a higher or lower level … execute unintended
… fails … changes over time … intermittent function “unintended time, duration" “unintended stuck at level … wrong
suddenly direction" direction
F = Function t = Time = required Function = performed Function
MODOS DE FALLA
MODO DE FALLA
La descripción de un modo de fallo del sistema y del subsistema se describe en
términos de pérdida o degradación funcional, por ejemplo, girar a la derecha de la
dirección cuando la rueda de mano se mueve a la izquierda, como un ejemplo de una
función no deseada. Cuando sea necesario, se debe incluir el estado de
funcionamiento del vehículo, por ejemplo, la pérdida de asistencia de dirección
durante el arranque o el apagado.
Un modo de fallo de componente/pieza se compone de un sustantivo y una
descripción de fallo, por ejemplo, sello retorcido.
Es fundamental que la descripción del error sea clara y comprensible para la persona
que está destinada a leerlo. Una declaración "no cumplida", "no está bien",
"defectuosa", "rota", etc. no es suficiente.
Se puede asociar más de un Modo de falla a una función. Por lo tanto, el equipo no
debe detenerse tan pronto como se identifique un Modo de falla. Deberían
preguntarse "¿de qué otra manera puede fallar esto?"
DEFINICION DE FALLA
CADENA DEL MODO DE FALLA

Hay tres aspectos diferentes de las fallas analizadas en un FMEA:
• Efecto de la falla (FE)
• Modo de falla (FM)s falla de una función se derivan de las
descripciones de la función. Hay varios
• Causa de falla (FC)
MODO DE
CAUSA o FALLA
EFECTO DE
MECANISMO LA FALLA
Cómo
Qué
Por qué falló?
provocó?
falló?
FOCO DE ANALISIS Qué daño
hizo?
CADENA DEL MODO DE FALLA
Hay tres aspectos diferentes de las fallas analizadas en un FMEA:
• Efecto de la falla (FE)
• Modo de falla (FM)s falla de una función se derivan de las descripciones de la
función. Hay varios
• Causa de falla (FC)
EFECTO DE FALLA
Un efecto de falla se define como la consecuencia de un modo de falla.
Describa los efectos en el siguiente nivel de integración de productos (interno o
externo), el usuario final que es el operador del vehículo (externo) y las regulaciones
gubernamentales (reglamentarias) según corresponda.
Los efectos para el cliente deben indicar lo que el usuario podría notar o experimentar,
incluidos los efectos que podrían afectar a la seguridad. La intención es pronosticar los
efectos de falla consistentes con el nivel de conocimiento del equipo. Un modo de falla
puede tener varios efectos relacionados con clientes internos y externos.
Los efectos pueden ser compartidos por los proveedores y con los proveedores con
subproveedores como parte de la colaboración de diseño.
La severidad de los efectos de falla se evalúa en una escala de uno a diez.
EFECTO DE FALLA
Ejemplos de efectos de falla en el usuario final:
• Sin efecto discernible
• Aspecto deficiente, por ejemplo, cierre antiestético, desvanecimiento de color,
corrosión cosmética
• Ruido, por ejemplo, desalineación, ruido fluido, chirrido/ruido, chirrido y squawk
• Olor desagradable, sensación áspera, aumento de los esfuerzos
• Funcionamiento deteriorado, intermitente, incapaz de operar, incompatibilidad
electromagnética (EMC)
• Fuga externa que resulta en pérdida de rendimiento, operación errática, inestable
• No se puede conducir el vehículo (caminar a casa)
• Incumplimiento de las regulaciones gubernamentales
• Pérdida de la dirección o el frenado
MODO DE FALLA
Un modo de falla se define como la forma en que un elemento podría no cumplir o
entregar la función prevista.
Los modos de falla se derivan de las funciones. Los modos de falla deben describirse
en términos técnicos, y no necesariamente como síntomas perceptibles por el cliente.
Al preparar el DFMEA, supongamos que el diseño se fabricará y ensamblará con la
intención del diseño. Las excepciones se pueden hacer a discreción del equipo cuando
los datos históricos indican que existen deficiencias en el proceso de fabricación.
Algunos ejemplos de modos de fallas de nivel de componente incluyen, entre otros:

NO RECOMENDADO NO RECOMENDADO
Componente agrietado agrietado
Componente deformado deformado
Componente fracturado fracturado
Pieza suelta suelta
Parte oxidada oxidada
Componente pegado pegado
MODO DE FALLA
Algunos ejemplos de modos de falla de nivel de sistema incluyen, entre otros:
• Pérdida completa de líquidos
• Se desconecta demasiado rápido
• No se desconecta
• No transmite par motor
• No tiene torsión completa
• Soporte estructural inadecuado
• Pérdida de apoyo estructural
• Sin señal / Señal intermitente
• Proporciona demasiada presión/señal/voltaje
• Proporciona una presión/señal/voltaje insuficiente
• Incapaz de soportar la carga/temperatura/vibración
CAUSA DE FALLA
Una causa de falla es una indicación de por qué podría ocurrir el modo de falla. La
consecuencia de una causa es el modo de falla. Identifique, en la medida de lo
posible, todas las causas potenciales para cada modo de falla.
Las causas de falla se pueden derivar de los modos de falla de la siguiente función y
requisito de nivel inferior y los factores de ruido potenciales (por ejemplo, de un
diagrama de parámetros).
Los tipos de posibles causas de falla podrían ser, pero no se limitan a:
• Diseño inadecuado para el rendimiento funcional (por ejemplo, material
incorrecto especificado, geometría incorrecta, pieza incorrecta seleccionada para la
aplicación, acabado superficial incorrecto especificado, especificación de viaje
inadecuada, material de fricción inadecuado especificado, capacidad de lubricación
insuficiente, suposición de vida útil de diseño inadecuada, algoritmo incorrecto,
instrucciones de mantenimiento inadecuadas, etc.)
CAUSA DE FALLA
• Interacciones del sistema (por ejemplo, interfaces mecánicas, flujo de fluidos,
fuentes de calor, retroalimentación del controlador, etc.)
• Cambios a lo largo del tiempo (por ejemplo, rendimiento, fatiga, inestabilidad del
material, fluencia, desgaste, corrosión, oxidación química, electromigración,
sobretensión, etc.)
• Diseño inadecuado para ambientes externos (por ejemplo, calor, frío, humedad,
vibración, escombros de carretera, sal de carretera, etc.)
• Error o comportamiento del usuario final (por ejemplo, equipo incorrecto utilizado,
pedal incorrecto utilizado, velocidades excesivas, remolque, tipo de combustible
incorrecto, daños en el servicio, etc.)
• Falta de diseño robusto para la fabricación (por ejemplo, la geometría de la pieza
permite la instalación de piezas hacia atrás o al revés, la pieza carece de
características de diseño distintivas, el diseño del contenedor de envío hace que las
piezas se rasquen o se peguen entre sí, la manipulación de piezas causa daños, etc.)
• Problemas de software (por ejemplo, estado no definido, código/datos dañados)
ANALISIS D FALLAS
Dependiendo de si el análisis se realiza a nivel de sistema, subsistema o componente,
se puede ver una falla como un efecto de falla , un modo de falla o una causa de falla .
Los modos de falla , las causas de falla y los efectos de falla deben coincidir con la
columna correspondiente de la hoja de formulario FMEA.
Por lo tanto, una causa de falla en el OEM se convierte en un modo de falla en un

nivel siguiente (nivel1). Sin embargo, los efectos de falla a nivel de vehículo (según lo
percibido por el usuario final) deben documentarse cuando se conocen, pero no se
asumen. Por lo tanto, se debe considerar la comunicación de acuerdo con la Figura
Las redes de falla pueden ser creadas por la organización que posee varios niveles del
diseño. Cuando varias organizaciones responsables de los diferentes niveles del
diseño, son responsables de comunicar los efectos de falla al siguiente nivel superior
o siguiente inferior según corresponda.
FAILURE ANALYSIS (STEP 4)
1. Failure Effects (FE) to the 3. Failure Cause (FC)

Next Higher Level Element 2. Failure Mode (FM) of the of the Next Lower Element or
and/or End User Focus Element Characteristic
Torque and rotating velocity of the Angle deviation by commutation system Brush card body bends in contact
window lifter motor too low intermittently connects the wrong coils area of the carbon brush
(L1, L3 and L2 instead of L1, L2 and L3)
ANÁLISIS DE FALLOS (PASO 4)

1. Efectos de fallo (FE) al siguiente elemento de nivel superior y/o usuario final
2. Modo de fallo (FM) del elemento de enfoque
3. Causa de fallo (FC) del siguiente elemento inferior o característica
El par y la velocidad de rotación del motor elevador de ventanas demasiado baja
Desviación de ángulo por sistema de conmutación conecta intermitentemente las
bobinas incorrectas (L1, L3 y L2 en lugar de L1, L2 y L3)
3. Causa de fallo (FC):La causa del error asociado con el "Siguiente elemento
inferior o característica" en el análisis de funciones.
COLABORACION CLIENTE PROVEEDOR
El resultado del Análisis de Fallo puede ser revisado por clientes y proveedores antes
del paso análisis de riesgos o después del paso análisis de riesgos basado en acuerdos
con el cliente y la necesidad de compartir con el proveedor.
Base para el análisis de riesgos

La definición completa de posibles FALLAS dará lugar a un análisis de riesgos
completo del paso 5 porque la clasificación de gravedad, ocurrencia y detección se
basa en las descripciones de fallas. El análisis de riesgos puede estar incompleto si los
posibles fallos son demasiado vagos o faltan.
ETAPA 5: ANALISIS de RIESGOS
PROPOSITO
El propósito del Análisis de Riesgos de Diseño es estimar el riesgo mediante la
evaluación de la severidad, la ocurrencia y la detección, y priorizar la necesidad de
acciones.
Los principales objetivos del Análisis de Riesgos de Diseño son:

• Asignación de controles existentes y/o planificados y calificación de fallas
• Asignación de controles de prevención a las causas del fallo
• Asignación de controles de detección a los modos de causas de fallo y/o fallo
• Clasificación de gravedad, ocurrencia y detección para cada cadena de fallas
• Evaluación de la prioridad de acción
• Colaboración entre cliente y proveedor (severidad)
• Base para el paso Optimización
CONTROLES DE DISEÑO
Los controles de diseño actuales son consideraciones probadas que se han
establecido para diseños similares y anteriores. Los documentos de control de diseño
son una base para la robustez del diseño.
Los controles de tipo de prevención y los controles de tipo de detección forman parte
de la biblioteca actual de métodos de verificación y validación.
Los controles de prevención proporcionan información u orientación que se utiliza
como entrada para el diseño. Los controles de detección describen los
procedimientos de validación y validación establecidos que se han demostrado
previamente para detectar el error, en caso de que se produzca. Referencias
específicas a características de diseño que actúan para evitar un fallo
.
CONTROLES DE PREVENCION ACTUALES
Los controles de prevención actuales describen cómo se mitiga una posible causa que
da lugar al modo de error mediante actividades existentes y planificadas. Describen la
base para determinar la calificación de ocurrencia. Los controles de prevención se
relacionan con el requisito de rendimiento.
Para los artículos que se han diseñado fuera de contexto y se compran como artículos
de stock o catálogo de un proveedor, el control de prevención debe documentar una
referencia específica a cómo el artículo cumple el requisito. Esto puede ser una
referencia a una hoja de especificaciones en un catálogo.
Los controles actuales de la prevención deben describirse de forma clara y exhaustiva,
con referencias citadas. Si es necesario, esto se puede hacer por referencia a un
documento adicional. Enumerar un control como "material probado" o "lecciones
aprendidas" no es una indicación lo suficientemente clara.
El equipo de DFMEA también debe considerar el margen de seguridad en el diseño
como un control de prevención.
Ejemplos de controles de prevención actuales:
• Directivas CEM adheridas, Directiva 89/336/CEE
• Diseño del sistema según simulación, cálculo de tolerancia y Procedimiento -
análisis de conceptos para establecer requisitos de diseño
• Estándar de diseño publicado para una clase de rosca
• Especificación del tratamiento térmico en el dibujo
• Especificaciones de rendimiento del sensor.
• Redundancia mecánica (a prueba de fallos)
• Diseño para la capacidad de prueba
• Estándares de diseño y materiales (internos y externos)
• Documentación (por ejemplo, registros de mejores prácticas, lecciones aprendidas,
etc.) de diseños similares
• A prueba de errores (diseño Poka-Yoke, es decir, la geometría de la pieza evita una
orientación incorrecta)

• Sustancialmente idéntico a un diseño que fue validado para una aplicación anterior,
con historial de rendimiento documentado. (Sin embargo, si se cambia el ciclo de
trabajo o las condiciones de funcionamiento, el artículo de arrastre requiere una
revalidación para que el control de detección sea relevante.)
• Blindaje o protecciones que mitiguen el desgaste mecánico potencial, la exposición
térmica o EMC
• Conformidad con las mejores prácticas
Después de completar las acciones preventivas, la ocurrencia es verificada por los
Controles de Detección.
CONTROLES DE DETECCION
Los controles de detección de corriente detectan la existencia de una causa de error o
el modo de error antes de que el elemento se libere para producción.
Los controles de detección actuales que se enumeran en la FMEA representan
actividades planificadas (o actividades ya completadas), no actividades potenciales
que pueden no llevarse a cabo realmente.
Los controles de detección de corriente deben describirse de forma clara y
exhaustiva. Enumerar un control como "Prueba" o "Prueba de laboratorio" no es una
indicación lo suficientemente clara de un control de detección. Las referencias a
pruebas, planes de prueba o procedimientos específicos deben citarse según
corresponda, para indicar que el equipo de fMEA ha determinado que la prueba
detectará realmente el modo de fallo o causa, si se produce (por ejemplo, Prueba No
1234 Prueba de presión de ráfaga, párrafo 6.1).
Ejemplos de controles de detección de corriente:
• Comprobación de la función
• Prueba de ráfaga
• Prueba ambiental
• Prueba de conducción
• Prueba de resistencia
• Rango de estudios de movimiento
• Hardware en bucle
• Software en bucle
• Diseño de experimentos
• Mediciones de laboratorio de salida de tensión
Todos los controles que conducen a una detección de la causa del error, o el modo de
error se introducen en la columna "Controles de detección actuales"
Los controles de detección de corriente detectan la existencia de una causa de error o
el modo de error antes de que el elemento se libere para producción.
Los controles de detección actuales que se enumeran en la FMEA representan
actividades planificadas (o actividades ya completadas), no actividades potenciales
que pueden no llevarse a cabo realmente.
Los controles de detección de corriente deben describirse de forma clara y
exhaustiva. Enumerar un control como "Prueba" o "Prueba de laboratorio" no es una
indicación lo suficientemente clara de un control de detección. Las referencias a
pruebas, planes de prueba o procedimientos específicos deben citarse según
corresponda, para indicar que el equipo de fMEA ha determinado que la prueba
detectará realmente el modo de fallo o causa, si se produce (por ejemplo, Prueba No
1234 Prueba de presión de ráfaga, párrafo 6.1).
CONFIRMACION DE LOS CONTROLES DE PREVENCION /DETECCION

Debe confirmarse la eficacia de los controles actuales de prevención y detección. Esto
se puede hacer durante las revisiones de desmontaje de validación. Dicha
confirmación puede documentarse dentro del DFMEA, o dentro de otros documentos
del proyecto, según corresponda, de acuerdo con el procedimiento normal de
desarrollo de productos del equipo. Es posible que se necesiten medidas adicionales
si se demuestra que los controles no son eficaces
CONFIRMACION DE LOS CONTROLES DE PREVENCION /DETECCION
EVALUACIONES
Cada modo de fallo, relación de causa y efecto se evalúa para estimar el riesgo.
Existen criterios de calificación para la evaluación del riesgo:
Gravedad (S): representa la gravedad del efecto de fallo
Ocurrencia (O): significa la ocurrencia de la detección de la causa de falla (D): significa
la detección de la falla ocurrida
causa y/o modo de fallo.
Los números de evaluación del 1 al 10 se utilizan para S, O y D respectivamente,

donde 10 representa la contribución de mayor riesgo
SEVERIDAD (S)
La clasificación de gravedad (S) es una medida asociada con el efecto de error más
grave para un modo de error determinado de la función que se está evaluando. La
clasificación se utiliza para identificar prioridades relativas al alcance de un FMEA
individual y se determina sin tener en cuenta la ocurrencia o detección.
La gravedad debe estimarse utilizando los criterios de la tabla de gravedad D1. La
tabla se puede aumentar para incluir ejemplos específicos del producto. El equipo del
proyecto FMEA debe acordar un criterio de evaluación y un sistema de calificación,
que sea coherente incluso si se modifica para el análisis de diseño individual.
Las evaluaciones de gravedad de los efectos de fallo deben ser transferidas por el
cliente al proveedor, según sea necesario.
Product General Evaluation Criteria Severity (S)
Blank until
Potential Failure Effects rated according to the criteria below. filled in by user
Corporate or
S Effect Severity criteria Product Line
Examples
Affects safe operation of the vehicle and/or other

10 vehicles, the health of driver or passenger(s) or road
Very
users or pedestrians.
High
9 Noncompliance with regulations.
8 Loss of primary vehicle function necessary for normal
driving during expected service life.
High
7 Degradation of primary vehicle function necessary for
normal driving during expected service life.
6 Loss of secondary vehicle function.
5 Degradation of secondary vehicle function.
Moderate
4 Very objectionable appearance, sound, vibration,
harshness, or haptics.
3 Moderately objectionable appearance, sound,

vibration, harshness, or haptics.
Low
2 Slightly objectionable appearance, sound, vibration,
harshness, or haptics.
1 Very low No discernible effect.
OCURRENCIA (O)
La calificación De ocurrencia (O) es una medida de la eficacia del control de
prevención, teniendo en cuenta los criterios de calificación.
Las clasificaciones de ocurrencias deben estimarse utilizando los criterios de la Tabla
de Ocurrencias D2. La tabla se puede aumentar para incluir ejemplos específicos del
producto. El equipo del proyecto FMEA debe acordar un criterio de evaluación y un
sistema de calificación, que sea coherente, incluso si se modifica para el análisis de
diseño individual (por ejemplo, automóviles de pasajeros, camiones, motocicletas,
etc.).
El número de calificación de Ocurrencia es una calificación relativa dentro del alcance
de la FMEA y puede no reflejar la ocurrencia real.
La clasificación Ocurrencia describe el potencial de la causa de error en el
funcionamiento del cliente, según la tabla de clasificación, teniendo en cuenta los
resultados de los controles de detección ya completados.
La experiencia, los manuales de datos, las bases de datos de garantía u otras
experiencias en el campo de productos comparables, por ejemplo, se pueden
consultar para el análisis de los números de evaluación.
Cuando las causas de falla sortean para su ocurrencia, se realiza teniendo en cuenta
una estimación de la eficacia del control de prevención actual. La precisión de esta
calificación depende de qué tan bien se ha descrito el control de prevención
OCURRENCIA (O)
Preguntas como las siguientes pueden ser útiles para un equipo al intentar
determinar la calificación de Ocurrencia apropiada:
• ¿Cuál es el historial de servicios y la experiencia de campo con componentes,
subsistemas o sistemas similares?
• ¿El artículo es un producto de arrastre o similar a un artículo de nivel anterior?
• ¿Qué tan significativos son los cambios de un elemento de nivel anterior?
• ¿El artículo es completamente nuevo?
• ¿Qué es la aplicación o cuáles son los cambios ambientales?
• ¿Se ha utilizado un análisis de ingeniería (por ejemplo, fiabilidad) para estimar la
tasa de ocurrencia comparable esperada para la aplicación?
• ¿Se han puesto en marcha controles de prevención?
• ¿Se ha demostrado la robustez del producto durante el proceso de desarrollo del
producto?
Occurrence Potential (O) for the Product
Potential Failure Causesratedaccording tothecriteriabelow. Consider Product Experience Blank until
and Prevention Controls when determining the best Occurrence estimate (Qualitative filled in by
rating). user
Prediction of Corporateor
O Failure Cause Occurrence criteria - DFMEA ProductLine
Occurring Examples
Firstapplication ofnewtechnologyanywhere withoutoperating
experienceand/orunderuncontrolled operatingconditions.No
product verification and/or validationexperience.
1 Extremely high
0 Standards do not exist and best practices have not yet been
determined. Prevention controls not able to predict field
performance or do not exist.
First use of design with technical innovations or materials within the
company. New application or change induty cycle / operating
conditions. Noproductverification and/or validation experience.
9
Prevention controls nottargeted toidentify performance to specific

requirements.
Very high First use of design with technical innovations or materials ona new
application. New application or change in duty cycle / operating
conditions.Noproductverification and/or validation experience.
8
Fewexistingstandards andbestpractices, notdirectly applicable for
this design. Prevention controls not a reliable indicator of field
performance.
New design basedon similar technology and materials. New
application or change in duty cycle / operating conditions. No
product verification and/or validation experience.
7
Standards, best practices, and design rules apply to the baseline
design,butnottheinnovations. Prevention controls provide limited
High indication of performance

Similar to previous designs, using existing technology and
materials. Similar application, with changes in duty cycle or
operating conditions. Previous testing or field experience.
6
Standards and design rules exist but are insufficient to ensure
thatthe failure cause will notoccur. Prevention controls provide some
ability to prevent a failurecause.
Occurrence Potential (O) for the Product
PotentialFailureCausesratedaccordingtothecriteriabelow.ConsiderProduct Blank
Experience and Prevention Controls when determining the best Occurrence until
estimate (Qualitative rating). filled in
by user
Prediction of Corporateor
O Failure Occurrence criteria - DFMEA ProductLine
Cause Examples
Occurring
Detailchangestopreviousdesign,usingproventechnologyand
materials.Similarapplication,dutycycleoroperatingconditions.
Previous testingorfield experience,ornewdesignwithsometest
experience related to thefailure.
5
Designaddresseslessonslearnedfrompreviousdesigns.Best
Practices re-evaluated for this design but have not yet been
Moderate proven.Preventioncontrolscapableoffindingdeficienciesinthe
productrelated tothefailure causeandprovide someindication
of performance.
Almostidenticaldesignwithshort-termfieldexposure.Similar
application, with minor change in duty cycle or operating
conditions. Previous testing or field experience.
4
Predecessordesignandchangesfornewdesignconformtobest
practices, standards, and specifications. Prevention controls
capableoffinding deficiencies intheproduct relatedtothefailure
cause and indicate likely design conformance.
Detailchangestoknowndesign(sameapplication, withminor
changeindutycycleoroperating conditions)andtestingorfield
experience under comparable operating conditions, or new
design with successfully completed test procedure.
3 Low
Designexpected toconform toStandards andBestPractices,

consideringLessonsLearnedfrompreviousdesigns.Prevention
controls capableoffinding deficiencies intheproductrelated to
thefailure causeandpredictconformanceofproductiondesign.
Almostidenticalmaturedesignwithlongtermfieldexposure. Same
application,withcomparabledutycycleandoperating conditions.
Testing or field experience under comparable operating
conditions.
2 Very low
Design expected to conform to standards and best practices,
considering Lessons Learned from previous designs, with
significantmarginofconfidence. Preventioncontrolscapableof
finding deficiencies inthe productrelatedtothe failure causeand
indicate confidence in design conformance.
1 Extremely Failureeliminatedthroughpreventioncontrolandfailure causeis not
low
possible by design
Product Experience: History of product usage within the company (Novelty of design, application or use case).
Results of already completed detection controls provide experience with the design.
Prevention Controls: Use of Best Practices for product design, Design Rules, Company Standards, Lessons Learned, Industry
Standards, Material Specifications, Government Regulations and effectiveness of prevention orientedanalyticaltoolsincluding
ComputerAidedEngineering,MathModeling,SimulationStudies,ToleranceStacks
and Design Safety Margins
Note: O 10, 9, 8, 7 can drop based on product validation activities.
DETECCION (D)
La clasificación de detección (D) es una medida estimada de la eficacia del control de
detección para demostrar de forma fiable la causa de error o el modo de error antes
de que el elemento se libere para producción. La clasificación de detección es la
clasificación asociada con el control de detección más eficaz.
La detección es una calificación relativa, dentro del alcance de la FMEA individual y se
determina sin tener en cuenta la gravedad o la ocurrencia. La detección debe
estimarse utilizando los criterios del cuadro D3. Esta tabla puede aumentarse con
ejemplos de métodos de detección comunes utilizados por la empresa. El equipo del
que sea coherente, incluso si se modifica para el análisis individual del producto.
La clasificación de detección es inicialmente una predicción de la eficacia de cualquier

control aún no probado. La eficacia se puede verificar y reevaluar una vez completado
el control de detección. Sin embargo, la finalización o cancelación de un control de
detección (como una prueba) también puede afectar a la estimación de la ocurrencia.
DETECCION (D)
Al determinar esta estimación, deben tenerse en cuenta cuestiones como las
siguientes:
• ¿Qué prueba es más eficaz para detectar la causa de falla o el modo de fallo?
• ¿Cuál es el perfil de uso / ciclo de trabajo requerido para detectar el fallo?
• ¿Qué tamaño de muestra se requiere para detectar el fallo?
• ¿Se ha demostrado el procedimiento de prueba para detectar este modo de
causa/fallo?
Detection Potential (D) for the Validation of the Product Design
Blank until
Detection Controls rated according to Detection Method Maturity and Opportunity for filled in by
Detection. user
Ability to Opportunity for Corporate or

D Detect Detection Method Maturity Detection Product Line
Examples
10 Test procedure yet to be developed. Test method not

defined
Very low Test method not designed specifically to Pass-Fail, Test-to-
9 detect failure mode or cause. Fail, Degradation
Testing
Pass-Fail, Test-to-
8 New test method; not proven. Fail, Degradation
Low Testing
7 Proven test method for verification of Pass-Fail Testing

functionality or validation of performance,
6 quality, reliability and durability; planned Test-to-Failure
timing is later in the product development
Moderate cycle such that test failures may result in
production delays for re-design and/or re- Degradation
5 Testing
tooling.
4 Proven test method for verification of Pass-Fail Testing

functionality or validation of performance,
3 quality, reliability and durability; planned Test-to-Failure
High timing is sufficient to modify production
Degradation
tools before release for production.
2 Testing
Ver Prior testing confirmed that failure mode or cause cannot occur,
1 y or detection methods proven to always detect the failure mode or
high failure cause.
PRIORIDAD DE ACCION (AP)

Una vez que el equipo ha completado la identificación inicial de los modos de error,
los efectos de error, las causas de error y los controles, incluidas las clasificaciones de
gravedad, ocurrencia y detección, deben decidir si se necesitan más esfuerzos para
reducir el riesgo. Debido a lalimitaciones de recursos, tiempo, tecnología y otros
factores, deben elegir la mejor manera de priorizar estos esfuerzos.
El método Action Priority (AP) se introduce en este manual. Representa las 1000
combinaciones posibles de S, O y D. Fue creado para dar más énfasis en la gravedad
primero, después la ocurrencia, después la detección. Esta lógica sigue la intención de
prevención de errores de FMEA. La tabla AP ofrece una prioridad sugerida alta-media-
baja para la acción. Las empresas pueden utilizar un único sistema para evaluar las
prioridades de acción en lugar de varios sistemas requeridos de varios clientes.

Las matrices de riesgo pueden representar combinaciones de S y O, S y D, y O y D.
Estas matrices proporcionan una representación visual de los resultados del análisis y
pueden utilizarse como insumo para la priorización de acciones basadas en criterios
establecidos por la empresa no incluidos en esta publicación.
Puesto que la tabla AP fue diseñada para trabajar con las tablas de gravedad,
ocurrencia y detección proporcionadas en este manual, si la organización elige
modificar las tablas S, O, D, para productos, procesos o proyectos específicos, la tabla
AP también debe ser cuidadosamente Revisado.
Prioridad alta (H): Máxima prioridad para la revisión y la acción.
El equipo debe identificar una acción adecuada para mejorar los controles de
prevención y/o detección o justificar y documentar por qué los controles actuales son
adecuados.
Medio de Prioridad (M): Prioridad media para revisión y acción.
El equipo debe identificar las acciones apropiadas para mejorar los controles de
prevención y/o detección, o, a discreción de la empresa, justificar y documentar por
qué los controles son adecuados.
Prioridad baja (L): Baja prioridad para revisión y acción.
El equipo podría identificar acciones para mejorar los controles de prevención o
detección
Se recomienda que los posibles efectos de error de gravedad 9-10 con prioridad de
acción alta y media, como mínimo, sean revisados por la administración, incluidas
las acciones recomendadas que se realizaron.
Esta no es la priorización de alto, medio o bajo riesgo, es la priorización de las
acciones para reducir el riesgo.
Action Priority (AP) for DFMEA and PFMEA
Action Priority isbasedoncombinations ofSeverity,Occurrence,andDetection ratingsin order to prioritize actions for riskreduction. Blank until
filled in byuser
Prediction of ACTION
Effect S Failure Cause O Ability to Detect D PRIORITY (AP) Comments
Occurring
Low - Very low 7-10 H
Very high 8-10 Moderate 5-6 H

High 2-4 H
Very high 1 H
Moderate 5-6 H
High 6-7
Product or Plant Effect 9-10 High 2-4 H
Very high Very high 1 H
Moderate 5-6 H
Moderate 4-5
High 2-4 H
Very high 1 M
Moderate 5-6 M
Low 2-3
High 2-4 L
Very high 1 L
Very low 1 Very high - Very low 1-10 L

Moderate 5-6 H
Very high 8-10
High 2-4 H
Very high 1 H
Moderate 5-6 H
High 6-7
Product or Plant Effect High 2-4 H
High 7-8 Very high 1 M
Moderate 5-6 M
Moderate 4-5
High 2-4 M
Very high 1 M
Low - Very low 7-10 M
Moderate 5-6 M
Low 2-3
High 2-4 L
Very high 1 L
Occurring

Moderate 5-6 H
Very high 8-10
High 2-4 M
Very high 1 M
Moderate 5-6 M
High 6-7
High 2-4 M
Product or
Very high 1 L
Plant Effect
4-6
Moderate Low - Very low 7-10 M
Moderate 5-6 L
Moderate 4-5
High 2-4 L
Very high 1 L
Low - Very low 7-10 L
Moderate 5-6 L
Low 2-3
High 2-4 L
Very high 1 L

Moderate 5-6 M
Very high 8-10
High 2-4 L
Very high 1 L
Moderate 5-6 L
High 6-7
High 2-4 L
Product or
Very high 1 L
PlantEffect Low
2-3
Moderate 5-6 L
Moderate 4-5
High 2-4 L
Very high 1 L
Moderate 5-6 L
Low 2-3
High 2-4 L
Very high 1 L
No discernible Effect 1 Very low - 1-10 Very high - Very low 1-10 L
Very high
COLABORACION CLIENTE PROVEEDOR SEVERIDAD

El resultado del Análisis de Riesgos crea la comprensión mutua del riesgo técnico
entre clientes y proveedores. Los métodos de colaboración van desde informes
verbales hasta informes formales. La cantidad de información compartida se basa en
las necesidades de un proyecto, la política de la empresa, los acuerdos contractuales,
etc. La información compartida depende de la colocación de la empresa en la cadena
de suministro.
A continuación se enumeran algunos ejemplos.
1. El OEM puede comparar las funciones de diseño, los efectos de falla y la gravedad
de un DFMEA a nivel de vehículo con el proveedor de nivel 1 DFMEA.
2. El proveedor de nivel 1 puede comparar las funciones de diseño, los efectos de fallo
y la gravedad de un subsistema DFMEA con el proveedor de nivel 2 que tiene la
responsabilidad de diseño.
3. El proveedor de nivel 1 comunica la información necesaria sobre las características
del producto en los dibujos y/o especificaciones de los productos u otros medios,
incluida la designación de características y gravedad estándar o especiales. Esta
información se utiliza como entrada para el proveedor de nivel 2 PFMEA, así como
para el PFMEA interno del nivel 1. Cuando el el equipo de diseño comunica el riesgo
asociado de hacer que las características del producto fuera de especificación que el
equipo de proceso puede construir en el nivel adecuado de controles de prevención y
detección en la fabricación. Referencia PFMEA Sección 3.4 para más información
Base para la optimización

La salida de los pasos 1, 2, 3, 4 y 5 del proceso FMEA de 7 pasos se utiliza para
determinar si se necesita una acción adicional de diseño o prueba. Las revisiones de
diseño, las revisiones de los clientes, las revisiones de gestión y las reuniones de
equipo multifuncionales conducen a la optimización del paso 6.
ETAPA 6: OPTIMIZACION
PROPOSITO
El propósito de la Optimización de Diseño es determinar las acciones para mitigar el
riesgo y evaluar la eficacia de esas acciones.
Los principales objetivos de una optimización de diseño son:
• Identificación de las acciones necesarias para reducir los riesgos
• Asignación de responsabilidades y plazos para la implementación de la acción
• Implementación y documentación de las medidas adoptadas, incluida la
confirmación de la eficacia de las acciones implementadas y la evaluación del riesgo
después de las medidas adoptadas
• Colaboración entre el equipo de FMEA, la dirección, los clientes y los proveedores
con respecto a posibles fallas
• Base para el refinamiento de los requisitos del producto y los controles de
prevención y detección
PROPOSITO
El objetivo principal de design Optimization es desarrollar acciones que reduzcan el
riesgo y aumenten la satisfacción del cliente mejorando el diseño. En este paso, el
equipo revisa los resultados del análisis de riesgos y asigna acciones para reducir la
probabilidad de que se produzca la causa de error o aumentar la robustez del control
de detección para detectar la causa de error o el modo de error. También se pueden
asignar acciones que mejoren el diseño, pero no necesariamente reduzcan la
calificación de evaluación de riesgos. Las acciones representan el compromiso de
tomar una acción específica, medible y alcanzable, no acciones potenciales que nunca
pueden implementarse. Las acciones no están pensadas para ser utilizadas para
actividades que ya están planificadas, ya que están documentadas en los Controles de
Prevención o Detección y ya se consideran en el análisis de riesgos inicial.
Si el equipo decide que no es necesario realizar más acciones, "No se necesita
ninguna otra acción" en el campo Comentarios para mostrar que se ha completado el
análisis de riesgos.
El DFMEA debe utilizarse para evaluar los riesgos técnicos relacionados con la mejora
continua del diseño.
PROPOSITO
La optimización es más eficaz en el siguiente orden:
• Modificaciones de diseño para eliminar o mitigar un efecto de fallo (FE).
• Modificaciones de diseño para reducir la ocurrencia (O) de la causa de falla (FC)
• Aumente la capacidad de detección (D) para la causa de error (FC) o el modo de
fallo (FM).
•]
En el caso de modificaciones de diseño, todos los elementos de diseño afectados se
evalúan de nuevo.
En el caso de modificaciones de concepto, se revisan todos los pasos de la FMEA para
las secciones afectadas. Esto es necesario porque el análisis original ya no es válido ya
que se basaba en un concepto de diseño diferente.
ASIGNACION DE RESPONSABILIDADES
Cada acción debe tener un individuo responsable y una fecha de finalización objetivo
(TCD) asociada.
La persona responsable garantiza que se actualice el estado de la acción. Si se
confirma la acción, esta persona también es responsable de la implementación de la
acción.
La fecha de finalización real para las acciones preventivas y de detección se
documenta, incluida la fecha en que se implementan las acciones.
Las fechas de finalización objetivo deben ser realistas (es decir, de acuerdo con el plan
de desarrollo del producto, antes de la validación del proceso, antes del inicio de la
producción).
Estado de las acciones
Niveles sugeridos para el estado de las acciones:
Abierto: No se ha definido ninguna acción.
Decisión pendiente (opcional), La acción ha sido definida, pero aún no se ha decidido.
Se está creando un documento de decisión.
Implementación pendiente (opcional)
La acción se ha decidido, pero aún no se ha aplicado.
Completado
Se han implementado acciones completadas y se ha demostrado y documentado su
eficacia. Se ha realizado una evaluación final.
No implementado
El estado No implementado se asigna cuando se toma una decisión de no
implementar una acción. Esto puede ocurrir cuando los riesgos relacionados con las
limitaciones prácticas y técnicas están más allá de las capacidades actuales.
La FMEA no se considera "completa" hasta que el equipo evalúa la prioridad de
acción de cada elemento y acepta el nivel de riesgo o documenta el cierre de todas
las acciones.
Si "No se toma ninguna acción", entonces la prioridad de acción no se reduce y el
riesgo de falla se lleva adelante en el diseño del producto. Las acciones son bucles
abiertos que deben cerrarse por escrito.
Evaluación de la eficacia de la acción

Cuando se ha completado una acción, se vuelven a evaluar los valores de Ocurrencia
y Detección y se puede determinar una nueva Prioridad de Acción.
La nueva acción recibe una calificación preliminar de Prioridad de Acción como
predicción de efectividad.
Sin embargo, el estado de la acción sigue siendo "pendiente de aplicación" hasta que
se haya probado la eficacia. Una vez finalizadas las pruebas, la calificación preliminar
debe ser confirmada o adaptada, cuando se indique. A continuación, el estado de la
acción cambia de "implementación pendiente" a "completado".
La reevaluación debe basarse en la eficacia de las acciones preventivas y de detección
tomadas y los nuevos valores se basan en las definiciones de las tablas de clasificación
Design FMEA Occurrence and Detection.
mejora continua
El DFMEA sirve como un registro histórico para el diseño. Por lo tanto, la gravedad,
ocurrencia y detección originales (S, O,D) los números deben ser visibles o, como
mínimo, disponibles y accesibles como parte del historial de versiones. El análisis
completado se convierte en un repositorio para capturar la progresión de las
decisiones de diseño y los refinamientos de diseño. Sin embargo, las clasificaciones S,
O, D originales pueden modificarse para los DFMEA genéricos, de base o genéricos
porque la información se utiliza como punto de partida para un análisis específico de
la aplicación.
DFMEA RISK ANALYSIS (STEP 5) DFMEA OPTIMIZATION (STEP 6)
Current Detection
Current Prevention
Controls (DC) of DFMEA
Action Taken with Pointer to Evidence

Control (PC) of FC
FC or FM Detection Action
Detection (D) of FC/FM
Responsible Person's Name
Status
DFMEA Preventive Action
Target Completion Date

Code (Optional)
Occurrence (O) of FC
Completion Date
Occurrence (O)
Detection (D)
Severity (S)
DFMEA AP
Filter DFMEA AP
Simulation of dynamic 2 Sample test: measuring the 2 L None Final product test: Test Engineer Mr. dd.mm. yyyy planned 6 2 1 L
forces on brush card elastics and plastic measuring the Max Mueller
body acc. deformation effects of current under worst
FEM 6370 brush card body acc. test case conditions acc.
spec. Test spec.
MRJ82/60 MRJ1140
Colaboración entre el equipo de FMEA, la Administración, los Clientes y los
Proveedores con respecto a posibles fallos
La comunicación entre el equipo, la dirección, los clientes y los proveedores de FMEA
durante el desarrollo del análisis técnico de riesgos y/o cuando el DFMEA está
inicialmente completo reúne a las personas para mejorar su comprensión de las
funciones y fallos del producto. De esta manera, hay una transferencia de
conocimiento que promueve la reducción de riesgos
ETAPA 7 DOCUMENTACION DE
RESULTADOS
PROPOSITO
El propósito del paso De documentación de resultados es resumir y comunicar los
resultados de la actividad FMEA.
Los principales objetivos de la Documentación de Resultados de Diseño son:
• Comunicación de resultados y conclusiones del análisis
• Establecimiento del contenido de la documentación
• Documentación de las medidas adoptadas, incluida la confirmación de la eficacia de

las acciones implementadas y la evaluación del riesgo después de las medidas
adoptadas
• Comunicación de las medidas adoptadas para reducir los riesgos, incluso dentro de
la organización, y con clientes y/o proveedores según corresponda
• Registro de análisis de riesgos y reducción de riesgos a niveles aceptables
RESULTADOS
REPORTE DEL AMEF
El informe puede utilizarse con fines de comunicación dentro de una empresa o entre
empresas. El informe no pretende reemplazar las revisiones de los detalles de DFMEA
cuando así lo solicite la administración, los clientes o los proveedores. Se pretende ser
un resumen para que el equipo de DFMEA y otros confirmen la finalización de cada
una de las tareas y revisen los resultados del análisis.
Es importante que el contenido de la documentación cumpla con los requisitos de la
organización, el lector previsto y las partes interesadas pertinentes. Los detalles
podrán acordarse entre las partes. De este modo, también se garantiza que todos los
detalles del análisis y de la propiedad intelectual permanezcan en la empresa en
desarrollo.
El diseño del documento puede ser específico de la empresa. Sin embargo, el informe
debe indicar el riesgo técnico de fracaso como parte del plan de desarrollo y los hitos
del proyecto.
REPORTE DEL AMEF
RESULTADOS
El contenido puede incluir lo siguiente:
A. Una declaración de estado final en comparación con las metas originales
establecidas en el Plan de Proyecto 1.5
1. Intención de FMEA – Propósito de este FMEA?
2. FMEA Timing – FMEA fecha de vencimiento?
3. Equipo FMEA – Lista de participantes?
4. Tarea FMEA - ¿Alcance de esta FMEA?
5. Herramienta FMEA – ¿Cómo llevamos a cabo el método de análisis utilizado?
B. Un resumen del alcance del análisis e identificar las novedades.
C. Un resumen de cómo se desarrollaron las funciones.
D. Un resumen de al menos los errores de alto riesgo determinados por el equipo y
proporcionar una copia de las tablas de clasificación S/O/D específicas y el método de
priorización del método de acción (por ejemplo, tabla de prioridad de acción).
E. Un resumen de las acciones tomadas y/o planeadas para abordar los fallos de alto
riesgo, incluido el estado de esas acciones.
RESULTADOS
REPORTE DEL AMEF

F. Un plan y compromiso de tiempo para las acciones de mejora de la FMEA en curso.
a. Compromiso y calendario para cerrar acciones abiertas
b. b. Compromiso de revisar y revisar el DFMEA durante la producción en masa
para garantizar la exactitud e integridad del análisis en comparación con el diseño
de producción (por ejemplo, revisiones provocadas a partir de cambios de
diseño, acciones correctivas, etc., basadas en los procedimientos de la empresa ).
(Consulte la sección 1.4 Caso 3 revisiones de FMEA)
c. c. Compromiso de capturar "cosas que han ido mal" en los DFMEA de la
fundación en beneficio de la reutilización del análisis futuro, cuando
corresponda. Consulte la sección 1.3.6 Fundación y FMEA familiares)
AMEF DE PROCESO ETAPA 1 : PREPARACION Y PLANIFICACION
PROPOSITO:
El propósito del Paso de Planificación y Preparación de Procesos es describir qué
productos/procesos deben incluirse o excluirse para su revisión en el proyecto
PFMEA.
El proceso tiene en cuenta que todos los procesos dentro de la instalación pueden
ser analizados o reanalizados utilizando PFMEA. Este proceso permite a una
organización revisar todos los procesos a un alto nivel y hacer una determinación
final para la cual se analizarán los procesos. La ventaja general de Preparación es
centrar los recursos en los procesos con la mayor prioridad.
PREPARACION
Los principales objetivos del Paso de Planificación y Preparación de Procesos son:
• Plan de proyecto: InTent, Timing, Team, Tasks, Tools (5T)
• Identificación de FMEA de referencia con las lecciones aprendidas
• Base para el paso Análisis de estructura
La identificación del proyecto PFMEA incluye una comprensión clara de lo que debe
evaluarse. Esto implica un proceso de toma de decisiones para definir los PFMEA que
se necesitan para un programa de cliente. Lo que debe excluir puede ser tan
importante como qué incluir en el análisis.
PREPARACION
Identificación y Límites del Proyecto PFMEA
A continuación se presentan algunas preguntas básicas que ayudan a identificar proyectos PFMEA.
• ¿Qué nos está comprando el cliente?
• ¿Existen nuevos requisitos?
• ¿Qué procesos/elementos específicos causan un riesgo al impartir el requisito/característica?
• ¿El cliente o la empresa requiere un PFMEA?
• ¿Hacemos el producto y tenemos control de diseño?
• ¿Compramos el producto y todavía tenemos control de diseño?
• ¿Compramos el producto y no tenemos control de diseño?
• ¿Quién es responsable del diseño de la interfaz?
• ¿Necesitamos un sistema, subsistema, componente u otro nivel de análisis?
Las respuestas a estas preguntas y otras definidas por la empresa ayudan a crear la lista de proyectos
DFMEA necesarios. La lista de proyectos PFMEA garantiza una dirección, un compromiso y un enfoque
coherentes.
Lo siguiente puede ayudar al equipo a definir los límites de PFMEA, según esté disponible:
• Requisitos legales
• Requisitos técnicos
PREPARACION
• Deseos/necesidades/expectativas del cliente (clientes externos e internos)

• Especificación de requisitos
• Diagramas (Bloque/Límite/Sistema)
• Esquemas, dibujos y/o modelos 3D
• Lista de materiales (BOM), Evaluación de riesgos
• FMEA anterior para productos similares
• Requisitos de corrección de errores, Diseño para la fabricación y montaje (DFM/A)
• Implementación de funciones de calidad QFD
La preparación debe establecerse al inicio del proceso para asegurar una dirección y enfoque coherentes,
por ejemplo, una línea de proceso completa, elemento de proceso / elemento de proceso.
Los procesos dentro de la planta que pueden afectar la calidad del producto y pueden ser considerados
para el análisis PFMEA incluyen: procesos de recepción, almacenamiento de piezas y materiales, entrega de
productos y materiales, fabricación, montaje, embalaje, etiquetado, producto completado transporte,
almacenamiento, procesos de mantenimiento, procesos de detección y procesos de reelaboración y
reparación, etc.
Una vez que se conozca el proyecto DFMEA, se debe elaborar un plan para la
ejecución del PFMEA.
Se recomienda utilizar el método 5T (Intención, Tiempo, Equipo, Tareas, Herramienta)
como se describe en la sección 1.5 de este manual. La organización también debe
PREPARACION
tener en cuenta el desarrollo de los métodos y/o entregables aplicables de los
requisitos específicos del cliente (RSR) en el plan del proyecto. El plan para el PFMEA
ayuda a la empresa a ser proactiva en el inicio temprano de la PFMEA. Las actividades
de DFMEA (proceso de 7 pasos) deben incorporarse al plan general del proyecto.
Identificación de la línea de base PFMEA
arte de la preparación para la realización de la PFMEA es saber qué
información ya está disponible que puede ayudar al equipo multifuncional.
Esto incluye el uso de una base PFMEA (descrita en la Sección 1.3), producto
similar PFMEA, o base de producto PFMEA. La fundación PFMEA es un
proceso de cimentación especializado FMEA para productos que
generalmente contienen límites de productos comunes o consistentes y
funciones relacionadas. Para un nuevo producto en la fundación, añadido a
esta fundación PFMEA serían los nuevos componentes y funciones
específicas del proyecto para completar el nuevo producto PFMEA. Las
adiciones para el nuevo producto pueden estar en la propia fundación
PFMEA, o en un nuevo documento con referencia a la familia o fundación
original PFMEA. Si no hay línea de base disponible, entonces el equipo
desarrollará un nuevo PFMEA.
Encabezado del DFMEA
PREPARACION
Durante la preparación, se debe rellenar la cabecera del documento PFMEA.
El encabezado puede modificarse para satisfacer las necesidades de la
organización e incluye parte de la información básica de la preparación de
PFMEA de la siguiente manera:
Nombre de la empresa: Nombre de la empresa responsable de PFMEA

Ubicación de ingeniería: Ubicación geográfica
Nombre del cliente: Nombre del cliente o producto
Año Modelo / Programa(s): Aplicación de Cliente o Modelo de Empresa /Estilo
Asunto: Nombre del Proyecto PFMEA (Sistema, Subsistema y/o Componente)
DfMEA Fecha de inicio: Fecha de inicio
DFMEA Fecha de revisión: última fecha de revisión
Equipo multifuncional: Miembros del Equipo
DFMEA ID Número: Determinado por la compañía
Responsabilidad de diseño de la empresa: Nombre del propietario de PFMEA
Nivel de Confidencialidad: Uso Comercial, Propietario, Confidencial
PREPARACION
Base para el análisis estructural

La información recopilada durante la Planificación y Preparación del Paso 1
se utilizará para desarrollar el Análisis de Estructura del Paso 2.
Propósito
El propósito del análisis de estructura de proceso es identificar y desglosar el sistema
de fabricación en elementos de proceso, pasos de proceso y elementos de trabajo de
proceso.
Los principales objetivos de un análisis de estructura de proceso son:
• Árbol de estructura o equivalente: diagrama de flujo de proceso
• Identificación de pasos de proceso y subpasos
Un diagrama de flujo de proceso o un árbol de estructura ayuda a definir el proceso y
proporcionar la base para el análisis de estructura. Los formatos pueden variar según
la empresa, incluido el uso de símbolos, el tipo de símbolo y su significado. Un
Proceso FMEA está destinado a representar el flujo de proceso tal como existe
físicamente al "caminar el proceso", describiendo el flujo del producto a través del
proceso. El análisis de funciones (paso 3) no debe comenzar hasta que el análisis de la
estructura (paso
2) está completo.
DIAGRAMA DE FLUJO
Un diagrama de flujo de proceso es una herramienta que se puede utilizar como
entrada para el análisis de estructura
Estructura de Árbol
El árbol de estructura organiza los elementos del sistema jerárquicamente e ilustra la
dependencia a través de las conexiones estructurales. Esta estructura pictórica
permite comprender las relaciones entre elementos de proceso, pasos de proceso y
elementos de trabajo de proceso. Cada uno de ellos es un Building Block que más
adelante tendrá funciones y errores agregados.
El elemento de proceso del PFMEA es el nivel más alto del árbol de estructura o
diagrama de flujo de proceso y PFMEA. Esto también se puede considerar el resultado
final de todos los pasos del proceso completados con éxito
• Diagramas de bloques/límites
•Diagrama
Estructura
dede Árbol
bloques/límites
Los diagramas de bloques/límites son herramientas útiles que representan el sistema
Design FMEA. El diagrama siguiente muestra las relaciones físicas y lógicas entre los
componentes del producto. Indica la interacción de componentes y subsistemas
las que el diseño interactúa durante su vida útil. El diagrama de límites se puede
utilizar para identificar los elementos de enfoque que se evaluarán en el análisis de
estructura y análisis de funciones.
• Diagramas de bloques/límites
•Diagrama
Estructura
dede Árbol
bloques/límites
Los diagramas de bloques/límites son herramientas útiles que representan el sistema
Design FMEA. El diagrama siguiente muestra las relaciones físicas y lógicas entre los
componentes del producto. Indica la interacción de componentes y subsistemas
las que el diseño interactúa durante su vida útil. El diagrama de límites se puede
utilizar para identificar los elementos de enfoque que se evaluarán en el análisis de
estructura y análisis de funciones.
Estructurar árboles
El árbol de estructura organiza los elementos del sistema jerárquicamente e ilustra la
dependencia a través de las conexiones estructurales.
De este modo, la ilustración claramente estructurada del sistema completo está
garantizada por el hecho de que cada elemento del sistema sólo existe una vez para
evitar la redundancia.
Las estructuras dispuestas bajo cada elemento del sistema son subestructuras
independientes (véase la figura 2.2-2).
Brush Card Base Body
Window Lifter Commutation System Carbon Brush

Motor
Electronic Control Unit
Magnets (Neodym)
Armature Shaft
Electromagnetic
Converter
Pole Housing
Lifting
Mechanism Magneto-mechanical Gear box
Converter
Window Lifter System
Guiding Frame
System Elements in Scope …

…
Colaboración entre el Cliente y el Proveedor

La salida del Análisis de Estructura (visualización del diseño y sus interfaces)
proporciona una herramienta de colaboración entre clientes y proveedores durante
las revisiones técnicas del proyecto de diseño y/o DFMEA.
Base para el análisis de funciones

La información definida durante el Paso 2 Análisis de Estructura se utilizará para
desarrollar el Análisis de Funciones del Paso 3. Si faltan elementos de diseño
(elementos) en el Análisis de estructura, también faltarán en el Análisis de funciones.
PROPOSITO
El objetivo del análisis de funciones de proceso es garantizar que las
funciones/requisitos previstos del producto/proceso se asignen adecuadamente.
Los principales objetivos de un análisis de funciones de proceso son:
• Visualización de las funciones del producto o del proceso
• Diagrama de flujo de proceso de árbol/red o equivalente
• Base para el paso Análisis de fallos• Asociación de requisitos o características a las
funciones
Función
•Una
Colaboración entre
función describe lo queequipos dede
el elemento ingeniería
proceso o el(sistemas, seguridad
paso de proceso y componentes)
está destinado a hacer. Puede haber
•más
Base para
de una el paso
función para Análisis de fallos
cada elemento de proceso o paso de proceso.
Antes de comenzar el Análisis de funciones, la información que se recopilaría podía incluir, entre otras,;
funciones de producto y proceso, requisitos de producto/proceso, condiciones ambientales de fabricación,
tiempo de ciclo, requisitos de seguridad ocupacional u operador, impacto ambiental, etc. Esta información es
importante para definir las funciones y requisitos "positivos" necesarios para el análisis funcional.
La descripción de una función debe ser clara.
El formato de frase recomendado es utilizar un verbo de acción seguido de un I para describir la función de
proceso medible ("DO THIS" "TO THIS").
Función
Una función debe estar en el PRESENTE TENSE; utiliza la forma base del verbo (por ejemplo, entregar,
contener, controlar, ensamblar, transferir).
Ejemplos: Taladrar agujero, aplicar pegamento, pasador de inserción, soporte de soldadura La función del
elemento de proceso comienza en un nivel alto y
hace referencia a la posición de proceso en el análisis de estructura. Como alta-
descripción de nivel, puede tener en cuenta funciones tales como: Función interna, función externa, función
relacionada con el cliente y / o función de usuario final.
Ejemplo: Ensamblar componentes

La función del paso de proceso describe las características del producto resultantes producidas en la
estación.
REQUISITOS
Una característica es una entidad distintiva (o atributo cuantificable) de un producto.
Por ejemplo, un diámetro o acabados de superficie. Para PFMEA, los requisitos se
describen en términos de características del producto y características del proceso.
Nota: El negativo de éstos será el modo de falla y la causa del error.
Una característica del producto (requisito) está relacionada con el rendimiento de una
función de proceso y se puede juzgar o medir. Una característica de producto se
muestra en un documento de dibujo o especificación de producto, por ejemplo,
geometría, material, acabado superficial, recubrimientos, etc. Las funciones de
proceso crean características del producto. Los documentos de diseño comprenden
los requisitos legales (por ejemplo, material sin plomo), requisitos de la industria (por
ejemplo, clase de rosca), requisitos del cliente (por ejemplo, cantidad) y requisitos
internos (por ejemplo, limpieza de piezas). Las características del producto se pueden
medir después de que se haya fabricado el producto (por ejemplo, brecha). Producto
característica del producto mensurable, seguida del requisito de rendimiento, por
ejemplo, el diámetro de sobrepasador de spline (Reglamento de limpiaparabrisas
gubernamental XYZ). El valor cuantitativo específico es opcional para la hoja de
formulario PFMEA.
Características del producto: • Puede derivarse de diversas fuentes, externas e
internas
Requisitos legales: Cumplimiento de las normas designadas de salud y seguridad y
protección del medio ambiente
Normas y normas de la industria: • ISO 9001, VDA Volumen 6 Parte 3, Auditoría de
Procesos, SAE J1739
Requisitos del cliente: De acuerdo con las especificaciones del cliente, por ejemplo, el
cumplimiento de la calidad requerida, la fabricación y el suministro de productos en
tiempo x y cantidad y (salida z/hora)
Requisitos internos:
• Fabricación del producto, en ciclo de proceso, cumplimiento de los costes de
producción previstos (por ejemplo, disponibilidad de instalaciones, rechazos
limitados, sin trabajo correctivo), principios del sistema de producción, calidad del
proceso e instrucciones de limpieza
Características del proceso:
• Una característica de proceso es el control de proceso que garantiza que la
característica del producto se logra mediante el proceso. Puede mostrarse en los
dibujos o especificaciones de fabricación (incluidas las instrucciones de trabajo del
operador, las instrucciones de configuración, los procedimientos de verificación de
VISULIZACION DE RELACIONES FUNCIONALES

Visualización de relaciones funcionales
La interacción de las funciones de elementos de proceso, las funciones de paso de
proceso y las funciones de elementos de trabajo de proceso se puede visualizar como
red de funciones, estructura de funciones, árbol de funciones y/o análisis de
funciones en función de la herramienta de software utilizada para realizar el PFMEA.
Por ejemplo, Análisis de funciones se encuentra en la Hoja de formulario para realizar
el PFMEA
El diagrama P, completado para funciones ideales específicas, ayuda a la identificación

de:
• Factores, niveles, respuestas y señales necesarias para la optimización del sistema
• Funciones que son entradas para el DFMEA
• Factores de control y ruido que podrían afectar el rendimiento funcional
• Salidas involuntarias del sistema (salidas desviadas)

Los equipos de ingeniería dentro de la empresa necesitan colaborar para asegurarse
de que la información sea consistente para un proyecto o programa de cliente,
especialmente cuando varios equipos de PFMEA están realizando simultáneamente el
análisis técnico de riesgos. Por ejemplo, la información de diseño de sistemas,
seguridad y/o grupos de componentes ayuda al equipo de PFMEA a comprender las
funciones del producto que fabrican. Esta colaboración puede ser verbal (reuniones
del programa) o escrita como un resumen.
Base para el análisis de fallos

La definición completa de las funciones de proceso (en palabras positivas) dará lugar
a un análisis completo del error del paso 4 porque los posibles errores son formas en
que las funciones podrían fallar (en palabras negativas).
PROPOSITO
El propósito del análisis de errores de proceso es identificar las causas, modos y
efectos de error, y mostrar sus relaciones para permitir la evaluación de riesgos.
Los principales objetivos de un análisis de fallos de proceso son:
• Establecimiento de la Cadena de Fallas
• Posibles efectos de error, modos de error, causas de error para cada función de
proceso.
• Identificación de las causas de fallas del proceso utilizando un diagrama de espinas
de pescado (4M) o una red de fallas
• Base para la documentación de fallos en la hoja de formulario FMEA y en el paso
Se realiza un análisis de errores para cada elemento/paso de la descripción del
proceso (Análisis de estructura/Paso 2 y Análisis de funciones/Paso 3).
EFECTO DE FALLA
Los efectos de error están relacionados con las funciones de la posición de proceso
(Sistema, Subsistema, Elemento de pieza o Nombre del proceso). Los efectos de error
se describen en términos de lo que el cliente podría notar o experimentar. Las fallas
que puedan afectar la seguridad o causar el incumplimiento de las regulaciones
deben identificarse claramente en el PFMEA.
Los clientes podrían ser:
• Cliente interno (próxima operación/operación posterior/operación tar-gets)
• Cliente externo (nivel de siguiente nivel/OEM/distribuidor)
• Organismos legislativos
• Producto o Producto usuario final/operador
Los efectos de error reciben una clasificación de gravedad según:
1. Su planta: el efecto del modo de fallo suponiendo que el defecto se detecta en la
planta (qué acción tomará la planta, por ejemplo, chatarra)
EFECTO DE FALLA
2. Envío a la planta: el efecto del modo de fallo suponiendo que el defecto no se
detecta antes de enviar a la siguiente planta (qué acción tomará la siguiente planta,
por ejemplo, ordenar)
3. Usuario final: el efecto del efecto del elemento de proceso (lo que el usuario final
notará, sentirá, escuchará, olerá, etc., por ejemplo, la ventana aumenta demasiado
lento)
Se deben hacer las siguientes preguntas para ayudar a determinar el impacto
potencial de los efectos de falla:
1. ¿El modo de falla afecta físicamente al procesamiento descendente o causa un
daño potencial a los equipos u operadores?
Esto incluye la incapacidad de ensamblar o unirse a un componente de acoplamiento
en las instalaciones de cualquier cliente posterior.
Si es así, identifique el impacto de fabricación "Su Planta" y/o "planta de envío a" en
el PFMEA. Si no es así, vaya a la pregunta 2.
EFECTO DE FALLA
Algunos ejemplos podrían ser:
• No se puede montar en la operación x
• No se puede acoplar en las instalaciones del cliente
• No se puede conectar en las instalaciones del cliente
• No se puede perforar en la operación x
• Provoca un desgaste excesivo de la herramienta en la operación x
• Equipos de daños en la operación x
• Pone en peligro al operador en las instalaciones del cliente
2. ¿Cuál es el impacto potencial en el usuario final?
Independientemente de los controles planificados o implementados, incluidos errores
o errores, tenga en cuenta lo que sucede con el elemento de proceso que conduce a
lo que el usuario final notaría o experimentaría. Esta información puede estar
disponible dentro de DFMEA. Si se lleva a cabo un efecto a partir de la DFMEA, la
descripción de los efectos del producto en el PFMEA debe ser coherente con los del
DFMEA correspondiente.
MODO DE FALLA
Un modo de falla se define como la forma en que un elemento podría no cumplir o
entregar la función prevista.
Los modos de falla se derivan de las funciones. Los modos de falla deben describirse
en términos técnicos, y no necesariamente como síntomas perceptibles por el cliente.
Al preparar el DFMEA, supongamos que el diseño se fabricará y ensamblará con la
intención del diseño. Las excepciones se pueden hacer a discreción del equipo cuando
los datos históricos indican que existen deficiencias en el proceso de fabricación.
Algunos ejemplos de modos de error de nivel de componente incluyen, entre otros:

NO RECOMENDADO
Componente agrietado agrietado
Componente deformado deformado
Componente fracturado fracturado
Pieza suelta suelta
Parte oxidada oxidada
Sticking Component sticking
EFECTO DE FALLA
• Ruido
• Alto esfuerzo
• Olor desagradable
• Funcionamiento intermitente
• Fuga de agua
• Inactivo áspero
• No se puede ajustar
• Difícil de controlar
• Aspecto deficiente
• Función del sistema regulador reducida o fallida
• Falta de control del vehículo por parte del usuario final
• Efecto de seguridad sobre el usuario final
EFECTO DE FALLA
3. ¿Qué sucedería si se detectara un efecto de error antes de llegar al usuario final?
También debe tenerse en cuenta el efecto de error en las ubicaciones actuales o
receptoras.
Identifique el impacto de fabricación "Su Planta" y/o "planta de envío" en el PFMEA.
• Apagado de línea
• Detener el envío
• Retención de patio
• 100% del producto desechado
• Disminución de la velocidad de la línea
• Añadida mano de obra para mantener la velocidad de línea requerida
• Reelaboración y reparación
MODO DE FALLA
Un modo de error (proceso) se define como la forma en que el proceso podría hacer
que el producto no entregue o proporcione la función prevista.
El equipo debe asumir que el diseño básico del producto es correcto; sin embargo, si
hay problemas de diseño que resultan en problemas de proceso, esos problemas
deben ser comunicados al equipo de diseño para su resolución.
Supongamos que el modo de error podría producirse, pero no necesariamente. Los
modos de fallo deben describirse en términos técnicos, no como un síntoma
perceptible por el cliente
La verificación de la integridad de los modos de falla se puede hacer a través de una

revisión de cosas pasadas mal, informes de rechazo o derechazo, y lluvia de ideas de
grupo. Las fuentes para esto también deben incluir una comparación de procesos
similares y una revisión de las reclamaciones de clientes (usuario final y operación
posterior) relacionadas con componentes similares.
MODO DE FALLA
Hay varias categorías de posibles modos de falla, incluyendo:
• Pérdida de la función/operación del proceso no realizada
• Función parcial - Funcionamiento incompleto
• Degradación de la función del proceso
• Función de proceso de sobrealcanzar - Demasiado alto.
• Función de proceso intermitente - operación no consistente
• Operación inestable
• Función de proceso no intencionada - funcionamiento incorrecto
• Pieza incorrecta instalada
• Función de proceso retrasada - funcionamiento demasiado tarde
MODO DE FALLA
Los modos de error típicos podrían ser, pero no se limitan a:
• Agujero demasiado superficial, demasiado profundo, perdido o fuera de lugar.
• Superficie sucia
• Acabado superficial demasiado liso
• Pines de conector desalineados
• Conector no completamente asentado
• Pasar una parte mala, o rechazar una buena parte, la operación de inspección de
bypass
• Falta la etiqueta
• Código de barras no legible
• La ECU brilló con un software incorrecto.
CAUSA DE FALLA
Una causa de error es una indicación de por qué podría ocurrir un modo de error. La
consecuencia de una causa es el modo de error. Identifique, en la medida de lo
posible, todas las posibles causas de fabricación o ensamblaje para cada modo de
error. La causa debe enumerarse de forma concisa y completa posible para que los
esfuerzos (controles y acciones) puedan estar dirigidos a causas apropiadas.
Las causas típicas del error pueden incluir el 4M clásico de Ishikawa, pero no se
limitan a:
• Hombre: trabajador de configuración, operador de máquina / asociado, asociado de
materiales, técnico de mantenimiento, etc.
Máquina/Equipo: robot, tanque de depósito de tolva, máquina de moldeo por
inyección, transportador de espiral, dispositivos de inspección, accesorios, etc.
• Material (indirecto): aceite de mecanizado, grasa de instalación, concentración de la
lavadora, (ayuda para el funcionamiento), etc.
• Entorno (Milieu): condiciones ambientales como calor, polvo, contaminación,
iluminación, ruido, etc.
CAUSA DE FALLA
• Un método para ayudar a revelar/descubrir las causas del fracaso es tener un
facilitador que guíe al equipo a través de "Preguntas de estimulación que provocan
pensamientos" Estas preguntas pueden ser preguntas de categoría amplia, suficientes
para estimular el proceso de pensamiento de los expertos en procesos, mientras que
mantener el número de preguntas a un nivel manejable. Las preguntas pueden ser
específicas del proceso y desglosadas en las categorías 4M. La lista inicial de
preguntas se puede formar revisando las Causas de Falla en PFMEA anteriores.
Ejemplo - Proceso de ensamblaje:
3.4.6.1 Hombre
1. A partir de las piezas disponibles dentro del proceso, ¿se puede aplicar una pieza
incorrecta?
2. ¿No se puede aplicar ninguna pieza?
3. ¿Se pueden cargar las piezas incorrectamente?
4. ¿Se pueden dañar las piezas - ¿Desde la recogida hasta la aplicación?
5. ¿Se puede utilizar material incorrecto?
CAUSA DE FALLA
• 3.4.6.2 Máquina
1. ¿Se puede interrumpir el proceso automatizado?
2. ¿Se pueden introducir los datos introducidos incorrectamente?
3. ¿Se puede ejecutar la máquina en modo manual, evitando los controles
automatizados?
4. ¿Existe un calendario para confirmar los controles de prevención y detección?
3.4.6.4 Entorno (Milieu)

1. ¿La iluminación es adecuada para la tarea?
2. ¿Pueden las piezas utilizadas dentro del proceso, ser consideradas material
extranjero?
La descripción de la causa del error debe ser clara. Términos como "defectuoso, roto",
"fallo del operador", "no cumplimiento o "no está bien" y así sucesivamente son
insuficientes para asignar exhaustivamente la causa y el modo de falla y para
determinar las acciones.
ANALISIS DE FALLAS
En función de los pasos del proceso, los errores se derivan y las cadenas de errores
(es decir, la estructura de errores/árboles de error/red de errores) se crean a partir
del análisis de funciones (véase la figura 3.3-1).
El elemento de foco de la estructura de error es el modo de error, con sus efectos de
error asociados y posibles causas de error.
Según el foco, un error se puede ver como un efecto de error, un modo de error o una
causa de error.
Para vincular las causas de error a un modo de error, la pregunta debe ser "¿Por qué
se está produciendo el modo de error?"
Para vincular los efectos de error a un modo de error, la pregunta debe ser "¿Qué
sucede en caso de un modo de error?"
ETAPA 4:
RELACION ENTRE PAMEF Y DAMEF
ANALISIS de FALLA
Un error de diseño de una característica (característica de producto) puede provocar
un error en una o varias funciones del producto. El fallo del proceso correspondiente
es la incapacidad del proceso para fabricar la misma característica que se diseñó. El
hecho de no ajustarse a una característica de producto conduce solo al efecto De
error. Sólo en este caso es el efecto de falla en el FMEA del diseño lo mismo que en el
proceso FMEA. Todos los efectos de error que son causados por un error de los
procesos y que no se identifican en El diseño FMEA tienen que ser recién definidos y
evaluados en el proceso FMEA.
Los efectos de error relacionados con el producto, el sistema y/o el

usuario final y sus gravedades asociadas deben documentarse cuando se
conocen, pero no se asumen. La clave para la identificación de los
efectos de fallo y las gravedades asociadas es la comunicación de las
partes implicadas y la comprensión de las diferencias y similitudes de
las fallas analizadas en DFMEA y PFMEA (véase también la figura 1.4-
1).
ANALISIS DE FALLAS DOCUMENTACION

Documentación de análisis de fallos
Una vez completados el Análisis de estructura, el análisis de funciones y el análisis de
errores, un árbol de estructura u hoja de cálculo puede tener varias vistas.
COLABORACION CLIENTE PROVEEDOR
3.4.10 Colaboración entre el cliente y el proveedor (efectos de fallo)
El resultado del Análisis de Fallo puede ser revisado por clientes y proveedores antes
del paso análisis de riesgos o después del paso análisis de riesgos basado en acuerdos
con el cliente y la necesidad de compartir con el proveedor.
Base para el análisis de riesgos

La definición completa de posibles errores dará lugar a un análisis de riesgos
completo del paso 5 porque la clasificación de gravedad, ocurrencia y detección se
basa en las descripciones de errores. El análisis de riesgos puede estar incompleto si
los posibles fallos son demasiado vagos o faltan.
PROPOSITO
El propósito del Análisis de Riesgos de Procesos es estimar el riesgo mediante la
evaluación de la gravedad, ocurrencia y detección, con el fin de priorizar la necesidad
de acciones.
Los principales objetivos del Análisis de Riesgos de Procesos son:
• Clasificación de gravedad, ocurrencia y detección para cada cadena de fallas
• Colaboración entre cliente y proveedor (Gravedad)
Hay dos grupos de control diferentes: controles de prevención actuales y controles de
detección actuales
3.5.2.1 Planificación de procesos
Definición: Los controles de prevención actuales facilitan la planificación óptima del
proceso para minimizar la posibilidad de que se produzcaun un error.
Prevención de posibles deficiencias de trazado de la instalación de producción:
• Las pruebas se ejecutan de acuerdo con la regulación de puesta en marcha AV
17/3b
3.5.2.2 Proceso de producción
Definición: Eliminar (prevenir) la causa de falla o reducir su tasa de ocurrencia.
Prevención de piezas producidas defectuosamente en la planta de producción:
• Funcionamiento a dos manos de máquinas
• La parte posterior no se puede fijar (Poka-Yoke)
• Posición dependiente de la forma
• Mantenimiento de equipos
• Mantenimiento del operador
• Instrucciones de trabajo / Ayudas visuales
• Controles de la máquina
• Lanzamiento de la primera parte

Las causas de fallo se clasifican por ocurrencia, teniendo en cuenta la eficacia del
control de prevención actual (Capítulo Evaluación de Riesgos).
Los controles de prevención actuales describen las medidas que deben
implementarse en el proceso de diseño y verificarse durante el prototipo, las
cualificaciones de la máquina (ejecución) y la verificación del proceso antes del inicio
de la producción regular. Los controles de prevención también pueden incluir
instrucciones de trabajo estándar, procedimientos de configuración, mantenimiento
preventivo, procedimientos de calibración, procedimientos de verificación de prueba
de errores, etc.
Definición: Los controles de detección actuales detectan la existencia de una causa de
error o el modo de error, ya sea mediante métodos automatizados o manuales, antes
de que el artículo salga del proceso o se envíe al cliente.
• Inspección visual
• Inspección visual con lista de verificación de muestras
• Inspección óptica con sistema de cámara
• Prueba óptica con muestra de límite
• Prueba atributiva con mandril
• Comprobación dimensional con un calibre de pinza
• Inspección aleatoria
• Monitoreo de par
• Monitoreo de la carga de prensa
• Comprobación de la función de fin de línea
CONTROLES ACTUALES DE PREVENCION Y DETECCION

Los controles actuales de prevención y detección deben confirmarse para que se
implementen y sean eficaces. Esto se puede hacer durante una revisión en la estación
(por ejemplo, Revisión lateral de línea, caminatas de línea y auditorías regulares). Si el
control no es efectivo, puede ser necesaria una acción adicional.
Las clasificaciones de Ocurrencia y Detección deben revisarse al utilizar datos de
procesos anteriores, debido a la posibilidad de diferentes condiciones para el nuevo
proceso.
EVALUACIONES
Cada relación de modo de error, causa y efecto (cadena de fallos o red) se evalúa por
su riesgo independiente. Existen tres criterios de calificación para la evaluación del
riesgo:
Gravedad (S): significa la gravedad del efecto de fracaso
Ocurrencia (O): significa la Ocurrencia de la Causa de Falla
Detección (D): significa detección de la causa de falla ocurrida y/ o el modo de falla
Los números de evaluación del 1 al 10 se utilizan para S, O y D respectivamente, en
los que 10 representa la contribución de mayor riesgo.
SEVERIDAD (S)
La gravedad es un número de clasificación asociado con el efecto más grave para un
modo de error determinado para el paso de proceso que se está evaluando. Es una
calificación relativa dentro del alcance de la FMEA individual y se determina sin tener
en cuenta la ocurrencia o detección.
Para los efectos específicos del proceso, la clasificación de gravedad debe
determinarse utilizando los criterios de la tabla de evaluación P1. La tabla se puede
aumentar para incluir ejemplos específicos corporativos o de línea de productos.
Las evaluaciones de los efectos de error deben ser mutuamente acordadas por el
cliente y la organización.
Process General Evaluation Criteria Severity (S)
Potential Failure Effects rated according to the criteria below. Blank until
filled in by user
S Effect Impact to Your Plant Impact to Ship-to Plant (when Impact to End User Corporate or
known) (when known) Product Line
Examples
Affects safe operation
of the vehicleand/or
Failure may result in an Failure may result in an acute
other vehicles,the
acute health and/or safety health and/or safety risk for
health of driver or
10 risk for the manufacturing the manufacturing or
passenger(s) or road
or assembly worker assembly worker
High users or
pedestrians.
Failure may result in in- Failure may result in in- Noncompliance with
9 regulations.
plant regulatory plant regulatory
noncompliance noncompliance
Line shutdown greater than
fullproduction shift; stop
shipment possible; field
100% ofproduction run
repair or replacement
affected may have to be
required (Assembly to End
scrapped. Loss ofprimary
User) other thanfor
Failure may result in in- plant vehiclefunction
regulatory noncompliance.
regulatory noncompliance necessary for
8 Failure may result in in- plant
or may have a chronic normal driving
regulatory noncompliance
health and/or safety risk for during expected
or may have a chronic
the manufacturing or service life.
health and/or safety risk for
Moderately assembly worker
the manufacturing or
high
assembly worker.
Product may have to be Line shutdown from 1 hour

sorted and a portion (less up tofull production shift; Degradation of
than 100%) scrapped; stop shipment possible; field primary vehicle
deviationfrom primary repair or replacement function necessary for
7
process; decreased line required (Assembly toEnd normal driving during
speedor added manpower User) otherthan for expected service life.
regulatory
noncompliance
Process General Evaluation Criteria Severity (S)
Potential Failure Effects rated according to the criteria below. Blank until
filled in by
user
S Effect Impact to Your Plant Impact to Ship-to Plant (when Impact to End User (when Corporate or
known) known) Product Line
Examples
100% of production run may

have to be reworked off line Line shutdown up to one hour Loss of secondary vehicle
6 and accepted function.
Less than 100% of product

A portion of the production run affected;strong possibilityfor
Moderately low Degradation of
mayhave to be reworked off additional defective product;
5 secondary vehicle
line and accepted sort
function.
required; no line shutdown
100% of production run may Defective product triggers Very objectionable

have to be reworked in station significant reactionplan; appearance, sound,
before it is processed additional defective products vibration, harshness, or
4
not haptics.
likely; sort notrequired
Moderately
Defective product triggers minor objectionable
A portion of the production run
reaction plan; additional appearance, sound,
mayhave tobereworked in-
defective products not likely; vibration, harshness, or
3 station before it isprocessed
sort not required haptics.
Low
Defective product triggers no Slightly objectionable
reaction plan; additional appearance, sound,
Slight inconvenience to defective products not likely; vibration, harshness, or
process, operation, or sort not required; requires haptics.
2 feedback to supplier
operator
No discernible effect or no No discernible effect.

1 Very low No discernible effect effect
OCURRENCIA (O)
La clasificación de ocurrencia (O) describe la aparición de la causa de error en el
proceso, teniendo en cuenta los controles de prevención actuales asociados.
El número de calificación de ocurrencia es una calificación relativa dentro del alcance
de la FMEA y puede no reflejar la ocurrencia real.
La clasificación Occurrence describe el potencial de la causa de error, según la tabla
de clasificación, sin tener en cuenta los controles de detección.
La experiencia u otras experiencias con procesos comparables, por ejemplo, se
pueden considerar en la evaluación de los números de calificación.
Al determinar esta calificación, deben tenerse en cuenta preguntas como las
siguientes:¿Cuál es el historial de equipos con procesos y pasos de proceso similares?
• ¿Cuál es la experiencia de campo con procesos similares?
• ¿El proceso es un proceso de prórroga o similar a un proceso anterior?
• ¿Qué tan significativos son los cambios de un proceso de producción actual?
• ¿El proceso es completamente nuevo?
• ¿Cuáles son los cambios ambientales?
• ¿Ya se han implementado las mejores prácticas?
• ¿Existen instrucciones estándar? (por ejemplo, instrucciones de trabajo,
OCURRENCIA (O)
procedimientos de configuración y calibración, mantenimiento preventivo,

procedimientos de verificación de prueba de errores y listas de verificación de
supervisión de procesos)
• ¿Se implementan soluciones técnicas de prueba de errores? (por ejemplo, diseño
de productos o procesos, diseño de accesorios y herramientas, secuencia de procesos
establecida, seguimiento/trazabilidad del control de producción, capacidad de la
máquina y gráficos SPC)
Occurrence Potential (O) for the Process
Potential Failure Causes rated according to the criteria below. Consider Prevention Controls
when determining the bestOccurrence estimate.Occurrence is apredictive qualitative rating
made at the time of evaluation and may not reflect the actual occurrence. The occurrence
Blank until filled in
rating number is a relative rating within the scope of the FMEA (process being evaluated). For
by user
Prevention Controls with multiple Occurrence Ratings, use the rating that best reflects the
robustness of the control.
Prediction of Type of Corporateor

O Failure Cause Control Prevention Controls ProductLine
Occurring Examples
10 Extremely high None No prevention controls.
9 Very high Behavioral Prevention controls will have little

8 effect in preventing failure cause.
7 High Prevention controls somewhat
effective in preventing failure cause.
6 Behavioral or
5 Moderate Technical Prevention controls are effective in
4 preventing failure cause.
3 Low Best
Practices: Prevention controls are highly
2 Very low Behavioral effective in preventing failure cause.
or Technical
Prevention controls are extremely

effectiveinpreventing failure cause
from occurring due to design (e.g. part
geometry) or process (e.g. fixture or
1 Extremely low Technical tooling design). Intent of prevention
controls - Failure Mode cannot be
physically produced due to the Failure
Cause.
DETECCION (D)
La detección es la clasificación asociada a una predicción del control de proceso más
eficaz de los controles de proceso de tipo de detección enumerados. La detección es
una calificación relativa, dentro del ámbito de la FMEA individual y se determina sin
tener en cuenta la gravedad o la ocurrencia. La detección debe estimarse utilizando
los criterios del cuadro P3. Esta tabla puede aumentarse con ejemplos de métodos de
detección comunes utilizados por la empresa.
La intención del término "producto discrepante de control" utilizado en los cuadros
P3 de los rangos 3 y 4 es disponer de controles/sistemas/procedimientos
que controla el producto discreto de tal manera, que la probabilidad de que el

producto escape de la instalación es muy baja.
Los controles comienzan desde que el producto se identifica como discreto hasta el
punto de disposición final. Estos controles suelen superar los controles que se usan
para productos discretos con rangos de detección más altos.
Después de la implementación de cualquier control no probado, la eficacia se puede
verificar y reevaluar.
DETECCION (D)
Al determinar esta estimación, deben tenerse en cuenta cuestiones como las
siguientes:
causa/fallo? Al determinar esta estimación, deben tenerse en cuenta cuestiones
como las siguientes:
causa/fallo?
Detection Potential (D) for the Validation of the Process Design
Detection Controls rated according to the Detection Method Maturity and Opportunity for Detection. Blank until
filled in by
user
Ability to Detection Method Corporate
Detect Maturity or Product
D Opportunity for Detection Line
Examples
No testing or inspection The failure mode will not or cannot be detected.
10 method has been
established or is known.
Very low It is unlikely that the
testing or inspection The failuremode is not easily detected through
9
method will detect the random or sporadic audits.
failure mode.
Testor inspection method Humaninspection (visual,tactile, audible), or use
has not been proven to be of manual gauging (attribute or variable) that
8 effective and reliable (e.g. should detect the failuremode or failure cause.
plant has little or no
experience with method, Machine-based detection (automated or semi-
Low gauge R&R results marginal automated with notification by light, buzzer,
on comparable process or etc.), or use of inspection equipment such as a
7 this application, etc.). coordinate measuring machine
that should detect failure mode or failure
cause.
Detection Potential (D) for the Validation of the Process Design
DetectionControlsratedaccordingtotheDetectionMethodMaturity andOpportunityfor Detection. Blank until
filled in by user
Ability to Detection Method Maturity Corporate or

Detect Product Line
D Opportunity for Detection
Examples
Humaninspection(visual,tactile,audible), or use of
manual gauging (attribute or variable) thatwilldetectthe
6 failure modeor failure cause (including product sample
Test or inspection method has
checks).
been proven to be effective and
reliable (e.g. plant has experience
Moderate with method; gauge R&R results
Machine-baseddetection(semi-automated withnotification
are acceptable on comparable
bylight, buzzer,etc.),oruse of inspection equipment such as
process or this application, etc.).
a coordinate measuring machine that will detect failure
5 mode or failure cause (including product samplechecks).
Machine-based automated detection method that will

detect the failure mode downstream,preventfurther
processingor system will identify the product as discrepant
and allow it to automatically move forward in the process
until the designated reject unload area. Discrepant product
4 will becontrolled by a robust system thatwill prevent outflow
ofthe product from the facility.
System has been proven tobe
effective andreliable (e.g.planthas
experience with method on
identical process or this
application), gauge R&R resultsare
acceptable,etc. Machine-based automated detection methodthatwill
High detectthe failure mode in- station, prevent further
processing or system will identify the product as discrepant
and allow it to automatically move forward in the process
until the designated reject unload area. Discrepant product
3 will becontrolled by a robust system thatwill prevent outflow
ofthe product from the facility.
Detection method has been

proven to be effectiveandreliable Machine-baseddetectionmethodthatwill detectthe
(e.g. planthasexperiencewith causeand prevent thefailure mode (discrepant part)
2
method, error-proofing from being produced.
verifications, etc.).
Failuremodecannotbephysicallyproducedas-designedorprocessed, ordetection methods

1 Very high
provento always detectthe failuremodeorfailure cause.

Una vez que el equipo ha completado la identificación inicial de los modos de falla y
los efectos, causas y controles, incluidas las clasificaciones de gravedad, ocurrencia y
detección, deben decidir si se necesitan más esfuerzos para reducir el riesgo. Debido
a las limitaciones inherentes a los recursos, el tiempo, la tecnología y otros factores,
deben elegir la mejor manera de priorizar estos esfuerzos.
El método Action Priority (AP) se introduce en este manual. Representa las 1000
combinaciones posibles de S, O y D. Fue creado para dar más énfasis en la gravedad
primero, después la ocurrencia, después la detección. Esta lógica sigue la intención de
prevención de errores de FMEA. La tabla AP ofrece una prioridad sugerida alta-media-
baja para la acción. Las empresas pueden utilizar un único sistema para evaluar las
prioridades de acción en lugar de varios sistemas requeridos de varios clientes.

Los números de prioridad de riesgo son el producto de S x O x D y oscilan entre 1 y
1000. La distribución RPN puede proporcionar cierta información sobre el rango de
clasificaciones, pero RPN por sí solo no es un método adecuado para determinar la
necesidad de más acciones, ya que RPN da el mismo peso a S, O y D. Por esta razón,
RPN podría resultar en números de riesgo similares para combinaciones muy
diferentes de S, O y D dejando al equipo incierto sobre cómo priorizar. Cuando se
utiliza RPN se recomienda utilizar un método adicional para priorizar como resultados
de RPN como S x O. El uso de un umbral de número de prioridad de riesgo (RPN) no
es una práctica recomendada para determinar la necesidad de acciones. Los métodos
RPN y S x O no se incluyen en esta publicación.

Las matrices de riesgo pueden representar combinaciones de S y O, S y D, y O y D.
Estas matrices proporcionan una representación visual de los resultados del análisis y
pueden utilizarse como insumo para la priorización de acciones basadas en criterios
establecidos por la empresa no incluidos en esta publicación.
Puesto que la tabla AP fue diseñada para trabajar con las tablas de gravedad,
ocurrencia y detección proporcionadas en este manual, si la organización elige
modificar las tablas S, O, D, para productos, procesos o proyectos específicos, la tabla
AP también debe ser cuidadosamente Revisado.
Prioridad alta (H): Prioridad alta (H): Máxima prioridad para la revisión y la acción.
El equipo debe identificar una acción adecuada para mejorar los controles de
prevención y/o detección o justificar y documentar por qué los controles actuales son
adecuados

El equipo debe identificar las acciones adecuadas para mejorar los controles de
prevención y/o detección, o, a discreción de la empresa, justificar y documentar por
qué los controles son adecuados.
El equipo podría identificar acciones para mejorar los controles de prevención o
detección.
Se recomienda que los posibles efectos de error de gravedad 9-10 con Action
Priority High y Medium, como mínimo, sean revisados por la administración,
incluidas las acciones recomendadas que se tomaron.
Esta no es la priorización de alto, medio o bajo riesgo, es la priorización de la
necesidad de acciones para reducir el riesgo.
Action Priority (AP) for DFMEA and PFMEA
Action Priority isbasedoncombinations ofSeverity,Occurrence,andDetection ratingsin order to prioritize actions for riskreduction. Blank until filled in
by user
Occurring
Very high 8-10 Moderate 5-6 H

High 2-4 H
Very high 1 H
Moderate 5-6 H
High 6-7
Product or Plant High 2-4 H
Effect Very high 9-10
Very high 1 H
Moderate 5-6 H
Moderate 4-5
High 2-4 H
Very high 1 M
Moderate 5-6 M
Low 2-3
High 2-4 L
Very high 1 L

Moderate 5-6 H
Very high 8-10
High 2-4 H
Very high 1 H
Moderate 5-6 H
High 6-7
Product or Plant High 2-4 H
Effect High 7-8 Very high 1 M
Moderate 5-6 M
Moderate 4-5
High 2-4 M
Very high 1 M
Moderate 5-6 M
Low 2-3
High 2-4 L
Very high 1 L
Failure Cause PRIORITY (AP)
Effect S O Ability to Detect D Comments
Occurring

Moderate 5-6 H
Very high 8-10
High 2-4 M
Very high 1 M
Moderate 5-6 M
High 6-7
High 2-4 M
Product or Plant Effect Very high 1 L
Moderate
4-6 Low - Very low 7-10 M
Moderate 5-6 L
Moderate 4-5
High 2-4 L
Very high 1 L
Moderate 5-6 L
Low 2-3
High 2-4 L
Very high 1 L

Moderate 5-6 M
Very high 8-10
High 2-4 L
Very high 1 L
Moderate 5-6 L
High 6-7
High 2-4 L
Product or PlantEffect Very high 1 L
Low
2-3 Low - Very low 7-10 L
Moderate 5-6 L
Moderate 4-5
High 2-4 L
Very high 1 L
Moderate 5-6 L
Low 2-3
High 2-4 L
Very high 1 L
No discernible Very low -

Effect 1 Very high 1-10 Very high - Very low 1-10 L
ETAPA 5: ANALISIS
de RIESGOS
El resultado del Análisis de Riesgos crea la comprensión mutua del riesgo técnico
entre clientes y proveedores. Los métodos de colaboración van desde informes
verbales hasta informes formales. La cantidad de información compartida se basa en
las necesidades de un proyecto, la política de la empresa, los acuerdos contractuales,
etc. La información compartida depende de la colocación de la empresa en la cadena
de suministro.
A continuación se enumeran algunos ejemplos.
1. El OEM puede comparar las funciones de diseño, los efectos de falla y la gravedad
de un DFMEA a nivel de vehículo con el proveedor de nivel 1 PFMEA.
2. El proveedor de nivel 1 comunica la información necesaria sobre las características
del producto en los dibujos y/o especificaciones de los productos u otros medios,
incluida la designación de características y gravedad estándar o especiales. Esta
información se utiliza como entrada para el proveedor de nivel 2 PFMEA, así como
para el PFMEA interno del nivel 1. Cuando el equipo de diseño comunica el riesgo
asociado de crear características del producto fuera de especificación, el equipo de
proceso puede construir en el nivel adecuado de prevención y controles de detección
en la fabricación.
.
Base para la optimización

La salida de los pasos 1, 2, 3, 4 y 5 del proceso FMEA de 7 pasos se utiliza para
determinar si se necesita una acción adicional de diseño o prueba. Las revisiones del
proceso, las opiniones de los clientes, la gestión
revisiones y las reuniones de equipo multifuncionales conducen a la Optimización del
Paso 6.
PROPOSITO
El propósito del paso de optimización de procesos es determinar las acciones para
mitigar el riesgo y evaluar la eficacia de esas acciones. El resultado final es un proceso
que minimiza el riesgo de producir y entregar productos que no cumplen con las
expectativas del cliente y de las partes interesadas.
Los principales objetivos de una optimización de procesos son:
• Asignación de responsabilidades y plazos para la implementación de la acción
• Base para el refinamiento de los requisitos del producto y/o proceso y los controles
de prevención y detección
PROPOSITO
El objetivo principal de la optimización es desarrollar acciones que reduzcan el riesgo
mejorando el proceso. En este paso, el equipo revisa los resultados del análisis de
riesgos y asigna acciones para reducir la aparición de la causa de error o aumentar la
capacidad de detectar la causa de error o el modo de error. También se pueden
asignar acciones que mejoren el proceso, pero no necesariamente reduzcan la
calificación de evaluación de riesgos. Las acciones representan el compromiso de
tomar una acción específica, medible y alcanzable, no acciones potenciales que nunca
pueden implementarse. Las acciones no están pensadas para usarse para actividades
que ya están planificadas, ya que se documentan en los controles de prevención o
detección y ya se tienen en cuenta en el análisis de riesgos inicial. Todas las acciones
deben tener un individuo responsable y un tiempo de finalización objetivo asociado a
la acción.
.
PROPOSITO
El PFMEA se puede utilizar como base para la mejora continua del proceso.
• Modificaciones de proceso para eliminar o mitigar un efecto de fallo (FE)
• Modificaciones del proceso para reducir la ocurrencia (O) de la Causa de Falla (FC).
• Aumente la capacidad de detección (D) para la causa de error (FC) o el modo de
fallo (FM).
• En el caso de modificaciones del proceso, todos los pasos del proceso afectados se
evalúan de nuevo.

que se basaba en un concepto de fabricación diferente.
El PFMEA puede utilizarse como base para la mejora continua del proceso
(TCD) asociada.
acción.
La fecha de finalización real para las acciones preventivas y de detección se
documenta, incluida la fecha en que se implementan las acciones.
producción).
Abierto
No se ha definido ninguna acción.
Decisión pendiente (opcional)
La acción ha sido definida, pero aún no se ha decidido. Se está creando un documento
de decisión.
Completado
No implementado


las acciones.
riesgo de falla se lleva adelante en el producto. Las acciones son bucles abiertos que
deben cerrarse por escrito.

Cuando se ha completado una acción, se vuelven a evaluar los valores de Ocurrencia
y Detección y se puede determinar una nueva Prioridad de acción.
La reevaluación debe basarse en la eficacia de las acciones preventivas y de detección
tomadas y los nuevos valores se basan en las definiciones de las tablas de clasificación
De ocurrencia y detección de FMEA de proceso.
mejora continua
El PFMEA sirve como registro histórico del proceso. Por lo tanto, la gravedad,
ocurrencia y detección originales (S, O,
D) los números deben ser visibles o, como mínimo, disponibles y accesibles como
parte del historial de versiones. El análisis completado se convierte en un repositorio
para capturar la progresión de las decisiones de proceso y los refinamientos de
diseño. Sin embargo, las clasificaciones originales S, O, D pueden modificarse para la
fundación, la familia o los PFMEA genéricos porque la información se utiliza como
punto de partida para un análisis específico del proceso
Colaboración entre el equipo de FMEA, la Administración, los Clientes y los
Proveedores con respecto a posibles fallos
La comunicación entre el equipo, la dirección, los clientes y los proveedores de FMEA
durante el desarrollo del análisis técnico de riesgos y/o cuando la PFMEA está
inicialmente completa reúne a las personas para mejorar su comprensión del
producto y
Current Prevention Control (PC) of
Force
sheet
FC
adjusted
acc. data
Occurrence (O) of FC
motor
MRKJ5038..
Current
FC or FM
performance
Detection
5 100% check of
curve acc. spec.

Controls (DC) of
2
Detection (D) of FC/FM
PFMEA AP
M
Special Characteristics
PFMEA RISK ANALYSIS (STEP 5)
Filter Code (Optional)
sensor
Prevention Action
control
position
Selected
press with
force
Selected
Action
press with
Detection
monitoring
Responsible Person's Name

Process
Duncan
Mr. Paul
Engineer
Target Completion Date

dd.
mm.
yyyy
Status
open
Action Taken with Pointer to

Evidence
Completion Date
PFMEA OPTIMIZATION (STEP 6)
Severity (S)
8
3
Occurrence (O)
2
Detection (D)
Special Characteristics
L
PFMEA AP
Remarks
RESULTADOS
PROPOSITO
El propósito del paso de documentación de resultados es resumir y comunicar los
resultados de la actividad Modo de error y Análisis de efectos.
Los principales objetivos de la documentación de resultados del proceso son:
adoptadas
• Registro de análisis de riesgos y reducción de riesgos a niveles aceptables
RESULTADOS
REPORTE DEL AMEF
El alcance y los resultados de un FMEA deben resumirse en un informe. El informe
puede utilizarse con fines de comunicación una empresa, o entre empresas. El
informe no pretende reemplazar las revisiones de los detalles de PFMEA cuando así lo
solicite la administración, los clientes o los proveedores. Se pretende ser un resumen
para el equipo de PFMEA y otros para confirmar la finalización de cada una de las
tareas y revisar los resultados del análisis.
desarrollo.
El diseño del documento puede ser específico de la empresa. Sin embargo, el informe
debe indicar el riesgo técnico de fracaso como parte del plan de desarrollo y los hitos
del proyecto. El contenido puede incluir lo siguiente:
REPORTE DEL AMEF
RESULTADOS
A. Una declaración de estado final en comparación con las metas originales
establecidas en el Plan de Proyecto 1.5
a. Intención de FMEA – Propósito de este FMEA?
b. FMEA Timing – FMEA fecha de vencimiento?
c. Equipo FMEA – ¿Lista de participantes?
d. Tarea FMEA - ¿Alcance de esta FMEA?
e. Herramienta FMEA – ¿Cómo llevamos a cabo el método de análisis utilizado?
B. Un resumen del alcance del análisis e identificar las novedades.

proporcionar una copia de las tablas de clasificación S/O/D específicas y el método de
priorización del método de acción (es decir, la tabla de prioridad de acción).
RESULTADOS
REPORTE DEL AMEF

a. Compromiso y calendario para cerrar acciones abiertas.
b. Compromiso de revisar y revisar el PFMEA durante la producción en masa para
garantizar la exactitud e integridad del análisis en comparación con el diseño de
producción (por ejemplo, revisiones provocadas a partir de cambios de diseño,
acciones correctivas, etc., basadas en los procedimientos de la empresa ). (Consulte la
sección 1.4 Caso 3 revisiones de FMEA)
c. Compromiso de capturar "cosas que han ido mal" en los PFMEA de la fundación en
beneficio de la reutilización del análisis futuro, cuando corresponda. (Consulte la
sección 1.3.6 De la Fundación y de las FMEA Familiares)
FMEA SUPLEMENTO PARA MONITORIO Y
RESPUESTA DEL SISTEMA (FMEA-MSR)
En un FMEA Suplementario para Monitoreo y Respuesta del Sistema, las posibles

Causas de Falla que pueden ocurrir bajo las condiciones de operación del cliente se
analizan con respecto a sus efectos técnicos en el sistema, vehículo, personas y
cumplimiento normativo. El método considera si el sistema detecta o no los modos de
error o las causas de error, o si el controlador detecta los efectos de error. El
funcionamiento del cliente debe entenderse como operaciones de usuario final o
operaciones de operación y mantenimiento en servicio.
FMEA-MSR incluye los siguientes elementos de riesgo:

a) Gravedad de los daños, incumplimiento normativo, pérdida o degradación de la
funcionalidad, y calidad inaceptable; representado por (S)
b) Frecuencia estimada de una causa de fallo en el contexto de una situación
operativa; representado por (F)
c) Posibilidades técnicas para evitar o limitar el efecto fallo a través de la detección
diagnóstica y la respuesta automatizada, combinadas con posibilidades humanas para
evitar o limitar el efecto de fallo a través de la percepción sensorial y la reacción
física; representado por (M)
La combinación de F y M es una estimación de la probabilidad de ocurrencia del
efecto de error debido a la falla (causa de error) y el comportamiento de mal
funcionamiento resultante (modo de error).
FMEA-MSR añade valor evaluando la reducción del riesgo como resultado de la

supervisión y la respuesta. FMEA-MSR evalúa el estado actual del riesgo de falla y
deriva la necesidad de un monitoreo adicional en comparación con las condiciones de
riesgo residual aceptable.
El análisis puede formar parte de un Design FMEA en el que los aspectos del
Desarrollo se complementan con aspectos de la Operación del Cliente. Sin embargo,
normalmente solo se aplica cuando la detección diagnóstica es necesaria para
mantener la seguridad o el cumplimiento.
c) Posibilidades técnicas para evitar o limitar el efecto fallo a través de la detección La

detección en DFMEA no es lo mismo que la supervisión en FMEA-MSR suplementario.
En DFMEA, los controles de detección documentan la capacidad de las pruebas para
demostrar el cumplimiento de los requisitos en el desarrollo y la validación. Para la
supervisión que ya forma parte del diseño del sistema, la validación está diseñada
para demostrar que la supervisión de diagnóstico y la respuesta del sistema funcionan
según lo previsto. Por el contrario, la supervisión en FMEA-MSR evalúa la eficacia del
rendimiento de detección de fallas en el funcionamiento del cliente, suponiendo que
se cumplan las especificaciones. El La clasificación de supervisión también comprende
el rendimiento seguro y la fiabilidad de las reacciones del sistema a las fallas
supervisadas. Contribuye a la evaluación del cumplimiento de los Objetivos de
Seguridad y puede ser utilizado para derivar el Concepto de Seguridad.
FMEA-MSR suplementario aborda los riesgos que en DFMEA de otro modo se
evaluarían como altos, considerando más factores que reflejan con precisión un
menor riesgo evaluado de acuerdo con las funciones de diagnóstico del sistema
operativo del vehículo. Estos factores adicionales contribuyen a una mejor
representación del riesgo de fracaso (incluido el riesgo de daño, el riesgo de
incumplimiento y el riesgo de no cumplir las especificaciones).
FMEA-MSR contribuye a la provisión de evidencia de la capacidad de los mecanismos
de diagnóstico, lógicos y de accionamiento para lograr y mantener un estado seguro o
conforme (en particular, la capacidad adecuada de mitigación de fallas dentro del
tiempo máximo de manejo de fallas dentro del tiempo máximo de manejo de fallas
dentro del tiempo máximo de manejo de fallas dentro del tiempo máximo de manejo
de fallas dentro del tiempo máximo de manejo de fallas dentro del tiempo máximo de
manejo de fallas dentro del tiempo máximo de manejo de fallas dentro del tiempo
máximo de manejo de fallas dentro del tiempo máximo de manejo de fallas dentro
del tiempo máximo de manejo de fallas dentro del tiempo máximo de manejo de
fallas dentro del tiempo máximo de intervalo y dentro del intervalo de tiempo
tolerante a errores).
FMEA-MSR evalúa el estado actual de riesgo de fallo en condiciones de usuario final

(no sólo el riesgo de daño a las personas). La detección de fallas/fallos durante el
funcionamiento del cliente se puede utilizar para evitar el efecto de fallo original
cambiando a un estado operativo degradado (incluida la desactivación del vehículo),
informando al conductor y/o escribiendo un código de problemas de diagnóstico
(DTC) en unidad de control para fines de servicio. En términos de FMEA, el resultado
de la detección y respuesta de diagnóstico CONFIABLE es eliminar (prevenir) el efecto
original, y reemplazarlo con un nuevo efecto menos severo.
FMEA-MSR es útil para decidir si el diseño del sistema cumple con los requisitos de
rendimiento con respecto a la seguridad y el cumplimiento. Los resultados pueden
incluir elementos tales como:
• es posible que se necesiten sensores adicionales para fines de monitoreo
• puede ser necesaria la redundancia en el procesamiento
• Las comprobaciones de verosimilitud pueden revelar fallos en el sensor
PROPOSITO: PREPARACION
Los principales objetivos de Planificación y Preparación en FMEA-MSR son:
• Plan de proyecto (InTent, Timing, Equipo, Tareas, Herramientas (5T))
• Identificación de FMEA basal
• Base para el paso Análisis de estructura
PREPARACION
Identificación y Límites del Proyecto FMEA-MSR
Identificación y límites de proyectos FMEA-MSR
La identificación del proyecto FMEA-MSR incluye una comprensión clara de lo que debe evaluarse. Esto
implica un proceso de toma de decisiones para definir los FMEA-MSR que se necesitan para un programa
de cliente. Lo que debe excluir puede ser tan importante como qué incluir en el análisis.
Lo siguiente puede ayudar al equipo a definir proyectos FMEA-MSR, según corresponda:
• Análisis de riesgos y evaluación de riesgos
• Requisitos legales
• Requisitos técnicos
• Deseos/necesidades/expectativas del cliente (clientes externos e internos)
• Especificación de requisitos
• Diagramas (Bloque/Límite/Sistema)
• Esquemas, dibujos y/o modelos 3D
• Lista de materiales (BOM), Evaluación de riesgos
• FMEA anterior para productos similares
Las respuestas a estas preguntas y otras definidas por la empresa ayudan a crear la lista de proyectos
FMEA-MSR necesarios. La lista de proyectos FMEA- MSR asegura una dirección, un compromiso y un
enfoque coherentes.
PREPARACION
A continuación se presentan algunas preguntas básicas que ayudan a identificar los límites de FMEA-MSR:
(1) Después de completar un DFMEA en un Sistema Electrónico Eléctrico/Electrónico/Programable, ¿existen
efectos que puedan ser perjudiciales para las personas o implicar incumplimiento normativo?
(2) ¿Indicó dfmea que todas las causas que conducen a daños o incumplimiento pueden detectarse
mediante la noción directa y/o algoritmos de verosimilitud?
(3) ¿Indicó el DFMEA que la respuesta prevista del sistema a todas y cada una de las causas detectadas es
cambiar a un estado operativo degradado (incluida la desactivación del vehículo), informar al conductor y/o
escribir un Código de Problemas de Diagnóstico (DTC) en la unidad de control para para fines de servicio?
FMEA para Monitoreo y Respuesta del Sistema puede utilizarse para examinar los sistemas que han
integrado mecanismos de monitoreo y respuesta a fallas durante el funcionamiento. Típicamente, estos son
sistemas más complejos compuestos de sensores, actuadores y unidades de procesamiento lógico. El
diagnóstico y el seguimiento en dichos sistemas pueden lograrse a través de hardware y/o software.
Los sistemas que pueden considerarse en un FMEA Suplementario para Monitoreo y Respuesta del Sistema
consisten en general en al menos un sensor, una unidad de control y un actuador o un subconjunto de ellos
y se llaman sistemas mecatrónicos. Los sistemas en el ámbito también pueden consistir en componentes
mecánicos de hardware (por ejemplo, neumáticos e hidráulicos).
El alcance de un FMEA Suplementario para Monitoreo y Respuesta del Sistema puede establecerse en
consulta entre el cliente y el proveedor. Los criterios de ámbito aplicables pueden incluir, pero no se limitan
a:
1. Relevancia de la seguridad del sistema
2. Normas ISO, es decir, Objetivos de Seguridad según ISO 26262
3. Requisitos de documentación de los órganos legislativos, por ejemplo, Reglamento de las Naciones
Unidas/CEPE, FMVSS/CMVSS, NHTSA y Cumplimiento de los Requisitos de Diagnóstico a bordo (OBD)
PREPARACION
Plan de Proyecto FMEA-MSR
Una vez que se conozca el proyecto FMEA-MSR, se debe elaborar un plan para la
ejecución del FMEA-MSR.
Se recomienda utilizar el método 5T (Intención, Tiempo, Equipo, Tareas, Herramienta)
como se describe en la sección 1.5 de este manual. El plan para el FMEA-MSR ayuda a
la empresa a ser proactiva en el inicio del FMEA-MSR temprano. Las actividades de
FMEA-MSR (proceso de 7 pasos) deben incorporarse al plan general del proyecto de
diseño.
Propósito
Los principales objetivos del Análisis de Estructura en FMEA-MSR son:
• Árbol de estructura o equivalente: diagrama de bloques, diagrama de límites,
modelo digital, partes físicas
• Identificación de interfaces de diseño, interacciones
Dependiendo del alcance del análisis, la estructura puede consistir en elementos de
hardware y elementos de software. Las estructuras complejas pueden dividirse en
varias estructuras (paquetes de trabajo) o diferentes capas de diagramas de bloques y
analizarse por separado por razones organizativas o para garantizar una claridad
suficiente.
El alcance de la FMEA-MSR se limita a los elementos del sistema para los que el
DFMEA de referencia demostró que hay causas de fallo que pueden dar lugar a
efectos peligrosos o no conformes. El alcance puede ampliarse para incluir las señales
recibidas por la unidad de control.
.
Para visualizar una estructura del sistema, se utilizan comúnmente dos métodos:
• Diagramas de bloques (límites)
• Estructurar árboles
Para obtener más detalles, consulte la Sección 2.2 Diseño FMEA.
ESTRUCTURA DE ARBOL
En un FMEA Suplementario para Monitoreo y Respuesta del Sistema, el elemento raíz
de un árbol de estructura puede estar a nivel de vehículo, es decir, para los
fabricantes de necesidades que analizan el sistema general (véase la figura 4.2-1) o a
nivel del sistema, es decir, para proveedores que analizan un subsistema o
componente ( véase la Figura 4.2-2).
PROPOSITO
Los principales objetivos del análisis de funciones en FMEA-MSR son:
• Visualización de funciones y relaciones entre funciones
• Árbol de funciones/red de funciones, o diagrama de parámetros equivalente
(diagrama P)
• Cascada de funciones de cliente (externas e internas) con requisitos asociados
• Base para el paso Análisis de fallos
En un FMEA Suplementario para Monitoreo y Respuesta del Sistema, la supervisión
para la detección de fallas y las respuestas a errores se consideran funciones. Las
funciones de hardware y software pueden incluir la supervisión de los estados del
sistema.
Las funciones de supervisión y detección de fallos/fallos pueden consistir, por
ejemplo: detecciones fuera del rango, comprobaciones de redundancia cíclica,
comprobaciones de verosimilitud y comprobaciones de contadores de secuencias.
Las funciones para las reacciones de error pueden consistir, por ejemplo, en la
provisión de valores predeterminados, el cambio a un modo de inicio cojeo, la
desactivación de la función correspondiente y/o la visualización de una advertencia.
PROPOSITO
Estas funciones se modelan para aquellos elementos estructurales que son
portadores de estas funciones, es decir, unidades de control o componentes con
capacidades computacionales como sensores inteligentes.
Además, se pueden considerar señales de sensor que son recibidas por las unidades
de control. Por lo tanto, las funciones de las señales también pueden describirse.
Por último, se pueden añadir funciones de actuadores, que describen la forma en que
el actuador o el vehículo reacciona a petición.
Se supone que los requisitos de rendimiento son el mantenimiento de un estado
seguro o conforme. El cumplimiento de los requisitos se evalúa a través de la
evaluación del riesgo.
En caso de que los sensores y/o actuadores no estén dentro del ámbito de análisis, las
funciones se asignan a los elementos de interfaz correspondientes (de acuerdo con el
concepto de seguridad, según corresponda).
Función
Una función describe lo que el elemento de proceso o el paso de proceso está destinado a hacer. Puede haber
más de una función para cada elemento de proceso o paso de proceso.
Antes de comenzar el Análisis de funciones, la información que se recopilaría podía incluir, entre otras,;
funciones de producto y proceso, requisitos de producto/proceso, condiciones ambientales de fabricación,
tiempo de ciclo, requisitos de seguridad ocupacional u operador, impacto ambiental, etc. Esta información es
PROPOSITO
Estas funciones se modelan para aquellos elementos estructurales que son
portadores de estas funciones, es decir, unidades de control o componentes con
capacidades computacionales como sensores inteligentes.
Además, se pueden considerar señales de sensor que son recibidas por las unidades
de control. Por lo tanto, las funciones de las señales también pueden describirse.
Por último, se pueden añadir funciones de actuadores, que describen la forma en que
el actuador o el vehículo reacciona a petición.
Se supone que los requisitos de rendimiento son el mantenimiento de un estado
seguro o conforme. El cumplimiento de los requisitos se evalúa a través de la
evaluación del riesgo.
En caso de que los sensores y/o actuadores no estén dentro del ámbito de análisis, las
funciones se asignan a los elementos de interfaz correspondientes (de acuerdo con el
concepto de seguridad, según corresponda).
PROPOSITO
El propósito del análisis de fallos en FMEA-MSR es describir la cadena de eventos que
conducen al efecto final, en el contexto de un escenario relevante.
Los principales objetivos del análisis de fallos en FMEA-MSR son:
• Establecimiento de la cadena de fallas
• Posible causa de falla, monitoreo, respuesta del sistema, efecto de falla reducida
• Identificación de las causas de fallos del producto mediante un diagrama de
parámetros o una red de fallos
• Base para la documentación de fallos en la hoja de formulario FMEA y en el paso
ESCENARIO DE FALLAS
Un escenario de error se compone de una descripción de las condiciones de
funcionamiento relevantes en las que un error da como resultado un
comportamiento incorrecto y posibles secuencias de eventos (estados del sistema)
que conducen a un estado final del sistema (efecto de error). Comienza a partir de
causas de error definidas y conduce a los efectos de error. (Véase la Figura 4.4- 1)
MODELO DE LA CADENA DE MODOS DE FALLA DFMEA – FMEA MSR
El enfoque del análisis es un componente con capacidades de diagnóstico, por
ejemplo, una ECU.
Si el componente no es capaz de detectar el error/fallo, se producirá el modo de error
que conduce al efecto final con el grado de gravedad correspondiente.
Sin embargo, si el componente puede detectar el error, esto conduce a una respuesta
del sistema con un efecto de error con una gravedad menor en comparación con el
efecto de error original. Los detalles se describen en los siguientes escenarios (1) a
(3).
El escenario de falla (1) describe el comportamiento del mal funcionamiento de la

ocurrencia del error al efecto de falla, que en este ejemplo no es peligroso pero
puede alcanzar un estado del sistema final no conforme.
El escenario de falla (2) describe el comportamiento del mal funcionamiento de la

ocurrencia del error al efecto de falla, que en este ejemplo conduce a un evento
peligroso.
Como aspecto del escenario de error, es necesario estimar la magnitud del intervalo
de tiempo de manipulación de fallas (tiempo entre la ocurrencia de la falla y la
aparición del efecto de fallo de peligro/no conforme).
El intervalo de tiempo de manipulación de fallas es el intervalo de tiempo máximo de
mal funcionamiento antes de que ocurra un evento peligroso, si los mecanismos de
seguridad no están activados.
Escenario de error (3) - Mitigado (efecto)
El escenario de falla (3) describe el comportamiento de mal funcionamiento de la

ocurrencia del error al efecto de error mitigado, que en este ejemplo conduce a una
pérdida o degradación de una función en lugar del evento peligroso.
CAUSA DE FALLA
La descripción de la causa del error es el punto de partida del análisis de fallas en un
FMEA suplementario para la supervisión y la respuesta del sistema. Se supone que se
ha producido la causa de error y no es la verdadera causa de error (causa raíz). Las
causas típicas de fallas son fallas eléctricas/electrónicas (fallos E/E) (consulte el
Apéndice C2). Las causas de la raíz pueden ser una robustez insuficiente cuando se
exponen a varios factores como el entorno externo, la dinámica del vehículo, el
desgaste, el servicio, el ciclo de tensión, la sobrecarga de bus de datos y los estados
de señal erróneos, etc. Las causas de error pueden.
se derivan de DFMEA, catálogos para fallas de componentes E/E y descripciones de
datos de comunicación de red.
CAUSA DE FALLA
Los equipos pueden decidir no incluir errores de supervisión de diagnóstico en
DFMEA porque las clasificaciones de ocurrencia sa menudo son muy bajas
(incluyendo "fallos latentes" Ref. ISO 26262). Por lo tanto, este análisis puede ser de
valor limitado. Sin embargo, la implementación correcta de la supervisión de
diagnóstico debe formar parte del protocolo de prueba.
Los controles de prevención de diagnósticos en un DFMEA describen cuán confiable
es un mecanismo para detectar la causa de falla y reacciona a tiempo con respecto a
los requisitos de rendimiento.
Los controles de detección de diagnósticos en un DFMEA se relacionarían de nuevo
con las pruebas de desarrollo que verifican la correcta implementación y la eficacia
del mecanismo de supervisión.
CAUSA DE FALLA
Los equipos pueden decidir no incluir errores de supervisión de diagnóstico en
DFMEA porque las clasificaciones de ocurrencia sa menudo son muy bajas
(incluyendo "fallos latentes" Ref. ISO 26262). Por lo tanto, este análisis puede ser de
valor limitado. Sin embargo, la implementación correcta de la supervisión de
diagnóstico debe formar parte del protocolo de prueba.
Los controles de prevención de diagnósticos en un DFMEA describen cuán confiable
es un mecanismo para detectar la causa de falla y reacciona a tiempo con respecto a
los requisitos de rendimiento.
Los controles de detección de diagnósticos en un DFMEA se relacionarían de nuevo
con las pruebas de desarrollo que verifican la correcta implementación y la eficacia
del mecanismo de supervisión.
MODO DE FALLA
Un modo de error es la consecuencia del error (causa del error). En FMEA-MSR se
consideran dos posibilidades:
a. En caso de escenarios de falla (1) y (2) no se detecta el fallo o la reacción del
sistema es demasiado tarde. Por lo tanto, el modo de falla en FMEA-MSR es lo mismo
que en DFMEA. (véase la Figura 4.4-5).
b. Diferente es el escenario de falla (3), donde se detecta el error y la respuesta del
sistema conduce a un efecto de error mitigado. En este caso, se agrega al análisis una
descripción para la supervisión de diagnóstico y la respuesta del sistema. Debido a
que la cadena de errores en esta posibilidad específica consiste en un error/error y
una descripción de un comportamiento previsto, esto se denomina una cadena de
fallas híbrida o una red de falla híbrida (consulte la figura 4.4-6).
MODO DE FALLA
Un modo de error es la consecuencia del error (causa del error). En FMEA-MSR se
consideran dos posibilidades:
a. En caso de escenarios de falla (1) y (2) no se detecta el fallo o la reacción del
sistema es demasiado tarde. Por lo tanto, el modo de falla en FMEA-MSR es lo mismo
que en DFMEA. (véase la Figura 4.4-5).
b. Diferente es el escenario de falla (3), donde se detecta el error y la respuesta del
sistema conduce a un efecto de error mitigado. En este caso, se agrega al análisis una
descripción para la supervisión de diagnóstico y la respuesta del sistema. Debido a
que la cadena de errores en esta posibilidad específica consiste en un error/error y
una descripción de un comportamiento previsto, esto se denomina una cadena de
fallas híbrida o una red de falla híbrida (consulte la figura 4.4-6).
EFECTO DE FALLA
Un efecto de error se define como la consecuencia de un modo de error. Los efectos
de error en FMEA-MSR son un comportamiento incorrecto del sistema o un
comportamiento previsto después de la detección de una causa de error. El efecto
final puede ser un "peligro" o "estado no conforme" o, en caso de detección y
respuesta oportuna del sistema, un "estado seguro" o "estado de cumplimiento" con
pérdida o degradación de una función.
La gravedad de los efectos de error se evalúa en una escala de diez puntos según la
tabla MSR1 y la tabla D1, respectivamente.
PROPOSITO
El propósito del análisis de riesgos en FMEA-MSR es estimar el riesgo de fracaso
mediante la evaluación de la gravedad, la frecuencia y la supervisión, y priorizar la
Los principales objetivos del Análisis de Riesgo FMEA-MSR son:

• Clasificación de gravedad, frecuencia y monitoreo para cada cadena de fallas.
• Colaboración entre cliente y proveedor (Gravedad)

Las causas de fallo se clasifican por ocurrencia, teniendo en cuenta la eficacia del
control de prevención actual (Capítulo Evaluación de Riesgos).
Los controles de prevención actuales describen las medidas que deben
implementarse en el proceso de diseño y verificarse durante el prototipo, las
cualificaciones de la máquina (ejecución) y la verificación del proceso antes del inicio
de la producción regular. Los controles de prevención también pueden incluir
instrucciones de trabajo estándar, procedimientos de configuración, mantenimiento
preventivo, procedimientos de calibración, procedimientos de verificación de prueba
de errores, etc.
Definición: Los controles de detección actuales detectan la existencia de una causa de
error o el modo de error, ya sea mediante métodos automatizados o manuales, antes
de que el artículo salga del proceso o se envíe al cliente.
• Inspección visual
• Inspección visual con lista de verificación de muestras
• Inspección óptica con sistema de cámara
• Prueba óptica con muestra de límite
• Prueba atributiva con mandril
• Comprobación dimensional con un calibre de pinza
• Inspección aleatoria
• Monitoreo de par
• Monitoreo de la carga de prensa
• Comprobación de la función de fin de línea
CONTROLES ACTUALES DE PREVENCION Y DETECCION

Los controles actuales de prevención y detección deben confirmarse para que se
implementen y sean eficaces. Esto se puede hacer durante una revisión en la estación
(por ejemplo, Revisión lateral de línea, caminatas de línea y auditorías regulares). Si el
control no es efectivo, puede ser necesaria una acción adicional.
Las clasificaciones de Ocurrencia y Detección deben revisarse al utilizar datos de
procesos anteriores, debido a la posibilidad de diferentes condiciones para el nuevo
proceso.
EVALUACIONES
Cada relación de modo de error, causa y efecto (cadena de fallos o red híbrida) se
evalúa por los tres criterios siguientes:
Gravedad (S): representa la gravedad del efecto de fallo
Frecuencia (F): representa la Frecuencia de Ocurrencia de
la causa en una situación operativa determinada, durante la vida útil prevista del
vehículo
Monitoreo (M): representa el potencial de detección de la
Funciones de supervisión de diagnóstico (detección de la causa del error, modo de
error y/o efecto de error)
Los números de evaluación del 1 al 10 se utilizan para S, F y M respectivamente,
donde 10 representa la contribución de mayor riesgo.
Al examinar estas calificaciones individualmente y en combinaciones de los tres
factores, se puede priorizar la necesidad de acciones de reducción de riesgos.
SEVERIDAD (S)
La clasificación de gravedad (S) es una medida asociada con el efecto de error más
grave para un modo de error determinado de la función que se está evaluando y es
idéntica para DFMEA y FMEA-MSR.
La gravedad debe estimarse utilizando los criterios de la tabla de gravedad MSR1. La
tabla se puede aumentar para incluir ejemplos específicos del producto. El equipo del
que sea coherente incluso si se modifica para el análisis de diseño individual.
Las evaluaciones de gravedad de los efectos de error deben ser transferidas por el
cliente al proveedor, según sea necesario.
Razones para la clasificación de frecuencias
En un FMEA Suplementario para Monitoreo y Respuesta del Sistema, la probabilidad
de que no ocurra en el campo bajo las condiciones de operación del cliente durante la
vida útil es relevante.
El análisis de la operación del usuario final requiere suposiciones de que el proceso de
fabricación está adecuadamente controlado para evaluar la suficiencia del diseño.
Ejemplos en los que una justificación puede basarse en:
• Evaluación basada en los resultados de Design FMEAs
• Evaluación basada en los resultados de los FMEA de Proceso
• Datos de campo de devoluciones y partes rechazadas
• Quejas de clientes
• Bases de datos de garantía
• Manuales de datos
La justificación se documenta en la columna "Rationale for Frequency Rating" de la
hoja de formulario FMEA-MSR.
FRECUENCIA
La clasificación de frecuencia (F) es una medida de la probabilidad de aparición de la
causa en situaciones de funcionamiento relevantes durante la vida útil prevista del
vehículo o del sistema utilizando los criterios del cuadro MSR2.
Si la causa del fallo no siempre conduce al efecto de fallo asociado, la clasificación
puede adaptarse, teniendo en cuenta la probabilidad de exposición a la condición de
funcionamiento pertinente (según el cuadro MSR2). En tales casos, la situación
operativa y la justificación deben indicarse en la columna "Rationale for Frequency
Rating".
Ejemplo: A partir de los datos de campo se sabe con qué frecuencia una unidad de
control es defectuosa en ppm/año. Esto puede llevar a F-3. El sistema bajo
investigación es un sistema de estacionamiento que se utiliza sólo un tiempo muy
limitado en comparación con el tiempo de funcionamiento total. Por lo tanto, el daño
a las personas sólo es posible cuando el defecto ocurre durante la maniobra de
estacionamiento. Por lo tanto, la frecuencia puede ser bajada a F-2.
Frequency Potential (F) for the Product
Frequencycriteria(F)fortheestimatedoccurrenceoftheFailureCause in relevant operating situations during Blank until
the intended service life of the vehicle filled in by
user
Estimated Corporateor
F Frequency Frequency criteria - FMEA-MSR ProductLine
Examples
Extremely Frequency of occurrence of the Failure Cause is unknown
10 high or cannot be orknown to be unacceptably high during the intended service life of the
determined vehicle
9 Failure Cause is likely to occur during the intended service life of the vehicle
High
8 Failure Cause may occur often in the field during the intended service life
of thevehicle
7 Failure Cause may occur frequently in the field during the intended service
life of thevehicle
6 Medium Failure Causemayoccursomewhatfrequently in thefield during the
intended service life of the vehicle
5 Failure Cause mayoccur occasionally in the field during the intended service
life of thevehicle.
Failure Cause is predicted to occur rarely in the field during the intended
4 Low service life of the vehicle. At least ten occurrences in the field are
predicted.
Failure Cause is predicted to occur in isolated cases in the field during the
3 Very low intended service life of the vehicle. At least one occurrence in the field is
predicted.
Failure Cause is predicted not to occur in the field during the intended
service life of the vehicle based on prevention and detection controls
2 Extremely low and field experience with similar parts. Isolated cases cannot be ruled out.
No
proof it will not happen.
FailureCausecannotoccurduringtheintendedservice life of thevehicleor

1 Cannot Occur is virtually eliminated.Evidencethat
Failure Cause cannot occur. Rationale is documented.
Controles de monitoreo actuales

Todos los controles planificados o ya implementados y que conducen a una detección
de la causa de error, el modo de error o el efecto de error por el sistema o por el
controlador se introducen en la columna "Controles de supervisión actuales".
Además, se debe describir la reacción de error después de la detección, es decir, la
provisión de valores predeterminados (si no se describe namente suficientemente por
el efecto de error).
La supervisión evalúa el potencial que la causa del error, el modo de error o el efecto
de error se pueden detectar lo suficientemente pronto para que el efecto de error
inicial se pueda mitigar antes de que se produzca un peligro o se alcance un estado no
conforme. El resultado es un efecto de estado final con una gravedad menor.
Monitoreo
La clasificación de supervisión (M) es una medida de la capacidad de detectar un
fallo/fallo durante el funcionamiento del cliente y aplicar la reacción de falla para
mantener un estado seguro o conforme.
La clasificación de monitoreo se relaciona con la capacidad combinada de todos los
sensores, la lógica y la percepción sensorial humana para detectar la falla/fallo; y
reaccionar modificando el comportamiento del vehículo mediante accionamiento
mecánico y reacción física (controlabilidad). Para mantener un estado de
funcionamiento seguro o conforme, la secuencia de detección y reacción de fallas
debe tener lugar antes de que se produzca el efecto peligroso o no conforme. La
clasificación resultante describe la capacidad de mantener un estado de operación
seguro o conforme.
La supervisión es una calificación relativa dentro del alcance de la FMEA individual y
se determina sin tener en cuenta la gravedad o la frecuencia. El seguimiento debe
estimarse utilizando los criterios del cuadro MSR3. Esta tabla se puede aumentar con
ejemplos de supervisión común. El equipo del proyecto FMEA debe acordar un
criterio de evaluación y un sistema de calificación que sea coherente, incluso si se
modifica para el análisis individual de productos.
Monitoreo
La suposición es que la supervisión se implementa y se prueba como diseñada. La
eficacia de la supervisión depende del diseño del hardware del sensor, la redundancia
del sensor y los algoritmos de diagnóstico que se implementan. Las métricas de
plausibilidad por sí solas no se consideran eficaces. Refiera a la tabla MSR3.
La aplicación del seguimiento y la verificación de la eficacia debe formar parte del
proceso de desarrollo y, por lo tanto, puede analizarse en el DFMEA correspondiente
del producto. (véase NOTA para las causas de fallos en la Sección 4.4.1).
La eficacia de la supervisión y respuesta de diagnóstico, el tiempo de respuesta de
supervisión de fallas y el intervalo de tiempo tolerante a errores deben determinarse
antes de la clasificación. Determinación de la La eficacia de la monitorización
diagnóstica se aborda en detalle en el anexo D de la ISO 26262-5:2018.
En la práctica, pueden distinguirse tres casos diferentes de supervisión/respuesta:
Si no hay control de supervisión, o si la supervisión y la respuesta no se producen

dentro del intervalo de tiempo de control de fallas, la supervisión debe calificarse
como no eficaz (M-10).
Monitoreo de Diagnóstico Confiable FMEA-MSR
El efecto de fallo original se elimina virtualmente. Sólo el efecto de fallo mitigado

sigue siendo relevante para la estimación del riesgo del producto o sistema. En este
caso solamente, el FE mitigado es relevante para la clasificación de prioridad de
acción, no para el FE original.
La asignación de las clasificaciones de supervisión a las causas de errores y sus
controles de supervisión correspondientes puede variar en función de:
a. Variaciones en el modo causa o fallo de error
b. Variaciones en el hardware implementado para la supervisión diagnóstica
c. El tiempo de ejecución del mecanismo de seguridad, es decir, el fallo se detecta
durante el "encendido" solamente
d. Variaciones en la respuesta del sistema
e. Variaciones en la percepción y reacción humana
f. Conocimiento de la ejecución y eficacia de otros proyectos (novedad)
Dependiendo de estas variaciones o del tiempo de ejecución, es posible que los
controles de supervisión no se consideren confiables en el sentido de M-1.
Monitoreo de Diagnóstico Confiable FMEA-MSR3
Monitoreo diagnóstico FMEA-MSR parcialmente efectivo
El efecto de error original se produce con menos frecuencia. La mayoría de los errores
se detectan y la respuesta del sistema conduce a un efecto de error mitigado. El
riesgo reducido se representa mediante la clasificación de supervisión.
El efecto de fallo más grave sigue siendo S-10.
Supplemental FMEA for Monitoring and System Response (M)
Monitoring Criteria (M) for Failure Causes, Failure Modes and Failure Effects by Monitoring duringCustomer Blank until
Operation.Usetheratingnumberthatcorrespondswith the least effective of either criteria for Monitoring or System filled in by
Response user
Effectiveness of
Monitoring Controls System Response / Human Corporateor
Diagnostic Monitoring / Sensory
and System Reaction Criteria ProductLine
M Perception Criteria
Response Examples
Thefault/failure cannotbedetectedat all or not No response during the Fault

during the Fault Handling TimeInterval;bythesystem, Handling Time Interval.
10 Not effective thedriver, a passenger, or service technician.
Thefault/failure canalmostneverbe detected in The reaction to the

relevant operating conditions.Monitoringcontrol fault/failure by the system
withlow effectiveness,highvariance,orhigh or the driver maynot
9 Very Low uncertainty. Minimaldiagnostic reliably occur during the
coverage. Fault
Handling Time Interval.
The fault/failure canbedetectedinvery few relevant The reaction to the fault/failure

operatingconditions. by the system or the driver may
Monitoring control with low effectiveness, high not always occur during the
8 Low variance, or high uncertainty. Diagnostic coverage Fault Handling Time Interval.
estimated <60%.
Low probability of detecting the fault/failure Low probability of reacting to the

duringtheFaultHandling Time Interval by the detected fault/failure during the
system or the driver. Monitoring control with Fault Handling Time Interval by
Moderately Low low effectiveness,highvariance,orhigh the system or the driver.
7
uncertainty. Diagnosticcoverage
estimated >60%.
Thefault/failure willbeautomatically detected by The automatedsystem or the

the system or the driver only during power-up, driver will be able toreact tothe
6 with medium varianceindetectiontime.Diagnostic detected fault/failure in many
coverage estimated>90%. operatingconditions.
Moderate
The fault/failure will be automatically detected by The automatedsystem or the
thesystemduringtheFault Handling Time Interval, driver will beable to react to
with medium variancein detection time, ordetected the detected fault/failure
5 by the driver in very many operating conditions. during the Fault Handling
Diagnostic coverage estimated between 90% -97%. Time Interval in very many
operating conditions.
Supplemental FMEA for Monitoring and System Response (M)
Monitoring Criteria (M) for Failure Causes, Failure Modes and Failure Effects by Monitoring Blank
during Customer Operation. Usetherating number thatcorrespondswith the until
least effective of either criteria for Monitoring or System filled in
Response by
user
Effectiveness of
Monitoring System Response / Human Corporateor
Diagnostic Monitoring /
M Controls and Reaction Criteria ProductLine
Sensory Perception Criteria Examples
System
Response
The fault/failure will be automatically The automatedsystem or
detected bythe system during the Fault the driver will be able to
Handling Time Interval, with medium react to the detected
Moderately
4 variance in detection time, or detected by fault/failure during the
High
the driver in most operating conditions. Fault Handling Time
Diagnosticcoverage interval, in most
estimated >97%. operating conditions.
The system will
automatically react to
The fault/failure will be automatically thedetectedfault/failure
detected bythe system during the Fault during the Fault Handling
Handling Time Interval with very low Time Interval in most
3 High variance in detection time, and with a high operating conditions with
probability. very low variance in
Diagnostic coverage estimated >99%. system
response time, and with a
high probability.
The system will
automatically react to the
The fault/failure will be detected
detectedfault/failure
automatically bythe system with very low
during the Fault Handling
variance in detection time during the Fault
2 Very High Time Interval with very
Handling Time Interval, and withavery
low variance in system
highprobability. Diagnostic coverage
responsetime,
estimated >99.9%.
and with a very high
probability.
Reliable and Thefault/failure will always bedetected The system will always
acceptable for automaticallybythesystem.Diagnostic automatically react to
1 elimination of coverage estimated tobe significantly thedetectedfault/failure
originalFailure greater than 99.9%. during the Fault
Effect. Handling Time Interval.
La Prioridad de Acción es una metodología que permite la priorización de la
necesidad de acción, teniendo en cuenta la Gravedad, Frecuencia y Monitoreo (SFM).
Esto se hace mediante la asignación de calificaciones de MFS que proporcionan una
base para la estimación del riesgo.
Consulte los capítulos anteriores para obtener información sobre cómo reducir el
riesgo primero por S, luego F y luego M.
Prioridad alta (H): Prioridad alta (H): Máxima prioridad para la revisión y la acción.
El equipo debe identificar una acción adecuada para reducir la frecuencia y/o
mejorar los controles de supervisión o justificar y documentar por qué los controles
actuales son adecuados.

El equipo debe identificar las acciones apropiadas para reducir la frecuencia y/o
mejorar los controles de monitoreo, o, a discreción de la empresa, justificar y
documentar por qué los controles son adecuados.
El equipo podría identificar acciones para reducir la frecuencia y/o mejorar los
controles de monitoreo
Se recomienda que los posibles efectos de error de gravedad 9-10 con Action
Priority High y Medium, como mínimo, sean revisados por la administración,
incluidas las acciones recomendadas que se tomaron.
Esta no es la priorización de alto, medio o bajo riesgo. Es la priorización de la
Action Priority (AP) for FMEA-MSR
ActionPriorityisbasedoncombinationsofSeverity,Frequency,andMonitoringratingsinorderto prioritize actions for riskreduction.
Prediction of Failure Cause

Occurring During Service ACTION
Effect S Life of Vehicle F Effectiveness of M PRIORITY
Monitoring (AP)
5-10 Reliable - Not effective 1-10 H

Medium - Extremely
high
Moderately high - Not 4-10 H
effective
Low 4
Very high - High 2-3 H
Product Effect High Reliable 1 M
10
Moderately high - Not 4-10 H
effective
Very low 3
Very high - High 2-3 M
Reliable 1 L
Moderately high - Not 4-10 M
Extremely low 2 effective
Reliable - High 1-3 L

Cannot occur 1 Reliable - Not effective 1-10 L
Low - Extremely high 4-10 Reliable - Not effective 1-10 H
Extremely low - Very low 2-10 H

Product Effect High Very high - Not
2-3
9
effective
Reliable - High 1 L
Medium - Extremely 6-10 Reliable - Not effective 1-10 H

high
5-10 H
Moderately high - Not
Medium 5
effective
1-4 M
Reliable - Moderately
high
Product Effect Moderately
high 7-8 Moderately low - Not 7-10 H
effective
Low 4
4-6 M
Moderately high -
Moderate
Reliable - High 1-3 L
Very low - Not effective 9-10 H
Very low 3 Moderately low - Low 7-8 M

Reliable - Moderate 1-6 L
7-10 M
Moderately low - Not
Extremely low 2
effective

Action Priority (AP) for FMEA-MSR
ActionPriorityisbasedoncombinationsofSeverity,Frequency,andMonitoringratingsinorderto prioritize actions for riskreduction.
Prediction of
Failure Cause ACTION PRIORITY
Effectiveness of Monitoring
Effect S Occurring F M (AP)
During Service
Life of Vehicle
High - Extremely 7-10 Reliable - Not effective 1-10 H

high
6-10 H
Product Effect Moderately low Moderate - Not effective
M 5-6
e 1-5 M
Reliable - Moderately high
4-6 d
i
u
m
Very low - Not effective 9-10 M
7-8 M
Moderately high - Moderate
Extremely low 2-4
- Low
Cann 1 Reliable - Not effective 1-10 L
ot
occur
High - Extremely 7-10 Reliable - Not effective 1-10 H

high
7-10 M
2-3
Product Effect Low M 5-6 Moderately low - Not effective
e Reliable - Moderate 1-6 L
d
i
u
m
Extremely low - 2-4 Reliable - Not effective 1-10 L
Low
Cann 1 Reliable - Not effective 1-10 L

ot
occur
Product Cannot
1 occur - 1-10 Reliable - Not effective 1-10 L
Effect Very Low Extrem
ely high
NOTE 1: If M=1, the Severity rating of the Failure Effect after Monitoring and System Response is to be used for determining MSR Action Priority.
If M is not equal to 1, then the Severity Rating of the original Failure Effect is to be used for determining MSR Action Priority.
NOTE 2: When FMEA-MSR is used, and M=1, then DFMEA Action Prioritization replaces the severity rating of the original Failure Effect with the Severity rating
of the mitigated Failure Effect.
PROPOSITO
El objetivo principal de optimización en FMEA-MSR es desarrollar acciones que
reduzcan el riesgo y mejoren la seguridad. En este paso, el equipo revisa los
resultados del análisis de riesgos y evalúa las prioridades de acción.
Los principales objetivos de FMEA-MSR Optimization son:
• Asignación de responsabilidades y fechas de finalización previstas para la
implementación de la acción
• Base para el refinamiento de los requisitos del producto y los controles de
prevención/detección
PROPOSITO
Las prioridades de acción alta y media pueden indicar la necesidad de mejorar
técnicamente.
Las mejoras pueden lograrse mediante la introducción de componentes más fiables
que reducen el potencial de aparición de la causa de fallo en el campo o introducen
una supervisión adicional que mejora las capacidades de detección del sistema. La
introducción de la supervisión es similar al cambio de diseño. La frecuencia de la
causa del error no se cambia. También puede ser posible eliminar el efecto de fallo
mediante la introducción de redundancia.
.
PROPOSITO
• Modificaciones del diseño de componentes para reducir la frecuencia (F) de la causa
de fallo (FC)
• Aumente la capacidad de supervisión (M) para la causa de falla (FC) o el modo de
fallo (FM).
En el caso de modificaciones de diseño, todos los elementos de diseño afectados se
evalúan de nuevo.
que se basaba en un concepto de diseño diferente
(TCD) asociada.
acción.
La fecha de finalización real se documenta, incluida la fecha en que se implementan
las acciones.
producción).
Abierto
No se ha definido ninguna acción.
Decisión pendiente (opcional)
La acción ha sido definida, pero aún no se ha decidido. Se está creando un documento
de decisión.
Completado
No implementado

las acciones. El cierre de todas las acciones debe documentarse antes de que la FMEA
se libere al inicio de la producción (SOP).
riesgo de falla se lleva adelante en el diseño del producto

Cuando se ha completado una acción, se vuelven a evaluar los valores de Frecuencia y
Supervisión, y se puede determinar una nueva Prioridad de acción.
La reevaluación debe basarse en la eficacia de las medidas de supervisión preventiva
y diagnóstica de MSR adoptadas y los nuevos valores se basan en las definiciones de
las tablas de clasificación de frecuencia y supervisión de FMEA-MSR.
mejora continua
FMEA-MSR sirve como un registro histórico para el diseño. Por lo tanto, la gravedad,
la frecuencia y la supervisión originales (S, F,
M) los números no se modifican una vez que se han tomado medidas.
El análisis completado se convierte en un repositorio para capturar la progresión de

las decisiones de diseño y los refinamientos de diseño.
Sin embargo, las clasificaciones originales S, F, M pueden modificarse para los DFMEA
genéricos, de familia o de base porque la información se utiliza como punto de
partida para un análisis específico de la aplicación.
RESULTADOS
PROPOSITO
El propósito del paso de documentación de resultados es resumir y comunicar los
resultados de la actividad Modo de error y Análisis de efectos.
Los principales objetivos de FMEA - MSR Results Documentation son:
adoptadas
• Registro de análisis de riesgos y reducción a niveles aceptables
RESULTADOS
REPORTE DEL AMEF
El alcance y los resultados de un FMEA deben resumirse en un informe. El informe se
puede utilizar con fines de comunicación dentro de una empresa, o entre empresas.
El informe no pretende reemplazar las revisiones de los detalles de FMEA-MSR
cuando lo solicite la administración, los clientes o los proveedores. Se pretende ser un
resumen para el equipo de FMEA-MSR y otros para confirmar la finalización de cada
una de las tareas y revisar los resultados del análisis.
desarrollo.
RESULTADOS
REPORTE DEL AMEF
El diseño del documento puede ser específico de la empresa. Sin
embargo, el informe debe indicar el riesgo técnico de fracaso como parte
del plan de desarrollo y los hitos del proyecto. El contenido puede
incluir lo siguiente:
A. Una declaración de estado final en comparación con las metas
originales establecidas en el Plan de Proyecto 1.5
1. Intención de FMEA – Propósito de este FMEA?
2. FMEA Timing – FMEA fecha de vencimiento?
3. Equipo FMEA – Lista de participantes?
4. Tarea FMEA - ¿Alcance de esta FMEA?
5. Herramienta FMEA – ¿Cómo llevamos a cabo el método de análisis
utilizado?
REPORTE DEL AMEF
B. Un resumen del alcance del RESULTADOS
análisis e identificar las novedades.

proporcionar una copia de las tablas de clasificación S/F/M específicas y el método de
priorización del método de acción (por ejemplo, tabla de prioridad de acción).
a. Compromiso y calendario para cerrar acciones abiertas.
b. Compromiso de revisar y revisar el FMEA-MSR durante la producción en masa para
garantizar la exactitud e integridad del análisis en comparación con el diseño de
producción original (por ejemplo, revisiones activadas a partir de cambios de diseño,
acciones correctivas, etc., basadas en procedimientos de la empresa). (Consulte la
sección 1.4 Caso 3 revisiones de FMEA)
c. Compromiso de capturar "cosas que han ido mal" en la fundación FMEA-MSRs en
beneficio de la reutilización del análisis futuro, cuando corresponda. (Consulte la
sección 1.3.6 De la Fundación y de las FMEA Familiares)
REQUISITOS APLICABLES IATF 16949
IATF 16949:2015
REQUISITOS
ESPECIFICOS DE
CLIENTES
REGLASDEL IATF
CORE TOOLS : IATF 16949

APQP, AMEF,SPC,
MSA, PPAP REQUISITOS DEL
PRODUCTO
Ciclo PDCA (phva) y
la IATF 16949:2016
Sistema de Gestión de la Calidad (4)
La Organización y su
contexto (4) Operacón
(8)
PLAN DO Satisfacción
Planificar Hacer del cliente
Apoyo y evaluación Resultados

Requisitos del Planificación Liderazgo del desempeño
del SGC
cliente (6) (5) (7 y 9)
Productos y
ACT CHECK Servicios
Actuar Verificar
Necesidades y
Mejora
expectativas de partes
(10)
interesadas
Pertinentes (4)
IATF CSR´S
GENERAL MOTORS - IATF 16949 - Customer

Specific Requirements
Mayo de 2019
CARTA DE ESCLARECIMENTOS E ADIÇÕES REFERENTES

A GENERAL MOTORS IATF 16949 CUSTOMERS SPECIFIC
REQUIREMENTS NOVEMBER 01ST, 2017, APLICÁVEIS AOS
FORNECEDORES DAS PLANTAS DA GM AMERICA DO SUL
(ARGENTINA, BRASIL, COLÔMBIA E EQUADOR)
São Caetano do Sul, 14 de Março de 2018.
IATF 16949:2016
• Objetivo
• El objetivo de esta norma de SGC para automoción es el desarrollo
de un sistema de gestión de la calidad que permita la mejora
continua, haciendo hincapié en la prevención de defectos y la
reducción de la variación y el desperdicio en la cadena de
suministro.
• Alcance
• La norma de SGC de automoción define los requisitos del sistema
de gestión de calidad para el diseño y desarrollo, producción y,
cuando es relevante, montaje, instalación y servicio de productos
relacionados con el automóvil, incluyendo productos con software
incorporado.
CSR- 1.1 Scope General
IATF16949:2016, First Edition, Oct 1, 2016, “Automotive Quality Management
System Standard,” ISO9001:2015, Fifth Edition, Sept 15, 2015, “Quality
Management Systems – Requirements”, and this document defines General
Motors fundamental quality system requirements for organizations where
automotive customer-specified parts for production and/or service are
manufactured. Third party certification to IATF16949 shall meet the following
conditions: The certification scope must include both IATF16949 and the
accompanying IATF16949 GMCustomer Specific Requirements, The
certification must be conducted in compliance with the IATF recognized
automotive certification scheme by a certification body currently contracted
and recognized by an IATF Oversight office.
CSR-1.1 Scope General
All IATF16949:2016 requirements, including

the requirements of this document, shall
be addressed in the organization’s quality
management system.
The English language version of

IATF16949:2016 or related reference
documents shall be the official version for
purposes of third party registration.
CSR - 1) Procedimentos Gerais e outros Requisitos para GM América do Sul.
Seção I – Esclarecimentos e adições aos requisitos globais da GM disponibilizados

no site www.iatfglobaloversight.org.
1) Procedimentos Gerais e outros Requisitos para GM América do Sul.
Os procedimentos estão disponibilizados no site
https://gmsupplypower.covisint.com. É de responsabilidade do fornecedor buscar
por atualizações. O fornecedor deve avaliar, anualmente, o atendimentos a cada um
dos requisitos específicos contidos nessa carta mantendo registros dos resultados
das avaliações, incluindo as evidências de conformidade. Caso seja necessária a
contratação de terceiros para a transferência de dados, o fornecedor é responsável
pela integridade dos mesmos. Os procedimentos e diretrizes desta carta não são
mandatórios aos fornecedores tier#1 da GM relacionados a *matéria-prima, material
indireto, material a granel e plantas GM que vendem peças ou serviços a outras
plantas. Excecção fica para fornecedores de blank da GM Argentina, que devem
atender os requisitos citados no documento. *Nota: É considerado matéria-prima
produtos que serão conformados (e.g.: produtos a serem estampados ou injetados)
internamente pela GM.
CSR - 3 Terms and definitions
Accessory Parts Parts manufactured to GM standards, that are

procured or released by GM, and are mechanically attached or
electronically connected to the vehicle before or after final
delivery to the customer.
Bypass Proactive approach to address potential error proofing

failures with a defined and approved process which addresses
the risk as defined in the PFMEA, considering safety, severity
and overall RPN rating. Bypass process is established before a
device failure. Bypass differs from a deviation process as a
deviation process is a reactive process.
CSR - 3 Terms and definitions
Customer References to “customer” in IATF16949:2016 and

this document shall be interpreted as the Procuring Division of
General Motors for suppliers pursuing third party registration
to IATF16949:2016 to satisfy General Motors sourcing
requirements third party quality system assessment
registration.
Severity Score Severity Score for a GM supply organization is
impacted when quality PRR is written with a documented
impact towards the GM final customer, GM manufacturing
plant, and GM product (vehicle, powertrain or component). A
Severity Matrix is used to equate the Plant and or Customer
Impact resulting in a Severity Score
4 Contexto de la
organización (continuación)
• No hay requisitos adicionales a los apartados 4.1 y 4.2, sin
embargo 4.3 y 4.4 tienen ahora requisitos adicionales:
• 4.3.1 Determinar el alcance del Sistema de gestión de la
calidad – suplemento – (ISO/TS 1.1, 1.2 y 4.2.2)
• Apartado 8.3: …mantenido como información documentada (ver ISO
9001, Sección 7.5). (4.3.1)
• 4.3.2 Requisitos específicos de clientes (CSR’s) – (ISO/TS viii

observaciones para la certificación)
• Los requisitos específicos del cliente (CSR) se evaluarán y se incluirán
en el alcance del sistema de gestión de la calidad de la organización.
5 LIDERAZGO
5 LIDERAZGO
5.3
5.1 Roles,
5.2
Liderazgo y Responsabilidades y
Política
Compromiso Autoridades en la
Organización
6 PLANIFICACIÓN
6 PLANIFICACIÓN
6.1 6.2
Acciones para abordar riesgos y Objetivos de la calidad y
oprtunidades planificación para lograrlos
7 APOYO
7 APOYO
7.5
7.1 7.3
Información
Recursos Toma de conciencia
documentada
7.2 7.4
Competencia Comunicación
7 APOYO (continuACIÓN)
• 7.5.3.2.1 Conservación de Registros– (ISO/TS 4.2.4.1)
• Política
• Las aprobaciones de piezas de producción, los registros de
herramientas (incluidos el mantenimiento y la propiedad), los
registros de diseño de productos y procesos, las órdenes de compra
(si procede) o los contratos y modificaciones se conservarán durante
el período de actividad del producto, más un año, a no ser que otra
cosa sea especificada por el cliente o agencia reguladora especifique
• NOTA: La información documentada de aprobación de la pieza de
producción puede incluir un producto aprobado, registros del equipo
de prueba de aplicación o datos de prueba aprobados
• 7.5.3.2.2 Especificaciones de ingeniería – (ISO/TS 4.2.3.1)

• … 10 días laborables
CSR - CUSTOMER SPECIFIC REQUIREMENTS
7.5.3.2.1 Record retention

The organization’s business records shall be
retained as specified in GMW15920
8 OPERACIÓN
8 OPERACIÓN
8.3
8.1 8.5 8.7
Diseño y
Planificaión y Producción y Control de las
desarrollo de
Control Provisión del salidas no
los productos y
Operacional servicio conformes
servicios
8.4
8.2 Control de los procesos,
8.6 Liberación de los
Requisitos para los productos y servicios
productos y servicios
productos y servicios suministrados
externamente
8 OPERAcióN (CONTINUación)
8.2.3.1.2 Caracteristicas especiales definidas por el

cliente
La organización debe cumplir con los requisitos del

cliente para la designación, documentación de
aprobación y control de las características especiales.
8.2.3.1.2 Customer-designated special characteristics

The organization shall follow General Motors Key
Characteristic Designation System Process GMW15049. Key
characteristics shall be applied as per IATF16949:2016 8.3.3.3
Special Characteristics.
8 OPERACIÓN (CONTINUACIÓN)
• 8.3.3.1. Entrada para el Diseño de Producto
La organización debe identificar, documentar y revisar

los requisitos de entrada de diseño de producto como
resultado de la revisión del contrato, los requisitos de
entrada del diseño de producto incluyen, pero no están
limitados a lo siguiente:
8.3.3.1 Product design input

All operations shall be analyzed for risk using a PFMEA.
Product requirements shall be identified and failure modes
comprehended in the PFMEA. Risk Priority Number (RPN)
values shall be consistently applied using Severity, Occurrence,
and Detection ranking tables. Severity shall be based on all risks
such as organization risk, customer risk, and end user risk.
• 8.3.3.3 Características especiales– (ISO/TS 7.3.2.3)

• La organización deberá utilizar un enfoque multidisciplinar para
establecer, documentar e implementar su(s) proceso(s) para
identificar características especiales, incluyendo las
determinadas por el cliente y el análisis de riesgo realizado por
la organización, e incluirá lo siguiente:
a) ....... características especiales se identifican con marcas específicas y
se encuentran en cascada a través de cada uno de estos documentos
b) Desarrollo de estrategias de control y seguimiento para características
especiales de productos y procesos de producción
c) Aprobación especifica del cliente, cuando sea necesario
d) ............ o los símbolos o anotaciones equivalentes de la organización,
tal como se definen en una tabla de conversión de símbolos. La tabla
de conversión de símbolos se presentará al cliente, si es necesario
• 8.3.4.2 Validación de diseño y desarrollo– (ISO/TS 7.3.6.1),

continuación
• Cuando se acuerde contractualmente con el cliente, esto incluirá
la evaluación de la interacción del producto de la organización,
incluido el software incorporado, dentro del sistema del producto
del cliente final
• 8.3.4.4 Proceso de aprobación de productos – (ISO/TS
7.3.6.3)
▪ La organización deberá aprobar los productos y servicios
proporcionados externamente de acuerdo con ISO 9001, apartado
8.4.3, antes de la presentación de su aprobación de parte al cliente
▪ La organización deberá obtener la aprobación documentada del
producto antes del embarque, si así lo requiere el cliente. Los registros
de dicha aprobación se conservarán
8 OPERAcióN (CONTINUACIÓN)
• 8.3.5.2 Salidas del diseño del proceso de producción–

(ISO/TS 7.3.3.2)
▪ Características especiales para el producto y proceso de fabricación
▪ Identificación de variables de entrada de proceso que afectan las
características
▪ Herramientas y equipo para producción y control, incluyendo
estudios de capacidad de equipos y proceso(s)
▪ Diagramas de flujo de proceso de fabricación / disposición en planta,
incluyendo la vinculación de producto, proceso y herramientas
▪ Resultados de la identificación y verificación “a prueba de errores”,
según corresponda
8.3.3.3 Special characteristics
The organization shall have a process to identify critical operations
within their manufacturing process.
8.3.4.4 Product approval process
The organization shall comply with the AIAG Production Part
Approval Process (PPAP) manual and GM 1927-03 Quality SOR
to meet this requirement.
8.3.5.2 Manufacturing process design output
The organization shall have a method to identify, control, and
monitor the high risk items on those critical operations.
There shall be rapid feedback and feed forward between
inspection stations and manufacturing, between departments, and
between shifts.
8 OPERACIÓN (CONTINUación)
8.3.6.1 Cambios del diseño y desarrollo– suplemento –

(ISO/TS 7.1.4 y 7.3.7)
▪ La organización debe:
• Evaluar los cambios de diseño después de la aprobación

inicial del producto, que deben ser aprobados internamente
y validados antes de la implementación de la producción.
• Para los productos con software incorporado, documentar
el nivel de revisión del software y del hardware como parte
del registro de cambios
8 OPERAción (CONTINUación)
• 8.4.2.3 Desarrollo de Sistema de gestión de calidad de
proveedor– (ISO/TS 7.4.1.2)
• La organización exigirá a sus proveedores de productos y servicios

de automoción que desarrollen, implementen y mejoren un
sistema de gestión de calidad certificado según la norma ISO
9001, a menos que el cliente lo autorice de otra manera (por
ejemplo, el punto a)) con el objetivo final de certificarse en esta
norma de SGC de automoción. A menos que el cliente
especifique lo contrario, se aplicará la siguiente secuencia para
lograr este requisito
8.3.6.1 Design and development changes – supplemental
All design changes, including those proposed by the organization, shall
have written approval by the authorized customer representative, or a
waiver of such approval, prior to production implementation. See also
AIAG Production Part Approval Process (PPAP) manual.
8.4.2.3 Supplier quality management system development
This clause applies to suppliers of the organization who are providers
of: a) production materials, b) production, service, and accessory parts,
or c) heat treating, plating, painting or other finishing services.
This clause does not apply to indirect or providers of services that add
no manufacturing value which include, but is not limited to
distributers, logistics, sequencers, parts packagers, tooling and
equipment.
• 8.4.2.4.1 Auditorías de segunda parte
• La organización debe incluir un proceso de auditoría de segunda
parte en su enfoque de gestión de proveedores. Las auditorías de
segunda parte se pueden utilizar para lo siguiente:
a) Evaluación del riesgo del proveedor
b) Supervisión de proveedores
c) Desarrollo del SGC de proveedores
d) Auditorías de productos
e) Auditorías de procesos
8 OPERAciÓN (CONTINUACIÓN)
• 8.4.2.4.1 Auditorías de segunda parte, continuación
▪ Basándose en un análisis de riesgos, incluyendo los requisitos de
seguridad / reglamentarios del producto, el desempeño del
proveedor y el nivel de certificación del SGC, como mínimo, la
organización deberá documentar los criterios para determinar la
necesidad, el tipo, la frecuencia y el alcance de las auditorías de
segunda parte
▪ La organización conservará los registros de los informes de auditoría
de segunda parte
▪ Si el alcance de la auditoría de segunda parte es evaluar el sistema de
gestión de calidad del proveedor, entonces el enfoque deberá ser
consistente con el enfoque del proceso de automoción
▪ NOTA: La orientación puede encontrarse en la Guía del auditor de la
IATF y en la ISO 19011
8.4.2.4.1 Second-party audits

Second-party auditors performing QMS audits must meet the
requirements in clause 7.2.4 SecondParty Auditor Compliance in
IATF16949:2016 plus meet these additional requirements: 1. The
organization (2nd party) must be IATF16949:2016 certified and
not on probation or suspension. 2. The organization (2nd party)
must utilize a qualified ISO Lead Auditor, or a qualified internal
auditor with evidence of their successful completion of training,
and a minimum of five internal ISO/TS16949:2009 and/or
IATF16949:2016 audits under the supervision of a qualified lead
auditor.
The organization (2nd party) must audit annually each qualifying
supplier and maintain records of the audit. Qualifying supplier is
defined by those suppliers determined to need second-party auditing
per clause 8.4.2.4.1 Second-Party Audits.
The duration of these audits must conform to the full application of
the Audit Day Requirements table of the current edition of
Automotive Certification Scheme for IATF16949 Rules for Achieving
and Maintaining IATF Recognition.
The second-party audits shall identify an acceptable passing level and
include a scoring or ranking to determine which suppliers have
passed. The organization shall have documented evidence that they
review and follow up on all non-conformances identified in the
second-party audit with the intent to close these non-conformances
8 OPERAción (CONTINUación)
• 8.4.2.5 Desarrollo de proveedor
▪ La organización determinará la prioridad, tipo, extensión y
oportunidad de las acciones de desarrollo de proveedores
requeridas para sus proveedores activos. La determinación de las
entradas incluirán pero no se limitarán a lo siguiente:
a) Los problemas de rendimiento identificados mediante la supervisión del
proveedor (ver apartado 8.4.2.4)
b) Resultados de la auditoría de la segunda parte (ver apartado 8.4.2.4.1)
c) Estado de certificación del sistema de gestión de calidad de terceros
d) análisis de riesgos
▪ La organización deberá implementar las acciones necesarias para

resolver los problemas de desempeño abiertos (insatisfactorios) y
buscar oportunidades de mejora continua
8.4.2.5 Supplier development

When a supplier to an organization is so small as to not have adequate
resources to develop a system according to IATF16949:2016 or ISO
9001:2015, certain specified elements may be waived by the
organization. The organization shall have decision criteria for
determining “specially designated small suppliers”. Such decision
criteria shall be in writing and applied consistently in the application of
this provision. The existence and use of such decision criteria shall be
verified by 3rd party auditors.
NOTE 1: ISO9001:2015 and IATF16949:2016 contain

fundamental quality management system requirements of value
to any size of provider of production materials, production,
service, and accessory parts, or heat treating, plating, painting
or other finishing services. There are a number of methods to
implement a compliant system, so it is recognized that a simpler
Quality Management System approach could be used for the
smaller suppliers of organizations to which IATF16949:2016
clause 8.4.2.3 applies.
NOTE 2: “Small” may also refer to volume supplied to
automotive.
8 OPERAción (CONTINUACIÓN)
• 8.5.1.1 Plan de control – (ISO/TS 7.5.1.1)

▪ La organización, si así lo requiere el cliente, proporcionará datos de medición y
conformidad recogidos durante la ejecución de los planes de pre-lanzamiento o
de control de producción
b) Métodos de validación de la primera pieza y de la última pieza para el seguimiento
del control realizado sobre las características especiales
▪ La organización debe revisar los planes de control y actualizarlos si es

requerido, por cualquiera de las siguientes:
f) La organización determina que ha enviado un producto no conforme al cliente
g) Cuando ocurran cambios que afecten al producto, al proceso de fabricación, a la
medición, a la logística, a las fuentes de suministro, a los cambios en el volumen de
producción o al análisis de riesgos (AMFE) (Ver el anexo A)
h) Después de una queja del cliente y la implementación de la acción correctiva
asociada, cuando sea aplicable
i) A una frecuencia establecida basada en un análisis de riesgos
8.5.1.1 Control plan

General Motors does not provide waivers to organizations for
control plan approval because General Motors signatures on the
Control Plan are not required.
The organization shall provide measurement, test, and inspection
data which demonstrates that control plan requirements, sample
sizes, and frequencies are being met when requested.
Sample sizes and frequencies shall be determined based on risk and
occurrence of failure modes, and to ensure that the customer is
adequately protected from receiving the product represented by the
inspection/tests before the results of the inspection/tests are known.
8 operación
• 8.5.1.2 – Instrucciones de trabajo del operador
normalizadas y los estándares visuales – (ISO/TS 7.5.1.2)
a) Comunicados y comprendidos por el personal responsable de
seguirlos
c) Presentado en el/los idioma(s) entendido(s) por el personal
responsable de seguirlos
• Los documentos de trabajo normalizados incluirán también normas para

la seguridad del operario
8.5.1.2 Standardized work – operator instructions and visual standards

Standardized work should include the what, how, and why tasks are
performed. All standardized work shall be followed.
Visual standards throughout the facility shall be common, including
between facilities building the same platform/product for global quality.
Visual standards shall be clearly communicated to all team members
that are affected and referenced in the standardized work.
Visual standards that differentiate “good” from “bad” shall satisfy
customer requirements and be controlled.
• 8.5.1.6 Gestión de las herramientas de producción y

equipos y herramientas de fabricación, prueba e
inspección – (ISO/TS 7.5.1.5 y 7.5.4.1)
• La organización deberá establecer e implementar un sistema
para la gestión de herramientas de producción, sea propiedad
de la organización o del cliente, incluyendo:
g) Identificación de la herramienta, como número de serie o número
de activo; su situación, como en producción, en reparación o
disponible; la propiedad; y ubicación.
• La organización verificará que las herramientas propiedad del
cliente, el equipo de fabricación y el equipo de prueba /
inspección están permanentemente marcados en una ubicación
visible de modo que se pueda determinar la propiedad y la
aplicación de cada elemento
8.5.1.6 Management of production tooling and manufacturing,

test, inspection tooling and equipment
Where warehouses or distribution centers (distributors) are
remote sites, the requirements for management of production
tooling may not be applicable.

Amef Onudi 2019

Cargado por

Copyright:

Formatos disponibles

Amef Onudi 2019

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Amef Onudi 2019

Cargado por

Copyright:

Formatos disponibles

VDA – AMEF

El Manual de AIAG y VDA FMEA es un manual de referencia para

• Prevención de Fallas (Controles Preventivos)

• Corrección de Fallas (Detección)

El AMEF se utiliza para abordar los aspectos técnicos de la reducción de riesgos. El

❖Evaluar los riesgos técnicos potenciales de falla de un producto o proceso

Las limitaciones de la FMEA incluyen lo siguiente:

• Es cualitativo (subjetivo), no cuantitativo (medible)

Las consideraciones para el análisis del AMEF y la implementación de sus

Define el producto y las especificaciones a

Diseña el proceso de forma de asegurar la

Utiliza los procesos realizando las tareas

Ocurrencia Detección Severidad

• Identifique y entienda las funciones, requerimientos y especificaciones relevantes para definir

• La determinación de los efectos potenciales incluye el análisis de las consecuencias

En la valoración de los distintos modos

• Ocurrencia es cuán a menudo puede ocurrir la causa de falla.

❑ Completo: las posibles fallas previsibles no se ocultan. La preocupación por

Los riesgos técnicos de falla identificados en el FMEA se evalúan como aceptables

Al utilizar el enfoque FMEA de la familia o Tipo para el nuevo producto o

• Cambios en los diseños o procesos.

Al inicio del proyecto se deben definir los siguientes temas:

Intención del AMEF – ¿Para que estamos haciendo FMEA? (Intent)

Tiempo del FMEA - ¿cuando se debe hacer? (timing)

Miembros Extendido y/o Expertos del AMEF

El Desarrollo del AMEF se lleva a cabo en siete pasos.

AMEF ANALISIS DE MODO Y EFECTO DE FALLA (AMEF DE PROCESO )

NOMBRE DE LA COMPAÑÍA: ASUNTO/ PROYECTO DFMEA Numero:

UBICACIÓN INGENIERIA: PFMEAFECHA DE INICIO: RESPONSABLE DEL DISEÑO

NOMBRE DEL CLIENTE : PFMEA FECHA DE REVISION: NIVEL DE CONFIDENCIALIDAD:

AÑO MODELO/ PLATAFORMA: EQUIPO MULTIFUNCIONAL

Base para el análisis estructural

• USUARIO FINAL: La persona que utiliza un producto después de que ha sido

• MONTAJE y FABRICACIóN: los lugares donde se llevan a cabo las operaciones de

El conocimiento de estos clientes puede ayudar a definir las funciones, requisitos y

• Define el alcance del análisis (ayuda a identificar posibles

Brush Card Base Body

Window Lifter Commutation System Carbon Brush

System Elements in Scope …

Colaboración entre el Cliente y el Proveedor

Base para el análisis de funciones

Un requisito funcional es un criterio por el cual se juzga o mide el rendimiento

Normas y normas de la industria:

Ejemplo de comportamiento del sistema

salidas del sistema no deseadas Los ruidos se describen en unidades físicas.

1. Next Higher Level 2. Focus Element

La numeración de encabezado de columna (1, 2, 3) y la codificación de color se incluyen para

Colaboración entre equipos de ingeniería (sistemas, seguridad y componentes)

Base para el análisis de fallos

Function derive failures Malfunctions

F = Function t = Time = required Function = performed Function

CADENA DEL MODO DE FALLA

Algunos ejemplos de modos de fallas de nivel de componente incluyen, entre otros:

Por lo tanto, una causa de falla en el OEM se convierte en un modo de falla en un

1. Failure Effects (FE) to the 3. Failure Cause (FC)

ANÁLISIS DE FALLOS (PASO 4)

Base para el análisis de riesgos

Los principales objetivos del Análisis de Riesgos de Diseño son:

CONTROLES DE PREVENCION ACTUALES