Configuring Alarm Popup Windows in Siemens WinCC TIA Portal

When a plant floor is supervised by an HMI panel and the operator's attention is focused on production throughput, a fault that is logged silently into the alarm history is operationally worthless. ISA-18.2 and IEC 62682 both emphasize that alarms must be communicated to the operator in a way that is impossible to ignore, which is why Siemens HMI platforms expose first-class alarm objects, alarm classes, and visual escalation paths. The question that motivates this guide is a classic one: an engineer has 20 discrete, money-losing alarms on a single process, the operator does not see them when they occur, and the engineer needs a guaranteed visual popup the moment any one of those 20 conditions becomes true. This article explains how to implement that popup in Siemens WinCC TIA Portal (the platform that superseded the older WinCC Flexible runtime referenced in legacy discussions) using three different techniques: a Screen Window driven by tag visibility, an event-driven screen call attached directly to the alarm, and the native popup behavior built into the WinCC Unified alarm control.

The procedures below apply to SIMATIC Comfort Panels (TP700 / TP900 / TP1200 / TP1500 / TP1900 / TP2200), SIMATIC WinCC Runtime Advanced on IPCs, and the newer SIMATIC WinCC Unified runtime on Unified Comfort Panels (MTP700 / MTP1000 / MTP1200 / MTP1500 / MTP1900) and Unified PC systems. TIA Portal V17 and V18 are the recommended engineering environments; V16 projects can be migrated, but new projects should target V18 to align with current firmware support cycles.

1. Alarm Popup Fundamentals and the Operator-Awareness Problem

An alarm popup is fundamentally different from an alarm in the alarm log. The alarm log is a passive record; it is useful for historians, root-cause analysis, and audit trails, but it requires the operator to look at it. An alarm popup is an active, modality-raising visual event that occurs at the moment the discrete condition transitions from false to true (or, depending on alarm class configuration, on every transition including acknowledge and clear).

For the specific case of 20 critical alarms, the design intent must be:

• Single point of acknowledgement. The operator clicks one button on the popup and the originating alarm in the underlying alarm control is acknowledged simultaneously. This eliminates the double-click pattern that leads to operator mistrust of the alarm system.
• Persistent visibility until acknowledged. The popup must not auto-dismiss on its own. It must remain on top of every other screen, including any modal dialogs that the application may already have open.
• Audible signaling. The popup must be accompanied by a configured WAV file triggered by the same alarm event.
• Suppression of duplicates. If multiple alarms in the group become active within the same scan, the popup must show once with a count ("3 critical alarms"), not three overlapping popups.

These requirements map directly to the WinCC alarm architecture: each discrete alarm has a trigger tag, an alarm class, an acknowledgment model, and optional event-driven scripts. The alarm class controls color, the icon, the sound file, and whether the alarm is "must-acknowledge" or "informational."

2. Prerequisites

Before configuring the popup, confirm that the following prerequisites are satisfied on the engineering station, the PLC, and the HMI target.

The aggregated alarm bit can be implemented in the PLC with a single OR instruction (FC or STL) or in Structured Text with the following idiom:

// SCL implementation, S7-1500
"AnyCriticalAlarm" := "Alarm_01_Active" OR "Alarm_02_Active" OR
                      "Alarm_03_Active" OR "Alarm_04_Active" OR
                      // ... continue through ...
                      "Alarm_19_Active" OR "Alarm_20_Active";

Alternatively, with a single-word OR reduction (cleaner and scalable):

// SCL: pack 20 alarm bits into DWORD, then OR-fold
#AlarmWord.%X0  := "Alarm_01_Active";
#AlarmWord.%X1  := "Alarm_02_Active";
#AlarmWord.%X2  := "Alarm_03_Active";
#AlarmWord.%X3  := "Alarm_04_Active";
// ... up to %X19 for alarm 20
IF #AlarmWord <> 0 THEN
    "AnyCriticalAlarm" := TRUE;
ELSE
    "AnyCriticalAlarm" := FALSE;
END_IF;

This avoids re-engineering the trigger logic every time an alarm is added. WinCC only needs the single tag AnyCriticalAlarm to render the popup.

