|
Whitepapers and Columns
|
|
| |
Can an RFID System Play Well with the Rest of Your
Network? (Part I)
That is certainly the question in the mind of many IT
departments. Simply stated, IT departments have two major RFID-related
concerns. First, they are concerned about the flood of data that
might take place when they plug an RFID solution into their
network. The potential for generating overwhelming, unrelenting
streams of data flying around the network as readers pick up
tags should be cause for concern. The fact that you really
can’t, in some cases, effectively turn the readers off, just
adds to the data challenge. ...
(click here to read the whole report)
|
| |
Can an RFID System Play Well with the
Rest of Your Network? (Part II)
Last time in this column series we discussed how readers
exist on the network and my illustration of the RFID domain
model. To review: Using the model, below, we can start to see
where the network pressure will manifest itself. The largest
issue currently has to do with the raw, unpersisted data moving
between the Edge and the Execution domains. As you plan your
RFID implementation, some of the key decisions facing you are as
follows ...
(click here to read the whole report) |
| |
|
Should You Push or Pull RFID Data?
In my last RFID coIumn, I explained the importance of
understanding how you and/or your RFID vendors will deal with
the “context” of read data. Here’s why: the processes occurring
in the facility coupled with the integration (communication)
ability of the execution system (such as a WMS) will ultimately
determine where context decisions are made and, therefore, where
the processing is done. I like to think of this is as the “push
or pull” decision (although there is a case for a combination of
push and pull).
(click here to read the whole report) |
|
| |
| |
|
| |
|
|