Cómo crear lógica de PLC para mantenimiento predictivo y reducir la lucha contra incendios reactiva

La lógica de PLC para mantenimiento predictivo desplaza los diagnósticos de la detección binaria de fallos al análisis de tendencias analógicas. Al monitorear la deriva, la varianza, el retardo de respuesta y el comportamiento del error PID dentro de la capa de control, los ingenieros pueden generar advertencias de mantenimiento tempranas antes de que ocurran disparos críticos, reduciendo el tiempo de inactividad no planificado y las llamadas fuera de horario que suelen seguir.

El mantenimiento reactivo se describe a menudo como un problema de estrategia de activos. En la práctica, también es un problema de carga de trabajo de control. Cuando los diagnósticos solo reaccionan después de un límite estricto, una prueba fallida o una condición de parada, el sistema de control se convierte en un anunciador de daños en lugar de un instrumento para la intervención temprana.

Durante la evaluación comparativa interna de escenarios de control de bombas en OLLA Lab, una media móvil de 10 segundos aplicada a una variable de control PID simulada identificó la adherencia (stiction) del actuador 42 minutos de simulación antes de que se activara un fallo de estado final discreto. Metodología: n=12 ejecuciones de degradación de válvula-bomba simuladas; tarea definida como la detección de fricción creciente del actuador antes del estado de fallo discreto; el comparador de referencia fue un peldaño estándar de fallo crítico utilizando solo prueba discreta; observado durante una sesión de simulación acotada por ejecución. Esto respalda un punto limitado: la lógica de tendencia analógica puede crear ventanas de advertencia más tempranas que la lógica de fallo discreto en una simulación controlada. No respalda una afirmación universal de tiempo de campo en todos los activos, lazos o programas de mantenimiento.

La literatura más amplia sobre mano de obra y operaciones apunta en la misma dirección, con el alcance adecuado. Los informes sobre vacantes en la fabricación y brechas de habilidades de Deloitte y la BLS indican una tensión persistente en los mercados laborales técnicos, mientras que las discusiones de la industria alineadas con la ISA vinculan constantemente el tiempo de inactividad no planificado y la intervención fuera de horario con la presión de retención para el personal técnico experimentado. Eso no prueba un modelo de agotamiento de causa única. Sí sugiere que el manejo reactivo de fallos no es un valor predeterminado inofensivo. Es costoso, disruptivo y generalmente llega en un momento inconveniente.

La diferencia técnica es la detección de estado binario frente a la detección de degradación analógica.

La lógica de PLC reactiva espera a que una condición sea inequívocamente mala. La lógica predictiva evalúa si el comportamiento del proceso tiende hacia el fallo antes de que llegue el fallo crítico. En términos de tipos de datos, el cambio suele ser de enclavamientos impulsados principalmente por BOOL a una combinación de BOOL, REAL, TIME y valores estadísticos derivados.

Una distinción concisa ayuda:

- La lógica reactiva pregunta: ¿Ha ocurrido la condición de fallo? - La lógica predictiva pregunta: ¿La firma del proceso se mueve hacia el fallo?

Esa distinción importa porque la mayoría de la degradación mecánica no nace como un evento discreto. Aparece primero como deriva, ruido, retraso, saturación, esfuerzo de corrección excesivo o recuperación inestable. El equipo suele susurrar antes de dispararse.

Los límites de la seguridad discreta

La lógica de fallo discreto sigue siendo necesaria. No es la villana aquí. Los disparos críticos, permisivos, retroalimentaciones de prueba, paradas de emergencia e interbloqueos de apagado son esenciales para la protección y la respuesta determinista.

La limitación es más estrecha: la lógica discreta suele llegar tarde para el diagnóstico de mantenimiento.

Los ejemplos son familiares:

• Un interruptor de límite cerrado de válvula nunca se prueba dentro del tiempo de espera.
• Una sobrecarga de bomba se dispara después de que la corriente supera el umbral.
• Un flotador de nivel muy alto se dispara solo después de que el tanque ya está en excursión.
• Un interruptor de velocidad cero de transportador falla solo después de que ya se ha perdido el movimiento.

