When we talk to companies about digital twins, most people start with a clear picture in mind. Usually they think of a 3D model of a warehouse or production environment, maybe with live operational data on top of it, showing conveyor status, throughput, utilization and where the vehicles are.
These applications are useful and give a good overview of day-to-day operations. They belong to a recognized category of their own, just not the one the term "digital twin" describes.
Model, shadow, twin
Kritzinger et al. (2018) classify digital representations by how data flows between the physical and the virtual object. A digital model has no automated data exchange at all, as with a CAD layout, a laser scan or a 3D rendering. A digital shadow has an automated one-way flow, where a change in the physical system changes the digital object but not the other way round. Only when the flow is automated in both directions do the authors speak of a digital twin. Their review also found that published work on the highest stage was scarce, while models and shadows dominated.
That puts a plain 3D model at the bottom of the scale. On its own it is a drawing: accurate, useful for construction and layout discussions, and entirely disconnected from the running operation. Nothing about it changes when a lane fills up or a shift starts late.
Adding live data moves it up one step. Now it shows what is happening, and for questions about the present state that is the right tool. But it is one step of two. The data goes in and stops there, and the limits appear as soon as the question is about a different state than the current one.
Why live data is not enough
Take a block storage area. Live data shows that a lane is congested and that reshuffling moves are piling up. It does not tell you whether the cause is lane depth, the assignment of articles to lanes, or the sequence in which orders arrive, nor which of the three is worth changing. Answering that takes a model that can be asked what would happen if any of the three were changed — and results that reach the people and systems doing the work.
The same applies in production logistics: live data can show that a line is waiting for material or that buffers are filling up, but understanding whether the cause lies in replenishment, sequencing, transport capacity or production planning requires the process logic behind it.
That second half is the step most implementations stop short of. Results from the model have to arrive where the work is done: as a revised slotting plan, as an order sequence that balances load across areas, as transport orders dispatched to a mixed fleet of AGVs and AMRs over VDA 5050, or as postings written back into the WMS or ERP. Where a decision still passes through a person, the loop is closed manually rather than automatically. The distinction matters when specifying a system, because the two approaches require very different interfaces.
How W2MO closes the loop
In W2MO the connection runs over camera-based tracking, which keeps positions and inventory current without scanning, and over interfaces to SAP, WMS systems and REST endpoints, which carry results back into execution.
Both directions only pay off if the model in between has something to say. A digital twin of a warehouse is not mainly a twin of what the building looks like, but of how it works. It has to know which article sits where, how far a picker walks to get it, how long the handling takes, who is available on an early shift and how the order volume arrives over a day. W2MO models that logic first and generates the 3D view from it, so visualization and calculation do not have to be maintained as separate representations.
W2MO also has no physics engine, and that is a deliberate limit. It does not calculate how a pallet tips, how a load shifts or how a gripper deforms a carton, and it is not the tool to buy for those questions. Process times come from measurement instead of physical simulation, from video-based time studies, recorded machine data or values from comparable installations. For a warehouse that is the more useful basis. For most warehouse planning questions, cost and throughput depend less on the exact mechanics of one movement than on how several thousand of them add up over a shift.
Terminology matters less here than specification. If a tender asks for a digital twin, the return interfaces are where to look first: what is the system expected to write back, to which target, and how much of it without a person in between? The second question follows from the first. A model that holds only geometry and live status has nothing to send back, however good the interfaces are.
Our answer to both is the same model. In W2MO, layout, processes, resources and flows sit in one structure, which is what makes the results transferable: a slotting plan or an order sequence calculated for a planning scenario can go into live operation without being rebuilt for it. If you would like to see how this works in practice, get in touch — we are happy to share examples from W2MO projects where planning models, real-time data and operational systems are connected.
Source: Kritzinger, W.; Karner, M.; Traar, G.; Henjes, J.; Sihn, W. (2018): Digital Twin in manufacturing: A categorical literature review and classification. IFAC-PapersOnLine 51(11), pp. 1016–1022. https://doi.org/10.1016/j.ifacol.2018.08.474