Figure 12informally describes the AlarmConditionType, its sub-types and where it is in the hierarchy of Event Types.

image015.png

Figure 12- AlarmConditionType Hierarchy Model

The AlarmConditionTypeis an abstract type that extends the AcknowledgeableConditionTypeby introducing an ActiveState, SuppressedStateand ShelvingState. It also adds the ability to set a delay time, re-alarm time, Alarmgroups and audible Alarmsettings The Alarm model is illustrated in Figure 13. This illustration is not intended to be a complete definition. It is formally defined in Table 35.

image016.png

Figure 13– Alarm Model

Table 35– AlarmConditionType definition

Attribute

Value

BrowseName

AlarmConditionType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of the AcknowledgeableConditionType defined in clause 5.7.2

HasComponent

Variable

ActiveState

LocalizedText

TwoStateVariableType

Mandatory

HasProperty

Variable

InputNode

NodeId

PropertyType

Mandatory

HasComponent

Variable

SuppressedState

LocalizedText

TwoStateVariableType

Optional

HasComponent

Variable

OutOfServiceState

LocalizedText

TwoStateVariableType

Optional

HasComponent

Object

ShelvingState

ShelvedStateMachineType

Optional

HasProperty

Variable

SuppressedOrShelved

Boolean

PropertyType

Mandatory

HasProperty

Variable

MaxTimeShelved

Duration

PropertyType

Optional

HasProperty

Variable

AudibleEnabled

Boolean

PropertyType

Optional

HasProperty

Variable

AudibleSound

AudioDataType

AudioVariableType

Optional

HasComponent

Variable

SilenceState

LocalizedText

TwoStateVariableType

Optional

HasProperty

Variable

OnDelay

Duration

PropertyType

Optional

HasProperty

Variable

OffDelay

Duration

PropertyType

Optional

HasComponent

Variable

FirstInGroupFlag

Boolean

BaseDataVariableType

Optional

HasComponent

Object

FirstInGroup

AlarmGroupType

Optional

HasComponent

Variable

LatchedState

LocalizedText

TwoStateVariableType

Optional

HasAlarmSuppressionGroup

Object

<AlarmGroup>

AlarmGroupType

OptionalPlaceholder

HasProperty

Variable

ReAlarmTime

Duration

PropertyType

Optional

HasComponent

Variable

ReAlarmRepeatCount

Int16

BaseDataVariableType

Optional

HasComponent

Method

Silence

Defined in 5.8.5

Optional

HasComponent

Method

Suppress

Defined in 5.8.6

Optional

HasComponent

Method

Unsuppress

Defined in 5.8.7

Optional

HasComponent

Method

RemoveFromService

Defined in 5.8.8

Optional

HasComponent

Method

PlaceInService

Defined in 5.8.9

Optional

HasComponent

Method

Reset

Defined in 5.8.4

Optional

HasSubtype

ObjectType

DiscreteAlarmType

HasSubtype

ObjectType

LimitAlarmType

HasSubtype

ObjectType

DiscrepancyAlarmType

The AlarmConditionTypeinherits all Propertiesof the AcknowledgeableConditionType. The following states are sub-states of the True EnabledState.

ActiveState/Idwhen set to True indicates that the situation the Conditionis representing currently exists. When a Conditioninstance is in the inactive state (ActiveState/Idwhen set to False) it is representing a situation that has returned to a normal state. The transitions of Conditionsto the inactive and Activestates are triggered by Serverspecific actions. Subtypes of the AlarmConditionTypespecified later in this document will have sub-state models that further define the Activestate. Recommended state names are described in Annex A.

The InputNode Propertyprovides the NodeIdof the Variablethe Valueof which is used as primary input in the calculation of the Alarmstate. If this Variableis not in the AddressSpace, a NULL NodeIdshall be provided. In some systems, an Alarmmay be calculated based on multiple Variables Values; it is up to the system to determine which Variable’s NodeIdis used.

SuppressedState, OutOfServiceStateand ShelvingStatetogether allow the suppression of Alarmson display systems. These three suppressions are generally used by different personnel or systems at a plant, i.e. automatic systems, maintenance personnel and Operators.

SuppressedStateis used internally by a Serverto automatically suppress Alarmsdue to system specific reasons. For example, a system may be configured to suppress Alarmsthat are associated with machinery that is in a state such as shutdown. For example, a low level Alarmfor a tank that is currently not in use might be suppressed. Recommended state names are described in Annex A.

OutOfServiceStateis used by maintenance personnel to suppress Alarmsdue to a maintenance issue. For example, if an instrument is taken out of service for maintenance or is removed temporarily while it is being replaced or serviced the item would have the OutOfServiceState set. Recommended state names are described in Annex A.

ShelvingStatesuggests whether an Alarmshall (temporarily) be prevented from being displayed to the user. It is quite often used by Operatorsto block nuisance Alarms. The ShelvingStateis defined in 5.8.10.

When an Alarmhas any or all of the SuppressedState, OutOfServiceStateor ShelvingStateset to True, the SuppressedOrShelvedproperty shall be set True and this Alarmis then typically not displayed by the Client. State transitions associated with the Alarmdo occur, but they are not typically displayed by the Clients as long as the Alarmremains in any of the SuppressedState, OutOfServiceStateor Shelvedstate.

The optional Property MaxTimeShelvedis used to set the maximum time that an Alarm Conditionmay be shelved. The value is expressed as duration. Systems can use this Propertyto prevent permanent Shelvingof an Alarm.If this Propertyis present it will be an upper limit on the duration passed into a TimedShelve Methodcall. If a value that exceeds the value of this Propertyis passed to the TimedShelve Method, then a Bad_ShelvingTimeOutOfRangeerror code is returned on the call. If this Propertyis present it will also be enforced for the OneShotShelvedstate, in that an Alarm Condition will transition to the Unshelvedstate from the OneShotShelvedstate if the duration specified in this Propertyexpires following a OneShotShelveoperation without a change of any of the other items associated with the Condition.

