OPC 10000-9 - UA Specification Part 9 - Alarms and Conditions 1.04

®
F O U N D A T I O N
OPC 10000-9
OPC UA Specification
OPC Unified Architecture
Part 9: Alarms & Conditions
Release 1.04
November 22, 2017
Specification Industry Standard Comments:
Type: Specification
Title: OPC Unified Date: November 22, 2017

Architecture
Part 9 :Alarms &

Conditions
Version: Release 1.04 Software: MS-Word

Source: OPC UA Part 9 - Alarms and
Conditions Release 1.04
Specification.docx
Author: OPC FOUNDATION Status: Release

OPC 10000-9: Alarms and Conditions ii Release 1.04
CONTENTS
Figures ................................................................................................................................... v
TABLES ................................................................................................................................. vi
1 Scope ............................................................................................................................. 1
2 Normative references ...................................................................................................... 1
3 Terms, definitions, and abbreviations .............................................................................. 2
3.1 Terms and definitions ............................................................................................. 2
3.2 Abbreviations and symbols ..................................................................................... 4
3.3 Used data types ..................................................................................................... 4
4 Concepts ........................................................................................................................ 4
4.1 General .................................................................................................................. 4
4.2 Conditions .............................................................................................................. 4
4.3 Acknowledgeable Conditions .................................................................................. 6
4.4 Previous states of Conditions ................................................................................. 7
4.5 Condition state synchronization .............................................................................. 8
4.6 Severity, quality, and comment ............................................................................... 8
4.7 Dialogs ................................................................................................................... 9
4.8 Alarms .................................................................................................................... 9
4.9 Multiple active states ............................................................................................ 11
4.10 Condition instances in the AddressSpace ............................................................. 12
4.11 Alarm and Condition auditing................................................................................ 13
5 Model ............................................................................................................................ 13
5.1 General ................................................................................................................ 13
5.2 Two-state state machines ..................................................................................... 14
5.3 ConditionVariable ................................................................................................. 15
5.4 ReferenceTypes ................................................................................................... 15
5.4.1 General ......................................................................................................... 15
5.4.2 HasTrueSubState ReferenceType ................................................................. 16
5.4.3 HasFalseSubState ReferenceType ................................................................ 16
5.4.4 HasAlarmSuppressionGroup ReferenceType ................................................. 17
5.4.5 AlarmGroupMember ReferenceType ............................................................. 17
5.5 Condition Model ................................................................................................... 17
5.5.1 General ......................................................................................................... 17
5.5.2 ConditionType ............................................................................................... 18
5.5.3 Condition and branch instances .................................................................... 21
5.5.4 Disable Method ............................................................................................. 22
5.5.5 Enable Method .............................................................................................. 22
5.5.6 AddComment Method .................................................................................... 23
5.5.7 ConditionRefresh Method .............................................................................. 23
5.5.8 ConditionRefresh2 Method ............................................................................ 25
5.6 Dialog Model ........................................................................................................ 27
5.6.1 General ......................................................................................................... 27
5.6.2 DialogConditionType ..................................................................................... 27
5.6.3 Respond Method ........................................................................................... 28
5.7 Acknowledgeable Condition Model ....................................................................... 29
5.7.1 General ......................................................................................................... 29
5.7.2 AcknowledgeableConditionType .................................................................... 29
Release 1.04 iii OPC 10000-9: Alarms and Conditions
5.7.3 Acknowledge Method .................................................................................... 30

5.7.4 Confirm Method ............................................................................................ 31
5.8 Alarm model ......................................................................................................... 32
5.8.1 General ......................................................................................................... 32
5.8.2 AlarmConditionType ...................................................................................... 32
5.8.3 AlarmGroupType ........................................................................................... 36
5.8.4 Reset Method................................................................................................ 37
5.8.5 Silence Method ............................................................................................. 37
5.8.6 Suppress Method .......................................................................................... 38
5.8.7 Unsuppress Method ...................................................................................... 39
5.8.8 RemoveFromService Method ........................................................................ 39
5.8.9 PlaceInService Method ................................................................................. 40
5.8.10 ShelvedStateMachineType ............................................................................ 41
5.8.11 LimitAlarmType ............................................................................................. 45
5.8.12 Exclusive Limit Types.................................................................................... 46
5.8.13 NonExclusiveLimitAlarmType ........................................................................ 49
5.8.14 Level Alarm ................................................................................................... 50
5.8.15 Deviation Alarm ............................................................................................ 51
5.8.16 Rate of change Alarms .................................................................................. 52
5.8.17 Discrete Alarms ............................................................................................ 53
5.8.18 DiscrepancyAlarmType ................................................................................. 55
5.9 ConditionClasses ................................................................................................. 56
5.9.1 Overview ....................................................................................................... 56
5.9.2 BaseConditionClassType .............................................................................. 57
5.9.3 ProcessConditionClassType .......................................................................... 57
5.9.4 MaintenanceConditionClassType .................................................................. 57
5.9.5 SystemConditionClassType ........................................................................... 57
5.9.6 SafetyConditionClassType ............................................................................ 58
5.9.7 HighlyManagedAlarmConditionClassType ..................................................... 58
5.9.8 TrainingConditionClassType ......................................................................... 58
5.9.9 StatisticalConditionClassType ....................................................................... 59
5.9.10 TestingConditionSubClassType..................................................................... 59
5.10 Audit Events ......................................................................................................... 59
5.10.1 Overview ....................................................................................................... 59
5.10.2 AuditConditionEventType .............................................................................. 60
5.10.3 AuditConditionEnableEventType ................................................................... 61
5.10.4 AuditConditionCommentEventType ............................................................... 61
5.10.5 AuditConditionRespondEventType ................................................................ 61
5.10.6 AuditConditionAcknowledgeEventType ......................................................... 61
5.10.7 AuditConditionConfirmEventType .................................................................. 62
5.10.8 AuditConditionShelvingEventType ................................................................. 62
5.10.9 AuditConditionSuppressionEventType ........................................................... 62
5.10.10 AuditConditionSilenceEventType................................................................... 62
5.10.11 AuditConditionResetEventType ..................................................................... 63
5.10.12 AuditConditionOutOfServiceEventType ......................................................... 63
5.11 Condition Refresh related Events ......................................................................... 63
5.11.1 Overview ....................................................................................................... 63
5.11.2 RefreshStartEventType ................................................................................. 64
5.11.3 RefreshEndEventType .................................................................................. 64
OPC 10000-9: Alarms and Conditions iv Release 1.04
5.11.4 RefreshRequiredEventType .......................................................................... 64

5.12 HasCondition Reference type ............................................................................... 65
5.13 Alarm & Condition status codes ............................................................................ 65
5.14 Expected A&C server behaviours ......................................................................... 65
5.14.1 General ......................................................................................................... 65
5.14.2 Communication problems .............................................................................. 66
5.14.3 Redundant A&C servers ................................................................................ 66
6 AddressSpace organisation ........................................................................................... 66
6.1 General ................................................................................................................ 66
6.2 EventNotifier and source hierarchy ....................................................................... 66
6.3 Adding Conditions to the hierarchy ....................................................................... 67
6.4 Conditions in InstanceDeclarations ....................................................................... 68
6.5 Conditions in a VariableType ................................................................................ 68
7 System State & Alarms ................................................................................................. 70
7.1 Overview .............................................................................................................. 70
7.2 HasEffectDisable .................................................................................................. 70
7.3 HasEffectEnable .................................................................................................. 70
7.4 HasEffectSuppress ............................................................................................... 71
7.5 HasEffectUnsuppressed ....................................................................................... 71
8 Alarm Metrics ................................................................................................................ 72
8.1 Overview .............................................................................................................. 72
8.2 AlarmMetricsType ................................................................................................ 72
8.3 AlarmRateVariableType ........................................................................................ 73
8.4 Reset Method ....................................................................................................... 73
Annex A (informative) Recommended localized names ........................................................ 75
A.1 Recommended state names for TwoState variables .............................................. 75
A.1.1 LocaleId “en” ................................................................................................. 75
A.1.2 LocaleId “de” ................................................................................................. 75
A.1.3 LocaleId “fr” .................................................................................................. 76
A.2 Recommended dialog response options ............................................................... 76
Annex B (informative) Examples .......................................................................................... 78
B.1 Examples for Event sequences from Condition instances ..................................... 78
B.1.1 Overview ....................................................................................................... 78
B.1.2 Server maintains current state only ............................................................... 78
B.1.3 Server maintains previous states .................................................................. 78
B.2 AddressSpace examples ...................................................................................... 80
Annex C (informative) Mapping to EEMUA .......................................................................... 82
Annex D (informative) Mapping from OPC A&E to OPC UA A&C ......................................... 83
D.1 Overview .............................................................................................................. 83
D.2 Alarms and Events COM UA wrapper ................................................................... 83
D.2.1 Event areas................................................................................................... 83
D.2.2 Event sources ............................................................................................... 83
D.2.3 Event categories ........................................................................................... 84
D.2.4 Event attributes ............................................................................................. 85
D.2.5 Event subscriptions ....................................................................................... 85
D.2.6 Condition instances ....................................................................................... 87
D.2.7 Condition Refresh ......................................................................................... 88
D.3 Alarms and Events COM UA proxy ....................................................................... 88
Release 1.04 v OPC 10000-9: Alarms and Conditions
D.3.1 General ......................................................................................................... 88

D.3.2 Server status mapping .................................................................................. 88
D.3.3 Event Type mapping ..................................................................................... 88
D.3.4 Event category mapping ................................................................................ 89
D.3.5 Event Category attribute mapping ................................................................. 90
D.3.6 Event Condition mapping .............................................................................. 93
D.3.7 Browse mapping ........................................................................................... 93
D.3.8 Qualified names ............................................................................................ 94
D.3.9 Subscription filters ........................................................................................ 95
Annex E – IEC62682 Mapping .............................................................................................. 97
E.1 Overview .............................................................................................................. 97
E.2 Terms ................................................................................................................... 97
E.3 Alarm records & State Indications ...................................................................... 105
Annex F System State (Informative) ................................................................................... 107
F.1 Overview ............................................................................................................ 107
F.2 SystemStateStateMachineType .......................................................................... 108
FIGURES
Figure 1 – Base Condition state model ................................................................................... 5

Figure 2 – AcknowledgeableConditions state model ............................................................... 6
Figure 3 – Acknowledge state model ...................................................................................... 7
Figure 4 - Confirmed Acknowledge state model ...................................................................... 7
Figure 5 – Alarm state machine model ................................................................................. 10
Figure 7 – Multiple active states example ............................................................................. 12
Figure 8 – ConditionType hierarchy ...................................................................................... 14
Figure 9 – Condition model .................................................................................................. 18
Figure 11 – AcknowledgeableConditionType overview.......................................................... 29
Figure 13 – Alarm Model ...................................................................................................... 33
Figure 14 – Shelve state transitions ..................................................................................... 42
Figure 15 – ShelvedStateMachineType model ...................................................................... 42
Figure 16 – LimitAlarmType.................................................................................................. 45
Figure 17 – ExclusiveLimitStateMachineType ....................................................................... 47
Figure 18 – ExclusiveLimitAlarmType ................................................................................... 48
Figure 19 – NonExclusiveLimitAlarmType ............................................................................. 49
Figure 20 – DiscreteAlarmType Hierarchy ............................................................................ 53
Figure 21 – ConditionClass type hierarchy ........................................................................... 56
Figure 22 – AuditEvent hierarchy ......................................................................................... 60
Figure 23 – Refresh Related Event Hierarchy ....................................................................... 64
Figure 24 – Typical HasNotifier Hierarchy ............................................................................ 67
Figure 25 – Use of HasCondition in a HasNotifier hierarchy ................................................. 68
Figure 26 – Use of HasCondition in an InstanceDeclarat ion ................................................. 68
Figure 27 – Use of HasCondition in a VariableType .............................................................. 69
Figure B.1 – Single state example ........................................................................................ 78
Figure B.2 – Previous state example .................................................................................... 79
OPC 10000-9: Alarms and Conditions vi Release 1.04
Figure B.3 – HasCondition used with Condition instances .................................................... 80

Figure B.4 – HasCondition reference to a Condition type ...................................................... 81
Figure B.5 – HasCondition used with an instance declaration ............................................... 81
Figure D.1 – The type model of a wrapped COM AE server .................................................. 85
Figure D.2 – Mapping UA Event Types to COM A&E Event Types ........................................ 89
Figure D.3 – Example mapping of UA Event Types to COM A&E categories ......................... 90
Figure D.4 – Example mapping of UA Event Types to A&E categories with attributes ........... 93
TABLES
Table 1 – Parameter types defined in Part 3 ........................................................................... 4

Table 2 – Parameter types defined in Part 4 ........................................................................... 4
Table 3 – TwoStateVariableType definition ........................................................................... 14
Table 4 – ConditionVariableType definition .......................................................................... 15
Table 5 – HasTrueSubState ReferenceType ......................................................................... 16
Table 6 – HasFalseSubState ReferenceType ....................................................................... 16
Table 7 – HasAlarmSuppressionGroup ReferenceType ........................................................ 17
Table 8 – AlarmGroupMember ReferenceType ..................................................................... 17
Table 9 – ConditionType definition ....................................................................................... 19
Table 10 – SimpleAttributeOperand ...................................................................................... 21
Table 11 – Disable result codes ........................................................................................... 22
Table 12 – Disable Method AddressSpace definition ............................................................ 22
Table 13 – Enable result codes ............................................................................................ 22
Table 14 – Enable Method AddressSpace definition ............................................................. 22
Table 15 – AddComment arguments ..................................................................................... 23
Table 16 – AddComment result codes .................................................................................. 23
Table 17 – AddComment Method AddressSpace definition ................................................... 23
Table 18 – ConditionRefresh parameters ............................................................................. 24
Table 19 – ConditionRefresh result codes ............................................................................ 24
Table 20 – ConditionRefresh Method AddressSpace definition ............................................. 25
Table 21 – ConditionRefresh2 parameters............................................................................ 25
Table 22 – ConditionRefresh2 result codes .......................................................................... 26
Table 23 – ConditionRefresh2 Method AddressSpace definition ........................................... 26
Table 24 – DialogConditionType Definition ........................................................................... 27
Table 25 – Respond parameters........................................................................................... 28
Table 26 – Respond Result Codes ....................................................................................... 28
Table 27 – Respond Method AddressSpace definition .......................................................... 28
Table 28 – AcknowledgeableConditionType definition .......................................................... 29
Table 29 – Acknowledge parameters .................................................................................... 30
Table 30 – Acknowledge result codes .................................................................................. 30
Table 31 – Acknowledge Method AddressSpace definition ................................................... 31
Table 32 – Confirm Method parameters ................................................................................ 31
Table 33 – Confirm result codes ........................................................................................... 31
Release 1.04 vii OPC 10000-9: Alarms and Conditions
Table 34 – Confirm Method AddressSpace definition ............................................................ 32

Table 35 – AlarmConditionType definition ............................................................................ 33
Table 36 – AlarmGroupType Definition ................................................................................. 36
Table 37 – Reset arguments ................................................................................................ 37
Table 38 – Silence result codes ........................................................................................... 37
Table 39 – Reset Method AddressSpace definition ............................................................... 37
Table 40 – Silence arguments .............................................................................................. 38
Table 41 – Silence result codes ........................................................................................... 38
Table 42 – Silence Method AddressSpace definition ............................................................ 38
Table 43 – Suppress result codes ........................................................................................ 38
Table 44 – Suppress Method AddressSpace definition ......................................................... 39
Table 45 – Unsuppress result codes ..................................................................................... 39
Table 46 – Unsuppress Method AddressSpace definition ..................................................... 39
Table 47 – RemoveFromService result codes ....................................................................... 40
Table 48 – RemoveFromService Method AddressSpace definition ....................................... 40
Table 49 – PlaceInService result codes ................................................................................ 40
Table 50 – PlaceInService Method AddressSpace definition ................................................. 41
Table 51 –ShelvedStateMachineType definition ................................................................... 42
Table 52 – ShelvedStateMachineType transitions ................................................................ 43
Table 53 – Unshelve result codes......................................................................................... 43
Table 54 – Unshelve Method AddressSpace definition ......................................................... 43
Table 55 – TimedShelve parameters .................................................................................... 44
Table 56 – TimedShelve result codes ................................................................................... 44
Table 57 – TimedShelve Method AddressSpace definition .................................................... 44
Table 58 – OneShotShelve result codes ............................................................................... 45
Table 59 – OneShotShelve Method AddressSpace definition ................................................ 45
Table 60 – LimitAlarmType definition .................................................................................... 46
Table 61 – ExclusiveLimitStateMachineType definition ......................................................... 47
Table 62 – ExclusiveLimitStateMachineType transitions ....................................................... 47
Table 63 – ExclusiveLimitAlarmType definition ..................................................................... 49
Table 64 – NonExclusiveLimitAlarmType definition ............................................................... 50
Table 65 – NonExclusiveLevelAlarmType definition .............................................................. 50
Table 66 – ExclusiveLevelAlarmType definition .................................................................... 51
Table 67 – NonExclusiveDeviationAlarmType definition ....................................................... 51
Table 68 – ExclusiveDeviationAlarmType definition .............................................................. 52
Table 69 – NonExclusiveRateOfChangeAlarmType definition ............................................... 52
Table 70 – ExclusiveRateOfChangeAlarmType definition ..................................................... 53
Table 71 – DiscreteAlarmType definition .............................................................................. 53
Table 72 – OffNormalAlarmType Definition ........................................................................... 54
Table 73 – SystemOffNormalAlarmType definition ................................................................ 54
Table 74 – TripAlarmType definition ..................................................................................... 54
Table 75 – InstrumentDiagnosticAlarmType definition .......................................................... 55
Table 76 – SystemDiagnosticAlarmType definition ............................................................... 55
OPC 10000-9: Alarms and Conditions viii Release 1.04
Table 77 – CertificateExpirationAlarmType definition ............................................................ 55

Table 78 – DiscrepancyAlarmType definition ........................................................................ 56
Table 79 – BaseConditionClassType definition ..................................................................... 57
Table 80 – ProcessConditionClassType definition ................................................................ 57
Table 81 – MaintenanceConditionClassType definition ......................................................... 57
Table 82 – SystemConditionClassType definition ................................................................. 58
Table 83 – SafetyConditionClassType definition ................................................................... 58
Table 84 – HighlyManagedAlarmConditionClassType definition ............................................ 58
Table 85 – TrainingConditionClassType definition ................................................................ 58
Table 86 – StatisticalConditionClassType definition ............................................................. 59
Table 87 – TestingConditionSubClassType definition ........................................................... 59
Table 88 – AuditConditionEventType definition..................................................................... 60
Table 89 – AuditConditionEnableEventType definition .......................................................... 61
Table 90 – AuditConditionCommentEventType definition ...................................................... 61
Table 91 – AuditConditionRespondEventType definition ....................................................... 61
Table 92 – AuditConditionAcknowledgeEventType definition ................................................ 61
Table 93 – AuditConditionConfirmEventType definition ........................................................ 62
Table 94 – AuditConditionShelvingEventType definition ....................................................... 62
Table 95 – AuditConditionSuppressionEventType definition ................................................. 62
Table 96 – AuditConditionSilenceEventType definition ......................................................... 63
Table 97 – AuditConditionResetEventType definition............................................................ 63
Table 98 – AuditConditionOutOfServiceEventType definition ................................................ 63
Table 99 – RefreshStartEventType definition ........................................................................ 64
Table 100 – RefreshEndEventType definition ....................................................................... 64
Table 101 – RefreshRequiredEventType definition ............................................................... 64
Table 102 – HasCondition ReferenceType ........................................................................... 65
Table 103 – Alarm & Condition result codes ......................................................................... 65
Table 104 – HasEffectDisable ReferenceType ...................................................................... 70
Table 105 – HasEffectEnable ReferenceType ...................................................................... 71
Table 106 – HasEffectSuppress ReferenceType ................................................................... 71
Table 107 – HasEffectUnsuppress ReferenceType ............................................................... 72
Table 108 – AlarmMetricsType Definition ............................................................................. 72
Table 109 – AlarmRateVariableType Definition .................................................................... 73
Table 110 – Suppress result codes ...................................................................................... 73
Table 111 – Reset Method AddressSpace definition ............................................................. 74
Table A.1 – Recommended state names for LocaleId “en” .................................................... 75
Table A.2 – Recommended display names for LocaleId “en” ................................................. 75
Table A.3 – Recommended state names for LocaleId “de” .................................................... 76
Table A.4 – Recommended display names for LocaleId “de” ................................................. 76
Table A.5 – Recommended state names for LocaleId “fr” ..................................................... 76
Table A.6 – Recommended display names for LocaleId “fr” .................................................. 76
Table A.7 – Recommended dialog response options ............................................................ 77
Table B.1 – Example of a Condition that only keeps the latest state ..................................... 78
Release 1.04 ix OPC 10000-9: Alarms and Conditions
Table B.2 – Example of a Condition that maintains previous states via branches ................. 79
Table C.1 – EEMUA Terms .................................................................................................. 82
Table D.1 – Mapping from standard Event categories to OPC UA Event types ..................... 84
Table D.2 – Mapping from ONEVENTSTRUCT fields to UA BaseEventType Variables ......... 86
Table D.3 – Mapping from ONEVENTSTRUCT fields to UA AuditEventType Variables ......... 86
Table D.4 – Mapping from ONEVENTSTRUCT fields to UA AlarmType Variables ................. 87
Table D.5 – Event category attribute mapping table ............................................................. 90
Table E.1 - IEC62682 Mapping ............................................................................................. 97
Table F.1 – SystemStateStateMachineType definition ........................................................ 109
Table F.2 - SystemStateStateMachineType transitions ....................................................... 110
OPC 10000-9: Alarms and Conditions x Release 1.04
OPC FOUNDATION
____________
UNIFIED ARCHITECTURE –
FOREWORD
This specification is the specification for developers of OPC UA applications. The specification is a result of an analysis a nd
design process to develop a standard interface to facilitate the development of applications by multiple vendors that shall
inter-operate seamlessly together.
Copyright © 2006-2018, OPC Foundation, Inc.
AGREEMENT OF USE
COPYRIGHT RESTRICTIONS
Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and
statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work
covered by copyright herein may be reproduced or used in any form or by any means --graphic, electronic, or mechanical,
including photocopying, recording, taping, or information storage and retrieval systems --without permission of the copyright
owner.
OPC Foundation members and non-members are prohibited from copying and redistributing this specification. All copies must
be obtained on an individual basis, directly from the OPC Foundation Web site
http://www.opcfoundation.org .
HTU UTH
PATENTS
The attention of adopters is directed to the possibility that compliance with or adoption of OPC specifications may require
use of an invention covered by patent rights. OPC shall not be responsible for identifying patents for which a license may be
required by any OPC specification, or for conducting legal inquiries into the legal validity or scope of those patents that a re
brought to its attention. OPC specifications are prospective and advisory only. Prospective users are responsible for
protecting themselves against liability for infringement of patents.
WARRANTY AND LIABILITY DISCLAIMERS
WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR
MISPRINTS. THE OPC FOUDATION MAKES NO WARRANTY OF ANY KIND, EXPRESSED OR IMPLIED, WITH REGARD
TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED
WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT
SHALL THE OPC FOUNDATION BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOS S OF PROFITS,
REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING,
PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
The entire risk as to the quality and performance of so ftware developed using this specification is borne by you.
RESTRICTED RIGHTS LEGEND
This Specification is provided with Restricted Rights. Use, duplication or disclosure by the U.S. government is subject to
restrictions as set forth in (a) this Agreement pursuant to DFARs 227.7202-3(a); (b) subparagraph (c)(1)(i) of the Rights in
Technical Data and Computer Software clause at DFARs 252.227 -7013; or (c) the Commercial Computer Software Restricted
Rights clause at FAR 52.227-19 subdivision (c)(1) and (2), as applicable. Contractor / manufacturer are the OPC Foundation,.
16101 N. 82nd Street, Suite 3B, Scottsdale, AZ, 85260 -1830
COMPLIANCE
The OPC Foundation shall at all times be the sole entity that may authorize developers, suppliers and sellers of hardware
and software to use certification marks, trademarks or other special designations to indicate compliance with these materials .
Products developed using this specification may claim compliance or conformance with this specification if and only if the
software satisfactorily meets the certification requirements set by the OPC Foundation. Products that do not meet these
requirements may claim only that the product was based on this specification and must not claim compliance or conformance
with this specification.
TRADEMARKS
Most computer and software brand names have trademarks or registered trademarks. The individual trademarks have not
been listed here.
Release 1.04 xi OPC 10000-9: Alarms and Conditions
GENERAL PROVISIONS
Should any provision of this Agreement be held to be void, invalid, unenforceable or illegal by a court, the validity and
enforceability of the other provisions shall not be affected thereby.
This Agreement shall be governed by and construed under the laws of the State of Minnesota, excluding its choice or law
rules.
This Agreement embodies the entire understanding between the parties with respect to, and supersedes any prior
understanding or agreement (oral or written) relating to, this specification.
ISSUE REPORTING
The OPC Foundation strives to maintain the highest quality standards for its published specifications, hence they undergo
constant review and refinement. Readers are encouraged to report any issues and view any existing errata here:
http://www.opcfoundation.org/errata
HTU UTH
OPC 10000-9: Alarms and Conditions xii Release 1.04
Revision 1.04 Highlights
The following table includes the Mantis issues resolved with this revision.
Mantis
Summary Resolution
ID
3237 IEC 62682 / ISA 18.2 support Added annex at end of document describing mapping between
two standards
3238 IEC 62682 terms and definitions Added additional terms as needed
3239 Silence from IEC62682 Added silence to AlarmConditionType
3240 IEC 62682 properties Added alarm properties including Ondelay, offdelay,
firstInGroup, realarmtime, realarmrepeatcount , conditionclass
modifier, and more
3241 Alarm System Diagnostics Added diagnostic information to allow server collect
standardized alarm diagnostic information
3269 1.03 / Page 11 / 5.1 / The Fixed formatting (also fixed other format and link issues)
formatting of the third paragraph is
broken
3380 IEC 62682 - Additional Alarm types Added Discrepancy Alarms, Deviation Alarm uses
3444 Missing references in Removed Modelling rules as indicated. Added text to

Opc.Ua.NodeSet2.xml StateMachines that might have instances where some states
and/or transition are not exposed, to expose ValidateStates
and ValidTransitions optional properties allowing clients to
determine what states are valid for the given instance
3452 AuditConditionCommentEventType Updated the name of the field to ConditionEventId

EventId field should be
AffectedEventId
3453 Safety Alarms are common; A Added section on Safety

Safety ConditionClass would be
useful.
3540 For IEC 62682 add OutOfService Added new optional StateMachine to the Alarm Model
3542 Highly Managed Alarms The model needs to be able to indicate a highly managed
alarm
3680 Table error on duplicate names Fix all table to have correct consistent names
3666 System State Added ReferenceType so that system state machines can
easily effect alarm states. Also include a sample system state
machine.
3716 Definition of SourceNode SourceNode updated to include “Property” when referencing

the property not the term.
3733 COM AE Mapping fActive to Added text to limit scope of assignment in wrapper code
TransitionTime is not accurate. example.
3749 Limit alarms and Arrays The specification should describe the behaviour of limit alarms
with respect to source variable that are arrays.
3795 Enable/Disable methods and how The specification already described Enable with regard to
they interact with branches, but the disable was updated to indicate all branches
ConditionBranches are disabled..
4021 Alarms in AddressSpace - Clarify Updated text to indicate what is required and what is server
behaviour when properties change specific behaviour
OPC 10000-9: Alarms and Conditions 1 Release 1.04
OPC Unified Architecture Specification
Part 9: Alarms & Conditions
1 Scope
This document specifies the representation of Alarms and Conditions in the OPC Unified
Architecture. Included is the Information Model representation of Alarms and Conditions in the
OPC UA address space. Other aspects of alarm systems like alarm philosophy, life cycle, alarm
response times, alarm types and many other details are captured in standards such as IEC
62682 and ISA 18.2. The Alarms and Conditions Information Model in this specification, is
designed in accordance with IEC 62682and ISA 18.2.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments
and errata) applies.
OPC 10000-1, OPC Unified Architecture - Part 1: Overview and Concepts

http://www.opcfoundation.org/UA/Part1/
OPC 10000-3, OPC Unified Architecture - Part 3: Address Space Model

OPC 10000-4, OPC Unified Architecture - Part 4: Services

