KR20080098267A

KR20080098267A - Rfid middleware system

Info

Publication number: KR20080098267A
Application number: KR1020070043736A
Authority: KR
Inventors: 박병섭
Original assignee: 박병섭
Priority date: 2007-05-04
Filing date: 2007-05-04
Publication date: 2008-11-07

Abstract

An RFID middleware system is provided to access to a plurality of protocols which are different with each other, and process large capacity data in real time. A reader interface part(16) has an adapter which are connected to a plurality of RFID readers(30a,30b,30c) of the mutually different kinds of machines through network, and collects the plurality of stream tag through the RFID adapter. An application interface unit(17) exchanges data with a plurality of clients by the plurality of clients using the mutually different protocol and the each protocol(50a,50b,50c). An event manager(11) manages stream tag data collected through the reader interface unit, produces the stream data according to the filtering condition received from client through the application interface unit, and transmits the application data to more than one of the plurality of clients through the application interface part.

Description

RFIDD middleware system {RFID MIDDLEWARE SYSTEM}

1 is a diagram illustrating a configuration of an RFID system to which an RFID middleware system according to the present invention is applied,

2 is a diagram illustrating a configuration of an RFID middleware system according to the present invention,

3 is a view for explaining the data exchange between the filter manager and the client of the RFID middleware system according to the present invention,

4 is a view for explaining the structure of a common class in the filtering class structure according to the present invention,

5 is a view for explaining the configuration of a JMS class according to the present invention,

6 is a view for explaining the configuration of a SOAP class according to the present invention,

7 to 11 are diagrams showing examples of the graphical user interface screen provided by the GUI generator of the RFID middleware system according to the present invention.

12 and 13 illustrate examples of a graphical user interface screen displayed on a client of an RFID system according to the present invention.

10: RFID Middleware System 11: Event Manager

12: tag storage unit 13: EM control unit

14: filter manager 15: GUI generation unit

16 reader interface 17 application interface

30a, 30b, 30c: RFID Reader 50a, 50b, 50c: Client

70: monitor

The present invention relates to an RFID middleware system, and more particularly, to an RFID middleware system capable of accessing a platform according to a plurality of mutually different protocols and processing a large amount of data in real time.

Real Time Enterprise (RTE) refers to a company that has improved its competitiveness by minimizing delays and speeding up decision-making through continuous process improvement and real-time delivery of information in the overall management point including internal and external companies. Recently, many companies are in the process of introducing or introducing a radio frequency identification (RFID) system to construct such an RTE.

Such an RFID system means that an RFID tag is attached to an object and wirelessly reads information of the tag through a reader to automatically utilize dozens of information of the object and information of the surrounding environment.

In order to use an RFID system for various application services, an RFID middleware system that delivers data stored in an RFID device to an application service at an appropriate place and at a proper time is required.

The transfer of accurate data by the RFID middleware system means that only the data of interest collected from the reader is filtered and delivered by the application service, and the data filtering function varies depending on the format and application environment of the data.

There is a difference between how to obtain the information needed in existing applications using simple electronic product codes (EPCs) and how to filter the information in applications using data with much more complex structures. In addition, the data processing method should be adopted in consideration of the amount of data to be processed and the number of filtering conditions to be processed at the same time to enable real-time processing without data loss.

Recently, RFID mid-rure systems or solutions have been proposed in various forms, but are mainly limited to processing data in a simple format such as EPC. In addition, traditional RFID middleware systems are typically limited to simply supporting communication between business applications and the core infrastructure.

Accordingly, an object of the present invention is to provide an RFID middleware system capable of accessing a platform according to a plurality of different protocols and processing a large amount of data in real time.

It is also an object of the present invention to provide an RFID middleware system capable of processing a large amount of data while supporting scalability and integration of various platforms according to different protocols used by an infrastructure, that is, an application service.

According to the present invention, there is provided a reader interface unit having an RFID adapter each connected to a plurality of RFID readers of different types through a network, and collecting stream tag data read by the plurality of RFID readers through the RFID adapter. ; An application interface unit for exchanging data with a plurality of clients using different protocols and the plurality of clients according to the respective protocols; Manage the stream tag data collected through the reader interface unit, process and filter the stream tag data according to filtering conditions received from the client through the application interface unit to generate application data, and through the application interface unit It is achieved by the RFID middleware system comprising an event manager for transmitting the application data to at least one of a plurality of clients.

