Implementing Redundant Controller Failure Alarms on PCS 7 OS Clients Without FB88 or SFC 87

In SIMATIC PCS 7 fault-tolerant architectures (S7-400H and CPU 410-5H), engineers seeking to generate an alarm on WinCC OS Clients when both CPUs lose communication or halt should not attempt to code custom logic using legacy blocks CONEC (FB88) or SFC 87 (C_DIAG). In an H-system, halting one CPU triggers an automated line switchover, keeping the S7-H connection healthy while FB88 only toggles its master/standby output (Q_MS). Furthermore, if both CPUs fail, controller execution ceases completely, making it impossible for internal code to transmit an alarm. Instead, engineers must rely on the standard PCS 7 DCS architecture: WinCC Lifebeat Monitoring (@Livebeat) automatically detects total AS communication loss and generates an un-suppressible system alarm, while the APL diagnostic block HCPUDIAG (FB257) provides discrete CPU0_Run and CPU1_Run flags for controller-level monitoring.

The Architectural Fallacy of Monitoring Dual Controller Failure Internally

A recurring question among automation engineers commissioning redundant S7-400H or CPU 410-5H controllers is how to write logic inside the AS program to trigger an alarm on WinCC OS Clients when both CPUs halt or lose power.

Attempting to achieve this through user programming inside the AS involves a fundamental architectural fallacy:
$$\text{If both CPUs of an S7-400H station fail, the controller stops executing instructions completely.}$$

When both processors enter STOP mode or lose electrical power, all cyclic Organization Blocks (OB1, OB35), user CFC charts, and message function blocks (ALARM_8P) cease running. The controller cannot evaluate logic, cannot format communication packets, and cannot transmit an alarm to WinCC.

Therefore, total controller failure monitoring must always be performed externally by the supervisory system (WinCC OS Server) or by an adjacent peer controller.

Behavior of FB88 (CONEC) and SFC 87 in Fault-Tolerant S7-H Connections

Engineers attempting to use FB88 (CONEC) and SFC 87 (C_DIAG) observe that halting one of the two CPUs fails to change any error outputs, altering only the Q_MS output flag.

This behavior occurs because FB88 queries the status of the logical S7 connection:
1. In an S7-400H system, an S7-H connection comprises four redundant physical sub-paths linking redundant CP 1623 cards to CP 443-1 modules or CPU onboard ports.
2. When CPU 0 halts, the redundant H-system operating system executes a bumpless hardware switchover to CPU 1.
3. The S7-H connection remains established and fully functional over the surviving sub-connection.
4. Because communication is not interrupted, SFC 87 evaluates the connection as healthy.
5. The only parameter that updates is Q_MS, which toggles to indicate that the active communication path shifted from Master to Standby. FB88 cannot provide discrete run/stop status for each CPU.

The Standard Solution: Automated WinCC Lifebeat Monitoring

In SIMATIC PCS 7, monitoring controller availability is an automated out-of-the-box system function requiring zero CFC logic:

How WinCC Lifebeat Monitoring Operates:

When the OS project is compiled, the engineering system automatically configures the Lifebeat Monitoring (@Livebeat) subsystem.
The WinCC OS Server cyclically sends an application-level ping packet to each configured Automation Station over the S7 Named Connection.
If both CPUs stop, power fails, or the plant bus is severed:
- WinCC detects that the AS failed to respond within the supervisory timeout ($5\text{ s}$).
- WinCC generates an un-suppressible, high-priority system alarm:
$$\text{'Process connection to Automation Station AS 410-5H interrupted'}$$
- The Picture Tree Navigator displays a flashing red warning symbol on top-level plant area buttons.
- All block icons associated with that AS display a crossed-out yellow communication fault flag.
- The Maintenance Station (MS) highlights the controller rack in red as completely inoperative.

Implementing Discrete CPU State Tracking via APL HCPUDIAG

If plant logic inside an adjacent controller (such as an ESD Safety System or peer AS) requires discrete binary inputs confirming whether CPU 0 or CPU 1 is running, engineers should deploy the standard APL diagnostic block HCPUDIAG (FB257):

