Space mission on-orbit autonomous updating method and device

Abstract

The application discloses a kind of aerospace task on-orbit autonomous updating method and device, belong to aerospace software design field.The method includes: the initialization configuration and rule definition of heterogeneous computing platform architecture are obtained to basic running system;The reliable transmission and verification reorganization of the update file and control instruction issued by ground are obtained to be updated file and to be executed control instruction;According to control instruction, the target task process and the isolated autonomous update of to-be-updated file are obtained to update effective target task process and full-phase execution state data;According to the execution state data, the full-process monitoring of update process and update result is obtained to be used for monitoring tracing update full-process record.The application can realize safe and reliable task on-orbit autonomous updating.

Description

Technical Field

[0001] This invention relates to the field of aerospace software design technology, and in particular to a method and apparatus for on-orbit autonomous updating of aerospace missions. Background Technology

[0002] In spacecraft computer system software, a heterogeneous architecture of "high-reliability computing units + high-performance computing units" is increasingly being adopted, with general-purpose operating systems such as Linux running on the high-performance computing units to support intelligent computing tasks. Since intelligent tasks often rely on the parallel computing capabilities of GPUs and comprehensive driver, SDK, and toolchain support, Linux has become a commonly used development, debugging, and runtime environment for high-performance units.

[0003] In related technologies, the traditional on-orbit update method for real-time embedded systems is mainly used. This process traditionally relies on manual operation of peripherals such as keyboards and mice, which is completely contradictory to the constraints of no peripheral input in the on-orbit environment. At the same time, the traditional method lacks refined task control and safety assurance mechanisms, and cannot meet the stringent requirements of on-orbit updates for safety and reliability.

[0004] Therefore, there is an urgent need for a method and device for autonomous on-orbit updates in space missions to solve the above-mentioned technical problems. Summary of the Invention

[0005] This invention provides a method and apparatus for on-orbit autonomous update of space missions, enabling safe and reliable on-orbit autonomous update. The technical solution is as follows: On the one hand, a method for on-orbit autonomous updating of space missions is provided, the method comprising: The heterogeneous computing platform architecture, built from high-reliability computing units and Linux high-performance computing units, is initialized, configured, and its rules are defined to obtain a basic operating system that includes cross-unit communication links and a high-frequency instruction dictionary. Based on the communication link and the established data verification rules, the update files and control commands issued from the ground are reliably transmitted, verified, and reassembled to obtain complete and verified update files and control commands to be executed. Based on the high-frequency instruction dictionary and the constructed security rules, the target task process and the file to be updated are updated in isolation and autonomously according to the control instructions, so as to obtain the updated target task process and the full-stage execution status data. The update process and update results are monitored throughout the entire process based on the execution status data, resulting in a complete update process record for monitoring and tracing.

[0006] On the other hand, an on-orbit autonomous update device for space missions is provided, the device comprising: The initialization module is used to initialize and configure the heterogeneous computing platform architecture built by high-reliability computing units and Linux high-performance computing units, and define the rules to obtain a basic operating system that includes cross-unit communication links and a high-frequency instruction dictionary. The verification module is used to reliably transmit, verify, and reassemble the update files and control commands sent from the ground according to the communication link and the constructed data verification rules, so as to obtain complete and verified update files and control commands to be executed. The update module is used to perform isolated autonomous updates on the target task process and the file to be updated according to the high-frequency instruction dictionary and the constructed security rules, and to obtain the updated target task process and full-stage execution status data. The monitoring module is used to monitor the entire update process and update results based on the execution status data, and obtain a full update process record for monitoring and tracing.

[0007] On the other hand, a computer device is provided, the computer device including a memory and a processor, the memory for storing computer programs, and the processor for executing the computer programs stored in the memory to implement the steps of the above-described on-orbit autonomous update method for space missions.

[0008] On the other hand, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, it implements the steps of the above-described on-orbit autonomous update method for space missions.

[0009] On the other hand, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the above-described on-orbit autonomous update method for space missions.

[0010] The technical solution provided by this invention can bring at least the following beneficial effects: First, by establishing a reliable communication link and a pre-set command dictionary, the ground only needs to issue simple commands and files to remotely trigger updates, completely eliminating the dependence on peripherals such as keyboards and mice, and meeting the operational constraints of unmanned on-orbit intervention; Second, through child process isolation execution, precise process positioning, and a "software-first, hardware-later" anti-false kill strategy, when completing the closed-loop operation of stopping the target task, atomically replacing files, and restarting, it can effectively avoid accidentally shutting down other parallel tasks, ensuring business continuity; Subsequently, through a full-process log recording and real-time status feedback mechanism, the entire update process is completely transparent to the ground, realizing status monitoring, result confirmation, and fault traceability, greatly reducing the complexity and risk of on-orbit operation and maintenance. This method addresses the pain points of the inability to intervene with peripherals on-orbit, the need for shutdown, replacement, and restart for Linux task updates, and the need for monitoring and traceability of the update process, constructing a safe and reliable autonomous update process, and providing background basis for the implementation of subsequent technical solutions. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart of an on-orbit autonomous update method for a space mission provided by an embodiment of the present invention; Figure 2 This is a structural diagram of an on-orbit autonomous update device for a space mission provided by an embodiment of the present invention; Figure 3 This is a hardware architecture diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0014] Please refer to Figure 1 The present invention provides an on-orbit autonomous update method for a space mission, the method comprising: Step 100: Initialize the configuration and define the rules for the heterogeneous computing platform architecture built by the high-reliability computing unit and the Linux high-performance computing unit to obtain the basic operating system containing cross-unit communication links and a high-frequency instruction dictionary; Step 102: Based on the communication link and the established data verification rules, reliably transmit, verify and reassemble the update file and control command issued from the ground to obtain a complete and verified update file and control command to be executed. Step 104: Based on the high-frequency instruction dictionary and the constructed security rules, perform isolated autonomous updates on the target task process and the file to be updated according to the control instructions to obtain the updated target task process and full-stage execution status data. Step 106: Monitor the entire update process and update results based on the execution status data to obtain a full update process record for monitoring and tracing.

