(高清版)GBT 33863.9-2021 OPC統(tǒng)一架構(gòu) 第9部分：報警和條件

OPC統(tǒng)一架構(gòu)第9部分：報警和條件OPCunifiedarchitecture—Part9:Alar國家市場監(jiān)督管理總局國家標(biāo)準(zhǔn)化管理委員會IGB/T33863.9—2021/IEC62541-9:2012 Ⅲ 1 1 1 13.2縮略語 23.3使用的數(shù)據(jù)類型 3 34.1概述 3 34.3可確認(rèn)的條件 44.4條件的先前狀態(tài) 6 6 74.7對話 7 74.9多個活動狀態(tài) 84.10在地址空間中的條件實例 94.11報警和條件審計 9 5.2兩種狀態(tài)的狀態(tài)機(jī) 5.3條件變量 5.4子狀態(tài)引用類型 5.5條件模型 5.6對話模型 205.7可確認(rèn)的條件模型 235.8報警模型 265.9條件類 435.10審計事件 455.11條件刷新相關(guān)事件 47 485.13報警和條件狀態(tài)代碼 49 ⅡGB/T33863.9—2021/IEC62541-6.2事件通知者和事件源層級結(jié)構(gòu) 6.3對層級結(jié)構(gòu)增加條件 6.5在變量類型中的條件 附錄A(資料性附錄)推薦的本地化名稱 附錄B(資料性附錄)示例 附錄C(資料性附錄)至EEMUA的映射 附錄D(資料性附錄)從OPCA&E至OPCUAA&C的映射 Ⅲ本部分是GB/T33863的第9部分?！狦B/T33863.1—2017OPC統(tǒng)一架構(gòu)第1部分：概述和概念(IEC/TR62541-1:2010,——GB/TOPC統(tǒng)一架構(gòu)第3部分：地址空間模型(IEC62541-3:2010,IDT);——GB/TOPC統(tǒng)一架構(gòu)第4部分：服務(wù)(IEC62541-4:2011,IDT);OPC統(tǒng)一架構(gòu)第5部分：信息模型(IEC62541-5:2011,IDT);——GB/TOPC統(tǒng)一架構(gòu)第6部分：映射(IEC62541-6:2011,IDT);——GB/TOPC統(tǒng)一架構(gòu)第8部分：數(shù)據(jù)訪問(IEC62541-8:2011,IDT)。1GB/T33863的本部分規(guī)定了OPC統(tǒng)一架構(gòu)中的報警和條件的表示法，包括OPCUA地址空間中下列文件對于本文件的應(yīng)用是必不可少的。凡是注日期的引用文件，僅注日期的版本適用于本文IEC/TR62541-1OPC統(tǒng)一架構(gòu)第1部分：綜述和概念(OPCunifiedarchitecture—Part1:IEC62541-3OPC統(tǒng)一架構(gòu)第3部分：地址空間模型(OPCunifiedarchitecture—Part3:IEC62541-4OPC統(tǒng)一架構(gòu)第4部分：服務(wù)(OPCunifiedarchitecture—Part4:Services)IEC62541-5OPC統(tǒng)一架構(gòu)第5部分：信息模型(OPCunifiedarchitecture—Part5:IEC62541-6OPC統(tǒng)一架構(gòu)第6部分：映射(OPCunifiedarchitecture—Part6:Mappings)IEC62541-8OPC統(tǒng)一架構(gòu)第8部分：數(shù)據(jù)訪問(OPCunifiedarchitecture—Part8:Dataaccess)EEMUA191:2007警報系統(tǒng)設(shè)計、管理和采購指南(Alarmsystems—Aguidetodesign,mana-gementandprocurement)(可從http://www.eemua.co.uk/獲得)IEC/TR62541-1、IEC62541-32GB/T33863.9—2021/IEC62541-9:2012條件分支ConditionBranch條件的一種特定狀態(tài)。特定條件所基于或相關(guān)的元素。在為條件生成的事件中，源節(jié)點特性(繼承于基本事件類型)包含條件源的NodeId。操作員通知服務(wù)器，已經(jīng)采取校正行動來處理報警起因的動作。禁用disable配置系統(tǒng)，以使基本報警條件出現(xiàn)也不會產(chǎn)生報警。操作員operator為監(jiān)控部分過程所分配的特定用戶。更新事件訂閱，以提供考慮保持的所有報警。報警處于的一種狀態(tài)，該狀態(tài)是希望將客戶端條件狀態(tài)與服務(wù)器的狀態(tài)進(jìn)行同步的客戶端所關(guān)在濾除設(shè)施上，當(dāng)某個報警引起操作員反感時，操作員可以暫時阻止該警報向操作員顯示。確定報警不會發(fā)生的邏輯準(zhǔn)則。下列縮略語適用于本文件。A&C:報警和條件(AlarmsandConditions)3參數(shù)類型參數(shù)類型A&E:報警和事件(AlarmsandEventDA:數(shù)據(jù)訪問(DataAccess)UA:統(tǒng)一架構(gòu)(UnifiedArchitecture)下列表格列出了本部分所使用的數(shù)據(jù)類型。表1列出了IEC62541-3中定義的基本數(shù)據(jù)類型，表2列出了IEC62541-4中定義的基本類型和數(shù)據(jù)類型。參數(shù)類型本部分定義了條件、對話條件和包括確認(rèn)能力的警報的信息模型。它是建立在IEC62541-3、每個條件實例都具有特定的條件類型。條件類型和派生類型是BaseEventType的子類型(見IEC62541-3和IEC62541-5)。本部分定義了許多行業(yè)中通用的類型。期望供應(yīng)商或其他標(biāo)準(zhǔn)化小組將定義從本部分中定義的通用基本類型派生出附加的條件類型。服務(wù)器支持的條件類型在服務(wù)器的地條件實例是條件類型的特定實現(xiàn)。由服務(wù)器決定這些實例是否也在服務(wù)器的地址空間中公開。4.10提供了有關(guān)條件實例的附加背景。條件實例應(yīng)具有惟一的標(biāo)識符以將它們與其他實例區(qū)分開。這4的先前狀態(tài)。引入條件分支來處理這個要求，并區(qū)分當(dāng)前狀態(tài)和先前狀態(tài)。每個條件分支都有一個BranchId,以將其與同一條件實例的其他分支區(qū)分開來。表示條件(主干)的當(dāng)前狀態(tài)的條件分支具有空的BranchId。服務(wù)器可為每個分支生成單獨的事件通知。當(dāng)由條件表示的狀態(tài)不需要進(jìn)一步關(guān)注基本條件狀態(tài)模型在圖1中示出。它由本部分中定義的各種條件子類型擴(kuò)展，并可由供應(yīng)商或其他標(biāo)準(zhǔn)化小組進(jìn)一步擴(kuò)展。條件的主要狀態(tài)是Disabled(禁用)和Enabled(啟用)。禁用狀態(tài)旨在允許在服務(wù)器或下面的服務(wù)器(在設(shè)備或某些下層系統(tǒng)中)上關(guān)閉條件。啟用狀態(tài)通常轉(zhuǎn)換進(jìn)入Disabled狀態(tài)會導(dǎo)致一個ConditionEvent(條件事件),在該條件返回到Enabled狀態(tài)之前不會生成后續(xù)EventNotification(事件通知)。服務(wù)器將生成用于啟用和禁用操作的AuditEvent(通過方法調(diào)用或某些服務(wù)器/供應(yīng)商特定的手段),而不是為每個Enabled或Disabled條件實例生成AuditEvent通知。更多信息見5.10.3中AuditAcknowledgeableConditions是基本條件類型的子類型。AcknowledgeableCoAckedState和ConfirmedState擴(kuò)展了由條件定義的Enabled狀態(tài)。狀態(tài)模型在圖2中示出。通過添加AckedState和(可選地)ConfirmedState來擴(kuò)展Enabled狀態(tài)。5AckedState=TRUEAckedState=FALSE基本確認(rèn)狀態(tài)模型如圖3所示。模型定義了AckedState。導(dǎo)致狀態(tài)改變的特定狀態(tài)改變?nèi)Q于服務(wù)器的實現(xiàn)。例如，在典型的報警模型中，改變被限制為轉(zhuǎn)換到活動狀態(tài)或確認(rèn)圖4示出了向基本確認(rèn)添加證實的更復(fù)雜的狀態(tài)模型。證實的確認(rèn)(ConfirmedAcknowledge)模型通常用于區(qū)分確認(rèn)某個條件的存在和已經(jīng)做出某事以解決該條6GB/T33863.9—2021/IEC62541-9:2一些系統(tǒng)要求保持條件的先前狀態(tài)一段時間。常見的用例是確認(rèn)過確認(rèn)轉(zhuǎn)換到活動狀態(tài)以及轉(zhuǎn)換到非活動狀態(tài)。具有嚴(yán)格安全規(guī)則的系統(tǒng)有時要多個條件分支也可用于其他用例，在這種情況下，條件的先前狀態(tài)快照(snapshot)需要執(zhí)客戶端可通過請求刷新訂閱來獲取處于關(guān)注的狀態(tài)的所有條件實例的當(dāng)客戶端通過調(diào)用ConditionRefresh(條件刷新)方法請求刷新。服務(wù)器將使用RefreshStartEvent來響應(yīng)。該事件后面是保持條件。服務(wù)器還可發(fā)送用刷新相關(guān)的事件通知分知?？蛻舳嗽诮邮盏絉efreshStartEvent的事件時，將所期間接收的任何新事件，而不將其標(biāo)記為可疑。客戶端還從作為刷新一部除可疑標(biāo)志。當(dāng)客戶端接收到RefreshEndEv關(guān)于條件刷新(ConditionRefresh),7GB/T33863.9—2021/IEC 為確?？蛻舳耸冀K被通知到，三個特殊的事件類型(RefreshEndEventType、RefreshStari8AckedState=TRUEAckedState9GB/T33863.9—2021/IEC本部分描述了每個方法需要生成的AuditEventType。例如，禁用方法具有對AuditConditionGB/T33863.9—2021/IEC以下條目定義了OPCUA報警和條件類型。圖7非正式地描述了這些類型的層級結(jié)構(gòu)。Limit會在IEC62541-5中定義會會GB/T33863.9—2021/IEC值引用數(shù)據(jù)類型建模規(guī)則IEC62541-4中定義的StateVariableType的子類型注：對該子類型的引用在StateVariableType的定義中沒有顯示。ConditionVariable由表4中正式定義的ConditionVariableType表示。值引用數(shù)據(jù)類型建模規(guī)則IEC62541-5中定義了BaseDataVariableType的子類型SourceTimestamp指示該ConditionVariable的值的最后一次改變時間。它應(yīng)是在條件變量值屬性的DataValue結(jié)構(gòu)內(nèi)從讀服務(wù)返回的相同時間。有子狀態(tài)的TwoState狀態(tài)機(jī)。這些引用僅在子狀態(tài)可用時存在。使用這種方法，TwoStateVariables可與IEC62541-5中定義的StateMachineType類似的方式用下屬狀態(tài)機(jī)進(jìn)行擴(kuò)展。HasTrueSubState引用類型是一個可直接使用的具體引用類型。它是NonHierarchicalReferences語義表示該子狀態(tài)(目標(biāo)節(jié)點)是TRUE超(super)狀態(tài)的下屬狀態(tài)。如果條件中多于一個狀態(tài)是相同超狀態(tài)的子狀態(tài)(即對于相同超狀態(tài)存在幾個HasTrueSubState引用),則它們都被視為獨立子狀態(tài)。表5規(guī)定了在地址空間中的表示法。引用的源節(jié)點應(yīng)是TwoStateVariableType的一個實例，而目標(biāo)節(jié)點應(yīng)是一個TwoStateVariableType的實例或者一個StateMachineType的子類型實例。它不需要提供從超狀態(tài)到子狀態(tài)的HasTrueSubState引用，但要求子狀態(tài)提供反向引用(IsTrue值引用HasFalseSubState引用類型是一個可直接使用的具體引用類型。它是NonHierarchicalReferences語義表示該子狀態(tài)(目標(biāo)節(jié)點)是FALSE超狀態(tài)的下屬狀態(tài)。如果條件中多于一個狀態(tài)是相同超狀態(tài)的子狀態(tài)(即對于相同超狀態(tài)，存在幾個HasFalseSubState引用),則它們都被視為獨立子狀態(tài)。表6中規(guī)定了在地址空間中的表示法。引用的源節(jié)點應(yīng)是TwoStateVariableType的一個實例，而目標(biāo)節(jié)點應(yīng)是一個TwoStateVariable它不需要提供HasFalseSubState引用從超狀態(tài)到子狀態(tài)，但是要求子狀態(tài)提供反向引用(IsFalse值引用條件模型通過定義條件類型擴(kuò)展了事件模型。條件類型引入了將它與基本事件模型區(qū)分開的狀態(tài)的概念。與基本事件類型不同，條件不是暫時的。條件類型進(jìn)一步擴(kuò)展為DialogConditionTypes和BaseEventTypeBaseEventTypeConditionType定義條件的所GB/T33863.9—2021/IEC值引用數(shù)據(jù)類型建模規(guī)則IEC62541-5中定義了BaseEventType的子類型ConditionType繼承BaseEventType的所有特性。它們的語義在IEC62541-5中定義。ConditionClassName提供CoGB/T33863.9—2021/IEC對于與條件實例的當(dāng)前狀態(tài)相關(guān)的所有事件通知，BranchId為空。如果BranchId不為空，則 該列表可能不是全面的。子類型可定義觸發(fā)事件通知的其他變量。對類型TwoState條件實例的NodeId用作Conditionld。它沒有明確地被建模為ConditionType的一個組件。表8定義了SimpleAtributeOperand以在EventF無5.5.3條件和分支實例條件實例可以是出現(xiàn)在服務(wù)器地址空間中的對象。如果是這種情況，ConditionId是對象的NodeId。結(jié)果代碼Bad_ConditionAlreadyDisa表9規(guī)定了Disable方法的地址空間表示法。值引用數(shù)據(jù)類型建模規(guī)則AuditConditionEnableEventTEnable用于將條件實例改變?yōu)镋nable狀態(tài)。通常，通過瀏覽地址空間中的條件實例來找到傳遞給Call服務(wù)的MethodId。但是，某些服允許客戶端通過指定ConditionId為ObjectId,以及指定關(guān)于ConditionType的方法聲明的NodeId作為MethodId,來調(diào)用Enable方法。結(jié)果代碼Bad_ConditionAlreadyEna表10規(guī)定了Enable方法的地址空間表示法。表10Enable方法的地址空間定義值引用數(shù)據(jù)類型建模規(guī)則AuditConditionEnableEventT務(wù)器都應(yīng)允許客戶端通過指定ConditionId為ObjectId,以及指定關(guān)于ConditionType的方法聲明的NodeId作為MethodId,來調(diào)用AddComment方法。不能在Conditiontype節(jié)點上調(diào)用該方法。[in]LocalizedTextEventId標(biāo)識為某個條件報告狀態(tài)的結(jié)果代碼用于指示指定的條件無效，或在ConditionTyp節(jié)點上調(diào)用了該方法將注釋添加到通過EventId標(biāo)識的事件發(fā)生。完全不支持注釋的相關(guān)EventType的EventId都被ConditionEvent(注釋變量包含此文本)將被發(fā)送用于標(biāo)識的狀態(tài)。如果將注釋添加到先前的狀態(tài)(即服務(wù)器已經(jīng)創(chuàng)建了分支的狀態(tài)),則將報告該分支的BranchId和所有Condition值。表11規(guī)定了AddComment方法的地址空間表示法。表11AddComment方法地址空間定義值引用數(shù)據(jù)類型建模規(guī)則AuditConditionCommentEventTConditionRefresh允許客戶端請求所有條Retain標(biāo)志)。這包括服務(wù)器維護(hù)分支的條件實例的先前狀態(tài)。當(dāng)客戶端最初連接到服務(wù)器時，以及刷新訂閱的有效SubscriptionIdBad_SubscriptionIdInva)該服務(wù)器發(fā)出一個RefreshStartEvent(在5.11.2中定義),標(biāo)記刷新的開始。RefreshStartEvent的副本被排入訂閱中每個事件MonitoredItem的事件流。每個事件副本b)該服務(wù)器發(fā)出滿足訂閱內(nèi)容過濾條件的保留條件和保留分支的條件的事件通知。注意，這種刷新通知的EventId應(yīng)與原始通知的EventId相同。c)該服務(wù)器可以將以前沒有發(fā)出的新事件通知連同那些正發(fā)送的作為Refresh請求一部分發(fā)布給通知者。客戶端應(yīng)檢查ConditionBd)該服務(wù)器發(fā)出的RefreshEndEvent(在5.11.3中定義)表示刷新結(jié)束。RefreshEndEvent的副本被排入訂閱中每個事件MonitoredItem的事件流。每個事件副本應(yīng)包含相同的EventId。表12規(guī)定了ConditionRefresh方法的地址空間表示法。值引用數(shù)據(jù)類型建模規(guī)則對話模型是條件模型的擴(kuò)展，用于服務(wù)器請求用戶輸入。它提供了與大多數(shù)對話類似的功能。通過在ResponseOptionSet中提供服務(wù)器特定響應(yīng)選項并給派生的條件類型添加附DialogConditionTyoe用對話來表達(dá)條件。其圖解如圖9所示，其正式定義見表13。值引用數(shù)據(jù)類型建模規(guī)則見附錄A。 GB/T33863.9—2021/IEC——Abort,Retry,Ignore;——Retry,Cancel:——Yes,No。值為-1。ResponseOptionSet數(shù)組的所選索引結(jié)果代碼Bad_DialogResponseInv值引用數(shù)據(jù)類型建模規(guī)則AuditConditionResponGB/T33863.9—2021/IEC65.7可確認(rèn)的條件模型可確認(rèn)的條件模型擴(kuò)展了條件模型。它對條件模型添加了可確認(rèn)和AcknowledgeableConditions由該ConditionType的子類型AcknowledgeableConditionType來表5.7.2AcknowledgeableCAcknowledgeableConditionType通過定義可確認(rèn)特征來擴(kuò)展ConditionType。它是一種抽象的類Acknowledgeable圖10AcknowledgeableConditionType概述值A(chǔ)cknowledgeableConditionT引用建模規(guī)則AcknowledgeableConditionType繼承ConditionType的所有特性。當(dāng)AckedState為FALSE時，指示條件實例需要對所報告的條件狀態(tài)進(jìn)行確認(rèn)。當(dāng)條件實例被確GB/T33863.9—2021/IEC按4.4中的規(guī)定創(chuàng)建該條件實例的分支。期望客戶AcknowledgeableConditionType的方法聲明的NodeId作為MethodId,來調(diào)用Acknowledge方法。在僅能夠確認(rèn)AckedState/Id是FAL結(jié)果代碼Bad_ConditionBranchAlreadyA用于指示特定條件無效或該方法在該條件類型節(jié)點上被調(diào)用表16Acknowledge方法地址空間定義值引用數(shù)據(jù)類型建模規(guī)則5.7.4Confirm方法Confirm被用來證實ConfirmedState設(shè)置為FALSE的條件實例狀態(tài)的事件通知。通常，通過在公開條件實例。因此，所有服務(wù)器應(yīng)允許客戶端通過指定ConditionId作為ObjectId和指定關(guān)于Ac-knowledgeableConditionType的方法聲明的NodeId作為MethodId,來調(diào)用Confirm方法。在Ac-knowledgeableConditionType節(jié)點上不能調(diào)用該方法。[in]LocalizedText表17Confirm方法參數(shù)僅能夠證實ConfirmedState/Id是TR結(jié)果代碼Bad_ConditionBranchAlreadyConfi用于指出該特定條件無效或該方法在該條件類型節(jié)點上被調(diào)用服務(wù)器負(fù)責(zé)確保每個事件具有惟一的EventId。這允許客戶端標(biāo)識并證實特定的事件通知。該EventId標(biāo)識一個報告了被證實狀態(tài)的特定事件通知?？商峁┳⑨屵m用于以EventId標(biāo)識的有效的EventId將導(dǎo)致ConfirmedsState/Id設(shè)置為TRUE的事件通知，注釋特性包含可選注釋參GB/T33863.9—2021/IEC62541-9:2012表18規(guī)定了該方法指定地址空間的表示法。值引用數(shù)據(jù)類型建模規(guī)則圖11非正式地描述了AlarmConditionType、其子類型和在事件類型層級結(jié)構(gòu)中的位置。NonExclusiveLimitNonExclusiveNonExclusivekkk-擴(kuò)展了AcknowledgeableConditionType。報警模型見圖12。該圖不是一個完整的定義。其正式定義見表19。圖12報警模型值引用數(shù)據(jù)類型建模規(guī)則在5.7.2中定義了AcknowledgeableConditionGB/T33863.9—2021/IECShelvingState建議是否應(yīng)(暫時)阻止對用戶顯示某個報警。它經(jīng)常用來阻止誤報警。SuppressedState和Shelv持續(xù)時間的上限。如果該特性存在，它也將對OneshotShelved狀態(tài)強(qiáng)制執(zhí)行，即如果在特性規(guī)定的持續(xù)時間期滿，則警報條件將從成的轉(zhuǎn)換，當(dāng)定義為“TimedshelvedCall”一部分的時間值到期時發(fā)生此轉(zhuǎn)換?！癆nyTransitionGB/T33863.9—2021/IEC圖13擱置狀態(tài)轉(zhuǎn)換ShelvedStateMachine包括子狀態(tài)層級結(jié)構(gòu)。它支持所有在Unshelved、OneShotShelved和值引用數(shù)據(jù)類型建模規(guī)則FiniteStateMachineType的子類在IEC6254UnshelvedToOneShotShUnshelveTime規(guī)定了直到TimedShelved狀態(tài)或(對于提供MaxTimeShelved特性的情況)One-shotShelved狀態(tài)自動地轉(zhuǎn)換進(jìn)入UnShelved狀態(tài)的剩余時間(按毫秒計)。在表21中描述了這些狀態(tài)和轉(zhuǎn)換。該狀態(tài)機(jī)還支持三種方法：TimedShelve、OneShotShelve和引用值UnshelvedToTimedSheUnshelvedToOneShotSheTimedShelvedToOneShotSOneShotShelvedToTime5.8.4Unshelve方法Unshelve設(shè)置報警條件為Unshelved狀態(tài)。結(jié)果代碼Bad_ConditionNotShe表22規(guī)定了Unshelve方法的地址空間表示法。表22Unshelve方法地址空間定義值引用數(shù)據(jù)類型建模規(guī)則TimedShelve設(shè)置報警條件為TimedShelved狀態(tài)。規(guī)定該報警被擱置的固定時間。服務(wù)器可以拒絕提供的存在MaxTimeShelved特性，則擱置時間應(yīng)小結(jié)果代碼Bad_ConditionAlreadyShe該報警已處于TimedShelved狀態(tài)，并且系Bad_ShelvingTimeOutOfR供的持續(xù)時間。該限制可能會公開為MaxTimeShelved特性。表23規(guī)定了TimedShelve方法的地址空間表示法。表23TimeShelve方法地址空間定義值引用數(shù)據(jù)類型建模規(guī)則OneShotShelve設(shè)置報警條件為OneShotShelved狀結(jié)果代碼表24規(guī)定了OneShotShelve方法的地址空間表示法。值引用數(shù)據(jù)類型建模規(guī)則AuditConditionShelvingEventTLimitAlarm是一種抽象類型，用于為具有多個限值的報警條件提供基本類型。LimitAlarm的圖釋見圖15。NonExclusiveLimit圖15LimitAlarmTypeLimitAlarmType的正式定義見表25。GB/T33863.9—2021/IEC62541-9:2012值引用數(shù)據(jù)類型建模規(guī)則AlarmConditionType的子類型在5.8.2在中定義定義了四個可選限值來配置派生限值報警類型的狀態(tài)。對于通限值應(yīng)設(shè)置這些特性。這些特性作為可選特性當(dāng)某個值等于限值時，所列出的報警限值可能引起報警產(chǎn)生；或某個值超過限值(即該值高于HighLimit或低于LowLimit限值)時，所列出的報警限值可能產(chǎn)生報警。關(guān)于等于限值的準(zhǔn)確行為是ExclusiveLimitStExclusiveLimitStateMachine定義了處理多個相互排斥限值的報警類型所使用的狀態(tài)機(jī)，如圖16GB/T33863.9—2021/IEC6它通過擴(kuò)展StateMachineType來創(chuàng)建。其形式定義見表26,在表27中描述了狀態(tài)轉(zhuǎn)換。值ExclusiveLimitStateM引用數(shù)據(jù)類型建模規(guī)則GB/T33863.9—2021/IEC62541-9:20引用目標(biāo)瀏覽名稱值目標(biāo)類型定義ExclusiveLimitStateMachine定義了代表多層報警處于活動狀態(tài)時實際層級的子狀態(tài)機(jī)。這里定義的子狀態(tài)機(jī)包括high、low、highigh和lowlow狀態(tài)。該模型還包括在其轉(zhuǎn)換狀態(tài)中的一系列轉(zhuǎn)ExclusiveLimExclusiveLimitAlarm用于規(guī)定具有多個相互排斥限值的報警類型的通用行為。ExclusiveLimitAlarm的圖釋如圖17所示。GB/T33863.9—2021/IEC6EnableStateCoExclusiveLimitStateMachExclusiveLimitAlarmType的正式定義見表28。值引用建模規(guī)則LimitAlarmType的子類型在5在中定義在中定義在中定義LimitState表示ExclusiveLimitAlarm處于活動狀態(tài)時的實際限值偏離。5.8.9NonExclusiveLimitAlarmTypeNonExclusiveLimitAlarmType用作規(guī)定多種非排斥限值的報警類型的通用行為。NonExclusiveLimitAlarmType的圖釋見圖18。工tNonExclusiveLevelNonExclusiveLimitAl值NonExclusiveLimitAlarmT引用數(shù)據(jù)類型建模規(guī)則LimitAlarmType的子類型在5NonExclusiveLevelAlarmTNonExclusiveDeviationAlarmTGB/T33863.9—2021/IEC62541-9:2定義了配置這些狀態(tài)的四個可選限值。即使所有的狀態(tài)都是可選項，至少應(yīng)提供HighState或LowState。HighState和LowState的定義意味著這些分組是相互獨立的。一個值不可能同時超出HighState值和LowState值。NonExclusive同時保持High狀態(tài)和HighHigh狀態(tài)處于活動狀態(tài)，應(yīng)使用該報警類型。NonExclusiveLevelAlarmType基于NonExclusiveLimitAlarmType。其正式定義見表30。值NonExclusiveLevelAlarmT引用數(shù)據(jù)類型建模規(guī)則NonExclusiveLevelAlarmType的子類型在5.8.9NonExclusiveLimitAlarmType沒有定義額外的特性。ExclusiveLevelAlarmTypeExclusiveLevelAlarmType是使用多個排斥性限值的特殊物位警報。其正式定義見表31。表31ExclusiveLevelAlarmTy值引用數(shù)據(jù)類型建模規(guī)則繼承了在中定義的ExclusiveLimiExclusiveLevelAlarmType沒有定義額外的特性。偏差報警通常用于報告過程值的期望設(shè)定值與實際測量值之間的超出偏差。GB/T33863.9—2021/IEC62541-9:20例如，如果設(shè)定值為10,高偏差報警限值設(shè)定為2,低偏差報警限值設(shè)定為-1。那么如果過程值降低到9以下，將進(jìn)入低子狀態(tài)；當(dāng)過程值大于12時，將進(jìn)入高子狀態(tài)。如果設(shè)定值變將相應(yīng)變?yōu)?0和13。NonExclusiveDeviNonExclusiveDeviationAlarmType是一種使用一個或多個非排斥狀態(tài)的特殊物位報警。例如，如NonExclusiveDeviationAlarmType基于NonExclusiveLimitAlarmType。其正式定義見表32。值NonExclusiveDeviationAlarmT引用數(shù)據(jù)類型建模規(guī)則NonExclusiveLimitAlarmType的子類型在5.8.9ExclusiveDeviationAlExclusiveDeviationAlarmType使用多個相互排斥的限值。其正式定義見表33。值ExclusiveDeviationAla引用數(shù)據(jù)類型建模規(guī)則繼承了在中定義的ExclusiveLimi變化率報警通常用于報告與值發(fā)生變化的速度相關(guān)的測量值出現(xiàn)異常變化GB/T33863.9—2021/IEC62541-物位變化率High限值為4m/min。如果該罐的物位變化率大于4m/min,則進(jìn)入High子狀態(tài)。NonExclusiveRateOfChanNonExclusiveRateOfChangeAlarmType是一種采用一個或多個非排斥性狀態(tài)的特殊物位報警。表34。表34NonExclusiveRateOfChangeAlar值NonExclusiveRateOfChangeAlarmT出處數(shù)據(jù)類型模型規(guī)則NonExclusiveLimitAlarmType的子類型在5.8.9NonExclusiveLimitAlarmType沒有定義附加特性。ExclusiveRateOfChanExclusiveRateOfChangeAlarmType采用多個相互排斥的限值。其正式定義見表35。值ExclusiveRateOfChangeAla出處數(shù)據(jù)類型模型規(guī)則繼承在中定義的ExclusiveLimiExclusiveLimitAlarmTy量的可能值(例如true/false,running/stopped/terminating)。本部分中定義的具有子類型的DiscreteAlarmTypedefined在圖19中示出。其正式定義見表36。GB/T33863.9—2021/IEC表36DiscreteAlarmType定義值出處數(shù)據(jù)類型模型規(guī)則AlarmConditionType的子類型在5.8.2值出處數(shù)據(jù)類型模型規(guī)則DiscreteAlarmType的子類型在中定義在中定義GB/T33863.9—2021/IEC62541-監(jiān)測的裝置部件出現(xiàn)非正常故障(如由于超載引起電機(jī)停止)時，報警變?yōu)榛顒拥摹Ｕ蕉x見表38。表38TripAlarmType定義值引用數(shù)據(jù)類型模型規(guī)則OffNormalAlarmType的子類型在中定義條件用于特定應(yīng)用領(lǐng)域(domain),如個條件分配到某個ConditionClass?？蛻舳丝梢允褂迷撎匦詠砗Y選出基本類(essentialclasses)。OPCUA為所有的ConditionClasses和在許多行業(yè)中使用的通用類定義了基本對象類型(ObjectType)。圖7非正式描述了該部分中定義的ConditionClass類型層級結(jié)構(gòu)。BaseObjectType△務(wù)器應(yīng)使用一個更明確的ConditionClass。所有ConditionClass類型來源于BaseConditionClassTyp其正式定義見表39。值引用數(shù)據(jù)類型模型規(guī)則BaseObjectType的子類型在IEC62541-值ProcessConditionCla引用數(shù)據(jù)類型模型規(guī)則BaseConditionClassType的子類型在.4MaintenanceConMaintenanceConditionClassType用來分類與維護(hù)相關(guān)的條件。其正式定義見表41。此處不提供值MaintenanceConditionClassT引用模型規(guī)則BaseConditionClassType的子類型在5.9.SystemConditionClassType用來分類與系統(tǒng)相關(guān)的條件。其正式定義見表42。系統(tǒng)條件出現(xiàn)在控制系統(tǒng)過程或監(jiān)測系統(tǒng)過程。此處不提供更多的定義。其他標(biāo)準(zhǔn)組織或供應(yīng)商將有望定義特定領(lǐng)域GB/T33863.9—2021/IEC值引用數(shù)據(jù)類型模型規(guī)則BaseConditionClassType的子類型在5.9.小AuditConditionAcknowlAuditConditionEventTypes通常用于對方法(Method)調(diào)用的響應(yīng)。然而，如果這種方法(Method)的功能通過其他特定服務(wù)器方式來執(zhí)行，則這些事件也應(yīng)被通知。在這種情況下，GB/T33863.9—2021/IEC62541-9:2012值A(chǔ)uditConditionEventT5.10.3AuditConditionEnab該事件類型用來指示某個條件實例的啟用狀態(tài)中的變化。其正式定義見表44。AuditConditionEnableEventT5.10.4AuditConditionCommen該事件類型用來報告AddComment動作。其正式定義見表45。值A(chǔ)uditConditionCommentEventT5.10.5AuditConditionRespon該事件類型用來報告Respond動作。其正式定義見表46。值A(chǔ)uditConditionRespondEventT該事件類型用來表示一個或多個條件的確認(rèn)或證實。其正式定義見表47。值A(chǔ)uditConditionAcknowledgeEventT5.10.7AuditConditionConfi該事件類型用來報告證實動作。其正式定義見表48。值A(chǔ)uditConditionConfirmEventT5.10.8AuditConditionShelvi該事件類型用來表示某個條件實例擱置狀態(tài)的變化。其正式定義見表49。值A(chǔ)uditConditionShelvingEventT圖22刷新相關(guān)事件層級5.11.2RefreshStartEventType該事件類型被服務(wù)器用來標(biāo)識刷新通知(RefreshNotification)周期的開始。在表50中正式定義值引用數(shù)據(jù)類型模型規(guī)則繼承在IEC62541-5中定義的SystemEventType特性，即，它具有對相同節(jié)點的HasProperty引用該事件類型被服務(wù)器用來標(biāo)識刷新通知(RefreshNotification)周期的結(jié)束。在表51中正式定義值引用數(shù)據(jù)類型模型規(guī)則繼承在IEC62541-5中定義的SystemEventType特性，即，它具有對相同節(jié)點的HasProperty引用5.11.4RefreshRequir該事件類型被服務(wù)器用來指示服務(wù)器中或該服務(wù)器下層子系統(tǒng)中的實使訂閱的條件狀態(tài)無效。在表52中正式定義了其在地址空間中的表示法。值引用數(shù)據(jù)類型模型規(guī)則繼承在IEC62541-5中定義的SystemEventType特性，即，它具有對相同節(jié)點的HasPropertyReferences子類型。在表53中正式定義了其在地址空間中的表示法。GB/T33863.9—2021/IEC是HasEventSource引用的目標(biāo)或HasEventSource的子類型。在第6章中定義了應(yīng)向用戶提供用于值引用Bad_ConditionAlreadyEna尋址的條件已被啟用Bad_ConditionAlreadyDisa尋址的條件已被禁用Bad_ConditionAlreadySheBad_ConditionBranchAlreadyABad_ConditionBranchAlreadyConfiBad_ConditionNotSheBad_DialogResponseInv所選的選項在ResponseOptionSet數(shù)組中是無效索引ConditionRefresh操作已經(jīng)在進(jìn)行中Bad_ShelvingTimeOutOfR所提供的擱置時間超過了服務(wù)器所允許的擱置范圍GB/T33863.9—2021/IEC服務(wù)器服務(wù)器裝置C客戶端可通過首先瀏覽跟隨HasEventSource引用(包括子類型，如HasNotifier引用)的GB/T33863.9—2021/IEC6罐區(qū)圖25示出了InstanceDeclaration中的HasCondition引用和HasEventSource引用的使用。它們在InstanceDeclarations上下關(guān)系中的HasEventSource引用和TypeDefinition節(jié)點的使用對事件罐類型罐類型A.1.1LocaleId“en”條件類型AcknowledgeableConditionTNonExclusiveLimitAlarmT條件類型顯示名稱A.1.2LocaleId“de”GB/T33863.9—2021/IEC條件類型AcknowledgeableConditionTNonExclusiveLimitAlarmTA.1.3LocaleId“fr”FALSE狀態(tài)名稱TRUE狀態(tài)名稱AcknowledgeableConditionT表A.5(續(xù))FALSE狀態(tài)名稱TRUE狀態(tài)名稱NonExclusiveLimitAlarmT表A.7推薦對話響應(yīng)選項Locale“en”Locale“de”Locale“fr”GB/T33863.9—2021/IEC62541-9:20下列示例示出了典型的報警情況下的事件流。表B.1和表B.2中列出了每個事件通知的狀態(tài)變量圖B.1單個狀態(tài)示例表B.1僅保持最新狀態(tài)的條件示例活動的確認(rèn)的證實的說明12345678“第一行用來說明條件的初始狀態(tài)。該狀態(tài)將不會被事件報告。GB/T33863.9—2021/IEC62541-9:2圖B.2說明了服務(wù)器對分支的使用，該服務(wù)器要求對所有進(jìn)入活動狀態(tài)的轉(zhuǎn)換而不僅僅是最近的先前的狀態(tài)先前的狀態(tài)當(dāng)前的狀態(tài)時間通知339?表B.2通過分支保持先前狀態(tài)的條件的示例活動的確認(rèn)的證實的說明1234已證實56GB/T33863.9—2021/IEC62541表B.2(續(xù))活動的確認(rèn)的證實的說明71先前狀態(tài)需要確認(rèn)。創(chuàng)建分支18912先前狀態(tài)需確認(rèn)。創(chuàng)建分支21先前狀態(tài)已證實。刪除分支12先前狀態(tài)已確認(rèn)，系統(tǒng)自動證實，刪除分支2第一行用來說明條件的初始狀態(tài)。該狀態(tài)將不會被事件報告。注1:如果條件的當(dāng)前狀態(tài)是已確認(rèn)，那么Acked標(biāo)志置位，并報告新的狀態(tài)(事件2)。如果條件狀態(tài)在它可以被確認(rèn)前就改變(事件6),則報告一個分支狀態(tài)(事件7)。對于事件6和7的時間戳是相同注2:在分支狀態(tài)被清除之前(事件12),它可被更新若干次(事件9注3:一個單一的條件可有許多分支狀態(tài)活動(事件11)。建議像在該表中一樣，只要先前的狀態(tài)(分支)存在，就讓“Retain=True及其相關(guān)條件的組織。該層級結(jié)構(gòu)是對Organizes和Aggregates引用提供的層級結(jié)構(gòu)的附加。圖B.3示出了帶條件實例的HasCondition引用的使用。GB/T33863.9—2021/IEC6對象對象服務(wù)器區(qū)域1罐區(qū)機(jī)器BHasCondition裝置BGB/T33863.9—2021/IEC服務(wù)器區(qū)域1PricssAlamExclusiveLimit本HasEventSourceExchusiveLevelMoyLevelAlarm7jpe機(jī)器B圖B.5示出了一個在類型系統(tǒng)中已經(jīng)定義了HasCondition引用的例子。該引用可指向一個條件類型或一個實例。在該例中示出了兩個變體。在類型系統(tǒng)中對一個條件類型的罐區(qū)罐區(qū)MjSystemAlarmTypeGB/T33863.9—2021/IEC表C.1列出了EEMUA的術(shù)語和OPCUA的術(shù)語如何映射到EEMUA的術(shù)語。OPCUA術(shù)語當(dāng)操作員已表明感覺到報警的存在時，報警被接在OPCUA中，這可以用Acknowle報警條件存在(即已超過限值，條件繼續(xù)存在)(在IEC62541-5中定義)向操作員提交的描述報警條件的測試信息(在IEC62541-5中定義)重的后果。在一些行業(yè)也被稱為提示或警告。現(xiàn)。例如，嚴(yán)重性低于50的報警可被視為警告即為報警被禁用當(dāng)操作員執(zhí)行一些系統(tǒng)不能執(zhí)行或需要操作授權(quán)執(zhí)行的過程當(dāng)產(chǎn)生報警的條件發(fā)生時，引發(fā)或發(fā)起一個報警“釋放”是一個工具，可以以類似于應(yīng)用擱置的方式應(yīng)用到一報警列表中刪除，并將其放在架子上。當(dāng)報警次引發(fā)時，它將以正常的方式出現(xiàn)在報警列表中OPCUA包括Retain標(biāo)志，作為其定義狀態(tài)的部分：“當(dāng)客戶端接收到Retain標(biāo)志設(shè)置為FALSE的下，條件/分支將從顯示中被刪除”擱置是一種工具，其應(yīng)用場合是：當(dāng)報警妨員能暫時阻止報警被顯示給操作員。擱置的報警將從列表中表C.1(續(xù))OPCUA術(shù)語EEMUA定義當(dāng)報警條件一直存在時，報警就為持續(xù)有效(引發(fā)和持續(xù)有效經(jīng)常被互換使用)”即使基本報警條件(例如報警設(shè)置已超過)是存在的，但當(dāng)采用的邏輯判據(jù)判定不應(yīng)該發(fā)生報警時，報警即被抑制當(dāng)操作員已表明感覺到報警的存在時，報警被接受。在前述從OPCA&E至OPCUAA&C的映射A&ECOM服務(wù)器中的事件區(qū)在A&ECOMUA包裝器中表示為具有BaseObjectType的根區(qū)域被表示為取決于UA服務(wù)器的帶BrowseName的對象。它總是成為來自服務(wù)器節(jié)點的區(qū)域?qū)蛹壗Y(jié)構(gòu)通過采用BrowseOpcArea和GetQualifiedAreaName方法來發(fā)現(xiàn)。由Browse惟一URI。每個區(qū)域均是來自其父區(qū)域的HasNotifier的引用目標(biāo)。它可能是對其子區(qū)域的一個或多個A&ECOM服務(wù)器中的事件源在A&ECOMUA包裝器中表示為具有BaseObjectType的簡單(Simple)事件類型是BaseEventType的直接子類型。跟蹤(Tracking)事件類型是每個ConditionName-ObjectType的NodeId是由COMAE服務(wù)器所分配的事件類型、EventCategoryID和ConditioBaseEventType水屬性1屬性2屬性1AlarmTypeConditionCategoryY屬性1屬性3GB/T33863.9—2021/IECA&ECOM服務(wù)器中的事件屬性在UA服務(wù)器中表示為HasProperty引用的目標(biāo)的變量，表D.1列出了A&ECOMUA包裝器所采用的ONEVENTSTRUCT內(nèi)的字段如何映射到UAONEVENTSTRUCT字段區(qū)域是COMAE服務(wù)器的默認(rèn)區(qū)域表D.2列出了由A&ECOMUA包裝器所用的ONEVENTSTRUCT內(nèi)的字段如何映射到UAONEVENTSTRUCT字段只設(shè)置用于跟蹤事件設(shè)置為COMAE服務(wù)器NamespaceURI表D.3列出了由A&ECOMUA包裝器所用的ONEVENTSTRUCT內(nèi)的字段如何映射到UAONEVENTSTRUCT字段總是設(shè)置為BaseConditionClassType總是設(shè)置為“BaseConditionClass”總是設(shè)置為空若OPC_CONDITION_ACKED比特未設(shè)置或OPC_CONDITION_ACTIVE比特已設(shè)置，則設(shè)置設(shè)置為“Enabled”或“Disabled”若OPC_CONDITION_ENABLED已設(shè)置由wNewState標(biāo)志中的比特構(gòu)造的一個字符為選擇該字符串，應(yīng)用以下規(guī)則：若OPC_CONDITION_ENABLED未設(shè)置，則“Disabled”;若OPC_CONDITION_ACKED未設(shè)置，則“Unacknowledged”;若OPC_CONDITION_ACKED已設(shè)置，則“Active”;若OPC_CONDITION_ENABLED已設(shè)置，則“Enabled”COMDA質(zhì)量轉(zhuǎn)換為UA狀態(tài)碼基于條件實例所接收到的最后事件而設(shè)置。ACK_COMMENT屬性的值設(shè)置為“Acknowledged”或“Unacknowledged”若OPC__CONDITION_ACKED已設(shè)置，則設(shè)置為TRUE設(shè)置為“Active”或“Inactive”若OPC__CONDITION_ACTIVE已設(shè)置，則設(shè)置為TRUE區(qū)域為COMAE服務(wù)器的默認(rèn)區(qū)域GB/T33863.9—2021/IECA&ECOM客戶端僅僅需要了解尋址如何連至UAA&C服務(wù)器。連——屬于除AuditEventType或ConditionType以外的任何子類型的那些A&A&E事件類型Simple?！狝&ETracking類別包括：在AuditEventType和TransitionEventType的子類型(包括AuditEventType自身和TransitionEventType自身在內(nèi))的層級結(jié)構(gòu)中所定義的所有事件類——A&ESimple類別包括：除AuditEventType和ConditionType及其各自的子類型外，GB/T33863.9—2021/IECUA條件類型BaseEvent類別3:AlarmConditionType個AlarmCondition與任何給定的A&E事件相關(guān)聯(lián)的屬性集合被封裝在ONEVENTSTRUCT內(nèi)。因此，A&EA&EONEVENTSTRUCT“屬性”以下各項都對應(yīng)于所有的A&E事件類型UABaseEventType特性：SourcUABaseEventType特性：MeUABaseEventType特性：Sev表D.4(續(xù))A&.EONEVENTSTRUCT“屬性”以下各項僅對應(yīng)于A&E條件相關(guān)事件UAConditionType特性：ConditioUAActiveState特性：EffectiveDisplaA&CAlarmConditionType特性：ActiveStA&.CConditionType特性：EnabledStA&.CAcknowledgeableConditionType特性：AckedSt的事件，均默認(rèn)設(shè)置為UNACKNOWLEDGED且AckRequiredA&CConditionType特性：Qual注：映射為非條件事件的事件均默認(rèn)設(shè)置為OPC_QUALITY_GOO通常，StatusCode的Severity字段是用于映射CQUALITY_BAD、OPC__QUALITY_GOOD和OPC__QUALITY_UNCERTAIN?？赡軙r，特殊狀態(tài)直接映射。這些包括(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)已設(shè)置，則Ack要求的表D.4(續(xù))A&EONEVENTSTRUCT“屬性”若事件是AlarmConditionType類型或子類型，且ActiveState從FALSE到工后的時間特性屬性適用于發(fā)布。若事件不是AlarmConditionType類型或子類型，則該字段設(shè)置為當(dāng)前時間由A&.ECOMUA代理服務(wù)器生成。這些惟一的條件事件cookies不與來自UAA&C服務(wù)器的地址空間的任何相關(guān)標(biāo)識符關(guān)聯(lián)以下各項僅適用于A&E跟蹤事件和確認(rèn)通知的A&E條件相關(guān)事件供應(yīng)商特定屬性——全部(ALL)假定全部A&E事件均支持“Areas”屬性。但是，沒有一個A&C事件的任何屬性或特性可以提供這個值。因此，A&ECOMUA代理服務(wù)器基于生成該事件的監(jiān)視項來初始化該Areas屬性的值。若A&訂閱未采用區(qū)域過濾，則相應(yīng)的A&C訂閱將只A&.CServer對象。代表該訂閱轉(zhuǎn)發(fā)給A&ECOM客戶端的事件會濾，則相關(guān)的UAA&C訂閱會對由區(qū)域字符串所標(biāo)含一個或多個監(jiān)視項。轉(zhuǎn)發(fā)給A&ECOM客戶端的事合格的區(qū)域名稱)供應(yīng)商特定屬性——基于類別不是由BaseEventType或ConditionType所公條件事件實例記錄被就地存儲在A&ECOMUA代理中。每個記錄都持有每個EventSource/條件實例的oneventstruct數(shù)據(jù)。當(dāng)條件實例轉(zhuǎn)換至INACTIVE|ACKED狀態(tài)時，在AckRequired=生成至任何訂閱客戶端的OnEvent回調(diào)。在客戶端應(yīng)用確認(rèn)當(dāng)前未確認(rèn)的(AckRequired=TRUE)一指示轉(zhuǎn)換已確認(rèn)的后續(xù)事件會導(dǎo)致對本地條件記錄的當(dāng)前狀態(tài)的更新，以及對任何訂閱客戶端的A&ECOMUA代理服務(wù)器保持基于事件類別的屬性映射。事件類別繼承了在UA事件類型層級結(jié)構(gòu)中的所有超類型所定義