Simulation method and system for launch process of carrier rocket, and electronic equipment

Abstract

The invention provides a simulation method and system for the launch process of a carrier rocket and electronic equipment, and relates to the technical field of rocket launch simulation. The method comprises the steps that a launching scheme of the carrier rocket is determined, and the launching scheme comprises launching parameters of the carrier rocket; modeling and verifying the launching scheme; and performing simulation test on the launch process of the carrier rocket based on the verified launch scheme, and responding and correcting faults in the simulation test process. According to the invention, the problem that the safety of the launch task of the carrier rocket is threatened due to the fact that key design defects are not found in time due to multiple technical bottlenecks existing in the distributed simulation technology of the reusable carrier rocket is solved.

Description

Technical Field

[0001] This disclosure relates to the field of rocket launch simulation technology, and more specifically, to a simulation method and system, and electronic equipment for the launch process of a launch vehicle. Background Technology

[0002] Currently, distributed simulation systems for reusable launch vehicles face multiple technical bottlenecks in their research and testing, particularly in the case of virtual-real hybrid distributed simulations, which suffer from insufficient real-time performance and incompatible system architectures. These issues not only increase research and development costs but may also lead to critical design flaws going undetected in a timely manner, threatening the safety of launch vehicle missions. Summary of the Invention

[0003] The purpose of this disclosure is to address the problem that current distributed simulation technology for reusable launch vehicles has multiple technical bottlenecks, which may lead to key design flaws not being detected in a timely manner, threatening the safety of launch vehicle launch missions.

[0004] According to one aspect of the present disclosure, a simulation method for a launch vehicle launch process is provided. The method includes: determining a launch scheme for the launch vehicle, wherein the launch scheme includes launch parameters of the launch vehicle; modeling and verifying the launch scheme; performing simulation tests on the launch process of the launch vehicle based on the verified launch scheme; and responding to and correcting faults in the simulation test process.

[0005] Optionally, the launch scheme is modeled and verified, including: using the system modeling language SysML to establish an architecture model of the launch vehicle's propulsion system, wherein the architecture model includes: a structural model, used to characterize the physical structural components in the launch vehicle's propulsion system; a thermal protection model, used to predict the temperature distribution data of the launch vehicle's heat shield tiles during the launch vehicle's reentry into the atmosphere; and using nonlinear finite element analysis to predict the launch vehicle's body deformation and verify the strength of the structural model.

[0006] Optionally, the launch scheme is validated, including: predicting the remaining service life of the launch vehicle's turbopump based on the first deep learning model, and generating a maintenance work order when an anomaly is detected in a component of the turbopump, and sending the maintenance work order to an interactive device for display; wherein, the first deep learning model is trained using the following method: Step S1: Initialize the turbopump life prediction model locally on the server. Step S2: Obtain multiple encrypted gradient parameters from multiple nodes respectively. The different gradient parameters are generated by different nodes during the process of training the turbopump life prediction model using their respective test site engine data. Step S3: Use the federated learning engine to perform weighted aggregation on multiple encrypted gradient parameters; Step S4: Update the turbopump life prediction model using the processed gradient parameters; Repeat steps S2 to S4 until the training of the turbopump life prediction model is complete.

[0007] Optionally, the launch scheme is validated, including: applying random perturbations to the combustion chamber pressure of the launch vehicle through Monte Carlo simulation to obtain the probability distribution of the launch vehicle's thrust; using a Bayesian update algorithm to quantify the deviation range between the output data of the thrust prediction model and the actual measurement data, and generating a confidence interval to represent the range of thrust values.

[0008] Optionally, the launch process of the launch vehicle is simulated and tested based on the launch scheme, including: receiving virtual flight control commands; responding to the virtual flight control commands and simulating the attitude changes of the launch vehicle in different flight phases to verify the stability of the launch vehicle's flight control system; driving the launch vehicle's engine nozzle to dynamically adjust the thrust within a preset thrust range according to the virtual flight control commands to test the launch vehicle's thrust adjustment mechanism; acquiring the launch vehicle's nozzle expansion ratio change data to verify the performance of the launch vehicle's control algorithm; and achieving coordinated operation between multiple simulation nodes through distributed middleware to ensure that the launch vehicle's separation mechanism and physical actuators move synchronously.

[0009] Optionally, responses and corrections are made to faults during the simulation test, including: if, during the launch vehicle's flight phase, the pressure fluctuation value of the second-stage engine combustion chamber exceeds a preset threshold, a graph neural network model is used to analyze the sensor topology of the launch vehicle and locate the cause of the fault where the combustion chamber pressure fluctuation value exceeds the preset threshold; the optimal fuel recovery trajectory of the launch vehicle is generated based on deep reinforcement learning; and a Bayesian update algorithm is used to quantify the deviation range between the temperature distribution data predicted by the thermal protection model and the actual measured temperature distribution data, thereby correcting the thermal protection model.

[0010] Optionally, the above method further includes: dynamically allocating computing power based on task priority according to deep reinforcement learning, wherein high-priority tasks are allocated to edge image processor GPU nodes for processing, and low-priority tasks are allocated to cloud processors for processing.

[0011] According to another aspect of the present disclosure, a simulation system for a launch vehicle launch process is provided to implement the above-mentioned method, comprising: a user interaction layer, an AI application layer, a functional logic layer, a data fusion layer, a middleware layer, a hardware interface layer, and a physical layer. The user interaction layer, located at the top layer of the simulation system, is used to realize human-computer interaction between the user and the simulation system and to define a unified communication protocol. The AI ​​application layer, located between the user interaction layer and the functional logic layer, is used to perceive the operational status of the launch vehicle during the simulation of the launch process. The functional logic layer, located between the AI ​​application layer and the functional logic layer, is used to... Between the physical layer and the data fusion layer, multi-physics coupled simulation of the launch vehicle in the simulation system is achieved, as well as cross-model data exchange and computation are realized. The data fusion layer, located between the functional logic layer and the middleware layer, is used to process data collected from sensors distributed at different locations on the launch vehicle. The middleware layer, located between the data fusion layer and the hardware interface layer, is used to implement at least the following functions: cross-platform communication, time synchronization, and spatial synchronization. The hardware interface layer, located between the middleware layer and the physical layer, is used to connect physical devices with the upper-level software system. The physical layer, located at the bottom layer of the simulation system, is used to support the physical devices.

