Architecting an RFID Middleware Framework

Architecting RFID Middleware

Joseph E. Hoag and Craig W. Thompson

Radio Frequency Identification (RFID) is an automatic identification technology that relies on cheap tags (transponders) that can be attached to objects (e.g., pallets, containers, ID badges, assets, vehicles, pets) and that can be read by nearby readers to help track where and what things are. The technology is like barcodes except the reading is wireless, does not require line of sight, many items can be read simultaneously, and individual items have individual identities. Reader ranges are typically measured in feet. While RFID is not a new technology, with recent initiatives from the US Government and Wal-Mart, the rate of improvement of RFID technology has been dramatic resulting in lower cost tags (now under 10 cents) and higher read reliability.

Commercial RFID is especially interesting because it can be seen as a vanguard of the coming world of sensors where most or all individual objects will have a network identity, have interfaces, and can communicate wirelessly with humans and other objects. Past architectural perspective columns have covered this coming Internet of things where everything is alive [2, 3, 4].In the Spring of 2005, the University of Arkansas opened its RFID Research Center. The Center is housed in a fully operational 7000 sq. ft. warehouse, is sponsored by major retailers and RFID equipment vendors, and contains the latest RFID technology (tags, antennas, readers, printers, conveyor belt). The Center is student staffed, one of a very few RFID Centers accredited by EPCglobal, and engaged in training, testing (especially for the retail industry), and general RFID and sensor research.

Because RFID is still in the fairly early adoption stage, many companies are still trying to assess the business case for RFID. One recent study [2] suggests that a retail industry wide problem with out of stocks (products that should be on the shelf but are not) can be significantly reduced. Another problem early adopters face is to assess what hardware and software investments they should make. Every RFID reader and printer presents a different interface systems are not yet interoperable.

In the summer of 2005, the Computer Science and Computer Engineering Department at the University of Arkansas started a project aimed at developing open-source RFID middleware to address this latter problem. This article describes the architecture of that software, some plans for future development, and some final observations on the challenges and benefits of addressing real problems in universities.

Overview of the RFID Middleware Architecture

Figure 1 shows a typical warehouse. Trucks back up to a dock door to unload pallets of goods. Pallets typically contain several containers which themselves contain items like bars of soap. Pallets and containers have RFID tags but, at least today, most low cost items do not have their own tag (for cost and consumer privacy reasons). RFID readers might be situated at the dock door, on conveyor belts, at storage racks, on fork lifts, or at doors leading into the store. By reading tags, a pallet or container can be traced as it moves along the supply chain.

Figure 1: Warehouse with RFID Readers

A first challenge we faced was how to model the warehouse world. We decided to use a mixture of agent and object technology. Each device (RFID reader, printer, camera, motion detector, forklift, conveyor belt) is an agent. While device interfaces may vary widely in terms of format and protocol, all agent communications are accomplished with XML messages over UDP/IP. Agents act as wrappers or translators for their associated devices: other middleware communicates with the agent, and the agent communicates with the device. Figure 2 shows several reader agents and a printer agent communicating with a DBMS agent and some user interface agents.

Figure 2: Sample TagCentric ConfigurationUbiquity Agent Architecture

We quickly discovered that we needed to develop two pieces of software: (1) A general-purpose core architecture designed to be extensible for pervasive computing applications, and (2) an RFID-related application architecture that specializes the generic agent architecture. We code-named the agent architecture Ubiquity and the RFID application architecture TagCentric.

We had a number of goals in mind when we created the Ubiquity agent architecture:

Flexibility. We wanted the architecture to be extendible to any number of applications. This meant that we could make no assumptions about the application in the architecture.

Portability. We wanted the applications to be able to run on as many different platforms as possible. For this reason, we chose to develop in Java, use XML as our communication language, and use simple UDP/IP as our communication medium. Although we chose to implement our software in Java, the essence of this framework lies in the format and meaning of its messages. An application can be written in any language and still participate in our architecture, so long as it can parse and transmit XML over UDP. Fault-tolerance. We wanted to avoid any single points of failure on the architecture level, which meant that we wanted architecture-level information (like which agents are up and running?) to be distributed among all agents, rather than stored in a central agent.

Power. We wanted to abstract as much core functionality as possible into the architecture, so that extending the architecture to an application was a relatively simple task.

Figure 3: Architecture Core Classes

Core Architecture Classes

The fundamental building block of the Ubiquity architecture is the Agent - see Figure 3. The Agent class provides basic communication functionality: subscribe to a message type, publish a message, post a message to a specific destination (which does not result in a return message), send a message to a specific destination (which results in a return reply), and handle an incoming message. The only things that distinguish one Agent from another in terms of personality are (1) which message types the Agent handles, and (2) how it processes those messages. You create an application-specific agent by creating an Agent-derived class that properly handles a given set of messages.

