Cómo solucionar problemas de escalado no lineal y control de relación PID en PLCs

Para solucionar casos límite en PLCs, como el escalado no lineal de tanques y el control de relación PID, los ingenieros deben validar la lógica frente al comportamiento simulado del proceso antes de la implementación. OLLA Lab proporciona un entorno basado en navegador para crear lógica de escalera (ladder), inyectar perturbaciones, observar la causalidad de E/S y comparar la filosofía de control prevista con la respuesta real del equipo sin riesgos para el hardware.

Las respuestas de los libros de texto sobre PLCs suelen fallar por una razón sencilla: muchas de ellas asumen sensores lineales, actuadores obedientes y un proceso que no se comporta de forma errática. Las plantas reales son menos educadas.

Cuando un tanque horizontal no escala de forma lineal, o un bucle de relación comienza a derivar durante una perturbación de flujo, los ingenieros a menudo terminan en foros leyendo respuestas parciales de desconocidos con distintos niveles de rigor. Algunos de esos consejos son excelentes. Otros son folclore con sintaxis. El riesgo comienza cuando la lógica no verificada pasa directamente de una pestaña del navegador a un controlador en vivo.

En un ejercicio reciente de control de calidad interno de Ampergon Vallis, los ingenieros replicaron 100 casos de resolución de problemas analógicos no resueltos en foros dentro de OLLA Lab y descubrieron que 72 de los "fallos de sintonización PID" reportados se explicaban mejor por errores de escalado o caracterización de señal aguas arriba que por la sintonización del controlador por sí sola [Metodología: Tamaño de la muestra = 100 casos analógicos no resueltos estilo foro; Definición de la tarea = reproducir el problema, aislar la fuente del fallo y clasificar la causa dominante; Comparador de referencia = diagnóstico original del foro o planteamiento implícito del fallo; Ventana temporal = revisión interna de control de calidad de Ampergon Vallis, Q1 2026]. Esto respalda un punto concreto: la simulación ayuda a separar los problemas de bucle de los problemas de medición. No demuestra ninguna tasa de fallos a nivel industrial.

Las respuestas de los libros de texto fallan porque suelen modelar la ruta de la señal como ideal y la respuesta de la máquina como inmediata. Los sistemas de campo rara vez ofrecen alguna de estas condiciones.

Una entrada de 4–20 mA en un proceso en vivo no es solo un número para escalar. Transporta errores del transmisor, ruido de cableado, efectos de filtrado, retardo del sensor, posibles problemas de conexión a tierra y, a veces, el sabotaje silencioso de una mala instalación. Un comando de válvula no es lo mismo que el movimiento de la válvula. La fricción estática (stiction), la banda muerta, el juego mecánico (backlash) y la neumática lenta son factores importantes. La lógica de escalera puede ser correcta mientras el proceso sigue comportándose mal. La puesta en marcha enseña esa distinción rápidamente.

El error práctico es tratar la lógica del PLC como si fuera solo sintaxis. No lo es. Es una intención de control ejecutable acoplada a un comportamiento físico.

Aquí es donde un entorno de simulación se vuelve operativamente útil. En OLLA Lab, los usuarios pueden crear lógica de escalera en un editor basado en navegador, ejecutar la secuencia en modo de simulación, inspeccionar variables y estados de E/S, y probar el comportamiento analógico antes de que intervenga cualquier hardware. Eso es importante porque "listo para la simulación" debería significar algo específico: un ingeniero puede probar, observar, diagnosticar y endurecer la lógica de control frente al comportamiento realista del proceso antes de que llegue a un proceso en vivo.

Vale la pena hacer una corrección útil aquí. Muchos "problemas de PID" no son problemas de PID. Son errores de escalado, suposiciones de retroalimentación incorrectas o fallos de secuenciación que llevan una etiqueta de PID.

El escalado lineal estándar falla cuando la geometría del recipiente no es lineal. Una conversión simple de pendiente y compensación (offset) no es físicamente correcta para tanques esféricos, tanques cilíndricos horizontales o cualquier recipiente donde el volumen no aumenta proporcionalmente con el nivel.

IEC 61131-3 le proporciona el marco de programación para implementar la lógica, pero no rescata un mal modelo de proceso. Si la geometría del tanque no es lineal, el método de escalado también debe ser no lineal.

¿Cuál es el enfoque de ingeniería correcto?

El enfoque correcto es convertir el nivel medido en volumen real utilizando:

• una tabla de búsqueda (lookup table) caracterizada,
• interpolación lineal por tramos entre puntos de ruptura (breakpoints), o
• una ecuación geométrica explícita si los requisitos del controlador y de mantenibilidad lo permiten.

En la mayoría de los entornos de planta, la aproximación lineal por tramos es la respuesta práctica. A menudo es lo suficientemente precisa cuando se segmenta correctamente, es más fácil de validar y más fácil de entender para el siguiente ingeniero a las 2 a.m. La elegancia es opcional; la capacidad de recuperación no lo es.

¿Por qué falla una instrucción SCP estándar?

Una instrucción estándar de escala con parámetros asume que:

• la señal de entrada es lineal con respecto a la variable medida, y
• la variable medida es lineal con respecto a la cantidad de ingeniería que le interesa.

