WinCC Redundant Alarm ACK Synchronization Troubleshooting

Problem Details: Cross-Server Alarm Acknowledgment Failure

In a Siemens WinCC redundant station pair (Server A and Server B) configured for fault-tolerant operation, the horn (audible annunciator) and the acknowledgment state do not propagate from one server to the other. The typical user-visible symptoms are:

• An alarm event triggers the audible horn on both Server A and Server B.
• The operator presses the ACK button (or sends the Acknowledgement tag) on Server A.
• The horn and unacknowledged indicator are cleared on Server A but remain active on Server B.
• Server B continues to show the alarm as unacknowledged and the horn continues to sound until a second ACK is performed locally.
• This breaks ISA 18.2 / IEC 62682 alarm-management expectations that a single operator action resolves the alarm presentation across all operator stations.

The defect is purely a configuration artefact, not a software bug. It is encountered most often when the acknowledgment tag is declared as an internal WinCC tag instead of an external (PLC) tag, or when the project-wide update mechanism is not configured for the redundant pair.

Root Cause Analysis

WinCC distinguishes between two tag classes that govern where acknowledgment data is stored:

When the ACK bit is configured as an internal tag, Server A writes its own copy of the bit when the operator acknowledges. Server B has no knowledge of that change and continues to assert its own horn until the operator repeats the ACK action. The redundant partner is unaware of the acknowledgment status, so the alarm remains "unacknowledged" in its runtime database and the configured horn script keeps firing.

Even when external tags are used, WinCC can fail to mirror the acknowledgment state if the project-wide update list does not include the alarm-relevant tag group. The project-wide update is the mechanism that WinCC uses to replicate tag values to all participating stations; if a tag is excluded, the runtime will not re-evaluate the alarm status when the bit transitions on the partner server.

WinCC Redundancy Model — How Synchronization Actually Works

Siemens WinCC supports redundant operation through the WinCC Redundancy option (part of the WinCC/Redundancy package for WinCC V7.x and integrated in TIA Portal for WinCC Professional / Unified). Two servers (Master and Standby) share a project. During normal operation the Master holds the active runtime connection to the AS (PLC), the Standby receives mirrored data via the redundant partner link (TCP/UDP, default port 5001 with additional ports for archive replication).

Key synchronization rules:

1. Tag values are synchronized by the redundancy partner service on every value change, but only if the tag is part of the project-wide update list and has been acquired by both servers.
2. Alarms and messages are accepted by both servers from the AS. The AS raises the alarm; both WinCC servers receive it because the alarm-acknowledgment bit and the alarm-pending bit are PLC-side data points, not WinCC-side.
3. Operator actions (ACK, horn reset, write setpoints) are commands issued by the WinCC server to the AS via the configured tag. The AS then echoes the new state to both WinCC servers on the next acquisition cycle.
4. Internal tags are exempt from the redundancy partner's value replication. The redundant service has no path to write the internal memory of the partner server because there is no PLC source of truth.

This last rule is precisely why the horn stays on at Server B. Server A flips its internal ACK bit, but Server B's internal copy is independent. The PLC never sees the ACK because internal tags do not map to any PLC address.

Solution 1 — Move the Acknowledgment Tag to an External PLC Address

This is the primary, recommended fix. The acknowledgment bit must be written to the controller so that both WinCC servers observe the same value on the next polling cycle.

Prerequisites

• Step 7 / TIA Portal project with at least one free Boolean memory area (e.g., M0.0, M100.0, or a DB bit such as "AlarmHMI".ACK_All).
• The PLC program must process the ACK bit, set the corresponding alarm-acknowledgment tag, and reset the ACK bit after a short pulse (typical: 200–500 ms) so that the next alarm can be acknowledged with a fresh rising edge.
• WinCC project with the AS connection configured and online test passed.

Step-by-Step Procedure (TIA Portal + WinCC Professional)

1. Open the TIA Portal project containing the HMI tags.
2. In the project tree, expand HMI Tags and locate the acknowledgment tag (commonly named Acknowledge, Horn_Reset, or Alarm_Ack).
3. Change the data source from Internal tag to the appropriate PLC connection. Example for an S7-1500:
   Connection: PLC_1 [S7-1500]
