A spaceborne algorithm management deployment system

Abstract

This application provides a spaceborne algorithm management and deployment system, comprising: a ground subsystem configured to: encapsulate the algorithm application and its runtime environment into an algorithm container, and package the algorithm container and corresponding deployment script to generate a versioned uploading data packet; send the uploading data packet via a space-to-ground wireless link; and a spaceborne processing unit configured to: receive the uploading data packet via a space-to-ground wireless link; create an independent directory structure in the spaceborne storage medium; execute the deployment script, deploy the files in the algorithm container to the independent directory structure, and configure the runtime environment; in response to task instructions from the ground subsystem, schedule the deployed algorithm to perform data processing on the spaceborne graphics processor; and write the status parameters generated during algorithm uploading, deployment, and operation into the spaceborne shared memory area, and transmit them to the ground subsystem via a telemetry link, forming a space-to-ground closed-loop status monitoring. This application improves the satellite's processing efficiency and resource utilization.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a spaceborne algorithm management and deployment system. Background Technology

[0002] Currently, Earth observation satellites are evolving towards real-time intelligent on-orbit processing, but traditional technical architectures severely restrict this process. Existing satellites typically employ a fixed-function design, with onboard algorithms embedded in the hardware before launch, making it impossible to update algorithms or reconfigure functions while the satellite is in orbit. Ground systems can only trigger preset tasks or receive data, lacking dynamic intervention methods to control onboard processing capabilities.

[0003] This static paradigm raises the following key questions: First, as mission complexity increases, a single satellite needs to support algorithms from diverse sources and with varying functions. Traditional architectures lack a unified framework for managing the entire lifecycle of algorithms, making it impossible to support independent uploading, isolated deployment, collaborative scheduling, and unified monitoring of different algorithms, thus hindering reliable management and resource coordination across multiple missions.

[0004] Secondly, the efficiency of multi-algorithm collaborative processing is constrained by the "memory wall" bottleneck. In traditional solutions, intermediate data needs to be read and written multiple times through the storage medium during serial processing of multiple algorithms, introducing significant I / O latency and making it difficult to meet real-time processing requirements.

[0005] Furthermore, the operational status of onboard algorithms is opaque. Ground personnel lack effective means to monitor whether the algorithm deployment was successful or whether its execution was abnormal, and fault location relies on ground speculation, resulting in poor maintainability.

[0006] Furthermore, the utilization rate of computing resources is low. The resources of the onboard processing unit are monopolized by a single task, making it impossible to flexibly schedule and reuse them among different algorithms, which restricts the overall application benefits of the satellite. Summary of the Invention

[0007] In view of this, the purpose of this application is to provide a spaceborne algorithm management and deployment system to overcome at least one of the above-mentioned defects.

[0008] In a first aspect, embodiments of this application provide a spaceborne algorithm management and deployment system. The system includes a ground subsystem and a spaceborne processing unit. The ground subsystem is configured to: encapsulate the algorithm application and its runtime environment into an algorithm container according to a preset standardized container format, and package the algorithm container and the corresponding deployment script to generate a versioned uploading data packet; and send the uploading data packet via a space-to-ground wireless link. The spaceborne processing unit is configured to: receive the uploading data packet via the space-to-ground wireless link; create an independent directory structure corresponding to the algorithm container and isolated from each other in the spaceborne storage medium to form an isolated runtime environment; execute the deployment script to deploy the files in the algorithm container to the independent directory structure and configure the runtime environment; in response to task instructions from the ground subsystem, schedule the deployed algorithm to perform data processing on the spaceborne graphics processor; and write the status parameters generated during algorithm uploading, deployment, and operation into the spaceborne shared memory area and transmit them to the ground subsystem via a telemetry link to form a space-to-ground closed-loop status monitoring.

[0009] In one optional embodiment of this application, the preset standardized container format specifies that each algorithm container includes at least the following directories: an application subdirectory for storing algorithm executable files, a configuration subdirectory for storing configuration files, a library subdirectory for storing dependency library files, a data subdirectory for storing input and output data, and a model subdirectory for storing pre-trained model files.

[0010] In one optional embodiment of this application, the onboard processing unit is further configured to: write the deployment success or failure status parameters into the onboard shared memory area after completing the execution of the deployment script of the algorithm container; the system further includes an onboard integrated electronic unit, configured to: read the status parameters from the onboard shared memory area and transmit them to the ground subsystem through the telemetry link.

[0011] In one optional embodiment of this application, the onboard processing unit is further configured to: pre-allocate a shared data area in the memory of the onboard graphics processor when multiple deployed algorithms need to be processed in sequence; and control the predecessor algorithm to write the processed output data into the shared data area through a thread synchronization mechanism, and trigger the subsequent algorithm thread to read the output data from the shared data area as its input.

[0012] In one optional embodiment of this application, the onboard processing unit is further configured to: monitor the memory and computing resource usage of the onboard graphics processor; and dynamically select one of the following scheduling modes—single algorithm execution, multi-algorithm parallel execution, or multi-algorithm serial execution—based on the monitoring results and task instructions.

[0013] In one optional embodiment of this application, the onboard processing unit is further configured to: package the final result data generated after the algorithm processing is completed in the onboard storage medium, and transmit it to the ground subsystem via the space-to-ground data link.

[0014] In one optional embodiment of this application, the onboard processing unit is further configured to: maintain an independent log directory for each deployed algorithm in the onboard storage medium, and store the running logs generated during the algorithm execution in the corresponding log directory, wherein the running logs can be downlinked via a satellite-to-ground link for ground analysis.

[0015] In one alternative embodiment of this application, the onboard processing unit is configured to support the independent uploading, deployment, and maintenance of multiple algorithm containers, and to maintain an isolated independent directory structure for each algorithm container in the onboard storage medium.

[0016] In one optional embodiment of this application, the onboard processing unit includes a unified instruction parser and scheduler, configured to perform unified instruction parsing and task scheduling management on multiple deployed algorithm containers.

[0017] In one optional embodiment of this application, the onboard processing unit includes a main management module and a graphics processing module; the main management module is configured to receive the uploading data packet, create a directory structure, execute deployment scripts, parse and schedule task instructions, and summarize status parameters; the graphics processing module is configured to provide the onboard graphics processor memory and be scheduled by the main management module to execute data processing algorithms.

