SpaceHMchat: AI-Based Spacecraft Health Management

• SpaceHMchat is an open-source human–AI collaboration framework for managing spacecraft power systems through closed-domain chat, featuring explicit mapping of human cognitive skills to LLM capabilities.
• It employs a multi-expert, modular architecture that uses chain-of-thought reasoning, function-calling APIs, fine-tuning, and retrieval-augmented generation to ensure transparent, auditable decision-making.
• Extensively validated across 23 performance metrics and supported by public datasets and simulation assets, SpaceHMchat underpins robust health management in satellite mega-constellations.

SpaceHMchat is an open-source Human–AI collaboration framework for closed-domain chat and all-in-loop health management (AIL HM) of spacecraft power systems (SPS). It integrates advanced LLMs, domain-dependent dialogue management, and modular reasoning pipelines to support conversational completion of operation, anomaly detection, fault diagnosis, and maintenance workflows in the context of satellite mega-constellations (Di et al., 19 Jan 2026). Designed as an adaptation of the HRIChat framework for space-related domains (Nakano et al., 2019), SpaceHMchat leverages explicit mapping between core human capabilities and aligned LLM strengths, yielding transparent, interpretable, and adaptive human-in-the-loop support for SPS health management.

1. Foundational Principles: The AUC Paradigm

The central organizing principle of SpaceHMchat is the "Aligning Underlying Capabilities" (AUC) paradigm. For each health management sub-task, the framework identifies the essential human cognitive ability and pairs it with an optimal LLM capability:

AIL HM Subtask	Human Skill	Aligned LLM Capability
Work Condition Recognition	Logical reasoning	Chain-of-thought (CoT) prompting
Anomaly Detection	Tool operation	Function-calling, MCP
Fault Localization	Pattern learning	Fine-Tuning (LoRA, SFT, GRPO)
Maintenance Decision Making	Semantic search & synthesis	Retrieval-Augmented Generation

This design enforces explicit, task-dependent mapping—for example, leveraging prompt-engineered CoT traces for condition recognition, or function-calling protocols for anomaly analytics. Figure 1(c) in (Di et al., 19 Jan 2026) visually depicts this mapping across the health management pipeline.

2. Modular System Architecture

SpaceHMchat is structured as a multi-expert, sequential module system. Each module encapsulates an LLM (or fine-tuned variant) and interfaces for domain-specific task completion. The pipeline is composed of:

1. Work Condition Recognition: Implements a prompt-encoded decision tree (cf. Figure A.2 in (Di et al., 19 Jan 2026)), enabling zero/few-shot CoT reasoning over sensor logs and operational timelines. Transparency is achieved by returning stepwise deductions in each dialogue turn, as illustrated by the following pseudocode:

system_prompt ← encode_decision_tree_as_stepwise_if_else() user_input ← "Time range [t₁,t₂], sensor log ..." LLM_input ← [system_prompt, user_input] LLM_output ← LLM(LLM_input) parse_CoT_steps(LLM_output) → reasoning_chain, final_state

1. Anomaly Detection: Employs function-calling APIs and the Model Context Protocol to expose analytics toolkits (e.g., MTGNN, Autoformer, LSTM) for operator-driven detection and visualization tasks. Tool configuration and invocation are fully auditable via explicit JSON objects.
2. Fault Localization: Utilizes Q&A-style datasets (Appendix A.3 (Di et al., 19 Jan 2026)), fine-tuned on >85,000 samples, to map time-series telemetry windows onto specific fault labels and rationales. LoRA, SFT, and GRPO techniques optimize generalization to rare edge cases.
3. Maintenance Decision Making: Leverages Retrieval-Augmented Generation and knowledge base query modules. Vector databases index technical documentation, expert logs, and literature, enabling root-cause analysis, risk assessment, and actionable recommendations with source-citing transparency.

Each module operates within a conversational, human-readable interface, abstracting away programming demands for junior operators.

3. Domain-Dependent Language Understanding and Dialogue Management

SpaceHMchat's chat dialogue system inherits architectural features from HRIChat for closed domains (Nakano et al., 2019). The system-level workflow comprises:

• Language Understanding (LU): Tokenization/morphological analysis (e.g., spaCy), dictionary/KB lookup, slot extraction via CRF sequence labeling with IOB tags, and intent classification using multinomial logistic regression. The LU parses user input into a semantic representation $$\{ \text{supertype}, \text{type}, \text{slot}_1, \ldots \}$$.
• Expert Modules: Two principal paths—reaction-based (Response Expert) and state-transition network-based (Network Expert)—with arbitration using developer-tuned scoring functions. The action selection pseudocode is:

sem = LU(user_utterance) score_resp = f_resp(sem) score_net = f_net(sem, net.current_state) if score_net > score_resp: selected = network_expert else: selected = response_expert action = selected.generate(sem) realize(action) if action.activates(expert2): action2 = expert2.generate(sem) realize(action2)

