基于NFC手机的RFID中间件设计

射频识别(RFID) 中间件位于RFID阅读器与上层服务器应用层之间，具有屏蔽底层设备、标签数据清洗、数据交互等功能。目前，国内外许多企业以及机构也都致力于RFID 中间件的研究，如：IBM、Microsoft、清华同方等都有自己的RFID 中间件产品。 这些产品大多部署在服务器端，如果短时间内产生了海量RFID 数据，大量原始数据都将集中在服务器端，对中间件的数据处理能力是很大的考验。同时，海量数据的传输会占用网络带宽，如果网络出现故障，有可能会造成数据的丢失。随着大数据时代的到来，传统RFID 中间件的瓶颈逐渐暴露，直接影响系统的整体性能。因此，在面对海量RFID原始数据的情况下，如何减小服务器端处理压力，降低系统对网络的依赖性成为 RFID 中间件急需解决的问题。本文就一种基于 NFC手机的RFID中间件进行研究与实现，将RFID 中间件技术与移动互联网相结合，弥补了传统RFID 中间件的不足之处，并且符合当前发展趋势。

1 中间件设计方案

1.1 系统架构

根据RFID 中间件功能需求以及移动设备资源有限等特点，提出了如图1 所示的系统架构。

图1 系统总体架构图

1) 设备管理模块主要包含 4 个部分，NFC读卡部分负责调用手机自带 NFC模块进行读取标签信息;外接阅读器管理部分兼容外接阅读器驱动，并通过蓝牙、WiFi、3G网络等与之进行数据交互;工作日志管理部分主要对手机及中间件的工作日志进行管理;手机状态查询部分能够实时地对手机电量、剩余存储空间、信号等状态进行查询。

2)数据处理模块主要包含5 个部分，协议校验部分负责对RFID 标签数据根据标识位进行初步校验，去除残缺的或者非本系统数据;标签缓存部分采用BlockingQueue 队列作为缓存将初步校验后的数据存储;冗余数据处理部分采用自适应的临近排序算法(Sorted Neighborhood Method，SNM)去除冗余数据;数据校验部分采用 CRC16 算法对标签数据中的校验源数据进行校验，以此验证标签数据是否被篡改过;数据分类部分根据约定的数据规则将数据进行分类。

3)数据库模块采用 SQLite 嵌入式数据库存储处理好的数据。

4)数据交互模块采用Quartz框架结合Socket编程实现中间件与服务器之间的数据交互。

5)任务管理模块负责将服务器端发送来的命令文件进行缓存与管理。

1.2 系统设计重点

1.2.1 设备管理模块

该模块主要为对硬件设备的管理与监控，集成NFC以及外接读卡器驱动，并且能够对系统工作日志以及手机状态进行查询。

系统主要采用 NFC模块对RFID 卡片进行读写，集成多种NFC标准，可自动判别卡片类型，相关代码如下所示：

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()}};

为了使系统有良好的可扩展性，中间件兼容多种读卡器驱动，通过蓝牙、WiFi、3G 网络等与外接读卡器进行数据传输。

此外，提供良好的接口，可对中间件工作日志以及手机电量、信号强度、剩余存储空间等信息进行实时查询与管理。

1.2.2 数据处理模块

1)数据缓存、校验及冗余数据处理。

系统采用BlockingQueue 队列作为缓存来存储短时间内接收的大量数据。 将接收的卡片数据进行初步校验，去除残缺或者非本系统数据。

表 1 为标签数据格式，其中UID 为每个标签唯一标识，校验数据中前7 位是用于生成校验码的原始数据，第8 位为本系统标签标识，且对每个标签的前7位校验数据采用 CRC16 算法生成校验码，与标签UID 一起由服务器通过JSON 文件写入到手机端数据库中。 当读取到标签数据后，中间件首先根据校验源数据中第8 位标识符来判断该卡片是否为本系统所属，然后采用相同的 CRC16 算法对前7 位校验数据生成校验码，并根据标签 UID 与数据库中的校验码相比较，以此来判断标签数据是否被改写。 8 位校验源数据在校验完成后需去掉，只将有用数据存储。

