RFID Middleware & Software

What RFID middleware does

A UHF reader in a warehouse can report the same tag dozens of times per second. Multiply that by a few hundred tags and several antennas, and a single dock door generates thousands of reads every minute. None of that raw data answers the questions a business actually asks: Did pallet 48 leave the building? Which cartons are missing from this shipment? How long has this asset been in repair?

RFID middleware is the layer of software between the readers and business applications. Its jobs are to:

• Connect to and manage readers and their antennas.
• Filter and smooth raw reads into clean, reliable observations.
• Apply business rules to turn observations into events.
• Look up what each tag represents (product, asset, person, location).
• Deliver events to ERP, WMS, POS, MES or custom applications, and to dashboards and alerts.

If you are new to the hardware side, read Components of an RFID System and RFID Readers Explained first.

Why raw reads need filtering

Duplicates

Readers inventory continuously. A tag sitting in front of an antenna is read again and again - that is normal and actually useful for reliability. But business systems want one record per item, not one per read. The first job of middleware is de-duplication: collapse repeated reads of the same EPC within a time window into a single observation, while keeping useful metadata such as first seen, last seen, read count, antenna and peak signal strength (RSSI).

Stray reads

UHF signals reflect off metal racks, floors and vehicles. A dock door antenna may occasionally read a tag on a pallet parked at the next door, or on goods stored nearby. These stray or cross reads create false events unless filtered. Common techniques include:

• Minimum read-count or RSSI thresholds before a tag is accepted.
• Comparing RSSI across antennas and assigning the tag to the strongest one.
• Requiring a trigger - a motion sensor, light curtain or forklift arrival - so the reader only "listens" when something is moving through the portal.
• Ignoring known static tags (for example, tags on fixtures near the antenna).

Missed reads and smoothing

The opposite problem also exists. A tag present the whole time may not answer in every inventory round because of orientation, shadowing by other goods or interference. If software declared "item gone" every time a read was missed, inventory would flicker. Smoothing solves this: a tag is considered present until it has not been seen for a defined period, often tens of seconds for a dock door and longer for shelves or rooms. Tuning these windows is a key part of commissioning.

From reads to business events

Once reads are clean, middleware applies rules to produce events that match how the business thinks:

Direction detection at portals usually combines the order in which antennas on each side see the tag, changes in RSSI over time and, on capable readers, phase measurements. Simple systems use two antenna zones and a timing rule; more demanding ones fuse reader data with sensors.

Location and zones

Passive UHF RFID does not give precise coordinates by default; it tells you which antenna (and therefore which zone) saw a tag. Middleware maps every reader antenna to a logical location - "Dock Door 3", "Store Room Shelf B2", "Fitting Room" - and reports events in those terms. When readers are moved or added, only this mapping changes, not the business applications.

Finer location is possible with ceiling-mounted array readers that estimate position from beam steering, phase and RSSI, typically to within a metre or two depending on the environment. For many processes, though, a well-designed set of zones is all that is needed: you rarely need to know where on the shelf an item is, only that it is on the right shelf.

Architecture: edge vs cloud

Where should filtering and event processing happen? There are three common places:

• On the reader. Many modern fixed readers run embedded applications that de-duplicate, filter and publish events directly. Ideal for small sites.
• On an edge server at the site. Collects data from many readers, applies rules locally and buffers events if the internet link drops.
• In the cloud. Central multi-site visibility, analytics, long-term history and integration with cloud ERP or SaaS applications.

In practice, the best designs are hybrid: filter and create events at the edge, then send only meaningful events to the cloud. That cuts bandwidth by orders of magnitude and keeps critical local processes - a dock door, a gate, a production line - working during a network outage, which matters at many Indian sites where connectivity can be unreliable.

Integration: LLRP, MQTT, APIs and webhooks

Southbound: talking to readers

• LLRP (Low Level Reader Protocol) - an EPCglobal standard for configuring UHF readers and receiving tag reports over TCP. Most enterprise fixed readers support it, which lets middleware work with readers from different makers.
• Vendor SDKs and APIs - richer access to features such as advanced filtering, phase data or GPIO, at the cost of portability.
• Reader-native REST, MQTT or HTTP push - many current readers can publish tag events directly as JSON to a broker or web endpoint, which greatly simplifies small projects.
• Handhelds - usually Android devices running an app that uses the manufacturer's SDK, syncing with a server over Wi-Fi or mobile data. See handheld RFID readers.

Northbound: talking to business systems

• REST APIs - the business application asks questions ("where is asset X?") or middleware posts transactions ("goods receipt for PO 4512").
• Webhooks - middleware calls a URL in the business system when an event happens, such as an unauthorised exit.
• MQTT and message queues - publish/subscribe streams that many consumers can use at once, robust to temporary disconnections.
• File or database integration - still common with older ERPs: scheduled CSV exports or staging tables.
• EPCIS - the GS1 standard (ISO/IEC 19987) for recording and sharing "what, when, where, why" events with trading partners. EPCIS 2.0 adds JSON and a REST interface.

The data model: EPC to item or asset master

A tag usually stores only an identifier - an EPC such as an SGTIN, SSCC or GIAI (see EPC Encoding & Tag Memory). Everything meaningful lives in the database. A sound model typically includes:

• Tag table - EPC, TID, encoding date, status (active, killed, replaced).
• Item or asset master - product or asset details, linked to one or more EPCs over its life (tags get damaged and replaced).
• Location master - sites, zones and the antenna-to-zone mapping.
• Event history - every event with time, location, business step and the user or process that caused it.
• Relationships - parent-child links such as items in a carton or cartons on a pallet.

For SGTIN-tagged retail goods, the GTIN part of the EPC can be decoded to find the product, while the serial identifies the individual unit. For assets, the GIAI or an internal number links directly to the asset register.

Dashboards, alerts and device management

Operations teams interact with RFID through dashboards and alerts rather than raw data: live stock by location, shipments verified against orders, assets overdue for calibration, dwell-time breaches. Alerts should go to the people who can act - by app notification, SMS, email or a light stack at the portal - and should be rare enough that people do not learn to ignore them.

Equally important, but often forgotten, is device management: monitoring reader health, antenna connection status, firmware versions, configuration backups and time synchronisation. A disconnected antenna cable produces no errors in the business system - just silently missing data. Good platforms alarm when a reader that normally sees hundreds of tags an hour suddenly sees none.

Security of RFID software

• Change default reader passwords, disable unused services and keep firmware updated.
• Place readers on a separate network segment or VLAN, with only the required ports open.
• Use TLS for MQTT, REST and webhooks; authenticate every client with keys or certificates.
• Apply role-based access in the application, and log who changed reader settings or zone mappings.
• Remember that the tag identifier is not a secret; authorisation decisions must be made in the backend. More in RFID Security & Privacy.

Build vs buy

For most organisations, the hybrid route is the sweet spot: a proven middleware layer handles readers and events, while in-house or partner developers build the screens and integrations that make it fit the business. Whatever you choose, insist on open interfaces and the ability to export your data. If you would like help evaluating options, our RFID consulting team can assess your processes and recommend an architecture.