一種基于事件處理的信息交換方法的研究

許 斌，蔡鴻明

0 引言

目前，隨著信息技術(shù)和網(wǎng)絡(luò)的發(fā)展以及企業(yè)信息化的強烈需求以及物聯(lián)網(wǎng)[1]的發(fā)展，在制造企業(yè)中，各種應用系統(tǒng)層出不窮，包括物料管理系統(tǒng)（MMS）、客戶關(guān)系系統(tǒng)（CRM）、制造執(zhí)行系統(tǒng)（MES）等，大量信息隨之產(chǎn)生，在多變的市場環(huán)境以及生產(chǎn)環(huán)境中，針對制造企業(yè)中信息源多樣并離散的特性，以及普遍存在的軟硬件信息交換問題，能夠提供更靈活、有效的信息交換方式，成為當今研究的一個方向。

目前比較常見的做法是使用基于服務(wù)的ESB（Enterprise Service Bus）的方式實現(xiàn)信息交換，ESB 是SOA 架構(gòu)中的消息傳輸中介，通過這個中介，每個組件可以通過標準的消息傳輸方式進行交互[2][3]。使用ESB 進行信息交換的本質(zhì)是事件驅(qū)動的處理方式，在通過復雜事件處理[4]來實現(xiàn)信息系統(tǒng)方面已有一些研究。早期的方式有基于ECA 規(guī)則[5]實現(xiàn)的主動數(shù)據(jù)庫，其中，數(shù)據(jù)庫的操作被用作組合事件。目前，該領(lǐng)域的相關(guān)研究向集合語義捕獲事件的方向轉(zhuǎn)變，SnoopIB 提供對信息處理和交換的上下文支持[6]。除了主動數(shù)據(jù)庫，更多的研究集中在復雜事件處理系統(tǒng)上。NextCEP提出了一種分布式復雜事件處理系統(tǒng)[7]，它使用一種語言來實現(xiàn)基于規(guī)則的模式檢測。

雖然使用ESB進行信息交換的方案是目前研究的主流，但其僅支持對企業(yè)中已有的服務(wù)進行信息交換，而在制造企業(yè)中大量存在的機械設(shè)備以及傳感器等難以轉(zhuǎn)化為服務(wù)。在事件處理方面，雖然上面提到的研究能夠解決各自領(lǐng)域的一些問題，但依然存在不足，比如應用領(lǐng)域的限制以及面對多變環(huán)境的可擴展性問題。

綜上所述，對于制造企業(yè)中應用系統(tǒng)中對信息交換實時性和有效性的要求，特別是對軟硬件信息交換的支持，已有的信息交換方式并不能滿足需求。本文提出一種基于事件處理的信息交換方法。首先，為了異構(gòu)信息交換以及事件處理的需要，信息需要從異構(gòu)信息源抽取、解析并轉(zhuǎn)化生成為格式統(tǒng)一的事件；其次，依據(jù)基于ECA 設(shè)計的規(guī)則，事件被篩選和處理，對原始的信息得到處理和加工；最后，通過事件推送的方式，將事件推送的指定的組件中，實現(xiàn)信息交換。

1 基于事件處理的信息交換框架

為了保證信息交換過程的動態(tài)性，并提供對多源信息交換的支持變化，本文提出一種基于事件處理的信息交換框架，如圖1所示：

圖1 基于規(guī)則事件驅(qū)動的信息交換框架

整個框架的主要模塊可以分為兩個部分：信息獲取以及解析、基于事件處理的信息交換。

⑴信息獲取以及解析，通過不同的通信方式獲取信息，并定制信息解析模塊對異構(gòu)信息進行解析。

⑵基于事件處理的信息交換階段，包含基于規(guī)則的事件處理過程，其中處理規(guī)則的模型定義也包含在本模塊內(nèi)。

對于不同的信息源，通過解析器解析生成事件實例，接著基于規(guī)則執(zhí)行事件處理，最后展現(xiàn)出來達到信息交換的效果。其中事件提醒，可以使用用戶自定義的展現(xiàn)方式進行展現(xiàn)，本文案例基于制造企業(yè)中生產(chǎn)車間的實際情況使用現(xiàn)場圖的方式進行展現(xiàn)。

2 信息抽取與事件生成

2.1 事件模型定義

Luckham 指出事件就是系統(tǒng)中活動的記錄[4]。對于單一活動來說，需要描述的包括活動的標示信息，活動包括自發(fā)發(fā)生的活動，同時也存在因為某些活動的觸發(fā)而被動產(chǎn)生的活動，即對應于簡單事件與復雜事件，針對這兩種不同的情況，使用一個表示類型的參數(shù)表示不同的類型，對應于由其他活動觸發(fā)的活動，其執(zhí)行以其他活動的產(chǎn)生的信息作為參考，即對應于事件的輸入，同時將活動所產(chǎn)生的結(jié)果作為事件的輸出，這個結(jié)果必定與活動一一對應。基于以上的分析，本文給出關(guān)于事件模型的定義。

