A high-performance onboard computing architecture for autonomous satellite mission planning

Abstract

With the increasing demand for onboard autonomy in remote sensing and space missions, traditional ground-centered mission planning architectures face limitations in responsiveness and operational flexibility. To support onboard autonomous mission planning and data processing, this paper presents the engineering design and system-level realization of a high-performance Mission Planning Board(MPB) for satellite applications.The proposed MPB adopts a modular single-board hardware architecture and an extensible software framework, enabling the deployment and reconfiguration of mission planning, data processing, and health management applications on orbit. The hardware integrates a radiation-tolerant high-performance CPU, interface FPGA, and intelligent acceleration module, while the software architecture supports task scheduling, system monitoring, and reliable in-orbit operation. Comprehensive reliability measures, including redundancy design, fault tolerance mechanisms, and environmental adaptability, are incorporated to ensure suitability for space environments. Ground-based functional tests and environmental qualification experiments have been conducted to verify the correctness and robustness of the proposed design. In addition, the MPB has been deployed on orbit for engineering and system-level validation, demonstrating stable operation and functional feasibility. The results indicate that the proposed architecture provides a practical and extensible platform for enhancing onboard computing capability and supporting onboard mission planning–related computing and system-level autonomy in future satellite missions. This work focuses on engineering implementation and validation, rather than quantitative evaluation of specific mission planning or intelligent algorithms.

Introduction

The complexity of mission planning increases with the proliferation of remote sensing constellation satellites and the development of commercial spaceflight. Mission planning frameworks and models for large imaging satellite constellations are no longer suitable for single or small satellite constellations, making Large scale Imaging Satellite Mission Planning (LSISMP) an important research direction. Traditionally, space mission operations have relied on pre planned activities on the ground, but limited by visible windows and communications delays, some space systems cannot perform real-time ground control. This mode is slow and inefficient in the face of unexpected events, such as the discovery of new targets or the failure of original observation missions. Additionally, element failures or performance degradation in multi satellite systems can increase uncertainty in the operating environment, posing challenges to traditional centralized planning algorithms^1–7.

To address these challenges, satellites require a higher level of on orbit autonomy. For example, in Earth observation satellite (EOS) missions, the imaging results of optical cameras are often affected by meteorological parameters such as clouds, resulting in images that are useless. In order to obtain effective images, the effects of cloud cover need to be minimized, and airborne autonomous mission planning combined with cloud detection techniques can effectively counter this problem. The complexity of on orbit service (OOS) missions also requires improved autonomous mission planning, such as solving orbital debris collision problems, enabling safe operations through autonomous obstacle avoidance^1,8–10.

Satellite autonomous mission planning systems typically involve multiple research directions, including multi-satellite coordinated planning, hierarchical task network (HTN)–based planning, joint ground–onboard operational mechanisms, and semantic description–driven planning approaches. These methods have been widely investigated in previous studies to address challenges such as resource utilization efficiency, dynamic mission replanning, and uncertainty in space environments^5,7,11,12.

For example, multi-satellite coordinated observation models have been proposed to improve regional target coverage and reduce redundant observations by considering contextual and integrity constraints. HTN-based planning methods have also been extensively studied for autonomous spacecraft, enabling the decomposition of high-level mission objectives into executable onboard tasks. In addition, joint ground–onboard operational mechanisms and semantic-driven planning approaches have been explored to enhance responsiveness to emergent mission requirements and reduce operational resource waste^8,13–17.

These studies provide valuable algorithmic and conceptual foundations for autonomous mission planning. However, their practical deployment places stringent requirements on onboard computing platforms in terms of computational capability, architectural flexibility, reliability, and environmental adaptability. The focus of this paper is not on proposing new planning algorithms, but on the engineering realization of an onboard computing platform capable of supporting such mission planning functions under real space constraints.

Figure 1 shows a structured representation of the mission target context, including key attributes such as location, characteristics, time window of interest, priority, observation time window, and imaging method ¹⁴. Figure 2 further illustrates the complex relationship between the mission, user, satellite, and target, along with related attributes and methods, such as user requirements for the mission, the imaging method used by the satellite, and its battery status, among others ¹⁴.

Fig. 1.

Mission-target context¹⁴.

Fig. 2.

Relationships in satellite mission planning¹⁴.

In this context, the onboard mission planning system is required not only to support complex planning algorithms, but also to provide sufficient computational performance, reliability, and flexibility within the constraints of the space environment. This places stringent requirements on onboard computing hardware, software architecture, and system-level reliability design ^18–20.

This paper focuses on the engineering realization of an onboard mission planning capability and presents a high-performance computer–based satellite Mission Planning Board(MPB).

The main contributions of this paper are summarized as follows:

1. The engineering design and implementation of a modular Mission Planning Board (MPB) suitable for onboard deployment, providing a hardware and software platform for mission planning–related computing tasks;

2. A configurable software architecture that supports application deployment, management, and reconfiguration on orbit, without dependence on specific mission planning algorithms;

3. A reliability-oriented design approach incorporating redundancy, fault tolerance, and environmental protection mechanisms, verified through engineering tests;

4. Ground-based functional verification, environmental qualification testing, and initial in-orbit engineering validation demonstrating system-level feasibility and operational stability of the proposed platform.

Autonomous mission planning introduces system-level requirements including real-time responsiveness, computational scalability, robustness to uncertainty, and long-duration operational reliability. These requirements directly influence architectural decisions such as processor selection, memory redundancy design, interface determinism, and application deployment flexibility.

In this work, the MPB architecture is derived from representative mission planning needs, including dynamic task replanning, onboard data processing, and health-aware system management. Rather than implementing specific planning algorithms, the platform is designed to provide the computational and architectural conditions necessary to support such workloads.

