Risks and Timing Constraints of Delayed Entire Downloads to Redundant OS Servers in PCS 7

In SIMATIC PCS 7, performing an 'Entire Download' to the Standby OS Server (Server 1B) and intentionally delaying the download to the Master OS Server (Server 1A) by two days violates core DCS high-availability principles and should not be executed. During the delay, the two servers run divergent project database schemas, tag dictionaries, and alarm structures, which causes the WinCC Redundancy synchronization agent to fail with critical errors (@RedundancyState = 4). Furthermore, if Server 1B becomes Master, Server 1A cannot synchronize, and OS Clients will display contradictory process data. The verified Siemens methodology is to download the Standby server, perform a brief verification (30 to 60 minutes), switch roles, and promptly download the second server.

Executive Summary

During major DCS human-machine interface revisions or software upgrades, plant engineers frequently seek cautious commissioning strategies to validate newly compiled graphics, scripts, and alarm configurations before committing them plant-wide. A common proposition is downloading the entire OS project to the Standby OS Server (Server 1B) while leaving the Master OS Server (Server 1A) running the legacy project for several days to 'make sure Server 1B is working properly'. Siemens official documentation explicitly warns that 'both partners should always be downloaded promptly'. This article details the severe technical hazards of running asynchronous redundant OS servers, analyzes how WinCC Redundancy handles divergent SQL schemas, and presents the approved, low-risk switchover procedure for redundant server downloads.

Architecture and Fundamental Mechanics

WinCC Redundancy Architecture, Database Synchronization Integrity, and Dual-Schema Failure Mechanics:

Core Requirement of Redundancy Consistency:
A PCS 7 redundant OS server pair operates as a unified fault-tolerant data entity.
Both servers maintain active Microsoft SQL Server databases (CC_..._M and CC_..._R).
The WinCC Redundancy agent (CCRedCom.exe) continually verifies database consistency, synchronizing messages, process value archives, and user archive tables across the Terminal Bus / Redundancy LAN.
Failure Cascade Triggered by a Delayed Entire Download:
Phase 1: Downloading Standby Server 1B:
- An Entire Download deletes the existing SQL database on Server 1B and replaces it with the newly compiled engineering database.
- Server 1B now possesses new tag definitions, modified alarm texts, updated script libraries, and altered archive tables.
Phase 2: Database Schema Divergence (The Two-Day Delay):
- Server 1A continues executing the old project database.
- CCRedCom.exe attempts periodic synchronization between Server 1A and Server 1B.
- Because the internal tag IDs, message IDs, and archive schemas differ, synchronization encounters fatal SQL foreign-key and table index conflicts.
- The redundancy agent enters a faulted state: @RedundancyState changes to 4 (Fault / Redundancy Error).
Phase 3: Client Inconsistency and Data Loss:
- Dedicated OS Clients establish connections to preferred servers. Clients connected to Server 1A display old graphics and missing tags; clients connected to Server 1B display new graphics.
- If Server 1A experiences a hardware failure during the two-day delay, Server 1B takes over, but all historical alarms and trend data logged on Server 1A during those two days can NEVER be synchronized to Server 1B, creating an unrecoverable regulatory data gap.

Step-by-Step Implementation Procedure

Approved Staged Download Procedure for Redundant OS Servers:
* Identify the active roles: verify on WinCC that Server 1A is Master (@RedundancyState = 1) and Server 1B is Standby (@RedundancyState = 2).
* In SIMATIC Manager on the ES, execute a full OS compile (Entire OS with Tags and messages).
Step 1: Download to Standby Server (Server 1B):
* Right-click the OS Standby node (OS_Server_1B) -> PLC -> Download.
* Select Entire OS.
* The project files are transferred and the new database is attached on Server 1B.
* Start WinCC Runtime on Server 1B.
Step 2: Verification and Controlled Switchover (Window: 30 to 60 Minutes):
* Log into Server 1B locally or connect a dedicated test OS Client pointing to Server 1B.
* Verify that process graphics, faceplates, and tag values display correctly without communication errors.
* Deactivate WinCC Runtime on Server 1A (or use the WinCC redundancy switchover utility).
* Server 1B automatically becomes Master (@RedundancyState = 1), smoothly servicing all plant operator clients.
Step 3: Prompt Download to Server 1A:
* Once Server 1B has been verified under live operator control for 30 to 60 minutes, immediately proceed to download Server 1A.
* Right-click the OS Master node (OS_Server_1A) -> PLC -> Download.
* Select Entire OS.
* Start WinCC Runtime on Server 1A.
* Server 1A initializes as Standby (@RedundancyState = 2).
* The redundancy synchronization agent engages: @RedundancyState transitions to 3 (Synchronizing) and cleanly returns to 2.
* Redundancy is fully restored with 100% database consistency.

Verification

Verify in WinCC Explorer on Server 1A and Server 1B that @RedundancyState indicates 1 (Master) and 2 (Standby).
Inspect the Windows Application Event Log and WinCC diagnostic log (WinCC_Sys_01.log); confirm zero redundancy synchronization errors.
Test failover: toggle connection on Server 1B; verify seamless transfer to Server 1A without operator screen freezes.

Limitations and Operational Precautions

Never perform an Entire Download directly to the active Master OS Server while operators are actively controlling the plant, as deactivating the master will disrupt client communication unless the Standby server is already prepared. If changes between versions are minor, use 'Download Changes' (Delta Download), which updates both servers synchronously while Runtime remains active.

Engineer FAQ

Why does Siemens recommend downloading redundant OS partners promptly?

Because running divergent project databases causes SQL schema conflicts, disables archive synchronization, and leads to contradictory client displays.

What happens if I delay downloading the master server by two days?

The redundancy agent faults (@RedundancyState = 4), clients display conflicting data, and historical data logged during the delay cannot synchronize.