Detecting Redundant Partner PC Shutdown in WinCC SCADA Systems

In a server-redundant HMI/SCADA architecture, an unannounced shutdown of the standby or active partner is one of the most operationally dangerous failure modes. The process keeps running on the surviving server, the operator never sees a change, and the redundancy itself is silently degraded until the next failover is required. Detecting that condition and raising an explicit alarm is therefore a commissioning requirement, not an option. This reference covers the native Siemens mechanisms (system messages, Lifebeat Monitoring, PCS7 Redundancy State Control) and compares them with a custom ICMP-ping VB-script and a PLC-side watchdog, plus the equivalent Rockwell FactoryTalk Alarms and Events station-redundancy path.

1. Problem Definition and Failure Modes

Two failure modes are commonly conflated but must be alarmed separately:

A complete redundancy-monitoring solution discriminates between these. The cheapest detection (ICMP) cannot tell you whether WinCC is running or only the OS; the most accurate (WinCC Lifebeat) cannot detect an OS-level crash.

2. Prerequisites

• WinCC V7.4 SP1 or later (V7.5 / V7.5 SP1 recommended for current UAT). The redundancy system messages and Lifebeat mechanism are present from V7.0 onward; the exact message ID ranges changed at V7.4.
• Two server projects configured with the WinCC Redundancy option, identical project path, identical tag database, and identical user administration. See the WinCC V7.5 Redundancy manual.
• TCP/IP connectivity on a fixed service VLAN (avoid spanning the control VLAN). A static IP for each server is mandatory because Lifebeat messages reference the partner by name/IP.
• For PCS7: PCS7 V9.0 SP2 or later with the Redundancy State Control Object installed from the PCS7 Library.
• For the custom ping script: WinCC script runtime enabled, and the Microsoft ICMP component (Ping) available on every WinCC server (built into Windows since Win7/Server 2008 R2).
• For FactoryTalk comparison: FactoryTalk View SE 12.0 or later, or FactoryTalk Alarms and Events 6.0 or later for the redundancy-enabled network station application.

3. Method A — Native WinCC Redundancy System Messages (Recommended)

WinCC's Redundancy option generates a fixed, documented set of system messages whenever the partner's state changes. These messages are written to the local Alarm Logging database even when the partner is unreachable, because they originate from the local Redundancy DLL monitoring the local @RM_SERVER tags.

3.1 Enable System Messages

1. Open WinCC Explorer on both servers.
2. Right-click Alarm Logging → Open.
3. In Alarm Logging: menu Tools → WinCC System Messages.
4. Check Activate system messages and confirm the message class System - Redundancy is selected. The default WinCC message numbers 1012300 to 1012399 cover redundancy state changes.
5. Click OK and repeat on the partner server.

3.2 Key System Tags and Messages

The complete enumeration is in the WinCC Information System under Configurations → Redundant Systems → Attachment: System Messages, and reproduced in chapter 4 of the WinCC Redundancy manual (PDF).

3.3 Tuning the Monitoring Time

Default partner monitoring time is 30 seconds. For most process plants this is too slow; a typical good value is 5–10 s.

1. In WinCC Explorer: Computer → Properties → Redundancy.
2. Set Partner monitoring time to 5 s and Connection establishment retry time to 1 s.
3. Restart the WinCC Runtime on both servers.

4. Method B — Lifebeat Monitoring (Project-Not-Running Detection)

Lifebeat Monitoring is a cyclic tag ping between WinCC servers. If the partner's WinCC project stops, the tag remains "stale" and Lifebeat flips the configured bit. Note: an OS-level shutdown on the partner also causes Lifebeat to fail, but the message wording will say "project not running" rather than "computer shut down"—logically equivalent for the operator.

4.1 Configuration

1. Open the WinCC project on server A.
2. In WinCC Explorer: Tools → Lifebeat Monitoring.
3. Add partner B by name or IP.
4. Set Monitoring time to 5 s and Monitoring time factor to 3 (lifebeat declared dead after 15 s).
5. Assign an internal binary tag (e.g. Partner_Alive) on server A; WinCC writes 0 when partner dies.
6. Mirror the configuration on server B.

4.2 Alarm Wiring

On each server, configure a tag-triggered alarm on Partner_Alive == 0 with class Error and text "Redundant partner WinCC project not running - failover capability lost." Hiding the alarm in the standby's own picture prevents spurious acknowledgement during commissioning.

5. Method C — PCS7 Redundancy State Control Object

For PCS7 V9.0 SP2 and later the Redundancy State Control Smart Object is supplied in the PCS7 library and can be dropped directly into a WinCC picture.

1. Open Graphics Designer on the OS server.
2. Library palette → Smart Objects → Control → PCS7 Redundancy State Control.
3. Place the object on the overview picture. Configure properties: Server names, Update interval = 5 s, Status text on standby and Status text on failure.
4. The object reads @RM_SERVER, @RM_MASTER, and the partner Lifebeat internally; it raises a red border and a configurable alarm bit if the partner is not reachable.

This is the most operationally friendly method for PCS7 users because no scripting is required and the object visualizes the redundancy state in the same faceplate that operators already use for unit control.

6. Method D — Custom VB-Script Ping

When the project is not a PCS7 OS, or when OS-level shutdown must be distinguished from a project-only stop, an ICMP-ping script is the standard workaround. The script below is a documented and field-proven pattern.

6.1 Internal Tag Definitions

