1. The station that had to choose what to keep running
Stanisław Lem’s Solaris returns as the recalled work because the Prometheus station is constantly making operational choices in a hostile environment: which experiments to run, which systems to power, which crew members to protect. The desktop is less dramatic but faces the same structure. It has a thermal budget, not just a power budget, and every high-dissipation task spends from both.
This entry wonders how the desktop schedules operations around thermal constraints and what it does when those constraints are violated.
2. Thermal-aware scheduling
A payload or compute job is not just an electrical load; it is a heat source. The autonomy must decide whether to run a task based on:
- the current temperature of the component and its neighbors;
- the predicted temperature rise during the task;
- the available heat rejection capacity, including radiator view factors and eclipse timing;
- the thermal state after the task completes, including recovery time;
- the value of the task relative to other tasks competing for the same thermal margin.
A high-value imaging pass might be deferred by ten minutes until the radiator has a better view of space. A batch compute job might be split into shorter runs with cooldown periods. A transmitter might be throttled when the power amplifier is hot. These are scheduling decisions, not just power decisions.
3. Thermal margins and thresholds
Thermal protection needs a hierarchy of thresholds, like electrical fault protection:
- Warning: a temperature is trending toward a limit; the autonomy logs and may pre-cool or defer optional loads.
- Caution: a temperature is near its operating limit; non-critical tasks are deferred and heaters or heat paths are adjusted.
- Critical: a temperature is near its survival limit; the autonomy enters a thermal emergency mode.
- Survival: a temperature has exceeded survival limits; the autonomy does whatever preserves hardware life, including shutting down subsystems.
The thresholds must account for sensor uncertainty and model error. A threshold that is too tight causes unnecessary shutdowns; too loose causes damage.
4. Emergency thermal modes
When thermal control is failing, the desktop needs predefined modes:
- Hot emergency: radiators are shaded, a heat path is blocked, or a payload is overheating. Response: shed heat sources, reorient if possible to expose radiators, activate backup heat paths, and notify ground.
- Cold emergency: a long eclipse, failed heater, or lost power has allowed temperatures to drop. Response: prioritize survival heaters, minimize load, and wait for sunlight or ground command.
- Thermal safe mode: a stable low-dissipation configuration that can persist until the thermal problem is understood. This is analogous to the ADCS safe mode but driven by temperature rather than attitude.
5. Coordination with power and ADCS
Thermal decisions cannot be made in isolation. A reorientation to cool a radiator changes the power collected by solar arrays and the pointing of payloads. A heater cycle consumes battery energy. A payload shutdown saves power but may also save heat. The thermal manager must negotiate with the power manager and the attitude manager, or a higher-level autonomy must arbitrate.
6. What this changes
- Scheduling must be thermal-aware, not just power-aware and value-aware.
- Thermal protection needs a hierarchy of thresholds and predefined emergency modes.
- Hot and cold emergencies require different responses, both aimed at preserving hardware.
- The thermal manager must coordinate with power and ADCS autonomy.
- The next entry will close the thermal wondering arc.