The optional Property AudibleEnabledis a Boolean that indicates if the current state of this Alarmincludes an audible Alarm.

The optional Property AudibleSoundcontains the sound file that is to be played if an audible Alarmis to be generated. This file would be play/generated as long as the Alarmis active and unacknowledged, unless the silence StateMachineis included, in which case it may also be silenced by this StateMachine.

The SilenceStateis used to suppress the generation of audible Alarms. Typically, it is used when an Operatorsilences all Alarmson a screen, but needs to acknowledge the Alarmsindividually. Silencing an Alarmshall silence the Alarmon all systems (screens) that it is being reported on. Not all Clientswill make use of this StateMachine, but it allows multiple Clientsto synchronize audible Alarmstates. Acknowledging an Alarmshall automatically silence an Alarm.

The OnDelayand OffDelay Propertiescan be used to eliminate nuisance Alarms. The OnDelayis used to avoid unnecessary Alarms when a signal temporarily overshoots its setpoint, thus preventing the Alarmfrom being triggered until the signal remains in the Alarmstate continuously for a specified length of time (OnDelaytime). The OffDelayis used to reduce chattering Alarmsby locking the Alarmindication for a certain holding period after the condition has returned to normal. I.e. the Alarmshall stay active for the OffDelaytime and shall not regenerate if it returns to active in that period. If the Alarmremains in the inactive zone for OffDelayit will then become inactive.

The optional variable FirstInGroupFlagis used together with the FirstInGroup object. The FirstInGroup Object is an instance of an AlarmGroupType that groups a number of related Alarms. The FirstInGroupFlagis set on the Alarminstance that was the first Alarmto trigger in a FirstInGroup. If this variable is present, then the FirstInGroupshall also be present. These two nodes allow an alarming system to determine which Alarmin the list was the trigger. It is commonly used in situations where Alarms are interrelated and usually multiple Alarmsoccur. For example, vibration sensors in a turbine, usually all sensors trigger if any one triggers, but what is important for an Operatoris the first sensor that triggered.

The LatchedState Object, if present, indicates that this Alarmsupports being latched. The Alarmwill remain with a retain bit of True until it is no longer active, is acknowledge and is reset. The Reset Method,if called while active has no effect on the Alarmand is ignored and an error of Bad_InvalidState is return on the call. The Objectindicates the current state, latched or not latched. Recommended state names are described in Annex A. If this Objectis provided the Reset Methodmust also be provided.

An Alarminstance may contain HasAlarmSuppressionGroup reference(s) to instance(s) of AlarmGroupType. Each instance is an AlarmSuppressionGroup. When an AlarmSuppressionGroupgoes active, the Servershall set the SuppressedStateof the Alarmto True. When all of referenced AlarmSuppressionGroupsare no longer active, then the Server shall set SuppressedStateto False. A single AlarmSuppressionGroupcan be assigned to multiple Alarms. AlarmSuppressionGroups are used to control Alarmfloods and to help manage Alarms.

ReAlarmTimeif present sets a time that is used to bring an Alarmback to the top of an Alarmlist. If an Alarmhas not returned to normal within the provided time (from when it last was alarmed), the Serverwill generate a new Alarmfor it (as if it just went into alarm). If it has been silenced it shall return to an un-silenced state, if it has been acknowledged it shall return to unacknowledged. The Alarmactive time is set to the time of the re-alarm.

ReAlarmRepeatCountif present counts the number times an Alarmwas re-alarmed. Some smart alarming system would use this count to raise the priority or otherwise generate additional or different annunciations for the given Alarm. The count is reset when an Alarmreturns to normal.

Silence Methodcan be used to silence an instance of an Alarm. It is defined in 5.8.5.

Suppress Methodcan be used to suppress an instance of an Alarm. Most Alarmsuppression occurs via advanced alarming, but this method allows additional access to suppress a particular Alarminstance. Additional details are provided in the definition in 5.8.6.

Unsuppress Methodcan be used to remove an instance of an Alarmfrom SuppressedState. Additional details are provided in the definition in 5.8.7.

PlaceInService Methodcan be used to remove an instance of an Alarmfrom OutOfServiceState. It is defined in 5.8.9.

RemoveFromService Methodcan be used to place an instance of an Alarmin OutOfServiceState. It is defined in 5.8.8.

Reset Methodis used to clear a latched Alarm. It is defined in 5.8.4. If this Objectis provided the LatchedState Objectshall also be provided.

More details about the AlarmModel and the various states can be found in Sub clause 4.8. and in Annex E.

The AlarmGroupTypeprovides a simple manner of grouping Alarms. This grouping can be used for Alarmsuppression or for identifying related Alarms. The actual usage of the AlarmGroupTypeis specified where it is used.

Table 36– AlarmGroupType Definition

Attribute

Value

BrowseName

AlarmGroupType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the FolderTypedefined in OPC 10000-5

AlarmGroupMember

Object

<AlarmConditionInstance>

AlarmConditionType

OptionalPlaceholder

The instance of an AlarmGroupTypeshould be given a name and description that describes the purpose of the Alarmgroup.

The AlarmGroupTypeinstance will contain a list of instances of AlarmConditionTypeor sub type of AlarmConditionTypereferenced by AlarmGroupMemberreferences. At least one Alarmmust be present in an instance of an AlarmGroupType.

TheReset Methodis used reset a latched Alarminstance. It is only available on an instance of an AlarmConditionTypethat exposes the LatchedState. Normally, the NodeIdof the Objectinstance is passed as the ObjectIdto the Call Service. However, some Serversdo not expose Conditioninstances in the AddressSpace. Therefore, Serversshall allow Clientsto call the Reset Methodby specifying ConditionIdas the ObjectId.The Methodcannot be called with an ObjectIdof the AlarmConditionType Node.

Signature

Reset();

The parameters are defined in Table 40

Table 37– Reset arguments

Argument

Description

Methodresult codes in Table 41(defined in Callservice)

Table 38– Silence result codes

Result Code

Description

Bad_MethodInvalid

