A Novel Large-Scale RFID Integration Architecture Based on SOA for Supply Chain Logistics Management

Transcription

1 20IO International Conference on Computer Application and System Modeling (ICCASM 2010) A Novel Large-Scale RFID Integration Architecture Based on SOA for Supply Chain Logistics Management Zhao Wen 1, 2, Wang Zhengfang 2, Ku Tao 2, l Graduate School of the Chinese Academy of Sciences, Beijing, China 2 Key Laboratory of Industrial Informatics, Shenyang Institute of Automation, CAS, Shenyang, China zhaowen@sia.cn Abstract-A novel SOA-based Architecture for large-scale deployment and integration of RFID devices at the edges of network was proposed, which implemented device agnostic to upstream layers and Seamless connectivity between the heterogeneous systems. The results of prototype platform applied in supply chain logistics management system show that the proposed architecture has remarkable performance both in flexibility and scalability. Keywords- Device Integration; Device Management; SOA I. INTRODUCTION lot (Internet of Things) has becoming academia focus and industry attention since it was proposed by MIT [I]. Doubtlessly, since the concept of IOT is put forward deriving from the research of creating a global system for tracking goods using EPC, supply chain logistics management is the most promising field for the large-scale applications of lot. Through RFID readers and other relevant sensors, we can identify and monitor the physical objects in the real world automatically and share the information easily, hence achieve increased visibility and efficiency throughout the supply chain and higher quality information flow between companies and their key trading partners [2]. With increasing of RFID applications, large-scale deployments of physical hardware have highlighting a great deal of challenges. Device integration, which is the bottom layer and core function in Enterprise systems, is becoming an issue. Firstly, there exist at least three standards applied in different fields and areas, but still no global RFID standards. The Enterprise systems have to deal with the complexity in order to support all of the underlying standards. Secondly, Hardware vendors usually provide their products with their proprietary access interface. As a result, the primary problem for the RFID applications to be solved, especially the largescale applications such as supply chain logistics management, is how to integrate disparate devices into the software system seamlessly. And finally, this situation becomes much more complicated when supply chain logistics management applications comprising numerous RFID readers, barcode scanners, sensors and printers from different vendors. So it is very important to find an efficient way to deploy and manage large numbers of devices from perspective of network administration. Meanwhile, the concept of SOA has gained significant attention in just a few years because of its flexibility and compatibility during the phases of systems development and integration. SOA provides a loosely-integrated suite of services used within multiple business domains and particularly significant for the device integration. As more and more Enterprise system and middleware are involved and implemented with SOA-based architecture, the layer for devices accessing, which is usually the bottom of middleware, is tend to be abstracted to an independent service platform integrated multiple devices and delivers data to upstream layers of system. In this paper, we propose a SO A-based architecture for integration, deployment and management of large-scale devices at the edges of network. The proposed architecture implements device agnostic to upstream layers by providing a unified interface, and makes the disparate hardware and software connected seamlessly by hiding the complexity of diverse standard complaint tags and individual reader idiosyncrasies effectively. Beyond that, in consideration of the deployment and management of large number of devices comprised in the Enterprise applications, we propose a novel solution by introducing another standalone server besides the edge server. This SOA-based architecture is intended to be suitable for supply chain logistics management application, as well as other large-scale distributed application. The rest of this paper is organized as follows. In Section II, related work is described. In section Il l, we discuss the requirements of our platform. Section IV presents the device integration platform architecture. Finally, Section V concludes the paper. n. RELATED WORK As the bridge between hardware and software, device integration has been widely studied. In order to support different readers, almost all the proposed RFID middleware architectures introduce a specialized component named HAL (Hardware Abstract Layer). Paper [3] is a typical case. The basic idea of HAL is to define a hardware abstraction interface that is used to access RFID readers and implement it for various reader devices and reader simulators. Through HAL interface, the higher layers beyond HAL could interact with devices indirectly. But this binding also limits HAL interface to be a system proprietary component and could not be interchangeable between different systems. Currently, the integration of RFID standards is an active research field. The universal standard of RFID has not yet emerging. So an urgent problem to be solved in the supply chain logistics is the tag data conversion when one object with a specific tag moves across different RFID systems /10/$ IEEE V4-290

