Prevención de saltos de tiempo del sistema hacia atrás y sobrescritura de archivos en servidores OS de WinCC

Los servidores OS de WinCC experimentan saltos de tiempo hacia atrás al iniciar el Runtime cuando fuentes de tiempo conflictivas —tales como un maestro del bus de planta no sincronizado, el servicio Windows Time (W32Time) o la sincronización del host del hipervisor— anulan el reloj local del sistema. Debido a que WinCC sincroniza la hora del sistema operativo Windows y escribe los cambios directamente en el RTC (BIOS) de hardware de la placa base, un telegrama de tiempo externo erróneo fuerza el reloj hacia atrás. Esto reescribe los archivos históricos de Tag Logging y Alarm Logging de SQL Server, provocando pérdida de datos y corrupción de índices de la base de datos.

Índice de contenidos

Mecanismo de los saltos de tiempo y corrupción de archivos en WinCC

En SIMATIC PCS 7, el reloj del sistema operativo del servidor OS de WinCC sirve como la referencia de tiempo maestra para registrar valores de proceso en Tag Logging y capturar eventos en Alarm Logging.

Cuando se inicia el Runtime de WinCC, se inicializan los subsistemas CCConfigStudio y TimeSync. Si la sincronización de tiempo de WinCC está habilitada, el servicio de runtime configura la hora del sistema Windows basándose en los telegramas de tiempo entrantes recibidos a través de la interfaz de comunicación configurada (por ejemplo, CP 1623 en el bus de planta o una tarjeta de red estándar mediante NTP). Posteriormente, Windows sincroniza su hora de software con el reloj en tiempo real de hardware de la placa base (RTC/BIOS).

Si un dispositivo externo transmite una marca de tiempo desactualizada (o si servicios de gestión de tiempo conflictivos compiten por el control del reloj), el tiempo de Windows salta hacia atrás.

Las consecuencias para los archivos de Microsoft SQL Server son catastróficas:
1. Sobrescritura de archivos: Tag Logging almacena valores cíclicos indexados por marca de tiempo. Un salto hacia atrás hace que los registros entrantes colisionen con los registros históricos existentes, sobrescribiendo los valores de proceso.
2. División / Bloqueo de segmentos de bases de datos: Los archivos circulares de SQL Server dependen de marcas de tiempo que aumentan estrictamente de forma monotónica. Cuando se inserta una marca de tiempo anterior a la fecha de inicio del segmento activo, el administrador de archivos encuentra violaciones de índices, bloqueando a menudo el segmento o generando excepciones en la base de datos.

Identificación de fuentes de sincronización de tiempo conflictivas

Para resolver la deriva del reloj hacia atrás, inspeccione las tres causas raíz más comunes:

  1. Maestro de tiempo erróneo en el bus de planta: Otro dispositivo en la red industrial (como una CPU S7-400 no configurada, una unidad SICLOCK no calibrada o una estación de ingeniería secundaria) está transmitiendo telegramas de tiempo con fechas/horas incorrectas.
  2. Conflictos del servicio Windows Time (W32Time): En entornos de dominio, el servicio Windows Time sincroniza automáticamente las máquinas cliente con el controlador de dominio de Active Directory. Si el controlador de dominio y el maestro de tiempo del bus de planta de PCS 7 no están sincronizados, WinCC y W32Time luchan repetidamente, provocando oscilaciones cíclicas de tiempo hacia adelante y hacia atrás.
  3. Sincronización del hipervisor de máquina virtual: En servidores OS virtualizados (por ejemplo, VMware vSphere o Microsoft Hyper-V), las herramientas de integración del hipervisor (como VMware Tools) sincronizan el reloj de la máquina virtual invitada con el servidor host físico en eventos específicos (vMotion de la máquina virtual, creación de instantáneas o sincronización periódica). Si el host ESXi se ejecuta en UTC y la invitado se ejecuta en hora local, o si la hora del host no está sincronizada, se producen cambios bruscos de hora.

Flujo de trabajo de configuración correctiva