表1 RFID 标签数据格式

数据冗余是RFID 系统不可避免的问题，如果数据不清洗，大量有用、无用的数据会占用网络带宽，增加系统处理负担;如果将接收的数据逐一与数据库中的数据进行比对，虽然准确率高，但是面对大量的RFID数据时会降低系统效率，因此，针对移动端有限的资源以及对数据处理效率的综合考虑，本系统采用SNM 算法来处理冗余数据。

数据清洗流程如图2 所示。

图2 数据清洗流程图

2)数据分类。

将通过清洗的数据根据事先约定好的数据规则进行分类，比如事先规定卡片中第 Ni ~Nj 位为数据标识位，则将数据存储到 SQLite 数据库相应表格中。

1.2.3 数据交互模块

该模块负责移动端中间件与服务器之间的数据交互，在保证数据完整性、安全性的前提下，提高传输速度。 采用Socket 通信，以文件的方式传输命令与数据，模块中采用 CRC 校验确保文件安全，并且支持文件断点上传、下载。 将相关文件在移动端进行存储与备份，即使网络出现故障，中间件也可以正常工作，且不会造成数据丢失。

数据交互流程如图3 所示。

图3 数据交互模块流程图

中间件采用Quartz开源框架根据需求设置作业调度，在一定时间自动向服务器发送一次请求，若服务器端有新的命令，则获取该命令，解析并执行，无需人工干预，且参数可由服务器端下发命令进行修改，自动化程度高，可配置性好，服务器端采用多线程处理中间件的请求，进而提高处理效率。

表2 数据交互模块传输速度测试

表 2 为对数据交互模块传输速度的测试结果，其中测试数据为支持ISO15693 标准的RFID标签数据，手机端通过3G 网络向服务器端上传RFID 标签数据文件，支持文件断点续传，而且当文件传输完成后，还会在本地进行备份，避免文件数据丢失。 由于手机端缓存有限，且经过测试，发送的数据包如果过大会导致数据丢失，所以系统数据包大小设置为 1kB，且每发送一次数据包，都会加上报头用以标识该手机以及报尾用作 CRC 校验。 当数据量较小时，传输速度受报头、报尾的影响较大，而当数据量增大时，报头、报尾对数据传输速度的影响越来越少。 所以，当传输的数据量增大到一定程度时(100000 条数据左右)，所消耗的时间基本上与数据量大小成正比，此外，数据传输速度受网络因素以及设备读写速度影响较大。

1.2.4 任务管理模块

将命令文件解析后依次执行，如果命令执行成功，则将命令文件移到备份文件夹中;如果由于网络原因造成命令执行失败，则将该命令加入到任务队列，待网络恢复后执行该命令，命令所需数据暂存在本地数据库中。

如以下JSON 命令所示，status 表示命令状态，即服务器端命令是否正常;order_type 表示命令类型，比如获取数据、修改参数等;details 中表示要进行的详细操作，其中的object 表示操作的对象;action 表示对该对象执行的操作，比如获取某一类型的数据、获取日志文件、获取设备状态或者是修改请求上传/下载时间间隔等程序参数，使得该中间件可配置性好。

1.2.5 数据存储模块

中间件根据服务器端发送来的命令，将相关数据生成JSON 文件，发送到服务器端的同时，将JSON格式的数据文件备份到本地存储设备中，防止由于网络问题等原因造成的服务器端接收的数据不完整，只有服务器端收到完整数据，并且发送相关命令给中间件，中间件才能根据命令将相关数据文件删除，以此节省移动设备的存储空间。

1.3 系统优点

1)减轻服务器端负担。

RFID原始数据经由多个部署在移动设备上的中间件进行处理，将处理后的有效数据发送到服务器端，这样既减少服务器端的压力，又减少网络传输量，提高了系统运行效率。

2)具有数据存储及备份功能，独立性强。

