MonitoredItem

每個(gè)監(jiān)控項(xiàng)均指明了要監(jiān)控的項(xiàng)目（item）和用來發(fā)送通知的訂閱。
item可以是一個(gè)節(jié)點(diǎn)的屬性（node attribute）。

MonitorItem可以監(jiān)控一個(gè)屬性，一個(gè)變量或者一個(gè)事件
可以通過MonitorItem定義的過濾器（fiter)，來決定是否產(chǎn)生一個(gè)通知
Queue attribute定義了可以被緩存的通知數(shù)量，可以通過配置策略決定丟棄新消息還是最老的消息

Triggering model

MonitoredItem服務(wù)允許某item只有在關(guān)聯(lián)Item被觸發(fā)時(shí)才會(huì)被觸發(fā)
這是通過在觸發(fā)對(duì)象和被觸發(fā)對(duì)象間建立連接來實(shí)現(xiàn)的

Notification

描述了數(shù)據(jù)變化和事件的數(shù)據(jù)結(jié)構(gòu)，通知會(huì)被打包為NotificationMessage并傳送給Client。
訂閱會(huì)以客戶定義的發(fā)布間隔周期性的發(fā)送NotificationMessage。

Subscription

訂閱用來向客戶端報(bào)告通知，其行為可以被總結(jié)如下：

訂閱包含一組由客戶端分配的監(jiān)控項(xiàng)。監(jiān)控項(xiàng)可以生成通知，這些通知，由訂閱發(fā)送給客戶端
訂閱擁有一個(gè)發(fā)布間隔，訂閱的發(fā)布間隔定義了訂閱執(zhí)行的循環(huán)率。每次執(zhí)行，訂閱均試圖發(fā)送一條NotificationMessages，NotificationMessages中包含了還沒有報(bào)告給客戶端的通知
訂閱以回應(yīng)發(fā)布請(qǐng)求的方式向客戶端發(fā)送NotificationMessages。發(fā)布請(qǐng)求通常以接收順序存儲(chǔ)到Session中，當(dāng)有通知需要發(fā)送時(shí)，在每次發(fā)布循環(huán)時(shí)，會(huì)從隊(duì)列中取出相應(yīng)的請(qǐng)求，并發(fā)送通知到客戶端，如果沒有待發(fā)送通知，請(qǐng)求則不會(huì)從隊(duì)列中被刪除
在循環(huán)的開始，如果已經(jīng)存在待發(fā)送通知但還沒有發(fā)布請(qǐng)求，服務(wù)器將會(huì)進(jìn)入等待狀態(tài)，一旦接收到發(fā)布請(qǐng)求，則立即向客戶端發(fā)送通知，無需等待另外一次循環(huán)
訂閱有一個(gè)存活計(jì)數(shù)器，保存了沒有發(fā)送通知的周期循環(huán)次數(shù)，當(dāng)循環(huán)次數(shù)達(dá)到用戶在創(chuàng)建訂閱時(shí)配置的預(yù)置，則會(huì)發(fā)送一條存活消息到客戶端，同時(shí)從隊(duì)列中取出一條發(fā)布請(qǐng)求，用于表示該訂閱仍然處于存活狀態(tài)。存活NotificationMessage中不包含通知，但包含下一條消息的序列號(hào)
訂閱是否發(fā)布通知可以由客戶端在創(chuàng)建時(shí)指定，也可以后續(xù)通過SetPublishMode服務(wù)設(shè)置，設(shè)置為Fasle時(shí)，訂閱將停止向客戶端推送通知，但是訂閱會(huì)繼續(xù)執(zhí)行，且持續(xù)發(fā)送存活消息
訂閱包含一個(gè)壽命計(jì)數(shù)器，保存了在沒有發(fā)布請(qǐng)求時(shí)經(jīng)歷的循環(huán)次數(shù)，當(dāng)達(dá)到閾值時(shí)，會(huì)刪除這個(gè)訂閱以及與訂閱相關(guān)的監(jiān)控項(xiàng)。在刪除訂閱時(shí)，會(huì)發(fā)送一條StateChangeNotification消息，并攜帶狀態(tài)碼Bad_Timeout
Session維護(hù)了已發(fā)送通知的轉(zhuǎn)發(fā)隊(duì)列，只有當(dāng)客戶端確認(rèn)消息接收后，才會(huì)從隊(duì)列宗移除，服務(wù)器應(yīng)當(dāng)保存有兩倍于發(fā)送請(qǐng)求數(shù)量的消息，這種能力可以由服務(wù)器的profile定義，如果轉(zhuǎn)發(fā)隊(duì)列滿，則刪除最舊的消息。當(dāng)訂閱被轉(zhuǎn)移到另外的session時(shí)，轉(zhuǎn)發(fā)隊(duì)列同時(shí)也需要遷移過去