2 TOT (Tag Data Translation) is responsible for the translation of tag IDs into different formats, which has been fully discussed in [4]. The deployment and management of RFID devices are also research focus. As shown in [3] [5] [6], different middleware has different strategies depended on their specific scenarios. Hence, the solution is inevitably binding to the architecture. Software giant companies such as Oracle and IBM also provide many RFID solutions. Oracle SES (Sensor Edge Server) is a component of Sensor-based Services, which supports RFID readers, sensors and response devices at the edge of the system infrastructure. It provides functionalities of data collection, data dispatcher, as well as device management, such as installation and status monitor [5]. Though Oracle SES could administrate the devices by a centralized admin console, the biggest problem lies that it doesn't support hot-deploy, which means that once a new device added into the edge, it has to restart to install. On the contrary, IBM proposes a more flexible architecture based on OSGi technology known as WRDI (WebSphere RFID Device Infrastructure) [6]. WRDI is an open standard based middleware platform implemented by IBM services partners, rather than IBM itself. The great drawback is that it comes pre-installed on OEM devices through an IBM authorized OEM Business Partner only. In another word, you have few choices about the devices involved. What's more, it is designed only for embedded devices, which excludes a lot of other type's devices. The problem of device integration is mostly handled as part of global architecture and laid to be the bottom layer before SOA becomes in vogue. Realizing the great advantage of SOA paradigm, more and more middleware architectures adopt this idea [7]. To provide a looselyintegrated suite of services, the functions of each module are abstracted more clearly and designed as independent services. Thus device integration is provided as a standalone platform in SOA-based architecture. Differing from most of the past work [8], our platform is not only contained with smart embedded devices, but also "dumps" devices. III. DISSCUSSION Firstly, we should make clear the role of our platform in a common RFID enterprise system. Supply chain logistics is comprised by thousands of logistics nodes, such as public warehouse, logistics parks, ports, railway freight station, and highway hub. The Enterprise IT infrastructure deployed over it inevitably becomes huge complex and heterogeneous large-scale distributed system. Our device integration platform is designed as the infrastructure's edge and responsible for interconnection with hardware directly. Next, we must seriously take account of devices to be used as edge server to host our platform in the network infrastructure, because this will influence our platform architecture heavily. Our platform is flexible, lightweight, and component-based, and it could be deployed on many memory constrained devices. The edge server could be as follows: Computers: A computer could connect hardware through different communication methods, network Ethernet, serial lines, etc. Edge Controllers: An embedded device with adequate processing power and memory discussed in [6]. It is capable of hosting a variety of embedded applications and is capable of interacting and controlling RFID readers, printers, and any other infrastructure devices. Smart Readers: This type reader has additional capabilities to host embedded applications, which just can be considered as embedded device. Others: Some similar embedded device, such as PDA, smart phone. The types of device to integrate should also pay more attention. The type and capability of RFID readers currently available in the market have been fully discussed in [9]. Broadly speaking, RFID readers could be divided into two classes: those which are smart with additional capabilities to host embedded applications, and those which are only providing base services. The methods of communication with RFID readers are also various, network cables, serial lines, etc. In addition, the types of sensors also should be considered. They are often used to control actuators as triggers or monitor the parameters of the environment, sometimes also used for locating the accurate position of objects. Another important device is barcode scanners, which is usually given little attention in RFID systems. RFID tag has not completely replaced barcodes now, and so in the future, due in part to their higher cost and the advantage of multiple data sources on the same object. Since barcodes are still widely used, barcode scanner would be an important part of our device integration platform. On the basis of above discussion, the services offered by our platform follow: Support different kinds of devices to make the disparate hardware and software connected seamlessly. RFID reads, barcode scanners, sensors, printers will be included. Support most of the current tag formats. Format translation between different RFID standards and barcodes is supported. Provide device deployment and configuration through a centralized administration console. Device status monitor is an additional. Provide early data process. The raw data captured from devices will be filtered and aggregated before dispatched to upstream layers. The principles and features of design follow: Device agnostic: This is the main feature to be realized in our paper. Hot-deploy: When installing a new device, updating an old device, or reconfiguring a runtime device, the edge server should not have to restart. Scalability: The system should be scalable to deal with those new devices not included before. Standard compliant: The platform is compliant to the main reader and tag standards. V4-291

