Satellite-borne containerization reasoning system supporting breakpoint continuous running through dual-computer fault switching

Abstract

The invention provides a satellite-borne containerized reasoning system supporting breakpoint continuous running through dual-computer fault switching, and the system is configured as follows: a first satellite-borne device accesses an image set stored in a shared directory, and images in the image set are processed in sequence by using a first reasoning program; before processing is started each time, a task starting mark under the shared directory is changed into a task which is started to run; the operation is executed after a predetermined amount of images are processed every time: the processing result of the currently processed image is stored, the identification code of the last image processed this time is written into the breakpoint record file in the shared directory, and the current timestamp is written into the state file; and the second satellite-borne equipment runs the daemon process, whether the processing process of the first satellite-borne equipment is down or not is determined by periodically checking a task starting mark and a state file, if yes, the task is automatically taken over, the image is continuously processed from the breakpoint according to the breakpoint recording file by using the second reasoning program, and the continuous running capability of the system in the satellite-borne scene is improved.

Description

Technical Field

[0001] This invention relates to the field of spaceborne computing technology, specifically to the field of artificial intelligence and spaceborne edge computing technology, and more specifically, to a spaceborne containerized inference system that supports breakpoint resumption through dual-machine fault switching. Background Technology

[0002] With the rapid development of deep learning and computer vision technologies, object detection algorithms based on convolutional neural networks have been widely used. The YOLO (You Only Look Once) series of algorithms, especially YOLOv5, has achieved a good balance on edge computing devices due to its high efficiency and real-time characteristics, becoming one of the mainstream methods in the current field of object detection.

[0003] In terms of hardware platforms, spaceborne edge intelligent devices typically employ a combination of CPUs and dedicated neural network acceleration chips to meet the demands of efficient inference. Intelligent acceleration cards can significantly improve the inference efficiency of deep learning models, and when combined with high-performance general-purpose CPUs, they enable the rational allocation and collaborative operation of computing resources. Furthermore, the introduction of containerization technologies such as Docker makes application deployment on edge devices more flexible and convenient. Container technology not only ensures environmental consistency but also improves system maintainability and scalability.

[0004] The field of edge intelligent image processing has developed a relatively mature hardware and software integration technology system, which can meet the requirements of real-time performance and accuracy to a certain extent. However, the stability and fault recovery capabilities of spaceborne systems in the harsh space environment still pose certain challenges in complex spaceborne application scenarios and need further improvement.

[0005] It should be noted that the background information presented here is only for illustrating relevant information about the present invention to aid in understanding the technical solution of the present invention, and does not imply that the relevant information is necessarily prior art. The relevant information was submitted and disclosed together with the present invention, and should not be considered prior art unless there is evidence that the relevant information was disclosed before the filing date of the present invention. Summary of the Invention

[0006] Therefore, the purpose of this invention is to overcome the shortcomings of the prior art and provide a spaceborne containerized image inference system, comprising: a first spaceborne device, which serves as a host and is configured to perform image processing tasks using a first inference program deployed in a first container; a second spaceborne device, which serves as an NFS server and a backup machine for the first spaceborne device, and is configured to provide a shared directory to the first spaceborne device via an NFS file-sharing mechanism, wherein the second spaceborne device deploys a daemon process, a second container built based on the same image as the first container, and a second inference program deployed in the second container that is the same as the first inference program; the system is configured such that the first spaceborne device accesses data stored in the shared directory. An image set is processed sequentially using a first inference program. Before each processing session, the task start flag in the shared directory is changed to indicate that the task has started. After processing a predetermined number of images, the following operations are performed: saving the processing results of the currently processed images, writing the recognition code of the last image processed to a breakpoint log file in the shared directory, and writing the current timestamp to the status file. A daemon process runs on a second onboard device, which periodically checks the task start flag and status file to determine if the first onboard device's processing has failed. If so, it automatically takes over the task and continues image processing from the breakpoint using the second inference program based on the breakpoint log file. This scheme achieves at least the following beneficial technical effects: Avoiding resource waste: Persistently saving task progress ensures that processing can continue from the breakpoint after fault recovery, avoiding redundant inference. Achieving high availability deployment: Supporting automatic switching between primary and backup machines provides strong fault tolerance and improves the system's continuous operation capability in real-world scenarios. Enhancing system robustness: Determining whether a failure has occurred based on the status file and breakpoint log file makes takeover judgment more accurate, avoiding misjudgments and omissions. Easy to deploy and maintain: Containerized deployment methods are standardized and easy to copy, migrate and maintain, making them suitable for industrial deployment needs.

