Deployment method and system for a launch vehicle

By deploying multi-zone system and health monitoring software in the launch vehicle, monitoring and dynamically voting the system status in real time and performing long-range recovery when startup fails, the problem of lack of abnormal monitoring and automatic recovery in the launch vehicle is solved, and the system's high reliability and automatic recovery capabilities are achieved.

CN119311286BActive Publication Date: 2025-06-10ORIENTAL SPACE TECH (SHANDONG) CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411856333.4
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-12-17
Publication Date
2025-06-10
Estimated Expiration
2044-12-17

AI Technical Summary

Technical Problem

The prior art lacks effective abnormal monitoring and automatic recovery functions in launch vehicles, which makes it difficult to accurately locate and solve problems when starting abnormalities, increases maintenance difficulty, and does not have automatic recovery functions when starting failure, resulting in long-term downtime.

Method used

By designing storage partitions for multi-partition system files, deploying health monitoring software to monitor hardware and software status in real time, voting and health monitoring of system startup status, calculating the confidence of each partition based on functional importance indicators and performing dynamic voting, and remotely recovering through FTP when the system cannot start normally.

Benefits of technology

The system is achieved with high reliability and stability, and an automatic recovery mechanism is provided, which reduces the on-site work burden of maintenance personnel, shortens the system recovery time, and reduces the risk of startup failure by intelligently selecting the most reliable startup file.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119311286B_ABST
    Figure CN119311286B_ABST
Patent Text Reader

Abstract

The present invention discloses a deployment method and system for a launch vehicle, specifically related to the field of operating system deployment. The present invention designs storage partitions through multi-partition system files; secondly, a health monitoring software is deployed to monitor the status of hardware and software in real time. After the device is powered on and starts up, the system sequentially boots the image files of three system partitions, and records the startup status after each startup; if the system gets stuck or encounters abnormal situations during startup, the monitoring software automatically processes them. Finally, the confidence level of each partition is calculated based on the functional importance index and dynamic voting is performed to determine the most reliable system version as the default startup system. When all image files cannot be started normally, the system enters the remote recovery mode, and downloads a temporary system image through an FTP connection for redeployment and recovery.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the technical field of operating system deployment, and more specifically, to a deployment method and system for a launch vehicle. Background Art

[0002] In the aerospace field, embedded operating systems are widely used in key control components such as satellites, aircraft, rockets, and spacecraft; due to their high reliability and real-time performance, these embedded systems can optimize resources and support tasks such as attitude control, navigation, communication, and fault detection of spacecraft. However, in the application of launch vehicles, the requirements for the reliability and stability of embedded operating systems are particularly stringent, because the success of system loading and startup is directly related to the success or failure of flight missions.

[0003] In the existing spacecraft system startup methods, some have achieved multi-mode boot, but do not provide effective anomaly monitoring and automatic recovery functions; others have introduced a simple restart mechanism, but do not cover multi-partitioning and failover strategies.

[0004] When these solutions are actually used, in the case of abnormal startup, the system lacks monitoring means, and it is difficult to accurately locate and solve problems; once the startup fails, it is necessary to disassemble the equipment or even the circuit board to perform further debugging, increasing the maintenance difficulty; the current system has no automatic recovery function in the case of abnormal startup, resulting in long-term downtime. Summary of the Invention

[0005] In order to overcome the above-mentioned defects of the prior art, an embodiment of the present invention provides a deployment method for a launch vehicle to solve the problems raised in the above background art.

[0006] To achieve the above object, the present invention provides the following technical solutions:

[0007] Step A1: Perform storage partition design on multi-partition system files;

[0008] Step A2: Deploy health monitoring software and monitor the hardware and software status in real time;

[0009] Step A3: Vote on the system startup status and perform health monitoring;

[0010] Step A4: Calculate the confidence level of each partition based on the function importance index after multi-partition startup and perform dynamic voting;

[0011] Step A5: Recover and redeploy the system.

[0012] Preferably, in the step A1, the storage partition design includes a system partition and a log partition;

[0013] Among them, the system partition contains three operating system images. When one system file fails, the system can switch to other images;

[0014] The log partition records key events and status changes during the system startup process, such as hardware detection, driver loading, service startup, etc.