Estos son eventos de protección válidos. Son instrumentos de alerta temprana deficientes. Para cuando un fallo discreto confirma el fallo, el proceso ya ha absorbido estrés, la producción ya se ha interrumpido, o ambas cosas.

El cambio analógico predictivo

La lógica predictiva utiliza señales continuas y tendencias derivadas para detectar comportamientos anormales antes.

Las entradas predictivas comunes incluyen:

• Retroalimentación de posición de 4–20 mA
• Corriente del motor
• Señales de presión, flujo, nivel o temperatura
• Tiempo de recorrido de la válvula
• Magnitud del error PID a lo largo del tiempo
• Duración de la saturación de la variable de control
• Retardo de comando a retroalimentación

En la práctica, la lógica de PLC para mantenimiento predictivo a menudo combina:

• medias móviles para suavizar el ruido,
• cálculos de tasa de cambio para detectar la velocidad de deriva,
• bandas de desviación para comparar el comportamiento actual con la línea base,
• temporizadores para asegurar la persistencia antes de alarmar,
• comparadores para separar la advertencia del disparo,
• diagnósticos PID para inferir resistencia mecánica o inestabilidad del proceso.

Esto no es misticismo de IA. Es una interpretación disciplinada de señales dentro de la capa de control.

Las firmas de degradación analógica importan porque el desgaste físico suele aparecer en el software como un cambio en el comportamiento de la señal antes de que aparezca como un fallo crítico.

Ese es el significado operativo de los diagnósticos basados en software en este artículo: utilizar funciones matemáticas de PLC y seguimiento de errores PID para activar advertencias de mantenimiento basadas en firmas de degradación mecánica.

Tres firmas de degradación comunes

1. Desplazamiento de la línea base (deriva) Un sensor que debería leer 4.0 mA en cero físico comienza a leer 4.2 mA o 4.3 mA bajo la misma condición. Esto puede indicar deriva de calibración, ensuciamiento, acumulación o error de referencia.
2. Aumento de la varianza (ruido) Un valor analógico previamente estable comienza a mostrar micro-picos erráticos o bandas de oscilación ensanchadas. Esto puede indicar cavitación, desgaste de rodamientos, cableado suelto, interferencia eléctrica o hidráulica de proceso inestable.
3. Respuesta retardada (lentitud) El tiempo transcurrido entre la emisión del comando y la respuesta medida aumenta en ciclos repetidos. Esto a menudo apunta a fricción del actuador, válvulas pegajosas, arrastre mecánico o debilidad neumática.

El punto importante no es simplemente que la señal cambió. Es que el patrón cambió de una manera que se correlaciona con una degradación física plausible.

Por qué la deriva importa más de lo que muchos equipos admiten

La deriva a menudo se descarta hasta que cruza un umbral de calibración. Esa es una visión administrativa ordenada, no siempre una útil operativamente.

Un pequeño desplazamiento de la línea base puede producir:

• falsa confianza en la posición real del proceso,
• esfuerzo de corrección PID innecesario,
• respuesta de alarma retardada,
• disparos molestos causados por comparadores aguas abajo más estrictos,
• pérdida oculta de margen de control.

Un lazo puede permanecer "en funcionamiento" mientras se vuelve progresivamente menos confiable.

### Ejemplo: una señal de flujo degradante

Considere un lazo de recirculación de bomba con una banda de flujo esperada estable bajo condiciones de operación fijas.

Un patrón de lógica predictiva podría buscar:

• flujo de media móvil por debajo de la línea base histórica,
• varianza creciente en ventana corta,
• aumento del tiempo para estabilizarse después del arranque de la bomba,
• excursiones repetidas de salida PID por encima del rango de corrección normal.

Cualquier señal puede ser ambigua. Juntas, forman una firma de degradación más defendible. Los buenos diagnósticos suelen provenir de la correlación, no de una sola etiqueta.

Los lazos PID no son solo dispositivos de control. También son testigos de diagnóstico.

Un lazo bien instrumentado registra cuánto debe trabajar el controlador para mantener el punto de ajuste. Si ese esfuerzo aumenta con el tiempo mientras la demanda del proceso sigue siendo comparable, el sistema físico puede estar degradándose.

Monitoreo del windup integral y esfuerzo de corrección

