Monitoring WinCC Redundancy Connection: Cable Fault Detection

Problem Definition: @RedundantServerState Does Not React to a Cable Disconnect

Two redundant WinCC servers and two clients are deployed. Each server is equipped with three network interfaces:

1. One Ethernet card dedicated to client communication across a managed LAN.
2. One Ethernet card dedicated to the redundancy connection between the two servers (direct cross-over cable).
3. One CP1613 SIMATIC NET card dedicated to S7 PLC communication.

The engineering requirement is to monitor the redundancy link and raise an alarm on the HMI when the cross-over cable fails or is unplugged. The integrator assigned the system tag @RedundantServerState to a status indicator expecting a value transition when the link is lost. The tag value did not change. A second test was performed in which the standby server was shut down; the local value remained at 1 with no transition into 3 (Fault) or 4 (Standby lost).

The expected behavior is that the partner's logical state should reflect reachability. The observed behavior is that the tag remains at 1 even when the link is physically broken. Resolving this requires understanding the difference between the logical partner state and the physical link state in the WinCC redundancy architecture.

Redundancy Architecture and Tag Semantics

The WinCC redundancy architecture separates the logical partner state from the physical link state. Three independent data paths exist on each server:

• Client LAN path – Managed switch fabric connecting both servers to both clients. Used for WinCC client/server data exchange (alarm logging, tag database, archive data, user administration).
• Redundancy path – Direct cross-over cable between the two server redundancy NICs. Carries the redundancy synchronization packets and the partner state information used to drive the failover decision.
• PLC path – CP1613 SIMATIC NET card running ISO-on-TCP or TCP to S7-300 / S7-400 controllers. Independent of the redundancy logic.

The system tag @RedundantServerState is a logical partner status tag, not a NIC link sensor. It reports what the local server believes about the partner's role in the redundancy group. The exact state values depend on the installed WinCC version (V7.4, V7.5, or TIA Portal WinCC Professional); the canonical list documented in the WinCC Information System is:

The transitions into state 3 or 4 are driven by the redundancy synchronization packets exchanged over the redundancy path. If the path is severed, the local server waits for the redundancy monitoring time (default 25 s in WinCC V7) before declaring a fault. The cable disconnect is treated as an unsupported operation in runtime, so depending on the version and the configured failover strategy the application may not transition cleanly into a fault state at all. The partner is still running, the partner's role is still Standby, and the redundancy application layer may not see a partner-absence event because the failover logic was not designed to react to mid-runtime cable pulls.

Root Cause Analysis

Three factors combine to produce the observed behavior:

1. Tag scope. @RedundantServerState reports the logical partner state, not the physical link state of the redundancy NIC. A cable that is unplugged does not immediately invalidate the partner's logical role; the partner is still running, it is just not reachable on the redundancy network.
2. Heartbeat and monitoring time. The redundancy partner state is updated based on the synchronization heartbeat and the configured monitoring time. If the cable is unplugged, the local server waits for the monitoring time before deciding the partner is unreachable, and only then does @RedundantServerState change.
3. Unsupported runtime operation. The WinCC Redundancy manual explicitly states that disconnecting the redundancy cable in runtime is not allowed. The system is not designed to handle this gracefully. Some WinCC V7 versions do not update the partner state if a coordinated failover is not in progress, which leaves the tag at 1 indefinitely.

Because the tag cannot reliably indicate a cable fault on its own, the engineering team must deploy a separate monitoring mechanism that observes the physical link state directly. The remainder of this article covers the methods that work in practice: WinCC system messages, SNMP-based NIC link monitoring, VBScript ping / TCP checks, and CP1613 health monitoring.

Solution Matrix

The recommended practice is to combine WinCC system messages (logical view) with SNMP-based link monitoring (physical view). This produces an alarm even when the redundancy protocol itself fails to react, and it covers both the cable-pull case and the partner-crash case.

Solution 1: WinCC System Messages in Alarm Logging

