射頻識(shí)別(RFID) 中間件位于RFID閱讀器與上層服務(wù)器應(yīng)用層之間，具有屏蔽底層設(shè)備、標(biāo)簽數(shù)據(jù)清洗、數(shù)據(jù)交互等功能。目前，國(guó)內(nèi)外許多企業(yè)以及機(jī)構(gòu)也都致力于RFID 中間件的研究，如：IBM、Microsoft、清華同方等都有自己的RFID 中間件產(chǎn)品。 這些產(chǎn)品大多部署在服務(wù)器端，如果短時(shí)間內(nèi)產(chǎn)生了海量RFID 數(shù)據(jù)，大量原始數(shù)據(jù)都將集中在服務(wù)器端，對(duì)中間件的數(shù)據(jù)處理能力是很大的考驗(yàn)。同時(shí)，海量數(shù)據(jù)的傳輸會(huì)占用網(wǎng)絡(luò)帶寬，如果網(wǎng)絡(luò)出現(xiàn)故障，有可能會(huì)造成數(shù)據(jù)的丟失。隨著大數(shù)據(jù)時(shí)代的到來(lái)，傳統(tǒng)RFID 中間件的瓶頸逐漸暴露，直接影響系統(tǒng)的整體性能。因此，在面對(duì)海量RFID原始數(shù)據(jù)的情況下，如何減小服務(wù)器端處理壓力，降低系統(tǒng)對(duì)網(wǎng)絡(luò)的依賴性成為 RFID 中間件急需解決的問(wèn)題。本文就一種基于 NFC手機(jī)的RFID中間件進(jìn)行研究與實(shí)現(xiàn)，將RFID 中間件技術(shù)與移動(dòng)互聯(lián)網(wǎng)相結(jié)合，彌補(bǔ)了傳統(tǒng)RFID 中間件的不足之處，并且符合當(dāng)前發(fā)展趨勢(shì)。

1 中間件設(shè)計(jì)方案

1.1 系統(tǒng)架構(gòu)

根據(jù)RFID 中間件功能需求以及移動(dòng)設(shè)備資源有限等特點(diǎn)，提出了如圖1 所示的系統(tǒng)架構(gòu)。

圖1 系統(tǒng)總體架構(gòu)圖

1) 設(shè)備管理模塊主要包含 4 個(gè)部分，NFC讀卡部分負(fù)責(zé)調(diào)用手機(jī)自帶 NFC模塊進(jìn)行讀取標(biāo)簽信息;外接閱讀器管理部分兼容外接閱讀器驅(qū)動(dòng)，并通過(guò)藍(lán)牙、WiFi、3G網(wǎng)絡(luò)等與之進(jìn)行數(shù)據(jù)交互;工作日志管理部分主要對(duì)手機(jī)及中間件的工作日志進(jìn)行管理;手機(jī)狀態(tài)查詢部分能夠?qū)崟r(shí)地對(duì)手機(jī)電量、剩余存儲(chǔ)空間、信號(hào)等狀態(tài)進(jìn)行查詢。

2)數(shù)據(jù)處理模塊主要包含5 個(gè)部分，協(xié)議校驗(yàn)部分負(fù)責(zé)對(duì)RFID 標(biāo)簽數(shù)據(jù)根據(jù)標(biāo)識(shí)位進(jìn)行初步校驗(yàn)，去除殘缺的或者非本系統(tǒng)數(shù)據(jù);標(biāo)簽緩存部分采用BlockingQueue 隊(duì)列作為緩存將初步校驗(yàn)后的數(shù)據(jù)存儲(chǔ);冗余數(shù)據(jù)處理部分采用自適應(yīng)的臨近排序算法(Sorted Neighborhood Method，SNM)去除冗余數(shù)據(jù);數(shù)據(jù)校驗(yàn)部分采用 CRC16 算法對(duì)標(biāo)簽數(shù)據(jù)中的校驗(yàn)源數(shù)據(jù)進(jìn)行校驗(yàn)，以此驗(yàn)證標(biāo)簽數(shù)據(jù)是否被篡改過(guò);數(shù)據(jù)分類部分根據(jù)約定的數(shù)據(jù)規(guī)則將數(shù)據(jù)進(jìn)行分類。

3)數(shù)據(jù)庫(kù)模塊采用 SQLite 嵌入式數(shù)據(jù)庫(kù)存儲(chǔ)處理好的數(shù)據(jù)。

4)數(shù)據(jù)交互模塊采用Quartz框架結(jié)合Socket編程實(shí)現(xiàn)中間件與服務(wù)器之間的數(shù)據(jù)交互。

