如何用Java软件来开发射频身份识别自动识别方案?

Oct 12, 2004
原文

如何用Java软件来开发射频身份识别 自动识别方案

本文主要描述怎么使用Sun Java 系统RFID软件来开发RFID解决方案.同时帮助开发人员理解架构,设计和实现.
文章也包括的一个可以下载的应用例子,sampleRFID.同同文档一起的ReadME描述的如何同给定接口编码的细节,并且如何配置平台.

什么是RFID和Auto-ID?

射频身份识或RFID使用射频波来识别唯一对象的一种方法.RFID是对下一代条码技术的需求作出的反应.
用最简单的术语来说,RFID系统有标签(应答器)和阅读器(询问器)组成.RFID技术处理用射频通讯收集储存在标签里的远程信息.

储存在标签里的信息范围从一个表示数字到数K的数据可以被写入和读出,动态的信息比如温度的历史在标签中维护.

自动识别或Auto-ID是一个广泛的术语,包括数据数据的方法和无人工干预直接进入计算机系统.
技术传统上认为Auto-ID的部分包括条码,生物测定学,RFID,和声音识别技术.

Auto-ID 技术提供系列方法用来追踪任何物体,任何时间,任何地点.Auto-ID系统基于上面低花费的聪明标签和阅读器,及唯一的对象表示模式.Auto-ID的目标是可以替代UPC条码系统而使用不贵的RFID标签嵌入到产品包装里.或更加好的方式比如嵌入到产品里面.虽然条码不会很快消失.有许多应用如果使用RFID标签将变的更加复杂和增加成本,而使用条码就比较完美。在可见的将来，将是条码和RFID标签共存的时期.

Auto-ID网络由数个使用Auto-ID系统的贸易伙伴组用来追踪供应链上的项目.这将提供商业上空前的实时资产和任何地方的库存视图.并且能提供有重大意义的商标保护努力.Auto-ID网络提供的好处在于定位伪造,串改,恐怖主义和其他的要求的操作的有效性


标准

EPCglobal是Auto-ID的创造中心.它的标准内容基于EPCglobal网络采用的EPC技术.Epglobal 网络包括一组允许及时，自动标识和共享供应链项目信息的技术.EPCglobal网络使用射频标识(RFID)技术是供应链项目信息可见性成为可能.这个网络有5个基本元素组成:

* 电子产品代码 (EPC)
* ID系统(EPC 标签和阅读器)
* EPC 中间件
* 对象命名服务(ONS)
* 物理标记语言

EPC编号系统:
如同统一产品代码(UPC)或条码,EPC是EPC网络上的物理对象的基本标识.
EPC标识厂商,产品,版本和序列号.并且使用额外的数字组表示唯一项目.
EPC标签数据标准规范版本1.1定义了电子产品代码(EPC)在RFID芯片上的编码.也定义如何被EPC网络信息系统层使用的编码(比如RFID信息服务器).

EPC标签和阅读器和接口协议:
EPC标签是带天线的微芯片.EPC被保存在这个标签里,这是在制造过程就被应用了.
EPC标签使用射频标识(RFID)来传递他们的EPC到EPC阅读器.EPC阅读器同EPC标签通讯通过无线电波并且通过EPC中间件发送信息到本地商业信息系统.
这是Auto-ID阅读器协议规范1.0定义的关于阅读器和EPC中间件的通讯的标准协议.

阅读器管理规范扩展了阅读器协议规范,定义了在大的网络上如何管理RFID的标准.

标签可以分类为被动，主动和半被动的.被动标签没有电池及当有提示的时候简单"反射".而活跃标签自带电池并且是通讯发起者.
半被动标签有一个电池,但是也是属于"反射"通讯.它不会启动一个通讯.
可以想象被动和半被动标签作为一个用来传送光的镜子 ,当有光照在它们上面的时候.今天,EPCglobal网络集中精力在被动标签标准上.我们可以期望EPCNetwork关于积极标签的标准很快建立.

