PIRF Platform Independent RFID middleware

Introduction Every RFID implementation includes more than just RFID readers and antennas. In many cases it may include more than one type of reader, tag, or both. The state of the technology today is such (and most probably will remain in the future) that each manufacturer provides different host protocol(s) for their devices. Standards of course exist, but they cover mostly the air protocols, not the host protocol between the controller (PC) and the reader. These protocols most often are complex. The manufacturers often provide some software libraries to help with the development of applications, but they are almost certainly incompatible with the other devices in the system. Naturally, the developer is left with a large number of incompatible software modules that need to work together. Adding a new device, or replacing an existing one basically means to rewrite entire parts of the application. This approach does not scale well, and needless to say is expensive to support. More importantly, the simplest of all cases is never realistic. In large implementations it is critical for the software to be able to control more than just the reader. It is a fact that in order to create a robust system, every module needs to work seamlessly thus presenting the look and feel of one integral system. Therefore, RFID readers often need to be controlled in cooperation with digital and analog sensors (including optical), attenuators, conveyor motors, door locks, barcode scanners, printers, and many other devices. When everything comes together it becomes obvious that a new approach is needed. This is especially true when one realizes that the individual software libraries provided by the respective manufacturers are all written in different languages, or do not run at all on UNIX, Linux, etc. The issue usually arises gradually, when companies start using one technology and later want to add new components or replace the vendor. It very soon becomes clear that the biggest investment is not the RFID hardware, but the software that works with it, and unfortunately, it is exactly that which becomes obsolete first. DataBrokers, Inc. has experienced the problem first hand. In each case it was difficult to modify the system after changing the RFID vendor. Based on this experience we decided to spend the time and money to develop platform and vendor independent middleware. The Essence of PIRF While designing PIRF, we had the following goals:

1. To provide a single consistent interface to all RFID related hardware components in the system. 2. To achieve it in a vendor-neutral manner. In other words, we should be able to replace one RFID reader with another one, made by a different company without the need to change the code, or the business logic in the system. 3. To be able to execute on as many different platforms (operating systems) as possible. 4. To design it in the best possible way so it could be easily used in distributed environments and with special attention to the needs of web-based applications. 5. Where possible to achieve plug-and-play feel. 6. To make it modular, scalable, and customizable.

We were able to hit all of our goals because:

We created a modular architecture, based on well-defined interfaces, which in turn allows us to provide a number of drivers all with the same API. We spent long hours analyzing and comparing different RFID devices until we completed a single list of methods (functions) that they all share. This is not the lowest common denominator, but rather what an application developer really needs from an RFID device. We provide control for RFID devices from different vendors, and one driver can be substituted with another with a mere change in the configuration file or less. The rest of the system continues to operate as before. When a new device comes to market we develop a driver for it and simply add it to the list. In addition to the low-level hardware support, we analyzed how implementations can cope with different transponder (RFID tag) types. As it stands today, every manufacturer has different data layout for their tags. Even if the client has selected a single vendor, corporations must have a strategy to change the tag at some point if only when upgrading their systems. To help with that, we developed several software abstractions that shield the developer (and the business logic) from the details of how exactly the data is stored on the chip. The developer is free to work with software concepts and can be assured that his code will not have to change as soon as a new chip is introduced. In addition, this simply saves a lot of development time, which is better spent coding the business logic than figuring out the hexadecimal layout of the individual transponder. In the end, we added tools to configure the middleware and allow it to automatically find the correct driver, which gives it its plug-and-play feel. To be able to execute on many platforms, we developed our product entirely in Java which enabled us to run the same code base without modifications on Windows, Windows CE, Linux, UNIX, etc.

List of Components PIRF version 1.1 provides:

1. The software modules – set of JAR files and native libraries for different platforms 2. Example applications with the source code 3. Documentation (including javadoc) 4. Sample configuration files

PIRF comes on a CD-ROM disk fully configured with Java Runtime Environment, so a demo application can be run directly from the CD without requiring installation on both Windows and Linux environments. PIRF version 1.0 comes by default with RFID drivers for Texas Instruments, FEIG, TagSys, Symbol, and Zebra (Philips) devices. In addition there are variations for the most popular drivers for control of multiplexer devices, smart shelves, RFID conveyor systems, POS, and RFID scanning tunnels. Provided are SOAP drivers and a simple HTTP SOAP server that allows RFID devices to be controlled remotely over TCP/IP in a firewall-friendly manner, which is mainly used for web-based and distributed systems where one server needs to interrogate multiple devices. Lastly, we provide RFID drivers for control of RCRFID microprocessor modules developed by DataBrokers, Inc., which can help eliminate the controller PC.

Licensing PIRF is designed for IT teams that are working on custom RFID solutions. It is licensed per development seat and there are no royalties for deployment. Once the application is created it can be distributed to all sites at no additional cost.