Address: %DB5.DBX0.0 (Boolean in a global DB)
   Acquisition mode: Cyclic continuous
Acquisition cycle: 500 ms (matches redundancy heartbeat)
4. If you are using a structured DB for HMI handshake, add a new tag:
   Name: HMI_Ack_All
Data type: Bool
Connection: PLC_1
Address: %DB100.DBX0.0
5. Compile and download the HMI project.
6. In the PLC program, evaluate the rising edge of HMI_Ack_All and pulse the configured "Acknowledgement" of the alarm-acknowledgment tag in the WinCC alarm configuration (or the bit used by the alarm group).
7. Reset HMI_Ack_All to 0 in the PLC after 200 ms to arm the next edge.

Sample Ladder Logic (TIA Portal, S7-1500)

// ACK edge detection
A   "HMI_Ack_All"
FP  "ack_edge"          // Edge memory bit, Bool
=   "AlarmSystem".ack   // Connection to WinCC alarm acknowledgement

// Pulse reset of the HMI bit (1-shot, 200 ms)
A   "HMI_Ack_All"
L   S5T#200MS
SD  "ack_pulse_timer"
A   "ack_pulse_timer"
R   "HMI_Ack_All"       // Clear the HMI-written ACK

WinCC Alarm Configuration Update

In the WinCC alarm editor, open the Single Message or Analog Alarm configuration for the affected alarm class. The "Acknowledgement" tag must point to the same external bit (or a derived acknowledgement status bit) that the PLC now updates. The "Horn" tag may remain a different internal bit if the horn is driven by a WinCC script, but the horn should be reset by evaluating the same external ACK status to ensure both servers go silent simultaneously.

Solution 2 — Configure Project-Wide Update

Even with an external tag, the redundant partner will not pick up the change unless the tag is part of the project-wide update list. This setting controls which tags are mirrored to all stations in the distributed system.

Step-by-Step

1. In the WinCC Explorer or TIA Portal HMI editor, open Tag Management.
2. Right-click the connection or tag group containing the acknowledgment tag and select Properties.
3. Navigate to the Update tab (TIA Portal: Properties → General → Update).
4. Enable the checkbox "Project-wide update" (German: Projektweite Aktualisierung).
5. Confirm with OK and recompile the project.

The official Siemens Knowledge Base article FAQ 24832901 — "How do you configure the project-wide update of tags in WinCC?" provides additional screenshots and addresses common pitfalls, including the requirement that the tag must be acquired by both partners and that the cycle time must be shorter than the redundancy switchover time to avoid stale data after a failover.

Solution 3 — Verify Server-Client / Redundant Topology

A common misconfiguration is treating two independent WinCC stations as a redundant pair when they are in fact two single-user stations. Confirm the topology:

If the project is in fact two independent stations (not a real redundant pair), you must create a dedicated handshake area in the PLC. Reserve, for example, DB200 bytes 0–31 for "station-to-station messages". Server A writes DB200.DBX0.0 = 1 when its operator presses ACK; the PLC then sets the corresponding ACK bit for Server B's alarm group; Server A clears its request after 200 ms. Both servers then read the same PLC status and reach identical ACK state on the next acquisition cycle.

Solution 4 — Use Spare PLC Bits When Project-Wide Update Is Not Available

On legacy WinCC V6.x / V7.0 systems where the project-wide update list cannot be edited, or in projects where the tag is read via OPC DA with limited update capabilities, an alternative pattern is to write a "global acknowledgment" into the PLC and use the PLC to drive the alarm-acknowledgment status of both stations.

1. Create a global DB in the PLC with one bit per alarm group that requires synchronized ACK.
2. In WinCC, map the "Acknowledgement" tag of each alarm to the corresponding PLC bit (not an internal tag).
3. Wire a single operator button (or a WinCC script triggered by a hotkey) to set the global DB bit.
4. The PLC handles pulse-stretching and any required interlocking.

This pattern matches the "use spare bits or DB bits for external tag" recommendation from experienced WinCC engineers and works on every WinCC version that supports external tags.

Horn Logic That Travels With the ACK

