WinCC Redundant Server Pairs in Distributed Multi-Site Systems

1. Overview: Why You Cannot Add a Third Server to a WinCC Redundancy Pair

WinCC Redundancy, as shipped in every current Siemens release from WinCC V7.0 through V8.1, is a strict two-node hot-standby architecture. The constraint is documented in the WinCC Help node "Redundancy" and repeated in the Siemens Industry Online Support entry ID 109976723 - WinCC V8.1: Configuration and communication:

"The WinCC Redundancy system always consists of 2 servers. Thus, you cannot configure any other PCs as redundant PCs for the two redundant server PCs."

This is a design decision, not a defect. WinCC Redundancy is engineered to recover the loss of a single node inside a pair; it does not implement a 2-of-3 quorum, leader election, or shared-state replication across more than two participants. The synchronization protocol uses a single TCP connection between two named peers, exchanges a defined set of runtime objects (process tags, alarms, user archives, tag logging), and the surviving server continues to publish those values to all subscribed clients.

When the operational requirement is "lose any two nodes, keep operating," the answer is not "add a third server to the pair." The answer is to architect the system as a distributed client/server configuration in which each redundancy pair remains two servers, but the client projects subscribe to multiple pairs simultaneously. A single WinCC client can be configured to display views on up to twelve different redundant servers, with each redundant pair acting as an independent failover island. This article walks through the exact configuration steps, naming rules, and topology constraints that make a multi-pair, multi-site WinCC architecture behave the way plant operators expect.

2. The Two-Server Redundancy Model in WinCC RT Classic

In WinCC RT (the classic Explorer-based runtime that ships under the names WinCC V7.4 SP3, V7.5, V7.5 SP1, V7.5 SP2, and V8.0/V8.1), redundancy is configured per computer. Open WinCC Explorer on the master, right-click the "Computer" node, select "Properties," and on the "Redundancy" tab enter the partner computer name. The partner reciprocates: both servers must agree on the pairing before either will synchronize.

Configuration fields that must match on both sides:

Once paired, the two servers continuously exchange the following runtime objects:

• Process tag values (Tag Management)
• Alarm messages and their acknowledgement state
• Tag logging values, including those currently in the runtime buffer
• User archive rows and their modification timestamps
• Picture Tree selections and the active picture name

The synchronization interval is configurable under "Computer > Properties > Redundancy > Synchronization." Default values: process tag synchronization every 1 second, alarm state every 2 seconds, archive every 30 seconds. Reducing these intervals increases network load; the cumulative bandwidth of a single WinCC pair at default settings is typically between 200 kbit/s and 2 Mbit/s depending on tag count.

Failover detection on a healthy pair is sub-second for process tags (loss of partner TCP connection is detected via heartbeat, default 5 seconds). Archive resynchronization after a failover requires between 30 seconds and several minutes, depending on archive size. During resync, alarm insertion order is preserved; the surviving server backfills the gap in the alarm log by querying its partner when the partner returns.

3. The Distributed System: Up to Twelve Servers per Client Project

The same WinCC help text that declares the two-server rule immediately afterward explains how to build larger systems. From the WinCC V8.1 documentation (ID 109976723):

"In runtime, each client can display views on up to twelve different redundant servers, e.g. display messages from Server 1 and Server 2, display and write process values from Server 3, display pictures from Server 4, etc."

The limit of twelve is a WinCC client engineering constraint, not a server constraint. Each WinCC Server process on each PC is independent; what limits a single client is the number of server data sources declared in that client's project. You add sources under "Server Data" in WinCC Explorer or under "Connections" in the TIA Portal HMI device configuration of the client HMI device.

The practical implication for multi-site plants:

4. Server Prefix Naming: Why Every Server Must Have a Unique Prefix

WinCC resolves cross-server tag references through a server prefix. The syntax is ServerPrefix::Tagname where ServerPrefix is a short, unique identifier (typically 2-8 characters) that the WinCC server publishes to clients. When a client receives MCR::TankLevel, the runtime consults its server data table, finds which configured server owns prefix MCR, and resolves the tag against that server's tag management.

