Digital Twin Data-Link Simulator

Telemetry Link

Update rate (Hz) 5

Packet loss 10%

One-way latency (ms) 120

Twin Sync Strategy

Physical Asset

Drive speed (rad/s) 2.4

Link State

Sync Accuracy

Angular error

0.0°

Packets/60

0 / 0

Time since last packet

0 ms

Mean error (10s)

0.0°

How it works

A digital twin only knows what its telemetry link tells it. The physical asset (left rotor) spins continuously at angle θ_p(t); a sensor samples θ_p at the chosen update rate and fires a packet toward the twin. Each packet independently survives with probability (1 − loss) and, if it survives, arrives after the configured one-way latency. The twin (right rotor) never sees θ_p(t) directly — only the packets that make it through:

packet_sent   = 1/rate seconds apart
packet_arrives = Bernoulli(1 − loss) after latency ms
twin state    = f(last arrived packets, strategy)

Three strategies for what the twin does between packets:

Hold-last — freeze at the last received angle. Simple, but drifts furthest whenever the link stalls.
Extrapolate — dead-reckon forward using the angular velocity estimated from the last two received packets: θ_twin(t) = θ_last + ω̂·(t − t_last). Tracks well if the real asset's speed is roughly constant, but overshoots through a gust.
Interpolate — smoothly blend toward each new packet's angle over a short window instead of snapping, trading a small constant lag for no visible jumps.

The angular error readout is |θ_twin − θ_physical| (shortest-arc), the real metric an industrial digital-twin operator watches to decide whether the twin can still be trusted for control decisions. Raising packet loss or latency, or lowering the update rate, starves the link and pushes that error up — exactly the "how connectivity affects a digital twin's accuracy and responsiveness" trade-off this simulator is built around.

Physical asset (ground truth) Digital twin (sync'd over link)

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.