5)任務(wù)管理模塊負(fù)責(zé)將服務(wù)器端發(fā)送來(lái)的命令文件進(jìn)行緩存與管理。

1.2 系統(tǒng)設(shè)計(jì)重點(diǎn)

1.2.1 設(shè)備管理模塊

該模塊主要為對(duì)硬件設(shè)備的管理與監(jiān)控，集成NFC以及外接讀卡器驅(qū)動(dòng)，并且能夠?qū)ο到y(tǒng)工作日志以及手機(jī)狀態(tài)進(jìn)行查詢。

系統(tǒng)主要采用 NFC模塊對(duì)RFID 卡片進(jìn)行讀寫，集成多種NFC標(biāo)準(zhǔn)，可自動(dòng)判別卡片類型，相關(guān)代碼如下所示：

mTechLists =new String[][]{new String[]{MifareClassic.class.getName()}，

new String[]{MifareUltralight.class.getName()}，

new String[]{NdefFormatable.class.getName()}，

new String[]{Ndef.class.getName()}，

new String[]{IsoDep.class.getName()}，

new String[]{NfcV.class.getName()}，

new String[]{NfcF.class.getName()}，

new String[]{NfcB.class.getName()}，

new String[]{NfcA.class.getName()}};

為了使系統(tǒng)有良好的可擴(kuò)展性，中間件兼容多種讀卡器驅(qū)動(dòng)，通過(guò)藍(lán)牙、WiFi、3G 網(wǎng)絡(luò)等與外接讀卡器進(jìn)行數(shù)據(jù)傳輸。

此外，提供良好的接口，可對(duì)中間件工作日志以及手機(jī)電量、信號(hào)強(qiáng)度、剩余存儲(chǔ)空間等信息進(jìn)行實(shí)時(shí)查詢與管理。

1.2.2 數(shù)據(jù)處理模塊

1)數(shù)據(jù)緩存、校驗(yàn)及冗余數(shù)據(jù)處理。

系統(tǒng)采用BlockingQueue 隊(duì)列作為緩存來(lái)存儲(chǔ)短時(shí)間內(nèi)接收的大量數(shù)據(jù)。 將接收的卡片數(shù)據(jù)進(jìn)行初步校驗(yàn)，去除殘缺或者非本系統(tǒng)數(shù)據(jù)。

表 1 為標(biāo)簽數(shù)據(jù)格式，其中UID 為每個(gè)標(biāo)簽唯一標(biāo)識(shí)，校驗(yàn)數(shù)據(jù)中前7 位是用于生成校驗(yàn)碼的原始數(shù)據(jù)，第8 位為本系統(tǒng)標(biāo)簽標(biāo)識(shí)，且對(duì)每個(gè)標(biāo)簽的前7位校驗(yàn)數(shù)據(jù)采用 CRC16 算法生成校驗(yàn)碼，與標(biāo)簽UID 一起由服務(wù)器通過(guò)JSON 文件寫入到手機(jī)端數(shù)據(jù)庫(kù)中。 當(dāng)讀取到標(biāo)簽數(shù)據(jù)后，中間件首先根據(jù)校驗(yàn)源數(shù)據(jù)中第8 位標(biāo)識(shí)符來(lái)判斷該卡片是否為本系統(tǒng)所屬，然后采用相同的 CRC16 算法對(duì)前7 位校驗(yàn)數(shù)據(jù)生成校驗(yàn)碼，并根據(jù)標(biāo)簽 UID 與數(shù)據(jù)庫(kù)中的校驗(yàn)碼相比較，以此來(lái)判斷標(biāo)簽數(shù)據(jù)是否被改寫。 8 位校驗(yàn)源數(shù)據(jù)在校驗(yàn)完成后需去掉，只將有用數(shù)據(jù)存儲(chǔ)。

表1 RFID 標(biāo)簽數(shù)據(jù)格式

數(shù)據(jù)冗余是RFID 系統(tǒng)不可避免的問(wèn)題，如果數(shù)據(jù)不清洗，大量有用、無(wú)用的數(shù)據(jù)會(huì)占用網(wǎng)絡(luò)帶寬，增加系統(tǒng)處理負(fù)擔(dān);如果將接收的數(shù)據(jù)逐一與數(shù)據(jù)庫(kù)中的數(shù)據(jù)進(jìn)行比對(duì)，雖然準(zhǔn)確率高，但是面對(duì)大量的RFID數(shù)據(jù)時(shí)會(huì)降低系統(tǒng)效率，因此，針對(duì)移動(dòng)端有限的資源以及對(duì)數(shù)據(jù)處理效率的綜合考慮，本系統(tǒng)采用SNM 算法來(lái)處理冗余數(shù)據(jù)。