[0007] Optionally, the second onboard device is configured to: consider the first onboard device to have crashed when the task start flag indicates that the task has started running and the time difference between the timestamp in the status file and the current time exceeds a preset time threshold; consider the first onboard device not to have crashed when the task start flag indicates that the task has started running and the time difference between the timestamp in the status file and the current time is less than or equal to the preset time threshold. This scheme can achieve at least the following beneficial technical effects: this scheme combines the task start flag and the timestamp in the status file to determine whether the first onboard device has abnormally exited, and takes over in a timely manner when it crashes, while avoiding misjudgment and incorrect takeover.

[0008] Optionally, after the first onboard device has finished processing all images in the image set, it immediately clears the breakpoint log file and updates the task start flag to indicate that the task has been successfully completed. This solution can achieve at least the following beneficial technical effects: it updates the breakpoint file and task start flag immediately upon task completion, avoiding misjudgments.

[0009] Optionally, initially, the task start flag is set to "task not started".

[0010] Optionally, the second onboard device is configured to first check the task start flag each time. If the task start flag indicates that the task has not started or has ended normally, the status file is not checked again; if the task start flag indicates that the task has started, the status file is checked again. This solution can achieve at least the following beneficial technical effects: it dynamically adjusts the frequency at which the daemon checks the task start flag and status file to set the check cycle according to specific circumstances, thus saving energy.

[0011] Optionally, based on changes in the mission initiation flag, the second onboard device dynamically adjusts the frequency at which the daemon process checks the mission initiation flag and status files. This solution achieves at least the following beneficial technical effects: it dynamically adjusts the frequency at which the daemon process checks the mission initiation flag and status files to set the check cycle according to specific circumstances, thus saving energy.

[0012] Optionally, when the task startup flag indicates the task has not started, the frequency at which the daemon checks the task startup flag and status file is set to a first frequency; when the task startup flag indicates the task has started, the frequency at which the daemon checks the task startup flag and status file is set to a second frequency, where the second frequency is higher than the first frequency. This scheme can achieve at least the following beneficial technical effects: when the task has not started, it uses lower detection rates to save energy; when the task has started, it uses a higher frequency to take over the task more quickly in case of anomalies, avoid long-term task interruptions, and better ensure task processing efficiency.

[0013] Optionally, when the task start flag indicates that the task has ended normally, the frequency at which the daemon checks the task start flag and status file is set to a third frequency, where the first frequency ≤ the third frequency < the second frequency. This scheme can achieve at least the following beneficial technical effects: when the task has ended normally, the scheme uses a lower detection frequency to save energy; when the task has started running, a higher frequency is used to take over the task more quickly in case of anomalies, avoid long-term task interruptions, and better ensure task processing efficiency.

[0014] Optionally, the image processing task can be either an image classification task or an object detection task.

[0015] Optionally, the system is installed on the satellite, and an interruption signal is introduced before satellite launch to simulate a system crash and test its fault tolerance capabilities. This approach can achieve at least the following beneficial technical effects: it conducts fault tolerance testing before launch to ensure that the system's fault tolerance capabilities can operate normally. Attached Figure Description

[0016] The embodiments of the present invention will be further described below with reference to the accompanying drawings, wherein:

[0017] Figure 1 This is a schematic diagram of the system operation structure and deployment environment according to an embodiment of the present invention;

[0018] Figure 2 This is a schematic diagram of the image processing flow of machine A according to an embodiment of the present invention;

[0019] Figure 3 This is a schematic diagram of the machine B protection and monitoring process according to an embodiment of the present invention;

[0020] Figure 4 This is a schematic diagram of the master and backup machine cooperative operation when machine A does not fail, according to an embodiment of the present invention.

[0021] Figure 5 This is a schematic diagram of the sequence of primary and backup machines operating in coordination when machine A fails, according to an embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the invention.