The MethodIdprovided does not correspond to the ObjectIdprovided. See OPC 10000-4for the general description of this result code.

Bad_NodeIdInvalid

Used to indicate that the specified ObjectIdis not valid or that the Methodwas called on the ConditionType Node.

See OPC 10000-4for the general description of this result code.

Bad_InvalidState

The Alarminstance was not latched or still active or still required acknowledgement. For an AlarmInstance to be reset it must have been in Alarm, and returned to normal and have been acknowledged prior to being reset.

Table 42specifies the AddressSpacerepresentation for the Reset Method.

Table 39– Reset Method AddressSpace definition

Attribute

Value

BrowseName

Reset

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionResetEventType

Defined in 5.10.11

TheSilence Methodis used silence a specific Alarminstance. It is only available on an instance of an AlarmConditionTypethat also exposes the SilenceState. Normally, the NodeIdof the Objectinstance is passed as the ObjectIdto the Call Service. However, some Serversdo not expose Conditioninstances in the AddressSpace. Therefore, Serversshall allow Clientsto call the Silence Methodby specifying ConditionIdas the ObjectId.The Methodcannot be called with an ObjectIdof the AlarmConditionType Node.

Signature

Silence();

The parameters are defined in Table 40

Table 40– Silence arguments

Argument

Description

Methodresult codes in Table 41(defined in Callservice)

Table 41– Silence result codes

Result Code

Description

Bad_MethodInvalid

The MethodIdprovided does not correspond to the ObjectIdprovided. See OPC 10000-4for the general description of this result code.

Bad_NodeIdInvalid

Used to indicate that the specified ObjectIdis not valid or that the Methodwas called on the ConditionType Node.

See OPC 10000-4for the general description of this result code.

Comments

If the instance is not currently in an audible state, the command is ignored.

Table 42specifies the AddressSpacerepresentation for the Silence Method.

Table 42– Silence Method AddressSpace definition

Attribute

Value

BrowseName

Silence

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionSilenceEventType

Defined in 5.10.10

TheSuppress Methodis used to suppress a specific Alarminstance. It is only available on an instance of an AlarmConditionTypethat also exposes the SuppressedState. This Methodcan be used to change the SuppressedStateof an Alarmand overwrite any suppression caused by an associated AlarmSuppressionGroup. This Methodworks in parallel with any suppression triggered by an AlarmSupressionGroup, in that if the Methodis used to suppress an Alarm, an AlarmSuppressionGroupmight clear the suppression.

Normally, the NodeIdof the object instance is passed as the ObjectIdto the Call Service. However, some Serversdo not expose Conditioninstances in the AddressSpace. Therefore, Serversshall allow Clientsto call the Suppress Methodby specifying ConditionIdas the ObjectId.The Methodcannot be called with an ObjectIdof the AlarmConditionType Node.

Signature

Suppress();

Method Result Codes in Table 43(defined in Call Service)

Table 43– Suppress result codes

Result Code

Description

Bad_MethodInvalid

The MethodIdprovided does not correspond to the ObjectId provided. See OPC 10000-4for the general description of this result code.

Bad_NodeIdInvalid

Used to indicate that the specified ObjectIdis not valid or that the Methodwas called on the ConditionType Node.

See OPC 10000-4for the general description of this result code.

Comments

Suppress Methodapplies to an Alarminstance, even if it is not currently active.

Table 44specifies the AddressSpacerepresentation for the Suppress Method.

Table 44– Suppress Method AddressSpace definition

Attribute

Value

BrowseName

Suppress

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionSuppressionEventType

Defined in 5.10.4

TheUnsuppress Methodis used to clear the SuppressedStateof a specific Alarminstance. It is only available on an instance of an AlarmConditionTypethat also exposes the SuppressedState. This Methodcan be used to overwrite any suppression cause by an associated AlarmSuppressionGroup. This Methodworks in parallel with any suppression triggered by an AlarmSuppressionGroup, in that if the Methodis used to clear the SuppressedStateof an Alarm, any change in an AlarmSuppressionGroup might again suppress the Alarm.

Normally, the NodeIdof the ObjectInstance is passed as the ObjectIdto the Call Service. However, some Serversdo not expose Conditioninstances in the AddressSpace. Therefore, Serversshall allow Clientsto call the Unsuppress Methodby specifying ConditionIdas the ObjectId.The Methodcannot be called with an ObjectIdof the AlarmConditionType Node.

Signature

Unsuppress();

Method Result Codes in Table 43(defined in Call Service)

Table 45– Unsuppress result codes

Result Code

Description

Bad_MethodInvalid

The MethodIdprovided does not correspond to the ObjectIdprovided. See OPC 10000-4for the general description of this result code.

Bad_NodeIdInvalid

Used to indicate that the specified ObjectIdis not valid or that the Methodwas called on the ConditionType Node.

See OPC 10000-4for the general description of this result code.

Comments

Unsuppress Methodapplies to an Alarminstance, even if it is not currently active.

Table 44specifies the AddressSpacerepresentation for the Suppress Method.

Table 46– Unsuppress Method AddressSpace definition

Attribute

Value

BrowseName

Unsuppress

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionSuppressionEventType

Defined in 5.10.4

TheRemoveFromService Methodis used to suppress a specific Alarminstance. It is only available on an instance of an AlarmConditionType that also exposes the OutOfServiceState. Normally, the NodeIdof the object instance is passed as the ObjectIdto the Call Service. However, some Serversdo not expose Conditioninstances in the AddressSpace. Therefore, Serversshall allow Clientsto call the RemoveFromService Methodby specifying ConditionIdas the ObjectId.The Methodcannot be called with an ObjectIdof the AlarmConditionType Node.

Signature

RemoveFromService ();

Methodresult codes in Table 47(defined in Call Service)

Table 47– RemoveFromService result codes

Result Code

Description

Bad_MethodInvalid

The MethodIdprovided does not correspond to the ObjectIdprovided. See OPC 10000-4for the general description of this result code.

Bad_NodeIdInvalid

