Most RFID estates were purchased as identification systems and are now being asked to behave like IoT infrastructure. The reader that closes a dock-door workflow is expected to feed a digital twin, a maintenance model and a sustainability report without any change to its firmware. The gap between those two jobs is not a protocol upgrade. It is an architecture.
A reader knows one thing: that a tag was or was not observed, on this antenna, at this moment. Everything that makes the fact useful — where the goods came from, which process step it belongs to, whether the observation is trustworthy, and how it should change a business record — has to be added by something else. Convergence architecture is the set of components that add it, in a defined order, with a defined owner for each step.
A reader on the network is not a sensor in the platform
Connecting a reader to Ethernet is device connectivity. It is not integration, and confusing the two is the most expensive mistake in this space.
- LLRP is a control protocol for antennas and read cycles, not a data contract for business events.
- Vendor SDKs expose different object models; an application that calls them directly becomes a permanent dependency on one brand.
- A raw read carries an EPC, an antenna port and a device timestamp, but no location semantics, no process context and no quality flag.
- Readers keep their own clocks. Without a shared time source, events from two portals cannot be ordered.
- Firmware, certificates and configuration have a lifecycle of their own, and nothing in the business layer owns it.
Four layers and one event contract
The architecture that works separates four responsibilities and fixes the interface between them before any code is written.
- Capture layer: readers, antennas, GPIO, PLC signals and environmental sensors. Its job is to turn physical activity into timestamped observations.
- Edge layer: filtering, deduplication, zone logic and business rules. Its job is to turn observations into events with meaning.
- Fabric layer: message transport, state retention and an append-only history. Its job is to deliver events reliably and to keep the latest known state of every tag.
- Application layer: ERP, WMS, digital twin, analytics and alerting. Its job is to act on events and to own the business record.
- The contract is a schema, not a document: tag identity, event type, source, timestamp with clock source, location, confidence, schema version and an idempotency key.
- Each layer owns exactly one failure mode. When something breaks, the contract tells you which layer to inspect.
Capture layer: making the physical world countable
Capture is where physics becomes data, and where most silent data loss originates.
- Synchronise every reader and edge node to one time source. NTP is adequate for inventory; PTP is worth it when you correlate two portals, or a portal with a camera.
- Buffer locally. A reader or edge node should hold at least 24 hours of events, so a network outage becomes a delay rather than a gap.
- Read on demand where possible. Continuous inventory scans at full power cost spectrum, heat and neighbour complaints; schedule them.
- Instrument the antenna, not only the reader: reflected power and read rate per port catch a failing cable before it fails completely.
- Keep raw reads at the edge for a short window. They are diagnostic gold and should not be shipped to the cloud by default.
Edge layer: turning reads into events
The edge is not a thin proxy. It is where the semantics of your operation live, and it must keep working when the WAN does not.
- Deduplicate within a short window per tag and antenna, so one pallet passing a portal does not become forty reads.
- Model zones as a state machine: outside, approaching, inside, departing. Direction and dwell time come from state transitions, not from timestamps alone.
- Apply business filters at the edge — which tag patterns matter, which readers are authoritative for which zone, which events are suppressed during a known intervention.
- Run offline-first. If the broker is unreachable, the edge queues, persists and replays with the original event time intact.
- Treat configuration as code: versioned, reviewed and pushed over the air, so a hundred sites do not drift into a hundred behaviours.
Fabric layer: MQTT for state, a log for history
Two different questions need two different stores, and conflating them is a common design failure.
- MQTT is excellent for current state: retained messages per tag and per zone give any new subscriber an immediate, correct picture.
- Use QoS 1 with idempotent consumers, and last-will messages so a dead gateway is visible within seconds rather than at the next audit.
- Keep an append-only log — Kafka, Redpanda or a time-series store — for audit, replay and model training. MQTT retention is not an audit trail.
- Design topics by domain and location, not by device serial: site, zone, event class, then identity.
- Make every consumer idempotent using the event key. Retries are normal; duplicate business transactions are not.
Application layer: the read path and the write path differ
Dashboards and goods receipts have opposite requirements, and the architecture should admit it.
- The read path tolerates seconds of latency. A digital twin, a heat map or a fill-rate dashboard can be a few seconds stale and still be useful.
- The write path cannot. A goods receipt or a shipment confirmation needs a transaction, an idempotency guarantee and a clear owner.
- Keep the ERP as the system of record for quantities and values. Keep the event log as the system of record for what physically happened.
- Expose queries by tag, by zone and by time window, using the same contract the edge produces. Applications should never speak LLRP.
- Alert on freshness: a stream that is silent because nothing happened looks identical to one that is silent because a gateway died.
Latency budgets and failure domains
Write the budget down before the first pilot, then measure against it.
- Capture to edge: under 200 milliseconds. This is a local hop and should be almost free.
- Edge to broker: under 500 milliseconds on a healthy WAN, with store-and-forward beyond that.
- Broker to business record: under two seconds on the write path, under ten seconds for dashboards.
- Reader loss: the edge buffers, and the alarm fires on missing antenna data rather than on a failed ping.
- Network loss: dual-homed switches and a local queue turn an outage into a delayed batch.
- Broker loss: consumers reconnect and replay from the log while the edge keeps producing.
- Cloud loss: the site keeps operating, and the gap is reconciled automatically on recovery.
A deployment sequence that survives procurement
Convergence is usually sold as a platform and delivered as a project. Sequence it as a project.
- Start with one portal and one process, and instrument it completely before adding a second.
- Baseline for four weeks: read rate, latency, reconciliation gap and the number of manual interventions.
- Add the edge layer second and prove that the process still runs with the WAN disconnected.
- Add the fabric and the application last, with the write path tested against duplicate and out-of-order events.
- Avoid five anti-patterns: raw reads streamed to the cloud, applications calling vendor SDKs, unsynchronised clocks, MQTT treated as a database, and every system opening its own connection to the reader.
Convergence succeeds when the reader stops being a device that a vendor supports and becomes a source that the platform can reason about. That transition is architectural, and it is cheaper to design once than to retrofit across a hundred sites.