EPC中间件:
EPC 中间件过去也叫做Savant.它是关于实时事件管理,EPC数据过滤和收集规范的标准.它覆盖了新的EPCglobal规范,当前作为过滤和收集规范的参考.

EPC信息服务:
EPC信息服务允许用户同使用EPC的商业伙伴交换数据

对象命名服务(ONS):
给你能力来定位包含关于世界上特定任何地方EPC信息的服务器.商业信息系统需要一种方法匹配EPC和货物关联的信息.
ONS是提供通过指明在www上的计算机来提供自动的网络服务.它为包含产品属性及相关属性被维护的的IP地址制定了一个标准.

物理标志语言:(PML)
用做通用语言在EPCglobal网络中,用来定义物理对象的数据.PML的目标是提供一般收集,标准表达词汇和分布信息到
EPC网络可用的对象.PML 核心规范1.0定义了PML标准.

介绍Sun Java 系统RFID软件.

Sun Java系统RFID软件是Sun唯一RFID中件间平台提供提供基于广泛被接受的工业标准也包括在EPCglobal中定义的标准.
它为公司使用EPC网络提供了一个基础. 它的设计规范是提供一个高层次高可靠性和扩充能力的EPC网络同时可以简化同多个
已经存在的后台企业系统整合的任务

Sun java系统RFID软件负责在EPC阅读器和标签之间的EPC数据和事件的通讯和处理,及后台供应链系统ERP.和RFID软件包含
两个基本的部件:1).RFID事件管理 2)RFID信息服务器.两个都可以下载.这两个组件基于Jini 2.0,Rio 3.0.1,及Java Web Service Developer pack 1.3和Sun Application server 7构造.

*RFID事件管理器同EPC标签阅读器通讯来出来大量的EPC数据进入系统.事件管理器也同后台系统通讯并向RFID信息服务器记录
EPC数据和事件.RFID事件管理器是Jnin-Based的事件管理系统.它容易铺捉,过滤和保存由连接到网络上的RFID阅读器产生的EPC事件.
它的主要目标是同RFID阅读器的接口,收集EPC事件,过滤多余信息,并且产生送往迎来RFID信息服务器的相关事件或者其他
EPR软件以备处理.RFID事件管理器Jini服务通过Rio被管理,Rio是一个开源的Jini服务组件包容器.

*RFID信息服务器负责储存和聚集围绕给定的EPC事件关系的业务数据.RFID信息服务器J2EE应用用做一个接口来俘获和查询EPC
相关数据.EPC相关数据包括:来自事件管理器的检查数据也包括映射EPCS到较高级别的商业数据的信息.
RFID 信息服务器是典型的用来转换低级检查到高级商业功能.RFID信息服务器运行在Sun Java系统Application Server 7.
其他信息系统应用接口通过XML信息交换.信息系统支持HTTP和JMS信息输送.
信息系统保存所有数据到关系数据库中.

这两个组件扮演了关键的角色在EPCglobalo 定义的EPC网络中


Sun Java系统RFID软件技术描述

Sun Java 系统RFID事件管理器收集RFID阅读器的信息,过滤信息并且提供大量的信息到RFID信息服务器或第三方的ERP系统.

Figure 1 描述 RFID事件管理器和RFID信息服务器怎样适合EPC Global网络



Figure 1: Sun Java System RFID软件和EPCglobal网络

RFID事件管理器由控制工作站和一个或多个执行代理组成在图2中描述



Figure 2: Sun Java System RFID事件管理器架构

计算机系统可以运行一个或多个执行代理并且每个执行代理可以完成一个或多个工作量.每个执行代理在启动的时候向控制工作站
注册.

控制工作站保存可使用的执行代理注册,监视它们的状态,分配工作量并且帮助他们完成工作量.

一个执行代理包含一个Adapter,一个Logger和Filter组件.每个执行代理可以组成Adapter的馈给信息送到一个或多个filter或
logger,并且没个filter馈给信息给一个或多个logger.Adapter是个Java代码片同实际的RFID阅读器接口.

