OPC UA Redundancy vs WinCC Server Redundancy Architecture

Overview: Two Different Layers of Redundancy

Industrial plants routinely confuse two distinct redundancy mechanisms because both are typically described as "redundancy" in vendor literature. In a Siemens environment the two that most often collide are:

• OPC UA Server Redundancy – defined in the OPC UA specification (IEC 62541), it is a transport- and data-access-level mechanism that lets an OPC UA client tolerate the loss of one OPC UA server endpoint.
• WinCC Server Redundancy – a Siemens product feature (WinCC/Redundancy option) that duplicates the runtime database, alarm logging, and tag archive of a WinCC station onto a second, hot-standby server.

These two mechanisms are not mutually exclusive and are commonly combined. They protect against different fault domains. Choosing the wrong layer (or assuming one layer implies the other) is a frequent root cause of single points of failure in HMI/SCADA architectures.

What OPC UA Redundancy Actually Does

OPC UA Redundancy is specified in the OPC UA Services specification (Part 4 of the multi-part OPC UA series, IEC 62541-4). The specification describes how a Server can advertise a list of redundant endpoints to a Client and how the Client can transparently fail over between them. Per the OPC Foundation reference (Part 4 §6.6.1), redundancy in OPC UA covers three independent layers:

1. Server Redundancy – multiple OPC UA server instances publish the same address space; clients can switch.
2. Client Redundancy – multiple clients consume the same data so a single client crash does not stop data acquisition.
3. Network Redundancy – multiple physical paths (e.g., ring topology with MRP) between a client and a server.

Server Redundancy is the most commonly used variant. The data model exposes a ServerArray – an ordered list of redundant server endpoints. Each endpoint is identified by a unique ServerUri. When the primary server becomes unreachable, the client reconnects to the next entry in the ServerArray using the same session. The Session Services layer (CreateSession, ActivateSession) is reused so the client does not need to rebuild subscriptions, monitored items, or registered nodes from scratch.

Redundancy Service Set (Part 4)

The relevant service set in Part 4 is the Redundancy Service Set. While the detailed wire format is in the OPC UA binary protocol, the architectural rules are:

OPC UA explicitly defines two server-side redundancy models:

• Transparent Redundancy – servers are clones; either may serve a request. The client is unaware of which server actually answered. The server selection is typically round-robin or health-based and is opaque to the application.
• Non-Transparent Redundancy – servers have state. Only the primary server services requests; the secondary becomes primary after a defined failover event. The client must be aware of the primary/secondary role.

Failover is typically detected by either a keep-alive timeout on the secure channel (default values are application-specific, e.g., 10 s for many SCADA stacks) or by a missed Publish response. The client's reaction is to reopen the session against the next ServerUri in the array.

What WinCC Server Redundancy Actually Does

WinCC/Redundancy is a Siemens Runtime option that installs a second WinCC Server (or WinCC Station in PCS 7) with the same project. At runtime, both partners run the same image database, the same alarm logging, the same tag logging archive, and the same scripts. They synchronize over a dedicated redundancy connection (default: TCP port 8000/tcp, configurable; secondary heartbeat on 8001/tcp in many versions – verify in the project). A typical configuration uses two servers named SERVER1 (preferred/master) and SERVER2 (standby).

Synchronization is continuous and includes:

• Tag value updates (changed values only, throttled by the redundancy synchronization cycle).
• Alarm and message acknowledgment states.
• User archive records.
• Logged-in operator sessions and audit trail entries.
• Pictures and script states for connected WinCC Clients.

On loss of the redundancy partner, the surviving server becomes the Master. Connected WinCC Clients (and web clients) automatically reconnect to the surviving server, provided the client connection list has both servers configured. The failover is controlled by:

• Redundancy synchronization timeout – if no heartbeat is received within this period (default 5 s in many versions, configurable up to 30 s), the partner is declared down.
• Redundancy loss tag – an internal boolean exposed in the project that can be displayed on the HMI.

Side-by-Side Feature Comparison

Architectural Topologies

Three typical combinations exist in a Siemens plant. The diagram below is rendered as inline SVG so it is portable and editable.

Topology 1 – OPC UA Redundancy Only

What it protects against: Loss of Server A. The client automatically re-establishes its session on Server B. There is no single point of failure at the OPC UA layer. There is, however, still a single point of failure at the PLC and at the network.

Topology 2 – WinCC Redundancy Only

What it protects against: Loss of WinCC Server 1. Server 2 becomes Master, and connected clients reconnect. Tags, alarms, and archives are continuously synchronized. There is still a single point of failure at the PLC and at the S7 channel to the PLC.

Topology 3 – Combined OPC UA + WinCC + S7-1500R/H Redundancy

What it protects against: Loss of a PLC CPU, loss of an OPC UA server, or loss of a WinCC server. This is the configuration recommended for SIL-2 / IEC 61508 operator-control applications and for batch servers in regulated industries.

Relationship to S7-REDCONNECT and S7-1500R/H

For S7-H systems, Siemens provides S7-REDCONNECT as part of the SIMATIC NET software. S7-REDCONNECT is essentially the S7 counterpart of OPC UA Server Redundancy: it provides redundancy for the S7 communication channel between a PC station (acting as OPC server or WinCC server) and a pair of S7-400H or S7-1500R/H CPUs. The behavior is the same – the OPC UA server (or WinCC channel) maintains a logical connection; if the primary CPU fails, S7-REDCONNECT switches the channel to the backup CPU within the configured S7-REDCONNECT monitoring time (commonly 1–5 s for S7-1500R/H with PROFINET ring).

The relationship between the three layers can be summarized:

Each layer adds resilience but also adds complexity, configuration time, and licensing cost. Most plants adopt a "defense in depth" approach: redundant PLC, redundant S7 channel, redundant OPC UA server pair, redundant WinCC pair. The trade-off is cost versus mean time between data loss for the operator.

Configuration: OPC UA Server Redundancy on a Siemens PC Station

The following procedure creates a redundant pair of OPC UA servers using the SIMATIC NET OPC UA Server. Verify exact steps against the installed SIMATIC NET version, as menu paths differ between V15, V16, V17, V18 and V19.

1. Install SIMATIC NET on both PC stations (e.g., SIMATIC NET V18 with the "OPC UA Server" component).
2. Configure the S7 connection in the SIMATIC NET Configuration Console to the redundant PLC pair. For S7-1500R/H, enable S7-REDCONNECT and select both CPU slots in the connection properties.
3. Enable the OPC UA Server in the Configuration Console under "OPC Settings → OPC UA Server". Set the server endpoint to a fixed port (default 4840/tcp for opc.tcp, or 4870 for the discovery endpoint).
4. Define the ServerArray: in the OPC UA server configuration, add a second server instance with a unique ServerUri (e.g., urn:siemens:simaticnet:opcua:serverA and urn:siemens:simaticnet:opcua:serverB) and cross-link them. The configuration tool generates the ServerArray automatically when "Redundant server" is selected.
5. Set redundancy mode – for the SIMATIC NET OPC UA server, this is a non-transparent redundancy: one server is the primary, the other is the warm standby. The client (e.g., WinCC, TIA Portal, or a third-party SCADA) must be configured with both server URIs.
6. Configure the client: in WinCC Professional, add two OPC UA connections in the "OPC UA" node of the HMI tags. In TIA Portal, add both server endpoints in the OPC UA client configuration. In WinCC V7, add both server URIs in the OPC UA channel configuration.
7. Set the keep-alive on the client side (e.g., 10 s) and the publish interval (e.g., 500 ms) to match the application tolerance for data staleness.

Configuration: WinCC Server Redundancy

1. Install WinCC on both servers with the same project version and the "Redundancy" option license.
2. In the WinCC Explorer, right-click the project root and open "Redundancy". If the option is licensed, the dialog enables the redundancy configuration. Enter the partner server name (e.g., SERVER2) and the synchronization port.
3. Configure the redundancy settings:
   • Synchronization time: the interval at which changed values are sent to the partner (e.g., 1000 ms – configurable).
   • Synchronization timeout: the maximum time without a heartbeat before the partner is considered failed (e.g., 5 s – confirm in your version's help text).
   • Behavior on partner loss: the local server switches to Master, logs the event, and emits a system alarm.
4. Configure connected WinCC Clients: in the client project, under "Server List", add both WinCC servers. The client tries Server 1 first and falls back to Server 2 if Server 1 is unreachable.
5. Configure OPC UA clients (if any): add both WinCC OPC UA server endpoints (each WinCC server publishes its own OPC UA server on port 4892 by default in TIA Portal, or 4802 in WinCC V7 – verify). The OPC UA client uses the same ServerArray mechanism as in the OPC UA section above.
6. Test the failover: stop the WinCC Runtime on Server 1 (not the OS). Within synchronization timeout seconds, Server 2 becomes Master, clients reconnect, and the operator can resume control.

Failover Behavior: Timing and Data Loss

The two mechanisms do not have identical failover behavior. The table below summarizes the typical values; actual values depend on configuration, network, and licensing.

Selection Decision Matrix

Use the matrix below as a starting point. The "right" answer always depends on the plant's risk assessment and on the layers that are already redundant.

Common Pitfalls

1. Assuming one layer implies the other. OPC UA Server Redundancy does not synchronize WinCC projects, and WinCC Redundancy does not make a single OPC UA endpoint redundant. Each layer must be configured and licensed independently.
2. Pointing both OPC UA servers at the same S7 connection. If both servers read the same S7 connection and that connection is the SPOF, the redundancy is illusory. Use S7-REDCONNECT so each server has an independent logical S7 path.
3. Mismatched timeouts. A 5 s WinCC redundancy timeout with a 30 s OPC UA keep-alive produces confusing alarms: the operator sees the WinCC server already failed-over while the OPC UA client is still talking to the old (now-defunct) endpoint.
4. Forgetting the redundancy license on the second server. WinCC will not enter redundancy mode at runtime if the option is not licensed on both servers.
5. Forgetting partner names in client projects. A WinCC Client configured only with Server 1 will lose its connection when Server 1 fails; the failover server is invisible to it.

Verification and Commissioning Checklist

1. Confirm that both OPC UA server endpoints respond to GetEndpoints and that the ServerArray contains both URIs.
2. Confirm that the OPC UA client can read a tag from Server A, then power off Server A; the client must continue reading the same tag from Server B within the keep-alive window.
3. Confirm that the WinCC redundancy heartbeat is present on the configured port (e.g., telnet SERVER2 8000 on a diagnostic laptop – do not leave a permanent telnet session open in production).
4. Stop WinCC Runtime on Server 1; verify that Server 2 becomes Master within the configured timeout and that connected WinCC Clients reconnect.
5. Verify that an internal tag such as @RedundancyLoss (or the version-specific equivalent) toggles correctly on the surviving server.
6. Trigger an OPC UA client failover (e.g., disable the Server A network port) and verify that the MES receives continuous data with no more than one missed Publish.
7. Document the failover time observed in your environment and compare it to the design target (commonly < 30 s end-to-end for the operator to regain control).

FAQ