[0015] These logs help to understand the system startup process and provide clues for troubleshooting when problems occur; record the fault events that occur in the system, including the fault type, occurrence time, and affected scope; provide log analysis tools to parse, filter, and search the log data; regularly back up the log data to prevent data loss or corruption; compress the old logs to save storage space; regularly clean up the expired log data to keep the log partition clean and efficient.

[0016] Preferably, in step A2, the health monitoring software classifies the detected anomalies into three categories, including module-level errors, partition-level errors, and process-level errors;

[0017] The health monitoring software is deployed to the device internal memory through the serial port method and loaded and run by the U-Boot program. When it detects an abnormal system startup, it records and executes the anomaly handling;

[0018] When the health monitoring software detects an anomaly, it immediately records the anomaly information, records the anomaly information in a log file, and determines the anomaly type based on the anomaly information to determine the corresponding handling strategy; executes the corresponding anomaly handling operation according to the handling strategy. After the anomaly handling is completed, it attempts to restore the system to the normal running state; reports the anomaly information and handling results to the system administrator or relevant maintenance personnel so that they can understand the system status and take further measures.

[0019] Preferably, in step A3, after the device is powered on and started, the system sequentially boots the image files of the three system partitions; after each startup, the health monitoring software records the startup status. If the startup process gets stuck or abnormal, the monitoring software automatically performs the following processing:

[0020] Restart and switch to the next system image: If the current partition fails, it will immediately trigger a restart operation and automatically switch to the next system image file for startup.

[0021] This process is automated and does not require manual intervention;

[0022] Determination of multiple startup failures: If multiple system image files fail to start continuously, the monitoring software will use a three-judgment-two-verdict mechanism to judge the reliability of the system files;

[0023] Specifically, it will count the number of successful startups and failures of each system image file based on the previously recorded startup status; if the number of failures of a certain image file exceeds two, it is considered unreliable;

[0024] The monitoring software will avoid attempting to start that image file again and instead try other reliable image files.

[0025] FTP remote recovery: When all system image files cannot be started properly, the monitoring software will attempt to download the most stable operating system version via an FTP connection for remote recovery deployment;

[0026] During this process, the monitoring software needs to pre-configure connection information such as the address, username, and password of the FTP server; once the connection is successful, it will download the specified operating system image file from the server and write it to the internal memory of the device; after the download is complete, the monitoring software will attempt to restart the system and load the newly downloaded image file.

[0027] Preferably, in step A4, after multi-partition startup, the confidence level of each partition is calculated based on the function importance index, including the following steps:

[0028] Real-time monitor and record the time required for the system to start up completely from power-on: Record the loading status and response time of each key component during startup; Capture and record any errors or abnormalities during startup, including error codes, occurrence times, and related components; Classify and prioritize the errors so that system administrators can quickly locate and solve problems; Store all startup responses and error records in a secure and reliable log file; Provide a convenient log query function that supports filtering and exporting according to conditions such as time range, error type, or component name;

[0029] Partition confidence level assessment: Based on historical startup records, calculate the successful startup rate of each system partition or version; The successful startup rate is defined as the proportion of the number of successful startups to the total number of startups within a certain time window; Statistically analyze the historical failures of each partition or version, including failure types, occurrence frequencies, and repair times; Provide improvement suggestions and optimization measures for system administrators based on the failure analysis results; Combine the successful startup rate and the historical failure analysis results to calculate the confidence level for each partition or version; The confidence level is a dynamic value that will be updated in real time according to new startup records and failure situations;

[0030] Determination of the default startup system and startup of alternative systems: According to the confidence ranking, select the system version with the highest confidence as the default startup system; when the confidence of the default system drops below a preset threshold, automatically trigger the selection and startup process of alternative systems; preset multiple alternative systems and sort them according to confidence; when the default system fails to start, automatically select the alternative system with the highest confidence for startup; provide a function to manually select alternative systems so that system administrators can intervene in specific situations; after the alternative system starts, continue to monitor the system operation status to ensure the stable operation of the system; if new faults or anomalies are found, immediately trigger the corresponding alarm and diagnostic mechanisms so that system administrators can handle them in a timely manner.

