Twin Latency and Timing
End-to-end latency, from sensor to corrected estimate to action, sets what a twin can control and must be budgeted deliberately.
The latency budget
Every stage between a sensor reading and a resulting action adds delay: acquisition, transmission, ingestion, assimilation, prediction, decision, and actuation. The sum is the end-to-end latency, and it determines which phenomena a twin can react to. Fast instabilities demand short loops; slow drifts tolerate long ones. Designing a twin means budgeting this latency stage by stage and holding each stage to its share.
Where delay accumulates
- Sensing and digitization of the raw signal
- Network transport from diagnostic to compute
- Ingestion: timestamping, calibration, validation
- Assimilation and model evaluation to update the estimate
- Decision and command generation
- Actuator response, which has its own physical delay
Time alignment
Measurements arrive at different times and with different delays. A twin must align them to a common time base, accounting for each channel's known latency, or it will fuse data from different moments as if simultaneous, corrupting the estimate. Precise, shared clocks and characterized per-channel delays are prerequisites for correct assimilation.
Latency versus fidelity
There is a direct tension: richer models take longer, but longer loops react to less. The resolution is layering, a fast low-latency loop for control-critical states and slower high-fidelity analyses running alongside. The twin does not choose one fidelity; it runs several at the latencies each application can accept.
In the Kronos machines
The Hyperion breeder's plasma-control-relevant phenomena set tight latency targets for its fast estimation path, while blanket thermal and life-tracking functions run on much longer budgets. The burner's tandem-mirror plug dynamics similarly define its fast-loop latency. These budgets are set and tested in simulation now, before the hardware and its real diagnostic and network delays exist, so the architecture can meet them once built. See real-time computing.