Data EPC Acquisition System Middleware Device Manager: DEPCAS MDM

Data EPC Acquisition System Middleware Device Manager: DEPCAS MDM I. Abad, C. Cerrada, J. A. Cerrada, R. Heradio 1 Software Engineering and Computer Systems Department. UNED: Distance Learning University of Spain. Madrid. Spain Abstract - One of the main purposes of RFID middleware is to manage and hide the broad range of device readers existing in acquisition RFID networks. There are two basic solutions to override. First is to define a specification that should be accomplished for every RFID reader inside a network. The second solution is to define an abstraction layer that can translate proprietary protocols and specific characteristics from a vendor to a general solution. In this paper we present the Middleware Device Manager in our proposal of RFID middleware called DEPCAS: Data EPC Acquisition System. Keywords: Radio Frequency Identification, RFIT: Radio Frequency Information System, DEPCAS: Data EPC Acquisition System, SCADA: Supervisory Control and Data Acquisition 1 Introduction Radio frequency identification (RFID) is one of today's most rapidly proliferating technologies for enterprises. Based on the promise of lower operating costs combined with more accurate product and asset information, organizations are introducing RFID technologies in different productive and organization areas: tracking, supply chain, optimize stock levels, enforce tighter security, people surveillance and industry regulations [1] are examples of these uses. As enterprises explore these potential benefits [2], many are realizing that scaling from a pilot program to a production scale deployment is not a trivial exercise. Without careful planning, it is possible to destabilize business operations as huge volumes of RFID messages generated at the edge of the enterprise flood toward the data center. Over time, this problem could get magnified as RFID tagging at the item level becomes mandated competence pressures. Most existing application and network infrastructures were not designed with RFID in mind. At the edge, if RFID infrastructure is deployed on general-purpose servers that require installation and ongoing support, manageability problems alone might render RFID cost-prohibitive. In addition, without a unified deployment model of centralized control and distributed enforcement, disconnected areas of RFID infrastructure will grow, creating a familiar set of application and data integration challenges. On the network side, RFID implementations will generate large amounts of new data that will fan in from the edge of an enterprise toward its data center core, placing further demands upon the existing network. To optimize the use of available network bandwidth and simplify the deployment of RFID technology, solutions are needed to collect and filter raw RFID tag data close to its source and subsequently to correlate, aggregate, and transform this data into meaningful business-level events. These events in turn should be acted upon locally, where appropriate, or securely routed and delivered to back-end inventory management, sales, and financial applications. It is this "intelligent information" that will enable RFID-ready applications to deliver on their promise of increased operational productivity. The fundamental requirements of this type of middleware are related to the management of infrastructure device readers, the processing information received from auto identification, the business needs to incorporate auto identification and sharing of information [3]. To address these requirements, software architectures that implement this type of middleware proposed a set of layers that specialize in solving different requirements. These layers are based primarily on the architecture proposed by EPCglobal organization[4], including the resolution of a protocol for reading between the middleware and the tag reading devices, called LLRP (Low Level Reader Protocol) and higher RP (Reader Protocol) according to the standards [5] [6], an event process from the reading of RFID tags [7], an assignment of semantic information to the object through an RFID identification 1 This research has been carried out under contract with the Spanish CICYT through the DPI-2008-05444 project. It also belongs to the activities carried out in the fram of the Robocity2030-II excellence network of the CAM (ref. S2009/DPI- 1559)