[0031] Preferably, in step A5, when all three system image files cannot pass the two-out-of-three decision, the system automatically enters the remote recovery mode; download a temporary system image through an FTP connection so that engineers can redeploy and recover remotely, reducing downtime and ensuring the test progress; the method of the remote recovery mode is specifically as follows:

[0032] Step E1: Configure the FTP connection;

[0033] Step E2: Use the TFTP protocol to download the kernel and system files into memory, start the TFTP client of the device; specify the path and file name of the kernel and system files to be downloaded; start the download process and monitor the download progress; after the download is completed, verify the integrity and correctness of the files;

[0034] Step E3: Set the startup parameters and start the kernel. According to the requirements of the downloaded kernel and system files, set the startup parameters. These parameters may include memory allocation, root file system location, etc.; in the startup manager or recovery mode of the device, specify to start using the downloaded kernel and system files; after confirming that the startup parameter settings are correct, start the kernel; monitor the startup process to ensure that the system can start smoothly and enter the temporary running state.

[0035] The present invention also provides a deployment system for a launch vehicle, using the above-mentioned deployment method for a launch vehicle, and the deployment system includes:

[0036] Storage partition design module: used for designing the storage partition of the multi-partition system files;

[0037] Health monitoring software deployment module: used for deploying health monitoring software and real-time monitoring of the hardware and software status;

[0038] Voting module: used for voting on the system startup status and health monitoring;

[0039] Confidence calculation module: used to calculate the confidence of each partition based on the function importance index after multi-partition startup and perform dynamic voting;

[0040] Recovery module: used to recover and redeploy the system.

[0041] Technical effects and advantages of the present invention:

[0042] 1. By storing three operating system images in multiple partitions, the present invention can quickly switch when a file fails, significantly improving the fault tolerance and stability of the system; without relying on a single backup, it improves the reliability of the system; and through the health monitoring program, it records the anomalies during the system startup process in real time, providing data support for fault troubleshooting and system optimization.

[0043] 2. The present invention provides an automatic recovery mechanism and can download and update system files through FTP remote connection to achieve remote deployment, greatly reducing the on-site work burden of maintenance personnel and shortening the system recovery time;

[0044] 3. Through the three-out-of-two decision mechanism and confidence calculation, the present invention can intelligently select the most reliable startup file, effectively reducing the risk of startup failure, and can automatically switch after multiple failures to ensure the continuous operation of the system. Description of the drawings

[0045] Figure 1 It is a schematic diagram of the method flow of the present invention.

[0046] Figure 2 It is a schematic diagram of the module connection of the present invention. Detailed implementation manners

[0047] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0048] Please refer to Figure 1 As shown, the present invention provides a highly reliable operating system deployment strategy for a launch vehicle, and its method is as follows:

[0049] Step A1: Perform storage partition design on the multi-partition system files;

[0050] In the step A1, the storage partition design includes a system partition and a log partition;

[0051] Among them, the system partition contains three operating system images. When one system file fails, the system can switch to other images;

[0052] The log partition records key events and status changes during the system startup process, such as hardware detection, driver loading, service startup, etc.

[0053] These logs help understand the system startup process and provide clues for troubleshooting when problems occur; record fault events that occur in the system, including fault types, occurrence times, and affected scopes; provide log analysis tools to parse, filter, and search log data; regularly back up log data to prevent data loss or corruption; compress old logs to save storage space; regularly clean up expired log data to keep the log partition clean and efficient.

[0054] Step A2: Deploy health monitoring software and monitor the hardware and software status in real time;

[0055] In the said Step A2, the health monitoring software classifies the detected anomalies into three categories, including module-level errors, partition-level errors, and process-level errors;

[0056] The health monitoring software is deployed to the device's internal memory through the serial port method and loaded and run by the U-Boot program. When it detects system startup anomalies, it records and executes anomaly handling;

[0057] When the health monitoring software detects an anomaly, it immediately records the anomaly information, records the anomaly information in a log file, and determines the anomaly type based on the anomaly information to determine the corresponding handling strategy; executes the corresponding anomaly handling operation according to the handling strategy. After the anomaly handling is completed, it attempts to restore the system to its normal operating state; reports the anomaly information and handling results to the system administrator or relevant maintenance personnel so that they can understand the system status and take further measures;

[0058] Among them, module-level errors affect the entire module, and errors during module initialization and function execution are monitored and recorded;

