In these domains RFID technology holds the promise to ... manual inventory counts, and the automatic detection of empty shelves and expired products in retail ...
LIT Middleware: Design and Implementation of RFID Middleware Based on the EPC Network Architecture Ashad Kabir, Bonghee Hong, Wooseok Ryu, Sungwoo Ahn Dept. of Computer Engineering, Pusan National University, Republic of Korea e-mail: {makcse,bhhong,wsryu,swan}@pusan.ac.kr
Abstract Radio Frequency Identification (RFID) technology can be used to significantly improve the efficiency of business processes by providing the capability of automatic identification and data capture. RFID system must implement functions to posses the enormous event data generated quickly by RFID readers. The proliferation of RFID tags and readers will require dedicated middleware solutions that manage readers and process event data. In this paper, we describe our middleware (called LIT Middleware) architecture with key features and also illustrate overall functional components of the middleware software as well as the system framework. Our component based middleware architecture provides extensibility, scalability and abstraction, and is also compatible with EPCglobal standards.
1 Introduction RFID technology uses radio-frequency waves to transfer data between readers and movable tagged objects, thus it is possible to create a physically linked world in which every object is numbered, identified, cataloged, and tracked. RFID is automatic and fast, and does not require line of sight or contact between readers and tagged objects. RFID systems have recently begun to find greater use in industrial automation and in supply chain management. In these domains RFID technology holds the promise to eliminate many existing business problems by bridging the gap between the virtual world of IT systems and the real world of products and logistical units. Common benefits include more efficient material handling processes, elimination of manual inventory counts, and the automatic detection of empty shelves and expired products in retail stores [1]. However, not only the business community that can benefit from the use of RFID tags, but also the consumer. The magic medicine cabinet [10], the magic wardrobe, and the often-cited fridge are some of the applications in which the consumer would benefit from these smart products. The widespread adoption of RFID requires not only low cost tags and readers, but also the appropriate networking infrastructure. To facilitate application development H.-D. Haasis et al., Dynamics in Logistics DOI: 10.1007/978-3-540-76862-3, © Springer 2008
221
222
A. Kabir et al.
even further, RFID infrastructure can also feature another component that consumes the events delivered by the middleware, combines the RFID data with application logic, and generates application-level events. The concept of a distributed networking infrastructure for RFID was initially proposed by the Auto-ID Center, an industry sponsored research program to foster RFID adoption, which coined the term Electronic Product Code (EPC) Network. Sun Java System also provides RFID software architecture for enabling the EPCglobal Network [2]. Java System RFID Software consists of two major components – The Java System RFID Event Manager and the Java System RFID Information Server. Oracle sensor based services offers a complete sensor based computing infrastructure for capturing, managing and responding to RFID and other sensor data implemented in the physical environment [3]. In this paper, we have analyzed those requirements the RFID middleware component should meet in order to manage large deployments of heterogeneous readers and the amount of data those readers capture. The main contribution of this paper is designing software component for RFID middleware, which addresses both application needs and the constraints of RFID technology. We called our middleware as Logistics Information Technology (LIT) Middleware. This paper is organized as follows. In Sect. 2, we review the EPCglobal network architecture relevant to our work. In Sect. 3, we describe features of our middleware. In Sect. 4, we illustrate implementation of LIT middleware with software architecture. We conclude in Sect. 5 with avenues for further research.
2 Overview of EPC Network Architecture The EPC Network, originally developed by the Auto-ID Center with its standards now managed by EPCglobal Inc. (also named shortly EPCglobal) [5], was designed to enable all objects in the world to be linked via the Internet. The EPC Network is built upon many fundamental technologies and standards. Figure 1 shows the structure of typical EPC Network [7] proposed by EPCglobal. In this paper, we focus on Application Level Events (ALE) and EPC Information Services (EPCIS), and consider both of them as RFID Middleware. In the rest of this section, we shortly discuss ALE and EPCIS. The EPC Network Architecture defines an interface through which clients may obtain filtered and consolidated EPC data from a variety of sources. This interface and functionality within the EPC Network Architecture are called ALE. The processing done at ALE typically involves: (1) receiving EPCs from one or more data sources such as readers; (2) accumulating data over intervals of time, filtering to eliminate duplicate EPCs and EPCs that are not of interest, and counting and grouping EPCs to reduce the volume of data; and (3) reporting in various forms. The role of the ALE interface within the EPC Network Architecture is to provide independence among the infrastructure components that acquire the raw EPC data, the architectural component(s) that filter and count EPC data, and the applications that use the data [8].
LIT Middleware: Design and Implementation of RFID Middleware
223
Fig. 1 RFID Middleware on the EPC Network Architecture
The EPCIS provides a uniform programmatic interface to allow various clients to capture, secure and access EPC-related data, and the business transactions with which that data is associated. The goal of EPCIS is to enable disparate applications to leverage EPC data via EPC-related data sharing, both within and across enterprises. EPCIS Accessing Application is responsible for carrying out overall enterprise business process, such as warehouse management, shipping and receiving, historical throughput analysis, and so forth, aided by EPC-related data. EPCIS Capturing Application supervises the operation of the lower EPC elements, and provides business context by coordinating with other sources of information involved in executing a particular step of a business process [6].
3 Features of LIT Middleware Our LIT Middleware considers the concept of ALE and EPCIS. In the rest of this section, we have summarized the key features of our middleware on the basis of ALE and EPCIS.
3.1 Features of ALE High Performance and Scalability RFID Middleware can have many applications, queries and readers. These criteria increase query processing time and also network traffic. RFID middleware should
224
A. Kabir et al.
have ability to handle many applications, queries and readers. Hence, we have implemented Duplication Removal technique for eliminating duplicate data and ultimately reducing network traffic. We also implemented Continuous Query Process and State Based Execution for high performance. Continuous Query Process RFID data is usually regarded as the streaming data which are huge, because they are gathered continuously by many readers. RFID middleware filters those data to process queries which applications request. The EPCglobal proposed ALE specification which mention Event Cycle Specification (ECSpec) and Event Cycle Report (ECReport) as the standard of interface for the RFID middleware. ECSpec is a specification for filtering and collecting RFID tag data and is treated as a Continuous Query (CQ) process during fixed time interval repeatedly. ECReport is a specification for describing the results of ECSpec. Figure 2 shows the architecture of CQ processing. In CQ processing, first application requests query through ECSpec to CQ Manager. CQ Manager builds query index (representing query using spatial data structure that improves the speed of operation) on the basis of query request. Reader interface continuously receives EPC data from RFID readers and evaluate queries using query index. Finally, send the result to user or application through CQ Manager. Duplication Removal Technique RFID Middleware receives EPC codes from readers. As tag reads are flowed into the middleware, there are a lot of noises and duplicate reads, so filtering operation is used to eliminate that redundant information, called duplication removal technique. During request query, user or application also mention time duration of each query. ALE treats this duration as Event Cycle. During each Event Cycle RFID readers can read same tag many times. Duplication removal technique removes those duplicate data. State-based Execution In our continuous query processor, we use state-based execution model instead of thread-based execution model [4]. When the number of thread is large, the thread-based execution model incurs significant overhead due to cache misses, lock contention, and switching. On the other hand, state-based execution model is a single scheduler thread that tracks system state and maintains the execution queue. The execution queue is shared among a small number of worker
Fig. 2 Continuous Query Processing in LIT Middleware
LIT Middleware: Design and Implementation of RFID Middleware
225
threads responsible for executing the queue entries. This state-based model avoids the limitations of the thread-based model, enabling fine grained allocation of resources according to application specific targets.
Abstraction and Extensibility Reader Abstraction and Extensibility There are many vendors of RFID Readers. Our system is independent from types of RFID Readers and vendors and also provides extensible architecture for new type of RFID reader. We used Common Reader Management Interface to manage heterogeneous RFID reader and also used UNIX device driver and Jini architecture concept, which can add new adapter at run time. We also used logical reader mapping which provide independence from number and arrangement of RFID readers. Application Abstraction There are many types of applications those use RFID middleware. Our system provides independence from different types of application using Common Application Interface and Common Application Query. We used common application interface provided by EPCglobal, which are Tag Memory Specification API, ALE Reading API, ALE Writing API, ALE Logical Reader API and Access Control API [8]. We also used common application query (ECSpec) provided by EPCglobal and standard format (e.g., XML) and standard protocols (HTTP, FILE and TCP).
3.2 Features of EPCIS High Performance The question of performance has always to be seen in relation to the questions of response time. In case of only few requests or queries to be processed, too much care about performance is not necessarily required. Having thousands of queries to be processed (in a short period of time) requires a well designed system, being able to bear the burden. We used CQ Index Technique to process enormous query efficiently. For track and trace query, we have implemented Fixed Interval R-tree [9]. Fixed Interval R-tree proposed new indexing, insert and split policy to process queries efficiently. It used to trace trajectories as well as monitor present locations of the tags. A tag trajectory is represented as a line by connecting two spatiotemporal locations captured when the tag enters and leaves the vicinity of a reader.
Abstraction and Extensibility Our system is persistent and compatible to store different types of EPCIS event and also support commercial legacy database (Oracle, MSSQL, MYSQL etc.). Hence,
226
A. Kabir et al.
Fig. 3 Data Source Access Component
we designed Data Source Access Component as shown in Fig. 3. It consists of Data Source Access Interface and Data Provider. Using interface different components of EPCIS can interact with legacy database. Using data provider, we can access various types of data sources. Different types of applications use EPCIS. EPCIS provide independence from different types of applications and platforms by supporting standard query interface (EPCIS query interface) proposed by EPCglobal [6]. It also uses standard data format (e.g., XML) and standard communication protocol (HTTP, TCP and WSDL). EPCIS also provide extensible architecture. That is, it support new EPCIS event (e.g., Sensor Event, e-Seal Event) by extending XSD and WSDL.
4 Design and Implementation of LIT Middleware Figure 4 shows the ALE Software architecture. It consists of four layers: Application Abstraction Layer, State-based Execution Layer, Continuous Query Layer and Reader Abstraction Layer. Application Abstraction Layer provides RFID data access via web-based ALE API by using JAX-WS. Our application also uses different types of logger (TCP, HTTP and FILE) to send result (ECReport) to subscriber. State-based Execution Layer is overall controller of middleware. It consists of controller, scheduler, query manager, reader manager and Thread Pool. Controller initiates different modules and manages whole system. Scheduler is thread based class used to manage schedule of middleware. Query manager stores and manages the query information. Reader manager keeps information of logical and physical reader mapping and makes the upper layer independent from the change of the physical reader configurations. The primary role of Reader Abstraction Layer is to support seamless link between the middleware software and various types of RFID readers. This component
LIT Middleware: Design and Implementation of RFID Middleware
227
Fig. 4 ALE Software Architecture
abstracts the tag read protocols, supports various types of reader devices and allows users to configure, monitor and control all these devices. It supports XML-based reader control methodology to control reader specific features. The functions of Continuous Query Layer are collecting, filtering and removing duplicate EPC data. Figure 5 shows the software architecture of EPCIS. It consists of three layers. Query Service Layer consists of query control component and standard query inter-
Fig. 5 EPCIS Software Architecture
228
A. Kabir et al.
Fig. 6 Management GUI of LIT Middle- Fig. 7 Client GUI of LIT Middleware ware
face that is independent on application program. Repository Layer consists of Query Processing Layer (here we implemented CQ Technique and Fixed Interval R-Tree), Data Access Layer (here we implemented Data Source Access Component) and Database Layer (consists of Legacy DB). Capturing Service Layer consists of event queue and capturing interface that gather information from ALE. We have implemented our system using several software tools: JAVA (JDK 5.0), Tomcat Web-server (version 6.0), and Smart UML (version 5.0.2). We have tested our system using RFID devices from several vendors such as Alien and Intermec. Figure 6 is the Management GUI of LIT Middleware, used to manage ECSpec and logical reader. Figure 7 is the Client GUI of LIT Middleware, used to query in EPCIS Repository.
5 Conclusions In this paper, RFID-based system called ‘RFID Middleware’ is examined and recently ratified EPCglobal de-facto standard interface for RFID middleware, ALE and EPCIS are also discussed. Then, the RFID-based middleware system which is compatible with the ALE and EPCIS standard is introduced with internal architecture. The nature of RFID system, requiring distributed network architecture, drives the requirements for common interface to let various applications have access to RFID tag data in a standardized way and such requirements bear ALE and EPCIS specification. In this paper, we have analyzed the features of our middleware which is compatible with ALE and EPCIS specification, and also summarize its architecture and functional operations. Future research includes requirements analysis, and implementation of Middleware for RTLS and Sensor Network. Acknowledgements “This work was supported by the Korea Research Foundation Grant funded by the Korean Government (MOEHRD – Ministry of Education and Human Resources Development)”.
LIT Middleware: Design and Implementation of RFID Middleware
229
References Alexander K, Gilliam T, Gramling K, Kindy M, Moogimane D, Schultz M, Woods M (2002) Focus on the supply chain: Applying auto-id within the distribution center. Technical Report IBM-AUTOID-BC-002, Auto-ID Center A Technical White Paper (2005) The Sun Java™ System RFID Software Architecture. www.sun.com An Oracle White Paper (2006) Enterprise Information Architecture for RFID and Sensor-Based Services, www.oracle.com Carney D, Çetintemel U, Rasin A, Zdonik S, Cherniack M, Stonebraker M (2003) Operator Scheduling in a Data Stream Manager. 29th VLDB Conference, Berlin, Germany, pp 838–849 EPCglobal Inc. http://www.epcglobalinc.org EPCglobal Inc. EPC Information Services (EPCIS) Specification. Working Draft Version 1.0, June 8, 2005 EPCglobal Inc. EPCglobal Architecture Framework. Final Version July 1, 2005 EPCglobal Inc. The Application Level Events Specification. Working Draft Version 1.1, July 13, 2006 Ahn S, Hong B, Ban C, Lee K (2006) Design and Implementation of an Index Structure Using Fixed Intervals for Tracing of RFID Tags. ICCSA, LNCS 3981, pp175–185 Wan D (1999) Magic medicine cabinet: A situated portal for consumer healthcare. In Proceedings of the International Symposium on Handheld and Ubiquitous Computing, Karlsruhe, Germany
