Configuring WinCC V7.5 Redundant Server Network Adapters

Overview

SIMATIC WinCC V7.5 redundant server pairs depend on three logically distinct network paths to deliver deterministic partner monitoring, fail-safe client redirection, and continuous process visibility. The three paths are the plant bus (PLC / field connection), the terminal bus (server-to-server and server-to-client WinCC station traffic), and the dedicated redundancy link (point-to-point heart-beat between the two WinCC servers).

Conflating these paths onto a single NIC, a single VLAN, or a single IP subnet is the most common architectural mistake when commissioning a WinCC redundant pair. Siemens engineering documentation for WinCC V7.5 explicitly calls for a dedicated network adapter for the redundant partner connection, and the configuration of that adapter is performed out-of-band through the SIMATIC Shell rather than through the WinCC project. The setting persists in the Windows registry and is preserved when a target PC is reloaded from an engineering station.

This reference covers the architectural rationale, the SIMATIC Shell procedure, the project duplicator behavior, switch and Scalance considerations, OPC redundancy interaction, commissioning verification, and a troubleshooting matrix for the most common field failures.

Architectural Rationale: Why Three Adapters

A WinCC V7.5 redundant server is a hot-standby pair. Both servers run a fully loaded WinCC project. The preferred server accepts process connections, archives tags, and serves clients. The standby server continuously receives the same archive and tag state through the redundancy mechanism. The status of the partner is exchanged over a dedicated socket pair that is bound to a specific network adapter on each server.

The architectural rules are:

1. Plant bus adapter — connects to PLCs / field devices (S7, S7-400H, S7-1500R/H, PROFINET, PROFIBUS). Carries process data only.
2. Terminal bus adapter — connects WinCC clients, WinCC servers (the redundant pair) and any third-party SCADA stations. Carries WinCC operator control, alarm, and archive traffic.
3. Redundancy link adapter — carries only the partner status and synchronization telegrams between the two WinCC servers. No PLCs, no clients, no engineering traffic.

Each adapter must sit in a different IP subnet. The three subnets must not overlap, and the routing tables on each server must be set up so that traffic to a partner's IP returns out the same adapter it arrived on. This is the source of the most common commissioning question: must the redundancy link be configured on both servers? The answer is yes — the binding is per-server, not propagated by the project.

Why Subnet Separation Matters

When the plant bus, terminal bus, and redundancy link share an IP subnet, several failure modes appear that are extremely difficult to diagnose in operation:

Recommended IP Layout

The redundancy link is frequently sized as a /30 or /31 subnet to make the intent self-documenting: only two addresses exist, one per server. Some sites use a back-to-back crossover cable between the two servers' redundancy NICs, eliminating the switch entirely. This is the highest-availability option because it removes the switch as a single point of failure on the partner-monitoring path.

Configuring the Redundancy Link in SIMATIC Shell

The redundancy link is bound to a network adapter through the SIMATIC Shell, which is a Siemens Windows Shell extension installed with WinCC. The binding is stored in the Windows registry under the WinCC redundancy key, not inside the WinCC project file. This is the engineering reason the binding survives a project download from the engineering station.

Prerequisites

• WinCC V7.5 (or V7.4 SP3 / V7.4) installed on both servers
• Local administrator rights on each server
• All three NICs installed, driver-loaded, and link-up
• TCP/IP addresses assigned and pingable on the same subnet for each pair
• WinCC services stopped during the configuration (recommended)

Procedure (per server)

