RTLS digital twin — a model that works because the locating feed is trustworthy.
RTLS digital twin programmes start with trustworthy locating feeds — we design the identity and location stream first; the twin second. Independent advisory.
Built on the same five-layer architecture as the RTLS programme — they share the event bus, the asset registry, and the semantic model.
Digital twins stall when the twin is prettier than the feed is trustworthy.
Feed honesty
A twin on late, sparse location events teaches the wrong lessons. Fix identity and latency first.
Question ownership
Every twin view needs a decision it changes this week — or it is a render farm.
Model hygiene
CAD and layout drift weekly in live sites. Budget change-control for the twin geometry.
Three reasons the model never makes it past the demo.
A twin earns its keep when an operator uses it to decide something. These are the patterns that stop that from happening.
Pretty 3D, no operations
The twin renders gorgeously in the executive briefing room but is never plugged into a live workflow. Nobody on the shop floor opens it. Nobody on the planning team trusts it. It is a visualisation, not a simulation.
Event stream isn’t there yet
The twin needs the live spatial and process event feed that the RTLS, MES, and IIoT programmes were meant to produce. Those event sources are partial, inconsistent, or batch-only. The twin starves.
Twin and reality diverge in 90 days
Layout changes, new equipment, revised SOPs, and vendor swaps drift the physical plant away from the twin. Without a governance model, the twin becomes wrong — quietly, then catastrophically.
Six layers between sensor stream and decision.
We design twins the same way we design RTLS programmes — from the decision back to the data, not the other way round.
The spine the twin runs on
Kafka, Pulsar, or AWS Kinesis — whichever your stack already speaks. The same bus that feeds the RTLS analytics layer feeds the twin. One event model, one source of truth, no parallel pipelines.
What is worth simulating
We start with the decision the twin must support — staffing, layout, throughput, scheduling — and scope the twin around that. Twins that try to model everything end up modelling nothing usefully.
3D model plus meaning
CAD or BIM ingest, asset registry binding, zone semantics, and process metadata. The twin knows what each object is, what state it can be in, and how it interacts with the rest of the workflow.
Discrete-event modelling
AnyLogic, FlexSim, or Siemens Plant Simulation running scenarios against the live state. Test staffing, routing, scheduling, and layout changes before they hit the floor. Output is a decision with a confidence interval.
Twin output, plant outcome
Every simulated decision is logged against the real-world outcome that follows it. The twin’s accuracy is measured continuously, not asserted in a slide deck. Drift triggers alarms, not surprises.
Keeping the twin honest
Change-control workflow that ties physical plant changes to twin updates. Ownership, SLA, and re-validation cadence defined before go-live. Twins age well only when somebody is paid to keep them aligned.
Three ways to bring us in.
Sized to the decision the twin has to support — not to a vendor roadmap.
Twin feasibility · 4 weeks
Decision scoping, event-stream audit, tooling shortlist, and a build-vs-buy recommendation. Output is a signed feasibility pack with a fixed-price build proposal.
Twin design · 8–12 weeks
Full reference architecture, geometry & semantic model, simulation logic, validation harness, and a pilot twin running against the live event bus. Ready to scale or hand to a systems integrator.
Twin build & deploy · 4–6 months
Production twin, integration with planning and ops workflows, operator training, governance model, and 90-day post-deployment validation. Fixed milestones, gated delivery.
Numbers from twins we have actually shipped.
Who builds industrial digital twins — and why the locating feed decides whether they run.
Platform vendors dominate the conversation: NVIDIA Omniverse for immersive 3D and collaboration, Siemens Xcelerator / Tecnomatix for plant simulation, Microsoft Azure Digital Twins for graph-based operational models, AVEVA for process-industry ops twins, plus discrete-event engines such as AnyLogic and FlexSim. Systems integrators and specialist twin houses configure those platforms well. RTLS vendors increasingly pitch “twin-ready” dashboards that are really 3D viewers on their own location stream.
The failure mode is consistent. The twin needs a normalised live event bus — zone entry/exit, dwell, throughput, asset state — from UWB, BLE-AoA, Passive RFID and MES/WMS sources with coherent identity and clock discipline. Without that spine the model is a beautiful offline simulation. omlox-style open location layers and AAS-conform semantics help, but someone still has to design the event model, edge normalisation and integration so Omniverse, AnyLogic or Azure DT are not each inventing their own truth.
What programmes get wrong: buying the visualisation first, then discovering the RTLS and MES feeds are batch, inconsistent or locked inside a proprietary API. Or scoping a photoreal twin when a discrete-event model against live occupancy would have paid back in one planning cycle.
We are tool-agnostic and sell no twin platform. Feasibility starts with the decision the twin must support, the event stream you already own, and a build-vs-buy call. Where the feed is not ready, we say so — and often fix the locating layer via platform build before the twin spend.
Who builds industrial digital twins — and why the locating feed decides whether they run.
Platform vendors dominate the conversation: NVIDIA Omniverse for immersive 3D and collaboration, Siemens Xcelerator / Tecnomatix for plant simulation, Microsoft Azure Digital Twins for graph-based operational models, AVEVA for process-industry ops twins, plus discrete-event engines such as AnyLogic and FlexSim. Systems integrators and specialist twin houses configure those platforms well. RTLS vendors increasingly pitch “twin-ready” dashboards that are really 3D viewers on their own location stream.
The failure mode is consistent. The twin needs a normalised live event bus — zone entry/exit, dwell, throughput, asset state — from UWB, BLE-AoA, Passive RFID and MES/WMS sources with coherent identity and clock discipline. Without that spine the model is a beautiful offline simulation. omlox-style open location layers and AAS-conform semantics help, but someone still has to design the event model, edge normalisation and integration so Omniverse, AnyLogic or Azure DT are not each inventing their own truth.
What programmes get wrong: buying the visualisation first, then discovering the RTLS and MES feeds are batch, inconsistent or locked inside a proprietary API. Or scoping a photoreal twin when a discrete-event model against live occupancy would have paid back in one planning cycle.
We are tool-agnostic and sell no twin platform. Feasibility starts with the decision the twin must support, the event stream you already own, and a build-vs-buy call. Where the feed is not ready, we say so — and often fix the locating layer via platform build before the twin spend.
Frequently asked questions.
What kind of RTLS digital twin do you enable?
Operationally useful twins built on the event stream you already own - for flow, capacity, and what-if analysis - not visual demos.
Which tools do you use?
We are tool-agnostic and work with platforms such as AnyLogic, FlexSim, and Visual Components based on your needs.
Do digital twin locating feeds require RTLS first?
A live location and event feed makes a twin far more valuable, but we can start from existing data and add real-time later.
What decisions does it support?
Layout changes, capacity planning, bottleneck analysis, and testing changes before you commit capital.
Last updated: 13 September 2026