Digital Twin Series · Level 3 · Live data
Real-Time Monitoring and State Synchronization
How does the twin stay in step with the real machine, and how do we know it is?
A live digital twin is only as good as its data. Sensor values are sampled, timestamped, sent over a network, processed and used to update the twin's state, and every step adds delay. This page lets you build the delay budget, see what a sampling rate can and cannot capture, see how a clock error can scramble the order of events, handle lost and late data, and watch a live state table go stale when the network fails.
| Use | Typical target for data age | Your worst case |
|---|
Total latency = network delay + processing delay, plus the wait for the next sample and the twin update. The sample wait is on average half the sampling interval and at worst a whole interval. The targets are typical examples, not standards. Fast motion control stays in the PLC and the drive; the twin sits beside it, not inside the fast loop.
| Signal | Typical sampling range | Use |
|---|
To see a frequency at all you need to sample at more than twice that frequency (the Nyquist limit). To see the shape of the wave you need many more samples per cycle, often 10 or more. A higher rate gives better accuracy but more data and network load, so use the lowest rate that serves the application.
Two devices stamp two events. If the clocks disagree by more than the gap between the events, the recorded order can be wrong, and root cause analysis goes wrong with it. Accuracy values are typical figures: NTP is about a millisecond or better on a local network and a few milliseconds over the internet; PTP with hardware timestamping reaches sub-microsecond. A free-running crystal clock drifts by its ppm figure.
A simulated 10 Hz temperature signal over 60 seconds. Samples can be lost, arrive too late or be out of range. Handling methods: hold the last valid value, or interpolate between valid values (which needs the next sample, so it adds a delay). Always flag the data quality so the twin and the user know how much to trust it.
| Parameter | Real machine | Twin | Age of twin value |
|---|
Simulated values. Each parameter updates at its own rate. The age is the time since the twin last received that value. A parameter counts as stale when its age is more than three times its update period. Try a network delay and an outage.
Figures are indicative and the simulations are simplified. Measure the delays, rates and clock errors on your own network and machine.