Per-Instance Alarm Filtering in TIA Portal LBP Faceplates

1. The Multi-Instance Alarm Filtering Problem

Template faceplates in TIA Portal are designed for reuse: a single graphic is instantiated multiple times on a process screen, each instance bound to a different PLC tag prefix. Motor faceplates in the Siemens LBP demo project follow this pattern - one faceplate type is instanced for every drive, conveyor, or pump. Each instance opens its own popup alarm view when the operator requests diagnostic information.

The non-trivial requirement is that the alarm popup must show only the alarms for the motor that opened it. Without filtering, the WinCC Alarm Control shows the full plant alarm buffer, which is operationally useless when 30 motors are on screen and the operator is inspecting motor M_17. The expected behavior is:

1. Operator clicks the alarm icon on the M_17 faceplate.
2. The popup faceplate opens with an embedded alarm view.
3. The alarm view automatically scopes its SQL/text filter to the M_17 tag-prefix namespace.
4. When the operator closes the popup, the alarm view either clears or retains last filter for audit.

The LBP reference implementation solves this elegantly, but the dynamization that drives it is hidden inside a property event that is not obvious to engineers inspecting the project for the first time. The filtering is not performed by a script attached to the alarm control itself - it is performed by a script attached to the Modified event of a Name object that is dynamically rewritten when each faceplate instance is opened.

2. Prerequisites: TIA Portal, LBP Library, and WinCC Versions

Before implementing per-instance alarm filtering, confirm the engineering environment matches the LBP reference design.

Reference documentation that should be on hand during implementation:

• SIMATIC WinCC Unified - Programming and Operating Manual (Siemens Support entry)
• SIMATIC TIA Portal - WinCC Professional V18 Function Manual
• TIA Portal - LBP Reference Library Description and Demo Project

3. How the LBP Library Achieves Instance-Specific Filtering

The LBP motor faceplate is structured in three nested layers:

1. Base faceplate - the visible motor graphic, with TagPrefix interface property.
2. Alarm popup faceplate - a modal screen opened via SiVARc and the Screenhandling script.
3. Embedded alarm control - a WinCC Alarm Control inside the popup that displays the message buffer.

The TagPrefix property is propagated from the HMI tag to the popup faceplate's interface. When the popup is opened, the LBP code rewrites the Name property of a hidden auxiliary object so that the new value embeds the TagPrefix string. Because the Name property changed, its Modified event fires. The script handler attached to Modified reads the new name, extracts the tag prefix, and pushes that prefix into the alarm control's MsgFilterSQL property (WinCC Unified) or MsgFilter collection (WinCC Professional).

The full chain is therefore:

1. PLC FB multi-instance data block tag prefix flows into faceplate TagPrefix interface property.
2. SiVARc + Screenhandling script opens the popup and assigns a unique, instance-scoped string to the Name property.
3. WinCC fires the Modified event on the Name object.
4. Script handler on Modified event computes the alarm filter expression and assigns it to the alarm control.
5. Alarm control refreshes, now scoped to the motor instance.

4. The Modified Property Event Mechanism Explained

Every dynamizable object in WinCC Unified and WinCC Professional exposes a Modified event on its string and variant properties. The event fires whenever the property value changes from one value to a different value at runtime - it does not fire on the initial assignment unless the value differs from the configured default.

The Modified event on Name is preferred for alarm filtering because:

• The Name property is purely textual and not visually used by the alarm control logic.
• It is guaranteed to change once per popup open when the TagPrefix is concatenated into the new value.
• It avoids triggering the event on background process updates that would re-fire the filter script unnecessarily.

5. Implementing the Tag Prefix and Name Dynamization

Step 1 - expose the TagPrefix to the popup faceplate interface:

1. Open the popup faceplate in the TIA Portal editor.
2. Right-click the faceplate root and select Interface > Properties.
3. Add a new property of type String named TagPrefix.
4. Set the property's Visible in HMI flag so it can be assigned when the popup is instantiated.

Step 2 - add a hidden auxiliary object:

1. Inside the popup faceplate, place a Text field with the Visible property set to false (so the operator never sees it).
2. Name this object AlarmFilterTrigger. Its default Name property must be set to a placeholder such as _UNSET_.

Step 3 - dynamize the Name property to include the TagPrefix:

1. Select AlarmFilterTrigger.
2. Open Properties > Properties > Name.
3. Create a script dynamization that returns: "ALARM_FILTER_" + Faceplate.Properties.TagPrefix.

For WinCC Unified JavaScript the dynamization body is:

return "ALARM_FILTER_" + Faceplate.Properties.TagPrefix;

For WinCC Professional VBScript use:

Dim sPrefix
sPrefix = SmartTags("Faceplate.Properties.TagPrefix")
Item.Name = "ALARM_FILTER_" & sPrefix

Every time the popup is opened with a different TagPrefix the Name changes, so the Modified event fires.

6. Script Code for Alarm Filter Application

6.1 WinCC Unified (JavaScript)

Attach the following script to the Modified event of the Name property of AlarmFilterTrigger:

// Triggered when AlarmFilterTrigger.Name changes
(function() {
    // Resolve the alarm control by name (assume control is named "MotorAlarmControl")
    var alarmControl = Screen.Items("MotorAlarmControl");
    var prefix = Faceplate.Properties.TagPrefix;

    // Build a SQL filter expression that matches alarms raised
    // with Area = 'MOTOR' and the tag-prefix specific source.
    var filterSQL =
        "(AREA = 'MOTOR') AND " +
        "(SOURCE LIKE '" + prefix + \\%.\\%' )";

    // Apply the filter to the alarm control
    alarmControl.MsgFilterSQL = filterSQL;

    // Optional: log for diagnostics
    HMIRuntime.Trace("Alarm filter applied for prefix: " + prefix);
})();

6.2 WinCC Professional / Comfort (VBScript)

For Comfort Panel runtime, attach the equivalent VBScript to the Modified event of the Name property:

' --- Modified event handler on AlarmFilterTrigger.Name ---
Dim oScreen
Dim oAlarm
Dim sPrefix
Dim sFilter

Set oScreen = HMIRuntime.Screens(HMIRuntime.BaseScreenName)
Set oAlarm = oScreen.ScreenItems("MotorAlarmControl")

sPrefix = SmartTags("TagPrefix")
sFilter = "AREA = 'MOTOR' AND SOURCE LIKE '" & sPrefix & ".%'"

oAlarm.MsgFilterSQL = sFilter

7. Wiring the Popup Alarm View into the Faceplate

Step-by-step wiring using the LBP Screenhandling script conventions:

1. Create a new screen FP_Alarm_Motor. Place the popup faceplate as the root.
2. Place the WinCC Alarm Control inside the popup, name it MotorAlarmControl.
3. Configure the alarm source under Alarm Control > Properties > Message Selection: enable System-defined messages and User-defined messages; set the message class filter to your MOTOR class.
4. Open the parent motor faceplate, find the alarm icon button, and assign the click event to call the LBP Screenhandling macro. Typical call form:
   

   Screenhandling.OpenPopup("FP_Alarm_Motor", Faceplate.Properties.TagPrefix);

5. Inside Screenhandling.OpenPopup, ensure the TagPrefix interface parameter of the popup faceplate is assigned from the call argument.

8. Configuring the Alarm Control Filter Source

The alarm control filter relies on the WinCC message configuration having a source naming convention that the script can match. Recommended convention:

When the operator opens the M_17 popup, TagPrefix = DB17_HMI.DB_Motor_17. The filter SOURCE LIKE 'DB17_HMI.DB_Motor_17.%' returns only alarms raised by that data block. The wildcard % matches sub-elements such as M1 inside the block.

9. Verification and Runtime Testing Procedure

1. Compile the project to the WinCC Unified RT or the Comfort Panel.
2. Start runtime. Confirm that the plant screen shows several motor faceplates, each with a distinct TagPrefix.
3. Trigger an alarm on motor M_17 (force the overload bit in the PLC, or use the alarm simulator).
4. Trigger an alarm on motor M_22.
5. Click the alarm icon on M_17 faceplate.
6. Verify the popup opens and the alarm list contains the M_17 alarm only.
7. Close the popup and open the M_22 alarm view. Confirm the M_22 alarm appears and the M_17 alarm is absent.
8. Inspect the WinCC Unified trace output (HMIRuntime.Trace) to confirm the filter expression logged matches the expected TagPrefix.
9. Close the popup and re-open the M_17 view. Confirm the filter still applies - because the Name property changes again on each open, the Modified event re-fires.

Pass criterion: the alarm control shows only alarms whose SOURCE matches the active TagPrefix, regardless of popup open/close cycles.

10. Troubleshooting Matrix

11. Practical Notes and Field-Commissioning Caveats

• Filter syntax differs by runtime. WinCC Unified uses standard SQL syntax with LIKE and %. WinCC Professional supports a SQL subset; do not assume portability without testing.
• Multi-user ES stations. When several engineers edit the same project, the AlarmFilterTrigger placeholder Name must remain unique per project; do not duplicate the object name across popups, because the alarm control references it by name.
• Performance. The Modified event triggers once per popup open. Avoid assigning the dynamization to a frequently updated property such as Caption; the filter recompute is cheap but the alarm query can be expensive on large plant buffers.
• Audit traceability. Pair the HMIRuntime.Trace log with the WinCC Unified audit option so each filter change is recorded with operator ID, timestamp, and TagPrefix.
• Tag-prefix uniqueness. The LBP library assumes every motor instance has a unique TagPrefix. If two motors share a prefix, their alarms will be visible in both popups. Verify by inspecting the HMI tag table.
• Scriptable alternative. If your version of WinCC Unified supports scheduled functions, the Modified-on-Name trick can be replaced by a scheduled function that polls Faceplate.Properties.TagPrefix and updates the filter every 500 ms. The Modified-on-Name approach is preferred because it is event-driven and lighter on the runtime.

12. Frequently Asked Questions