Note N02 · September 2026
The radiator sets the throughput
In an orbital data centre the thermal envelope, not the die, decides sustained compute. That makes duty cycle a control problem rather than a provisioning one, and it is the strongest argument for reconfigurable fabric in orbit.
The claim
A radiator rejects heat as a fixed function of area and emissivity. Compute demand does not hold still. That mismatch is the whole design problem, and it is the one place where a reconfigurable fabric beats fixed silicon outright: the fabric can trade area for power at runtime, and a fixed accelerator cannot.
Three constraints that behave differently in orbit
Power is cheap, heat rejection is not. Continuous-illumination orbits make solar energy abundant. Rejecting the waste heat is radiative only, and radiator mass scales with peak load rather than average load. Sizing for peak means carrying mass you rarely use. Sizing for average is cheaper but requires compute with a degraded mode that is real rather than a throttle.
Radiation sets the service interval, not the failure rate. Single-event upsets are recoverable. Single-event functional interrupts cost availability, because recovery needs something outside the failed domain to notice and act. On a five-year mission there is no patch window and no hands-on service, so the recovery path has to be hardware that cannot itself be the thing that hung.
Data movement dominates the energy budget before arithmetic does. On the CMS Level-1 trigger datapath I built at CERN, the accelerator array was never the constraint. Keeping it fed across a clock-domain boundary was. The same shape appears in an orbital rack: inter-satellite optical links and the on-board memory hierarchy decide utilisation long before multiplier count does.
What I have built against each
Degraded-mode compute. At EPFL's Embedded Systems Laboratory I work on ASTRA, a CGRA toolchain targeting the Square Kilometre Array, and I am building a DMA engine for on-array data movement plus the compiler support in HELIOS to drive it. SKA and an orbital data centre are the same class of problem: a fixed power and cooling budget, a workload that must fit inside it, and a requirement that the mapping change after deployment without new silicon. A CGRA is one of few substrates where running the same kernel at half the power is a compile-time decision rather than a clock gate.
Recovery that does not depend on the thing that failed. At SpaceLocker I designed an analog safety board with voting logic, watchdogs and safe-mode fallbacks that recovers a payload autonomously from dead-on-arrival conditions. It is discrete logic on purpose. It has no firmware to corrupt. Alongside it I implemented a triple-redundant flash scheme with a self-healing bootloader, and 2-of-3 EEPROM voting with complement shadow fields for upset resilience. The complement shadow matters because plain triplication reports a stuck-at pattern as a clean majority. That hardware cleared ESA PDR and CDR and passed thermal vacuum, vibration and shock qualification.
Datapath, measured rather than simulated. At CERN openlab I built the programmable-logic pipeline feeding a transformer anomaly-detection model on an AMD Versal ACAP, with cycle-accurate latency probes in hardware. Measured end-to-end latency landed within 1.25 % of the Vitis estimate, which is the number I care about, because it means the model of the system was right before the board existed.
Three questions I would ask first
- What is the radiator area per kilowatt at the current design point, and what does the sustained-to-peak compute ratio look like once that is fixed?
- Is the degraded mode a frequency and voltage scale, or a different mapping of the workload? The second is worth far more and is much harder to retrofit.
- Where does fault-recovery authority live today, and does it share a power domain or a clock with the compute it is supposed to recover?
These are the questions I asked about a payload at SpaceLocker. The scale is different. The failure modes are not.