Glosario de Automatización • Tiempo delta (dt)

¿Qué es el tiempo delta (dt) en los cálculos de SCADA?

Ingeniería Merobix • • 8 min de lectura

Casi todo cálculo que involucra cómo cambia un valor con el tiempo, sea que acumule un total, mida una tasa o tome una derivada, contiene un multiplicador oculto: la cantidad de tiempo que de verdad pasó entre dos ejecuciones. Ese intervalo es el tiempo delta, por lo general escrito dt, y tratarlo como una constante fija cuando en realidad es variable es una de las fuentes más silenciosas de deriva en el código de control. Esta guía explica por qué dt pertenece a estos cálculos, cómo capturar el tiempo transcurrido real en lugar de suponerlo, y los errores de acumulación que aparecen cuando el barrido de un controlador se acelera y se ralentiza bajo carga.

Volver al glosario

Tiempo delta (dt) en una línea: El tiempo delta, o dt, es el tiempo transcurrido real entre dos ejecuciones de un pedazo de lógica, y es el término que convierte una tasa en una cantidad o una cantidad en una tasa. Cualquier integral (tasa por dt) o derivada (cambio entre dt) debe usar el dt medido en lugar de un barrido fijo supuesto, porque el barrido de un PLC varía con la carga; usar un barrido nominal constante cuando el real difiere hace que los totales y las tasas deriven en proporción a esa diferencia.

Por qué toda tasa e integral necesita dt

Las tasas y los totales son dos lados de la misma relación: una tasa es una cantidad dividida entre un tiempo, y una cantidad es una tasa multiplicada por un tiempo. Ese tiempo es dt. Para acumular flujo en un total, el controlador multiplica la tasa de flujo actual por el tiempo desde que agregó por última vez, para que las unidades salgan: barriles por minuto por minutos da barriles. Para calcular una tasa de cambio de un nivel que sube, divide el cambio de nivel entre el tiempo en que ese cambio ocurrió, para que pies entre minutos den pies por minuto. En ambas direcciones el tiempo transcurrido no es decoración opcional; es el término que hace la aritmética dimensionalmente correcta.

La tentación es hornear dt como una constante, porque un controlador se configura para correr una tarea en un periodo nominal y es fácil escribir el código como si ese periodo fuera exactamente lo que transcurre. Si la tarea debe correr cada cien milisegundos, un programador puede simplemente multiplicar por una décima de segundo cada barrido. Eso funciona sólo en la medida en que el intervalo real iguale al nominal, y en un controlador real no siempre lo hace, porque el barrido se ve afectado por todo lo demás que el CPU está haciendo.

El modelo mental correcto es que el barrido nominal es un objetivo, no una garantía. El patrón seguro es medir cuánto tiempo pasó de verdad y usar ese valor medido, para que el cálculo se mantenga correcto sin importar si el barrido corrió a tiempo, corrió largo porque la carga de lógica se disparó, o se retrasó por las comunicaciones. Cuando dt se mide en lugar de suponerse, un totalizador acumula la cantidad verdadera y una tasa refleja la velocidad real de cambio, independiente de qué tan estable resulte ser el barrido.

Capturar el tiempo transcurrido real

Hay dos formas comunes de obtener un dt real. La primera es un reloj de marcha libre o un temporizador de alta resolución que el controlador expone como un valor que cuenta de continuo. En cada ejecución, el código lee el reloj actual, resta el valor del reloj que guardó la vez pasada, y la diferencia es dt; luego guarda el valor actual para la próxima vez. La sutileza es manejar el contador que da la vuelta cuando alcanza su máximo y regresa a cero, lo cual la aritmética sin signo por lo general resuelve limpiamente si el ancho del contador y la resta se tratan de forma consistente, pero que producirá un dt salvaje si se ignora.

La segunda forma es una diferencia de estampas de tiempo. Si cada muestra lleva una estampa de tiempo, sea estampada por el PLC, la RTU o un dispositivo, dt es simplemente la diferencia entre la estampa de tiempo de esta muestra y la de la anterior. Este es el enfoque natural cuando el cálculo corre sobre datos que llegan con tiempos adjuntos, como puntos historizados o telemetría, en lugar de sobre un controlador ejecutando una tarea periódica. Tiene la ventaja de que refleja el tiempo que la medición de verdad representa, no el tiempo en que el código resultó correr, lo que importa cuando los datos se ponen en búfer o se retrasan en tránsito.