[0012] According to another aspect of the present disclosure, an electronic device is provided, comprising: a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the above-described method.

[0013] According to another aspect of the present disclosure, a computer-readable storage medium is provided that stores a computer program thereon, which, when executed by a processor, implements the above-described method.

[0014] The beneficial effects of the technical solution provided in this disclosure are as follows: This disclosure proposes a design method for a distributed simulation system combining virtual and real elements for the launch process of a launch vehicle based on a seven-layer architecture. By verifying the launch scheme of the launch vehicle and responding to and correcting the faults in the launch vehicle simulation test process after verification, the technical effect of timely detection of design defects of the launch vehicle is achieved, which improves the safety of the launch vehicle launch mission and reduces the simulation cost of the launch vehicle launch process is achieved. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments of this disclosure will be briefly introduced below.

[0016] Figure 1 A schematic diagram of the architecture of a simulation system for a launch vehicle launch process provided in this embodiment of the disclosure; Figure 2A flowchart illustrating a simulation method for a launch vehicle launch process provided in this embodiment of the present disclosure; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0017] The embodiments of this disclosure are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this disclosure, and do not constitute a limitation on the technical solutions of the embodiments of this disclosure.

[0018] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this disclosure mean that the corresponding feature can be implemented as the presented feature, information, data, step, operation, element, and / or component, but do not exclude implementation as other features, information, data, step, operation, element, component, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element are connected through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “and / or” as used herein indicates at least one of the items defined by the term, for example, “A and / or B” or “A, B” indicates implementation as “A,” or implementation as “B,” or implementation as “A and B.”

[0019] To make the objectives, technical solutions, and advantages of this disclosure clearer, the embodiments of this disclosure will be described in further detail below with reference to the accompanying drawings.

[0020] First, the technical terms used in this disclosure will be introduced and explained: Virtual-real hybrid distributed simulation refers to a simulation method that utilizes both a virtual environment (a computer-generated simulation environment) and real-world physical entities (real devices or systems) in a simulation system, distributing these elements across different geographical locations to enable collaborative work and interaction.

[0021] As mentioned earlier, distributed simulation systems for reusable launch vehicles face multiple technical bottlenecks in research and development and testing, particularly in the case of distributed simulations combining virtual and physical elements in different locations, which suffer from insufficient real-time performance and incompatible system architectures. While some existing technical solutions attempt to optimize processes through layered architecture design, significant shortcomings remain. For example, one related technical solution proposes a five-layer architecture (including physical, network, application, data, and user layers). Due to the ambiguous functional division of these layers and the lack of standardized communication protocols between hardware interfaces and the virtual model, command delays exceed 15 milliseconds during semi-physical testing. Taking engine ignition testing as an example, the thrust curve calculated by the virtual model requires multi-level protocol conversion to drive the physical actuators, resulting in low response efficiency and severely restricting the development cycle and testing reliability. Furthermore, another existing technical solution describes an augmented reality (AR) assisted testing system that relies solely on a monocular camera for virtual-physical overlay, with a synchronization error exceeding 5 millimeters. In rocket stage separation simulations, deviations in the actions of the virtual model and the physical separation mechanism lead to a collision risk misjudgment rate as high as 12%. Existing light field projection technologies (such as traditional holographic screens) cannot meet the requirements of high-dynamic scenarios due to insufficient resolution (below 4K) and the lack of time synchronization mechanisms. The problem of data silos is also prominent. For a certain type of rocket simulation system, due to inconsistent data formats across different test sites, model training requires more than 30% of the time for manual data processing and cleaning. Furthermore, model validation relies solely on root mean square error, lacking a quantitative assessment of uncertainties, resulting in a confidence level of less than 80% for reentry phase thermal protection simulations. These problems not only increase R&D costs but may also lead to key design flaws going undetected, threatening mission safety.

[0022] The simulation method, system, and electronic equipment for the launch process of a carrier rocket disclosed herein are intended to solve at least one of the above-mentioned technical problems in the prior art.

[0023] The following description of several exemplary embodiments illustrates the technical solutions of this disclosure and the technical effects produced by these solutions. It should be noted that the following embodiments can be referenced, learned from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0024] Figure 1 This is a schematic diagram of the architecture of a simulation system for a launch vehicle launch process provided in an embodiment of this disclosure, as shown below. Figure 1 As shown, the system includes: a user interaction layer 10, an AI application layer 11, a functional logic layer 12, a data fusion layer 13, a middleware layer 14, a hardware interface layer 15, and a physical layer 16. User interaction layer 10, located at the top layer of the simulation system, is used to realize human-computer interaction between users and the simulation system and to define a unified communication protocol.

[0025] The simulation system proposed in this disclosure breaks the traditional linear interaction mode of hierarchical architecture and realizes real-time collaboration between hardware control, AI decision-making, and user feedback through a two-way closed-loop link.

[0026] from Figure 1 As can be seen, each layer is seamlessly connected through standardized interfaces (for example, the user interaction layer 10 and the AI ​​application layer 11 exchange control commands and data streams via HTTP and MQTT protocols, respectively), forming a top-down command transmission and bottom-up data feedback mechanism. This design not only improves the system's response speed and stability but also makes system expansion and maintenance more convenient. This hierarchical architecture effectively solves problems existing in current technologies, such as fragmented architecture layers, low virtual-real synchronization accuracy, and insufficient data sharing and reliability, thereby improving overall collaborative work efficiency.

