Design and implementation of configurable RFID middleware for mobile devices

　　Design and implementation of configurable RFID middleware for mobile devices

　　0 Preface

　　Radio Frequency Identification (RFID) middleware is a layer of software between the physical RFID reader and the upper-layer application software. The RFID middleware shields various reader transmission standards, so that the upper-layer application software is unified and non-uniform. Variable data and control interface; in addition, it can also integrate and filter the original data to generate user-customized data reports. When RFID technology is applied on a large scale, massive amounts of data will be generated, and the application of RFID middleware will make data processing and transmission relatively simple. The connecting function of middleware makes the design of RFID system more flexible and easier to maintain. Whether it is changes in back-end applications or front-end readers, it will not affect the other end, eliminating the complexity of maintaining many-to-many connections. problem.

　　RFID middleware is the product of the development of RFID technology application field and application scale. There are some products on the market today, such as: RFID middleware products of SUN, Microsoft and BEA. However, most of these products run on PC or server. Due to the limited network bandwidth, a large amount of data must be transmitted through the network, and a large amount of invalid data must be concentrated on the server side. The server must filter and filter the massive data and transform the data into what users need and meaningful according to certain business rules. This kind of complicated processing will increase the pressure on the server and affect the performance of the system. In the event of a network failure, it is also easy to cause data loss and so on.

　　With the advancement of technology, the memory storage capacity and CPU processing capacity of mobile devices (such as PDAs, etc.) have been continuously enhanced, which also makes it possible to design an RFID middleware for mobile devices. In response to this technology development trend, this paper proposes a flexibly deployable RFID middleware SeaMobileMiddleware (SMM) for mobile devices. SMM can effectively use the free resources such as the memory and CPU of mobile devices, and do a series of preprocessing before sending the data to the server to optimize the original data, reduce the pressure on the network and the server, and automatically store the data when the network fails to ensure the consistency of the data Sex.

　　1　 RFID middleware SMM system architecture

　　The system architecture has a great impact on the overall performance of the system. Aiming at the characteristics of mobile devices, a flexibly configurable RFID middleware SMM system architecture for mobile devices is given, as shown in Figure 1.

　　The overall system architecture of SMM includes three modules, among which: the lowest layer is the Device module, which is responsible for abstracting the physical real device into the device object of the system; the middle layer is the Task Manager module, which is the core module of SMM, which is responsible for processing users and upper-layer applications. All commands of the system are converted into the Task object of the system and executed by standard XML commands to control the Device object; the uppermost layer is the User Interface (UI) module, which is a graphical interface developed based on standard Java swing. The user can conveniently control the Device object locally. At the same time, SMM also provides a standard Web service interface to facilitate other remote systems to control and manage mobile devices.

　　By providing local UI and remote management interface for mobile devices, SMM can enable users to customize the process and transform the original label data into meaningful data that users want through filtering and filtering. The XML-based standard interface provided by Task Manger also provides good scalability and compatibility for SMM.

　　1.1　Device module

　　Due to the wide variety of tags, readers, and so on, the standards are different. One of the core functions of RFID middleware is to shield the difference in reader transmission standards and provide a unified interface for the upper layer. Through abstraction, SMM treats different types of RFID readers, PDAs and other mobile devices as different types of Device objects, and configures three attributes of Rule, Dispatcher, and Driver for each Device. The original data sent by different tags are adapted to a unified data format through the Driver, and the unified data format is converted into the data required by the upper-level system through the Rule, and then the data is sent to the required upper-level application through the Dispatcher.

　　1) Driver: Considering the diversity of tags and readers in practical applications, Driver adapts and processes different types of reader data, and unifies and formats the data. The default Driver is built in the SMM architecture, which is responsible for processing most of the current popular Readers. At the same time, for special needs, users can develop specific Drivers to complete the data standardization of special Readers and Tags.

　　2) Rule: Rule can customize specific business logic and data filtering rules, thereby transforming data into meaningful data required by upper-level applications.

　　For example: Extract data from tags produced by the same manufacturer through Rule configuration.

　　3) Dispatcher: Dispatcher defines the data distribution path and provides routing functions for data. The Dispatcher can be customized to send data to the upper-level application that the user needs. In addition, the system provides an offline Dispatcher for data processing when the device is offline. When the device is offline, the system will save the data in the embedded mobile database "Olite". When the system is connected, the offline Dispatcher will automatically send the historical events saved in the "Olite" database to the upper application to achieve Data is automatically synchronized.

　　Based on abstract ideas, the Device module abstracts various RFID readers into different objects. Real devices are managed by configuring Rule, Dispatcher, and Drive attributes, formatting tag data from different sources into unified standard data, filtering the data according to user-defined rules, and forwarding it to the corresponding upper-level system.

　　1.2　Task Manager module

　　Another core function of RFID middleware is to provide a standard interface to the outside, which is convenient for upper application call and secondary development [10]. The Task Manager module in SMM provides standard input and output by managing all commands and task execution.

　　The Task Manager module has the following functions: 1) Accept various XML commands, parse the XML commands to find the corresponding task objects and encapsulate the results into standard XML to return to the caller after execution; 2) Provide efficient task queues to handle various tasks Such XML commands; 3) Provide a dynamic log queue so that users can monitor the relevant information of the device in real time.

　　Based on the Task Manager module, SMM provides two types of requests: graphical interface and Web Service to control and manage mobile devices so that users can obtain the data they need. If it is an internal SMM request, a standard Java API is provided; if it is an external request, a standard XML-based Web interface is provided. Figure 3 shows the implementation process of Task Manager. In the module, the upper application sends standard XML commands to the SMM through the HTTP protocol, and the SMM processes various HTTP requests through the embedded lightweight HTTP Server Jetty. After Jetty receives the standard XML request, it sends various XML commands to the Task Manager module. After the Task Manager parses the XML format command, it obtains the corresponding Task object through Java reflection. If the Task object is synchronous, the Task execution method is called, and the corresponding result is returned and converted into standard XML to the Jetty server; if the Task object is asynchronous, it is placed in the task queue, and the return is empty.

　　The task queue uses threads to execute tasks in a first-in first-out method. In order to show the task execution process, this article gives the device startup process to show the process of controlling the device by the upper application program.

　　The upper-level application sends standard XML commands to the Jetty server through the HTTP (POST) method, the format is as follows:

　　According to the content of "action", Task Manager obtains the Start Device Task instance of the corresponding task through the reflection mechanism provided by Java, and passes the corresponding device name as a parameter to the Start Device Task instance. Since the Start Device Task is asynchronous, the Start Device Task will be executed in the task queue and return empty. When the task queue executes the Start Device Task task, the Task Manager log queue will write the log in real time to change the status of dev21 and dev22, and return to the UI of SMM.

Read recommendations:

M04 ISO11784/5 Animal Microchip Implant

M03 ICAR Certifiicated Injected Under Skin Microchip

M02- Pet Microchip with Needle Pack

Introduction to the working principle of RFID.dog microchip maker

What are the advantages of UHF RFID electronic tags? Mainly in three aspects!Pet Tag Sale