Developing Auto-ID Solutions using Sun Java System RFID Software

Radio Frequency Identification or RFID is a method of identifying unique items using radio waves. RFID technology has emerged in response to the need for a next generation bar code. In the simplest terms, an RFID system consists of a tag (transponder) and a reader (interrogator). The technology of RFID deals with the remote collection of information stored on a tag using radio frequency communications. Information stored on the tag can range from as little as an identification number, to kilobytes of data written to and read from the tag, to dynamic information maintained on the tag, such as temperature histories.

Automatic Identification or Auto-ID is a broad term that covers methods of collecting data and entering it directly into computer systems without human involvement. Technologies traditionally considered part of Auto-ID include bar codes, biometrics, RFID, and voice recognition.

Auto-ID technology provides the means to track any object, anytime, anywhere. The Auto-ID system is based upon the use of low-cost smart tags and readers, and unique object-identification schemes. Auto-ID is achieved by replacing today's UPC barcode labels with inexpensive RFID tags based on tiny slivers of silicon which can be embedded into product packaging, or better yet, into products themselves, although Bar Codes will not go away any time soon. There are many applications where RFID adds complexity and cost, and bar codes are perfectly fine. One will see bar codes and RFID tags used hand-in-hand for many years to come.

An Auto-ID Network comprises various trading partners using the Auto-ID system for tracking and tracing items automatically throughout the supply chain. This provides businesses with an unprecedented real-time view of their assets and inventories anywhere, thereby enabling significant gains to operational efficiencies and brand protection efforts. The Auto-ID Network supplies benefits beyond operational efficiencies by enabling safe and secure supply chains with applications that address counterfeiting, tampering, terrorism, and regulatory compliance, among others.

The EPCglobal is a spin-off of the Auto-ID Center. It is a standards body chartered with defining the standards for EPC technology for global adoption of EPCglobal Network. The EPCglobal Network is a set of technologies that enable immediate, automatic identification and sharing of information on items in the supply chain. The EPCglobal Network uses radio frequency identification (RFID) technology to enable true visibility of information about items in the supply chain. The network is comprised of five fundamental elements:

Electronic Product Code (EPC)
ID System (EPC Tags and Readers)
EPC Middleware
Object Name Service (ONS)
Physical Markup Language

Electronic Product Code (EPC) Numbering System: Like the Universal Product Code (UPC) or bar code, the Electronic Product Code(EPC) is the fundamental identifier for a physical object in a EPC Network. The EPC identifies the manufacturer, product, version and serial number, and uses an extra set of digits to identify unique items. The EPC Tag Data Standards Specification Version 1.1 defines the encoding of the Electronic Product Code onto the RFID chip, as well as how it is encoded for use in the information systems layer of the EPC Network (for example the RFID Information Server).

EPC Tags, Readers and Interface Protocols: EPC Tags consist of a microchip attached to an antenna. The EPC is stored on this tag, which is applied to an item during the manufacturing process. EPC Tags communicate their EPCs to EPC Readers using Radio Frequency Identification (RFID). EPC Readers communicate with EPC Tags through radio waves and deliver information to local business information systems using EPC Middleware. There is an Auto-ID Reader Protocol Specification 1.0 in the works which defines a standard protocol by which Readers communicate with EPC Middleware. The Reader Management Specification extends the Reader Protocol Specification, defining a standard for managing RFID readers in a large network.

Tags can be classified as Passive, Active and Semi-passive. Passive tags do not have batteries, and simply "reflect" the communication when prompted. On the other hand, active tags have batteries and initiate the communication. Semi-passive tags have a battery but also "reflect" the communication; it does not, however, initiate the communication. One can think of passive and semi-passive tags as mirrors that transmit information (light) when they have light shine upon them. Today, the EPCglobal Network has been focusing on standards for passive tags. One can expect to see an EPCNetwork standard coming up that addresses Active Tags.

EPC Middleware: The EPC Middleware has also been called Savant in the past. It is a standard for Real-time Event Management, EPC Data Filtering and Collection. It is being covered by an emerging EPCglobal specification, currently referred to as Filtering and Collection Specification.

EPC Information Services: EPC Information Services enable users to exchange data with trading partners based on EPCs.

Object Name Service (ONS): Gives you the ability to locate a server that contains more information about the particular EPC anywhere in the world. Business information systems need a way of matching the EPC to information about the associated item. The ONS is an automated networking service that provides this service by pointing computers to sites on the World Wide Web. It provides standards for specifying the Internet addresses where product attributes and related information are maintained.

Physical Markup Language (PML): Is used as a common language in the EPCglobal Network to define data on physical objects. The goal of the PML is to provide a collection of common, standardized vocabularies to represent and distribute information related to EPC Network enabled objects. The PML Core Specifications 1.0 define the PML standards.

The Sun Java System RFID Software is Sun's unique RFID middleware platform offering that is based on widely accepted industry standards including those defined by EPCglobal. It provides the foundation for deploying the EPC Network for a company. It is designed specifically to provide high levels of reliability and scalability for a EPC Network while also simplifying the task of integrating with multiple existing back-end enterprise systems.