The application interface unit may communicate with the client using at least one of a Java Message Service (JMS) protocol, a Simple Object Access Protocol (SOAP), and a HyperText Transfer Protocol (HTTP).

The event manager may include a tag storage unit for storing the stream tag data collected through the reader interface unit, a filter manager for processing and filtering the stream tag data according to the filtering condition to generate application data, and It may include an EM control unit for transmitting the application data generated by the filter manager to the client via the application interface unit.

Here, the filtering class structure between the filter manager and each client may include: a plurality of individual protocol classes for managing filters using the respective protocols; A FilterMgr class having a FilterSet class in which filter information for each filter is recorded, an API (Application Program Interface) for requesting operation on the filter information, and each individual protocol class includes an API (Application Program Interface) of the FilterMgr class. When accessing the FilterSet class at the same time through), it may include a common class consisting of the FlterServer class that controls access by setting a predetermined threshold area.

Here, the FilterSet class is composed of a plurality of members in which a method does not exist; The member constituting the FilterSet class may include a filter rule for each filter.

In addition, the FlterServer class generates a thread when each individual protocol class accesses the FilterSet class through the API of the FilterMgr class; The thread may lock the file in which the filter information of the FilterSet class is recorded and perform the operation request received through the FilterMgr class.

The individual protocol class may include a JMS class for managing the filter using the Java Message Service (JMS) protocol and a SOAP class for managing the filter using the Simple Object Access Protocol (SOAP) on AXIS. Can be.

Wherein the filtering class structure further comprises a JMS service provider supporting the Java Message Service (JMS) protocol for the JMS class; The JMS class provides an application program interface (API) for the Java Message Service (JMS) protocol, the JMSController class for accessing the JMS service provider and storing the operation request for the filter information in the JMS service provider; The ListenerBody class that reads the operation request for the filter information stored in the JMS service provider and delivers it to the FilterSet class through the FilterMgr class of the common class, and is connected to the JMS service provider, generates the ListenerBody class to be asynchronous. In general, it may include a listener class for processing the operation request for the filter information.

In addition, the SOAP class provides an API (Application Program Interface) for the Simple Object Access Protocol (SOAP), and a SOAPController class for accessing the AXIS to perform an operation request for the filter information, and from the SOAPController class. The operation request may include a FilterMgr.jws class that delivers the operation request to the FilterSet class through the FilterMgr class of the common class.

Wherein the RFID adapter is connected to each of the RFID readers through TCP / IP; The stream tag data collected through the reader interface unit may be transferred to the event manager in the form of an XML file and stored in the tag storage unit.

Hereinafter, with reference to the drawings will be described the present invention in more detail.

FIG. 1 is a diagram illustrating a configuration of an RFID system to which an RFID middleware system 10 according to the present invention is applied, and FIG. 2 is a diagram illustrating a configuration of an RFID middleware system 10 according to the present invention.

Referring to FIG. 1, an RFID system according to the present invention includes a plurality of RFID readers 30a, 30b, and 30c, an RFID midware system, and a plurality of clients 50a, 50b, and 50c which are application services.

In the RFID middleware system 10 according to the present invention, the RFID readers 30a, 30b, and 30c are provided to receive stream tag data from RFID readers 30a, 30b, and 30c of different types. In the present invention, the RFID middleware system 10 recognizes RFID readers 30a, 30b, and 30c of Matrics, Alian, and Intermec as an example.

Meanwhile, as illustrated in FIG. 2, the RFID middleware system 10 includes a reader interface unit 16, an application interface unit 17, and an event manager 11.

The reader interface unit 16 is connected to the RFID readers 30a, 30b and 30c through the network 90 to collect stream tag data read by the RFID readers 30a, 30b and 30c. Here, the reader interface unit 16 corresponds to the type of each RFID reader 30a, 30b, 30c connected to the different types of RFID readers 30a, 30b, 30c and the network 90 through the network 90 as described above. It includes an adapter (not shown), and collects stream tag data received through each RFID adapter.