[0015] In this embodiment of the invention, the technical solution provided by the present invention can bring at least the following beneficial effects: First, by establishing a reliable communication link and a pre-set instruction dictionary, the ground only needs to issue simple instructions and files to remotely trigger updates, completely eliminating the dependence on peripherals such as keyboards and mice, and meeting the operational constraints of unmanned on-orbit intervention; Second, through child process isolation execution, precise process positioning, and a "software-first, hardware-later" anti-false kill strategy, when completing the closed-loop operation of stopping the target task, atomically replacing files, and restarting, it can effectively avoid accidentally closing other parallel tasks, ensuring business continuity; Subsequently, through the full-process log recording and real-time status feedback mechanism, the entire update process is completely transparent to the ground, realizing status monitoring, result confirmation, and fault traceability, greatly reducing the complexity and risk of on-orbit operation and maintenance. This method addresses the pain points of the inability to intervene with peripherals on-orbit, the need for shutdown, replacement, and restart for Linux task updates, and the need for monitoring and traceability of the update process, constructing a safe and reliable autonomous update process, and providing background basis for the implementation of subsequent technical solutions.

[0016] The following description Figure 1 The execution method for each step is shown.

[0017] First, for step 100, the heterogeneous computing platform architecture built by the high-reliability computing unit and the Linux high-performance computing unit is initialized, configured, and the rules are defined to obtain the basic operating system including cross-unit communication links and high-frequency instruction dictionaries.

[0018] The onboard computing platform consists of a high-reliability computing unit (SoC2018) running SpaceOS and a high-performance computing unit (NVIDIAXavier) running Linux. An Ethernet link is established between the high-reliability computing unit and the high-performance computing unit. The ground sends update files and control commands to the high-reliability computing unit via the space-to-ground link, and the high-reliability computing unit then forwards them to the Linux side.

[0019] This step is the core preparatory stage for the entire on-orbit autonomous update. All operations are completed before ground launch. The goal is to enable the on-board high-performance computing unit running Linux to have the basic capabilities of "autonomously receiving update data, parsing and executing instructions, managing security processes, and transmitting status results", thereby fundamentally solving the pain points of no peripheral intervention and inability to operate manually in orbit.

[0020] The initial configuration process includes the following sub-steps: The high-performance computing unit running Linux is processed by program creation and module encapsulation to obtain an on-orbit autonomous update program that integrates UDP sending and receiving, frame parsing and verification, instruction parsing and combination, execution scheduling and log transmission units.

[0021] Specifically, this step is used to implant and encapsulate the Linux operating system of the onboard high-performance computing unit (NVIDIA Xavier) to obtain an autonomous update daemon that runs in the background for a long time and has complete update control capabilities. This daemon is the main body for executing all on-orbit update operations.

[0022] The self-update program is compiled into a Linux executable file, deployed on a protected non-volatile storage partition (such as / opt / onboard_update / ), and configured as a daemon (systemd service) that starts automatically at system boot. After the on-orbit system powers on, the program automatically starts and continuously listens on the specified UDP port, requiring no manual intervention.

[0023] The program employs a modular design, with each module running independently and interacting through internal interfaces, ensuring that a failure in a single module does not affect the overall process. UDP transceiver unit: Responsible for Ethernet communication with the high-reliability computing unit (SoC2018), realizing the sending and receiving of UDP packets, and handling the receipt of receive timeout and packet loss retransmission requests.

[0024] Frame parsing and verification unit: Parses the header information of the received UDP frame, extracts fields such as session identifier, frame sequence number, and total number of frames, calculates the CRC check value of the frame data, compares it with the check value carried in the frame header, and determines the data integrity.

[0025] Command parsing and combination unit: responsible for parsing control commands issued from the ground, matching command templates in the high-frequency command dictionary, filling in personalized parameters to generate the final executable command, and performing command validity verification.

[0026] The execution scheduling unit manages the execution flow of update tasks, is responsible for creating independent child processes to execute update commands, monitoring the running status of child processes, controlling the sequential execution of each stage of "stop-replace-restart", and handling execution timeouts and exceptions.

[0027] Log and backhaul unit: Records key information and logs throughout the entire update process in real time, packages status data in a preset format, and backhauls it to the high-reliability computing unit via the UDP transceiver unit.

[0028] Furthermore, based on the cross-unit data interaction requirements, the Ethernet link and UDP communication parameters of the high-reliability computing unit and the high-performance computing unit are configured to obtain a bidirectional communication link with clearly specified receive / return ports, receive buffer size, and receive timeout threshold.

[0029] Specifically, this step is used to configure the protocol and optimize the parameters of the Ethernet physical link between the high-reliability computing unit and the high-performance computing unit, so as to obtain a dedicated update data transmission channel with low latency, verifiability and distinguishable sessions, and solve the data interaction problem between heterogeneous units on the satellite.

[0030] Configure static IP addresses, subnet masks, and gateways for the Ethernet link based on the TCP / IP protocol stack to ensure network connectivity between the two computing units; at the same time, specify dedicated UDP ports: Receive port: the port on the Linux side used to receive update files and control commands issued by the high-reliability unit (e.g., 5000); Return port: the port on the Linux side used to send status receipts and log data to the high-reliability unit (e.g., 5001).

[0031] In addition, configure the UDP receive buffer size (e.g., 1MB) to adapt to large file frame transmission, and set the receive timeout (e.g., 5 seconds). If no subsequent frame is received after this timeout, a timeout retransmission request will be triggered.

[0032] Define globally unique update session identifier (SessionID) and frame sequence number (FrameSN) rules: Session identifier: generated by the ground and distributed with the update request, used to distinguish different batches of on-orbit update tasks and avoid old data packets from being mistakenly triggered for updates due to network latency; Frame sequence number: each UDP frame is assigned a unique consecutive sequence number, used by the Linux side to reassemble complete files and instructions in order, and to locate the packet loss location.

