A multi-threaded satellite on-orbit autonomous mission planning system and method

Abstract

The application provides a multi-thread satellite on-orbit autonomous task planning system and method. The system comprises a support layer comprising a plurality of system service encapsulation modules, the support layer being configured for hardware access encapsulation and operating system service adaptation; a data interaction layer comprising a shared memory area and an asynchronous message queue; and an application layer comprising a plurality of functional modules, specifically comprising: a module loading and thread management module, a telemetry and telecontrol module, a task prediction module, a target planning module and an observation initiation module; wherein the system uses a multi-thread scheduling mechanism combining event driving and periodic driving. The planning system proposed by the application realizes mode conversion from ground centralized planning to real-time autonomous planning on the satellite, and shortens the emergency task response time from the hour level to the minute level.

Description

Technical Field

[0001] This invention relates to the field of spacecraft on-orbit management and control technology, and in particular to a multi-threaded satellite on-orbit autonomous mission planning system and method, which runs on the onboard computing unit and is suitable for satellite air and ground observation missions. Background Technology

[0002] With the rapid development of aerospace technology, satellite application missions are becoming increasingly complex and dynamic, placing unprecedented demands on on-orbit autonomous mission planning capabilities. For example, scenarios such as emergency observation of sudden disasters, continuous tracking of moving targets, multi-payload collaborative operations, and autonomous constellation collaboration all require satellites to respond quickly to environmental changes and make real-time planning decisions on-orbit. However, current mainstream satellite mission planning technologies reveal three interrelated core bottlenecks when addressing these challenges: First, the strong dependence on ground-based systems leads to real-time bottlenecks. Most existing mission planning systems follow the traditional paradigm of "centralized ground-based computing and passive onboard execution." The specific process involves ground control stations receiving satellite status data, large-scale ground computing facilities running complex planning algorithms to generate detailed command sequences, which are then injected into the satellite via uplink for execution. This long "sensing, downlinking, planning, uplinking, and execution" chain results in response delays of several hours or even longer, completely failing to meet the demands of emergency missions with extremely high time sensitivity. The root cause is that onboard software is designed only as a "command interpreter" and "timing trigger," lacking on-orbit real-time autonomous decision-making capabilities at the architectural level. This ground-centric planning model has become the primary obstacle to improving satellite rapid response capabilities.

[0003] Second, the "siloed" custom development model leads to a portability bottleneck. Currently, spaceborne mission planning software generally adopts a "one-to-one" deep customization development model tailored to specific satellite platforms, payloads, and missions. This model results in a "siloed" structure for the software system, with highly tight internal coupling: hardware drivers, business logic, core algorithms (such as orbit prediction and resource scheduling) are intertwined and bound to the underlying operating system. When it is necessary to port existing software to a new satellite model (such as migrating from a platform based on a certain processor to one based on the "Loongson 2K2000"), or to integrate a new planning algorithm, engineers have to make extensive and in-depth modifications and adaptations to the original code. Such modifications are not only time-consuming and costly, but also highly susceptible to introducing unforeseen errors, compromising system stability. More seriously, it hinders the cross-platform and cross-model reuse of advanced algorithms and software modules, making the entire industry's technological iteration pace sluggish and unable to adapt to the new normal of rapid evolution in satellite platform and mission requirements.

[0004] Third, there are systemic risks associated with the reliable operation of high-performance computing units in orbit. To meet the computing power demands of complex planning algorithms, new-generation satellites are incorporating high-performance processors such as the Loongson 2K2000. However, the reliability of these processors and their complex software systems operating in the harsh space radiation environment over long periods presents inherent challenges compared to traditional, single-function satellite computers. If a traditional software architecture with coarse-grained thread management and poor module isolation is adopted, an anomaly in one module or a deadlock in one thread could cause the entire planning system to crash, thereby affecting the satellite's core mission. Therefore, how to utilize high-performance computing capabilities while isolating risks and ensuring overall system reliability through innovative software architecture design has become a pressing systems engineering problem.

[0005] While some existing research attempts to introduce more intelligent planning algorithms on-board, it often overlooks the criticality of the software infrastructure supporting these algorithms. A typical contradiction is that advanced, dynamically adjustable algorithms are "crammed" into a static, single-threaded, loop-based software framework, rendering their advantages ineffective. This makes the system prone to problems such as delayed response, resource contention, and fault propagation when facing mixed, concurrent, and highly dynamic task flows, making it difficult to support true on-orbit autonomy and intelligence.

[0006] In summary, the challenges facing satellite mission planning have evolved from simple algorithm performance issues to a comprehensive challenge involving system architecture, real-time scheduling, reliability engineering, and software engineering. The industry urgently needs a new system architecture paradigm that simultaneously meets the following requirements: 1) supports real-time on-orbit decision-making and rapid response; 2) achieves high modularity and decoupling, supporting rapid portability and upgrades; and 3) incorporates robust fault-tolerance mechanisms to ensure reliable operation on high-performance computing units. Summary of the Invention

[0007] The objective of this invention is to provide a multi-threaded satellite on-orbit autonomous mission planning system and method. Through the system and / or method, the problems of poor real-time performance, weak portability, and insufficient reliability of existing satellite mission planning software are solved, realizing the transformation from ground-based centralized planning to on-board real-time autonomous planning, and shortening the emergency mission response time from hours to minutes.