[0023] As mentioned in the background section, the stability and fault recovery capabilities of spaceborne systems in harsh space environments still present certain challenges in complex spaceborne application scenarios and require further improvement. In spaceborne application scenarios where image inference systems are deployed based on intelligent accelerator card platforms (such as real-time target monitoring by Earth remote sensing satellites), the inventors found that large-scale image processing tasks often have long execution times and large data volumes. Once the spaceborne computer crashes or the container exits abnormally, the task will be completely interrupted, the completed parts will be lost, and it will need to be restarted from scratch. This not only wastes a lot of computing resources but also seriously affects system availability and business continuity. In particular, research has revealed the following drawbacks in actual deployment:

[0024] (1) Lack of automatic takeover mechanism between primary and backup systems: Especially in spaceborne remote sensing missions, data transmission bandwidth is limited, and real-time processing and data integrity are crucial. Most current target detection deployment systems operate in stand-alone mode or rely solely on manual fault recovery. Once the spaceborne computer host machine crashes or the spaceborne main computer experiences a single-event upset or other fault, or the target container terminates abnormally, the system mission will be unable to continue running. During operation, problems such as mission interruption and image loss occur frequently, seriously affecting the continuity of the processing flow and data integrity.

[0025] (2) Container-run tasks lack the ability to resume from breakpoints: Image inference tasks such as YOLOv5 take a long time to run on large-scale datasets such as COCO. Existing systems usually infer the entire dataset from scratch and cannot record the progress of processing. When the system restarts or is interrupted, the completed part needs to be repeated, resulting in wasted resources and time.

[0026] (3) The host computer's status detection mechanism is inadequate and cannot trigger failover in a timely manner: Most current systems focus on model inference itself and do not adequately monitor the health status of the host computer (hereinafter referred to as the host). For example, in inference tasks deployed in Docker containers, there is a lack of a real-time status update mechanism, which means that in the event of a crash or no response, the host cannot be automatically detected and the standby machine cannot be quickly triggered to take over. In a space environment, any crash or interruption means the failure of critical tasks or the loss of data.

[0027] In summary, current edge inference systems still have significant shortcomings in terms of high availability, task continuity assurance, and container-level fault tolerance, making it difficult to meet the actual needs of long-term unattended operation or uninterrupted critical tasks.

[0028] To address the above technical challenges, this invention proposes a design concept for "a spaceborne containerized image inference system supporting breakpoint resumption and fault switching," and constructs a primary and backup container collaborative processing mechanism. The entire formation process includes the following key stages:

[0029] (1) Identify existing problems: During use, it was found that the original system had core problems such as "lack of automatic takeover mechanism between main and backup systems", "lack of breakpoint resume capability for container running tasks" and "imperfect host status detection mechanism". To solve these problems, it is necessary to implement functions such as saving image processing progress, file sharing, and immediate takeover by backup machine when the host encounters a fault.

[0030] (2) Design a breakpoint resume mechanism: embed a processing progress recording module in the inference program. After each image is processed, its identification code (such as number and name) is immediately written to the breakpoint record file, and the timestamp in the status file is updated at the same time. The mechanism supports automatic writing of the final breakpoint in the event of abnormal interruption of the container (such as using Ctrl+C to simulate abnormal interruption in the Linux operating system to force the interruption of the task, or simulating machine crash when the machine is powered off) to ensure that there are no omissions.

[0031] (3) Construct a primary-backup collaboration mechanism: Deploy a daemon process (script) in the container of the backup host to continuously monitor the timestamp and task start flag written to the status file by the host. When the task start flag indicates that the host task has started normally and the timestamp has exceeded the set time threshold without being updated, the backup machine determines that the host has crashed and automatically takes over. The backup machine can continue to process tasks from the breakpoint to ensure that there is no interruption, no duplication, and no loss of images.

