1
INTEGRATION FRAMEWORK
BACKGROUND OF THE INVENTION
The present invention relates to data transfer between 5 sensor or actuator devices and higher-level applications.
Automated identification and data collection (AIDC) is the identification or direct collection of data into a computer system without using a keyboard. RFID (radio frequency identification) is an advanced AIDC technology. RFID uses 10 electronic tags that have a small integrated circuit and an antenna. Depending on the type of tag, up to several KB of data can be stored on one tag. The transfer of data takes place at radio frequencies. This makes it possible to read many tags simultaneously, even if the tags are not within a line of 15 sight from a reader. A device used to read data from or write data to electronic tags is generally known as an interrogator.
A "smart item" is an item or machine that can store and communicate data about itself to an external system. Any communication channel (e.g., radio frequencies, infrared) 20 can be used. The communication process can lead to changes in the data stored in the smart item. More sophisticated smart items also have processing capabilities that enable them to interact with other smart items directly and, for example, negotiate a common behavior. Smart items can 25 store and communicate different kinds of data including a unique item identifier (UID) and other item attributes for the item. Some have sensors that can record environmental data such as temperature, humidity, acceleration, or location. The communicated data can be real-time data or historical data, 30 or both.
Examples of smart items include tagged items, RFID interrogators, actuator devices, and aware goods. An actuator device is a machine that moves or controls something
35
(e.g., a conveyer belt, a vending machine). Aware goods are goods that can detect information about their environment (e.g., goods equipped with location or temperature sensors).
SUMMARY OF THE INVENTION
40
The present invention provides methods and apparatus, including computer program products, for data transfer between sensor or actuator devices and higher-level applications. 45
A computer program product in accordance with this invention is operable to cause data processing apparatus to receive a set of rules, the rules specifying what data to furnish to an external application; receive item data including item identifiers from one or more tag readers, each item 50 identifier being read from a digital tag bound to a physical item, the item identifier uniquely identifying the item; receive additional item data from other sensor devices, the other sensor devices being devices other than tag readers, the additional item data containing additional physical item 55 attributes besides an item identifier, the additional item data being related to one or more items identified by the tag readers; use the rules, item identifiers, and additional item data to determine which subset of the item identifiers and additional item data to furnish to the external application; go and furnish to the external application data consisting of only the subset of the received item identifiers and additional item data.
In general, in one aspect, the computer program product is further operable to receive data from the external appli- 65 cation, the data including configuration data for controlling an actuator device; convert the configuration data to a format
2
compatible with the actuator device; and furnish the converted configuration data to the actuator device.
The invention can be implemented to realize one or more of the following advantages:
Applications served by the integration framework receive data from billions of smart items in real time without having to expend a lot of processing power to perform the collection and filtering. Instead, the integration framework can filter out the irrelevant data before furnishing the data to the applications.
The smart items do not need to be confined to a single factory or store. Instead, the integration framework can collect data from many geographically-dispersed locations.
Applications served by the integration framework do not need to support a hardware-specific interface for every possible type of smart item. Instead, the integration framework can hide the hardware-specific details from the applications and convert between hardware-specific formats and a generic format. Hardware can be added or replaced without affecting the applications.
A system built using an integration framework in accordance with the invention is readily extensible. The integration framework provides an open infrastructure that supports different kinds of communication channels for interfacing with applications and different kinds of hardware abstractions for interfacing with different kinds of sensor devices, including different RFID devices. The infrastructure can be easily extended to accommodate new communication channels and new hardware interfaces.
Business rules enable the integration framework to adapt to new configurations and scenarios without the need for a software engineer to reprogram the operations.
The details of one or more implementations of the invention are set forth in the accompanying drawings and the description below. Other features and advantages of the invention will become apparent from the description, the drawings, and the claims.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of an integration framework in accordance with the invention.
FIG. 2 is a block diagram of an integration framework using multiple integration engines in a hierarchical fashion.
FIG. 3 is a block diagram of an exemplary integration engine.
FIG. 4 is a block diagram of an exemplary hardware interface.
FIG. 5 is a block diagram of an exemplary electronic tag. Like reference symbols in the various drawings indicate like elements.
DETAILED DESCRIPTION
An integration framework in accordance with the invention can be used to implement a wide variety of applications involving AIDC technology. Such applications include supply chain management systems, intelligent agents, and realtime item tracking systems of the kind described in U.S. patent applications No. 60/347,672, filed on Jan. 11, 2002; and No. 60/353,198, filed on Feb. 1, 2002, the entire contents of which are incorporated by this reference. Use in an example ITS will be described below.
3
Item Tracking System Example
An item tracking system (ITS) includes data processing equipment and software for maintaining information about billions of tagged items. In this specification, the term 'item' 5 has a very broad meaning. It encompasses the meaning of the term 'item' as used in the above referenced patent applications and includes any physical object that might have a location, be shipped, be sold to a consumer, and so on. 10
A tagged item is an item that carries a self-identifying tag. The tag might be associated with a single item (in the sense above) or it might be associated with a collection of items. Thus, to give just a few examples, a tagged item can be any of the following: an individual item, like a bottle of soap; a 15 case containing a collection of items of possibly various types, or a pallet containing many cases, and so on; a container; a truck or trailer; an airplane; a ship; and a railroad car.
The information maintained by the ITS can include the 20 location, status and context of each tagged item. This information can be both current and historical. The ITS receives queries from higher-level applications and responds to the queries in real time.
The ITS is designed to run continuously, 365 days a year, 25 24 hours a day, and support a high volume of data traffic. Such a system can benefit from an integration framework in accordance with the invention. As will be described below, the integration framework can collect and filter data on behalf of the ITS and furnish the ITS with only data that has 30 been requested by the ITS.
FIG. 1 is a block diagram of a framework 100 to integrate RFID technologies with higher-level systems, e.g., the ITS described above. The framework 100 is designed for RFIDenabled devices but can support other sensor or actuator 35 devices like aware goods, embedded Internet appliances and other smart items. Support for a given device is implemented using a hardware interface such as the exemplary hardware interface shown in FIG. 4. The framework 100 collects data from different types of smart items 120 and furnishes the 40 collected data to higher-level applications 130. The framework can also write data to the smart items 120.
The framework 100 has an integration engine 110 that reads and writes data from various smart items 120, processes the data and furnishes the processed data to the 45 higher-level applications 130 in real time. Doing so in real time means that the data is processed as it is received and furnished as it is processed. The integration engine 110 can also receive data from the higher-level applications 130 and write the data to the smart items 120. 50
Processing the data can include data filtering. For example, one application may only be interested in receiving UIDs and location data while another application may only be interested data collected from certain smart items. A separate filter can be provided for each application request- 55 ing data.
Processing the data can also include data aggregation. Data aggregation involves combining data together to produce higher-level data. For example, combining the UID of an item located within a truck with the temperature reading 60 from the truck to produce a temperature reading for the item. Aggregating data can make the data more meaningful than if the data were treated individually. Aggregation can also involve accumulating real-time data into a batch and sending the batched data at pre-defined intervals instead of in real 65 time. The data can be time-stamped with the date and time of collection.
4
The integration engine 110 is configured to interface with different kinds of hardware interfaces that provide basic read and write functionality. The integration engine 110 translates between hardware-specific data formats and a generic format, or, in some cases, application-specific formats. In this way, the integration engine 110 hides the hardware specifics from the applications 130.
FIG. 2 shows how multiple integration engines 110 can be used to manage a large number of smart items. Each integration engine 110 can be assigned to transfer data to and from particular locations (e.g., factories, loading docks, stores) where smart items are found. The applications 130 can subscribe to one or more of the integration engines 110. Each integration engine 110 can be implemented as multiple integration engines 110 that are nested. The output of one integration engine 110 can be the input into a higher-level integration engine 110.
FIG. 3 shows an exemplary implementation of an integration engine 110. The integration engine 110 manages all resources and objects involved in interacting with smart items and controls the overall process. The integration engine 110 includes a control manager 310, an interrogator agent 320, a processing agent 330, and a communication agent 340. The components can be implemented using conventional programming technologies including component-based technologies such as Java, C# or C++ objects.
The control manager 310 provides the programming interface between the integration engine 110 and the applications 130. The programming interface implements a generic (non-implementation-specific) communication interface to which various adapters can be plugged-in. The adapters translate between a specific communication interface (e.g., RPC, COM, CORBA, JMS, HTTP) and the generic communication interface.
The control manager 310 receives rules from the applications 130, interprets the rules, receives client commands, interprets client commands, and instantiates the appropriate interrogator agents, processing agents, and communication agents to execute the rules. The rules can define or constrain various aspects of the behavior of the interrogator agents, processing agents, and communication agents. For example, the rules can define what data to furnish to an application (e.g., only furnish data if it is UID or location data), what data to write to the hardware (e.g., if the temperature of the truck drops below a pre-determined threshold, then write a command that turns the air conditioning off), or when to furnish the data (e.g., once a day). Rules can also define how to combine collected data to generate higher-level data (e.g., combine the UID of an item located within a truck with the temperature of the truck to determine whether the item is overheated). The control manager 310 interprets and applies the rules as data is received.
In one implementation, the control manager 310 contains or is coupled in some way to a rules repository for storing the rules received from the applications and a rules engine for executing the stored rules. The rules received from the applications can be represented as UML (Unified Modeling Language) models, EJB (enterprise JavaBeans) beans, or XML (Extensible Markup Language) documents. If necessary, the control manager 310 converts the rules into an internal format used by the rules engine.
An interrogator agent 320 is responsible for overall control over a single hardware device interface such as an RFID controller interface. An interrogator agent 320 interfaces with a hardware interface, the control manager 310, and a processing agent 330. The interrogator agent 320 receives data from the hardware interface. The interrogator agent 320
|