WinCC emits system messages tagged with the redundancy class whenever a redundancy-relevant event occurs. The exact message numbers depend on the installed WinCC version; the WinCC Information System index for Redundancy > System Messages lists them per version. Typical event categories include partner-unreachable, connection-loss, role-switch, and synchronization-error notifications.

To enable and surface these messages on the HMI:

1. Open the WinCC Explorer on the server.
2. Open Alarm Logging.
3. In the message class tree, confirm that System is active and the redundancy subclass is selected.
4. Filter the message list to the redundancy-related message numbers; note the numbers from the WinCC Information System for your installed version.
5. Configure message attributes: priority, acknowledgment requirement, and the appearance (color, font) for unacknowledged and acknowledged states.
6. On the HMI, place a WinCC Alarm Control or a simple message window on the redundancy status screen. The operator will see the alarm text, message number, and timestamp when the redundancy connection is lost.

System messages are a reliable indicator for the logical partner-loss event. They fire when the partner becomes unreachable regardless of the root cause (cable, switch, server crash, redundancy service crash). They may not fire in all versions when only the physical link is broken but the partner is still considered reachable at the application layer, so SNMP or ICMP monitoring should be added for physical-link coverage.

Solution 2: SNMP-Based NIC Link Monitor

The standard MIB-II interface table exposes the operational status of every network interface on a Windows server. The relevant OID is ifOperStatus:

• OID: 1.3.6.1.2.1.2.2.1.8.<ifIndex>
• Data type: INTEGER (enumeration)
• Polled via SNMPv2c read-only community string

When the cross-over cable is unplugged, the NIC driver reports ifOperStatus = 2 (down) within a few seconds (typically < 5 s, depending on the NIC driver and link-negotiation timing). The SNMP poll cycle is the dominant latency; with a 1 s scan rate the fault is visible to the SCADA within 2 s.

SNMP Service Setup on Windows Server

1. Install the SNMP feature. In Server Manager, select Add Roles and Features > Features > SNMP Service. Install both the SNMP service and the WMI SNMP Provider.
2. Open Services, right-click SNMP Service, open Properties.
3. On the Security tab, add a community string. Use a private read-only string such as redundancy_mon. Do not use public in a production environment.
4. Add the monitoring host (the SNMP OPC server host) to the list of Accepted community names with READ ONLY rights.
5. On the Security tab, accept SNMP packets from the monitoring host IP only.
6. On Windows Firewall with Advanced Security, create a new inbound rule to allow UDP port 161 from the monitoring host IP.
7. Restart the SNMP service.
8. Verify with an SNMP browser from the monitoring host: snmpwalk -v2c -c redundancy_mon <server-ip> 1.3.6.1.2.1.2.2.1.8. You should see the ifOperStatus values for every interface.

SNMP OPC Server Configuration (KEPServerEX)

Use an SNMP-aware OPC server such as KEPServerEX with the SNMP driver. The redundancy link monitoring use case is documented in the KEPServerEX Network Redundancy documentation.

1. Create a new channel of type SNMP.
2. Add a device for each WinCC server, with the server's redundancy NIC IP as the endpoint.
3. Use the device's MIB browser to locate ifOperStatus for the redundancy NIC, noting the ifIndex. The ifIndex can be found by walking 1.3.6.1.2.1.2.2.1.2 (ifDescr) and matching the redundancy adapter description; for example, on a typical Intel I350-T4 the redundancy NIC may be Intel(R) I350 Gigabit Network Connection #3.
4. Create a tag such as ServerA_RedLinkStatus of type INTEGER bound to the ifOperStatus OID.
5. Set the scan rate to 1000 ms.
6. Expose the OPC DA tags to WinCC over the OPC channel.

WinCC Side: External Tag and HMI Indicator

1. In WinCC Explorer, open Tag Management and add the OPC tags from the KEPServerEX server as external tags via the OPC channel (or via OPC DA if the KEPServerEX runs on a separate host).
2. On the redundancy status screen, add a status display or a multistate indicator (e.g., a colored circle) bound to the ifOperStatus tag. Configure the states: 1 = green (up), 2 = red (down), 3–7 = yellow (other).
3. For alarm generation, add a tag-based alarm on the OPC tag. Configure the limit value to trigger on any value other than 1. Set the message text to "Redundancy link down" and enable the audible alarm.