Here, the RFID adapter may be connected to each RFID reader 30a, 30b, 30c through TCP / IP, and the stream tag data collected through the RFID adapter may be managed in the form of an XML file.

The application interface unit 17 exchanges data with a plurality of clients 50a, 50b, 50c using different protocols and a plurality of clients 50a, 50b, 50c according to each protocol. Here, each client (50a, 50b, 50c) has a platform according to the protocol, the application interface 17 of the RFID middleware system 10 according to the present invention is a client (50a, 50b, 50c) of different platforms Enable connection of.

In the present invention, the client (50a, 50b, 50c) has a platform in accordance with the Java Message Service (JMS) protocol, Simple Object Access Protocol (SOAP), and HyperText Transfer Protocol (HTTP) as an example, according to the application interface unit 17 exchanges data with the client (50a, 50b, 50c) in accordance with the Java Message Service (JMS) protocol, Simple Object Access Protocol (SOAP), and HyperText Transfer Protocol (HTTP).

Meanwhile, the event manager 11 manages stream tag data collected through the reader interface unit 16. The event manager 11 processes and filters the stream tag data according to the filtering conditions received from the clients 50a, 50b, and 50c through the application interface unit 17 to generate application data. The event manager 11 transmits the application data generated according to the filtering condition to the corresponding clients 50a, 50b, and 50c through the application interface unit 17.

Referring to FIG. 2, the event manager 11 according to the present invention uses a tag storage unit 12 in which stream tad data collected through the reader interface unit 16 is stored, and an application interface unit 17. A filter manager 14 for processing and filtering stream tag data according to the filtering conditions received from the clients 50a, 50b, and 50c to generate application data, and applying the application data generated by the filter manager 14 to the application interface unit. It may include an EM control unit 13 for transmitting to the corresponding client (50a, 50b, 50c) through (17).

Hereinafter, a method in which the filter manager 14 of the event manager 11 according to the present invention performs an operation request for a filter will be described in detail with reference to FIGS. 3 to 6.

The filter manager 14 according to the present invention is provided in the form of a program for managing a filter used in the RFID middleware system 10. In addition, the event manager 11 supports various protocols of the clients 50a, 50b, and 50c so that the clients 50a, 50b, and 50c of various platforms are accessible.

Here, the filter manager 14 accesses a filter file, for example, XMLFilter.xml, in which a plurality of clients 50a, 50b, and 50c access a single filter file, that is, stream tag data stored in the tag storage unit 12. In order to solve the synchronization problem that occurs, as shown in Fig. 3, the individual processors 14a, 14b, 14c which process the filter control command including the filtering condition transmitted from the clients 50a, 50b, 50c according to each protocol. ), And an integrated processor 14d for managing the filter file integrated and managing the filter file according to the filter control command processed by the individual processors 14a, 14b, and 14c.

Meanwhile, in the RFID middleware system 10 according to the present invention, the filtering class structure between the platform of each client 50a, 50b, 50c and the filter manager 14 will be described in detail. It may include a plurality of individual protocol classes to manage and a common class that all protocols use to manage them collectively.

4 is a diagram illustrating a structure of a common class in the filtering class structure according to the present invention. Referring to FIG. 4, the common class may include a FilterSet class, a FilterMgr class, and a FlterServer class.

The FilterSet class records filter information for each filter. The FilterSet class is used to store each filter as an object and transmit the same to the clients 50a, 50b, and 50c through the network 90. The FilterSet class may be defined as a bundle of filters to be registered.

Here, the FilterSet class is composed of a plurality of members in which a method does not exist. Each member may include a filter rule for a filter to be registered, such as TagID, reader1, readerNum, maxDiscoveryDay, and the like.

The FilterMgr class includes an application program interface (API) for requesting operation on filter information. As shown in FIG. 4, the FilterMgr class has an application program interface (API) and communicates with a filter file in which actual filter information is recorded, that is, a FilterServer class that accesses XMLFilter.xml as described above.