定義1 事件模型 EM=＜ED,EI,EO,ET,T＞

其中ED 表示事件資源的標識，記錄每個事件資源特有的標識信息；EI 表示事件的輸入，記錄復雜事件的輸入信息；EO 表示事件的輸出，記錄復雜事件的輸出信息；ET表示事件的類型，有簡單事件以及復雜事件兩種類型；T 代表時間戳，記錄事件發(fā)生的時間。

定義2 事件標識ED=＜EId,EName,ELocation,EDescription＞

其中EId 是事件的唯一標示；EName 表示事件的名稱；ELocation 表示事件的位置信息；EDescription 表示事件的描述信息，用文本形式描述其特性。

定義3 事件資源信息體EM=＜ EId,Attrs,T＞

事件資源信息體包含事件資源的主體信息，包括其唯一的標識EId，信息集Attrs，時間戳T，其中信息集Attrs 中包含一系列屬性，事件處理過程中的參數(shù)都包含于其中。

事件的輸入EI 以及事件的輸出EO 均以事件資源信息體為主要信息載體。事件的輸出EO，即表示該事件資源的一些特性，與該資源的屬性相關(guān)，另一方面，對于簡單事件來說，其事件的輸入EI 為空，而對于復雜事件來說，其輸入可以包含多個事件，這些輸入的事件信息均與那些事件的輸出相對應。

ET 代表事件類型，由簡單事件和復雜事件兩種類型。

T 表示事件的觸發(fā)時間，為了系統(tǒng)處理的一致性，在系統(tǒng)內(nèi)使用統(tǒng)一的方式進行時間錄入。

2.2 事件實例生成

在生成事件實例之前，需要在系統(tǒng)中注冊所需要使用的事件源，即是根據(jù)上文中事件資源的定義建立事件資源的過程，針對簡單事件和復雜事件存在兩種不同的注冊方式：

⑴簡單事件直接來源于各個不同的事件源，其資源的定義只需要根據(jù)能夠接受到的信息內(nèi)容給出信息體的結(jié)構(gòu)以及其資源標識信息。

⑵復雜事件來自于系統(tǒng)中事件處理，并且系統(tǒng)中事件處理是基于規(guī)則完成，那么復雜事件資源與規(guī)則對應，定義復雜事件資源需要選定對應的規(guī)則，并且選擇一些事件作為其輸入，而其輸出則由規(guī)則給出，并不需要在事件資源定義時給出。

信息的抽取與解析：事件有多種不同的事件源，即可以來自于企業(yè)中應用系統(tǒng)的操作，也可以來自于連入系統(tǒng)的各種設(shè)備，對于不同的信息源有不同的信息抽取和解析方式，其抽取和解析過程，如圖2所示：

圖2 信息解析與轉(zhuǎn)化

在信息解析完成之后，通過事件的唯一標示與定義的事件相關(guān)聯(lián)，并且將產(chǎn)生的實例保存在事件池中，同時將日志記錄于系統(tǒng)中。

3 基于事件處理的信息交換

3.1 規(guī)則定義與構(gòu)建

在事件處理領(lǐng)域使用ECA 規(guī)則描述事件觸發(fā)規(guī)則以及處理過程。一個ECA 規(guī)則包含事件、條件和動作。其主要形式如下：

表示規(guī)則的觸發(fā)情況，condition 是用戶自定義函數(shù)的布爾集合，action 給出了處理過程。

本文提出了可擴展的規(guī)則模型，定義如下：

定義 4 用于事件處理的可擴展規(guī)則 XR=＜XRId,XRName,OnEvent.,Condition,Action,Priority,Type＞

其中XRId 唯一標示一個規(guī)則；XRName 表示規(guī)則名；OnEvent 表示規(guī)則的觸發(fā)情況，其值為事件標識的集合，集合中的事件發(fā)生都可以觸發(fā)規(guī)則；Condition 表示規(guī)則觸發(fā)之后需要驗證的條件；Action 表示條件滿足后的動作；Priority 代表事件處理的優(yōu)先級；Type 代表規(guī)則類型，主要有兩種類型，一種是消耗型規(guī)則，即觸發(fā)的事件需要從事件池中移除，另一種是非消耗型規(guī)則，與消耗型相反，不會將事件從事件池中移除。

條件（Condition）主要用于檢驗事件中屬性集合以及執(zhí)行過程中全局變量的值是否滿足一定規(guī)則，用于判斷條件真假的操作符主要包括兩種，如圖1所示：

