Alert handling for multi instance alerts

An alert handling for multi instance alerts allows triggering multiple alerts from the periphery over a special WinCC OA driver or over a manager (see Multi instance alert). The alert properties (e.g. the alert class or the alert text) can be changed dynamically when the alert is triggered.

For this purpose, the data point element must have an alert handling config (_alert_hdl). A multi instance alert can be triggered via a special driver, a manager, a CTRL script or a panel by setting specific values to the corresponding alert handling attributes.

Using alertSet() to the _alert_hdl.._event attribute the alert actions (CAME, ACK, WENT, etc. - see "_alert_hdl.<i>._event" alert handling) of a multi instance alert are set. Multi instance alerts can be acknowledged either directly via the alert screen or indirectly via the periphery by using a special alert class (see driverAckClassPrefix and Examples of alert handling). The _alert_hdl.._multi_instanceattribute (bool) defines whether an alert handling config is used for multi instance alerts.

  • When using a special driver, it should be noted that the peripheral address is assigned to exactly one driver instance, whereby alerts can be received through that driver instance only.

  • In principle, multi instance alerts (thus also the _alert_hdl.._multi_instance attribute) should only be used for alerts which were generated externally and of which several instances may exist.

  • Configurations may not be set with dpSetTimed()/dpSetTimedWait(). An exception is to set the source time to NULL time using dpSetTimed()/dpSetTimedWait() to prevent a growing configuration history.

  • When using multi instance alerts, it is to consider that for the acknowledgement of the driver the alert class of the configuration and not the alert class of the alert are used.

  • External alerts cannot be acknowledged per a dpSet on the _alert_hdl.._ack attribute because the device alert would be still active.

  • In case of multi instance alerts, the displayed alert color (_act_state_color) is not defined by the priority but the acknowledgement state. The alert which changes the acknowledgement state also defines the current color, e.g.:

    • Alert with alert class "information" (Prio 10) is triggered. The alert cannot be acknowledged which means the state is "CAME/acknowledged" -> _act_state_color corresponds to the color of CAME/acknowledged defined for "information"

    • Alert with alert class "warning" (Prio 40) is triggered. The alert can be acknowledged which means the state is "CAME/unacknowledged" -> _act_state_color corresponds to the color of CAME/unacknowledged defined for "warning"

    • Alert with alert class "alert" (Prio 60) is triggered. The alert state does not change and is still "CAME/unacknowledged" -> _act_state_color still corresponds to the color of "warning"

    • Alert with alert class "information" is triggered. The alert state changes to "CAME/acknowledged" -> _act_state_color corresponds to the color of "CAME/acknowledged" defined for "information".

Multi instance alerts can be used for all numeric data types of a data point element (uint, int, float and bool).

Addressing of an alert instance

In many cases the periphery generates an alert message number for an alert instance. In order that the driver/manager is able to identify/reference uniquely an alert instance in the periphery, several attributes are required: the manager number, the device number, the alert source handling the alert and the alert message number assigned to an alert instance. The driver/manager can use these attributes (all or only selected) to change the alert states in the device (e.g. to acknowledge). These additional attributes are stored in the database. It is up to the driver/manager to fill and use these attributes. All these attributes are stored in the _alert_hdl.._alert_id attribute (string). This attribute can be used for filtering alerts (e.g. to find all alerts of a specific alert source) or in a dpQuery, alertGet or alertConnect calls. The unique identification of data point elements with multi instance alerts (as well as other alerts) is still verified by using the alert time (atime) and the count.

The count is assigned cyclically to multi instance alarms and is stored for each alarm range without overloading the configuration history. This minimizes the risk that another alert with the same count and time overwrites the actual alert. Therefore, the count must be re-determined each time an access to the alert is required or if the alert attributes should be changed.

Additional values

Together with the alert instance also additional properties, so-called additional values, can be stored in a multi instance alert. For further information see Additional Values.

Independent alarm acknowledgement

Multi instance alerts can be acknowledged in any order. This means, a younger alert can be acknowledged before an older alert or a WENT alert can be acknowledged before a CAME alert.

Requirements and restrictions

  • The driver / manager must support multi instance alerts.
  • Multi instance alerts are not supported for sum alerts.
  • Smoothing, transformation and low level old/new comparison are not available for data point elements that have a multi instance alert peripheral address.
  • For driver startup/restart a synchronization of existing alerts in the event manager and the actual available alerts in the peripheral device has to be implemented by the specific driver: Alerts that remained in the Event manager without a corresponding alert at the peripheral device have to be to set to WENT and automatically acknowledged; New alerts have to be created and pending alerts have to be updated to the current state. The implementation of synchronization is the responsibility of the specific driver.
  • Multi instance alerts can not be handled from distributed systems with a WinCC OA version < 3.10.

  • For multi instance alerts the possibility to acknowledge all alert instances with one command (dpSet using the attribute _alert_hdl.._ack) is now prohibited if more than 100 alerts instances are pending for a data point element.

    If there are more than 100 alert instances detected while making a bulk acknowledge the following error is reported and the alert instances remain unacknowledged. 
    WCCILevent   (0), <TIMESTAMP>, PARAM,WARNING,    54,  Unexpected state, DP: <DPE identifier>, EvDpManager, setAlertValueAttributes:
 bulk acknowledge for multi instance alarms is not allowed

