hen designing an RFID system, you should first understand and consider two key aspects of turning RFID data into useful information. First, you need a way to convert the raw incoming RFID data into a meaningful context for further processing and subsequent actions. Because today's marketplace provides an abundance of RFID tag choices, data encoding formats, and custom data options, you'll need a powerful and flexible encoding and decoding architecture to support applications now and into the future.
Second, while it might be relatively easy to build an RFID data acquisition and analysis system for the number of tags your business uses today, you have to consider the future. The system must be able to avoid data overload when your system collects data from hundreds of thousands of RFID tags. Filtering and smoothing are important concepts to understand; early in the design process you need to identify architectures that provides flexibility in processing data at the point of activity.
Decoding Raw RFID Tag Data
Any discussion about making RFID data usable must begin with a discussion about how raw RFID tag data actually looks as it comes into your enterprise from RFID readers.
RFID tags used in the supply chain are encoded with an Electronic Product Code, or EPC, which is a globally-unique identifier for the object being tagged. There are a number of different encoding formats; which one a particular tag uses depends on the tagged item. These formats can be specific to groups of goods, such as shipping containers, or can be specific to each individual asset type. To ensure that each EPC is unique, EPCglobal (the organization driving standards for EPC) assigns each company a unique manager number. Each company is then responsible for assigning the other fields required by the encoding format being used.
RFID readers typically return the raw HEX or binary representation of an EPC, values which must then be decoded using bit-level programming to derive a useful representation of the information that a tag holds. As an example, an RFID reader may read and output a HEX value of 30700048440663802E185523
. This value must be converted to binary, then decoded programmatically according to the EPC specification to extract the decimal field values, and finally, formatted to return a meaningful representation of the EPC called the Uniform Resource Identifier (URI) representation.
The binary representation of the tag HEX value shown above is (note that the two lines below represent a single value):
The EPC tag specification outlines the decoding process, which you can follow by interpreting the binary string bit by bit to get a more useful representation.
After decoding the binary value, the URI representation of the tag above is:
That value must be processed further to determine the item it actually represents. The URI representation is often used for reporting, as it is easier for programs or individuals to extract meaningful information about the tagged item from that representation than from HEX or binary values, by filtering or grouping on the various fields.
The tag in this example is a 96-bit EPC value encoded using the Serial Global Trade Identifier Number (SGTIN-96) format, as indicated by the sgtin-96
field in the URI representation or the eight-bit constant at the start of the binary representation. The SGTIN-96 tag data specification requires six fields to be set for each tag; the combination of all six fields ensures each tag's uniqueness. These six fields are:
|Figure 1. Decoding an EPC SGTIN-96 Tag: Here's a humanly-readable version of the fields contained in this tag type, showing how an application can convert raw HEX values to meaningful data fields.|
- Header, which is 8 bits and is common for all SGTIN-96 tags
- Filter, which is three bits and specifies if the tagged object is an item, case or pallet
- Partition, which is three bits and indicates how the subsequent fields are divided to get the correct data for each
- Company Prefix, which is 20-40 bits (depending on the Partition) and contains the company's EAN.UCC Company Prefix
- Item Reference, which is 24-4 bits (depending on the Partition) and contains the item's GTIN item reference number
- Serial Number, which is 38 bits and contains the item's unique serial number
In the tag example used here, the URI representation urn:epc:tag:sgtin-96:3.0037000.06542.773346595
indicates that the tag is an SGTIN-96 tag that has a Filter
value of 3
(meaning that it is tracking a shipping unit), a Company Prefix
(Proctor & Gamble), an Item Reference
(Bounty ® Paper Towels 15 Pack) and a Serial Number
, which uniquely differentiates that item from others of the same type. Figure 1
shows the breakdown of the tag fields.
The International Standards Organization (ISO) defines a number of other RFID tag standards governing the data stored on RFID tags. A number of these standards, such as ISO 15693, specify how
data should be stored on a tag, but provide flexibility as to what that data can represent. In these cases, the custom data field of a tag can contain any data the company wishes to store on the tag in whatever format the company wants.
Other ISO standards exist for tags used in specific industries; these govern what data should be stored on a tag. For example, the ISO 11784 standard specifies that the data on a 64-bit RFID tag used for electronic animal identification must store three fields: a control field of 16 bits indicating animal or non-animal application, a country code field of 10 bits, and a national identification code of 38 bits. This standard also reserves a number of bits for future use.
Whether you are using EPC or ISO tags, decoding tag data requires detailed, bit-level programming to convert the raw tag data from binary or HEX into business information. In an RFID system that tracks both ISO tags and EPC tags of varying encoding formats, tag decoding tasks can involve significant research and low-level programming resources. To accomplish this task correctly, developers must work with fairly complex specificationsoften for multiple tag formatswithin their application, all of which can add up to a significant amount of new code. Thus, the decoding efforts involved in building a flexible RFID system can be reduced by adopting an RFID middleware platform to perform the decoding tasks automatically, exposing decoded, meaningful data to applications and business logic through easy-to-use interfaces and development options.
|Editor's Note: The author, Matt Teskey, is a Product Manager at Sybase iAnywhere, a vendor of RFID products. We have selected this article for publication because we believe it to have objective technical merit.