Used to indicate that the specified ObjectIdis not valid or that the Methodwas called on the ConditionType Node.

See OPC 10000-4for the general description of this result code.

Comments

Instances that do not expose the OutOfService Stateshall reject RemoveFromServicecalls. RemoveFromService Methodapplies to an Alarminstance, even if it is not currently in the Active State.

Table 48specifies the AddressSpacerepresentation for the RemoveFromService Method.

Table 48– RemoveFromService Method AddressSpace definition

Attribute

Value

BrowseName

RemoveFromService

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionOutOfServiceEventType

Defined in 5.10.12

ThePlaceInService Methodis used to set the OutOfServiceState to False of a specific Alarminstance. It is only available on an instance of an AlarmConditionTypethat also exposes the OutOfServiceState. Normally, the NodeIdof the ObjectInstance is passed as the ObjectIdto the Call Service. However, some Serversdo not expose Conditioninstances in the AddressSpace. Therefore, Serversshall allow Clientsto call the PlaceInService Methodby specifying ConditionIdas the ObjectId.The Methodcannot be called with an ObjectIdof the AlarmConditionType Node.

Signature

PlaceInService ();

Methodresult codes in Table 47(defined in Call Service)

Table 49– PlaceInService result codes

Result Code

Description

Bad_MethodInvalid

The MethodIdprovided does not correspond to the ObjectIdprovided. See OPC 10000-4for the general description of this result code.

Bad_NodeIdInvalid

Used to indicate that the specified ObjectIdis not valid or that the Methodwas called on the ConditionType Node.

See OPC 10000-4for the general description of this result code.

Comments

The PlaceInService Methodapplies to an Alarminstance, even if it is not currently in the Active State.

Table 48specifies the AddressSpacerepresentation for the PlaceInService Method.

Table 50– PlaceInService Method AddressSpace definition

Attribute

Value

BrowseName

PlaceInService

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionOutOfServiceEventType

Defined in 5.10.12

The ShelvedStateMachineTypedefines a sub-state machine that represents an advanced Alarm filtering model. This model is illustrated in Figure 15.

The state model supports two types of Shelving: OneShotShelvingand TimedShelving. They are illustrated in Figure 14. The illustration includes the allowed transitions between the various sub-states. Shelvingis an Operatorinitiated activity.

In OneShotShelving, a user requests that an Alarmbe Shelved for its current Activestate. This type of Shelvingis typically used when an Alarmis continually occurring on a boundary (i.e. a Conditionis jumping between High Alarmand HighHigh Alarm, always in the Activestate). The One Shot Shelvingwill automatically clear when an Alarmreturns to an inactive state. Another use for this type of Shelvingis for a plant area that is shutdown i.e. a long running Alarmsuch as a low level Alarmfor a tank that is not in use. When the tank starts operation again the Shelvingstate will automatically clear.

In TimedShelving, a user specifies that an Alarmbe shelved for a fixed time period. This type of Shelvingis quite often used to block nuisance Alarms. For example, an Alarmthat occurs more than 10 times in a minute may get shelved for a few minutes.

In all states, the Unshelvecan be called to cause a transition to the Unshelve state; this includes Un-shelvinganAlarmthat is in the TimedShelvestate before the time has expired and the OneShotShelvestate without a transition to an inactive state.

All but two transitions are caused by Methodcalls as illustrated in Figure 14. The “Time Expired” transition is simply a system generated transition that occurs when the time value defined as part of the “Timed Shelved Call” has expired. The “Any Transition Occurs” transition is also a system generated transition; this transition is generated when the Conditiongoes to an inactive state.

image017.png

Figure 14– Shelve state transitions

The ShelvedStateMachineTypeincludes a hierarchy of sub-states. It supports all transitions between Unshelved, OneShotShelvedand TimedShelved.

The state machine is illustrated in Figure 15and formally defined in Table 51.

image018.png

Figure 15– ShelvedStateMachineType model

Table 51–ShelvedStateMachineType definition

Attribute

Value

BrowseName

ShelvedStateMachineType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the FiniteStateMachineType defined in OPC 10000-5

HasProperty

Variable

UnshelveTime

Duration

PropertyType

Mandatory

HasComponent

Object

Unshelved

StateType

HasComponent

Object

TimedShelved

StateType

HasComponent

Object

OneShotShelved

StateType

HasComponent

Object

UnshelvedToTimedShelved

TransitionType

HasComponent

Object

TimedShelvedToUnshelved

TransitionType

HasComponent

Object

TimedShelvedToOneShotShelved

TransitionType

HasComponent

Object

UnshelvedToOneShotShelved

TransitionType

HasComponent

Object

OneShotShelvedToUnshelved

TransitionType

HasComponent

Object

OneShotShelvedToTimedShelved

TransitionType

HasComponent

Method

TimedShelve

Defined in Clause 5.8.10.3

Mandatory

HasComponent

Method

OneShotShelve

Defined in Clause 5.8.10.4

Mandatory

HasComponent

Method

Unshelve

Defined in Clause 5.8.10.2

Mandatory

UnshelveTimespecifies the remaining time in milliseconds until the Alarmautomatically transitions into the Un-shelvedstate. For the TimedShelvedstate this time is initialised with the ShelvingTimeargument of the TimedShelve Methodcall. For the OneShotShelvedstate the UnshelveTimewill be a constant set to the maximum Duration except if a MaxTimeShelvedProperty is provided.

This FiniteStateMachinesupports three Activestates; Unshelved, TimedShelvedand OneShotShelved. It also supports six transitions. The states and transitions are described in Table 52. This FiniteStateMachinealso supports three Methods; TimedShelve, OneShotShelveand Unshelve.

Table 52– ShelvedStateMachineType transitions

BrowseName

References

BrowseName

TypeDefinition

Transitions

UnshelvedToTimedShelved

FromState

Unshelved

StateType

ToState

TimedShelved

StateType

HasEffect

AlarmConditionType

HasCause

TimedShelve

Method

UnshelvedToOneShotShelved

FromState

Unshelved