The horn tag (the Boolean that drives the audible alarm) often remains as an internal WinCC tag driven by a global script. That script must read the same external ACK status to reset the horn. A canonical pattern is:

// WinCC VBScript, executed cyclically (e.g., 250 ms)
Dim ackStatus
ackStatus = HMIRuntime.Tags("AlarmSystem_ack").Read  ' External tag, PLC address

If ackStatus = 1 Then
    HMIRuntime.Tags("Horn_Active").Write 0           ' Internal horn control
Else
    ' Horn remains ON if any unacknowledged alarm exists
    HMIRuntime.Tags("Horn_Active").Write 1
End If

With this structure, the horn bit itself can remain internal because the decision criterion is external and is identical on both servers.

Verification Steps

After applying the fix, perform the following validation sequence:

1. Online tag inspection: In the WinCC tag simulator or TIA Portal online view, force the PLC ACK bit to 0. Both servers should report the same value within one acquisition cycle.
2. Redundant partner status: Open the WinCC Redundancy Control Center (or Redundancy → Status in TIA Portal). Confirm both servers report Partner connected and that the project-wide update is active.
3. Alarm injection test: Trigger a controlled alarm from the PLC (e.g., set a process variable out of range). Verify the horn activates on both Server A and Server B.
4. ACK on Server A only: Press ACK on Server A. Within 1 second, the horn must silence on Server B as well, and the alarm must move to the "acknowledged" state in both runtime databases.
5. ACK on Server B only: Repeat the test in the opposite direction to confirm the propagation is symmetric.
6. Failover test: Disconnect Server A from the network. Server B must take over as the active partner without any duplicate or stuck alarm. The alarm-acknowledgment state must be preserved.
7. Audit trail review: In the WinCC Alarm Logging database, confirm that the acknowledgment operator, timestamp, and station are correctly recorded for every event.

Common Pitfalls and Field Notes

• Mixing internal and external ACK tags across alarm groups: Some operators configure the "Horn" as internal and the "Acknowledgement" as external, or vice versa. The two must be derived from the same external source, or the horn will keep firing on one server even after ACK.
• Acquisition cycle too slow: A 5-second cycle on a 500 ms redundancy heartbeat can leave the partner server showing stale alarm state for several seconds. Use 250–500 ms for alarm-related tags.
• WinCC Unified (TIA Portal V17+) specific behavior: Unified uses the "Alarm Control" object and a JavaScript-style API. The same rule applies — the Acknowledge action must trigger a write to an external tag. Internal tags declared in Unified are scoped to a single session and are not replicated to the redundant partner.
• OPC UA clients: When the alarm source is an OPC UA server, ensure the ACK is written back to the OPC UA server (not a WinCC internal tag) so the server can broadcast the state change to all subscribers.
• PanelView 800 / Component HMI: On Rockwell PanelView 800 / Component HMIs, the equivalent feature is configured via the "Write to PLC on Acknowledge" setting. Reference the Rockwell Knowledge Base article 1023357 for the cross-vendor pattern: ACK must always be persisted to a controller-side address.
• EcoStruxure Geo SCADA Expert (ClearSCADA): Multi-operator acknowledgment in Geo SCADA is handled by the Select Multiple Alarms user-account privilege, as documented in the Schneider Electric Geo SCADA knowledge base. The same principle applies: the central alarm database holds the ACK state, and any operator station queries that database rather than holding its own copy.
• Ignition by Inductive Automation: In Ignition, acknowledgment is recorded in the central alarm status component and is visible to all clients. See the Ignition 7.9 Alarm Status — Acknowledgement documentation for the operator workflow.

Standards and Best-Practice References

Alarm acknowledgment behavior is governed by several industry standards that should be reviewed before commissioning:

• ISA 18.2 / IEC 62682 — Management of Change and Alarm Recognition: requires that operator actions on one HMI be reflected consistently across all operator-viewable stations.
• IEC 62443 — Industrial network security: when ACK is moved to the PLC, the ACK bit becomes a writable control point and must be included in the zone/conduit security model.
• Siemens WinCC Redundancy Manual — Functional description of the partner service, default ports, and switchover timing.