A container is scanned at receiving, then moved to storage, then to a production line. Your system shows it in storage. But the last confirmed read was two hours ago, the BLE signal has been intermittent, and nobody knows whether it has moved since.
Is the container in storage, or is that just the last place anyone saw it?
That gap between last recorded and currently verified is where many industrial tracking systems quietly fail. For anyone building in Industrial IoT, robotics, or Physical AI, the harder problem is not collecting more sensor data. It is knowing whether the data you have actually reflects an asset's identity, location, and state right now.
Different technologies, different observations
Industrial tracking usually combines several technologies. Each answers a different question.
RFID identifies tagged objects. It supports material identification, inventory tracking, production traceability, and checkpoint records. The catch is that missed reads happen, and a system that assumes every expected read will occur ends up with gaps in its history.
BLE provides proximity and approximate location observations. It is useful for knowing what is nearby, but it should not automatically be treated as exact coordinates. Its usefulness depends on the environment and deployment configuration.
UWB supports distance measurement and location estimation, which makes it a fit where more precise positioning is needed, such as mobile equipment within defined industrial areas. Real performance still has to be tested under your actual operating conditions.
Vision systems use cameras and computer vision for object recognition in factories, warehouses, and robotic cells. Obstruction and changing visibility can degrade what they see.
These technologies are not interchangeable. Each contributes a different kind of evidence.
Why sensor fusion is more than merging streams
Take the container example again. An RFID reader identifies it at a checkpoint, BLE gives proximity context, UWB contributes a position estimate, and a camera sees the object and its surroundings. Individually, each observation is limited. Combined, they can describe the asset's physical context much better.
But fusion is not just collecting readings from multiple devices. You have to ask:
- Do these observations refer to the same physical asset?
- Were they recorded at compatible times?
- Is the location information reliable enough to act on?
- Do any observations conflict?
- Does a missing measurement change how an event should be interpreted?
If you skip these questions, combining sources can add uncertainty instead of removing it.
Five data quality problems to design for
- Missing reads. An RFID tag goes undetected during a movement. If your logic assumes every movement generates an event, the history becomes incomplete.
- Stale measurements. A location stays in the system after the asset has moved. Distinguish the last known location from a verified current observation.
- Timing mismatches. A location update and an equipment event arrive with different timestamps. Correlating them without accounting for timing can lead to wrong conclusions.
- Conflicting measurements. Two sensors disagree. Flag the conflict and evaluate it instead of silently trusting one source.
- Communication gaps. A dropped connection can look like an asset that isn't moving. Your architecture should tell communication gaps apart from real inactivity.
A minimal way to model this
Here is a simplified Python sketch of the idea. It is not a production design, but it shows how to keep the "last known vs. verified" distinction explicit, separate a silent data source from a stationary asset, and surface conflicts instead of hiding them.
from dataclasses import dataclass from datetime import datetime, timedelta, timezone @dataclass class Observation: asset_id: str source: str # "rfid", "ble", "uwb", "vision" zone: str observed_at: datetime # when the sensor measured it, not when it arrived def location_status( obs: Observation, max_age: timedelta, source_last_heartbeat: datetime, heartbeat_timeout: timedelta, ) -> str: now = datetime.now(timezone.utc) if now - source_last_heartbeat > heartbeat_timeout: # The source itself has gone quiet, so we can't tell # "asset hasn't moved" from "we can't see anything". return "communication_gap" if now - obs.observed_at <= max_age: return "verified_current" return "last_known" def find_conflicts(observations: list[Observation], window: timedelta): """Return pairs of observations for the same asset, close in time, that report different zones. O(n^2): fine for a sketch, group by asset_id first if you have a lot of data.""" conflicts = [] for i, a in enumerate(observations): for b in observations[i + 1:]: if (a.asset_id == b.asset_id and a.zone != b.zone and abs(a.observed_at - b.observed_at) <= window): conflicts.append((a, b)) return conflicts Even this small version forces useful decisions. How old can an observation be before it stops counting as current? How close in time must two readings be before you compare them? Which source wins, or does a human review it? These thresholds should come from your environment, not defaults.
Test before you trust the fusion
Before combining technologies, set up a defined test area with a known set of assets and observation points, then compare individual sensors against combined observations.
| Test condition | What to evaluate |
|---|---|
| Normal operation | Baseline identification and location performance |
| Missed reads | Frequency of identity and event detection errors |
| Interference | Changes in observation reliability |
| Timing errors | Accuracy of event correlation |
| Conflicting observations | Ability to detect inconsistent measurements |
| Recovery | Behavior when observations become available again |
Useful metrics include identity error rate, location accuracy against reference positions, event detection reliability for movements and handoffs, and recovery behavior after missing or inconsistent data.
The goal is not to assume fusion always wins. It is to find out when combining observations actually adds useful information.
From tracking to physical state estimation
Knowing which asset you are looking at and roughly where it is covers only part of the picture. You also need to know whether those observations still describe the current situation. State estimation means interpreting available measurements, such as identity, estimated location, equipment observations, timestamps, and uncertain or missing readings, to form a picture of the system's current state.
This matters even more when AI systems use physical-world data to make recommendations. A model that treats a stale location as current can easily recommend the wrong action. Better identity and measurement context gives it a more honest basis for decisions.
Where this applies
The same problems show up in manufacturing (linking material identity to production records), logistics (visibility across storage and handoffs), construction and industrial transportation (equipment and material context across sites), and robotics (interpreting the objects a robot handles). Requirements differ in each, so sensor selection and evaluation should be based on your real operating environment.
Takeaway
Reliable tracking takes more than installing tags, readers, cameras, or positioning devices. Missing reads, stale observations, interference, and communication gaps belong in the system design, not in the exception handling. Combining RFID, BLE, UWB, vision, and equipment data can give useful physical context, as long as you measure how good that context actually is.
If you want to read further, Aperture Venture Studio has a research page on industrial identification, sensor integration, and measurement reliability under imperfect operating conditions.
How does your system handle "last known" versus "verified current" locations? I'd be curious what staleness thresholds and conflict rules have worked in practice.
