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 an 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. Currently the BACnet driver supports only Intrinsic Alarming, as there are no objects with EventEnrollment supported at the moment.
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 ReceptionTo 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 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 ObjectIn 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.
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 ClassIn 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 2 server must be added to the list. 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 Online Help for the BACnet Application (<wincc_oa_path>\BACnet_<version>\help). Mapping of BACnet Alarms to WinCC OAFor 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.
Figure: BACnet peripheral address with Event_State property
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 informationThe information in an received Event Notification can be as follow:
The confirmation to a ConfirmedEventNotification is done automatically in the driver. There is no explicit confirmation possibility by the user. Contents of alarm additional valuesWith 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:
Alarm acknowledgmentAlarm 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 InformationFor 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.
Notification Class (NOC) and WinCC OA Alert Class RelationIn 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 driverActually, 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. Note 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/.
Figure: BACnet Alarm priority mapping 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.
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". Note 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). 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 queryAn 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:
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. GetEnrolmentSummaryThis 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. GetAlarmSummaryThis 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. |
V 3.11 SP1
Copyright ETM professional control GmbH 2013 All Rights Reserved