StateType

ToState

OneShotShelved

StateType

HasEffect

AlarmConditionType

HasCause

OneShotShelve

Method

TimedShelvedToUnshelved

FromState

TimedShelved

StateType

ToState

Unshelved

StateType

HasEffect

AlarmConditionType

TimedShelvedToOneShotShelved

FromState

TimedShelved

StateType

ToState

OneShotShelved

StateType

HasEffect

AlarmConditionType

HasCause

OneShotShelving

Method

OneShotShelvedToUnshelved

FromState

OneShotShelved

StateType

ToState

Unshelved

StateType

HasEffect

AlarmConditionType

OneShotShelvedToTimedShelved

FromState

OneShotShelved

StateType

ToState

TimedShelved

StateType

HasEffect

AlarmConditionType

HasCause

TimedShelve

Method

TheUnshelve Methodsets the instance of AlarmConditionTypeto the Unshelvedstate. Normally, the MethodIdfound in the Shelvingchild of the Conditioninstance and the NodeIdof the Shelvingobject as the ObjectIdare passed to the Call Service. However, some Serversdo not expose Conditioninstances in the AddressSpace. Therefore, all Serversshall also allow Clientsto call the Unshelve Methodby specifying ConditionIdas the ObjectId.The Methodcannot be called with an ObjectIdof the ShelvedStateMachineType Node.

Signature

Unshelve( );

Method Result Codes in Table 53(defined in Call Service)

Table 53– Unshelve result codes

Result Code

Description

Bad_ConditionNotShelved

See Table 103for the description of this result code.

Table 54specifies the AddressSpacerepresentation for the Unshelve Method.

Table 54– Unshelve Method AddressSpace definition

Attribute

Value

BrowseName

Unshelve

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionShelvingEventType

Defined in 5.10.7

TheTimedShelve Methodsets the instance of AlarmConditionTypeto the TimedShelvedstate (parameters are defined in Table 55and result codes are described in Table 56). Normally, the MethodIdfound in the Shelvingchild of the Conditioninstance and the NodeIdof the Shelvingobject as the ObjectIdare passed to the Call Service. However, some Serversdo not expose Conditioninstances in the AddressSpace. Therefore, all Serversshall also allow Clientsto call the TimedShelve Methodby specifying ConditionIdas the ObjectId.The Methodcannot be called with an ObjectIdof the ShelvedStateMachineType Node.

Signature

TimedShelve(

[in] Duration ShelvingTime

);

Table 55– TimedShelve parameters

Argument

Description

ShelvingTime

Specifies a fixed time for which the Alarmis to be shelved. The Servermay refuse the provided duration. If a MaxTimeShelved Property exist on the Alarmthan the Shelvingtime shall be less than or equal to the value of this Property.

Method Result Codes (defined in Call Service)

Table 56– TimedShelve result codes

Result Code

Description

Bad_ConditionAlreadyShelved

See Table 103for the description of this result code.

The Alarmis already in TimedShelvedstate and the system does not allow a reset of the shelved timer.

Bad_ShelvingTimeOutOfRange

See Table 103for the description of this result code.

Comments

Shelvingfor some time is quite often used to block nuisance Alarms. For example, an Alarmthat occurs more than 10 times in a minute may get shelved for a few minutes.

In some systems the length of time covered by this duration may be limited and the Servermay generate an error refusing the provided duration. This limit may be exposed as the MaxTimeShelved Property.

Table 57specifies the AddressSpacerepresentation for the TimedShelve Method.

Table 57– TimedShelve Method AddressSpace definition

Attribute

Value

BrowseName

TimedShelve

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

AuditConditionShelvingEventType

Defined in 5.10.7

TheOneShotShelve Methodsets the instance of AlarmConditionTypeto the OneShotShelvedstate. Normally, the MethodIdfound in the Shelvingchild of the Conditioninstance and the NodeIdof the Shelvingobject as the ObjectIdare passed to the Call Service. However, some Serversdo not expose Conditioninstances in the AddressSpace. Therefore, all Serversshall also allow Clientsto call the OneShotShelve Methodby specifying ConditionIdas the ObjectId.The Methodcannot be called with an ObjectIdof the ShelvedStateMachineType Node.

Signature

OneShotShelve( );

Method Result Codes are defined in Table 58(status code field is defined in CallService)

Table 58– OneShotShelve result codes

Result Code

Description

Bad_ConditionAlreadyShelved

See Table 103for the description of this result code.

The Alarmis already in OneShotShelvedstate.

Table 59specifies the AddressSpacerepresentation for the OneShotShelve Method.

Table 59– OneShotShelve Method AddressSpace definition

Attribute

Value

BrowseName

OneShotShelve

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionShelvingEventType

Defined in 5.10.7

Alarmscan 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 LimitAlarmTypeis an abstract type used to provide a base Typefor AlarmConditionTypeswith multiple limits. The LimitAlarmTypeis illustrated in Figure 16.

image019.png

Figure 16– LimitAlarmType

The LimitAlarmTypeis formally defined in Table 60.

Table 60– 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.12.3

HasSubtype

ObjectType

NonExclusiveLimitAlarmType

Defined in Clause 5.8.13

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

Four optional limits are defined that configure the states of the derived limit AlarmTypes. These Propertiesshall be set for any Alarmlimits that are exposed by the derived limit Alarmtypes. These Propertiesare 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 Propertyshall still be provided, but will have its AccessLevelset 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 AdaptiveSAlarming. They contain the configured Alarmlimit. If a Serversupports AdaptiveAlarmingfor Alarmlimits, the corresponding base Alarmlimit 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 AdaptiveAlarmcan be reset if any algorithmic changes need to be discarded.

The Alarmlimits listed may cause an Alarmto be generated when a value equals the limit or it may generate the Alarmwhen the limit is exceeded, (i.e. the Value is above the limit for HighLimitand below the limit for LowLimit). The exact behaviour when the value is equal to the limit is Serverspecific.

