Cómo corregir errores en totalizadores de flujo en PLC mediante matemáticas de enteros frente a reales

Los errores en los totalizadores de flujo en PLC suelen provenir de dos fallas matemáticas distintas: el truncamiento de enteros y la pérdida de precisión en números de punto flotante de precisión simple. Las etiquetas INT descartan el flujo fraccionario, mientras que las etiquetas REAL de 32 bits pueden llegar a dejar de registrar pequeños incrementos frente a un total acumulado grande. Una totalización confiable requiere disciplina en los tipos de datos, un diseño de desbordamiento (rollover) y una validación basada en simulación.

Un totalizador de flujo puede ser incorrecto incluso cuando el transmisor, la bomba y las tuberías se comportan correctamente. La falla suele estar dentro del modelo aritmético del PLC, no en el proceso. Esa distinción es importante porque las matemáticas incorrectas son más silenciosas que el hardware defectuoso.

Durante una ejecución simulada de una bomba de 24 horas en OLLA Lab, al probar un totalizador INT de 16 bits frente a un incremento repetido de 0.4 galones, el acumulador registró 0 galones mientras que el proceso simulado movió 576 galones. Metodología: tamaño de muestra = 1 tarea de simulación controlada utilizando incrementos fijos repetidos; comparador de referencia = acumulación aritmética esperada de 0.4 galones durante 1,440 minutos; ventana de tiempo = 24 horas simuladas. Esto respalda un punto específico: el truncamiento de enteros puede producir una pérdida completa del flujo fraccionado en un caso de prueba determinista. No establece una tasa de falla universal en campo.

Aquí es donde la "sintaxis frente a la capacidad de despliegue" se vuelve real. Un peldaño (rung) puede parecer correcto, compilarse sin errores y aun así engañar a las operaciones durante semanas.

Los errores de truncamiento ocurren cuando un PLC almacena o procesa flujo fraccionario utilizando un tipo de datos entero que no puede representar decimales. Si el incremento entrante es 0.8 y el destino es un INT, la parte fraccionaria se descarta antes de convertirse en inventario.

En entornos IEC 61131-3, este comportamiento es normal para el tipo de datos. El error es asumir que el proceso lo tolerará.

Los límites de los enteros con signo de 16 bits

Un entero de 16 bits con signo (`INT`) tiene un rango finito:

- Mínimo: `-32,768` - Máximo: `32,767`

Si un totalizador acumula conteos de pulsos o volumen escalado directamente en un `INT`, aparecen rápidamente dos modos de falla:

- Desbordamiento (Overflow): una vez que el valor excede `32,767`, pasa al rango negativo o genera un error, dependiendo del comportamiento de la plataforma y el manejo de la instrucción. - Eliminación fraccionaria: cualquier valor inferior a 1.0 se trunca cuando se convierte o se escribe en un destino entero.

Para una aplicación de pulsos por unidad, el desbordamiento puede ocurrir sorprendentemente rápido. Para un totalizador incremental derivado de una señal analógica, el truncamiento puede ocurrir en cada ciclo de escaneo. Uno es dramático; el otro suele ser más difícil de notar.

Por qué los totalizadores de enteros eliminan silenciosamente el flujo real

Las matemáticas de enteros no "redondean un poco". Eliminan el resto. Si su lógica calcula:

• `Incremento_Flujo = 0.8 galones por escaneo`
• `Total_INT = Total_INT + Incremento_Flujo`

entonces la suma efectiva se convierte en:

• `Total_INT = Total_INT + 0`

El proceso movió fluido. El PLC no registró nada.

Este es un error de diseño común cuando los ingenieros escalan una señal de flujo de 4–20 mA a unidades de ingeniería, dividen por una base de tiempo y luego escriben el resultado en un acumulador entero. El peldaño puede ser sintácticamente válido, pero el totalizador ya está comprometido.

Por qué la tasa de escaneo empeora el problema

Los ciclos de escaneo rápidos aumentan la probabilidad de que cada volumen incremental sea pequeño. Eso significa que más adiciones caen por debajo de 1.0 unidad de ingeniería y se pierden si el destino se basa en enteros.

Por lo tanto, un totalizador de alta resolución requiere más que un bloque ADD. Requiere alineación entre:

• escalado de señal,
• intervalo de escaneo,
• unidades de ingeniería,
• tipo de datos del acumulador.