If two servers share the same prefix, clients cannot disambiguate, and the runtime will return values from whichever server happens to respond first - which is non-deterministic and unsafe for control-room display. The prefix must be:

• Unique across all servers visible to the same client project
• Identical between the master and standby of a redundancy pair (clients see one logical server behind the prefix; the runtime picks the live member of the pair)
• Configured under "Computer > Properties > General > Server Prefix" in WinCC Explorer
• Implemented on the HMI server side under "Runtime settings > General > Server prefix" in TIA Portal

Typical prefix conventions used in plant deployments:

Clients display the logical prefix MCRA, MCRB, SCRA, SCRB. The failover between MCRA_M and MCRA_S is invisible to the client because the client only references MCRA::TankLevel; the WinCC redundancy layer swaps which physical server supplies the value.

The configuration that makes this work on the client side is "Preferred server" under each server entry in the client's project. Set the preferred server to the local control room's master when the client is in the main control room, and to the standby control room's master when the client is in the standby control room. This bias accelerates recovery when the partner in the local room fails but the partner at the remote room is still healthy: the client prefers its local copy first, then falls back to the remote pair.

5. Multi-User System in TIA Portal (WinCC Professional / RT Professional)

WinCC Professional (also called RT Professional) integrated into the TIA Portal offers a different but compatible model: the multi-user system. In this architecture one or more HMI servers publish runtime data, and multiple HMI clients (WinCC RT Client) subscribe to those servers without holding their own copy of the project. The TIA Portal documentation defines the configurations at Multi-user system (RT Professional).

Key differences from WinCC RT classic:

• Project engineering is centralized in TIA Portal; all HMI devices (servers and clients) share one project file on the engineering station.
• HMI server devices are added under "Devices & Networks" with the device type "WinCC RT Professional."
• HMI clients are added similarly; their "Connections" editor binds them to one or more HMI servers.
• Redundancy for RT Professional is configured per HMI server under "Runtime settings > Redundancy" - the partner HMI server is selected from the project tree. Behavior is the same two-server model as classic WinCC.

In TIA Portal V17 and later, RT Professional supports the "Redundancy" runtime license option, and the partner is configured with a few clicks rather than through WinCC Explorer dialogs. The TIA Portal project compiles into separate runtime executables for each HMI device, deployed independently through the "Download to device" workflow. Once running, the two paired servers behave identically to a classic WinCC pair.

6. Designing the Two-Control-Room Topology

The canonical "main control room plus standby control room" architecture with full WinCC redundancy is shown below. This design pattern applies whether you use WinCC RT classic or WinCC RT Professional.

6.1 Server placement and licensing

6.2 Network requirements

Each redundancy pair requires a dedicated TCP path between the two partners. Recommended practices:

• Separate VLAN for the redundancy partner connection (so plant broadcast traffic does not interfere with the synchronization stream).
• Minimum 100 Mbit/s dedicated link; 1 Gbit/s recommended for large tag counts (>10,000 tags).
• Latency between the two peers should be below 50 ms RTT. Cross-room links typically satisfy this on plant fiber; WANs across cities often do not, in which case the standby room should be considered an independent pair with its own PLC connections rather than a true partner.
• Firewall rules must permit the configured redundancy port bidirectionally on the partner IPs only; deny on all others.
• All four servers should resolve each other's names via DNS; add static entries to C:\Windows\System32\drivers\etc\hosts as a fallback in case DNS is degraded during a failover event.

6.3 Client subscription strategy

Both MCR and SCR operators need to see the same data. Two configurations are valid:

1. Local-first: Each client configures its own pair as the preferred server, with the remote pair as secondary. This minimizes cross-room bandwidth in normal operation.
2. Symmetric: Both rooms' clients list all four servers equally. Simpler engineering, more cross-room traffic.

For dual control room standby operation, configuration (1) is preferred: under normal conditions each room runs on its own data, and only on failover does the standby room pull from the main room.

7. Step-by-Step Configuration Procedure