Standard panel for alert handling of numeric values

The panel for configuring a multi instance alert of numeric values (int, uint, float) consists of two tabs - Limits and Parameters.

Figure 1. Alert handling (int, uint and float) panel - Limits tab

Limits tab

An alert handling for multi instance alerts consists of minimum 2 alert ranges - one good range and one bad range. For multi instance alerts a new alert instance is generated only if the corresponding alert range is set (not by setting a certain value like for the alert handling of continuous/discrete values). Alerts come, are acknowledged and go as specified by the periphery / manager. This means, the value (_original.._value) has no direct relation to the alert (setting the value does not trigger/reset an alert ). The value that was written to the first additional value (_alert_hdl.._add_value_1) of the multi instance alert can be displayed in the alert screen (see attributesFromAddValues config entry).

Since multi instance alerts are not triggered on value change, the alert range for the good range is not free selectable. The good range is always the alert range with the index 1.

  • Alert class: Select one of the available alert classes (see also chapter _alert_class) for the bad range. The good range has no alert class.

  • Came text: Enter a text for each alert range. This text will be displayed when the value is within the defined alert range (CAME alert). The text will be displayed in the alert screen, e.g.: "Measuring sonde 2: CO content critical". The CAME text of the good range is not displayed in the alert screen, but can be used for queries (e.g. for use in an enum context). By default, the CAME text for the bad range is "not Ok came" and for the good range "Ok came". These default texts are defined in the para.msg message cataloge under the keys "multiinstance_ok_came_alarmtext" and "multiinstance_not_ok_came_alarmtext" and can be changed or can be overwritten when the alert is triggered. If additional values were set, the content of the second additional value (_alert_hdl.._add_value_2) can be shown in the alert screen for the bad range (see attributesFromAddValues).

  • Went text: Enter a text for each alert range. This text will be displayed when the value has left the defined alert range (WENT alert). The text will be displayed in the alert screen, e.g.: "Measuring sonde 2: CO content OK". The WENT text of the good range is not displayed in the alert screen, but can be used for queries (e.g. for use in an enum context). By default the WENT text for the bad range is "not Ok went" and for the good range "Ok went". These default texts are defined in the para.msg message cataloge under the keys "multiinstance_ok_went_alarmtext" and "multiinstance_not_ok_went_alarmtext" and can be changed in this file or can be overwritten when the alert is triggered. If additional values were set, the content of the second additional value (_alert_hdl.._add_value_2) can be shown in the alert screen for the bad range (see attributesFromAddValues).

Parameters tab

The layout of the Parameters tab is similar to the Parameters tab of a sum alert handling (except the Ignore alerts with priority smaller thansetting).

Alert handling of boolean values

The alert handling of boolean values characterizes that the occurrence of an alert depends on two possible states (TRUE or FALSE).

Figure 2. Alert handling of a boolean data point element

Ranges tab

  • Good range: The good range (Off (0)) is fixed for multi instance alerts and cannot be changed.
  • Color bar: The red area is the alerts range, the green area is the good range (normal range) when the system runs properly, i.e. when no alert should be triggered.
  • Came text: Enter for the both states (1 (TRUE) or 0 (FALSE)) a text. The text of the alerts state will be shown in the alert panel when the state changes. The Came text in the good range is not shown in the alert screen, but can be used for queries (e.g. use in an enum context). By default, the Came text for the bad range is "not Ok came" and for the good range "Ok came". These default texts are defined in the para.msg message cataloge under the keys "multiinstance_ok_came_alarmtext" and "multiinstance_not_ok_came_alarmtext" and can be changed there or can be overwritten when the alert is triggered. If additional values were set, the content of the second additional value (_alert_hdl.._add_value_2) can be shown in the alert screen for the bad range (see attributesFromAddValues)
  • Alert class: Define for the alert state (not good range) one of the seven predefined alert classes (see chapter _alert_class (Alert class)) or apply a separate alert class using the DP selector on the right. You can also override the alert class - for further information see "Alert class" above.

Parameters tab

The layout of the Parameters tab is similar to the Parameters tab of a sum alert handling (except the Ignore alerts with priority smaller than setting).

For examples, see chapter Examples of alert handling.