Cómo programar la compensación de deriva analógica en un PLC para sensores con desgaste

La compensación de deriva analógica en un PLC consiste en detectar y gestionar el error gradual del sensor que permanece dentro del rango normal de 4–20 mA. En la práctica, los ingenieros combinan filtrado, comprobaciones de plausibilidad de tasa de cambio, lógica de offset y alarmas de mantenimiento, para luego validar estos comportamientos en simulación antes de aplicarlos a un proceso real.

La deriva analógica suele ser más peligrosa que un fallo analógico crítico, ya que puede permanecer eléctricamente válida mientras se vuelve físicamente incorrecta. Un bucle roto suele anunciarse por sí solo; un transmisor con deriva a menudo no lo hace.

Durante la validación interna en el escenario de desviación analógica acelerada de OLLA Lab, la lógica de control sin compensación en un bucle de nivel simulado mostró una desviación de hasta el 4,2% entre el valor de proceso inferido y el estado físico simulado antes de que existiera cualquier condición de alarma estándar fuera de rango [Metodología: n=12 ejecuciones de simulación en una tarea de control de nivel de tanque, comparador base = modelo de señal nominal sin deriva con lógica idéntica, ventana de tiempo = ciclo de desviación acelerado de 24 horas ejecutado durante la validación de laboratorio interna de marzo de 2026]. Esto respalda la afirmación limitada de que la deriva dentro del rango puede producir un comportamiento de control materialmente engañoso antes de que reaccione la lógica convencional de fallo por sub-rango o sobre-rango. No respalda ninguna afirmación general sobre todas las plantas, todos los sensores o todas las arquitecturas de control.

Programar para la deriva no se trata de pretender que el software pueda reparar hardware dañado. Se trata de ampliar la visibilidad diagnóstica y preservar la calidad del control el tiempo suficiente para detectar, compensar, alarmar y realizar el mantenimiento de manera ordenada.

La deriva analógica es más peligrosa porque crea un fallo dentro del rango. La señal permanece dentro de la banda eléctrica esperada, por lo que el PLC la acepta como plausible a menos que la lógica adicional indique lo contrario.

Un fallo crítico es más fácil de detectar. En un bucle convencional de 4–20 mA, un cable cortado, un cortocircuito o un fallo grave del transmisor a menudo llevan la señal fuera del rango de medición normal. Esa es precisamente la razón por la que existen convenciones de señalización de fallos basadas en estándares.

NAMUR NE 43 detecta muchos fallos críticos, no la degradación gradual de la veracidad

NAMUR NE 43 define regiones de corriente de fallo estandarizadas para instrumentación analógica, de modo que los sistemas receptores puedan distinguir la medición del proceso del comportamiento de fallo del dispositivo. En la práctica común:

• < 3,6 mA a menudo indica sub-rango o fallo
• > 21,0 mA a menudo indica sobre-rango o fallo
• 4,0 a 20,0 mA se trata como la banda operativa válida

Esto funciona bien para bucles rotos y fallos obvios del transmisor. No resuelve la deriva que permanece dentro de 4–20 mA mientras la medición física se aleja lentamente de la realidad.

| Condición de la señal | El PLC ve | Respuesta típica de la lógica de fallo básica | Riesgo real | |---|---|---|---| | 0 mA o cerca de cero | Señal inválida | Dispara fallo de sub-rango | Generalmente obvio y manejado rápidamente | | < 3,6 mA | Región de fallo | Acción de alarma / a prueba de fallos | Detectable por lógica de fallo estándar | | > 21,0 mA | Región de fallo | Acción de alarma / a prueba de fallos | Detectable por lógica de fallo estándar | | 4–20 mA con sesgo gradual | Señal válida | Sin fallo por comprobaciones de rango simples | El controlador actúa sobre un valor de proceso falso |

El problema operativo es simple: un bucle PID no puede distinguir entre "preciso pero inconveniente" y "plausible pero incorrecto" a menos que se le proporcione más contexto.

¿Qué causa la deriva analógica en plantas reales?

La deriva analógica suele provenir de una degradación física lenta, no de un colapso eléctrico repentino.

Las causas comunes incluyen:

- Ensuciamiento del sensor: incrustaciones, lodos, recubrimientos o biopelículas en las sondas - Envejecimiento térmico: degradación de termopares, deriva de componentes del transmisor - Fatiga mecánica: desgaste del diafragma en instrumentos de presión - Inestabilidad de referencia: envejecimiento de sensores de pH y conductividad - Estrés ambiental: vibración, entrada de humedad, ciclos de temperatura - Efectos de instalación: problemas en líneas de impulso, estrés de montaje, blindaje deficiente, problemas de puesta a tierra