Solution 3: VBScript Ping / TCP Check

For installations where an external SNMP OPC server cannot be deployed, a VBScript Global Action in WinCC can be configured to poll the partner's redundancy IP and write the result to an internal tag.

Place the script in Global Script > Actions > Global Actions and trigger it on a 1-second cycle. The script uses the Shell object to execute ping:

' WinCC VBScript - Redundancy Link Monitor (ICMP)
' Trigger: cyclic, 1000 ms
' Tags used: RedundancyLinkOK (internal, DWORD)
' PARTNER_IP: redundancy NIC of partner server (192.168.100.0/30 subnet)

Const PARTNER_IP = "192.168.100.2"
Dim objShell, objExec, strResult, intOK
Set objShell = CreateObject("WScript.Shell")
Set objExec  = objShell.Exec("ping -n 1 -w 1000 " & PARTNER_IP)
strResult = objExec.StdOut.ReadAll
If InStr(strResult, "TTL=") > 0 Then
    intOK = 1
Else
    intOK = 0
End If
HMIRuntime.Tags("RedundancyLinkOK").Write intOK
Set objExec = Nothing
Set objShell = Nothing

For a TCP-based check that verifies the redundancy service is responsive (not just the OS), use the WinCC redundancy service port. The default WinCC V7 redundancy port is documented in the WinCC Information System under Redundancy > Configuration > Communication Ports. A short-timeout TCP connect (e.g., 500 ms) to this port is a more reliable indicator than ICMP, because it verifies that the redundancy service on the partner is alive.

' WinCC VBScript - Redundancy Link Monitor (TCP connect)
' Replace ICMP block with TCP connect using WMI / Winsock
Dim objTCP, blnOK
Set objTCP = CreateObject("MSWinsock.Winsock")
objTCP.RemoteHost = "192.168.100.2"
objTCP.RemotePort = 135  ' replace with documented WinCC redundancy port
objTCP.Connect
' Wait up to 500 ms for connect state
Dim tStart
tStart = Timer
Do While objTCP.State <> 7 And (Timer - tStart) < 0.5
    objTCP.WaitForData 50
Loop
If objTCP.State = 7 Then
    intOK = 1
Else
    intOK = 0
End If
objTCP.Close
HMIRuntime.Tags("RedundancyLinkOK").Write intOK
Set objTCP = Nothing

Solution 4: CP1613 Health Monitoring

The CP1613 SIMATIC NET card has its own diagnostics. If the PLC communication path is critical to monitor, the SIMATIC NET Configuration Console and the S7-DOS diagnostic tool expose the link state and the S7 connection state. When the CP1613 loses its link or the S7 connection drops, the WinCC PLC tags transition to "substitute value" with quality code "bad".

1. In WinCC Tag Management, enable quality reporting for the PLC tags (default in WinCC V7).
2. Use a Global Script action to iterate over critical tags and check HMIRuntime.Tags(...).Quality. If any tag is in a bad state for longer than 5 seconds, raise an alarm.
3. Optionally, query the S7 connection state via the SIMATIC NET OPC server and expose it as a separate tag.

Implementation Walkthrough: Combined Monitoring

The following is a recommended implementation that combines all relevant methods into a single redundancy status faceplate on the HMI.

1. Configure WinCC system messages for redundancy events. This gives a baseline alarm in the Alarm Logging view.
2. Install and configure the SNMP service on both servers. Use a private community string. Restrict the accepted hosts to the SNMP OPC server host only.
3. Install and configure the SNMP OPC server (e.g., KEPServerEX) on a third host — not on the redundant servers, to avoid a single point of failure for monitoring.
4. Add SNMP tags for ifOperStatus on the redundancy NIC of each server.
5. Add WinCC external tags pointing to the SNMP OPC tags via the OPC channel.
6. Add a VBScript Global Action to ping the partner's redundancy IP and write the result to an internal tag. Use TCP if ICMP is blocked.
7. Create a WinCC screen with a redundancy status faceplate:
   • Top row: server A status (SNMP up/down, ping result, last state change timestamp).
   • Middle row: server B status (SNMP up/down, ping result, last state change timestamp).
   • Bottom row: @RedundantServerState for both servers and the last system message related to redundancy.