[0018] The spaceborne algorithm management and deployment system provided in this application includes: a ground subsystem configured to: encapsulate algorithm applications and their operating environments into algorithm containers, and package the algorithm containers and corresponding deployment scripts to generate versioned uploading data packets; send the uploading data packets via a space-to-ground wireless link; and a spaceborne processing unit configured to: receive the uploading data packets via a space-to-ground wireless link; create an independent directory structure in the spaceborne storage medium; execute the deployment script, deploy the files in the algorithm containers to the independent directory structure, and configure the operating environment; respond to task instructions from the ground subsystem, schedule the deployed algorithms to perform data processing on the spaceborne graphics processor; and write the status parameters generated during algorithm uploading, deployment, and operation into the spaceborne shared memory area, and transmit them to the ground subsystem via a telemetry link, forming a space-to-ground closed-loop status monitoring. This application upgrades traditional satellites from functionally fixed dedicated hardware to an open on-orbit intelligent computing platform that supports multiple algorithm ecosystems, allows for software-defined functions, flexible service expansion, and real-time status observation, thereby improving the satellite's mission adaptability, processing timeliness, system reliability, and resource utilization.

[0019] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of the structure of the spaceborne algorithm management and deployment system provided in the embodiments of this application; Figure 2 A flowchart of the ground subsystem provided in the embodiments of this application; Figure 3 This is one of the flowcharts for the onboard processing unit provided in the embodiments of this application; Figure 4 This is a second flowchart of the onboard processing unit provided in the embodiments of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0023] First, the applicable scenarios for this application will be introduced. This application can be applied to the field of data processing technology.

[0024] Research has revealed that existing Earth observation satellites typically employ a fixed-function design, with onboard algorithms burned into the hardware before launch, making on-orbit updates or reconstruction impossible. This static processing paradigm severely hinders the satellite's evolution towards real-time on-orbit intelligence. This static paradigm leads to multiple technical drawbacks: First, the lack of a unified algorithm lifecycle management framework makes it impossible to support independent uploading, isolated deployment, and collaborative scheduling of multi-source algorithms, failing to meet the reliable management requirements of multiple tasks. Second, multi-algorithm collaborative processing is constrained by the "memory wall" bottleneck, requiring intermediate data to be read and written multiple times through storage media, introducing significant I / O latency. Third, the operational status of onboard algorithms is opaque, making it impossible for the ground to effectively monitor whether deployment was successful or whether execution was abnormal; faults rely on ground-based speculation, resulting in poor maintainability. Fourth, computational resource utilization is low, with processing resources monopolized by a single task, preventing flexible scheduling and reuse among different algorithms.

[0025] To address the issues of fixed, limited, or unsuitable functions in traditional satellite missions, this application aims to transform satellites into dynamically configurable algorithm service platforms. By injecting different algorithm containers on the ground, on-orbit flexible reconfiguration of satellite service functions can be achieved, thereby improving the applicability of the satellite system.

[0026] Based on this, this application provides a spaceborne algorithm management and deployment system, aiming to overcome the shortcomings of existing technologies such as fixed satellite functions, low algorithm collaboration efficiency, opaque status, and low resource utilization. By designing a management and deployment system that supports containerized encapsulation of algorithms, satellite-to-ground wireless transmission, automated onboard deployment and configuration, and closed-loop status feedback, this application achieves dynamic reconfiguration of satellite on-orbit processing capabilities, efficient collaborative computing among multiple algorithms, real-time visibility and controllability of operational status, and reuse of onboard computing resources. This application supports independent uploading, isolated deployment, and flexible combination of multiple different algorithms, realizing on-demand expansion and on-orbit reconfiguration of satellite service functions.

[0027] The system provided in this application serves as an open spaceborne algorithm platform. Its core strength lies in supporting the independent uploading, isolated deployment, and unified management of multiple different algorithms. Any algorithm conforming to a pre-defined standardized container format, regardless of its origin (e.g., algorithms from different vendors, such as Company A and Company B) or functional type, can be deployed in orbit through a unified process. Furthermore, the system supports flexible combination and on-demand scheduling of deployed algorithms based on business needs: for example, in one mission scenario, algorithms 1, 2, and 3 can be scheduled for sequential collaborative processing; in another mission scenario, algorithms 4 and 5 can be executed independently, or only algorithms 1 and 3 can be combined to complete a specific function. This mechanism enables the satellite to quickly adapt to diverse Earth observation missions, achieving flexible expansion and on-orbit reconfiguration of business functions.

[0028] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of the spaceborne algorithm management and deployment system provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 The spaceborne algorithm management and deployment system 10 includes a ground subsystem 11 deployed at a ground control center and a spaceborne processing unit 12 deployed on a satellite platform. The system also involves an integrated data transmission and control unit for space-to-ground data transmission, a ZU19EG module for data forwarding, and a comprehensive electronic module for managing remote control and telemetry.

[0029] Ground subsystem 11 encapsulates the algorithm application and its operating environment into an algorithm container with a specific directory structure according to a predefined standardized container format; then, it writes an automated deployment script and packages it with the algorithm container to generate a numbered uploading data packet; finally, it sends the data packet and related uploading instructions to the satellite through the satellite-to-ground wireless link built by the data transmission and telemetry control integrated machine.

[0030] The onboard processing unit 12 receives data packets uploaded by the ground subsystem 11 via the satellite-to-ground wireless link and the ZU19EG module. After parsing, it creates an independent directory structure corresponding to the algorithm container in the onboard storage medium, which is isolated from each other. Then, it executes the deployment script in the data packet, deploys the files in the algorithm container to the directory and completes the environment configuration. After the configuration is completed, it calls the status writing program to write the deployment result status to the onboard shared memory area. When it receives a task execution instruction from the ground, it schedules the deployed algorithm to be executed in the graphics processor memory. The real-time status parameters during the algorithm execution process are continuously written to the shared memory area and transmitted to the ground by the integrated electronic module through the telemetry link, thereby realizing closed-loop status monitoring of the entire process.

[0031] The correspondence and functions of the components in the system architecture are as follows: Ground subsystem 11 is responsible for encapsulating algorithm packages, sending uplink commands, and receiving and processing downlink data.

[0032] The wireless link / telemetry and control system is responsible for establishing and maintaining the satellite-to-ground wireless link to achieve two-way data transmission between space and ground (command uplink and data downlink).

