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):

   0011000001110000000000000100100001000100000001100   110010000000000000101110000110000101010100100011

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:

   urn:epc:tag:sgtin-96:3.0037000.06542.773346595

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 of 0037000 (Proctor & Gamble), an Item Reference of 06542 (Bounty ® Paper Towels 15 Pack) and a Serial Number of 773346595, 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 specifications?often for multiple tag formats?within 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.

Custom Tag Data Requires Flexible Decoding
The examples above for supply chain and animal tracking showcased two different tag standards, emphasizing the need for low-level data decoding. One commonality between the two examples is that they both involved decoding of known data with standardized data encodings, so that a company or software provider could build a decoding engine to recognize the tag and expose the various fields. Unfortunately, this model of supporting only known data formats falls apart when new standards are introduced, or new uses arise for existing standards that allow companies to write custom data directly onto an RFID tag.

Increasingly, RFID applications are seeking to incorporate custom data directly onto RFID tags, eliminating the need to use the RFID tag value simply as a unique identifier to look up additional information in a backend system or database. For example, a company might want to store data such as an expiration date, original manufacturer, last maintenance check, or other relevant data about an asset directly on its RFID tag so that this valuable information is always available. In addition, many systems are looking to encrypt this custom data, or employ other techniques such as bit-shifting to protect the custom data.

Custom data is often a requirement for closed-loop RFID systems. In closed-loop systems, companies can use whatever tag type and whatever data format they want. Because the same system both creates and consumes the tag data, compatibility with other companies or systems is not necessary.

The ability to support custom data is also a requirement for open systems with standardization, as is the case with new standards being developed for specific applications or industries. These standards often leverage existing ISO tag specifications, but take advantage of the ability to write custom data to part of the tag. An industry can then standardize on what and how to write to this custom data field. But despite the eventual standardization, decoding logic must still be written to convert the raw data into the business-specific fields for processing.

EPC generation 2 (Gen 2) and ISO specifications both support writing custom data to RFID tags. Because, by definition, custom data is not standardized, any encoding or decoding software must be flexible, and not simply provide support for the encoding and decoding of the existing standard tag formats. This highlights the need for a flexible architecture for encoding and decoding RFID tags. The architecture needs to be able to handle the demands of organizations and industries looking to take full advantage of the data storage flexibility provided by RFID hardware and tags.

On way to allow organizations to work with current, future, and custom tag data formats is to turn to third-party vendors. For example, the RFID Anywhere platform from Sybase iAnywhere includes a flexible encoding/decoding system built around Data Protocol Processors (DPPs), which automatically encode and decode today’s most common standard tag formats, but provides an extensible interface to support custom data, giving organizations flexibility in tag and protocol selection. The system can also incorporate any custom tag data format required by an application, including encrypted tag data. Also, because developers can easily create DPPs and integrated directly into the RFID Anywhere platform, organizations can be assured of a flexible, future-proof platform without costly platform extensions or consultant fees.

Figure 2. Flexible Data Encoding: The figure shows two potential choices for formatting custom tag data enabled by DPPs.

The need for such an architecture can be illustrated with a simple internal IT asset tracking RFID application. Because a system such as this is a closed-loop system, the company can choose the tag that best suits their environment, for example, ISO 18000-6B tags, and can encode any data they want on the tag. In this example, the company wants to store an asset ID, the name of the department that owns the asset (DN), the employee number of the employee who is responsible for the asset (EN) and whether or not the asset is company-owned (CO).

Using a flexible encoding and decoding architecture, the company has the ability to design the custom data portion of the ISO 18000-6B tag to hold whatever data they want, as long as the methods to encode and decode, created in the DPP, match up. For example, the company could store the department number in the first three bytes, followed immediately by the two bytes for employee number, then one byte for the company-owned flag. Alternatively, they could mix these fields around, use bit shifting to rearrange the data, or even encrypt the data on the tag if they so desired. Figure 2 shows several possible data arrangements.