[0008] In a first aspect of the invention, the aforementioned task is addressed by a multi-threaded on-orbit autonomous mission planning system for satellites, the system comprising: A support layer, comprising multiple system service encapsulation modules, is configured for hardware access encapsulation and operating system service adaptation. The data interaction layer includes a shared memory area and an asynchronous message queue; and The application layer includes multiple functional modules, specifically: module loading and thread management module, telemetry and remote control module, task prediction module, target planning module, and observation initiation module; The system uses a multi-threaded scheduling mechanism that combines event-driven and period-driven approaches. The event-driven and period-driven multi-threaded scheduling mechanism includes: using differentiated thread driving and execution strategies for different modules based on task characteristics, specifically including: The cycle-driven thread uses a short-cycle creation and destruction strategy, applicable to modules including telemetry and remote control modules and observation initiation modules. The short-cycle creation and destruction strategy includes: triggering a system timer to dynamically create a new thread instance to execute the module's work for the current cycle; the thread instance terminates itself after completing its deterministic workflow; and... Event-driven threads employ a long-term sleep and event-driven wake-up strategy, applicable to modules including task forecasting and goal planning. The long-term sleep and event-driven wake-up strategy includes: the thread actively sleeps after creation, blocking on its dedicated asynchronous message queue; when an external event occurs, other modules or timers send a corresponding wake-up message to the asynchronous message queue; the operating system then schedules the thread to execute; the thread retrieves a message from the queue and executes the complete calculation process; after the thread finishes, it returns to the sleep state.

[0009] In one embodiment of the present invention, the support layer includes a hardware access encapsulation module and an operating system service adaptation module; The hardware access encapsulation module is configured to encapsulate driver calls to the CAN controller, RS422 serial port, and GPIO into a unified Python API interface. The operating system service adaptation module is configured to perform secondary encapsulation of the native multithreading, timer, inter-process communication, and file system services provided by Linux.

[0010] In one embodiment of the present invention, the shared memory area is used to store status data, including satellite orbit parameters, mission mode identifier, and system health status; and The asynchronous message queue is used for the transmission of events and instructions between modules. Functional modules that need to receive events have independent input message queues. The asynchronous message queue is configured as a circular buffer with overflow protection.

[0011] In one embodiment of the present invention, the module loading and thread management module is configured to perform system initialization, critical data set recovery, and dynamic creation and management of the lifecycle and scheduling strategies of all threads; The telemetry and remote control module is configured to integrate telemetry acquisition and transmission with remote control command reception and parsing; The mission prediction module is configured for rapid visibility prediction and coarse screening of targets for air or ground observation. The target planning module includes an attitude adjustment calculation and fine planning submodule, configured for precise trajectory extrapolation, attitude guidance law calculation, load parameter generation, and final task sequence optimization; and The observation initiation module is configured to monitor and issue generated task instruction packages according to timing requirements.

[0012] In one embodiment of the present invention, the key data set includes orbital parameters, mission configuration, and target library index; the key data set is serialized and stored in a designated area of ​​non-volatile memory triggered by ground commands or specific events; the system automatically restores the key data set from the non-volatile memory each time it starts up.

[0013] In one embodiment of the present invention, the system is deployed on the mission planning board of a satellite platform and interacts with the satellite management unit of the integrated electronic system of the satellite via a communication bus and an asynchronous serial port.

[0014] In a second aspect of the invention, the aforementioned task is also addressed by a multi-threaded satellite on-orbit autonomous mission planning method, which uses the aforementioned multi-threaded satellite on-orbit autonomous mission planning system and includes the following steps: System initialization and hot recovery; The creation and scheduling of differentiated threads are initiated by creating all functional threads according to the configuration table and applying different scheduling strategies: creating telemetry and remote control threads and observation initiation threads, binding timers to them, and starting the creation and destruction cycle; creating task forecasting threads and target planning threads, which then sleep after creation, waiting for the wake-up event of their respective message queues; The event-driven dynamic task planning closed loop includes trigger prediction sub-steps, trigger fine planning and attitude calculation sub-steps, and monitoring and distribution sub-steps; and Configurable system maintenance supports triggering on-site saving operations via ground commands, which will persist all current critical data and create a new system snapshot.

[0015] In one embodiment of the present invention, the triggering prediction sub-step includes: the telemetry and remote control module parses the uploading end instruction and sends an MSG_NEW_TARGET event to the task prediction thread message queue; the task prediction thread is awakened, performs orbit extrapolation and visibility analysis, writes the results into the unplanned set in shared memory, and replies to the satellite service via the CAN bus with a feedback packet including the next power-on time; The triggering of the fine planning and attitude calculation sub-steps includes: using an independent monitoring thread or a timer based on system time to compare the intersection times of targets in the planning set in real time; when the difference reaches a preset threshold, sending an MSG_PLANNING_TRIGGER event to the target planning thread queue; the target planning thread is awakened, generates the final task sequence, and stores it in the planning result queue; and The monitoring and distribution sub-steps include: the periodically running observation initiation thread checks the planning result queue in each execution cycle, and when the preset execution time of the task package is close, the task package is sent to the satellite service module via the CAN bus.

[0016] In a third aspect, the present invention also provides an electronic device comprising: A processor, configured to execute machine-readable instructions; A graphics card configured to train the multi-threaded satellite on-orbit autonomous mission planning method; and A memory configured to store machine-readable instructions that, when executed by a processor and / or graphics card, perform the steps of the multi-threaded satellite on-orbit autonomous mission planning method.

[0017] In a fourth aspect, the present invention also provides a computer-readable storage medium having stored thereon computer-readable instructions which, when executed by a processor, perform the steps of the multi-threaded satellite on-orbit autonomous mission planning method.

[0018] The technical solution provided by this invention has the following advantages: 1. The multi-threaded on-orbit autonomous mission planning system and method proposed in this invention achieves essential on-orbit real-time autonomous capability. Through event-driven threads, the system can respond to on-board events (e.g., new targets, timed triggers) in milliseconds and perform complete planning calculations on-site, compressing the traditional large-scale closed loop between satellite and ground into a small-scale closed loop on-board. This reduces the response time for emergency observation missions from hours to minutes, greatly enhancing the satellite's autonomy and timeliness.