[0033] This mechanism is the core means to solve the unreliability of the UDP protocol and ensure that multi-task updates do not conflict.

[0034] Furthermore, the system state variables and session identifier system of the update process are defined and initialized to obtain the receive state variables with initial values ​​of 0, and the session identifier and sequence number used to identify different update requests.

[0035] Specifically, this step is used to initialize and assign values ​​to the core state variables of the self-updating program, build the internal flow control state machine of the program, and ensure that the update process is executed in an orderly manner in the order of "receive-verify-execute-return".

[0036] First, define three Boolean state variables, all initialized to 0 (indicating incomplete / normal): File reception completion flag: 0 = file not fully received, 1 = file fully received and secondary verification passed; Command reception completion flag: 0 = control command not received or not parsed, 1 = command has been fully received and successfully parsed; Verification failure flag: 0 = all received frames passed verification, 1 = there are frames that failed verification and need to be retransmitted.

[0037] The program then uses a combination of state variables to determine the current process stage: only when "file reception completion flag = 1, instruction reception completion flag = 1, and verification failure flag = 0" will the session state be set to "pending execution" and the subsequent instruction execution stage be entered; if any state variable is abnormal, the current process will be terminated and an error message will be returned.

[0038] Furthermore, the commonly used system operations in the entire update process are templated and indexed to obtain a high-frequency instruction dictionary and parameter mapping rules with integers or short strings as indexes and Linux executable commands or combined commands as templates.

[0039] This step is used to predefine standardized instruction execution templates and security constraint rules on the Linux side, resulting in a scalable, highly secure, and low-transmission-volume instruction execution system. This is the core design of this invention's embodiment to achieve "complex updates can be triggered by only sending indexes and parameters from the ground".

[0040] Specifically, a lightweight key-value structure is used to build the instruction dictionary, which is stored in a read-only memory area inside the program to prevent on-track tampering. Key (Command Index): Uses an integer or short string (such as K_STOP_PROC, K_REPLACE_FILE, K_RESTART_PROC), occupying very few bytes, greatly reducing the amount of data transmitted on the satellite-to-ground link; Value (command template): Corresponds to the executable command or command combination template of the Linux system, and uses placeholders to mark the location of personalized parameters.

[0041] Next, parameter mapping rules are established for each Value, and placeholders are used to define personalized parameter positions. For example, {PROC} represents the process name, {PID} represents the process ID, {SRC} represents the temporary file path, and {DST} represents the target path. Commonly used update operations are written into a dictionary, including at least: stopping the process, querying the PID, copying / overwriting, verifying the file, setting permissions, starting the process, and echoing the status. The combined commands are used to express the sequential execution of "stop-replace-verify-restart".

[0042] Finally, based on the requirements for secure execution and attack prevention of on-orbit updates, the permission boundaries and parameter ranges for instruction execution are constrained to obtain security rules that only allow the execution of command templates within the high-frequency instruction dictionary and parameters filled with mapping rules.

[0043] Specifically, this embodiment defines two layers of security constraints to prevent malicious instruction injection and unauthorized operations: Command whitelist: Only allows execution of predefined Value templates in the command dictionary, prohibits the execution of arbitrary system commands, and eliminates dangerous operations such as "rm-rf / "; Parameter validity verification: All personalized parameters are strictly verified, including character set verification (command separators such as ;, |, & are prohibited) and path validity verification (only the preset task directory and temporary update directory are allowed to be accessed, and access to critical system directories such as / boot and / etc is prohibited).

[0044] Then, for step 102, according to the communication link and the constructed data verification rules, the update file and control command issued from the ground are reliably transmitted, verified and reassembled to obtain a complete and verified update file and control command to be executed.

[0045] In this embodiment of the invention, the file to be updated and the control instructions to be executed are obtained in the following manner: According to the UDP communication protocol specification, the raw update data received by the high-reliability unit is processed into frames and packaged to obtain a standardized UDP frame sequence in which each frame contains a session identifier, frame sequence number, total number of frames, data type, length and CRC check field.

[0046] Specifically, based on the operational performance of the on-orbit mission, the ground control station initiates targeted mission update requests and sends two types of core data to the onboard high-reliability computing unit as input material for subsequent autonomous updates.

[0047] One is the set of task files to be updated, containing all the target files that need to be replaced, covering all elements of Linux task execution: Executable files: main program for the task, dependent library files (.so); The core of intelligent tasks: AI model files and algorithm parameter files; Configuration and scripts: startup scripts, configuration files, environment variable scripts.

[0048] The ground system will pre-calculate the total length and global CRC check value of each file, and send them along with the file metadata for subsequent secondary verification on the Linux side.

[0049] Another approach is to update control commands, using a lightweight format of "command index key + personalized parameters" instead of full Linux commands, significantly reducing the amount of data transmitted over the satellite-to-ground link. For example: Command Key: K_UPDATE_TASK (corresponds to the "Stop-Replace-Verify-Restart" command combination); Custom parameters: Process name=ai_target_detect, Source file path= / tmp / update / ai_detect, Target path= / opt / tasks / ai_detect, Startup parameter=--device=gpu0.

[0050] Simultaneously, the ground team will generate a globally unique 32-bit session ID for this update, which will be distributed along with all data. This ID is used throughout the entire update process to distinguish different batches of update tasks, completely resolving the issue of "old data packets arriving late and triggering updates erroneously" caused by network latency.

[0051] The highly reliable computing unit (SoC2018) running SpaceOS serves as a trusted data relay node for the spaceborne system. It does not parse the updated content itself, but is only responsible for breaking down large files and instructions sent from the ground into small frames suitable for UDP transmission, and ensuring transmission reliability through a retransmission mechanism.

