Figure1_

 

 

 

Figure9_

 

     OPC UA Specification

OPC 10000-9

 

OPC Unified Architecture

Part 9: Alarms & Conditions

 

 

Release 1.04

November 22, 2017

 

 

 

 

 

 

 


Specification Type:

Industry Standard Specification

Comments:

 

 

 

 

 

 

 

 

Title:

OPC Unified Architecture

Part 9 :Alarms & Conditions

Date:

November 22, 2017

 

 

 

 

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

 

 

 

 

 


 

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

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

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

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 InstanceDeclaration....................... 68

Figure 27 – Use of HasCondition in a VariableType.................................. 69

Figure B.1 – Single state example........................................................ 78

Figure B.2 – Previous state example..................................................... 79

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

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

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

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 FOUNDATION

____________

 

UNIFIED ARCHITECTURE –

FOREWORD

This specification is the specification 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 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
HTUhttp://www.opcfoundation.orgUTH.

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 are 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 LOSS 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 software 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.

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: HTUhttp://www.opcfoundation.org/errataUTH

 


Revision 1.04 Highlights

The following table includes the Mantis issues resolved with this revision.

Mantis ID

Summary

Resolution

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 formatting of the third paragraph is broken

Fixed formatting (also fixed other format and link issues)

3380

IEC 62682 - Additional Alarm types

Added Discrepancy Alarms, Deviation Alarm uses

3444

Missing references in Opc.Ua.NodeSet2.xml

Removed Modelling rules as indicated.  Added text to 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 EventId field should be AffectedEventId

Updated the name of the field to ConditionEventId

3453

Safety Alarms are common; A Safety ConditionClass would be useful.

Added section on Safety

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 TransitionTime is not accurate.

Added text to limit scope of assignment in wrapper code 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 they interact with ConditionBranches

The specification already described Enable with regard to branches, but the disable was updated to indicate all branches are disabled..

4021

Alarms in AddressSpace - Clarify behaviour when properties change

Updated text to indicate what is required and what is server specific behaviour

 

 

 

 


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

http://www.opcfoundation.org/UA/Part3/

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

http://www.opcfoundation.org/UA/Part4/

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

http://www.opcfoundation.org/UA/Part5/

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

http://www.opcfoundation.org/UA/Part6/

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

http://www.opcfoundation.org/UA/Part7/

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

http://www.opcfoundation.org/UA/Part8/            

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

http://www.opcfoundation.org/UA/Part11/

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

 

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

https://www.ietf.org/rfc/rfc2046.txt

IETF RFC2047: Multipurpose Internet Mail Extensions (MIME) Part Three

https://www.ietf.org/rfc/rfc2047.txt

         

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 conditions 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 designed 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 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. 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.

Figure2_

 

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.

Figure6_

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.

Figure5_

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.

Figure7_

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 previous 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. This 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.

Figure3_

 

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

Figure10_

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.

Figure4_

 

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

.

Figure11_

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

 

 

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 state, 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 that 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

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling
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

References

NodeClass

BrowseName

Comment

 

 

 

 

 

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

References

NodeClass

BrowseName

Comment

 

 

 

 

 

 

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

References

NodeClass

BrowseName

Comment

 

 

 

 

 

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.

Figure12_

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

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseEventType defined in OPC 10000-5

HasSubtype

ObjectType

DialogConditionType

Defined in Clause 5.6.2

HasSubtype

ObjectType

AcknowledgeableConditionType

Defined in Clause 5.7.2

 

 

 

 

 

 

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

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionEnableEventType

Defined in 5.10.2

 

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 Servers do not expose Condition instances in the AddressSpace. Therefore, all Servers shall 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

Result Code

Description

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

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

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.

 

Method result codes in Table 16 (defined in Call Service)

Table 16 – AddComment result codes

Result Code

Description

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

AuditConditionCommentEventType

Defined in 5.10.4

 

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

   );

 

The parameters are defined in Table 18

Table 18 – ConditionRefresh parameters

Argument

Description

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.

 

Method result codes in Table 19 (defined in Call Service)

Table 19 – ConditionRefresh result codes

Result Code

Description

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

See OPC 10000-4 for the general 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 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

 

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

 

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

 

AlwaysGeneratesEvent

ObjectType

RefreshStartEventType

Defined in 5.11.2

AlwaysGeneratesEvent

ObjectType

RefreshEndEventType

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

   );

 

The parameters are defined in Table 18

Table 21 – ConditionRefresh2 parameters

Argument

Description

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.

 

Method result codes in Table 19 (defined in Call Service)

Table 22 – ConditionRefresh2 result codes

Result Code

Description

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

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

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

 

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

 

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

 

AlwaysGeneratesEvent

ObjectType

RefreshStartEventType

Defined in 5.11.2

AlwaysGeneratesEvent

