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.