數(shù)據(jù)清洗流程如圖2 所示。

圖2 數(shù)據(jù)清洗流程圖

2)數(shù)據(jù)分類。

將通過(guò)清洗的數(shù)據(jù)根據(jù)事先約定好的數(shù)據(jù)規(guī)則進(jìn)行分類，比如事先規(guī)定卡片中第 Ni ~Nj 位為數(shù)據(jù)標(biāo)識(shí)位，則將數(shù)據(jù)存儲(chǔ)到 SQLite 數(shù)據(jù)庫(kù)相應(yīng)表格中。

1.2.3 數(shù)據(jù)交互模塊

該模塊負(fù)責(zé)移動(dòng)端中間件與服務(wù)器之間的數(shù)據(jù)交互，在保證數(shù)據(jù)完整性、安全性的前提下，提高傳輸速度。 采用Socket 通信，以文件的方式傳輸命令與數(shù)據(jù)，模塊中采用 CRC 校驗(yàn)確保文件安全，并且支持文件斷點(diǎn)上傳、下載。 將相關(guān)文件在移動(dòng)端進(jìn)行存儲(chǔ)與備份，即使網(wǎng)絡(luò)出現(xiàn)故障，中間件也可以正常工作，且不會(huì)造成數(shù)據(jù)丟失。

數(shù)據(jù)交互流程如圖3 所示。

圖3 數(shù)據(jù)交互模塊流程圖

中間件采用Quartz開(kāi)源框架根據(jù)需求設(shè)置作業(yè)調(diào)度，在一定時(shí)間自動(dòng)向服務(wù)器發(fā)送一次請(qǐng)求，若服務(wù)器端有新的命令，則獲取該命令，解析并執(zhí)行，無(wú)需人工干預(yù)，且參數(shù)可由服務(wù)器端下發(fā)命令進(jìn)行修改，自動(dòng)化程度高，可配置性好，服務(wù)器端采用多線程處理中間件的請(qǐng)求，進(jìn)而提高處理效率。

表2 數(shù)據(jù)交互模塊傳輸速度測(cè)試

表 2 為對(duì)數(shù)據(jù)交互模塊傳輸速度的測(cè)試結(jié)果，其中測(cè)試數(shù)據(jù)為支持ISO15693 標(biāo)準(zhǔn)的RFID標(biāo)簽數(shù)據(jù)，手機(jī)端通過(guò)3G 網(wǎng)絡(luò)向服務(wù)器端上傳RFID 標(biāo)簽數(shù)據(jù)文件，支持文件斷點(diǎn)續(xù)傳，而且當(dāng)文件傳輸完成后，還會(huì)在本地進(jìn)行備份，避免文件數(shù)據(jù)丟失。 由于手機(jī)端緩存有限，且經(jīng)過(guò)測(cè)試，發(fā)送的數(shù)據(jù)包如果過(guò)大會(huì)導(dǎo)致數(shù)據(jù)丟失，所以系統(tǒng)數(shù)據(jù)包大小設(shè)置為 1kB，且每發(fā)送一次數(shù)據(jù)包，都會(huì)加上報(bào)頭用以標(biāo)識(shí)該手機(jī)以及報(bào)尾用作 CRC 校驗(yàn)。 當(dāng)數(shù)據(jù)量較小時(shí)，傳輸速度受報(bào)頭、報(bào)尾的影響較大，而當(dāng)數(shù)據(jù)量增大時(shí)，報(bào)頭、報(bào)尾對(duì)數(shù)據(jù)傳輸速度的影響越來(lái)越少。 所以，當(dāng)傳輸?shù)臄?shù)據(jù)量增大到一定程度時(shí)(100000 條數(shù)據(jù)左右)，所消耗的時(shí)間基本上與數(shù)據(jù)量大小成正比，此外，數(shù)據(jù)傳輸速度受網(wǎng)絡(luò)因素以及設(shè)備讀寫速度影響較大。

1.2.4 任務(wù)管理模塊

將命令文件解析后依次執(zhí)行，如果命令執(zhí)行成功，則將命令文件移到備份文件夾中;如果由于網(wǎng)絡(luò)原因造成命令執(zhí)行失敗，則將該命令加入到任務(wù)隊(duì)列，待網(wǎng)絡(luò)恢復(fù)后執(zhí)行該命令，命令所需數(shù)據(jù)暫存在本地?cái)?shù)據(jù)庫(kù)中。

