Clearing Non-Acknowledged and Unacknowledged Phantom Alarms in SIMATIC PCS 7 OS Runtime

In SIMATIC PCS 7 OS Runtime, alarms can become permanently trapped in the active alarm list ('anstehende Meldungen') as non-acknowledgeable phantom alarms when their originating automation blocks are deleted, unlinked, or modified in CFC while the alarm was in an active 'Incoming' (Came In) state. Because the deleted block can never send the corresponding 'Outgoing' (Went Out) transition, the WinCC Alarm Logging runtime database retains the message indefinitely. For large numbers of trapped messages (e.g., hundreds of obsolete alarms), manual tag toggling is impractical. The definitive Siemens solution involves executing an automated alarm cache purge: closing WinCC Runtime, resetting the WinCC Alarm Logging short-term archive cache via the Alarm Logging editor or Reset_Alarms utility, and recompiling the OS from SIMATIC Manager with 'With memory reset' checked.

The Lifecycle of PCS 7 Alarms and Root Causes of Phantom Messages

In SIMATIC PCS 7, process alarms generated by technological blocks (MotL, VlvL, MonAnL) operate via the Siemens Alarm_8P mechanism. The controller communicates message state transitions to WinCC through a strict three-phase handshake: Came In (+) -> Went Out (-) -> Acknowledged (Q).

Phantom alarms (alarms that persist in the active alarm banner and cannot be acknowledged or cleared) typically arise during commissioning and revamping due to procedural oversights:

Chart Deletion in Alarm State: An engineer deletes a CFC chart or block instance while a fault condition is active. Because the block no longer exists in the AS, it will never execute the outgoing transition.
Communication Interruption Mid-Handshake: A network interruption occurs precisely between message generation and acknowledgment logging, leaving the WinCC SQL Server runtime cache in an inconsistent state.
Event ID Collisions: When typical charts are duplicated without updating block message identifiers (MsgEvId), multiple blocks attempt to drive the same message instance in Alarm Logging.

Evaluating Remediation Methods: Manual Bit Toggling vs Database Reset

Depending on the number of trapped alarms, engineering teams must deploy the appropriate remediation strategy:

Remediation MethodEngineering EffortTechnical ProcedureScalabilityInternal Tag TogglingHigh (Unusable for large volumes)Map internal binary tag in Alarm Logging; toggle 1 $\rightarrow$ 0 to simulate outgoingSuitable for 1 to 10 isolated alarmsSiemens Alarm Purge ScriptLow / AutomatedExecute official Siemens Reset_Alarms C-script or SQL cleanup utilityRecommended for 100+ trapped alarmsAlarm Logging ResetFast / CleanDeactivate runtime; reset Alarm Logging archive tables in WinCC ExplorerResets active lists; clears test alarmsEntire OS Compile + Memory ResetThorough / StandardRecompile OS from SIMATIC Manager with With memory resetRebuilds entire message database cleanly

For facilities facing hundreds of phantom alarms, attempting to create manual test tags and buttons is completely unworkable; a direct runtime database reset is the only viable solution.

Step-by-Step Procedure to Purge Stuck Runtime Alarms

To purge all stuck phantom alarms and synchronize the active alarm list with true plant status, follow this procedure:

Ensure Controller Program Integrity: In SIMATIC Manager, verify that all active CFC charts compile with zero errors and that module drivers are completely updated.
Deactivate WinCC Runtime: On the affected OS Server (or Single Station), deactivate WinCC Runtime and close WinCC Explorer.
Execute Alarm Logging Archive Reset: Open the project in WinCC Explorer. Open Alarm Logging. In the menu or tree, right-click Archive Configuration -> Messages and select Reset. This purges the temporary active alarm list cache without deleting long-term historical archives.
Recompile OS with Memory Reset: In SIMATIC Manager on the Engineering Station, right-click the OS, select Compile, choose Entire OS, check With memory reset, and select Tags and messages.
Download to OS Server: Download the freshly compiled OS project to the OS Server.
Activate Runtime: Start WinCC Runtime. The AS controllers will re-evaluate active field signals and transmit only genuine, currently active process alarms to the WinCC alarm banner.

Verification

Confirm that phantom alarms are completely eradicated using these validation steps:

Alarm Banner Inspection: In WinCC Runtime, inspect the single-line alarm banner and the main AlarmControl page. Confirm that the 900+ stuck phantom alarms are no longer present in the 'Pending Alarms' list.
Legitimate Fault Generation: Force a test limit alarm on an existing field transmitter. Verify that the alarm appears immediately, can be acknowledged with the operator horn/ack button, and clears cleanly when the signal normalizes.
Redundancy Synchronization Check: In a redundant server pair, verify that the alarm list on Server A and Server B matches identically and @RM_SYNCHRONIZING returns to 0.

Limitations and Operational Precautions

When resetting alarm logging databases, observe these operational precautions:

Historical Log Impact: Performing a full Alarm Logging reset clears the immediate runtime message buffer. If historical alarm audit trails are required for regulatory compliance, ensure Process Historian or backup archive segments are secured.
Plant In-Run Consideration: Resetting the OS message cache is best performed during scheduled plant maintenance or coordinated unit turnarounds.
Preventative Engineering Practice: Never delete or rename CFC charts while field equipment is in a faulted or running state. Clear alarms or suppress them in CFC before deleting technological blocks from the project.

Engineer FAQ

Why can't I just click 'Acknowledge' on phantom alarms?

Acknowledgment only acknowledges an alarm; it does not clear it from the active list. An alarm remains in the active list until the controller block issues the 'Went Out' state transition.

Will resetting Alarm Logging delete my project's message configuration?

No. Resetting the Alarm Logging archive clears only the runtime operational cache (.mdf/.ldf segments). The static message definitions compiled from CFC remain 100% intact.

What is the official Siemens FAQ regarding stuck alarms?

Siemens published FAQ Entry ID 109749345 detailing the automated script and database procedure to clear obsolete alarms without manual tag reconfiguration.