序列號(hào)是一個(gè)UINT32，并從1開始向前滾動(dòng)。
當(dāng)訂閱創(chuàng)建后，在第一個(gè)周期結(jié)束時(shí)，會(huì)向client發(fā)送一條消息，用于通知客戶端訂閱可用。如果有通知要發(fā)送，則發(fā)送NotificationMessage，如果沒有，則發(fā)送存活消息，并設(shè)置序列號(hào)為1，這是唯一不需要等待到keep alive閾值的場(chǎng)景。
客戶端接受消息要比發(fā)布周期更加頻繁，因一個(gè)發(fā)布周期可能包含有多條消息，但客戶端可以設(shè)置服務(wù)器不緩存發(fā)布通知來減輕壓力，但會(huì)增加響應(yīng)的延時(shí)。
在訂閱的聲明周期中，序列號(hào)不會(huì)被重置，也即在40億消息中不會(huì)出現(xiàn)重復(fù)的消息ID。
消息序列號(hào)還可以用于消息重發(fā)。
訂閱被設(shè)計(jì)為獨(dú)立于具體的通信協(xié)議，短暫的連接丟失不會(huì)導(dǎo)致丟失數(shù)據(jù)和事件。在設(shè)計(jì)時(shí)，要確保該特性得以正確實(shí)現(xiàn)，也即能夠處理較長時(shí)間的通訊中斷和有計(jì)劃斷鏈。如果服務(wù)器支持該特性，服務(wù)器的緩存區(qū)將會(huì)設(shè)計(jì)的比較大。

HasEventSource

HasEventSource引用類型是一個(gè)具體的引用類型，并可以直接被使用，是HierarchicalReferences的子類。
這個(gè)引用類型的語義是將event source（事件源）以一種層次化的、非循環(huán)的方式關(guān)聯(lián)起來。該類型以及該類型的所有子類是打算用來幫助發(fā)現(xiàn)服務(wù)器能夠產(chǎn)生的事件。但對(duì)于服務(wù)器來說，并不需要強(qiáng)制的建立從事件源（EventSource，產(chǎn)生事件）到事件通知器的關(guān)系，例如server對(duì)象，其隱含的表示是所有事件源的通知器。
該關(guān)系的起點(diǎn)是一個(gè)事件訂閱的源（一個(gè)對(duì)象，該對(duì)象的EventNotifer屬性的SubscribeToEvent位有效）。
該關(guān)系的終點(diǎn)可以是任意NodeClass節(jié)點(diǎn)，只要該節(jié)點(diǎn)能夠通過訂閱產(chǎn)生事件通知，并傳遞給關(guān)系源端。
另外，從”A“點(diǎn)開始，沿著HasEventSource或其子關(guān)系不能再回到A點(diǎn)，但是允許存在多條路徑都指向節(jié)點(diǎn)“B“。

HasNotifier

HasNotifier引用也是一個(gè)可以被直接使用的關(guān)系。
HasNotifier引用的語義是將作為通知器的節(jié)點(diǎn)與其他通知器對(duì)象節(jié)點(diǎn)關(guān)聯(lián)起來。該引用的目的是建立事件通知對(duì)象（event notifying object）的層次化結(jié)構(gòu)，而且HasNotifer是HasEventSource的子類。
該引用的起點(diǎn)需要是能夠作為事件訂閱源的對(duì)象或視圖，終點(diǎn)同樣。事件訂閱源是指EventNotifier屬性中“SubscribeToEvents”生效的對(duì)象。
如果HasNotifier引用的終點(diǎn)產(chǎn)生了一個(gè)事件，那么該引用的起點(diǎn)同樣可以提供這個(gè)事件。也即通過HasNotifier引用，可以建立起事件通知的層次。

Alarm

告警是AcknowledgeConditions的特殊化，相比Condition告警增加了活動(dòng)狀態(tài)，以及擱置和抑制狀態(tài)。

告警如果處于活動(dòng)狀態(tài)（Active）則表明條件所表示的狀況正在發(fā)生，如果Active=False則表明處于正常狀態(tài)

有些告警會(huì)引入Active狀態(tài)的子狀態(tài)，入high level state與critical high state

擱置狀態(tài)（Shelved）可以由操作員通過OPC UA方法設(shè)置，抑制狀態(tài)（Suppressed）由服務(wù)器出于內(nèi)部原因設(shè)置，告警服務(wù)器通常會(huì)實(shí)現(xiàn)抑制、擱置和停止服務(wù)特性，以避免操作員被告警風(fēng)暴淹沒，而能夠?qū)Ｗ⒂谡嬲龂?yán)重的告警
擱置、抑制和停止服務(wù)狀態(tài)與Disable狀態(tài)不同，它們表明告警仍然生效，并繼續(xù)通過訂閱分發(fā)至客戶端

下圖描述了典型的告警時(shí)間線：


在值達(dá)到Alarm Limit時(shí)，產(chǎn)生了告警