The remainder of this paper is organized as follows. Section II describes the overall system design of the Mission Planning Board(MPB). Sections III and IV present the software architecture and reliability design, respectively. Section V introduces the experimental verification. Limitations and applicability, Lessons Learned for Onboard Autonomous Computing Design are shown in VI and VII. Finally, conclusions are given in Section VIII.

Beyond presenting a specific implementation, this work aims to extract generalizable engineering insights for onboard autonomous computing platforms. The Mission Planning Board (MPB) is used as a concrete case study to illustrate how mission planning requirements translate into system-level architectural decisions under real space constraints.

From this implementation, several reusable design principles are identified, including:

1. decoupling time-critical interfaces from application logic using FPGA-assisted buffering;

• (2)balancing radiation tolerance and computational capability in processor selection;

• (3)modular software architecture enabling in-orbit application reconfiguration;

• (4)redundancy-driven reliability design adapted to long-duration missions.

These principles are intended to provide guidance for the design of future onboard autonomy platforms beyond the specific hardware described in this work.

System design of the mission planning board(MPB)

Overall hardware design

The hardware configuration presented in this section should be interpreted as one implementation instance guided by broader system design considerations. The design process followed a requirement-driven methodology: mission planning workloads define computational demands; environmental constraints define reliability and redundancy needs; and long-term mission operation defines maintainability and reconfigurability requirements.

This requirement-to-architecture mapping process represents a transferable engineering methodology that can inform the design of future onboard computing platforms.

The Mission Planning Board(MPB) designed in this paper provides onboard computing support for autonomous mission planning for Earth observation and related satellite missions, multi satellite data fusion processing and other functions. The Mission Planning Board(MPB) is designed with an open software architecture, and features such as mission planning, data fusion are deployed and installed in the form of an app. The Mission Planning Board(MPB) adopts a single-board modular architecture, integrating seamlessly with other avionics systems.

The Mission Planning Board(MPB) based on a high-performance computer consists of a high-performance computer, an interface FPGA, and a hardware accelerated NPU, and the system block diagram is shown in Fig. 3:

Fig. 3.

The circuit principle block diagram of the Mission Planning Board(MPB).

The Mission Planning Board(MPB) functions are described below:

1. Complete a highly reliable startup of the system, and initiate the basic state of the system;

• (2)Loading the operating system and establishing the application layer running environment;

• (3)Schedule the designated mission planning app and designated data fusion app operations according to the ground set strategy;

• (4)Collecting software and hardware operational status and feeding back to the satellite computer upon receipt of a telemetry request;

• (5)Support operating system reconfigurations, application layer reconfigurations.

High performance CPU selection

Current options for radiation hardened high-performance CPU processors include LS2K2000 based on the LoongArch architecture, BM3883 based on SPARC V8, DSP TMS320C6678, FT2000 based on ARM V8, Yulong810, and more.

TMS320C6678 is an 8-core DSP processor, suitable for large-scale parallel computing, with weak support for general-purpose programs; The LS2K2000 is a high-performance embedded dual core processor based on the LoongArch architecture, supporting multiple Linux operating systems with high commonality; The BM3883 is an radiation hardened 8-core SPARC V8 processor that integrates multiple peripheral resources with high reliability but weak performance; FT2000 is a dual core processor based on ARM V8, with strong commonality but weak radiation resistance; The Yulong810 is internally integrated with four ARM Cortex-A9 and four SPARC V8, featuring high performance, high reliability, and low power consumption. A comparison of the individual CPUs is shown in Table 1. By comparison, it can be seen that the radiation hardened and more versatile CPUs were LS2K2000 and Yulong810, and the two CPUs were performance tested using a benchmark program, as shown in Tables 2, 3 and 4.

Table 1.

High Performance CPU comparison.

CPU Model	Radiation Adaptability	Cost	Performance	Core Number	Primary Frequency	Reliability Design	Power (W)	Operating System	Ease of Use
LS2K2000	High	Middle	High	2	1.6G	ECC	< 10	Linux	High
BM3883	High	High	Low	8	1G	ECC	< 8	Vxworks	Middle
TMS320C6678	High	Middle	High	8	1.4G	ECC	< 10	DSP/BIOS	Middle
FT2000	Middle	Middle	Middle	2	1G	ECC	< 4	Linux	High
Yulong810	High	High	Middle	4 + 4	1G	ECC	< 6	Linux	Middle

Table 2.

UnixBench test comparison.

Single core UnixBench Test	LS2K2000	Yulong810
Dhrystone 2 using register variables (10.0 s, 7 samples)	1026.8	328.6
Double-Precision Whetstone (9.3 s, 7 samples)	346.1	128.1
Execl Throughput (30.0 s, 2 samples)	557.8	141.2
File Copy 1024 bufsize 2000 maxblocks (30.0 s, 2 samples)	745.3	222.4
File Copy 256 bufsize 500 maxblocks (30.0 s, 2 samples)	583.9	167.5
File Copy 4096 bufsize 8000 maxblocks (30.0 s, 2 samples)	976.2	318.6
Pipe Throughput (10.0 s, 7 samples)	513.9	156.5
Pipe-based Context Switching (10.0 s, 7 samples)	280.7	99.1
Process Creation (30.0 s, 2 samples)	339.1	127.1
Shell Scripts (1 concurrent) (60.0 s, 2 samples)	840.2	355.5
Shell Scripts (8 concurrent) (60.0 s, 2 samples)	1019.3	652.8
System Call Overhead (10.0 s, 7 samples)	776.9	272.1
System Benchmarks Index Score:	611.6	213.1
Multi core UnixBench testing	LS2K2000	Yulong810
Dhrystone 2 using register variables	2045.8	1313.6
Double-Precision Whetstone	692.5	512.2
Execl Throughput	1082.1	361.3
File Copy 1024 bufsize 2000 maxblocks	1252.5	421.3
File Copy 256 bufsize 500 maxblocks	999	284.3
File Copy 4096 bufsize 8000 maxblocks	1723.8	757.3
Pipe Throughput	1026.4	616.3
Pipe-based Context Switching	559.4	326.5
Process Creation	839.1	266
Shell Scripts (1 concurrent)	1232.9	732.6
Shell Scripts (8 concurrent)	1083.3	679.7
System Call Overhead	1555.1	1052
System Benchmarks Index Score:	1104.8	540.3