The Transport class handles all communication for an Agent. We use two basic flavors of messages: (1) Point-to-Point messages, and (2) Publishable messages. Point-to-Point messages involve a single recipient; an example might be a command to turn on a reader. Publishable messages are general interest messages that may have any number of interested recipients; one example is the AgentConnected message that an agent sends when it starts up. Rather than implement a complicated publish/subscribe mechanism for publishable messages, we decided to use a multicast facility. A transport object maintains two sockets: a MulticastSocket to handle Publish/Subscribe operations for publishable messages, and a regular UDP socket to handle Post/Send operations for point-to-point messages.

The Transport class employs background threads to unload incoming packets from its sockets and store them on intermediate queues. By dedicating threads to the quick unloading of incoming packets, we avoid packet-overrun problems on the receive side. Also, there is fragmentation logic built into the Transport class, so that messages of any size can be successfully transmitted and received.

The XMLTranslator class assists the Transport class in translating incoming XML messages into Message objects and is covered in more detail below.

Messaging

Figure 4 shows our messaging scheme, along with a few of our architecture-level messages. The basic idea is that all messages contain header information, which corresponds to the Message class. Each message also contains a type-specific message body, corresponding to a MessageBody-derived class.

Figure 4: Architecture Message ClassesThe message classes (both header and body) contain a toXML() method, which converts a Message object to an XML string. To convert from an XML string to a Message object, we use the XMLTranslator class described in the previous section. In order to make the XML-to-object transformation easy for the XMLTranslator, Message classes have to be designed in a certain fashion: (1) Each MessageBody-derived class must fill in a value for the MessageType field in its constructor, and (2) For each attribute XYZ of the message class, there must exist a corresponding setXYZ() method which accepts a string parameter representing the value of XYZ and has a return type of void.

Figure 5 illustrates the complementary processes of converting a Message object to XML and converting XML to a Message object (in this case, a DiscoveryRequest message). The sending agent for a message will use the toXML() method of the Message object to convert it to an XML string. The receiving agent will employ the XMLTranslator.parse() method to convert the incoming XML string into a Message object.

Figure 5: Message/XML ConversionUser Interface Support

Our generic device architecture takes advantage of the soft controller from [4]. A soft controller is a truly universal remote control that can read a remote devices user interface specification. There might be more than one such specification for a given device, based on the model-view-controller design pattern. That is, devices support a native API interface but their interface to humans is via a separate interface called a GUIPanel. GUIPanels for different devices are arranged in a GUIAgent dashboard - see Figure 7. That is, a GUIAgent is composed of GUIPanels, each of which corresponds to a connected agent.

The GUIAgent operates by listening for AgentConnected messages. When the GUIAgent receives such a message, it searches for the existence of a Panel class, where is the value of the Type field in the AgentConnected message. If a Panel class is located, the GUIAgent creates a new panel corresponding to the newly connected agent. If a Panel class does not exist, then the AgentConnected message is ignored. For example, if an agent of type Reader emitted an AgentConnected message, then the GUIAgent would look for the existence of a class called ReaderPanel and pop one up if it existed.

Figure 6 provides a UML description of the GUI classes in the architecture. GUIAgent is an abstract class; there must be an application-specific class derived from GUIAgent which provides the setUpLocalPanels() method. A local panel is one that does not correspond to any specific agent, like an administration panel or a test panel; local panels are typically application-specific. The application also has the ability to set the title of the GUIAgent window.

The GUIPanel class is also abstract; the application-specific GUIPanel-derived classes must provide a handleAsyncMessage() method to determine the disposition of incoming asynchronous messages. GUIPanel-derived classes can register for asynchronous (i.e., publishable) messages via the registerForAsyncMessage() method. GUIPanel-derived classes allow application developers to associate a panel with an agent type; a panel for agent type XYZ will be displayed for each agent of type XYZ that becomes active. Figure 7 shows a ReaderPanel from our TagCentric application; each active Reader agent (regardless of the underlying reader device type) is controllable by such a panel. Through the clever use of GUIPanels and agent typing, one can develop a common look-and-feel for an entire class of devices, such RFID readers or RFID tag printers.

Figure 6: Architectural GUI SupportFigure 7 shows the GUIPanel from an actual application (our TagCentric RFID middleware application). On the left is a tree-based list of currently active agents, organized into agent types. On the right is the GUIPanel for the currently selected agent (an RFID reader agent).

