IEC 62541-9:2012

IEC 62541-9 ®
Edition 1.0 2012-07
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
OPC unified architecture –
Part 9: Alarms and conditions
Architecture unifiée OPC –
Partie 9: Alarmes et conditions

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester.
If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication,
please contact the address below or your local IEC member National Committee for further information.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les
microfilms, sans l'accord écrit de la CEI ou du Comité national de la CEI du pays du demandeur.
Si vous avez des questions sur le copyright de la CEI ou si vous désirez obtenir des droits supplémentaires sur cette
publication, utilisez les coordonnées ci-après ou contactez le Comité national de la CEI de votre pays de résidence.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00
CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.

Useful links:
IEC publications search - www.iec.ch/searchpub Electropedia - www.electropedia.org
The advanced search enables you to find IEC publications The world's leading online dictionary of electronic and
by a variety of criteria (reference number, text, technical electrical terms containing more than 30 000 terms and
committee,…). definitions in English and French, with equivalent terms in
It also gives information on projects, replaced and additional languages. Also known as the International
withdrawn publications. Electrotechnical Vocabulary (IEV) on-line.

IEC Just Published - webstore.iec.ch/justpublished Customer Service Centre - webstore.iec.ch/csc
Stay up to date on all new IEC publications. Just Published If you wish to give us your feedback on this publication
details all new publications released. Available on-line and or need further assistance, please contact the
also once a month by email. Customer Service Centre: csc@iec.ch.

A propos de la CEI
La Commission Electrotechnique Internationale (CEI) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications CEI
Le contenu technique des publications de la CEI est constamment revu. Veuillez vous assurer que vous possédez
l’édition la plus récente, un corrigendum ou amendement peut avoir été publié.

Liens utiles:
Recherche de publications CEI - www.iec.ch/searchpub Electropedia - www.electropedia.org
La recherche avancée vous permet de trouver des Le premier dictionnaire en ligne au monde de termes
publications CEI en utilisant différents critères (numéro de électroniques et électriques. Il contient plus de 30 000
référence, texte, comité d’études,…). termes et définitions en anglais et en français, ainsi que
Elle donne aussi des informations sur les projets et les les termes équivalents dans les langues additionnelles.
publications remplacées ou retirées. Egalement appelé Vocabulaire Electrotechnique
International (VEI) en ligne.
Just Published CEI - webstore.iec.ch/justpublished
Service Clients - webstore.iec.ch/csc
Restez informé sur les nouvelles publications de la CEI.
Just Published détaille les nouvelles publications parues. Si vous désirez nous donner des commentaires sur
Disponible en ligne et aussi une fois par mois par email. cette publication ou si vous avez des questions
contactez-nous: csc@iec.ch.
IEC 62541-9 ®
Edition 1.0 2012-07
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
OPC unified architecture –
Part 9: Alarms and conditions
Architecture unifiée OPC –
Partie 9: Alarmes et conditions

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
PRICE CODE
INTERNATIONALE
CODE PRIX XD
ICS 25.040.40; 25.100.01 ISBN 978-2-83220-286-9

– 2 – 62541-9 © IEC:2012
CONTENTS
FOREWORD . 7
INTRODUCTION . 9
1 Scope . 10
2 Normative references . 10
3 Terms, definitions, abbreviations and data types . 10
3.1 Terms and definitions . 10
3.2 Abbreviations . 12
3.3 Used data types . 12
4 Concepts . 12
4.1 General . 12
4.2 Conditions . 13
4.3 Acknowledgeable Conditions . 14
4.4 Previous States of Conditions . 16
4.5 Condition State Synchronization . 16
4.6 Severity, Quality and Comment . 17
4.7 Dialogs . 17
4.8 Alarms . 17
4.9 Multiple Active States . 18
4.10 Condition Instances in the Address Space . 19
4.11 Alarm and Condition Auditing . 20
5 Model . 20
5.1 General . 20
5.2 Two-State State Machines . 21
5.3 Condition Variables . 23
5.4 Substate Reference Types . 23
5.4.1 General . 23
5.4.2 HasTrueSubState ReferenceType . 23
5.4.3 HasFalseSubState ReferenceType . 24
5.5 Condition Model . 24
5.5.1 General . 24
5.5.2 ConditionType . 25
5.5.3 Condition and Branch Instances . 28
5.5.4 Disable Method . 28
5.5.5 Enable Method . 29
5.5.6 AddComment Method . 29
5.5.7 ConditionRefresh Method . 30
5.6 Dialog Model . 32
5.6.1 General . 32
5.6.2 DialogConditionType . 32
5.6.3 Respond Method . 34
5.7 Acknowledgeable Condition Model . 34
5.7.1 General . 34
5.7.2 AcknowledgeableConditionType . 34
5.7.3 Acknowledge Method . 36
5.7.4 Confirm Method . 37