[0032] According to one embodiment of the present invention, for simplicity, the first spaceborne device will be referred to as machine A and the second spaceborne device as machine B. See also Figure 1 A spaceborne containerized image inference system is provided, comprising: machine A, which acts as the host and is configured to perform image processing tasks using a first inference program deployed in a first container; and machine B, which acts as an NFS server and a backup machine for machine A, configured to provide a shared directory to machine A via an NFS file-sharing mechanism. Machine B has a daemon process deployed thereon, a second container built based on the same image as the first container, and a second inference program deployed in the second container that is identical to the first inference program. The system is configured such that: machine A accesses an image set stored in the shared directory, processes the images in the image set sequentially using the first inference program, changes the task start flag in the shared directory to "task started" before each processing session, and performs the following operations after processing a predetermined number of images: saving the processing results of the currently processed images, writing the identification code of the last image processed in this session to a breakpoint log file in the shared directory, and writing the current timestamp to a status file; machine B runs the daemon process, periodically checking the task start flag and status file to determine if machine A's processing has crashed. If so, machine B automatically takes over the task and continues image processing from the breakpoint using the second inference program based on the breakpoint log file. Optionally, the identification code can be an image sequence number (such as video number + frame number), or an image sequence number and image name. The predetermined quantity can be 1, 2, or 5 images, etc., as defined by the implementer.

[0033] As an illustration, the CPUs of machines A and B can be Hygon C86, and can also be equipped with intelligent accelerator cards such as Neural Processing Units (NPUs) or Machine Learning Processing Units (MLUs), like the Cambricon MLU370. Machines A and B run a Linux operating system that supports Docker containers. The operating system layer can be Ubuntu 22.04, providing NFS service and the Docker engine. Both machines A and B have independent Docker containers built on the same custom image. These containers can be Docker containers created using the MagicMind image, with the base image being the Ubuntu 18.04 Docker image provided by MagicMind. The consistent container image source ensures seamless task continuation after a switchover between machines A and B. If used for object detection tasks, this image can integrate the following resources to support object detection tasks: MagicMind SDK (including runtime and compiler), Python environment, C++ environment, NFS mounted shared directory, pre-trained object detection model (such as YOLOv5 model), COCO dataset, related scripts and programs, and other MagicMind folder mounts (such as logs, temporary files, etc.).

[0034] Optionally, the primary and backup machines maintain state synchronization via an NFS file-sharing mechanism. To ensure high availability and stability, machine B acts as the NFS server, and machine A acts as the client, mounting the shared directory ` / home / ict / shared_dir` for reading and writing task status files, including `progress.txt` (corresponding to the breakpoint log file), `status.txt` (corresponding to the status file), and `start.txt` (corresponding to the task start flag). When machine A crashes due to an abnormal interruption or power failure, machine B can determine the status of machine A based on the contents of the files in the mounted shared directory and automatically take over the tasks.

[0035] According to one embodiment of the present invention, machine B is configured to: consider machine A to have crashed when the task start flag indicates that the task has started running and the time difference between the timestamp in the status file and the current time exceeds a preset time threshold; consider machine A not to have crashed when the task start flag indicates that the task has started running and the time difference between the timestamp in the status file and the current time is less than or equal to the preset time threshold. For example, the preset time threshold can be set to 500ms, 1s, 2s, or 3s, etc. Assuming the preset time is 1s, machine B reads the current time when the task has started running, subtracts the latest timestamp in the status file from the current time to obtain the time C. If the time C is less than or equal to 1s, machine A is considered not to have crashed; otherwise, machine A is considered to have crashed, i.e., an anomaly has occurred and the task has not been processed normally. This scheme can at least achieve the following beneficial technical effects: this scheme combines the task start flag and the timestamp in the status file to determine whether machine A has abnormally exited, and takes over in a timely manner when it crashes, while avoiding misjudgment and incorrect takeover.

[0036] According to one embodiment of the present invention, after machine A has finished processing all images in the image set, it immediately clears the breakpoint log file and updates the task start flag to indicate that the task has been completed normally. After machine A has finished processing all images in the image set, it can also clear the timestamps in the status file or set them to default values ​​to prevent errors in the next task. However, this solution at least achieves the following beneficial technical effects: it updates the breakpoint file and task start flag immediately upon task completion, avoiding misjudgments.