Figure 7: GUIAgent from TagCentric ApplicationTagCentric RFID Application Architecture

Our initial goal was to be able to gather tag-read information from RFID readers and deposit the information into a user-specified database. This meant that we needed to be able to communicate with a number of different reader types and a number of different databases. Belatedly, we also realized that we needed to support RFID tag printers since you cannot read tags if you dont print them first! At present we support

Three popular types of RFID tag readers: Symbol, Thingmagic and Alien. These were a challenge because they all presented different native application program interfaces (APIs).

Several relational database management systems: Derby, Oracle, DB2, MySQL, Sequel Server and Postgres. Using JDBC helped standardize our interface to these database systems.

One popular RFID tag printer: Zebra

The TagCentric application architecture consists of RFID-specific classes derived from the Agent, GUIPanel, and MessageBody abstract classes.

Messages

The first step in designing a TagCentric agent is to decide what messages it needs to be able to send and receive. Figure 8 shows the messages that we support in our TagCentric application. For brevity, we omit the attributes and operations of the classes in this diagram.

Figure 8: TagCentric Message ClassesHere is a brief description of each message:

Readers:

ReaderOn Start emitting tag-read information

ReaderOff Stop emitting tag-read information

ReaderStatusRequest I want to know your current status

ReaderStatusUpdate Here is my current status

TagDataList Here is some tag-read data. Tag data includes the tag number, a timestamp associated with the read event, and the ID of the reader which read the tag.

Printers:

PrinterStatusRequest I want to know you current status

PrinterStatusUpdate Here is my current status

PrintTags Start printing RFID tags

Database:

DBStatusRequest I want to know your current status

DBStatusUpdate Here is my current status

DBInitialize Initialize or update your schema

DBCmd Perform the given command

DBQuery Perform the given query

Agents

Figure 9 shows a UML representation of the Agent-derived classes in our RFID middleware application.

The abstract ReaderAgent class provides some common logic used across all readers and (through the use of abstract methods) dictates that all ReaderAgent-derived classes must properly respond to ReaderOn, ReaderOff, and ReaderStatusRequest messages. In addition to providing agents for Symbol, Alien and Thingmagic readers, we provide a synthetic reader agent (FakeReaderAgent), which is useful for testing when one cannot access a real reader.

Similarly, the abstract PrinterAgent class provides some common logic used across all printer types, and also dictates that all PrinterAgent-derived classes shall support the PrinterStatusRequest and PrintTags messages.

Figure 9: TagCentric Agent ClassesWe chose to handle the database agent a little differently. Since so much of what a DBAgent does is the same across all database types, we chose to implement a single non-abstract DBAgent class, rather than deriving a class for each specific database (i.e., OracleDBAgent, AccessDBAgent, etc) . The DBAgent must respond to DBStatusRequest, DBInitialize, DBQuery, DBCmd and TagDataList messages.

User InterfaceFigure 10 shows the GUI-related classes associated with the TagCentric application.

The RFIDGUIAgent is the GUIAgent-derived user interface application for the TagCentric software (see Figure 7). This application is the primary means of user interaction with our integration software.

The AdminPanel and the TestPanel are local panels that do not correspond to any particular agent. The AdminPanel allows the user to manage reader and printer agent information, and to launch (or kill) the database agent or any number of reader or printer agents. The TestPanel allows the user to conduct RFID-related performance tests.

The ReaderPanel, DatabasePanel and PrinterPanel are displayed on demand, whenever a ReaderAgent, DBAgent or PrinterAgent (respectively) is activated. In Figure 7, two reader agents, one printer agent, and one database agent are active, and their respective panels are available for user interaction.

Note that there is only one ReaderPanel, and not one for each type of reader (i.e., AlienReaderPanel, SymbolReaderPanel, etc). This means that TagCentric will present the same user interface for all RFID readers. This greatly simplifies the use of the software for those facilities that support multiple reader types. The same general scheme will apply to tag printers when we support multiple tag printers.

Figure 10: TagCentric User Interface ClassesResults

As we go to press, TagCentric has been operational for a semester at the RFID Research Center at University of Arkansas. We have lately added user defined features like an easy-to-use install script, query histories, DBMS schema evolution, and documentation, and we have tested scalability with 10-20 readers of mixed types (a small warehouse). Our TagCentric software should be ready for open-source release in Fall 2006.

Future Work

We are planning a number of enhancements to both the Ubiquity framework and the TagCentric RFID application architecture, and we invite community contributions.

Ubiquity Enhancements:

Scalability. We plan to add support for enclaves of agents so we can scale our system from one installation to federated applications.

Security. We are interested in how fine-grained role-based access control can control which agents can task other agents.

