Resolving SICLOCK 'Synchronization Protected' Fault in PCS 7 V7.0

Problem Overview

When a SICLOCK central clock is deployed as the master time source for a SIMATIC PCS 7 V7.0 installation, the device may report a synchronization protected fault on the front-panel display, the Web-Based Management (WBM) interface, and the red FAULT LED. In a typical dual-plant configuration the SICLOCK is the master on two independent plant bus Ethernet segments. The automation systems (S7-416-3 PN/DP) synchronize correctly in NTP mode, but the OS servers fail to take the time. The SICLOCK holds its output in a safe state and rejects the SIMATIC frames coming from the OS side, while continuing to broadcast on the plant bus to the PLCs.

This is one of the more common time-master commissioning issues in PCS 7 V7.0 plants where the SICLOCK has been retrofitted into an existing OS server / CP1613 stack. The fault is recoverable, but the fix is not always obvious because three independent configuration layers must agree: the SICLOCK port mode (eth1 / eth2), the OS server's CP1613 mode in the SIMATIC Configuration Console, and the PC station's Station Configuration Editor binding. If any one of them drifts, the SICLOCK raises the protection fault instead of a clean loss of sync event. The fault is documented in the SICLOCK TC100 Operating Instructions (Siemens, 2013) and is described in detail for redundant plants in the SICLOCK TC400 / TC100 Redundancy Application Note 0108.

System Topology and Component Map

Reference installation: two PCS 7 V7.0 plants, one SICLOCK central clock, separate plant bus segments per plant.

The SICLOCK distribution model is well documented in the TC100 operating instructions: the device transmits time on each Ethernet port using either the SIMATIC time protocol (used by CP1613 and by S7-400 CPUs with the time-of-day function) or NTP, and the two ports can be configured independently. Mixing modes on the two ports is permitted and is in fact the standard PCS 7 deployment: NTP for the AS, SIMATIC for the OS.

Decoding the 'Synchronization Protected' Fault

The synchronization protected text on the SICLOCK display is not a generic loss-of-sync message. It is generated by the device's stratum / protection logic when a downstream node behaves as if it were a master and tries to push time back into the SICLOCK, or when a slave reports a time state that the SICLOCK treats as worse than local and therefore refuses to follow. The TC100 firmware labels this state with a red FAULT LED and a non-acknowledgeable alarm that is logged in the WBM under Diagnostics → Messages as text Synchronization protected (front-panel abbreviation SYNC PROT).

According to the TC400 / TC100 Redundancy Application Note 0108, the protection trigger has three documented causes:

1. A receiving node sends a SIMATIC time frame that includes a stratum or quality field that the SICLOCK considers worse than its own. The TC100 will not demote itself; it raises the protection fault instead.
2. A receiving node configured as a SIMATIC master re-broadcasts the time at a higher stratum, creating a loop. This is the most common cause when a CP1613 is configured in PC internal master or master / slave mode rather than slave in the SIMATIC Configuration Console.
3. Excessive time jumps at the slave side. The redundancy app note states that, in the mode without proxy, parameterizable jump limits are exceeded and the time jump has to be acknowledged. If the slave is in proxy mode, the SICLOCK treats the unacknowledged jump as a protection event.

In PCS 7 V7.0 deployments, root cause #2 (CP1613 mode) is by far the most frequent. Engineers commissioning a new OS server frequently leave the time mode in PC internal master, which makes the OS a master on the plant bus and triggers the protection fault on the SICLOCK seconds after boot. The same configuration produces no error on the OS itself, so the symptom appears only on the SICLOCK side and only when both are online together.

Root Cause Analysis for the Reported Configuration

The reported case — PCS 7 V7.0, S7-416-3 PN/DP, SICLOCK as master, eth1 and eth2 in SIMATIC mode, NTP PLC sync working, OS not syncing — narrows the failure to a small set of probable causes. Execute the diagnostic flow below in order.