Siga estos pasos para establecer una única jerarquía de tiempo autorizada:

  1. Deshabilitar los servicios de Windows Time conflictivos:
    * Abra los servicios de Windows (services.msc).
    * Localice Windows Time (W32Time).
    * Si la sincronización de tiempo de WinCC está configurada como el cronometrador maestro en el bus de planta, establezca el tipo de inicio de Windows Time en Deshabilitado (Disabled) o configúrelo para que se sincronice estrictamente con el maestro NTP corporativo autorizado.
  2. Deshabilitar la sincronización de hora del invitado del hipervisor:
    * En los servidores OS virtualizados, abra la configuración de la máquina virtual en vSphere Client.
    * En Opciones de VM (VM Options) -> VMware Tools, desmarque Sincronizar hora del invitado con el host (Synchronize guest time with host).
    * Añada los siguientes parámetros de configuración avanzada al archivo de configuración .vmx de la máquina virtual:
    • tools.syncTime = "FALSE"
    • time.synchronize.continue = "FALSE"
    • time.synchronize.restore = "FALSE"
  3. Verificar la configuración de sincronización de tiempo de WinCC:
    * En SIMATIC Manager / WinCC Explorer, abra Time Synchronization.
    * Confirme si el servidor OS está designado como Maestro (Master) o Esclavo (Slave).
    * Asegúrese de que solo esté seleccionado el punto de acceso al bus de planta designado. Deshabilite la sincronización de tiempo en el bus de terminal si el NTP se gestiona externamente.
  4. Inspeccionar los registros de diagnóstico:
    * Abra C:\Program Files (x86)\Siemens\WinCC\Diagnostics\TimeSync.log.
    * Busque entradas tales como Time jump detected o New system time differs by -XXXX seconds. Identifique la dirección MAC o la dirección IP reportada en la entrada del registro.

Verificación

  • En la barra de tareas de Windows, supervise el reloj del sistema. Confirme que los segundos avancen sin problemas, sin fluctuaciones ni saltos repentinos cuando se active el Runtime de WinCC.
  • Inspeccione TimeSync.log para confirmar que las correcciones de tiempo se mantienen dentro de las tolerancias normales de deriva de milisegundos (< 5 ms).
  • Abra el Tag Logging de WinCC y verifique que las marcas de tiempo de los archivos en las tablas de procesos activos avancen estrictamente en orden cronológico sin colisiones de registros.

Limitations and Operational Precautions / Limitaciones y precauciones operativas

  • Nunca cambie la fecha u hora de Windows mientras el Runtime de WinCC esté activo. Desactive siempre el Runtime y detenga SQL Server antes de realizar ajustes manuales en el reloj.
  • Si ya se ha producido un salto de tiempo significativo hacia atrás, los segmentos de base de datos existentes para ese intervalo de tiempo pueden corromperse permanentemente. Debe restablecer los archivos de Tag Logging y Alarm Logging para garantizar un funcionamiento fiable en el futuro.
  • La deriva del RTC de hardware también puede ser el resultado de una batería de tipo botón CMOS de la placa base defectuosa. Sustituya la batería si la pérdida del reloj de hardware persiste después de los ciclos de encendido.

Preguntas frecuentes del ingeniero

  • ¿Puede WinCC manejar las transiciones del horario de verano (DST)?
    Sí. WinCC almacena internamente todas las marcas de tiempo en Tiempo Universal Coordinado (UTC). Los ajustes locales del horario de verano afectan únicamente a la visualización gráfica en los controles del runtime, evitando la corrupción de archivos durante los cambios de hora estacionales.
  • ¿Por qué cambia la hora de la BIOS cuando cambia la hora de Windows?
    Los sistemas operativos Windows modernos escriben actualizaciones de sincronización de tiempo en el reloj en tiempo real CMOS de la placa base física al apagar el equipo y mediante una sincronización periódica del sistema.
  • ¿Qué debo hacer si las tendencias históricas ya se han sobrescrito?
    Para restaurar la integridad de la base de datos, ejecute una compilación completa del OS con borrado de memoria (reset memory) y reinicie los archivos de runtime de Tag Logging en WinCC Configuration Studio.

Referencias técnicas

  • Manual del sistema de sincronización de tiempo de SIMATIC PCS 7 (A5E41356410-AA).
  • Siemens Industry Online Support Entry ID 109801081: Time Synchronization in Virtualized PCS 7 Environments.
  • VMware Knowledge Base 1189: Disabling Time Synchronization in VMware Tools.

Artículos relacionados

Etiquetas relacionadas

WinCC, PCS 7, Time Synchronization, SQL Server, BIOS, Tag Logging, VMware, W32Time

20 respuestas