Configuring TIA Portal HMI Alarm Class Priority Order

Problem Statement

An S7-300 PLC reports a mix of alarm severities to a TP2200 Comfort HMI engineered in TIA Portal V12/V13 with WinCC Comfort/Advanced. Discrete alarm bits are configured and the alarm view displays them correctly, but the order in the runtime is strictly chronological. A temperature-limit alarm that arrives 5 minutes after a low-pressure fault is rendered above the low-pressure fault, even though the operator must see the low-pressure fault first. The required behavior is to display alarms grouped by class, with the most critical class always on top, and to use time only as the secondary sort key within a class.

This article documents the configuration path to achieve that behavior on a TP2200 Comfort panel, including the limits of the chronological default, how to create and order user-defined alarm classes, and how the WinCC alarm view combines class priority with time-of-occurrence in runtime.

Prerequisites

WinCC Alarm Architecture Overview

WinCC Comfort / Advanced organises runtime alarms into three orthogonal structures:

• Alarm class — determines the visual style (icon, foreground and background color), the acknowledgment model, and the default priority of every alarm assigned to it. The class also controls how the alarm behaves in the audit / non-logged runtime (NLR) buffer.
• Alarm — a single event (discrete / bit-triggered, analog-limit, or PLC-reported) with its text, tag trigger, and a reference to one alarm class.
• Alarm view / alarm line / alarm window — the visualization. The view receives alarms from all classes; the class controls the order in which they are displayed.

According to the Siemens TIA Portal help, "in addition to the acknowledgment behavior, when creating a new alarm class, you define the default priority of alarms of this alarm class." Useful information on alarms — TIA Portal documentation. This priority is the property the runtime uses to order the alarm buffer.

Alarm Class Priority Model

The WinCC alarm class is a categorical priority, not a numeric one in the runtime. The class list shown in the project tree is ordered from "most important" (top) to "least important" (bottom). The runtime sorts the alarm buffer first by that order and then by the time the alarm came in (chronological within the same class).

User-defined classes inherit the same model: each carries an acknowledgment model, color / icon and a display priority. The classes are listed in the project tree under HMI alarms > Alarm classes in the order the runtime uses to sort.

For comparison, some non-Siemens SCADA packages expose per-tag numeric priority. AVEVA InTouch, for example, defines an alarm priority of 1–999 with 1 being the most severe (see the AVEVA InTouch alarm priorities documentation). WinCC on a TP/Comfort panel does not use that model; priority is set per class, not per individual alarm value, and the runtime sort is categorical.

Alarm Visualization Controls

Three different controls consume the alarm buffer; each has slightly different behavior with respect to priority sorting.

When the field report reports "only last error in the first line of error or alarm in the view" and the desired behavior is "important Alarm group (group : ID 1 to 99) first line", the fix is to put the group in its own class and put that class at the top of the list — both the alarm line and the alarm view then pick that class first.

Configuring Alarm Class Priority — Step-by-Step

The class ordering in the project tree is the runtime sort order. To put a "temperature" class above a generic "warning" class, you do not assign a numeric value — you move the class up or down the list. The procedure:

1. In the TIA project tree, expand the HMI device (TP2200) and open HMI alarms > Alarm classes.
2. Right-click Alarm classes and choose Add new alarm class. Give it a name (for example, Faults or Temperature alarms). Avoid names longer than 24 characters; the alarm line truncates them.
3. Select the new class and, in the inspector pane, set the properties:
   • Name — operator-visible name (used in the class column of the alarm view).
   • Display name — text shown in the alarm view's class column when localized.
   • Default acknowledgment — With single acknowledgment, With always acknowledgment, or Without acknowledgment. The choice is the only way to express "this class does not require operator clear" in the runtime.
   • Background color / text color / icon — pick colors so the operator can identify the class at a glance (red for Faults, amber for Warnings, cyan for Info).
   • State machine — leave at default unless the project is integrated with a non-Siemens MES connector (then set to With state machine).
4. Drag-and-drop the class in the project tree so the most important class is at the top of the list. The runtime uses the list order, not the order of creation, to sort.
5. If a class is no longer required, do not delete it if any alarm still references it. Right-click the class, choose Find > Cross-references, re-assign each referencing alarm to a valid class, then delete.

Example: Three-Class Priority Stack for a Heating Process

With this order, "Boiler low pressure" stays at the top of the alarm view until acknowledged, even if 50 warnings arrive in the meantime.

Assigning Alarms to the Correct Class

With the class list ordered correctly, every alarm's "Alarm class" property must be set to the class that matches its severity. The procedure:

1. Open HMI alarms > Discrete alarms (for bit-triggered alarms) or Analog alarms (for limit-triggered alarms).
2. Select an alarm.
3. In the inspector, set Alarm class to the correct class (e.g., Faults for the temperature alarm, Warnings for the informational one).
4. Verify the Priority field on the alarm — it should be inherited from the class default. If you need to override for a single alarm, raise the priority value (a higher number moves the alarm up in the buffer, but only relative to other alarms in the same class).
5. Use Edit > Find and replace with the filter "Alarm class = Faults" to bulk-modify the priority of every fault alarm if you change the class default after the alarms have been created.