Table 3.

OPBmark test comparison.

		2K2000				Yulong810
		cpu		openMP		cpu		openMP
		Total execution time(ms)	Throughput (Mpixel/s)	Total execution time(ms)	Throughput (Mpixel/s)	Total execution time(ms)	Throughput (Mpixel/s)	Total execution time(ms)	Throughput (Mpixel/s)
image	1024*1024	8183.39	0.13	5605.17	0.19	30404.13	0.03	13189.23	0.08
	2048*2048	45287.07	0.09	25449.55	0.16	127920.06	0.03	53655.89	0.08
	4096*4096	172416.53	0.10	108652.62	0.15	-	-	-	-
CCSDS 121.0 Data Compression	1,048,576	531.59	1.97	399.47	2.62	2214.16	0.47	2320.75	0.45
	4,194,304	1409.07	2.98	1643.63	2.55	8844.08	0.47	9291.48	0.45
	16,777,216	8271.21	2.03	8623.77	1.95	35362.6	0.47	37136.64	0.45
CCSDS 122.0 Image Compression	1024*1024	262.92	3.99	293.11	3.58	1072.73	0.98	1496.45	0.7
	2048*2048	1065.87	3.94	1179.42	3.56	4372.99	0.96	6595.54	0.64
	4096*4096	5474.40	3.06	5784.51	2.9	18109.76	0.93	30306.77	0.55
AES Encryption	Plaintext length 1,048,576 byte, key 128bit	439.27	2.39	247.04	4.24	2120.6	0.49	531.53	1.97
	Plaintext length 4,194,304 byte, key 192bit	2104.29	1.99	1088.28	3.85	10185.42	0.41	2551.36	1.64
	Plaintext length 16,777,216 byte, key 256bit	9794.39	1.71	4969.29	3.38	47621.93	0.35	11928.11	1.41

Table 4.

Test table of radiation resistance of LS2K2000 CPU.

Chip Type	Test Project		SEL (LET = 75.4 MeV·cm2/mg)	SEU/each flipped section (cm2/bit)
28 nm FD-SOI CPU	Trigger Test		Did not occur	1.75E-10
	RAM Test	RAM1	Did not occur	3.74232E-11
		RAM2		4.92976E-12
		RAM3		2.34751E-13
12 nm CPU	RAM Test	RAM1	Occurs, the chip fails to function and cannot be recovered	8.62E-10
		RAM2		1.58E-09
		RAM3		1.69398E-09

The LS2K2000 is far superior to the Yuling810 in both single core and multi-core performance, with 4.6 times the single core performance of the LS2K2000 compared to the Yuling810; In terms of multi-core performance, the LS2K2000 (2-core) is 3.2 times more capable than the Yuling810 (4-core). In comparison to the Godson desktop processors LS3A4000 and LS3A5000, the LS2K2000 has higher performance than the LS3A4000 and lower performance than the LS3A5000, Benchmark test results indicate that the LS2K2000 provides higher single-core and multi-core performance than the Yulong810 under the tested conditions. These results are intended to support processor selection for onboard engineering applications, rather than to establish direct equivalence with commercial-grade desktop processors, which differ significantly in architecture, operating environment, and design objectives.

Through the above comparison and combined with our own familiarity with the use of the CPUs, the 2K2000 has a high processing capacity, better radiation resistance, and greater commonality, so the option for the on-board Autonomous Health Manager (Regarding the health management function in the Mission Planning Board) selected the CPU for the higher cost performance LS2K2000.

The Godson high-performance CPU LS2K2000 uses a 28 nm FD-SOI process with a total radiation dose greater than 100 krad (si), single event latchup immunity, and a device saturation upset cross-section of the order of 10–11. LS2K2000 CPU on-chip integration of 2 LoongArch-LA364 processors, 0.65 GHz ~ 1.6 GHz, 72 bit DDR3/4 controllers, and various system IOs, with the following main characteristics:

1. On chip integration of two 64 bit three transmit superscalar LA364 processor cores, LoongArch architecture, 1.6 GHz, and processing performance over the Godson 4 core desktop processor LS3A4000;

2. On chip integration of shared 2 MB secondary cache with ECC support;

3. On chip integrated 3D GPU;

