RFID software typically performs a specific function such as keeping track of inventory in a warehouse or reordering inventory based on items removed from a shelf in a retail store. Based on data the application receives from the tags about the items (whether they be retail products, pallets, cartons, shipments or trucks), the application takes appropriate action.
Based on events within the enterprise, the software would also send information to the readers to write data on individual tags, such as the sale of an item, or an emptied pallet, or a code specifying that a shipment that has left a warehouse and is bound for a retail outlet.
RFID applications tend to be specific to a vertical industry, such as supply chain, retail, medical, warehousing, etc. A software engineer typically doesn'tand shouldn'tneed to develop expertise in RFID technology. Thus, multiple organizations are actively working to develop a systems interface layer that will let programmers work primarily at the application layer, without having to deal with the RFID hardware. This systems layer is called the RFID middleware layer.
Middleware is the glue that binds hardware components from lower layers to higher application layers. While in principle it's a horizontal technology, to make it industrially useful, it often has hooks to industry-specific verticals where needed.
In the specific context of RFID, the middleware layer performs additional functions such as:
- Making read/write more reliable
- Pulling and pushing data through a network of readers to the correct location (much like a router)
- Controlling and monitoring readers
- Allowing secure read/write operations
- Reducing RF interference
- Handling tag-based and reader-based events
- Notifying an application
- Accepting and forwarding interrupt commands from an application
- Alerting users about exceptions
Architecturally, the RFID middleware layer would typically be divided into sub-layers, with the lower layers focusing on functions relating to reading from and writing to the tag reliably, robustly, and securely.
The upper layers are linked to the applications and therefore would typically provide hooks for applications including functionality such as:
- Product shipment tables
- Product routing and planning tables
- Tag tables
- Reader tables
- Portal tables
- Enterprise IT systems such as billing, ERP, SCM, and CRM
- Handling tag code standards such as the Electronic Product Code
Such lower middleware layers create abstract classes for readers, tags, the RFID network, etc. When new technology such as a reader with new protocols is available, its characteristics can be incorporated into the middleware, thereby requiring minimal structural or even code-level changes to the software.
The upper middleware layers, in addition to having hooks for applications, may also include additional data functionality such as cross-referencing tag IDs with shipment IDs, or shipment IDs with location IDs, or tag time-stamps with expected time of arrival of a shipment. They can store/retrieve such information from the database, so RFID applications could typically refer to the database IDs instead of the tag IDs.
Having solid middleware in place means programmers can focus on developing the business logic for applications instead of having to understand different kinds of hardware. Within a given application, an enterprise might need to support readers and tags from different manufacturers, active as well as passive tags, tags operating at different frequencies/protocols, or tags with different read/write reliability and specifications. Middleware simplifies these problems. Eventually, middleware might be able to reduce the time it takes to integrate RFID hardware into existing applications.