[0027] According to some optional embodiments of this disclosure, the user interaction layer 10 defines a unified communication protocol (such as a binary data format based on Apache Avro), and the protocol conversion layer is compressed from 4 layers to 1 layer, reducing latency by 99.9%.

[0028] The FPGA multi-protocol conversion module supports lossless interoperability between CAN / 1553B, serial port, and Ethernet, reducing the cost of connecting older equipment by 70%.

[0029] User interaction layer 10 also includes a light field projection terminal (e.g., a 65-inch, 8K resolution laser projector) working in conjunction with an AR head-mounted display device (gesture recognition accuracy ≤2mm) to support multimodal operation. For example, engineers can use the AR head-mounted display device to "grab" the virtual rocket fuel tank with gestures, adjusting the liquid oxygen / kerosene ratio to 75:25. The system projects the center of gravity changes in real time, and the holographic image refresh rate is 120Hz, ensuring no motion blur in the dynamic effects. The voice command "Start Level 1 Separation" triggers the linkage between the virtual model and the physical actuators, and the light field projection synchronously displays the separation spark effect with a time synchronization error ≤1μs.

[0030] AI application layer 11, located between user interaction layer 10 and functional logic layer 12, is used to perceive the operational status of the launch vehicle during the simulation of the launch process.

[0031] AI application layer 11 is mainly used to realize health management, fault diagnosis, and path optimization functions. Among them, health management refers to analyzing the vibration spectrum of the turbine pump (sampling rate 1kHz) based on the Long Short-Term Memory Network and the attention mechanism (LSTM-Attention model) to predict the remaining life with an error ≤8%. If bearing wear exceeds the limit, maintenance work orders are automatically generated and pushed to the AR interface.

[0032] Fault diagnosis refers to using graph neural networks (GNNs) to analyze the topological relationships of sensors and locate the source of anomalies (such as valve jamming) within 10 seconds, with an accuracy of ≥95%.

[0033] Path optimization refers to using deep reinforcement learning (DRL) to generate the optimal fuel recovery trajectory, with a landing accuracy of ≤0.5 meters, which is 60% higher than traditional algorithms.

[0034] The functional logic layer 12, located between the AI ​​application layer 11 and the data fusion layer 13, is used to realize the multi-physics coupling simulation of the launch vehicle in the simulation system, as well as to realize cross-model data exchange and calculation.

[0035] Functional logic layer 12 specifically addresses the key technology implementation for multi-physics coupling modeling and joint solution of reusable launch vehicles in simulation systems.

[0036] Multiphysics coupled simulation defines three core physical models in the simulation system: aerodynamic model, structural model, and thermal protection model.

[0037] The aerodynamic model is based on Large Eddy Simulation (LES) to calculate shock wave effects in the Mach number range of 0-20, with a mesh resolution of 0.1 mm. This function allows for the analysis of aerodynamic characteristics around the rocket body during reentry or launch; accurate prediction of complex flow phenomena such as shock wave location, separation, and reflection; and support for subsequent physical field inputs such as heat flux, pressure distribution, and vibration.

[0038] The structural model predicts rocket body deformation using nonlinear finite element analysis (Nonlinear FEA), with a fatigue life error of ≤5%. This function can predict material fatigue life and structural stability, providing a basis for structural optimization design.

[0039] The thermal protection model simulates the temperature distribution of the thermal insulation tiles during reentry, with an error ≤1℃. This function can verify the effectiveness of the thermal protection system design; predict material ablation behavior; and provide boundary conditions for cooling system design.

[0040] Joint solution refers to the use of MPI (Message Passing Interface) to achieve cross-model data exchange, with a computation step size of ≤1ms under the acceleration of Graphics Processing Unit (GPU), and supports real-time dynamic response.

[0041] Message Passing Interface (MPI) is a standard interface specification for writing parallel programs, widely used in high-performance computing, scientific computing, and large-scale data processing. It defines a set of communication protocols and function interfaces for message passing between processes or nodes, enabling developers to efficiently implement parallel computing in distributed memory systems.

[0042] The data fusion layer 13, located between the functional logic layer 12 and the middleware layer 14, is used to process data collected from sensors distributed at different locations on the launch vehicle.

[0043] Data fusion layer 13 is a crucial component of the entire system architecture. This layer is responsible for integrating, cleaning, analyzing, and assessing the reliability of heterogeneous data from multiple sensors, models, and simulators in real time, ultimately outputting high-precision, low-latency, and highly interpretable decision support information.

[0044] The data fusion layer 13 mainly implements real-time stream processing and credibility assessment functions.

[0045] Real-time stream processing refers to the use of streaming computing frameworks by high-speed servers to process more than 100,000 sensor data points per second with a latency of less than 10ms, ensuring timely fault response.

[0046] Credibility assessment involves applying a ±5% random perturbation to the combustion chamber pressure using Monte Carlo simulation to simulate uncertainties that may occur during actual operation. After multiple simulations, a probability distribution of thrust output is obtained, which is used to evaluate the robustness and risk boundary of the system.

[0047] By combining Bayesian updates with the latest measured data to dynamically correct the parameters of the original thrust prediction model, the accuracy of the thrust prediction model in predicting future states is improved. This method is particularly suitable for modeling propulsion systems with uncertainties and nonlinear characteristics.

[0048] Compared to the original model, the Bayesian-updated thrust prediction model shows a significant improvement in prediction accuracy, with an error reduction of ≥30%. The final output is a 95% confidence interval (e.g., thrust prediction value 4850-5150 kN), which is visually displayed through a holographic dashboard heatmap.

[0049] The aforementioned 95% confidence interval refers to the statistical range given for the thrust prediction value, indicating that there is a 95% probability that the actual thrust is within this interval, providing a more reliable basis for engineering judgment than a single value.

[0050] The middleware layer 14, located between the data fusion layer 13 and the hardware interface layer 15, is used to implement at least the following functions: cross-platform communication, time synchronization, and spatial synchronization.

