(高清版)GBT 33863.9-2021 OPC统一架构 第9部分：报警和条件

OPC统一架构第9部分：报警和条件OPCunifiedarchitecture—Part9:Alar国家市场监督管理总局国家标准化管理委员会IGB/T33863.9—2021/IEC62541-9:2012 Ⅲ 1 1 1 13.2缩略语 23.3使用的数据类型 3 34.1概述 3 34.3可确认的条件 44.4条件的先前状态 6 6 74.7对话 7 74.9多个活动状态 84.10在地址空间中的条件实例 94.11报警和条件审计 9 5.2两种状态的状态机 5.3条件变量 5.4子状态引用类型 5.5条件模型 5.6对话模型 205.7可确认的条件模型 235.8报警模型 265.9条件类 435.10审计事件 455.11条件刷新相关事件 47 485.13报警和条件状态代码 49 ⅡGB/T33863.9—2021/IEC62541-6.2事件通知者和事件源层级结构 6.3对层级结构增加条件 6.5在变量类型中的条件 附录A(资料性附录)推荐的本地化名称 附录B(资料性附录)示例 附录C(资料性附录)至EEMUA的映射 附录D(资料性附录)从OPCA&E至OPCUAA&C的映射 Ⅲ本部分是GB/T33863的第9部分。——GB/T33863.1—2017OPC统一架构第1部分：概述和概念(IEC/TR62541-1:2010,——GB/TOPC统一架构第3部分：地址空间模型(IEC62541-3:2010,IDT);——GB/TOPC统一架构第4部分：服务(IEC62541-4:2011,IDT);OPC统一架构第5部分：信息模型(IEC62541-5:2011,IDT);——GB/TOPC统一架构第6部分：映射(IEC62541-6:2011,IDT);——GB/TOPC统一架构第8部分：数据访问(IEC62541-8:2011,IDT)。1GB/T33863的本部分规定了OPC统一架构中的报警和条件的表示法，包括OPCUA地址空间中下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文IEC/TR62541-1OPC统一架构第1部分：综述和概念(OPCunifiedarchitecture—Part1:IEC62541-3OPC统一架构第3部分：地址空间模型(OPCunifiedarchitecture—Part3:IEC62541-4OPC统一架构第4部分：服务(OPCunifiedarchitecture—Part4:Services)IEC62541-5OPC统一架构第5部分：信息模型(OPCunifiedarchitecture—Part5:IEC62541-6OPC统一架构第6部分：映射(OPCunifiedarchitecture—Part6:Mappings)IEC62541-8OPC统一架构第8部分：数据访问(OPCunifiedarchitecture—Part8:Dataaccess)EEMUA191:2007警报系统设计、管理和采购指南(Alarmsystems—Aguidetodesign,mana-gementandprocurement)(可从http://www.eemua.co.uk/获得)IEC/TR62541-1、IEC62541-32GB/T33863.9—2021/IEC62541-9:2012条件分支ConditionBranch条件的一种特定状态。特定条件所基于或相关的元素。在为条件生成的事件中，源节点特性(继承于基本事件类型)包含条件源的NodeId。操作员通知服务器，已经采取校正行动来处理报警起因的动作。禁用disable配置系统，以使基本报警条件出现也不会产生报警。操作员operator为监控部分过程所分配的特定用户。更新事件订阅，以提供考虑保持的所有报警。报警处于的一种状态，该状态是希望将客户端条件状态与服务器的状态进行同步的客户端所关在滤除设施上，当某个报警引起操作员反感时，操作员可以暂时阻止该警报向操作员显示。确定报警不会发生的逻辑准则。下列缩略语适用于本文件。A&C:报警和条件(AlarmsandConditions)3参数类型参数类型A&E:报警和事件(AlarmsandEventDA:数据访问(DataAccess)UA:统一架构(UnifiedArchitecture)下列表格列出了本部分所使用的数据类型。表1列出了IEC62541-3中定义的基本数据类型，表2列出了IEC62541-4中定义的基本类型和数据类型。参数类型本部分定义了条件、对话条件和包括确认能力的警报的信息模型。它是建立在IEC62541-3、每个条件实例都具有特定的条件类型。条件类型和派生类型是BaseEventType的子类型(见IEC62541-3和IEC62541-5)。本部分定义了许多行业中通用的类型。期望供应商或其他标准化小组将定义从本部分中定义的通用基本类型派生出附加的条件类型。服务器支持的条件类型在服务器的地条件实例是条件类型的特定实现。由服务器决定这些实例是否也在服务器的地址空间中公开。4.10提供了有关条件实例的附加背景。条件实例应具有惟一的标识符以将它们与其他实例区分开。这4的先前状态。引入条件分支来处理这个要求，并区分当前状态和先前状态。每个条件分支都有一个BranchId,以将其与同一条件实例的其他分支区分开来。表示条件(主干)的当前状态的条件分支具有空的BranchId。服务器可为每个分支生成单独的事件通知。当由条件表示的状态不需要进一步关注基本条件状态模型在图1中示出。它由本部分中定义的各种条件子类型扩展，并可由供应商或其他标准化小组进一步扩展。条件的主要状态是Disabled(禁用)和Enabled(启用)。禁用状态旨在允许在服务器或下面的服务器(在设备或某些下层系统中)上关闭条件。启用状态通常转换进入Disabled状态会导致一个ConditionEvent(条件事件),在该条件返回到Enabled状态之前不会生成后续EventNotification(事件通知)。服务器将生成用于启用和禁用操作的AuditEvent(通过方法调用或某些服务器/供应商特定的手段),而不是为每个Enabled或Disabled条件实例生成AuditEvent通知。更多信息见5.10.3中AuditAcknowledgeableConditions是基本条件类型的子类型。AcknowledgeableCoAckedState和ConfirmedState扩展了由条件定义的Enabled状态。状态模型在图2中示出。通过添加AckedState和(可选地)ConfirmedState来扩展Enabled状态。5AckedState=TRUEAckedState=FALSE基本确认状态模型如图3所示。模型定义了AckedState。导致状态改变的特定状态改变取决于服务器的实现。例如，在典型的报警模型中，改变被限制为转换到活动状态或确认图4示出了向基本确认添加证实的更复杂的状态模型。证实的确认(ConfirmedAcknowledge)模型通常用于区分确认某个条件的存在和已经做出某事以解决该条6GB/T33863.9—2021/IEC62541-9:2一些系统要求保持条件的先前状态一段时间。常见的用例是确认过确认转换到活动状态以及转换到非活动状态。具有严格安全规则的系统有时要多个条件分支也可用于其他用例，在这种情况下，条件的先前状态快照(snapshot)需要执客户端可通过请求刷新订阅来获取处于关注的状态的所有条件实例的当客户端通过调用ConditionRefresh(条件刷新)方法请求刷新。服务器将使用RefreshStartEvent来响应。该事件后面是保持条件。服务器还可发送用刷新相关的事件通知分知。客户端在接收到RefreshStartEvent的事件时，将所期间接收的任何新事件，而不将其标记为可疑。客户端还从作为刷新一部除可疑标志。当客户端接收到RefreshEndEv关于条件刷新(ConditionRefresh),7GB/T33863.9—2021/IEC 为确保客户端始终被通知到，三个特殊的事件类型(RefreshEndEventType、RefreshStari8AckedState=TRUEAckedState9GB/T33863.9—2021/IEC本部分描述了每个方法需要生成的AuditEventType。例如，禁用方法具有对AuditConditionGB/T33863.9—2021/IEC以下条目定义了OPCUA报警和条件类型。图7非正式地描述了这些类型的层级结构。Limit会在IEC62541-5中定义会会GB/T33863.9—2021/IEC值引用数据类型建模规则IEC62541-4中定义的StateVariableType的子类型注：对该子类型的引用在StateVariableType的定义中没有显示。ConditionVariable由表4中正式定义的ConditionVariableType表示。值引用数据类型建模规则IEC62541-5中定义了BaseDataVariableType的子类型SourceTimestamp指示该ConditionVariable的值的最后一次改变时间。它应是在条件变量值属性的DataValue结构内从读服务返回的相同时间。有子状态的TwoState状态机。这些引用仅在子状态可用时存在。使用这种方法，TwoStateVariables可与IEC62541-5中定义的StateMachineType类似的方式用下属状态机进行扩展。HasTrueSubState引用类型是一个可直接使用的具体引用类型。它是NonHierarchicalReferences语义表示该子状态(目标节点)是TRUE超(super)状态的下属状态。如果条件中多于一个状态是相同超状态的子状态(即对于相同超状态存在几个HasTrueSubState引用),则它们都被视为独立子状态。表5规定了在地址空间中的表示法。引用的源节点应是TwoStateVariableType的一个实例，而目标节点应是一个TwoStateVariableType的实例或者一个StateMachineType的子类型实例。它不需要提供从超状态到子状态的HasTrueSubState引用，但要求子状态提供反向引用(IsTrue值引用HasFalseSubState引用类型是一个可直接使用的具体引用类型。它是NonHierarchicalReferences语义表示该子状态(目标节点)是FALSE超状态的下属状态。如果条件中多于一个状态是相同超状态的子状态(即对于相同超状态，存在几个HasFalseSubState引用),则它们都被视为独立子状态。表6中规定了在地址空间中的表示法。引用的源节点应是TwoStateVariableType的一个实例，而目标节点应是一个TwoStateVariable它不需要提供HasFalseSubState引用从超状态到子状态，但是要求子状态提供反向引用(IsFalse值引用条件模型通过定义条件类型扩展了事件模型。条件类型引入了将它与基本事件模型区分开的状态的概念。与基本事件类型不同，条件不是暂时的。条件类型进一步扩展为DialogConditionTypes和BaseEventTypeBaseEventTypeConditionType定义条件的所GB/T33863.9—2021/IEC值引用数据类型建模规则IEC62541-5中定义了BaseEventType的子类型ConditionType继承BaseEventType的所有特性。它们的语义在IEC62541-5中定义。ConditionClassName提供CoGB/T33863.9—2021/IEC对于与条件实例的当前状态相关的所有事件通知，BranchId为空。如果BranchId不为空，则 该列表可能不是全面的。子类型可定义触发事件通知的其他变量。对类型TwoState条件实例的NodeId用作Conditionld。它没有明确地被建模为ConditionType的一个组件。表8定义了SimpleAtributeOperand以在EventF无5.5.3条件和分支实例条件实例可以是出现在服务器地址空间中的对象。如果是这种情况，ConditionId是对象的NodeId。结果代码Bad_ConditionAlreadyDisa表9规定了Disable方法的地址空间表示法。值引用数据类型建模规则AuditConditionEnableEventTEnable用于将条件实例改变为Enable状态。通常，通过浏览地址空间中的条件实例来找到传递给Call服务的MethodId。但是，某些服允许客户端通过指定ConditionId为ObjectId,以及指定关于ConditionType的方法声明的NodeId作为MethodId,来调用Enable方法。结果代码Bad_ConditionAlreadyEna表10规定了Enable方法的地址空间表示法。表10Enable方法的地址空间定义值引用数据类型建模规则AuditConditionEnableEventT务器都应允许客户端通过指定ConditionId为ObjectId,以及指定关于ConditionType的方法声明的NodeId作为MethodId,来调用AddComment方法。不能在Conditiontype节点上调用该方法。[in]LocalizedTextEventId标识为某个条件报告状态的结果代码用于指示指定的条件无效，或在ConditionTyp节点上调用了该方法将注释添加到通过EventId标识的事件发生。完全不支持注释的相关EventType的EventId都被ConditionEvent(注释变量包含此文本)将被发送用于标识的状态。如果将注释添加到先前的状态(即服务器已经创建了分支的状态),则将报告该分支的BranchId和所有Condition值。表11规定了AddComment方法的地址空间表示法。表11AddComment方法地址空间定义值引用数据类型建模规则AuditConditionCommentEventTConditionRefresh允许客户端请求所有条Retain标志)。这包括服务器维护分支的条件实例的先前状态。当客户端最初连接到服务器时，以及刷新订阅的有效SubscriptionIdBad_SubscriptionIdInva)该服务器发出一个RefreshStartEvent(在5.11.2中定义),标记刷新的开始。RefreshStartEvent的副本被排入订阅中每个事件MonitoredItem的事件流。每个事件副本b)该服务器发出满足订阅内容过滤条件的保留条件和保留分支的条件的事件通知。注意，这种刷新通知的EventId应与原始通知的EventId相同。c)该服务器可以将以前没有发出的新事件通知连同那些正发送的作为Refresh请求一部分发布给通知者。客户端应检查ConditionBd)该服务器发出的RefreshEndEvent(在5.11.3中定义)表示刷新结束。RefreshEndEvent的副本被排入订阅中每个事件MonitoredItem的事件流。每个事件副本应包含相同的EventId。表12规定了ConditionRefresh方法的地址空间表示法。值引用数据类型建模规则对话模型是条件模型的扩展，用于服务器请求用户输入。它提供了与大多数对话类似的功能。通过在ResponseOptionSet中提供服务器特定响应选项并给派生的条件类型添加附DialogConditionTyoe用对话来表达条件。其图解如图9所示，其正式定义见表13。值引用数据类型建模规则见附录A。 GB/T33863.9—2021/IEC——Abort,Retry,Ignore;——Retry,Cancel:——Yes,No。值为-1。ResponseOptionSet数组的所选索引结果代码Bad_DialogResponseInv值引用数据类型建模规则AuditConditionResponGB/T33863.9—2021/IEC65.7可确认的条件模型可确认的条件模型扩展了条件模型。它对条件模型添加了可确认和AcknowledgeableConditions由该ConditionType的子类型AcknowledgeableConditionType来表5.7.2AcknowledgeableCAcknowledgeableConditionType通过定义可确认特征来扩展ConditionType。它是一种抽象的类Acknowledgeable图10AcknowledgeableConditionType概述值AcknowledgeableConditionT引用建模规则AcknowledgeableConditionType继承ConditionType的所有特性。当AckedState为FALSE时，指示条件实例需要对所报告的条件状态进行确认。当条件实例被确GB/T33863.9—2021/IEC按4.4中的规定创建该条件实例的分支。期望客户AcknowledgeableConditionType的方法声明的NodeId作为MethodId,来调用Acknowledge方法。在仅能够确认AckedState/Id是FAL结果代码Bad_ConditionBranchAlreadyA用于指示特定条件无效或该方法在该条件类型节点上被调用表16Acknowledge方法地址空间定义值引用数据类型建模规则5.7.4Confirm方法Confirm被用来证实ConfirmedState设置为FALSE的条件实例状态的事件通知。通常，通过在公开条件实例。因此，所有服务器应允许客户端通过指定ConditionId作为ObjectId和指定关于Ac-knowledgeableConditionType的方法声明的NodeId作为MethodId,来调用Confirm方法。在Ac-knowledgeableConditionType节点上不能调用该方法。[in]LocalizedText表17Confirm方法参数仅能够证实ConfirmedState/Id是TR结果代码Bad_ConditionBranchAlreadyConfi用于指出该特定条件无效或该方法在该条件类型节点上被调用服务器负责确保每个事件具有惟一的EventId。这允许客户端标识并证实特定的事件通知。该EventId标识一个报告了被证实状态的特定事件通知。可提供注释适用于以EventId标识的有效的EventId将导致ConfirmedsState/Id设置为TRUE的事件通知，注释特性包含可选注释参GB/T33863.9—2021/IEC62541-9:2012表18规定了该方法指定地址空间的表示法。值引用数据类型建模规则图11非正式地描述了AlarmConditionType、其子类型和在事件类型层级结构中的位置。NonExclusiveLimitNonExclusiveNonExclusivekkk-扩展了AcknowledgeableConditionType。报警模型见图12。该图不是一个完整的定义。其正式定义见表19。图12报警模型值引用数据类型建模规则在5.7.2中定义了AcknowledgeableConditionGB/T33863.9—2021/IECShelvingState建议是否应(暂时)阻止对用户显示某个报警。它经常用来阻止误报警。SuppressedState和Shelv持续时间的上限。如果该特性存在，它也将对OneshotShelved状态强制执行，即如果在特性规定的持续时间期满，则警报条件将从成的转换，当定义为“TimedshelvedCall”一部分的时间值到期时发生此转换。“AnyTransitionGB/T33863.9—2021/IEC图13搁置状态转换ShelvedStateMachine包括子状态层级结构。它支持所有在Unshelved、OneShotShelved和值引用数据类型建模规则FiniteStateMachineType的子类在IEC6254UnshelvedToOneShotShUnshelveTime规定了直到TimedShelved状态或(对于提供MaxTimeShelved特性的情况)One-shotShelved状态自动地转换进入UnShelved状态的剩余时间(按毫秒计)。在表21中描述了这些状态和转换。该状态机还支持三种方法：TimedShelve、OneShotShelve和引用值UnshelvedToTimedSheUnshelvedToOneShotSheTimedShelvedToOneShotSOneShotShelvedToTime5.8.4Unshelve方法Unshelve设置报警条件为Unshelved状态。结果代码Bad_ConditionNotShe表22规定了Unshelve方法的地址空间表示法。表22Unshelve方法地址空间定义值引用数据类型建模规则TimedShelve设置报警条件为TimedShelved状态。规定该报警被搁置的固定时间。服务器可以拒绝提供的存在MaxTimeShelved特性，则搁置时间应小结果代码Bad_ConditionAlreadyShe该报警已处于TimedShelved状态，并且系Bad_ShelvingTimeOutOfR供的持续时间。该限制可能会公开为MaxTimeShelved特性。表23规定了TimedShelve方法的地址空间表示法。表23TimeShelve方法地址空间定义值引用数据类型建模规则OneShotShelve设置报警条件为OneShotShelved状结果代码表24规定了OneShotShelve方法的地址空间表示法。值引用数据类型建模规则AuditConditionShelvingEventTLimitAlarm是一种抽象类型，用于为具有多个限值的报警条件提供基本类型。LimitAlarm的图释见图15。NonExclusiveLimit图15LimitAlarmTypeLimitAlarmType的正式定义见表25。GB/T33863.9—2021/IEC62541-9:2012值引用数据类型建模规则AlarmConditionType的子类型在5.8.2在中定义定义了四个可选限值来配置派生限值报警类型的状态。对于通限值应设置这些特性。这些特性作为可选特性当某个值等于限值时，所列出的报警限值可能引起报警产生；或某个值超过限值(即该值高于HighLimit或低于LowLimit限值)时，所列出的报警限值可能产生报警。关于等于限值的准确行为是ExclusiveLimitStExclusiveLimitStateMachine定义了处理多个相互排斥限值的报警类型所使用的状态机，如图16GB/T33863.9—2021/IEC6它通过扩展StateMachineType来创建。其形式定义见表26,在表27中描述了状态转换。值ExclusiveLimitStateM引用数据类型建模规则GB/T33863.9—2021/IEC62541-9:20引用目标浏览名称值目标类型定义ExclusiveLimitStateMachine定义了代表多层报警处于活动状态时实际层级的子状态机。这里定义的子状态机包括high、low、highigh和lowlow状态。该模型还包括在其转换状态中的一系列转ExclusiveLimExclusiveLimitAlarm用于规定具有多个相互排斥限值的报警类型的通用行为。ExclusiveLimitAlarm的图释如图17所示。GB/T33863.9—2021/IEC6EnableStateCoExclusiveLimitStateMachExclusiveLimitAlarmType的正式定义见表28。值引用建模规则LimitAlarmType的子类型在5在中定义在中定义在中定义LimitState表示ExclusiveLimitAlarm处于活动状态时的实际限值偏离。5.8.9NonExclusiveLimitAlarmTypeNonExclusiveLimitAlarmType用作规定多种非排斥限值的报警类型的通用行为。NonExclusiveLimitAlarmType的图释见图18。工tNonExclusiveLevelNonExclusiveLimitAl值NonExclusiveLimitAlarmT引用数据类型建模规则LimitAlarmType的子类型在5NonExclusiveLevelAlarmTNonExclusiveDeviationAlarmTGB/T33863.9—2021/IEC62541-9:2定义了配置这些状态的四个可选限值。即使所有的状态都是可选项，至少应提供HighState或LowState。HighState和LowState的定义意味着这些分组是相互独立的。一个值不可能同时超出HighState值和LowState值。NonExclusive同时保持High状态和HighHigh状态处于活动状态，应使用该报警类型。NonExclusiveLevelAlarmType基于NonExclusiveLimitAlarmType。其正式定义见表30。值NonExclusiveLevelAlarmT引用数据类型建模规则NonExclusiveLevelAlarmType的子类型在5.8.9NonExclusiveLimitAlarmType没有定义额外的特性。ExclusiveLevelAlarmTypeExclusiveLevelAlarmType是使用多个排斥性限值的特殊物位警报。其正式定义见表31。表31ExclusiveLevelAlarmTy值引用数据类型建模规则继承了在中定义的ExclusiveLimiExclusiveLevelAlarmType没有定义额外的特性。偏差报警通常用于报告过程值的期望设定值与实际测量值之间的超出偏差。GB/T33863.9—2021/IEC62541-9:20例如，如果设定值为10,高偏差报警限值设定为2,低偏差报警限值设定为-1。那么如果过程值降低到9以下，将进入低子状态；当过程值大于12时，将进入高子状态。如果设定值变将相应变为10和13。NonExclusiveDeviNonExclusiveDeviationAlarmType是一种使用一个或多个非排斥状态的特殊物位报警。例如，如NonExclusiveDeviationAlarmType基于NonExclusiveLimitAlarmType。其正式定义见表32。值NonExclusiveDeviationAlarmT引用数据类型建模规则NonExclusiveLimitAlarmType的子类型在5.8.9ExclusiveDeviationAlExclusiveDeviationAlarmType使用多个相互排斥的限值。其正式定义见表33。值ExclusiveDeviationAla引用数据类型建模规则继承了在中定义的ExclusiveLimi变化率报警通常用于报告与值发生变化的速度相关的测量值出现异常变化GB/T33863.9—2021/IEC62541-物位变化率High限值为4m/min。如果该罐的物位变化率大于4m/min,则进入High子状态。NonExclusiveRateOfChanNonExclusiveRateOfChangeAlarmType是一种采用一个或多个非排斥性状态的特殊物位报警。表34。表34NonExclusiveRateOfChangeAlar值NonExclusiveRateOfChangeAlarmT出处数据类型模型规则NonExclusiveLimitAlarmType的子类型在5.8.9NonExclusiveLimitAlarmType没有定义附加特性。ExclusiveRateOfChanExclusiveRateOfChangeAlarmType采用多个相互排斥的限值。其正式定义见表35。值ExclusiveRateOfChangeAla出处数据类型模型规则继承在中定义的ExclusiveLimiExclusiveLimitAlarmTy量的可能值(例如true/false,running/stopped/terminating)。本部分中定义的具有子类型的DiscreteAlarmTypedefined在图19中示出。其正式定义见表36。GB/T33863.9—2021/IEC表36DiscreteAlarmType定义值出处数据类型模型规则AlarmConditionType的子类型在5.8.2值出处数据类型模型规则DiscreteAlarmType的子类型在中定义在中定义GB/T33863.9—2021/IEC62541-监测的装置部件出现非正常故障(如由于超载引起电机停止)时，报警变为活动的。正式定义见表38。表38TripAlarmType定义值引用数据类型模型规则OffNormalAlarmType的子类型在中定义条件用于特定应用领域(domain),如个条件分配到某个ConditionClass。客户端可以使用该特性来筛选出基本类(essentialclasses)。OPCUA为所有的ConditionClasses和在许多行业中使用的通用类定义了基本对象类型(ObjectType)。图7非正式描述了该部分中定义的ConditionClass类型层级结构。BaseObjectType△务器应使用一个更明确的ConditionClass。所有ConditionClass类型来源于BaseConditionClassTyp其正式定义见表39。值引用数据类型模型规则BaseObjectType的子类型在IEC62541-值ProcessConditionCla引用数据类型模型规则BaseConditionClassType的子类型在.4MaintenanceConMaintenanceConditionClassType用来分类与维护相关的条件。其正式定义见表41。此处不提供值MaintenanceConditionClassT引用模型规则BaseConditionClassType的子类型在5.9.SystemConditionClassType用来分类与系统相关的条件。其正式定义见表42。系统条件出现在控制系统过程或监测系统过程。此处不提供更多的定义。其他标准组织或供应商将有望定义特定领域GB/T33863.9—2021/IEC值引用数据类型模型规则BaseConditionClassType的子类型在5.9.小AuditConditionAcknowlAuditConditionEventTypes通常用于对方法(Method)调用的响应。然而，如果这种方法(Method)的功能通过其他特定服务器方式来执行，则这些事件也应被通知。在这种情况下，GB/T33863.9—2021/IEC62541-9:2012值AuditConditionEventT5.10.3AuditConditionEnab该事件类型用来指示某个条件实例的启用状态中的变化。其正式定义见表44。AuditConditionEnableEventT5.10.4AuditConditionCommen该事件类型用来报告AddComment动作。其正式定义见表45。值AuditConditionCommentEventT5.10.5AuditConditionRespon该事件类型用来报告Respond动作。其正式定义见表46。值AuditConditionRespondEventT该事件类型用来表示一个或多个条件的确认或证实。其正式定义见表47。值AuditConditionAcknowledgeEventT5.10.7AuditConditionConfi该事件类型用来报告证实动作。其正式定义见表48。值AuditConditionConfirmEventT5.10.8AuditConditionShelvi该事件类型用来表示某个条件实例搁置状态的变化。其正式定义见表49。值AuditConditionShelvingEventT图22刷新相关事件层级5.11.2RefreshStartEventType该事件类型被服务器用来标识刷新通知(RefreshNotification)周期的开始。在表50中正式定义值引用数据类型模型规则继承在IEC62541-5中定义的SystemEventType特性，即，它具有对相同节点的HasProperty引用该事件类型被服务器用来标识刷新通知(RefreshNotification)周期的结束。在表51中正式定义值引用数据类型模型规则继承在IEC62541-5中定义的SystemEventType特性，即，它具有对相同节点的HasProperty引用5.11.4RefreshRequir该事件类型被服务器用来指示服务器中或该服务器下层子系统中的实使订阅的条件状态无效。在表52中正式定义了其在地址空间中的表示法。值引用数据类型模型规则继承在IEC62541-5中定义的SystemEventType特性，即，它具有对相同节点的HasPropertyReferences子类型。在表53中正式定义了其在地址空间中的表示法。GB/T33863.9—2021/IEC是HasEventSource引用的目标或HasEventSource的子类型。在第6章中定义了应向用户提供用于值引用Bad_ConditionAlreadyEna寻址的条件已被启用Bad_ConditionAlreadyDisa寻址的条件已被禁用Bad_ConditionAlreadySheBad_ConditionBranchAlreadyABad_ConditionBranchAlreadyConfiBad_ConditionNotSheBad_DialogResponseInv所选的选项在ResponseOptionSet数组中是无效索引ConditionRefresh操作已经在进行中Bad_ShelvingTimeOutOfR所提供的搁置时间超过了服务器所允许的搁置范围GB/T33863.9—2021/IEC服务器服务器装置C客户端可通过首先浏览跟随HasEventSource引用(包括子类型，如HasNotifier引用)的GB/T33863.9—2021/IEC6罐区图25示出了InstanceDeclaration中的HasCondition引用和HasEventSource引用的使用。它们在InstanceDeclarations上下关系中的HasEventSource引用和TypeDefinition节点的使用对事件罐类型罐类型A.1.1LocaleId“en”条件类型AcknowledgeableConditionTNonExclusiveLimitAlarmT条件类型显示名称A.1.2LocaleId“de”GB/T33863.9—2021/IEC条件类型AcknowledgeableConditionTNonExclusiveLimitAlarmTA.1.3LocaleId“fr”FALSE状态名称TRUE状态名称AcknowledgeableConditionT表A.5(续)FALSE状态名称TRUE状态名称NonExclusiveLimitAlarmT表A.7推荐对话响应选项Locale“en”Locale“de”Locale“fr”GB/T33863.9—2021/IEC62541-9:20下列示例示出了典型的报警情况下的事件流。表B.1和表B.2中列出了每个事件通知的状态变量图B.1单个状态示例表B.1仅保持最新状态的条件示例活动的确认的证实的说明12345678“第一行用来说明条件的初始状态。该状态将不会被事件报告。GB/T33863.9—2021/IEC62541-9:2图B.2说明了服务器对分支的使用，该服务器要求对所有进入活动状态的转换而不仅仅是最近的先前的状态先前的状态当前的状态时间通知339⑫表B.2通过分支保持先前状态的条件的示例活动的确认的证实的说明1234已证实56GB/T33863.9—2021/IEC62541表B.2(续)活动的确认的证实的说明71先前状态需要确认。创建分支18912先前状态需确认。创建分支21先前状态已证实。删除分支12先前状态已确认，系统自动证实，删除分支2第一行用来说明条件的初始状态。该状态将不会被事件报告。注1:如果条件的当前状态是已确认，那么Acked标志置位，并报告新的状态(事件2)。如果条件状态在它可以被确认前就改变(事件6),则报告一个分支状态(事件7)。对于事件6和7的时间戳是相同注2:在分支状态被清除之前(事件12),它可被更新若干次(事件9注3:一个单一的条件可有许多分支状态活动(事件11)。建议像在该表中一样，只要先前的状态(分支)存在，就让“Retain=True及其相关条件的组织。该层级结构是对Organizes和Aggregates引用提供的层级结构的附加。图B.3示出了带条件实例的HasCondition引用的使用。GB/T33863.9—2021/IEC6对象对象服务器区域1罐区机器BHasCondition装置BGB/T33863.9—2021/IEC服务器区域1PricssAlamExclusiveLimit本HasEventSourceExchusiveLevelMoyLevelAlarm7jpe机器B图B.5示出了一个在类型系统中已经定义了HasCondition引用的例子。该引用可指向一个条件类型或一个实例。在该例中示出了两个变体。在类型系统中对一个条件类型的罐区罐区MjSystemAlarmTypeGB/T33863.9—2021/IEC表C.1列出了EEMUA的术语和OPCUA的术语如何映射到EEMUA的术语。OPCUA术语当操作员已表明感觉到报警的存在时，报警被接在OPCUA中，这可以用Acknowle报警条件存在(即已超过限值，条件继续存在)(在IEC62541-5中定义)向操作员提交的描述报警条件的测试信息(在IEC62541-5中定义)重的后果。在一些行业也被称为提示或警告。现。例如，严重性低于50的报警可被视为警告即为报警被禁用当操作员执行一些系统不能执行或需要操作授权执行的过程当产生报警的条件发生时，引发或发起一个报警“释放”是一个工具，可以以类似于应用搁置的方式应用到一报警列表中删除，并将其放在架子上。当报警次引发时，它将以正常的方式出现在报警列表中OPCUA包括Retain标志，作为其定义状态的部分：“当客户端接收到Retain标志设置为FALSE的下，条件/分支将从显示中被删除”搁置是一种工具，其应用场合是：当报警妨员能暂时阻止报警被显示给操作员。搁置的报警将从列表中表C.1(续)OPCUA术语EEMUA定义当报警条件一直存在时，报警就为持续有效(引发和持续有效经常被互换使用)”即使基本报警条件(例如报警设置已超过)是存在的，但当采用的逻辑判据判定不应该发生报警时，报警即被抑制当操作员已表明感觉到报警的存在时，报警被接受。在前述从OPCA&E至OPCUAA&C的映射A&ECOM服务器中的事件区在A&ECOMUA包装器中表示为具有BaseObjectType的根区域被表示为取决于UA服务器的带BrowseName的对象。它总是成为来自服务器节点的区域层级结构通过采用BrowseOpcArea和GetQualifiedAreaName方法来发现。由Browse惟一URI。每个区域均是来自其父区域的HasNotifier的引用目标。它可能是对其子区域的一个或多个A&ECOM服务器中的事件源在A&ECOMUA包装器中表示为具有BaseObjectType的简单(Simple)事件类型是BaseEventType的直接子类型。跟踪(Tracking)事件类型是每个ConditionName-ObjectType的NodeId是由COMAE服务器所分配的事件类型、EventCategoryID和ConditioBaseEventType水属性1属性2属性1AlarmTypeConditionCategoryY属性1属性3GB/T33863.9—2021/IECA&ECOM服务器中的事件属性在UA服务器中表示为HasProperty引用的目标的变量，表D.1列出了A&ECOMUA包装器所采用的ONEVENTSTRUCT内的字段如何映射到UAONEVENTSTRUCT字段区域是COMAE服务器的默认区域表D.2列出了由A&ECOMUA包装器所用的ONEVENTSTRUCT内的字段如何映射到UAONEVENTSTRUCT字段只设置用于跟踪事件设置为COMAE服务器NamespaceURI表D.3列出了由A&ECOMUA包装器所用的ONEVENTSTRUCT内的字段如何映射到UAONEVENTSTRUCT字段总是设置为BaseConditionClassType总是设置为“BaseConditionClass”总是设置为空若OPC_CONDITION_ACKED比特未设置或OPC_CONDITION_ACTIVE比特已设置，则设置设置为“Enabled”或“Disabled”若OPC_CONDITION_ENABLED已设置由wNewState标志中的比特构造的一个字符为选择该字符串，应用以下规则：若OPC_CONDITION_ENABLED未设置，则“Disabled”;若OPC_CONDITION_ACKED未设置，则“Unacknowledged”;若OPC_CONDITION_ACKED已设置，则“Active”;若OPC_CONDITION_ENABLED已设置，则“Enabled”COMDA质量转换为UA状态码基于条件实例所接收到的最后事件而设置。ACK_COMMENT属性的值设置为“Acknowledged”或“Unacknowledged”若OPC__CONDITION_ACKED已设置，则设置为TRUE设置为“Active”或“Inactive”若OPC__CONDITION_ACTIVE已设置，则设置为TRUE区域为COMAE服务器的默认区域GB/T33863.9—2021/IECA&ECOM客户端仅仅需要了解寻址如何连至UAA&C服务器。连——属于除AuditEventType或ConditionType以外的任何子类型的那些A&A&E事件类型Simple。——A&ETracking类别包括：在AuditEventType和TransitionEventType的子类型(包括AuditEventType自身和TransitionEventType自身在内)的层级结构中所定义的所有事件类——A&ESimple类别包括：除AuditEventType和ConditionType及其各自的子类型外，GB/T33863.9—2021/IECUA条件类型BaseEvent类别3:AlarmConditionType个AlarmCondition与任何给定的A&E事件相关联的属性集合被封装在ONEVENTSTRUCT内。因此，A&EA&EONEVENTSTRUCT“属性”以下各项都对应于所有的A&E事件类型UABaseEventType特性：SourcUABaseEventType特性：MeUABaseEventType特性：Sev表D.4(续)A&.EONEVENTSTRUCT“属性”以下各项仅对应于A&E条件相关事件UAConditionType特性：ConditioUAActiveState特性：EffectiveDisplaA&CAlarmConditionType特性：ActiveStA&.CConditionType特性：EnabledStA&.CAcknowledgeableConditionType特性：AckedSt的事件，均默认设置为UNACKNOWLEDGED且AckRequiredA&CConditionType特性：Qual注：映射为非条件事件的事件均默认设置为OPC_QUALITY_GOO通常，StatusCode的Severity字段是用于映射CQUALITY_BAD、OPC__QUALITY_GOOD和OPC__QUALITY_UNCERTAIN。可能时，特殊状态直接映射。这些包括(UA=>COM):BadConfigurationError=>OPC_QUALITY_CONFIG_BadNotConnected=>OPC_QUALITY_NOT_CONNBadDeviceFailure=>OPC_QUALITY_DEVICE_FABadSensorFailure=>OPC_QUALITY_SENSOR_FABadNoCommunication=>OPC_QUALITY_COMM_FABadOutOfService=>OPC_QUALITY_OUT_OF_SEUncertainNoCommunicationLastUsableValueUncertainLastUsableValue=>OPC_QUALITY_LAST_UUncertainSensorNotAccurate=>OPC_QUALITY_SENSOR_CALUncertainEngineeringUnitsExceeUncertainSubNormal=>OPC_QUALITY_SUB_NGoodLocalOverride=>OPC_QUALITY_LOCAL_O若ACKNOWLEDGED比特(opc_condition_acked)已设置，则Ack要求的表D.4(续)A&EONEVENTSTRUCT“属性”若事件是AlarmConditionType类型或子类型，且ActiveState从FALSE到工后的时间特性属性适用于发布。若事件不是AlarmConditionType类型或子类型，则该字段设置为当前时间由A&.ECOMUA代理服务器生成。这些惟一的条件事件cookies不与来自UAA&C服务器的地址空间的任何相关标识符关联以下各项仅适用于A&E跟踪事件和确认通知的A&E条件相关事件供应商特定属性——全部(ALL)假定全部A&E事件均支持“Areas”属性。但是，没有一个A&C事件的任何属性或特性可以提供这个值。因此，A&ECOMUA代理服务器基于生成该事件的监视项来初始化该Areas属性的值。若A&订阅未采用区域过滤，则相应的A&C订阅将只A&.CServer对象。代表该订阅转发给A&ECOM客户端的事件会滤，则相关的UAA&C订阅会对由区域字符串所标含一个或多个监视项。转发给A&ECOM客户端的事合格的区域名称)供应商特定属性——基于类别不是由BaseEventType或ConditionType所公条件事件实例记录被就地存储在A&ECOMUA代理中。每个记录都持有每个EventSource/条件实例的oneventstruct数据。当条件实例转换至INACTIVE|ACKED状态时，在AckRequired=生成至任何订阅客户端的OnEvent回调。在客户端应用确认当前未确认的(AckRequired=TRUE)一指示转换已确认的后续事件会导致对本地条件记录的当前状态的更新，以及对任何订阅客户端的A&ECOMUA代理服务器保持基于事件类别的属性映射。事件类别继承了在UA事件类型层级结构中的所有超类型所定义