Configuring WinCC Redundant Runtime Clients on Multi-User Servers

Overview

A common WinCC architecture problem is running a visualization with a redundant WinCC server pair serving only web clients, then needing to add one or more runtime clients for an operator control room with multiple monitors per station. Because each monitor can be tied to its own runtime window (or to a web browser instance), plant engineers frequently try to save WebClient licenses by using WinCC Runtime instead of WebClient on each monitor PC.

The two engineering constraints that drive this design are:

• License economics: A single WinCC Runtime license on a control-room PC can drive four monitors from one station, while WebClient licenses are counted per concurrent browser session.
• Failover behavior: The runtime clients must automatically switch to the surviving partner server when one server fails, without operator action.

Both constraints are satisfied by converting the existing single-user project to a multi-user server project, configuring a redundant server pair, and adding a multi-client (runtime client) that participates in the redundant server failover. The conversion cannot be performed online; runtime must be stopped on the affected stations during the structural change.

Architectural Prerequisites

Before reconfiguration, verify the existing topology against the requirements below. Items marked required block progress if missing.

License Model and Sizing

WinCC Professional / RT Professional separates runtime licensing from the connection topology. The license items that matter for a redundant server + N runtime clients layout are:

• WinCC RT Server (6AV2 105-....): Required on each redundant server. The redundancy license (WinCC Redundancy) is included with the server license above V16, but confirm the option key on the license container.
• WinCC RT Client (Powerpack or standalone): Per concurrent client station. The multi-client uses one RT Client license regardless of how many monitors the station drives, because the client PC runs one RT session.
• WinCC WebClient: Per concurrent web browser session. Each browser tab/window counts as one client. The WebNavigator option on the server side is licensed separately.
• WinCC WebServer: Activates the WebNavigator publishing role on a station. A multi-client can also act as a webserver, which is the recommended pattern when WebClient sessions are still needed alongside the new RT clients.

Sizing Example (8 monitors across 2 PCs)

Assume: 2 redundant servers, 2 control-room PCs each with 4 monitors, and 10 existing web clients from remote users.

If the control-room PCs are configured as multi-clients and webservers, they can host both the 4-monitor runtime view and 5 browser sessions each, while the 10 existing remote WebClient licenses continue to be served by the server pair (or by the multi-client/webserver PCs if preferred).

Conversion Path: Single-User to Multi-User Project

The current project is a single-user project on a single WinCC station. The runtime client addition requires the project type to be changed to a multi-user (server + client) project. The conversion is a structural operation that affects the project directory, the HMI device list, and the runtime database layout.

Pre-Conversion Backup

1. Stop Runtime on the WinCC station.
2. Close WinCC and the TIA Portal completely.
3. Copy the entire project folder (including the .apXX file, IM folder, Logs folder, and System folder) to a backup location. Verify checksum.
4. Export the WinCC project archive from TIA Portal: Project → Archive → TIA Portal project archive (.zapXX).
5. Document all S7 connections, tag prefixes, and scheduled tasks. These will be referenced when you re-author them on the redundant partner.

Step-by-Step Conversion

1. Open the project in TIA Portal.
2. In the project tree, locate the HMI device (the existing single-user station).
3. Right-click the HMI device and open Properties → General → Type.
4. Change the device type from WinCC RT Professional (single-user) to WinCC RT Professional (server).
5. Confirm the conversion wizard. The wizard removes single-user-only objects (local pictures, local scripts not bound to a server context) and prepares the project for a server role.
6. Compile the HMI station fully. Address any compile errors before proceeding; these are typically missing tag prefixes or scripts that referenced local files.
7. Add a second HMI device of type WinCC RT Professional (server) to the project. This second device will become the redundant partner.
8. Open Properties → Redundancy on both server devices and enable Redundant operation. Set the partner IP address and partner computer name on each side.
9. Configure the redundancy heartbeat interval (default 1 s) and the failover trigger conditions (typically loss of partner heartbeat beyond N seconds or loss of all S7 connections).
10. Add a third HMI device of type WinCC RT Professional (client). This is the multi-client that will run in the control room.
11. On the client device, set Properties → Runtime → Server assignment to point to both redundant servers by name.
12. On each server, add a server-prefix for this client. The server prefix ensures the client reads the correct tag namespace from whichever server is currently the master.
13. Compile all three devices. Download to each target station.
14. On the client station, enable WinCC Webserver if WebClient sessions are also required from this PC.

Redundancy Behavior and Failover

With the configuration above, WinCC Redundancy implements a hot-standby pair. The runtime behavior is:

The client automatically follows the master. No operator action is required when one server fails. The client connection drops briefly during the failover window; open picture windows will re-establish on the new master. Persistent alarms and logged data are preserved by the server that survived.

Configuring the Start Screen and Server Assignment

On the WinCC server, in Runtime settings → General, select a picture (e.g., Start.pdl) as the Start screen. The start screen is what the multi-client displays when it launches the connection to the server. Configure the same start screen on both servers to avoid different opening views after failover.

On the multi-client, the server assignment is configured per device:

1. Open the client device in TIA Portal.
2. Navigate to Properties → Runtime settings → Server.
3. Add both servers (Server A and Server B) to the Server list.
4. Set Preferred server to Server A (the primary master).
5. Enable Automatic switchover in the event of server failure. This is enabled by default but verify it is checked.
6. Set the failover timeout (default 5 s). Tune based on network quality; lower values trigger earlier switchover but increase false positives on brief network blips.

Multi-Client as Webserver

The recommended pattern when the multi-client is added to a redundant pair that previously only had web clients is to make the multi-client act as a webserver. This keeps web-client sessions on a station that is local to the control-room PCs, reducing load on the server pair. The architecture becomes:

• Server A / Server B: Hold the S7 connections, run the project, mirror each other for redundancy.
• Multi-client PC: Connects to the active server (A or B) via WinCC client connection, serves 4 monitors, and also publishes a WebNavigator endpoint for browser sessions.

To configure the multi-client as webserver:

1. On the multi-client device in TIA Portal, open Properties → Runtime settings → WebNavigator.
2. Enable WinCC Webserver.
3. Configure the HTTPS certificate (self-signed for testing, CA-issued for production).
4. Set the WebClient port (default 80 for HTTP, 443 for HTTPS).
5. Configure the WebClient license count on the multi-client station (the 5 sessions per PC in the example above).

When the server fails, the multi-client's webserver role is unaffected because it sources its data from whichever server is currently master. Browser sessions will see a brief disconnect, then reconnect automatically if the client supports it (most do, after a page refresh).

Verification Procedure

After commissioning, verify each behavior with a controlled test:

1. Startup test: Boot both servers, then the multi-client. Confirm the multi-client connects to Server A (preferred) within 10 s. Confirm the start screen displays on all four monitors.
2. Tag read test: From the multi-client, change a tag value (e.g., a motor speed setpoint). Confirm the value persists on Server A and that the multi-client's screen reflects the change within the configured update cycle (default 1 s).
3. Failover test (planned outage): Stop Runtime on Server A using the WinCC system tray icon. Within the failover timeout, confirm the multi-client switches to Server B. Verify open screens refresh with current values. Verify alarms are still logged.
4. Failover test (hard outage): Pull the network cable on Server A or power-cycle the server. Repeat step 3. Confirm the multi-client recovers automatically.
5. Recovery test: Bring Server A back online. Confirm it re-enters standby and resyncs from Server B. Confirm the multi-client does not switch back to Server A (master retention).
6. WebClient test: From a separate PC, open a browser to the multi-client's webserver URL. Log in. Confirm picture navigation works. Repeat the failover test and confirm the browser session reconnects after a manual refresh.
7. License test: On the License Viewer (Automation License Manager), confirm all server and client licenses are correctly assigned and not floating back to the license pool.

Troubleshooting Matrix

Online Change Limitations

WinCC RT Professional does not support online changes to the project type (single-user ↔ multi-user), to redundancy settings, or to the server/client topology. These are structural changes that require:

1. Stopping Runtime on every station involved.
2. Making the change in TIA Portal.
3. Recompiling all affected devices.
4. Downloading to each target station.
5. Restarting Runtime in the correct order: servers first, then clients.

However, runtime changes to pictures, tags, scripts, and alarms can be downloaded online to a running server (and replicated to the standby if configured). The Online → Compile and Download to Target System path supports incremental changes that do not alter the device topology.

Operational Best Practices

• Identical project on both servers: Both servers must run the same compiled project. Configure the redundancy partner so each server knows about the other's project state. Mismatched projects cause runtime warnings and degraded failover.
• Synchronize time: Use NTP on all servers and clients. Alarms and logs use local time; mismatched clocks make troubleshooting difficult.
• Document the failover timeout: Operators should know how long visibility is lost during a failover (typically 3-10 s). Document this in the operations manual.
• Avoid mixing single-user and multi-user projects on the same server: A WinCC station can host only one project type at a time.
• Test failover regularly: Schedule quarterly failover tests. A redundant pair that has never been tested is a single point of failure in practice.
• License audit: Run the Automation License Manager report monthly. License drift is a common cause of "License missing" runtime errors after server hardware changes.

Frequently Asked Questions