8. Configure a tag-based alarm on the SNMP down state and on the ping failure to trigger an audible alarm. Forward the alarm via WinCC IndustrialDataBridge or a third-party notification tool (SMS, email) to operations.

Verification Procedure

To verify the monitoring setup, perform a controlled fault test on a non-production system or during a maintenance window:

1. Note the initial state of all monitored tags and the system message log.
2. Unplug the cross-over cable between the two servers' redundancy NICs.
3. Wait for the scan rate of the SNMP OPC server (1 s) plus the WinCC tag update cycle (1 s).
4. Confirm that:
   • The ifOperStatus tag transitions to 2 (down).
   • The WinCC HMI indicator turns red.
   • A tag-based alarm is raised in Alarm Logging.
   • The VBScript ping returns 0 (failure) and writes to the internal tag.
   • The system message for redundancy connection loss appears in the alarm log within the configured monitoring time (default 25 s).
5. Reconnect the cable.
6. Confirm that all indicators return to the green/up state, the tag-based alarm clears, and the system message for connection restoration appears.
7. Document the test result and the recovery time for the operations team.

Troubleshooting Matrix

Architecture Considerations

Beyond monitoring, the network architecture itself should be hardened to avoid the conditions that produce the symptoms described here.

• VLAN separation. Place the client-server network and the redundancy link on different VLANs. The redundancy link should be a dedicated /30 subnet (255.255.255.252) with only the two redundancy NICs as members — for example, 192.168.100.0/30 with hosts 192.168.100.1 and 192.168.100.2.
• Dedicated switch vs. cross-over cable. A direct cross-over cable is the simplest and most reliable redundancy link because it has no intermediate device to fail. If a small dedicated switch is used (e.g., for cable length extension), use a managed switch with link-loss forwarding and disable STP on the redundancy ports to avoid the 30–50 s STP blocking time on link-up.
• NIC teaming. Do not team the redundancy NIC with any other NIC. Teaming is for bandwidth and resilience on the client LAN, not for the redundancy link, which must be a single dedicated path so that the partner can detect a fault deterministically.
• Time synchronization. Use the same NTP source for both servers. Inconsistent time can cause the redundancy protocol to interpret heartbeat delays as faults and trigger unnecessary failovers.
• Firewall rules. Document all required ports for the WinCC redundancy service, the SNMP service (UDP 161), and the SIMATIC NET S7 communication (TCP 102 for ISO-on-TCP, plus the configured port for the WinCC redundancy service). The default ports are documented in the WinCC Information System under Redundancy > Communication Ports.
• Physical layer. Use industrial-grade Ethernet cables and connectors for the redundancy link. Label both ends clearly. Document the cable in the plant's cable management system. Avoid routing the redundancy cable parallel to VFD power cables; cross at 90° if routing must cross.

Network Redundancy in Industrial Context

Network redundancy in industrial automation extends beyond the WinCC server-pair model. It applies to controller-level redundancy (S7-400H, ControlLogix redundancy), drive-level redundancy (Active Line Module + Basic Line Module topologies), and field-network redundancy (PRP, HSR, MRP, DLR on PROFINET, EtherChannel on EtherNet/IP). The principles are the same: duplicate communication modules, duplicate physical paths, deterministic failover, and dedicated monitoring of each path's health.

For driver-level redundancy — for example, the Triconex Ethernet driver — the architecture is documented in the KEPServerEX Network Redundancy documentation. The driver uses two communication modules to provide a redundant path from the OPC server to the controller, and it switches between them on link loss.

For a methodological approach to designing and verifying network-redundancy monitoring, the Reliability Block Diagram (RBD) framework is widely used. The RBD shows how the failure of individual components (cable, NIC, switch, server, software) contributes to the overall system failure probability. The methodology and case studies are documented in A practical approach to monitoring network redundancy.

FAQ