Intrinsic and Algorithmic Reporting
The data exchange in the alarm and event processing uses special object types. Their especialness is the response to an event, which represents the incoming of a predefined state with specified criteria. An event is able to trigger specified actions or can be only registered, e.g. in a operating or alarm protocol. An event can also represent a state, which triggers an alarm and that requires a user's acknowledgment.
BACnet defines two different mechanisms for the creation of alarms and events.
The first one is Intrinsic Alarming. It depends on object internal properties, which forms the basis of the monitoring of an event or an alarm.
The second mechanism is Algorithmic Alarming. The rule-based alerting is functionally more comprehensive, because it is based on an additionally event enrollment object.
The WinCC OA BACnet driver can absorb the alarm alerts (UnconfirmedEventNotification, ConfirmedEventNotification) from the BACnet device.
This chapter describes consistent handling of the BACnet alarm in WinCC OA including acknowledgement is meant. Of course, the user has also the possibility to read the Event_State on a normal way and configure an alert handling config on the receiving DPE. In that case, the alert handling takes place independent of the BACnet device and solely in WinCC OA.
- Prerequisites for BACnet Alarm Reception
- Intrinsic Alarming Object
- Notification Class
- Mapping of BACnet Alarms to WinCC OA
- BACnet alarm information
- Contents of alarm additional values
- Alarm acknowledgment
- Acknowledgement Information
- Notification Class (NOC) and WinCC OA Alert Class Relation
- Alarm priority mapping for the BACnet driver
- Alarm general query
Prerequisites for BACnet Alarm Reception
To receive BACnet alarms/events there are proper settings in the involved BACnet objects required. For intrinsic alarms there are two objects to consider. The first one is the object supporting intrinsic alarming (e.g. an Analog Input - BACnet_AI). The second is the Notification Class object (NOC). In the following the alarm related settings are described.
Intrinsic Alarming Object
In this object the corresponding events must be enabled by setting the Event_Enable property. Each event (TO_OFFNORMAL, TO_FAULT and TO_NORMAL) can be enabled separately. For proper operation with WinCC OA it is not allowed to enable e.g. only TO_OFFNORMAL and not TO_NORMAL. Because in that case WinCC OA will receive a coming alarm and it will never receive the going alarm. The allowed settings are listed in the following table.
| TO_OFFNORMAL | TO_FAULT | TO_NORMAL | Description |
|---|---|---|---|
| 0 | 0 | 0 | No events are received. |
| 1 | 0 | 1 | Only OFFNORMAL events are received. |
| 0 | 1 | 1 | Only FAULT events are received. |
| 1 | 1 | 1 | OFFNORMAL and FAULT events are received. |
Furthermore, a proper Notification Class object must be set using the Notification_Class property. This property must point to a valid Notification Class object.
Notification Class
The Notification Class determines the BACnet priority of the events and whether an alert must be acknowledged or not. In the Recipient_List Property the user can select whether Unconfirmed or Confirmed services should be used or define the time intervals when the recipients are reachable.
For further information see chapter BACnet_NOC in the BACnet addon description.
Recipient list
In the related Notification Class object the driver must be added to the recipient list, as the BACnet device sends the event notifications only to the recipients in this list. For a redundant WinCC OA project both BACnet drivers on the two servers must be added to the list.
You can use the data point element _BacnetDevice.NotificationClasses to add the driver to the recipient list of a Notification Class. The driver registers with all instances of Notification Classes defined on this element. Use bit 16 of _BacnetDevice.ConfigFlags to specify if the driver shall register with BACnet address (0) or device identifier (1). The driver is registered during every connection establishment or if there is a change to _BacnetDevice.NotificationClasses.
To deregister the driver, set bit 15 of _BacnetDevice.ConfigFlags and write a new value to _BacnetDevice.NotificationClasses afterwards.
Mapping of BACnet Alarms to WinCC OA
For handling BACnet alarms in WinCC OA two proper configured configs are needed - _address (peripheral address) and _alert_hdl (alert handling).
With the _address config it is selected on which DPE the alarm is reported. For the mapping a normal peripheral address with Event_State property is used. The receive mode of this address must be set to Alarm.
For intrinsic alarms the reception mode Alarm is only allowed for the Event_State property.
The second config needed is the _alert_hdl config. It must be configured on the same DPE (Event_State property) as the _address config. This _alert_hdl config must be of the type multiinstance (for information on multiinstance alarms see Alert handling for multiinstance alarms).
BACnet alarm information
The information in an received Event Notification can be as follow:
| Information field | Description |
|---|---|
| Process Identifier | This is the value configured in the Notification Class Recipient_List property. Currently this value is not checked in WinCC OA when an event notification is received. But it is important that the same value is used to acknowledge the alarm. Thus, it is necessary that the process identifier defined in the Recipient_List is the same as this used by the driver for acknowledgment (processIdentifier config entry). |
| Initiating Device Identifier | Part of the peripheral address. Defines to which DPE the alarm is directed. |
| Event Object Identifier | Part of the peripheral address. Defines to which DPE the alarm is directed. |
| Notification Class | Not mapped to WinCC OA. |
| Time Stamp |
With this time stamp an alert will be triggered in WinCC OA, if it is a time and not a sequence number. The time stamp is necessary for subsequent acknowledgment. |
| Priority | In WinCC OA the priority is defined in the alert class. Thus, there is a mapping between BACnet priority and WinCC OA alert classes (see section "Alarm priority mapping" below). Using this mapping depending on the BACnet priority a proper WinCC OA alert class is selected. The original BACnet priority is mapped to _alert_hdl.._add_value_3. |
| Event Type |
The event type depends on the object type. It is mapped to alert _alert_hdl.._add_value_6 attribute. This parameter describes which type of event has been received and it can be e.g. change-of-bitstring (0), change-of-state (1), change-of-value (2). Depending on the event type different further event data are mapped to additional values (see section "Content of alarm additional values" below). |
| Message Text | Is mapped to _alert_hdl.._add_value_2. |
| Notify Type |
Can be either ALARM, EVENT or ACK_NOTIFICATION. The information is used internally to activate, deactivate or acknowledge the alarm. In WinCC OA there is no difference between the Notify Type ALARM and EVENT. Both are handled the same way. An alarm is triggered for both types. ACK_NOTIFICATION acknowledges the WinCC OA alert. |
| AckRequired |
This parameter determines if the Event requires acknowledgement. This parameter is only used internally. |
| From State | This parameter is only used internally. |
| To State |
Set to _original.._value DPE with Event_State property address. This field contains the actual value of the Event_State property. It is also written to _alert_hdl.._add_value_1. E.g. for a binary input the new event state might be OFFNORMAL. |
| Event Values |
The event values depend on the object, sending the alarm and on the BACnet event type. These values are mapped to _add_values attribute as described in section "Content of alarm additional values" below). |
The confirmation to a ConfirmedEventNotification is done automatically in the driver. There is no explicit confirmation possibility by the user.
Contents of alarm additional values
With the aid of the alert handling for multiinstance alarms it is possible to store the different event parameters on additional values and return them (for information on additional values see Additional Values and on the config attributes for additional values see _alert_hdl). The following table contains the actual mapping:
| Attribute (of the config _alert_hdl) | BACnet event values |
|---|---|
| _add_value_1 | Actual value of Event_State |
| _add_value_2 | BACnet event message |
| _add_value_3 | BACnet priority |
| _add_value_4 | Reserved |
| _add_value_5 | Reserved |
| _add_value_6 | BACnet event type (the value of this field determines how the fields below must be interpreted) |
| _add_value_7 |
OUT_OF_RANGE (5): status flags COMMAND_FAILURE (3): status flags CHANGE_OF_STATE (1): status flags UNSIGNED_RANGE (11): status flags CHANGE_OF_LIFE_SAFETY (8): status flags FLOATING_LIMIT(4): status flags DOUBLE_OUT_OF_RANGE(14): status flags SIGNED_OUT_OF_RANGE(15): status flags UNSIGNED_OUT_OF_RANGE(16): status flags CHANGE_OF_CHARACTERSTRING(17): status flags CHANGE_OF_STATUS_FLAGS(18): status flags CHANGE_OF_RELIABILITY(19): status flags CHANGE_OF_BITSTRING(0): status flags |
| _add_value_8 |
OUT_OF_RANGE: exceeding value COMMAND_FAILURE: command value CHANGE_OF_STATE: type of state change UNSIGNED_RANGE: exceeding value CHANGE_OF_LIFE_SAFETY: new life safety mode FLOATING_LIMIT: reference value DOUBLE_OUT_OF_RANGE: exceeding value SIGNED_OUT_OF_RANGE: exceeding value UNSIGNED_OUT_OF_RANGE: exceeding value CHANGE_OF_CHARACTERSTRING: changed value CHANGE_OF_STATUS_FLAGS: empty CHANGE_OF_RELIABILITY: reliability CHANGE_OF_BITSTRING: value |
| _add_value_9 |
OUT_OF_RANGE: dead band COMMAND_FAILURE: feedback value CHANGE_OF_STATE: new state value UNSIGNED_RANGE: empty CHANGE_OF_LIFE_SAFETY: new life safety state FLOATING_LIMIT: reference value DOUBLE_OUT_OF_RANGE: dead band SIGNED_OUT_OF_RANGE: dead band UNSIGNED_OUT_OF_RANGE: dead band CHANGE_OF_CHARACTERSTRING: alert value CHANGE_OF_STATUS_FLAGS: empty CHANGE_OF_RELIABILITY: empty CHANGE_OF_BITSTRING: empty |
| _add_value_10 |
OUT_OF_RANGE: exceeding limit COMMAND_FAILURE: empty CHANGE_OF_STATE: empty UNSIGNED_RANGE: exceeding limit CHANGE_OF_LIFE_SAFETY: expected life safety operation FLOATING_LIMIT: error margin DOUBLE_OUT_OF_RANGE: exceeding limit SIGNED_OUT_OF_RANGE: exceeding limit UNSIGNED_OUT_OF_RANGE: exceeding limit CHANGE_OF_CHARACTERSTRING: empty CHANGE_OF_STATUS_FLAGS: empty CHANGE_OF_RELIABILITY: empty CHANGE_OF_BITSTRING: empty |
Alarm acknowledgment
Alarm acknowledgement in this section means the consistent acknowledgement in the BACnet system. This means:
An alarm is acknowledged in WinCC OA, if the alarm is acknowledged in the device. So the acknowledgment state of the device and that of WinCC OA shall be consistent.
Of course, the user can decouple the acknowledgment in BACnet and WinCC OA by configuration means. In this section the different issues, which must be considered concerning acknowledgment are described.
Normally, an alarm is acknowledged directly in WinCC OA, what means that the UI sends a message to the WinCC OA event manager to acknowledge the alarm. If the acknowledgment should also take place in the device, the message must be sent first to the device. And if the driver receives a confirmation from the device that the alarm was acknowledged, the alarm can be also acknowledged in WinCC OA. For the latter case alert classes have been defined for external acknowledgement. To enable the alert classes, set the following config entry:
[driver]
driverAckClassPrefix = "BACnet"
This entry tells the UI not to directly acknowledge the alert with an alertclass prefix "BACnet" and instead set a special internal DP of the driver, which tells it to send an acknowledgement message to BACnet device.
Acknowledgement Information
For the alert acknowledgement the driver needs information to refer to the alarm to acknowledge. This information is stored in the AlertID, the driver uses to identify alarms. The AlertID is internally used by the driver and the user should not get into contact with it.
In the service for acknowledgment of alarms there is some information, which is listed in the table below. The bold items must match for an unique identification of the event notification. If this parameter does not match exactly the device reports an "Inconsistent Parameter" error is issued and an acknowledgment does not take place.
| Acknowledging Process Identifier | The process identifier in the acknowledge telegram must match the process identifier in the notification. This means, that the process identifier in the recipient list in the NOC must match the process identifier of the driver. |
| Event Object Identifier | Taken from corresponding peripheral address. |
| Event State Acknowledged | Value of event state. |
| Time Stamp | Must be the source time stamp of the alert. The source time stamp can also be a sequence number. |
| Acknowledgment Source | User who does the acknowledgement (default value of BACnet API used). |
| Time Of Acknowledgment | Time of alert acknowledgement (default value of BACnet API used). |
Notification Class (NOC) and WinCC OA Alert Class Relation
In BACnet the NOC defines the alarm state model. In WinCC OA the model is determined by the alert class (see _alert_class (Alert class)). These models are not independent. So they must be adjusted in accordance for correct alert processing. In the BACnet NOC there are the priority and the Ack_Required properties. The Ack_Required property defines, which transition (TO_OFFNORMAL, TO_FAULT, TO_NORMAL) must be acknowledged and which not. BACnet NOC and WinCC OA alert class are depending from each other.
Alarm priority mapping for the BACnet driver
Actually, the WinCC OA alert class is derived from the BACnet priority. A mapping can be defined in the panel Alarm priority mapping (System management -> BACnet -> BACnet Alarm priority mapping). With a proper mapping the WinCC OA alarm priority will reflect the BACnet priority.
In order that the "BACnet" tab is visible in the system management, the BACnet subproject must be integrated into the WinCC OA project before. For further information, see chapter "Embedding and Configuring the Object Library" in the BACnet.chm under <wincc_oa_path>/BACnet_<version>/help/.
This mapping takes place for a driver data point and is stored at the internal data point element _Bacnet_<driver number>.Config.AlarmPrioMapping. If a mapping was defined for a BACnet device (DPE _BacnetDevice.AlarmPrioMapping) in the configuration panel of the BACnet driver, it is used preferentially. Otherwise the mapping defined in the driver is used. Both DPEs are of the type dyn_string and the format of the stored mapping is:
Priority1 AlertClass1
Priority2 AlertClass2
Priority3 AlertClass3
...This means that WinCC OA AlertClass1 is used for BACnet priorities Priority1 to Priority2 - 1 and so on. The last range extends to the highest BACnet property value 255.
Not every WinCC OA acknowledge type can be used for the settings of the NOC Ack_Required property or it does not make sense, if the expected behavior should be reached. The following matrix in the table gives an overview about the combinations of the settings for the NOC Ack_Required property and WinCC OA acknowledge types. In this matrix only the TO_OFFNORMAL is shown. The same applies to the TO_FAULT transition.
| Not acknowledgeable | Acknowledge deletes | CAME is acknowledgeable | CAME or WENT must be acknowledged | CAME and WENT must be acknowledged separately | |
|
AckRequired: TO_OFFNORMAL =0 TO_NORMAL =0 |
OK | Not allowed | OK | OK | OK |
|
AckRequired: TO_OFFNORMAL =1 TO_NORMAL =0 |
Not allowed | Not allowed | Not allowed | Partly allowed | OK |
|
AckRequired: TO_OFFNORMAL =0 TO_NORMAL =1 |
Not allowed | Not allowed | Not allowed | Partly allowed | OK |
|
AckRequired: TO_OFFNORMAL =1 TO_NORMAL =1 |
Not allowed | Not allowed | Not allowed | Not allowed | OK |
The acknowledgement of BACnet alarms takes place in the WinCC OA Alert and event panel. Thus, the alarm must be visible and acknowledgeable in order to be acknowledged in the device. For example, it is not allowed to use a Not acknowledgeable WinCC OA alert type, if the BACnet alarm expects any acknowledgment. In this case, an unacknowledged transitions remain in the device.
The type Acknowledge deletes must not be used because it does not fit the BACnet alarm model, where alarms never go by acknowledgment.
The mode CAME is acknowledgeable must not be used for alarms which need an acknowledgment in the device, because in the device an alarm still needs to be acknowledged in the case if the alarm already went.
Came or went must be acknowledged must be used with care for the cases where one transition in the device needs an acknowledgement, because if the other transition is acknowledged in WinCC OA the alarm is removed in WinCC OA and an unacknowledged alert remains in the device. This is due to the fact thath BACnet devices can not acknowledge "CAME or WENT" but only "CAME", "WENT" or "CAME and WENT".
In case of the combination of the alert class mode "came or went must be acknowledged" and the BACnet notification class "AckRequired: TO_OFFNORMAL=1, TO_NORMAL=0", it may happen that alarms are not acknowledged in the device if they are acknowledged in the wrong order (WENT before CAME).
This behavior can be avoided by setting the config entryalarmExternAckFirst=1 in the [bacnet] section. Because of this entry, the transition which requires an extern acknowledgement will be acknowledged first. This will ensure acknowledgement in the device. However, it is recommended to set this entry only in the case that this combination is really needed in the project.
In general, it is not allowed to set the setting Acknowledge old alarms in the WinCC OA alert class, because old alarms cannot be acknowledged in the BACnet device.
Alarm general query
An important issue when mapping BACnet alarms to WinCC OA is the synchronization of alarm status at certain points. For example if the driver has lost the connection to the device and after connection reestablishment alarm status should be correctly indicated.
For that purpose the driver uses the GetEventInformation service to retrieve alarm status in these cases. GetEventInformation is used because all relevant information is returned by this service. The retrieval of alarm status is also called Event General Query (Event GQ) in the subsequent description. During Event GQ the driver synchronizes the alarm status between the device and WinCC OA. This means all alarms which exist only in WinCC OA and not in the device are deleted and if there are alarms in the device and not in WinCC OA these alarms are triggered in WinCC OA. If the alarm status is equal nothing happens.
The driver executes automatic Event GQ in the following cases:
-
Connection establishment to the device
-
Redundancy Switch
An GQ can be also triggered manually on a device by using the _Bacnet_Device.Command.GQ DPE. Therefor a correct value must be set for the DPE (see Description of internal data point).
If GetEventInformation is not supported by the device the driver tries to use GetEnrolmentSummary service and if this is also not existing the driver uses GetAlarmSummary. Both alternatives have some drawbacks in comparison to GetEventInformation. These are described in the following.
GetEnrolmentSummary
This service must be executed twice to get a list of active condition. First all unacknowledged alarms are read and afterwards all alarms in ACTIVE state. This must be done because the service can not provide all active and unacknowledged alarms in one call. Afterwards the driver must read Event_Time_Stamps and Acked_Transitions properties in order to complete all necessary information for alarm synchronization.
GetAlarmSummary
This service returns only all active alarms and it works only for Notify_Type Alarm. Therefore all objects must not have the Notify_Type Event, because in such cases an active state is not returned as result of GetAlarmSummary. Futhermore it does not return unacknowledged states, if the current state is NORMAL. For this reasons GetAlarmSummary is a bad alternative for alarm status synchronization and hopefully only of minor practical importance.
Event_Message_Texts Property
The optional property Event_Message_Texts contains the last alarm texts and can be used to retrieve alarm texts during an Event GQ. This property must be supported by the device. The driver reads the property if bit 3 of _BacnetDevice.Flags is set to 1.
