¿Qué es el registro de datos a bordo en la RTU?
Cuando un sitio remoto pierde su enlace con el mundo exterior, el proceso que monitorea no se detiene amablemente; los tanques siguen llenándose, las bombas siguen corriendo y las presiones siguen cambiando, vea alguien o no. El registro de datos a bordo es cómo una RTU o gateway de borde asegura que esas lecturas sobrevivan el apagón: las marca con hora y las guarda localmente en memoria que no olvida cuando parpadea la energía, y cuando el enlace regresa envía todo el tramo faltante aguas arriba para llenar el hueco. Esta guía explica cómo funciona el registro a bordo, en qué se diferencia de rellenar huecos del lado del servidor, y cómo forma la fuente de la que dependen el almacenar-y-reenviar y el dimensionado del buffer.
Registro de datos a bordo en una línea: El registro de datos a bordo es la práctica de que una RTU o gateway de borde registre lecturas con marca de tiempo en su propia memoria no volátil local, independiente de si el enlace aguas arriba está disponible. Cuando cae la conectividad, el dispositivo sigue registrando, y cuando el enlace regresa reproduce las lecturas guardadas para reponer el periodo que no pudo transmitir. Esto difiere del relleno del historiador del lado del servidor, que reconstruye o vuelve a solicitar los datos faltantes en el sistema central; el registro a bordo captura los datos en la fuente en primer lugar, y es el origen que da sentido al almacenar-y-reenviar y al dimensionado del buffer.
Marca de tiempo y almacenamiento no volátil en el borde
El rasgo definitorio del registro de datos a bordo es que cada lectura se sella con la hora en que se tomó de verdad, en el dispositivo, en el momento de la medición, en lugar de la hora en que llega a un servidor. Esto importa porque un dato que llega tarde durante un relleno se atribuiría, de otro modo, al momento de la llegada, colapsando una hora de eventos reales en un solo instante. Al cargar su propia marca de tiempo desde el nacimiento, cada lectura mantiene su verdadera posición en la línea de tiempo sin importar cuánto esperó en el buffer, así una tendencia reconstruida tras un corte muestra lo que en realidad pasó cuando pasó.
El almacenamiento debe ser no volátil, es decir, retener su contenido al perder energía, porque las mismas condiciones que rompen un enlace de comunicaciones, tormentas, caídas de energía, fallas de equipo, a menudo coinciden con interrupciones de energía en el sitio. La memoria volátil se vaciaría en cada bajón de tensión, frustrando el propósito justo cuando más se necesitaba. El registro a bordo por tanto escribe en memoria flash o similar persistente, para que una lectura capturada antes de un corte siga ahí después de que el dispositivo se reinicie, lista para enviarse una vez que se restauren tanto la energía como las comunicaciones.
Como el dispositivo registra en el borde, también puede desacoplar qué tan rápido captura los datos de qué tan seguido los envía al final. Podría muestrear y registrar con frecuencia para buena resolución mientras transmite mucho menos seguido, de modo que el registro histórico sea denso aunque el flujo en vivo sea escaso. Esta captura local es lo que permite que un sitio conserve un histórico detallado durante periodos en los que el ancho de banda o la conectividad nunca habrían permitido transmitir esos datos en tiempo real.
Registro a bordo frente a relleno del historiador
Es fácil confundir el registro de datos a bordo con el relleno del historiador porque ambos terminan llenando huecos en el registro central, pero operan en extremos opuestos de la cadena y resuelven mitades distintas del problema. El registro a bordo es una capacidad del lado de la fuente: captura y preserva los datos en el dispositivo de campo en el instante en que se miden, así la información existe aun mientras no puede enviarse. El relleno del historiador es un proceso del lado del servidor que inserta o repara datos en el historiador central, a menudo solicitando lo que el dispositivo de campo logró conservar. El relleno no tiene nada que insertar a menos que algo en la fuente haya conservado los datos en primer lugar.
Esta distinción determina qué es recuperable de verdad tras un corte. Si la RTU registró a bordo, el historiador puede rellenarse con las lecturas verdaderas y con marca de tiempo para todo el hueco, y el registro queda completo. Si la RTU no registró, entonces ninguna astucia del lado del servidor puede recuperar mediciones que nunca se almacenaron en ninguna parte; el historiador solo puede interpolar o dejar un hueco, porque los valores subyacentes simplemente ya no existen. La interpolación del servidor es una adivinanza entre dos puntos conocidos, mientras que el registro a bordo entrega los valores reales que ocurrieron en medio.
En la práctica los dos se diseñan para trabajar juntos en lugar de competir. El registro a bordo de la RTU es la fuente autoritativa de la verdad sobre lo que pasó en el sitio, y el mecanismo de relleno del historiador es el medio por el que esa verdad se jala al registro central una vez que el enlace regresa. Entender cuál capa es responsable de la captura y cuál de la reconstrucción evita el error común de suponer que un historiador central puede llenar cualquier hueco, cuando en realidad solo puede llenar los huecos que un dispositivo de campo se tomó la molestia de registrar.
Alimentar el almacenar-y-reenviar y el dimensionado del buffer
El registro de datos a bordo es el motor detrás del almacenar-y-reenviar, el patrón en el que un dispositivo guarda lecturas durante un corte y las reenvía cuando puede. El almacenar es exactamente el registro a bordo; el reenviar es la reproducción que lo vacía aguas arriba cuando la conectividad regresa. Sin el registro no habría nada que reenviar, así que el registro a bordo no es una función separada del almacenar-y-reenviar sino su cimiento. Cuando alguien dice que un sitio atraviesa un corte y lo repone después, el registro a bordo es lo que lo hizo posible.
La restricción práctica es el tamaño del buffer, porque la memoria no volátil es finita y un corte largo genera muchas lecturas. El buffer debe contener suficientes datos registrados para cubrir el corte más largo que el sitio probablemente vea, y si se llena antes de que el enlace regrese, el dispositivo enfrenta una elección entre sobrescribir los datos más viejos o rechazar escrituras nuevas, cualquiera de las cuales pierde información. Dimensionar el buffer se reduce entonces a la tasa de registro multiplicada por la duración del corte de peor caso, y por eso un sitio que muestrea densamente o está en mala cobertura necesita más memoria que un sitio que registra escasamente en un enlace confiable.
En una plataforma SCADA de nube, el registro a bordo es lo que convierte un corte en un retraso en lugar de una pérdida, y la plataforma es donde esa recuperación se hace visible. Cuando un sitio reconecta y transmite su rezago, Merobix ingiere las lecturas con marca de tiempo para que el hueco se llene con histórico real en lugar de una línea interpolada, y los operadores pueden ver con claridad que el registro está completo. Ese comportamiento de extremo a extremo, capturar en el borde, conservar en memoria no volátil, reproducir al reconectar y reconciliar en la nube, es lo que permite a los sitios remotos entregar un registro sin cortes a pesar de los enlaces poco confiables en los que viven.
Preguntas frecuentes
¿Cuál es la diferencia entre el registro de datos a bordo y el almacenar-y-reenviar?
Son dos partes del mismo comportamiento en lugar de funciones separadas. El registro de datos a bordo es el almacenar: la RTU registra lecturas con marca de tiempo en memoria no volátil conforme ocurren. El almacenar-y-reenviar agrega el reenviar: cuando el enlace regresa, el dispositivo reproduce esas lecturas registradas aguas arriba para reponer el hueco. El registro a bordo es el cimiento, porque sin un registro local no habría nada que el almacenar-y-reenviar enviara una vez restaurada la conectividad.
¿Por qué los registros a bordo deben marcarse con hora en el dispositivo?
Porque las lecturas reproducidas tras un corte llegan mucho después de haberse tomado, y sin sus marcas de tiempo originales se atribuirían al momento en que finalmente alcanzaron el servidor. Sellar cada lectura con la hora real de la medición en el dispositivo preserva su posición correcta en la línea de tiempo sin importar cuánto esperó en el buffer. Esto es lo que permite que una tendencia reconstruida tras un corte muestre los eventos en las horas en que de verdad ocurrieron en lugar de amontonados en el instante de la reconexión.
¿Puede un historiador de servidor recuperar datos si la RTU no los registró?
No. El relleno del historiador del lado del servidor solo puede insertar datos que algún dispositivo de campo haya capturado y conservado; no puede recuperar mediciones que nunca se almacenaron en ninguna parte. Si la RTU no tenía registro a bordo, el historiador en el mejor de los casos puede interpolar una adivinanza entre el último punto conocido antes del corte y el primero después, lo que no es lo mismo que los valores reales. Por eso el registro a bordo en la fuente es esencial para un registro verdaderamente completo.
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.