1. Open SIMATIC Shell from the Windows desktop. Right-click the WinCC server icon in the system tray and choose SIMATIC Shell > Settings, or launch it from Start > Siemens Automation > SIMATIC > SIMATIC Shell.
2. In the SIMATIC Shell dialog, navigate to the Redundancy tab.
3. Enable the option Connection to redundant partner via network adapter.
4. Select the Static option for the partner connection mode (recommended for deterministic partner selection).
5. From the network adapter dropdown, select the NIC bound to the redundancy link subnet (in the example above, the adapter carrying 192.168.30.11 on Server A).
6. Enter the partner computer name or the partner redundancy IP. Use the partner's redundancy link IP, not the terminal-bus IP.
7. Click Apply and confirm the registry write. SIMATIC Shell writes to HKLM\SOFTWARE\Siemens\WinCC\Redundancy.
8. Repeat steps 1–7 on Server B, binding to Server B's redundancy NIC (192.168.30.12) and pointing at Server A's redundancy IP.
9. Start the WinCC services and verify the partner status in WinCC Explorer — the redundancy icon must show green on both servers within 30 s.

Reference: SIMATIC HMI WinCC V7.5: How to configure the redundant servers.

Project Duplicator Behavior

The WinCC Project Duplicator creates a copy of the WinCC project for the standby server. It adjusts the computer name, the redundancy role, and several server-specific tag prefixes. It does not alter the SIMATIC Shell binding, because that binding is per-target-PC and lives in the registry.

This produces the following observed behavior that surprises many engineers:

• Immediately after duplication, the new standby server appears to be redundant with the original — because both servers inherited the default binding (the first NIC in the binding order, or the terminal-bus NIC if the engineer did not pre-configure SIMATIC Shell).
• After a project reload from the engineering station, the binding is still preserved on the target — because the registry is not touched by the project download.
• If the engineer later changes the SIMATIC Shell binding on one server but not the other, the pair becomes asymmetric: Server A monitors Server B on the correct NIC, but Server B monitors Server A on the wrong NIC. Failover still appears to work in steady state but is non-deterministic under load.

Network Switch and Scalance Considerations

Most production sites use a managed switch (commonly a Siemens SCALANCE XC/XB/XR family) for the redundancy link rather than a crossover cable. The Scalance family supports VLAN tagging, IGMP snooping, and port mirroring — all of which are useful when commissioning and troubleshooting a redundant pair.

VLAN assignment

Assign the redundancy link ports to a dedicated VLAN. Do not share the VLAN with the terminal bus or the plant bus. On Scalance XC-216, configure the redundancy ports as untagged access ports of a VLAN that exists only on those two ports.

Spanning tree

If the redundancy link is a single cable between two Scalance switches (redundant ring topology), enable Rapid Spanning Tree Protocol (RSTP) on the relevant ports. If the redundancy link is a direct cable between the two servers (crossover or through a small dedicated switch), disable STP on those ports to avoid the 30–50 s re-convergence window blocking partner heart-beats after a topology change.

QoS / Priority

Mark the redundancy UDP packets with a fixed DSCP value (WinCC uses a fixed port range; see below) and apply a strict-priority queue on the Scalance. The redundancy partner-monitoring protocol is intolerant of jitter beyond a few hundred milliseconds.

Port mirroring

During commissioning, mirror the redundancy port on the Scalance to a laptop running Wireshark. The captured traffic is unencrypted UDP and reveals the partner state machine directly. This is the fastest way to confirm the SIMATIC Shell binding is in effect.

WinCC Redundancy Ports and Protocol

The WinCC redundancy partner-monitoring protocol uses a small, fixed set of UDP and TCP ports. Allow these in any host firewall between the two servers.

OPC Redundancy Interaction

Many WinCC sites expose tag data to a higher-level MES, historian, or third-party SCADA via OPC. When the underlying WinCC pair is redundant, the OPC client must also be configured to follow the failover. Two patterns are common:

1. OPC DA with redundant server connection strings — the OPC client lists both WinCC server OPC DA endpoints; the client driver takes the first responsive endpoint. Reconnection time depends on the client driver's polling interval.
2. OPC UA with redundant endpoint URLs — the OPC UA client is configured with both server URLs and a discovery URL pointing to a redundancy broker. Failover is faster than OPC DA but requires the WinCC OPC UA server to be licensed on both partners.

A practical consideration: the OPC client's view of "the server" must be the WinCC preferred server's tag namespace. If the OPC client connects to the standby and the standby's archive is not yet current, historical reads return gaps. Configure the OPC client's failover threshold to match the WinCC archive sync interval, not a hard-coded 5 s.