[0059] Partition-level errors only affect a single partition, and anomalies in partition initialization, process management, etc. are monitored;

[0060] Process-level errors are monitored for a single process and include errors such as process execution, overflow, and storage conflicts.

[0061] Step A3: Vote on the system startup status and perform health monitoring;

[0062] In step A3, after the device is powered on and starts up, the system sequentially boots the image files of three system partitions; after each startup, the health monitoring software records the startup status. If the system gets stuck or encounters abnormal conditions during startup, the monitoring software will automatically perform the following operations:

[0063] Restart and switch to the next system image: If a failure occurs in the current partition, it will immediately trigger a restart operation and automatically switch to the next system image file for startup.

[0064] This process is automated and does not require manual intervention;

[0065] Determination of multiple startup failures: If multiple system image files fail to start up continuously, the monitoring software will use a three-out-of-two decision mechanism to judge the reliability of the system files;

[0066] Specifically, it will count the number of successful startups and failure times of each system image file based on the previously recorded startup status; if the number of failure times of a certain image file exceeds two, it is considered unreliable;

[0067] The monitoring software will avoid attempting to start this image file again and instead try other reliable image files.

[0068] FTP remote recovery: When all system image files cannot start up normally, the monitoring software will attempt to download the most stable operating system version through an FTP connection for remote recovery and deployment;

[0069] During this process, the monitoring software needs to pre-configure connection information such as the address, username, and password of the FTP server; once the connection is successful, it will download the specified operating system image file from the server and write it into the internal memory of the device; after the download is complete, the monitoring software will attempt to restart the system and load the newly downloaded image file.

[0070] Step A4: After multi-partition startup, calculate the confidence level of each partition based on the functional importance index and perform dynamic voting;

[0071] In step A4, calculating the confidence level of each partition based on the functional importance index after multi-partition startup includes the following steps:

[0072] Real-time monitor and record the time required for the system to start up completely: Record the loading status and response time of each key component during startup; Capture and record any errors or exceptions that occur during startup, including error codes, occurrence times, and related components; Classify and prioritize errors so that system administrators can quickly locate and resolve issues; Store all startup responses and error records in a secure and reliable log file; Provide a convenient log query function that supports filtering and exporting based on conditions such as time range, error type, or component name;

[0073] Partition confidence assessment: Based on historical startup records, calculate the successful startup rate for each system partition or version; The successful startup rate is defined as the ratio of the number of successful startups to the total number of startups within a certain time window; Conduct statistical analysis on the historical failures of each partition or version, including failure types, occurrence frequencies, and repair times; Provide improvement suggestions and optimization measures for system administrators based on the failure analysis results; Combine the successful startup rate and historical failure analysis results to calculate the confidence level for each partition or version; The confidence level is a dynamic value that is updated in real time based on new startup records and failure situations;

[0074] Determination of the default startup system and startup of alternative systems: Select the system version with the highest confidence as the default startup system based on the confidence ranking; When the confidence level of the default system drops below a preset threshold, automatically trigger the selection and startup process of alternative systems; Preset multiple alternative systems and sort them according to confidence; When the default system fails to start, automatically select the alternative system with the highest confidence to start; Provide a function to manually select alternative systems so that system administrators can intervene in specific situations; After the alternative system starts, continue to monitor the system running status to ensure that the system can run stably; If new failures or exceptions are found, immediately trigger the corresponding alarm and diagnostic mechanisms so that system administrators can handle them in a timely manner;

[0075] The specific method of the two-out-of-three judgment mechanism in the three-judgment-two ruling mechanism is as follows:

[0076] Step B1: The system sequentially loads three system image files during startup and performs startup detection; The health status after each image file starts is recorded by the health monitoring program, including startup success, abnormal termination, and startup failure status;

[0077] Step B2: When at least two versions start successfully among the startup states of the three image files, the system determines that this version is the current reliable startup file and selects the version with the highest reliability as the default startup file of the system;

[0078] Step B3: When only one version starts successfully or all three versions fail among the three versions, the system enters the fault recovery process to ensure that the system can be restored to a reliable state when it cannot be started locally;

[0079] The method for weight calculation and startup reliability rate statistics in the three-judge-two-verdict mechanism is specifically as follows:

[0080] Step C1: After each system partition starts up successfully, the health monitoring program records the startup status and stores the success, failure, and abnormal results in the log partition;

[0081] Step C2: Different weights are assigned to the startup status of each partition; a weight of 1.0 is given for a successful startup, representing the stability of the partition startup; a weight of 0.5 is given for an abnormal startup, indicating that there is a certain risk in this partition; a weight of 0 (the lowest) is given for a failed startup, representing the state of inability to start;

[0082] Step C3: The startup history of each partition is weighted and averaged to calculate the reliability rate of each system image file. The specific calculation method of the reliability rate is as follows:

[0083] , where represents the startup reliability rate of the i-th system image file; represents the weight of the i-th image file in the j-th startup; represents the status of the i-th image file in the j-th startup, where 1 represents success and 0 represents failure or abnormality; N represents the historical startup times of this image file;

[0084] The method for startup decision-making and switching strategy in the three-judge-two-verdict mechanism is specifically as follows:

[0085] Step D1: When the system powers on and starts up, the health monitoring program first calculates the reliability rate of each image file, and takes the file with the highest reliability rate as the default startup system; if this file cannot be started due to abnormal conditions, the system will automatically switch to the image file with the second-highest reliability rate;

[0086] Step D2: After the system starts up successfully, the system dynamically updates the reliability rate and weights, so that the system default startup file always points to the current most stable image;

[0087] Step D3: If the reliability rate of a certain partition is continuously lower than 50% for a long time, the system marks this image file as a "high-risk version" and enters the remote redeployment process, and replaces the image file of this partition by downloading the most basic and stable version image;

[0088] Step A5: Recover and redeploy the system;

[0089] In step A5, when all three system image files fail the two-out-of-three decision, the system automatically enters the remote recovery mode; download a temporary system image through an FTP connection so that engineers can redeploy and recover remotely, reducing downtime and ensuring the progress of the test; the method of the remote recovery mode is specifically as follows:

[0090] Step E1: Configure the FTP connection;

[0091] Step E11: Set the IP address of the device and enter the network configuration interface of the device; manually set or obtain the IP address of the device automatically through DHCP according to the network environment; after confirming that the device IP address is set correctly, save the configuration and restart the network service;

[0092] Step E12: In the FTP client configuration of the device, enter the IP address of the FTP server; if the FTP server requires authentication, also enter the username and password; test the connection with the FTP server to ensure that the configuration is correct;

[0093] Step E2: Use the TFTP protocol to download the kernel and system files to the memory, start the TFTP client of the device; specify the path and file name of the kernel and system files to be downloaded; start the download process and monitor the download progress; after the download is complete, verify the integrity and correctness of the files;

[0094] Step E3: Set the startup parameters and start the kernel. According to the requirements of the downloaded kernel and system files, set the startup parameters. These parameters may include memory allocation, root file system location, etc.; in the startup manager or recovery mode of the device, specify to start using the downloaded kernel and system files; after confirming that the startup parameters are set correctly, start the kernel; monitor the startup process to ensure that the system can start successfully and enter the temporary running state;

[0095] Among them, the key commands of the remote recovery mode process are specifically as follows:

[0096] # 1. Set the FTP server IP

[0097] set serverip 192.168.1.100

[0098] # 2. Download the new system file (if there have been 2 startup failures)

[0099] tftp 0x40000000 uImage

[0100] # 3. Set the startup parameters and execute the restart and load

[0101] set bootargs root= / dev / nfs nfsroot= 192.168.1.100: / nfs_files / rootfs tcp,v4 rw

[0102] console= / dev / ttySAC0,115200

[0103] saveenv

[0104] bootm 0x40000000。

[0105] The present invention also provides a deployment system for a launch vehicle, which uses a deployment method for a launch vehicle as described above. The deployment system includes:

[0106] A storage partition design module: used for designing the storage partitions of a multi-partition system file;

[0107] A health monitoring software deployment module: used for deploying health monitoring software and real-time monitoring of the hardware and software status;

[0108] A voting module: used for voting on the system startup status and health monitoring;

[0109] A confidence level calculation module: used for calculating the confidence level of each partition based on the functional importance index after multi-partition startup and performing dynamic voting;

[0110] A recovery module: used for recovering and redeploying the system. Embodiment 1