OPC 10000-5, OPC Unified Architecture - Part 5: Information Model

OPC 10000-6, OPC Unified Architecture - Part 6: Mappings

OPC 10000-7, OPC Unified Architecture - Part 7: Profiles

OPC 10000-8, OPC Unified Architecture - Part 8: Data Access

OPC 10000-11, OPC Unified Architecture - Part 11: Historical Access

EEMUA: 2nd Edition EEMUA 191 – Alarm System – A guide to design, management and
procurement (Appendixes 6, 7, 8, 9)
https://www.eemua.org/Products/Publications/Print/EEMUA -Publication-191.aspx
IEC 62682: Management of alarms systems for the process industries ( Edition 1.0 2014-10)
https://webstore.iec.ch/publication/7363
ISA 18.2: Management of Alarm Systems for the Process Industries

https://www.isa.org/store/ansi/isa-182-2016,-management-of-alarm-systems-for-the-
process-industries/46962105
Release 1.04 2 OPC 10000-9: Alarms and Conditions
IETF RFC2045: Multipurpose Internet Mail Extensions (MIME) Part One
https://www.ietf.org/rfc/rfc2045.txt
IETF RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two
IETF RFC2047: Multipurpose Internet Mail Extensions (MI ME) Part Three
3 Terms, definitions, and abbreviations

3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in The following documents,
in whole or in part, are normatively referenced in this document and are indispensable for its
application. For dated references, only the edition cited applies. For undated references, the
latest edition of the referenced document (including any amendments and errata) applies.
OPC 10000-1, OPC 10000-3, OPC 10000-4, and OPC 10000-5 as well as the following apply.
3.1.1
Acknowledge
Operator action that indicates recognition of an Alarm
Note 1 to entry: This definition is copied from EEMUA. The term “Accept” is another common term used to describe
Acknowledge. They can be used interchangeably. This document will use Acknowledge.
3.1.2
Active
state for an Alarm that indicates that the situation the Alarm is representing currently exists
Note 1 to entry: Other common terms defined by EEMUA are “Standing” for an Active Alarm and “Cleared” when
the Condition has returned to normal and is no longer Active.
3.1.3
AdaptiveAlarm
Alarm for which the set point or limits are changed by an algorithm.
Note 1 to entry: AdaptiveAlarms are alarms that are adjusted automatically by algorithms. These algorithms might
detect conditions in a plant and change setpoints or limits to keep alarms from occurring. These changes occur, in
many cases, without Operator interactions.
3.1.4
AlarmFlood
condition during which the alarm rate is greater than the Operator can effectively manage
Note 1 to entry: OPC UA does not define the conditions that would be considered alarm flooding, these condition s
are defined in other specification such as IEC 62682 or ISA 18.2
3.1.5
AlarmSuppressionGroup
group of Alarms that is used to suppress other Alarms.
Note 1 to entry: An AlarmSuppressionGroup is an instance of an AlarmGroupType that is used to suppress other
Alarms. If any Alarm in the group is active, then the AlarmSuppressionGroup is active. If all Alarms in the
AlarmSuppressionGroup are inactive then the AlarmSuppressionGroup is inactive
Note 2 to entry: The Alarm to be affected references AlarmSuppressionGroups with a HasAlarmSuppressionGroup
ReferenceType.
3.1.6
ConditionClass
Condition grouping that indicates in which domain or for what purpose a certain Condition is
used
Note 1 to entry: Some top-level ConditionClasses are defined in this specification. Vendors or organisations may
derive more concrete classes or define different top -level classes.
3.1.7
ConditionBranch
specific state of a Condition
Note 1 to entry: The Server can maintain ConditionBranches for the current state as well as for previous states.
3.1.8
ConditionSource
element which a specific Condition is based upon or related to
Note 1 to entry: Typically, it will be a Variable representing a process tag (e.g. FIC101) or an Object representing
a device or subsystem.
In Events generated for Conditions, the SourceNode Property (inherited from the BaseEventType) will contain the
NodeId of the ConditionSource.
3.1.9
Confirm
Operator action informing the Server that a corrective action has been taken to address the
cause of the Alarm
3.1.10
Disable
system is configured such that the Alarm will not be generated even though the base Alarm
Condition is present
Note 1 to entry: This definition is copied from EEMUA and is further defined in EEMUA.
In IEC62682 disable is referenced as “Out of Service” .
3.1.11
LatchIngAlarm
alarm that remains in alarm state after the process condition has returned to normal and requires an
Operator reset before the alarm returns to normal
Note 1 to entry: Latching alarms are typically discrepancy alarms, where an action does not occur within a specific
time. Once the action occurs the alarm stays active until it is reset.
3.1.12
Operator
special user who is assigned to monitor and control a portion of a process
Note 1 to entry: “A Member of the operations team who is assigned to monitor and control a portion of the process
and is working at the control system’s Console” as defined in EEMUA. In this standard an Operator is a special user.
All descriptions that apply to general users also apply to Operators.
3.1.13
Refresh
act of providing an update to an Event Subscription that provides all Alarms which are
considered to be Retained
Note 1 to entry: This concept is further defined in EEMUA.
3.1.14
Retain
Alarm in a state that is interesting for a Client wishing to synchronize its state of Conditions
with the Server’s state
3.1.15
Shelving
facility where the Operator is able to temporarily prevent an Alarm from being displayed to the
Operator when it is causing the Operator a nuisance
Note 1 to entry ”A Shelved Alarm will be removed from the list and will not re -annunciate until un-shelved.” as
defined in EEMUA.
3.1.16
Suppress
act of determining whether an Alarm should not occur
Note 1 to entry: “An Alarm is suppressed when logical criteria are applied to determine that the Alarm should not
occur, even though the base Alarm Condition (e.g. Alarm setting exceeded) is present” as defined in EEMUA. In
IEC62682 Suppressed Alarms are also described as being “Suppressed by Design”, in that the system is design ed
with logic to Suppress an Alarm when certain criteria exist. For example, if a process unit is taken off line then low
level alarms are Suppressed for all equipment in the off -line unit.
3.2 Abbreviations and symbols

A&E Alarm & Event (as used for OPC COM)
COM (Microsoft Windows) Component Object Model
DA Data Access
MIME Multipurpose Internet Mail Extensions
UA Unified Architecture
3.3 Used data types
The following tables describe the data types that are used throughout this document. These
types are separated into two tables. Base data types defined in OPC 10000-3 are given in Table
1. The base types and data types defined in OPC 10000-4 are given in Table 2.
Table 1 – Parameter types defined in OPC 10000-3

Parameter Type
Argument
BaseDataType
NodeId
LocalizedText
Boolean
ByteString
Double
Duration
String
UInt16
Int32
UtcTime
Table 2 – Parameter types defined in OPC 10000-4
Parameter Type
IntegerId
StatusCode
4 Concepts
4.1 General
This standard defines an Information Model for Conditions, Dialog Conditions, and Alarms
including acknowledgement capabilities. It is built upon and extends base Event handling which
is defined in OPC 10000-3, OPC 10000-4 and OPC 10000-5. This Information Model can also
be extended to support the additional needs of specific domains. The details of what aspects
of the Information Model are supported are defined via Profiles (see OPC 10000-7 for Profile
definitions). Some systems may expose historical Events and Conditions via the standard
Historical Access framework (see OPC 10000-11 for Historical Event definitions).
4.2 Conditions
Conditions are used to represent the state of a system or one of its components. Some common
examples are:
 a temperature exceeding a configured limit

 a device needing maintenance
 a batch process that requires a user to confirm some step in the process before
proceeding
Each Condition instance is of a specific ConditionType. The ConditionType and derived types
are sub-types of the BaseEventType (see OPC 10000-3 and OPC 10000-5). This part defines
types that are common across many industries. It is expected that vendors or other
standardisation groups will define additional ConditionTypes deriving from the common base
types defined in this part. The ConditionTypes supported by a Server are exposed in the
AddressSpace of the Server.
Condition instances are specific implementations of a ConditionType. It is up to the Server

whether such instances are also exposed in the Server’s AddressSpace. Clause 4.10 provides
additional background about Condition instances. Condition instances shall have a unique
identifier to differentiate them from other instances. This is independent of whether they are
exposed in the AddressSpace.
As mentioned above, Conditions represent the state of a system or one o f its components. In
certain cases, however, previous states that still need attention also have to be maintained.
ConditionBranches are introduced to deal with this requirement and distinguish current state
and previous states. Each ConditionBranch has a BranchId that differentiates it from other
branches of the same Condition instance. The ConditionBranch which represents the current
state of the Condition (the trunk) has a NULL BranchId. Servers can generate separate Event
Notifications for each branch. When the state represented by a ConditionBranch does not need
further attention, a final Event Notification for this branch will have the Retain Property set to
False. Clause 4.4 provides more information and use cases. Maintaining previous states and
therefore the support of multiple branches is optional for Servers.
Conceptually, the lifetime of the Condition instance is independent of its state. However,
Servers may provide access to Condition instances only while ConditionBranches exist.
The base Condition state model is illustrated in Figure 1. It is extended by the various Condition
subtypes defined in this standard and may be further extended by vendors or other
standardisation groups. The primary states of a Condition are disabled and enabled. The
Disabled state is intended to allow Conditions to be turned off at the Server or below the Server
(in a device or some underlying system). The Enabled state is normally extended with the
addition of sub-states.
Disabled
Enabled
Figure 1 – Base Condition state model
A transition into the Disabled state results in a Condition Event however no subsequent Event
Notifications are generated until the Condition returns to the Enabled state.
When a Condition enters the Enabled state, that transition and all subsequent transitions result
in Condition Events being generated by the Server.
If Auditing is supported by a Server, the following Auditing related action shall be performed.
The Server will generate AuditEvents for Enable and Disable operations (either through a
Method call or some Server / vendor – specific means), rather than generating an AuditEvent
Notification for each Condition instance being enabled or disabled. For more information, see
the definition of AuditConditionEnableEventType in 5.10.2. AuditEvents are also generated for
any other Operator action that results in changes to the Conditions.
4.3 Acknowledgeable Conditions

AcknowledgeableConditions are sub-types of the base ConditionType.
AcknowledgeableConditions expose states to indicate whether a Condition has to be
acknowledged or confirmed.
An AckedState and a ConfirmedState extend the EnabledState defined by the Condition. The
state model is illustrated in Figure 2. The enabled state is extended by adding the AckedState
and (optionally) the ConfirmedState.
Disabled
Enabled
AckedState = TRUE AckedState = False
ConfirmedState ConfirmedState
= TRUE = False
Figure 2 – AcknowledgeableConditions state model
Acknowledgment of the transition may come from the Client or may be due to some logic internal
to the Server. For example, acknowledgment of a related Condition may result in this Condition
becoming acknowledged, or the Condition may be set up to automatically Acknowledge itself
when the acknowledgeable situation disappears.
Two Acknowledge state models are supported by this standard. Either of these state models
can be extended to support more complex acknowledgement situations.
The basic Acknowledge state model is illustrated in Figure 3. This model defines an AckedState.
The specific state changes that result in a change to the state depend on a Server’s
implementation. For example, in typical Alarm models the change is limited to a transition to
the Active state or transitions within the Active state. More complex models however can also
allow for changes to the AckedState when the Condition transitions to an inactive state.
AckedState = TRUE
Ack
Acknowledge
By
Method
Server
AckedState = False
Figure 3 – Acknowledge state model
A more complex state model which adds a confirmation to the basic Acknowledge is illustrated
in Figure 4. The Confirmed Acknowledge model is typically used to differentiate between
acknowledging the presence of a Condition and having done something to address the
Condition. For example, an Operator receiving a motor high temperature Notification calls the
Acknowledge Method to inform the Server that the high temperature has been observed. The
Operator then takes some action such as lowering the load on the motor in order to reduce the
temperature. The Operator then calls the Confirm Method to inform the Server that a corrective
action has been taken.
Acknowledged Unacknowledged
Acknowledge Method
Acknowledge By Server
Server restricts to
Unconfirmed until
Acknowledged
Unconfirmed Confirmed
Confirm Method
Confirmed by Server
Figure 4 - Confirmed Acknowledge state model
4.4 Previous states of Conditions

Some systems require that previous states of a Condition are preserved for some time. A
common use case is the acknowledgement process. In certain environments , it is required to
acknowledge both the transition into Active state and the transition into an inactive state.
Systems with strict safety rules sometimes require that every transition into Active state has to
be acknowledged. In situations where state changes occur in short succession there can be
multiple unacknowledged states and the Server has to maintain ConditionBranches for all
previous unacknowledged states. These branches will be deleted after they have been
acknowledged or if they reached their final state.
Multiple ConditionBranches can also be used for other use cases where snapshots of pr evious
states of a Condition require additional actions.
4.5 Condition state synchronization

When a Client subscribes for Events, the Notification of transitions will begin at the time of the
Subscription. The currently existing state will not be reported. Thi s means for example that
Clients are not informed of currently Active Alarms until a new state change occurs.
Clients can obtain the current state of all Condition instances that are in an interesting state,
by requesting a Refresh for a Subscription. It should be noted that Refresh is not a general
replay capability since the Server is not required to maintain an Event history.
Clients request a Refresh by calling the ConditionRefresh Method. The Server will respond with
a RefreshStartEventType Event. This Event is followed by the Retained Conditions. The Server
may also send new Event Notifications interspersed with the Refresh related Event
Notifications. After the Server is done with the Refresh, a RefreshEndEvent is issued marking
the completion of the Refresh. Clients shall check for multiple Event Notifications for a
ConditionBranch to avoid overwriting a new state delivered together with an older state from
the Refresh process. If a ConditionBranch exists, then the current Condition shall be reported.
This is True even if the only interesting item regarding the Condition is that ConditionBranches
exist. This allows a Client to accurately represent the current Condition state.
A Client that wishes to display the current status of Alarms and Conditions (known as a “current
Alarm display”) would use the following logic to process Refresh Event Notifications. The Client
flags all Retained Conditions as suspect on reception of the Event of the
RefreshStartEventType. The Client adds any new Events that are received during the Refresh
without flagging them as suspect. The Client also removes the suspect flag from any Retained
Conditions that are returned as part of the Refresh. When the Client receives a
RefreshEndEvent, the Client removes any remaining suspect Events, since they no longer
apply.
The following items should be noted with regard to ConditionRefresh:
 As described in 4.4 some systems require that previous states of a Condition are
preserved for some time. Some Servers – in particular if they require acknowledgement
of previous states – will maintain separate ConditionBranches for prior states that still
need attention.
ConditionRefresh shall issue Event Notifications for all interesting states (current and
previous) of a Condition instance and Clients can therefore receive more than one Event
for a Condition instance with different BranchIds.
 Under some circumstances a Server may not be capable of ensuring the Client is fully
in sync with the current state of Condition instances. For example, if the underlying
system represented by the Server is reset or communications are lost for some period
of time the Server may need to resynchronize itself with the underlying system. In these
cases, the Server shall send an Event of the RefreshRequiredEventType to advise the
Client that a Refresh may be necessary. A Client receiving this special Event should
initiate a ConditionRefresh as noted in this clause.
 To ensure a Client is always informed, the three special EventTypes
(RefreshEndEventType, RefreshStartEventType and RefreshRequiredEventType)
ignore the Event content filtering associated with a Subscription and will always be
delivered to the Client.
 ConditionRefresh applies to a Subscription. If multiple Event Notifiers are included in
the same Subscription, all Event Notifiers are refreshed.
4.6 Severity, quality, and comment
Comment, severity and quality are important elements of Conditions and any change to them
will cause Event Notifications.
The Severity of a Condition is inherited from the base Event model defined in OPC 10000-5. It
indicates the urgency of the Condition and is also commonly called ‘priority’, especially in
relation to Alarms in the ProcessConditionClassType.
A Comment is a user generated string that is to be associated with a certain state of a Condition.
Quality refers to the quality of the data value(s) upon which this Condition is based. Since a
Condition is usually based on one or more Variables, the Condition inherits the quality of these
Variables. E.g., if the process value is “Uncertain”, the “Level Alarm” Condition is also
questionable. If more than one variable is represented by a given condition or if the condition
is from an underlining system and no direct mapping to a variable is available, it is up to the
application to determine what quality is displayed as part of the condition.
4.7 Dialogs
Dialogs are ConditionTypes used by a Server to request user input. They are typically used
when a Server has entered some state that requires intervention by a Client. For example a
Server monitoring a paper machine indicates that a roll of paper has been wound and is ready
for inspection. The Server would activate a Dialog Condition indicating to the user that an
inspection is required. Once the inspection has taken place the user responds by informing the
Server of an accepted or unaccepted inspection allowing the process to continue.
4.8 Alarms
Alarms are specializations of AcknowledgeableConditions that add the concepts of an Active
state and other states like Shelving state and Suppressed state to a Condition. The state model
is illustrated in Figure 5. The complete model with all states is defined in 5.8.
Disabled
Enabled
Active = False
Active = TRUE
Suppressed = TRUE Suppressed = False
Shelved Unshelved
OutOfService=TRUE OutOfService= False
AckedState = TRUE AckedState = False
ConfirmedState
ConfirmedState
= TRUE = False
SilenceState SilenceState
= TRUE = False
Figure 5 – Alarm state machine model
An Alarm in the Active state indicates that the situation the Condition is representing currently
exists. When an Alarm is an inactive state it is representing a situation that has returned to a
normal state.
Some Alarm subtypes introduce sub-states of the Active state. For example, an Alarm
representing a temperature may provide a high level state as well as a critically high state (see
following Clause).
The shelving state can be set by an Operator via OPC UA Methods. The suppressed state is
set internally by the Server due to system specific reasons. Alarm systems typically implement
the suppress, out of service and shelve features to help keep Operators from being
overwhelmed during Alarm “storms” by limiting the number of Alarms an Operator sees on a
current Alarm display. This is accomplished by setting the SuppressedOrShelved flag on second
order dependent Alarms and/or Alarms of less severity, leading the Operator to concentrate on
the most critical issues.
The shelved, out of service and suppressed states differ from the Disabled state in that Alarms
are still fully functional and can be included in Subscription Notifications to a Client.
Alarms follow a typical timeline that is illustrated in Figure 6. They have a number of delay times
associated with them and a number of states that they might occupy. The goal of an alarming
system is to inform Operators about conditions in a timely manner and allow the Operator to
take some action before some consequences occur. The consequences may be economic
(product is not usable and must be discard), may be physical (tank overflows), may safety (fire
or explosion could occur) or any of a number of ot her possibilities. Typically, if no action is
taken related to an alarm for some period of time the process will cross some threshold at which
point consequences will start to occur. The OPC UA Alarm model describes these states, delays
and actions.
In Alarm
Normal Acknowledged Alarm Normal
Unacknowledged
Allowable Response time No Action, Process has

consequences
Consequences
start occurring
Process Value
Process
Responds to
action
Alarm Limit
Ack Operator Process Alarm Deadband
Delay Response Delay
Delay
Time OffDelay
Figure 6 - Typical Alarm Timeline example
4.9 Multiple active states

In some cases, it is desirable to further define the Active state of an Alarm by providing a sub-
state machine for the Active State. For example, a multi-state level Alarm when in the Active
state may be in one of the following sub-states: LowLow, Low, High or HighHigh. The state
model is illustrated in Figure 7.
Active = False
Active = TRUE
Low High
LowLow HighHigh
Figure 7 – Multiple active states example
With the multi-state Alarm model, state transitions among the sub-states of Active are allowed
without causing a transition out of the Active state.
To accommodate different use cases both a (mutually) exclusive and a non -exclusive model
are supported.
Exclusive means that the Alarm can only be in one sub-state at a time. If for example a
temperature exceeds the HighHigh limit the associated exclusive level Alarm will be in the
HighHigh sub-state and not in the High sub-state.
Some Alarm systems, however, allow multiple sub-states to exist in parallel. This is called non-
exclusive. In the previous example where the temperature exceeds the HighHigh limit a non -
exclusive level Alarm will be both in the High and the HighHigh sub-state.
4.10 Condition instances in the AddressSpace

Because Conditions always have a state (Enabled or Disabled) and possibly many sub-states
it makes sense to have instances of Conditions present in the AddressSpace. If the Server
exposes Condition instances they usually will appear in the AddressSpace as components of
the Objects that “own” them. For example, a temperature transmitter that has a built-in high
temperature Alarm would appear in the AddressSpace as an instance of some temperature
transmitter Object with a HasComponent Reference to an instance of a LimitAlarmType.
The availability of instances allows Data Access Clients to monitor the current Condition state
by subscribing to the Attribute values of Variable Nodes. The values of the nodes may not
always correspond with the value that appear in Events, they may be more recent then what
was in the Event.
While exposing Condition instances in the AddressSpace is not always possible, doing so allows
for direct interaction (read, write and Method invocation) with a specific Condition instance. For
example, if a Condition instance is not exposed, there is no way to invoke the Enable or Disable
Method for the specific Condition instance.
4.11 Alarm and Condition auditing

The OPC UA Standards include provisions for auditing. Auditing is an important security and
tracking concept. Audit records provide the “Who”, “When” and “What” information regarding
user interactions with a system. These audit records are especially important when Alarm
management is considered. Alarms are the typical instrument for providing information to a user
that something needs the user’s attention. A record of how the user reacts to this information
is required in many cases. Audit records are generated for all Method calls that affect the state
of the system, for example, an Acknowledge Method call would generate an
AuditConditionAcknowledgeEventType Event.
The standard AuditEventTypes defined in OPC 10000-5 already include the fields required for
Condition related audit records. To allow for filtering and grouping, this standard defines a
number of sub-types of the AuditEventTypes but without adding new fields to them.
This standard describes the AuditEventType that each Method is required to generate. For
example, the Disable Method has an AlwaysGeneratesEvent Reference to an
AuditConditionEnableEventType. An Event of this type shall be generated for every invocation
of the Method. The audit Event describes the user interaction with the system, in some cases
this interaction may affect more than one Condition or be related to more than one state.
5 Model
5.1 General
The Alarm and Condition model extends the OPC UA base Event model by defining various
Event Types based on the BaseEventType. All of the Event Types defined in this standard can
be further extended to form domain or Server specific Alarm and Condition Types.
Instances of Alarm and Condition Types may be optionally exposed in the AddressSpace in
order to allow direct access to the state of an Alarm or Condition.
The following sub clauses define the OPC UA Alarm and Condition Types. Figure 8 informally
describes the hierarchy of these Types. Subtypes of the LimitAlarmType and the
DiscreteAlarmType are not shown. The full AlarmConditionType hierarchy can be found in
Figure 8
.
BaseEvent
Defined in [UA Part 5]
Type
StateMachine
Type
SystemEvent
Type
ConditionType
RefreshStart
Acknowledgeable DialogCondition EventType
Condition Type Type
Shelved
AlarmCondition StateMachineType
Type RefreshEnd
EventType
LimitAlarm DiscreteAlarm ExclusiveLimit

Type Type StateMachineType
RefreshRequired
EventType
OffNormalAlarm
Type
SystemOffNormal
AlarmType
Figure 8 – ConditionType hierarchy
5.2 Two-state state machines

Most states defined in this standard are simple – i.e. they are either True or False. The
TwoStateVariableType is introduced specifically for this use case. More complex states are
modelled by using a StateMachineType defined in OPC 10000-5.
The TwoStateVariableType is derived from the StateVariableType defined in OPC 10000-5 and
formally defined in Table 3.
Table 3 – TwoStateVariableType definition
Attribute Value
BrowseName TwoStateVariableType
DataType LocalizedText
ValueRank -1 (-1 = Scalar)
IsAbstract False
References NodeClass BrowseName DataType TypeDefinition Modelling
Rule
Subtype of the StateVariableType defined in OPC 10000-5.
Note that a Reference to this subtype is not shown in the definition of the StateVariableType
HasProperty Variable Id Boolean PropertyType Mandatory
HasProperty Variable TransitionTime UtcTime PropertyType Optional
HasProperty Variable EffectiveTransitionTime UtcTime PropertyType Optional
HasProperty Variable TrueState LocalizedText PropertyType Optional
HasProperty Variable FalseState LocalizedText PropertyType Optional
HasTrueSubState StateMachine or <StateIdentifier> Defined in Clause 5.4.2 Optional
TwoStateVariableType
HasFalseSubState StateMachine or <StateIdentifier> Defined in Clause 5.4.3 Optional
TwoStateVariableType
The Value Attribute of an instance of TwoStateVariableType contains the current state as a

human readable name. The EnabledState for example, might contain the name “Enabled” when
True and “Disabled” when False.
Id is inherited from the StateVariableType and overridden to reflect the required DataType
(Boolean). The value shall be the current st ate, i.e. either True or False.
TransitionTime specifies the time when the current state was entered.
EffectiveTransitionTime specifies the time when the current state or one of its sub states was
entered. If, for example, a LevelAlarm is active and – while active – switches several times
between High and HighHigh, then the TransitionTime stays at the point in time where the Alarm
became active whereas the EffectiveTransitionTime changes with each shift of a sub state.
The optional Property EffectiveDisplayName from the StateVariableType is used if a state has
sub states. It contains a human readable name for the current state after taking the state of any
SubStateMachines in account. As an example, the EffectiveDisplayName of the EnabledState
could contain “Active/HighHigh” to specify th at the Condition is active and has exceeded the
HighHigh limit.
Other optional Properties of the StateVariableType have no defined meaning for

TwoStateVariableType.
TrueState and FalseState contain the localized string for the TwoStateVariableType value when
its Id Property has the value True or False, respectively. Since the two Properties provide meta-
data for the Type, Servers may not allow these Properties to be selected in the Event filter for
a MonitoredItem. Clients can use the Read Service to get the information from the specific
ConditionType.
A HasTrueSubState Reference is used to indicate that the True state has sub states.
A HasFalseSubState Reference is used to indicate that the False state has sub states.
5.3 ConditionVariable
Various information elements of a Condition are not considered to be states. However, a change
in their value is considered important and supposed to trigger an Event Notification. These
information elements are called ConditionVariable.
ConditionVariables are represented by a ConditionVariableType, formally defined in Table 4.
Table 4 – ConditionVariableType definition
Attribute Value
BrowseName ConditionVariableType
DataType BaseDataType
ValueRank -2 (-2 = Any)
IsAbstract False
Rule
Subtype of the BaseDataVariableType defined in OPC 10000-5.
HasProperty Variable SourceTimestamp UtcTime PropertyType Mandatory
SourceTimestamp indicates the time of the last change of the Value of this ConditionVariable.
It shall be the same time that would be returned from the Read Service inside the DataValue
structure for the ConditionVariable Value Attribute.
5.4 ReferenceTypes
5.4.1 General
This Clause defines ReferenceTypes that are needed beyond those already specified as part
of OPC 10000-3 and OPC 10000-5. This includes extending TwoStateVariableType state
machines with sub states and the addition of Alarm grouping.
The TwoStateVariableType References will only exist when sub states are available. For
example, if a TwoStateVariableType machine is in a False State, then any sub states referenced
from the True state will not be available. If an Event is generated while in the False state and
information from the True state sub state is part of the data that is to be reported than this data
would be reported as a NULL. With this approach, TwoStateVariableTypes can be extended
with subordinate state machines in a similar fashion to the StateMachineType defined in OPC
10000-5.
5.4.2 HasTrueSubState ReferenceType

The HasTrueSubState ReferenceType is a concrete ReferenceType that can be used directly.
It is a subtype of the NonHierarchicalReferences ReferenceType.
The semantics indicate that the sub state (the target Node) is a subordinate state of the True
super state. If more than one state within a Condition is a sub state of the same super state
(i.e. several HasTrueSubState References exist for the same super state) they are all treated
as independent sub states. The representation in the AddressSpace is specified in Table 5.
The SourceNode of the Reference shall be an instance of a TwoStateVariableType and the

TargetNode shall be either an instance of a TwoStateVariableType or an instance of a subtype
of a StateMachineType.
It is not required to provide the HasTrueSubState Reference from super state to sub state, but
it is required that the sub state provides the inverse Reference (IsTrueSubStateOf) to its super
state.
Table 5 – HasTrueSubState ReferenceType
Attributes Value
BrowseName HasTrueSubState
InverseName IsTrueSubStateOf
Symmetric False
IsAbstract False
References NodeClass BrowseName Comment
5.4.3 HasFalseSubState ReferenceType

