WinCC Unified Alarm Filter Script Removed in V18 Workaround Guide

WinCC Unified Alarm Filter Script Removed in V18: Complete Workaround Guide

Siemens WinCC Unified (TIA Portal) introduced a regression in V18 where the ability to dynamize the alarm control filter through a script was silently dropped from the engineering environment. Projects migrated from V17 lose the filter script at compile time, and the script editor no longer offers the alarm control's filter property as a scriptable target. This reference documents the affected versions, the engineering-side root cause, and three field-verified workarounds that restore filter dynamization without requiring an upgrade to V19.

1. Problem Details

1.1 Observed Symptom

On a WinCC Unified alarm control object (HMI tag-based alarm or controller-based alarm), the engineer previously attached a JavaScript to the Filter property in V17. After migrating the project to TIA Portal V18:

• The filter script is no longer visible in the Events or Properties dialog of the alarm control.
• The Filter property does not appear in the script editor's object list when attaching a script.
• Existing V17 scripts fail to compile or are stripped during migration.
• The filter UI in runtime is functional for static text filters, but dynamic value-based filtering no longer works.

1.2 Reproduction Sequence

1. Create a TIA Portal V17 project with WinCC Unified PC Runtime or Unified Comfort Panel.
2. Add a screen containing an Alarm Control object (e.g., AlarmControl_1).
3. Right-click the Filter property of the alarm control and attach a JavaScript that returns a filter expression (e.g., return "AlarmClassName == 'AlarmHigh'";).
4. Compile and download. The filter dynamization works in runtime.
5. Migrate the project to TIA Portal V18 SPx (any SP level to date).
6. Open the same alarm control. The Filter property no longer offers a script trigger.

1.3 Functional Impact

2. Affected Versions and Products

3. Root Cause Analysis

3.1 Engineering System Change

In V18, the alarm control object model was refactored. The Filter property was reclassified from a scriptable dynamization target to a static configuration property on the alarm control property sheet. The change is visible in the TIA Portal property inspector: in V17 the property shows a small lightning-bolt icon next to the Filter field, indicating a script trigger is available; in V18 that lightning-bolt icon is absent.

3.2 Why the Runtime Did Not "Break"

The runtime API for alarm control filtering was not removed. The JavaScript engine inside WinCC Unified still accepts filter assignments when the script runs in a context where it can reach the alarm control item (e.g., through Screen.Items or through a function parameter). What changed is purely the engineering-side dialog binding that previously let an engineer "wire" a script to the filter without writing code.

3.3 Object Model Reference (V18)

4. Workaround A: Access via Screen.Items

The most portable workaround is to call the filter from a global JavaScript module or from a button's Click event, reaching the alarm control through the screen collection.

4.1 Step-by-Step Implementation

1. In the TIA Portal project tree, expand WinCC Unified > Screens and select the screen that contains the alarm control (e.g., Screen_AlarmOverview).
2. Open the Scripts node under the screen and create a new JavaScript function called ApplyAlarmFilter.
3. Insert the function body shown below.
4. Wire the function to a UI control (button, IO field change event, or a tag-triggered scheduled task).

4.2 Code: Global JavaScript Module

// File: Scripts\Global.js (WinCC Unified global module)
// Applies a dynamic filter expression to the alarm control on the active screen.
// Parameters:
//   screenName    : string  - Name of the screen containing the alarm control
//   alarmCtrlName : string  - Name of the alarm control object on the screen
//   filterExpr    : string  - Filter expression understood by the alarm control
// Returns:
//   boolean       - true if filter was applied, false if control not found
export function ApplyAlarmFilter(screenName, alarmCtrlName, filterExpr) {
    try {
        let screen = Screen.Items(screenName);
        if (screen === null || screen === undefined) {
            HMIRuntime.Trace("ApplyAlarmFilter: screen not found - " + screenName);
            return false;
        }
        let alarm = screen.Find(alarmCtrlName);
        if (alarm === null || alarm === undefined) {
            HMIRuntime.Trace("ApplyAlarmFilter: alarm control not found - " + alarmCtrlName);
            return false;
        }
        alarm.Filter = filterExpr;
        // Re-evaluate to ensure runtime applies the new expression
        if (typeof alarm.ApplyFilter === "function") {
            alarm.ApplyFilter();
        }
        return true;
    } catch (e) {
        HMIRuntime.Trace("ApplyAlarmFilter exception: " + e.message);
        return false;
    }
}

4.3 Code: Button Click Event Script

// Triggered by a "High Priority" push button on Screen_AlarmOverview
export function Btn_HighPriority_Click(item) {
    // Hardcoded filter expression for high-priority active alarms only
    let filter = "(Priority >= 2) AND (State = 1)";
    let screen = Screen.Items("Screen_AlarmOverview");
    let alarm  = screen.Find("AlarmControl_1");
    alarm.Filter = filter;
    alarm.ApplyFilter();
}

4.4 Filter Expression Grammar

WinCC Unified filter expressions use the same grammar as WinCC Professional. The following operators and operands are supported on the Filter property:

4.5 Verification of Workaround A

1. Compile the project and start the runtime simulator.
2. Click the configured button. Open the HMI trace viewer (HMIRuntime.Trace output visible in the diagnostics window).
3. Confirm no "screen not found" or "alarm control not found" messages appear.
4. Confirm only alarms matching the filter expression are visible in the alarm control.
5. Toggle a priority-1 alarm in the PLC and verify it does NOT appear when filtered for priority >= 2.

