Deleting Non-Acknowledgeable OS Messages in WinCC PCS 7 V8.1

1. Problem Statement

Non-acknowledgeable process messages in the WinCC/PCS 7 OS runtime remain visible in the message list, the message line, the group display, the block icon, and the status bar of the screen window even after the underlying automation system (AS) cause has been cleared. Operators cannot acknowledge the message because the standard acknowledge button is disabled or the message is not assigned to an authorization group that permits acknowledgment. The condition is observed across PCS 7 V8.0, V8.1, V8.2, and V9.0 installations but is most disruptive on systems where the operator's only recourse is a full OS restart.

The official Siemens Support article 109751476 - Deletion of non-acknowledgeable process messages in the WinCC PCS 7 OS runtime provides a C script solution for PCS 7 V9.0 / WinCC V7.4 SP1. That script calls runtime functions that do not exist in WinCC V7.3 (PCS 7 V8.0/V8.1) or WinCC V7.4 (PCS 7 V8.2), which is the core compatibility gap this document addresses.

2. Affected Versions and Compatibility Matrix

The root cause and the available remediation differ significantly between PCS 7 versions. The matrix below captures the verified behavior of the official deletion script and the supported runtime APIs.

To determine the installed version on a running OS server, open the WinCC Explorer and read Project Properties > Computer > Version or check C:\Program Files\Siemens\Automation\WinCC\bin\WinCC.exe file version.

3. Root Cause Analysis of Non-Acknowledgeable Messages

A process message transitions through states defined in the WinCC alarm engine. The relevant internal state bits are:

Non-acknowledgeable behavior is normally produced by one of four conditions:

1. Authorization mismatch: The operator logged in has a lower level than the Authorization field configured in the message class. The Ack button is greyed out. Visible in WinCC Explorer > Alarm Logging > Message Classes > Authorization.
2. Gearing locked: The message is part of a geared message group and the locking signal is held. The MSG_STATE_LOCK bit prevents acknowledgment.
3. AS variable toggled too fast: The incoming bit toggles faster than the operator can acknowledge, leaving the message in a perpetual Incoming/Outgoing state. The block icon and status bar reflect the last known state but the message line keeps the last entry visible.
4. Project / configuration error: A message class is configured with Single acknowledgment = No and Group acknowledgment = No, leaving the operator with no path. The WinCC CS documentation in the AS-OS Engineering manual lists the relevant class settings under "Acknowledgment concept".

Items (1) and (4) are configuration defects and should be corrected in the engineering project before any runtime workaround is applied. Items (2) and (3) are runtime conditions and the focus of the rest of this document.

4. Reference: The Official V9.0 Deletion Procedure

The Siemens Support article 109751476 deploys a C action triggered by a button on a separate WinCC picture. The script enumerates the message archive, identifies messages in the Not Acknowledgeable state, and forces the state to a value that the runtime treats as closed. The script body is delivered by Siemens as a downloadable project template accompanying the support entry.

The deletion logic relies on WinCC C API functions and runtime Pokes that are part of the WinCC V7.4 SP1 release. The names of those functions are not published in the public Siemens manual set; the support article is the only authoritative reference. The script's failure on V7.3 (PCS 7 V8.1) is the source thread's central observation: "some of c functions not exist in older wincc." Because the exact function list is not disclosed, this document does not attempt to reproduce the script verbatim but does cover the same logical operation using the alarm hiding and archive manipulation techniques available on V7.3.

5. Why the V9.0 Method Fails on V8.1 and Earlier

WinCC C API surface is extended between major versions. The functions referenced by the V9.0 script fall into two categories:

• Message state query / modification: Functions in the msrt_api family used to read and write the state of a runtime message. Introduced and stabilized in WinCC V7.4 SP1.
• Alarm archive maintenance: Functions that interact with the SQL-based alarm logging archive (segment manipulation, forced commitment). The exact entry points are version-dependent.