[0051] Middleware layer 14 serves as a "bridge" connecting the underlying hardware devices and the upper-layer application logic. It is responsible for handling key tasks such as cross-platform communication, protocol conversion, time / space synchronization, and distributed collaborative simulation, and is a core supporting module for building complex simulation systems, digital twin systems, and hardware-in-the-loop testing environments.

[0052] Middleware layer 14 uses HLA distributed middleware to enable multiple simulation nodes (such as aircraft dynamics model, propulsion system model, and ground station control model) to operate collaboratively; it provides a unified federated management mechanism to ensure the coordination and consistency of each subsystem in terms of time and data.

[0053] HLA (High Level Architecture) is an international standard (IEEE 1516) for distributed simulation, widely used in aerospace, defense and other fields.

[0054] High-precision clock synchronization is achieved using IEEE 1588 PTP (Precision Time Protocol), ensuring that multiple simulation nodes run on the same time base and avoiding logic errors caused by time deviations. The time synchronization accuracy is ≤1μs.

[0055] It supports large-scale data stream transmission, meets the data interaction needs in high-speed dynamic scenarios, and can be used for complex tasks such as rocket cluster simulation and multi-rocket collaborative launch, with a data distribution rate of ≥1Gbps.

[0056] The middleware layer 14 uses a field-programmable gate array (FPGA) to convert CAN, 1553B, serial port and Ethernet protocols, convert traditional RS-422 sensor data into MQTT protocol with a latency of <100μs, and supports seamless access for older devices.

[0057] The middleware layer 14 also uses LiDAR (0.01mm accuracy) and Kalman filtering algorithm to achieve a virtual model pose deviation of ≤1mm from the physical device.

[0058] Middleware layer 14 also uses precise clock synchronization (IEEE 802.1AS) via industrial Ethernet (TSN protocol) with time jitter ≤1μs to meet the millisecond-level response requirements of rocket engines.

[0059] TSN (Time-Sensitive Networking) is a set of standard protocols defined by IEEE, designed for applications requiring deterministic latency and high-precision synchronization; it is particularly suitable for time-sensitive systems such as industrial control, autonomous driving, and aerospace.

[0060] Hardware interface layer 15, located between middleware layer 14 and physical layer 16, is used to connect physical devices with upper-layer software systems.

[0061] Hardware interface layer 15 is primarily responsible for direct interaction with physical devices, including receiving sensor data and sending control commands. It ensures that upper-layer software can accurately perceive and control the actual physical environment, which is crucial for achieving high-fidelity simulation testing and real-time monitoring.

[0062] The hardware interface layer 15 mainly includes the rocket test stand and sensor array.

[0063] The rocket test stand offers six degrees of freedom (translation and rotation along the X, Y, and Z axes), enabling precise simulation of the rocket's attitude changes during different flight phases. It is suitable for simulating complex dynamic scenarios such as takeoff, separation, and landing. Using a real engine nozzle instead of a simulator increases the realism of the simulation. Receiving commands from the virtual flight control system creates a hybrid virtual-real simulation environment. It can dynamically adjust thrust based on virtual commands to simulate different flight conditions and emergency situations, with a thrust adjustment range of 50%-110%. This flexibility helps test the engine's performance under different loads.

[0064] The sensor array primarily consists of a lidar scanner that scans the arrow's deformation with an accuracy of 0.01mm, suitable for capturing minute deformations or damage. An infrared thermal imager monitors the surface temperature distribution of the insulation tiles to ensure the effectiveness of the thermal protection system; its 100Hz sampling rate allows for rapid response to temperature changes and provides high temporal resolution data. High-speed, low-latency 5G networks are used to transmit data, ensuring real-time data transmission from sensors to the analysis system with a latency of less than 15ms, ensuring the control system can react promptly and avoid potential safety hazards.

[0065] Physical layer 16, located at the bottom layer of the simulation system, is used to carry physical devices.

[0066] Physical layer 16 is the foundational layer of the entire system, responsible for carrying all physical resources such as hardware devices, communication links, and structural materials. This layer determines the system's physical reliability, environmental resistance, communication bandwidth, and adaptability to extreme operating conditions, and is the core support for building a highly reliable aerospace system.

[0067] Physical layer 16 is the lowest and most basic layer in the system architecture, mainly composed of various physical entities, including but not limited to: rocket body structural materials, launch platform and ground control station, communication antenna and transmission medium, power system and propulsion device, as well as sensors and actuators.

[0068] The rocket body structure can be based on carbon fiber composite material (tensile strength ≥500MPa, temperature resistance ≥2000℃) and ground telemetry and control station (uplink speed ≥10Gbps) to ensure reliability under extreme conditions.

[0069] Figure 1 The core of the simulation system shown lies in its seven-layer vertical architecture, with each layer seamlessly connected through standardized interfaces to form a closed-loop process of "user interaction, intelligent decision-making, and physical execution".

[0070] exist Figure 1 Based on the simulation system shown, this disclosure provides a simulation method for the launch process of a carrier rocket, which is applied to... Figure 1 The simulation system shown is as follows: Figure 2 As shown, the method includes the following steps: Step S201: Determine the launch plan for the launch vehicle, wherein the launch plan includes the launch parameters of the launch vehicle.

[0071] In this step, relevant personnel (such as engineers) set a target of 10 tons of payload capacity to low Earth orbit for the launch vehicle through an AR interface. The simulation system uses AI to generate multiple candidate schemes, and then uses holographic projection to compare and demonstrate the stability of each scheme under a crosswind of 20 m / s. This allows relevant personnel to select a launch scheme from the multiple candidate schemes.

[0072] Step S202: Model and verify the launch scheme.

[0073] In this step, optionally, after selecting a set of launch schemes, the simulation system uses Model-Based Systems Engineering (MBSE) to model the launch schemes, automatically generating SysML models, which are then exported to ANSYS to verify the structural strength.