[0052] Since the Ethernet MTU (Maximum Transmission Unit) is typically 1500 bytes and the UDP header occupies 28 bytes, each large file and instruction is split into a payload of 1472 bytes per frame, generating a continuous frame sequence. Each frame uses a uniform structured format, with all fields of fixed length, facilitating fast parsing on the Linux side.

[0053] Furthermore, the packaged UDP frame sequence is transmitted to the on-orbit autonomous update program via the communication link, and the corresponding frame is automatically retransmitted if no transmission receipt is received within a timeout period. The received UDP frame sequence is parsed for frame header information and the checksum is calculated and compared to obtain the checksum result and payload data for each frame. If the current frame fails the checksum, an error receipt containing a session identifier, frame sequence number, and error code is generated and sent back to the high-reliability unit to request the retransmission of the current frame.

[0054] Specifically, the high-reliability unit sends the frame sequence in ascending order of frame number, and starts a timer after each frame is sent (preset timeout is 3 seconds). If a "frame received successfully" receipt is received from the Linux side within the timeout period, the frame buffer is destroyed and the next frame is sent. If no receipt is received within the timeout period, or a "frame verification failed" receipt is received, the frame is retransmitted, up to a maximum of 5 times. If the number of retransmissions is exceeded, the transmission is terminated and a "transmission failed" error is sent back to the ground.

[0055] The high-reliability unit only performs data handling and transmission reliability control, without parsing update commands and file contents, thus achieving "decoupling of high-reliability unit and Linux-side tasks": when adding or modifying update commands on the Linux side, there is no need to modify the software of the high-reliability unit, which greatly reduces the maintenance complexity of the onboard system.

[0056] Subsequently, the UDP transceiver unit and frame parsing and verification unit of the Linux-side self-updating program work together to parse, verify and cache each received UDP frame in real time, while providing rapid feedback on erroneous frames.

[0057] The self-updating program acts as a daemon process, continuously listening to the UDP receive port (e.g., 5000) configured in step one. Upon receiving a UDP packet, it immediately parses all fields in the frame header: First, it verifies the session identifier; if it does not match the identifier of the currently ongoing update session, it discards the frame directly to avoid interference from old packets; it extracts the frame sequence number, total number of frames, data type, and CRC check value to prepare for subsequent verification and caching.

[0058] Calculate the CRC32 checksum for the payload portion of the frame and compare it with the CRC checksum carried in the frame header: Verification failed: Immediately set the "verification failure flag = 1" defined in step one, generate an error receipt containing "session identifier + frame sequence number + error code = 0x01 (verification failed)", and send it to the high-reliability unit through the UDP return port (e.g. 5001) to request retransmission of the frame; Verification passed: Clear the verification failure flag corresponding to the frame, store the payload data into the memory buffer according to the frame number, and add the frame number to the "received frame number set" for subsequent determination of whether all frames have been received.

[0059] If no new frame is received within the timeout period set in step one (e.g., 5 seconds), a "timeout receipt" (error code = 0x02) is generated to inform the high-reliability unit to retransmit the subsequent frames of the last received frame, thus avoiding transmission suspension due to link interruption.

[0060] Finally, based on the correspondence between frame sequence number and total number of frames, all valid single-frame payloads that pass verification are cached and sequentially spliced ​​to obtain the complete file to be updated and the control instructions to be executed.

[0061] Specifically, when the size of the "received frame sequence number set" on the Linux side is equal to the "total number of frames" in the frame header, it means that all frames have been received and the process enters the data reassembly and global verification stage to ensure that the final files and instructions are completely consistent with those sent from the ground.

[0062] Based on the frame sequence number in ascending order, the payloads of all frames in the memory buffer are concatenated to restore the original complete data transmitted from the ground. Simultaneously, based on the "data type" field, the reconstructed data is divided into two categories: "files to be updated" and "control commands," which are processed separately.

[0063] The reconstructed files are written to the Linux default session isolation temporary directory (format: / tmp / update / [session ID] / ). For example, if the session ID for this update is 0x12345678, the files will be written to the / tmp / update / 12345678 / directory. Using the session ID as the subdirectory name can completely avoid file conflicts between multiple batch update tasks. Next, perform double verification: ① File length verification: compare the length of the written file with the length in the file metadata sent from the ground; ② Global CRC verification: calculate the CRC32 value of the entire file and compare it with the global CRC value sent from the ground. If any verification fails, the entire temporary directory is deleted, a "File Verification Failed" receipt (error code = 0x03) is generated and sent back to the ground, and the update is terminated; if the verification passes, the "File Reception Complete Flag = 1" is set.

[0064] The recombined control commands are initially parsed, and the command index Key and personalized parameters are extracted. The Key is checked to see if it exists in the high-frequency command dictionary pre-built in step one. If the Key does not exist, an "unknown command" receipt (error code = 0x04) is generated and sent back to the ground to terminate the update. If the Key exists, the "command reception completion flag = 1" is set.

[0065] The Linux-side self-update program completes all processing in this step only if the following three conditions are met simultaneously: file reception completion flag = 1; command reception completion flag = 1; verification failure flag = 0.

[0066] At this point, the program switches its internal session state from "receiving" to "pending execution" and generates a "data reception complete" receipt message, containing information such as session identifier, total number of bytes received, file verification result, and command parsing result. This message is then transmitted back to the ground control station via the high-reliability unit. Upon receiving this receipt, the ground confirms the successful completion of the data transmission phase and awaits the Linux side to proceed to the subsequent update execution phase.

[0067] For step 104, based on the high-frequency instruction dictionary and the constructed security rules, the target task process and the file to be updated are updated in an isolated and autonomous manner according to the control instructions, so as to obtain the updated target task process and the full-stage execution status data.

[0068] In this embodiment of the invention, the update process includes the following steps: The control instruction to be executed is structured and parsed based on the high-frequency instruction dictionary to obtain the instruction index and corresponding personalized parameters.