service [8], and a service to receive or transmit information to business applications from the RFID middleware [9]. Primari/Uni v. Arkansas Rifidi Sensor Abstraction Layer Furthermore, the implementations include what is called generically device manager that allows the configuration and the management of every device incorporated to the RFID network. In this article we focus on this software component that is usually included in every RFID middleware and we present the alternative in which we are working for the development of our proposed architecture called DEPCAS (Data EPC Acquisition System). DEPCAS define software architecture for solving the RFID middleware based on system architecture for monitoring and control (SCADA) process. DEPCAS propose the scenario concept to generalize the process that can be performed from the acquisition of auto identification information. The processing of a scenario produces results that contain elements relevant to their semantic direct use in business applications. The graphical interface is called in DEPCAS GUV (Graphical User Viewer) and is designed to standardize access to the information managed in the middleware regardless of the scenario being driving. Henceforth this paper is structured as follows: Section 2 presents middleware device manager in existing proposals for middleware, which s are included and how they are integrated with other elements of the middleware, in Section 3 we presents the middleware device manager (MDM) defined in DEPCAS, in Section 4 we presents the MARC (Minimun Abstract Reader Commands) commands to manage different readers vendor inside a unique RFID network,, and finally the section 5 describes implementation prototype of RRTL (RFID Readers Topology Language) using MARC sentences developed in DEPCAS to solve MDM. 2 The RFID device management There are several existing RFID middleware implementations (Table 1): OSS RFID middleware as Fosstrak, Rifidi or Aspire, RFID middleware platforms as Sun Java System RFID software or WebSphere RFID system and RFID middleware proprietary as Detego RFID Suite Solution or OAT RFID Suite. Every of these solutions include a solution to infrastructure management with two main positions. One solution is to force the use of a specific protocol inside RFID reader s network while the other extreme is to accept any kind of reader and the middleware will provide bundle mechanism to uniform the devices. Table 1. RFID Middleware and Device Management Components Name Device Management AutoIDLabs Fosstrak LLRP Adaptor + HAL Adaptor Aspire Aspire Hardware Abstraction Layer Sun Micro Systems. RF-IT Solutions OAT Systems Sun Java RFID System v3.0 WebSphere RFID Detego OAT Foundation Suite RFID Execution Agent WebSphere RFID Device Infrastructure You-R Device Management OAT Device Manager The study of these different RFID Device Management components allows obtaining a set of characteristics that are implemented to solve it in the RFID middleware. Between these features we include: Device Agnostic. Configuration and parameterization of RFID devices. Topological RFID devices. Start-up Devices. Statistical and Report RFID devices data. Monitoring Devices in live operation Diagnosis of device in live operation LLRP implementation OSGi Technology These features and s define the operation of the middleware device manager in RFID middleware [10][11]. For example, Device Agnostic Feature is provided when middleware infrastructure acts as an integration point for RFID readers, printers, and other infrastructure devices, such as any sensors and actuators. RFID reader and printer manufacturers typically provide complex configuration options, proprietary interface languages, and communication protocols. If RFID Device Infrastructure eliminates the need for RFID integrators to be aware of these complexities and provides a device agnostic interface with which supported devices can be configured hiding the complexity. Other features are related to scope and technological implementation. Some of the middleware device manager support the EPC Global Network specification to connect with RFID Reader. The Low Level Reader Protocol standardizes a set of instructions to configure, send and receive reader information. In the technological side, several middleware device manager have used different software solutions. Between them, the OSGi Architecture is one of the most common specification framework used in our days. The OSGi specification enable components to hide their

implementation from others components while communicating through services. Next table shows the cross results between existing RFID middleware implementation and the device manager set of characteristics presented in this section (middleware logic manager) for auto-identification process, the GUV (graphical user viewer) or man-machine interface, and finally the EPCIS (EPC Information System) as software component to communicate with other systems. The main objectives of MDM are: Table 2. Middleware RFID/MDM Characteristics 2 FOSSTRACK RIFIDI ASPIRE SUN DETEGO OAT F.S. Manage the topology RFID reader s network. Agnostic management of different RFID vendors. Homogeneous process of different RFID tag reads. Support LLRP and ALE specification process. Provide configurable RFID network Hide operational environment Minimum tag management operations. Monitoring and controlling RFID readers.. Device Y N Y Y Y Y Y Agnostic Device Y Y Y N N Y Y Configuration Topological N N Y Y N Y Y Configuration Needs Y Y Y N N N N Programming Starting-up Device Statistical Data Y N Y N N Y Y from Device Monitoring Data N N N Y Y Y Y from Device Diagnosis Y N Y N Y N Y capabilities LLRP Implement. Y Y Y N N N N OSGi Technologies N Y Y N N N N 3 Middleware Device Manager in DEPCAS DEPCAS (EPC Data Acquisition System) is a proposed architecture for RFID middleware systems dedicated to data acquisition in real and heterogeneous environments. The scheme proposed is based on the supervisory and control systems known as SCADA (Supervisory Control and Data Acquisition). In this case, the remote terminal units in SCADA systems are replaced by the antenna-reader RFID systems to receive auto identification information. The communication networks are used to connect reader (communication via serial, Ethernet...) to the system Central acquisition software. The basic structure of DEPCAS is divided into four sub-systems: the MDM (middleware device manager) for the management of infrastructure, MLM 2 Y: Yes/ N: No To support these objectives the MDM definition includes the concept of Minimum Abstract Reader Commands (MARC) and the RFID Reader Topology Language (RRTL). The MARC allow to hide the particularities of every RFID reader vendor through a set of operations that are mapped to specific vendor API. The RRTP includes the description of RFID topologies including control and management of readers. The MDM core architecture prototype have been developed using TCP and HTTP for transporting reader protocol messages, while the message content can be either XML or Text. In addition, it support synchronous and asynchronous messaging (through the reader s protocol Notification Channels mechanisms). 4 Minimum Abstract Reader Commands (MARC) MARC is the minimum set of instructions that an RFID reader must supply to support the operational instructions inside a network. The set of MARC is closed and give an independent layer of RFID management. The implementation of MARC is related to RFID reader API and gives a dependent hardware layer. The commands included in MDM are described in Table 3: Table 3. MARC Commands MARC setantennasequence setautofalseoutput setautofalsepause setautomode setautostarttrigger setautostarttimer Operations Set an order sequence to read from multiple antennas installed in one reader mode to ignore tag reads mode to pause working Start/Stop autonomous reader s Activate the trigger sending s in reader autonomous Activate periodic timer reader