Sun Java系统RFID 事件管理器 来自被包装的预定义了编码的Adapter.它能理解EPC-顺从的RFID阅读器使用的指定的通讯协议.
这些阅读器 Adapter可以看做计算机系统里同周围外部设备通讯的设备驱动程序.
目前,没有标准的通讯协议可以被RFID阅读器使用来同消费它们的RFID事件的软件通讯.
RFID阅读器是独立的一片(典型的)硬件用来同RFID标签基于无线电频率通讯.
Adpater(适配器A)获得RFID标签的EPC并且产生一个事件包含时间戳和时间源(阅读器和天线发现标签).
事件被传送到处理事件的一组监听器.监听器是filter或logger.Filter可以平滑数据,扔掉先前探测信息或到其他
filter或logger的路由信息.过滤后的数据被传送作为一个事件到感兴趣的listener.Listener可以被其他有更多的数据的filter或logger作为一个连接器到第三方消费RFID信息的应用

The two tables below list the supported filters and loggers and their main functionality.
下列两个表列出了支持的filter和logger及它们主要的功能.

Table:1 Filters 由SunJava系统RFID事件管理器实现.
Filter Type Description
BandPass BandPass在阅读器EPC执行滤过器,来自阅读器的事件匹配EPC掩码被放行到listener,其他的则放弃.
Delta 报告标签进入和留下的视野
EPCFilter 同BandPass.
Smoothing Smoothing creates a union of EPC's discovered over the number of specified N cycles. If an EPC was discovered in cycle N, it is reported, if it hasn't been seen in more than the last N cycles, it is not reported. This is necessary because the RFID readers do not report tags with 100% tag accuracy.

Table 2: Loggers 由Sun Java系统RFID事件管理器实现.
名称 描述
FileLogger Logger that writes out PML Core to a file
HttpPmlLogger Logger thats write out PML Core to an HTTP connection
JMSLogger Logger that writes out PML Core to a JMS Queue or Topic
SocketLogger Creates a Socket connection and starts writing PML Core to the connection
SsocketLogger Creates a Server Socket connection and starts writing PML Core to the connection

The user configures the adapters, filters and loggers properties through an XML configuration file. The adapters, filters and loggers are tied to one another by use of a special

tag in the configuration file. Figure 3 below illustrates the design and syntax of the XML configuration file. The dotted lines imply that the associated elements or components are optional. Zero or more of each can be present.


Figure 3: Illustration of Sun Java System RFID Event Manager Configuration File

The following attributes define the Adapters of the RFID Event Manager:

1. name: The unique name for the component.
2. classname: The name of the Java class that implements the component.
3. LogLevel: The LogLevel parameter specifies the detail of logging information to be generated by the Adapter. The settings follow java.util.logging conventions established in the J2SE release of the Java VM.
4. properties: A sequence of name value pairs.
5. outputs: a sequence of component names that will be registered as event listeners to this adapter. The outputs normally designate one or more filters, or loggers.

Some of the common properties include:

1. Reader Hostname
2. Reader EPC identifier
3. Log Level


Anatomy of an EPC
EPC can be represented as a URI (Uniform Resource Identifier) to enable the data exchange between software systems. EPC URI are based on the EPC Tag Data Standards defined by EPCglobal. These standards define completely that portion of EPC tag data that is standardized, including how that data is encoded on the EPC tag itself (that is, the EPC Tag Encodings), as well as how it is encoded for use in the information systems layers of the EPC Systems Network (the EPC URI or Uniform Resource Identifier Encodings). The EPC Tag Encodings include a Header field followed by one or more Value Fields. The Header field defines the overall length and format of the Values Fields. The Value Fields contain a unique EPC Identifier and optional Filter Value when the latter is judged to be important to enable effective and efficient reading of the EPC tags.

The EPC encoded in an RFID tag can identify the manufacturer, product, version and serial number, and also provides an extra set of digits to identify unique items.

For various industries, the EPC identifier specifies various coding schemes:

* General Identifier (GID)
* Serialized version of the EAN.UCC Global Trade Item Number (GTIN)
* EAN.UCC Serial Shipping Container Code (SSCC)
* EAN.UCC Global Location Number (GLN)
* EAN.UCC Global Returnable Asset Identifier (GRAI)
* EAN.UCC Global Individual Asset Identifier (GIAI)

