¿Qué es una marca de tiempo futura en SCADA?
De vez en cuando un valor llega al historiador marcado con una hora que aún no ha ocurrido - mañana, la próxima semana o años adelante. Es una falla confusa porque el número en sí puede ser perfectamente válido; solo la hora adjunta está mal. Esta guía explica cómo un reloj de dispositivo adelantado, un desfase de zona horaria doblado o un rollover de GPS malo empuja las lecturas al futuro, por qué eso rompe las consultas de último valor y las tendencias de maneras fáciles de malinterpretar, y cómo rastrear el problema de vuelta a un ajuste de reloj o zona horaria en lugar del proceso.
Marca de tiempo futura en una línea: Una marca de tiempo futura es un valor SCADA cuya hora registrada es posterior al momento real en que se midió, normalmente porque un reloj de dispositivo está adelantado, una conversión de UTC a local se aplicó dos veces, o un receptor GPS dio la vuelta a su contador de semanas de forma incorrecta. El valor puede ser de calidad Buena, pero como se ubica en el futuro corrompe las tendencias, se esconde detrás de las consultas de último valor y puede ser rechazado o mal archivado por el historiador.
Cómo un valor termina marcado en el futuro
Hay tres maneras comunes en que una marca de tiempo salta por delante del tiempo real. La más simple es un reloj mal fijado: una RTU, un PLC o una pasarela cuyo reloj de tiempo real se ajustó de forma incorrecta, derivó tras una batería muerta o se tecleó a mano con la fecha equivocada. La hora que ese dispositivo cree que es se vuelve la marca de tiempo fuente en cada lectura que produce, y si cree que es el próximo marzo, ahí es donde aterrizan los datos. Un dispositivo que perdió su reloj y se reinició a una época por defecto puede igual de fácil leer hacia atrás, pero una fecha mal tecleada o un reloj empujado adelante durante la puesta en marcha es una causa frecuente de saltos hacia adelante.
La segunda causa es un desfase de zona horaria doblado. Un dispositivo de campo reporta en UTC, una pasarela convierte con buena intención de UTC a hora local, y luego el host SCADA convierte lo que supone que es UTC a local otra vez, así que el desfase se aplica dos veces y el valor aterriza horas adelante. En una zona horaria de desfase positivo la lectura aparece en el futuro por el tamaño de dos desfases. La tercera causa es el rollover de semana de GPS: los receptores GPS más viejos cuentan semanas en un campo que da la vuelta más o menos cada veinte años, y un receptor que maneja mal el rollover puede emitir una fecha muchos años desviada, arrastrando consigo cualquier marca de tiempo que discipline.
Por qué los datos futuros rompen tendencias y consultas de último valor
El efecto más dañino de una marca de tiempo futura es sobre la consulta de último valor, el patrón que el SCADA usa constantemente para responder la pregunta de cuánto vale este tag ahora mismo. Como una muestra con fecha futura tiene la hora más alta de la serie, gana esa consulta y se queda pegada. La carátula, la pantalla de resumen y cualquier cálculo que lea el valor actual se aferran a una lectura que no será superada hasta que el tiempo real de verdad alcance esa marca de tiempo - lo que podría ser días o años después. El operador ve un número congelado que nunca se actualiza, aunque datos frescos y correctamente marcados estén llegando por debajo, porque esas muestras más nuevas tienen marcas de tiempo anteriores y nunca se vuelven la más reciente.
Las tendencias se distorsionan de forma equivalente. Un solo punto lanzado muy lejos a la derecha obliga al eje de tiempo a estirarse para acomodarlo, comprimiendo los datos reales en una banda delgada a la izquierda y dejando un largo hueco vacío. Las agregaciones sobre un periodo pueden jalar una muestra que no pertenece a ese periodo, o perder datos que se archivaron bajo un contenedor futuro. Algunos historiadores se defienden de esto al rechazar muestras cuya marca de tiempo excede el ahora por más de una tolerancia configurada, lo que detiene la corrupción pero descarta en silencio las lecturas, así que el tag simplemente muestra un hueco. De cualquier manera el síntoma - un último valor pegado o una tendencia estropeada - apunta de vuelta al tiempo, no al sensor.
Rastrearlo a un reloj o zona horaria en SCADA en la nube
La forma más rápida de localizar una marca de tiempo futura es comparar la marca de tiempo de calidad del valor contra el momento en que los datos se recibieron de verdad. Si una lectura lleva una marca de tiempo fuente horas o años adelante de cuando el servidor la ingirió, el reloj o el desfase está aguas arriba en el dispositivo o la pasarela, no en el historiador. De ahí el diagnóstico se estrecha rápido: todo un dispositivo leyendo unas horas adelante apunta a un doble desfase de zona horaria; un dispositivo años adelante apunta a un rollover de GPS o una fecha muy equivocada; un tag adelante mientras sus vecinos están bien apunta a una conversión por tag y no a un reloj de dispositivo.
Una plataforma de SCADA en la nube ayuda de dos maneras. Primera, registra tanto una marca de tiempo fuente del campo como una marca de tiempo de servidor al ingerir, así que la brecha entre ellas es visible por lectura y un salto hacia adelante es fácil de detectar en lugar de quedar enterrado. Segunda, puede aplicar una ventana de razonabilidad que marca o pone en cuarentena las muestras marcadas más allá de un margen sensato adelante del tiempo del servidor, para que un valor con fecha futura no envenene en silencio la consulta de valor actual de cada pantalla y cálculo aguas abajo. El arreglo permanente sigue estando aguas arriba - disciplinar el reloj del dispositivo a una buena fuente de tiempo, asegurar que UTC se convierta a local exactamente una vez a lo largo del camino, y actualizar o reemplazar receptores que manejan mal el rollover de GPS - pero sacar a la luz la brecha entre fuente y servidor es lo que convierte un tag congelado desconcertante en un problema de reloj obvio.
Preguntas frecuentes
¿Por qué mi tag SCADA está pegado en un valor que nunca se actualiza?
Una causa frecuente es una marca de tiempo futura. Si una muestra llegó marcada con una hora en el futuro, se vuelve el último valor de la serie y gana cada consulta de último valor, así que la carátula se congela en ella mientras datos más nuevos y correctamente marcados llegan por debajo con marcas de tiempo anteriores y nunca la rebasan. Revise si la marca de tiempo más nueva del tag es posterior al tiempo actual real; si lo es, corrija el reloj del dispositivo o la conversión de zona horaria que la produjo.
¿Cómo pone un error de zona horaria los datos en el futuro?
Suele ocurrir cuando una conversión de UTC a local se aplica dos veces a lo largo del camino de datos - por ejemplo una pasarela convierte de UTC a local, luego el host SCADA convierte el mismo valor otra vez suponiendo que aún es UTC. En una zona horaria que está adelante de UTC, el desfase doblado empuja la lectura horas al futuro. El valor de la lectura es correcto; solo la hora adjunta está mal, que es por qué la calidad puede seguir siendo Buena mientras la tendencia se ve rota.
¿El historiador debe rechazar las marcas de tiempo en el futuro?
Muchos historiadores aplican una ventana de razonabilidad que marca o descarta muestras marcadas más de una pequeña tolerancia adelante del tiempo actual del servidor, lo que evita que un valor malo corrompa las tendencias y las consultas de valor actual. El intercambio es que las muestras rechazadas dejan un hueco en lugar de un punto equivocado, así que conviene registrar lo que se rechazó. El rechazo es una red de seguridad, no una cura: la falla subyacente de reloj o zona horaria aún necesita corregirse en la fuente.
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.