Data update rate
Data update rate (also called data cadence) describes how frequently each stream feeding a digital twin changes, and how many concurrent objects must refresh together. It is not one plant-wide number. A PDF work instruction may never change after publish. A temperature point may write every 15 minutes into a historian. A tagged forklift fleet may report positions many times per second across hundreds or thousands of movers.
Plants care because demos hide the load. A pretty hall model can look live while only a handful of slow tags move. The architecture that paints a sensor value on a wall is not automatically the architecture that keeps concurrent locations coherent under shift traffic. Latency is the delay of one sample. Update rate is how often samples arrive and how wide the concurrent set is.
Sort twin providers by the hardest stream you need this quarter. If the job is manuals and slow SCADA points, many platforms suffice. If the job is live logistics positions, ask for proof at the object count and sample frequency you will run, not at the slide animation.
Key Components
Static content: Documents, CAD snapshots, and SOP pages that change on publish, not on a timer.
Sparse time series: Sensors and KPIs that update on minutes-to-hours intervals, often from SCADA, MES, or historians.
High-cardinality live streams: Many concurrent identities (people, vehicles, loads) each updating often, typically from RTLS.
Concurrent object count: How many identities the twin must place and refresh in the same window without dropping or freezing the map.
Write and render path: Ingest, store, and draw. A path built for sparse writes often fails first on render when thousands of locations move.
Applications in Manufacturing and Logistics
Operations teams use update-rate thinking when comparing twin demos. Ask what is consumed (documents, historian tags, RTLS positions), what is shown (labels, heat, live locations), and what is processed (aggregates versus per-object paths). Internal logistics under logistics optimization usually needs the high-cardinality path. A training twin may only need static geometry and manuals.
Engineering and OT teams size infrastructure from the same split. Sparse sensor twins sit next to existing historians. Live mover twins need a location engine and a map that stays interactive when every truck moves at once.
Benefits and Challenges
Benefit: honest bake-offs and fewer bought platforms that look live in a quiet demo and stall on a real shift. Challenge: vendors blur the categories on one slide. A twin built for concurrent movers can usually host slow sensors and static docs as extras. A twin built only for slow or static data often cannot grow into thousands of live positions without a redesign.
Related Terms
Latency is delay per sample. Spatiotemporal data and spatially oriented datasets describe place-plus-time records. Operational digital twins usually need higher cadence than static digital twins. RTLS is the common source for high-cardinality location.
Frequently Asked Questions
Is a 15-minute sensor update 'real time'? It is real enough for many process trends. It is not the same load as sub-second positions on a full forklift fleet.
Can one twin do all three cadences? A platform built for concurrent live movers can usually display manuals and sparse sensors. The reverse is the hard direction.
What should we ask in a demo? How many concurrent moving objects, at what sample rate, were in the live run. Then ask how static docs and slow tags ride the same map.
Does update rate replace the twin-type filter? No. Twin type (static, simulation, operational, predictive) still comes first. Update rate sorts operational demos that look alike on slides.