Real-Time Computing for Twins
The control-relevant parts of a twin must produce answers within hard deadlines, which shapes their algorithms and hardware.
Deadlines, not just speed
Real-time computing is not about being fast on average; it is about guaranteeing an answer within a deadline every single time. A control loop that must run at a fixed rate cannot tolerate an occasional slow cycle. The parts of a twin that feed control therefore live under hard-real-time discipline, which constrains the algorithms, the software, and the hardware they use.
What determinism requires
- Bounded worst-case execution time, not just a good typical time
- Algorithms with predictable cost, avoiding iterations that might not converge in time
- Fast surrogates in place of unbounded physics solves
- A real-time operating environment that does not introduce unpredictable delays
Why surrogates are mandatory here
A full physics solve has variable and often long runtime, unacceptable in the loop. Surrogates provide a fixed, small, predictable cost, which is exactly what a deadline demands. This is one of the strongest practical reasons a twin invests in surrogate modeling: not only speed, but the bounded, repeatable timing that real-time control requires.
Separating fast from slow
The twin runs a fast path under real-time constraints for state estimation and control, and a slow path without deadlines for analytics, retraining, and full-physics checks. The slow path can correct and improve the fast path between deadlines, but never blocks it. This separation is a recurring theme across the twin architecture.
In the Kronos twins
Fusion control loops for the Hyperion breeder and the burner run at demanding rates, so their twin-derived functions are engineered for bounded timing from the start. The design is validated in simulation, on representative real-time hardware, before any machine exists, so that timing behavior is proven ahead of construction beginning in the second quarter of 2027. See latency and timing and coupling to control.