How to Clear Stale and Hanging System Alarms from Deleted Field Devices in PCS 7 OS

To clear stale or "hanging" system alarms in SIMATIC PCS 7 WinCC OS—where alarms from deleted PROFIBUS/PROFINET field devices remain stuck in the active alarm list with a struck-through timestamp—use the official Siemens reset script (SIOS Entry 109751476) or reset the Alarm Logging runtime database cache. These ghost alarms occur because the AS controller transmitted an incoming fault message (COME) before the hardware slave was removed from HW Config. Once the device and its driver blocks are deleted and module drivers recompiled, the AS no longer possesses the block instance to issue the outgoing (GO) event, leaving the alarm permanently unacknowledged and un-cleared in WinCC.

Root Cause: Why Deleted Fieldbus Slaves Leave Hanging Alarms

In SIMATIC PCS 7, alarm state tracking between the Automation System (AS) and WinCC Operator Station (OS) operates as a stateful, event-driven handshake:
1. Incoming State (COME): When a fieldbus slave (e.g., DP slave 1/14) fails, the diagnostic block (DP_DIAG or OB_DIAG1) calls ALARM_8P to transmit an incoming event. WinCC inserts the alarm into its active list.
2. Hardware Deletion: An engineer removes the failed slave in HW Config, updates the process image, and recompiles the CFC charts with "Generate module drivers".
3. The Orphaned Alarm: The CFC compiler deletes the associated diagnostic block from the @ charts. Because the block no longer exists in the AS, it can never evaluate a healthy state or dispatch the outgoing message (GO) to WinCC.
4. Result: WinCC Alarm Logging expects a matching GO telegram from the originating AS block number. Standard operator acknowledgment acknowledges the event, but the alarm cannot exit the active list without an outgoing state.

Understanding the Struck-Through Timestamp Indicator

When an alarm displays a horizontal strike-through line across its timestamp or message text in the WinCC AlarmControl table:
- Missing Outgoing Event: The alarm management engine flags that communication with the originating technological block has been severed or the block instance has vanished while the alarm was active.
- Emergency Acknowledge Failure: Attempting an emergency acknowledgment (Not-Quittieren) using the internal message number fails because emergency acknowledgment only satisfies the operator acknowledgment flag; it cannot fabricate a missing outgoing state.

Method 1: Using the Official Siemens Acknowledge Reset Tool (SIOS 109751476)

Siemens provides a dedicated engineering solution documented in SIOS Entry 109751476 ("Resetting hanging messages in PCS 7 OS"):

Step 1: Download and Integrate the Reset Picture

Download the diagnostic PDL package from SIOS entry 109751476.
Copy the supplied picture file (e.g., @ResetHangingAlarms.pdl) into the OS project's GraCS directory on the primary OS Server.
Open Graphics Designer in WinCC Explorer to inspect the internal C-script:
- The script connects to the WinCC Open Development Kit (ODK) Message Service Runtime API (MSRTSetMsgGone()), which programmatically injects a synthetic GO state directly into the local Alarm Logging runtime buffer for specified message numbers.

Step 2: Execute the Reset in WinCC Runtime

In WinCC OS Runtime, open the navigation window and invoke @ResetHangingAlarms.pdl.
The picture displays a grid listing all active alarms currently flagged as orphaned or stuck.
Select the hanging DP slave message (e.g., "DP-Slave 1/14: Ausfall").
Click the Reset / Force Gone button.
Result: The script issues the missing outgoing telegram. The alarm clears from the active alarm list (Neuliste) and moves to the historical archive (Archivliste).
Repeat the operation on the redundant partner OS Server if database replication does not immediately clear both nodes.

Method 2: Resetting the WinCC Alarm Logging Runtime Database

If the reset PDL is unavailable or if numerous stale alarms clutter a test/commissioning station, perform a complete runtime database cache reset:

Operational Workflow:

Deactivate WinCC Runtime on the affected OS station.
Close WinCC Explorer and open Windows Command Prompt as Administrator.
Terminate any residual WinCC database processes by executing:
cmd CCCleaner
Navigate to the OS project directory in Windows File Explorer.
Locate the subfolder ArchiveManager\AlarmLogging.
Back up and remove the temporary runtime segment cache files (*.mdf and *.ldf representing the active short-term ring buffer; do not delete historical long-term backup archives).
Restart WinCC Explorer and activate Runtime.
Result: WinCC recreates a clean, synchronized alarm cache from the active AS controller states, completely clearing deleted hardware ghost messages.

Verification

To verify that the hanging alarms have been successfully cleared:
- Open the WinCC AlarmControl incoming list on all operator stations: confirm that the deleted DP/PN slave alarms no longer appear.
- Check the WinCC Short-Term and Long-Term Alarm Archives: verify that the message appears with an artificial outgoing timestamp (GO) and correct operator acknowledgment metadata.
- Trigger a legitimate process or hardware alarm (e.g., unplug a test module): confirm that real alarms appear, acknowledge, and clear cleanly without disruption.

Limitations and Operational Precautions

Process Historian (PH) Considerations: If the plant utilizes SIMATIC Process Historian (PH), manually resetting messages via database deletion requires caution. Ensure the PH database is synchronized to prevent unmatched incoming alarms in the long-term historical reporting database.
Redundant OS Server Pairs: When clearing alarms on redundant OS servers, always execute the procedure on the standby server first, verify stability, and then repeat on the master server to avoid split-brain alarm tracking.
Never Delete Slaves While Alarms Are Active: The best operational practice is to acknowledge and physically restore or bypass a faulty slave before removing it from the HW Config project.

Engineer FAQ

Why did Not-Quittieren (Emergency Acknowledge) not clear the alarm?

Emergency acknowledgment only satisfies the requirement that an operator has seen the fault. It does not generate the technological GO state that informs WinCC the physical fault condition has cleared.

Will resetting the Alarm Logging cache delete my historical alarm records?

No. Historical long-term archives stored in SQL database segments remain untouched. Only the active, short-term runtime buffer holding current states is re-indexed.

Can this issue occur with PROFINET devices as well as PROFIBUS?

Yes. Any distributed device (PROFIBUS DP, PROFINET IO, AS-Interface) whose driver blocks are removed from CFC while an alarm state is actively registered in WinCC can cause hanging alarms.

Where can I find the exact message number of the hanging alarm?

In WinCC AlarmControl, configure the table columns to display the Message Number (MsgNr). This number is required if targeting the message specifically via the reset script.

Technical References

Siemens Industry Online Support: SIOS Entry 109751476 ("Resetting hanging alarms in PCS 7 OS").
SIOS Entry 109742323: PCS 7 Compendium Part A - System Diagnostics and Driver Engineering.
SIOS Entry 109809264: SIMATIC Process Control System PCS 7 Advanced Process Library Manual.
Siemens WinCC ODK Manual: Working with MSRT Message Service Functions in WinCC Runtime.