3 Platform independence: Our platform is designed to run standalone and could be reused in other middleware. Modularization and SOD (service-oriented design): This principle ensures loosely coupled among different components. IV. A. Architecture Overview SYSTEM DESIGN To implement the function requirements and design principles discussed in previous section, we propose a novel architecture based on Web Service and OSGi (Open Service Gateway Initiative) technology, which are all realization framework of SOA thinking. Web Services seem like most suitable to heterogeneous systems. However, the OSGi architecture provides with an open, lightweight, and easy-todeploy component mode. Its pluggable, dynamic changeable characteristics meet demands such as dynamic expansion and modification to the system functions as well as the change of system behaviors [10]. Therefore, they can excellently satisfy our demand. To be an independent platform, the interface provided for invoker of higher layer should be standard-compliant. EPC standard is one of the extensively accepted specifications, which is specifically designed for supply chain logistics management [2]. In the light of the popularization of EPC, our architecture is EPC-compliant. Figure 1 shows that the SOA-based device integration platform generally incorporates three subsystems: Edge Server Core, Edge Server Administration, and Device Driver Reposito r y. ::.....:: ---_ Upper La'ers Core could be deployed on the edge server discussed In previous section. 1) HAL Module: To implement device agnostic to upstream layers by providing a unified interface, makes the disparate hardware and software connected seamlessly. Thus it's crucial for the whole architecture. In the view of tremendous heterogeneous between different device types, instead of just one general unified interface for all hardware, our HAL is comprised by different interfaces for different device types: RP (EPC Reader Protocol) and LLRP (Lower Level Reader Protocol) for RFID readers, BAI (Barcode Scanner Abstract Interface) for barcode scanners, and SAl (Sensor Abstract Interface) for sensors. This is different from most of the existing middleware frameworks which also introduce HAL conception. We choose EPC specifications as the unified interface for RFID readers, rather than design our own. Because we don't think it's a wise way to propose a private HAL interface in each framework, since it only could be worked well for the middleware itself but without interchangeability for others. 2) RFID Reader Connection Module: To integrate diverse RFID Readers into the platfrom DcvlteJ)rm:r Rq>OSliory 5t 8 Jk"",el>" <:r RqIOSIlOI)' Rerr:ote Server Figure 1. F.dj;C'Sn_ Admon'SI""QIl \ 1 B. Edge Server Core j i,. H -.!,",III :! :_ t ' Edge Server The Architecture of Devices Integration Platfonn. Edge Server Core contains the core components of the platform. Each function is treated as a service in SOA thinking and implemented as OSGi bundles. Edge Server RFID Reader Connect ion ":odule Figure 2. The Framework of RFID Reader Connection Module. RFID readers could be simply divided into three classes: EPC RP-compliant readers, EPC LLRP-compliant readers, and non EPC-compliant readers. In order to access non EPCcompliant RFID readers through EPC protocol, we convert them into RP-compliant readers. RP reader proxy is the mediate between non EPC-compliant readers and RP interface. It ensures a graceful mapping of non EPCcompliant readers to EPC RP-compliant ones. To simplify this conversion, RAI (RFID Reader Abstract Interface) is defined. By implementing RAI, a proprietary adapter provided for each type of RFID reader can convert the non EPC-compliant reader into EPC-compliant one directly. In fact, it's no use to implement an adapter for each type of RFID reader. We only need to implement the proprietary access protocols of different vendors, such as BRI (Basic Reader Interface), which is the access protocol for a serial of Intermec RFID readers. This strategy also gives the platform more flexibility and expansibility. Once a new RFID reader is added, what has to do is just to develop a corresponding adapter implemented with RAI. What's more, in other V4-292

