本文簡單介紹OPC AE規(guī)范的條件概念，更多通信資源請登錄網(wǎng)信智匯(http://wangxinzhihui.com)。OPC AE規(guī)范描述了OPC事件服務(wù)器應(yīng)該實現(xiàn)的對象和接口，實現(xiàn)在多個OPC客戶端間共享事件和警報條件。

警報是一種異常條件。條件是OPC事件服務(wù)器的一些過程狀態(tài)集合。例如，標(biāo)簽FIC101可能具有“LevelAlarm”或與之相關(guān)的“偏差警報”條件。條件可以被定義（可選地）為包括多個子條件。例如LevelAlarm條件可能包括“HighAlarm”、“HighHighAlarm”和“LowAlarm”，以及“LowLowAlarm”子條件1。

在OPC事件服務(wù)器中，條件由OPCCondition2類型的對象表示。每個OPCCondition與一個OPCSource相關(guān)聯(lián)，如下圖所示。OPCSource可以是過程標(biāo)簽（例如FIC101）或可能的設(shè)備或子系統(tǒng)。如果OPC事件服務(wù)器是OPC DA服務(wù)器，OPCSource也可能是OPCItem。

1、子條件

條件可以是單一狀態(tài)，也可以是多狀態(tài)。多狀態(tài)條件是指其狀態(tài)包含多個感興趣的“范圍”或子狀態(tài)。例如，“LevelAlarm”條件可能具有多個子狀態(tài)，包括“HighAlarm”和“HighHighAlarm”。

表示每個子狀態(tài)，由OPCSubCondition類型的對象（該對象也不是COM對象）執(zhí)行。每個OPCSubCondition與一個OPC條件相關(guān)聯(lián)，如下圖所示。多狀態(tài)條件的子狀態(tài)必須互斥，例如標(biāo)簽不能同時處于HighAlarm和同時發(fā)出HighHighAlarm。

子條件允許客戶更容易地處理密切相關(guān)的事件通知，使得客戶端更容易檢測并正確顯示報警。例如：FIC101 從“HighAlarm” 切換到 “HighHighAlarm” ，這些子狀態(tài)被建模為相同條件（“LevelAlarm”）。如果建模為獨立的條件，則很難確定這些條件如何排斥。

單個狀態(tài)條件只有一個子狀態(tài)感，因此只有一個子條件。比如“硬件故障”，其中硬件設(shè)備要么處于故障狀態(tài)，要么不處于故障狀態(tài)。

2、?OPCConditions屬性

每個OPCCondition都具有以下屬性：

????????Name：條件名稱，例如“LevelAlarm”。條件名稱在事件服務(wù)器中必須是唯一的。

????????Active：關(guān)聯(lián)的對象當(dāng)前處于由條件表示的狀態(tài)。

????????ActiveSubCondition：如果處于活動狀態(tài)，這是當(dāng)前處于活動狀態(tài)的SubCondition的名稱。對于單狀態(tài)條件，該值將是條件名稱。例如：如果LevelAlarm條件處于活動狀態(tài)，則ActiveSubCondition值可能為“高報警”。

????????Enabled：條件激活/禁止。

????????Quality：條件所基于的數(shù)據(jù)值的當(dāng)前質(zhì)量。

????????Acked：如果條件激活，則表示條件已得到確認(rèn)。

????????LastAckTime： 最近確認(rèn)的時間。

????????SubCondiLastActive：最近轉(zhuǎn)換到當(dāng)前活動子條件的時間。這是確認(rèn)時必須指定的時間值

????????CondLastActive：最近轉(zhuǎn)換到此狀態(tài)的時間。

????????LastInactive：此條件下最近一次轉(zhuǎn)換的時間。

????????AcknowledgerID：上次確認(rèn)此條件的客戶端的ID。

????????Comment：上次確認(rèn)此條件時，客戶端傳入的備注。

3、Condition質(zhì)量

條件（Condition）通常基于一個或多個具有“質(zhì)量”屬性的OPCItem。條件也有相關(guān)的質(zhì)量。如果過程值為“不確定”，則“LevelAlarm”情況也令人懷疑。與OPCItems一樣，條件將具有強(qiáng)制的“質(zhì)量”屬性。當(dāng)質(zhì)量發(fā)生變化時，它將生成一個事件通知。

由服務(wù)器決定如何獲得“質(zhì)量”的值。服務(wù)器也可能定義一種特殊的EventCategory，用于報告值的不良質(zhì)量屬性。

質(zhì)量屬性的值符合OPC DA中的OPC質(zhì)量標(biāo)志定義規(guī)范。

4、OPCSubConditions屬性

每個OPCSubCondition都具有以下屬性：

????????Name：子條件的名稱。例如“HighAlarm”表示“液位報警”。在單一狀態(tài)報警的情況下，子條件名稱為與關(guān)聯(lián)的條件名稱相同。子條件的名稱必須為在其相關(guān)條件下是唯一的。

????????Definition：由子條件表示的子狀態(tài)的表達(dá)式。

????????Severity：此子條件生成的任何事件的嚴(yán)重性。請注意，同一條件的不同子條件可能具有不同的嚴(yán)重程度。

????????Description：子條件生成的事件通知中的文本字符串。

5、Condition定義

條件定義是特定于服務(wù)器的。例如：

????????1）一個或多個OPCItem上的布爾表達(dá)式。例：FIC101.PV>100和FIC101.PV<150。這是LevelAlarm條件的HighAlarm子條件的定義。

????????2）引用由底層系統(tǒng)或設(shè)備定義的條件的文本字符串，例如：“設(shè)備故障”。

????????3）與OPC事件服務(wù)器相關(guān)聯(lián)的條件的文本字符串。例如：

?????????在指定時間關(guān)閉

?????????服務(wù)器過載

?????????底層系統(tǒng)/設(shè)備故障

?????????等等。

6、嚴(yán)重性

嚴(yán)重程度值表示子條件的緊急程度。這也通常被稱為“優(yōu)先級”，尤其是與過程警報有關(guān)的優(yōu)先級。值的范圍從1到1000，其中1是嚴(yán)重性最低，1000為最高。通常，嚴(yán)重性為1表示信息性事件，而1000的值表示災(zāi)難性事件，可能導(dǎo)致嚴(yán)重的經(jīng)濟(jì)損失或生命損失。

預(yù)計很少有服務(wù)器實現(xiàn)能夠支持1000個不同的嚴(yán)重性級別。因此服務(wù)器開發(fā)人員負(fù)責(zé)將其嚴(yán)重性級別分布在1–1000范圍內(nèi)，客戶端可以采用線性分布的方式。例如：

下圖為底層設(shè)備嚴(yán)重性到OPC嚴(yán)重性范圍的映射表。

有些服務(wù)器可能不支持任何災(zāi)難性事件，因此它們可能會選擇映射它們的所有嚴(yán)重程度都劃分為1–1000范圍的一個子集（例如，1–666）。

7、Condition啟用/禁用

客戶端可以啟用和禁用條件。

?????????服務(wù)器可以選擇在被禁用時繼續(xù)測試某個條件。但是，無法生成事件通知，也無法確認(rèn)。

?????????禁用狀態(tài)下是否定義以下條件屬性取決于服務(wù)器：

????????Active、ActiveSubCondition、Quality、Acked、LastAckTime、SubCondLastActive、CondLastActive、LastInactive、AcknowledgerID和Comment。

?????????在刷新時，將不會為禁用條件生成事件通知。

?????????啟用時，與“激活條件”事件通知關(guān)聯(lián)的時間屬性為啟用后首次發(fā)現(xiàn)該條件的時間，或該條件變?yōu)榛顒訝顟B(tài)的時間。

