Resolving Redundancy Loss Connectivity ID 16#2 Alarms in SIMATIC PCS 7

In SIMATIC PCS 7 (V8.2 through V9.1), the operator alarm 'Redundancy loss connectivity ID 16#2' is generated by system diagnostic driver blocks in the '@CFC' chart folder monitoring redundant AS-OS or I/O communication links. If CPU and OS diagnostic buffers show no physical hardware failures, the alarm is typically triggered by transient communication jitter exceeding the default 15-second monitoring timeout. To eliminate nuisance alarms, verify network cable and switch integrity, adjust the communication load percentage in the S7-400 CPU properties, and tune the debounce monitoring delay on the system driver block.

Executive Summary

High-availability automation architectures in SIMATIC PCS 7 utilize redundant S7-400H or CPU 410-5H controllers connected to redundant OS servers and distributed I/O across industrial Ethernet (Fault-tolerant S7 connections) and redundant PROFIBUS/PROFINET networks. During normal plant operations, engineers may observe recurring operator alarms displaying the message text: Redundancy loss connectivity ID 16#2 (or error codes referencing connectivity ID 2), despite both controller CPUs remaining in RUN mode without diagnostic buffer fault entries.

These alarms originate from system-generated diagnostic blocks (such as RCV_RED, SND_RED, RED_INFO, or OR_M_16) located inside the hidden @CFC charts automatically produced by the PCS 7 Driver Generator. These blocks cyclically monitor the health of redundant data paths. If cyclic handshakes or redundancy synchronization frames experience transient network delays exceeding the block's internal timeout (default 15 seconds), the block asserts a connectivity loss alarm. This article explains the architectural origin of Connectivity ID 16#2, diagnostic verification methods, and engineering procedures to stabilize redundancy alerting.

Architecture and Fundamental Mechanics

The PCS 7 Maintenance and Basis Libraries provide standardized driver blocks that instantiate inside @CFC_RXT or @CFC_AS system charts during AS-OS compilation with the 'Generate module drivers' option enabled.

Redundant communication monitoring utilizes specific block algorithms to evaluate connection paths:
1. Fault-Tolerant S7 Connection Monitoring: Redundant S7 connections between S7-400H and WinCC OS servers utilize dual Industrial Ethernet paths (Path A and Path B via CP 443-1 or internal CPU PN ports). The system blocks monitor cyclic keep-alive telegrams.
2. Connectivity ID 16#2: The identifier 16#2 specifically corresponds to the secondary redundant sub-connection (Path B / Link 2) within a configured fault-tolerant connection pair. When Link 2 fails to acknowledge a heartbeat telegram within the parameter timeout, the system block generates message class 'System Alarm - AS' with the specific error tag.
3. Monitoring Timeout (Delay Time): The system driver blocks incorporate a delay parameter (typically initialized to 15.0s via an input parameter like DELAY or MON_TM). If transient communication congestion—caused by heavy WinCC trend archiving, background AS-OS downloads, or network switch spanning-tree recalculations—delays handshakes beyond 15 seconds, the alarm trips, even though the primary path (Link 1) maintained 100% process control continuity.
4. CPU Communication Slice: If the CPU parameter 'Scan cycle load from communication [%]' is set too low (e.g., default 20%), the controller prioritizes cyclic OB execution over background communication processing, starving Link 2 handshake responses during high CPU utilization.

Step-by-Step Implementation Procedure

Follow these steps to diagnose and resolve nuisance 'Redundancy loss connectivity ID 16#2' alarms in SIMATIC PCS 7:

Identify the Generating System Block and Chart:
- In WinCC Runtime, open the Alarm Logging overview.
- Right-click the alarm 'Redundancy loss connectivity ID 16#2' and select 'Loop in Alarm' (or note the message origin block tag).
- The block tag will reference an automatically generated chart in the Component View under Charts > @CFC_* (e.g., @CFC_RXT or @CFC_AS410).
- Open the referenced @CFC chart in the CFC Editor to inspect the specific diagnostic block (e.g., RED_INFO or OR_M_16).
Inspect Physical Network and Industrial Switch Health:
- In the SIMATIC NET diagnostic console or SCALANCE Web Based Management (WBM), inspect the physical ports for Link 2.
- Check for physical cable CRC errors, packet collisions, or loose optical fiber connectors on the CP 443-1 modules or CPU Ethernet ports.
- Ensure network switches bridging AS-OS communication utilize RSTP (Rapid Spanning Tree Protocol) or MRP (Media Redundancy Protocol) with properly configured ring managers to eliminate broadcast storms.
Optimize CPU Communication Cycle Load:
- In SIMATIC Manager, open HW Config for the target S7-400H / CPU 410 station.
- Double-click the CPU in the rack to open 'Properties'.
- Select the 'Cycle/Clock Memory' tab.
- Locate 'Scan cycle load from communication [%]'. If set to the default 20%, increase this setting to 35% or 40% (maximum recommended 50%). This reserves sufficient CPU microcode execution time for redundancy handshake telegrams.
- Save and compile HW Config, then download changes to the AS in RUN mode (CiR).
Adjust Driver Block Monitoring Delay Time:
- In the CFC Editor, open the system @CFC chart containing the reporting redundancy driver block.
- Locate the monitoring time input parameter (typically labeled MON_TM, DELAY, or TI_MON).
- Note the default value (typically 15.0 seconds).
- If network audits confirm physical infrastructure is robust but transient bursts cause nuisance alarms, increase the monitoring delay parameter to 30.0 or 45.0 seconds.
- Note: Modifying system-generated blocks directly in @CFC can be overwritten if 'Generate module drivers' is executed with full chart compilation. To make the change permanent, adjust the default delay parameter on the block type in the Master Data Library or use a dedicated user CFC to manipulate the input parameter.
Verify Redundant WinCC Channel Diagnosis:
- On the WinCC OS Server, open 'WinCC Channel Diagnosis' (WinCCChannelDiagnosis.exe).
- Expand 'SIMATIC S7 Protocol Suite' > 'Industrial Ethernet'.
- Verify that both logical connections within the 'Named Connections' or 'Industrial Ethernet' group display 'State: OK' and 'Error: 0'.

Verification

In WinCC Alarm Logging, verify that the 'Redundancy loss connectivity ID 16#2' alarm clears and goes into the acknowledged/historical log.
Monitor the system during peak operational activity (e.g., during active trend logging, shift change reports, or recipe downloads) to confirm the alarm does not recur spuriously.
In SIMATIC Manager, select the S7-400H station and open 'PLC > Module Information > Diagnostic Buffer' to confirm zero communication error entries.
Intentionally disconnect the physical cable for Link 2 in a controlled maintenance window: verify that the alarm triggers accurately after the newly configured debounce timeout (e.g., 30 seconds) and clears immediately upon cable re-insertion.

Limitations and Operational Precautions

Do not increase monitoring delay parameters excessively (e.g., greater than 60 seconds), as this delays genuine diagnostic detection of severed physical cables or damaged optical transceivers. Never delete system-generated @CFC charts, as doing so disables AS-OS module diagnostics entirely and causes compilation aborts. Redundant network architectures and CP modules must be verified against current hardware compatibility lists through an authorized Siemens distributor or the Siemens Industry Mall.

Engineer FAQ

What does 'ID 16#2' represent in the redundancy alarm text?

In PCS 7 redundant fault-tolerant S7 connection diagnostics, 16#2 designates the second redundant communication path (Path B / Link 2) within the dual-channel connection structure.

Why is there no error in the CPU diagnostic buffer when this alarm occurs?

The CPU diagnostic buffer records hardware failures, rack faults, and internal firmware exceptions. A temporary delay in receiving an application-layer keep-alive telegram on Link 2 is treated as a communication event by the driver blocks, not a CPU hardware fault.

Will running 'Generate module drivers' overwrite my changes in @CFC charts?

Yes. If you directly edit parameters inside @CFC charts, running a full AS compile with 'Generate module drivers' can reset inputs to default library values. Parameterize the block in a user chart or customize the template in the Master Data Library.

Can high OS server network traffic cause Connectivity ID 2 alarms?

Yes. If the OS Server network card handles both plant bus communication and heavy terminal bus traffic without dedicated NIC segregation, packet congestion can delay handshake telegrams beyond 15 seconds.

How does increasing CPU communication load percentage impact cycle time?

Increasing communication load from 20% to 40% allows the CPU to spend more time processing network frames, which slightly extends cyclic OB scan times. Ensure your OB execution times remain comfortably within their cycle intervals.