Here, XMLFilter.xml can access several files at the same time, so the FilterServer class sets the critical area and controls access. Accordingly, the FilterServer class has functions provided by the FilterMgr class to remove file corruption due to simultaneous access to XMLFilter.xml, and to simply perform operation requests such as writing, deleting, and reading filter information for the filter file. Will be.

Table 1 below shows examples of the methods of the FilterMgr class. Filter information can be set in the FilterMgr class using the functions shown in Table 1. Filter information can be controlled using the FM_XMLInsert, FM_XMLDelete, and FM_GetXMLFile functions.

TABLE 1

Method Role setTagID (Filter setting) Set TagID. setReader1 (Field setting) Set Reader1. setReaderNum (FILTER SETTING) Set ReaderNum. setMinDiscoveryDay (Filter setting) Set MinDiscoveryDay. setMinDiscoveryTime (Filter setting) Set MinDiscoveryTime. setMaxDiscoveryDay (Filter setting) Set MaxDiscoveryDay. setMaxDiscoveryTime (Filter setting) Set MaxDiscoveryTime. setAntenna (Field setting) Set the antenna. setRemoteAddr (Filter setting) Configure RemoteAddr. FM_XMLInsert (API) Record the set filter information. FM_XMLDelete (API) Delete the set filter information. FM_GetXMLFile (API) Get set filter information as String.

FilterServer class accepts the operation request by using socket to prevent filter file damage when several individual protocol classes access FMLFilter.xml that stores filter information at the same time, and sets critical area when accessing filter file. To support synchronization. As shown in FIG. 4, the FilterServer class creates one thread when a connection is made using the FilterMgr class, and each thread locks the filter file according to the operation request and performs an operation according to the operation request.

On the other hand, each protocol class may include a JMS class for managing the filter using the Java Message Service (JMS) protocol, and a SOAP class for managing the filter using the Simple Object Access Protocol (SOAP) on AXIS.

5 is a view for explaining the configuration of a JMS class according to the present invention. The JMS class shown in the figure may include a JMSController class, a ListenerBody class, and a Listener class.

Here, the filter manager 14 according to the present invention may include a JMS service provider supporting a Java Message Service (JMS) protocol for a JMS class. In the present invention, as a JMS service provider, as shown in FIG. 5. For example, using OPENJMS.

Referring to Figure 5 summarizes the overall processing of the JMS class, the JMSController class performs an operation request for the filter using the API. This operation request is accumulated in the testQueue of OPENJMS, read from the Listener class, and connected to the actual filter file XMLFilter.xml using the FilterMgr class of the common class. Filter files accessed by the FilterMgr class are accumulated in the InterMiddlewareQueue of OPENJMS, and finally the contents of XMLFilter.xml can be received as a string in the JMSController class.

The JMSController class provides an application program interface (API) for the Java Message Service (JMS) protocol. The JMSController class accesses OPENJMS, a JMS service provider, and transmits an operation request for the filter information, which is stored in a testQueue of OPENJMS. Here, the JMSController class runs on the platform of the clients 50a, 50b, 50c.

Table 2 below shows an example of methods and their roles in the JMSController class.

TABLE 2

Method Role JMS_Connect Connect to JMS. JMS_XMLInsert Save filter information (using FilterSet). JMS_XMLDelete Delete filter information (using FilterSet). JMS_GetXML Get filter information as a String. JMS_Exit Request to terminate connection to JMS

The Listener class is connected to OPENJMS. It creates a ListenerBody class to handle arithmetic requests asynchronously. And the ListenerBody class actually handles the operation request, and the Listener class uses the class for processing asynchronous operation requests. The ListenerBody class receives the operation request requested by the JMSController class from the testQueue of OPENJMS and performs the operation according to the operation request. Here, ListenerBody class internally owns an object of FilterMgr class and uses it to perform operation request.

6 is a view for explaining the configuration of the SOAP class according to the present invention. The SOAP class according to the present invention manages a filter using Simple Object Access Protocol (SOAP) in AXIS. As shown in FIG. 6, the SOAP class transmits data to AXIS running on Apache (“Apache tomcat” of FIG. 6) using an XML method, which is a communication method of the Simple Object Access Protocol (SOAP). It can communicate directly with XML and can also communicate with the provided API (Application Program Interface).