[0074] ANSYS is an engineering simulation software suite widely used in various industrial fields such as aerospace, automotive, electronics, energy, and machinery manufacturing. It provides multi-physics simulation capabilities, covering simulation analysis of multiple disciplines including structural mechanics, fluid mechanics, heat conduction, electromagnetic fields, acoustics, and system control.

[0075] Step S203: Based on the verified launch scheme, conduct simulation tests on the launch process of the launch vehicle, and respond to and correct any faults that occur during the simulation test.

[0076] The technical solution proposed in this disclosure verifies the launch scheme of the launch vehicle and responds to and corrects the faults in the launch vehicle simulation test process after the verification is completed. This achieves the technical effect of timely detection of design defects of the launch vehicle, improving the safety of the launch vehicle launch mission, and reducing the simulation cost of the launch vehicle launch process.

[0077] This disclosure provides a possible implementation method, executing step S202, modeling and verifying the launch scheme, including the following steps: using the system modeling language SysML to establish an architecture model of the launch vehicle's propulsion system, wherein the architecture model includes: a structural model, used to characterize the physical structural components in the launch vehicle's propulsion system; a thermal protection model, used to predict the temperature distribution data of the launch vehicle's heat shield tiles when the launch vehicle re-enters the atmosphere; and using nonlinear finite element analysis to predict the launch vehicle's body deformation and verify the strength of the structural model.

[0078] SysML (Systems Modeling Language) is a standardized modeling language developed specifically for systems engineering.

[0079] In this step, the structural model and thermal protection model are built using the SysML language. The structural model predicts rocket body deformation through nonlinear finite element analysis, with a fatigue life error of ≤5%. This function can predict material fatigue life and structural stability, providing a basis for structural optimization design.

[0080] The thermal protection model simulates the temperature distribution of the thermal insulation tiles during reentry, with an error ≤1℃. This function can verify the effectiveness of the thermal protection system design; predict material ablation behavior; and provide boundary conditions for cooling system design.

[0081] According to some optional embodiments of this disclosure, the execution step S202 to verify the launch scheme further includes: predicting the remaining service life of the launch vehicle's turbopump based on a first deep learning model, and when an abnormality is detected in the components of the turbopump, generating a maintenance work order and sending the maintenance work order to an interactive device for display.

[0082] The aforementioned first deep learning model can be an LSTM-Attention model. In the embodiments disclosed herein, the simulation system analyzes the vibration spectrum of the turbine pump based on the LSTM-Attention model (the sampling rate can be set to 1kHz) and predicts the remaining lifespan with an error ≤8%. If bearing wear exceeds the limit, a maintenance work order is automatically generated and pushed to the AR interface.

[0083] As some optional embodiments of this disclosure, the first deep learning model described above is trained using the following method: Step S1: Initialize the turbopump life prediction model locally on the server. Step S2: Obtain multiple encrypted gradient parameters from multiple nodes respectively. The different gradient parameters are generated by different nodes during the process of training the turbopump life prediction model using their respective test site engine data. Step S3: Use the federated learning engine to perform weighted aggregation on multiple encrypted gradient parameters; Step S4: Update the turbopump life prediction model using the processed gradient parameters; Repeat steps S2 to S4 until the training of the turbopump life prediction model is complete.

[0084] In the embodiments disclosed herein, the aforementioned LSTM-Attention model is trained using a distributed machine learning framework of federated learning gradient aggregation. Each node trains its model locally and then uses dynamic encryption technology to protect the gradient parameters of its local model before uploading the encrypted gradient parameters to a cloud server. The cloud server performs weighted averaging (weights are the proportion of data from each test case) aggregation on the gradient parameters uploaded by each node, and uses the aggregated gradient parameters to update the global model, thus preventing data leakage.

[0085] The training process of the above model will be described below with reference to specific embodiments.

[0086] Assume that test site A provides engine data for high-temperature environments, and test site B provides data for low-temperature environments.

[0087] In test site A, the local training set contains 1000 sets of engine high-temperature operating condition data (combustion chamber pressure ≥10MPa). The local model is trained using the local training set in test site A. The gradient parameters generated during the training of the local model are encrypted with differential privacy (ε=0.1) and then uploaded to the server.

[0088] In test site B, 500 sets of cryogenic startup data for liquid oxygen pumps (temperature ≤ -180℃) are provided. A local model is trained using the local training set in test site B. The gradient parameters generated during the training of the local model are encrypted with differential privacy (ε=0.1) and then uploaded to the server.

[0089] The server uses a federated learning engine to perform weighted aggregation of the encrypted gradient parameters uploaded by each test site (which can be understood as each client) (e.g., weights A:B=2:1). Then, it uses the weighted aggregated gradient parameters to update the global lifetime prediction model. The above steps are repeated until the global lifetime prediction model meets the preset accuracy requirements.

[0090] The federated learning engine supports secure data aggregation across test sites, reducing data cleaning time and significantly decreasing cross-test site collaborative training time.

[0091] According to some optional embodiments of this disclosure, the execution step S202 to verify the launch scheme also includes the following technical solutions: applying random perturbation to the combustion chamber pressure of the launch vehicle through Monte Carlo simulation to obtain the probability distribution of the launch vehicle's thrust; using a Bayesian update algorithm to quantify the deviation range between the output data of the thrust prediction model and the actual measurement data, and generating a confidence interval to represent the range of thrust values.

[0092] In the embodiments of this disclosure, Monte Carlo simulation is used to apply a random perturbation of ±5% to the combustion chamber pressure to simulate uncertainties that may occur in actual operation. After multiple simulations, a probability distribution of thrust output is obtained, which is used to evaluate the robustness and risk boundary of the system.

[0093] By combining Bayesian updates with the latest measured data to dynamically correct the parameters of the original model, the accuracy of the model's prediction of future states is improved. This method is particularly suitable for modeling propulsion systems with uncertainties and nonlinear characteristics.