setautostoptimer setautostoptrigger setautotrueoutput setautotruepause setconnecttcp setnotifyaddress setnotifyformat setnotifytime setpassword setrun settagtype settime setusername in reader autonomuos Reset periodic timer reader in reader autonomous Reset the trigger sending s in reader autonomous mode to process tag reads mode to start reading process Establish a TCP connection Init a listening TCP port to instruct the reader to send notification messages Configure the format message to be used by the reader Establish the period that the reader notifier should use Identify the password reader access Start to execute a configuration reader mode Establish the expected tag type property Synchronize reader time Identify the user reader access The RRTL definition is supported by an XSD squeme and the results with XML files. An example of some RRTL commands is shown in figure 1: The MDM prototype includes MARC implementation for RFID reader ALIEN8780, FEIG2000, SKYWRAEM2 and we are working in MARC implementation for ThingMagic Mercury 4, Intermec IF61 and Impinj Speedway R420. 5 RFID Reader Topology Language (RRTL) RFID Reader Topology Language (RRTL) is a language to define RFID network topologies that includes control and management of RFID devices. The language manages the process and filter of tag reads to uniform them to DEPCAS system. The RRTL command could be classified by their application: 1. Resource definition. 2. Time management. 3. Conditional configuration 4. Tag management 5. Device management 6. Control and flow configuration 7. Database management 8. Web service control 9. File management 10. Tag position and code management 11. Process synchronization 12. User commands There are a set of miscellaneous sentences that are related with different kind of operation like start/stop operation, locks, etc. Figure 1. RRTL Reader Command Example One simple topology with RRTL commands is shown in fig. 2: Figure 2. Topology example