La acción integral acumula error con el tiempo para eliminar el desplazamiento. Si el lazo ahora requiere materialmente más contribución integral de la que requería bajo condiciones de operación similares, algo en la ruta del proceso puede haber cambiado.

Los ejemplos incluyen:

• aumento de la fricción del empaque de la válvula,
• ensuciamiento de superficies de transferencia de calor,
• disminución de la eficiencia de la bomba,
• amortiguadores que se vuelven pegajosos,
• sesgo del instrumento desplazándose.

Un patrón de diagnóstico práctico es realizar tendencias de:

• punto de ajuste,
• variable de proceso,
• variable de control,
• término integral acumulado o proxy de corrección equivalente,
• tiempo en banda después de la perturbación.

Si el lazo necesita un 20% más de esfuerzo correctivo este mes para lograr el mismo envolvente de respuesta, el controlador puede estar informando una historia mecánica, la haya escuchado el mantenimiento o no.

Alarmas de saturación de CV

La saturación de la Variable de Control (CV) es uno de los indicadores tempranos más claros de problemas ocultos.

Si la salida PID permanece en o cerca del 100% o 0% más tiempo de lo que justifican la sintonización normal y las condiciones del proceso, el lazo puede estar compensando:

• flujo restringido,
• límites de recorrido del actuador,
• equipo subdimensionado o degradado,
• sesgo del sensor,
• perturbación del proceso más allá del envolvente esperado.

Se puede escribir un peldaño de advertencia acotado para marcar la saturación sostenida antes de que ocurra un disparo del proceso.

Los elementos lógicos típicos incluyen:

• comparador para CV > umbral alto,
• temporizador de retardo a la conexión para persistencia,
• permisivo para excluir el transitorio de arranque,
• bit de advertencia de mantenimiento en lugar de bit de apagado.

Esa última distinción importa. La lógica de advertencia y la lógica de protección no deben fusionarse casualmente. Una es diagnóstica. La otra es autoritaria.

### Un ejemplo compacto: lógica de tasa de cambio y media móvil

A continuación, se muestra una ilustración simple de cómo la lógica predictiva puede implementarse como una capa matemática antes de alarmar.

( Se asume un intervalo de muestreo constante ) PV_Filtrada := (PV_0 + PV_1 + PV_2 + PV_3 + PV_4) / 5.0;

ROC := (PV_Filtrada - PV_Filtrada_Anterior) / Tiempo_Muestreo_Segundos;

Proxy_Varianza := ABS(PV_Bruta - PV_Filtrada);

IF Proxy_Varianza > Umbral_Varianza THEN Temporizador_Ruido := Temporizador_Ruido + Tiempo_Muestreo_Segundos; ELSE Temporizador_Ruido := 0.0; END_IF;

IF (Temporizador_Ruido >= 10.0) AND (CV > 85.0) AND (ABS(SP - PV_Filtrada) > Umbral_Error) THEN Advertencia_Maint_Predictivo := TRUE; END_IF;

PV_Filtrada_Anterior := PV_Filtrada;

Esto es intencionalmente simple. Las implementaciones reales deben tener en cuenta el tiempo de escaneo, el escalado, la supresión de arranque, el estado del modo, los bypasses de mantenimiento y el contexto del estado del proceso.

Un flujo de trabajo de lógica predictiva defendible comienza con un comportamiento de degradación observable, no con una etiqueta "predictiva" genérica.

Construya la lógica en este orden:

Ejemplo: adherencia de válvula, cavitación de bomba, ensuciamiento de sensor, respuesta lenta del actuador.

Ejemplo: aumento de varianza, deriva de línea base, tiempo de recorrido creciente, saturación de CV persistente.

Ejemplo: media móvil, banda muerta, tasa de cambio, persistencia de temporizador, desviación de la línea base.

1. Defina el modo de fallo
2. Identifique la firma visible por software más temprana
3. Elija el tratamiento de señal correcto
4. Separe la advertencia del disparo Las advertencias de mantenimiento predictivo generalmente deben notificar y registrar, no apagar directamente, a menos que la condición también viole un límite de protección.
5. Establezca una definición operativa de "correcto" "Correcto" significa que la advertencia aparece lo suficientemente temprano, bajo las condiciones adecuadas, con un comportamiento de falsos positivos aceptable, y se restablece solo cuando el proceso vuelve a un estado normal verificado.
6. Valide contra escenarios anormales Pruebe el arranque, ráfagas de ruido, modo manual, pérdida de sensor y estados de bypass de mantenimiento.

