Si los sensores de metano, temperatura y humedad tienen suficiente precisión, ¿se pueden analizar conjuntamente sus tres series de datos sin más? No necesariamente. Si el valor de metano representa el aire de las 10:00, pero la temperatura corresponde a las 10:03 y la humedad al estado de las 9:58, los tres números agrupados en una misma fila no describen el mismo fenómeno. Una diferencia de unos minutos entre sensores puede parecer pequeña, pero alrededor de sucesos rápidos, como la alimentación, la activación de un ventilador o la apertura de una puerta, puede invertir la causa y el efecto.
La sincronización temporal no consiste simplemente en hacer coincidir las horas que aparecen en pantalla. Consiste en distinguir la hora en que ocurrió el fenómeno, la hora en que el sensor generó el valor, la hora en que lo recibió el gateway, la hora en que lo almacenó el servidor, y la hora en que se realizaron la corrección y la agregación, además de gestionar sus relaciones y su incertidumbre. Sin esta distinción, datos normales que llegan tarde pueden convertirse en valores atípicos y una interrupción de las comunicaciones puede interpretarse como una variación real de la concentración.
Cuatro formas en que un error del reloj altera el análisis
La primera es la distorsión de la correlación. Si la concentración de metano disminuyó durante los 5 minutos posteriores a la activación de un ventilador, pero el reloj del sensor de metano está adelantado 7 minutos, el gráfico mostrará que la concentración bajó primero y el ventilador se encendió después. El modelo analítico puede subestimar el efecto de la ventilación o incluso estimarlo en sentido contrario.
La segunda es la pérdida del máximo y de la ventana del evento. Si se define como ventana de análisis el periodo de 30 minutos posterior a la alimentación, pero el reloj está desfasado 10 minutos, en algunos sensores el intervalo de aumento quedará fuera de esa ventana. Aunque los promedios diarios de los sensores sean similares, serán diferentes la causa del pico y el tiempo de respuesta. La tercera es una interpolación incorrecta. Si se consideran simultáneos valores obtenidos en momentos distintos y se interpolan linealmente, se crean combinaciones de metano y humedad que nunca existieron.
La cuarta son los duplicados y los errores de orden. Si, cuando un dispositivo retransmite datos obtenidos sin conexión, solo se conserva la hora de recepción, un valor observado ayer aparecerá como un cambio brusco de hoy. Si el reloj se reinicia después de reiniciar el dispositivo, pueden repetirse marcas de tiempo del pasado; y si se aplica incorrectamente el horario de verano o una conversión de hora local, puede duplicarse o desaparecer una hora. Aunque se opere únicamente en granjas de Corea, el servidor, las herramientas de análisis y las organizaciones colaboradoras pueden utilizar husos horarios distintos, por lo que resulta más seguro almacenar con base UTC.
La hora de observación y la de recepción no son intercambiables
OGC SensorThings API distingue en una Observation el phenomenonTime, cuando ocurrió el fenómeno, y el resultTime, cuando se generó el resultado. Un sistema de campo puede añadir además la hora de recepción y la de ingesta. La ventaja de esta estructura es que permite separar los retrasos de red de los problemas del reloj del sensor.
Por ejemplo, si la hora de observación es 10:00, la de recepción en el gateway es 10:00:03 y la de ingesta en la nube es 12:15, es muy probable que el sensor y la comunicación local funcionaran con normalidad y que los datos se retransmitieran tras una interrupción de la red externa. Por el contrario, si varios dispositivos llegan simultáneamente al gateway, pero la hora de observación de un sensor se mantiene adelantada 4 minutos, puede sospecharse una deriva del reloj del dispositivo.
En dispositivos de prestaciones limitadas que no tienen reloj, el gateway puede asignar la hora de observación. En ese caso, los datos deben indicar timestamp_source=gateway y debe conocerse el retraso máximo de la transmisión del dispositivo al gateway. Copiar sin dejar rastro la hora de recepción del servidor como hora de observación puede parecer inofensivo durante el funcionamiento normal, pero altera considerablemente los resultados el día en que se produce un retraso de comunicaciones.
Principio de la sincronización temporal: considerar juntos la referencia, el error y el retraso
IETF RFC 5905 especifica la arquitectura y los algoritmos de NTPv4 para sincronizar los relojes de sistema de servidores de tiempo y clientes distribuidos. Sin embargo, el mero hecho de utilizar NTP no garantiza que todos los datos estén correctamente alineados. Hay que comprobar cuándo se sincronizó por última vez el dispositivo, cuál es el retraso de red hasta el servidor de referencia y cómo conserva la hora durante los reinicios y las interrupciones de la red externa.
Al gestionar la calidad temporal como un indicador operativo, conviene observar conjuntamente offset, drift y uncertainty. El offset es la diferencia entre la hora de referencia y la hora actual del dispositivo; el drift es la velocidad a la que aumenta el error con el tiempo; y la uncertainty expresa dentro de qué intervalo alrededor del valor mostrado puede encontrarse la hora real de observación. Si el dispositivo permanece sin conexión durante 6 horas y su reloj puede retrasarse 1 segundo por hora, la incertidumbre temporal se acumula hasta el momento de la recuperación.
La precisión necesaria se calcula a partir del objetivo del análisis. En datos destinados a observar tendencias mensuales mediante medias de 10 minutos, una diferencia de unos segundos puede tener escaso efecto en la conclusión. Si se analiza una respuesta de 30 segundos tras el control de un ventilador o se comparan los tiempos de llegada de una pluma a sensores distintos, un error de 1 minuto resulta crítico. No es necesario exigir precisión de nanosegundos a todos los dispositivos, pero tampoco tiene sentido un estado de sincronización completada que no especifique el error permitido.
Escenario de campo: por qué la humedad parecía causar el aumento del metano
Supongamos que en verano se detecta en un establo un patrón según el cual, cada vez que aumenta la humedad, la concentración de metano sube 3 minutos después. El equipo de análisis interpreta que el cambio de humedad influyó en la respuesta del sensor o en la actividad de los animales. Sin embargo, una inspección revela que el sensor de humedad utilizaba la hora del gateway, mientras que el de metano empleaba su reloj interno, que estaba adelantado 5 minutos respecto de la hora real. Tras corregirlo, el aumento del metano queda mejor alineado con la alimentación y la parada del ventilador que lo precedieron que con la humedad.
En este caso, los valores de los sensores no eran incorrectos; lo incorrecto era el orden de los acontecimientos. Aunque el coeficiente de correlación y el modelo de efectos retardados anteriores a la corrección temporal parezcan estadísticamente plausibles, pueden llevar a una conclusión equivocada. La sincronización temporal no es un aspecto menor del preprocesamiento analítico, sino una condición previa para interpretar la causalidad.
Un método de verificación consiste en crear un evento de referencia. Se registra un suceso controlado que puedan detectar simultáneamente varios dispositivos, o un cambio en el estado de un ventilador, y se comparan las marcas de tiempo. Siempre que sea posible, se contrastan con un reloj de referencia independiente o con el registro del gateway. No basta con comparar las horas de la base de datos: hay que seguir el mismo acontecimiento en la pantalla del dispositivo, los paquetes del gateway y los registros del servidor para localizar el tramo en el que se produjo el retraso.
Cómo diseñar una canalización de análisis sincronizada
En los datos brutos se conserva sin cambios la hora comunicada por el dispositivo. En campos separados se guardan la hora convertida a UTC, la hora de observación corregida, la magnitud de la corrección, el huso horario, el reloj de referencia, la última hora de sincronización y el indicador de calidad. Si se sobrescribe la marca de tiempo original, no será posible revisar posteriormente las reglas de sincronización.
A continuación se establecen las reglas de remuestreo. Si el metano se mide cada 10 segundos, la temperatura cada 1 minuto y la humedad cada 5 minutos, no deben fusionarse simplemente las filas: hay que utilizar una ventana temporal común y una función de agregación. La elección entre media, mediana, conservación del último valor e integración debe responder al significado físico. Se define la diferencia temporal máxima admisible para buscar el valor más próximo y se consideran ausentes los valores que queden fuera de ese intervalo. Es preferible revelar un dato ausente que forzar la imputación de un valor obtenido en un momento lejano.
También hay que distinguir el tiempo de respuesta del sensor del error del reloj. Aunque reciban el mismo aire a la vez, las respuestas del metano y la humedad pueden retrasarse debido al filtro protector, la longitud del tubo de muestreo, el caudal de la bomba y el principio del sensor. Este retraso no desaparece con la sincronización temporal, por lo que es necesario determinar mediante ensayos en paralelo las características de respuesta de cada dispositivo e incorporarlas al análisis.
La versión de las reglas de corrección temporal también debe conservarse junto con la fórmula de cálculo. Por ejemplo, si solo se aplicó una corrección lineal de la deriva durante un periodo concreto, hay que registrar las horas de inicio y fin, el evento de referencia, el coeficiente de corrección y la persona que la aprobó. Aunque más adelante se encuentren mejores datos del reloj de referencia, no debe sobrescribirse la información bruta; hay que crear una nueva versión de la corrección para poder reproducir tanto el informe anterior como el resultado modificado. El informe de calidad también debe registrar cuánto cambiaron los principales indicadores antes y después de la corrección.
Las directrices de seguridad de OT del NIST exigen considerar conjuntamente el rendimiento, la fiabilidad y la seguridad en los sistemas que detectan y controlan el entorno físico. Si un servidor de tiempo o un gateway distribuye horas incorrectas a causa de un ataque o un error, también pueden resultar dañados el orden de las alarmas y los registros de auditoría. Las fuentes de tiempo autorizadas, el control de acceso, los registros de cambios de hora, la detección de saltos anómalos y una estrategia de conservación local deben formar parte de los criterios operativos.
Lista de comprobación para la puesta en práctica
Defina para cada análisis el error temporal máximo admisible y la frecuencia de muestreo necesaria.
Almacene en campos distintos la hora de observación, la de generación del resultado, la de recepción y la de ingesta.
Conserve la hora original, la conversión a UTC, el valor corregido y el motivo de la corrección.
Recopile para cada dispositivo la fuente de tiempo, la última sincronización, el offset, el drift y la incertidumbre.
Pruebe el comportamiento temporal durante reinicios, interrupciones de la red externa y sustituciones del gateway.
Predefina la ventana temporal común, la función de agregación y la tolerancia de emparejamiento con el valor más próximo.
Ordene los datos retransmitidos por la hora de observación original, no por la hora de recepción.
Separe mediante ensayos en paralelo el tiempo de respuesta del sensor y el error del reloj.
Vincule también a la misma referencia temporal los registros de eventos como la activación de ventiladores, la alimentación y la apertura de puertas.
Marque en el análisis de reducción los intervalos cuya calidad temporal supere el límite y evalúe su sensibilidad.
Conclusión
La sincronización temporal de los datos de metano, temperatura y humedad no es una labor de ordenación destinada a producir gráficos atractivos. Es el sistema de coordenadas del análisis que permite determinar qué ocurrió primero y cómo respondieron los sensores y el establo a los cambios ambientales. Aunque los valores sean exactos, si la hora es incorrecta pueden cambiar la correlación, los picos, los tiempos de respuesta y el efecto de reducción.
Un buen sistema no confía incondicionalmente en todas las marcas de tiempo. Registra el origen y el error de la hora, separa la observación de la transmisión y aplica tolerancias adecuadas al objetivo del análisis. El primer paso es comparar a qué hora registran un mismo acontecimiento los sensores de metano, temperatura y humedad y el evento del ventilador. Solo cuando esa diferencia puede medirse y gestionarse, las cifras de varios sensores empiezan a describir un único lugar.