Una lectura de un sensor puede tener hasta tres horas: cuando se midió el valor, cuando el Gateway lo recogió y cuando el sistema receptor lo recibió. En condiciones normales apenas hay unos segundos de diferencia y parece que da igual cuál se almacene. Tras una interrupción de la red, pueden separarse por horas: un sistema que guardó la hora equivocada atribuye la carga de ayer al intervalo de hoy.
Esta guía forma parte de la serie sobre calidad y transmisión de datos.
Tres horas distintas
| Hora | La establece | Para qué sirve |
|---|---|---|
| Hora de origen | El dispositivo o contador, cuando mide el valor o este cambia | Análisis, intervalos de energía y secuencia de eventos |
| Hora de recogida | El Gateway, cuando lee o recibe el valor | Estado de las consultas; hora de referencia si el dispositivo no proporciona la de origen |
| Hora de llegada | La plataforma receptora | Estado de la conexión; retraso de los datos |
Los protocolos difieren en la información temporal que transportan:
- OPC UA DataValue puede incluir un SourceTimestamp y un ServerTimestamp, como establece la parte 4 de la especificación. La marca temporal de origen puede faltar si la fuente no la proporciona.
- Los tipos de IEC 60870-5 con marca temporal llevan la hora de la estación remota; los demás no llevan ninguna.
- Modbus no transporta una marca temporal. La hora de recogida es la mejor disponible.
- MQTT no transporta la hora de medición. Inclúyala en la carga útil.
Registre para cada punto qué hora lleva y de dónde procede.
Reglas que evitan la mayoría de los errores
- Use UTC o un desfase horario explícito. RFC 3339 define formatos como
2026-09-23T14:05:00Zy2026-09-23T15:05:00+01:00. La hora local sin desfase resulta ambigua cuando los relojes se atrasan en otoño: en España, la hora de 02:00 a 03:00 ocurre dos veces. - Etiquete los intervalos de forma coherente. Indique si la marca de una lectura de 15 minutos corresponde al inicio o al final del intervalo y aplique la misma regla en todos los sistemas. Una discrepancia desplaza cada valor un intervalo y sitúa el pico de demanda en el cuarto de hora equivocado.
- Sincronice los relojes. Todo dispositivo que establece la hora de origen necesita una fuente horaria fiable. Registre cuál utiliza y genere una alarma si su reloj se desvía o pierde la sincronización.
- Nunca sustituya la hora de origen por la de llegada. Si una lectura no lleva la hora de origen, conserve la hora de recogida e identifíquela como tal.
Datos que llegan tarde tras una interrupción
Cuando se restablece la conexión, un Gateway que ha almacenado lecturas las envía con retraso. El receptor debe colocar cada una según su hora de origen:
La guía de almacenamiento y envío diferido explica cuánto tarda en vaciarse esa cola. Compruebe qué hace la plataforma receptora con los datos tardíos: algunas los aceptan solo dentro de un plazo; otras recalculan totales y alarmas ya procesados; otras los ignoran. Acuerde el comportamiento y pruébelo con una interrupción programada.
Duplicados
Los reintentos pueden hacer que una misma lectura llegue dos veces: una antes de que se detecte un fallo y otra desde la cola de reintentos. Asigne una identidad a cada lectura, por ejemplo el identificador del punto junto con su hora de origen, para que el receptor conserve una sola copia. Sin esa identidad, un intervalo reenviado duplica la energía contabilizada. La guía de QoS de MQTT explica por qué la entrega «al menos una vez» produce duplicados.
Un valor que no ha cambiado
Un valor constante no es necesariamente un valor obsoleto, y una hora de origen antigua no siempre significa que la fuente se haya detenido. Un servidor OPC UA puede conservar el SourceTimestamp de un valor sin cambios y, al mismo tiempo, confirmar el valor con un ServerTimestamp nuevo. Evalúe la vigencia del dato según la última confirmación del valor y de su estado de calidad por el servidor, junto con las horas de origen y llegada. El servidor puede confirmar un valor sin cambios aunque no reciba un mensaje nuevo de la fuente. La guía de datos obsoletos explica cómo decidir cuándo un punto está obsoleto.
Definir las marcas temporales de un proyecto
Para cada punto, registre:
- qué hora lleva la lectura y qué componente la establece;
- la zona horaria y la fuente de sincronización de ese componente;
- en los valores agregados por intervalos, si la etiqueta indica el inicio o el final;
- la identidad utilizada para eliminar duplicados;
- cómo gestiona el receptor las lecturas tardías y cuál es el retraso máximo aceptado.
Marcas temporales con Edge
Edge en el Gateway ZGW-20 asigna una marca temporal a cada lectura y la envía con ella a cada destino. Si un destino remoto deja de estar disponible y Edge reenvía las lecturas más adelante, estas mantienen sus marcas temporales originales. En los protocolos consultados, como Modbus, BACnet y OPC UA, la marca corresponde a la hora de lectura. Compruebe que la plataforma receptora archive las lecturas tardías según esa hora.
Preguntas frecuentes
¿Qué diferencia hay entre la hora de origen y la de llegada?
La hora de origen indica cuándo se midió o cambió el valor en el dispositivo. La de llegada indica cuándo lo recibió el sistema receptor. Normalmente las separan segundos; tras una interrupción de la red pueden separarlas horas. Para el análisis use la hora de origen; para supervisar la conexión, la de llegada.
¿Deben estar en UTC las marcas temporales de telemetría?
Sí. Almacene y transmita las horas en UTC o con un desfase explícito, como permite RFC 3339, y conviértalas a la hora local solo para mostrarlas. Sin desfase, la hora local es ambigua durante una hora cada otoño, cuando los relojes se atrasan.
¿Cómo se asigna una marca temporal a los datos por intervalos?
Indique si la marca señala el inicio o el final del intervalo y mantenga esa convención en todos los sistemas. Un valor de 15 minutos etiquetado como 10:15 puede corresponder a 10:00–10:15 o a 10:15–10:30.