Reader Development Stages

One of the main goals of Rifidi is to emulate RFID Readers. We do this by trying to match as closely as possible the input to and output from a reader. In this way, client programs are "fooled" into thinking they are talking to a real reader.

RFID Readers Currently Supported in Rifidi

• Alien 9800
• Symbol XR440
• LLRP Reader
• Awid MPR
• EPC Reader
• ThingMagic (work in progress)

Stages of Building a Reader

Stage 0 Prerequisites

Goal: To understand the reader and its associated tools

In order to start emulating a hardware reader, there are several things that are recommended before you begin. These things are, as follows:

1. The reader itself - the hardware version of the reader, available for your use. Familiarize yourself with the reader to get used to the command set and the functionality of it.
2. The documentation for the reader - the spec that documents all commands and behaviors of the reader.
3. Network/wire information monitors. Here are the tools that are used at Pramari:
   1. Network tools:
      1. Wireshark - this is a network analyzing tool that will assist you greatly in showing the exact inputs and outputs of the reader.
      2. Snark - This tool is an HTTP proxy. It can "intercept" HTTP messages sent to and from a client so that you can see them. When using a reader that uses HTTP, it is simpler to use than Wireshark.
   2. Serial tools:
      1. Serial Port Monitor - a simple tool that monitors all traffic over a serial port (real or virtual). A must-have when testing serial readers.
      2. Virtual Serial Port creation tools like com0com or VSPD. This will allow you to create virtual serial ports on your computer, allowing you to more easily test any serial reader. If you don't want to use virtual serial ports, you will have to use a real serial port connected to a seperate computer to test a serial reader.
4. Client testing tools - Tools that will help you test the reader once you have implemented it. These tools include:
   1. The client tool - Most readers have a simple client provided by the manufacturer that can connect to a hardware reader.
   2. Edge or ALE servers - If you have any edge servers or ALE servers that can connect to the reader you are trying to implement, you can use those to test how faithful your reader is to the real thing.

Ouput: Validate approach. Make sure tools are sufficient and reader that you are not biting off too much

Stage 1 Design Questions

Goal: To gain a deep understanding of how the reader works

1. What communications protocol does your reader use?
   1. The current version of the engine (current as of 7-3-07) supports TCP, UDP, and Serial(RS232) protocols. If you are using one of these protocols, nearly all of the work is done for you for the communication.
   2. If you need a different protocol, you will need to write a different module. A guide showing how to do this is here (INSERT LINK HERE), and more information can be found at stage 3.
2. Does your reader have an autonomous mode (a mode where the reader will search for and report tags without user input)?
   1. If yes, there is an autonomous module which most likely be able to assist you, depending on the behavior of the autonomous mode.
      1. If it cannot help you, you will have to create your own autonomous module where you define your own behavior. Further documentation on creating an autonomous module can be found at (INSERT LINK HERE).
   2. If no, you can move on.
3. Does the reader have any sort of login?
   1. There is code that can support both readers without login and those with login. A guide showing how to use the login commands is here (INSERT LINK HERE).
4. Does the reader use a non-standard protocol, like http, to communicate?
   1. If it does, you can set a protocol class that will filter through all communication and strip out/add information as you see fit.
5. How do you get and set reader properties?
6. How do you get tag lists?
7. Are there extra features that you will need to implement (such as heart beat)?
8. What is the tag memory model like?
   1. Under what conditions are tags added to memory?
   2. Under what conditions are tags removed from memory?
      1. Is there a concept of persist time (i.e. an amount of time that the tag stays in memory after it is deleted)?
      2. Are there certain events that trigger tags to be removed, (e.g. a taglist is sent to the client)?
   3. Is there more than one list of tags (i.e. a list of current tags and a list of previously seen tags)?

Output:

1. The output of this stage should be a good description of the reader that answers the previous questions. It should probably follow the form of the readers pages that are already done (see Alien 9800 for an example.
2. Identification of any necessary Rifidi Engine enhancements (i.e. Socket parsing, HTTP, Utility methods such as methods to help print bytes, and other anything that is too complicated and buried inside the engine or that just hasn't been implemented yet)

Stage 2 Reader Core Implementation

Goal: To implement the skeleton of a reader module

Basically, you will need to implement the files as outlined in the package structure page. Don't worry too much about the complications of the Tag Memory model just yet. The basic goal is to just write a reader that you can connect to.

1. Create a reader project. For help see Create_a_new_reader_project
2. Next write stubs for all of the required packages. See Package_Structure_for_a_reader_project. Also Refer to the Symbol reader for help getting started because it is the simplest at the moment.
3. After you have written the required classes, you will want to write a basic handler method that you can test out. Perhaps the handler method should just print out a message when it gets called.
4. Test out the reader by connecting to it and sending the command which you have written a handler method for.

Output: A simple reader that you can connect to. As the goal of this stage is to build a simple handler method, you will want to make sure that a command that you send from a client is actually getting into the handler method that you have written, and not just getting stuck in the emulator somewhere. Make sure to put debug output in the handler method to check for it.

Stage 3 Communicating and Getting tags

Goal: The goal is to have it connect to all of the tools we wish the reader would support, such as BEA Edge server and LogicAlloy ALE server and to enable these tools to get tags from the reader.

1. When you first get the reader up and running, the next step is to get it communicating with tools that recognize it and get tags back from it, so you will probably have to implement several new handler methods.
2. Use the Network/wire monitors listed in Stage 0 part 3 to monitor any traffic that goes into or out of your reader, and compare that to the traffic of the hardware reader. In this way, you can get your output as close to the hardwarereader as possible. Take note of the commands that the client tools send the hardware reader, and design handler methods to respond to these methods correctly.
3. The final step is to implement whatever handler methods you will need to get tags back from the reader. Most readers have some sort of an "on demand" mode where a client can send a command and get a tag list back.

Output A reader that client tools can connect to and that can respond with tags

Stage 4 Extended Handler Methods & Extra Features

Goal: Implement extra features for convenience and to extend functionality of the reader beyond a basic level

1. Now that a client can connect and get tags from a rifidi reader, it may be nice to implement some "non-essential" commands or features. For example, there may be more than one way to connect to a reader (i.e. using http, or a bit-encoded protocol), there may be ways to get and set certain properties, or there may be an autonomous mode for the reader. In this stage you can implement these extra features and handler methods.

Output A reader that includes extra features and/or extra handler methods

Stage 5 Testing and Preparing for Release

Goal:To make sure that a reader is properly tested and that future maintenance is as painless as possible

1. Once the desired features are implemented, the reader should be rigorously tested with various tools on both windows and linux.
2. It is recommended that Junit tests are written and stored in the eclipse project along with the code
3. If changes have been to the emulator packages, make sure that it did not unintentionally affect other readers
4. Write documentation describing various features of your reader. See Alien 9800 for an example

Output: A reader that has been thoroughly tested, Junit tests, and documentation