Operating System Parity Rules for Redundant OS Servers and Alarm Timestamp Synchronization in PCS 7

In SIMATIC PCS 7, redundant WinCC OS Servers must run identical operating system versions, service packs, and WinCC update releases; mixing Windows Server 2016 and 2019 across a redundant server pair is strictly unsupported due to DCOM, RPC marshaling, and SQL Server replication incompatibilities. Furthermore, alarm timestamps that deviate from local PC time (such as by 15 minutes or exact timezone offsets) occur because S7 controllers timestamp alarms in UTC inside OB cycles, while WinCC renders alarms based on Windows Time Zone and daylight saving settings. To resolve this, configure centralized plant-wide time synchronization (via SICLOCK or central NTP master) across all controllers and OS servers.

Executive Summary

High-availability operator supervision in SIMATIC PCS 7 depends on two foundational architectural pillars: paired WinCC OS Server redundancy and plant-wide deterministic time synchronization. During system upgrades or routine plant maintenance, engineers frequently encounter two critical questions. First, can a redundant OS Server pair temporarily or permanently run mismatched operating systems (for instance, keeping Server A on Windows Server 2016 while commissioning Server B on Windows Server 2019)? Second, why do process alarm timestamps in WinCC Alarm Logging drift or mismatch the operator console clock by 15 minutes or several hours?

Operating system parity across redundant servers is a non-negotiable requirement in PCS 7: subtle differences in Windows security protocols, DCOM RPC authentication, and SQL Server replication engines prevent reliable redundancy synchronization. Regarding alarm timestamping, PCS 7 utilizes controller-based UTC timestamping at the instant of event detection. If the automation controller clock drifts or the WinCC station's timezone mapping is misconfigured, historical alarms desynchronize. This guide explains the technical reasons behind OS parity rules and details how to establish deterministic time synchronization across the entire automation hierarchy.

Architecture and Fundamental Mechanics

The PCS 7 high-availability architecture links operating system services, relational databases, and controller interrupt timing:

The OS Parity Requirement for WinCC Redundancy:
- WinCC Redundancy (CCRedSync.exe) synchronizes runtime process databases, alarm logs, and user actions between Server A and Server B via Microsoft SQL Server replication and proprietary network sockets.
- Different Windows Server versions (e.g., 2016 vs 2019) enforce different security baselines, SMB dialects, RPC encryption levels, and SQL Server cumulative updates.
- Running mismatched operating systems creates transient communication timeouts, failed database replication, and false redundancy split-brain states (Redundancy Error ID 16#2). Siemens documentation strictly mandates identical OS builds and software patch levels on redundant pairs.
- Note: A temporary version mismatch is tolerated ONLY during a documented rolling update migration, provided the transition is completed within the planned maintenance window.
S7 Controller Timestamping Architecture (UTC Mechanics):
- When a process alarm occurs (e.g., via ALARM_8P or EventTS), the S7-400 or CPU 410 controller stamps the alarm telegram using its internal real-time clock in Coordinated Universal Time (UTC) with millisecond precision.
- The controller does NOT track daylight saving time (DST) or regional time zones; UTC provides an absolute, monotonically increasing time reference that prevents duplicate or missing timestamps during clock adjustments.
WinCC Local Display Conversion and Clock Drift:
- When WinCC receives the UTC alarm telegram, the Alarm Control component converts the UTC timestamp into local display time by applying the Windows operating system's configured Time Zone and DST offset.
- Discrepancies arise in two primary scenarios:
- Clock Drift: If the controller clock is not synchronized with an external NTP master (such as SICLOCK), internal hardware crystal oscillator drift causes the controller clock to drift by minutes or hours.
- Timezone Mismatch: If the Windows client timezone is misconfigured (or if time synchronization is poorly routed across subnets), alarms display misleading timestamps.

Step-by-Step Implementation Procedure

Follow these steps to ensure OS parity and establish centralized time synchronization in PCS 7:

Enforce Operating System Parity on Redundant OS Servers:
- Verify operating system version on Server A and Server B: press Win + R, type winver, and press Enter.
- Ensure both servers run the identical Windows Server version (e.g., Windows Server 2019 Standard 64-bit, Build 1809).
- Verify that identical SIMATIC PCS 7 and WinCC updates/hotfixes are installed using SIMATIC Manager ('Help > About > Installed Software').
- Do NOT operate redundant servers with different Windows OS versions in production.
Configure Central Time Master (SICLOCK or Domain NTP):
- Designate a central GPS/NTP time server (such as Siemens SICLOCK TC400) or a central domain controller as the master clock on the Plant Bus.
- Ensure all controllers (CPU 410-5H) and OS Servers share access to this NTP time server.
Configure S7 CPU Time Synchronization in HW Config:
- Open HW Config for each automation station in SIMATIC Manager.
- Double-click the Industrial Ethernet CP or CPU onboard PROFINET interface (e.g., PN-IO).
- Switch to the 'Time Synchronization' tab.
- Check 'Enable time-of-day synchronization in NTP mode'.
- Enter the IP addresses of the primary and secondary NTP time servers.
- Set the synchronization interval (recommended: 10 seconds).
- Save and compile HW Config and download to the CPU.
Configure WinCC Time Synchronization in WinCC Explorer:
- On the OS Server project, open WinCC Explorer.
- In the navigation tree, double-click 'Time Synchronization'.
- In the Time Synchronization dialog, check 'Synchronization via Terminal Bus (Slave)' if receiving time from a master OS or domain controller, or 'Synchronization via Industrial Ethernet (Master)' if the OS Server distributes time.
- Ensure the option 'UTC' is selected for internal time base.
- Click 'OK'.
Configure OS Client Timezones:
- On all OS Client engineering stations and operator consoles, ensure the Windows Time Zone matches the physical plant location (e.g., UTC+01:00 or UTC-05:00).
- Ensure 'Adjust for daylight saving time automatically' is checked consistently across all operator PCs.

Verification

In SIMATIC Manager, select the CPU and press Ctrl + D: check the 'Time System' tab and verify that the CPU clock status is 'Synchronized' via NTP.
Trigger a test process alarm in CFC: observe the alarm entry in the WinCC Alarm List.
Verify that the alarm timestamp matches the operator console local clock within 1 second.
Open WinCC Redundancy status on the redundant OS pair: verify that both servers report 'Fault-tolerant mode' with zero synchronization errors.

Limitations and Operational Precautions

Never configure multiple conflicting time masters on the same network broadcast domain; doing so causes controllers and OS servers to oscillate between time sources, producing jumping timestamps in trend archives. Redundant server licenses must match across both nodes. Genuine system software and licensing should be procured and verified through an authorized Siemens distributor or the Siemens Industry Mall.

Engineer FAQ

Can redundant OS Servers run different Windows versions permanently?

No. Running different Windows versions on redundant servers is strictly unsupported by Siemens due to DCOM and SQL database replication incompatibilities.

Why does the controller use UTC time instead of local time?

UTC provides an absolute, monotonically increasing time reference that prevents duplicate or missing timestamps during daylight saving time transitions.