Preventing Backward System Time Jumps and Archive Overwrites in WinCC OS Servers

Preventing Backward System Time Jumps and Archive Overwrites in WinCC OS Servers

WinCC OS Servers experience backward time jumps upon starting Runtime when conflicting time sources—such as an unsynchronized Plant Bus master, Windows Time Service (W32Time), or hypervisor host synchronization—override the local system clock. Because WinCC synchronizes the Windows operating system time and writes changes directly to the motherboard hardware RTC (BIOS), an erroneous external time telegram forces the clock backward. This rewrites historical SQL Server Tag Logging and Alarm Logging archives, causing data loss and database index corruption.

Table of Contents

• Mechanism of Time Jumps and Archive Corruption in WinCC
• Identifying Conflicting Time Synchronization Sources
• Corrective Configuration Workflow
• Verification
• Limitations and Operational Precautions
• Engineer FAQ
• Technical References
• Related Articles
• Related Tags

Mechanism of Time Jumps and Archive Corruption in WinCC

In SIMATIC PCS 7, the WinCC OS Server operating system clock serves as the master time reference for logging process values into Tag Logging and capturing events in Alarm Logging.

When WinCC Runtime launches, the CCConfigStudio and TimeSync subsystems initialize. If WinCC Time Synchronization is enabled, the runtime service sets the Windows system time based on incoming time telegrams received via the configured communication interface (e.g., CP 1623 on the Plant Bus or standard NIC via NTP). Windows subsequently synchronizes its software time with the motherboard hardware Real-Time Clock (RTC/BIOS).

If an external device broadcasts an outdated timestamp (or if conflicting time management services fight for clock control), the Windows time jumps backward.

The consequences for Microsoft SQL Server archives are catastrophic:
1. Archive Overwrites: Tag Logging stores cyclic values indexed by timestamp. A backward jump causes incoming records to collide with existing historical records, overwriting process values.
2. Database Segment Splitting / Locking: SQL Server circular archives rely on strict monotonically increasing timestamps. When a timestamp earlier than the active segment start date is inserted, the archive manager encounters index violations, often locking the segment or generating database exceptions.

Identifying Conflicting Time Synchronization Sources

To resolve backward clock drift, inspect the three most common root causes:

1. Rogue Time Master on Plant Bus: Another device on the industrial network (such as an unconfigured S7-400 CPU, an uncalibrated SICLOCK unit, or a secondary engineering workstation) is transmitting time telegrams with incorrect dates/hours.
2. Windows Time Service (W32Time) Conflicts: In domain environments, the Windows Time service automatically synchronizes client machines with the Active Directory domain controller. If the domain controller and the PCS 7 Plant Bus time master are not synchronized, WinCC and W32Time repeatedly fight, causing cyclical forward and backward time oscillations.
3. Virtual Machine Hypervisor Synchronization: On virtualized OS servers (e.g., VMware vSphere or Microsoft Hyper-V), hypervisor integration tools (such as VMware Tools) synchronize the guest VM clock with the physical host server upon specific events (VM vMotion, snapshot creation, or periodic sync). If the ESXi host runs on UTC and the guest runs on local time, or if host time is unsynchronized, sudden hour shifts occur.

Corrective Configuration Workflow

Follow these steps to establish a single, authoritative time hierarchy:

1. Disable Conflicting Windows Time Services:
   * Open Windows Services (services.msc).
   * Locate Windows Time (W32Time).
   * If WinCC Time Synchronization is configured as the master timekeeper on the plant bus, set the startup type of Windows Time to Disabled or configure it to sync strictly with the authoritative corporate NTP master.
2. Disable Hypervisor Guest Time Synchronization:
   * On virtualized OS servers, open the VM settings in vSphere Client.
   * Under VM Options -> VMware Tools, uncheck Synchronize guest time with host.
   * Add the following advanced configuration parameters to the VM .vmx configuration file:
   • tools.syncTime = "FALSE"
   • time.synchronize.continue = "FALSE"
   • time.synchronize.restore = "FALSE"
3. Verify WinCC Time Synchronization Configuration:
   * In WinCC Explorer, open Time Synchronization.
   * Confirm whether the OS Server is designated as a Master or Slave.
   * Ensure that only the designated Plant Bus access point is selected. Disable time synchronization on the Terminal Bus if NTP is managed externally.
4. Inspect Diagnostic Logs:
   * Open C:\Program Files (x86)\Siemens\WinCC\Diagnostics\TimeSync.log.
   * Check for entries such as Time jump detected or New system time differs by -XXXX seconds. Identify the MAC address or IP address reported in the log entry.

Verification

• In Windows Taskbar, monitor the system clock. Confirm that seconds advance smoothly without jitter or sudden leaps when WinCC Runtime activates.
• Inspect TimeSync.log to confirm that time corrections remain within normal millisecond drift tolerances (< 5 ms).
• Open WinCC Tag Logging and verify that archive timestamps in active process tables advance strictly in chronological order without record collisions.

Limitations and Operational Precautions

• Never change the Windows date or time while WinCC Runtime is active. Always deactivate Runtime and stop SQL Server before making manual clock adjustments.
• If a significant backward time jump has already occurred, existing database segments for that time range may be permanently corrupted. You must reset Tag Logging and Alarm Logging archives to ensure reliable operation going forward.
• Hardware RTC drift can also result from a failing motherboard CMOS coin-cell battery. Replace the battery if hardware clock loss persists after power cycles.

Engineer FAQ

• Can WinCC handle daylight saving time (DST) transitions?
  Yes. WinCC internally stores all timestamps in Coordinated Universal Time (UTC). Local daylight saving adjustments affect only the graphic display in runtime controls, preventing archive corruption during seasonal time changes.
• Why does the BIOS time change when Windows time changes?
  Modern Windows operating systems write time synchronization updates to the physical motherboard CMOS real-time clock upon shutdown and periodic system sync.
• What should I do if historical trends are already overwritten?
  To restore database integrity, execute a complete OS compilation with memory reset and reset the Tag Logging runtime archives in WinCC Configuration Studio.

Technical References

• SIMATIC PCS 7 Time Synchronization System Manual (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.

Related Articles

• Hardening WinCC Virtual Machines: Best Practices for Network and Time Configuration.
• Recovering Corrupted WinCC Tag Logging and Alarm Logging SQL Databases.

Related Tags

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