The RRTL commands for XML data for FEIG configuration in this example is: <?xml version="1.0" encoding="utf-8"?> <system-spec xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:nonamespaceschemalocation="rfid_loader_master_rrtl_esp.xsd"> <resource> <timer-job chain="test" name="alien_8780_0"> <time-span milliseconds="1000" / <timer-job chain="test" name="feig_lrua_2000_0"> <time-span milliseconds="1000" /> <timer-job chain="test" name="skyeware_m2_0"> <time-span milliseconds="1000" /> <file name="datafile" filename="c:/uned/mdm/datafile.mdm" append="true"newline-style="windows" /> </resource> <reader driver-class="mdmfeiglru2000setup" type-class="mdmfeiglru2000setup" name="feig_lrua_2000_0" organization="uned" campus="madrid / Univ.EDE" address="c/ Juan, 28040-MADRID" dept="issi" location="planta: 1, Desp: 112" use="test" auto-mode="true" auto-interval="1000" auto-chain="test" > <arg>192.168.1.35</arg><arg>10001</arg><arg>feig</arg> <arg>password</arg> <property> <key="setnotifyaddress"/ <value="localhost:9002"/> </property> <property key="settagtype" value="*" trim="false" /> <property key="setnotifyformat" value="xml" /> <property key="settime" value="2008/12/31" /> <property key="setnotifytime" value="1"/> <property key="setantennasequence" value="1,0,0,0"/> <property key="setautomode" value="1"/> <property key="setpolling" value="500" /> <property> <key="setconnecttcp" value="192.168.1.35:1001"/> <property key="setusername" value="feig" /> <property key="setpassword" value="password" /> <property key="setrun" value="1"/> </reader> <chain name="test"> <poll generate-empty="false" reader="alien_8780_0" /> <poll generate-empty="false" reader="feig_lrua_2000" /> <poll generate-empty="false" reader="skyeware_m2_0" /> <purifier period="1000" reads="2" generateempty="false"/> <echo message="reading tag...id=${tagid}" /> <transfer resource="rmi to DBMonitor.java" forward-resource="localhost:3232"/> </chain> </system-spec> point (antennas, edge readers, reader, PLCs with RFID readers, etc.) or redundant reader points. This two main subject are covered in or solution of DEPCAS MDM, one with the use of MARC to hide device management or standardization protocols and topological questions with RRTL to express network configuration. About future works there are different issues to be resolved. First, we want to extend the MARC ality to new devices as Intermec IF61, Impinj Speedway R420 or Siemens RF6660A. Second there are other topological concepts to work in with RRTL as tag tables, conditional operations master/submaster and peer to peer network reader organizations, etc. 7 References [1] R. Russell, Manufacturing Execution Systems: Moving toi the next level, Pharmaceutical Technology, January 2004, pp 38-50. [2] H. Ramamurthy, B.S. Prabhu, Rajit Gadh. ReWINS: A distributed multi-rf Sensor Control network for industrial automation, IEEE Wireless Telecommunications Symposium (WTS 2005), Pormona, California, 2005. [3] Xiaoyong Su, Chi-Cheng Chu, B. S. Prabhu, Rajit Gadh, On the creation of Automatic Identification and Data Capture infrastructure via RFID and other technologies The Internet of Things: from RFID to the Next-Generation Pervasive Networked Systems, Lu Yan, Yan Zhang, Laurence T. Yang, Huansheng Ning (eds.), Auerbach Publications, Taylor & Francis Group, 24 pp., 2007. [4] Brewer, A., Sloan, N. and Landers, T.L., Intelligent tracking in manufacturing. Journal of Intelligent Manufacturing. v10 i3. 245-250. 1999 [5] C. Floerkemeier, C. Roduner, and M. Lampe, RFID Application Development with the Accada Middleware Platform. IEEE Systems Journal. 2007 [6] Q.Z. Shenz, X. Li, S. Zealdally, Enabling next-generation RFID applications: Solutions and challenges. Computer, Col 41, Issue 9. 2008. [7] M C. Bornhövd, T. Lin, S. Haller, and J. Schaper, Integrating Automatic Data Acquisition with Business Processes - Experiences with SAP s Auto-ID Infrastructure. In Proceedings of the 30st international conference on very large data bases (VLDB). Toronto, 1182 1188. 2004. [8] Curtin, J. Kauffman, R.J., Riggins F.J., Making the MOST out of RFID Technology: a research agenda for the study of the adoption usage and impact of RFID, Springer Science+Business Media. Abril 2007. [9] N. Kefalakis, N. Leontiadis, J. Soldatos, D. Donsez, Middleware Building Blocks for Architecting RFID Systems, Mobile Lightweight Wireless Systems, Vol 13, pp 325-336. August 2009 [10] Wells,A.: RFID Detail, IMPO Magazine, Advantage Businness Media. June 2009 [11] EPC Information Services (EPCIS), EPCGlobal, version 1.0.1, 2007 [12] J. Han, H. Gonzalez, X. Li, D. Klabjan. Warehousing and Mining Massive RFID Data Sets, ADMA 2006: 1-18. 2006 6 Conclusions Regarding the development of MDM for RFID, there are two main focuses. One is to build an agnostic RFID device acquisition system in the same time it accomplish the existing standard proposals. The other one is how to manage topological RFID network questions like RFID levels reader