[0094] Compared to the original model, the Bayesian-updated model shows a significant improvement in prediction accuracy, with an error reduction of ≥30%. The final output is a 95% confidence interval (e.g., thrust prediction of 4850-5150 kN), which is visually displayed through a holographic dashboard heatmap.

[0095] The aforementioned 95% confidence interval refers to the statistical range given for the thrust prediction value, indicating that there is a 95% probability that the actual thrust is within this interval, providing a more reliable basis for engineering judgment than a single value.

[0096] This disclosure provides an optional implementation method. Step S203 simulates the launch process of a launch vehicle based on a launch scheme, including the following steps: receiving virtual flight control commands; responding to the virtual flight control commands, simulating the attitude changes of the launch vehicle in different flight phases to verify the stability of the launch vehicle's flight control system; driving the launch vehicle's engine nozzle to dynamically adjust the thrust within a preset thrust range according to the virtual flight control commands to test the launch vehicle's thrust adjustment mechanism; acquiring the launch vehicle's nozzle expansion ratio change data to verify the performance of the launch vehicle's control algorithm; and achieving coordinated operation between multiple simulation nodes through distributed middleware to ensure that the launch vehicle's separation mechanism and physical actuators move synchronously.

[0097] In the embodiments of this disclosure, commands are received from the virtual flight control system, realizing a simulation environment that combines virtual and real elements. Furthermore, the simulation system provides six degrees of freedom (translation and rotation along the X, Y, and Z axes), enabling precise simulation of the rocket's attitude changes at different flight stages. It is suitable for simulating complex dynamic scenarios such as takeoff, separation, and landing. It can also be used to verify the stability of the launch vehicle's flight control system.

[0098] It can dynamically adjust thrust according to virtual commands, simulate different flight conditions and emergency situations, with a thrust adjustment range of 50%-110%, thereby enabling the testing of the launch vehicle's thrust adjustment mechanism.

[0099] After the rocket test stand performs a virtual maiden flight, it uses a deep reinforcement learning (DRL) algorithm to generate a thrust curve to drive the physical nozzle. Sensors acquire data on the changes in the launch vehicle's nozzle expansion ratio and feed it back to the data calibration model in real time.

[0100] As some optional embodiments of this disclosure, high-precision clock synchronization is also achieved through distributed middleware to ensure that multiple simulation nodes operate on the same time base and avoid logic errors caused by time deviations.

[0101] This disclosure provides an optional implementation method. Step S203 involves responding to and correcting faults during the simulation test. This is achieved through the following method: During the launch vehicle's flight phase, if the pressure fluctuation value of the second-stage engine combustion chamber exceeds a preset threshold, a graph neural network model is used to analyze the sensor topology of the launch vehicle and locate the cause of the fault where the combustion chamber pressure fluctuation value exceeds the preset threshold; the optimal fuel recovery trajectory of the launch vehicle is generated based on deep reinforcement learning; and a Bayesian update algorithm is used to quantify the deviation range between the temperature distribution data predicted by the thermal protection model and the actual measured temperature data, thereby correcting the thermal protection model.

[0102] During flight, if the pressure fluctuation in the second-stage engine combustion chamber exceeds the threshold (5%), a return path is immediately planned. Deep reinforcement learning (DRL) is used to generate the optimal fuel recovery trajectory, and holographic projection dynamically updates the landing trajectory. After recovery, the credibility assessment module analyzes the actual data and corrects the thermal protection model parameters, reducing the ablation prediction error from 5% to 1.2%.

[0103] In the embodiments of this disclosure, when locating the cause of a fault where the combustion chamber pressure fluctuation value exceeds a preset threshold, a graph neural network (GNN) can be used to analyze the sensor topology relationship, which can quickly locate the abnormal source (such as valve jamming) in a short time.

[0104] In some optional embodiments of this disclosure, the above method further includes: dynamically allocating computing power based on task priority according to deep reinforcement learning, wherein high-priority tasks are allocated to edge image processor GPU nodes for processing, and low-priority tasks are allocated to cloud processors for processing.

[0105] In the embodiments disclosed herein, the DRL algorithm can also be used to dynamically allocate computing power, assigning high-precision aerodynamic calculations to edge GPU nodes and historical data analysis tasks to cloud CPU clusters, thereby increasing resource utilization from 40% to 80%.

[0106] The simulation system and method proposed in this disclosure will be described below in two different application scenarios.

[0107] Example 1: Full-process simulation verification During the design phase, engineers used an AR interface to set a target of 10 tons of payload capacity to low Earth orbit for the launch vehicle. They also used AI to generate five candidate schemes and used holographic projection to compare and demonstrate the stability of each scheme under a crosswind of 20 m / s.

[0108] After selecting a scheme, the MBSE tool automatically generates a SysML model, which is then exported to ANSYS to verify the structural strength.

[0109] During the testing phase, the rocket test stand performed a virtual maiden flight. The DRL algorithm generated a thrust curve to drive the physical nozzle, and the sensor provided real-time feedback data to calibrate the model with an error of ≤0.5%.

[0110] During the flight phase, the edge AI detected that the pressure fluctuation in the combustion chamber of the second-stage engine exceeded the threshold (5%), and immediately planned the return route, dynamically updating the landing trajectory with holographic projection.

[0111] After recovery, the credibility assessment module analyzed the actual data and corrected the parameters of the thermal protection model, reducing the ablation prediction error from 5% to 1.2%.

[0112] Example 2: Cross-test field collaborative optimization Test site A provides high-temperature engine data, while test site B provides low-temperature data. The federated learning framework protects local data through differential privacy (ε=0.1) and aggregates and updates the global model, improving the generalization ability of turbopump life prediction by 20%. At the same time, the DRL algorithm dynamically allocates computing power, assigning high-precision aerodynamic calculations to edge GPU nodes and historical data analysis tasks to cloud CPU clusters, increasing resource utilization from 40% to 80%.

[0113] Step 1: Requirements Input and Solution Generation User interaction layer: Engineers wear AR headsets and use gestures to select the rocket body diameter (3.5 meters), and then use voice input to "generate a rocket scheme with a low Earth orbit carrying capacity of ≥10 tons based on historical test site engine data".