如以下JSON 命令所示，status 表示命令狀態(tài)，即服務(wù)器端命令是否正常;order_type 表示命令類型，比如獲取數(shù)據(jù)、修改參數(shù)等;details 中表示要進(jìn)行的詳細(xì)操作，其中的object 表示操作的對(duì)象;action 表示對(duì)該對(duì)象執(zhí)行的操作，比如獲取某一類型的數(shù)據(jù)、獲取日志文件、獲取設(shè)備狀態(tài)或者是修改請(qǐng)求上傳/下載時(shí)間間隔等程序參數(shù)，使得該中間件可配置性好。

1.2.5 數(shù)據(jù)存儲(chǔ)模塊

中間件根據(jù)服務(wù)器端發(fā)送來(lái)的命令，將相關(guān)數(shù)據(jù)生成JSON 文件，發(fā)送到服務(wù)器端的同時(shí)，將JSON格式的數(shù)據(jù)文件備份到本地存儲(chǔ)設(shè)備中，防止由于網(wǎng)絡(luò)問(wèn)題等原因造成的服務(wù)器端接收的數(shù)據(jù)不完整，只有服務(wù)器端收到完整數(shù)據(jù)，并且發(fā)送相關(guān)命令給中間件，中間件才能根據(jù)命令將相關(guān)數(shù)據(jù)文件刪除，以此節(jié)省移動(dòng)設(shè)備的存儲(chǔ)空間。

1.3 系統(tǒng)優(yōu)點(diǎn)

1)減輕服務(wù)器端負(fù)擔(dān)。

RFID原始數(shù)據(jù)經(jīng)由多個(gè)部署在移動(dòng)設(shè)備上的中間件進(jìn)行處理，將處理后的有效數(shù)據(jù)發(fā)送到服務(wù)器端，這樣既減少服務(wù)器端的壓力，又減少網(wǎng)絡(luò)傳輸量，提高了系統(tǒng)運(yùn)行效率。

2)具有數(shù)據(jù)存儲(chǔ)及備份功能，獨(dú)立性強(qiáng)。

移動(dòng)設(shè)備的存儲(chǔ)性能越來(lái)越強(qiáng)，當(dāng)網(wǎng)絡(luò)或者服務(wù)器端出現(xiàn)故障時(shí)，可將RFID數(shù)據(jù)存儲(chǔ)在移動(dòng)設(shè)備中，有效避免數(shù)據(jù)丟失。 因此在斷網(wǎng)的情況下也可以正常工作，解決了以往RFID中間件技術(shù)對(duì)網(wǎng)絡(luò)的依賴。

3)操作靈活，部署簡(jiǎn)單。

NFC手機(jī)集讀卡器、中間件于一體，可以根據(jù)數(shù)據(jù)量的大小增減設(shè)備數(shù)量，也可根據(jù)卡片分布對(duì)中間件位置做出調(diào)整，方便部署，同時(shí)也解決了以往RFID系統(tǒng)中讀卡器與中間件之間信息安全及傳輸速率問(wèn)題。

4)系統(tǒng)可配置性高。

中間件與服務(wù)器端通過(guò)傳輸JSON命令來(lái)控制系統(tǒng)進(jìn)行相關(guān)操作或者更改系統(tǒng)參數(shù)，比如獲取指定數(shù)據(jù)、改變數(shù)據(jù)交互時(shí)間間隔等。 同時(shí)，操作人員也可以通過(guò)系統(tǒng)界面對(duì)中間件參數(shù)進(jìn)行設(shè)置，解決了以往中間件自動(dòng)化低、可配置性差等缺點(diǎn)。

5)自動(dòng)報(bào)警機(jī)制。

系統(tǒng)定期對(duì)設(shè)備日志及狀態(tài)信息進(jìn)行自檢，若出現(xiàn)緊急狀況，比如設(shè)備電量不足、存儲(chǔ)空間過(guò)滿以及卡片信息被篡改等，可以及時(shí)地向指定的手機(jī)號(hào)碼發(fā)送預(yù)警信息，避免造成損失，彌補(bǔ)了以往中間件報(bào)警不及時(shí)的弊端。

2 系統(tǒng)實(shí)現(xiàn)及運(yùn)行效果

系統(tǒng)采用 Java 語(yǔ)言基于 Eclipse 平臺(tái)編寫，數(shù)據(jù)庫(kù)為 SQLite 嵌入式數(shù)據(jù)庫(kù)，測(cè)試設(shè)備為魅族 MX3 智能手機(jī)，其 RAM 容量為 2 GB，CPU 頻率為 1638MHz，ROM 為 32 GB，測(cè)試用卡片遵循 ISO15693 標(biāo)準(zhǔn)，采用NFC模塊讀取卡片內(nèi)容，部分運(yùn)行界面如圖4 所示。