The procedure below uses WinCC RT classic (V7.x / V8.x). For TIA Portal RT Professional, the equivalent steps are reached through "Devices & Networks > HMI server > Runtime settings > Redundancy."

7.1 Prerequisites

• Four server-grade PCs with identical hardware (CPU, RAM, disk). Asymmetric pairs cause inconsistent archive performance.
• Windows Server 2019 Standard (or later) installed and patched on all four servers.
• Identical local administrator account (e.g., WinCCAdmin) on all four PCs with the same password. Configure through Local Users and Groups, not through Active Directory managed service accounts, to avoid permission drift.
• Plant network with the redundancy VLAN configured and ports open.
• NTP service pointing to a common time source on all four servers.
• WinCC installation media matching the version (e.g., V8.1 DVD or SIMATIC WinCC V8.1 setup).
• Licenses: 4x WinCC Server, 4x WinCC Redundancy option, plus RT Client licenses per operator station.

7.2 Configure server MCR-SRV1 (master of main pair)

1. Install WinCC V8.1 with the "WinCC Server" and "Redundancy" options checked.
2. Open the WinCC project on MCR-SRV1.
3. In WinCC Explorer, right-click "Computer" and select "Properties."
4. On the "General" tab, set Computer name to MCR-SRV1 and Server prefix to MCR.
5. On the "Redundancy" tab, check Activate redundancy, enter partner MCR-SRV2, and leave port 80 (HTTP) or 443 (HTTPS) as required by your firewall policy.
6. On the "Start-up" tab, add the WinCC service account under "Authorizations."
7. Save and close. Repeat the entire project on MCR-SRV2, SCR-SRV1, SCR-SRV2 - but adjust computer names and partner names accordingly.

7.3 Configure server MCR-SRV2 (standby of main pair)

1. Open the same WinCC project (copy from MCR-SRV1 first, or share the project folder with file-level replication).
2. Set Computer name to MCR-SRV2 and Server prefix to MCR (must match the master).
3. Set Partner to MCR-SRV1.
4. Save and close.

7.4 Configure server SCR-SRV1 (master of standby pair)

1. Open the SCR project (can be a different WinCC project from the MCR if it serves a different process area, or a copy with adjusted server prefixes).
2. Set Computer name to SCR-SRV1 and Server prefix to SCR.
3. Set Partner to SCR-SRV2.

7.5 Configure server SCR-SRV2 (standby of standby pair)

1. Set Computer name to SCR-SRV2 and Server prefix to SCR.
2. Set Partner to SCR-SRV1.

7.6 Configure each operator client

1. On each operator station, install the WinCC RT Client runtime.
2. Open the client project (or the shared project in TIA Portal).
3. Under "Server Data," add four entries: MCR-SRV1, MCR-SRV2, SCR-SRV1, SCR-SRV2. Each entry is configured with the server's IP, the prefix, and the redundancy-aware connection parameters.
4. For each server entry, set the Preferred server. On MCR clients, set MCR-SRV1 as the preferred server for the MCR pair and SCR-SRV1 as the preferred server for the SCR pair. Reverse for SCR clients.
5. Compile and download the client project. Activate runtime.

7.7 Configure alarm and archive redundancy

Beyond the basic pair, you must enable redundancy for each subsystem that contains stateful data:

• Alarm Logging: In the Alarm Logging editor, open the "Configuration" dialog and verify "Redundancy" is enabled. Defaults are usually correct.
• Tag Logging: Open each archive's properties and verify "Redundancy" is checked. Archive segments are replicated between partners; on failover the surviving server continues writing.
• User Archives: Enable redundancy per archive. Field-proven pitfall: large user archives with millions of rows can take 10+ minutes to resync after a long failover; size accordingly.

8. Verification and Commissioning Tests

Acceptance testing for a multi-pair WinCC architecture must demonstrate failover in each pair independently and verify that the client re-converges. The standard test sequence is:

8.1 Pair-level failover test