Cualquiera que sea la fuente usada, unas cuantas guardas lo mantienen honesto. Un dt de cero, que ocurre si el cálculo corre dos veces dentro de un tic de reloj o sobre dos muestras con la misma estampa de tiempo, no debe usarse como divisor, así que el código de derivada tiene que protegerse contra ello. Un dt implausiblemente grande, de un atoramiento largo, un reinicio o un hueco en la telemetría, por lo general debe acotarse o la muestra saltarse en lugar de permitirle volcar un trozo enorme en un totalizador o producir una tasa calculada enorme. Y la primera ejecución tras el arranque no tiene valor previo que restar, así que por lo general siembra el valor guardado y no produce salida hasta la segunda pasada.

Errores de acumulación y dt a través de una cadena SCADA

El modo de falla de suponer un barrido constante es una deriva lenta y sistemática en lugar de una falla obvia. Si el código multiplica por cien milisegundos nominales cada barrido pero el controlador bajo carga en realidad promedia un poco más entre ejecuciones, un totalizador acumula ligeramente muy poco cada vez, y a lo largo de un turno o un mes esos pequeños faltantes suman un total que está consistentemente fuera en una sola dirección. Como cada barrido individual se ve razonable y el total aún trepa con sensatez, el error se esconde a plena vista, justo como una lectura mal escalada que tiende correctamente pero reporta el número equivocado.

Las derivadas sufren el problema espejo. Una tasa de cambio calculada dividiendo entre un dt supuesto que es más corto que el intervalo real lee alto, y una que usa un dt más largo lee bajo, así que una alarma de tasa de cambio puede dispararse temprano o tarde sin razón visible en la señal cruda. Como las derivadas ya amplifican el ruido, alimentarlas con un dt equivocado agrava un cálculo ya delicado. Usar el intervalo medido mantiene la tasa calculada anclada al tiempo real sin importar cómo vague el barrido.

En una arquitectura SCADA de nube como Merobix, la disciplina de dt vive en dos niveles. En el borde, el PLC, la RTU o el computador de flujo que corre el totalizador primario y la lógica de tasa debe usar su propio tiempo transcurrido medido para que los números que reporta ya estén correctos. En la plataforma, cualquier cálculo hecho sobre datos historizados o transmitidos - un tag calculado que deriva una tasa, o un total reconstruido a partir de puntos de tasa almacenados - debe usar la diferencia entre las estampas de tiempo reales de las muestras en lugar de un intervalo de sondeo nominal, porque la telemetría es en búfer, de almacenar y reenviar e irregular por naturaleza. Llevar estampas de tiempo exactas de extremo a extremo es lo que permite a una tasa o una integral calculada después embonar con la realidad física que describe, y es por lo que la integridad de las estampas de tiempo y la corrección de dt son en realidad la misma preocupación.

Preguntas frecuentes

¿Por qué no puedo simplemente usar el tiempo de barrido como constante?

Porque el intervalo real entre ejecuciones varía con la carga del CPU, las comunicaciones y las interrupciones, así que el tiempo transcurrido real se aleja del barrido nominal. Multiplicar por una constante fija hace que un totalizador acumule ligeramente de más o de menos cada barrido, y esos pequeños errores se apilan en una sola dirección a lo largo de horas y días. Medir el tiempo transcurrido real en cada ejecución mantiene los totales y las tasas correctos sin importar cómo vague el barrido.

¿Cómo se captura dt en un PLC?

Lea un reloj de marcha libre o un temporizador de alta resolución en cada ejecución, reste el valor que guardó la vez pasada y use la diferencia como dt, luego guarde el valor actual para la próxima vez. De forma alterna, si las muestras llevan estampas de tiempo, tome la diferencia entre estampas consecutivas. En cualquier caso, guárdese contra un dt de cero antes de dividir, acote o salte los huecos implausiblemente grandes, y siembre el valor almacenado en la primera pasada para que la primera salida no sea basura.

¿Cuál es la diferencia entre dt y el tiempo de barrido?

El tiempo de barrido es el periodo nominal al que se configura correr una tarea, un objetivo al que el controlador apunta. dt es el tiempo transcurrido real que pasó entre dos ejecuciones reales, que puede ser más largo o más corto que el barrido nominal según la carga. Los cálculos deben usar el dt medido, no el tiempo de barrido configurado, porque es el intervalo real lo que hace a una tasa o una integral dimensional y numéricamente correcta.

Más en Fundamentos de SCADA
Verificar sincronización de tiempo en la pila SCADA  •  Tiempo de ida y vuelta (RTT)  •  Fuente de marca de tiempo  •  Sincronización de tiempo NTP  •  Segundo intercalar  •  Todo en Fundamentos de SCADA →
Capacitación SCADA gratuita para operadores
Merobix University - 70 lecciones en video y 261 preguntas de examen, del primer inicio de sesión a los reportes de cumplimiento (contenido en inglés). Sin llamada de ventas.
Comenzar gratis →