[0114] Step 2: Data Encryption and Local Training Test Site A (High Temperature Environment): The local training dataset contains 1,000 sets of engine high temperature operating condition data (combustion chamber pressure ≥ 10 MPa). The local model is trained based on the training dataset of Test Site A to predict the turbopump life (RMSE ≤ 8%). The generated gradient parameters are encrypted with differential privacy (ε = 0.1) and then uploaded to the cloud.

[0115] Test Site B (Low Temperature Environment): The local training dataset contains 500 sets of liquid oxygen pump low temperature start-up data (temperature ≤ -180℃). The local model is trained based on the training dataset of Test Site B to predict the life of the turbopump. The generated gradient parameters are encrypted with differential privacy (ε=0.1) and then uploaded to the cloud.

[0116] Step 3: Global Model Aggregation and Validation Data fusion layer: The federated learning engine performs weighted aggregation of the encrypted gradient parameters uploaded from test site A and test site B on the server side (weight A:B=2:1), and uses the weighted aggregation gradient parameters to update the global lifetime prediction model, reducing the generalization error by 20%.

[0117] Credibility assessment: Using Monte Carlo simulation of random perturbation input parameters (temperature ±10℃, pressure ±3%), the 95% confidence interval of the lifetime prediction (e.g., 850-920 hours) is output and visualized through a holographic interface.

[0118] Step 4: Dynamic Resource Scheduling Middleware layer: Dynamically allocate computing power based on task priority using the DRL algorithm: high-priority tasks (such as real-time aerodynamic calculations) are allocated to edge GPU nodes with a grid resolution of 0.1mm and a computation latency of ≤1ms; low-priority tasks (such as historical data analysis) are allocated to cloud CPU clusters with a data throughput of ≥1TB / h.

[0119] AI Application Layer: Utilizes the DRL algorithm to access the historical design database and generate 5 candidate schemes (such as liquid oxygen / kerosene ratios of 70:30, 75:25, etc.) within 5 seconds. The schemes are compared and displayed using light field projection (8K resolution) to show the swing amplitude of the rocket body under a crosswind of 20m / s (maximum deviation ≤0.5°).

[0120] Step 5: MBSE Modeling and Validation Functional Logic Layer: After selecting a scheme, the SysML tool automatically generates a propulsion subsystem model, including: Structural model: tensile strength of carbon fiber composite material ≥500MPa (ANSYS nonlinear FEA verification); Thermal protection model: temperature distribution prediction of thermal insulation tiles during reentry (error ≤1℃), etc.

[0121] Data fusion layer: Monte Carlo simulation is used to apply ±5% perturbation to the combustion chamber pressure, and the thrust confidence range (4850-5150 kN) is output and displayed through a holographic instrument panel heat map.

[0122] Step 6: Semi-physical joint testing Hardware interface layer: The rocket test stand (six-degree-of-freedom platform) receives virtual flight control commands, drives the physical nozzle to adjust thrust (50%-110%), and the lidar scans the nozzle expansion ratio change in real time (accuracy 0.01mm).

[0123] Middleware layer: HLA middleware synchronizes multi-node simulation time (IEEE 1588 PTP protocol, error ≤1μs) to ensure that the virtual separation mechanism and the physical actuator move in sync.

[0124] Step 7: Dynamic Fault Response and Correction AI application layer: When the edge computing node detects that the pressure fluctuation in the combustion chamber of the secondary engine exceeds the threshold (5%), the GNN model locates the fault source within 10 seconds (fuel valve jamming probability ≥90%), triggering DRL to generate the return trajectory (landing accuracy ≤0.5 meters).

[0125] Data fusion layer: After recovery, the Bayesian update algorithm corrects the thermal protection model based on the measured temperature data (infrared thermal imager, sampling rate 100Hz), reducing the ablation prediction error from 5% to 1.2%.

[0126] The technical solution proposed in this disclosure can achieve the following technical effects compared with the prior art: Adopting a seven-layer vertical architecture, it clearly defines and standardizes interfaces for the user interaction layer, AI application layer, functional logic layer, data fusion layer, middleware layer, hardware interface layer, and physical layer. Each layer achieves bidirectional data communication through standardized binary interfaces, enabling end-to-end collaboration and resolving the layer fragmentation problem of traditional architectures. This reduces protocol conversion layers, improves simulation efficiency, and shortens the development cycle.

[0127] Federated learning is integrated with HLA middleware, and encrypted gradient aggregation and IEEE 1588 time synchronization mechanism are integrated into distributed simulation to break through the limitation of data silos and support secure collaboration across test sites.

[0128] Based on the industrial Ethernet protocol, the optical field and AR synchronization technology achieves a spatial error of ≤1mm and a time error of ≤1μs, providing technical support for high-precision virtual-real interaction.

[0129] The output distribution is generated through Monte Carlo simulation, and the Bayesian update dynamically corrects the model, quantifying the 95% confidence interval to provide a scientific basis for decision-making.

[0130] Virtual testing replaces 50% of physical testing, significantly reducing R&D costs.

[0131] This disclosure provides an electronic device including a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the steps of the method provided in any optional embodiment of this disclosure. Compared with the prior art, this achieves the technical effects of timely detection of design defects in launch vehicles, improving the safety of launch vehicle launch missions, and reducing the simulation cost of launch vehicle launch processes. In one alternative embodiment, an electronic device is provided, such as Figure 3 As shown, Figure 3 The illustrated electronic device 3000 includes a processor 3001 and a memory 3003. The processor 3001 and the memory 3003 are connected, for example, via a bus 3002. Optionally, the electronic device 3000 may further include a transceiver 3004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 3004 is not limited to one type, and the structure of the electronic device 3000 does not constitute a limitation on the embodiments of this disclosure.

