RFID Middleware Architecture: Where Devices End and Business Logic Begins

Between the reader and the ERP there is a layer that nobody wants to own: middleware. It receives thousands of raw read events per minute, most of which are duplicates, and must produce a small number of business facts that finance and operations can defend.

Get the architecture wrong and the symptoms look like hardware faults — duplicate stock movements, stale quantities, events arriving out of order, or a portal that works until the network blips.

What must middleware actually do?

Five jobs, and only the first is about talking to readers.

• Device abstraction: manage readers, antennas, power, sessions and firmware across vendors.
• Event normalisation: convert vendor-specific reads into one schema with reader, antenna, timestamp, RSSI and EPC.
• Filtering and deduplication: collapse repeated reads of the same tag in the same zone into one logical event.
• Business enrichment: attach location, direction, order or pallet context.
• Reliable delivery: buffer, retry and replay so the ERP never sees a partial picture.

Anything that is not one of these five is business logic and belongs in the application layer, not in middleware.

What are the four layers?

A workable split is device layer, edge layer, business layer and integration layer. The names matter less than the boundaries.

• Device layer: LLRP or vendor SDK, reader configuration, antenna inventory, firmware state.
• Edge layer: runs on site, buffers locally, applies zone rules, survives network loss.
• Business layer: deduplication windows, session logic, direction inference, exception rules.
• Integration layer: adapters to ERP/WMS, idempotent APIs, mapping tables, audit log.

The most common architectural mistake is putting deduplication in the integration layer. It then runs after buffering, so a replay duplicates business documents.

Where does LLRP help and where does it hurt?

LLRP is a standard protocol for reader configuration and tag reporting, and it is the right abstraction when you have several reader vendors. One driver, one data model, one configuration path.

It is not a universal answer. Some vendor features — advanced antenna switching, on-reader filtering, custom tag data — are exposed only through proprietary SDKs. A hybrid design is normal: LLRP for the standard 80 %, vendor SDK for the specific 20 %, behind the same internal interface.

• Use LLRP for configuration, inventory control and standard tag reports.
• Use vendor SDKs for features LLRP cannot express.
• Never let the vendor SDK leak into the business layer; wrap it.

How should buffering and offline operation work?

Networks fail. A portal that loses its connection for 30 seconds must not lose 500 reads.

The edge layer needs a local queue with persistent storage, capacity for at least one shift, and a defined behaviour when it fills: drop oldest, drop newest, or block the line. Blocking a production line is usually unacceptable, so define it explicitly rather than discovering it.

• Persistent local queue, encrypted at rest.
• Capacity plan: peak reads per hour × hours of autonomy.
• Explicit overflow policy, documented and tested.
• Replay with idempotency keys so duplicates do not create duplicate documents.

What filtering and deduplication rules are actually used?

Three rules cover most deployments, and they should be configurable, not hard-coded.

Time-window deduplication: the same EPC in the same zone within N seconds counts once. Directional deduplication: an EPC seen on entry antenna then exit antenna within a window becomes a movement, not two independent reads. State-based suppression: if the ERP already has the item in the target location, the read is a no-op.

• Window length depends on the process: 2–5 s for a portal, 30–60 s for a shelf sweep.
• Direction inference needs antenna-level RSSI or sequence, not just timestamps.
• Log suppressed events for audit; do not discard them silently.

What monitoring does middleware need?

Middleware is where you can see the truth early, so instrument it.

Track read rate per antenna, event latency from read to ERP commit, queue depth, retry count and duplicate-suppression ratio. Alert on trends, not just failures: a slowly rising queue depth is a failing disk or a growing backlog, months before an outage.

• Per-antenna read rate and null rate over time.
• End-to-end latency p95, not average.
• Queue depth and replay count.
• Firmware and configuration drift across readers.

Bottom line

Middleware exists to turn noise into facts: abstract devices, normalise events, filter and deduplicate, enrich, and deliver reliably. Put deduplication before buffering, keep vendor code behind an interface, define your offline behaviour before the network tests you, and instrument the layer so degradation is visible while it is still cheap to fix.