[0019] 2. The multi-threaded on-orbit autonomous mission planning system and method proposed in this invention provides excellent software portability and maintainability. The modules are highly decoupled; the three-layer architecture, especially the standardized data interaction layer, strictly defines the interfaces between modules (e.g., message formats, shared data structures), ensuring that upgrading any functional module in the application layer (e.g., replacing the orbit prediction algorithm from HPOP to a higher-precision numerical integrator) has almost no impact on other modules. Hardware dependencies are isolated; the support layer encapsulates all hardware operations. When porting to a new satellite platform (e.g., replacing the CPU or bus), only the support layer's driver program and a small amount of hardware-related code need to be adapted or rewritten. The application layer's business logic modules can be reused as a whole, reducing the porting workload by more than 70% and significantly reducing the risk of introducing new errors.

[0020] 3. The multi-threaded on-orbit autonomous mission planning system and method proposed in this invention constructs an inherently highly reliable operating environment. The creation and destruction strategy of short-cycle threads divides the software operation into a series of independent, stateless execution units from a time dimension. Any transient fault within a unit is completely cleared when the thread ends, preventing it from propagating and achieving automatic fault clearing. The periodic system snapshot mechanism enables the system to recover to the most recent known healthy mission state within seconds after encountering an uncorrectable error reset, ensuring the continuity of long-cycle complex tasks. Through asynchronous communication of message queues and lock protection of shared memory, the competitive access to data between modules is fundamentally eliminated, improving the operational stability in a multi-threaded environment.

[0021] 4. The multi-threaded on-orbit autonomous mission planning system and method proposed in this invention achieves efficient utilization and flexible allocation of computing resources. The on-demand startup characteristic of event-driven threads means that computationally intensive planning algorithms only occupy the CPU when a mission is triggered, while the system resources are used to serve high-priority periodic tasks (such as telemetry) at other times. This dynamic resource allocation mode is very suitable for the energy-saving and long-life design requirements of mission planning boards that operate intermittently, and also makes it possible to run more complex intelligent algorithms under limited onboard computing power. Attached Figure Description

[0022] To further illustrate the above and other advantages and features of the various embodiments of the present invention, a more specific description of the various embodiments of the present invention will be presented with reference to the accompanying drawings. It is to be understood that these drawings depict only typical embodiments of the invention and are therefore not intended to limit its scope. In the drawings, identical or corresponding parts will be indicated by identical or similar reference numerals for clarity.

[0023] Figure 1 A schematic diagram of the architecture of a multi-threaded satellite on-orbit autonomous mission planning system according to an embodiment of the present invention is shown. Figure 2A schematic diagram of a periodic-driven scheduling strategy according to an embodiment of the present invention is shown; Figure 3 A schematic diagram of an event-driven scheduling strategy according to an embodiment of the present invention is shown; Figure 4 This diagram illustrates a comparison of the lifecycles of a periodically driven thread and an event-driven thread according to an embodiment of the present invention; and Figure 5 A flowchart illustrating a multi-threaded on-orbit autonomous mission planning method for satellites according to an embodiment of the present invention is shown. Detailed Implementation

[0024] In the following description, the invention is described with reference to various embodiments. However, those skilled in the art will recognize that the embodiments may be practiced without one or more specific details or with other alternatives and / or additional methods or components. In other instances, well-known structures or operations are not shown or described in detail so as not to obscure the inventive points of the invention. Similarly, for illustrative purposes, specific numbers and configurations are set forth to provide a comprehensive understanding of the embodiments of the invention. However, the invention is not limited to these specific details.

[0025] In this specification, references to "an embodiment" or "this embodiment" mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment of the invention. The phrase "in one embodiment" appearing throughout this specification does not necessarily refer to the same embodiment in all instances.

[0026] It should be noted that the embodiments of the present invention describe the method steps in a specific order; however, this is only for illustrating the specific embodiment and not for limiting the order of the steps. On the contrary, in different embodiments of the present invention, the order of the steps can be adjusted according to actual needs.

[0027] In this invention, the various networks, modules, or units of the system according to the invention can be implemented using software, hardware, firmware, or a combination thereof. When a module is implemented using software, its function can be implemented through computer program flow. For example, the module can be implemented using code segments (such as code segments in languages ​​like C and C++) stored in a storage device (such as a hard disk, memory, etc.), wherein the corresponding function of the module can be implemented when the code segment is executed by a processor. When a module is implemented using hardware, its function can be implemented by setting a corresponding hardware structure. For example, the module's function can be implemented by hardware programming a programmable device such as a field-programmable gate array (FPGA), or by designing an application-specific integrated circuit (ASIC) that includes multiple transistors, resistors, capacitors, and other electronic devices. When a module is implemented using firmware, the module's function can be written in the form of program code into a read-only memory such as an EPROM or EEPROM of the device, and the corresponding function of the module can be implemented when the program code is executed by a processor. In addition, some functions of the module may need to be implemented by separate hardware or by working in cooperation with the hardware. For example, the detection function is implemented by a corresponding sensor (such as a proximity sensor, accelerometer, gyroscope, etc.), the signal transmission function is implemented by a corresponding communication device (such as a Bluetooth device, infrared communication device, baseband communication device, Wi-Fi communication device, etc.), the output function is implemented by a corresponding output device (such as a display, speaker, etc.), and so on.

[0028] To address the issues of poor real-time performance, weak portability, and insufficient reliability in existing satellite mission planning software, this invention provides a multi-threaded satellite on-orbit autonomous mission planning system and method. The multi-threaded satellite on-orbit autonomous mission planning system provided by this invention is, for example, a highly modular software system based on a multi-threaded collaborative and event-driven architecture. This system aims to fundamentally improve the on-orbit real-time response capability, cross-platform and cross-mission portability, and long-term on-orbit operational reliability of mission planning software through an innovative hierarchical modular design and an event / cycle dual-driven multi-threaded model. The system enables a shift from centralized ground-based planning to real-time autonomous on-board planning, reducing emergency mission response time from hours to minutes or even seconds. Furthermore, the system constructs a loosely coupled software framework, allowing core functional modules to be independently developed, tested, replaced, and upgraded like "Lego bricks," significantly reducing the cost and risk of integrating new algorithms and adapting to new models. The multi-threaded on-orbit autonomous mission planning system provided by this invention ensures that even if a single computing module experiences a momentary failure, the entire mission planning system can still maintain the normal operation or safe degradation of its core functions through differentiated thread lifecycle management and resource isolation strategies.