[0033] The ZU19EG module is responsible for receiving OTA upload packets from the data transmission link and the actual payload data from the camera, thus serving as the data input.

[0034] The integrated electronic module is responsible for the basic functions of telemetry, remote control and power management of the entire satellite, and provides necessary bus support and interfaces for various processing modules on the satellite.

[0035] The GPU module, or onboard processing unit, is responsible for receiving, unpacking, deploying, scheduling, and executing algorithms, ultimately completing on-orbit data processing.

[0036] In summary, this system constitutes a complete space-ground collaborative processing link: the ground system packages the algorithm container and uploads it via the data transmission and telemetry control integrated machine; the onboard system receives and forwards data through the ZU19EG module; the integrated electronic module ensures the interactive operation of communication between the ground system and various devices; and finally, the GPU module completes the dynamic deployment, scheduling and execution of the algorithm, realizing the construction of data flow function and laying the foundation for the solidification of satellite functions into software definition.

[0037] Please see Figure 2 , Figure 2 A flowchart illustrating the ground subsystem provided in an embodiment of this application. Figure 2 As shown in the illustration, the ground subsystem provided in this application embodiment is configured as follows: S101. Based on the preset standardized container format, the algorithm application and its running environment are encapsulated into an algorithm container, and the algorithm container and the corresponding deployment script are packaged to generate a versioned uploading data package.

[0038] The ground subsystem encapsulates the debugged algorithm project according to a predefined, standardized container format. Specifically, the system places the algorithm's executable file in a designated application subdirectory (e.g., APP), the configuration file (e.g., AI_config.json) in a configuration subdirectory (config), the required dependency library files in a library subdirectory (lib), the pre-trained model file (e.g., engine format) in a model subdirectory (model), and creates a data subdirectory (data) and a log subdirectory (log), together forming a complete, self-contained algorithm container (e.g., named AI_DIR). Subsequently, the ground subsystem compresses and packages the pre-written automated deployment script (e.g., AI_OTA_config.sh), the algorithm container, and an independent state writing program (e.g., OTAwriteShm) into an upload data package with a unique number (e.g., GPU_000_AI_APP.zip). This data package is the smallest deployment unit that can be transmitted to the satellite.

[0039] The preset container format specifies that the algorithm container should include at least the following directories: an application subdirectory for storing algorithm executable files, a configuration subdirectory for storing configuration files, a library subdirectory for storing dependency library files, a data subdirectory for storing input and output data, and a model subdirectory for storing pre-trained model files.

[0040] The application subdirectory is dedicated to storing executable algorithm program files, serving as the core carrier of algorithm functionality. The configuration subdirectory stores configuration and parameter files required for algorithm execution, defining its specific behavior. The library subdirectory centrally manages all software library files upon which the algorithm depends, ensuring the integrity of the runtime environment. The data subdirectory serves as the data workspace in the algorithm processing flow, categorizing and storing raw input data, intermediate data generated during processing, and final result data. The model subdirectory is specifically used to store pre-trained model files (such as neural network weight files) upon which the algorithm depends. This mandatory directory structure design provides a clear and unified interface specification for ground-based encapsulation and on-board automated deployment scripts.

[0041] The ground subsystem encapsulates the algorithm executable file, dependency library, and configuration file into an algorithm container according to a preset container format, and packages the algorithm container and deployment script to generate an uploading data package.

[0042] In this embodiment, a standardized algorithm container structure (e.g., named AI_DIR) is defined by a preset container format, serving as the core carrier of the algorithm and its complete runtime environment. This container contains at least the following core directories: APP directory (application subdirectory): used to store executable modules of algorithm applications (such as AI000, AI001).

[0043] The config directory (configuration subdirectory) is used to store the algorithm's configuration files (such as AI_config.json).

[0044] The data directory (data subdirectory) is used to categorize and store the raw data (AI_raw_data) required for algorithm processing, the intermediate data generated during processing (AI_interim_data), and the final result data (AI_result_data).

[0045] The lib directory (library subdirectory) is used to store the environment library files that the algorithm depends on.

[0046] The log directory (log subdirectory) is used to store logs generated during the algorithm's execution, organized by algorithm number.

[0047] The model directory (model subdirectory) is used to store pre-trained model files (such as engine format models) required by the algorithm.

[0048] OTA directory (betting management subdirectory): used for version management of betting packages.

[0049] The script directory (script subdirectory) is used to store scripts for automated deployment, configuration, etc. Subsequently, the ground subsystem packages the encapsulated algorithm container together with the written automated deployment script (such as AI_OTA_config.sh) and the state writing program to generate the final uploading data package (such as GPU_000_AI_APP.zip).

[0050] Furthermore, the ground subsystem encapsulates the algorithm executable file, dependency libraries, and configuration files into an algorithm container according to a preset container format, and packages the algorithm container and deployment script to generate an uploading data package.

[0051] The deployment script (e.g., named AI_OTA_config.sh) is an automated execution program whose main functions include: 1) File deployment: Deploy all files in the algorithm container (including algorithm applications, model files, dependency libraries, configuration files, etc.) to the specified directory location of the on-board processing unit.

[0052] 2) Environment configuration: Automatically complete the environment configuration required for algorithm operation, such as installing necessary dependency libraries and setting file access permissions, to ensure that the algorithm can be executed smoothly on the satellite and to prepare for subsequent status monitoring and result feedback.

[0053] Subsequently, the ground subsystem packages this deployment script together with the algorithm container and the state writer to form the final uploading data package.

[0054] In step S101, the ground subsystem encapsulates the algorithm executable file, dependency library and configuration file into an algorithm container (AI_DIR) according to the preset container format, and packages the algorithm container and deployment script to generate an uploading data package.

[0055] Specifically, the ground subsystem compresses and packages the encapsulated algorithm container (AI_DIR), the written automated deployment script (such as AI_OTA_config.sh), and the independent state writing program (such as OTAwriteShm) together to form the final transportable uploading package. This uploading package adopts a unified naming convention; for example, GPU_000_AI_APP.zip represents the 0th algorithm, GPU_001_AI_APP.zip represents the 1st algorithm, and so on. This uploading package is the smallest functional unit supporting on-orbit deployment, and the numbering in its name facilitates version control of the algorithms.

[0056] S102, Send up data packets via satellite-to-ground wireless link.

