
L-DALI User Manual
126
LOYTEC
Version 5.2
LOYTEC electronics GmbH
alarms can also become inactive, but an acknowledgement is still required. Then they
become
ack-pending
. When an alarm is inactive and was acknowledged it finally disappears
from the alarm summary.
An alarm state can be of different alarm types. The alarm type specifies the class of the
alarm. The following alarm types exist:
Off-Normal Alarm
: This alarm type is a generic alarm class that applies to binary and
multi-state alarm conditions. It indicates that the alarmed data point is on an off-normal
operating condition that triggered the alarm. An alarm value is supplied. In technology
alarm servers, restrictions may apply.
High/Low Limit Alarm
: This alarm type is typical for analog alarm conditions. It
applies when the alarmed value is over or under the defined alarm limits. An alarm
value is supplied. In technology alarm servers, restrictions may apply.
Fault Alarm
: This alarm type is indicating that the monitored data point is in a fault
state. This is different from off-normal or high/low limit alarms. The value of the data
point is within the specifications of the alarm condition but the data point itself is
considered faulty. This can stem from an unreliable value or an offline value, i.e., if the
data point is offline. No alarm value is supplied.
Alarms may be generated from a given data point value (alarm value or value range) or by
comparing a data point command value with a feedback value (feedback alarm). When
defining a feedback alarm, the alarmed data point represents the command value and has a
‘feedbackValue’ property relation (see Section 6.1.12). This property relation can be linked
to another data point, which effectively provides the feedback value.
Alarmed data points also possess other property relations. The ‘enableAlarm’ property
relation can be used to disable or enable alarm conditions when linked to a data point. The
property relations ‘highLimit’, ‘lowLimit’, ‘deadband’ can be used to modify analog alarm
conditions. The property relations ‘inAlarm’ and ‘ackPend’ are TRUE if a data point is in
an alarm state or needs acknowledgement, respectively.
When a data point is alarmed by a generic alarm server, which reports to a technology that
requires a dedicated technology data point (e.g., an alarm for a user register is reported to
BACnet), the required data point is automatically created and linked via the ‘nativeAlarm’
property relation.
Alarm server objects possess property relations that provide a counter value of active
unacknowledged, active acknowledged, and inactive unacknowledged alarms. These
property relations may be linked to other data points that can be used to process this
information.
Other devices can access the alarm information through a technology alarm server or the
Web service. These devices are
alarm clients
. They register with the alarm server and get
notified about changes to the alarm summary. Alarm clients can be used to display the
current alarm summary and to acknowledge alarm transitions. Depending on the underlying
technology, some restrictions may apply to the available alarm information and
acknowledgement behavior. Refer to the technology sections for more information.
6.4.2
Historical Alarm Log
The alarm summary of the alarm objects contains a live list of currently active and
acknowledge-pending alarms. As soon as an alarm becomes inactive and has been
acknowledged, it disappears from the alarm summary. To store a historical log of alarm
transitions an
alarm log
is utilized. An alarm log can log transitions of one or more alarm
objects.
The alarm log is always local and stored as a file on the device. The size of an alarm log is
configurable. The alarm log operates as a ring buffer. As soon as its size limit is reached,