• System Action Realizer: Fills conversational templates, sets state/context variables, and integrates expert-activation hooks.

Space-specific ontologies are engineered by extracting entity classes (Spacecraft, Mission, CelestialBody, Event, etc.) and their relations (launchedBy, orbiting, uses) from open datasets (NASA, DBpedia, ESA). The knowledge graph backend (Neo4j) supports canonicalization and synonym resolution in slot post-processing.

4. Human–AI Collaboration and Transparency

The collaboration mechanisms enable adaptive learning and interpretability at all stages:

• Conversational Interface: Natural language input/output, with operators issuing requests and system guiding dialogue via explicit state management.
• Adaptive Learning: Escalated fault cases are appended for continuous fine-tuning, propagating experiential knowledge into model updates.
• Transparency: Logical deductions, code execution, and knowledge retrieval steps are fully logged. Chain-of-thought reasoning and explicit citations enable human auditors to reconstruct diagnostic and maintenance conclusions.

5. Hardware-Realistic Platforms and Simulation Assets

To support experimental validation, SpaceHMchat integrates a physical test bench replicating a low Earth orbit SPS, including solar array simulators, battery packs, charge/discharge regulators, power distribution modules, and load simulators. Fault injection is performed via dedicated hardware ports, and telemetry (33 sensors at 1 Hz) is collected. A high-fidelity digital twin simulation model is provided and made publicly available (Appendix A.5 (Di et al., 19 Jan 2026)).

6. Quantitative Evaluation and Dataset Release

SpaceHMchat is empirically validated on 23 metrics across all core stages:

Task	Accuracy/Success Metrics	Latency/Timing	Additional Quality Measures
Work Condition Recognition	Conclusion accuracy: 100% (50/50)	2.907 s avg.	Logical coherence: 100%; step-wise: 100%
Anomaly Detection	One-shot success: 98.0%, final: 100%	Algorithm select: 0.977 s	Tool invocation accuracy: 99.6%
Fault Localization	Acc: 89.43%, Precision: 90.01%, Recall: 89.50%, F₁: 89.35%	48.938 s avg.	Matthews Corr. Coef.: 0.8883
Maintenance Decision Making	Task completion: 100% (50/50)	~127 s per phase	Citation accuracy: 97.3%

The released AIL HM dataset (XJTU-SPS), the first of its kind for SPS management, includes:

• MR: Work-Mode Recognition (6 modes)
• AD: Anomaly Detection (>700,000 records)
• FL/FD: Fault Localization/Diagnosis (17 types)
• F/R: Forecasting/Reconstruction (1 Hz, 33 channels)

All data and simulation assets are publicly available for benchmarking and further research.

7. Implementation Blueprint and Best Practices

SpaceHMchat's design is grounded in structured modular development and evaluation protocols. Key development steps, as extrapolated from HRIChat and validated in the space context (Nakano et al., 2019), encompass:

• Dialogue goals/scenarios definition (10–12 space topics)
• Ontology extraction and synonym table generation
• LU schema design and example utterance drafting (~1,000 annotated)
• Model training for slot extraction and intent classification
• Reaction knowledge authoring (~200 ResponsePairs)
• State-transition network definition and isolated testing
• Action selection, scoring, and context variable management
• Deployment and pilot user studies (10–15 users, scaling to 60+), with rigorous metric logging

Empirical lessons emphasize annotation consistency, concise dialogue state nets, contradiction checking, streamlined developer tooling, and sparse but strategic use of persistent context variables.

A plausible implication is that this blueprint, rigorously applying domain-dependent LU, modular expert blending, and transparent evaluation, enables rapid prototyping and robust scalability for closed-domain space dialogue systems such as SpaceHMchat.

8. Illustrative Dialogue and Use Case

An exemplar work condition recognition dialogue (cf. Fig. 3 (Di et al., 19 Jan 2026)):

• User: "During ['2024-10-18 18:43:23', '2024-10-18 18:44:15'], what was the spacecraft’s work condition?"
• SpaceHMchat: Computes stepwise CoT
  • Step 1: solar voltage = 28.746 V > 1 V ⇒ Sunlit Area
  • Step 2: load currents = 0 A ⇒ No Task
  • Step 4: battery currents = –0.441/–0.449/–0.423 A < –0.1 A ⇒ Step 5
  • Step 5: Δ voltage < 0.05 V ⇒ CV Charging
  • Step 7: all sensors normal
  • Final: "In summary, the condition was [CV Charging, Sunlit Area, No Task]."

This transparent, step-labeled deduction contrasts with base LLMs lacking AUC guidance, which generically reply "Nominal conditions" with no extractable reasoning trace.

In conclusion, SpaceHMchat represents a modular, validated exemplar of Human–AI collaborative dialogue and health management for the space systems domain, operationalizing theoretically grounded mapping, modular toolchain orchestration, and data-driven transparency across core system life-cycle tasks (Di et al., 19 Jan 2026, Nakano et al., 2019).