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 18.

Figure 18 – LimitAlarmType

The LimitAlarmType is formally defined in Table 92.

Table 92 – LimitAlarmType definition

Attribute	Value
BrowseName	LimitAlarmType
IsAbstract	False
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the AlarmConditionType defined in clause 5.8.2.
HasSubtype	ObjectType	ExclusiveLimitAlarmType	Defined in Clause 5.8.19.3
HasSubtype	ObjectType	NonExclusiveLimitAlarmType	Defined in Clause 5.8.20
HasProperty	Variable	HighHighLimit	Double	PropertyType	Optional
HasProperty	Variable	HighLimit	Double	PropertyType	Optional
HasProperty	Variable	LowLimit	Double	PropertyType	Optional
HasProperty	Variable	LowLowLimit	Double	PropertyType	Optional
HasProperty	Variable	BaseHighHighLimit	Double	PropertyType	Optional
HasProperty	Variable	BaseHighLimit	Double	PropertyType	Optional
HasProperty	Variable	BaseLowLimit	Double	PropertyType	Optional
HasProperty	Variable	BaseLowLowLimit	Double	PropertyType	Optional
HasProperty	Variable	SeverityHighHigh	UInt16	PropertyType	Optional
HasProperty	Variable	SeverityHigh	UInt16	PropertyType	Optional
HasProperty	Variable	SeverityLow	UInt16	PropertyType	Optional
HasProperty	Variable	SeverityLowLow	UInt16	PropertyType	Optional
HasProperty	Variable	HighHighDeadband	Double	PropertyType	Optional
HasProperty	Variable	HighDeadband	Double	PropertyType	Optional
HasProperty	Variable	LowDeadband	Double	PropertyType	Optional
HasProperty	Variable	LowLowDeadband	Double	PropertyType	Optional
ConformanceUnits
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. The limits shall follow the following inequality HighHigh > High > Low > LowLow. If Deadband properties are provided then:

• HighHighLimit - HighHighDeadband > HighLimit
• HighLimit – HighDeadband > LowLimit
• LowLimit + LowDeadband < HighLimit
• LowLowLimit + LowLowDeadband < LowLimit

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.