[0029] Figure 1 A schematic diagram of the architecture of a multi-threaded satellite on-orbit autonomous mission planning system according to an embodiment of the present invention is shown. Figure 1 As shown, the multi-threaded on-orbit autonomous mission planning system for satellites provided by this invention includes: a support layer 101, a data interaction layer 102, and an application layer 103. For example... Figure 1 As shown, the multi-threaded on-orbit autonomous mission planning system provided by this invention is deployed on the mission planning board hardware 100 of the satellite platform (e.g., a module with Loongson 2K2000 as the main processor), and interacts with the satellite service management unit of the integrated electronic system through a communication bus (e.g., CAN bus) and an asynchronous serial port (e.g., RS422). In one embodiment of this invention, the multi-threaded on-orbit autonomous mission planning system is a software system. This software system adopts a three-layer, two-drive overall architecture, where the three layers refer to the support layer, the data interaction layer, and the application layer, and the two drives refer to a thread scheduling mechanism that combines event-driven and period-driven approaches.

[0030] Support layer 101 runs in Linux user space and consists of a series of system service encapsulation modules, primarily used for hardware access encapsulation and operating system service adaptation. Support layer 101 does not directly contain business logic. Support layer 101 includes hardware access encapsulation modules and operating system service adaptation modules.

[0031] The hardware access encapsulation module is used to encapsulate driver calls to underlying hardware (such as CAN controller, RS422 serial port, GPIO for receiving second pulses PPS) into a unified and secure Python API interface, shielding the hardware details from the top.

[0032] The operating system service adaptation module is used to perform secondary encapsulation of Linux's native multithreading, timer, inter-process communication (IPC), file system and other services to suit aerospace applications, providing a simpler and more fault-tolerant calling interface.

[0033] The support layer 101 is key to software portability. When the hardware platform changes, only the hardware encapsulation module of this layer needs to be modified or rewritten, and the upper-layer business logic can be reused to the greatest extent.

[0034] The data interaction layer 102, as the core decoupling layer of this architecture, is a logically standardized data exchange center. It does not contain business logic and only provides two core mechanisms: a shared memory area and an asynchronous message queue.

[0035] The shared memory area is used to store global state data that needs to be frequently accessed by multiple modules, such as satellite orbit parameters, mission mode identifiers, and system health status. Access is protected by mechanisms such as mutex locks.

[0036] Asynchronous message queues are used for event and instruction passing between modules. Each functional module that needs to receive events has its own independent input message queue. For example, remote control instructions, target completion events, and planning trigger events are all encapsulated as messages and delivered to the corresponding module's queue. This design completely decouples direct calls between modules, allowing modules to focus only on their own queues and shared memory, achieving physical isolation and logical connectivity between modules.

[0037] Application layer 103 consists of multiple highly cohesive and loosely coupled business function modules, each running on an independent thread. The core modules include: a module loading and thread management module, a telemetry and remote control module, a task prediction module, a target planning module, and an observation initiation module.

[0038] The module loading and thread management module includes the system entry point, which is responsible for system initialization, recovery of critical data sets, and dynamic creation and management of the lifecycle and scheduling strategies of all functional threads.

[0039] The telemetry and remote control module is used to integrate telemetry data acquisition and transmission with remote control command reception and parsing functions.

[0040] The mission forecasting module is responsible for rapid forecasting and coarse screening of the visibility of airborne or ground-based observation targets.

[0041] The target planning module includes attitude calculation and fine planning sub-modules, which are responsible for accurate trajectory extrapolation, attitude guidance law calculation, load parameter generation, and final task sequence optimization.

[0042] The observation initiation module is responsible for monitoring and issuing the generated task instruction packages according to the timing requirements.

[0043] This invention employs differentiated thread-driven and execution strategies for different modules based on task characteristics to achieve an optimal balance between real-time performance, efficiency, and reliability. Specifically, the system utilizes a multi-threaded scheduling mechanism that combines event-driven and periodic-driven approaches.

[0044] Figure 2 A schematic diagram of a periodic-driven scheduling strategy according to an embodiment of the present invention is shown. Figure 3 A schematic diagram of an event-driven scheduling strategy according to an embodiment of the present invention is shown. Figure 4 A schematic diagram comparing the lifecycles of a periodically driven thread and an event-driven thread according to an embodiment of the present invention is shown below. Figures 2-4 This explains the cycle-driven thread 201 and the event-driven thread 301.

[0045] like Figure 2 , Figure 4 As shown, the periodic-driven thread 201 uses a short-cycle creation and destruction strategy, applicable to modules including the telemetry and remote control module and the observation initiation module. The periodic-driven thread 201 includes a telemetry and remote control thread and an observation initiation thread. The short-cycle creation and destruction strategy includes: triggering a system timer (e.g., every 1 second) to dynamically create a new thread instance to execute the module's work for the current cycle (e.g., collecting and sending telemetry data, checking the task package distribution queue once), and the thread instance terminates itself after completing its deterministic workflow.

[0046] The advantages of periodically driven threads are: deterministic real-time performance, ensuring the strict periodicity of critical services such as telemetry; fault isolation, any software errors within a thread (such as memory out-of-bounds errors or computational anomalies) are limited to a single cycle and cleared as the thread is destroyed, without accumulating or polluting the next cycle, greatly enhancing the system's fault tolerance; and resource cleanliness, avoiding problems such as memory leaks that may occur with long-running threads.

