Depending on the type and degree of urgency of the alarm, the system user may be required to acknowledge a change in the alarm state with an explicit operator action.
There are two types of acknowledgement:
- Acknowledgement: Confirmation of an incoming alarm
- Reset: Confirmation that an alarm is no longer present
This type of interaction can be carried out locally or with clients, via the network.
There are three standard categories of alarm, or alarm functions, reflecting the type of acknowledgement required:
- Simple alarm
- Basic alarm
- Extended alarm
Each alarm source is assigned (via a Notification Class, see further below) to one alarm function only. No further distinction is made at this stage between OFFNORMAL and FAULT alarms.
Neither incoming alarms (disturbance appears) nor disappearing alarms (disturbance disappears) require acknowledgement.
Acknowledgment is required for incoming alarms only, but not for alarms that have been cleared (that is, acknowledgement required but not reset).
Locking alarm with acknowledgement of incoming alarms (disturbance appears) and cleared alarms (disturbance disappears). Alarms in this category require both acknowledgement and reset.
While testing the system, it may not be possible to reset an alarm. The reason is that an Extended Alarm is not reset until it has been acknowledged, and the time delay has expired.
The alarm remains locked until the fault has disappeared and has been acknowledged and a reset has been carried out, e.g.:
The burner system is restarted when the service engineer has acknowledged the alarm, cleared the fault and reset the alarm. The alarm state of every alarm-generating object is managed within the object itself. The state machines above illustrate this for each of the alarm functions.
The alarm function simple message is the same function as the simple alarm. State transitions, however, are not indicated as events, but alarms.
For HVAC applications and response in the system, the functionality is identical to simple alarm: Simple alarm without acknowledgement of incoming and outgoing faults. The only difference is EventNotification as alarm or event.
Any alarm function under BACnet can be used. The following behavior can be defined for customized alarms:
- EventNotification can occur as either event or alarm
- Acknowledgement: For each change of state (TO-OFFNORMAL, TO-NORMAL, and TO-FAULT) can be defined whether or not an acknowledgement is required.
[AckTra] Acknowledged transitions
This feature is used to represent the acknowledgement status, or to handle information about which state transitions currently still require acknowledgement. The value of [AckTra] is based on the alarm function, the current [EvtSta] and the monitoring of acknowledgements already received.
[AckTra] consists of three flags, one each for TO-OFFNORMAL, TO-NORMAL and TO-FAULT. The flags have the following meanings:
- The flag is always FALSE when there has been a relevant state transition and an acknowledgement is required, because this is a requirement of the alarm function and no acknowledgement has yet taken place.
- The flag is TRUE when no acknowledgement of the state transition is required. This may be the case because the alarm function does not require acknowledgement, or because no state transition has occurred, or because a state transition that has occurred has already been acknowledged.
[TiAck] Time of acknowledgement
Time of the last acknowledgement (time stamp).