[0069] Specifically, the control commands are broken down into personalized parameters in the form of command indexes (Keys) and key-value pairs according to a preset format, and the core metadata of this update is extracted: Required parameters: Target task process name, temporary update file path, target installation path Optional parameters: process startup parameters, file permission configuration, restart timeout, verification algorithm type For example, disassembly: The key K_UPDATE_TASK|PROC=ai_detect|SRC= / tmp / update / 12345678 / ai_detect|DST= / opt / tasks / ai_detect|PERM=755 is obtained. The corresponding parameter set includes process name, source path, target path and file permissions.

[0070] Furthermore, the command templates that match in the dictionary are searched according to the instruction index, and the command templates are filled with placeholders and combined according to the parameter mapping rules to obtain the final executable commands that are executed in sequence.

[0071] Specifically, the Value command template corresponding to the Key is found in the high-frequency instruction dictionary constructed in the aforementioned steps, and personalized parameters are filled into the template according to the placeholder mapping rules to generate the final executable command.

[0072] Example of a single command: Key=K_STOP_PROC, template=kill-15{PID}, after filling, kill-151234 is generated. Example of a combined command: Key=K_UPDATE_TASK, which corresponds to the sequential execution chain of "Stop → Backup → Replace → Verify → Restart", and after filling, it generates an ordered sequence containing 5 commands.

[0073] Furthermore, the final executable command is validated according to security rules to obtain the command execution permission determination result; if the validation fails, an error receipt containing the reason for the failure is generated and the update is terminated.

[0074] Specifically, the generated final command undergoes strict three-level validation; if any level fails, the update is immediately terminated and an error is returned. Command whitelist verification: Only commands predefined in the command dictionary are allowed to be executed, and dangerous system commands such as rm -rf, mkfs, and reboot are prohibited. Path control verification: Checks whether all file paths belong to the preset whitelist directories (only allowing access to the task directory / opt / tasks / and the temporary update directory / tmp / update / ), and prohibits access to critical system directories such as / boot, / etc, and / root. Parameter security verification: Filter command separators (;, |, &), redirection characters (>, >>), and wildcards (*, ?) in parameters to prevent command injection attacks.

[0075] In this embodiment of the invention, after completing the above processing, the final executable command that has passed the legality verification can be updated in an isolated manner to obtain the target task process and full-stage execution status data that have been updated. The update process is as follows: An independent child process is created based on the on-orbit autonomous update procedure to execute the final executable command.

[0076] Specifically, in order to completely solve the problem of blocking communication during the update execution process and to achieve resource isolation between the update task and the system core process, this embodiment of the invention adopts an isolation architecture of "parent process listening to communication + child process executing update".

[0077] The parent process is the self-updating main process, which remains resident and does not participate in the specific update operation. It is only responsible for: ① continuously listening to the UDP port to receive new instructions or retransmission requests from the ground; ② real-time transmission of update phase status and logs; ③ monitoring the running status of child processes and handling timeout or crash exceptions of child processes.

[0078] The child process is the updating execution process. It is created by the parent process through the fork() system call and is specifically used to execute the final executable command sequence. After execution, it automatically exits and releases all resources.

[0079] By using the Linux cgroups mechanism to constrain child processes' resources, it ensures that update operations do not consume excessive system resources and affect other tasks. For example: CPU limit: Set the CPU utilization cap to 20% and adjust the priority to nice-n10 (lower than system critical tasks). Memory limit: Set the maximum available memory to 512MB to prevent memory overflow during the update process from causing system crashes; Disk I / O limit: Set the maximum read / write speed to 10MB / s to prevent large file copying from consuming all disk bandwidth.

[0080] The parent process sets a global execution timeout for the child process (default 300 seconds). If the child process fails to exit after this time, it is determined to be in update suspension, the child process is forcibly terminated and an "execution timeout" error is returned, and the automatic rollback mechanism is triggered.

[0081] Furthermore, based on the target task process name in the personalized parameters, the list of currently running subprocesses is queried and filtered to obtain a list of PIDs that match the target task; the process attributes corresponding to the filtered target PIDs are compared and verified, and after confirming that the target PID completely matches the task to be updated, the target task process is stopped according to a preset termination strategy.

[0082] Specifically, this embodiment does not directly rely on the process name to terminate the process (to avoid mistakenly killing processes with the same name). Instead, it obtains the unique target PID through the following steps: Execute the command `ps -ef|grep {PROC}` to obtain a list of PIDs for all processes with the same name; Execute `ls -l / proc / {PID} / exe` for each PID to obtain the absolute path of the process's executable file; Compare the executable file path with the target path of this update to filter out the uniquely matching target PID; Optional verification: Further compare the process's startup parameters ( / proc / {PID} / cmdline) and process group ID to ensure 100% matching.

[0083] Next, a "soft first, hard later" tiered termination strategy is adopted to prioritize graceful process exit and avoid data loss or file corruption: Level 1 (Soft Termination): Sends a SIGTERM signal (signal 15) to the target PID, notifying the process to actively save data, release resources, and exit normally; waits 10 seconds and then checks whether the process still exists.

[0084] Level 2 (Hard Termination): If the soft termination times out, a SIGKILL signal (signal 9) is sent to the target PID to forcibly terminate the process; this signal cannot be caught by the process, ensuring that the process is terminated.

[0085] Each operation records the return code and execution time, and writes them to the update log for subsequent traceability.

[0086] After performing the termination operation, execute the process query command again to confirm that the target PID has disappeared from the process list. If the PID still exists after three consecutive queries, it is determined as a "stop failed", the update is terminated, and an error message is returned.

[0087] Furthermore, the file to be updated is overwritten and replaced with the original file in the target path, and the integrity of the replaced target file is verified. If the verification fails, a file rollback operation is performed to restore the original file and return the replacement failure information.

[0088] This embodiment uses Linux's native atomic operations to replace files, completely solving the problem of file corruption caused by power outages or crashes in traditional overwrite methods. At the same time, multiple verifications ensure that the replaced files are complete and correct.