flowchart TD
    A["S7-400H Operating System / @CPU_RT"] --> B["HCPUDIAG (FB257)"]
    B --> C["CPU0_Run (BOOL)"]
    B --> D["CPU1_Run (BOOL)"]
    B --> E["Redundant (BOOL)"]
    B --> F["SyncError (BOOL)"]
    C & D --> G["AND Logic: Single or Dual CPU Trip Detection"]

Configuration Steps:

In the Master Data Library, locate HCPUDIAG under the APL Diagnostics directory.
Insert HCPUDIAG into a cyclic interrupt task (e.g., OB32 or OB35).
The system compiler automatically links HCPUDIAG to the @CPU_RT driver block during Generate Module Drivers.
Interconnect the dedicated boolean outputs:
- CPU0_Run = 0: Indicates CPU in Rack 0 has stopped or faulted.
- CPU1_Run = 0: Indicates CPU in Rack 1 has stopped or faulted.
- Redundant = 0: Indicates loss of redundancy (single processor operation).
These outputs can be transmitted to peer stations via S7 inter-PLC communication blocks (BSEND/BRCV).

Redundancy Failure Monitoring Implementation Matrix

The following matrix compares methods for supervising redundant controller health:

Monitoring MethodExecution LocationDetects Single CPU Stop?Detects Dual CPU Total Loss?Standard DCS PracticeFB88 (CONEC) / SFC 87AS User ChartNo (Toggles Q_MS only)No (CPU ceases execution)Obsolete; not recommendedAPL HCPUDIAG (FB257)AS Diagnostic ChartYes (CPU0_Run, CPU1_Run)Handled before total lossRecommended for AS logicWinCC Lifebeat MonitoringOS Server SubsystemRedundancy agent logs eventYes (Generates System Alarm)Standard PCS 7 System FeaturePCS 7 Maintenance StationAsset Management ServerYellow maintenance alertRed total asset failure alarmStandard PCS 7 Asset Management

Verification

To confirm that controller failure alarms function reliably:
1. Open the WinCC Alarm banner on an OS Client.
2. In the AS rack, switch CPU 1 to STOP mode while CPU 0 remains in RUN:
- Confirm that WinCC continues operating bumplessly.
- Verify that WinCC logs the incoming system alarm: 'Loss of redundancy in AS 410-5H'.
- In CFC, verify that HCPUDIAG.CPU1_Run transitions to 0 and HCPUDIAG.Redundant transitions to 0.
3. Switch CPU 0 to STOP mode (simulating total AS outage):
- Within 5 seconds, WinCC Lifebeat Monitoring triggers the alarm: 'Process connection to AS interrupted'.
- All faceplates and block icons on the client transition to the communication-failure visual state.

Limitations and Operational Precautions

Observe the following engineering constraints:
- No In-Controller Alarms for Dual Halts: Never attempt to program a buzzer or physical horn output from the same controller that is being monitored for total failure; when both CPUs halt, digital outputs de-energize to their fail-safe state (typically 0V).
- External Heartbeat Relays: For hardwired emergency sirens, use an external watchdog timer relay (such as a hardware flasher relay driven by a toggling digital output from the CPU) that de-energizes and sounds an alarm if the CPU stops pulsing.
- Redundant Plant Bus Cabling: Ensure plant bus switches (SCALANCE X) and cables are genuinely redundant; severed network switches can trigger false total AS failure alarms while controllers are still running.

Engineer FAQ

Why did only Q_MS change when I stopped one CPU while testing FB88?

FB88 monitors the overall logical connection, not individual CPUs. Because S7-400H connections are fault-tolerant, stopping one CPU causes a seamless switchover to the partner CPU path, keeping the connection healthy and toggling only Q_MS.

How does WinCC know an AS has stopped if the AS cannot send an alarm?

WinCC uses Lifebeat Monitoring (@Livebeat), which actively polls the AS controller every few seconds. If the controller fails to acknowledge the poll within the timeout window, WinCC generates the alarm locally on the OS.

Can I use HCPUDIAG on non-redundant controllers?

No. HCPUDIAG is designed specifically for fault-tolerant S7-400H and CPU 410-5H controllers. On standard single CPUs, use the standard @CPU_RT diagnostic block.