WinCC Active Alarm Count: VBScript and Unified Methods

Overview: Counting Active Alarms in WinCC Runtime

Displaying the live count of active (pending, unacknowledged, or currently raised) alarms is one of the most common WinCC HMI/SCADA requirements. Operators need to see at a glance whether the process is in alarm, and the number itself becomes a key process KPI for status overviews, bar graphs, and dashboard tiles. Siemens offers two distinct scripting surfaces depending on the platform generation:

• WinCC 7.x (Classic, COM-based runtime): the AlarmControl ActiveX control exposes alarm statistics through its status bar; VBScript reads these values via StatusbarElementText by setting StatusbarElementId.
• WinCC Unified (TIA Portal V17+): the modern JavaScript-based API exposes HMIRuntime.Alarming.GetActiveAlarms() (and related methods) to return structured alarm data including counts.

Both paths return the count you need, but they live in different runtime models, compile against different object models, and behave differently under load. The remainder of this reference covers both, plus the limits, caveats, and verification steps that come from field deployments. The Unified approach is documented by Siemens in support entry 109955144, and the AlarmControl limits are listed in the TIA Portal V20 operating manual at Alarm Control Overview (RT Unified).

Prerequisites

Before implementing active-alarm counting, confirm the following on the engineering station and target runtime:

• WinCC 7.4 SP1 / 7.5 / 7.5 SP1 (or matching the version installed on the target OS) with the AlarmControl licensed and present in Graphics Designer.
• For Unified: TIA Portal V17 or later with WinCC Unified Comfort Panel or PC Runtime V17/V18/V19/V20 installed.
• Configured alarm classes (e.g., "Errors", "Warnings", "System") and an active alarm logging / message configuration with at least one message that can be raised in test.
• For scripts that run on a button event, the button must have authorization configured (operator-level is sufficient for read operations).
• For scripts that write to an internal tag, the internal tag must exist with the correct data type (Int or DInt) and be in the runtime tag list.

Method 1 - WinCC 7.x AlarmControl + StatusbarElementId

The classic WinCC AlarmControl is an ActiveX control embedded in a process picture. It already computes internal counters (pending messages, messages in list, to-acknowledge) and renders them in the configurable status bar. The VBScript trick is to point the status bar at a specific element, read the displayed text, and bind that text to a static field, IO field, or bar display.

How StatusbarElementId Works

Each status bar element (a small text/icon area along the bottom of the AlarmControl) corresponds to a numeric ID. By setting objA.StatusbarElementId = N on the runtime AlarmControl object, you tell the control which counter the next read of StatusbarElementText should return. The IDs are stable for a given WinCC version but are not formally published as a public API contract; you must enumerate them in Graphics Designer on a per-project basis.

Setting StatusbarElementId does not change the visible status bar of the control; it only changes which element the API will return on the next read of StatusbarElementText. This makes it safe to use a hidden AlarmControl purely as a counter source.

StatusbarElementId Reference

The exact ID-to-element mapping depends on the AlarmControl configuration in the project (which status bar elements are enabled and in what order). The table below lists the elements that the WinCC 7 AlarmControl typically exposes; verify the order in Graphics Designer before deploying.

VBScript Implementation

The canonical pattern is: a hidden (or visible) AlarmControl on the picture reads the counter, a StaticText or IO field displays it, and a button (or scheduled Global Script action) triggers the refresh. The following code is a working example for WinCC 7.x.

Option Explicit

' --- Read active alarm count from AlarmControl status bar ---
Dim objA    ' AlarmControl
Dim objT    ' StaticText / IO field that displays the number
Dim lngId   ' Status bar element ID to read

Set objA = HMIRuntime.ActiveScreen.ScreenItems("Control1")
Set objT = HMIRuntime.ActiveScreen.ScreenItems("StaticText1")

' ID 1 = number of pending (active) messages in standard WinCC 7 builds.
' Verify by opening the AlarmControl properties -> Status Bar and counting
' the elements in order; the index is 1-based.
lngId = 1

objA.StatusbarElementId = lngId
objT.Text = objA.StatusbarElementText

For automatic refresh without operator action, schedule the same body in a Global Script action triggered by a 1-second standard cycle. To avoid 1 Hz polling on a 10,000-tag project, use a trigger tag that the alarm subsystem sets on any state change, then evaluate that trigger in the action.

Showing and Hiding the AlarmControl on Demand

