Everyone knows that RFID is the greatest thing since sliced bread, right? It's perfectly foolproof and will revolutionize the way you do business. Okay, that was just a bit of a reality check. RFID isn't foolproof. Nothing is.
The reality is that for the near term, "dead" tags will be a fact of life. Part of the reason for this is that we're still seeing early production runs of some EPC-style tags and the kinks are still being worked out of the production process. Quality has improved dramatically over the past year but the failure rate is still high compared to bar code printing.
Even when we see full-scale production of Gen2 tags (which will increase quality to a much more acceptable level), transportation, handling and routine wear-and-tear will result in damage to tags—just as they do to bar codes.
And, just as bar codes have a human readable interpretation (HRI) to allow key entry in the event a symbol is unreadable, RFID tags will need some form of backup in the event of damage.
The big difference between RFID and bar codes is that, at least in the EPC world, data is binary. So, should we provide an HRI for EPC and other RFID tags?
The answer is an emphatic, "Yes and no." Think about it. The EPC Serialized Global Trade Item Number (SGTIN) code is a string of 96 ones and zeros. For example (broken into 4 digit units for ease of recognition): 0011 0000 0111 0100 0010 0101 0111 1011 1111 0100 0110 0010 0101 1111 1000 0000 0000 0000 1000 0010 0100 0110 0000 0100. Key entering 96 bits from an EPC tag isn't anyone's idea of a good time, or a good idea.
AIM Global's RFID Experts Group (REG) is finalizing recommendations for bar code backup along with an HRI—but neither would be pure binary. Current thinking for the bar code is to use a UCC/EAN-128 symbol with the appropriate Application Identifier (AI), once assigned. Data would be converted to octal (digits 0-7) for encodation and also for the HRI.
Why octal? Because it's extremely efficient for encoding long binary strings in UCC/EAN-128. It also makes key entry a bit easier than a hexadecimal code, particularly on handheld terminals where entering letters may require shifts, double-shifts or multiple key presses (as when text messaging from a 12-key keypad on a cell phone).
What would the HRI for the data string above look like in octal or hex? In the following example, (9999) represents a yet-tobeassigned AI and the data is represented according to current recommendations from the REG. (The actual AI would have to be assigned a value of 7777 or less to fit within the octal scheme.)
Octal: (9999) 0021 3741 0140 1407 2045 3677 2142 2770 0000 4044 3004
Hex: (9999) 0B2F C230 3074 257B F462 5F80 0082 4604
As you can see, hex is 12 characters shorter than octal but might be much harder to key enter unless you're using a full keypad.
Octal also enables a significantly smaller bar code symbol since an all-numeric string can be encoded in Code Set C (doubledensity numeric) in UCC/EAN-128. Code Set C encodes two digits in a single bar code character. Similarly efficient numeric compaction is also available with RSS/Composite and Data Matrix, both of which might be used as "bar code" backup symbologies. This compaction is beneficial because, even with an ßß-dimension of 0.010 inches (10 mils), a UCC/EAN-128 symbol, with quiet zone, is nearly four inches wide—the width of the most commonly used label stock.
The REG is also making recommendations for bar code and HRI backup in non-EPC applications. Insofar as these applications will likely use standard ASCII for data, the HRI and bar code data would also be ASCII.
The question for non-EPC applications is one of symbology. It is most likely that a 2D symbol such as Data Matrix or PDF417 would be necessary (the U.S. Department of Defense is currently using PDF417 for this purpose).
This is only one of the topics the REG is addressing in developing guidance on implementing RFID. Contact me if you're interested in learning what else the REG is doing.
Bert Moore
[email protected]