A single PLC tag can drive more than one alarm of different classes. For example, the same temperature word can fire both a Warnings analog alarm at 80 °C and a Faults alarm at 95 °C. The runtime raises both events; the Faults one is shown above the Warnings one because its class is higher in the list.

S7-300 Side: Trigger Sources for HMI Alarms

On the S7-300 side, three trigger sources are commonly used with WinCC alarms. None of them require a special S7 function block; the HMI detects the trigger and raises the alarm.

Example DB layout for a small heating process:

DATA_BLOCK "HMI_AlarmsDB"
  STRUCT
    bLowPressure     : BOOL;   // Faults class
    bHighTemp        : BOOL;   // Faults class
    bFilterDue       : BOOL;   // Warnings class
    bServiceHoursOK  : BOOL;   // Information class
    rTemperature     : REAL;   // analog input for limit alarms
  END_STRUCT
END_DATA_BLOCK

Bind bLowPressure to a discrete alarm of class Faults, bFilterDue to a discrete alarm of class Warnings, and bind rTemperature to two analog alarms (one at 80 °C of class Warnings, one at 95 °C of class Faults).

Configuring the Alarm View Sort Order

The alarm view does not have a separate "sort by class" setting — it inherits the class order from the project. Two view properties are commonly mis-set and break the desired sort:

• Sort column — must be the "Alarm class" column, not "Time". If the operator can change the sort column at runtime, the chronological view will return as soon as the column is clicked.
• Sort order — ascending order shows the highest-priority class on top of the buffer (because the class names are ordered by their project order, not by display name).

To make the priority sort the only one the operator can use:

1. Open the HMI screen that contains the alarm view.
2. Select the alarm view and, in the inspector under Properties > Columns and bars, confirm that the Alarm class column is the first column, and that the Allow operator change check is cleared for that column.
3. Under Properties > Sort, set the sort to Alarm class, ascending, and clear Allow operator change.
4. Set Properties > Selection > Filter to All if every class should be visible. If a separate view per class is required, use a filter expression that references the class name (e.g., 'Alarm class' = "Faults").

Configuration Script for the Alarm View

The following VBScript can be placed in the screen's "Open" event to enforce the priority sort, override any operator change, and pin the class column to position 0:

Sub Screen_OnOpen()
    Dim objView
    Set objView = Screen.Items("AlarmView1")
    objView.SortColumn = 1         ' 1 = Alarm class column (index 0)
    objView.SortDirection = 0      ' 0 = Ascending (highest-priority class first)
    objView.AllowSortChange = False
    objView.AllowColumnChange = False
    objView.Columns(0).Visible = True
    objView.Columns(0).Width = 120
    objView.Columns(0).AllowResize = False
End Sub

Special Case: Custom Class Without Acknowledgment

A frequent request is a class that shows before the Faults and Warnings classes but does not require acknowledgment — for example, a "Multiple active alarms" summary banner. WinCC supports this; the procedure is:

1. Create the new class (e.g., Info banner) with Default acknowledgment = Without acknowledgment.
2. Move it to the top of the alarm class list in the project tree.
3. Assign the summary alarm to that class.
4. Verify in runtime that the banner appears on the first line of the alarm view without forcing an acknowledgment.

The "without acknowledgment" property prevents the operator from having to clear the banner before the underlying faults and warnings become the focus. Do not give the banner class an acknowledgment model that is stricter than the classes beneath it; the runtime will let the operator clear it, but the underlying fault will still be the first non-cleared entry in the buffer.

Logging and Long-Term History

For applications that require alarm history beyond the panel's volatile buffer, configure a log on the HMI side:

1. Open HMI logs > Alarm logs.
2. Add a new alarm log; give it a name and choose the storage path (SD card on the TP2200, or a network share if a UPS-backed path is available).
3. In the log's properties, enable the Logging mode for every alarm class that must be persisted (typically Faults and Warnings; Information is usually kept volatile to limit file growth).
4. Set a retention policy: Number of segments × Size per segment should not exceed the storage capacity. On an SD card of 4 GB this is rarely a constraint, but on a 512 MB card, limit to 2 segments of 50 MB.

The runtime records an entry to the log on every state transition (raised, cleared, acknowledged). The class is preserved in the log, so the priority sort can be re-applied when the log is replayed in the alarm view by setting the alarm view to "Source = Log" and the sort column to "Alarm class".

Verification and Runtime Test

After downloading the project to the TP2200, verify the sort order with a controlled trigger sequence:

1. Start Runtime on the panel (or in the TIA PLCSim / PLCSim Advanced HMI simulation).
2. Force a low-severity alarm (e.g., the Warnings bit bFilterDue) and wait 30 s.
3. Force a high-severity alarm (e.g., the Faults bit bLowPressure).
4. Open the alarm view. The Faults entry must be on the top line; the Warnings entry must be below it, even though the warnings bit was raised first.
5. Clear the high-severity alarm (acknowledge or reset the bit). The Warnings entry should move to the top because it is now the highest-priority class still active.
6. Trigger an analog limit on the Warnings class (e.g., raise rTemperature to 85 °C). The warning should appear below the fault, even if the fault occurred 10 minutes earlier.
7. If the order is wrong, the most common cause is the alarm view's "Sort column" property being set to "Time" instead of "Alarm class", or the class list in the project tree not being in the desired order.

Acceptance Criteria

Troubleshooting Matrix

Frequently Asked Questions