The short version
Start from the decision you want to make, instrument only what that decision needs, get time synchronisation and a stable spatial reference right, and validate the twin against measured reality before anyone simulates anything.
'Digital twin' covers everything from a dashboard to a physics simulation, which is why projects drift. ISO 23247 gives the manufacturing version a useful structure — observable elements, device communication, digital twin entities and user entities — and NIST has published use-case scenarios built on it. Borrowing that vocabulary keeps a programme honest about what is actually being modelled.
Start from the decision, not the sensors
Write down the question first: where does the bottleneck form on this line, which bay is blocked, how long did that pallet wait, would a second picker help. The question sets the required resolution — and usually reveals that four cameras and eleven sensors answer it, not a full-site instrumentation programme.
The layers
| Layer | Job | Where it usually breaks |
|---|---|---|
| Sensing | Cameras, PLC tags, RFID, environmental sensors | Unsynchronised clocks; no calibration record |
| Edge inference | Detection, tracking, counting, zone events on-device | Bandwidth blown by streaming raw video to the cloud |
| State model | Entities, positions, states over time | No stable spatial reference; IDs not durable across cameras |
| Event store | Append-only history you can replay | Aggregates kept, raw events discarded |
| Simulation and analytics | What-if, capacity, scheduling | Simulated before the twin was validated |
Three details that decide whether it works
- 01Time. Stamp events at capture, on a synchronised clock. Without that, fused camera and PLC events produce a plausible story about the wrong order of operations.
- 02Space. Calibrate cameras into one site coordinate frame and store the calibration as versioned configuration. When maintenance nudges a mount, the twin must fail loudly rather than silently shift its zones.
- 03Identity. A pallet seen by three cameras is one entity. Durable re-identification across views is the hardest part of the build and the part that makes replay trustworthy.
Validate before you simulate
Pick a shift, hand-count the ground truth for a handful of measures — throughput, dwell time, blocked minutes — and compare against the twin. Publish the error. A twin with a known five per cent error on dwell time is a decision tool; a twin with unknown error is a screensaver, and every simulation built on it inherits that uncertainty invisibly.
Keep the raw event history. Aggregates answer today's question; replay answers next quarter's, and it is the only way to test a new detector against last month's incident.
Cameras in workplaces carry privacy obligations. Run detection at the edge, keep only events and anonymised crops where possible, and document retention — the design choice that makes a works-council or DPIA conversation short.
What we would do in a pilot
One zone, real cameras and sensors, edge inference on Jetson-class hardware, an event store with replay, and a published accuracy comparison against a hand-counted shift before any simulation work begins.
Sources
- 01ISO 23247-1:2021 — Digital twin framework for manufacturing — ISO
- 02Use Case Scenarios for Digital Twin Implementation Based on ISO 23247 — NIST (AMS 400-2)
- 03Jetson Orin Nano Developer Kit User Guide — NVIDIA
Figures drawn from our own engagements elsewhere on this site are illustrative placeholders. Anything attributed above links to its public source.