Resolve a 12-Minute Time Difference Between Redundant PCS 7 OS Servers

Do not correct a 12-minute discrepancy by manually changing one server until you identify the configured time master and synchronization path. First determine why the two redundant OS servers are not following the same source, then restore the documented time-synchronization configuration and verify both server clocks. Siemens' PCS 7 V9.0 manual warns that a time jump greater than five seconds can cause a configured time master to switch to slave; this behavior is explicitly version-scoped and should not be generalized without checking the installed release.

Why redundant servers can drift apart

The source reports two OS servers and three OS clients, with both servers said to take time from a PC station, but does not identify the PCS 7 version, topology or whether that PC is configured as the authoritative source. If the servers are not receiving or applying the same time reference, their clocks can diverge. The observed 12-minute difference is evidence of a synchronization problem, not proof of a particular setting failure.

Map the time-master and time-slave roles

List every time source and role: PC station/domain controller, both OS servers, OS clients and any central plant clock. Confirm how each network synchronizes time and whether the OS servers are configured as masters, cooperative masters or slaves in the PCS 7 Time Synchronization editor. Siemens states that only one component within a stratum can be the active time master. Do not assume that two Windows PCs independently described as using “the PC station” are actually synchronized through the same configured master.

Restore a single documented synchronization design

Use the Time Synchronization manual for the installed PCS 7 release and match the configuration to the actual workgroup/domain and plant-bus/terminal-bus topology. Siemens' PCS 7 V9.0 manual describes several architectures: central clock, domain-controller time source, and OS-server cooperative masters. These are alternatives with different prerequisites, not settings to combine indiscriminately. Correct the underlying source or role configuration instead of repeatedly changing one server's clock by hand.

Apply manual time corrections cautiously

For PCS 7 V9.0, Siemens documents that a time jump greater than five seconds on a computer configured as time master causes it to become a time slave and generates “Time synchronization has been permanently switched to slave.” The manual says that state persists after restart and requires restoring the master role using the documented procedure. This specific threshold and message are V9.0 documentation; verify the matching release manual before assuming identical behavior elsewhere.

Assess archive and event implications

A manual time correction can change the order or apparent spacing of event timestamps; the thread does not establish exactly how the site's archives or redundancy synchronization will respond. Siemens' time-synchronization procedures address time master roles and system synchronization, but no source here verifies the effect of a 12-minute step on this installation's archive update. Plan any correction during an approved window and confirm archive and event behavior after synchronization has recovered.

Commissioning procedure

Record PCS 7 release/service pack, OS versions, domain/workgroup membership and current time on both OS servers, the PC station and clients.
Identify the configured active/passive/cooperative master for the terminal bus and plant bus, and determine how each server is set to receive time.
Check synchronization state and diagnostics on both OS servers; compare the configured source and role settings, not just the displayed clocks.
Correct the misconfigured or unavailable source/role using the release-matched Siemens procedure. Avoid an unplanned large manual time step on an active time master.
Once both servers are following the intended source, verify they converge and remain synchronized over the configured interval.
Review archive synchronization, alarm/event chronology and OS client status under site procedures. Record any time jump and its operational impact.

Expected result and verification

Both redundant servers should follow the project's intended common time-synchronization design. Verify each server's configured role and source, current time and synchronization diagnostics, then confirm clients and relevant records show consistent timestamps. Merely setting two clocks to the same displayed minute does not prove they will remain synchronized.

Version applicability

The ticket provides no PCS 7 release. Siemens' opened Time Synchronization (V9.0) manual documents V9.0 behaviors and configurations; its five-second time-jump behavior is not asserted as universal. For another version, use that version's official manual and applicable release documentation.

Verification

After correcting the source/role configuration, check both OS servers in the PCS 7 Time Synchronization editor/diagnostics and observe their clocks over at least the configured synchronization interval. Confirm the clients obtain time from the intended server(s), and inspect archive/redundancy status plus representative alarm/event timestamps. Escalate if the clocks diverge again even though both report the expected time source.

Limitations and Operational Precautions

The exact Windows/domain setup, source PC, master role, PCS 7 release and archive configuration are missing. No specific root cause or archive effect can be claimed from the discussion. Manual clock changes can affect event chronology; follow site change control and preserve relevant logs before correcting a large offset.

Engineer FAQ

Should I manually subtract 12 minutes from one server? Not before identifying its time-master role and source. In PCS 7 V9.0 a jump above five seconds can change a master's role; verify the installed release behavior first.

What should be checked first? Document the time source and master/slave/cooperative roles for both OS servers, domain controller/PC station and clients.

Can both redundant servers act as masters? PCS 7 V9.0 describes cooperative time-master configurations, but only one component per stratum is active at a time. Follow the exact architecture in the deployed-version manual.

Will the time correction break archive synchronization? The source does not establish a specific outcome. Treat timestamp chronology and archive state as operational checks during a controlled correction.

What confirms the issue is fixed? Both OS servers show the intended configured source and synchronization state, clocks remain aligned over the configured interval, and clients/records show consistent time.

Technical References

Siemens, Time Synchronization (V9.0), Function Manual, 05/2017, A5E39221891-AA, §§3.7–3.8 (time roles/topology), §4.2 (time synchronization rules), §§4.3–4.4 (workgroup/domain architectures), §6.4 (OS stations), and §6.9 (redundant systems): https://cache.industry.siemens.com/dl/files/544/109746544/att_923935/v1/ps7tsy_b_en-US.pdf?download=true

Related Tags

PCS 7 time synchronization

Redundant OS Servers

Time master

20 respuestas

Resolve a 12-Minute Time Difference Between Redundant PCS 7 OS Servers