The Sun Java System RFID Software is responsible for the communication and processing of EPC data and events between EPC readers and tags, and the back-end supply chain systems such as ERP. The RFID Software contains two primary components: 1) RFID Event Manager and 2) RFID Information Server. Both are available for download. These two components are built on top of Jini 2.0, Rio 3.0.1, the Java Web Services Developer Pack 1.3, and the Sun Java System Application Server 7.

The RFID Event Manager communicates with EPC tag readers to process large amounts of EPC data coming into the system. The Event Managers also communicate with back-end systems and the RFID Information Server to log EPC data and events. The RFID Event Manager is a Jini-based event management system. It facilitates the capture, filtering and eventual storage of Electronic Product Code (EPC) events generated by RFID readers connected to the network. Its main goal is to interface with RFID readers, gather EPC events, filter redundant information, and feed relevant events to the RFID Information Server or other ERP software for further processing. The RFID Event Manager Jini services are managed through Rio, an open source container of Jini Service Beans.
The RFID Information Server is responsible for storing and aggregating associated business data around a given EPC event. The RFID Information Server is a J2EE application that serves as an interface for capture and query of EPC-related data. EPC-related data can include tag observation data from Event Managers as well as information that maps EPCs to higher level business data. The RFID Information Server is typically used to translate a set of low-level observations into higher-level business functions. The RFID Information Server runs on the Sun Java System Application Server 7. Other applications interface with IS through XML message exchange. The IS supports HTTP and JMS message transports. The IS persists all data in a relational database.

These two components play key roles in the EPC Network defined by EPCglobal.

The Sun Java System RFID Event Manager gathers information from the RFID Readers, filters the information, and provides the massaged information to either the RFID Information Server or a 3rd party ERP system.

Figure 1 depicts how the RFID Event Manager and RFID Information Server fit into the EPC Global network.

EPC Network

Figure 1: Sun Java System RFID software and the EPCglobal Network

The RFID Event Manager consists of a Control Station and one or more Execution agents as depicted in Figure 2.

EPC Event

Figure 2: Sun Java System RFID Event Manager Architecture

A computer system can run one or more execution agents and each execution agent can carry out one or more workloads. Each execution agent registers at startup with the control station.

The Control Station keeps a registry of available Execution Agents, monitors their status, assigns workload and helps them carry out the workload.

An Execution Agent consists of an Adapter, Logger and Filter components. Each Execution Agent can be composed of a combination of adapters feeding information into one or multiple filters or loggers, and each filter feeding information into one or multiple loggers. The adapter is a piece of Java code that interfaces to the actual RFID Reader device. The Sun Java System RFID Event Manager comes packaged with a predefined number of adapters that understand the specific communication protocol used by the leading EPC-compliant RFID readers. These reader adapters can be viewed as equivalent to device drivers used to communicate with peripherals in a computer system. At this time, there is no standard communication protocol that can be used by RFID readers to communicate with software that consumes their RFID events. The RFID Reader is a separate piece of (typically) hardware that communicates with the RFID tags over Radio Frequency. The adapter obtains the EPC of the RFID tag, and generates an event that includes a timestamp and the source of the event (the reader and/or antenna that discovered the tag). The event is posted to a set of listeners which then process the event. The listeners are filters or loggers. Filters can smooth the data, throw away previously detected information, or route information to other filters and loggers. The filtered data is posted as an event to interested listeners. The listeners can be other filters that will further massage the data, or loggers that serve as connectors to 3rd party applications that consume the RFID information.

The two tables below list the supported filters and loggers and their main functionality.

Table:1 Filters implemented by the Sun Java System RFID Event Manager

Filter Type	Description
BandPass	BandPass Performs a pass filter on Reader EPC's, events from readers that match the EPC Mask are passed on to listeners, while others are not.
Delta	Delta Reports tags leaving and entering the field of view
EPCFilter	EPCFilter Performs a pass filter on tag EPC's, epcs that match the EPC Mask are passed on to listeners, while others are not.
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 implemented by the Sun Java System RFID Event Manager

Name	Description
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 <output> 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:

name: The unique name for the component.
classname: The name of the Java class that implements the component.
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.
properties: A sequence of name value pairs.
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:

Reader Hostname
Reader EPC identifier
Log Level

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:

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."
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."
URIs for Raw Bit Strings which represent invalid bit-level patterns as a single decimal number. For example: "urn:epc:raw:64.20018283527919."
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.

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"?> 
<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>
    
    <Observation>
        <ns2:ID xmlns:ns2="urn:autoid:specification:universal:Identifier:xml:schema:1">4</ns2:ID>
        
         <DateTime>2004-05-27T15:36:25.758-07:00</DateTime>
        
        <Command>TagsIn</Command>
        
        <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.

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.

SDN Home > Products & Technologies > Java Technology > Reference > Technical Articles and Tips > Developer Technical Articles & Tips > Electronic Commerce >