[0057] In this step, the ground subsystem sends the uplink data packet via the satellite-to-ground wireless link. Specifically, the ground subsystem sends the generated uplink data packet, along with the corresponding uplink control commands (such as algorithm uplink commands), to the data transmission and control integrated unit. The data transmission and control integrated unit modulates and transmits the data packet uplink to the on-orbit satellite via a wireless channel, thereby initiating the on-board deployment process.

[0058] After the ground system sends the uploading command and uploading data packet, the onboard processing unit performs the uploading packet reception and deployment operations.

[0059] The betting process begins with the ground preparation phase (algorithm packaging, configuration script writing, and betting package creation). Subsequently, the ground system sends an OTA betting command. Upon receiving the OTA betting package, the onboard GPU of the spacecraft launches and executes the deployment script within the betting package via the GPU application. After the deployment script completes execution, the system checks the betting success flag in shared memory. If the flag is "yes," it indicates successful betting deployment, and the process ends; if it is "no," it means an error occurred during deployment, and the process terminates or requires exception handling.

[0060] In the embodiments of this application, the onboard processing unit is configured to perform the following deployment steps: First, it receives the uploading data packet sent from the ground via the satellite-to-ground wireless link (corresponding to "the GPU onboard end receives the OTA uploading packet").

[0061] Next, the algorithm number in the uploading package is parsed (e.g., "000" is parsed from the filename GPU_000_AI_APP.zip), the data package is automatically decompressed, and the deployment script within the package (such as AI_OTA_config.sh) is executed, thereby completing the automatic installation and configuration of the algorithm in the spaceborne environment (corresponding to "GPU application startup uploading script execution" and subsequent success determination). Through this process, the remote and automated deployment of the algorithm from the ground to the on-orbit environment is realized.

[0062] Please see here. Figure 3 , Figure 3 This is one of the flowcharts for the onboard processing unit provided in the embodiments of this application. For example... Figure 3 As shown in the embodiments of this application, the onboard processing unit is configured as follows: S201, Receives uploading data packets via satellite-to-ground wireless link.

[0063] The onboard processing unit receives uplink data packets via a satellite-to-ground wireless link. Specifically, the satellite's data transmission and telemetry control unit receives and demodulates the wireless signals, then delivers the data packets to the onboard processing unit via the intra-satellite bus (e.g., via the ZU19EG module), providing the raw data source for subsequent algorithm deployment.

[0064] S202. Create an isolated directory structure in the onboard storage medium that corresponds to the algorithm container, so as to form an isolated operating environment.

[0065] The onboard processing unit parses the received uploading data packets, obtains information such as the algorithm number, and then creates an isolated directory structure corresponding to the algorithm container in the onboard storage medium (such as a solid-state drive). This directory structure is dedicated to the algorithm, providing physically isolated storage space for subsequent file deployment and ensuring that the operating environments of different algorithms do not interfere with each other.

[0066] S203. Execute the deployment script to deploy the files in the algorithm container to an independent directory structure and configure the runtime environment.

[0067] The onboard processing unit automatically decompresses the uploading data packet and executes the deployment script (AI_OTA_config.sh) within the packet.

[0068] It's important to note that each algorithm container carries its own independent deployment script, the content of which is pre-customized according to the algorithm's own operational requirements. For example, when executing the deployment script for Algorithm 1, the script will create a dedicated independent directory structure for Algorithm 1 in the onboard storage medium based on Algorithm 1's preset configuration, and only install the dependency libraries, model files, and configuration files required by Algorithm 1. Similarly, when executing the deployment script for Algorithm 2, it will create a dedicated directory structure for Algorithm 2 and deploy its runtime environment as needed. In other words, each algorithm's deployment script is "installed and created on demand," independent of each other and without interference, thus achieving physical isolation of the runtime environments of multiple algorithms.

[0069] The script automatically copies or moves all files (including applications, models, libraries, configurations, etc.) within the algorithm container (AI_DIR) to the isolated directory created in step S202, and automatically performs a series of environment configuration operations, such as installing necessary dependent libraries, setting file execution permissions, and configuring environment variables, thereby completing the automated installation of the algorithm and preparation of the runtime environment on the satellite.

[0070] The onboard processing unit automatically decompresses the uploading data package and executes the deployment script (such as AI_OTA_config.sh) within the package to deploy the files in the algorithm container to an isolated directory structure and complete the runtime environment configuration.

[0071] As a crucial closed-loop step in the deployment process, after the deployment script completes execution, an independent status writing program (e.g., OTAwriteShm) is automatically invoked. This program writes the configuration result (success or failure) of the algorithm container into a pre-allocated specific location in the onboard shared memory area as a clear status identifier. Subsequently, the main management program in the onboard processing unit reads this status identifier and transmits it to the ground subsystem via the space-to-ground link. This mechanism achieves real-time closed-loop monitoring from onboard execution to ground feedback, ensuring the controllability of the uploading and deployment process.

[0072] Multiple algorithms can be independently packaged, uploaded, and deployed according to the aforementioned steps S101 to S203. After each algorithm is successfully uploaded, it forms its own independent isolated environment in the onboard storage medium. Finally, a unified and standardized multi-algorithm container directory structure will be established and maintained on the onboard processing unit to achieve parallel management of algorithms and environment isolation.

[0073] In one embodiment of the unified directory structure of this application, the root directory AI_DIR is a standardized container structure containing dedicated subdirectories for storing executable applications (APP), configuration files (config), input / output data (data), dependency libraries (lib), runtime logs (log), model files (model), OTA (Application Overlay) content, and deployment scripts (script). Specifically, the OTA directory stores the file packages obtained by independently overlaying and decompressing each algorithm (e.g., AI000, AI001, AI002). Through this design, each algorithm has its own dedicated subdirectory or file under the APP, log, and script directories, distinguished by the algorithm number (e.g., 000, 001, 002), thereby achieving isolation between physical storage and the runtime environment, avoiding mutual interference between algorithms, and supporting the parallel deployment and flexible management of multiple algorithms.

[0074] After the deployment script for the algorithm container is executed, the status parameters indicating whether the deployment was successful or failed are written to the onboard shared memory area.

[0075] S204, in response to mission instructions from the ground subsystem, schedules the deployed algorithms to perform data processing on the onboard graphics processor.