On a WinCC V7.3 SP2 (PCS 7 V8.1) installation, the C compiler emits unresolved external errors when the script is loaded. The diagnosis is straightforward: open the Global Script C editor, recompile the project, and read the output window. Any line containing unresolved external symbol or LNK2019 corresponds to a function that does not exist in this build of WinCC. There is no patch or hotfix that back-ports these functions into V7.3; the only path is to use a runtime technique that does not depend on them.

6. Alarm Hiding Workaround (Detailed Procedure)

The hide-alarm feature is present in every WinCC V7.x release that ships the AlarmControl OCX. It is purely a runtime operator action and does not require scripting. The procedure is the source thread's recommended fallback for V8.1 systems.

6.1 Prerequisites

• Operator authorization level 9 (System) or higher, because the Hide function is in the System authorization class.
• A WinCC picture with an AlarmControl inserted from the WinCC object palette (Controls > WinCC AlarmControl).
• Toolbar configured to expose the Hide button. Default WinCC toolbars do not include it.

6.2 Configure the AlarmControl Toolbar

1. Open Graphics Designer and create a new picture called Pic_HideNonAck.pdl in the project directory \Grafic\.
2. Insert an AlarmControl from the object palette. Resize to cover most of the screen.
3. Double-click the control to open the configuration dialog.
4. Switch to the Toolbar tab. The dialog lists the available buttons in a tree view.
5. Expand Message list and enable the entry Hide message. The corresponding toolbar button is added.
6. Confirm with OK. Save the picture.

6.3 Filter for the Non-Acknowledgeable Message

1. Open the OS runtime and navigate to the new picture. Log in as a system-level user.
2. Click the Selection button in the alarm control toolbar to open the message selection dialog.
3. Set the following filter criteria:
   • State = Incoming, Incoming/Outgoing, Outgoing (deselect Acknowledged)
   • Acknowledgment = "Not acknowledgeable" or filter by Authorization = No ack
   • Time range = wide enough to include the stuck message
4. Apply the filter. The list collapses to the candidate messages.

6.4 Hide the Message

1. Right-click the offending message in the list.
2. Select Hide message (or click the toolbar Hide button).
3. Confirm the dialog "Do you want to hide this message?".

The hidden message is removed from the live message list and from the message line. It is written to the alarm log with the operator name and the timestamp. The hide action does not modify the AS variable, the message class, or the underlying status word in the block icon, which is the limitation discussed in the next section.

6.5 Restore Hidden Messages

If the hidden message returns (e.g., the AS condition reoccurs), the OS does not automatically re-display it. To recover hidden messages during commissioning or test:

1. Open the same picture and the same filter.
2. Click the Show hidden messages toolbar button (configured alongside Hide message in step 6.2).
3. Select the message and click Restore message.

7. Cleaning the Residual Block Icon and Status Bar Symbols

After the message is hidden, operators observe that the block icon faceplate and the screen window status bar still display the alarm symbol. The cause is that the block icon and the status bar are driven by the block's MSG_STAT output word, not by the message list state. The hide action clears the list but does not write to the AS status word.

The residual symbols are not caused by lingering real conditions; the source thread confirms "in the fact there are not reasons for these messages and alarm symbols." The symbols are stale state in the block instance DB that was never cleared because the gear/lock bit remained high after the cause went away.

7.1 Trigger-and-Acknowledge Reset

The cleanest non-scripted reset is a forced trigger and acknowledge cycle. This is normally only used during commissioning, not in production, because it requires the operator to simulate the alarm condition.

1. Open the faceplate of the affected block.
2. Locate the message that is stuck. The faceplate shows the message text and the acknowledge button if authorization permits.
3. If the ACK button is enabled, click it. The symbol clears and the message line removes the entry.
4. If the ACK button is disabled, log in with a higher authorization level (level 9 "System") and try again.

7.2 Status Word Reset via WinCC Tag Simulation

For blocks where the ACK button is permanently disabled (configuration defect or wrong authorization class), the next option is to clear the block's status word directly.