6.2 Script Body (place in a Global Action scheduled every 2–5 s)

'===============================================
'-- Detecting connectivity to Redundant Partner --
'-- Place in a WinCC Global Action with trigger --
'-- cycle 2000 ms. Tested on WinCC V7.4 SP1. ----
'===============================================
Dim RemotePC_IPAddress, My_PingResult
Dim MyAlarm

RemotePC_IPAddress = HMIRuntime.Tags("RemotePC_IPAddress").Read
My_PingResult = ToPing_AnIP(RemotePC_IPAddress)

HMIRuntime.Trace "Ping " & RemotePC_IPAddress & " = " & vbTab & My_PingResult & vbCrLf
HMIRuntime.Tags("RemotePC_IP_PingStatus").Write Trim(My_PingResult)

On Error Resume Next
If My_PingResult <> "Success" Then
    HMIRuntime.Tags("RemotePC_IP_Disconnected").Write 1
Else
    HMIRuntime.Tags("RemotePC_IP_Disconnected").Write 0
End If
If Err.Number <> 0 Then
    HMIRuntime.Trace "Error#" & CStr(Err.Number) & Space(1) & Err.Description
    Err.Clear
End If
On Error Goto 0
'===============================================

6.3 Required Helper Function ToPing_AnIP

Insert the following function into the project's global script area (paste into the .bmo file before the calling Global Action):

Function ToPing_AnIP(sIP)
    Dim oShell, oExec, sLine, sResult
    Set oShell = CreateObject("WScript.Shell")
    Set oExec  = oShell.Exec("ping -n 1 -w 1000 " & sIP)
    Do While Not oExec.StdOut.AtEndOfStream
        sLine = oExec.StdOut.ReadLine
        If InStr(sLine, "Reply from") > 0 Then
            ToPing_AnIP = "Success"
            Exit Function
        End If
    Loop
    ToPing_AnIP = "Timeout"
End Function

The -w 1000 switch limits each ICMP wait to one second; combined with a 2 s global-action cycle, the worst-case detection latency is about 3 s.

6.4 Alarm Wiring on the Ping Tag

Create a tag-triggered alarm on RemotePC_IP_Disconnected rising edge, class Error, with the message text "Redundant partner {RemotePC_IPAddress} not reachable - PC is shut down or network partition." Combine with a status-color change on the redundancy status picture (green → red on rising edge of the disconnect bit).

7. Method E — PLC-Side Watchdog (Authoritative)

A PLC-driven watchdog is the most reliable mechanism because the PLC is the only participant that always remains alive. The pattern is:

1. Each WinCC server has a discrete output (or a tag written by WinCC to the PLC) toggling at 1 Hz.
2. In the PLC, run a timer (e.g. S7 TON, 5 s preset) that resets on every toggle.
3. If the timer elapses without a reset, set a marker (e.g. Partner_PC_Offline) and raise an alarm on the HMI through the standard PLC→WinCC alarm path.
4. Mirror the logic for both servers so each one watches the other.

Example for a SIMATIC S7-1500 in Structured Text (TIA Portal V16 or later):

// Watchdog on input "PC1_Heartbeat" from server 1
IF "PC1_Heartbeat" THEN
    "Timer_PC1"(PT := T#5S);          // running timer
    IF "Timer_PC1".Q THEN              // 5 s elapsed without reset
        "Partner_PC1_Offline" := TRUE;
    END_IF;
ELSE
    "Timer_PC1".TON(IN := FALSE);       // reset on first miss
    "Partner_PC1_Offline" := FALSE;
END_IF;

Equivalent ladder for an Allen-Bradley CompactLogix 5380 (RSLogix/Studio 5000 V32 or later) uses a TON instruction with a 5 s preset, and exposes Partner_PC1_Offline to FactoryTalk View as a tag-trendable alarm point.

8. FactoryTalk Alarms and Events Cross-Reference

On a Rockwell FactoryTalk View SE network-station application the same engineering problem is solved inside the A&E subsystem rather than at the HMI runtime. A network station application supports FactoryTalk Alarms and Events redundancy out of the box, while a local station application does not. Reference: FactoryTalk Alarms and Events System Configuration Guide (FT AE publication FTAE-RM001).

9. Method Selection Matrix

10. Verification Procedure

1. From the active server, open Alarm Logging and confirm the system message class System - Redundancy is active and contains message numbers 1012300-1012399.
2. Simulate partner shutdown: log into the standby, run shutdown /s /t 0. Within the configured monitoring time + 2 s the active server must raise the configured alarm.
3. Verify operator visibility: the alarm must appear on every client, with a distinct color (red / blinking), and must require operator acknowledgement.
4. Recover: power the partner server; verify the clear-alarm (1012302) is raised automatically and the redundancy state tags return to 2 (standby) on the partner.
5. Negative test: disconnect the crossover/heartbeat cable only. Both servers should raise a redundancy-lost alarm, not a partner-shutdown alarm—proving the alarm path uses the alarm NIC, not the application NIC.
6. Negative test: stop only the WinCC Runtime on the partner (do not shut down Windows). Method A and Method B should fire; Method D should not fire (ICMP still succeeds). This proves Methods A and B are functioning as designed.
7. Trend RemotePC_IP_PingStatus (Method D) and @RM_SERVER (Method A) for one week and confirm there are no spurious flaps.

11. Troubleshooting Matrix

12. FAQ