[0076] The onboard processing unit responds to mission execution instructions received from ground subsystems via the space-to-ground link. This unit parses the instructions and schedules the corresponding deployed algorithms according to the requirements. During scheduling, the algorithms are loaded into the memory of the onboard GPU to execute core data processing tasks. For multiple algorithms with data dependencies, zero-copy data transfer can be achieved through a pre-allocated shared memory pool in the GPU memory, and the execution order can be synchronized using mechanisms such as mutexes and condition variables.

[0077] After the algorithm is deployed, the ground subsystem can send execution commands. The onboard processing unit supports the following three execution modes: 1) Single Algorithm Execution: Ground commands directly specify and invoke the target algorithm (such as object detection, image segmentation, etc.). The algorithm executes independently on the GPU, and its results are stored in a standardized directory (such as data / AI_result_data), while the execution log is saved in the corresponding log directory (such as log / xxx).

[0078] 2) Parallel execution of multiple algorithms: When GPU computing resources are sufficient and no data interaction is required between algorithms, the onboard processing unit can start multiple threads or processes after parsing the instructions, allowing each algorithm to execute independently and concurrently, with a process similar to single-algorithm execution. If the system detects insufficient resources, it will automatically switch to serial mode.

[0079] 3) Serial execution of multiple algorithms (based on multi-threaded collaboration and zero-copy sharing of GPU memory): When there are data dependencies in the task flow (the output of the predecessor algorithm serves as the input of the subsequent algorithm), a serial execution mode is adopted. This application proposes an efficient scheduling scheme, the core flow of which takes algorithms AI000 and AI001 as an example.

[0080] Its workflow includes: Initialization phase: The main process registers signal handlers, parses command-line arguments, sets up the GPU device and CUDA environment, and pre-allocates the shared GPU memory pool. Subsequently, it initializes synchronization objects (mutex locks, condition variables, CUDA events) and status flags.

[0081] Worker thread execution phase: The main process creates and starts two worker threads, AI000 and AI001, and initially sets AI000 to be executable (a1000_ready=true). The two threads operate with symmetrical logic, waiting in a loop for their dedicated condition variables to be triggered. Upon being awakened, if the global shutdown flag is false, the core data processing task is executed. The key mechanism is that each thread directly accesses the GPU memory region corresponding to the other thread, achieving zero-copy data sharing. After the task is completed, the thread records CUDA events, updates the global state flag through a mutex lock, triggers the condition variable of the other thread to make it ready, and then enters the waiting state again.

[0082] Exit Phase: If the main process receives an exit signal during the monitoring loop, it sets `shutdown=true` and notifies all condition variables to wake up worker threads. Worker threads exit in an orderly manner after detecting the shutdown flag. Finally, the main process waits for all worker threads to finish, then releases shared GPU memory, destroys synchronization objects and CUDA events, and the process ends.

[0083] S205. Write the status parameters generated during the algorithm uploading, deployment and operation into the onboard shared memory area, and transmit them to the ground subsystem via the telemetry link to form a closed-loop status monitoring between the satellite and the ground.

[0084] In this step, throughout the entire algorithm execution process, each deployed algorithm has its own dedicated storage space in the onboard shared memory area. This space is used to update key operational status parameters (such as computation progress, health status, and exception codes) to the preset telemetry structure in real time. The onboard integrated electronic unit periodically or triggered by events reads these status parameters from this shared memory area, encapsulates them into telemetry frames, and transmits them to the ground subsystem via an independent telemetry link (such as a CAN bus). This provides the ground with closed-loop monitoring and real-time surveillance capabilities for the deployment and operational status of the onboard algorithms.

[0085] In step S205, the onboard processing unit outputs and transmits back the status parameters, detailed logs, and processing results generated during the algorithm's execution, specifically including: For real-time status monitoring, each deployed algorithm has its own dedicated storage space in the onboard shared memory area, continuously updating its operating status to the preset telemetry structure; the onboard integrated electronic unit periodically or event-triggeredly reads these status parameters through an internal bus (such as CAN) and transmits them to the ground via the telemetry link to achieve real-time monitoring of the operating status of the on-orbit algorithm.

[0086] For detailed data recording and packet transmission, in addition to real-time status, the detailed runtime logs generated by each algorithm execution (generated and stored sequentially in the corresponding algorithm subdirectories under the log directory, such as log / xxx / xxx.log), raw input data, intermediate processing data, and final result data (usually stored in the corresponding subdirectories under the data directory, such as AI_result_data) are all completely preserved in the onboard storage medium. The ground subsystem can, as needed, instruct the onboard processing unit to package the above data for a specified algorithm or time period, and then send it to the ground via the data transmission channel composed of the onboard high-speed data processing unit (such as ZU19EG) and the integrated data transmission and control unit. This mechanism supports detailed post-mission analysis and fault diagnosis of the mission execution process.

[0087] The system also includes an onboard integrated electronic unit, configured to read status parameters from the onboard shared memory area and transmit them to the ground subsystem via a telemetry link.

[0088] The specific workflow is as follows: Various status parameters written by the onboard processing unit are periodically read from the onboard shared memory area. These parameters include, but are not limited to, the deployment results (success / failure), real-time operational health status (such as progress and error codes), and resource usage. Subsequently, the onboard integrated electronic unit performs necessary formatting and packaging of these status parameters, encapsulating them into telemetry data frames conforming to the space-to-ground communication protocol. Finally, the encapsulated status data is reliably transmitted downlink to the ground subsystem via an independent telemetry link (such as a CAN bus). This mechanism ensures that ground personnel can monitor the entire lifecycle status of the onboard algorithm in near real-time, constituting a key link in achieving a knowable and controllable closed-loop feedback throughout the "deployment-operation" process, significantly enhancing the system's maintainability and mission reliability.

[0089] For further details, please refer to Figure 4 , Figure 4 This is a second flowchart of the onboard processing unit provided in an embodiment of this application. Figure 4 As shown in the embodiments of this application, the onboard processing unit is further configured as follows: S301. When multiple deployed algorithms need to be processed in sequence, a shared data area is pre-allocated in the memory of the onboard graphics processor.

[0090] When task analysis determines that multiple algorithms need to be executed serially and that there are data dependencies between the algorithms, the onboard processing unit pre-allocates a contiguous storage area in the global memory of the onboard graphics processor (GPU) as a shared memory data area. The size of this shared memory data area is dynamically calculated based on the input and output data scale of the algorithms involved or determined according to preset rules. This aims to provide a dedicated high-speed buffer for direct data interaction between algorithms, avoiding I / O latency introduced by multiple reads and writes of intermediate results through the onboard storage medium.