1. Both MCR servers running. Verify in WinCC Explorer "Redundancy" status indicator: both show "Master" and "Standby" correctly.
2. On the operator client, navigate to a screen that reads MCR::TankLevel. Note the value.
3. Pull the network cable from MCR-SRV1.
4. Within 5 seconds, MCR-SRV2 transitions to "Master." Verify by reconnecting a client session and observing the value remains unchanged.
5. Reconnect the cable. MCR-SRV1 returns as standby. Verify resync completes within the configured time.

8.2 Cross-pair client test

1. On the SCR operator station, open a screen showing both MCR::TankLevel and SCR::TankLevel.
2. Pull the network cable from MCR-SRV1 (now: MCR-SRV2 is the only survivor of the MCR pair).
3. Verify the MCR value on the SCR client continues to update from MCR-SRV2 without operator intervention.
4. Power down MCR-SRV2 as well (now: no MCR servers are running).
5. Verify the SCR client logs an alarm "Server MCR not reachable" and the SCR-related values continue normally from the SCR pair.

8.3 Archive continuity test

1. Trigger a known process event (e.g., a tank level crossing 50%) on the MCR pair.
2. Verify the alarm appears in the Alarm Logging view on both the MCR and SCR operator stations.
3. Failover MCR-SRV1 to MCR-SRV2.
4. Verify the historical tag logging view shows no gap across the failover time.

8.4 Performance baseline

Record before commissioning: CPU, RAM, network utilization, archive write latency, alarm insertion rate. These become the baseline against which future failure modes are compared. Typical target numbers for a 5,000-tag project with 10 archives on a four-core Xeon at 2.5 GHz:

9. Licensing, Operating System, and Hardware Constraints

10. Troubleshooting Matrix

11. Field-Proven Notes and Caveats

Time synchronization is non-negotiable. WinCC uses the system clock for archive timestamps and alarm ordering. If two servers drift more than 1 second apart, archive continuity breaks across failover. Configure all servers to point at the same NTP source and verify with w32tm /monitor before commissioning.

Use identical service accounts. WinCC replicates files between partners using the service account credentials. If the account differs in name or password between partners, file replication silently fails and the failover surfaces as missing picture files or broken alarm views.

Avoid cross-WAN redundancy. WinCC Redundancy tolerates at most ~50 ms RTT between partners. For geographically distant rooms, prefer the multi-pair architecture: each room is its own pair, and clients subscribe to both pairs rather than running one pair stretched across the WAN. The synchronization protocol was not designed for high-latency links, and recovery behavior becomes non-deterministic above the latency limit.

The 12-server client limit is a per-project limit. If the plant grows beyond 12 servers in a single client view, split the operator stations. The most common pattern is one client project per process area, with a higher-level SCADA (WinCC OA, SIMATIC PCS 7, or a third-party system) aggregating above them.

Tag Logging resync can be slow. After a long outage, the surviving server must replay its partner's archive backlog. For projects with multi-gigabyte archives, this can take hours. Pre-size the archive partition with 2-3x the expected steady-state consumption to leave headroom for backlog.

Picture Tree failover is automatic. The picture tree selection state is replicated, so an operator who has drilled into a sub-picture on the master and then fails over to the standby will see the same sub-picture after recovery. This is one of the few stateful pieces of information that survives failover seamlessly.

OPC UA redundancy is version-dependent. In TIA Portal V18 / V19, the WinCC Professional OPC UA Server is published from both members of a pair; clients with OPC UA redundancy awareness pick the live server. Older releases expose only one OPC UA endpoint at a time. Verify your release's OPC UA redundancy behavior against the TIA Portal release notes.

Server project file replication. WinCC Redundancy does not replicate the project file (the .mcp for classic or the TIA Portal project). You must keep both project copies byte-identical through an out-of-band mechanism: robocopy scheduled task, DFS Replication, or a shared project folder on a SAN. Treat the project as code; do not let engineers edit one copy and forget to push to the partner.

Anti-virus exclusions. Add the WinCC project folder, the WinCC archive folder, and the WinCC service executables to the anti-virus exclusion list on both partners. Real-time scanning of the archive database files causes intermittent I/O stalls that WinCC interprets as partner loss and triggers spurious failovers.

FAQ