Un REAL de 32 bits resuelve el problema de las fracciones, pero introduce una falla diferente: pérdida de precisión en valores acumulados grandes. Una vez que el total es lo suficientemente grande, los pequeños incrementos entrantes ya no cambian el número almacenado.

Este es un comportamiento IEEE 754, no necesariamente un defecto de software. Es así como funciona el punto flotante de precisión simple.

El límite de precisión de punto flotante

La mayoría de los tipos `REAL` de PLC son valores de punto flotante de precisión simple IEEE 754. En términos de ingeniería práctica, proporcionan alrededor de 7 dígitos decimales significativos de precisión.

Eso significa que el tamaño del cambio representable más pequeño depende de la magnitud del número ya almacenado.

Ejemplos:

• Cerca de `10.0`, sumar `0.01` suele ser representable.
• Cerca de `1,000,000.0`, sumar `0.01` puede ser demasiado pequeño para cambiar el valor almacenado.
• Cerca de totales más grandes, incluso incrementos modestos pueden ser absorbidos.

El totalizador no falla porque el proceso se detuvo. Falla porque la resolución numérica del acumulador se ha vuelto más gruesa que el incremento que se está sumando.

Cómo se ve el efecto de "absorción"

El síntoma clásico es simple:

• el transmisor de flujo indica flujo activo,
• la bomba está funcionando,
• el proceso está moviendo producto físicamente,
• pero el totalizador SCADA se queda plano.

En ese punto, los operadores suelen sospechar de las comunicaciones, el retraso del historiador o la deriva de la instrumentación. A veces, el problema es mucho menos glamoroso: el acumulador se ha quedado sin granularidad útil.

Un `REAL` puede representar números grandes o incrementos pequeños lo suficientemente bien para muchas tareas. No puede hacer ambas cosas indefinidamente en un totalizador creciente sin controles de diseño.

Por qué esto importa en dosificación, servicios públicos y reportes de custodia

No todos los totalizadores son críticos financieramente, pero muchos son operacionalmente importantes. Los errores en el flujo acumulado pueden distorsionar:

• cálculos de rendimiento de lotes,
• registros de dosificación química,
• reportes de balance de agua,
• estimaciones de uso de CIP,
• conciliación de inventario de tanques,
• decisiones de mantenimiento vinculadas al rendimiento.

Este artículo no hace una afirmación de cumplimiento de transferencia de custodia. Hace una afirmación de ingeniería más estrecha: si la arquitectura del acumulador es débil, el volumen reportado puede divergir materialmente de la realidad física.

La respuesta correcta depende de lo que esté acumulando: pulsos, unidades de ingeniería escaladas o incrementos de tiempo fraccionarios. No existe una única elección de etiqueta universal, pero hay patrones defendibles.

Use DINT para acumulación de conteo completo cuando sea posible

Si la fuente es un flujo de pulsos y cada pulso representa una cantidad fija, un `DINT` suele ser más seguro que un `INT`.

Por qué:

• Un `DINT` con signo de 32 bits varía de `-2,147,483,648` a `2,147,483,647`
• Retrasa drásticamente el desbordamiento en relación con `INT`
• Preserva conteos exactos de números enteros

Para la totalización de pulsos, contar enteros como enteros suele ser el diseño más limpio.

Use REAL con cuidado para la acumulación de trabajo fraccionario

Si el incremento de la fuente es fraccionario, un `REAL` puede ser útil como acumulador de trabajo, no siempre como el único totalizador de por vida.

Buenos casos de uso:

• acumular flujo fraccionario en ventanas cortas,
• mantener un subtotal antes del desbordamiento,
• admitir totales diarios o por lotes visibles para el operador con intervalos de reinicio limitados.

Caso de uso arriesgado:

• dejar que un solo REAL de 32 bits crezca indefinidamente mientras se añaden incrementos muy pequeños.

Ahí es donde la erosión de la precisión se convierte en un problema de diseño en lugar de uno teórico.

Use LREAL si su plataforma lo admite y la aplicación lo justifica

Un `LREAL` de 64 bits ofrece mucha mayor precisión y rango que un `REAL` de 32 bits. En plataformas que lo admiten de manera confiable en las capas de controlador, HMI, historiador e interfaz, suele ser una solución más limpia para la totalización fraccionaria de larga duración.

Pero "admitirlo" debe significar soporte de extremo a extremo:

• comportamiento de la instrucción del controlador,
• transporte de etiquetas,
• compatibilidad con SCADA/HMI,
• tipo de almacenamiento del historiador,
• interpretación de la capa de reporte.

Una etiqueta de controlador matemáticamente sólida no es suficiente si el resto de la pila la reduce silenciosamente.

Un totalizador de desbordamiento en cascada separa la acumulación fraccionaria del almacenamiento a largo plazo. Este patrón suele ser más robusto que mantener un total de punto flotante que crece constantemente.

El principio de diseño es simple:

• acumular pequeños incrementos en un registro capaz de manejar fracciones,
• transferir trozos más grandes a un total entero de largo alcance,
• retener solo el resto en el registro fraccionario.

Esto reduce la posibilidad de que las pequeñas adiciones desaparezcan frente a un número de punto flotante muy grande.

Ejemplo de patrón lógico

Paso 1: Acumular el incremento de flujo bruto en un total de trabajo REAL.

`ADD Incremento_Flujo, Total_Trabajo_Real, Total_Trabajo_Real`

Paso 2: Comprobar si el total de trabajo ha alcanzado un umbral de transferencia.

`CMP Total_Trabajo_Real >= 100.0`

Paso 3: Mover la cantidad del umbral a un total maestro entero de largo alcance.

`ADD 100, Total_Maestro_DINT, Total_Maestro_DINT`

`SUB Total_Trabajo_Real, 100.0, Total_Trabajo_Real`

Por qué funciona este patrón

El beneficio de ingeniería es la estabilidad numérica.

Un diseño en cascada le brinda:

• retención de fracciones en el registro de trabajo,
• almacenamiento de largo alcance en el total maestro entero,
• reducción de la pérdida de precisión de punto flotante porque el subtotal REAL se mantiene relativamente pequeño,
• clara auditabilidad de cómo se construye el total.

También puede extender el patrón con:

• totales de lotes,
• registros de reinicio diario,
• totales retenidos no volátiles,
• comprobaciones de alarma para anomalías de desbordamiento,
• enclavamientos de secuencia que evitan actualizaciones durante estados de instrumento no válidos.

Qué significa "correcto" para un diseño de totalizador

Un totalizador no es "correcto" porque el peldaño se compile o el número en la HMI cambie. Es correcto cuando la lógica satisface una definición operativa como:

• el volumen acumulado coincide con la aritmética esperada dentro de la tolerancia definida,
• se evita o maneja explícitamente el comportamiento de desbordamiento,
• los estados de entrada no válidos no crean una acumulación falsa,
• el comportamiento de reinicio es controlado y auditable,
• la precisión a largo plazo sigue siendo adecuada para el propósito del reporte.

Ese es el estándar que importa en la puesta en marcha.

OLLA Lab es útil aquí como un entorno de validación acotado, no como un oráculo. Su valor es que los ingenieros pueden observar el comportamiento escaneo por escaneo, manipular entradas de forma segura y comparar el estado de la lógica de escalera (ladder) frente al comportamiento del proceso simulado antes de que un sistema real herede el error.

En términos prácticos, eso significa que puede probar si las matemáticas del totalizador se comportan correctamente en condiciones operativas realistas en lugar de confiar en un peldaño visualmente ordenado.

Lo que OLLA Lab hace observable

Utilizando el Editor de Lógica de Escalera, el Modo de Simulación y el Panel de Variables, un usuario puede:

• construir un totalizador utilizando lógica `INT`, `DINT`, `REAL` o de tipo mixto,
• inyectar incrementos de flujo fijos o variables,
• monitorear los valores del acumulador en tiempo real,
• comparar el comportamiento de la entrada frente a las matemáticas de salida,
• acelerar la simulación para exponer problemas de precisión a largo plazo más rápidamente.

Eso es operacionalmente útil porque muchas de estas fallas son lentas en el campo. En la simulación, se vuelven inspeccionables.

Definición operativa de "Listo para Simulación"

En este contexto, Listo para Simulación significa que un ingeniero puede:

• probar el comportamiento de control previsto,
• observar el efecto de cada entrada y transición de estado,
• diagnosticar fallas numéricas y de secuenciación,
• endurecer la lógica contra el comportamiento realista del proceso,
• documentar por qué la lógica revisada es más confiable antes de que llegue a un proceso real.

No significa competencia en el sitio, certificación o preparación automática para la puesta en marcha sin supervisión. La simulación es un ensayo, no una absolución legal.

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