3. Alarm Architecture in WinCC TIA Portal

Discrete alarms in WinCC are configured under HMI Tags > Alarm (in WinCC Comfort/Advanced) or under HMI Alarms > Discrete Alarms (in WinCC Unified). Each alarm has the following configurable attributes:

For the popup to fire on the rising edge, the trigger tag's "Trigger edge" property must be set to "Rising edge (positive)" or "Both edges." Choosing "Both edges" will also fire the popup on the acknowledge event, which is usually undesirable because the popup itself drives the acknowledge. Use "Rising edge only" unless you specifically need re-alerting behavior.

4. Method 1 - Screen Window with Tag-Based Visibility (Recommended for WinCC Comfort / Advanced)

This is the most direct, lowest-risk method. A Screen Window is a HMI object on the root process screen that hosts another screen inside a rectangular region. Its visibility is bound to a tag value, which makes it ideal for alarm popups because the binding is evaluated every HMI scan.

4.1 Create the popup screen

1. In the project tree, right-click Add new screen and create Popup_Critical_Alarm.pdl (Comfort/Advanced) or Popup_Critical_Alarm screen (Unified).
2. Set the screen size to a small rectangle, e.g., 400 x 200 pixels, positioned in the upper-right corner of the root process screen for non-blocking visual placement.
3. Add an I/O field bound to the alarm number, an Alarm view object filtered to the "CriticalProcess" group, and an Acknowledge button.
4. The Acknowledge button's "Event > Press" is configured with the system function AcknowledgeAlarm targeting the active alarm, OR with the system function EditAlarm with state = "Acknowledged."

4.2 Place a Screen Window on the root screen

1. Open the main process screen (e.g., Process_Overview).
2. From the toolbox, drag Screen Window onto the screen at the same 400 x 200 position.
3. Set Properties > General > Screen to Popup_Critical_Alarm.
4. Under Properties > Animations > Visibility, add an animation driven by the HMI tag AnyCriticalAlarm with the rule: tag value = 1 -> Visible = TRUE.
5. Confirm that "Adapt to parent screen size" is disabled so the popup retains its own dimensions.

4.3 Bind the popup screen's own visibility

The Screen Window's visibility animation is the master switch. When the aggregated alarm tag goes high, the Screen Window appears, loading the popup screen and all its contents. When the operator acknowledges the alarm, the PLC clears the corresponding bit, the aggregated bit falls, and the Screen Window hides.

This pattern has three important advantages:

• No scripting is required. The configuration is purely declarative, which means it can be modified, diffed, and version-controlled as XML without executable code review.
• It scales. The trigger tag is one bit, regardless of whether the project has 20 or 200 alarms.
• It is consistent across panels. The same configuration works on TP700, TP1200, TP1900, and IPC RT Advanced without modification.

5. Method 2 - Event-Driven Screen Call via the Alarm Control

WinCC alarm controls (the standard Alarm view object in Comfort/Advanced, or the Alarm Control in Unified) expose events for IncomingAlarm, AcknowledgedAlarm, and ClearedAlarm. A script or system-function call can be attached to the IncomingAlarm event to call ActivateScreen on the popup, regardless of the current visible screen.

Configuration in WinCC Comfort / Advanced:

1. Place an Alarm view on any persistent screen (a screen that is always open, often the root). You do not need to make it visible to the operator; it can sit on an "invisible" navigation screen if preferred.
2. In Properties > Events > Incoming alarm, configure the system function ActivateScreen with target screen Popup_Critical_Alarm.
3. To avoid stacking duplicate popups, configure the popup screen itself to close the Alarm view on its "Press" event by calling ActivateScreen back to the previous screen, or use the system function AcknowledgeAlarm with the alarm that fired the popup.

This method is suitable when the operator might be on a non-root screen (e.g., a recipe screen or a trend screen) and you want the popup to appear regardless of where they are. The alarm control is on the root process screen, but because ActivateScreen is global, the popup loads on top of whatever the current screen is. For overlapping-popup suppression, combine this with the aggregated alarm tag from Method 1.

6. Method 3 - WinCC Unified Native Alarm Popup

