Overview
SIMATIC WinCC Unified is the HMI/SCADA runtime integrated into TIA Portal V17 and later. Alarm acknowledgement is one of the most frequently exercised runtime functions, and yet it is also one of the most commonly mis-configured: a runtime user logs in, attempts to acknowledge a program alarm that is no longer active, and the alarm stays on the screen in red. The control state of the alarm is not "Acknowledged" but "Outgoing" or "Came In / Went Out", and the acknowledge button click has no effect.
This article documents the root cause observed on WinCC Unified V17 panels and Runtime Advanced/Professional, the role configuration that triggers it, and the corrective steps inside TIA Portal Engineering. It also covers the script-based acknowledge pattern that bypasses the alarm control toolbar entirely, and the diagnostic checks that confirm the fix.
Affected Products and Versions
| Product | Version | Status |
|---|---|---|
| SIMATIC WinCC Unified V17 Engineering | V17.0 / V17.0 Update 1 | Reproduced, fixed by role change |
| SIMATIC WinCC Unified Runtime (PC) | V17.0 / V17.0 Update 1+ | Affected when user holds HMI Monitor Client role |
| SIMATIC Unified Comfort Panels (MTP700–MTP2200) | Firmware V17.0+ | Affected; HMI Monitor Client role applied at panel level |
| TIA Portal Engineering | V17, V17 Update 1, V18, V19 | Configuration steps identical across versions |
The behaviour has been confirmed against the TIA Portal V17 Help set and the SIMATIC HMI WinCC Unified Engineering V17 manual. Equivalent configuration locations apply on V18 and V19; the HMI Monitor Client role is unchanged across these releases.
Root Cause: HMI Monitor Client Role
Every WinCC Unified user is assigned one or more roles. A role is a named permission set that grants or denies access to runtime functions such as login, value modification, and alarm acknowledgement. The role "HMI Monitor Client" is built-in and reserved for read-only clients (for example, a parallel observation station connected to the same project, or an external MES viewer that pulls data from the runtime but must not influence it).
When this role is assigned to a user, the runtime displays an orange frame around the active window and the message "Monitor only" in the header bar. In this mode the acknowledge button is rendered, but every acknowledge call is silently rejected by the runtime authorization engine. The alarm state machine therefore never advances from Came In / Went Out to Acknowledged.
The orange banner is a deliberate UX cue placed by Siemens to make the cause obvious. If the banner is missing and acknowledge still fails, the issue is one of the other causes listed in the troubleshooting matrix below.
Preconditions for Normal Acknowledgement
Before changing anything, validate the four preconditions below. Any one of them being false can produce the same symptom as the role issue.
- Alarm is configured with the "Acknowledgement" class. Open the HMI tag that triggers the alarm, switch to the Properties > Events > Alarms section, and confirm that Alarm class is set to "Acknowledgement" (not "Notification" or "System" — those do not require acknowledgement and the button will be greyed out).
- Tag value has actually returned to non-alarm state. Place an IO field next to the alarm control bound to the same tag. If the IO field still shows the alarm-triggering value, the alarm is logically still active and cannot be acknowledged as "outgoing"; you are acknowledging an active alarm, which is allowed but does not change the visible colour until the trigger value clears.
- No individual-acknowledgement lock is set. The alarm class may have "Individual acknowledgement" enabled. In that case the group-acknowledge button on the alarm control does not affect rows that are part of an individually-acknowledged group. Use the single-row acknowledge button instead.
- The current user holds an authorization that allows acknowledgement. Verify the Authorization column of the Users and Roles editor. The user must be assigned to a role whose Operator actions > Alarm control > Acknowledge right is granted.
Solution: Remove the HMI Monitor Client Role
Step 1 — Identify the role assignment
- Open the TIA Portal project that contains the Unified device.
- In the project tree, expand Security settings > Users and roles.
- Select the user account that is currently logged in to runtime (e.g., "Operator", "Admin", or the customized account).
- Inspect the Assigned roles column. If "HMI Monitor Client" appears here, this is the cause.
Step 2 — Remove or replace the role
- Uncheck the HMI Monitor Client checkbox for the affected user.
- Confirm that the user still has at least one role that grants alarm acknowledgement. The default "HMI Operator" role shipped with TIA Portal templates includes this right. If a custom role is in use, navigate to Roles > [role name] > Operator actions > Alarm control and confirm that Acknowledge is enabled.
- If the user is supposed to monitor only and never acknowledge, leave the role and instead create a separate operator account with the proper role. Do not give a working operator the monitor-only role "temporarily" and forget to remove it — this is the most common field occurrence.
Step 3 — Compile and download
- Right-click the Unified device in the project tree and select Compile > Software (rebuild all).
- Download the new configuration to the runtime. For a Unified PC runtime use Online > Download to device. For a Unified Comfort Panel, transfer via TIA Portal or a USB/RDN stick.
- Log in as the affected user. Confirm that the orange Monitor only banner no longer appears in the runtime header.
Verification
After recompiling and downloading, perform the following sequence in runtime:
- Trigger the alarm by writing the configured trigger value to the HMI tag (use the IO field placed during diagnostics, or the PLC simulator).
- Clear the trigger value so the alarm transitions to Outgoing (still shown in red).
- Click Acknowledge on the single row. The alarm must move out of the visible list — for alarm class "Acknowledgement" with the default Outgoing state visible until acknowledged setting, the row disappears the moment the click is registered.
- Repeat the test using the group-acknowledge toolbar button on a second instance of the alarm.
- Open the alarm log (view > Alarm log). The event must be present with state transitions Came In > Went Out > Acknowledged and a timestamped user name in the operator column.
If the row still does not clear, capture the alarm log export and the runtime diagnostic trace (path: C:\ProgramData\Siemens\Automation\WinCCUnified\Logfiles on PC runtime). The trace file RT_Alarm_<timestamp>.log contains the authorization check failure that can confirm the role issue independent of the banner.
Script-Based Acknowledgement
When acknowledgement must be driven from a custom button (for example, a physical push-button wired to a tag, a navigation button that doubles as acknowledge, or an external system that cannot reach the alarm control toolbar), WinCC Unified exposes the alarm API through VBScript in the Scripts editor of the screen.
The following pattern acknowledges a program alarm by source name. It is the WinCC Unified equivalent of legacy WinCC's HMIRuntime.Alarm calls, adapted for the unified runtime object model.
' Attach to a button "OnClick" event
Sub AcknowledgeProgramAlarm(sourceName)
Dim alarmControl
Dim eventIds
Dim i
Set alarmControl = ScreenItems("AlarmControl1")
' Build the filter: program alarms with the matching source name
alarmControl.Filter.SourceName = sourceName
alarmControl.Filter.AlarmClassName = "Acknowledgement"
' Refresh to load current matching rows
alarmControl.Refresh()
' Iterate the active rows and acknowledge
For i = 0 To alarmControl.Rows.Count - 1
If alarmControl.Rows.Item(i).State = hmiAlarmStateCameInWentOut Then
alarmControl.AcknowledgeRow i, 0
End If
Next
End Sub
Key points when using the script path:
- The
alarmControlobject is the runtime handle of the alarm control placed on the screen. The name must match exactly (case-sensitive). - The state constant
hmiAlarmStateCameInWentOut(value 6) is the only state where acknowledge produces a visible change for a non-active alarm. - Calling
AcknowledgeRowtriggers the same authorization check as the toolbar button. If the current user is still "Monitor only", the script call returns an error code in the runtime diagnostic log and the state will not change. The role fix from the previous section is required first. - Wrap the call in
On Error Resume Nextduring commissioning to surface the error code (read it withErr.Number/Err.Description); remove the resume-next wrapper before going to production.
Troubleshooting Matrix
| Symptom | Likely Cause | Diagnostic | Fix |
|---|---|---|---|
| Alarm stays red after acknowledge; orange "Monitor only" banner visible | User assigned HMI Monitor Client role | Look for orange frame; check role in TIA Portal | Uncheck HMI Monitor Client role; assign proper operator role |
| Alarm stays red after acknowledge; no banner | Tag value still in alarm range (alarm is active, not outgoing) | Bind IO field to tag; check PLC value | Clear trigger condition; trigger value must leave alarm range |
| Group acknowledge does nothing; single-row acknowledge works | Individual acknowledgement enabled in alarm class | Open alarm class properties in TIA | Use single-row acknowledge, or change class to group acknowledgement |
| Acknowledge button greyed out | Alarm class is "Notification" (no acknowledgement required) or user role lacks right | Check alarm class and role authorizations | Change class to "Acknowledgement" or grant the role right |
| Script-based acknowledge returns error -1 / -2 | Wrong screen item name, or runtime not yet initialized | Check Err.Number; log screen load state |
Use exact ScreenItem name; defer call until screen "Loaded" event |
| Acknowledge works in Engineering runtime, fails on production panel | Project on panel not reloaded after role change | Check panel project version stamp | Re-download the full project to the panel |
| Alarm disappears immediately, no log entry for acknowledge | Alarm class set to "Without acknowledgement" with auto-clear | Check alarm class in TIA | Switch class to "Acknowledgement" if a log entry is required |
Alarm Class Configuration Reference
WinCC Unified ships with four default alarm classes. The behaviour of the acknowledge button is defined by the class, not by the tag or the script.
| Alarm Class | Acknowledgement Required | State After Acknowledge | Log Entry on Ack |
|---|---|---|---|
| Acknowledgement | Yes | Removed from active list (if outgoing) or stays as acknowledged-active | Yes |
| Notification | No | Not applicable; button disabled | No |
| System | Optional | Depends on configuration | Yes if enabled |
| Without acknowledgement / status | No | Not applicable | No |
The class "Acknowledgement" has two sub-options that affect what happens after a click:
- Single acknowledgement — one user click acknowledges one row. Required for alarms that map to a specific physical event (motor overload, limit switch) where accountability is per-event.
- Group acknowledgement — toolbar button can acknowledge all visible rows of the same class. Acceptable for nuisance alarms that occur in bursts.
User and Role Configuration Reference
Roles are defined in Security settings > Roles. Each role contains an explicit list of operator actions. The actions relevant to alarm acknowledgement are:
| Path in Role Editor | Right | Effect on Runtime |
|---|---|---|
| Operator actions > Alarm control > Acknowledge | Granted | Single-row acknowledge button works |
| Operator actions > Alarm control > Acknowledge group | Granted | Group acknowledge toolbar button works |
| Operator actions > Alarm control > Reset | Granted | Reset action on persistent alarms enabled |
| (role) HMI Monitor Client | Assigned | Read-only; ALL operator actions are denied regardless of other roles |
Runtime Diagnostic Trace
When the cause is not obvious from the UI, enable the runtime diagnostic trace to capture the authorization decision:
- On the PC runtime, open the WinCC Unified Configuration Tool.
- Navigate to Diagnostics > Trace.
- Set the trace level for category AlarmControl to Verbose and for UserManagement to Info.
- Reproduce the acknowledge attempt.
- Open the trace file in C:\ProgramData\Siemens\Automation\WinCCUnified\Logfiles\Trace. Search for the alarm's source name. The line
Acknowledge denied: user 'Operator' lacks authorization 'AlarmControl.Acknowledge'confirms the role issue independent of the orange banner.
For Unified Comfort Panels, the same trace is reachable via the panel's service interface (project tree, panel, right-click > Online > Diagnostics).
Best Practices
- Never assign HMI Monitor Client to a working operator. Create a dedicated "ViewOnly" user for read-only clients. This eliminates the entire class of "I forgot to remove the role" incidents.
- Use the IO field diagnostic trick during commissioning. It costs five minutes to wire and saves hours of "is the tag or the role wrong" arguments during SAT.
- Prefer group acknowledgement for nuisance alarms, single for accountability events. Mixed classes in the same control are confusing to operators and produce inconsistent log entries.
- Document the role mapping in the project FMEA. If an operator is locked out of acknowledge during a real fault, the production line stops. The role assignment is a safety-relevant configuration.
- Lock the role editor behind a separate engineering password. Operators should not be able to grant themselves the Monitor Client role from the runtime.
Edge Cases
Redundant runtime / load balancing. When two Unified PC runtimes serve the same project (a primary and a standby), both must receive the updated role configuration. The role store is per-runtime, not shared, and a change in TIA Portal does not propagate until each runtime is downloaded.
Open Interface clients. External systems that connect via the WinCC Unified Open Pipe can acknowledge alarms through the AlarmAcknowledge command. They are subject to the same authorization check; the operator account configured for the Open Pipe must hold the proper role.
Multi-language operator names. The user logged in for acknowledge is the one stored in the alarm log "Operator" column. When the project uses SIMATIC Logon (Windows domain authentication), make sure the domain account maps to a Unified user that holds the proper role — a common oversight is mapping the operator to a default account that has no roles assigned.
Web client vs. native panel client. The orange banner behaviour and the role enforcement are identical between the panel-native runtime and the browser-based Unified runtime. Do not assume that switching from a panel to a browser will resolve the issue — the role check is client-side, not transport-side.
FAQ
Why are my WinCC Unified alarms shown in red even after the trigger value is cleared?
Red indicates an alarm that is "Came In / Went Out" — the trigger has cleared but the alarm has not yet been acknowledged. As soon as a user with the proper role clicks Acknowledge, the row leaves the active list. The colour is correct; the missing piece is the acknowledge action.
What is the orange "Monitor only" banner in WinCC Unified runtime?
It is a visual indicator that the logged-in user holds the "HMI Monitor Client" role. This role restricts the user to read-only operations, so the Acknowledge button is rendered but every click is rejected by the runtime authorization engine. Remove the role in TIA Portal under Security settings > Users and roles to restore normal operation.
How do I acknowledge a WinCC Unified alarm from a custom button or script?
Use the alarm control's runtime API from a VBScript attached to the button: refresh the control, iterate the rows, and call alarmControl.AcknowledgeRow i, 0 on rows whose state is hmiAlarmStateCameInWentOut. The current user must still hold a role that grants alarm acknowledgement — the script does not bypass the authorization check.
Why does group acknowledge work for some alarms but not others?
The alarm class "Acknowledgement" can be configured for single or group acknowledgement. If the class uses single acknowledgement, the group toolbar button does not affect rows in that class. Either switch the class to group acknowledgement, or use the single-row Acknowledge button on each row.
Does fixing the role require a project recompile and full download?
Yes. Role and user changes are part of the project configuration, not a runtime parameter. Recompile the Unified device and download the complete project to the runtime or panel. After download, log out and back in to refresh the user's authorization token — the change is not applied to an active session.