[0047] like Figure 3 , Figure 4As shown, event-driven thread 301 uses a long-term sleep and event-driven wake-up strategy, applicable to modules including the task forecasting module and the target planning module. Event-driven thread 301 includes a task forecasting thread, a target planning thread, and a pose adjustment calculation thread. The long-term sleep and event-driven wake-up strategy involves these threads being actively suspended (i.e., sleeping) after creation, blocked on their dedicated asynchronous message queue. When an external event occurs (such as receiving a "betting complete" instruction, the target rendezvous time approaching, or the pose adjustment enable flag being set), other modules (such as the remote control module) or timers post the corresponding wake-up message to the queue. The operating system then schedules the thread to execute, the thread retrieves the message from the queue and executes the complete calculation process, and the thread returns to the sleep state after completion.

[0048] It should be noted that, Figure 2 and Figure 3 In Python, the main function, such as the `main` function, is the entry point for the software after it starts. The `main` function contains many module functions, but these module functions do not run directly on the `main` function. Instead, each module function is executed by a separate thread created by Python, performing only its specific functionality. This ensures independence from other modules. When a module function finishes execution, its thread cannot remain within the module, as this would cause memory leaks. Therefore, to prevent this, Python automatically destroys the thread corresponding to the module function after its execution. Figure 2 and Figure 3 The term "function end" in this context refers to the termination of execution of a module function that includes thread functionality.

[0049] The advantages of event-driven threads are: real-time response, as the corresponding processing thread can be woken up within milliseconds once an event occurs, meeting the need for rapid response; resource efficiency, as computationally intensive planning threads only run when necessary, avoiding idle running and consuming valuable CPU resources during waiting periods, making them particularly suitable for the "on-demand power-on" task planning board working mode; and loose coupling, as modules communicate through message queues, the sender does not need to know the internal state of the receiver, achieving complete decoupling.

[0050] In one embodiment of the invention, the system defines and maintains a set of critical data (e.g., orbital parameters, mission configuration, and target library index). This critical data set can be serialized and stored in a designated area of ​​non-volatile memory, triggered by ground commands or specific events. Each time the system starts, it automatically restores these critical data sets from the non-volatile memory, ensuring the continuity of mission status and enabling "breakpoint resumption." Furthermore, all asynchronous message queues are designed as self-protected circular buffers to ensure that critical event messages are not lost under high load.

[0051] This invention also provides a multi-threaded satellite on-orbit autonomous mission planning method, which can use the aforementioned multi-threaded satellite on-orbit autonomous mission planning system, such as... Figure 5 As shown, the method includes the following steps: Step 501: System initialization and state hot recovery.

[0052] After the satellite mission planning board is powered on, the Linux operating system is started first. After the operating system completes kernel loading and driver initialization, it automatically or according to configuration starts the module loading and thread management module of the mission planning software described in this invention. Subsequently, this module reads the system snapshot file from a designated area of ​​non-volatile memory (such as SSD), automatically restores key mission field data such as the six satellite orbital elements, mission configuration table, and the labeled target library, so that the system quickly enters the most recent mission-ready state, rather than the initial state of a cold start.

[0053] Step 502: Creation and scheduling of differentiated threads. Start by creating all functional threads according to the configuration table and applying different scheduling strategies.

[0054] Specifically, create and immediately start the telemetry and remote control thread and the observation initiation thread, and bind them to a timer with a period of T1 (e.g., 1 second) to start the creation and destruction cycle; create the task forecast thread, the target planning thread and the attitude calculation thread, and suspend (sleep) them immediately after creation, waiting for the wake-up event of their respective message queues.

[0055] It's important to note that event or thread wake-ups have no priority. Modules are linearly related, and task planning is typically based on the order of time. If two tasks overlap, they must be prioritized.

[0056] Step 503: Event-driven dynamic task planning closed loop, specifically including the trigger prediction sub-step, the trigger fine planning and attitude calculation sub-step, and the monitoring and distribution sub-step.

[0057] The triggering of the forecast sub-step includes: when new target data is injected from the ground via the remote control link and a "injection end" command is sent, the telemetry and remote control module parses the command and sends an MSG_NEW_TARGET event to the message queue of the mission forecast thread. The mission forecast thread is then awakened, performs orbit extrapolation and visibility analysis, writes the results to the unplanned set in shared memory, and replies to the satellite administrators via the CAN bus with a feedback packet including the next power-on time.

[0058] The triggering of the fine planning and attitude calculation sub-steps includes: A separate monitoring thread or a timer based on system time compares the intersection times of targets in the planning set in real time. When the difference reaches a preset threshold (e.g., 3 minutes earlier for an air task), an MSG_PLANNING_TRIGGER event is sent to the target planning thread queue. The target planning thread is awakened, performs high-precision calculations, generates the final task sequence, and stores it in the planning result queue. Simultaneously, if attitude adjustment is required, the attitude adjustment calculation thread is triggered in advance.

[0059] The monitoring and distribution sub-steps include: the periodically running observation initiation thread checks the planning results queue in each execution cycle. Once it detects that the preset execution time of a task package is approaching (e.g., 260 seconds in advance), it is immediately sent to the satellite service module via the CAN bus to drive payload execution.

[0060] Step 504: Configurable system maintenance, which supports triggering the saving of on-site operations via ground commands, to persist all current critical data again, forming a new system snapshot, and providing a rapid recovery baseline for dealing with possible space single-event upsets and other failures.

[0061] The following example, using a remote sensing experimental satellite with air-to-ground remote sensing and SAR imaging capabilities, illustrates the multi-threaded on-orbit autonomous mission planning system and method proposed in this invention.