After the company determines the encoding scheme, developers build a DPP to read tags encoded and affixed to the assets. As these tags are read by RFID hardware and integrated into the RFID Anywhere system, the DPP automatically handles the custom decoding operations and exposes the decoded tag data to business logic. In this manner, application developers always working with pre-decoded data and do not need to be concerned with decoding within their applications.

Avoiding Data Overload
In addition to understanding what raw RFID tag data looks like, it is important to understand the truth behind the common concern of RFID data overload and how it can easily be avoided. Many people believe that large RFID systems with hundreds of thousands of tags, and potentially hundreds of readers sending the raw data from these tags into a system can easily become overloaded. The truth is that only a very small percentage of this raw data can be classified as useful. The real goal for avoiding data overload lies in eliminating useless data, sending only valuable information further into the system. Techniques to reduce data volumes include smoothing, filtering, or simply distributing the data load over a number of locations through local processing at the edge of the network

As a data overload example, suppose a warehouse is looking to have a near real-time view of changing inventory levels. To do this, assume the warehouse holds 10,000 items tagged with 96-bit RFID tags. Readers take inventory every two minutes. Further, assume that 1,000 items are removed from the warehouse every day, while 1,000 new items are added. In this scenario, approximately 117 kilobytes (10,000 x 96 bits) of data gets generated every two minutes, which is about 3.5 megabytes (30 x 117 kilobytes) of data every hour, or about 85 megabytes (24 x 3.5 megabytes) per day. But because the only data the company is concerned is changes in inventory, only 192,000 bits ((the 1,000 added +1,000 removed) x 96 bits) is valuable, equaling less than 1 percent of the data potentially generated by the system.

Smoothing and filtering are two very effective ways of eliminating useless data before it propagates into enterprise systems and applications. Smoothing is the ability to ignore temporary data inconsistencies to avoid generating meaningless events. For example, if a reader reads a specific RFID tag, then the tag isn’t read during a 5 second span only to re-appear thereafter, was that tag ever really gone, or did some external interference simply get in the way? RFID system designers must balance the system’s tolerance for temporary data inconsistencies by ignoring useless data and events while still maintaining system performance.

Filtering is the process of reporting only on tags that match a certain criteria. For example, a simple filter might only generate activity reports for RFID-tagged pallets that enter a warehouse, and might discard any item- or case-level tags picked up by the RFID readers. So, although you may often hear about RFID systems generating and collecting massive amounts of data, only a very small amount of that data needs to be propagated into enterprise systems if smoothing and filtering are used correctly.

The location in the network where filtering or smoothing occurs can greatly impact the effectiveness of a filtering or smoothing implementation, as well as the overall flexibility of a system. If the filtering occurs at the RFID reader level, such as by ignoring all except pallet-level reporting, the RFID system will be difficult to modify if the company decides to use case or item tracking in the future.

Another problem is that you can dramatically increase the ROI of an RFID system if multiple applications share the RFID data. Each application may potentially care about different items than the other applications. Thus, if the data for some items gets discarded at the reader level, new applications will not be able to get access to it.

A second option could be to perform smoothing and filtering far away from the reader?at the enterprise layer. However, filtering or smoothing at the enterprise or at some central location wastes all the bandwidth involved in moving useless data through the network, only to have it discarded. Another option is to put the filtering and smoothing logic for an application right into the application code. This seems like a reasonable idea, until you consider the task of building and maintaining a filtering and smoothing engine in your application code; not a recommended approach for any application design team.

A better solution is to perform filtering and smoothing operations at the RFID middleware layer. Some RFID middleware platforms contain filtering and smoothing capabilities, discarding useless data at the edge of the network so that application developers work only with important events or processed reports. This ability to perform filtering, smoothing and other logic at the edge of the network is often referred to as edge processing.