The Variablethat is the source of the LimitAlarmType Alarmshall be a scalar. This LimitAlarmTypecan be subtyped if the Variablethat 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 Alarmis generated,
  • if all elements exceed the limit an Alarmis generated,
  • the limits may also be an array, in which case if any array limit is exceeded by the corresponding source array element, an Alarmis generated.

This clause describes the state machine and the base AlarmType behaviour for AlarmConditionTypeswith multiple mutually exclusive limits.

The ExclusiveLimitStateMachineTypedefines the state machine used by AlarmConditionTypesthat handle multiple mutually exclusive limits. It is illustrated in Figure 17.

image020.png

Figure 17– ExclusiveLimitStateMachineType

It is created by extending the FiniteStateMachineType. It is formally defined in Table 61and the state transitions are described in Table 62.

Table 61– ExclusiveLimitStateMachineType definition

Attribute

Value

BrowseName

ExclusiveLimitStateMachineType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the FiniteStateMachineType

HasComponent

Object

HighHigh

StateType

HasComponent

Object

High

StateType

HasComponent

Object

Low

StateType

HasComponent

Object

LowLow

StateType

HasComponent

Object

LowToLowLow

TransitionType

HasComponent

Object

LowLowToLow

TransitionType

HasComponent

Object

HighToHighHigh

TransitionType

HasComponent

Object

HighHighToHigh

TransitionType

Table 62– ExclusiveLimitStateMachineType transitions

BrowseName

References

BrowseName

TypeDefinition

Transitions

HighHighToHigh

FromState

HighHigh

StateType

ToState

High

StateType

HasEffect

AlarmConditionType

HighToHighHigh

FromState

High

StateType

ToState

HighHigh

StateType

HasEffect

AlarmConditionType

LowLowToLow

FromState

LowLow

StateType

ToState

Low

StateType

HasEffect

AlarmConditionType

LowToLowLow

FromState

Low

StateType

ToState

LowLow

StateType

HasEffect

AlarmConditionType

The ExclusiveLimitStateMachineTypedefines the sub state machine that represents the actual level of a multilevel Alarm when it is in the Activestate. The sub state machine defined here includes High, Low, HighHighand LowLowstates. This model also includes in its transition state a series of transition to and from a parent state, the inactive state. This state machine as it is defined shall be used as a sub state machine for a state machine which has an Activestate. This Activestate could be part of a “level” Alarmor “deviation” Alarmor any other Alarmstate machine.

The LowLow, Low, High, HighHighare typical for many industries. Vendors can introduce sub-state models that include additional limits; they may also omit limits in an instance. If a model omits states or transitions in the StateMachine, it is recommended that they provide the optional Property AvailableStatesand/or AvailableTransitions(see OPC 10000-5).

The ExclusiveLimitAlarmTypeis used to specify the common behaviour for Alarm Typeswith multiple mutually exclusive limits. The ExclusiveLimitAlarmTypeis illustrated in Figure 18.

image021.png

Figure 18– ExclusiveLimitAlarmType

The ExclusiveLimitAlarmTypeis formally defined in Table 63.

Table 63– ExclusiveLimitAlarmType definition

Attribute

Value

BrowseName

ExclusiveLimitAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the LimitAlarmType defined in clause 5.8.11.

HasSubtype

ObjectType

ExclusiveLevelAlarmType

Defined in Clause 5.8.14.3

HasSubtype

ObjectType

ExclusiveDeviationAlarmType

Defined in Clause 5.8.15.3

HasSubtype

ObjectType

ExclusiveRateOfChangeAlarmType

Defined in Clause 5.8.16.3

HasComponent

Object

LimitState

ExclusiveLimitStateMachineType

Mandatory

The LimitStateis a sub state of the ActiveState and has an IsTrueSubStateOfreference to the ActiveState. The LimitStaterepresents the actual limit that is violated in an instance of ExclusiveLimitAlarmType. When the ActiveStateof the AlarmConditionTypeis inactive the LimitStateshall not be available and shall return NULL on read. Any Eventsthat subscribe for fields from the LimitStatewhen the ActiveStateis inactive shall return a NULL for these unavailable fields.

The NonExclusiveLimitAlarmTypeis used to specify the common behaviour for Alarm Typeswith multiple non-exclusive limits. The NonExclusiveLimitAlarmTypeis illustrated in Figure 19.

image022.png

Figure 19– NonExclusiveLimitAlarmType

The NonExclusiveLimitAlarmTypeis formally defined in Table 64.

Table 64– NonExclusiveLimitAlarmType definition

Attribute

Value

BrowseName

NonExclusiveLimitAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the LimitAlarmType defined in clause 5.8.11.

HasSubtype

ObjectType

NonExclusiveLevelAlarmType

Defined in Clause 5.8.14.2

HasSubtype

ObjectType

NonExclusiveDeviationAlarmType

Defined in Clause 5.8.15.2

HasSubtype

ObjectType

NonExclusiveRateOfChangeAlarmType

Defined in Clause 5.8.16.2

HasComponent

Variable

HighHighState

LocalizedText

TwoStateVariableType

Optional

HasComponent

Variable

HighState

LocalizedText

TwoStateVariableType

Optional

HasComponent

Variable

LowState

LocalizedText

TwoStateVariableType

Optional

HasComponent

Variable

LowLowState

LocalizedText

TwoStateVariableType

Optional

HighHighState, HighState, LowState, and LowLowStaterepresent the non-exclusive states. As an example, it is possible that both HighState and HighHighState are in their True state. Vendors may choose to support any subset of these states. Recommended state names are described in Annex A.

Four optional limits are defined that configure these states. At least the HighStateor the LowStateshall be provided even though all states are optional. It is implied by the definition of a HighStateand a LowState, that these groupings are mutually exclusive. A value cannot exceed both a HighStatevalue and a LowStatevalue simultaneously.

A levelAlarm is commonly used to report when a limit is exceeded. It typically relates to an instrument – e.g. a temperature meter. The level Alarmbecomes active when the observed value is above a high limit or below a low limit.