4 scenarios, you can exchange different kinds of RFID readers without to adjust other parts of the platform except their corresponding adapters. Besides, tag data integration is also in our consideration. We borrow ideas from the general TOT system proposed in [4], provide a TOT for translating any format of tag data into another once it is required. 3) Barcode Scanner Connection Module: To integrate diverse barcode scanners into the platfrom. Figure r ;a '\ AL! L.ac-"-'A -"' H \ ;/ Sensor Connection Module Barcode Scanner Connection Module The Framework of Barcode Scanner and Sensor Connection Module. The requirements for barcode scanner have been discussed in Section III. We define a single interface named BAI (Barcode Scanner Abstract Interface) to unify the way to access diverse barcode scanners. Through a corresponding adapter implemented with BAl, the platform hides the individual device idiosyncrasies. Besides, the general TOT is responsible for translating the barcode into EPC tag format. In this way, barcodes could be handled as EPC tag by the upper layers. 4) Sensor Connection Module: To integrate diverse sennors into the platfrom. Sensors are often used for locating the accurate position of objects or monitoring the parameters of the environment in supply chain logistics management, and sometimes they are often used as triggers to control actuators. We define a single interface named SAl (Sensor Abstract Interface) to unify the way to access diverse sensors. Through a corresponding adapter implemented with SAl, the platform hides the individual sensor idiosyncrasies. 5) RFID Reader WebService Module: To provide device-level service. With the development of smart device and SOA, it tends to deploy the networked embedded devices as a web service in distributed systems [8]. To meet this fashion trend, the device-level webservice is also offered as an option. 6) Data Integration Module: To integrate diverse data from hardware into EPC-compliant application level events. ALE-compliant (Application Level Event) is a basic and critical feature for EPC-compliant middleware. This module is intended to access hardware through HAL by a unified way and integrate the heterogeneous data into a specified ALE-compliant event report. In this way, the layer employed upper our platform could consume the data sent from the platform through ALE interface. 7) Data Process Module: To process data by filtering and aggregating. Generally, some tag data read from RFlD readers are "noise". Thus, duplicate tags or even bad read caused by network problem should be handled before sending to upper layers. Early data process will be more meaningful for largescale deployments to ease both the network overload and data process in upper layers. This module is compatible with the EPCglobal ALE specification and provides two services: data filtering and aggregating. By configuring the custom logical readers and filtering principles in ECSpecs, we can only aggregate the expected reports. This module is an option but strongly recommended. However, currently many smart RFlD readers also offer the same early data process. In that case, the reports generated in Reader Integration module could be sent by Data Dispatcher directly. 8) Data Dispatcher Module: To dispatch data reports to upper layers. This module is used to send reports as webservice. However, recognizing that many existing RFID systems are still use JMS for communication between different layers, the dispatcher can transmit the report to upstream layers by JMS protocol. The dispatcher manner could be configured by administration console. C. Edge Server Administration Console Edge Server Administration Console provides a userfriendly interface to deploy, configure, and administrate the whole Edge Server Core via JMX. Our design adopts plug-in structure based on OSGi technology. Each specific functional plug-in is encapsulated as an independent bundle. These components are divided into three groups on the basis of function: basic settings, physical device management, and data management. Among them, basic setting includes general server settings such as user access control. All of them will enable system consultants and/or users to easily build and deploy expected solutions. Though the layer beyond HAL could access hardware by a unified manner, the physical device configuration itself will be still vastly different. Physical device administration is involved with RFID reader configuration plug-in, barcode scanner configuration plug-in, and sensor configuration plugin. It enables the end users to configure the parameters of physical devices and monitor the runtime status of them. In contrast to the classes of RFID readers, there will be three components of RFID reader administration. One is used to configure RP readers, one is for LLRP readers, and the other is for RAI implemented Readers. For non EPC-compliant RFID readers, barcode scanners, and sensors, corresponding adapters are required. In large-scale systems, the management of numerous drivers and adapters will be another challenge task. To solve this problem, a download function from remote repository is equipped as a plus. This mechanism will be illustrated in detail later. Data management components set is responsible for data process. ECSpec editor and LRSpec editor are provided as V4-293