移动设备的存储性能越来越强，当网络或者服务器端出现故障时，可将RFID数据存储在移动设备中，有效避免数据丢失。 因此在断网的情况下也可以正常工作，解决了以往RFID中间件技术对网络的依赖。

3)操作灵活，部署简单。

NFC手机集读卡器、中间件于一体，可以根据数据量的大小增减设备数量，也可根据卡片分布对中间件位置做出调整，方便部署，同时也解决了以往RFID系统中读卡器与中间件之间信息安全及传输速率问题。

4)系统可配置性高。

中间件与服务器端通过传输JSON命令来控制系统进行相关操作或者更改系统参数，比如获取指定数据、改变数据交互时间间隔等。 同时，操作人员也可以通过系统界面对中间件参数进行设置，解决了以往中间件自动化低、可配置性差等缺点。

5)自动报警机制。

系统定期对设备日志及状态信息进行自检，若出现紧急状况，比如设备电量不足、存储空间过满以及卡片信息被篡改等，可以及时地向指定的手机号码发送预警信息，避免造成损失，弥补了以往中间件报警不及时的弊端。

2 系统实现及运行效果

系统采用 Java 语言基于 Eclipse 平台编写，数据库为 SQLite 嵌入式数据库，测试设备为魅族 MX3 智能手机，其 RAM 容量为 2 GB，CPU 频率为 1638MHz，ROM 为 32 GB，测试用卡片遵循 ISO15693 标准，采用NFC模块读取卡片内容，部分运行界面如图4 所示。

图4 系统运行部分界面

当程序运行时，将手机连接电脑，在 Eclipse 中启动 Dalvik 调试监控服务器 (Dalvik Debug MonitorService，DDMS)，并通过 DDMS 自带的 Heap 来查看系统消耗内存，显示该程序所占内存为 22.628 M，CPU 占用率为6%，由此可见，该系统可在移动设备有限的资源中完美运行。 并且经测试，包含 1000 W条RFID数据的 SQLite 数据库大小为188 M，从所占存储空间来看，该RFID 中间件可部署于大部分主流移动设备中，并且可有效处理并存储更多的数据。

为了模拟处理大量RFID 数据下系统工作状况，编写程序根据RFID数据规则自动生成测试数据，不同数据量的系统性能测试结果如表3 所示。

表3 中间件部分性能测试

表3 中T 表示将原始数据经过清洗并且存入数据库所需时间，R和P分别表示数据清洗的召回率和正确率，R=系统正确识别的重复记录数/数据集中实际包含的重复记录数，P=系统正确识别的重复记录数/系统总共检索到的重复记录数，Size表示保存相应数据量数据库的大小。

可以看出，系统能够满足基本的数据处理要求，但数据清洗的召回率、正确率及所耗时间还有待提高，分析其原因主要是滑动窗口的大小以及排序关键字的选择。 当窗口太小时，容易漏配，即去除冗余效果不佳，导致召回率不理想;当窗口太大时，会产生许多没必要的比较，时间效果不理想。所以，采用自适应随机窗口在二者间找到一个平衡点。 本系统选取的关键字是时间戳，而根据实际应用，新到达的RFID数据更能代表当前状况，所以每次比较都保留最新时间戳数据，这样，使得部分数据之间的时间阈值可能小于预设值，即有的数据被误认为是重复数据，导致了准确率不是很理想。

3 结束语

本文提出了基于NFC手机的RFID中间件，由于NFC手机集读卡器与中间件功能于一体，且有较好的存储能力，即使在网络出现故障时中间件仍然可以运行，同时也使得系统部署更为灵活;数据交互模块采用Quartz框架与Socket编程相结合，自动化程度高;通过JSON命令或者良好的界面对参数进行设置，使得系统具有良好的可配置性;在系统发生异常时还可实时发出报警短信，以便及时处理;充分利用移动互联网的优势，将RFID 中间件与移动平台完美结合，解决了传统中间件的诸多不便之处。