If you’ve ever been asked to “unify our RFID, BLE, and RTLS feeds into one dashboard,” then you already know the problem that seems simple on the surface, but gets complicated quickly. Industrial IoT projects often fail, not because one particular protocol is challenging to implement, but because no one designed for the eventual reality of running four or five location technologies simultaneously across the factory floor-each with different latency capabilities, failure modes, and varying ideas about what a “location event” entails.
In this post, we’ll discuss the crucial architectural choices when building the data layer beneath an industrial asset tracking or in-plant logistics system-the kind that needs to be able to accurately report “where is this forklift/cart/badge right now” well enough for a production planner to rely on.
Why relying on just one protocol is never a solution
While it might be appealing to standardize on a single location technology to simplify the system, in practice, this quickly becomes impractical:
- Passive RFID is affordable and excellent for capturing bulk inventory at choke points, such as when a pallet passes through a dock door. However, it is event-driven, not continuous; it only registers that an item has passed a reader, not its entire path between readers.
- BLE offers widespread and inexpensive zone-level presence detection, useful for locating people and assets across a facility, but the typical accuracy is at the room level rather than sub-meter precision.
- UWB/RTLS provides sub-meter accuracy, essential for applications like forklift-pedestrian proximity alerts. However, the infrastructure cost per square foot is considerably higher, so it is usually deployed in specific, critical areas rather than facility-wide.
- LoRaWAN is designed for long-range, low-power sensor telemetry, such as tracking temperature, humidity, or managing communication between distant buildings and the plant, but it is not designed for real-time positioning.
The architectural takeaway: You are not building a single pipeline, but rather a normalization layer. This layer will take diverse event types with different structures and consolidate them into a common spatial-temporal model so that downstream components like dashboards, alerting systems, and machine learning models can understand “location” as a singular concept.
A reference shape for the ingestion layer
A pattern that holds up reasonably well across deployments looks like this:
[Readers/Anchors/Gateways]
│
▼
[Protocol-specific edge adapters] ← normalize timestamps, IDs, signal metadata
│
▼
[Message broker / event bus] ← MQTT or AMQP, buffered for network drops
│
▼
[Event normalization service] ← maps raw reads → canonical "presence event"
│
▼
[Time-series / spatial store] ← this is where "where is X" actually lives
│
▼
[Rules & ML layer] ← congestion prediction, replenishment triggers, anomaly detection
A few key considerations for this design:
Prioritise edge-based normalisation where possible. RFID readers and BLE gateways frequently have highly variable clock accuracy. If you postpone timestamp synchronisation to the cloud, you’ll spend a considerable amount of time debugging false “teleportation” bugs caused by clock drift.
Model presence as an interval, not a single point. A simple schema might store (tag_id, timestamp, location).
A more robust design would be (entry time, exit time, confidence).
Most common queries for dwell time, zone occupancy, and congestion are actually interval-based, and transforming point-in-time events into intervals retrospectively is often challenging.
- Incorporate handling for missing reads from the start. Every location technology will have gaps-a badge that doesn’t transmit for 90 seconds, an RFID tag that is misread. Your normalisation layer must explicitly account for the possibility of “no signal equals not present,” or your occupancy metrics will subtly be incorrect.
Where machine learning truly adds value
Once you have clean presence and movement data, the more complex engineering challenges emerge further up the stack:
- Kanban and replenishment prediction primarily involves time-series forecasting: analysing consumption rates, production schedules, and inventory levels. However, the real sophistication lies in managing the noise introduced by the data (missed reads, delayed material movements) to avoid generating false shortage alerts.
- Station queue prediction can be significantly improved by modelling the plant floor as a graph, where stations are nodes and material/worker flow represents edges, rather than treating each station in isolation.
- Kitting and picking validation are ideal candidates for simple edge-based anomaly detection. For example, you can flag an unexpected RFID read at a kitting station before the cart even leaves the area, rather than having to catch it much later in the assembly process.
The integration layer determines project success
Ultimately, none of the technical aspects matter if the output doesn’t reach the systems where people actually work. For most manufacturing plants, this typically means integration with SAP or another ERP system, an MES, and sometimes a WMS. The most practical approach is to treat your normalized event store as the source of truth and push derived events (zone entries/exits, replenishment triggers, alerts) into these enterprise systems via a message broker. This approach minimizes the integration surface and makes it much easier to swap out sensor hardware in the future without modifying your core ERP/MES systems.
If you are navigating a multi-protocol industrial IoT architecture for a manufacturing environment, this in-depth look at integrating AI, RFID, BLE, UWB, and RTLS technologies specifically for ERP/MES interoperability goes into greater detail on common integration patterns.
Key Takeaway
The complexity of industrial IoT integration doesn’t stem from any single sensor technology; it lies in building a normalisation and data model layer that addresses heterogeneous, unreliable location signals as a critical engineering task rather than an afterthought. Getting this foundation right makes the ML and dashboard components much easier to build and maintain.
I’m open to diving deeper into any of these aspects – from event schema design and edge vs. cloud considerations to the machine learning side of things – in the comments below.
Curious how this looks in practice? PlantLog AI has a more detailed breakdown of how these pieces — RFID, BLE, UWB, RTLS, and the AI layer on top — come together for in-plant logistics, including the ERP/MES integration side. Worth a look if you're evaluating this kind of architecture for your own facility.
Top comments (0)