The NonExclusiveLevelAlarmTypeis a special level Alarmutilized with one or more non-exclusive states. If for example both the High and HighHighstates need to be maintained as active at the same time then an instance of NonExclusiveLevelAlarmTypeshould be used.

The NonExclusiveLevelAlarmTypeis based on the NonExclusiveLimitAlarmType. It is formally defined in Table 65.

Table 65– NonExclusiveLevelAlarmType definition

Attribute

Value

BrowseName

NonExclusiveLevelAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the NonExclusiveLimitAlarmType defined in clause 5.8.13.

No additional Propertiesto the NonExclusiveLimitAlarmTypeare defined.

The ExclusiveLevelAlarmTypeis a special level Alarmutilized with multiple mutually exclusive limits. It is formally defined in Table 66.

Table 66– ExclusiveLevelAlarmType definition

Attribute

Value

BrowseName

ExclusiveLevelAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Inherits the Properties of the ExclusiveLimitAlarmType defined in clause 5.8.12.3.

No additional Propertiesto the ExclusiveLimitAlarmTypeare defined.

A deviation Alarmis commonly used to report an excess deviation between a desired set point level of a process value and an actual measurement of that value. The deviation Alarmbecomes active when the deviation exceeds or drops below a defined limit.

For example, if a set point had a value of 10, a high deviation Alarmlimit of 2 and a low deviation Alarmlimit of -1 then the low sub state is entered if the process value drops below 9; the high sub state is entered if the process value raises above 12. If the set point were changed to 11 then the new deviation values would be 10 and 13 respectively. The set point can be fixed by a configuration, adjusted by an Operatoror it can be adjusted by an algorithm, the actual functionality exposed by the set point is application specific. The deviation Alarmcan also be used to report a problem between a redundant data source where the difference between the primary source and the secondary source exceeds the included limit. In this case, the SetpointNodewould point to the secondary source.

The NonExclusiveDeviationAlarmTypeis a special level Alarmutilized with one or more non-exclusive states. If for example both the High and HighHigh states need to be maintained as active at the same time then an instance of NonExclusiveDeviationAlarmTypeshould be used.

The NonExclusiveDeviationAlarmTypeis based on the NonExclusiveLimitAlarmType. It is formally defined in Table 67.

Table 67– NonExclusiveDeviationAlarmType definition

Attribute

Value

BrowseName

NonExclusiveDeviationAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the NonExclusiveLimitAlarmType defined in clause 5.8.13.

HasProperty

Variable

SetpointNode

NodeId

PropertyType

Mandatory

HasProperty

Variable

BaseSetpointNode

NodeId

PropertyType

Optional

The SetpointNode Propertyprovides the NodeIdof the set point used in the deviation calculation. In cases where the Alarmis generated by an underlying system and if the Variableis not in the AddressSpace, a NULL NodeIdshall be provided.

The BaseSetpointNode Propertyprovides the NodeIdof the original or base setpoint. The value of this node is the value of the setpoint to which an AdaptiveAlarmcan be reset if any algorithmic changes need to be discarded. The value of this node usually contains the originally configured set point.

The ExclusiveDeviationAlarmTypeis utilized with multiple mutually exclusive limits. It is formally defined in Table 68.

Table 68– ExclusiveDeviationAlarmType definition

Attribute

Value

BrowseName

ExclusiveDeviationAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling Rule

Inherits the Propertiesof the ExclusiveLimitAlarmTypedefined in clause 5.8.12.3.

HasProperty

Variable

SetpointNode

NodeId

PropertyType

Mandatory

HasProperty

Variable

BaseSetpointNode

NodeId

PropertyType

Optional

The SetpointNode Propertyprovides the NodeIdof the set point used in the Deviationcalculation. If this Variableis not in the AddressSpace, a NULL NodeIdshall be provided.

The BaseSetpointNode Propertyprovides the NodeIdof the original or base setpoint. The value of this node is the value of the set point to which an AdaptiveAlarmcan be reset if any algorithmic changes need to be discarded. The value of this node usually contains the originally configured set point.

A Rateof Change Alarmis commonly used to report an unusual change or lack of change in a measured value related to the speed at which the value has changed. The Rateof Change Alarmbecomes active when the rate at which the value changes exceeds or drops below a defined limit.

A Rateof Changeis measured in some time unit, such as seconds or minutes and some unit of measure such as percent or meter. For example, a tank may have a High limit for the Rateof Changeof its level (measured in meters) which would be 4 meters per minute. If the tank level changes at a rate that is greater than 4 meters per minute then the High sub state is entered.

The NonExclusiveRateOfChangeAlarmTypeis a special level Alarmutilized with one or more non-exclusive states. If for example both the High and HighHigh states need to be maintained as active at the same time this AlarmConditionTypeshould be used

The NonExclusiveRateOfChangeAlarmTypeis based on the NonExclusiveLimitAlarmType. It is formally defined in Table 69.

Table 69– NonExclusiveRateOfChangeAlarmType definition

Attribute

Value

BrowseName

NonExclusiveRateOfChangeAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the NonExclusiveLimitAlarmType defined in clause 5.8.13.

HasProperty

Variable

EngineeringUnits

EUInformation

PropertyType

Optional

EngineeringUnits provides the engineering units associated with the limits values. If this is not provided the assumed Engineering Unit is the same as the EU associated with the parent variable per second e.g. if parent is meters, this unit is meters/second.

ExclusiveRateOfChangeAlarmTypeis utilized with multiple mutually exclusive limits. It is formally defined in Table 70.

Table 70– ExclusiveRateOfChangeAlarmType definition

Attribute

Value

BrowseName

ExclusiveRateOfChangeAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Inherits the Propertiesof the ExclusiveLimitAlarmTypedefined in clause 5.8.12.3.

HasProperty

Variable

EngineeringUnits

EUInformation

PropertyType

Optional

EngineeringUnits provides the engineering units associated with the limits values. If this is not provided the assumed Engineering Unit is the same as the EU associated with the parent variable per second e.g. if parent is meters, this unit is meters/second.