Reflection. To support plug and play, when new agents enter and leave an environment, we need a way to publish an agents interface so other agents can discover this functionality. As an add-in to the architecture, we are also interested in associating domain-constrained natural language grammars with agents so humans can control them [4].

TagCentric Enhancements:

Routine enhancements. We will need to add support for smart tags, sensors, tag printers, and a common network-wide time. Our current middleware works with stationary readers but mobile readers (i.e., mounted on a fork lift or on a vehicle) are becoming important so our software will work for this case but a challenge is to add location awareness.

Analysis, Interoperability, and Intelligence. Users need a way to query tag data and provide results of queries to policy engines that watch for lost items and bottlenecks in the retail chain. They want their middleware to interface to their enterprise ERP systems. They also want their middleware to be intelligent to form deductions, like Tag B was not read by Reader Y, but Tag A was read by Reader Y, and Tags A and B are on the same pallet, so we can infer Tag B likely passed by Reader Y unread.

EPCIS Reference Implementation. EPC Information Services (EPCIS) is a specification for a standard aimed at enabling users to exchange EPC-related data with trading partners through a global network.

Observations

At the Microsoft Faculty Summit in Redmond in July 2006, one of the issues discussed was how to attract students to computing. One idea was to somehow engage students by expanding our definition of computer science to applications, thus connecting computing back into many other fields, e.g., computational X where X is biology, physics, linguistics, archaeology, etc. where much exciting work is going on. Fred Martin recently wrote an article entitled Toy Projects Considered Harmful [6] in which he argued that toy problems that do not matter (except for a grade) are de rigueur in de classroom but fail to give students the sense that their work matters.

Our RFID Middleware project is targeted at engaging students in real problems. For the last four semesters, it has engaged around 30 students in a team project that involves software design and development in an operational environment where results matter. Many aspects of the project become very real customer requests for functionality, upwards compatibility, stability, and testing, testing, testing. Students benefit because they build and test a part of something that is being used. They respond to evolving needs of the RFID Research Center. Companies are very interested in supporting and employing these students.

Even so, we face some challenges now and expect to face more in the future. Our current challenge is code development in the face of high turnover the average student spends 1-2 semesters working on the project so we have to assign them modular units of work. Having one lead designer with the project from the beginning has been invaluable. As we evolve from simply supporting the RFID Center to making our code open source in the Fall semester, we have experienced a flurry of activity on documenting and testing. To ease into this transition to open source, we will partner with some early adopters. We are unsure how open source will affect our resources so stay tuned, we will have an update soon.

References

[1]Radio Frequency Identification, Wikipedia, http://en.wikipedia.org/wiki/RFID

[2]Craig Thompson, Everything is Alive, Architectural Perspective Column, IEEE Internet Computing, Jan-Feb 2004.

[3]Craig Thompson, Smart Devices and Soft Controllers, Architectural Perspective Column, IEEE Internet Computing, Jan-Feb 2005.

[4]Craig Thompson, Paul Pazandak, Harry Tennant, Talk to your Semantic Web, Architectural Perspective Column, IEEE Internet Computing, Nov-Dec 2005.

[5]William Hardgrave, Matthew Waller, and Robert Miller, Does RFID Reduce Out of Stocks? A Preliminary Analysis, Technical Report ITRI-WP058-1105, Information Technology Research Center, 1 November, 2006. http://itri.uark.edu/research/display.asp?article=ITRI-WP058-1105

[6]Fred Martin, Toy Projects Considered Harmful, Communications of the ACM, Vol. 49, Number 7, July 2006, pp. 113-116 Biography

Craig W. Thompson is a professor and Charles Morgan Chair in Database at the University of Arkansas and president of Object Services and Consulting, a middleware research company. His research interests include data engineering, software architectures, middleware, and agent technology. Thompson has a PhD in computer science from the University of Texas at Austin. He is an IEEE Fellow. Contact him at cwt@engr.uark.edu.

Joseph E. Hoag received his MS degree from University of California at Davis. He worked at Lawrence Livermore National Laboratory, Philips Electronics, Orbital Sciences Corporation, Boeing, and as a contract software engineer before returning entering the PhD program at University of Arkansas. Contact him at jhoag@engr.uark.edu.R

R

R

R

R

R

R

R

R

R

R

R

Conveyor belt

Storage

Loading dock

Pallets

R

R

R

R = RFID Reader

Camera

Pallet/Container/Item

EMBED Unknown

In the XML diagrams in this article, bolded-italicized methods are abstract methods.

Draft for publication in

C. Thompson, Architectural Perspectives column, IEEE Internet Computing, to appear around Nov-Dec 2006.