Aquí es donde Simulation-Ready necesita una definición precisa. En el uso de Ampergon Vallis, un ingeniero Simulation-Ready es aquel que puede probar, observar, diagnosticar y endurecer la lógica de control contra el comportamiento realista del proceso antes de que llegue a un proceso en vivo. No alguien que simplemente puede colocar contactos y bobinas en el orden correcto.

Construya evidencia de ingeniería, no una galería de capturas de pantalla

Si desea demostrar una habilidad de diagnóstico real, documente un cuerpo compacto de evidencia de ingeniería:

Describa la degradación introducida: deriva, ruido, adherencia, retardo, saturación o sesgo.

Explique qué cambió después de la primera prueba: umbrales, filtros, temporización, histéresis o interbloqueos.

1. Descripción del sistema Defina la unidad de proceso, el objetivo de control, las E/S y el envolvente operativo.
2. Definición operativa de "correcto" Indique exactamente qué debe detectar la lógica, qué tan temprano, bajo qué condiciones y con qué reglas de supresión.
3. Lógica de escalera y estado del equipo simulado Muestre la lógica del peldaño y el comportamiento del proceso correspondiente en la simulación.
4. El caso de fallo inyectado
5. La revisión realizada
6. Lecciones aprendidas Registre falsos positivos, detecciones perdidas, dependencias del estado del proceso e implicaciones de puesta en marcha.

Esa estructura es más creíble que una carpeta llena de capturas de pantalla pulidas.

Un entorno de simulación con riesgos contenidos es útil porque muchos comportamientos de mantenimiento predictivo no pueden ensayarse de forma segura en equipos en vivo.

Generalmente, no puede pedirle a un ingeniero junior que inyecte deriva analógica en un lazo de producción, fuerce una válvula a una adherencia progresiva o desestabilice deliberadamente un skid de proceso solo para ver si funciona una advertencia de mantenimiento. El ejercicio derrotaría su propio propósito.

Aquí es donde OLLA Lab se vuelve operativamente útil. OLLA Lab es un simulador de lógica de escalera y gemelo digital interactivo basado en web que permite a los ingenieros construir lógica de escalera, ejecutar simulación, inspeccionar E/S y variables, y validar la lógica contra el comportamiento realista de la máquina en un entorno contenido. En el contexto acotado de este artículo, su valor es específico: proporciona un lugar para ensayar la lógica matemática predictiva contra patrones de degradación simulados antes de que exista cualquier decisión de implementación.

Inyección de firmas de deriva, ruido y desgaste

Dentro de un flujo de trabajo de simulación, los ingenieros pueden practicar:

• cambiar las líneas base de entrada analógica para imitar la deriva del sensor,
• agregar varianza u oscilación para imitar la instrumentación ruidosa,
• aumentar el retardo de comando a retroalimentación para imitar el desgaste del actuador,
• observar el comportamiento de salida PID bajo una resistencia de proceso creciente,
• probar si los umbrales de advertencia se activan antes de los fallos críticos.

El beneficio clave no es la conveniencia. Es la repetibilidad.

Un ejercicio útil de mantenimiento predictivo en OLLA Lab incluiría:

• un escenario de bomba, válvula o tanque,
• etiquetas analógicas visibles en el panel de variables,
• herramientas PID o comparadores donde sea relevante,
• una secuencia de degradación definida,
• comportamiento de advertencia esperado,
• un paso de verificación contra el estado del equipo simulado.

Ese último paso importa. La lógica no debe validarse solo contra cambios de etiquetas. También debe verificarse contra la consecuencia del proceso virtual. Una advertencia que se ve elegante en la vista de peldaño pero llega después de que el tanque virtual se desborda no es una alerta temprana.

Validación de lógica contra gemelos digitales

La validación de gemelos digitales debe definirse de forma estrecha aquí: probar si la lógica de control produce el comportamiento esperado cuando se aplica a un modelo virtual realista de equipo o estado de proceso.

Eso significa observar si:

• la advertencia ocurre antes de que el proceso cruce un umbral dañino,
• la lógica permanece estable bajo el ruido operativo normal,
• los modos de arranque y manual no generan alarmas molestas,
• los bypasses de mantenimiento se comportan según lo previsto,
• la respuesta del equipo simulado coincide con la interpretación del estado de la escalera.

Esto no es lo mismo que la certificación de seguridad formal, la verificación SIL o la aceptación en sitio. Es ensayo y validación en un entorno acotado.

Un flujo de trabajo práctico de OLLA Lab para diagnósticos predictivos

Una secuencia de laboratorio disciplinada podría verse así:

Ese orden refleja el juicio de puesta en marcha: establecer lo normal, inyectar lo anormal, verificar la respuesta, revisar, repetir.

1. Construya la lógica de escalera base para la unidad de proceso.
2. Ejecute el escenario bajo condiciones nominales y registre el comportamiento analógico de la línea base.
3. Agregue un bloque de media móvil o tasa de cambio.
4. Introduzca una firma de degradación a la vez.
5. Sintonice los umbrales de advertencia y los temporizadores de persistencia.
6. Compare las alarmas de estado de escalera contra el comportamiento del equipo simulado.
7. Revise la lógica para reducir los falsos positivos.
8. Vuelva a ejecutar el escenario con un perfil de perturbación diferente.

Los estándares y la literatura no dicen "use este peldaño exacto". Respaldan la lógica de ingeniería subyacente: detectar comportamientos anormales temprano, validar el comportamiento de control antes de la implementación donde sea posible y tratar los diagnósticos como parte de la confiabilidad del sistema en lugar de como una ocurrencia tardía.

La base relevante incluye:

- IEC 61508: enfatiza la disciplina del ciclo de vida, la integridad sistemática y el rigor de validación para sistemas relacionados con la seguridad eléctricos/electrónicos/programables. Si bien la lógica de mantenimiento predictivo no es automáticamente una función de seguridad, la mentalidad de validación del estándar sigue siendo instructiva. - Guía de exida y práctica de seguridad funcional: distinguen repetidamente entre cobertura de diagnóstico, comportamiento de prueba y respuesta validada del sistema. - Literatura de IFAC y control de procesos: respalda el uso de la evaluación del desempeño del control, el comportamiento del lazo y las firmas de actuadores o sensores como indicadores de degradación. - Literatura de sensores y monitoreo de condiciones: respalda el análisis de tendencias, el análisis de varianza y la detección de anomalías en señales industriales para fines de mantenimiento. - Estudios de fuerza laboral manufacturera de Deloitte y BLS: respaldan el contexto más amplio de que la presión de personal técnico y la exposición al tiempo de inactividad siguen siendo preocupaciones operativas graves, aunque no deben reducirse a una sola estadística de titular.

La conclusión práctica es modesta y defendible: la lógica de PLC para mantenimiento predictivo es más fuerte cuando traduce la degradación física en un comportamiento de señal observable, y luego valida la lógica de advertencia contra la respuesta realista del proceso antes de la implementación.

Una buena implementación incluye límites claros entre diagnósticos, acción de mantenimiento y protección.

Utilice esta lista de verificación:

• modo de fallo definido
• envolvente de operación normal conocida
• escalado y filtrado de señales
• temporización de persistencia
• supresión de arranque y modo
• separación de advertencia frente a disparo
• texto de alarma orientado al operador
• ruta de registro de mantenimiento
• validación estilo simulación o FAT
• historial de revisiones después de pruebas anormales

Si falta uno de ellos, la lógica aún puede ejecutarse, pero es menos probable que sobreviva al contacto con un proceso real.

- U.S. Bureau of Labor Statistics (BLS) – Occupational Outlook Handbook - Deloitte Insights – 2025 Manufacturing Industry Outlook - The Manufacturing Institute & Deloitte – Talent and workforce research - European Commission – Industry 5.0 - IEC 61131-3 standard overview (IEC) - IEC 61508 functional safety standard overview (IEC) - ISO 10218 industrial robot safety standard overview (ISO) - International Federation of Robotics – World Robotics reports - IFAC-PapersOnLine journal homepage - Sensors journal – industrial digital twin and monitoring research