新聞中心

        EEPW首頁 > 模擬技術(shù) > 設(shè)計(jì)應(yīng)用 > 無線射頻識別RFID中間件技術(shù)

        無線射頻識別RFID中間件技術(shù)

        作者: 時(shí)間:2010-10-20 來源:網(wǎng)絡(luò) 收藏

          (RFID)技術(shù)是一種快速、實(shí)時(shí)、準(zhǔn)確的信息采集與處理技術(shù),通過射頻信號對實(shí)體對象進(jìn)行唯一有效的標(biāo)識,可廣泛應(yīng)用于生產(chǎn)、零售、物流、交通、醫(yī)療、國防、畜牧、采礦等各個(gè)行業(yè)。

          基本的RFID系統(tǒng)一般由3部分組成:以及應(yīng)用支撐軟件。是應(yīng)用支撐軟件的一個(gè)重要組成部分,是銜接硬件設(shè)備如和企業(yè)應(yīng)用軟件如企業(yè)資源規(guī)劃(ERP)、客戶關(guān)系管理(CRM)等的橋梁。的主要任務(wù)是對傳來的與相關(guān)的數(shù)據(jù)進(jìn)行過濾、匯總、計(jì)算、分組,減少從閱讀器傳往企業(yè)應(yīng)用的大量原始數(shù)據(jù)、生成加入了語意解釋的事件數(shù)據(jù)。可以說,是RFID系統(tǒng)的“神經(jīng)中樞”。

          對于RFID中間件的設(shè)計(jì),有諸多問題需要考慮,如:如何實(shí)現(xiàn)軟件的諸多質(zhì)量屬性、如何實(shí)現(xiàn)中間件與硬件設(shè)備的隔離、如何處理與設(shè)備管理功能的關(guān)系、如何實(shí)現(xiàn)高性能的數(shù)據(jù)處理等等。

          1 RFID網(wǎng)絡(luò)框架結(jié)構(gòu)

          網(wǎng)絡(luò)的框架結(jié)構(gòu)如圖1所示。

          標(biāo)簽數(shù)據(jù)經(jīng)過中間件的分組、過濾等處理上報(bào)給應(yīng)用系統(tǒng);應(yīng)用系統(tǒng)負(fù)責(zé)事件數(shù)據(jù)的持久化存儲,以及標(biāo)簽綁定的業(yè)務(wù)信息的管理。

          RFID系統(tǒng)共享公共服務(wù)平臺提供根節(jié)點(diǎn)對象名稱服務(wù)(ONS)、企業(yè)應(yīng)用鑒權(quán)管理、標(biāo)簽信息發(fā)現(xiàn)和企業(yè)授權(quán)碼管理等公共服務(wù)。其中,根節(jié)點(diǎn)ONS連同所有企業(yè)級RFID系統(tǒng)的內(nèi)部ONS,組成一個(gè)ONS樹,任何一個(gè)標(biāo)簽都可以在ONS樹上找到標(biāo)簽所對應(yīng)的標(biāo)簽信息庫的地址,即可以進(jìn)一步訪問到標(biāo)簽對應(yīng)的詳細(xì)信息。

          2 中間件功能及實(shí)現(xiàn)原理

          一言蔽之,中間件的功能就是接受應(yīng)用系統(tǒng)的請求,對指定的一個(gè)或者多個(gè)閱讀器發(fā)起操作命令如標(biāo)簽清點(diǎn)、標(biāo)簽標(biāo)識數(shù)據(jù)寫入、標(biāo)簽用戶數(shù)據(jù)區(qū)讀寫、標(biāo)簽數(shù)據(jù)加鎖、標(biāo)簽殺死等,并接收、處理、向后臺應(yīng)用系統(tǒng)上報(bào)結(jié)果數(shù)據(jù)。

          其中,標(biāo)簽清點(diǎn)是最為基本、也是應(yīng)用最為廣泛的功能。

          2.1標(biāo)簽清點(diǎn)功能概述

          標(biāo)簽清點(diǎn)的工作流程可簡單描述為:

          應(yīng)用系統(tǒng)以規(guī)則的形式定義對標(biāo)簽數(shù)據(jù)的需求,規(guī)則由應(yīng)用系統(tǒng)向中間件提出,由中間件維護(hù)。規(guī)則中定義了:需要哪些閱讀器的清點(diǎn)數(shù)據(jù),標(biāo)簽數(shù)據(jù)上報(bào)周期(事件周期)的開始和結(jié)束條件,標(biāo)簽數(shù)據(jù)如何過濾,標(biāo)簽數(shù)據(jù)如何分組,上報(bào)數(shù)據(jù)為原始清點(diǎn)數(shù)據(jù)、新增標(biāo)簽數(shù)據(jù)還是新減標(biāo)簽數(shù)據(jù),標(biāo)簽數(shù)據(jù)包含哪些原始數(shù)據(jù)等。

          應(yīng)用系統(tǒng)指定某項(xiàng)規(guī)則,向中間件提出對標(biāo)簽數(shù)據(jù)的預(yù)訂。

          中間件根據(jù)應(yīng)用系統(tǒng)對標(biāo)簽數(shù)據(jù)的預(yù)訂情況,適時(shí)啟動事件周期,并向閱讀器下發(fā)標(biāo)簽清點(diǎn)命令。

          閱讀器將一定時(shí)間周期(讀取周期)中清點(diǎn)到的數(shù)據(jù),發(fā)送給中間件。讀取周期可由中間件與閱讀器制定私下協(xié)商確定。

          中間件接由收閱讀器上報(bào)的數(shù)據(jù)。

          中間件根據(jù)規(guī)則的定義,對接收數(shù)據(jù)做過濾、分組、累加等操作,并在事件周期結(jié)束時(shí),按照規(guī)則的要求生成數(shù)據(jù)結(jié)果報(bào)告,發(fā)送給規(guī)則的預(yù)訂者。過濾過程可去除重復(fù)數(shù)據(jù)、應(yīng)用系統(tǒng)不感興趣的數(shù)據(jù),大大降低了組件間的傳輸數(shù)據(jù)量。

          此流程可參見圖2。

          此處,需要說明一下邏輯閱讀器的概念。

          中間件將事件源抽象為一個(gè)邏輯概念——邏輯閱讀器,一個(gè)邏輯閱讀器可以包含多個(gè)物理閱讀,甚至可更細(xì)化為包含多個(gè)物理閱讀器的多個(gè)天線。

          邏輯閱讀器的劃分可以根據(jù)實(shí)際的系統(tǒng)部署情況來確定,比如,某一個(gè)倉庫兩個(gè)出口部署了4個(gè)閱讀器,可根據(jù)需要將這4個(gè)閱讀器配置成為一個(gè)邏輯閱讀器,不妨命名為“倉庫出口”。應(yīng)用系統(tǒng)在需要倉庫出口的標(biāo)簽數(shù)據(jù)時(shí),可基于這個(gè)邏輯閱讀器下發(fā)清點(diǎn)命令,而邏輯閱讀器名稱作為部分應(yīng)用程序接口(API)調(diào)用的參數(shù)。

          2.2標(biāo)簽清點(diǎn)實(shí)現(xiàn)原理

          如前所述,規(guī)則是整個(gè)中間件功能的關(guān)鍵元素。規(guī)則相當(dāng)于應(yīng)用系統(tǒng)發(fā)給中間件的訂貨單,定義了對貨品(標(biāo)簽數(shù)據(jù))的時(shí)間(事件周期)和規(guī)格(如何過濾、如何分組、報(bào)告樣式等)的要求,原理描述部分參考EPCglobal相關(guān)內(nèi)容[1]。

          規(guī)則、報(bào)告有自身的信息模型,表征其承載的信息,同時(shí),規(guī)則擁有其自身的狀態(tài)機(jī)模型。在接受應(yīng)用系統(tǒng)的長期預(yù)訂、單次預(yù)訂時(shí),這些預(yù)訂操作會激發(fā)規(guī)則的狀態(tài)變遷,如從“未被請求”狀態(tài)躍遷到“已被請求”狀態(tài)。

          規(guī)則由應(yīng)用系統(tǒng)通過API定義。

          (1) 規(guī)則信息模型

          規(guī)則信息模型的描述采用了統(tǒng)一建模語言(UML),如圖3所示。

          在面向?qū)ο蟮恼Z境中,規(guī)則可表征為一個(gè)類(ECSpec)。從信息模型描述中可看出,一個(gè)規(guī)則類,與其他多個(gè)類具有關(guān)聯(lián)關(guān)系,或者說擁有如下屬性:一個(gè)或者多個(gè)邏輯閱讀器的列表(readers)、事件周期邊界定義(boundaries)、一個(gè)或者多個(gè)報(bào)告的定義(reportSpecs)、是否在報(bào)告中包含規(guī)則本身的標(biāo)記(includeSpecInReports)。

          (2) 報(bào)告信息模型

          與規(guī)則信息模型類似,報(bào)告信息模型如圖4所示。

          其中,事件報(bào)告組類(ECReports)擁有如下屬性:規(guī)則名稱(specName)、時(shí)間上報(bào)時(shí)間(date)、事件周期時(shí)長(totalMilliseconds)、事件周期結(jié)束條件(terminationCondition)、規(guī)則定義類實(shí)例(spec)、一個(gè)或者多個(gè)報(bào)告類的實(shí)例列表(reports)。

          報(bào)告類(ECReport)中包含了具體的標(biāo)簽數(shù)據(jù)信息。

          (3) 標(biāo)簽清點(diǎn)API

          應(yīng)用系統(tǒng)下發(fā)的定義規(guī)則、預(yù)訂數(shù)據(jù)等請求,以調(diào)用中間件提供的API的方式完成。API調(diào)用過程可采用Java RMI、SOAP等相關(guān)具體技術(shù)實(shí)現(xiàn),其中最重要的API參見表1。

          其中,poll操作相當(dāng)于subscribe操作收到一個(gè)事件周期的數(shù)據(jù)之后調(diào)用unsubscribe操作;immediate操作相當(dāng)于define操作定義規(guī)則之后,調(diào)用poll操作,然后調(diào)用undefine操作。

          (4) 規(guī)則狀態(tài)機(jī)模型

          規(guī)則從其定義開始,可能存在于3種狀態(tài):未被請求狀態(tài)(Unrequested)、已被請求狀態(tài)(Requested)、激活狀態(tài)(Active)。

          當(dāng)規(guī)則創(chuàng)建之后,還沒有被任何客戶端(即應(yīng)用系統(tǒng))預(yù)訂,規(guī)則處于Unrequested狀態(tài);對規(guī)則的第一個(gè)預(yù)訂動作將使規(guī)則躍遷到Requested狀態(tài);當(dāng)事件周期開始條件滿足時(shí),規(guī)則進(jìn)入Active狀態(tài);當(dāng)事件周期結(jié)束條件滿足時(shí),如果規(guī)則存在預(yù)訂者,則躍遷到Requested狀態(tài),否則躍遷到Unrequested狀態(tài)。3 中間件系統(tǒng)架構(gòu)

          中間件系統(tǒng)作為一個(gè)軟件系統(tǒng)(或稱組件),在實(shí)現(xiàn)一定功能、性能要求之外,可理解性、可擴(kuò)展性、可修改性(或稱可重構(gòu)性)、可插入性、可重用性等質(zhì)量屬性都將作為軟件設(shè)計(jì)的要求被提出來。

          近十余年來,面向?qū)ο笏枷霂缀跞嬲碱I(lǐng)軟件設(shè)計(jì)領(lǐng)域,成為最主流的分析、設(shè)計(jì)方法。而近數(shù)年來,對設(shè)計(jì)模式的研究也已日臻完善,模式幾乎已成為一種“更高級編程語言”(相比于Java、C++等高級編程語言)被廣泛應(yīng)用。

          面向?qū)ο笏枷搿⒃O(shè)計(jì)模式都是以實(shí)現(xiàn)軟件的可理解、可擴(kuò)展、可修改、可插入、可重用等目標(biāo)為己任的,本文也將應(yīng)用面向?qū)ο笏枷搿⒖寄J秸Z言,對中間件的軟件架構(gòu)做一個(gè)初步的探討,下文的例子如涉及高級編程語言,均采用Java語言[2]。

          3.1封裝、隔離處理流程中的各個(gè)節(jié)點(diǎn)

          將中間件的業(yè)務(wù)流程中的各個(gè)節(jié)點(diǎn)分作不同模塊處理,可以獲得封裝、高內(nèi)聚、低耦合等優(yōu)勢,參見圖5。

          其中,報(bào)告上傳模塊,負(fù)責(zé)實(shí)現(xiàn)不同類型的報(bào)告上傳方式,如HTTP、JMS等;API接口模塊,負(fù)責(zé)隔離應(yīng)用系統(tǒng)和中間件核心業(yè)務(wù)邏輯處理模塊,向應(yīng)用系統(tǒng)提供中間件API接口;中間件核心業(yè)務(wù)邏輯處理模塊,負(fù)責(zé)中間件核心業(yè)務(wù),包括數(shù)據(jù)接收過濾、數(shù)據(jù)分組、報(bào)告生成、規(guī)則對象的狀態(tài)跳轉(zhuǎn)等;閱讀器通信模塊,負(fù)責(zé)中間件系統(tǒng)與閱讀器的通信。

          3.2門面模式、工廠模式對外部暴露API接口

          為了避免后臺應(yīng)用系統(tǒng),即中間件的客戶端過分耦合,采用門面模式(Facade)對系統(tǒng)內(nèi)部、外部實(shí)現(xiàn)清晰的隔離。處理流程可參見圖6所示的序列圖。客戶端僅僅與Facade類建立聯(lián)系,如果Facade接口定義得足夠清晰,客戶端可以對中間件的內(nèi)部實(shí)現(xiàn)一無所知,這體現(xiàn)了面向?qū)ο笾械姆庋b性。

          類的設(shè)計(jì)參見源代碼示例,從中可以看出,采用簡單工廠模式(Simple Factory)能夠在客戶端不知情的情況下,靈活地替換API實(shí)現(xiàn)類的版本。中間件API接口清晰地定義了中間件提供的操作,客戶端只須知道工廠類(APIFactory)能夠得到中間件API接口的實(shí)例即可。

          中間件API接口MiddlewareAPI:

          publicinterfaceMiddlewareAPI{

          void define(String specName, ECSpec spec);

          void undefine(String specName);

          void subscribe(String specName, String uri);

          void unsubscribe(String specName, String uri);

          EPCReports poll(String specName);

          EPCReports immediate(ECSpec spec);

          }

          工廠類APIFactory:

          publicclassAPIFactory{

          publicstaticMiddlewareAPIgetAPIInstance(){

          }

          }

          API的實(shí)現(xiàn)類A:

          publicclassClient{

          publicstaticvoidmain(String[] args) {

          MiddlewareAPI api = APIFactory.getAPIInstance();

          api.define("a new spec", new EPCSpec());

          }

          }


        上一頁 1 2 下一頁

        評論


        相關(guān)推薦

        技術(shù)專區(qū)

        關(guān)閉
        主站蜘蛛池模板: 临城县| 锦州市| 临高县| 巴彦县| 东莞市| 太原市| 福贡县| 七台河市| 深圳市| 新乐市| 常山县| 高要市| 美姑县| 屏东市| 武安市| 搜索| 抚顺市| 昌邑市| 会泽县| 宝兴县| 邛崃市| 峡江县| 常山县| 奎屯市| 大化| 万山特区| 孟村| 开封市| 无极县| 昌宁县| 扎兰屯市| 甘肃省| 苍南县| 酒泉市| 新民市| 清丰县| 威信县| 吴桥县| 汕头市| 九龙县| 长武县|