The combination of PLCs sync fine in NTP and OS does not sync in SIMATIC with the SICLOCK reporting synchronization protected is the classic signature of a CP1613 in master mode. Verify the Configuration Console first before touching the SICLOCK configuration. The same diagnostic flow is also referenced in the Siemens support entry Entry ID 67689753 and Entry ID 27236051 on Siemens Industry Online Support, which list the SIMATIC mode time configuration for PCS 7 OS servers.

SIMATIC Mode vs NTP Mode — What Each Port Should Carry

The SICLOCK has two Ethernet ports, each with an independent mode, broadcast address, and time source. The expected layout for a dual-plant PCS 7 V7.0 system is:

The two modes can be used on the same SICLOCK simultaneously — that is the documented configuration. The TC100 operating instructions confirm the menu path Settings → Ethernet → Port n → Mode accepts the values SIMATIC, NTP, or off. The protection fault is independent of mode and is triggered by the quality of incoming frames, not the outgoing mode.

Step-by-Step Resolution Procedure

The procedure below is for a PCS 7 V7.0 OS server pair (single OS in the example; redundant OS is covered in the next section).

Prerequisites

• Administrator account on the OS server
• Read access to the SICLOCK WBM (default user admin, password on device label)
• PCS 7 V7.0 engineering station with the PC station configuration editor (HW Config) installed
• Plant operator permission to take the OS server offline briefly
• Direct console access to the OS server (RDP is acceptable if the CP1613 driver is not restarted remotely)

Step 1 — Capture the SICLOCK alarm log

Open a browser session to the SICLOCK WBM at http://<SICLOCK-IP>, navigate to Diagnostics → Messages, and export the current fault buffer to CSV. Confirm the synchronization protected alarm is the most recent. The same alarm also appears on the front-panel display as the red FAULT LED plus the text SYNC PROT.

Step 2 — Verify SICLOCK port mode and source

On the SICLOCK, navigate to Settings → Ethernet → Port 1 (and Port 2) and verify:

• Mode: SIMATIC
• IP address: matches the plant bus subnet
• Source: internal (i.e., the SICLOCK is the master, not a slave to a higher-stratum source). If Source is external, the SICLOCK is following another master — set to internal if this device is intended to be the plant master.
• Stratum: 1
• Broadcast address: plant bus directed broadcast (typically 255.255.255.255 or the subnet broadcast)

Step 3 — Set the CP1613 to Slave mode

1. On the OS server, open Start → SIMATIC → SIMATIC Configuration Console.
2. Select the CP1613 entry under Modules / Network adapters.
3. Open the Time tab.
4. Change Type of time transmission from PC internal master to Slave (for a single OS server) or to Slave / passive (for the standby OS in a redundant pair).
5. Confirm the Source address for time-of-day synchronization is the SICLOCK eth-port IP for the relevant plant.
6. Click Apply and confirm the driver prompt to restart the CP1613.

Step 4 — Bind the CP1613 to the OS server in the PC station

On the engineering station, open the PC Station configuration in HW Config (PCS 7 V7.0: Start → SIMATIC → PC Station or via the project tree). Verify the CP1613 occupies index 1 (or index 2 for the standby) of the OS server and that the IE General interface is bound to the correct plant bus. Save the configuration and download to the PC station.

Step 5 — Restart the OS server application

Stop the WinCC Explorer / OS server runtime, wait for the CP1613 to renegotiate (about 30 s), then restart the OS. The status line at the bottom of the WinCC Explorer should report a valid time and the SICLOCK should clear the protection fault within the next beacon cycle (10 s by default for SIMATIC frames).

Step 6 — Acknowledge the alarm on the SICLOCK

On the SICLOCK WBM, navigate to Diagnostics → Messages and acknowledge the synchronization protected alarm. The red FAULT LED extinguishes, the Synchronization status indicator changes from protected to OK, and the message buffer shows the alarm leaving with timestamp and operator ID.

Step 7 — Confirm synchronization on the SICLOCK