圖4 系統(tǒng)運(yùn)行部分界面

當(dāng)程序運(yùn)行時(shí)，將手機(jī)連接電腦，在 Eclipse 中啟動(dòng) Dalvik 調(diào)試監(jiān)控服務(wù)器 (Dalvik Debug MonitorService，DDMS)，并通過(guò) DDMS 自帶的 Heap 來(lái)查看系統(tǒng)消耗內(nèi)存，顯示該程序所占內(nèi)存為 22.628 M，CPU 占用率為6%，由此可見(jiàn)，該系統(tǒng)可在移動(dòng)設(shè)備有限的資源中完美運(yùn)行。 并且經(jīng)測(cè)試，包含 1000 W條RFID數(shù)據(jù)的 SQLite 數(shù)據(jù)庫(kù)大小為188 M，從所占存儲(chǔ)空間來(lái)看，該RFID 中間件可部署于大部分主流移動(dòng)設(shè)備中，并且可有效處理并存儲(chǔ)更多的數(shù)據(jù)。

為了模擬處理大量RFID 數(shù)據(jù)下系統(tǒng)工作狀況，編寫程序根據(jù)RFID數(shù)據(jù)規(guī)則自動(dòng)生成測(cè)試數(shù)據(jù)，不同數(shù)據(jù)量的系統(tǒng)性能測(cè)試結(jié)果如表3 所示。

表3 中間件部分性能測(cè)試

表3 中T 表示將原始數(shù)據(jù)經(jīng)過(guò)清洗并且存入數(shù)據(jù)庫(kù)所需時(shí)間，R和P分別表示數(shù)據(jù)清洗的召回率和正確率，R=系統(tǒng)正確識(shí)別的重復(fù)記錄數(shù)/數(shù)據(jù)集中實(shí)際包含的重復(fù)記錄數(shù)，P=系統(tǒng)正確識(shí)別的重復(fù)記錄數(shù)/系統(tǒng)總共檢索到的重復(fù)記錄數(shù)，Size表示保存相應(yīng)數(shù)據(jù)量數(shù)據(jù)庫(kù)的大小。

可以看出，系統(tǒng)能夠滿足基本的數(shù)據(jù)處理要求，但數(shù)據(jù)清洗的召回率、正確率及所耗時(shí)間還有待提高，分析其原因主要是滑動(dòng)窗口的大小以及排序關(guān)鍵字的選擇。 當(dāng)窗口太小時(shí)，容易漏配，即去除冗余效果不佳，導(dǎo)致召回率不理想;當(dāng)窗口太大時(shí)，會(huì)產(chǎn)生許多沒(méi)必要的比較，時(shí)間效果不理想。所以，采用自適應(yīng)隨機(jī)窗口在二者間找到一個(gè)平衡點(diǎn)。 本系統(tǒng)選取的關(guān)鍵字是時(shí)間戳，而根據(jù)實(shí)際應(yīng)用，新到達(dá)的RFID數(shù)據(jù)更能代表當(dāng)前狀況，所以每次比較都保留最新時(shí)間戳數(shù)據(jù)，這樣，使得部分?jǐn)?shù)據(jù)之間的時(shí)間閾值可能小于預(yù)設(shè)值，即有的數(shù)據(jù)被誤認(rèn)為是重復(fù)數(shù)據(jù)，導(dǎo)致了準(zhǔn)確率不是很理想。

3 結(jié)束語(yǔ)

本文提出了基于NFC手機(jī)的RFID中間件，由于NFC手機(jī)集讀卡器與中間件功能于一體，且有較好的存儲(chǔ)能力，即使在網(wǎng)絡(luò)出現(xiàn)故障時(shí)中間件仍然可以運(yùn)行，同時(shí)也使得系統(tǒng)部署更為靈活;數(shù)據(jù)交互模塊采用Quartz框架與Socket編程相結(jié)合，自動(dòng)化程度高;通過(guò)JSON命令或者良好的界面對(duì)參數(shù)進(jìn)行設(shè)置，使得系統(tǒng)具有良好的可配置性;在系統(tǒng)發(fā)生異常時(shí)還可實(shí)時(shí)發(fā)出報(bào)警短信，以便及時(shí)處理;充分利用移動(dòng)互聯(lián)網(wǎng)的優(yōu)勢(shì)，將RFID 中間件與移動(dòng)平臺(tái)完美結(jié)合，解決了傳統(tǒng)中間件的諸多不便之處。