The DiscreteAlarmTypeis used to classify Typesinto Alarm Conditionswhere the input for the Alarmmay take on only a certain number of possible values (e.g. True/False, running/stopped/terminating). The DiscreteAlarmTypewith sub types defined in this standard is illustrated in Figure 20. It is formally defined in Table 71.

image023.png

Figure 20– DiscreteAlarmType Hierarchy

Table 71– DiscreteAlarmType definition

Attribute

Value

BrowseName

DiscreteAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the AlarmConditionType defined in clause 5.8.2.

HasSubtype

ObjectType

OffNormalAlarmType

Defined in Clause 5.8.15

The OffNormalAlarmTypeis a specialization of the DiscreteAlarmTypeintended to represent a discrete Conditionthat is considered to be not normal. It is formally defined in Table 72. This sub type is usually used to indicate that a discrete value is in an Alarmstate, it is active as long as a non-normal value is present.

Table 72– OffNormalAlarmType Definition

Attribute

Value

BrowseName

OffNormalAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the DiscreteAlarmType defined in clause 5.8.17.1

HasSubtype

ObjectType

TripAlarmType

Defined in Clause 5.8.17.4

HasSubtype

ObjectType

SystemOffNormalAlarmType

Defined in Clause 5.8.17.3

HasProperty

Variable

NormalState

NodeId

PropertyType

Mandatory

The NormalState Propertyis a Propertythat points to a Variablewhich has a value that corresponds to one of the possible values of the Variablepointed to by the InputNode Propertywhere the NormalState Property Variablevalue is the value that is considered to be the normal state of the Variablepointed to by the InputNode Property. When the value of the Variablereferenced by the InputNode Propertyis not equal to the value of the NormalState Propertythe Alarmis Active. If this Variableis not in the AddressSpace, a NULL NodeIdshall be provided.

This Conditionis used by a Serverto indicate that an underlying system that is providing Alarminformation is having a communication problem and that the Servermay have invalid or incomplete Conditionstate in the Subscription. Its representation in the AddressSpaceis formally defined in Table 73.

Table 73– SystemOffNormalAlarmType definition

Attribute

Value

BrowseName

SystemOffNormalAlarmType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasSubtype

ObjectType

CertificateExpirationAlarmType

Defined in Clause 0

Subtype of the OffNormalAlarmType, i.e. it has HasProperty Referencesto the same Nodes.

The TripAlarmTypeis a specialization of the OffNormalAlarmTypeintended to represent an equipment trip Condition. The Alarmbecomes active when the monitored piece of equipment experiences some abnormal fault such as a motor shutting down due to an overload condition. It is formally defined in Table 74. This Typeis mainly used for categorization.

Table 74– TripAlarmType definition

Attribute

Value

BrowseName

TripAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the OffNormalAlarmType defined in clause 5.8.17.2.

The InstrumentDiagnosticAlarmTypeis a specialization of the OffNormalAlarmTypeintended to represent a fault in a field device. The Alarmbecomes active when the monitored device experiences a fault such as a sensor failure. It is formally defined in Table 74. This Typeis mainly used for categorization.

Table 75– InstrumentDiagnosticAlarmType definition

Attribute

Value

BrowseName

InstrumentDiagnosticAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the OffNormalAlarmType defined in clause 5.8.17.2.

The SystemDiagnosticAlarmTypeis a specialization of the OffNormalAlarmTypeintended to represent a fault in a system or sub-system. The Alarmbecomes active when the monitored system experiences a fault. It is formally defined in Table 74. This Typeis mainly used for categorization.

Table 76– SystemDiagnosticAlarmType definition

Attribute

Value

BrowseName

SystemDiagnosticAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the OffNormalAlarmType defined in clause 5.8.17.2.

This SystemOffNormalAlarmTypeis raised by the Serverwhen the Server’sCertificate is within the ExpirationLimitof expiration. This Alarmautomatically returns to normal when the certificate is updated.

Table 77– CertificateExpirationAlarmType definition

Attribute

Value

BrowseName

CertificateExpirationAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the SystemOffNormalAlarmType defined in clause 5.8.17.3

HasProperty

Variable

ExpirationDate

DateTime

PropertyType

Mandatory

HasProperty

Variable

ExpirationLimit

Duration

PropertyType

Optional

HasProperty

Variable

CertificateType

NodeId

PropertyType

Mandatory

HasProperty

Variable

Certificate

ByteString

PropertyType

Mandatory

ExpirationDateis the date and time this certificate will expire.

ExpirationLimitis the time interval before the ExpirationDateat which this Alarmwill trigger. This shall be a positive number. If the property is not provided, a default of 2 weeks shall be used.

CertificateType– See OPC 10000-12 for definition of CertificateType.

Certificateis the certificate that is about to expire.

The DiscrepancyAlarmTypeis commonly used to report an action that did not occur within an expected time range.

The DiscrepancyAlarmTypeis based on the AlarmConditionType. It is formally defined in Table 78.

Table 78– DiscrepancyAlarmType definition

Attribute

Value

BrowseName

DiscrepancyAlarmType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the AlarmConditionTypedefined in 5.8.2.

HasProperty

Variable

TargetValueNode

NodeId

PropertyType

Mandatory

HasProperty

Variable

ExpectedTime

Duration

PropertyType

Mandatory

HasProperty

Variable

Tolerance

Double

PropertyType

Optional

The TargetValueNode Propertyprovides the NodeIdof the Variablethat is used for the target value.

The ExpectedTime Propertyprovides the Durationwithin which the value pointed to by the InputNode shall equal the value specified by the TargetValueNode(or be within the Tolerancerange, if specified).

The Tolerance Propertyis a value that can be added to or subtracted from the TargetValueNode’svalue, providing a range that the value can be in without generating the Alarm.

A DiscrepancyAlarmType can be used to indicate a motor has not responded to a start request within a given time, or that a process value has not reached a given value after a setpoint change within a given time interval.

The DiscrepancyAlarmTypeshall return to normal when the value has reached the target value.