8、?Area啟用/禁用

客戶端可以啟用和禁用區(qū)域。

如果源的條件狀態(tài)設(shè)置為“已啟用”，并且的層次結(jié)構(gòu)中的所有區(qū)域都已啟用，則源啟用。

如果源的條件狀態(tài)設(shè)置為禁用或其層次結(jié)構(gòu)中的任何區(qū)域禁用，則該源將被禁用。

舉例說明，如下圖所示。

圖中以“S”命名的對象為源，以命名的對象為區(qū)域。高亮顯示的對象處于禁用狀態(tài)（即，A2、A11、S3和S5被禁用）。假設(shè)客戶端正在訂閱模型中所有區(qū)域和源的事件。

????????1）盡管源“S2”為啟用狀態(tài)，但是A11不是。因此，客戶端不能接收到這個條件的事件。

????????2）源“S4”為啟用狀態(tài)，且包含的區(qū)域（A12，A1以及A0）君均為啟用，所以，客戶端沒可以接收到這個條件的事件。

????????3）源“S5”為禁用狀態(tài)，盡管包含的區(qū)域都已啟用，客戶端不能接收到這個條件的事件。

9、Condition狀態(tài)集

下圖為OPC Condition的示例狀態(tài)機(jī)。

????????1）每個狀態(tài)轉(zhuǎn)換都是一個事件。在每次狀態(tài)轉(zhuǎn)換時都會發(fā)送事件通知消息。

????????2）每個與條件相關(guān)的事件通知，需要確認(rèn)的包括：條件名稱、條件最近進(jìn)入活動狀態(tài)或轉(zhuǎn)換為新的子條件的時間，以及事件通知的唯一標(biāo)識Cookie。信息由OPC客戶端在確認(rèn)條件時指定，OPC事件服務(wù)器識別正在發(fā)生的特定事件（狀態(tài)轉(zhuǎn)換）使用此信息。。如果接收到具有過期的SubCondLastActive屬性的確認(rèn)（這可能是由于系統(tǒng)中的延遲造成的），條件狀態(tài)不會得到確認(rèn)。

????????3）請注意，確認(rèn)會影響條件狀態(tài)，如果條件當(dāng)前處于活動狀態(tài)或它當(dāng)前處于非活動狀態(tài)，并且最近的活動狀態(tài)未被確認(rèn)。如果不活動，未確認(rèn)條件再次變?yōu)榛顒訝顟B(tài)，所有后續(xù)確認(rèn)都將被驗證，針對新激活的條件狀態(tài)屬性。服務(wù)器可以選擇使用Cookie屬性的事件通知，以記錄“舊”條件激活的確認(rèn)，但此類“晚”確認(rèn)對該狀況的當(dāng)前狀態(tài)沒有影響。

????????4）條件激活狀態(tài)的確認(rèn)可能來自O(shè)PC客戶端，也可能是由于OPC事件服務(wù)器內(nèi)部的邏輯。例如，對相關(guān)OPC條件的確認(rèn)，可能導(dǎo)致該OPC條件被確認(rèn)，或者OPC條件可能被設(shè)置為當(dāng)條件變?yōu)椴换顒訒r自動確認(rèn)。

????????5）對于不跟蹤或不需要確認(rèn)的情況，狀態(tài)轉(zhuǎn)換更簡單——只是在啟用-非活動、啟用-活動和禁用狀態(tài)之間切換。

????????6）建議事件服務(wù)器生成用于啟用和禁用操作的跟蹤事件，而不是為每個被啟用或禁用的條件實例生成事件通知。如果不符合這個建議，則按區(qū)域啟用和禁用可能會導(dǎo)致大量事件通知。

更多通信資源請登錄網(wǎng)信智匯(http://wangxinzhihui.com)。