Puntos clave
Respuesta breve: Los códigos de fallo genéricos desperdician tiempo de diagnóstico. Los códigos bien diseñados nombran el dispositivo específico, la condición específica y sugieren un paso de recuperación. La disciplina cuesta más al principio y ahorra horas por fallo para siempre. Véase también Diseño de códigos de motivo de inactividad.
"Sensor Fault" no le dice al operario nada accionable. ¿Qué sensor? ¿Qué tipo de fallo? ¿Qué comprobar primero?
Resultado: el operario investiga desde cero. El tiempo medio de diagnóstico aumenta. El OEE se resiente.
Ejemplo malo: FLT_SENSOR. Ejemplo bueno: FLT_PE_INFEED_LOW_LOW con descripción "Fotocélula de entrada con lectura baja durante 2 s, compruebe la lente por suciedad."
Prefijo, dispositivo y condición consistentes. Los operarios aprenden el patrón.
Documente cada código de fallo: id, descripción, acción sugerida, escalado. Los operarios lo consultan; el CMMS enlaza órdenes de trabajo a los códigos.
El código de fallo se envía al campo de motivo del CMMS. Los informes muestran los códigos de fallo principales por línea. Las investigaciones se dirigen a los peores.
1. Códigos escritos por el programador sin revisión del operario. Los códigos tienen sentido para el programador; no para el operario a las 3 a. m.
2. Sin documentación. La biblioteca de códigos vive en la cabeza del programador.
3. Categorías genéricas que lo engloban todo. "Otro fallo" oculta la causa real.
4. Códigos que cambian entre revisiones del PLC. Los datos históricos quedan inutilizables.
La disponibilidad del OEE está dominada por el tiempo de inactividad. Los códigos de fallo nutren la categorización de motivos de inactividad. Los códigos específicos generan un Pareto específico; los códigos genéricos producen una porción del 30% sin sentido llamada "Sensor Fault".
El módulo OEE de Fabrico ingiere códigos de fallo del PLC vía OPC UA / Modbus, los mapea a códigos de motivo y genera informes de Pareto que impulsan mejoras de diseño.
Vea cómo Fabrico captura esto automáticamente, explorar OEE para la fabricación o reserva una demo.
Ingeniería de control con aportes de operarios y mantenimiento.
Sí. Refactorizar en la próxima revisión del programa.
Variable. Es normal tener de decenas a cientos.
A menudo minutos por fallo. De forma acumulada, horas por semana.
Respuesta breve: Los códigos de fallo genéricos desperdician tiempo de diagnóstico. Los códigos bien diseñados nombran el dispositivo específico, la condición específica y sugieren un paso de recuperación. La disciplina cuesta más al inicio y ahorra horas por fallo para siempre.
"Sensor Fault" no le dice al operario nada accionable. ¿Qué sensor? ¿Qué tipo de fallo? ¿Qué comprobar primero?
Resultado: el operario investiga desde cero. El tiempo medio de diagnóstico aumenta. El OEE se resiente.
Ejemplo malo: FLT_SENSOR. Ejemplo bueno: FLT_PE_INFEED_LOW_LOW con descripción "Lectura baja del fotocélula de entrada durante 2 s, revise la lente por suciedad."
Prefijo consistente, dispositivo, condición. Los operarios aprenden el patrón.
Documente cada código de fallo: id, descripción, acción sugerida, escalado. Los operarios lo consultan; el CMMS vincula órdenes de trabajo a códigos.
El código de fallo alimenta la razón en el CMMS. Los informes muestran los códigos de fallo principales por línea. Las investigaciones se dirigen a los más problemáticos.
1. Códigos escritos por el programador sin revisión del operario. Los códigos tienen sentido para el programador; no para el operario a las 3 a. m.
2. Sin documentación. La biblioteca de códigos vive en la cabeza del programador.
3. Cajones de sastre genéricos. "Other Fault" oculta la causa real.
4. Códigos que cambian entre revisiones del PLC. Los datos históricos se vuelven inutilizables.
La Disponibilidad del OEE está dominada por el tiempo de inactividad. Los códigos de fallo alimentan la categorización de las razones de tiempo de inactividad. Los códigos específicos producen un Pareto específico; los códigos genéricos generan una porción del 30% "Sensor Fault" sin significado.
El módulo OEE de Fabrico ingiere códigos de fallo del PLC vía OPC UA / Modbus, los mapea a códigos de causa y genera informes de Pareto que impulsan mejoras de diseño.
Ingeniería de control con aporte de operarios y mantenimiento.
Sí. Refactorice en la próxima revisión del programa.
Variable. Decenas a cientos es lo habitual.
A menudo minutos por fallo. Acumuladamente, horas por semana.
Iniciar sesión
Blog