Operators frequently want the count to be visible while the AlarmControl window itself stays hidden. Wire the AlarmControl to a button, then toggle the Visible property:

Option Explicit
Dim objA
Set objA = HMIRuntime.ActiveScreen.ScreenItems("Control1")
objA.Visible = Not objA.Visible

This "give-away" approach keeps screen real estate small while still letting the count update. The AlarmControl must remain in the picture tree (just Visible = False) so its internal counter continues to track live alarms. Removing the control from the screen tree stops the counter.

Bar-Graph or Trend Display

For a bar visualization, bind an IO field or bar object to an internal tag that the script writes, then assign the bar's process value to that tag. The intermediate tag pattern is preferable to direct scripting on the bar because it lets you reuse the count for archive logging and trend displays.

Method 2 - WinCC Unified Alarming API

WinCC Unified replaces the COM-based AlarmControl model with a JavaScript API surfaced through HMIRuntime.Alarming. The active-alarm count can be read either by enumerating the active-alarm array or by subscribing to alarm-state events.

Reading the Count via GetActiveAlarms()

Siemens support entry 109955144 documents Alarming.GetActiveAlarms() for Unified. The method returns an array of currently active alarm records. A simple count is the array length:

// WinCC Unified - read number of active alarms (V20 behavior)
export async function GetActiveAlarmCount() {
  try {
    const result = await HMIRuntime.Alarming.GetActiveAlarms({});
    if (result && Array.isArray(result.Alarms)) {
      return result.Alarms.length;
    }
    return 0;
  } catch (e) {
    HMIRuntime.Trace("GetActiveAlarmCount failed: " + e);
    return -1;
  }
}

The asynchronous form is the supported pattern for V17+. Wrap the call in a try / catch in production code so a transient failure does not crash the screen or leave a stale value in the bound tag.

Subscribing to Alarm Events for Real-Time Count

Polling GetActiveAlarms() on a 1 Hz cycle works, but the cleaner pattern in Unified is event subscription. Register a callback that increments or decrements a counter on OnAlarmActive / OnAlarmCleared:

// WinCC Unified - subscribe to active-alarm events
let activeCount = 0;

HMIRuntime.Alarming.OnAlarmActive = function(alarm) {
  activeCount += 1;
  Tags("U_ALARM_COUNT").Write(activeCount);
};
HMIRuntime.Alarming.OnAlarmCleared = function(alarm) {
  if (activeCount > 0) activeCount -= 1;
  Tags("U_ALARM_COUNT").Write(activeCount);
};

Use the internal tag U_ALARM_COUNT as the binding target for the bar or text display. This eliminates polling jitter and produces a count that is consistent with the runtime's own state model. For multi-screen projects, register the subscription once on a global module and unsubscribe on RT shutdown to avoid double-counting.

Performance Limits (TIA Portal V20)

Unified Runtime imposes hard and soft limits on the alarm subsystem. From the TIA Portal V20 operating manual for PC RT Unified, AlarmControl overview (Alarm Control Overview (RT Unified)):

Counting Formula for Capacity Planning

For estimating storage and CPU load, the expected sustained count C over a time window T is approximately:

where R is the raise rate (alarms/sec) and D is the discharge rate (alarms cleared/sec). At steady state, C equals the configured alarm buffer. If R > D for an extended window, the buffer fills and the runtime drops oldest entries. The same arithmetic applies when sizing the V20 alarm buffer: target a buffer at least 2x the expected peak C to absorb bursts.

Active vs Logged Alarm State

Active-alarm count is not the same as the alarm log count. Many engineers confuse the two and end up with a script that returns the size of the log archive. The distinctions:

Configuration Steps

In Graphics Designer (WinCC 7)

1. Insert the AlarmControl from the Smart Object / Control palette onto the picture. Name it Control1 (or your preferred name).
2. Open the AlarmControl properties dialog. In the Status Bar section, enable the elements you need (Pending, In List, To Acknowledge). The order you enable them determines the index in the API.
3. Add a StaticText (or IO field) to the picture and name it StaticText1. This is the destination for the count.
4. Open the VBScript editor and paste the read script. Set the trigger to a button event or a 1 s standard cycle in Global Script.
5. Optional: set Control1.Visible = False in Graphics Designer so the operator only sees the count, not the alarm list.
6. Add a button to toggle visibility using the toggle script above.
7. Compile and Run the runtime; raise a test alarm (e.g., set a tag to 1) and confirm the count increments.