[0037] According to one embodiment of the present invention, the task start flag includes flag 0, flag 1, and flag 2. Initially, the task start flag is set to flag 0, indicating that the task has not started, that is, the task has not yet started, and machine A has not yet started the image processing flow. If the task starts processing, the task start flag is set to flag 1, indicating that the task has started running, that is, the task has started and is running, and machine A is in the image inference execution stage. If the task has completed processing, the task start flag is set to flag 2, indicating that the task has ended normally, that is, machine A's task has been successfully completed, all image processing is finished, and the standby machine does not need to take over. The task start flag (or status flag signal) mainly records the task's running stage information, used by the primary and standby machines to determine whether the task has started, is in progress, or has been completed. Through these three status values, the standby machine can accurately determine the current task's progress and, in conjunction with the timestamp and breakpoint file, decide whether to perform takeover. Machine B is configured to check the task start flag first each time. If the task start flag shows that the task has not started running or the task has ended normally, then the status file is no longer checked; if the task start flag shows that the task has started running, then the status file is checked again. This solution can achieve at least the following beneficial technical effects: it dynamically adjusts the frequency of the daemon process checking the task startup flag and status file, so as to set the check cycle according to the specific situation and save energy.

[0038] According to one embodiment of the present invention, machine B dynamically adjusts the frequency at which the daemon process checks the task startup flag and status file based on changes in the task startup flag. When the task startup flag indicates that the task has not started, the frequency at which the daemon process checks the task startup flag and status file is set to a first frequency; when the task startup flag indicates that the task has started, the frequency at which the daemon process checks the task startup flag and status file is set to a second frequency, wherein the second frequency is higher than the first frequency. The first frequency (not started) is set to check once every 10 seconds, while the second frequency (started) is set to check once every 1 second. The second frequency is 10 times the first frequency, ensuring that the task startup can be detected in seconds and reducing CPU and disk I / O to 1 / 10 during the idle phase. This scheme can achieve at least the following beneficial technical effects: the scheme dynamically adjusts the frequency at which the daemon process checks the task startup flag and status file to set the check cycle according to specific circumstances, saving energy; the scheme uses lower detection frequency when the task has not started to save energy; and the scheme uses higher frequency when the task has started to take over the task more quickly in case of anomalies, avoiding long-term task interruptions and better ensuring task processing efficiency.

[0039] According to one embodiment of the present invention, when the task start flag indicates that the task has ended normally, the frequency at which the daemon checks the task start flag and status file is set to a third frequency, wherein the first frequency ≤ the third frequency < the second frequency. For example, the first frequency (not started) is set to check once every 10 seconds, the second frequency (started) is set to check once every 1 second, and the third frequency is set to check once every 5 seconds. This scheme can achieve at least the following beneficial technical effects: when the task has ended normally, the scheme uses a reduced detection frequency to save energy; when the task has started running, a higher frequency is used to take over the task more quickly in case of anomalies, avoid long-term task interruption, and better ensure task processing efficiency.

[0040] According to an example of the present invention, the following describes the collaborative processing mechanism between machine A and machine B. In the entire image (also known as picture) processing flow, machine B acts as a backup machine, monitoring the status of machine A (the master machine) in real time through a guardian mechanism. In case of an anomaly, machine B takes over the processing tasks, ensuring the integrity and robustness of the tasks. The following description covers three aspects: machine A's processing logic, machine B's monitoring and takeover logic, and the master-slave collaborative operation logic.

[0041] (1) Machine A image processing logic

[0042] The image processing script runs inside container A, and is divided into three stages: initialization, batch processing execution, and task termination. Figure 2 As shown. The illustrative execution logic is as follows:

[0043] Initialization phase: When executing the task, determine whether it is the first time to process an image. If so, write 1 to the task start flag in the shared directory (the initial value is 0, indicating that machine A has not started executing the task), indicating that the task has started running in machine A. At the same time, record the processing progress (first image number and image name) to the breakpoint log file and update the timestamp to the status file periodically.

[0044] Image processing stage: The system sequentially reads the next image to be processed, performing preprocessing, inference, and post-processing operations. Upon successful processing of each image, the breakpoint log file and status file are immediately updated to ensure that the task progress and running status are externally perceptible.

[0045] Task completion phase: If machine A has finished processing all images, the breakpoint log file will be cleared and the value in the task start flag will be updated to 2 (indicating that machine A has successfully completed the task), releasing the possibility of the standby machine taking over.

[0046] (2) Monitoring and takeover logic of machine B