Edge Processing to Expose Valuable Information
One common method of exposing valuable RFID information to enterprise applications is through Application-Level Events (ALE). The ALE specification, published by EPCGlobal Inc., provides a standards-based method for applications to request and receive tag data for EPC tags. ALE implementations provide the ability to filter and consolidate data from multiple sources, and then expose the data in the form of periodic, XML-based event cycle reports. These reports summarize the tag activity during the event cycle, and often have configurable options for duration, along with filtering and grouping based on the fields of a URI representation. Because these reports contain only the URI or raw HEX representation of each tag, it is up to the application that receives the report to process the XML document and add the business context. For example, an application might be responsible for mapping a company prefix to the actual company name for display or storage.

It is important to note that ALE by itself is not business logic. ALE processing is largely infrastructural, in that it only reports the specific details of data gathering. No business semantics are expressed in event cycle reports; only the consumers of ALE reports truly implement the business logic of an application. As an example, an ALE event cycle report might contain the information that at Location L, within the time interval Time1-Time2, 100 case-level EPC tags, and 1 pallet-level EPC tag were read. A business application would be required to express the business-level semantics of this report: at Location L, at time Time2, 100 cases were loaded onto a specific pallet.

Although the ALE standard has been ratified and incorporated into a number of applications and RFID middleware offerings, it has some limitations that make it unsuitable for a variety of RFID implementations. These limitations include:

• ALE reports expose the URI representation of EPC tags; therefore application developers must understand how to decode each URI to extract the meaningful fields. For example, if an application receives an ALE report with the URI representation urn:epc:tag:sgtin-96:3.0037000.06542.773346595, it would need to know that the representation stores the Company Prefix between the first two periods after the last colon. This logic must be implemented by the application because the ALE event cycle report does not provide direct mapping between field names and values.
• ALE uses pattern matching against the URI representation for filtering and grouping, meaning that the person configuring reports needs to know the format of the URI representation.
• The current ALE standard does not provide the flexibility to report on custom data potentially stored in EPC generation 2 tags, meaning that an application processing the report must manually decode the custom data field?and also that you can’t perform filtering or grouping on specific sections of the custom data field.
• Most importantly, the ALE specification only reports on EPC tags, so systems that use ISO tags cannot leverage the ALE specification.

Additional Options for Edge Processing
Thankfully, there are options for processing tag data at the edge of the networkthat offer ALE-style XML reports as well as a variety of improvements, including multi-protocol support for both EPC and ISO tags, and the ability to combine data from ISO and EPC tags into one report. These reports use DPPs to report more than just a raw or URI representation, and support separate XML elements in each tag that let developers access specific fields without needing to know how to decode a specific representation (see Figure 3). Sybase’s Report Engine MP creates filtering and grouping sets using SQL statements instead of pattern matching, eliminating the need to understand each representation, and includes scheduling support, allowing administrators to easily define periodic reports.

Sybase’s edge processing options also include custom business modules, where developers can focus on creating business logic, writing code to handle events?usually the appearance or disappearance of a tag.

Figure 3. Sample ALE Report Output: Here’s a section of a report file sample output from a report generated by Sybase’s Report Engine MP.

Figure 4. Sample Business Module: The figure shows a portion of the .NET C# code in a sample business module that handles tag events.

Business modules (see Figure 4) are extremely flexible and can perform a variety of tasks required by the system, including using a DPP to decode a tag, looking up information in a database to help make a decision on what to do with the tag data, or generate and send output in any format to an enterprise system.

So, you’ve seen a number of important items to consider when designing an RFID system. First, you’ll want a way to access raw tag data for processing easily, without having to write repetitive low-level code. Choose an architecture that provides out-of-the-box convenience, supporting both today’s common tags and standard formats as well as the power and flexibility to support the custom data capabilities of ISO and EPC Gen2 tags. Second, the ALE specification implemented by a number of RFID middleware vendors defines a reporting system to smooth, filter, and group data to reduce or eliminate meaningless RFID data before it gets propagated up the network into the enterprise. In addition, look for products that provide a framework to build or configure edge processing components in the form of ALE or multiprotocol reports, and support building custom business modules. These components provide the ideal platform on which to build a variety of RFID solutions that enable an organization to focus on their business, without worrying about the complexities of RFID today.