[0089] Specifically, before the replacement, back up the original files in the target path to the temporary session isolation directory for this update ( / tmp / update / [session ID] / backup / ), and name the backup file after the original filename.bak. If the subsequent update fails, you can quickly roll back to the state before the update using this backup file.

[0090] The file replacement process strictly follows the three-step atomic replacement method of "temporary writing → verification → renaming and overwriting": Write the files to be updated in the temporary directory to a temporary file in the target path, named {DST}.new (e.g., / opt / tasks / ai_detect.new). Perform length verification and CRC32 global verification on the {DST}.new file to ensure that no data is corrupted during the writing process; The command `mv{DST}.new{DST}` completes the overwrite; in Linux, `mv` operations within the same partition are atomic operations, either succeeding completely or failing completely, without any intermediate state of partial file writing.

[0091] After the replacement is complete, execute the commands `chmod {PERM} {DST}` and `chown root:root {DST}` according to the permission parameters in the control instructions to ensure that the file has the correct execute permissions and owner, avoiding subsequent startup failures due to insufficient permissions. Simultaneously, perform a global CRC check on the replaced target file again, comparing it with the checksum of the original file sent from the ground. If the checksum fails, immediately perform a rollback operation: rename the backup file `{DST}.bak` back to overwrite the original file, delete temporary files, and return a "file replacement failed" error.

[0092] Finally, the target file that has passed the verification is updated and restarted according to the preset startup command, and the survival status and function of the target task process after restarting are verified to obtain the update execution status data.

[0093] Specifically, the corresponding restart command is used based on the deployment type of the target task: System service: Execute systemctl restart{SERVICE_NAME}; Daemon process: Executes nohup{DST}{START_PARAMS}&; For regular applications: execute {DST}{START_PARAMS} directly; The restart command is also executed through a child process, while the parent process continuously monitors the restart process.

[0094] This embodiment does not rely solely on the existence of the process to determine a successful restart, but instead employs a three-layer verification mechanism to ensure the task runs normally: Process liveness verification: Check if the target PID exists within 5 seconds after restarting to confirm that the process has started; Log keyword verification: Read the task's execution log and check if preset keywords such as "initialization completed" or "service started successfully" appear; Heartbeat signal verification: The waiting task sends a periodic heartbeat signal (default period of 1 second) to the high-reliability computing unit. If 3 normal heartbeats are received consecutively, the task is considered to be running normally.

[0095] If all verifications fail within the preset timeout period (default 60 seconds), the restart is deemed a failure, and an automatic rollback is immediately executed: forcibly terminating any potentially abnormal processes; overwriting the backup files with the target path; restarting the original version of the task and verifying it; and sending back the "restart failed" error and a detailed log summary to facilitate troubleshooting on the ground.

[0096] For step 106, the update process and update result are monitored throughout the entire process based on the execution status data to obtain a full update process record for monitoring and tracing.

[0097] In this embodiment of the invention, the updated full-process record is obtained in the following way: Based on the execution status data obtained from each update, key information of each stage of the update execution is recorded and processed in real time to obtain a complete update process log. The process log includes session identifier, instruction index, process name, PID, file path, verification result, stage status, return code, and timestamp. Based on the final result of the update execution, the fault information in the update failure scenario is extracted and additionally processed to obtain an error feedback message containing the failure stage location and core log summary; The process logs and error feedback messages are packaged according to a preset format and transmitted back to the ground to obtain an updated full process record.

[0098] Specifically, during execution, logs, key information and results are continuously recorded. The key information includes at least: session identifier, key, process name, PID, temporary path, target path, verification result, stage status, return code, and timestamp. The above information is packaged into a back transmission message according to a preset format and sent to the high-reliability unit, which then transmits it to the ground, thereby enabling the update process to be monitored in real time and traced afterward. When an update fails, the feedback includes information about the failure stage (such as "stop failed / replacement failed / verification failed / restart failed") and necessary log summaries to help the ground team quickly locate the problem.

[0099] Simultaneously, the following processes are designed to harden the system: Firmware hardening: Backup, verify, and restore the firmware related to the high-performance computing unit boot process when necessary to ensure reliable system bootability; Image hardening: Redundant backup of Linux system images, automatically repairing or restarting when abnormalities are detected during boot self-test; Operational hardening: After system startup, image refresh and error repair strategies are executed periodically to improve the stability and fault tolerance of long-term on-orbit operation and update process.

[0100] Through the above implementation methods, the present invention can complete the autonomous update of Linux on-orbit running tasks without relying on peripheral device interaction, and achieve fast and accurate execution through instruction dictionary and parameterization combination. Furthermore, the update process is guaranteed to be safe and reliable and the impact on other tasks is controllable through subprocess isolation, verification and return mechanisms.

[0101] Please refer to Figure 2 This invention provides an on-orbit autonomous update device for space missions, the device comprising: Initialization module 200 is used to initialize and configure the heterogeneous computing platform architecture built by high-reliability computing units and Linux high-performance computing units, and define the rules to obtain a basic operating system that includes cross-unit communication links and a high-frequency instruction dictionary; Verification module 202 is used to reliably transmit, verify and reassemble the update file and control command issued from the ground according to the communication link and the constructed data verification rules, so as to obtain a complete and verified update file and control command to be executed. Update module 204 is used to perform isolated autonomous updates on the target task process and the file to be updated according to the high-frequency instruction dictionary and the constructed security rules, and to obtain the updated target task process and full-stage execution status data. The monitoring module 206 is used to monitor the entire update process and update results based on the execution status data, and obtain a full update process record for monitoring and tracing.