[0062] The hardware and basic software environment of this system are as follows: This system is deployed on a satellite mission planning board. Its hardware core is a Loongson 2K2000 processor, equipped with DDR4 memory as a program cache, and uses large-capacity eMMC or SSDs for storing the operating system, applications, and mission data. Physical interfaces include: The CAN bus controller, as the core communication link with the satellite management unit in the integrated satellite electronic system, is used to transmit telemetry and remote control data as well as mission command packets.

[0063] The RS422 asynchronous serial port is mainly used to receive software reconstruction (update) data packets from the ground; at the same time, this serial port is also multiplexed to receive the pulse-per-second (PPS) signal distributed by the mission management unit, providing a high-precision time synchronization reference for the mission planning board.

[0064] After the task planning board is powered on, the bootloader first loads the Linux operating system kernel. After the kernel completes initialization and mounts the root file system, it automatically starts the task planning main program described in this invention. All software modules of this system run as user-space processes on the Linux environment.

[0065] The system startup and initialization are as follows: After the task planning board is powered on and the hardware is initialized, U-Boot boots and loads the Linux kernel. After the kernel completes initialization, it starts the user space initialization process and finally executes the startup script to start the main Python program of this task planning software (such as task_mng_main.py).

[0066] The module loading and thread management module runs first. This module reads the latest imp_data.dat file from the SSD's user data area and successfully recovers orbit coefficients, task configuration tables, target file lists, etc. If the file does not exist or is corrupted, it initializes with default parameters and records alarm telemetry.

[0067] This module calls the initialization function of the underlying interface module to perform operations such as clearing data, initializing data pointers, and re-establishing message queue channels for the underlying driver buffer of the CAN channel and RS422 channel connected to the spacecraft, as well as the shared memory area of ​​the data interaction layer and various asynchronous message queues.

[0068] After the data interaction layer initialization is completed, the main module (i.e., the application layer) begins creating business threads: a telemetry and remote control thread is created, bound to a timer with a period of 1000ms, and its periodic loop is started; an observation initiation thread is created, bound to a timer with a period of 1000ms, and its periodic loop is started; a task prediction thread is created, and its execution body is blocked on a message queue named MsgQ_Predict and put to sleep; a target planning thread is created, and its execution body is blocked on a message queue named MsgQ_Planning and put to sleep; a posture calculation thread is created, and its execution body is blocked on a message queue named MsgQ_Attitude and put to sleep.

[0069] The following example illustrates the application of the multi-threaded on-orbit autonomous mission planning system and method proposed in this invention in dynamic mission planning.

[0070] Example 1: Rapid response to moving air targets. The specific process is as follows: 1. When a new space-moving target is detected on the ground via the telemetry and control network, its orbital data is immediately generated and uploaded via the remote control link.

[0071] 2. The satellite mission module forwards the power-on initialization package (informing the mission planning board of the reason for power-on) and data packets to the mission planning board via the CAN bus.

[0072] 3. During its current execution cycle, the periodically running telemetry and remote control thread receives the boot initialization package and submits a message to the MsgQ_Predict queue {Event type: New target annotation, file path: / boot / task_app / task_1 / data_file / task_target, event status: pending update}.

[0073] 4. When the periodically running telemetry and remote control thread receives the data packet during its current execution cycle, it performs the verification and stores it as a target file in the SSD (such as target_20260131.dat).

[0074] 5. Before the end of the cycle, the same thread posts a message to the MsgQ_Predict queue {Event type: New target post, File path: / boot / task_app / task_1 / data_file / task_target, Event status: Updated}.

[0075] 6. The task forecasting thread, which is in a dormant state, is awakened upon receiving the above message. This thread will traverse the target data file path, combine it with the real-time orbit of the local satellite, and use the HPOP model for rapid extrapolation to calculate that there will be a high-quality rendezvous opportunity in approximately 25 minutes.

[0076] 7. The forecast thread writes the detailed information of this opportunity (rendezvous time Tc, geometric relationship) into the unplanned set in the mission data buffer, and sends a power-on feedback packet to the space service via the CAN bus: {current shutdown time: Tnow+5s, next planned power-on time: Tc-10min}. Then, the thread enters sleep mode again.

[0077] 8. The mission planning module shuts down the mission planning board after Tnow+5s, and then restarts the mission planning board at Tc-10min, sending a boot initialization package to it.

[0078] 9. During its current execution cycle, the periodically running telemetry and remote control thread receives the boot initialization packet and submits a message to the MsgQ_Predict queue {Event type: last planning result boot, file path: / boot / task_app / task_1 / data_file / task_target, event status: updated}.

[0079] 10. The mission forecasting thread, which is in a dormant state, is immediately awakened by this message. This thread will traverse the target data file path, combine it with the real-time orbit of the local satellite, and use the HPOP model to quickly extrapolate, calculating that there is a high-quality rendezvous opportunity approximately 5 minutes later and 200 minutes later (the current rendezvous time Tc, the next rendezvous time Tnext).

[0080] 11. The forecast thread writes the detailed information of this opportunity (rendezvous time Tc, geometric relationship) into the unplanned set in the mission data buffer, and sends a power-on feedback packet to the space service via the CAN bus: {This shutdown time: Tnow+6min, next planned power-on time: Tnext-10min}. Then, the thread enters sleep mode again.

[0081] 12. When the time monitoring mechanism detects that Tc is approaching, it automatically sends a planning trigger message to the MsgQ_Planning queue.

[0082] 13. The target planning thread is awakened and performs high-precision HPOP track extrapolation and load parameter calculation. Within 2 seconds, it generates an air-to-ground task package containing specific power-on / off instructions and tracking angles, and puts its pointer into the planning result queue.

[0083] 14. The observation initiation thread, which operates periodically, retrieves the task packet from the queue in the next second cycle, determines that the execution time is approaching, and immediately sends it to the satellite service via the CAN bus.