In TIA Portal (WinCC Unified)

1. Create a Unified HMI device in the TIA project. Add an internal tag U_ALARM_COUNT of type Int.
2. In the HMI screen, drop a text field or bar that should display the count.
3. Bind the text field's "Text" property to the tag U_ALARM_COUNT via a dynamic animation, or bind the bar's "Process value" property to the same tag.
4. Add a Scheduled task or screen-event script that calls HMIRuntime.Alarming.GetActiveAlarms() and writes the array length to U_ALARM_COUNT.
5. For event-driven counting, register the OnAlarmActive and OnAlarmCleared callbacks from the screen's "Loaded" event or from a global module loaded once at RT startup.
6. Compile the HMI and download to the Unified Runtime. Raise a test alarm and verify the count updates without a refresh cycle.

Edge Cases, Security, and Field-Proven Caveats

• ID 37 misconception. Some legacy scripts hard-code StatusbarElementId = 37. This is not a published index in current WinCC 7 builds and often returns blank. Replace with the verified local index (typically 1 for "pending").
• Count not updating. If the AlarmControl is removed from the picture entirely (not just hidden), its internal counter stops tracking live alarms. Keep the control in the screen tree, even if Visible = False.
• Count includes hidden or filtered alarms. The "pending" counter is global to the alarm subsystem, not scoped to the current filter. Operators may see a count of 15 but only 4 rows in the list because the list filter is narrower. Document this in the operator manual.
• Acknowledged-but-active alarms. Some sites expect the count to drop on acknowledgment. In WinCC, "active" and "to-be-acknowledged" are separate states. A count via ID 1 only decrements when the alarm is both acknowledged and cleared (or returns to OK).
• Unified restart behavior. On Unified RT restart, the alarm log persists but the in-memory active-alarm list is rebuilt from the controller subscriptions. Expect a 2-5 second window where the count is "0" before subscriptions re-establish. Schedule the first poll after a 5 s delay or use the event-driven pattern from a global module.
• Performance under alarm flood. Polling GetActiveAlarms() at 10 Hz during a 1,000-alarm burst will burn CPU on the RT. Switch to the event-subscription pattern for high-flood systems. The V20 continuous-load ceiling of 20 alarms/sec is a hard limit, not a recommendation.
• Multi-client divergence. In a Unified distributed system, each client's count reflects its own subscription. The server's "global" count is only visible if a client explicitly queries the server's alarm aggregate via a tag provider.
• Authorization. Reading the count is read-only and does not require elevated rights, but acknowledging or clearing does. Make sure the button wiring that triggers the toggle-visibility script is not blocked by the runtime's user-management configuration. The WinCC 7 Information System documents operator authorization under "User Administration" in the WinCC online help.
• Counting on alarm-bar vs alarm-control. The AlarmBar control (single-line, no status bar) used in some compact panels does not expose StatusbarElementId. For AlarmBar, count via a tag you increment in a message-triggered Global Script action, or migrate to a slim AlarmControl with the status bar hidden.
• Time-zone and shift-aware counting. The active-alarm count has no time component, so a "shift total" cannot be derived from the live count alone. Use the alarm archive (WinCC Alarm Logging in classic, Logging tag provider in Unified) for shift totals.

Troubleshooting Matrix

Verification Procedure

After deployment, verify the count is live and accurate with the following controlled test:

1. Open the runtime and clear the AlarmControl with "Reset" so the count starts at 0.
2. Raise a known alarm (e.g., force a tag to the alarm-trigger value). Confirm the count increments to 1 within one refresh cycle.
3. Raise a second alarm from a different class. Confirm the count is 2.
4. Acknowledge both alarms via the AlarmControl. Confirm the "to-ack" status bar element decrements but the "active" count remains 2 (alarms still pending).
5. Clear both alarms (return tags to OK). Confirm the active count returns to 0.
6. Open a second client (Unified) or a second picture (WinCC 7) and confirm the count is consistent.
7. Force a controller restart (Unified) or RT restart (WinCC 7) and confirm the count re-establishes within the documented window (2-5 s for Unified; immediate for WinCC 7 if the AlarmControl persists in the loaded picture).
8. Document the IDs used, the script file name, and the cycle time in the project handover log for the next maintainer.

FAQ