Cómo convertir los diagnósticos de PLC y SCADA en un mantenimiento fiable sin alterar el control.
La señal ya existe dentro de la capa de control
Un PLC a menudo sigue funcionando mientras su estado se deteriora. Primero, consulta el historial de diagnósticos, no la pantalla mímica. Las interrupciones de comunicación aumentan lentamente. Un módulo de E/S remotas señala fallos intermitentes. En la capa SCADA, las desconexiones se repiten antes de que se detenga la producción. Son advertencias tempranas, no ruido. Los controladores modernos ya exponen los datos. No siempre necesitas una red de sensores nueva. La parte difícil es asignar a cada señal un destino útil. Ese destino es un registro de mantenimiento vinculado a un activo real.
Paso 1 — Recopila los estados reales de salud del controlador
La lógica predictiva debe utilizar señales compatibles realmente con el dispositivo. No des por hecho que todos los PLC exponen los mismos datos de estado. En un Allen-Bradley ControlLogix (como un procesador Allen-Bradley ControlLogix) o un sistema CompactLogix, supervisa los contadores de errores del puerto EtherNet/IP en tarjetas de comunicación como el módulo de comunicaciones 1756 ControlLogix. Registra los recuentos de fallos recuperables por estación remota. En un controlador Woodward accesible mediante Modbus TCP (supervisando sistemas con módulos de E/S Woodward), consulta los registros de mantenimiento requerido y límite de vida útil. Algunos dispositivos informan directamente de fallos internos o de una alimentación anómala.
-
Paso 1 — Enumera cada diagnóstico que el dispositivo objetivo proporciona realmente.
-
Paso 2 — Registra la tendencia de los contadores semanalmente, ya que la frecuencia revela el deterioro mejor que un solo evento.
-
Paso 3 — Genera alarmas solo ante una pendiente ascendente o una duración, no por un único destello.
-
Paso 4 — Vincula cada contador a un activo etiquetado, nunca a un bastidor genérico.
Paso 2 — Deja de convertir cada alarma en una orden de trabajo
SCADA capta la atención del operador. Mantenimiento decide quién interviene. Confundir ambas funciones entierra el deterioro real bajo órdenes innecesarias. Una alarma de alta temperatura puede ser simplemente un comportamiento normal de la producción. Una breve desconexión puede recuperarse por sí sola. Por tanto, califica la condición antes de crear trabajo. La repetición es más importante que un evento aislado. La duración a menudo importa más que la gravedad máxima. Una deriva lenta por debajo del límite de alarma aún puede justificar una visita. Además, mantén separadas la confirmación y la finalización. Un operador confirma que se observó un fallo. Eso no demuestra que el equipo haya sido reparado.
-
Paso 1 — Añade una regla que requiera tres repeticiones en siete días para activar el trabajo.
-
Paso 2 — Adjunta el contexto: el activo, la tendencia y las reparaciones anteriores.
-
Paso 3 — Cierra la orden solo después de realizar y registrar el trabajo.
El historial de reparaciones mejora el modelo
Los datos del historiador muestran lo que ocurrió antes de un fallo. El historial de mantenimiento muestra lo que ocurrió después de que alguien lo revisara. Supón que un error de comunicaciones sigue generando órdenes de trabajo. Los técnicos no encuentran ningún defecto de hardware en cada revisión. Es probable que el disparador sea demasiado sensible. Sin embargo, si el mismo evento siempre termina con el reemplazo de un conector, confía en ese patrón. Merece atención más temprana. El trabajo finalizado separa el síntoma de la causa. Un fallo fantasma de E/S puede deberse a un dispositivo de campo que perdió alimentación. Reemplazar el módulo repararía el activo equivocado. La nota de cierre conserva la causa real para el siguiente turno.
Integra sin invitar al riesgo
Un CMMS no debe convertirse en un cliente privilegiado del sistema de control. Enruta los diagnósticos a través de una capa de datos. Obtén la tendencia de SCADA o de un historiador. Utiliza OPC UA de solo lectura para la información estandarizada de estado y diagnóstico. Después, un servicio de integración pasa los eventos calificados a la plataforma de mantenimiento mediante una API. Esto mantiene el tráfico de mantenimiento alejado de la lógica crítica en tiempo real. Las operaciones matemáticas predictivas no necesitan ejecutarse dentro del controlador. Además, protege la red. Una aplicación de mantenimiento rara vez necesita escribir en la memoria del PLC. Limítala al acceso de solo lectura. Sigue el proceso de control de cambios de la planta antes de que cualquier enlace automatizado llegue a producción. Por último, sincroniza los relojes. Un evento de SCADA con una marca de tiempo separada varios minutos del registro del CMMS arruina la reconstrucción del fallo.
Conclusión y recomendaciones de acción
El mantenimiento predictivo recompensa la paciencia y un flujo de datos limpio, no los paneles sofisticados. Primero, recopila solo los estados de salud que tus dispositivos proporcionan realmente. Segundo, califica una condición mediante repetición y duración antes de generar una orden. Además, deja que un historial de reparaciones verificado entrene tus activadores con el tiempo. Sin embargo, nunca permitas que el CMMS escriba en la lógica de control ni omitas el control de cambios. Por tanto, crea una ruta de solo lectura a través del historiador y OPC UA, con la hora sincronizada. Por último, trata la propia infraestructura de control como un equipo que requiere mantenimiento. Empieza esta semana con un enlace EtherNet/IP crítico. Valida el circuito de extremo a extremo antes de ampliarlo a toda la planta.
Autor: Sun Yifei es ingeniero de automatización industrial con más de 10 años de experiencia en PLC, DCS y sistemas de control.