The HasFalseSubState ReferenceType is a concrete ReferenceType that can be used directly.
It is a subtype of the NonHierarchicalReferences ReferenceType.
The semantics indicate that the sub state (the target Node) is a subordinate state of the False
super state. If more than one state within a Condition is a sub state of the same super state
(i.e. several HasFalseSubState References exist for the same super state) they are all treated
as independent sub states. The representation in the AddressSpace is specified in Table 6.
The SourceNode of the Reference shall be an instance of a TwoStateVariableType and the

TargetNode shall be either an instance of a TwoStateVariableType or an instance of a subtype
of a StateMachineType.
It is not required to provide the HasFalseSubState Reference from super state to sub state, but
it is required that the sub state provides the inverse Reference (IsFalseSubStateOf) to its super
state.
Table 6 – HasFalseSubState ReferenceType
Attributes Value
BrowseName HasFalseSubState
InverseName IsFalseSubStateOf
Symmetric False
IsAbstract False
5.4.4 HasAlarmSuppressionGroup ReferenceType

The HasAlarmSuppressionGroup ReferenceType is a concrete ReferenceType that can be used
directly. It is a subtype of the HasComponent ReferenceType.
This ReferenceType binds an AlarmSuppressionGroup to an Alarm.
The SourceNode of the Reference shall be an instance of an AlarmConditionType or sub type

and the TargetNode shall be an instance of an AlarmGroupType.
Table 7 – HasAlarmSuppressionGroup ReferenceType
Attributes Value
BrowseName HasAlarmSuppressionGroup
InverseName IsAlarmSuppressionGroupOf
Symmetric False
IsAbstract False
5.4.5 AlarmGroupMember ReferenceType

The AlarmGroupMember ReferenceType is a concrete ReferenceType that can be used directly.
It is a subtype of the Organizes Reference Type.
This ReferenceType is used to indicate the Alarm instances that are part of an Alarm Group.
The SourceNode of the Reference shall be an instance of an AlarmGroupType or sub type of it

and the TargetNode shall be an instance of an AlarmConditionType or a subtype of it.
Table 8 – AlarmGroupMember ReferenceType
Attributes Value
BrowseName AlarmGroupMember
InverseName MemberOfAlarmGroup
Symmetric False
IsAbstract False
5.5 Condition Model

5.5.1 General
The Condition model extends the Event model by defining the ConditionType. The
ConditionType introduces the concept of states differentiating it from the base Event model.
Unlike the BaseEventType, Conditions are not transient. The ConditionType is further extended
into Dialog and AcknowledgeableConditionType, each of which has their own sub-types.
The Condition model is illustrated in Figure 9 and formally defined in the subsequent tables. It
is worth noting that this figure, like all figures in this document, is not intended to be complete.
Rather, the figures only illustrate information provided by the formal definitions .
BaseEventType
ConditionType
PropertyType:
PropertyType:
ConditionName ConditionClassId
PropertyType:
PropertyType: ConditionClassName
BranchId
PropertyType:
PropertyType: ConditionSubClassId
Retain PropertyType:
ConditionSubClassName
ConditionVariableType:
Quality
ConditionRefresh
LastSeverity
ConditionRefresh2
TwoStateVariableType:
Enable
EnableState
Disable
Comment
AddComment
ClientUserId
Acknowledgeable Dialog
ConditionType ConditionType
Figure 9 – Condition model
5.5.2 ConditionType
The ConditionType defines all general characteristics of a Condition. All other ConditionTypes
derive from it. It is formally defined in Table 9. The False state of the EnabledState shall not be
extended with a sub state machine.
Table 9 – ConditionType definition
Attribute Value
BrowseName ConditionType
IsAbstract True
Rule
Subtype of the BaseEventType defined in OPC 10000-5
HasSubtype ObjectType DialogConditionType Defined in Clause 5.6.2
HasSubtype ObjectType AcknowledgeableConditio Defined in Clause 5.7.2
nType
HasProperty Variable ConditionClassId NodeId PropertyType Mandatory

HasProperty Variable ConditionClassName LocalizedText PropertyType Mandatory
HasProperty Variable ConditionSubClassId NodeId[] PropertyType Optional
HasProperty Variable ConditionSubClassName LocalizedText[] PropertyType Optional
HasProperty Variable ConditionName String PropertyType Mandatory
HasProperty Variable BranchId NodeId PropertyType Mandatory
HasProperty Variable Retain Boolean PropertyType Mandatory
HasComponent Variable EnabledState LocalizedText TwoStateVariableType Mandatory
HasComponent Variable Quality StatusCode ConditionVariableType Mandatory
HasComponent Variable LastSeverity UInt16 ConditionVariableType Mandatory
HasComponent Variable Comment LocalizedText ConditionVariableType Mandatory
HasProperty Variable ClientUserId String PropertyType Mandatory
HasComponent Method Disable Defined in Clause 5.5.4 Mandatory

HasComponent Method Enable Defined in Clause 5.5.5 Mandatory
HasComponent Method AddComment Defined in Clause 5.5.6 Mandatory
HasComponent Method ConditionRefresh Defined in Clause 5.5.7 None
HasComponent Method ConditionRefresh2 Defined in Clause 5.5.8 None
The ConditionType inherits all Properties of the BaseEventType. Their semantic is defined in
OPC 10000-5. SourceNode Property identifies the ConditionSource. See 5.12 for more details.
If the ConditionSource is not a Node in the AddressSpace, the NodeId is set to NULL. The
SourceNode Property is the Node, which the Condition is associated with, it may be the same
as the InputNode for an Alarm, but it may be a separate node. For example, a motor, which is
a Variable with a Value that is an RPM, may be the ConditionSource for Conditions that are
related to the motor as well as a temperature sensor associated with the motor. In the former
the InputNode for the High RPM Alarm is the value of the Motor RPM, while in the later the
InputNode of the High Alarm would be the value of the temperature sensor that is associated
with the motor.
ConditionClassId specifies in which domain this Condition is used. It is the NodeId of the
corresponding subtype of BaseConditionClassType. See 5.9 for the definition of ConditionClass
and a set of ConditionClasses defined in this standard. When using this Property for filtering,
Clients have to specify all individual subtypes of BaseConditionClassType NodeIds. The OfType
operator cannot be applied. BaseConditionClassType is used as class whenever a Condition
cannot be assigned to a more concrete class.
ConditionClassName provides the display name of the subtype of BaseConditionClassType.
ConditionSubClassId specifies additional class[es] that apply to the Condition. It is the NodeId
of the corresponding subtype of BaseConditionClassType. See 5.9.6 for the definition of
ConditionClass and a set of ConditionClasses defined in this standard. When using this
Property for filtering, Clients have to specify all individual sub types of BaseConditionClassType
NodeIds. The OfType operator cannot be applied. The Client specifies a NULL in the filter, to
return Conditions where no sub class is applied. When returning Conditions, if this optional field
is not available in a Condition, a NULL shall be returned for the field.
ConditionSubClassName provides the display name[s] of the ConditionClassType[s] listed in

the ConditionSubClassId.
ConditionName identifies the Condition instance that the Event originated from. It can be used
together with the SourceName in a user display to distinguish between different Condition
instances. If a ConditionSource has only one instance of a ConditionType, and the Server has
no instance name, the Server shall supply the ConditionType browse name.
BranchId is NULL for all Event Notifications that relate to the current state of the Condition
instance. If BranchId is not NULL, it identifies a previous state of this Condition instance that
still needs attention by an Operator. If the current ConditionBranch is transformed into a
previous ConditionBranch then the Server needs to assign a non-NULL BranchId. An initial
Event for the branch will generated with the values of the ConditionBranch and the new
BranchId. The ConditionBranch can be updated many times before it is no longer needed. When
the ConditionBranch no longer requires Operator input the final Event will have Retain set to
False. The retain bit on the current Event is True, as long as any ConditionBranches require
Operator input. See 4.4 for more information about the need for creating and maintaining
previous ConditionBranches and Clause B.1 for an example using branches. The BranchId
DataType is NodeId although the Server is not required to have ConditionBranches in the
Address Space. The use of a NodeId allows the Server to use simple numeric identifiers, strings
or arrays of bytes.
Retain when True describes a Condition (or ConditionBranch) as being in a state that is
interesting for a Client wishing to synchronize its state with the Server’s state. The logic to
determine how this flag is set is Server specific. Typically, all Active Alarms would have the
Retain flag set; however, it is also possible for inactive Alarms to have their Retain flag set to
TRUE.
In normal processing when a Client receives an Event with the Retain flag set to False, the
Client should consider this as a ConditionBranch that is no longer of interest, in the case of a
“current Alarm display” the ConditionBranch would be removed from the display.
EnabledState indicates whether the Condition is enabled. EnabledState/Id is True if enabled,

False otherwise. EnabledState/TransitionTime defines when the EnabledState last changed.
Recommended state names are described in Annex A.
A Condition’s EnabledState effects the generation of Event Notifications and as such results in
the following specific behaviour:
 When the Condition instance enters the Disabled state, the Retain Property of this
Condition shall be set to False by the Server to indicate to the Client that the Condition
instance is currently not of interest to Clients. This includes all ConditionBranches if any
branches exist.
 When the Condition instance enters the enabled state, the Condition shall be evaluated
and all of its Properties updated to reflect the current values. If this evaluation causes
the Retain Property to transition to True for any ConditionBranch, then an Event
Notification shall be generated for that ConditionBranch.
 The Server may choose to continue to test for a Condition instance while it is Disabled.
However, no Event Notifications will be generated while the Condition instance is
disabled.
 For any Condition that exists in the AddressSpace the Attributes and the following
Variables will continue to have valid values even in the Disabled state; EventId, Event
Type, Source Node, Source Name, Time, and EnabledState. Other Properties may no
longer provide current valid values. All Variables that are no longer provided shall return
a status of Bad_ConditionDisabled. The Event that reports the Disabled state should
report the Properties as NULL or with a status of Bad_ConditionDisabled.
When enabled, changes to the following components shall cause a ConditionType Event
Notification:
 Quality
 Severity (inherited from BaseEventType)
 Comment
This may not be the complete list. Sub-Types may define additional Variables that trigger Event
Notifications. In general, changes to Variables of the types TwoStateVariableType or
ConditionVariableType trigger Event Notifications.
Quality reveals the status of process values or other resources that this Condition instance is
based upon. If, for example, a process value is “Uncertain”, the associated “LevelAlarm”
Condition is also questionable. Values for the Quality can be any of the OPC StatusCodes
defined in OPC 10000-8 as well as Good, Uncertain and Bad as defined in OPC 10000-4. These
StatusCodes are similar to but slightly more generic than the description of data quality in the
various field bus specifications. It is the responsibility of the Server to map internal status
information to these codes. A Server that supports no quality information shall return Good.
This quality can also reflect the communication status associated with the system that this value
or resource is based on and from which this Alarm was received. For communication errors to
the underlying system, especially those that result in some unavailable Event fields, the quality
shall be Bad_NoCommunication error.
Events are only generated for Conditions that have their Retain field set to True and for the
initial transition of the Retain field from True to False.
LastSeverity provides the previous severity of the ConditionBranch. Initially this Variable
contains a zero value; it will return a value only after a severity change . The new severity is
supplied via the Severity Property, which is inherited from the BaseEventType.
Comment contains the last comment provided for a certain state ( ConditionBranch). It may have
been provided by an AddComment Method, some other Method or in some other manner. The
initial value of this Variable is NULL, unless it is provided in some other manner. If a Method
provides as an option the ability to set a Comment, then the value of this Variable is reset to
NULL if an optional comment is not provided.
ClientUserId is related to the Comment field and contains the identity of the user who inserted
the most recent Comment. The logic to obtain the ClientUserId is defined in OPC 10000-5.
The NodeId of the Condition instance is used as ConditionId. It is not explicitly modelled as a
component of the ConditionType. However, it can be requested with the following
SimpleAttributeOperand (see Table 10) in the SelectClause of the EventFilter:
Table 10 – SimpleAttributeOperand
Name Type Description

SimpleAttributeOperand
typeId NodeId NodeId of the ConditionType Node
browsePath[] QualifiedName empty
attributeId IntegerId Id of the NodeId Attribute
5.5.3 Condition and branch instances

Conditions are Objects which have a state which changes over time. Each Condition instance
has the ConditionId as identifier which uniquely identifies it within the Server.
A Condition instance may be an Object that appears in the Server Address Space. If this is the
case the ConditionId is the NodeId for the Object.
The state of a Condition instance at any given time is the set values for the Variables that
belong to the Condition instance. If one or more Variable values change the Server generates
an Event with a unique EventId.
If a Client calls Refresh the Server will report the current state of a Condition instance by re-
sending the last Event (i.e. the same EventId and Time is sent).
A ConditionBranch is a copy of the Condition instance state that can change independently of
the current Condition instance state. Each Branch has an identifier called a BranchId which is
unique among all active Branches for a Condition instance. Branches are typically not visible in
the Address Space and this standard does not define a standard way to make them visible.
5.5.4 Disable Method

The Disable Method is used to change a Condition instance to the Disabled state. Normally, the
NodeId of the object instance as the ObjectId is passed to the Call Service. However, some
Servers do not expose Condition instances in the AddressSpace. Therefore, all Servers shall
allow Clients to call the Disable Method by specifying ConditionId as the ObjectId. The Method
cannot be called with an ObjectId of the ConditionType Node.
Signature
Disable();
Method Result Codes in Table 11 (defined in Call Service)
Table 11 – Disable result codes
Result Code Description

Bad_ConditionAlreadyDisabled See Table 103 for the description of this result code.
Table 12 specifies the AddressSpace representation for the Disable Method.
Table 12 – Disable Method AddressSpace definition
Attribute Value
BrowseName Disable
Rule
AlwaysGeneratesEvent ObjectType AuditConditionEnable Defined in 5.10.2
EventType
5.5.5 Enable Method

The Enable Method is used to change a Condition instance to the enabled state. Normally, the
NodeId of the object instance as the ObjectId is passed to the Call Service. However, some
allow Clients to call the Enable Method by specifying ConditionId as the ObjectId. The Method
cannot be called with an ObjectId of the ConditionType Node. If the Condition instance is not
exposed, then it may be difficult for a Client to determine the ConditionId for a disabled
Condition.
Signature
Enable();
Method result codes in Table 13 (defined in Call Service)
Table 13 – Enable result codes

Bad_ConditionAlreadyEnabled See Table 103 for the description of this result code.
Table 14 specifies the AddressSpace representation for the Enable Method.
Table 14 – Enable Method AddressSpace definition
Attribute Value
BrowseName Enable
Rule
AlwaysGeneratesEvent ObjectType AuditConditionEnableEventType Defined in 5.10.2
5.5.6 AddComment Method

The AddComment Method is used to apply a comment to a specific state of a Condition instance.
Normally, the NodeId of the Object instance is passed as the ObjectId to the Call Service.
However, some Servers do not expose Condition instances in the AddressSpace. Therefore, all
Servers shall also allow Clients to call the AddComment Method by specifying ConditionId as
the ObjectId. The Method cannot be called with an ObjectId of the ConditionType Node.
Signature
AddComment(
[in] ByteString EventId
[in] LocalizedText Comment
);
The parameters are defined in Table 15
Table 15 – AddComment arguments
Argument Description
EventId EventId identifying a particular Event Notification where a state was reported for a
Condition.
Comment A localized text to be applied to the Condition.
Table 16 – AddComment result codes

Bad_MethodInvalid The MethodId provided does not correspond to the ObjectId provided. See OPC 10000-
4 for the general description of this result code.
Bad_EventIdUnknown See Table 103 for the description of this result code.
Bad_NodeIdInvalid Used to indicate that the specified ObjectId is not valid or that the Method was called on
the ConditionType Node.
See OPC 10000-4 for the general description of this result code.
Comments
Comments are added to Event occurrences identified via an EventId. EventIds where the related
EventType is not a ConditionType (or subtype of it) and thus does not support Comments are
rejected.
A ConditionEvent – where the Comment Variable contains this text – will be sent for the
identified state. If a comment is added to a previous state (i.e. a state for which the Server has
created a branch), the BranchId and all Condition values of this branch will be reported.
Table 17 specifies the AddressSpace representation for the AddComment Method.
Table 17 – AddComment Method AddressSpace definition
Attribute Value
BrowseName AddComment
References NodeClass BrowseName DataType TypeDefinition ModellingRule
HasProperty Variable InputArguments Argument[] PropertyType Mandatory
AlwaysGeneratesEvent ObjectType AuditConditionComment Defined in 5.10.4
EventType
5.5.7 ConditionRefresh Method

ConditionRefresh allows a Client to request a Refresh of all Condition instances that currently
are in an interesting state (they have the Retain flag set). This includes previous states of a
Condition instance for which the Server maintains Branches. A Client would typically invoke this
Method when it initially connects to a Server and following any situations, such as
communication disruptions, in which it would require resynchronization with the Server. This
Method is only available on the ConditionType or its subtypes. To invoke this Method, the call
shall pass the well-known MethodId of the Method on the ConditionType and the ObjectId shall
be the well-known ObjectId of the ConditionType Object.
Signature
ConditionRefresh(
[in] IntegerId SubscriptionId
);
Table 18 – ConditionRefresh parameters
SubscriptionId A valid Subscription Id of the Subscription to be refreshed. The Server shall verify that
the SubscriptionId provided is part of the Session that is invoking the Method.
Table 19 – ConditionRefresh result codes

Bad_SubscriptionIdInvalid See OPC 10000-4 for the description of this result code
Bad_RefreshInProgress See Table 103 for the description of this result code
Bad_UserAccessDenied The Method was not called in the context of the Session that owns the Subscription
Comments
Sub clause 4.5 describes the concept, use cases and information flow in more detail.
The input argument provides a Subscription identifier indicating which Client Subscription shall
be refreshed. If the Subscription is accepted the Server will react as follows:
1) The Server issues an event of RefreshStartEventType(defined in 5.11.2) marking the

start of Refresh. A copy of the instance of RefreshStartEventType is queued into the
Event stream for every Notifier MonitoredItem in the Subscription. Each of the Event
copies shall contain the same EventId.
2) The Server issues Event Notifications of any Retained Conditions and Retained
Branches of Conditions that meet the Subscriptions content filter criteria. Note that the
EventId for such a refreshed Notification shall be identical to the one for the original
Notification, the values of the other Properties are Server specific, in that some Servers
may be able to replay the exact Events with all Properties/Variables maintaining the
same values as originally sent, but other Servers might only be able to regenerate the
Event. The regenerated Event might contain some updated Property/Variable values.
For example, if the Alarm limits associated with a Variable were changed after the
generation of the Event without generating a change in the Alarm state, the new limit
might be reported. In another example, if the HighLimit was 100 and the Variable is 120.
If the limit were changed to 90 no new Event would be generated since no change to the
StateMachine, but the limit on a Refresh would indicate 90, when the original Event had
indicated 100.
3) The Server may intersperse new Event Notifications that have not been previously
issued to the Notifier along with those being sent as part of the Refresh request. Clients
shall check for multiple Event Notifications for a ConditionBranch to avoid overwriting a
new state delivered together with an older state from the Refresh process.
4) The Server issues an instance of RefreshEndEventType (defined in 5.11.3) to signal the
end of the Refresh. A copy of the instance of RefreshEndEventType is queued into the
Event stream for every Notifier MonitoredItem in the Subscription. Each of the Events
copies shall contain the same EventId.
It is important to note that if multiple Event Notifiers are in a Subscription all Event Notifiers are
processed. If a Client does not want all MonitoredItems refreshed, then the Client should place
each MonitoredItem in a separate Subscription or call ConditionRefresh2 if the Server supports
it.
If more than one Subscription is to be refreshed, then the standard call Service array processing
can be used.
As mentioned above, ConditionRefresh shall also issue Event Notifications for prior states if
they still need attention. In particular, this is True for Condition instances where previous states
still need acknowledgement or confirmation.
Table 20 specifies the AddressSpace representation for the ConditionRefresh Method.
Table 20 – ConditionRefresh Method AddressSpace definition
Attribute Value
BrowseName ConditionRefresh
AlwaysGeneratesEvent ObjectType RefreshStartEvent Defined in 5.11.2
AlwaysGeneratesEvent ObjectType RefreshEndEvent Defined in 5.11.3
5.5.8 ConditionRefresh2 Method

ConditionRefresh2 allows a Client to request a Refresh of all Condition instances that currently
are in an interesting state (they have the Retain flag set) that are associated with the given
Monitored item. In all other respects it functions as ConditionRefresh. A Client would typically
invoke this Method when it initially connects to a Server and following any situations, such as
communication disruptions where only a single MonitoredItem is to be resynchronized with the
Server. This Method is only available on the ConditionType or its subtypes. To invoke this
Method, the call shall pass the well-known MethodId of the Method on the ConditionType and
the ObjectId shall be the well-known ObjectId of the ConditionType Object.
This Method is optional and as such Clients must be prepared to handle Servers which do not
provide the Method. If the Method returns Bad_MethodInvalid, the Client shall revert to
ConditionRefresh.
Signature
ConditionRefresh2(
[in] IntegerId SubscriptionId
[in] IntegerId MonitoredItemId
);
Table 21 – ConditionRefresh2 parameters
SubscriptionId The identifier of the Subscription containing the MonitoredItem to be refreshed. The
Server shall verify that the SubscriptionId provided is part of the Session that is invoking
the Method.
MonitoredItemId The identifier of the MonitoredItem to be refreshed. The MonitoredItemId shall be in the
provided Subscription.

Table 22 – ConditionRefresh2 result codes

Bad_SubscriptionIdInvalid See OPC 10000-4 for the description of this result code
Bad_MonitoredItemIdInvalid See OPC 10000-4 for the description of this result code
Bad_RefreshInProgress See Table 103 for the description of this result code
Bad_UserAccessDenied The Method was not called in the context of the Session that owns the Subscription
Bad_MethodInvalid See OPC 10000-4 for the description of this result code
Comments
Sub clause 4.5 describes the concept, use cases and information flow in more detail.
The input argument provides a Subscription identifier and MonitoredItem identifier indicating
which MonitoredItem in the selected Client Subscription shall be refreshed. If the Subscription
and MonitoredItem is accepted the Server will react as follows:
1) The Server issues a RefreshStartEvent (defined in 5.11.2) marking the start of Refresh.
The RefreshStartEvent is queued into the Event stream for the Notifier MonitoredItem in
the Subscription.
2) The Server issues Event Notifications of any Retained Conditions and Retained
Branches of Conditions that meet the Subscriptions content filter criteria. Note that the
EventId for such a refreshed Notification shall be identical to the one for the original
Notification, the values of the other Properties are Server specific, in that some Servers
may be able to replay the exact Events with all Properties/Variables maintaining the
same values as originally sent, but other Servers might only be able to regenerate the
Event. The regenerated Event might contain some updated Property/Variable values.
For example, if the Alarm limits associated with a Variable were changed after the
generation of the Event without generating a change in the Alarm state, the new limit
might be reported. In another example, if the HighLimit was 100 and the Variable is 120.
If the limit were changed to 90 no new Event would be generated since no change to the
StateMachine, but the limit on a Refresh would indicate 90, when the original Event had
indicated 100.
3) The Server may intersperse new Event Notifications that have not been previously
issued to the notifier along with those being sent as part of the Refresh request. Clients
shall check for multiple Event Notifications for a ConditionBranch to avoid overwriting a
new state delivered together with an older state from the Refresh process.
4) The Server issues a RefreshEndEvent (defined in 5.11.3) to signal the end of the
Refresh. The RefreshEndEvent is queued into the Event stream for the Notifier
MonitoredItem in the Subscription.
If more than one MonitoredItem or Subscription is to be refreshed, then the standard call Service
array processing can be used.
As mentioned above, ConditionRefresh2 shall also issue Event Notifications for prior states if
those states still need attention. In particular, this is True for Condition instances where
previous states still need acknowledgement or confirmation.
Table 20 specifies the AddressSpace representation for the ConditionRefresh2 Method.
Table 23 – ConditionRefresh2 Method AddressSpace definition
Attribute Value
BrowseName ConditionRefresh2
AlwaysGeneratesEvent ObjectType RefreshStartEvent Defined in 5.11.2
AlwaysGeneratesEvent ObjectType RefreshEndEvent Defined in 5.11.3
5.6 Dialog Model

5.6.1 General
The Dialog Model is an extension of the Condition model used by a Server to request user input.
It provides functionality similar to the standard Message dialogs found in most operating
systems. The model can easily be customized by providing Server specific response options in
the ResponseOptionSet and by adding additional functionality to derived Condition Types.
5.6.2 DialogConditionType
The DialogConditionType is used to represent Conditions as dialogs. It is illustrated in Figure
10 and formally defined in Table 24.
ConditionType
EnableState
DialogConditionType
IsTrueSubState
TwoStateVariableType: Respond
DialogState
Prompt LastResponse
ResponseOptionSet OkResponse
DefaultResponse CancelResponse
Figure 10 - DialogConditionType Overview

Table 24 – DialogConditionType Definition
Attribute Value
BrowseName DialogConditionType
IsAbstract False
Rule
Subtype of the ConditionType defined in clause 5.5.2
HasComponent Variable DialogState LocalizedText TwoStateVariableType Mandatory
HasProperty Variable Prompt LocalizedText PropertyType Mandatory
HasProperty Variable ResponseOptionSet LocalizedText [ ] PropertyType Mandatory
HasProperty Variable DefaultResponse Int32 PropertyType Mandatory
HasProperty Variable LastResponse Int32 PropertyType Mandatory
HasProperty Variable OkResponse Int32 PropertyType Mandatory
HasProperty Variable CancelResponse Int32 PropertyType Mandatory
HasComponent Method Respond Defined in Clause 5.6.3. Mandatory
The DialogConditionType inherits all Properties of the ConditionType.
DialogState/Id when set to True indicates that the Dialog is active and waiting for a response.
Recommended state names are described in Annex A.
Prompt is a dialog prompt to be shown to the user.
ResponseOptionSet specifies the desired set of responses as array of LocalizedText. The index
in this array is used for the corresponding fields like DefaultResponse, LastResponse and
SelectedOption in the Respond Method. The recommended localized names for the common
options are described in Annex A.
Typical combinations of response options are

 OK
 OK, Cancel
 Yes, No, Cancel
 Abort, Retry, Ignore
 Retry, Cancel
 Yes, No
DefaultResponse identifies the response option that should be shown as default to the user. It
is the index in the ResponseOptionSet array. If no response option is the default, the value of
the Property is -1.
LastResponse contains the last response provided by a Client in the Respond Method. If no
previous response exists, then the value of the Property is -1.
OkResponse provides the index of the OK option in the ResponseOptionSet array. This choice
is the response that will allow the system to proceed with the operation described by the prompt.
This allows a Client to identify the OK option if a special handling for this option is available. If
no OK option is available, the value of this Property is -1.
CancelResponse provides the index of the response in the ResponseOptionSet array that will
cause the Dialog to go into the inactive state without proceeding with the operation described
by the prompt. This allows a Client to identify the Cancel option if a special handling for this
option is available. If no Cancel option is available , the value of this Property is -1.
5.6.3 Respond Method

Respond is used to pass the selected response option and end the dialog. DialogState/Id will
return to False.
Signature
Respond(
[in] Int32 SelectedResponse
);
Table 25 – Respond parameters
SelectedResponse Selected index of the ResponseOptionSet array.
Table 26 – Respond Result Codes

Bad_DialogNotActive See Table 103 for the description of this result code.
Bad_DialogResponseInvalid See Table 103 for the description of this result code.
Table 27 specifies the AddressSpace representation for the Respond Method.
Table 27 – Respond Method AddressSpace definition
Attribute Value
BrowseName Respond
AlwaysGeneratesEvent ObjectType AuditConditionRespondEventType Defined in 5.10.5
5.7 Acknowledgeable Condition Model

5.7.1 General
The Acknowledgeable Condition Model extends the Condition model. States for
acknowledgement and confirmation are added to the Condition model.
AcknowledgeableConditions are represented by the AcknowledgeableConditionType which is a

subtype of the ConditionType. The model is formally defined in the following sub clauses.
5.7.2 AcknowledgeableConditionType
The AcknowledgeableConditionType extends the ConditionType by defining acknowledgement
characteristics. It is an abstract type. The AcknowledgeableConditionType is illustrated in
Figure 11 and formally defined in Table 28.
ConditionType
EnableState
Acknowledgeable
ConditionType
HasTrueSubState TwoStateVariableType:
AckedState Acknowledge
ConfirmedState
Confirm
Figure 11 – AcknowledgeableConditionType overview
Table 28 – AcknowledgeableConditionType definition
Attribute Value
BrowseName AcknowledgeableConditionType
IsAbstract False
Rule
Subtype of the ConditionType defined in clause 5.5.2.
HasSubtype ObjectType AlarmConditionType Defined in Clause 5.8.2
HasComponent Variable AckedState LocalizedText TwoStateVariableType Mandatory