ObjectType

RefreshEndEventType

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.

Figure13_

Figure 10 - DialogConditionType Overview

Table 24 – DialogConditionType Definition

Attribute

Value

BrowseName

DialogConditionType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling
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

   );

The parameters are defined in Table 25

Table 25 – Respond parameters

Argument

Description

SelectedResponse

Selected index of the ResponseOptionSet array.

 

Method result codes in Table 26 (defined in Call Service)

Table 26 – Respond Result Codes

Result Code

Description

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

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

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.

Figure14_

Figure 11 – AcknowledgeableConditionType overview

Table 28 – AcknowledgeableConditionType definition

Attribute

Value

BrowseName

AcknowledgeableConditionType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

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 acknowledged. 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(

   [in] ByteString EventId

   [in] LocalizedText Comment

   );

The parameters are defined in Table 29

Table 29 – Acknowledge parameters

Argument

Description

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.

 

Method result codes in Table 30 (defined in Call Service)

Table 30 – Acknowledge result codes

Result Code

Description

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_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

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

 

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

AuditConditionAcknowledge

EventType

Defined in 5.10.5

 

 

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(

   [in] ByteString       EventId

   [in] LocalizedText    Comment

   );

The parameters are defined in Table 32

Table 32 – Confirm Method parameters

Argument

Description

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.

 

Method result codes in Table 33 (defined in Call Service)

Table 33 – Confirm result codes

Result Code

Description

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.

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_NodeIdUnknown

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

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

AuditConditionConfirmEventType

Defined in 5.10.7

 

 

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.

Figure15_

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 definition. It is formally defined in Table 35.

Figure16_

Figure 13 – Alarm Model

Table 35 – AlarmConditionType definition

Attribute

Value

BrowseName

AlarmConditionType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of the AcknowledgeableConditionType defined in clause 5.7.2

HasComponent

Variable

ActiveState

LocalizedText

TwoStateVariableType

Mandatory

HasProperty

Variable

InputNode

NodeId

PropertyType

Mandatory

HasComponent

Variable

SuppressedState

LocalizedText

TwoStateVariableType

Optional

HasComponent

Variable

OutOfServiceState

LocalizedText

TwoStateVariableType

Optional

HasComponent

Object

ShelvingState

 

ShelvedStateMachineType

Optional

HasProperty

Variable

SuppressedOrShelved

Boolean

PropertyType

Mandatory

HasProperty

Variable

MaxTimeShelved

Duration

PropertyType

Optional

 

 

 

 

 

 

HasProperty

Variable

AudibleEnabled

Boolean

PropertyType

Optional

HasProperty

Variable

AudibleSound

AudioDataType

AudioVariableType

Optional

HasComponent

Variable

SilenceState

LocalizedText

TwoStateVariableType

Optional

 

 

 

 

 

 

HasProperty

Variable

OnDelay

Duration

PropertyType

Optional

HasProperty

Variable

OffDelay

Duration

PropertyType

Optional

 

 

 

 

 

 

HasComponent

Variable

FirstInGroupFlag

Boolean

BaseDataVariableType

Optional

HasComponent

Object

FirstInGroup

 

AlarmGroupType

Optional

HasComponent

Variable

LatchedState

LocalizedText

TwoStateVariableType

Optional

 

 

 

 

 

 

HasAlarmSuppressionGroup

Object

<AlarmGroup>

 

AlarmGroupType

OptionalPlaceholder

 

 

 

 

 

 

HasProperty

Variable

ReAlarmTime

Duration

PropertyType

Optional

HasComponent

Variable

ReAlarmRepeatCount

Int16

BaseDataVariableType

Optional

 

 

 

 

 

 

HasComponent

Method

Silence

Defined in  5.8.5

Optional

HasComponent

Method

Suppress

Defined in 5.8.6

Optional

HasComponent

Method

Unsuppress

Defined in 5.8.7

Optional

HasComponent

Method

RemoveFromService

Defined in 5.8.8

Optional

HasComponent

Method

PlaceInService

Defined in 5.8.9

Optional

HasComponent

Method

Reset

Defined in 5.8.4

Optional

 

 

 

 

 

HasSubtype

ObjectType

DiscreteAlarmType

 

 

 

HasSubtype

ObjectType

LimitAlarmType

 

 

 

HasSubtype

ObjectType

DiscrepancyAlarmType

 

 

 

 

 

 

 

 

 

 

The 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 sensors 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 identifying related Alarms. The actual usage of the AlarmGroupType is specified where it is used.

Table 36 – AlarmGroupType Definition

Attribute

Value

BrowseName

AlarmGroupType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling
Rule

Subtype of the FolderType defined in OPC 10000-5

AlarmGroupMember

Object

<AlarmConditionInstance>

 

AlarmConditionType