1. Identify the block instance DB and the bit that drives the alarm. In the standard PCS 7 APL libraries, this is typically bit MSG_STAT.0 (incoming) and MSG_STAT.2 (acknowledged) of the instance DB's MSG_STAT word.
2. Open the faceplate in maintenance view (Authorization level 6 or higher).
3. Trigger the alarm manually by setting the input condition for one scan cycle. Use the simulation input on the block faceplate where available.
4. Clear the input. The block raises and acknowledges the message in one cycle, and the MSG_STAT word returns to 0.

7.3 Scripted Reset on V7.3 (Advanced)

For systems where the manual cycle is impractical (many blocks), a C script on a separate picture can iterate over a configured tag list and write 0 to MSG_STAT. The script does not call the missing V7.4 API; it uses SetTagWord and the tag names that the WinCC tag management exports for each instance DB. Because the procedure is project-specific (block type, instance tag naming, authorization class), it cannot be reproduced verbatim. The general pattern:

// Pseudo-code for V7.3 block icon cleanup
// Compile in WinCC Global Script C editor

#include "apdefap.h"

void OnClick(const char* lpszPictureName, const char* lpszObjectName)
{
    int i;
    char szTag[256];
    for (i = 0; i < g_nBlockCount; i++)
    {
        sprintf(szTag, "AS_%s_H1.MSG_STAT", g_szBlocks[i]);
        DWORD dwOldVal = GetTagDWord(szTag);
        // Bit pattern of "incoming, not acknowledged"
        if (dwOldVal & 0x0001)
        {
            // Trigger via standard MSG_LOCK manipulation
            sprintf(szTag, "AS_%s_H1.MSG_LOCK", g_szBlocks[i]);
            SetTagByte(szTag, 0);
        }
    }
}

8. Alternative Approaches

8.1 Use the OS Project Editor to Suppress Message Classes

For systems where the offending messages belong to a class that is not safety-critical (e.g., system messages, operator messages, lifecycle messages), the OS project editor can disable the class entirely. This is a permanent project change and is appropriate only when the class is not used in the operator's workflow. The path is WinCC Explorer > OS Project Editor > Message Configuration > Message Classes; uncheck the box next to the class to be suppressed, then compile the OS.

8.2 Cold Restart of the OS

A full OS restart clears the runtime message list and the in-memory status words. The block icons in the AS retain the last state, so a restart is not a complete fix; it is a temporary measure. Schedule it for the next planned outage.

8.3 Open a Siemens Support Request

9. Prevention and Engineering Best Practices

1. Configure authorization carefully. In the message class, set the Authorization for acknowledgment to a level that the operator can reach, or configure a separate "Main operator" level. Misconfigured authorization is the most common cause of non-acknowledgeable messages in brownfield migrations.
2. Flapping suppression. Use the Suppression time field in the message configuration to filter messages that toggle faster than a defined debounce. A value of 500 ms is typical for process alarms.
3. Gearing review. For each geared message group, ensure that the locking signal (the input that holds the gear) is wired to a value that returns to 0 when the underlying condition clears. Gears that latch on a manual reset cause the exact symptom described in this document.
4. Test the message class during FAT. The factory acceptance test should include a deliberate non-acknowledgeable condition and verify that the operator can recover. The recovery path tested in FAT is the path that will work in production.
5. Document the operator's recovery path. Add a one-page procedure to the operations manual: how to filter, how to hide, how to restore. The procedure in section 6 is the basis for that one-pager.

10. Verification and Commissioning Checklist

Run the following checks after applying any of the procedures above. Each check has a pass/fail criterion and a recovery step if the check fails.

11. Troubleshooting Matrix

12. Summary of Tools and Where to Get Them

• Siemens Support article 109751476 - Official V9.0 deletion template and procedure. Reference only; not portable to V7.3 / V7.4 SP0.
• WinCC Explorer (part of the PCS 7 installation) - for project editor and version inspection.
• Graphics Designer (part of the PCS 7 installation) - for the alarm hiding picture.
• SQL Server Management Studio (SSMS) for SQL Server 2014 / 2016 - for verifying the alarm log content after a hide action.