There is much debate
over the benefits of
RFID
technology versus
Bar Code technology.
The AIDC 100 held a
forum on October 20,
2004 called "Truth
in Technologies
2004: RFID & Bar
Codes", that
addressed this
subject in detail.
The Forum was a
tremendous success
and spurred many
thoughts, comments,
and opinions
subsequent to the
event. Comments
prior to and
subsequent to the
forum are listed
below.
Click here
if you would like to
see the
presentations given
at the Forum.
The
following expressed
comments and
OPINIONS are
those of various
AIDC 100 members and
do not necessarily
reflect the position
of the AIDC 100. We
encourage anyone
interested in the
subject to send
their opinion to
Dick Meyers
(dickmeyers@mindspring.com)
for posting on the
site.
For more information
and the
qualifications of
our members, go to
http://aidc100.org/ and
click on the list of
AIDC 100 Members
then select the
appropriate person.
February 17, 2006
RFID or Barcode
Chris Kapsambelis
RFID and Barcode are
becoming
interchangeable.
Recently, I read an
article in RFID
Journal titled “Wal-Mart
Explores New RFID
Form Factors”1.
The article stated
that Wal-Mart was
rolling out handheld
RFID interrogators,
mobile computers
that can read RFID
tags, forklift
mounted RFID
readers, and even
RFID readers that an
employee might wear.
The article also
mentioned that these
new devices can read
Barcode. All of
these rollouts are
aimed at helping
Wal-Mart with
inventory control.
In addition to
reading RFID tags on
pallets and cases,
these devices can
also be used to read
shelf tags or
location tags,
presumably to record
Put-away, and
Picking
transactions.
What struck me about
the article was the
fact that all these
devices are operated
manually and require
a human interface in
order to function.
In recalling the “Technology
Guide”2,
published by the
Auto-ID Center at
MIT around the year
2003, and currently
located in the
archives of
www.EPCGlobalInc.org,3
the emphasis for
selecting RFID was
its superior
capability for
Automatic Data
Capture. The fact
that RFID required
no “Line of Sight”,
and the ability to
simultaneously read
large groups of
tags, would lead to
a global network of
stationary readers,
that would
automatically read
items, and track
them within the
Supply Chain, in
what was described
as a Network of
Things.
The higher cost of
RFID was to be
justified by the
increase in
productivity that
would result from
saving the labor
needed in manually
scanning bar codes,
and the reduction in
operating costs due
to the higher level
of accuracy that
only full automation
can provide. Manual
scanning would
disappear, RFID
equipped portals
would automatically
read pallet loads of
cases leaving a
factory, and similar
portal readers would
receive them when
they arrived at
destination. Within
a given facility,
storage bays
equipped with
readers were to take
instant and
continuous inventory
of every thing in
the warehouse.
Similarly, shelf
readers were to
perform the same
function for the
sales floor. With
this system in
place, near-perfect
supply chain
visibility was
assured, and this
would result in
unprecedented levels
of productivity
throughout the
Supply Chain.
Today, the
Department of
Defense (DoD) has
concluded that human
intervention is
required to be sure
that RFID readings
are complete. See
article “No
Silver Bullets”4.
Wal-Mart is moving
from portal, and
shelf interrogators
to dual capability
manual readers. The
concept of
hands-free, full
automation is being
abandoned in the
interest of
economics. Manual
interrogators can
fulfill multiple
roles. At one time
they can be used to
capture Receiving
Transactions, while
at another time, the
same hardware can be
used to capture
Shipping
Transactions.
Similarly, a much
smaller set of RFID
hardware can be
utilized to capture
all the data needed
for the operation of
the Supply Chain.
The concept of full
automation with RFID
is moving in the
direction of
manually reading
items one at a time
very similar to what
is done with
Barcode. See article
“Six
Sigma and the Single
Tag”5
Currently, the EPC
data on each tag is
also printed in
barcode using the
GTIN, SSCC, and
other standards. The
Association for
Automatic
Identification and
Mobility (AIM)'s
RFID Experts Group (REG)
and Technical
Symbology Committee
(TSC) have been
working on
recommendations to
use barcode as
backup in the event
of tag failure. AIM
announced recently,
that the
recommendations have
been forwarded to
EPCglobal's Tag Data
Standards (TDS)
group for final
review and
publication. The
final specification
is due to be
released within the
next two months.
When this is done,
every RFID tag will
also have a barcode
symbol.
While DoD, Wal-Mart
and others will
undoubtedly demand
their suppliers
continue to tag
pallets and cases
with RFID, It
appears that most
users will have a
choice as to which
technology to use
for Data Collection.
Since items in the
Supply Chain are
being labeled with
RFID, Barcode, or
both, a user will be
able to choose which
manual data
collection
technology is more
suitable. In the
end, the choice
between RFID and
Barcode will be
selected by popular
demand.
References:
-
http://www.rfidjournal.com/article/articleview/2105/1/9/
-
http://archive.epcglobalinc.org/new_media/brochures/Technology_Guide.pdf
-
http://www.epcglobalinc.org/
-
http://www.fcw.com/article88738-05-02-05-Print
-
http://www.rfidjournal.com/article/articleview/2102/1/2/
October 28, 2004
New EPC Symbol
Chris Kapsambelis
First, let me thank
everyone who has
responded positively
for the need for an
EPCSymbol designed
to back-up RFID, and
act as an
alternative method
for retrieving the
EPC Number.
In an effort to
focus the discussion
I would like to make
the following
points:
-
The EPC number
is part of a
concept to
provide unique
identification
for every item
used in the
transportation
of goods in the
Supply Chain.
-
RFID was chosen
because it was
believed to have
properties,
unlike barcode,
that will permit
the complete
automation of
the process by
not requiring
manual scanning
for data
capture.
-
On July 30, 2004
I wrote on this
BLOG that the
current form of
passive RFID had
properties that
were the same as
barcode, and
therefore would
be no better in
reading pallet
loads of cases.
-
0n October 29,
2004, at the
"Truth in
Technologies
2004: RFID & Bar
Codes"
forum,
it was verified
by a number of
speakers that
the read rate at
RFID equipped
portals, where
pallets are
being received,
varies from 50%
to 80%, and the
emphasis will be
on the
acquisition of
accurate ASNs to
make up for the
shortcomings of
RFID.
In the spirit of
retaining the
emphasis on
automation that RFID
and EPC promise, The
EPCSymbol should be
designed for high
speed fixed position
scanning. That means
an X dimension of
about 20 mils and an
aspect ratio of at
least 2:1.
Everything that
Sprague Ackley says
in his analysis of
my code that was
submitted as an
EPCSymbol is true.
However, not
necessarily
relevant. In an
effort to reduce the
code to its smallest
possible size, I
chose to forgo the
use of the super
redundancy included
in Code128 and
others. Instead I
am relying on the
fact that the symbol
will be printed on a
white label with
thermal transfer
printers resulting
in an ANSI Grade of
A.. Given that the
symbol will be fixed
length and scanned
exclusively by laser
scanners in motion,
I believe that 100%
accuracy can be
guaranteed by
depending on the
scanner to provide
the needed
redundancy through
multiple scan
comparisons. The
super redundancy
came into use as a
result of poor
printing with early
dot-matrix printers
using faded ink
ribbons, and
printing directly on
Kraft paper cartons.
Given today's
printing
technology super
redundancy is
probably
unnecessary.
I realize that this
is a controversial
point of view, and
that the only way to
prove the point is
with extensive
side-by-side
testing. In my
initial email to
Clive Hohberger, I
mentioned that
Code128 Subset C can
be used to code the
decimal equivalent
of the EPC number
with about a 10%
increase in code
size. I believe
Sprague Ackley, in
his analysis
mentions this as a
possibility.
I, therefore,
recommend that
Code128 Subset C be
adopted to encode
the EPCSymbol.
Ted Williams
responded by
suggesting an RSS
expanded symbol. Now
that we have Ted
Williams(who under
my command invented
Code128) engaged,
perhaps Ted can
suggest any
modifications that
can be made that
preserve the ability
of existing
scanners to read the
symbol, while at the
same time allows
future scanner
designs to improve
the symbol's
readability. I
suggest that one of
Code128's function
codes be embedded in
the center to act as
both a unique
identifier and a
center marker. This
will permit future
scanner designs to
independently decode
each half of the
symbol, and will
remove the need for
excessive code
orientation.
As to Sprague
Ackley's suggestion
to consider Code
93i, I am at a loss
since I do not know
anything about it.
Sprague's
description of its
properties sounds
too good to be true.
Before it is
adopted, several
applications, where
it is used for high
speed fixed position
scanning, should be
examined to
determine read rate,
and accuracy. I do
not think that there
is any question on
this point relative
to Code128.
October 25, 2004
New EPC Symbol
Bert Moore
Folks:
Admittedly, I'm not
aware of the
naissance of this
specific thread
(I've seen the
e-mails but don't
know how Rick
somehow initiated
it) so I'm wondering
if there has already
been a discussion
about where the bar
code scanner would
be connected -- and
that's the basis of
my question.
That is, would it be
connected to the bar
code side of the
host software (since
not all units,
presumably will be
EPC tagged) or will
it be somehow be
routed to the RFID
edge server for
interpretation?
If it's the former,
wouldn't an SSCC-18
serve adequately for
retail users -- at
least in the interim
until the vast
majority of items
are, in fact, EPC
tagged?
October 25, 2004
New EPC Symbol
Tom Brady
I support the use of
RSS Expanded as
indicated by Ted
Williams.
RSS capable scanners
have been delivered
for at least the
last 2 years. Our
Global Standards
Management Process (GSMP)
has recommended an
open date for the
use of RSS as
January 2008. It is
estimated over 80%
of scanners will be
RSS capable by that
date.
Various user groups
are planning
applications using
the AIs in addition
to the GTIN. Such
applications will be
released for open
use as their
implementation is
proven.
As an example, the
Joint Industry
Coupon Committee is
working on RSS
expanded for US
coupon applications
with an open use
date of October 2008
(look at our Web
page
www.uc-council.org,
search for "coupons"
if you are
interested in a copy
of the current draft
proposal and
background
material).
One of the work
items as Gen 2 and
future standards are
completed is the
method of carrying
the AIs in expanded
tags and their
relationship to the
EAN.UCC keys (SGTIN,etc).
It seems to me that
RSS expanded is well
suited to co-exist
with EPC Tags.
The questions about
parsing are still
open to be resolved
most likely through
the new EPC
Architecture Review
Committee (ARC).
These are items
which must be
resolved. There will
certainly be
co-existence with
current bar codes as
well as the proposed
EPC structures
proposed here.
October 24, 2004
New EPC Symbol
Ted Williams
Assuming a 2-digit
AI to identify
the 96-bit EPC data
application, and
96-bit binary to
29-digit numeric
conversion, the
attached is a 151X
RSS expanded symbol
that would back up a
96-bit EPC tag.
I recommend this as
it is already
supported by newer
point-of-sale
scanners for
omnidirectional
scanning. It is also
a supported
symbology in the
General EAN.UCC
Specifications. So
it would require the
least modification
to the EAN.UCC
system - only the
definition of a new
AI for EPC-96.
Overview of
Symbologies Suitable
for EPC Encoding
By Sprague Ackley
24 October 2004
Many thanks to Chris
Kapsambelis for
suggesting a symbol
capable of encoding
EPC data. I, too,
was questioned
regarding encoding
exactly the EPC
bytes (on 15
September 2004) and
replied that there
is only one public
domain linear
symbology capable of
encoding bytes in a
uniform fashion but
that there are other
possible solutions.
At that time and
still the case, the
EAN/UCC technical
committee has not
begun any work on
the subject. At
that time, I
contacted the UCC
and informed them of
the concern.
Chris has now called
the question by
proposing a symbol.
I felt compelled to
make some comments
on his suggestion as
well as to do a
simple analysis of
the possibilities
using published
symbologies.
Chris' symbol
Chris claims that
his symbol is the
shortest possible
symbol encoding 12
bytes (he actually
encodes 24 hex
characters). Chris'
symbol encodes 24
(7,2) characters
inside weak start,
stop and guard
patterns. Forced to
use 16 of the 20
characters in the
(7,2) set, he
therefore has chosen
to utilize
non-self-checking
characters and he
has not added any
check characters.
His symbol would be
at least 100s of
times more likely to
suffer character
substitution errors
than UPC-E.
Furthermore, a
single error in the
last bar which
provides scan
direction
information renders
the symbol
un-decodable. In
order to make the
symbol resistant to
character
substitution errors
at similar security
levels to other
symbologies without
character
self-checking, he
would need at least
three check
characters. For
symmetry sake, I
have used four in
this comparison. I
have not added any
compensation for the
"Achilles heal" in
the start and stop
patterns. I am
calling the
resulting symbol
Chriscode.
Fine print
I have attached my
symbology
worksheet. It is
possible that there
are errors and I
encourage anyone so
inclined to check my
math. I only
considered the
EPC-96 data here but
I did the
calculations for
EPC-64 also. An
EPC-96 data string
contains exactly 12
bytes. All the
symbol lengths used
in this comparison
are in terms of X.
I have not included
the Quiet Zones, but
all symbols will
need at least one
and should have
two. It would be
possible to design
an entirely new
symbology using
large (n,k)
characters without
quiet zones that
would be shorter
than any in this
comparison of
Chriscode and the
published
symbologies.
Encoding bytes
directly
People that I talked
to wanted to encode
bytes directly.
That means that the
output of the
decoder is exactly
12 bytes, not Chris'
solution of 24
bytes. The only
public domain linear
symbologies capable
of this trick are
Code 128 and 93i.
In both cases, there
are virtually no
available printers
or readers that
support this
feature. Needless
to say, adoption of
a byte-capable
symbology by EAN.UCC
would inspire
vendors to supply
conforming products
in a very short
time. The best
solution here is 93i
at 208X. 93i is not
only the shortest
symbol (by 58X, on
average) but it is a
fixed length,
whereas a Code 128
symbol length can
vary by over 50%
forcing the use of
larger label stock
and taller bars.
The Code 128 byte
feature with AIs is
specifically not
allowed according to
the current
standard.
Encoding digits or
hex characters
If users do not mind
post-processing hex
characters or digits
into byte values,
then there are
several options.
The shortest symbol
both compresses the
bytes into a
30-digit integer and
then encodes the
digits using code
set C in Code 128.
The resulting symbol
is 200X. Encoding
decimal bytes in
Code 128 results in
a symbol that is
247X. Assuming the
AI standard was
modified and a
2-digit AI assigned,
an EAN/UCC-128
symbol would be 222X
using a compressed
integer and 269X
using decimal
bytes. Chriscode is
the smallest symbol
for encoding hex
characters at 209X.
By comparison, an
EAN/UCC ITF-14
symbol is 120.5X.
Error correction for
a better solution
for automated
scanning
If users are really
ready to encode
serialized
information on
shipping containers,
then they should
seriously consider
93i with error
correction. 93i is
the only public
domain linear
symbology with error
correction and as
mentioned earlier,
it is the only one
that can encode
bytes uniformly. A
93i symbol can
sustain complete
obliteration to
either the start or
stop plus additional
characters or up to
six symbol
characters and be
fully readable. A
93i symbol with
error correction
would nearly
eliminate no-reads
from automated
scanning
applications and
display less that 1%
of the substitution
errors of ITF-14. A
93i symbol with
error correction
encoding 12 bytes is
244X.
Bar height and
automated scanning
Another feature of
93i with error
correction is that
the symbol can be
scanned
unambiguously in
halves. This means
that the symbol
behaves as if it has
bars that are nearly
twice as tall as
other symbologies to
an automated scanner
for a given
X-dimension. When
compared to existing
applications of
ITF-14 using the
same X-dimension,
the bars would be
the same height as
the ITF-14 symbol
allowing similar
scanner tilt
angles. Needless to
say, proprietary
"stitching"
techniques in use
today could be used
with even greater
performance
improvement when
coupled with the
error correction
capability of 93i.
Summary
Chris Kapsambelis
has opened the eyes
of the industry with
his insightful
proposal for
scanning EPC-96 data
in a bar code
symbol. While the
shortest symbol for
encoding hex
characters is
Chriscode at 209X,
the best solution
for encoding the
exact same data
found in an EPC tag
is by using the
published AIM
symbology 93i at
208X. Once the
industry considers a
new symbology for
encoding automated
scanning data, the
error correction
feature of 93i
encoded in 244X
makes it ideally
suited for the
task. 93i can both
sustain damage and
use the same bar
height as is now
employed with
ITF-14.
Alternately, an EAN/UCC-128
symbol at either
222X or 269X without
error correction and
with bars that are
twice as high for
the same X-dimension
as the symbol used
today could do the
job without
introducing another
symbology into the
EAN.UCC system.
October 22, 2004
RFID & Bar Codes
Pail Chartier
Fellow AIDC 100
Members,
Sorry that I could
not be with you at
the recent meeting,
but I am working on
a UK Government
initiative to roll
out RFID centres. I
have been following
the thread of the
arguments, and I
know that Craig is
concerned with
having a back-up
data capture system.
So let me review
some of the
arguments.
1. For non-standard
pallets there is a
direct linkage
between the SSCC in
bar code and in the
EPC tag, so we have
a extant bar code
solution that
requires no new
investment.
2. For cases we need
something to
distinguish between
the different RF
tags to support
anti-collision. ISO
has solutions that
do not require a
serialised item
code, so the
14-digit SCC is a
valid fallback. A
fundamental
question that still
has to be addressed
is why have a
serialised GTIN? At
least it has not
been properly
answered.
3. If there is a
need for the SGTIN,
then the EAN.UCC
GSMP group should be
looking at
serialising the GTIN
for encoding in bar
code. We already
have sound
symbologies that can
achieve this. The
problem is that we
all seem to be hung
up on encoding
exactly the same bit
string in the
back-up bar code as
in the RF tag. We
are using two
fundamentally
different data
capture technologies
and do not have to
merge the logic at
the lowest level.
4. Furthermore, I
can see lots of
product
manufacturers
baulking at the idea
of adding
serialisation to
product codes that
are incorporated as
part of the product
packaging at decimal
fractions of a cent
per impression. What
happens when the
serialised bar code
does not verify? Do
we expect online
verifiers on every
filling line?
5. The migration
from EAN/UPC, or
Interleaved 2 of 5,
or Code 128 scanning
to RFID is not going
to happen overnight.
So these old but
robust data carriers
and their data
capture
infrastructure will
still be in place in
5
to 10 years time.
Now some are
proposing to add a
DIFFERENT bar code
symbology in
addition to these
and the EPC RF tag.
Do we really expect
the retailers and
others in the supply
chain to invest in
both RFID data
capture and install
or upgrade to a new
scanner base?
6. A final point for
now. Those of us who
remember the 1970s
and even the 1980s
know that we did not
solve all the bar
code data capture
problems on day one.
EPC has been
over-hyped as
providing fully
automated data
capture when it - as
yet - cannot do this
in all cases. RFID
brings considerable
benefits in a number
of applications.
With more work on
the technology it
will be increasingly
successful. The
problem is that the
Internet of Things
has been reduced to
a mantra that has
little foundation on
sound AIDC
technology and
experience. We
should be addressing
the real problem and
educating the world
to the benefits of
two great
technologies.
October 22, 2004
New EPC Symbol
TomThatcher
Dear Rick,
We are all in
agreement that there
should be a method
to represent the tag
data in bar code and
human readable
form. However, we
believe that the
work already done by
the AIM RFID Experts
Group has
sufficiently covered
this issue.
Best regards,
Tom Thatcher
President, Tharo
Systems, Inc.
October 22, 2004
New EPC Symbol
Rick Bushnell
Chris, Clive and
Craig, et al,
Since I'm the one
who raised the
question (wow, I had
no idea what hell it
was raise, I guess
it was on a lot of
people's minds) I'd
like to remind you
all that I first
discussed this with:
Will Garcia
Product Manager
Tharo Systems, Inc
will@tharo.com
(330) 273-4408
I really think that
you should contact
him because he has
already done some of
this work.
By the way I think
the back up is a
fantastic idea and I
have put Chris's
email below for
Will's review.
October 22, 2004
New EPC Symbol
Chris Kapsambelis
Hello Clive:
As a result of your
call to use barcode
as backup for the
RFID EPC tag in the
commercial sector.
I designed a new
barcode symbol that
encodes the 96 bit
EPC number in the
smallest possible
length of any
barcode symbology.
My first version of
this symbol is
attached.
I am willing to
place the symbol in
the public domain
and sign all
necessary waivers
for its free use.
Since the symbol can
be printed in a 4 x
2 inch space using a
20 mil. X dimension,
it can easily be
fitted on a 4X6 inch
label.
The 20 mil. X
dimension coupled
with the two-part
design ala UPC, will
permit reading cases
over a 360 degrees
of orientation,
traveling at very
high speed, on
conveyors, by fixed
position scanners.
There are many
distribution
centers, as well as
UPS and FedEx, that
are reading similar
size barcodes at
high speeds for
sortation purposes
As a result of what
was learned at the
Forum: Truth in
Technologies, I
believe that the
need to have a
barcode on the EPC
tag, that can be
read in motion on a
conveyor, will
become a crucial
alternative. Given
that the read rate
of pallet loads with
RFID is now shown to
be between 50% and
80%, the need for
automated palletizes
instrumented with
readers that can
generate 100%
perfect ASNs will
become a paramount
element of the
overall process.
The EPCsymbol will
give users the
choice of using
fixed position
scanners, ala UPS or
FedEx, or RFID.
Furthermore Manual
pallet loading
operations can use
hand held portable
scanners to generate
the ASNs accurately.
There is a danger to
going without
barcode backup for
the EPC tag. If
RFID fails to meet
its promise, it will
be discarded, and if
it is discarded, the
whole concept of the
EPC network for
tracking goods in
the supply chain
will probably be
abandoned as well.
The use of barcode
as backup, will give
added assurance that
the concept will
survive regardless
of the effectiveness
of RFID.
The problem of
introducing a new
symbol is that none
of the existing
scanners can read
the barcode. To
address this
problem, I am
working on an
alternative that
makes use of Code
128 Subset C that
can be read by any
of the existing
scanners.
Unfortunately, this
will require about
10% more space which
will have to be
compensated by a
proportionate
reduction of the X
dimension. However,
on the long run,
this may be a better
compromise.
If there is any
interest in any of
this, perhaps some
testing is in order
to prove out the
concept, and
finalize all the
parameters.
Please let me know
what you think.
October 22, 2004
RFID & Bar Codes
Craig K. Harmon
Folks,
Since it was my
presentation, let me
tell you what I said
and what I meant. I
said, there is no
EPC bar code . . .
further that there
is no convention for
recording a human
readable
interpretation of
EPC.
I am aware that
there are many bar
codes that can
record a numeric or
alphanumeric
equivalent. I am
also aware of Andy's
1994 patent. The
issue is that there
is "no accepted
means for an EPC
back-up, be it a bar
code,
two-dimensional
symbol, or HRI."
While there may be
solutions, there is
nothing that has
been embraced.
October 22, 2004
RFID & Bar Codes
Andy Longacre
Gents --
The final
sentence in this
review, otherwise
useful and
excellent, cannot go
unchallenged!
Perhaps it's useful
to start by saying
that most
communications
channels in use
today cannot (taken
literally) transmit
and receive "binary
codes" ... instead,
most transmit
streams of 8-bit
packets called
bytes, and a stream
12 bytes can, of
course, represent 96
bits. (Please note,
one might prefer to
use hexadecimal
representation,
which then requires
24 characters.) AND
of course Many
barcodes today can
encode any stream of
12 bytes or 24
characters that one
wishes. The very
thought that barcode
systems can't "read
and output binary
codes" (while RFID
readers presumably
can) is sure
poppycock!
-- Andy
Longacre
BTW -- there -are-
linear symbologies
that encode data in
unadulterated binary
form (see U.S.
Patent 5,479,515
e.g.) for what
that's worth.
October 22, 2004
RFID & Bar Codes
Chris Kapsambelis
At the recent forum,
titled "Truth in
Technologies 2004:
RFID & Bar Codes"
and hosted by the
AIDC100, I and
others raised many
of the points that
have been the
subject of
discussion on this
Opinion Page. The
following are some
of the
important points
that were raised and
the responses, as I
understand them:
-
Several members
of the audience
indicated that
the RFID read
rate for cases
loaded on
pallets ranged
from 50% to
80%. The
question was
raised as to how
this shortfall
in data
collection was
going to be
handled? The
response was
that an Advance
Shipment
Notice(ASN) will
be
required. The ASN will
be used at
Receiving to
fill in the
missing data. A
pallet load can
be received even
if only one of
the tags on the
pallet was read.
This led to an
observation that
most errors in
the make up of
the ASN will go
undetected.
-
Given that the
100% read rate
for pallet loads
is no longer
required, why
can't the less
expensive
barcodes be used
to identify
pallets and
cases using
fixed position
scanners? The
response to this
point was
twofold
-
It is
anticipated
that in the
future there
will be a
requirement
to uses
Read/Write
tags.
-
RFID is
expected to
be more
effective in
capturing
data from
cases as
pallets are
broken up
into fast
moving
inventories
in the back
rooms of
department
stores. How
is this any
different
from barcode
is not clear
to me.
-
A point was
raised that
currently the
specifications
do not require
that the
EPCGlobal 96 bit
binary number be
printed on the
label in
barcode. The
failure of any
tag will result
in either the
total loss of
identity or the
need to key
enter the 96 bit
code. Many in
the audience
felt that the
use of barcode
as backup for
tag failure was
essential. It
was also pointed
out that non of
the present
barcode systems
had the ability
to read and
output binary
codes.
August 11, 2004
RFID & Bar Codes
Chris Kapsambelis
Based on recent
press reports that
have leaked out of
the Wal-Mart pilot
program in Dallas
Texas, the reading
of pallets loaded
with RFID equipped
tags is no where
near 100%. This
will force Wal-Mart
to push the problem
up the chain, and
demand that
suppliers provide
pallet loads that
are guaranteed to
have 100% of
readable pallets and
cases, together with
an advance computer
record of the pallet
and all the cases as
a group. This will
enable Wal-Mart to
fall back to a
position of reading
any one of the tags
on the pallet and
use middleware to
lookup the
remainder.
While this sounds
like a reasonable
solution, there are
a number of issues
that are worthy of
discussion:
-
Since Wal-Mart
is unable to use
the technology
to effectively
read pallets and
cases as a
group, how are
the suppliers
going to capture
this data prior
to shipping. If
they "Slap &
Ship", the
errors will not
be caught until
Wal-Mart begins
to remove cases
from the pallet.
This is much too
late in the
supply chain to
be finding
errors. The
suppliers will
be forced to
develop systems
that can read
each case
individually as
it is being
loaded onto the
pallet.
-
As a solution to
the general
supply chain
problem, are
companies, like
Wal-Mart,
willing to
accept a system
that depends
largely on
trust?
-
As cases are
broken up for
further
distribution,
how does
Wal-Mart plan to
capture partial
pallet loads as
they move around
their
facilities?
-
If the finding
is that group
reading of tags
is not feasible,
why is RFID
better than Bar
Code?
August 3, 2004
RFID & Bar Codes
Craig K. Harmon
REG Team Leader
Speaking for the
RFID Experts Group (REG),
we completely agree
with Ed and Tom.
August 3, 2004
RFID & Bar Codes
Tom Brady
I fully support Ed’s
message.
I propose the use of
AIDC 100 knowledge
in a very positive
manner to build
"initial
installation" user
analytical
guidelines. These
would be used to
identify
and quantify
performance,
ergonomic, and
quality characteristics.
Results would
provide a solid
foundation to build
effective
implementation of
both bar codes and
RFID, identify
interoperability
requirements, and
point to further
research needs. The
guidelines can be
based on "use case
scenarios" now being
developed.
To me, success will
be the effective use
of all AIDC
technologies to
improve
"visibility" throughout
supply chains. This
includes network
connectivity and
supporting data
collection
and management. A
much expanded AIDC
vision.
August 2, 2004
RFID & Bar Codes
Bob Scaringe
The article suggests
some solutions to
the problems cited
and illustrates the
premise that the
technical issues
will be overcome.
Nobody that I know
of has come out and
said there are
stoppers that can't
be overcome. I
don't think you are
saying that either
Chris.
I have to tell you
that the whole
adoption cycle of
RFID sounds eerily
similar to the RFDC
technical issues
raised in the 80's
relative to
interference from
cell phones,
security systems,
fading due to
reflections and even
the non-technical
issues of security
of the data being
transmitted and
health concerns of
more RF are all
arguments we have
heard before that
were overcome.
The suggestion is:
do we (as a group)
believe the
technical/soft
issues will be
overcome? Then,
what position do we
take (as a group)
relative to its'
adoption. Maybe
there should be a
discussion and vote
at the meeting.
August 2, 2004
RFID & Bar Codes
Chris Kapsambelis
In response to the
message from Bob
Scaringe, I would
like to refer the
membership to the
article by H.L. van
Eeden that appears
on the latest issue
of RFID Journal.
http://www.rfidjournal.com/article/articleview/1056/1/82
Mr. van Eeden goes
into great detail
concerning the
problems associated
with the use of
multiple readers and
antennas.
July 31, 2004
RFID & Bar Codes
Dick Meyers
Over recent months,
I find most
interesting many
inaccurate articles
in the press about
the "coming" of RFID
and the "death" of
Bar Codes! We
should put this
movement into proper
perspective without
reinventing the
wheel! This
dialogue reminds me
of the same events
that occurred 20-30
years ago when the
food industry
dictated the use of
UPC and the DoD/Auto
industry dictated
the use of Code 39.
Many of the same
discussions took
place then that are
now occurring on the
topic of RFID.
As an industry, we
should take
advantage of what
happened years ago
and smooth the
implementation of a
newer technology in
a complimentary
fashion by using it
where the
APPLICATION
warrants. It would
be more efficient if
both "users" and
"suppliers" worked
TOGETHER to
formulate RFID
schedules and
marking levels along
with the most
effective
applications. In
addition, clarity
should be
established relative
to the continued use
of Bar Coding.
The aforementioned
goals are precisely
what "Truth in
Technologies 2004:
RFID & Bar Codes" on
October 20th are all
about. Attend and
learn the real truth
from the prime
players including
users, suppliers,
consultants,
technology providers
plus many expert
members from the
AIDC 100!
Participate in
this unique forum
and contribute to
the enhancement of
the AIDC industry.
You will be richly
rewarded.
July 30, 2004
RFID & Bar Codes
Chris Kapsambelis
I was disappointed
with the agenda for
the above subject.
The simple fact is
that RFID, in the
form that is
proposed for use in
the supply chain
between large
retailers and their
suppliers, offers no
advantage over Bar
Code, and is more
costly. The agenda
focuses on problems
of RFID
implementation and
compliance, and
fails to mention
anything about the
merits of Bar Code.
Where is the "Truth"
implied in the
title?
Proponents of RFID
point to the fact
that RFID does not
require a Direct
Line of Sight to
read a tag, while
Bar Code does. This
is the property of
RFID that,
proponents say, will
permit the complete
reading of Item
tags, Case Tags, and
Pallet Tags as they
pass RFID readers at
strategically
located portals. I
maintain that, in
its current form,
RFID does require a
Direct Line of Sight
and, therefore, is
not superior to Bar
Code. A closer
examination of the
proposed form of
RFID technology will
show why the above
statement is true.
In order to achieve
the low cost
requirement for RFID,
the focus is on
passive tags with a
printed circuit,
high Q, tuned, loop
antenna. By its very
nature, this results
in a two dimensional
tag very similar to
a barcode label.
Some traditional
barcode printer
suppliers have
introduced printers
that can print and
encode labels/tags
with some of their
printers.
Radio loop antennas
are highly
directional, and
require that the
face of the
label/tag be
orthogonal to the
reader in a straight
line. Otherwise,
they fail to read.
This is the same
technology that has
been used for Radio
Direction
Finding(RDF). We
are all familiar
with old movies
showing German army
vans with a loop
antenna on the roof
being rotated slowly
to determine the
direction of the
spy's radio
transmitter
frantically sending
a message in Morse
Code.
The directivity of
these tags renders
them equivalent in
performance to Bar
Code labels with the
exception that RFID
can read through
some non-conductive
materials such as
wood and plastic.
However, since they
cannot read through
or around metal,
metal film, and
practically all
liquids, this
property is almost
useless. With Bar
Code, you can at
least see what you
are reading.
The need to ensure
an orientation in a
straight line,
unobstructed by
metal or liquid,
between the reader
and all the tags, as
well as, the
requirement that all
tags must be facing
the reader, makes
the task of reliably
reading a pallet of
cases completely
impossible.
As far as using
Singulation and
Aggregation to make
up for unreadable
tags, these
techniques can also
be used with Bar
Code, and the
solution is both
cheaper and more
flexible.
As for the concepts
of PML, ONS, and
SAVANT they apply
equally to Bar Code
and RFID. If they
can be justified for
RFID, they can be
justified for Bar
Code.
One of the truths
that has to come out
of this conference
is that unless the
use of active tags
with dipole
antennas, oriented
vertically, similar
to cell phones, are
adopted, very little
of the hype
associated with RFID
will come to pass.
There is no need to
continue testing the
current form of RFID.
Anyone with a
rudimentary
knowledge of Radio
Frequency
Electromagnetic
Waves and their
propagation can
easily analyze this
technology and come
to the conclusion
that it will not
work as currently
proposed.
There are many other
differences that
favor Bar Code, but
if what I have said
so far does not
concern anyone,
there is no point in
continuing the
debate.
July 30, 2004
RFID & Bar Codes
Ed Barkan
Nobody is more
pro-barcode than I
am, but I am
concerned that we,
as a group, can be
so intent on
pointing out the
flaws and
misconceptions of
RFID that we fail to
acknowledge that it
will probably find
useful applications,
and many of them may
well have been
impractical to do
with barcodes. When
this ultimately
happens, we don't
want to be perceived
as having taken the
position that RFID
is only a dream that
will never amount to
anything, or we will
lose credibility as
an organization.
I think our duty at
this time is to be
perfectly honest and
open about the
relative merits of
barcodes and RFID.
This will make it
clear that much of
what is said in the
popular press, such
as RFID replacing
barcodes at POS, is
unlikely to be
practical in the
foreseeable future.
I would also
hesitate to claim
that some of the
issues pointed out
here are
insurmountable. For
example, there has
been discussion
about the fact that
the antennas on RFID
tags are
directional. This is
true, but some of
the greatest
interest in RFID is
coming from people
who are interested
in tracking objects
that are moved
through a portal,
either on a conveyor
belt, a fork lift or
even manually
carried. In these
situations it is
quite practical to
mount multiple
antennas around the
portal to compensate
for
the directionality
of the tags. There
may be ways around
some of the other
limitations of RFID
tags as well,
although they may
limit the areas
where deploying them
will be practical.
July 30, 2004
RFID & Bar Codes
Clive Hohberger
While bar code are "Ooohhh...
sooo 20th century!"
as my college-age
daughter would
say... as one
involved in both bar
code and RFID for
many years, and one
involved in the REG
developing
guidelines for RFID
deployment by DoD
(read NATO), my view
has become that I do
NOT believe RFID can
be successfully
deployed without bar
code back up... any
more than we could
have deployed bar
code in the 70's and
80's without human
readable back-up.
1) UHF RFID tag
non-read rates are
still too high, due
to transponder
damage, aging, RF
effects of the
packaging on the tag
(a huge unrecognized
problem), poor
transponder antenna
design, reader
cross-interference,
and tag sensitivity
variations due to
chip-to-chip and
transponder
manufacturing
quality control
issues. Pilot
studies of UHF RFID
have not anywhere
approached the 99+%
read reliability
rates we saw with
13.56 MHz RFID in
baggage handling.
2) Generation 1
Class 0 and 0+ UHF
tags are
read-performance
focused, actually
work quite well in
pilots (and Zebra is
supporting many
pilots right now).
My bet is that
96-bit Class 0+ tags
are a good model for
Generation 2 tag
performance. This
proves that
Generation 1 tags
CAN do the job, when
transponders are
performance
optimized. But the
successful Class 0
transponder designs
are more expensive
than most of the
cost-oriented
Generation 1 Class 1
designs, because...
3) The obsessive
focus of Wal-Mart
suppliers on
reducing UHF tag
cost has aggravated
many of the
transponder and
smart label quality
issues above. You
can't have
sophisticated
transponder
antennas, test in
quality and have low
cost simultaneously.
This just increases
the probability of a
non-read in
practice, especially
for cost-focused
Generation 1 Class 1
tag designs.
4) Generation 1 tag
designs are not
nearly as well
thought out as the
Generation 2 Chicago
Protocol in dealing
with issues such as
activation by
multiple readers
simultaneously in a
cross-docking
environment.
Wide-scale
Generation 2
production is
probably mid 2005.
This implies that...
5) Unfortunately,
initial deployment
will be with
Generation 1 tags, a
great deal of which
will be cost-focused
designs.
6) Most importantly,
there is a huge sea
change in the supply
chain business
model, which is why
we are deploying
RFID! A pallet no
longer consists of
48 identical product
code-labeled boxes.
With RFID you have
to deal with 48
serialized cases,
each of which can
and must be tracked
separately once the
pallet is broken.
That's the whole
point of the
technology change!
7) If you can't read
the RFID tag on a
case, you lose the
serialized
information, as
current EAN.UCC bar
code standards don't
incorporate
serialization. All
you can retrieve
from the bar code is
the GTIN or product
code.
8) Therefore on the
DoD Military
Shipping Label, we
proposed adding a
field to the master
PDF-417 bar code
using Data
Identifier 96S to
carry the EPCglobal
or DoD tag data
structure as a bar
code back up to the
RFID tag!
9) There is a raging
discussion within
the UCC and
EPCglobal community
about the need and
form for bar code
backup of the EPC
tag in the
commercial sector.
It started last
spring in the GSC
meeting in Ft
Lauderdale, and I
believe this issue
must be shaken out
by the end of the
year. Its basically
an issue of
providing CONTINUITY
between EAN.UCC bar
code standards and
EPC RFID standards
for supply chain
management.
10) I believe that
the change in
business processes
to individual
serialized case
tracking is so
fundamental that bar
code back-up is
essential to the
successful
deployment of the
current EPCglobal
Generation 1 RFID
technology.
Otherwise, cases
with unreadable tags
will lose their
serialized identity,
and not fit into the
new inventory
management IT
system.
Granted, there will
be coexisting "bar
code-based product
code-only systems"
and "serialized case
code RFID-based
systems" for a long
time, but at the IT
level you don't want
to deal with
serialized cases
being "lost" to the
product code-only
system just because
the RFID tags gave a
no-read. Aside from
creating a nightmare
inventory management
problem, you lose
the business benefit
of the RFID tag, and
the ability to
recover its cost in
the new business
process. A back-up
bar code for the
EPCtag allows you to
avoid the inventory
management, and to
keep the serialized
case in the
appropriate tracking
system.
An Analogy: Think
about last few
visits you made to
the supermarket...
how many bar coded
grocery items had to
be entered from the
human readable on
the package? And how
did the cashier..
and the store IT
system... manually
handle UPC or EAN-labeled
items where the bar
code on the label
was missing, ripped
or unreadable?
Now imagine how this
must be done in a DC
on a conveyor
running at 500 feet
per minute when an
RFID tag gives a no
read!
July 30, 2004
RFID & Bar Codes
Andy Longacre
One more interesting
observation
regarding RFID and
it's claimed
advantage of not
requiring
line-of-sight
reading: objects
that would interfere
with reading -also-
need not be in
sight! When a
barcode is obscured
from reading, the
operator can know
it. When an RFID
tag is "obscured"
from reading, the
operator (a) might
not be sure there's
even a tag to be
read and even if so
(b) might have not a
clue what's around
to interfere with
its being read. The
out-of-sight
character in RFID is
also an Achilles
heel.
Viva barcodes!