5. Workaround B: Use the item Parameter from a Dynamizable Property

Where the alarm control's Filter property itself does not offer a script trigger, you can attach a script to any other scriptable property on the alarm control and use the implicit item parameter to reach the control. This works because, in WinCC Unified, any property script receives the object as the item argument by default.

5.1 Implementation

1. Open the alarm control properties in TIA Portal V18.
2. Select a property that still offers a script trigger (e.g., Visible, Enabled, or any custom property).
3. Attach a JavaScript. The function signature automatically receives item representing the alarm control.
4. Set the filter on the item reference.

5.2 Code: Filter via Visible Property Script

// Attached to the Visible property of AlarmControl_1.
// The "item" parameter is the alarm control object itself.
// Using it we can reach the filter even though the Filter
// property no longer exposes a script trigger in V18.
export function AlarmCtrl_Visible(item) {
    // Always keep the control visible
    let visible = true;

    // Dynamic filter logic that was previously bound to the Filter event
    let priorityTag = Tags("HMI_DB.FilterPriority").Read();
    let stateMask   = Tags("HMI_DB.StateMask").Read();

    let filterExpr = "Priority >= " + priorityTag + " AND State = " + stateMask;
    item.Filter = filterExpr;
    if (typeof item.ApplyFilter === "function") {
        item.ApplyFilter();
    }

    return visible;
}

5.3 Scheduled-Task Variant (1-second polling)

// Triggered every 1000 ms by a WinCC Unified scheduled task named
// "AlarmFilterRefresh". Reads the current tag values and applies the filter.
export function AlarmFilterRefresh_Tick() {
    let alarm = Screen.Items("Screen_AlarmOverview").Find("AlarmControl_1");
    let prio  = Tags("HMI_DB.FilterPriority").Read();
    let state = Tags("HMI_DB.StateMask").Read();

    alarm.Filter = "Priority >= " + prio + " AND State = " + state;
    alarm.ApplyFilter();
}

6. Workaround C: Use the Alarm Filter Criteria String Builder

For projects that only require static filter logic with a few operator-selectable conditions, the alarm control's built-in filter criteria editor remains functional in V18. This is not a script solution, but it eliminates the need for a script altogether.

1. Open the alarm control configuration.
2. Select the Filter tab.
3. Click Criteria and define conditions using the dialog (e.g., Priority >= 2).
4. Save and download. The filter is applied at runtime without any scripting.

For projects that previously used dynamic filter strings driven by tag values, this approach requires migrating logic into multiple configured filter profiles that the user selects at runtime via FilterCriteria property (R/W).

7. Migrating V17 Scripts to V18: Step-by-Step

Use the following migration checklist when porting an existing V17 alarm filter script to a V18 project.

1. Inventory the existing scripts. In V17, export the script library and document each alarm control that uses filter scripting. Note the alarm control name, screen, and the filter expression source (tags, constants).
2. Decide on the workaround strategy:
   • If the filter expression depends on runtime tags that change frequently, use Workaround B (item parameter) with a scheduled task or tag trigger.
   • If the filter expression is set only on user actions (button presses), use Workaround A (Screen.Items).
   • If the filter expression is essentially static, use Workaround C (built-in criteria).
3. Refactor the function signature to receive an item or screenName/alarmCtrlName argument. Do not rely on implicit ES-side binding to the alarm control.
4. Validate filter grammar against the table in §4.4. Note that = for comparison (not ==) is the WinCC filter idiom in both V17 and V18, although == is also accepted.
5. Add exception handling around every alarm.Filter = assignment. A null reference will throw a runtime error visible in the HMI diagnostics window.
6. Compile and run the simulator before downloading to a panel. The simulator respects HMIRuntime.Trace and surfaces null-reference exceptions in the log.
7. Document the workaround in the project README so future engineers understand why the script is not bound to the alarm control's Filter property in the ES.

8. Performance and Trace Considerations

9. V19 Roadmap and Siemens Support Path

According to Siemens technical support escalation feedback, the alarm control filter scripting capability is expected to be reinstated in TIA Portal V19. Until V18 ES receives an update that restores the dialog-level binding, the workarounds in §4 and §5 are the only supported paths.

To track the official fix:

1. Visit the Siemens Industry Online Support entry referenced in the V18 release notes: TIA Portal V18 Update 1 release notes (Siemens Support entry 109807123).
2. Search the Siemens Support database for "WinCC Unified alarm control filter script" and subscribe to the entry. New updates trigger an email.
3. Open a support request (Siemens ID required) referencing the V18 regression and request notification when V18 ES or V19 ES restores the feature.

10. Verification Checklist Before Going Live

11. Symptom-to-Workaround Matrix

12. Related Siemens Documentation References

• TIA Portal V18 Update 1 release notes and updates (Siemens Support 109807123)
• Example of configuring the alarm view (WinCC RT Professional) - TIA Portal documentation portal
• WinCC Unified System Manual, Chapter "Alarm Control" (TIA Portal V18 help, installed locally or via Siemens Support entry 109811387)
• WinCC Unified Scripting Reference, "Screen.Items" and "Screen.Find" sections (TIA Portal V18 help)