[0047] The daemon script (i.e., daemon process) of machine B always runs in the background, periodically reading the file status in the shared directory to determine whether machine A has crashed abnormally. Its operation process is as follows: Figure 3 As shown. Its monitoring and takeover logic is as follows:

[0048] Continuously monitor the startup status: Continuously read the task startup flag to determine whether task A on machine has started running (when the value is 1). If it is another value such as 0 or 2 (0 indicates that task A on machine has not started running, 2 indicates that task A on machine has completed successfully), then continue to listen and wait.

[0049] Anomaly detection logic: If the task start flag is 1 (indicating that the task on machine A has started) and the timestamp in the status file has not been updated for a long time, then machine A is determined to have crashed abnormally.

[0050] Take over task execution: Read the breakpoint log file to obtain the current breakpoint position, resume processing from the image breakpoint, and execute the same preprocessing, inference, and postprocessing process as machine A.

[0051] Task completion processing: After the task is completed, machine B will also clear the breakpoint log file and set the task start flag to 2 to indicate that the task has been completed and avoid misjudgment.

[0052] (3) When machine A does not malfunction and the task can be completed normally, the overall task flow coordination timing relationship is as follows: Figure 4 As shown; when machine A experiences an interruption or crash, the overall task flow's collaborative timing relationship is as follows: Figure 5 As shown in the image, the interaction logic between machine A, machine B, and the shared directory at different stages is illustrated.

[0053] Initialization Phase: The user starts the daemon script on machine B and enters listening mode. Then, it initializes the task start flag in the shared directory to 0, indicating that machine A has not yet started executing tasks, and starts the image processing task on machine A. Normal Processing Phase: After processing the first image, machine A updates the task start flag to 1, indicating that machine A has started the normal processing flow. Afterward, for each image processed, it immediately updates the breakpoint log file and the status file. The breakpoint log file contains the sequence number and name of the currently processed image, and the status file contains the current timestamp. Machine B periodically reads these files to determine whether it needs to take over.

[0054] Abnormal downtime phase: If machine A crashes and the timestamp in the status file has not been updated for a long time, and there are recorded breakpoints in the breakpoint save file and breakpoint record file, machine B will automatically identify and execute task takeover, continuing to execute the task from the breakpoint recorded in the breakpoint record file.

[0055] Task completion phase: If machine A successfully completes the image processing task without unexpected crashes during task execution, the program in machine A will clear the breakpoint log file and set the task start flag to 2, indicating that the task process has ended normally, preventing the task from being processed repeatedly or mistakenly taken over; if the task is taken over and completed by machine B, the program in machine B will finally set the task start flag to 0 so that the next task can be started.

[0056] According to one embodiment of the present invention, deployment and verification tests can also be performed before the system is launched with a satellite. For example, the system runs on two heterogeneous hardware platforms using high-performance general-purpose CPUs and intelligent accelerator cards (NPUs), with primary and backup containers deployed on the machines and a shared directory (NFS) mounted. During testing, key technical challenges such as model version compatibility, Docker container and host machine state synchronization, and NFS access permission conflicts were resolved. This invention, starting from the image inference scenario and closely addressing the fault tolerance requirements of actual deployment, successfully completed multiple rounds of image inference tests in a real deployment environment. During testing, Ctrl+C was used for software interrupt testing, and hardware-level crash testing was also conducted by powering off the machine. The tests showed that the present invention effectively supports the continuous operation of the system under power outages and operating system crashes, verifying the engineering practicality and technical feasibility of the solution.

[0057] In summary, some embodiments of the present invention can achieve at least one of the following effects:

[0058] (1) Integrated design of breakpoint resume and automatic switching to avoid resource waste: The breakpoint recording and exception recovery functions are integrated in the container to realize the reasoning process without interruption, duplication and missing diagrams; the task progress is persistently saved to ensure that the process can continue from the breakpoint after the fault is recovered, avoiding repeated reasoning.

[0059] (2) Achieve high availability deployment: Supports automatic switching between primary and backup machines, has strong fault tolerance, and improves the system's continuous operation capability in real-world scenarios.

[0060] (3) Enhance system robustness: Based on status files and breakpoint log files, it can determine whether a crash has occurred, making takeover judgment more accurate and avoiding misjudgment or omission.