[0091] S302. Through the thread synchronization mechanism, the predecessor algorithm is controlled to write the processed output data into the shared data area, and the subsequent algorithm thread is triggered to read the output data from the shared data area as its input.

[0092] When scheduling and executing these algorithms, the onboard processing unit controls the execution flow, ensuring that after the current algorithm (e.g., AI000) completes its data processing, it directly writes the output to a designated area of ​​the shared memory pool. Immediately afterwards, the subsequent algorithm (e.g., AI001) is scheduled to start, and it is controlled to bypass traditional onboard storage media (such as hard drives) and directly read the output data of the predecessor algorithm from the same designated area of ​​the shared memory pool, using this as its own input data to begin computation. This process achieves "zero-copy" data transfer between algorithms, improving the efficiency of multi-algorithm collaborative processing.

[0093] Specifically, the access of each algorithm to the shared memory pool is synchronized through a mutex lock and condition variable mechanism.

[0094] Specifically, to ensure safe and orderly access to the shared memory pool by multiple algorithm threads and avoid data races or read / write conflicts, the onboard processing unit uses mutexes and condition variables to synchronize the execution of each algorithm. Specifically, mutexes protect access permissions to critical data areas in the shared memory pool, ensuring that only one algorithm thread performs write operations at a time. Simultaneously, condition variables are used to precisely control the execution order of algorithms. For example, subsequent algorithm threads are made to wait for the preceding algorithm thread to send a "data ready" signal before being awakened and executed. This achieves lock-step coordination between algorithms, improving the efficiency of the data processing chain while ensuring the stability and correctness of the system.

[0095] The onboard processing unit is also configured as follows: Monitor the memory usage of the onboard graphics processor; based on the monitoring results and task instructions, dynamically select one of the following scheduling modes for scheduling: single-algorithm execution, multi-algorithm parallel execution, or multi-algorithm serial execution.

[0096] Specifically, this unit continuously monitors the real-time memory usage of the onboard graphics processor to quantitatively assess the currently available computing resources. Simultaneously, in conjunction with mission instructions received from the ground subsystem (which contain information such as the identifier, quantity, execution parameters, and mission type of the algorithms to be executed), the onboard processing unit makes a comprehensive decision: based on the resource monitoring results and the parsed content of the mission instructions, it dynamically selects whether to schedule multiple algorithms into parallel or serial execution modes.

[0097] For example, when sufficient available memory is detected and there are no data dependencies between the multiple algorithms indicated by the task instructions, a parallel mode is selected to improve throughput; conversely, if resources are scarce or there are data dependencies between algorithms, a serial mode is automatically selected to ensure the smooth execution of the task chain. This dynamic scheduling mechanism enables adaptive management of onboard computing resources, optimizing the overall system efficiency and resource utilization while meeting task requirements.

[0098] The onboard processing unit is also configured as follows: The final result data generated after the algorithm is processed is packaged in the onboard storage medium and transmitted to the ground subsystem via the space-to-ground data link.

[0099] Specifically, after the deployed algorithm completes data processing according to mission instructions, the onboard processing unit collects and organizes the final result data generated by the algorithm (such as target detection location information, classification results, etc.) in a designated directory on the onboard storage medium (such as the data / AI_result_data subdirectory of the corresponding algorithm container). Subsequently, the unit compresses and packages the specified result data files according to ground instructions or preset rules to form data packets that meet the downlink transmission format requirements. Finally, the data is transmitted via a dedicated space-to-ground data link (distinct from the telemetry link for transmitting status parameters, which typically has higher bandwidth).

[0100] For example, after being modulated by the integrated data transmission and control unit, the packaged result data packets are transmitted downlink to the ground subsystem for further analysis, application, or distribution. This mechanism ensures the reliable and orderly recovery of effective information products from space to ground, completing a full business loop from mission uplink to result downlink.

[0101] The onboard processing unit is also configured as follows: Each deployed algorithm maintains an independent log directory in the onboard storage medium, and the running logs generated during the algorithm execution are stored in the corresponding log directory.

[0102] Here, the operation logs can be downlinked via satellite-to-ground links for ground analysis.

[0103] Specifically, to ensure the maintainability and post-analysis capabilities of the system, the unit creates and maintains an independent log directory (e.g., located in the log subdirectory of the corresponding algorithm container structure) in the onboard storage medium for each successfully deployed algorithm.

[0104] During algorithm execution, various operational logs (including but not limited to debugging information, event records, performance statistics, and error reports) generated by the algorithm itself or the onboard processing unit are written to the algorithm's dedicated log directory in real time or on a per-execution basis. This algorithm-specific log isolation storage design effectively avoids mutual interference between logs from different tasks, enabling ground personnel to quickly and accurately locate the operational status and abnormal points of a specific algorithm after receiving the downlinked log data. This provides structured and traceable data support for diagnosing on-orbit problems, optimizing and iterating algorithms, and analyzing mission reliability.

[0105] Furthermore, the onboard processing unit is configured to support the independent uploading, deployment, and maintenance of multiple algorithm containers, and maintains an isolated independent directory structure for each algorithm container in the onboard storage medium, thereby achieving true platformization and multi-tasking capabilities.

[0106] Specifically, the system does not rely on a single algorithm, but rather serves as an open platform that allows multiple different algorithm containers (such as GPU_000_AI_APP.zip, GPU_001_AI_APP.zip, etc.) to be uploaded to the ground on demand and in sequence. The uploading, transmission, receiving, deployment, and configuration processes of each algorithm container are carried out independently, following the aforementioned unified specifications, and are independent of each other.

[0107] On the onboard storage medium, the onboard processing unit maintains a physically or logically isolated complete directory structure (i.e., independent subdirectories for applications, configurations, libraries, data, models, logs, etc.) for each successfully deployed algorithm container. This architecture ensures that the files, dependencies, configurations, intermediate runtime data, and logs of different algorithms are isolated from each other, fundamentally avoiding mutual interference and resource conflicts between algorithms. The platform centrally manages and schedules these coexisting algorithms on demand through a unified task scheduler and instruction parsing module, enabling a single satellite to flexibly carry out and quickly switch between executing multiple heterogeneous intelligent processing tasks. This achieves the evolution from a "single-function device" to a "multi-task service platform," improving the satellite's mission adaptability, resource utilization, and application expansion potential.

