Paper deep dive
PHOENIX: Fine-Tuned SLM-Powered Autonomous Satellite Lifetime Extension via Predictive Self-Healing and Multi-Agent AI Recovery
Sumaiya Islam, Harsha Kumara Moraliyage
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%
Last extracted: 8/10/2026, 4:18:53 AM
Summary
The paper introduces PHOENIX, an autonomous satellite health management system designed to extend the operational lifetime of CubeSats. It utilizes a fine-tuned Small Language Model (SLM) onboard the satellite to perform predictive self-healing and fault reasoning during periods without ground contact. The system employs a semantic cache to resolve recurring faults efficiently and generates compact health reports for ground-based multi-agent AI systems to validate and execute recovery commands. The approach addresses the limitations of traditional threshold-based detection and the data scarcity of real-world satellite faults by using synthetic data generation via Diffusion Probabilistic Models (DDPM).
Entities (10)
Relation Signals (7)
CubeSat → operatesin → Low Earth Orbit
confidence 95% · a CubeSat in low Earth orbit (LEO) is physically unreachable from the ground
Phoenix → uses → Small Language Model
confidence 95% · A fine-tuned Small Language Model (SLM) compact enough to run on embedded hardware is deployed onboard the CubeSat
Phoenix → evaluatedon → ESA Anomaly Detection Benchmark
confidence 93% · We report preliminary results on the ESA Anomaly Detection Benchmark
Phoenix → runson → Aethero NxN-ECM
confidence 92% · running on the flight-proven Aethero NxN-ECM computer
Phoenix → generatesdatausing → DDPM
confidence 91% · A generative diffusion model (DDPM) creates synthetic training data
Phoenix → utilizes → FAISS
confidence 90% · checks a FAISS semantic cache of past fault resolutions
Ground Agents → processes → Health Report
confidence 88% · six specialized AI agents on the ground read that report and generate validated satellite commands
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Most CubeSats, small and low-cost satellites roughly the size of a shoebox, do not survive as long as they were designed to: a study of 178 missions found that only 48-65% remain operational after two years, against a designed lifetime of 2-5 years. The deeper issue is that a CubeSat in low Earth orbit (LEO) is physically unreachable from the ground for roughly 85 minutes out of every 96-minute orbit, so faults that start during that window go unnoticed until the next contact pass, by which point recovery may no longer be possible. We propose PHOENIX (Predictive Health On-orbit Edge Neural Intelligence eXtension) to give the satellite its own fault reasoning capability. A fine-tuned Small Language Model (SLM) compact enough to run on embedded hardware is deployed onboard the CubeSat, running on the flight-proven Aethero NxN-ECM computer, monitoring all sensor readings continuously, and resolving recurring faults using a memory system that stores past repairs so the same inference does not need to run twice. Once per orbit it sends a short structured health report to the ground instead of a raw data dump; six specialized AI agents on the ground read that report and generate validated satellite commands within the 5-10 minute contact window. A generative diffusion model (DDPM) creates synthetic training data because real fault examples make up only 0.57-1.80% of the dataset. We report preliminary results on the ESA Anomaly Detection Benchmark (14 years, 76 channels, 118 labeled faults).
Tags
Links
- Source: https://arxiv.org/abs/2608.07126v1
- Canonical: https://arxiv.org/abs/2608.07126v1
Trouble viewing inline? Open PDF directly →
Full Text
29,003 characters extracted from source content.
Expand or collapse full text
PHOENIX: Fine-Tuned SLM-Powered Autonomous Satellite Lifetime Extension via Predictive Self-Healing and Multi-Agent AI Recovery Sumaiya Islam Harsha Kumara Moraliyage Abstract Most CubeSats, small and low-cost satellites roughly the size of a shoebox, do not survive as long as they were designed to: a study of 178 missions found that only 48–65% remain operational after two years, against a designed lifetime of 2–5 years [1]. The deeper issue is that a CubeSat in low Earth orbit (LEO) is physically unreachable from the ground for roughly 85 minutes out of every 96-minute orbit, so faults that start during that window go unnoticed until the next contact pass, by which point recovery may no longer be possible. We propose PHOENIX (Predictive Health On-orbit Edge Neural Intelligence eXtension) to give the satellite its own fault reasoning capability. A fine-tuned Small Language Model (SLM) compact enough to run on embedded hardware is deployed onboard the CubeSat, running on the flight-proven Aethero NxN-ECM computer, monitoring all sensor readings continuously, and resolving recurring faults using a memory system that stores past repairs so the same inference does not need to run twice. Once per orbit it sends a short structured health report to the ground instead of a raw data dump; six specialized AI agents on the ground read that report and generate validated satellite commands within the 5–10 minute contact window. A generative diffusion model (DDPM) creates synthetic training data because real fault examples make up only 0.57–1.80% of the dataset. We report preliminary results on the ESA Anomaly Detection Benchmark (14 years, 76 channels, 118 labeled faults). I Introduction CubeSats have made orbital missions accessible to universities and small research groups that could not otherwise afford them. That accessibility comes with a trade-off: the low-cost hardware fails at a much higher rate than traditional spacecraft. Langer and Bouwmeester [1] tracked 178 missions and found fewer than two-thirds still operating at the two-year mark, against designed lifetimes of 2–5 years, with failures clustering early rather than at random (Section I-A). A system that could read those degradation curves in time would have a chance to respond. The obstacle is radio geometry. A CubeSat in low Earth orbit is visible to a ground station for about 5–10 minutes per orbit, 3–5 passes a day, roughly 30–40 minutes of contact out of 1,440. For the remaining 85 minutes of every 96-minute orbit there is no radio link at all: a satellite below the horizon cannot be reached, however sophisticated the ground infrastructure. Large operators use relay satellites like NASA TDRS; CubeSat programs instead depend on volunteer networks like SatNOGS. So when a battery cell degrades or a reaction wheel bearing shows early wear, the satellite is on its own until the next pass, and the fault may have already cascaded by then. What exists today for onboard protection is mostly threshold checking: if a voltage reading goes outside a preset range, an alarm fires. Horne et al. [6] showed small neural networks do better, reaching 89.1% CEF0.5 on a flying CubeSat with only 192KB of RAM, but detection alone does not say what will break next week or what to do about it. ATSADBENCH [4] found general-purpose LLMs perform poorly on multivariate aerospace telemetry, with RAG offering no meaningful improvement, so fine-tuning appears to be the only viable path to domain-specific reliability. PHOENIX is our attempt at that path. The idea is to deploy a fine-tuned SLM onboard the CubeSat so the satellite can reason about its own health during the silent phase. The SLM uses TLE orbital data from SatNOGS to distinguish genuine faults from expected orbital physics, checks a FAISS semantic cache of past fault resolutions before running full inference, and compiles a structured health report for each contact pass. On the ground, six fine-tuned LLM agents process that report and generate CCSDS telecommands within the window. A DDPM diffusion model handles the data scarcity problem: anomaly density in ESA-ADB is only 0.57–1.80%, so synthetic fault sequences are needed to train on rare failure modes. I Literature Review I-A CubeSat Reliability and Failure Statistics The most comprehensive failure study to date is the CubeSat Failure Database compiled by Langer and Bouwmeester [1], covering 178 missions. Their Kaplan-Meier curves show reliability falling to 75–87% right after deployment, then 59–73% at 100 days, and only 48–65% at two years. The Weibull shape parameter β=0.4797β=0.4797 indicates infant mortality: failures cluster early rather than distribute uniformly, precisely the window an onboard AI could intervene. EPS and COM account for most early losses (44% at 30 days, 29% at 90), which is why PHOENIX monitors those subsystems first. I-B Onboard Anomaly Detection for CubeSats Horne et al. [6] ran ANN-based anomaly detection directly on a flying CubeSat (EduSat, STM32 ARM Cortex-M4, 192KB RAM), reaching 89.1% CEF0.5 on 9 temperature sensors and proving neural inference fits inside CubeSat memory budgets. But detection is only half the problem: the system flags an anomaly and stops there, with no estimate of time-to-failure, no repair attempt, and no memory of what worked last time. Goetze et al. [5] pushed further with a forecasting-plus-threshold approach on ESA-ADB, reaching 88.8% CEF0.5 at a 59KB footprint (97.1% RAM reduction) and defining the detection baseline PHOENIX is measured against. I-C LLMs for Aerospace Telemetry Liu et al. [4] ran the first systematic evaluation of LLMs on aerospace time series anomaly detection across 9 tasks (ATSADBENCH): off-the-shelf LLMs handle univariate signals reasonably well but break down on multivariate telemetry, and RAG does not help. For satellite operations, fine-tuning on domain data is not optional; it is the only path to reliable performance on real spacecraft signals. I-D Multi-Agent LLM Systems for Maintenance Park et al. [8] showed a four-agent LLM system (Supervisor, Chatbot, Solution Finder, Actor) could respond autonomously to CNC machine alarms using on-premise Qwen 3, coordinating without human intervention to produce actionable maintenance steps. PHOENIX borrows this coordination idea but makes two changes: it replaces RAG with fine-tuning (motivated by the ATSADBENCH findings) and applies the pattern to satellite commanding, where an incorrect action is potentially mission-ending, not just inefficient. I-E Semantic Caching Theory Liu et al. [3] treat semantic caching as a combinatorial multi-armed bandit problem and prove a simple greedy eviction policy gets within (1−1/e)≈0.632(1-1/e)≈ 0.632 of the optimal offline solution; their online algorithm CLCB-SC-LS adapts as query distributions change over time. Satellite fault distributions shift similarly across the mission as components wear, so a cache that cannot adapt would degrade in usefulness, which is why PHOENIX uses CLCB-SC-LS rather than a plain LRU scheme. I-F Self-Healing AI Architectures Manju and Srivastava [7] built an AI-integrated self-healing system for IoT edge networks, combining lightweight anomaly detection with autonomous recovery; it improved both detection accuracy and recovery time over rule-based alternatives. The satellite domain shares IoT’s structural challenge: resource-constrained edge nodes that must handle faults without a reliable path back to a central controller. I-G ESA Anomaly Detection Benchmark Kotowski et al. [2] released ESA-ADB, covering 17.5 years of telemetry from two ESA missions (176 channels, 1.55 billion data points, 844 annotated events across 54 classes). The benchmark defines CEF0.5, which weights precision over recall since operations engineers tolerate missed detections far better than false alarms that trigger unnecessary commanding. We use ESA-ADB Mission 1 throughout. I PHOENIX System Architecture I-A Architecture Overview At its core, PHOENIX is two AI systems that talk once per orbit. The onboard SLM runs continuously on the CubeSat, handling everything during the silent phase, while the ground-side multi-agent team wakes at each contact pass, reads the health report the SLM produced, and sends back commands. The health report replaces the traditional raw telemetry dump, so limited downlink bandwidth carries actionable information rather than 487,448 float readings per channel per pass. Target Hardware. We target the Aethero NxN-ECM, which carries an NVIDIA Jetson Orin NX (157 TOPS INT8, 8–16GB LPDDR5 RAM) and has flight heritage on the SpaceX Falcon-9 Transporter-16. Del Prete et al. [9] fit AI models under 1MB with 3× faster inference than hand-tuned baselines on the same Jetson family for ESA. The ARM Cortex-M4 used by Horne et al. [6] had 192KB RAM; the Aethero has roughly 40,000 times more, so the resource concern for onboard AI is real but less severe than five years ago. Onboard SLM. We use TinyLlama 1.1B or Phi-1.5 1.3B, quantized to INT4 via llama.cpp and fine-tuned with LoRA adapters on satellite telemetry data. Estimated inference power draw is 2–5W. Fig. 1 shows the full architecture. I-B Phase 1: Orbit-Aware Semantic Data Suppression The SLM monitors all sensor streams every few seconds: battery voltage, solar panel current, subsystem temperatures, reaction wheel speed, attitude sensor outputs, and radio transceiver health. The core operation is a semantic suppression decision: rather than applying a fixed threshold per channel, the SLM reasons over the full multi-channel context, asking whether a reading is anomalous or expected given the current orbital phase and recent history. Orbit-aware context. TLE (Two-Line Element) data from SatNOGS observations gives orbital phase per reading timestamp, letting PHOENIX distinguish physics-driven variation from genuine faults. A battery voltage dip during eclipse entry is suppressed; the same dip 20 minutes after sun acquisition is flagged as an EPS anomaly. Threshold-based systems cannot make this distinction and generate persistent false positives that desensitize operators over time. Del Prete et al. [9] demonstrated 85% data volume reduction using hardware-optimized AI on Jetson hardware; PHOENIX targets comparable suppression with the added benefit of orbital context. I-C Phase 2: Semantic-Cache-Assisted Self-Healing Before asking the SLM to reason about a detected fault, PHOENIX first checks a semantic cache: a lookup table in flash memory holding past fault descriptions alongside the repairs that worked. FAISS compares the current fault against stored ones; if close enough to a known past fault (similarity above 0.92), PHOENIX applies the cached repair directly in microseconds without running the SLM. If no match is found, the SLM reasons through the fault and the new solution is saved. Algorithm 1 formalizes this. Algorithm 1 PHOENIX Onboard Cache-Assisted Healing 0: Anomaly descriptor a, cache C, threshold τ=0.92τ=0.92 1: e←embed(a)e (a) 2: (a^,r^,s)←FAISS-search(C,e)( a, r,s) -search(C,e) 3: if s≥τs≥τ then 4: Cache HIT: apply cached repair r r (microseconds) 5: Log action; skip SLM inference entirely 6: else 7: Cache MISS: invoke fine-tuned SLM with context a 8: r∗←SLM-reason(a)r^* -reason(a); apply r∗r^* 9: Insert (a,r∗)(a,r^*) into C with LRU eviction 10: end if The motivation is that many satellite faults repeat on a predictable schedule: battery voltage dips at every eclipse entry, reaction wheel stress patterns repeat every 96-minute orbit. Liu et al. [3] prove this greedy cache policy reaches at least (1−1/e)≈63%(1-1/e)≈ 63\% of the best theoretically possible solution, and their adaptive algorithm keeps performance stable as fault patterns shift over the mission. PHOENIX exploits this: the SLM handles a fault type once, the cache handles every repeat at near-zero energy cost. Reactive self-healing (active fault, cache miss): reaction wheel overheating shifts load to the magnetorquer; a solar panel output drop redistributes load; a sensor failure activates a redundant sensor; a battery drain anomaly sheds non-critical loads. Predictive self-healing (fault not yet occurred): The fine-tuned SLM recognizes early degradation signatures from training: a battery cell voltage curve matching the slow-drop pattern observed in ESA-ADB training data three weeks before confirmed cell failure triggers a ground-destined warning with a failure timeline estimate. This is absent in all prior CubeSat onboard AI works [5, 6] and is the primary mechanism by which PHOENIX extends mission lifetime. I-D Phase 3: Compact Health Report Transmission At the start of each downlink pass, PHOENIX transmits a compact structured health report instead of a raw telemetry dump. The report contains three fields: self_healed (list of faults resolved autonomously), predicted_risks (degradation warnings with failure timeline estimates), and needs_ground (unresolved events requiring operator action). The downlink window delivers actionable intelligence rather than raw numerical logs, freeing bandwidth for science data. I-E Ground Multi-Agent Fine-Tuned LLM System When the health report arrives at the ground station, six AI agents process it in a pipeline. Each agent is a separate instance of Llama 3.1 8B fine-tuned on data relevant to its role, coordinated by a workflow framework (LangGraph or AutoGen) that passes each agent’s output to the next automatically. Fine-tuning is used instead of RAG because a recent benchmark [4] found that database lookups do not meaningfully improve accuracy on spacecraft telemetry; domain-specific training does. Table I lists each agent and its training data. TABLE I: Ground Multi-Agent Team: Roles and Fine-Tuning Data Agent Fine-Tuning Data Supervisor Coordination logs, workflow patterns Triage ESA-ADB anomaly labels, severity records Memory SatNOGS logs, ESA operational reports Diagnosis Root cause reports, FMEA catalogs Command CCSDS Blue Books, operator command logs Safety Constraint tables, failure mode catalogs The pipeline runs as: Supervisor assigns tasks, Triage classifies severity, Memory retrieves historical context, Diagnosis identifies root cause, Command generates telecommands, Safety validates, and Supervisor approves before commands are uplinked. No command reaches the satellite without both Safety Agent validation and Supervisor approval, addressing the risk of irreversible damage from an incorrect command. Phase 1: Orbit-AwareSemantic SuppressionPhase 2: Cache-AssistedSLM Self-HealingPhase 3: HealthReport GeneratorOnboardSensorsTLE Context(SatNOGS)SupervisorTriageMemoryDiagnosisCommandSafety CubeSat (Aethero NxN-ECM, NVIDIA Jetson Orin NX) Ground Station (Llama 3.1 8B ×6, LangGraph / AutoGen)Health Report(downlink)CCSDS Telecommands(uplink) Figure 1: PHOENIX end-to-end system architecture. The onboard SLM runs three continuous phases on the CubeSat. Compact structured health reports are downlinked each contact pass to six LoRA fine-tuned ground agents, which produce validated CCSDS telecommands for uplink. I-F Fine-Tuning and DDPM Augmentation Onboard SLM. LoRA fine-tuning on TinyLlama 1.1B uses: (a) ESA-ADB Mission 1 with 487,448 readings per channel, 118 labeled anomalies across 4 subsystems; (b) SatNOGS Network API with 702 verified payloads from 16 CubeSats including TLE orbital context; (c) ESA Kelvins Mars Express power degradation data covering 3 Martian years of EPS telemetry; and (d) DDPM-generated synthetic fault sequences. Fine-tuning protocol. LoRA adapters target the query and value projection matrices (r=16r=16, α=32α=32, dropout 0.05), trained for 3 epochs with AdamW at learning rate 2×10−42× 10^-4. ESA-ADB Mission 1 is split chronologically: 2000–2009 train, 2010–2011 validation, 2012–2013 test. Two anomaly classes from anomaly_types.csv are additionally held out of training so the test split measures generalization to unseen fault types, not interpolation. Evaluation reports CEF0.5 against the Goetze et al. baseline [5] plus per-subsystem precision and recall; Section V-C lists this as the next step. DDPM fault augmentation. Only 0.57–1.80% of the ESA-ADB data contains actual faults; a model trained on so few examples will not learn enough variation to handle real missions. We use a DDPM (Denoising Diffusion Probabilistic Model), a generative AI that learns the statistical pattern of real faults and creates realistic synthetic ones covering power system failures, reaction wheel wear, and communication dropouts. Generated-data realism is measured with the FID score (Fréchet Inception Distance), which compares the statistical distribution of real and generated sequences. TABLE I: ESA-ADB Mission 1 Dataset Statistics (Verified) Property Value Time range 2000-01-01 to 2013-12-31 (14 yrs) Readings per channel 487,448 Total channels 76 (58 target, 18 support) Subsystems monitored 4 Total annotated events 200 (118 real, 78 rare, 4 gaps) Anomaly-channel mappings 3,589 Data format float32 (normalized 0.0–1.0) Anomaly density 1.80% IV Experiment: Proof of Concept IV-A Dataset We use ESA-ADB Mission 1 [2], downloaded from Zenodo (DOI: 10.5281/zenodo.12528696), provided as per-channel pickle files. Table I summarizes the verified dataset statistics. We additionally collected 25 CubeSat observations from the SatNOGS Network API covering 16 unique satellites (702 telemetry payloads), each including TLE orbital elements to enable orbit-phase-aware suppression. IV-B Data Preprocessing Pipeline Channel data is loaded from pickle format. Normalized float32 values are aligned to the anomaly label timeline from labels.csv and anomaly_types.csv. The 58 target channels are extracted; non-target support channels are retained as contextual features. Anomaly windows are defined by (StartTime, EndTime) pairs from the labels file. Each annotated event spans a mean of 17.9 channels (3,589 mappings over 200 events), confirming the multivariate nature of satellite anomalies. TABLE I: ESA-ADB Mission 1 Event Category Breakdown Category Count % Real Anomaly 118 59.0 Rare Nominal Event 78 39.0 Communication Gap 4 2.0 Total 200 100 IV-C Anomaly Distribution Analysis Table I shows the event category breakdown for ESA-ADB Mission 1. The proportion of Rare Events (78 of 200) alongside true anomalies (118 of 200) directly motivates the DDPM augmentation strategy, since training exclusively on 118 real anomalies is insufficient to capture the full diversity of fault signatures PHOENIX must recognize. IV-D Baseline Anomaly Detection As a comparison baseline we apply the forecasting-plus-threshold approach of Goetze et al. [5] on ESA-ADB Mission 1: XceptionTimePlus predicts each target channel over a 224-timestep sliding window, and deviation exceeding a learned threshold flags an anomaly, achieving 88.8% CEF0.5 at 59KB RAM. PHOENIX targets matching or exceeding this score while additionally providing predictive warnings and self-healing that the detection-only baseline cannot offer. IV-E Semantic Cache Simulation To validate the energy-saving potential of the onboard semantic cache, we simulate cache behavior on the 118 ESA-ADB anomaly events in chronological order: each anomaly is encoded as a 384-dimensional embedding, and cosine similarity against cached embeddings (threshold τ=0.92τ=0.92) determines a cache HIT, which PHOENIX resolves without SLM inference. Given the 4-subsystem structure of Mission 1 and its 14-year duration, the same fault signatures recur across multiple annotated events. The simulation finds a cache hit rate of approximately 62% after the first 30 days, consistent with recurring EPS thermal cycles and degradation patterns dominating the fault distribution, which translates directly to a 62% reduction in SLM inference calls and energy expenditure per orbit. IV-F Data Volume Reduction Raw ESA-ADB Mission 1 contains 487,448 float32 readings per channel across 58 target channels, 28.27 million readings per full dataset segment. PHOENIX Phase 1 retains only anomaly descriptors and early-warning flags; since anomalies and rare events account for 1.80% of the Mission 1 timeline, 98.2% of readings are suppressible as nominal, consistent with the 85% reduction Del Prete et al. [9] demonstrate for hardware-aware AI on Jetson hardware. Sensor ReadingApply TLE Orbital ContextAnomaly Detected?Suppress (Phase 1)FAISS Cache LookupCache HIT?Apply Cached RepairInvoke Fine-Tuned SLMInsert to Cache (LRU)Compile Health ReportDownlink at Next PassNoYesNoYes Figure 2: PHOENIX three-phase onboard decision flowchart. Nominal readings are suppressed after orbital context is applied (Phase 1). Anomalies trigger a FAISS semantic cache lookup; a hit resolves the fault instantly while a miss invokes the fine-tuned SLM and updates the cache (Phase 2). A compact health report is compiled for downlink (Phase 3). IV-G Contact Window and Bandwidth Budget To make the suppression argument concrete, we calculate whether raw CubeSat telemetry can physically fit inside a typical contact window. Raw telemetry size per orbit. A CubeSat sampling 58 channels at 1 Hz produces: Draw D_raw =58×4 B×5760 s/orbit =58× 4 B× 5760 s/orbit =1,336,320 B≈1.27 MB/orbit =1,336,320 B≈ 1.27 MB/orbit (1) where 5760 s is one 96-minute orbit and 4 B is the float32 sample size. Downlink time at standard CubeSat UHF rates. A 9.6 kbps UHF radio (common in student CubeSats) transfers data at 1,200 bytes/s. Downlinking 1.27 MB takes: traw=1,336,3201,200=1,114 s≈18.6 mint_raw= 1,336,3201,200=1,114 s≈ 18.6 min (2) This exceeds the 5–10 minute contact window. Raw telemetry from a single orbit does not fit. The satellite must either drop data or compress it. After PHOENIX Phase 1 suppression. At 98.2% nominal suppression, the transmitted payload shrinks to: Dsupp=1,336,320×0.018≈24,054 B≈23.5 KBD_supp=1,336,320× 0.018≈ 24,054 B≈ 23.5 KB (3) Downlink time drops to 24,054/1,200≈2024,054/1,200≈ 20 s, well within any contact window and leaving the remaining bandwidth free for science data. Cache inference energy savings. With SLM inference drawing approximately 3 W for 2 s per query (6 J per call), the cache hit rate of 62% translates to a direct energy saving. Over a mission segment with N anomaly events: ΔE=0.62×N×6 J E=0.62× N× 6 J (4) For the 118 annotated events in ESA-ADB Mission 1, this is 0.62×118×6≈4390.62× 118× 6≈ 439 J saved relative to running the SLM on every anomaly. The cache does not change mission reliability on its own, but it preserves battery capacity that would otherwise be spent on redundant inference over the same recurring fault signatures. V Discussion V-A Comparison to Prior Work Table IV compares PHOENIX against the closest prior systems. The gap that stands out most is that every prior onboard AI work stops at detection: it flags that something is wrong and waits for ground contact. PHOENIX acts on that detection immediately via the cache or the SLM, then reports the outcome rather than the raw signal. Whether that survives deployment on real hardware is still an open question, but the design logic is straightforward. TABLE IV: PHOENIX vs. Prior Onboard CubeSat AI Works Work Det. Pred. Heal Cache Gnd.AI Horne [6] ✓ Goetze [5] ✓ Park [8] ✓ ✓ PHOENIX ✓ ✓ ✓ ✓ ✓ Table IV does not by itself show that PHOENIX matches prior detection performance, so Table V states the detection figures directly. Goetze et al. [5] is the like-for-like baseline, sharing the ESA-ADB channel set and CEF0.5 metric; Horne et al. [6] is listed for context but evaluates a different platform. PHOENIX’s figure is a design target, not a measured result, since the SLM has not yet been trained (Section V-C). TABLE V: Detection Comparison (Horne et al. uses a 9-channel EduSat evaluation, not ESA-ADB). Work CEF0.5 Footprint Channels Horne [6] 89.1% 192KB 9 Goetze [5] 88.8% 59KB 58 PHOENIX (target) ≥ 88.8% n/a 58 V-B Novelty of Contributions Prior onboard CubeSat AI work stops at detection. PHOENIX is, to our knowledge, the first system to close the loop from detection through autonomous repair to ground-validated telecommand generation. The onboard semantic cache is grounded in the near-optimal guarantee from Liu et al. [3], making it the first theoretically motivated cache design for satellite fault management. Orbit-aware suppression using live TLE context is also new: existing detectors treat telemetry as a raw time series, unaware of eclipse or sun phase. Finally, since ATSADBENCH [4] shows raw LLMs struggle on multivariate aerospace signals, PHOENIX fine-tunes each ground agent on domain-specific data and compresses the sensor stream into a structured health report they are trained to interpret. V-C Limitations and Future Work The current proof of concept demonstrates data pipeline feasibility and cache simulation on ESA-ADB Mission 1. Full evaluation requires (a) training the LoRA fine-tuned SLM per Section I-F, (b) training the DDPM for synthetic fault augmentation, and (c) end-to-end multi-agent evaluation on generated telecommands. The CLCB-SC-LS algorithm [3] provides a principled framework for cache adaptation, but its application to LEO orbital periodicity requires empirical validation on hardware. Deploying a fine-tuned SLM onboard raises challenges beyond detection accuracy: a short context window limits multi-orbit history, so the semantic cache acts as external memory; INT4 weights are more sensitive to radiation-induced bit flips than full precision, so periodic checksum verification with fallback to threshold detection is a required safeguard not yet implemented; and continual onboard fine-tuning, needed as fault distributions drift over the mission, risks catastrophic forgetting of rare fault classes, for which a frozen base model with swappable LoRA adapters is the safer alternative we plan to evaluate. V-D IEEE IES GenAI Challenge 2026 Alignment Satellites are industrial electronic systems under extreme resource and safety constraints. PHOENIX applies generative AI at three points: a fine-tuned SLM for onboard predictive reasoning, a DDPM for the chronic shortage of labeled fault data, and a fine-tuned multi-agent LLM for safe ground command synthesis, arguing that INT4 quantization and flight-proven Jetson hardware make a domain long seen as too constrained for generative AI tractable. VI Conclusion A CubeSat spends roughly 97% of each orbit out of radio contact with the ground, the window where failures start and, without onboard intelligence, go unnoticed until too late. PHOENIX fills that window with something more capable than threshold checks. The preliminary results are encouraging: a simulated 62% cache hit rate resolves many recurring faults without invoking the SLM at all, and 98% of raw readings are suppressible as nominal. Training and deploying the fine-tuned SLM and DDPM on real hardware (Section V-C) is left for future work, but the data pipeline and theoretical foundations are in place, and the gap between a CubeSat’s designed and actual operational lifetime may finally be closeable from the inside. References [1] M. Langer and J. Bouwmeester, “Reliability of CubeSats – Statistical Data, Developers’ Beliefs and the Way Forward,” in Proc. 30th AIAA/USU Conf. Small Satellites (SSC16), Logan, UT, 2016. [2] K. Kotowski et al., “European Space Agency Benchmark for Anomaly Detection in Satellite Telemetry,” arXiv:2406.17826v2, 2024. Available: https://doi.org/10.5281/zenodo.12528696 [3] X. Liu et al., “Semantic Caching for Low-Cost LLM Serving: From Offline Learning to Online Adaptation,” arXiv:2508.07675v3, 2026. [4] Y. Liu et al., “Evaluating Large Language Models for Time Series Anomaly Detection in Aerospace Software,” arXiv:2601.12448v2, 2026. [5] C. Goetze, T. Schlippe, and D. Lakey, “Deep Learning-Based Anomaly Detection in Spacecraft Telemetry on Edge Devices,” arXiv:2603.29375v1, 2026. [6] R. Horne et al., “Anomaly Detection Using Deep Learning Respecting the Resources on Board a CubeSat,” J. Aerospace Inf. Syst., vol. 20, no. 12, p. 859–875, Dec. 2023. [7] Manju and V. K. Srivastava, “AI-Integrated Self-Healing System for Robust Fault Detection and Automatic Recovery in IoT Environments,” Int. J. Innovative Sci. Research Technol., vol. 10, no. 12, p. 1947–1958, Dec. 2025. [8] J. Park et al., “LLM-based Multi-Agent System for Autonomous Maintenance Process of Machine Tools,” in Proc. PHM Society Annual Conf., 2025. [9] R. Del Prete et al., “Optimizing Deep Learning Models for On-Orbit Deployment Through Neural Architecture Search,” Scientific Reports, vol. 15, no. 37783, 2025.