EN 62541-9:2012

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Enotna arhitektura OPC - 9. del: Alarmi in pogoji (IEC 62541-9:2012)OPC Unified Architecture - Teil 9: Alarme und Zustände (IEC 62541-9:2012)Architecture unifiée OPC - Partie 9: Alarmes et conditions (CEI 62541-9:2012)OPC Unified Architecture - Part 9: Alarms and Conditions (IEC 62541-9:2012)35.240.50Uporabniške rešitve IT v industrijiIT applications in industry25.040.40Merjenje in krmiljenje industrijskih postopkovIndustrial process measurement and controlICS:Ta slovenski standard je istoveten z:EN 62541-9:2012SIST EN 62541-9:2012en01-november-2012SIST EN 62541-9:2012SLOVENSKI
STANDARD
EUROPEAN STANDARD EN 62541-9 NORME EUROPÉENNE
EUROPÄISCHE NORM September 2012
CENELEC European Committee for Electrotechnical Standardization Comité Européen de Normalisation Electrotechnique Europäisches Komitee für Elektrotechnische Normung
Management Centre: Avenue Marnix 17, B - 1000 Brussels
© 2012 CENELEC -
All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. EN 62541-9:2012 E
ICS 25.040.40; 25.100.01
English version
OPC unified architecture -
Part 9: Alarms and conditions (IEC 62541-9:2012)
Architecture unifiée OPC -
Partie 9: Alarmes et conditions (CEI 62541-9:2012)
OPC Unified Architecture -
Teil 9: Alarme und Zustände (IEC 62541-9:2012)
This European Standard was approved by CENELEC on 2012-08-31. CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.
The following dates are fixed: • latest date by which the document has to be implemented at national level by publication of an identical national standard or by endorsement (dop) 2013-05-31 • latest date by which the national standards conflicting with the document have to be withdrawn (dow) 2015-08-31
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CENELEC [and/or CEN] shall not be held responsible for identifying any or all such patent rights.
Endorsement notice The text of the International Standard IEC 62541-9:2012 was approved by CENELEC as a European Standard without any modification. In the official version, for Bibliography, the following note has to be added for the standard indicated :
IEC 62541-7 NOTE Harmonised as EN 62541-7.
- 3 - EN 62541-9:2012 Annex ZA
(normative)
Normative references to international publications with their corresponding European publications
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.
NOTE
When an international publication has been modified by common modifications, indicated by (mod), the relevant EN/HD applies.
Publication Year Title EN/HD Year
IEC/TR 62541-1 - OPC unified architecture -
Part 1: Overview and concepts CLC/TR 62541-1 -
IEC 62541-3 - OPC unified architecture -
Part 3: Address space model EN 62541-3 -
IEC 62541-4 - OPC unified architecture -
Part 4: Services EN 62541-4 -
IEC 62541-5 - OPC unified architecture -
Part 5: Information model EN 62541-5 -
IEC 62541-6 - OPC unified architecture -
Part 6: Mappings EN 62541-6 -
IEC 62541-8 - OPC unified architecture -
Part 8: Data access EN 62541-8 -
EEMUA 191 2007 Alarm systems - A guide to design, management and procurement - -
IEC 62541-9 Edition 1.0 2012-07 INTERNATIONAL STANDARD NORME INTERNATIONALE OPC unified architecture –
Part 9: Alarms and conditions
Architecture unifiée OPC –
Partie 9: Alarmes et conditions
INTERNATIONAL ELECTROTECHNICAL COMMISSION COMMISSION ELECTROTECHNIQUE INTERNATIONALE XD ICS 25.040.40; 25.100.01 PRICE CODE CODE PRIX 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 SIST EN 62541-9:2012

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 SIST EN 62541-9:2012

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 SIST EN 62541-9:2012

– 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. SIST EN 62541-9:2012

– 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. SIST EN 62541-9:2012

– 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. SIST EN 62541-9:2012

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 SIST EN 62541-9:2012

– 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. SIST EN 62541-9:2012

– 14 – 62541-9 © IEC:2012
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.
Figure 2 – AcknowledgeableConditions State Model Disabled
Enabled Disabled Enabled ConfirmedState = TRUE
AckedState = TRUE ConfirmedState = FALSE AckedState = FALSE IEC
1476/12 IEC
1477/12 SIST EN 62541-9:2012
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.
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.
AckedState = TRUE AckedState = FALSE Ack By Server Acknowledge
Method IEC
1478/12 SIST EN 62541-9:2012
– 16 – 62541-9 © IEC:2012
Figure 4 – Confirmed Acknowledge State Model 4.4 Previous States of Conditions Some systems require that previous states of
...