Abstract: With the rapid development and widespread application of EPC and RFID technologies, RFID middleware has become the central nervous system of RFID systems. This paper discusses EPC systems and RFID middleware, and designs an embedded RFID middleware based on the EPCglobal ALE standard, enabling the integration of standard RFID middleware onto readers and realizing the concept of integration. Keywords: Electronic Product Code; Application Layer Event Interface; Radio Frequency Identification; Middleware; Embedded System 1 Introduction While RFID technology has developed rapidly and been increasingly widely applied, two problems have also emerged: First, in such a large market, numerous protocols exist, along with various readers with different usage and operation methods, which seriously hinders the large-scale application of RFID technology; second, how to integrate, filter, and transmit this data so that enterprises are not overwhelmed by massive amounts of data and fail to reap the benefits of RFID technology is another important problem that urgently needs to be solved. In this context, RFID middleware was born and developed rapidly. RFID middleware can shield readers of various specifications and models and tags of various protocol standards, so that upper-layer application software can have a unified and unchanging interface. In addition, it is responsible for integrating and filtering data, generating reports, and making the transmission and application of massive data possible. At present, the RFID middleware at home and abroad is large in size and is designed only for PCs. It cannot be directly ported to embedded readers. This paper implements a portable embedded RFID middleware based on the ALE standard that can run directly on embedded reader devices. 2 EPCglobal ALE standard EPC[1] is an abbreviation for Electronic Product Code. It was proposed by the Auto-ID Center of MIT. Its main idea is to assign an electronic tag to each product participating in the Internet of Things. The tag stores a world-unique EPC code. When the product passes through the reader, the RFID technology reads the data and obtains the corresponding EPC code. Finally, the corresponding EPC code is parsed by the server connected to the Internet. The EPC system mainly consists of EPC codes, EPC tags, EPC readers, EPC middleware, PML (Physical Markup Language) server, ONS (Object Name Resolution Service) server, etc. The system protocol mainly consists of RFID communication protocol, Application Event Management (ALE) protocol, etc. The EPC ALE[2] protocol is the interface protocol between EPC middleware, reader module and client application. This protocol defines how the client can filter and integrate EPC tags from multiple readers, and defines a unified interface for different enterprise applications and readers. In this way, even if the backend application is added or replaced by other software, or the type of RFID reader changes or is added, other components do not need to be modified. The processing procedures included in ALE are: receiving EPC tag codes from one or more data sources; integrating data at certain time intervals according to the client (enterprise application) requirements, filtering duplicate and uninteresting EPC codes; and packaging and sending reports in different forms according to the client requirements. The ALE protocol is event-based and can operate in synchronous or asynchronous mode. It has high real-time requirements but does not require long storage time for received EPC data. Once received EPC data has been processed and sent by all relevant events, the data can be deleted. The file format for sending data packets is XML. All data to be sent to clients or other readers is encapsulated into an XML file. The client parses the received data file according to the corresponding XML format to extract the relevant data information. The position of ALE in EPCglobal is shown in Figure 1, located between the original EPC detection event layer (RFID tag reading layer) and the application business logic layer. Figure 1 Position of ALE in EPCglobal network structure 3 Embedded RFID Middleware Implementation Scheme Based on EPCglobal ALE Standard 3.1 Main Features of the RFID Middleware Designed in This Paper This middleware is built on an embedded system, which is different from middleware running on a general computer. Implementing RFID middleware functions on an embedded system allows the middleware to be integrated into the reader. This enhances the reader's performance, transforming the traditional "dumb" reader into a truly "smart" reader. Furthermore, it integrates the RFID middleware and reader into a unified whole, embodying the "All in a box" concept. This simplifies RFID system installation and reduces costs. The middleware also supports the EPCglobal ALE standard, a widely used standard applicable to various reader models and tag standards, providing a unified and consistent standard interface for upper-layer applications, exhibiting strong versatility and compatibility. The middleware also features network functionality, including standard web server and database capabilities. This enables network communication and data buffering between readers and between readers and clients, with network data encapsulated in standard XML format for transmission. 3.2 Embedded RFID Reader Hardware System Platform This embedded RFID reader has three basic hardware modules: an antenna and radio frequency module, a DSP baseband board module, and a main control system module. The antenna and RF module are responsible for transmitting and receiving RF signals. The DSP baseband module is responsible for converting the signals received by the RF module into digital signals, performing CRC checks, and transmitting the data to the main control system module through the HPI interface. It is also responsible for parsing and implementing control commands issued by the main control system module. The main control system module is mainly responsible for the control of the entire system, tag processing, and customer service response. The main control system module mainly consists of an ARM (AT91RM9200) and peripheral devices, with the operating system being arm-linux 2.4.19. The middleware will run in this module. 3.3 Embedded RFID Middleware Software Architecture This system adopts a layered software architecture. The lower layer is the Linux operating system and driver modules for various peripheral interfaces, including DSP drivers, network port drivers, and serial port drivers. The middle layer is the GoAhead web server and the embedded database SQLite. The upper layer is reader management, ReadProtocol, and the ALE layer, as shown in Figure 2. Figure 2. Software Architecture. The operating system is the foundation of the middleware. Embedded Linux is used as the operating system for this embedded RFID middleware. Linux supports multiple protocols such as TCP/IP and HTTP, eliminating complex work such as protocol porting, reducing the development difficulty of the middleware, and shortening the development cycle. The DSP driver, network port driver, and serial port driver are driver modules developed for RFID readers, requiring only some modifications to the Linux support. Linux porting technology is mature and will not be elaborated on in this article. The GoAhead Web server is a web server mainly for embedded systems. Its main functional modules include a security module, a GoForm module, a CGI module, and an SSL (Secure Sockets Layer) module. The security module includes an in-memory database module, which is mainly responsible for storing user information and providing confidentiality and security mechanisms. The GoForm module is mainly responsible for processing the form data submitted by the client and returning the corresponding processing results in the form of a web page. The CGI module mainly handles the client's CGI requests. The SSL module implements the SSL protocol in GoAhead. This is the basic software architecture of the embedded middleware designed in this paper. All network development of the system is carried out on this architecture. The GoAhead web server serves as a data forwarding platform and module hosting platform for the middleware. Data communication between the reader and the client, and between readers themselves, is handled by the GoAhead web server. The development of the ALE protocol implementation module (ALE module), database management module, reader management module, and ReaderProtocol Server module is also based on GoAhead. The database used is SQLite, a small, free, and open-source embedded database application software. It provides the standard SQL language and, due to its fast operation speed, meets the real-time requirements of data. It can be integrated into application software or run independently. This system chooses it mainly for smoothing and filtering raw data and filtering data according to client commands. Reader Management is the reader management module, responsible for setting the working status and working mode of this reader. Reader Protocol is the reader protocol server, responsible for managing all readers connected to this middleware reader, and is the implementation of the Reader Protocol on the middleware. The ALE Server is the ALE protocol server and the core of the system. It is responsible for providing standard ALE interfaces to upper-layer applications and implementing various ALE interfaces. 3.4 Implementation of the ALE Standard in this Embedded Middleware System How to implement the EPCglobal ALE specification in the RFID middleware software system is the core of this system development. In the system, we developed an ALE module to implement the EPCglobal ALE standard. Since the basic software architecture adopted by the middleware is the GoAhead Web server, it serves as a module hosting platform on which the ALE module can be well embedded. The location of the ALE module in GoAhead and its processing flow are shown in Figure 3. Figure 3: Location of the ALE module in GoAhead and its processing flow. The client sends an XML file containing ALE commands to the server using the HTTP protocol. The server receives the XML file in the GoAhead process, encapsulates it into a message, fills in the specific message type according to different interface functions, and then sends it to the ALE process through the command message queue. In the ALE process, the message is retrieved from the command message queue, and the XML file is handed over to the corresponding function for parsing and operation based on the message type. In the ALE module, for each user-defined ECSpec[2] (which is a complex data structure type that specifies how to process and complete an event cycle), the system implements four states: Undefine, Unrequested, Requested, and Active. Undefine indicates that the ECSpec can no longer be used and will soon be released; Unrequested indicates that the ECSpec is currently in a state without user subscriptions; Requested indicates that the ECSpec is currently in a state with user subscriptions; Active indicates that the ECSpec is currently about to trigger a thread to create and send reports. Each ECSpec that is not in Undefine will correspond to a dedicated sub-thread (created in the ALE process), which handles the specific data extraction, report creation, and sending specified by the ECSpec. The sub-threads corresponding to each ECSpec will not interfere with each other. The sub-threads are only connected to the main thread (the original thread of the ALE process), and the triggering and control of the sub-thread by the main thread is achieved through the condition variable mechanism. When the system extracts, filters, and integrates data according to the corresponding ECSpec requirements, it will be combined with the database system module. The database system module first filters out duplicate and redundant EPC codes from the raw data read from the reader and masks the differences in data formats between various readers. After unifying the data format, the data is sent to the SQLite database, becoming the data source for database operations. Data extraction and other operations are performed within this data source, implemented using SQLite's standard SQL language. After each data operation, expired data in the data source must be deleted. After data extraction and integration, the system encapsulates the data into XML format according to the specific requirements of the corresponding ECSpec and sends it to subscribed users via TCP. 4. Conclusion The innovation of this paper lies in the design of RFID middleware based on the EPCglobal ALE standard in embedded systems. A clear approach was proposed, and an embedded RFID middleware based on the EPCglobal ALE standard was implemented according to this approach. After compilation and testing, the system is small in size, stable and reliable, has good real-time performance, and high parallel processing speed, making it widely applicable to embedded RFID reader systems. References: [1] AUTO-ID Center, The EPCglobal Architecture Framework, [EB/OL]. [2] AUTO-ID Center, The Application Level Events (ALE) Specification Version 1.0 [EB/OL]. [3] Wang Xuelong. Embedded Linux System Design and Application. Tsinghua University Press, 2001. [4] Klaus Finkenzeller, translated by Chen Dacai. Radio Frequency Identification (RFID) Technology. Beijing: Electronic Industry Press, 2001. [5] Lu Dongxin, Li Qiang, Liu Chang'an. Design of RFID Reader Based on ARM [J]. Microcomputer Information, 2006, 10-2: 286-288.