La distinción importante es fallo frente a degradación. Los fallos críticos rompen la cadena de medición. La deriva la degrada mientras deja la cadena aparentemente intacta.

Programar para el décimo año significa escribir lógica de control para un instrumento tal como se comportará después de la exposición, el ensuciamiento, la vibración y el historial de mantenimiento, no solo como se comporta el día de la puesta en marcha.

Para este artículo, programar para la deriva significa implementar estructuras de software que hagan que el error de medición gradual sea más observable y menos dañino operativamente. En términos de ingeniería acotada, esto incluye:

• Lógica de offset de calibración por software para condiciones de cero o referencia conocidas
• Comprobaciones de plausibilidad de tasa de cambio frente a límites físicos del proceso
• Filtrado para suprimir el ruido sin ocultar el movimiento real del proceso
• Alarmas de desviación entre mediciones redundantes o inferidas
• Indicadores de mantenimiento que indican que la compensación está creciendo más allá de los límites aceptables

Aquí es también donde el uso de Simulation-Ready por parte de Ampergon Vallis necesita una definición precisa. Un ingeniero Simulation-Ready no es alguien que simplemente puede escribir sintaxis de escalera de memoria. Un ingeniero Simulation-Ready puede probar, observar, diagnosticar y endurecer la lógica de control contra el comportamiento realista del proceso antes de que llegue a un proceso real.

Ninguna estrategia de software soluciona completamente la instrumentación degradada. Sin embargo, puede reducir el error de control, mejorar la visibilidad de los fallos y crear una ventana de mantenimiento más limpia.

1. Lógica de auto-cero o offset de tara

La lógica de auto-cero captura el sesgo del sensor durante un estado de referencia física conocido y almacena ese sesgo como un offset utilizado para corregir el valor medido.

Esto es apropiado solo cuando el proceso tiene una condición de referencia defendible, como:

• un tanque vacío con nivel bajo verificado
• una línea de presión venteada a referencia atmosférica
• una báscula con carga cero confirmada
• una ruta de flujo detenida con estado de flujo cero confirmado

Una rutina de auto-cero adecuada requiere permisivos estrictos. Si el estado de referencia no es real, la corrección se convierte en un error formalizado.

2. Comprobación de plausibilidad de tasa de cambio

La lógica de tasa de cambio (RoC, por sus siglas en inglés) rechaza o alarma valores que se mueven más rápido de lo que el proceso puede cambiar físicamente.

Ejemplos:

• el nivel de un tanque grande no debería saltar un 8% en un ciclo de escaneo
• un proceso térmico no debería ganar 20°C en unos pocos segundos sin una entrada de energía correspondiente
• una señal de presión no debería oscilar más rápido de lo que permite el sistema mecánico a menos que existan problemas de ruido o instrumentación

La lógica RoC no corrige directamente la deriva, pero ayuda a distinguir el cambio lento y creíble del comportamiento de señal inverosímil y puede evitar que los datos erróneos impulsen decisiones de control.

3. Filtrado

El filtrado suaviza el ruido y las perturbaciones a corto plazo para que el controlador reaccione al comportamiento del proceso en lugar de al ruido eléctrico.

Las opciones de software comunes incluyen:

• filtros de media móvil
• filtros de retardo de primer orden
• suavizado ponderado
• manejo de banda muerta para pequeñas fluctuaciones

El filtrado es útil, pero también es fácil de usar incorrectamente. Un filtro demasiado agresivo ocultará la realidad del proceso y retrasará el reconocimiento de fallos.

4. Comparación de sensores redundantes

La lógica de sensores redundantes compara dos mediciones de la misma variable de proceso o variables relacionadas y genera una alarma cuando la desviación supera un umbral definido.

Los patrones típicos incluyen:

• Comparación directa del Sensor A frente al Sensor B
• valor del transmisor frente al valor inferido por balance de masa o estado del equipo
• variable de proceso frente al estado esperado durante pasos de secuencia conocidos

Esto suele ser más robusto que la lógica de offset independiente porque crea una señal de discrepancia.

5. Límite de compensación y alarma de mantenimiento

La compensación siempre debe tener un techo. Si el offset requerido sigue aumentando, la lógica debe dejar de tratar el instrumento como saludable y emitir una alarma de mantenimiento.

Las condiciones de alarma útiles incluyen:

• la magnitud del offset supera el umbral de ingeniería
• el offset cambia con demasiada frecuencia
• la desviación entre sensores redundantes persiste más allá del umbral del temporizador
• los valores filtrados y brutos divergen más allá de la envolvente de ruido esperada

Una rutina de compensación sin un límite de mantenimiento no es una estrategia de resiliencia completa.

Una rutina de auto-cero solo debe ejecutarse cuando el proceso se encuentra en una condición de referencia verificada.

Permisivos requeridos antes de capturar un offset de cero

Los permisivos típicos pueden incluir:

• Pump_Off = TRUE
• Valve_Open = TRUE o estado conocido de venteo/drenaje abierto
• Level_Switch_Low = TRUE u otra confirmación independiente de condición vacía
• Ninguna alarma activa que inhiba la calibración
• Autorización del operador o de la secuencia presente
• Calibración no en curso

La confirmación independiente es importante. Usar el sensor que presenta deriva para probar su propio cero puede automatizar una respuesta incorrecta.

Ejemplo de estructura de escalera

Rung 1: Pump_Off Valve_Open Level_Switch_Low Zero_Request ----] [---------] [-------------] [--------------] [----------------(Enable_Zero_Routine)

Rung 2: Enable_Zero_Routine One_Shot ----] [------------------] [----------------------------------------(Capture_Zero)

Rung 3: Capture_Zero ----] [------------------[SUB Raw_Input Zero_Reference_Counts Sensor_Offset_Value]

Rung 4: Always_On ----] [------------------[SUB Raw_Input Sensor_Offset_Value Calibrated_PV]

Rung 5: ABS(Sensor_Offset_Value) > Offset_Limit ---------------------------------------------------------------(Drift_Maintenance_Alarm)

Qué hace cada peldaño (rung)

• Rung 1 establece los permisivos para un evento de cero válido.
• Rung 2 utiliza un disparo único (one-shot) para que el offset se capture una vez, no en cada escaneo.
• Rung 3 calcula el offset entre la entrada bruta y la referencia conocida.
• Rung 4 aplica el offset almacenado para producir una variable de proceso calibrada.
• Rung 5 genera una alarma si el offset crece más allá de un umbral de mantenimiento aceptable.

La aritmética exacta depende de la convención de escalado. Algunos sistemas capturan cuentas brutas, otros unidades de ingeniería. Cualquiera puede funcionar si la referencia es clara y la ruta de conversión está controlada.

¿Qué puede salir mal con la lógica de auto-cero?

Las rutinas de auto-cero fallan cuando los permisivos son débiles o cuando se asume el estado del proceso en lugar de verificarlo.

Los modos de fallo comunes incluyen:

• capturar el cero mientras queda producto residual en el recipiente
• aplicar offsets después del mantenimiento sin restablecer las comprobaciones de validación
• permitir que los operadores activen la calibración desde la HMI sin confirmación física
• ocultar la degradación crónica del instrumento detrás de una compensación que crece continuamente
• corregir la PV mostrada mientras se dejan los cálculos de alarma y control en la ruta de señal bruta

Los límites de tasa de cambio y el filtrado realizan trabajos diferentes. A menudo se discuten juntos porque ambos se encuentran en la capa de acondicionamiento de señal, pero no son intercambiables.

El filtrado reduce el ruido

El filtrado suaviza la variación de corta duración para que la lógica vea un valor de proceso más estable.

Utilice el filtrado cuando:

• la señal bruta contiene ruido eléctrico
• el proceso es naturalmente lento en relación con el tiempo de escaneo
• las fluctuaciones menores están creando alarmas molestas o acciones de control inestables

Evite el filtrado excesivo cuando:

• el proceso es rápido
• el tiempo de respuesta de seguridad es importante
• los operadores necesitan ver transitorios reales
• la detección de estados anormales depende del reconocimiento rápido de cambios

Las comprobaciones de tasa de cambio imponen plausibilidad física

La lógica RoC pregunta si la señal se está moviendo de una manera que el proceso realmente puede soportar.

Utilice comprobaciones RoC cuando:

• se conozca la dinámica del proceso
• los grandes saltos instantáneos sean físicamente imposibles
• una señal incorrecta pueda desencadenar una acción de control dañina
• desee alarmar, congelar o sustituir valores cuando el movimiento sea inverosímil

Un patrón práctico es:

1. leer el valor analógico bruto
2. aplicar un filtrado ligero
3. comparar el valor actual frente al anterior a lo largo del tiempo
4. calcular la RoC
5. alarmar o mantener el valor si la RoC supera el umbral físico
6. alimentar el valor validado en la lógica de control

Esa secuencia suele ser más defendible que colocar un filtro pesado frente al PID y esperar lo mejor.

Probar la lógica de deriva en equipos reales es lento, intrusivo y, a menudo, injustificable operativamente. Ahí es donde la simulación se vuelve útil.

En OLLA Lab, el valor relevante no es que el entorno sea digital. El valor es que puede observar la lógica de control frente a un modelo de proceso cambiante, inyectar una condición de fallo acotada e inspeccionar el comportamiento de E/S sin tocar el equipo de producción.

Lo que OLLA Lab está haciendo aquí, en términos acotados

Para este caso de uso, OLLA Lab funciona como un simulador de lógica de escalera y gemelo digital basado en web donde un ingeniero puede:

• construir o editar lógica de escalera en el navegador
• ejecutar la simulación sin hardware físico
• monitorear variables y estados de E/S
• comparar el comportamiento de la escalera frente al estado del equipo simulado
• aplicar desviaciones basadas en escenarios para probar el manejo de fallos y la lógica de compensación

Ese es un entorno de validación y ensayo. No es un sustituto para las pruebas de aceptación en planta, la calibración de campo o la verificación formal de seguridad funcional.

Un flujo de trabajo práctico de validación de deriva en OLLA Lab

Un flujo de trabajo típico es:

1. Construir la lógica de control base en el editor de escalera Incluir escalado de entrada bruta, PV calibrada, alarmas y cualquier uso de la señal por parte del PID o la secuencia.
2. Abrir el modo de simulación Iniciar el modelo de proceso y verificar el comportamiento nominal sin deriva aplicada.
3. Utilizar el Panel de Variables Observar la entrada bruta, la PV corregida, el valor de offset, los bits de alarma y cualquier estado de proceso relacionado.
4. Seleccionar o configurar un escenario de deriva analógica Aplicar un sesgo matemático lento a la entrada analógica bruta durante una línea de tiempo acelerada.
5. Comparar la PV bruta frente al estado físico simulado Esta es la prueba clave. El punto no es si el peldaño compila; es si la lógica todavía representa el proceso.
6. Validar el comportamiento de compensación Confirmar si la lógica de offset, el filtrado, las comprobaciones RoC y las alarmas de mantenimiento se comportan según lo previsto.
7. Revisar y volver a ejecutar Cambiar umbrales, permisivos o límites de compensación y repetir el escenario.

Aquí es donde la compresión del tiempo importa. Un patrón de degradación de 24 horas puede evaluarse en minutos en lugar de consumir un turno o un día de producción.

La pregunta correcta no es "¿funcionó la lógica?". La pregunta correcta es "¿qué dejó de ser cierto a medida que la señal se degradaba?".

Observe estas variables juntas, no de forma aislada

Al validar la compensación de deriva, monitoree:

• Entrada analógica bruta
• Valor de ingeniería bruto escalado
• PV corregida o compensada
• Estado del equipo físico simulado
• Magnitud del offset
• Valor de RoC
• Bits de alarma y mantenimiento
• Salida PID o decisiones de secuencia que utilizan la PV

La comparación entre el estado físico simulado y la PV visible para el controlador es especialmente importante.

Defina "correcto" antes de comenzar la prueba

Un ingeniero debe definir la corrección en términos observables, tales como:

• la PV compensada permanece dentro de una tolerancia establecida del estado físico simulado
• la alarma de deriva se activa después de que se cumplen las condiciones de umbral y temporizador
• la rutina de offset solo se ejecuta cuando los permisivos son verdaderos
• la salida PID no se satura ni persigue un error falso más allá de los límites definidos
• la alarma de mantenimiento se activa antes de que la compensación exceda la política de ingeniería

Sin una definición operativa de correcto, la simulación se vuelve difícil de evaluar rigurosamente.

Una galería de capturas de pantalla no es una evidencia de ingeniería sólida por sí sola.

Si desea demostrar una capacidad real (internamente, ante un ingeniero jefe o en un contexto de contratación), documente un cuerpo compacto de pruebas utilizando esta estructura:

Establezca los criterios de aceptación en términos medibles: tolerancia, umbral de alarma, offset permisible, tiempo de respuesta o comportamiento de secuencia.

Describa la deriva o desviación exacta introducida: magnitud, dirección, tasa, duración y si permaneció dentro del rango.

Registre qué cambió en la lógica: captura de offset, constante de filtro, umbral RoC, alarma de mantenimiento, comparación de sensores o estructura de permisivos.

1. Descripción del sistema Defina el proceso, el tipo de instrumento, el rango de señal, el objetivo de control y los estados operativos relevantes.
2. Definición operativa de "correcto"
3. Lógica de escalera y estado del equipo simulado Muestre la lógica del peldaño y el comportamiento correspondiente de la máquina o proceso simulado en condiciones nominales.
4. El caso de fallo inyectado
5. La revisión realizada
6. Lecciones aprendidas Explique qué pasó por alto el diseño inicial, qué mejoró la lógica revisada y qué requiere aún mantenimiento o verificación de campo.

Ese formato ayuda a demostrar juicio, no solo familiaridad con el software.

Las ideas de ingeniería subyacentes aquí están bien establecidas, pero pertenecen a diferentes dominios y no deben confundirse.

Estándares y marcos técnicos relevantes

Define niveles de señal de fallo estandarizados para interfaces de corriente analógicas. Útil para distinguir fallos críticos del comportamiento de medición dentro del rango válido.

• NAMUR NE 43

Proporciona el marco de seguridad funcional más amplio para sistemas relacionados con la seguridad eléctricos, electrónicos y electrónicos programables. Es relevante para la filosofía de manejo de fallos, pero no significa que cada rutina de compensación de deriva sea una función de seguridad.

• IEC 61508

La guía de la industria sobre calibración, acondicionamiento de señales, gestión de alarmas y mantenimiento de sensores informa cómo debe acotarse la compensación.

• Práctica de instrumentación de procesos e ISA

La investigación en capacitación industrial y validación basada en modelos respalda el uso de la simulación para ensayos, inyección de fallos y preparación para la puesta en marcha, especialmente donde las pruebas en vivo son costosas o arriesgadas.

• Literatura sobre gemelos digitales y simulación

Un límite necesario en las declaraciones de seguridad

La lógica de compensación de deriva puede mejorar la calidad del control y la visibilidad diagnóstica. Eso no la convierte automáticamente en una función de seguridad certificada, un mecanismo con clasificación SIL o un sustituto para el mantenimiento de instrumentos, pruebas de prueba o capas de protección independientes.

OLLA Lab es la herramienta adecuada cuando la tarea es ensayar y validar la lógica consciente de la deriva frente a un proceso simulado antes de exponer un sistema real a esa lógica.

En términos de producto acotados, OLLA Lab respalda este trabajo permitiendo a los ingenieros:

• crear lógica de escalera en un editor basado en navegador
• ejecutar simulaciones sin hardware
• inspeccionar variables, etiquetas y comportamiento de E/S
• trabajar a través de escenarios industriales realistas
• comparar la lógica de control frente al comportamiento del gemelo digital
• iterar rápidamente sobre la lógica de estado anormal y las comprobaciones de estilo de puesta en marcha

Eso lo hace útil para tareas que los empleadores no pueden asignar económicamente a ingenieros sin experiencia en un proceso real: validar lógica, rastrear causa y efecto, manejar condiciones anormales y revisar la lógica después de un fallo.

No debe posicionarse como un atajo hacia la competencia en el sitio, la certificación o el cumplimiento formal. La puesta en marcha en campo todavía implica la condición de la instrumentación, la calidad de la instalación, el conocimiento del proceso y el juicio humano bajo restricciones que ningún simulador reproduce completamente.

La compensación de deriva analógica es un problema de calidad de control y diagnóstico, no solo un ejercicio de programación. El caso peligroso no es el transmisor muerto que todos notan. Es el transmisor envejecido que permanece dentro de 4–20 mA mientras mueve silenciosamente al controlador lejos del proceso real.

La respuesta práctica es combinar medidas de software acotadas (lógica de offset, filtrado, comprobaciones de plausibilidad RoC, comparación de sensores y alarmas de mantenimiento) con una validación disciplinada. La simulación es valiosa porque comprime el tiempo y expone el comportamiento. Permite a los ingenieros probar cómo responde la lógica a la degradación lenta antes de que la planta pague el costo.

Si el objetivo es estar Simulation-Ready, el estándar es claro: demuestre que la lógica sigue siendo observable, diagnóstica y defendible bajo condiciones de fallo realistas antes de que llegue al equipo real.

- Descripción general de seguridad funcional IEC 61508 - Recursos de automatización y seguridad funcional de exida - Åström & Hägglund, *Advanced PID Control* (ISA) - Skogestad (2003), Reglas de sintonización PID00062-8) - Tao et al. (2019), Gemelo digital en la industria