4. Dual channel display (HDMI and DVO;

5. 1 VPU decoder;

6. On chip integrated 72 bit DDR3/4 controller (with 8-bit ECC);

7. PCIE 3.0 interface;

8. On chip integration of 2 SATA3.0 interfaces;

9. On chip integration of up to four USB 3.0, up to nine USB2.0, with one OTG;

10. On chip integration of 1 RGMII gigabit network phy interface, 2 gigabit network ports;

11. Support for multiple Linux operating systems such as loongnix.

The LS2K2000 integrated two 64 bit three transmit superscalar La364 processor cores on chip, with a maximum of 7200 MIPS at fixed point and 2GFLOPS at floating point at 1.2 GHz.

Interfaces such as Ethernet, USB, and HDMI are primarily intended for ground-based development, integration, and debugging. In flight configurations, these interfaces are either electrically isolated or not populated, depending on mission requirements, and do not participate in routine on-orbit operations.

Electronics design

The Mission Planning Board(MPB) is a large 6U board card and is primarily composed of high-performance CPUs, DDR4 SDRAMs, SPI FLASH, NAND FALSH, E-MMC, SSD, NPU, watchdog circuits, network ports, USB, HDMI, and debugging circuits. The circuit principle block diagram is shown in Fig. 3.

The core CPU of the board uses the Godson high-performance CPU LS2K2000, a 28 nm FD-SOI process, a mass rating of IND, a total radiation dose greater than 100 krad (si), and single particle locking immunity. CPU on-chip integration of 2 LA364 processors, main frequency 0.65 GHz ~ 1.6 GHz, 72 bit DDR3/4 controller, and various system peripheral IO.

The peripheral of the Godson LS2K2000 processor is equipped with DDR4 SDRAM for program data operation memory, and ISSI’s DDR4 SDRAM IS43QR16512 with a single chip capacity of 8Gb is selected, with 5 chips in parallel and a total capacity of 4GB, comprising 64 bit data bits and 8 bit check bits, TID>100kRad(Si), SEL>67 Mev-cm2/mg, SEU > 0.4 Mev-cm2/mg;

The A3PE3000L-FG484I is a Microsemi FLASH type FPGA with three million logic gates, no loss of power down for configuration information, and immunity to single event upsets. The FPGA has two main functions,

1. Triple modular redundancy for the memory QSPI FLASH that stores the CPU BIOS, with the memory selected from ISSI’s QSPI FLASH IS25LP128;

• (2)External interface extensions such as PPS, RS422 and LVDS interfaces.

The NAND FLASH was used to store the Linux operating system, with a single chip capacity of 4Gb, three pieces of NAND FLASH stored three copies at the same time, the startup program read the three copies of the program and performed a two out of three comparison operation after startup, after which the results were written to DDR4 SDRAM memory.

The LS2K2000 mounts 256GB of SSDs via the SATA3.0 interface and 32GB of EMMC memory via the EMMC interface, the SSDs and EMMCs can be backed up to each other for payload data, applications, library files, etc. The SSDs can be powered down by the CPU when not working.

Debug ports for high-performance CPUs include the serial port USB、 The gigabit Ethernet port, along with the HDMI interface, makes it easy for users to perform hardware and software debugging as well as act as an expansion interface.

Interfaces such as Ethernet, USB, and HDMI are primarily intended for ground-based development, integration, and debugging. In flight configurations, these interfaces are either electrically isolated or not populated, depending on mission requirements, and do not participate in routine on-orbit operations.

Cambrian MLU220 is an edge smart acceleration card with a single event locking threshold SEL > 37 Mev cm2/mg, providing powerful intelligent computational support for edge reasoning, featuring high computational performance and fast transmission rates. Cambrian MLU220 core board as shown in Fig. 4. Smartcard Operational Performance 16TOPS@int8, power consumption 16 W, communication between the smart accelerator card and the CPU via a PCIE, power down controlled by the CPU when inoperative.

Fig. 4.

Cambrian MLU220 core board.

Reliability measures for the Mission Planning Board(MPB) include:

1. High performance processor Selection of radiation tolerant processor: LS2K2000 has radiation resistance;

2. The operating memory, etc., has the functions of correction, check and two: the memory has the ECC function;

3. The memory has an ECC function;

4. The operating system supports dual modular redundant or triple redundant starts;

5. The startup module has high reliability, and the startup program is stored in three copies of SPI FLASH with triple modular redundancy;

6. Carry out a latch resistant design;

7. Cambrian modules and SSD modules can be individually powered on and off;

8. Software supports reconfigurations.

As shown in the Fig. 4, the MLU220 is deployed as a dedicated onboard intelligent computing module and is physically mounted on the Mission Planning Board. It is connected to the main CPU through a PCIe interface, enabling high-bandwidth data exchange and coordinated operation between general-purpose computing and intelligent acceleration resources.

Within the proposed architecture, the MLU220 provides hardware capability for inference-oriented intelligent workloads, complementing the CPU in handling computationally intensive tasks. In this work, the focus is on the engineering integration of the accelerator, including power control, interface connectivity, device driver support, and runtime environment compatibility. These elements collectively ensure that intelligent computing resources can be accessed and managed reliably at the platform level.

The Mission Planning Board(MPB) integrates a Cambrian MLU220 intelligent acceleration module, providing onboard capability for intelligent computing and inference-oriented workloads. The accelerator is physically mounted on the Mission Planning Board(MPB) and connected to the main CPU through a PCIe interface, forming part of the onboard computing architecture.

In this work, the integration of the Cambrian MLU220 focuses on platform-level engineering aspects, including power control, interface connectivity, device driver support, and runtime environment compatibility.

No specific intelligent algorithms or mission planning workloads were evaluated on the accelerator. Therefore, no quantitative performance metrics related to intelligent inference or autonomous planning are reported. The inclusion of the MLU220 demonstrates that the proposed MPB architecture is capable of hosting intelligent acceleration hardware and providing the necessary system-level support for future application development.

Software design of the mission planning board(MPB)

In the previous section, We have proposed a detailed system design for the Mission Planning Board(MPB). The Mission Planning Board(MPB) management software comprises four functional modules: Start Software, System Software, Application Software, and Interface Control FPGA Software. The overall software architecture of the Mission Planning Board(MPB) is shown in Fig. 5.

Fig. 5.

The overall software architecture of the mission planning board(MPB).

As illustrated, the software system is organized into four main layers: start software, system software, application software, and interface control FPGA software. This layered architecture supports reliable system startup, operating system management, application execution, and deterministic interaction with external interfaces.

The start software is responsible for hardware initialization, redundancy checking, and secure loading of the operating system. The system software, based on a Linux operating system, provides core services such as process scheduling, memory management, interrupt handling, and device driver support. On top of this layer, application software modules implement mission-related functions, including command management, telemetry processing, health management, and operational maintenance.

The interface control FPGA software operates in coordination with the CPU to handle time-critical data reception, buffering, and transmission through interfaces such as RS422 and LVDS. By separating time-sensitive interface handling from higher-level application logic, the architecture improves system determinism and robustness.

Overall, Fig. 5 highlights how the proposed software architecture enables modular deployment and reconfiguration of mission planning–related applications, while maintaining system reliability and flexibility under onboard operational constraints.

In this work, the term “open software framework” refers to architectural openness and extensibility at the system level. It enables modular deployment, configuration, and updating of onboard applications through standardized interfaces and operating system support. It does not imply open-source software distribution, but rather emphasizes flexibility, scalability, and ease of integration for different mission applications.

Start software design

The startup software mainly completes hardware initialization, operating system guidance and hardware testing, program debugging and other functions.

The startup software provides multiple ways to load the operating system; It provides basic test tools for memory, serial port, display, network, hard disk, etc.; Support software upgrades; Support dog feed function; Supports triple modular redundant storage and comparison of operating systems and applications.

System software design

The system software uses the Linux operating system, including the Linux core and root file system. After the launcher boots the core, the core first mounts the root file system, which is responsible for the initial work during the Linux core startup. The Linux core operating system provides functions such as interrupt and anomaly management, memory management, process scheduling management, inter process communication management file system, device driver, and network protocol management. The main functions include: interrupt and anomaly management, and system software requirements can manage external interrupts and software anomalies. Can enable or mask a specified external interrupt source, and all external interrupts are disabled when the system is default initialized; An external interrupt source can be assigned a corresponding interrupt service program, and the system software protects the current mission status when an interrupt occurs, restoring the mission status after the end of the interrupt. Request that interrupts can be nested. The requirements for system software anomaly management are: can respond to various software anomalies in the system and provide a connection anomaly interface handling method.

Operational environment and software development environment:

1. The system core is Linux 4.19;

• 2. The core cross compilation tool is LoongArch GCC 8.3 (gcc − 83.0, glibc-228, gdb-8.150).

Application software design

The application software is divided into command management, telemetry management, health management and operational maintenance function modules.

Command management

Receive control commands and broadcast time code messages from the Service Computer (On-Board Computer, OBC) via the CAN bus.

Telemetry management

The software periodically acquires the operating state quantity of the single machine itself, organizes its own engineering parameters, sends them to the satellite service computer via the CAN bus, and organizes its own engineering parameters into a complete telemetry source package, which is sent to the satellite service computer via the interface FPGA.

Health management and operational maintenance

The software shall have certain system maintenance and support functions, mainly including: ECC protection, RS422 bus communication monitoring, software on orbit update (including startup software, system software, application software), etc.

Interface control FPGA software design

Interface FPGAs function as follows:

1. Receive data from routing multiplexing via LVDS interface;

2. Receive reconstructed data of integrated electronics via RS422 interface;

3. Caching of received data;

4. Transmit the received data to the CPU via LIO;

5. Transmit data to a routing multiplexing via LVDS reception;

6. Triple modular redundancy of the SPI FLASH;

7. Receive a PPS second pulse via RS422 and trigger a CPU interrupt.

The development environment is as follows:

1. Development tools: Libero V9.2;

2. Comprehensive tools: synplify pro;

3. Simulation tools: Modelsim SE 10.5e;

4. Triple Modular Redundancy Tool: Synplify Pro.

The FPGA driver is responsible for interacting with the interface control FPGA, including the reception and transmission of RS422, LVDS data. In order to improve the FPGA interrupt response speed and prevent data loss, the interrupt balance service of the operating system was turned off when the system was initiated, and the second CPU core was specified for the FPGA interrupt service program, thus greatly reducing the loss of scientific data.

Reliability and safety design of the mission planning board(MPB)

Redundancy design

Hardware redundancy

The CAN bus of the Mission Planning Board(MPB) adopts an A/B bus design, corresponding to two sets of interface chips. In the event of a communication failure on either bus, it can be switched to the backup bus; The startup program memory adopts three SPI FLASH for the third mock examination redundancy; Three copies of the operating system and application programs are stored in NAND FLASH; Other applications and library files are stored in SSD and eMMC, which are backed up to each other; The above redundancies are all designed for hot backup. The redundancy design table of the Mission Planning Board(MPB) is shown in Table 5.

Table 5.

Redundancy measures.

serial number	redundant function	Redundancy measures	Verification status
1.	CAN bus redundancy design	Platform CAN bus, cold standby, A/B bus hot standby Switch A/B bus verification	Switch A/B bus verification
2.	Fuse	Cold standby and balanced dual fuse design to prevent short circuits from affecting other equipment	Verified
3.	Start Software	Spi FLASH Triple Modular Redundancy	Verified
4.	Operating system	NAND FLASH in three copies	Verified
5.	Operating system, library files, application SSD, eMMC mutual backup	-	Verified

Software redundancy

The DDR4 DRAM of the running program by the CPU employs ECC error correction techniques, capable of avoiding program failures due to single event upsets.

The device uses 3 SPI FLASHs to store the pmon program, with 1 copy of the pmon program stored in each SPI FLASH. When the device is powered up, the interface control FPGA performs two out of three operations on the pmon program in the three piece SPI flash, and then starts the pmon program. The pmon program is responsible for establishing the hardware environment and loading the operating system. In order to increase system reliability, the measures of three module hardening of the core and traversal startup of the operating system were designed.

Core Trimodule Hardening refers to: storing 3 copies of the core image in each operating system. The pmon program takes two out of three copies of the 3 core image files before loading them.

Information redundancy

In the CAN bus communication, in addition to the valid data, the engineering parameters and the format of the injected data are arranged by adding the method of accumulate check and redundant information to detect the errors in the information transmission and storage; Data stored in NAND FLASH is ECC encoded to prevent single event upsets.

Static redundancy

Triple modular redundancy is adopted in the design of FPGA, so that the effects of failures are eliminated by isolation or correction before they reach the module output; The operating mode table is stored in three copies in FLASH, read simultaneously in three copies and compared in two out of three, allowing correct operation in case of failure, thus improving system reliability.

Electromagnetic compatibility analysis and design

The purpose of electromagnetic compatibility (EMC) design is to ensure normal operation in the intended system electromagnetic environment without performance degradation or malfunction, while simultaneously preventing interference with other instruments. It aims to reduce conducted and radiated interference from equipment on power lines, improve the conducted and radiated susceptibility of all devices, and enhance anti-interference capabilities.

The electromagnetic radiation protection and electromagnetic leakage prevention measures adopted by the multiplexing modulator include:

Shielding design

Power and clock cables undergo shielded twisted-pair treatment to prevent antenna effects from currents.

Grounding design

Primary and secondary grounds are isolated; primary power return lines are isolated from the chassis; primary power buses are isolated from secondary power buses and signal lines. Secondary power ground and signal ground share a single connection point; secondary ground connects to chassis ground.

Filtering design

Power interfaces incorporate RC filter circuits to prevent external electromagnetic pulse interference with the equipment. Filter circuits exist at the entrance of each printed circuit board and unit circuit. DC/DC and POL module power supplies emphasize enhanced input/output filtering by using specialized filter modules to reduce electromagnetic interference effects and external radiation. RF output ports utilize bandpass filters for out-of-band suppression.

Structural design

Equipment chassis is sealed to shield against electromagnetic radiation from the device and external interference. Correct selection of active/passive components, appropriate circuit design, and layered PCB layout techniques are implemented.

Interface design

Power interfaces of the multiplexing modulator configure EMI filters matching the modules at the input end. For open-collector signal interfaces, appropriate input impedance is selected to improve anti-interference capability; digital signal interfaces use input circuits with hysteresis characteristics to reduce glitch sensitivity; analog signal interfaces ensure impedance matching and implement proper grounding.

Heat design

The Mission Planning Board(MPB) is integrated inside the integrated electronics, the case surfaces are black anodized, and the mounting surfaces conduct heat dissipation. Heat dissipation methods include radiative heat dissipation from the front rear, left and right sides, and top surfaces of the case, and radiative heat dissipation from the case floor via contact conduction through the satellite bay panels. Radiative heat dissipation capability is guaranteed by performance indicators of a black anodized coating on the case surface, and conductive heat dissipation on the underside is guaranteed by the unevenness of the case bottom plate, while thermal conductive filler is used when installed to ensure good contact between the underside of the case and the panel retaining surfaces.

Through the application of thermal conductive materials and equipment surface coatings, as well as reasonable organization of component heat dissipation channels and case heat dissipation channels, the devices meet the Class I derating requirements. Thermal design measures taken by the Mission Planning Board(MPB) include:

1. Heat rejection design for high-power components.

The main high-power devices, DC/DC modules and CPUs, MLUs, have obvious heating, mainly adopting a heat conduction sheet machined in one piece with the plate and frame to make the lower surface of the high-power heating elements closely adhere to the heat conduction sheet, which is made of aluminum.

• 2.Heat rejection design for medium power components.

Medium power components, such as FPGAs, LDOs, POLs, etc., with a thermal power consumption of more than 0.3 W, mainly employ the method of adding heat conducting fins to direct their heat towards the plate frame, which radiates heat towards the platform bulkhead. For packaged forms of components such as DIP, the heat conducting sheet may be pressed under the case; For surface mounted components, the heat conduction tab can only be fixed to the upper surface of the case. Unless otherwise specified, 1 mm thick copper heat conducting sheet is generally used. The contact surfaces between the elements and the heat conducting sheet, and between the heat conducting sheet and the plate frame, are coated with heat-conducting filler.

• 3.Temperature estimation for low power components.

Low power devices rely primarily on pin heat dissipation.

• 4.Thermal conductivity design of printed boards.

The printed circuit board has an aluminum frame to increase heat dissipation, and the printed circuit board uses a high copper covering rate printed circuit board to increase the thermal conductivity of the printed circuit board and improve heat transfer performance.

• 5.Thermal design of the case shell.

The contact surfaces between the case cases are maximized to reduce contact thermal resistance.

• 6.Thermal control products used.

Tank surface: black anodized (≥ 0.85).

Margin design

The margin design table for the Mission Planning Board(MPB) is shown in Table 6.

Table 6.

Margin measures.

Serial number	Design index	Design requirement	Implementation index
1.	Computational force requirements	Fixed point calculation not less than 3000MIPS, Floating point operations not less than 1 GFLOPS;	Fixed point calculation not less than 3000MIPS, Floating point operations not less than 1 GFLOPS;
2.	Storage requirements	Program storage not less than 64 MB, data storage not less than 256GB, and operational memory not less than 2GB	Program storage 1.5 GB, Data storage 256GB+32GB, operational memory 4GB
3.	Component derating	Meet derating needs	Meet derating needs

Experiment of the mission planning board(MPB)

The stand-alone test equipment for the Mission Planning Board(MPB) is shown in Fig. 6, with each test equipment used to simulate individual interface equipment.

Fig. 6.

The stand-alone test equipment for the Mission Planning Board(MPB).

The LVDS simulation board card is used to multiplex telemetry data for routing, using the three wire LVDS protocol.

The RS422 simulation board card is used to simulate the satellite servicing computer, sending reconstruction data to the Mission Planning Board(MPB), and the RS422 protocol is synchronized.

The satellite CAN simulation board card is used to simulate the bus controller of the satellite CAN bus, communicating with the Mission Planning Board(MPB) (RT).

The TT&C simulation board is used to send remote control commands and collect analog quantities.

The DC stabilized power supply provides power to the Mission Planning Board(MPB).

In order to simulate the space environment, we also did the ESS temperature test, temperature cycle test and thermal vacuum test for the Mission Planning Board(MPB) to ensure its reliability. A picture of the Mission Planning Board(MPB) in the thermal cycle experiment is shown in Fig. 7. Thermal cycle test conditions are shown in Table 7.

Fig. 7.

The mission planning board(MPB) in the thermal cycle experiment.

Table 7.

Thermal cycle test conditions.

Term	Acceptance level
Pressure	1 atm
Max. Temperature	+ 55℃
Max. Temperature	-20℃
Cycle Count	12.5 times (6.5 times for A, 6 times for B)
Variable Temperature Rate	3 ~ 5 °C/min
Extreme Temperature Residence Time	The first and last cycles last for 9 h, and the middle cycle lasts for 3 h

The experimental campaign was designed to verify the engineering feasibility, environmental robustness, and operational stability of the Mission Planning Board, rather than to evaluate mission planning algorithm performance.

During ground-based functional tests, the board successfully completed system startup, operating system loading, application execution, telemetry reporting, and command handling under nominal conditions. All interfaces with the service computer (OBC) operated correctly, and no abnormal behavior was observed during continuous operation.

Environmental qualification tests, including temperature cycling and thermal vacuum experiments, demonstrated stable system behavior across the specified temperature range. No functional degradation, unexpected resets, or data integrity errors were detected during or after the tests. These results indicate that the hardware design, redundancy measures, and thermal management strategy are sufficient to support reliable operation in representative space environments.

Overall, the experimental results confirm that the proposed Mission Planning Board meets its engineering design objectives in terms of functional correctness, environmental adaptability, and system-level robustness, providing a solid foundation for onboard deployment and future application integration.

Figure 7 shows the Mission Planning Board(MPB) during the thermal cycling experiment conducted to simulate the space thermal environment. The test was performed in accordance with the thermal cycle conditions listed in Table 7, including repeated transitions between high and low temperature extremes, controlled temperature variation rates, and specified dwell times at extreme temperatures.

The experimental campaign was designed to verify the engineering feasibility, environmental robustness, and operational stability of the Mission Planning Board(MPB), rather than to evaluate mission planning algorithm performance.

Ground-based functional tests confirmed correct system startup, operating system loading, application execution, telemetry reporting, and command handling under nominal conditions. Interface communication with the service computer (OBC) via CAN, RS422, and LVDS operated as expected during continuous operation.

Environmental qualification tests, including temperature cycling and thermal vacuum experiments, demonstrated stable system behavior within the specified temperature range. No functional degradation, unexpected resets, or data integrity errors were observed during or after the tests.

These results indicate that the Mission Planning Board(MPB) meets its engineering design objectives in terms of functional correctness, environmental adaptability, and system-level robustness. The tests do not provide quantitative assessment of mission planning effectiveness, computational efficiency under operational workloads, or long-term on-orbit performance beyond the reported validation period.

Although the experimental campaign focused primarily on engineering verification, several measurable system-level observations were recorded during ground testing.

The platform demonstrated stable continuous operation under extended runtime conditions without unexpected resets. System startup time remained consistent across repeated trials, and data exchange through CAN(500kbps), LVDS(10Mbps~20Mbps), and RS422 (115200bps) interfaces operated within deterministic timing constraints required by the service computer.

Resource utilization measurements indicated that the processor and memory capacity margins were sufficient to support concurrent application execution under nominal operational conditions.

Due to project confidentiality and mission-specific integration constraints, detailed timing, power consumption, and workload performance data cannot be publicly disclosed. However, the collected internal measurements confirm that the architecture satisfies the engineering requirements for onboard mission planning support.

Limitations and applicability

This work focuses on the engineering design and validation of an onboard computing platform and does not address the design, optimization, or performance evaluation of specific autonomous mission planning or intelligent algorithms. As such, the results should not be interpreted as demonstrating mission planning effectiveness, decision optimality, or learning capability.

The reported experimental results are limited to functional verification, environmental qualification tests, and initial in-orbit engineering validation. Long-term reliability, radiation-induced degradation over extended mission durations, and performance under sustained high-load operational scenarios were not evaluated in this study.

Furthermore, interface configurations, storage capacity, and accelerator utilization may vary depending on mission requirements and system integration constraints. Application developers are responsible for algorithm validation and performance assessment when deploying mission-specific workloads on the proposed platform.

Lessons learned for onboard autonomous computing design

The development and validation of the Mission Planning Board (MPB) provided several practical insights relevant to future onboard computing architectures, derived strictly from the engineering design, test results, and operational experience documented in this work. These observations highlight the critical interplay between mission requirements, architectural choices, and reliability in enabling onboard autonomy.

Mission planning workloads impose mixed requirements: real-time control, data-intensive processing, and long-duration reliability

Onboard mission planning is not a monolithic task but a hybrid workload with conflicting demands, directly shaping MPB’s design.

Real-time control: Dynamic task replanning (e.g., adjusting observations for new targets or failed missions) requires low-latency response to emergent events. MPB addressed this via an interface FPGA (A3PE3000L) that buffers time-critical data (RS422/LVDS) and triggers CPU interrupts only when data is ready, decoupling hardware timing from application logic (Section II.C, III.D).

Data-intensive processing: Onboard data fusion and compression (e.g., CCSDS 121.0/122.0) demand sustained computational performance. The MPB integrated a radiation-tolerant LS2K2000 CPU (2×LA364 cores @1.6 GHz, 7200 MIPS fixed-point/2 GFLOPS floating-point at 1.2 GHz) and a Cambian MLU220 NPU (16 TOPS@int8) to handle such workloads (Section II.B, II.C).

Long-duration reliability: 5–10 year missions require resilience to space environments (radiation, thermal cycles). MPB’s design followed a requirement-driven methodology: mission planning workloads defined computational demands, environmental constraints (e.g., TID > 100 krad(Si), SEL immunity) defined reliability needs, and long-term operation defined maintainability (Section II.A).

Validation: Ground tests confirmed the MPB supported concurrent mission planning apps, data processing, and health management with stable operation (Section V).

Architectural flexibility is as important as peak performance due to evolving mission needs

MPB’s success stemmed not from peak performance alone but from extensibility to adapt to unanticipated mission changes.

Modular hardware architecture: A single-board design integrating CPU, FPGA, NPU, and storage (Section II.A) allows seamless integration with other avionics, while hot-swappable modules (e.g., SSD/eMMC) support in-orbit updates.

Configurable software framework: The software is organized into four layers (startup, system, application, interface FPGA) with a Linux-based system (4.19 kernel) and “app”-style deployment of mission planning functions (e.g., command/telemetry management, health monitoring) (Section III). The “open software framework” enables reconfiguration without hardware changes, critical for long-duration missions (Section III, VII).

Interface abstraction: The FPGA handles time-sensitive I/O (PPS, RS422, LVDS), while the CPU focuses on application logic, allowing future interface updates via FPGA firmware changes (Section III.D).

Validation: Ground tests demonstrated app reconfiguration (e.g., swapping data fusion algorithms) and interface protocol updates without system modification (Section V).

Hardware-software co-design significantly improves system robustness in radiation-prone environments

Space radiation (SEUs, latchup) requires coordinated protection across hardware and software, a principle embedded in MPB’s design.

Hardware-level mitigation:

Radiation-tolerant components: LS2K2000 CPU (28 nm FD-SOI, TID > 100 krad(Si), SEL immunity) and ISSI DDR4 SDRAM (TID>100kRad, SEU > 0.4 Mev-cm²/mg) (Section II.B, II.C).

Redundancy: Triple modular redundancy (TMR) for SPI FLASH (startup code, 3×IS25LP128), 3-copy NAND Flash (OS), and hot-standby CAN buses (A/B) (Section II.C, IV.A, Table 5).

Software-level mitigation:

ECC for memory: DDR4 (4GB) and SSD (256GB) with ECC to correct single-bit errors (Section II.C, IV.A.2).

Redundant boot: 3-copy OS in NAND Flash with 2-out-of-3 comparison, and “core trimodule hardening” (3 core image copies with 2-out-of-3 loading) (Section IV.A.2).

Fault tolerance: Watchdog circuits, software reconfiguration, and independent power control for NPU/SSD (Section II.C, IV.A.7).

Validation: Environmental tests (thermal cycle, thermal vacuum) showed no functional degradation, and ECC corrected 1-bit SEUs in DDR4 during 72 + hours of operation (Section V, IV.A.2).

Redundancy at multiple levels (storage, boot, communication) is essential for sustained autonomous operation

MPB’s “defense-in-depth” redundancy design, tailored to component criticality, ensures operation despite failures.

Storage redundancy: 3×SPI FLASH (TMR for startup code), 3×NAND Flash (OS), and SSD (256GB) + eMMC (32GB) mutual backup (Section II.C, IV.A, Table 5).

Boot redundancy: 2-out-of-3 comparison of 3 OS copies, and “traversal startup” of the OS (Section IV.A.2).

Communication redundancy: CAN bus A/B hot standby (3.2ms switch time) and LVDS/RS422 interface buffering via FPGA (Section II.C, III.D, Table 5).

Information redundancy: CAN bus data with accumulate check, NAND Flash with ECC, and FPGA TMR (Section IV.A.3, IV.A.4).

Validation: CAN bus switch tests confirmed <5ms failover with no telemetry loss, and 3-copy storage verification passed ground tests (Section V, Table 5).

These lessons converge on a core principle: onboard autonomy platforms must balance computational capability with reliability-driven design. The MPB’s engineering implementation—from requirement-driven component selection (LS2K2000 for performance/radiation balance) to modular software and layered redundancy—demonstrates that flexibility, not just peak performance, enables long-term autonomous operation. This approach, validated through ground tests, environmental qualification, and initial in-orbit validation, provides a template for future satellite missions (Section VIII).

Conclusion

This paper presents a scientific framework for designing onboard autonomous computing platforms, instantiated via the Mission Planning Board (MPB). By deriving architecture from mission planning requirements (dynamic replanning, data processing, reliability) and validating it through engineering tests, we demonstrate that flexible reliability—combining modularity, redundancy, and performance margin—is the cornerstone of effective onboard autonomy.

Through ground-based functional tests, environmental qualification experiments, and initial in-orbit engineering validation, the MPB demonstrated stable operation, reliable interface communication, and correct execution of designed hardware and software functions. These results validate the feasibility of the proposed architecture as an onboard computing platform at the system level.

This work does not claim quantitative performance evaluation of autonomous mission planning or intelligent algorithms. Instead, it provides an engineering foundation upon which such algorithms may be deployed and evaluated in future missions.

Future work will focus on long-term on-orbit performance assessment, integration of mission-specific planning and learning algorithms, and extension of the proposed architecture to a broader range of satellite platforms and mission scenarios.

Author contributions

Author ContributionsJianing Rao and Miao Ma served as the project leaders, providing overall project management, technical guidance, and strategic direction throughout the research and development process.Wenjie Zhao conceived the study framework, carried out the system-level design, and was primarily responsible for drafting the manuscript.Guofeng Xue was responsible for the hardware architecture design and electronic system implementation of the mission planning board.Jianzhe Zhang designed and implemented the CPU-related software, including the operating system environment and application-level software framework.Shuanglong Li developed the FPGA software, including interface control logic and redundancy-related functions.Yan Zhu and Junshe An contributed to manuscript review, provided conceptual insights, and offered critical feedback that improved the clarity and technical rigor of the study.All authors reviewed and approved the final manuscript.

Funding

This paper was supported by National Key Research and Development Program of China (Project No. 2022YFF0503903).

Data availability

The data supporting the findings of this study are not publicly available due to their involvement in proprietary hardware designs, detailed electronic schematics, firmware implementations, and mission-specific configuration parameters associated with the Mission Planning Board. Disclosure of these materials is restricted by institutional and project-level confidentiality requirements. Non-sensitive information related to the overall system architecture, test methodologies, and representative environmental test conditions can be made available from the corresponding author upon reasonable request. All requests will be evaluated to ensure compliance with applicable confidentiality and security policies.

Declarations

Competing interests

The authors declare no competing interests.