_alert_hdl

Short sign pattern for sum alert.

Allows selecting alerts according to their priority abbreviation. If you specify several characters, all alerts that possess one of these characters will be included ("AW" includes all alerts with the priority "A" and "W").

Can only be used for sum alerts.

Acknowledge all alerts of an alert handling.

Is used to acknowledge all unacknowledged alarms of a data point (see also _ack_state respectively _alert_hdl.<i>._ack_state" alert handling).

This, for example, is used in the _alert_hdl PARA panel when there the alarms are acknowledged to configure the alarm.

Sum alert for "acknowledge deletes"?

The included individual alerts are limited to alerts of certain acknowledgement types. See chapter _alert_class (Alert class)

Can only be used for sum alerts.

Sequence of acknowledgement statuses for sum alerts.

Can only be used for sum alerts.

Is set on CAME and/or WENT side (bit 5 and 21), depending on what must be acknowledged.

As long as _oblig is set an alert is visible and cannot be deleted.

Acknowledgement type of an alert:

The query returns how the alert (CAME/WENT) that was active at that given moment was acknowledged. In order to acknowledge the alert, use alertSet(). Therefore, you have to know the time of the alert. For this attribute only DPATTR_ACKTYPE_SINGLE or DPATTR_ACKTYPE_MULTIPLE are possible.. See also _alert_hdl.<i>._ack_state" alert handling.

Type of acknowledgement

Constants:

/Acknowledgement deletes

ACKNOWLEDGEMENT_DELETES = 0,

// cannot be acknowledged

ACKNOWLEDGEMENT_NONE = 1,

// Came can be acknowledged

ACKNOWLEDGEMENT_CAME = 2,

// Alert pair must be acknowledged

ACKNOWLEDGEMENT_PAIR = 3,

//came and went has to be acknowledged

ACKNOWLEDGEMENT_CAMEANDGONE = 4,

//Acknowledgement type for sum alerts. Corresponds to the type "cannot be acknowledged".

ACKNOWLEDGEMENT_SUMALERT = 5

Priority of the current range

Not relevant for multiinstance alerts.

Current range

Not relevant for multiinstance alerts.

Acknowledgement status of the highest pending alert. With this attribute the current acknowledgement state of the highest pending alert can be queried.

1 = CAME unacknowledged

2 = CAME acknowledged

3 = WENT unacknowledged

4 = CAME/WENT/unacknowledged

0 = No alert

For possible constants see chapter "_alert_hdl.<i>._act_state" alert handling.

Not relevant for multiinstance alerts.

Background color string of the current highest pending alert.

Not relevant for multiinstance alerts.

Foreground color string of the current highest pending alert.

Not relevant for multiinstance alerts.

Font style of the highest pending alert.

Not relevant for multiinstance alerts.

Priority of the current highest pending alert.

Not relevant for multiinstance alerts.

Range of the current alert status of the highest pending alert.

In case of alert with the ranges OK/HI/URGENT. A value triggers an alert and results in URGENT and thereafter in HI. As long as URGENT is not acknowledged and is pending, the _act_state_range is 3 (URGENT is pending and has the highest priority). act_range is 2 (the last value change resulted in the range HI). If the URGENT is acknowledged, the _act_state_range is also 2 (HI is now the highest alert).

Not relevant for multiinstance alerts.

Text of the current highest pending alert.

Not relevant for multiinstance alerts.

Text of the current range

Not relevant for multiinstance alerts.

_alert_hdl.<detail>._alerts

Returns all alert pairs (CAME time and WENT time) that are known for this detail by the Event. This also applies for alerts, which are intended to be deleted. If <detail> is 0, the alerts of all details are returned.

Sum alert for "both must be acknowledged"?

The included individual alerts are limited to alerts of certain acknowledgement types. See chapter _alert_class (Alert class).

Can only be used for sum alerts.

Count in order to disambiguate the WENT time for simultaneous alerts.

The _gone_time_idx is a read-only attribute. Therefore, you can only query the attribute.

Reference to alert class of the range

The alert class will be converted internally to a DPIdentifier.

Note: For multiinstance alerts it is not permitted to escalate an alert class while an alert action (_event) is being triggered.

Note: _class must not be defined directly behind _event:DPATTR_ALERTEVENT_CAME to be used as alert class.

When is the alert deleted or moved?

Configure the attribute through the config _alert_class (alert class) -> "Arguments" tab.

Defines whether an alert pair which can be deleted (if obsolete and invisible) is deleted or stored. Is set on both sides (bit 15 and 31).

In the alert class you can specify whether archived alerts shall be deleted or stored after the archive period elapses. The bit is only relevant when ARCHIVE_ALERT_BIT_ATTR = 1. Due to this bit, the data manager decides whether the alert will be deleted (Bit = 1) or will be stored (Bit =0).

Configure the attribute through the config _alert_class (alert class) -> "Arguments" tab.

Is it an alert handling of discrete values?

_discrete_states is set implicitly when adding an alert range of the _type DPDETAIL_RANGETYPE_MATCH or DPDETAIL_RANGETYPE_SET.

Note:

This attribute is only used during runtime and is not saved in the database. Therefore it is not used for the ASCII export.

DP list for sum alert.

You can either only set a _dp_list or a _dp_pattern. You cannot set both simultaneously.

Escalated alert class of an alert. The alert class will be converted internally to a DpIdentifier.

Note: The detail number (alarm range) must be given when querying, e.g.:

main()

{

time t;

string value;

setTime(t,2011,2,18, 12,17,59,781);

alertGet(t, 3, "dist_2:ExampleDP_AlertHdl1.:_alert_hdl.2._escalation_class", value);

DebugN("value: ", value);

}

--->

WCCOActrl2:["value: "]["dist_2:danger."]

Triggers an alert action. Multiinstance alarms can only be triggered/updated/acknowledged using this attribute. For possible constants see "_alert_hdl.<i>._event" alert handling.

Note: For multiinstance alarms it is not permitted to escalate an alarm class while an alert action (_event) is being triggered.

Note: _class must not be defined directly behind _event:DPATTR_ALERTEVENT_CAME to be used as alert class.

Note: Multiple equal attributes to the same alert instance are ignored (e.g. _event:DPATTR_ALERTEVENT_CAME and _event:DPATTR_ALERTEVENT_SINGLE_ACK can not be defined in one alertSet()).

The _hyst_time attribute (called Delay in the alert_hdl configuration) specifies the minimum time in seconds that an alert must be in a bad range for it to be triggered. When the alert is back in a good range, it is immediately cleared. For an alert instance, the _alert_hdl.<detail>._hyst_time can be used to get the values used for an alert instance. The configuration applies per alert range. See chapter Delayed Alerts for more information.

Lower insensitivity barrier (hysterisis)

The attribute is of the same variable type as the data point element, for example, int _I_hyst_limit.

NOTE: The value must be set in absolute and not in relative (= use in PARA!)

Represents the state of the last alert pair. When an alert pair is created (CAME) _last (bit 18) is set. As soon as the pair is gone, _last (bit 18) is set. If an alert pair is still in a CAME state, and a gone impulse occurs, the CAME side is set to FALSE. However, bit 18 is not changed. The attribute is set either on CAME or GONE side. As soon as the alert pair is obsolete, both sides are set to FALSE.

If a measured value has more than one "bad" range, the measured value may change to a range that is not close-by the range "good". In WinCC OA all the ranges between "good" and the current "bad" range are pending (e.g. together with the alert also a warning is pending). The _last flag is set for the current "bad" range, the other ranges in between are also pending but without an activated flag.

If a measured value changes to a "bad" range several times and leaves the range without being acknowledged in the meantime, a quite number of still not acknowledged messages is pending. The first (=oldest) message is assigned with the _last_of_all flag. This event should also be acknowledged first. In the example of _last, not only the flag "_last" but also the flag "last_of_all" is set for the message.

the "last_of_all" flag is passed on from the current event of the measured value to the next event of this measured value. The flag "_last" is interesting only when you have more than one "bad" range. "_last" can be set in case of a stack of not acknowledged messages of a measured value also for several events .

Pattern that defines when the range should trigger an EVENT. The patterns depend on the data type of the DPE:

Bit32: 01X…

1 .. pattern matched when Bit32 has a 1 at this position.

0 .. pattern matched when Bit32 has a 0 at this position.

X .. pattern matched when Bit32 has a 0 or a 1 at this position.

For example:

11111111111111111111111111111111

10101010101010101010101010101010

XXXXXXXXXXXXXXXX1111111111111111

INT, FLOAT: Ranges, for example, 0-10 or 6.3 - 20.8 (period is used as decimal point in all languages).

TEXT: Wildcards with * and ?

A * can always be used for all data types and always matches.

Can only be used for discrete alerts.

Minimum priority (to suppress alerts)

Alerts below this minimum priority do not apply to the sum alert for that, this attribute was set.

Reverse (negate) value range handling.

Negate means that the attributes _match and _set will be negated.

Group alert for "cannot be acknowledged"?

The included individual alerts are limited to alerts of certain acknowledgement types. See chapter _alert_class (Alert class).

Number of ranges

You can create the ranges using _alert_hdl.<rangeNo>._type

Sequence of alerts for group alerts

Constants:

ORDER_PRIO_STATE = 0,

// Priority prior to alert state

ORDER_SIGN_STATE = 1,

// Abbreviation prior to alert state

ORDER_STATE_PRIO = 2,

// Alert state prior to priority

ORDER_STATE_SIGN = 3

// Alert state prior to abbreviation.

Can only be used for sum alerts.

Alert index for the alert partner

In order to disambiguate alarms that occur simultaneously, there is a counter in the alert time. The attribute _partn_idx is this counter for the attribute _partner of type time.

Alert time for the alert partner

An alert is comprised of 2 events CAME and WENT. The partner of CAME is WENT and the partner of WENT is CAME. _partner of the CAME event therefore returns the WENT time or 1.1.1970 (if the alarm did not go yet). _partner des WENT events returns the CAME time.

Is set on CAME (bit 7) and/or GONE side (bit 23) if a single acknowledgement occurs.

The _single_ack is a read-only attribute. Therefore, you can only query the attribute.

Configure the attribute through the config _alert_class (alert class) -> "Arguments" tab.

The attribute alert_hdl.._state summarizes the status bits (_obsolete, _ackable etc) in a bit32 pattern.

_state of a CAME event returns in the first 16 bits the status bits for the CAME event.

_state includes bits as well for coming alerts as for going alerts. The bits 0 - 15 are reserved for "CAME", the bits 16 - 31 for "WENT".

_state of a WENT event returns in the first 16 bits the status bits for the WENT event. The bit 0 _direction can be used to identify whether the state is a WENT or CAME event state.

Filters the bits, which trigger an alert in case of a state change in a specific range. If the specified state bits of the match change, an alert will be given.

The attribute is only valid for discrete alert handling.

Current system time.

The alert time will be set due to the time of a value change or due to the time of the _event attribute. This can be different than the current time, for example, in case of a periphery that is not always online. _system_time is the time as WinCC OA created an alarm.

For example:

A PLC is connected to a WinCC OA system through a dial-up connection. At 12:00 o'clock a fire breaks out. The PLC tries to establish a connection to the control center. For 20 minutes this does not work due to problems with the telephone line. When the alert is reported at 12:20 o'clock, the alert possesses the alert time 12:00. If the question "why did the control room need 20 minutes before alerting the fire department, arises later,

the control room can verify that it took 20 minutes before the alert arrived.

The attribute _type will be used for creating an alert handling and for adding alert ranges for a DPCONFIG_ALERT_NONBINARY_SIGNAL.

Create an alert handling as follows_

_alert_hdl.._type =

DPCONFIG_ALERT_BINARYSIGNAL = 12

DPCONFIG_ALERT_NONBINARYSIGNAL = 13

DPCONFIG_SUM_ALERT = 59

Create alert classes as follows:

_alert_hdl.<rangeNo>._type =

DPDETAIL_RANGETYPE _MIN=6,

DPDETAIL_RANGETYPE _MAX=7,

DPDETAIL_RANGETYPE MINMAX=4, DPDETAIL_RANGETYPE MATCH=5,

DPDETAIL_RANGETYPE SET=3

Upper insensitivity barrier (hysteresis).

NOTE: The value must be set in absolute and not in relative (= use in PARA!)

The alert panel only displays alerts with the value _visible = true.

An alert is not visible if the alert state changes to "no alert" or there is a new pending alert and the option "acknowledge old alarms" is not defined in the alert class.