Para un tanque cilíndrico horizontal, el nivel puede ser lineal con respecto a la salida del transmisor, pero el volumen no es lineal con respecto a la altura. La parte central del tanque acumula volumen más rápido por unidad de altura que los extremos. Si utiliza una escala lineal única, el volumen mostrado será incorrecto en gran parte del rango, y cualquier control aguas abajo que utilice ese valor heredará el error.

¿Cómo se implementa el escalado no lineal en OLLA Lab?

El flujo de trabajo es directo y comprobable.

Escriba la lógica de escalera o la lógica de cálculo equivalente que:

• encuentre el segmento activo,
• calcule la pendiente local,
• interpole entre puntos adyacentes,
• emita el volumen real estimado.

1. Mapear la geometría Defina la relación nivel-volumen utilizando de 10 a 20 puntos de ruptura en todo el rango del recipiente.
2. Construir la estructura de datos Ingrese los puntos de ruptura como arreglos o variables mapeadas en el Panel de Variables de OLLA Lab.
3. Ejecutar la lógica de interpolación
4. Simular el proceso Ejecute el escenario del tanque en modo de simulación y varíe la señal de nivel en todo el rango.
5. Comparar el estado calculado frente al observado Valide que el volumen calculado siga el estado del tanque simulado en los rangos bajo, medio y alto.

El control de relación no es un bucle PID intentando controlar dos flujos a la vez. La arquitectura correcta suele ser una disposición maestro-esclavo en la que el flujo salvaje (wild flow) determina el punto de ajuste (setpoint) del flujo controlado.

La relación que lo rige es simple:

SP de flujo controlado = PV de flujo salvaje × Ajuste de relación

Esa ecuación es la filosofía de control en una línea. Todo lo demás es detalle de implementación, aunque el detalle de implementación es donde las plantas se vuelven costosas.

¿Cómo se valida el control de relación en OLLA Lab?

Las herramientas analógicas, la visibilidad de variables y el flujo de trabajo de simulación orientado a PID de OLLA Lab hacen que esto sea comprobable sin tocar un skid en vivo.

Una secuencia de validación práctica es:

• crear dos etiquetas (tags) de flujo analógico,
• designar una como la PV de flujo salvaje,
• calcular el punto de ajuste esclavo a partir de la ecuación de relación,
• vincular el punto de ajuste esclavo al bucle de flujo controlado,
• ejecutar la simulación e inyectar una perturbación en el flujo salvaje,
• observar si el flujo controlado sigue proporcionalmente,
• verificar si hay sobreimpulso (overshoot), retardo, saturación y windup integral.

La simulación es el puente entre el consejo plausible y la lógica desplegable. Convierte una sugerencia verbal en un comportamiento observado bajo condiciones controladas.

Un entorno de software-in-the-loop permite a un ingeniero cerrar esas brechas antes de la puesta en marcha en el sitio. En términos operativos, la validación de gemelo digital significa comparar la secuencia prevista y la respuesta esperada del proceso frente al comportamiento simulado observado.

¿Qué se debe validar antes de la implementación?

Como mínimo, valide:

¿Cada cambio de entrada produce la salida y la transición de estado esperadas?

• Causalidad de E/S

¿Los estados de inicio, ejecución, parada, disparo y reinicio ocurren en el orden previsto?

• Integridad de la secuencia

¿El escalado, el filtrado, las alarmas y las interacciones PID se comportan en todo el rango operativo?

• Comportamiento analógico

¿Qué sucede ante la pérdida de sensor, retroalimentación con rebote (chattering), actuación retardada o demanda de proceso imposible?

• Condiciones anormales

Yaga es más útil cuando el planteamiento del problema existe como narrativa en lugar de lógica terminada. Los ingenieros senior a menudo explican las soluciones como filosofía de control, no como implementación peldaño a peldaño.

¿Cómo deberían usarlo los ingenieros de forma segura?

Un flujo de trabajo disciplinado se ve así:

1. Pegue o resuma la filosofía de control.
2. Pida a Yaga que desglose la narrativa en estados, permisivos, enclavamientos, alarmas y salidas.
3. Construya o refine la lógica de escalera en el editor.
4. Ejecute la simulación.
5. Inspeccione variables, transiciones de E/S y respuesta analógica.
6. Inyecte un fallo.
7. Revise la lógica basándose en el comportamiento observado.

Las afirmaciones del artículo se basan en estándares establecidos y prácticas de control de procesos, con límites claros.

Estándares y referencias relevantes

• IEC 61131-3 define lenguajes de programación y estructuras de software comunes para controladores programables.
• ISA-5.1 estandariza los símbolos de instrumentación y la identificación.
• IEC 61508 enmarca la seguridad funcional a nivel de sistema.

Este artículo fue preparado por el equipo de ingeniería de Ampergon Vallis Lab, especializado en la validación de sistemas de control y metodologías de simulación para entornos industriales.

El contenido ha sido verificado internamente por el equipo de control de calidad de Ampergon Vallis, asegurando que las metodologías de simulación descritas se alinean con las prácticas estándar de la industria y las capacidades actuales de OLLA Lab.

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standard overview - NIST Smart Manufacturing Profile - IEEE Access: Digital twin enabling technologies (DOI)