[0061] (4) Easy to deploy and maintain: Containerized deployment methods are standardized and easy to copy, migrate and maintain, and are suitable for industrial deployment needs.

[0062] (5) Downtime detection and judgment mechanism based on status log file: Combine the task start flag signal, the timestamp in the status file and the breakpoint recorded in the breakpoint log file to judge whether the host has exited abnormally, and avoid misjudgment and wrong takeover.

[0063] (6) Cross-host task state sharing mechanism: NFS mounting is used to realize state and breakpoint file sharing, ensuring consistency between primary and standby containers in state awareness and data reading.

[0064] (7) Verification mechanism supports fault tolerance test: interrupt signal is introduced to simulate abnormal termination scenario, and the power is cut off to machine A to simulate the crash caused by hard machine abnormality. The system showed good automatic recovery and task continuation capabilities in the test.

[0065] It should be noted that although the steps are described in a specific order above, it does not mean that the steps must be executed in the above specific order. In fact, some of these steps can be executed concurrently, or even in a different order, as long as the required function can be achieved.

[0066] This invention can be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement various aspects of the invention.

[0067] Computer-readable storage media can be tangible devices that hold and store instructions for use by an instruction execution device. Computer-readable storage media can include, for example, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof.

[0068] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A spaceborne containerized image inference system, comprising: The first onboard device, which acts as the host, is configured to perform image processing tasks using a first inference program deployed in a first container. The second onboard device, which serves as an NFS server and a backup for the first onboard device, is configured to provide a shared directory to the first onboard device via the NFS file sharing mechanism. It has a daemon, a second container built on the same image as the first container, and a second inference program deployed in the second container that is the same as the first inference program. The system is configured as follows: The first onboard device accesses the image set stored in the shared directory, and uses the first inference program to process the images in the image set in sequence. Before each processing starts, the task start flag in the shared directory is changed to "task has started running". After processing a predetermined number of images, the following operations are performed: save the processing results of the currently processed images, write the identification code of the last image processed in this session into the breakpoint record file in the shared directory, and write the current timestamp into the status file. The second onboard device runs a daemon process that periodically checks the task start flag and status file to determine if the first onboard device's processing has crashed. If so, it automatically takes over the task and uses the second inference program to continue processing the image from the breakpoint based on the breakpoint log file.

2. The system according to claim 1, characterized in that, The second onboard equipment is configured as follows: When the task start flag indicates that the task has started running and the time difference between the timestamp in the status file and the current time exceeds a preset time threshold, the first onboard device is considered to have crashed. The first satellite-borne device is considered not to have crashed when the task start flag indicates that the task has started running and the time difference between the timestamp in the status file and the current time is less than or equal to a preset time threshold.

3. The system according to claim 2, characterized in that, After the first onboard device has finished processing all the images in the image set, it immediately clears the breakpoint log file and updates the mission start flag to indicate that the mission has been completed normally.

4. The system according to claim 3, characterized in that, Initially, the task start flag is set to "task not started".

5. The system according to claim 4, characterized in that, The second onboard device is configured to first check the mission initiation flag each time, wherein... If the task start flag indicates that the task has not started or has ended normally, the status file will not be checked again. If the task start flag indicates that the task has started running, continue checking the status file.

6. The system according to claim 3, characterized in that, Based on the changes in the mission initiation flag, the second onboard equipment dynamically adjusts the frequency at which the daemon checks the mission initiation flag and status files.

7. The system according to claim 6, characterized in that, When the task startup flag is "task not started", the frequency at which the daemon checks the task startup flag and status file is set to the highest frequency. When the task start flag indicates that the task has started running, the frequency at which the daemon checks the task start flag and status file is set to a second frequency, which is higher than the first frequency.

8. The system according to claim 7, characterized in that, When the task start flag indicates that the task has ended normally, the frequency at which the daemon checks the task start flag and status file is set to the third frequency, where the first frequency ≤ the third frequency < the second frequency.

9. The system according to any one of claims 1-8, characterized in that, Image processing tasks include image classification tasks and object detection tasks.

10. The system according to any one of claims 1-8, characterized in that, The system is installed on the satellite, and an interruption signal is introduced before the satellite launch to simulate a system crash and test the system's fault tolerance capability.

Images