Carrier rocket deployment method and system
Through the combination of multi-partition storage design and health monitoring software, automatic abnormality detection and remote recovery of the spacecraft system are realized, and maintenance difficulties and downtime problems in the startup abnormal situation in the existing technology are solved, improving the reliability and stability of the system sex.
Patent Information
- Application Number
- CN202411856333.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-17
- Publication Date
- 2025-01-14
- Estimated Expiration
- 2044-12-17
AI Technical Summary
The existing spacecraft system lacks effective abnormality monitoring and automatic recovery functions in the case of abnormal startup, resulting in increased maintenance difficulties and long-term downtime.
Adopting a multi-partition storage design, health monitoring software is deployed to monitor hardware and software status in real time, automatically select the most reliable system image for startup through dynamic voting and confidence calculation, and remotely recover through FTP in case of failure.
The system is achieved with high reliability and stability, reducing the on-site work burden of maintenance personnel, shortening the system recovery time, reducing the risk of startup failure, and ensuring the continuous operation of the system.
Smart Images

Figure CN119311286A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of operating system deployment, and more specifically, to a launch vehicle deployment method and system. Background Art
[0002] In the aerospace field, embedded operating systems are widely used in key control components such as satellites, aircraft, rockets and spacecraft; these embedded systems can optimize resources and support spacecraft attitude control, navigation, communication, fault detection and other tasks due to their high reliability and real-time performance. However, in launch vehicle applications, the reliability and stability requirements of embedded operating systems are particularly stringent, because the success of system loading and startup is directly related to the success or failure of the flight mission.
[0003] Among the existing spacecraft system startup methods, some have implemented multi-mode booting but have not provided effective abnormality monitoring and automatic recovery functions; others have introduced simple restart mechanisms but have not covered multi-partitioning and failover strategies.
[0004] When these solutions are actually used, if the system is in an abnormal startup state, it is difficult to accurately locate and solve the problem due to the lack of monitoring methods. Once the startup fails, the equipment or even the board needs to be disassembled for further debugging, which increases the difficulty of maintenance. The current system has no automatic recovery function in the event of abnormal startup, resulting in long 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 method for deploying a launch vehicle to solve the problems raised in the above-mentioned background technology.
[0006] To achieve the above object, the present invention provides the following technical solutions: Step A1: Design storage partitions for multi-partition system files; 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; 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.
[0007] Preferably, 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 the system startup process, such as hardware detection, driver loading, service startup, etc.
[0008] These logs help to understand the system startup process and provide clues for troubleshooting when problems occur; record system failure events, including failure type, occurrence time, and impact scope; provide log analysis tools to parse, filter, and search log data; regularly back up log data to prevent data loss or damage; compress old logs to save storage space; and regularly clean up expired log data to keep log partitions neat and efficient.
[0009] 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; 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.
[0010] Preferably, 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, and 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.
[0011] This process is automated and requires no human intervention; 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; Specifically, it counts the number of successful and failed boots of each system image file based on the previously recorded boot status; if an image file fails more than twice, it is unreliable; The monitoring software will avoid trying to boot that image file again and try other reliable image files instead.
[0012] 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 pre-configure the FTP server address, user name, password and other 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 try to restart the system and load the newly downloaded image file.
[0013] Preferably, in 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 boot up: recording the loading status and response time of each key component during the boot process; capturing and recording any errors or exceptions that occur during the boot process, including error codes, occurrence times, and related components; categorizing and prioritizing errors so that system administrators can quickly locate and resolve issues; storing all boot 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; 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 certain 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: sort by confidence and select the system version with the highest confidence as the default startup system; when the confidence of the default system drops below the preset threshold, the selection and startup process of the alternative system is automatically triggered; multiple alternative systems are preset and sorted according to confidence; when the default system cannot be started, the alternative system with the highest confidence is automatically selected for startup; provide the function of manually selecting an alternative system so that the system administrator can intervene in specific circumstances; after the alternative system is started, continue to monitor the system operation status 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.
[0014] Preferably, 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 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: Step E1: Configure FTP connection; Step E2: Use the TFTP protocol to download the kernel and system files to the memory, start the device's TFTP client; 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 file; 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. These parameters may include memory allocation, root file system location, etc. In the device's boot manager or recovery mode, specify to use the downloaded kernel and system files for booting; after confirming that the boot parameter settings are correct, start the kernel; monitor the boot process to ensure that the system can boot smoothly and enter the temporary running state.
[0015] The present invention also provides a deployment system for a launch vehicle, using the deployment method for a launch vehicle as described above, the deployment system comprising: 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.
[0016] Technical effects and advantages of the present invention: 1. The present invention stores three operating system images through multiple partitions, and can quickly switch when a file fails, which significantly improves the fault tolerance and stability of the system; there is no need to rely on a single backup, which improves the reliability of the system; and through the health monitoring program, the abnormalities in the system startup process are recorded in real time, providing data support for troubleshooting and system optimization.
[0017] 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 workload of maintenance personnel and shortening system recovery time; 3. The present invention can intelligently select the most reliable startup file through the three-judgment and two-decision mechanism and confidence calculation, effectively reducing the risk of startup failure, and can automatically switch after multiple failures to ensure continuous operation of the system. BRIEF DESCRIPTION OF THE DRAWINGS
[0018] Figure 1 It is a schematic diagram of the method flow of the present invention.
[0019] Figure 2 It is a schematic diagram of module connection of the present invention. DETAILED DESCRIPTION
[0020] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0021] See also Figure 1 As shown, the present invention provides a highly reliable operating system deployment strategy for a launch vehicle, and the method is as follows: 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 the system startup process, such as hardware detection, driver loading, service startup, etc.
[0022] These logs help to understand the system startup process and provide clues for troubleshooting when problems occur; record system failure events, including failure type, occurrence time, and impact scope; provide log analysis tools to parse, filter, and search log data; regularly back up log data to prevent data loss or damage; compress old logs to save storage space; and regularly clean up expired log data to keep log partitions neat and efficient.
[0023] Step A2: Deploy health monitoring software and monitor hardware and software status in real time; 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 the corresponding abnormal processing operations based on the processing strategy. After the abnormal 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. Among them, module-level errors affect the entire module, monitoring and recording errors in module initialization and function execution; Partition-level errors only affect a single partition, and monitor abnormalities in partition initialization, process management, and other links; Process-level errors monitor a single process, including errors such as process execution, overflow, and storage conflict.
[0024] 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.
[0025] This process is automated and requires no human intervention; 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; Specifically, it counts the number of successful and failed boots of each system image file based on the previously recorded boot status; if an image file fails more than twice, it is unreliable; The monitoring software will avoid trying to boot that image file again and try other reliable image files instead.
[0026] 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 pre-configure the FTP server address, user name, password and other 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 try to restart the system and load the newly downloaded image file.
[0027] 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; 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 boot up: recording the loading status and response time of each key component during the boot process; capturing and recording any errors or exceptions that occur during the boot process, including error codes, occurrence times, and related components; categorizing and prioritizing errors so that system administrators can quickly locate and resolve issues; storing all boot 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; 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 certain 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: According to the confidence ranking, the system version with the highest confidence is selected as the default startup system; when the confidence of the default system drops below the preset threshold, the selection and startup process of the alternative system is automatically triggered; multiple alternative systems are preset and ranked according to confidence; when the default system cannot be started, the alternative system with the highest confidence is automatically selected for startup; the function of manually selecting an alternative system is provided so that the system administrator can intervene in specific situations; after the alternative system is started, the system operation status continues to be monitored to ensure that the system can run stably; if a new fault or abnormality is found, the corresponding alarm and diagnosis mechanism is immediately triggered so that the system administrator can handle it in time; The specific method of the two-judgment decision mechanism in the three-judgment two-judgment decision 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 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 weight of 1.0 is assigned to a successful startup, indicating the stability of the startup of the partition; a weight of 0.5 is assigned to a startup abnormality, indicating that the partition has certain risks; a weight of 0 is assigned to a startup failure, indicating that the partition 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 abnormality; N represents the number of historical startups of the image file; 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; Step A5: Recover and redeploy the system; In step A5, when all three system image files fail to pass the three-judgment and two-determination test, 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 E11: Set the IP address of the device and enter the network configuration interface of the device; manually set or automatically obtain the IP address of the device through DHCP according to the network environment; after confirming that the IP address of the device is set correctly, save the configuration and restart the network service; 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 user name and password; test the connection with the FTP server to ensure that the configuration is correct; Step E2: Use the TFTP protocol to download the kernel and system files to the memory, start the device's TFTP client; 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 file; 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. These parameters may include memory allocation, root file system location, etc. In the device's boot manager or recovery mode, specify to use the downloaded kernel and system files for booting. After confirming that the boot parameter settings are correct, start the kernel. Monitor the boot process to ensure that the system can boot smoothly and enter the temporary running state. Among them, the key commands of the remote recovery mode process are: # 1. Set FTP server IP set serverip 192.168.1.100 # 2. Download new system files (if the startup has failed twice) tftp 0x40000000 uImage # 3. Set startup parameters and perform restart loading set bootargs root= / dev / nfs nfsroot= 192.168.1.100: / nfs_files / rootfstcp,v4 rw console= / dev / ttySAC0,115200 saveenv bootm 0x40000000.
[0028] The present invention also provides a deployment system for a launch vehicle, using the deployment method for a launch vehicle as described above, the deployment system comprising: 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. Example 1
[0029] Assume that the three system startup records are as follows (weight assumptions: success = 1.0, abnormality = 0.5, failure = 0): First time: Partition A succeeds, Partition B fails, and Partition C fails; Second time: Partition A succeeds, Partition B fails, and Partition C succeeds; The third time: Partition A is abnormal, Partition B is successful, and Partition C is successful.
[0030] Calculate the startup reliability of each partition: Partition A Reliability:
[0031] Partition B Reliability:
[0032] Partition C Reliability:
[0033] Therefore, the system defaults to selecting partition A with the highest reliability as the startup file. If the startup fails, it will automatically switch to partition C with the second highest reliability to ensure system stability.
[0034] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in 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; 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; 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 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 the system startup process.
3. 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.
4. A method for deploying a launch vehicle according to claim 1, characterized in that: 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; 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; Once the download is complete, the monitoring software will attempt to reboot the system and load the newly downloaded image file.
5. A launch vehicle deployment method 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.
6. A method for deploying a launch vehicle according to claim 5, characterized in that: The specific method of the two-judgment decision mechanism in the three-judgment two-judgment decision 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.
7. A method for deploying a launch vehicle according to claim 6, 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.
8. A method for deploying a launch vehicle according to claim 6, characterized in that: 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.
9. 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.
10. A launch vehicle deployment system, using a launch vehicle deployment method according to any one of claims 1 to 9, 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
Remote upgrade function realization method and system based on MCU and TFTP protocol
CN113900697A
Industrial control system software security upgrading method supporting state rollback
CN115328518A
Multivariate metadata based cloud deployment monitoring for lifecycle operations
US20160350102A1
Cited By
DCS controller software restarting method based on trusted computing and related products
CN119597547A