5.服務(wù)集
5.12 MonitoredItem服務(wù)集
5.12.1 MonitoredItem模型
5.12.1.1概述
客戶端定義MonitoredItems來訂閱數(shù)據(jù)和事件。每個MonitoredItem標識要監(jiān)視的項目和用于發(fā)送通知的訂閱定嗓。要監(jiān)控的項目可以是任何節(jié)點屬性蚁署。
通知是描述數(shù)據(jù)更改和事件發(fā)生的數(shù)據(jù)結(jié)構(gòu)供常。它們被打包到NotificationMessages中傳送給客戶端奄毡。訂閱以用戶指定的發(fā)布間隔周期性地發(fā)送NotificationMessages兵志，發(fā)送這些消息的周期稱為發(fā)布周期椎镣。
MonitoredItems定義了四個主要參數(shù)艺晴，它們告訴Server如何采樣冗美、評估和報告項目魔种。這些參數(shù)是采樣間隔、監(jiān)視模式粉洼、過濾器和隊列參數(shù)节预。圖15說明了這些概念叶摄。
除了Value Attribute之外，只監(jiān)視值的更改安拟。篩選器不用于這些屬性蛤吓。這些屬性值的任何更改都會生成一個Notification。
Value屬性在監(jiān)視變量時使用糠赦。對變量值進行監(jiān)視会傲，以了解其值的變化或狀態(tài)的變化。本標準(見7.17.2)和OPC 10000-8中定義的過濾器用于確定值的變化是否大到足以導(dǎo)致為變量生成通知拙泽。
對象和視圖可以用來監(jiān)視事件淌山。事件只在EventNotifier屬性的SubscribeToEvents位被設(shè)置的節(jié)點中可用。本標準中定義的過濾器(見7.17.3)用于確定從節(jié)點接收到的事件是否被發(fā)送到客戶端顾瞻。該過濾器還允許選擇EventType字段泼疑，將包含在事件中，如EventId, EventType, SourceNode荷荤，時間和描述王浴。
OPC 10000-3描述了事件模型和基本的EventTypes。
基本EventTypes的屬性和AddressSpace中基本EventTypes的表示在OPC 10000-5中指定梅猿。
5.12.1.2采樣間隔
客戶端創(chuàng)建的每個MonitoredItem都被分配一個采樣間隔氓辣，該采樣間隔要么繼承自訂閱的發(fā)布間隔，要么專門定義為覆蓋該速率袱蚓。負數(shù)表示請求由訂閱的發(fā)布間隔定義的默認采樣間隔钞啸。采樣間隔指示服務(wù)器對其底層源進行數(shù)據(jù)更改采樣的最快速率。
如果客戶訂閱事件喇潘，則客戶端應(yīng)定義采樣間隔為0体斩。
分配的采樣間隔定義了一個“最佳努力”循環(huán)率，服務(wù)器使用該循環(huán)率從其源對項目進行采樣颖低。在此上下文中絮吵，“盡最大努力”意味著服務(wù)器將盡最大努力以這種速度進行采樣〕佬迹可以接受比此速率更快的采樣速率蹬敲，但對滿足客戶的需求來說并不是必須的。Server如何處理采樣率以及它在內(nèi)部輪詢數(shù)據(jù)源的頻率是Server實現(xiàn)的細節(jié)莺戒。但是伴嗡，返回給客戶的值之間的時間間隔應(yīng)大于或等于采樣間隔。
客戶端也可以指定采樣間隔為0从铲，這表示服務(wù)器應(yīng)該使用最快的實際速率瘪校。預(yù)計服務(wù)器將只支持有限的采樣間隔集，以優(yōu)化它們的操作。如果服務(wù)器不支持客戶端請求的準確間隔阱扬，那么服務(wù)器將根據(jù)服務(wù)器確定的最合適的間隔分配給MonitoredItem泣懊。它將這個分配的間隔返回給Client。OPC 10000-5中定義的服務(wù)器能力對象確定了服務(wù)器支持的采樣間隔麻惶。
服務(wù)器可能支持基于抽樣模型收集的數(shù)據(jù)或基于異常模型生成的數(shù)據(jù)馍刮。支持的最快采樣間隔可能等于0，這表示該數(shù)據(jù)項是基于異常的用踩，而不是在一段時間內(nèi)采樣渠退。基于異常的模型意味著底層系統(tǒng)不需要采樣和報告數(shù)據(jù)更改脐彩。
客戶端可以使用修改后的采樣間隔值作為設(shè)置發(fā)布間隔和訂閱的保持活動計數(shù)的提示碎乃。例如，如果MonitoredItems的最小修改采樣間隔是5秒惠奸，那么發(fā)送keepalive之前的時間應(yīng)該大于5秒梅誓。
請注意，在許多情況下佛南，OPC UA服務(wù)器提供對解耦系統(tǒng)的訪問梗掰，因此不了解數(shù)據(jù)更新邏輯。在這種情況下嗅回，即使OPC UA Server以協(xié)商的速率進行采樣及穗，底層系統(tǒng)也可能以慢得多的速率更新數(shù)據(jù)。在這種情況下绵载，只能以較慢的速度檢測到更改埂陆。
如果底層系統(tǒng)更新項目的行為是已知的，它將通過OPC 10000-3中定義的MinimumSamplingInterval屬性可用娃豹。如果服務(wù)器為最小采樣間隔屬性指定了一個值焚虱，它將總是返回一個修正后的采樣間隔，該值等于或高于客戶端訂閱的最小采樣間隔懂版。
客戶端還應(yīng)該知道OPC UA服務(wù)器的采樣和底層系統(tǒng)的更新周期通常是不同步的鹃栽。這可能會導(dǎo)致變更檢測的額外延遲，如圖16所示躯畴。
5.12.1.3監(jiān)控模式
監(jiān)控模式參數(shù)用于啟用和禁用MonitoredItem的采樣民鼓，并提供獨立啟用和禁用通知的報告。此功能允許將MonitoredItem配置為示例私股、示例和報告摹察，或者兩者都不配置。禁用采樣不會改變?nèi)魏纹渌鸐onitoredItem參數(shù)的值倡鲸，比如它的采樣間隔。
當(dāng)啟用MonitoredItem MonitoringMode時(即從殘疾人抽樣或報告)或是在啟用狀態(tài),創(chuàng)建服務(wù)器應(yīng)當(dāng)向第一個樣品盡快和這個樣品的時間成為下一個采樣間隔的起點黄娘。
5.12.1.4過濾器
每次采樣MonitoredItem時峭状，服務(wù)器都會使用為MonitoredItem定義的過濾器來評估采樣克滴。篩選器參數(shù)定義了服務(wù)器用來確定是否應(yīng)該為示例生成Notification的條件。篩選器的類型依賴于正在監(jiān)視的項目的類型优床。例如劝赔，在監(jiān)視變量值時使用DataChangeFilter和AggregateFilter，在監(jiān)視事件時使用EventFilter胆敞。本標準描述了采樣和評估着帽，包括濾波器的使用。其他過濾器可以在本系列標準的其他部分中定義移层。
5.12.1.5隊列參數(shù)
如果示例通過了篩選條件仍翰，則會生成一個Notification，并由Subscription排隊等待傳輸观话。在創(chuàng)建MonitoredItem時定義隊列的大小予借。當(dāng)隊列滿并收到一個新的通知時，服務(wù)器要么丟棄最舊的通知并將新通知放入隊列中频蛔，要么用新通知替換添加到隊列中的最后一個值灵迫。MonitoredItem在創(chuàng)建MonitoredItem時為這些丟棄策略之一配置。如果一個DataValue的通知被丟棄晦溪，并且隊列的大小大于1瀑粥，那么在DataValue statusCode的InfoBits部分的Overflow位(標志)被設(shè)置。如果discardOldest為TRUE三圆，最老的值將從隊列中刪除狞换，隊列中的下一個值將設(shè)置標志。如果discardOldest為FALSE嫌术，添加到隊列的最后一個值將被替換為新的值哀澈。新值將獲得標志設(shè)置，以指示下一個NotificationMessage中丟失的值度气。圖17說明了隊列溢出處理割按。
如果隊列大小為1，則隊列成為一個總是包含最新通知的緩沖區(qū)磷籍。在這種情況下适荣，如果MonitoredItem的采樣間隔比訂閱的發(fā)布間隔快，則MonitoredItem將進行過采樣院领，客戶端將總是收到最新的值弛矛。當(dāng)隊列大小為1時，丟棄策略被忽略比然。
另一方面丈氓，客戶端可能希望訂閱沒有任何間隔的連續(xù)通知流，但不希望在采樣間隔報告它們。在這種情況下万俗，MonitoredItem將創(chuàng)建一個隊列大小足以容納兩個連續(xù)發(fā)布周期之間生成的所有通知湾笛。然后，在每個發(fā)布周期闰歪，訂閱將向客戶端發(fā)送為MonitoredItem排隊的所有通知嚎研。服務(wù)器應(yīng)按照隊列中的順序返回任何特定項目的通知。
服務(wù)器可能會以比采樣間隔更快的速率采樣库倘，以支持其他客戶端;客戶端應(yīng)該只期望在協(xié)商的采樣間隔內(nèi)的值临扮。根據(jù)過濾器和實現(xiàn)約束，服務(wù)器可能會交付比采樣間隔指定的更少的值教翩。如果為MonitoredItem配置了DataChangeFilter杆勇，那么它總是應(yīng)用于隊列中與當(dāng)前示例相比較的最新值。
例如迂曲，如果DataChangeFilter中的AbsoluteDeadband是“10”靶橱，隊列可以由以下順序的值組成:
- 100
- 111
- 100
- 89
- 100 當(dāng)使用死帶過濾器時，數(shù)據(jù)排隊可能會導(dǎo)致意外行為路捧，并且遇到的更改的數(shù)量大于可維護的值的數(shù)量关霸。隊列中的第一個新值不能超過發(fā)送給客戶端的前一個值的死區(qū)限制。
隊列大小是Server在監(jiān)視Events時支持的最大值杰扫。在這種情況下队寇，服務(wù)器負責(zé)事件緩沖區(qū)。如果事件丟失章姓，則 EventQueueOverflowEventType類型的事件被放置在隊列中佳遣。當(dāng)必須丟棄訂閱事件的MonitoredItem上的第一個事件時，將生成此事件凡伊。除了為這個MonitoredItem定義的隊列的大小之外零渐，它被放入MonitoredItem的隊列中，而不丟棄任何其他事件系忙。如果discardOldest設(shè)置為TRUE诵盼，它將被放在隊列的開頭，并且永遠不會被丟棄银还，否則將被放在隊列的末尾风宁。聚合服務(wù)器不應(yīng)傳遞此類事件。它應(yīng)該像其他連接錯誤場景一樣處理蛹疯。
5.12.1.6觸發(fā)模式
MonitoredItems服務(wù)允許添加只有在其他項目(觸發(fā)項)觸發(fā)時才報告的項目戒财。這是通過在觸發(fā)項和要報告的項之間創(chuàng)建鏈接來實現(xiàn)的。要報告的項目的監(jiān)控模式被設(shè)置為僅采樣捺弦，因此它將采樣和隊列通知饮寞，而不報告它們孝扛。圖18說明了這個概念。
觸發(fā)機制是一個有用的特性骂际，它允許客戶端通過將一些項配置為頻繁采樣疗琉，但只在其他事件發(fā)生時報告冈欢，從而減少在線上的數(shù)據(jù)量歉铝。
指定了以下觸發(fā)行為。
- 如果觸發(fā)項的監(jiān)控模式為SAMPLING凑耻，則觸發(fā)項觸發(fā)要上報的項目時不上報太示。
- 如果觸發(fā)項的監(jiān)控方式為REPORTING，則觸發(fā)項觸發(fā)需要上報的項目時上報香浩。
- 如果觸發(fā)項的監(jiān)控模式為“DISABLED”类缤，則觸發(fā)項不觸發(fā)上報。
- 如果要報告的項目的監(jiān)控模式為SAMPLING邻吭，則在觸發(fā)項目觸發(fā)要報告的項目時才報告餐弱。
- 如果要報告的項目的監(jiān)控模式是REPORTING，這實際上會導(dǎo)致忽略觸發(fā)項目囱晴。要報告的項目的所有通知將在發(fā)布間隔過期后發(fā)送膏蚓。
- 如果要報告的項目的監(jiān)控模式是DISABLED，那么將不會有要報告的項目的抽樣畸写，因此也不會有要報告的通知驮瞧。
- 當(dāng)?shù)谝粋€通知在鏈接創(chuàng)建后排隊等待觸發(fā)項時，第一個觸發(fā)器將發(fā)生枯芬÷郾剩客戶端在一個觸發(fā)項和一組要報告的項之間創(chuàng)建和刪除觸發(fā)鏈接。如果表示要報告的項目的MonitoredItem在其關(guān)聯(lián)的觸發(fā)鏈接被刪除之前被刪除千所，則觸發(fā)鏈接也被刪除狂魔，但觸發(fā)項不受影響。
刪除MonitoredItem不應(yīng)與刪除它所監(jiān)視的屬性相混淆淫痰。如果包含被監(jiān)控屬性的節(jié)點被刪除最楷，MonitoredItem會生成一個StatusCode Bad_NodeIdUnknown的Notification，表示刪除黑界，但MonitoredItem不會被刪除管嬉。