62541-9 © IEC:2012 – 3 –
5.8 Alarm Model . 38
5.8.1 General . 38
5.8.2 AlarmConditionType . 38
5.8.3 ShelvedStateMachineType . 40
5.8.4 Unshelve Method . 43
5.8.5 TimedShelve Method . 44
5.8.6 OneShotShelve Method . 44
5.8.7 LimitAlarmType . 45
5.8.8 ExclusiveLimit Types . 46
5.8.9 NonExclusiveLimitAlarmType. 49
5.8.10 Level Alarm . 51
5.8.11 Deviation Alarm . 52
5.8.12 Rate of Change . 53
5.8.13 Discrete Alarms . 54
5.9 ConditionClasses . 56
5.9.1 Overview . 56
5.9.2 Base ConditionClassType . 56
5.9.3 ProcessConditionClassType . 56
5.9.4 MaintenanceConditionClassType . 57
5.9.5 SystemConditionClassType . 57
5.10 Audit Events . 57
5.10.1 Overview . 57
5.10.2 AuditConditionEventType . 58
5.10.3 AuditConditionEnableEventType . 58
5.10.4 AuditConditionCommentEventType . 59
5.10.5 AuditConditionRespondEventType . 59
5.10.6 AuditConditionAcknowledgeEventType . 59
5.10.7 AuditConditionConfirmEventType . 59
5.10.8 AuditConditionShelvingEventType . 59
5.11 Condition Refresh Related Events . 60
5.11.1 Overview . 60
5.11.2 RefreshStartEventType . 60
5.11.3 RefreshEndEventType . 60
5.11.4 RefreshRequiredEventType . 61
5.12 HasCondition Reference Type . 61
5.13 Alarm and Condition Status Codes . 62
6 AddressSpace Organisation . 62
6.1 General . 62
6.2 Event Notifier and Source Hierarchy . 62
6.3 Adding Conditions to the Hierarchy . 63
6.4 Conditions in InstanceDeclarations . 64
6.5 Conditions in a VariableType . 65
Annex A (informative) Recommended Localized Names . 66
Annex B (informative) Examples . 69
Annex C (informative) Mapping to EEMUA . 74
Annex D (informative) Mapping from OPC A&E to OPC UA A&C . 75
Bibliography . 89

– 4 – 62541-9 © IEC:2012
Figure 1 – Base Condition State Model . 14
Figure 2 – AcknowledgeableConditions State Model . 14
Figure 3 – Acknowledge State Model . 15
Figure 4 – Confirmed Acknowledge State Model . 16
Figure 5 – Alarm State Machine Model. 18
Figure 6 – Multiple Active States Example . 19
Figure 7 – ConditionType Hierarchy . 21
Figure 8 – Condition Model . 25
Figure 9 – DialogConditionType Overview. 32
Figure 10 – AcknowledgeableConditionType Overview . 35
Figure 11 – AlarmConditionType Hierarchy Model . 38
Figure 12 – Alarm Model . 39
Figure 13 – Shelve state transitions . 41
Figure 14 – Shelved State Machine Model . 41
Figure 15 – LimitAlarmType . 45
Figure 16 – ExclusiveLimitStateMachine . 47
Figure 17 – ExclusiveLimitAlarmType . 49
Figure 18 – NonExclusiveLimitAlarmType . 50
Figure 19 – DiscreteAlarmType Hierarchy . 54
Figure 20 – ConditionClass Type Hierarchy . 56
Figure 21 – AuditEvent Hierarchy. 58
Figure 22 – Refresh Related Event Hierarchy . 60
Figure 23 – Typical Event Hierarchy . 63
Figure 24 – Use of HasCondition in an Event Hierarchy . 64
Figure 25 – Use of HasCondition in an InstanceDeclaration . 65
Figure 26 – Use of HasCondition in a VariableType . 65
Figure B.1 – Single State Example . 69
Figure B.2 – Previous State Example . 70
Figure B.3 – HasCondition used with Condition instances . 72
Figure B.4 – HasCondition reference to a Condition Type . 73
Figure B.5 – HasCondition used with an instance declaration . 73
Figure D.1 – The Type Model of a Wrapped COM AE Server . 77
Figure D.2 – Mapping UA Event Types to COM A&E Event Types . 81
Figure D.3 – Example Mapping of UA Event Types to COM A&E Categories . 82
Figure D.4 – Example Mapping of UA Event Types to A&E Categories with Attributes . 85