[0102] In this embodiment of the invention, the initialization configuration and rule definition of the heterogeneous computing platform architecture built from high-reliability computing units and Linux high-performance computing units to obtain a basic operating system including cross-unit communication links and a high-frequency instruction dictionary includes: The high-performance computing unit running Linux is processed by program creation and module encapsulation to obtain an on-orbit autonomous update program that integrates UDP sending and receiving, frame parsing and verification, instruction parsing and combination, execution scheduling and log transmission units; Based on the cross-unit data interaction requirements, the Ethernet link and UDP communication parameters of the high-reliability computing unit and the high-performance computing unit are configured to obtain a bidirectional communication link with clearly specified receive / return ports, receive buffer size and receive timeout threshold. The system state variables and session identifier system of the update process are defined and initialized to obtain the receive state variables with initial values ​​of 0, the session identifier and sequence number used to identify different update requests; The common system operations in the entire update process are templated and indexed to obtain a high-frequency instruction dictionary and parameter mapping rules with integers or short strings as indexes and Linux executable commands or combined commands as templates. Based on the requirements for secure execution and attack prevention of on-orbit updates, the permission boundaries and parameter ranges for instruction execution are constrained to obtain security rules that only allow the execution of command templates within the high-frequency instruction dictionary and parameters filled with mapping rules.

[0103] In this embodiment of the invention, based on the communication link and the established data verification rules, the update files and control commands issued from the ground are reliably transmitted, verified, and reassembled to obtain complete and verified update files and control commands to be executed, including: According to the UDP communication protocol specification, the raw update data received by the high-reliability unit is processed into frames and packaged to obtain a standardized UDP frame sequence in which each frame contains a session identifier, frame sequence number, total number of frames, data type, length and CRC check field. The packaged UDP frame sequence is transmitted to the on-orbit autonomous update program according to the communication link, and the corresponding frame is automatically retransmitted if no transmission receipt is received within the timeout period. The received UDP frame sequence is parsed and the checksum is calculated and compared to obtain the checksum result and payload data of each frame. If the current frame fails the checksum, an error receipt containing the session identifier, frame sequence number and error code is generated and sent back to the high reliability unit to request the retransmission of the current frame. Based on the correspondence between frame sequence number and total number of frames, all valid single-frame payloads that pass verification are cached and sequentially spliced ​​to obtain the complete file to be updated and the control instructions to be executed.

[0104] In this embodiment of the invention, based on the high-frequency instruction dictionary and the constructed security rules, the target task process and the file to be updated are autonomously updated in isolation according to control instructions, resulting in updated target task process and full-stage execution status data, including: The control instruction to be executed is structured and parsed according to the high-frequency instruction dictionary to obtain the instruction index and corresponding personalized parameters; The command template is searched for in the dictionary according to the instruction index, and the command template is filled with placeholders and combined according to the parameter mapping rules to obtain the final executable command to be executed in sequence. The final executable command is validated according to security rules to obtain the command execution permission determination result; if the validation fails, an error receipt containing the reason for the failure is generated and the update is terminated. The final executable command, after passing the legality verification, is updated in an isolated manner to obtain the target task process and full-stage execution status data that have been updated.

[0105] In this embodiment of the invention, the isolated autonomous update of the final executable command after legality verification to obtain the updated target task process and full-stage execution status data includes: A separate subprocess is created based on the on-orbit autonomous update procedure to execute the final executable command; Based on the target task process name in the personalized parameters, the list of currently running subprocesses is queried and filtered to obtain a list of PIDs that match the target task. The process attributes corresponding to the selected target PID are compared and verified. After confirming that the target PID completely matches the task to be updated, the target task process is stopped according to the preset termination policy. The file to be updated is overwritten and replaced with the original file at the target path, and the integrity of the replaced target file is verified. If the verification fails, a file rollback operation is performed to restore the original file and return the replacement failure information. The target file that has passed the verification is updated and restarted according to the preset startup command, and the survival status and function of the target task process after restarting are verified to obtain the update execution status data.

[0106] In this embodiment of the invention, the update process and update result are monitored throughout the entire process based on the execution status data to obtain a full update process record for monitoring and tracing, including: Based on the execution status data obtained from each update, key information of each stage of the update execution is recorded and processed in real time to obtain a complete update process log. The process log includes session identifier, instruction index, process name, PID, file path, verification result, stage status, return code, and timestamp. Based on the final result of the update execution, the fault information in the update failure scenario is extracted and additionally processed to obtain an error feedback message containing the failure stage location and core log summary; The process logs and error feedback messages are packaged according to a preset format and transmitted back to the ground to obtain an updated full process record.

[0107] It should be noted that the on-orbit autonomous update device for space missions provided in the above embodiments is only an example of the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the on-orbit autonomous update device for space missions provided in the above embodiments and the on-orbit autonomous update method embodiments for space missions belong to the same concept, and the specific implementation process is detailed in the method embodiments, which will not be repeated here.

[0108] Embodiments of this application also provide a computer device, please refer to... Figure 3 The computer device includes a processor and a memory, the memory storing at least one instruction, at least one program, code set or instruction set, the at least one instruction, at least one program, code set or instruction set being loaded and executed by the processor to implement the on-orbit autonomous update method for space missions provided in the above-described method embodiments.

[0109] The embodiments of this application also provide a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by a processor to implement the on-orbit autonomous update method for space missions provided in the above-described method embodiments.

[0110] Embodiments of this application also provide a computer program product, which includes a computer program. A processor of a computer device reads the computer program from a computer-readable storage medium and executes the computer program, causing the computer device to perform any of the on-orbit autonomous update methods for space missions described in the above embodiments.

[0111] For ease of description, the above systems or devices are described separately as various modules or units based on their functions. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware components.

[0112] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0113] Finally, it should be noted that in this document, relational terms such as first, second, third, and fourth are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0114] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for on-orbit autonomous updating of space missions, characterized in that, The method includes: The heterogeneous computing platform architecture, built from high-reliability computing units and Linux high-performance computing units, is initialized, configured, and its rules are defined to obtain a basic operating system that includes cross-unit communication links and a high-frequency instruction dictionary. Based on the communication link and the established data verification rules, the update files and control commands issued from the ground are reliably transmitted, verified, and reassembled to obtain complete and verified update files and control commands to be executed. Based on the high-frequency instruction dictionary and the constructed security rules, the target task process and the file to be updated are updated in isolation and autonomously according to the control instructions, so as to obtain the updated target task process and the full-stage execution status data. The update process and update results are monitored throughout the entire process based on the execution status data, resulting in a complete update process record for monitoring and tracing.