[0111] Suppose the three system startup records are as follows (weight assumption: success = 1.0, anomaly = 0.5, failure = 0):

[0112] The first time: Partition A is successful, Partition B is anomalous, and Partition C fails;

[0113] The second time: Partition A is successful, Partition B fails, and Partition C is successful;

[0114] The third time: Partition A is anomalous, Partition B is successful, and Partition C is successful.

[0115] Calculate the startup reliability rate of each partition:

[0116] Reliability rate of Partition A:

[0117] Reliability rate of Partition B:

[0118] Reliability rate of Partition C:

[0119] Therefore, the system by default preferentially selects partition A with the highest reliability rate as the startup file. If the startup fails, it will automatically switch to partition C with the second highest reliability rate to ensure system stability.

[0120] Finally, the above are only the preferred embodiments of the present invention and are not used to limit the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A method for deploying a launch vehicle, characterized in that: include: Step A1: Design storage partitions for multi-partition system files; In step A1, the storage partition design includes a system partition and a log partition; The system partition contains three operating system images. When a system file fails, the system can switch to other images. The log partition records key events and status changes during system startup; Step A2: Deploy health monitoring software and monitor hardware and software status in real time; Step A3: Voting and health monitoring of system startup status; In step A3, after the device is powered on, the system boots the image files of the three system partitions in sequence; after each startup, the health monitoring software records the startup status. If a freeze or abnormality occurs during the startup process, the monitoring software automatically performs the following processing: Restart and switch to the next system image: If the current partition fails, it will immediately trigger a restart operation and automatically switch to the next system image file for startup; Multiple startup failure judgment: If multiple system image files fail to start continuously, the monitoring software will use a three-judgment and two-judgment mechanism to judge the reliability of the system files; Among them, the specific method of the two-judgment adjudication mechanism in the three-judgment two-judgment mechanism is: Step B1: When the system starts, the system loads three system image files in sequence and performs startup detection; the health status of each image file after startup is recorded by the health monitoring program, including startup success, abnormal termination and startup failure status; Step B2: when at least two versions of the three image files are successfully started, the system determines that the version is the current reliable startup file and selects the version with the highest reliability as the default startup file of the system; Step B3: When only one of the three versions is successfully started or all fail, the system enters the failure recovery process to ensure that the system is restored to a reliable state when it cannot be started locally; The specific method of starting decision-making and switching strategies in the three-judgment-two-decision mechanism is: Step D1: When the system is powered on, the health monitoring program first calculates the reliability of each image file and uses the file with the highest reliability as the default boot system; if the file cannot be started due to an abnormal situation, the system will automatically switch to the image file with the second highest reliability; Step D2: After the system is successfully started, the system dynamically updates the reliability rate and weight so that the system default startup file always points to the most stable image at the moment; Step D3: If the reliability of a partition is lower than 50% for a long period of time, the system marks the image file as a "high-risk version" and enters the remote redeployment process to replace the image file of the partition by downloading the most basic and stable version image; FTP remote recovery: When all system image files cannot be started normally, the monitoring software will try to download the most stable operating system version through FTP connection for remote recovery deployment; During this process, the monitoring software needs to be pre-configured with the FTP server address, username and password connection information; once the connection is successful, it will download the specified operating system image file from the server and write it to the device's internal memory; after the download is complete, the monitoring software will attempt to restart the system and load the newly downloaded image file; Step A4: After the multi-partition is started, the confidence of each partition is calculated based on the function importance index and dynamic voting is performed; Step A5: Recover and redeploy the system.

2. A method for deploying a launch vehicle according to claim 1, characterized in that: In step A2, the health monitoring software classifies the detected anomalies into three categories, including module-level errors, partition-level errors, and process-level errors; The health monitoring software is deployed to the internal memory of the device through the serial port, loaded and run by the U-Boot program, and records and executes exception processing when abnormal system startup is detected; When the health monitoring software detects an abnormality, it immediately records the abnormal information and records it in a log file. It also determines the abnormality type based on the abnormal information and determines the corresponding processing strategy. It performs corresponding exception processing operations according to the processing strategy. After the exception processing is completed, it attempts to restore the normal operation of the system. It reports the abnormal information and processing results to the system administrator or relevant maintenance personnel so that they can understand the system status and take further measures.