WinCC Unified (the runtime that ships with TIA Portal V16+ for MTP panels and Unified PC) embeds popup behavior directly in the alarm control. The Alarm Control > Properties > General > ShowPopup setting enables a built-in modal popup that appears whenever an alarm is raised in the configured filter group. The popup can be styled, sized, and instrumented with custom JavaScript through the Unified event subscription model.

To configure:

1. Open the Unified alarm control on the desired screen.
2. In the alarm control properties, set ShowPopup = TRUE.
3. Define the filter expression to restrict the popup to the "CriticalProcess" alarm group.
4. Optionally bind a custom screen to PopupScreen if the default popup layout is insufficient.
5. For further customization, attach a JavaScript handler in the screen's Loaded event:

// WinCC Unified JavaScript - subscribe to alarm event
HMIRuntime.EventProvider.subscribe("Alarm.CriticalGroup",
  function(eventObj) {
    if (eventObj.eventName === "Incoming") {
      HMIRuntime.UI.OpenScreen("Popup_Critical_Alarm",
        { alarmId: eventObj.alarmId,
          alarmText: eventObj.alarmText });
    }
  });

The OpenScreen call supports passing parameters to the popup screen, which the popup can read via HMIRuntime.Runtime properties. This is the modern equivalent of the legacy C-script pattern and is the recommended approach for new WinCC Unified deployments. For the official Unified JavaScript API reference, consult the SIMATIC WinCC Unified Programming Reference manual available from the Siemens Industry Online Support portal at support.industry.siemens.com.

7. Scripting Implementation Details

Although the visibility-binding approach (Method 1) is preferred, there are cases where scripting is unavoidable: complex acknowledgement logic, conditional colors, or routing to different popups based on the originating alarm class. The following examples cover both the Comfort/Advanced VB scripting environment and the Unified JavaScript environment.

7.1 VB Script in WinCC Comfort / Advanced

The legacy WinCC Flexible C-script pattern was to write a script on the Display property of a Picture Window that returns TRUE when an alarm is active. The TIA Portal equivalent uses a similar approach with VB:

' VB Script - placed on the "Visible" property of the Screen Window
Dim alarmActive As Boolean
alarmActive = SmartTags("AnyCriticalAlarm").Value
If alarmActive Then
    Visible = True
Else
    Visible = False
End If

For per-alarm conditional logic, the script can interrogate the originating alarm:

' VB Script - on the "OnIncomingAlarm" event of an Alarm view
Sub OnIncomingAlarm(ByVal alarmObj)
    Dim alarmText As String
    alarmText = alarmObj.AlarmText
    Select Case alarmObj.AlarmClass
        Case "CriticalProcess"
            HMIRuntime.Screens("Popup_Critical_Alarm").Visible = True
            SmartTags("Popup_AlarmText").Value = alarmText
        Case Else
            ' Do not popup for non-critical alarms
    End Select
End Sub

The HMIRuntime.Screens object exposes the entire runtime's screen collection, and the Visible property is writable from any screen. The SmartTags collection provides typed access to all configured HMI tags.

7.2 JavaScript in WinCC Unified

// JavaScript - subscribe to alarm events at screen load
let popupScreen = null;

export function OnLoaded(screen) {
    popupScreen = screen;
    HMIRuntime.EventProvider.subscribe("Alarm.MyCriticalGroup",
        onAlarmEvent);
}

function onAlarmEvent(eventObj) {
    if (eventObj.eventName === "Incoming" &&
        eventObj.state === "ActiveNotAcknowledged") {
        HMIRuntime.UI.OpenScreen("Popup_Critical_Alarm",
            { alarmId: eventObj.alarmId,
              alarmText: eventObj.alarmText,
              priority: eventObj.priority });
    }
}

export function OnUnloaded() {
    HMIRuntime.EventProvider.unsubscribe("Alarm.MyCriticalGroup",
        onAlarmEvent);
}

The OnUnloaded cleanup is critical: failing to unsubscribe will cause memory leaks that manifest as progressively slower alarm response on long-running panels. The exact subscription model and event payload format are documented in the SIMATIC WinCC Unified V18 manual, entry ID 109773641, available at SIMATIC WinCC Unified Programming Reference.