In addition, the SOAP class may include a SOAPController class and a FilterMgr.jws class, as shown in FIG. 6.

The SOAPController class provides an application program interface (API) for the Simple Object Access Protocol (SOAP). It connects to AXIS and performs an operation request for filter information. [Table 3] below shows an example of methods of SOAPController class and its role. The SOAPController class runs on the platform of clients 50a, 50b, 50c.

TABLE 3

Method Role SOAP_XMLInsert Save filter information (using FilterSet). SOAP_XMLDelete Delete filter information (using FilterSet). SOAP_GetXML Get filter information as a String.

The FilterMgr.jws class includes an application program interface (API) that performs an operation request for filter information. The FilterMgr.jws class has a role similar to that of FilterMgr of the common class described above, but is modified for the AXIS environment. Accordingly, files processed by the FilterMgr class and the FilterMgr.jws class of the common class may be classified into FilterMgr.java and FilterMgr.jws. In summary, the FilterMgr class of the common class is used for the HyperText Transfer Protocol (HTTP) and Java Message Service (JMS) protocols, and the FilterMgr.jws class is used for the Simple Object Access Protocol (SOAP).

Through the filtering class structure as described above, the filter manager 14 generates application data from the stream tag data according to the filtering condition for the filter information from each client 50a, 50b, 50c, and the EM controller 13 filters the filter. Application data generated by the manager 14 is transmitted to the corresponding clients 50a, 50b, and 50c.

Referring back to FIG. 2, the event manager 11 according to the present invention is a GUI generator that displays a graphical user interface screen on the monitor 70 under the control of the EM controller 13. It may further include (15).

7 to 11 are diagrams showing examples of a graphical user interface screen provided by the GUI generator 15 according to the present invention.

FIG. 7 is a diagram showing an example of a screen showing the connection status of the RFID readers 30a, 30b, and 30c connected to the adapter of the reader interface unit 16. As shown in FIG. As shown in the figure, the type of the RFID reader (30a, 30b, 30c), the IP address, the port number of the corresponding adapter, the On / Off status is displayed on the screen.

In addition, by using the 'add information', 'edit information', and 'delete all' buttons among the selection buttons provided at the bottom of the screen, the information of the RFID readers 30a, 30b, 30c can be managed as a file, and 'selective access' '/ Release' button to individually connect and disconnect the RFID reader (30a, 30b, 30c).

FIG. 8 is a diagram illustrating an example in which stream tag data collected from RFID readers 30a, 30b, and 30c connected in a state where connection is set through the screen of FIG. 7 is displayed on a screen.

FIG. 9 is a view for explaining a process of adding new RFID readers 30a, 30b, and 30c on the screen of FIG. 7. When the 'Add Info' button is selected, the 'Add Reader Information' screen is displayed and through this, By selecting the types, IP addresses and ports of the readers 30a, 30b, and 30c, new RFID readers 30a, 30b and 30c can be added. FIG. 10 is a diagram illustrating an example of a screen in which the RFID readers 30a, 30b, and 30c of FIG. 8 allow a user to select separate antenna reading when an antenna is detachable.

11 is a diagram illustrating an example of stream tag data displayed on a screen by filtering according to a specific filtering condition. Here, FIG. 11 shows TagID, types of RFID readers 30a, 30b, and 30c ('Alien' of 'Reader' item in FIG. 11), and period ('Min_Day' and 'Max_Day' items in FIG. 11) as filtering conditions. It is a diagram illustrating an example in which stream tag data corresponding to a filtering condition is set and extracted in real time and displayed on a screen.

12 is a diagram showing an example of a graphical user interface screen displayed on the clients 50a, 50b, 50c of the RFID system according to the present invention.

As shown in the figure, through the screen displayed on the client (50a, 50b, 50c), the setting of the API (Application Program Interface), for example, as described above, the JMS (Java Message Service) protocol, SOAP (Simple Object) Select one of Access Protocol) and HTTP (HiperText Transfer Protocol) supported by the client 50a, 50b, 50c, select TagID, RFID reader type 30a, 30b, 30c, set period, and select antenna The screen for selecting a filtering condition is displayed by selecting and the like.