2. The method as described in claim 1, characterized in that, The initialization configuration and rule definition of the heterogeneous computing platform architecture built from high-reliability computing units and Linux high-performance computing units result in a basic operating system including cross-unit communication links and a high-frequency instruction dictionary, including: The high-performance computing unit running Linux is processed by program creation and module encapsulation to obtain an on-orbit autonomous update program that integrates UDP sending and receiving, frame parsing and verification, instruction parsing and combination, execution scheduling and log transmission units; Based on the cross-unit data interaction requirements, the Ethernet link and UDP communication parameters of the high-reliability computing unit and the high-performance computing unit are configured to obtain a bidirectional communication link with clearly specified receive / return ports, receive buffer size and receive timeout threshold. The system state variables and session identifier system of the update process are defined and initialized to obtain the receive state variables with initial values ​​of 0, the session identifier and sequence number used to identify different update requests; The common system operations in the entire update process are templated and indexed to obtain a high-frequency instruction dictionary and parameter mapping rules with integers or short strings as indexes and Linux executable commands or combined commands as templates. Based on the requirements for secure execution and attack prevention of on-orbit updates, the permission boundaries and parameter ranges for instruction execution are constrained to obtain security rules that only allow the execution of command templates within the high-frequency instruction dictionary and parameters filled with mapping rules.

3. The method as described in claim 2, characterized in that, Based on the communication link and the established data verification rules, the updated files and control commands issued from the ground are reliably transmitted, verified, and reassembled to obtain complete and verified files to be updated and control commands to be executed, including: According to the UDP communication protocol specification, the raw update data received by the high-reliability unit is processed into frames and packaged to obtain a standardized UDP frame sequence in which each frame contains a session identifier, frame sequence number, total number of frames, data type, length and CRC check field. The packaged UDP frame sequence is transmitted to the on-orbit autonomous update program according to the communication link, and the corresponding frame is automatically retransmitted if no transmission receipt is received within the timeout period. The received UDP frame sequence is parsed and the checksum is calculated and compared to obtain the checksum result and payload data of each frame. If the current frame fails the checksum, an error receipt containing the session identifier, frame sequence number and error code is generated and sent back to the high reliability unit to request the retransmission of the current frame. Based on the correspondence between frame sequence number and total number of frames, all valid single-frame payloads that pass verification are cached and sequentially spliced ​​to obtain the complete file to be updated and the control instructions to be executed.

4. The method as described in claim 2, characterized in that, Based on the high-frequency instruction dictionary and the constructed security rules, the target task process and the files to be updated are autonomously updated in isolation according to control instructions, resulting in updated target task process and full-stage execution status data, including: The control instruction to be executed is structured and parsed according to the high-frequency instruction dictionary to obtain the instruction index and corresponding personalized parameters; The command template is searched for in the dictionary according to the instruction index, and the command template is filled with placeholders and combined according to the parameter mapping rules to obtain the final executable command to be executed in sequence. The final executable command is validated according to security rules to obtain the command execution permission determination result; if the validation fails, an error receipt containing the reason for the failure is generated and the update is terminated. The final executable command, after passing the legality verification, is updated in an isolated manner to obtain the target task process and full-stage execution status data that have been updated.

5. The method as described in claim 4, characterized in that, The isolated autonomous update of the final executable command after validity verification, to obtain the updated target task process and full-stage execution status data, includes: A separate subprocess is created based on the on-orbit autonomous update procedure to execute the final executable command; Based on the target task process name in the personalized parameters, the list of currently running subprocesses is queried and filtered to obtain a list of PIDs that match the target task. The process attributes corresponding to the selected target PID are compared and verified. After confirming that the target PID completely matches the task to be updated, the target task process is stopped according to the preset termination policy. The file to be updated is overwritten and replaced with the original file at the target path, and the integrity of the replaced target file is verified. If the verification fails, a file rollback operation is performed to restore the original file and return the replacement failure information. The target file that has passed the verification is updated and restarted according to the preset startup command, and the survival status and function of the target task process after restarting are verified to obtain the update execution status data.

6. The method as described in claim 5, characterized in that, Based on the execution status data, the entire update process and update results are monitored to obtain a complete update process record for monitoring and tracing, including: Based on the execution status data obtained from each update, key information of each stage of the update execution is recorded and processed in real time to obtain a complete update process log. The process log includes session identifier, instruction index, process name, PID, file path, verification result, stage status, return code, and timestamp. Based on the final result of the update execution, the fault information in the update failure scenario is extracted and additionally processed to obtain an error feedback message containing the failure stage location and core log summary; The process logs and error feedback messages are packaged according to a preset format and transmitted back to the ground to obtain an updated full process record.

7. An on-orbit autonomous update device for space missions, characterized in that, The device includes: The initialization module is used to initialize and configure the heterogeneous computing platform architecture built by high-reliability computing units and Linux high-performance computing units, and define the rules to obtain a basic operating system that includes cross-unit communication links and a high-frequency instruction dictionary. The verification module is used to reliably transmit, verify, and reassemble the update files and control commands sent from the ground according to the communication link and the constructed data verification rules, so as to obtain complete and verified update files and control commands to be executed. The update module is used to perform isolated autonomous updates on the target task process and the file to be updated according to the high-frequency instruction dictionary and the constructed security rules, and to obtain the updated target task process and full-stage execution status data. The monitoring module is used to monitor the entire update process and update results based on the execution status data, and obtain a full update process record for monitoring and tracing.

8. A computer device, characterized in that, The computer device includes a memory and a processor. The memory is used to store computer programs, and the processor is used to execute the computer programs stored in the memory to implement the steps of the method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the steps of the method described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the steps of the method according to any one of claims 1-6.

Images