Table 1 – Parameter Types defined in IEC 62541-3 . 12
Table 2 – Parameter Types defined in IEC 62541-4 . 12
Table 3 – TwoStateVariableType Definition . 22
Table 4 – ConditionVariableType Definition. 23
Table 5 – HasTrueSubState ReferenceType . 24
Table 6 – HasFalseSubState ReferenceType . 24
Table 7 – ConditionType Definition . 26

62541-9 © IEC:2012 – 5 –
Table 8 – SimpleAttributeOperand to select ConditionId. 28
Table 9 – Disable Method AddressSpace Definition . 29
Table 10 – Enable Method AddressSpace Definition . 29
Table 11 – AddComment Method AddressSpace Definition . 30
Table 12 – ConditionRefresh Method AddressSpace Definition . 32
Table 13 – DialogConditionType Definition. 33
Table 14 – Respond Method AddressSpace Definition . 34
Table 15 – AcknowledgeableConditionType Definition . 35
Table 16 – Acknowledge Method AddressSpace Definition . 37
Table 17 – Confirm Method Parameters . 37
Table 18 – Confirm Method AddressSpace Definition . 38
Table 19 – AlarmConditionType Definition . 39
Table 20 – ShelvedStateMachine Definition . 42
Table 21 – ShelvedStateMachine Transitions . 43
Table 22 – Unshelve Method AddressSpace Definition . 44
Table 23 – TimedShelve Method AddressSpace Definition . 44
Table 24 – OneShotShelve Method AddressSpace Definition . 45
Table 25 – LimitAlarmType Definition . 46
Table 26 – ExclusiveLimitStateMachineType Definition . 47
Table 27 – ExclusiveLimitStateMachineType Transitions . 48
Table 28 – ExclusiveLimitAlarmType Definition . 49
Table 29 – NonExclusiveLimitAlarmType Definition . 51
Table 30 – NonExclusiveLevelAlarmType Definition . 52
Table 31 – ExclusiveLevelAlarmType Definition . 52
Table 32 – NonExclusiveDeviationAlarmType Definition . 53
Table 33 – ExclusiveDeviationAlarmType Definition . 53
Table 34 – NonExclusiveRateOfChangeAlarmType Definition . 54
Table 35 – ExclusiveRateOfChangeAlarmType Definition . 54
Table 36 – DiscreteAlarmType Definition . 55
Table 37 – OffNormalAlarmType Definition . 55
Table 38 – TripAlarmType Definition . 55
Table 39 – BaseConditionClassType Definition . 56
Table 40 – ProcessConditionClassType Definition . 57
Table 41 – MaintenanceConditionClassType Definition . 57
Table 42 – SystemConditionClassType Definition . 57
Table 43 – AuditConditionEventType Definition . 58
Table 44 – AuditConditionEnableEventType Definition . 58
Table 45 – AuditConditionCommentEventType Definition . 59
Table 46 – AuditConditionRespondEventType Definition . 59
Table 47 – AuditConditionAcknowledgeEventType Definition . 59
Table 48 – AuditConditionConfirmEventType Definition . 59
Table 49 – AuditConditionShelvingEventType Definition . 59
Table 50 – RefreshStartEventType Definition . 60

– 6 – 62541-9 © IEC:2012
Table 51 – RefreshEndEventType Definition . 60
Table 52 – RefreshRequiredEventType Definition . 61
Table 53 – HasCondition ReferenceType . 61
Table 54 – Alarm and Condition Result Codes . 62
Table A.1 – Recommended state names for LocaleId “en” . 66
Table A.2 – Recommended display names for LocaleId “en” . 66
Table A.3 – Recommended state names for LocaleId “de” . 67
Table A.4 – Recommended display names for LocaleId “de” . 67
Table A.5 – Recommended state names for LocaleId “fr” . 67
Table A.6 – Recommended display names for LocaleId “fr” . 68
Table A.7 – Recommended Dialog Response Options . 68
Table B.1 – Example of a Condition that only keeps the latest state . 69
Table B.2 – Example of a Condition that maintains previous states via branches . 71
Table C.1 – EEMUA Terms . 74
Table D.1 – Mapping from ONEVENTSTRUCT fields to UA BaseEventType Variables . 78
Table D.2 – Mapping from ONEVENTSTRUCT fields to UA AuditEventType Variables . 78
Table D.3 – Mapping from ONEVENTSTRUCT fields to UA AlarmType Variables . 79
Table D.4 – Event Category Attribute Mapping Table . 83