[0132] Processor 3001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with this disclosure. Processor 3001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0133] Bus 3002 may include a pathway for transmitting information between the aforementioned components. Bus 3002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 3002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0134] The memory 3003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0135] The memory 3003 is used to store computer programs that execute embodiments of the present disclosure, and is controlled by the processor 3001 to execute them. The processor 3001 is used to execute the computer programs stored in the memory 3003 to implement the steps shown in the foregoing method embodiments.

[0136] Electronic devices include, but are not limited to, computer equipment.

[0137] This disclosure provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0138] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0139] It should be understood that although arrows indicate various operation steps in the flowcharts of the embodiments of this disclosure, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of the embodiments of this disclosure, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all of the steps in each flowchart may include multiple sub-steps or multiple stages based on the actual implementation scenario. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured as required, and the embodiments of this disclosure do not limit this.

[0140] The above description is only an optional implementation method for some implementation scenarios of this disclosure. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this disclosure without departing from the technical concept of this disclosure also fall within the protection scope of the embodiments of this disclosure.

Claims

1. A simulation method for the launch process of a carrier rocket, characterized in that, include: Determine the launch plan for the launch vehicle, wherein the launch plan includes the launch parameters of the launch vehicle; The launch scheme was modeled and verified. Based on the verified launch scheme, the launch process of the launch vehicle was simulated and tested, and faults in the simulation test were responded to and corrected.

2. The method according to claim 1, characterized in that, Modeling and validating the launch scheme includes: An architecture model of the launch vehicle's propulsion system is established using the system modeling language SysML. The architecture model includes: a structural model, which characterizes the physical structural components in the launch vehicle's propulsion system; and a thermal protection model, which predicts the temperature distribution data of the launch vehicle's thermal insulation tiles during atmospheric reentry. The strength of the structural model is verified by predicting the deformation of the launch vehicle body through nonlinear finite element analysis.

3. The method according to claim 1, characterized in that, The verification of the launch scheme includes: The remaining service life of the launch vehicle's turbopump is predicted based on the first deep learning model, and when an abnormality is detected in the components of the turbopump, a maintenance work order is generated and sent to the interactive device for display. The first deep learning model is trained using the following method: Step S1: Initialize the turbopump life prediction model locally on the server. Step S2: Obtain multiple encrypted gradient parameters from multiple nodes respectively. The different gradient parameters are generated by different nodes during the process of training the turbopump life prediction model using their respective test field engine data. Step S3: Use the federated learning engine to perform weighted aggregation processing on the multiple encrypted gradient parameters; Step S4: Update the turbopump life prediction model using the processed gradient parameters; Repeat steps S2 to S4 until the training of the turbopump life prediction model is completed.

4. The method according to claim 1, characterized in that, The verification of the launch scheme includes: By applying random perturbations to the combustion chamber pressure of the launch vehicle through Monte Carlo simulation, the probability distribution of the launch vehicle's thrust was obtained. A Bayesian update algorithm is used to quantify the deviation range between the output data of the thrust prediction model and the actual measurement data, and to generate a confidence interval to represent the range of thrust values.

5. The method according to claim 1, characterized in that, The launch process of the launch vehicle was simulated and tested based on the launch scheme, including: Receive virtual flight control commands; In response to the virtual flight control commands, the attitude changes of the launch vehicle at different flight stages are simulated to verify the stability of the launch vehicle's flight control system. The virtual flight control commands drive the rocket's engine nozzle to dynamically adjust the thrust within a preset thrust range, thereby testing the rocket's thrust adjustment mechanism. To obtain data on the change in the nozzle expansion ratio of the launch vehicle and to verify the performance of the launch vehicle's control algorithm; Distributed middleware is used to enable coordinated operation among multiple simulation nodes to ensure that the separation mechanism of the launch vehicle is synchronized with the physical actuators.

6. The method according to claim 2, characterized in that, Responding to and correcting faults during simulation testing, including: During the flight phase of a launch vehicle, if the pressure fluctuation value of the combustion chamber of the second-stage engine exceeds a preset threshold, a graph neural network model is used to analyze the sensor topology of the launch vehicle and locate the cause of the fault where the pressure fluctuation value of the combustion chamber exceeds the preset threshold. Generate the optimal fuel recovery trajectory for launch vehicles based on deep reinforcement learning; The deviation range between the temperature distribution data predicted by the thermal protection model and the actual measured temperature distribution data is quantified using a Bayesian update algorithm, and the thermal protection model is then corrected.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: Based on deep reinforcement learning, computing power is dynamically allocated according to task priority. High-priority tasks are assigned to edge image processor GPU nodes for processing, while low-priority tasks are assigned to cloud processors for processing.

8. A simulation system for the launch process of a carrier rocket, used to implement the method according to any one of claims 1 to 7, characterized in that, include: The layers consist of a user interaction layer, an AI application layer, a functional logic layer, a data fusion layer, a middleware layer, a hardware interface layer, and a physical layer. The user interaction layer, located at the top layer of the simulation system, is used to realize human-computer interaction between the user and the simulation system and to define a unified communication protocol. The AI ​​application layer, located between the user interaction layer and the functional logic layer, is used to perceive the operational status of the launch vehicle during the simulation of the launch process. The functional logic layer, located between the AI ​​application layer and the data fusion layer, is used to realize multi-physics coupling simulation of the launch vehicle in the simulation system, as well as cross-model data exchange and calculation. The data fusion layer, located between the functional logic layer and the middleware layer, is used to process data collected from sensors distributed at different locations on the launch vehicle. The middleware layer, located between the data fusion layer and the hardware interface layer, is used to implement at least the following functions: cross-platform communication, time synchronization, and spatial synchronization. The hardware interface layer, located between the middleware layer and the physical layer, is used to connect physical devices with the upper-layer software system. The physical layer, located at the bottom layer of the simulation system, is used to support physical devices.

9. An electronic device, comprising: A memory, a processor, and a computer program stored on the memory, characterized in that the processor executes the computer program to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images