3. A method for deploying a launch vehicle according to claim 1, characterized in that: In the step A4, the confidence of each partition is calculated based on the function importance index after starting multiple partitions, including the following steps: Real-time monitoring and recording of the time required for the system to boot up and fully start: recording the loading status and response time of each key component during the startup process; capturing and recording any errors or exceptions that occur during the startup process, including error codes, occurrence time, and related components; categorizing and prioritizing errors so that system administrators can quickly locate and resolve problems; storing all startup response and error records in secure and reliable log files; providing convenient log query functions, supporting filtering and exporting by time range, error type, or component name conditions; Partition confidence assessment: Based on historical boot records, calculate the successful boot rate of each system partition or version; the successful boot rate is defined as the ratio of successful boot times to total boot times within a time window; perform statistical analysis on historical faults of each partition or version, including fault type, frequency of occurrence, and repair time; provide improvement suggestions and optimization measures to system administrators based on fault analysis results; calculate confidence for each partition or version based on the successful boot rate and historical fault analysis results; confidence is a dynamic value that will be updated in real time based on new boot records and fault conditions; Determination of the default startup system and startup of the alternative system: select the system version with the highest confidence as the default startup system based on the confidence ranking; automatically trigger the selection and startup process of the alternative system when the confidence of the default system drops below the preset threshold; preset multiple alternative systems and sort them according to confidence; automatically select the alternative system with the highest confidence to start when the default system cannot be started; provide the function of manually selecting the alternative system so that the system administrator can intervene; continue to monitor the system operation status after the alternative system is started to ensure that the system can run stably; if new faults or abnormalities are found, immediately trigger the corresponding alarm and diagnosis mechanism so that the system administrator can handle them in time.

4. A method for deploying a launch vehicle according to claim 1, characterized in that: The specific method of weight calculation and startup reliability statistics in the three-judgment-two-decision mechanism is as follows: Step C1: After each system partition is started, the health monitoring program records the startup status and stores the success, failure, and abnormal results in the log partition; Step C2: assign different weights to the startup status of each partition; A successful startup is assigned a weight of 1.0, which represents the stability of the partition startup; The startup exception is assigned a weight of 0.5, indicating that the partition is at risk; Startup failure is assigned the lowest weight of 0, indicating a state where it cannot be started; Step C3: Perform a weighted average on the boot history of each partition to calculate the reliability of each system image file. The reliability calculation method is as follows: ,in, It is expressed as the startup reliability rate of the i-th system image file; It is represented as the weight of the i-th image file in the j-th startup; It represents the status of the i-th image file in the j-th startup, where 1 represents success and 0 represents failure or exception; N represents the number of historical startups of the image file.

5. A launch vehicle deployment method according to claim 1, characterized in that: In step A5, when all three system image files fail to pass the three-judgment-two-determination, the system automatically enters the remote recovery mode; a temporary system image is downloaded through the FTP connection so that engineers can redeploy and recover remotely, reducing downtime and ensuring the progress of the test; the method of the remote recovery mode is specifically as follows: Step E1: Configure FTP connection; Step E2: Use the TFTP protocol to download the kernel and system files to the memory, start the TFTP client of the device; specify the path and file name of the kernel and system files to be downloaded; start the download process and monitor the download progress; Step E3: Set the boot parameters and start the kernel. Set the boot parameters according to the requirements of the downloaded kernel and system files. In the boot manager or recovery mode of the device, specify to use the downloaded kernel and system files for booting. After confirming that the boot parameter settings are correct, start the kernel.

6. A launch vehicle deployment system, using a launch vehicle deployment method as claimed in any one of claims 1 to 5, characterized in that: The deployment system comprises: Storage partition design module: used to design storage partitions for multi-partition system files; Health monitoring software deployment module: used to deploy health monitoring software and monitor hardware and software status in real time; Voting module: used to vote on the system startup status and health monitoring; Confidence calculation module: used to calculate the confidence of each partition based on the function importance index and perform dynamic voting after multi-partition startup; Recovery module: used to recover and redeploy the system.

Citation Information

Patent Citations

  • High data integrity processing system

    CN108874571A

  • System and method for monitoring test launch command on basis of voice drive

    CN109935230A