Given EPC data, its header field indicates which coding scheme can be applied. The standard URI representation of EPCs has 4 categories:

1. URIs for pure identities (also called canonical forms) which contains only the EPC fields to identify a physical object. For example, a pure identity URI for GID can be "urn:epc:id:gid:10.1002.2" and a URI for GRAI can be "urn:epc:id:grai:0652642.12345.1234."
2. URIs for EPC Tags which represents the tag encodings. These URIs can be used by application software to write a tag. An example for a Serialized GTIN 64-bit encoding is "urn:epc:tag:sgtin-64:3.0652642.800031.400."
3. URIs for Raw Bit Strings which represent invalid bit-level patterns as a single decimal number. For example: "urn:epc:raw:64.20018283527919."
4. URIs for EPC Patterns. Each pattern URI refers to a set a EPCs for the EPC filtering purpose. For example: a pattern "urn:epc:pat:sgtin-64:3.0652642.[1024-2047].*" refers to any SGTIN Identifier 64-bit tag with Filter value as 3, Company Prefix as 0652642, Item Reference in the range from 1024 to 2047 and any Serial Number.

For further details, EPC TagData Standards Specification.

Anatomy of a PML message

The RFID Event Manager loggers output PMLCore XML messages, conformant to version 1.0 of the specification published by the Auto-ID Center. The specifications can be located here. The snippet below is a PML message sent by the Event Manager corresponding to a TagsIn event, ie, when a tagged item comes in view of an antenna. A similar event with a command TagsOut is sent when a tagged item goes out of view of an antenna.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!-- The root element of PML Core -->
<Sensor xmlns="urn:autoid:specification:interchange:PMLCore:xml:schema:1">
<!--The EPC of the reader specified in the RFID Event Manager configuration file for the Reader adapter -->
<ns1:ID xmlns:ns1="urn:autoid:specification:universal:Identifier:xml:schema:1">urn:epc:id:gid:1.1.3</ns1:ID>
<!-- The root element for an observation -->
<Observation>
<ns2:ID xmlns:ns2="urn:autoid:specification:universal:Identifier:xml:schema:1">4</ns2:ID>
<!-- The time when the observation was recorded by the RFID Event Manager -->
<DateTime>2004-05-27T15:36:25.758-07:00</DateTime>
<!--If the PML is generated from a Delta Event, the value of Command is either TagsIn or TagsOut -->
<Command>TagsIn</Command>
<!-- A tag observation -->
<Tag>
<!-- The EPC of the observed tag -->
<ns3:ID xmlns:ns3="urn:autoid:specification:universal:Identifier:xml:schema:1">urn:epc:id:gid:1.1.209</ns3:ID>
</Tag>
</Observation>
</Sensor>

The Sensor element is the main interchange element for PML Core messaging. This element is a composite element comprised of the following subordinate elements:

* ID element
* one or more Observation elements

The Sensor element captures sensor information. A sensor is considered any device that makes measurements and observations. Sensors in the EPC Network are identified by an identifier code. The default identification scheme should be the EPC.

The ID element follows EPC as the default identification scheme to uniquely identify sensors and tags. The use of other identification scheme is supported, but is not encouraged. The EPC is represented as a URI as specified in [EPC] or later versions of this specification.

Each Observation element contains data that are the result of a measurement by a particular sensor. Each observation must be labeled with date and time. It can also be equipped with a unique ID, and a reference to the kind of command that was issued to make the observation. The Observation element consists of the following:

* an optional ID element
* an optional Command element
* DateTime element
* zero or more Data elements
* zero or more Tag elements

The DateTime element captures the date and time when the observation was made. It is based on the [XSD] data type. The Command element can be used to specify the command that was issued to trigger the observation. The Tag element is a special kind of observed value introduced with recognition of the importance of automatic identifications in the EPC network. The tag entity represents any device that can be detected by a sensor. The Tag element consists of the following elements:

* ID element
* optional Data element
* zero or more Sensor elements