Further reading on OPC redundancy trade-offs: OPC Redundancy Questions & Answers (Software Toolbox).

Verification and Commissioning Procedure

After SIMATIC Shell configuration and project deployment, perform the following checks before handing the redundant pair to operations.

Layer 3 verification

1. From Server A, ping -t 192.168.30.12 on the redundancy NIC. Verify the route is via the redundancy adapter using tracert.
2. From Server B, ping -t 192.168.30.11 on the redundancy NIC.
3. Confirm no firewall is blocking the WinCC redundancy ports (see table above) using Test-NetConnection -Port 5001 192.168.30.12 in PowerShell.

SIMATIC Shell verification

1. On both servers, open SIMATIC Shell and confirm the partner computer name resolves to the redundancy IP, not the terminal-bus IP.
2. Inspect the registry key HKLM\SOFTWARE\Siemens\WinCC\Redundancy. The value PartnerAdapter must contain the GUID or friendly name of the redundancy NIC.

WinCC Explorer verification

1. Open WinCC Explorer on both servers. The redundancy icon (two interlocking arrows) must be green within 30 s of service start.
2. Click Redundancy > Status on each server. Confirm Partner state = Connected, Sync state = Synchronized, Archive sync lag < 5 s.

Failover test

1. With the process in a safe state, stop the WinCC service on Server A (preferred server).
2. On Server B, confirm promotion to preferred within 10 s.
3. Confirm connected clients are redirected to Server B and operator screens reload within 30 s.
4. Restart Server A. Confirm it rejoins as standby and the archive re-syncs within 60 s.

Network-level failover test

1. With the process in a safe state, disconnect the redundancy NIC cable on Server A.
2. Confirm Server A continues to serve the plant bus and terminal bus, but logs a redundancy partner loss event.
3. Reconnect the cable. Confirm partner re-establishment and archive re-sync.
4. Repeat with the terminal bus cable disconnected. Server A must continue; clients must reconnect to Server B; archive sync must continue.
5. Repeat with the plant bus cable disconnected. Both servers must remain in standby mode, no failover triggered (no process is at risk, no client is at risk).

Troubleshooting Matrix

Common Pitfalls

The following items are the highest-frequency commissioning mistakes observed in field deployments.

• Same NIC for terminal bus and redundancy — works in the lab, fails under production traffic.
• SIMATIC Shell binding configured on only one server — produces asymmetric partner monitoring; failover is non-deterministic.
• Redundancy link routed through a layer-3 hop — adds latency and a single point of failure. The link should be layer-2 adjacent.
• Spanning tree enabled on a direct server-to-server crossover — blocks traffic for 30–50 s after any link flap.
• Firewall rule created on one server but not the other — partner can be reached one-way only; heart-beat timeouts.
• DNS used to resolve partner name on the redundancy link — a DNS outage then breaks redundancy. Use the partner IP directly in SIMATIC Shell.
• Project Duplicator run with the wrong redundancy role — both servers think they are preferred; clients see two competing preferred servers.

Checklist Before Going Live

1. Three NICs installed, drivers current, link-up on both servers.
2. Three subnets assigned, non-overlapping, statically configured (no DHCP on these NICs).
3. SIMATIC Shell configured on both servers, partner IP and adapter verified.
4. Registry key PartnerAdapter inspected and matches the redundancy NIC on both servers.
5. Windows Firewall rules allow the WinCC redundancy port range in both directions.
6. Managed switch: redundancy VLAN created, STP disabled (or RSTP configured correctly), QoS priority applied.
7. Layer-3 ping test passed from each redundancy NIC to the partner.
8. WinCC Explorer partner status green on both servers.
9. Archive sync verified at steady state; archive sync lag < 5 s.
10. Service-stop failover test passed; clients redirected within 30 s.
11. Network-cable failover tests passed for each of the three paths independently.
12. OPC client failover test passed; clients re-establish within configured retry window.

FAQ