[0108] Through the aforementioned mechanism, this application constructs a truly open spaceborne algorithm platform. Algorithms from different sources and with different functions (e.g., target detection algorithms from Company A, image segmentation algorithms from Company B, and classification algorithms for scenario C) can be independently uploaded to the satellite and coexist in an isolated environment, as long as they adhere to a pre-defined standardized container format. The ground system can dynamically combine these algorithms to form task workflows according to actual business needs: for example, in a marine surveillance scenario, ship detection algorithms and track tracking algorithms can be scheduled to execute collaboratively; in an urban planning scenario, a combination of change detection algorithms and ground feature classification algorithms can be used. This flexible scalability of "algorithm as a service" enables a single satellite to carry out multiple business missions, significantly improving the satellite's mission adaptability and application benefits.

[0109] Furthermore, the onboard processing unit includes a unified instruction parser and scheduler, configured to perform unified instruction parsing and task scheduling management for multiple deployed algorithm containers.

[0110] Here, the onboard processing unit is equipped with a unified instruction parser and scheduler. This module, as the core hub for onboard algorithm task management, is responsible for centrally receiving and parsing task instructions from ground subsystems, mapping the instruction content into specific executable algorithm tasks. Based on this, the scheduler dynamically and orderly schedules the corresponding algorithms to be executed on the graphics processor according to the status of each algorithm container currently deployed on the satellite, resource occupancy, and the execution order of the algorithms. This enables unified management, collaborative scheduling, and resource allocation of multiple algorithm tasks, effectively improving the flexibility and processing efficiency of the onboard computing platform.

[0111] Furthermore, the onboard processing unit includes a main management module and a graphics processing module; The main management module is configured to receive the uploading data packets, create the directory structure, execute the deployment scripts, parse and schedule task instructions, and summarize status parameters. Here, the main management module is configured to perform a series of management and coordination tasks. Specifically, this includes: receiving uploading data packets transmitted via the satellite-to-ground link; parsing the data packets and creating corresponding isolated directory structures in the onboard storage medium; calling and executing the automated deployment scripts within the data packets to complete the installation of algorithms and environment configuration; parsing task execution instructions from the ground and making scheduling decisions (such as selecting parallel or serial mode) based on the instruction content and system resource status; and summarizing the running status parameters from each algorithm and writing them into the onboard shared memory area to provide a data source for status transmission.

[0112] The graphics processing module is configured to provide onboard graphics processor memory and is scheduled by the main management module to perform data processing algorithms.

[0113] The graphics processing module (GPU), as a dedicated computing hardware platform, primarily provides the onboard graphics processor and its memory resources. Controlled by the main management module's scheduling instructions, this module is responsible for carrying and executing specific algorithmic data processing tasks. When the main management module issues an execution command, the GPU is activated, loading the specified algorithm into the GPU's memory to run and complete core computations such as image processing and model inference. In multi-algorithm collaborative scenarios, this module is also responsible for allocating and managing a shared memory pool in the GPU's memory according to the main management module's instructions, and for coordinating zero-copy data transfer and synchronization between algorithms.

[0114] This modular division clarifies the "control flow" and "computation flow" within the onboard processing unit. The main management module is responsible for high-level, logical management and scheduling, while the graphics processing module focuses on low-level, computationally intensive processing tasks. The two work together through a clear interface to form an efficient and reliable onboard processing core.

[0115] Traditional satellites have fixed functions and cannot be updated in orbit. This application, through a standardized algorithm container design and a complete OTA (Over-The-Air) upload process, packages the algorithm and its operating environment in a unified manner, enabling the satellite to dynamically receive, install, and switch between different service algorithms according to ground commands. This transforms the satellite into an open "on-orbit algorithm platform," which can be flexibly reconfigured according to commands throughout its lifecycle to perform diverse intelligent tasks (such as switching from ship detection to urban monitoring). This achieves a leap from "hardware-defined" to "software-defined," expanding the satellite's application scenarios and its full lifecycle value.

[0116] This application optimizes on-board collaborative processing performance through a multi-algorithm scheduling scheme based on a shared GPU memory pool and zero-copy technology. For serial tasks with data dependencies, traditional methods require data transfer via storage media, introducing significant I / O latency. This application achieves zero-copy data transfer by enabling subsequent algorithm threads to directly access the output area of ​​the predecessor algorithm in GPU memory, supplemented by a synchronization mechanism. This eliminates redundant data movement overhead, reduces the overall latency of serial execution of multiple algorithms, and significantly improves the timeliness and system efficiency of on-board intelligent processing, meeting the needs of on-orbit information extraction scenarios with extremely high real-time requirements.

[0117] This application enhances the reliability and maintainability of the system by designing a closed-loop state monitoring mechanism and a standardized container isolation structure. Critical states from injection to execution are recorded and downloaded via shared memory. Combined with the independent runtime space of each algorithm (including dedicated configurations, data, and logs), the entire on-orbit state is made "knowable and controllable." Ground-based systems can remotely monitor the algorithm health status and quickly locate anomalies using downloaded logs. The isolation between algorithms effectively avoids mutual interference, improves the overall stability of the system, and provides operational support for long-term reliable on-orbit operation.

[0118] This application achieves intelligent management and on-demand scheduling of onboard GPU resources by constructing a dynamic resource awareness and adaptive scheduling mechanism. The system monitors GPU resource usage in real time and automatically matches the optimal execution mode based on task instructions: when resources are sufficient, it prioritizes single-algorithm execution or parallel execution of multiple algorithms to improve efficiency; when resources are scarce, it automatically switches to serial execution mode. Especially in the serial mode of multiple algorithms, a shared GPU memory pool strategy is adopted to avoid multiple reads and writes of storage media, thereby improving the system's timeliness. Through this mechanism, scheduling flexibility is achieved, and the utilization rate of onboard computing resources is improved.

[0119] This application defines a clear interface standard for algorithm integration through the proposed standardized algorithm container format and uploading package specification, enabling the platform to possess excellent scalability. Any algorithm conforming to this standard can be integrated through a unified process, which lays the technical foundation for building an open spaceborne application ecosystem and supports the continuous evolution and industrialization of technology.