The filtering condition set through the screen shown in FIG. 12 is transmitted to the RFID middleware system 10, and is extracted from the stream tag data according to the filtering condition by the filter manager 14 of the RFID middleware system 10 to be applied. It is generated as data. Application data is then sent back to the clients 50a, 50b, 50c and displayed as shown in FIG.

Although the preferred embodiments of the present invention have been described in detail above, the scope of the present invention is not limited thereto, and various modifications and improvements of those skilled in the art using the basic concepts of the present invention defined in the following claims are also provided. It belongs to the scope of rights.

As described above, according to the present invention, according to the present invention, it is possible to access the platform according to a plurality of mutually different protocols, and to process a large amount of data in real time.

In addition, according to the present invention, it is possible to process a large amount of data while supporting scalability and integration of various platforms according to different protocols used by an infrastructure, that is, an application service.

Claims

A reader interface unit having an RFID adapter each connected to a plurality of RFID readers of different types through a network, and collecting stream tag data read by the plurality of RFID readers through the RFID adapter;

An application interface unit for exchanging data with a plurality of clients using different protocols and the plurality of clients according to the respective protocols;

Manage the stream tag data collected through the reader interface unit, process and filter the stream tag data according to filtering conditions received from the client through the application interface unit to generate application data, and through the application interface unit RFID middleware system comprising an event manager for transmitting the application data to at least one of a plurality of clients.

The method of claim 1,

And the application interface unit communicates with the client using at least one of a Java Message Service (JMS) protocol, a Simple Object Access Protocol (SOAP), and a HyperText Transfer Protocol (HTTP).

The method of claim 2,

The event manager

A tag storage unit for storing the stream tag data collected through the reader interface unit;

A filter manager for processing and filtering the stream tag data according to the filtering condition to generate application data;

And an EM controller for transmitting the application data generated by the filter manager to the corresponding client through the application interface unit.

The method of claim 3,

The filtering class structure between the filter manager and each client is

A plurality of individual protocol classes for managing filters using the respective protocols;

A FilterMgr class having a FilterSet class in which filter information for each filter is recorded, an API (Application Program Interface) for requesting operation on the filter information, and each individual protocol class includes an API (Application Program Interface) of the FilterMgr class. RFID middleware system comprising a common class consisting of FlterServer class for controlling access by setting a predetermined threshold area when accessing the FilterSet class at the same time.

The method of claim 5,

The FilterSet class consists of a plurality of members having no methods;

And the member constituting the FilterSet class includes a filter rule for each filter.

The method of claim 5,

The FlterServer class creates a thread when each individual protocol class connects to the FilterSet class through the API of the FilterMgr class;

The thread locks the file in which the filter information of the FilterSet class is recorded, and performs the operation request received through the FilterMgr class.

The method according to any one of claims 4 to 6,

The individual protocol class

A JMS class for managing the filter using the Java Message Service (JMS) protocol;

RFID middleware system comprising a SOAP class for managing the filter using the Simple Object Access Protocol (SOAP) on AXIS.

The method of claim 7, wherein

The filtering class structure further comprises a JMS service provider supporting the Java Message Service (JMS) protocol for the JMS class;

The JMS class

A JMSController class for providing an application program interface (API) for the Java Message Service (JMS) protocol, and accessing the JMS service provider to store an operation request for the filter information in the JMS service provider;

A ListenerBody class that reads an operation request for the filter information stored in the JMS service provider and delivers it to the FilterSet class through the FilterMgr class of the common class;

And a listener class connected to the JMS service provider and generating the ListenerBody class to process the operation request for the filter information asynchronously.

The method of claim 7, wherein

The SOAP class

A SOAPController class that provides an API (Application Program Interface) for the Simple Object Access Protocol (SOAP), accesses the AXIS, and performs an operation request for the filter information;

And a FilterMgr.jws class that forwards the operation request from the SOAPController class to the FilterSet class through the FilterMgr class of the common class.

The method of claim 3,

The RFID adapter is connected to each of the RFID readers via TCP / IP;

The stream tag data collected through the reader interface unit is delivered to the event manager in the form of an XML file and stored in the tag storage unit.