HasComponent Variable ConfirmedState LocalizedText TwoStateVariableType Optional
HasComponent Method Acknowledge Defined in Clause 5.7.3 Mandatory

HasComponent Method Confirm Defined in Clause 5.7.4 Optional
The AcknowledgeableConditionType inherits all Properties of the ConditionType.
AckedState when False indicates that the Condition instance requires acknowledgement for the
reported Condition state. When the Condition instance is acknowledged the AckedState is set
to True. ConfirmedState indicates whether it requires confirmation. Recommended state names
are described in Annex A. The two states are sub-states of the True EnabledState. See 4.3 for
more information about acknowledgement and confirmation models. The EventId used in the
Event Notification is considered the identifier of this state and has to be used when calling the
Methods for acknowledgement or confirmation.
A Server may require that previous states be acknowled ged. If the acknowledgement of a
previous state is still open and a new state also requires acknowledgement, the Server shall
create a branch of the Condition instance as specified in 4.4. Clients are expected to keep track
of all ConditionBranches where AckedState/Id is False to allow acknowledgement of those. See
also 5.5.2 for more information about ConditionBranches and the examples in Clause B.1. The
handling of the AckedState and branches also applies to the ConfirmedState.
5.7.3 Acknowledge Method

The Acknowledge Method is used to acknowledge an Event Notification for a Condition instance
state where AckedState is False. Normally, the NodeId of the object instance is passed as the
ObjectId to the Call Service. However, some Servers do not expose Condition instances in the
AddressSpace. Therefore, Servers shall allow Clients to call the Acknowledge Method by
specifying ConditionId as the ObjectId. The Method cannot be called with an ObjectId of the
AcknowledgeableConditionType Node.
Signature
Acknowledge(
);
Table 29 – Acknowledge parameters
EventId EventId identifying a particular Event Notification.
Only Event Notifications where AckedState/Id was False can be acknowledged.
Comment A localized text to be applied to the Condition.
Table 30 – Acknowledge result codes

Bad_ConditionBranchAlreadyAcked See Table 103 for the description of this result code.
Bad_MethodInvalid The method id does not refer to a method for the specified object or
ConditionId.
Bad_NodeIdInvalid Used to indicate that the specified ObjectId is not valid or that the Method was
called on the ConditionType Node. See OPC 10000-4 for the general
description of this result code.
Comments
A Server is responsible to ensure that each Event has a unique EventId. This allows Clients to
identify and acknowledge a particular Event Notification.
The EventId identifies a specific Event Notification where a state to be acknowledged was
reported. Acknowledgement and the optional comment will be applied to the state identified with
the EventId. If the comment field is NULL (both locale and text are empty) it will be ignored and
any existing comments will remain unchanged. If the comment is to be reset, an empty text with
a locale shall be provided.
A valid EventId will result in an Event Notification where AckedState/Id is set to True and the
Comment Property contains the text of the optional comment argument. If a previous state is
acknowledged, the BranchId and all Condition values of this branch will be reported. Table 31
specifies the AddressSpace representation for the Acknowledge Method.
Table 31 – Acknowledge Method AddressSpace definition
Attribute Value
BrowseName Acknowledge
AlwaysGenerates ObjectType AuditConditionAcknowledge Defined in 5.10.5
Event EventType
5.7.4 Confirm Method

The Confirm Method is used to confirm an Event Notifications for a Condition instance state
where ConfirmedState is False. Normally, the NodeId of the object instance is passed as the
ObjectId to the Call Service. However, some Servers do not expose Condition instances in the
AddressSpace. Therefore, Servers shall allow Clients to call the Confirm Method by specifying
ConditionId as the ObjectId. The Method cannot be called with an ObjectId of the
AcknowledgeableConditionType Node.
Signature
Confirm(
);
Table 32 – Confirm Method parameters
EventId EventId identifying a particular Event Notification.
Only Event Notifications where the Id property of the ConfirmedState is False can be
confirmed.
Comment A localized text to be applied to the Conditions.
Table 33 – Confirm result codes

Bad_ConditionBranchAlreadyConfirmed See Table 103 for the description of this result code.
Bad_MethodInvalid The method id does not refer to a method for the specified object or
ConditionId.
Bad_NodeIdUnknown Used to indicate that the specified ObjectId is not valid or that the Method
was called on the ConditionType Node.
Comments
A Server is responsible to ensure that each Event has a unique EventId. This allows Clients to
identify and confirm a particular Event Notification.
The EventId identifies a specific Event Notification where a state to be confirmed was reported.
A Comment can be provided which will be applied to the state identified with the EventId.
A valid EventId will result in an Event Notification where ConfirmedState/Id is set to True and
the Comment Property contains the text of the optional comment argument. If a previous state
is confirmed, the BranchId and all Condition values of this branch will be reported. A Client can
confirm only events that have a ConfirmedState/Id set to False. The logic for setting
ConfirmedState/Id to False is Server specific and may even be event or condition specific.
Table 34 specifies the AddressSpace representation for the Confirm Method.

Table 34 – Confirm Method AddressSpace definition
Attribute Value
BrowseName Confirm
AlwaysGenerates ObjectType AuditConditionConfirmEventType Defined in 5.10.7
Event
5.8 Alarm model

5.8.1 General
Figure 12 informally describes the AlarmConditionType, its sub -types and where it is in the
hierarchy of Event Types.
ConditionType
AcknowledgeableConditionType
AlarmConditionType
Discrepancy LimitAlarmType DiscreteAlarmType

AlarmType
OffNormalAlarmType
ExclusiveLimit NonExclusiveLimit
AlarmType AlarmType
SystemOffNormalAlarmType
Exclusive Exclusive Exclusive NonExclusive NonExclusive NonExclusive

Level MultiDeviation RateOfChange Level MultiDeviation RateOfChange
Figure 12 - AlarmConditionType Hierarchy Model

5.8.2 AlarmConditionType
The AlarmConditionType is an abstract type that extends the AcknowledgeableConditionType
by introducing an ActiveState, SuppressedState and ShelvingState. It also adds the ability to
set a delay time, re-alarm time, Alarm groups and audible Alarm settings The Alarm model is
illustrated in Figure 13. This illustration is not intended to be a complete definitio n. It is formally
defined in Table 35.
ConditionType
EnableState
Acknowledgeable
ConditionType
AlarmCondition
IsTrueSubState Type
ActiveState InputNode
SuppressedOrShelved
SuppressedState
TwoStateVariableType: MaxTimeShelved
OutOfServiceState
AudibleEnable
SilenceState AudibleSound
LatchedState ReAlarmTime
OnDelay
RepeatCount
OffDelay
FirstInGroup
ReAlarmRepeatCount
FirstInGroupFlag
Silence
<AlarmGroup>
Reset
OutOfService
Suppress
StateMachineType:
ShelvingState
CurrentState
Figure 13 – Alarm Model
Table 35 – AlarmConditionType definition
Attribute Value
BrowseName AlarmConditionType
IsAbstract False
References Node BrowseName DataType TypeDefinition Modelling
Class 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 AudioDataTyp AudioVariableType Optional
e
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 Object LatchedState LocalizedText TwoStateVariableType Optional
HasAlarmSuppre Object <AlarmGroup> AlarmGroupType OptionalPla

ssionGroup ceholder
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 Object DiscreteAlarmType

HasSubtype Object LimitAlarmType
HasSubtype Object DiscrepancyAlarmType
The AlarmConditionType inherits all Properties of the AcknowledgeableConditionType. The

following states are sub-states of the True EnabledState.
ActiveState/Id when set to True indicates that the situation the Condition is representing
currently exists. When a Condition instance is in the inactive state ( ActiveState/Id when set to
False) it is representing a situation that has returned to a normal state. The transitions of
Conditions to the inactive and Active states are triggered by Server specific actions. Subtypes
of the AlarmConditionType specified later in this document will have sub -state models that
further define the Active state. Recommended state names are described in Annex A.
The InputNode Property provides the NodeId of the Variable the Value of which is used as
primary input in the calculation of the Alarm state. If this Variable is not in the AddressSpace,
a NULL NodeId shall be provided. In some systems, an Alarm may be calculated based on
multiple Variables Values; it is up to the system to determine which Variable’s NodeId is used.
SuppressedState, OutOfServiceState and ShelvingState together allow the suppression of

Alarms on display systems. These three suppressions are generally used by different personnel
or systems at a plant, i.e. automatic systems, maintenance personnel and Operators.
SuppressedState is used internally by a Server to automatically suppress Alarms due to system

specific reasons. For example, a system may be configured to suppress Alarms that are
associated with machinery that is in a state such as shutdown. For example, a low level Alarm
for a tank that is currently not in use might be suppressed. Recommended state names are
described in Annex A.
OutOfServiceState is used by maintenance personnel to suppress Alarms due 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.
ShelvingState suggests whether an Alarm shall (temporarily) be prevented from being displayed
to the user. It is quite often used by Operators to block nuisance Alarms. The ShelvingState is
defined in 5.8.10.
When an Alarm has any or all of the SuppressedState, OutOfServiceState or ShelvingState set
to True, the SuppressedOrShelved property shall be set True and this Alarm is then typically
not displayed by the Client. State transitions associated with the Alarm do occur, but they are
not typically displayed by the Clients as long as the Alarm remains in any of the
SuppressedState, OutOfServiceState or Shelved state.
The optional Property MaxTimeShelved is used to set the maximum time that an Alarm
Condition may be shelved. The value is expressed as duration. Systems can use this Property
to prevent permanent Shelving of an Alarm. If this Property is present it will be an upper limit
on the duration passed into a TimedShelve Method call. If a value that exceeds the value of
this Property is passed to the TimedShelve Method, then a Bad_ShelvingTimeOutOfRange error
code is returned on the call. If this Property is present it will also be enforced for the
OneShotShelved state, in that an Alarm Condition will transition to the Unshelved state from
the OneShotShelved state if the duration specified in this Property expires following a
OneShotShelve operation without a change of any of the other items associated with the
Condition.
The optional Property AudibleEnabled is a Boolean that indicates if the current state of this
Alarm includes an audible Alarm.
The optional Property AudibleSound contains the sound file that is to be played if an audible
Alarm is to be generated. This file would be play/generated as long as the Alarm is active and
unacknowledged, unless the silence StateMachine is included, in which case it may also be
silenced by this StateMachine.
The SilenceState is used to suppress the generation of audible Alarms. Typically, it is used
when an Operator silences all Alarms on a screen, but needs to acknowledge the Alarms
individually. Silencing an Alarm shall silence the Alarm on all systems (screens) that it is being
reported on. Not all Clients will make use of this StateMachine, but it allows multiple Clients to
synchronize audible Alarm states. Acknowledging an Alarm shall automatically silence an
Alarm.
The OnDelay and OffDelay Properties can be used to eliminate nuisance Alarms. The OnDelay
is used to avoid unnecessary Alarms when a signal temporarily overshoots its setpoint, thus
preventing the Alarm from being triggered until the signal remains in the Alarm state
continuously for a specified length of time (OnDelay time). The OffDelay is used to reduce
chattering Alarms by locking the Alarm indication for a certain holding period after the condition
has returned to normal. I.e. the Alarm shall stay active for the OffDelay time and shall not
regenerate if it returns to active in that period. If the Alarm remains in the inactive zone for
OffDelay it will then become inactive.
The optional variable FirstInGroupFlag is used together with the FirstInGroup object. The
FirstInGroup Object is an instance of an AlarmGroupType that groups a number of related
Alarms. The FirstInGroupFlag is set on the Alarm instance that was the first Alarm to trigger in
a FirstInGroup. If this variable is present, then the FirstInGroup shall also be present. These
two nodes allow an alarming system to determine which Alarm in the list was the trigger. It is
commonly used in situations where Alarms are interrelated and usually multiple Alarms occur.
For example, vibration sensors in a turbine, usually all senso rs trigger if any one triggers, but
what is important for an Operator is the first sensor that triggered.
The LatchedState Object, if present, indicates that this Alarm supports being latched. The Alarm
will 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 Alarm and is ignored and an error of
Bad_InvalidState is return on the call. The Object indicates the current state, latched or not
latched. Recommended state names are described in Annex A. If this Object is provided the
Reset Method must also be provided.
An Alarm instance may contain HasAlarmSuppressionGroup reference(s) to instance(s) of

AlarmGroupType. Each instance is an AlarmSuppressionGroup. When an
AlarmSuppressionGroup goes active, the Server shall set the SuppressedState of the Alarm to
True. When all of referenced AlarmSuppressionGroups are no longer active, then the Server
shall set SuppressedState to False. A single AlarmSuppressionGroup can be assigned to
multiple Alarms. AlarmSuppressionGroups are used to control Alarm floods and to help manage
Alarms.
ReAlarmTime if present sets a time that is used to bring an Alarm back to the top of an Alarm
list. If an Alarm has not returned to normal within the provided time (from when it last was
alarmed), the Server will generate a new Alarm for 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 Alarm active time is set to the time of the re-alarm.
ReAlarmRepeatCount if present counts the number times an Alarm was 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 Alarm returns to
normal.
Silence Method can be used to silence an instance of an Alarm. It is defined in 5.8.5.
Suppress Method can be used to suppress an instance of an Alarm. Most Alarm suppression
occurs via advanced alarming, but this method allows additional access to suppress a particular
Alarm instance. Additional details are provided in the definition in 5.8.6.
Unsuppress Method can be used to remove an instance of an Alarm from SuppressedState.

Additional details are provided in the definition in 5.8.7.
PlaceInService Method can be used to remove an instance of an Alarm from OutOfServiceState.

It is defined in 5.8.9.
RemoveFromService Method can be used to place an instance of an Alarm in