[0084] Example 1 demonstrates a rapid response to airborne moving targets. From ground-based injection to satellite-based dissemination of planning results, the entire process is completed on-board, with the time consumption primarily depending on the orbit extrapolation calculation time (in seconds), achieving near real-time response.

[0085] Example 2: Demonstration of regional target imaging and software module upgrade. The specific process is as follows: 1. After the satellite had been in orbit for a year, the user raised a new requirement: to upgrade the geo-precision planning algorithm to a new version in order to improve the efficiency of multi-objective scheduling.

[0086] 2. All planning algorithms are independent .py files, and are referenced using Python's import function during use.

[0087] 3. Based on the interface specifications of this invention's architecture (input: target list, orbit; output: planning task package), ground-based researchers independently developed a new GDCAL_v2 algorithm module and conducted thorough testing on the ground.

[0088] 4. The ground system uploads the software incremental package containing the new GDCAL_v2 module to the satellite via the RS422 reconfiguration channel. The mission planning board's software reconfiguration mechanism is responsible for safely updating the application layer program image in the SSD.

[0089] 5. After the satellite restarts, the system initialization process remains unchanged. When performing Earth imaging missions, the event triggering process is the same as above. The difference is that after the target planning thread is awakened, it loads and calls the new GDCAL_v2 algorithm module. Since the input / output interfaces of this module are completely consistent with the old version, the thread scheduling framework, message communication mechanism, and all other modules require no modification, and the system seamlessly uses the upgraded algorithm.

[0090] This process fully demonstrates the great convenience and security of the architecture of this invention in supporting on-orbit software upgrades and algorithm iterations.

[0091] The following example illustrates the application of the multi-threaded on-orbit autonomous mission planning system and method proposed in this invention in reliability scenarios.

[0092] Suppose that during high-precision extrapolation, the target planning thread encounters a strong single-event effect, causing an array out-of-bounds access exception in a certain calculation function. In a traditional architecture, this exception could lead to the entire thread crashing or deadlocking, thus blocking the entire planning process. In the architecture of this invention: 1. This exception will cause the current target planning thread instance to fail. However, since it is an event-driven, one-time execution, the thread's lifecycle will naturally end after the failure.

[0093] 2. The exception is caught by the operating system and the error log is recorded in a specific area of ​​shared memory.

[0094] 3. When the observation initiating thread checks the planning results queue in the next cycle, it finds that the expected task package has not been generated (because the planning thread failed). According to the preset strategy, it can send an asynchronous alarm packet indicating planning calculation failure to the ground through the telemetry thread.

[0095] 4. Most importantly, the telemetry and remote control threads and the observation initiation thread, being periodic threads, remain completely unaffected, continuing to operate stably with a 1-second cycle, maintaining basic communication and monitoring functions with the satellite crew. The system achieves "functional degradation" rather than "overall collapse."

[0096] 5. Upon receiving an alarm, the ground can send commands to restore the system from the persistent "snapshot" or re-trigger the planning process. This significantly enhances system robustness.

[0097] The multi-threaded on-orbit autonomous mission planning system and method proposed in this invention, through an innovative "three-layer, two-drive" architecture, not only provides an efficient and real-time on-orbit planning solution, but more importantly, it offers an advanced design paradigm suitable for highly reliable aerospace software systems requiring long-term on-orbit maintenance and upgrades. It deeply integrates the modular and decoupling concepts of software engineering with the high reliability requirements of aerospace, effectively solving the industry challenge of simultaneously achieving real-time performance, portability, and reliability. This is of great significance for promoting the intelligent and autonomous development of satellites.

[0098] In one embodiment of the present invention, an electronic device is also provided, comprising a processor, a graphics card, and a memory. The memory is configured to store machine-readable instructions, the graphics card is configured to train the multi-threaded satellite on-orbit autonomous mission planning method, and the processor is configured to execute the machine-readable instructions. When the processor and / or graphics card executes the machine-readable instructions, the following processing steps are implemented: system initialization and state hot recovery; creation and scheduling of differentiated threads, creating all functional threads according to a configuration table and applying different scheduling strategies; event-driven dynamic mission planning closed loop; configurable system maintenance, supporting the triggering of a save-the-state operation via ground commands to persist all current critical data again, forming a new system snapshot.

[0099] The graphics card used can preferably be a model with a GPU computing power higher than 5.0. Since the amount of data to be trained is large, providing a graphics card configuration can significantly improve the training speed.

[0100] The memory includes various media capable of storing machine-readable instructions, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0101] It is understood that, in addition to the memory and processor mentioned above, the computer system described above also includes other hardware and software components not listed in this specification. The specific components can be determined according to the model of the specific data processing equipment in different application scenarios, and will not be listed and described in detail in this specification.

[0102] In one embodiment of the present invention, a computer-readable storage medium is also provided, on which machine-readable instructions are stored. When executed by a processor, the machine-readable instructions perform the following processing steps: system initialization and hot recovery of state; creation and scheduling of differentiated threads, creating all functional threads according to a configuration table and applying different scheduling strategies; event-driven dynamic task planning closed loop; configurable system maintenance, supporting the triggering of saving the current state operation through ground commands, persisting all current key data again, and forming a new system snapshot.

[0103] Although various embodiments of the present invention have been described above, it should be understood that they are presented by way of example only and not as limitations. It will be apparent to those skilled in the art that various combinations, modifications, and alterations can be made without departing from the spirit and scope of the invention. Therefore, the breadth and scope of the invention disclosed herein should not be limited by the exemplary embodiments disclosed above, but should be defined according to the technical solutions of the invention and their equivalents.

Claims

