RFID中介軟體如何處理複雜的事件？

Hu等人於 2008 年 Complex Event Processing in RFID Middleware: A Three Layer Perspective 文章裏提到：現在已經有一些中介軟體處理 RFID 事件的過濾和匯總等功能，例如有 BEA 、 Sun 、 Singularity 和 Logicalloy 等公司的產品；不過，作者們注意到 EPCglobal Network 的架構，在 Application Level Events 和 EPC Information Service 之間有一個叫做 EPC Capture Application 的層次。他們說，在 EPC Capture Application 層次， RFID 中介軟體應該運作一些複雜的功能，為了處理特定的商務流程而處理較複雜的 RFID 事件。

架構分為三個層次，由下層到上層依序為：

1. 邏輯結構： RFID 事件源自讀寫機探測到的基本事件，而複雜的事件是由一些基本事件組成，或者，複雜事件也可以由另外一些複雜事件組成。
2. 時間限制：在複雜事件結構中，可以加上時間限制的屬性。
3. 事件偵測：應用前二層的產物，藉由複雜事件分析，向上回報究竟發生了哪些事件類型。

這篇文章對事件結構做了初步的正規描述，並使用 Petri Net 為處理工具。對第一層，邏輯結構方面，使用 Petri Net 延伸的模型 Composite Event Structure-layer Net 。對時間限制層面，使用 structured token and transition mark 處理。對事件偵測層面，使用 Petri Net 著色方法處理；但是本文尚未討論到 Petri Net 著色方法的細節。

邏輯結構

每一個基本事件，按照 EPCglobal 的說法，是讀寫機探測並回報在什麼時候「看見」了哪個 tag 。用大寫字母 A, B, ... 表示每一個基本事件的類型。於是，用到以下六項運算，可以處理許多基本事件之間的各種基本邏輯關係：

1. 彙總： (A, n) 表示進來 n 個 A 事件。
2. 分離： (A | B) 表示進來的事件是 A 或 B 。
3. 結合： (A & B) 表示 A 和 B 二事件都進來。
4. 否定： (~ A) 表示 A 事件沒有進來。
5. 順序： (A; B, t) 表示依序有 A 和 B 二事件，而且二事件的間距在 t 時間區段之內。
6. 內在： Within(A, t) 表示 A 事件在 t 時間區間之內進來。

事件的間距定義是，對事件 e 有一對參數 [Start e, End e] ，表示事件發生的時間和結束的時間。事件 e 自己發生的時間長度是 (Start e - End e) 。二事件 A, B 有 (A; B, t) 順序，代表：

(A & B) [0 < Start A - End B < t]

即為 A, B 二事件除了同時發生之外，加上 A, B 的時間有些差距。

而事件 A 在 t 時間之內發生， Within(A, t) ，可以改寫成：

(A, 1)[Start A - End A > t]

(註：以上二式都是文章中的原文照列，不過看起來有一些矛盾的疑問。)
即為發生了一件 A 事件，並且此事件持續了有 t 時間區段那麼久。

所以，事件的順序關係是結合關係的特例，而內在關係是彙總關係的特例。

以上所指六項運算符號，扣除二項特例，可以有四種 Petri Net 圖型表達彙總、分離、結合、以及否定等關係。

時間限制

對一個事件 e ，將它對應事件類型的集合表示為 S e 。則加上時間限制的結構是一個三元詞組 (Start e, End e, S e) ：例如，進來一個事件 (epc, r, t) ，則做出一個 token 為 (t, t, {(epc, r, t)}) 。
(註：此例中 (epc, r, t) 也有些疑問，在此也暫以原文照列。)
做成這樣的 token 是為了使 Petri Net 中 Guard 位置計算比較方便。

其他人的相關作品

Siemens RFID 中介軟體使用宣告式的語言，可撰寫規則，用到邏輯和時間限制的運算語法。事件偵測以圖論為基礎。

SAMOS 以 Colored Petri Net 做事件偵測的機制。

Esper 是一件開源軟體，處理複雜事件和事件串流的架構。用到類似 SQL 的語言表達複雜事件，並使用自動狀態機做事件偵測。

ALE middleware 架構布局

目前正在思考 Application Level Events 介面 [1,2] 如何整併入系統中。我的構想如右圖。 Middleware 為 ALE 介面的實作，處理讀寫命令呼叫及程序觸發與控制，可能是獨立 server 、或是 DLL 、 local services 或 Web services 形式。一件 middleware server 可以管理許多台 readers 。 Middleware 對應用系統提供介面做讀取 (pooling) 。

Middleware 對 readers 以低層 reader 協定 (LLRP) 溝通，對應用系統則以 SOAP (簡單物件存取協定) 溝通。 Readers 的設定表可能離線備份在 middleware ，使上下二端讀取設定比較簡單。每一台 reader 只和少數一件 middleware（或二件，包含備援機）溝通，不同步的問題會比較少。應用系統的開發人員則呼叫 middleware 的 ALE 介面，傳 SOAP 參數或訊息，讓程式比較好寫。不過，少數的 middleware 會是效能關卡，這方面還要思考解決方案。


Middleware 做成獨立模組，內涵物可以有許多故事。例如 [4] 的處理方式。

SOAP 效能問題則可以參考 [3] 的處理方式（參左圖）：應用系統送出訊息（由路線 2 ）都由 client 代理，處理每一串 SOAP 訊息都先找 cache 有沒有舊的相同資料（由路線 3 ），若有則發送舊的訊息（由路線 5 ），或者若沒有則發送新訊息（由路線 5 ）。

參考資料

[1] EPCglobal Inc. The EPCglobal architecture framework, EPCglobal final version 1.2 approved 10 September 2007. http://www.epcglobalinc.org/standards/architecture/architecture_1_2-framework-20070910.pdf , Sep. 10, 2007 (referred at August 2008).

[2] EPCglobal Inc. The Application Level Events (ALE) specification, version 1.1: Part I: Core specification. http://www.epcglobalinc.org/standards/ale/ale_1_1-standard-core-20080227.pdf , Feb. 27, 2008 (referred at September 2008).

[3] K. Devaram and D. Andresen. SOAP optimization via client-side caching. Proceedings of the First International Conference on Web Services (ICWS'03), pp. 520-524, Las Vegas, NV, June 24-27, 2003.

[4] J. Song, T. Kim, S. Lee, and H. Kim. Security enhanced RFID middleware system. Procedings of World Academy of Science, Engineering and Technology, v.10, pp.79-82, Dec. 10, 2005.