Alarms can be modelled with multiple exclusive sub-states and assigned limits or they may be modelled with nonexclusive limits that can be used to group multiple states together.
The LimitAlarmType is used to provide a base Type for AlarmConditionTypes with multiple limits. The LimitAlarmType is illustrated in Figure 17.
Figure 17 – LimitAlarmType
The LimitAlarmType is formally defined in Table 90.
Table 90 – LimitAlarmType definition
Subtype of the AlarmConditionType defined in clause 5.8.2.
|HasSubtype||ObjectType||ExclusiveLimitAlarmType||Defined in Clause 18.104.22.168|
|HasSubtype||ObjectType||NonExclusiveLimitAlarmType||Defined in Clause 5.8.19|
|A & C Exclusive Limit|
|A & C Non-Exclusive Limit|
Four optional limits are defined that configure the states of the derived limit Alarm Types. These Properties shall be set for any Alarm limits that are exposed by the derived limit Alarm types. These Properties are listed as optional but at least one is required. For cases where an underlying system cannot provide the actual value of a limit, the limit Property shall still be provided, but will have its AccessLevel set to not readable. It is assumed that the limits are described using the same Engineering Unit that is assigned to the variable that is the source of the Alarm. For Rate of change limit Alarms, it is assumed this rate is units per second unless otherwise specified.
Four optional base limits are defined that are used for AdaptiveAlarming. They contain the configured Alarm limit. If a Server supports AdaptiveAlarming for Alarm limits, the corresponding base Alarm limit shall be provided for any limits that are exposed by the derived limit Alarm types. The value of this property is the value of the limit to which an AdaptiveAlarm can be reset if any algorithmic changes need to be discarded.
The Alarm limits listed may cause an Alarm to be generated when a value equals the limit or it may generate the Alarm when the limit is exceeded, (i.e. the Value is above the limit for HighLimit and below the limit for LowLimit). The exact behaviour when the value is equal to the limit is Server specific.
The Variable that is the source of the LimitAlarmType Alarm shall be a scalar. This LimitAlarmType can be subtyped if the Variable that is the source is an array. The subtype shall describe the expected behaviour with respect to limits and the array values. Some possible options:
- if any element of the array exceeds the limit an Alarm is generated,
- if all elements exceed the limit an Alarm is generated,
- the limits may also be an array, in which case if any array limit is exceeded by the corresponding source array element, an Alarm is generated. The four optional severity Properties, if defined, provided the severity for each of the limits.
The four optional deadband Properties, if they are defined, are used to delay the return to normal until the value is within the limit by the value of the deadband. For example, if a Value exceeds a HighLimit of 20, and there is a HighDeadband define of 1, the value will remain in alarm until the Value drops below 19. An Alarm deadband can be used to limit Alarms in a system where values may bounce or have some noise (i.e. the value is jumping up and down by 0.2). They keep the Alarm from being reactivated until it has dropped enough to not retrigger by noise.
In the event of a restart of an AlarmManager, the AlarmManager shall recover the LimitAlarm state, this also applies to all subtypes.