Difference between revisions of "Reader Development Stages"

Revision as of 00:47, 12 February 2008

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 Alien9800 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 basics of a reader module</b>

1. The heart of the reader is the ReaderModule. This is where all components of the reader are initially created. The order in which they are created is as follows(modules in [brackets] are optional):
   1. Antennas
   2. Radio
   3. TagMemory
   4. ExceptionHandler
   5. SharedResources
   6. [LoginCommandAdapter]
   7. InteractiveCommunication
   8. InteractiveCommandAdapter
   9. InteractiveCommandController
   10. [AutonomousCommunication]
   11. [AutonomousCommandAdapter]
   12. [AutonomousCommandController]
2. More information on ReaderModules can be found at (INSERT LINK HERE). Also refer to AlienReaderModule, EPCReaderModule, and AwidReaderModule, which should all be very similar to what you have to do in the module.
3. Write some basic handler methods so that you can test communication:
   1. Login (if needed)
   2. Other simple handler methods needed.
4. Rifidi IDE Integration - To actually run and test the reader, you will need to integrate it into the IDE. You will need to follow these steps: Reader Module IDE Integration

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