Plant twin projects rarely fail on the modelling. They fail on refresh, and they fail in a specific and avoidable way: somebody picks an interval — every thirty seconds, every five minutes — and applies it to the whole plant. The yard, the docks and the line feed then share a refresh rate that is simultaneously too slow for one of them and wasteful for the others. The research on this is unambiguous and slightly counterintuitive: frequent synchronisation raises cost and congests the data path, infrequent synchronisation biases the predictions and produces wrong decisions, and the fixed-interval policy most implementations default to is the weakest of the available options. The useful question is not how often, but on what. Talk to a solutions engineer.
Refresh Is a Trigger, Not an Interval
Why the yard, the docks and the line feed need three different models, how spatial and state modelling fail in opposite ways, and which simulation use cases need live data at all.
Spatial and State Are Two Models, Not One
Almost every difficulty downstream traces back to treating these as a single thing. They are built differently, they change at different rates, and they go wrong in ways that are not equally visible.
Geometry, areas, routes, capacities. It is comparatively static — a yard does not change shape weekly — and it is the part people build first because it is visible and demonstrates well.
Occupancy, status, sequence position, age. It is what every operational decision actually reads, it changes constantly, and it is the part that is usually underbuilt because it photographs badly.
A wrong spatial model is obvious and gets fixed. A wrong state model looks correct, renders beautifully, and is quietly out of date — which is the failure that survives a demonstration and reaches production.
The published reference architecture for manufacturing digital twins frames this from a domain and entity point of view, with a functional view specifying the functional entities the entity-based model supports. The practical reading is that what you are modelling and what you are observing about it are separate concerns, and collapsing them is a design decision rather than a simplification.
Three Zones, Three Requirements
Place the zones against what each one actually needs and the idea of a single plant-wide fidelity setting falls apart on sight.
The requirements are close to inverted. The yard needs real positional precision and changes a handful of times a shift. The line feed barely needs coordinates — position on a fixed route is implied by sequence — but its state has to be current within seconds and correctly ordered. Any single refresh rate chosen for both is wrong for both.
What Each Zone Needs, Concretely
The same comparison with the detail that actually goes into a specification. Swipe sideways on mobile.
| Zone | Spatial fidelity | State granularity | Refresh trigger | What goes wrong |
|---|---|---|---|---|
| Yard | Metre-level — which slot, which row | Coarse: arrived, parked, called, at door, gone | Gate read and each move | Trailers hunted on foot; the twin says row C and it is in row F |
| Docks | Discrete — there are twelve doors, not coordinates | Transitions matter more than status: occupied is less useful than occupied since | Door sensor and dock state change | Scheduling against a door that was released twenty minutes ago |
| Line feed | Barely spatial — position on a fixed route is implied by sequence | Fine-grained and ordered: which call, which position, which station | Each call, each delivery confirmation | Sequence drifts and an axle assembly reaches a station it was not built for |
| Line-side buffers | Shelf or location level | Count and age, because an old part at the front is still an old part | Pick and replenish events | First-in-first-out assumed and not actual, which traceability later has to unpick |
Note the fourth column. Every entry is an event rather than a duration, which is the whole argument of this page expressed as a specification. None of these zones is well served by a clock.
The fourth row is the one most often left out of a twin entirely. Line-side buffers hold small quantities for short periods, which makes them look unimportant next to a yard holding forty trailers. They are also where consumption order is actually decided, and a buffer modelled as a quantity rather than as an ordered set of items with ages is the reason first-in-first-out turns out, months later, to have been an assumption rather than a practice.
Worth checking this week
How stale is your twin at the moment it gets read?
Not on average — at the moment somebody makes a decision from it. For most fixed-interval twins nobody has measured this, and it is usually worse in exactly the busy periods where the twin is being relied on most.
Why Fixed Intervals Lose Twice
The clearest way to see it is a single yard trailer across a single shift.
Polling pays for twenty-four reads and is still wrong for up to a full interval after every real movement. Reading on change pays for three and is never wrong. The polling approach is worse on both axes at once, which is what makes it such a persistent choice — it feels conservative, and its cost is invisible because the reads all succeed.
This matches the formal result directly. Of the policies studied, a state-dependent one — synchronise when the state warrants it — performs close to what is achievable with full information and significantly better than a state-independent policy, which is what a fixed interval is. An approximate periodic state-dependent policy is reported as near-optimal, which matters practically: you do not need a perfect trigger, you need one that responds to change at all.
There is a second cost that rarely appears in the design. Polling every asset on a schedule produces a load profile that is flat by construction, which means it is sized for a quiet plant and offers no headroom when a shift genuinely gets busy. Event-driven load rises with activity, which is the shape you want, because the moments when more is happening are precisely the moments the twin needs to be accurate.
Which Use Cases Need Live Data
Fewer than people assume, and sorting this early removes most of the cost from a twin programme.
Needs an accurate spatial model and almost no live state. You are asking what would happen if, so the twin can be a snapshot. This is the cheapest genuine use case and usually the one skipped.
Needs modest spatial detail and current state, because it commits real resources. Staleness here converts directly into a trailer waiting.
Needs very little geometry and very fresh ordered state. The question is whether the next calls can be met, which is about order and timing rather than position.
Needs consumption state and replenishment events. Spatial detail adds nothing and adding it is how this use case gets delayed behind a modelling project.
The first entry is the one to start with. Layout and capacity questions are genuinely valuable, need no live feed at all, and can be answered from a snapshot while the state layer is still being built. Programmes that begin with the live-state use cases spend six months on plumbing before producing a single answer, and that is usually where the sponsorship runs out.
Where Vehicle Plants Differ
The zone analysis above is general. Two things make it sharper on a vehicle line.
The first is sequence. A chassis moves through stations in a fixed order and the parts feeding it have to arrive in that order, so the line-feed state model is not a set of quantities but an ordered list. A twin that tracks how many axle assemblies are at the station and not which ones, in what order, models the wrong thing — and it will look correct right up to the point a unit reaches a station expecting a variant that was consumed two positions earlier.
The second is that the yard holds finished goods as well as inbound material. A trailer in a yard may be carrying parts in or completed vehicles out, and those two have different urgency, different ownership and different consequences when the twin is wrong. The same positional discipline that keeps a maintenance record attached to the right unit applies here: an identity that follows the physical thing rather than the slot it happens to occupy.
How FleetRabbit Handles This
Oneflow is not a twin and does not try to be one. It supplies the layer a twin is usually missing — observed state, with evidence and honest timing — and leaves the geometry and the plan where they already are.
Oneflow records observations as they happen — a gate read, a move, a call confirmed — which is the state-dependent pattern rather than a scheduled sweep. The twin updates when something changed and stays quiet when nothing did.
Each record carries the moment it was actually taken, not the moment it arrived. Captures made during a connectivity gap queue on site and arrive batched without shifting the timeline they describe.
A partial scan or an unreadable label appears as held with the reason attached and cannot be selected until somebody resolves it. A twin that interpolates over a gap is confidently wrong, which is worse than visibly incomplete.
Oneflow does not own the layout, the schedule or the master data. It supplies the observed state layer that a twin needs and leaves the rest where it already lives.
Questions Plant Teams Ask
What refresh rate should a plant twin use?
None, as a single setting. Refresh should be triggered by change per zone — a gate read, a door transition, a line call — because a fixed interval is both wasteful when nothing is moving and stale when something is. Set Your Refresh Triggers.
Is more frequent synchronisation always better?
No, and this is established rather than a matter of opinion. Frequent synchronisation raises cost and congests the data path; infrequent synchronisation biases predictions and yields wrong decisions. The optimum is a policy that responds to state, not a higher frequency. See the Event Trigger.
Should we model the yard or the line feed first?
Whichever has a decision waiting on it. If trailers are being hunted on foot, model the yard. If sequence is drifting, model the line feed. Modelling both at once in one pass is how a twin becomes a two-year programme. Model One Zone First.
How much spatial detail do we actually need?
Only enough for the decisions being made. Docks are a discrete set of doors rather than coordinates. Line feed is a sequence rather than a map. The yard is the one zone that genuinely needs metre-level placement. Scope the Spatial Model.
Can we run simulations without a live feed?
Yes, and the most valuable early use case works exactly that way. Layout and capacity questions run against a snapshot, which means they deliver answers while the state layer is still being built rather than after it. Model One Zone First.
What happens to the twin during a network outage?
That depends on whether captures queue locally and arrive carrying their original timestamps. If they do, the twin reconstructs the gap correctly once the link returns. If they arrive stamped on receipt, the whole period is silently shifted. Review Your Twin’s Staleness.
Should the twin fill gaps by interpolating?
No. A twin that interpolates across a gap is confidently wrong and gives no signal that it is. Showing a reading as held, with the reason, is less satisfying to look at and considerably safer to act on.
Does a twin replace the MES or the planning system?
It should not. The plan and the master data belong where they already are; a twin adds a representation and, if you let it, a second opinion about things it never observed. Keeping the boundary explicit is the point. Talk to a Solutions Engineer.
Start with one zone
Build the State Layer the Twin Is Missing
Observations recorded when things change rather than on a clock, each carrying the time it was genuinely taken, uncertain readings held rather than interpolated, and no claim at all on your geometry, your schedule or your master data.
