Alarm server and alarm clients

Alarm servers are entities capable of producing an alarm. Alarm clients are entities capable of receiving an alarm.

There are two types of alarm client: temporary alarm receivers and pre-configured alarm receivers. The following concept for temporary alarm recipients is only valid for Desigo PX.

Temporary alarm receivers

Temporary alarm receivers are not defined at the engineering stage. They can be connected to or removed from the network at any time during operation. If a temporary alarm receiver is connected to the network, it will perform the following activities for every alarm server:

  • The alarm recipient enters its address in the BACnet property recipient list [RecpList] of the BACnet device object of the automation station, using the BACnet service AddListElement.
  • Read information about all currently existing alarms, and all currently outstanding acknowledgements, from the automation station (BACnet service GetEventInformation). This ensures that the alarm receiver – irrespective of when it was connected – displays the current alarm status of the system.

After making these entries, the temporary alarm receiver, while connected, will receive all alarm messages from the automation station in accordance with the routing mechanisms described below.

If an automation station cannot transfer an alarm message to a temporary alarm receiver (e.g., because it is no longer connected to the network), the address of the receiver concerned will be removed from the [RecpList]. All alarm messages destined for that receiver will then be deleted.

Preconfigured alarm receivers

The preconfigured alarm receivers are entered in the notification class object:

  • In the [DestList] for Desigo PX
  • In the [RecpList] for Desigo room automation

Time response in the network

The routing of all alarm and acknowledgement ,messages between the alarm server and the alarm clients takes place over the BACnet network using special BACnet services. These are:

  • Confirmed Event Notification for all changes in the alarm state of an alarm-generating object (TO_OFFNORMAL, TO_NORMAL, TO_FAULT), and for messages via local acknowledgements. Direction: Direction: From alarm server to alarm client.
  • AcknowledgeAlarm for the routing of acknowledgements (including reset) performed by the user on an alarm client. Direction: From alarm client to alarm server.

The two services are referred to as Confirmed Services, that is, the receiving device always confirms the receipt of a service by immediately returning a SimpleAck message. This tells the transmitting device that its message has been received by the receiving device. If no SimpleAck message is received, the transmitting devices tries to send the message again (up to three times).

An alarm is always issued by one (and only one) alarm server. Generally, however, there will be several alarm clients on the network. To maintain consistency, all alarm clients must always display the same alarm state. For this reason, all alarm-related functions must always be routed to all the alarm clients. The procedure is the same for both temporary and pre-configured alarm receivers.

The following time-diagrams describe the communications via the network for the various alarm-related events.

Change of alarm state

This procedure is carried out for every change in alarm state on an alarm server: TO_OFFNORMAL, TO_FAULT und TO_NORMAL. The data record Confirmed Event Notification contains the following information:

  • BACnet address of the alarm server
  • Object ID of the alarm-generating object
  • Time stamp
  • Alarm priority
  • Initial and final state of the transmitted state transition (this is used to determine whether the state transition is TO_OFFNORMAL, TO_FAULT or TO_NORMAL)
  • Acknowledgement required [AckReq]: Does the notified state transition require acknowledgement or not?
  • Alarm text
  • Other technical details

Based on this information, the alarm client can present the alarm in a comprehensible way; it may also read additional information automatically from the alarm server, and if required, return any acknowledgement to the correct address.

If a temporary alarm receiver does not confirm receipt with a SimpleAck message (via the Confirmed Event Notification input), the alarm server will try three times more to transmit the alarm to the relevant alarm receiver. The message for this alarm client will then be lost and its reference will be deleted from the [RecpList] of the BACnet device object.

Alarm acknowledgement over the network

This process is performed for all acknowledgements made on an alarm client.

Acknowledge and reset

The alarm can be acknowledged by any alarm client. The AcknowledgeAlarm data record contains information as to which alarm is being acknowledged and other details related to this alarm and the acknowledging alarm client. The alarm acknowledgement is confirmed with a SimpleAck message by the alarm server which generated the alarm. All other alarm clients in the network will be sent a Confirmed Event Notification to notify them of the alarm acknowledgement. They, in turn, will send a SimpleAck message to acknowledge the receipt of this notification, the objective being to ensure that all clients have up-to-date and consistent information.

Local alarm acknowledgement

Alarms can also be acknowledged and reset locally on the alarm server. The alarm is acknowledged internally in the alarm server that generated the alarm. Confirmed Event Notifications are now transmitted to all alarm clients, to notify them that the alarm has been acknowledged. The alarm clients, in turn, send a SimpleAck message to acknowledge their receipt of the Confirmed Event Notification.

Disabling the routing of alarms

Each alarm-generating object has an [EnEvt] parameter (data type: Boolean). Alarm messages (and system events) are only transmitted over the network if [EnEvt=TRUE]. This does not affect the alarm monitoring of the object, that is, the alarm state machine is always kept up to date.