62541-9 © IEC:2012 – 7 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
OPC UNIFIED ARCHITECTURE –
Part 9: Alarms and conditions
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62541-9 has been prepared by subcommittee 65E: Devices and
integration in enterprise systems, of IEC technical committee 65: Industrial-process
measurement, control and automation.
The text of this standard is based on the following documents:
FDIS Report on voting
65E/243/FDIS 65E/268/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
A list of all parts of the IEC 62541 series, published under the general title OPC unified
architecture, can be found on the IEC website.

– 8 – 62541-9 © IEC:2012
The committee has decided that the contents of this publication will remain unchanged until
the stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data
related to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
62541-9 © IEC:2012 – 9 –
INTRODUCTION
This International Standard is a specification intended for developers of OPC UA applications.
The specification is a result of an analysis and design process to develop a standard interface
to facilitate the development of applications by multiple vendors that inter-operate seamlessly
together.
– 10 – 62541-9 © IEC:2012
OPC UNIFIED ARCHITECTURE –
Part 9: Alarms and conditions
1 Scope
This part of the IEC 62541 series 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.
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) applies.
IEC/TR 62541-1, OPC Unified Architecture – Part 1: Overview and Concepts
IEC 62541-3, OPC unified architecture – Part 3: Address Space Model
IEC 62541-4, OPC unified architecture – Part 4: Services
IEC 62541-5, OPC unified architecure – Part 5: Information Model
IEC 62541-6, OPC unified architecure – Part 6: Mappings
IEC 62541-8, OPC unified architecture – Part 8: Data Access
EEMUA 191:2007, Alarm Systems – A guide to design, management and procurement,
available at
3 Terms, definitions, abbreviations and data types
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 62541-1,
IEC 62541-3 and IEC 62541-5 as well as the following apply.
3.1.1
Acknowledge
operator action that indicates recognition of a new Alarm
Note 1 to entry: As defined in 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 represents 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.

62541-9 © IEC:2012 – 11 –
3.1.3
ConditionClass
a 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.4
ConditionBranch
a 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.5
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.6
Confirm
operator action informing the Server that a corrective action has been taken to address the
cause of the Alarm
3.1.7
Disable
system is configured such that the Alarm will not be generated even though the base Alarm
Condition is present
Note 1 to entry: As defined in EEMUA.
3.1.8
Operator
special user who is assigned to monitor and control a portion of the 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 specification an Operator is a special
user. All descriptions that apply to general users also apply to Operators.
3.1.9
Refresh
an update to an Event Subscription that provides all Alarms which are considered to be
Retained
Note 1 to entry: This concept is further described in EEMUA.
3.1.10
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.11
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

– 12 – 62541-9 © IEC:2012
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.12
Suppress
logical criterion to determine that the Alarm does 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.
3.2 Abbreviations
A&C Alarms and Conditions
A&E Alarms and Events
DA Data Access
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 IEC 62541-3 are in Table 1.
The base types and data types defined in IEC 62541-4 are in Table 2.
Table 1 – Parameter Types defined in IEC 62541-3
Parameter Type
Argument
BaseDataType
NodeId
LocalizedText
Boolean
ByteString
Double
Duration
String
UInt16
Int32
UtcTime
Table 2 – Parameter Types defined in IEC 62541-4
Parameter Type
IntegerId
StatusCode
4 Concepts
4.1 General
This specification defines an Information Model for Conditions, Dialog Conditions, and Alarms
including acknowledgement capabilities. It is built upon and extends base eventing which is
defined in IEC 62541-3, IEC 62541-4 and IEC 62541-5. This Information Model can also be
extended to support the additional needs of specific domains.

62541-9 © IEC:2012 – 13 –
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 subtypes of the BaseEventType (see IEC 62541-3 and IEC 62541-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. Subclause 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 of 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. Subclause 4.4 provides more information and use cases. Maintaining previous
states and therefore also 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 specification 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.
– 14 – 62541-9 © IEC:2012
Disabled
Enabled
IEC  1476/12
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.
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.
4.3 Acknowledgeable Conditions
AcknowledgeableConditions are subtypes of the base ConditionType. Acknowledge-
ableConditions expose states to indicate whether a Condition has to be acknowledged or
confirmed.
An AckedState and a ConfirmedState extend the Enabled state 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
= FALSE
= TRUE
IEC  1477/12
Figure 2 – AcknowledgeableConditions State Model

62541-9 © IEC:2012 – 15 –
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 specification. 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
inactive.
AckedState = TRUE
Ack
Acknowledge
By
Method
Server
AckedState = FALSE
IEC
...