1. A multi-threaded on-orbit autonomous mission planning system for satellites, characterized in that, include: A support layer, comprising multiple system service encapsulation modules, is configured for hardware access encapsulation and operating system service adaptation. The data interaction layer includes a shared memory area and an asynchronous message queue; as well as The application layer includes multiple functional modules, specifically: module loading and thread management module, telemetry and remote control module, task prediction module, target planning module, and observation initiation module; The system uses a multi-threaded scheduling mechanism that combines event-driven and period-driven approaches. The event-driven and period-driven multi-threaded scheduling mechanism includes: using differentiated thread driving and execution strategies for different modules based on task characteristics, specifically including: The cycle-driven thread uses a short-cycle creation and destruction strategy. Applicable modules include telemetry and remote control modules and observation initiation modules. The short-cycle creation and destruction strategy includes: triggering a system timer to dynamically create a new thread instance to execute the module's work for the current cycle; the thread instance terminates itself after completing its deterministic workflow. Event-driven threads employ a long-term sleep and event-driven wake-up strategy, applicable to modules including task forecasting and goal planning. The long-term sleep and event-driven wake-up strategy includes: the thread actively sleeps after creation, blocking on its dedicated asynchronous message queue; when an external event occurs, other modules or timers send a corresponding wake-up message to the asynchronous message queue; the operating system then schedules the thread to execute; the thread retrieves a message from the queue and executes the complete calculation process; after the thread finishes, it returns to the sleep state.

2. The multi-threaded on-orbit autonomous mission planning system for satellites according to claim 1, characterized in that, The support layer includes a hardware access encapsulation module and an operating system service adaptation module. The hardware access encapsulation module is configured to encapsulate driver calls to the CAN controller, RS422 serial port, and GPIO into a unified Python API interface. The operating system service adaptation module is configured to perform secondary encapsulation of the native multithreading, timer, inter-process communication, and file system services provided by Linux.

3. The multi-threaded on-orbit autonomous mission planning system for satellites according to claim 1, characterized in that, The shared memory area is used to store status data, including satellite orbit parameters, mission mode identifiers, and system health status; and The asynchronous message queue is used for the transmission of events and instructions between modules. Functional modules that need to receive events have independent input message queues. The asynchronous message queue is configured as a circular buffer with overflow protection.

4. The multi-threaded on-orbit autonomous mission planning system for satellites according to claim 1, characterized in that, The module loading and thread management module is configured for system initialization, recovery of critical data sets, and dynamic creation and management of the lifecycle and scheduling strategies of all threads. The telemetry and remote control module is configured to integrate telemetry acquisition and transmission with remote control command reception and parsing; The mission prediction module is configured for rapid visibility prediction and coarse screening of targets for air or ground observation. The target planning module includes an attitude calculation and fine planning sub-module, which is configured for precise orbit extrapolation, attitude guidance law calculation, load parameter generation, and final task sequence optimization. as well as The observation initiation module is configured to monitor and issue generated task instruction packages according to timing requirements.

5. The multi-threaded on-orbit autonomous mission planning system for satellites according to claim 4, characterized in that, The key data set includes orbital parameters, mission configuration, and target library index; the key data set is serialized and stored in a designated area of ​​non-volatile memory triggered by ground commands or specific events; the key data set is automatically restored from the non-volatile memory each time the system starts.

6. The multi-threaded on-orbit autonomous mission planning system for satellites according to claim 1, characterized in that, The system is deployed on the mission planning board of the satellite platform and interacts with the satellite management unit of the integrated electronic system through a communication bus and asynchronous serial port.

7. A multi-threaded satellite on-orbit autonomous mission planning method, using the multi-threaded satellite on-orbit autonomous mission planning system according to any one of claims 1 to 6, characterized in that, The steps include the following: System initialization and hot recovery; The creation and scheduling of differentiated threads are initiated by creating all functional threads according to the configuration table and applying different scheduling strategies: creating telemetry and remote control threads and observation initiation threads, binding timers to them, and starting the creation and destruction cycle; creating task forecasting threads and target planning threads, which then sleep after creation, waiting for the wake-up event of their respective message queues; The event-driven dynamic task planning closed loop includes the trigger prediction sub-step, the trigger fine planning and attitude calculation sub-step, and the monitoring and distribution sub-step; as well as Configurable system maintenance supports triggering on-site saving operations via ground commands, which will persist all current critical data and create a new system snapshot.

8. The multi-threaded on-orbit autonomous mission planning method for satellites according to claim 7, characterized in that, The triggering prediction sub-step includes: the telemetry and remote control module parses the uploading end command and sends an MSG_NEW_TARGET event to the mission prediction thread message queue; the mission prediction thread is awakened, performs orbit extrapolation and visibility analysis, writes the results into the unplanned set in shared memory, and replies to the satellite service via the CAN bus with a feedback packet including the next power-on time; The triggering of the fine planning and attitude calculation sub-steps includes: using an independent monitoring thread or a timer based on system time to compare the intersection times of targets in the planning set in real time; when the difference reaches a preset threshold, sending an MSG_PLANNING_TRIGGER event to the target planning thread queue; the target planning thread is awakened, generates the final task sequence, and stores it in the planning result queue; and The monitoring and distribution sub-steps include: the periodically running observation initiation thread checks the planning result queue in each execution cycle, and when the preset execution time of the task package is close, the task package is sent to the satellite service module via the CAN bus.

9. An electronic device, characterized in that, include: A processor, configured to execute machine-readable instructions; A graphics card configured to train a multi-threaded satellite on-orbit autonomous mission planning method as described in any one of claims 7 to 8; as well as A memory configured to store machine-readable instructions that, when executed by a processor and / or graphics card, perform the steps of the multi-threaded satellite on-orbit autonomous mission planning method according to any one of claims 7 to 8.

10. A computer-readable storage medium storing computer-readable instructions thereon, characterized in that, When the computer-readable instructions are executed by a processor, they perform the steps of the multi-threaded satellite on-orbit autonomous mission planning method according to any one of claims 7 to 8.

Images