表1 條件操作符

關(guān)系操作符（RO）和邏輯操作符（LO），其中關(guān)系操作符主要用于比對事件的屬性情況，邏輯操作符則用于條件的邏輯拼接，如下給出操作符定義：

動作（Action）表示當規(guī)則觸發(fā)時滿足執(zhí)行條件需要進行的處理，本文中Action 主要用于計算與該規(guī)則對應的復雜事件的輸出屬性集。

3.2 基于規(guī)則的事件處理

基于規(guī)則的事件處理被設(shè)計用于信息交換。事件處理的過程主要包括事件檢測和事件處理。過程，如圖3所示：

圖3 基于規(guī)則事件處理流程圖

⑴在系統(tǒng)中實時進行事件檢測，首先需要確定觸發(fā)的規(guī)則。為了更快速的進行觸發(fā)規(guī)則的篩選，在規(guī)則編輯完成進入規(guī)則庫后，同時維護事件-規(guī)則的關(guān)系表，即當該事件發(fā)生時，可以通過該對應關(guān)系表迅速找到以該事件為觸發(fā)的規(guī)則集。

⑵在規(guī)則觸發(fā)之后，需要對規(guī)則的條件進行驗證，驗證的過程基于活動的事件實例以及 全局參數(shù)，對規(guī)則中定義的條件進行驗證。本文基于RETE 算法提出了一個檢測算法，用于檢測規(guī)則的條件是否被滿足，該算法偽代碼如下：

該算法將觸發(fā)事件和規(guī)則文件作為輸入，檢驗規(guī)則是否被觸發(fā)，如果能夠被觸發(fā)則通過對條件節(jié)點的逐個驗證，實現(xiàn)對規(guī)則的檢測，最終獲得其條件是否滿足的真值或假值。

⑶在規(guī)則的條件被驗證為真時，該規(guī)則即被判定為需要執(zhí)行。此時，基于該規(guī)則的事件處理被推送至執(zhí)行隊列中，該執(zhí)行隊列使用基于優(yōu)先級的隊列表示，當一個新的事件處理需求被推送至執(zhí)行隊列時，系統(tǒng)會基于規(guī)則優(yōu)先級選擇合適的位置，插入新的規(guī)則等待執(zhí)行。

3.3 信息展現(xiàn)

通過事件處理，能夠?qū)亩鄠€信息源接收的信息以事件的形式進行交換。在本文中，所有的信息都通過事件的形式進行展現(xiàn)，基于事件驅(qū)動的方式進行信息推送。

經(jīng)過事件處理之后，系統(tǒng)中存在包括簡單事件以及復雜事件等大量事件，使用事件推送的方式，根據(jù)用戶定義展現(xiàn)界面進行展現(xiàn)，在展現(xiàn)界面中的各元素，可以通過事件訂閱的方式綁定相應的事件，將事件與界面中組件相互映射，一旦事件實例發(fā)布時，偵聽該事件的元素就會得到相應并更新，主要過程如下：

⑴展現(xiàn)層組件通過事件提醒模塊訂閱事件，當訂閱成功后，組件與其訂閱的事件之間的對應關(guān)系，通過訂閱信息管理模塊保存并管理。

⑵同時基于消息中間件的消息傳輸機制，在與該事件一一對應的消息隊列中增加該組件，將該組件與消息隊列進行綁定，當有消息到達時隨即被推至該組件。

⑶經(jīng)過事件處理后產(chǎn)生的事件后，事件的輸出部分作為消息加入消息中間件中特定的消息隊列，并實時的推送至組件，比如通過與界面元素綁定，能夠?qū)崟r地通過界面更新展現(xiàn)交換的信息。

4 實現(xiàn)與驗證

本文以某生產(chǎn)車間的監(jiān)控系統(tǒng)對基于事件的信息交換方法進行驗證。在車間中，存在大量的設(shè)備，這些設(shè)備通過PLC 可以與車間的設(shè)備進行信息傳輸，獲取設(shè)備運行狀態(tài)。為了獲取車間生產(chǎn)執(zhí)行的實時狀態(tài)，主要功能為一個可用于監(jiān)視的車間執(zhí)行狀態(tài)現(xiàn)場圖。設(shè)計系統(tǒng)架構(gòu)，如圖4所示：

圖4 應用系統(tǒng)架構(gòu)

具體的流程如下：

⑴信息的獲取和解析并生成事件實例，如圖5所示：

圖5 配置及處理過程

信息的獲取通過PLC 與平臺進行SOCKET 通信獲取，事件模型中關(guān)于事件標示的定義在下圖（圖5 第一部分）A區(qū)域給出，包括事件名稱（EName）、設(shè)備代碼（EId）等信息息的內(nèi)容以一串字符標示，B 區(qū)域則給出了事件信息體（EM）的定義，并且給出了通信內(nèi)容與信息體屬性的映射關(guān)系。完成創(chuàng)建并保存之后，事件將以XML的格式表示并進行保存和管理。