Una secuencia de validación útil en OLLA Lab sería:

1. Crear una fuente de flujo simulada con un comportamiento incremental conocido.
2. Construir un totalizador usando `INT` y otro usando `REAL`.
3. Ejecutar ambos bajo incrementos idénticos.
4. Observar el truncamiento en la ruta de enteros.
5. Aumentar el acumulador REAL hasta que los pequeños incrementos dejen de cambiar el total.
6. Reemplazar el diseño con un desbordamiento en cascada o una estrategia de mayor precisión.
7. Volver a ejecutar el escenario y comparar los resultados.

Aquí es donde OLLA Lab se vuelve operacionalmente útil. Proporciona visibilidad sobre una clase de fallas que a menudo sobreviven a la revisión de escritorio y solo se vuelven obvias después de que la conciliación de inventario se vuelve difícil.

Una captura de pantalla de un peldaño no es evidencia de ingeniería. Solo es ilustrativa a menos que esté vinculada al comportamiento, la inyección de fallas y el historial de revisiones.

Si desea demostrar un trabajo de control serio, utilice un paquete de evidencia compacto con seis partes:

Documente la falla exacta introducida: truncamiento de enteros, desbordamiento, absorción de punto flotante, escalado incorrecto o condición de carrera de reinicio.

Explique el cambio de diseño: migración a `DINT`, adopción de `LREAL`, desbordamiento en cascada, lógica de transferencia de umbral o acumulación controlada.

1. Descripción del sistema Defina el contexto del proceso, la fuente de la señal, las unidades, los supuestos de escaneo y el objetivo de totalización.
2. Definición operativa de "correcto" Establezca el comportamiento aritmético esperado, la tolerancia, las reglas de reinicio y el manejo de estados no válidos.
3. Lógica de escalera y estado del equipo simulado Muestre la lógica y el comportamiento del proceso simulado correspondiente juntos, no de forma aislada.
4. El caso de falla inyectado
5. La revisión realizada
6. Lecciones aprendidas Capture lo que probó la prueba, qué supuestos fallaron y qué debería convertirse en un estándar de diseño.

Esa estructura está más cerca de la evidencia de puesta en marcha que de una simple instantánea de portafolio.

El comportamiento subyacente del tipo de datos se basa en principios estándar de programación industrial y computación numérica, no en el folclore de la plataforma.

Los anclajes relevantes incluyen:

• IEC 61131-3 para lenguajes de programación PLC y convenciones de tipos de datos utilizados en sistemas de control industrial.
• IEEE 754 para el comportamiento de la aritmética de punto flotante, incluidos los límites de precisión finita y representacionales.
• IEC 61508 para el principio más amplio de que los errores de diseño sistemáticos en sistemas programables deben identificarse y controlarse mediante procesos de ingeniería disciplinados.
• Literatura sobre simulación y gemelos digitales en automatización industrial, que generalmente respalda el uso de entornos modelados para validar el comportamiento del control antes de la implementación, especialmente cuando las pruebas en vivo son costosas o riesgosas.

Este artículo no afirma que un simulador por sí solo establezca cumplimiento, integridad de seguridad o aceptación en campo. Hace una afirmación más estrecha: la simulación mejora la observabilidad de fallas de lógica determinista que, de otro modo, son costosas de detectar tarde.

Los errores en los totalizadores de flujo suelen ser causados por malas elecciones de tipos de datos. Las etiquetas `INT` eliminan fracciones, las etiquetas `REAL` pueden llegar a perder pequeños incrementos frente a totales grandes, y ambas fallas pueden permanecer invisibles el tiempo suficiente para dañar los reportes, la confianza en el inventario y la confianza del operador.

La solución de ingeniería es sencilla en principio: utilice la arquitectura numérica correcta para la señal, defina qué significa "correcto" antes de la puesta en marcha y valide el comportamiento bajo carga. Esa es la diferencia entre un programa de escalera que se ejecuta y una estrategia de control que sigue siendo confiable en la producción.

- IEEE Std 754-2019 — Aritmética de punto flotante - IEC 61131-3 — Lenguajes de programación PLC - IEC 61508 — Visión general de seguridad funcional - Kritzinger et al. (2018), Gemelo digital en la fabricación (IFAC) - Tao et al. (2019), Gemelo digital en la industria (IEEE TII)