8. Step-by-Step Configuration Procedure (Comfort Panel)

This procedure walks through Method 1 (Screen Window with tag-based visibility) end-to-end on a TP1200 Comfort running TIA Portal V18.

Step 1 - Create the aggregated alarm tag

1. In the PLC program, create the AnyCriticalAlarm BOOL tag as shown in Section 2.
2. In TIA Portal, expand HMI Tags > Default tag table, add a new HMI tag AnyCriticalAlarm connected to the PLC tag.
3. Set acquisition mode to "Cyclic continuous" with a 100 ms cycle (faster than 100 ms wastes panel CPU; slower than 500 ms feels sluggish for critical alarms).

Step 2 - Configure the 20 discrete alarms

1. In the HMI project tree, open HMI Alarms > Discrete Alarms.
2. Create 20 alarm entries. For each, set the trigger tag, alarm class "Errors with acknowledge," and a meaningful alarm text.
3. Set all 20 to alarm group "CriticalProcess" and enable logging.

Step 3 - Build the popup screen

1. Create new screen Popup_Critical_Alarm.
2. Add a Text field bound to the alarm number tag (this requires a tag that the PLC updates with the active alarm index, or an internal HMI tag set by the alarm's "Incoming alarm" event).
3. Add an Acknowledge button. Its "Press" event uses system function AcknowledgeAlarm with the alarm ID parameter.
4. Add a Close button using ActivateScreen with target = previous screen, or rely on the auto-hide behavior driven by the aggregated tag clearing.

Step 4 - Place the Screen Window

1. On the root process screen, add a Screen Window object at the chosen position.
2. Configure it to host Popup_Critical_Alarm.
3. Add a Visibility animation bound to AnyCriticalAlarm: value = 1 -> Visible.

Step 5 - Configure audible signaling

1. Transfer a WAV file to the panel using ProSave or TIA Portal's "Load to device > Sounds" path.
2. In the alarm class "Errors with acknowledge," set "Acoustic signal = ON" and select the WAV file.

Step 6 - Compile, download, and test

1. Right-click the HMI device and choose Compile > Software (rebuild all).
2. Download to the panel.
3. Force the aggregated bit high from the PLC watch table and verify the popup appears.
4. Acknowledge the alarm and verify the popup closes.

9. Verification, Commissioning, and Acceptance Test

The verification phase is non-negotiable for critical alarms because operator trust is destroyed by a single missed event. Use the following checklist on the HMI simulator (RT) before live deployment.

Test 6 (power-cycle persistence) is frequently missed and is the single most important test for a process where the panel reboots during shifts. WinCC alarms configured with "persistent" property will survive a reboot; non-persistent alarms will not.

10. Performance, Licensing, and Best Practices

The following engineering guidelines keep the popup implementation robust on long-running installations.

• Power tag budget. Each discrete alarm consumes one power tag license unit on WinCC Comfort/Advanced. For a project with 20 alarms, ensure the runtime license covers at least the alarm count plus the rest of the application tags. WinCC Unified uses a different model (alarm count is licensed by the runtime tier rather than per alarm).
• Avoid polling loops in scripts. Bind visibility declaratively rather than checking tags in a script loop. Polling scripts cost CPU and compete with the alarm scanner.
• One popup per alarm group. Multiple popup screens, each gated by its own aggregated tag, are acceptable (e.g., "critical," "warning," "info") but should be visually differentiated by color and position.
• Suppress non-essential transitions. If the alarm class is "Errors without acknowledgment," do not use the visibility-binding approach; the popup will appear but cannot be dismissed. Use a dedicated alarm view with a "Clear" button instead.
• Localize all alarm text. Configure alarm text in all project languages. The popup displays text in the operator's currently selected runtime language.
• Version control the .ap17 / .ap18 file. TIA Portal projects are XML-based and can be diffed in Git, but the alarm configuration is spread across multiple XML files. Use TIA Portal's "Project comparison" tool to detect drift between commissioning and production versions.

11. Troubleshooting Matrix

12. Frequently Asked Questions