5 tools to define the ALE specifications. After the specs are defined, they should be bound to specific physical RFID readers. Thus logical RFID reader configuration manager is introduced. Filter principles and aggregation rules can be applied to individual devices or to a multiple devices that are logically grouped. In addition, some issues concerned with the deployment of the Edge Server Administration Console itself are needed to pay more attention. Firstly, since it also hosted in OSGi runtime environment as Edge Server Core, it could be operated in the same host played the role as edge server. Certainly, it could be installed and assembled on a standalone server as well. This is all depended on your application Scenario, especially the device played the role as edge server. Secondly, only the required components are loaded to lighten the weight. And bundles could be loaded or uninstalled at the runtime without restarting the whole server. D. Driver Repository Server On the above we talked about that most RFID middleware architectures adopt the same strategy to interact with the hardware: define a unify interface for all the devices in hardware abstract layer, after that, develop the corresponding adapter for a specific device, and then deploy the adapter as long as necessary. It works well and hides the complexity of hardware effectively. But for large-scale application such as supply chain logistics management, it will be a headache to deploy and maintain so many adapters on thousands of edge servers. We propose a novel solution by introducing another standalone server as Driver Repository besides the edge server. The Driver Repository server works like this: All of the adapters and drivers centralize on the driver repository server, which serves an inquiry and download interface to external. When a new specific physical device is installed and its adapter has not deployed on the edge server yet, the physical device administration console will query the driver repository and download automatically the right adapter to the edge server. A similar mechanism also works when adapters need to update. In this way, all of adapters to be deployed in the whole system will under the uniform management and maintenance. Essentially, the driver repository is a remote OSGi bundle repository. It consists of three components: Driver Database, Driver Repository Administration console, and Inquiry Download Interface. All of the drivers and adapters are deposited on the Driver Database. When a new adapter is developed or an old adapter is updated, it could be stored on the Driver Database used by edge server to download. It largely shortens the time between developments and deployments. Driver Repository Administration console is used for managing the installation, inquiry and deletion operators to all the adapters on the repository in a userfriendly way. Inquiry Download Interface serves as webservice for accessing the driver repository from external. V. CONCLUSION With increasing of RFID applications in supply chain logistics management, large-scale deployments of physical hardware are highlighting certain challenges. Meanwhile, as more and more Enterprise system and middleware are involved and realized with SOA-based architecture, the layer for devices accessing is tend to be abstracted to an independent service platform that handle multiple devices and deliver data to upstream layers of the system. In this paper, we propose a SOA-based architecture for integration, deployment and management of RFID devices at the edges of network, which implements device agnostic to upstream layers and makes the disparate hardware and software connected seamlessly by providing a unified interface. Beyond that, in consideration of the deployment and management of large number of devices, we present a novel solution by introducing another standalone server as driver repository besides the edge server. This SOA-based architecture tends to be suitable for the supply chain logistics management applications, as well as other large-scale applications. ACKNOWLEDGMENT Supported by the 863 Hi-Tech Research and Development Program of China under contract No. 2006AA04Al19-5, Natural Science Foundation of LiaoNing Province under contract No. 09L [I] REFERENCES International Telecommunication Union (2005), The Internet of Things Executive Summary, ITU Internet Reports [2] EPCGlobal, [3] AGhayal, ZXhan, and R.Moona, "SmartRF-A Flexible and Light Weight RFID Middleware," The IEEE International Conference on e Business Engineering (ICEBE 2008), ApriL2008, pp , doi: 10 li09iicebe [4] L.Schmidt, N.Mitton, and D.Simplot-Ryl, "Towards unified tag data translation for the Internet of Things," Wireless Communications, Vehicular Technology, Information Theory and Aerospace & Electronic Systems Technology (Wireless VITAE 2009), May.2009, pp , doi: IWIRELESSVITAE I [5] An Oracle White Paper: Enterprise Information Architecture for RFID and Sensor-Based Service, February 2006, [6] IBM WebSphere RFID Handbook, [7] Patrik Spiess and Stamatis Karnouskos, "SOA-based Integration of the Internet of Things in Enterprise Services," The IEEE International Conference on Web Services (ICWS 2009), July.2009 pp , doi:lo.li09/icws [8] Thomas Frenken, Patrik Spiess, and Furgen Anke, "A Flexible and Extensible Architecture for Device-Level Service Deployment," Service Wave 2008, pp ,doi: / _20 [9] Christian Floerkemeier, "Integrating RFID Readers in the Enterprise IT -Dverview of Intra-organizational RFID System Services and Architectures," Academic publication of the Auto-ID Labs, May.2008, autoidlabs. org/publ ications/page. html [10] OSGi Alliance, V4-294