OutOfServiceState. It is defined in 5.8.8.
Reset Method is used to clear a latched Alarm. It is defined in 5.8.4. If this Object is provided
the LatchedState Object shall also be provided.
More details about the Alarm Model and the various states can be found in Sub clause 4.8. and
in Annex E.
5.8.3 AlarmGroupType
The AlarmGroupType provides a simple manner of grouping Alarms. This grouping can be used
for Alarm suppression or for identif ying related Alarms. The actual usage of the
AlarmGroupType is specified where it is used.
Table 36 – AlarmGroupType Definition
Attribute Value
BrowseName AlarmGroupType
IsAbstract False
Rule
Subtype `of the FolderType defined in OPC 10000-5
AlarmGroupMember Object <AlarmConditionInstance> AlarmConditionType OptionalPla
ceholder
The instance of an AlarmGroupType should be given a name and description that describes the
purpose of the Alarm group.
The AlarmGroupType instance will contain a list of instances of AlarmConditionType or sub type
of AlarmConditionType referenced by AlarmGroupMember references. At least one Alarm must
be present in an instance of an AlarmGroupType.
5.8.4 Reset Method

The Reset Method is used reset a latched Alarm instance. It is only available on an instance of
an AlarmConditionType that exposes the LatchedState. Normally, the NodeId of the Object
instance is passed as the ObjectId to the Call Service. However, some Servers do not expose
Condition instances in the AddressSpace. Therefore, Servers shall allow Clients to call the
Reset Method by specifying ConditionId as the ObjectId. The Method cannot be called with an
ObjectId of the AlarmConditionType Node.
Signature
Reset();
Table 37 – Reset arguments
Method result codes in Table 41 (defined in Call service)
Table 38 – Silence result codes

Bad_InvalidState The Alarm instance was not latched or still active or still required acknowledgement.
For an Alarm Instance to be reset it must have been in Alarm, and returned to normal
and have been acknowledged prior to being reset.
Table 42 specifies the AddressSpace representation for the Reset Method.
Table 39 – Reset Method AddressSpace definition
Attribute Value
BrowseName Reset
AlwaysGenerates Ob jectType AuditConditionRes Defined in 5.10.11

Event etEventType
5.8.5 Silence Method

The Silence Method is used silence a specific Alarm instance. It is only available on an instance
of an AlarmConditionType that also exposes the SilenceState. Normally, the NodeId of the
Object instance is passed as the ObjectId to the Call Service. However, some Servers do not
expose Condition instances in the AddressSpace. Therefore, Servers shall allow Clients to call
the Silence Method by specifying ConditionId as the ObjectId. The Method cannot be called
with an ObjectId of the AlarmConditionType Node.
Signature
Silence();

Table 40 – Silence arguments
Method result codes in Table 41 (defined in Call service)
Table 41 – Silence result codes

Comments
If the instance is not currently in an audible state, the command is ignored.
Table 42 specifies the AddressSpace representation for the Silence Method.
Table 42 – Silence Method AddressSpace definition
Attribute Value
BrowseName Silence
Rule
AlwaysGeneratesEvent ObjectType AuditConditionSilenceEventType Defined in 5.10.10
5.8.6 Suppress Method

The Suppress Method is used to suppress a specific Alarm instance. It is only available on an
instance of an AlarmConditionType that also exposes the SuppressedState. This Method can
be used to change the SuppressedState of an Alarm and overwrite any suppression caused by
an associated AlarmSuppressionGroup. This Method works in parallel with any suppression
triggered by an AlarmSupressionGroup, in that if the Method is used to suppress an Alarm, an
AlarmSuppressionGroup might clear the suppression.
Normally, the NodeId of the object instance is passed as the ObjectId to the Call Service.
However, some Servers do not expose Condition instances in the AddressSpace. Therefore,
Servers shall allow Clients to call the Suppress Method by specifying ConditionId as the
ObjectId. The Method cannot be called with an ObjectId of the AlarmConditionType Node.
Signature
Suppress();
Table 43 – Suppress result codes

Comments
Suppress Method applies to an Alarm instance, even if it is not currently active.

Table 44 specifies the AddressSpace representation for the Suppress Method.
Table 44 – Suppress Method AddressSpace definition
Attribute Value
BrowseName Suppress
Rule
AlwaysGeneratesEvent ObjectType AuditConditionSuppressionEvent Defined in 5.10.4

Type
5.8.7 Unsuppress Method

The Unsuppress Method is used to clear the SuppressedState of a specific Alarm instance. It
is only available on an instance of an AlarmConditionType that also exposes the
SuppressedState. This Method can be used to overwrite any suppression cause by an
associated AlarmSuppressionGroup. This Method works in parallel with any suppression
triggered by an AlarmSuppressionGroup, in that if the Method is used to clear the
SuppressedState of an Alarm, any change in an AlarmSuppressionGroup might again suppress
the Alarm.
Normally, the NodeId of the ObjectInstance is passed as the ObjectId to the Call Service.
Servers shall allow Clients to call the Unsuppress Method by specifying ConditionId as the
ObjectId. The Method cannot be called with an ObjectId of the AlarmConditionType Node.
Signature
Unsuppress();
Table 45 – Unsuppress result codes

Comments
Unsuppress Method applies to an Alarm instance, even if it is not currently active.
Table 44 specifies the AddressSpace representation for the Suppress Method.
Table 46 – Unsuppress Method AddressSpace definition
Attribute Value
BrowseName Unsuppress
Rule
AlwaysGeneratesEvent ObjectType AuditConditionSuppressionEventType Defined in 5.10.4
5.8.8 RemoveFromService Method

The RemoveFromService Method is used to suppress a specific Alarm instance. It is only
available on an instance of an AlarmConditionType that also exposes the OutOfServiceState.
Normally, the NodeId of the object instance is passed as the ObjectId to the Call Service.
Servers shall allow Clients to call the RemoveFromService Method by specifying ConditionId
as the ObjectId. The Method cannot be called with an ObjectId of the AlarmConditionType Node.
Signature
RemoveFromService ();
Table 47 – RemoveFromService result codes

Comments
Instances that do not expose the OutOfService State shall reject RemoveFromService calls.
RemoveFromService Method applies to an Alarm instance, even if it is not currently in the Active
State.
Table 48 specifies the AddressSpace representation for the RemoveFromService Method.
Table 48 – RemoveFromService Method AddressSpace definition
Attribute Value
BrowseName RemoveFromService
Rule
AlwaysGeneratesEvent ObjectType AuditConditionOutOfServiceEventType Defined in 5.10.12
5.8.9 PlaceInService Method

The PlaceInService Method is used to set the OutOfServiceState to False of a specific Alarm
instance. It is only available on an instance of an AlarmConditionType that also exposes the
OutOfServiceState. Normally, the NodeId of the ObjectInstance is passed as the ObjectId to
the Call Service. However, some Servers do not expose Condition instances in the
AddressSpace. Therefore, Servers shall allow Clients to call the PlaceInService Method by
specifying ConditionId as the ObjectId. The Method cannot be called with an ObjectId of the
AlarmConditionType Node.
Signature
PlaceInService ();
Table 49 – PlaceInService result codes

Comments
The PlaceInService Method applies to an Alarm instance, even if it is not currently in the Active
State.
Table 48 specifies the AddressSpace representation for the PlaceInService Method.
Table 50 – PlaceInService Method AddressSpace definition
Attribute Value
BrowseName PlaceInService
AlwaysGeneratesEvent ObjectType AuditConditionOutOfService Defined in 5.10.12

EventType
5.8.10 ShelvedStateMachineType
5.8.10.1 Overview
The ShelvedStateMachineType defines 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: OneShotShelving and TimedShelving. They
are illustrated in Figure 14. The illustration includes the allowed transitions between the various
sub-states. Shelving is an Operator initiated activity.
In OneShotShelving, a user requests that an Alarm be Shelved for its current Active state. This
type of Shelving is typically used when an Alarm is continually occurring on a boundary (i.e. a
Condition is jumping between High Alarm and HighHigh Alarm, always in the Active state). The
One Shot Shelving will automatically clear when an Alarm returns to an inactive state. Another
use for this type of Shelving is for a plant area that is shutdown i.e. a long running Alarm such
as a low level Alarm for a tank that is not in use. When the tank starts operation again the
Shelving state will automatically clear.
In TimedShelving, a user specifies that an Alarm be shelved for a fixed time period. This type
of Shelving is quite often used to block nuisance Alarms. For example, an Alarm that occurs
more than 10 times in a minute may get shelved for a few minutes.
In all states, the Unshelve can be called to cause a transition to the Unshelve state; this includes
Un-shelving an Alarm that is in the TimedShelve state before the time has expired and the
OneShotShelve state without a transition to an inactive state.
All but two transitions are caused by Method calls 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 Condition goes to an inactive
state.
Unshelved
Any Transition Occurs

Timed Shelve call
UnShelve call
UnShelve call
Time Expired One Shot Shelve call
Timed Oneshot
Shelved One Shot Shelve call Shelved
Timed Shelve call
Figure 14 – Shelve state transitions
The ShelvedStateMachineType includes a hierarchy of sub-states. It supports all transitions

between Unshelved, OneShotShelved and TimedShelved.
The state machine is illustrated in Figure 15 and formally defined in Table 51.
FiniteStateMachineType
StateType
TransitionType
ShelvedStateMachine
Type
UnshelveTime Unshelve
TimedShelvedToUnshelved
Unshelved HasCause
OneShotShelvedToUnShelved
TimedShelved
HasCause
OneShotShelved
UnShelvedToTimedShelved TimedShelvedToOneShotShelved
HasCause
HasCause
OneShotShelvedToTimedShelved
UnShelvedToOneShotShelved
HasCause
HasCause
TimedShelve OneShotShelve
Figure 15 – ShelvedStateMachineType model
Table 51 –ShelvedStateMachineType definition
Attribute Value
BrowseName ShelvedStateMachineType
IsAbstract False
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
UnshelveTime specifies the remaining time in milliseconds until the Alarm automatically
transitions into the Un-shelved state. For the TimedShelved state this time is initialised with the
ShelvingTime argument of the TimedShelve Method call. For the OneShotShelved state the
UnshelveTime will be a constant set to the maximum Duration except if a MaxTimeShelved
Property is provided.
This FiniteStateMachine supports three Active states; Unshelved, TimedShelved and

OneShotShelved. It also supports six transitions. The states and transitions are described in
Table 52. This FiniteStateMachine also supports three Methods; TimedShelve, OneShotShelve
and 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
HasCause OneShotShelve Method
TimedShelvedToUnshelved FromState TimedShelved StateType
ToState Unshelved StateType
TimedShelvedToOneShotShelved FromState TimedShelved StateType
ToState OneShotShelved StateType
HasCause OneShotShelving Method
OneShotShelvedToUnshelved FromState OneShotShelved StateType
ToState Unshelved StateType
OneShotShelvedToTimedShelved FromState OneShotShelved StateType
ToState TimedShelved StateType
HasCause TimedShelve Method
5.8.10.2 Unshelve Method

The Unshelve Method sets the instance of AlarmConditionType to the Unshelved state.
Normally, the MethodId found in the Shelving child of the Condition instance and the NodeId of
the Shelving object as the ObjectId are passed to the Call Service. However, some Servers do
not expose Condition instances in the AddressSpace. Therefore, all Servers shall also allow
Clients to call the Unshelve Method by specifying ConditionId as the ObjectId. The Method
cannot be called with an ObjectId of the ShelvedStateMachineType Node.
Signature
Unshelve( );
Table 53 – Unshelve result codes

Bad_ConditionNotShelved See Table 103 for the description of this result code.
Table 54 specifies the AddressSpace representation for the Unshelve Method.
Table 54 – Unshelve Method AddressSpace definition
Attribute Value
BrowseName Unshelve
AlwaysGeneratesEvent ObjectType AuditConditionShelvingEventType Defined in 5.10.7
5.8.10.3 TimedShelve Method

The TimedShelve Method sets the instance of AlarmConditionType to the TimedShelved state
(parameters are defined in Table 55 and result codes are described in Table 56). Normally, the
MethodId found in the Shelving child of the Condition instance and the NodeId of the Shelving
object as the ObjectId are passed to the Call Service. However, some Servers do not expose
Condition instances in the AddressSpace. Therefore, all Servers shall also allow Clients to call
the TimedShelve Method by specifying ConditionId as the ObjectId. The Method cannot be
called with an ObjectId of the ShelvedStateMachineType Node.
Signature
TimedShelve(
[in] Duration ShelvingTime
);
Table 55 – TimedShelve parameters
ShelvingTime Specifies a fixed time for which the Alarm is to be shelved. The Server may refuse the
provided duration. If a MaxTimeShelved Property exist on the Alarm than the Shelving
time shall be less than or equal to the value of this Property.
Method Result Codes (defined in Call Service)
Table 56 – TimedShelve result codes

Bad_ConditionAlreadyShelved See Table 103 for the description of this result code.
The Alarm is already in TimedShelved state and the system does not allow a reset of the
shelved timer.
Bad_ShelvingTimeOutOfRange See Table 103 for the description of this result code.
Comments
Shelving for some time is quite often used to block nuisance Alarms. For example, an Alarm
that 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 Server may
generate an error refusing the provided duration. Th is limit may be exposed as the
MaxTimeShelved Property.
Table 57 specifies the AddressSpace representation for the TimedShelve Method.
Table 57 – TimedShelve Method AddressSpace definition
Attribute Value
BrowseName TimedShelve
5.8.10.4 OneShotShelve Method

The OneShotShelve Method sets the instance of AlarmConditionType to the OneShotShelved
state. Normally, the MethodId found in the Shelving child of the Condition instance and the
NodeId of the Shelving object as the ObjectId are passed to the Call Service. However, some
also allow Clients to call the OneShotShelve Method by specifying ConditionId as the ObjectId.
The Method cannot be called with an ObjectId of the ShelvedStateMachineType Node.
Signature
OneShotShelve( );
Method Result Codes are defined in Table 58 (status code field is defined in Call Service)
Table 58 – OneShotShelve result codes

Bad_ConditionAlreadyShelved See Table 103 for the description of this result code.
The Alarm is already in OneShotShelved state.
Table 59 specifies the AddressSpace representation for the OneShotShelve Method.
Table 59 – OneShotShelve Method AddressSpace definition
Attribute Value
BrowseName OneShotShelve
5.8.11 LimitAlarmType
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 an abstract type used to provide a base Type for AlarmConditionTypes
with multiple limits. The LimitAlarmType is illustrated in Figure 16.
AlarmConditionType
LimitAlarmType
BaseLowLimit LowLimit
BaseLowLowLimit LowLowLimit
BaseHighLimit HighLimit
BaseHighHighLimit HighHighLimit
ExclusiveLimit NonExclusiveLimit
AlarmType AlarmType
Figure 16 – LimitAlarmType
The LimitAlarmType is formally defined in Table 60.

Table 60 – LimitAlarmType definition
Attribute Value
BrowseName LimitAlarmType
IsAbstract False
Rule
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 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 AdaptiveSAlarming. 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. T he 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.
5.8.12 Exclusive Limit Types

5.8.12.1 Overview
This clause describes the state machine and the base Alarm Type behaviour for
AlarmConditionTypes with multiple mutually exclusive limits.
5.8.12.2 ExclusiveLimitStateMachineType
The ExclusiveLimitStateMachineType defines the state machine used by AlarmConditionTypes
that handle multiple mutually exclusive limits. It is illustrated in Figure 17.
StateType
TransitionType
ExclusiveLimit
StateMachineType
HighHigh HighToHighHigh
High HighHighToHigh
Low LowToLowLow
LowLow LowLowToLow
Figure 17 – ExclusiveLimitStateMachineType
It is created by extending the FiniteStateMachineType. It is formally defined in Table 61 and

the state transitions are described in Table 62.
Table 61 – ExclusiveLimitStateMachineType definition
Attribute Value
BrowseName ExclusiveLimitStateMachineType
IsAbstract False
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
Transitions
HighHighToHigh FromState HighHigh StateType
ToState High StateType
HighToHighHigh FromState High StateType
ToState HighHigh StateType
LowLowToLow FromState LowLow StateType
ToState Low StateType
LowToLowLow FromState Low StateType
ToState LowLow StateType
The ExclusiveLimitStateMachineType defines the sub state machine that represents the actual
level of a multilevel Alarm when it is in the Active state. The sub state machine defined here
includes High, Low, HighHigh and LowLow states. 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 Active state.
This Active state could be part of a “level” Alarm or “deviation” Alarm or any other Alarm state
machine.
The LowLow, Low, High, HighHigh are 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 AvailableStates and/or AvailableTransitions (see OPC 10000-5).
5.8.12.3 ExclusiveLimitAlarmType
The ExclusiveLimitAlarmType is used to specify the common behaviour for Alarm Types with
multiple mutually exclusive limits. The ExclusiveLimitAlarmType is illustrated in Figure 18.
EnableState ConditionType
Acknowledgeable
IsTrueSubState
ConditionType
ActiveState AlarmConditionType
LowLimit
LowLowLimit
LimitAlarmType
HighLimit
IsTrueSubState
HighHighLimit
ExclusiveLimit
AlarmType
ExclusiveLimitStateMachineType:
LimitState
CurrentState
ExclusiveLevel ExclusiveDeviation ExclusiveRateOfChange

AlarmType AlarmType AlarmType
Figure 18 – ExclusiveLimitAlarmType
The ExclusiveLimitAlarmType is formally defined in Table 63.

Table 63 – ExclusiveLimitAlarmType definition
Attribute Value
BrowseName ExclusiveLimitAlarmType
IsAbstract False
Rule
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
Type
HasSubtype ObjectType ExclusiveRateOfChangeAlarm Defined in Clause 5.8.16.3
Type
HasComponent Object LimitState ExclusiveLimitStateMachineType Mandatory
The LimitState is a sub state of the ActiveState and has an IsTrueSubStateOf reference to the
ActiveState. The LimitState represents the actual limit that is violated in an instance of
ExclusiveLimitAlarmType. When the ActiveState of the AlarmConditionType is inactive the
LimitState shall not be available and shall return NULL on read. Any Events that subscribe for
fields from the LimitState when the ActiveState is inactive shall return a NULL for these
unavailable fields.
5.8.13 NonExclusiveLimitAlarmType
The NonExclusiveLimitAlarmType is used to specify the common behaviour for Alarm Types
with multiple non-exclusive limits. The NonExclusiveLimitAlarmType is illustrated in Figure 19.
EnableState ConditionType
IsTrueSubState
Acknowledgeable
ConditionType
ActiveState AlarmConditionType
LowLimit
LowLowLimit
LimitAlarmType
HighLimit
HighHighLimit
IsTrueSubState
NonExclusiveLimit
AlarmType
HighHighState
HighState
LowState
LowLowState
NonExclusiveLevel NonExclusiveDeviation NonExclusiveRateOfChange

AlarmType AlarmType AlarmType
Figure 19 – NonExclusiveLimitAlarmType
The NonExclusiveLimitAlarmType is formally defined in Table 64.

Table 64 – NonExclusiveLimitAlarmType definition
Attribute Value
BrowseName NonExclusiveLimitAlarmType
IsAbstract False
Rule
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 NonExclusiveRateOfChangeAlarm Defined in Clause 5.8.16.2
Type
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 LowLowState represent 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 HighState or the
LowState shall be provided even though all states are optional. It is implied by the definition of
a HighState and a LowState, that these groupings are mutually exclusive. A value cannot
exceed both a HighState value and a LowState value simultaneously.
5.8.14 Level Alarm

5.8.14.1 Overview
A level Alarm is commonly used to report when a limit is exceeded. It typically relates to an
instrument – e.g. a temperature meter. The level Alarm becomes active when the observed
value is above a high limit or below a low limit.
5.8.14.2 NonExclusiveLevelAlarmType
The NonExclusiveLevelAlarmType is a special level Alarm utilized 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 NonExclusiveLevelAlarmType should be used.
The NonExclusiveLevelAlarmType is based on the NonExclusiveLimitAlarmType. It is formally

Table 65 – NonExclusiveLevelAlarmType definition
Attribute Value
BrowseName NonExclusiveLevelAlarmType
IsAbstract False
Subtype of the NonExclusiveLimitAlarmType defined in clause 5.8.13.
No additional Properties to the NonExclusiveLimitAlarmType are defined.
5.8.14.3 ExclusiveLevelAlarmType
The ExclusiveLevelAlarmType is a special level Alarm utilized with multiple mutually exclusive
limits. It is formally defined in Table 66.
Table 66 – ExclusiveLevelAlarmType definition
Attribute Value
BrowseName ExclusiveLevelAlarmType
IsAbstract False
Inherits the Properties of the ExclusiveLimitAlarmType defined in clause 5.8.12.3.
No additional Properties to the ExclusiveLimitAlarmType are defined.
5.8.15 Deviation Alarm

5.8.15.1 Overview
A deviation Alarm is 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 Alarm becomes
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 Alarm limit of 2 and a low deviation
Alarm limit of -1 then the low sub state is entered if the process value drop s 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 Operator or it can be adjusted by an algorithm, the actual
functionality exposed by the set point is application specific. The deviation Alarm can 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
SetpointNode would point to the secondary source.
5.8.15.2 NonExclusiveDeviationAlarmType
The NonExclusiveDeviationAlarmType is a special level Alarm utilized 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 NonExclusiveDeviationAlarmType should be used.
The NonExclusiveDeviationAlarmType is based on the NonExclusiveLimitAlarmType. It is

Table 67 – NonExclusiveDeviationAlarmType definition
Attribute Value
BrowseName NonExclusiveDeviationAlarmType
IsAbstract False
HasProperty Variable SetpointNode NodeId PropertyType Mandatory
HasProperty Variable BaseSetpointNode NodeId PropertyType Optional
The SetpointNode Property provides the NodeId of the set point used in the deviation
calculation. In cases where the Alarm is generated by an underlying system and if the Variable
is not in the AddressSpace, a NULL NodeId shall be provided.
The BaseSetpointNode Property provides the NodeId of the original or base setpoint. The value
of this node is the value of the setpoint to which an AdaptiveAlarm can be reset if any algorithmic
changes need to be discarded. The value of this node usually contains the originally configured
set point.
5.8.15.3 ExclusiveDeviationAlarmType
The ExclusiveDeviationAlarmType is utilized with multiple mutually exclusive limits. It is formally
Table 68 – ExclusiveDeviationAlarmType definition
Attribute Value
BrowseName ExclusiveDeviationAlarmType
IsAbstract False
References NodeClass BrowseName DataType TypeDefinition Modelling Rule
HasProperty Variable SetpointNode NodeId PropertyType Mandatory
HasProperty Variable BaseSetpointNode NodeId PropertyType Optional
The SetpointNode Property provides the NodeId of the set point used in the Deviation
calculation. If this Variable is not in the AddressSpace, a NULL NodeId shall be provided.
The BaseSetpointNode Property provides the NodeId of the original or base setpoint. The value
of this node is the value of the set point to which an AdaptiveAlarm can be reset if any
algorithmic changes need to be discarded. The value of this node usually contains the originally
configured set point.
5.8.16 Rate of change Alarms

5.8.16.1 Overview
A Rate of Change Alarm is 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 Rate of Change
Alarm becomes active when the rate at which the value changes exceeds or drops below a
defined limit.
A Rate of Change is 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 Rate of
Change of 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.
5.8.16.2 NonExclusiveRateOfChangeAlarmType
The NonExclusiveRateOfChangeAlarmType is a special level Alarm utilized 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 AlarmConditionType should be used
The NonExclusiveRateOfChangeAlarmType is based on the NonExclusiveLimitAlarmType. It is

Table 69 – NonExclusiveRateOfChangeAlarmType definition
Attribute Value
BrowseName NonExclusiveRateOfChangeAlarmType
IsAbstract False
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.
5.8.16.3 ExclusiveRateOfChangeAlarmType
ExclusiveRateOfChangeAlarmType is utilized with multiple mutually exclusive limits. It is
Table 70 – ExclusiveRateOfChangeAlarmType definition
Attribute Value
BrowseName ExclusiveRateOfChangeAlarmType
IsAbstract False
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 pa rent
variable per second e.g. if parent is meters, this unit is meters/second.
5.8.17 Discrete Alarms

5.8.17.1 DiscreteAlarmType
The DiscreteAlarmType is used to classify Types into Alarm Conditions where the input for the
Alarm may take on only a certain number of possible values (e.g. True/False,
running/stopped/terminating). The DiscreteAlarmType with sub types defined in this standard
is illustrated in Figure 20. It is formally defined in Table 71.
AlarmCondition
Type
LimitAlarmType DiscreteAlarmType
OffNormalAlarmType
SystemOffNormalAlarmType TripAlarmType
CertificateExpirationType
Figure 20 – DiscreteAlarmType Hierarchy
Table 71 – DiscreteAlarmType definition
Attribute Value
BrowseName DiscreteAlarmType
IsAbstract False
Rule
Subtype of the AlarmConditionType defined in clause 5.8.2.
HasSubtype ObjectType OffNormalAlarmType Defined in Clause 5.8.15
5.8.17.2 OffNormalAlarmType
The OffNormalAlarmType is a specialization of the DiscreteAlarmType intended to represent a
discrete Condition that 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 Alarm state, it is active as long
as a non-normal value is present.
Table 72 – OffNormalAlarmType Definition
Attribute Value
BrowseName OffNormalAlarmType
IsAbstract False
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 Property is a Property that points to a Variable which has a value that
corresponds to one of the possible values of the Variable pointed to by the InputNode Property
where the NormalState Property Variable value is the value that is considered to be the normal
state of the Variable pointed to by the InputNode Property. When the value of the Variable
referenced by the InputNode Property is not equal to the value of the NormalState Property the
Alarm is Active. If this Variable is not in the AddressSpace, a NULL NodeId shall be provided.
5.8.17.3 SystemOffNormalAlarmType
This Condition is used by a Server to indicate that an underlying system that is providing Alarm
information is having a communication problem and that the Server may have invalid or
incomplete Condition state in the Subscription. Its representation in the AddressSpace is
Table 73 – SystemOffNormalAlarmType definition
Attribute Value
BrowseName SystemOffNormalAlarmType
IsAbstract True
HasSubtype ObjectType CertificateExpirationAlarm Defined in Clause 0
Type
Subtype of the OffNormalAlarmType, i.e. it has HasProperty References to the same Nodes.
5.8.17.4 TripAlarmType
The TripAlarmType is a specialization of the OffNormalAlarmType intended to represent an
equipment trip Condition. The Alarm becomes 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 Type is mainly used for categorization.
Table 74 – TripAlarmType definition
Attribute Value
BrowseName TripAlarmType
IsAbstract False
Rule
Subtype of the OffNormalAlarmType defined in clause 5.8.17.2.
5.8.17.5 InstrumentDiagnosticAlarmType
The InstrumentDiagnosticAlarmType is a specialization of the OffNormalAlarmType intended to
represent a fault in a field device. The Alarm becomes active when the monitored device
experiences a fault such as a sensor failure. It is formally defined in Table 74. This Type is
mainly used for categorization.
Table 75 – InstrumentDiagnosticAlarmType definition
Attribute Value
BrowseName InstrumentDiagnosticAlarmType
IsAbstract False
Rule
5.8.17.6 SystemDiagnosticAlarmType
The SystemDiagnosticAlarmType is a specialization of the OffNormalAlarmType intended to
represent a fault in a system or sub-system. The Alarm becomes active when the monitored
system experiences a fault. It is formally defined in Table 74. This Type is mainly used for
categorization.
Table 76 – SystemDiagnosticAlarmType definition
Attribute Value
BrowseName SystemDiagnosticAlarmType
IsAbstract False
Rule
5.8.17.7 CertificateExpirationAlarmType
This SystemOffNormalAlarmType is raised by the Server when the Server’s Certificate is within
the ExpirationLimit of expiration. This Alarm automatically returns to normal when the certificate
is updated.
Table 77 – CertificateExpirationAlarmType definition
Attribute Value
BrowseName CertificateExpirationAlarmType
IsAbstract False
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
ExpirationDate is the date and time this certificate will expire.
ExpirationLimit is the time interval before the ExpirationDate at which this Alarm will trigger.
This shall be a positive number. If the property is not provided, a defaul t of 2 weeks shall be
used.
CertificateType – See OPC 10000-12 for definition of CertificateType.
Certificate is the certificate that is about to expire.
5.8.18 DiscrepancyAlarmType
The DiscrepancyAlarmType is commonly used to report an action that did not occur within an
expected time range.
The DiscrepancyAlarmType is based on the AlarmConditionType. It is formally defined in Table

78.
Table 78 – DiscrepancyAlarmType definition
Attribute Value
BrowseName DiscrepancyAlarmType
IsAbstract False
References Node BrowseName DataType TypeDefinition Modelling
Class Rule
Subtype of the AlarmConditionType defined in 5.8.2.
HasProperty Variable TargetValueNode NodeId PropertyType Mandatory
HasProperty Variable ExpectedTime Duration PropertyType Mandatory
HasProperty Variable Tolerance Double PropertyType Optional
The TargetValueNode Property provides the NodeId of the Variable that is used for the target
value.
The ExpectedTime Property provides the Duration within which the value pointed to by the
InputNode shall equal the value specified by the TargetValueNode (or be within the Tolerance
range, if specified).
The Tolerance Property is a value that can be added to or subtracted from the
TargetValueNode’s value, 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 DiscrepancyAlarmType shall return to normal when the value has reached the target value .
5.9 ConditionClasses
5.9.1 Overview
Conditions are used in specific application domains like Maintenance, System or Process. The
ConditionClass hierarchy is used to specify domains and is orthogonal to the ConditionType
hierarchy. The ConditionClassId Property of the ConditionType is used to assign a Condition to
a ConditionClass. Clients can use this Property to filter out essential classes. OPC UA defines
the base ObjectType for all ConditionClasses and a set of common classes used across many
industries. Figure 21 informally describes the hierarchy of ConditionClass Types defined in this
standard.

BaseObjectType
BaseConditionClass
Type
ProcessConditionClass MaintenanceConditionClass SystemConditionClass

Type Type Type
Figure 21 – ConditionClass type hierarchy
ConditionClasses are not representations of Objects in the underlying system and, therefore,
only exist as Type Nodes in the Address Space.
5.9.2 BaseConditionClassType
BaseConditionClassType is used as class whenever a Condition cannot be assigned to a more
concrete class. Servers should use a more specific ConditionClass, if possible. All
ConditionClass Types derive from BaseConditionClassType. It is formally defined in Table 79.
Table 79 – BaseConditionClassType definition
Attribute Value
BrowseName BaseConditionClassType
IsAbstract True
Subtype of the BaseObjectType defined in OPC 10000-5.
5.9.3 ProcessConditionClassType
The ProcessConditionClassType is used to classify Conditions related to the process itself.
Examples of a process would be a control system in a boiler or the instrumentation associated
with a chemical plant or paper machine. The ProcessConditionClassType is formally defined in
Table 80.
Table 80 – ProcessConditionClassType definition
Attribute Value
BrowseName ProcessConditionClassType
IsAbstract True
Rule
Subtype of the BaseConditionClassType defined in clause 5.9.2.
5.9.4 MaintenanceConditionClassType
The MaintenanceConditionClassType is used to classify Conditions related to maintenance.
Examples of maintenance would be Asset Management systems or conditions, which occur in
process control systems, which are related to calibration of equipment. The
MaintenanceConditionClassType is formally defined in Table 81. No further definition is
provided here. It is expected that other standards groups will de fine domain-specific sub-types.
Table 81 – MaintenanceConditionClassType definition
Attribute Value
BrowseName MaintenanceConditionClassType
IsAbstract True
5.9.5 SystemConditionClassType
The SystemConditionClassType is used to classify Conditions related to the System. It is
formally defined in Table 82. System Conditions occur in the controlling or monitoring system
process. Examples of System related items could include available disk space on a compute r,
Archive media availability, network loading issues or a controller error, No further definition is
provided here. It is expected that other standards groups or vendors will de fine domain-specific
sub-types.
Table 82 – SystemConditionClassType definition
Attribute Value
BrowseNam SystemConditionClassType
e
IsAbstract True
5.9.6 SafetyConditionClassType
The SafetyConditionClassType is used to classify Conditions related to safety. It is formally
Safety Conditions occur in the controlling or monitoring system process. Examples of safety
related items could include, emergency shutdown systems or fire suppression systems.
Table 83 – SafetyConditionClassType definition
Attribute Value
BrowseName SafetyConditionClassType
IsAbstract True
5.9.7 HighlyManagedAlarmConditionClassType
In Alarm systems some Alarms may be classified as highly managed Alarms. This class of
Alarm requires special handling that varies according to the individual requirements. It might
require individual acknowledgement or not allow suppression or any of a number of other
special behaviours. The HighlyManagedAlarmConditionClassType is used to classify
Conditions as highly managed Alarms. It is formally defined in Table 84.
Table 84 – HighlyManagedAlarmConditionClassType definition
Attribute Value
BrowseName HighlyManagedAlarmConditionClassType
IsAbstract True
5.9.8 TrainingConditionClassType
The TrainingConditionClassType is used to classify Conditions related to training system or
training exercises. It is formally defined in Table 85. These Conditions typically occur in a
training system or are generated as part of a simulation for a training exercise. Training
Conditions might be process or system conditions. It is expected that other standards groups
or vendors will define domain-specific sub-types.
Table 85 – TrainingConditionClassType definition
Attribute Value
BrowseName TrainingConditionClassType
IsAbstract True
Subtype of the BaseConditionClassType defined in clause.
5.9.9 StatisticalConditionClassType
The StatisticalConditionClassType is used to classify Conditions related that are based on
statistical calculations. It is formally defined in Table 86. These Conditions are generated as
part of a statistical analysis. They might be any of an Alarm number of types.
Table 86 – StatisticalConditionClassType definition
Attribute Value
BrowseName StatisticalConditionClassType
IsAbstract True
Subtype of the BaseConditionClassType defined in clause.
5.9.10 TestingConditionSubClassType
The TestingConditionSubClassType is used to classify Conditions related to testing of an Alarm
system or Alarm function. It is formally defined in Table 87. Testing Conditions might include a
condition to test an alarm annunciation such as a horn or other panel. It might also be used to
temporarily reclassify a Condition to check response times or suppression logic. It is expected
that other standards groups or vendors will define domain -specific sub-types.
Table 87 – TestingConditionSubClassType definition
Attribute Value
BrowseName TestingConditionSubClassType
IsAbstract True
5.10 Audit Events

5.10.1 Overview
Following are sub-types of AuditUpdateMethodEventType that will be generated in response to
the Methods defined in this document. They are illustrated in Figure 22.

AuditEventType
AuditUpdateMethod
EventType
AuditCondition
EventType
AuditConditionConfirm AuditConditionRespond
EventType EventType
AuditConditionEnable AuditConditionSupress
EventType EventType
AuditConditionComment AuditConditionShelving
EventType EventType
AuditConditionAcknowledge AuditConditionOutOf AuditConditionSIlence

EventType ServiceEventType EventType
Figure 22 – AuditEvent hierarchy
AuditConditionEventTypes are normally used in response to a Method call. However, these

Events shall also be notified if the functionality of such a Method is performed by some other
Server-specific means. In this case, the SourceName Property shall contain a proper
description of this internal means and the other Properties should be filled in as described for
the given EventType.
5.10.2 AuditConditionEventType
This EventType is used to subsume all AuditConditionEventTypes. It is formally defined in Table
88.
Table 88 – AuditConditionEventType definition
Attribute Value
BrowseName AuditConditionEventType
IsAbstract False
Subtype of the AuditUpdateMethodEventType defined in OPC 10000-5
AuditConditionEventTypes inherit all Properties of the AuditUpdateMethodEventType defined

in OPC 10000-5. Unless a subtype overrides the definition, the inherited Properties of the
Condition will be used as defined.
 The inherited Property SourceNode shall be filled with the ConditionId.

 The SourceName shall be “Method/” and the name of the Service that generated the
Event (e.g. Disable, Enable, Acknowledge, etc.).
This EventType can be further customized to reflect particular Condition related actions.
5.10.3 AuditConditionEnableEventType
This EventType is used to indicate a change in the enabled state of a Condition instance. It is
Table 89 – AuditConditionEnableEventType definition
Attribute Value
BrowseName AuditConditionEnableEventType
IsAbstract False
Subtype of the AuditConditionEventType defined in 5.10.2 that is, inheriting the InstanceDeclarations of that Node.
The SourceName shall indicate Method/Enable or Method/Disable. If the audit Event is not the
result of a Method call, but due to an internal action of the Server, the SourceName shall reflect
Enable or Disable, it may be preceded by an appropriate description such as “ Internal/Enable”
or “Remote/Enable”.
5.10.4 AuditConditionCommentEventType
This EventType is used to report an AddComment action. It is formally defined in Table 90.
Table 90 – AuditConditionCommentEventType definition
Attribute Value
BrowseName AuditConditionCommentEventType
IsAbstract False
HasProperty Variable ConditionEventId ByteString PropertyType Mandatory
HasProperty Variable Comment LocalizedText PropertyType Mandatory
The ConditionEventId field shall contain the id of the event for which the comment was added.
The Comment contains the actual comment that was added.
5.10.5 AuditConditionRespondEventType
This EventType is used to report a Respond action (see 5.6). It is formally defined in Table 91.
Table 91 – AuditConditionRespondEventType definition
Attribute Value
BrowseName AuditConditionRespondEventType
IsAbstract False
HasProperty Variable SelectedResponse Uint32 PropertyType Mandatory
The SelectedResponse field shall contain the response that was selected.
5.10.6 AuditConditionAcknowledgeEventType
This EventType is used to indicate acknowledgement or confirmation of one or more Conditions.
It is formally defined in Table 92.
Table 92 – AuditConditionAcknowledgeEventType definition
Attribute Value
BrowseName AuditConditionAcknowledgeEventType
IsAbstract False
The ConditionEventId field shall contain the id of the Event that was acknowledged.
The Comment contains the actual comment that was added , it may be a blank comment or a
NULL.
5.10.7 AuditConditionConfirmEventType
This EventType is used to report a Confirm action. It is formally defined in Table 93.
Table 93 – AuditConditionConfirmEventType definition
Attribute Value
BrowseName AuditConditionConfirmEventType
IsAbstract False
The ConditionEventId field shall contain the id of the Event that was confirmed.
The Comment contains the actual comment that was added, it may be a blank comment or a
NULL.
5.10.8 AuditConditionShelvingEventType
This EventType is used to indicate a change to the Shelving state of a Condition instance. It is
Table 94 – AuditConditionShelvingEventType definition
Attribute Value
BrowseName AuditConditionShelvingEventType
IsAbstract False
HasProperty Variable ShelvingTime Duration PropertyType Optional
If the Method indicates a TimedShelve operation, the ShelvingTime field shall contain duration
for which the Alarm is to be shelved. For other Shelving Methods, this parameter may be omitted
or NULL.
5.10.9 AuditConditionSuppressionEventType
This EventType is used to indicate a change to the Suppression state of a Condition instance.
Table 95 – AuditConditionSuppressionEventType definition
Attribute Value
BrowseName AuditConditionSuppressionEventType
IsAbstract False
This Event indicates an Alarm suppression operation. An audit Event of this type shall be
generated, if audit events are supported for any suppression action, including automatic system
based suppression.
5.10.10 AuditConditionSilenceEventType
This EventType is used to indicate a change to the Silence state of a Condition instance. It is
Table 96 – AuditConditionSilenceEventType definition
Attribute Value
BrowseName AuditConditionSilenceEventType
IsAbstract False
This event indicates that an Alarm was silenced, but not acknowledged. An audit event of this
type shall be generated, if Audit events are supported for any silence action, including automatic
system based silence.
5.10.11 AuditConditionResetEventType
This EventType is used to indicate a change to the Latched state of a Condition instance. It is
Table 97 – AuditConditionResetEventType definition
Attribute Value
BrowseName AuditConditionResetEventType
IsAbstract False
This event indicates that an Alarm was reset. An audit event of this type shall be generated, if
Audit events are supported for any Alarm action.
5.10.12 AuditConditionOutOfServiceEventType
This EventType is used to indicate a change to the OutOfService State of a Condition instance.
Table 98 – AuditConditionOutOfServiceEventType definition
Attribute Value
BrowseName AuditConditionOutOfServiceEventType
IsAbstract False
An audit Event of this type shall be generated if audit Events are supported.
5.11 Condition Refresh related Events

5.11.1 Overview
Following are sub-types of SystemEventType that will be generated in response to a Refresh
Methods call. They are illustrated in Figure 23.

BaseEventType
SystemEventType
RefreshStart RefreshEnd RefreshRequired

EventType EventType EventType
Figure 23 – Refresh Related Event Hierarchy
5.11.2 RefreshStartEventType
This EventType is used by a Server to mark the beginning of a Refresh Notification cycle. Its
representation in the AddressSpace is formally defined in Table 99.
Table 99 – RefreshStartEventType definition
Attribute Value
BrowseName RefreshStartEventType
IsAbstract True
Subtype of the SystemEventType defined in OPC 10000-5, i.e. it has HasProperty References to the same
Nodes.
5.11.3 RefreshEndEventType
This EventType is used by a Server to mark the end of a Refresh Notification cycle. Its
representation in the AddressSpace is formally defined in Table 100.
Table 100 – RefreshEndEventType definition
Attribute Value
BrowseName RefreshEndEventType
IsAbstract True
Subtype of the SystemEventType defined in OPC 10000-5, i.e. it has HasProperty References to the
same Nodes.
5.11.4 RefreshRequiredEventType
This EventType is used by a Server to indicate that a significant change has occurred in the
Server or in the subsystem below the Server that may or does invalidate the Condition state of
a Subscription. Its representation in the AddressSpace is formally defined in Table 101.
Table 101 – RefreshRequiredEventType definition
Attribute Value
BrowseName RefreshRequiredEventType
IsAbstract True
Subtype of the SystemEventType defined in OPC 10000-5, i.e. it has HasProperty References to the
same Nodes.
When a Server detects an Event queue overflow, it shall track if any Condition Events have
been lost, if any Condition Events were lost, it shall issue a RefreshRequiredEventType Event
to the Client after the Event queue is no longer in an overflow state.
5.12 HasCondition Reference type

The HasCondition ReferenceType is a concrete ReferenceType and can be used directly. It is
a subtype of NonHierarchicalReferences. The representation in the AddressSpace is specified
in Table 102.
The semantic of this ReferenceType is to specify the relationship between a ConditionSource

and its Conditions. Each ConditionSource shall be the target of a HasEventSource Reference
or a sub type of HasEventSource. The AddressSpace organisation that shall be provided for
Clients to detect Conditions and ConditionSources is defined in Clause 6. Various examples for
the use of this ReferenceType can be found in B.2.
HasCondition References can be used in the Type definition of an Object or a Variable. In this
case, the SourceNode of this ReferenceType shall be an ObjectType or VariableType Node or
one of their InstanceDeclaration Nodes. The TargetNode shall be a Condition instance
declaration or a ConditionType. The following rules for instantiation apply:
 All HasCondition References used in a Type shall exist in instances of these Types as
well.
 If the TargetNode in the Type definition is a ConditionType, the same TargetNode will
be referenced on the instance.
HasCondition References may be used solely in the instance space when they are not available
in Type definitions. In this case the SourceNode of this ReferenceType shall be an Object,
Variable or Method Node. The TargetNode shall be a Condition instance or a ConditionType.
Table 102 – HasCondition ReferenceType
Attributes Value
BrowseName HasCondition
InverseName IsConditionOf
Symmetric False
IsAbstract False
5.13 Alarm & Condition status codes

Table 103 defines the StatusCodes defined for Alarm & Conditions.
Table 103 – Alarm & Condition result codes

Symbolic Id Description
Bad_ConditionAlreadyEnabled The addressed Condition is already enabled.
Bad_ConditionAlreadyDisabled The addressed Condition is already disabled.
Bad_ConditionAlreadyShelved The Alarm is already in a shelved state.
Bad_ConditionBranchAlreadyAcked The EventId does not refer to a state that needs acknowledgement.
Bad_ConditionBranchAlreadyConfirmed The EventId does not refer to a state that needs confirmation.
Bad_ConditionNotShelved The Alarm is not in the requested shelved state.
Bad_DialogNotActive The DialogConditionType instance is not in Active state.
Bad_DialogResponseInvalid The selected option is not a valid index in the ResponseOptionSet array.
Bad_EventIdUnknown The specified EventId is not known to the Server.
Bad_RefreshInProgress A ConditionRefresh operation is already in progress.
Bad_ShelvingTimeOutOfRange The provided Shelving time is outside the range allowed by the Server for Shelving
5.14 Expected A&C server behaviours

5.14.1 General
This section describes behaviour that is expected from an OPC UA Server that is implementing
the A&C Information Model. In particular this section describes specific behaviours that apply
to various aspect of the A&C Information Model.
5.14.2 Communication problems

In some implementation of an OPC UA A&C Server, the Alarms and Condition are provided by
an underlying system. The expected behaviour of an A&C Server when it is encountering
communication problems with the underlying system is:
 If communication fails to the underlying system,

– For any Event field related information that is exposed in the address space, t he
Value/StatusCode obtained when reading the Event fields that are associated with the
communication failure shall have a value of NULL and a StatusCode of
Bad_CommunicationError.
– For Subscriptions that contain Conditions for which the failure applies, the effected
Conditions generate an Event, if the Retain field is set to True. These Events shall have
their Event fields that are associated with the communication failure contain a
StatusCode of Bad_CommunicationError for the value.
– A Condition of the SystemOffNormalAlarmType shall be used to report the
communication failure to Alarm Clients. The NormalState field shall contain the NodeId
of the Variable that indicates the status of the underlying system.
 For start-up of an A&C Server that is obtaining A&C information from an already running
underlying system:
– If a value is unavailable for an Event field that is being reported do to a start-up of the
UA Server (i.e. the information is just not available for the Event) the Event field shall
contain a StatusCode set to Bad_WaitingForInitialData for the value.
– If the Time field is normally provided by the underlying system and is unavailable, the
Time will be reported as a StatusCode with a value of Bad_WaitingForInitialData.
5.14.3 Redundant A&C servers
In an OPC UA Server that is implementing the A&C Information Model and that is configured to
be a redundant OPC UA Server the following behaviour is expected:
 The EventId is used to uniquely identify an Event. For an Event that is in each of the
redundant Servers, it shall be identical. This applies to all standard Events, Alarms and
Conditions. This may be accomplished by sharing of information between redundant
Server (such as actual Events) or it may be accomplished by providing a strict EventId
generating algorithm that will generate an identical EventId for each Event
 It is expected that for cold or warm failovers of redundant Servers, Subscription for
Events shall require a Refresh operation. The Client shall initiate this Refresh operation.
 It is expected that for hot failovers of redundant Servers, Subscriptions for Events may
require a Refresh operation. The Server shall issue a RefreshRequiredEventType Event
if it is required.
 For transparent redundancy, a Server shall not require any action be performed by a
Client.
6 AddressSpace organisation
6.1 General
The AddressSpace organisation described in this Clause allows Clients to detect Conditions
and ConditionSources. An additional hierarchy of Object Nodes that are notifies may be
established to define one or more areas; the Client can subscribe to specific areas to limit the
Event Notifications sent by the Server. Additional examples can be found in Clause B.2.
6.2 EventNotifier and source hierarchy

HasNotifier and HasEventSource References are used to expose the hierarchical organization
of Event notifying Objects and ConditionSources. An Event notifying Object represents typically
an area of Operator responsibility. The definition of such an area configuration is outside the
scope of this standard. If areas are available, they shall be linked together and with the included
ConditionSources using the HasNotifier and the HasEventSource Reference Types. The Server
Object shall be the root of this hierarchy.
Figure 24 shows such a hierarchy. Note that HasNotifier is a sub-type of HasEventSource. I.e.
the target Node of a HasNotifier Reference (an Event notifying Object) may also be a
ConditionSource. The HasEventSource Reference is used if the target Node is a
ConditionSource but cannot be used as Event notifier. See OPC 10000-3 for the formal
definition of these Reference Types.
Server
HasEventSource
HasNotifier
HasNotifier Area 1 HasNotifier
HasNotifier Tank Farm Machine B
Tank A HasNotifier
HasEventSource
LevelMeasurement Device B Device C
Figure 24 – Typical HasNotifier Hierarchy
6.3 Adding Conditions to the hierarchy

HasCondition is used to reference Conditions. The Reference is from a ConditionSource to a
Condition instance or – if no instance is exposed by the Server – to the ConditionType.
Clients can locate Conditions by first browsing for ConditionSources following HasEventSource
References (including sub-types like the HasNotifier Reference) and then browsing for
HasCondition References from all target Nodes of the discovered References.
Figure 25 shows the application of the HasCondition Reference in a HasNotifier hierarchy. The
Variable LevelMeasurement and the Object “Device B” Reference Condition instances. The
Object “Tank A” References a ConditionType (MySystemAlarmType) indicating that a Condition
exists but is not exposed in the AddressSpace.
Server
HasNotifier
HasNotifier Area 1 HasNotifier
HasNotifier Tank Farm Machine B
Tank A HasNotifier
HasEventSource
HasCondition
Device B
LevelMeasurement
MyAlarmTypeA:
MyLevelAlarmType: Condition 1
HasCondition
LevelMonitoring
HasCondition
MyAlarmTypeA:
MySystemAlarmType Condition 2
Figure 25 – Use of HasCondition in a HasNotifier hierarchy
6.4 Conditions in InstanceDeclarations

Figure 26 shows the use of the HasCondition Reference and the HasEventSource Reference in
an InstanceDeclaration. They are used to indicate what References and Conditions are
available on the instance of the ObjectType.
The use of the HasEventSource Reference in the context of InstanceDeclarations and

TypeDefinition Nodes has no effect for Event generation.
TankType Tank A
HasEventSource
HasEventSource
LevelMeasurement LevelMeasurement
HasCondition HasCondition
MyLevelAlarmType: MyLevelAlarmType:
LevelMonitoring LevelMonitoring
Figure 26 – Use of HasCondition in an InstanceDeclaration
6.5 Conditions in a VariableType

Use of HasCondition in a VariableType is a special use case since Variables (and
VariableTypes) may not have Conditions as components. Figure 27 provides an example of this
use case. Note that there is no component relationship for the “LevelMonitoring” Alarm. It is
Server-specific whether and where they assign a HasComponent Reference.
BaseObjectType BaseVariableType
Tank A
AlarmType AnalogItemType
HasEventSource
ExclusiveLevel LevelMeasurementType
AlarmType
HasCondition LevelMeasurementType:
LevelMeasurement
ExclusiveLevelAlarmType: HasCondition
LevelMonitoring
ExclusiveLevelAlarmType:
LevelMonitoring
Figure 27 – Use of HasCondition in a VariableType

7 System State & Alarms

7.1 Overview
The state of alarms is affected by the state of the process, equipment, system or plant. For
example, when a tank is taken out of service, the level alarms associated with the tank would
be no longer used, until the tank is returned to service. This section describe s ReferenceTypes
that can be used by a StateMachine to indicate that a specific Effect on Alarms caused by the
transition of a StateMachine. StateMachines that describe the state of a process, system or
equipment can vary, but an example StateMachine is provided in Annex F.
7.2 HasEffectDisable
The HasEffectDisable ReferenceType is a concrete ReferenceType and can be used directly.
It is a subtype of HasEffect.
The semantic of this ReferenceType is to point form a Transition to an Alarm that will be
disabled.
 If the Reference is to an Object then all Alarms in the HasNotifier hierarchy below that
Object are disabled,
 If the target is an AlarmType then all instances of that AlarmType in the HasNotifier
hierarchy below the Object containing the StateMachine are disabled,
 If the target is an Alarm instance then the given Alarm instance is disabled.
The SourceNode of this ReferenceType shall be an Object of the ObjectType TransitionType or

one of its subtypes. The TargetNode can be of an Object or AlarmType.
The representation of the HasEffectDisable ReferenceType in the AddressSpace is specified in

Table 104
Table 104 – HasEffectDisable ReferenceType
Attributes Value
BrowseName HasEffectDisable
InverseName MayBeDisabledBy
Symmetric False
IsAbstract False
7.3 HasEffectEnable
The HasEffectEnable ReferenceType is a concrete ReferenceType and can be used directly. It
is a subtype of HasEffect.
enabled.
Object are enabled,
 If the target is an AlarmType then all instances of that AlarmType in the HasNotifier
hierarchy below the Object containing the StateMachine are enabled
 If the target is an Alarm instance then the given Alarm instance is enabled.

one of its subtypes. The TargetNode can be of any NodeClass.
The representation of the HasEffectenable ReferenceType in the AddressSpace is specified in

Table 105
Table 105 – HasEffectEnable ReferenceType
Attributes Value
BrowseName HasEffectEnable
InverseName MayBeEnabledBy
Symmetric False
IsAbstract False
7.4 HasEffectSuppress
The HasEffectSuppress ReferenceType is a concrete ReferenceType and can be used directly.
It is a subtype of HasEffect.
suppressed.
 If the reference is to an Object then all Alarms in the EventNotifer hierarchy below that
Object are suppressed,
 If the target is an AlarmType then all instance of that AlarmType in the HasNotifier
hierarchy below the Object containing the StateMachine are suppressed,
 If the target is an Alarm instance then the given Alarm instance is suppressed.

The representation of the HasEffectSuppress ReferenceType in the AddressSpace is specified

in Table 106
Table 106 – HasEffectSuppress ReferenceType
Attributes Value
BrowseName HasEffectSuppress
InverseName MayBeSuppressedBy
Symmetric False
IsAbstract False
7.5 HasEffectUnsuppressed
The HasEffectUnsuppressed ReferenceType is a concrete ReferenceType and can be used
directly. It is a subtype of HasEffect.
The semantic of this ReferenceType is to point form a Transition to an Alarm that will no longer
be suppressed.
Object are removed from being suppressed,
 If the target is an AlarmType then all instance of that AlarmType are no longer
suppressed below the Object containing the StateMachine,
 if the target is an Alarm instance then the given Alarm instance is no longer suppressed.
No errors are logged if the Alarm was not suppressed.

The representation of the HasEffectUnsuppress ReferenceType in the AddressSpace is

specified in Table 107
Table 107 – HasEffectUnsuppress ReferenceType
Attributes Value
BrowseName HasEffectUnsuppress
InverseName MayBeUnsuppressedBy
Symmetric False
IsAbstract False
8 Alarm Metrics
8.1 Overview
The goal of a well-designed alarm system is to ensure that an Operator is made aware of issues,
both critical and non-critical, but is not overwhelmed by alarms/alerts or other messages. When
designing an alarm system, criteria are defined for alarm rates and general performance of the
system at various levels (Operator station, plant area, overall system etc.). Evaluating the
performance of an alarm system with regard to these design criteria requires the collection of
alarm metrics. These metrics provide summaries of alarm rates and other alarm related
information.
This section defines a standard structure for metrics. This structure can be implemented at
multiple levels allowing a Server to collect metrics as needed. For example, an Object of this
type might be added to the Server Object providing a summary of the Alarm performance for
the entire Server. An instance might also be provided on an Object that includes a HasNotifier
hierarchy, such as a tank Object. In this case, it would provide the summary of all of the Alarms
that are part of the tank HasNotifier hierarchy.
8.2 AlarmMetricsType
This ObjectType is used for metric information. The ObjectType is formally defined in Table
108.
Table 108 – AlarmMetricsType Definition
Attribute Value
BrowseName AlarmMetricsType
IsAbstract False
Rule
Subtype of the BaseObjectType defined in OPC 10000-5.
HasComponent Variable AlarmCount UInt32 BaseDataVariableType Mandatory
HasComponent Variable StartTime UtcTime BaseDataVariableType Mandatory
HasComponent Variable MaximumActiveState Duration BaseDataVariableType Mandatory
HasComponent Variable MaximumUnAck Duration BaseDataVariableType Mandatory
HasComponent Variable CurrentAlarmRate Double AlarmRateVariableType Mandatory
HasComponent Variable MaximumAlarmRate Double AlarmRateVariableType Mandatory
HasComponent Variable MaximumReAlarmCount UInt32 BaseDataVariableType Mandatory
HasComponent Variable AverageAlarmRate Double AlarmRateVariableType Mandatory
HasComponent Method Reset Mandatory
An instance of AlarmMetricsType can be added, with a HasComponent reference, to any Object

that has its “SubscribeToEvents” bit set within the EventNotifier Attribute. It will collect the Alarm
metrics for all Alarm sources assigned to this notifier Object. For example, if Alarm metrics are
desired for Tank A Object (see Figure B.3) that is in the HasNotifier hierarchy than an instance
of this object would be referenced by the Tank A object. When this object is associated with the
Server Object it will report Alarm metrics for the entire Server.
AlarmCount is the total count of Alarms since the last restart of the system or reset of this
counter.
StartTime is the time at which the Server started or the time of the last Reset Method invocation,
whichever is later.
MaximumActiveState is the maximum time for which an Alarm was in the active state.
MaximumUnAck is the maximum time for which an Alarm was in the unacknowledged state.
CurrentAlarmRate is the sum of Alarms that occurred in the last Rate number of minutes (see
8.3). This sum should not include nuisance Alarms (i.e. chattering alarms). It is updated every
Rate number of minutes.
MaximumAlarmRate is the maximum Alarm rate detected since the start of the Server, where
the rate is calculated as for CurrentAlarmRate.
MaximumReAlarmCount is the maximum ReAlarmCount for any Alarm.
AverageAlarmRate is the average Alarm rate since the start of the Server or the last invocation
of Reset Method, where the rate is calculated as for CurrentAlarmRate.
Reset is a Method that will reset all of the counters, rates or times in this Object
8.3 AlarmRateVariableType
This variable type provides a unit field for the rate for which the Alarm diagnostic applies.
Table 109 – AlarmRateVariableType Definition
Attribute Value
BrowseName AlarmRateVariableType
IsAbstract False
ValueRank Scalar
DataType Double
HasProperty Variable Rate UInt16 PropertyType Mandatory
Rate – is the number of minutes over which the item is calculated.
8.4 Reset Method

The Reset Method is used reset all of the counters, rates and time in the Object
Signature
Reset();
Table 110 – Suppress result codes

Bad_NodeIdInvalid Used to indicate that the specified ObjectId is not valid. See OPC 10000-4 for the
general description of this result code.
Comments
The Reset Method will clear all setting in the diagnostic object and initialize them to zero.
Table 111 specifies the AddressSpace representation for the Reset Method.
Table 111 – Reset Method AddressSpace definition
Attribute Value
BrowseName Reset
Rule
AlwaysGeneratesEvent ObjectType AuditUpdateMethodEventType Defined in OPC 10000-5

Annex A (informative)
Recommended localized names
A.1 Recommended state names for TwoState variables

A.1.1 LocaleId “en”
The recommended state display names for the LocaleId “en” are listed in Table A.1 and
Table A.2
Table A.1 – Recommended state names for LocaleId “en”
Condition Type State Variable False State Name True State Name
ConditionType EnabledState Disabled Enabled
DialogConditionType DialogState Inactive Active
AcknowledgeableConditionType AckedState Unacknowledged Acknowledged
ConfirmedState Unconfirmed Confirmed
AlarmConditionType ActiveState Inactive Active
SuppressedState Unsuppressed Suppressed
OutOfServiceState In Service Out of Service
SilenceState Silenced Not Silenced
LatchedState Latched Unlatched
NonExclusiveLimitAlarmType HighHighState HighHigh inactive HighHigh active
HighState High inactive High active
LowState Low inactive Low active
LowLowState LowLow inactive LowLow active
Table A.2 – Recommended display names for LocaleId “en”
Condition Type Browse Name display name

Unshelved Unshelved
Shelved TimedShelved Timed Shelved
OneShotShelved One Shot Shelved
Exclusive HighHigh HighHigh
High High
Low Low
LowLow LowLow
A.1.2 LocaleId “de”

The recommended state display names for the LocaleId “de” are listed in Table A.3 and
Table A.4.
Table A.3 – Recommended state names for LocaleId “de”
ConditionType EnabledState Ausgeschaltet Eingeschaltet
DialogConditionType DialogState Inaktiv Aktiv
AcknowledgeableConditionType AckedState Unquittiert Quittiert
ConfirmedState Unbestätigt Bestätigt
AlarmConditionType ActiveState Inaktiv Aktiv
SuppressedState Nicht unterdrückt Unterdrückt
OutOfServiceState In Betrieb Außer Betrieb
SilenceState Stumm Nicht Stumm
LatchedState Verriegelt Entriegelt
NonExclusiveLimitAlarmType HighHighState HighHigh inaktiv HighHigh aktiv
HighState High inaktiv High aktiv
LowState Low inaktiv Low aktiv
LowLowState LowLow inaktiv LowLow aktiv
Table A.4 – Recommended display names for LocaleId “de”

Unshelved Nicht zurückgestellt
Shelved TimedShelved Befristet zurückgestellt
OneShotShelved Einmalig zurückgestellt
Exclusive HighHigh HighHigh
High High
Low Low
LowLow LowLow
A.1.3 LocaleId “fr”

The recommended state display names for the LocaleId “fr” are listed in Table A.5 and
Table A.6.
Table A.5 – Recommended state names for LocaleId “fr”
ConditionType EnabledState Hors Service En Service
DialogConditionType DialogState Inactive Active
AcknowledgeableConditionType AckedState Non-acquitté Acquitté
ConfirmedState Non-Confirmé Confirmé
AlarmConditionType ActiveState Inactive Active
SuppressedState Présent Supprimé
OutOfServiceState En Fonction Hors Fonction
SilenceState Muette Non-Muette
LatchedState
NonExclusiveLimitAlarmType HighHighState Très Haute Inactive Très Haute Active
HighState Haute inactive Haute active
LowState Basse inactive Basse active
LowLowState Très basse inactive Très basse active
Table A.6 – Recommended display names for LocaleId “fr”

Unshelved Surveillée
Shelved TimedShelved Mise de coté temporelle
OneShotShelved Mise de coté unique
Exclusive HighHigh Très haute
High Haute
Low Basse
LowLow Très basse
A.2 Recommended dialog response options

The recommended Dialog response option names in different locales are listed in Table A.7.
Table A.7 – Recommended dialog response options
Locale “en” Locale “de” Locale “fr”

Ok OK Ok
Cancel Abbrechen Annuler
Yes Ja Oui
No Nein Non
Abort Abbrechen Abandonner
Retry Wiederholen Réessayer
Ignore Ignorieren Ignorer
Next Nächster Prochain
Previous Vorheriger Precedent
Annex B(informative)
Examples
B.1 Examples for Event sequences from Condition instances

B.1.1 Overview
The following examples show the Event flow for typical Alarm situations. The tables list the
value of state Variables for each Event Notification.
B.1.2 Server maintains current state only

This example is for Servers that do not support previous states and therefore do not create and
maintain Branches of a single Condition.
Figure B.1 shows an Alarm as it becomes active and then inactive and also the
acknowledgement and confirmation cycles. Table B.1 lists the values of the state Variables. All
Events are coming from the same Condition instance and therefore have the same ConditionId.
Confirmed
Acked
Active
Time Axis
Event
Notifications 1 2 3 4 5 6 7 8
Figure B.1 – Single state example
Table B.1 – Example of a Condition that only keeps the latest state
EventId BranchId Active Acked Confirmed Retain Description

-*) NULL False True True False Initial state of Condition.
1 NULL True False True True Alarm goes active.
2 NULL True True False True Condition acknowledged Confirm required
3 NULL False True False True Alarm goes inactive.
4 NULL False True True False Condition confirmed
6 NULL False False True True Alarm goes inactive.
7 NULL False True False True Condition acknowledged, Confirm required.
8 NULL False True True False Condition confirmed.
*) The first row is included to illustrate the initial state of the Condition. This state will not be reported by an Event.
B.1.3 Server maintains previous states

This example is for Servers that are able to maintain previous states of a Condition and
therefore create and maintain Branches of a single Condition.
Figure B.2 illustrates the use of branches by a Server requiring acknowledgement of all
transitions into Active state, not just the most recent transition. In this example no
acknowledgement is required on a transition into an inactive state. Table B.2 lists the values of
the state Variables. All Events are coming from the same Condition instance and have therefore
the same ConditionId.
Previous State
(BranchId 2)
Acked=false
Active=true
Previous State
(BranchId 1)
Active=true
Confirmed
Current State
Acked
(BranchId Null)
Active
Time Axis
Event
Notifications 1 2 3 5 6 8 10 14
4 7 9 12
11 13
Figure B.2 – Previous state example
Table B.2 – Example of a Condition that maintains previous states via branches
EventId BranchId Active Acked Confirmed Retain Description

a)
NULL False True True False Initial state of Condition.
2 NULL True True True True Condition acknowledged requires Confirm
3 NULL False True False True Alarm goes inactive.
4 NULL False True True False Confirmed
6 NULL False True True True Alarm goes inactive.
b) Prior state needs acknowledgment. Branch #1
7 1 True False True True created.
8 NULL True False True True Alarm goes active again.
9 1 True True False True Prior state acknowledged, Confirm required.
b)
10 NULL False True True True Alarm goes inactive again.
Prior state needs acknowledgment. Branch #2
11 2 True False True True
created.
12 1 True True True False Prior state confirmed. Branch #1 deleted.
Prior state acknowledged, Auto Confirmed by
13 2 True True True False
system Branch #2 deleted.
14 NULL False True True False No longer of interest.
a) The first row is included to illustrate the initial state of the Condition. This state will not be reported by an Event.
Notes on specific situations shown with this example:

If the current state of the Condition is acknowledged then the Acked flag is set and the new state is reported (Event
#2). If the Condition state changes before it can be acknowledged (Event #6) then a branch state is reported (Event
#7). Timestamps for the Events #6 and #7 is identical.
The branch state can be updated several times (Events #9) before it is cleared (Event #12).
A single Condition can have many branch states active (Events #11)
b) It is recommended as in this table to leave Retain=True as long as there exist previous states (branches).
B.2 AddressSpace examples

This Clause provides additional examples for the use of HasNotifier, HasEventSource and
HasCondition References to expose the organization of areas and sources with their associated
Conditions. This hierarchy is additional to a hierarchy provided with Organizes and Aggregates
References.
Figure B.3 illustrates the use of the HasCondition Reference with Condition instances.
Objects
HasNotifier
Server
Area 1
Organizes
Tank Farm Machine B
Tank A
HasEventSource
LevelMeasurement
HasCondition
HasEventSource
MyLevelAlarmType:
LevelMonitoring
Device B
HasCondition
MyAlarmTypeA:
Condition 1
MyAlarmTypeA:
Condition 2
Figure B.3 – HasCondition used with Condition instances
In systems where Conditions are not available as instances, the ConditionSource can reference
the ConditionTypes instead. This is illustrated with the example in Figure B.4.
Objects
HasNotifier
Server
Area 1
ProcessAlarm
Type
Organizes
Tank Farm Machine B
ExclusiveLimit
AlarmType
Tank A
HasEventSource
Exclusive
Level
LevelMeasurement
HasCondition
MyLevelAlarmType
Figure B.4 – HasCondition reference to a Condition type
Figure B.5 provides an example where the HasCondition Reference is already defined in the
Type system. The Reference can point to a Condition Type or to an instance. Both variants are
shown in this example. A Reference to a Condition Type in the Type system will result in a
Reference to the same Type Node in the instance.
MySystemAlarmType
Tank Farm
HasNotifier
HasCondition
HasCondition
TankType Tank A
HasEventSource HasEventSource
LevelMeasurement LevelMeasurement
HasCondition HasCondition
MyLevelAlarmType: MyLevelAlarmType:
LevelMonitoring LevelMonitoring
Figure B.5 – HasCondition used with an instance declaration

Annex C
(informative)
Mapping to EEMUA
Table C.1 lists EEMUA terms and how OPC UA terms maps to them.
Table C.1 – EEMUA Terms
EEMUA Term OPC UA Term EEMUA Definition
An Alarm is accepted when the Operator has indicated awareness of its presence.
Accepted Acknowledged=True
In OPC UA this can be accomplished with the Acknowledge Method.
An Alarm Condition which is on (i.e. limit has been exceeded and Condition
Active Alarm Active = True
continues to exist).
Message Property Test information presented to the Operator that describes the Alarm Condition.
Alarm
(defined in OPC
Message
10000-5.)
Severity Property The ranking of Alarms by severity and response time.
Alarm Priority (defined in OPC
10000-5.)
A lower priority Notification than an Alarm that has no serious consequence if
ignored or missed. In some Industries also referred to as a Prompt or Warning”.
Alert -
No direct mapping! In UA the concept of Alerts can be accomplished by the use of
severity. E.g., Alarms that have a severity below 50 may be considered as Alerts.
Cleared Active = False An Alarm state that indicates the Condition has returned to normal.
An Alarm is disabled when the system is configured such that the Alarm will not be
Disable Enabled = False
generated even though the base Alarm Condition is present.
A request from the control system that the Operator perform some process action
Prompt Dialog
that the system cannot perform or that requires Operator authority to perform.
Raised Active = True An Alarm is Raised or initiated when the Condition creating the Alarm has occurred.
A ‘release’ is a facility that can be applied to a standing (UA = active) Alarm in a similar
way to which Shelving is applied. A released Alarm is temporarily removed from the
Release OneShotShelving Alarm list and put on the shelf. There is no indication to the Operator when the Alarm
clears, but it is taken off the shelf. Hence, when the Alarm is raised again it appears
on the Alarm list in the normal way.
An Alarm is Reset when it is in a state that can be removed from the Display list.
OPC UA includes Retain flag which as part of its definition states: “when a Client
Reset Retain=False receives an Event with the Retain flag set to False, the Client should consider this as
a Condition/Branch that is no longer of interest, in the case of a “current Alarm display”
the Condition/Branch would be removed from the display”
Shelving is a facility where the Operator is able to temporarily prevent an Alarm from
being displayed to the Operator when it is causing the Operator a nuisance. A
Shelving Shelving
Shelved Alarm will be removed from the list and will not re-annunciate until un-
shelved.
An Alarm is Standing whilst the Condition persists (Raised and Standing are often
Standing Active = True
used interchangeably)’.
An Alarm is suppressed when logical criteria are applied to determine that the Alarm
Suppress Suppress should not occur, even though the base Alarm Condition (e.g. Alarm setting
exceeded) is present.
Acknowledged = An Alarm is accepted when the Operator has indicated awareness of its presence. It
Unaccepted
False is unaccepted until this has been done.
Annex D(informative)
Mapping from OPC A&E to OPC UA A&C
D.1 Overview
Serving as a bridge between COM and OPC UA components, the Alarm and Events proxy and
wrapper enable existing A&E COM Clients and Servers to connect to UA Alarms and Conditions
components.
Simply stated, there are two aspects to the migration strategy. Th e first aspect enables a UA
Alarms and Conditions Client to connect to an existing Alarms and Events COM Server via a
UA Server wrapper. This wrapper is notated from this point forward as the A&E COM UA
Wrapper. The second aspect enables an existing Alarms and Events COM Client to connect to
a UA Alarms and Conditions Server via a COM proxy. This proxy is notated from this point
forward as the A&E COM UA Proxy.
An Alarms and Events COM Client is notated from this point forward as A&E COM Client.
A UA Alarms and Conditions Server is notated from this point forward as UA A&C Server.
The mappings describe generic A&E COM interoperability components. It is recommended that
vendors use this mapping if they develop their own components, however, some applica tions
may benefit from vendor specific mappings.
D.2 Alarms and Events COM UA wrapper

D.2.1 Event areas
Event Areas in the A&E COM Server are represented in the A&E COM UA Wrapper as Objects
with a TypeDefinition of BaseObjectType. The EventNotifier Attribute for these Objects always
has the SubscribeToEvents flag set to True.
The root Area is represented by an Object with a BrowseName that depends on the UA Server.
It is always the target of a HasNotifier Reference from the Server Node. The root Area allows
multiple A&E COM Servers to be wrapped within a single UA Server.
The Area hierarchy is discovered with the BrowseOPCAreas and the GetQualifiedAreaName
Methods. The Area name returned by BrowseOPCAreas is used as the BrowseName and
DisplayName for each Area Node. The QualifiedAreaName is used to construct the NodeId. The
NamespaceURI qualifying the NodeId and BrowseName is a unique URI assigned to the
combination of machine and COM Server.
Each Area is the target of HasNotifier Reference from its parent Area. It may be the source of
one or more HasNotifier References to its child Areas. It may also be a source of a
HasEventSource Reference to any sources in the Area.
The A&E COM Server may not support filtering by Areas. If this is the case then no Area Nodes
are shown in the UA Server address space. Some implementations could use the AREAS
Attribute to provide filtering by Areas within the A&E COM UA Wrapper.
D.2.2 Event sources

Event Sources in the A&E COM Server are represented in the A&E COM UA Wrapper as Objects
with a TypeDefinition of BaseObjectType. If the A&E COM Server supports source filtering then
the SubscribeToEvents flag is True and the Source is a target of a HasNotifier Reference. If
source filtering is not supported the SubscribeToEvents flag is False and the Source is a target
of a HasEventSource Reference.
The Sources are discovered by calling BrowseOPCAreas and the GetQualifiedSourceName

Methods. The Source name returned by BrowseOPCAreas is used as the BrowseName and
DisplayName. The QualifiedSourceName is used to construct the NodeId. Event Source Nodes
are always targets of a HasEventSource Reference from an Area.
D.2.3 Event categories

Event Categories in the A&E COM Server are represented in the UA Server as ObjectTypes
which are subtypes of BaseEventType. The BrowseName and DisplayName of the ObjectType
Node for Simple and Tracking Event Types are constructed by appending the text ‘EventType’
to the Description of the Event Category. For Condition Event Types the text ‘AlarmType’ is
appended to the Condition Name.
These ObjectType Nodes have a super type which depends on the A&E Event Type, the Event
Category Description and the Condition Name; however, the best mapping requires knowledge
of the semantics associated with the Event Categories and Condition Names. If an A&E COM
UA Wrapper does not know these semantics then Simple Event Types are subtypes of
BaseEventType, Tracking Event Types are subtypes of AuditEventType and Condition Event
Types are subtypes of the AlarmType. Table D.1 defines mappings for a set of “well known”
Category description and Condition Names to a standard super type.
Table D.1 – Mapping from standard Event categories to OPC UA Event types
COM A&E Event Type Category Description Condition Name OPC UA EventType
Simple --- --- BaseEventType

Simple Device Failure --- DeviceFailureEventType
Simple System Message --- SystemEventType
Tracking --- --- AuditEventType
Condition --- --- AlarmType
Condition Level --- LimitAlarmType
Condition Level PVLEVEL ExclusiveLevelAlarmType
Condition Level SPLEVEL ExclusiveLevelAlarmType
Condition Level HI HI NonExclusiveLevelAlarmType
Condition Level HI NonExclusiveLevelAlarmType
Condition Level LO NonExclusiveLevelAlarmType
Condition Level LO LO NonExclusiveLevelAlarmType
Condition Deviation --- NonExclusiveDeviationAlarmType
Condition Discrete --- DiscreteAlarmType
Condition Discrete CFN OffNormalAlarmType
Condition Discrete TRIP TripAlarmType
There is no generic mapping defined for A&E COM sub-Conditions. If an Event Category is
mapped to a LimitAlarmType then the sub Condition name in the Event are be used to set the
state of a suitable State Variable. For example, if the sub-Condition name is “HI HI” then that
means the HighHigh state for the LimitAlarmType is active
For Condition Event Types the Event Category is also used to define subtypes of
BaseConditionClassType.
Figure D.1 illustrates how ObjectType Nodes created from the Event Categories and Condition
Names are placed in the standard OPC UA HasNotifier hierarchy.
BaseEventType
<CategoryA> <CategoryB>
AuditEventType
EventType EventType
<CategoryC>
EventType
<ConditionNameX>
AlarmType
AlarmType
DeviationAlarmType LevelAlarmType
ExclusiveLimit
AlarmType
<ConditionNameY>
AlarmType
ExclusiveLevel <ConditionNameZ>
AlarmType AlarmType
Figure D.1 – The type model of a wrapped COM AE server
D.2.4 Event attributes

Event Attributes in the A&E COM Server are represented in the UA Server as Variables which
are targets of HasProperty References from the ObjectTypes which represent the Event
Categories. The BrowseName and DisplayName are the description for the Event Attribute. The
data type of the Event Attribute is used to set DataType and ValueRank. The NodeId is
constructed from the EventCategoryId, ConditionName and the AttributeId.
D.2.5 Event subscriptions

The A&E COM UA Wrapper creates a Subscription with the COM AE Server the first time a
MonitoredItem is created for the Server Object or one of the Nodes representing Areas. The
Area filter is set based on the Node being monitored. No other filters are specified.
If all MonitoredItems for an Area are disabled then the Subscription will be deactivated.
The Subscription is deleted when the last MonitoredItem for the Node is deleted.
When filtering by Area the A&E COM UA Wrapper needs to add two Area filters: one based on
the QualifiedAreaName which forms the NodeId and one with the text ‘/*’ appended to it. This
ensures that Events from sub areas are correctly reported by the COM AE Server.
A simple A&E COM UA Wrapper will always request all Attributes for all Event Categories when
creating the Subscription. A more sophisticated wrapper may look at the EventFilter to
determine which Attributes are actually used and only request those.
Table D.2 lists how the fields in the ONEVENTSTRUCT that are used by the A&E COM UA
Wrapper are mapped to UA BaseEventType Variables.
Table D.2 – Mapping from ONEVENTSTRUCT fields to UA BaseEventType Variables
UA Event Variable ONEVENTSTRUCT Notes

Field
szSource A ByteString constructed by appending the fields together.

szConditionName
EventId ftTime
ftActiveTime
dwCookie
dwEventType The NodeId for the corresponding ObjectType Node. The
dwEventCategory szConditionName maybe omitted by some implementations.
EventType
szConditionName
SourceNode szSource The NodeId of the corresponding Source Object Node.
SourceName szSource -
Time ftTime -
ReceiveTime - Set when the Notification is received by the wrapper.
LocalTime - Set based on the clock of the machine running the wrapper.
Message szMessage Locale is the default locale for the COM AE Server.
Severity dwSeverity -
Table D.3 lists how the fields in the ONEVENTSTRUCT that are used by the A&E COM UA
Wrapper are mapped to UA AuditEventType Variables.
Table D.3 – Mapping from ONEVENTSTRUCT fields to UA AuditEventType Variables

Field
ActionTimeStamp ftTime Only set for tracking Events.

Status - Always set to True.
ServerId - Set to the COM AE Server NamespaceURI
ClientAuditEntryId - Not set.
ClientUserId szActorID -
Table D.4 lists how the fields in the ONEVENTSTRUCT that are used by the A& E COM UA
Wrapper are mapped to UA AlarmType Variables.
Table D.4 – Mapping from ONEVENTSTRUCT fields to UA AlarmType Variables

Field
Set to the NodeId of the ConditionClassType for the Event

ConditionClassId dwEventType Category of a Condition Event Type. Set to the NodeId of
BaseConditionClassType Node for non-Condition Event Types.
Set to the BrowseName of the ConditionClassType for the Event
ConditionClassName dwEventType Category of Condition Event Type. To set “BaseConditionClass"
non-Condition Event Types.
ConditionName szConditionName -
BranchId - Always set to NULL.
Set to True if the OPC_CONDITION_ACKED bit is not set or
Retain wNewState
OPC_CONDITION_ACTIVE bit is set.
EnabledState wNewState Set to "Enabled" or "Disabled"
EnabledState.Id wNewState Set to True if OPC_CONDITION_ENABLED is set
A string constructed from the bits in the wNewState flag.
The following rules are applied in order to select the string:
EnabledState. "Disabled" if OPC_CONDITION_ENABLED is not set.
wNewState
EffectiveDisplayName "Unacknowledged" if OPC_CONDITION_ACKED is not set.
"Active" if OPC_CONDITION_ACKED is set.
"Enabled" if OPC_CONDITION_ENABLED is set.
Quality wQuality The COM DA Quality converted to a UA StatusCode.
Set based on the last Event received for the Condition instance.
Severity dwSeverity
Set to the current value if the last Event is not available.
Comment - The value of the ACK_COMMENT Attribute
ClientUserId szActorID -
AckedState wNewState Set to "Acknowledged" or "Unacknowledged "
AckedState.Id wNewState Set to True if OPC_CONDITION_ACKED is set
ActiveState wNewState Set to "Active" or "Inactive "
ActiveState.Id wNewState Set to True if OPC_CONDITION_ACTIVE is set
This time is set when the ActiveState transitions from False to
True.
Note: Additional logic applies to exclusive limit alarms, in that the
LimitState.TransitionTime also needs to be set, but this is set each
time a limit is crossed (multiple limits might exist). For the initial
transition to True the ftActiveTime is used for both
LimitState.TransitionTime and ActiveState.TransitionTime. For
subsequent transition the ActiveState.Transition time does not
ActiveState.TransitionTime ftActiveTime change, but the LimitState.TransitionTime will be updated with the
new ftActiveTime.
For example, if an alarm has Hi and HiHi limits, when the Hi limit
is crossed and the alarm goes active the FTActiveTime is used for
both times, but when the HiHi limit is later crossed, the
FtActiveTime is only be used for the LimitState.TransitionTime.
Note: The ftActiveTime is part of the key for identifying the unique
event in the A&E server and needs to be saved for processing any
commands back to the A&E Server.
The A&C Condition Model defines other optional Variables which are not needed in the A&E
COM UA Wrapper. Any additional fields associated with Event Attributes are also reported.
D.2.6 Condition instances

Condition instances do not appear in the UA Server address space. Conditions can be
acknowledged by passing the EventId to the Acknowledge Method defined on the
AcknowledgeableConditionType.
Conditions cannot be enabled or disabled via the COM A&E Wrapper.

D.2.7 Condition Refresh

The COM A&E Wrapper does not store the state of Conditions. When ConditionRefresh is called
the Refresh Method is called on all COM AE Subscriptions associated with the ConditionRefresh
call. The wrapper needs to wait until it receives the call back with the bLastRefresh flag set to
True in the OnEvent call before it can tell the UA Client that the Refresh has completed.
D.3 Alarms and Events COM UA proxy

D.3.1 General
As illustrated in the figure below, the A&E COM UA Proxy is a COM Server combined with a UA
Client. It maps the Alarms and Conditions address space of UA A&C Server into the appropriate
COM Alarms and Event Objects.
Subclauses D.3.2 through D.3.9 identify the design guidelines and constraints used to develop
the A&E COM UA Proxy provided by the OPC Foundation. In order to maintain a high degree
of consistency and interoperability, it is strongly recommended that vendors, who choose to
implement their own version of the A&E COM UA Proxy, follow these same guidelines and
constraints.
The A&E COM Client simply needs to address how to connect to the UA A&C Server.
Connectivity approaches include the one where A&E COM Clients connect to a UA A&C Server
with a CLSID just as if the target Server were an A&E COM Server. However, the CLSID can
be considered virtual since it is defined to connect to intermediary components that ultimately
connect to the UA A&C Server. Using this approach, the A&E COM Client calls co-create
instance with a virtual CLSID as described above. This connects to the A&E COM UA Proxy
components. The A&E COM UA Proxy then establishes a secure channel and session with the
UA A&C Server. As a result, the A&E COM Client gets a COM Event Server interface pointer.
D.3.2 Server status mapping

The A&E COM UA Proxy reads the UA A&C Server status from the Server Object Variable
Node. Status enumeration values that are returned in ServerStatusDataType structure can be
mapped 1 for 1 to the A&E COM Server status values with the exception of UA A&C Server
status values Unknown and Communication Fault. These both map to the A&E COM Server
status value of Failed.
The VendorInfo string of the A&E COM Server status is mapped from ManufacturerName.
D.3.3 Event Type mapping

Since all Alarms and Conditions Events belong to a subtype of BaseEventType, the A&E COM
UA Proxy maps the subtype as received from the UA A&C Server to one of the three A&E Event
types: Simple, Tracking and Condition. Figure D.2 shows the mapping as follows:
 Those A&C Events which are of subtype AuditEventType are marked as A&E Event type
Tracking.
 Those A&C Events which are ConditionType are marked as A&E Event type Condition.
 Those A&C Events which are of any subtype except AuditEventType or ConditionType
are marked as A&E Event type Simple.
UA Base Event
BaseEvent Types
Type
AuditEvent Condition SystemEvent BaseModelChangeEvent

Type Type Type Type
Mapping of UA Events includes subtypes of each base event type
Tracking Condition Simple
COM Alarm and

Event Types
Figure D.2 – Mapping UA Event Types to COM A&E Event Types
Note that the Event type mapping described above also applies to the children of each subtype.
D.3.4 Event category mapping

Each A&E Event type (e.g. Simple, Tracking, Condition) has an associated set of Event
categories which are intended to define groupings of A&E Events. For example, Level and
Deviation are possible Event categories of the Condition Event type for an A&E COM Server.
However, since A&C does not explicitly support Event categories, the A&E COM UA Proxy uses
A&C Event types to return A&E Event categories to the A&E COM Client. The A&E COM UA
Proxy builds the collection of supported categories by traversing the type definitions in the
address space of the UA A&C Server. Figure D.3 shows the mapping as follows:
 A&E Tracking categories consist of the set of all Event types defined in the hierarchy of
subtypes of AuditEventType and TransitionEventType, including AuditEventType itself
and TransitionEventType itself.
 A&E Condition categories consist of the set of all Event types defined in the hierarchy
of subtypes of ConditionType, including ConditionType itself.
 A&E Simple categories consist of the set of Event types defined in the hierarchy of
subtypes of BaseEventType excluding AuditEventType and ConditionType and their
respective subtypes.
UA Condition Type COM A&E Condition

Hierarchy Type
(partial)
BaseEvent
Type
Condition Event Type
Condition Catergory 1 : ConditionType

Type
Catergory 2 : AcknowledgeableConditionType
Catergory 3 : AlarmConditionType
AcknowledgeableCondition
Type
AlarmCondition
Type
Figure D.3 – Example mapping of UA Event Types to COM A&E categories
Category name is derived from the display name Attribute of the Node type as discovered in
the type hierarchy of the UA A&C Server.
Category description is derived from the description Attribute of the Node type as discovered in
the type hierarchy of the UA A&C Server.
The A&E COM UA Proxy assigns Category IDs.
D.3.5 Event Category attribute mapping

The collection of Attributes associated with any given A&E Event is encapsulated within the
ONEVENTSTRUCT. Therefore, the A&E COM UA Proxy populates the Attribute fields within
the ONEVENTSTRUCT using corresponding values from UA Event Notifications either directly
(e.g., Source, Time, Severity) or indirectly ( e.g., OPC COM Event category determined by way
of the UA Event type). Table D.5 lists the Attributes currently defined in the ONEVENTSTRUCT
in the leftmost column. The rightmost column of Table D.5 indicates how the A&E COM UA
proxy defines that Attribute.
Table D.5 – Event category attribute mapping table
A&E ONEVENTSTRUCT “attribute” A&E COM UA Proxy Mapping

The following items are present for all A&E event types
szSource UA BaseEventType Property: SourceName
ftTime UA BaseEventType Property: Time
szMessage UA BaseEventType Property: Message
dwEventType See Clause D.3.3
dwEventCategory See Clause D.3.4
dwSeverity UA BaseEventType Property: Severity
dwNumEventAttrs Calculated within A&E COM UA Proxy
pEventAttributes Constructed within A&E COM UA Proxy
The following items are present only for A&E Condition-Related Events
szConditionName UA ConditionType Property: ConditionName

szSubConditionName UA ActiveState Property: EffectiveDisplayName
wChangeMask Calculated within Alarms and Events COM UA proxy
wNewState: OPC_CONDITION_ACTIVE A&C AlarmConditionType Property: ActiveState
Note that events mapped as non-Condition Events and those that do not derive
from AlarmConditionType are set to ACTIVE by default.
wNewState: A&C ConditionType Property: EnabledState
OPC_CONDITION_ENABLED Note, Events mapped as non-Condition Events are set to ENABLED (state bit
mask = 0x1) by default.
wNewState: OPC_CONDITION_ACKED A&C AcknowledgeableConditionType Property: AckedState
Note that A&C Events mapped as non-Condition Events or which do not derive
from AcknowledgeableConditionType are set to UNACKNOWLEDGED and
AckRequired = False by default.
wQuality A&C ConditionType Property: Quality
Note that Events mapped as non-Condition Events are set to
OPC_QUALITY_GOOD by default.
In general, the Severity field of the StatusCode is used to map COM status
codes OPC_QUALITY_BAD, OPC_QUALITY_GOOD and
OPC_QUALITY_UNCERTAIN. When possible, specific status' are mapped
directly. These include (UA => COM):
Bad status codes

Bad_ConfigurationError => OPC_QUALITY_CONFIG_ERROR
Bad_NotConnected => OPC_QUALITY_NOT_CONNECTED
Bad_DeviceFailure => OPC_QUALITY_DEVICE_FAILURE
Bad_SensorFailure => OPC_QUALITY_SENSOR_FAILURE
Bad_NoCommunication => OPC_QUALITY_COMM_FAILURE
Bad_OutOfService => OPC_QUALITY_OUT_OF_SERVICE
Uncertain status codes

Uncertain_NoCommunicationLastUsableValue =>
OPC_QUALITY_LAST_USABLE
Uncertain_LastUsableValue => OPC_QUALITY_LAST_USABLE
Uncertain_SensorNotAccurate => OPC_QUALITY_SENSOR_CAL
Uncertain_EngineeringUnitsExceeded =>
OPC_QUALITY_EGU_EXCEEDED
Uncertain_SubNormal => OPC_QUALITY_SUB_NORMAL
Good status codes

Good_LocalOverride => OPC_QUALITY_LOCAL_OVERRIDE
bAckRequired If the ACKNOWLEDGED bit (OPC_CONDITION_ACKED) is set then the Ack
Required Boolean is set to False, otherwise the Ack Required Boolean is set to
True. If the Event is not of type AcknowledgeableConditionType or subtype then
the AckRequired Boolean is set to False.
ftActiveTime If the Event is of type AlarmConditionType or subtype and a transition from
ActiveState of False to ActiveState to True is being processed then the
TransitionTime Property of ActiveState is used. If the Event is not of type
AlarmConditionType or subtype then this field is set to current time.
Note: Additional logic applies to exclusive limit alarms, This value should be
mapped to the LimitState.TransitionTime.
dwCookie Generated by the A&E COM UA Proxy. These unique Condition Event cookies
are not associated with any related identifier from the address space of the UA
A&C Server.
The following is used only for A&E tracking events and for A&E condition-relate events which are acknowledgement
notifications
szActorID

Vendor specific Attributes – ALL
ACK Comment
AREAS All A&E Events are assumed to support the "Areas" Attribute. However, no
Attribute or Property of an A&C Event is available which provides this value.
Therefore, the A&E COM UA Proxy initializes the value of the Areas Attribute
based on the MonitoredItem producing the Event. If the A&E COM Client has
applied no area filtering to a Subscription, the corresponding A&C Subscription
will contain just one MonitoredItem – that of the UA A&C Server Object. Events
forwarded to the A&E COM Client on behalf of this Subscription will carry an
Areas Attribute value of empty string. If the A&E COM Client has applied an
area filter to a Subscription then the related UA A&C Subscription will contain
one or more MonitoredItems for each notifier Node identified by the area
string(s). Events forwarded to the A&E COM Client on behalf of such a
Subscription will carry an areas Attribute whose value is the relative path to the
notifier which produced the Event (i.e., the fully qualified area name).
Vendor specific Attributes – based on category
SubtypeProperty1 All the UA A&C subtype Properties that are not part of the standard set exposed
SubtypePropertyn by BaseEventType or ConditionType
Condition Event instance records are stored locally within the A&E COM UA Proxy. Each record
holds ONEVENTSTRUCT data for each EventSource/Condition instance. When the Condition
instance transitions to the state INACTIVE|ACKED, where AckRequired = True or simply
INACTIVE, where AckRequired = False, the local Condition record is deleted. When a Condition
Event is received from the UA A&C Server and a record for this Event (identified by
source/Condition pair) already exists in the proxy Condition Event store, the existing record is
simply updated to reflect the new state or other change to the Condition, setting the change
mask accordingly and producing an OnEvent callback to any subscribing Clients. In the case
where the Client application acknowledges an Event which is currently unacknowledged
(AckRequired = True), the UA A&C Server Acknowledge Method associated with the Condition
is called and the subsequent Event produced by the UA A&C Server indicating the transition to
acknowledged will result in an update to the current state of the local Condition record as well
as an OnEvent Notification to any subscribing Clients.
The A&E COM UA Proxy maintains the mapping of Attributes on an Event category basis. An
Event category inherits its Attributes from the Properties defined on all supertypes in the UA
Event Type hierarchy. New Attributes are added for any Properties defined on the direct UA
Event type to A&E category mapping. The A&E COM UA Proxy adds two Attributes to each
category: AckComment and Areas. Figure D.4 shows an example of this mapping.
Composite set of UA properties from

UA Condition Type BaseEventType +
Hierarchy ConditionType +
(partial) AcknowleageableConditionType A&E COM UA
Proxy : Mapped
Categories and
BaseEvent Associated
Type
Attributes
Condition
Type

BaseEventType +
ConditionType +
AcknowledgeableCondition AcknowleageableConditionType +
Type AlarmConditionType
AlarmCondition
Type

BaseEventType +
ConditionType
Figure D.4 – Example mapping of UA Event Types to A&E categories with attributes
D.3.6 Event Condition mapping

Events of any subtype of ConditionType are designated COM Condition Events and are subject
to additional processing due to the stateful nature of Condition Events. COM Condition Events
transition between states composed of the triplet ENABLED|ACTIVE|ACKNOWLEDGED. In UA
A&C, Event subtypes of ConditionType only carry a value which can be mapped to ENABLED
(DISABLED) and optionally, depending on further sub typing, may carry additional information
which can be mapped to ACTIVE (INACTIVE) or ACKNOWLEDGED (UNACKNOWLEGED).
Condition Event processing proceeds as described in Table D.5 (see A&E ONEVENTSTRUCT
“Attribute” rows: OPC_CONDITION_ACTIVE, OPC_CONDITION_ENABLED and
OPC_CONDITION_ACKED).
D.3.7 Browse mapping

A&E COM browsing yields a hierarchy of areas and sources. Areas c an contain both sources
and other areas in tree fashion where areas are the branches and sources are the leaves. The
A&E COM UA Proxy relies on the "HasNotifier" Reference to assemble a hierarchy of
branches/areas such that each Object Node which contains a HasNotifier Reference and whose
EventNotifier Attribute is set to SubscribeToEvents is considered an area. The root for the
HasNotifier hierarchy is the Server Object. Starting at the Server Object, HasNotifier
References are followed and each HasNotifier target whose EventNotifier Attribute is set to
SubscribeToEvents becomes a nested COM area within the hierarchy.
Note that the HasNotifier target can also be a HasNotifier source. Further, any Node which is a
HasEventSource source and whose EventNotifier Attribute is set to SubscribeToEvents is also
considered a COM Area. The target Node of any HasEventSource Reference is considered an
A&E COM “source” or leaf in the A&E COM browse tree.
In general, Nodes which are the source Nodes of the HasEventSource Reference and/or are
the source Nodes of the HasNotifier Reference are always A&ECOM Areas. Nodes which are
the target Nodes of the HasEventSource Reference are always A&E COM Sources. Note
however that targets of HasEventSource which cannot be f ound by following the HasNotifier
References from the Server Object are ignored.
Given the above logic, the A&E COM UA Proxy browsing will have the following limitations:
Only those Nodes in the UA A&C Server’s address space which are connected by the
HasNotifier Reference (with exception of those contained within the top level Objects folder)
are considered for area designation. Only those Nodes in the UA A&C Server’s address space
which are connected by the HasEventSource Reference (with exception of those contained
within the top level Objects folder) are considered for area or source designation. To be an
area, a Node shall contain a HasNotifier Reference and its EventNotifier Attribute shall be set
to SubscribeToEvents. To be a source, a Node shall be the target Node of a HasEventSource
Reference and shall have been found by following HasNotifier References from the Server
Object.
D.3.8 Qualified names

D.3.8.1 Qualified name syntax
From the root of any sub tree in the address space of the UA A&C Server, the A&E COM Client
may request the list of areas and/or sources contained within that level. The resultant list of
area names or source names will consist of the set of browse names belonging to those Nodes
which meet the criteria for area or source designation as described above. These names are
"short" names meaning that they are not fully qualified. The A&E COM Client may request the
fully qualified representation of any of the short area or source names. In the case of sources,
the fully qualified source name returned to the A&E COM Client will be the string encoded value
of the NodeId as defined in OPC 10000-6 (e.g., “ns=10;i=859“). In the case of areas, the fully
qualified area name returned to the COM Client will be the relative path to the notifier Node as
defined in OPC 10000-4 (e.g., “/6:Boiler1/6:Pipe100X/1:Input/2:Measurement“). Relative path
indices refer to the namespace table described below.
D.3.8.2 Namespace table

UA Server Namespace table indices may vary over time. This represents a problem for those
A&E COM Clients which cache and reuse fully qualified area names. One solution to this
problem would be to use a qualified name syntax which includes the complete URIs for all
referenced table indices. This however would result in fully qualified area names which are
unwieldy and impractical for use by A&E COM Clients. As an alternative, the A&E COM UA
Proxy will maintain an internal copy of the UA A&C Server's namespace table together with the
locally cached endpoint description. The A&E COM UA Proxy will evaluate the UA A&C Server’s
namespace table at connect time against the cached copy and automatically handle any re -
mapping of indices if required. The A&E COM Client can continue to present cached fully
qualified area names for filter purposes and the A&E COM UA Proxy will ensure these names
continue to reference the same notifier Node even if the Server's namespace table changes
over time.
To implement the relative path, the A&E COM UA Proxy maintains a stack of INode interfaces
of all the Nodes browsed leading to the current level. When the A&E COM Client calls
GetQualifiedAreaName, the A&E COM UA Proxy first validates that the area name provided is
a valid area at the current level. Then looping through the stack, the A&E COM UA Proxy builds
the relative path. Using the browse name of each Node, the A&E COM UA Proxy constructs the
translated name as follows:
QualifiedName translatedName = new QualifiedName(Name,(ushort)

ServerMappingTable[NamespaceIndex]) where
Name – the unqualified browse name of the Node
NamespaceIndex – the Server index

the ServerMappingTable provides the Client namespace index that corresponds to the
Server index.
A ‘/’ is appended to the translated name and the A&E COM UA Proxy continues to loop through
the stack until the relative path is fully constructed .
D.3.9 Subscription filters

D.3.9.1 General
The A&E COM UA Proxy supports all of the d efined A&E COM filter criteria.
D.3.9.2 Filter by Event, category or severity

These filter types are implemented using simple numeric comparisons. For Event filters, the
received Event shall match the Event type(s) specified by the filter. For Category filters, the
received Event’s category (as mapped from UA Event type) shall match the category or
categories specified by the filter. For severity filters, the received Event severity shall be within
the range specified by the Subscription filter.
D.3.9.3 Filter by source

In the case of source filters, the UA A&C Server is free to provide any appropriate, Server-
specific value for SourceName. There is no expectation that source Nodes discovered via
browsing can be matched to the SourceName Property of the Event returned by the UA A&C
Server using string comparisons. Further, the A&E COM Client may receive Events from
sources which are not discoverable by following only HasNotifier and/or HasEventSource
References. Thus, source filters will only apply if the source string can be matched to the
SourceName Property of an Event as received from the target UA A & C Server. Source filter
logic will use the pattern matching rules documented in the A&E COM specification, including
the use of wildcard characters.
D.3.9.4 Filter by area

The A&E COM UA Proxy implements Area filtering by adjusting the set of MonitoredItems
associated with a Subscription. In the simple case where the Client selects no area filter, the
A&E COM UA Proxy will create a UA Subscription which contains just one MonitoredItem, the
Server Object. In doing so, the A&E COM UA Proxy will receive Events from the entire Server
address space – that is, all Areas. The A&E COM Client will discover the areas associated with
the UA Server address space by browsing. The A&E COM Client will use
GetQualifiedAreaName as usual in order to obtain area strings which can be used as filters.
When the A&E COM Client applies one or more of these area strings to the COM Subscription
filter, the A&E COM UA Proxy will create MonitoredItems for each notifier Node identified by
the area string(s). Recall that the fully qualified area name is in fact the namespace qualified
relative path to the associated notifier Node.
The A&E COM UA Proxy calls the TranslateBrowsePathsToNodeIds Service to get the Node
ids of the fully qualified area names in the filter. The Node ids are then added as MonitoredItems
to the UA Subscription maintained by the A&E COM UA Proxy. The A&E COM UA Proxy also
maintains a reference count for each of the areas added, to handle the case of multi ple A&E
COM Subscription applying the same area filter. When the A&E COM Subscriptions are
removed or when the area name is removed from the filter, the ref count on the MonitoredItem
corresponding to the area name is decremented. When the ref count goes t o zero, the
MonitoredItem is removed from the UA Subscription.
As with source filter strings, area filter strings can contain wildcard characters. Area filter strings
which contain wildcard characters require more processing by the A&E COM UA Proxy. When
the A&E COM Client specifies an area filter string containing wildcard characters, the A&E COM
UA Proxy will scan the relative path for path elements that are completely specified. The partial
path containing just those segments which are fully specified re presents the root of the notifier
sub tree of interest. From this sub tree root Node, the A&E COM UA Proxy will collect the list
of notifier Nodes below this point. The relative path associated with each of the collected notifier
Nodes in the sub tree will be matched against the Client supplied relative path containing the
wildcard character. A MonitoredItem is created for each notifier Node in the sub tree whose
relative path matches that of the supplied relative path using established pattern matching rul es.
An area filter string which contains wildcard characters may result in multiple MonitoredItems
added to the UA Subscription. By contrast, an area filter string made up of fully specified path
segments and no wildcard characters will result in one MonitoredItem added to the UA
Subscription. So, the steps involved are:
1) Check if the filter string contains any of these wild card characters, '*', '?', '#', '[', ']', '!', ' -
'.
2) Scan the string for path elements that are completely specified by retrieving the substring
up to the last occurrence of the ‘/’ character.
3) Obtain the NodeId for this path using TranslateBrowsePathsToNodeIds
4) Browse the Node for all notifiers below it.
5) Using the ComUtils.Match() function match the browse names of these notifiers against
the Client supplied string containing the wild card character.
6) Add the Node ids of the notifiers that match as MonitoredItems to the UA Subscription.
Annex E – IEC62682 Mapping

E.1 Overview
This section provides a description of how the IEC 62682 information model can be mapped to
OPC UA. It highlights term differences, concepts and other functionality. IEC 62682 provides
additional information about managing and limiting alarms not covered by this specifi cation.
Note: ISA 18.2 is not discussed by this mapping, but IEC 62682 and ISA 18.2 are related and
most definitions in ISA 18.2 correspond to the definitions in IEC 62682.
E.2 Terms
IEC 62682 defines a large number of terms that are covered by the OPC UA model but not used
in the text. These IEC 62682 terms are listed below and include a description, mapping or
relationship to OPC UA Alarms and Events :
Table E.1 - IEC62682 Mapping
IEC 62682 OPC UA Mapping / IEC 62682 Definition

Related Concept
OPC UA Application of
absolute alarm ExclusiveDeviationAlar An alarm generated when the alarm set point is exceeded.
mType
NonExclusiveDeviation
Both OPC UA models expose a set point and process the
AlarmType
Alarm as an absolute Alarm requires, the only difference is the
interaction between relative states (High, HighHigh...)
adaptive alarm Alarm for which the setpoint is changed by an algorithm (e.g.,
rate based).
In OPC UA adaptive alarming may be part of a vendor

specific alarm application, but it would or could make use
of a number of standard Alarm functions described in this
specification. OPC UA provides limit, rate of change and
deviation alarming. Vendors can easily develop algorithms to
adjust any of the limits that are exposed.
adjustable alarm ExclusiveLimitAlarm An alarm for which the set point can be changed
/ operator-set Type manually by the Operator.
alarm NonExclusiveLimitAlar
mType
Both OPC UA models allow Alarm limits to be writeable
and allow for an Operator to change the limit. For all
changes to limits an audit event should be generated
tracking the change.
advanced A collection of techniques that can help manage

alarming annunciations during specific situations.
In OPC UA advanced alarming may be part of a vendor

specific alarm application, but it would or could make use
of a number of standard Alarm functions described in this
specification, such as adaptive setting of a setpoint for
deviation Alarm. It might also require the definition of
new Alarm sub-types.

Related Concept
Annunciation / Retain A function of the alarm system is to call the attention of

Alarm the Operator to an alarm.
Annunciation
OPC UA provides an Alarm model that includes concepts
such as re-alarming, Alarm silence and Alarm delays, but
it is up to the Client application to make use of these
features to generate both audible and visual
annunciation to the Operator. OPC UA does not provide
visual indication but it does provide priority information
on which the client can be configured to provide the
appropriate visual display. A key concept for alarm
display is the concept of Alarm states and a Retain bit
(see Annex B for more details).
alarm attribute Various Alarm The setting for an alarm within the process control
Properties system.
OPC UA defines a number of Properties that reflect what

would be termed alarm attributes in IEC 62682 such as
Alarm setpoint which maps to the setpoint property in an
ExclusiveDeviationAlarmType.
alarm class ConditionClass, A group of alarms with a common set of alarm

management requirements (e.g., testing, training,
ConditionSubClass monitoring, and audit requirements).
OPC UA provides ConditionClasses, but also provides

other groupings, like ConditionSubClass OPC UA also
specifies a number of predefined classes, but it is
expected that vendors, other standards group or even
end users will define their own extensions to these
classes. The OPC concepts allow Alarms to be
categorized as needed.
alarm Deadband ExclusiveDeviationAl A change in signal from the alarm setpoint necessary for
armType the alarm to return to normal.
NonExclusiveDeviati
onAlarmType
In OPC UA the ExclusiveDeviationAlarmType and
NonExclusiveDeviationAlarmType contain an Alarm
deadband and can be used for the same functionality
described in IEC 62682.
filtering(alarm) Event Subscription A function which selects alarm records to be displayed

according to a given element of the alarm record.
In OPC UA Alarms are received by a Client according to

the specific filter requested by the Client. The filtering
can be very robust or very simple according to the needs
of the client. It is up to the Client application to generate
and provide the appropriate filter to the server. OPC UA’s
Alarm model is a subscription based model, not a push
model that is configured on a server. The choice of filter
is a client’s responsibility.
alarm flood Alarm diagnostics A condition during which the Alarm rate is greater than
the Operator can effectively manage - (e.g., more than
10 Alarms per 10 minutes).

Related Concept
OPC UA does not define Alarm flooding but it does

provide the capability to collect diagnostics that would
allow an engineer to review overall Alarm performance.
alarm group alarm group A set of alarms with common association (e.g., process
unit, process area, equipment set, or service). Alarm
groups are primarily used for display purposes.
OPC UA allows the definition of Alarm groups and the

assignment of Alarms to these groups. In addition. OPC
UA allows Alarms to also be part of a category. OPC UA
also allows Alarms to be organized as a HasNotifier
hierarchy (see clause 6). Groups, categories and
hierarchies can be used for filtering or restricting Alarms
that are being displayed.
alarm history historical events long term repository for alarm records.
OPC 10000-11 describes historical Events.
alarm log short term repository for alarm records.
This part does not specify repositories for Alarms. Alarm

logging is a Client function.
alarm collection of processes and practices for determining,

management documenting, designing, operating, monitoring, and
maintaining alarm systems.
alarm system
management
OPC UA provides an infrastructure to allow vendors and
Operators to provide Alarm management, as such it
should be an integral part of an alarm management
system.
alarm message Events text string displayed with the alarm indication that
provides additional information to the Operator (e.g.,
Operator action).
OPC UA provides an Event structure that includes many

different pieces of information (see OPC 10000-5 for
additional details). Clients can subscribe for as much of
this information as desired and display this as an Alarm
message. All typical fields that would be associated with
an Alarm message are available. In addition OPC UA
provides significant additional information.
alarm priority Priority relative importance assigned to an alarm within the alarm
system to indicate the urgency of response (e.g.,
seriousness of consequences and allowable response
time)
OPC UA provides a Priority Variable as part of the Alarm

Object that provides the same functionality

Related Concept
alarm rate Alarm diagnostics the number of alarm annunciation, per Operator, in a
specific time interval.
OPC UA provides diagnostics allowing the collection of

Alarm rate information at any level in the system.
Record (Alarm) Events, Event a set of information which documents an alarm state
filtering change.
In OPC UA all Alarms are generated as an Event and the

Client can select the fields that are to be included in the
Events. This selection can be customized for each
AlarmConditionType, which allows a customized Alarm
record to be generated.
alarm setpoint, Limit Alarms, the threshold value of a process variable or discrete state
alarm limit, Discrete Alarms that triggers the alarm indication.
alarm trip point
OPC UA supports Alarm limits and setpoints for multiple
Alarm types, including limit Alarms and discrete Alarms.
Sorting (alarm) a function which orders alarm records to be displayed

according to a given element of alarm record.
OPC UA does not provide Alarm sorting as part of an

event subscription. Multiple filtering options are
provided, but the Client is required to perform any
ordering of Alarms.
alarm summary, a display that lists alarm annunciations with selected

alarm list information (e.g., date, time, priority, and alarm type).
In OPC UA Alarm summaries and Alarm lists are Client

functionality and are not specified. Extensive filtering
capabilities are provided by the Server to allow easier
implementation of Alarm summaries or lists by a Client.
Alert An audible and/or visible means of indicating to the

Operator an equipment or process condition that can
require evaluation when time allows.
Alerts are items that should be attended to, but are not
as urgent as Alarms. OPC UA does not differentiate
between Alarms and alerts, but it does provide a full
range of priorities for Alarms. It is up to the end users to
determine what range of priorities are considered an
alert vs an Alarm etc.

Related Concept
allowable The maximum time between the annunciation of the

response time alarm and when the Operator takes corrective action to
avoid the consequence.
OPC UA does not provide any specific fields for

allowable response time, but it does track the times at
which an Alarm occurs and when any actions are taken
on the Alarm.
annunciator device or group of devices that call attention to changes

in process conditions
OPC UA does not define annunciators, this is Client

functionality that can be implemented using OPC UA
Audit comprehensive assessment that includes the evaluation

of alarm system performance and the effectiveness of
the work practices used to administer the alarm system .
OPC UA does provide a number of features that can

facilitate an audit, including diagnostics and audit
events. Do not confuse OPC Audit Event with the IEC
audit concept.
bad- an alarm generated when the signal for a process

measurement measurement is outside the expected range (e.g., 3.8
alarm mA for a 4 mA to 20 mA signal).
A bad measurement Alarm is not defined in OPC UA,

but limit Alarms are defined and they could be used
directly to represent a bad-measurement Alarm.
Alternatively, limit Alarms could be further subtyped to
allow easier filtering on bad-measurement Alarms if
desired.
bit-pattern alarm Discrete alarm an alarm that is generated when a pattern of digital
signals matches a predetermined pattern.
In OPC UA a bit pattern Alarm can be mapped to a

DiscreteAlarmType.
calculated alarm An alarm generated from a calculated value instead of a

direct process measurement.
In OPC UA any of the defined Alarm types can be applied

to calculated values or to process values.

Related Concept
call-out alarm alarm that notifies and informs an Operator by means

other than, or in addition to, a console display (e.g.,
pager or telephone)
OPC UA does not specify call-out alarms, since this is

client functionality. OPC UA does provide the ability to
categorize or group an Alarm such that it could be easily
identified as requiring a different type of annunciation.
chattering alarm OnDelay, OffDelay alarm that repeatedly transitions between the alarm state
and the normal state in a short period of time.
The OPC UA features of OnDelay and OffDelay can be

used to help control chattering Alarms.
classification ConditionClasses the process of separating alarms into alarm classes

based on common requirements (e.g. testing, training,
monitoring, and auditing requirements).
OPC defines a number of extensible ConditionClasses

that can be used for this purpose.
controller-output alarm generated from the output signal of a control

alarm algorithm (e.g., PID controller) instead of a direct
process measurement.
OPC UA does not provide an Alarm type for controller-

output alarm, but a type could be created or an existing
type could be used, depending on the requirements.
dynamic An automatic modification of alarm attributes based on

alarming process state or conditions.
OPC UA does not define dynamic alarming behaviour,

but it allows programmatic access to limits, set points or
other parameters that would be required for a dynamic
alarming solution.
enforcement enhanced alarming technique that can verify and restore

alarm attributes in the control system to the values in the
master alarm database.
OPC UA does not provide enforcement, but it enables

enforcement by providing an information model that
includes default setting for Alarm types as well as original
settings for dynamic Alarms. These features can be used
by a Client application to provide enforcement.
fleeting alarm Suppression, An alarm that transitions between an active alarm state
Shelving and an inactive alarm state in a short period of time.
OPC UA provides Alarm Suppression and Shelving which

an Operator might use to control fleeting Alarms.

Related Concept
first-out alarm FirstInGroup An alarm determined (i.e., by first-out logic) to be the

first-up alarm first, in a multiple-alarm scenario.
FirstInGroupFlag
OPC UA can support first-up/first-out Alarms as part of
the Alarm information model, including definition of the
group of Alarms.
instrument InstrumentDiagnostic An alarm generated by a field device to indicate a fault (e.g.,

diagnostic alarm AlarmType sensor failure).
OPC UA provides support for InstrumentDiagnostic Alarms

that can be used to represent a failed sensor or an instrument
diagnostic.
monitoring Alarm Diagnostics measurement and reporting of quantitative (objective) aspects

of alarm system performance.
OPC UA provides diagnostic collection capabilities that can be

used to measure and reports quantitative information related
to alarm system performance.
nuisance alarm Alarm Diagnostics An alarm that annunciates excessively, unnecessarily, or

does not return to normal after the Operator response is
taken. EXAMPLE: Chattering alarm, fleeting alarm, or
stale alarm.
The OPC UA model provides Alarm Diagnostics for

tracking the information needed to identify if an Alarm is
a nuisance Alarm (i.e. has been in an Alarm state
excessively or does not return to normal).
plant state StateMachines defined set of operational conditions for a process plant.
plant mode
OPC UA provides an example StateMachine (see
Annex F) that can be customized or adapted to provide
process information. This StateMachine could also be
used to affect alarming.
process area Event Hierarchies physical, geographical or logical grouping of resources

determined by the site.
Object References
( OPC 10000-5 )
OPC UA provides multiple manners in which an
information model can be displayed, this includes
grouping objects into process areas or any other desired
grouping. This is an inherent part of the OPC UA
information model.
re-alarming ReAlarmTime alarm that is automatically re-annunciated to the

alarm, re- Operator under certain conditions.
triggering alarm ReAlarmRepeatCoun
t
OPC UA supports re-alarming as part of its base
AlarmConditionType.

Related Concept
recipe-driven StateMachines alarm with setpoints that depend on the recipe that is
alarm currently being executed.
Alarm Limits
OPC UA provides support for adjustable Alarm limits. It

also provides support for programs and other
functionality that could be used to drive recipes. Annex F
provides an example of a StateMachine and how it could
be used to adjust Alarm settings.
Reset LatchedState / Reset Operator action that unlatches a latched alarm.
OPC UA provides an optional StateMachine to indicate

an Alarm is capable of being latched and is in a latched
state. It also provides a Reset Method for clearing the
latched state.
safety related SafetyConditionClas an alarm that is classified as critical to process safety for
alarm sType the protection of human life or the environment.
safety alarm
OPC UA defines a safety ConditionClass for grouping
safety related alarms.
stale alarm Alarm Diagnostics alarm that remains annunciated for an extended period
of time (e.g., 24 hours).
OPC UA Alarm Diagnostics can track the length of time

an Alarm is active.
state-based StateMachine alarm that has attributes modified or is suppressed based

alarm - mode- on operating states or process conditions.
based alarms
OPC UA can provide a system state StateMachine to
support process, device or system states (see Annex F).
With this StateMachine Servers can adjust Alarm
attributes or just Suppress or Disable Alarms based on
the StateMachine. The StateMachine can be applied at
multiple levels in the system.
statistical alarm StatisticalConditionC alarm generated based on statistical processing of a

lassType process variable or variables.
OPC UA provides an Alarm Condition class that any of

the existing AlarmConditionTypes can be assigned to.
This allows any Alarm types, such as limit Alarms, to be
generated by statistical analysis.
Suppress SuppressedOrShelv Any mechanism to prevent the indication of the alarm to

ed the Operator when the base alarm condition is present
(i.e., shelving, suppressed by design, out-of-service).
OPC UA provides a flag SuppressedOrShelved that

matches this functionality.

Related Concept
suppressed by SuppressedState alarm annunciation to the Operator prevented based on

design plant state or other conditions.
OPC UA provides a SuppressedState that matches this

functionality.
system SystemDiagnosticAla alarm generated by the control system to indicate a fault

diagnostic alarm rmType within the system hardware, software or components.
OPC UA defines a system diagnostic Alarm that can be

used to represent faults with system hardware, software
or components.,
The following terms in IEC 62682 match the terms/concepts defined in the OPC UA specification and
do not need any addition mapping or discussion:
 Acknowledge
 Active
 Alarm
 Alarm OffDelay
 Alarm OnDelay
 Alarm Type
 Deviation Alarm
 Discrepancy Alarm
 Event
 Highly Managed Alarm
 LatchingAlarm
 OutofService
 Rateofchange alarms
 Return to normal
 Shelve
 Silence
 Unacknowledged
E.3 Alarm records & State Indications

OPC UA provides all of the items listed as both required and recommended as part of its
alarm definitions, but it is up to the client to subscribe for the information. In OPC UA the
Client controls what alarm information is requested and obtained from the Server. The Server
does not define visual aspects of the alarm system , but does provide priority information from
which the visual aspect can be set on the client side.
OPC UA also supports all of the states described in IEC 62682. This includes tracking the
process states, system states and individual alarm states. OPC UA also provides a
StateMachine model that can be used in conjunction with an alarm system to alter alarm
behaviour based on the state of a system or process. For example , during start-up or
shutdown of a process or a system some alarms might be suppressed.
The behaviour of an OPC UA alarm system also mimic s that required by IEC 62682. All
behaviour described in IEC 62682 can easily be mapped to functionality define in OPC UA
Alarm & Conditions.
Annex F System State (Informative)

F.1 Overview
The state of alarms is affected by the state of the process, equipment, system or plant. For
example, when a tank is taken out of service, the level alarms associated with the tank would
be no longer used, until the tank is returned to service. This section describes a StateMachine
that can be deployed as part of a system designed and used to reflect the current state of the
system, process, equipment or item. Customized version of this model can be implemented for
any system, this sample is just an illustration .
The current state from the StateMachine is applied to all items in the HasNotifier hierarchy
below the object with which the StateMachine is associated. The SystemState StateMachine
can be used to automatically disable, enable, suppress or un-suppress Alarms related to the
Object (with in the hierarchy of alarms from the given object). The StateMachine can also be
used by advanced alarming software to adjust the setpoint, limits or other items related to the
Alarms in the hierarchy.
Optionally, multiple SystemState StateMachines can be deployed.
Operating
Process
Stabilized
Shutdown
Take Out
ShuttingDown Of Service
StartingUp
StartUp Emergency
Shutdown/
Return to Other
Shutdown
Service Initiate Complete
Startup
Shutdown
Isolate
Line Up
System
OutofService
Hand to Hand to
Process Maintenance
Maintenance
Figure F. 1 - SystemState transitions

F.2 SystemStateStateMachineType
The SystemStateStateMachineType includes a hierarchy of sub-states. It supports multiple
transitions between Operating, StartingUp, ShuttingDown, Shutdown, OutOfService and
Maintenance.
The state machine is illustrated in Figure F. 2 and formally defined in Table 51.
StateType
TransitionType
SystemState
StateMachineType
Operating
QuickStart
ShuttingDown
ShutdownToOperating HasCause
StartingUp
Shutdown OutOfService
Shutdown
OutOfService OutofServiceToShutdown
Maintenance HasCause
Quick ShutdownToOutOfService HasCause
Shutdown
HasCause OperatingToShutdown Place
OutOfService
OutofServiceToOperating
ShuttingdownToShutdown HasCause
Stop OperatingToOutofService HasCause
HasCause OperatingToShuttingDown
MaintenanceToOutOfService
HasCause
StartingUpToOperating
OutOfserviceToMaintenance HasCause
Start
HasCause ShutdownToStartingUp Maintain
Figure F. 2 - SystemStateStateMachineType Model

Table F.1 – SystemStateStateMachineType definition
Attribute Value
BrowseName SystemStateStateMachineType
IsAbstract False
References Node BrowseName DataType TypeDefinition Modelling Rule
Class
Subtype of the FiniteStateMachineType defined in OPC
10000-5
HasComponent Object Operating StateType

HasComponent Object ShuttingDown StateType
HasComponent Object StartingUp StateType
HasComponent Object Shutdown StateType
HasComponent Object OutOfService StateType
HasComponent Object Maintenance StateType
HasComponent Object ShutdownToOperating TransitionType

HasComponent Object OperatingToShutdown TransitionType
HasComponent Object ShuttingdownToShutdown TransitionType
HasComponent Object OperatingToShuttingdown TransitionType
HasComponent Object StartingUpToOperating TransitionType
HasComponent Object ShutdownToStartingUp TransitionType
HasComponent Object OutofServiceToShutdown TransitionType
HasComponent Object ShutdownToOutOfService TransitionType
HasComponent Object OutofServiceToOperating TransitionType
HasComponent Object OperatingToOutofService TransitionType
HasComponent Object MaintenanceToOutOfService TransitionType
HasComponent Object OutOfServiceToMaintenance TransitionType
HasComponent Method Start Defined in Clause XXX Optional

HasComponent Method Maintain Defined in Clause XXX Optional
HasComponent Method Stop Defined in Clause XXX Optional
HasComponent Method PlaceOutOfservice Defined in Clause XXX Optional
HasComponent Method QuickShutdown Defined in Clause XXX Optional
HasComponent Method QuickStart Defined in Clause XXX Optional
HasComponent Method OutOfServiceShutdown Defined in Clause XXX Optional
The actual selection of States and Transitions would depend on the deployment of the
StateMachine. If the StateMachine were being applied to a tank or other part of a process it
might have a different set of States then if it was applied to a meter or instrument. The meter
may only have Operating, OutOfService and Maintenance, while the tank may have all of the
described States and Transitions.
The StateMachine supports six possible states including: Operating, ShuttingDown, StartingUp,
Shutdown, OutOfService, Maintenance. It supports 12 possible Transitions and 7 possible
Methods.
Table F.2 - SystemStateStateMachineType transitions
Transitions
ShutdownToOperating FromState Shutdown StateType
ToState Operating StateType
HasCause QuickStart Method
OperatingToShutdown FromState Operating StateType
ToState Shutdown StateType
HasCause QuickShutdown Method
ShuttingdownToShutdown FromState ShuttingDown StateType
OperatingToShuttingdown FromState Operating StateType
ToState ShuttingDown StateType
HasCause Stop Method
StartingUpToOperating FromState StartingUp StateType
ShutdownToStartingUp FromState Shutdown StateType
ToState StartingUp StateType
HasCause Start Method
OutofServiceToShutdown FromState OutOfService StateType
HasCause OutOfServiceShutdown Method
ShutdownToOutOfService FromState Shutdown StateType
ToState OutOfService StateType
HasCause OutOfServiceShutdown Method
OutOfServiceToOperating FromState OutOfService StateType
HasCause PlaceOutOfService Method
OperatingToOutofService FromState Operating StateType
HasCause PlaceOutOfService Method
MaintenanceToOutofService FromState Maintenance StateType
HasCause Maintain Method
OutOfServiceToMaintenance FromState OutOfService StateType
ToState Maintenance StateType
HasCause Maintain Method
The system can always generate additional HasCause References, such as internal code. No
HasEffect References are defined, but an implementation might define HasEffect References
(such as HasEffectDisable) for disabling or enabling Alarms, suppressing Alarms or adjusting
setpoints or limits of Alarms. The targets of the reference might be an individual Alarm or portion
of a plant or piece of equipment. See section 7 for a list of HasEffect References that could be
used.
______________

OPC 10000-9 - UA Specification Part 9 - Alarms and Conditions 1.04

Uploaded by

Copyright:

Available Formats

OPC 10000-9 - UA Specification Part 9 - Alarms and Conditions 1.04

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OPC 10000-9 - UA Specification Part 9 - Alarms and Conditions 1.04

Uploaded by

Copyright:

Available Formats

®

Title: OPC Unified Date: November 22, 2017

Part 9 :Alarms &

Version: Release 1.04 Software: MS-Word

Author: OPC FOUNDATION Status: Release

5.7.3 Acknowledge Method .................................................................................... 30

5.11.4 RefreshRequiredEventType .......................................................................... 64

D.3.1 General ......................................................................................................... 88

Figure 1 – Base Condition state model ................................................................................... 5

Figure B.3 – HasCondition used with Condition instances .................................................... 80

Table 1 – Parameter types defined in Part 3 ........................................................................... 4

Table 34 – Confirm Method AddressSpace definition ............................................................ 32

Table 77 – CertificateExpirationAlarmType definition ............................................................ 55

Copyright © 2006-2018, OPC Foundation, Inc.

WARRANTY AND LIABILITY DISCLAIMERS

RESTRICTED RIGHTS LEGEND

Revision 1.04 Highlights

3239 Silence from IEC62682 Added silence to AlarmConditionType

3444 Missing references in Removed Modelling rules as indicated. Added text to

3452 AuditConditionCommentEventType Updated the name of the field to ConditionEventId

3453 Safety Alarms are common; A Added section on Safety

3716 Definition of SourceNode SourceNode updated to include “Property” when referencing

OPC Unified Architecture Specification

Part 9: Alarms & Conditions

OPC 10000-1, OPC Unified Architecture - Part 1: Overview and Concepts

OPC 10000-3, OPC Unified Architecture - Part 3: Address Space Model

OPC 10000-4, OPC Unified Architecture - Part 4: Services

OPC 10000-5, OPC Unified Architecture - Part 5: Information Model

OPC 10000-6, OPC Unified Architecture - Part 6: Mappings

OPC 10000-7, OPC Unified Architecture - Part 7: Profiles

OPC 10000-8, OPC Unified Architecture - Part 8: Data Access

OPC 10000-11, OPC Unified Architecture - Part 11: Historical Access

ISA 18.2: Management of Alarm Systems for the Process Industries

IETF RFC2045: Multipurpose Internet Mail Extensions (MIME) Part One

IETF RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two

3 Terms, definitions, and abbreviations

3.2 Abbreviations and symbols

Table 1 – Parameter types defined in OPC 10000-3

Table 2 – Parameter types defined in OPC 10000-4

 a temperature exceeding a configured limit

Condition instances are specific implementations of a ConditionType. It is up to the Server

Figure 1 – Base Condition state model

4.3 Acknowledgeable Conditions

AckedState = TRUE AckedState = False

Figure 2 – AcknowledgeableConditions state model

Figure 3 – Acknowledge state model

Figure 4 - Confirmed Acknowledge state model

4.4 Previous states of Conditions

4.5 Condition state synchronization

The following items should be noted with regard to ConditionRefresh:

Suppressed = TRUE Suppressed = False

OutOfService=TRUE OutOfService= False

AckedState = TRUE AckedState = False

Figure 5 – Alarm state machine model

Allowable Response time No Action, Process has

Figure 6 - Typical Alarm Timeline example

4.9 Multiple active states

Figure 7 – Multiple active states example

4.10 Condition instances in the AddressSpace

4.11 Alarm and Condition auditing