Configuring WinCC 6.2 Redundant Server-Client Architecture with SIMATIC Manager Step 7

Building a fault-tolerant HMI layer for a plant that cannot tolerate visualization downtime requires a redundant WinCC server pair feeding one or more client stations. This article walks through the full configuration sequence for WinCC 6.2 (SP2/SP3 era) coupled with SIMATIC Manager Step 7 V5.5, the configuration the original question was about. The procedure differs from the PCS 7 path because the user explicitly stated they are running Step 7 + WinCC 6.2 and not the PCS 7 engineering suite. Where the source material is ambiguous (e.g. what exactly is meant by a "client backup"), the article calls out the ambiguity and shows the correct engineering path rather than guessing.

1. Redundant Client-Server Model: Concept Review

A redundant client-server visualization layer consists of three logical roles:

• AS (Automation Station) — the S7-300 / S7-400 PLCs, the only true source of process truth.
• Server pair — two WinCC Runtime stations running the same project. One is the Master, the other is the Standby. Both hold a mirror of the runtime database, alarm log, and tag archive.
• Client(s) — WinCC Runtime stations (or WinCC/Web Navigator clients) that read process data and alarms from a server. A client always nominates a preferred server and switches to the partner on failover.

The dashed mirror link between Server 1 and Server 2 is the redundancy channel. The solid arrows are the S7 connection to the AS and the WinCC client-server connection. On Master failure the Standby promotes itself and accepts the same client connections within a few seconds; on client side, the connection simply retries and resolves to the new master.

2. Prerequisites

3. Engineering the Project in SIMATIC Manager

Open SIMATIC Manager and create or open the STEP 7 project that owns the AS programs. The WinCC OS lives inside the STEP 7 project tree as a child of a PC station, which is what allows a single download to populate both the S7 program and the WinCC project on the target PC.

1. Right-click the project, choose Insert New Object > SIMATIC PC Station. Create one PC station for WINCC_SERVER_1 and a second for WINCC_SERVER_2. Add a third PC station for each client (WINCC_CLIENT_1, WINCC_CLIENT_2).
2. Open each server PC station, insert a WinCC Application object. Assign one to OS = Server 1, the other to OS = Server 2.
3. Open the Hardware catalog and add an IE General or vendor-specific network adapter to each PC station. Set IP addresses and subnet consistent with the plant LAN. The client PC station must also have its IE General configured, since the WinCC project stores the server connection at project-generation time.
4. Configure the S7 connection: in the AS, use NetPro to add an S7 connection from the AS to each WinCC server PC station. Use different connection IDs (e.g. 1 for Server 1 and 2 for Server 2) so the same DBs are read through independent paths.

4. Configuring the Redundant Server Pair in WinCC Explorer

Open WinCC Explorer on the engineering station and load the OS = Server 1 project (this is done by right-clicking the WinCC Application and selecting Open Object). The project that opens is the server project; you will later point the redundant partner at the second PC station.

1. In the navigation tree, right-click the Redundancy node and open its properties.
2. Set Redundant partner server to the computer name of the standby server (e.g. WINCC_SERVER_2). Use the FQDN only if DNS is reliable; otherwise use the NetBIOS name and ensure a matching entry exists in the local hosts file on each server.
3. Configure the synchronization parameters. The defaults that ship with WinCC 6.2 are conservative; tighten them only after stress testing:

4. Save and close. Repeat the configuration on the second server, swapping the Redundant partner server to point at Server 1. The two configurations must be mirror images.
5. Open the Computer node on each server and set Startup to WinCC Runtime. Confirm that the Autostart list contains the redundancy service.

5. OS Server Assignment and Server Data Generation

OS server assignment in WinCC 6.2 is the mechanism that turns a generic WinCC project into one that knows which server is Server 1, which is Server 2, and which clients are allowed to subscribe.

1. Open the server project in WinCC Explorer. Right-click Server Data and choose Configure.
2. In the assignment dialog, list every WinCC station in the system and select the role: Server, Server (Standby), or Client. Order matters: the first server listed becomes the initial Master unless overridden in step 4 of section 4.
3. For each client, enter its computer name and the project path on the server that will serve it, e.g. \\WINCC_SERVER_1\WinCC_Projects\Plant\. The standby path is filled in automatically when the standby row is defined.
4. Click Generate. WinCC writes a server-side configuration that tells the Master which clients to expect, and a client-side stub that tells each client which servers to try.
5. Open the OS = Client project in WinCC Explorer. In Server Data the names entered in step 3 should appear; if they do not, the client PC station in SIMATIC Manager was not given a WinCC Application of type "Client" — fix the project type and regenerate.