在Ack Delay期間，告警處于Unacknowledged狀態(tài)，也即在此時(shí)間段內(nèi)，操作員沒有感知到告警，因此未進(jìn)行操作
當(dāng)操作員感知到告警，并確認(rèn)后，告警進(jìn)入了Acknowledged狀態(tài)，此時(shí)操作員需要時(shí)間確認(rèn)這個(gè)告警并作出反應(yīng)，此時(shí)處于Operator Response Delay
之后采取行動(dòng)，進(jìn)入到Process Delay狀態(tài)，到操作生效為止
之后產(chǎn)生效果，值向下，并在經(jīng)過告警死區(qū)之后消除并轉(zhuǎn)入Normal狀態(tài)
如果不進(jìn)行操作，則值繼續(xù)上升并產(chǎn)生后果

Condition Instance

Condition通常會(huì)有狀態(tài)和子狀態(tài)，因此在AddressSpace中保存Condition的實(shí)例是有意義的。如果Server選擇暴露condition，那么condition通常是作為對(duì)象的一部分存在的，也即對(duì)象“擁有”這個(gè)條件。
如：
一個(gè)溫度傳感器內(nèi)置了高溫告警，則這個(gè)告警在地址空間中會(huì)以溫度傳感器實(shí)例的部件（hasComponent)關(guān)系的形式作為溫度傳感器的一部分，且這個(gè)告警是LimitAlarmType的實(shí)例。
有些時(shí)候可以選擇不在地址空間中暴露condition，這樣就沒有辦法修改condition的狀態(tài)。
告警和狀態(tài)的審計(jì)是系統(tǒng)中非常重要的安全功能，當(dāng)用戶調(diào)用方法更改Condition的狀態(tài)時(shí)，會(huì)產(chǎn)生AuditConditionAcknowledgeEventType類型的事件。

HasCondition Reference

該引用的語義是關(guān)聯(lián)ConditionSource和它的Condition，每個(gè)ConditionSource都應(yīng)該是HasEventSource或其子引用的目標(biāo)節(jié)點(diǎn)。
HasCondition關(guān)系可以用在VariabeType或者ObjectType之上，也可以用于它們的實(shí)例聲明，HasCondition的目標(biāo)節(jié)點(diǎn)則可以是ConditionType類型或者實(shí)例。

如果在類型中（ObjectType/VariableType）中有HasCondition關(guān)系，其實(shí)例也要繼承
如果類型中引用的是ConditionType，其類型實(shí)例也要指向該ConditionType
如果類型上不允許配置HasCondition，則可以在實(shí)例上增加

AddressSpace Sample

總結(jié)來說：

HasNotifer維護(hù)了一個(gè)通知器的層次，目的端產(chǎn)生的事件在源端可讀，由此可以在不同的通知器層次有針對(duì)性的讀取事件（如只讀Area1或者只讀Tank Farm）
HasEventSource用于指明事件生成的源，只有HasEventSource及其子類型所指向的目標(biāo)節(jié)點(diǎn)上可以由HasCondition關(guān)系
HasCondition關(guān)系表明了能夠具體生成的Condition/告警
通常的ConditionType對(duì)象是作為對(duì)象的一部分存在的，這里的MyAlarmTypeA實(shí)際上是從ConditionType繼承而來
某些服務(wù)器中，HasCondition的target節(jié)點(diǎn)可以是ConditionType

另外，在類型中定義的ConditionType是可以在實(shí)例中得到繼承的，如下圖所示：

幾個(gè)問題

Event、Condition和Alarm是什么關(guān)系

EventType是ConditionType的父類
ConditionType是AlarmType的父類
Event、Condition和Alarm是其實(shí)例
Event最為泛化，主要是定義了事件的基本屬性
Condition則擁有狀態(tài)
Alarm則擁有更多可被設(shè)置的狀態(tài)

HasEventSource、HasNotifier有什么區(qū)別

HasEventSource指明了事件產(chǎn)生的源
HasNotifier是HasEventSource的子類
HasNotifer組織的是一張通知器的網(wǎng)，關(guān)系的目標(biāo)節(jié)點(diǎn)所產(chǎn)生的事件在源端也可以看到，可供用戶定義自己查看事件的范圍
Condition只能加到HasEventSource的目標(biāo)節(jié)點(diǎn)上

GeneratesEvent、AlwaysGenerateEvent引用有什么區(qū)別

GeneratesEvent表明ObjectType，VariableType可能產(chǎn)生事件，以及Method在調(diào)用時(shí)可能產(chǎn)生事件
AlwaysGenerateEvent的起點(diǎn)只能是Method，且在每次調(diào)用時(shí)必然產(chǎn)生事件
GeneratesEvent和AlwaysGenerateEvent的終點(diǎn)只能是表示EventType及其子類

參考資料

《OPC統(tǒng)一架構(gòu)From馬克》2.10，4.9，5.7章節(jié)
《OPC UA Part 3 - Address Space Model Release 1.04 Specification》4.6, 7.15, 7.16, 7.17, 7.18章節(jié)
《OPC UA Part 4 - Services Release 1.04 Specification》5.12, 5.13章節(jié)
《OPC UA Part 9 - Alarms and Conditions Release 1.04 Specification》 第4章，第5章，第6章，附錄B.2節(jié)

總結(jié)

以上是生活随笔為你收集整理的OPC UA的监控项、订阅、和通知的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。