OptionalPlaceholder

 

 

 

 

 

 

 

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();

 

The parameters are defined in Table 40

Table 37 – Reset arguments

Argument

Description

 

 

Method result codes in Table 41 (defined in Call service)

Table 38 – Silence result codes

Result Code

Description

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

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

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

 

 

 

 

 

 

 

 

AlwaysGeneratesEvent

ObjectType

AuditConditionResetEventType

Defined in 5.10.11

 

 

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();

 

The parameters are defined in Table 40

Table 40 – Silence arguments

Argument

Description

 

 

Method result codes in Table 41 (defined in Call service)

Table 41 – Silence result codes

Result Code

Description

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_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

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

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

 

 

 

 

 

 

 

 

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();

 

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

Table 43 – Suppress result codes

Result Code

Description

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_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

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

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

 

 

 

 

 

 

 

 

AlwaysGeneratesEvent

ObjectType

AuditConditionSuppressionEventType

Defined in 5.10.4

 

 

 

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. However, some Servers do not expose Condition instances in the AddressSpace. Therefore, 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();

 

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

Table 45 – Unsuppress result codes

Result Code

Description

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_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

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

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

 

 

 

 

 

 

 

 

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. However, some Servers do not expose Condition instances in the AddressSpace. Therefore, 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 ();

 

Method result codes in Table 47 (defined in Call Service)

Table 47 – RemoveFromService result codes

Result Code

Description

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_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

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

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

 

 

 

 

 

 

 

 

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 ();

 

Method result codes in Table 47 (defined in Call Service)

Table 49 – PlaceInService result codes

Result Code

Description

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_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

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

 

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

 

 

 

 

 

 

AlwaysGeneratesEvent

ObjectType

AuditConditionOutOfServiceEventType

Defined in 5.10.12

 

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.

Figure17_

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.

Figure18_

Figure 15 – ShelvedStateMachineType model

Table 51 –ShelvedStateMachineType definition

Attribute

Value

BrowseName

ShelvedStateMachineType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the FiniteStateMachineType defined in OPC 10000-5

 

 

 

 

 

 

 

HasProperty

Variable

UnshelveTime

Duration

PropertyType

Mandatory

 

 

 

 

 

 

HasComponent

Object

Unshelved

 

StateType

 

HasComponent

Object

TimedShelved

 

StateType

 

HasComponent

Object

OneShotShelved

 

StateType

 

 

 

 

 

 

 

HasComponent

Object

UnshelvedToTimedShelved

 

TransitionType

 

HasComponent

Object

TimedShelvedToUnshelved

 

TransitionType

 

HasComponent

Object

TimedShelvedToOneShotShelved

 

TransitionType

 

HasComponent

Object

UnshelvedToOneShotShelved

 

TransitionType

 

HasComponent

Object

OneShotShelvedToUnshelved

 

TransitionType

 

HasComponent

Object

OneShotShelvedToTimedShelved

 

TransitionType

 

 

 

 

 

 

 

HasComponent

Method

TimedShelve

Defined in Clause 5.8.10.3

Mandatory

HasComponent

Method

OneShotShelve

Defined in Clause 5.8.10.4

Mandatory

HasComponent

Method

Unshelve

Defined in Clause 5.8.10.2

Mandatory

 

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

 

HasEffect

AlarmConditionType

 

 

HasCause

OneShotShelve

Method

TimedShelvedToUnshelved

FromState

TimedShelved

StateType

 

ToState

Unshelved

StateType

 

HasEffect

AlarmConditionType

 

TimedShelvedToOneShotShelved

FromState

TimedShelved

StateType

 

ToState

OneShotShelved

StateType

 

HasEffect

AlarmConditionType

 

 

HasCause

OneShotShelving

Method

OneShotShelvedToUnshelved

FromState

OneShotShelved

StateType

 

ToState

Unshelved

StateType

 

HasEffect

AlarmConditionType

 

OneShotShelvedToTimedShelved

FromState

OneShotShelved

StateType

 

ToState

TimedShelved

StateType

 

HasEffect

AlarmConditionType

 

 

HasCause

TimedShelve

Method

 

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( );

 

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

Table 53 – Unshelve result codes

Result Code

Description

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

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

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

Argument

Description

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

Result Code

Description

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

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

AuditConditionShelvingEventType

Defined in 5.10.7

 

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 Servers do not expose Condition instances in the AddressSpace. Therefore, all Servers shall 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

Result Code

Description

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

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionShelvingEventType

Defined in 5.10.7

 

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.

Figure19_

Figure 16 – LimitAlarmType

The LimitAlarmType is formally defined in Table 60.

Table 60 – LimitAlarmType definition

Attribute

Value

BrowseName

LimitAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling
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. The subtype shall describe the expected behaviour with respect to limits and the array values. Some possible options:

·      if any element of the array exceeds the limit an Alarm is generated,

·      if all elements exceed the limit an Alarm is generated,

·      the limits may also be an array, in which case if any array limit is exceeded by the corresponding source array element, an Alarm is generated.

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.

Figure20_

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

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the FiniteStateMachineType

HasComponent

Object

HighHigh

 

StateType

 

HasComponent

Object

High

 

StateType

 

HasComponent

Object

Low

 

StateType

 

HasComponent

Object

LowLow

 

StateType

 

HasComponent

Object

LowToLowLow

 

TransitionType

 

HasComponent

Object

LowLowToLow

 

TransitionType

 

HasComponent

Object

HighToHighHigh

 

TransitionType

 

HasComponent

Object

HighHighToHigh

 

TransitionType

 

 

Table 62 – ExclusiveLimitStateMachineType transitions

BrowseName

References

BrowseName

TypeDefinition

 

Transitions

HighHighToHigh

FromState

HighHigh

StateType

 

ToState

High

StateType

 

HasEffect

AlarmConditionType

 

HighToHighHigh

FromState

High

StateType

 

ToState

HighHigh

StateType

 

HasEffect

AlarmConditionType

 

LowLowToLow

FromState

LowLow

StateType

 

ToState

Low

StateType

 

HasEffect

AlarmConditionType

 

LowToLowLow

FromState

Low

StateType

 

ToState

LowLow

StateType

 

HasEffect

AlarmConditionType

 

 

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

Figure21_

Figure 18 – ExclusiveLimitAlarmType

 The ExclusiveLimitAlarmType is formally defined in Table 63.

Table 63 – ExclusiveLimitAlarmType definition

Attribute

Value

BrowseName

ExclusiveLimitAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling
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

HasSubtype

ObjectType

ExclusiveRateOfChangeAlarmType

Defined in Clause 5.8.16.3

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.

Figure22_

Figure 19 – NonExclusiveLimitAlarmType

 The NonExclusiveLimitAlarmType is formally defined in Table 64.

Table 64 – NonExclusiveLimitAlarmType definition

Attribute

Value

BrowseName

NonExclusiveLimitAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling
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

NonExclusiveRateOfChangeAlarmType

Defined in Clause 5.8.16.2

HasComponent

Variable

HighHighState

LocalizedText

TwoStateVariableType

Optional

HasComponent

Variable

HighState

LocalizedText

TwoStateVariableType

Optional

HasComponent

Variable

LowState

LocalizedText

TwoStateVariableType

Optional

HasComponent

Variable

LowLowState

LocalizedText

TwoStateVariableType

Optional

 

HighHighState, HighState, LowState, and 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 defined in Table 65.

Table 65 – NonExclusiveLevelAlarmType definition

Attribute

Value

BrowseName

NonExclusiveLevelAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the NonExclusiveLimitAlarmType defined in clause 5.8.13.

 

 

 

 

 

 

 

No additional 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

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

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 drops below 9; the high sub state is entered if the process value raises above 12. If the set point were changed to 11 then the new deviation values would be 10 and 13 respectively.  The set point can be fixed by a configuration, adjusted by an 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 formally defined in Table 67.

 

Table 67 – NonExclusiveDeviationAlarmType definition

Attribute

Value

BrowseName

NonExclusiveDeviationAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the NonExclusiveLimitAlarmType defined in clause 5.8.13.

HasProperty

Variable

SetpointNode

NodeId

PropertyType

Mandatory

HasProperty

Variable

BaseSetpointNode

NodeId

PropertyType

Optional

 

The SetpointNode 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 defined in Table 68.

Table 68 – ExclusiveDeviationAlarmType definition

Attribute

Value

BrowseName

ExclusiveDeviationAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling Rule

Inherits the Properties of the ExclusiveLimitAlarmType defined in clause 5.8.12.3.

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 formally defined in Table 69.

Table 69 – NonExclusiveRateOfChangeAlarmType definition

Attribute

Value

BrowseName

NonExclusiveRateOfChangeAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the NonExclusiveLimitAlarmType defined in clause 5.8.13.

HasProperty

Variable

EngineeringUnits

EUInformation

PropertyType

Optional

 

 

 

 

 

 

 

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

5.8.16.3          ExclusiveRateOfChangeAlarmType

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

Table 70 – ExclusiveRateOfChangeAlarmType definition

Attribute

Value

BrowseName

ExclusiveRateOfChangeAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Inherits the Properties of the ExclusiveLimitAlarmType defined in clause 5.8.12.3.

HasProperty

Variable

EngineeringUnits

EUInformation

PropertyType

Optional

 

 

 

 

 

 

 

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

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.

Figure23_

Figure 20 – DiscreteAlarmType Hierarchy

Table 71 – DiscreteAlarmType definition

Attribute

Value

BrowseName