El Manual FMEA AIAG/VDA (2019) es una publicación conjunta del Automotive Industry Action Group (AIAG) de Estados Unidos y la asociación alemana del automóvil (VDA). Define un proceso de siete pasos para el AMFE de diseño (DFMEA), el AMFE de proceso (PFMEA) y el AMFE complementario para monitorización y respuesta del sistema (FMEA-MSR). Su principal innovación respecto a enfoques anteriores es la sustitución del Número de Prioridad de Riesgo (RPN) por la Prioridad de Acción (AP) — una clasificación H/M/L basada en tablas que trata la severidad, la probabilidad y la detección como factores de peso desigual, en lugar de multiplicarlos en un único número. La misma tabla AP fue adoptada posteriormente por SAE J1739.
El paso 1 del manual introduce el AMFE base: un AMFE existente para una familia de productos o procesos, utilizado como punto de partida para un nuevo análisis. Un AMFE base bien mantenido recoge todos los fallos conocidos de proyectos anteriores y resultados de validación. El AMFE del nuevo proyecto se construye extendiéndolo, no desde cero.
Esto es precisamente lo que hace un tipo en KF. Un ítem de tipo acumula los modos de fallo, causas, efectos y acciones correctivas de una clase de productos o procesos. Cuando se inicia el AMFE de un nuevo proyecto, el ítem del proyecto se crea como instancia del tipo correspondiente; todos los modos de fallo históricos se heredan automáticamente. Cuando el proyecto descubre nuevos fallos, estos pueden promoverse de vuelta al tipo mediante el checklist invertido, actualizando el AMFE base para todos los proyectos futuros.
| Paso | Manual | KF |
|---|---|---|
| 1. Planificación y preparación | Definir alcance, objetivos, equipo y calendario; identificar el AMFE base | Crear el ítem del proyecto; heredar estructura e historial de fallos de un tipo (el AMFE base) |
| 2. Análisis de estructura | Descomponer el sistema: sistema → subsistema → componente → característica | Construir una jerarquía de componentes mediante relaciones entre ítems |
| 3. Análisis de funciones | Definir la función y los requisitos de cada elemento estructural | Documentar funciones en las descripciones de ítems; requisitos como subítems o texto |
| 4. Análisis de fallos | Identificar modos de fallo, efectos (hacia arriba) y causas (hacia abajo) para cada función | Registrar eventos en ítems; efectos, modo de fallo y causa se apilan verticalmente en un único evento |
| 5. Evaluación de riesgos | Asignar S a efectos, O a causas, D a controles; calcular AP | Campos S-O-D nativos en cada evento; AP calculada automáticamente |
| 6. Optimización | Definir acciones recomendadas; asignar responsable y fecha límite; reevaluar S-O-D tras la realización | Las acciones son ítems de primera clase con responsable, fecha límite y S-O-D antes/después |
| 7. Documentación | Archivar el AMFE; registrar lecciones aprendidas; vincular a DVP&R y plan de control | Todos los ítems están versionados y son buscables; las lecciones promovidas al tipo actualizan el AMFE base |
Los pasos 2 y 3 son la adición más explícita del manual AIAG/VDA respecto a la práctica AMFE anterior. La descomposición estructural (paso 2) es necesaria para mapear las interfaces entre niveles del sistema, y el análisis de funciones (paso 3) proporciona el puente entre estructura y fallo: un modo de fallo es siempre el fallo de una función.
En KF, el árbol estructural es la jerarquía de componentes de los ítems — la misma jerarquía que impulsa el informe AMFE, el árbol de fallos y el checklist. Las funciones se documentan en la descripción del ítem o como subítems. Los requisitos se modelan como ítems de tipo Action etiquetados con requirement sobre el mismo ítem, siguiendo el modelo descrito en la página de ISO 26262: un requisito es algo que un agente debe hacer o garantizar, por lo que una acción es la representación correcta. El cumplimiento es entonces la finalización de la tarea — el requisito queda satisfecho cuando su acción se marca como realizada.
La brecha que subsiste respecto a la estructura de columnas del manual es que no existe un vínculo explícito en el modelo de datos entre un evento de modo de fallo y el requisito específico que incumple. En una hoja DFMEA conforme al manual, una fila traza función → requisito → modo de fallo de forma explícita. En KF, los tres están presentes en el mismo ítem — funciones en la descripción, requisitos como acciones etiquetadas, modos de fallo como eventos — pero una auditoría columna a columna no encontraría una referencia cruzada consultable entre ellos.
El manual define una cadena de fallo vertical: un efecto de fallo (impacto en el nivel superior o en el usuario final) vinculado a un modo de fallo (cómo el elemento no cumple su función) vinculado a una causa de fallo (por qué ocurre el modo de fallo). La severidad se valora sobre el efecto; la probabilidad sobre la causa; la detección sobre los controles de esa causa.
KF agrupa los tres en un único evento: el título del evento es el modo de fallo, y la descripción contiene la causa y el efecto. Esto mantiene el AMFE compacto y legible. Los campos S-O-D están en el evento y se corresponden con los campos del manual. La divergencia menor es que efecto, modo y causa no están en columnas separadas — están en una única vista estructurada.
La tabla AP del manual — adoptada también en el Apéndice I de SAE J1739 — es la misma tabla que KF utiliza para el cálculo automático de AP. El RPN sigue disponible como campo opcional; el manual desaconseja el uso de umbrales de RPN como único criterio de decisión, lo que es coherente con el enfoque de KF de mostrar tanto RPN como AP.
El sistema antes/después de S-O-D está soportado de forma nativa: cada acción sobre un evento lleva valores actualizados de severidad, probabilidad y detección que reflejan el riesgo una vez completada la acción. El informe AMFE muestra tanto el riesgo original como el residual.
El manual cubre FMEA-MSR para cualquier sistema con capacidad de monitorización y respuesta integrada, usando los mismos tres campos adicionales que SAE J1739: Frecuencia (F), Monitorización (M) y SEV tras la respuesta del sistema. KF soporta FMEA-MSR mediante el modelo antes/después de riesgo: el mecanismo de diagnóstico en campo se modela como una acción de detección sobre el evento, su campo D lleva el valor de M y su nueva S lleva la severidad mitigada. Se aplica la misma tabla AP — la priorización de riesgos del MSR usa la misma lógica de tres factores con la misma salida H/M/L. Véase la página SAE J1739 para el mapeo detallado.
| Aspecto | Soporte en KF | Estado |
|---|---|---|
| Campos S, O, D | Nativos en cada evento | ✅ |
| Prioridad de Acción (AP) | Nativa, automática; misma tabla que el manual | ✅ |
| S-O-D antes/después | Valores originales conservados; las acciones llevan los valores actualizados | ✅ |
| AMFE base / reutilización de lecciones aprendidas | Jerarquía de tipos con modos de fallo heredados; checklist invertido para promoción | ✅ |
| Jerarquía del sistema (análisis de estructura) | Árbol de componentes de ítems | ✅ |
| Cadena de fallo (efecto → modo → causa) | Evento único con descripción apilada | ✅ alineado |
| Trazabilidad función → requisito → modo de fallo | Funciones en la descripción del ítem; requisitos como acciones etiquetadas; sin referencia cruzada explícita entre el evento y el requisito específico que incumple | ⚠ |
| FMEA-MSR | Modelado mediante S antes/después en una acción de detección; se aplica la misma tabla AP | ✅ |
| Responsable por acción | Campo de responsable en la acción | ✅ |
| RPN | Opcional, calculado | ✅ |
| Plan de control del proceso | No soportado | ❌ |