許 斌,蔡鴻明
目前,隨著信息技術和網絡的發展以及企業信息化的強烈需求以及物聯網[1]的發展,在制造企業中,各種應用系統層出不窮,包括物料管理系統(MMS)、客戶關系系統(CRM)、制造執行系統(MES)等,大量信息隨之產生,在多變的市場環境以及生產環境中,針對制造企業中信息源多樣并離散的特性,以及普遍存在的軟硬件信息交換問題,能夠提供更靈活、有效的信息交換方式,成為當今研究的一個方向。
目前比較常見的做法是使用基于服務的ESB(Enterprise Service Bus)的方式實現信息交換,ESB 是SOA 架構中的消息傳輸中介,通過這個中介,每個組件可以通過標準的消息傳輸方式進行交互[2][3]。使用ESB 進行信息交換的本質是事件驅動的處理方式,在通過復雜事件處理[4]來實現信息系統方面已有一些研究。早期的方式有基于ECA 規則[5]實現的主動數據庫,其中,數據庫的操作被用作組合事件。目前,該領域的相關研究向集合語義捕獲事件的方向轉變,SnoopIB 提供對信息處理和交換的上下文支持[6]。除了主動數據庫,更多的研究集中在復雜事件處理系統上。NextCEP提出了一種分布式復雜事件處理系統[7],它使用一種語言來實現基于規則的模式檢測。
雖然使用ESB進行信息交換的方案是目前研究的主流,但其僅支持對企業中已有的服務進行信息交換,而在制造企業中大量存在的機械設備以及傳感器等難以轉化為服務。在事件處理方面,雖然上面提到的研究能夠解決各自領域的一些問題,但依然存在不足,比如應用領域的限制以及面對多變環境的可擴展性問題。
綜上所述,對于制造企業中應用系統中對信息交換實時性和有效性的要求,特別是對軟硬件信息交換的支持,已有的信息交換方式并不能滿足需求。本文提出一種基于事件處理的信息交換方法。首先,為了異構信息交換以及事件處理的需要,信息需要從異構信息源抽取、解析并轉化生成為格式統一的事件;其次,依據基于ECA 設計的規則,事件被篩選和處理,對原始的信息得到處理和加工;最后,通過事件推送的方式,將事件推送的指定的組件中,實現信息交換。
為了保證信息交換過程的動態性,并提供對多源信息交換的支持變化,本文提出一種基于事件處理的信息交換框架,如圖1所示:

圖1 基于規則事件驅動的信息交換框架
整個框架的主要模塊可以分為兩個部分:信息獲取以及解析、基于事件處理的信息交換。
⑴信息獲取以及解析,通過不同的通信方式獲取信息,并定制信息解析模塊對異構信息進行解析。
⑵基于事件處理的信息交換階段,包含基于規則的事件處理過程,其中處理規則的模型定義也包含在本模塊內。
對于不同的信息源,通過解析器解析生成事件實例,接著基于規則執行事件處理,最后展現出來達到信息交換的效果。其中事件提醒,可以使用用戶自定義的展現方式進行展現,本文案例基于制造企業中生產車間的實際情況使用現場圖的方式進行展現。
Luckham 指出事件就是系統中活動的記錄[4]。對于單一活動來說,需要描述的包括活動的標示信息,活動包括自發發生的活動,同時也存在因為某些活動的觸發而被動產生的活動,即對應于簡單事件與復雜事件,針對這兩種不同的情況,使用一個表示類型的參數表示不同的類型,對應于由其他活動觸發的活動,其執行以其他活動的產生的信息作為參考,即對應于事件的輸入,同時將活動所產生的結果作為事件的輸出,這個結果必定與活動一一對應。基于以上的分析,本文給出關于事件模型的定義。
定義1 事件模型 EM=<ED,EI,EO,ET,T>
其中ED 表示事件資源的標識,記錄每個事件資源特有的標識信息;EI 表示事件的輸入,記錄復雜事件的輸入信息;EO 表示事件的輸出,記錄復雜事件的輸出信息;ET表示事件的類型,有簡單事件以及復雜事件兩種類型;T 代表時間戳,記錄事件發生的時間。
定義2 事件標識ED=<EId,EName,ELocation,EDescription>
其中EId 是事件的唯一標示;EName 表示事件的名稱;ELocation 表示事件的位置信息;EDescription 表示事件的描述信息,用文本形式描述其特性。
定義3 事件資源信息體EM=< EId,Attrs,T>
事件資源信息體包含事件資源的主體信息,包括其唯一的標識EId,信息集Attrs,時間戳T,其中信息集Attrs 中包含一系列屬性,事件處理過程中的參數都包含于其中。
事件的輸入EI 以及事件的輸出EO 均以事件資源信息體為主要信息載體。事件的輸出EO,即表示該事件資源的一些特性,與該資源的屬性相關,另一方面,對于簡單事件來說,其事件的輸入EI 為空,而對于復雜事件來說,其輸入可以包含多個事件,這些輸入的事件信息均與那些事件的輸出相對應。
ET 代表事件類型,由簡單事件和復雜事件兩種類型。
T 表示事件的觸發時間,為了系統處理的一致性,在系統內使用統一的方式進行時間錄入。
在生成事件實例之前,需要在系統中注冊所需要使用的事件源,即是根據上文中事件資源的定義建立事件資源的過程,針對簡單事件和復雜事件存在兩種不同的注冊方式:
⑴簡單事件直接來源于各個不同的事件源,其資源的定義只需要根據能夠接受到的信息內容給出信息體的結構以及其資源標識信息。
⑵復雜事件來自于系統中事件處理,并且系統中事件處理是基于規則完成,那么復雜事件資源與規則對應,定義復雜事件資源需要選定對應的規則,并且選擇一些事件作為其輸入,而其輸出則由規則給出,并不需要在事件資源定義時給出。
信息的抽取與解析:事件有多種不同的事件源,即可以來自于企業中應用系統的操作,也可以來自于連入系統的各種設備,對于不同的信息源有不同的信息抽取和解析方式,其抽取和解析過程,如圖2所示:

圖2 信息解析與轉化
在信息解析完成之后,通過事件的唯一標示與定義的事件相關聯,并且將產生的實例保存在事件池中,同時將日志記錄于系統中。
在事件處理領域使用ECA 規則描述事件觸發規則以及處理過程。一個ECA 規則包含事件、條件和動作。其主要形式如下:

表示規則的觸發情況,condition 是用戶自定義函數的布爾集合,action 給出了處理過程。
本文提出了可擴展的規則模型,定義如下:
定義 4 用于事件處理的可擴展規則 XR=<XRId,XRName,OnEvent.,Condition,Action,Priority,Type>
其中XRId 唯一標示一個規則;XRName 表示規則名;OnEvent 表示規則的觸發情況,其值為事件標識的集合,集合中的事件發生都可以觸發規則;Condition 表示規則觸發之后需要驗證的條件;Action 表示條件滿足后的動作;Priority 代表事件處理的優先級;Type 代表規則類型,主要有兩種類型,一種是消耗型規則,即觸發的事件需要從事件池中移除,另一種是非消耗型規則,與消耗型相反,不會將事件從事件池中移除。
條件(Condition)主要用于檢驗事件中屬性集合以及執行過程中全局變量的值是否滿足一定規則,用于判斷條件真假的操作符主要包括兩種,如圖1所示:

表1 條件操作符
關系操作符(RO)和邏輯操作符(LO),其中關系操作符主要用于比對事件的屬性情況,邏輯操作符則用于條件的邏輯拼接,如下給出操作符定義:
動作(Action)表示當規則觸發時滿足執行條件需要進行的處理,本文中Action 主要用于計算與該規則對應的復雜事件的輸出屬性集。
基于規則的事件處理被設計用于信息交換。事件處理的過程主要包括事件檢測和事件處理。過程,如圖3所示:

圖3 基于規則事件處理流程圖
⑴在系統中實時進行事件檢測,首先需要確定觸發的規則。為了更快速的進行觸發規則的篩選,在規則編輯完成進入規則庫后,同時維護事件-規則的關系表,即當該事件發生時,可以通過該對應關系表迅速找到以該事件為觸發的規則集。
⑵在規則觸發之后,需要對規則的條件進行驗證,驗證的過程基于活動的事件實例以及 全局參數,對規則中定義的條件進行驗證。本文基于RETE 算法提出了一個檢測算法,用于檢測規則的條件是否被滿足,該算法偽代碼如下:

該算法將觸發事件和規則文件作為輸入,檢驗規則是否被觸發,如果能夠被觸發則通過對條件節點的逐個驗證,實現對規則的檢測,最終獲得其條件是否滿足的真值或假值。
⑶在規則的條件被驗證為真時,該規則即被判定為需要執行。此時,基于該規則的事件處理被推送至執行隊列中,該執行隊列使用基于優先級的隊列表示,當一個新的事件處理需求被推送至執行隊列時,系統會基于規則優先級選擇合適的位置,插入新的規則等待執行。
通過事件處理,能夠對從多個信息源接收的信息以事件的形式進行交換。在本文中,所有的信息都通過事件的形式進行展現,基于事件驅動的方式進行信息推送。
經過事件處理之后,系統中存在包括簡單事件以及復雜事件等大量事件,使用事件推送的方式,根據用戶定義展現界面進行展現,在展現界面中的各元素,可以通過事件訂閱的方式綁定相應的事件,將事件與界面中組件相互映射,一旦事件實例發布時,偵聽該事件的元素就會得到相應并更新,主要過程如下:
⑴展現層組件通過事件提醒模塊訂閱事件,當訂閱成功后,組件與其訂閱的事件之間的對應關系,通過訂閱信息管理模塊保存并管理。
⑵同時基于消息中間件的消息傳輸機制,在與該事件一一對應的消息隊列中增加該組件,將該組件與消息隊列進行綁定,當有消息到達時隨即被推至該組件。
⑶經過事件處理后產生的事件后,事件的輸出部分作為消息加入消息中間件中特定的消息隊列,并實時的推送至組件,比如通過與界面元素綁定,能夠實時地通過界面更新展現交換的信息。
本文以某生產車間的監控系統對基于事件的信息交換方法進行驗證。在車間中,存在大量的設備,這些設備通過PLC 可以與車間的設備進行信息傳輸,獲取設備運行狀態。為了獲取車間生產執行的實時狀態,主要功能為一個可用于監視的車間執行狀態現場圖。設計系統架構,如圖4所示:

圖4 應用系統架構
具體的流程如下:
⑴信息的獲取和解析并生成事件實例,如圖5所示:

圖5 配置及處理過程
信息的獲取通過PLC 與平臺進行SOCKET 通信獲取,事件模型中關于事件標示的定義在下圖(圖5 第一部分)A區域給出,包括事件名稱(EName)、設備代碼(EId)等信息息的內容以一串字符標示,B 區域則給出了事件信息體(EM)的定義,并且給出了通信內容與信息體屬性的映射關系。完成創建并保存之后,事件將以XML的格式表示并進行保存和管理。
⑵規則的建立與復雜事件的定義(圖5 第二部分):針對系統功能的需求,設計負載檢測規則,檢測設備負載是否超過既定值,當負載過高時,生產監視部分將獲取新的狀態數據并動態更新,根據如上的規則添加頁面編輯規則,完成包括規則名稱、優先級、觸發事件等的編輯。
⑶復雜事件創建(圖5 第三部分):在規則建立完成之后,基于已有的規則,需要建立復雜事件,除了基本信息所要求的事件名事件標示等,還需要指定其生成時所依賴的規則以及輸入事件集。
⑷信息交換與展現:事件“清洗機A”(接收到清洗機A的狀態信息,I)發生后,該事件所能觸發的規則將被檢驗,若規則的條件滿足則產生新的事件“清洗機負載過高”(K),其以I的事件信息體作為輸入,其自身的事件信息體即輸出由規則的Action 決定。此外,通過完成界面組件與事件的綁定(圖5 第四部分)之后,當K 產生時,監控頁面就會對該元素進行包括顏色、數據展示等方式進行展現。
當設備的運行超過負載時,在整體現場監視圖(圖6)上通過不同的顏色進行展現,同時右側表格給出最新具體的狀態信息,如圖6所示:

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

表2 與已有方法的比較

針對以上幾點從表中可以看出,使用基于事件處理的方法在應用范圍與擴展性上有較大的優勢,主要有以下兩點點特點:⑴使用事件表示信息,更具通用性;⑵基于規則進行事件處理,能夠靈活的應對多變的需求,具有較好的擴展性。
綜上所述,本文提出的基于事件處理的信息交換框架,首先建立事件模型,提出多源信息向事件轉化的方法,以事件描述異構的多源信息,接著建立能夠滿足事件處理要求的規則模型,同時給出基于規則的事件處理方法,并介紹了信息交換的展現方法,最后通過一個制造企業中生產車間的監控系統作為驗證,證明了本文所提出的基于事件處理的信息交換方法是切實可行的。在接下來的工作中,主要針對性能指標與安全指標,對整個方法的研究體系進行完善和改進。
[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]蔡昭權.基于ESB的異構系統集成實現[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.