On the SICLOCK WBM, the Synchronization status indicator should now read green. Verify the Slaves page lists the CP1613 MAC address of the OS server under Active SIMATIC slaves for the relevant port.

Redundant OS Server Considerations

For PCS 7 V7.0 redundant OS server pairs, the time configuration is per-server, not shared. Both OS servers must independently be in Slave or Slave / passive mode, and only one of the pair should be the active time consumer at any moment. The recommended split is:

Setting both servers to Slave / active causes the same protection-fault condition as the single-master case: the SICLOCK sees two clients and either rejects both or selects one based on stratum, leaving the other in a degraded state. Setting both to PC internal master is the most common misconfiguration and produces the reported synchronization protected alarm. For a redundant SICLOCK pair, the redundancy app note 0108 specifies that the parameterizable jump limit on the standby clock must be set wide enough to absorb the failover step and the alarms must be acknowledged by the operator on the standby clock before it takes over as master.

SICLOCK Firmware and Configuration Cross-Reference

Firmware release notes for the SICLOK product tree are available on Siemens Industry Online Support. The behavior summarized below is the documented V2.x line that is the current recommendation for PCS 7 V7.0 deployments; consult the release notes for the exact build you are commissioning:

The TC400 / TC100 Redundancy Application Note 0108 lists the parameterizable jump limit (menu Settings → Time → Jump limit on the WBM) and the alarm-acknowledgment workflow for production plants where the SICLOCK is part of a redundant clock pair. For a single-clock plant the default jump limit is acceptable; for a redundant pair the standby must be set to alarm-only (no step) to satisfy no-step audit policies.

Verification Checks After the Fix

1. SICLOCK WBM status: Synchronization indicator green; Diagnostics → Messages shows no active synchronization protected alarm.
2. SICLOCK front-panel display: green RUN LED steady, FAULT LED off.
3. CP1613 status: SIMATIC Configuration Console → CP1613 → Time tab → Status reads Slave, time locked to SICLOCK.
4. OS time: WinCC Explorer status bar shows the time, drift less than 1 second vs the SICLOCK display time, refreshed every 10 s.
5. AS time: S7-416-3 PN/DP time-of-day read from the online diagnostic buffer shows the same time and the same second boundary as the SICLOCK (within 10 ms).
6. Loop test: disconnect the SICLOCK from the plant bus; the CP1613 status should move to Slave, no time source within 30 s, not to PC internal master. This confirms the OS is no longer a master on the bus.
7. Redundant OS failover test: stop the active OS server; the standby should take over without raising a new protection alarm and the SICLOCK should remain in OK state.

Field-Proven Caveats

• Configuration Console persistence: PCS 7 V7.0 stores the CP1613 time mode in the registry under HKLM\SOFTWARE\Siemens\S7SIMATIC\CP1613. Some virus scanners reset this branch on definition updates; if the protection fault reappears weeks after the fix, re-check the Configuration Console value first.
• Time format: The S7-416-3 PN/DP expects SIMATIC time frames in BST format (date-and-time, 8 bytes). The SICLOCK default is BST; if the S7-400 CPU was previously synchronized by an external master in a different format, the time-of-day will not align — verify Settings → Time → Format on the SICLOCK.
• Second OS in a redundant pair: When the standby OS is in Slave / passive mode, it does not actively request time; it accepts whatever the master provides. If the standby is brought online after a long outage, expect a single time step on activation, not a continuous drift.
• Plant bus VLANs: SIMATIC time frames do not cross L3 boundaries by default. If a router is between the SICLOCK and the OS server, configure the router to forward UDP port 50000 (the default SIMATIC time port) or move the OS server to the same L2 segment as the SICLOCK.
• GPS loss: A SICLOCK that loses its GPS reference for more than the parameterizable holdover time will degrade from stratum 1 to stratum 2 and may be rejected by a CP1613 configured for stratum 1 only. This is not the protection fault, but it produces a similar symptom and is worth ruling out before commissioning.

Frequently Asked Questions