⑵規(guī)則的建立與復雜事件的定義（圖5 第二部分）：針對系統(tǒng)功能的需求，設(shè)計負載檢測規(guī)則，檢測設(shè)備負載是否超過既定值，當負載過高時，生產(chǎn)監(jiān)視部分將獲取新的狀態(tài)數(shù)據(jù)并動態(tài)更新，根據(jù)如上的規(guī)則添加頁面編輯規(guī)則，完成包括規(guī)則名稱、優(yōu)先級、觸發(fā)事件等的編輯。

⑶復雜事件創(chuàng)建（圖5 第三部分）：在規(guī)則建立完成之后，基于已有的規(guī)則，需要建立復雜事件，除了基本信息所要求的事件名事件標示等，還需要指定其生成時所依賴的規(guī)則以及輸入事件集。

⑷信息交換與展現(xiàn)：事件“清洗機A”（接收到清洗機A的狀態(tài)信息，I）發(fā)生后，該事件所能觸發(fā)的規(guī)則將被檢驗，若規(guī)則的條件滿足則產(chǎn)生新的事件“清洗機負載過高”（K），其以I的事件信息體作為輸入，其自身的事件信息體即輸出由規(guī)則的Action 決定。此外，通過完成界面組件與事件的綁定（圖5 第四部分）之后，當K 產(chǎn)生時，監(jiān)控頁面就會對該元素進行包括顏色、數(shù)據(jù)展示等方式進行展現(xiàn)。

當設(shè)備的運行超過負載時，在整體現(xiàn)場監(jiān)視圖（圖6）上通過不同的顏色進行展現(xiàn)，同時右側(cè)表格給出最新具體的狀態(tài)信息，如圖6所示：

圖6 現(xiàn)場監(jiān)控圖

本文提出的基于事件處理的信息交換方法，將多源信息以事件的形式進行事件處理并以消息中間件推送至各組件達到信息交換的目的，從應用范圍、擴展性、性能以及質(zhì)量與安全指標方面與ESB的方式以及常見的基于消息點對點的方式進行比較，如表2所示：

表2 與已有方法的比較

針對以上幾點從表中可以看出，使用基于事件處理的方法在應用范圍與擴展性上有較大的優(yōu)勢，主要有以下兩點點特點:⑴使用事件表示信息，更具通用性；⑵基于規(guī)則進行事件處理，能夠靈活的應對多變的需求，具有較好的擴展性。

5 小結(jié)

綜上所述，本文提出的基于事件處理的信息交換框架，首先建立事件模型，提出多源信息向事件轉(zhuǎn)化的方法，以事件描述異構(gòu)的多源信息，接著建立能夠滿足事件處理要求的規(guī)則模型，同時給出基于規(guī)則的事件處理方法，并介紹了信息交換的展現(xiàn)方法，最后通過一個制造企業(yè)中生產(chǎn)車間的監(jiān)控系統(tǒng)作為驗證，證明了本文所提出的基于事件處理的信息交換方法是切實可行的。在接下來的工作中，主要針對性能指標與安全指標，對整個方法的研究體系進行完善和改進。

[1]Stephan Haller,Stamatis Karnouskos and Christoph Schroth.The Internet of Things in an Enterprise Context[J].Lecture Notes in Computer Science,2009,5468:14-28.

[2]蔡昭權(quán).基于ESB的異構(gòu)系統(tǒng)集成實現(xiàn)[J].計算機應用,2005,28(2):538-540.

[3]Gulnoza Ziyaeva,Eunmi Choi,Dugki Min.Content-Based Intelligent Routing and Message Processing in Enterprise Service Bus [C].International Conference on Convergence and Hybrid Information Technology.Daejeon,KOR,2008:245-249.

[4]Luckham David.The Power of Events:An Introduction to Complex Event Processing in Distributed Enterprise Systems [M].Boston,US:Addison-Wesley Educational Publishers Inc,2002.

[5]Jing Zhang.Verification of ECA rule based management and control systems [C].4th IEEE Conference on Automation Science and Engineering.Washington DC,USA,2008:1-7.

[6]Raman Adaikkalavan and Sharma Chakravarthy.Snoopib:interval-based event specification and detection for active databases [J].Data &Knowledge Engineering,2006,59(1):139-165.

[7]NP Schultz-Moeller,M Migliavacca,and P Pietzuch.2009.Distributed complex event processing with query rewriting[C].Proceedings of the Third ACM International Conference on Distributed Event-Based Systems.New York,USA,2009,Article No.4.