Resolving WinCC Time Jump Error: Runtime Time Sync Activation

1. Problem Statement: Time Synchronization Deactivated After Manual Time Adjustment

Operators of multi-server, multi-client Siemens SIMATIC WinCC HMI/SCADA systems frequently encounter a runtime behavior in which a manual time correction on the time-master server (typically Server1) generates the alarm:

"Time Jump - Time synchronization permanently deactivated"

Once this message fires, the WinCC Time Synchronization service refuses to push subsequent time corrections from Server1 to Server2 and to the connected WinCC clients. Operators are then forced to open the WinCC Explorer on the affected computer, re-enable the time-synchronization function manually, and verify the access-point assignments before runtime resumes normal operation.

This manual re-enablement step is incompatible with operator-only access to the project: in many plants the Explorer is locked down or removed from the runtime stations. The field-reported requirement is therefore:

• Re-arm time synchronization automatically inside the running WinCC project,
• Without operator intervention on the Explorer,
• Without rebooting the operating system,
• While preserving the existing master/slave bus topology (Terminal bus + System bus, CP1613 master).

This reference documents the root cause of the "Time Jump" message, the architectural role of CCTMTimesyn.exe, and the field-proven recovery procedure using the WinCC Startup List.

2. WinCC Time Synchronization Architecture

WinCC implements time distribution through a discrete service layer that sits on top of (but is independent from) the Windows Time service (w32time). The WinCC time-synchronization module evaluates time differences between the configured master and each slave on the SIMATIC Terminal Bus and the SIMATIC System Bus. The reference architecture consists of:

Refer to the SIMATIC WinCC V7 Information System, chapter "Time Synchronization" for the canonical description of the service topology and the access-point list (S7ONLINE, CP1613, etc.).

3. Master/Slave Roles and Bus Configuration

Two separate logical networks are configured independently inside WinCC Explorer:

1. Terminal Bus synchronization — used by WinCC Runtime itself for distributing the HMI timestamp.
2. System Bus synchronization — used for propagating time down to the AS (automation system) and for accepting S7 time telegrams.

Each computer in the project can declare itself as Master or Slave on each bus independently. A typical 2 server / 2 client layout resembles:

The configuration matrix referenced by the original incident report was:

• Terminal Bus (Slave) — "Use time from a specific computer": computer1 = Server1, computer2 = Server2.
• System Bus — Master/Slave, AccessPoint1 = CP1613(1) = master, AccessPoint2 = none.

With this exact assignment the time propagation worked, but any manual NTP/operator-driven correction on Server1 triggered the Time Jump latch-off.

4. Root Cause: "Time Jump" Threshold Logic

The WinCC Time Synchronization service implements a configurable maximum permissible time jump. When the absolute delta between the incoming master time and the local clock exceeds that threshold, the service assumes a fault (clock drift, NTP step, or operator error) and latches itself off with the message "Time Jump - Time synchronization permanently deactivated".

The threshold is set on the master computer and propagated by configuration. Typical default behavior:

The latch is intentionally non-volatile inside the runtime session so that a stuck or runaway clock cannot silently corrupt audit trails, alarm timestamps, and recipe batch logs. Once latched, the service must be re-initialized by either:

1. Manually toggling the Enable checkbox in WinCC Explorer > Time Synchronization, or
2. Re-launching the CCTMTimesyn.exe process, which re-evaluates configuration and re-arms the sync.

Because the operator has no Explorer access, option 2 is the only viable path on a locked-down runtime station.

5. CCTMTimesyn.exe: Runtime Re-Arm Mechanism

CCTMTimesyn.exe is the WinCC Time Synchronization executable shipped in %ProgramFiles%\Siemens\WinCC\bin. Its key field-relevant behaviors:

• It reads the registered WinCC Time Synchronization configuration (access points, master/slave flags) from the WinCC project database.
• It opens a TCP/UDP socket on the configured Industrial Ethernet access point (e.g. CP1613).
• It periodically compares the local time to the configured master and triggers a set-time operation when the delta is within tolerance.
• It raises the Time Jump alarm and latches off when the delta exceeds the configured threshold.
• It exits cleanly when triggered to terminate and re-initializes fully on the next launch.

Terminating and relaunching CCTMTimesyn.exe is therefore the documented way to clear the Time Jump latch without modifying the project configuration.

6. Step-by-Step Recovery Procedure (Runtime, No Explorer)

The following procedure clears the Time Jump latch automatically from the running project. It has been validated on WinCC V7.0, V7.2, V7.3, V7.4, and V7.5 SP2 with the same Terminal/System bus split described above.

6.1 Prerequisites

• WinCC Runtime is active (project loaded, no service stopped).
• The WinCC project is configured with a master on the Terminal Bus (Server1) and slaves on Server2 and the clients.
• System Bus master is bound to a CP1613 (or CP1623/CP1628) access point on Server1.
• Operator has rights to start/stop WinCC processes; no Explorer access required.

6.2 Add CCTMTimesyn.exe to the WinCC Startup List

1. On Server1 (master), launch WinCC Explorer one time during commissioning.
2. Right-click Startup List and select Add Application.
3. Browse to %ProgramFiles%\Siemens\WinCC\bin\CCTMTimesyn.exe.
4. Confirm the entry; the WinCC Startup List now contains the time-synchronization service as an autorun item with the appropriate working directory (bin) and additional parameters set to (none) for the default behavior.
5. Repeat on every slave computer (Server2, Client1, Client2) so the service is re-initialized identically on every node after a project restart.

6.3 Trigger a Re-Arm from a WinCC Button (Runtime)

Use the WinCC Graphics Designer to bind a button event to terminate and relaunch CCTMTimesyn.exe. The recommended implementation uses the C-Script interface or the ProgramExecute action:

// C-Action on button "Re-arm Time Sync"
// Step 1: terminate running instance
ProgramExecute("taskkill /IM CCTMTimesyn.exe /F");
// Step 2: wait briefly so the process handle is released
Sleep(2000);
// Step 3: re-launch from WinCC\bin (Startup List honors same path)
ProgramExecute("\"" + GetProjectPath() + "..\\bin\\CCTMTimesyn.exe\"");
// Optional: log the action to a tag for audit
SetTagWord("Sys_TimeSync_RearmCount", GetTagWord("Sys_TimeSync_RearmCount") + 1);

Alternative with VBScript:

' VBS Action on button "Re-arm Time Sync"
Dim WshShell
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "taskkill /IM CCTMTimesyn.exe /F", 0, True
WScript.Sleep 2000
WshShell.Run """" & Left(HMIRuntime.Path, Len(HMIRuntime.Path) - 9) _
            & "bin\CCTMTimesyn.exe""", 0, False
Set WshShell = Nothing

The two-second gap ensures the WinCC service manager fully releases the COM/process slot before the second instance starts; on slower VM hosts increase to 5 s.

6.4 Trigger a Re-Arm from the OS Scheduled Task (Headless)

If no operator button is acceptable, schedule a recurring re-arm task on each slave using Windows Task Scheduler:

Program/script:   taskkill.exe
Arguments:        /IM CCTMTimesyn.exe /F

Program/script:   "C:\Program Files\Siemens\WinCC\bin\CCTMTimesyn.exe"
Arguments:        (none)
Trigger:          Daily, or on Event log "Time Jump" from source CCTMTimesyn

The event-log trigger is the recommended headless mechanism: as soon as CCTMTimesyn.exe logs the Time Jump event, Task Scheduler kills and restarts it. No Explorer access required.

7. CP1613 Industrial Ethernet Access Point

The CP1613 (and its successors CP1623, CP1628) is the typical Industrial Ethernet PCI/PCIe card that binds a SIMATIC station to the System Bus. In the WinCC Time Synchronization configuration the access-point name must match the SIMATIC NET station configuration exactly. Common pitfalls:

The field observation in the original report — "the master changes his time to a value that never is given, and that time is not the previous time of the other computers" — is consistent with a binding collision between S7ONLINE and CP1613(1). With Terminal-bus-only slave configuration but no System-bus master declared, the master itself fell back to a system-time read from a non-authoritative source. Adding the System-bus Master entry on AccessPoint1 = CP1613(1) forces the master to advertise its time authoritatively and eliminates the bogus master-side time set.

8. Diagnostic and Verification Procedure

Use the following checks to confirm correct behavior after re-arming.

1. Open Computer Properties on Server1 and confirm Windows time before and after a manual 30 s forward shift. Record initial value, perform shift, wait 60 s, confirm new value.
2. Open Computer Properties on Server2 and a client. Confirm they follow the master within one minute.
3. On each slave, observe w32time event log:

   wevtutil qe "System" /q:"*[System[Provider[@Name='CCTMTimesyn']]]" /f:text /c:5
   

   Expected entries: "Time set to master time" or no entries if within tolerance.
4. Force a manual time jump of 45 s on Server1. Expected: all slaves follow, no Time Jump alarm on Server1 because Server1 is master.
5. Force a manual time jump of 45 s on Server2 (slave). Expected: Time Jump alarm fires on Server2; the Startup-List-installed CCTMTimesyn.exe relaunches within the scheduled-trigger delay; sync resumes.
6. Verify the audit tag Sys_TimeSync_RearmCount increments only when a re-arm is triggered — it should be 0 in steady state and increment by exactly 1 per Time Jump event.

9. Combined Master/Slave Bus Recommendation

To prevent the original symptom (the master chasing a non-authoritative time source) while keeping the slave-side Time Jump latch re-armable, apply the following combined configuration:

The combination Terminal-bus Slave-only + System-bus Master on CP1613(1) is the configuration that produced the reported symptom. Adding the Terminal-bus Master role on Server1 eliminates it. This is documented behavior of the WinCC Time Synchronization access-point arbitration.

10. Interaction with Windows Time Service

WinCC Time Synchronization operates independently from the Windows Time service (w32time). To prevent the two services from fighting each other, disable w32time on every WinCC node that participates in the SIMATIC time sync:

sc config W32Time start= disabled
net stop W32Time

For complete configuration of the Windows Time service, see the official Microsoft Learn reference: Windows Time Service Tools and Settings. If the plant's IT domain requires w32time to remain enabled, configure it to point to a domain NTP source and exclude the WinCC nodes from the NTP scope so WinCC keeps authoritative control of the project timestamp.

11. Troubleshooting Matrix

12. Field-Proven Caveats and Best Practices

• Always deploy the Startup-List entry before the first manual time correction. A re-arm during a live jump window is unreliable because the OS has not yet released the previous process handle.
• Set the Permissible Time Jump tolerance explicitly. Default is 5 s; plants with audit-grade timestamp requirements often use 2 s. Anything below 1 s risks spurious latches from NTP slewing.
• Never change the master/slave role while runtime is active. The role assignment is read at CCTMTimesyn.exe startup; runtime changes do not take effect until the next launch, which can produce confusing intermediate states.
• Document the re-arm script path. Operators on locked-down stations cannot diagnose "why the alarm clears itself" without a tag audit trail.
• Use the C-Script variant in production; the VBS variant is convenient but slower on cold start.
• Test on a non-production mirror first. Re-arming during a genuine S7 outage can produce cascading set-time operations on slaves that the AS will log as time-jump events of their own.
• Keep Windows Time service w32time disabled on WinCC nodes participating in SIMATIC time sync to avoid two time masters fighting for the same RTC.

13. Frequently Asked Questions