All ID elements follow the EPC as the default identification scheme to uniquely identify sensors and tags.

urn:epc:id:gid:1.1.3 is the unique ID of the Reader and Antenna encoded in the GID EPC scheme. A reader can have a unique EPC for each associated antennae, or if the EPC for each antennae is not specified, all antennae will inherit the reader EPC. If the unique EPC for each Reader-antenna is mapped to the location of the antenna, it can be used to track the location of the tagged item as it is scanned by the antenna. urn:epc:id:gid:1.1.209 is the unique EPC number of the tagged item read by the RFID reader represented in GID URI format.

RFID Implementation Hurdles

Theoretically, automating product scanning should make RFID simpler to operate than bar-code technology. However, in many ways, the technology's increased capabilities make it more challenging.

The most basic challenge is managing data. Unlike bar-code technology, where information is scanned only when someone passes a printed label in front of a reader, RF scanning is always on. Consequently, RFID systems must filter data that is constantly streaming in. Additionally, these systems must contend with physical factors that may interfere with RFID's use of radio waves. Warehouses and plants that have electric motors and metal obstructions can have electromagnetic interference. Product materials?liquids or metals?may absorb or reflect RF signals.

As with supply chain integration, RFID technology has the potential to allow suppliers, customers, and other firms in the industry access to critical competitive information. However, with RFID it could be used to gather the information clandestinely because it is so anonymous.

The IDs on passive RFID cards can easily be stolen using a sniffer and a power source without the knowledge or consent of the ID's owner. One major problem with passive RFID systems is that the power source comes from the receiver, not from within the RFID tag itself. This makes the tags cheaper and more robust, but it also makes them vastly less secure. Unless the encryption is very good, the RFID unique identifiers can be duplicated.

Future
To date, only the EPC Tag Data Standards Version 1.1 is finalized. The term Savant is deprecated. Savant standards 1.0 are in the process of being replaced by specifications and standards focused on Event Manager, Reader Management, Reader Protocol, Filtering and Collection, and EPCIS.

References

[XSD] XML Schema Part 2: Datatypes W3C Recommendation, 02 May 2001 http://www.w3.org/TR/xmlschema-2/

[EPC] Michael Mealling and Ken Traub, The URI Representation of the Electronic Product Code and Related Types , Working Draft Version, 12 August 2003 EPC Global http://www.epcglobalinc.com

EPC Tag Data Standards Version 1.1 http://www.epcglobalinc.com/standards_technology/EPCTagDataSpecification11rev124.pdf

PML Core specification 1.0 http://www.epcglobalinc.com/standards_technology/Secure/v1.0/PML_Core_Specification_v1.0.pdf

Auto-ID Savant Specification 1.0 http://www.epcglobalinc.com/standards_technology/specifications.html

Auto-ID Reader Protocol Specification 1.0 http://www.epcglobalinc.com/standards_technology/specifications.html

Sun Java System RFID Software Product Documentation http://docs.sun.com/db/coll/RFID_04q3

EPC and RFID: Enabling the Next Level of Business Efficiencies http://wwws.sun.com/software/solutions/rfid/index.html

The Sun RFID Test Center http://wwws.sun.com/software/solutions/rfid/testcenter/index.html

The Sun" EPC Network Architecture http://wwws.sun.com/software/solutions/rfid/EPCNetArch_wp021304a.pdf

The RFID Journal http://www.rfidjournal.com/

Acknowledgements
The author would like to thank Ricardo Labiaga of the RFID engineering team at Sun for his input, help and guidance in writing this paper.

About the Authors

Alka Gupta is a member of the Technical Staff at Sun Microsystems. She's responsible for working with Sun's ISV's and partners to help them adopt the emerging Sun technologies and platforms quickly and efficiently. Alka has been in this industry for nearly 10 years. Alka graduated from the Indian Institute of Technology (IIT), India.

Mayank Srivastava is a Software Engineering Manager in Market Development Engineering, at Sun Microsystems. In this capacity, Mayank's group responsibilities include providing help to ISVs to adopt Sun's technology and systems.