6. Building and Downloading to Each PC Station

SIMATIC Manager's PC-Station download model is the cleanest way to push a consistent project to all four machines in one go.

1. Right-click the WINCC_SERVER_1 PC station and choose Download to Target System > Selected Station. The S7 program (if any) and the WinCC project are written. Repeat for Server 2 and each client.
2. On the engineering PC, in WinCC Explorer, right-click Server Data on the server project and choose Download. This populates the dynamic server/client binding that the SIMATIC download does not handle.
3. Reboot each PC in this order: Server 1, Server 2, then the clients. A staggered boot prevents two WinCC instances from fighting for the Master role on cold start.

7. Client-Side Configuration and Failover Behavior

A client never holds authoritative data — it is a thin read-only subscriber. Its job is to:

1. Resolve both server names at startup.
2. Connect to the Preferred Server defined under Server Data.
3. If the connection is lost or no life-sign is received within the redundancy monitoring window, mark the preferred server as Failed and try the second entry in the server list.
4. Continue reconnect attempts to the failed server in the background; the first one to come back wins and the client transparently returns to it (unless the system was configured for "stay on current master").

Total detection-and-switchover time at the client is bounded by:

T_failover ≤ T_life_sign × retries + T_reconnect

With default settings, expect 3–5 s to declare the master down, plus 1–3 s for the client to establish the new connection. Plan operator screens for a worst-case switchover of ~8 s. Lossless alarm transfer is the redundancy's job; lossless screen-state transfer is not — graphic dynamization will repaint from the new server's mirror.

8. Verification and Commissioning Procedure

Walk the following test sequence on the live system before sign-off. Each step assumes a running plant and a working S7 connection.

1. Process-data round-trip. Force a tag in the AS via STEP 7 VAT. Confirm it updates on Server 1, on Server 2 (mirrored), and on both clients. Lag on Server 2 should be within the configured online synchronization interval.
2. Alarm round-trip. Trigger a low-priority alarm from the AS. Confirm it appears on the alarm list of all four stations, in identical time-stamped order.
3. Archive continuity. Stop Master (Server 1) gracefully via WinCC > Runtime > Stop. Verify the Standby promotes, clients reconnect, the new master continues the archive, and the old master, on restart, requests the missing archive range from its partner.
4. Hard-fail simulation. Pull the power cord on Server 1. The life-sign timeout should fire within the configured window; the Standby should promote; clients should reconnect.
5. Network-isolation simulation. Block the TCP port used by the redundancy service (default 443 or the dedicated WinCC redundancy port) between the two servers. Confirm same behavior as step 4.
6. Return-to-master. Restore Server 1. If return-to-master is enabled, confirm the original ownership reverts and clients migrate back without a process-visible gap.
7. Client-only failure. Reboot one client while the server pair keeps running. The client should reconnect to its preferred server with no error visible to the operator other than a brief loss of display.

9. Redundancy Status and Event Codes

WinCC 6.2 logs redundancy events to the Windows Event Log under Source = WinCC and to the GFile internal log. The events that matter for commissioning are:

10. Troubleshooting Matrix

11. Performance and Sizing Considerations

Redundancy roughly doubles the server-side CPU and memory load compared to a single server because every process-value change is mirrored. Field rules of thumb for WinCC 6.2 era hardware:

• Server pair total tag count: stay below 8,000 external tags combined. Above this, the synchronization channel becomes the bottleneck on 100 Mbit/s LAN.
• Alarm throughput: 50 alarms/s sustained, 200/s peak. Archive resync after a long partition can back up the redundancy service.
• Network: dedicate a 1 Gbit/s link between the two servers for the mirror channel if the system exceeds 2,000 tags or has heavy archive traffic. The path can share a managed switch with QoS, but must not be on a port that is also used for client traffic.
• Disk: archives on both servers should have at least 20 % free space, since archive resync writes temporary data and a full disk silently breaks resync.