Source-linked AI summary
Deciphering the Enigma of Satellite Computing with COTS Devices: Measurement and Analysis
Ruolin Xing, Mengwei Xu, Ao Zhou, Qing Li, Yiran Zhang, Feng Qian, Shangguang Wang
TL;DR
The effects of satellite thermal control and energy management on COTS computing capability and reliability remain an open question. The paper measures these interactions using a real satellite and reports temperature and energy constraints, motivating platform-aware task scheduling.
Problem
The effects of satellite thermal control and energy management on actual COTS computing capability and reliability, and how to schedule tasks within platform constraints, remain open questions.
Source: §1 · pp. 1–2Method
The authors measure COTS computing on a real satellite to study thermal-control and power-management effects and release the resulting datasets.
Source: §1 · p. 3, §7 · p. 13Results
Up to 10% reduction in computational performance from chip heating; the authors identify surface temperature and DoD as key platform constraints on onboard computing.
Source: §1 · pp. 2–3Takeaways & Limitations
The authors call for greater focus on scheduling computing tasks under platform constraints to support long-term stable execution.
Source: §1 · p. 3The study focuses on maximizing processed data volume rather than meeting real-time requirements.
Source: §2.2 · p. 4
Abstract
from arXiv · showhide
In the wake of the rapid deployment of large-scale low-Earth orbit satellite constellations, exploiting the full computing potential of Commercial Off-The-Shelf (COTS) devices in these environments has become a pressing issue. However, understanding this problem is far from straightforward due to the inherent differences between the terrestrial infrastructure and the satellite platform in space. In this paper, we take an important step towards closing this knowledge gap by presenting the first measurement study on the thermal control, power management, and performance of COTS computing devices on satellites. Our measurements reveal that the satellite platform and COTS computing devices significantly interplay in terms of the temperature and energy, forming the main constraints on satellite computing. Further, we analyze the critical factors that shape the characteristics of onboard COTS computing devices. We provide guidelines for future research on optimizing the use of such devices for computing purposes. Finally, we have released the datasets to facilitate further study in satellite computing.
1 INTRODUCTION
This section frames onboard COTS computing as constrained by satellite thermal and energy conditions, then reports measurements and calls for scheduling that respects those constraints. The study uses real-satellite experiments and releases data to support further work.
1 INTRODUCTION
- The open questions are how thermal control and energy management affect actual onboard computing capability and reliability, and how to schedule tasks within platform constraints.Existing temperature and energy models primarily support pre-launch analysis; real-world data could help integrate those models with satellite-computing simulations.Source: §1 · p. 2
- Real in-orbit testing is costly and difficult to interpret because the satellite is hard to maintain and environmental, payload, and workload factors vary together.The authors report more than 1,000 hours of experiments and release detailed datasets for future research.Source: §1 · pp. 2–3
- The study combines in-orbit experiments with a 1:1 terrestrial testbed and factor-focused experiments, collecting over 1,000 hours of investigative work and more than 10 million telemetry lines.Preparation and testing took two years, and data collection lasted six months.Source: §1 · p. 2
- Eclipse or daylight cycles mostly shift payload-chip and surface temperatures within ±5 °C, with start-to-end differences under 2 °C; timing matters more for short tasks than long ones.The authors suggest that short tasks may benefit from an eclipse-period launch, while long-task launch timing need not account for the cycle.Source: §1 · p. 2
- Approximately 6% of converted solar energy remains unused, while computing consumes 30% to 40% of energy; the authors attribute the mismatch to computation scheduling and energy-collection cycles.They suggest accounting for these cycles because residual solar energy is not consumed when the battery is full.Source: §1 · p. 3
- Chip heating can reduce computational performance by up to 10%, while a DoD rise from 25% to 30% can reduce battery lifespan by approximately 25%; surface temperature and DoD are key constraint metrics.The authors identify temperature and energy as significant limits on computing capability and reliability.Source: §1 · pp. 2–3
2 MEASUREMENT METHODOLOGY
The methodology uses the BUPT-1 satellite to study two COTS device types across computing workloads, collecting payload and satellite telemetry data and comparing controlled ground tests.
2.1 Real-world Satellite System
- BUPT-1 is a 12U small satellite in a Sun-synchronous orbit, providing a platform whose performance parameters slightly exceed mainstream 6U-and-smaller CubeSats.Source: §2.1 · p. 3
2.2 Onboard Devices and Experiments
- Experiments used Raspberry Pi 4B and Atlas 200 DK devices, with Pi-A and Atlas-B serving as primary devices and the other two as controls.Source: §2.2 · pp. 3–4
- Workloads included Raspberry Pi stress tests and image inference, plus Atlas image encoding, classification, and object detection, with Atlas inference using one or four threads.Source: §2.2 · p. 4
- The study targets maximizing processed data volume, since satellite tasks can tolerate some latency and are not focused on real-time requirements.Source: §2.2 · p. 4
2.3 Data Collection and Processing
- Collected payload data describes onboard device behavior, while satellite telemetry covers platform temperature, energy consumption, attitude, and orbit.Source: §2.3 · p. 4
- Experiments ran from March 22 to July 30 after about two months of stability testing, yielding over 22 GB of telemetry and over 30 GB of payload data.Source: §2.3 · p. 4
- To reduce irrelevant-factor effects, the researchers matched ground-test thermal alteration, synchronized device clocks to UTC, and generated identical command sequences on the satellite and ground.Source: §2.3 · p. 4
3 TEMPERATURE RESULTS
Temperature constrains onboard COTS computing differently across devices and operating conditions: chip heating throttles the Raspberry Pi, while sustained or concurrent Atlas workloads can overheat satellite structures. Space heating is slower than ground heating, and daylight-versus-eclipse starts have little measured effect on computing performance.
3 TEMPERATURE RESULTS
- During two days of typical operation, surface temperature stayed at or below 4°C for 90% of the time; during a nine-hour period without computing or communication, it ranged from 0 to 1°C.The nine-hour trace showed only slight variation with eclipse-to-daylight transitions.Source: §3 · p. 5
3.1 Chip/Surface Temperature Variations
- Raspberry Pi workloads heat the chip more than the surface, reaching about 82°C, whereas a full-capacity, four-thread Atlas run brings its surface to about 24°C after three hours.The devices have different thermal designs; the Pi's smaller chip surface restricts heat dissipation, while Atlas has added conductive plates.Source: §3.1 · p. 6
- As Atlas computing level rises from Low to Full, its satellite power and temperature increasingly approach the values measured under the same ground workloads.This comparison is reported for Atlas computing tasks across the tested levels.Source: §3.1 · p. 6
3.2 Overheating
- Atlas reaches the 30°C surface limit after 540 minutes alone, while two Atlas devices reach it around 40 minutes in and are eventually shut down.The two devices share an aluminum surface, intensifying surface-temperature rise under concurrent workloads.Source: §3.2 · pp. 7–8
- Raspberry Pi chip heating causes about 5% frequency throttling; YOLOv3 and YOLOv5 latency rises roughly 10% at saturation, while Atlas performance changes little with chip temperature.For Raspberry Pi inference tasks other than image segmentation, absolute inference time rises around 5% to 8%; Atlas satellite-ground performance differs by less than 1%.Source: §3.2 · p. 7
3.3 Heating Rate
- Satellite devices take 2–4 times as long as ground devices to reach saturation, and most satellite experiments reach maximum temperature only in their final 20% of a three-hour run.Intermittent computing is suggested as a way to reduce average temperature over time.Source: §3.3 · pp. 8–9
3.4 Daylight and Eclipse Zones
- Daylight-versus-eclipse starts barely affect Raspberry Pi temperatures, but Atlas ends with about 8°C chip and 5°C surface differences despite minimal task-performance differences.The authors attribute the temperature differences primarily to uneven solar irradiation and the devices' different thermal conductivity.Source: §3.4 · p. 9
4 ENERGY RESULTS
The energy results show periodic solar collection and substantial computing-related power use, with energy efficiency and safe battery operation dependent on workload and satellite power conditions.
4.1 Energy Harvesting Patterns
- In a typical cycle, solar power exceeds total satellite power while batteries are nearly full, leaving about 3Wh unutilized; solar power later falls to zero in eclipse.The energy subsystem handles generation, storage, and distribution using solar panels, rechargeable batteries, and power control.Source: §4 · p. 9, §4.1 · p. 10
- Solar collection cycles at both orbital and roughly 24-hour scales, with daylight yields clustering around 16Wh and orbital changes linked to sunlight exposure and panel angle.The EPS working mode shapes daily cycles, and increasing solar-panel power raises panel temperature, which must remain below its tolerance threshold.Source: §4.1 · p. 10
4.2 Energy Expenditure Breakdown
- Communication and computation consume 20% of battery DoD within 30 minutes, while computing energy can reach 30%–40% of short-term energy use and communication is usually around 5Wh per round.Over 24-hour intervals, collection and consumption differences generally do not exceed 20%.Source: §4.2 · p. 11
- Across two weeks, average DoD is 16%, but it reaches around 35% from day two to three and can briefly exceed 50%, alongside both unused solar energy and deficits during compute-intensive tasks.The authors recommend scheduling onboard COTS computing to use energy effectively without exceeding the DoD limit.Source: §4.2 · p. 11
4.3 Computational Energy Efficiency
- On Raspberry Pi, space-ground energy-use difference is around 2%, while Atlas differs by about 10%; ground inference counts are at least as high but consume more power.Energy consumption for processing 100 images and images processed per 60 minutes are compared in Tables 4 and 5.Source: §4.3 · p. 12, Table 4 · p. 12, Table 5 · p. 12
- Higher computational loads improve energy-efficiency ratios, but can elevate thermal risk; onboard task scheduling must account for both power and thermal constraints.The analysis attributes the improved ratio at higher load to additional power being channeled to computing.Source: §4.3 · p. 12
5 RELATED WORK
Related work spans real satellite systems, orbital edge computing, and research testbeds, while empirical validation remains difficult and simulations may diverge from real environments.
Satellite System and Measurement
- Satellite-system research includes real systems, measurement studies, and systems based on authentic data, but most work targets integrated terrestrial-satellite Internet systems.A smaller fraction studies specific computing tasks [74] or applications.Source: §5 · pp. 12–13
Orbital Edge Computing
- Orbital edge computing uses COTS devices for in-orbit processing, especially remote sensing, while energy consumption and task scheduling receive growing attention.In-orbit processing can extract insights from remote-sensing imagery or discard irrelevant data.Source: §5 · p. 13
Testbed for Satellite Research
- The field has relied on modeling and simulation, but limited empirical validation can make conclusions diverge from real scenarios; hardware-in-the-loop and physical testbeds add realism at substantial cost [74].StarryNet combines simulation flexibility with partial system realism.Source: §5 · p. 13
6 DISCUSSION ON RADIATION EFFECTS
The discussion describes radiation-related semiconductor effects and reports no SEE-caused computational errors in a six-month experiment with devices lacking special radiation hardening.
6 DISCUSSION ON RADIATION EFFECTS
- Single Event Upsets can flip memory or register bits and may be corrected in software, whereas Single Event Latchups can cause sustained current and irreversible spacecraft damage.Both are categories of Single Event Effects.Source: §6 · p. 13
- Protection approaches include Triple Modular Redundancy and Byzantine algorithms, alongside integrated software-hardware design [21, 72, 79].The paper notes that terrestrial high-performance COTS devices are expected to meet aerospace-grade reliability standards through such design.Source: §6 · p. 13
- In a six-month computational experiment, no SEE-caused errors were observed, and selected COTS devices with simple electromechanical and thermal modifications were broadly reliable against radiation effects at roughly 500 km LEO.The passage attributes less pronounced SEE effects in LEO to Earth’s magnetic field.Source: §6 · p. 13
7 CONCLUSION
The paper builds a real satellite system to study how thermal control and power management affect COTS computing constraints and task scheduling, and plans to release comprehensive datasets.
7 CONCLUSION
- The authors build a real satellite system to study thermal-control and power-management impacts on COTS computing constraints and task scheduling.The work aims to help further research on satellite computing systems through release of comprehensive datasets.Source: §7 · p. 13
- The paper plans to release comprehensive datasets to support further research on satellite computing systems.Source: §7 · p. 13
- The study focuses on the impact of thermal control and power management on onboard COTS computing.Its stated scope includes computing constraints and task scheduling.Source: §7 · p. 13