[0120] In summary, this application, through a complete technical solution of "containerized packaging - reliable uploading - flexible scheduling - efficient execution - status monitoring", upgrades the satellite into an intelligent computing platform with definable functions, scalable services, schedulable resources, and observable status. It achieves significant improvements in flexibility, economy, efficiency, and reliability, and is of great significance to promoting the development of next-generation intelligent satellite technology.

[0121] This application defines a unified algorithm container format and uploading package specification based on a standardized container-based dynamic deployment method for onboard algorithms. Combined with automated deployment scripts, it realizes the one-time packaging and on-orbit automated deployment of algorithms and their complete operating environment, forming the cornerstone of "software-defined satellites".

[0122] The zero-copy collaborative computing model based on a shared GPU memory pool pre-allocates a shared pool in the GPU's global memory for data-dependent tasks. Through a synchronization mechanism, subsequent algorithms can directly access the output area of ​​the predecessor algorithm, achieving zero-copy data transfer between algorithms and reducing processing latency.

[0123] The closed-loop status monitoring mechanism for betting and deployment uses independent status writing to the program and shared memory to provide real-time feedback on the betting and deployment status to the ground, forming a closed loop of "instruction-execution-feedback" to ensure that the process is knowable and controllable.

[0124] Based on a resource-aware dynamic multi-mode scheduling strategy, the system monitors resource usage in real time and can automatically switch between three execution modes: single algorithm, multi-algorithm parallel, and serial.

[0125] The system features a platform architecture that supports independent uploading and unified management of multiple algorithms. Designed as an open platform, it supports independent uploading and isolated coexistence of multiple compliant algorithms. Through a unified instruction parser and scheduler, it manages the entire lifecycle, laying the foundation for building a spaceborne application ecosystem.

[0126] Compared with existing technologies that suffer from fixed satellite functions, low algorithm collaboration efficiency, opaque system status, and low utilization of computing resources, this application constructs a complete management system that includes "standardized algorithm container encapsulation, satellite-to-ground wireless transmission, automatic onboard deployment, and closed-loop status monitoring." It also innovatively introduces a zero-copy collaborative computing model based on a shared GPU memory pool and a resource-aware dynamic multi-mode scheduling strategy. This enables on-demand dynamic reconfiguration of satellite on-orbit processing capabilities, efficient and seamless collaboration among multiple algorithms, knowable and controllable status throughout the entire process, and intelligent reuse of onboard computing resources. Consequently, the satellite is upgraded from a single-function dedicated hardware platform to a flexible, efficient, reliable, and scalable intelligent computing platform, improving the satellite's mission adaptability, processing timeliness, system reliability, and overall economic benefits.

[0127] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0128] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0129] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0130] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0131] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0132] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A spaceborne algorithm management and deployment system, characterized in that, Including ground subsystems and spaceborne processing units, The ground subsystem is configured as follows: According to the preset standardized container format, the algorithm application and its running environment are encapsulated into an algorithm container, and the algorithm container and the corresponding deployment script are packaged to generate a versioned uploading data package; The uploading data packet is transmitted via a satellite-to-ground wireless link; The onboard processing unit is configured as follows: The uploading data packet is received via the satellite-to-ground wireless link; Create an isolated directory structure corresponding to the algorithm container in the onboard storage medium to form an isolated operating environment; Execute the deployment script to deploy the files in the algorithm container to the independent directory structure and configure the runtime environment; In response to mission instructions from the ground subsystem, deployed algorithms are scheduled to perform data processing on the onboard graphics processor; The status parameters generated during the algorithm's uploading, deployment, and operation are written into the onboard shared memory area and transmitted down to the ground subsystem via the telemetry link, forming a closed-loop status monitoring system between the satellite and the ground.

2. The system according to claim 1, characterized in that, The preset standardized container format specifies that each algorithm container should include at least the following directories: an application subdirectory for storing algorithm executable files, a configuration subdirectory for storing configuration files, a library subdirectory for storing dependency library files, a data subdirectory for storing input and output data, and a model subdirectory for storing pre-trained model files.

3. The system according to claim 1, characterized in that, The onboard processing unit is also configured to write the deployment success or failure status parameters into the onboard shared memory area after completing the execution of the deployment script of the algorithm container; the system also includes an onboard integrated electronic unit, configured to read the status parameters from the onboard shared memory area and transmit them to the ground subsystem through the telemetry link.

4. The system according to claim 1, characterized in that, The onboard processing unit is further configured to: When multiple deployed algorithms need to be processed sequentially and collaboratively, a shared data area is pre-allocated in the memory of the onboard graphics processor. Through a thread synchronization mechanism, the predecessor algorithm is controlled to write the processed output data into the shared data area, and subsequent algorithm threads are triggered to read the output data from the shared data area as their input.

5. The system according to claim 1, characterized in that, The onboard processing unit is further configured to: Monitor the memory and computing resource usage of the onboard graphics processor; Based on the monitoring results and task instructions, the system dynamically selects one of the following scheduling modes: single-algorithm execution, multi-algorithm parallel execution, or multi-algorithm serial execution.

6. The system according to claim 1, characterized in that, The onboard processing unit is further configured to: The final result data generated after the algorithm is processed is packaged in the onboard storage medium and transmitted to the ground subsystem via the space-to-ground data link.

7. The system according to claim 1, characterized in that, The onboard processing unit is further configured to: Each deployed algorithm maintains an independent log directory in the onboard storage medium, and the operation logs generated during the algorithm execution are stored in the corresponding log directory. The operation logs can be downlinked via the satellite-to-ground link for ground analysis.

8. The system according to claim 1, characterized in that, The onboard processing unit is configured to support the independent uploading, deployment, and maintenance of multiple algorithm containers, and to maintain an isolated independent directory structure for each algorithm container in the onboard storage medium.

9. The system according to claim 1, characterized in that, The onboard processing unit includes a unified instruction parser and scheduler, configured to perform unified instruction parsing and task scheduling management on multiple deployed algorithm containers.

10. The system according to claim 1, characterized in that, The onboard processing unit includes a main management module and a graphics processing module; The main management module is configured to receive the uploading data packet, create the directory structure, execute the deployment script, parse and schedule task instructions, and summarize status parameters. The graphics processing module is configured to provide the onboard graphics processor memory and is scheduled by the main management module to execute data processing algorithms.

Images